2009-04-22 29 views
24

我有一個擁有28gig事務日誌文件的數據庫。恢復模式很簡單。我只是把數據庫的完整備份,然後跑了兩個:即使在備份之後,爲什麼我無法收縮事務日誌文件?

backup log dbmcms with truncate_only

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

數據庫的名稱是db_mcms和事務日誌文件的名稱是Wxlog0。

也沒有幫助。我不確定接下來要做什麼。

+0

無法運行上面的第一個命令,因爲我的數據庫處於完全恢復模式(儘管我認爲它很簡單)。我們的結果定期將數據庫從生產恢復到質量保證並且無法將恢復模式更改爲簡單。 – dudeNumber4 2015-01-14 14:04:53

回答

42

謝謝大家回答。

我們終於找到了問題。在sys.databases中,log_reuse_wait_desc等於'replication'。顯然,這意味着SQL Server在等待複製任務完成之前可以重用日誌空間。

複製 從來沒有在這個數據庫上使用過,或者這個服務器 曾經在這個數據庫上玩過。我們通過運行sp_removedbreplication來清除不正確的狀態。在我們運行這個之後,備份日誌和dbcc shrinkfile工作得很好。

絕對是一個用來裝袋的技巧。

來源:

http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b

http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705

+3

我搜索了很長時間才找到你的文章,這正是我的情況,我曾經啓用然後禁用數據庫鏡像。這顯然是一個神器。謝謝! – smoore4 2013-08-25 16:25:50

+1

感謝你!解決了我的問題吧! – sys49152 2014-05-31 12:57:05

0

你是否從SQL Server管理工作室內用GUI進行過嘗試。右鍵單擊數據庫,任務,縮小,文件。選擇filetype = Log。

我一個星期前爲我工作。

+0

沒有骰子。奇怪的是,它告訴我文件中可用的空閒空間是負數7gigs。 在這個數據庫似乎有東西被搗毀,我不知道它是什麼。 :( – 2009-04-22 20:53:18

0

嘗試後你創建另一個完全備份的備份日誌W/TRUNCATE_ONLY(IIRC你應該這樣做無論如何要保持日誌鏈)。在簡單恢復模式下,您的日誌不應該增長太多,因爲它在每次事務之後都會被截斷。然後嘗試指定希望日誌文件的大小,例如

-- shrink log file to c. 1 GB 
DBCC SHRINKFILE (Wxlog0, 1000); 

的TRUNCATEONLY選項不會重新排列日誌文件中的頁面,所以你可能在你的文件的「結束」,這可以防止它被縮小有一個活動頁面。

您還可以使用DBCC SQLPERF(LOGSPACE)來確保日誌文件中有真正的空間被釋放。

0

將數據庫恢復爲完整模式,運行事務日誌備份(而不僅僅是完整備份),然後收縮。

收縮後,您可以將數據庫恢復到簡單模式,並且它的日誌記錄將保持相同的大小。

0

您不能縮小比最初創建的大小更小的事務日誌。

1

如果您在2005年對數據庫設置了恢復模式(不知道2005年之前的版本),它會將日誌文件放在一起,然後您可以將其恢復爲完全恢復模式以重新啓動/重新創建日誌文件。我們用SQL 2005 express來解決這個問題,因爲在改變恢復模式之前,我們無法接近數據的4GB限制。

27

如果您的數據庫設置爲自動增長日誌&,那麼最終會出現大量虛擬日誌文件,您可能會遇到此問題。
運行DBCC LOGINFO('databasename') &看看最後一個條目,如果這是2,那麼你的日誌文件將不會縮小。與數據文件不同,虛擬日誌文件不能在日誌文件中移動。

您需要多次運行BACKUP LOG和DBCC SHRINKFILE才能使日誌文件收縮。

對於日誌&之間運行DBBC LOGINFO額外獎勵積分推卸

+5

感謝這個,它解決了我的問題。在http://technet.microsoft.com/en-us/library/ms178037%28v=sql.105%29更多的技術細節。 aspx和http://technet.microsoft.com/en-us/library/ms345414%28v=sql.105%29.aspx。 – jeffcook2150 2012-08-21 05:46:37

2

我有同樣的問題,在過去。通常需要多次執行收縮和trn備份。在極端情況下,我將數據庫設置爲「簡單」恢復,然後在日誌文件上執行收縮操作。這對我來說總是有效的。但是最近我遇到了一個不行的情況。這個問題是由於長時間運行的查詢沒有完成,所以任何縮小的嘗試都是無用的,直到我可以殺死該進程然後運行我的縮小操作。我們正在談論的日誌文件增長到60 GB,現在縮小到500 MB。

請記住,只要您從FULL更改爲簡單恢復模式並進行縮小,請不要忘記將其設置回FULL。然後立即執行完整的數據庫備份。

3

'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 
3

這個答案已經從here擡起,並張貼在這裏的情況下,其他線程被刪除:

你有非分佈式日誌中LSN是問題的事實。 我已經看到這一次之前不知道爲什麼我們不會取消 事務複製。我們將在內部進行調查。您可以 執行以下命令取消標記事務, 複製

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 

此時,你應該能夠截斷日誌。

0

我試着列出的所有解決方案,並沒有一次成功。我最終不得不做一個sp_detach_db,然後刪除ldf文件並重新附加數據庫,迫使它創建一個新的ldf文件。這工作。

1

我知道這是一個幾年的歷史,但想補充一些信息。

我發現在非常大的日誌中,特別是當數據庫未設置爲備份事務日誌(日誌非常大)時,日誌的第一次備份不會將log_reuse_wait_desc設置爲無,而是將狀態保留爲備份狀態。這將阻止收縮。第二次運行備份正確地將log_reuse_wait_desc重置爲NOTHING,允許收縮進行處理。

相關問題