SQL Server 2017 si arresta in modo anomalo durante il backup perché il percorso del file è errato

Stavo cercando di ripristinare il mio database e SQL Server ha continuato a bloccarsi. Vorrei ricevere un messaggio in SSMS che diceva che c'era un errore di trasporto di rete (la connessione è caduta a causa dell'incidente). Ho controllato i registri e non ho trovato altro che SQL Server chiuso in modo imprevisto. Dovrei quindi andare e riavviare il servizio.

Ho ristretto il problema allo script che la GUI stava cercando di eseguire. Il problema è che quando si esegue un backup del registro di coda, il percorso dei file di backup è errato. Dovrebbe essereD:\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

Ho due domande

1. Come posso risolvere questo percorso? Ho provato ad andare nelle impostazioni del server e il percorso di backup è D:senza barra. Se aggiungo la barra, la GUI la rimuove. Questo è SSMS v17.9.1. Posso scegliere D:\mapbenefits\e funziona, ma voglioD:\DATABASE\...

2. è un insetto? Il server SQL dovrebbe arrestarsi in modo anomalo solo perché un percorso non è stato digitato correttamente? Una volta risolto il percorso del file non ha problemi. Posso riprodurre in qualsiasi momento semplicemente spostando il percorso del file.

Se eseguo una query per verificare la versione ottengo CU13, ma se vado nelle impostazioni vedo la versione 14.0.1000.169.

Sembra che questo sia un bug ed è riproducibile, quindi l'ho pubblicato qui: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- cause

Sono stato in grado di riprodurre questo.

Nel 2016, se inserisco un percorso non valido come quello, ricevo questo messaggio:

Impossibile aprire il dispositivo di backup "D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak". Errore del sistema operativo 3 (Il sistema non riesce a trovare il percorso specificato.)

Su CU 13 2017 (14.0.3048.4), il servizio si arresta in modo anomalo. Hai già detto che nell'ultimo aggiornamento rapido (14.0.3049.1), il servizio non si arresta in modo anomalo, ma la sessione viene interrotta.

Ho confermato che si applica anche lo stesso comportamento esatto RESTORE DATABASE: passare un percorso come "D: Backup" (con una barra rovesciata mancante) o "D :: \ Backup" (due punti in più) blocca l'istanza di SQL Server (grazie Michael K Campbell per averlo sollevato).

Se inserisco un percorso "valido" che non esiste, ottengo il comportamento corretto ("impossibile trovare il percorso specificato") nel 2017.

Questo è un bug - sia in CU 13 che nella build dell'aggiornamento rapido. Il passaggio di parametri errati ai comandi BACKUPo RESTOREnon dovrebbe arrestare il servizio o interrompere la sessione. Puoi segnalarlo sul sito di feedback .

Nota: la versione con arresto anomalo del servizio di questo bug può essere riprodotta in una versione di anteprima pubblica di SQL Server 2019 (CTP2.2 - grazie a Denis Rubashkin per averlo segnalato)

Guardando questo in un debugger, sembra che il codice di convalida del percorso sia semplicemente rotto. Finisce per causare un overflow dello stack chiamando ricorsivamente sqlmin!CheckFileStreamReserveddopo che i controlli normali (e piuttosto estesi) sul percorso fornito non riescono a capirlo. Lo overflow dello stack interrompe il servizio sulla build 3048. La stessa cosa accade sul 3049 tranne una sequenza di violazioni dell'accesso mentre il tentativo di gestire lo overflow dello stack interrompe invece la connessione anziché arrestare l'intero server.

Una correzione per questo errore è stata rilasciata in SQL Server 2017 CU 15:

FIX: SQL Server 2017 si arresta in modo anomalo a causa dell'overflow dello stack quando si tenta di eseguire il backup del master del database su disco

Il problema è stato risolto anche in CTP 3.0 di SQL Server 2019.