There are many changes, but probably the two biggest ones are:
1) Cache fusion for write-write
In 8i, cache fusion delivers write-read cache fusion. If one instance holds
a "dirty" block that another instance wants to read, it builds and ships a
read-consistent image of the block across the high speed interconnect,
without pinging to disk as was required by previous versions. 9i RAC
extends this functionality to writes from the other instance as well. This
is the main reason that Oracle says that RAC will scale for any
application - indiscriminate writes won't cause the tremendous disk pinging
overhead that it did previously. What this means is that you will want a
fat and fast high speed interconnect since it will be a lot busier than in
previous versions.
2) Simplified lock configuration. Releasable locks have been the default
for some time, but fixed locks (or hash locks) were commonly used for much
of the database in the past. All or most of the locking code has been
rewritten and optimized for releasable locks (my understanding at least).
The use of fixed locks isn't abolished in RAC, but overriding the default
releasable locks will disable cache fusion. What this means is a lot less
configuring, tuning, and general dinking around with gc_ parameters. In any
RAC configuration, I would not override this except as a last resort.
A lot of the "complex" reputation that OPS has from its earlier days is
based on the configuration and tuning of these locks and some of the
associated "partitioning" esoteria. For example, one of the techniques used
(and taught in the v7 OPS ILT class) was of creating tablespaces consisting
of multiple datafiles, assigning fixed locks to those datafiles, manually
allocating extents to different freelist groups in those datafiles, and
modifying the application so that writes/reads to/from a particular
"partition" of the data occur only from one instance. The net result was of
"partitioning" the data in a single table into distinct sets in distinct
datafiles with distinct sets of fixed locks, distinct freelist groups and
accessing a single set only from one instance - if possible - to reduce
pinging and lock transformation overhead. (This is vastly simplified and
perhaps a bit fuzzy to me now. If so, Scott H. will correct it!) This is
where the "your application has to be designed for OPS" over-generalization
comes from. Essentially some form of logical/physical "partitioning" of the
data and access to the data was the key to successfully implementing OPS for
any kind of OLTP-like write intensive system in an active-active mode in the
past. There were/are some other methods of application partitioning also
that were more suitable in specific circumstances, but this was usually
regarded as the base case - for OLTP at least. 8i relaxed this some by
introducing cache fusion, which dramatically reduced the "other instance"
read overhead.
While there are a lot of other improvements for OPS/RAC in 9i, the core of
it, in my opinion, is based on the extension of cache fusion to write-write
scenarios and the changes/optimization for releasable locks. The
combination of the two is supposed to dramatically increase performance as
well as dramatically reduce design and administrative complexity. I haven't
yet had the opportunity to do much of anything with RAC, but I was an early
adopter of v7 OPS and 8i OPS (not much experience with 8.0x OPS) and
developed some close contacts inside Oracle's internal OPS development and
OPS tuning groups. I have great faith in these people - some of the
brightest I've ever met. All the basic elements are there for success.
Even if 9i RAC does come out of the factory with a wheel a bit out of round,
I think they will smooth it out in short order. After all, Oracle is hyping
RAC like the second coming - RAC was even the centerpiece of Larry
Ellision's keynote address at OOW 2000. Much of the technology press
regards RAC as THE seminal "new feature" in 9i. In general, Oracle has put
so many of its 9i marketing eggs in the RAC basket that failure is NOT an
option! OPS was often sort of regarded as the "black sheep" of the product
family in the past. (Trivia question: "How many OPS presentations were
there at Open World in 1997? 1998? even 1999?) RAC is now being promoted
as the holy grail for scalability and availability. Part of that marketing
effort appears to be denying that RAC is essentially the "grown up" version
of that "back sheep" family member OPS! Too many simply donned the garlic
necklace and held up a cross whenever someone even mentioned OPS. ("This is
my cousin Vlad. I know, he looks a lot like my other cousin Dracula, but he
isn't. Vlad is a nice fellow!")
-Don Granaman
[certifiable OraSaurus]
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 6:01 PM
> >[via Oracle-L digest]
> > From: "Don Granaman" <[EMAIL PROTECTED]>
> > Date: Wed, 25 Jul 2001 22:29:47 -0500
> > Subject: Re: (Fwd) Re: Oracle 8i and clustering
> >
> > I don't know exactly the context in which you heard this (NT
> > cluster specific?),
>
> Don,
>
> Probably just my bad paraphrase of a dim recollection of a
> fast/careless read of previous comments on the list.
>
> Can you give a brief explanation of what will be new/changed
> in RAC, and what it means?
>
> thanks,
> ep
>
>
> >...but rest assured that OPS is not going to be
> > "replaced", except in name. The current party line is that "real
> > application clusters" is a radical departure from OPS. It simply
> > isn't true. RAC is a very major upgrade/rewrite and renaming of
> > OPS, not a different technology. There seems to be a *LOT* of
> > misinformation floating around on this issue and much of it seems
> > be coming from Oracle's marketing machine.
> >
> >-Don Granaman
> >[certifiable OPS OraSaurus]
> >
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Eric D. Pierce
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Don Granaman
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
