SQL錯誤日志記錄了數據庫運行過程的遇到的各種問題及一些重要信息，作為排錯需要，我們通常都不會主動去清理這些日志文件，只有每次重啟服務器時，SQL會自動刪除時間最老的日志文件，并新生成一個日志文件。
通過在服務器上查看數據庫的日志文件，發(fā)現存在大量的query notification dialog的信息，而且出現的頻率非常的高，導致日志文件增大非?？?。

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

最新評論