Oracle история подключений пользователей

Обновлено: 06.07.2024

В посте рассматривается способ разблокировки и доступа к учебному и тестовому пользователю (схемы) HR в базе данных Oracle Database 18c Express Edition. Рассмотрены следующие вопросы:

Краткий обзор Multitenant архитектуры
Разблокировка пользователя HR

Multitenant
Flashback Table
Flashback Database
Oracle Partitioning
In-Memory Column Store и Aggregation
Advanced Analytics и Security
Online Index Rebuild
Online Table Redefinition
Query Results Cache и PL/SQL Function Result Cache
Oracle Advanced Compression
Materialized View Query Rewrite
Oracle Spatial and Graph
Bitmap Indexes

Разблокировка пользователя (схемы) HR

Предполагается, что есть успешно установленная Oracle Database 18c Express Edition. При необходимости, можно установить Oracle Database 18c Express Edition используя следующие материалы: установка Oracle Database 18c Express Edition на Linux и установка Oracle Database 18c Express Edition на Windows. Нижеописанные шаги будут работать с Oracle Database 18c Express Edition, установленной, как на операционную систему Linux, так и на Windows.

Вариант разблокировки с помощью SQL*Plus.

Шаг 1. Подключение к CDB

Выполняется подключение к CDB с помощью пользователя sys с ролью as sysdba:

Подключение успешно прошло к CDB. Далее проверяется имя и идентификатор CDB.

Результат запроса показывает, что CDB имеет имя XE и ее уникальный идентификатор = 0. По умолчанию, после установки Oracle Database 18c Express Edition есть одна PDB с именем XEPDB1. Следующий запрос покажет существующие PDB.

Проверяется наличие пользователя HR в CDB.

Запрос не вернул данные. Это означает, что пользователя HR нет в CDB. Далее необходимо подключиться к PDB и найти там HR.

Шаг 2. Подключение к PDB

Есть два способа подключиться к PDB с использованием SQL*Plus.

Способ 1. Находясь в CDB, подключиться к PDB используя команду alter session. В примере ниже происходит переключение из сеанса CDB к PDB с именем XEPDB1:

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

Запросы показывают характеристики существующей PDB (Шаг 1.).

Способ 2. Можно подключиться к PDB с консоли операционной системы, указав параметры подключения.

Ниже выполняется подключение к PDB под пользователем sys с указанием IP адреса сервера БД, порта и имени PDB (по умолчанию для созданной PDB (XEPDB1) используется порт 1539):

Подключение прошло успешно.

Для информации: Администраторы баз данных временами выполняют подключение к БД используя аутентификацию на уровне операционной системы с помощью команды sqlplus / as sysdba и без указания пароля. При запуске этой команды в среде с Multitenant архитектурой будет осуществлено подключение к CDB. Для того, чтобы напрямую подключиться к PDB минуя CDB, используется sqlplus / as sysdba и без указания пароля, также необходимо в переменную среду операционной системы добавить новый системный параметр ORACLE_PDB_SID и в его значении указать название PDB. Этот параметр для подключения к PDB без указания пароля могут осуществлять только пользователи sys и system. Остальные пользователи будут автоматически подключены к CDB, если не укажут параметры подключения к PDB. Ниже описываются шаги подключения к PDB для пользователя sys с применением параметра ORACLE_PDB_SID в переменной среде операционной системы. Это очень удобный способ для администраторов баз данных:

Подключение к PDB прошло успешно напрямую из операционной системы без указания пароля и параметров подключения PDB. Далее проверяется имя и идентификатор PDB.

После успешного подключения к PDB c использованием одного из двух способов определяется наличие пользователя HR, а также его статус.

Запускается запрос поиска пользователя HR среди всех существующих пользователей в XEPDB1:

Получен результат, подтверждающий наличие пользователя HR в PDB.

При помощи запроса определяется имя, статус и дата блокировки пользователя HR:

Шаг 3. Разблокировка пользователя HR

После установки Oracle Database 18c Express Edition учетная запись HR заблокирована и пароль у нее просрочен (необходимо задать новый пароль) (см. предыдущий шаг – Шаг 2.). В этом случае, система позволяет сделать запросы к объектам HR (таблицам, представлениям, функциям и т.п.) от имени других пользователей при наличии соответствующих привилегий. Например, при выполнении запроса на определение количества строк в таблице EMPLOYEES пользователя HR под пользователем SYS система успешно выдаст следующий результат:

Для пользователя HR назначается новый пароль:

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

Необходимо заново подключиться к PDB под пользователем sys:

и разблокировать пользователя HR следующей командой:

Операции назначения пароля и разблокировки пользователя HR прошли успешно. Проверяется статус пользователя:

Пользователь HR разблокирован и новый пароль активен. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Используя данные для подключения к PDB, выполняется вход систему под учетной записью HR и запускается запрос для определения количества строк в его таблице EMPLOYEES.

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL*Plus.

Вариант разблокировки с помощью SQL Developer.

Шаг 1. Подключение к CDB

Для этого создается новое подключение в SQL Developer и указываются необходимые параметры подключения к CDB, такие как:

Name: XE_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать CDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XE
SID или имя CDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

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

После нажатия Connect произойдет успешное подключение к CDB с именем XE. Далее проверяется имя, идентификатор и версия CDB, а также выводятся существующие PDB.

Как и ожидалось, выведенные выше данные идентичны полученным с помощью SQL*Plus.

Далее проверяется наличие пользователя HR в CDB.

Запрос не вернул данные, это означает, что пользователя HR нет в CDB. Теперь необходимо подключиться к PDB и проверить наличие HR в PDB.

Шаг 2. Подключение к PDB

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1, такие как:

Name: XEPDB1_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных. Пользователи sys и system могут подключиться с одним и тем же паролем и к CDB и к PDB.

После нажатия Connect произойдет успешное подключение к подключаемой БД XEPDB1. Далее проверяется имя и идентификатор.

Результаты показывают, что было подключение к PDB с именем XEPDB1 и идентификатором 3. Определяется наличие пользователя HR в этой PDB. В иерархии дерева надо выбрать «Other Users» в соединении с именем XEPDB1_18c как показано на скриншоте:

В списке пользователей необходимо найти пользователя HR и нажать на правую кнопку. Из контекстного меню выбрать «Edit User». Откроется новое модальное окно «Edit User» как показано на скриншоте. Как видно на скриншоте учетная запись HR заблокирована (Account is Locked) и пароль у нее просрочен (Password Expired):

Шаг 3. Разблокировка пользователя HR:

В продолжение предыдущего шага необходимо:

Задать идентичный пароль в полях New Password (новый пароль) и Confirm Password (подтвердить пароль).
Снять галочку из пункта Password Expired (user must change next login).
Снять галочку из пункта Account is Locked для разблокировки пользователя.
Нажать Apply.

Пользователь HR разблокирован и ему назначен пароль. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1 с пользователем HR, такие как:

Name: XEPDB1_18c_hr
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении с пользователем HR.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: HR
Указывается имя пользователя для подключения к БД.

Role: default
Подключение к БД осуществляется пользователем HR. Данный пользователь не может использовать роль SYSDBA.

Password:
Пароль, который был назначен пользователю HR на третьем шаге, то есть hr.

После нажатия Connect произойдет успешное подключение к PDB с именем XEPDB1 под пользователем HR. Выполняется запрос для определения количества строк в таблице EMPLOYEES:

И так, мы настроили аудит. Информация о действиях пользователей в базе данных начала собираться. Мы знаем, где ёё можно посмотреть. Но всё это будет напрасно, если мы не сможем разобраться в этом большом количестве разнообразных данных. Поэтому попытаемся выработать основные этапы анализа аудита. Начнём с подключений пользователей к базе данных. Так как в больших системах количество соединений может составлять тысячи за день, нас в первую очередь будут интересовать подключения пользователей обладающих расширенными привилегиями. К таким пользователям относятся системные учётные записи, отдельная учётная запись администратора базы данных, если таковая имеется. Так же к ним можно отнести и пользователей, которые могут изменить критически важные данные, например известные нам пользователи AH и BE. Такие подключения следует, прежде всего, отслеживать по месту откуда делается попытка соединения. Если соединение осуществлялось с компьютера имя, которого отличается от привычного имени, то, скорее всего, произошёл взлом или утечка регистрационных данных учётной записи. Во всяком случае, на эти записи следует обратить внимание. Выполним, к примеру, следующий запрос:

В результате мы видим, что было произведено успешное подключение под учётной системной записью BE с компьютера W005, хотя пользователь раньше всегда соединялся только с терминалов W003 или W004. Возможно, это говорит о том, что учётная запись BE была взломана. Если же проверка успешных подключений привилегированных пользователей не показала ничего подозрительного, то нам стоит проанализировать соединения, которые по тем или иным причинам завершились с ошибкой. Делается это с помощью следующего запроса:

В данном случае видно, что попытка подключения под пользователями AH и BE окончилась неудачей. Но если одиночное неудачное соединение пользователя AH можно списать на ошибку ввода пароля. То аудит подключений пользователя BE может говорить о попытке взлома учётной записи. Кроме вопросов касающихся безопасности аудит подключений можно использовать и в целях определения сеансов сильно загружающих экземпляра базы данных. Всё дело в том, что при удачном завершении подключения в аудит происходит запись некоторой статистики сеанса. Поэтому обращаясь к столбцам SESSION_CPU, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_DLOCK можно находить сеансы которые используют, слишком большое количество процессорного времени, осуществляют много физических и логических чтений или имеют взаимоблокировки. Выполним, к примеру, следующий запрос:

Здесь мы видим, что сеанс пользователя VP длился девять часов, причём время, в течение которого использовался процессор, составило более восьми часов. Это, скорее всего, говорит о ненормальной работе приложения, в котором работал пользователь. Определить, какое это приложение можно только по числовому идентификатору сеанса SESSIONID. Ему соответствует поле AUDSID представления V$SESSION. К сожалению когда мы будем просматривать аудит мы уже не найдем в этом представлении информацию о сеансе. Поэтому нам придётся дополнительно вести историю сеансов с помощью системных триггеров. Разобравшись с подключениями и не выявив попыток взлома или несанкционированного использования учётных записей, можно попытаться разобраться в остальных действиях пользователей. И начать это лучше с проверки выполнения системных команд. К ним в первую очередь стоит отнести команду ALTER SYSTEM динамически меняющую экземпляр базы данных, команды выдачи, отбора привилегий GRANT и REVOKE, операторы изменения настройки аудита AUDIT и NOAUDIT. Выбрать все записи, образующиеся при выполнении этих команд можно с помощью следующего запроса:

Попробуем провести анализ полученного результата. Первая запись говорит нам о том, что администратором была включена опция аудита PROCEDURE. На это указывает действие SYSTEM AUDIT в столбце ACTION_NAME и название опции в столбце AUDIT_OPTION. Далее следует семь записей, отображающие выдачу администратором объектных привилегий роли HR_PROG, о чём свидетельствует тип действия SYSTEM AUDIT. Столбцы OWNER и OBJ_NAME при этом идентифицируют объект, на который выдаются права, а столбец GRANTEE получателя этих привилегий. Расшифровку выдаваемых прав, можно осуществить с помощью значения столбца OBJ_PRIVILEGE. Здесь каждое положение символа соответствует определённой объектной привилегии. Если символ имеет значение Y, то значит, привилегия на объект была предоставлена. В нашем случае роли были предоставлены все объектные привилегии, которые имеются для данного типа объекта. В следующей записи аудита присутствует действие SYSTEM GRANT, означающее, что администратором была произведена выдача системной привилегии роли HR_PROG. Посмотреть какая привилегия при этом выдавалась можно в столбце SYS_PRIVILEGE. В нашем случае там находится значение ALTER SESSION. Далее мы видим группу записей с общим действием GRANT ROLE. Это действие относится к предоставлению роли пользователям или другим ролям, выдаваемая роль при этом отображается в столбце OBJ_NAME. В нашем случае была произведена выдача администратором роли CONNECT пользователям AH, BE, VP и роли HR_PROG пользователю AH. Причём в последнем случае роль была предоставлена пользователю с правом передачи, о чём свидетельствует присутствие символа A в столбце ADMIN_OPTION. Четырнадцатая запись аудита, пожалуй, не нуждается в пояснении. Действие ALTER SYSTEM явно указывает на то, что администратором была выполнена в системе одноименная команда и дополнительной информации мы здесь не увидим. Последние две записи аудита относятся, как было ранее рассмотрено, к предоставлению ролей пользователям. Но выдачу этих ролей осуществляют не привилегированные пользователи. Так мы видим, что пользователь AH предоставил роль HR_PROG пользователю BE, без права передачи, который в свою очередь попытался выдать эту роль пользователю VP, но потерпел неудачу. Ошибка при этом отобразилась в столбце RETURNCODE. Анализ аудита, осуществляемый с использованием представления DBA_AUDIT_STATEMENT, имеет большое значение, так как именно на этом этапе есть возможность определить попытки повышения привилегий учётной записи и вероятность замести следы несанкционированных действий путём изменения настроек аудита. Поэтому надо внимательно анализировать все без исключения записи на предмет, кто выполняет, какие действия, в какое время и главное откуда. Если же нам на этом этапе не удалось обнаружить никаких подозрительных действий, то мы можем спокойно переходить к следующему виду анализа аудита – анализу действий над объектами. Под объектами здесь подразумевается не только объекты схемы, но и системные объекты: пользователи, профили, роли, табличные пространства и т.д. Посмотреть аудит этих объектов можно с помощью следующего запроса:

Проанализируем полученный результат. В первых четырёх записях мы видим, что администратор создал роль HR_PROG и учетные записи пользователей AH, BE, VP. Их имена отображены в столбце OBJ_NAME, а действия совпадают с названиями применяемых SQL команд. После этого администратор включил триггер безопасности HR.SECURE_EMPLOYEES. На это указывает действие ENABLE TRIGGER и имя объекта в полях OWNER и OBJ_NAME. Далее пользователь AH попытался обратиться к таблице HR.EMPLOYEES. Но вместо какого либо понятного нам действия, в столбце ACTION_NAME мы видим лишь значение SESSION REC. На самом деле это значение означает, что запись факта всех действий для этого объекта в течение сеанса будет отображаться в этой записи, так как настройке опций был применён режим по умолчанию BY SESSION. Определить какие команды применялись к данному объекту можно по положению специального символа в столбце SES_ACTIONS. В нашем случае это положение соответствует команде UPDATE, а сам символ имеет значение F, что означает неудачное выполнение команды. После этого пользователь AH попытался выключить триггер безопасности HR.EMPLOYEES. Но потерпел неудачу. Это видно по значению поля RETURNCODE. Далее этим же пользователем были выполнены две команды SELECT и UPDATE применительно к объекту HR.JOBS. Это было определено из положения символов S в значении столбца SES_ACTIONS. Кстати данный символ свидетельствует об успешном выполнении команды. Продолжая анализ, мы видим, что в следующей записи присутствует действие CREATE TRIGGER, которое говорит нам о том, что администратор изменил триггер HR.SECURE_EMPLOYEES. Поле NEW_NAME здесь указывает на основной объект. В нашем случае это таблица HR.EMPLOYEES, к которой относится данный триггер. После того как триггер пересоздан, пользователь AH получил возможность удачно выполнить команду UPDATE для таблицы HR.EMPLOYEES, на это указывает положение символа S в значении столбца SES_ACTIONS. И наконец, в последней записи аудита видно как пользователь BE осуществил доступ к таблице HR.JOBS. Но в значении столбца SES_ACTIONS мы видим только символ B. Позиция его соответствует выполненной команде SELECT, но результат выполнения команды неизвестен. На самом деле присутствие этого символа означает, что произошло удачное и одновременно неудачное выполнение команды в течение сеанса.

Сопровождаем журнал

По мере роста количества записей в журнале аудита, возникает необходимость в проведении определённых действий связанных с сопровождением этого журнала. Если этого не делать, то мы можем столкнуться с рядом проблем, от сложности в анализе аудита, до полной остановки системы в случае переполнения табличного пространства SYSTEM. Что же это за действия? Перечислим их - это удаление лишних и архивирование нужных записей, сброс маркера максимального уровня заполнения таблицы SYS.AUD$, а также проведение усечения данной таблицы. Теперь рассмотрим их более подробно. В первую очередь необходимо время от времени удалять лишние записи из журнала аудита. Стратегия удаления может быть разнообразной. Допустим можно выборочно удалять отдельные записи аудита непосредственно в процессе анализа. Например, выполним следующий запрос и проанализируем полученный результат:

Подозрительных действий не обнаружено, и мы можем удалить, к примеру, первую запись. Удаление надо производить непосредственно из таблицы SYS.AUD$, используя при этом в качестве ключа значения столбцов SESSIONID и ENTRYID:

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

Приведённые выше способы удаления подразумевают хранение оставшейся информации, которая нас интересует непосредственно в самом журнале аудита. Это может привести к тому, что, по мере роста журнала аудита, эту информацию также придётся удалять. Чтобы этого не делать, можно организовать архивирование нужных нам записей аудита. Для этого можно создать архивные таблицы по структуре соответствующие представлениям журнала аудита в схеме отличной от SYS. Попробуем продемонстрировать это на примере. Создадим архивную таблицу ARCH_AUDIT_SESSION в схеме SYSTEM. По структуре она будет соответствовать представлению DBA_AUDIT_SESSION, но располагаться в другом табличном пространстве.

Теперь перенесём нужные нам записи из представления DBA_AUDIT_SESSION:

После того как все архивные таблицы созданы и необходимые нам записи аудита будут в них перенесены, можно спокойно очистить журнал аудита одной командой DELETE. Правда само удаление записей не решит проблему роста журнала. Для её устранения необходим сброс маркера максимального уровня заполнения таблицы SYS.AUD$. И сделать это можно с помощью нескольких способов. Первый состоит в том, чтобы очистить таблицу SYS.AUD$ с помощью команды TRUNCATE TABLE. Это приведёт к сбросу маркера. Если в таблице должны оставаться какие-либо записи, то необходимо вначале создать копию таблицы с помощью оператора CREATE TABLE AS SELECT. Затем выполнить команду TRUNCATE TABLE и вставить записи из копии таблицы обратно. Если при создании копии таблицы возникают проблемы, например не хватает места в табличном пространстве, то можно выгрузить данные в файл экспорта. Затем провести импорт данных обратно в таблицу. В качестве недостатка этого способа следует отметить, что неиспользуемые блоки, возникшие в результате удаления записей из журнала аудита, не освобождаются. И хотя таблица SYS.AUD$ не будет больше расти по объёму до определённого уровня, она будет иметь такой же размер, как и до её очистки. Чтобы избежать этого, можно использовать ещё один способ сброса маркера. Он представляет собой перемещение таблицы SYS.AUD$ в другое табличное пространство с помощью команды ALTER TABLE MOVE TABLESPACE и последующий возврат таблицы в табличное пространство SYSTEM:

При этом происходит не только сброс маркера максимального уровня, но и освобождение неиспользуемых блоков сегмента, то есть усечение таблицы. Единственно, что надо не забыть в этом случае, это перекомпилировать объекты, зависимые от таблицы SYS.AUD$, так как данная команда переводит их в статус инвалидных.

Используем расширенный режим

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

Рассматривая результат запроса, мы видим, что администратор выполнил какое-то изменение экземпляра базы данных с помощью команды ALTER SYSTEM. Но нам не видно, какие конкретно изменения он сделал. Это могло быть и изменение инициализационного параметра, и уничтожение сеанса пользователя. Если бы мы знали, какую команду выполнил пользователь в данный момент времени, мы могли бы точнее определить само действие и опасность его для системы. К счастью в Oracle начиная с девятой версии, предусмотрен расширенный режим аудита. В данном режиме в качестве дополнения в журнал аудита записываются исполняемые SQL команды, или значения переменных привязки, если таковые имеются. Включается данный режим изменением параметра инициализации AUDIT_TRAIL. Для этого надо присвоить ему значение DB,EXTENDED. Попробуем включить данный режим:

Перезагрузим экземпляр и проверим правильность установки значения параметра:

Расширенный режим установился. Заполним журнала аудита новой информацией. И если теперь мы повторим запрос к представлению журнала, то увидим, что в столбце SQL_TEXT появился текст выполненной команды:

В результате становиться понятно, какие действия совершил пользователь SYSTEM с экземпляром базы данных. Правда иногда, когда в SQL операторе используются связанные переменные, текст команды не даёт полной информации о совершаемом действии. В этом случае нам надо знать значения этих переменных. К примеру, в результате выполнения следующего запроса мы видим две записи с совершенно одинаковыми DML командами. Единственное что их отличает это значения связанных переменных, отображённых в столбце SQL_BIND.

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

Применяем другие виды журналов

Журнал аудита, который мы рассматривали выше, представляет собой таблицу AUD$ в схеме пользователя SYS. Но это не единственно место для хранения записей аудита. Кроме таблицы, аудит можно помещаться в системный журнал операционной системы или в XML файлы. Для включения данных режимов требуется изменить значение параметра инициализации AUDIT_TRAIL. Попробуем включить один из таких режимов. Для этого выполним следующую команду:

Перезагрузим экземпляр и вновь сгенерируем аудит. Если после этого мы сделаем запрос таблице SYS.AUD$, то увидим, что она пуста:

Но зато в системном журнале операционной системы появились записи. В нашем случае это будет выглядеть примерно так:

Информацию протоколирования можно записывать не только в системный журнал, но и в отдельные XML файлы. Их расположение определяется значением параметра AUDIT_FILE_DEST и по умолчанию может указывать на директории ORACLE_BASE/admin/DB_UNIQUE_NAME /adump или ORACLE_HOME/rdbms/audit. Попробуем включить данный режим, выполнив следующую команду:

Перезагрузим экземпляр и проверим значения параметров инициализации:

Далее проведём генерацию аудита. После чего мы обнаружим в директории C:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP несколько файлов. Это и будут файлы журнала аудита. В каждом отдельном файле с помощью XML формата будут отражены действия, выполняемые пользователем в течение одного сеанса. Имя файла при этом формируется из префикса ora_ и идентификатора серверного процесса. Приведем для примера содержимое одного такого файла:

Здесь мы могли бы столкнуться с большими трудностями при анализе аудита, так как довольно сложно обрабатывать такие файлы. Но Oracle облегчает задачу, предоставив нам системное представление V$XML_AUDIT_TRAIL. Сделав запрос к нему, мы получим данные аудита в уже привычной для нас табличной форме, где большинство столбцов соответствуют столбцам уже рассмотренного нами представления DBA_AUDIT_TRAIL.

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

По работе часто приходилось разбираться с производительностью серверов БД Oracle. После выхода Oracle 10g задача по мониторингу и диагностике проблем с производительностью значительно упростилась – с помощью истории активных сессий (Active Session History, ASH) стало возможно узнать, что происходило с БД в прошлом, что творится на сервере в данный момент, и даже прогнозировать, что будет происходить с нагрузкой в будущем.

Требовали некоторых телодвижений по их установке и настройке – это Oracle Enterprise Manager Console (DB Console) или Oracle Enterprise Manager Grid Control (сейчас Oracle Enterprise Manager Cloud Control). DB Console из моей (и не только) практики требовал для установки применения очень сильных админских заклятий. Также в целях экономии ресурсов не все хотят ставить на сервера БД дополнительные сервисы или разворачивать на своей площадке отдельную инфраструктуру для мониторинга;
Обладали рядом архитектурных недостатков. К примеру, в случае зависания сервера БД доступ к информации из истории активных сессий посредством Oracle Enterprise Manager Console становился невозможным, и оперативно выяснить, что «что-то пошло не так» (с) было практически нереально;
Отсутствовала функциональность в части сохранения данных мониторинга и последующего его анализа на своей площадке.

В общем, после рассмотрения всех доступных на тот момент вариантов, было принято волевое решение собирать свой «велосипед» из подручных материалов.

Независимость от установленных на базе данных у клиента средств мониторинга;
Возможность сохранения результатов мониторинга в локальной базе данных для последующей их обработки;
Расширяемость. Возможность добавления функциональности при необходимости;
Кроссплатформенность. Работа программы как в Unix/Linux, так и в Windows окружении.

Встраиваемая key value storage. Для хранения данных истории активных сессий; Библиотека для создания графиков на Java SE. Для решения задачи подошел stacked chart. Основные изменения для достижения требуемого результата – аналогично тому, как в Oracle Enterprise Manager – см. ChartPanel; Библиотека для создания Gantt графиков в Java Swing; Для более удобного вывода табличных данных, календарь и т.д.; Отличная библиотека для работы с датами в Java; Форматирование sql, pl/sql кода; Для подсветки sql, pl/sql кода.

Общая информация об ASH Viewer:
ASH Viewer предоставляет графический интерфейс для просмотра данных по активным сессиям. Программа периодически опрашивает сервер БД Oracle для получения списка активных сессий, сохраняет информацию в локальной базе данных, после чего данные визуализируются. Для версий до версии 10g база данных опрашивается один раз в секунду, для Oracle 10g и выше запрос информации из v$active_session_history и обновление графика происходят каждые 30 секунд.

Для версии 10g и выше есть возможность включения эмуляции ASH. Данный режим подходит для баз, у которых не подключена платная опция Oracle Diagnostic Pack, или для Oracle в редакции Standard Edition. Для 9i, 8i версий выбираем Standard.

Интерфейс Top Activity:
Интерфейс идентичен странице Top Activity Oracle Enterprise Manager. Выделяем произвольный диапазон на графике и получаем данные по top активных сессий и SQL/PL/SQL-операторов. Есть возможность получить детальную информацию по запросу – текст запроса, планы выполнения:
– Напрямую из v$sql_plan (по различным plan_hash_value). Сделано для совместимости с предыдущими версиями СУБД Oracle;
– DBMS_XPLAN.DISPLAY_CURSOR. Из курсорного кэша. Планы выполнения по определенному sql_id;
– DBMS_XPLAN.DISPLAY_AWR. Планы исполнения из репозитория рабочей нагрузки, также по sql_id.
В настройках можно выставить автоматический режим, при котором программа самостоятельно обновляет top sql-сессий и процессов по заданному окну (по умолчанию – 5 минут последней активности сервера БД), количество SQL, PL/SQL операторов, по которым выбирается детальная информация из БД (запрос из v$sql) и возможность изменения масштаба представления графика Top Activity относительно количества процессоров (параметр сервера БД cpu_count). По выделенному диапазону можно получить ASH-отчет (аналогично тому выводу, который получаем через скрипт) через вызов API сервера БД – DBMS_WORKLOAD_REPOSITORY.ASH_REPORT_TEXT

Интерфейс Detail:
Детализация по CPU Used и каждой группе событий ожидания. Работает аналогично интерфейсу Top Activity Oracle Enterprise Manager, только отсутствует автоматический режим. Также можно настраивать количество операторов, по которым выбирается детальная информация из v$sql, сохранение планов исполнения запросов в локальной базе и возможность изменения масштаба представления графика относительно количества процессоров в системе.

Интерфейс History:
На этой странице можно просматривать историю активных сессий, используя собранные данные из истории активных сессий Oracle. Навигация производится через интерфейс «Календарь». Также в интерфейсе «Календарь» можно выбрать диапазон дней и удалить его из локальный базы, чтобы освободить пространство на диске (например, в случае длительного сбора истории активных сессий). Работает offline режим, при котором можно запускать ASH Viewer только для просмотра архивных данных. Для получения более полной информации в архивном режиме рекомендуется собирать информацию в online в автоматическом режиме, иначе информация по sql-запросам будет доступна только в виде SQL ID/ HASH Value.

В случае если отсутствует подключение к БД (сбои в сети, проблемы с листенером, перезапуск БД), ASH Viewer автоматически пытается подключиться к серверу Oracle через каждые 30 секунд для продолжения сбора информации об истории активных сессий;
Есть возможность в настройках указать сбрасывать в буфер обмена ОС данные из топ SQL/PL/SQL-операторов.

Текущий мониторинг производительности СУБД Oracle;
Просмотр истории активных сессий за предыдущий период наблюдения;
Создание отчетов по работе БД Oracle.

Запись действий на экране в gif файл — ScreenToGif
Утилита для нагрузочного тестирования баз данных — Hummerora.

Как администратор базы геоданных, вы время от времени должны просматривать, кто подключен к базе геоданных, и какие соединения являются блокированными ресурсами. Вам даже, возможно, потребуется удалить некоторые подключения. Например, редактор мог оставить сеанс редактирования открытым, заблокировал данные в сеансе редактирования и запретил другим редакторам доступ к ним. Если число подключений к базе геоданных ограничено, то может потребоваться отключить какого-либо пользователя, который не смог выйти, чтобы освободить подключение. Или вам может потребоваться отключить всех пользователей, чтобы вы могли применить патч к базе данных, восстановить базу данных или сжать базу геоданных.

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

Внимание:

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

Для отключения пользователей от базы геоданных в Oracle, администратор базы геоданных должен быть добавлен в роль DBA или иметь права ALTER SYSTEM и SELECT_CATALOG_ROLE.

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

Идентификация и удаление подключений из ArcMap

Вы можете подключиться к базе геоданных как ее администратор в ArcMap для просмотра и удаления подключений в диалогом окне Администрирование базы геоданных .

Запустите ArcMap или ArcCatalog .
Подключитесь к базе геоданных как администратор базы геоданных.
Щелкните правой кнопкой подключение к базе геоданных в дереве Каталога, выберите пункт Администрирование и щелкните Администрирование базы геоданных .
Перейдите на закладку Подключения .

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

Сеанс будет немедленно отключен от базы геоданных.

Идентификация и удаление подключений с помощью ArcPy

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

В данном примере файл подключения ( oragdb.sde ) создан в папке temp. Он подключается к базе данных spora от имени пользователя sde.

Укажите файл подключения, который вы создали в предыдущем шаге.

Возвращается список подключений пользователей.

Укажите ID подключения, которое нужно удалить. Здесь удаляется подключение с ID 33:

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