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'est parce qu'il n'y avait pas de fichier journal dans la sauvegarde, et qu'il devait être restauré en utilisant:

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' WITH RECOVERYoption, avec votre RESTOREcommande de base de données , 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 des sauvegardes du journal des transactions, c'est-à-dire que vous souhaitez uniquement restaurer une sauvegarde de la base de données et ensuite pouvoir accéder à la base de données.

Votre commande devrait ressembler à ceci,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

Vous pouvez avoir plus de succès à l'aide de l'assistant de restauration de base de données dans SQL Server Management Studio. De cette façon, vous pouvez sélectionner les emplacements de fichiers spécifiques, l'option de remplacement et l'option AVEC récupération.

J'ai eu cette situation en restaurant une base de données sur une instance SQL Server 2005 Standard Edition à l'aide de Symantec Backup Exec 11d. Une fois le travail de restauration terminé, la base de données est restée dans un état "Restauration". Je n'ai eu aucun problème d'espace disque - la base de données n'est tout simplement pas sortie de l'état "Restauration".

J'ai exécuté la requête suivante sur l'instance SQL Server et j'ai constaté que la base de données était immédiatement utilisable:

RESTORE DATABASE <database name> WITH RECOVERY

Voici comment procéder:

1. Arrêtez le service (MSSQLSERVER);
2. Renommez ou supprimez la base de données et les fichiers journaux (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) ou partout où vous avez les fichiers;
3. Démarrez le service (MSSQLSERVER);
4. Supprimez la base de données avec problème;
5. Restaurez à nouveau la base de données.

J'ai eu un incident similaire avec l'arrêt d'un serveur secondaire d'envoi de journaux. Après la commande de suppression du serveur de l'envoi de journaux et de l'arrêt de l'envoi de journaux du serveur principal, la base de données sur le serveur secondaire est restée bloquée dans l'état de restauration après la commande

RESTORE DATABASE <database name> WITH RECOVERY

Les messages de la base de données:

RESTORE DATABASE a traité correctement 0 pages en 18,530 secondes (0,000 Mo / sec).

La base de données était de 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 dans une nouvelle avec un nom différent. Au début, cela a échoué et après avoir corrigé les noms de fichiers de la nouvelle base de données, il a été exécuté avec succès - en tout cas, le problème que je décris est réapparu même si j'ai bien compris 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. Compte tenu des réponses du forum ci-dessus (Bhusan's), j'ai essayé d'exécuter dans l'éditeur de requêtes sur le côté ce qui suit:

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 une erreur "syntaxe incorrecte près de ...".

C'était la solution minimale que j'ai essayée pour résoudre ce problème (base de données bloquée en état de restauration) et j'espère qu'elle pourra être appliquée à plus de cas.

OK, j'ai un problème similaire et exactement comme dans le cas de Pauk, il a été causé par le manque d'espace disque du serveur lors de la restauration et a donc provoqué un état de restauration permanent. Comment mettre fin à 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

S'il est nécessaire de restaurer plusieurs fichiers, les commandes CLI nécessitent respectivement AVEC NORECOVERY et WITH RECOVERY - seul le dernier fichier dans la commande doit avoir AVEC RECOVERY pour ramener 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 en direct. ApexSQL et Idera ont leurs propres solutions. Revue par SQL Hammer sur ApexSQL Restore . La restauration virtuelle est une bonne solution si vous avez affaire à 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 œil sur l' infographie ici pour une comparaison.

Cela peut être assez évident, mais cela m'a fait trébucher tout à l'heure:

Si vous effectuez une sauvegarde de journal de fin, ce problème peut également être dû au fait que cette option est cochée dans l'assistant de restauration SSMS - «Laisser la base de données source à l'état de restauration (AVEC NORCOVERY)»

J'ai compris pourquoi.

Si le client qui a émis la RESTORE DATABASEcommande se déconnecte pendant la restauration, la restauration 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 ne reste connecté tout le temps.

