Реорганизовать и сокращать никогда не рекомендуется на самом деле.
Если вы можете перевести приложения, которые база данных обслуживает, в автономный режим, вы можете ускорить процесс и уменьшить фрагментацию индекса, удалив все индексы и ограничения первичного / внешнего ключа до сжатия (это будет означать, что будет перемещаться меньше данных, так как только страницы данных будут перетасовываться, а не существующие на данный момент страницы индекса, что ускоряет процесс), а затем воссоздают все индексы и ключи.
Воссоздание индексов после сжатия означает, что они не должны быть существенно фрагментированными, а их удаление во время сжатия означает, что их восстановление не оставит много маленьких «дырок» в размещении страниц в файлах, которые могут вызвать фрагментацию позже.
Другой вариант, если вы можете отключить приложения от сети, - это перенести все данные в новую базу данных той же структуры. Если ваш процесс сборки надежный, вы сможете быстро создать эту пустую БД, если не создадите ее из текущей БД (восстановите резервную копию текущей, обрежьте / удалите все содержимое таблиц и выполните полное сжатие).
Возможно, вы все же захотите удалить все индексы в месте назначения и воссоздать их впоследствии, поскольку это может быть намного более эффективным при изменении большого количества проиндексированных данных (в данном случае это 100%). Чтобы ускорить процесс копирования, поместите файлы данных базы данных назначения на разные физические диски в источник (если только вы не используете твердотельные накопители, в этом случае вам не нужно заботиться о сокращении движений головы), вы можете переместить их в исходное местоположение, когда вы закончите.
Кроме того, если вы создаете место назначения как новое (вместо того, чтобы очищать копию источника), создайте его с начальным размером, который будет содержать все текущие данные, а также рост за несколько месяцев - это сделает копирование данных немного быстрее, так как он не будет выделять новое пространство время от времени на протяжении всего процесса.
Это может быть лучше, чем использование сжатия, поскольку перенос данных в новую базу данных повторяет предполагаемое действие операции сжатия, но потенциально с гораздо меньшей фрагментацией (что является непреднамеренным следствием реорганизации и сжатия). Сжатие просто берет блоки в конце файла и помещает их в первый пробел ближе к началу, не прикладывая усилий для сохранения связанных данных.
Я подозреваю, что результат будет более эффективным с точки зрения пространства, так как после этого, вероятно, будет меньше частично использованных страниц. Сжатие просто переместит частично использованные страницы, перемещение данных с большей вероятностью приведет к заполнению целых страниц, особенно если вы вставляете в место назначения в порядке кластеризованного ключа / индекса таблицы (где таблица имеет один) и создаете другие индексы после того, как все данные перенесены.
Конечно, если вы вообще не можете перевести приложения в автономный режим, просто выполнить сжатие - это единственный вариант, так что если вам действительно нужно освободить место, воспользуйтесь этим. В зависимости от ваших данных, шаблонов доступа, общего размера рабочего набора, объема ОЗУ сервера и т. Д. Дополнительная внутренняя фрагментация может оказаться не столь значимой в конце.
Для операции копирования либо SSIS, либо базовый T-SQL будут работать точно так же (опция SSIS может быть менее эффективной, но ее впоследствии легче поддерживать). Если вы создаете отношения FK в конце вместе с индексами, вы можете сделать простое «для каждой таблицы, скопировать» в любом случае. Конечно, для одноразового использования, вероятно, тоже хорошо сжимается + реорганизация, но мне просто нравится пугать людей, чтобы они никогда не рассматривали регулярные сокращения! (Я знал, что люди планируют их ежедневно).
Если вам не хватает места, и ваши данные не должны становиться такими большими, то сокращайте их, но после этого перестраивайте свои индексы с соответствующими коэффициентами заполнения, которые учитывают типичный рост.
Если вашей конечной целью является уменьшение размера резервной копии, убедитесь, что вы внедрили комплексную стратегию резервного копирования для очистки журнала транзакций, а при резервном копировании базы данных используйте параметры сжатия.
Я бы не рекомендовал автоматическое увеличение на 5 ГБ, если вы, как правило, не собираетесь часто увеличивать 5 ГБ. В противном случае у вас могут возникнуть проблемы с производительностью. Сначала необходимо установить размер данных, который, по вашему мнению, требуется, скажем, в течение года, а параметр автоматического роста должен соответствовать размеру, который вы тестировали, который не влияет на производительность. См. Не трогайте эту кнопку сжатия базы данных в SQL Server! Майк Уолш.
Перестройка индексов перед сжатием приводит к тому, что индексы плохо размечены. Это не хорошо, чтобы восстановить, а затем сжать. Сжатие приводит к искажению индексов для восстановления пространства, поэтому перестроение заранее, а затем сжатие не имеет смысла. См. Когда использовать Auto Shrink от Thomas LaRock.
источник
Я не знаю, будет ли это работать лучше, чем переиндексация после сжатия, но другой вариант - создать новый файл данных соответствующего размера и переместить все данные в него. В этом случае я бы сначала сделал переиндексацию, чтобы вы знали, каков фактический размер данных. Одна загвоздка в том, что если это первый файл в первичном файле данных, я не думаю, что вы можете очистить его. Вы должны быть в состоянии уменьшить его, а затем переместить данные обратно, и это позволит избежать переворота страницы. Однако, если вы смотрите на переход в твердое состояние, это не должно иметь большого значения в любом случае.
источник
Возвращаясь к этому пути поздно. Тем не менее, мы долго размышляли и тестировали использование сжатия в наших средах тестирования. Что касается темы, бывают случаи, когда сокращение является жизнеспособным вариантом. Но знание того, когда и как его применять, жизненно важно для правильного исполнения как в долгосрочной, так и в краткосрочной перспективе.
В нашем сценарии мы недавно добавили многочисленные изменения в нашу большую БД, включая сжатие, разбиение, архивирование и обычное удаление избыточных данных. В результате использованная часть нашего первичного файла данных сократилась до менее половины того, что было раньше. Но какой смысл носить с собой весь этот багаж? Тем более что, в отличие от некоторых статей в Интернете, размер ваших файлов данных напрямую соотносится с длительностью резервного копирования / восстановления. Это потому, что, в отличие от многих статей, в реальных сценариях загружается больше данных на любой странице, чем просто то, что вы, возможно, удалили.
Более того, это открывает отличный сценарий сокращения:
Таким образом, единственными данными, оставшимися там, будут системные объекты вашей БД, статистика, процедуры и еще много чего. Сжатие должно быть намного, НАМНОГО быстрее, и нет необходимости в дополнительном обслуживании индексов для ваших основных объектов данных, которые будут созданы аккуратно в порядке и минимальном риске для будущей фрагментации.
источник