次の例のミラーリングを理解するのに助けが必要です。
FL のプライマリ サーバー ドイツのミラー サーバー
私のアプリケーションは、FL システムのテーブルへの挿入を行っています
ケース 1 : ミラー サーバーがダウンしています -- ネットワークの問題 -- 挿入はプリンシパルのトランザクション ログに書き込まれると想定しています -- ディスクにはコミットされません 誰かが FL データベースにクエリを実行しようとするとどうなりますか。彼らは最後の取引[挿入]を見ますか? SQL サーバーがクエリを実行するとき、DB と tlog の両方を調べますか?
ケース 2: ミラー サーバーが 2 日間ダウンした場合。その後、トランザクション ログは成長し続けると思います。これがアプリケーションの応答時間にどのように影響するか説明できますか?
ケース 3 : ミラーがしばらく (1 週間) ダウンしている場合。ミラーリングを壊した方がいいですか？また、これは、ミラーリングを再構成するために、DB の完全バックアップを再度取得したことを意味しますか?
ミラーリングの種類が指定されていないため、自動フェイルオーバーで安全性が高いと仮定します
ケース 1 :プリンシパルは「切断」状態になります。トランザクションはプリンシパルのディスクにコミットされますが、ミラーにはコミットされません (明らかに)。トランザクションはログの「アクティブ」部分に残り、バックアップされません。つまり、トランザクション ログが大きくなり、sys.databases のlog_reuse_wait_desc 列が MIRRORING になります。FL データベースはオフラインのままで、切断された状態になります。FORCE_SERVICE_ALLOW_DATA_LOSSミラーを壊した時点でオンラインにするようなものを使用しない限り、クエリを実行することはできません (ただし、プリンシパルはまだそれを認識しておらず、ログを保持し続けます)
ケース 2:トランザクション ログは、autogrow の設定に従って増加し続けます。これは自動拡張ログの通常のケースです。自動拡張を取得するたびにオーバーヘッドが発生し、多くの仮想ログ ファイルが作成される可能性があります。自動拡張を適切な値に設定して、50MB 単位で拡張しないようにすることをお勧めします。
ケース 3: ミラーリングを再開するためにサイト間でコピーする必要がある完全なデータベース バックアップのサイズと比較して、変更したデータの変更量によって異なります。SQL Server 2008 には、ログ圧縮などのオプションがあります。これは、より少ない帯域幅でより多くのトランザクションを送信できることを意味します (使用している場合)。