RACCheck
21/10/2013 2 Comments
Running RAC? (Why? No, really, WHY? Never heard of DataGuard? With a broker?)
Running RAC?
Not sure if you’ve configured it correctly?
Not sure if you have all of the recommended initialisation parameters set?
All recommended RPM’s installed?
All daemons running?
etc, etc, etc,
Well, as of Oracle 11.2.0.4 where’s a new feature provided by default called RACCheck. You can find it installed in directory $ORACLE_HOME/suptools/raccheck, (or you can download it from MOS article 1268927.1) and it’s called “raccheck”. With a little sudo configuration, or the root passwords, you can check the configuration on every node in a few minutes per node (run at a sensible time). All the basics appear to be covered, and you get a nice list of anomalies out of the system in HTML format.
I don’t necessarily agree with some of the errors/warnings produced (you might want the “problems” it’s finding!), but it gives you cause to re-think about an element of the system that may be configured in a non-standard way, and you get lots of relevant and useful links to MOS articles.
e.g. One problem:
| WARNING | SQL Check | Some user sessions lack proper failover mode (BASIC) and method (SELECT) | All Databases |
Can be happily ignored as I’m using a SCAN listener, which renders this WARNING irrelevant.
but I would recommend that you use the utility and accept/understand any exceptions. It should help stabilise any RAC installations you may have.
Neil Chandler's DB Blog 
RAC = scalability/concurrency. 4 node RAC lets more users hammer the database
DataGuard = disaster recovery
4 node RAC + Dataguard gives the best of both worlds, and conveniently (for Oracle) lines Oracles pockets with gold.
LikeLike
You will find its cheaper (HW+SW) and faster to run a single instance with Dataguard and a broker, and has an equivalent percentage uptime. The cluster/GI stack lowers the overall uptime percentage of each node due to significantly increased complexity. If a node goes, you get a brown-out. You stop processing. That’s technically down, for a while.
The (transparent) scalability of RAC is much exaggerated, by salesmen. And you still have a SPOF. It’s called the SAN.
Most applications out there don’t have TAF, or FAN capability. Lose a node and frequently you find that app server reboots/restarts are required. Even if the app is TAF/FAN capable, the brown-out duration can be just as long as it takes a broker to open a DG system and register the Production service in the listener on the DR server and get your app connected over in DR.
RAC = improved concurrency over a single instance? Look at the effort Oracle has to put in just to ensure it has the Current Version block with a exclusive lock, changing the status from (whatever) to XCUR (with maybe an interconnect block transfer), processes talking to other nodes and getting them to change the status of the same block in their buffers from SCUR to CR (or whatever it decides to do – it varies). RAC more concurrent? No, it’s not.
The only real reason to use RAC is if the largest computer out there can’t handle your CPU/Memory requirements. What are you doing that requires more than 256 cores and 16TB of RAM? That’s a LOT of power.
LikeLike