史丹利好熱

 

測試的AlwaysOn環境有3台DB，DB1是主要複本，DB2是同步(synchronous)的次要複本，DB3則是非同步(Asynchronous)的次要複本。

 

---

查詢延遲截斷交易紀錄原因

如果發現有延遲截斷交易紀錄的現象，可以查詢sys.databases catalog view，從欄位log_reuse_wait_desc找到可能延遲的原因，我們這次出現的是9:AVAILABILITY_REPLICA

看起來是次要複本資料庫還在等待處理交易紀錄

*log_reuse_wait_desc: 交易記錄空間的重複利用正等待進行最後一個檢查點的下列其中一個作業

 

我們來實驗模擬這次遇到的狀況，時光重現的順序:

1. 執行前，觀察DB1、DB2及DB3的log使用狀況
2. 製造複本資料庫不再接收同步的現象
3. 執行交易紀錄備份(Transaction log Backup)，並且觀察DB1、DB2及DB3的log使用狀況是否降低
4. 恢復DB3複本資料庫開始同步
5. 再執行交易紀錄備份(Transaction log Backup)，觀察DB1、DB2及DB3的log使用狀況是否降低

 

---

執行前，觀察DB1、DB2及DB3的log使用狀況

分別連到DB1、DB2及DB3的Instance執行

SELECT @@servername
DBCC SQLPERF(logspace)

 

執行結果:

 

---

製造複本資料庫不再接收同步的現象

我們選非同步(Asynchronous)的複本DB3，手動用SQL指令暫停同步

ALTER database AGdb set hadr suspend

 

出現了 "未進行同步處理"

 

---

執行交易紀錄備份(Transaction log Backup)

BACKUP LOG [AGdb] TO  DISK = N'E:\SQL\AGDb_2017102801.trn' 
WITH NOFORMAT, NOINIT,  NAME = N'AGDB資料庫 備份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

 

 

再查詢一次log使用狀況，發現沒有截斷交易紀錄，而且三台DB都是，他們果然是一國的!

SELECT @@servername
DBCC SQLPERF(logspace)

 

沒有降下來，還是46%，有種交通阻塞的悶。

 

---

恢復DB3複本資料庫開始同步

ALTER database AGdb set hadr RESUME

 

 

---

再執行交易紀錄備份(Transaction log Backup)

BACKUP LOG [AGdb] TO  DISK = N'E:\SQL\AGDb_2017102802.trn'
WITH NOFORMAT, NOINIT,  NAME = N'AGDB資料庫 備份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

 

交易記錄檔的使用情形，由 46% 降為 17% .

 

小結:

 

如果次要複本伺服器一時之間回不來，只好當斷則斷，捨不下永遠無得，勘不破正是迷障.

ALTER AVAILABILITY GROUP [AG]
REMOVE REPLICA ON N'DB3';

 

增加Transaction log備份頻率: 截斷交易紀錄(減少過多VLFs) + 更好的RPO(Recovery Point Objective復原點目標)

docs says

建議您時常進行記錄備份，以將工作損失風險降至最低，同時也讓記錄能夠截斷。

 

---

參考

sys.databases (Transact-SQL)

Factors that can delay log truncation

ALTER DATABASE (TRANSACT-SQL) SET HADR

交易記錄備份 (SQL Server)

redo thread and a switch-role thread DeadLock導致的未進行同步處理