KB3095156-FIX: Error 9002 и Error 3052 при попытке добавить или создать резервную копию файла журнала в SQL Server 2012 или SQL Server 2014

Проблемы

Предположим, что вы используете группу доступности AlwaysOn в базе данных Microsoft SQL Server 2012 или SQL Server 2014, а также есть большая открытая активная транзакция, и для нее требуется дополнительное пространство журнала. Если файл журнала не может увеличиваться по одной из указанных ниже причин, происходит сбой транзакции.

• Недостаток дополнительного места в файле

• Настройка файла журнала не растет

• В файле журнала достигнуто значение, заданное максимальным размером

Кроме того, появляется приведенное ниже сообщение об ошибке:

После выполнения резервного копирования журнала появляется еще одно сообщение об ошибке 9002:

После другого резервного копирования журнала вы получите еще одно сообщение об ошибке 9002 и сообщение об ошибке 5901:

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

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

Решение

Эта проблема впервые устранена в следующем накопительном обновлении SQL Server:

• Накопительное обновление 3 для SQL Server 2014 с пакетом обновления 1 (SP1)

• Накопительное обновление 10 для SQL Server 2014

• Накопительное обновление 8 для SQL Server 2012 с пакетом обновления 2 (SP2)

Обходное решение

Вы можете использовать описанное ниже временное решение для усечения журналов и действий возобновления.

1. Установите флажки для всех вторичных реплик, чтобы убедиться, что вторичная реплика last_hardened_lsn (см. sys.dm_hadr_database_replica_states) соответствует первичной реплике last_hardened_lsn. Это можно сделать, выполнив следующий запрос, который подключен к первичному экземпляру реплики.

   SELECT ags.name as AGGroupName,    ar.replica_server_name as InstanceName,    hars.role_desc,    db_name(drs.database_id)as DBName,    drs.last_hardened_lsn, drs.log_send_queue_size,    drs.synchronization_state_desc as SyncState,    ar.availability_mode_desc as SyncMode,    CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id    FROM sys.dm_hadr_database_replica_states drs    LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id    LEFT JOIN sys.availability_groups ags  ON ar.group_id = ags.group_id    LEFT JOIN sys.dm_hadr_availability_replica_states hars        ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id      WHERE db_name(drs.database_id) = '<database name>'

2. На первичной реплике

   • Удалите базу данных из группы доступности.

   • Повторно добавьте базу данных в группу доступности.

3. На каждой вторичной реплике

   • Повторно добавьте базу данных в группу доступности.

Удаляя базу данных из группы доступности, вы сразу же сокращаете свои журналы и освобождаете пространство журнала. Если last_hardened_lsn каждой вторичной реплики идентичны первичной реплике, а резервные копии журналов не предпринимаются во время удаления базы данных из группы доступности и повторного добавления базы данных на каждом из них, дополнительная реплика будет успешно добавлена без ошибок или восстанавливать резервные копии журналов на получателе. Если вторичная реплика не является текущей, и вам нужно удалить базу данных из группы доступности до того, как она сможет быть сопоставлена, то перед повторной добавим ее в группу доступности может потребоваться восстановление резервных копий журналов, чтобы перехватить базу данных и повторно заполнить ее с помощью резервной копии базы данных журнала транзакций.

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".