Приветствую!В эти праздники проводил комплекс мероприятий по оптимизации SQL-сервера.В число задач к-е я планировал
и выполнил входила дефрагментация базы на 5-ом RAID'е.Трудно сказать насколько сильный эффект на производительность
дала именно эта фича,но скажу одно:сервер стал "летать".1 час дефрагментации 20 гигабайтной базы снизил число фрагментов с 238 до 72-х (т.е.база относительно не так уж и сильно дефрагментирована).Эффект должен быть по определению независимо RAID это или нет.В любом случае не такая уж это длительная и утомительная процедура чтобы мучаться сомнениями-запусти и все.Не забудь что помимо external потом проехаться internal дефрагментацией.
Я дефрагментированные таблицы без кластерных ключей сначала "сжимаю" путем создания левого кластерного индекса.
Данные упаковываются в соотв.с default fill factor.Потом делаю дефрагментацию на уровне экстентов (dbcc dbreindex).
Кластерный индекс убиваю.Вижу: десяток наиболее дефрагментированных таблиц освободили страниц на 3 гига.Про принудительное обновление статистики и прочее думаю говорить не стоит...

2 Александр Гладченко.
Не всегда.Взять банковскую базу данных.Она используется не только как OLTP (ввод документов т.п.)но и получения отчетности.От того что 50 юзеров у меня имеют возможность работать с кэшированными данными (buffer cash hit ratio ок.99 %) это не значит что для построения и получения отчетности одному-двум юзерам эти кэшированные данные пригодятся.
Наоборот в силу специфики используемых таблиц и т.п. я наблюдаю рост phisical I/O активности у этих пользователей.А тут уже вступает в дело фактор фрагментации.Тогда выбираются последовательно данные для отчетности из страниц на диске...