![image](https://habrastorage.org/webt/65/ss/dh/65ssdhfbun3rdcakns_aifqklpo.png)
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.
Performance Home
На вкладке Performance Home можно увидеть основные графики утилизации БД.
Average Runnable Process
Этот график дает общее понимание использования CPU.
![](https://habrastorage.org/webt/_l/nr/d2/_lnrd2y4jcujfsw8kb7bln8maum.png)
№ | Показатель | Описание |
---|---|---|
1 | Instance Foreground CPU | Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете |
2 | Instance Background CPU | Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle |
3 | Non-database Host CPU | Отображает утилизацию CPU процессами, не относящимися к текущему инстансу |
4 | Load Average | Отображает среднюю длину очереди процессов, ожидающих выполнения |
5 | CPU Treads/CPU Cores | Отображает лимит максимально возможного использования CPU |
Average Active Sessions
Average Active Sessions отображает информацию в разрезе классов событий ожидания и утилизации CPU. Активные сессии представляют собой каждое подключение пользователя из какого-то процесса, находящегося в активном состоянии (то есть работают в настоящий момент) или в состоянии ожидания. Среднее количество активных сессий рассчитывается как результат деления суммы всех событий ожидания на временной интервал.
- Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
- Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
- Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).
![](https://habrastorage.org/webt/4o/xc/_n/4oxc_nu0kc5q8sqh32cetsug7x0.png)
Если на графике нажать кнопку Include Background, можно увидеть дополнительно статистику по фоновым процессам.
В Oracle есть такие классы события ожидания:
№ | Класс события ожидания | Описание |
---|---|---|
1 | Cluster | События ожидания, связанные с управлением кластером RAC (Real Cluster Application) |
2 | Queueing | Содержит события, которые показывают задержки получения дополнительных данных в канальной среде. Время, затраченное в этих ожиданиях, указывает на неэффективность или другие проблемы в канале, что влияет на такие функции Oracle, как Oracle Streams, параллельные запросы или PL/SQL пакеты DBMS_PIPE |
3 | Network | Сетевые события ожидания, включая события, возникающие во время обмена сообщениями по сети |
4 | Administrative | Ожидание выполнения DBA-команд, например пересоздание индекса |
5 | Configuration | Ожидания, вызванные неправильной конфигурацией ресурсов базы данных или экземпляра (например, недостаточный размер лог-файла) |
6 | Commit | События ожидания фиксации. Включает в себя одно-единственное событие ожидания log file sync (событие ожидания синхронизации файлов журналов), которое вызывают выполняемые в базе данных операции фиксации |
7 | Application | События ожидания, возникающие из-за кода приложения |
8 | Concurency | Ожидает внутренних ресурсов базы данных |
9 | System I/O | События ожидания системного ввода-вывода. Включает в себя события ожидания, связанные с фоновыми процессами ввода-вывода, в том числе событие db file parallel write (событие ожидания выполнения параллельной записи в файлы базы данных), которого ожидает фоновый процесс записи в базу данных, и события, связанные с чтением и записью в архивные журналы и журналы повторного выполнения |
10 | User I/O | События ожидания пользовательского ввода-вывода. Включает в себя события ожидания, связанные с пользовательскими процессами ввода-вывода, в том числе db file sequential read (событие ожидания выполнения последовательного чтения из файлов базы данных) и db file scattered read (событие ожидания выполнения чтения из файлов базы данных «вразброс») |
11 | Scheduler | События ожидания планировщика, включает в себя события ожидания, связанные с работой приложения Resource Manager (диспетчер ресурсов) |
12 | Other | Другие события ожидания, включает в себя разнородные события ожидания |
Throughput
Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.
![](https://habrastorage.org/webt/0t/av/0f/0tav0f4lzzxx-1hkzidjtfkrg78.png)
Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.
I/O
Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.
![](https://habrastorage.org/webt/yr/wu/gh/yrwughgelfmnsko6ccctnddao8k.png)
Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.
I/O Function
График дает представление об уровне утилизации диска приложениями или джобами. То есть на графике можно увидеть, какие процессы больше всего читали и писали за определенный период.
![](https://habrastorage.org/webt/ft/_w/5o/ft_w5o0g-7vuc8ua-mjnj-q9eek.png)
Можно выделить следующие категории:
№ | Категория | Описание |
---|---|---|
1 | Фоновые процессы | Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации) |
2 | Активность | XML DB, Streams AQ, Data Pump, Recovery, RMAN |
3 | Тип I/O | Включает прямую запись и чтение (в том числе чтение из кэша) |
4 | Другое | Включает операции ввода/вывода управляющих файлов |
I/O Type
Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.
![](https://habrastorage.org/webt/vz/hn/lg/vzhnlgu-gxgapuj7hztrps0aasm.png)
Consumer group
Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.
Parallel Executions
Раздел дает представление о показателях, связанных с параллельным выполнением запросов. Параллельный запрос делится на несколько процессов для ускорения выполнения запроса. Параллельное выполнение полезно при выполнении тяжелых запросов. Подробнее можно прочесть в официальной документации Oracle.
![](https://habrastorage.org/webt/bh/xc/uf/bhxcufas63yjs8m3ji5wfgbwopm.png)
![](https://habrastorage.org/webt/d9/30/2n/d9302nlayxabplojxw5y9c164jg.png)
Services
Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.
![](https://habrastorage.org/webt/ln/ud/fy/lnudfyclxfw34cr2xxkmzwa0qjy.png)
ASH Report
ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.
![](https://habrastorage.org/webt/1j/ed/bx/1jedbxkffjb8nptt7pemyrr7k-0.png)
На графике можно выбрать признак, по которому хочется посмотреть статистику. Основные признаки:
- События ожидания и группы событий ожидания.
- Группы пользователей, пользователи, сервисы, инстансы.
- SQL-запросы.
На графике выше можно увидеть, что с 02:00 до 02:24 наблюдается рост времени ожидания чтения с диска, превышающего количество процессоров в системе.
Помимо этого можно посмотреть статистику по SQL-запросам, перейдя на вкладку SQL Monitoring.
![](https://habrastorage.org/webt/-k/ik/7f/-kik7fcgredodvchgtgwtd9rmye.png)
На этой вкладке отображается топ-100 запросов по выбранному критерию (например, продолжительность, последние запросы, распределение по DB Time, утилизация диска). Нажав на SQL ID, можно провалиться глубже в детализацию и посмотреть как сам запрос, так и план его выполнения и потребляемые ресурсы. Подробнее про план выполнения запросов можно почитать в статьях Методы доступа к данным в Oracle и Опыт и рекомендации по оптимизации SQL-запросов.
Рассмотрим ситуацию, возникшую во время проведения нагрузочного тестирования одного из сервисов.
![](https://habrastorage.org/webt/w2/3z/p6/w23zp6hxl-ghdydtjulzj5q22k8.png)
На графике явно прослеживается рост времени ожидания сети в моменты запуска тестов. При более детальном рассмотрении в списке SQL-запросов был найден запрос, который утилизировал сеть. Он обращался по dblink к другой БД.
![](https://habrastorage.org/webt/gj/ke/nb/gjkenbhdr2h6uc2bh5q0qqvx0os.png)
AWR
AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.
Load Profile
Здесь отображается общая информация по тому, как была загружена БД за выбранный период.
![](https://habrastorage.org/webt/k1/xj/88/k1xj88b1boxtnf6j_rizoz48is0.png)
№ | Параметр | Описание |
---|---|---|
1 | DB Time(s) | Сумма времени утилизации процессора и время ожидания (без простоя) |
2 | DB CPU(s) | Нагрузка на процессор |
3 | Background CPU(s) | Загрузка процессора фоновыми задачами |
4 | Redo size | Объем чтения |
5 | Logical reads | Среднее количество логических чтений блоков |
6 | Block changes | Среднее значение измененных блоков |
7 | Physical reads | Физическое чтение в блоках |
8 | Physical writes | Количество записей в блоках |
9 | Read I/O requests | Количество чтений |
10 | Write I/O requests | Количество записей |
11 | Read I/O (MB) | Объем чтения |
12 | Write I/O (MB) | Объем записей |
13 | IM scan rows | Количество строк в In-Memory Compression Units (IMCU), которые были доступны |
14 | Session Logical Read IM | Чтения в In-Memory |
15 | User calls | Пользовательские вызовы |
16 | Parses | Разборы |
17 | Logons | Количество входов |
18 | Excecutes | Количество вызовов |
19 | Rollback | Количество откатов данных |
20 | Transacions | Количество транзакций |
Instance Efficiency Percentages
![](https://habrastorage.org/webt/jb/7z/s5/jb7zs5ntt33kok0imk6pthddyck.png)
№ | Показатель | Критерии |
---|---|---|
1 | Buffer nowait | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
2 | Buffer Hit | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
3 | Library cache hit | Если показатель меньше 95% — нужно расширять shared pool (либо причина в bind-переменных) |
4 | Redo NOWAIT | Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log |
5 | Parse CPU to Parse Elapsd | Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных |
6 | Non-Parse CPU | Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы |
7 | In-memory sort | Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting |
8 | Soft Parse | Чем он выше, тем меньше у нас Hard Parse |
9 | Latch Hit | Чем он выше, тем меньше мы ждем Latches (если он низкий — у нас проблемы с CPU-Bound и Latches) |
Top 10 Foreground Events by Total Wait Time
В разделе находится топ-10 событий, которые ожидали ресурсов дольше остальных.
![](https://habrastorage.org/webt/zi/bt/jd/zibtjdooyvmul3bvlupv4qrujwa.png)
При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.
![](https://habrastorage.org/webt/er/aq/sg/eraqsgmolkjbolzvesvmgpzbqwy.png)
Описание некоторых событий ожидания:
№ | Событие ожидания | Описание |
---|---|---|
1 | DB CPU | Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка |
2 | db file sequential read | Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода |
3 | db file scattered read | Указывает на проблему с фулл-сканами, возможно, нужны индексы |
4 | read by other session | Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая |
5 | enq TX – row lock contention | Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами |
6 | DB FILE SEQUENTIAL READ | Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно |
7 | LOG FILE SYNC | Значение AVG WAIT более 20 мс может свидетельствовать о проблемах |
8 | DB FILE SCATTERED READ | Если это событие выполняется — возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение |
9 | direct path read temp ИЛИ direct path write temp |
Эти события дают информацию по использованию временных файлов |
10 | Buffer Busy Wait | Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания |
Host CPU и Instance CPU
Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.
![](https://habrastorage.org/webt/um/ij/qx/umijqxh9lamn1s-rrt03kzaesv4.png)
![](https://habrastorage.org/webt/0d/n8/b1/0dn8b1ghrpwt0vzfpuyekakam-i.png)
Foreground Wait Class, Foreground Wait events и Background Wait Events
Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.
![](https://habrastorage.org/webt/kp/xi/xe/kpxixe3faaarrzyxvwkwuvn7tkm.png)
![](https://habrastorage.org/webt/vk/kj/g_/vkkjg_8nj2-zchtktfucq2cybgk.png)
![](https://habrastorage.org/webt/nr/oi/sg/nroisgt-jshim_qyfbx4vgmzbj0.png)
SQL statistics
Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.
![](https://habrastorage.org/webt/fv/lm/ig/fvlmig8woupng-odsej9ins7z8o.png)
№ | Параметр | Описание |
---|---|---|
1 | SQL ordered by Elapsed Time | Топ SQL-запросов по затраченному времени на их выполнение |
2 | SQL ordered by CPU Time | Топ SQL-запросов по процессорному времени |
3 | SQL ordered by User I/O Wait Time | Топ SQL-запросов по времени ожидания ввода/вывода для пользователя |
4 | SQL ordered by Gets | Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры |
5 | SQL ordered by Reads | Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода |
6 | SQL ordered by Physical Reads (UnOptimized) | В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC) |
7 | SQL ordered by Executions | Наиболее часто выполняемые запросы |
8 | SQL ordered by Parse Calls | Отображает количество попыток разбора SQL-запросов до его выполнения |
9 | SQL ordered by Sharable Memory | Запросы, занимающие больший объем памяти общего пула SGA |
10 | SQL ordered by Version Count | Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле |
11 | Complete List of SQL Text | Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы «select * from...», запросы с большим количеством «like» и т. п.) |
Active Session History (ASH) Report
![](https://habrastorage.org/webt/2t/yt/6e/2tyt6egiq3_zkb9ampo1nuojdvy.png)
В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.
![](https://habrastorage.org/webt/pn/lx/xi/pnlxxiukmct5z74ruefsqmlkzey.png)
В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.