If the master component of the hot standby system breaks down, then a standby component automatically assumes the function of the master component.
The hot standby configuration does not provide any protection against errors and inconsistencies caused by the user or by an application. To prevent these types of errors, you have to perform regular data and log backups even in a hot standby system.
If such errors occur, you have to resort to importing data and log backups up to a certain point in time. For more information about this, see the documentation for the Database Manager GUI: Restoring Data and Database Manager CLI: Backing Up and Restoring Database Instances.
The cluster software constantly monitors the master component of the hot standby system.
...
1. When the master component fails, the cluster software defines one of the standby components as the new master component and sends corresponding information to the standby component.
2. The new standby component assumes the virtual server name of the master component, with which the system is addressed externally.
3. The standby component is given write rights for the log area and reads the last log entries that have not yet been read, particularly all transactions that were completed with a COMMIT.
4. The database system transfers the standby component to ONLINE operational state.