Как проверить статус oracle

Обновлено: 01.07.2024

Добрый день! Сегодняшняя статья посвящена аудиту пользователей в БД. Все примеры работают на БД Oracle, но используемые алгоритмы и срезы проверок, вероятно, есть во всех распространенных базах, просто немного иначе реализуются.

Перед нами была поставлена задача оценки активности пользователей БД с точки зрения информационной безопасности, а именно проверки ролей, привилегий, периода доступа к БД и иных метрик, которыми наделяются пользователи БД при предоставлении доступа.

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

Установить связь «пользователь Oracle – ПК», с которых производилась авторизация в Oracle конкретными пользователями;
Обозначить период активности пользователя в БД, в т.ч. флаг активности в текущем году;
Проверить привилегии пользователя – в Oracle это звучит как Role privileges и System privileges.

Также была задача выявить все возможные действия для каждого объекта БД каждым пользователем, но сохранить уникальность пользователя не удавалось: оборотной стороной медали была потеря наглядности данных, поэтому мы решили создать отдельное представление.

Итак, начну с последнего и наиболее простого с точки зрения реализации пункта – мониторинга привилегий пользователей на каждый объект БД. Для создания этого представления хватило системной таблицы dba_tab_privs, в которой содержатся все пользователи и их полномочия, а также те, кто выдал эти полномочия. Итак, запустим следующий код:

Результат этого кода показывает, к каким объектам БД (OWNER, TABLE_NAME, TYPE) имеет доступ конкретный пользователь (GRANTEE), и какие полномочия у него есть для работы с каждым объектом БД (PRIVS_TO_OBJECT_BD):

Иными словами, суть представления – показать доступные действия пользователя для каждого объекта БД (в данном случае связка Пользователь БД + Объект БД – уникальна).

Отлично, двигаемся дальше. Теперь рассмотрим код для сбора различных системных атрибутов по каждому пользователю БД. Ввиду сложности кода разобьём его на составные части (для удобства выделим связанные атрибуты в SQL-блоки “with”). Так, сначала определимся с перечнем пользователей, по которым будем собирать аналитику. В нашем случае мы исключили пользователей, которые в качестве default_tablespace используют системные пространства БД:

Данный код использует системное представление dba_users и собирает некоторые атрибуты, например, текущий статус пользователя (открыт/заблокирован/…), дату блокировки пользователя, а также профайл пользователя (администратор/пользователь/технологическая учетная запись):

Так, список ключей уникален, теперь будем обогащать эту таблицу атрибутами из других системных таблиц, исходя из задачи. О них далее.

Добавим данные по авторизациям пользователей в БД. Для этого немного преобразуем системное представление dba_audit_session. Ввиду того, что изначально в представлении перечень пользователей БД неуникален, воспользуемся функцией listagg для сбора однотипных метрик пользователя в один кортеж. Для справки: функция listagg таблицу вида:

Преобразует в вид:

С помощью этой функции получаем уникальность пользователей БД, а значит готовы обогащать этими данными первоначальный список пользователей. Исходный код по авторизациям пользователей в БД выглядит так:

Результат исполнения кода:

Обратите внимание, дополнительно оконная sql-функция считает количество ПК, с которых осуществлялся вход под выбранным пользователем (атрибут PC_CNT).

Результат исполнения запроса:

Далее, выделим права каждого пользователя, для этого используем 2 таблицы Oracle DB: dba_role_privs и dba_tab_privs:

И второй код, для dba_tab_privs:

В столбце CNT_ROLE_PRIVELEGES – количество ролей каждого пользователя. Здесь можно отследить критичные. Например, для нас возможность пользователя просматривать содержимое всех таблиц на сервере – недопустима, поэтому все роли “select any table” были заменены на “select table”, что позволяет выводить содержимое только созданных пользователем таблиц. В принципе готово, осталось собрать все блоки “with” в одно представление с помощью конструкции JOIN:

Результат итогового представления (для наглядности показан в виде single record view):

Таким образом созданы 2 представления, которые показывают наглядную картину по аудиту пользователей, а также доступы к критичным объектам БД. В дальнейшем можно настроить систему алертов, которая бы при наступлении определённого события оповещала заинтересованных сотрудников любым доступным в вашей организации способом, например:

Да и в целом, инструменты, представленные в статье, частично готовы решать задачу оптимизации места на сервере за счет оценки активности пользователей. То есть, если у вас есть логины, которые последний раз заходили в БД несколько лет назад – то, вероятно, можно очищать их персональное пространство. Тема оценки активности использования объектов БД – уже совсем другая задача.

Для нашего приложения у нас есть файл конфигурации для подключения к базе данных Oracle (URL, имя пользователя, пароль).

Запуск приложения занимает 2-5 минут. Если с базой данных что-то не так, я вижу это в логах, но мне нужно подождать 2-5 минут. Это много времени.

Поэтому я хочу быстро и просто найти способ определить, что с базой данных все в порядке и он-лайн.

Ты хоть представляешь, как я могу это сделать?

Если вы выполните следующий запрос:

ps -ef | grep pmon

Процесс PMON (монитор процесса) проверяет все остальные фоновые процессы. Затем вы должны проверить журнал предупреждений для дальнейшего расследования.

Первое и первое: вам нужно знать имя пользователя и пароль для подключения к базе данных на шаге 2

Проверьте процесс оракула:

если команда в любом случае возвращает выходные данные, т.е. если в вашей среде запущен процесс pmon / oracle, то база данных работает.

Перейти ORACLE_HOME/bin и запустить:

Если после входа в систему вы получаете ошибки, то база данных не запускается:

Вы должны использовать / написать скрипт, который будет подключаться к серверу и посмотреть, подключена ли ваша база данных. Здесь ребята из Oracle помогут. Просто запустите его из сценария пакетной обработки / оболочки (см. Запуск сценариев из командной строки SQL ) и посмотрите его вывод. Если все в порядке, тогда у вас есть ответ.

Или просто попробуйте с клиентом SQL * Plus.

Возможно, было бы целесообразно выполнить фактический запрос к базе данных. Это просто гарантирует, что вы можете подключиться и запросить. Я бы сделал это очень простым и быстрым, например:

PMON проверит все процессы bg

Кроме того, мы можем проверить, работает база данных или нет.

Чтобы проверить общий статус базы данных, я рекомендую:

Проверьте, запущены ли процессы базы данных. Например, из оболочки Unix, работающей:

покажет запущенные базы данных, время запуска и то, какие пользователи Oracle запустили каждую из них.

Проверьте, работают ли слушатели, используя $ ps -ef | grep tns и $ lsnrctl status LISTENER

Выбор gv$resource_limit покажет, достигла ли база данных какого-либо настроенного предела.

В том числе: Проверьте состояние экземпляра Oracle, проверьте процесс обслуживания Oracle, проверьте процесс мониторинга Oracle, всего три части.

1.1 Проверьте состояние экземпляра Oracle

Среди них «STATUS» указывает текущее состояние экземпляра Oracle, которое должно быть «OPEN», «DATABASE_STATUS» указывает текущее состояние базы данных Oracle, которое должно быть «ACTIVE».

1.2 Проверка состояния журнала онлайн Oracle

Выходной результат должен иметь более 3 записей (включая 3) записи, «STATUS» должен быть не «INVALID», не «DELETED». Примечание: «СТАТУС» пуст для обозначения нормального.

1.3 Проверьте состояние табличного пространства Oracle

СОСТОЯНИЕ должно быть ОНЛАЙН на выходе.

1.4 Проверьте состояние всех файлов данных Oracle

«STATUS» на выходе должно быть «ONLINE». или:

«STATUS» на выходе должно быть «ДОСТУПНО».

1.5 Проверка на недействительные объекты

Если запись возвращается, это означает, что существует недопустимый объект. Если эти объекты связаны с приложением, вам нужно перекомпилировать его для создания или:

1.6 Проверьте состояние всех сегментов отката

«СОСТОЯНИЕ» всех сегментов отката на выходе должно быть «ОНЛАЙН».

2. Проверьте использование ресурсов, связанных с Oracle

содержать:
А. Проверьте значения соответствующих параметров в файле инициализации Oracle.
б. Проверьте подключение к базе данных и проверьте место на системном диске.
В. Проверьте использование различных табличных пространств Oracle, проверьте некоторые объекты с ненормальными расширениями,
г. Проверьте содержимое системного табличного пространства, проверьте следующее расширение объекта и максимальное значение расширения табличного пространства, всего семь частей.

2.1 Проверьте значения соответствующих параметров в файле инициализации Oracle

Если LIMIT_VALU-MAX_UTILIZATION <= 5, это означает, что параметры инициализации Oracle, связанные с RESOURCE_NAME, должны быть скорректированы. Можно изменить, изменив файл параметров инициализации Oracle $ ORACLE_BASE / admin / CKDB / pfile / initORCL.ora.

2.2. Проверка соединения с базой данных

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

Среди них: SID сеанса (сеанса), идентификационный номер;

USERNAME - имя пользователя, с которого был установлен разговор;

Какой инструмент используется для сеанса PROGRAM для подключения к базе данных;

STATUS Текущее состояние этого сеанса. ACTIVE означает, что сеанс выполняет определенные задачи. INACTIVE означает, что текущий сеанс не выполняет никаких операций.

Если установлено слишком много подключений, это потребляет ресурсы базы данных. В то же время некоторые «зависшие» подключения, возможно, придется очистить вручную. Если администратор базы данных хочет отключить сеанс вручную, выполните:

(Обычно не рекомендуется использовать этот метод для разрыва соединения с базой данных, поэтому иногда сеанс не будет отключен. Легко вызвать прерывание соединения. Рекомендуется проверить spid операционной системы через sid и использовать ps –ef | grep spidno для подтверждения spid Не фоновый процесс ORACLE. Используйте команду kill -9 операционной системы, чтобы разорвать соединение)

Примечание. В приведенном выше примере сеансы с SID от 1 до 10 (столбец USERNAME пуст) являются фоновыми процессами Oracle и не выполняют никаких операций в этих сеансах.

2.3 Проверьте место на системном диске

Если оставшееся пространство файловой системы слишком мало или увеличивается быстрее, вам необходимо подтвердить его и удалить неиспользуемые файлы, чтобы освободить место.

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 9.7G 3.9G 5.4G 42% /

/dev/sda1 479M 16M 438M 4% /boot

/dev/sda2 49G 19G 28G 41% /data

none 1014M 0 1014M 0% /dev/shm

2.4 Проверьте использование табличного пространства

select f.tablespace_name,
a.total,
f.free,
round((f.free / a.total) * 100) "% Free"
from (select tablespace_name, sum(bytes / (1024 * 1024)) total
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "% Free";

Если процент простоя% Free составляет менее 10% (включая 10%), обратите внимание на увеличение файла данных для расширения табличного пространства вместо использования функции автоматического расширения файла данных. Пожалуйста, не добавляйте слишком много файлов данных в табличное пространство.Принцип увеличения файлов данных заключается в том, что размер каждого файла данных составляет 2G или 4G, а максимальное ограничение для автоматического расширения составляет 8G.

2.5 Проверьте некоторые расширенные ненормальные объекты

Если запись возвращается, расширение этих объектов почти достигло максимального значения расширения, когда оно было определено. Для этих объектов необходимо изменить параметры его структуры хранения.

2.6 Проверка содержимого системного табличного пространства

Если запись возвращается, это указывает на то, что в системном табличном пространстве есть некоторые не системные и системные пользовательские объекты. Далее следует проверить, относятся ли эти объекты к нашему приложению. Если это уместно, переместите эти объекты в несистемное табличное пространство, и вам следует проверить значение табличного пространства по умолчанию для владельца этих объектов.

2.7 Проверьте следующее расширение объекта и максимальное значение расширения табличного пространства

Если запись возвращается, это указывает, что следующее расширение этих объектов больше, чем максимальное значение расширения табличного пространства, к которому принадлежит объект, и параметры хранения соответствующего табличного пространства должны быть скорректированы.

3. Проверьте результаты резервного копирования базы данных Oracle

содержать:
a. Проверьте информацию журнала резервного копирования базы данных;
б. Проверьте время создания файлов в томе резервной копии;
c. Проверьте электронную почту пользователя оракула.
3.1. Проверьте информацию журнала резервного копирования базы данных

Предположение: временный каталог для резервного копирования - / backup / hotbakup, нам нужно проверить результат резервного копирования 22 июля 2009 года, а затем использовать следующую команду для проверки:

cat /backup/hotbackup/hotbackup-09-7-22.log|grep –i error

Файл журнала сценария резервного копирования - hotbackup-month-date-year.log, находящийся во временном каталоге резервного копирования. Если в файле есть «ОШИБКА:», это означает, что резервное копирование не было успешным, и существует проблема, которую необходимо проверить.

3.2 Проверьте время создания файлов в томе резервной копии

Том резервной копии является временным каталогом для резервного копирования. Дата просмотра файла в результате вывода должна быть сгенерирована сценарием горячего резервного копирования ранним утром того же дня. Если время указано неверно, это означает, что сценарий горячего резервного копирования не был успешно выполнен.

3.3 Проверьте электронную почту пользователя оракула

4. Проверьте производительность базы данных Oracle

В этом разделе мы в основном проверяем производительность базы данных Oracle, в том числе: проверяем события ожидания базы данных, проверяем взаимоблокировки и обработку, проверяем процессор, ввод-вывод, производительность памяти, проверяем, существует ли процесс взаимоблокировки, проверяем связь / перенос строк и регулярно выполняем статистический анализ , Проверьте частоту попаданий в буфер, проверьте частоту попаданий в общий пул, проверьте область сортировки, проверьте буфер журнала, всего десять частей.

4.1. Проверка базы данных на события ожидания

Если в базе данных много событий ожидания, таких как освобождение защелки, постановка в очередь, ожидание занятости буфера, последовательное чтение файла db, чтение файла db, разбросанное по разным данным и т. Д., В течение длительного времени, их необходимо проанализировать, и могут возникнуть проблемные утверждения.

4.2 Получить оператор SQL с самым высоким показанием диска

4.3. Найти десятку плохо работающих SQL

4.4 Пять систем с наибольшим временем ожидания ждут сбора событий

4.5 Проверка долгосрочного SQL

4.6. Проверьте процесс, который потребляет больше всего процессора

4.7 Проверьте таблицы с высокой фрагментацией

4.8 Проверьте соотношение ввода-вывода в табличном пространстве

4.9 Проверьте соотношение ввода / вывода файловой системы

4.10 Проверка на тупик и обработку

Запрос информации о текущем объекте блокировки:

Уровень Oracle убивает сессию:

Сеанс уничтожения на уровне операционной системы:

5. Проверьте базу данных процессора, ввода-вывода, производительность памяти

Запишите использование ЦП, ввода-вывода, памяти и т. Д. Базы данных, используйте команды vmstat, iostat, sar, top и другие для сбора информации и проверки информации для определения использования ресурса.

5.1 Использование процессора:

top - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29

Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie

Cpu(s): 1.2% us, 0.1% sy, 0.0% ni,98.8% id, 0.0% wa, 0.0% hi, 0.0% si

Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffers

Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30495 oracle 15 0 8329m 866m 861m R 10 5.4 7:53.90 oracle

32501 oracle 15 0 8328m 1.7g 1.7g S 2 10.6 1:58.38 oracle

32503 oracle 15 0 8329m 1.6g 1.6g S 2 10.2 2:06.62 oracle

Обратите внимание на синий шрифт выше, эта часть представляет оставшийся ЦП системы. Когда среднее значение падает ниже 10%, это рассматривается как ненормальное использование ЦП. Вам необходимо записать это значение и записать состояние как ненормальное.

5.2 Использование памяти:

total used free shared buffers cached

Mem: 2026 1958 67 0 76 1556

-/+ buffers/cache: 326 1700

Swap: 5992 92 5900

Как показано выше, синяя часть представляет общую память системы, красная часть представляет память, используемую системой, а желтая часть представляет оставшуюся память системы. Когда оставшаяся память составляет менее 10% от общей памяти, она считается ненормальной.

5.3 Ситуация с системным вводом / выводом:

Linux 2.6.9-22.ELsmp (AS14) 07/29/2009

avg-cpu: %user %nice %sys%iowait %idle

0.16 0.00 0.05 0.36 99.43

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 3.33 13.16 50.25 94483478 360665804

avg-cpu: %user %nice %sys%iowait %idle

0.00 0.00 0.00 0.00 100.00

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 0.00 0.00 0.00 0 0

Как показано выше, синий шрифт указывает состояние чтения и записи диска, а красный шрифт указывает состояние ожидания ввода-вывода ЦП.

5.4 Системная нагрузка:

12:08:37 up 162 days, 23:33, 15 users, load average: 0.01, 0.15, 0.10

Как показано выше, синий шрифт обозначает нагрузку на систему. Если следующие три значения превышают 2,5, это указывает на то, что система работает при перегрузке. Запишите это значение в таблицу проверки и сочтите его ненормальным.

5.5 Проверьте, есть ли процесс зомби

Некоторые процессы зомби блокируют нормальную работу других сервисов и регулярно убивают процессы зомби.

5.6 Проверьте ссылку на линию / миграцию

Примечание. Обычно таблица с длинными необработанными столбцами имеет ссылку на строку, находит строку миграции и сохраняет ее в таблице chained_rows. Если такой таблицы нет, выполните ее.

Вы можете увидеть, какие строки являются перенесенными строками по таблице имя_хеда, head_rowid в таблице chained_rows

5.7 Регулярный статистический анализ
Для системы, использующей Oracle Cost-Based-Optimizer, необходимо регулярно собирать и обновлять статистическую информацию объектов данных, чтобы оптимизатор мог составить правильный план объяснения на основе подготовленной информации. Статистическая информация должна обновляться в следующих ситуациях:
а. Изменения в приложении
б. Масштабная миграция данных, миграция исторических данных, импорт других данных и т. д.
C. Количество данных изменилось
Проверьте, нужно ли обновлять статистику таблицы или индекса, например:

Если количество строк сильно отличается, таблица должна обновлять статистическую информацию, поэтому рекомендуется собирать статистическую информацию раз в неделю, например:

5.8 Проверьте частоту попаданий в буфер

Если частота попаданий ниже 90%, вам нужно увеличить параметр базы данных db_cache_size.

5.9 Проверка коэффициента попадания в общий пул

Если оно ниже 95%, вам необходимо настроить приложение для использования переменных связывания или настроить размер общего пула параметров базы данных.

5.10 Проверьте область сортировки

Если отношение диск / (памятка + строка) слишком велико, вам нужно настроить sort_area_size (workarea_size_policy = false) или pga_aggregate_target (workarea_size_policy = true).

5.11 Проверьте буфер журнала

Если повторное размещение буфера повторных попыток / повторных записей превышает 1%, вам нужно увеличить log_buffer.

6. Проверьте безопасность базы данных

В этом разделе мы в основном проверяем безопасность базы данных Oracle, в том числе: проверяем информацию о безопасности системы, регулярно меняем пароль, всего две части.

6.1 Проверьте информацию журнала безопасности системы

Каталог файла журнала безопасности системы находится в / var / log, который в основном проверяет информацию журнала пользователя об успешном или неудачном входе в систему.

Проверьте журнал успешного входа в систему:

Jan 8 08:44:43 rac2 sshd[29559]: Accepted password for root from ::ffff:10.10.10.6 port 1119 ssh2……

Проверьте журнал неудачного входа в систему:

Jan 9 10:30:44 rac2 sshd[3071]: Invalid user ydbuser from ::ffff:192.168.3.5

Jan 9 10:30:56 rac2 sshd[3071]: Failed password for invalid user ydbuser from ::ffff:192.168.3.5 port 36005 ssh2

Jan 10 22:44:38 rac2 sshd[21611]: Failed password for root from ::ffff:10.10.10.6 port 1723 ssh2

6.2 Проверьте пользователя, чтобы сменить пароль

В системе баз данных часто бывает много пользователей, таких как: сторонние системы мониторинга баз данных, демонстрационные пользователи во время первоначальной установки базы данных, пользователи-администраторы и т. Д. Пароли этих пользователей часто пишутся, и многие люди знают, что они будут скрытыми мотивами. Люди привыкли атаковать систему и даже изменять данные. В число пользователей, которым необходимо изменить свои пароли, входят:
Пользователи администратора базы данных SYS, SYSTEM; другие пользователи.
После входа в систему введите cat / etc / passwd в командной строке, чтобы проверить, есть ли среди перечисленных пользователей неиспользуемые или странные учетные записи. Если он существует, он записывается как ненормальный.

Метод изменения пароля:

7. Другие проверки

В этом разделе мы в основном проверяем, является ли текущая задача crontab нормальной и не сработала ли работа Oracle. Существует шесть частей.

7.1 Проверьте, является ли текущая задача crontab нормальной

7.2 Сбой работы Oracle

Если есть проблемы, рекомендуется перестроить задание, например:

7.3. Контролировать рост объема данных

Согласно ежедневной проверке на этой неделе, найдите объекты базы данных с быстро расширяющимся пространством и примите соответствующие меры:

- Удалить исторические данные
Мобильные правила предусматривают, что в базе данных должно храниться не менее 6 месяцев исторических данных, поэтому предыдущие исторические данные можно рассмотреть для резервного копирования, а затем очистить, чтобы освободить занимаемое ими пространство ресурса.

--- Расширить табличное пространство

Примечание: При изменении структуры базы данных, такой как добавление табличного пространства, добавление файлов данных или файлов журнала повторов, эти операции вызовут изменения в контрольном файле базы данных Oracle. Администратор базы данных должен создать резервную копию контрольного файла. Метод резервного копирования:

Выполнить оператор SQL:

Таким образом, команда SQL для создания управляющего файла будет сгенерирована в каталоге USER_DUMP_DEST (указан в файле параметров инициализации).

7.4 Проверка на неуспешные индексы

Примечание. Обычно состояние индекса в таблице разделов равно N / A. Если индекс не выполнен, перестройте его, например:

Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.

Performance Home

На вкладке Performance Home можно увидеть основные графики утилизации БД.

Average Runnable Process

Этот график дает общее понимание использования CPU.

№	Показатель	Описание
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

Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).

