從分析SQLSERVER ERRORLOG查找錯誤折射出的工作效率問題
前幾天，在備份某一台伺服器上的某一個庫的時候遇到問題，資料庫80G+，在完整備份的時候，SQLSERVER報錯
消息 3271，級别 16，狀态 1，第 49 行
在檔案 "E:\DataBase\xxxxxx\FG_xxxxx_ClassId_05_data.ndf" 上發生不可恢複的 I/O 錯誤: 2(系統找不到指定的檔案。)。
消息 3013，級别 16，狀态 1，第 49 行
BACKUP DATABASE 正在異常終止。 伺服器上挂有20+個資料庫，所有資料庫都能完整備份，唯獨這個庫有問題，資料庫名稱：9115
這裡有問題會有兩種可能：
1、資料庫由于某些原因損壞
2、磁盤有問題導緻資料庫損壞
在某個晚上我對資料庫進行了checkdb的修複，修複時間大概3個多小時
何總說可以先重新開機伺服器，因為他曾經試過重新開機伺服器，資料庫的損壞問題又正常了
但是我不敢貿然重新開機伺服器，怕重新開機了起不來
大家可能覺得checkdb了，修複了就可以正常備份，備份完了就完事了，能不能正常備份我還不清楚，因為磁盤空間不太夠
但是作為DBA最起碼要追查一下原因
有三個疑問需要追查：
（1）從什麼時候開始這個資料庫就已經損壞了？？？
（2）其他庫有沒有出現同樣的錯誤（發生不可恢複的 I/O 錯誤: 2(系統找不到指定的檔案）？？？
（3）這個庫是不是從别的伺服器那裡搬過來的，如果是，是搬過來之前就有損壞，還是搬過來之後才損壞？？？
追查就要依靠SQLSERVER ERRORLOG
說了這麽久，好像跟效率不沾邊？？？
效率問題
首先我們管理着上千個資料庫，每天的工作，從上班忙到下班，下班忙到睡覺，系統如此之多
怎麽才能快速查找出這兩個疑問的答案呢？
難題：SQLSERVER ERRORLOG日志檔案很大，直接用SQLSERVER自帶的日志檢視器來加載會報“out of memory”或“出現多個錯誤”或“SSMS直接崩潰”
用UE？？更不用想了，直接崩潰
步驟1：雖然在伺服器上直接檢視也可以，但是我擔心的是
1、會影響伺服器性能
2、如果重新開機SQL或機器，最老的日志就沒有了
先壓縮這幾個errorlog，然後拷貝到本地，其實拷貝到本地作為一個備份的作用，而且想怎麽查就怎麽查
步驟2：怎麽才能檢視這麽大的日志檔案？在本機安裝一個SQLSERVER，然後替換
安裝路徑\Microsoft SQL Server\MSSQL.1\MSSQL\LOG下面的日志檔案
替換的時候要注意，不用每個都替換，隻需要替換第5和第6個日志檔案，因為這兩個檔案都上GB級别
步驟3：替換了之後，打開SSMS，我們需要查找第6個檔案裡有“系統找不到指定的檔案”字眼的
日志記錄，确定時間，第6個檔案的修改時間是2012-11-3，我們就從2012-1-1開始查找
如果2012-1-1之前還有記錄，我們就再修改一下時間，而結束時間我們就選擇2015-10-10
保證可以覆寫到整個日志檔案
輸入下面的SQL語句
EXEC xp_readerrorlog 0,1,'9115','系統找不到指定的檔案','2016-01-01','2018-10-10','DESC' 查找到沒有記錄，用了9分鐘時間
步驟4：繼續查找第6個日志檔案，看一下9115這個庫是從什麼時候開始存在在這個伺服器上的
使用下面的SQL語句
EXEC xp_readerrorlog 6,1,'9115',NULL,'2011-05-09','2018-10-10','DESC' 可以看到在2012-06-11 的時候這個庫就已經存在在這台伺服器上
步驟5：繼續查找第5個日志檔案
查到了，用了42秒，查到5行記錄，最早出現問題是在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(系統找不到指定的檔案。). 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. 問題一和問題三解開了
最早出現（系統找不到指定的檔案）問題是在2013-11-18 00:35:48
是不是搬過來不清楚，不過可以肯定的是，這個庫在這台伺服器上跑了一段時間才出現這個問題的，可以說明剛開始的時候資料庫是沒有問題的
步驟6：繼續第二個問題
使用下面SQL語句來檢視第5和第6個日志檔案，排查其他庫有沒有出現同樣的錯誤
EXEC xp_readerrorlog 6,1,NULL,'系統找不到指定的檔案','2011-12-12','2018-10-10','DESC'
EXEC xp_readerrorlog 5,1,NULL,'系統找不到指定的檔案','2011-12-12','2018-10-10','DESC' 第6個日志檔案沒有任何記錄
第5個日志檔案都是9115這個資料庫的，而9457這個資料庫應該是還原的時候找不到bak檔案
步驟7：這個時候大家一定會想繼續使用SQL語句來繼續查找錯誤
但是，因為第一個日志檔案是不能替換的，就算停掉SQL，開啟SQL之後又會重新生成，大家可能會替換來替換去，改檔案名
雖然改檔案名使用SQL語句這些方法也可以，但是這篇文章強調的兩個字是“效率”
觀察一下各個日志檔案的大小，ERRORLOG.4才21MB
我們完全可以用SQLSERVER自帶的日志檢視器來檢視
為什麽用SQLSERVER自帶的日志檢視器而不用UE等文本編輯工具，因為SQLSERVER自帶的日志檢視器的篩選功能比UE好很多
而且篩選出來的結果很直覺，很好用，效率也不相差多少
1、改名
2、在消息包含文本框裡輸入“系統找不到指定的檔案”
第4個日志檔案一條記錄都沒有
同樣，在第3、2、1個日志檔案也是一條記錄都沒有
注意：
隻要應用了“篩選器”之後，你在加載下一個ERRORLOG檔案的時候，日志檢視器就會自動幫你篩選出符合要求的記錄
而不會顯示全部記錄！！
在ERRORLOG裡面找到39條符合要求的記錄，全部都是9115這個庫的
第二個問題解開了，隻有9115這個庫出現 （發生不可恢複的 I/O 錯誤: 2(系統找不到指定的檔案） 的錯誤
總結
每天的工作中，我會把每天做的工作記錄下來，也會遇到同樣的問題可以快速找到解決辦法
在工作量這麼多的情況下，如何減輕自己的工作量，不停反思才能提高工作效率~
一個小小的總結的，希望大家多多支援o(∩_∩)o
參考文章：
聽風吹雨
SQL Server 錯誤日志過濾（ERRORLOG）
如有不對的地方，歡迎大家拍磚o(∩_∩)o
2014-5-11補充
昨晚成功完整備份了資料庫9115，保證了資料安全，可能還有一些資料頁損壞，不過成功備份了資料庫就可以進行下一步的工作：檢查硬碟
檢查死鎖
dbcc traceon(1204,1222,-1)
dbcc tracestatus(1204,1222,-1)
1204
傳回參與死鎖的鎖的資源和類型，以及受影響的目前指令。
1222
以不符合任何 XSD 架構的 XML 格式，傳回參與死鎖的鎖的資源和類型，以及受影響的目前指令。--作用域：僅全局