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

"Richard" <qaz1521_at_hotmail.com> wrote in message news:bjgeei$34k$1$8300dec7_at_news.demon.co.uk...
> Real Application Clusters used to be called Parallel Server.

Don't let Larry catch you saying that!! RAC is a completely new product, new technology, never seen before, dropped out of the sky etc etc etc. But between you and me, oh OK... it's Parallel Server (aka "OPS") but with some very striking enhancements indeed that makes it, practically, a quite different beastie altogether. Cache Fusion is the buzzword that our Original Poster probably wants to read up on, as compared with 'block pinging' or 'forced disk writes'.

>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.

The database in a RAC just happens to be stored on a disk or array to which each of the machines in a cluster has co-equal access. That's all.

>In my opinion, the main advantages are
> redundancy and scalability. If one of the nodes in your cluster goes
down,
> the others continue working. If your cluster starts getting overloaded,
you
> can add more nodes.

Mmmm. Sort of. In practice, adding nodes takes a greater and greater overhead, and things can start slowing down. The interconnect between the nodes of your cluster becomes a primary determinant of scalability, in other words.

Redundancy of nodes is certainly true, though you still have a single point of failure in that the database resides on a single shared disk/array. RAID will help there, though -though not perfectly, as you go on to point out.

> The main disadvantage is that RAC depends on the clustering solutions
> offered by your server manufacturer. This can mean that the nodes in your
> cluster need to be physically close together. Hence if you get a disaster
> like a fire in your data centre, the entire cluster can be destroyed.
> Redundant nodes won't save you. I've heard that some operating systems
> (VMS?) can implement clustering over a wide area. I'd be interested to
hear
> from anybody who knows about this.

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.

>Also, I've seen presentations by Compaq
> showing a wide area clustering technique linking nodes with a fibre that
can
> be thousands of meters long. Not much use though unless you are in a
campus
> environment where you have access to cable ducts to string the fibre
between
> buildings.
>
> 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 ;-)

>Here you have redundancy among nodes but
> the disk array or hub still forms a single point of failure. You can
> mitigate this to some extent using RAID arrays but, in a catastrophe like
> 9/11 or the Canary Wharf bomb, you still lose the lot.

True, true.

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!!

>
> I think data guard has always been called data guard but I believe there
is
> a similar product called Fail Safe that is only available for Windows
> platforms.

Not quite. Data Guard is just a new marketing term for ye olde Standby Database. The name actually surfaced in 8i, where a product of that name basically consisted of a number of scripts for automating the failover of the primary database to the standby. The 9i Data Guard is a much richer product than that, offering complete fault tolerance and zero data loss.

Fail Safe is a completely different product that is, indeed, for Windows only. It is, essentially, a RAC-like solution without the RAC. Trouble with Windows Advanced Server is, you see, that RAC actually won't work on it if you choose to install the Microsoft Cluster Services component (because it doesn't permit co-equal ownership of the shared disk resource). So, if you have a Windows Cluster, and want the failover/redundancy capabilities of RAC, Fail Safe provides it. Only one node of the Windows cluster is ever actually the active node for a given database, and when it fails, the instance is re-started from scratch on the surviving node (compare that with a true RAC solution, where there are two (or more) instances concurrently running. Nothing needs starting from scratch in a true RAC, because the instance was already running on the surviving node). Disadvantages: failover takes longer. Massive advantage: it's not RAC, and therefore there's no RAC licence to pay for (which, last time I looked, was extremely pricey).

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.

>I've never used data guard but my understanding is that you have
> a primary node and one or more secondary nodes. As redo logs are
generated
> they are copied to the secondary nodes. The secondaries run in continuous
> backup recovery mode and apply the archived redo logs as they are
received.
> Interconnection can be achieved using an ordinary wan link so your nodes
> can be widely separated. Unlike RAC, this provides protection against
> disasters. If your primary data centre burns down, your secondary nodes
can
> be hundreds of miles away so they will still be available.
>

As I say, Data Guard is simply the old Standby Database on steroids. There are new enhancements to the old standby model whereby LGWR can be used to transmit redo to the remote database synchronously, instead of ARCH doing so asynchronously. That means (in theory) you can activate the remote site to be the new primary without any data loss (in old standby, the fact that ARCH had to wait for a log switch before being able to transmit anything meant that you were likely to lose the redo stored in the current online redo log in the event of a disaster at the primary site).

The other new feature in Data Guard is that your standby database no longer needs to be an exact physical replica of your primary. The "logical standby database" means that provided the *schemas* are identical between the primary and the standby, replication of redo can still cope.

> The disadvantage with data guard is that your databases are not
> synchronised. Some delays are inevitable while the redo log is being
built
> up and then transmitted.

Not actually true any more. In 9i, the standby can be in an identical state to the primary, with no delays (other than those inevitably arising from the time it takes to actually transmit redo down a wire). At the highest level of Data Guard protection, if there's anything happening on primary which can't be transmitted to the standby, the primary will be shut down to prevent data divergence. Since you then can't do anything on primary, the standby cannot be out of sync with it.

It is true, however, that that's only the case for the highest form of protection. At the other levels of protection, you can configure how much out-of-synch-ness you are prepared to tolerate.

Regards
HJR
>Another option, replication, allows changes to be
> committed in smaller chunks over a WAN so your databases are out of sync
for
> shorter periods. Replication can be tricky to implement though.
>
> Best wishes,
>
> Richard
>
> "Eric" <eric32_at_hotmail.com> wrote in message
> news:AyN6b.437$fC5.147403_at_news20.bellglobal.com...
> > Hi all,
> >
> > I have some confusion about Oracle 9i's new components.
> > What are the differences between Real Application Clusters, Guard I and
> > Guard II? What are their corresponding components names in the previous
> > releases?
> >
> > Thanks!
> >
> > Eric
> >
> >
> >
> >
>
>
Received on Sun Sep 07 2003 - 20:31:02 CDT