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

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

Хороший обзор параметров профиля для управления задачей обновления и краткое описание каждого параметра доступно в ►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). Если обновление или размещение также вызывают отказ, то необходимо удалить соответствующие записи или сбросить и обработать их заново.

Доступ к общему мониторингу процесса обновления и подробному рассмотрению выявленных неисправностей можно получить либо через административное управление для ►Update Records (см. рис. 10.3), либо из ►Update Program Administration (см. рис. 10.4).

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