由 于數(shù)據(jù)庫(kù)日志增長(zhǎng)被設(shè)置為“無(wú)限制”,所以時(shí)間一長(zhǎng)日志文件必然會(huì)很大,一個(gè)400G的數(shù)據(jù)庫(kù)居然有600G的LOG文件,嚴(yán)重占用了磁盤空間。由于主要 是做OLAP,所以數(shù)據(jù)庫(kù)本身不會(huì)有大變動(dòng),所以日志也就沒有多少作用了,因此想辦法把數(shù)據(jù)庫(kù)日志文件收縮到很小或者刪除。
網(wǎng) 上搜索相關(guān)解決方案后,得到的答案豐富多彩,但是真正管用的方案并不多,這里分享一個(gè)csdn上找到的方法。這個(gè)方法講述了SQL Server 2005和SQL Server 2008在收縮數(shù)據(jù)庫(kù)日志的不同之處,頗有幫助。同時(shí),該方法的效率很高,收縮600G的日志到10M只花了不到30秒。
最后附上代碼:
適用于SQL Server 2000的方法
DUMP TRANSACTION [jb51] WITH NO_LOG BACKUP LOG [jb51] WITH NO_LOG DBCC SHRINKDATABASE([jb51])
其中jb51為數(shù)據(jù)庫(kù)名
適用于SQL Server 2005的方法
Backup Log [jb51] WITH no_log GO DUMP TRANSACTION [jb51] WITH no_log GO USE jb51 DBCC SHRINKFILE (2) GO
說明:由于SQL Server 2008對(duì)文件和日志管理進(jìn)行了優(yōu)化,所以以上語(yǔ)句在SQL2005中可以運(yùn)行但在SQL2008中已經(jīng)被取消。
USE[master] GO ALTER DATABASE jb51 SET RECOVERY SIMPLE WITH NO_WAIT GO ALTER DATABASE jb51 SET RECOVERY SIMPLE --簡(jiǎn)單模式 GO USE jb51 GO DBCC SHRINKFILE (N'DNName_Log', 11, TRUNCATEONLY) GO USE[master] GO ALTER DATABASE jb51 SET RECOVERY FULL WITH NO_WAIT GO ALTER DATABASE jb51 SET RECOVERY FULL --還原為完全模式 GO
其中jb51為數(shù)據(jù)庫(kù)名,DNName_Log為日志名,需要找一下,具體的說明可以參考這篇文章,也有圖文方法 https://www.jb51.net/article/136523.htm
這篇文章就介紹到這了,需要的朋友可以參考一下,希望大家以后多多支持腳本之家。
標(biāo)簽:七臺(tái)河 益陽(yáng) 威海 宿州 來(lái)賓 天水 銅仁 防疫戰(zhàn)設(shè)
巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《SQL Server 2000/2005/2008刪除或壓縮數(shù)據(jù)庫(kù)日志的方法》,本文關(guān)鍵詞 SQL,Server,2000,2005,2008,刪除,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。