次の方法で共有

SQL Server からミラー化されたデータベースのパフォーマンスを最適化する

この記事には、Microsoft Fabric の SQL Server からのソース データベースとミラー化されたデータベースのパフォーマンスを最適化するための重要な手順が含まれています。

Important

この機能は プレビュー段階です。

スキャンのパフォーマンスを制御する

データベース内のテーブルでミラーリングが有効になっている場合、スキャン プロセスでは、トランザクション ログを収集することによって定期的に変更がキャプチャされます。 このプロセスは、最も古い未更新のコミット済みトランザクションの LSN から始まり、次の N-1 レプリケート トランザクションをスキャンします。N は、@maxtransの sys.sp_change_feed_configure_parameters パラメーターを使用して指定されたトランザクションの数を表します。 maxtrans パラメーター値は、各スキャン サイクルで処理するトランザクションの最大数を示します。

スキャンの待ち時間が非常に長い場合は、 maxtrans 値を大きくすると便利ですが、レプリケートされるトランザクションが少ない場合や比較的大きなトランザクションが含まれる場合は、 maxtrans 設定を低くすることをお勧めします。 動的最大トランザクション機能は、ログの使用状況、スキャンの待機時間、ワークロードなどの他の要因に基づいて、各スキャン中に最適な maxtrans 値を自動的に決定することで、このプロセスを効率化します。 dynamicmaxtrans変更フィード設定が有効になっている場合、Fabric は maxtrans パラメーターを動的に調整し、最適なスキャン パフォーマンスを確保します。

sys.sp_help_change_feed_settingsを使用して動的最大トランザクション機能の設定を確認するか、repl_logscan_dynamic_maxtrans拡張イベントを使用して各スキャンのランタイム値を監視します。

動的最大トランザクション機能を有効にするには、 @dynamicmaxtrans を 1 に設定します。 例えば次が挙げられます。

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1;

動的最大トランザクション機能の最大値と下限を変更するには、それぞれ @maxtrans と @dynamicmaxtranslowerbound を使用します。 例えば次が挙げられます。

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1
, @dynamicmaxtranslowerbound=5
, @maxtrans=5000;

動的な最大トランザクションの設定に関する考慮事項

SQL Server 2025 (プレビュー) では、動的最大トランザクション機能が既定で有効になっています。 動的最大トランザクション機能は有効になっており、Azure SQL Database と Azure SQL Managed Instance では管理または無効にできません。

動的 maxtrans が有効になっている場合、ミラーリングはログ スキャン フェーズ中に最大 10,000 トランザクション (既定) または構成された最大トランザクション値を処理します。 このフェーズの実行時間が長くなりすぎないように、3 分間のタイムアウトが適用されます。 タイムアウトの期限が切れる前に処理されたトランザクションはすべてミラー化されたデータベースに発行され、残りのトランザクションは次のスキャン中にキャプチャされます。

動的最大トランザクション機能の最適な値は、ワークロード、待機時間、およびその他の要因によって異なります。 待機時間が必要以上で、各バッチの transaction_count が下限設定 (既定では 200) より大きい場合は、動的 maxtrans 機能を有効にすることを検討してください。 これを監視するには、latencyのsys.dm_change_feed_log_scan_sessions列を使用するか、拡張イベント repl_logscan_dynamic_maxtransを使用して、current_maxtransがmaxtrans セットに到達しているかどうかを確認します。 待機時間が長い場合は、sys.sp_help_change_feed_settingsmaxtransの上限を増やすことを検討してください。

タイムアウトが頻繁に発生しているかどうかを監視するには、拡張イベント repl_logscan_dynamic_maxtrans を使用します。 prev_phase2_scan_termination_reasonフィールドには、スキャンからのタイムアウトが発生したときにLogScanTerminationReason_MaxScanDurationReached値が設定されます。 タイムアウトが頻繁に発生する場合は、 maxtrans を下げるか、 sys.sp_help_change_feed_settings を使用して動的 maxtrans を無効にすることを検討してください。

SQL Server ミラーリングのリソース ガバナー

SQL Server 2025 (プレビュー) では、SQL Server 上のファブリック ミラーリングのワークロードを管理および上限とするリソース ガバナー プールを作成できます。 リソース ガバナーを使用して、データベース エンジンのリソース消費を管理し、ユーザー ワークロードのポリシーを適用できます。 リソース ガバナーを使用すると、ユーザー クエリ ワークロードで使用できる CPU、メモリ、物理 I/O の量など、さまざまなサーバー リソースを予約または制限できます。 これにより、ファブリック ミラーリングの変更フィード データ収集による負荷からプライマリ ビジネス ワークロードを保護できます。 詳細については、「 リソース ガバナー」を参照してください。

SQL Server 2025 for Fabric ミラーリングのワークロード グループの構成を開始するには、次のサンプル スクリプトと手順を使用します。

  • RESOURCE POOLの任意の名前を選択できます。
  • このサンプル スクリプトでは、ファブリック ミラーリングを可能にするために、CPU の必要な割合の上限を構成します。 次の例では、50% の 50 を使用しています。 この値は、CPU の競合が発生したときにリソース プール内のすべての要求が受信できる最大平均 CPU 帯域幅です。 ファブリック ミラーリングをさらに制限するには、小さい値を使用します。
  • WORKLOAD GROUP名は、サンプル スクリプトの値と一致する必要があります。 各ワークロード グループは、ミラーリングの特定のフェーズ用です。 各ワークロード グループは、リソース ガバナー プールとワークロードの計画方法に応じて、同じプールまたは異なるプールに配置できます。
  • SQL Server インスタンスで初めてリソース ガバナーを構成する前に、 リソース ガバナーのドキュメント、例、ベスト プラクティスを慎重に確認してください。
--Create resource pool for Fabric mirroring
CREATE RESOURCE POOL [ChangeFeedPool] WITH (MAX_CPU_PERCENT = 50);

--Create workload groups for Fabric mirroring. Do not modify.
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_snapshot_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_capture_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_publish_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_commit_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_notification_group] USING [ChangeFeedPool];

通常どおり、変更を適用してリソース ガバナーを有効にするには:

ALTER RESOURCE GOVERNOR RECONFIGURE

関連コンテンツ

  • Last updated on