我所講的一個(gè)故事的背景是這樣的，在某一個(gè)POS的項(xiàng)目中使用SQLSERVER 2000做前臺(tái)數(shù)據(jù)庫，IBM 的DB2做后臺(tái)數(shù)據(jù)庫。前臺(tái)數(shù)據(jù)庫的環(huán)境是這樣的操作系統(tǒng)是WINDOWS2000 SERVER(10 USERS),數(shù)據(jù)庫是SQLSERVER2000(E)+SP3,Application是POS的收銀系統(tǒng)（是一種實(shí)時(shí)的交易系統(tǒng)）。硬件的配置是：P4 XRON 2.4G*2,36G HDD*5 做的RAID5 ,1G MEMORY，HP DDS4 磁帶機(jī),數(shù)據(jù)庫的容量一般保持在5G左右。
因?yàn)閿?shù)據(jù)比較的重要，并且數(shù)據(jù)容量也不大，我們要求的備份策略是每天在磁帶機(jī)做POS_DB的全備份（一個(gè)星期7天一個(gè)循環(huán)），在晚上還在硬盤上做全部備份（MASTER,MSDB,POS_DB).這樣保持雙重的保險(xiǎn)。
1.故障爆發(fā)：
2003－12－26 13:00
客戶報(bào)告所有的POS死機(jī)和SERVER運(yùn)行速度非常的慢。經(jīng)過重新啟動(dòng)服務(wù)器（啟動(dòng)到檢查RAID卡時(shí)開始報(bào)警）我們發(fā)現(xiàn)在WINDEOWS 2000 SERVER的“系統(tǒng)日志”中有這樣的信息：
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的“錯(cuò)誤日志”中有這樣的信息：
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邏輯檢查失敗：如果有一個(gè)WINDOWS程序在讀取和寫數(shù)據(jù)庫文件時(shí)是成功的，但是在詳細(xì)的數(shù)據(jù)邏輯檢查時(shí)沒有成功（比如：不完整的頁），SQLSERVER會(huì)返回MSG 823的錯(cuò)誤。下面就是一個(gè)I/O邏輯檢查失敗MSG 823的實(shí)例：
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'..
要解決這樣的問題，首先要在該數(shù)據(jù)庫中執(zhí)行DBCC CHECKDB（錯(cuò)誤信息提示的數(shù)據(jù)庫文件）。如果DBCC CHECKDB報(bào)錯(cuò)，在你修復(fù)錯(cuò)誤之前糾正這些錯(cuò)誤。如果這些錯(cuò)誤信息一直保留到執(zhí)行DBCC CHECKDB運(yùn)行之后，或者DBCC CHECKDB沒有報(bào)告任何錯(cuò)誤，檢查WINDOWS NT系統(tǒng)的的事件查看器的和系統(tǒng)錯(cuò)誤或磁盤錯(cuò)誤相關(guān)的信息。你也可以聯(lián)系硬件廠商運(yùn)行正確的診斷工具。
壞了:-(，數(shù)據(jù)庫文件有問題，在檢查OS的事件查看器，我們發(fā)現(xiàn)在一個(gè)星期之前就有錯(cuò)誤信息（只是OFFSET的偏移地址不同）。
趕緊檢查HDD,果然發(fā)現(xiàn)在RAID5的第一快HDD亮了紅燈（灰塵太多，很難于看清）
執(zhí)行 DBCC CHECKDB('POS_DB')檢查發(fā)現(xiàn)：
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.
啊哈，果然有很多的表都有錯(cuò)誤關(guān)聯(lián)（請記錄每一個(gè)錯(cuò)誤表的OBJECT ID)
從MSDN查到：
錯(cuò)誤號(hào)Msg 823:表示SQLSERVER在讀取數(shù)據(jù)和寫數(shù)據(jù)時(shí)檢測到硬件設(shè)備有問題或者系統(tǒng)有問題。
TORN PAGE:的意思是不完整的頁
0x0000001bf96000：這是從數(shù)據(jù)文件開始處到TORN PAGE 的字節(jié)數(shù)。
錯(cuò)誤號(hào)Msg 8939 ：大家可以看看：
http://support.microsoft.com/default.aspx?kbid=320434FIX：在運(yùn)行 CHECKDB 時(shí)，具有 TABLOCK 提示的大容量插入（bulk insert, bcp 等）可能導(dǎo)致錯(cuò)誤 8929 和 8965
錯(cuò)誤號(hào)MSG 8928:是和8939相關(guān)聯(lián)的信息，
錯(cuò)誤號(hào)MSG 8965:是和8939相關(guān)聯(lián)的信息，
大家可以到下面的地址找到相關(guān)的信息：
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壞，造成數(shù)據(jù)庫文件破壞
2.更換HDD
2003－12－28 23:00
現(xiàn)在就體現(xiàn)了RAID5的好處，壞了一塊HDD，系統(tǒng)可以照常運(yùn)行，不過系統(tǒng)的日志和SQLSERVER的日志還是有MSG823的報(bào)錯(cuò)信息。
按照RAID 卡的REBUILD的步驟將新的HDD綁定到原始的RAID5中，順利完成:-)
用DBCC檢查數(shù)據(jù)庫的完整性
DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS
發(fā)現(xiàn)還是有和更換HDD之前一樣的ERROR信息，看來數(shù)據(jù)庫文件還是有問題。
--有一個(gè)奇怪問題1，既然是5塊HDD的RAID5，為何有一塊HDD壞會(huì)影響數(shù)據(jù)庫文件的損壞，不解？？？:-(
3.恢復(fù)數(shù)據(jù)庫
2003－12－29 00:30
沒有辦法，用備份的數(shù)據(jù)集恢復(fù)數(shù)據(jù)庫（看來備份是多么的重要）
USE MASTER
GO
RESTORE DATABASE POS_DB FROM DISK='D:\DATABASEBACKUP\POS_DB_BACKUP.DAT'
重新啟動(dòng)MSSQLSERCVER服務(wù)，
NET STOP MSSQLSERVER / NET START MSSQLSERVER
用DBCC檢查數(shù)據(jù)庫的完整性
DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS
和恢復(fù)之前的錯(cuò)誤信息一致，沒有改變。
--奇怪問題之2，SQLSERVER BACKUP 之前并不驗(yàn)證數(shù)據(jù)庫的完整性，數(shù)據(jù)庫的全備份竟然是有問題的。氣憤！！
看來只能通過工具修復(fù)數(shù)據(jù)庫了（--在修改之前記錄錯(cuò)誤表的記錄數(shù)，以便修復(fù)數(shù)據(jù)庫后進(jìn)行比較）。
在查詢分析器中運(yùn)行：
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個(gè)參數(shù):
REPAIR_ALLOW_DATA_LOSS
執(zhí)行由 REPAIR_REBUILD 完成的所有修復(fù)，包括對行和頁進(jìn)行分配和取消分配以改正分配錯(cuò)誤、結(jié)構(gòu)行或頁的錯(cuò)誤，以及刪除已損壞的文本對象。這些修復(fù)可能會(huì)導(dǎo)致一些數(shù)據(jù)丟失。修復(fù)操作可以在用戶事務(wù)下完成以允許用戶回滾所做的更改。如果回滾修復(fù)，則數(shù)據(jù)庫仍會(huì)含有錯(cuò)誤，應(yīng)該從備份進(jìn)行恢復(fù)。如果由于所提供修復(fù)等級的緣故遺漏某個(gè)錯(cuò)誤的修復(fù)，則將遺漏任何取決于該修復(fù)的修復(fù)。修復(fù)完成后，備份數(shù)據(jù)庫。
REPAIR_FAST 進(jìn)行小的、不耗時(shí)的修復(fù)操作，如修復(fù)非聚集索引中的附加鍵。這些修復(fù)可以很快完成，并且不會(huì)有丟失數(shù)據(jù)的危險(xiǎn)。
REPAIR_REBUILD 執(zhí)行由 REPAIR_FAST 完成的所有修復(fù)，包括需要較長時(shí)間的修復(fù)（如重建索引）。執(zhí)行這些修復(fù)時(shí)不會(huì)有丟失數(shù)據(jù)的危險(xiǎn)。
第一次運(yùn)行，我們會(huì)發(fā)現(xiàn)：
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'.
再次運(yùn)行，還是有同樣的錯(cuò)誤。糟糕:=)看來這種方式是無法修復(fù)這樣測錯(cuò)誤。
失敗！！！
再仔細(xì)看看SQLSERVER BOL發(fā)現(xiàn)CHECKDB還有一個(gè)非常有用的參數(shù)PHYSICAL_ONLY
PHYSICAL_ONLY
僅限于檢查頁和記錄標(biāo)題物理結(jié)構(gòu)的完整性，以及頁對象 ID 和索引 ID 與分配結(jié)構(gòu)之間的一致性。該檢查旨在以較低的開銷檢查數(shù)據(jù)庫的物理一致性，同時(shí)還檢測會(huì)危及用戶數(shù)據(jù)安全的殘缺頁和常見的硬件故障。PHYSICAL_ONLY 始終意味著 NO_INFOMSGS，并且不能與任何修復(fù)選項(xiàng)一起使用。
再次運(yùn)行：
DBCC CHECKDB('POS_DB') with NO_INFOMSGS,PHYSICAL_ONLY
然后再運(yùn)行：
DBCC CHECKDB('POS_DB',repair_allow_data_loss) WITH TABLOCK
這次會(huì)返回一些8952.8956的錯(cuò)誤信息:
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 ().
根據(jù)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.
這些問題不會(huì)引起數(shù)據(jù)或索引的損壞，這些問題的元數(shù)據(jù)是正確的，只是刪除再重新建立索引。
看來問題是修改了。
再次運(yùn)行DBCC CHECKDB('POS_DB'),再次運(yùn)行:DBCC CHECKDB('POS_DB'),message沒有錯(cuò)誤信息。
ok成功修復(fù):-)
4.檢查修復(fù)后的數(shù)據(jù)庫并且備份數(shù)據(jù)庫
檢查DBCC CHECKDB報(bào)錯(cuò)的相關(guān)表，和沒有執(zhí)行DBCC之前的記錄數(shù)進(jìn)行比較，發(fā)現(xiàn)有一個(gè)表少了40條記錄。郁悶:-
5.總結(jié)
1.RAID5并不能保證SQLSERVER 2000 數(shù)據(jù)庫的數(shù)據(jù)文件的完整性；
2.SQLERVER 2000的備份程序不驗(yàn)證數(shù)據(jù)庫文件的數(shù)據(jù)完整性；如果你的數(shù)據(jù)文件有問題，備份時(shí)也不圖示；
3.DBCC CHECKDB的repair_allow_data_loss并不是非常安全的，不能修復(fù)所有的錯(cuò)誤，即使是對不完整頁（TORN PAGE）的修復(fù)也會(huì)著成數(shù)據(jù)丟失；
4.DBCC CHECKDB的REPAIR_ALLOW_DATA_LOSS參數(shù)無法修復(fù)所有的錯(cuò)誤;
參考文章:
http://support.microsoft.com/default.aspx?scid=kb;en-us;298806
http://support.microsoft.com/default.aspx?scid=kb;en-us;284440
http://support.microsoft.com/default.aspx?kbid=320434
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
http://support.microsoft.com/default.aspx?scid=kb;en-us;308795
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
-----------------------------------------------------------------------------------------------------------------
EXECUTE master.dbo.xp_sqlmaint N'-PlanID 4F597334-7ABF-4140-8DF3-2CE11E9CE6C2 -Rpt "E:\DATABASE\數(shù)據(jù)庫維護(hù)計(jì)劃14.txt"? -BkUpMedia DISK -BkUpDB "E:\DATABASE" -BkExt "BAK"'
數(shù)據(jù)庫全備份也成功了
Microsoft (R) SQLMaint 實(shí)用工具（Unicode），版本 登錄到 SQL Server“P4”以“NT AUTHORITY\SYSTEM”（受信任）身份
開始維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃1”（在 2005-7-6 15:56:31 上）
[1] 數(shù)據(jù)庫 OTSP庫 備份...
??? 目的: [E:\DATABASE\OtSpOnline_db_200507061556.BAK]
??? ** 執(zhí)行時(shí)間: 0 小時(shí)，2 分鐘，30 秒 **
結(jié)束維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃1”（在 2005-7-6 15:59:01 上）
SQLMAINT.EXE 進(jìn)程退出代碼: 0 (成功)
------------------------------------------------------------------------------------------------------------
執(zhí)行下面的數(shù)據(jù)庫維護(hù)計(jì)劃
EXECUTE master.dbo.xp_sqlmaint N'-PlanID DB9949C7-4262-46EF-A16E-B5A16E9455CC -Rpt "E:\db_bak\數(shù)據(jù)庫維護(hù)計(jì)劃-Tonychen-200507022.txt" -DelTxtRpt 1WEEKS -WriteHistory? -CkDBRepair? '
錯(cuò)誤日志如下：
Microsoft (R) SQLMaint 實(shí)用工具（Unicode），版本 登錄到 SQL Server“SPSERVER”以“SPSERVER\Administrator”（受信任）身份
開始維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃-Tonychen-20050702”（在 2005-7-6 11:32:32 上）
[1] 數(shù)據(jù)庫 OtSp: 檢查數(shù)據(jù)鏈接...
[Microsoft SQL-DMO （ODBC SQLState: 42000）] 錯(cuò)誤 8906: [Microsoft][ODBC SQL Server Driver][SQL Server]擴(kuò)展盤區(qū) (3:10487)（屬于數(shù)據(jù)庫 ID 7）在 SGAM (3:3) 和 PFS (3:8088) 中進(jìn)行了分配，但未在任何 IAM 中進(jìn)行過分配。PFS 標(biāo)志 'MIXED_EXT ALLOCATED?? 0_PCT_FULL'。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 發(fā)現(xiàn)了 1 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在表 'WWCHAT_SUB_Around' 中，該表的對象 ID 為 1214627370）。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 發(fā)現(xiàn)了 1 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在數(shù)據(jù)庫 'OtSp' 中）。
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss 是最低的修復(fù)級別（對于由 DBCC CHECKDB (OtSp noindex) 發(fā)現(xiàn)的錯(cuò)誤而言）。
??? 發(fā)現(xiàn)下列錯(cuò)誤:
[Microsoft][ODBC SQL Server Driver][SQL Server]擴(kuò)展盤區(qū) (3:10487)（屬于數(shù)據(jù)庫 ID 7）在 SGAM (3:3) 和 PFS (3:8088) 中進(jìn)行了分配，但未在任何 IAM 中進(jìn)行過分配。PFS 標(biāo)志 'MIXED_EXT ALLOCATED?? 0_PCT_FULL'。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 發(fā)現(xiàn)了 1 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在表 'WWCHAT_SUB_Around' 中，該表的對象 ID 為 1214627370）。
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB 發(fā)現(xiàn)了 1 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在數(shù)據(jù)庫 'OtSp' 中）。
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss 是最低的修復(fù)級別（對于由 DBCC CHECKDB (OtSp noindex) 發(fā)現(xiàn)的錯(cuò)誤而言）。
??? ** 執(zhí)行時(shí)間: 0 小時(shí)，0 分鐘，41 秒 **
[2] 數(shù)據(jù)庫 otspbak: 檢查數(shù)據(jù)鏈接...
??? ** 執(zhí)行時(shí)間: 0 小時(shí)，0 分鐘，4 秒 **
正在刪除舊的文本報(bào)告...?? 已刪除 0 個(gè)文件。
結(jié)束維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃-Tonychen-20050702”（在 2005-7-6 11:33:17 上）
SQLMAINT.EXE 進(jìn)程退出代碼: 1 (失敗)
解決方法：
alter database otsponline set single_user --切換到單用戶模式下
dbcc checkdb('otsp',repair_allow_data_loss) WITH TABLOCK -- 進(jìn)行數(shù)據(jù)庫修復(fù)
alter database otsponline set multi_user --切換回到多用戶模式下
重新執(zhí)行數(shù)據(jù)庫維護(hù)計(jì)劃：
EXECUTE master.dbo.xp_sqlmaint N'-PlanID DB9949C7-4262-46EF-A16E-B5A16E9455CC -Rpt "E:\db_bak\數(shù)據(jù)庫維護(hù)計(jì)劃-Tonychen-200507022.txt" -DelTxtRpt 1WEEKS -WriteHistory? -CkDBRepair? '
事務(wù)日志正確：
Microsoft (R) SQLMaint 實(shí)用工具（Unicode），版本 登錄到 SQL Server“P4”以“NT AUTHORITY\SYSTEM”（受信任）身份
開始維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃1”（在 2005-7-6 15:53:49 上）
[1] 數(shù)據(jù)庫 OTSP: 檢查數(shù)據(jù)鏈接...
??? ** 執(zhí)行時(shí)間: 0 小時(shí)，1 分鐘，34 秒 **
結(jié)束維護(hù)計(jì)劃“數(shù)據(jù)庫維護(hù)計(jì)劃1”（在 2005-7-6 15:55:23 上）
SQLMAINT.EXE 進(jìn)程退出代碼: 0 (成功)