Ознаки
Припустимо, що ви використовуєте групу доступності 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. один або кілька одиниць відновлення, що належать до <імені бази даних бази даних> "не вдалося створити контрольно-пропускний пункт. Зазвичай це спричинено відсутністю системних ресурсів, таких як диск або пам'ять, або в деяких випадках через корупцію в базі даних. Перегляньте попередні дані в журналі помилок, щоб отримати докладні відомості про цю помилку.
Після того, як під час Відкочування транзакції ви можете отримати таке повідомлення про помилку:
MSG 3052, рівень 16, стан 1, рядок 4BACKUP LOG не зміг виконати оновлення для <імені бази даних> ". Подальші резервні копії журналів вимагатимуться, щоб перейти до резервної копії з "<lsn ID 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, перелічених у розділі "застосовується до".
