FAILOVER:
In the context of Oracle Net, failover refers to the mechanism of switching over to an alternate resource when connection to the primary resource gets terminated due to any reason. Connection failure may be broadly categorized as:
Those that occur while making the initial connection. (Connect Time Failover)
Those that occur after a connection has been successfully established. (TAF)
The first category of connection failure can be dealt with comparatively easily. If your attempt to connect to an instance fails, you can make the connection attempt again, but this time to a backup instance. As long as you have backup instances configured, you can continue trying to connect, until a successful connection is established. This process is technically termed as Connect Time Failover.
Connect Time Failover.
The connect time failover feature allows client to connet to another listener if the initial connection to the first listener fails.Multiple listener locations are specified in the client tnsnames.ora file. If a connection attempt to the first listener fails , a connection request to the next listener in the list is attempted .You can acheive this feature by adding Multiple listener addresses within an address list of tnsnames.Here is an example of what a tnsnames.ora file looks like with a connect-time failover enabled.
TNS Parameter for Connect time failover is FAILOVER. Default value of this is ON.
(failover=on) is default for ADDRESS_LISTs and DESCRIPTION_LISTs , so we do not need to explicitly specify this parameter to put it on.
Sample for TNS net service alias for Client Side Connect time Failover :-
myrac_failover =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1522))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1522))
)
(CONNECT_DATA =
(SERVICE_NAME = myrac)
)
)
Notice the additional entry under the ADDRESS_LIST section. Here two listener are specified .If a connection is unsuccessful when attempting to connect to the rac1-vip host on port 1521, a connection attempt is made to the rac2-vip host on port 1521 .
Note:- Entries in the ADDRESS_LIST do not have to be a RAC nodes . The example that i explained here is for two node RAC database. You can also configure connect-time failover with a standby database , so that one of the entries in the list may be a standby database .As long as the defined service(Database) in the ADDRESS_LIST is availabe on the other
node , client is able to connect to that node.
For example,
failover_norac=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=TCP) (HOST=prod_db) (PORT=1521))
(ADDRESS= (PROTOCOL=TCP) (HOST=standby_db) (PORT=1521))
(FAILOVER= TRUE)
)
(CONNECT_DATA=
(SERVICE_NAME= orcl)
)
)
The other criteria, of cource , that the address in the list will allow the client to get to the data that is needed by the application. With oracle RAC , we know that data is always the same, as it is the same database. In the case of physical or logical standby database
whether or not the data is accessible depends upon how these standby database is configured.
Note:- An important issue to be aware of at this point is that Connect Time Failover only works for you, if you are using dynamic registration.
Transparent application failover (TAF)
Now, let’s look at how TAF works. Unlike connect time failover, which is invoked before the connection is made, TAF comes into play after the connection is made (and then, broken). If the connection is lost while the application is running, Oracle Net will transparently reconnect the application to another instance accessing the same database.
TAF supports two types of failover: SESSION and SELECT. A SESSION failover connection is not over ambitious. It just fails over to a backup instance. All work in progress at that point are irrevocably lost. SELECT failover is more intricate in as much as it enables some type of read only application to failover without losing the work in progress. If a SELECT statement was in progress at the time of the termination of the connection, then as the connection is reestablished to a backup instance, Oracle Net re-executes the SELECT statement and positions the cursor in a manner that the client can seamlessly continue fetching the rows. But that’s about all that TAF has to offer. It doesn’t have any mechanism to recover DML statements that were in progress, when the failure occurred, or even for SELECT statements, you lose global temporary tables, package states and session settings.
TAF supports two failover methods: BASIC and PRECONNECT. In BASIC method, you connect to the backup instance when the primary connection fails. In the PRECONNECT method, you connect to the backup instance at the same time you connect to the primary instance. This has the obvious benefit of having a backup connection available all of the time, thus reducing the time of ‘failover’. But the downside is that you have to pay the extra ‘cost’ in terms of resources spent, of having a backup connection open all the while.
TAF is configured by adding a FAILOVER_MODE parameter to the CONNECT_DATA parameter for a net service name. Below is an example for configuring TAF with two node RAC
Note:-
Specifies a different net service name to be used to establish the backup connection. A backup should be specified when using PRECONNECT to pre-establish connections. Specifying a BACKUP is strongly recommended for BASIC methods; otherwise, reconnection might first attempt the instance that has just failed, adding additional delay until the client reconnects.
http://oracleinquisitive.blogspot.in/2012/09/transparent-application-failover-taf.html
In the context of Oracle Net, failover refers to the mechanism of switching over to an alternate resource when connection to the primary resource gets terminated due to any reason. Connection failure may be broadly categorized as:
Those that occur while making the initial connection. (Connect Time Failover)
Those that occur after a connection has been successfully established. (TAF)
The first category of connection failure can be dealt with comparatively easily. If your attempt to connect to an instance fails, you can make the connection attempt again, but this time to a backup instance. As long as you have backup instances configured, you can continue trying to connect, until a successful connection is established. This process is technically termed as Connect Time Failover.
Connect Time Failover.
The connect time failover feature allows client to connet to another listener if the initial connection to the first listener fails.Multiple listener locations are specified in the client tnsnames.ora file. If a connection attempt to the first listener fails , a connection request to the next listener in the list is attempted .You can acheive this feature by adding Multiple listener addresses within an address list of tnsnames.Here is an example of what a tnsnames.ora file looks like with a connect-time failover enabled.
TNS Parameter for Connect time failover is FAILOVER. Default value of this is ON.
(failover=on) is default for ADDRESS_LISTs and DESCRIPTION_LISTs , so we do not need to explicitly specify this parameter to put it on.
Sample for TNS net service alias for Client Side Connect time Failover :-
myrac_failover =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1522))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1522))
)
(CONNECT_DATA =
(SERVICE_NAME = myrac)
)
)
Notice the additional entry under the ADDRESS_LIST section. Here two listener are specified .If a connection is unsuccessful when attempting to connect to the rac1-vip host on port 1521, a connection attempt is made to the rac2-vip host on port 1521 .
Note:- Entries in the ADDRESS_LIST do not have to be a RAC nodes . The example that i explained here is for two node RAC database. You can also configure connect-time failover with a standby database , so that one of the entries in the list may be a standby database .As long as the defined service(Database) in the ADDRESS_LIST is availabe on the other
node , client is able to connect to that node.
For example,
failover_norac=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=TCP) (HOST=prod_db) (PORT=1521))
(ADDRESS= (PROTOCOL=TCP) (HOST=standby_db) (PORT=1521))
(FAILOVER= TRUE)
)
(CONNECT_DATA=
(SERVICE_NAME= orcl)
)
)
The other criteria, of cource , that the address in the list will allow the client to get to the data that is needed by the application. With oracle RAC , we know that data is always the same, as it is the same database. In the case of physical or logical standby database
whether or not the data is accessible depends upon how these standby database is configured.
Note:- An important issue to be aware of at this point is that Connect Time Failover only works for you, if you are using dynamic registration.
Transparent application failover (TAF)
Now, let’s look at how TAF works. Unlike connect time failover, which is invoked before the connection is made, TAF comes into play after the connection is made (and then, broken). If the connection is lost while the application is running, Oracle Net will transparently reconnect the application to another instance accessing the same database.
TAF supports two types of failover: SESSION and SELECT. A SESSION failover connection is not over ambitious. It just fails over to a backup instance. All work in progress at that point are irrevocably lost. SELECT failover is more intricate in as much as it enables some type of read only application to failover without losing the work in progress. If a SELECT statement was in progress at the time of the termination of the connection, then as the connection is reestablished to a backup instance, Oracle Net re-executes the SELECT statement and positions the cursor in a manner that the client can seamlessly continue fetching the rows. But that’s about all that TAF has to offer. It doesn’t have any mechanism to recover DML statements that were in progress, when the failure occurred, or even for SELECT statements, you lose global temporary tables, package states and session settings.
TAF supports two failover methods: BASIC and PRECONNECT. In BASIC method, you connect to the backup instance when the primary connection fails. In the PRECONNECT method, you connect to the backup instance at the same time you connect to the primary instance. This has the obvious benefit of having a backup connection available all of the time, thus reducing the time of ‘failover’. But the downside is that you have to pay the extra ‘cost’ in terms of resources spent, of having a backup connection open all the while.
TAF is configured by adding a FAILOVER_MODE parameter to the CONNECT_DATA parameter for a net service name. Below is an example for configuring TAF with two node RAC
Note:-
Specifies a different net service name to be used to establish the backup connection. A backup should be specified when using PRECONNECT to pre-establish connections. Specifying a BACKUP is strongly recommended for BASIC methods; otherwise, reconnection might first attempt the instance that has just failed, adding additional delay until the client reconnects.
http://oracleinquisitive.blogspot.in/2012/09/transparent-application-failover-taf.html
No comments:
Post a Comment