Oracle mechanics

09.03.2018

log file sequential read

Filed under: Active Session History,AWR,Oracle — Игорь Усольцев @ 12:14
Tags:

Всплеск нагрузки на IO подсистему:

сопровождался, по нашим с Дмитрием Якубеней наблюдениям, дисбалансом в отчёте AWR — совершенно незначительные цифры пользовательской нагрузки (*):

Load Profile                    Per Second   Per Transaction  Per Exec  Per Call
~~~~~~~~~~~~~~~            ---------------   --------------- --------- ---------
             DB Time(s):              73.0               0.0      0.01      0.00
              DB CPU(s):              10.5               0.0      0.00      0.00
      Background CPU(s):               0.9               0.0      0.00      0.00
      Redo size (bytes):       6,734,104.6           3,153.3
  Logical read (blocks):       2,698,366.4           1,263.6
          Block changes:          41,001.2              19.2
 Physical read (blocks):          11,301.7               5.3
Physical write (blocks):           3,319.9               1.6
       Read IO requests:           4,417.3               2.1
      Write IO requests:             721.0               0.3
           Read IO (MB):              44.2               0.0                      -- *
          Write IO (MB):              13.0               0.0                      -- *
...

никак не коррелировали с Total (MB) нагрузкой AWR IO Profile (**): (more…)

Реклама

21.05.2014

Ожидание utl_file I/O

Filed under: AWR,Oracle,wait events — Игорь Усольцев @ 21:51
Tags: , ,

При анализе проблем длительного выполнения concurrent request в системе OEBS, зная CLIENT_ID/SID-ы медленно выполнявшихся дочерних процессов и номера начального/конечного снапшотов интересующего периода, достаточно просто выделить «проблемный» запрос из истории ASH:

11.2.0.4@ SQL> @ash_sql_wait_tree_hist "client_id = 'USER007' and (instance_number, session_id, session_serial#) in ((1,2251,19231),(1,1707,26715))" 67983 67991
 
LVL INST_ID BLOCKING_TREE  CLIENT_ID   EVENT                          WAITS_COUNT EXECS_COUNT SESS_COUNT AVG_WA SQL_ID        TOP_LEVEL_SQL_ID SQL_TEXT
--- ------- -------------- ----------- ------------------------------ ----------- ----------- ---------- ------ ------------- ---------------- ------------------------------------------------
  1       1 FOREGROUND     USER007     On CPU / runqueue                      940        1064          2      0 c4wtbv2xcmq78 c4wtbv2xcmq78    begin fnd_file_private.logfile_get(:s, :b); end;
  1       1 FOREGROUND     USER007     On CPU / runqueue                      285           1          2      0                                
  1       1 FOREGROUND     USER007     library cache: mutex X                  30          30          2     10 c4wtbv2xcmq78 c4wtbv2xcmq78    begin fnd_file_private.logfile_get(:s, :b); end;
  1       1 FOREGROUND     USER007     library cache: mutex X                  14           0          2     11                                
...

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

06.10.2013

Скрипты для сравнения планов выполнения

Filed under: AWR,CBO,Oracle,SQL Tuning — Игорь Усольцев @ 23:59
Tags: , , ,

Копия в интернет-журнале «Форс»

Периодически появляется необходимость сравнить / найти различия в планах выполнения запроса, для последующих глубокомысленных умозаключений и выводов

Пакет DBMS_XPLAN, как я понимаю, вплоть до последних версий такую возможность не реализовал (несмотря на сделанную в 11.2 недокументированную заявку в виде DBMS_XPLAN.DIFF_PLAN_AWR — см.легковоспроизводимый на 12.1.0.1 пример на morganslibrary.org)

А поскольку планы (и запросы) встречаются весьма объёмные и сравнивать их на маленьком экране ноутбука не всегда удобно, написал пару скриптов:

  • PLAN_OL_DIFF_AWR.SQL — для выявления отличий в секции Outline (т.е. в наборах подсказок, собственно, и формирующих сравниваемые планы)
  • PLAN_QB_DIFF_AWR.SQL — для удобства просмотра / анализа отличий планов по конкретным блокам (Query Block)

Далее — пример использования (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…)

18.12.2012

Использование временного пространства при параллельном выполнении

Filed under: AWR,commonplace,Oracle,PX,temp segment — Игорь Усольцев @ 00:39
Tags: , ,

Обратил на себя внимание меняющийся объём используемого временного табличного пространства при выполнении ежедневного задания по неатомарному обновлению матвью, по данным периодически заполняемой таблицы TEMP_TEMP_SEG_USAGE:

SQL> select trunc(date_time) AS DATE_TIME,
  2         max(SUM_TEMP_USAGE_MB) as MAX_SUM_TEMP_USAGE_MB
  3    from (select date_time,
  4                 round(sum(blocks) * t.block_size / 1024 / 1024) as SUM_TEMP_USAGE_MB
  5            from SYSTEM.TEMP_TEMP_SEG_USAGE ttu, dba_tablespaces t
  6           where sql_id in ('7q1grk5zza7f0')
  7             and ttu.TABLESPACE = t.tablespace_name
  8             and date_time > sysdate - 8
  9           group by date_time, t.block_size)
 10   group by trunc(date_time)
 11   order by trunc(date_time) desc
 12  /

 

DATE_TIME   MAX_SUM_TEMP_USAGE_MB
----------- ---------------------
13.12.2012                   3279
12.12.2012                  28813 -- ???
11.12.2012                   3095
10.12.2012                   3276
09.12.2012                   3277
08.12.2012                   3276
07.12.2012                   3095
06.12.2012                  26766 -- ???

— ничего необычного, конечно же, в этом нет: статистика выполнения запроса показывает прямую зависимость потребляемого объёма TEMP от количества использованных при выполнении PX процессов: (more…)

12.02.2012

Проблема при создании AWR снапшотов в Oracle 11g

Как известно, начиная с Oracle 11g, для избежания длительного блокирования ресурсов и/или создания избыточной нагрузки на систему как только создание AWR снапшота занимает больше 15 минут процессы M00X (MMON slaves) самоуничтожаются и MMON приостанавливает генерацию снимков AWR на 23 часа, в отличие от 10g, в которой процессы создания снимков выполнялись без ограничений по времени

В этом месте возникает практический вопрос: как восстановить генерацию AWR снапшотов? Например, если после обновления на 11.2 ситуация повторяется изо дня в день и AWR снимки не генерируются?

При возникновении проблемы Oracle пишет след.отладочную информацию (more…)

Блог на WordPress.com.