前幾天，在備份某一臺服務(wù)器上的某一個庫的時候遇到問題，數(shù)據(jù)庫80G+，在完整備份的時候，SQLSERVER報錯

消息 3271，級別 16，狀態(tài) 1，第 49 行在文件 "E:/DataBase/xxxxxx/FG_xxxxx_ClassId_05_data.ndf" 上發(fā)生不可恢復(fù)的 I/O 錯誤: 2(系統(tǒng)找不到指定的文件。)。消息 3013，級別 16，狀態(tài) 1，第 49 行BACKUP DATABASE 正在異常終止。

服務(wù)器上掛有20+個數(shù)據(jù)庫，所有數(shù)據(jù)庫都能完整備份，唯獨這個庫有問題，數(shù)據(jù)庫名稱：9115

這里有問題會有兩種可能：

1、數(shù)據(jù)庫由于某些原因損壞

2、磁盤有問題導(dǎo)致數(shù)據(jù)庫損壞

在某個晚上我對數(shù)據(jù)庫進行了checkdb的修復(fù)，修復(fù)時間大概3個多小時

何總說可以先重啟服務(wù)器，因為他曾經(jīng)試過重啟服務(wù)器，數(shù)據(jù)庫的損壞問題又正常了

但是我不敢貿(mào)然重啟服務(wù)器，怕重啟了起不來

大家可能覺得checkdb了，修復(fù)了就可以正常備份，備份完了就完事了，能不能正常備份我還不清楚，因為磁盤空間不太夠

但是作為DBA最起碼要追查一下原因

有三個疑問需要追查：

（1）從什么時候開始這個數(shù)據(jù)庫就已經(jīng)損壞了？？？

（2）其他庫有沒有出現(xiàn)同樣的錯誤（發(fā)生不可恢復(fù)的 I/O 錯誤: 2(系統(tǒng)找不到指定的文件）？？？

（3）這個庫是不是從別的服務(wù)器那里搬過來的，如果是，是搬過來之前就有損壞，還是搬過來之后才損壞？？？

追查就要依靠SQLSERVER ERRORLOG

說了這麼久，好像跟效率不沾邊？？？

效率問題

首先我們管理著上千個數(shù)據(jù)庫，每天的工作，從上班忙到下班，下班忙到睡覺，系統(tǒng)如此之多

怎麼才能快速查找出這兩個疑問的答案呢？

難題：SQLSERVER ERRORLOG日志文件很大，直接用SQLSERVER自帶的日志查看器來加載會報“out of memory”或“出現(xiàn)多個錯誤”或“SSMS直接崩潰”

用UE？？更不用想了，直接崩潰

步驟1：雖然在服務(wù)器上直接查看也可以，但是我擔(dān)心的是

1、會影響服務(wù)器性能

2、如果重啟SQL或機器，最老的日志就沒有了

先壓縮這幾個errorlog，然后拷貝到本地，其實拷貝到本地作為一個備份的作用，而且想怎麼查就怎麼查

步驟2：怎麼才能查看這麼大的日志文件？在本機安裝一個SQLSERVER，然后替換

安裝路徑/Microsoft SQL Server/MSSQL.1/MSSQL/LOG下面的日志文件

替換的時候要注意，不用每個都替換，只需要替換第5和第6個日志文件，因為這兩個文件都上GB級別

步驟3：替換了之后，打開SSMS，我們需要查找第6個文件里有“系統(tǒng)找不到指定的文件”字眼的

日志記錄，確定時間，第6個文件的修改時間是2012-11-3，我們就從2012-1-1開始查找

如果2012-1-1之前還有記錄，我們就再修改一下時間，而結(jié)束時間我們就選擇2015-10-10

保證可以覆蓋到整個日志文件

輸入下面的SQL語句

EXEC xp_readerrorlog 6,1,'9115','系統(tǒng)找不到指定的文件','2012-01-01','2015-10-10','DESC'

查找到?jīng)]有記錄，用了9分鐘時間

步驟4：繼續(xù)查找第6個日志文件，看一下9115這個庫是從什么時候開始存在在這個服務(wù)器上的

使用下面的SQL語句

EXEC xp_readerrorlog 6,1,'9115',NULL,'2011-05-09','2015-10-10','DESC'

可以看到在2012-06-11 的時候這個庫就已經(jīng)存在在這臺服務(wù)器上

步驟5：繼續(xù)查找第5個日志文件

查到了，用了42秒，查到5行記錄，最早出現(xiàn)問題是在2013-11-18 00:35:48

A read of the file 'E:/DataBase/xxxx/FG_xxxxx_ClassId_05_data.ndf' at offset 0x00000009668000 succeeded after failing 1 time(s) with error: 2(系統(tǒng)找不到指定的文件。). Additional messages in the SQL Server error log and system event log may PRovide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

問題一和問題三解開了

（1）從什么時候開始這個數(shù)據(jù)庫就已經(jīng)損壞了？？？

最早出現(xiàn)（系統(tǒng)找不到指定的文件）問題是在2013-11-18 00:35:48

（3）這個庫是不是從別的服務(wù)器那里搬過來的，如果是，是搬過來之前就有損壞，還是搬過來之后才損壞？？？

是不是搬過來不清楚，不過可以肯定的是，這個庫在這臺服務(wù)器上跑了一段時間才出現(xiàn)這個問題的，可以說明剛開始的時候數(shù)據(jù)庫是沒有問題的

步驟6：繼續(xù)第二個問題

使用下面SQL語句來查看第5和第6個日志文件，排查其他庫有沒有出現(xiàn)同樣的錯誤

EXEC xp_readerrorlog 6,1,NULL,'系統(tǒng)找不到指定的文件','2011-12-12','2015-10-10','DESC'EXEC xp_readerrorlog 5,1,NULL,'系統(tǒng)找不到指定的文件','2011-12-12','2015-10-10','DESC'

第6個日志文件沒有任何記錄

第5個日志文件都是9115這個數(shù)據(jù)庫的，而9457這個數(shù)據(jù)庫應(yīng)該是還原的時候找不到bak文件

步驟7：這個時候大家一定會想繼續(xù)使用SQL語句來繼續(xù)查找錯誤

但是，因為第一個日志文件是不能替換的，就算停掉SQL，開啟SQL之后又會重新生成，大家可能會替換來替換去，改文件名

雖然改文件名使用SQL語句這些方法也可以，但是這篇文章強調(diào)的兩個字是“效率”

觀察一下各個日志文件的大小，ERRORLOG.4才21MB

我們完全可以用SQLSERVER自帶的日志查看器來查看

為什麼用SQLSERVER自帶的日志查看器而不用UE等文本編輯工具，因為SQLSERVER自帶的日志查看器的篩選功能比UE好很多

而且篩選出來的結(jié)果很直觀，很好用，效率也不相差多少

1、改名

2、在消息包含文本框里輸入“系統(tǒng)找不到指定的文件”

第4個日志文件一條記錄都沒有

同樣，在第3、2、1個日志文件也是一條記錄都沒有

注意：

只要應(yīng)用了“篩選器”之后，你在加載下一個ERRORLOG文件的時候，日志查看器就會自動幫你篩選出符合要求的記錄

而不會顯示全部記錄！！

在ERRORLOG里面找到39條符合要求的記錄，全部都是9115這個庫的

第二個問題解開了，只有9115這個庫出現(xiàn) （發(fā)生不可恢復(fù)的 I/O 錯誤: 2(系統(tǒng)找不到指定的文件）的錯誤

總結(jié)

每天的工作中，我會把每天做的工作記錄下來，也會遇到同樣的問題可以快速找到解決辦法

在工作量這么多的情況下，如何減輕自己的工作量，不停反思才能提高工作效率~

一個小小的總結(jié)的，希望大家多多支持o(∩_∩)o

參考文章：

聽風(fēng)吹雨

SQL Server 錯誤日志過濾（ERRORLOG）

如有不對的地方，歡迎大家拍磚o(∩_∩)o

2014-5-11補充

昨晚成功完整備份了數(shù)據(jù)庫9115，保證了數(shù)據(jù)安全，可能還有一些數(shù)據(jù)頁損壞，不過成功備份了數(shù)據(jù)庫就可以進行下一步的工作：檢查硬盤