修復sql2000資料庫置疑
在實際的操作中由於突然斷電或者突然斷網造成資料庫置疑（在企業管理器中資料庫後面出現置疑兩個字），下面我們通過以下方法來進行修復置疑的資料庫。
A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
B.停掉資料庫伺服器。
C. 將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。
D. 啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。
E. 設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F.設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
G.下面執行真正的恢復操作，重建資料庫日誌文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
執行過程中，如果遇到下列提示信息：
伺服器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
H.驗證資料庫一致性（可省略）
dbcc checkdb('test')
一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
I.設置資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
J.最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
② SQL SERVER資料庫報823錯誤怎麼解決
823錯誤，也就是所謂的硬IO錯誤，可以理解為SQL Server希望讀取到某頁，而Windows告訴SQL Server，無法讀取到該頁,這情況一般是SQL Server文件頁有缺失所致，通過用WINHEX分析SQL Server文件的結構再用其備份補上這一頁就可以了。找正大數據幫恢復，很多年了！特別牛X~~~~
③ SQL的錯誤 錯誤: 823，嚴重度: 24，狀態: 2。
數據文件損壞了，如果之前有完全備份恢復一個完全備份，注意恢復前先備份尾日誌。
備份尾日誌的方法是在backup 語句後加上no_truncate選項
比如
backup log portalse1 to disk='d:\portalse1.trn' with no_truncate
另外還有可能是硬碟出問題了，用磁碟掃描檢查一下磁碟。
④ 我在附加資料庫時出現這示一個對話框提示：Micrsoft sql_dmo(odbc sqlstate:HY000)錯誤：823
錯誤 823
嚴重級別 24
消息正文
在文件 ''%4!'' 的偏移量 %3! 處的 %2! 過程中，檢測到 I/O 錯誤 %1!。
解釋
Microsoft® SQL Server™ 在對某設備進行讀或寫請求時遇到 I/O 錯誤明鋒型。該錯誤通常表明磁碟問題。但是，錯誤日誌中在錯誤 823 之前記錄的其它核心消息應指出涉及了哪個設備。
對策
檢查該設備的可訪問性和狀態。
如果可能，執行硬體診斷並糾正問題。
從最新的資料庫備份還原損壞的文件。從資料庫備份中還原應始終是修復已損壞資料庫的首選方法。
如果沒有備份或者檢測到激猜基喚的錯誤是孤立的，則 DBCC CHECKDB 的修復功能可能很有用。然而，比起從備份中還原損壞的文件，可能使用 DBCC CHECKDB 消耗的時間更多，且可能無法恢復全部數據。
⑤ SQL server附加資料庫時出錯，提示說： 附加資料庫時出錯。有關詳細信息，請單擊「消息」列中的超鏈接。急
這個是因為資料庫是從其他電腦或者其他版本的原始文件，需要手動分配一下當前資料庫版本的訪問資料庫原始文件的許可權，解決方法如下：
1、首先打開資料庫之後，選擇性的進行登錄的，這里我們運用sa密碼進行登錄。
⑥ SQLSERVER2000 資料庫損壞，求修復方法 錯誤: 823，嚴重度: 24，狀態: 2 I/O error (bad page ID) detecte
可以使用DBCC 來修復，DBCC CHECKDB('資料庫名稱',REPAIR_ALLOW_DATA_LOSS)
⑦ sql資料庫附加出錯怎麼辦
解決方法步驟如下：
1、首先打開sqlserver management studio,登錄身份選擇windows身份驗證，點擊連接。
⑧ sql 錯誤 823
--------------------- 1.日誌文件被破壞823錯誤 ---------------------- 日誌文件被破壞的資料庫文件，通過如下方法附加上去後，資料庫里所有的表都不能訪問，提示錯誤832，請問要如何解決？？ use master go sp_configure 'allow updates',1 go reconfigure with override go update sysdatabases set status=-32768 where dbid=DB_ID('linyi_pljy') go dbcc rebuild_log('linyi_pljy','e:Program FilesMicrosoft SQL ServerMSSQLDatalinyi_pljy_log.ldf') go sp_dboption 'linyi_pljy','dbo use only','false' go sp_configure 'allow updates',0 go reconfigure with override go --------------------- 2.附加資料庫文件時,提示823錯誤 ---------------------- EXEC sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打開修改系統表的開關 */ update sysdatabases set status = 32768 where name = '資料庫名' DBCC REBUILD_LOG ('資料庫名', 'E: dzzdatabase dzz1204_Log.LDF' ) update sysdatabases set status = 0 where name = '資料庫名' restore database 資料庫名 WITH RECOVERY EXEC sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 關閉打開修改系統表的開關 */ --------------------- 3.因為停電等原因造成MSSQL資料庫,提示823錯誤 ---------------------- USE MASTER GO sp_dboption 『databaseName』, 』single user』, 『true』 Go DBCC CHECKDB(』databaseName』, REPAIR_REBUILD) Go USE databaseName go exec sp_msforeachtable 『DBCC CHECKTABLE(''』?''』,REPAIR_REBUILD)』 go sp_dboption 『databaseName』, 』single user』, 『false』 Go 如果還不行，可以採用允許丟失數據的方式修復，如下： USE MASTER GO sp_dboption 『databaseName』, 』single user』, 『true』 Go DBCC CHECKDB(』databaseName』, REPAIR_ALLOW_DATA_LOSS) Go USE databaseName go exec sp_msforeachtable 『DBCC CHECKTABLE(''』?''』,REPAIR_REBUILD)』 go sp_dboption 『databaseName』, 』single user』, 『false』 Go --------------------- 4.在大富翁論壇收集的資料庫恢復資料 ---------------------- SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager(SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器) 1、正常的備份、恢復方式正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。卸下資料庫的命令：Sp_detach_db 資料庫名連接資料庫的命令：Sp_attach_db或者sp_attach_single_file_db s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16] sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′ 使用此方法可以正確恢復SQL Sever7.0和SQL Server 2000的資料庫文件，要點是備份的時候一定要將mdf和ldf兩個文件都備份下來，mdf文件是資料庫數據文件，ldf是資料庫日誌文件。例子：假設資料庫為test，其數據文件為test_data.mdf，日誌文件為test_log.ldf。下面我們討論一下如何備份、恢復該資料庫。卸下資料庫：sp_detach_db 'test' 連接資料庫：sp_attach_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf' sp_attach_single_file_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf' 2、只有mdf文件的恢復技術由於種種原因，我們如果當時僅僅備份了mdf文件，那麼恢復起來就是一件很麻煩的事情了。如果您的mdf文件是當前資料庫產生的，那麼很僥幸，也許你使用sp_attach_db或者sp_attach_single_file_db可以恢復資料庫，但是會出現類似下面的提示信息設備激活錯誤。物理文件名 'C:Program FilesMicrosoft SQL ServerMSSQLdata est_Log.LDF' 可能有誤。已創建名為 'C:Program FilesMicrosoft SQL ServerMSSQLData est_log.LDF' 的新日誌文件。但是，如果您的資料庫文件是從其他計算機上復制過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤信息伺服器: 消息 1813，級別 16，狀態 2，行 1 未能打開新資料庫 'test'。CREATE DATABASE 將終止。設備激活錯誤。物理文件名 'd: est_log.LDF' 可能有誤。怎麼辦呢？別著急，下面我們舉例說明恢復辦法。 A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。 B．停掉資料庫伺服器。 C．將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。 D．啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。 E．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。 use master go sp_configure 'allow updates',1 go reconfigure with override go F．設置test為緊急修復模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀置疑離線緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表 G．下面執行真正的恢復操作，重建資料庫日誌文件 dbcc rebuild_log('test','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf') 執行過程中，如果遇到下列提示信息：伺服器: 消息 5030，級別 16，狀態 1，行 1 未能排它地鎖定資料庫以執行該操作。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。[brown] 說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。正確執行完成的提示應該類似於： [brown]警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。 H．驗證資料庫一致性（可省略） dbcc checkdb('test') 一般執行結果如下： CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 I．設置資料庫為正常狀態 sp_dboption 'test','dbo use only','false' 如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。 J．最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成 sp_configure 'allow updates',0 go reconfigure with override go 來自：yzhshi, 時間：2003-3-11 9:59:00, ID：1670897 為藍色頁面用戶再提供一份，不過建議使用黃色頁面，頁面標志更清晰一些。 SQL Server資料庫文件恢復技術 yzhshi([email protected]) SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager (SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器) 1、正常的備份、恢復方式正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。卸下資料庫的命令：Sp_detach_db 資料庫名連接資料庫的命令：Sp_attach_db或者sp_attach_single_file_db s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16] sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′ 使用此方法可以正確恢復SQL Sever7.0和SQL Server 2000的資料庫文件，要點是備份的時候一定要將 mdf和ldf兩個文件都備份下來，mdf文件是資料庫數據文件，ldf是資料庫日誌文件。例子：假設資料庫為test，其數據文件為test_data.mdf，日誌文件為test_log.ldf。下面我們討論一下如何備份、恢復該資料庫。卸下資料庫：sp_detach_db 'test' 連接資料庫：sp_attach_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf' sp_attach_single_file_db 'test','C:Program FilesMicrosoft SQL ServerMSSQLData est_data.mdf' 2、只有mdf文件的恢復技術由於種種原因，我們如果當時僅僅備份了mdf文件，那麼恢復起來就是一件很麻煩的事情了。如果您的mdf文件是當前資料庫產生的，那麼很僥幸，也許你使用sp_attach_db或者 sp_attach_single_file_db可以恢復資料庫，但是會出現類似下面的提示信息 設備激活錯誤。物理文件名 'C:Program FilesMicrosoft SQL ServerMSSQLdata est_Log.LDF' 可能有誤。已創建名為 'C:Program FilesMicrosoft SQL ServerMSSQLData est_log.LDF' 的新日誌文件。 但是，如果您的資料庫文件是從其他計算機上復制過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤信息 伺服器: 消息 1813，級別 16，狀態 2，行 1 未能打開新資料庫 'test'。CREATE DATABASE 將終止。設備激活錯誤。物理文件名 'd: est_log.LDF' 可能有誤。 怎麼辦呢？別著急，下面我們舉例說明恢復辦法。 A．我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager 裡面建立。 B．停掉資料庫伺服器。 C．將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的數據 庫數據文件test_data.mdf。 D．啟動資料庫伺服器。此時會看到資料庫test的狀態為"置疑"。這時候不能對此資料庫進行任何操作。 E．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫服 務器，按右鍵，選擇"屬性"，在"伺服器設置"頁面中將"允許對系統目錄直接修改"一項選中。也可以 使用如下語句來實現。 use master go sp_configure 'allow updates',1 go reconfigure with override go F．設置test為緊急修復模式 update sysdatabases set status=-32768 where dbid=DB_ID('test') 此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於"只讀置疑離線緊急模式"可以 看到資料庫裡面的表，但是僅僅有系統表 G．下面執行真正的恢復操作，重建資料庫日誌文件 dbcc rebuild_log('test','C:Program FilesMicrosoft SQL ServerMSSQLData est_log.ldf') 執行過程中，如果遇到下列提示信息： 伺服器: 消息 5030，級別 16，狀態 1，行 1 未能排它地鎖定資料庫以執行該操作。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager 打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。 正確執行完成的提示應該類似於： 警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致 性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為"只供DBO使用"。此時可以 訪問資料庫裡面的用戶表了。 H．驗證資料庫一致性（可省略） dbcc checkdb('test') 一般執行結果如下： CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。 DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。 I．設置資料庫為正常狀態 sp_dboption 'test','dbo use only','false' 如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。 J．最後一步，我們要將步驟E中設置的"允許對系統目錄直接修改"一項恢復。因為平時直接操作系統表 是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用 如下語句完成 sp_configure 'allow updates',0 go reconfigure with override go ===================================================================================== (轉) 修復SQLSERVER2000資料庫之實戰經驗 我所講的一個故事的背景是這樣的，在某一個POS的項目中使用SQLSERVER 2000做前台資料庫，IBM 的DB2做後台資料庫。前台資料庫的環境是這樣的操作系統是WINDOWS2000 SERVER(10 USERS),資料庫是 SQLSERVER2000(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 ring read at offset 0x0000001bf96000 in file D :DATAPOS_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 ring read at offset 0x00000074964000 in file 'D:DATAPOS_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 ring read at offset 0x00000094004000 in file 'F:SQLDatamydb.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 ring 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相關聯的信息， 錯誤號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:DATABASEBACKUPPOS_DB_BACKUP.DAT' 重新啟動MSSQLSERCVER服務， NET STOP MSSQLSERVER / NET START MSSQLSERVER 用DBCC檢查資料庫的完整性 DBCC CHECKDB('POS_DB') WITH ALL_ERRORMSGS 和恢復之前的錯誤信息一致，沒有改變。 --奇怪問題之2，SQLSERVER BACKUP 之前並不驗證資料庫的完整性，資料庫的全備份竟然是有問題的。氣憤！！ 看來只能通過工具修復資料庫了（--在修改之前記錄錯誤表的記錄數，以便修復資料庫後進行比較）。
⑨ SQL的823錯該怎麼改
nbsp;最近工作上碰見SQL資料庫附加提示「823」號錯誤。從網上搜了一些資料，按照幾個方法執行後解決了此類問題。並對解決後資料庫出現不一致的問題也做了解決辦法的說明。我的資料庫是因為伺服器系統壞掉，重新安裝到別的伺服器上了，把資料庫文件和日誌拷過去後，想附加，結果出現了823錯誤提示。於是就到網上網路了一下，找到了這個方法。
原因: 1、因為停電等原因造成MSSQL資料庫,提示823錯誤。
2、日誌文件被破壞823錯誤。
SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager(SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器)
1、正常的備份、恢復方式
正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。
卸下資料庫的命令：Sp_detach_db 資料庫名
連接資料庫的命令：Sp_attach_db或者sp_attach_single_file_db
s_attach_db [@dbname =] ′dbname′, [@filename1 =] ′filename_n′ [,...16]
sp_attach_single_file_db [@dbname =] ′dbname′, [@physname =] ′physical_name′
使用此方法可以正確恢復SQL Sever7.0和SQL Server 2000的資料庫文件，要點是備份的時候一定要將mdf和ldf兩個文件都備份下來，mdf文件是資料庫數據文件，ldf是資料庫日誌文件。
例子：
假設資料庫為test，其數據文件為test_data.mdf，日誌文件為test_log.ldf。下面我們討論一下如何備份、恢復該資料庫。
卸下資料庫：sp_detach_db 'test'
連接資料庫：sp_attach_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf'
sp_attach_single_file_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf'
2、只有mdf文件的恢復技術
由於種種原因，我們如果當時僅僅備份了mdf文件，那麼恢復起來就是一件很麻煩的事情了。
如果您的mdf文件是當前資料庫產生的，那麼很僥幸，也許你使用sp_attach_db或者sp_attach_single_file_db可以恢復資料庫，但是會出現類似下面的提示信息
設備激活錯誤。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有誤。
已創建名為 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日誌文件。
但是，如果您的資料庫文件是從其他計算機上復制過來的，那麼很不幸，也許上述辦法就行不通了。你也許會得到類似下面的錯誤信息
伺服器: 消息 1813，級別 16，狀態 2，行 1
未能打開新資料庫 'test'。CREATE DATABASE 將終止。
設備激活錯誤。物理文件名 'd:\test_log.LDF' 可能有誤。
怎麼辦呢？別著急，下面我們舉例說明恢復辦法。
A我們使用默認方式建立一個供恢復使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
B．停掉資料庫伺服器。
C.將剛才生成的資料庫的日誌文件test_log.ldf刪除，用要恢復的資料庫mdf文件覆蓋剛才生成的資料庫數據文件test_data.mdf。D．啟動資料庫伺服器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。E．設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器，按右鍵，選擇「屬性」，在「伺服器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F.設置test為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀\置疑\離線\緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表
G．下面執行真正的恢復操作，重建資料庫日誌文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
執行過程中，如果遇到下列提示信息：
伺服器: 消息 5030，級別 16，狀態 1，行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。[brown]
說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
[brown]警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
H．驗證資料庫一致性（可省略）
dbcc checkdb('test')
一般執行結果如下：
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 'test' 中）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
I．設置資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
如果沒有出錯，那麼恭喜，現在就可以正常的使用恢復後的資料庫啦。
J．最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager裡面恢復，也可以使用如下語句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
對於提示"分配錯誤"及"一致性錯誤"依次執行下列語句:
sp_dboption '資料庫', 'SINGLE USER', TRUE
DBCC CHECKDB('資料庫', REPAIR_ALLOW_DATA_LOSS)
sp_dboption '資料庫', 'SINGLE USER', FALSE
用這些修復語句修復後，返回的一些有代表性的錯誤信息：
再根據錯誤信息，查詢不能修復的信息備份，將之刪除，再將備份的信息插入原來的地方，問題解決
⑩ 附加SQL2000資料庫823錯誤
有沒有附加日誌文件，
如果庫文件和日誌文件一塊附加都附加不上的話，按以下步驟操作：
1，在sqlserver中新建庫（新建沒有表的空庫，庫名為你附加失敗的庫名），記住資料庫文件存放地址（最好指定目錄）。
2，停止sqlserver服務，在新建的庫文件目錄下將日誌文件刪除（.ldf），然後將附加失敗的庫文件覆蓋進去。
3，啟動sqlserver服務，但不停止一切連接該庫的服務。
然後執行語句：
use master
go
alter database db_name set emergency
go
4、置為單用戶模式，並重建日誌：
alter database db_name set single_user with rollback immediate
go
alter database db_name Rebuild Log on (name=log_name,filename='C:\log_name.ldf')
go
alter database dbname set multi_user
go
其中日誌文件目錄及文件名按實際情況填寫。
5、dbcc checkdb嘗試修復庫。
Use master
go
sp_dboption 資料庫名, single, true
dbcc checkdb(dbname,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(dbname,REPAIR_REBUILD)
go
sp_dboption 資料庫名, single, false
go
。如果修復過程中有錯誤則庫損壞嚴重，可能修復失敗。