Il n’y a pas de raisons connues pour expliquer cette erreur. Cependant, l’erreur peut se produire pour l’une des raisons suivantes :<\/p>
- \n
- Votre instance SQL Server a été déconnectée lors de la restauration des sauvegardes du journal des transactions.<\/li>\n\n\n\n
- Le processus de restauration a été annulé.<\/li>\n\n\n\n
- Le serveur a manqué d’espace disque lors de la restauration de la base de données.<\/li>\n<\/ul>
Comment corriger l’erreur ?<\/strong><\/strong><\/h2>
Remarque : <\/strong>avant de procéder, assurez-vous que le serveur dispose d’un espace disque suffisant, puis essayez de restaurer la base de données. Si vous n’avez pas de problème d’espace disque, suivez la solution décrite ci-dessous.<\/p>
Pour résoudre le problème, essayez de supprimer la base de données problématique et de la restaurer à nouveau. Pour ce faire, exécutez la commande suivante dans la fenêtre de requête de SQL Server Management Studio (SSMS) :<\/p>
Remarque : <\/strong>si vous ne pouvez pas supprimer la base de données, essayez de la détacher à l’aide de la procédure stockée sp_detach_db. Si la procédure stockée renvoie l’erreur a base de données est utilisée<\/a>”“, vous pouvez utiliser la commande dbcc detachdb <\/strong>pour détacher la base de données. Cependant, vous devez être prudent car il s’agit d’une commande non documentée.<\/p>
USE [master]<\/p>
GO<\/p>
– Créer à nouveau la base de données avec le même nom que l’original<\/p>
CREATE DATABASE [database_name] ;<\/p>
– restaurer la base de données à l’aide des scripts de sauvegarde habituels<\/p>
RESTORE DATABASE nom_de_la_base<\/p>
FROM DISK = ‘saisir le chemin du fichier .bak’<\/p>
AVEC LA RÉCUPÉRATION<\/p>
Remarque : <\/strong>si vous devez restaurer plusieurs fichiers de base de données, exécutez la commande RESTORE AVEC l’option NORECOVERY. Pour le dernier fichier de base de données, exécutez la commande RESTORE AVEC RECOVERY.<\/p>
Que faire si la base de données devient inaccessible ?<\/strong><\/strong><\/h2>
Si vous pouvez restaurer la base de données mais qu’elle n’est plus accessible et qu’elle est marquée comme SUSPECT, vous devrez la réparer. N’oubliez pas que vous ne pouvez pas réparer une base de données SUSPECT. Vous devez d’abord rendre la base de données accessible en la plaçant en mode URGENCE. Pour ce faire, exécutez la commande suivante :<\/p>
ALTER DATABASE nom_de_la_base SET EMERGENCY<\/p>
Une fois la base de données accessible, il est essentiel que vous ayez un accès exclusif à la base de données. Définissez donc l’état de la base de données en mode SINGLE_USER et exécutez DBCC CHECKDB avec l’option ‘REPAIR_ALLOW_DATA_LOSS’.<\/p>
ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE<\/p>
DBCC CHECKDB (‘nom_de_la_base_de_données’,REPAIR_ALLOW_DATA_LOSS)<\/p>
Ensuite, remettez la base de données en mode MULTI_USER en exécutant la commande suivante :<\/p>
ALTER DATABASE nom_de_la_base SET MULTI_USER<\/p>
![\"Téléchargement](\"https:\/\/www.stellarinfo.com\/public\/frontEnd\/images\/article\/fr\/win.png\")
<\/a><\/figure>\n<\/div>