Транзакция SE14 : утилита базы данных. Дополнение.

В 2013 году я опубликовал пост "Транзакция SE14 : утилита базы данных", в которой описал основные моменты по использованию этой транзакции.

Как вы помните, в SAP системе существует два словаря:

• ABAP Dictionary на уровне севера приложений,
• Database Dictionary на уровне базы данных.

Объект (таблица, индекс), созданный по всем правилам разработки в SAP системе, должен существовать в обоих словарях (рис 1).

Рис. 1. Два словаря системы.

Давайте спустимся в кроличью нору немного глубже. :)

Когда я рассказывал про SAP Program buffer на уровне сервера приложений SAP, я упоминал про ABAP loads, которые генерируются для каждой ABAP программы и запускаются ABAP процессором в рабочих процессах инстанции. Для таблиц ситуация похожая. Для каждого объекта ABAP Dictionary (таблицы/домена/структуры и т.п.) существует динамический объект (Runtime object), который генерируется на основе записи из SAP словаря, и содержит техническую информацию об объекте. ABAP программа работает с элементами ABAP словаря не напрямую, а через динамические объекты.

Динамический объект генерируется автоматически при активации (транзакция SE11: ABAP словарь) новой таблицы или внесении изменений в существующую. Динамический объект можно просмотреть, если в транзакции SE11 выбрать пункт меню "Утилиты -> Динамический объект -> Просмотреть" (рис. 2).

Рис. 2. Просмотр динамического объекта для таблицы.

Динамические объекты, которые являются активными в текущий момент времени, отображаются в виде двух частей (рис. 3):

• заголовок (хранится в таблице DDNTT),
• описание полей (содержится в таблице DDNTF).

Рис. 3. Пример динамического объекта для таблицы T000.

Таблицы, в которых хранятся активные динамические объекты, существуют только на уровне базы данных и их нет в ABAP Dictionary. Поэтому посмотреть их структуру можно только в транзакции SE14 или на уровне базы данных. А для просмотра содержимого можно воспользоваться функциональным модулем DD_SHOW_NAMETAB (транзакция SE37). При обновлении объектов через транспортные запросы используется аналогичная пара таблиц для временного хранения неактивных объектов ABAP словаря - DDXTT и DDXTF.

Для того, чтобы проверить корректность динамического объекта, то есть соответствие его активному объекту ABAP словаря, необходимо в SE11 или SE14 выбрать пункт меню "Утилиты -> Динамический объект -> Проверить" (рис. 2). Результатом проверки будет окно вида (рис. 4).

Рис. 4. Результаты проверки динамического объекта.

Вернемся обратно к основной теме.

Почему я всё это рассказал? А потому что объект в Database Dictionary создается на основе динамического объекта (Runtime object). То есть только для активного объекта ABAP словаря, который прошёл все проверки на уровне сервера приложений SAP. И, если мы хотим проверить объект базы данных, выбрав в SE11 пункт меню "Утилиты -> Объект базы данных -> Проверить" (рис. 5), то будет произведена сверка объекта из Database Dictionary и динамического объекта на уровне сервера приложений SAP.

Рис. 5. Проверка объекта базы данных.

Таким образом, можно отобразить взаимосвязь объектов следующим образом (рис. 6).

Рис. 6. Работа с объектами в словарях данных системы SAP.

Иногда во всей этой отлаженной машине возникают коллизии. В основном, при изменении объектов ABAP словаря - перенос транспортных запросов, импорт пакетов обновлений и так далее.

Хочу рассказать историю, которая произошла у меня на проекте в канун последнего Нового Года. Разработчик расширил таблицу на одно поле в системе разработки. Так как тестовой системы временно не было (тут можно вспомнить о важности тестовой системы), было принято решение импортировать запрос с изменениями в продуктивную систему перед новогодними каникулами. При импорте запроса разработчик не учёл, что за время работы с данной функциональностью в системе, таблица выросла на 200 миллионов записей (как у классика: за время в пути собачка могла подрасти). В итоге, импорт запроса проходил успешно. Активация изменений в таблице на уровне ABAP словаря тоже выполнялась успешно. Изменённый динамический объект генерировался, а вот дальше происходил сбой. Таблица на уровне базы данных упрямо не хотела адаптировать изменения - добавлять новое поле.

Что же может помочь при решении проблем с объектами ABAP словаря?

Во-первых, два инструмента - транзакции SE11 и SE14, которые можно использовать для локализации проблемы. Необходимо проверить статусы объекта на уровне всех словарей: динамический объект, таблицу на уровне базы данных. Нет ли где несоответствий и ошибок. При работе системы с некорректным динамическим объектом возникают дампы вида DDIC_TYPE_INCONSISTENCY, DDIC_TYPELENG_INCONSISTENT, DDIC_TYPE_REF_ACCESS_ERROR, TYPELOAD_NEW_VERSION и т.п.

Во вторых, при проблемах на уровне базы данных: для создания отсутствующих объектов или активации изменений на уровне базы данных необходимо использовать транзакцию SE14 (первый пост про транзакцию SE14).

В-третьих, при коллизиях с динамическим объектом можно попробовать удалить его (то есть записи из таблиц DDNTT и DDNTF) через функциональный модуль DD_NAMETAB_DELETE (транзакция SE37). После этого динамический объект можно попробовать заново сгенерировать через активацию таблицы в транзакции SE11.

Ну и наконец, при проблемах с объектом базы данных, когда объект ABAP словаря и динамический объект консистентны, а объект базы данных не проходит проверку, можно осторожно выполнить операцию пересоздания динамического объекта (Runtime object), при этом взяв в качестве источника данных - таблицу на уровне базы данных. Напоминаю, что обычно для генерации динамического объекта используется объект ABAP словаря.
Для пересоздания необходимо войти в транзакцию SE14 в 000 манданте под пользователем DDIC. Задать необходимую таблицу и выбрать пункт меню "Таблица -> Реконструировать" или "Table -> Reconstruct" (рис. 7).

Рис. 7. Инициирование пересоздание динамического объекта из таблицы на уровне базы данных.

Так как после этой операции динамический объект скорее всего будет не соответствовать объекту в ABAP словаре, обязательно в SE11 активировать таблицу ещё раз, приведя в соответствие динамический объект и объект ABAP словаря.

Так же стоит иметь ввиду, что во время пересоздания объекта с данными на уровне базы данных, используется пространство в табличном пространстве PSAPUNDO (или PSAPROLL). А при пересоздании индекса для таблицы - пространство в табличном пространстве PSAPTEMP. При внесении изменений в большие таблицы имейте это в виду.

Возвращаясь к моей новогодней истории, я потратил 2 дня на решение проблемы. Изначально импорт и активация таблицы не произошли корректно из-за недостаточного места в PSAPROLL, а потом, после 3-4 автоматических попыток адаптировать таблицу на уровне базы данных, система уже не реагировала на несоответствия между словарями. Пришлось пересоздать динамический объект указанным выше способом. Расширить место во всех необходимых табличных пространствах, включая табличные пространства, в которых хранилась сама таблица и её индексы, и запустить процесс адаптации таблицы и её индексов в ручном режиме через SE14. 2 дня были потрачены из-за длительности обработки таблицы с таким количеством записей.

После решения всех проблем, обязательно проверьте динамический объект и объект базы данных через соответствующие пункты меню в SE11/SE14.

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

• 1248769 - Inconsistency between database and ABAP Dictionary
• 2180238 - DDIC Inconsistency Check [VIDEO]
• 2048261 - Inactive runtime objects in the ABAP Dictionary 

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

Двухуровневая концепция доменов в SAP AS ABAP

Как я уже не раз упоминал, на уровне сервера приложений AS ABAP ведется централизованный ABAP-словарь. Это обеспечивает платформо-независимость SAP системы от используемой базы данных. О соответствии ABAP-словаря словарю базы данных я писал в посте "Транзакция SE14: утилита базы данных". 

В ABAP-словаре на низшем уровне выделяют такое понятие, как домен. Домен это техническое описание единицы данных, в котором указывается тип и размерность данных, атрибуты вывода и, если необходимо, список значений. Например, домен MANDT, определяющий мандант системы, имеет тип CLNT с длиной 3 символа (рис. 1).

Рис. 1. Описание домена MANDT.

Напрямую в ABAP-программе или описании полей таблицы использовать домен нельзя. Для описания полей или переменных используется элемент данных, который использует домен и содержит дополнительно семантическое описание, например, название поля в различных вариациях и на различных языках (рис. 2 и 3).

Рис. 2. Описание элемента данных MANDT.

Рис. 3. Семантическое описание элемента данных MANDT.

В дальнейшем элемент данных можно использовать для описания поля таблицы. Например, T000, содержащей записи о мандантах SAP системы (рис. 4).

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

Информацию по доменам, элементам данных или полям таблицы можно посмотреть через транзакцию SE11 (рис. 5).

Рис. 5. Просмотр информации по элементам ABAP-словаря в транзакции SE11.

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

Подробности в курсе "BC430 - ABAP Dictionary".


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

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


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