問題背景 運維操作失誤，在沒有正常關閉sqlserver的情況下，將伺服器關閉了，重啟後某些表損壞（應該是某些頁損壞了，沒有損壞的頁還能訪問到數據，但是訪問損壞了的頁就有問題），目前資料庫只有4.20號的備份。 報錯信息 查詢腳本：select * from t_jxjs_pctq where c_ ...
問題背景
運維操作失誤，在沒有正常關閉sqlserver的情況下，將伺服器關閉了，重啟後某些表損壞（應該是某些頁損壞了，沒有損壞的頁還能訪問到數據，但是訪問損壞了的頁就有問題），目前資料庫只有4.20號的備份。
報錯信息
查詢腳本：select * from t_jxjs_pctq where c_bh_tqxx = '8ae480b26320550e016323d098050175';
報錯信息：HY000-[SQL Server] 資料庫 ID 11,頁[1:60682]已標記為RestorePending,可能表名磁碟已損壞，要從此狀態進行恢復，請執行還原操作。
報錯可能的原因
RestorePending一般是在進行頁恢復的過程中出現的，就是在進行了restore操作之後但還沒有進行recovery操作之前頁的狀態。出現這樣的問題可以肯定這個表是損壞了，但是在查詢數據的時候如果不會查詢到損壞頁面的數據話是不會報錯的，也就是說可以有條件的使用這個表。參考資料
5.7號和4.20號的數據量對比
| 表名 | 4.20號 | 5.6號 |
|---|---|---|
| T_JXJS_PCTQ | 1716 | 2175 |
| T_YWGY_WSQD_WS | 7358 | 8275 |
| T_JXJS_HYJL | 244 | 287 |
資料庫修複
--修複改資料庫 1.此時我們需要將資料庫設置成單用戶模式：
右鍵點擊資料庫 -> 屬性 -> 選項 -> 狀態 -> 限制訪問 -> 選擇Single-> 確定。註意修複完成後需要改回多用戶模式。
--2.使用dbcc checkdb進行資料庫修複
DBCC CHECKDB ('db_xfzx', REPAIR_FAST)
--修複過程中報錯信息：
T_JXJS_HYJL的 DBCC 結果。
消息 8928，級別 16，狀態 2，第 1 行
對象 ID 885578193，索引 ID 1，分區 ID 72057594060341248，分配單元 ID 72057594075873280 (類型為 In-row data): 無法處理頁 (1:70890)。有關詳細信息，請參閱其他錯誤消息。
DBCC 語句的修複級別導致避開了此修複。
消息 8939，級別 16，狀態 98，第 1 行
表錯誤: 對象 ID 885578193，索引 ID 1，分區 ID 72057594060341248，分配單元 ID 72057594075873280 (類型為 In-row data)，頁 (1:70890)。測試(IS_OFF (BUF_IOERR, pBUF->bstat))失敗。值為 12584969 和 -6。
修複此錯誤要求首先修正其他錯誤。
消息 8976，級別 16，狀態 1，第 1 行
表錯誤: 對象 ID 885578193，索引 ID 1，分區 ID 72057594060341248，分配單元 ID 72057594075873280 (類型為 In-row data)。在掃描過程中未發現頁 (1:70890)，但該頁的父級 (1:704) 和上一頁 (1:450709) 都引用了它。請檢查以前的錯誤消息。
修複此錯誤要求首先修正其他錯誤。
對象 'T_JXJS_HYJL' 的 6 頁中有 249 行。
CHECKDB 在表 'T_JXJS_HYJL' (對象 ID 885578193)中發現 0 個分配錯誤和 3 個一致性錯誤。
--3.重建索引並修複，報一樣的錯
DBCC CHECKDB ('db_xfzx', REPAIR_REBUILD)
--4.在修複過程中發現T_YWGY_WSQD_WS，T_JXJS_HYJL均有此報錯。同時檢查其他庫沒有發現有損壞情況。
--5.嘗試進行單個表修複，以及對損壞頁的單獨修複，均會報上面的的錯。
dbcc checktable('t_jxjs_pctq',REPAIR_REBUILD)
dbcc page(11,1,60682,3)
dbcc checkdb並未能解決問題。
重建索引
1.執行了dbcc checkdb後，報錯的信息里有索引 ID 1;這個信息的提供，可能是索引頁的損壞。但是前面執行的DBCC CHECKDB ('db_xfzx', REPAIR_REBUILD)重建索引修複，並沒能解決問題。
2.猜測:因為一個表中有多個索引，所以是不是單獨重新生成每一個索引就能發現是哪個索引有問題呢？
3.在sqlserver客戶端工具上面，對錶T_JXJS_HYJL包括主鍵在內的三個索引進行重新生成，過程中有一個普通索引(I_JXJS_PCTQ_TQXX)的重新生成失敗了，報錯信息和最開始查詢的信息一樣。嘗試重新組織該索引還是一樣的問題。那麼問題就出在I_JXJS_PCTQ_TQXX這個普通索引上了。
4.既然重建索引失敗了，嘗試刪除該索引，發現可以刪除，再重新創建該索引。
5.重建完成後再修複,DBCC CHECKDB ('db_xfzx', REPAIR_FAST) 。這時異常信息裡面沒有T_JXJS_HYJL表的異常信息。查看表中的數據已經正常，異常的數據可以正常查詢，數據量的統計也已經正常。
6.同樣T_YWGY_WSQD_WS該表有一個普通索引重新生成有問題，採用上面的方法也能解決。而T_JXJS_HYJL這張表的數據出現重建異常的是主鍵，由於有主鍵約束，所以不能刪除索引，嘗試修改為非主鍵，但是報錯和查詢一樣的的錯誤。看來主鍵的數據不能這麼做。最終由於該表只有兩百多條數據，而且並不重要，直接恢復了4.20號的數據。
7.當然對錶T_YWGY_WSQD_WS也可以採用將該表的數據通過select * into tableA from tableB;的形式插入到另外的表，重新創建該表後將數據恢復回來，然後重建索引。
結語
1.運行dbcc checkdb(db_name)檢查資料庫的完整性。根據日誌判斷可能由於某個索引的索引頁缺失，索引不完整，導致某些數據查詢的異常。而重新生成索引，不能成功，可以先刪除該索引，再重新創建。
2.如果是主鍵索引則可以採用數據遷移的方式。
3.需要註意的是修複過程中不要使用DBCC CHECKDB ('數據名'', REPAIR_ALLOW_DATA_LOSS)，REPAIR_ALLOW_DATA_LOSS該語句是可能丟失數據的。
4.修複完成後需要從單用戶模式修改為多用戶模式。
5.做到未雨綢繆，提前做好備份，每天備份，對備份的數據進行還原測試。做到有”備”無患
