SQL Server 2017 аварийно завершает работу при резервном копировании из-за неправильного пути к файлу

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

Я сузил проблему до сценария, который пытался запустить графический интерфейс. Проблема заключается в том, что когда дело доходит до создания резервной копии журнала, путь к файлам резервной копии неверен. Должен быть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:без косой черты. Если я добавлю косую черту, графический интерфейс удалит ее. Это 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 CU 13 (14.0.3048.4) это приводит к сбою службы. Вы уже упоминали, что в последнем исправлении (14.0.3049.1) служба не падает, но сеанс завершается.

Я подтвердил, что точно такое же поведение применимо и к нему RESTORE DATABASE- передача пути типа «D: Backups» (с отсутствующей обратной косой чертой) или «D :: \ Backups» (лишняя двоеточие) приводит к сбою экземпляра 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.