The complexity of the failover process depends on the status of the client applications when the primary database fails. Failover of database applications can be divided into two broad categories, based on the status of the database connection at the time of failure:
- Connect-time failover
This type of
.
- Runtime failover
This type of failover occurs when a client application has already connected to the primary database, and the database then fails. Clients may or may not have an active transaction at the time of the failure.
The following sections describe conceptually the actions that are needed in the backup database in order to re-create the same state for the clients as they had in the primary database at the time the failure occurred.
Tip
Failover does not take care of failure at all levels. If a client application terminates for any reason or if the client system crashes, database failover mechanisms do not help. Failover mechanisms are designed only to handle database failures. In the case of client failure, the client application must be restarted by some other means.
Connect-time failover occurs when the primary database fails either before or during the connection attempt. The only thing then required for a successful failover is for the client application to connect to the backup database instead of the primary database. The only information required for such a failover is the user’s username and password. There is no need to preserve any transaction state, because the failure precedes any database connection—no transactions will be in progress. Connect-time failover is relatively simple to implement, and clients will not notice that a failover has occurred.
In the case of a runtime failover, the client application has already connected to the database server. The complexities of such a failover depend on whether there is an active transaction at the time the failover occurs.
The simplest runtime failover scenario is the case in which the client application has connected to the primary database but does not have an active transaction in progress. In this case, the application will have already established a user session. Some of the session parameters—for example, NLS_LANGUAGE and NLS_DATE_FORMAT—may have been set explicitly by the application using ALTER SESSION commands such as the following:
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MON-DD';
As the application has no open transaction, it will not notice the failure of the primary database until the next transaction begins. In this case, a successful failover requires that two things happen: the application must connect to the backup database, and it must reestablish the same session environment that it had on the primary database. To do this, the application must resubmit the specific statements that were used to establish that environment.
The more complicated runtime failover scenario is the case in which the client application has a transaction in progress when the failover occurs. In this case, when reconnecting to the backup database, the client will need to worry about the following items:
The session environment established using ALTER SESSION commands
Any SQL cursors that were open at the time of failure
PL/SQL package states, which include settings for global variables
Any DML statements that may have been issued before the failure occurred
In order for a successful failover to occur when a client has an open transaction, the following steps must be taken:
The client application must connect to the alternate database.
The client application then must set up the same session environment that was in place on the primary database.
The client application must re-create any package states that were in effect at the time of the failure.
The client application must restart processing from the point at which the failure occurred.
The most difficult item in this list is the restarting of the application that was in progress so that processing continues from the point at which the failure occurred. Failover complexity depends on the type of database transactions within the client application. Transactions involving only SELECT statements are simpler to deal with than those involving INSERT, UPDATE, and DELETE operations. If the application was executing DML statements, some of those may have been committed. For example, a stored procedure may execute two UPDATE statements, and one of those may have already been committed when the failure occurred. When the primary database fails, committed transactions remain in place, but any uncommitted transactions are rolled back. You may need to code restart logic into your applications so that they will know where to pick up working after a failover occurs.