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 queue, le chemin d'accès aux fichiers de sauvegarde est incorrect. Ça devrait être 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
J'ai deux questions.
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 choisirD:\mapbenefits\et ça marche mais je veuxD:\DATABASE\...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 en déblayant le chemin du fichier.
Si j'exécute une requête pour vérifier la version, j'obtiens CU13, mais si je vais 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-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 de 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 tel que "D: Backups" (avec une barre oblique inverse manquante) ou "D ::\Backups" (deux points supplémentaires) plante l'instance SQL Server (merci Michael K Campbell pour ce sujet).
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 BACKUP ou RESTORE ne doit pas bloquer le service ou 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 avoir pointé ce out)
En regardant cela dans un débogueur, il semble que le code de validation du chemin soit simplement cassé. Il finit par provoquer un débordement de pile en appelant récursivement dans sqlmin!CheckFileStreamReserved après que les vérifications normales (et assez approfondies) du chemin fourni ne parviennent pas à le comprendre. 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:
Le problème est également résolu dans SQL Server 2019 CTP 3.0.