Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
Друзья, помогите разобраться с отчетом. Не прошу научить, а прошу потыкать носом на узкие места. Спасибо.

ОТЧЕТ
12 дек 06, 13:29    [3523968]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
ОТЧЕТ
Не прошу научить, а прошу потыкать носом на узкие места.

Почему вы думаете, что у вас есть узкие места? У вас есть реальные проблемы?

38.82 Hard parses в секунду. Расскажите девелоперам, что такое bind-переменные ;)

P.S. Снапшот за сутки - это слишком долго.
12 дек 06, 13:35    [3524028]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
Чего за сутки ? 42 минуты написано ...
12 дек 06, 13:38    [3524062]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
Точно, спасибо.
12 дек 06, 13:39    [3524072]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
SQL*Net more data to client     3,744,852          0        522      0    434.0
12 дек 06, 13:39    [3524079]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
Да. У меня есть реальная проблема при некоторых операциях. Конечно, можно сделать трассировку этих сессий, и потом проанализировать их. Но в данном отчете разве нельзя увидеть что может влиять на торможение. Ведь не всегдя могут быть плохими запросы. Хотя и понятно, что запрос - это услуга, которую мы хотим получить быстро и надо в них искать проблемы. Хранилище у меня RAID5. На нем буквально все. Другие диски мне никто не дает. ОС - Windows. Вот я и думаю ,что может есть и другие места узкие, но по результатам отчета пока не замечаю супер глобальных вещей.
12 дек 06, 13:40    [3524084]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1511
                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
SQL*Net more data to client     3,744,852          0        522      0    434.0

Это что там огромное такое тянется на клиента? 20% времени от 42 минут...
12 дек 06, 13:42    [3524102]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
pre_page_sga                  TRUE
12 дек 06, 13:47    [3524144]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
KoTTT
                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
SQL*Net more data to client     3,744,852          0        522      0    434.0

Это что там огромное такое тянется на клиента? 20% времени от 42 минут...


А по данному отчету, я так понимаю, уже не сказать?
12 дек 06, 13:47    [3524148]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1511
db_file_multiblock_read_count 128

А это число откуда взято? На основе тестов или?
12 дек 06, 13:50    [3524167]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
ОТЧЕТ
Конечно, можно сделать трассировку этих сессий, и потом проанализировать их. Но в данном отчете разве нельзя увидеть что может влиять на торможение.

Это общесистемная агрегация. Из агрегации нельзя понять составляющие. Наибольшая проблема системы не обязательно является наибольшей проблемой волнующих вас операций. Вы можете "попасть", если будете удачливы. Вы можете сравнить сегодняшний отчёт (всё плохо) со вчерашним (все хорошо) - и посмотреть что бросится в глаза.

Волнующие вас операции испытывают проблемы с SQL*Net more data to client? Или это ождиания испытываю те, чьи сессии никого не волнуют? Может быть да, может быть нет. "Может быть" - вы не можете сказать точно по этой агрегации. Трассировка конкретной проблемной сессии может.
12 дек 06, 13:50    [3524169]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
KoTTT
db_file_multiblock_read_count 128

А это число откуда взято? На основе тестов или?


Это из рекомендаций разработчиков.
12 дек 06, 13:52    [3524191]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
Q u a d r o
ОТЧЕТ
Конечно, можно сделать трассировку этих сессий, и потом проанализировать их. Но в данном отчете разве нельзя увидеть что может влиять на торможение.

Это общесистемная агрегация. Из агрегации нельзя понять составляющие. Наибольшая проблема системы не обязательно является наибольшей проблемой волнующих вас операций. Вы можете "попасть", если будете удачливы. Вы можете сравнить сегодняшний отчёт (всё плохо) со вчерашним (все хорошо) - и посмотреть что бросится в глаза.

Волнующие вас операции испытывают проблемы с SQL*Net more data to client? Или это ождиания испытываю те, чьи сессии никого не волнуют? Может быть да, может быть нет. "Может быть" - вы не можете сказать точно по этой агрегации. Трассировка конкретной проблемной сессии может.


Понятно. Сделаю сейчас трассиоровку проблемных операций.
12 дек 06, 13:53    [3524198]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
MacDuck
Member

Откуда: Москва-Подольск
Сообщений: 6387
ОТЧЕТ
ОТЧЕТ

db_file_multiblock_read_count 128
large_pool_size               8388608
db_writer_processes           3

Хм...
12 дек 06, 14:14    [3524392]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
MacDuck
Member

Откуда: Москва-Подольск
Сообщений: 6387
ОТЧЕТ

Это из рекомендаций разработчиков.


Очень интересно.

А это откуда:
optimizer_index_caching       95
optimizer_index_cost_adj      10
12 дек 06, 14:16    [3524412]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
ОТЧЕТ
Guest
Замечания понял! Сейчас буду их изучать. Спасибо.

Вот TKPROF проблемной операции ОТЧЕТ
12 дек 06, 14:50    [3524764]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1511
И в чем там проблема?
Разве что в
SQL*Net message from client                  1008       10.99         34.56

Ну и в hard parsing, ес-но.
12 дек 06, 14:58    [3524839]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
ОТЧЕТ
Вот TKPROF проблемной операции ОТЧЕТ


У вас два лидера:

SELECT /*+FIRST_ROWS*/ t.t_CredOperID, t.t_ObjectTypeID_Ref, 
  t.t_OperTypeNumber_Ref, t.t_IsDeleted, t.t_ObjectID_Ref, t.t_CredOperDate, 
  t.t_CreditNumber_Ref, t.t_SystemOperationID, t.t_StageID_Ref, 
  t.t_BatchOperID_Ref,lobject.t_SHORTNAME, op_stage.t_STAGENAME, 
  type_op.t_TYPEOPERNAME, t.t_SYSTEMOPERATIONID, copstage.t_OPER 
FROM
 dcrd_op_dbt t, dcopstage_dbt copstage, dlobject_dbt lobject, dop_stage_dbt 
  op_stage, dtype_op_dbt type_op WHERE (t.t_CredOperID >= :1) AND 
  (((((((t.t_OBJECTTYPEID_REF=lobject.t_OBJECTID AND t.t_STAGEID_REF=
  op_stage.t_STAGEID) AND t.t_OPERTYPENUMBER_REF=type_op.t_TYPEOPERNUMBER) 
  AND t.t_STAGEID_REF=copstage.t_STAGEID_REF) AND t.t_CREDOPERID=
  copstage.t_CREDOPERID_REF) AND t.t_ISDELETED=:2) AND ((t.t_CreditNumber_Ref=
  :3 AND (t.t_ObjectTypeID_Ref=:4 OR t.t_ObjectTypeID_Ref=:5)) OR 
  (t.t_ObjectTypeID_Ref=:6 AND t.t_ObjectID_Ref IN (select 
  ens_crd.t_EnsContractID_Ref from dens_crd_dbt ens_crd where 
  ens_crd.t_CreditNumber_Ref=26))))) ORDER BY t.t_CredOperID


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.04          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch       14     47.53      48.98      10086    6491692          0         144
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       18     47.54      49.02      10086    6491692          0         144

Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 129  

Rows     Row Source Operation
-------  ---------------------------------------------------
     72  FILTER  
 518769   NESTED LOOPS  
 518769    NESTED LOOPS  
 518769     NESTED LOOPS  
 518769      NESTED LOOPS  
 518769       TABLE ACCESS BY INDEX ROWID DCRD_OP_DBT 
 533841        INDEX RANGE SCAN DCRD_OP_DBT_IDX0 (object id 915276)
 518769       TABLE ACCESS BY INDEX ROWID DCOPSTAGE_DBT 
1037578        INDEX RANGE SCAN DCOPSTAGE_DBT_IDX1 (object id 915157)
 518769      TABLE ACCESS BY INDEX ROWID DOP_STAGE_DBT 
 518769       INDEX UNIQUE SCAN DOP_STAGE_DBT_IDX0 (object id 917239)
 518769     TABLE ACCESS BY INDEX ROWID DLOBJECT_DBT 
 518769      INDEX UNIQUE SCAN DLOBJECT_DBT_IDX0 (object id 916700)
 518769    TABLE ACCESS BY INDEX ROWID DTYPE_OP_DBT 
 518769     INDEX UNIQUE SCAN DTYPE_OP_DBT_IDX1 (object id 919581)
      1   INDEX UNIQUE SCAN DENS_CRD_DBT_IDX0 (object id 915929)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                      14        0.00          0.00
  db file sequential read                     10086        0.14          9.49
  SQL*Net message from client                    14        0.00          0.02
  latch free                                      2        0.00          0.00
********************************************************************************

SELECT /*+FIRST_ROWS*/ t.t_CredOperID, t.t_ObjectTypeID_Ref, 
  t.t_OperTypeNumber_Ref, t.t_IsDeleted, t.t_ObjectID_Ref, t.t_CredOperDate, 
  t.t_CreditNumber_Ref, t.t_SystemOperationID, t.t_StageID_Ref, 
  t.t_BatchOperID_Ref,lobject.t_SHORTNAME, op_stage.t_STAGENAME, 
  type_op.t_TYPEOPERNAME, t.t_SYSTEMOPERATIONID, copstage.t_OPER 
FROM
 dcrd_op_dbt t, dcopstage_dbt copstage, dlobject_dbt lobject, dop_stage_dbt 
  op_stage, dtype_op_dbt type_op WHERE (t.t_CredOperID <= :1) AND 
  (((((((t.t_OBJECTTYPEID_REF=lobject.t_OBJECTID AND t.t_STAGEID_REF=
  op_stage.t_STAGEID) AND t.t_OPERTYPENUMBER_REF=type_op.t_TYPEOPERNUMBER) 
  AND t.t_STAGEID_REF=copstage.t_STAGEID_REF) AND t.t_CREDOPERID=
  copstage.t_CREDOPERID_REF) AND t.t_ISDELETED=:2) AND ((t.t_CreditNumber_Ref=
  :3 AND (t.t_ObjectTypeID_Ref=:4 OR t.t_ObjectTypeID_Ref=:5)) OR 
  (t.t_ObjectTypeID_Ref=:6 AND t.t_ObjectID_Ref IN (select 
  ens_crd.t_EnsContractID_Ref from dens_crd_dbt ens_crd where 
  ens_crd.t_CreditNumber_Ref=26))))) ORDER BY t.t_CredOperID DESC


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        7     24.18      24.80         11    3246141          0          72
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9     24.18      24.80         11    3246141          0          72

Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 129  

Rows     Row Source Operation
-------  ---------------------------------------------------
     72  FILTER  
 518769   NESTED LOOPS  
 518769    NESTED LOOPS  
 518769     NESTED LOOPS  
 518769      NESTED LOOPS  
 518769       TABLE ACCESS BY INDEX ROWID DCRD_OP_DBT 
 533841        INDEX RANGE SCAN DESCENDING DCRD_OP_DBT_IDX0 (object id 915276)
 518769       TABLE ACCESS BY INDEX ROWID DCOPSTAGE_DBT 
1037578        INDEX RANGE SCAN DCOPSTAGE_DBT_IDX1 (object id 915157)
 518769      TABLE ACCESS BY INDEX ROWID DOP_STAGE_DBT 
 518769       INDEX UNIQUE SCAN DOP_STAGE_DBT_IDX0 (object id 917239)
 518769     TABLE ACCESS BY INDEX ROWID DLOBJECT_DBT 
 518769      INDEX UNIQUE SCAN DLOBJECT_DBT_IDX0 (object id 916700)
 518769    TABLE ACCESS BY INDEX ROWID DTYPE_OP_DBT 
 518769     INDEX UNIQUE SCAN DTYPE_OP_DBT_IDX1 (object id 919581)
      4   INDEX UNIQUE SCAN DENS_CRD_DBT_IDX0 (object id 915929)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       7        0.00          0.00
  latch free                                     11        0.00          0.00
  db file sequential read                        11        0.01          0.05
  SQL*Net message from client                     7        0.00          0.00
********************************************************************************

optimizer_index_cost_adj=10 заставляет оптимизатор считать индексный доступ в 10 раз дешевле (девелоперы "повёрнуты" на индексах?).

Верните это в 100 (на уровне сессии), уберите хинт first_rows и выполните эти запросы, посмотрите на результат. Судя по Rows с использованием индекса вытаскивается не мало записей (какой это % это общего кол-ва записей в таблице?). И обратите внимание - вы тащите тонны информации, чтобы на последнем шаге оставить только 72 записи (на стадии filter). Посмотрите на предикаты доступа.
12 дек 06, 15:06    [3524890]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Заменить один из OR на IN, а второй передалать в UNION ALL (или UNION - на месте понятнее будет).
Должно дать прирост перфоманса.
Хотя в остальных случаях ЭТОТ ЖЕ запрос выполняется быстро (отличается только сортировкой парой пробелов в строке " op_stage, dtype_op_dbt type_op WHERE ( t.t_CredOperID = :1 ) AND")
Это наводит на мысль, что подводит параметр _optim_peek_user_binds=TRUE.
Для одного из запросов план правильный - целиком на UNIQUE SCAN.
Советую захинтовать запрос, прописав путь доступа явными образом, хотя может хватить и хинта ORDERED и/или USE_NL со списком алиасов из "правильного" плана.
12 дек 06, 16:16    [3525473]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
RA\/EN
Для одного из запросов план правильный - целиком на UNIQUE SCAN.

Скажите мне - каким образом "целиком на UNIQUE SCAN" означает правильный план??

Небольшой пример:

select /*+ first_rows */ *
 from z_test a, z_test2 b
 where a.object_id=b.object_id
  and a.object_id between 0 and 1000000
  and mod(b.data_object_id, 700)=0
 order by a.object_id

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.02          0          4          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      1.12       1.10          0     123966          0         165
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      1.13       1.13          0     123970          0         165

Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 5  

Rows     Row Source Operation
-------  ---------------------------------------------------
    165  NESTED LOOPS  (cr=123966 pr=0 pw=0 time=431211 us)
  61202   TABLE ACCESS BY INDEX ROWID Z_TEST (cr=1558 pr=0 pw=0 time=183673 us)
  61202    INDEX RANGE SCAN I_Z_TEST (cr=130 pr=0 pw=0 time=61250 us)(object id 154176)
    165   TABLE ACCESS BY INDEX ROWID Z_TEST2 (cr=122408 pr=0 pw=0 time=888127 us)
  61202    INDEX UNIQUE SCAN I_Z_TEST2 (cr=61206 pr=0 pw=0 time=446816 us)(object id 154177)

select /*+ full(a) full(b) */ *
 from z_test a, z_test2 b
 where a.object_id=b.object_id
  and a.object_id between 0 and 1000000
  and mod(b.data_object_id, 700)=0
 order by a.object_id

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          4          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      0.12       0.11          0       1710          0         165
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      0.12       0.12          0       1714          0         165

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5  

Rows     Row Source Operation
-------  ---------------------------------------------------
    165  SORT ORDER BY (cr=1710 pr=0 pw=0 time=117259 us)
    165   HASH JOIN  (cr=1710 pr=0 pw=0 time=97569 us)
    165    TABLE ACCESS FULL Z_TEST2 (cr=855 pr=0 pw=0 time=56903 us)
  61202    TABLE ACCESS FULL Z_TEST (cr=855 pr=0 pw=0 time=74 us)


Теперь вы скажете мне, что "целиком на UNIQUE SCAN" - правильный план???
12 дек 06, 16:29    [3525613]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Q u a d r o
RA\/EN
Для одного из запросов план правильный - целиком на UNIQUE SCAN.

Скажите мне - каким образом "целиком на UNIQUE SCAN" означает правильный план??

/*поскакали сферические кони в вакууме*/ 

Q u a d r o
Теперь вы скажете мне, что "целиком на UNIQUE SCAN" - правильный план???


Я в отчете смотрел, там сначала одни юники, потом, около конца, только один RANGE (пропфукал его), и время выполнения микросопокическое. Отличие данного запроса от предыдущего (проблемного) я привел, как и возможную причину.
P.S. Я не теоретически рассуждаю, а практически по данному запросу и по данному трейсу.
12 дек 06, 16:44    [3525775]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
RA\/EN
/*поскакали сферические кони в вакууме*/

