PRIMECLUSTER Wizard for Oracle 4.2 Configuration and Administration Guide

3.1.1 Standby Operation and Scalable Operation with Oracle9i RAC

This section discusses how PRIMECLUSTER Wizard for Oracle controls Oracle in standby operation or scalable operation (Oracle9i RAC).

Oracle startup

Oracle is started through a shell script. The startup procedure is as follows:

1. su - <Oracle DBA user>

2. sqlplus / nolog

3. connect / as sysdba

4. startup nomount or startup mount

5. alter database mount (if “startup nomount” was executed at step 4.)

6. alter database open

• Initialized parameter file and server parameter file

  The initialized parameter file is not specified for Oracle startup through PRIMECLUSTER Wizard for Oracle, so the default initialized parameter file will be used instead. Specify the initialized parameter file for the following default path (symbolic link).

  <$ORACLE_HOME>/dbs/init<$ORACLE_SID>.ora

  A server parameter file should be located in the shared disk because the file contents are changed dynamically. When a server parameter file is used, enter the full path of the server parameter file in an initialization parameter file.
  It is recommended that the same values for initialization parameters are set between cluster nodes.
  
  The server parameter file must be located on the shared disk device because it is dynamically changed. When you use the server parameter file, enter the full path for the initialized parameter file. See “2.2.7 Oracle Database Creation and Setting”.
  
  It is recommended that the initialized parameter file settings are the same on the operating nodes and standby nodes.

• Recovery processing

  1. PRIMECLUSTER Wizard for Oracle recovers the Oracle instance in the following cases:
     When there is ACTIVE table space in the V$BACKUP view.

  2. When there are files required to be recovered in the V$RECOVER_FILE view.

  When RAC is running, the above recovery processing is exception.

• DBA authentication

  PRIMECLUSTER Wizard for Oracle connects to Oracle instance with SYSDBA system privilege to start up or stop Oracle instance/database. In this case, local connection in operating system authentication is used.

Oracle shutdown

• When users shut down and switch Oracle, the procedure is as follows:

  1. su - <Oracle DBA user>

  2. sqlplus / nolog

  3. connect / as sysdba

  4. shutdown <immediate / abort / transactional> (Setup with StopModeStop)
     Default : immediate

  5. If Oracle is not stopped at step 4 (except for abort), use shutdown abort.

  6. If Oracle is not stopped at step 4 or step 5, shut it down forcibly by sending SIGKILL to the background process.

• The procedure of stopping failed Oracle resources including non-Oracle resources is as follows:

  1. su - <Oracle DBA user>

  2. sqlplus / nolog

  3. connect / as sysdba

  4. shutdown <immediate / abort / transactional> (Setup with StopModeFail)
     Default : abort

  5. If Oracle is not stopped at step 4 (except for abort), use shutdown abort.

  6. If Oracle is not stopped at step 4, shut it down forcibly by sending SIGKILL to the background process.

Oracle monitoring

Oracle is monitored through binary programs. The monitoring procedure is as follows:

1. Check the background process (PMON, SMON) periodically. If the process status can be confirmed, go to step 2.

2. su - <Oracle DBA user>

3. Local connection to the Oracle instance as a SYSTEM user

4. Check if Oracle status is OPEN

5. Check if the background process (PMON, SMON, DBWn, LGWR, CKPT) are alive.

6. Check if “insert”, “update” and “delete” can be properly executed using the monitoring table on the SYSTEM user's default table space

7. Oracle is reconnected once every 24 hours.

If Oracle is stopped, 1 is executed at a 30 second interval (static). If Oracle gets activated, 2 or after is executed. If node startup is completed then the node is operating, only 5 and 6 are executed at a regular interval. The default value is 30 seconds, and can be changed. Note that “6” is executed at a 60-second interval at least.

• SYSTEM user password

  PRIMECLUSTER Wizard for Oracle monitors Oracle as a SYSTEM user. Register the SYSTEM user’s password. See “2.2.7 Oracle Database Creation and Setting”.

• Monitoring table

  PRIMECLUSTER Wizard for Oracle creates a monitoring table on the SYSTEM user’s default table space if the monitoring table does not exist. The table is only a few bites, and will not be deleted.

• Warning notification

  If the following symptoms are detected, PRIMECLUSTER Wizard for Oracle will notify RMS of the warning state. It is not the Fault state, so a failover will not occur.

  • Oracle cannot be connected due to incorrect SYSTEM user’s password that is registered with the “clorapass” command (ORA-01017 detected)

  • Since the SYSTEM user password is wrong, so Oracle connection is not allowed

  • When the max session or max process error occurs, so Oracle connection is not allowed

  • While monitoring SQL (e.g. insert and update) is not replied for a certain period of time, but Oracle connection is allowed, and the Oracle status is OPEN.

  • Since the SYSTEM user's password has expired, so Oracle connection is not allowed (ORA-28001 detected)

• Monitoring timeout

  If monitoring SQL (insert, update) is released, and there is no reply from Oracle after a certain period of time, the monitoring timeout will be considered then the Oracle instance resource will be put into Warning. If the monitoring timeout occurs for twice in a row, a resource will be considered as fault then a failover or degradation will be performed.
  The monitoring timeout (the wait time from Oracle) can be changed with WatchTimeout.

Listener startup

Listener is started through a shell script. The startup procedure is as follows:

1. su - <Oracle user>

2. lsnrctl start <ListenerName>

3. Make sure that a listener process does exist.

Listener shutdown

Listener is shutdown through a shell script. The startup procedure is as follows:

1. su - <Oracle user>

2. lsnrctl stop <ListenerName>

3. Make sure that a listener process does not exist.

4. If Listener is not stopped at step 3, shut it down forcibly by sending SIGKILL to the background process.

Listener monitoring

Listener is monitored through binary programs. The monitoring procedure is as follows:

1. Make sure that a listener process does not exist.

2. Make sure that the net service name is valid with tnsping if TNSName is set.

If a listener of a standby node is stopped, execute 1 at regular time intervals. If the listener gets activated and becomes an operating node, execute 1. and 2. at regular time intervals. The default interval time is 30 seconds, and it can be changed with Interval. Note that 2. is executed at a 60-second interval at least.