По соображениям производительности служба обновления делится на подклассы. Для менее важных частей обновления существует отдельная которая может выполнять часть обновлений совместно. Настройка службы обновления V2 не является обязательной. Если этой службы нет, то служба обновлений продолжает решать ее задачи.
Запросы вывода передаются часто называемой которая временно сохраняет их в объектах пока они реально не выводятся. Администратор системы SAP R/3 должен решить, где следует хранить объекты TemSe: в БД с использованием механизмов защиты РСУБД или в файловой системе с помощью средств управления ОС.
В системе должен быть доступен, по крайней мере, один процесс спула. Каждая инстанция может иметь любое число таких процессов.
Процессы спула координируют все процессы вывода, такие как запросы на печать и отправку факса. В зависимости от конфигурации запросы вывода могут передаваться на физический носитель или обрабатываться с помощью системы спулинга ОС. В обоих случаях осуществляется контроль вывода — его мониторинг, а системные сообщения записываются в системные журналы SAP R/3.
занимает среди служб особое место. Аналогично серверу сообщений, эта служба действует в масштабе всей системы, т. е. обеспечивать данную службу для всей системы может только одна инстанция. Обычно для этого достаточно одного процесса. Если система работает с особенно большой нагрузкой, то допускаются несколько процессов службы блокировки, но они должны существовать в одной и той же инстанции, так как информация о блокировке хранится в основной памяти компьютера (память с общим доступом). Соответственно термин «сервер блокировок» (Enqueue Server) используется как синоним инстанции, которая обеспечивает такую службу и для самой службы.
Если это возможно, сервер блокировок (Enqueue Server) и сервер сообщений (Message Server) должны выполняться на одной инстанции, поскольку функционируют они в тесном «сотрудничестве». Сервер блокировок управляет логическими блокировками для Такая транзакция состоит из последовательности функционально и логически согласованно связанных рабочих шагов. Обычно транзакция R/3 включает в себя несколько диалоговых шагов, которые могут выполняться различными процессами. С точки зрения БД каждый шаг диалога, составляющий физическую и логическую единицу, представляет собой транзакцию базы данных и закрывается после шага диалога. РСУБД может координировать только эти транзакции БД с помощью своих собственных процедур управления блокировками. С точки зрения системы SAP R/3 этого недостаточно, вся транзакция SAP R/3 должна выполняться или откатываться назад полностью. По данной причине в R/3 были введены (LUW—Logical Units of Work). SAP R/3 придерживается принципов ACID (атомарность, непротиворечивость, изолированность, надежность) для логических единиц работы, как они определены для транзакций в РСУДБ. К логической единице работы применяются следующие правила:
► Атомарность (Atomic)
LUWs составляют элементарную единицу работы. LUW может выполняться только целиком.
► Непротиворечивость (Consistent)
LUW переводит непротиворечивую БД в новое непротиворечивое состояние, т. е. после выполнение LUW достигается корректное состояние.
► Изолированность (Isolated)
LUW выполняются независимо друг от друга. Они могут работать параллельно. Если несколько LUW пытаются работать с одними и теми же ресурсами, то они могут сделать это только при последовательном выполнении.
► Долговечность (Durable)
Результаты успешно выполненных LUW сохраняются и хранятся постоянно. Например, на результат не влияют возможные системные ошибки.
Для удовлетворения этих требований необходим сервер блокировок. Запросы блокировок, генерируемые в результате транзакций SAP R/3, передаются серверу сообщений, который, в свою очередь, передает их на выполнение серверу блокировок. Для снижения дополнительной нагрузки на сеть лучше размещать сервер сообщений и сервер блокировок на одной инстанции. Сервер блокировок работает с блокировками в специально выделенной области оперативной памяти. Таким образом, отказ сервера блокировок приводит к потере всех блокировок SAP R/3, а следовательно — к автоматическому откату (отмене) всех LUW, на которые они влияют. При таком отказе планировщик немедленно пытается запустить новый рабочий процесс сервера блокировок на этой инстанции.