Какой хороший у вас аргумент.
12 дек 06, 17:08    [3526032]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
Q u a d r o
RA\/EN
/*поскакали сферические кони в вакууме*/

Какой хороший у вас аргумент.

Ну ё-мое, ну когда по проводкам или чему-то подобному стоит хинт FIRST_ROWS, какой план может быть (что разрабочик имел ввиду)? Какой HASH JOIN?
Г-н Quadro, Вы, несомненно, профессионал, но сейчас вырвали фразу из контекста.
Лучше конструктивно покритикуйте мое мнение применимо к данной задаче.
12 дек 06, 17:35    [3526302]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
RA\/EN
Г-н Quadro, Вы, несомненно, профессионал, но сейчас вырвали фразу из контекста.
Лучше конструктивно покритикуйте мое мнение применимо к данной задаче.

Хорошо - Вам следует смотреть внимательней, вместо того чтобы кидаться в меня конями в вакууме... Без обид?

Для запроса в 0.01 сек.:

1      NESTED LOOPS  
1       TABLE ACCESS BY INDEX ROWID DCRD_OP_DBT 
1        INDEX UNIQUE SCAN DCRD_OP_DBT_IDX0 (object id 915276)
1       TABLE ACCESS BY INDEX ROWID DTYPE_OP_DBT 
1        INDEX UNIQUE SCAN DTYPE_OP_DBT_IDX1 (object id 919581)

Для того что выполнился два раза за 49.02 сек.:

518769      NESTED LOOPS  
518769       TABLE ACCESS BY INDEX ROWID DCRD_OP_DBT 
533841        INDEX RANGE SCAN DCRD_OP_DBT_IDX0 (object id 915276)
518769       TABLE ACCESS BY INDEX ROWID DCOPSTAGE_DBT 
1037578        INDEX RANGE SCAN DCOPSTAGE_DBT_IDX1 (object id 915157)

Судя по тому, что в запросах присутсвует ORDER BY t.t_CredOperID но в итоге шага SORT ORDER BY в плане нет - DCRD_OP_DBT_IDX0 и есть индекс по DCRD_OP_DBT.t_CredOperID.

Разница лишь в изначальном access-предикате для t.t_CredOperID. В первом случае он t.t_CredOperID = :1 (отсюда unique scan), во втором - t.t_CredOperID >= :1 (отсюда range scan).

Эти разные запросы и возвращают они разный ответ.

Я только могу сказать, что во втором случае driving table и/или пусть доступа к ней возможно выбраны не верно - из 518769 записей, удовлетворяющих условию t.t_CredOperID >= :1 в конечном итоге было оставлено 72. Поэтому я и спросил - какой это процент по отношению к общему кол-ву записей в таблице (может дешевле будет full scan) или выбран просто не верный access-предикат (поэтому посоветовал убрать first_rows, который имеет обычай тяготь ко всякой ерунде если может избежать sort order by, да ещё и в придачу для него индексы выглядят на порядок дешевле чем должны...).
12 дек 06, 17:52    [3526412]     Ответить | Цитировать Сообщить модератору
 Re: ОТЧЕТ STATSPACK  [new]
Q u a d r o
Member

Откуда: Canada
Сообщений: 1987
RA\/EN
Ну ё-мое, ну когда по проводкам или чему-то подобному стоит хинт FIRST_ROWS, какой план может быть (что разрабочик имел ввиду)? Какой HASH JOIN?

Никогда не видели, как "повёрнутые" на индексах разработчики рисуют этот хинт, только чтобы увидеть в плане индексы, которые делают их счастливыми?

Давайте отличать случай "я интерактивное приложение и хочу первые строки как можно быстрее" и "опс, у нас были повёрнутые на индексах разработчики....". С учётом параметров optimizer_index_caching и optimizer_index_cost_adj мне кажется симпатичным второй вариант :)
12 дек 06, 17:59    [3526470]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить