SQL Server 2017 виходить з ладу під час резервного копіювання, тому що filepath неправильний

Я намагався відновити свою базу даних, і SQL Server постійно виходив з ладу. Я отримав би повідомлення в SSMS, в якому сказано, що виникла помилка в мережевому транспорті (з'єднання випало з-за краху). Я перевірив журнали і не знайшов нічого більше, ніж несподівано закрився SQL Server. Тоді мені доведеться піти і перезапустити послугу.

Я звузив проблему до сценарію, який GUI намагався запустити. Проблема полягає в тому, що коли йдеться про резервну копію журналу хвоста, шлях до файлів резервного копіювання неправильний. Вона повинна бутиD:\mapbenefits\...

BACKUP LOG [mapbenefits]
TO  DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT,  NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
    NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

У мене два питання.

1. Як виправити цей шлях? Я спробував зайти в налаштування сервера, і шлях резервного копіювання не D:має нахилу. Якщо я додаю косу рису, gui видаляє її. Це SSMS v17.9.1. Я можу вибрати, D:\mapbenefits\і це працює, але я хочуD:\DATABASE\...

2. Це помилка? Чи повинен збій сервера SQL тільки тому, що шлях неправильно введений? Після того, як я виправив шлях до файлу, він не матиме проблем. Я можу відтворити в будь-який час, просто відключивши шлях файлу.

Якщо я запускаю запит, щоб перевірити версію, я отримую CU13, але якщо я переходжу до налаштувань, я бачу версію 14.0.1000.169.

Схоже, це помилка і відтворюється, тому я опублікував це тут: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- причини

Я зміг це відтворити.

Якщо я ставлю недійсний шлях таким чином, у 2016 році я отримую це повідомлення:

Не вдається відкрити резервний пристрій "D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak". Помилка операційної системи 3 (Система не може знайти вказаний шлях.)

У 2017 році 13 CU (14.0.3048.4) це призводить до збою служби. Ви вже згадували, що в останньому виправлення (14.0.3049.1) сервіс не виходить з ладу, але сеанс знищується.

Я підтвердив, що саме така поведінка стосується RESTORE DATABASEі проходження шляху, наприклад "D: Резервне копіювання" (з відсутньою косою рисою) або "D :: \ Резервні копії" (додаткова двокрапка), вибиває екземпляр SQL Server (спасибі Майкл Кемпбелл для доведення цього).

Якщо я поставлю "дійсний" шлях, який не існує, я отримаю правильну поведінку ("не вдається вказати шлях") у 2017 році.

Це помилка - як у CU 13, так і в збірці виправлень. Передавання невірних параметрів командам BACKUPабо RESTOREкомандам не повинно збивати службу або знищувати ваш сеанс. Ви можете повідомити про це на сайті відгуків .

Примітка. Версія цього помилки, що завершується службою, може бути відтворена у відкритій версії попереднього перегляду SQL Server 2019 (CTP2.2 - завдяки Денису Рубашкіну за вказівку на це)

Дивлячись на це у відладчику, здається, що код перевірки шляху просто порушений. Це в кінцевому підсумку викликає переповнення стека шляхом рекурсивного виклику sqlmin!CheckFileStreamReservedпісля того, як звичайні (і досить обширні) перевірки наданого шляху не мають сенсу для цього. Переповнення стека знижує службу в збірці 3048. Те ж саме відбувається і з 3049, за винятком послідовності порушень доступу під час спроби обробки переповнення стека замість цього розриває з'єднання, а не зупиняє весь сервер.

Виправлення цієї помилки було випущено в SQL Server 2017 CU 15:

Виправлення: SQL Server 2017 виходить з ладу через переповнення стека, коли ви намагаєтесь створити резервну копію майстра бази даних на диск

Проблема також вирішена в SQL Server 2019 CTP 3.0.