Sauvegarde de restauration de SQL Server 2012 vers un nouveau nom de base de données


16

Je semble me souvenir qu'en 2008, vous pouviez restaurer une sauvegarde sur une nouvelle copie d'une base de données, en changeant le nom dans le champ "Destination Database" de l'assistant de restauration. Cela créerait une toute nouvelle base de données, qui est une copie de la base de données d'origine restaurée au moment voulu. Pour ma vie, je n'ai pas compris comment faire faire à SQL 2012 cela.

Maintenant, je comprends (grâce à Aaron Bertrand) que cela n'a pas vraiment changé, et que 2012 me rend en fait plus évident que cette stratégie était une mauvaise idée en premier lieu!

Donc, ce que je dois faire est le suivant: Créez une nouvelle base de données, 'MyDB_Copy', à partir d'une base de données existante, 'MyDB', en utilisant ses fichiers de sauvegarde. Nous avons des sauvegardes complètes nocturnes (.bak) et des TLogs toutes les 15 minutes (.trn). Je ne veux pas que le «MyDB» existant soit affecté / touché du tout, car il est «en direct».

Après la création de MyDB_Copy à partir du fichier principal de sauvegarde complète, je dois ensuite restaurer quelques dizaines de sauvegardes TLog pour le faire arriver à un certain moment.


Pouvez-vous ou Aaron partager pourquoi c'est une mauvaise idée? ou un lien vers le problème où il est expliqué?
Thronk

Je crois que c'est quelque chose à propos des noms logiques qui ne sont pas modifiés, et donc vous vous retrouveriez avec deux bases de données au même endroit qui ont des noms et des fichiers physiques différents mais des noms logiques identiques, ce qui pose des problèmes pour les plans de maintenance qui dépendent sur les noms logiques. Dans ma situation, ces bases de données restaurées / copiées n'ont jamais duré plus de quelques heures, mais je peux voir pourquoi ce n'est pas une bonne pratique.
NateJ

Réponses:


18

Basé sur l' exemple E de la documentation , ouvrez une nouvelle fenêtre de requête et exécutez:

RESTORE DATABASE MyDB_Copy FROM DISK = 'C:\blahblah\MyDB.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'MyDB' TO 'C:\blahblah\Data\MyDB_Copy.mdf',
---------------------------------------^^^^^
  MOVE 'MyDB_log' TO 'C:\blahblah\Data\MyDB_Copy.ldf';
-------------------------------------------^^^^^

Les noms logiques ne sont pas importants; les noms de fichiers physiques sont. Cela fait des hypothèses sur vos noms de fichiers logiques et qu'il n'y en a que deux; courir EXEC MyDB..sp_helpfile;pour être sûr.

Si vous devez restaurer des journaux, passez RECOVERYà NORECOVERY:

  WITH REPLACE, NORECOVERY,
----------------^^

Ensuite, vous pouvez émettre une série de:

RESTORE LOG MyDB_Copy FROM DISK = 'C:\blahblah\file1.trn' WITH NORECOVERY;

Et sur le tout dernier:

RESTORE LOG MyDB_Copy FROM DISK = 'C:\blahblah\fileN.trn' WITH RECOVERY;

Ou si vous n'avez besoin que d'une partie d'un journal jusqu'à un certain point dans le temps (je suppose que vous avez vérifié où se trouvent les LSN et les heures afin que vous sachiez exactement de quels fichiers vous avez besoin):

RESTORE LOG MyDB_Copy FROM DISK = 'C:\blahblah\fileN.trn' WITH 
  STOPAT = '<some point in time Friday>', RECOVERY;

La façon dont vous avez dit fonctionner dans les versions précédentes n'aurait jamais fonctionné, à moins que la sauvegarde ne provienne d'un autre serveur. Par défaut, il essaiera de placer les nouveaux fichiers mdf et ldf exactement au même endroit, ce qui n'est pas possible.


D'accord, cela a aidé un peu. Maintenant, je dois restaurer quelques dizaines de fichiers TRN pour remettre la base de données dans l'état où elle était vendredi soir (les sauvegardes complètes n'ont lieu que quotidiennement; les sauvegardes TLog ont lieu toutes les 15 minutes). À l'aide de votre exemple, j'ai obtenu la base de données créée à partir du fichier BAK principal, mais j'obtiens une nouvelle erreur lorsque j'essaie une instruction similaire pour restaurer le journal. Il indique que "le journal ou la sauvegarde différentielle ne peut pas être restauré car aucun fichier n'est prêt à être restauré".
NateJ

@NateJ, vous devriez alors poser une question complète. :-)
Aaron Bertrand

1
Génial, je le tape maintenant! Merci beaucoup pour votre aide. Je suis déçu d'avoir eu quelques représentants négatifs chez StackOverflow mais si cela fonctionne, cela en vaudra la peine.
NateJ

1
@NateJ Vous devriez récupérer ce représentant car la question a été supprimée lors de sa migration (ou le sera éventuellement). Ce n'était pas moi, mais je soupçonne que c'était à cause de votre accusation selon laquelle cela fonctionnait en une seule version, mais pas maintenant, alors que c'est clairement une mauvaise compréhension de ce qui se passait ...
Aaron Bertrand

Oh je me suis trompé. Quelque chose comme ça fonctionnait auparavant - je ne me souviens peut-être pas exactement de quoi / comment, mais je conviens que cela a été mal compris. Mon collègue jure de haut en bas, mais maintenant que j'y pense, cela n'a plus de sens. Nous devons avoir fait quelque chose de différent, en utilisant l'interface graphique. J'ai l'impression que l'utilisation des commandes / scripts comme vous l'avez suggéré va être meilleure pour nous. :) Les journaux sont en cours de restauration, avec succès jusqu'à présent!
NateJ

0

Tout ce que vous devez faire pour restaurer plusieurs fois la même base de données est de changer le nom des fichiers disque de cette base de données. De toute évidence, vous devez également donner à la base de données un nom différent de toute autre base de données dans SQL Server. Dans SSMS après avoir sélectionné le fichier .bak pour la restauration et tapé le nom de la base de données, vous cliquez ensuite sur «Fichiers» dans la section «Sélectionner une page» à gauche et changez simplement le nom des fichiers disque.

A bientôt Doug

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.