ターゲットデータベースが「復元中」の状態になるのは正常なことです
また、データがすべて最新であることを確認するために、いくつかのクエリを実行したいと思います。
一時的に読み取り専用の非復元状態にしてデータを確認し、復元チェーン全体を壊さずに復元に戻すことはできますか?
ありがとう!
ログ配布をSTANDBY
ではなくNORECOVERY
モードに構成することをお勧めします。これにより、レポートなどのためにセカンダリデータベースにクエリを実行できます。
NORECOVERY
モードを使用する場合、セカンダリデータベースはユーザーがアクセスすることを許可しないため、データベースはコミットされていないトランザクションについて心配する必要がありません。ログは、ユーザーがアクセスしたり変更したりすることを心配することなく、現在の状態で復元できます。
STANDBY
モードを使用すると、データベースはNORECOVERY
モードで復元し、開いているトランザクションを確認してロールします。それが完了すると、ユーザーはデータベースにアクセスでき、データベースは読み取り専用モードになります。次のログが復元されると、データベースはすべてのユーザーを切断し、ロールバック/転送プロセスを繰り返してから、再びデータベースを読み取り専用モードにします。泡立て、すすぎ、繰り返します。
トランザクションログの復元と考えてください。各トランザクションログを復元するときは、DBをNORECOVERYのままにして、必要なポイントまで復元するまで追加のログファイルを追加し続けることができるようにします。次に、それをRECOVERYに設定すると、データベースを読み取ることができます。理にかなっていますか?
@DenisTは、「すべてのユーザーを切断する」オプションをチェックして、すべてのユーザーが起動するようにする必要があるという良い点を提起しました。そうでない場合、ログの復元は失敗します。
これに関するすばらしい記事があります http://askmesql.blogspot.se/2011/01/log-shipping-norecovery-vs-standby-mode.html
一時的に読み取り専用の非復元状態にしてデータを確認し、復元チェーン全体を壊さずに復元に戻すことはできますか?
その質問の鍵は、「復元チェーンを壊すこと」です。
番号を照会して検証する場合は、ログ配布のスタンバイモードが最適なオプションです。
SQL Server 2012 Enterprise Editionを使用できる場合は、読み取り専用サブスクライバーの可用性グループを優先してログ配布を中止できます。これにより、要件も達成されます。
私はこれが古い投稿であることを知っていますが、他の誰かがこの質問をした場合に備えてチャイムを鳴らすと思いました。ログチェーンの中断を回避するだけの場合は、復元を実行しているSQLエージェントジョブを無効にします。 .trnファイルはファイルシステムにバックアップされ、待ち時間が発生します(ジョブを無効にした時間の長さによって異なります)が、データベースを解放して、必要なことをすべて実行できます。ジョブを再度有効にすると、ファイルは中断したところから順番に処理されます。