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

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

6 голосов
/ 01 апреля 2010

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

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

Что сработало нормально, сократилось до 8 МБ ... но рассматриваемая БД - это Издатель доставки журналов, и журнал уже вернулся к размеру около 500 МБ и быстро растет.

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

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

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

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

Ответы [ 6 ]

18 голосов
/ 01 апреля 2010

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

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

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

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

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

5 голосов
/ 01 апреля 2010
1 голос
/ 01 апреля 2010

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

0 голосов
/ 11 июля 2016

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

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

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

    ALTER DATABASE EmployeeDB MODIFY FILE (ИМЯ = SharePoint_Config_log, РАЗМЕР = 2 МБ, МАКСИМАЛЬНЫЙ = 200 МБ, FILEGROWTH = 10 МБ);

Кроме того, вы должны знать, что операция сжатия с помощью плана обслуживания повлияет на файл * .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 голосов
/ 28 июля 2014

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

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

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

Общие сведения о ведении журнала и восстановлении в SQL Server

Общие сведения о резервных копиях SQL Server

0 голосов
/ 14 февраля 2014

для SQL Server 2005

DBCC SHRINKFILE (имя_файла_базы_данных, NOTRUNCATE)

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

Сжатие и усечение разные.

Мой опыт:

AA дБ, 6,8 ГБ, журнал транзакций
Первый запуск: 6,8 ГБ
резервное копирование, копирование, восстановление журналов после второго запуска: 1,9 ГБ
резервное копирование, копирование, восстановление журналов после третьего запуска: 1,7 ГБ
резервное копирование, копирование, восстановление журналов после четвертого запуска: 1 ГБ

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

...