Oracle mechanics

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.