データベース ミラーリング セッション中のページの自動修復
SQL Server 2008 以降では、ミラー データベースに破損ページがあると、データベース ミラーリング パートナーが、データ ページの読み取りを妨げるエラーを解決して自動的に復旧しようとします。ミラーリング セッションを構成する一方のパートナーは、ページを読み取れない場合、もう一方のパートナーに新しいコピーを要求します。要求が受け入れられ、新しいコピーを取得できた場合は、読み取り不可能なページがそのコピーに置き換えられます。通常、これによりエラーは解決します。
.gif "注意") 注 |
|---|
データベース ミラーリング パートナーによるページの自動修復は、DBCC 修復とは異なります。ページの自動修復では、すべてのデータが保持されます。一方、DBCC REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正すると、一部のページ (データ) が削除されることがあります。 |
ページの自動修復が試行されるエラーの種類
次の表に示すいずれかのエラーが原因でデータ ファイル操作が失敗した場合のみ、そのページにデータベース ミラーリングの自動修復が適用されます。
エラー番号 |
説明 |
ページの自動修復の原因となるインスタンス |
|---|---|---|
オペレーティング システムがデータの巡回冗長検査 (CRC) を実行し、それに失敗した場合のみ処理が行われます。 |
ERROR_CRC。このエラーのオペレーティング システムの値は 23 です。 |
|
論理エラー。 |
破損した書き込みや不適切なページ チェックサムなどの論理データ エラー。 |
|
829 |
ページが復元待ちとしてマークされています。 |
すべて。 |
最近発生した 823 CRC エラーおよび 824 エラーを確認するには、msdb データベースの suspect_pages テーブルを参照してください。
自動的には修復できないページの種類
次のコントロール ページの種類は、データベース ミラーリングでは修復できません。
ファイル ヘッダー ページ (ページ ID 0)。
ページ 9 (データベースのブート ページ)。
アロケーション ページ。これには、グローバル アロケーション マップ (GAM) ページ、共有グローバル アロケーション マップ (SGAM) ページ、およびページ空き容量 (PFS) ページなどが含まれます。
プリンシパル データベースでの I/O エラーの処理
プリンシパル データベースでページの自動修復が試行されるのは、ノードが SYNCHRONIZED 状態にあり、プリンシパル サーバーからミラー サーバーへログ レコードを送信し続けている場合だけです。ページの自動修復が試行される場合の基本的な処理順序を次に示します。
プリンシパル データベースのデータ ページで読み取りエラーが発生すると、プリンシパル サーバーは、該当するエラー状態を使用して suspect_pages テーブルに行を挿入します。次に、プリンシパル サーバーは、ミラー サーバーにそのページのコピーを要求します。この要求では、ページ ID と、現在フラッシュされたログの最後にある LSN を指定します。要求対象のページは、復元待ちとしてマークされます。これにより、ページの自動修復の試行時、このページにはアクセスできなくなります。修復の試行時にこのページにアクセスしようとすると、エラー 829 (復元待ち) が発生して失敗します。
ページ要求を受け取ったミラー サーバーは、まず、その要求で指定されている LSN までログを再実行し、その後、ミラー データベースの該当ページへのアクセスを試みます。該当ページにアクセスできた場合は、そのページのコピーをプリンシパル サーバーに送信します。アクセスできない場合、ミラー サーバーはプリンシパル サーバーにエラーを返します。つまり、ページの自動修復は失敗となります。
プリンシパル サーバーは、要求したページの新しいコピーが含まれている応答を処理します。
ページの自動修復機能によって問題のあるページが修正されると、suspect_pages テーブルで、そのページが復元済み (event_type = 4) としてマークされます。
ページ I/O エラーによって遅延トランザクションが発生した場合は、ページを修復した後で、プリンシパル サーバーがそれらのトランザクションを解決しようとします。
ミラー データベースでの I/O エラーの処理
ミラー データベースで発生したデータ ページの I/O エラーは、次のように処理されます。
ミラー サーバーがログ レコードを再実行している最中に I/O エラーが検出されると、そのミラーリング セッションは SUSPENDED 状態になります。この時点で、ミラー サーバーは、該当するエラー状態を使用して suspect_pages テーブルに行を挿入します。次に、ミラー サーバーは、プリンシパル サーバーにそのページのコピーを要求します。
プリンシパル サーバーは、プリンシパル データベースの該当ページにアクセスを試みます。該当ページにアクセスできた場合は、そのページのコピーをミラー サーバーに送信します。
要求したすべてのページのコピーを受け取った時点で、ミラー サーバーはミラーリング セッションの再開を試行します。ページの自動修復機能によって問題のあるページが修正されると、suspect_pages テーブルで、そのページが復元済み (event_type = 5) としてマークされます。
要求したページをプリンシパル サーバーから受信できない場合は、ページの自動修復の試行が失敗し、ミラーリング セッションは中断されたままになります。ミラーリング セッションを手動で再開すると、破損したページが同期フェーズ時に再びヒットします。
開発者のベスト プラクティス
ページの自動修復は、バックグラウンドで実行される非同期プロセスです。したがって、ミラー化されたデータベースであっても、読み取れないページを要求した場合はデータベース操作に失敗し、その原因を示すエラー コードが返されます。ミラー化されたデータベースのアプリケーションを開発するときは、失敗した操作を例外として処理できるようにする必要があります。SQL Server エラー コードが 823、824、または 829 のときは、その操作を後で再試行してください。