Comment résoudre un problème de base de données SQL en état de récupération en attente

L’état « Récupération en cours » sur une base de données SQL Server est l’un de ces problèmes frustrants qui apparaissent soudainement, surtout après un arrêt brutal ou un plantage. En clair, votre base de données indique à SQL Server qu’elle doit être récupérée, mais pour une raison inconnue, ce processus ne peut pas démarrer. Cela se produit souvent lorsque l’espace disque est insuffisant, que des fichiers sont corrompus ou que des problèmes d’autorisations surviennent. Heureusement, il existe des solutions pour diagnostiquer et, espérons-le, résoudre le problème sans avoir à tout reconstruire.

Comment corriger l’état « Récupération en attente » sur une base de données SQL Server ?

Vérifiez que vous disposez de suffisamment d’espace disque libre.

Cela peut paraître évident, mais on l’oublie souvent. Si le disque contenant vos fichiers de base de données est plein, SQL Server rencontre un problème et ne parvient pas à récupérer la base de données. Vous pouvez le vérifier en ouvrant l’Explorateur de fichiers et en accédant au dossier où sont stockés vos fichiers de base de données — généralement quelque chose comme C:\Program Files\Microsoft SQL Server\MSSQL\ xx. ERASQLINSTANCEID \MSSQL\DATA. Si votre disque est presque plein, essayez de supprimer ou de déplacer certains fichiers non essentiels vers un autre lecteur ou de libérer de l’espace.

Conseil de pro : vérifiez si SQL Server manque d’espace disque, car Windows peut parfois rendre la chose compliquée. Après avoir libéré de l’espace, redémarrez le service SQL Server pour forcer la base de données à se restaurer. Cette simple opération suffit parfois à résoudre le problème.

Vérifiez que vos fichiers de base de données existent toujours et sont accessibles.

Ensuite, vérifiez que les fichiers de base de données (.mdf et.ldf) sont bien présents. Il arrive souvent qu’ils disparaissent suite à des suppressions accidentelles, une corruption du disque ou des problèmes d’autorisations. Le chemin d’accès par défaut de ces fichiers est généralement :

• C:\Program Files\Microsoft SQL Server\MSSQL<xx>.ERASQLINSTANCEID\MSSQL\DATA

Ouvrez ce dossier et vérifiez que les fichiers de base de données s’y trouvent. S’ils sont absents, cela pose problème ; la restauration à partir d’une sauvegarde sera peut-être votre seule solution. Si les fichiers sont présents, passez à l’étape suivante.

Assurez-vous que SQL Server dispose des autorisations nécessaires pour accéder aux fichiers.

Cela peut être une cause insidieuse. Faites un clic droit sur les fichiers de base de données, sélectionnez Propriétés, puis accédez à l’ onglet Sécurité. Vérifiez si le compte de service SQL Server (par exemple, NT Service\MSSQLSERVER ou un compte de domaine) dispose du Contrôle total. Si ce n’est pas le cas, cliquez sur Modifier et ajoutez le compte en lui accordant les autorisations nécessaires. Il arrive que des mises à jour Windows ou des modifications d’autorisations perturbent ce processus de manière inattendue.

Sur une configuration, j’ai constaté que les autorisations se réinitialisaient complètement sans aucun avertissement — je ne sais pas pourquoi cela fonctionne, mais corriger les autorisations est utile dans la plupart des cas.

Redémarrez le service SQL Server

Il s’agit d’une procédure classique. Si le service n’est pas en cours d’exécution, la base de données ne peut pas être récupérée. Ouvrez services.msc, recherchez SQL Server ( nom de l’instance ) et vérifiez s’il est en cours d’exécution. Si ce n’est pas le cas, faites un clic droit dessus et sélectionnez « Démarrer ».S’il est en cours d’exécution, redémarrez-le. Sur certaines machines, cela peut relancer le processus de récupération. N’oubliez pas que si vous utilisez SQL Server Express, vous devez redémarrer le service SQL Server Express.

Après un redémarrage, patientez quelques minutes ; la base de données peut mettre ce temps à se reconnecter. Dans SSMS, développez « Bases de données » et vérifiez si l’état est revenu à la normale.

Essayez de redémarrer la base de données dans SSMS.

Si le redémarrage du service n’a pas résolu le problème, cliquez avec le bouton droit sur la base de données directement dans SSMS, puis sélectionnez Redémarrer. Cela suffit parfois à la remettre en mode normal. Patientez quelques instants, puis actualisez la page et vérifiez si le message « Récupération en cours » persiste.

Détacher puis rattacher la base de données

C’est un peu risqué si vous n’êtes pas prudent, mais si vous avez une sauvegarde récente, ça vaut le coup d’essayer. Dans SSMS, faites un clic droit sur la base de données, puis allez dans Tâches > Mettre hors ligne. Confirmez, puis faites un clic droit à nouveau et choisissez Détacher. Une fois la base détachée, rattachez-la en faisant un clic droit sur Bases de données et en cliquant sur Attacher. Accédez à vos fichiers de base de données et ajoutez-les à nouveau. Normalement, SQL devrait pouvoir la rattacher sans problème.

Attention : si vous voyez une erreur du type « Impossible de détacher une base de données suspecte ou en cours de récupération. Elle doit être réparée ou supprimée », il est temps de passer à l’étape suivante, car cela signifie qu’il y a une corruption plus profonde ou un problème interne.

Réparez la base de données si rien d’autre ne fonctionne

Si le problème persiste et que la base de données refuse de se connecter, elle peut nécessiter une réparation. Pour cela, commencez par faire une copie de vos fichiers MDF et LDF ; une sauvegarde est toujours recommandée avant d’utiliser des commandes de réparation. Ensuite :

• Arrêtez le service SQL Server ( services.msc ).
• Démarrez SQL Server en mode mono-utilisateur ou avec les services minimaux si nécessaire.
• Exécuter des commandes dans SSMS, par exemple :

ALTER DATABASE DatabaseName SET EMERGENCY; GO DBCC CHECKDB (DatabaseName); GO ALTER DATABASE DatabaseName SET SINGLE_USER; GO DBCC CHECKDB (DatabaseName, REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS; GO ALTER DATABASE DatabaseName SET MULTI_USER; GO 

Cette opération est assez radicale et comporte un risque de perte de données ; ne l’utilisez donc que si vous êtes à l’aise avec les conséquences potentielles. Le mode d’urgence permet à SQL de se réparer efficacement.

D’autres options si rien d’autre ne fonctionne

Dans certains cas, vous devrez restaurer une sauvegarde ou consulter les journaux d’erreurs SQL pour trouver des indices. Pour consulter les journaux, développez Gestion dans SSMS, puis cliquez sur Journaux SQL Server > Actuels. Parfois, les journaux indiquent la véritable cause du problème : corruption de fichiers, autorisation refusée ou fichiers manquants.

Conseils supplémentaires — n’oubliez pas

Résoudre ces problèmes peut s’apparenter à un jeu de taupe. Généralement, corriger les permissions ou libérer de l’espace disque suffit. Parfois, la restauration de la base de données à partir d’une sauvegarde récente est la solution la plus sûre, surtout en cas de corruption. Soyez prudent et, si possible, effectuez d’abord un test sur une copie.

Résumé

• Vérifiez l’espace disque disponible et libérez-en si nécessaire.
• Vérifiez que les fichiers de base de données sont présents et accessibles.
• Vérifiez que les autorisations sont correctes pour SQL Server.
• Redémarrez ou relancez le service dans SSMS
• Détacher puis rattacher la base de données
• Tentez les commandes de réparation si tout le reste échoue.

Conclure

Toute cette histoire est pénible, mais ces étapes couvrent les causes les plus fréquentes d’un message « Récupération en attente ».Parfois, un simple redémarrage suffit, et d’autres fois, il faut utiliser des commandes de réparation plus complexes. Pensez à faire des sauvegardes et armez-vous de patience. Idéalement, évitez de saturer votre disque dur pour éviter que ce problème ne se reproduise. Croisons les doigts pour que cela permette à certains de remettre leur base de données en ligne sans avoir à tout recommencer.