
# --------------------------- ADD -------------------------------------------

<Add>
Add

Использование: щелкните по \"Add\"; введите данные в диалоговое окно; щелкните по \"Добавить\".

Можно добавить сервер вручную, введя в CandleDBConfig следующую информацию:

1) Server name - имя сервера базы данных для мониторинга.

2) Home directory - полное имя каталога установки сервера.

3) $Product version - версия или уровень выпуска работающей базы данных.

4) Init file name - полное имя файла инициализации базы данных. 
   Это необязательное поле; оно используется только для информации.  OMA
   для $Product не нуждается в имени файла инициализации.

5) Login ID - ID регистрации базы данных, используемый для соединения с $Product.

6) Password - пароль, используемый в сочетании с \"ID регистрации\".

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

</Add>

# --------------------------- CHANGES ---------------------------------------
#
# Removed since it was only current to 98R2.

# --------------------------- DISPLAY ---------------------------------------
#
# DISPLAY has been combined with MODIFY.


# --------------------------- EXCLUDE ---------------------------------------

<Exclude/Include>
Exclude/Include

Использование: выберите один или несколько серверов базы данных, показанных в CandleDBConfig; щелкните по
\"Exclude\".

\"Exclude\" - это переключатель.  С его помощью можно исключить серверы из мониторинга.  Если сервер в настоящий момент
исключен, то \"Exclude\" повторно активирует его и включит сервер в число сервер, подлежащих мониторингу.
 
Если в результате выполнения \"Search\" найдены и неработающие серверы, то CandleDBConfig проверяет все допустимые файлы
$init_name, указывающие на реальную базу данных, чтобы представить сервер.
Однако файл $init_name может быть пробным или устаревшим.  \"Exclude\" позволяет исключить такие серверы из
рассмотрения в дальнейшем. 

Заметьте, что исключать сервер только потому, что он не работает, НЕ НУЖНО.  Можно сконфигурировать агент для мониторинга
неработающего сервера и даже запустить такой агент.  Агент зарегистрируется в CMS и будет время от времени пытаться
соединиться с базой данных.  Если база данных запущена, то агент будет составлять отчеты об этой базе данных.  Следовательно,
можно задать агент для мониторинга базы данных $Product, которая работает не всегда; такой агент будет сообщать о
работе базы данных, только когда она действительно работает.

Поле \"Status\" серверов базы данных в CandleDBConfig будет обновлено и в нем будут показаны исключенные серверы.

</Exclude/Include>

# --------------------------- INTRO   ---------------------------------------
#
# Not used.

# --------------------------- LIST ------------------------------------------

<List Config Files>
List Config Files

Использование: выберите один или несколько серверов базы данных, показанных в CandleDBConfig; щелкните по \"List\";
просмотрите файл конфигурации; если показаны кнопки  \"Prev\" и \"Next\", то щелкните по ним, чтобы просмотреть
другие
файлы конфигурации; щелкните по \"Cancel\".

Процедура \"List\" используется для просмотра содержимого файлов конфигурации сервера базы данных, созданных
CandleDBConfig.  В
настоящий момент файлы можно только просматривать; изменить их из CandleDBConfig нельзя.

</List Config Files>

# --------------------------- LOCATE ----------------------------------------

<Search II (Disk Searches)>
Search II (Disk Searches)

Использование: щелкните по \"Search II\"; выберите тип поиска; щелкните по \"Go\".

Процедура \"Search II\" предоставляет несколько методов поиска, которые можно использовать, если операция \"Search\" не нашла
все базы данных, мониторинг которых нужно выполнять.  Можно выбрать следующие варианты \"Search II\":

1) Поиск в \$PATH сценариев, содержащих $home_name.

   Если вы используете для запуска приложений базы данных сценарии, расположенные на локальном компьютере, то
   каждый сценарий должен содержать оператор, который задает для $home_name имя каталога установки базы данных.   В этом
   варианте выполняется поиск всех сценариев в \$PATH UNIX, которые содержат этот оператор.

2) Поиск, начиная с указанного каталога.  Обычно это каталог \$HOME владельца базы данных.  Однако можно задать любой
каталог, указав полное имя каталога.  Алгоритм поиска аналогичен алгоритму варианта 1), за исключением того, что поиск
выполняется в указанном каталоге и его подкаталогах, а не в каталогах, заданных в \$PATH.
   
3) Поиск возможных владельцев $Product.

   CandleDBConfig может выполнить поиск файлов в каталогах \$HOME пользователей UNIX, которые могут быть владельцами
   установки базы данных.  В результате будет показан список всех пользователей UNIX, в ID или в описании которых есть
   символы \"$Prd\" или \"dba\"; эти пользователи могут быть владельцами $Product.
   После того, как вы выберете пользователей в этом списке, CandleDBConfig выполнит поиск установок $Product в
   дереве каталогов этих пользователей.  

   Учтите, что этот вариант поиска применим только к пользователям, которые заданы в файле /etc/passwd или в совместно
   используемых базах данных регистрации \"yp\" или \"nis\".  Заметьте также, что в списке указаны файловые системы
   пользователей.  Информация в этом поле указывает физическое местонахождение диска пользователя; это поможет вам
   определить, с какими пользователями вы будете продолжать работу.

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


Список серверов базы данных в CandleDBConfig будет обновлен и в него будут включены все серверы, найденные при помощи
метода \"Search II\".

</Search II (Disk Searches)>

# --------------------------- LOGIN  ----------------------------------------

<Specify Logins/Passwords>
Specify Logins/Passwords

Использование: выберите один или несколько серверов базы данных, показанных в CandleDBConfig; щелкните по \"Specify\";
введите данные в диалоговое окно; щелкните по \"OK\".

При помощи процедуры \"Specify\" можно задать ID регистрации и пароли, которые агент использует для получения доступа к
базе данных.  Можно выбрать новый или существующий ID регистрации в базе данных.   ID регистрации по умолчанию - "candle".  ID регистрации в базе данных задается администратором базы данных и используется для получения доступа к базе данных.  ID
регистрации в базе данных и ID регистрации в UNIX могут совпадать или не совпадать.  Серверы, которые заданы в OMA для
$Product, но для которых нет никакой информации об ID регистрации и пароле, помечаются в CandleDBConfig символом (I)
(Incomplete, Неполные).

Процедура \"Specify\" ТОЛЬКО ПРЕДОСТАВЛЯЕТ агентам мониторинга Candle информацию о том, как нужно соединяться с базой
данных.
CandleDBConfig не создает ID регистрации в базе данных, не назначает пароли и не предоставляет никакие права доступа.  Вы
сами должны убедиться, что ID регистрации в базе данных и пароль совпадают с заданными вами.  Однако при помощи процедуры
\"Verify\" вы можете проверить, работает ли заданная в CandleDBConfig комбинация ID регистрации/пароль с вашей базой
данных.

Если вы оставите поле пароля пустым, то CandleDBConfig спросит у вас, действительно ли вы хотите использовать пустой
пароль.  Пустой пароль означает, что регистрация в базе данных сконфигурирована для работы без пароля.  Из соображений
безопасности в файле журнала $CANDLEHOME/logs/<имя_хоста>_dd_config.log пароль показан как \"xxxxxx\".  

Замечание для Oracle 7.1.4:  В Oracle 7.1.4 для чтения просмотров производительности можно использовать только внутренний
ID регистрации администратора \"sys\".  Этот дефект исправлен в последующих выпусках Oracle, но не исправлен в выпуске
7.1.4.  Поэтому при соединении с базой данных Oracle 7.1.4 нужно задать в качестве ID регистрации в базе данных \"sys\".  

Список серверов базы данных в CandleDBConfig будет обновлен и в него будут включены все новые ID регистрации. 

</Specify Logins/Passwords>

# --------------------------- MODIFY ---------------------------------------

<Modify/Display>
Modify/Display

Использование: выберите один или несколько серверов базы данных, показанных в CandleDBConfig; щелкните по \"Modify\";
введите данные в диалоговое окно или измените данные; щелкните по \"Modify"\.

Процедура \"Modify\" показывает список перечисленных ниже атрибутов конфигурации; значения всех атрибутов, за
исключением имени сервера, можно изменить. 

1) Home directory - полное имя каталога установки сервера.

2) $Product version - версия или уровень выпуска работающей базы данных.

3) Init file name - полное имя файла инициализации базы данных. 
   Это необязательное поле; оно используется только для информации.  OMA
   для $Product не нуждается в имени файла инициализации.

   ВНИМАНИЕ: Если сервер изменил имена, ТО НЕ ЗАМЕНЯЙТЕ значение в этом поле на новое имя файла $init_name.  Вместо
   этого исключите этот сервер и дайте CandleDBConfig возможность добавить новое имя в качестве нового сервера.   

4) Login ID - ID регистрации базы данных, используемый для соединения с $Product.

5) Password - пароль, используемый в сочетании с \"ID регистрации\".

Список серверов базы данных в CandleDBConfig будет обновлен и в него будут включены вся новая информация о конфигурации.

</Modify/Display>

# --------------------------- OPTIONS ------------------------------------------

<Options>
Options

Использование: щелкните по \"Options\"; выберите опции; щелкните по \"OK\".

При помощи функции \"Options\" можно выбрать режим работы среды выполнения операций CandleDBConfig.
Если выбрана опция \"verfiy configuration files\", то любая операция CandleDBConfig будет проверять, нет ли ошибок в
формате файлов конфигурации базы данных, которые расположены в каталоге $CANDLEHOME/config.  

По умолчанию (опция \"verfiy configuration files\") при выполнении каждой операции CandleDBConfig вносит запись
в существующий файл журнала ($CANDLEHOME/logs/<имя_хоста>_dd_config.log).  Если вы хотите внести в журнал только последнюю
операцию или вообще отключить запись, то выберите либо \"create new log file\", либо \"do not write to log file\".

</Options>

# --------------------------- OWNER  ----------------------------------------
#
# OWNER is now a part of Search2.

# --------------------------- SCAN ------------------------------------------

<Search>
Search

Использование: если нужно, то щелкните по \"not-running\"; щелкните по \"Options\"; выберите опции; щелкните по \"OK\";
щелкните по \"Search\".

Если вы запускаете CandleDBConfig или нажимаете \"Search\", то CandleDBConfig выполняет начальный поиск всех серверов
$Product, работающих в среде.  Если вы выберете \"not running\", то CandleDBConfig будет также искать базы данных, которые
не работают в данный момент.  Результаты поиска будут показаны в диалоговом окне CandleDBConfig.
 
CandleDBConfig проверяет все работающие серверы $Product, определяет место их установки в вашей системе UNIX и запрашивает
другую информацию о серверах.  Время, необходимое для завершения поиска, зависит от установленной версии UNIX.

Если CandleDBConfig выполняет поиск неработающих серверов, то создается внутренний список всех потенциальных каталогов
$home_name и выполняется поиск всех серверов, заданных в этих каталогах.  Для составления списка потенциальных
каталогов $home_name CandleDBConfig использует следующие источники:

1) Каталог $home_name всех работающих серверов.

2) Текущее значение переменной среды $home_name (если оно существует).

3) Все операторы в автоматических сценариях (.profile, .login и так далее) в каталоге \$HOME владельца базы данных,
   которые создают переменную среды $home_name.

4) Сценарий root \$ORACLE_HOME/orainst/root.sh, выполненный после установки Oracle, создает файл реестра
   /etc/oratab.  Как для Oracle, так и для Candle рекомендуется выполнить этот сценарий, чтобы можно было легко найти
   серверы Oracle.  CandleDBConfig предполагает, что имя файла реестра или oratab - /etc/oratab.

Если функция \"Search\" найдет сервер, мониторинг которого выполнять не нужно, то его можно исключить, нажав кнопку
\"Exclude\".  Кроме того, будут действовать все выбранные опции (кнопка \"Options\"), пока вы не измените их.

</Search>

# --------------------------- SYSTEM ---------------------------------------

<System/DB Config>
System/DB Config

Ниже приведен краткий обзор действий по подготовке системы и базы данных, которые нужно выполнить, чтобы агент
мониторинга OMEGAMON Monitoring Agent (OMA) мог выполнять мониторинг базы данных.  Полную информацию смотрите в
публикации \"Installing Candle Products on UNIX\" (Установка продуктов Candle в UNIX). 

SYSTEM

1) Для выполнения kddos требуются специальные разрешения UNIX.  Эти разрешения нужно было задать при установке OMA.  Если это
   не сделано, то их можно задать при помощи программы установки продукта Candle.  Дополнительную информацию
   смотрите в публикации \"Installing Candle Products on UNIX\".

2) CMS нужно заполнить подходящими данными.  Это нужно было сделать при установке OMA.  Если это не сделано, то CMS можно
   заполнить при помощи программы установки продукта Candle.  Дополнительную информацию
   смотрите в публикации \"Installing Candle Products on UNIX\".

DATABASE

INFORMIX

Для Informix требуется только одно разрешение - разрешение на соединение с базой данных.  Соответствующий
оператор SQL содержится в файле $CANDLEHOME/misc/koxgrant.sql.

В OMA для Informix входит программа, которую нужно выполнить как дополнительную программу Informix ALARMPROGRAM.  Измените
ONCONFIG так, чтобы программа ALARMPROGRAM стала программой $CANDLEHOME/<архив>/koxerr для вашего типа операционной системы
UNIX.  Если в вашем распоряжении уже есть пользовательская программа ALARMPROGRAM, то измените оператор ONCONFIG
ALARMPROGRAM так, чтобы он указывал на koxerr.sh, а koxerr.sh так, чтобы он указывал на вашу программу.  Полные инструкции содержатся в сценарии koxerr.sh.

ORACLE

В OMA для Oracle для соединения с базой данных используется ID регистрации Oracle.  OMA может использовать любой ID
Oracle (если только вы не работаете с Oracle 7.1.4), даже если этот ID используется для других целей.  CandleDBConfig не создает этот ID.  При желании можно задать ID без
пароля.  В таком случае задайте для CandleDBConfig пустой пароль. 
ID регистрации и пароли Oracle НЕ ЗАВИСЯТ от регистра.

Приведенный ниже оператор SQL Oracle задает ID и пароль для Oracle.  В этом примере \"id_ora\" - это ID регистрации Oracle, а \"пароль\" - это пароль:

  CREATE USER id_ora IDENTIFIED BY пароль;

Требования к защите различны для разных выпусков Oracle:

  7.1.4  Агент OMA для Oracle должен соединяться с Oracle с ID \"sys\". Это ограничение Oracle.

  7.1.6  Можно использовать любой ID регистрации Oracle, но у этого ID должны быть разрешения на чтение любых таблиц.  Если
         используется ID \"candle\", то для предоставления этих разрешений нужно соединиться с Oracle с ID регистрации в
         Oracle с полномочиями DBA и выполнить следующий оператор SQL:

           GRANT SELECT ANY TABLE TO id_ora;

         Это ограничение Oracle.

  7.2 и более новые.  Можно использовать любой ID регистрации Oracle, но ему нужно предоставить только определенные
      полномочия.  В Candle есть сценарий SQL, который предоставляет эти полномочия.  Сценарий находится в
      $CANDLEHOME/misc/korgrant.sql.
      Ниже приведены краткие инструкции по выполнению этого сценария.  Дополнительную информацию смотрите в публикации
     \"Installing Candle Products on UNIX\".

      a) Задайте переменные среды Oracle ORACLE_SID и ORACLE_HOME, подходящие для этой установки.  Если вы сконфигурировали
         базы данных, то вы можете \"найти источник\" файлов в каталоге config, чтобы задать эти переменные.

      b) Запустите sqlplus.

      c) В командной строке SQL введите следующее: SQL> @korgrant candle

      Внимание: sqldba и svrmgr(l) не разрешают использовать параметры в сценариях SQL.  
      Если вы выполняете korgrant.sql с одной из этих программ, то нужно изменить его, заменив все вхождения &1 на ID
      регистрации, который вы хотите использовать.

Для работы OMA для Oracle нужно установить просмотры производительности и синонимы Oracle.  Они создаются программой
установки Oracle, если программа полностью выполнена.  
Просмотры производительности и синонимы можно также создать при помощи соответствующих сценариев SQL, которые расположены в
КАТАЛОГ_УСТАНОВКИ_ORACLE/rdbms/admin.  Дополнительную информацию смотрите в документации Oracle.
Если вы используете ID регистрации Oracle \"sys\" (это единственный ID, который можно использовать в Oracle 7.1.4),
то это не обязательное требование.

Oracle 7.2 игнорирует права доступа к таблице V\$LATCH.  Чтобы исправить этот дефект, примените исправление Oracle для
дефекта \"base bug #254661\". Это исправление позволяет просматривать данные в \"Cache Totals Report\" (Общий отчет о
кэше). Если вы не устанавливаете это исправление, то нужно установить Oracle с ID регистрации \"sys\".

Для работы OMA для Oracle не требуется доступ к таблицам SYS.DBA_VIEWS и SYS.DBA_SYNONYMS, но этот доступ требуется для
выполнения процедуры \"Verify\" CandleDBConfig.  Если CandleDBConfig не сможет прочитать эти таблицы, то полностью
проверить установку не удастся.
Однако OMA по-прежнему будет работать.

SYBASE

В OMA для Sybase для соединения с базой данных используется ID регистрации Sybase.  OMA может использовать любой ID Sybase,
даже если этот ID используется для других целей.  CandleDBConfig не создает этот ID.  При желании можно задать ID без
пароля.  
В таком случае задайте для CandleDBConfig пустой пароль.  ID регистрации и пароли Sybase ЗАВИСЯТ от регистра.

Приведенный ниже оператор isql Sybase задает ID и пароль для Sybase.  В этом примере \"id_syb\" - это ID регистрации Sybase,
а \"пароль\" - это пароль:    

  sp_addlogin id_syb,пароль
  go

Кроме того, в Candle есть сценарий SQL, $CANDLEHOME/misc/koygrant.sql, при помощи которого можно предоставить необходимые
полномочия.

Агент мониторинга OMEGAMON Monitoring Agent для Sybase использует для соединения с Sybase библиотеку Sybase \"Open
Client\".  Если библиотека \"Open Client\" не установлена на компьютере Sybase, то агент не сможет соединиться с Sybase и в
файл col.out будет внесено сообщение о том, что CT-INIT завершилось неудачно.   Определить, установлена ли библиотека \"Open
Client\", можно, проверив наличие в каталоге установки Sybase файла lib/libct.a.

Если библиотека \"Open Client\" не установлена, то нужно получить один из следующих продуктов:

1) продукт \"Open Client\" от Sybase.  По нашим данным, каждая лицензия на сервер Sybase предоставляет заказчикам
   однократную бесплатную лицензию на \"Open Client\".  Дополнительную информацию можно получить в Sybase.

2) версию среды выполнения CTlib для Sybase.  Ее можно получить бесплатно от службы поддержки уровня 2 Candle.  У Candle есть
   разрешение от Sybase на распространение компонента среды выполнения CTlib.

</System/DB Config>

# --------------------------- VERIFY ---------------------------------------

<Verify OMA Installation>
Verify OMA Installation

Использование: щелкните по \"Verify\"; просмотрите результаты в диалоговом окне; щелкните по \"Cancel\".

Процедура \"Verify\" проверяет, правильно ли установлен агент OMA; выполняются следующие проверки:

1) допустима ли версия UNIX.

2) правильно ли заданы разрешения UNIX в подкаталогах key каталога $CANDLEHOME.

3) заданы ли специальные разрешения UNIX для kddos.

4) существуют ли файлы конфигурации продукта для этого хоста.

Для каждого сконфигурированного сервера процедура \"Verify\" проверяет:

5) допустимы ли файлы конфигурации и выполнено ли конфигурирование.

6) существуют ли каталог установки и файл инициализации базы данных и есть ли у вас разрешения на чтение файла.

7) установлен ли для сервера продукт Sybase Open Client.

8) работает ли сервер базы данных.  Если сервер не работает, то продолжить проверку OMA для этой базы данных невозможно.

9) можете ли вы успешно зарегистрироваться в базе данных.

10) можете ли вы получить доступ к таблицам производительности Oracle V\$.  Если вы не можете получить доступ, то это может
    быть вызвано следующими причинами:

    a) таблицы не были созданы (смотрите главу 5 руководства по планированию, раздел \"V\$ Dynamic Performance Tables\")
       (Динамические таблицы производительности V\$).

    b) не выполнен сценарий korgrant.sql.

    Если у вас нет полномочий DBA, то вы не сможете выявить причину.

    Процедура \"Verify\" тестирует все просмотры производительности и синонимы Oracle.  Агент OMA для Oracle давал сбои
    на некоторых участках, так как просмотры производительности и синонимы создаются при установке Oracle лишь
    частично.  Кроме того, для выполнения этого тестирования требуется, чтобы для пользователя Oracle было задано право
    доступа SELECT для SYS.DBA_VIEWS и SYS.DBA_SYNONYMS.  Предоставление этих прав НЕ ВХОДИТ в сценарий korgrant.sql, так
    как большинство установок Oracle задает для права доступа к таблицам каталога SELECT значение PUBLIC.

11) можете ли вы получить доступ к таблицам производительности Oracle 7.2 SYS.V_\$LATCH.  Если вы не можете получить доступ,
    то ознакомьтесь с публикацией \"Installing Candle Products on UNIX\".

12) выполнен ли сценарий Sybase koygrant.sql.  Этот сценарий предоставляет вашему ID регистрации в Sybase роль sa_role.  

13) для Informix: внесены ли необходимые изменения в оператор ALARMPROGRAM в файле ONCONFIG.  Дополнительную информацию
   смотрите в публикации \"Installing Candle Products on UNIX\".

14) отвечает ли хост CMS на команду ping.

15) может ли агент соединиться с CMS.  Если агент не может соединиться с CMS, то это может быть вызвано следующими
    причинами:

    a) неправильно заданы хост, номер порта или имя CMS.

    b) CMS не работает.

    Если у CandleDBConfig нет прямого доступа к компьютеру CMS и если CandleDBConfig не знает точно место установки CMS на
    компьютере, то CandleDBConfig не сможет выявить причину неполадки.

16) введены ли данные в CMS и выполнена ли перезагрузка CMS после ввода данных.  Если система CMS была просто
    перезагружена, то предыдущие результаты могут быть не окончательными.  Поэтому процедура \"Verify\" дает агенту
    возможность поработать примерно пять минут, прежде, чем решить, что система CMS не работает или не заполнена.  Однако
    если агент определит, что CMS не работает, то агент IVP будет перезапущен немедленно, так как по умолчанию этот
    агент ждет десять минут, прежде чем попытаться соединиться повторно.
 
Процедура \"Verify\" не проверяет:

1) соответствует ли уровень cat, atr, sql (заполнение данными) и соответствующих файлов в CMS установленному агенту. 

2) приводят ли ошибки при распределении времени к тайм-аутам связи.

3) для Informix: не были ли отозваны полномочия PUBLIC прав доступа SELECT для системных таблиц.  В сценарии koxgrant.sql
   не предусмотрено предоставление таких прав; предполагается, что права сохраняются в том виде, в котором они были
   изначально предоставлены Informix.

</Проверить установку OMA

