Question

Je reculai 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 coincé 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 il devait être roulé en utilisant l'avant:

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 ensemble de données et le 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
Était-ce utile?

La solution

Vous devez utiliser l'option WITH RECOVERY, avec votre commande RESTORE de base de données, d'apporter votre base de données en ligne dans le cadre du processus de restauration.

Ceci est bien sûr que si vous ne souhaitez pas restaurer les sauvegardes du journal des transactions, à savoir que vous ne souhaitez restaurer une sauvegarde de base de données et être en mesure d'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 sucess à l'aide de l'assistant de base de données de restauration 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.

Autres conseils

J'ai eu cette situation restaurer une base de données à un SQL Server 2005 Standard Edition instance en utilisant Symantec Backup Exec 11d. Une fois la base de données a terminé la tâche de restauration est restée dans un état « Restauration ». Je n'avais pas d'espace disque issues-- la base de données n'a tout simplement pas sortir de l'état « Restauration ».

J'ai couru la requête suivante sur l'instance SQL Server et a constaté que la base de données est immédiatement devenu utilisable:

RESTORE DATABASE <database name> WITH RECOVERY

Voici comment vous le faites:

  1. Arrêtez le service (MSSQLSERVER);
  2. renommer ou supprimer la base de données et fichiers journaux (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) ou chaque fois que vous avez les fichiers;
  3. Démarrez le service (MSSQLSERVER);
  4. Supprimer la base de données avec le problème;
  5. Restauration à nouveau la base de données.

J'ai eu un incident similaire avec l'arrêt d'un journal expédition serveur secondaire. Une fois la commande pour supprimer le serveur d'envoi de journaux et arrêté le journal d'expédition du serveur principal de la base de données sur le serveur secondaire est resté coincé dans l'état restauration après la commande

RESTORE DATABASE <database name> WITH RECOVERY

Les messages de base de données:

  

RESTORE DATABASE traitée avec succès 0 pages en 18.530 secondes   (0,000 Mo / sec).

La base de données a été à nouveau utilisable après ces 18 secondes.

J'ai eu un problème similaire avec la restauration en utilisant SQL Management Studio. J'ai essayé de restaurer une sauvegarde de la base de données à une nouvelle avec un nom différent. Au début, cela a échoué et après avoir fixé le nouveau noms de fichiers de base de données, il a été réalisé avec succès - en tout cas la question que je décris ont refait même si je suis arrivé ce droit dès la première fois. Ainsi, après la restauration, la base de données d'origine est resté avec (... Restauration) à côté de son nom. Compte tenu des réponses du forum ci-dessus (Bhusan de) J'ai essayé en cours d'exécution dans l'éditeur de requête sur le côté qui suit:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

qui fixe la question. J'avais du mal au début à cause du nom de base de données contenant des caractères spéciaux. Je résolus en ajoutant des guillemets doubles autour -. Guillemets simples ne fonctionneraient pas donner une erreur « syntaxe incorrecte près ... »

Ce fut la solution minimale que j'ai essayé de résoudre ce problème (base de données coincé dans le rétablissement de l'état) et j'espère qu'il peut être appliqué à d'autres cas.

OK, j'ai le même problème et exactement comme il était dans le cas de Pauk, il a été causé par le serveur exécutant d'espace disque lors de la restauration et ainsi provoqué un état de restauration permanente. Comment mettre fin à cet état sans arrêter les services SQL Server?

Je l'ai trouvé une solution:)

Drop database *dbname*

option de récupération est utilisé par défaut lorsque RESTORE DATABASE / RESTORE LOG commande est exécutée. Si vous êtes coincé dans le processus « restauration » vous pouvez ramener une base de données à l'état en ligne en exécutant:

RESTORE DATABASE YourDB WITH RECOVERY
GO

S'il y a un besoin de plusieurs fichiers restauration, commandes CLI nécessite NORECOVERY et AVEC RÉCUPÉRATION respectivement - que le dernier fichier de 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 utiliser l'Assistant SQL Server Management Studio également:

entrer image description ici

Il y a aussi processus de restauration virtuelle, mais vous devrez utiliser des solutions 3ème partie. Habituellement, vous pouvez utiliser une sauvegarde de base de données comme base de données en ligne en direct. ApexSQL et Idera a ses propres solutions. Examen par SQL Marteau à propos ApexSQL Restore . Virtual restauration 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 disque. Vous pouvez jeter un oeil sur infographique ici pour une comparaison.

Cela peut être assez évident, mais il me trébuché tout à l'heure:

Si vous prenez une sauvegarde de fichier journal de queue, cette question peut aussi être causée par avoir coché cette option dans les SSMS assistant de restauration - « Laissez base de données source dans l'état de restauration (NORECOVERY) »

entrer image description ici

Je me suis dit pourquoi.

Si le client qui a émis la commande de RESTORE DATABASE se déconnecte lors de la restauration, la restauration sera bloqué.

Il est étrange que le serveur, quand on lui dit de restaurer une base de données par une connexion client, ne sera pas terminer la restauration, à moins que le client reste connecté tout le temps.

celui-ci a fait le travail:

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

J'ai eu une situation où ma base de données a montré la restauration de l'état et je ne pouvais pas courir des questions et ne pouvait pas se connecter avec notre logiciel.

Qu'est-ce que je l'ai fait sortir de cette situation est:

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

  2. J'ai ouvert le dossier DATA où les fichiers LDF et Mdf trouve dans le répertoire SQL, normalement son comme: « C: \ Program Files \ *********** MSSQL \ DATA

  3. Je copié les fichiers LDF et Mdf de la base de données:    [Nom db] .mdf et [nom db] _log.ldf

Je recopié ces deux fichiers dans un autre dossier.

  1. Alors j'ai commencé à tous les services liés à SQL (à l'étape 1) à nouveau des services Windows.

  2. Started mon studio de gestion MS SQL avec connexion normale.

  3. Faites un clic droit sur la base de données coupable et a frappé SUPPR (pour supprimer la base de données du tout).

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

  5. Crée une nouvelle base de données avec le même nom (même nom de l'une I supprimé à l'étape 6 - la base de données coupable).

  6. Alors, [nom de la base de données] -> clic droit -> Tâches -.> Déconnecter

  7. I alors copié à la fois des fichiers (de l'étape 3) retour au dossier de données (étape 2).

  8. [nom de base de données] -> clic droit -> Tâches -.> Mettre en ligne

J'ai eu. en mon nom de base de données, et la requête ne fonctionne pas à cause de cela (en disant syntaxe incorrecte près « ») Puis j'ai réalisé que je besoin d'un support pour le nom:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Dans mon cas, il suffisait de abandonner la base de données qui a été suspendu dans l'état "Restauration ..." avec la commande SQL

 drop database <dbname> 

dans une fenêtre de requête.

Alors je droit cliqué avec le bouton Bases de données et sélectionné Actualiser qui a supprimé l'entrée dans Management Studio. Par la suite, je l'ai fait une nouvelle restauration qui a bien fonctionné (notez que l'amenant ne fonctionne pas en mode hors connexion, un redémarrage du service SQL ne fonctionne pas, un redémarrage du serveur ne fonctionne pas aussi bien).

Je l'ai eu ce problème quand je a également reçu une erreur de TCP dans le journal des événements ...

Laissez tomber le DB avec sql ou faites un clic droit sur elle dans le gestionnaire « supprimer » Et encore une fois la restauration.

Je l'ai fait commencé à le faire par défaut. Script de la chute DB, recréent puis restaurer.

Par défaut, chaque RESTORE DATABASE est livré avec RECOVERY mis en place. Les options « norecovery », indique essentiellement le serveur SQL que la base de données est en attente pour plus de restaurer des fichiers (peut-être un fichier DIFF et LOG fichier et, pourrait inclure la queue-log fichier de sauvegarde, si possible). Les options « RECOVERY », finissent toutes les transactions et laissez la base de données prêts à effectuer des transactions.

  1. si votre base de données est configuré avec SIMPLE modèle de récupération, vous ne pouvez effectuer une FULL restauration avec l'option NORECOVERY, lorsque vous avez un DIFF sauvegarde. Non LOG sauvegarde sont autorisés dans SIMPLE base de données de modèle de récupération.
  2. Dans le cas contraire, si votre base de données est configuré avec FULL ou VRAC-LOGGED modèle de récupération, vous pouvez effectuer une FULL restore suivie NORECOVERYoption , puis effectuer une DIFF suivie NORECOVERY, et, enfin, effectuer LOG restauration avec l'option RECOVERY.

Rappelez-vous, LE DERNIER DOIT AVOIR RESTORE QUERY OPTION RECOVERY . Il pourrait être une manière explicite ou non. Dans thermies 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

option REPLACE doit être utilisé avec précaution car il peut conduire à la perte de données

Ou, si vous effectuez une sauvegarde complète et DIFF, vous pouvez utiliser

   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 au serveur SQL de faire rapport tous les 10% complété.

Si vous préférez, vous pouvez observer le processus ou de restauration dans la requête en fonction 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

Espérons que cela aide.

  1. Laissez vérifier et exécuter service SQL Agent d'abord.
  2. Utilisation de T-SQL suivante:

    SELECT nom     DE master.sys.sysaltfiles     WHERE dbid = DB_ID ( 'nom_base');

  3. Utilisation de T-SQL en continu:

    RESTAURER LA BASE DE DONNÉES DE = DISK 'db_path' AVEC RESTART, REMPLACER;

Espérons que cela aide!

Toutes les options de récupération basé AVEC ne fonctionne pas pour moi.

Qu'est-ce que devait faire la restauration complète 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

J'ai eu le même problème ... même si je ne sais pas pourquoi ma base de données a connu ce problème que mon disque était pas plein ... Il est comme il a été corrompu ou quelque chose. J'ai essayé tout ce qui précède qu'aucun d'entre eux entièrement travaillé, je pensais surtout la suggestion d'arrêter le service et la suppression des fichiers mdf et LDF travailleraient ... mais il a gelé encore sur la restauration?

J'ai fini par résoudre ce problème en supprimant les fichiers comme mentionné, mais au lieu d'essayer de restaurer la DB à nouveau je copiais sur frais .mdf et .ldf et attaché ces aide de l'assistant de fixation frontal. Relief, il a travaillé !!

Il a fallu une éternité pour copier les nouveaux fichiers que je suis en utilisant une machine virtuelle ... donc copier et coller le presse-papiers comme une heure a pris lui-même donc je ne recommanderais cela comme une dernière tentative.

J'ai MyDbName (restauration ...) cas en raison de SQL Express sous licence limite.

Dans le fichier journal, je trouve ceci:

  

CREATE DATABASE ou ALTER DATABASE a échoué car résultant   la taille de la base de données cumulative serait dépasser votre limite autorisée de 10240 MB   par la base de données.

Donc, si vous essayez de restaurer une base de données plus grande, vous avez besoin de changer votre serveur SQL Express Developer Edition par exemple.

Ce qu'il fixe pour moi était

  1. arrêter l'instance
  2. créer une sauvegarde des fichiers .mdf et .ldf dans le dossier de données
  3. Redémarrez l'instance
  4. supprimer la base de données coincé restauration
  5. mettre les fichiers .mdf and.ldf de nouveau dans le dossier de données
  6. Joindre l'instance à l'.mdf et .ldf fichiers
RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top