Throughput

Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.

Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.

Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.

Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.

I/O Function

График дает представление об уровне утилизации диска приложениями или джобами. То есть на графике можно увидеть, какие процессы больше всего читали и писали за определенный период.

Можно выделить следующие категории:

№	Категория	Описание
1	Фоновые процессы	Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации)
2	Активность	XML DB, Streams AQ, Data Pump, Recovery, RMAN
3	Тип I/O	Включает прямую запись и чтение (в том числе чтение из кэша)
4	Другое	Включает операции ввода/вывода управляющих файлов

I/O Type

Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.

Consumer group

Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.

Parallel Executions

Раздел дает представление о показателях, связанных с параллельным выполнением запросов. Параллельный запрос делится на несколько процессов для ускорения выполнения запроса. Параллельное выполнение полезно при выполнении тяжелых запросов. Подробнее можно прочесть в официальной документации Oracle.

Services

Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.

ASH Report

ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.

События ожидания и группы событий ожидания.
Группы пользователей, пользователи, сервисы, инстансы.
SQL-запросы.

AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.

Load Profile

Здесь отображается общая информация по тому, как была загружена БД за выбранный период.

№	Параметр	Описание
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

№	Показатель	Критерии
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 событий, которые ожидали ресурсов дольше остальных.

При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.

Описание некоторых событий ожидания:

№	Событие ожидания	Описание
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 высокий, это может свидетельствовать о том, что процессор является узким местом.

Foreground Wait Class, Foreground Wait events и Background Wait Events

Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.

SQL statistics

Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.

№	Параметр	Описание
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

В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.

В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.

Следуйте за нами на нашей фан-странице, чтобы получать уведомления каждый раз, когда появляются новые статьи. Facebook

1- Введение аудита системы Oracle

Аудит (Auditing) означает мониторинг и запись (monitoring and recording) действий конфигурированных в базе данных. Включая действия от обоих пользователей (user) database user и nondatabase user.

Nondatabase Users: Это пользователь определенного приложения. Данное приложение использует базу данных Oracle, и поэтому они могут выполнить действия с базой данных. Данные пользователи должны быть идентифицированы в базе данных используя атрибут CLIENT_IDENTIFIER. Аудит данных пользователей сложнее по сравнению с аудитом пользователей базы данных (Database users).

Аудит (Auditing) является нужной и важной работой для администратора базы данных. Это эффективный инструмент, который предотврещает неверные действия. И всегда выполняется первым в любых инновациях безопасности в Oracle.

Помимо этого существуют некоторые другие причины, которые должны быть аудитированы:

Аудитор проверяет пользователей, у которые имеют привелегию доступа к чувствительным объектам.
Аудит трейла (Audit Trail) эффективно предотвращает пользователя от неверных действий.
Audit Trail это обязательно, если вы расследовать и хотите узнать, что выполняется неправильно.
Audit Trail предупреждает вас о подозрительных действиях, вы можете выполнить анализ того, что вам кажется неясным.
Audit Trail очень важен при определении контроля доступа, особенно в существующих приложениях.
Очень сложно определить, что "правило аудита доступа" не разрушит бизнес процесс, только если вы знаете текущее состояние и что они делают.

Действия аудита создают Audit Trail, включая записи, позволяющие найти, что было выполнено в базе данных.
Основываясь на это, чтобы знать что сделали пользователи, и какие привилегии были использованы …
Для каждой записи иеется важная информация как:
- Кто выполнил
- Где выполнено (какая Schema или какой Object)
- Когда выполнено.
- Как выполнено (Какие команды SQL были выполнены).
- Так же другие полезные информации в расследовании и мониторинге.

2- Активировать режим стандартного аудита (standard audit mode)

Standard Audit (Стандартный аудит) это самая обширная и полная база аудита в базе данных Oracle. Позволяет аудитировать действия (Action), вид действий, объект, привилегию (Privilege), доступ пользователя..

Активировать режим аудита (Audit).
Определить категории (category) нужные для аудита, то есть определить какие действия будут создавать трейл (Создать Audit Trail).

Чтобы активировать режим аудита базы данных, вам нужно получить доступ к Oracle с пользователем имеющим привилегию sysdba.

Аудит трейлы (Audit trail) могут быть таблицей данных или файл на операционной системе. Если аудитор не имеет привилегию (privilege) DBA, лучше всего сохранять информацию аудита на файлах. Есть 4 способа для настройки хранения "аудит трейла".

Параметр	Описание
DB	Трейл сохраненный в таблице AUD$, содержит только команду (statement) не полный текст.
DB,EXTENDED	Трейл сохраненный в таблице AUD$, полный текст (Значения переменных (variable) для каждой записи..)
XML	Трейл сохраненный в файле операционной системы, формата XML, содержание похожее на параметр DB.
XML,EXTENDED	Трейл сохраненный в файле операционной системы, формата XML, содержание похожее на параметр DB,EXTENDED.

3- Настроить Audit с параметром DB

Для начала, вам нужно активировать режим аудита с параметром DB (audit_trail = DB), выполнить команды ниже:

В данном примере мы выполним аудит (audit) таблицы для Scott.EMP, с параметром DB, это значит "аудит трейлы" (audit trail) будут сохранены в базе данных (Точнее будут сохранены в таблице AUD$).

Использовать другой user чтобы выполнить некоторые действия на таблице Scott.EMP, например update. Данные действия будут сохранены в таблице AUD$.

4- Настроить Audit с параметром DB,EXTENDED

Настроить режим аудита с параметром audit_trail = DB,EXTENDED.

Выполнить действие update на таблице Scott.EMP:

Использовать другой user, чтобы выполнить определенное действие на таблице Scott.EMP:

5- Set up Audit with XML parameter

Используя параметр audit_trail = xml, "аудит трейлы (audit trail)" будут сохранены в файле с форматом XML.

Файлы Audit обычно расположены в папке adump. Но чтобы знать точно, вы можете использовать следующую команду для проверки папки, содержащей файлы Audit.

6- Set up Audit with XML,EXTENDED parameter

Когда вы настраиваете аудит с параметром Audit_trail = xml,extended, полученный результат похож на использование параметра Audit_trail = xml, но в файлах XML добавит информацию про команды (statement), которые были выполнены.

7- Просмотр связанных параметров

Когда режим аудита уже настроен для базы данных, вы можете проверить использованный параметр.

Проверить название папки, содержащей файлы Audit, которые будут созданы.

Название папки содержащей файлы Audit сохранено в файле spfile<SID>.ora.

Изменить папку содержащую файлы Audit:

View more Tutorials:

Это онлайн курс вне вебсайта o7planning, который мы представляем, он включает бесплатные курсы или курсы со скидкой.

Читайте также: