物理、オペレーティング システム、または SQL Server の問題により、データベース ミラーリング セッションでエラーが発生する可能性があります。 データベース ミラーリングでは、Sqlservr.exe が正しく機能しているかどうか、または失敗したかどうかを確認するために依存するコンポーネントは定期的にチェックされません。 ただし、一部の種類の障害では、影響を受けるコンポーネントからエラーが Sqlservr.exeに報告されます。 他のコンポーネントから報告されるエラーを ハード エラーといいます。 それ以外の場合は気付かれないその他のエラーを検出するために、データベース ミラーリングは独自のタイムアウト メカニズムを実装します。 ミラーリング タイムアウトが発生すると、データベース ミラーリングでは、エラーが発生したと見なされ、 ソフト エラーが宣言されます。 ただし、SQL Server インスタンス レベルで発生する一部のエラーでは、ミラーリングがタイムアウトせず、検出されない可能性があります。
重要
ミラー化されたデータベース以外のデータベースのエラーは、データベース ミラーリング セッションでは検出できません。 さらに、データ ディスク障害が原因でデータベースが再起動されない限り、データ ディスクの障害が検出される可能性はほとんどありません。
エラー検出の速度と、したがって、ミラーリング セッションの障害に対する反応時間は、エラーがハードかソフトかに依存します。 ハード エラーの中には、ネットワーク障害など、直ちに報告されるものもあります。 しかし、場合によっては、コンポーネント固有のタイムアウト時間のために報告が遅くなるハード エラーもあります。 ソフト エラーの場合、ミラーリングタイムアウト期間の長さがエラー検出の速度を決定します。 既定では、この時間は 10 秒間です。 これは推奨最小値です。
ハードエラーによる障害
ハード エラーの原因としては、次の条件が考えられます (ただし、これらに限定されません)。
接続またはケーブルの切断
不適切なネットワーク カード
ルーターの変更
ファイアウォールの設定変更
エンドポイントの再構成
トランザクション ログの保存先ドライブの消失
オペレーティング システムまたはプロセスのエラー
たとえば、プリンシパル データベースのログ ドライブが応答しなくなり、失敗した場合、オペレーティング システムは重大なエラーが発生したことを Sqlservr.exe に通知します。
ネットワーク コンポーネントや一部の IO サブシステムなどの一部のコンポーネントには、障害を特定するための独自のタイムアウトがあります。 このようなタイムアウトは、データベース ミラーリングとは無関係であり、データベース ミラーリングに関する知識がなく、その動作を完全に認識していません。 このような場合、タイムアウト遅延により、障害が発生してから、データベース ミラーリングで結果のハード エラーが発生するまでの時間が長くなります。
注
データベース ミラーリングに対して実行されるアクティブなエラー チェックは、ソフト エラーの場合にのみ発生します。 詳細については、このトピックの後半の「ソフト エラーによるエラー」を参照してください。
ネットワーク上で発生しているエラー状態を把握できるように、次のようなイベントが TCP 接続で発生した場合にはどのようなエラー メッセージがポートに送信されるのかを、ネットワーク エンジニアに問い合わせてください。
DNS が機能していません。
ケーブルが接続されていません。
Microsoft Windows に存在します。
ポートを監視しているアプリケーションで障害が発生しています。
Windows ベースのサーバーの名前が変更されています。
Windows ベースのサーバーが再起動されます。
注
ミラーリングでは、サーバーにアクセスするクライアントに固有の問題から保護されません。 たとえば、パブリック ネットワーク アダプターがプリンシパル サーバー インスタンスへのクライアント接続を処理し、プライベート ネットワーク インターフェイス カードがサーバー インスタンス間のすべてのミラーリング トラフィックを処理する場合を考えてみます。 この場合、パブリック ネットワーク アダプターの障害により、クライアントはデータベースにアクセスできなくなりますが、データベースはミラー化され続けます。
ソフトエラーによる障害
ミラーリングのタイムアウトの原因となる可能性がある条件は次のとおりです (ただし、これらに限定されません)。
TCP リンクのタイムアウト、パケットの紛失または破損、不正な順序のパケットなどのネットワーク エラー。
応答していないオペレーティング システム、サーバー、またはデータベース。
Windows サーバーのタイムアウト。
CPU やディスクの過負荷、いっぱいになったトランザクション ログ、メモリやスレッドが不足しているシステムなど、コンピューティング リソースの不足。 このような場合は、タイムアウト期間を長くするか、ワークロードを軽減するか、ハードウェアを交換してワークロードを処理できるようにする必要があります。
ミラーリング Time-Out 仕組み
ソフト エラーはサーバー インスタンスによって直接検出できないため、ソフト エラーによってサーバー インスタンスが無期限に待機する可能性があります。 これを防ぐために、データベース ミラーリングでは、ミラーリング セッション内の各サーバー インスタンスに基づいて独自のタイムアウト メカニズムが実装され、開いている各接続に対して固定間隔で ping が送信されます。
接続を開いたままにするには、サーバー インスタンスは、定義されたタイムアウト期間中に、その接続に対する ping と、もう 1 つの ping を送信するために必要な時間を受け取る必要があります。 タイムアウト時間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスがその接続により通信していることを示します。 ping を受信すると、サーバー インスタンスはその接続のタイムアウト カウンターをリセットします。
タイムアウト期間中に接続で ping が受信されない場合、サーバー インスタンスは接続がタイムアウトしたと見なします。サーバー インスタンスはタイムアウト接続を閉じ、セッションの状態と動作モードに従ってタイムアウト イベントを処理します。
他のサーバーが実際に正しく進行している場合でも、タイムアウトは失敗と見なされます。 セッションのタイムアウト値が短すぎて、いずれかのパートナーの定期的な応答性に対して短すぎる場合は、誤ったエラーが発生する可能性があります。 1 つのサーバー インスタンスが応答時間が非常に遅く、タイムアウト期間が経過する前に ping を受信しない別のサーバー インスタンスに正常に接続すると、誤ったエラーが発生します。
ハイ パフォーマンス モード セッションでは、タイムアウト期間は常に 10 秒です。 これは通常、誤ったエラーを回避するのに十分です。 高い安全性モードのセッションでは、既定のタイムアウト期間は 10 秒ですが、期間は変更できます。 誤認エラーを避けるために、ミラーリングのタイムアウト時間を常に 10 秒以上にすることをお勧めします。
タイムアウト値を変更するには (高い安全性モードのみ)
- ALTER DATABASE <database> SET PARTNER TIMEOUT <integer> ステートメントを使用します。
現在のタイムアウト値を表示するには
- sys.database_mirroring 内の mirroring_connection_timeout をクエリします。
エラーへの応答
エラーの種類に関係なく、エラーを検出するサーバー インスタンスは、インスタンスの役割、セッションの動作モード、およびセッション内の他の接続の状態に基づいて適切に応答します。 パートナーが失われた場合に発生する処理については、「 データベース ミラーリングの動作モード」を参照してください。
こちらもご覧ください
ロールの切り替え中のサービス中断の見積もり (データベース ミラーリング)
データベース ミラーリングの動作モード
データベース ミラーリング セッション中のロールの切り替え (SQL Server)
データベース ミラーリング (SQL Server)