SQL Server 2008 - Уменьшение Журнала транзакций - Какой-либо способ автоматизировать?

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

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

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

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

Вот мой план актуальной резервной копии:

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

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

6
задан Albert 31 March 2010 в 20:13
поделиться

3 ответа

Если ваш файл растет каждую ночь на 500 МБ, есть только одно правильное действие: предварительно увеличить файл до 500 МБ и оставить его там. Уменьшение файла журнала вредно. Автоматический рост файла журнала также вреден.

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

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

Есть и другие, я просто устал их перечислять.

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

18
ответ дан 8 December 2019 в 04:51
поделиться

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

1
ответ дан 8 December 2019 в 04:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: