前天接到同事電話：SQL服務(wù)器磁盤空間爆滿導(dǎo)致數(shù)據(jù)庫無法訪問。遠程到服務(wù)器上，發(fā)現(xiàn)原來是SQL錯誤日志文件惹的禍，數(shù)據(jù)庫在1秒內(nèi)產(chǎn)生上100M大小的日志，沒多長時間就將磁盤空間堵滿了。
SQL錯誤日志記錄了數(shù)據(jù)庫運行過程的遇到的各種問題及一些重要信息，作為排錯需要，我們通常都不會主動去清理這些日志文件，只有每次重啟服務(wù)器時，SQL會自動刪除時間最老的日志文件，并新生成一個日志文件。
通過在服務(wù)器上查看數(shù)據(jù)庫的日志文件，發(fā)現(xiàn)存在大量的query notification dialog的信息，而且出現(xiàn)的頻率非常的高，導(dǎo)致日志文件增大非常快。
通過google了解到這個錯誤跟service broker的消息機制由關(guān)系，可以通過使用跟蹤標記：DBCC TraceOn(4133,-1)可消除此信息。
不過現(xiàn)在的當務(wù)之急是如何清掉這些日志信息，最簡單的辦法就是到SQL的日志目錄中刪除這些日志文件即可，不過考慮到刪除之前需要停止SQL Server服務(wù)，可能會導(dǎo)致緩存中的數(shù)據(jù)丟失，因此，這不是推薦的做法。
那么正確的做法應(yīng)該怎樣呢？
執(zhí)行如下語句：
EXEC sp_cycle_errorlog;
每執(zhí)行一次SQL會自動初始化一個日志文件，將日志的內(nèi)容清空，當SQL有7個日志文件時（默認），請執(zhí)行7次該操作，每次會將日志文件時間最老那個清空。
讀者不必擔心清空會消耗很長的時間，我這邊的有個日志有40G，命令執(zhí)行完后，該文件立即清空了。在時間緊急的情況，這種方式尤為方便。
那么有沒有辦法設(shè)置每個日志文件的固定大小呢？
查過這方面的資料，有人說可以在注冊表中設(shè)置ErrorLogSizeInKb的大小，不過僅限于SQL2012，其他版本的數(shù)據(jù)庫設(shè)置后不生效，這個我沒有驗證過，有興趣的朋友可以一起討論下。
數(shù)據(jù)庫無日志報錯恢復(fù)
造成原因,客戶的SqlServer為2000版本,由于日志過大無人管理,沒有空間了,然后客戶分離數(shù)據(jù)庫想刪除日志(據(jù)說200G的日志=.=),然后顯示分離出錯,但是刷新后數(shù)據(jù)庫卻已經(jīng)分離,刪除日志后,數(shù)據(jù)庫無法附加,經(jīng)過在網(wǎng)上查詢,總結(jié)出以下辦法,幸好有用的表都沒有損壞,只有統(tǒng)計表數(shù)據(jù)損壞,不過沒關(guān)系反正作業(yè)會重置這些表的.
--確保企業(yè)管理器沒有打開任何數(shù)據(jù)庫
--設(shè)置數(shù)據(jù)庫緊急狀態(tài)
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--設(shè)置數(shù)據(jù)庫為緊急模式
update sysdatabases set status=-32768 where dbid=DB_ID('Procurement')
--重建數(shù)據(jù)庫日志文件
dbcc rebuild_log('Procurement','D:\Procurement_log.ldf')
--驗證數(shù)據(jù)庫一致性（可省略）
dbcc checkdb('Procurement')
--設(shè)置數(shù)據(jù)庫為正常狀態(tài)
sp_dboption 'Procurement','dbo use only','false'
--最后一步，我們要將步驟E中設(shè)置的“允許對系統(tǒng)目錄直接修改”一項恢復(fù)
sp_configure 'allow updates',0
go
reconfigure with override
go
現(xiàn)在你的數(shù)據(jù)庫就允許連接了,現(xiàn)在可以查看一下每個表的數(shù)據(jù)是否有問題,如果有問題,只能找專業(yè)的數(shù)據(jù)回復(fù)了.
喜歡 
頂
難過
囧
圍觀
無聊
