正常方式下，要備份一個資料庫，首先要先將該資料庫從運行的資料服務器中斷開，或者停掉整個資料庫服務器，然後複製文件。
| 卸下資料庫的命令：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 ServerMSSQLDatatest_data.mdf',』C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf' sp_attach_single_file_db 』test',』C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data.mdf' |
只有mdf文件的救援技術
因為種種原因，我們假如當時僅僅備份了mdf文件，那麼救援起來就是一件很麻煩的事情了。
假如您的mdf文件是當前資料庫產生的，那麼很僥倖，也許妳使用sp_attach_db或者sp_attach_single_file_db可以救援資料庫，但是會出現類似下面的提示信息。
| 設備提示錯誤。物理文件名 』C:Program FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF' 可能有誤。 已創建名為 』C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF' 的新日誌文件。 |
但是，假如您的資料庫文件是從其他機器上複制過來的，那麼很不幸，也許上述辦法就行不通了。妳也許會得到類似下面的錯誤信息服務器：
|
動靜 1813，級別 16，狀態 2，行 1 未能打開新資料庫 』test'。CREATE DATABASE 將終止。 設備提示錯誤。物理文件名 "d:test_log.LDF" 可能有誤。 |
不要著急，下面我們舉例說明救援辦法。
我們使用默認方式建立一個供救援使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
停掉資料庫服務器。
將剛才天生的資料庫的日誌文件test_log.ldf刪除，用要救援的資料庫mdf文件覆蓋剛才天生的資料庫資料文件test_data.mdf。
啟動資料庫服務器。此時會看到資料庫test的狀態為「置疑」。這時候不能對此資料庫進行任何操作。
設置資料庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫服務器，按右鍵，選擇「屬性」，在「服務器設置」頁面中將「允許對系統目錄直接修改」一項選中。也可以使用如下語句來實現。
| use master go sp_configure 』allow updates',1 go reconfigure with override go 設置test為緊急修複模式 update sysdatabases set status=-32768 where dbid=DB_ID(』test) |
此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於「只讀置疑脫機緊急模式」可以看到資料庫裡面的表，但是僅僅有系統表。
下面執行真正的救援操作，重建資料庫日誌文件
| dbcc rebuild_log(』test',』C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf') |
執行過程中，假如碰到下列提示信息：
|
服務器: 動靜 5030，級別 16，狀態 1，行 1 未能排它地鎖定資料庫以執行該操作。 |
說明您的其他程序正在使用該資料庫，假如剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫的系統表，那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於：
| 警告: 資料庫 』test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置資料庫選項，並且可能需要刪除多餘的日誌文件。 DBCC 執行完畢。假如 DBCC 輸出了錯誤信息，請與系統管理員聯繫。 |
此時打開在SQL Server Enterprise Manager裡面會看到資料庫的狀態為「只供DBO使用」。此時可以訪問資料庫裡面的用戶表了。
驗證資料庫一致性（可省略）
dbcc checkdb(』test')
一般執行結果如下：
| CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在資料庫 』test' 中）。 DBCC 執行完畢。假如 DBCC 輸出了錯誤信息，請與系統管理員聯繫。 |
設置資料庫為正常狀態
| sp_dboption 』test',』dbo use only',』false' |
假如沒有出錯，那麼恭喜，現在就可以正常的使用救援後的資料庫啦。
最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項救援。因為平時直接操作系統表是一件比較危險的事情。
當然，我們可以在SQL Server Enterprise Manager裡面救援，也可以使用如下語句完成
| sp_configure 』allow updates',0 go reconfigure with override go |
提醒您：碰到SQL資料庫資料丟失時，在保持一份冷靜態度的同時要盡快的找專業的資料救援公司諮詢、檢測，使您的損失降到最低。
資料救援由資料救援服務站製作，以創用CC 姓名標示-相同方式分享 4.0 國際 授權條款釋出。
此作品衍生自http://datatw2015.pixnet.net/blog。
留言列表
