Покритикуйте план обслуживания, плиз

Здравствуйте.
Есть MS SQL Server 2008 R2. Основная рабочая база на данный момент весит 30Гб (за три месяца со старта проекта так набрала весу). Её специфика в том, что в неё круглосуточно автоматически вливаются данные (висит служба стороннего ПО, которая это делает). Пользователей на данный момент - четыре. В перспективе - до 300.

Итак, план ослуживания один, субпланов три:

Первый субплан (ночное обслуживание):
1. Проверка на целостность ВСЕХ баз данных PHYSICAL_ONLY (ибо слишком много времени занимает нормальная проверка). При успешном выполнении этого пункта переходим к остальным
2. Перестроение индекса для всех пользовательских баз.
3. Обновление статистики всех пользовательских баз
4. Очистка процедурного кэша
5. Полный бэкап логов
6. Полный бэкап пользовательских баз.

Второй субплан (дневное обслуживание):
1. Реорганизация индексов всех пользовательских баз.
2. Обновление статистики всех пользовательских баз.
4. Очистка процедурного кэша

Третий субплан (утром в субботу): проверка на целостность всех баз данных.

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

А модель восстановления базы какая?

Full

Какой сакральный смысл в "Обновление статистики всех пользовательских баз" сразу после "перестроения индексов" в первом субплане, если у вас как я думаю деваултное автообновление статискики для всех БД ?

DrNil
Full

А почему тогда "Полный бэкап логов" раз в сутки и почему он перед "Полный бэкап пользовательских баз"?
В чем его тайный смысл?
4. Зачем вам очистка процедурного кэша? у вас статистика сильно меняется и потому у оптимизатора башню сносит?

Зачем все эти "перестроения" и "реорганизации" индексов? У вас идет сильная их фрагментация? Почему не делать "адаптивную" реорганизацию/перестроение индексов в зависимости от их фрагментированности?

stavgreengo
Какой сакральный смысл в "Обновление статистики всех пользовательских баз" сразу после "перестроения индексов" в первом субплане, если у вас как я думаю деваултное автообновление статискики для всех БД ?

Насчёт порядка обновления статистики и перестроения индексов я сам в сомнениях - прочитанные мною материалы оставили мысль что здесь что-то не так. Поэтому и спраашиваю.
Автообновление статистики на пользовательских БД я отключил.

tpg

DrNil Full А почему тогда "Полный бэкап логов" раз в сутки и почему он перед "Полный бэкап пользовательских баз"? В чем его тайный смысл? 4. Зачем вам очистка процедурного кэша? у вас статистика сильно меняется и потому у оптимизатора башню сносит? Зачем все эти "перестроения" и "реорганизации" индексов? У вас идет сильная их фрагментация? Почему не делать "адаптивную" реорганизацию/перестроение индексов в зависимости от их фрагментированности?

Если не трудно - разъясните, в чём разница при порядке бэкапов ?
Насколько мне известно очищать процедурный кэш обязательно надо после обновления статистики, иначе потом неоптимальные, устаревшие планы запросов будет использоваться.

А перестроения и реорганизации я сделал ввиду того что постоянно обновляется информация в БД

Хорошо, если я всё сделал не так как надо, посоветуйте оптимальный план обслуживания с учётом специфики (постоянные вставки данных).
А то критика какая-то необоснованная получается.

DrNil
1. Проверка на целостность ВСЕХ баз данных PHYSICAL_ONLY (ибо слишком много времени занимает нормальная проверка). При успешном выполнении этого пункта переходим к остальным

Лучше делать на другой железяке на отресторенных бэкапах.

DrNil
2. Перестроение индекса для всех пользовательских баз.

Индексы надо перестраивать нужные, а не все.

DrNil
4. Очистка процедурного кэша

Нафига?

DrNil
5. Полный бэкап логов

А зачем вам тогда full recovery, если вы логи бэкапите так же часто, как и базу?

проверка
Второй субплан (дневное обслуживание): 1. Реорганизация индексов всех пользовательских баз.

Что вы там такое делаете, если за 12 часов у вас фрагментируется вся база? O_o

автор
4. Очистка процедурного кэша

Дубль 2: нафига?