Когда можно уменьшить базу данных?

Я знаю, что сокращение - это дьявол: он изменяет порядок страниц и отвечает за рак кожи, фрагментацию данных и глобальное потепление. Этот список можно продолжить ... При этом, скажем, у меня есть база данных объемом 100 ГБ, и я удаляю 50 ГБ данных - не из одной таблицы, а из общего сокращения старых данных на уровне базы данных, охватывающем 90% всей базы данных. таблицы - представляет ли это подходящий вариант использования для сокращения базы данных?

Если нет, то какие соответствующие шаги необходимо предпринять для очистки дома после удаления такого большого процента данных из базы данных? Я могу думать о двух: перестроить индексы и обновить статистику. Что-то еще?

Реорганизовать и сокращать никогда не рекомендуется на самом деле.

Если вы можете перевести приложения, которые база данных обслуживает, в автономный режим, вы можете ускорить процесс и уменьшить фрагментацию индекса, удалив все индексы и ограничения первичного / внешнего ключа до сжатия (это будет означать, что будет перемещаться меньше данных, так как только страницы данных будут перетасовываться, а не существующие на данный момент страницы индекса, что ускоряет процесс), а затем воссоздают все индексы и ключи.

Воссоздание индексов после сжатия означает, что они не должны быть существенно фрагментированными, а их удаление во время сжатия означает, что их восстановление не оставит много маленьких «дырок» в размещении страниц в файлах, которые могут вызвать фрагментацию позже.

Другой вариант, если вы можете отключить приложения от сети, - это перенести все данные в новую базу данных той же структуры. Если ваш процесс сборки надежный, вы сможете быстро создать эту пустую БД, если не создадите ее из текущей БД (восстановите резервную копию текущей, обрежьте / удалите все содержимое таблиц и выполните полное сжатие).

Возможно, вы все же захотите удалить все индексы в месте назначения и воссоздать их впоследствии, поскольку это может быть намного более эффективным при изменении большого количества проиндексированных данных (в данном случае это 100%). Чтобы ускорить процесс копирования, поместите файлы данных базы данных назначения на разные физические диски в источник (если только вы не используете твердотельные накопители, в этом случае вам не нужно заботиться о сокращении движений головы), вы можете переместить их в исходное местоположение, когда вы закончите.

Кроме того, если вы создаете место назначения как новое (вместо того, чтобы очищать копию источника), создайте его с начальным размером, который будет содержать все текущие данные, а также рост за несколько месяцев - это сделает копирование данных немного быстрее, так как он не будет выделять новое пространство время от времени на протяжении всего процесса.

Это может быть лучше, чем использование сжатия, поскольку перенос данных в новую базу данных повторяет предполагаемое действие операции сжатия, но потенциально с гораздо меньшей фрагментацией (что является непреднамеренным следствием реорганизации и сжатия). Сжатие просто берет блоки в конце файла и помещает их в первый пробел ближе к началу, не прикладывая усилий для сохранения связанных данных.

Я подозреваю, что результат будет более эффективным с точки зрения пространства, так как после этого, вероятно, будет меньше частично использованных страниц. Сжатие просто переместит частично использованные страницы, перемещение данных с большей вероятностью приведет к заполнению целых страниц, особенно если вы вставляете в место назначения в порядке кластеризованного ключа / индекса таблицы (где таблица имеет один) и создаете другие индексы после того, как все данные перенесены.

Конечно, если вы вообще не можете перевести приложения в автономный режим, просто выполнить сжатие - это единственный вариант, так что если вам действительно нужно освободить место, воспользуйтесь этим. В зависимости от ваших данных, шаблонов доступа, общего размера рабочего набора, объема ОЗУ сервера и т. Д. Дополнительная внутренняя фрагментация может оказаться не столь значимой в конце.

Для операции копирования либо SSIS, либо базовый T-SQL будут работать точно так же (опция SSIS может быть менее эффективной, но ее впоследствии легче поддерживать). Если вы создаете отношения FK в конце вместе с индексами, вы можете сделать простое «для каждой таблицы, скопировать» в любом случае. Конечно, для одноразового использования, вероятно, тоже хорошо сжимается + реорганизация, но мне просто нравится пугать людей, чтобы они никогда не рассматривали регулярные сокращения! (Я знал, что люди планируют их ежедневно).

Будет ли база данных снова расти? Если это так, то усилия, которые вы собираетесь приложить к операциям сжатия, будут просто напрасными, потому что, когда вы уменьшите размер файла, а затем добавите больше данных, файл просто снова будет расти, и транзакции должны ждать, пока этот рост произойдет. Если у вас есть неоптимальные настройки автоматического роста и / или медленная езда, эта деятельность роста будет довольно болезненной.

Если вы уменьшите базу данных, для чего вы собираетесь использовать освободившееся дисковое пространство? Опять же, если вы просто собираетесь освободить это пространство на случай, если эта база данных снова вырастет, то вы просто крутите свои колеса.

Теперь, когда у вас есть все это свободное место в файле, вы можете перестроить ваши индексы, чтобы они лучше оптимизировались (и это будет гораздо менее болезненно делать, когда у вас есть свободное место для этого - подумайте о попытке сменить свитер в крошечном шкафу против большой спальни).

Поэтому, если это не было основной операцией очистки, и вы действительно не будете снова наращивать тот же уровень данных, я бы просто оставил все как есть и сосредоточился на других областях оптимизации.

Если вам не хватает места, и ваши данные не должны становиться такими большими, то сокращайте их, но после этого перестраивайте свои индексы с соответствующими коэффициентами заполнения, которые учитывают типичный рост.

Если вашей конечной целью является уменьшение размера резервной копии, убедитесь, что вы внедрили комплексную стратегию резервного копирования для очистки журнала транзакций, а при резервном копировании базы данных используйте параметры сжатия.

• Создать полную резервную копию базы данных (SQL Server)
• Резервные копии журнала транзакций (SQL Server)

Я бы не рекомендовал автоматическое увеличение на 5 ГБ, если вы, как правило, не собираетесь часто увеличивать 5 ГБ. В противном случае у вас могут возникнуть проблемы с производительностью. Сначала необходимо установить размер данных, который, по вашему мнению, требуется, скажем, в течение года, а параметр автоматического роста должен соответствовать размеру, который вы тестировали, который не влияет на производительность. См. Не трогайте эту кнопку сжатия базы данных в SQL Server! Майк Уолш.

Перестройка индексов перед сжатием приводит к тому, что индексы плохо размечены. Это не хорошо, чтобы восстановить, а затем сжать. Сжатие приводит к искажению индексов для восстановления пространства, поэтому перестроение заранее, а затем сжатие не имеет смысла. См. Когда использовать Auto Shrink от Thomas LaRock.

Я не знаю, будет ли это работать лучше, чем переиндексация после сжатия, но другой вариант - создать новый файл данных соответствующего размера и переместить все данные в него. В этом случае я бы сначала сделал переиндексацию, чтобы вы знали, каков фактический размер данных. Одна загвоздка в том, что если это первый файл в первичном файле данных, я не думаю, что вы можете очистить его. Вы должны быть в состоянии уменьшить его, а затем переместить данные обратно, и это позволит избежать переворота страницы. Однако, если вы смотрите на переход в твердое состояние, это не должно иметь большого значения в любом случае.

Возвращаясь к этому пути поздно. Тем не менее, мы долго размышляли и тестировали использование сжатия в наших средах тестирования. Что касается темы, бывают случаи, когда сокращение является жизнеспособным вариантом. Но знание того, когда и как его применять, жизненно важно для правильного исполнения как в долгосрочной, так и в краткосрочной перспективе.

В нашем сценарии мы недавно добавили многочисленные изменения в нашу большую БД, включая сжатие, разбиение, архивирование и обычное удаление избыточных данных. В результате использованная часть нашего первичного файла данных сократилась до менее половины того, что было раньше. Но какой смысл носить с собой весь этот багаж? Тем более что, в отличие от некоторых статей в Интернете, размер ваших файлов данных напрямую соотносится с длительностью резервного копирования / восстановления. Это потому, что, в отличие от многих статей, в реальных сценариях загружается больше данных на любой странице, чем просто то, что вы, возможно, удалили.

Более того, это открывает отличный сценарий сокращения:

1. Создайте сценарий, который найдет все объекты и их файловые группы в вашей базе данных (множество примеров в Интернете), используйте его для создания предложений удаления, а также для создания определений для каждого из ваших индексов и ограничений.
2. Создайте новый файл и файловую группу и установите его по умолчанию.
3. Удалите все некластеризованные индексы (обратите внимание, некоторые индексы могут быть ограничениями).
4. Создайте свои кластеризованные индексы в новой файловой группе с помощью DROP_EXISTING = ON (что, между прочим, является чрезвычайно быстрой, минимально регистрируемой операцией для начала по сравнению со многими альтернативами).
5. Воссоздайте свои некластерные индексы.
6. Наконец, СОХРАНИТЕ свой старый файл данных (обычно ПЕРВИЧНЫЙ).

Таким образом, единственными данными, оставшимися там, будут системные объекты вашей БД, статистика, процедуры и еще много чего. Сжатие должно быть намного, НАМНОГО быстрее, и нет необходимости в дополнительном обслуживании индексов для ваших основных объектов данных, которые будут созданы аккуратно в порядке и минимальном риске для будущей фрагментации.