SQL Server 2017 ulega awarii podczas tworzenia kopii zapasowej, ponieważ ścieżka do pliku jest niepoprawna

Próbowałem przywrócić bazę danych, a SQL Server ciągle się zawieszał. Dostanę komunikat w SSMS, który mówi, że wystąpił błąd transportu sieciowego (połączenie zostało przerwane przez awarię). Sprawdziłem dzienniki i nie znalazłem nic poza nieoczekiwanym zamknięciem programu SQL Server. Musiałbym wtedy przejść i ponownie uruchomić usługę.

Zawęziłem problem do skryptu, który GUI próbował uruchomić. Problem polega na tym, że jeśli chodzi o wykonanie kopii zapasowej dziennika ogona, ścieżka do plików kopii zapasowej jest nieprawidłowa. Powinno być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

Mam dwa pytania.

1. Jak naprawić tę ścieżkę? Próbowałem przejść do ustawień serwera, a ścieżka kopii zapasowej D:nie zawiera ukośnika. Jeśli dodam ukośnik, GUI go usunie. To jest SSMS 17.9.1. Mogę wybrać D:\mapbenefits\i to działa, ale chcęD:\DATABASE\...

2. Czy to błąd? Czy serwer SQL powinien ulec awarii tylko dlatego, że ścieżka jest niepoprawnie wpisana? Po naprawieniu ścieżki do pliku nie ma żadnych problemów. Mogę się rozmnażać w dowolnym momencie, po prostu spłukując ścieżkę pliku.

Jeśli uruchomię zapytanie w celu sprawdzenia wersji, dostanę CU13, ale jeśli przejdę do ustawień, zobaczę wersję 14.0.1000.169.

Wygląda na to, że jest to błąd i jest odtwarzalny, więc opublikowałem go tutaj: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- przyczyny

Udało mi się to odtworzyć.

W 2016 r., Jeśli podam nieprawidłową ścieżkę, otrzymam następujący komunikat:

Nie można otworzyć urządzenia kopii zapasowej „D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak”. Błąd systemu operacyjnego 3 (system nie może znaleźć określonej ścieżki).

W dniu 13 CU 2017 (14.0.3048.4) powoduje awarię usługi. Wspomniałeś już, że w najnowszej poprawce (14.0.3049.1) usługa nie ulega awarii, ale sesja zostaje zabita.

Potwierdziłem, że to samo dotyczy RESTORE DATABASErównież zachowania - przekazanie ścieżki typu „D: Kopie zapasowe” (z brakującym ukośnikiem odwrotnym) lub „D :: \ Kopie zapasowe” (dodatkowy dwukropek) powoduje awarię instancji SQL Server (dzięki Michael K Campbell za poruszenie tego).

Jeśli ustawię „prawidłową” ścieżkę, która nie istnieje, otrzymam prawidłowe zachowanie („nie można znaleźć określonej ścieżki”) w 2017 r.

To jest błąd - zarówno w CU 13, jak i kompilacji poprawek. Podanie niepoprawnych parametrów do poleceń BACKUPlub RESTOREnie powinno spowodować awarii usługi ani zabić sesji. Możesz to zgłosić na stronie z opiniami .

Uwaga: wersję tego błędu powodującą awarię usługi można odtworzyć w publicznej wersji zapoznawczej programu SQL Server 2019 (CTP2.2 - dzięki Denisowi Rubashkinowi za zwrócenie na to uwagi)

Patrząc na to w debuggerze, wydaje się, że kod sprawdzania poprawności ścieżki jest po prostu zepsuty. W rezultacie powoduje przepełnienie stosu przez rekurencyjne wywoływanie sqlmin!CheckFileStreamReservedpo normalnych (i dość obszernych) kontrolach podanej ścieżki, które nie mają sensu. Przepełnienie stosu powoduje wyłączenie usługi w kompilacji 3048. To samo dzieje się w 3049, z wyjątkiem sekwencji naruszeń dostępu podczas próby obsłużenia przepełnienia stosu zamiast tego przerywa połączenie, a nie zatrzymuje cały serwer.

Poprawka dla tego błędu została wydana w SQL Server 2017 CU 15:

Poprawka: SQL Server 2017 ulega awarii z powodu przepełnienia stosu podczas próby wykonania kopii zapasowej wzorca bazy danych na dysku

Problem został również rozwiązany w programie SQL Server 2019 CTP 3.0.