Oracle mechanics

19.05.2012

DML при ошибочной оценке cardinality удалённых обзоров

Filed under: CBO,heuristics,hints,Oracle,parameters,remote — Игорь Усольцев @ 00:15
Tags: , , ,

Ошибка при транзакционном обновлении материализованного представления (atomic mview refresh):

ORA-01555 caused by SQL statement below (SQL ID: aq07w6jd7yv7b, Query Duration=10956 sec, SCN: 0x004e.042dcb2b):
INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "LOCAL_OWNER"."MV_LOCAL_MATVIEW" SELECT * FROM V_COMPLICATED_LOCAL_VIEW

На неспортивных методах типа увеличения undo tablespace останавливаться смысла нет — запрос работает неприемлемо долго

Формально план по которому выполняется запрос выглядит недорогим и быстрым:

------------------------------------------------------------------------------------------------
| Id  | Operation                              | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |IN-OUT|
------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                       |  39382 |  3961K|    54  (17)| 00:00:01 |      |
|   1 |  LOAD TABLE CONVENTIONAL               |        |       |            |          |      |
|   2 |   HASH JOIN RIGHT OUTER                |  39382 |  3961K|    54  (17)| 00:00:01 |      |
|   3 |    VIEW                                |      1 |    26 |    13  (31)| 00:00:01 |      |
|   4 |     HASH JOIN OUTER                    |      1 |    39 |    13  (31)| 00:00:01 |      |
|   5 |      VIEW                              |      1 |    13 |     4  (25)| 00:00:01 |      |
|   6 |       SORT UNIQUE                      |      1 |    35 |     4  (25)| 00:00:01 |      |
|   7 |        REMOTE                          |      1 |    35 |     3   (0)| 00:00:01 | R->S |--< здесь и далее E-Rows=1 для REMOTE
|   8 |      VIEW                              |      1 |    26 |     8  (25)| 00:00:01 |      |
|   9 |       SORT GROUP BY                    |      1 |    70 |     8  (25)| 00:00:01 |      |
|  10 |        NESTED LOOPS                    |        |       |            |          |      |
|  11 |         NESTED LOOPS                   |      1 |    70 |     7  (15)| 00:00:01 |      |
|  12 |          MERGE JOIN CARTESIAN          |      1 |    57 |     6  (17)| 00:00:01 |      |
|  13 |           REMOTE                       |      1 |    22 |     2   (0)| 00:00:01 | R->S |
...

одинаково неточно оценивая cardinality удалённых обзоров:

Remote SQL Information (identified by operation id):
----------------------------------------------------

7 - SELECT "..." FROM "REMOTE_OWNER"."V_REMOTE_VIEW" WHERE ... (accessing 'REMOTE.DBLINK.RU' ) -- реально возвращает 298 строк

13 - SELECT "..." FROM "REMOTE_OWNER"."V_REMOTE_VIEW2" (accessing 'REMOTE.DBLINK.RU' )         -- реально возвращает 39873 строк

...

— давно известная и, судя по статусу бага, достаточно принципиальная и до сих пор не решённая проблема — Bug 9128233: INCORRECT CARDINALITY OF REMOTE VIEW:

  Status - Closed, not feasible to fix
...
  DETAILED PROBLEM DESCRIPTION
  ============================
  When a remote view is joined to a local table the estimated cardinality seems not correct which can result in inferior execution plan
...
  WORKAROUND INFORMATION
  ======================
   use a cardinality hint 
   /*+ gather_plan_statistics CARDINALITY(REMOTE_VIEW 600)*/ 

   this is not very acceptable hint...

— как следствие, в плане выполнения появляются «недорогие» операции MERGE JOIN CARTESIAN и NESTED LOOPS с участием удалённых обзоров , которые могут выполняются до появления ORA-1555

Лирическое отступление: простой кейс на 11.2.0.3 показывает, что оценка кол-ва строк (cardinality, E-Rows) становится неточной (не обязательно 1 — алгоритм не совсем понятен) при локальном выполнении любого запроса, использующего удалённый обзор, состоящий из более чем одной таблицы:

11.2.0.3.@SQL> create table t as select * from dual connect by rownum <= 10000;

Table created.

11.2.0.3.@SQL> exec dbms_stats.gather_table_stats('','T');

PL/SQL procedure successfully completed.

11.2.0.3.@SQL> create or replace view tv as select t.dummy as d1, d.dummy as d2 from t, dual d;

View created.

11.2.0.3.@SQL> select * from tv@loopback tv;

10000 rows selected.

-----------------------------------------------
| Id  | Operation              | Name | Rows  |
-----------------------------------------------
|   0 | SELECT STATEMENT REMOTE|      | 10000 | -- удалённое выполнение, оценка правильная
|   1 |  NESTED LOOPS          |      | 10000 |
|   2 |   TABLE ACCESS FULL    | DUAL |     1 |
|   3 |   TABLE ACCESS FULL    | T    | 10000 |
-----------------------------------------------

Note
-----
- fully remote statement

11.2.0.3.@SQL> select * from tv@loopback tv, dual;

10000 rows selected.

---------------------------------------------
| Id  | Operation            | Name | Rows  |
---------------------------------------------
|   0 | SELECT STATEMENT     |      |     1 |
|   1 |  MERGE JOIN CARTESIAN|      |     1 |
|   2 |   REMOTE             | TV   |     1 | -- локальное выполнение, оценка НЕправильная
|   3 |   BUFFER SORT        |      |     1 |
|   4 |    TABLE ACCESS FULL | DUAL |     1 |
---------------------------------------------

11.2.0.3.@SQL> select/*+ driving_site(tv)*/ * from tv@loopback tv, dual;

10000 rows selected.

-----------------------------------------------
| Id  | Operation              | Name | Rows  |
-----------------------------------------------
|   0 | SELECT STATEMENT REMOTE|      | 10000 |
|   1 |  MERGE JOIN CARTESIAN  |      | 10000 |
|   2 |   MERGE JOIN CARTESIAN |      |     1 |
|   3 |    REMOTE              | DUAL |     1 |
|   4 |    BUFFER SORT         |      |     1 |
|   5 |     TABLE ACCESS FULL  | DUAL |     1 |
|   6 |   BUFFER SORT          |      | 10000 |
|   7 |    TABLE ACCESS FULL   | T    | 10000 | -- удалённое выполнение, оценка правильная
-----------------------------------------------

Note
-----
- fully remote statement

Возвращаясь к нашим баранам начальной проблеме — естественным и рекомендуемым Oracle решением был бы перенос запроса на удалённый сайт:

11.1.0.7.@SQL> SELECT/*+ driving_site(@"SEL$ECBAE663" "V_REMOTE_VIEW")*/
...

39399 rows selected.

Elapsed: 00:00:11.23

--------------------------------------------------------------------------------------------------
| Id  | Operation                                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT REMOTE                  | 39395 |  6116K|       | 15493   (2)| 00:02:24 |

— при этом план отражает более-менее адекватную стоимость, замечательно быстро выполняется, но не совсем подходит для обновления mview, т.к. Oracle пока умеет выполнять DML только одним курсором и только на стороне расположения объекта DML

Точнее, есть вариант перенести весь обзор V_COMPLICATED_LOCAL_VIEW, на котором строится MVIEW, целиком на удалённый сайт — при этом курсор при обновлении MVIEW останется локальным со ссылкой на удалённый обзор (с CARDINALITY=1 но это не имеет значения), а результаты запроса к этому обзору в свою очередь, будут формироваться удалённо и правильно — в соответствии с настройками оптимизатора и статистикой объектов на дальней стороне db link

Однако в рассматриваемом случае перенос всего обзора на удалённый сайт не является универсальным решением, т.к. рассматриваемый обзор V_COMPLICATED_LOCAL_VIEW является смешанным  (т.е. используюет и локальные, и удалённые таблицы и обзоры) и описанный перенос обзора на удалённый сайт порождает проблемы с неправильной оценкой CARDINALITY уже локальных таблиц

Поскольку при локальном выполнении запросов с удалёнными вьюшками неправильная оценка CARDINALITY (и неоптимальный план выполнения) является типичным поведением, приходится использовать вспомогательные техники, типа хинтов и/или переформулирования текста запроса

Например, для рассматриваемого локального DML можно стандартными параметрами запретить использование MERGE JOIN CARTESIAN и осложнить использование NESTED LOOPS:

