Симптоми
Приемете, че използвате група за достъпност на AlwaysOn в база данни на Microsoft SQL Server 2012 или SQL Server 2014 и съществува голяма открита активна транзакция и изисква допълнително място за регистриране. Когато регистрационният файл не може да се увеличи поради една от следните причини, транзакцията е неуспешна.
-
Липса на допълнително място за файлове
-
Регистрационният файл е конфигуриран да не се разраства
-
Регистрационният файл достигна максимално конфигурирания си размер
Освен това се извежда следното съобщение за грешка:
Грешка: 9002, тежест: 17; щат: 9. Регистърът на транзакциите за база данни "<име на база данни>" е пълен, поради "LOG_BACKUP".
След като изпълните архивирането на регистрационен файл, получавате друго съобщение за грешка за 9002:
Грешка: 9002, тежест: 17; щат: 9. Регистърът на транзакциите за база данни "<име на база данни>" е пълен, поради "ACTIVE_TRANSACTION".
След друго архивиране на регистрационни файлове, след това получавате друго съобщение за грешка за 9002, последвано от съобщение за грешка в 5901:
Грешка: 9002, тежест: 17; щат: 9. Регистърът на транзакциите за база данни "<име на база данни>" е пълен, поради "AVAILABILITY_REPLICA".
Не можа да се запише запис за контролна точка в <име на база данни>, тъй като Регистърът е извън пространството. Свържете се с администратора на базата данни, за да съкратите регистрационния файл или да разпределите повече място към регистрационните файлове на базата данни. Грешка: 5901, тежест: 16; щат: 1. един или повече единици за възстановяване, принадлежащи към базата данни "<име на база данни>" не успя да генерира контролен пункт. Това обикновено се дължи на липсата на системни ресурси, като например диск или памет, а в някои случаи поради корупция в базата данни. Преглед на предишни записи в регистъра за грешки за по-подробна информация за този неуспех.
Когато след това бъдат взети по време на възстановяването на транзакцията следващото следващо КПП или log, е възможно да получите следното съобщение за грешка:
MSG 3052, Level 16, State 1, Line 4BACKUP LOG не можа да регистрира актуализации за базата данни "<име на база данни>". Следва да се изисква последващо архивиране, за да се придвижите до точката за архивиране от "<LSN ИД 1>" към "<LSN ID 2>" след като сте направили достъпни за регистрирането им.
Когато получите тези съобщения, вече не можете да изпращате нови транзакции към базата данни и не можете да отглеждате регистрационния файл или да добавяте друг регистрационен файл.
Решение
Първоначално проблемът е коригиран в следната сборна актуализация на SQL Server:
Всяка нова сборна актуализация за SQL Server съдържа всички поправки и всички корекции на защитата, които са били включени в предишната сборна актуализация. Препоръчваме ви да изтеглите и инсталирате последните сборни актуализации за SQL Server:
Заобиколно решение
Можете да използвате следното заобиколно решение, за да съкратите регистрационните файлове и да възобновите дейността.
-
Проверете всяко вторично копие, за да потвърдите вторичната реплика 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>'
-
В основната реплика
-
Премахнете базата данни от групата достъпност.
-
Добавете повторно базата данни към групата достъпност.
-
-
Във всяка вторична реплика
-
Добавете повторно базата данни към групата достъпност.
-
Чрез премахване на базата данни от групата достъпност той веднага ще съкрати регистрационните файлове и свободното място за регистриране. Ако last_hardened_lsn за всяка вторична реплика е идентична с основната реплика и не са предприети архивиране на регистрационни файлове по време на премахването на базата данни от групата достъпност и повторното Добавяне на базата данни върху всяко вторично, вторичната реплика ще бъде успешно добавена повторно без грешки или трябва да възстанови архивирането на регистрационния файл в вторично. Ако вторичната реплика не е актуална с основната реплика и трябва да премахнете базата данни от групата за достъпност, преди да може да се изравнят вторичната реплика, е необходимо да има архивиране на регистрационните файлове за архивиране, за да я обедините, преди да я добавите повторно към групата за достъпност или да пуснете базата данни върху вторичната реплика и да я направите повторно
Състоянието
Microsoft потвърди, че това е проблем в продуктите на Microsoft, които са посочени в секцията "важи за".
