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

Home -> Community -> Usenet -> c.d.o.server -> Re: What are the differences between Real Application Clusters, Guard I and Guard II?

Re: What are the differences between Real Application Clusters, Guard I and Guard II?

From: Richard <qaz1521_at_hotmail.com>
Date: Mon, 8 Sep 2003 19:04:55 +0100
Message-ID: <bjigc9$hjg$1$8300dec7@news.demon.co.uk>


> Don't let Larry catch you saying that!!

I'd better not! I once saw a video of him demonstrating OPS. Larry pulls a lever in the data centre and a lightning bolt strikes one of his servers (shades of Michelangelo's 'Creation of Adam' here - what's going on in Larry's head?). Not to worry though. Larry's running OPS so everything's OK. Of course, in practice, Larry, his cluster and anything else in the vicinity would be black and crispy after an event like that but when did Oracle ever let the laws of physics interfere with marketing?

Cache Fusion is the buzzword that our Original
> Poster probably wants to read up on, as compared with 'block pinging' or
> 'forced disk writes'.

I had a very brief look at an Oracle white paper about this. As far as I can see, this means that each instance has its own buffer cache and the caches are synchronised by passing data through the cluster interconnect rather than via the database files on disk as in OPS. Is this about right?

> >You can think
> > of it as a number of physically separate computers each containing a
> > synchronised copy of the database.
>
> No, you can't think of it that way at all. In a RAC, there is only ONE
> database, but with multiple co-ordinated instances. There's no duplication
> of the database, and there's no duplication of the instances, either. Each
> instance is entirely independent of the others, but access to database
> resources is co-ordinated between them by the cluster management and CGS
> software components.

You are absolutely right. I tried to oversimplify my response by referring to the database instead of to the instance. What happens with the 'shared nothing' clusters that Oracle refers to? If the nodes in the cluster have no shared disks, surely each node must maintain a local copy of all of the database files. I suppose if these files are synchronised by the clustering system then, from a user perspective, you really only see one set of files so it looks like a shared disk cluster but without the single point of failure.

> I have heard rumours of a RAC in Beijing where the nodes are separated by
> 18kms. Quite why anyone would do that, I have no idea. And it could just
be
> rumour.
>

I heard a similar story about American Express splitting an OPS cluster between Brooklyn and Manhattan. This must be to protect against catastrophe. Perhaps Beijing is prone to natural disasters or prolonged power cuts.

> > Another problem is that some clusters consist of a number of nodes
> connected
> > to a communal disk array or hub.
>
> Er, all clusters do that. That's one of the definitions of a cluster ;-)

Are you sure? I don't know enough about clustering hardware to speak with any authority but I thought some clusters used the 'shared nothing' approach that Oracle refers to in its documentation. This would get around the single point of failure problem caused by shared disk arrays or a hub as well as the proximity vulnerability caused by having to locate all your nodes close together. I suppose there must be disadvantages with the shared nothing approach though (interconnect cost, latency etc) as it doesn't seem to be very popular.

> Which makes the comment I had from one student all the more worrying: "we
> don't need to do backups because we've got RAC". Yikes!!

Sounds like you need to offer the student's boss some consultancy (for a handsome fee of course).

> Real Application Clusters Guard (which is what I assume the Original
Poster
> meant by "Guard II") is a sort-of Fail Safe for non-Windows products (or
> even for Windows products). It's a 2-node solution that is genuinely a
RAC.
> An Instance runs on both nodes, accessing the one database, but Users can
> only connect to one of the instances (the "primary" instance). When the
node
> that instance is running on fails, various monitors that are installed as
> part of Clusters Guard detect the failure, and promote the secondary node
to
> being the new primary. It was already running an instance (this is a
genuine
> RAC solution, after all, unlike Fail Safe), and so failover should be
> quicker than for Fail Safe or other host-based solutions. Basically, you
> install Clusters Guard when you want the redundancy features of RAC, but
> don't need or want the scale-up and speed-up that RAC can often supply,
and
> hence one active node at a time is suitable for your use.

Presumably it also has the cost advantages of the Fail Safe product.

I'm getting too old to keep up with all the new features in Oracle, especially now Oracle 10 is on the horizon. I feel a change of career coming on. Do you think Larry might be looking for a highly paid lifestyle consultant?

Many thanks for your very informative response.

Richard Received on Mon Sep 08 2003 - 13:04:55 CDT

Original text of this message

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