Comments 5
Не очень понятны претензии к шринку. На практике место на СХД ограничено, выделяют его неохотно, после отдельных операций в базе разносит некоторые файлы. Я обычно формирую единый скрипт по всем файлам базы, первый заход транкейтонли, дальше просто шринк, во всех случаях ограничение времени. Да и можно вычислить в каком из файлов осталось много свободного места, отсортировать очередность. Запустил в студии- оно и давит. При этом в рамках свободного места стараюсь выполнять лесенкой, в несколько иттераций.
Ребилд- очень нехорошая штука. Ребилд в стандарт редакции блокирует таблицу, ребилд создает копию таблицы. То есть, для больших таблиц ребилд упорото жрет место. Если таблица занимает треть базы- значит ее объем увеличится тоже на треть, потом это место будет освобождено. При этом база может запросто сожрать все место на диске. Вот тут и пригодится шринк.
На практике для крупных таблиц лучше использовать только (исключительно) реоганайз. Можно исходить из того, что скорость чтения из базы для не самого могучего сервера на уровне 8-10 Гб в минуту. При перестроении индексов на это идет 1-3 Гб чтения в минуту. Вот из этого и нужно исходить. 800 Гб таблица (резервед, со всеми индексами) реорг часов 5, вполне реалистично.
Вы прикидывает теоретически, а я практически этим занимаюсь на терабайтных базах. Реорганайза вы не дождетесь
У нас есть базы больше десятка Тб. Каждая из таких баз- это сотни файлов, все крупные объекты секционированы. То есть, сделать реорг всем объектам- вполне реалистичный сценарий.
А вот если в 10 Тб базе два файла, лога и данных, при этом самая крупная таблица с индексами занимает половину- во, там дождаться шансов нет- но такая ситуация свидетельствует о крайне неудачной архитектуре приложения.
Так-то базы размером до 600-800 Гб вполне комфортно поддаются обслуживанию, даже без секционирования.
у меня норм на многотерабайтных реорг идет, у всех все по разному
Разумеется о standard речи не идёт
MSSQL: снова о дефрагментации и SHRINK