Oracle подскажите выход

← →
Кщд (2013-09-12 13:39) [40]

>antonn © (12.09.13 13:10) [38]
и, да - это ни с чем не идёт вразрез
просто Вы не представляете механизма работы СУБД(в данном случае - Oracle).

← →
Пит (2013-09-12 13:43) [41]

> да, это "косяк" транзакционной модели Oracle.

ну почему косяк, это вроде как фича) Чтобы выдать быстрее результаты, предполагая, что не все данные могут быть отфечены в итоге. Вычисления на лету, принцип "не делать того, что можно сделать позже", это вполне интересная концепция

> не "догнал", от чего может зависеть план в данном случае?

от того, что нужно. Как можно быстрее получить все результаты или как можно быстрее получить первый результат - от этого может зависеть план запроса. И могут применяться разные стратегии, в зависимости от того, что нужно получить

← →
Пит (2013-09-12 13:45) [42]

> если результат запроса не хранится

ну, кстати, у многих БД (оракл в том числе) есть кеш запросов. Что наглядно видно, когда второй раз запрос исполняется заметно быстрее.

← →
Кщд (2013-09-12 13:55) [43]

>Пит (12.09.13 13:43) [41]
>ну почему косяк, это вроде как фича)
ясно, я не о том

>Как можно быстрее получить все результаты или как можно быстрее получить первый результат
про first_rows, all_rows - это понятно
думал, речь идёт о смене плана для УЖЕ открытого курсора

← →
[ВладОшин] © (2013-09-12 13:57) [44]

всегда думал, что надо подсказки юзать
иначе никак

ну эти SELECT /*+ FIRST_ROWS([num_row]) */ или /*+ ALL_ROWS */
они на план, бывает, влияют

а в компоненте(про который говорил) юзается курсор, да.

← →
Пит (2013-09-12 14:09) [45]

> всегда думал, что надо подсказки юзать
> иначе никак

ну почему никак... Например, если оракл встретит:

... where exists (select null from xxx)

понятно же, что подзапрос логичнее выполнять по стратегии получения первого результата, на чем и остановиться.

← →
Кщд (2013-09-12 14:12) [46]

>[ВладОшин] © (12.09.13 13:57) [44]
>всегда думал, что надо подсказки юзать
лучше не надо)
а если очень хочется, то не псевдоинтеллектуальные, типа "first_rows"/ "all_rows", правила работы которых сокрыты в чёрном ящике оптимизатора, а конкретные - для получения желаемого плана

← →
Кщд (2013-09-12 14:26) [47]

>Пит (12.09.13 14:09) [45]
указанный пример - это не стратегия оптимизатора
это метод объединения таблиц(или наборов данных)
в данном случае - это cross-join semi, т.е. декартово полуобъединение

> Кщд (12.09.13 14:12) [46]

Я про
>> Как можно быстрее получить все результаты или как можно быстрее получить первый результат

А то, что индексы подсказать юзать и какие - это понятно. естественно.

> лучше не надо)

Да и я так думаю. Да и не хочется :)
Только иногда (2 раза в последние 2 года понадобилось) приходится. Иначе никак было, очень долго без
/*+ use_hash(sss, nnn) index(nnn) */
/*+ OPT_PARAM("optimizer_index_caching", 100) OPT_PARAM("optimizer_index_cost_adj", 10) */
работало
Ну и то - пока нашел, пока прочитал, пока подобрал значения..

Я просил пример, когда юзверю требуется листать НД по 5 килозаписей на страницу...
И когда это оправдано, нежели сразу запросить только то, что нужно...
(Про объем трафика умолчу)

> Dennis I. Komarov © (12.09.13 21:58) [49]
>
> Я просил пример, когда юзверю требуется листать НД по 5
> килозаписей на страницу

Платежи за неделю. Куча таблиц, сложные соединения. Работает секунд 10. Группировка по точкам продаж.
Отлично, говорит юзер. А теперь по датам.
Отлично, говорит юзер. А теперь по типу юзеров.
А сколько принял каждый оператор? А во сколько на каких точках максимум?
и т.п.
Т.е. все записи те же самые, но юзер их по разному группирует

Второй раз уже не 10 сек, конечно, меньше, но все равно, подвисает.

Поэтому: берем все и грид с возможностями+.
Данные (5 к) уже готовы/отобраны, все на клиенте
Группируются секунду - две.

И более того, если у юзера есть вопрос по какой то цифре из группировки - он может тут же развернуть ее и посмотреть из чего она складывается.

Oracle подскажите выход Найти похожие ветки