Сокращение журнала транзакций SQL Server

В настоящее время мне приходится иметь дело с журналом транзакций SQL Server, который вышел из-под контроля. Отказ от ответственности: я не dba, и это не моя область знаний, поэтому, пожалуйста, потерпите меня.

В настоящее время у меня есть файл журнала транзакций объемом 115 ГБ для базы данных объемом 500 МБ, который (очевидно) в течение некоторого времени плохо управлялся, чтобы он мог войти в это состояние.

Главный приоритет - освободить место на диске, занимаемое этим файлом, прежде чем мы исчерпаем! Мне сказали, что увеличивать размер диска нельзя, даже временно, и, исходя из прошлого роста, мы должны действовать довольно скоро.

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

Поскольку в полночь мы регулярно выполняем полное резервное копирование БД, могу ли я временно перевести базу данных в простой режим восстановления (после запуска одной из этих резервных копий), сжать файл журнала, чтобы освободить (практически все) пространство и затем верните его в полное восстановление с помощью стратегии резервного копирования, упомянутой выше?

Я думаю, что если что-то случится в это время, мы можем просто восстановить полную резервную копию без использования журналов.

ОБНОВИТЬ

Несколько дополнительных деталей в ответ на некоторые ответы и комментарии:

• Мы хотим сохранить возможность восстановления на определенный момент времени, чтобы база данных оставалась в режиме полного восстановления.

• Причина, по которой файл t-log стал настолько большим, заключается в том, что он никогда не копировался . Проверено как log_reuse_wait_desc возвращает «LOG_BACKUP».

Журнал транзакций для этой базы данных содержит все транзакции с момента последнего резервного копирования журнала транзакций или последнего переключения из простого режима восстановления. Выполните следующие действия, чтобы получить окончательный ответ о том, почему SQL Server не может усекать журнал и, следовательно, почему журнал растет.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Если вы хотите восстановить момент времени, оставьте БД в модели полного восстановления и делайте частые резервные копии журналов. Каждая резервная копия журнала будет содержать все транзакции с момента последнего резервного копирования журнала. Процесс резервного копирования журнала также отвечает за очистку журнала и маркировку пространства для повторного использования, т.е. следующая транзакция, выполненная в БД, будет записана в начало усеченного журнала циклическим образом. Это резервное копирование и повторное использование журнала препятствует росту файла журнала.

Если вас не интересует момент восстановления времени и вы хотите упростить администрирование базы данных. Затем установите для базы данных простую модель восстановления и не делайте резервных копий t-log. SQL Server автоматически усекает журнал транзакций после каждой транзакции. Это означает, что после фиксации транзакции в журнале запись перезаписывается следующей транзакцией и т. Д.

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

Загрузите и разверните https://ola.hallengren.com/ решение для администрирования базы данных, чтобы охватить резервные копии, фрагментацию индекса, статистику и CHECKDB.

Вы также можете найти возвращенный отчет об использовании диска, щелкнув правой кнопкой мыши по БД в Object Explorer> Отчеты> Стандартные отчеты> «Использование диска», чтобы вернуть свободное место в t-log.

Я также рекомендую вам Google, почему так важно сохранять цепочку журналов без изменений с точки зрения аварийного восстановления и как переключение с полного на простое разрывает цепочку, оставляя вас подверженными потере данных.

Поскольку в полночь мы регулярно выполняем полное резервное копирование БД, могу ли я временно перевести базу данных в простой режим восстановления (после запуска одной из этих резервных копий), сжать файл журнала, чтобы освободить (практически все) пространство и затем верните его в полное восстановление с помощью стратегии резервного копирования, упомянутой выше?

Да, это будет безопасно при условии, что вы не будете вмешиваться в транзакции, например, в ночное время. В общем случае, если база данных должна находиться в режиме полного восстановления, необходимо регулярно создавать резервные копии T-Log. Это уменьшит проблему, с которой вы столкнулись. Я пишу «в общем», потому что в некоторых случаях я видел, как люди устанавливали базу данных на полную, не зная, почему они это сделали. Давайте предположим, что это не тот случай.

Вы можете подумать, почему журнал имеет такой размер относительно размера базы данных. База данных объемом 500 МБ с журналом 116 ГБ кажется очень непропорциональной для одного события. Я бы посоветовал следить за тем, что происходит в базе данных, чтобы увидеть, как она достигла такого размера.