Аудит в Oracle

Question

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

• пользователь, который изменил
• время изменения произошло
• старое значение и новое значение

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

Как я уже говорил, у нас так много таблиц, и мы не можем создавать триггер для каждой таблицы.каждый стол.Таким образом, идея заключается в создании основного триггера, который может вести себя динамически для любой таблицы, которая запускает триггер.Я пытался это сделать, но не повезло совсем ... кажется, что Oracle ограничивает среду триггера только для таблицы, которая объявлена ​​кодом, а не динамически, как мы хотим.

Есть ли у васЛюбая идея о том, как сделать это или любой другой совет для решения этой проблемы?

Answer 1

Если у вас есть корпоративная версия 10g, вам стоит взглянуть на Oracle Fine-Grained Auditing . Это определенно лучше, чем кататься самостоятельно.

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

Я знаю, что это не то, что вы хотите услышать, потому что оно не соответствует структуре таблицы, которую вы описали выше. Но сохранение строки со значениями OLD и NEW для каждого столбца, на которое влияет обновление, - очень плохая идея:

1. Не масштабируется (одно обновление, затрагивающее десять столбцов, порождает десять вставок)
2. Как насчет того, когда вы вставляете запись?
3. Собирать состояние записи в любой момент времени - полная боль

Итак, создайте таблицу аудита для каждой таблицы приложения с идентичной структурой. Это означает включение CHANGED_TIMESTAMP и CHANGED_USER в таблицу приложения, но это не плохо.

Наконец, и вы знаете, к чему это ведет, для каждой таблицы есть триггер, который вставляет в таблицу аудита целую запись, содержащую только значения: NEW. Триггер должен срабатывать при вставке и обновлении. Это дает полную историю, достаточно легко отразить две версии записи. Для УДАЛЕНИЯ вы вставите запись аудита только с заполненным первичным ключом, а все остальные столбцы пустыми.

Вы возразите, что у вас слишком много таблиц и слишком много столбцов для реализации всех этих объектов. Но достаточно просто сгенерировать таблицу и вызвать операторы DDL из словаря данных (user_tables, user_tab_columns).

Answer 2

Вам не нужно писать свои собственные триггеры.

Oracle поставляется с гибкими и детализированными сервисами аудита. Взгляните на этот документ (9i) в качестве отправной точки. (Изменить: Вот ссылка для 10g и 11g версий одного и того же документа.)

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