Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Выбор условий аудита

Предположим, что ваша компания является глобальной корпорацией с 50000 (или более) сотрудников, разбросанных по всему миру. Принимая во внимание различия трудовых законодательств и циклов оплаты, можно сказать, что база данных персонала HR работает преимущественно в режиме OLTP. Если в этом случае регистрировать любое обращение к столбцам COMM и SALARY, то журнал аудита очень скоро разрастется до неуправляемых размеров. Обдумывая возможные решения, вы можете захотеть ограничить регистрацию обращений только в выдающихся случаях (например, при попытке просмотра зарплат, превышающих 150000, или при попытке просмотра вашей личной зарплаты). Подобное ограничение можно задать в политике FGA, указав условие в специальном параметре audit_condition при вызове процедуры. Если политика уже была определена, удаляем ее:
Параметр audit_condition использован для ограничения регистраций в журнале аудита только теми случаями, когда значение столбца SALARY превышает 150000 или когда значение EMPID равно 100. Если пользователь выбирает запись для кого-то, чья зарплата равна, например, 149 999, такое действие не будет регистрироваться. Обратите внимание,

Пользователь не выбирает данные ни из столбца SALARY, ни из COMM, поэтому журнал не ведется. Однако запрос
что для формирования записи журнала аудита необходимо выполнение обоих условий: пользователь должен обращаться к определенным столбцам и условие аудита должно быть выполнено. Если пользователь не обращается к значению столбца SALARY или COMM в запросе, то журнал не будет формироваться, даже если запрашиваемая запись имеет значение 150000 в столбце SALARY. Например, пусть зарплата Jake составляет 160000 и его идентификатор EMPID равен 52. Пользователь, который просто хочет узнать, кто является его начальником, выдает такой запрос:
формирует журнал. Столбец SALARY упомянут в предложении WHERE, поэтому пользователь неявно выбирает его, так что условие обращения к столбцу выполнено. Значение SALARY извлеченных записей превышает 150000 - условие аудита выполнено. Оба события произошли, поэтому будет сформирована запись в журнале аудита.
Для генерирования записи в журнале аудита необходимо наступление двух событий: условие аудита должно оцениваться как «истина» и пользователь должен выбирать соответствующие столбцы. При наступлении только одного события запись аудита не будет сформирована.
Условие аудита не обязательно должно ссылаться на столбцы таблицы, для которой определена политика; оно может ссылаться на и другие значения, в том числе на псевдостолбцы. Последняя возможность удобна тогда, когда вы хотите отслеживать действия не всех пользователей, а только некоторых. Предположим, что требуется регистрировать обращения к таблице EMP пользователя Scott. Определяем политику следующим образом:

Регистрироваться будут только действия пользователя Scott. Условие можно без труда заменить на более подходящее, например, указав USER IN (''SCOTT'', 'FRED'), чтобы включить аудит для Scott и Fred.
Возможно, требуется регистрировать все действия, которые выполняются по завершении рабочего дня: определяем политику следующим образом:

Регистрироваться будут все обращения к столбцам SALARY и COMM всех пользователей, выполненные вне временного интервала, начинающегося в 9 часов утра и заканчивающегося в 5 часов вечера. Все политики были названы по-разному и определены для одной таблицы - EMP, поэтому впоследствии в журнале аудита можно будет идентифицировать записи, вызванные применением каждой из политик. Например, чтобы узнать, какой пользователь обращался к записям EMP в нерабочее время, выполним такой запрос:

Вы можете задать любое количество условий, удовлетворяющих конкретным требованиям аудита для вашей собственной базы данных.
Запись переменных связывания
Я подготовил отличную ловушку для Scott - пользователя, который любит просматривать зарплаты разных высокооплачиваемых руководителей нашей компании и мою в том числе). Теперь каждый раз, когда Scott захочет узнать размер такой зарплаты, этот факт будет записан в журнал аудита.
Однако предположим, что после всех этих тщательных приготовлений Scott почувствует, что «запахло жареным», и каким-то образом раскроет мой план. Будучи исключительно сообразительным, он изменяет свой запрос, используя переменную связывания и надеясь тем самым избежать аудита:

Но его попытка терпит неудачу, так как FGA собирает значения переменных связывания (в дополнение к тексту SQL-оператора). Эти значения можно увидеть в столбце SQL_BIND представления DBA_FGA_AUDIT_ TRAIL. В предыдущем примере были бы записаны следующие данные:
Указывает на то, что речь идет о первой переменной связывания. Если в запросе несколько переменных связывания, то последующие будут отображаться как #2, #3 и т. д.

Указывает фактическую длину значения переменной связывания. В нашем примере Scott использовал значение 100, поэтому длина равна 3.

Указывает фактическое значение переменной связывания. В данном случае это 100.
Столбец SQL_BIND содержит строку значений, если использовано несколько переменных связывания. Например, если бы запрос был таким:

Переменные связывания идентифицируются позицией, значением и длиной значения.
Обратите внимание, что переменные связывания записываются в формате
Запись значений переменных связывания чрезвычайно важна, причем не только в целях контролируемости, но и для анализа шаблона доступа к данным, который сложно исследовать каким-то иным способом. Предположим, вы хотите определить наилучшую схему индексирования для хранилища данных. Следует на некоторое время включить детальный аудит для объектов, затем проанализировать значения столбцов SQL_TEXT и SQL_BIND журнала аудита и получить представление о ти пах значений, выбираемых пользователями. Такую информацию можно было бы также получить из представления V$SQL, но данное представление осуществляет выборку из разделяемого пула, из которого с течением времени старые операторы могут быть удалены. Журналы FGA сохраняются в таблице FGA_LOG$ до тех пор, пока администратор базы данных явно не удалит их. Поэтому журналы FGA обеспечивают более надежный механизм сбора текстов запросов и значений переменных связывания. Полученные сведения оказываются весьма полезны при разработке стратегии индексирования и секционирования.
 



jAntivirus