привет коллеги

есть задача настроить аудит и кое-какое логирование изменений таблиц - пришли аудиторы, поругались что крититические таблицы не логируются и непонятно что делал юзер Х 11 месяцев назад и ушли

так как "у нас в Техасе все большое" - надо делать все аккуратно чтобы не взорвать диски, да и перформанс системы далеко не айс

по см20 - очень хочется хранить эти файлы аудита отдельно, так как их хранить нужно год со всех аппл серверов (45 штук). не будет ли проблем с производительностью при таком хранении? Ограничить размеры файлов можно, но например 100М файл "улетает" часа за 4 и получается что задача не решена

по логированию таблиц - есть ли какой-то список таблиц которые вот прям нужно логировать? мне ничего кроме Т000 и Е071* ничего в голову не приходит особо, аудиторы ничего не сказали, а бизнес вроде не требует (не так как в фармаси, где был утвержденный список таблиц штук 50)

клиент rec/client = 1 включать боится - производительность - больной вопрос

спасибо заранее за мнения

День добрый.
Вы бы прислушались к аудитором и сделали как они просят.
Что касается логирования таблиц, чтобы его активировать в DEFAULT.PFL установите параметр профиля rec/client = ALL или rec/client = xxx , где xxx номер продуктивного манданта, разницу понимаете. Тем самым вы активируете аудит изменения для настроечных таблиц а не для всех всех всех. Дальше отслеживаейте рост таблицы DBTABLOG, т.к. все изменения записываются в неё. Не переживайте, на производительности это не скажется, главное следить за ростом таблицы DBTABLOG и в случае чего можно отключить логирование для любой таблицы. Спустя год лишнее в ней можно заархивировать или удалить.
По поводу Аудита безопасности, 100Мб за 4 часа очень много, поэтому меняйте настройки фильтра в sm19, для начала уберите галочки с RFC а потом по мере ненадобности.

Спасибо огромное за ответ, аудиторы никаких конкретных рекомендаций не оставили, в том и дело

настроечные таблицы подвержены очень бодрым изменениям, довольно боль;шие проекты постоянно заливаются в продуктив, поэтому клиент против и хочет выбрать критические таблицы (штук 10-20 макс), а не все что сапом поставляются с галочками, я в общем понимаю - уследить будет сложно, более 20 только продуктивных систем

100Мб за 4 часа - это только критические события

Вы для начала активируйте хотя бы на одной системе, и посмотрите в DBTABLOG по каким таблиц больше всего логов, и если надо отключите для них логирование.
"100Мб за 4 часа - это только критические события" - если это так, то вашей системе "плохо", откройте sm20 и посмотрите что это за события, и если необходимо отключите их в SM19 (Detailed Display).
В любом случае логируйте ТОЛЬКО то что вам нужно, а не то что рекомендуют аудиторы, их задача посчитать активных пользователей. Главное чтобы мультилагон не был включен, а аудит и логирование изменений таблиц по моему не является обязательным условием.

спасибо за ответ

как насчет центрального отдельного хранения аудит логов? какие подводные камни?

Да пожалуйста, настраивайте, создавайте общую папку и указывайте её в качестве в параметре DIR_AUDIT, попутно перепроверьте остальные параметры журналов безопасности.
Если нужна помощь, обращайтесь, мой skype: a.krasovsky

Если свеженький NW, то изучите RAL. Очень полезная вещь!!!
Внедрили по просмотру HR-данных. Все удовлетворены, включая нас, базисников.

всем спасибо за ответы, по результатам тестов -

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

активация параметра rec/client=<prd_client>в "лоб" тоже подпортила жизнь и производительность просела очень сильно - так как Z* таблицы по дефолту поставлялись с галочкой логирования, да и 30 000 таблиц логировать - среди которых вполне есть таблицы с изменяющимися данными - тоже не очень хорошая идея. Список сократили до 20+ таблиц, а у остальных галки поснимали.

как-то так:)