Cluster Server 7.4.2 Database Agent for Oracle Configuration Guide - Windows
- Introducing the VCS agent for Oracle
- Installing the product and configuring VCS
- Installing and configuring Oracle
- About installing Oracle
- Prerequisites for installing Oracle
- Installing Oracle
- About creating and configuring Oracle
- Prerequisites for configuring Oracle
- Managing Storage using SFW
- Creating a temporary service group
- Configuring Oracle on the first node
- Bringing the temporary service group online
- Creating the Oracle database on shared disks
- Creating the listener service
- Configuring the listeners to use the virtual IP address
- Associating the database with the listener
- Configuring the Oracle database
- Configuring the Oracle and listener services
- Dismounting a volume
- Configuring Oracle on failover nodes
- Configuring the Oracle service group
- Administering the Oracle service group
- Troubleshooting
- Appendix A. Resource type definitions
- Appendix B. Sample configuration
- Appendix C. Oracle Enterprise Manager 10g Grid Control with VCS
- About Oracle Enterprise Manager 10g Grid Control with VCS
- Installing the VCS agent for Oracle
- Installing Oracle Enterprise Manager server
- Installing Oracle
- Installing the Oracle Management Agent
- Creating and configuring Oracle database and listener on the first node
- Configuring Oracle on failover nodes
- Configuring the Oracle service group
- Configuring a virtual network name
- Configuring the listener for virtual network name
- Configuring the database service for virtual network name
- Configuring an additional Oracle management agent
- Adding the database to the OEM 10g Grid Control
- Making the additional agent highly available
How application availability is achieved in a physical environment
The VCS agents continuously monitor the application, storage, and network components that the application uses in the cluster. The agents are able to detect failures in all of these components. For example, an application-level failure such as a configured application virtual server or application service becoming unavailable, a fault in the storage such as a configured disk becoming inaccessible, or a network failure.
When a fault occurs, VCS fails over the application service group to the next available system in the application service group's system list. A service group failover means that the VCS storage agents deport and import the disks or LUNs on the new system. The VCS network agents bring the network components online and the application-specific agents then start the application services on the new system.
In a disaster recovery cluster configuration, VCS first attempts to failover the application service group within the local cluster. If all the systems in the local cluster are unavailable, VCS attempts to failover the service group to a system at the remote site.
In a NetApp environment, the VCS NetApp agents perform the following actions in that order:
Connect the virtual disks (LUNs) to the target hosts (NetAppSnapDrive agent).
Perform a mirror break that enables write access to the target (NetAppSnapMirror agent).
Reverse the direction of replication by demoting the original source to a target, and begin replicating from the new source (NetAppSnapMirror agent).
If replication is set up using Volume Replicator (Volume Replicator), the Volume Replicator replication agents make the Secondary RVG at the remote site write-enabled so that it becomes the new Primary. After the storage is connected, VCS starts the application services on the new system at the remote site. The data that is replicated to the remote site is used to restore the application services to the clients.