Автоматическое повторное восстановление для зеркальных баз данных Fabric из Управляемого экземпляра Azure SQL

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

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

Для защиты операционных баз данных от сбоев записи для критически важных транзакций OLTP, мирроринг в Базе данных Azure SQL и Управляемом экземпляре Azure SQL использует возможность авторесида, которая позволяет журналу транзакций быть усечённым и инициализировать мирроринг базы данных на Fabric.

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

В Базе данных SQL Azure и Управляемом экземпляре SQL Azure можно повторно выполнить на уровне базы данных или на уровне таблицы.

Изменен уровень базы данных: Непрерывное зеркальное отображение данных останавливается для всех таблиц в базе данных, которые включены для зеркального отображения, журнал транзакций усечен, а зеркальное отображение повторно инициализировано для базы данных, повторно публикуя начальный снимок всех таблиц, включенных для зеркального отображения. Затем добавочные изменения возобновляют непрерывную репликацию.
Пересев уровня таблицы: Непрерывное зеркальное отображение данных останавливается только для таблиц, требующих пересева. Отражение повторно инициализируется для затронутых таблиц через повторную публикацию первоначального снимка. Затем добавочные изменения возобновляют непрерывную репликацию.

Причины автоматического повторного изменения на уровне базы данных

Повторное изменение на уровне базы данных защищает доступность записи базы данных, гарантируя, что журнал транзакций не увеличивается до максимального размера. Максимальный размер журнала транзакций основан на целевом уровне службы базы данных Базы данных SQL Azure или Управляемом экземпляре SQL Azure. Использование журнала транзакций для базы данных, включенной для зеркального отображения Fabric, может продолжать расти и препятствовать усечению журнала. После того как размер журнала транзакций достигает максимального предела, запись в базу данных завершается неудачей.

Предотвращение усечения журнала из-за зеркалирования может происходить по нескольким причинам:
- Задержка при зеркальном отображении данных из источника в зеркальную базу данных предотвращает усечение транзакций, ожидающих репликации из журнала транзакций.
- Длительные реплицированные транзакции, ожидающие репликацию, не могут быть усечены, что занимает пространство журнала транзакций.
- Постоянные ошибки записи в зону приземления в OneLake могут предотвратить репликацию.
  - Этот сценарий может быть вызван недостаточными разрешениями. Зеркалирование в Fabric использует Управляемое удостоверение, назначаемое системой (SAMI), или Управляемое удостоверение, назначаемое пользователем (UAMI) для записи в зону назначения в One Lake. Если это не настроено правильно, репликация транзакций может многократно завершиться ошибкой.
    
    Замечание
    
    Поддержка управляемой идентичности, назначаемой пользователем (UAMI), сейчас представлена в предварительной версии.
Если емкость Fabric приостановлена и возобновляется, состояние зеркальной базы данных остается приостановленным. В результате изменения, внесенные в источник, не реплицируются в OneLake. Чтобы возобновить зеркальное отображение, перейдите в зеркальную базу данных на портале Fabric, выберите "Возобновить репликацию". Зеркальное отображение продолжается, откуда она была приостановлена.

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

Причины автоматического повторного изменения на уровне таблицы

При изменении схемы в исходных таблицах, включенных для зеркального отображения, схема для этих зеркальных таблиц в Fabric больше не соответствует источнику. Это может произойти из-за следующих ALTER TABLE инструкций языка определения данных (DDL) T-SQL в источнике:

Добавить/удалить/изменить/переименовать столбец
Усечение/переименование таблицы
Добавление некластеризованного первичного ключа

Повторная инициализация выполняется только для затронутых таблиц.

Шаг

Чтобы определить, предотвращает ли зеркальное отображение Структуры для зеркальной базы данных журналов, проверьте log_reuse_wait_desc столбец в sys.databases представлении системного каталога, чтобы узнать, является REPLICATIONли причина. Дополнительные сведения о типах ожидания повторного использования журнала см. в разделе "Факторы, которые задерживают усечение журнала транзакций". Рассмотрим пример.

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

Если запрос отображает REPLICATION тип ожидания повторного использования журнала, то из-за зеркального отображения журнала транзакций не удается очистить зафиксированные транзакции и продолжить заполнение. Дополнительные сведения об устранении неполадок с использованием журналов в Базе данных SQL Azure см. в статье "Устранение ошибок журнала транзакций с помощью базы данных SQL Azure".

Используйте следующий скрипт 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 столбце указывает состояние повторного изменения.

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

Журнал транзакций превышает @autoreseedthreshold процент полного, например 70.
Причина повторного использования журнала .REPLICATION
Так как ожидание REPLICATION повторного использования журнала может быть вызвано для других функций, таких как репликация транзакций или CDC, автоматически выполняется только в том случае, если sys.databases.is_data_lake_replication_enabled = 1. Это значение настраивается зеркальным отображением Структуры.

Проверьте, было ли инициировано повторное заполнение базы данных.

Если выполняется повторное засевание всей базы данных, учтите следующие условия.

Столбец 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.

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

Для любой таблицы, в которой выполняется повторное изменение, найдите значение 7 столбца state в sys.sp_help_change_feed_table.

См. дополнительные сведения в sys.sp_help_change_feed_table.

Устранение неполадок зеркальных баз данных Fabric из Управляемого экземпляра SQL Azure

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-12-02