среда, 28 ноября 2012 г.

Утилита DPMON

Ссылка на статью
Как я уже говорил в посте про SAP Management Console, в данной утилите, как и в SAP MMC в MS Windows Server, можно, помимо всего прочего, осуществлять мониторинг рабочих процессов (WPs) ABAP инстанции SAP системы на уровне операционной системы.

Иногда это бывает жизненно необходимо. Например, в ситуации, когда заняты все диалоговые рабочие процессы инстанции, вход в систему затруднен. В данном случае, время отклика системы огромно, так как запросы "толкаются" в очереди ABAP-диспетчера. И часто список процессов операционной системы не дает представления о причинах проблемы - процессоры сервера, на котором работает диалоговая инстанция, могут быть не загружены. А в увеличенном времени отклика инстанции могут быть виноваты "тяжелые" процессы к базе данных, которые удерживают диалоговые рабочие процессы диалоговой инстанции за пользователями. Известно, что SAP ABAP инстанции используют принцип мультиплексирования рабочих процессов, что позволяет большему количеству пользователей работать на инстанции с меньшим количеством рабочих процессов. Тут этот принцип может дать сбой и пользователям будет не хватать свободных диалоговых рабочих процессов.

Итак, как еще можно достучаться до таблицы рабочих процессов с уровня операционной системы? В файлах SAP ядра есть утилита DPMON, которая запускается из-под пользователя <sid>adm командой вида:
 > dpmon nr=04 
или
 > dpmon pf=/usr/sap/<SID>/SYS/profile/<SID>_D04_hostname 
здесь 04 - номер диалоговой инстанции, а <SID>_D04_hostname имя её профиля.

Утилита имеет небольшое меню (рис. 1), через которое можно просмотреть статистику очереди диспетчера (рис. 2), таблицу рабочих процессов инстанции (рис. 3), остановить тот или иной рабочий процесс, дабы освободить ресурсы системы и дать остальным пользователям поработать и так далее.

Рис.1. Меню утилиты DPMON.

Рис. 2. Статистика очереди ABAP диспетчера.

Рис. 3. Таблица рабочих процессов ABAP инстанции.

Утилита доступна для всех SAP систем с ABAP стеком и всех операционных систем. В новой версии (на снимках экрана система SAP R/3 4.6C) может немного отличаться в лучшую сторону. Например, добавлением функций для мониторинга J2EE инстанции.

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


четверг, 22 ноября 2012 г.

Журнальные файлы Oracle и archivelog mode. Часть II.

Ссылка на статью
В первой части поста я остановился на онлайн журнальных файлах. Продолжим.

Онлайн журнальные файлы используются по кругу (рис. 1).

Рис. 1. Запись в онлайн журнальные файлы ORACLE.

После того, как полностью заполнен онлайн журнал группы G11, начинается запись в журнал группы G12 и так далее, пока не дойдет до группы G14. После использования последней группы, процесс записи должен переключиться на первый журнал и начать запись в него. И тут есть 2 варианта. Дело в том, что экземпляр ORACLE может работать в двух режимах:
  • ARCHIVELOG MODE,
  • NOARCHIVELOG MODE,


вторник, 20 ноября 2012 г.

понедельник, 12 ноября 2012 г.

Журнальные файлы Oracle и archivelog mode. Часть I.

В структуре базы данных ORACLE, которая представлена на рисунке 1, можно выделить 3 крупные части:
  • процессы,
  • области в оперативной памяти,
  • файлы на жестком диске.
Рис.1 Структура СУБД ORACLE.
Выделяют 2 вида процессов. Первый - это фоновые процессы, которые запускаются всегда при запуске экземпляра (инстанции) и выполняют огромное количество операций по обслуживанию базы данных, очистки, журналированию, восстановлению и так далее. Второй тип - это, так называемые, "shadow processes", которые создаются в количестве равном количеству рабочих процессов SAP инстанций, работающих с этим экземпляром базы данных. Они-то и обрабатывают SQL запросы к базе данных со стороны SAP системы.
Также еще есть, отдельно стоящий, процесс сетевого слушателя (ORACLE Listener), который "слушает" определенный сетевой порт (в случае SAP системы, по умолчанию это 1527) и обеспечивает соединение к экземпляру базы данных извне.

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

Ну и наконец, файлы базы данных. Это прежде всего профиль - файл, который используется для инициализации экземпляра базы данных при запуске. Содержит набор параметров и указатели на важные директории базы данных. Хранится и имеет название:
/oracle/<SID>/<ora_version>/database/SPFILE<SID>.ORA.
Контрольный файл базы данных, который содержит структуру базы данных. Очень важен для целостности экземпляра, поэтому хранится в 3 экземплярах. Одну копию можно обнаружить тут - /oracle/<SID>/origlogA/cntrl/CNTRL<SID>.DBF.
Самый большой объем занимают файлы с данными, которые логично распределены между табличными пространствами экземпляра. По-умолчанию, расположены в директориях вида /oracle/<SID>/sapdataX.
Журнальные файлы ORACLE делятся на онлайн и оффлайн. Остановимся на них подробнее.

В журнальные файлы ORACLE записывает все операции, которые производятся с файлами данных. Таким образом, если произойдет сбой, то ORACLE при восстановлении экземпляра сможет повторить все операции с данными в той же последовательности, как это происходило во времени до сбоя. Данные файлы очень важны для работы базы данных, поэтому за ними нужен "глаз да глаз".

По-умолчанию, при создании экземпляра базы данных для SAP системы организуется 4 группы журнальных файлов размером по 50 Мб с дублированием (зеркалированием) каждого. Онлайн журнальные файлы распределены по 4 директориям:
/oracle/<SID>/origlogA/
             LOG_G11M1.DBF
             LOG_G13M1.DBF
/oracle/<SID>/origlogB/
             LOG_G12M1.DBF
             LOG_G14M1.DBF
/oracle/<SID>/mirrlogA/
             LOG_G11M2.DBF
             LOG_G13M2.DBF
/oracle/<SID>/mirrlogB/
             LOG_G12M2.DBF
             LOG_G14M2.DBF
Здесь видно 4 группы G11, G12, G13, G14 с двумя копиями M1 и M2 в каждой.
Данные директории рекомендуется распределять по разным файловым системам с RAID1 или RAID1+0  для приемлемого уровня отказоустойчивости и быстродействия.

Продолжение следует...

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