Support Package Manager и Add-On Installation Tool или просто SPAM/SAINT

С технической точки зрения ABAP-часть любой SAP системы (SAP ERP, SAP BI, SAP NW и т.д.) можно разделить на две компоненты:

• SAP Kernel (ядро) в виде исполняемых файлов под текущую платформу,
• База данных, в которой находятся все программные коды и настройки системы.

Логически ABAP часть системы это набор модулей (рис. 1) или компонент (рис. 2), которые тесно интегрированы между собой. Подробности можно найти в этой статье.

Рис. 1. Модульная структура SAP системы.

Рис. 2. Список компонент системы. 

Каждая система (SAP ERP, SAP BI, SAP NW и т.д.) имеет свой уникальный набор компонент, часть из которых составляет базис системы (SAP_BASIS, SAP_ABA, PI_BASIS) и называется SAP NetWeaver, а другая часть содержит модули системы.

Компоненты можно добавлять. Добавляемые компоненты называются add-on. У каждой компоненты есть версия и уровень пакетов поддержки (рис. 2 - второй и третий столбцы).

Для управления компонентами в системе существует два инструмента:

• Support Package Manager (транзакция SPAM) - утилита для установки обновлений (Support Packages) на компоненты системы,
• Add-On Installation Tool (транзакция SAINT) - утилита для установки и повышения версии дополнительных компонент (add-on). 

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

Даже, если обновлять систему через новые инструменты, как например, Software Update Manager, всё равно внутри работают утилиты SPAM/SAINT.

Сами утилиты так же, как и компоненты системы, имеют версию и уровень пакетов поддержки (рис. 3 и 4). 

Рис. 3. Support Package Manager (SPAM).

Рис. 4. SAP Add-On Installation Tool (SAINT).

Перед обновлением системы (компонент) необходимо установить обновления для утилит SPAM/SAINT. Обе утилиты обновляются из одного пакета поддержки и имеют одинаковый уровень пакетов поддержки (рис. 3 и 4). Обновления являются кумулятивными, то есть устанавливать надо только самую последнюю версию. Найти их можно, перейдя по ссылке http://support.sap.com/software/patches.html, выбрав пункт "Browse Download Catalog" и пункт "Additional Components" (рис. 5).

Рис. 5. Поиск пакетов поддержки для утилит SPAM/SAINT - I.

На следующем экране выбрать "SAP SPAM/SAINT UPDATE" (рис. 6) и затем версию утилиты (рис. 7) 

Рис. 6. Поиск пакетов поддержки для утилит SPAM/SAINT - II.

Рис. 7. Поиск пакетов поддержки для утилит SPAM/SAINT - III.

Выбрать самое свежее обновление и скачать с помощью SAP Download Manager (рис. 8).

Рис. 8. Скачивание пакетов поддержки для утилит SPAM/SAINT.

Обновление утилит выполняется через Support Package Manager (транзакция SPAM) выбором пункта меню "Import SPAM/SAINT Update" (рис. 9).

Рис. 9. Импорт обновления для утилиты SPAM/SAINT.

После окончания импорта необходимо перезапустить транзакцию SPAM (рис. 10) и проверить текущий уровень пакетов поддержки (рис. 11).

Рис. 10. Перезапуск SPAM после обновления.

Рис. 11. Проверка новой версии утилит SPAM/SAINT.

В случае ошибок можно заглянуть в SAP note # 822379 - Known problems with Support Packages in SAP NW 7.0x AS ABAP или SAP note # 1843157 - Known problems with Support Packages in SAP NW 7.40 AS ABAP.

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

Опрос: рабочее место администратора SAP систем

Как-то давно я просил вас поделиться программным обеспечением, которое вы используете для работы. Тогда я открыл для себя утилиту для создания скриншотов Greenshot и до сих пор её использую. 

Сегодня я решил провести опрос в нашей маленькой компании на тему рабочего места администратора. Укажите, пожалуйста, кто какую версию операционной системы и клиентского места SAP GUI использует на своей основной рабочей станции, на которой работает большую часть времени.

Спасибо. 

Результаты:

Windows 7/SAP GUI 7.40 победил. :)


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

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 % пониманием того, что вы делаете. Дополнительную информацию можно найти тут.

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

Зачем я веду этот блог?

Я начал свою профессиональную деятельность в 2002 году. Почти сразу судьба свела меня с системами SAP, которые я с тех пор и администрирую. Как я начинал свою карьеру и попал в SAP, я описывал в посте про своё 35-летие.

Проработав около 5 лет, я начал понимать, что мне стало тесно в роли SAP Basis консультанта. Захотелось передать свои знания, поделиться какими-то наработками и материалами.

Причин данного желания я вижу две.

Во-первых, желание передать другому свои знания у меня было всегда. Это как шило в одном месте. :) Я всегда восхищался людьми, которые могут буквально "на пальцах" объяснять сложные вещи. К тому же, во времена начала моей карьеры информации по администрированию систем SAP было очень мало, особенно на русском языке. Приходилось собирать её по крупицам, чуть ли не как легенды, которые один администратор передавал другому. Это еще при условии, что первый был готов и, самое главное, мог поделиться знаниями с ближним. Мне хотелось внести свой вклад в общее дело, отдать, так сказать, дань.

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

Поэтому в 2008 году я зарегистрировал этот блог и написал свой первый пост.

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

Не скрою, что одно время мною владела идея немного заработать на блоге, или как сейчас говорят "монетизировать блог". Статистика посещения моего блога на данный момент такова: по рабочим дням примерно 60 уникальных посетителей и 130-150 просмотров. Бывают пиковые значения 95 и 220 соответственно, но происходит это очень редко. В месяц получается около 6500 - 7500 просмотров, при хорошем раскладе (рис. 1). Статистику я никогда не скрывал, она отображается внизу правой колонки. Согласитесь, что посещение не ахти какое. Мой опыт показывает, что увеличение частоты написания постов дает небольшой прирост посещаемости (+10-15 %), но при этом быстро истощает мои нервные и физические силы.

Рис. 1. Статистика блога sidadm за последний месяц.

Я повесил на свой блог два блока рекламы. Больше не вижу смысла, так как сам рекламу не люблю и использую "AdBlock" во всех своих браузерах. Теперь, внимание! За примерно 6 лет показа этих блоков рекламы от Google я "заработал" 63,71 $ (рис. 2)! Причем, вывести можно сумму от 100 $. Таким образом, на рекламе я не заработал ни копейки. Ну и, честно говоря, эта затея почти сразу стала представлять для меня чисто спортивный интерес.

Рис. 2. Статистика Google AdSense.

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

Я усвоил для себя мысль, что используя тематику "Администрирование систем SAP" и публикуя посты в одиночку, большую аудиторию не соберешь, а следовательно, на рекламе и подобных механизмах денег не заработаешь. Даже, ведя блог такое продолжительное время, как я. Признаюсь, это очень не просто. Блогов на тематику SAP, в которых 3-5 постов 4-5 летней давности в Интернете вагон и маленькая тележка.

Так что же мотивирует меня не бросать этот блог и продолжать писать? Информации сейчас в сети в разы больше, чем когда я начинал. В том числе и на русском языке. Можно далеко не ходить и взять для примера тот же портал SAPLand или знаменитый SAPForum.RU. Денег на ведении блога тоже не заработаешь. Так что же?

Ну, во-первых, меня мотивирует то, что данный ресурс содержит уже более 220 постов, и, как минимум, 60 % из них вполне актуальны и реально полезны. Бросить такой проект уже не так просто, как блог из 5 постов. К тому же у меня есть, хочется в это верить, постоянная аудитория, которая читает мой блог и изредка даёт об этом знать. Кстати, обратная связь тоже хороший мотивирующий фактор, и её никогда мало не бывает.

Во-вторых, и это главный аргумент, данный блог держит меня в тонусе. Писать по 3-5 постов в месяц - это комфортный для меня режим, при котором я могу выдавать качественный и полезный контент, а не посты по теме "проснулся, вошёл в систему, проверил логи, поел, пошел спать". :) Тот кто писал статьи или посты знает, что это далеко не так просто, как кажется на первый взгляд. Даже, если тема знакомая и простая, то при написании статьи необходимо собрать информацию из всех доступных источников и свести её воедино. Если есть пробелы в знаниях или хотя бы просто неуверенность в каких-то моментах, то необходимо найти все ответы и удостовериться в их точности. А про мало знакомую тему я и не говорю. Плюс для каждой статьи надо подготовить скриншоты, нарисовать пояснительные схемы. Поэтому для меня писать посты и статьи - это очень полезное занятие, которое обновляет мои собственные знания и при котором я более тщательно прорабатываю новые для себя темы. Существует такое утверждение, что человек лучше знает материал, если может объяснить его другому.

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

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

Если вам нужен будет совет или захотите что-то мне написать на эту тему, то мой адрес прежний - shibolov@gmail.com.


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

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


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

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

Как вы знаете, я кроме этого блога, веду еще колонку на портале SAPLand.

В конце прошлого года портал проводил голосование на звание лучших авторов 2015 года. 

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

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

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


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