Oracle mechanics

30.07.2019

Несовместимость и совместное использование SQL Patch и SQL Plan Baseline

Filed under: Oracle,Plan Management,SQL Tuning — Игорь Усольцев @ 23:57
Tags: ,

Тесты с простым тестовым запросом проводились на версии 18c — там трассировка и комментарии Oracle полнее, хотя описываемые особенности известны и наблюдаемы, как минимум, с версии 12.1

Итак, для запроса одновременно созданы два элемента SPMSQL Patch и SQL Plan Baseline:

18.0.0.0.SCOTT@localhost/ORCLCDB SQL> @spm_check4sql_id 2rv6gr3ufpa78

SIGNATURE             SPM_TYPE          SQL_HANDLE                     PATCH_NAME                     ORIGIN         VERSION    CREATED             LAST_MODIFIED       LAST_EXECUTED       ENABLED ACCEPTED FIXED REPROD PURGE ADAPT
--------------------- ----------------- ------------------------------ ------------------------------ -------------- ---------- ------------------- ------------------- ------------------- ------- -------- ----- ------ ----- -----
 17843842952808529353 SQL Patch         SQL_f7a2109ff6027dc9           2rv6gr3ufpa78_hash             MANUAL-SQLTUNE 18.0.0.0.0 26.07.2019 02:25:34 26.07.2019 02:25:34                     YES     NO       NO    YES    NO    NO
 17843842952808529353 SQL Plan Baseline SQL_f7a2109ff6027dc9           SQL_PLAN_gg8hhmzv04zf916ed3edf UNKNOWN        18.0.0.0.0 25.07.2019 04:09:23 25.07.2019 04:09:29 25.07.2019 04:09:29 YES     YES      YES   YES    YES   NO

, Baseline фиксирует индексный доступ:

SQL> @bl12_hints SQL_PLAN_gg8hhmzv04zf916ed3edf

OUTLINE_HINTS
--------------------------------------------------------------------------------
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('18.1.0')
DB_VERSION('18.1.0')
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
FULL(@"SEL$1" "O"@"SEL$1")
INDEX(@"SEL$1" "P"@"SEL$1" ("PRODUCT_INFORMATION"."PRODUCT_ID"))
LEADING(@"SEL$1" "O"@"SEL$1" "P"@"SEL$1")
USE_NL(@"SEL$1" "P"@"SEL$1")
NLJ_BATCHING(@"SEL$1" "P"@"SEL$1")

, в то время как SQL Patch настроен на Hash Join / Full Table Scan:

SQL> @sqlpatch_hints 2rv6gr3ufpa78_hash

SQL_PATCH_HINTS
-------------------------------------------------------------
FULL(@"SEL$1" "P"@"SEL$1") USE_HASH(@"SEL$1" "P"@"SEL$1")

(more…)

01.06.2018

12.2: ORA-979 при разборе запросов с использованием WITH clause, PLSQL function и View Merging

Filed under: 12.2,bugs,Oracle — Игорь Усольцев @ 10:25
Tags: ,

Евгений Калинин обнаружил запрос, факт успешности выполнения которого неожиданно зависел от использования/неиспользования столбцов Inline view(*) а качестве параметров PLSQL_FUNCTION, и худшем случае завершавшийся простой ошибкой:

12.2.0.1.@ SQL> with s_q_by_month as
  2   (select contract_id,
...
 19     group by contract_id,
...
 30  s_q as
 31   (select plsql_function(sum_rub, -- вот этих столбцов *
 32                          max_amt,
...
 36      from (select contract_id,    -- вот этого Inline view
...
 43                   max(amt) as max_amt,
 44                   sum(amt_rub) as sum_rub,
...
 48              from s_q_by_month
 49             group by contract_id,
...
 56  select
 57   * from s_q
 58  /
 * from s_q
          *
ERROR at line 57:
ORA-00979: not a GROUP BY expression

, возникавшей на этапе построения плана, обрывая трассировку где-то в районе Query Transformation — в данном случае трейс заканчивался упоминанием OJE(Outer Join Elimination)

Соответствующая трассировка по номеру ошибки, почерпнутая из Bug 21799456 : ORA-979 ERROR GENERATED FROM A SELECT STATEMENT IN 12C: (more…)

24.03.2013

flashback cursor

Filed under: bugs,heuristics,Oracle,shared pool — Игорь Усольцев @ 23:42
Tags: , ,

При рассмотрении AWR незначительно нагруженной системы была замечена потенциально неприятная вещь:

SQL ordered by Sharable Memory

Sharable Mem (b)   Executions   % Total   SQL Id
   1,107,305,151      435,718      8.59   3ncb946nuqnch
     246,287,584          500      1.91   0y84vjmqf0qc2

— дочерние курсоры первого запроса в сумме превосходят 1GB! (more…)

04.06.2012

Как форсировать разбор SQL при каждом выполнении: новый параметр _disable_cursor_sharing в 11.2.0.3

Filed under: bind variables,CBO,Oracle,parameters,Plan Management,SQL — Игорь Усольцев @ 01:52
Tags: , , , , , ,

Иногда (нечасто) возникает необходимость при каждом выполнении запроса со связанными переменными выполнять разбор этого запроса оптимизатором (hard parse) с целью генерации отдельного плана для каждого набора связанных переменных. Такая необходимость может возникать, например, в случае нечастого выполнения тяжёлых отчётов, для которых Oracle вполне в состоянии подобрать быстрый план, если бы в запросе не использовались связанные переменные и традиционный механизм повторного использования курсоров cursor sharing

Вариантами решения проблемы могли бы быть (Dion Cho: Making SQL always hard parsed): (more…)

Блог на WordPress.com.