Oracle mechanics

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]

22.02.2017

Hintset Object

Filed under: Oracle,Oracle 12c,parameters,shared pool — Игорь Усольцев @ 18:52
Tags: ,

The plan_baseline hintset is just the list of hints SPM tried to use to reproduce the plan

В ТОПе Library Cache периодически появлялся непривычный объект:

SQL> select *
  2    from (select hash_value,
  3                 substr(name, 1, 100) as object_name,
  4                 namespace,
  5                 type,
  6                 kept,
  7                 count(*),
  8                 min(timestamp),
  9                 sum(locked_total),
 10                 sum(pinned_total),
 11                 sum(loads),
 12                 sum(executions),
 13                 sum(sharable_mem)
 14            from v$db_object_cache
 15           group by hash_value,
 16                    substr(name, 1, 100),
 17                    namespace,
 18                    type,
 19                    kept
 20           order by sum(sharable_mem) desc)
 21   where rownum <= 3
 22  /
 
HASH_VALUE OBJECT_NAME          NAMESPACE      TYPE           KEPT COUNT(*) MIN(TIMESTAMP)      SUM(LOCKED_TOTAL) SUM(PINNED_TOTAL) SUM(LOADS) SUM(EXECUTIONS) SUM(SHARABLE_MEM)
---------- -------------------- -------------- -------------- ---- -------- ------------------- ----------------- ----------------- ---------- --------------- -----------------
2209848120 6004199150836888961  HINTSET OBJECT HINTSET OBJECT NO          1                                 14872             14872          4               0         625277440
 838046317 select               SQL AREA       CURSOR         NO        459 2016-11-02/10:54:33            442985            288445      79518          180659         155325176
 269081421 select               SQL AREA       CURSOR         NO        627 2016-10-31/00:07:03            273128            218432     143717           91650         154551720
...

необычайно крупного размера SHARABLE_MEM > 600MB с цифровым наименованием, под коим числилось 2 объекта: (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…)

15.11.2015

_high_priority_processes 12c

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

Максим Филатов привлёк внимание к странным изменениям в приоритетах background процессов в Oracle 12c

Например, на 12.1.0.2 OEL x86_64 release 6.4 доморощенным скриптом наблюдаю:

SQL> @param_ _high_priority_processes

 
NAME                      VALUE                                        IS_DEF   IS_MOD     IS_ADJ   DSC
------------------------- -------------------------------------------- -------- ---------- -------- -------------------------------
_high_priority_processes  LMS*|LM*|LCK0|GCR*|DIAG|CKPT|DBRM|RMS0|LGWR  TRUE     FALSE      FALSE    High Priority Process Name Mask

— расширенный в 12c список процессов, которые должны запускаться с высоким приоритетом, однако на хосте вижу, что повышенный приоритет имеют лишь:

$ ps axl|grep '\-2'|grep ora_
0   500 13933     1  -2   - 184900632 19376  hrtime Ss ?      582:49 ora_vktm_INST1
0   500 13966     1  -2   - 185022444 647692 poll_s Ss ?      302:28 ora_lms0_INST1
0   500 13970     1  -2   - 185022444 647544 poll_s Ss ?      298:04 ora_lms1_INST1
0   500 13974     1  -2   - 185022444 647728 poll_s Ss ?      300:44 ora_lms2_INST1

