Chaque fois que je redémarre 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.)
chkdsk /r- pas de mauvais secteurs.J'ai exécuté DBCC CHECKDBsans erreur:
*(CHECKDB found 0 allocation errors and 0 consistency errors in database)* Windows 10 et SQL Server 2016 Express.
Réponses:
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 à l'intérieur de 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 met hors ligne (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 les antivirus, les protections contre les intrusions sur 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û aux 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 la fonction de 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)
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 quand 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 .
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 unique à 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 d'espace libre sur votre disque local . Pour contourner ce problème, 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).
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.
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 être parfaite.