Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (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 мониторинг) такой проблемы бы не возникло.
Первая задача администратора: сделать так, чтобы всё заработало.
Вторая задача: разобраться в ситуации, выяснить причины ошибки и выполнить шаги, чтобы не допустить повторение ошибки в будущем.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий