sql資料庫在現在的中小型企業中運用是非常多地，但它的損壞也是很常見地，現就sql資料庫損壞的狀況、原因及應急方案分析一下。
一． 在還原資料庫和附加資料庫時出錯 sql備份有兩種方法：一是直接複製mdf和ldf檔案，二是利用sql備份機制建立備份檔案，但無論是那種備份都會出現無法附加或無法還原的情況。下面就分析一下出錯的原因。
１． 在利用備份出來的資料庫檔案和日誌檔案附加時會報「錯誤：823」和「一致性錯誤」如圖：
這種錯誤出現的原因有：（１）在資料庫讀寫過程中突然宕機或重啟，重啟後資料庫有時會出現「置疑」，這時利用mdf和ldf檔案附加時就會出現「一致性錯誤」，有的會出現「錯誤： 823」，這種錯誤出現的原因是在資料庫讀寫過程中，機器突然宕機或重啟，由於緩衝資料丟失，資料庫無法寫入正確的資料，那麼資料庫會寫入一些無關的資料，這樣就會造成資料庫出錯。（２）在備份資料庫時由於磁碟中有壞道，備份出來的mdf檔案不完整時也會出現這種錯誤，這種情況必須地修復損壞mdf檔案中損壞的頁，但有時會丟失幾條資料！ 如果出現上面的錯誤，如果對mdf檔案結構不是很清楚的話，請不要對原檔案進行胡亂修改，這樣會適得其反，會造成更大的損失。
２． 因為sql備份資料庫機制有問題（人個感覺，如果資料非常龐大時，備份出來的檔案有時會有問題），當使用者利用備份出來的備份檔案進行還原資料庫，資料庫會報「發和內部一致性錯誤」和無任何提示的錯誤，其中「發和內部一致性錯誤」最為常見。如圖：
出現這種情況大部分都是備份檔案損壞造成地，有部分備份檔案備份時一切正常，但還原時就會提示「發和內部一致性錯誤」，這種錯誤的修復比較複雜，因為我們不能用任何sql語句進行修復。如果損壞不是很嚴重時，我們可以在還原資料時選擇「恢復完成狀態」中地「使資料庫不再執行，但能還原其它事務日誌」，這樣就可以用命令來修復，常常這種情況用命令修復完後，資料會丟失部分！
二． 附加還原資料庫後，檢測資料庫是出現一致性錯誤和分配錯誤,如下面錯誤：
伺服器: 訊息 8928，級別 16，狀態 6，行 1
物件 id 0，索引 id 0: 未能處理頁 (1:39)。詳細資訊請參閱其它錯誤。
伺服器: 訊息 2575，級別 16，狀態 1，行 1
伺服器: 訊息 8906，級別 16，狀態 1，行 1
擴充套件盤區 (1:40)（屬於資料庫 id 7）在 sgam (1:3) 和 pfs (1:1) 中進行了分配，但未在任何 iam 中進行過分配。pfs 標誌 'mixed_ext allocated 0_pct_full'。
伺服器: 訊息 8906，級別 16，狀態 1，行 1
擴充套件盤區 (1:38)（屬於資料庫 id 7）在 sgam (1:3) 和 pfs (1:1) 中進行了分配，但未在任何 iam 中進行過分配。pfs 標誌 'mixed_ext allocated 0_pct_full'。
伺服器: 訊息 7965，級別 16，狀態 1，行 1
表錯誤: 由於無效的分配 (iam) 頁，未能檢查物件 id 10，索引 id 1。
伺服器: 訊息 8906，級別 16，狀態 1，行 1
擴充套件盤區 (1:39)（屬於資料庫 id 7）在 sgam (1:3) 和 pfs (1:1) 中進行了分配，但未在任何 iam 中進行過分配。 pfs 標誌 'iam_pg mixed_ext allocated 0_pct_full'。
伺服器: 訊息 8909，級別 16，狀態 1，行 1
表錯誤: 物件 id 10，索引 id 1，頁 id (1:39)。頁首結構中的 pageid = (1:0)。
'test' 的 dbcc 結果。
checkdb 發現了 1 個分配錯誤和 0 個一致性錯誤，這些錯誤並不與任何單個的物件相關聯。
'sysobjects' 的 dbcc 結果。
物件 'sysobjects' 有 55 行，這些行位於 1 頁中。
'sysindexes' 的 dbcc 結果。
物件 'sysindexes' 有 34 行，這些行位於 1 頁中。
'syscolumns' 的 dbcc 結果。
物件 'syscolumns' 有 359 行，這些行位於 6 頁中。
'systypes' 的 dbcc 結果。
物件 'systypes' 有 26 行，這些行位於 1 頁中。
'syscomments' 的 dbcc 結果。
物件 'syscomments' 有 127 行，這些行位於 16 頁中。
'sysfiles1' 的 dbcc 結果。
物件 'sysfiles1' 有 2 行，這些行位於 1 頁中。
'syspermissions' 的 dbcc 結果。
物件 'syspermissions' 有 18 行，這些行位於 1 頁中。
'sysusers' 的 dbcc 結果。
物件 'sysusers' 有 0 行，這些行位於 0 頁中。
checkdb 發現了 4 個分配錯誤和 2 個一致性錯誤（在表 'sysusers' 中，該錶的物件 id 為 10）。
'sysproperties' 的 dbcc 結果。
物件 'sysproperties' 有 0 行，這些行位於 0 頁中。
'sysdepends' 的 dbcc 結果。
物件 'sysdepends' 有 309 行，這些行位於 1 頁中。
'sysreferences' 的 dbcc 結果。
物件 'sysreferences' 有 0 行，這些行位於 0 頁中。
'sysfulltextcatalogs' 的 dbcc 結果。
物件 'sysfulltextcatalogs' 有 0 行，這些行位於 0 頁中。
'sysfulltextnotify' 的 dbcc 結果。
物件 'sysfulltextnotify' 有 0 行，這些行位於 0 頁中。
'sysfilegroups' 的 dbcc 結果。
物件 'sysfilegroups' 有 1 行，這些行位於 1 頁中。
'mytest' 的 dbcc 結果。
物件 'mytest' 有 2 行，這些行位於 1 頁中。
'dtproperties' 的 dbcc 結果。
物件 'dtproperties' 有 0 行，這些行位於 0 頁中。
checkdb 發現了 5 個分配錯誤和 2 個一致性錯誤（在資料庫 'test' 中）。
repair_allow_data_loss 是最低的修復級別（對於由 dbcc checkdb (test ) 發現的錯誤而言）。
引起這種錯誤一般是因為資料庫某個頁被改寫或清０了，所以會發生一致性錯誤和分配錯誤，
三． 最為常見的「未能讀取並閂鎖頁 (1:4234)（用閂鎖型別 sh）」
在檢測資料庫，會常見到下面的錯誤： 「伺服器: 訊息 8966，級別 16，狀態 1，行 1 未能讀取並閂鎖頁 (1:4234)（用閂鎖型別 sh）。sysobjects 失敗」。這種「未能讀取並閂鎖頁 (1:4234)（用閂鎖型別 sh）」錯誤常常會出現在系統表中：sysobjects、sysindexes、syscolumns等中，這種錯誤出現的原因是因為系統表被破壞，這種錯誤是很麻煩地，因為sql的效驗比較嚴密，只要稍改乙個關鍵字節，都出報這個錯誤，但有時可以匯出部分資料。
四． 誤刪除或誤格式化後sql資料庫的恢復在很多情況下，使用者會誤刪除或誤格式化掉sql資料庫，出現這種情況後使用者會用市面上軟體finaldata和easyrecovery來恢復資料庫，雖然用這些資料庫軟體可以恢復出mdf和ldf檔案來，但１００％都會無法附加地（除非資料庫不使用），即使附加成功，但錯誤會很多，資料庫也無法使用，因為資料庫在日常中經常增加和刪除記錄，這樣就會出資料庫檔案儲存不連續的情況，而市面上的軟體都是連續取資料，所以會造成資料庫無法附加。出現這種錯誤時，使用者應盡量不要使用本計算機，更不要安裝軟體和寫任何資料。由於市面上的軟體還沒有完全智慧型地恢復資料庫，所以只能手工恢復這種誤刪除的資料，這樣就必須了解sql資料庫檔案的結構。
附mdf檔案檢測工具：
恢復SQL資料庫
復sql資料庫 近日，使用者打 請求技術支援，說素材採集資料庫連線不上，筆者在網管控制台啟動應用程式，發現確實如此，如圖1所示。圖1 錯誤資訊 筆者進行了簡單的測試 ping資料庫伺服器沒有問題，證明網路連線沒有問題 odbc連線也可以連線到資料庫伺服器的master資料庫，證明客戶端沒有問題。問題...
SQL資料庫損壞怎麼辦？教你資料恢復應急方案
最近一段時間 神馬軟體系統中心 接到很多客戶諮詢sql資料庫損壞，附加資料庫報錯的一些問題，在這裡整理一下sqlsever 資料庫常見的一些 故障現象 及注意事項。目前各大 中小型企業使用sqlsever 應用的非常多，但由於各種原因，也會經常出現一些不同的故障，常見的有一下幾種 一，附加資料庫檔案...
SQL資料庫置疑恢復
資料庫置疑恢復 步驟1 建立乙個新的資料庫，命名為原來資料庫的名字。步驟2 停止sql server 步驟3 把老資料庫的mdf檔案替換新資料庫的相應的mdf檔案，並把ldf檔案刪除。步驟4 重新啟動sql server服務，然後執行如下命令 use master gosp configure al...