Oracle mechanics

27.11.2013

Сравнение объёмных планов выполнения

Однажды при проведении учебно-боевых стрельб тестов:

— в условиях отсутствия массированных ожиданий ввода-вывода, ничего катастрофического при этом не происходит — сервер бд по-прежнему доступен и управляем, но причина загрузки ЦПУ любопытна, в том смысле, что имеет прямое отношение к типичным проблемам производительности Oracle

С точки зрения бд (AWR) та же картина выглядела следующим, не менее захватывающим образом:

WORKLOAD REPOSITORY report for

DB Name         DB Id    Instance     Inst Num Startup Time    Release     RAC
------------ ----------- ------------ -------- --------------- ----------- ---
OEBS          2598577434 OEBS2               2 05-Oct-13 09:23 11.2.0.3.0  YES

Host Name        Platform                         CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
db2server.oebs.r Linux x86 64-bit                   16     8       2      94.60

              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:     58446 08-Oct-13 16:00:08       501      31.8
  End Snap:     58447 08-Oct-13 17:00:13       527      30.5
   Elapsed:               60.08 (mins)
   DB Time:            5,040.45 (mins)                                           -- на 2 порядка больше Elapsed на 8 честных ядрах!

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           53,883          17.8            -- DB использовала 900 минут из доступных 960 = 60 х 16 CPUs
...

~~~~~~~~         Load Average
               Begin       End     %User   %System      %WIO     %Idle
           --------- --------- --------- --------- --------- ---------
               85.91     89.47      96.2       3.1       0.0       0.0           -- в результате - хороший LA при отсутстви WIO

SQL ordered by CPU Time               DB/Inst: OEBS/OEBS2  Snaps: 58446-58447    -- список виновных и непричастных

    CPU                   CPU per           Elapsed
  Time (s)  Executions    Exec (s) %Total   Time (s)   %CPU    %IO    SQL Id
---------- ------------ ---------- ------ ---------- ------ ------ -------------
  46,964.3            9   5,218.26   87.2  245,583.7   19.1     .1 fppuw3hpvww2d -- основной запрос
Module: XXX_COMISSION_FOR_EXCEL
SELECT * FROM XXX_REPO_COMISSIONERS_V X WHERE X.CONTRACT_ID = :B3 AND X.CURRENCY
_CODE = :B2 AND X.SCHET_VAT_TYPE = :B1 ORDER BY TO_NUMBER(SPCFIC_TYPE_ORDER),X.T
RX_NUMBER

  44,905.9            8   5,613.23   83.3  234,735.5   19.1     .0 grmwmf7p3503s -- top level sql
Module: XXX_COMISSION_FOR_MAIL
BEGIN XXX_COMISSION_REP.comiss_reports_mail(:errbuf,:rc,:A0,:A1,:A2,:A3,:A4,:A5,
:A6,:A7); END;

   2,053.2            0        N/A    3.8   10,814.1   19.0     .3 3h4nurpz9mgv4 -- top level sql
Module: XXX_COMISSION_FOR_EXCEL
BEGIN XXX_COMISSION_REP.create_comiss_reps_batch(:errbuf,:rc,:A0,:A1); END;

     635.3           77       8.25    1.2    3,692.5   17.2    2.6 79fbwuzw18and -- далее неинтересно
...

— главным потребителем ЦПУ является запрос fppuw3hpvww2d, вызываемый из процедур grmwmf7p3503s и 3h4nurpz9mgv4:

SQL> select top_level_sql_id, count(*)
  2    from v$active_session_history
  3   where sql_id = 'fppuw3hpvww2d'
  4   group by top_level_sql_id
  5   order by count(*) desc
  6  /

TOP_LEVEL_SQL_ID   COUNT(*)
---------------- ----------
grmwmf7p3503s         92699
3h4nurpz9mgv4         11191

Как представлен запрос в Library Cache?

SQL> @shared_cu fppuw3hpvww2d

INST    EXECS LAST_ACTIVE_TIME    ELA_PER_EXEC PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  USE_FEEDBACK_STATS OPTIMIZER_STATS  BIND_EQ_FAILURE  REASON1
---- -------- ------------------- ------------ --------------- -------------- ----- ---------- ---------- ---------- ------------------ ---------------- ---------------- --------------------
   1        1 08.10.2013 17:46:00     16452956      2845227671          84363     0 Y          Y          Y          N                  N                Y                Bind mismatch(33)  |
   1      128 08.10.2013 17:54:23    300770995       287300496          89834     2 Y          Y          Y          N                  N                Y                Bind mismatch(33)  |
   2      116 08.10.2013 17:57:25   8898944796      3564323271         147928     5 Y          N          Y          N                  N                N                                    

— тремя экземплярами дочерних курсоров на 2-х нодах, сгенерированными по причине Adaptive/Extended Cursor Sharing (ECS) с разными планами. К несчастью, худший (судя по ELA_PER_EXEC) план выпал на 2-й инстанс, проблемы которого и наблюдаются в AWR

Быстрое решение — подключиться к 1-му экземпляру и зафиксировать лучший из имеющихся планов с хэшем 2845227671, курсор с которым находится в тамошнем Shared Pool-е:

11.2.0.3.OEBS1@ SQL> @create_bsline fppuw3hpvww2d 2845227671 "XXX_COMISSION_FOR_EXCEL"
Baseline SQL_8fc941e591c2e46c SQL_PLAN_8zka1wq8w5t3c171ee7b7 was [re]created
for SQL_ID=fppuw3hpvww2d, SQL_PLAN_HASH=2845227671

PL/SQL procedure successfully completed

после чего ситуация начала поправляться:

SQL> @shared_cu fppuw3hpvww2d

INST    EXECS LAST_ACTIVE_TIME    ELA_PER_EXEC PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  USE_FEEDBACK_STATS OPTIMIZER_STATS  BIND_EQ_FAILURE  REASON1                               SQL_PLAN_BASELINE
---- -------- ------------------- ------------ --------------- -------------- ----- ---------- ---------- ---------- ------------------ ---------------- ---------------- ------------------------------------- ------------------------------
   1        1 08.10.2013 17:46:00     16452956      2845227671          84363     0 Y          Y          Y          N                  N                Y                SQL Tune Base Object Different(3)  |
   1        1 08.10.2013 19:04:15      9198046      2845227671          84363     1 Y          N          N          Y                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   1      128 08.10.2013 17:54:23    300770995       287300496          89834     2 Y          Y          Y          N                  N                Y                SQL Tune Base Object Different(3)  |
   1        3 08.10.2013 19:07:42     13421729      2845227671         134524     3 N          N          Y          N                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2        3 08.10.2013 18:53:45     61386286      2845227671          84363     0 Y          N          N          Y                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2        5 08.10.2013 18:56:24     84832378      2845227671          84363     2 Y          N          N          Y                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2       32 08.10.2013 19:08:12     14746924      2845227671         135229     3 N          N          Y          N                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2      117 08.10.2013 19:08:13  10920026688      3564323271         147928     5 Y          N          Y          N                  N                N                SQL Tune Base Object Different(3)  |                                

пока совсем не исправилась в достаточно странном виде:

SQL> @shared_cu fppuw3hpvww2d

INST    EXECS LAST_ACTIVE_TIME    ELA_PER_EXEC PLAN_HASH_VALUE OPTIMIZER_COST CHILD BIND_SENSE BIND_AWARE SHAREABLE  USE_FEEDBACK_STATS OPTIMIZER_STATS  BIND_EQ_FAILURE  REASON1                               SQL_PLAN_BASELINE
---- -------- ------------------- ------------ --------------- -------------- ----- ---------- ---------- ---------- ------------------ ---------------- ---------------- ------------------------------------- ------------------------------
   1        1 10.10.2013 10:56:38     12313498      2845227671          83497     0 Y          N          N          Y                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   1       99 10.10.2013 13:12:12      6710485      2845227671          86392     1 N          N          Y          N                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2        1 10.10.2013 10:54:48     15788825      2845227671          83497     0 Y          N          N          Y                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7
   2       48 10.10.2013 13:16:20      8376866      2845227671         205605     1 N          N          Y          N                  N                N                Optimizer mismatch(13)  |             SQL_PLAN_8zka1wq8w5t3c171ee7b7

