RE: Moving to RAC`
Date: Mon, 2 Mar 2015 13:08:56 +0000
Message-ID: <85D44D05C4C24C40AFDED6C1FC0E1BDF99522D3F_at_SNSLCVWEXCH02.abl.cda.navy.mil>
I'm in the same situation here. We are late delivering a huge upgrade to our suite of applications, consolidating them, and all efforts have been made to get it working on a single server in the test environment. Our test environment is a fraction of the intended production environment with no working external interfaces. We will start consolidating the activities and databases of various business units into a single VPD enabled database. Nobody knows how this is going to work and no one has really thought about how it will work in production and what tools etc will be need to keep it running. We will start with a single activity later this year.
I submitted a paper and recommended that we go to RAC on Solaris cluster, local logical standby, cloud control, logical standby on a disaster recover site. We will only have two of the packs, performance and tuning, paid for in our enterprise agreement. The only out-of-pocket we would have to pay for licenses is for that RAC. I'm having cold feet about whether or not to ask for enough licenses to build a RAC test system which would probably cost us an additional 300k or maybe less if we go per user. Would you wait a year and build the standby system first? I'm trying to figure out how to provide some sort of high availability. I dread trying to do all of this unless we have an identical system to practice on.
We don't know how this thing is going to work on a single server hence my desire to get cloud control up and running. Is it premature to think about suggesting RAC?
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
Sent: Sunday, March 01, 2015 6:56 PM
To: oracle-l_at_freelists.org
Subject: Re: Moving to RAC`
OK, great. It seems to be OLTP database strewn into RAC configuration to attain fault tolerance. You should be monitoring for any process spending significant time on any event starting with "gc", especially "gc current block busy" and "gc current block". Any events like that mean that you are updating the same data from at least two different nodes. The "2 way" events aren't possible if you don't have 3 or more nodes. However, adhering to the principle of functional partitioning, which says that all DML operations on the same set of tables should be performed from the same node, is crucial. When you have a single instance installation, locks are essentially memory structures and locking a row means reading and modifying a memory location. Memory access times are measured in nanoseconds. If you have RAC, locks include network. And network communication is measured in milliseconds. Of course, if you want to run reports, then you have to monitor cache fusion, which is characterized by "gc cr" events, where "cr" stands for "consistent read". That, however, doesn't seem to be of too great concern in your situation. Cache fusion is a marketing name for the ability of Oracle to construct a consistent image of the block, consistent up to a SCN, and ship it to the requesting node. Yes, you guessed it, it also includes network communication, however caching can offset that.
On 03/01/2015 04:25 PM, Ram Raman wrote:
"wants to achieve more resilience and fault tolerance" - That seems to be the goal.
It is not a DW; they are not even thinking about running reports or backup in the other node.
he said the need for RAC wasn't part of this discussion. So let's not worry about it and just advise him on his question.
So one other thing to keep in mind. Companies may certify their application in RAC and only mean there is nothing in RAC that will break their App. Eg, the sequence issue mentioned before. That does not mean their app is suitable for RAC and will scale well in a RAC environment.
But the answer to the question is crucial. If he wants to achieve more resilience and fault tolerance, he needs to set the system up one way and if he needs to run reports, it's another setup, and if the system is a DW system, it's yet another set of settings. To tell him how to scale, I must know what does he want to do and why. That's the philosophical catch 22.5.
--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com
†Ûiÿü0ÁúÞzX¬¶Ê+ƒü n– {ú+iÉ^
Received on Mon Mar 02 2015 - 14:08:56 CET