之前在UAT環(huán)境搭建的SQL SERVER 2008 R2數(shù)據(jù)庫一直用得比較正常，但最近發(fā)現(xiàn)在Sharepoint中不能進(jìn)行任何操作了，開始以為是什么配置出了問題（因?yàn)橐恢痹谘芯恳恍┬碌膽?yīng)用和集成，需要不斷地測試），但后來發(fā)現(xiàn)是數(shù)據(jù)庫硬盤沒用一點(diǎn)空間了，那么自然是不能存任何數(shù)據(jù)了，所以最先開始清理一些無用的數(shù)據(jù)庫日志，磁盤空間多了幾個(gè)G的容量，但是等到第二天情況依然如此，數(shù)據(jù)庫硬盤還是滿了，問題依舊存在，后臺仔細(xì)檢查了一下所有數(shù)據(jù)庫的容量（因?yàn)樽畛跻詾槭菙?shù)據(jù)庫空間每天增長太快了把硬盤占滿了），發(fā)現(xiàn)才十幾個(gè)G的，而硬盤總空間有126G，因此進(jìn)一步檢查了這個(gè)磁盤空間，發(fā)現(xiàn)才三十多個(gè)G，一開始感覺很納悶，為什么會缺少將近90G呢？后來發(fā)現(xiàn)是原來windows賬號的關(guān)系，之前用的登錄賬號權(quán)限有限，無法獲取磁盤的所有空間容量，因此換了管理員的賬號登錄后，發(fā)現(xiàn)原來是SQL SERVER有一個(gè)錯(cuò)誤日志的容量將近90G，總算找到磁盤滿的原因了，下一步就是如何去解決它。

一開始聽了同事的建議，直接通過文件剪貼的方式把這個(gè)SQL SERVER 錯(cuò)誤日志文件直接移動到另外一個(gè)硬盤上，折騰了好幾個(gè)小時(shí)最終以失敗告終，說明錯(cuò)誤日志被系統(tǒng)進(jìn)程占用著，并不能通過這個(gè)暴力方式進(jìn)行，因此走回正軌，通過SQL SERVER維護(hù)命令進(jìn)行操作，最終成功清除了90G的錯(cuò)誤日志文件，具體過程如下：

由于默認(rèn)情況下，SQL Server 保存 7 個(gè) ErrorLog 文件，名為：

ErrorLog

ErrorLog.1

ErrorLog.2

ErrorLog.3

ErrorLog.4

ErrorLog.5

ErrorLog.6

--清除 SQL Server 錯(cuò)誤日志文件 存檔

EXEC sp_cycle_errorlog
GO

執(zhí)行一次EXEC sp_cycle_errorlog就會產(chǎn)生一個(gè)新的errorlog，然后把errorlog.6給刪掉。就是先進(jìn)先出（隊(duì)列類似的情況）這樣循環(huán)6次就可以把errorlog都刷新一遍。

 當(dāng)查詢窗口中，出現(xiàn)以下錯(cuò)誤信息時(shí)：

消息 17049，級別 16，狀態(tài) 1，過程 sp_cycle_errorlog，第 9 行
 由于出現(xiàn)操作系統(tǒng)錯(cuò)誤 '5(拒絕訪問。)'，無法將錯(cuò)誤日志文件從 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG.5' 循環(huán)到 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG.6'。SQL Server 外部的進(jìn)程可能會阻止 SQL Server 讀取這些文件。因此，錯(cuò)誤日志條目可能已丟失，并且或許不可能查看某些 SQL Server 錯(cuò)誤日志。請確保任何其他進(jìn)程都未將該文件鎖定為只寫訪問。"
DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請與系統(tǒng)管理員聯(lián)系。

手工刪除那個(gè)90G的錯(cuò)誤日志文件即可。       

通過本次的經(jīng)歷，適當(dāng)掌握一些SQL SERVER維護(hù)命令在實(shí)際工作上也非常有必要的，而且相對于ORACEL數(shù)據(jù)庫，SQL SERVER的維護(hù)要相對簡單一些。