Сброс буферов SAP инстанции

В 2015-2016 годах я публиковал цикл из 5 статей про буферизацию на уровне сервера приложений SAP. Если вы ещё не читали, то рекомендую ознакомиться. Финальный пост и ссылки на предыдущие статьи серии можно найти тут. 

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

Рис. 1. Пример списка буферов SAP инстанции, отображаемых в транзакции ST02.

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

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

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

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

• /$SYNC - сброс всех буферов, кроме Program Buffer,
• /$CUA - сброс CUA buffer,
• /$TAB - сброс TABLE buffer (в зависимости от версии системы: двух или одного),
• /$TAB <table_name> - сброс буферов только для таблицы <table_name>,
• /$NAM - сброс Nametab buffer,
• /$DYN - сброс Screen buffer,
• /$ESM - сброс Exp./ Imp. Shared Memory Buffer,
• /$PXA - сброс Program Buffer (PXA),
• /$OBJ - сброс Shared Buffer.

Команды сброса надо набирать в поле ручного ввода транзакции в SAP GUI (рис. 2). Действуют они только на текущую инстанцию. 

Рис. 2. Ввод команды для сброса табличных буферов SAP инстанции.

Про последнюю команду (/$OBJ) в прошлый раз я не упоминал. Она добавилась. Дополнительное упоминание про сброс этого буфера можно найти в SAP note # 100923 - Problems during displacement in the shared buffer.

При принятии решения о сбросе буферов инстанции помните, что: 

• Сброс буферов резко снижает производительность работы данной инстанции.
• Сброс буферов (также как и рестарт инстанции) может помочь привести систему в порядок, но первопричину сбоя таким способом вы не решите. 
• Делайте сброс только понимая что вы делаете. 
• Постарайтесь выявить конкретный буфер и сбросить только его, а не все буферы сразу (/$SYNC). 

Дополнительно существует возможность сбросить буфер полномочий для пользователя. Вот в этом посте я рассказывал про то, как с помощью транзакции SU53 проанализировать каких полномочий не хватает пользователю в SAP системе. А вот тут рассказывал про буфер полномочий, который хранится в контексте пользователя. В SU53 можно сбросить этот буфер: выберете пункт меню "Значения полномочий (Authorization values) -> Сбросить буфер пользователя (Reset User Buffer)" и буфер текущего пользователя сбросится (рис. 3).

Рис. 3. Сброс буфера полномочий для пользователя.

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

P.S. Я понимаю, что я могу знать далеко не всё. Если у вас есть дополнения по этой теме, то напишите в комментарии. Спасибо.

SAP буферизация. Заключение

На уровне сервера приложений SAP AS ABAP существует механизм буферизации. Этот механизм я описал в 4 постах:

• SAP буферизация: общие сведения - описаны типы буферов, инструменты мониторинга и настройки, а также общие рекомендации.
• SAP Program buffer - генерация ABAP loads, параметры настройки SAP Program buffer (PXA), рекомендации по производительности.
• Буферизация таблиц на уровне сервера приложений SAP - I - виды буферизации таблиц, мониторинг, настройка.
• Буферизация таблиц на уровне сервера приложений SAP - II - проблемы табличного буфера в SAP, синхронизация буферов, использование транзакции ST10.

Как вы помните из первого поста про память, на уровне инстанции SAP системы выделяют две области памяти: Shared Memory (память доступная для всех процессов) и Local Memory (индивидуальные области памяти для каждого рабочего процесса). Буферы SAP системы являются частью Shared Memory (рис. 1).

Рис. 1. Области памяти в SAP AS ABAP инстанции.

На уровне операционной системы (UNIX) области SAP Shared Memory создаются как отдельные единицы и имеют порядковый номер. Возможно их объединение в пулы, и, в этом случае, на уровне операционной системы выделяется одна область Shared Memory - пул (pool). Пулы также имеют порядковый номер. Мы, как администраторов SAP системы, можем использовать только пулы с номерами 10 и 40.

Для настройки областей SAP Shared Memory и пулов используются параметры вида:

ipc/shm_psize_nn = значение 

Здесь nn - номер области или пула (обязательно две цифры). Например, ipc/shm_psize_07.

Если значение параметра равно "0", значит данная область исключена из пула. Например, ipc/shm_psize_13 = 0 означает, что 13 область исключена из 10 пула.

Если значение отрицательное, то это означает, что данная область включена в пул, номер которого указан в значении. Например, ipc/shm_psize_33 = -10 означает, что область с номером 33 перенесена в 10-й пул.

Положительное значение возможно только для пулов (10 и 40) и указывает их размеры в байтах.

Посмотреть все области можно в транзакции ST02, если перейти по пути "Detail analysis menu -> Storage -> Shared memory detail" (рис. 2).

Рис. 2. Список Shared Memories с номерами.

В поле "Key" указан номер области. На этом экране так же можно увидеть какие области входят в 10 и 40 пулы.

В данном примере параметры пулов следующие (рис. 3).

Рис. 3. Размеры Shared Memory Pools.

В этом и этом постах я уже упоминал про использование утилиты sappfpar. С её помощью можно проверить профиль инстанции (и соответственно, всю инстанцию) на корректность конфигурации памяти. Как я уже упоминал, программа входит в состав SAP Kernel и может быть вызвана с уровня операционной системы командой вида:

 # sappfpar pf=/usr/sap/<sid>/SYS/profile/<instance_profile> check

В результатах работы программы можно найти список всех областей SAP Shared Memory с размерами и номерами, а также рекомендации по размерам пулов 10 и 40 (рис. 4).

Рис. 4. Проверка профиля инстанции утилитой sappfpar.

Если программа выявит некорректные значения, то выдаст сообщения об ошибках и рекомендации (рис. 5).

Рис. 5. Рекомендации по конфигурации памяти от утилиты sappfpar.

Такая организация/конфигурация используется во всех Unix системах. В SAP note # 1137734 - Assignment of memory areas, shared memories and pools можно найти подробности, а во вложении списки областей SAP Shared Memory для каждой операционной системы.  

Стоит отметить, что конфигурация данных областей, кроме 10 и 40 пулов (ipc/shm_psize_10 и ipc/shm_psize_40), без четкого указания со стороны поддержки SAP не рекомендуется.

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

Как я уже упоминал в посте "SAP NetWeaver 7.4: особенности конфигурации памяти", в системах, начиная с версии SAP NetWeaver 7.4, в плане управления памятью появился целый ряд изменений и нововведений.
Отметим еще два:

• Generic Table Buffer и Single Record Table Buffer были объединены в один - Table Buffer.
• Shared Memory Pools (параметры ipc/shm_psize_10 и ipc/shm_psize_40) по-умолчанию деактивированы, но могут быть использованы, как и ранее.

Table Buffer отображается и может быть проанализирован в транзакции ST02 (рис. 6).

Рис. 6. Единый Table Buffer.

Размер его (в Мб) может быть указан через новый параметр rsdb/tbi_buffer_area_MB. Значение параметра (по-умолчанию) равное "1", означает, что размер вычисляется по формуле:

Размер в байтах = (rttb/buffer_length * 1024 + zsca/table_buffer_area) * 1,1

Список областей Shared Memory без пулов выглядит так, как на рисунке 7.

Рис. 7. Список Shared Memories в SAP NetWeaver 7.4.

Подробнее про это можно найти в SAP note # 1864189 - Incorrect display of Generic Key and Single Record Buffer in ST02 или по ссылке.

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

Существуют следующие команды:

• /$SYNC - сброс всех буферов, кроме Program Buffer,
• /$CUA - сброс CUA buffer,
• /$TAB - сброс TABLE buffer (двух или одного),
• /$NAM - сброс Nametab buffer,
• /$DYN - сброс Screen buffer,
• /$ESM - сброс Exp./ Imp. Shared Memory Buffer,
• /$PXA - сброс Program Buffer (PXA).

Рис. 8. Сброс табличного буфера.

Сброс буферов может быть уместен при обнаружении некорректности в их работе, но стоит помнить, что при выполнении обнуления буфера падает производительность системы (особенно это актуально для продуктивных систем). Выполняйте данные команды только со 100 % пониманием того, что вы делаете. Дополнительную информацию можно найти тут.

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

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

В предыдущем посте я описал механизм буферизации таблиц в SAP системе на уровне сервера приложений AS ABAP. Осталось осветить еще пару моментов, связанных с этим механизмом.

Если в системе сконфигурирована только одна SAP инстанция (один сервер приложений), которая называется центральной (CI или PAS), то в работе буферизации проблем не возникает. Если в таблицу на уровне базы данных были внесены изменения, то записи в буфере отмечаются как "некорректные" (invalidated) и не используются до обновления их из базы данных.
Проблемы могут возникнуть, если в системе сконфигурированы дополнительные сервера приложений. Для сохранения консистентности данных в локальных табличных буферах всех инстанций необходим механизм синхронизации буферов (рис. 1).

Рис. 1. Синхронизация табличных буферов.

Рассмотрим пример. В локальных буферах инстанций А и Б хранятся записи таблицы T001. Рабочий процесс на инстанции А выполнил команду обновления записей в таблице (UPDATE T001). После этого интерфейс базы данных обновил данные на уровне базы данных и в табличном буфере инстанции А (или отметил их как "устаревшие"). Инстанция Б не знает об обновлении данных в таблице и использует устаревшие данные из своего локального табличного буфера.

Механизм синхронизации буферов, который решает проблему, работает следующим образом:

1. Помимо изменений записей буферизированной таблицы T001 в базе данных и в буфере инстанции А (инстанции, рабочий процесс которой выполнил инициацию изменений), интерфейс базы данных вносит информацию об изменении в таблицу DDLOG.
2. Все SAP инстанции периодически считывают записи из DDLOG и отмечают у себя в локальных буферах записи из этой таблицы, как "устаревшие". В данном примере это записи таблицы T001. 

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

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

• rdisp/bufrefmode = sendon,exeauto.
• rdisp/bufreftime = 120 (значение по-умолчанию).

Второй параметр (rdisp/bufreftime) задает в секундах периодичность чтения таблицы DDLOG SAP инстанциями. Нельзя выставлять ниже 60. Рекомендуемые значения от 60 до 120.

Если консистентность данных таблицы очень важна, то следуют пожертвовать производительностью и отключить буферизацию этой таблицы на уровне SAP. 

Стоит добавить, что механизм синхронизации буферов работает не только для табличного буфера, но и для других (например, PXA).

В системе посмотреть настройки и записи в таблице DDLOG можно нажав в транзакции ST02 последовательность кнопок "Detail analysis menu -> Additional functions: Buffer synchron." (рис. 2).

Рис. 2. Настройки и записи синхронизации буферов.

Полезные ноты на данную тему:

• 1054534 - Automatic corrections for buffer synchronization parameters,
• 1099937 - Improved diagnosis options for buffer synchronization.

При анализе таблиц, в контексте буферизации на уровне SAP инстанции, возможны следующие проблемные ситуации:

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

Выявить проблемы с буферизацией поможет транзакция ST10 - Table Call Statistics. Данный инструмент позволяет просмотреть статистику по количеству обращений к таблицам со стороны базы данных и ABAP-процессора, а также информацию по буферизации.

На начальном экране транзакции ST10 следует выбрать пункты "All Tables", "This Server" и "Since Startup" и нажать кнопку "Show Statistics" (рис. 3).

Рис. 3. Начальный экран транзакции ST10.

Статистика отображается в виде таблицы (рис. 4).

Рис. 4. Статистика по таблицам системы.

Настроена ли буферизация для таблицы можно увидеть в поле "Buf key opt":

• ful - полная буферизация,
• gen - буферизация по ключу,
• sng - буферизация единичных записей,
• пусто - буферизация отключена.

В поле "Buffer State" для буферизированных таблиц можно обнаружить следующие значения:

• Valid - записи таблицы в буфере и могут быть прочитаны при запросе,
• Invalid - записи в таблице устарели, потому что операция изменения в базе данных еще не завершена,
• Pending - записи в таблице устарели, но они не будут обновлены при следующем обращении, потому что не прошел период завершения операции изменения в базе данных,
• Loadable - записи в таблице устарели, но будут обновлены при следующем обращении к таблице со стороны ABAP-процессора,
• Loading - записи таблицы в данный момент подгружаются в буфер из базы данных,
• Absent, Displaced - записи таблицы еще не в буфере (например, не было ни одного обращения к ним),
• Multiple - статус возникает для таблиц, для которых активна буферизация по ключу, когда часть областей данных в буфере, а часть нет,
• Error - при загрузке данных в буфер произошла ошибка, буферизация невозможна. 

Для анализа буферизированных таблиц следует отсортировать таблицу по столбцу "DB Activity - Rows Affected" (рис. 5). Таблицы в топе количества чтений и настроенном буфере должны быть выбраны для дальнейшего изучения. Здесь возможны две причины: 

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

Рис. 5. Список таблиц с большим количеством чтений из базы данных.

Также можно проанализировать количество "Invalidations" и "Changes" для буферизированных таблиц, отсортировав список по соответствующим столбцам. Таблицы из топ - кандидаты на предмет корректировки настроек буферизации (рис. 6, 7).

Рис. 6. Список таблиц с большим количеством "сбоев" при чтении буфера.

Рис. 7. Список таблиц с большим количеством изменений.

При нажатии на панели кнопки "Next view" можно посмотреть объём, который каждая таблица занимает в буфере и максимальный размер, который она занимала с момента старта инстанции (рис. 8).

Рис. 8. Анализ объема, занимаемого таблицей в буфере.

Внимание стоит уделить таблицам, которые занимают больше 1 Мб и имеют много "Invalidations" и таблицам, которые занимают больше 5 Мб.

Предупреждение: никогда не отключайте буферизацию для таблиц из области имен SAP без прямого указания на это в SAP нотах.

Для анализа не буферизированных таблиц можно нажать на панели кнопку "Not buffered" и отсортировать по столбцу "ABAP Processor Requests - Total" (рис. 9).

Рис. 9. Анализ не буферизированных таблиц.

Здесь стоит обратить внимание на небольшие таблицы (< 5 Мб), содержащие настройки системы и, либо сгенерированные в процессе настройки (например, таблицы типа Aххх, где xxx>499), либо из области имен клиента (Y* или Z*). Также необходимо учитывать частоту изменений данных в таблице (столбец "Changes").

Для таблиц из области имен SAP указания следует искать в SAP нотах.


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

Буферизация таблиц на уровне сервера приложений 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.


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

SAP Program buffer

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

• 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 buffer, Program 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 нот:

• 746984 - Performance problems in connection with PXA semaphores, 
• 1267828 - Swaps in program buffer even though plenty of space is free.

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

SAP буферизация: общие сведения

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

Рис. 1. SAP буферы.

Использование буферов на уровне сервера приложений SAP даёт ряд важных преимуществ:

• увеличение быстродействия при чтении данных: доступ к SAP буферу обычно в 10-100 раз быстрее, чем к базе данных,
• уменьшение нагрузки на базу данных с увеличением производительности всей системы в целом,
• уменьшение очереди ABAP диспетчера, как следствие уменьшения времени обработки каждого шага диалога рабочими процессами и более быстрое переключение между задачами.

Все SAP буферы можно разделить на три категории:

• системные,
• буферы для объектно-ориентированных приложений,
• табличные.

Детальную информацию по буферам SAP инстанции и их влияние на производительность системы можно найти в таблице (рис. 2).

Рис.2. SAP буферы с описанием.

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

Рис. 3. Основной экран транзакции ST02.

У каждого буфера есть два параметра: размер самого буфера (общий - Allocated и свободный - Free space) и количество записей в нём (максимальное - Dir. size Entries и свободное - Free directory Entries). 

Для каждого буфера доступна детальная информация: для перехода к детальному экрану необходимо дважды щелкнуть на строку с названием буфера (рис. 4).

Рис. 4. Детальная информация о буфере TTAB.

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

Рис. 5. История использования буфера TTAB.

При анализе работы буфера необходимо отслеживать два параметра:

• коэффициент попадания (hit ratio), который показывает эффективность работы буфера,
• вытеснения из буфера (swaps). 

Hitratio снижается как при отсутствии объекта в буфере, так и при неконсистентности (invalidation), когда объект в базе данных был изменен, напрямую или при импорте транспортного запроса, а в буфере осталась "старая" версия. Для снижения такого эффекта рекомендуется выполнять перенос запросов с изменениями программ и настроек в продуктивную систему один или два раза в неделю. Время для переноса следует выбирать с учетом нагрузки на систему со стороны пользователей.

Вытеснения из буфера, количество которых фиксируется в поле "Swaps", происходит в момент нехватки в буфере места или свободного количества записей (поле "Free directory Entries").

Основные рекомендации при мониторинге буферов:

1. Коэффициент попадания (hit ratio) должен быть не ниже 95 %. Для Nametab (NTAB) буферов точность должна быть минимум 99,5 %. 
2. Буферы должны быть достаточного, но не слишком большого размера (размер буфера и количество записей).
3. Количество вытеснений из буфера (swaps) должно стремиться к 0.

Для уменьшения количества swaps необходимо увеличить размер буфера или количество записей в буфере, в зависимости от того, чего не хватает. На примере (рис. 3) для буфера "Export/Import" большое количество вытеснений (swaps) обусловлено нехваткой свободных записей в буфере ("Free directory Entries").

Изменение размеров буфера производится через параметры SAP системы. Список параметров доступен по кнопке "Current Parameters" на основном экране транзакции ST02 (рис. 6).

Рис. 6. Список параметров инстанции для настройки SAP буферов.

Изменение рекомендуется проводить в диапазоне 10-50 % от начального значения, после чего проводить мониторинг (после минимум недельной работы SAP инстанции). Перед установкой любого параметра необходимо изучить справку по нему в транзакции RZ11 и на SAP Help Portal. А так же учитывать единицы измерения - байт, Кб, блоки по 8 Кб.

Полезные SAP notes по данной теме:

• 625305 - Profile parameters for the error analysis buffer,
• 702728 - Profile parameters for export/import buffer instances.

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