Я пишу сценарий копии баз данных с одного сервера на другой. Оба работают под управлением SQL Server 2005, и базы данных находятся в режиме полного восстановления.
Журналы транзакций в этих базах данных могут быть довольно большими, и они мне не нужны на сервере, на который они копируются. (т.е. мне не нужно иметь возможность восстановления в любой момент времени, мне просто нужна копия базы данных в момент выполнения резервного копирования). Поэтому, если возможно, я бы хотел избежать времени, затрачиваемого на создание резервной копии журнала, копирование через медленную сеть и восстановление.
Я пытаюсь использовать для этого вариант резервного копирования «NO_LOG». Это создает резервную копию нормально, но когда я пытаюсь восстановить резервную копию на целевом сервере, база данных остается в состоянии «Восстановление» и к ней нельзя получить доступ. Я предполагаю, что это потому, что он ожидает, что я восстановлю журналы транзакций.
Есть ли способ обойти это и создать новый пустой журнал транзакций? Обратите внимание, что я не могу просто обрезать журналы транзакций на исходном сервере, прежде чем делать резервную копию (без NO_LOG), поскольку они важны.
Если нет, то какие есть другие варианты получения копии базы данных, кроме резервного копирования / восстановления? Я уже пробовал метод «передачи», который записывает все объекты и данные в скрипт, но он слишком медленный для моих нужд из-за большого количества объектов.
Спасибо
Изменить: вот используемые команды
BACKUP DATABASE FrontEnd TO DISK='c:\somepath\abackup.bak' WITH NO_LOG, COPY_ONLY
RESTORE DATABASE FrontEnd FROM Disk='c:\somepath\abackup.bak' WITH RECOVERY
Ответ на эту команду:
Processed 1944 pages for database 'FrontEnd', file 'DimensionPrototype' on file 1.
The database cannot be recovered because the log was not restored.
This RESTORE statement successfully performed some actions, but the database could not be brought online because one or more RESTORE steps are needed. Previous messages indicate reasons why recovery cannot occur at this point.
RESTORE DATABASE ... FILE=<name> successfully processed 1944 pages in 0.923 seconds (17.253 MB/sec).
Для этого не нужно использовать NO_LOG с параметром COPY_ONLY. Для восстановления с восстановлением будет достаточно полной резервной копии COPY_ONLY. Когда вы восстанавливаете базу данных, она создает файлы журнала и данных с размерами, которые были при создании резервной копии. Вы не можете этого избежать. NO_LOG обрезает ваш журнал транзакций, поэтому вы не можете выполнить восстановление вашей первичной базы данных на определенный момент времени после его запуска. Если вы выполнили эту команду, вам необходимо начать создание резервной копии заново, выполнив стандартную полную резервную копию.
Во-первых, здесь, кажется, есть какое-то заблуждение, что весь журнал транзакций (файл .ldf) попадает в ваш файл резервной копии. Это не вариант. SQL Server копирует достаточно журнала транзакций, чтобы операция восстановления могла восстановить базу данных.
Причина, по которой вы не можете восстановить базу данных, заключается в том, что вам необходимо восстановить резервную копию журнала поверх только что восстановленной резервной копии, чтобы база данных могла выполнить восстановление. SQL Server не может перевести базу данных в оперативный режим из восстановления без резервной копии журнала. Для получения дополнительной информации см. Это статья ms kb.
Нет никакого способа обойти это. Успокойся и купи еще дисковое пространство.
Я ожидаю, что самый простой способ сделать это - уменьшить журнал транзакций вашей базы данных Frontend до исходного размера и сделать резервную копию базы данных, а затем увеличить журнал транзакций до подходящего размера.
Вы должны делать это в тихое время, когда транзакционная активность минимальна.