DBCC SHRINKFILE爲什麼在數據庫作業中不一致地工作？

DBCC SHRINKFILE當我在日誌文件中手動運行它始終工作，甚至當我得到以下信息：DBCC SHRINKFILE爲什麼在數據庫作業中不一致地工作？

'Cannot shrink log file 2 (Claim_Log) because all logical log files are in use.'

當我從工作中運行，但是，它只能收縮日誌的約三分之一時間。其他時候，它仍然很大（約150Gb）。除了上面列出的以外，沒有任何錯誤。這是我使用的聲明：

DBCC SHRINKFILE (N'Claim_log' , 0, TRUNCATEONLY)

我在作業步驟中啓用了「在歷史記錄中包含步驟輸出」。有什麼我可以做，以獲得更多的信息，爲什麼這不起作用？

編輯：下面是從日誌的完整信息：

'Executed as user: *. Cannot shrink log file 2 (Claim_Log) because all logical 
log files are in use. [SQLSTATE 01000] (Message 9008) DBCC execution completed. 
If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] 
(Message 2528). The step succeeded.'

我已經嘗試踢出來的用戶數據庫，並將其設置爲單用戶模式。

來源

2008-12-09 Keith Walton

我最近解決了類似的問題，我發現在sys.databases中，log_reuse_wait_desc等於'replication'。顯然，這意味着SQL Server在等待複製任務完成之前可以重用日誌空間。

但是，我們的數據庫和我們的服務器上從未使用過複製功能。您應該能夠通過運行'sp_removedbreplication'來清除狀態;但對於我'sp_removedbreplication'沒有解決問題。相反，SQL剛回到說，數據庫不是複製的一部分......

，我發現我的答案在這裏：

基本上我不得不創建複製，將所有複製指針重置爲零;然後刪除我剛剛創建的複製。即

Execute SP_ReplicationDbOption {DBName},Publish,true,1 
GO 
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 
GO 
DBCC ShrinkFile({LogFileName},0) 
GO 
Execute SP_ReplicationDbOption {DBName},Publish,false,1 
GO

來源

2011-07-06 04:10:53 MrEs

首先嚐試發出CHECKPOINT命令，然後從BOL（http://msdn.microsoft.com/en-us/library/aa226036(SQL.80).aspx）所採取的日誌

強制所有當前數據庫的髒頁寫入磁盤萎縮。髒頁進入緩衝區緩存後修改了數據或日誌頁面，但修改尚未寫入磁盤。有關日誌截斷的更多信息，請參見截斷事務日誌。

來源

2008-12-09 17:01:49 rip747

我將它添加到我的工作，並給它一個嘗試 – 2008-12-09 17:05:18

表示當前日誌文件正在使用併發出檢查點，其中檢查點將寫入未從事務日誌文件（髒頁）寫入數據文件的數據文件。檢查是否有任何當前的活動是怎麼回事與否，使用活動事務

入住在2005年 SELECT * FROM sys.dm_tran_session_transactions

2000 DBCC LOGINFO

好好計劃=> 1 。創建維護計劃備份日誌（Made Plan）。

來源

2009-08-29 05:18:05

DBCC SHRINKFILE爲什麼在數據庫作業中不一致地工作？

回答

相關問題