Путаница в файле журнала SQL Server
Я ищу ясности в файле журнала SQL Server. У меня большая база данных (2 ГБ), резервная копия которой в последнее время по какой-то причине не создавалась. Файл журнала для базы данных вырос примерно до 11 ГБ, что, насколько я понимаю, это все транзакции и операторы, которые произошли в базе данных.
Мои вопросы:
Что вызывает сброс файла журнала базы данных? Что на самом деле означает «промывка»? Каковы последствия сжатия файла или базы данных для большого файла журнала?
Ответы 3
Резервная копия обычно очищает журнал транзакций. В журнале транзакций хранятся все изменения с момента последнего резервного копирования. В зависимости от того, как вы создаете резервную копию базы данных, вам может вообще не понадобиться вести полный журнал транзакций. Если вы используете MS SQL2000 / MS SQL2005, установка режима восстановления на Простой удаляет журнал транзакций.
Убедившись, что у вас есть чистая копия базы данных (без риска потери), можно безопасно удалить журнал транзакций. Для этого есть несколько команд SQL, но я обычно меняю режим восстановления на Простой, затем сжимаю базу данных, а затем при необходимости устанавливаю режим восстановления обратно на Полный.
Если вам нужна дополнительная информация, укажите версию SQL, которую вы используете, и то, как вы выполняете резервное копирование, и я посмотрю, смогу ли я подробнее рассказать о вашей конкретной настройке.
На самом деле, я не верю, что резервное копирование базы данных сжимает журналы, а резервное копирование самих журналов транзакций сжимает их. SQL Server делает различие между ними.
Обычно я либо выполняю «простое» восстановление всех баз данных, либо делаю резервное копирование журналов транзакций частью моего регулярного плана обслуживания (обычно один раз в неделю).
После резервного копирования журнала транзакций эти транзакции удаляются из журнала, но пространство, используемое операцией, автоматически не восстанавливается. Если вы делаете регулярные резервные копии журналов транзакций, это может быть хорошо. Предполагается, что пространство используется для транзакций и снова понадобится в будущем. Постоянное сжатие журнала транзакций может отрицательно сказаться на производительности, поскольку при повторной необходимости базе данных потребуется расширить журнал.
Итак, чтобы решить вашу проблему, сначала сделайте полную резервную копию и резервную копию журнала транзакций. Вам не нужно переходить в простой или однопользовательский режим. Затем сжимайте базу данных и каждые несколько часов создавайте резервную копию журнала транзакций. На своих серверах я делаю это каждые 10 минут, но это полностью зависит от того, как часто нужно для их среды. Следите за тем, как изменяется размер журнала, не забудьте оставить достаточно места, чтобы ему не приходилось регулярно расширяться, плюс немного для развлечения.
Когда вы сокращаете базу данных, используйте DBCC SHRINKFILE, а не DBCC SHRINKDATABASE, поскольку последний будет сжимать всю базу данных, а не только файл журнала. Также у вас не так много контроля над тем, сколько места восстанавливается.