Ознаки
Розглянемо такий сценарій:
-
Групи доступності AlwaysOn використовуються в екземплярі Microsoft SQL Server 2016 або 2017.
-
Настроювання SQL Server керованих резервних копій в одній або кількох базах даних користувачів, які додаються до доступної групи.
-
Ви запускаєте на вимогу журнал резервного копіювання бази даних.
-
Видаліть базу даних із доступної групи, а потім додайте її знову. Або відновлення після відмови бази даних.
-
Ви запускаєте на вимогу журнал резервного копіювання бази даних.
У цьому випадку є розрив у ланцюжку журналів, запитуючи managed_backup.fn_available_backups таблиці в базі даних msdb.
Причина
Ця проблема виникає через те, що під час видалення бази даних із доступної групи, а потім додавання її назад або відновлення після відмови бази даних, новий GUID бази даних створюється в стовпці database_guid таблиці smart_backup_files . Це призводить до того, що розділ перелічить дані в непослідовному порядку та запускає ланцюжок журналів розривів.
Спосіб вирішення
Це виправлення включено до сукупного пакета оновлень для SQL Server:
Сукупне оновлення 1 для SQL Server 2017 р.
Сукупний пакет оновлень 5 для SQL Server 2016 із пакетом оновлень 1
Про збірки SQL Server
Кожна нова збірка для SQL Server містить усі виправлення та всі виправлення системи безпеки, включені в попередню збірку. Радимо інсталювати останні сукупні оновлення для SQL Server:
Стан
Корпорація Майкрософт підтвердила, що це проблема в продуктах Microsoft, перелічених у розділі "Стосується".
Посилання
Дізнайтеся про термінологію, яку корпорація Майкрософт використовує для опису оновлень програмного забезпечення.
