A hot standby system consists of a master and one or more standby components. The hot standby system behaves externally like a normal individual database instance.
Within the cluster system, the individual components communicate with each other using internal, local addresses.
The following information is required to access a hot standby system:
· Name of the database instance (HOTELDB in the figure)
· Virtual Server Name (HOTEL_VIRTUAL in the figure): identifies the computer that is currently the master component. If the master component fails, then the Virtual Server Name goes over to the standby component, which takes on the master role.
Example of setting up a hot standby system
The standby components are in the STANDBY operational state, which corresponds to a state between ADMIN and ONLINE. A standby component in STANDBY operational state is not a real instance; it becomes one only after the master instance has failed and the standby component assumes its function.
Master and standby components use the same database parameters. To change database parameters, execute the corresponding DBM command on the master component. The changes are transferred by the system to all standby components.
Master and standby component use the same log area, although the standby components only have read access to this.
Unlike a hot standby system, standby databases have separate log areas for all instances.
To protect against hardware errors, we recommend that you mirror the log area in a hot standby system.
Master and standby components each have separate data areas that are independent of each other. They also have their own kernel, cache, a separate X Server, DBM Server and so on.
Access to a shared log area
See also:
Synchronizing Master and Standby Components