注
この修正プログラムを適用した後、512 バイトの物理セクター サイズを持つすべてのサーバーまたはレプリカでスタートアップ パラメーターとしてトレース フラグ 1800 を有効にし、再起動して、この修正プログラムを正常に動作させる必要があります。
現象
たとえば次のようなシナリオを考えてみます。
Microsoft SQL Serverで AlwaysOn 可用性グループまたは Logshipping 機能を有効にします。
AlwaysOn 可用性グループ (AG) のプライマリ レプリカとセカンダリ レプリカのログ ファイルを格納するディスクのセクター サイズは異なります。 または、Logshipping 環境では、Logshipping プライマリ サーバーと Logshipping セカンダリ サーバーのログ ファイルを格納するディスクのセクター サイズは異なります。 次に例を示します。
- プライマリ レプリカ ログ ファイルは、セクター サイズが 512 バイトのディスクにあります。 ただし、セカンダリ レプリカ ログ ファイルは、セクター サイズが 4 KB (KB) のディスク上にあります。
- プライマリ レプリカ ログ ファイルは、セクター サイズが 512 バイトのオンプレミスのローカル システムにあります。 ただし、セカンダリ レプリカは、セクター サイズが 4 KB (KB) の Windows Azure Storage ディスクにあります。
このシナリオでは、次のエラー メッセージが SQL Server エラー ログに記録されます。 サーバーを再起動する前にセカンダリに適用されていないログがあった場合、再起動後もしばらくエラー メッセージが続く可能性があります。
注
同期 IO にフォールバックする必要がある X のずれしたログ IO がありました。 現在の IO はファイル ...にあります。
さらに、AG または Logshipping 同期は、同期 I/O が原因で非常に遅く実行されます。 セカンダリ レプリカが Windows Azure Storage にある場合、同期プロセスの完了に予想以上に長い時間がかかります。
注 この問題は、4 KB のセクター サイズを持つ新しいドライブと、512 バイトのセクター サイズを持つ古いドライブの両方を使用する場合に発生します。 新しいドライブの詳細については、「SQL Server - 新しいドライブ 4K セクター サイズと SQL Server-記憶域スペース/VHDx と 4K セクター サイズを使用する」を参照してください。
解決策
この問題は、SQL Serverの次の累積的な更新プログラムで最初に修正されました。
SQL Server 2014 /en-us/help/3011055 の累積的な更新プログラム 5
SQL Server 2012 SP2 /en-us/help/3002049 の累積的な更新プログラム 3
SQL Server 2012 SP1 /en-us/help/3002044 の累積的な更新プログラム 13
修正プログラムを適用し、セクター サイズが 512 バイトのディスク上で実行されているすべてのサーバー レプリカでスタートアップ パラメーターとしてトレース フラグ 1800 を有効にすると、次のファイルのサイズが小さく増加することがわかります。
- トランザクション ログ ファイル
- ログ バックアップ
さらに、プライマリ サーバーのSQL Server エラー ログに次のメッセージが記録されていることがわかります。
注
データベース '<database name>' のログの末尾は、4096 バイトの新しいセクター サイズと一致するように書き換えられています
これは、無視しても問題のない情報メッセージです。
SQL Server 用の累積的な更新プログラムについて
SQL Serverの各新しい累積的な更新プログラムには、すべての修正プログラムと、以前の累積的な更新プログラムに含まれていたすべてのセキュリティ修正プログラムが含まれています。 SQL Serverの最新の累積的な更新プログラムを参照してください。
- SQL Server 2014 の最新の累積的な更新プログラム
- SQL Server 2012 SP2 の最新の累積的な更新プログラム
- SQL Server 2012 SP1 の最新の累積的な更新プログラム
回避策
この問題を回避するには、移動先のトランザクション ログ ファイルを、 物理セクターあたりのバイト数 が 512 バイトに設定されているドライブに移動します。
状態
Microsoft は、これが "適用対象" セクションに記載されている Microsoft 製品の問題であることを確認しました。
追加情報
ベスト プラクティスとして、すべてのレプリカ上のすべてのディスク (少なくともログ ファイルをホストするすべてのディスク) のセクター サイズが同じであることを確認してください。 セカンダリに 512 バイトの物理セクターがあり、プライマリのセクター サイズが 4 KB である混合環境では、TF 1800 は、512 バイトの物理セクター サイズを持つすべてのサーバーまたはレプリカのスタートアップ フラグとして使用し、再起動する必要があります。 これにより、進行中のログ作成形式で 4 KB のセクター サイズが使用されます。
より大きなセクター サイズでのSQL Serverのしくみの詳細については、サポート ブログの次の投稿を参照してください。
SQL Server- 記憶域スペース/VHDx と 4K セクター サイズ
Fsutil コマンド プロンプト ユーティリティを使用して、物理セクターあたりのバイト数の値を決定できます。 このパラメーターが出力に表示されない場合は、 KB アーティクル 982018 で指定されている修正プログラムを適用する必要があります。
使用しているドライブの種類を確認するには、次の手順を実行します。
管理者特権を持つコマンド プロンプトから次のコマンドを実行します。
Fsutil fsinfo ntfsinfo x: 注 x プレースホルダーは、確認しているドライブを表します。[ セクターあたりのバイト数] と [ 物理セクターあたりのバイト数] の値を使用して、使用しているドライブの種類を決定します。 これを行うには、次の表を使用します。
"セクターあたりのバイト数" 値 "Bytes per Physical Sector" の値 ドライブの種類 4096 4096 4 K ネイティブ 512 4096 Advanced Format (512E とも呼ばれる) 512 512 512 バイト ネイティブ