AWR snapshots (снимки) очень полезны, но Oracle по умолчанию делает их каждые 60 минут. Если вы заинтересованы в анализе проблем с производительностью, которая случилась 10 минут назад, то снимки AWR ничем не помогут. Однако все-таки способ получить эту информацию имеется. Oracle Database собирает статистику Active Session History (состоящую в основном из статистики ожидания для различных событий) для всех активных сеансов каждую секунду, и сохраняет ее в циклическом буфере в SGA. Таким образом, ASH записывает самую свежую активность сеанса (за последние пять или десять минут).
Процесс MMNL (в Oracle его называют manageability monitor light — облегченный монитор управляемости, хотя этот процесс отображается как “manageability monitor process 2”, когда запрашивается представление V$BGPROCESS) выполняет легковесные задачи управляемости, включая метрики и захват хронологической информации сеансов для средства ASH при некоторых обстоятельствах. Например, MMNL сбросит данные ASH на диск, если буфер памяти ASH заполнится до истечения часового интервала, что обычно заставляет MMON выталкивать его.
Анализ ASH предоставляет эффективные данные по производительности, поскольку сосредоточен только на активных сеансах. Анализ текущих активных сеансов выполняется с использованием представления V$ACTIVE_SESSION_HISTORY, а анализ хронологии более старых сеансов — с помощью представления DBA_HIST_ACTIVE_SESSION_HISTORY.
На заметку! Дополнительная статистика в Oracle Database не оказывает заметного влияния на производительность, поскольку поступает в основном прямо из SGA через фоновые процессы. Средство ASH использует около 2 Мбайт памяти в SGA на каждый процессор.
Данные текущего активного сеанса
Как должно быть известно, представление V$SESSION хранит данные обо всех текущих сеансах. Оно содержит 72 столбца информации, и потому слишком громоздко для анализа данных сеанса. Вот почему ASH упрощает представление V$SESSION и получает из него наиболее важную информацию ожидания. Oracle предлагает новое представление V$ACTIVE_SESSION_HISTORY, которое содержит по одной строке для каждого активного сеанса, откуда ASH делало выборку, и возвращает строку самого последнего сеанса первой.
Представление V$ACTIVE_SESSION_HISTORY — это место, где база данных хранит пример данных всех активных сеансов. В этом представлении имеется столбец по имени SESSION_STATE, который показывает, активен ли сеанс. Столбец SESSION_STATE принимает два значения: ON CPU или WAITING. Сеанс считается активным в следующих случаях:
- состояние сеанса ON CPU, что означает активное использование сеансом процессора для выполнения работы с базой данных;
- состояние сеанса WAITING, но столбец EVENT указывает, что сеанс не ожидает никаких событий в классе IDLE.
Обратите внимание, что ASH — скользящий буфер в SGA; это находящаяся в памяти хронология активного сеанса. Таким образом, в загруженной базе данных старая информация часто перезаписывается, поскольку ASH собирает данные из представления V$SESSION каждую секунду.
На заметку! Использование статистики ASH для настройки производительности экземпляра рассматривается в главе 20.
Хронологические данные более старых сеансов
Представление словаря данных DBA_HIST_ACTIVE_SESSION_HISTORY хранит хронологическую информацию о последнем активном сеансе. Другими словами, это представление — не что иное, как коллекция снимков представления V$ACTIVE_SESSION_HISTORY, которое само по себе является образом данных активного сеанса.
Существуют два способа заполнения DBA_HIST_ACTIVE_SESSION_HISTORY.
- В процессе получения регулярных (по умолчанию — ежечасных) снимков, выполняемых AWR, фоновый процесс MMON передает AWR данные ASH.
- Oracle может понадобиться передать данные в представление DBA_HIST_ACTIVE_SESSION_HISTORY между моментами получения регулярных снимков, если буфер памяти окажется заполненным, и база данных не сможет записать в него данные об активности сеанса. В этом случае новый фоновый процесс MMNL выполнит выталкивание данных из буфера памяти в представление словаря данных.
Генерация отчета ASH
Для получения отчета ASH можно воспользоваться сценарием ashrpt.sql, находящимся в каталоге $ORACLE_HOME/rdbms/admin. Применение этого сценария аналогично использованию сценария awrrpt.sql, описанного ранее в этой главе. Этот сценарий генерирует информацию об операторах SQL, которые выполнялись в указанный период времени, и включает детали о блокировках и ожидании. Вот как можно запустить сценарий ashrpt.sql для получения отчета ASH:
$ $ORACLE_HOME/rdbms/admin/ashrpt.sql
Вам будет предложено ввести временные рамки для сбора информации ASH, кроме того, формат вывода отчета — HTML или текстовый, а также имя отчета. В листинге 1 ниже показана часть отчета ASH.
ASH Report For NICKO/nicko DB Name DB Id Instance Inst Num Release Cluster Host -------- ---------- -------- -------- ------- -------- --------- NICKO 1974138210 nicko 1 11.1.0 NO localhost CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size ----- ------------- ------------- ------------- -------------- 1 304M (100%) 100M (32.9%) 184M (60.5%) 2.0M (0.7%) Analysis Begin Time: 28-Jun-08 12:29:55 Analysis End Time: 28-Jun-08 13:30:00 Elapsed Time: 60.1 (mins) Sample Count: 81 Average Active Sessions: 0.02 Avg. Active Session per CPU: 0.02 Report Target: None specified
Первый раздел отчета ASH, Top User Events, предоставляет информацию о верхних пользовательских событиях, как показано в листинге 2:
Top User Events DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
Avg Active
Event Event Class % Activity Sessions
------------------------------ ------------- ------------ -----------
null event Other 19.75 0.00
CPU + Wait for CPU CPU 18.52 0.00
SQL*Net break/reset to client Application 18.52 0.00
log file switch completion Configuration 1.23 0.00
log file sync Commit 1.23 0.00
-------------------------------------------------------------
Раздел Top Background Events (Верхние фоновые события), показанный в листинге 3 ниже, демонстрирует события ожидания в базе данных.
Top Background Events DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
Avg Active
Event Event Class % Activity Sessions
------------------------------ ------------- ------------ -----------
os thread startup Concurrency 20.99 0.00
control file parallel write System I/O 9.88 0.00
CPU + Wait for CPU CPU 6.17 0.00
db file sequential read User I/O 1.23 0.00
log file parallel write System I/O 1.23 0.00
Раздел Top Service/Module (Верхняя служба/модуль), показанный в листинге 4, отображает активность, разделенную в соответствии со службами и модулями экземпляра.
Top Service/Module DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
Avg Active
Service Module % Activity Sessions
------------------------------ ------------- ------------ -----------
SYS$BACKGROUND UNNAMED 35.80 0.01
nicko OEM.SystemPool 20.99 0.00
SYS$USERS UNNAMED 17.28 0.00
nicko OEM.BoundedPool 7.41 0.00
SYS$USERS EM_PING 6.17 0.00
В листинге 5 ниже показана информация о важнейших типах команд SQL (раздел Top SQL Command Types), выполненных в базе данных за последний час.
Top SQL Command Types DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
Avg Active
SQL Command Type % Activity Sessions
------------------------------ ------------- ------------
PL/SQL EXECUTE 19.75 0.00
SELECT 9.88 0.00
INSERT 1.23 0.00
UPDATE 1.23 0.00
В листинге 6 ниже идентифицируются верхние операторы SQL (раздел Top SQL Statements), выполненные за анализируемый период ASH.
Top SQL Statements DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30) SQL ID % Activity Event % Event --------------- ---------- ---------------------------- ---------- 2b064ybzkwf1y 18.52 SQL*Net break/reset to client 18.52 BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
После этого следует раздел под названием Top SQL Using Literals (Верхние операторы SQL, использующие литералы), который поможет идентифицировать SQL-операторы, не использующие переменные привязки.
Следующие два сегмента, показанные в листинге 7, относятся Top Sessions (Ведущие сеансы) и Top Blocking Sessions (Ведущие блокирующие сеансы), основанные на ожиданиях в очереди и статистике ожидания занятого буфера.
Top Sessions DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
-> '# Samples Active' shows the number of ASH samples in which the session
was found waiting for that particular event. The percentage shown
in this column is calculated with respect to wall clock time
and not total database activity.
Top Blocking Sessions DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
-> Blocking session activity percentages are calculated with respect to
waits on Enqueues and "buffer busy" only
Следующие три сегмента подводят итог по ведущим объектам базы данных, ведущим файлам и ведущим защелкам в экземпляре. В конце отчет ASH содержит итоговую информацию о событиях ожидания в базе данных, распределенных по меньшим временным слотам, чем общий период анализа, как показано в листинге 8.
В этом примере часовой период времени разбит на десять шестиминутных интервалов. Данный пример поможет более точно выявить моменты ухудшения производительности.
Activity Over Time DB/Inst: NICKO/nicko (Jun 28 12:29 to 13:30)
-> Analysis period is divided into smaller time slots
-> Top 3 events are reported in each of those slots
-> 'Slot Count' shows the number of ASH samples in that slot
-> 'Event Count' shows the number of ASH samples waiting for that event in that slot
-> '% Event' is 'Event Count' over all ASH samples in the analysis period
Slot Event
Slot Time (Duration Count Event Count % Event
-------------------- -------- ----------------------------- -------- -------
12:30:00 (6.0 min) 6 SQL*Net break/reset to client 3 3.70
null event 2 2.47
os thread startup 1 1.23
12:36:00 (6.0 min) 4 CPU + Wait for CPU 3 3.70
null event 1 1.23
12:42:00 (6.0 min) 7 CPU + Wait for CPU 2 2.47
null event 2 2.47
os thread startup 2 2.47
12:48:00 (6.0 min) 9 SQL*Net break/reset to client 3 3.70
CPU + Wait for CPU 2 2.47
control file parallel write 2 2.47
12:54:00 (6.0 min) 13 control file parallel write 4 4.94
os thread startup 4 4.94
CPU + Wait for CPU 2 2.47
13:00:00 (6.0 min) 16 CPU + Wait for CPU 5 6.17
SQL*Net break/reset to client 4 4.94
null event 3 3.70
13:06:00 (6.0 min) 9 CPU + Wait for CPU 3 3.70
SQL*Net break/reset to client 2 2.47
os thread startup 2 2.47
13:12:00 (6.0 min) 5 null event 2 2.47
CPU + Wait for CPU 1 1.23
SQL*Net break/reset to client 1 1.23
13:18:00 (6.0 min) 4 SQL*Net break/reset to client 1 1.23
control file parallel write 1 1.23
null event 1 1.23
13:24:00 (6.0 min) 8 os thread startup 4 4.94
CPU + Wait for CPU 2 2.47
SQL*Net break/reset to client 1 1.23
End of Report
