Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
ткпруфер
Guest
Люди, кто разбирается в трассировке, подскажите, как интерпретировать файлик трассировки. сортировал сперва по времени выполнения, потом по разбору, и по выборке (sort=exeela,prsela,fchela).

смущают строки:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

что будет являться рекурсивными операторами, а что нет?
24 авг 11, 22:09    [11174245]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
Flok
Member

Откуда:
Сообщений: 258
ткпруфер,

+ Understanding Recursive Calls


Sometimes, to execute a SQL statement issued by a user, Oracle Database must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, then Oracle Database makes recursive calls to allocate the space dynamically. Recursive calls are also generated when data dictionary information is not available in the data dictionary cache and must be retrieved from disk.

If recursive calls occur while the SQL Trace facility is enabled, then TKPROF produces statistics for the recursive SQL statements and marks them clearly as recursive SQL statements in the output file. You can suppress the listing of Oracle Database internal recursive calls (for example, space management) in the output file by setting the SYS command-line parameter to NO. The statistics for a recursive SQL statement are included in the listing for that statement, not in the listing for the SQL statement that caused the recursive call. So, when you are calculating the total resources required to process a SQL statement, consider the statistics for that statement and those for recursive calls caused by that statement.
24 авг 11, 23:07    [11174431]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
юзер вася
Guest
см "recursive depth"
24 авг 11, 23:20    [11174494]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
юзер петя
Guest
юзер вася
см "recursive depth"
а что означает этот "recursive depth"?
я так понимаю он увеличивается когда запрос к словарю данных
порождает в свою очередь новый запрос к словарю данных. так это?
25 авг 11, 06:57    [11175046]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
юзер петя
юзер вася
см "recursive depth"
а что означает этот "recursive depth"?
я так понимаю он увеличивается когда запрос к словарю данных
порождает в свою очередь новый запрос к словарю данных. так это?
Нет.
Миллсап
рекурсивный характеризует исполнение ядром Oracle вызовов
базы данных в контексте других вызовов базы данных.
К примеру, трассируем следующий код:
declare 
  qq number;
begin
  select 1 into qq from dual;
end;
В трассировке будет курсор с dep=0
PARSING IN CURSOR #12 len=59 dep=0 uid=5 oct=47 lid=5 tim=1435913172353 hv=674610314 ad='82d98390'
declare
  qq number;
begin
И рекурсивный с dep=1
PARSING IN CURSOR #13 len=18 dep=1 uid=5 oct=3 lid=5 tim=1435913174455 hv=32127143 ad='728d8120'
SELECT 1 FROM DUAL
END OF STMT
А запросы к словарю - частный случай.
25 авг 11, 07:30    [11175072]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
юзер вася
Guest
юзер петя
юзер вася
см "recursive depth"
а что означает этот "recursive depth"?
я так понимаю он увеличивается когда запрос к словарю данных
порождает в свою очередь новый запрос к словарю данных. так это?

recursive depth в отчете tkprof означает глубину вложенности
25 авг 11, 08:13    [11175139]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
ткпруфер
Guest
Flok
ткпруфер,

+
+ Understanding Recursive Calls


Sometimes, to execute a SQL statement issued by a user, Oracle Database must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, then Oracle Database makes recursive calls to allocate the space dynamically. Recursive calls are also generated when data dictionary information is not available in the data dictionary cache and must be retrieved from disk.

If recursive calls occur while the SQL Trace facility is enabled, then TKPROF produces statistics for the recursive SQL statements and marks them clearly as recursive SQL statements in the output file. You can suppress the listing of Oracle Database internal recursive calls (for example, space management) in the output file by setting the SYS command-line parameter to NO. The statistics for a recursive SQL statement are included in the listing for that statement, not in the listing for the SQL statement that caused the recursive call. So, when you are calculating the total resources required to process a SQL statement, consider the statistics for that statement and those for recursive calls caused by that statement.


правильно ли я понял, что мы можем обойтись без OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS, если установим SYS command-line parameter to NO?
Т.е. в файле трассировки, полученной с помощью утилиты tkprof то, нас ALL RECURSIVE STATEMENTS не интересуют?
Misses in library cache during parse: 1 - это должно вызвать беспокойство, если в своих файлах трассировки (разных), я постоянно встречаю промахи у библиотечном кэше в течение разбора?

помогите разобрать пример пожалуйста:

select name, s_date
from rp_depts
order by 1 asc

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.01          0          0          0           0
Fetch        7      0.00       0.07          0          7          0          88
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9      0.00       0.09          0          7          0          88

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

Rows     Row Source Operation
-------  ---------------------------------------------------
     88  SORT ORDER BY (cr=7 pr=0 pw=0 time=321 us)
     88   TABLE ACCESS FULL RP_DEPTS (cr=7 pr=0 pw=0 time=150 us)


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
  SQL*Net message from client                     7        9.39         39.86

у меня возникли сразу следующие вопросы:

1.) Количество фаз выборки (fetch) равно 7 для выборки 88 строк. Правильно ли я понимаю, что число фаз напрямую зависит от размера блока БД? И в нашем случае потребовалось 7 раз обращаться к SGA, чтобы выбрать эти 88 строк?
Т.к. DISK=0, а QUERY=7, то это говорит о том, что обращение было только к кэшу буфферов и было выбрано 7 блоков из кэша буфферов? т.е. при каждой фазе выборки выбиралось по одному блоку из кэша?

Misses in library cache during parse: 1 - вот тут вопрос, почему всё же промах? нормально ли это?

наблюдался TABLE ACCESS FULL RP_DEPTS, но это нормально, т.к. табличка очень мала (всего 88 строк).
о том, что было взято 7 блоков из кэша говорит значение параметра cr=7?

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS нас не интересует?

и о чём говорит разница между OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS и теми значениями, которые идут сразу после запроса? (select name, s_date
from rp_depts
order by 1 asc)
25 авг 11, 10:34    [11175830]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
Мир труд жвачка
Member

Откуда:
Сообщений: 1527
юзер петя
юзер вася
см "recursive depth"
а что означает этот "recursive depth"?
я так понимаю он увеличивается когда запрос к словарю данных
порождает в свою очередь новый запрос к словарю данных. так это?


Отчасти да.
Некие системные вызовы могут требовать других вложенных. Для тех глубина будет увеличиваться.
Другие могут выполняться на одном уровне вложенности.

query0
- query1
- - query2
- - - query3
- - - query3
- - - query3
- - - query3
- query1
25 авг 11, 10:39    [11175882]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 500
ткпруфер
правильно ли я понял, что мы можем обойтись без OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS, если установим SYS command-line parameter to NO?
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS нас не интересует?


1. Не все рекурсивные запросы системные. См. выше пример wurdu.
2. Системные рекурсивные запросы тоже могут требовать к себе внимания


ткпруфер
Misses in library cache during parse: 1 - вот тут вопрос, почему всё же промах? нормально ли это?

Это значит, что подходящий курсор не был найден в кеше и был построен новый, т.о. это hard parsing.
Не каждый parse call ведет к hard parsing.


ткпруфер
1.) Количество фаз выборки (fetch) равно 7 для выборки 88 строк. Правильно ли я понимаю, что число фаз напрямую зависит от размера блока БД?

Количество fetch calls не зависит от размера блока, а зависит от того сколько таких вызовов захочет сделать приложение (или PLSQL).
Наиболее вероятный и частый вариант, когда приложение повторяет fetch calls пока не прочитает все строки. В этом случае количество таких вызовов зависит от fetch size (измеряется в строках) и количества необходимых для прочтения строк.


ткпруфер
Т.к. DISK=0, а QUERY=7, то это говорит о том, что обращение было только к кэшу буфферов и было выбрано 7 блоков из кэша буфферов?

Да

ткпруфер
т.е. при каждой фазе выборки выбиралось по одному блоку из кэша?

В общем случае зависит от того откуда будут данные читаться - из кеша или из workarea.
В твоем случае из workarea. Было сделано 7 вызовов fetch. Во время первого fetch все необходимые строки были считаны (это потребовало чтения 7 блоков из кеша) и отсортированы, результат хранится в SQL workarea.
Остальные 6 fetch calls читали данные из workarea и не требовали чтений блоков. Это будет видно, если посмотришь cr у вызовов FETCH в трейс файле.


ткпруфер
о том, что было взято 7 блоков из кэша говорит значение параметра cr=7?

Да, это означает, что во время выполнения этого шага плана выполнения было сделано 7 consistant read.
25 авг 11, 12:33    [11177054]     Ответить | Цитировать Сообщить модератору
 Re: Какие операторы являются рекурсивными, а какие нет (чтение трассировки)?  [new]
Flok
Member

Откуда:
Сообщений: 258
ткпруфер
Flok
ткпруфер,

++
+ Understanding Recursive Calls


Sometimes, to execute a SQL statement issued by a user, Oracle Database must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, then Oracle Database makes recursive calls to allocate the space dynamically. Recursive calls are also generated when data dictionary information is not available in the data dictionary cache and must be retrieved from disk.

If recursive calls occur while the SQL Trace facility is enabled, then TKPROF produces statistics for the recursive SQL statements and marks them clearly as recursive SQL statements in the output file. You can suppress the listing of Oracle Database internal recursive calls (for example, space management) in the output file by setting the SYS command-line parameter to NO. The statistics for a recursive SQL statement are included in the listing for that statement, not in the listing for the SQL statement that caused the recursive call. So, when you are calculating the total resources required to process a SQL statement, consider the statistics for that statement and those for recursive calls caused by that statement.


правильно ли я понял, что мы можем обойтись без OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS, если установим SYS command-line parameter to NO?
Т.е. в файле трассировки, полученной с помощью утилиты tkprof то, нас ALL RECURSIVE STATEMENTS не интересуют?


при вызове команды tkprof с параметром SYS=NO в отчет не попадут лишь те рекурсивные вызовы, генерируемые от SYS вследствие необходимости (например, sql-операторы для обновления кэша словаря данных), а рекурсивные вызовы юзера, вызванные переключением контекста, естественно никуда не исчезнут (то есть, к примеру, если у тебя в plsql блоке вызывается sql-оператор, то он будет обозначен как рекурсивный.

Агрегирующие блоки OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS и OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
никуда не исчезнут и информация в них, естественно, будет одинаковой, как при обработке файла трассировки с параметром sys=yes так и с sys=no.

Пример:
Connected to:
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production

SQL> create or replace function C return number is
  2     res_ number;
  3  begin
  4     select 1 into res_ from dual;
  5     return res_;
  6  end C;
  7  /

Function created.

SQL> create or replace function B return number is
  2     res_ number;
  3  begin
  4     select C into res_ from dual;
  5     return res_;
  6  end B;
  7  /

Function created.

SQL> create or replace function A return number is
  2     res_ number;
  3  begin
  4     select B into res_ from dual;
  5     return res_;
  6  end A;
  7  /

Function created.

SQL> exec dbms_session.set_sql_trace(true);

PL/SQL procedure successfully completed.

SQL> select 'from SQLPlus' from dual;

'FROMSQLPLUS'
------------
from SQLPlus

SQL> DECLARE
  2     what_   varchar2(30);
  3     dummy_  number;
  4  BEGIN
  5     dbms_lock.sleep(3);
  6     select 'from Anonymous PLSQL Block' into what_ from dual;
  7     select A into dummy_ from dual;
  8  END;
  9  /

PL/SQL procedure successfully completed.

SQL> drop function A;

Function dropped.

SQL> drop function B;

Function dropped.

SQL> drop function C;

Function dropped.

SQL> exec dbms_session.set_sql_trace(false);

PL/SQL procedure successfully completed.

SQL> 

Кусок из файла трассировки, обработанного с параметром SYS=no
SQL ID: 
Plan Hash: 1483783492
select 'from SQLPlus' 
from
 dual


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        2      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0          0          0           1

Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 40  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=2 us)

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

DECLARE
   what_   varchar2(30);
   dummy_  number;
BEGIN
   dbms_lock.sleep(3);
   select 'from Anonymous PLSQL Block' into what_ from dual;
   select A into dummy_ from dual;
END;

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       2.99          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       2.99          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 40  
********************************************************************************

SQL ID: 
Plan Hash: 1497342653
SELECT 'from Anonymous PLSQL Block' 
FROM
 DUAL


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        1      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          0          0           1

Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 40     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=2 us)

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

SQL ID: 
Plan Hash: 1497365346
SELECT A 
FROM
 DUAL


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        1      0.01       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.01       0.00          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 40     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=3 us)

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

SQL ID: 
Plan Hash: 1497365306
SELECT B 
FROM
 DUAL


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        1      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 40     (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=3 us)

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

SQL ID: 
Plan Hash: 1497365270
SELECT C 
FROM
 DUAL


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        1      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 40     (recursive depth: 3)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=2 us)

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

SQL ID: 
Plan Hash: 1497365227
SELECT 1 
FROM
 DUAL


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        1      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 40     (recursive depth: 4)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=1 us)

А вот отрывок из отчета, обработанного с параметром SYS=yes
SQL ID: 
Plan Hash: 1509829461
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0),2))
from
 objauth$ where obj#=:1 group by grantee#,privilege#,nvl(col#,0) order by 
  grantee#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          3          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          3          0           1

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

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT GROUP BY (cr=21 pr=0 pw=0 time=214 us)
      1   TABLE ACCESS BY INDEX ROWID OBJAUTH$ (cr=21 pr=0 pw=0 time=110 us)
      1    INDEX RANGE SCAN I_OBJAUTH1 (cr=20 pr=0 pw=0 time=82 us)(object id 103)

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

SQL ID: 
Plan Hash: 1509845191
delete from com$ 
where
 obj#=:1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.01          2          2          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.01          2          2          0           0

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  DELETE  COM$ (cr=2 pr=2 pw=0 time=15097 us)
      0   INDEX RANGE SCAN I_COM1 (cr=2 pr=2 pw=0 time=15092 us)(object id 108)

Агрегирующие блоки, как я уже сказал у них одинаковые:

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

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        6      0.00       0.00          0          0          0           0
Execute      7      0.04       3.01          0          0          6           3
Fetch        2      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       15      0.04       3.02          0          0          6           4

Misses in library cache during parse: 4


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse      368      0.09       0.08          0          0          0           0
Execute    565      0.10       0.25         12        275        344         106
Fetch      839      0.06       1.02        133       2017          0         686
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1772      0.26       1.36        145       2292        344         792

Misses in library cache during parse: 77
Misses in library cache during execute: 69

   24  user  SQL statements in session.
  538  internal SQL statements in session.
  562  SQL statements in session.
25 авг 11, 13:36    [11177750]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить