Re: RAC/OPS changes

2001-07-27 Thread Thater, William

[EMAIL PROTECTED] wrote:
 
 Well you asked for this. Don't read this if you are faint
 of heart and weak of mind.

ORA-99 : Brain Overload.;-)

this one i'll save and keep rereading until it makes sense.

thanks.


--
Bill Shrek Thater   Certifiable ORACLE DBA
Telergy, Inc.[EMAIL PROTECTED]
~~
You gotta program like you don't need the money,
You gotta compile like you'll never get hurt,
You gotta run like there's nobody watching,
It's gotta come from the heart if you want it to work.
~~
If a program is useful, it must be changed.
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Thater, William
  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).



RE: RAC/OPS changes

2001-07-27 Thread Mohan, Ross

Scott, 

Thanks for the info, but aside from
the somewhat fleshy last paragraph, 
there's not much meat here. It sounds
rather like an Oracle marketing piece. 

For instance, do you have any pointers
or further information on the 27 patents you mentioned? 

Don't get me wrong: thanks for the effort behind the post, but.there's 
not much to chew on there


-Original Message-
Sent: Thursday, July 26, 2001 7:46 PM
To: Multiple recipients of list ORACLE-L


Well you asked for this. Don't read this if you are faint
of heart and weak of mind.

Oracle9i Real Application Clusters is the next
evolutionary step up from Oracle Parallel Server, and is
the result of more than 6 years of development, 9
patents, and 18 additional patents pending. Oracle9i Real
Application Clusters are unique in that they provide:

Out-of-the-box, near-linear scaling transparency

Compatibility with all applications, with no redesign
required

Fast growth clusters, the ability to rapidly add nodes
and disk

Based on Oracle's Cache Fusion architecture, Oracle9i
Real Application Clusters provide transparent application
scalability by quickly and efficiently sharing frequently
accessed data across all the servers in a cluster,
resolving all manners of contention between servers in
the process.

In the Cache Fusion architecture, read requests may be
served by any of the memory caches in the cluster
database. In cases where data is being updated,
coordination between the caches of each server becomes
necessary so that both the data being read and the data
being updated are consistent and correct.

If the query request is served by a remote cache, then
the block is transferred across the high speed cluster
interconnect from one node's cache to another. This
fusing of the caches happens automatically and is
transparent to the application.  This transparency is the
key technology that provides the fast, efficient scaling
of Oracle9i Real Application Clusters.

I warned ya,

Scott

 [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: 
  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: Mohan, Ross
  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).



RAC/OPS changes

2001-07-26 Thread Eric D. Pierce

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



Re: RAC/OPS changes

2001-07-26 Thread sheisey

Well you asked for this. Don't read this if you are faint
of heart and weak of mind.

Oracle9i Real Application Clusters is the next
evolutionary step up from Oracle Parallel Server, and is
the result of more than 6 years of development, 9
patents, and 18 additional patents pending. Oracle9i Real
Application Clusters are unique in that they provide:

Out-of-the-box, near-linear scaling transparency

Compatibility with all applications, with no redesign
required

Fast growth clusters, the ability to rapidly add nodes
and disk

Based on Oracle's Cache Fusion architecture, Oracle9i
Real Application Clusters provide transparent application
scalability by quickly and efficiently sharing frequently
accessed data across all the servers in a cluster,
resolving all manners of contention between servers in
the process.

In the Cache Fusion architecture, read requests may be
served by any of the memory caches in the cluster
database. In cases where data is being updated,
coordination between the caches of each server becomes
necessary so that both the data being read and the data
being updated are consistent and correct.

If the query request is served by a remote cache, then
the block is transferred across the high speed cluster
interconnect from one node's cache to another. This
fusing of the caches happens automatically and is
transparent to the application.  This transparency is the
key technology that provides the fast, efficient scaling
of Oracle9i Real Application Clusters.

I warned ya,

Scott

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



Re: RAC/OPS changes

2001-07-26 Thread Don Granaman

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: