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


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