Запросы на резервное копирование SQL, файлы журналов и доставку журналов
Мне дали резервную копию.bak-файла сервера MS-SQL для восстановления на моей машине, размер которого составлял около 25 МБ, но потребовалось 10 ГБ свободного дискового пространства, поскольку файл журнала был такого размера, что указывает на то, что файл журнала для них не восстанавливается ни усеченный. (Обратите внимание, что файл журнала 10 ГБ должен быть в основном пустым, иначе файл.bak будет намного больше, чем 25 МБ)
Эта база данных предназначена для мало используемой (и, возможно, не очень важной) базы данных, и на этом же сайте есть еще одна гораздо более важная и гораздо более крупная база данных (размер где-то в районе 5 Гб), которая имеет меньший файл журнала, поэтому я при условии, что файл журнала для этой базы данных урезается.
Мне сказали, что сайт использует доставку журналов для резервного копирования своей основной базы данных на второй сервер, но я не уверен, что резервная копия меньшей базы данных также создается.
Итак, я предполагаю, что либо они используют только доставку журналов для основной базы данных, либо они только выполняют резервное копирование основной базы данных.
Что поднимает несколько вопросов
- Существует ли какое-либо резервное копирование, которое пользователь / администратор на сайте может выполнить, которое мешает или нарушает доставку журналов?
- Если вы используете доставку журналов, достаточно ли этого, чтобы журналы не росли непрерывно, или вам все еще нужно делать резервные копии журналов (используя, например, план обслуживания)?
- Это не так уж важно, но если я когда-нибудь получу резервную копию, которой нужно больше места для файла журнала, чем у меня есть, есть ли способ восстановить его без файла журнала или без устранения проблемы в источнике и получения новой резервное копирование.
1 ответ
SQL фактически не изменяет размер журнала после резервного копирования журнала - вместо этого он просто изменяет внутренние метаданные, чтобы пометить части журнала (называемые виртуальными файлами журнала или VLF), которые можно использовать повторно. Этот процесс называется усечением журнала. Таким образом, ваш лог-файл будет расти, если не будет свободных VLF, но он никогда не уменьшится, если вы вручную не скажете SQL Server сделать это.
Поскольку размер журнала базы данных составляет 10 ГБ, восстановление резервной копии также создаст файл журнала 10 ГБ независимо от того, какой объем фактически используется. То же самое относится к любым файлам данных.
Вы можете сжать файл журнала с помощью команды " DBCC SHRINKFILE " - хотя, если вы не уверены, что размер журнала снова не увеличится до 10 ГБ, я рекомендую не делать этого (увеличение размера файла влияет на производительность). Длительные транзакции или операции по обслуживанию базы данных могут израсходовать большое количество журнала транзакций, поэтому стоит выяснить, почему размер журнала составляет 10 ГБ, прежде чем сжиматься.
Чтобы ответить на ваши 3 вопроса:
Существует ли какое-либо резервное копирование, которое пользователь / администратор на сайте может выполнить, которое мешает или нарушает доставку журналов?
Да - если вы разорвете цепочку резервного копирования, выполнив резервное копирование журнала в место назначения за пределами конфигурации доставки журналов, в результате резервное копирование не будет применено к дополнительному серверу. В этой ситуации вы должны использовать резервные копии COPY_ONLY, поскольку они не повредят цепочку журналов. Это относится только к резервным копиям журнала, поскольку полные резервные копии не усекают журнал.
Если вы используете доставку журналов, достаточно ли этого, чтобы журналы не росли непрерывно, или вам все еще нужно делать резервные копии журналов (используя, например, план обслуживания)?
Это должно быть хорошо, если только нет чего-то другого, что останавливает усечение журнала, такого как зеркальное отображение базы данных, длительные транзакции, репликация или даже создание снимка базы данных. Чтобы выяснить, почему ваш журнал не обрезается, нужно посмотреть на столбец log_reuse_wait_desc в sys.databases.
Также возможно (но маловероятно), что задание резервного копирования для доставки журналов выполняет резервное копирование с использованием COPY_ONLY/NO_TRUNCATE, что означает, что файл журнала будет непрерывно увеличиваться после заполнения.
Это не так уж важно, но если я когда-нибудь получу резервную копию, которой нужно больше места для файла журнала, чем у меня есть, есть ли способ восстановить его без файла журнала или без устранения проблемы в источнике и получения новой резервный.
Если вы сожмете файл журнала, то сделайте полную резервную копию, и при восстановлении SQL Server создаст базу данных, используя меньший файл журнала.
Если вы не можете сжать, но восстанавливаете на сервере разработки / тестирования, вы можете смонтировать некоторое временное хранилище и использовать "WITH MOVE" в вашем операторе RESTORE, чтобы переместить файл журнала на этот диск, затем сжать журнал и переместить журнал. файл из временного хранилища (предостерегает о том, следует ли вам сокращать журнал или не применять!).