Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 план запроса  [new]
asdfasd
Guest
Подскажите пожалуйста
неожидано обнаружил для себя странную вещь
запрос select * from clients where clientcode>0 and 1=0
SELECT STATEMENT
FILTER 1=0
TABLE ACCESS FULL CLIENTCODE>0 здесь есть и большиая стоимость и кардинальность
Трассировка
PARSING IN CURSOR #2 len=49 dep=0 uid=180 oct=3 lid=180 tim=331962121132 hv=129542913 ad='906b3fb0'
select * from clients where clientcode>0 and 1=0
END OF STMT
PARSE #2:c=0,e=98,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=331962121127
BINDS #2:
EXEC #2:c=0,e=56,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=331962121239
WAIT #2: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=37 tim=331962121290
WAIT #2: nam='SQL*Net more data to client' ela= 49 driver id=1413697536 #bytes=2001 p3=0 obj#=37 tim=331962121386
WAIT #2: nam='SQL*Net message from client' ela= 5175 driver id=1413697536 #bytes=1 p3=0 obj#=37 tim=331962126620
FETCH #2:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=331962126692
WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=37 tim=331962126745
*** 2013-08-02 12:10:29.338
WAIT #2: nam='SQL*Net message from client' ela= 36963206 driver id=1413697536 #bytes=1 p3=0 obj#=37 tim=331999089982
STAT #2 id=1 cnt=0 pid=0 pos=1 obj=0 op='FILTER (cr=0 pr=0 pw=0 time=9 us)'
STAT #2 id=2 cnt=0 pid=1 pos=1 obj=436656 op='TABLE ACCESS FULL CLIENTS (cr=0 pr=0 pw=0 time=0 us)'

Насколько я вижу в трассировке нет обращения к таблице cr=0 pr=0 и это верно НО почему тогда строится такой план по идее он должен быть вообще без таблицы Я рассчитывал что Oracle увидит что обращение к ней никогда не понадобится и отразит это в плане. И как тогда из плана (без трассировки) я должен понимать что запрос все таки исполнится быстро без обращения к таблице.
Oracle 10g
2 авг 13, 12:17    [14652826]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
A.
Guest
asdfasd
Я рассчитывал что Oracle увидит что обращение к ней никогда не понадобится и отразит это в плане. И как тогда из плана (без трассировки) я должен понимать что запрос все таки исполнится быстро без обращения к таблице.
Oracle 10g


так и есть
SELECT STATEMENT	
FILTER 1=0 
TABLE ACCESS FULL	 CLIENTCODE>0
2 авг 13, 12:21    [14652855]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
qwerqw
Guest
A.
asdfasd
Я рассчитывал что Oracle увидит что обращение к ней никогда не понадобится и отразит это в плане. И как тогда из плана (без трассировки) я должен понимать что запрос все таки исполнится быстро без обращения к таблице.
Oracle 10g


так и есть
SELECT STATEMENT	
FILTER 1=0 
TABLE ACCESS FULL	 CLIENTCODE>0


Не понял что есть? Из этого плана получается что сначала он должен обратится к таблице а потом результаты отфильтровать?
Или я что то нетак понимаю?
5 авг 13, 11:22    [14662704]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
--Eugene--
Member

Откуда: Боярышник
Сообщений: 2170
qwerqw,

насколько я понимаю, "FILTER 1=0" означает, что "TABLE ACCESS FULL" не будет исполнено ниразу
(могу ошибаться)
5 авг 13, 11:51    [14662907]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
DВА
Member

Откуда:
Сообщений: 5439
Тот FILTER который в самом плане запроса - тот глобальный, рулит на уровне таблиц, а вот тот который предикатах - тот уже на уровне строк.
5 авг 13, 11:55    [14662932]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
Sacramento
Member [заблокирован]

Откуда: from Paris with love
Сообщений: 525
Оч наглядно будет сравнение трасс для
1)select count(*) from clients, clients
2)select count(*) from clients, clients where 1=0

по
'db file sequential read'
'db file scattered read'
5 авг 13, 12:31    [14663224]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
A.
Guest
qwerqw
A.
пропущено...


так и есть
SELECT STATEMENT	
FILTER 1=0 
TABLE ACCESS FULL	 CLIENTCODE>0


Не понял что есть? Из этого плана получается что сначала он должен обратится к таблице а потом результаты отфильтровать?
Или я что то нетак понимаю?

Сначала выполнится rowsource FILTER 1=0 и ниже эта ветка выполняться уже не будет.
5 авг 13, 12:32    [14663234]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
qweqwer
Guest
A.
qwerqw
пропущено...


Не понял что есть? Из этого плана получается что сначала он должен обратится к таблице а потом результаты отфильтровать?
Или я что то нетак понимаю?

Сначала выполнится rowsource FILTER 1=0 и ниже эта ветка выполняться уже не будет.

Я бытоже хотел так читать этот план Но в таком случае планк огда идет индексный доступ (сверху таблица внизу индекс)
тоже следовало понимать как сначала таблица потом индекс (чего быть не может)
Вопрос скорее по форме в трасе я вижу что к таблице обращений нет НО почему так показывается план
5 авг 13, 12:36    [14663266]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
--Eugene--
Member

Откуда: Боярышник
Сообщений: 2170
A.,

а не подскажете the fucking manual, где описаны типы шагов пути доступа к данным?
обыскался - не нашел
5 авг 13, 12:38    [14663281]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
--Eugene--
Member

Откуда: Боярышник
Сообщений: 2170
qweqwer
...НО почему...
- это поведение описано где-то в the fucking manual-е. когда-то видел, а щас найти не могу... :(
5 авг 13, 12:41    [14663302]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 500
qweqwer
A.
пропущено...

Сначала выполнится rowsource FILTER 1=0 и ниже эта ветка выполняться уже не будет.

Я бытоже хотел так читать этот план Но в таком случае планк огда идет индексный доступ (сверху таблица внизу индекс)
тоже следовало понимать как сначала таблица потом индекс (чего быть не может)
Вопрос скорее по форме в трасе я вижу что к таблице обращений нет НО почему так показывается план

План запроса выполняется сверху вниз. Однако для выполнения текущего row source как правило (но не всегда) нужны данные данные из дочернего row source, поэтому данные читаются обычно снизу вверх. Row sources это в итоге функции кода Oracle. Сначала выполнится fetch (select statement), вызовет filter, filter уже не вызовет full scan.

Ниже план запроса для твоего случая, смотри столбец Starts
> alter session set statistics_level=all;

Session altered.

> select count(*) from big where 1=0;

  COUNT(*)
----------
         0

> select * from table(dbms_xplan.display_cursor(null, null, 'allstats last'));

----------------------------------------------------------------------------
| Id  | Operation           | Name | Starts | E-Rows | A-Rows |   A-Time   |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |      1 |        |      1 |00:00:00.01 |
|   1 |  SORT AGGREGATE     |      |      1 |      1 |      1 |00:00:00.01 |
|*  2 |   FILTER            |      |      1 |        |      0 |00:00:00.01 |
|   3 |    TABLE ACCESS FULL| BIG  |      0 |    962K|      0 |00:00:00.01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(NULL IS NOT NULL)
5 авг 13, 12:52    [14663365]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
asdffывап
Guest
Alexander Anokhin
qweqwer
пропущено...

Я бытоже хотел так читать этот план Но в таком случае планк огда идет индексный доступ (сверху таблица внизу индекс)
тоже следовало понимать как сначала таблица потом индекс (чего быть не может)
Вопрос скорее по форме в трасе я вижу что к таблице обращений нет НО почему так показывается план

План запроса выполняется сверху вниз. Однако для выполнения текущего row source как правило (но не всегда) нужны данные данные из дочернего row source, поэтому данные читаются обычно снизу вверх. Row sources это в итоге функции кода Oracle. Сначала выполнится fetch (select statement), вызовет filter, filter уже не вызовет full scan.

Ниже план запроса для твоего случая, смотри столбец Starts
> alter session set statistics_level=all;

Session altered.

> select count(*) from big where 1=0;

  COUNT(*)
----------
         0

> select * from table(dbms_xplan.display_cursor(null, null, 'allstats last'));

----------------------------------------------------------------------------
| Id  | Operation           | Name | Starts | E-Rows | A-Rows |   A-Time   |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |      1 |        |      1 |00:00:00.01 |
|   1 |  SORT AGGREGATE     |      |      1 |      1 |      1 |00:00:00.01 |
|*  2 |   FILTER            |      |      1 |        |      0 |00:00:00.01 |
|   3 |    TABLE ACCESS FULL| BIG  |      0 |    962K|      0 |00:00:00.01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(NULL IS NOT NULL)


Спасибо! стало яснее!
5 авг 13, 14:18    [14664056]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
Sacramento
Member [заблокирован]

Откуда: from Paris with love
Сообщений: 525
Хмм... Надо же. Я всегда думал что утром одеваясь нужно сначала обуть шпильки, потом напялить юбку, застегнуть блузку, натащить трусы, и только затем уже ити чистить зубы.
А оно оказываецо все наоборот нужно делать. Гмм...

К сообщению приложен файл. Размер - 4Kb
5 авг 13, 15:15    [14664538]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
DВА
Member

Откуда:
Сообщений: 5439
Sacramento
Хмм... Надо же. Я всегда думал что утром одеваясь нужно сначала обуть шпильки, потом напялить юбку, застегнуть блузку, натащить трусы, и только затем уже ити чистить зубы.
А оно оказываецо все наоборот нужно делать. Гмм...

если на вас шпильки и юбка, то уже не важно, когда вы чистите зубы
5 авг 13, 15:18    [14664568]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
Хохлов
Member

Откуда:
Сообщений: 1169
--Eugene--
A.,

а не подскажете the fucking manual, где описаны типы шагов пути доступа к данным?
обыскался - не нашел

Christian Antognini: Troubleshooting Oracle Performance -> Chapter 6 - Execution Plans
5 авг 13, 17:42    [14665560]     Ответить | Цитировать Сообщить модератору
 Почему???  [new]
Великий Почемуха
Guest
Ну почему???
SQL> select * from (
  2    select q1.* from sys.obj$ q1, sys.obj$, sys.obj$, sys.obj$, sys.obj$, sys.obj$, sys.obj$
  3  ) where 1 = 0
  4  /

no rows selected

Elapsed: 00:00:00.15
SQL> select * from (
  2    select count(*) from sys.obj$, ( select * from  sys.obj$ where rownum < 1000)
  3  ) where 1 = 0
  4  /

no rows selected

Elapsed: 00:00:09.96
11 авг 13, 19:18    [14693769]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 10039
Великий Почемуха
Ну почему???


У каждого yin'a (in-nine view materialization в даном случае) должен быть свой yang .

SY.
11 авг 13, 19:41    [14693804]     Ответить | Цитировать Сообщить модератору
 Re: план запроса  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1780
--Eugene--
A.,

а не подскажете the fucking manual, где описаны типы шагов пути доступа к данным?
обыскался - не нашел
Не поверите: Oracle® Database Performance Tuning Guide
11g Release 2 (11.2), E16638-07
11 авг 13, 19:48    [14693820]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить