SQL Server 2017 se bloque lors de la sauvegarde car le chemin de fichier est incorrect

J'essayais de restaurer ma base de données et SQL Server ne cessait de planter. J'obtiendrais un message dans SSMS qui disait qu'il y avait une erreur de transport réseau (la connexion a chuté avant le crash). J'ai vérifié les journaux et trouvé rien de plus que SQL Server fermé de façon inattendue. Je devrais alors aller redémarrer le service.

J'ai limité le problème au script que l'interface graphique tentait d'exécuter. Le problème est que lorsqu'il s'agit de prendre une sauvegarde de journal de fin, le chemin d'accès aux fichiers de sauvegarde est incorrect. CA devrait etreD:\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

J'ai deux questions.

1. Comment réparer ce chemin? J'ai essayé d'entrer dans les paramètres du serveur et le chemin de sauvegarde est D:sans barre oblique. Si j'ajoute la barre oblique, l'interface graphique la supprime. Il s'agit de SSMS v17.9.1. Je peux choisir D:\mapbenefits\et ça marche mais je veuxD:\DATABASE\...

2. Est-ce un bug? Le serveur SQL doit-il se bloquer simplement parce qu'un chemin est mal tapé? Une fois que j'ai corrigé le chemin du fichier, il n'a aucun problème. Je peux reproduire à tout moment simplement en nettoyant le chemin du fichier.

Si j'exécute une requête pour vérifier la version, j'obtiens CU13, mais si j'entre dans les paramètres, je vois la version 14.0.1000.169.

Il semble que ce soit un bug et est reproductible, je l'ai donc posté ici: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- les causes

J'ai pu reproduire cela.

En 2016, si je mets un chemin invalide comme ça, je reçois ce message:

Impossible d'ouvrir le périphérique de sauvegarde «D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak». Erreur du système d'exploitation 3 (le système ne peut pas trouver le chemin spécifié.)

Sur 2017 CU 13 (14.0.3048.4), il en résulte un blocage du service. Vous avez déjà mentionné que dans le dernier correctif (14.0.3049.1), le service ne plante pas, mais la session est interrompue.

J'ai confirmé que le même comportement exact s'applique RESTORE DATABASEégalement - le passage d'un chemin comme "D: Backups" (avec une barre oblique inverse manquante) ou "D :: \ Backups" (deux points supplémentaires) bloque l'instance de SQL Server (merci Michael K Campbell pour en avoir parlé).

Si je mets un chemin "valide" qui n'existe pas, j'obtiens le comportement correct ("ne peut pas trouver le chemin spécifié") en 2017.

Il s'agit d'un bug - à la fois dans CU 13 et dans la version du correctif. La transmission de paramètres incorrects aux commandes BACKUPou RESTOREne doit pas bloquer le service ni tuer votre session. Vous pouvez le signaler sur le site de commentaires .

Remarque: la version de service-crash de ce bogue peut être reproduite dans une version d'aperçu publique de SQL Server 2019 (CTP2.2 - merci à Denis Rubashkin pour l'avoir signalé)

En regardant cela dans un débogueur, il semble que le code de validation de chemin soit simplement cassé. Il finit par provoquer un débordement de pile en appelant récursivement sqlmin!CheckFileStreamReservedaprès que les vérifications normales (et assez étendues) sur le chemin fourni n'ont pas donné de sens. Le débordement de pile met fin au service sur la version 3048. La même chose se produit sur 3049, sauf une séquence de violations d'accès lors de la tentative de traitement du débordement de pile, à la place, rompt la connexion plutôt que d'arrêter tout le serveur.

Un correctif pour ce bogue a été publié dans SQL Server 2017 CU 15:

CORRECTIF: SQL Server 2017 se bloque en raison d'un débordement de pile lorsque vous essayez de sauvegarder le maître de base de données sur le disque

Le problème est également résolu dans SQL Server 2019 CTP 3.0.