早上檢查數據發現,有一台數據的硬盤空間只剩下幾MB。習慣性檢查日志文件,發現日志文件居然暴增到了350多GB
首先備份日志,再收縮-------無變化。(實際上日志備份每1小時1擋,正常在跑.)
---------------------------------------------------------------------------
檢查日志空間占用及不能截斷原因:
DBCC SQLPERF(LOGSPACE) GO SELECT name,recovery_model_desc,log_reuse_wait,log_reuse_wait_desc FROM sys.databases GO
可以看到log_reuse_wait_desc 為REPLICATION
在該庫下執行DBCC loginfo(),可以看到該數據庫的所有VLF的狀態都為2,也就是active狀態。
DBCC loginfo()
-----------------------------------------------------------------------
sp_removedbreplication 'XXXX'
實際上由於這個數據庫之前並沒有搭建過復制。服務器應該也沒有改過名字,所以該大招無效。
-----------------------------------------------------------------------
既然不是復制為何log_reuse_wait_desc 為REPLICATION呢?
疑凶轉移到了CDC(CDC和復制實際上底層都是使用LogReader的Job來掃描日志)。
SELECT IS_CDC_ENABLED ,CASE WHEN IS_CDC_ENABLED = 0 THEN 'CDC功能禁用' ELSE 'CDC功能啟用'END 描述 FROM SYS.DATABASES WHERE NAME = 'XXXX'
該庫果然開啟了CDC,繼續檢查CDC Job的運行狀態:
Declare @Job_ID as UNIQUEIDENTIFIER select @Job_ID=Job_ID from msdb.dbo.sysjobs where name = 'cdc.XXXX_capture' Exec master..sp_MSget_jobstate @Job_ID
返回值為 4 - 表示完成(成功或失敗),正常情況下CDC Capture的Job應該是1(正在運行)才對。
斷定cdc.XXXX_capture這個Job由於某種原因被異常中止了。
------------------------------------------------------------------------------------
至少日志不能截斷的原因終於找到了。
手動啟動cdc.XXXX_capture。此處省略NNNN分鍾等待(在此提醒各位硬盤空間不夠的童鞋,cdc捕獲也需要大量磁盤空間哦!!!騰出足夠的硬盤空間或者新建個log文件在其他盤吧)。
等待log_reuse_wait_desc狀態變為LOG_BACKUP。
備份日志后收縮日志成功!~
打完收工。