SQL Server 2008-сжатие журнала транзакций-любой способ автоматизации?

Я вошел и проверил свой журнал транзакций на днях, и это было что-то сумасшедшее, как 15GB. Я запустил следующий код:

USE mydb
GO
BACKUP LOG mydb WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE(mydb_log,8)
GO

который работал нормально, сжал его до 8 МБ...но БД, о которой идет речь, является издателем доставки журналов, и журнал уже резервное копирование до 500 МБ и быстро растет.

есть ли способ автоматизировать это сжатие журнала, помимо создания пользовательской задачи плана обслуживания "выполнить задачу инструкции T-SQL" и подключения ее к моему журналу задача резервного копирования? Если так, то хорошо...но я просто думал, что SQL Server будет иметь лучший способ справиться с этим. Я думал, что он должен сжиматься автоматически, когда вы берете резервную копию журнала, но этого не происходит (возможно, из-за моей доставки журналов, я не знаю).

вот мой текущий план резервного копирования:

  • полное резервное копирование каждую ночь
  • резервное копирование журнала транзакций один раз в день, поздним утром (возможно, зацепить журнал, сжимающийся на этот...не нужно сжиматься каждый день, хотя)

или, может быть, я просто запускаю его раз в неделю, после запуска полной задачи резервного копирования? Что вы все думаете?

6
sql sql-server sql-server-2005 sql-server-2008

6 ответов

Если файл растет каждую ночь на 500 МБ есть только одно правильное действие:предварительно увеличьте файл до 500 МБ и оставьте его там. Сжатие файла журнала повреждает. Наличие файла журнала auto-grow также повреждает.

  • вы нажмете инициализацию нулевого заполнения роста файла во время обычных операций, снижая производительность
  • ваш журнал растет с небольшими приращениями, создавая много виртуальных файлов журнала, что приводит к ухудшению операционной производительность
  • ваш журнал фрагментируется во время усадки. Хотя это не так плохо, как фрагментация файла данных, фрагментация файла журнала по-прежнему влияет на производительность
  • однажды ежедневный рост 500MB закончится из дискового пространства, и вы бы хотели, чтобы файл был предварительно выращен

вам не нужно верить мне на слово, вы можете прочитать в некоторых блогах MVP, что они говорят о практике сжатия журналов и файлов на регулярной основе основа:

есть еще, я просто устал связывать их.

каждый раз, когда вы сжимаете файл журнала, фея теряет свои крылья.

18
5

Я думаю, что вы предлагаете в своем вопросе правильный подход. То есть "подключить журнал, сокращающийся на" ваш ночной процесс резервного копирования / обслуживания. Главное, что вы регулярно делаете резервные копии журналов транзакций, что позволит уменьшить базу данных при выполнении задачи сжатия. Главное, что нужно иметь в виду, что это двухэтапный процесс: 1) резервное копирование журнала транзакций, который автоматически "усекает" ваш файл журнала; 2) Запустите сжатие против вашего файла журнала. "усечение" не обязательно (или когда-либо?) означает, что файл будет сжиматься...сокращается это отдельный шаг, который вы должны сделать.

1

для SQL Server 2005

инструкция DBCC shrinkfile команда ( Database_log_file_name , аргумент notruncate)

Это утверждение не нарушает доставку журналов. Но, возможно, вам придется бежать больше, чем один. Для каждого запуска резервное копирование, копирование и восстановление доставки журналов для запуска после повторного запуска этой инструкции.

сокращение и усечение различны.

мой опыт:

AA db, 6.8 GB журнал транзакций
первый запуск: 6.8 GB
доставка журналов резервное копирование, копирование, восстановление после второго запуска: 1.9 GB
резервное копирование, копирование, восстановление после третьего запуска: 1.7 GB
резервное копирование, копирование, восстановление после четвертого запуска: 1 GB

BB db, 50GB журнал транзакций
первый запуск: 39 ГБ
резервное копирование, копирование, восстановление после второго запуска: 1 ГБ

0

создание резервной копии журнала транзакций не означает, что онлайн размер файла журнала транзакций будет уменьшаться. Размер файла остается прежним. При резервном копировании транзакции в онлайн-журнале транзакций она помечается для перезаписи. Он не удаляется автоматически, и никакие пробелы не освобождаются, поэтому размер остается прежним.

Как только вы установите размер файла LDF, сохраните его размер, установив правильную частоту резервного копирования журнала транзакций.

пол Рэндал обеспечивает подробности здесь:

понимание ведения журнала и восстановления в SQL Server

понимание резервных копий SQL Server

0

на основе рекомендаций Microsoft перед тем, как вы собираетесь сжать файл журнала, вы должны сначала попытаться выполнить следующие возможности:

  • освобождение дискового пространства, чтобы журнал мог автоматически расти.
  • перемещение файла журнала на диск с достаточным свободным пространством.
  • увеличение размера файла журнала.
  • Добавить файл журнала на другой диск.

  • включите автоматический рост с помощью инструкции alter DATABASE для установки ненулевое приращение роста для опции FILEGROWTH.

    ALTER DATABASE EmployeeDB изменить файл (NAME = SharePoint_Config_log, SIZE = 2MB, MAXSIZE = 200MB, FILEGROWTH = 10MB);

кроме того, вы должны знать о сокращении операции через план обслуживания будет влиять на *.файл MDF и *.файл LDF. поэтому вам нужно создать план обслуживания с задачей задания SQL и написать следующую команду, чтобы можно было только сжать *.файл LDF вашей целевой размер.

use sharepoint_config
go
alter database sharepoint_config set recovery simple
go
dbcc shrinkfile('SharePoint_Config_log',100)
go
alter database sharepoint_config set recovery FUll
go

Примечание: 100 называется target_size для файла в мегабайтах, выражается как целое число. Если не указано, DBCC SHRINKFILE уменьшает размер до размера файла по умолчанию. Размер по умолчанию-это размер, указанный при создании файла.

по моему скромному мнению, не рекомендуется периодически выполнять операцию усадки! Только в некоторых случаях вам нужно уменьшить физический размер.

вы также можете проверить это полезное руководство сжать план обслуживания файла журнала транзакций в SQL Server

0