Lotus Domino является очень надежным сервером. Но даже самые надежные продукты могут сталкиваться с проблемами, вызывающими их зависания или аварии. Если это происходит, то чем быстрее вы сможете изолировать, проанализировать и исправить проблему, тем раньше ваши пользователи продолжат счастливо работать, а вы вернетесь к другим заботам.

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

Что такое зависания и аварии сервера?

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

Авария сервера

Авария сервера Domino представляет собой ситуацию, когда серверная программа завершается и больше не работает. Зачастую, вы можете определить задание, которое выполнял сервер перед завершением работы, просмотрев аварийный экран или log-файл NSD/RIP (в зависимости от работающей у вас версии Domino).

Общими симптомами аварии сервера Domino являются:

• Сервер Domino больше не работает, но другие программы системы все еще работают.
• Консоль сервера Domino не появляется, даже если задания кажутся загруженными.
• Сервер Domino загрузился и неожиданно завершился без выполнения каких-либо действий.
• На консоли или в Log.nsf отобразилось сообщение о серьезной (panic) ошибке, и система завершила работу.
• NSD/RIP автоматически выполняет и генерирует файл, а сервер завершается и/или перезапускается сам по себе.

Существует несколько различных типов аварий сервера. Например, одноразовая авария. Как следует из названия, она может возникнуть один раз и никогда больше не появляться. Одноразовая авария Domino может быть вызвана поврежденной памятью или поврежденным документом, к которому обратился процесс. Например, предположим, что помещенный в Mail.box документ поврежден. Когда маршрутизатор Domino обращается к Mail.box для перенаправления документа его адресату, это приводит к аварии сервера Domino. Аналогичная ситуация может возникнуть (а может и нет) в будущем. Обычно, одноразовые аварии анализировать труднее всего.

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

Периодические аварии возникают по определенному графику. Они не кажутся связанными с какими-либо конкретными действиями; а могут происходить в одно и то же время каждый день. В таких ситуациях вы должны точно идентифицировать, что выполняется на сервере в это время и что может вызвать проблему. Например, представьте, что на сервере Domino работает запланированный агент (scheduled agent), запускающийся каждый месяц. Этот агент может вызывать аварию сервера. В таких сценариях вы должны сначала запретить агента, создающего проблему, и затем разобраться, почему агент вызывает проблему (и устранить причину).

ABEND - это специальная форма аварии сервера. Термин ABEND - это комбинация слов "abnormal end" (аварийное завершение). ABEND-аварии не создают файлы RIP или NSD.

К причинам аварий относятся:

• Проблемы в коде программы (либо на сервере, либо на клиенте).
• Повреждение в базе данных.
• Программная проблема в стороннем приложении, обращающемся к Domino.
• Недостаток памяти.
• Запрещенные действия, вызванные пользовательским кодом.
• Утечка памяти.
• Незавершенный запрос.

Зависание сервера

Зависание сервера Domino - это ситуация, когда сервер Domino все еще работает, но одна или более задач на сервере не отвечает на запросы. Эти задачи все еще могут быть активны, но они не делают того, что должны. Термин "зависание" определяет также состояние, которое иногда возникает, когда компьютерные программы не работают так, как задумано. Большую часть времени зависания возникают из-за низкоуровневого зацикливания или постоянной недоступности ресурса, вызывающего серьезные проблемы производительности. Зависания сервера наиболее часто приписываются проблемам с ресурсами, поэтому они иногда рассматриваются как проблемы производительности.

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

Симптомами зависания сервера Domino являются:

• Domino все еще работает, но не отвечает клиентам. В этом случае пользователи часто сообщают, что они получают сообщения "Server not responding" ("Сервер не отвечает").
• Консоль ведет себя так, как будто она потеряла соединение и не воспринимает никаких команд, даже таких простых как quit.
• Обращающиеся к серверу клиенты (например, для открытия базы данных) сталкиваются с большим временем реакции.
• Возникают тайм-ауты семафоров. Команда 'show stat' будет записывать информацию о тайм-аутах семафоров. Вот пример тайм-аутов семафоров, записанных в Statrep.nsf: Sem.Timeouts = 430D: 58 0A13:42 030B:28 0116:26 0A12:21. В этом примере 430D - это имя семафора, а 58 - количество тайм-аутов. Обратите внимание на то, что тайм-ауты семафоров не всегда указывают на проблему производительности. Обычно тайм-ауты семафоров возникают на занятом сервере. Статистика Sem.timeouts не появляется в Statrep.nsf, если на сервере не возникали какие-либо тайм-ауты семафоров.
• Выдаются сообщения, относящиеся к производительности, например:
  Insufficient memory.
  Insufficient memory. NSF Folder Pool is full.
  Maximum number of memory segments that Notes can support has been exceeded.
  Network operation did not complete in a reasonable amount of time.
  Server not responding.

Обратите внимание на то, что в ситуации с зависанием сервера, NSD/RIP никогда не генерируются автоматически.

К причинам зависаний сервера относятся проблемы ресурсов (недостаточно ресурсов), конфликты со сторонними приложениями и аппаратные проблемы. В общем случае зависания сервера труднее проанализировать, чем аварии сервера. Одно последнее замечание: аварии и зависания возникают не только на сервере Domino, они также происходят и на Notes-клиенте.

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

В данном разделе мы проанализируем общие подходы к поиску неисправностей при авариях и зависаниях сервера.

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

Если произошла авария сервера Domino, и он не может перезапуститься, удалите задания из переменной Notes.ini Servertask и попытайтесь сузить область поиска и идентифицировать задание, вызывающее аварию. Если вы подозреваете, что вызывает проблему конкретное задание, откройте консоль сервера и сократите число возможных сообщений об ошибках, генерируемых заданием. Например, если маршрутизатор вызвал аварию при обращении к почте в Mail.box, переименуйте Mail.box и дайте возможность серверу снова создать Mail.box.

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

Рассмотрите следующие вопросы:

• Сервер Domino выдает сообщения об ошибках на консоль, или в log-файл?
• Каков точный синтаксис сообщения об ошибке?
• Где генерируется сообщение об ошибке? На сервере Domino или на Notes-клиенте?
• Когда впервые возникла эта проблема?
• Изменяли ли вы что-либо перед возникновением проблемы?

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

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

Если вы подозреваете, что проблема вызвана поврежденной базой данных или документом, запустите служебные задания Updall, Fixup и Compact (с соответствующими ключами). Также, попытайтесь, по возможности, заново создать полнотекстовый индекс в базе данных, если полагаете, что проблема возникла из-за плохого индекса.

Поиск неисправностей при зависаниях сервера Domino

Если на консоли сервера постоянно появляются проблемы c семафорами, проверьте, нет ли конфликта в графике заданий. Если система медленно реагирует, проверьте ваши не Domino приложения, чтобы определить, работают ли они тоже медленно. Кроме того (как общее правило), убедитесь в том, что система обновлена последними заплатками (patch).

NSD-анализ
Определение процесса, который вызвал аварию на сервере, часто является первым шагом в устранении аварии на сервере. В Domino 6 и старше NSD-файл может быть хорошим местом для начала поиска. NSD предоставляет всю текущую информацию о состоянии сервера (стек вызовов для всех потоков, информацию об оперативной памяти и т.д.). В случае аварии log-файл NSD будет генерироваться автоматически сервером Domino и будет сохранен в каталоге data\IBM_TECHNICAL_SUPPORT. log-файл NSD будет иметь название, включающее в себя метку времени генерирования NSD. Например: Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log указывает на то, что этот NSD был создан 17 января 2006 года. Когда NSD выполняется, он прикрепляется к каждому процессу и потоку для дампа стека вызовов. Это может помочь вам определить причину аварии сервера или рабочей станции.

"Сердцем" NSD-файла является секция трассировки стека. Эта секция предоставляет схему прохождения кода каждого потока в существующем процессе и его текущее состояние. Это очень полезно при анализе аварии или зависания на сервере. Также, исследуя NSD-файл, вы можете найти все основные файлы, сгенерированные в каталоге Domino data и можете выполнить основной анализ трассировки последнего стека вызовов, которые были сделаны аварийным процессом. В таком сложном продукте, как Domino, трассировка стека одинакового действия на двух различных серверах может выдать различные результаты.

В NSD-файле вы можете идентифицировать исполняемый файл аварийного процесса, выполнив поиск по словам "fatal," "panic" или "segmentation". Определяя процесс, мы можем увидеть, что ему предшествовало и, возможно, определить, как возникла авария. Если не было найдено ни "panic", ни "fatal", иногда дамп может содержать ссылку на "segmentation fault" в функции. Это указывает на то, что процесс попытался обратиться к общему сегменту памяти, который по каким-то причинам был поврежден и завершился аварийно без вызова "fatal_error" или "panic".

Ниже приведен фрагмент NSD-файла, который был создан при аварии серверного процесса:

### FATAL THREAD 39/83 [ nSERVER:07c0: 2764]
### FP=0743f548, PC=60197cf3, SP=0743ebd0, stksize=2424
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x60197cf3 nnotes._Panic@4+483 (7430016,496dae76,0,496dace8)
@[ 2] 0x600018a4 nnotes._OSBBlockAddr@8+148 (1153f38,2000000,743f608,1)
@[ 3] 0x6000bd92 nnotes._CollectionNavigate@24+610 (0,743fc74,f,0)
@[ 4] 0x600626cc nnotes._ReadEntries@68+2860 (4c5440e8,4cfb8dba,800f,1)
@[ 5] 0x600b9f6f nnotes._NIFReadEntriesExt@72+351 (0,4cfb8dba,800f,1)
@[ 6] 0x10032d40 nserverl._ServerReadEntries@8+1424 (0,8d0c0035,4b64b5bc,4ae46dd6)
@[ 7] 0x100191fc nserverl._DbServer@8+2284 (41b0383,cb740064,0,23696f8)
@[ 8] 0x1002b8c8 nserverl._WorkThreadTask@8+1576 (4711d68,0,3,563fb10)
@[ 9] 0x100016cb nserverl._Scheduler@4+763 (0,563fb10,0,10ec334)
@[10] 0x6011e5e4 nnotes._ThreadWrapper@4+212 (0,10ec334,563fb10,0)
[11] 0x77e887dd KERNEL32.GetModuleFileNameA+465

Когда аварийный процесс определен, вы можете сфокусироваться на поиске неисправностей в этом конкретном процессе.

ServerTasks
Если авария сервера происходит постоянно (например, каждые пять минут), полезно временно удалить строку ServerTasks= из файла Notes.ini сервера. Тогда сервер может быть перезапущен и задания можно будет загрузить поодиночке для определения процесса, вызывающего аварию.

Panic-сообщения
Когда Domino обнаруживает постоянную ошибку или условие, которое может привести к повреждению данных или к каким-либо другим проблемам, он немедленно вызывает подпрограмму, называемую Panic. Это специальная структура, используемая для постоянного мониторинга критических частей кода во время его работы. Она помогает как можно раньше выявить проблемы перед их обострением и возможным повреждением данных. Когда вызывается panic, система немедленно останавливается (это можно рассматривать как контролируемую аварию). При этом генерируются сообщения, иногда на английском, а иногда в виде кода (например: PANIC: 04:3C). Вы можете передать этот код в службу Lotus Software Technical Support для дальнейшего поиска неисправностей.

Инструментальные средства для поиска неисправностей

В данном разделе рассматриваются некоторые из инструментальных средств поиска неисправностей, доступные при возникновении аварии или зависания сервера Domino. Перед использованием этих средств проконсультируйтесь с документацией по администрированию Domino.

RIP (Domino R5)

RIP-файл генерируется при авариях сервера. Этот файл содержит информацию о том, что делал сервер во время аварии. Он сообщает о любых авариях системы, а не только связанных с Domino. RIP-файлы генерируются только в Domino 5.x. В Domino 6 и старше функции, ранее выполняемые RIP, выполняет NSD; он также обладает дополнительными возможности, которые отсутствуют в RIP.

Для генерирования RIP-файла необходимо на сервере Domino загрузить QNC.EXE. Программа QNC.EXE (часто называемая "quincy") является отладочной программой по умолчанию, поставляемой с Domino. Программа QNC.EXE обычно расположена в каталоге \Domino. Для запуска QNC.EXE введите "qnc -I" в строке приглашения операционной системы. Вы можете также запустить QNC.EXE, набрав "qnc nserver" при загрузке сервера. Если при авариях сервера RIP-файлы не генерируются, проверьте, запущен ли QNC.EXE. Обычно, RIP-файлы создаются в каталоге data.

NSD (Domino 6 и старше)

Как упоминалось ранее, Domino 6 и старше предоставляют функциональные возможности NSD. Это файл, который содержит информацию о состоянии сервера во время аварии. Дополнительная информация приведена выше в разделе "NSD-анализ".

Дамп памяти (Domino 6 и старше)

В Domino 6 и старше вы можете использовать команду "sh memory dump" в консоли сервера для создания файла с дампом памяти. Дамп памяти содержит информацию об используемой Domino оперативной памяти в данное время. Она очень полезна при проблемах производительности и утечках памяти. Обычно, файлы с дампом памяти формируются в каталоге data\IBM_TECHNICAL_SUPPORT. Название файла с дампом памяти содержит метку времени генерирования NSD. Например:

memory_ KIRANTP_2005_09_14@17_50_08.dmp

Примечание: Для записи доступной памяти в файл вместо просмотра его на консоли сервера выполните следующую команду: sh memory dump >memory.txt

Журналы HTTP-запросов

Для поиска неисправностей, связанных с авариями и зависаниями Web-сервера Domino, служба Lotus Software Technical Support часто просит вас создать журнал HTTP-запросов. Для разрешения настроек по умолчанию журналов запросов измените файл Notes.ini на сервере и добавьте строку HTTPEnableThreadDebug=1. Это установит операцию ведения журналов HTTP-запросов в уровень по умолчанию. Для установки фиксации в журналах более подробной информации обратитесь к документации по администрированию Domino. Вы можете также разрешить ведение журналов HTTP-запросов динамически, введя "tell http debug thread on / off" в консоли сервера Domino. При разрешенном ведении журналов HTTP-запросов Domino создает набор файлов с названиями htthr*.log. Например: htthr_a40_10_20050914@171556.log.

Возможность ведения журналов HTTP-запросов может использоваться только для поиска специфических неисправностей и, обычно, с указаниями и помощью службы Lotus Software Technical Support. Не используйте ее для каких-либо других целей, например, для общего администрирования. Эти log-файлы со временем увеличиваются в размерах, поэтому вы не должны оставлять разрешенными эти настройки длительный промежуток времени, в противном случае вы займете все доступное дисковое пространство.

Автоматический сбор данных

Notes/Domino 6.0.1 представил инструментальное средство автоматического сбора диагностических данных, известное также под названием Automatic Data Collection, или, кратко, ADC. Automatic Data Collection просто означает, что при авариях Notes-клиента или сервера Domino программа собирает все необходимые данные для отладки аварии и передает их в почтовую базу данных после перезапуска клиента или сервера. Таким образом, администраторы имеют одно место в домене, в котором могут увидеть все аварии, произошедшие у любого клиента и на любом сервере. Это поможет исключить ситуации, когда администратор или пользователь не могут получить нужные данные на аварийном клиенте или сервере.

Настройки Notes.ini

Для поиска проблем производительности и аварий вы можете разрешить следующие отладочные параметры Notes.ini:

• Debug_threadid=1 записывает в журнал ID каждого процесса и потока для каждой операции на сервере.
• Debug_show_timeout=1 включает вывод на консоль сообщений о тайм-аутах семафоров и создает текстовый файл semdebug.txt.
• Debug_capture_timeout=10 - время выдачи каждого сообщения о тайм-аутах семафора.
• CONSOLE_LOG_ENABLED=1 (Domino 6 и старше) разрешает ведение журнала на консоли Domino.

Восстановление после аварий сервера

Вы можете настроить функцию восстановления для автоматической обработки аварий Domino-сервера. При авариях на сервере она автоматически завершает работу и перегружает сервер без какого-либо вмешательства администратора. Domino записывает информацию об аварии в каталоге data. При перезагрузке сервер Domino проверяет, является ли это перезагрузкой после аварии. Если да, автоматически посылается электронное письмо человеку, или группе людей, указанных в поле "Mail Fault Notification to".

Фатальные ошибки (такие как исключительные ситуации операционной системы или внутренние panic-ошибки) завершают каждый процесс Domino и освобождают все связанные с ними ресурсы. Сценарий startup обнаруживает эту ситуацию и перезапускает сервер. Если вы используете несколько серверных разделов, а авария произошла в одном разделе, завершается и перезагружается только этот раздел.

Новые функциональные возможности поиска неисправностей в Domino 7

В данном разделе кратко рассматриваются новые функциональные возможности Domino 7, которые могут помочь вам проанализировать и устранить аварии и зависания сервера.

Domino Domain Monitoring

Одной из наиболее значительных и полезных возможностей обслуживания сервера и поиска неисправностей в Domino 7 является Domino Domain Monitoring (DDM). Она обеспечивает единое место для мониторинга всех серверов в домене (или нескольких доменах). DDM использует программы, называемые пробниками (probe), для сбора информации из отдельных серверов и передает ее в специальную базу данных (DDM.nsf), в которой вы можете просмотреть собранные данные. Это позволяет осуществлять мониторинг, анализ и поиск неисправностей на большом количестве серверов из одной консоли Domino Administrator.

Activity Trends

Функция Activity Trends (тренды активности) позволяет вам анализировать "исторические" серверные данные, помогая проследить тренды, которые можно идентифицировать только за определенный период времени. Вы можете просмотреть эти данные для предсказания и устранения будущих проблем. Эти данные собираются из log-файла (Log.nsf) и задания Catalog и записываются в базу данных Activity Trends (Activity.nsf). Задание Activity Trends Collector обрабатывает эти данные и формирует данные в виде трендов, которые вы можете использовать для построения графиков и для распределения ресурсов.

Запись истории строки состояния в log-файл

Теперь вы можете разрешить Notes-клиенту вести журнал сообщения строки состояния в локальном log-файле (Log.nsf) или во внешнем файле, которые вы назначите. Это помогает искать неисправности на Notes-клиенте. Используйте настройку Notes.ini logstatusbar=1, чтобы разрешить ведение журнала сообщений строки состояния в Log.nsf. Для просмотра записанных сообщений откройте Log.nsf и перейдите в вид Miscellaneous Events. Сообщения строки состояния добавляются с Status Msg. Для записи сообщений строки состояния во внешний файл используйте настройку Notes.ini Debug_Outfile=<path to file> вместе с настройкой Notes.ini logstatusbar=1. Например:
logstatusbar=1
Debug_Outfile=c:\temp\StatusBarLogging.txt

При этом сообщения строки состояния будут записываться в файл StatusBarLogging.txt.

Файл Log.nsf также может предоставить снимок действий, записанных в строке состояния перед аварией Notes-клиента.

Fault Analyzer

Fault Analyzer - это новая функциональная возможность, обрабатывающая все новые аварии, поступающие в почтовую базу данных Automatic Data Collection. Задание Fault Analyzer ищет базу данных, настроенную на документы Fault Report, и определяет, соответствует ли полученный стек уже происходившей аварии. Эта возможность дополняет функцию Automatic Data Collection, анализируя стеки вызовов, записанные в почтовой базе данных Fault Report, и оценивая их для определения того, существуют ли другие экземпляры той же проблемы.

Fault Analyzer настраивается одновременно с настройкой Automatic Data Collection (см. рисунок 1). Используйте документ Server Configuration для настройки Automatic Data Collection на сервере и разрешите или запретите Fault Analyzer.

Рисунок 1. Настройка Fault Analyzer

Если Fault Analyzer обнаруживает дублирование сообщений об аварии, сообщается о новой аварии как ответ на оригинальную аварию, а присоединения либо удаляются из ответа (для экономии места в базе данных), либо сохраняются вместе с ответом.

Улучшения Automatic Data Collection

Теперь при использовании инструментального средства Automatic Data Collection для сбора информации об авариях на сервере сначала проверяется, запущен ли сервер под Domino Controller, и, если да, используются log-файлы Controller. Если нет, проверяется, разрешено ли ведение журналов в консоли, и, если да, используется выводимая на консоль информация. Наконец, данные извлекаются из Log.nsf, если не были установлены ни Domino Controller, ни ведение журналов в консоли.

Теперь вы можете выбрать, какие файлы (используя групповые символы) будут собираться программой Automatic Data Collection, работающей на клиентах или на серверах. На Notes-клиентах она настраивается в документе Desktop Policy Settings (см. рисунок 2).

Рисунок 2. Настройка Automatic Data Collection на Notes-клиенте

На серверах Domino она настраивается в документе Server Configuration (см. рисунок 3).

Рисунок 3. Настройка Automatic Data Collection на сервере Domino

Функция Automatic Data Collection позволяет вам собирать диагностические файлы из других продуктов IBM, а также из продуктов сторонних поставщиков.

Существует вероятность того, что информация, передаваемая Automatic Data Collection, может быть очень объемной. Если это становится проблемой, вы можете настроить Automatic Data Collection на ограничение размера NSD-присоединений и журнала консоли, передаваемых в базу данных Fault Reports (см. рисунок 3).

Shutdown Monitor

Часто требуется продолжительное время для завершения работы сервера Domino после выполнения команды quit или restart. Чтобы сократить задержку, завершение Domino при выполнении этих команд гарантирует задание Shutdown Monitor. Если сервер не завершает свою работу в назначенное время, он завершается принудительно, а перед завершением работы генерируется log-файл NSD. Предельный срок указывается в поле Server Shutdown Timeout раздела Automatic Server Restart документа Server в закладке Basics (см. рисунок 4).

Рисунок 4. Установка Server Shutdown Timeout

По умолчанию Server Shutdown Timeout установлен в 5 секунд. Эта функция может быть запрещена установкой параметра Notes.ini shutdown_monitor_disabled=1.

Process Monitor (только платформы Windows)

Задание Process Monitor выполняет мониторинг процессов, которые должны работать как часть среды сервера Domino. Это задание выполняется только на платформах Microsoft Windows; данная функциональность реализована в Domino для платформ Unix без использования отдельного серверного задания. Если какой-либо из этих процессов отсутствует, задание переводит сервер в состояние panic и определяет, какой процесс был преждевременно завершен. Задание Process Monitor работает с программой Nprocmon.exe, которая выполняет мониторинг процесса Nserver.exe на ненормальное завершение.

Данная функциональная возможность может значительно уменьшить число проблем ненормального завершения, которые, в противном случае, трудно проанализировать (потому что часто трудно определить, какой процесс завершился и вызвал проблему на сервере). Для запрещения работы задания Process Monitor установите переменную process_monitor_disabled=1 в файле Notes.ini на сервере.

Заключение

В данной статье мы определили различия между аварией и зависанием сервера Domino. Мы рассмотрели некоторые процедуры поиска неисправностей и инструментальные средства, которые вы можете использовать для анализа и исправления проблем Notes/Domino. Мы также рассмотрели новее функциональные возможности для поиска неисправностей, представленные в Notes/Domino 7. Вы можете обратиться к этой статье в любое время, когда столкнетесь с аварией или зависанием Notes-клиента или сервера Domino, что, как мы надеемся, не будет происходить слишком часто.

• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов