ГЛАВА 10

СЛУЖБА ОБНОВЛЕНИЯ

Модуль обновления является в системе R/3 центральным компонентом. Однако он не является независимым компонентом. Обновление работает в тесном взаимодействии с другими службами R/3, такими как служба диалога и фонового выполнения, и особенно обработки очередей.

SAPLUW

Бизнес-процесс в системе SAP отображается в логическую единицу работы SAP (LUW, см. главу 1), которая может состоять из нескольких изменений экрана. Эта диалоговая или фоновая обработка приводит к изменению данных, которое можно записать в базу данных только полностью (т. е. со всеми изменениями из LUW) или нельзя записать вообще. Система обновления SAP гарантирует, что изменения не записываются в базу данных, пока не будет завершен SAP LUW, и что никакие данные не изменяются, если транзакция SAP прерывается. В большинстве случаев обновление выполняется асинхронно в конце LUW (см. раздел 1.4). Это приводит к значительному повышению производительности для диалоговых пользователей, которые могут продолжать свою работу в следующей LUW, пока система обновления все еще записывает изменения в базу данных.

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

Определение

В среде R/3 термин обновление означает выполнение изменений в базе данных R/3, которые система SAP производит обычно асинхронно после того, как данные были введены или изменены. Для отображения LUW R/3 в транзакции базы данных требуется специальная система обновления. Логические единицы работы R/S отображаются в независимые LUW R/3, которые состоят из нескольких транзакций базы данных. Это возможно только с отдельной системой обновления; в противном случае каждая LUW R/3 должна будет отображаться точно в одну транзакцию базы данных. Система обновления делает возможным управление вводом данных отдельно от самого обновления и консолидирует процессы обновления.

Например, если пользователь вводит данные, то они сначала передаются процессу диалога. Самим процессом диалога изменения в БД не вносятся; для этого используются специальные процессы обновления, записывающие изменения асинхронно (см. рис. 10.1).

Рис. 10.1. Асинхронное обновление

Когда SAP LUW обрабатывается в диалоге, сделанные изменения сохраняются как модули (определенные как функциональные модули и соответствующие данные) в запросе обновления. В заключение диалоговой части транзакции SAP запрос обновления закрывается, записывается заголовок обновления (см. рис. 10.2), и вызывается сама задача обновления, которая выполняет изменения в базе данных, как определено в запросе обновления. Заблокированные записи от диалоговой или фоновой обработки наследуются задачей обновления, которая разблокирует объекты, когда завершается обновление.

Пользователи могут заметить, что асинхронные изменения по сравнению с синхронными дают более высокую производительность системы. Пользователь может быстро модифицировать, ввести или удалить данные — ему не нужно ждать, пока будут выполнены эти запросы, а изменения асинхронно поступят в БД. Подобные запросы обрабатываются в фоновом режиме специальными процессами. Асинхронное обновление особенно выгодно при внесении в данные обширных изменений, например при крупной модификации корпоративных данных или создании заказов. Оно улучшает масштабируемость системы R/3. Обычно пользователи никак не могут повлиять на то, как именно вносятся изменения в БД — асинхронно или синхронно. Это зависит от применяемой программы АВАР.

Рис. 10.2. Запрос обновления

Запрос обновления

Данные, которые будут изменены SAP LUV, сохраняются в запросе обновления (называемом также записью обновления). Запросы обновления состоят из заголовка обновления, одного или нескольких V1, V2 и модулей групповой обработки (см. рис. 10.2).

Таблицы обновления

Информация о запросах обновления сохраняется в таблицах обновления:

► VBHDR — Заголовки обновления

► VBMOD — Модули обновления

► VBDATA — Данные, перенесенные в модули

► VBERROR — Информация об ошибках, которая порождается, если обновление прерывается.

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

Режим обновления

Программы ABAP поддерживают три типа обновлений:

► Локальные обновления

► Асинхронные обновления

► Синхронные обновления

Программа ABAP определяет используемый режим, который не могут изменить ни администратор, ни пользователь.

Локальные обновления

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

Асинхронные обновления

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

Синхронное обновление

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

Обновления V1 и V2

Система различает модули обновления V1 и V2. Существует также групповая обработка для часто используемых функциональных модулей, называемая иногда обновлением V3. Обновление V1 включает в себя критические изменения управляющих функций. Подобные обновления используются для бизнес-операций, например для изменения в имеющихся на складе материалах. Изменения в такие объекты должны вноситься как можно быстрее. Обновления V2, напротив, используются в основном для целей статистики и поэтому имеют более низкий приоритет, чем обновления V1.

Каждый модуль обновления соответствует модулю функции обновления. Будет ли использоваться обновление V1, V2 или V3, зависит от модуля функции и не может изменяться администратором.

На уровне системы обработку модулей V1 и V2 можно распределить по отдельным рабочим процессам обновления в классах UPD и UPD2 (см. главу 15). Для определения числа обновленных процессов UPD и UPD2 используются профильные параметры. Проверить распределение рабочих процессов можно с помощью ►Process Overview (см. главу 15). Если в системе не сконфигурированы рабочие процессы UDP2, то обновление V2 выполняется в рабочем процессе UDP.

Обновления V2 не обязательно выполняются только после обновлений V1. Когда обрабатывается компонент V1, система автоматически пытается обработать компоненты V2 этого запроса обновления.

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

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

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

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

Если происходят ошибки на уровне системы, то можно также деактивировать обновление вручную в окне управления ►Update Records с помощью Update Records • Update • Deactivate, а затем после исправления проблем вновь активировать с помощью Update Records • Activate (см. рис. 10.3). Прерывание обновления и проблемы с обновлением записываются в системном журнале R/3 (см. главу 15).

Рис. 10.3. Управление записями обновления

Чтобы получить обзор текущей ситуации, необходимо вывести сначала все запросы обновления. Когда начинается работа с ►Update Records, следует проверить, что выбраны предыдущие записи обновления для всех пользователей и во всех клиентах. Однако для пользователя при настройках по умолчанию выводятся только его собственные записи обновления от текущей даты и текущего клиента. Объем данных, которые ожидают обновления в любой данный момент времени, является хорошим индикатором того, что число процессов обновления удовлетворяет требованиям системы (см. рис.10.5).

Блокировки SAP, унаследованные обновлением из диалогового или фонового процесса, остаются в силе, пока не будет выполнено обновление V1 для соответствующих объектов. Если пользователь пытается работать с объектом, который заблокирован в связи с ожиданием обновления, выводится сообщение об ошибке. Необходимо выбрать достаточно большое число процессов обновления, чтобы гарантировать, что такие сообщения об ошибках возникали как можно реже. Рекомендуемое время ожидания рабочего процесса обновления не должно превышать пяти минут.

Рис. 10.4. Начальное меню для управления программой обновления

Рис. 10.5. Обзор записей обновления

Прерванные обновления являются особенно важными. Когда обновления прерываются, необходимые для обновления записи данных процессы не могут выполняться, что означает, что изменения не будут реализованы в базе данных R/3 (см. рис. 10.6).

Рис. 10.6. Прерванные обновления

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

► init — Запись ожидает обновления

► auto — Когда задача обновления снова активируется после выключения сервера обновлений, запись будет обновлена автоматически

► run — Запись обрабатывается

► err — Произошла ошибка, которая вызвала прерывание запроса

► V1 — Модули V1 заказа были выполнены без ошибок; запрос ожидает обновления V2

► V2 — Запрос ожидает групповой обработки (обновления V3)

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

Таблица 10.1. Описания информационных пиктограмм

Поиск неисправностей

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

1. В меню ►Update Records выберите статус Terminated, укажите клиента, пользователя и период времени.

2. Выберите Execute.

3. Система выводит на экран список прерванных обновлений (см. рис. 10.6). Для каждой записи показывается клиент, пользователь, время, код сгенерировавшей обновление транзакции и состояние.

4. Проанализируйте прерывание обновления совместно с ответственным лицом из отдела пользователей.

5. Выделите отдельные записи обновления и протестируйте их с помощью команды Update Records • Test. Можно также осуществлять обновление с помощью Update Records • Debugging. Перед использованием данной функции следует учесть, что она создает ощутимую нагрузку на системные ресурсы.

6. Если это не дает результатов, проверьте заголовок записи обновления. Он содержит все административные данные записи. Чтобы вывести ее, выберите Goto • Update Header (см. рис. 10.7).

Рис. 10.7. Заголовок обновления

Рис. 10.8. Модули обновления

7. Чтобы найти функциональный модуль, необходимый для обновления записи (модуль обновления), выберите Update Modules в списке записей с прерванным Обновлением ►Update Records. На рис. 10.8 это показано для записей из рис. 10.6. Здесь необновленная запись состоит из двух компонентов V1 и одного компонента V2.

8. Для проверки реальных данных в записи обновления выберите команду Goto • Display Data.

9. Проверьте в ►System Log системы R/3 сообщения об ошибках, которые возникли во время прерывания обновления.

Примечание

В процессе обычной работы R/3 администратора непосредственно касаются три вопроса, связанных с обновлением:

1. Активен ли сервис обновления?

2. Были ли прерывания обновления?

3. Насколько велика очередь ожидающих запросов обновления?

Мониторинг операций обновления — это одна из повседневных задач системного администратора.

► Обзор всех открытых обновлений

Чтобы получить начальный обзор при запуске SM13, необходимо ввести «*» для пользователя и клиента и выбрать дату перед установкой системы. В противном случае при настройках по умолчанию будет показан только список собственных записей обновления пользователя в текущем клиенте от текущей даты.

► Удаление блокированных записей

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

Lock entries: SAP Menu • Tools • Administration • Monitor • Lock Entries (SM12)

System log: SAP Menu • Info • System Log (SM21)

Update program administration: не существует записи в стандартном меню SAP (SM14)

Update records: SAP Menu • Tools • Administration • Monitor • Update (SM13)

Быстрые ссылки

► SAP Service Marketplace, псевдоним installation

► SAP Service Marketplace, псевдоним technology

Указания SAP Service Marketplace

Таблица 10.2. Указания SAP для системы обновления

1. Обновление было деактивировано в связи с переполнением табличного пространства. Какие требуются действия после расширения табличного пространства?

a. Никакие действия не требуются; служба обновления реактивируется автоматически.

b. Необходимо активировать службу обновления.

c. Необходимо разместить все записи обновления вручную.

2. Какое состояние имеет запись обновления в случае ожидания?

a. Active

b. Released

c. Init

d. Start

3. Какой параметр профиля R/3 используется для передачи сообщения пользователю, запрос обновления которого отменен?

a. rdisp/vbmail

b. Сообщение передается пользователю в любом случае

c. rdisp/rbdelete