當前位置:首頁 > 技術分享技術分享

【資料庫救援】MySQL 資料庫救援技巧

發佈時機:  瀏覽:

 

正常方式下,要備份一個資料庫,首先要先將該資料庫從運行的資料服務器中斷開,或者停掉整個資料庫服務器,然後複製文件。

 

卸下資料庫的命令: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

未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。假如 DBCC 輸出了錯誤信息,請與系統管理員聯繫。

說明您的其他程序正在使用該資料庫,假如剛才您在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 授權條款

晟誼資料救援晟誼科技製作,以創用CC 姓名標示-相同方式分享 4.0 國際 授權條款釋出。
此作品衍生自http://www.data-tw.com/

  發表評論 共有條評論  
用戶名: 密碼:  
聯絡人: E-mail: 電 話:
驗證碼:   (看不清楚,點擊刷新)
 
  評論(共有 0 條評論)
站內搜尋
軟體下載

客户案例
教學視頻
返回首頁
聯絡我們
    新竹服務站 地址: 新竹市金城一路11號1樓 電話:(03)5713211
    高雄直營站 地址:高雄市建國二路168號 電話(07)2380668
    台中漢碩站 地址: 台中市公益路117-2號 電話: (04) 23015535
    台南服務站 地址:台南市北門路一段262號2樓(06)7030-501轉212
    中壢華冠站 地址: 桃園縣中壢市明德路15號 電話: (03) 2813885
    中壢華冠站 地址: 中壢市320中正路389號 168 櫃 (03) 281-3885#12
資料救援-晟誼科技 版權所有 Copyrigh@ 2003-2012 All Rights Reserved 客服熱線:0800-600-966 硬碟資料救援專家,全力為您提供資料救援服務!