Есть ли SAP в Италии?

В столице Италии прекрасные красивые, современные и быстрые, но очень шумные трамваи.

Маленькие машины, нежно прижимающиеся на тесных улицах и в не менее тесных гаражах.

Сиеста - это закон для всех. Даже платная парковка в сиесту денег не требует.

Грустные памятники, поседевшие от наглых птиц.

Велосипеды, велосипеды и еще раз велосипеды. Корзины тех, что стоят достаточно давно, превращаются в урны.

Шикарные панорамные виды с холмов и невысоких гор.

Не менее прекрасные городские виды.

Узкие улочки, играющие роль лестниц и дорог для машин одновременно.

Для узких улочек нужна маленькая, но шустрая полиция.

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

Где даже памятнику тяжело остаться равнодушным и не сделать сэлфи.

Светофоры для пешеходов в Италии 3-х секционные, а для машин с большими красными секциями.

Полностью автоматизированные умывальники с индивидуальной сушилкой для рук.

И педальные. Страна, в которой даже в бытовых мелочах проявляется любовь к быстрым автомобилям.

Вкусная еда, которую превращают в произведения искусства.

Тосканские наглые коты, позволяющие иногда себя сфотографировать. Кстати, кошек в Италии надо подзывать "мичу-мичу-мичу", иначе не поймут. :)

А SAP-а я там не нашёл. :(


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

С днем знаний! Скидки.

Поздравляю всех с днём знаний!

Это уже стало традицией: в связи с праздником делать скидку на первый обучающий пакет SAPADM_01. 

Поддержу традицию. Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до 23:59 5 сентября 2016 года я отдам его за 5 000* рублей. 
А тому, кто купит все пакеты (а их на данный момент 5), я так же сделаю скидку, и отдам их все за 20 000** рублей.

Условия акции: 
* - в случае покупки только первого пакета, его надо оплатить в течении сентября, 
** - в случае покупки всех пакетов, обучение надо оплатить в течении 2-х месяцев: сентября-октября.

Подробности про обучение тут.

Прокачай свой SAP Basis skill! :)

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

Обновление полномочий пользователя

В прошлом посте я описывал как проанализировать какие полномочия отсутствуют у пользователя, работающего в SAP системе. Для этого служит транзакция SU53.

Когда пользователь входит в SAP систему все его полномочия загружаются в его контекст.

При внесении изменений в профиль полномочий, который присвоен пользователю, возможно несколько вариантов обновления полномочий у самого пользователя:

• если значение параметра auth/new_buffering (рис. 1) меньше 4, то для обновления полномочий пользователю необходимо выйти из системы и войти заново (logout/login).
• можно выполнить отчет RSUSR405 через транзакцию SE38/SA38 (рис. 2). Этот отчет сбрасывает (обновляет) буферы полномочий у всех пользователей во всех мандантах системы.
• если значение параметра auth/new_buffering равно 4, то полномочия обновятся автоматически.

Рис. 1. Параметр системы auth/new_buffering.

Рис. 2. Запуск отчета по сбросу буферов всех пользователей во всех мандантах.

В современных системах (начиная с SAP BASIS 6.10) параметр auth/new_buffering по умолчанию равен 4. В старых системах при изменении параметра на это значение стоит помнить про вопрос производительности. Операции импорта запросов с ролями и профилями полномочий и сохранение изменений в составе полномочий у пользователя, который работает в системе, будут занимать больше времени.

Подробности в SAP note # 209899 - User buffer for authorization check.

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

Как понять каких полномочий не хватает пользователю?

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

В системе действует принцип "что не разрешено, то запрещено". То есть изначально пользователю не разрешено ничего, кроме входа (логина) в систему.

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

Рис. 1. Роли и полномочия в SAP системе. 

Роли присваиваются пользователям, после чего пользователи получают, указанный в них, набор полномочий.

Присвоенный пользователю набор полномочий в SAP системе можно посмотреть в транзакции SU56 (рис. 2).

Рис. 2. Список присвоенных пользователю полномочий.

Проверка полномочий в SAP системе производится в 2 этапа:

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

Покажу на примере. 

Пользователь пытается запустить транзакцию SM04 и получает уведомление об отсутствии полномочий на запуск транзакции (рис. 3).

Рис. 3. Сообщение об отсутствии полномочий на запуск транзакции SM04.

Для анализа недостающих полномочий необходимо в поле запуска транзакции набрать транзакцию SU53 (рис. 4).

Рис. 4. Анализ недостастающих полномочий в транзакции SU53.

Как видно из снимка экрана, сообщение об ошибке это результат неудачной проверки первого типа - на запуск транзакции, в данном случае SM04. 

Стоит отметить, что все полномочия в SAP системе выделются через объекты полномочий, у которых есть поля и присвоенные им значения. Для удобства поиска и выбора все объекты полномочий объединены в классы. 

За полномочия на запуск транзакции (первый этап проверки) отвечает объект полномочий S_TCODE (рис. 4). Значениями поля TCD являются транзакции, которые пользователь может запускать. В данном случае система искала в этом объекте значение SM04, не нашла и выдала сообщение об ошибке.

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

Рис. 5. Сообщение об отсутствии полномочий на администрирование процессов/программ в SM04.

Анализ полномочий, транзакция SU53, показал отсутствие уже совсем другого объекта полномочий (рис. 6). Кстати, если проверять полномочия из запущенной транзакции, то стоит вбивать "/nSU53". Об этом я писал тут.

Рис. 6. Анализ полномочий на работу в транзакции SM04.

Данный инструмент показывает только те полномочия, на проверке которых система "споткнулась". То есть только один, последний, шаг. 

Для получения полного списка необходимых полномочий на выполнение той или иной операции в системе существует другой инструмент. Но об этом в другой раз.

Учтите, что если вы хотите анализировать у пользователей результаты последней проверки полномочий, то необходимо им добавить полномочия на запуск транзакции SU53 - объект S_TCODE. Либо можно использовать параметр auth/tcodes_not_checked (рис. 7). Можно ввести значения "SU53", "SU56" или сразу обе транзакции "SU53 SU56" и, тогда система не будет проводить первый тип проверки для этих транзакций.

Рис. 7. Параметр для отключения проверок для транзакций SU53, SU56.

Подробности о концепции ролей и полномочий можно найти в курсе "SAP ADM940 - ABAP AS Autorization Concept".

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

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.

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

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

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


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