SQL Server 2k5 - резервное копирование базы данных без файлов журнала

Question

Файлы журнала часто бывают большими и громоздкими. Есть ли способ «сделать резервную копию» базы данных SQL Server без каких-либо файлов журнала (или с пустыми файлами журнала)?

Answer 1

Части журнала фактически включены в резервную копию. Это то, как вы получаете последовательность при восстановлении. Страницы, которые изменяются во время выполнения резервного копирования, извлекаются из журнала (или зарегистрированных изменений), а затем применяются в конце процесса восстановления.

Вы не можете обойти это, но вы можете ограничить объем ведения журнала SQL Server. Вы делаете это, переводя базу данных в простой режим, но если вы делаете это, то понимаете, что вы не сможете восстановить ее до того времени, когда кто-то выпустит на

delete myTable

и забыл предложение WHERE. Вы можете восстановиться только после полного резервного копирования.

Вам нужно регулярно выполнять резервное копирование базы данных (с помощью команды BACKUP DATABASE), а также чаще запускать команды BACKUP LOG. Обычно люди каждую ночь создают полное резервное копирование небольших баз данных, а затем регистрируют резервное копирование каждый час. Это позволяет восстанавливать данные в любой точке в течение дня, при условии сохранения всех этих файлов резервных копий.

Он также управляет размерами файла журнала, поскольку команда BACKUP LOG освобождает пространство в файлах журнала для повторного использования.

Answer 2

Извините, но ваш вопрос не имеет смысла.

Когда вы создаете резервную копию базы данных, вы резервируете данные страниц из файлов данных (MDF и NDF), не файла (ов). Затем механизм добавляет любые изменения (из журнала записей ), которые произошли во время резервного копирования.

Записи журнала (, а не файлы) резервируются с помощью BACKUP LOG. Это не нужно, если база данных имеет простую модель восстановления.

Когда вы восстанавливаете БД, то она воссоздает файлы на диске. Это то, что вы имеете в виду?

Сам файл журнала абсолютно необходим для работы всех СУБД.

Единственный вопрос здесь заключается в том, как выполнить их резервное копирование / восстановление в контексте стратегии BCP / DR.

Answer 3

Непосредственно перед созданием полной резервной копии базы данных выполните:

BACKUP LOG databasename WITH TRUNCATE_ONLY

Причина, по которой это делается раньше, заключается в том, что будущая резервная копия журнала будет по-прежнему сохранять согласованность на определенный момент времени. Таким образом, у вас всегда будет действительная цепочка (в любом случае, начиная с этой полной резервной копии - TRUNCATE будет препятствовать выполнению восстановления на определенный момент времени, поскольку при каждом последнем резервном копировании журнала, хотя все ваши резервные копии только для данных будут все еще будет в силе).