Как проверять активность базы данных без проблем с производительностью и масштабируемостью?

Question

Мне нужно провести аудит всей активности базы данных, независимо от того, исходила ли она из приложения или кто-то выдавал SQL-запрос другими способами.Поэтому аудит должен проводиться на уровне базы данных.Речь идет о базе данных Oracle.Я рассматривал возможность сделать это с помощью триггеров, а также с помощью так называемого детального аудита, который предоставляет Oracle.В обоих случаях мы включили аудит конкретных таблиц и определенных столбцов.Однако мы обнаружили, что производительность действительно падает, когда мы используем любой из этих методов.

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

Answer 1

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

Отправьте необработанные данные между приложением и базой данных на другую машину, декодируйте и проанализируйте их там.

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

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

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

Answer 2

Не надо «раскачивать свое».Просто включите аудит:

1. Установите параметр базы данных AUDIT_TRAIL = DB.
2. Запустите экземпляр.
3. Войдите с помощью SQLPlus.
4. Введите заявление

   audit all;

   Это включает аудит для многих важных операций DDL, но DML и некоторые другие операторы DDL по-прежнему не проверяются.
5. Чтобы включить аудит этих других действий, попробуйте использовать такие утверждения:

   audit alter table; -- DDL audit
   audit select table, update table, insert table, delete table; -- DML audit

Примечание:Вся активность «как sysdba» ВСЕГДА проверяется на операционной системе.В Windows это означает журнал событий Windows.В UNIX это обычно $ORACLE_HOME/rdbms/audit.

Проверьте Глава аудита Oracle 10g R2 Справочника по SQL базы данных.

Журнал аудита базы данных можно просмотреть в представлении SYS.DBA_AUDIT_TRAIL.

Следует отметить, что внутренний аудит Oracle будет высокопроизводительным по определению.Он предназначен именно для этого, и очень трудно представить себе что-либо еще, конкурирующее с ним по производительности.Кроме того, существует высокая степень «детального» контроля аудита Oracle.Вы можете получить это настолько точно, насколько захотите.Наконец, таблицу SYS.AUD$ вместе с ее индексами можно переместить в отдельное табличное пространство, чтобы предотвратить заполнение табличного пространства SYSTEM.

Добрые пожелания, опус

Answer 3

Если вы хотите записать копии измененных записей в целевой системе, вы можете сделать это с помощью Golden Gate Software и не понести больших затрат на утечку ресурсов на стороне источника.Также вам не нужно вносить какие-либо изменения в исходную базу данных для реализации этого решения.

Golden Gate очищает журналы повторов на предмет транзакций, ссылаясь на список интересующих вас таблиц.Эти изменения записываются в «файл следа» и могут быть применены к другой схеме в той же базе данных или отправлены в целевую систему и применены там (идеально для снижения нагрузки на исходную систему).

После того, как вы доставите файл следа в целевую систему, вы можете внести некоторые изменения в конфигурацию, вы можете установить опцию для выполнения аудита и, если необходимо, вы можете вызвать 2 функции Golden Gate, чтобы получить информацию о транзакции:

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

2) Если к вашим записям еще не прикреплены CHANGED_BY_USERID и CHANGED_DATE, вы можете использовать функции Golden Gate на целевой стороне, чтобы получить эту информацию для текущей транзакции.Ознакомьтесь со следующими функциями в Справочном руководстве GG:Ggheader ("userid") ggheader ("timeStamp")

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

Answer 4

если вы используете oracle, то есть функция CDC (захват изменения данных), которая является более эффективным решением для требований аудита.