— что заметно по первичной причине повторного неиспользования курсора REASON1 и значению V$SQL_SHARED_CURSOR.USE_FEEDBACK_STATS=Y

Причиной проявления Cardinality Feedback в запросе со связанными переменными (V$SQL.IS_BIND_SENSITIVE=Y) является уже описанное мной ранее использование в запросе параметризованных обзоров с условиями типа:

...
where l.ext_flag = fnd_profile.VALUE ('XXX_PARAM')
...

— что является, к сожалению, распостранённой практикой в ОЁБС программировании

Ок, быстрый workaround в виде Baseline найден и применён, однако опыт показывает, что для сложного запроса с использованием и связанных переменных, и параметризованных обзоров такое решение нельзя считать надёжным, по крайней мере для версии 11.2

Надёжнымм решениями в таких случаях оказываются:

  • Stored Outline — старый, но надёжный метод фиксации плана, с особенностями в части управления
  • SQL Patch — привязывается к тексту запроса, учитывая внешнюю простоту текста запроса, вполне подходит для добавления небольшого кол-ва подсказок
  • фиксация проблемных мест плана выполнения подсказками, видимыми и понятными разработчикам

Учитывая, что два последних удобоваримых варианта требуют точного списка хинтов, а запрос действительно непростой (600+ строк в плане), пробуем по истории ASH (dba_hist_active_sess_history) определить наиболее проблемные блоки выполнения запроса по «плохому» плану 3564323271:

SQL> @ash_sqlmon_hist fppuw3hpvww2d 3564323271 "" 58440

 ID PLAN_OPERATION                                     OBJECT_OWNER OBJECT_NAME                       COST CARDINALITY  BYTES QBLOCK_NAME  WAIT_PROFILE
--- -------------------------------------------------  ------------ ------------------------------- ------ ----------- ------ ------------ -----------------------------------------------------------------------------------------------------------------------------------------
  0   SELECT STATEMENT                                                                              147928                                 ON CPU(6);
...
533                  VIEW                                           VW_SQ_5                            236          66   1782 SEL$A7C6D689 ON CPU(1);
534                    NESTED LOOPS                                                                                           SEL$A7C6D689 ON CPU(3);
535                      NESTED LOOPS                                                                  236          66   2970              ON CPU(1);
536                        TABLE ACCESS FULL           APPS         XXX_COMISSION_PAYNT_HEADER          63          65   1755 SEL$A7C6D689 ON CPU(139534); latch: cache buffers chains(42); latch free(21); buffer busy waits(12); gc cr block 2-way(1); db file sequential read(1);
537                        INDEX RANGE SCAN            APPS         XXX_COMISSION_PAYNT_LINES_N1         2          17        SEL$A7C6D689 ON CPU(35);
538                      TABLE ACCESS BY INDEX ROWID   APPS         XXX_COMISSION_PAYNT_LINES            3           1     18 SEL$A7C6D689 ON CPU(88); gc cr block 2-way(10); db file sequential read(1); latch: row cache objects(1);
...
634         TABLE ACCESS BY INDEX ROWID ... 

— очевиден блок SEL$A7C6D689, на выполнение которого и тратится большая часть времени:

  • ON CPU(139534) — почти 140 тысяч записей осталось в истории ASH
  • latch: cache buffers chains(42); latch free(21); buffer busy waits(12); gc cr block 2-way(1) — заметна лёгкая конкуренция, поскольку запрос выполнялся одновременно многими сессиями

Как отличаются планы выполнения блока SEL$A7C6D689 плохого 3564323271 и хорошего 2845227671 планов?

SQL> @plan_qb_diff_awr fppuw3hpvww2d 3564323271 2845227671 "SEL$A7C6D689"

PLAN_HASH_VALUE QBLOCK_NAME    ID OPERATION                              OBJECT_OWNER OBJECT_NAME                    CARDINALITY      BYTES       COST
--------------- ------------- --- -------------------------------------- ------------ ------------------------------ ----------- ---------- ----------
     3564323271 SEL$A7C6D689  533   VIEW                                              VW_SQ_5                                 66       1782        236
     3564323271 SEL$A7C6D689  534     NESTED LOOPS
     3564323271               535       NESTED LOOPS                                                                          66       2970        236
     3564323271 SEL$A7C6D689  536         TABLE ACCESS FULL              APPS         XXX_COMISSION_PAYNT_HEADER              65       1755         63
     3564323271 SEL$A7C6D689  537         INDEX RANGE SCAN               APPS         XXX_COMISSION_PAYNT_LINES_N1            17                     2
     3564323271 SEL$A7C6D689  538       TABLE ACCESS BY INDEX ROWID      APPS         XXX_COMISSION_PAYNT_LINES                1         18          3

     2845227671 SEL$A7C6D689  608   VIEW                                              VW_SQ_5                                  1         27          5
     2845227671 SEL$A7C6D689  609     SORT UNIQUE                                                                              1         45
     2845227671               610       NESTED LOOPS
     2845227671               611         NESTED LOOPS                                                                         1         45          5
     2845227671 SEL$A7C6D689  612           TABLE ACCESS BY INDEX ROWID  APPS         XXX_COMISSION_PAYNT_LINES                1         18          4
     2845227671 SEL$A7C6D689  613             INDEX RANGE SCAN           APPS         XXX_COMISSION_PAYNT_LINES_N2             1                     3
     2845227671 SEL$A7C6D689  614           INDEX UNIQUE SCAN            APPS         XXX_COMISSION_PAYNT_HEADER_PK1           1                     0
     2845227671 SEL$A7C6D689  615         TABLE ACCESS BY INDEX ROWID    APPS         XXX_COMISSION_PAYNT_HEADER               1         27          1

— выгода хорошего плана хорошо отражена в стоимости блока: 5 против 236 — иногда жалко, что Oracle вынужден пренебрегать расчётами CBO при применении адаптивных технологий!

Для получения списка различающихся подсказок скрипт PLAN_OL_DIFF_AWR.SQL пришлось немного откорректировать, добавив возможность вывода различий для отдельного блока запроса — получилось вполне удобно, как мне кажется:

SQL> --                sql_id        bad plan hash good plan hash qb_name
SQL> @plan_ol_diff_awr fppuw3hpvww2d 3564323271    2845227671     SEL$A7C6D689

PLH_3564323271                                                                                       PLH_2845227671
---------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------
FULL(@"SEL$A7C6D689" "XH"@"SEL$64")
INDEX(@"SEL$A7C6D689" "XL"@"SEL$64" ("XXX_COMISSION_PAYNT_LINES"."XXX_COMISSION_PAYNT_HEADER_ID"))
LEADING(@"SEL$A7C6D689" "XH"@"SEL$64" "XL"@"SEL$64")
NLJ_BATCHING(@"SEL$A7C6D689" "XL"@"SEL$64")
USE_NL(@"SEL$A7C6D689" "XL"@"SEL$64")
                                                                                                     INDEX(@"SEL$A7C6D689" "XH"@"SEL$64" ("XXX_COMISSION_PAYNT_HEADER"."XXX_COMISSION_PAYNT_HEADER_ID"))
                                                                                                     INDEX_RS_ASC(@"SEL$A7C6D689" "XL"@"SEL$64" ("XXX_COMISSION_PAYNT_LINES"."TRX_NUMBER"))
                                                                                                     LEADING(@"SEL$A7C6D689" "XL"@"SEL$64" "XH"@"SEL$64")
                                                                                                     NLJ_BATCHING(@"SEL$A7C6D689" "XH"@"SEL$64")
                                                                                                     USE_HASH_AGGREGATION(@"SEL$A7C6D689")
                                                                                                     USE_NL(@"SEL$A7C6D689" "XH"@"SEL$64")

