一次SQL Server 2000修複實踐

server 我所講的一個故事的背景是這樣的，在某一個POS的項目中使用SQL SERVER 2000做前台資料庫，IBM 的DB2做後台資料庫。前台資料庫的環境是這樣的作業系統是WINDOWS 2000 SERVER(10 USERS),資料庫是SQL SERVER 2000(E)+SP3,Application是POS的收銀系統（是一種即時的交易系統）。硬體的配置是：P4 XRON 2.4G*2,36G HDD*5 做的RAID5 ,1G MEMORY，HP DDS4 磁帶機,資料庫的容量一般保持在5G左右。
　　因為資料比較的重要，並且資料容量也不大，我們要求的備份策略是每天在磁帶機做POS_DB的全備份（一個星期7天一個迴圈），在晚上還在硬碟上做全部備份（MASTER,MSDB,POS_DB).這樣保持雙重的保險。

　　1.故障爆發：

　　2003－12－26 13:00

　　客戶報告所有的POS死機和SERVER運行速度非常的慢。經過重新啟動伺服器（啟動到檢查RAID卡時開始警示）我們發現在WINDEOWS 2000 SERVER的“系統日誌”中有這樣的資訊：

Error: 823, Severity: 24, State: 2
I/O error (torn page) detected during read at offset 0x0000001bf96000 in file D :\DATA\POS_DB.mdf'.
SQLSERVER的“錯誤記錄檔”中有這樣的資訊：
2003-12-10 03:34:22.23 spid56 Error: 823, Severity: 24, State: 2
2003-12-10 03:34:22.23 spid56 I/O error (torn page) detected during read at offset 0x00000074964000 in file 'D:\DATA\POS_DB.mdf'..

　　來自msdn的解釋：

I/O logical check failure: If a read Windows API call or a write Windows API call for a database file is successful, but specific logical checks on the data are not successful (a torn page, for example), an 823 error is raised. The following error message is an example of an 823 error for an I/O logical check failure:
2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..
To resolve this problem, first run the DBCC CHECKDB statement on the database that is associated with the file in the error message. If the DBCC CHECKDB statement reports errors, correct those errors before you troubleshoot this problem. If the problem persists even after the DBCC CHECKDB errors have been corrected, or if the DBCC CHECKDB statement does not report any errors, review the Microsoft Windows NT system event log for any system errors or disk-related errors. You can also contact your hardware vendor to run any appropriate diagnostics.

　　I/O邏輯檢查失敗：如果有一個WINDOWS程式在讀取和寫資料庫檔案時是成功的，但是在詳細的資料邏輯檢查時沒有成功（比如：不完整的頁），SQLSERVER會返回MSG 823的錯誤。下面就是一個I/O邏輯檢查失敗MSG 823的執行個體：

2003-09-05 16:51:18.90 spid17 Error: 823, Severity: 24, State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:\SQLData\mydb.MDF'..

　　要解決這樣的問題，首先要在該資料庫中執行DBCC CHECKDB（錯誤資訊提示的資料庫檔案）。如果DBCC CHECKDB報錯，在你修複錯誤之前糾正這些錯誤。如果這些錯誤資訊一直保留到執行DBCC CHECKDB運行之後，或者DBCC CHECKDB沒有報告任何錯誤，檢查WINDOWS NT系統的的事件檢視器的和系統錯誤或磁碟錯誤相關的資訊。你也可以聯絡硬體廠商運行正確的診斷工具。

　　壞了，資料庫檔案有問題，在檢查OS的事件檢視器，我們發現在一個星期之前就有錯誤資訊（只是OFFSET的位移地址不同）。

　　趕緊檢查HDD,果然發現在RAID5的第一快HDD亮了紅燈（灰塵太多，很難於看清）

　　執行 DBCC CHECKDB('POS_DB')檢查發現：

Server: Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 26342838, index ID 35207, page ID (1:50978). The PageId in the page header =(32230:-2048732002).

Server: Msg 8939, Level 16, State 1, Line 1
Table error: Object ID 859150106, index ID 255, page (1:238770). Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057 and -1.

Server: Msg 8928, Level 16, State 1, Line 1
Object ID 861246123, index ID 0: Page (1:57291) could not be processed. See other errors for details.

Server: Msg 2511, Level 16, State 1, Line 1
Table error: Object ID 862626116, Index ID 0. Keys out of order on page (1:269310), slots 0 and 1.

　　啊哈，果然有很多的表都有錯誤關聯（請記錄每一個錯誤表的OBJECT ID)。

　　從MSDN查到：

　　錯誤號碼Msg 823:表示SQLSERVER在讀取資料和寫資料時檢測到硬體裝置有問題或者系統有問題。

　　TORN PAGE:的意思是不完整的頁

　　0x0000001bf96000：這是從資料檔案開始處到TORN PAGE 的位元組數。

　　錯誤號碼Msg 8939 ：大家可以看看：http://support.microsoft.com/default.aspx?kbid=320434
FIX：在運行 CHECKDB 時，具有 TABLOCK 提示的大容量插入（bulk insert, bcp 等）可能導致錯誤 8929 和 8965。

　　錯誤號碼MSG 8928:是和8939相關聯的資訊，

　　錯誤號碼MSG 8965:是和8939相關聯的資訊，

　　大家可以到下面的地址找到相關的資訊：

http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
PRB: Error message 823 may indicate hardware problems or system problems
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
FIX: CheckDB May Not Fix Error 8909 or Error 8905

　　故障確診：RAID有一塊HDD壞，造成資料庫檔案破壞

　　2.更換HDD

　　2003－12－28 23:00

　　現在就體現了RAID5的好處，壞了一塊HDD，系統可以照常運行，不過系統的日誌和SQLSERVER的日誌還是有MSG823的報錯資訊。

　　按照RAID 卡的REBUILD的步驟將新的HDD綁定到原始的RAID5中，順利完成。

　　用DBCC檢查資料庫的完整性

DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS

　　發現還是有和更換HDD之前一樣的ERROR資訊，看來資料庫檔案還是有問題。

　　--有一個奇怪問題1，既然是5塊HDD的RAID5，為何有一塊HDD壞會影響資料庫檔案的損壞，不解？



　　3.恢複資料庫

　　2003－12－29 00:30

　　沒有辦法，用備份的資料集恢複資料庫（看來備份是多麼的重要）

USE MASTER
GO
RESTORE DATABASE POS_DB FROM DISK='D:\DATABASEBACKUP\POS_DB_BACKUP.DAT'

　　重新啟動MS SQL SERCVER服務。

NET STOP MSSQLSERVER / NET START MSSQLSERVER

　　用DBCC檢查資料庫的完整性

DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS

　　和恢複之前的錯誤資訊一致，沒有改變。

　　--奇怪問題之2，SQLSERVER BACKUP 之前並不驗證資料庫的完整性，資料庫的全備份竟然是有問題的。氣憤！！

　　看來只能通過工具修複資料庫了（--在修改之前記錄錯誤表的記錄數，以便修複資料庫後進行比較）。

　　在查詢分析器中運行：

ALTER DATABASE POS_DB SET SINGL_USER
GO
DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE POS_DB SET MULTI_USER
GO

　　CHECKDB 有3個參數:

REPAIR_ALLOW_DATA_LOSS

　　執行由 REPAIR_REBUILD 完成的所有修複，包括對行和頁進行分配和取消分配以改正分配錯誤、結構行或頁的錯誤，以及刪除已損壞的文字物件。這些修複可能會導致一些資料丟失。修複操作可以在使用者事務下完成以允許使用者復原所做的更改。如果復原修複，則資料庫仍會含有錯誤，應該從備份進行恢複。如果由於所提供修複等級的緣故遺漏某個錯誤的修複，則將遺漏任何取決於該修複的修複。修複完成後，備份資料庫。
　　
　　REPAIR_FAST 進行小的、不耗時的修複操作，如修複非叢集索引中的附加鍵。這些修複可以很快完成，並且不會有遺失資料的危險。

　　REPAIR_REBUILD 執行由 REPAIR_FAST 完成的所有修複，包括需要較長時間的修複（如重建索引）。執行這些修複時不會有遺失資料的危險。

　　第一次運行，我們會發現：

DBCC results for 'TABLE_NAME'.
There are 1 rows in 1 pages for object 'TABLE_NAME'.
The error has been repaired.
CHECKDB found 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).
CHECKDB fixed 0 allocation errors and 1 consistency errors in table '(Object ID 26342838)' (object ID 26342838).

　　這樣的資訊有很多，並且有“The error has been repaired”的提示。不過到最後還是有這樣的資訊：

CHECKDB found 0 allocation errors and 19 consistency errors in database 'POS_DB'.
CHECKDB fixed 0 allocation errors and 19 consistency errors in database 'POS_DB'.

　　再次運行，還是有同樣的錯誤。糟糕:=)看來這種方式是無法修複這樣測錯誤。

　　失敗！！！

　　再仔細看看SQL SERVER BOL發現CHECKDB還有一個非常有用的參數PHYSICAL_ONLY

PHYSICAL_ONLY

　　僅限於檢查頁和記錄標題物理結構的完整性，以及頁物件識別碼 和索引 ID 與分配結構之間的一致性。該檢查旨在以較低的開銷檢查資料庫的物理一致性，同時還檢測會危及使用者資料安全的殘缺頁和常見的硬體故障。PHYSICAL_ONLY 始終意味著 NO_INFOMSGS，並且不能與任何修複選項一起使用。

　　再次運行：

DBCC CHECKDB('POS_DB') with NO_INFOMSGS,PHYSICAL_ONLY
　　
　　然後再運行：

DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK

　　這次會返回一些8952.8956的錯誤資訊:

Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database 'POS_DB', index 'POS_REFER.Idx2_POS_REFER' (ID 861246123) (index ID 2). Extra or invalid key for the keys:

Server: Msg 8956, Level 16, State 1, Line 1
Index row (1:26315:23) with values (PLU_ID = '6922825200240' and PRD_AGGR_ID = 10006 and EVNT_ID = NULL and RGST_MDE = 0 and SUBPRD_NBR = 0 and STR_ID = 12 and PRD_AGGR_ID = 10006 and SUBPRD_NBR = 0 and STR_ID = 12 and PLU_ID = '6922825200240' and EVNT_ID = NULL and RGST_MDE = 0) points to the data row identified by ().

　　根據MSDN上的說明：

This problem does not cause any data or index corruption. The problem is in the metadata which is corrected only by dropping and re-creating the indexes.

　　這些問題不會引起資料或索引的損壞，這些問題的中繼資料是正確的，只是刪除再重建立立索引。

　　看來問題是修改了。

　　再次運行DBCC CHECKDB('POS_DB'),再次運行:DBCC CHECKDB('POS_DB'),message沒有錯誤資訊。

　　成功修複。

　　4.檢查修複後的資料庫並且備份資料庫

　　檢查DBCC CHECKDB報錯的相關表，和沒有執行DBCC之前的記錄數進行比較，發現有一個表少了40條記錄。鬱悶。

　　5.總結

　　1.RAID5並不能保證SQLSERVER 2000 資料庫的資料檔案的完整性；

　　2.SQLERVER 2000的備份程式不驗證資料庫檔案的資料完整性；如果你的資料檔案有問題，備份時也不圖示；

　　3.DBCC CHECKDB的repair_allow_data_loss並不是非常安全的，不能修複所有的錯誤，即使是對不完整頁（TORN PAGE）的修複也會著成資料丟失；

　　4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS參數無法修複所有的錯誤;