celui-ci a fonctionné:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

J'ai eu une situation où ma base de données montrait un état de restauration et je ne pouvais pas exécuter de requêtes et ne pouvais pas me connecter avec notre logiciel.

Ce que j'ai fait pour sortir de cette situation, c'est:

1. Arrêtez tous les services liés à SQL à partir des services Windows.

2. J'ai ouvert le dossier DATA où se trouvent les fichiers Ldf et Mdf dans le répertoire SQL, normalement son genre: "C: \ Program Files *********** \ MSSQL \ DATA

3. J'ai ensuite copié les fichiers Ldf et Mdf de la base de données: [nom db] .mdf et [nom db] _log.ldf

J'ai copié ces deux fichiers dans un autre dossier.

4. Ensuite, j'ai redémarré tous les services liés à SQL (à l'étape 1) à partir des services Windows.

5. Démarré mon studio MS SQL Management avec une connexion normale.

6. Faites un clic droit sur la base de données coupable et appuyez sur SUPPRIMER (pour supprimer la base de données).

7. Tous les fichiers LDF et MDF liés à cette base de données sont passés du dossier DATA (mentionné à l'étape 2).

8. 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).

9. Puis [nom de la base de données] -> clic droit -> tâches -> Déconnecter.

10. J'ai ensuite copié les deux fichiers (de l'étape 3) dans le dossier DATA (étape 2).

11. [nom de la base de données] -> clic droit -> tâches -> Mettre en ligne.

J'ai eu un . dans mon nom de base de données, et la requête n'a pas fonctionné à cause de cela (en disant syntaxe incorrecte près de '.') Ensuite, j'ai réalisé que j'avais besoin d'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 pendait dans l'état "Restauration ..." avec la commande SQL

 drop database <dbname> 

dans une fenêtre de requête.

J'ai ensuite cliqué avec le bouton droit sur Bases de données et sélectionné Actualiser, ce qui a supprimé l'entrée dans Management Studio. Ensuite, j'ai fait une nouvelle restauration qui a bien fonctionné (notez que la mise hors ligne ne fonctionnait pas, un redémarrage du service SQL ne fonctionnait pas, un redémarrage du serveur ne fonctionnait pas aussi bien).

J'ai eu ce problème lorsque j'ai également reçu une erreur TCP dans le journal des événements ...

Déposez la base de données avec sql ou faites un clic droit dessus dans le gestionnaire "supprimer" Et restaurer à nouveau.

J'ai en fait commencé à le faire par défaut. Créez un script pour la suppression de la base de données, recréez puis restaurez.

Par défaut, tout RESTORE DATABASEest livré avec la RECOVERYconfiguration. Les options «NORECOVERY» indiquent essentiellement à SQL Server que la base de données attend plus de fichiers de restauration (peut être un fichier DIFF et un fichier LOG et, si possible, inclure un fichier de sauvegarde du journal de fin). Les options 'RECOVERY', terminent toutes les transactions et laissent la base de données prête à effectuer des transactions.

Donc:

1. si votre base de données est configurée avec le modèle de récupération SIMPLE , vous ne pouvez effectuer une restauration COMPLÈTE avec NORECOVERYoption que lorsque vous disposez d'une sauvegarde DIFF . Aucune sauvegarde de LOG n'est autorisée dans la base de données du modèle de récupération SIMPLE .
2. Sinon, si votre base de données est configurée avec le modèle de récupération FULL ou BULK-LOGGED , vous pouvez effectuer une restauration FULL suivie d'une NORECOVERYoption, puis effectuer un DIFF suivi NORECOVERYet enfin, effectuer une restauration LOG avec RECOVERYoption.

N'oubliez pas, LA DERNIÈRE REQUÊTE DE RESTAURATION DOIT AVOIR UNE RECOVERYOPTION . Cela pourrait être explicite ou non. Dans les thermes de T-SQL, la situation:

1.

 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 prudence car elle peut entraîner une perte de données

Ou, si vous effectuez une sauvegarde COMPLÈTE et DIFF, vous pouvez utiliser ceci

   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

 2. 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 sûr, vous pouvez effectuer une restauration avec l'option STATS = 10 qui indique à SQL Server de signaler tous les 10% achevés.

Si vous préférez, vous pouvez observer le processus ou restaurer dans une requête en temps réel. Comme suit:

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.

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é:

1. J'ai d'abord suivi les étapes de Tipu Delacablu (lire quelques articles)
2. exécuter la commande: drop database [your database], qui vous donnera une erreur vous indiquant le nom de la base de données de clichés
3. exécuter la commande: supprimez la base de données [base de données d'instantanés], puis réexécutez la commande à l'étape 2.

Avez-vous essayé de lancer un VERIFY UNIQUEMENT? Juste pour être sûr qu'il s'agit d'une sauvegarde audio.

http://msdn.microsoft.com/en-us/library/ms188902.aspx

J'ai le cas MyDbName (Restoring ...) en raison de la limite de licence SQL Express.

Dans le fichier journal, j'ai trouvé ceci:

CREATE DATABASE ou ALTER DATABASE a échoué car la taille de base de données cumulée résultante dépasserait votre limite de licence de 10240 Mo par base de données.

Donc, si vous essayez de restaurer une base de données plus grande, vous devez par exemple basculer votre serveur SQL Express vers l'édition Developer .

Ran dans un problème similaire lors de la restauration de la base de données en utilisant SQL Server Management Studio et il est resté bloqué en mode de restauration. Après plusieurs heures de suivi des problèmes, la requête suivante a fonctionné pour moi. La requête suivante restaure la base de données d'une sauvegarde existante à un état précédent. Je crois que le hic, c'est d'avoir le fichier .mdf et .log dans le même répertoire.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

1. Laissez d'abord vérifier et exécuter le service d'agent SQL.

2. Utilisation du T-SQL suivant:

   SELECT nom de fichier FROM master.sys.sysaltfiles WHERE dbid = DB_ID ('db_name');

3. Utilisation continue de T-SQL:

   RESTORE DATABASE FROM DISK = 'DB_path' AVEC RESTART, REPLACE;

J'espère que cette aide!

Toutes les options basées sur WITH RECOVERY ne fonctionnaient pas pour moi.

Ce qui a été fait pour effectuer la restauration complète depuis 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

J'ai eu le même problème ... bien que je ne sache pas pourquoi ma base de données a rencontré ce problème car mon lecteur n'était pas plein ... C'est comme s'il était corrompu ou quelque chose. J'ai essayé toutes les solutions ci-dessus, aucune d'entre elles ne fonctionnait pleinement, je pensais surtout que la suggestion d'arrêter le service et de supprimer les fichiers mdf et ldf fonctionnerait ... mais elle a quand même gelé lors de la restauration?

J'ai fini par résoudre ce problème en supprimant les fichiers comme mentionné, mais au lieu d'essayer de restaurer à nouveau la base de données, j'ai copié des fichiers .mdf et .ldf frais et les ai joints à l'aide de l'assistant de pièce jointe frontale. Le soulagement, ça a marché !!

Il a fallu FOREVER pour copier sur les nouveaux fichiers car j'utilise une machine virtuelle ... donc copier et coller en utilisant le presse-papiers a pris comme une heure, donc je ne recommanderais cela que comme une dernière tentative.

Ce qui m'a arrangé, c'est

1. arrêter l'instance
2. création d'une sauvegarde des fichiers .mdf et .ldf dans le dossier de données
3. Redémarrez l'instance
4. supprimer la restauration de la base de données bloquée
5. remettez les fichiers .mdf et.ldf dans le dossier de données
6. Attachez l'instance aux fichiers .mdf et .ldf

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Utilisez la commande suivante pour résoudre ce problème

RESTORE DATABASE [DatabaseName] WITH RECOVERY