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

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

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

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

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

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

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

  • Журнал транзакций заполнен более чем на @autoreseedthreshold %, например, 70. В SQL Server настройте это значение при включении функции, используя sys.sp_change_feed_configure_parameters.
  • Причина повторного использования журнала — REPLICATION.
  • Поскольку ожидание повторного использования журнала REPLICATION может возникать из-за других функций, таких как транзакционная репликация или CDC, автоматическое повторное заполнение выполняется только при sys.databases.is_data_lake_replication_enabled = 1. Это значение задается в Fabric Mirroring.

Diagnose

Чтобы определить, препятствует ли зеркалирование 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 журнал транзакций не может очищаться от зафиксированных транзакций и продолжает заполняться.

Используйте следующий скрипт 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 связана с зеркалированием, выпустите инструкцию CHECKPOINT по исходной базе данных SQL Server, чтобы принудительно освободить лог-пространство. Дополнительные сведения см. в разделе КОНТРОЛЬНАЯ ТОЧКА (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.

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

  • Last updated on