
- •Теперь, когда вы овладели использованием детального аудита во всех типах сред, научитесь использовать его дополнительные возможности в сервере Oracle Database 10g
- •Fga в сервере Oracle9iDatabase
- •Все типы dml-операторов
- •Сравнение с подходом на основе триггеров
- •Поведение средств fga во время изменения данных
- •Все важные столбцы?
- •Регистрация значений переменных связывания
- •Обобщение вышеизложенного
- •Комбинируем обычный и детальный аудит
- •Аудит fga и обычный аудит: различия
Сравнение с подходом на основе триггеров
Итак, что можно сделать с помощью средств FGA и чего нельзя сделать с помощью старого подхода на основе триггеров?
До СУБД Oracle Database 10gаудит DML-операторов выполнялся с помощью триггеров, подобными следующему (примечание: это – не настоящий код, а только показательный пример):
CREATE TRIGGER XXXXX
ON Таблица
AFTER INSERT OR UPDATE OR DELETE
FOR EACH ROW
BEGIN
INSERT INTO AUDIT_LOG
Старое значение, Новое значение, Время.....
END
Этот триггер "захватывает" старые и новые значения и заносит их в таблицу AUDIT_LOG. Если требуется, такую процедуру можно выполнить также и в автономной транзакции. Самая большая проблема состоит в том, что этот триггер срабатывает для каждой строки, а не один раз для каждого оператора. Например, следующий оператор инициирует запуск триггера 10,000 раз и запись 10,000 строк в таблицу аудита:
update accounts set balance = 1200 where balance >= 3000;
Этот подход может серьезно подорвать производительность выполнения оператора обновления и может даже привести к его сбою из-за проблем с пространством в журнале аудита. Использование триггера операторов вместо "строкового" триггера также не решит проблему, поскольку он не может "захватывать" никаких новых или старых значений из отдельных строк. Напротив, в подходе с использованием FGA создается только одна запись, и вставка выполняется только один раз при каждом выполнении оператора, а не для каждой обрабатываемой строки, что незначительно влияет на производительность, если вообще влияет.
В FGA вы можете указывать только нужные столбцы, чтобы ограничить генерацию записей аудита только теми столбцами, к которым выполняется доступ. В триггерах такая функциональная возможность достигается с помощью предложения WHERE, вставляемого в тело триггера. Однако здесь имеется очень важное различие – в триггерах столбцы проверяются только тогда, когда они изменяются, а не при любом доступе. В FGA события аудита инициируются при каждом обращении к столбцам независимо от того, изменяются они или нет. Это свойство делает FGA более универсальным механизмом, чем триггеры.
Другое преимущество – применимость средств FGA. Иногда, когда триггеры INSTEAD OF, определенные на представлении, модифицируют его базовую таблицу, другой триггер INSTEAD OF не может перехватить изменения, сделанные другим триггером, и, следовательно, они не могут быть зарегистрированы. А средства FGA, установленные на представлениях или таблицах, перехватывают изменения независимо от их источника – пользовательских операторов или триггеров.
А вообще есть ли какие-то ситуации, в которых триггеры являются лучшей альтернативой по сравнению со средствами FGA? Таких ситуаций может быть две:
вспомните, средства FGA вставляют записи аудита, используя автономные транзакции, которые фиксируются в их собственном контексте. Если в DML-операторе возникает ошибка или выполняется его откат, вставленная запись аудита неоткатывается. Если пользователь что-то модифицирует, но не фиксирует это, изменение не производится, а запись аудита создается в любом случае. Это может приводить к появлению отдельных ложноположительных записей в таблице аудита, потенциально нежелательной ситуации. При последующем анализе таблицы аудита с использованием номеров SCN, извлекаемых ретроспективными запросами, можно, вероятно, обнаружить эту проблему, но процесс анализа может быть достаточно сложным. Но если этот риск не приемлем, то подход на основе триггеров более предпочтителен по сравнению со средствами FGA;
средства FGA записывают SQL-операторы, выполняемые пользователем, и номера SCN, но не значения данных до и после изменения. Для извлечения этих значений следует применять отдельное средство, использующее ретроспективные запросы к таблицам. Поскольку выполнение ретроспективных запросов зависит от информации, содержащейся в сегментах отката и ограниченной по времени, данное средство, может быть, и не извлечет старые значения, измененные достаточно давно. Подход на основе триггеров позволяет фиксировать изменения в их источнике, следовательно, регистрация старых и новых значений гарантируется.