Конфигурирование SAP системы - IV

В 2013 году я написал цикл статей про параметры AS ABAP части SAP системы. В постах я описал где они хранятся и как их изменять. Можете освежить свои знания и прочитать статьи еще раз:

• Конфигурирование SAP системы - I,
• Конфигурирование SAP системы - II,
• Конфигурирование SAP системы - III.

Как вы помните, параметры AS ABAP части SAP системы хранятся в профилях (profiles). До версии SAP NetWeaver 7.1 было 3 профиля (рис. 1). В более свежих системах содержимое двух профилей было объединено в один и общее количество профилей сократилось до 2-х (для системы с одной инстанцией). Об этом я рассказывал в этом посте. 

Рис. 1. Последовательность чтения SAP параметров и профили SAP.

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

Поэтому необходимо соблюдать ряд правил при работе с параметрам SAP системы.

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

Правило 2. Профили SAP хранятся в операционной системе в виде текстовых файлов. Расположены файлы, в случае Unix, в директориях /usr/sap/<SID>/SYS/profile и /sapmnt/<SID>/profile. В случае Windows это директория <DISK>:\usr\sap\<SID>\SYS\profile. SAP не рекомендует изменять параметры на уровне операционной системы. Поэтому второе правило говорит о том, что SAP профили необходимо загрузить в базу данных. Сделать это можно в транзакции RZ10. И в дальнейшем изменение параметров производить там же.

Правило 3. Если вы изменяете параметры в SAP профиле, то ПЕРЕД операцией всегда делайте резервную копию предыдущей версии файла.

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

Во-первых, когда мы ведем профили полномочий в транзакции RZ10, система автоматически при внесении изменений в профиль и сохранении его создаёт новую версию. А предыдущую версию профиля сохраняет в базе данных (рис. 2).

Рис. 2. Просмотр сохранённых версий профиля SAP.

По любой старой версии профиля всегда можно просмотреть административные данные: имя профиля, версию, когда и кем были внесены изменения  (рис. 3).

Рис. 3. Просмотр административных данных старой версии профиля.

Ну и конечно же можно открыть содержимое профиля и просмотреть все значения параметров SAP.

Теперь перейдём на уровень операционной системы и посмотрим что с профилями там.

При ведении профилей SAP через транзакцию RZ10 в каждом файле автоматически генерируется заголовок с полезной информацией. В заголовке можно найти версию профиля, дату активации и автора. Дополнительно добавляются комментарии для всех изменённых параметров (рис. 4).

Рис. 4. Пример профиля SAP с уровня операционной системы.

При этом каждый раз, когда мы в транзакции RZ10 нажимаем на кнопку "Сохранить" и активируем изменённый профиль, на уровне операционной системы создаётся копия старого профиля. В системах до SAP NetWeaver 7.1 это была одна копия с расширением .BAK, которая каждый раз перезаписывалась. То есть хранилось 2 копии профиля - текущая и предыдущая (рис. 5).

Рис. 5. Пример списка профилей SAP на уровне операционной системы.

А, начиная с SAP NetWeaver 7.1 все предыдущие версии профиля хранятся в виде отдельных копий с расширениями .1, .2, .3 и так далее (рис. 6). Только не путайте эти числа с версиями профиля в RZ10, они не совпадают. В данном случае, это версии копий файла на уровне операционной системы.

Рис. 6. Пример списка профилей SAP на уровне операционной системы.

Таким образом, в случае проблем можно проанализировать старые копии профилей и понять почему система не запускается или работает не так как раньше. Ну или быстро восстановить старую версию профиля, скопировав его из резервной копии на уровне файловой системы сервера. Только потом, при старте системы, не забудьте согласовать откат изменений и в профиле в транзакции RZ10.

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

Организация памяти в SAP AS ABAP - III

Это третья часть статьи из цикла статей про организацию памяти в SAP AS ABAP. Первые две доступны по следующим ссылкам:

• Организация памяти в SAP AS ABAP - I - описаны виды памяти в SAP инстанции,
• Организация памяти в SAP AS ABAP - II - описаны схемы выделения памяти для диалоговых и не-диалоговых рабочих процессов в системе SAP.

Размеры всех областей памяти в SAP, про которые мы уже говорили, устанавливаются через параметры системы. Про настройку SAP системы через параметры я писал тут: часть 1, часть 2, часть 3. 

На рисунке 1 отображены основные области и соответствующие им параметры системы.

Рис. 1. Основные области памяти SAP и параметры.

Более детальное описание параметров по областям памяти представлено в таблице на рисунке 2.

Рис. 2. Параметры SAP для настройки памяти.

Установка значений этих параметров производится в профиле инстанции через транзакцию RZ10. Перед установкой параметра необходимо изучить справку по нему в транзакции RZ11 (рис. 3) и справку на SAP Help Portal. 

Рис. 3. Вызов справки по SAP параметру.

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

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

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

Копирование манданта SAP системы

Как вы знаете, в SAP системе есть такое понятие как мандант. Мандант системы, с одной стороны, это набор таких данных как: манданто-зависимые настройки (customizing), основные записи пользователей (users) и основные данные или данные приложений (application data, master data) (рис. 1).

Рис. 1. Структура данных в SAP системе.

С другой стороны, с технического ракурса, мандант это набор записей таблиц, у которых поле MANDT = <номер манданта>. На уровне бизнеса же, мандант - это автономная единица в SAP системе для работы предприятия и хранения данных. В теории, два предприятия могут работать в разных мандантах одной системы без какого-либо нарушения целостности и безопасности данных.

Учтите что, в англоязычной литературе, мандант это client.

Мандант имеет номер из трех цифр и, в системе может быть до 1000 мандантов (от 000 до 999).

После установки SAP системы, в зависимости от типа и версии продукта, в ней могут присутствовать несколько стандартных мандантов, таких как, 000, 001 и 066.

Все остальные (рабочие) манданты создаются путем копирования существующего манданта. Изначально, в качестве исходного манданта для копии рекомендуется использовать мандант 000. В дальнейшем, по мере жизни системы, может быть использован любой другой мандант системы.

Существует три вида процедуры копирования:

• локальная копия манданта,
• удаленная копия манданта,
• экспорт/импорт манданта.

Локальная копия манданта подразумевает, что копирование производится внутри одной SAP системы.

Процедура выполнения локальной копии следующая:

1. В транзакции BD54 создать логическую систему для нового манданта.
2. В транзакции SCC4 создать запись о новом манданте.
3. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
4. В транзакции SCCL запустить копирование с выбранным профилем для копирования.
5. Для мониторинга процесса использовать транзакцию SCC3.

Полезные SAP notes:

• 550894 - CC-ADMIN: Setting up a new client - описана процедура создания первого манданта из эталонного 000 манданта,
• 446485 - CC-ADMIN: Special copying options - специальные дополнительные опции, которые можно активировать при копировании манданта.

Удаленная копия манданта (remote client copy) выполняется между двумя системами. Копия выполняется "на лету", то есть физической копии манданта не создается, место на жестком диске не используется. В качестве механизма используется RFC.

Процедура удаленного копирования манданта:

1. В целевой системе войти в транзакцию BD54 и создать логическую систему для нового манданта.
2. В целевой системе в транзакции SCC4 создать запись о новом манданте.
3. В транзакции SM59 создать RFC-соединение до исходного манданта/системы.
4. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
5. В транзакции SCC9 запустить копирование с выбранным профилем.
6. Для мониторинга использовать транзакцию SCC3 в целевой системе.

Полезные SAP notes:

• 99284 - RFC exception: RESOURCE_FAILURE - описаны решения проблем с RFC,
• 557132 - CC-TOPIC: Remote client copy - общая нота про нюансы удаленного копирования манданта,
• 47502 - CC-REMOTE: Messages of the Remote Clientcopy - сообщения об ошибках во время удаленного копирования и что с ними делать.

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

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

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

Процедура экспорта манданта следующая:

1. В исходной системе/манданте войти в транзакцию SCC8 и запланировать экспорт в транспортные запросы с выбранным профилем.
2. Мониторинг производится в транзакции SCC3.

Процедура импорта манданта следующая:

1. В целевой системе в транзакции BD54 создать логическую систему для нового манданта.
2. В целевой системе в транзакции SCC4 создать запись о новом манданте.
3. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
4. Войти в транзакцию STMS, найти запросы с экспортом, запустить импорт запросов.
5. После окончания импорта войти в транзакцию SCC7 и выполнить шаги пост-импорта манданта.
6. Мониторинг последнего шага в транзакции SCC3.

Прежде чем выполнять любой вид копии манданта следует выполнить расчет необходимого дискового пространства. Об этом я уже писал тут.

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

При копировании манданта репозитарий не копируется (рис. 1). При удаленном копировании можно (выбрав соответствующий профиль копирования) скопировать манданто-независимые настройки. Объединить два манданта в один при копировании нельзя.

Если обновляется/замещается существующий мандант, то перед копированием данные из него удаляются (можно это выполнить предварительно вручную).  

При удаленном копировании и экспорте/импорте необходимо чтобы структура таблиц исходной и целевой системы совпадали. Сравнение можно выполнить на предварительном этапе через кнопку "RFC/сравнение систем" (рис. 3).

Рис. 3. Сравнение структуры таблиц перед удаленным копированием.

Еще полезные SAP notes:

• 489690 - CC INFO: Copying large production clients,
• 22514 - CC-INFO: Error analysis for client copy.

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

Конфигурирование SAP системы - III

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

Как вы уже знаете, настроенные значения параметров для конкретной SAP системы хранятся в наборе из 3-х профилей:

• START_<instance>_<Host name> - стартовый профиль,
• DEFAULT.PFL - default профиль,
• <SID>_<instance>_<Host name> - профиль инстанции.

Все профили читаются при старте и являются критической частью любой SAP системы.

Рассмотрим как поведет себя SAP система, когда не обнаружит тот или иной профиль при старте. Я для экспериментов использовал систему на MS Windows Server/ORACLE. У систем на разных платформах есть нюансы, но общее поведение совпадает.
Итак,

1. Удалим стартовый профиль и попробуем запустить SAP cистему.
   Старт системы не проходит дальше запуска Windows-сервиса SAP<SID>_<sys_number> (рис. 1).
   
   

   

   Рис. 1. Ошибка при старте сервиса SAP<SID>_<sys_number>.

Конфигурирование SAP системы - II

В первой части статьи я рассказал про источники значений системных параметров SAP системы и последовательность их считывания.

Продолжим.

Параметры ABAP стэка SAP системы могут быть двух видов:

• статические,
• динамические.

Параметров первого типа на данный момент в системе больше, чем второго. В версии SAP NetWeaver 7.0 и 7.3 их примерно 70%. Отличаются тем, что для вступления изменений в силу необходим рестарт сервера приложений SAP.

Параметры второго типа могут быть изменены двумя способами:

• изменения только в оперативной памяти (действуют до перезагрузки сервера приложений),
• изменения в оперативной памяти и/или в профиле инстанции.

В таблице TPFYPROPTY хранятся записи о параметрах системы. Если в поле "DYNAMIC" у параметра стоит "X", то параметр динамический (рис. 1).

Рис. 1. Содержимое таблицы TPFYPROPTY.