Есть запрос такого типа:
где C - некая константа, которая задается вне запроса.
Здесь нет ни одного условия, индекс-консультант ничего не посоветовал, что и следовало ожидать.
Объем таблицы bgm2 - 70 млн, на выходе запроса получается менее 1 млн записей.
Что можно предпринять, для увеличения скорости его выполнения?

P.S.:План запроса такой:
( WorkTable
( HashGroupBy
( HashGroupBy
( HashJoin*
( TableScan bgm2 )
)
)
)
)

Машина 2xXEON 4Г кэш AWE. Win2003. ASA 9.02.3182
Замечено, что АСА создает еще временный файл asat0000.tmp, который доходит по объему до 10 гиг. Это что же, ему нужен кэш такой? Может ли АСА тратить лишнее время на хранение там промежуточных результатов?
Мне кажется 6 часов слишком жирно для такого запроса.

P.S.: Кстати, АСА этот файлик не обрезает и не удаляет, даже при перезапуске и перезагрузке АСА его не убивает. Т.е. один раз создался, и всё, пока ручками не прибьешь никуда не денется - не приятно как-то втихаря место на диске утекает.

Именно в такой последовательности?
Нет, не существует.
Почему же консультант не посоветовал его? Я вот как раз думал строить или нет его.
Надо проверить бы.

Индекс, кстати, может и не помочь, ибо если он будет использоваться только для упорядочивания, а к этому придется еще читать и основную таблицу, то это может оказаться накладнее. А ведь вся таблица в кэше сидит, т.к. видно что сервер использует только процессор, обращений к диску нет вообще.
Я перед экспериментами как раз хотел посоветоваться, а имеет ли смысл? Ворочить такую таблицу не быстрое дело.

По крайней мере я попробывал создать виртуальный индекс. Как и следовало ожидать ничего кардинального не изменилось. План тот же (и неудивительно когда вся таблица в памяти). Использование индекса оптимизатор отклонил.

Промежуточный набор ~60 млн


Posted via ActualForum NNTP Server 1.3

to golsa
Это и есть две агрегатные OLAP-функции. С группировкой все нормально.

ТЗ никто не писал, т.е. формулирую сам для себя:
Необходимо получить статистический анализ данных. Необходимо расчитать параметры математических моделей, которые отражали бы ряды q по d для каждой пары (b,n).
Проблема в том, что в исходных данных имеется полный реестр (b,n,d,q,...,pk), где b,n,d изначально не уникальны (уникален pk), более того, в любой записи в любой момент может меняться значение n. И держать агрегированый свод (b,n,d,q), где b,n,d уникальны - накладно по производительности и емкости.

А запрос тупой по определению, упростил и так до невозможности. Условно говоря вложенный запрос возвращает нам "куб", три измерения и показатель в данной точке. Над этим кубом работают статистические функции, которые одно измерение заменяют, показателями математических моделей.

Может и впрямь завести агрегированный свод, вместо вложенного селекта?

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

Нее, GROUP BY CUBE и GROUPING SETS здесь не помогут. Они нужны для вычисления итоговых результатов по плоскостям/осям этого куба, а мне эти итоги не нужны. Т.е. они нужны при одновременном использовании нескольких видов группировок, а тут обычная группировка.