Oracle mechanics

04.05.2017

ORA-1555 / ORA-3170 on read-only standby DBBP 12.1.0.2.160719

Filed under: Active Data Guard,Oracle,parameters — Игорь Усольцев @ 23:06
Tags: ,

наблюдались в виде:

ORA-01555 caused by SQL statement below (SQL ID: 7hgzff6vkrwkz, Query Duration=11 sec, SCN: 0x0000.00000001)
or
ORA-03170: deadlocked on readable physical standby (undo segment 1413)

— очень похоже на Bug 17323222 ORA-1555 / ORA-3170: deadlocked on readable physical standby (undo segment x) on ADG, т.е. ORA-3170 аналогично указывает на несуществующий SEGMENT_ID, а ORA-1555 возникает на коротком Query Duration

Похоже, лечится изменением параметра:

SQL> ALTER SYSTEM SET "_temp_undo_disable_adg"=TRUE;

— случайно в то же время применённым для исправления ORA-07445 [kteclck()+363]

14.11.2016

Скоро 12.2

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

На прошлой неделе появилась полная версия документации Oracle Database 12c Release 2

, следом Mike Dietrich публикует триптих:

New SPFILE parameters in Oracle Database 12.2.0.1
Obsolete SPFILE Parameters 12.2.0.1
Deprecated Parameters in Oracle Database 12.2.0.1

, и Российский Oracle, по слухам, в конце месяца готовит целенаправленный семинар с более подробным описанием/обсуждением новых опций «Oracle Database 12c Release 2»

— всё идёт к скорому релизу

17.10.2016

12c: Wrong Results, параллельное выполнение и OPTIMIZER_FEATURES_ENABLE

Filed under: Oracle,parameters,PX,Scripts — Игорь Усольцев @ 23:49
Tags: ,

В процессе разбора очередного случая с неправильными рез-том в Oracle 12.1.0.2.*, на этот раз при параллельном выполнении запроса, и предварительно проверив варианты, перечисленные в How to Narrow Down Wrong Results Issues from Parallel Execution (Doc ID 1340246.1), по предложению представителя поддержки, проверил относительно новый функционал — DBMS_SQLDIAG с ключом PROBLEM_TYPE_WRONG_RESULTSHow to use DBMS_SQLDIAG to Assist Diagnosis of Wrong Results Issues (Doc ID 1492650.1):

SQL> declare
declare
  2  l_sql_diag_task_id  varchar2(100);
  3  begin
  4      l_sql_diag_task_id :=  dbms_sqldiag.create_diagnosis_task (
  5        sql_id => '67z9jx22r5sx8',
  6        problem_type => dbms_sqldiag.PROBLEM_TYPE_WRONG_RESULTS,
  7        task_name => 'Test_WR_diagnostic_task' );
  8      dbms_sqltune.set_tuning_task_parameter(
  9        l_sql_diag_task_id,
 10        '_SQLDIAG_FINDING_MODE',
 11        DBMS_SQLDIAG.SQLDIAG_FINDINGS_FILTER_PLANS);
 12  end;
 13  /
/
 
PL/SQL procedure successfully completed

(more…)

06.10.2016

ORA-07445 [kteclck()+363]

Filed under: Active Data Guard,Oracle — Игорь Усольцев @ 23:44
Tags: ,

— дважды встречена на ADG Standby при выполнении запросов с использованием TEMP TABLE TRANSFORMATION после применения обновлений Database Patch Set Update : 12.1.0.2.160419 или Database Bundle Patch: 12.1.0.2.160719 (в виде [kteclck()+586])

Workaround в виде «_with_subquery» = inline* был найден самостоятельно и быстро, а по ре-там SR, заведённого / доведённого Сергеем Щукиным до Severity 1 поддержка завела Bug 23732326 : ORA-07445 [KTECLCK+363] IN ADG ENVIRONMENT и даже сопроводительный документ ORA-07445 [kteclck()+363] In Active Data Guard (ADG) Environment (Doc ID 2177342.1), не предложив, однако, на настоящий момент никакого другого, лучшего решения

Типичный stacktrace:

...
kteclck()+586           signal   __sighandler()
ktelbhw()+809           call     kteclck()
qesldBumpHwm()+197      call     ktelbhw()
qesldCommitHwmLoad()+92 call     qesldBumpHwm()
qesldCommit3tIDL()+210  call     qesldCommitHwmLoad()
qes3tExecSQL()+1110     call     qesldCommit3tIDL()
qerleStart()+220        call     qes3tExecSQL()
...

*) установка «_with_subquery» = inline на уровне системы, кроме ущербности в выборе планов выполнения (Performanz), вызывает:

ORA-32034: unsupported use of WITH clause

на Primary db версии 12.1.0.2.3, например

24.08.2016

12c, адаптивный LGWR: ожидания log file sync и target log write size

Из более-менее традиционной картинки ожиданий log file sync:

12.1.0.2@ SQL> @ash_wait_tree "event = 'log file sync' and inst_id = 1"
 
LVL INST_ID BLOCKING_TREE     WAIT_CLASS  EVENT                         WAITS_COUNT SESS_COUNT AVG_WA
--- ------- ----------------- ----------- ----------------------------- ----------- ---------- ------
  1       1 (FOREGROUND)      Commit      log file sync                       10992       6879    130 -- польз.процессы
  1       1 (J...)            Commit      log file sync                          13         13      0 -- и Job-ы ожидают LGWR
  2       1   (LGWR)          Other       LGWR any worker group                4675          1    190 -- , висящий, восновном,
  2       1   (LGWR)          Other       target log write size                3880          1      4 -- на этих 3-х ожиданиях
  2       1   (LGWR)          Other       LGWR all worker groups                691          1    265 -- и облокируемый
  2       1   (LGWR)                      On CPU / runqueue                      61          1      0
...
  3       1     (LG..)        System I/O  log file parallel write              5064          1    217 -- LGWR-worker-ами (LG..)
  3       1     (LG..)        Other       LGWR worker group ordering            129          1    223
  3       1     (FOREGROUND)              On CPU / runqueue                       2          1      0
  4       1       (LG..)      System I/O  log file parallel write               129          1    347

— можно предположить, что для уменьшения log file sync достаточно сократить время/кол-во блокирующих ожиданий LGWR any worker group/LGWR all worker groups и target log write size, распределённых в этом случае приблизительно поровну

И если первая группа ожиданий очевидно «упирается» в кол-во/скорость работы LGWR-worker-ов, обозначенных как (LG..): (more…)

23.08.2016

12c: Очередной пропущенный ORA-00979: not a GROUP BY expression — Bug 22338374

Filed under: Oracle — Игорь Усольцев @ 23:12
Tags: ,

Евгений Калинин в очередной раз успешно сумел заставить Oracle выдать странное — на этот раз рез-т запроса (аналитических функции, CONNECT BY, SUBQUERY FACTORING, CASE, ANSI JOIN в комбинациях) с ошибкой в перечислении GROUP BY столбцов вместо ORA-00979 выдавал рез-ты, отличные от рез-тов правильного в части GROUP BY запроса, и, более того, зависел от применения или неприменения TEMP TABLE TRANSFORMATION в плане выполнения!

Столь странное поведение, очевидно, выходило за рамки приличий, пришлось/удалось сделать несложный тесткейс и заслать в оркест обратиться в техподдержку с SR-запросом Query with left outer join gives WRONG results instead of ORA-00979: not GROUP BY expression in 12c (more…)

04.04.2016

12c: данные SPM Baseline в SYS.SQLOBJ$PLAN, необходимое уточнение

Filed under: Oracle,Scripts — Игорь Усольцев @ 23:31
Tags: ,

В дополнение к одной из предыдущих заметок оказалось, что в SYS.SQLOBJ$PLAN хранятся данные только «новых» SPM Plan Baseline-ов, созданных в версии 12c

Данные «унаследованных» Baseline-ов версии 11g после обновления так и остаются в табличке SYS.SQLOBJ$DATA

Т.е. если используются Baseline-ы разных версий:

12.1.0.2@ SQL> select plan_name, version from dba_sql_plan_baselines order by 2;
 
PLAN_NAME                       VERSION
------------------------------- ----------
SQL_PLAN_8yh6xn9ncndbf8f932b0a  11.2.0.3.0 -- *
...
SQL_PLAN_3yyva1p88muu4109f0d5f  11.2.0.3.0
SQL_PLAN_593vgbak4tb3409c26202  12.1.0.2.0
...

— то запрос к SYS.SQLOBJ$PLAN для Baseline-а версии 11.2 (*) ничего не даст:

SQL> @spb12 SQL_PLAN_8yh6xn9ncndbf8f932b0a

Дополненный соответствующим UNION ALL SYS.SQLOBJ$DATA скрипт SPB12.SQL правильно отображает содержимое Baseline-ов, созданных в обеих версиях:

SQL> @spb12 SQL_PLAN_8yh6xn9ncndbf8f932b0a
 
OUTLINE_HINTS
-------------------------------------
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
DB_VERSION('11.2.0.3')
...

02.03.2016

12c: данные SPM Baseline в SYS.SQLOBJ$PLAN

Filed under: Oracle,Plan Management — Игорь Усольцев @ 19:26
Tags:

Ежели в версии 11g Oracle хранил данные всех элементов системы SQL Plan Mangement (SPM, включая SQL Patch, SQL Profile и SQL Plan Baseline (SPB)) в SYS.SQLOBJ$DATA.COMP_DATA, то, начиная с 12.1 данные, составляющие собственно Baseline, переместились в clob OTHER_XML новой таблицы SQLOBJ$PLAN, которая также содержит полный план выполнения на момент создания SPM Baseline-а

Этот сохранённый план может быть любопытен в иллюстративных целях, например, при просмотре через Enterprise Manager/Cloud Control, или через соответствующий command line скрипт SPB12.SQL представляет информацию в следующем виде: (more…)

17.02.2016

UPGRADE 12c: краткий список возможных проблем

Filed under: bugs,Oracle,Plan Management — Игорь Усольцев @ 22:37
Tags:

В блогах Oracle мелькнула заметка Mike Dietrich Some Parameter Recommendations for Oracle 12c, обобщающая некоторые проблемы обновления

Появилась и пропала (#гугльпомнит), вероятно, ввиду недостаточного оптимизма)

Однако, кроме описания различных случаев/багов и соответствующих параметров/workaround-ов, заметка содержала практически официальные описания параметров управления SQL Plan Directives (SPD): (more…)

14.01.2016

12c: старая проблема High version count и параметр PARALLEL_INSTANCE_GROUP

Filed under: Диагностика системы (instance),Oracle,shared pool — Игорь Усольцев @ 08:13
Tags:

С коллегой Сергеем Щукиным смотрели на проблему избыточной генерации трейсов типа Huge Trace Files Created Containing «—— Cursor Obsoletion Dump sql_id=%s ——» (Doc ID 1955319.1) — где в соотвествии с рекомендациями, установка параметра _kks_obsolete_dump_threshold = 0 помогла отключить/избавиться от трейсов

Но проблему High version count это не решило:

12.1.0.2@ SQL> select inst_id, sql_id, count(*)
  2    from gv$sql
  3   group by inst_id, sql_id
  4   having count(*) > 1000
  5   order by count(*) desc
  6  /
 
INST_ID SQL_ID          COUNT(*)
------- ------------- ----------
      1 7u1z273sfty8z      93057
      1 5cbp4s5jq04xg       7169
      2 gyvrs5a6pm7h7       1225

Топовые запросы имели схожую статистику курсоров: (more…)

Следующая страница →

Блог на WordPress.com.