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

Откуда:
Сообщений: 23
Иногда встречаются запросы, которые большую часть своих чтений делают в вызовах execute, а не в вызовах fetch, как им положено.

Например (вырезано из выходного файла утилиты tkprof):

********************************************************
SELECT T.DATE_STOP, T.NM_FAILURE
FROM EVENT_LOG T 
WHERE T.FID_OBJ = :B1 
       AND T.FID_DIC IN (4010000, 4010010, 4020000) 
       AND T.PARAM_TYPE IN (1, 4) 
       AND T.DATE_STOP = (SELECT MAX(DATE_STOP)
                           FROM EVENT_LOG 
                           WHERE FID_OBJ = :B1 
                                AND 
                                DATE_STOP BETWEEN :B4 AND :B3 AND
                               (IS_OPEN = 1 
                                 OR 
                                DATE_START BETWEEN :B3 AND :B2 ) 
                                AND 
                                 PARAM_TYPE IN (1, 4))


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute     42     80.75    2834.65     836549    1777559          0           0
Fetch       42      0.00       0.19         17         43          0           6
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       84     80.75    2834.84     836566    1777602          0           6

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 43     (recursive depth: 2)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                    824505        0.64       1510.32
  read by other session                     1314542        0.44       1247.91
  latch: cache buffers chains                   444        0.00          0.01
  buffer busy waits                               1        0.00          0.00

**************************************************************

Более того, анализ исходного файла трассировки показывает, что блоки, которые запрашивает процесс в событиях db file sequential read и read by other session, принадлежат сегментам, которые не упоминаются в плане выполнения запроса.

Например, вот часть исходного трассировочного файла:
...
WAIT #32: nam='read by other session' ela= 231 file#=9 block#=156505 class#=1 ob
j#=30383 tim=5678314293
WAIT #32: nam='read by other session' ela= 2 file#=9 block#=156521 class#=1 obj#
=30383 tim=5678314326
WAIT #32: nam='read by other session' ela= 222 file#=9 block#=156521 class#=1 ob
j#=30383 tim=5678314562
...

Можно убедиться, что упомянутые блоки принадлежат индексу EVENT_LOG_PK_NOBJ_TOBJ_DAT

SQL> select owner, segment_name, block_id, blocks from dba_extents
  2  where file_id = 9
  3        and
  4        156505 between block_id and block_id + blocks
  5  /
 
OWNER    SEGMENT_NAME               BLOCK_ID     BLOCKS
-------- -------------------------- ---------- ----------
BNEVENT  EVENT_LOG_PK_NOBJ_TOBJ_DAT 156425       1024

А в плане запроса этот индекс не упоминается:

Plan hash value: 2024362470
---------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                       |     1 |    34 |    21   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID    | EVENT_LOG             |     1 |    34 |     4   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN              | EVENT_LOG_CEH_IND     |     1 |       |     3   (0)| 00:00:01 |
|   3 |    SORT AGGREGATE               |                       |     1 |    28 |            |          |
|*  4 |     FILTER                      |                       |       |       |            |          |
|*  5 |      TABLE ACCESS BY INDEX ROWID| EVENT_LOG             |     1 |    28 |    17   (0)| 00:00:01 |
|*  6 |       INDEX RANGE SCAN          | EVENT_LOG_IS_OPEN_IND |     6 |       |    15   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Разбирался ли кто-нибудь, чем может заниматься вызов execute в таких случаях?
15 янв 09, 13:19    [6690038]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
автор
А в плане запроса этот индекс не упоминается
А план надо тоже из trace-файла брать, глядишь и индекс появится.
15 янв 09, 13:40    [6690284]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Zverg
Member

Откуда:
Сообщений: 23
wurdu
А план надо тоже из trace-файла брать, глядишь и индекс появится.


Согласен. Это может быть. Просто в трейсе не было плана, поэтому воспользовался dbms_xplan. Однако вопрос был более общий. Вот, например, запрос, каких большинство:

SELECT id_obj2 from link_tm
    where id_obj1 = :b3
          and
          id_link_type = 35
          and
          getdateparam(id_obj2, 14001) = :b2
          and
          getdictparam(id_obj2, 14002) = :b1
          and
          rownum <= 1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   2945      1.17       2.13          0          0          0           0
Fetch     2945    174.23     254.42        175     575332          0        2606
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     5891    175.40     256.56        175     575332          0        2606

Как и полагается select'у, чтения здесь выполняются fetch-вызовами. А запрос из заглавного сообщения странен тем, что большинство чтений выполняются вызовами execute. Такие запросы попадаются, но редко. Хотя принципиальных отличий от "нормальных" запросов внешне не заметно.
20 янв 09, 07:59    [6708069]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
for update ?
20 янв 09, 08:12    [6708078]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Elic
Member

Откуда:
Сообщений: 29979
Вячеслав Любомудров
for update ?
Вот нарыл писаный ещё под семёрку код (исполнялся на 9.2.0.8.0 win):
SELECT DECODE(:b1 + :b2 ,1,:b3,2,:b4,3,:b5)   
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   4708      1.40       1.38          0          0          0           0
Fetch     4708      0.21       0.29          1      14124          0        4708
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     9417      1.62       1.68          1      14124          0        4708

Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 30     (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
   4708  TABLE ACCESS FULL DUAL 
...
EXEC #7:c=0,e=214,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=2,tim=4749650970032
FETCH #7:c=0,e=40,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=2,tim=4749650970096
BINDS #7:
 bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=120 offset=0
   bfp=035a03b4 bln=22 avl=01 flg=05
   value=0
 bind 1: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=0 offset=24
   bfp=035a03cc bln=22 avl=01 flg=01
   value=0
 bind 2: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=0 offset=48
   bfp=035a03e4 bln=22 avl=03 flg=01
   value=-1
 bind 3: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=0 offset=72
   bfp=035a03fc bln=22 avl=02 flg=01
   value=1
 bind 4: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=0 offset=96
   bfp=035a0414 bln=22 avl=01 flg=01
   value=0
EXEC #7:c=0,e=214,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=2,tim=4749650970553
FETCH #7:c=0,e=42,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=2,tim=4749650970620
...
Ну чего тут можно execute-ить?
20 янв 09, 10:33    [6708558]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Elic
Вячеслав Любомудров
for update ?
Вот нарыл писаный ещё под семёрку код (исполнялся на 9.2.0.8.0 win)

Что за машина? случаем не однопроцессорный декстоп?
+
alter session set statistics_level = all;
alter session set sql_trace=true;

declare 
    l_res number;
    l_p1 number;
    l_p2 number;
    l_p3 number;
    l_p4 number;
    l_p5 number;
begin
    dbms_random.seed(0);
    for x in 1..5000 loop
        l_p1 := trunc(mod(dbms_random.value*10, 4));
        l_p2 := trunc(mod(dbms_random.value*10, 4));
        l_p3 := dbms_random.value;
        l_p4 := dbms_random.value;
        l_p5 := dbms_random.value;

        select decode(l_p1 + l_p2, 1, l_p3, 2, l_p4, 3, l_p5) into l_res 
        from dual;
    end loop;
end;
/

alter session set sql_trace=false;
--десктоп 10.2.0.4
SELECT DECODE(:B5 + :B4 , 1, :B3 , 2, :B2 , 3, :B1 ) 
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   5000      0.20       0.08          0          0          0           0
Fetch     5000      0.09       0.06          0          0          0        5000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    10001      0.29       0.15          0          0          0        5000

EXEC #2:c=0,e=70,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=434121725381
FETCH #2:c=0,e=62,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=1,tim=434121752319
EXEC #2:c=0,e=69,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=434121780209
FETCH #2:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=1,tim=434121808387
EXEC #2:c=0,e=58,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=434121837446
FETCH #2:c=0,e=35,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=1,tim=434121860142
...
--сервер 9.2.0.8 64bit
SELECT DECODE(:B5 + :B4 , 1, :B3 , 2, :B2 , 3, :B1 )
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   5000      0.06       0.08          0          0          0           0
Fetch     5000      0.06       0.05          0      15000          0        5000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    10001      0.12       0.14          0      15000          0        5000

EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1203553753233713
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=1203553753233713
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1203553753233713
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=1203553753233713
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1203553753233713
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=1203553753233713
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1203553753233713
FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=1203553753233713
...

Я думаю что это случай всяких погрешностей и многократного выполнения, и возможно, в твоем случае еще и клиент (это ведь не PL?).
20 янв 09, 11:22    [6708908]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
KIREAL
Member

Откуда:
Сообщений: 390
Elic
Вячеслав Любомудров
for update ?
Вот нарыл писаный ещё под семёрку код (исполнялся на 9.2.0.8.0 win):
SELECT DECODE(:b1 + :b2 ,1,:b3,2,:b4,3,:b5)   
FROM
 DUAL
...
Ну чего тут можно execute-ить?


Ну чего тут можно добывать? :)
20 янв 09, 11:27    [6708950]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Elic
Member

Откуда:
Сообщений: 29979
Timm
случаем не однопроцессорный декстоп?
Ага :)
Timm
и возможно, в твоем случае еще и клиент (это ведь не PL?).
Нет, чистый серверный PL/SQL с небольшими вкраплениями SQL (в том числе, и вот такими эмуляциями case-а).
20 янв 09, 11:31    [6708981]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Elic
Member

Откуда:
Сообщений: 29979
KIREAL
Elic
Ну чего тут можно execute-ить?
Ну чего тут можно добывать? :)
Твой деревенский юмор понятен лишь тебе.
20 янв 09, 11:34    [6709014]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
Zverg
чем может заниматься вызов execute в таких случаях?

Не уверен, но может например выполнить подзапрос.
20 янв 09, 13:09    [6709776]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
wildwind
Zverg
чем может заниматься вызов execute в таких случаях?

Не уверен, но может например выполнить подзапрос.

Не, не может.
2 автор: можете залить куда-нибудь запакованый сырой трейс?
20 янв 09, 13:28    [6709972]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
KIREAL
Member

Откуда:
Сообщений: 390
Elic,

:) Как скажешь!
20 янв 09, 15:19    [6711014]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Elic
Вячеслав Любомудров
for update ?
Вот нарыл писаный ещё под семёрку код (исполнялся на 9.2.0.8.0 win):
SELECT DECODE(:b1 + :b2 ,1,:b3,2,:b4,3,:b5)   
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   4708      1.40       1.38          0          0          0           0
Fetch     4708      0.21       0.29          1      14124          0        4708
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     9417      1.62       1.68          1      14124          0        4708

Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 30     (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
   4708  TABLE ACCESS FULL DUAL 
...
...
Ну чего тут можно execute-ить?
Ну, насколько я понял, автора интересовало не столько время, сколько чтения
21 янв 09, 03:18    [6713275]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
mosan
Member

Откуда:
Сообщений: 82
Ветка немного стара, но ее решения я не вижу.

У меня тот же вопрос. Вот отрывок из tkprof:
SELECT /*+ INDEX (EVENT1,event_ondate_channel_idx)*/
EVENT1.KIND_CODE ,
EVENT_BLOCK2.BLOCK_TYPE_ID ,
DECODE(BBC_CUST_standby_events_vi3.STANDBY_EXISTS, 3111001, 3111001, 3111000, 3111000, 1, 3111001, 0, 3111000) F0 ,
CASE WHEN (PROMO_TIMING5.PROMO_ID = -1 AND
PROMO_TIMING5.PROMO_TARGET_ID = -1 AND
и т.д. очень длинный SQL без FOR UPDATE

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      8.81       8.84          0        264          0           0
Fetch        2      0.15       2.05        717       4636          0          90
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      8.96      10.90        717       4900          0          90

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

Rows     Row Source Operation
-------  ---------------------------------------------------
     90  NESTED LOOPS OUTER (cr=4636 pr=717 pw=0 time=2055291 us)
     90   NESTED LOOPS OUTER (cr=4616 pr=717 pw=0 time=2053810 us)
     90    NESTED LOOPS OUTER (cr=4616 pr=717 pw=0 time=2052364 us)
     90     NESTED LOOPS OUTER (cr=4401 pr=717 pw=0 time=2049673 us)
     90      NESTED LOOPS OUTER (cr=3940 pr=717 pw=0 time=2047019 us)
     90       NESTED LOOPS  (cr=3757 pr=717 pw=0 time=2044931 us)
     90        NESTED LOOPS  (cr=3307 pr=717 pw=0 time=2041310 us)
и т.д. очень длинный EXPLAIN PLAN

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       4        0.00          0.00
  SQL*Net more data to client                    19        0.00          0.00
  db file sequential read                       265        0.11          3.17
  SQL*Net message from client                     4        0.00          0.02
********************************************************************************


Cоответствующий отрывок из трейса:
EXEC #44:c=8859375,e=8891289,p=4,cr=264,cu=0,mis=1,r=0,dep=0,og=1,tim=1474157983
WAIT #44: nam='SQL*Net message to client' ela= 6 driver id=1413697536 #bytes=1 p3=0 obj#=520661 tim=1474158033
WAIT #44: nam='SQL*Net more data to client' ela= 36 driver id=1413697536 #bytes=2002 p3=0 obj#=520661 tim=1474158100
WAIT #44: nam='db file sequential read' ela= 8641 file#=4 block#=2529635 blocks=1 obj#=523075 tim=1474166907
WAIT #44: nam='db file scattered read' ela= 8805 file#=4 block#=2529636 blocks=5 obj#=523075 tim=1474175844
WAIT #44: nam='db file sequential read' ela= 6839 file#=4 block#=1429499 blocks=1 obj#=519161 tim=1474184617
WAIT #44: nam='db file scattered read' ela= 11144 file#=4 block#=1429500 blocks=5 obj#=519161 tim=1474195821
WAIT #44: nam='db file scattered read' ela= 8223 file#=4 block#=1429506 blocks=7 obj#=519161 tim=1474204914
WAIT #44: nam='db file scattered read' ela= 11122 file#=4 block#=1429514 blocks=7 obj#=519161 tim=1474216344
и т.д. 

Так, что же он делает 8 секунд? Заранее спасибо!
(tkprof прилагается)
30 апр 09, 16:23    [7135297]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
mosan
Member

Откуда:
Сообщений: 82
tkprof не прилагается. Извиняюсь.
30 апр 09, 16:25    [7135306]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
mosan
Misses in library cache during execute: 1
...
Так, что же он делает 8 секунд? Заранее спасибо!
(tkprof прилагается)

Тут наиболее вероятен длительный hard parse, видимо очень много таблиц, судя по
mosan

и т.д. очень длинный EXPLAIN PLAN

Повторный запуск этого же запроса сколько занимает?


Навсякий, по случаю описаному у Elic:

SELECT DECODE(:b1 + :b2 ,1,:b3,2,:b4,3,:b5)   
FROM
 DUAL


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   4708      1.40       1.38          0          0          0           0
Fetch     4708      0.21       0.29          1      14124          0        4708
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     9417      1.62       1.68          1      14124          0        4708

Запрос с кучей BIND вызывающийся многократно, при трассировке 12 уровня,
работы на стадии execute никакой (disk,query,current), но списано много времени на cpu.
Обычно это наводка от трассировки Bind переменных, время на преобразование значений и вывод в файл приписывается стадии execute, натыкались много раз.
30 апр 09, 16:58    [7135507]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
mosan
Member

Откуда:
Сообщений: 82
Спасибо тебе и ежику! Ты прав - очень много таблиц.
Но почему parsing делается в execute, а не в parse?

автор
Повторный запуск этого же запроса сколько занимает?
Выполняется в момент.

Так, что же мне делать?
30 апр 09, 17:54    [7135708]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
mosan
tkprof не прилагается. Извиняюсь.

Закинь на ifolder.
30 апр 09, 18:07    [7135759]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Elic
Member

Откуда:
Сообщений: 29979
mosan
Но почему parsing делается в execute, а не в parse?
Parsing издревле откладывается до как можно позднейшего момента времени, чтобы уменьшить количество round-trip между клиентом и сервером, а также чтобы сделать bind-peeking.
30 апр 09, 18:22    [7135811]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
mosan
Member

Откуда:
Сообщений: 82
Timm
mosan
tkprof не прилагается. Извиняюсь.

Закинь на ifolder.


http://ifolder.ru/11887954
Done.
30 апр 09, 18:23    [7135812]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
mosan
Member

Откуда:
Сообщений: 82
Elic
mosan
Но почему parsing делается в execute, а не в parse?
Parsing издревле откладывается до как можно позднейшего момента времени, чтобы уменьшить количество round-trip между клиентом и сервером, а также чтобы сделать bind-peeking.


Тем не менее обычно это делается на этапе parse. Если я правильно понимаю, это вызванно большим количеством таблиц.
30 апр 09, 18:32    [7135848]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
mosan
Тем не менее обычно это делается на этапе parse. Если я правильно понимаю, это вызванно большим количеством таблиц.

Думаю, это вызвано
Misses in library cache during execute: 1
CPU возможно от латчей.
30 апр 09, 18:46    [7135914]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Можно еще вдобавок к 10046 включить 10053, тогда будет видны действия CBO (правда трейс файл будет намного больше).
Сколько запрос работает при
alter session set "_optim_peek_user_binds"=false;
?
30 апр 09, 18:57    [7135964]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
Elic
mosan
Но почему parsing делается в execute, а не в parse?
Parsing издревле откладывается до как можно позднейшего момента времени, чтобы уменьшить количество round-trip между клиентом и сервером, а также чтобы сделать bind-peeking.

Как мне кажется этим (откладыванием парса) занимается клиент, но не сервер. Строчка Parse в трейсе означает "я ща отпарсил вот эту дрянь". Просто здесь парс прошел также и на стадии Execute, и был дольше. Возможно из-за bind peeking, возможно из-за чего-то другого.
30 апр 09, 19:01    [7135984]     Ответить | Цитировать Сообщить модератору
 Re: Чем занимается select?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
mosan
Тем не менее обычно это делается на этапе parse. Если я правильно понимаю, это вызванно большим количеством таблиц.
Например, это может быть связано с тем, что распарсенный и открытый курсор был инвалидирован А трассировка была запущена после того как курсор был распарсен. Вот пример как этого можно добиться:
create table t as select 1 num from dual;

declare
 p_cursor number;
 p_res  number;
 p_sql varchar2(4000);
begin  
  p_sql := 'select 1 from ' || rpad('t,', 1000, 't,') || 't';
  p_cursor:=dbms_sql.open_cursor;
  dbms_sql.parse(p_cursor, p_sql, dbms_sql.native);
  execute immediate 'COMMENT ON TABLE T IS ''tst'''; --инвалидируем курсор
  execute immediate 'alter session set events = ''10046 trace name context forever, level 8''';
  p_res:=dbms_sql.execute(p_cursor);
  execute immediate 'alter session set events = ''10046 trace name context off''';
end;
Результат tkprof
select 1 
from
 t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,t,
  t,t,t,t,t,t,t


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1     10.46      10.49          0       2004          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        1     10.46      10.49          0       2004          0           0

Misses in library cache during parse: 0
Misses in library cache during execute: 1
1 май 09, 10:34    [7136778]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить