Трассировка файла оракулом. Как сопоставить имя 'SYS_TEMP_0FD9D6616_3CFB8B' (или идентификатор объекта = -40016362) с конкретным блоком материализации (с as) - PullRequest
Новая
       10

Трассировка файла оракулом. Как сопоставить имя 'SYS_TEMP_0FD9D6616_3CFB8B' (или идентификатор объекта = -40016362) с конкретным блоком материализации (с as)

0 голосов
/ 04 ноября 2019

Я начал изучать оптимизацию запросов Oracle. И у меня есть вопрос по поводу файла трассировки.

Например, в файле трассировки есть план запроса (извините, что без форматирования вам не нужно его читать, просто обратите внимание на SYS_TEMP_0FD9D6611_3CFB8B): 

    TEMP TABLE TRANSFORMATION  (cr=4,525,645 pr=1 pw=1 time=6.1696s)
      LOAD AS SELECT  (cr=2 pr=0 pw=1 time=0.0006s)
        TABLE ACCESS FULL TABLE3 (cr=2 pr=0 pw=0 time=0.0000s cost=2 size=12 card=4)
      SORT AGGREGATE (cr=4,525,643 pr=1 pw=0 time=6.1689s)
        NESTED LOOPS OUTER (cr=4,525,643 pr=1 pw=0 time=6.8775s cost=4,522,314 size=42,943,800 card=2,260,200)
          TABLE ACCESS FULL TABLE1 (cr=5,241 pr=0 pw=0 time=0.6861s cost=1,429 size=13,561,200 card=2,260,200)
          VIEW  (cr=4,520,402 pr=1 pw=0 time=5.2771s cost=2 size=13 card=1)
            TABLE ACCESS FULL SYS_TEMP_0FD9D6616_3CFB8B (cr=4,520,402 pr=1 pw=0 time=4.1430s cost=2 size=12 card=4)

Если в запросе есть материализованный блок, например: 

    with tmp as 
    (select /*+ materialize */ * from table t
    where t.val = 'A')

Затем в файле трассировки в плане запроса появляются следующие строки: 

    STAT #398394272 id=12 cnt=4 pid=11 pos=1 obj=-40016367 op='TABLE ACCESS FULL SYS_TEMP_0FD9D6611_3CFB8B (cr=4 pr=1 pw=0 time=324 us cost=2 size=12 card=4)'

Когда материализованный блок вЗапрос только один, легко понять, что он относится конкретно к вышеуказанному with блоку.

Но когда много блоков with, из файла трассировки неясно, к какому блоку принадлежит object SYS_TEMP_0FD9D6611_3CFB8B.

Я пытался сопоставить по имени object SYS_TEMP_0FD9D6611_3CFB8Bи номер объекта obj=-40016367, но из файла все еще не ясно, что к чему.

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

В запросах, которые яразобраться на работе, есть 10-40 таких материальных блоков. Из-за этого очень легко запутаться в плане запроса.

Или, может, я вообще что-то не так делаю? Моя конечная цель - понять, где висят запросы в процессе ETL. Если я попытаюсь что-то проанализировать неправильно, посоветуйте, как лучше это сделать.

1 Ответ

0 голосов
/ 05 ноября 2019

План выполнения обычно является хорошим индикатором здесь. LOAD AS SELECT покажет вам фазу, на которой создается временная таблица, а затем доступ к временной таблице появится позже в плане. Посмотрев на операции «под» LOAD AS SELECT, можно надеяться, что вы можете связать это обратно с текстом SQL в запросе 

SQL> create table t as select * from dba_Objects;

Table created.

SQL>
SQL> set autotrace traceonly explain
SQL> with
  2  t1 as
  3  ( select /*+ materialize */ owner, count(*) c1
  4    from   t
  5    group by owner ),
  6  t2 as
  7  ( select /*+ materialize */ owner, max(object_id) c2
  8    from   t
  9    group by owner ),
 10  t3 as
 11  ( select /*+ materialize */ t1.owner, c1,c2
 12    from   t1,t2
 13    where t1.owner = t2.owner )
 14  select * from t3;

Execution Plan
----------------------------------------------------------
Plan hash value: 4120770359

-------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                        | Rows  | Bytes |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                             |    37 |  3404 |
|   1 |  TEMP TABLE TRANSFORMATION               |                             |       |       |
|   2 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9DA551_C656D5E3 |       |       |
|   3 |    HASH GROUP BY                         |                             |    37 |   222 |
|   4 |     TABLE ACCESS FULL                    | T                           | 82667 |   484K|
|   5 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9DA552_C656D5E3 |       |       |
|   6 |    HASH GROUP BY                         |                             |    37 |   407 |
|   7 |     TABLE ACCESS FULL                    | T                           | 82667 |   888K|
|   8 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9DA553_C656D5E3 |       |       |
|*  9 |    HASH JOIN                             |                             |    37 |  5846 |
|  10 |     VIEW                                 |                             |    37 |  2923 |
|  11 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9DA551_C656D5E3 |    37 |   222 |
|  12 |     VIEW                                 |                             |    37 |  2923 |
|  13 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9DA552_C656D5E3 |    37 |   407 |
|  14 |   VIEW                                   |                             |    37 |  3404 |
|  15 |    TABLE ACCESS FULL                     | SYS_TEMP_0FD9DA553_C656D5E3 |    37 |  1184 |
-------------------------------------------------------------------------------------------------

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

   9 - access("T1"."OWNER"="T2"."OWNER")
...