Копирование манданта 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.

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

Механизм импорта транспортных запросов. Решение проблем

В этом посте рассказывая про транспортную систему (TMS), я уже упоминал, что она используется не только для импорта транспортных запросов, но и для обновления системы пакетами поддержки (SAP Support Packages), и при установке дополнений в систему (add-ons).

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

• tp - утилита на уровне операционной системы, которая управляет всем процессом импорта, согласовывая работу всех инструментов;
• R3trans - утилита на уровне операционной системы, которая умеет выгружать и загружать данные в любую базу данных, поддерживаемую компанией SAP AG;
• RDDIMPDP - диспетчер импорта в SAP системе, запускающий фоновые RDD*-задания;
• RDD*-задания - набор фоновых ABAP-отчетов, которые выполняют различные фазы импорта в SAP системе. 

Утилита tp согласовывает работу фоновых заданий через таблицы базы данных TRBAT и TRJOB. В первую из них утилита tp добавляет задания для диспетчера импорта (RDDIMPDP) в виде списка запросов на импорт с обозначением текущих фаз импорта. Во второй фиксируются номера и ID фоновых RDD*-заданий во время выполнения. После окончания импорта утилита tp удаляет записи из таблиц, считывая коды возврата. Таким образом, если в данный момент не происходит импорт запросов на перенос, то данные таблицы не должны содержать записи.

Основные шаги импорта перечислены в таблице на рисунке 1.

Рис. 1. Шаги по импорту транспортных запросов/пакетов поддержки в SAP систему.

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

Но вернемся к таблице. Для каждого шага утилитой tp вызывается своя утилита (поле "Инструмент"). Каждый инструмент в поддиректории /usr/sap/trans/tmp генерирует журнал выполнения (поле "Вид журнала"), который после завершения этапа переносится в поддиректорию /usr/sap/trans/log.

Диспетчер импорта (RDDIMPDP) запускается по событию SAP_TRIGGER_RDDIMPDP, которое инициализирует tp с уровня операционной системы через утилиту sapevt (рис. 2). Все RDD*-задания выполняются из под пользователя DDIC (рис. 3).

Рис. 2. Настройки задания RDDIMPDP.

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

Планирование диспетчера импорта производится через отчет RDDNEWPP (000 мандант, пользователь DDIC, транзакция SE38 -> отчет RDDNEWPP -> Выполнить) (рис. 4).

Рис. 4. Планирование фонового задания RDDIMPDP.

Итак, если по какой-то причине импорт запросов/пакетов поддержки не происходит, то проверяем следующее:

• журнал утилиты tp, который доступен по следующему пути "транзакция STMS -> Обзор -> Импорты -> Перейти к -> ПрогрУпрПереносом (TP): системный журнал (выбрать систему)" (или на уровне операционной системы файл /usr/sap/trans/log/SLOG*.SID);
• не блокирован ли пользователь DDIC в 000 манданте;
• в транзакции SM37 анализ запуска диспетчера импорта (RDDIMPDP) и RDD*-заданий;
• на уровне операционной системы в поддиректориях /usr/sap/trans/tmp и
  /usr/sap/trans/log анализ журналов (рис. 1), определение сбойного шага импорта;
• в транзакции SE16 проверка записей таблиц TRBAT и TRJOB.

Если перенос запроса завис на одном из этапов, за который отвечает одно из RDD*-заданий, то можно попробовать, войдя в 000 мандант под пользователем DDIC, выполнить программу RDDIMPDP через транзакцию SE38 вручную.

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

Дополнительная информация по данной теме:

• материалы учебного курса SAP ADM325 (Unit 4: Importing Transport Requests);
• SAP ноты из раздела BC-CTS, например:
  - 11677 - Transports with event-controlled RDDIMPDP,
  - 358813 - Job class of background jobs during import,
  - 1702079 - Background jobs cannot be started, exit code 7 in SLOG during Support Package/transport import,
  - 1712442 - Transport request hung during import. Background job RDDIMPDP is not scheduled.

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