Что если вам действительно необходимо сжать базу данных?
Пересказ статьи Brent Ozar. What If You Really DO Need to Shrink a Database?
Вы уже слышали, что сжатие базы данных - это плохо, поскольку связано с появлением как внешней, так и внутренней фрагментации, вызывает блокировки, рост журнала транзакций при запуске, а также является медленным и однопоточным. Вы понимаете, что если речь идет всего лишь о 10-20-30% базы данных, а база данных составляет всего 100-200 ГБ, то вы можете спокойно оставить это место, потому что все равно будете его использовать.
Но ваша ситуация отличается:
Вы получили задание сжать базу данных для более легкого восстановления её в другом окружении, например, когда вам нужно восстановить её в QA или среде разработки. Эти ваши серверы не нуждаются в таком большом неиспользуемом пространстве.
Подход на основе ALTER INDEX…REBUILD имеет несколько ключевых преимуществ по сравнению с сжатием:
Однако этот подход имеет также и несколько недостатков:
- Ваша база имеет размер 1Тб или более.
- Вы удалили 50% данных.
- Вы имеете 500Гб+ свободного пространства.
- Вы не видите необходимости в этом пространстве, поскольку теперь вы собираетесь регулярно выполнять удаление и архивацию.
Вы получили задание сжать базу данных для более легкого восстановления её в другом окружении, например, когда вам нужно восстановить её в QA или среде разработки. Эти ваши серверы не нуждаются в таком большом неиспользуемом пространстве.
Не сжимайте. Сделайте вместо этого:
- Добавьте новую файловую группу и новые пустые файлы в ней. Сделайте эту группу новой файловой группой по умолчанию.
- Переместите объекты в новую файловую группу с помощью команд ALTER INDEX...REBUILD.
- Когда вы переместили все объекты, сожмите старую файловую группу, что произойдет очень быстро.
- Просто оставьте её там - это местоположение вашей новой базы данных.
Подход на основе ALTER INDEX…REBUILD имеет несколько ключевых преимуществ по сравнению с сжатием:
- Он может использовать параллелизм: вы можете указать сколько ядер использовать с помощью хинта MAXDOP. Это действительно полезно на серверах с установкой MAXDOP =1 на уровне сервера, поскольку ваш хинт уровня запроса перепишет её даже в большую сторону.
- Он может перемещать одновременно более одной 8-килобайтной страницы. Черт, вы можете даже одновременно перестроить несколько индексов в различных потоках, если нужно, что действительно ускоряет работу.
- Вы выбираете дни/время для каждого объекта: возможно, некоторые из ваших объектов интенсивно используются в течение некоторого временного окна, и вы не хотите трогать их до времени обслуживания.
- Вы выбираете установки для каждого объекта: перестройка индекса с ONLINE = ON медленная. Некоторые из ваших объектов могут представлять собой архивные таблицы или не использоваться в течение определенных дней/времени. Поэтому вы можете использовать для них ONLINE = OFF, чтобы ускорить производительность.
Однако этот подход имеет также и несколько недостатков:
- Это выполняется быстрей, но за счет более высокой нагрузки: сжатие базы данных - это процесс с низкими издержками: вам трудно заметить перемещение лишь одной 8-килобайтной страницы за раз при использования одного ядра ЦП. Перестройка же индексов напрягает: люди заметят, когда вы бросаете массу ядер ЦП на решение проблемы и начнете действительно забивать ваше хранилище. Это просто обратная сторона медали для ускорения выполнения: если вы хотите быстрей закончить, то должны более напряженно работать.
- Это также означает, что чем больше генерируется записей в логи, тем быстрей: поскольку мы перемещаем столь много данных и этот процесс полностью журнализируется, то он может вызвать проблемы при создании бэкапов журналов транзакций, росте размеров файлов журналов, зеркалировании базы данных, Always On Availability Groups и репликации хранилища/VM. Входите в это постепенно, начиная с самых маленьких таблиц, чтобы вы могли увидеть влияние, оказываемое на размеры ваших журналов транзакций.
- ONLINE = ON - не вполне онлайн: Даже онлайновая перестройка индексов требует включения режима блокировки схемы для того, чтобы закончить свою работу. К счастью, начиная с SQL Server 2014, мы получили опцию WAIT_AT_LOW_PRIORITY (ожидание при низком приоритете), которая позволяет смягчить эту проблему.
- Вы должны выполнить некоторую подготовительную работу: запустить DBCC SHRINKDATABASE просто, но ALTER INDEX…REBUILD потребует больше работы, если вы хотите получить все те преимущества, о которых я говорил выше.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой