Я работаю над устранением неполадок в базе данных Oracle, которая имеет некоторые общие проблемы с производительностью. Я выполнил следующий запрос:
SELECT event AS "Event|Name",
total_waits "Total|Waits",
round(time_waited / 100, 0) "Seconds|Waiting",
total_timeouts "Total|Timeouts",
average_wait / 100 "Average|Wait|(in secs)"
FROM sys.v_$system_event e
ORDER BY time_waited DESC;
Первые несколько строк вернулись следующим образом. Миллионы секунд ожидания! (Для сравнения, наши другие БД имеют время ожидания <10 секунд для основных событий.) Что делают эти события и что может вызвать такое большое время ожидания? БД работает уже 30 дней, поэтому мы наблюдаем агрегацию за это время.
Event Name Waits Seconds Timeouts Avg Wait
---------------------- --------- -------- -------- --------
SQL*Net message from client 488397968 32050594 0 0.0656
rdbms ipc message 91335556 2455744 9529486 0.0269
DIAG idle wait 5214769 347077 5214769 0.0666
Streams AQ: qmn coordinator idle wait 186521 173696 93278 0.9312
Streams AQ: qmn slave idle wait 95359 173692 51 1.8215
Space Manager: slave idle wait 523165 173647 521016 0.3319
pmon timer 968303 173630 870108 0.1793
fbar timer 8770 173403 8713 19.7723
smon timer 14103 173278 7006 12.2866
log file sync 57967889 90402 649458 0.0016
og file parallel write 86618366 39509 0 0.0005
db file sequential read 244286101 11171 0 0
control file parallel write 1274395 3949 0 0.0031
db file scattered read 157316868 1635 0 0
db file parallel read 11948170 1190 0 0.0001
"SQLСетевое сообщение от клиента "- это время, затраченное базой данных на ожидание запроса от клиента на выполнение каких-либо действий (я бы также интерпретировал это как показатель количества SQLЧистые запросы, обрабатываемые базой данных). AskTom есть дополнительная информация о мероприятии. Это тоже не похоже на очень долгое среднее ожидание, так что, возможно, у вас есть приложение, которое делает МНОГО небольших запросов к серверу? Это много ожидания за 30 дней (в среднем 16 миллионов в день).
Что касается сообщения rdbms ipc, это означает (Справочник Oracle 10g):
«Фоновые процессы (LGWR, DBWR, LMS0) используют это событие, чтобы указать, что они простаивают и ждут, пока процессы переднего плана отправят им сообщение IPC для выполнения некоторой работы».
Обычно это не событие с точки зрения настройки. (Бурлесон)
выбор только из v $ system_event имеет ограниченное применение. Представление содержит общее время ожидания и счетчики всех событий ожидания с момента последнего запуска базы данных. В последний раз база данных запускалась год назад или несколько минут назад, но в любом случае меня обычно интересует только то, что происходит сейчас с моим оператором sql, пакетным заданием или конечными пользователями. Конечные пользователи ждут неактивных нефоновых ожиданий, но v $ system_event содержит все события, включая более 50 простаивающих событий и множество ожиданий фоновых, не пользовательских процессов, которые заботятся о базе данных. Вместо того, чтобы запускать этот запрос, попробуйте запустить отчет AWR или статистический пакет или посмотреть на экран производительности или верхней активности в Enterprise Manager. быстрый способ увидеть, что сейчас происходит в базе данных, - запустить следующий оператор select:
select nvl(s.username,s.program) username
, s.sid sid
, s.serial# serial
, s.sql_hash_value sql_hash_value
, substr(decode(w.wait_time, 0, w.event, 'ON CPU'),1,15) event
, w.p1 p1
, w.p2 p2
, w.p3 p3
from v$session s
, v$session_wait w
where w.sid=s.sid
and s.status='ACTIVE'
and s.type='USER';
который сообщит вам, кто ждет, а кто загружает процессор или запрашивает его. Выполняя запрос снова и снова, вы можете понять, какие узкие места существуют в системе. Представление Oracle 10g и выше v $ active_session_history содержит эту информацию, выборку которой производится раз в секунду. Это гораздо более мощные данные, чем v $ system_event, но их сложно добыть. Для добычи данных вы можете использовать главный экран активности Enterprise Manager, но если у вас нет OEM, есть отличный бесплатный инструмент.