Oracle mechanics

14.07.2017

12c CDB: особенности отображения блокировок, скрипт LOCK_TREE_LOCAL_CDB

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

В PDB snapshot copy окружении версии 12.1.0.2:

SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;

Session altered.

SQL> select con_id, name from v$containers;

CON_ID NAME
------ ---------------
     1 CDB$ROOT
     2 PDB$SEED
     3 PDBCLONE0101
...
    15 PDBCLONE0113
...

18 rows selected.

Артём Горбик показал странно отображаемую сессию-блокер:

SQL> select service_name,con_id,program from gv$session where sid=4921;

SERVICE_NAME CON_ID PROGRAM
------------ ------ ----------------------
SYS$USERS         1 oracle@hostname (J017)

— формально работающую в CDB$ROOT:

SQL> select name, con_id from v$containers where con_id=1;

NAME                     CON_ID
-------------------- ----------
CDB$ROOT                      1

, и в то же время выполняющую Scheduler Job в контейнере-клоне:

SQL> select SESSION_ID,JOB_NAME,con_id from cdb_scheduler_running_jobs where session_id = 4921;

SESSION_ID JOB_NAME               CON_ID
---------- ------------------ ----------
      4921 update_mviews              15

SQL> select name, con_id from v$containers where con_id=15;

NAME                     CON_ID
-------------------- ----------
PDBCLONE0113                 15

Модифицировал под это дело скрипт (с суффиксом _CDB), добавив к инстансу/сессии (INST#/SID#4) номер контейнера — CON#: (more…)

13.07.2017

ORA-00600 [kteoprpect-2]

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

на physical standby / ADG instance в виде:

Thu Jun 29 19:01:00 2017
Errors in file /opt/oracle/base/diag/rdbms/orcl/orcl1/trace/orcl1_mrp0_16186.trc:
ORA-10562: Error occurred while applying redo to data block (file# 4, block# 1371409)
ORA-10564: tablespace UNDOTBS
ORA-01110: data file 4: '+DGDATA/orcl/datafile/undotbs.259.885215567'
ORA-10560: block type 'EXTENT MAP BLOCK OF SYSTEM MANAGED UNDO SEGMENT'
ORA-00600: internal error code, arguments: [kteoprpect-2], [1498751285], [1498751284], [], [], [], [], [], [], [], [], []
Thu Jun 29 19:01:00 2017
MRP0: Background Media Recovery process shutdown (orcl1)

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

12.1.0.2.SYS@ SQL> ALTER SYSTEM SET "_smu_debug_mode"=2049;

System altered.

и, соответственно, лечится (по рекомендации техподдержки): (more…)

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…)

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

Блог на WordPress.com.