Le système d'exploitation a renvoyé l'erreur 21 (le périphérique n'est pas prêt.)
À chaque redémarrage de Windows, pour certaines bases de données, j'obtiens cette erreur:
Le système d'exploitation a renvoyé l'erreur 21 (le périphérique n'est pas prêt.)
- J'ai vérifié le disque avec
chkdsk /r- pas de mauvais secteurs. J'ai exécuté
DBCC CHECKDBsans erreur:*(CHECKDB found 0 allocation errors and 0 consistency errors in database)*- Si je redémarre SQL Server, les erreurs disparaissent.
Windows 10 et SQL Server 2016 Express.
Chaque fois que je redémarre Windows, pour certaines bases de données, cette erreur se produit. (Erreur OS 21 - Appareil non prêt)
Cela est dû au fait qu'un disque était hors ligne ou n'était pas en ligne au moment du démarrage de SQL Server, ou avait des états de transition après la mise en ligne de SQL Server.
3.Si je redémarre SQL Server, les erreurs disparaissent
Oui, car les bases de données ont été remontées dans SQL Server. Vous pouvez également déconnecter-> en ligne la base de données et cela fonctionnera, en supposant que le périphérique de disque a été corrigé.
Cela peut facilement être reproduit dans un environnement de test en plaçant une base de données sur un disque, en désactivant le disque, en exécutant une requête de sélection (pour obtenir l'erreur), en remettant le disque en ligne et en remarquant que la sélection échoue toujours avec la même erreur. La base de données devra être remontée pour fonctionner à nouveau et ne pas obtenir l'erreur 21 du système d'exploitation.
Que devrais tu faire?
Demandez à quelqu'un d'effectuer un traçage de fenêtres pour comprendre pourquoi il ne se met pas en ligne initialement ou pourquoi il se déconnecte (toute transition d'état) ou pourquoi il s'affiche prêt pour Windows mais ne l'est vraiment pas (peut-être que d'autres pilotes doivent être chargés pour il).
De plus, vérifiez que tous les pilotes de filtre de disque sont à jour pour des choses comme l'antivirus, les protections contre les intrusions de l'hôte, etc., car ceux-ci peuvent également bloquer le service/démarrage/état.
Je pense que j'ai trouvé la cause.
Le problème est probablement dû à options d'alimentation "Démarrage rapide" .
C'est une technique Windows pour réduire le temps de démarrage; Le démarrage rapide combine les éléments d'un arrêt à froid et mise en veille prolongée .
Ici vous pouvez trouver un autre article sur les avantages et les inconvénients
Je l'ai désactivé et le problème semble résolu.
Ce sont mes observations et comment j'ai résolu le problème (pour le bénéfice d'autres personnes qui peuvent avoir le même problème)
- J'utilisais l'instance Amazon ec2 exécutant le serveur SQL.
- J'avais un périphérique EBS Block attaché à l'instance ec2, mappé au lecteur D :.
- Mes données et journaux se trouvaient dans le lecteur D :.
- Lorsque j'arrête l'instance ec2 et que je la remonte plus tard, j'ai toujours rencontré l'erreur de "périphérique non prêt" et les bases de données ne se présentaient pas.
- J'ai essayé de définir le service MSSQLSERVER avec "Démarrage différé".
- Cependant, à partir des journaux du serveur SQL, j'ai constaté que le délai n'était pas respecté et MSSQLSERVER a démarré en même temps que le démarrage.
- De l'observateur d'événements, j'ai observé le moment où le lecteur D: devient sain.
- À partir des journaux du serveur SQL, j'ai noté l'heure à laquelle SQL Server démarre ma base de données utilisateur.
- J'ai observé que, le lecteur D: n'est disponible qu'après 6 secondes plus tard; et évidemment l'erreur "Appareil non prêt" apparaît.
- J'ai également noté que le "démarrage différé" n'était pas honoré car il y avait un autre service nommé "SQL SERVER LaunchPad" qui démarre "MSSQLSERVER".
- Je n'ai pas besoin de la capacité Analytics du "Launchpad". J'ai donc désactivé ce service.
- Maintenant, "MSSQLSERVER" démarre avec un retard et peut trouver les fichiers du lecteur D:
L'erreur complète que j'ai obtenue lors de la connexion à mon instance MS SQL par défaut locale (2017) via MSSMS est:
Le système d'exploitation a renvoyé l'erreur 21 (le périphérique n'est pas prêt.) À SQL Server lors d'une lecture à l'offset 0x000000000ae000 dans le fichier "D:\MSSQL\DATA\tempdev.mdf". Des messages supplémentaires dans le journal des erreurs SQL Server et le journal des erreurs du système d'exploitation peuvent fournir plus de détails. Il s'agit d'une condition d'erreur grave au niveau du système qui menace l'intégrité de la base de données et doit être corrigée immédiatement. Effectuez une vérification complète de la cohérence de la base de données (DBCC CHECKDB). Cette erreur peut être causée par de nombreux facteurs; pour plus d'informations, consultez la documentation en ligne de SQL Server. (Microsoft SQL Server, erreur: 823) Pour obtenir de l'aide, cliquez sur: http://go.Microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=823&LinkId=20476
J'ai commencé à l'obtenir une fois que j'ai déplacé mon tempdb vers mon nouveau lecteur D. Faire un démarrage/arrêt du service SQL supprime l'erreur. Je n'ai jamais eu cette erreur lorsque tout était sur C. Mes deux disques sont SSD et cryptés avec Bitlocker, je ne sais pas si cela pourrait être le problème, peut-être que le lecteur C est déverrouillé très tôt car le système d'exploitation en a besoin, et le lecteur D est déverrouillé plus tard .
- Selon la réponse de Max ( https://dba.stackexchange.com/a/175115 ), la désactivation de "Démarrage rapide" a résolu mon problème. Selon l'article, les liens Max vers ( https://www.howtogeek.com/243901/the-pros-and-cons-of-windows-10s-fast-startup-mode/ ) c'est assez obscur à trouver, dans "Choisir ce que font les boutons d'alimentation" puis "Modifier les paramètres actuellement indisponibles".
- Contrairement à la réponse de Venvig ( https://dba.stackexchange.com/a/226115 ), la définition du service "SQL Server" sur Type de démarrage = "Automatique (démarrage différé)" a également résolu mon problème ( avec Windows'Fast Startup réactivé).
Ce problème m'a également énervé. J'ai 5 dbs accrochés à mon instance SQL Server, dont 3 fonctionnent correctement, mais 2 se plaignent
Le système d'exploitation a renvoyé l'erreur 21 (le périphérique n'est pas prêt.) À SQL Server lors d'une lecture à l'offset 0x00000000204000 dans le fichier 'E:\xxxxxxxx.mdf'
Voici ma solution.
- Activez Services.msc, recherchez le service appelé SQL Server (nom de l'instance), cliquez avec le bouton droit et redémarrez.
- Revenez à ssms, actualisez votre base de données et les choses devraient fonctionner.
En passant, j'ai essayé de prendre la méthode db hors ligne/en ligne. Cela n'a pas fonctionné dans mon cas. La force brute de redémarrer le service sqlserver a bien fonctionné. cela pourrait être un problème pour ceux dont l'enjeu de mettre tous les dbs hors ligne est trop élevé. Cependant, si vous faites juste du développement local comme moi, cette solution devrait convenir.
J'ai rencontré le même problème à plusieurs reprises et j'ai pensé que je devrais partager ma solution (malgré les réponses déjà fournies):
J'ai donc deux instances SQL (SQL 2008 et SQL 2017). L'erreur ne se manifeste pas dans mon instance SQL08 mais sur SQl17. Cela est dû aux "informations d'identification du compte" fournies lors de l'installation/configuration de chaque instance SQL:
Cela peut être vu sous Windows Services. Le SQL08 a été configuré pour utiliser le "compte système local" tandis que le SQL17 défaillant a été défini sur "COMPTE RÉSEAU" lors de l'installation. Il suffit donc de changer cela et de redémarrer le service SQL ici (ou de redémarrer l'instance dans le navigateur SQL).
La deuxième partie de ce problème est propre à SQL Server 2017 CTP 2.0 lors de l'utilisation de SQL Server Management Studio V17, auquel cas le SMO est passé à l'utilisation de " sys.dm_os_enumerate_fixed_drives "au lieu de l'ancien" xp_fixeddrives "pour obtenir des informations sur l'espace libre de votre disque local. Pour contourner cela, accédez au DEVICE MANAGER et désactivez temporairement le lecteur cité (dans mon cas, c'était le lecteur "G" qui est juste mon lecteur de DVD-ROM).