— как это и было в 11g, а вот фактически рекомендованный в параметре LGWR работает со стандартным приоритетом(: (more…)

25.07.2015

12c: как надёжно отключить Automatic Dynamic Statistics на уровне запроса?

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

В предыдущей заметке 12c: Automatic Dynamic Statistics я сослался на документ поддержки Dynamic Sampling Level Is Changed Automatically in 12C (Doc ID 2002108.1), рекомендующий в качестве метода отключения ADS
использовать подсказку на следующем примере:

Disabling Dynamic Statistics

ADS can be disabled but setting optimizer_dynamic_sampling to 0 either with a parameter or using a hint.

Disable for all tables:
select /*+ dynamic_sampling(0) */ …

Пробуя отключить Automatic Dynamic Sampling в одном из тестовых запросов, обратил внимание, что метод с /*+ DYNAMIC_SAMPLING(0) */ нельзя признать надёжным: (more…)

03.06.2013

Параметр _very_large_object_threshold

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

English version

Начиная с Oracle 11.2 на выбор способа чтения блоков индекса между serial direct path read и буферизованным чтением (через db buffer cache SGA) при операции INDEX FAST FULL SCAN (IFFS) влияет параметр:

SQL> @param_ _very_large_object_threshold

NAME                         VALUE IS_DEF   DSC
---------------------------- ----- -------- -----------------------------------------------------
_very_large_object_threshold 500   TRUE     upper threshold level of object size for direct reads

Правильное значение этого параметра: процент от размера буферного кэша (точнее, параметра _db_block_buffers) при превышении которого индекс считается «большим» и в процессе IFFS будет использоваться direct path read, если же размер индекса меньше — IFFS будет выполняться стандартными чтениями блоков через буферный кэш SGA — в точности как показал Саян Малакшинов в своём блоге Example of controlling “direct path reads” decision through SQL profile hints (index_stats/table_stats), где кроме этого параметра описывает хинт INDEX_STATS(“OWNER”.”TABLE_NAME”, “INDEX_NAME”, scale, blocks=X), частовстречаемый / применяемый в SQL Profiles

В процессе тестирования на разных платформах, о котором мы договорились с Саяном, замечено также влияние значения параметра _very_large_object_threshold на управление direct path read с использованием event 10949 при полном сканировании таблиц (more…)

24.11.2012

Особенности расчёта cardinality в материализованных подзапросах при обновлении 11.1 -> 11.2

Filed under: CBO,heuristics,Oracle,parameters,SQL — Игорь Усольцев @ 11:10
Tags: , , , ,

После обновления 11.1.0.7 -> 11.2.0.3 БОЛЬШОЙ ЗАПРОС перешёл к бесконечным временам выполнения, причиной чему стала неточность определения cardinality некого подзапроса, вынесенного в секцию WITH основного запроса, и автоматически материализованного Oracle ввиду неоднократности использования

План проблемного подзапроса, выполняемого отдельно, без необходимости TEMP TABLE TRANSFORMATION показывает не вполне точные, но разумные оценки: (more…)

Таймауты параллельных ожиданий, или почему по умолчанию объекты бд создаются noparallel

Filed under: Oracle,parameters,PX,statistics,wait events — Игорь Усольцев @ 00:43
Tags: , , , ,

Простой недорогой OLTP запрос в непараллельном режиме выполняется предсказуемо быстро:

11.2.0.3.@ SQL> select /*+ noparallel */ *
  2    from view_history
  3   where order_id = 4181494
  4     and start_dt >= sysdate - 20
  5     and sysdate - 20 < end_dt
  6  /

no rows selected

Elapsed: 00:00:00.12

(more…)

21.09.2012

Влияние параметра optimizer_index_cost_adj на оптимизатор версии 11.1

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

Традиционно начинаю с неэффективно работающего запроса:

11.1.0.7.@ SQL> Select
Distinct ("EXP")
  From "SOME_PARTITIONED_TABLE"
 Where "PATH__LVL" < 10
   And ("PATH" In (Chr(9) || 'R' || Chr(9),
                   Chr(9) || 'R' || Chr(9) || 'v11' || Chr(9)))
/

------------------------------------------------------------+-----------------------------------+---------------+
| Id  | Operation              | Name                       | Rows  | Bytes | Cost  | Time      | Pstart| Pstop |
------------------------------------------------------------+-----------------------------------+---------------+
| 0   | SELECT STATEMENT       |                            |       |       |  6723 |           |       |       |
| 1   |  RESULT CACHE          | 9qyjpzzpk6tyu0r3wpj8un8pbd |       |       |       |           |       |       |
| 2   |   HASH UNIQUE          |                            |    21 |  1155 |  6723 |  00:02:35 |       |       |
| 3   |    PARTITION RANGE ALL |                            |    59 |  3245 |  6722 |  00:02:35 | 1     | 5     |
| 4   |     INDEX FULL SCAN    | MULTIFIELDS_INDX           |    59 |  3245 |  6722 |  00:02:35 | 1     | 5     |
------------------------------------------------------------+-----------------------------------+---------------+
Predicate Information:
----------------------
4 - access("PATH__LVL"<10)
4 - filter((INTERNAL_FUNCTION("PATH") AND "PATH__LVL"<10))

Строка RESULT CACHE в плане значения не имеет и определяется установленным в системе параметром:

SQL> show parameter result_cache_mode

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
result_cache_mode                    string      FORCE

Показательно, хотя и не очень важно в этом случае, что тот же запрос с одним условием выполняется по тому же «плохому» плану: (more…)

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

Создайте бесплатный сайт или блог на WordPress.com.