Аудит в Oracle

Question

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

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

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

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

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

Answer 1

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

Оракул предлагает гибкие и мелкозернистые услуги аудита. Посмотрите на this document (9i) в качестве отправной точки. (. Edit: Вот ссылка для 10g и 11g версий одного и того же документа)

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

Answer 2

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

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

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

1. Это не масштабируется (одно обновление прикасаясь десять колонн нерестится десять вставок)
2. Что о том, когда вы вставляете запись?
3. Это полная боль, чтобы собрать состояние записи в любой момент времени

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

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

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