Сделайте пожалуйста
Попробуйте сделать составной индекс по полям date_call, sl_entry[, sl_entry_nom] (можно поэксперементировать разным чередованием полей через VIRTUAL INDEX и посмотреть на планы запросов). Так же попробуйте выполнить:
чтобы СУБД вычислила характеристики скорости жесткого диска.

Плюс сообщите точную версию ASA, так как оптимизаторы 9.0.0, 9.0.1 и 9.0.2 немного работают по разному, самый правильный и точный сейчас на текущий момент я считаю оптимизатор 9.0.2, который умеет делать оценку в планах использования внутренних временных таблиц (work table) и более граммотно определяет когда лучше использовать индекс, когда hash-алгоритм, а когда и просто table scan.

Вышлите пожалуйста на ящик указанный в моем профиле графический план Вашего запроса. Очень интересно посмотреть, почему оптимизатор так поступает.

P.S. На всякий пожарный - посмотреть как его сохранить можно здесь .

Пока смотрю сразу - попробуйте поставить опцию БД "Optimization_Goal" на "All Rows". Насчет максимального приоритета - это погорячились, интересно, а ОС то должна работать сама ? Очень большая фрагментация файла БД, обязательно необходима дефрагментация диска. Есть ли в БД достаточно таблиц с BLOB-ами ? Если нет, то думаю размер страницы 16 кб не уместен и для такой БД лучше подошел бы размер 8 кб. Рекомендую через ASTEMP переназначить хранение временных файлов в специально созданную директорию вместо их хранения в в профильных стандартных папках W2K.

Еще вопрос - сколько вообще памяти на сервере - я смотрю ASA берет в рамках 90-128 мб, это очень мало для 2-х гиговой БД.

Я думаю table scan идет из за большого размера страницы БД (а значит менее вместительного кэша) и малого размера памяти. Оптимизатор видимо считает, что легче сразу провести table scan, с одновременной хэш-группировкой подходящих по фильтру записей не используя кэш, чем поднять в кэш огромный индекс, просмотреть его и выбрать даты, потом поднимать по ним записи с таблицы с фильтрацией и группировкой, а потом проводить сортировку. В принципе с логической точки зрения оптимизатор не прав, так как считать 10 миллионов записей по любому дольше, но с другой стороны для многопользовательской работы может быть он и прав, что не хочет весь используемый кэш отдавать только одному уже изначально долгому процессу и тормозить все остальные процессы.

Выходы:
1. Увеличить размер физической памяти и вообще сменить сервер (желательно)
2. Уменьшить минимальный размер кэш (обязательно)
3. Изменить размер страницы (обязательно)
4. Сделать составной индекс вместо простого (ничего страшного на самом деле, при правильном индексе можно добиться ORDERED GROUP BY, что уберет work table из плана запроса)
5. Навязывать индексы через force (для такого запроса вполне допустимо исходя из того, что примерное содержание данных известно и не изменяется)
6. Сгружать без сортировки все во времянку, ее возвращать клиенту с нужной сортировкой (думаю здесь это не обоснованно)

P.S. Ну и в заключение можно сказать, что во первых table scan не всегда плохо, нужно смотреть на реальное время выполнения запроса, не стоит ожидать от ASA 8-9 шустрой работы одной сессии, так как они ориентированны на большое кол-во сессий и встроенный веб-сервер. И не стоит забывать, что можно написать к ним на форум, выложить план запроса и спросить "почему". Частенько на такие вопросы они создают новый CASE и равняют оптимизатор до нужного уровня.

old_joy MasterZiv
select sl_entry_nom,count(*)
from tarif_string_c
where date_call='2004-11-16'
and sl_entry=11
group by sl_entry_nom
order by isnull(sl_entry_nom,sl_entry_nom)

Пробовал со старым размером страницы (16 кб) - не сработало.


"Тонкая, однако, работа..."
(м/ф "Падал прошлогодний снег")
Вообще оптимизатор ASA очень сложно надуть, я иногда запросы вообще так переписывал, что по соединениям в них таблиц казалось бы вообще ничего общего не было, однако оптимизатор умудрялся все равно давать те же самые планы запросов на них. Из чего я и сделал правильный вывод, что обманывать его пустой номер, нужно искать причину его мотивации выбора соотвествующего плана.