Настройка автоматического повторного изменения для зеркальных баз данных Fabric из SQL Server

В этой статье рассматривается автоматическое восстановление для зеркального копирования базы данных из экземпляра SQL Server.

Существуют определенные ситуации, когда задержки зеркального отображения в Fabric могут привести к увеличению использования файла журнала транзакций. Это связано с тем, что журнал транзакций не может быть усечен до тех пор, пока не были реплицированы зафиксированные изменения в зеркальную базу данных. После достижения максимального заданного предельного размера журнала транзакций запись в базу данных завершается ошибкой. Чтобы защитить операционные базы данных от сбоев записи для критически важных транзакций OLTP, можно настроить автоматический механизм, позволяющий журналу транзакций быть усеченным и повторно инициализировать зеркальное отображение базы данных в Fabric.

Повторное изменение останавливает поток транзакций в Microsoft Fabric из зеркальной базы данных и повторно инициализирует зеркальное отображение в настоящем состоянии. Это включает создание нового начального моментального снимка таблиц, настроенных для зеркального отображения, и репликацию этих таблиц в Microsoft Fabric. После создания моментального снимка добавочные изменения реплицируются.

Во время повторного изменения зеркальный элемент базы данных в Microsoft Fabric доступен, но не будет получать добавочные изменения до завершения повторного изменения. Столбец reseed_state в sys.sp_help_change_feed_settings столбце указывает состояние повторного изменения.

Функция автоматического пересева отключена по умолчанию в SQL Server 2025, чтобы включить, см. Включение автоматического пересева. Функция автоматического использования включена и не может быть управляемой или отключенной в Базе данных SQL Azure и Управляемом экземпляре SQL Azure.

В зеркальном отображении структуры отслеживается журнал транзакций базы данных SQL источника. Автоматический запуск активируется только в том случае, если выполняются следующие три условия:

• Журнал транзакций превышает @autoreseedthreshold процент полного, например 70. В SQL Server настройте это значение при включении функции с sys.sp_change_feed_configure_parameters.
• Причина повторного использования журнала .REPLICATION
• Так как ожидание REPLICATION повторного использования журнала может быть вызвано для других функций, таких как репликация транзакций или CDC, автоматически выполняется только в том случае, если 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 вызвана зеркальным отображением. Дополнительные сведения см. в разделе КОНТРОЛЬНАЯ ТОЧКА (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.

Проверьте, активируется ли повторное изменение

• Столбец reseed_state в системной хранимой процедуре sys.sp_help_change_feed_settings в исходной базе данных SQL указывает текущее состояние повторного изменения.

  • 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.

Связанный контент

• Устранение неполадок зеркальных баз данных Fabric из SQL Server
• Оптимизация производительности зеркальных баз данных из SQL Server