Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Is RAC DOA?

Re: Is RAC DOA?

From: Ray Stell <stellr_at_cns.vt.edu>
Date: Tue, 17 Aug 2004 13:48:22 -0400
Message-ID: <20040817174822.GA22196@locust.cns.vt.edu>


I tried to create as disturbing a subject line as I could to get attention. Thank you for all your responses, very interesting.

There were some replies on my first query topic that led me to believe the waters had been muddied here. I originally posted about a public network failure and the responses on this topic where about the private net. I have posted privately to those who showed an interest in this. I thought I'd try to stir up some trouble here in hopes that a clue would float up to the surface for me.

So, there are two parts here:
I. my techie problem
II. my Oracle Corp. TAR experience

I. techie problem:



environment:
1. Oracle 10.1.0.2 (10.1.0.3 came out this week, I'll go there next,

   but my tar consultant doesn't think it will be fruitful)

2. 2 - Red Hat 3.0 intel x86 servers
3. 1 - shared disk on NetApp filer
4. Oracle clustering, CRS
5. 1 - client running running same OS and Oracle versions
6. cluster/client configured to failover and load balance across 

   the two servers
7. note that in this configuration, an instance failure (shutdown

   abort) fails over perfectly, long running queries fail over immediately,    sometimes I could not even detect it had happened during the output    display (very cool, btw)

test:

1. sqlplus connect to cluster
2. determine which node I get connected to
3. run long running query on that node
4. inject a network failure on server interface the client is

   connected to

5. sessions to other node are locked up.
6. long running query fails, ends in ora-3113
7. watch both nodes stay locked up until network is restored

Can anyone verify that you have seen RAC recover from this sort of failure? Thanks for your help.

II. my Oracle Corp. experience:



I open a TAR to review the issue. Everyone (me, Oracle TAR consultant, developer he is consulting with) from the start thinks we have a config problem and assume this can be worked around. This implies to me that it is believed that RAC can survive public network failures. I can't for the life of me figure out now why we all thought this. I've gone back to the docs and searched. There seems to be little detail on what high availability means in practice.

I spent a month working a TAR over the effect of a public network failure on the cluster. We work on fixing my config, since it must be the source of the problem. A month later, they come back to me and say this is a "bug" that will not be fixed as it is considered a new feature request. What's the bug number? "2791912". Not found.

Now, my tar is not closed, yet. I have posted to the consultant these questions:

  1. Can I get the real bug number? Can I read any of the detail?
  2. Why did he think this should work when we started?`
  3. Why is this considered a "bug"? Do interal Oracle people think this should work under some configuration?
  4. Are there other hardware/software combinations that I might try to test that are not subject to this mystery bug?
  5. Does this make Linux not a viable/supported platform for HA?

No response since last Friday. Maybe they're on vacation before the kids go back to school. As one person put it, "we started (our) company because we saw what a disaster Oracle was making out of a pretty cool technology." ;)



Ray Stell stellr_at_vt.edu (540) 231-4109 KE4TJC 28^D

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 Aug 17 2004 - 12:45:46 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US