Oracle mechanics

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

Реклама

13.11.2016

Oracle 12.1: Library Cache Lock на объекте типа $BUILD$, Adaptive Plan и параллельное выполнение

Filed under: Oracle,Scripts,shared pool,wait events — Игорь Усольцев @ 23:37
Tags: ,

Активизировавшаяся конкуренция за объекты Library Cache в форме ожиданий library cache lock, и в меньшей степени kksfbc child completion, library cache: mutex X:

Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           Total Wait       Wait   % DB Wait    
Event                                Waits Time (sec)    Avg(ms)   time Class   
------------------------------ ----------- ---------- ---------- ------ -----------
DB CPU                                          10.3K              77.6         
library cache lock                 159,109     1554.8       9.77   11.7 Concurrency -- здесь
db file sequential read            297,807      436.2       1.46    3.3 User I/O
cursor: pin S wait on X             26,087      322.5      12.36    2.4 Concurrency
log file sync                      116,938      267.6       2.29    2.0 Commit  
SQL*Net more data from client    1,809,223      131.1       0.07    1.0 Network 
kksfbc child completion              2,213      108.3      48.94     .8 Other       -- , здесь
control file sequential read       290,199       72.9       0.25     .5 System I
direct path write                    6,026       46.3       7.69     .3 User I/O
library cache: mutex X              83,522       45.7       0.55     .3 Concurrency -- и здесь

оказалось вызвана PX-slave процессами (P…) одного параллельно выполнявшимся запроса dx0fckp3gckku в стадии подготовки (IN_PARSE) адаптивного плана (SQL_ADAPTIVE_PLAN_RESOLVED = 1): (more…)

15.04.2016

Рекурсивно-адаптивный SQL_ID «frjd8zfy2jfdq» версии 12.1.0.2

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

Максим Филатов обратил внимание на заметно High Version Count запрос:

SQL ordered by Version Count         DB/Inst: ORCL/ORCL1  Snaps: 101565-101567
-> Only Statements with Version Count greater than 20 are displayed

 Version                           
  Count   Executions     SQL Id    
-------- ------------ -------------
     916          N/A frjd8zfy2jfdq
...

, судя по множеству источников / MODULE-й:

SQL> select decode(session_type, 'BACKGROUND', REGEXP_SUBSTR(program, '\([^\)]+\)'), nvl2(qc_session_id, 'PX', 'USER')) as PROGRAM_TYPE,
  2         count(*),
  3         count(distinct module)
  4    from gv$active_session_history
  5   where sql_id = 'frjd8zfy2jfdq'
  6   group by decode(session_type, 'BACKGROUND', REGEXP_SUBSTR(program, '\([^\)]+\)'), nvl2(qc_session_id, 'PX', 'USER'))
  7  /
 
PROGRAM_TYPE                                       COUNT(*) COUNT(DISTINCTMODULE)
------------------------------------------------ ---------- ---------------------
PX                                                       66                    43

— похожий на рекурсивный, выполняемый, в основном, PX-slave процессами

Как оказалось, запрос этот удостоен отдельной ноты Frequent Execution of SQL_ID «frjd8zfy2jfdq» in 12.1.0.2 (Doc ID 2059121.1): (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…)

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

17.05.2015

12c: конкуренция при компиляции курсоров

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

После обновления бд до версии 12.1.0.2 столкнулись с проблемой блокировок курсоров, сопровождавшей замедлившийся процесс разбора (parse) некоторых запросов, и материально выраженой большим кол-вом/долей ожиданий cursor: pin S wait on X и library cache lock в ASH/AWR:

Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           Total Wait       Wait   % DB Wait    
Event                                Waits Time (sec)    Avg(ms)   time Class   
------------------------------ ----------- ---------- ---------- ------ --------
cursor: pin S wait on X                941      60,9K   64747.53   50.3 Concurrency
DB CPU                                          42,5K              35.1         
library cache lock                  20,478     6681,6     326.28    5.5 Concurrency

Наблюдение в режиме реального времени позволило достаточно быстро и пОлно диагностировать и разрешить проблему, начиная с топа запросов по ожиданиям: (more…)

17.04.2013

Bug 10297948 High Version Count with PX_MISMATCH on Serial Queries in RAC

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

Достаточно интересный для описания баг, с которым столкнулись в версии 11.2.0.2.0 Linux x86_64, практически выражается в периодическом «замирании» кластерных инстансов на ожиданиях, связанных с конкуренцией за shared pool, например, в таком виде:

11.2.0.2@ SQL> select event, count(*)
2    from dba_hist_active_sess_history
3   where snap_id = 135127
4     and session_state = 'WAITING'
5   group by event
6   order by count(*) desc
7  /

EVENT                                COUNT(*)
---------------------------------- ----------
library cache lock                       5311
cursor: pin S wait on X                  3800
db file sequential read                   119

или — в таком: (more…)

24.03.2013

flashback cursor

Filed under: bugs,heuristics,Oracle,shared pool — Игорь Усольцев @ 23:42
Tags: , ,

При рассмотрении AWR незначительно нагруженной системы была замечена потенциально неприятная вещь:

SQL ordered by Sharable Memory

Sharable Mem (b)   Executions   % Total   SQL Id
   1,107,305,151      435,718      8.59   3ncb946nuqnch
     246,287,584          500      1.91   0y84vjmqf0qc2

— дочерние курсоры первого запроса в сумме превосходят 1GB! (more…)

02.03.2013

11.2: ожидание cursor: pin S wait on X при избыточной генерации курсоров параллельного выполнения

В почти идеальном топе ожиданий AWR версии 11.2.0.3 попалось странное :

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           16,642          77.7
direct path read                  7,870,194       3,309      0   15.4 User I/O
log file sync                       154,270         292      2    1.4 Commit
cursor: pin S wait on X                 218         269   1235    1.3 Concurrenc -- ***
direct path read temp               157,474         204      1    1.0 User I/O

— нечастое ожидание cursor: pin S wait on X с огромной длительностью ~ 1.2 сек занимает больше процента DB time

Согласно классическим описаниям Troubleshooting ‘cursor: pin S wait on X’ waits. [ID 1349387.1]«cursor: pin S wait on X» Reference Note основными причинами ожидания являются:

  • частые или длительные hard parse
  • либо множественные копии курсора в shared pool — high version count

(more…)

11.11.2012

ORA-00600: [kglUnKeepHandle] при превышении лимита количества дочерних курсоров

Filed under: hints,Oracle,shared pool — Игорь Усольцев @ 22:19
Tags: , ,

alert.log:

Mon Oct 22 14:00:44 2012
Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_9219.trc  (incident=110752):
ORA-00600: internal error code, arguments: [kglUnKeepHandle], [0x7D39A5EE0], [], [], [], [], [], [], [], [], [], []
Mon Oct 22 14:01:58 2012
Non critical error ORA-48913 caught while writing to trace file "/opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_9219.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [512000000] reached
Writing to the above trace file is disabled for now on...

— попутная ошибка ORA-48913 вызвана ограничением размера трейса:

SQL> @param max_dump_file_size

NAME                VALUE    DSC
------------------- -------- ------------------------------------
max_dump_file_size  1000000  Maximum size (in bytes) of dump file

, в отличие от описания выраженного в блоках ОС = 512 байт (Oracle 11.1.0.7 Linux x86_64) — см. [ID 30762.1]

Трейс /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_9219.trc достаточно быстро указывает на причину ошибки ORA-600 [kglUnKeepHandle]: (more…)

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

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