sql1813
1813是提示沒有資料庫，你還原資料庫前應該先創建一個庫(空庫)。
⑵ sql 2000 資料庫附加失敗 提示823
sqlserver附加資料庫錯誤823的解決方案2008-10-13 15:06sqlserver附加資料庫錯誤823的解決方案一、SQL-Server附加資料庫時失敗。
1、異常情況：伺服器在正常運行的情況下突然斷電，導致資料庫文件損壞，具體表現是：資料庫名後面有「（置疑）」字樣。
2、異常分析：關於823錯誤的 SQL-SERVER 中的幫助：
================================
錯誤 823
嚴重級別 24
消息正文
在文件 "%4!" 的偏移量 %3! 處的 %2! 過程中，檢測到 I/O 錯誤 %1!。
解釋
Microsoft SQL Server 在對某設備進行讀或寫請求時遇到 I/O 錯誤。該錯誤通常表明磁碟問題。但是，錯誤日誌中在錯誤 823 之前記錄的其它核心消息應指出涉及了哪個設備。
3、解決辦法：
在SQL-Server企業管理器中，新建同名資料庫（這里假設為Test）後，停止資料庫，把損壞的資料庫文件Data.mdf和Test_log.LDF覆蓋剛才新建資料庫目錄下的Data.mdf和Test_log.LDF，同時刪除Test_log.LDF文件；啟動資料庫服務，發現資料庫名Test後面有「置疑」字樣。不要緊，打開SQL自帶查詢分析器，分別執行如下SQL語句：
第一、
exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打開修改系統表的開關 */
第二、
update sysdatabases set status=32768 where name='資料庫名' /* 設置資料庫狀態 */
第三、
DBCC REBUILD_LOG ('資料庫名','D:\database\Test_Log.LDF') /* 重建LDF文件 */
第四、
update sysdatabases set status=0 where name='資料庫名' /* 重置資料庫狀態 */
第五、
restore database 資料庫名 WITH RECOVERY /* 恢復資料庫 */
第六、
exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 關閉打開修改系統表的開關 */
按照此方法操作，應該能修復資料庫正常訪問了。如果問題依然存在，最笨的一個方法就是新建另一個資料庫，把原資料庫（Test）各個表的數據導出到新建資料庫表中。
============================================================
補充說明：用上面的六步把資料庫置疑的問題解決了，但是資料庫表裡還有損壞的表(inf_gdscode)，把壞表導出的時候也不成功。最後在查詢分析器里運行：
USE nmgbt_hcxuexipos (資料庫名)
GO
DBCC CHECKTABLE ('inf_gdscode',REPAIR_ALLOW_DATA_LOSS)
GO
⑶ 只有mdf文件，怎麼恢復SQLSERVER資料庫
比較麻煩，不過我恢復成功過，o(∩_∩)o...哈哈
等我給你找找。
use master
go
exec sp_configure 'allow updates',1
go
reconfigure with override
go
update sysdatabases set status=-32768 where dbid=DB_ID('test')
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
dbcc checkdb('test')
exec sp_dboption 'test','dbo use only','false'
exec sp_configure 'allow updates',0
go
reconfigure with override
go
sql資料庫修復技術
SQL Server資料庫備份有兩種方式，一種是使用BACKUP DATABASE將資料庫文件備份出去，另外一種就是直接拷貝資料庫文件mdf和日誌文件ldf的方式。下面將主要討論一下後者的備份與恢復。本文假定您能熟練使用SQL Server Enterprise Manager(SQL Server企業管理器)和SQL Server Quwey Analyser(SQL Server查詢分析器)
1、正常的備份、sql資料庫修復方式
正常方式下，我們要備份一個資料庫，首先要先將該資料庫從運行的數據伺服器中斷開，或者停掉整個資料庫伺服器，然後復制文件。
卸下資料庫的命令：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是資料庫日誌文件。
例子：
資料庫修復包括：sql資料庫修復 sql資料庫恢復sql server修復 文件修復 raid數據恢復 sql資料庫修復 raid磁碟陣列 sql恢復 sql server恢復 假設資料庫為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 輸出了錯誤信息，請與系統管理員聯系。
說明您的其他程序正在使用該資料庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。數據恢復 sql資料庫修復 密碼恢復 sql資料庫恢復 硬碟異響 壞道修復 文件恢復 sql server修復 文件修復 raid數據恢復 sql資料庫修復 raid磁碟陣列 sql恢復 sql server恢復 硬碟數據恢復 硬碟壞道修復 硬碟數據修復 數據修復
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 2005附加資料庫時提示1813錯，錯誤如圖
新建一個空白的資料庫然後把你的資料庫還原回去就可以了
⑸ sql2008附加資料庫時出錯消息顯示為
你這樣做吧，我也是參考別人的資料。
直接restore或附加應該是不行的, 用腳本+導數據肯定沒有問題。
2005轉到2000的步驟步驟
1. 生成for 2000版本的資料庫腳本
2005 的manger studio
-- 打開"對象資源管理器"(沒有的話按F8), 連接到你的實例
-- 右鍵要轉到2000的庫
-- 任務
-- 生成腳本
-- 在"腳本向導"的"選擇資料庫"中, 確定選擇的是要轉到2000的庫
-- 勾選"為所選資料庫中的所有對象編寫腳本"
-- 在接下來的"選擇腳本選項"中, 找到"為伺服器版本編寫腳本"項, 選擇"SQL Server 2000"
-- 其他選項根據需要設置
-- 最後把腳本保存到一個 .sql 腳本文件
2. 在2000中創建目標資料庫
在查詢分析器(或2005的manger studio在打開腳本文件), 連接到SQL Server 2000,執行上面生成的腳本.以創建一個新的資料庫
3. 將數據從2005導到2000
2005 的manger studio
-- 打開"對象資源管理器"(沒有的話按F8), 連接到你的實例
-- 右鍵要轉到2000的庫
-- 任務
-- 導出數據
-- 在"SQL Server 導入和導出向導"的"選擇數據源"步驟中, 確定選擇的是要導出的資料庫
-- 在"選擇目標"步驟中, 連接到 2000, 並選擇步驟2新建的庫
-- 在"選擇源表和源視圖"中, 選擇所有的表
-- 最後完成
⑹ 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
用這些修復語句修復後，返回的一些有代表性的錯誤信息：
再根據錯誤信息，查詢不能修復的信息備份，將之刪除，再將備份的信息插入原來的地方，問題解決
⑺ 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資料庫日誌文件
麻煩了，很多DBA不太清楚，資料庫的日誌裝的其實是真正的數據（歸檔前改變的數據），所以日誌文件也是非常重要的。
至於有些資料庫的日誌文件過大，主要是DBA沒有正確的對資料庫進行調優設置造成的。
下面的方法也許對你是有用的。
0.備份數據文件'xxzx_discuz_Log.MDF'
1.新建一個同名的資料庫'xxzx_discuz'
2.再停掉sqlserver服務(注意不要分離資料庫)
3.用原資料庫的數據文件'xxzx_discuz_Log.MDF' 覆蓋掉新建的資料庫
4.再重啟sqlserver服務
5.此時打開企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名）
6.完成後一般就可以訪問資料庫中的數據了。這時,資料庫本身一般還有問題,解決辦法是：利用資料庫的腳本創建一個新的資料庫,然後通過DTS將數據導進去就行了.
SQL代碼
use master
go
sp_configure 'allow updates',1 reconfigure with override
go
update sysdatabases set status =32768 where name='置疑的資料庫名'
go
sp_dboption '置疑的資料庫名', 'single user', 'true'
go
dbcc checkdb('置疑的資料庫名')
go
update sysdatabases set status =28 where name='置疑的資料庫名'
go
sp_configure 'allow updates', 0 reconfigure with override
go
sp_dboption '置疑的資料庫名', 'single user', 'false'
go
特別注意最後一步中的說明「這時,資料庫本身一般還有問題,解決辦法是：利用資料庫的腳本創建一個新的資料庫,然後通過DTS將數據導進去就行
⑼ sql附加資料庫時錯誤
1
那你這樣
先新建一個
同名的資料庫。
2
停止
資料庫伺服器
將tt_data.mdf覆蓋新建的數據這個
資料庫文件
3
在
企業管理器
附加資料庫
或用樓上的語句附加
你先試一下
如果不行
如果置疑了就會很麻煩，
還有如果這個資料庫很重要的話，你給我傳過來我幫你！