При некорректном выполнении задания следует выполнить повторную оценку или отмену задания. Если оно проходит тестирование, задание следует назначить пакетному сеансу. После этого следует протестировать весь сеанс и оценить воздействие добавления или изменения задания. При удалении пакетных заданий из сеанса или настройки пакетного расписания следует выполнить весь сеанс и оценить воздействие изменения. В любом случае, при неуспешном выполнении тестирования пакетного сеанса следует либо отменить изменение, либо произвести его повторную оценку. При успешном тестировании пакетных заданий диспетчер мощности должен подать RFC ответственным за управление изменениями на утверждение внедрения изменения.
При тестировании пакетных сеансов диспетчер мощности должен помнить о необходимости оценки влияния на системные ресурсы, имеющие отношение к работающим пользователям. Следует вновь отметить, что работающие пользователи должны иметь наивысший приоритет при определении требований к использованию ресурсов. Пакетная обработка всегда занимает второстепенное положение по отношению к потребностям пользователей. В дополнение к тестированию или если тестирование неосуществимо, диспетчер мощности может использовать прогнозы рабочей нагрузки, основанные на ранее определенных оперативных и пакетных показателях. Используя ранее определенные данные и информацию профиля пакетного задания, диспетчер мощности сможет экстраполировать ожидаемые результаты производительности пакетов. Это, конечно же, не является полноценной заменой фактическому тестированию сеансов и мониторингу характеристик производительности.
В зависимости от процесса изменений в организации, временные незапланированные изменения в расписании в ответ на ошибки не требуют предварительной подачи RFC ответственным за управление изменениями. Диспетчер мощности должен записать все временные изменения в журнал диспетчера мощности для последующего рассмотрения. Временные изменения могут включать:
· Изменение выделения ресурсов для заданий
· Изменение приоритета задания
· Управление пакетными сеансами и заданиями (запуском и остановкой)
· Изменение выделения системных ресурсов
Если возможно, следует избегать внесения таких изменений, так как внесение изменений без надлежащей оценки воздействия изменения может неблагоприятно повлиять на информационную среду и, возможно, снизить производительность работы работающих пользователей. Например, диспетчер мощности должен максимально ограничить внесение непротестированных изменений в ситуациях, когда ошибки препятствуют выполнению пакетных заданий с высоким приоритетом.
Обо всех незапланированных постоянных изменениях, внесенных в ответ на ошибки, необходимо сообщать ответственным за управление изменениями. Однако так как для завершения пакетных заданий следует немедленно вносить изменения в ответ на ошибки, ответственные за управление изменениями должны дать диспетчеру мощности полномочия на внесение необходимых изменений (определяемые ответственными за управление изменениями) без предварительной подачи RFC. Следует приложить все усилия, чтобы протестировать изменение перед его внедрением и не допустить неблагоприятного воздействия на информационную среду. Диспетчер мощности должен записывать все изменения в журнале диспетчера мощности и подать RFC в свободное время (как можно скорее после внесения изменений). Это обеспечивает запись всех изменений среды в базу данных управления конфигурациями. (Дополнительные сведения см. в руководстве MOF Configuration Management Service Management Function).
Резервное копирование системы
Для данных транзакций и информации из журналов пакетной обработки следует регулярно осуществлять резервное копирование, чтобы обеспечить доступность и целостность данных предприятия и прочей информации, а также чтобы обеспечить способ восстановления данных в случае аварии. Операции резервного копирования должны быть сосредоточены на возможности автоматического предоставления копий уничтоженных критических данных и восстановления этой информации.
Как и в случае со всеми операционными системами, резервное копирование пакетной архитектуры должно осуществляться регулярно. Информация, для которой следует выполнять резервное копирование, вместе с рекомендуемой частотой резервного копирования представлены ниже:
· Журналы пакетов и ошибок (ежедневно)
· Данные транзакций (ежедневно)
· Информация журналов на серверах приложений (еженедельно)
В дополнение к данным транзакций, следует периодически осуществлять резервное копирование всей информации в пакетной архитектуре, которая может потребоваться для восстановления системы в случае аварии. (Дополнительные сведения см. в руководстве MOF IT Service Continuity Management Service Management Function).
Архивация
Архивация данных представляет собой процесс, при котором данные транзакций записываются в альтернативное хранилище, после чего они удаляются из баз данных пакетной архитектуры. Архивация данных необходима для того, чтобы свести к минимуму долгосрочные последствия непрерывного роста базы данных; по мере накопления информации в рабочих базах данных возрастает вероятность неблагоприятного воздействия на производительность пакетной архитектуры. Архивация также необходима для удовлетворения требований законодательства по сохранности данных (например, финансовых и налоговых отчетов).
Дата добавления: 2015-11-04; просмотров: 12 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |