► rdisp/vb_stop_active
Этот параметр определяет, может ли задача обновления быть деактивирована. Когда это значение задано как 1, задача обновления может быть деактивирована автоматически при серьезных проблемах с базой данных или вручную. В отличие от предыдущих версий эта деактивация задачи обновления предотвращает проблемы с базой данных, возникающие в результате отмены обновлений. Если это значение задано как 0, то задача обновления не может быть деактивирована.
10.3. Мониторинг и обслуживание обновления
Отказ задачи обновления быстро приведет к зависанию системы, так как изменяемые объекты останутся заблокированными и таблицы обновления продолжат увеличиваться в размере. Обычно задача обновления в системе R/3 не требует никакого специального обслуживания. Однако если возникает проблема в базе данных, то это исключительная ситуация, требующая максимально быстрого разрешения.
Причины ошибок
Возможные причины отказа обновлений (или даже отказа всей системы обновлений) включают проблемы с базой данных и конфликты блокировок в приложении.
Различаются две основные области проблем:
► Проблемы для всей системы, такие как вызванные проблемами базы данных, часто деактивируют задачу обновления. Хорошим примером этого является достижение максимального размера в базе данных Oracle. Поэтому при остановке задачи обновления сначала необходимо проверить журнал системы R/3 (см. главу 15) и файлы журналов базы данных и поискать общие системные проблемы. Когда проблема решена, необходимо перезапустить службу обновления вручную.
► Другой тип проблем обновления имеет более изолированную, локальную природу, которая часто вызывается ошибками программирования в объектах заказчика. Это требует вмешательства разработчика и пользователя, чтобы совместно решить, что делать с записями обновления. Можно использовать обзор ►Update Records для удаления, обновления, размещения или сброса отдельных или всех записей. Обновление означает продолжение обновления; размещение означает, что обновленная запись все еще находится в своем начальном состоянии (статус init). Если обновление или размещение также вызывают отказ, то необходимо удалить соответствующие записи или сбросить и обработать их заново.
10.3.1. Мониторинг обновленияДоступ к общему мониторингу процесса обновления и подробному рассмотрению выявленных неисправностей можно получить либо через административное управление для ►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. Обзор записей обновления
10.3.2. Обслуживание прерванных обновленийПрерванные обновления являются особенно важными. Когда обновления прерываются, необходимые для обновления записи данных процессы не могут выполняться, что означает, что изменения не будут реализованы в базе данных 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 администратора непосредственно касаются три вопроса, связанных с обновлением:
