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

Откуда: Jacksonville, FL
Сообщений: 16268
Доброго времени суток, уважаемые.
просветите, почему оптимизатор считает, что с индексом хуже, чем без индекса.
Исходные данные.
Table Stats::
  Table: TRANSACTION_HISTORY  Alias: TRANSACTION_HISTORY  (Using composite stats)
  (making adjustments for partition skews)
  ORIGINAL VALUES::    #Rows: 100373481  #Blks:  1263288  AvgRowLen:  89.00
  PARTITIONS::
  PRUNED: 1463
  (sampled 919 partitions) 

Index: TRANSACTION_HISTORY_TC_I  Col#: 10
    USING COMPOSITE STATS
    LVLS: 2  #LB: 341216  #DK: 188  LB/K: 1814.00  DB/K: 75311.00  CLUF: 14158650.00 
SQL> select a.partitioning_type, a.partition_count,  a.locality from user_part_indexes a where a.index_name='TRANSACTION_HISTORY_TC_I';

PARTITI PARTITION_COUNT LOCALI
------- --------------- ------
RANGE              1463 LOCAL
Таблица рэнж партицированая. Одна партиция - один день.
методы доступа со следующей статистикой
Access Path: TableScan
    Cost:  118838.84  Resp: 118838.84  Degree: 0
      Cost_io: 108308.00  Cost_cpu: 60939006617
      Resp_io: 108308.00  Resp_cpu: 60939006617
  Access Path: index (RangeScan)
    Index: TRANSACTION_HISTORY_TC_I
    resc_io: 1257557.00  resc_cpu: 19052271628
    ix_sel: 0.086527  ix_sel_with_filters: 0.086527
    Cost: 1260849.41  Resp: 1260849.41  Degree: 1 

соответсвтенно, оптимизатор выберет TableScan, но ниже видно
SQL> select /*+index(TRANSACTION_HISTORY TRANSACTION_HISTORY_TC_I)*/
  2  count(*)
  3  from srv.transaction_history
  4  where transaction_type_code in (101202, 101207, 101201)
  5  and entry_date > trunc(sysdate);

  COUNT(*)
----------
        77

 Elapsed: 00:00:00.06

Execution Plan
----------------------------------------------------------
Plan hash value: 2665839937

--------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop
--------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                          |     1 |    13 |  1260K  (1)| 01:52:55 |       |
|   1 |  SORT AGGREGATE                      |                          |     1 |    13 |            |          |       |
|   2 |   PARTITION RANGE ITERATOR           |                          | 34012 |   431K|  1260K  (1)| 01:52:55 |   KEY |  1463
|   3 |    INLIST ITERATOR                   |                          |       |       |            |          |       |
|*  4 |     TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTION_HISTORY      | 34012 |   431K|  1260K  (1)| 01:52:55 |   KEY |  1463
|*  5 |      INDEX RANGE SCAN                | TRANSACTION_HISTORY_TC_I |  8659K|       | 32821   (2)| 00:02:57 |   KEY |  1463
--------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - filter("ENTRY_DATE">TRUNC(SYSDATE@!))
   5 - access("TRANSACTION_TYPE_CODE"=101201 OR "TRANSACTION_TYPE_CODE"=101202 OR "TRANSACTION_TYPE_CODE"=101207)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2449  consistent gets
          0  physical reads
          0  redo size
        207  bytes sent via SQL*Net to client
        247  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> ed
Wrote file afiedt.buf

  1  select
  2  count(*)
  3  from srv.transaction_history
  4  where transaction_type_code in (101202, 101207, 101201)
  5* and entry_date > trunc(sysdate)
SQL> /

  COUNT(*)
----------
        77

Elapsed: 00:00:04.78

Execution Plan
----------------------------------------------------------
Plan hash value: 977220078

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                 | Name                | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |                     |     1 |    13 |   118K  (9)| 00:10:39 |    |  |
|   1 |  SORT AGGREGATE           |                     |     1 |    13 |            |          |    |  |
|   2 |   PARTITION RANGE ITERATOR|                     | 34012 |   431K|   118K  (9)| 00:10:39 |   KEY |  1463 |
|*  3 |    TABLE ACCESS FULL      | TRANSACTION_HISTORY | 34012 |   431K|   118K  (9)| 00:10:39 |   KEY |  1463 |
-----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter(("TRANSACTION_TYPE_CODE"=101201 OR "TRANSACTION_TYPE_CODE"=101202 OR
              "TRANSACTION_TYPE_CODE"=101207) AND "ENTRY_DATE">TRUNC(SYSDATE@!))


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       2973  consistent gets
        894  physical reads
          0  redo size
        224  bytes sent via SQL*Net to client
        247  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL>

Заранее спасибо
23 окт 08, 11:37    [6345016]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
#DK: 188
Маловато будет :)
23 окт 08, 12:31    [6345545]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Timm
#DK: 188
Маловато будет :)

не прокоментируете более подробно ?
23 окт 08, 12:37    [6345591]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Покажи row source из трейса первого плана (с использованием индекса).
Скорее всего первый пункт плана (сканирование индекса) возвращает горазде меньше строк, чем это предполагает оптимизатор (8,6М - кстати, как он получил это число?). Т.е. он скорее всего ошибается уже с первого шага, вероятно, из-за разницы в распределении данных в колонке transaction_type_code, в которой для значений (101202, 101207, 101201) записей гораздо меньше чем "в среднем по больнице TRANSACTION_HISTORY_TC_I".
23 окт 08, 13:04    [6345882]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=2710 pr=1 pw=0 time=46216 us)'
STAT #1 id=2 cnt=704 pid=1 pos=1 obj=0 op='PARTITION RANGE ITERATOR PARTITION: KEY 1463 (cr=2710 pr=1 pw=0 time=5714 us)'
STAT #1 id=3 cnt=704 pid=2 pos=1 obj=0 op='INLIST ITERATOR  (cr=2710 pr=1 pw=0 time=34620 us)'
STAT #1 id=4 cnt=704 pid=3 pos=1 obj=154083 op='TABLE ACCESS BY LOCAL INDEX ROWID TRANSACTION_HISTORY PARTITION: KEY 1463 (cr=2710 pr=1 pw=0 time=29904 us)'
STAT #1 id=5 cnt=704 pid=4 pos=1 obj=163020 op='INDEX RANGE SCAN TRANSACTION_HISTORY_TC_I PARTITION: KEY 1463 (cr=2405 pr=1 pw=0 time=15924 us)'
XCTEND rlbk=0, rd_only=1
23 окт 08, 14:03    [6346529]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Ну вот, 704 строки in real vs. 8.6M approximated.
Если запрос настолько важен, можно собрать статистику с гистограммами по этому столбцу. Тогда у CBO будет пища для размышлений :)
23 окт 08, 14:10    [6346600]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Timm
Ну вот, 704 строки in real vs. 8.6M approximated.
Если запрос настолько важен, можно собрать статистику с гистограммами по этому столбцу. Тогда у CBO будет пища для размышлений :)

спасибо большое... теперь есть куда рыть.
23 окт 08, 14:16    [6346665]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
pravednik
Timm
Ну вот, 704 строки in real vs. 8.6M approximated.
Если запрос настолько важен, можно собрать статистику с гистограммами по этому столбцу. Тогда у CBO будет пища для размышлений :)

спасибо большое... теперь есть куда рыть.


Посмотрите трайс event 10053.

С уважением,
bw.
24 окт 08, 10:36    [6350612]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
BW
pravednik
Timm
Ну вот, 704 строки in real vs. 8.6M approximated.
Если запрос настолько важен, можно собрать статистику с гистограммами по этому столбцу. Тогда у CBO будет пища для размышлений :)

спасибо большое... теперь есть куда рыть.


Посмотрите трайс event 10053.

С уважением,
bw.

ну, собственно, исходные данные вместе с методами доступа как раз от туда
24 окт 08, 10:50    [6350727]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
sql+
Guest
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.
24 окт 08, 10:56    [6350788]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
sql+
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.

ну это как раз тот случай, когда "не стал сильно опираться на 10053".... статистика не качественная, поэтому имею такие пироги
24 окт 08, 10:59    [6350820]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Опять же не факт, что 2449 consistent gets одноблочным чтением при доступе по индексу быстрее чем 2973 consistent gets мультиблочным при fullscan. Рассчитывать на то, что всегда все блоки будут в кэше наверное нельзя. По мне так, план не так уж и плох :)
24 окт 08, 11:20    [6351007]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
wurdu
Опять же не факт, что 2449 consistent gets одноблочным чтением при доступе по индексу быстрее чем 2973 consistent gets мультиблочным при fullscan. Рассчитывать на то, что всегда все блоки будут в кэше наверное нельзя. По мне так, план не так уж и плох :)

ну как выяснилось, план с индексом не совсем правильный )))....
а по поводу мультиблочных чтений, то при фулскане их всего 19, по 5 блоков в каждом... остальные 799 - одноблочные
24 окт 08, 12:13    [6351502]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
Коль топик вроде прикрыт, то можно похволить немного оффтопа.

sql+
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.


Можно поподробнее? Я был уверен, что 10053 можно доверять не меньше, чем 10046.

С уважением,
bw.
24 окт 08, 14:57    [6352735]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
BW
Коль топик вроде прикрыт, то можно похволить немного оффтопа.

sql+
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.


Можно поподробнее? Я был уверен, что 10053 можно доверять не меньше, чем 10046.

С уважением,
bw.

ну вы посомотрите...оптимизатор по своей статистике решил, что в индексе перелопатится 8.5 миллиона строк, хотя трейс 10046 показал, что на самом деле 704
24 окт 08, 15:14    [6352901]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
pravednik
BW
Коль топик вроде прикрыт, то можно похволить немного оффтопа.

sql+
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.


Можно поподробнее? Я был уверен, что 10053 можно доверять не меньше, чем 10046.

С уважением,
bw.

ну вы посомотрите...оптимизатор по своей статистике решил, что в индексе перелопатится 8.5 миллиона строк, хотя трейс 10046 показал, что на самом деле 704


Покажите полный файл от 10053.

С уважением,
bw.
24 окт 08, 15:32    [6353046]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
pravednik
BW
Коль топик вроде прикрыт, то можно похволить немного оффтопа.

sql+
Я бы не стал сильно опираться на 10053. Практика показывет, что 10053 может показать один план. А реальный план будет совсем другой.


Можно поподробнее? Я был уверен, что 10053 можно доверять не меньше, чем 10046.

С уважением,
bw.

ну вы посомотрите...оптимизатор по своей статистике решил, что в индексе перелопатится 8.5 миллиона строк, хотя трейс 10046 показал, что на самом деле 704

Это разные данные. 10046 показывает реальное количество строк, обработанных во время выполнения, это runtime статистика. 10053 - CBO estimations. И оно будет показывать именно тот план, который будет использоваться запросом при включенном трейсе CBO.
Другое дело, что 10053 можно получить не на работающей сессии, а искусственно, через explain plan например. И тогда действительно, план CBO может отличаться от реального просто потому, что CBO насильственно попросили построить план прямо сейчас, а приложение могло использовать другой, заранее полученый. Ничего в этом странного нет, тут все описано.
24 окт 08, 15:37    [6353089]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
pravednik
ну вы посомотрите...оптимизатор по своей статистике решил, что в индексе перелопатится 8.5 миллиона строк, хотя трейс 10046 показал, что на самом деле 704


Всупление Timm написал, поэтому удаляю :)

10046 показывает реальный план по которому выполнялся закрываемый курсор, он тоже может быть не "проблемным", часто можно наблюдать ситуацию когда процедура запущенная под 10046 выполняется быстро, а без медленно. Также можно наблюдать и "смешанную" ситуацию, которая легко вводит в заблуждение, курсор начал выполнятся до трассировки по плохому плану, и в трассировку попадает статистика выполнения с большим временем, а план попадает от следующего открытия курсора, в результате в профайлерах мы видим плохое выполнение запроса по ресурсам и "хороший" план ( не тот, что вызвал эти затраты). Надо внимательно смотреть сырой трейс. В 11g вроде появился дополнительный параметр вывода трассировки 'hv=' , который показывает plan_hash_value
24 окт 08, 15:56    [6353288]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
Timm
Ничего в этом странного нет, тут все описано.


В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

С уважением,
bw.
24 окт 08, 17:02    [6353861]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
BW

В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.
2) С реального приложения не всегда можно получить 10053, поскольку во первых нужно обеспечить hard-parsing, т.е. вытеснить существующий план для начала, а во вторых нужна обычно трассировка одного запроса, а не всей кучи. Поэтому для получения 10053 обычно запрос выносят отдельно в тестовый блок и тут легко получить проблемы из (1) или делают все тот-же explain plan, думаю у sql+ как раз такая проблема.
24 окт 08, 17:38    [6354123]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Я и ёжик
BW

В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.
2) С реального приложения не всегда можно получить 10053, поскольку во первых нужно обеспечить hard-parsing, т.е. вытеснить существующий план для начала, а во вторых нужна обычно трассировка одного запроса, а не всей кучи. Поэтому для получения 10053 обычно запрос выносят отдельно в тестовый блок и тут легко получить проблемы из (1) или делают все тот-же explain plan, думаю у sql+ как раз такая проблема.

в моем случае как раз второй вариант
24 окт 08, 17:44    [6354154]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
Я и ёжик
BW

В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.


Это вообще не понял.

Я и ёжик

2) С реального приложения не всегда можно получить 10053, поскольку во первых нужно обеспечить hard-parsing, т.е. вытеснить существующий план для начала, а во вторых нужна обычно трассировка одного запроса, а не всей кучи. Поэтому для получения 10053 обычно запрос выносят отдельно в тестовый блок и тут легко получить проблемы из (1) или делают все тот-же explain plan, думаю у sql+ как раз такая проблема.


Во-первых, в данном топике определенная ситуация и не надо ее расширять. Если бы планы запросов в трейсах от 10053 и 10046 были разные, тогда можно было думать. Если я не увидел указания на это, то укажите что я пропустил.

Во-вторых, hard-parse - это не проблема, а ограничение, которые кстати есть и у 10046.

С уважением,
bw.
24 окт 08, 18:02    [6354248]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
BW

Я

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.

Это вообще не понял.

Это просто констатация факта, что моменту снятия 10053 могут быть уже другие условия, отличные от тех которые были, когда формировался проблемный план.
"Нельзя войти в одну и ту же реку дважды" (c)


BW

Во-первых, в данном топике определенная ситуация и не надо ее расширять. Если бы планы запросов в трейсах от 10053 и 10046 были разные, тогда можно было думать. Если я не увидел указания на это, то укажите что я пропустил.

Мне кажется вы забыли прочитать то, что написали здесь:
bw https://www.sql.ru/forum/actualpost.aspx?bid=3&tid=607543&mid=6354248&p=1&act=quot#6352735
Коль топик вроде прикрыт, то можно похволить немного оффтопа.
...
Можно поподробнее? Я был уверен, что 10053 можно доверять не меньше, чем 10046.

Т.е. насколко можно понять ваш текст, идет офтопик, в рамках которого ВАМИ поднят вопрос об уточнении фразы sql+ отражающей ЕГО практику и степени доверия к 10053 и 10046.
При чем тут конкретная ситуация ТОПика, если по вашей просьбе мы перешли к офтопику мне непонятно. А в чем в принципе может быть проблема с 10053 с моей точки зрения, я как раз и рассказал.

BW

Во-вторых, hard-parse - это не проблема, а ограничение, которые кстати есть и у 10046.
10046 не требуется hard-parsing для показания статистики курсора, достаточно soft и закрытия курсора. Проблема в том, что до 10.2.0.4 нет методов инвалидации плана конкретного курсора, а инвалидация всех курсоров связаных с какой то таблицей или сброс shared pool на промышленной системе не всегда хорошая идея.
24 окт 08, 18:40    [6354437]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
BW
Member

Откуда:
Сообщений: 727
pravednik
Я и ёжик
BW

В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.
2) С реального приложения не всегда можно получить 10053, поскольку во первых нужно обеспечить hard-parsing, т.е. вытеснить существующий план для начала, а во вторых нужна обычно трассировка одного запроса, а не всей кучи. Поэтому для получения 10053 обычно запрос выносят отдельно в тестовый блок и тут легко получить проблемы из (1) или делают все тот-же explain plan, думаю у sql+ как раз такая проблема.

в моем случае как раз второй вариант


Т.е. наблюдается расхождение между планами исполнения, которые показываются в трассах от 10046 и 10053, и обоих случаях исполнялись запросы, а не использовался EXPLAIN PLAN?

С уважением,
bw.
24 окт 08, 19:22    [6354588]     Ответить | Цитировать Сообщить модератору
 Re: Почему не используется индекс, хотя с ним лучше  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
BW
pravednik
Я и ёжик
BW

В статье не упоминается про 10053. Разницу между EXPLAINPLAN и sql_trace и что такое "bind peeking" я знаю. Но не понимаю в чем проблемы с 10053, если трасса снимается с работающего запроса?

1) Это уже другой парсинг, это могут быть другие переменные, это уже может быть другая среда, другая статистика.
2) С реального приложения не всегда можно получить 10053, поскольку во первых нужно обеспечить hard-parsing, т.е. вытеснить существующий план для начала, а во вторых нужна обычно трассировка одного запроса, а не всей кучи. Поэтому для получения 10053 обычно запрос выносят отдельно в тестовый блок и тут легко получить проблемы из (1) или делают все тот-же explain plan, думаю у sql+ как раз такая проблема.

в моем случае как раз второй вариант


Т.е. наблюдается расхождение между планами исполнения, которые показываются в трассах от 10046 и 10053, и обоих случаях исполнялись запросы, а не использовался EXPLAIN PLAN?

С уважением,
bw.

в обоих случаях выполнялись запросы...могу выслать оба трейса для обоих случаев (с хинтом и без)..но правда, только в понедельник... различее в планах - это роу сорс при индексном доступе
24 окт 08, 20:36    [6354736]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить