从 Azure SQL 数据库自动为 Fabric 镜像数据库重新分配

2025-10-17

本文介绍 Azure SQL 数据库中用于镜像过程的自动重新初始化。

在某些情况下，如果镜像到 Fabric 时存在延迟，则事务日志文件使用量可能会增加。在提交更改复制到镜像数据库之前，无法截断事务日志。事务日志大小达到其最大定义限制后，写入数据库会失败。为了保护操作数据库免受关键 OLTP 事务的写入失败的影响，可以设置自动重播机制，使事务日志能够被截断，并将数据库镜像重新初始化以连接到 Fabric。

自动配置的功能已启用，无法在 Azure SQL 数据库和 Azure SQL 托管实例中对其进行管理或禁用。

停止从镜像数据库向 Microsoft Fabric 的事务流，并以当前状态重新初始化镜像功能。重新生成涉及为镜像配置的表创建新的初始快照，并将其复制到 Microsoft Fabric。快照后，将同步增量更改。

在 Azure SQL 数据库和 Azure SQL 托管实例中，重新分配可以在数据库级别或表级别发生。

数据库级别重新分配： 为启用镜像的数据库中的所有表停止正在进行的数据镜像，事务日志将被截断，并且通过重新发布为镜像启用的所有表的初始快照重新初始化数据库。然后，增量更改将继续复制。
表级重播种： 仅对需要重播种的表停止正在进行的数据镜像。通过重新发布初始快照来为受影响的表重新初始化镜像过程。然后，增量更改将继续复制。

数据库级自动重新分配的原因

在数据库级别重新分配可确保事务日志不会增长到最大大小，从而保护数据库写入可用性。最大事务日志大小基于 Azure SQL 数据库或 Azure SQL 托管实例的数据库服务级别目标。启用了 Fabric 镜像的数据库的事务日志使用量可能会继续增加，从而导致日志截断被延迟。事务日志大小达到最大定义的限制后，写入数据库会失败。

由于镜像阻止日志截断可能由多种原因引起：
- 源到镜像数据库的数据镜像延迟会阻止从事务日志中截断待复制的事务。
- 长时间运行的复制事务由于等待复制而无法截断，因此占用了事务日志空间。
- 写入 OneLake 的着陆区时发生的持续性错误会阻止复制。
  - 例如，由于没有足够的权限。镜像到 Fabric 使用系统分配的托管标识写入 One Lake 中的登陆区域。如果未正确配置，则事务复制可能会重复失败。
为了防范这种情况，当使用的日志空间超过已配置总日志空间一定阈值时，镜像会触发整个数据库的自动重新填充。
如果 Fabric 容量已暂停并恢复，镜像数据库状态将保持暂停。因此，源中所做的更改不会复制到 OneLake。若要恢复镜像，请转到 Fabric 门户中的镜像数据库，选择 “恢复复制”。镜像从暂停位置继续。

如果 Fabric 容量长时间保持暂停状态，镜像可能无法从停止点恢复，并且将从头开始重新分配数据。这是因为长时间暂停数据库镜像可能会导致源数据库事务日志的使用量增长，并阻止日志截断。恢复镜像后，如果使用的事务日志文件空间接近完整，则会启动数据库重新分配以释放保留的日志空间。

表级自动重新分配的原因

在为镜像启用的源表上发生架构更改时，Fabric 中这些镜像表的架构不再与源匹配。这可能是由于源上的以下 ALTER TABLE 数据定义语言（DDL） T-SQL 语句导致的：

添加/删除/更改/重命名列
截短/重命名表
添加非聚集主键

仅针对受影响的表触发 Reseed。

诊断

若要确定 Fabric 镜像是否阻止镜像数据库的日志截断，请检查log_reuse_wait_desc系统目录视图中的sys.databases列以查看原因是否为REPLICATION。有关日志重用等待类型的详细信息，请参阅延迟事务日志截断的因素。例如：

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

如果查询显示 REPLICATION 日志重用等待类型，则由于 Fabric 镜像，事务日志无法清除已提交的事务，并且会继续增加。有关 Azure SQL 数据库中日志使用情况的其他故障排除，请参阅排查 Azure SQL 数据库的事务日志错误。

使用以下 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];

在重置种子期间

在重新分配期间，Microsoft Fabric 中的镜像数据库项可用，但在重新分配完成之前不会收到增量更改。在reseed_state中的sys.sp_help_change_feed_settings列指示重新植入状态。

在 Fabric 镜像中，监视源 SQL 数据库事务日志。仅在满足以下三个条件时才会触发自动重播种：

事务日志已满超过@autoreseedthreshold百分比，例如70。
日志重用原因是 REPLICATION。
REPLICATION由于日志重用等待可能会引发其他功能（如事务复制或 CDC），因此仅在 = 1 时sys.databases.is_data_lake_replication_enabled自动执行。此值由 Fabric Mirroring 配置。

检查是否已触发数据库级重排

如果正在重新播种整个数据库，请检查是否符合以下条件。

reseed_state 在源 SQL 数据库上的系统存储过程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。

检查是否已触发表级重排

对于任何要重置的表，请在7中查找state列的sys.sp_help_change_feed_table值。

有关详细信息，请参阅 sys.sp_help_change_feed_table。

排查 Azure SQL 数据库中的 Fabric 镜像数据库问题

反馈

此页面是否有帮助？