Восстановите резервную копию MSSQL, которая была сделана с параметром NO_LOG
Я пишу копию базы данных с одного сервера на другой. Оба работают под управлением 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).
3 ответа
Я полагаю, что самый простой способ сделать это - сжать журнал транзакций базы данных Frontend до его первоначального размера и сделать резервную копию базы данных, а затем увеличить журнал транзакций до приемлемого размера.
Вы должны делать это в спокойное время, когда происходит минимальная транзакционная активность.
Вам не нужно использовать NO_LOG с опцией COPY_ONLY, чтобы сделать это. Полного резервного копирования COPY_ONLY будет достаточно для восстановления с восстановлением. Когда вы восстанавливаете базу данных, она собирается создать файлы журнала и данных в тех размерах, которые были при создании резервной копии. Вы не можете обойти это. NO_LOG is truncating your transaction log, so you can't do a point in time recovery of your primary database after you run this. You need to start your backup set over by doing a standard full backup if you have issued this command.
Во-первых, здесь, кажется, есть некоторое заблуждение, что весь журнал транзакций (файл.ldf) попадает в ваш файл резервной копии. Это не вариант. SQL Server копирует достаточное количество журнала транзакций, чтобы операция восстановления могла восстановить базу данных.
Причина, по которой вы не можете восстановить базу данных, заключается в том, что вам нужно восстановить резервную копию журнала поверх резервной копии, которую вы только что восстановили, чтобы база данных могла выполнить восстановление. SQL Server не может перевести базу данных в оперативный режим из восстановления без резервного копирования журнала. Для получения дополнительной информации см. Эту статью MS KB.
Там нет никакого способа обойти это. Соси его и иди купи больше места на диске.