Re: RAC/OPS changes
[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
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).
Re: RAC/OPS changes
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
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: