none
ディスク構成が違う場合でのログファイルなしのDBのアタッチについて RRS feed

  • 質問

  • ディスク構成が違う場合でのログファイルなしのアタッチについて質問させてください

    DBをデタッチ/アタッチによって、下記のようにソースシステムからターゲットシステムへDBのコピーしようとしています。
    その際、ファイルの転送時間を減らすため、トランザクションログファイルをなしでアタッチしようとしています。

    Database:SQL Server 2000

    [ソースシステム]
    D:\data\dbdata1.mdf
    E:\data\dbdata2.ndf
    F:\log\dblog1.ldf

    [ターゲットシステム] ※Eドライブ、Fドライブはない
    D:\data1\dbdata1.mdf
    D:\data2\dbdata2.ndf
    D:\data1\db_log.LDF ←ログファイルなしのアタッチによる自動生成

    EnterpriseManagerからのGUI操作では問題なくアタッチ可能なのですが、
    クエリからsp_attach_dbをつかってアタッチしようとすると

    Could not open new database 'db'. CREATE DATABASE is aborted.
    Device activation error. The physical file name 'F:\log\dblog1' may be incorrect.


    とメッセージがでて失敗してしまいます。
    通常、ログファイルなしでアタッチした場合、以下のメッセージが出てアタッチ可能です。

    Device activation error. The physical file name 'D:\log\dblog1' may be incorrect.
    New log file 'D:\data\DB_log.LDF' was created

    成功する場合としない場合の違いは、トランザクションログがあったドライブの有無なので、
    それがエラー原因かと考えています。これをクエリによって回避する方法はないでしょうか?

    sp_attach_dbのパラメータを見てみましたが、それらしきパラメータはありませんでした。。

    よろしくお願いいたします。

    2010年4月14日 2:13

回答

  • 最初の質問時にEnterprise ManagerからのGUI操作では成功したと書きましたが、再現しようとしたところ、sp_attach_dbをクエリから実行したときと同様のエラーがでて失敗しました。成功時の担当者が私ではないのではないのですが、もしかしたらログありでアタッチ・デタッチし、ログなしでアタッチしたのかもしれません(この方法ではうまくいきます。)

    またドライブ構成の違うSQL Serverが用意できたので、テスト用のDBを作り、ログなしでアタッチしてみたところ同様に成功しました。
    このことからドライブ構成が違ったことが原因ではなくEMC RMで切り離したDBファイルが何らかの原因があるのではと疑っています。
    これ以上調べるにはEMC RMの仕様を詳しく追わないといけなさそうなので、現状では出来ないということでクローズさせていただこうと思います。

    皆様ご回答ありがとうございました。

    >M_Lewisさん
    SQL Profilerで成功時と失敗時比較したところ、ログを再作成しているところでエラー945が出ていることがわかりました。
    発行SQLには全然差がないようなのでファイル側に原因があるのかもしれません。

    [成功時]
    spid56 Attempting to rebuild primary log file for database <DB名>
    spid56 New log file <Logファイル> built

    [失敗時]
    Error: 945, Severity:14, State: 2

    「ファイルなどのリソースが存在しないため、データベースにアクセスできませんでした。」
    http://technet.microsoft.com/ja-jp/library/aa337443.aspx

    >わざとトランザクション ログなしで運用するのは危ないですよ
    コピー後のシステムのSLAはとても低いのでトラログなしでもアタッチ可能ならと思って方法の一つとして模索していました。
    (仮にアタッチ後にDBが壊れても再度コピーすれば問題なし。)
    私も通常のシステムであれば、当然やりたくはないですね。。

    >naginoさん
    返信ありがとうございます。
    データファイルは複数あるので残念ながらsp_attach_single_file_dbは使えませんでした。
    また、CREATE DATABASE ~ FOR ATTACHについては、sp_attach_dbにて最終的に実行するSQLがCREATE DATABASE...なので同様にアウトでした。

    >コミットされたもののチェックポイントされていない直近のデータの更新が失われますが、それは許容もしくは必ずチェックポイントを実行しているということでしょうか。
    RMはチェックポイント実行していなかったと思うのですが、直近のデータの更新が失われるのは、ソースシステムがあるので今回は許容していました。
    • 回答としてマーク youki_s 2010年4月16日 10:51
    2010年4月16日 10:51

すべての返信

  • > ファイルの転送時間を減らすため、トランザクションログファイルをなしでアタッチしようとしています。

    ソースシステムから "dbdata1.mdf"、"dbdata2.ndf" のみをコピーし、"dblog1.ldf" はコピーせず、ターゲットシステムでは、""dbdata1.mdf"、"dbdata2.ndf" のみをアタッチすることを考えられているのであれば、そのようなことを実施すると、データベースの整合性が保てなくなってしまう可能性があるので、実施するべきではないと思います。

    トランザクションログファイルの物理ファイルサイズが大きいことが問題なのであれば、トランザクションログのバックアップを実施した上で、圧縮(Shrink) を実施することにより、サイズを小さくすることが可能です。

    2010年4月14日 4:41
  • NOBTA さん

    返信ありがとうございます。

    ソースシステムでは、トランザクションログの切り離し後、EMC Replication Manager を使って、日次のバックアップとして複製したデータファイルを用いています。そのため、トラザクションログをコピーしないことによる、ソースとターゲットでのデータの不整合は起きないと考えています。

    システムとしても下記のとおりtechnet(2008のものですが…)にあるので、不整合は発生しないと思いますが、いかがでしょうか?

    読み書き可能なデータベースは、通常、新しい場所にログ ファイルをアタッチできます。ただし、場合によっては、データベースの再アタッチに既存のログ ファイルが必要になります。したがって、デタッチされたログ ファイルなしでデータベースが正常にアタッチされるまで、デタッチされたすべてのログ ファイルを常に保持しておくことが重要です

    (http://technet.microsoft.com/ja-jp/library/ms190794.aspx)

      #ここの記載にある場合によって…というのが気になります。。

    またシュリンクですが、ソースシステムはすでに定常運用されているシステムなので、バックアップの仕組はできれば変えたくないため実施しない方針でいます。

    2010年4月14日 6:08
  • SQL Profiler を使って Enterprise Manager からアタッチしてうまくいく時にどんなコマンドを実行しているか除いてみればどうやってやっているかわかるんじゃないですかね。

    わざとトランザクション ログなしで運用するのは危ないですよ。アタッチ直後にデータベースが使用不可になってもがんばって復旧するなりする覚悟があれば挑戦するのは止めませんが、私なら自分では絶対やりません。


    回答が得られたら、もらった回答の [回答済み] ボタンをクリックしてスレッドを回答済みにしましょう
    2010年4月15日 2:44
  • こんにちは、nagino です。

    単純に sp_attach_single_file_db を使う、というのでは駄目なのでしょうか?
    http://technet.microsoft.com/ja-jp/library/aa259610(SQL.80).aspx
    EMC の Replication Manager を導入するぐらいの規模だと、データファイルが複数ありそうなので、それで無理なのかもしれませんが・・・。

    他には、未確認ですが CREATE DATABASE ~ FOR ATTACH ではどうでしょうか。
    http://technet.microsoft.com/ja-jp/library/aa258257(SQL.80).aspx

    あと、整合性についてはおっしゃる通りなので問題ないと思いますが、Replication Manager を使っていてもトランザクションログを使用しない場合、コミットされたもののチェックポイントされていない直近のデータの更新が失われますが、それは許容もしくは必ずチェックポイントを実行しているということでしょうか。
    (Replication Manager がチェックポイントを実行していましたっけ?)

     


    MCITP(Database Developer/Database Administrator)
    2010年4月15日 13:42
  • 最初の質問時にEnterprise ManagerからのGUI操作では成功したと書きましたが、再現しようとしたところ、sp_attach_dbをクエリから実行したときと同様のエラーがでて失敗しました。成功時の担当者が私ではないのではないのですが、もしかしたらログありでアタッチ・デタッチし、ログなしでアタッチしたのかもしれません(この方法ではうまくいきます。)

    またドライブ構成の違うSQL Serverが用意できたので、テスト用のDBを作り、ログなしでアタッチしてみたところ同様に成功しました。
    このことからドライブ構成が違ったことが原因ではなくEMC RMで切り離したDBファイルが何らかの原因があるのではと疑っています。
    これ以上調べるにはEMC RMの仕様を詳しく追わないといけなさそうなので、現状では出来ないということでクローズさせていただこうと思います。

    皆様ご回答ありがとうございました。

    >M_Lewisさん
    SQL Profilerで成功時と失敗時比較したところ、ログを再作成しているところでエラー945が出ていることがわかりました。
    発行SQLには全然差がないようなのでファイル側に原因があるのかもしれません。

    [成功時]
    spid56 Attempting to rebuild primary log file for database <DB名>
    spid56 New log file <Logファイル> built

    [失敗時]
    Error: 945, Severity:14, State: 2

    「ファイルなどのリソースが存在しないため、データベースにアクセスできませんでした。」
    http://technet.microsoft.com/ja-jp/library/aa337443.aspx

    >わざとトランザクション ログなしで運用するのは危ないですよ
    コピー後のシステムのSLAはとても低いのでトラログなしでもアタッチ可能ならと思って方法の一つとして模索していました。
    (仮にアタッチ後にDBが壊れても再度コピーすれば問題なし。)
    私も通常のシステムであれば、当然やりたくはないですね。。

    >naginoさん
    返信ありがとうございます。
    データファイルは複数あるので残念ながらsp_attach_single_file_dbは使えませんでした。
    また、CREATE DATABASE ~ FOR ATTACHについては、sp_attach_dbにて最終的に実行するSQLがCREATE DATABASE...なので同様にアウトでした。

    >コミットされたもののチェックポイントされていない直近のデータの更新が失われますが、それは許容もしくは必ずチェックポイントを実行しているということでしょうか。
    RMはチェックポイント実行していなかったと思うのですが、直近のデータの更新が失われるのは、ソースシステムがあるので今回は許容していました。
    • 回答としてマーク youki_s 2010年4月16日 10:51
    2010年4月16日 10:51