5

SQL Server 2005 環境でログ配布を使用することを検討しています。アイデアは、セカンダリ サーバーへの頻繁なログ配布を設定することでした。目的: セカンダリ サーバーを使用してレポート クエリを提供し、それによってプライマリ データベース サーバーの負荷を軽減します。

私はsqlservercentral フォーラムのスレッドでこれに出くわしました:

ログ配布を作成する場合、2 つの選択肢があります。norecovery オプションまたはスタンバイ オプションを使用して、ログの復元操作を実行するように構成できます。norecovery オプションを使用する場合、select ステートメントを発行することはできません。norecovery の代わりにスタンバイ オプションを使用すると、データベースで選択クエリを実行できます。ログ ファイルの復元が発生した場合、スタンバイ オプションを使用すると、ユーザーは復元プロセスによって警告なしに追い出されることに注意してください。スタンバイ オプションを使用してログ配布を構成する場合、セカンダリ データベースのすべてのプロセスを強制終了してログの復元を実行するか、データベースが使用されている場合はログの復元を実行しないかの 2 つの選択肢から選択することもできます。もちろん、2 番目のオプションを選択した場合、誰かがデータベースへの接続を開き、それを閉じないと、復元操作が実行されない可能性があります。

だから私の質問は：

  • 上記は本当ですか？私の意図した方法でログ配布を本当に使用できないでしょうか?
  • 本当なら、トランザクション ログの復元中にデータベースに対して SELECT ステートメントを実行できない理由を誰か説明してもらえますか?

編集：

最初の質問は、この serverfault questionの複製です。しかし、2 番目の質問に答えていただきたいと思います。トランザクション ログの復元中に SELECT ステートメントを実行できないのはなぜですか?

4

6 に答える 6

7

トランザクションログの復元中にデータベースに対してSELECTステートメントを実行できない理由を誰かが説明できますか？

簡単に言うと、RESTOREステートメントは、復元されるデータベースを排他的にロックします。

書き込みについては、復元と互換性がない理由を説明する必要がないことを願っています。なぜ読み取りも許可されないのですか？まず第一に、データベースをロックしているセッションが読み取りまたは書き込みを実行するかどうかを知る方法はありません。ただし、可能であっても、復元（ログまたはバックアップ）は、データベース内のデータページを直接更新する操作です。これらの更新は物理的な場所（ページ）に直接送信され、論理階層（metadata-partition-page-row）に従わないため、他のデータリーダーからのインテントロックの可能性を尊重せず、構造を変更する可能性がありますそれらが読まれるとき。ページのnext-prevポインタに続くSELECTテーブルスキャンが混乱状態になり、読み取りが破損します。

于 2009-12-02T16:43:55.577 に答える
7

はい、いいえ。

Log Shippingをデータベースの読み取り専用コピーに構成することで、レポートワークロードをセカンダリサーバーにオフロードできるという点で、やりたいことを正確に実行できます。私は以前にこのタイプのアーキテクチャを何度も設定しましたが、実際に非常にうまく機能します。

注意点は、トランザクションログバックアップファイルの復元を実行するために、問題のデータベースへの他の接続があってはならないということです。したがって、復元プロセスの実行時に失敗してユーザー接続を優先するか、復元を実行するためにすべてのユーザー接続を切断して成功するかの2つの選択肢があります。

復元の頻度にもよりますが、これは必ずしも問題ではありません。たとえば、1時間ごとに1時間の10時に、レポートが失敗する可能性があるという事実をユーザーに教育するだけです。これが発生した場合は、単にレポートを再実行してください。

編集：ビジネスニーズに合った代替アーキテクチャソリューションを評価することもできます。たとえば、データベーススナップショットを使用したトランザクションレプリケーションまたはデータベースミラーリング

于 2009-12-02T13:24:48.960 に答える
3

エンタープライズバージョンを使用している場合は、データベースミラーリングとスナップショットを使用して、データベースの読み取り専用コピーを作成し、レポートなどに使用できます。ミラーリングでは、「内部」で「継続的な」ログ配布を使用します。これは、説明したシナリオで頻繁に使用されます。

于 2009-12-02T14:06:04.513 に答える
2

はい、それは本当だ。

次のことが起こると思います。
トランザクションログが復元されている間、データベースの大部分が更新されているため、データベースはロックされています。
これは、何よりもパフォーマンス上の理由によるものです。

私は2つのオプションを見ることができます：

  1. データベースミラーリングを使用します。
  2. レポートシステムが使用されていないときにのみ発生するようにログ配布をスケジュールします。
于 2009-12-02T13:24:04.037 に答える
0

ピアツーピアレプリケーションは機能しますか。次に、1つのインスタンスでクエリを実行できるため、元のインスタンスの負荷を節約できます。

于 2009-12-02T14:08:20.463 に答える
0

少し混乱しますが、復元の n​​orecovery フラグは、データベースが復旧状態からオンライン状態に移行しないことを意味します。これが、select ステートメントが機能しない理由です。データベースはオフラインです。no-recovery フラグは、データベースをオンラインに戻さずに (DR タイプのシナリオで) 複数のログ ファイルを連続して復元できるようにするためにあります。

ログ配布を望まない場合や不利な点がある場合は、一方向のトランザクション レプリケーションに切り替えることができますが、オーバーヘッドやセットアップは全体的により複雑になります。

于 2009-12-02T13:27:23.423 に答える