Аудит в Oracle

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

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

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

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

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


oracle triggers audit auditing
person Alvaro Castro    schedule 06.05.2010    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

person Mike Atlas    schedule 06.05.2010

arrow_upward
5
arrow_downward

Если у вас корпоративная версия 10g, вам следует изучить детальный аудит . Это определенно лучше, чем кататься самостоятельно.

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

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

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

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

Наконец, и вы знаете, к чему это ведет, создайте триггер для каждой таблицы, который вставляет целую запись только со значениями: NEW в таблицу аудита. Триггер должен срабатывать при INSERT и UPDATE. Это дает полную историю, достаточно легко различить две версии записи. Для DELETE вы вставите контрольную запись с заполненным только первичным ключом и пустыми всеми остальными столбцами.

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

person APC    schedule 06.05.2010