# 錯誤描述

錯誤描述：資料庫的事務日誌已滿。若要查明無法重用日誌中的空間的原因 ，請參閱sys.databases 中的 log_reuse_wait_desc 列 。

# 錯誤原因
## 事務日誌介紹

官方文件中有如下說明：
>SQL Server 資料庫引擎 事務日誌的特徵：
事務日誌是作為資料庫中的單獨的檔案或一組檔案實現的。 日誌快取與資料頁的緩衝區快取記憶體是分開管理的，因此可在 SQL Server 資料庫引擎中生成簡單、快速和功能強大的程式碼。 有關詳細資訊，請參閱事務日誌物理體系結構。
日誌記錄和頁的格式不必遵守資料頁的格式。
事務日誌可以在幾個檔案上實現。 透過設定日誌的 FILEGROWTH 值可以將這些檔案定義為自動擴充套件。 這樣可減少事務日誌內空間不足的可能性，同時減少管理開銷。 有關詳細資訊，請參閱 ALTER DATABASE (Transact-SQL) 檔案和檔案組選項。
重用日誌檔案中空間的機制速度快且對事務吞吐量影響最小。

>日誌截斷將釋放日誌檔案的空間，以便由事務日誌重新使用。 必須定期截斷事務日誌，防止佔滿分配的空間。 幾個因素可能延遲日誌截斷，因此監視日誌大小很重要。 某些操作可以最小日誌量進行記錄以減少其對事務日誌大小的影響。
日誌截斷從 SQL Server 資料庫的邏輯事務日誌中刪除不活動的虛擬日誌檔案 (VLF)，釋放邏輯日誌中的空間以便物理事務日誌重用這些空間。 如果事務日誌從不截斷，它最終將填滿分配給物理日誌檔案的所有磁碟空間。
為了避免空間不足，除非由於某些原因延遲日誌截斷，否則將在以下事件後自動進行截斷：
簡單恢復模式下，在檢查點之後發生。
在完整恢復模式或大容量日誌恢復模式下，如果自上一次備份後生成檢查點，則在日誌備份後進行截斷（除非是僅複製日誌備份）。

> 日誌截斷並不減小物理日誌檔案的大小。 若要減少物理日誌檔案的物理大小，則必須收縮日誌檔案。 有關收縮物理日誌檔案大小的資訊，請參閱 管理事務日誌檔案的大小。但是，請記住可能延遲日誌截斷的因素。 如果在日誌收縮後還需要儲存空間，則會再次增加事務日誌，導致在增加日誌操作期間產生效能開銷。

在日誌記錄長時間處於活動狀態時，事務日誌截斷將延遲，事務日誌可能填滿。
實際上，日誌截斷會由於多種原因發生延遲。查詢 sys.databases 目錄檢視的 log_reuse_wait 和 log_reuse_wait_desc 列，瞭解哪些因素（如果存在）阻止日誌截斷。 下表對這些列的值進行了說明。

