MS SQL Server數(shù)據(jù)庫(kù)清理錯(cuò)誤日志的方法
更新時(shí)間:2013年11月08日 09:24:08 作者:
SQL服務(wù)器磁盤空間爆滿導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法訪問(wèn)。遠(yuǎn)程到服務(wù)器上,發(fā)現(xiàn)原來(lái)是SQL錯(cuò)誤日志文件惹的禍,數(shù)據(jù)庫(kù)在1秒內(nèi)產(chǎn)生上100M大小的日志,沒(méi)多長(zhǎng)時(shí)間就將磁盤空間堵滿了,下面說(shuō)說(shuō)解決方案
SQL錯(cuò)誤日志記錄了數(shù)據(jù)庫(kù)運(yùn)行過(guò)程的遇到的各種問(wèn)題及一些重要信息,作為排錯(cuò)需要,我們通常都不會(huì)主動(dòng)去清理這些日志文件,只有每次重啟服務(wù)器時(shí),SQL會(huì)自動(dòng)刪除時(shí)間最老的日志文件,并新生成一個(gè)日志文件。
通過(guò)在服務(wù)器上查看數(shù)據(jù)庫(kù)的日志文件,發(fā)現(xiàn)存在大量的query notification dialog的信息,而且出現(xiàn)的頻率非常的高,導(dǎo)致日志文件增大非???。

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

通過(guò)google了解到這個(gè)錯(cuò)誤跟service broker的消息機(jī)制由關(guān)系,可以通過(guò)使用跟蹤標(biāo)記:DBCC TraceOn(4133,-1)可消除此信息。
不過(guò)現(xiàn)在的當(dāng)務(wù)之急是如何清掉這些日志信息,最簡(jiǎn)單的辦法就是到SQL的日志目錄中刪除這些日志文件即可,不過(guò)考慮到刪除之前需要停止SQL Server服務(wù),可能會(huì)導(dǎo)致緩存中的數(shù)據(jù)丟失,因此,這不是推薦的做法。
那么正確的做法應(yīng)該怎樣呢?
執(zhí)行如下語(yǔ)句:
EXEC sp_cycle_errorlog;
每執(zhí)行一次SQL會(huì)自動(dòng)初始化一個(gè)日志文件,將日志的內(nèi)容清空,當(dāng)SQL有7個(gè)日志文件時(shí)(默認(rèn)),請(qǐng)執(zhí)行7次該操作,每次會(huì)將日志文件時(shí)間最老那個(gè)清空。
讀者不必?fù)?dān)心清空會(huì)消耗很長(zhǎng)的時(shí)間,我這邊的有個(gè)日志有40G,命令執(zhí)行完后,該文件立即清空了。在時(shí)間緊急的情況,這種方式尤為方便。
那么有沒(méi)有辦法設(shè)置每個(gè)日志文件的固定大小呢?
查過(guò)這方面的資料,有人說(shuō)可以在注冊(cè)表中設(shè)置ErrorLogSizeInKb的大小,不過(guò)僅限于SQL2012,其他版本的數(shù)據(jù)庫(kù)設(shè)置后不生效,這個(gè)我沒(méi)有驗(yàn)證過(guò),有興趣的朋友可以一起討論下。
數(shù)據(jù)庫(kù)無(wú)日志報(bào)錯(cuò)恢復(fù)
造成原因,客戶的SqlServer為2000版本,由于日志過(guò)大無(wú)人管理,沒(méi)有空間了,然后客戶分離數(shù)據(jù)庫(kù)想刪除日志(據(jù)說(shuō)200G的日志=.=),然后顯示分離出錯(cuò),但是刷新后數(shù)據(jù)庫(kù)卻已經(jīng)分離,刪除日志后,數(shù)據(jù)庫(kù)無(wú)法附加,經(jīng)過(guò)在網(wǎng)上查詢,總結(jié)出以下辦法,幸好有用的表都沒(méi)有損壞,只有統(tǒng)計(jì)表數(shù)據(jù)損壞,不過(guò)沒(méi)關(guān)系反正作業(yè)會(huì)重置這些表的.
--確保企業(yè)管理器沒(méi)有打開(kāi)任何數(shù)據(jù)庫(kù)
--設(shè)置數(shù)據(jù)庫(kù)緊急狀態(tài)
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--設(shè)置數(shù)據(jù)庫(kù)為緊急模式
update sysdatabases set status=-32768 where dbid=DB_ID('Procurement')
--重建數(shù)據(jù)庫(kù)日志文件
dbcc rebuild_log('Procurement','D:\Procurement_log.ldf')
--驗(yàn)證數(shù)據(jù)庫(kù)一致性(可省略)
dbcc checkdb('Procurement')
--設(shè)置數(shù)據(jù)庫(kù)為正常狀態(tài)
sp_dboption 'Procurement','dbo use only','false'
--最后一步,我們要將步驟E中設(shè)置的“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)恢復(fù)
sp_configure 'allow updates',0
go
reconfigure with override
go
現(xiàn)在你的數(shù)據(jù)庫(kù)就允許連接了,現(xiàn)在可以查看一下每個(gè)表的數(shù)據(jù)是否有問(wèn)題,如果有問(wèn)題,只能找專業(yè)的數(shù)據(jù)回復(fù)了。
相關(guān)文章
全國(guó)省市區(qū)縣最全最新數(shù)據(jù)表(數(shù)據(jù)來(lái)源谷歌)
因?yàn)楣ぷ黜?xiàng)目需求,需要一個(gè)城市縣區(qū)數(shù)據(jù)表,上網(wǎng)搜了下,基本都不全,所以花了3天時(shí)間整理了一遍.2010-04-04
SQLServer 獲得用戶最新或前n條訂單的幾種SQL語(yǔ)句小結(jié)
場(chǎng)景:有一張用戶表,一個(gè)訂單表,要求獲得一個(gè)用戶對(duì)應(yīng)的最新的一條訂單信息。2011-08-08
sqlserver 錯(cuò)誤602,未能在sysindexes中找到數(shù)據(jù)庫(kù) 的解決辦法
這是因?yàn)楦郊拥牡臄?shù)據(jù)庫(kù)是Sql2005格式,而使用的是Sql2000附加造成的2010-05-05
SQL Server 數(shù)據(jù)庫(kù)分離與附加(圖文教程)
SQL Server 數(shù)據(jù)庫(kù)分離與附加(圖文教程),需要的朋友可以參考一下2013-05-05
SqlServer強(qiáng)制斷開(kāi)數(shù)據(jù)庫(kù)已有連接的方法
在執(zhí)行建庫(kù)腳本時(shí),往往會(huì)先將原有的數(shù)據(jù)庫(kù)drop掉,由于SqlServer檢測(cè)到有數(shù)據(jù)連接時(shí)禁止執(zhí)行drop database操作,所以建庫(kù)腳本經(jīng)常執(zhí)行失敗,為此我們需要一種能強(qiáng)制斷開(kāi)數(shù)據(jù)庫(kù)已有連接的方法,需要的朋友可以參考下2012-12-12
關(guān)于Select Where In 的排序問(wèn)題
有很多人不知道SQL里怎么按 Select Where In 的內(nèi)容進(jìn)行字段排序.假如SQL語(yǔ)句為:2008-03-03

