RE: Re: Sizing - RAC, storage subsystem EMC

> -----Original Message-----
>
> Can someone please suggest if it is a basic database design
> flaw which leads to the requirement of such costly technologies
> like RAC in the first place?
> (I mean if the dataset is huge why not use transportable
> tablespaces
> and keep 'regularly purging' the database of 'old data'?)
>

If I interpret this correctly, this seems to be related to getting datafiles from a dead server to a fail over server??

One simple way to do this is have I/O connections from both boxes to the storage. Then, if fail over is required, mount the storage on the fail over box and start the database. This can be automated, but some care and testing is required to make absolutely sure that the fail over will never mount the storage and try to run the database at the same time as the primary. When the primary is fixed, make absolutely sure that it can't mount the database file systems and start the database until the secondary has been shutdown. Allowing both boxes to run the database will trash your database. "Geez, one little semicolon out of place in the fail over scripts ..."

If you can stand an outage long enough for an operator to manually verify that the primary box is dead and manually run the fail over, etc., I think that best fits the K.I.S.S. philosophy. And my experience with Sun and IBM is that a set up with fault tolerant storage, such as 0+1, will run for YEARS without problems.

> (oh ok..now please dont take it personally and assume
> that I am nit picking on someone/anyone who is
> using/recommending RAC
> ....it is just that I want to explore and understand
> alternatives!)
>
> Can someone point to some 'good reasons'
> (please do not cut and paste from Oracle documents!!)
> where RAC
> was the 'only possible solution available' ?
>

As I think was previously said, RAC is for when the database absolutely, positively can't be down; for example, if it services something like the New York Stock Exchange.

If you can tolerate a short outage, then you can use a standby database, or you can use the technique I previously described of manually moving file system mounts from one box to another.

You want a case study? Here you go:

Another thing to investigate is Transparent Application Fail over (TAF). This is a fail over handled entirely by sqlnet. The rate quoting database used by www.dollar.com uses this. In our case, rate updates are done in the primary database, and the tables that supply the rates in the primary and secondary databases are kept in sync using simple replication every five minutes. If the primary fails, you might have a situation where the rates in the secondary have not been updated, and rate updates must stop until the primary is back up; but we can live with that. Getting the syntax correct in the sqlnet files requires a bit of trial, error, and foul language. If your application will work with TAF, it has proven to be reliable for us.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephen Lee
  INET: Stephen.Lee_at_DTAG.Com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).