| log_reuse_wait 值 | log_reuse_wait_desc 值 | 描述 
|--|--|:----------
| 0 | NOTHING | 當前有一個或多個可重複使用的虛擬日誌檔案 (VLF)。
|1	|CHECKPOINT |	自上次日誌截斷之後，尚未生成檢查點，或者日誌頭尚未跨一個虛擬日誌 (VLF) 檔案移動。 （所有恢復模式）這是日誌截斷延遲的常見原因。 有關詳細資訊，請參閱資料庫檢查點 (SQL Server)。
|2	|LOG_BACKUP	|在截斷事務日誌前，需要進行日誌備份。 （僅限完整恢復模式或大容量日誌恢復模式）完成下一個日誌備份後，一些日誌空間可能變為可重複使用。
|3	|ACTIVE_BACKUP_OR_RESTORE	|資料備份或還原正在進行（所有恢復模式）。如果資料備份阻止了日誌截斷，則取消備份操作可能有助於解決備份直接導致的此問題。
|4	|ACTIVE_TRANSACTION	|事務處於活動狀態（所有恢復模式）：一個長時間執行的事務可能存在於日誌備份的開頭。 在這種情況下，可能需要進行另一個日誌備份才能釋放空間。 請注意，長時間執行的事務將阻止所有恢復模式下的日誌截斷，包括簡單恢復模式，在該模式下事務日誌一般在每個自動檢查點截斷。延遲事務。 “延遲的事務 ”是有效的活動事務，因為某些資源不可用，其回滾受阻。 有關導致事務延遲的原因以及如何使它們擺脫延遲狀態的資訊，請參閱延遲的事務 (SQL Server)。長時間執行的事務也可能會填滿 tempdb 的事務日誌。 Tempdb 由使用者事務隱式用於內部物件，例如用於排序的工作表、用於雜湊的工作檔案、遊標工作表，以及行版本控制。 即使使用者事務只包括讀取資料（SELECT 查詢），也可能會以使用者事務的名義建立和使用內部物件， 然後就會填充 tempdb 事務日誌。
|5	|DATABASE_MIRRORING	|資料庫映象暫停，或者在高效能模式下，映象資料庫明顯滯後於主體資料庫。 （僅限完整恢復模式）有關詳細資訊，請參閱資料庫映象 (SQL Server)。
|6	|REPLICATION	|在事務複製過程中，與釋出相關的事務仍未傳遞到分發資料庫。 （僅限完整恢復模式）有關事務複製的資訊，請參閱 SQL Server Replication。
|7	|DATABASE_SNAPSHOT_CREATION	|正在建立資料庫快照。 （所有恢復模式）這是日誌截斷延遲的常見原因，通常也是主要原因。
|8	|LOG_SCAN	|發生日誌掃描。 （所有恢復模式）這是日誌截斷延遲的常見原因，通常也是主要原因。
|9	|AVAILABILITY_REPLICA|	可用性組的輔助副本正將此資料庫的事務日誌記錄應用到相應的輔助資料庫。 （完整恢復模式）有關詳細資訊，請參閱： AlwaysOn 可用性組概述 (SQL Server)。
|10	|—	|僅供內部使用
|11	|—	|僅供內部使用
|12	|—	|僅供內部使用
|13	|OLDEST_PAGE|	如果將資料庫配置為使用間接檢查點，資料庫中最早的頁可能比檢查點日誌序列號 (LSN) 早。 在這種情況下，最早的頁可以延遲日誌截斷。 （所有恢復模式）有關間接檢查點的資訊，請參閱資料庫檢查點 (SQL Server)。
|14	|OTHER_TRANSIENT	|當前未使用此值。

