この記事では、SQL Server インスタンスからデータベースをミラーリングするための自動再シードについて説明します。
Important
この機能は プレビュー段階です。
Fabric へのミラーリングの遅延により、トランザクション ログ ファイルの使用量が増加する場合があります。 これは、コミットされた変更がミラー化されたデータベースにレプリケートされるまで、トランザクション ログを切り捨てることができないためです。 トランザクション ログのサイズが定義された上限に達すると、データベースへの書き込みが失敗します。 重要な OLTP トランザクションの書き込みエラーからオペレーショナル データベースを保護するために、トランザクション ログを切り捨てて、Fabric にデータベース ミラーリングを再初期化できるようにする自動解放メカニズムを設定できます。
再シードは、ミラー化されたデータベースから Microsoft Fabric へのトランザクションのフローを停止し、現在の状態でミラーリングを再初期化します。 これには、ミラーリング用に構成されたテーブルの新しい初期スナップショットを生成し、Microsoft Fabric にレプリケートする必要があります。 スナップショットの後、増分変更がレプリケートされます。
再シード中、Microsoft 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
ファブリック ミラーリングがミラー化されたデータベースのログの切り捨てを妨げているかどうかを確認するには、log_reuse_wait_desc システム カタログ ビューの sys.databases 列を調べて、理由がREPLICATIONされているかどうかを確認します。 ログ再利用待機の種類の詳細については、「 トランザクション ログの切り捨てを遅らせる要因」を参照してください。 例えば次が挙げられます。
SELECT [name], log_reuse_wait_desc
FROM sys.databases
WHERE is_data_lake_replication_enabled = 1;
クエリ REPLICATION ログ再利用待機の種類が示されている場合、ファブリック ミラーリングにより、トランザクション ログはコミットされたトランザクションを空にできず、入力を続けます。
次の 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」 を参照してください。
ソース データベースでは、再シードはミラーリングによって保持されているトランザクション ログ領域を解放する必要があります。 ミラーリングが原因で保留状態が引き続きCHECKPOINT場合は、ソース SQL Server データベースに手動REPLICATIONを発行して、ログ領域の解放を強制します。 詳細については、 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」 を参照してください。