| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RAC, TAF, ... do they really work?
Jose,
From the Oracle Manuals an excerpt.
Kind Regards,
Robert.
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c01_02intro.htm#44932
Oracle9i Database Concepts
Release 2 (9.2)
Transparent Application Failover
Transparent Application Failover (TAF) enables an application user to
automatically reconnect to a database if the connection fails. Active
transactions roll back, but the new database connection, made by way of
a different node, is identical to the original. This is true regardless
of how the connection fails.
With Transparent Application Failover, a client notices no loss of
connection as long as there is one instance left serving the
application. The database administrator controls which applications run
on which instances and also creates a failover order for each application.
Elements Affected by Transparent Application Failover During normal client/server database operations, the client maintains a connection to the database so the client and server can communicate. If the server fails, so then does the connection. The next time the client tries to use the connection the client issues an error. At this point, the user must log in to the database again.
With Transparent Application Failover, however, Oracle automatically obtains a new connection to the database. This enables users to continue working as if the original connection had never failed.
There are several elements associated with active database connections. These include:
· Client/Server database connections · Users' database sessions executing commands · Open cursors used for fetching · Active transactions · Server-side program variables
http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96580/advcfg.htm#479015 Oracle9i Net Services Administrator's Guide Release 2 (9.2)
What TAF Restores
TAF automatically restores some or all of the following elements
associated with active database connections. Other elements, however,
may need to be embedded in the application code to enable TAF to recover
the connection.
Client-Server Database Connections
TAF automatically reestablishes the connection using the same connect
string or an alternate connect string that you specify when configuring
failover.
Users' Database Sessions
TAF automatically logs a user in with the same user ID as was used prior
to failure. If multiple users were using the connection, then TAF
automatically logs them in as they attempt to process database commands.
Unfortunately, TAF cannot automatically restore other session
properties. These properties can, however, be restored by invoking a
callback function.
Executed Commands
If a command was completely executed upon connection failure, and it
changed the state of the database, TAF does not resend the command. If
TAF reconnects in response to a command that may have changed the
database, TAF issues an error message to the application.
Open Cursors Used for Fetching
TAF allows applications that began fetching rows from a cursor before
failover to continue fetching rows after failover. This is called
"select" failover. It is accomplished by re-executing a SELECT statement
using the same snapshot, discarding those rows already fetched and
retrieving those rows that were not fetched initially. TAF verifies that
the discarded rows are those that were returned initially, or it returns
an error message
Active Transactions
Any active transactions are rolled back at the time of failure because
TAF cannot preserve active transactions after failover. The application
instead receives an error message until a ROLLBACK is submitted.
Serverside Program Variables
Serverside program variables, such as PL/SQL package states, are lost
during failures; TAF cannot recover them. They can be initialized by
making a call from the failover callback.
Jose Manuel Quesada wrote:
> Hi guys.
> This is a question
>
> As far as I know, RAC enables a database to work in a cluster mode, making it to a node crash. The client connections attached to the dead node are lost, however, unless you configure the connections for TAF. The TAF mode rollbacks any transaction on the fly, giving an error. If you develop your code with TAF in mind, you can catch this error and re-run the transaction by means of the TAF reconnection.
> But, if you have tons of lines of code in tens of legacy applications, what can you do to take advantage of this stuff?. Is this technology, in its current status suitable for this scenarios?. Does it provide any benefit?
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
-- Robert Blok Database consultant Bartokstraat 18 robert.blok_at_xs4all.nl 1901 XH CASTRICUM rbserver.xs4all.nl t. +31 (0)251 67 05 33 | f. +31 (0)251 65 82 41 | m. +31 (0)6 51 252 055 === If you think education is expensive, try ignorance. (Derek Bok) === ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Tue Apr 20 2004 - 07:07:37 CDT
 |
 |