Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Баг? оптимизатора и connect by  [new]
Allbest
Member

Откуда:
Сообщений: 143
SQL> select  to_char(eventdate, 'dd.mm.yyyy hh24:mi.ss') || ' ' || case
  2           when idglobaltype = 2 then
  3            rpad(chr(9), (level - 1) - 1, chr(9))
  4           else
  5            rpad(chr(9), level - 1, chr(9))
  6         end || eventdescr as eventdescr
  7    from log
  8   start with idlog = :id
  9  connect by prior idlog = idlogparent
 10   order siblings by idlog
 11  /


Execution Plan
----------------------------------------------------------
Plan hash value: 607149231

----------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                         |    15 |  1710 |     5  (20)| 00:00:01 |
|*  1 |  CONNECT BY WITH FILTERING    |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID | LOG                     |     1 |   126 |     3   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN          | PK_IDLOG                |     1 |       |     2   (0)| 00:00:01 |
|   4 |   NESTED LOOPS                |                         |       |       |            |          |
|   5 |    BUFFER SORT                |                         |       |       |            |          |
|   6 |     CONNECT BY PUMP           |                         |       |       |            |          |
|   7 |    TABLE ACCESS BY INDEX ROWID| LOG                     |    15 |  1710 |     4   (0)| 00:00:01 |
|*  8 |     INDEX RANGE SCAN          | IDX_LOG_LOGPARENT       |    10 |       |     3   (0)| 00:00:01 |
|   9 |   TABLE ACCESS FULL           | LOG                     |    19M|  2271M|   116K  (8)| 00:01:57 |
----------------------------------------------------------------------------------------------------

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

   1 - access("IDLOGPARENT"=PRIOR "IDLOG")
   3 - access("IDLOG"=13576296)
   8 - access("IDLOGPARENT"=PRIOR "IDLOG")


Обратите внимание на столбец COST - детали и итоговый результат... Повеселило :)
Воспроизводится на 32-битных версиях 10.2.0.3 и 10.2.0.4 под винду.. Никакими ухищрениями не удается заставить оптимизатор обратиться по индексу IDX_LOG_LOGPARENT к таблице log (вместо фул-скана)
С другой стороны, на 64-битном 10.2.0.4 AIX имеем:



----------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                         |    15 |  1710 |     5  (20)| 00:00:01 |
|*  1 |  CONNECT BY WITH FILTERING    |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID | LOG                     |     1 |   126 |     3   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN          | PK_IDLOG                |     1 |       |     2   (0)| 00:00:01 |
|   4 |   NESTED LOOPS                |                         |       |       |            |          |
|   5 |    CONNECT BY PUMP            |                         |       |       |            |          |
|   6 |    TABLE ACCESS BY INDEX ROWID| LOG                     |    15 |  1710 |     4   (0)| 00:00:01 |
|*  7 |     INDEX RANGE SCAN          | IDX_LOG_LOGPARENT       |     9 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------

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

   1 - access("IDLOGPARENT"=PRIOR "IDLOG")
   3 - access("IDLOG"=13576296)
   7 - access("IDLOGPARENT"=PRIOR "IDLOG")


Под ухищрениями понимались
а)манипуляции статистикой таблицы вплоть до импорта соответствующей с версии на AIX
б)манипуляции системной статистикой
в)прямая простановка хинтов

Параметры таблиц, ессно, одинаковы. Специфические настройки оптимизатора на уровне систем отсутствуют...

Банальная бага оптимизатора? Но если так, то ее стоит отнести чисто к 32-х битной винде и соотвествующим версиям? Не странно ли?
1 авг 11, 16:22    [11054167]     Ответить | Цитировать Сообщить модератору
 Re: Баг? оптимизатора и connect by  [new]
j2k
Member

Откуда: Новосибирск
Сообщений: 550
Allbest,

connect by prior idlog = idlogparent

Местами не пробовали менять?
1 авг 11, 16:29    [11054227]     Ответить | Цитировать Сообщить модератору
 Re: Баг? оптимизатора и connect by  [new]
Allbest
Member

Откуда:
Сообщений: 143
Ни к каким изменениям не приводит..
1 авг 11, 16:35    [11054272]     Ответить | Цитировать Сообщить модератору
 Re: Баг? оптимизатора и connect by  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
Allbest,

приведи список всех индексов (лучше ДДЛ всей таблицы)
1 авг 11, 17:13    [11054554]     Ответить | Цитировать Сообщить модератору
 Re: Баг? оптимизатора и connect by  [new]
YAP
Member

Откуда: Киев
Сообщений: 2116
Bug 5065418, исправлен в 10.2.0.4
1 авг 11, 17:14    [11054562]     Ответить | Цитировать Сообщить модератору
 Re: Баг? оптимизатора и connect by  [new]
Allbest
Member

Откуда:
Сообщений: 143
To YAP...
The performance of some connect by queries degrades more than expected
when the operation uses temp space (spills to disk).

eg:
If a connect by query that uses filtering (the query plan shows filtering
as the option for connect by) runs slower, and there is not enough memory
for the connect operation to complete (it has to spill to disk), you may
be encountering this problem. One way to verify whether it has switched
to the no-filtering mode is to run the query with sql_trace turned on and
then check whether the third child of the connect by row source is
outputting any rows.


Даже если дать дофига PGA и очистить таблицу, то план не меняется. С другой стороны, уточнил данные с 10.2.0.4 под виндой (проверял не сам) - план оказался адекватным (стоял изначально режим copmatibility c 10.2.0.3)....
В общем, похоже на правду...............
1 авг 11, 18:41    [11055162]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить