Одной из наиболее типичных проблем, с которой можно столкнуться при использовании БД Oracle в Sun Cluster  - невозможность запуска ресурса сервера БД Oracle (ресурс типа SUNW.oracle_server) при помощи стандартных средств соответствующего агента. В качестве симптомов наблюдается следующее : ресурс пытается запуститься на одном из узлов кластера совместно с какими-либо другими "сервисами" ресурсной группы, однако,  при истечении установленного времени ожидания (timeout) ресурс признается "неисправным" и принимается решение о переключении группы (failover) на другие ноды. В результате наблюдается эффект "пинг-понга" этой  ресурcной группы  (а в ряде случаев и нескольких групп, если сконфигурированы соответствующие связи). При этом запуск сервера БД при помощи штатных средств Oracle возможен и успешно проходит, а конфигурация агента Sun Cluster не вызывает каких-либо нареканий.

Чем же может быть вызвана данная проблема ? Очевидно, подобное поведение связано с невозможностью агента связаться с БД и оценить ее состояние. Как известно, основные функции любого агента - это способность корректно запускать, останавливать, а также осуществлять мониторинг процессов специфического для этого агента приложений. Механизм мониторинга, в данном случае, предназначен для того, чтобы  постоянно выполнять оценку процессов БД на предмет их работоспособности с целью "уведомления" RGM (resource group manager) о их состоянии. Мониторинг в данном случае осуществляется при помощи специального пользователя БД имеющего доступ к представлению v_$sysstat. Нередки случаи, когда этот пользователь блокируется/удаляется администратором Oracle по ошибке или БД находится в так называемом "restricted mode" (запрещены все пользовательские сессии кроме администраторов) .Соответственно, в первую очередь необходимо проверить наличие этого пользователя в БД и его способность выполнять запросы - ведь от этого зависит работоспособность  "монитора" агента. Рассмотрим основные шаги такой проверки.

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

Конфигурацию ресурса,  а именно значения его свойств, связанных с соединением к БД,  в Sun Cluster 3.1 можно получить при помощи запуска утилиты "scrgadm -pvv"  (для версии  Sun Cluster 3.2 аналогичный вывод  у "clresource list -v") :
 
...
    (oracle-rg:oracle-server-rs) Res property name: Probe_timeout
      (oracle-rg:oracle-server-rs:Probe_timeout) Res property class: extension
      (oracle-rg:oracle-server-rs:Probe_timeout) Res property description: Timeout value (in seconds) used by monitor for database operations.
      (oracle-rg:oracle-server-rs:Probe_timeout) Res property type: int
      (oracle-rg:oracle-server-rs:Probe_timeout) Res property value: 300
    (oracle-rg:oracle-server-rs) Res property name: Connect_cycle
      (oracle-rg:oracle-server-rs:Connect_cycle) Res property class: extension
      (oracle-rg:oracle-server-rs:Connect_cycle) Res property description: Number of fault monitor probe cycles before disconnecting from database
      (oracle-rg:oracle-server-rs:Connect_cycle) Res property type: int
      (oracle-rg:oracle-server-rs:Connect_cycle) Res property value: 5
    (oracle-rg:oracle-server-rs) Res property name: Parameter_file
      (oracle-rg:oracle-server-rs:Parameter_file) Res property class: extension
      (oracle-rg:oracle-server-rs:Parameter_file) Res property description: Oracle parameter file. If not specified then Oracle's default will be used.
      (oracle-rg:oracle-server-rs:Parameter_file) Res property type: string
      (oracle-rg:oracle-server-rs:Parameter_file) Res property value: /u01/app/oracle/product/10.2.0/test/pfile/initTEST.ora
    (oracle-rg:oracle-server-rs) Res property name: Connect_string
      (oracle-rg:oracle-server-rs:Connect_string) Res property class: extension
      (oracle-rg:oracle-server-rs:Connect_string) Res property description: Oracle user and password. Used by fault monitor to connect to database
      (oracle-rg:oracle-server-rs:Connect_string) Res property type: string
      (oracle-rg:oracle-server-rs:Connect_string) Res property value: sc_fm/sc_fm@test.db
    (oracle-rg:oracle-server-rs) Res property name: ORACLE_SID
      (oracle-rg:oracle-server-rs:ORACLE_SID) Res property class: extension
      (oracle-rg:oracle-server-rs:ORACLE_SID) Res property description: Oracle System Identifier (SID)
      (oracle-rg:oracle-server-rs:ORACLE_SID) Res property type: string
      (oracle-rg:oracle-server-rs:ORACLE_SID) Res property value: TEST
    (oracle-rg:oracle-server-rs) Res property name: ORACLE_HOME
      (oracle-rg:oracle-server-rs:ORACLE_HOME) Res property class: extension
      (oracle-rg:oracle-server-rs:ORACLE_HOME) Res property description: Oracle Home directory
      (oracle-rg:oracle-server-rs:ORACLE_HOME) Res property type: string
      (oracle-rg:oracle-server-rs:ORACLE_HOME) Res property value: /u01/app/oracle/product/10.2.0
...

В данном случае нас интересует свойство Connect_string, содержащее имя пользователя/пароль : sc_fm/sc_fm (а также имя test.db из описания tnsnames.ora)

После того как определен пользователь, необходимо проверить соединение с БД при помощи sqlplus (запуск sqlplus необходимо производить из под пользователя "oracle") :

$ sqlplus sc_fm/sc_fm
SQL> select * from sys.v_$sysstat;
SQL> quit

В случае если проверка показала, что такой пользователь БД отсутствует, необходимо выполнить его добавление при помощи следующей процедуры :

$ sqlplus /nolog
SQL> connect / as sysdba
SQL> create user sc_fm identified by sc_fm;
SQL> grant create session, create table to sc_fm;
SQL> grant select on v_$sysstat to sc_fm;
SQL> alter user sc_fm default tablespace users quota 1m on users;
SQL> quit

В случае если пользователь существует но доступ  для него закрыт, то, по всей видимости, БД находится в  "restricted mode" (вывод из этого режима производится при помощи "SQL>alter system disable restricted session;" ).