SQL Server 2012 Восстановление резервной копии на новое имя БД

16

Кажется, я помню, что в 2008 году вы могли восстановить резервную копию в новую копию БД, изменив имя в поле «База данных назначения» из мастера восстановления. Это создаст совершенно новую БД, которая является копией исходной БД, восстановленной до того момента времени, который вы хотели. Я до сих пор не понял, как заставить SQL 2012 сделать это.

Теперь я понимаю (благодаря Аарону Бертрану), что это не изменилось, и что 2012 год на самом деле делает для меня еще более очевидным, что эта стратегия была плохой идеей!

Итак, мне нужно сделать следующее: создать новую БД «MyDB_Copy» из существующей БД «MyDB», используя ее файлы резервных копий. У нас есть ночные полные резервные копии (.bak) и каждые 15 минут TLogs (.trn). Я не хочу, чтобы существующий «MyDB» был затронут / затронут вообще, потому что он «живой».

После создания MyDB_Copy из основного файла полной резервной копии мне нужно восстановить несколько десятков резервных копий TLog, чтобы получить его в определенный момент времени.

NateJ
источник
Можете ли вы или Аарон поделиться, почему это плохая идея? или ссылка на вопрос, где это объясняется?
Тронк
Я полагаю, что это что-то в том, что логические имена не меняются, и, таким образом, вы получите две БД в одном месте, которые имеют разные имена и физические файлы, но идентичные логические имена, что вызывает проблемы для планов обслуживания, которые зависят на логические имена. В моей ситуации эти восстановленные / скопированные БД никогда не длились дольше нескольких часов, но я понимаю, почему это не очень хорошая практика.
NateJ

Ответы:

18

Основываясь на примере E в документации , откройте новое окно запроса и выполните:

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';
-------------------------------------------^^^^^

Логические имена не важны; физические имена файлов. Это делает предположения о ваших логических именах файлов и о том, что их всего два; бежать, EXEC MyDB..sp_helpfile;чтобы быть уверенным.

Если вам нужно восстановить логи, то измените RECOVERYна NORECOVERY:

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

Тогда вы можете выпустить серию:

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

И на самом последнем:

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

Или, если вам нужна только часть журнала до определенного момента времени (я полагаю, вы проверили, где находятся номера LSN и время, чтобы точно знать, какие файлы вам нужны):

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

То, как вы сказали, работало в предыдущих версиях, никогда бы не сработало, если бы резервное копирование происходило с другого сервера. По умолчанию он пытается поместить новые файлы mdf и ldf в одно и то же место, а это невозможно.

Аарон Бертран
источник
Хорошо, это немного помогло. Теперь мне нужно восстановить несколько десятков файлов TRN, чтобы вернуть БД в состояние, в котором она была в пятницу вечером (полное резервное копирование происходит только ежедневно; резервное копирование TLog происходит каждые 15 минут). Используя ваш пример, я получил БД, созданную из основного файла BAK, но я получаю новую ошибку при попытке выполнить аналогичное утверждение для восстановления журнала. В нем говорится, что «журнал или дифференциальная резервная копия не могут быть восстановлены, потому что нет файлов, готовых к перемотке».
NateJ
@NateJ тогда тебе следует задать полный вопрос. :-)
Аарон Бертран
1
Круто, я печатаю это сейчас! Большое спасибо за Вашу помощь. Я огорчен тем, что получил несколько отрицательных повторений в StackOverflow, но если это сработает, оно того стоит.
NateJ
1
@NateJ Вы должны вернуть этого представителя, потому что вопрос был удален, когда он был перенесен (или будет в конечном итоге). Это был не я, но я подозреваю, что это было из-за вашего обвинения, что это работало в одной версии, но не сейчас, когда это явно просто неправильное понимание происходящего ...
Аарон Бертран
О, я понял. Нечто подобное работало раньше - возможно, я не помню точно, что / как, но я согласен, что это неправильно поняли. Мой коллега ругается вверх и вниз, но теперь, когда я думаю об этом, это не имеет смысла. Мы должны были сделать что-то по-другому, используя графический интерфейс. Я чувствую, что использование команд / скриптов, как вы предложили, будет лучше для нас. :) Логи восстанавливаются сейчас, пока успешно!
NateJ
0

Все, что вам нужно сделать, чтобы восстановить одну и ту же базу данных несколько раз, это изменить имя файлов на диске для этой базы данных. Очевидно, вам нужно присвоить базе данных другое имя для любой другой базы данных в SQL Server. В SSMS после того, как вы выбрали файл .bak для восстановления и ввели имя для базы данных, вы нажимаете «Файлы» в разделе «Выберите страницу» слева и просто меняете имя файлов на диске.

Ура Дуг

Doug
источник