Сжатие файла данных не влияет на производительность.
Ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха-ха! <фыркает>
<вытирает слёзы с глаз, пытается сфокусироваться на экране ноутбука, убирает слюну с клавиатуры>
ЛОЖЬ
Единственный случай, когда сжатие файла данных не повлияет на производительность, — это если вы используете параметр WITH TRUNCATEONLY и в конце сжимаемого файла есть свободное пространство.
Сжатие влияет на производительность во время своего выполнения. Оно перемещает огромные объёмы данных, генерирует операции ввода-вывода, полностью протоколирует всё, что делает, и расходует ресурсы процессора.
Сжатие влияет на производительность после своего выполнения. Весь этот журнал транзакций должен быть архивирован, доставлен (log shipped), отзеркален, просканирован репликацией транзакций и так далее. И если файл данных снова будет расти, новое пространство снова придётся заполнять нулями (если только у вас не включена мгновенная инициализация файлов).
Хуже всего то, что сжатие вызывает сильную фрагментацию индексов — что губительно для производительности интервальных сканирований.
К сожалению, у меня никогда не было времени переписать код сжатия (я изначально писал его не так), поэтому, вероятно, мы навсегда застряли с его колоссальной ущербностью (это технический термин).
Ознакомьтесь с этой записью в блоге, где я вдаюсь в подробности и объясняю альтернативу использованию сжатия: Почему не стоит сжимать файлы данных, и с этой, где рассказывается, как правильно управлять размерами файлов данных: Importance of data file size management. А ещё вот эту — просто потому что она классная (безопасно для работы): TGIF Time Warp.
И помните:
- Сжатие файла данных — зло
- Команда
DBCC SHRINKDATABASE— ещё большее зло - Автосжатие — самое большое зло
Сжатие — просто скажите «нет». С помощью правильного обучения и эффективного консультирования мы можем раз и навсегда избавить мир от этой ужасной напасти.
Комментариев нет:
Отправить комментарий