因為高可用必須是完整備份,所以日志就會越來越大。
平時收縮日志最簡單粗暴的方法是 先把數據庫設置為簡單模式,然后收縮日志文件,然后再恢復為完整備份。
但是 高可用模式下,系統是無法設置為簡單模式的。
所以采用一下方法(責任自負,后果自負):以下操作在主庫上進行操作,因為只有主副本可讀可寫.
step1:備份日志文件到空盤
BACKUP LOG myDatabaseName TO DISK='NUL:'
step2:查看日志狀態
Use myDatabaseName GO dbcc loginfo
如果狀態為 "2",執行 step3
如果狀態為"0",則可跳過Step3 直接執行Step 4
step3:帶 EMPTYFILE 參數 執行收縮 ,執行后再 DBCC loginfo 查看,沒有反應可以多執行幾次 step 1,2,3,4
DBCC SHRINKFILE (myDatabaseName_Log, EMPTYFILE);
step4:收縮日志文件到指定大小 以下單位為M.
DBCC SHRINKFILE (myDatabaseName_Log, 500); –This would physically shrink the database size to 500 Megabytes.
注意事項:
1 當日志無法收縮時,請確認副本數據庫是否是正常狀態,如果副庫是可疑狀態,則無法收縮成功. 如果是這種情況,可以刪除可疑庫再進行操作.
Note: Before determining the size of 500Mb to shrink to, you may want to consider how much of the log file is in use, otherwise the shrink operation will not work. Also, you may want to consider allowing the size of the log file to be 25% of the size of the physical database file (.MDF) because otherwise when log growth happens, the database operations will block all active transactions and that will cause latency within applications (imagine users complaining).
You can determine how much of the log file is in use by running this query:
Use myDatabaseName GO SELECT name ,size/128.0 – CAST(FILEPROPERTY(name, ‘SpaceUsed’) AS int)/128.0 AS AvailableSpaceInMB FROM sys.database_files;
So to determine the size of the log file to shrink to, subtract the “AvailableSpaceInMB” from the physical database size reported by the command: DBCC SQLPERF(LOGSPACE);. Then add some cushion so that future physical log growth does not block transactions from occurring.