Когда следует использовать автоматическое сжатие файлов журнала в SQL Server?
У меня было несколько проблем с слишком большими размерами файлов журналов на моих серверах SQL (2000). Microsoft не рекомендует использовать автоматическое сжатие для файлов журнала, но, поскольку это функция, она должна быть полезна в некоторых сценариях. Кто-нибудь знает, когда лучше использовать свойство автоматической усадки?
Ответы 4
Я использовал его, когда у нас была демонстрационная версия огромной базы данных, которая занимала много места на ноутбуке, поэтому мы использовали ее, чтобы уменьшить размер.
Ключ в том, чтобы использовать его только тогда, когда данные в основном выбрасываются.
Вам следует периодически обрезать журналы как часть стратегии резервного копирования.
Он не выбрасывает никаких данных
Вы можете обрезать журнал, если уменьшение размера важно, если это работает с вашей схемой резервного копирования. То есть вы делаете полное резервное копирование, усекаете, а затем снова создаете резервную копию, когда активность практически отсутствует.
Я знаю, что он не выбрасывает никаких данных. Я имел в виду, что его следует использовать только тогда, когда целостность данных не важна.
Я считаю, что автоматическое сжатие полезно, когда у вас много довольно небольших баз данных, которые часто становятся больше из-за добавления данных, а затем имеют много пустого места. Вы также не должны беспокоиться о том, что файлы будут фрагментированы на диске, когда они будут часто увеличиваться и уменьшаться. Я бы никогда не использовал автоматическое сжатие для критически важной базы данных или базы данных размером более 2 ГБ, поскольку вы никогда не знаете, когда сработает операция сжатия, и доступ к базе данных будет заблокирован до завершения сжатия.
Ваша проблема не в том, что вам нужно периодически автоматически уменьшать размер, а в том, что вам нужно периодически создавать резервные копии файлов журнала. (Мы делаем резервную копию каждые 15 минут.) Резервного копирования самой базы данных недостаточно, вы также должны вести журнал. Если вы не создадите резервную копию журнала транзакций, он будет увеличиваться до тех пор, пока не займет все место на диске. Если вы сделаете резервную копию, это освободит пространство для повторного использования (вам все равно, вероятно, потребуется сжать его после первого резервного копирования, чтобы уменьшить размер журнала до более разумного). Если вам не нужно иметь возможность восстанавливаться после транзакций (что должно быть возможно, если вся ваша база данных не состоит из таблиц, которые загружаются из другого источника и могут быть легко перезагружены), то установите для журнала значение простой режим восстановления.
Одна из причин, по которой автоматическое сжатие не является хорошей идеей, заключается в том, что вы будете часто увеличивать журнал транзакций, что снижает производительность. ЕСЛИ вы создаете резервную копию журнала, который вы получите относительно стабильного размера (объем пространства, обычно используемый журналом транзакций в период времени между резервными копиями), тогда журнал будет только время от времени увеличиваться, если есть необычно большой объем для транзакций.
Никогда не включайте автоматическое сжатие. Это вызывает снижение производительности по нескольким причинам. Файловая система и индексы становятся фрагментированными, что требует значительных ресурсов. В этом также нет необходимости, если вы правильно управляете своими резервными копиями.
Прочтите этот ответ Пола Рэндала о сбое сервера и просто скажите Нет для автоматического сжатия !!
«Не путайте это с сжатием файла журнала, которое иногда бывает полезно и необходимо». - из цитированной вами статьи Пола Рэндала;)
В производственной базе данных, которая является транзакционной, вы не должны усекать журнал, вы должны создать его резервную копию.