Data Volume Management в SAP ERP

16 июня был в Московском офисе компании SAP CIS на инфо дне, который назывался "Управление объемами данных в SAP ERP системах" или Data Volume Management.

В целом мне понравилось.

Мои заметки.

Data Volume Management это проект по управлению данными на системе SAP ERP, который достиг определенной точки роста базы данных. Ориентиры: размер базы данных от 500 Гб и прирост от 30 Гб ежемесячно.

Аргументы для начала проекта Data Volume Management:

• рост базы данных, который часто происходит по экспоненте,
• требования законодательства к хранению данных,
• требования со стороны законодательства к удалению персональных данных (особенно в США и Европе),
• планирование перехода на SAP HANA.

Состоит из массового первого этапа и последующих, выполняемых на регулярной основе.

Основные шаги методологии:

1. Определение top 30 самых больших таблиц (обычно это > 60 % от размера всей базы данных). Анализ этого списка таблиц.
2. Избегание. Ненужные данные (например, логи). Отключение позволит избежать роста. В определении обращений к логам на чтение поможет транзакция ST10.
3. Уменьшение. Например, слишком много детальной информации. Перенастройка.
4. Обобщение. Исключение детальных данных из функциональных модулей при отображении их в других модулях. Например, MM данные в FI.
5. Удаление. Старых ненужных данных. Например, spool requests, batch-input sessions.
6. Архивация. Несет положительный эффект на быстродействии системы, но не всегда явный и не на все таблицы/программы. 

Последний этап (архивация) необходимо проводить на регулярной основе.

Архивация поддерживает уровень бизнес объектов. Необходимо учитывать зависимости между объектами архивации. Система делает это автоматически. 

В основной транзакции SARA есть кнопка Network Graphic, где отображается связь объектов и последовательность проведения процедуры архивации (рис. 1).

Рис. 1. Network Graphic для объектов архивации.

Основные понятия:

• Residence time – время жизни документа – от создания до архивации.
• Retention time – от создания до удаления документа из архива.
• Archiving object – часто это бизнес-объект. Настройка объектов архивации в транзакции AOBJ. Транзакция DB15 – связь таблиц и объектов архивации.

Archive File – сжатый плоский файл, обычно степень 1:5.

Стадии процедуры архивации:

1. Программа записи – создание N-файлов архивов.
2. Удаление (1 процесс удаления на 1 архивный файл).
3. Перенос архивных файлов на External Storage System (часто это Content Server, желательно работа по протоколу Archive Link).

Рекомендуется фаза резервного копирования файловой системы с архивными файлами перед фазой удаления данных из БД.

В программе удаления commit в конце. Поэтому либо удаляет всё, либо ничего.

Для особо важных данных рекомендуется этап удаления данных проводить со считыванием архивных данных из Content Server, то есть рекомендуемая последовательность:

1. Программа записи.
2. Перенос архивных файлов на External Storage System.
3. Удаление архивных файлов из файловой системы.
4. Удаление данных из базы данных с чтением из External Storage System (Content Server).

Данные по архивации содержатся в таблицах ADMI_RUN и ADMI_FILES. По их содержимому можно понять проводилась ли архивация когда-либо в системе.

Способы доступа к данным в архивах:

• Транзакция SARA,
• Транзакция SE38,
• Стандартные транзакции, в которых есть эта функциональность
• Reload (для очень редких объектов). Возможно только на тестовой системе или сразу после процедуры архивации. В целом, не рекомендуется.
• SAP Archive Information System (SAP AS). Транзакция SARI. Построенные индексы для архивов. Таблицы ZARIX_* в БД. Поля настраиваются. Если все поля, что и в архивных данных, то очень большие. Содержат ссылки на смещения в конкретном архивном файле. Иначе очень медленный Full Scan по архивным файлам.

С появлением SAP HANA появились новые нюансы. Вводится понятие Data Aging for SAP HANA.

3 типа данных:

• Hot data – данные в памяти (In-memory).
• Warm data (только для BW) HANA Dynamic Tiering 
• Cold data – для BW – Near Line Storage, для всех систем на SAP HANA - Data Archiving, для SAP S4/HANA – Data Aging – разбиение всех данных на партиции и определение устаревших данных, которые не грузятся в БД, а лежат на дисках БД.

Технология SAP ILM – удаление архивных файлов по расписанию.

Для проведения проекта по Data Volume Management в SAP Solution Manager (начиная с версии 7.01) есть инструмент DVM Workcenter (DVM Cockpit). Транзакция SM_WORKCENTER. Дает больший профит только на большом ландшафте.

Материалы презентаций инфо-дня можно скачать по ссылке.

По архивации в SAP системе есть курс "SAP BIT660 - Data Archiving".

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

BRBACKUP: резервирование и восстановление

Утилита BRBACKUP входит в состав набора утилит BR*TOOLs (ранее SAPDBA) и служит для создания резервных копий базы данных и восстановления из них в случае сбоя. Про это я писал в постах:

• Резервное копирование SAP системы,
• BRTOOLS как архиватор.

В качестве хранилища для резервных копий базы данных можно использовать несколько вариантов. Например, магнитные ленты, диски. В качестве утилиты для копирования данных можно использовать утилиты dd или cpio. Настройка производится в профайле /oracle/<SID>/<DB_vers>/dbs/init<SID>.sap.

При использовании утилиты dd необходимо так же настроить размеры буферов, которые используются командой при записи/чтении данных (рис. 1).

Рис. 1. Буферы утилиты dd.

Причем, для операционных систем Windows и Unix используются разные наборы буферов.

Данные буферы влияют на скорость записи/чтения на хранилище резервных копий. Подробности можно найти по ссылке.

Недавно я решил (в очередной раз) оптимизировать размеры буферов. Исходная база данных ORACLE, размер 1,3 Тб. Операционная система: HP-UX. Копия данных выполняется на ленточную библиотеку HP MSL4048 G3 (магнитные ленты Ultrium 5, 3000 Мб (compression 2:1), 1500 Мб (raw)). Для записи одной резервной копии используется одна магнитная лента.

Результаты моих экспериментов приведены в таблице на рисунке 2.

Рис. 2. Тестирование буферов команды dd.

В результате остановился на значении 250К, которое заменило начальное равное 192К (первая строка). Хотя выигрыш и незначительный. Таблица показывает нелинейность и нелогичность воздействия размера буфера на время выполнения резервного копирования. Так что пробуйте разные значения.

Но история на этом не закончилась.

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

Будьте осторожны. Размер буфера утилиты dd при восстановлении должен быть идентичен тому, что использовался при создании копии. Данные о буферах можно найти в журнале резервной копии.


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

Дамп в системе ZDATE_LARGE_TIME_DIFF

На днях при полной перезагрузке системы вместе с серверным оборудованием один из дополнительных диалоговых серверов приложений начал "плодить" ABAP дампы ZDATE_LARGE_TIME_DIFF (рис. 1).

Рис. 1. Дамп ZDATE_LARGE_TIME_DIFF.

Причем дампы возникали как при определенных операциях пользователей, так и просто при фоновой работе системы. Примерно, раз в 20 минут (рис. 2).

Рис. 2. Частота дампов ZDATE_LARGE_TIME_DIFF.

Текущее время на сервере приложений и сервере базы данных на момент обнаружения ошибки было идентичное (рис. 3).

Рис. 3. Выводы команды date.

Помогла только перезагрузка севера приложений (SAP). После этого дампы пропали, отчет RSDBTIME ошибок не показывает (рис. 4).

Рис. 4. Результаты отчета RSDBTIME.

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

Устранение разницы во времени не помогает. Только перезагрузка.

Подробности можно найти по ссылке и в нотах, которые там указаны.


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

SAP Download Manager 2.1.143

Про SAP Download Manager я писал несколько раз:

• Загрузка пакетов поддержки,
• Установка SAP Download Manager на Mac OS X,
• Обновился SAP Download Manager и Новая версия SAP Download Manager.

В марте 2016 года вышла новая версия - SAP Download Manager 2.1.143. 

Ссылку на скачивание можно найти в SAP Download Basket на сайте SAP Support Portal (рис. 1).

Рис. 1. Ссылка на страницу с утилитой SAP Download Manager.

Страница портала, посвященная SAP Download Manager, содержит ссылку на скачивание утилиты (универсальной для всех платформ) и инструкцию по установке и настройке (рис. 2).

Рис. 2. Страница SAP Download Manager на портале поддержки.

Утилита распространяется в zip-архиве. В данной версии необходимо распаковать лишь один файл DLManager.jar, ну например, в директорию C:\Program Files (x86)\SAP\DownloadManager\ (рис. 3).

Рис. 3. Распаковка утилиты SAP Download Manager.

Для работы утилиты необходимо, чтобы на компьютере была установлена Java Runtime Environment (JRE) version 1.5 или выше. Проверить версию JRE можно через эту web-страницу.

Дальнейшая установка утилиты SAP Download Manager представляет собой инициализацию настроек при первом запуске (рис. 4-6). Необходимо будет указать настройки соединения и директорию для хранения скаченных файлов.

Рис. 4. Запуск настройки утилиты.

Рис. 5. Настройка соединения.

Рис. 6. Настройка директория для хранения скаченных файлов.

Интерфейс самой утилиты не изменился (рис. 7).

Рис. 7. Основной экран утилиты SAP Download Manager.

Доступно скачивание по-отдельности, всем списком и по расписанию (рис. 8). Возможность докачки существует, как и раньше.

Рис. 8. Планирование старта закачки для объекта.

Изменения коснулись аспектов безопасности. Пароль S-юзера не сохраняется, его необходимо вводить при каждом запуске утилиты SAP Download Manager.

Для последующих запусков удобно сделать ярлык и разместить его там, где это удобно. Например, на рабочем столе (рис. 9).  

Рис. 9. Ярлык для запуска утилиты SAP Download Manager.

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

С днём системного администратора!

Поздравляю всех причастных и сочувствующих с днём системного администратора!

Желаю поменьше:

• неожиданных обрывов,
• неразрешимых ошибок,
• неуловимых глюков,
• падений систем,
• неподъемных объемов задач в экстрасжатые сроки.

Желаю побольше:

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

Наша работа не магия, как это часто кажется окружающим, а талант и пот (Гилфоил "Кремниевая долина" S01E02).


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

Хватит ли номеров для транспортных запросов?

При введении в эксплуатацию любого сложного программного продукта требуется его настройка и доработка под текущего пользователя (заказчика). Причем, чем сложнее программное обеспечение, тем больше требуется внести изменений для успешного внедрения его в инфраструктуру предприятия. Часто программные продукты предоставляют инструментарий для донастройки системы. Это может быть утилита, позволяющая провести настройку параметров системы, или среда разработки, которая использует тот или иной язык программирования для написания необходимых модулей и функций.

SAP система не исключение. Для изменений объектов репозитария и настроек используется система разработки (DEV), для тестирования - система контроля качества (QAS), а после тестирования изменения переносятся в систему промышленной эксплуатации или продуктивную систему (PRD). Типичный ландшафт представлен на рисунке 1.

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

Для переноса изменений между системами используются транспортные запросы. Их можно сравнить с патчами, которые содержат новые версии программ, записи таблиц или другие объекты. Транспортные запросы генерируются в системе разработки, по мере готовности они деблокируются (release) и переносятся или импортируются, сначала в тестовую систему, а затем в систему промышленной эксплуатации. 

Для импорта запросов используется транзакция STMS. Запросы импортируются по одному или очередями. 

Каждый транспортный запрос имеет свой уникальный идентификатор или номер, вида:

<SID>K9<номер запроса>

Интервалы номеров запросов имеют длину 5 символов и изменяются от '00001' до '99999'. 

Как я уже упоминал в посте "Решение проблем с транспортной системой", текущий номер запроса хранится в таблице E070L. Новый присваивается путём увеличения текущего на единицу.

На проектах, которые существуют давно и активно разрабатываются, высока вероятность достижения максимального номера, равного '99999'. Многие переживают, что дальше всё остановится. Спешу развеять опасения. :) Дальше автоматически будут использованы буквы латинского алфавита. Для расширения используются диапазоны от 'A0000' до 'ZZZZZ' или от 'AAAAA' до 'Z9999' (рис. 2). В результате, существует порядка 40 миллионов номеров для транспортных запросов.  

Рис. 2. Пример расширенной нумерации транспортных запросов.

Так же можно использовать отчет RSWBO301, который находит свободные непрерывные интервалы выбранной длины. Например, вводим длину 5000 и получаем интервал, который можно использовать (рис. 3 и 4) - с '74262' до '79261'. При этом в данном примере последний активный номер в системе уже '9A00FY'. 

Рис. 3. Пример использования программы RSWBO301.

Рис. 4. Результаты работы отчета RSWBO301.

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

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

Подробности можно найти в SAP нотах:

• 1674286 - How to modify CTS transport number range (ABAP),
• 106911 - Transport system: number range filled for requests.

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

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.

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