Re: Client reconnection after node failure under 9i RAC?

In article <397070c1.0203250246.3949e9be_at_posting.google.com>, peter.bates_at_ditm.nsw.gov.au says...
>
>Hi,
>I've got a few questions about oracle 9i Real Application clusters.
>
>If a node in the cluster fails, what happens to the clients connected
>to that node?
>
>I've seen a few demos of this product in which the client (SQL PLUS)
>kept on processing after a node failure. However, is this a function
>of the server, or of the client?
>
>To restate the question, do clients have to be re-designed in order to
>take advantage of seemless failover in 9i?
>
>Thanks

Peter

It depends on whether you have Transparent Application Failover configured or not, and on whether your application code is compiled with the OCI8 libraries (or above). The easiest way to demo RAC failover from one node to another is to use a SQL*Plus session, because it is compiled with the OCI8 libraries, and TAF is pretty straight forward to set up with it (a few changes to your tnsnames entries is all that's needed).

Now the applications that might have problems with this are ones that contain state. From meory, the Developer/2000 tools still have this issue. Connections via SQL*Plus, JDBC (thick driver) and (I think) ODBC are OK. Could be wrong on the ODBC connections though. If you have a web based application, it can be pretty easy to set up to use TAF as well.

TAF has a couple of different failover modes. The default is NONE (i.e. not turned on). You can also have it set to SESSION (fails over the session but you need to re-execute your last statement), or SELECT (Fail over the session and continue the query). You can even set it up to have the session PRECONNECT if you want to. One thing that you can't yet failover (but we're a'workin' on it!) is DML, because it's always stateful.

More details in the Net Services Administrator's Guide, Chapter 15, if you're interested.

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Mon Mar 25 2002 - 10:37:28 CST