Auto-shrink в MS SQL SERVER 2008R2

Почему и чем "опасен" шринк" ("автошринк")???
По умолчанию сервера автосжатие - True, то есть включено по "заводским" настройкам самого майкрософт я так понимаю.... Но при этом всём в "методичках" и "статьях" (я так понимаю, что они официальные, т.к. размещены на оф. сайте) оно типа как бы не рекомендовано, т.к. частое сжатие (частый шринк) приводит к фрагментации данных в файловой системе. (а фрагментация я так понимаю, когда физический порядок страницы не совпадает с логическим, т.е. в новой базе данных этот порядок соблюдается, логический = физическому, но после удаления таблицы он сразу же нарушается???я правильно понимаю?? но не в этом вопрос).
Так вот, после удаления таблиц, место внутри базы освобождается, но на диске база все также осталась ( сиквел сервер не отдает место файловой системе обратно), я применяю шринк (вручную), место освобождается на диске (сиквел сервер отдает это место файловой системе?). И если я все правильно понимаю здесь две стороны:
1. при распухании базы, следует делать шринк (допустим даже вручную), чтобы после удаления данных, вернуть место файловой системе. Это дает плюс "огромный" , ну типа отдает место свободное и база меньше весит, т.е. база не занимает свободное место (место без данных) на диске. Но после шринка появляется фрагментация
2.при определённых действиях база распухает, например при удалении данных, данные внутри базы меньше, но в файловой системе занимает также. Шринк не производится, база распухает, данные весят к примеру 60 гб, а на диске 80гб, 20 гб это свободное место на диске в файловой системе. И данные не займут больше места, пока не займут всё свободное место, т.е. 20 гб.
Я написал много чего как я понимаю и вопросы, на которые хочется получить ответ. Я начинающий АБД. Время чтобы тестить есть, начальство брало меня чтобы выучить как специалиста, который будет все это в будущем контролировать с но правда с постоянным самообучением. Я про себя сказал к слову о том, что много моментов не пойму в силу не понятия слэнга...

Я задался этим вопросом, т.к. у меня база данных: размер 85303,23 МБ и свободно 17759,58 МБ (20,8%). Стоит автошринк, но в вышенаписанном мною я пояснил что не рекомендовано. Вопрос стоит о оптимизации базы , а именно ее размере, попытки ее уменьшить без вреда данным. Может быть сделать перестройку индексов и в дальнейшем отключить автошринк?? Прошу помочь в очередной раз, я не прошу сразу "все карты на стол" и "как все и сразу" сделать, а советов из своего личного опыта и с опытом в применении всех возможных рекомендаций майкрософта в решении такой проблемы или проблем к ним близким.

Добавлено через 1 минуту
Я хоть и без опыта но баз чтобы протестить все варианты хватит.

0

Тут только в степень этого надо нужно понимать.
На мой взгляд, делать rebuild надо:
1. В случае, если вы используете кучу, например - для предварительной вставки и модификации данных. Тогда alter table rebuild нужен периодически, т.к. страницы в куче, помеченные на удаление, потом в распределение свободного места не попадают. И это как раз тот момент, когда файл данных бесполезно пухнет.
2. Когда фрагментация на главных таблицах, притом имеющих объем свыше 10-15 Гб выросла свыше 20-25%
3. Когда какой-нибудь дебил сделал кластерный индекс по newid(), и таблица интенсивно используется на вставку/обновления (как в простигосподи exchange) (это, наверное, единственный случай, когда можно настраивать задание на автоматический ребилд, так часто, как только это возможно организационно. И даже не проверять фрагментацию предварительно).
4. Когда был Alter table, особенно с удалением какого либо поля, или с добавлением поле фиксированного размера. Тут нужен alter table rebuild обязательно.

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

А вот статистику пересчитывать, наоборот - нужно так часто, как это возможно по организационным соображениям.

Любимое занятие всех 1С-ников делать каждый вечер ребилд/реорганайз индексов (есть куча навороченных скриптов по этому поводу) - влияет на производительность, в основном, из-за того, что после rebuild индекса идет обновление статистики по нему, бонусом, и соответственно, все кэшированные планы тоже становятся неактуальны (а у 1С прямо болезнь кэшировать планы с идиотскими параметрами, и потом страдать на ровном месте - вчера летало, сегодня восползает).
А вот после реорганайза - не идет. Поэтому рождаются перлы, типа "если индекс фрагментирован менее, чем на 10% - то реорганайз, иначе ребилд".
Но в первом случае - это плацебо, а во втором - "красный стрептоцид", у которого другое действующее начало и оно вообще бесцветное :-)

Все имхо.
Сегодня на работе куча дурной работы, хочется отвлечься :-) Пишу всякую фигню.

0

Сообщение от uaggster Тут только в степень этого надо нужно понимать.

Чтоб понимать степень - нужно как-то все эти нюансы отдельно мониторить и препарировать. Когда десятки инстансов и сотни баз это уже немного утомительно. Проще везде типовые джобы настроить, чем искать, где именно там guid-ы кластерным ключом висят, например

0