アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (Always On 可用性グループ)

AlwaysOn 可用性グループ のアクティブなセカンダリ機能では、1 つ以上のセカンダリ レプリカ (読み取り可能なセカンダリ レプリカ) への読み取り専用アクセスをサポートしています。 読み取り可能なセカンダリ レプリカは、すべてのセカンダリ データベースへの読み取り専用アクセスを許可します。 ただし、読み取り可能なセカンダリ データベースは読み取り専用に設定されません。 これらは動的です。 セカンダリ データベースは、対応するプライマリ データベースに対する変更がそのセカンダリ データベースに適用されると変更されます。 一般的なセカンダリ レプリカでは、持続性のあるメモリ最適化テーブルを含めて、セカンダリ データベースのデータはほぼリアルタイムです。 また、フルテキスト インデックスはセカンダリ データベースと同期されます。 多くの場合、プライマリ データベースと対応するセカンダリ データベース間のデータ待機時間は数秒です。

プライマリ データベースに適用されるセキュリティ設定は、セカンダリ データベースに保存されます。 これには、ユーザー、データベース ロール、およびアプリケーション ロールと、それぞれの権限が含まれます。また、透過的なデータ暗号化 (TDE) も含まれます (プライマリ データベースで有効な場合)。

注意

セカンダリ データベースにデータを書き込むことはできませんが、ユーザー データベースやシステム データベース ( tempdbなど) を含め、セカンダリ レプリカをホストするサーバー インスタンス上の読み書き可能なデータベースには書き込むことができます。

AlwaysOn 可用性グループ また、読み取り可能なセカンダリ レプリカへの読み取りを目的とした接続要求の再ルーティング (読み取り専用ルーティング) もサポートしています。 読み取り専用ルーティングについては、「 リスナーを使用した読み取り専用セカンダリ レプリカ (読み取り専用ルーティング) への接続」を参照してください。

利点

読み取り可能なセカンダリ レプリカに読み取り専用接続を割り当てることには、次の利点があります。

  • プライマリ レプリカを読み取り専用ワークロードから解放することができ、リソースをミッション クリティカルなワークロード用に保護できます。 ミッション クリティカルな読み取りワークロードまたは待機時間が許容できないワークロードは、プライマリ上で実行する必要があります。

  • 読み取り可能なセカンダリ レプリカをホストするシステムに対する投資収益率を向上させます。

また、読み取り可能なセカンダリは、次のように読み取り専用操作に対する堅牢なサポートを提供します。

  • 読み取り可能なセカンダリ データベースの自動一時統計により、ディスク ベース テーブルに対する読み取り専用クエリが最適化されます。 メモリ最適化テーブルの場合、不足している統計は自動的に作成されます。 ただし、古い統計の自動更新はありません。 手動でプライマリ レプリカの統計を更新する必要があります。 詳細については、このトピックの後の「 読み取り専用アクセス データベースの統計」をご覧ください。

  • ディスク ベース テーブルに対する読み取り専用ワークロードは、行のバージョン管理を使用してセカンダリ データベースでのブロック競合を除去します。 他のトランザクション分離レベルが明示的に設定されていても、セカンダリ データベースに対して実行されるすべてのクエリは、スナップショット分離トランザクション レベルに自動的にマップされます。 また、すべてのロック ヒントが無視されます。 これにより、リーダー/ライターの競合が解消されます。

  • 持続性のあるメモリ最適化テーブルに対する読み取り専用ワークロードは、同じトランザクション分離レベル制限で、ネイティブ ストアド プロシージャか SQL 相互運用性を使用して、プライマリ データベースでのアクセスとまったく同じ方法でデータにアクセスします。 プライマリ レプリカで実行されるレポート ワークロードまたは読み取り専用クエリは、セカンダリ レプリカでも変更せずに実行できます。 同様に、セカンダリ レプリカで実行されるレポート ワークロードまたは読み取り専用クエリは、プライマリ レプリカでも変更せずに実行できます。 他のトランザクション分離レベルが明示的に設定されていても、セカンダリ データベースに対して実行されるすべてのクエリは、ディスク ベース テーブルと同様に、スナップショット分離トランザクション レベルに自動的にマップされます。

  • セカンダリ レプリカ上では、ディスク ベースおよびメモリ最適化テーブル型の両方について、テーブル変数に対する DML 操作が許可されます。

可用性グループの前提条件

  • 読み取り可能なセカンダリ レプリカ (必須)

    データベース管理者は、セカンダリ ロールで実行しているときに、すべての接続 (読み取り専用アクセスのみ) または読み取りを目的とした接続のみを許可するように 1 つ以上のレプリカを構成する必要があります。

    注意

    必要に応じて、プライマリ ロールで実行しているときに、読み取り専用接続を除外するように可用性レプリカを構成することもできます。

    詳細については、「可用性レプリカに対するクライアント接続アクセスについて (SQL Server)」を参照してください。

  • 可用性グループ リスナー

    読み取り専用ルーティングをサポートするには、可用性グループに 可用性グループ リスナーが存在する必要があります。 読み取り専用クライアントは、このリスナーに接続要求を送信する必要があります。クライアントの接続文字列では、アプリケーションの目的として "読み取り専用" を指定する必要があります。 つまり、 読み取りを目的とした接続要求であることが必要です。

  • 読み取り専用ルーティング

    読み取り専用ルーティング は、可用性グループ リスナーに送信される読み取りを目的とした受信接続要求を、使用できる読み取り可能なセカンダリ レプリカにルーティングする SQL Server の機能です。 読み取り専用ルーティングの前提条件は次のとおりです。

    • 読み取り専用ルーティングをサポートするには、読み取り可能なセカンダリ レプリカに読み取り専用ルーティングの URL が必要です。 この URL は、ローカル レプリカがセカンダリ ロールで実行されている場合にのみ有効です。 読み取り専用ルーティングの URL は、必要に応じてレプリカごとに指定する必要があります。 各読み取り専用ルーティングの URL は、読み取りを目的とした接続要求を特定の読み取り可能なセカンダリ レプリカにルーティングする際に使用されます。 通常は、読み取り可能なすべてのセカンダリ レプリカに読み取り専用ルーティングの URL が割り当てられます。

    • 可用性レプリカがプライマリ レプリカである場合に読み取り専用ルーティングをサポートするには、その可用性レプリカに読み取り専用ルーティング リストが必要です。 読み取り専用ルーティング リストは、ローカル レプリカがプライマリ ロールで実行されている場合にのみ有効です。 このリストは、必要に応じてレプリカごとに指定する必要があります。 通常、各読み取り専用ルーティング リストには、すべての読み取り専用ルーティングの URL が含まれており、リストの末尾にローカル レプリカの URL が示されています。

      注意

      読み取りを目的とした接続要求は、現在のプライマリ レプリカの読み取り専用ルーティング リスト内の最初に使用できる読み取り可能なセカンダリにルーティングされます。 負荷分散はありません。

    詳細については、このトピックの後の「 可用性グループの読み取り専用ルーティングの構成 (SQL Server)など) を含め、セカンダリ レプリカをホストするサーバー インスタンス上の読み書き可能なデータベースには書き込むことができます。

注意

可用性グループ リスナーと読み取り専用ルーティングの詳細については、「 可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)が存在する必要があります。

制限事項と制約事項

