Базы данных Oracle - статьи


             

Сравнение с подходом на основе триггеров


Итак, что можно сделать с помощью средств 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? Таких ситуаций может быть две:



    Содержание  Назад  Вперед