На прошлой неделе моему экземпляру sql server 2017 (работающему на Windows Server 2016) не хватило места, и диск был полностью заполнен файлом журнала транзакций объемом 190 ГБ.
К счастью, это было в облачном экземпляре, поэтому я быстро размонтировал диск, увеличил его еще на 200 ГБ или около того, а затем перемонтировал и отформатировал неиспользуемое пространство.
Однако у меня все еще был этот гигантский файл журнала на 190 ГБ. Резервные копии журналов не были настроены. Поэтому я вручную сделал резервную копию журналов транзакций. Затем я запустил отчет об использовании диска, и, к счастью, он показал, что 95% пространства журнала транзакций не используется:
Однако размер самого файла журнала по-прежнему составляет 190 ГБ. После некоторого исследования люди предложили мне сжать файл журнала, просто очистив его от большей части данных, сделав резервную копию. Итак, я попытался сжать его, и он обрабатывался в течение нескольких секунд, а затем окно утилиты сжатия закрылось без каких-либо ошибок. Однако размер файла журнала составляет 190 ГБ.
Я запросил log_reuse_wait_desc для своей базы данных, и мне было возвращено «LOG_BACKUP». Этот статус, по-видимому, означает, что перед сжатием файла журнала транзакций я должен сделать резервную копию, но я только что сделал резервную копию?
Я застрял на этом этапе, я хотел бы иметь файл журнала транзакций меньшего размера (что-то вроде 10-20 ГБ), и я хотел бы автоматически создавать резервную копию журнала, либо достаточно регулярно, чтобы он никогда не превышал 10-20 ГБ, либо автоматически когда размер файла составляет 10-20 ГБ.
Кто-нибудь знает, как бороться со статусом LOG_BACKUP, который блокирует мою возможность сжать файл, помимо простого запуска резервного копирования (поскольку я уже сделал это)?
Вот мои dm_db_log_stats для базы данных:
Вы заметите, что мой общий счетчик vlf огромен (1097), мой активный счетчик vls меньше (300), но я не уверен, что это значит.