Yes, RAC is not transparent. And RAC is not 100% reliable in case of crashed
(not delibirate shutdowns).
I put my manual, how to install it, on http://ftp.portera.com/Linux/, but it
is installation only (and I had an issues wghen tried to migrate lab onto
10.2.0.2 from 10.2.0.1, more likely because of hugetlb). But, again, don't
be confused - RAC provide _no short service interruptions_ service, but not
_HA access_ (in reality) - the chance of fatal failure in RAC is high enough
because of extra complexity.
----- Original Message -----
From: <CLEMENS.BLEILE@(protected)>
To: "Tom Corr" <tcorr@(protected)>
Sent: Friday, September 22, 2006 9:15 AM
Subject: AW: [suse-oracle] Oracle 10g R2 RAC on SLES 9
>
> Hi Tom,
>
> concerning 1.) you may check those links:
>
>
http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/9i_jdbc/OCIdriverTAFSample/Readme.html
>
> http://www.ioug.org/client_files/members/select_pdf/04q1/JAVA.pdf
>
> Concerning 2.) Did you test this with sqlplus ? You may run in sqlplus-Bug
5474008. There's a patch available on Metalink. But the Service should
actually not "crash". BTW what do you mean with "crash"? What's the output
of "crs_stat <service-resource>"?
>
>
> BTW, where did you get 10.2.0.3 from? It is not available yet.
>
>
> Ciao
>
> Clemens
>
>
> --- Originalnachricht ---
> > 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
>
>
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
