Re: RAC/OPS changes

From: Don Granaman <granaman_at_home.com>
Date: Thu, 26 Jul 2001 22:30:33 -0700
Message-ID: <F001.00356CA6.20010726220522@fatcity.com>

There are many changes, but probably the two biggest ones are:

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.
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" <ORACLE-L_at_fatcity.com> Sent: Thursday, July 26, 2001 6:01 PM

> >[via Oracle-L digest]
> > From: "Don Granaman" <granaman_at_home.com>
> > 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: PierceED_at_csus.edu
>
> 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: 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Don Granaman
  INET: granaman_at_home.com

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

Received on Fri Jul 27 2001 - 00:30:33 CDT