Кому интересно. Oracle Reports 10.1.2.3

Столкнулся с такой фичей, - есть таблица, с кучей полей.
В таблице есть поле, пусть будет "abc", типа char(2) not null (не индексировано), значения типа: 01,02,03 и т.д..
Так вот в "в репортах", если в запросе написать
, то отчёт генерится минуты 2,
а если
или равносильно
, то 5-10 секунд!

Замечу, что сам запрос, что с abc='01' , что abc=1 - отрабатавает одинаково быстро (0,01 сек.)

Может кто знает, где @ зарыта?

Leonid Kudryavtsev,

Сам бы не поверил )
Планы посмотрел, причина понятна и в тоже время нет )

table: id (number), abc char(2), created (sysdate) ...

index1: id
index2: zzz, abc, yyy
index3: abc, created

Запросы:
1.

2.


Так вот SQL Developer, SQL Plus в запросах 1 и 2 использует index3
А Reports, в 1 случае - index2, а во втором - index1

Leonid Kudryavtsev,

самому не понятно..
а получается всё может быть и быть всё может, чеснслово..
скрин прилагаю

Leonid Kudryavtsev,

v$sql
sql_textmodulehash_valueselect id from hm_tp where tp='01' and created between :d_sta and :d_endrwbuilder.exe3322942397
v$sql_plan 3322942397
operation options object_nameobject_type filter_predicatesINDEXUNIQUE SCANindex1INDEX (UNIQUE)("CREATED">=:D_STA AND "CREATED"<=:D_END)INDEXSKIP SCANindex2INDEX"TP"='01'

v$sql
sql_textmodulehash_valueselect id from hm_tp where tp=01 and created between :d_sta and :d_endrwbuilder.exe1710107384
v$sql_plan 1710107384
operation options object_nameobject_type filter_predicatesINDEXUNIQUE SCANindex1INDEX (UNIQUE)TO_NUMBER("TP")=1INDEXRANGE SCANindex4INDEXnull

index4: created

d_sta и d_end: Datatype: Date , Width: 12 , Input Mask: ddmmyyyyhh24mi

-=APS=-,

hash_valueoperationoptionsobject_nameobject_typecostcardinalitybytescpu_costaccess_predicatesfilter_predicatesprojectiontime3322942397"INDEX""UNIQUE SCAN""index1""INDEX (UNIQUE)"24019263274263842006"TP"='01'("CREATED">=:D_STA AND "CREATED"<=:D_END)"ID"[NUMBER.22]"33322942397"INDEX""SKIP SCAN""index2""INDEX"23977037432904167"TP"='01'"TP""='01'ROWID[ROWID.31]. "ID"[NUMBER.22]. "TP"[CHARACTER.2]. "CREATED"[DATE.7]. ROWID[ROWID.31]3

hash_valueoperationoptionsobject_nameobject_typecostcardinalitybytescpu_costaccess_predicatesfilter_predicatesprojectiontime1710107384"INDEX""UNIQUE SCAN""index1""INDEX (UNIQUE)"13696273528574"CREATED">=:D_STA AND "CREATED"<=:D_ENDTO_NUMBER("TP")=1"ID"[NUMBER.22]11710107384"INDEX""RANGE SCAN""index4""INDEX"16646261681"CREATED">=:D_STA AND "CREATED"<=:D_ENDROWID[ROWID.31]. "ID"[NUMBER.22]. "TP"[CHARACTER.2]. "CREATED"[DATE.7]. ROWID[ROWID.31]1

-=APS=-,

Не по существу APS :) а "тулза" - select from

Путаетесь в показаниях. Индексы были приведены с одними названиями полей (abc), план с совершенно другим названием полей.
abc это tp

Ну и "а что за план такой, малость "укороченный"?", в v$sql_plan есть и TABLE ACCESS и все остальное. Какие-то куски плана.
Там много чего есть, что нужно то, имхо необходимое привёл.

Вы уверяли, что index1: id а на плане index1 access predicate TP='01'. Кто-то врет или Вы или Oracle. Предположу, что это Вы )))
index1: id
index2: zzz, tp, yyy
index3: tp, created
index4: created

повторюсь, - именно reports использует другие индексы, те же forms используют как нужно - index3

Leonid KudryavtsevНу и понятное дело, что Reports тут совершенно не причем.
Посмотрел, - согласен )

-=APS=-..на основании "подсмотренных" биндов
Что-то в "биндах", - согласен )

вообщем посмотрел EXPLAIN PLAN FOR в навигаторе, что и нужно было сделать изначально, имеем:



Id Operation Name Rows Bytes Cost (%CPU)0 SELECT STATEMENT 1926 32742 240 (1) 1 FILTER 2 INDEX UNIQUE SCAN index1 1926 32742 240 (1) 3 INDEX SKIP SCAN index2 770K 239 (1)



Id Operation Name Rows Bytes Cost (%CPU)0 SELECT STATEMENT 369 6273 1 (0) 1 FILTER 2 INDEX UNIQUE SCAN index1 369 6273 1 (0) 3 INDEX RANGE SCAN index4 6646 1 (0)



Id Operation Name Rows Bytes Cost (%CPU)0 SELECT STATEMENT 14 238 1 (0) 1 INDEX RANGE SCAN index3 14 238 1 (0)

т.е. с биндами одни индексы, без - другие используются