Oracle mechanics

23.02.2018

Наблюдаемые особенности компиляции Matview курсоров на примере 12c Out-of-Place (OOP) Refresh

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

В процессе тестирования с Максимом Филатовым Patch 20933264: OUT-OF-PLACE COMPLETE REFRESH NOT USING DIRECT LOAD IN POPULATING OUTSIDE TABLE наблюдали следующее воспроизводимое поведение:

12.1.0.2@ SQL> CREATE MATERIALIZED VIEW scott.EMP_SNAPSHOT2 tablespace users REFRESH complete ON DEMAND as SELECT * FROM "SCOTT"."EMP" join "SCOTT"."DEPT" using(deptno)
  2  /

Materialized view created.

SQL> alter session set events '10979 trace name context forever';

Session altered.

SQL> alter session set events '10046 trace name context forever , level 12';

Session altered.

SQL> exec dbms_mview.refresh('"SCOTT"."EMP_SNAPSHOT2"', method => '?', atomic_refresh => false, out_of_place => TRUE)

PL/SQL procedure successfully completed.

После чего SYS.SNAP_REFOP$ содержит три операции: (more…)

Реклама

15.01.2018

12c: Простейшее использование INMEMORY при обновлении Materialized View

Filed under: Oracle,Oracle new features — Игорь Усольцев @ 21:14
Tags: ,

Предварительно усилив параллельность выполнения — как несложный и действенный метод ускорения FULL SCAN-ов, HASH JOIN-ов, сокращения direct path temp read / write- операций и потребления TEMP пространства, соответственно:

12.1.0.2@ SQL> alter session force parallel QUERY parallel 32;

Session altered

, получаем:

SQL> exec dbms_mview.refresh('"BI"."MV_EXPENSES_DETAIL"', atomic_refresh => TRUE, parallelism => 32) -- parallelism => 32 - особой роли не играет, скорее как индикатор
 
PL/SQL procedure successfully completed
 
Executed in 140,578 seconds

— стартовый рез-т, SQL MONITOR которого показывает много direct path read на MAT_VIEW ACCESS FULL (*) + всё ещё заметное, несмотря на параллельное выполнение, потребление TEMP (11G) с сопутствующими direct path temp — операциями при выполнении вышележащего HASH JOIN (**): (more…)

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

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

Блог на WordPress.com.