Oracle mechanics

22.10.2017

Oracle 12.1.0.2: глобальное параллельное построение индекса при PARALLEL_FORCE_LOCAL=TRUE

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

При установленном параметре:

SQL> @param parallel_force_local
 
NAME                  VALUE  IS_DEF   IS_MOD     DSC
--------------------- ------ -------- ---------- -------------------------------
parallel_force_local  TRUE   FALSE    FALSE      force single instance execution

параллельное построение индекса легко распеределяется между нодами RAC: (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]

30.11.2016

12c: Log File Sync, параметр _DB_MTTR_ADVICE и опасности увеличения кол-ва LGWR-workers

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

После switchover-а на аналогичное железо в разы выросло время ожидания log file sync:

12.1.0.2@ SQL> @ash_wait_tree "event = 'log file sync'" 0 "where inst_id = 1"
 
LVL BLOCKING_TREE         EVENT                         WAIT_CLASS WAITS_COUNT SESS_COUNT AVG_WA  EST_WAITS EST_AVG_LATENCY_MS
--- --------------------- ----------------------------- ---------- ----------- ---------- ------ ---------- ------------------
  1 (FOREGROUND)          log file sync                 Commit           37104       2019    395    1992400                 19 -- ну не 19 мс, конечно, но точно > 10 мс - недопустимо долго
  1 (J...)                log file sync                 Commit              37         35      0          0               1000
  2   (LGWR)              LGWR any worker group         Other            31107          1    518     134101                231 -- осн.блокер для log file sync
  2   (LGWR)              target log write size         Other             4053          1      7    1898397                  2
  2   (LGWR)              LGWR all worker groups        Other             1137          1    187      59184                 19
  2   (LGWR)              On CPU / runqueue                                 54          1      0          0               1000
  2   (LGWR)              enq: CF - contention          Other               19          1    316         60                317
  2   (LGWR)              control file sequential read  System I/O          12          1      1      10607                  1
  2   (LGWR)              control file parallel write   System I/O           7          1      1       6261                  1
  3     (LG..)            LGWR wait for redo copy       Other            25103          1    606      73038                340 -- осн.блокер для LGWR any worker group *
  3     (LG..)            log file parallel write       System I/O        6290          1    209     200335                 31
  3     (LG..)            LGWR worker group ordering    Other              406          1    223       2500                162
  4       (FOREGROUND)    On CPU / runqueue                              21073        354      0          0               1000
  4       (J...)          On CPU / runqueue                               3908         21      0          0               1000
  4       (LG..)          log file parallel write       System I/O         230          1    228       1014                227
  4       (LG..)          LGWR wait for redo copy       Other              176          1    198       1391                127
  4       (Q...)          On CPU / runqueue                                122          1      0          0               1000
  5         (FOREGROUND)  On CPU / runqueue                                176          4      0          0               1000

— при этом в качестве важного промежуточного блокера в вышеприведённой цепочке по частоте и продолжительности неожиданно проявилось LGWR wait for redo copy (*), что было отчётливо заметно в цепочке ожиданий, начиная с LGWR any worker group: (more…)

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, например

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

14.11.2015

Патч 20476175 для версий до 12.1.0.2.5

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

В предыдущей заметке фактически продублировал описание известного Bug 20476175 High VERSION_COUNT (in V$SQLAREA) for query with OPT_PARAM(‘_fix_control’) hint

Баг этот, кроме случая использования подсказок OPT_PARAM(‘_fix_control’) непосредственно в теле запроса, обладает ещё одной неприятной особенностью — он «работает» также в случае применения этих подсказок через SQL Patch (и, подозреваю, через SQL Profile)

Например, если для простого запроса select count(*) from emp (SQL_ID=g59vz2u4cu404) сотворить простой SQL Patch: (more…)

08.11.2015

12c: hardcoded подсказка _fix_control и новая проблема High Version Count

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

Как бы продолжая тему багов/особенностей 12c, появился запрос с заметной долей Shared Pool Concurrency ожиданий в процессе выполнения с ASH мониторингом вида:

SQL> @ash_sqlmon2 45u45mpanbatr
 
LAST_PLSQL SQL_ID        PLAN_HASH_VALUE   ID PLAN_OPERATION                                 PX   ASH_ROWS WAIT_PROFILE
---------- ------------- --------------- ---- ------------------------------------------------- ---------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hard Parse 45u45mpanbatr               0    0 sql_plan_hash_value = 0                       385      48755 cursor: pin S wait on X(47474); library cache lock(653); ON CPU(318); cursor: mutex X(121); cursor: mutex S(120); kksfbc child completion(52); cursor: pin S(8); library cache: mutex X(7);
Soft Parse 45u45mpanbatr      2447725225    0 sql_plan_hash_value > 0; sql_exec_id is null  514      37420 cursor: pin S wait on X(36708); library cache lock(454); cursor: mutex X(88); cursor: mutex S(77); ON CPU(44); kksfbc child completion(32); library cache: mutex X(11); SQL*Net message from dblink(3);
Soft Parse 45u45mpanbatr      2907472699    0 sql_plan_hash_value > 0; sql_exec_id is null  601     113412 cursor: pin S wait on X(107536); ON CPU(3566); library cache lock(1607); cursor: mutex X(286); cursor: mutex S(255); kksfbc child completion(88); PX Deq: Signal ACK EXT(26); library cache: mutex X(24);
...

— на этапах Hard/Soft Parse, доля которых для запроса составляла ~ 2/3 общего времени выполнения: (more…)

07.11.2015

ORA-01841, Table Expansion и Interval Partitioning в версии 12.1.0.2

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

Коллеги-разработчики с радостью сообщили, что наконец-то сломали 12-й Oracle обнаружили проблему, а Александр Шакура подготовил отличный тесткейс:

12.1.0.2@ SQL> create table partit_Tab tablespace users
  2  PARALLEL ( DEGREE 16 INSTANCES 1 ) PARTITION BY RANGE(DT) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
  3  ( PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2005', 'DD-MM-YYYY')))
  4  as
  5  select sysdate dt from dual
  6  union all
  7  select sysdate-300 dt from dual
  8  union all
  9  select sysdate+300 dt from dual
 10  /
 
Table created
 
SQL> select * from partit_Tab ch
  2   where ch.dt < to_date('01-SEP-15','DD-MON-YY')
  3      or ch.dt between to_date('01-SEP-15','DD-MON-YY') and to_date('30-SEP-15','DD-MON-YY')
  4  /
 
DT
-----------
03.01.2015
 
SQL> select * from partit_Tab ch
  2   where ch.dt < date '2015-09-01'
  3      or ch.dt between date '2015-09-01' and date '2015-09-30'
  4  /
 
select * from partit_Tab ch
 where ch.dt < date '2015-09-01'
    or ch.dt between date '2015-09-01' and date '2015-09-30'
 
ORA-01841: (full) year must be between -4713 and +9999, and not be 0

В процессе обследования выяснилось, что: (more…)

13.09.2015

ORA-12850 в многоинстансных запросах

Filed under: Oracle,RAC,shared pool — Игорь Усольцев @ 02:09
Tags:

Выполняя запросы к GV$ обзорам в кластере, нередко можно получить:

11.2.0.3@INST1 SQL> @lock_tree
11.2.0.3@INST1 SQL> @lock_tree
with
*
ERROR at line 1:
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated

— при втором и последующих выполнениях

Разработчики по этому поводу — How To Diagnose ORA-12850 Could Not Allocate Slaves On All Specified Instances(Doc ID 1350377.1):

In case you know the SQL that caused the ORA-12850, experienced DBAs/developers can purge the SQL from the library cache on all nodes and try to execute the SQL again

— отсылают к использованию DBMS_SHARED_POOL.PURGE, что не всегда приносит желаемый эффект, т.е. проблемный курсор из Shared Pool-ов инстансов (а точнее, из его видимой через GV$SQL части) после такой очиски «исчезает», но практически это может не решить проблемы, и ошибка ORA-12850 проявится при очередном выполнении (more…)

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

Блог на WordPress.com.