この記事では、SQL Server インスタンスからデータベースをミラーリングするための自動再シードについて説明します。
特定の状況では、Microsoft Fabricへのミラーリングの遅延がトランザクションログファイルの使用増加につながることがあります。 この増加は、コミットされた変更がミラーされたデータベースに複製されるまでトランザクションログを切り捨てられないためです。 トランザクションログサイズが定義された最大限度に達すると、データベースへの書き込みは失敗します。 重要な OLTP トランザクションの書き込みエラーからオペレーショナル データベースを保護するために、トランザクション ログを切り捨てて、Fabric にデータベース ミラーリングを再初期化できるようにする自動解放メカニズムを設定できます。
リシードはミラーされたデータベースからFabricへのトランザクションの流れを止め、現在の状態でミラーリングを再初期化します。 このプロセスは、ミラーリング用に設定されたテーブルの新しい初期スナップショットを生成し、そのスナップショットをFabricに複製することを含みます。 スナップショット取得後、増分変更がレプリケートされます。
再シード中は、Fabric内のミラー化されたデータベースアイテムが利用可能ですが、再シードが完了するまでインクリメンタルな変更は受けません。
reseed_stateのsys.sp_help_change_feed_settings列は、再シード状態を示します。
SQL Server 2025では自動再シード機能はデフォルトで無効化されています。 有効化するには 「自動再シードを有効にする」を参照してください。 Azure SQL DatabaseおよびAzure SQL Managed Instanceでは、この機能が有効化されており、管理・無効化はできません。
ファブリック ミラーリングでは、ソース SQL データベーストランザクション ログが監視されます。 オートリシードは以下の3つの条件が満たされた場合にのみトリガーされます。
- トランザクション ログの使用率は
@autoreseedthreshold% を超えています。たとえば、70です。 SQL Serverでは、機能を有効にする際にsys.sp_change_feed_configure_parametersを使ってこの値を設定してください。 - ログの再利用の理由は
REPLICATION。 - トランザクション レプリケーションや CDC などの他の機能に対して
REPLICATIONログ再利用待機を発生させることができます。そのため、自動実行は、sys.databases.is_data_lake_replication_enabled= 1 の場合にのみ発生します。 この値は、ファブリック ミラーリングによって構成されます。
Diagnose
Fabric ミラーリングがミラーリングされたデータベースのログの切り捨てを妨げているかどうかを特定するには、sys.databases システム カタログ ビューの log_reuse_wait_desc 列を確認し、その理由が REPLICATION であるかどうかを判断してください。 ログ再利用待機の種類の詳細については、「 トランザクション ログの切り捨てを遅らせる要因」を参照してください。 例えば次が挙げられます。
SELECT [name], log_reuse_wait_desc
FROM sys.databases
WHERE is_data_lake_replication_enabled = 1;
クエリに REPLICATIONログ再利用待機タイプが表示される場合は、Fabric ミラーリングが原因で、トランザクション ログからコミット済みトランザクションを削除できず、ログが増え続けます。
次の T-SQL スクリプトを使用して、ログ領域の合計、および現在のログの使用状況と使用可能な領域を確認します。
USE <Mirrored database name>
GO
--initialize variables
DECLARE @total_log_size bigint = 0;
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;
--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
max_size*1.0*8192/1024/1024 AS [max size in MB],
growth
FROM sys.database_files
WHERE TYPE = 1
OPEN sdf
FETCH NEXT FROM sdf INTO @size,
@max_size,
@growth
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @total_log_size = @total_log_size +
CASE @growth
WHEN 0 THEN @size
ELSE @max_size
END
FETCH NEXT FROM sdf INTO @size,
@max_size,
@growth
END
CLOSE sdf;
DEALLOCATE sdf;
--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;
-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
@total_log_size AS [total log space in MB],
@used_log_size/@total_log_size AS [used log space in percentage];
自動再シードを有効にする
前のT-SQLスクリプトで返されるログ使用量がほぼ満杯(例えば70%を超える)場合は、 sys.sp_change_feed_configure_parameters システムのストアドプロシージャを使ってミラードデータベースを自動再シードを有効にすることを検討してください。 たとえば、自動応答動作を有効にするには、次のようにします。
USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
@autoreseed = 1
, @autoreseedthreshold = 70;
詳細については、「sys.sp_change_feed_configure_parameters」 を参照してください。
ソースデータベースでは、再シードプロセスがミラーリングで保留されたトランザクションログ空間を解放するべきです。 ミラーリングによる遅延原因が依然としてREPLICATIONする場合は、ソースSQL Serverデータベースに手動CHECKPOINTを発行し、ログ空間の解放を強制してください。 詳細については、 CHECKPOINT (Transact-SQL) を参照してください。
手動で再初期化
自動再シードを有効にする前にその影響を把握できるよう、以下のストアド プロシージャを使用して、特定のデータベースに対する手動再シードをテストすることをお勧めします。
USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;
詳細については、「 sys.sp_change_feed_reseed_db_init」を参照してください。
再シードがトリガーされたかどうかを確認する
ソースSQLデータベースのシステムストアドプロシージャ
reseed_stateのsys.sp_help_change_feed_settings列は現在の再シード状態を示します。-
0= 標準。 -
1= データベースが Fabric に再初期化するプロセスを開始しました。 過渡状態。-
2= データベースはFabricに再初期化し、レプリケーションの再起動を待っています。 遷移中の状態。 複製が確立されると、再シード状態は0に変わります。
-
詳細については、「 sys.sp_help_change_feed_settings」を参照してください。
-
データベースでミラーリングが有効になっているすべてのテーブルは、
7のstate列に対してsys.sp_help_change_feed_tableの値を持っています。詳細については、「sys.sp_help_change_feed_table」 を参照してください。