次に示すように、一部の操作は完全にはサポートされていません。

  • 読み取り可能なレプリカは、読み取り用に有効になるとすぐに、セカンダリ データベースへの接続の受け入れを開始できます。 ただし、プライマリ データベースにアクティブなトランザクションが存在する場合、行のバージョンは、対応するセカンダリ データベースで完全に使用可能にはなりません。 セカンダリ レプリカの構成時にプライマリ レプリカ上に存在していたアクティブなトランザクションは、コミットまたはロールバックする必要があります。 このプロセスが完了するまでは、セカンダリ データベースでのトランザクションの分離レベルのマッピングは完了せず、クエリは一時的にブロックされます。

    警告

    長いトランザクションを実行すると、ディスク ベース テーブルおよびメモリ最適化テーブルの両方について、バージョン管理される行の保持数に影響が及びます。

  • メモリ最適化テーブルを含むセカンダリ データベースでは、メモリ最適化テーブルに対して行バージョンが常に生成されますが、セカンダリ レプリカが読み取り用として有効になった際にプライマリ レプリカに存在していたすべてのアクティブなトランザクションが完了するまで、クエリがブロックされます。 これにより、ディスク ベース テーブルとメモリ最適化テーブルの両方が同時にレポート ワークロードおよび読み取り専用クエリに使用できるようになります。

  • 変更の追跡および変更データ キャプチャは、読み取り可能なセカンダリ レプリカに所属するセカンダリ データベースではサポートされません。

    • 変更の追跡は、セカンダリ データベースでは明示的に無効になります。

    • 変更データ キャプチャは、セカンダリ データベースで有効にすることができますが、これはサポートされていません。

  • 読み取り操作はスナップショット分離トランザクション レベルにマップされるため、プライマリ レプリカでのゴースト レコードのクリーンアップが 1 つ以上のセカンダリ レプリカのトランザクションによってブロックされることがあります。 ゴースト レコードのクリーンアップ タスクでは、プライマリ レプリカのディスク ベース テーブルに含まれるゴースト レコードが、セカンダリ レプリカで不要になったときに自動的にクリーンアップされます。 これは、プライマリ レプリカでトランザクションを実行する場合の処理と似ています。 セカンダリ データベースでの極端なケースでは、ゴーストのクリーンアップをブロックしているセカンダリ上の実行時間の長い読み取りクエリを終了する必要があります。 セカンダリ レプリカの接続が切断された場合、またはセカンダリ データベースでデータの移動が中断された場合、ゴーストのクリーンアップがブロックされる可能性があります。 この状態ではログの切り捨ても実行できなくなるので、この状態が続く場合は、セカンダリ データベースを可用性グループから削除することをお勧めします。 メモリ最適化テーブルでは、行バージョンがメモリに保持され、プライマリ レプリカの行バージョンに依存しないため、ゴースト レコードのクリーンアップに関する問題は発生しません。

  • セカンダリ レプリカで引き続き必要なゴースト レコードがファイルに含まれている場合、プライマリ レプリカでのディスク ベース テーブルが含まれているファイルに対する DBCC SHRINKFILE 操作は失敗する可能性があります。

  • SQL Server 2014以降では、ユーザー操作または障害のためにプライマリ レプリカがオフラインになっても、読み取り可能なセカンダリ レプリカをオンラインのままにすることができます。 ただし、この場合、可用性グループ リスナーもオフラインになるため、読み取り専用ルーティング機能しません。 読み取り専用ワークロードにアクセスするには、クライアントは読み取り専用セカンダリ レプリカに直接接続する必要があります。

注意

読み取り可能なセカンダリ レプリカをホストしているサーバー インスタンスで、 sys.dm_db_index_physical_stats 動的管理ビューに対してクエリを実行すると、再実行のブロックという問題が発生する可能性があります。 これは、この動的管理ビューが、指定したユーザー テーブルまたはビューで IS ロックを獲得することが原因です。IS ロックは、そのユーザー テーブルまたはビューの X ロックに関して REDO スレッドの要求をブロックする可能性があります。

パフォーマンスに関する考慮事項

このセクションでは、読み取り可能なセカンダリ データベースのパフォーマンスに関するいくつかの考慮事項について説明します。

データ待機時間

セカンダリ レプリカへの読み取り専用アクセスの実装が役立つのは、読み取り専用ワークロードである程度のデータ待機時間を許容できる場合です。 データ待機時間が許容できない場合は、読み取り専用ワークロードをプライマリ レプリカに対して実行することを検討してください。

プライマリ レプリカは、プライマリ データベースでの変更のログ レコードをセカンダリ レプリカに送信します。 それぞれのセカンダリ データベースで、専用の再実行スレッドがログ レコードに適用されます。 読み取りアクセス セカンダリ データベースでは、その変更を含むログ レコードがセカンダリ データベースに適用され、トランザクションがプライマリ データベース上でコミットされない限り、特定のデータの変更はクエリ結果に反映されません。

つまり、プライマリ レプリカとセカンダリ レプリカの間には待機時間 (通常は数秒程度) が発生します。 ただし、ネットワークの問題のためにスループットが低下するなどの特殊なケースでは、待機時間が長くなることがあります。 I/O ボトルネックが生じた場合やデータの移動が中断された場合は、待機時間が増加します。 データ移動の中断を監視するには、 AlwaysOn ダッシュボード または sys.dm_hadr_database_replica_states 動的管理ビューを使用できます。

メモリ最適化テーブルが含まれるデータベースでのデータ待機時間

読み取りワークロードのためにセカンダリ レプリカのメモリ最適化テーブルにアクセスする場合は、 信頼できるタイムスタンプ を使用して、 信頼できるタイムスタンプより前にコミットされたトランザクションから行を返します。 信頼できるタイムスタンプは、プライマリ レプリカ上で行のガベージ コレクションを実行するためにガベージ コレクション スレッドによって使用される最も古いタイムスタンプ ヒントです。 このタイムスタンプは、前回の更新以降、メモリ最適化テーブル上の DML トランザクションの数が内部しきい値を超えたときに更新されます。 最も古いトランザクションのタイムスタンプがプライマリ レプリカで更新されるたびに、持続性のあるメモリ最適化テーブル上の次の DML トランザクションにより、このタイムスタンプが特殊なログ レコードの一部としてセカンダリ レプリカに送信されます。 セカンダリ レプリカの再実行スレッドにより、このログ レコードの処理の一環として信頼できるタイムスタンプが更新されます。

信頼できるタイムスタンプの待機時間への影響

  • トランザクション スループットが高い OLTP ワークロードの場合、待機時間はディスク ベース テーブルと同様になります。 これは一般的なケースであることが予想されます。

  • 実行時間の長いトランザクションでは、信頼できるタイムスタンプを遅延させます。 スナップショット分離のタイムスタンプは最も古いトランザクションのコミットによって決定されるため、これはディスク ベースのテーブルにアクセスするときと変わりません。

  • 信頼できるタイムスタンプの前回の更新以降のプライマリ レプリカに対するトランザクションによる変更は、信頼できるタイムスタンプが次に転送および更新されるまでセカンダリ レプリカに表示されません。 信頼できるタイムスタンプの更新用の内部しきい値を超える前にプライマリ レプリカのトランザクション アクティビティが停止した場合、信頼できるタイムスタンプに対する前回の更新以降に行われた変更はセカンダリ レプリカに表示されません。 この問題を軽減するには、プライマリ レプリカ上の持続性のあるダミーのメモリ最適化テーブルに対していくつかの DML トランザクションを実行する必要があります。 また、お勧めしませんが、手動チェックポイントを実行して、信頼できるタイムスタンプの配布を強制することもできます。

メモリ最適化テーブルのデータ待機時間の監視およびトラブルシューティング

信頼できるタイムスタンプを調べるには、プライマリ レプリカに対して次のクエリを実行します。

  
SELECT MAX(base_generation)   
   AS max_base_generation  
   FROM sys.dm_db_xtp_gc_cycle_stats  
GO  
  

また、セカンダリ レプリカで使用される信頼できるタイムスタンプを識別するには、アクティブな読み取りワークロードと同時に次のクエリを実行します。

  
SELECT begin_tsn   
   FROM sys.dm_db_xtp_transactions  
GO  
  

読み取り専用ワークロードの影響

セカンダリ レプリカを読み取り専用アクセス用に構成した場合、セカンダリ データベースに対する読み取り専用ワークロードによって (ディスク ベース テーブルに対する読み取り専用ワークロードで大量の I/O が発生する場合には特に)、再実行スレッドの CPU や (ディスク ベース テーブルに対する) I/O などのシステム リソースが消費されます。 すべての行がメモリ内にあるため、メモリ最適化テーブルにアクセスしても IO の影響はありません。

また、セカンダリ レプリカの読み取り専用ワークロードによって、ログ レコードを介して適用されるデータ定義言語 (DDL) による変更がブロックされることもあります。

  • 行のバージョン管理のために、読み取り操作は共有ロックを保持しませんが、スキーマ安定度 (Sch-S) ロックを保持します。これにより、DDL の変更を適用する再実行操作がブロックされることがあります。 DDL 操作にはテーブルおよびビューの ALTER/DROP が含まれますが、ストアド プロシージャの DROP や ALTER は含まれません。 たとえば、プライマリのディスク ベースまたはメモリ最適化テーブルを削除する場合などです。 再実行スレッドは、テーブルを削除するためにログ レコードを処理する場合、テーブルに対する SCH_M ロックを取得する必要があります。また、テーブルにアクセスする実行中のクエリによってブロックされる可能性があります。 この動作は、プライマリ レプリカでも同じです。ただし、テーブルの削除は再実行スレッドではなくユーザー セッションの一部として実行されます。

  • メモリ最適化テーブルに対しては、他にもブロック要素があります。 セカンダリ レプリカで同時実行されているネイティブ ストアド プロシージャがある場合に、ネイティブ ストアド プロシージャを削除すると、再実行スレッドのブロックが発生する可能性があります。 この動作は、プライマリ レプリカでも同じです。ただし、ストアド プロシージャの削除は再実行スレッドではなくユーザー セッションの一部として実行されます。

クエリの作成に関するベスト プラクティスを調べて、セカンダリ データベースでベスト プラクティスを実施してください。 たとえば、データ集計などの実行時間の長いクエリは使用率が低い時間帯にスケジュールするようにします。

注意

セカンダリ レプリカに対するクエリによって再実行スレッドがブロックされると、 sqlserver.lock_redo_blocked XEvent が発生します。

インデックス作成

読み取り可能なセカンダリ レプリカでの読み取り専用ワークロードを最適化するには、セカンダリ データベースのテーブルにインデックスを作成できます。 セカンダリ データベースではスキーマやデータの変更を行えないため、プライマリ データベースでインデックスを作成し、再実行プロセスによってセカンダリ データベースに変更を転送できるようにします。

セカンダリ レプリカでのインデックス使用状況を監視するには、 sys.dm_db_index_usage_stats動的管理ビューの user_seeks列、 user_scans 列、および user_lookups 列を照会します。

読み取り専用アクセス データベースの統計

テーブルとインデックス付きビューの列の統計情報を使用して、クエリ プランを最適化します。 可用性グループの場合、プライマリ データベースで作成および管理される統計は、トランザクション ログ レコードの適用の一部としてセカンダリ データベースに自動的に保存されます。 ただし、セカンダリ データベースの読み取り専用ワークロードについて、プライマリ データベースで作成される統計とは別の統計が必要になることがあります。 しかし、セカンダリ データベースは読み取り専用アクセスに制限されているため、セカンダリ データベースで統計を作成することはできません。

この問題に対処するために、セカンダリ レプリカでは、セカンダリ データベースの一時的な統計を、 tempdbに作成して管理します。 一時的な統計と、(プライマリ データベースで作成されてセカンダリ データベースに保存される) 永続的な統計とを区別するために、サフィックス _readonly_database_statistic が一時的な統計の名前に付加されます。

一時的な統計を作成して更新できるのは、 SQL Server のみです。 ただし、永続的な統計の場合と同じツールを使用すると、一時的な統計を削除したり、そのプロパティを監視したりできます。

  • DROP STATISTICSTransact-SQL ステートメントを使用して一時的な統計を削除します。

  • sys.stats カタログ ビューと sys.stats_columns カタログ ビューを使用して統計を監視します。 sys_stats には、どの統計が一時的または永続的なものかを示すための is_temporary列が含まれています。

プライマリ レプリカまたはセカンダリ レプリカ上のメモリ最適化テーブルでは、自動統計更新がサポートされません。 セカンダリ レプリカに対するクエリ パフォーマンスとプランを監視し、必要であれば、プライマリ レプリカの統計を手動で更新する必要があります。 ただし、不足している統計は、プライマリ レプリカとセカンダリ レプリカについて自動的に作成されます。

SQL Server の統計の詳細については、「 統計」を参照してください。

セカンダリ データベースの古い永続的な統計

SQL Server によって検出されます。 しかし、プライマリ データベースで変更する以外は、永続的な統計に変更を加えることはできません。 クエリの最適化のために、 SQL Server はセカンダリ データベースのディスク ベース テーブルに一時的な統計を作成し、古い永続的な統計の代わりにこの統計を使用します。

永続的な統計がプライマリ データベースで更新されると、統計は自動的にセカンダリ データベースに永続化されます。 次に、 SQL Server は、一時的な統計よりも新しい、更新された永続的な統計を使用します。

可用性グループのフェールオーバーが発生すると、すべてのセカンダリ レプリカで一時的な統計が削除されます。

制限事項と制約事項

  • 一時的な統計は tempdbに格納されるので、 SQL Server サービスを再起動すると、一時的な統計はすべてなくなります。

  • サフィックス _readonly_database_statistic は、 SQL Serverによって生成される統計用に予約されています。 このサフィックスは、プライマリ データベースで統計を作成するときには使用できません。 詳細については、統計に関する記事を参照してください。

セカンダリ レプリカ上でのメモリ最適化テーブルへのアクセス

セカンダリ レプリカでの読み取りワークロードの分離レベルは、プライマリ レプリカで許可されているもののみです。 セカンダリ レプリカでは、分離レベルのマッピングが行われません。 このことにより、プライマリ レプリカで実行できるレポート ワークロードを、セカンダリ レプリカでも変更せずに実行できます。 このため、プライマリ レプリカのレポート ワークロードのセカンダリ レプリカへの移行や、セカンダリ レプリカを使用できない場合にその逆を実行することが、容易に行うことができます。

次のクエリは、プライマリ レプリカで実行できないように、セカンダリ レプリカでも実行できません。

  • メモリ最適化テーブルでのみ実行されるクエリの場合、サポートされている分離レベルは SNAPSHOT、REPEATABLE READ、および SERIALIZABLE のみです。 データベース レベルで MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT オプションを有効にしていなければ、READ UNCOMMITTED または READ COMMITTED 分離レベルのクエリではエラーが返されます。

    SET TRANSACTION ISOLATION LEVEL READ_COMMITTED  
    -- This is not allowed  
    BEGIN TRAN  
    SELECT * FROM t_hk  
    COMMIT  
    
    

    エラー メッセージ:

    Msg 41368, Level 16, State 0, Line 2  
    Accessing memory optimized tables using the CREAD_COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hing, such as WITH (SNAPSHOT).  
    
  • メモリ最適化テーブルでロック ヒントはサポートされません。 たとえば、次のクエリはすべて、エラーが発生し失敗します。 NOLOCK ヒントのみ使用でき、メモリ最適化テーブルとの使用では NOOP になります。

    SELECT * FROM t_hk WITH (PAGLOCK)  
    SELECT * FROM t_hk WITH (READPAST)  
    SELECT * FROM t_hk WITH (ROWLOCK)  
    SELECT * FROM t_hk WITH (READPAST)  
    SELECT * FROM t_hk WITH (TABLOCK)  
    SELECT * FROM t_hk WITH (XLOCK)  
    SELECT * FROM t_hk WITH (UPDLOCK)  
    
  • 複数コンテナーにまたがるトランザクションでは、メモリ最適化テーブルにアクセスするセッション分離レベル "snapshot" を持つトランザクションはサポートされていません。 たとえば、

    SET TRANSACTION ISOLATION LEVEL SNAPSHOT  
    -- This is not allowed  
    BEGIN TRAN  
       SELECT * FROM t_hk  
    COMMIT  
    

    エラー メッセージ:

    Msg 41332, Level 16, State 0, Line 5  
    Memory optimized tables and natively compiled stored procedures cannot be accessed or created when the session TRANSACTION ISOLATION LEVEL is set to SNAPSHOT.  
    

キャパシティ プランニングの注意点

  • ディスク ベース テーブルの場合、読み取り可能なセカンダリ レプリカでは、2 つの理由から tempdb に領域が必要になることがあります。

    • スナップショット分離レベルは行バージョンを tempdbにコピーします。

    • セカンダリ データベースの一時的な統計が tempdbに作成されて管理されます。 一時的な統計により、 tempdbのサイズが多少増加することがあります。 詳細については、このセクションの後の「 読み取り専用アクセス データベースの統計」をご覧ください。

  • 1 つまたは複数のセカンダリ レプリカに対して読み取りアクセスを構成した場合、ディスク ベース テーブルについてセカンダリ データベースに行バージョンのポインターを格納するために、プライマリ データベースでデータ行の削除、変更、または挿入ごとに 14 バイトのオーバーヘッドが生成されます。 この 14 バイトのオーバーヘッドはセカンダリ データベースに適用されます。 14 バイトのオーバーヘッドがデータ行に追加されるため、ページ分割が発生することがあります。

    行バージョンのデータはプライマリ データベースでは生成されません。 代わりに、セカンダリ データベースで行バージョンが生成されます。 ただし、行のバージョン管理により、プライマリ データベースとセカンダリ データベースの両方でデータ ストレージが増加します。

    行バージョン データの追加の有無は、プライマリ データベースのスナップショット分離または READ COMMITTED スナップショット分離 (RCSI) レベル設定によって決まります。 次の表では、ディスク ベース テーブルについて、読み取り可能なセカンダリ データベースでのバージョン管理の動作を設定別に説明します。

    セカンダリ レプリカは読み取り可能かどうか スナップショット分離または RCSI レベルは有効かどうか プライマリ データベース セカンダリ データベース
    いいえ いいえ 行のバージョンまたは 14 バイトのオーバーヘッドなし 行のバージョンまたは 14 バイトのオーバーヘッドなし
    いいえ はい 行のバージョンおよび 14 バイトのオーバーヘッド 行のバージョンはないが、14 バイトのオーバーヘッドあり
    はい いいえ 行のバージョンはないが、14 バイトのオーバーヘッドあり 行のバージョンおよび 14 バイトのオーバーヘッド
    はい はい 行のバージョンおよび 14 バイトのオーバーヘッド 行のバージョンおよび 14 バイトのオーバーヘッド

参照

AlwaysOn 可用性グループ (SQL Server の概要)
可用性レプリカに対するクライアント接続アクセスについて (SQL Server)
可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)
統計