KB3009974 - 修正: SQL Server AG およびログ配布環境で、ディスクのプライマリ レプリカ ログ ファイルとセカンダリ レプリカ ログ ファイルのセクター サイズが異なると、同期が遅くなる

適用先
SQL Server 2014 Developer SQL Server 2014 Enterprise SQL Server 2014 Standard SQL Server 2012 Enterprise SQL Server 2012 Developer SQL Server 2012 Standard SQL Server 2016 Enterprise Core SQL Server 2016 Standard SQL Server 2016 Developer SQL Server 2016 Enterprise SQL Server 2016 Web SQL Server 2016 Express

注

この修正プログラムを適用した後、この修正プログラムが正しく機能するように、物理セクター サイズが 512 バイトのすべてのサーバーまたはレプリカで、スタートアップ パラメータとしてトレース フラグ 1800 を有効にして再起動する必要があります。

現象

たとえば次のようなシナリオを考えてみます。

  • Microsoft SQL Server で AlwaysOn 可用性グループまたはログ配布機能を有効にします。

  • AlwaysOn 可用性グループ (AG) のプライマリ レプリカとセカンダリ レプリカのログ ファイルを格納するディスクのセクター サイズは異なります。 また、ログ配布環境では、ログ配布のプライマリ サーバーとログ配布のセカンダリ サーバーのログ ファイルを格納するディスクのセクター サイズが異なります。 次に例を示します。

    • プライマリ レプリカ ログ ファイルは、セクター サイズが 512 バイトのディスク上にあります。 ただし、セカンダリ レプリカ ログ ファイルは、セクター サイズが 4 キロバイト(KB) のディスク上にあります。
    • プライマリ レプリカ ログ ファイルは、セクター サイズが 512 バイトのオンプレミス ローカル システム上にあります。 ただし、セカンダリ レプリカは、セクター サイズが 4 キロバイト (KB) の Windows Azure Storage ディスク上に配置されます。

このシナリオでは、次のエラー メッセージが SQL Server エラー ログに記録されます。 サーバーの再起動前にセカンダリに適用されなかったログがあった場合、再起動後もしばらくの間、エラー メッセージが続くことがあります。

注

同期 IO にフォールバックする必要がある不整合のログ IO が X 個ありました。 現在の IO がファイルにあります ....

さらに、同期 I/O のために AG またはログ配布の同期の実行速度が非常に遅くなります。 セカンダリ レプリカが Windows Azure ストレージにある場合、同期プロセスの完了に予想以上に時間がかかる。

注: この問題は、4 KB セクター サイズの新しいドライブと 512 バイト セクター サイズの古いドライブの両方を使用する場合に発生します。 新しいドライブの詳細については、「SQL Server - 新しいドライブ 4K セクター サイズとSQL Server 記憶域スペース/VHDx と 4K セクター サイズを使用します。

解決策

この問題は、次の SQL Server の累積的な更新プログラムで最初に修正されました。

SQL Server 2014 用の累積的な更新プログラム 5 /en-us/help/3011055

SQL Server 2012 SP2 の累積的な更新プログラム 3 /en-us/help/3002049

SQL Server 2012 SP1 の累積的な更新プログラム 13 /en-us/help/3002044

修正プログラムを適用し、セクター サイズが 512 バイトのディスク上で実行されているすべてのサーバーのレプリカで、スタートアップ パラメータとしてトレース フラグ 1800 を有効にすると、次のファイルのサイズがわずかに増加します。

  • トランザクション ログ ファイル
  • ログ バックアップ

さらに、プライマリ サーバーの SQL Server エラー ログに次のメッセージが記録されます。

注

データベース '<データベース名>' のログの末尾は、新しいセクター サイズ (4096 バイト) に合わせて書き換えられています

これは、無視しても問題のない情報メッセージです。

SQL Server 用の累積的な更新プログラムについて

SQL Server 用の新しい累積的な更新プログラムには、以前の累積的な更新プログラムに含まれていたすべての修正プログラムとすべてのセキュリティ修正プログラムが含まれています。 SQL Server の最新の累積的な更新プログラムを参照してください。

回避策

この問題を回避するには、コピー先のトランザクション ログ ファイルを、 物理セクターあたりのバイト数 が 512 バイトに設定されているドライブに移動します。

状態

Microsoft は、これが "適用対象" セクションに記載されている Microsoft 製品の問題であることを確認しました。

追加情報

ベスト プラクティスとしては、すべてのレプリカ上のすべてのディスク (少なくともログ ファイルをホストするすべてのディスク) のセクター サイズが同じであることを確認します。 セカンダリの物理セクターが 512 バイト、プライマリのセクター サイズが 4 KB の混在環境では、物理セクター サイズが 512 バイトで再起動されたすべてのサーバーまたはレプリカで、TF 1800 をスタートアップ フラグとして使用する必要があります。 これにより、進行中のログ作成形式で 4 KB のセクター サイズが使用されます。

より大きなセクター サイズでの SQL Server の動作の詳細については、サポート ブログの次の投稿を参照してください。

SQL Server – 記憶域スペース/VHDx および 4K セクター サイズ

Fsutil コマンド プロンプト ユーティリティを使用して、物理セクターあたりのバイト数の値を決定できます。 このパラメーターが出力に表示されない場合は、 KB 記事 982018 で指定された修正プログラムを適用する必要があります。

使用しているドライブの種類を確認するには、次の手順を実行します。

  1. 管理者特権を持つコマンド プロンプトから次のコマンドを実行します。
    Fsutil fsinfo ntfsinfo x: 注: x プレースホルダーは、確認するドライブを表します。

  2. [ Bytes Per Sector ] および [Bytes per Physical Sector ] の値を使用して、使用しているドライブの種類を特定します。 これを行うには、次の表を使用します。

    "Bytes Per Sector" の値 "Bytes per Physical Sector" の値 ドライブの種類
    4096 4096 4 K ネイティブ
    512 4096 Advanced Format (512E とも呼ばれる)
    512 512 512 バイト ネイティブ