none
MDFファイル破損、トランザクションログなしで、障害後のLDFファイルからデータを復旧したい

    質問

  • SQL Server 2000 Enterprise Edition SP4を使用しています。

    先日、障害が発生しました。

    障害は、エラー6443314、最後に9001ときて、DBへの

    アクセスができないという障害です。

     

    最新の完全バックアップファイルから復元し、

    現場はなんとか運用できていますが、

    半日分のデータが吹っ飛んでしまいました。

     

    現在、手元にあるデータは、以下の通りです。

    ・障害前の完全バックアップファイル

    ・障害後のMDFファイル

    ・障害後のLDFファイル

     

    復旧モデルはシンプルです。

    障害直後のトランザクションログをとっていません。

     

    障害後のログからMDFファイルが破損していると考えています。

     

    障害前の完全バックアップファイルを別サーバに復元し、

    障害後のLDFファイルを使って、障害直前の状態まで

    復旧できるのでしょうか?

    できるとすれば、どのような方法でしょうか?

     

    2008年6月19日 0:36

回答

  •  yang-kee さんからの引用

    待ちました…。神様はいるんですね。。。。

    おお!身近にいるんじゃないですか!

    フォーラムに参加してくださいますよう、お伝えください。

     

    masterにカタログさせといて、強引にデータ・ログファイルを入れ替えて、未確認モードを解除して、復旧。

    なるほどぉ。

     

    未確認モードの解除というとsp_resetstatusが思い当たりますが、ご提示のようなやり方があるんですね。

     

     yang-kee さんからの引用

    現在、repair_rebuild にて復旧中であります。

    もう、ここまでくれば復旧できたも同然ですね。

    おめでとうございます!

     

    とてもタメになりました。

    こういうトラブルって、忘れた頃に身に降りかかってきますよね。

    忘れないようにメモらせていただきます。

    2008年6月20日 9:49

すべての返信

  •  yang-kee さんからの引用

    復旧モデルはシンプルです。

    障害直後のトランザクションログをとっていません。

    そうですね。復旧モデルがシンプルなんで、ログバックアップを取ってもしょうがないです。

    紛失分のデータをどうにか救う望みがあるとしたら、

     yang-kee さんからの引用

    ・障害後のMDFファイル

    これをなんとかするしかなさそうですがどうでしょう。

    MDFファイルをデータベース名を変えてアタッチできませんか?

    他にSQL Serverインスタンスがあるのであれば、データベース名を変えなくてもいいですけれども。

     

    確か、LDFファイルを指定しなくてもアタッチできたと思います。

    指定しなければ、勝手に空っぽのLDFを作ってくれたような・・・。

    ちょっと自信ないです。

     

    Books Onlineでエラー番号をみてみると

    インデックス破損が原因のエラー→ログ記録キャンセルでエラー→ログ閉塞

    こんなかんじでしょうか。

    根拠があるわけでもなく、なんとなくですが、ログファイルのほうが重症のような気がするんですよねぇ。

    インデックスの破損なら、DBCC CHECKDBでどうにかなりそうな。

     

     yang-kee さんからの引用

    障害前の完全バックアップファイルを別サーバに復元し、

    障害後のLDFファイルを使って、障害直前の状態まで

    復旧できるのでしょうか?

    やってみなければ分からないと思いますよ。

    ----追記---

    すみません。ちゃんと読んでいませんでした。

    障害前のフルバックアップと障害後のログファイルの組み合わせで、直前まで復旧するのは不可能です。

    それに、復旧モデルがシンプルでのログなんてのは、適当に切り捨てられちゃうし一時領域みたいなものですから。

    2008年6月19日 4:57
  • >かめたろさん
    ご回答いただきまして、ありがとうございます。
    実はいつもかめたろさんのご投稿に助けられております。

     

     かめたろ さんからの引用

    MDFファイルをデータベース名を変えてアタッチできませんか?

    アタッチ時に644のエラーが出ます。

     

     かめたろ さんからの引用

    インデックス破損が原因のエラー→ログ記録キャンセルでエラー→ログ閉塞

    こんなかんじでしょうか。

    まさに、そんな感じです。

     

     かめたろ さんからの引用

    確か、LDFファイルを指定しなくてもアタッチできたと思います。

    シングルアタッチと呼ばれるものでしょうか?
    障害後のMDFファイルをシングルアタッチすると、
    デバイスアクティブ化エラー でLDFを読み込めませんです。
    パスはあってるのですが、、、。
    MDFもLDFも怪しくなってきました。

     

     

     かめたろ さんからの引用

    障害前のフルバックアップと障害後のログファイルの組み合わせで、直前まで復旧するのは不可能です。

    それに、復旧モデルがシンプルでのログなんてのは、適当に切り捨てられちゃうし一時領域みたいなものですから。

    シンプルのログってあっても意味ないですよね(-_-)

     

    せめて壊れたMDFとLDFをSQL Serverが認識できる状態まで
    持って行ければ、必要なデータだけでも吸い出せるかと思うのですが、
    何か手段があるのでしょうか?
    2008年6月19日 7:26
  • 最後の砦である大事なMDF,LDFは、コピーを作ってからいろいろ試してくださいね。

     

     yang-kee さんからの引用

    実はいつもかめたろさんのご投稿に助けられております。

    へへ、そう言っていただけると励みになります。

     

     yang-kee さんからの引用

    障害後のMDFファイルをシングルアタッチすると、
    デバイスアクティブ化エラー でLDFを読み込めませんです。

    データベースをデタッチし、LDFを削除後、アタッチしてみました。

    Code Snippet

    CREATE DATABASE kame3
    ON PRIMARY (FILENAME = 'D:\Program Files\Microsoft SQL Server\MSSQL\Data\kame_Data.MDF')
    FOR ATTACH

    結果

    デバイス アクティブ化エラー。物理ファイル名 'D:\Program Files\Microsoft SQL Server\MSSQL\data\kame_Log.LDF' は正しくありません。
    新しいログ ファイル 'D:\Program Files\Microsoft SQL Server\MSSQL\Data\kame3_log.LDF' が作成されました。

     

    元々ログファイルがあった場所を探しに行きますが、無ければ、通常はログファイルが新規作成されるはずです。

    GUI、sp_attach_dbでアタッチする場合も同様だったと思います。

     

     yang-kee さんからの引用

    アタッチ時に644のエラーが出ます。

    やっぱりMDFファイルが壊れているのでしょうか・・・

     

    Books Onlineのエラー644のページにあるように、ご購入先に連絡する

    SQL Server の識者の登場を待つ

    sql mdf repair なんかで検索するとHITするような、サードパーティ製ツールにすがる

     

    もう私にはこれぐらいしか・・・
    2008年6月19日 8:51
  • >かめたろさん

    いろいろと試していただきましてありがとうございますm(_ _)m
    最後の砦を危うく削除するところでしたよ。

     

     かめたろ さんからの引用

    元々ログファイルがあった場所を探しに行きますが、無ければ、通常はログファイルが新規作成されるはずです。
    GUI、sp_attach_dbでアタッチする場合も同様だったと思います。

    やっぱりMDFファイルが壊れているのでしょうか・・・


    それでも644出ました。MDFファイル破損で間違いなさそうです。

     かめたろ さんからの引用

    SQL Server の識者の登場を待つ

    待ちました…。神様はいるんですね。。。。
    アドバイスいただきまして、以下のような手順を試みています。

     

    (1) Enterprise Manager から、問題のDBと同じ名前、同じデータファイル名、同じログファイル名でDB作成
    (2) SQL Server 停止
    (3) 壊れたMDF、LDFファイルをを、(1)で作成したデータファイル、ログファイルに上書きコピー
    (4) SQL Server 起動

    (5) 以下のクエリで未確認モードを解除

    Code Snippet

    use master
    go
    sp_configure 'allow updates',1
    go

    reconfigure with override
    go

    -- 未確認モード解除
    update master..sysdatabases set status = 16 where name = 'データベース名'
    go

     

     


    (6) 以下のクエリでDB復旧

    Code Snippet
    DBCC DBRECOVER ('データベース名', IGNOREERRORS)
    go

     

     

    この時点でもエラー644が出ましたが、無視。

    (7) SQL Server再起動
    この時点で未確認モードが解除され、Enterprise Managerから見えるようになりました!

    (8) DBCHECK ←今ここ

    Code Snippet
    DBCC CHECKDB ('データベース名')

     

     

    MDFが30GBあるんで、CHECKDB かなり時間かかりそうです(T_T)
    モードって設定できたんだ。。。奥が深すぎて溺れてます。

     

    以上中間報告です。データ抽出できるようになりましたらご報告いたします。

    2008年6月20日 4:21
  • ようやく前述 (8) DBCHECK で整合性チェックができました。

    インデックスエラーはあったもののアロケーションエラーはなかったので、

    一部のデータを除き、ほぼ障害前の状態まで戻りました。

     

    現在、repair_rebuild にて復旧中であります。

    2008年6月20日 8:33
  •  yang-kee さんからの引用

    待ちました…。神様はいるんですね。。。。

    おお!身近にいるんじゃないですか!

    フォーラムに参加してくださいますよう、お伝えください。

     

    masterにカタログさせといて、強引にデータ・ログファイルを入れ替えて、未確認モードを解除して、復旧。

    なるほどぉ。

     

    未確認モードの解除というとsp_resetstatusが思い当たりますが、ご提示のようなやり方があるんですね。

     

     yang-kee さんからの引用

    現在、repair_rebuild にて復旧中であります。

    もう、ここまでくれば復旧できたも同然ですね。

    おめでとうございます!

     

    とてもタメになりました。

    こういうトラブルって、忘れた頃に身に降りかかってきますよね。

    忘れないようにメモらせていただきます。

    2008年6月20日 9:49
  •  かめたろ さんからの引用

    masterにカタログさせといて、強引にデータ・ログファイルを入れ替えて、未確認モードを解除して、復旧。

    SQL Serverを騙すやり方ですよね(笑)

    してやったり!といった感じです。

     

     かめたろ さんからの引用

    未確認モードの解除というとsp_resetstatusが思い当たりますが、ご提示のようなやり方があるんですね。

    こちらの方法は初めて知りました。

    勉強させていただきます。

     

     かめたろ さんからの引用

    こういうトラブルって、忘れた頃に身に降りかかってきますよね。

    本当にそうですよね!

    今回の件で事前、事後対策の大切さが身に染みました。

     

    途中で神様が降りてきたとは言え、かめたろさんのアドバイスがあってここまで来れたと感じております。

     

    奇跡です。

    本当にありがとうございました!

    2008年6月21日 5:28