— список «правильных» подсказок — почти готов в стобце PLH_2845227671, остаётся привести / заменить подсказки INDEX и INDEX_RS_ASC к пользовательскому виду с именами индексов и можно проверять:

SQL> SELECT
  2  /*+       LEADING(@"SEL$A7C6D689" "XL"@"SEL$64" "XH"@"SEL$64")
  3            USE_HASH_AGGREGATION(@"SEL$A7C6D689")
  4            USE_NL(@"SEL$A7C6D689" "XH"@"SEL$64")
  5            NLJ_BATCHING(@"SEL$A7C6D689" "XH"@"SEL$64")
  6            INDEX(@"SEL$A7C6D689" "XH"@"SEL$64" XXX_COMISSION_PAYNT_HEADER_PK1)
  7            INDEX(@"SEL$A7C6D689" "XL"@"SEL$64" XXX_COMISSION_PAYNT_LINES_N2)
  8  */
  9   * from XXX_REPO_comissioners_v x
 10  WHERE x.contract_id = :v1
 11  AND x.currency_code = :v2
 12  AND x.schet_vat_type = :v3
 13  order by to_number(SPCFIC_TYPE_ORDER),x.trx_number
 14  /

Elapsed: 00:03:29.91 -- не лучшее, но по сравнению с 2+ часами выполнения плохого плана - вполне удовлетворительное по SLA время выполнения

SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor('','',format => '+outline'));

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
SQL_ID  cspksrd1kf196, child number 0
-------------------------------------

Plan hash value: 1117760336 -- поскольку фиксировался только план выполнения проблемного блока общий план изменился
...
2133 rows selected.

Теми же скриптами можно посмотреть в каком виде подсказки попали в Outline последнего плана выполнения:

SQL> @plan_ol_diff_awr cspksrd1kf196 1117760336 "" SEL$A7C6D689

PLH_1117760336                                                                                       PLH_
---------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------
INDEX(@"SEL$A7C6D689" "XH"@"SEL$64" ("XXX_COMISSION_PAYNT_HEADER"."XXX_COMISSION_PAYNT_HEADER_ID"))
INDEX_RS_ASC(@"SEL$A7C6D689" "XL"@"SEL$64" ("XXX_COMISSION_PAYNT_LINES"."TRX_NUMBER"))
LEADING(@"SEL$A7C6D689" "XL"@"SEL$64" "XH"@"SEL$64")
NLJ_BATCHING(@"SEL$A7C6D689" "XH"@"SEL$64")
OUTLINE_LEAF(@"SEL$A7C6D689")
USE_HASH_AGGREGATION(@"SEL$A7C6D689")
USE_NL(@"SEL$A7C6D689" "XH"@"SEL$64")                                                                

и как в действительности выполнялся интересующий блок:

SQL> @plan_qb_diff_awr cspksrd1kf196 1117760336 "" SEL$A7C6D689

PLAN_HASH_VALUE QBLOCK_NAME    ID OPERATION                                OBJECT_OWNER OBJECT_NAME                    CARDINALITY      BYTES       COST
--------------- ------------- --- ---------------------------------------- ------------ ------------------------------ ----------- ---------- ----------
     1117760336 SEL$A7C6D689  607   VIEW                                                VW_SQ_5                                  1         27          5
     1117760336 SEL$A7C6D689  608     SORT UNIQUE                                                                                1         45
     1117760336               609       FILTER
     1117760336               610         NESTED LOOPS
     1117760336               611           NESTED LOOPS                                                                         1         45          5
     1117760336 SEL$A7C6D689  612             TABLE ACCESS BY INDEX ROWID  APPS         XXX_COMISSION_PAYNT_LINES                1         18          4
     1117760336 SEL$A7C6D689  613               INDEX RANGE SCAN           APPS         XXX_COMISSION_PAYNT_LINES_N2             1                     3
     1117760336 SEL$A7C6D689  614             INDEX UNIQUE SCAN            APPS         XXX_COMISSION_PAYNT_HEADER_PK1           1                     0
     1117760336 SEL$A7C6D689  615           TABLE ACCESS BY INDEX ROWID    APPS         XXX_COMISSION_PAYNT_HEADER               1         27          1

— результат ожидаем, остаётся пара небольших замечаний

Использованная в тесте подсказка USE_HASH_AGGREGATION, успешно попала в Outline «хороших» планов выполнения, но породила в реальных планах несколько неожиданную операцию SORT UNIQUE, т.е. подсказки секции Outline действующего плана выполнения, вообще говоря, необязательны для безусловного использования

И «боевые» запросы, и последний тест с подсказками успешно выполнялись после предварительной инициализации сессии («наполнения» переменных пакетов, использующихся в parameterized views запроса), если же переменные не инициализировать, план выполнения существенно отличается и операциями (например, тот же хинт USE_HASH_AGGREGATION в плане порождает ожидаемую операцию HASH UNIQUE), и, как следствие, планом, стоимостью и скоростью выполнения:

C:\>sqlplus apps/xxx -- новая сессия без инициализации переменных

11.2.0.3.OEBS1@APPS SQL> explain plan for
  2  SELECT
  3  /*+       LEADING(@"SEL$A7C6D689" "XL"@"SEL$64" "XH"@"SEL$64")
  4            USE_HASH_AGGREGATION(@"SEL$A7C6D689")
  5            USE_NL(@"SEL$A7C6D689" "XH"@"SEL$64")
  6            NLJ_BATCHING(@"SEL$A7C6D689" "XH"@"SEL$64")
  7            INDEX(@"SEL$A7C6D689" "XH"@"SEL$64" XXX_COMISSION_PAYNT_HEADER_PK1)
  8            INDEX(@"SEL$A7C6D689" "XL"@"SEL$64" XXX_COMISSION_PAYNT_LINES_N2)
  9  */
 10   * from XXX_REPO_comissioners_v x
 11  WHERE x.contract_id = :v1
 12  AND x.currency_code = :v2
 13  AND x.schet_vat_type = :v3
 14  order by to_number(SPCFIC_TYPE_ORDER),x.trx_number
 15  /

Explained.

Elapsed: 00:00:07.53                        -- не слишком быстрый разбор ввиду громоздкости запроса

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2897900854

-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                                    | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                             |                                |     1 |  1022 |     0   (0)|          |
|   1 |  SORT AGGREGATE                                              |                                |     1 |    41 |            |          |
...
| 619 |                        VIEW                                  | VW_SQ_5                        |     1 |    27 |   488K  (1)| 01:37:45 |
| 620 |                         HASH UNIQUE                          |                                |     1 |    45 |            |          | -- ожидаемая операция
| 621 |                          NESTED LOOPS                        |                                |       |       |            |          |
| 622 |                           NESTED LOOPS                       |                                |     1 |    45 |   488K  (1)| 01:37:45 |
| 623 |                            TABLE ACCESS BY INDEX ROWID       | XXX_COMISSION_PAYNT_LINES      |   261K|  4601K|   226K  (1)| 00:45:22 |
| 624 |                             INDEX FULL SCAN                  | XXX_COMISSION_PAYNT_LINES_N2   |   261K|       |  1333   (1)| 00:00:16 |
|*625 |                            INDEX UNIQUE SCAN                 | XXX_COMISSION_PAYNT_HEADER_PK1 |     1 |       |     0   (0)| 00:00:01 |
|*626 |                           TABLE ACCESS BY INDEX ROWID        | XXX_COMISSION_PAYNT_HEADER     |     1 |    27 |     1   (0)| 00:00:01 |
...

— просто в качестве иллюстрации дополнительного осложняющего эффекта при использовании параметризованных представлений (parameterized view) в запросах

2 комментария »

  1. Hey mate, .This was an superb post for such a hard topic to speak about. I appear forward to seeing many more excellent posts like this one. Thanks

    комментарий от ruxjacxort@hotmail.co.uk — 04.01.2014 @ 20:44 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: