пятница, 29 января 2016 г.

Лучшие авторы SAPLand за 2015 год: награждение

Ссылка на статью
Как вы знаете, я кроме этого блога, веду еще колонку на портале SAPLand.
В конце прошлого года портал проводил голосование на звание лучших авторов 2015 года. 

Я просил вас проголосовать по мере возможности. :) Еще раз спасибо за ваш голос.

В итоге, я был выбран в качестве одного из трёх лучших авторов портала и в этом году получил своё вознаграждение. 


Наградой стал памятный кубок "Лучший автор SAPLand 2015 года", 3 книги издательства SAP-PRESS (одна в бумажном виде, 2 в электронном) и на выбор любой SAP семинар в учебном центре SAP в течении 2016 года. 

Хороший стимул работать и развиваться дальше. :) 
Спасибо, что читаете мой блог.

четверг, 28 января 2016 г.

Буферизация таблиц на уровне сервера приложений SAP - I

Ссылка на статью
Как я уже писал, для увеличения быстродействия каждая SAP инстанция использует механизм буферизации. Группа буферов хранит скомпилированные ABAP-loads программ, экраны, определения таблиц и полей, временные данные. Это позволяет существенно ускорить выполнение программ на уровне сервера приложений.

Вы уже знаете, что буферы на уровне сервера приложений SAP подразделяются на системные, буферы для объектно-ориентированных приложений и табличные. ABAP-программы читают данные из таблиц системы и, последний класс буферов, табличные, позволяет на порядок снизить время обращения к данным. Следует различать буферизацию таблиц на уровне базы данных и на уровне серверов приложений (рис. 1).

Рис. 1. Буферизация таблиц в SAP системе.

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

На уровне сервера приложений SAP выделяют три типа буферизации:
  • Полная буферизация - при первом обращении к данным таблицы, всё её содержимое копируется в Table buffer. Стоит учитывать, что для манданто-зависимых таблиц, выборка будет производится только по ключу текущего манданта. Используется только для маленьких таблиц.
  • Буферизация по ключу (Generic area buffering) - в этом случае, устанавливается количество ключевых полей, по которым будут копироваться данные в буфер. 
  • Буферизация единичных записей (Single record buffering) - каждая запрашиваемая запись отдельно буферизируется на уровне SAP инстанции. Используется только при SQL-запросе, содержащем слово "SINGLE". Например, "SELECT SINGLE * FROM TABL01 WHERE ...". При запросе несуществующих записей, создает записи об этом, что сокращает время работы и нагрузку на базу данных при повторных запросах.

Буферизация настраивается для каждой SAP таблицы в отдельности. На экран настройки можно попасть через транзакцию SE11 (на панели кнопка "Technical Settings") (рис. 2) или напрямую в транзакции SE13.

Рис. 2. Переход на экран настройки буферизации для таблицы.

Буферизация таблицы может быть запрещена (рис. 3), разрешена и активирована по ключу (рис. 4), по отдельным записям или полная (рис. 5).

Рис. 3. Пример не разрешенной буферизации SAP таблицы.

Рис. 4. Пример настройки буферизации по одному ключевому полю.

Рис. 5. Пример полной буферизации SAP таблицы.

С технической стороны буферизация SAP таблиц реализована в виде двух буферов в оперативной памяти сервера приложений AS ABAP (рис. 6).

Рис. 6. Два вида табличных буфера SAP инстанции.

Мониторинг использования осуществляется в транзакции ST02. Каждый буфер имеет размер и максимальное количество записей (рис. 7).

Рис. 7. Табличные буферы в транзакции мониторинга буферов, ST02.

Настройка осуществляется через параметры SAP инстанции, которые можно найти, нажав в верхней панели основного экрана транзакции ST02 кнопку "Current parameters" (рис. 8).

Рис. 8. Параметры SAP Table Buffers.

При мониторинге следует руководствоваться рекомендациями:
  • Точность Generic Key Buffer должна быть не ниже 95 % (в идеале 99 %).
  • Если для Single Record Buffer не наблюдается появление swaps, то точностью можно пренебречь.

Буферизацию стоит активировать при следующих условиях:
  • данные в таблице редко изменяются,
  • к данным в таблице идёт частое обращение,
  • таблица меньше 1 Мб,
  • в большинстве случаев доступ производится по первичному ключу,
  • таблица хранит настроечные данные. 

Настройки буферизации для стандартных таблиц следует изменять только при прямой рекомендации в SAP нотах. При активации буферизации для таблиц клиента следует проанализировать объем буферов, при необходимости, скорректировав их размер.

При использовании следующих SQL-операндов буферизация не используется (Code Inspector предупреждает при проверки кода программы):
  • SELECT ... BYPASSING BUFFER,
  • SELECT FOR UPDATE,
  • SELECT DISTINCT,
  • сортировка ORDER BY не по первичному ключу,
  • использование функций вида: MIN, MAX, COUNT, SUM, AVG,
  • когда условие WHERE содержит IS NULL или IS NOT NULL,
  • Native SQL запросы.

В следующем посте будут освещены методы анализа проблем в буферизации таблиц на уровне сервера приложений SAP.


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


понедельник, 18 января 2016 г.

Что такое SAP System Identificator (SAPSID)

Ссылка на статью
Каждая SAP система идентифицируется через "SAP System Identificator", который должен быть уникальным в рамках одного ландшафта.

Сокращенно "SAP System Identificator" записывается как SAPSID или просто SID.  

SAPSID представляет собой три символа. Первый символ идентификатора должен быть латинской буквой, второй и третий могут быть, как латинской буквой, так и цифрой. Например, ET1, E12, ETS.

На уровне базы данных есть идентичный идентификатор, который, для того, чтобы не путать с уровнем SAP, в документации обозначается как DBSID.

DBSID и SAPSID теоретически могут не совпадать, но для удобства идентификации уровней SAP и базы данных, а так же администрирования, рекомендуется устанавливать их одинаковыми.

SAPSID задается при установке любой SAP системы (исключение Trial системы) администратором. Для удобства идентификации систем я рекомендую использовать своё кодирование. Как вы знаете, типовой SAP ландшафт представляет собой три системы: система разработки и настройки (DEV), система тестирования или контроля качества (QAS) и продуктивная система (PRD) (рис. 1). Каждая система имеет свой уникальный идентификатор. Часто в продуктивной системе уровень приложений усиливают дополнительными  диалоговыми инстанциями, которые всё равно имеют общий SAPSID (об этом я писал тут).

Рис. 1. Типовой SAP ландшафт.

Рассмотрим как можно закодировать назначение систем в SAPSID. Например, предприятие, которое будут обслуживать системы ландшафта называется "Газмясвагонстекломаш". Системы будут выполнять стандартные функции - DEV, QAS и PRD. Ландшафт ERP систем можно закодировать через SAPSID=DBSID следующим образом: GDE, GQE и GPE. Здесь первый символ от названия предприятия, второй от назначения системы (DEV, QAS, PRD), а последний служит идентификацией ERP системы. Ландшафт BI систем будет кодироваться: GDB, GQB и GPB соответственно. Вы можете выбрать любую другую схему кодирования. Главное, чтобы она была.

Для SAPSID существует набор запрещенных комбинаций. Например, ADD, ADM, ALL, AMD, AND, ANY, ARE, ASC, BIN, BIT, COM, CON, DBA, DBO, DTD, END, EPS, EXE, FOR, GET, GID, IBM, INT, KEY, LOG, LPT, LIB, MAP, MAX, MEM, MIG, MIN, MON, NET, NIX, SAP, SID, SQL, USR, VAR и т.д. Все они с описанием приведены в SAP note # 1979280 - Reserved SAP System Identifiers (SAPSID) with Software Provisioning Manager 1.0
Самое интересное, что комбинации DEV, QAS и PRD не запрещены. :) Но я бы использовать их не стал.

Большинство комбинаций будут забракованы на этапе установки системы. Например, в SAP Software Provisioning Manager 1.0 (рис. 2 и 3).


Рис. 2. Ввод SAPSID на этапе установки SAP системы.

Рис. 3. Сообщение об ошибке в SWPM.

В дальнейшем SAPSID и DBSID могут быть изменены, например, через SWPM (пункт "System Rename"). Но так как процедура по своей сути идентична гомогенному копированию системы, выбирайте SAPSID раз и навсегда. :)


понедельник, 11 января 2016 г.

SAP Program buffer

Ссылка на статью
Общие сведения про буферизацию на уровне SAP инстанции я описывал в этом посте:

Продолжим.

Исполняемую часть ABAP стека SAP системы можно разделить на 2 компоненты:
  • ядро (SAP Kernel), написанное на языке C++, 
  • программы, написанные на языке ABAP.

SAP Kernel представляет собой набор исполняемых файлов зависимых от платформы, на которой работает текущая SAP система. Под платформой подразумевается связка "архитектура сервера - операционная система - база данных". Например, "сервер HP PA_RISC 64 bit - ОС HP-UX 11.31 64 bit - БД ORACLE 11g".
Поддерживаемые платформы для каждой SAP системы можно найти в PAM (подробности в этом посте).

ABAP программы поставляются в виде исходных кодов и хранятся в таблицах базы данных. Для примера можно посмотреть таблицу REPOSRC - это основная таблица для исходных кодов программ.

В SAP есть своя внутренняя нумерация платформ (в данном случае, версия базы данных не учитывается). Платформу текущей системы можно найти, если в SAP GUI перейти в пункт меню "System -> Status" (рис. 1).

Рис. 1. Платформы SAP систем.

Для того, чтобы рабочий процесс SAP инстанции ("ABAP процессор") мог выполнить код ABAP программы, необходимо для неё сгенерировать ABAP load. ABAP loads генерируются для каждой платформы (Platform ID). Если программа ни разу не запускалась в данной SAP системе или текущий ABAP load был сгенерирован для другой платформы, то при запуске программы будет затрачено время на автоматическую генерацию ABAP load, а в строке состояния будет соответствующее сообщение (рис. 2).

Рис. 2. Генерация ABAP program load.

Обычно SAP система работает на одной платформе, но в случае гетерогенной среды, когда сервера приложений расположены на разных платформах, генерируемый объём ABAP loads будет выше, так как в системе будут одновременно храниться ABAP loads для разных платформ.

Возможна централизованная массовая генерация ABAP loads с помощью SAP Load Generator (транзакции SGEN). Подробности можно найти в справке или в SAP note # 481548 - Mass generation for new load format.

Рабочий процесс считывает ABAP loads из специального буфера SAP инстанции, который называется Program bufferProgram Execution Area (сокращенно PXA) или просто ABAP buffer. Буферизация позволяет существенно снизить время доступа к программам при выполнении. Все SAP буферы создаются в рамках одной инстанции.

Рабочие процессы могут считывать ABAP loads только из этого буфера. Если место в буфере заканчивается, то последний используемый load удаляется (для выборки используется алгоритм LRU). Такое удаление фиксируется, как swaps.

Мониторинг программного буфера осуществляется посредством транзакции ST02 (рис. 3).

Рис. 3. Мониторинг Program Buffer в ST02.

По двойному щелчку на строку с именем буфера можно посмотреть детали (рис. 4).

Рис. 4. Детальная информация по Program Buffer в ST02.

Если нажать последовательность кнопок "Buffered objects -> PXA buffer technical", то можно увидеть список ABAP loads, содержащихся в буфере (рис. 5).

Рис. 5. Список программ в Program Buffer.

Большинство программ имеют небольшой размер (до 8 Кб), но потенциальный размер всех ABAP loads SAP системы может быть очень большим (несколько Гб). Поэтому, не смотря на большой размер PXA буфера (например, 1000 Мб), могут наблюдаться swaps. При невозможности увеличить размер буфера допускается до 10 000 swaps в день. Такое количество swaps не приводит к сильному провалу производительности системы.

За размер буфера отвечает один параметр - abap/buffersize (рис. 6). Размера буфера указывается в Кб, а максимальное количество объектов в буфере (Directory Size) рассчитывается как четвертая часть от размера. Например, при размере буфера 640 000 Кб, Directory Size - 160 000 (рис. 3).

Рис. 6. Параметры настройки Program Buffer.

Точность буфера (HitRatio) должна быть не меньше 95 %, иначе вырастет доля "load and generation time" во времени отклика системы. Точность может уменьшаться при импорте новых исходников ABAP программ (особенно, при импорте пакетов поддержки или апгрейде системы) или при смене платформы, на которой работает SAP система. 

Так как Program buffer очень важен для производительности системы, существует механизм сохранения точности при перезапуске системы. В случае выключения системы текущий список программ сохраняется в специальный файл (pxanew) в рабочей директории инстанции (/usr/sap/<SID>/<instance_name>/work). На случай аварийного останова системы есть файл pxastat в той же директории. При старте SAP системы считывается список программ из локального файла и происходит наполнение Program buffer. Подробности можно найти в SAP нотах 23642 - Description of pxanew and pxastat и 1122370 - Only a few programs loaded in PXA after server start.

Еще пара тематических SAP нот: