Пример проблемы при переполнении файловой системы

Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (troubleshooting). Утром одна из систем была обнаружена в недоступном для пользователей состоянии. Анализ показал, что инстанция SAP запущена, а база данных Oracle нет. После старта базы данных система стала доступна для работы, а последующий анализ показал, что не завершился ночной оффлайн бэкап базы данных. Про резервное копирование я писал в посте "Резервное копирование SAP системы". 

Так как при оффлайн резервировании база данных Oracle на время копирования данных останавливается, то утром она была обнаружена как раз в остановленном состоянии.

Анализ журналов копирования показал ошибку при старте базы данных после резервирования: при записи журналов не хватило места на какой-то файловой системе сервера (рис. 1).

Рис. 1. Ошибка в журнале оффлайн резервирования базы данных Oracle.

Тут стоит вспомнить один из моих недавних постов "Анализ места на диске в Unix". Вооружившись советами из статьи и командами bdf и du, можно легко обнаружить, что в домашней директории Oracle закончилось свободное пространство. Много места занимает директория с журналами (log), а именно журнал процесса Listener (рис. 2 и 3).

Рис. 2. Вывод команды bdf.

Рис. 3. Анализ размера директорий в файловой системе.

Тут опять же, стоит вспомнить пост "Старые журналы событий SAP и ORACLE", в котором я упоминал про этот журнал. Данный журнал хранит информацию о соединениях процессов SAP с Oracle. Смело очищаем и высвобождаем место (рис. 4).

Рис. 4. Удаление содержимого журнала listener.log.

После этого проблема решена. 

Стоит отметить, что при настроенном мониторинге (например, через CCMS мониторинг) такой проблемы бы не возникло. 

Первая задача администратора: сделать так, чтобы всё заработало. 

Вторая задача: разобраться в ситуации, выяснить причины ошибки и выполнить шаги, чтобы не допустить повторение ошибки в будущем. 

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

Старые журналы событий 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. ;)

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