Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Migrating 8i OPS to RAC 9.2

Re: Migrating 8i OPS to RAC 9.2

From: Mladen Gogala <mgogala_at_adelphia.net>
Date: Mon, 23 Jun 2003 03:23:38 -0700
Message-ID: <F001.005B76A7.20030623020935@fatcity.com>


On 2003.06.23 04:39, K Gopalakrishnan wrote: Hi Vivek,

Other than the installation/upgrade issues, RAC tuning requires deeper understandings of the cache fusion and the GCS,GES internals. For example, the cache fusion will not happen after certain number of lock converts/downgrade-upgrades and it will use DISK to tranfer the blocks between instances.
Can you point me to any technical document confirming such a behavior? My understanding of RAC was based on a talk with a person from oracle support. Based on the nautre of the database and the workload, you may want to incrase or decrease the number of times a block can be trasfered over the wire and decide after X number of wire transfers, you can force the disk transfer.
My company is considering converting to oracle 9.2 and buying a RAC license. I did my reading on the Metalink, but I must have missed that. But you can still use the GC_FILES_TO_LOCKS parameters in the RAC instances if you know your application very well and I have seen the GC parameters in some of the Oracle TPC benchmarks. Well, now, benchmarks are precisely the reason why "discrete transactions" were invented and why there is a parameter called "_disable_logging". There was a huge row over discrete transactions (ones that didn't generate normal undo information but went to a special buffer instead) and Oracle Corp. even withdrew from the TPC for a period of 6 months or so. My opinion of audited published benchmarks is that they're all "cooked" to the same extent as the Enron books. There should be a very valid justification for using GC_FILES_TO_LOCKS in a RAC environment and the only valid justification I can think of is CPU consumption. To tell the truth, releasable locks do not work properly in OPS (8i) version and we're still using GC parameters there. And the other interesting thing in RAC is the CR copies are created by the owner, not the requester. But in OPS the CR copy will be created by the requester and the owner has no responsibility other than just downgrading the locks (X to NULL). Like this there are so many small small things are changed in RAC comparing with OPS and some of the basic OPS concepts are no longer valid in RAC (and RAC Tuning). I believe that the OPS in version 8i was doing precisely that. That was the responsibility of the BSP process. The ability to generate a read-consistent copy over the wire was called cache fusion.

Good luck for your RAC Migration and do let us know if you have faced any of the complexities in the upgrade/migration/or whatever.. Thanks! One more question: would you recommend automatic undo mgmt for a RAC environment? In an OPS environment, we created private rollback segments for each instance to minimize pinging and each instance has it's own tablespace for rollback segments. There can be only one undo tablespace in 9i instance. Have you experimented with AUM and RAC? Can I have each instance look into its own undo tablespace?

--

Mladen Gogala
Oracle DBA
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Mladen Gogala
 INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services

---------------------------------------------------------------------
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). Received on Mon Jun 23 2003 - 05:23:38 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US