Организация памяти в SAP AS ABAP - II

В первой части статьи про организацию памяти в SAP системе я обрисовал общую картину. Теперь вы знаете, что в SAP системе существует понятие виртуальной памяти, которая состоит из общей (Shared memory) и локальной (Local memory) памяти. Основные области памяти были также обозначены. Продолжим.

Как вы знаете, в SAP системе используется мультиплексирование рабочих процессов. Благодаря этому, ограниченное количество рабочих процессов, в данном случае диалоговых, может обрабатывать запросы большого количества пользователей системы. SAP транзакция разбивается на шаги (их еще называют шагами диалога), которые являются единицами исполнения на рабочих процессах SAP инстанции.

Во время входа в SAP систему каждый пользователь занимает небольшой объем памяти, который называется контекстом или начальным контекстом пользователя. В данном объеме памяти хранятся такие данные, как полномочия пользователя, значения SET/GET параметров и т.п. Во время работы пользователя в системе к его контексту добавляются данные необходимые для работы транзакций, например, номера документов. Логически и физически контекст каждого пользователя хранится в Roll area.

Стоит отметить, что когда пользователь открывает еще одну сессию (режим работы) в рамках одного логина в систему, нажимая в SAP GUI на панели кнопку "Create new session" (рис. 1), то создается еще одна копия контекста пользователя. Обе копии хранят данные отдельно друг от друга.

Рис. 1. Открытие новой сессии.

Все запросы от пользователей (шаги диалога) попадают в очередь к диспетчеру рабочих процессов, или ABAP диспетчеру. Он выбирает свободный рабочий процесс, который будет выполнять шаг диалога конкретного пользователя. Для выполнения шага диалога рабочему процессу необходимы данные текущего пользователя - его контекст. Процесс копирования контекста из Roll area в локальную память рабочего процесса называется roll-in (рис. 2).

Рис. 2. Мультиплексирование рабочих процессов.

После выполнения шага диалога, контекст выгружается из локальной памяти обратно в Roll area. Данный процесс, в свою очередь, называется roll-out. Ну и как я уже упоминал в первой части, Roll area состоит из двух областей - буфер в памяти и физический файл.

Последовательность выделения памяти для шага диалога в рамках рабочего процесса диалога (DIA WP) представлена на рис. 3.

Рис. 3. Выделение памяти для диалогового рабочего процесса.

1. Сначала для пользователя выделяется небольшой объем Roll area, который задается параметром ztta/roll_first. При рекомендуемом значении ztta/roll_first = 1, выделяется минимальный размер: в зависимости от релиза системы это около 100-200 Кб.
2. Если размер контекста пользователя растет, то используется память Extended memory. Тут стоит отметить, что данная память не копируется из Shared области в локальную область рабочего процесса, а выделяется блоками (параметр em/blocksize_KB = 1024 - менять по собственной инициативе не рекомендуется), а в контексте пользователя хранятся только указатели (pointers) на блоки в Extended memory (maping). Это обеспечивает быстрое переключение контекстов (roll-in/roll-out).
3. Если контекст пользователя использует весь объем Extended memory, определенный в квоте на один шаг диалога (параметр ztta/roll_extension), то рабочий процесс начинает снова использовать локальную память в Roll area, до размера квоты, определенной параметром ztta/roll_area.
4. Если рабочему процессу необходимо еще больше памяти, то она выделяется в области SAP Heap memory (локальная память). С данного момента рабочий процесс переходит в PRIV режим (private mode). Это означает, что контекст пользователя не выгружается из рабочего процесса до тех пор, пока не будут выполнены все диалоговые шаги транзакции. Таким образом, данный рабочий процесс выпадает из цикла мультиплексирования и становится персональным для текущего пользователя. Подробности тут.
5. Если рабочему процессу необходимо SAP Heap memory больше, чем сконфигурировано в квоте, определенной параметром abap/heap_area_dia, то программа прерывается с дампом, сообщающем о нехватке памяти.

Данная схема выделения памяти используется в диалоговых рабочих процессах на всех платформах и не-диалоговых рабочих процессах в операционной системе MS Windows.

Для не-диалоговых рабочих процессов в Unix картина несколько иная (рис. 4).

Рис. 4. Схема выделения памяти для не-диалоговых рабочих процессов в Unix.

Так как для не-диалоговых рабочих процессов (например, фоновых заданий или спула) не используется принцип мультиплексирования (то есть программа всегда полностью выполняется на одном рабочем процессе), то не стоит и задачи уменьшения локальной памяти рабочего процесса. Скорее наоборот, необходимо ограничить использование Extended memory не-диалоговыми процессами, оставляя весь объем для диалоговых пользователей. И это прекрасно достигается, использованием схемы, представленной на рис. 4.


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

Ошибка BR255W Cannot read from standard input

На одной из систем в журнале оффлайн бэкапа базы данных в DB13, который выполняется стандартными средствами SAP (утилита BRBACKUP), была постоянная ошибка-предупреждение (рис. 1). На создание резервной копии базы данных ошибка не влияла, но в глаза мне, как перфекционисту со стажем, всё время бросалась.

Рис. 1. Ошибка в DB13.

Несколько попыток решить проблему наскоком, результата не дали. Проблема совершенно не гуглилась и каждый раз я решал, что это какой-то глюк операционной системы MS Windows, на которой установлена система.

В этот раз я обратил внимание на строку, которая идет до сообщения об ошибке, - система запрашивает подтверждения от пользователя перед остановом базы данных (рис. 1). Изучив еще раз тщательно журнал, обнаружил, что в опциях выполняемой команды BRBACKUP есть некоторые пробелы (рис. 2).

Рис. 2. Формат команды BRBACKUP.

Задания, которые мы планируем через "Календарь планирования операций базы данных" (транзакция DB13 или DBACOCKPIT), содержатся в таблице SDBAC. Открыв в транзакции SE16 содержимое таблицы SDBAC с фильтром DBSYS = 'ORACLE', обнаружил интересную картину (рис. 3).

Рис. 3. Записи таблицы SDBAC.

Опции для операции оффлайн бэкапа базы данных без журнальных файлов отличаются от опций всех остальных операций по созданию резервных копий базы данных. Отсутствующая опция '-c force' означает режим без участия пользователя, то есть без подтверждений и вопросов. Подробности об этой опции тут.

Как описано в SAP note # 859450 - Maintenance of the DB13-command table SDBAC, записи в этой таблице можно аккуратно корректировать, не меняя назначение операций в глобальном смысле. Таблица открыта на ведение. Добавляем опции в строку таблицы и сохраняем.

Рис. 4. Изменение записи в таблице SDBAC.

Результат: корректное создание оффлайн бэкапов базы данных без предупреждений и ошибок (рис. 5).

Рис. 5. Выполнение операции без ошибок и предупреждений.

Перфекционист во мне доволен. :)


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

Организация памяти в SAP AS ABAP - I

Данным постом я начинаю цикл статей посвященных производительности SAP систем.

Так как SAP система имеет трехзвенную архитектуру и работает на различных аппаратных и программных платформах, то производительность SAP системы зависит от многих факторов. Можно выделить следующие:

• производительность и утилизация (оптимальное использование) аппаратной части,
• производительность операционной системы,
• производительность базы данных,
• производительность сервера приложений SAP (AS ABAP, AS JAVA) в целом и его частей.

Поговорим о памяти. Как вы знаете, на уровне операционной системы есть два понятия:

• физическая память (оперативная память, ОЗУ) - равна размеру физически установленной памяти в сервер.
• виртуальная память - равна сумме физической памяти и размеру swap области (paging area, файл подкачки). 

Виртуальная память ограничена двумя факторами - размер аппаратных ограничений (сумма физической памяти и swap области) и логические ограничения архитектуры. В 32-х битной архитектуре один процесс может адресовать теоретически максимум 4 Гб (2³²).  В реальности это даже меньше: в зависимости от типа операционной системы - от 2 до 3,8 Гб. Со стороны SAP установка 32-х битных версий на разные операционные системы описана в SAP note 146528 - Configuration of R/3 on hosts with much RAM. В случае 64-х битной архитектуры это число фактически не ограничено (16 Эб). Для использования 64-х битной архитектуры аппаратного обеспечения необходимо, чтобы операционная система, база данных и SAP kernel были 64-х битные. С 2007 года все продукты компании SAP устанавливаются только как 64-х битные с поддержкой Unicode.

На уровне сервера приложений SAP (AS ABAP) выделяют собственное понятие виртуальной памяти, которое включает в себя два вида памяти (рис. 1):

• shared memory - память доступная для всех процессов инстанции SAP AS ABAP,
• local memory - память доступная только для одного рабочего процесса системы.

Рис. 1. Типы памяти в SAP: общая картина.

Shared memory содержит следующие области:

• SAP буферы, которые содержат глобальные объекты для всех пользователей/процессов инстанции. 
• SAP roll memory, которая располагается в двух областях: памяти (Roll buffer) и на уровне файловой системы (SAP roll file). Cодержит начальный контекст пользователя (имя, полномочия, значения по умолчанию и т.д.), который генерируется единожды при входе в систему. 
• SAP paging memory так же состоит из двух частей - область в памяти (Paging buffer) и файл на уровне сервера приложений (SAP paging file). Содержит ABAP объекты (Data clusters и параметры для вызывающих программ и транзакций) во время выполнения операндов вида IMPORT/EXPORT FROM/TO MEMORY, SUBMIT REPORT, CALL TRANSACTION, CALL DIALOG и т.п. 
• Extended memory содержит данные для отдельных пользователей и их запущенных транзакций (внутренние таблицы, списки и т.п.). Даже если пользователь не запустил ни одной транзакции, место в Extended memory он занимает, так как там хранится вторая часть контекста пользователя. 

Local memory содержит следующие области:

• Local memory - локальные области для каждого рабочего процесса, которые содержат, например, SAP cursor cache (хранит и разбирает SQL запросы) и I/O буфер для передачи данных от и до базы данных.
• Heap memory - выделяется по требованию, если рабочему процессу не хватает Extended memory. Освобождается по окончанию шага диалога.

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

С днём знаний!

Поздравляю всех с днем знаний!

Хочу сообщить тем, кто еще не в курсе, что лето закончилось. Да, совсем. Да, больше не завезут. Да, следующее только в следующем году.

Наступил сентябрь. Пора что-то менять, может быть начать что-нибудь новое. Или, хотя бы, освежить память и голову после лета. :)

В связи с этим праздником, как и в прошлом году, я делаю скидку на первый обучающий пакет SAPADM_01. Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до часа Х (а это 23:59 2 сентября 2015 года) я отдам его за 5 000* рублей. 
А тому, кто купит все пакеты (а их на данный момент 5), я так же сделаю скидку, и отдам их все за 20 000** рублей.

Условия акции: 
* - в случае покупки только первого пакета, его надо оплатить в течении сентября, 
** - в случае покупки всех пакетов, обучение надо оплатить в течении 2-х месяцев: сентября-октября.

Подробности про обучение тут.

Скидка только сегодня-завтра. 3-го сентября цена, как на странице с курсами и скидки пройдут. Да, совсем. Да, больше не завезут. Да, следующие только в следующем году. :)

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

История одного долгоиграющего отчёта

Данным постом, я выполняю давно обещанное, но не выполненное. За что приношу свои извинения.

Этот пост написал и просил меня разместить у себя в блоге Дмитрий Бондарев.
Контакты Дмитрия: электронная почта: bdmalex@mail.ru, skype: bdmalex.
Стиль и пунктуация - автора.

История одного долгоиграющего отчёта
... или как сократить срок его выполнения не исправляя ни одной строки ABAP кода

   Существовал в нашей организации SAP ECC 6.0 на HP-UX платформе. И написали по какому-то ТЗ ABAP программисты отчёт дивный, который при запуске колбасил сервер и только после порядка 14 часов работы выдавал результат.

   Ушёл ABAP-программист с чувством выполненного долга в отпуск, и естественно начальство начало задавать вопросы базису: "Почему это работает так долго?".

   Начальственный заход для решения проблемы был простой: добавили в сервер ещё пяток ядер и немного ОЗУ. Запустили отчёт заново – и прослезились, никаких изменений.

   Запускаем отчёт с трассировкой и получаем следующие унылые результаты:

• 98% времени уходит на работу на Сentral Instance (CI),
• 2% времени уходит на работу и взаимодействие с базой данных (DB).

   Так как у нас CI и DB – это 2 разных сервера, я даже слегка расстроился. Мне сначала думалось, что проблема связана с большим временем работы на БД. А стало ясно, что игры с оптимизацией запросов никаких существенных профитов не принесут и оптимизировать надо именно то,что крутится на СI.

   Первый резерв вспомнился навскидку – это класс задания:

Выбираем класс "A" – и задание отрабатывает за 12 часов.
Всего на 7% меньше – но уже приятно!

   Дальше, переходим на сервер приложений и запускаем любимую команду top.
Выясняется, что существенный % времени занимает переключение задания между ядрами процессора. А что будет, если жёстко привязать задание к одному процессорному ядру и заставить его работать только там. Зачем тратить драгоценное время на скачки с одного ядра на другое?
Заходим сразу после запуска задания в SM66 (или SM50, ну в общем это дело вкуса) и выясняем необходимый нам PID (идентификатор процесса). Далее на HP-UX под нашим любимым пользователем <sid>adm  запускаем команду:

 > mpsched –c номер_процессорного ядра  –p PID 

   Смотрим результат: отчёт отработал за 10 часов.

Для других *nix-платформ команды привязки следующие:

• bindprocessor для AIX
• psrset для Solaris
• taskset (+ chrt) для Linux

   В принципе, на этом можно было бы успокоиться, но ведь аппетит всегда приходит во время еды? Что ещё можно сделать, чтобы ускориться?

   Ну, а почему бы не повысить приоритет нашему процессу. Запускаем:

 > renice –n +20 –p PID 

   Смотрим результат: отчёт отрабатывает за 8 часов.

   Вот таким, совсем нехитрым способом, можно ускорить выполнение любого отчёта на многопроцессорной машинке с HP-UX (и не сомневаюсь, что аналогично можно сделать на любой *nix платформе, разве что запускаемые команды будут отличаться названием). В моём случае выигрыш составил порядка 42%, что на мой взгляд – вполне осязаемая и ощутимая величина.

Автор: Дмитрий Бондарев (e-mail: bdmalex@mail.ru, skype: bdmalex)

HP-UX. Многоликая команда find

Командная строка операционной системы Unix, в данном случае HP-UX, очень удобный и мощный инструмент, если уметь им пользоваться.

В этом посте я писал, как настроить командную строку в HP-UX.
А тут я давал ссылку на краткую справку по текстовому редактору VI. Совершенно несложно освоить основной набор команд и не бояться работать в операционной системе. Я иногда, чисто машинально, пытаюсь использовать команды VI в блокноте операционной системы Windows. :)

Сегодня я хотел бы привести несколько комбинаций использования команды find в HP-UX, которые могут быть полезны.

Итак, первый вариант позволяет найти все файлы с именем core на сервере:

 # find / -type f -name core -exec ls -l {} \; 

Здесь первая опция указывает где производить поиск, вторая - выбирать только простые файлы, третья - шаблон для поиска имени файла, опция "-exec" позволяет выполнять команду с найденными файлами. В данном случае это просто вывод списка найденных файлов.

Второй вариант - поиск файлов больше определенного размера:

 # find ./ -type f -size +100000000c -exec ls -al {} \; 

 В данном случае поиск осуществляется в текущей директории, выборка идет только простых файлов, размером больше 100 Мб (опция -size +1000000000c). Полученный список отображается на экране (рис. 1).

Рис. 1. Результаты работа команды find.

 
Если необходимо удалить файлы (лучше всего с подтверждением для каждого файла), то использовать команду вида:

  # find ./ -type f -size +100000000c -exec rm -i {} \; 

Ну и последний полезный, на мой взгляд, вариант:

 # find ./ -type f -mtime +365 -exec ls -al {} \; 

В данном случае, команда выведет на экран список "старых" файлов, которые не модифицировались год (то есть дата модификации больше 356 дней).

Другие опции команды в документации man.

Если у вас есть свои полезные комбинации, пишите в комментариях.

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

Гомогенное копирование системы SAP R/3 4.6C

В цикле постов про копирование SAP систем я уже рассказывал про основные этапы гомогенного копирования системы. Этому был посвящен вот этот пост. Там же была ссылка на инструкцию по гомогенному копированию системы SAP ERP 6.0 на платформе MS Windows 2003/Oracle 10g.

Данный пост относится к той же теме, но его еще можно назвать ностальгии-постом. :) Посмотрите на сриншот. Администраторы, которые воюют работают с системами компании SAP 10 лет или более, я уверен, сразу узнают его и пустят скупую слезу. :) Это утилита SAPINST, которая являлась лишь графическим окном к процессу установки системы - процессу R3SETUP.

Итак, сегодня я добавляю в свою коллекцию инструкций - инструкцию по гомогенному копированию системы SAP R/3 4.6С SR2 на платформе HP-UX 11.11 и ORACLE 8.1.7.

Особенности:

• полностью описан процесс подготовки операционной системы HP-UX 11.11 к установке SAP системы и базы данных ORACLE.
• приведена процедура по работе с программой установки системы SAP R/3 4.6C на операционную систему HP-UX.
• в инструкции раскрыта процедура установки СУБД ORACLE 8.1.7 и обновлению её до версии 8.1.7.4.
• описана процедура переноса базы данных ORACLE с использованием утилиты R3COPY и оффлайн бэкапа базы данных.
• указаны шаги по пост-установочной настройке системы.
• приведен список необходимых документов и SAP нот для установки и гомогенному копированию системы.

Данная версия системы до сих пор используется на некоторых предприятиях. Прекрасно работает и помогает им автоматизировать их финансово-хозяйственную деятельность. Хотя администрировать и поддерживать такие системы с каждым годом всё сложнее и страшнее. :)

Подробная инструкция (34 страницы) доступна по этой ссылке (zip-архив, 1540 Кб).

Я думаю, что данная инструкция поможет не только при гомогенном копировании, но и при установке системы SAP R/3 4.6C с нуля. В сети по таким старым вещам информации все меньше и меньше. Так что, надеюсь, что кому-то пригодится. :)

Страница со всеми инструкциями как всегда была оперативно обновлена.


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