Компания IBM
Опубликован: 14.12.2004 | Доступ: свободный | Студентов: 1529 / 139 | Оценка: 4.36 / 3.98 | Длительность: 16:32:00
ISBN: 978-5-9556-0031-4
Специальности: Системный архитектор
Лекция 8:

Дополнительные средства администрирования

< Лекция 7 || Лекция 8: 123 || Лекция 9 >
Аннотация: В лекции рассматриваются важные средства администрирования. Прежде всего, это работа с очередью недоставленных сообщений - Dead-Letter Queue (DLQ). Далее описываются средства и методика работы с ошибками, возникающими при работе с объектами и сообщениями Websphere MQ. Рассматриваются инструментальные средства и приемы работы администратора WebSphere MQ такие как: архивация менеджеров программой saveqmgr, управление потоками сообщений, документирование интерфейсов и т.д., а также управление производительностью WebSphere MQ.
Ключевые слова: persistent, файл ошибок, журнал изменений свойств объектов, линейный вид логирования, круговой вид логирования, rcdmqobj, синтаксис, тип объекта, PRC, модельная очередь, имя объекта, файл, Unix, объект, rcrmqobj, запись, checkpoint, команда, NOT, трансмиссионная очередь, очередь недоставленных сообщений, очередь, менеджер, WebSphere MQ Explorer, свойства сообщений, Dead-Letter Header, код ошибки, поле, runmqdlq, Maximum Queue Depth, transmission, атрибут, remote, WebSphere MQ Messages and Codes Helper, ПО, программа, WebSphere MQ Administrator (Support Pac MO71), интерфейс, список, пункт, меню, канал типа Server Connection, client, Connection, IP, адрес, курсор, browser, отображение, тело сообщения, Support Pac IH03 (IBM WebSphere Business Integration Message Broker display, test and performance utilities), websphere mq administrator, saveqmgr, скрипт, имя файла, администратор, базы данных, передача сообщений, централизованная обработка сообщений, брокер сообщений, message broker, производительность, документирование

Очередь недоставленных сообщений и восстановление данных

Практически все события, за исключением обработки non persistent сообщений, фиксируются в различных лог файлах WebSphere MQ. Существует два вида лог файлов. В первый записываются сообщения об ошибках, а во второй все изменения состояния объектов менеджера, включая обработанные persistent сообщения. Файл ошибок имеет формат, который легко прочитать с помощью любого текстового редактора. В него записываются события, связанные со стартом или остановкой менеджера и каналов, ошибки установки соединения, ошибки приема или отправки сообщений, например с некорректным форматом или ошибки конвертации, связанные с кодовой страницей. Одним словом, все события, связанные с обеспечением деятельности всех менеджеров очередей, созданных на данном компьютере. Расположение этих файлов задается при первоначальной установке WebSphere MQ. Например, для платформы Windows по умолчанию они расположены в каталоге C:\Program Files\IBM\WebSphere MQ\Errors и имеют название amqerrXX.LOG, где ХХ – номер файла. Второй тип файлов имеет специальный формат и представляет собой журнал изменений свойств объектов. Кроме этого в него записываются все persistent сообщения, обработанные менеджером очередей. Для каждого локального менеджера создаются свои файлы. Например, для менеджера очередей QM_Win2000 на платформе Windows они расположены в C:\Program Files\IBM\WebSphere MQ\log\QM_Win2000\active\ и имеют имя s000000X.log, где X – номер файла. Напомним, что существует два вида логирования сообщений и изменений свойств объектов – линейный и круговой. Линейный вид логирования, в отличие от кругового, позволяет как записывать, так и восстанавливать состояние менеджера в определенный момент времени. Запись образа объектов менеджера производится с помощью команды rcdmqobj . Синтаксис команды имеет вид:

rcdmqobj -m QmgrName -t ObjectType
  GenericObjName

где:

QmgrName – имя менеджера.

ObjectTypeтип объекта. Может принимать значения nl или namelist для списка кластеров, prcs или p rocess для процессов, q или queue для всех типов очередей, ql или qlocal для локальных очередей, qa или qalias для alias очередей, qr или qremote для удаленных локальных очередей, qm или qmodel для модельных очередей, qmgr для менеджера, * или all для всех объектов.

GenericObjNameимя объекта.

Встречаются ситуации, когда необходимо удалить файл очереди, содержащий сообщения. Это необходимо, например, при заполнении свободного пространства дисковой системы (тома), выделенной под WebSphere MQ на UNIX платформах. В этом случае WebSphere MQ сообщит, что объект данной очереди поврежден. Восстановить поврежденные как сознательно, так и в результате сбоя дисковой системы, объекты при условии линейного логирования, можно с помощью команды rcrmqobj . Синтаксис команды имеет вид:

rcrmqobj -m QmgrName -t ObjectType
  GenericObjName

где:

QmgrName – имя менеджера;

ObjectTypeтип объекта;

GenericObjNameимя объекта.

В результате выполнения этой команды восстанавливаются не только очереди, но и persistent сообщения в очередях. Это возможно благодаря тому, что для каждого объекта менеджера ведется запись изменений его состояния, и так называемые точки checkpoint . Команда rcrmqobj повторяет все события, которые были с поврежденным объектом от последнего checkpoint до конца лог файла. Поскольку not persistent сообщения в файл не записываются, то они и не восстанавливаются.

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

Кроме технических ошибок бывают еще и логические ошибки, связанные с неправильными настройками объектов. Если в локальной удаленной очереди указано неверное имя удаленного менеджера или очереди назначения, то сообщения все равно будут доставлены на менеджер, расположенный по адресу, указанному в канале отправителе, который использует соответствующую трансмиссионную очередь. Для обработки ошибочных или недоставленных сообщений существует специальная очередь недоставленных сообщений, которая указывается в атрибуте менеджера Dead-letter Queue в закладке Extended. Изменим пример из лекции 5, в котором при создании на менеджере QM_Win2000 локальной удаленной очереди Win2000_HPUX.RQ будет неправильно указана очередь, в которую нужно доставить сообщения:

ALTER QREMOTE ('Win2000_HPUX.RQ') +
       XMITQ('Win2000_HPUX.TQ') +
       RNAME('Win2000_AIX.Q') +
       RQMNAME('QM_HPUX')

Очереди назначения Win2000_AIX.Q на менеджере QM_HPUX не существует, однако сообщение все равно будет доставлено на этот менеджер в очередь DEAD_LETTER. Его можно просмотреть с помощью WebSphere MQ Explorer (рис. 7.1).

Просмотрев свойства сообщения, в закладке Dead-Letter Header можно увидеть код ошибки 2085, который говорит о том, что в заголовке сообщения существует неизвестный объект. В поле Destination Queue можно увидеть, что очередью назначения является несуществующая очередь Win2000_AIX.Q. Из данной ситуации есть три выхода:

  1. Создать очередь Win2000_AIX.Q на менеджере QM_HPUX и перенаправить сообщение из DEAD_LETTER в нее с помощью команды:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести команду:

    ACTION(RETRY)

    и нажать <Ctrl+d> (для платформы Windows <Ctrl+z> <Enter> и еще раз <Ctrl+z> <Enter> ) и выйти из команды runmqdlq нажав <Ctrl+c>. В результате выполнения данной команды WebSphere MQ попытается заново инициировать помещение сообщения с указанными атрибутами из очереди DEAD_LETTER. Этот способ следует применять в случае переполнения существующей очереди назначения. Напомним, что если количество

    Свойства недоставленного сообщения

    увеличить изображение
    Рис. 7.1. Свойства недоставленного сообщения

    сообщений в очереди превышает ее атрибут Maximum Queue Depth, то вновь поступающие сообщения также будут помещаться в очередь недоставленных сообщений.

  2. Перенаправить сообщение в другую очередь, например в Win2000_HPUX.Q. В данном случае синтаксис команды runmqdlq будет выглядеть следующим образом:

    runmqdlq DEAD_LETTER QM_Win2000

    Далее ввести:

    ACTION(FWD) FWDQ('Win2000_HPUX.Q')
      HEADER(NO)

    и нажать Ctrl+d. Сообщения из очереди DEAD_LETTER будут помещены в очередь Win2000_HPUX.Q.

  3. Удалить сообщение из DEAD_LETTER, исправить свойства локальной удаленной очереди Win2000_HPUX.RQ на менеджере QM_Win2000:

    ALTER QREMOTE ('Win2000_HPUX.RQ')
       RNAME('Win2000_HPUX.Q')

    и послать сообщение заново.

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

Иногда встречается случай, когда после перезагрузки менеджера очередей пропадают сообщения из трансмиссионной (transmission) очереди, несмотря на то, что ее атрибут Default Persistence установлен в persistent. В таком случае следует проверить этот атрибут в соответствующей локальной удаленной (remote) очереди и также установить его в persistent.

< Лекция 7 || Лекция 8: 123 || Лекция 9 >