數據庫 'tempdb' 的事務日志已滿。若要查明無法重用日志中的空間的原因

 

最常的做法：

 

--1.清空日志
DUMP TRANSACTION tempdb WITH NO_LOG
--2.截斷事務日志：
BACKUP LOG tempdb WITH NO_LOG
--3.收縮數據庫文件
DBCC SHRINKDATABASE(tempdb)

 

比較保險的做法：

1. 將tempdb移至D盤或者其它非系統分區;

2. tempdb增加文件大小(最大值至少5G，初始值可大一點)並重啟SqlServer服務.

 

參考文章：

1. 微軟官方優化數據庫：點擊打開鏈接

2. 點擊打開鏈接

 

注：微軟的優化里有：

將 tempdb 的恢復模式設置為  SIMPLE。 此模式自動回收日志空間以保持較小的空間要求。

USE [master]
GO
ALTER DATABASE tempdb SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE tempdb SET RECOVERY SIMPLE   --簡單模式
GO

其實是無效的，因為tempdb無法設置為simple恢復模式。

 

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

--查看會話

 

SELECT * 
FROM sys.dm_exec_sessions AS t2,sys.dm_exec_connections AS t1
        CROSS APPLY sys.dm_exec_sql_text(t1.most_recent_sql_handle) AS st
WHERE   t1.session_id = t2.session_id 
ORDER BY t1.session_id

--查看日志狀態
SELECT NAME,log_reuse_wait_desc FROM sys.databases

--中止會話

 

Kill session_id

 

 

微軟文檔：導致日志截斷延遲的因素　 點擊打開鏈接

 

下表介紹了 sys.database 目錄視圖的 log_reuse_wait 列和 log_reuse_wait_desc 列的值。

 

 

log_reuse_wait 值	log_reuse_wait_desc 值	說明
0	NOTHING	當前有一個或多個可重用的虛擬日志文件。
1	CHECKPOINT	自上次日志截斷之后，尚未出現檢查點，或者日志頭部尚未跨一個虛擬日志文件移動（所有恢復模式）。 這是日志截斷延遲的常見原因。 有關詳細信息，請參閱檢查點和日志的活動部分。
2	LOG_BACKUP	要求日志備份將日志標頭前移（僅適用於完整恢復模式或大容量日志恢復模式）。   日志備份不會阻止截斷。 注意：   日志備份完成后，日志標頭將前移，並且一些日志空間可能會變為可重新使用。
3	ACTIVE_BACKUP_OR_RESTORE	數據備份或還原正在進行（所有恢復模式）。 數據備份與活動事務的工作原理相同；數據備份運行時，將阻止截斷。 有關詳細信息，請參閱本主題后面的“數據備份操作與還原操作”部分。
4	ACTIVE_TRANSACTION	事務處於活動狀態（所有恢復模式）。 在日志備份開始時，可能存在長時間運行的事務。 在這種情況下，釋放空間可能需要進行其他日志備份。 有關詳細信息，請參閱本主題后面的“長時間運行的活動事務”部分。 事務將延遲（僅適用於 SQL Server 2005 Enterprise Edition 及更高版本）。 “延遲的事務”實際上是其回滾由於某些資源不可用而受阻的活動事務。 有關導致事務延遲的原因以及如何使它們擺脫被延遲狀態的信息，請參閱延遲的事務.
5	DATABASE_MIRRORING	數據庫鏡像暫停，或者在高性能模式下，鏡像數據庫明顯滯后於主體數據庫（僅限於完整恢復模式）。 有關詳細信息，請參閱本主題后面的“數據庫鏡像與事務日志”部分。
6	REPLICATION	在事務復制過程中，與發布相關的事務仍未傳遞到分發數據庫（僅限於完整恢復模式）。 有關詳細信息，請參閱本主題后面的“事務復制與事務日志”部分。
7	DATABASE_SNAPSHOT_CREATION	正在創建數據庫快照（所有恢復模式）。 這是日志截斷延遲的常見原因，通常也是主要原因。
8	LOG_SCAN	正在進行日志掃描（所有恢復模式）。 這是日志截斷延遲的常見原因，通常也是主要原因。
9	OTHER_TRANSIENT	此值當前未使用。