Автоматическое восстановление для зеркализованных баз данных Fabric из Azure SQL Database

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

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

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

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

В Azure SQL Database и Azure SQL Managed Instance можно выполнить пересоздание на уровне базы данных или таблицы.

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

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

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