Может кто-нибудь пролить некоторый свет на это?
В наших ящиках для разработчиков наша база данных полностью находится в файловой группе PRIMARY, и все работает нормально.
Мы заметили, что на одном из наших производственных серверов, недавно обновленных с 2005 по 2008 год, он работает медленнее, чем должен. На этом компьютере есть две файловые группы - PRIMARY и INDEXES. Обе файловые группы содержат по 1 файлу на логический том, по одному логическому тому на ЦП (и каждый логический том представляет собой RAID 10 из 4 физических дисков).
Мы изолировали несколько запросов, которые выполнялись быстро на устройствах разработки и медленно (до 40 раз медленнее) на производственной машине. Оказалось, что эти запросы использовали некластеризованные индексы, которые находились в файловой группе INDEXES. Настройка некоторых запросов для использования только кластеризованных индексов, которые были в файловой группе PRIMARY, снизила их время до нормального.
В качестве окончательного подтверждения, мы повторно развернули ту же базу данных на том же компьютере, чтобы все было в ПЕРВИЧНОМ, и все вернулось к норме!
Вот статистический вывод одного из запросов, выполняемых одинаково на машине с разными конфигурациями файловых групп (имена таблиц изменены для защиты невиновных):
БЫСТРО (все в ПЕРВИЧНОЙ файловой группе):
(3 row(s) affected)
Table '0'. Scan count 2, logical reads 14, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '2'. Scan count 2, logical reads 7, ...
Table '3'. Scan count 2, logical reads 1012, ...
Table '4'. Scan count 1, logical reads 3, ...
SQL Server Execution Times:
CPU time = 437 ms, elapsed time = 445 ms.
МЕДЛЕННО (индексы разбиты на собственную файловую группу):
(3 row(s) affected)
Table '0'. Scan count 209, logical reads 428, ...
Table '1'. Scan count 0, logical reads 0,...
Table '2'. Scan count 1021, logical reads 9043,....
Table '3'. Scan count 209, logical reads 105754, ....
Table '4'. Scan count 0, logical reads 0, ....
Table '5'. Scan count 1, logical reads 695, ...
**Table '#46DA8CA9'. Scan count 205, logical reads 205, ...**
Table '6'. Scan count 6, logical reads 436, ...
Table '7'. Scan count 1, logical reads 12,....
SQL Server Execution Times:
CPU time = 17581 ms, elapsed time = 17595 ms.
Обратите внимание на странную временную таблицу и дополнительные таблицы, задействованные в медленном запросе. Кажется очевидным, что наличие второй файловой группы затрудняет выбор плана выполнения для SQL Server. Что, черт возьми, происходит?
Я считаю, что тот факт, что некластеризованные индексы находятся в другой файловой группе, здесь не имеет значения, из выходных данных STATISTICS IO выше ясно, что у вас есть два совершенно разных плана выполнения.
Вы перестраивали индексы и обновляли статистику после обновления с SQL 2005 до SQL 2008? Если нет, сделайте это как можно скорее. Если вы можете опубликовать планы выполнения обоих запусков (а также план из окна разработчика), это может дать больше информации.