## 排查日誌已滿問題
官方文件：[解決事務日誌已滿的問題（SQL Server 錯誤 9002）](https://docs.microsoft.com/zh-cn/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002?view=sql-server-2017)

# 解決方法
在SQL 2008中清除日誌必須在簡單模式下進行，等清除動作完畢在調回到完整模式（否則資料庫就不支援時間點備份）
```sql
--檢視日誌檔案狀況
 use dbname
 dbcc shrinkfile('logname')  --like  XXXX_log
 ```
## 方法一：介面方式收縮日誌
### 第一步：調整恢復模式
選擇資料庫-屬性-選項-恢復模式-選擇簡單
![在這裡插入圖片描述](https://img-blog.csdn.net/20181007092451207?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE1OTIzNTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)
![在這裡插入圖片描述](https://img-blog.csdn.net/20181007092511682?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE1OTIzNTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)

>在完整 恢復模式下，所有大容量操作都將被完整地記錄下來。 但是，可以透過將資料庫暫時切換到用於大容量操作的大容量日誌恢復模式，最小化一組大容量操作的日誌記錄。 最小日誌記錄比完整日誌記錄更為有效，並在大容量事務期間，降低了大規模大容量操作填滿可用的事務日誌空間的可能性。 不過，如果在最小日誌記錄生效時資料庫損壞或丟失，則無法將資料庫恢復到故障點。

### 第二步：收縮日誌檔案
選擇資料庫-任務-收縮-檔案
![在這裡插入圖片描述](https://img-blog.csdn.net/20181007092531672?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE1OTIzNTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)
![在這裡插入圖片描述](https://img-blog.csdn.net/20181007092547477?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE1OTIzNTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)

#### 選項說明
**"資料庫"**
顯示所選資料庫的名稱。

**"檔案型別"**
選擇檔案的檔案型別。 可用的選項包括 “資料” 和 “日誌” 檔案。 預設選項為 “資料”。 選擇不同的檔案組型別，其他欄位中的選項會相應地發生更改。

**"檔案組"**
在與以上所選的 “檔案型別” 相關聯的檔案組列表中選擇檔案組。 選擇不同的檔案組，其他欄位中的選項會相應地發生更改。

**"檔名"**
從所選檔案組和檔案型別的可用檔案列表中選擇檔案。

**"位置"**
顯示當前所選檔案的完整路徑。 此路徑無法編輯，但是可以複製到剪貼簿。

**"當前分配的空間"**
對於資料檔案，會顯示當前分配的空間。 對於日誌檔案，會顯示根據 DBCC SQLPERF (LOGSPACE) 的輸出計算出的當前分配的空間。

**"可用空間"**
對於資料檔案，會顯示根據 SHOWFILESTATS (fileid) 的輸出計算出的當前可用空間。 對於日誌檔案，會顯示根據 DBCC SQLPERF (LOGSPACE) 的輸出計算出的當前可用空間。

**"釋放未使用的空間"**
將任何檔案中未使用的空間釋放給作業系統，並將檔案收縮到最後分配的區，因此無需移動任何資料即可減小檔案尺寸。 不會將行重新定位到未分配的頁。

**"在釋放未使用的空間前重新組織頁"**
等效於執行用於指定目標檔案大小的 DBCC SHRINKFILE。 選中此選項時，使用者必須在 “將檔案收縮到” 框中指定目標檔案的大小。

**"將檔案收縮到"**
為收縮操作指定目標檔案的大小。 此大小值不得小於當前分配的空間或大於為檔案分配的全部區的大小。 如果輸入的值超出最小值或最大值，那麼一旦焦點改變或單擊工具欄上的按鈕時，數值將恢復到最小值或最大值。

**"透過將資料遷移到同一檔案組中的其他檔案來清空檔案"**
從指定檔案遷移所有資料。 此選項允許使用 ALTER DATABASE 語句刪除檔案。 此選項等效於執行帶有 EMPTYFILE 選項的 DBCC SHRINKFILE。

### 第三步：調整恢復模式
選擇資料庫-屬性-選項-恢復模式-選擇簡單
![在這裡插入圖片描述](https://img-blog.csdn.net/20181007092602435?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE1OTIzNTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)
## 方法二：命令列方式收縮日誌
**本方法未實際操作**
```sql
USE [master]
	GO 
	ALTER DATABASE DNName SET RECOVERY SIMPLE WITH NO_WAIT
	GO
	ALTER DATABASE DNName SET RECOVERY SIMPLE--簡單模式
	GO
	USE DNName
	GO
	DBCC SHRINKFILE(N'DNName_Log',11,TRUNCATEONLY)
	GO
	USE [master]
	GO
	ALTER DATABASE DNName SET RECOVERY FULL WITH NO_WAIT
	GO
	ALTER DATABASE DNName SET RECOVERY FULL--還原為完全模式
	GO
```

# 另請參閱
[SQL Server 事務日誌體系結構和管理指南](https://docs.microsoft.com/zh-cn/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-2017)
[管理事務日誌檔案的大小](https://docs.microsoft.com/zh-cn/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-2017)
[事務日誌](https://docs.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-2017)
[收縮檔案](https://docs.microsoft.com/zh-cn/sql/relational-databases/databases/shrink-a-file?view=sql-server-2017)
[探查 SQL Server 虛擬日誌檔案](http://blog.51cto.com/jimshu/1174474)
[SQL2008R2 收縮資料庫問題 - 日誌檔案不變小](https://www.cnblogs.com/strayromeo/p/6961758.html)

SQLServer 2008中事務日誌已滿問題處理

相關文章