| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
 Previous |
 Next |
| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
Previous |
Next |
This chapter describes high availability configurations for the OracleAS Metadata Repository. The next chapter, Chapter 8, "OracleAS Infrastructure: High Availability for Oracle Identity Management", describes high availability configurations for Oracle Identity Management.
To make OracleAS Metadata Repository highly available, you need to make the database highly available. Common configurations for a highly available database include:
The last section, Section 7.4, "Checking the Status of OracleAS Metadata Repository", describes how to check the status of the database and the listener.
In a cold failover cluster database, you install the database on storage shared by two nodes. These nodes are in a hardware cluster. One of these nodes (the active node) runs the database processes. If the active node fails for any reason, a failover event occurs and the other node (the passive node) takes over and runs the database processes.
In a cold failover cluster configuration, you set up a virtual hostname and virtual IP address, and associate them with the active node. Clients access the active node using the virtual hostname and virtual IP address. Using a virtual hostname or virtual IP address shields the clients from needing to know which node is servicing their requests. During a failover, the passive node becomes the active node, and the virtual hostname and virtual IP address are now associated with the new active node.
Figure 7-1 shows a diagram of a cold failover cluster database on UNIX; Figure 7-2 shows it on Windows. Note the following differences:
On Windows, you need to run Oracle Fail Safe and Microsoft Cluster Server. On UNIX, you run the vendor clusterware.
On Windows, you install the database ORACLE_HOME on the local storage of each node. On UNIX, you install it on the shared storage. For both UNIX and Windows, the data files for the database are located on the shared storage.
Figure 7-1 Cold Failover Cluster Database on UNIX
Figure 7-2 Cold Failover Cluster Database on Windows
You can use the Oracle Application Server installer to install a cold failover cluster database that is already populated with the OracleAS Metadata Repository. See the Oracle Application Server Installation Guide for details.
If you already have a cold failover cluster database, you can load the OracleAS Metadata Repository into the existing database using the OracleAS Metadata Repository Creation Assistant. See the Oracle Application Server Metadata Repository Creation Assistant User's Guide for details.
Running and managing a cold failover cluster database is similar to running single-instance database. The only difference is using the virtual hostname instead of the physical hostname.
Before you can start, stop or check the status of Database Console against a cold failover cluster database, you need to set the ORACLE_HOSTNAME environment variable to the virtual hostname. This is required on UNIX platforms. For example, in Figure 7-1, the virtual hostname is db.mydomain.com. You would set ORACLE_HOSTNAME as follows:
C shell:
$ setenv ORACLE_HOSTNAME db.mydomain.com
Bourne or Korn shell:
% ORACLE_HOSTNAME=db.mydomain.com % export ORACLE_HOSTNAME
After setting the variable, you can then run the "emctl action dbconsole" commands, where action is start, stop, or status (for example, emctl start dbconsole).
On Windows, ORACLE_HOSTNAME is set in the Windows registry. You do not need to set it as an environment variable.
Backup and recovery procedures are covered in detail in the Oracle Application Server Administrator's Guide. This section describes backup and recovery details that are specific to cold failover cluster databases.
Backup Considerations
Place archive logs for the OracleAS Metadata Repository on the shared disk. This ensures that when failing over from one cluster node to another in the case of media recovery, the archive logs are also failed over and available.
You can generate archive logs to a local file system. However, make this destination accessible to both nodes so that no matter which node is active, the database instance writes archive logs to the same location. Otherwise, the backup operation will not be able to see all the archive log files.
Plan your capacity requirements carefully to ensure that you have adequate space to store the desired number of archive logs.
Recovery Considerations
There are no special considerations for recovering a cold failover cluster database. If you store archive logs on a local file system, in the case of media recovery, you must make all archive logs be available to the Oracle Application Server instance performing the recovery. You can perform the recovery from either node of the cluster.
If You Are Running on Microsoft Windows
One of the steps that you have to do to prepare your OracleAS Metadata Repository for backup using the OracleAS Backup and Recovery Tool is to run the "alter database archivelog" command to enable ARCHIVELOG mode. See the "Enabling ARCHIVELOG Mode" section in the Oracle Application Server Administrator's Guide.
However, if Oracle Fail Safe has database polling enabled, the following error message will appear when you run the command:
ORA-01126: database must be mounted EXCLUSIVE and not open for this operation
To avoid this error message, you need to disable database polling in Oracle Fail Safe. To do this:
Start Oracle Fail Safe Manager.
Expand the following: Clusters > cluster_name > Cluster Resources, and select db_instance_name.
cluster_name is the name of the cold failover cluster, and db_instance_name is the name of the database instance.
Select the Database tab.
Disable Database Polling.
After completing the backup or restore operation, you can re-enable database polling.
You need to disable database polling because the OracleAS Backup and Recovery Tool shuts down the database. On Windows, Oracle Fail Safe performs database polling and restarts the database if it is down. This means that every time before you perform "backup_cold" or "restore_repos" with the OracleAS Backup and Recovery Tool on the active node, you must disable database polling in the Oracle Fail Safe Manager and re-enable it after the backup/restore operation.
Database polling opens the database and monitors or "pings" the database. For the "alter database archivelog" command to succeed, make sure database polling is disabled and the database is mounted EXCLUSIVE before executing the command.
In the failover operation, you need to fail over the virtual hostname and IP, and also the shared storage to the standby node. For details, refer to the instructions provided by your vendor clusterware.
You can also use a Real Application Clusters database for the OracleAS Metadata Repository database. In a Real Application Clusters database, you have multiple database instances running on different nodes and sharing access to an Oracle database. These database instances are linked by an interconnect.
The multiple database instances in a Real Application Clusters configuration provide high availability through redundancy. A Real Application Clusters configuration also provides scalability: you can simply add nodes to the cluster (for example, to handle increased traffic or to improve performance).
You need to use the Oracle database installer to install a Real Application Clusters database. Refer to the Real Application Clusters installation guide that is shipped with the database for details.
After you have installed a Real Application Clusters database, you can load the OracleAS Metadata Repository into the Real Application Clusters database using the OracleAS Metadata Repository Creation Assistant. See the Oracle Application Server Metadata Repository Creation Assistant User's Guide for details.
For details on administering Real Application Clusters databases, including performing procedures such as:
stopping and starting database instances
adding and deleting nodes and database instances
managing storage
managing backup and recovery
troubleshooting
see the Oracle Real Application Clusters Administrator's Guide. You can find this guide in the Oracle Database documentation set.
There are other types of solutions that provide high availability for the database. You can install the OracleAS Metadata Repository in such databases using the OracleAS Metadata Repository Creation Assistant. Examples of such solutions include storage snapshots, cloning, or local data guard. These solutions create a copy of the database from which you can perform a restore operation if the database fails. See the database documentation for details on these solutions.
To check the status of the OracleAS Metadata Repository database, run the following commands:
Connect to the database and check its state:
ORACLE_HOME/bin/sqlplus /nolog SQL> connect SYS as SYSDBA SQL> select status from v$instance;
Check the status of the database listener:
ORACLE_HOME/bin/lsnrctl status
