SQL Server: base de données bloquée dans l'état "Restauration"
J'ai sauvegardé une base de données:
BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing
Et puis essayé de le restaurer:
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE --force restore over specified database
Et maintenant, la base de données est bloquée dans l'état de restauration.
Certaines personnes ont émis l'hypothèse que c'était parce qu'il n'y avait pas de fichier journal dans la sauvegarde et qu'il devait être restauré à l'aide de:
RESTORE DATABASE MyDatabase
WITH RECOVERY
Sauf que, bien sûr, échoue:
Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Et exactement ce que vous voulez dans une situation catastrophique est une restauration qui ne fonctionnera pas.
La sauvegarde contient à la fois un fichier de données et un fichier journal:
RESTORE FILELISTONLY
FROM DISK = 'MyDatabase.bak'
Logical Name PhysicalName
============= ===============
MyDatabase C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF
Vous devez utiliser l'option WITH RECOVERY avec votre commande database RESTORE pour mettre votre base de données en ligne dans le cadre du processus de restauration.
Ceci est bien sûr uniquement si vous n’avez pas l’intention de restaurer les sauvegardes du journal des transactions, c’est-à-dire que vous souhaitez uniquement restaurer une sauvegarde de base de données et pouvoir ensuite accéder à la base de données.
Votre commande devrait ressembler à ceci,
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE,RECOVERY
L’assistant de restauration de la base de données dans SQL Server Management Studio vous permettra peut-être d’avoir plus de succès. De cette façon, vous pouvez sélectionner des emplacements de fichiers spécifiques, l'option de remplacement et l'option WITH Recovery.
J'ai eu cette situation en restaurant une base de données à une instance de SQL Server 2005 Standard Edition en utilisant Symantec Backup Exec 11d. Une fois le travail de restauration terminé, la base de données est restée dans l'état "Restauration". Je n'ai pas eu de problèmes d'espace disque - la base de données n'est tout simplement pas sortie de l'état "Restauration".
J'ai lancé la requête suivante sur l'instance SQL Server et constaté que la base de données devenait immédiatement utilisable:
RESTORE DATABASE <database name> WITH RECOVERY
Voici comment vous le faites:
- Arrêtez le service (MSSQLSERVER);
- Renommez ou supprimez les fichiers de base de données et les fichiers journaux (C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data ...) ou où que vous soyez.
- Démarrer le service (MSSQLSERVER);
- Supprimer la base de données avec problème;
- Restaurez la base de données à nouveau.
Bonne chance!
J'ai eu un incident similaire avec l'arrêt d'un serveur secondaire d'envoi de journaux . Après la commande permettant de supprimer le serveur de l'envoi de journaux et d'arrêter l'envoi de journaux du serveur principal, la base de données sur le serveur secondaire s'est bloquée en restauration du statut après la commande
RESTORE DATABASE <database name> WITH RECOVERY
Les messages de la base de données:
RESTORE DATABASE a traité avec succès 0 pages en 18.530 secondes (0,000 MB/sec).
La base de données était à nouveau utilisable après ces 18 secondes.
J'ai eu un problème similaire avec la restauration à l'aide de SQL Management Studio. J'ai essayé de restaurer une sauvegarde de la base de données sur une nouvelle avec un nom différent. Au début, cela a échoué et après avoir corrigé les noms de fichier de la nouvelle base de données, l'opération a été effectuée avec succès. Dans tous les cas, le problème que je décris s'est reproduit, même si je l'ai compris correctement dès la première fois. Ainsi, après la restauration, la base de données d'origine est restée avec un (Restauration ...) à côté de son nom. Considérant les réponses du forum ci-dessus (Bhusan), j'ai essayé de lancer dans l'éditeur de requêtes du côté suivant:
RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"
qui a résolu le problème. J'avais des problèmes au début à cause du nom de la base de données qui contenait des caractères spéciaux. J'ai résolu ce problème en ajoutant des guillemets doubles - les guillemets simples ne fonctionneraient pas en donnant l'erreur "Syntaxe incorrecte près de ...".
C’était la solution minimale que j’essayais de résoudre ce problème (base de données bloquée en état de restauration) et j’espère que cela pourra être appliqué à un plus grand nombre de cas.
OK, le problème est similaire et, exactement comme dans le cas de Pauk, le serveur a manqué d’espace disque lors de la restauration et a donc provoqué un état de restauration permanente. Comment arrêter cet état sans arrêter les services SQL Server ?
J'ai trouvé une solution :)
Drop database *dbname*
L'option WITH RECOVERY est utilisée par défaut lorsque les commandes RESTORE DATABASE/RESTORE LOG sont exécutées. Si vous êtes bloqué dans le processus de "restauration", vous pouvez ramener une base de données à l'état en ligne en exécutant:
RESTORE DATABASE YourDB WITH RECOVERY
GO
Si la restauration de plusieurs fichiers est nécessaire, les commandes CLI requièrent respectivement WITH NORECOVERY et WITH RECOVERY - seul le dernier fichier de la commande doit avoir WITH RECOVERY pour remettre la base de données en ligne:
RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO
Vous pouvez également utiliser l’assistant SQL Server Management Studio:
Il existe également un processus de restauration virtuelle, mais vous devrez utiliser des solutions tierces. Habituellement, vous pouvez utiliser une sauvegarde de base de données comme base de données en ligne dynamique. ApexSQL et Idera ont leurs propres solutions. Examen par SQL Hammer à propos de ApexSQL Restore . La restauration virtuelle est une bonne solution si vous effectuez un grand nombre de sauvegardes. Le processus de restauration est beaucoup plus rapide et peut également économiser beaucoup d’espace sur le lecteur de disque. Vous pouvez jeter un oeil sur infographie ici pour comparer.
Cela peut paraître assez évident, mais cela m’a fait trébucher tout à l’heure:
Si vous effectuez une sauvegarde de journal détaillé, ce problème peut également être dû au fait que cette option est cochée dans l'Assistant Restauration SSMS - "Laissez la base de données source à l'état de restauration (WITH NORECOVERY)"
J'ai compris pourquoi.
Si le client qui a émis la commande RESTORE DATABASE se déconnecte pendant la restauration, celle-ci sera bloquée.
Il est étrange que le serveur, lorsqu'il est invité à restaurer une base de données par une connexion client, ne termine pas la restauration à moins que le client reste connecté tout le temps.
celui-ci a fonctionné:
Dans une situation où ma base de données affichait l'état de restauration, je ne pouvais exécuter aucune requête et je ne pouvais pas me connecter à notre logiciel.
Ce que j'ai fait pour sortir de cette situation, c'est:
Arrêtez tous les services liés à SQL à partir des services Windows.
J'ai ouvert le dossier DATA où se trouvent les fichiers Ldf et Mdf dans le répertoire SQL, normalement comme suit: "C:\Program Files ***********\MSSQL\DATA
Ensuite, j'ai copié les fichiers Ldf et Mdf de la base de données: [nom de la base de données] .mdf et [nom de la base de données] _log.ldf
J'ai copié ces deux fichiers dans un autre dossier.
Ensuite, j'ai redémarré tous les services liés à SQL (étape 1) à partir des services Windows.
Démarrage de mon studio de gestion MS SQL avec une connexion normale.
Faites un clic droit sur la base de données coupable et appuyez sur Supprimer (pour supprimer la base de données du tout).
Tous les fichiers LDF et MDF liés à cette base de données sont passés du dossier DATA (mentionné à l'étape 2).
Création d'une nouvelle base de données avec le même nom (même nom que celui que j'ai supprimé à l'étape 6 - la base de données coupable).
Ensuite, [nom de la base de données] -> clic droit -> tâches -> Take Offline.
J'ai ensuite copié les deux fichiers (à partir de l'étape 3) dans le dossier DATA (étape 2).
[nom de la base de données] -> clic droit -> tâches -> Mettre en ligne.
J'ai eu un . dans la base de données, et la requête n'a pas fonctionné à cause de cela (en disant syntaxe incorrecte près de '.'). J'ai alors réalisé qu'il me fallait un crochet pour le nom:
RESTORE DATABASE [My.DB.Name] WITH RECOVERY
Dans mon cas, il suffisait de supprimer la base de données qui était suspendue dans l'état "Restauration ..." avec la commande SQL
drop database <dbname>
dans une fenêtre de requête.
Ensuite, j'ai cliqué avec le bouton droit sur Bases de données et sélectionné Actualiser qui a supprimé l'entrée dans Management Studio. Ensuite, j'ai effectué une nouvelle restauration qui a bien fonctionné (notez que la mise hors ligne ne fonctionnait pas, qu'un redémarrage du service SQL ne fonctionnait pas, un redémarrage du serveur ne fonctionnait pas aussi bien).
Par défaut, chaque RESTORE DATABASE est livré avec la configuration RECOVERY. L’option 'NORECOVERY' indique en gros à SQL Server que la base de données attend d’autres fichiers de restauration (par exemple, un fichierDIFFet un fichierLOGet peut inclure enregistrer le fichier de sauvegarde, si possible) . Les options 'Récupération' terminent toutes les transactions et laissent la base de données prête à effectuer des transactions.
Alors:
- si votre base de données est configurée avecSIMPLEmodèle de récupération, vous pouvez uniquement exécuter une optionCOMPL&EGRAVE;TErestauration avec
NORECOVERY, lorsque vous disposez d'une sauvegardeDIFF. AucunJOURNALsauvegarde n'est autorisé dansSIMPLEmodèle de récupération de base de données. - Sinon, si votre base de données est configurée avec le modèle de récupérationFULLou BULK-LOGGED , vous pouvez effectuer unFULLrestore suivi de
NORECOVERYoption, puis effectuez unDIFF.suivi deNORECOVERYet, enfin, exécutez l'optionLOGrestore avecRECOVERY.
Rappelez-vous, LA DERNIÈRE RECHERCHE DE RESTAURATION DOIT AVOIR RECOVERY OPTION . Ce pourrait être une manière explicite ou non. Dans les versions de T-SQL, la situation:
USE [master] GO RESTORE DATABASE Database_name FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, RECOVERY -- This option could be omitted. GO
L’option WITH REPLACE doit être utilisée avec précaution car elle peut entraîner une perte de données
Ou, si vous effectuez une sauvegarde FULL et DIFF, vous pouvez utiliser cette
USE [master]
GO
RESTORE DATABASE Database_name
FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1,
NOUNLOAD,NORECOVERY
GO
RESTORE DATABASE Database_name
FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1,
NOUNLOAD, RECOVERY
GO
USE [master] GO -- Perform a Tail-Log backup, if possible. BACKUP LOG Database_name GO -- Restoring a FULL backup RESTORE DATABASE Database_name FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY GO -- Restore the last DIFF backup RESTORE DATABASE Database_name FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1, NORECOVERY,NOUNLOAD GO -- Restore a Log backup RESTORE LOG Database_name FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2, RECOVERY, NOUNLOAD GO
Bien entendu, vous pouvez effectuer une restauration avec l'option STATS = 10 qui indique à SQL Server de générer un rapport tous les 10% terminés.
Si vous préférez, vous pouvez observer le processus ou restaurer en temps réel la requête .
USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO
J'espère que cette aide.
J'ai eu ce problème lorsque j'ai également reçu une erreur TCP dans le journal des événements ...
Supprimez la base de données avec SQL ou cliquez dessus avec le bouton droit de la souris dans le gestionnaire "Supprimer"
J'ai effectivement commencé à le faire par défaut. Script de la base de données déposer, recréer puis restaurer.
Il peut également y avoir un problème lors de la suppression d'une base de données bloquée si l'instantané est activé. Pour moi cela a fonctionné:
- J'ai d'abord suivi Tipu Delacablu steps (lire quelques posts)
- exécuter la commande: drop database [votre base de données], ce qui vous donnera une erreur en vous indiquant le nom de la base de données instantanée
- exécutez la commande: déposer la base de données [base de données instantané], puis exécutez à nouveau la commande à l'étape 2.
Avez-vous essayé d'exécuter une vérification uniquement? Juste pour m'assurer que c'est une sauvegarde saine.
Bonne discussion. L’erreur la plus courante commise par un nombre maximum d’utilisateurs est de restaurer la base de données avec l’option de récupération disposant de plusieurs sauvegardes. Cela rend la base de données dans l'état RESTORING.
Si vous effectuez une récupération ponctuelle, commencez par restaurer avec NoRecovery. Avec la dernière option de sauvegarde, vous devez utiliser la restauration avec Recovery.
Lisez référence1 et référence2 à propos de la sauvegarde et de la restauration.
J'ai eu le même problème ... bien que je ne sais pas pourquoi ma base de données a rencontré ce problème car mon lecteur n'était pas plein ... C'est comme si elle avait été corrompue ou quelque chose du genre. J'ai essayé toutes les solutions ci-dessus. Aucune d'entre elles n'a pleinement fonctionné. J'ai surtout pensé que la suggestion de mettre fin au service et de supprimer les fichiers mdf et ldf fonctionnerait ... mais que la restauration était toujours bloquée?
J'ai finalement résolu le problème en supprimant les fichiers comme indiqué, mais au lieu d'essayer de restaurer la base de données, j'ai copié de nouveaux fichiers .mdf et .ldf et les ai joints à l'aide de l'assistant de pièce jointe frontale. Relief, ça a marché !!
Il a fallu TOUJOURS copier les nouveaux fichiers lorsque j'utilise une machine virtuelle ... donc copier et coller à l'aide du presse-papiers a pris environ une heure, je ne le recommanderais donc qu'à la dernière tentative.
J'ai le cas MyDbName (Restoring ...) en raison de la limite de licence de SQL Express.
Dans le fichier journal, j'ai trouvé ceci:
CREATE DATABASE ou ALTER DATABASE a échoué car le résultat la taille cumulée de la base de données serait supérieure à votre limite de licence de 10240 Mo} _ par base de données.
Ainsi, si vous essayez de restaurer une base de données plus grande, vous devez basculer votre serveur SQL Express vers la version Developer} _ par exemple.
Toutes les options basées sur WITH RECOVERY ne fonctionnaient pas pour moi.
Ce qui a été fait était de faire la restauration complète à partir de Management Studio.
USE [master]
RESTORE DATABASE Sales_SSD
FROM DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak'
WITH FILE = 1,
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',
NOUNLOAD, REPLACE, STATS = 5
- Laissez vérifier et exécuter le service d'agent SQL en premier.
En utilisant T-SQL suivant:
SELECT nom de fichier FROM master.sys.sysaltfiles WHERE dbid = DB_ID ('nom_bdd');
Utilisation continue de T-SQL:
RESTORE DATABASE FROM DISK = 'DB_path' WITH RESTART, REPLACE;
J'espère que cette aide!
RESTORE DATABASE {DatabaseName}
FROM DISK = '{databasename}.bak'
WITH REPLACE, RECOVERY
Ce qui a réglé ça pour moi était
- arrêter l'instance
- créer une sauvegarde des fichiers .mdf et .ldf dans le dossier de données
- Redémarrez l'instance
- supprimer la base de données bloquée la restauration
- remettez les fichiers .mdf et.ldf dans le dossier de données
- Attachez l'instance aux fichiers .mdf et .ldf