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