Сигрид Хагеман - SAP R/3 Системное администрирование

Модули групповой обработки

В модулях групповой обработки (V3) обновление выполняется не в процессе обновления — оно выполняется асинхронно в пакетном задании (отчет RSM13005). При таком подходе сначала консолидируют собранные вызовы функционального модуля. Если одна и та же запись изменяется несколько раз, то сначала вычисляется получающееся значение и только оно записывается в базу данных один раз. В остальном же администрирование и управление функциональными модулями идентичны модулям обновления V2. В частности, это означает, что запросы обновления остаются в таблицах обновления, пока они не будут обработаны при групповой обработке.

Будут ли использоваться для групповой обработки модули V3, определяется в программе АВАР или в Customizing для приложения (одним из примеров является извлечение «дельта» в логистике с помощью транзакции LBWE). Если определено использование модуля V3, то администратор SAP отвечает за планирование и мониторинг регулярной групповой обработки.

С точки зрения системного администратора неважно, какие операции выполняет пользователь (т. е. какие транзакции генерируют записи обновления). Пользователю нет необходимости знать, как выполняются операции обновления внутри R/3, для него важнее пропускная способность системы и результаты. Именно системный администратор должен обеспечить фактическое обновление. В следующих разделах поясняется, какие методы и инструментальные средства применяются для этого.

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

Число процессов обновления UDP и UDP2 определяется с помощью параметров rdisp/wp_no_vb и rdisp/wp_no_vb2 (соответственно) в профиле инстанции. Число записей обновления для обработки является критическим фактором в определении числа и распределения процессов обновления (см. раздел 10.3.1). Верхняя граница задается производительностью оборудования, т. е. доступными в системе R/3 ресурсами. Соответственно необходимо контролировать процессы обновления. В качестве точки отсчета для начальных настроек рекомендуется сконфигурировать примерно один рабочий процесс обновления для каждых четырех диалоговых процессов. Поскольку обновление V2 не является критическим по времени, то обычно бывает достаточно одного рабочего процесса UDP2 на систему.

Мультиплексирование

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

Хороший обзор параметров профиля для управления задачей обновления и краткое описание каждого параметра доступно в ►Update Program Administration.Некоторые из наиболее важных конфигурационных параметров описаны ниже.

Конфигурационные параметры

► rdisp/vbmail

Можно сконфигурировать систему R/3 для автоматической отправки сообщения пользователю, когда запрос обновления этого пользователя вызвал ошибку. Для этого нужно задать rdisp/vbmail = 1. Однако значение 0 деактвирует отправку сообщений пользователю в случае ошибки. Значением по умолчанию для этого параметра является 1.

► rdisp/vbdelete

Этот параметр определяет интервал в днях, после которого не полностью выполненные запросы обновления удаляются, когда система R/3 (или одна из ее инстанций) перезапускается. Значением по умолчанию для этого параметра является 50 дней. Разрешено или нет автоматическое удаление или обновление, зависит от бизнес-окружения и может также обсуждаться с аудиторами. Если нежелательно, чтобы незавершенные записи обновления удалялись, нужно задать этот параметр равным 0.

► rdisp/vbreorg

Этот параметр управляет удалением не полностью созданных запросов обновления при перезапуске системы R/3 или одной из ее инстанций. 0 означает, что такие запросы не удаляются; 1 означает удаление таких запросов. Можно также удалять неполные запросы обновления с помощью ►Update Program Administration,управления для ►Update Recordsили отчета RSM13002.Неполные запросы обновления возникают во время прерывания пользователем процесса (отката), когда часть запроса обновления уже была записана в базу данных.

► rdisp/vb_stop_active

Этот параметр определяет, может ли задача обновления быть деактивирована. Когда это значение задано как 1, задача обновления может быть деактивирована автоматически при серьезных проблемах с базой данных или вручную. В отличие от предыдущих версий эта деактивация задачи обновления предотвращает проблемы с базой данных, возникающие в результате отмены обновлений. Если это значение задано как 0, то задача обновления не может быть деактивирована.

Отказ задачи обновления быстро приведет к зависанию системы, так как изменяемые объекты останутся заблокированными и таблицы обновления продолжат увеличиваться в размере. Обычно задача обновления в системе R/3 не требует никакого специального обслуживания. Однако если возникает проблема в базе данных, то это исключительная ситуация, требующая максимально быстрого разрешения.

Причины ошибок

Возможные причины отказа обновлений (или даже отказа всей системы обновлений) включают проблемы с базой данных и конфликты блокировок в приложении.

Различаются две основные области проблем:

► Проблемы для всей системы, такие как вызванные проблемами базы данных, часто деактивируют задачу обновления. Хорошим примером этого является достижение максимального размера в базе данных Oracle. Поэтому при остановке задачи обновления сначала необходимо проверить журнал системы R/3 (см. главу 15) и файлы журналов базы данных и поискать общие системные проблемы. Когда проблема решена, необходимо перезапустить службу обновления вручную.

► Другой тип проблем обновления имеет более изолированную, локальную природу, которая часто вызывается ошибками программирования в объектах заказчика. Это требует вмешательства разработчика и пользователя, чтобы совместно решить, что делать с записями обновления. Можно использовать обзор ►Update Recordsдля удаления, обновления, размещения или сброса отдельных или всех записей. Обновление означает продолжение обновления; размещение означает, что обновленная запись все еще находится в своем начальном состоянии (статус init). Если обновление или размещение также вызывают отказ, то необходимо удалить соответствующие записи или сбросить и обработать их заново.