Старые журналы событий SAP и ORACLE

Сегодня мы поговорим о старых записях в журналах событий процессов SAP и ORACLE.

Процессы ORACLE:

1. Лидером в рейтинге "самый бесполезный и быстрорастущий журнал событий" является лог процесса LISTENER. :) Файл журнала располагается в директории /oracle/<SID>/<ora_version_bit>/network/log и имеет имя - listener.log. В системе с несколькими диалоговыми инстанциями всего за год файл может "распухнуть" до 1,5 Гб!
   
   
   
   
   В Unix-е очистить его очень легко. Достаточно выполнить команду # > listener.log . В Windows придется перезапускать сервис LISTENER, а во время его останова - удалять содержимое файла. Либо поиграться с программа типа unlocker, но сервис для нормальной работы перестартовать потом все равно придётся. Вот тебе и первая выгода (с) ;)
   
   
2. Основной журнал событий базы данных ORACLE - alert_<SID>.log. Место обитания - директория /oracle/<SID>/saptrace/background/. Растет не так быстро, но при долгой работе базы данных имеет размер исчисляемый десятками Мб. Автоматически не обнуляется. Значит этим должны заниматься мы. Какие плюсы от небольшого размера файла? Они очевидны - меньшие требования к дисковому пространству, удобство в анализе. Очищать целиком, право, не стоит: записи в нем, в отличии от предыдущего лога, очень важны. В Windows процедура понятна: останавливаете СУБД, открываете файл текстовым редактором, удаляете лишние строки, сохраняете файл, запускаете СУБД. Как хорошо, что продуктивных систем на Windows все таки не так уж много. ;) В Unix можно поиграться двумя комбинациями команд: wc и split. Первая команда (# wc -l alert_<SID>.log) поможет нам понять сколько всего записей в данном файле. Хорошо бы еще знать дату первой и последней записей. После этого делите файл на части командой # split -line_count alert_<SID>.log. Результат команды - несколько файлов, содержащие по line_count строк из файла alert_SID.log. Анализируете файлы. Содержащие старые ненужные строки удаляете. Оставшийся можно делить еще. В итоге, командой mv заменяете текущий файл alert_<SID>.log полученным укороченным.

Процессы SAP:

1. В системе SAP есть отличный автоматический процесс (задание) под названием CleanUpLogs, который можно (нужно) запланировать в транзакции DB13 с некой периодичностью (например, 1 раз в неделю). Параметры хранения журналов событий и записей указываются либо в профайле init<SID>.dba (в случае использования SAPDBA (версия системы ниже SAP 4.6С)), либо в init<SID>.sap (использование BRTOOLS). Что и как удаляется можно посмотреть в данных профайлах и в журнале выполнения задания в DB13. Информацию можно почерпнуть в нотках - # 204499 и # 403704.
   
   
   
   
   
   
   
   
   
   
2. Если база данных находится в режиме ARCHIVELOG и для создания резервных копий используются утилиты SAP: brbackup/brarchive, то стоит обратить внимание еще на один журнал системы. Это файл /oracle/<SID>/saparch/arch<SID>.log, в котором хранятся записи о том, на какой носитель и когда был скопирован тот или иной оффлайн журнал базы данных ORACLE. Старые записи из этого файла тоже можно почистить. Использовать можно те же способы, что и для файла alert_<SID>.log. 
   
   
3.  Ну и еще можно заглянуть в транспортную директорию - /usr/sap/trans/. Там есть директория log, которую можно проверить на предмет существования в ней старых журналов, которые можно сархивировать в другое место или просто удалить. Ну и директория /usr/sap/trans/EPS/in, в ней хранятся в распакованном виде все пакеты поддержки, которые были установлены на систему или стоят в очереди на установку. Те которые уже были установлены просятся в /dev/null. ;)

Автор: Шиболов Вячеслав Анатольевич