Tom
Configuring client side for Load Balancing where the IP addresses
are referring to the VIP'S NOT to the "real" IP'S). The node running
the query was brutally crashed and the session was failed over where
from client side the process was totally transparent up to the point
that the query was finished successfully .
To be very clear here , nothing was done to the APP code to achieve
this.
Yoav
-----Original Message-----
From: Tom Corr [mailto:tcorr@(protected)]
Sent: Friday, September 22, 2006 2:24 PM
To: suse-oracle@(protected)
Subject: [suse-oracle] Oracle 10g R2 RAC on SLES 9
All -
I'm more interested in your comments concerning RAC in general. We seem
to
have had a really difficult time getting it to run correctly - even with
Oracle consulting involved...
Basically, we have a two node oracle cluster, each with 2 amd opterons
and
each with 12 gig of ram. SLES9 SP3 is the OS. We are running Oracle
10.2.0.3 database and RAC.
Anyhow, here are my observations so far:
1 - RAC really isnt a "transparent" solution to anyone. That is though,
queries will fail over from one node to another thats about it.
Prepared
statements do not fail over. So application logic has to be made aware
of
which node they are running on, and in the event they end up on a
different
node, they must re-prepare all statements. The same holds true of
cursors.
This does not seem like a very transparent application failover to me...
I
was coding this kind of logic some years ago... That is the application
must
be coded to trap errors from sql statements, and then try to re-prepare
statements all over again.
2 - The named services that you set up from with DBCA or srvctl. To get
around problem from above, I decided to make one node "preferred" and
the
other node "available". I then just ran a simple script that would
connect
to the "preferred" node in the background and query host_name from
v$instance. While the script was running we crashed the preferred node.
Just so we can see if connections would end up on the "available" node.
they
did not. As a matter of fact the SERVICE ended up crashing too, as
reported
from "crs_stat -t". We are now debugging the "crs logs" to see what
happened. we can now, no longer modify the service with DBCA, we can
only
use the command line srvctl command...
Has anyone else had any other experiences with RAC? Does anyone know of
work
arounds or solutions to the issues mentioned above?
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
