State: 2
2003-09-05 16:51:18.90 spid17 I/O error (torn page) detected during read at offset 0x00000094004000 in file 'F:SQLDatamydb.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相關聯的信息,
錯誤號M
造成數據庫文件破壞
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:DATABASEBACKUPPOS_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).
這樣的信息有很多,並