Мне был предоставлен файл резервной копии .bak сервера MS-SQL для восстановления на моем компьютере, который был размером около 25 МБ, но требовал 10 ГБ свободного дискового пространства, потому что файл журнала был такого размера, что указывает на то, что файл журнала не восстанавливается ни усеченный. (Обратите внимание, что файл журнала 10 ГБ должен быть в основном пустым, иначе файл .bak будет намного больше 25 МБ)
Эта база данных предназначена для мало используемой (и, возможно, не очень важной) базы данных, и на том же сайте есть еще одна гораздо более важная и гораздо большая база данных (размер где-то около 5 ГБ), которая имеет файл журнала меньшего размера, поэтому я предполагая, что файл журнала для этой базы данных обрезается.
Мне сказали, что сайт использует доставку журналов для резервного копирования своей основной базы данных на второй сервер, но я не уверен, выполняется ли резервное копирование меньшей базы данных.
Итак, я предполагаю, что либо они используют доставку журналов только для основной базы данных, либо они создают резервную копию только основной базы данных.
Это вызывает несколько вопросов
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, чтобы переместить файл журнала на этот диск, затем сжать журнал и переместить журнал. файл из временного хранилища (предостережения о том, следует ли вам сокращать журнал или не применять!).