11.1.0.7.@SQL> explain plan for
2  INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "LOCAL_OWNER"."MV_LOCAL_MATVIEW"
3  SELECT
4  /*+ opt_param('_optimizer_mjc_enabled' 'false')
5      opt_param('optimizer_index_cost_adj', 10000)
6      opt_param('optimizer_index_caching' 0)
7  */
8  * FROM
...

------------------------------------------------------------------------------------------
| Id  | Operation                        | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |IN-OUT|
------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                 |  39382 |  3961K|   182   (8)| 00:00:03 |      |
|   1 |  LOAD TABLE CONVENTIONAL         |        |       |            |       |         |
|   2 |   HASH JOIN RIGHT OUTER          |  39382 |  3961K|   182   (8)| 00:00:03 |      |
|   3 |    VIEW                          |      1 |    26 |    57   (9)| 00:00:01 |      |
|   4 |     HASH JOIN OUTER              |      1 |    39 |    57   (9)| 00:00:01 |      |
|   5 |      VIEW                        |      1 |    13 |     4  (25)| 00:00:01 |      |
|   6 |       SORT UNIQUE                |      1 |    35 |     4  (25)| 00:00:01 |      |
|   7 |        REMOTE                    |      1 |    35 |     3   (0)| 00:00:01 | R->S |
|   8 |      VIEW                        |      1 |    26 |    52   (6)| 00:00:01 |      |
|   9 |       SORT GROUP BY              |      1 |    70 |    52   (6)| 00:00:01 |      |
|  10 |        HASH JOIN                 |      1 |    70 |    51   (4)| 00:00:01 |      |
|  11 |         NESTED LOOPS             |      1 |    57 |     6  (17)| 00:00:01 |      | <-- NESTED LOOPS between REMOTE!!!
|  12 |          REMOTE                  |      1 |    22 |     2   (0)| 00:00:01 | R->S |
|  13 |          VIEW                    |      1 |    35 |     4  (25)| 00:00:01 |      |
|  14 |           WINDOW SORT PUSHED RANK|      1 |    35 |     4  (25)| 00:00:01 |      |
|  15 |            REMOTE                |      1 |    35 |     3   (0)| 00:00:01 | R->S |
|  16 |         MAT_VIEW ACCESS FULL     |   3512 | 45656 |    45   (3)| 00:00:01 |      |
|  17 |    HASH JOIN RIGHT OUTER         |  39382 |  2961K|   124   (6)| 00:00:02 |      |
|  18 |     VIEW                         |      1 |    26 |    48   (5)| 00:00:01 |      |
|  19 |      SORT GROUP BY               |      1 |     5 |    48   (5)| 00:00:01 |      |
|  20 |       VIEW                       |      1 |     5 |    48   (5)| 00:00:01 |      |
|  21 |        SORT UNIQUE               |      1 |   126 |    48   (5)| 00:00:01 |      |
|  22 |         HASH JOIN                |      1 |   126 |    47   (3)| 00:00:01 |      |
|  23 |          REMOTE                  |      1 |    22 |     2   (0)| 00:00:01 | R->S |
|  24 |          MAT_VIEW ACCESS FULL    |   3512 |   356K|    45   (3)| 00:00:01 |      |
|  25 |     HASH JOIN RIGHT OUTER        |  39382 |  1961K|    75   (6)| 00:00:01 |      |
|  26 |      VIEW                        |      1 |    26 |    48   (5)| 00:00:01 |      |
|  27 |       SORT GROUP BY              |      1 |    35 |    48   (5)| 00:00:01 |      |
|  28 |        HASH JOIN                 |      1 |    35 |    47   (3)| 00:00:01 |      |
|  29 |         REMOTE                   |      1 |    22 |     2   (0)| 00:00:01 | R->S |
|  30 |         MAT_VIEW ACCESS FULL     |   3512 | 45656 |    45   (3)| 00:00:01 |      |
|  31 |      TABLE ACCESS FULL           |  39382 |   961K|    26   (4)| 00:00:01 |      |
------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
...
12 - SEL$ECBAE663 / V_REMOTE_VIEW@SEL$24
...
15 - SEL$5EC70623 / V_REMOTE_VIEW2@SEL$21

— формируется почти удовлетворительный план, отрабатывающий за ~ 1000 секунд, что уже в 10 раз лучше первоначального, однако остаётся неразумный NESTED LOOPS между 2-мя удалёнными таблицами

Аналогичный план можно получить при стандартных для этой системы значениях параметров optimizer_index_caching / optimizer_index_cost_adj (очевидно, способствующих NESTED LOOPS), форсируя использование HASH JOIN с помощью event 10093:

$ oerr ora 10093
10093, 00000, "CBO Enable force hash joins"

11.1.0.7.@SQL> @param optimizer_index

NAME                                       VALUE                                    IS_DEF   IS_MOD  DSC
------------------------------------------ ---------------------------------------- -------- ---------- ---------------------------------
optimizer_index_caching                    95                                       FALSE    FALSE   optimizer percent index caching
optimizer_index_cost_adj                   10                                       FALSE    FALSE   optimizer index cost adjustment

11.1.0.7.@SQL> alter session set events '10093 trace name context forever , level 1';

Session altered.

11.1.0.7.@SQL> explain plan for
2  INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "LOCAL_OWNER"."MV_LOCAL_MATVIEW"
3  SELECT
4  /*+ opt_param('_optimizer_mjc_enabled' 'false') */
5  * FROM
...

Устранить остающийся медленный NESTED LOOPS можно, например, явно указывая cardinality удалённых таблиц подсказками:

11.1.0.7.@SQL> explain plan for
2  INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "LOCAL_OWNER"."MV_LOCAL_MATVIEW"
3  SELECT
4  /*+ opt_param('_optimizer_mjc_enabled' 'false')
5      opt_param('optimizer_index_cost_adj', 10000)
6      opt_param('optimizer_index_caching' 0)
7      cardinality(@"SEL$5EC70623" "V_REMOTE_VIEW" 300)
8      cardinality(@"SEL$ECBAE663" "V_REMOTE_VIEW2" 40000)
9  */
10  * FROM
11  (
...

------------------------------------------------------------------------------------------
| Id  | Operation                        | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |IN-OUT|
------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                 |  39382 |  3961K|   182   (8)| 00:00:03 |      |
|   1 |  LOAD TABLE CONVENTIONAL         |        |       |            |       |         |
|   2 |   HASH JOIN RIGHT OUTER          |  39382 |  3961K|   182   (8)| 00:00:03 |      |
|   3 |    VIEW                          |      1 |    26 |    58  (11)| 00:00:01 |      |
|   4 |     HASH JOIN OUTER              |      1 |    39 |    58  (11)| 00:00:01 |      |
|   5 |      VIEW                        |      1 |    13 |     4  (25)| 00:00:01 |      |
|   6 |       SORT UNIQUE                |      1 |    35 |     4  (25)| 00:00:01 |      |
|   7 |        REMOTE                    |      1 |    35 |     3   (0)| 00:00:01 | R->S |
|   8 |      VIEW                        |      1 |    26 |    53   (8)| 00:00:01 |      |
|   9 |       SORT GROUP BY              |      1 |    70 |    53   (8)| 00:00:01 |      |
|  10 |        HASH JOIN                 |     13 |   910 |    52   (6)| 00:00:01 |      |--быстрые соединения с удалёнными таблицами
|  11 |         HASH JOIN                |     19 |   912 |    49   (5)| 00:00:01 |      |
|  12 |          VIEW                    |    300 | 10500 |     4  (25)| 00:00:01 |      |
|  13 |           WINDOW SORT PUSHED RANK|    300 | 10500 |     4  (25)| 00:00:01 |      |
|  14 |            REMOTE                |    300 | 10500 |     3   (0)| 00:00:01 | R->S |--правильная оценка через подсказку
|  15 |          MAT_VIEW ACCESS FULL    |   3508 | 45604 |    45   (3)| 00:00:01 |      |
|  16 |         REMOTE                   |  40000 |   859K|     2   (0)| 00:00:01 | R->S |--правильная оценка через подсказку
...

— при совпадающей стоимости (что достаточно забавно) получающийся запрос отрабатывает быстро, но сложные названия блоков в подсказках придётся менять при всяком изменении подлежащих запросов и обзоров. По этой же причине для фиксации плана этого запроса не рассматривается baseline‘ы и прочий SPM

Кроме того хинт /*+ CARDINALITY*/ не поддерживается Oracle и может вести себя непредсказуемо после неминуемых обновлений

При возможности изменить SQL текст головного обзора V_COMPLICATED_LOCAL_VIEW исключить медленный NESTED LOOPS можно переформулировав запрос — например, локально материализуя подзапросы из удалённых обзоров:

11.1.0.7.@SQL> create or replace view V_COMPLICATED_LOCAL_VIEW
2  as
3  with os as
4  (select--+ materialize
5   ...
6     from LOCAL_VIEW_FOR_REMOTE,..
...
22  SELECT/*+ opt_param('_optimizer_mjc_enabled' 'false')
23            opt_param('optimizer_index_cost_adj', 10000)
24            opt_param('optimizer_index_caching' 0)       */
...
View created.

11.1.0.7.@SQL> explain plan for
2  INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "LOCAL_OWNER"."MV_LOCAL_MATVIEW" SELECT * FROM V_COMPLICATED_LOCAL_VIEW;

---------------------------------------------------------------------------------------------
| Id  | Operation                           | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |IN-OUT|
---------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                    |  39382 |  5961K|   184   (8)| 00:00:03 |      |
|   1 |  LOAD TABLE CONVENTIONAL            |        |       |            |          |      |
|   2 |   VIEW                              |  39382 |  5961K|   184   (8)| 00:00:03 |      |
|   3 |    TEMP TABLE TRANSFORMATION        |        |       |            |          |      |
|   4 |     LOAD AS SELECT                  |        |       |            |          |      |
|   5 |      VIEW                           |      1 |    26 |    58  (11)| 00:00:01 |      |
|   6 |       HASH JOIN OUTER               |      1 |    31 |    58  (11)| 00:00:01 |      |
|   7 |        VIEW                         |      1 |    13 |     4  (25)| 00:00:01 |      |
|   8 |         SORT UNIQUE                 |      1 |    35 |     4  (25)| 00:00:01 |      |
|   9 |          VIEW                       |      1 |    35 |     3   (0)| 00:00:01 |      |
|  10 |           REMOTE                    |      1 |    35 |     3   (0)| 00:00:01 | R->S |
|  11 |        VIEW                         |      1 |    18 |    53   (8)| 00:00:01 |      |
|  12 |         SORT GROUP BY               |      1 |    36 |    53   (8)| 00:00:01 |      |
|  13 |          VIEW                       |      1 |    36 |    52   (6)| 00:00:01 |      |
|  14 |           HASH JOIN                 |      1 |    35 |    52   (6)| 00:00:01 |      |
|  15 |            VIEW                     |      1 |    13 |    47   (3)| 00:00:01 |      |
|  16 |             VIEW                    |      1 |    40 |    47   (3)| 00:00:01 |      |
|  17 |              HASH JOIN              |      1 |    35 |    47   (3)| 00:00:01 |      |--***
|  18 |               VIEW                  |      1 |    22 |     2   (0)| 00:00:01 |      |--***
|  19 |                REMOTE               |      1 |    22 |     2   (0)| 00:00:01 | R->S |--***
|  20 |               MAT_VIEW ACCESS FULL  |   3508 | 45604 |    45   (3)| 00:00:01 |      |--***
|  21 |            VIEW                     |      1 |    22 |     4  (25)| 00:00:01 |      |
|  22 |             VIEW                    |      1 |    35 |     4  (25)| 00:00:01 |      |
|  23 |              WINDOW SORT PUSHED RANK|      1 |    35 |     4  (25)| 00:00:01 |      |
|  24 |               VIEW                  |      1 |    35 |     3   (0)| 00:00:01 |      |
|  25 |                REMOTE               |      1 |    35 |     3   (0)| 00:00:01 | R->S |
|  26 |     HASH JOIN RIGHT OUTER           |  39382 |  3961K|   127   (7)| 00:00:02 |      |
|  27 |      VIEW                           |      1 |    26 |     2   (0)| 00:00:01 |      |
|  28 |       TABLE ACCESS FULL             |      1 |    26 |     2   (0)| 00:00:01 |      |
|  29 |      HASH JOIN RIGHT OUTER          |  39382 |  2961K|   124   (6)| 00:00:02 |      |
|  30 |       VIEW                          |      1 |    26 |    48   (5)| 00:00:01 |      |
|  31 |        SORT GROUP BY                |      1 |     5 |    48   (5)| 00:00:01 |      |
|  32 |         VIEW                        |      1 |     5 |    48   (5)| 00:00:01 |      |
|  33 |          SORT UNIQUE                |      1 |   126 |    48   (5)| 00:00:01 |      |
|  34 |           HASH JOIN                 |      1 |   126 |    47   (3)| 00:00:01 |      |
|  35 |            REMOTE                   |      1 |    22 |     2   (0)| 00:00:01 | R->S |
|  36 |            MAT_VIEW ACCESS FULL     |   3508 |   356K|    45   (3)| 00:00:01 |      |
|  37 |       HASH JOIN RIGHT OUTER         |  39382 |  1961K|    75   (6)| 00:00:01 |      |
|  38 |        VIEW                         |      1 |    26 |    48   (5)| 00:00:01 |      |
|  39 |         SORT GROUP BY               |      1 |    35 |    48   (5)| 00:00:01 |      |
|  40 |          HASH JOIN                  |      1 |    35 |    47   (3)| 00:00:01 |      |
|  41 |           REMOTE                    |      1 |    22 |     2   (0)| 00:00:01 | R->S |
|  42 |           MAT_VIEW ACCESS FULL      |   3508 | 45604 |    45   (3)| 00:00:01 |      |
|  43 |        TABLE ACCESS FULL            |  39382 |   961K|    26   (4)| 00:00:01 |      |
---------------------------------------------------------------------------------------------

— в такой редакции запрос выполняется без медленных операций — только быстрые (для этого случая) HASH JOIN‘ы с удалёнными таблицами/обзорами при незначительным увеличением стоимости (184 vs 182), что выглядит достаточно естественно из-за накладных расходов при TEMP TABLE TRANSFORMATION

Важно, что предпочтение HASH JOIN при использовании метода материализации удалённых запросов не является Cost Based, что отражено в трейсе оптимизатора:

***********************
Table Stats::
Table: V_REMOTE_VIEW  Alias: V_REMOTE_VIEW  (NOT ANALYZED)
#Rows: 0  #Blks:  0  AvgRowLen:  0.00                                                              -- статистика удалённого обзора
Access path analysis for V_REMOTE_VIEW
***************************************
...
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: V_LOCAL_VIEW_FOR_REMOTE  Alias: TD  (NOT ANALYZED)
#Rows: 0  #Blks:  0  AvgRowLen:  0.00                                                              -- статистика локального синонима удалённого обзора
***********************
...
***************************************
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]:  V_LOCAL_VIEW_FOR_REMOTE[TD]#0  MV_LOCAL_MVIEW[P]#1

***************
Now joining: MV_LOCAL_MVIEW[P]#1
***************
NL Join
Outer table: Card: 1.00  Cost: 5.00  Resp: 0.00  Degree: 0  Bytes: 22
Access path analysis for MV_PARTNER_PROBLEM
Inner table: MV_LOCAL_MVIEW  Alias: P
Access Path: TableScan
NL Join:  Cost: 58.21  Resp: 58.21  Degree: 1                                                     -- стоимость Nested Loops
...
HA Join
HA cost: 58.71                                                                                    -- стоимость Hash Join > Nested Loops
resc: 58.71 resc_io: 57.00 resc_cpu: 32906495
resp: 58.71 resp_io: 57.00 resp_cpu: 32906495
Best:: JoinMethod: Hash                                                                           -- Oracle выбирает более дорогой Hash Join
Cost: 58.71  Degree: 1  Resp: 58.71  Card: 0.06 Bytes: 35

— похоже, что в случае использования subquery factoring / TEMP TABLE TRANSFORMATION отдаётся предпочтение операциям FULL SCAN / HASH JOIN

В результате Job по обновлению mview теперь выполняется так:

11.1.0.7.@SQL> exec dbms_job.run(863);

PL/SQL procedure successfully completed

Executed in 2,406 seconds

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

Комментариев нет.

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 такие блоггеры, как: