Database Reference
In-Depth Information
In addition, you'll need to consult any documentation you have that gives advice on setting up RAC to support
other Oracle products, such as eBusiness Suite and ATG Web Commerce.
There are additional tools you'll need to learn if you are building your own RAC clusters. Oracle has built various
tools to help in validating RAC environments, such as:
•
RACcheck (MOS 1268927.1)
•
Cluster Verify (MOS 316817.1)
•
RDA MOS 314422.1 and 250262.1 for Database checks
And, of course, there are all of the OS-specific settings, package requirements, and checks. Going through all of
this effort on a traditional platform is well worth the effort. If you are fortunate, all of this will be documented one time
and someone will make the effort to keep up with all of the documentation updates and RACcheck results to keep
the “do it yourself ” documentation updated. However, doing this takes a lot of time, the right people, a lot of handoffs
between departments, and a lot of resulting QA work to make sure the work was done right.
Documenting and distributing complex technical information and training people to understand the information
is a challenge for most companies, especially smaller and midsize companies. Adding to challenges are all of the
handoffs between multiple teams that are required to implement all of the requirements. Someone may forget to
route the interconnect traffic to redundant RAC-only switches (which are also expensive), or forget to configure
Jumbo frames on both the server and switches. There can be additional issues related to external vendor software
supporting IO multipathing. Because all of these scenarios are very real, Oracle has found the need to invest in
extensive RAC diagnostic facilities.
Oracle is helping to manage this complexity by extending RACcheck and other tools to catch setup issues.
However, the conclusion is that there are real reasons the people in the Oracle RAC assurance group and Oracle
support are very busy these days. Engineered systems and ODAs take a lot of the work to correctly deploy RAC off your
shoulders.
ODAs provide an answer to all of these challenges by making RAC configurations self-contained. There are
no external interconnect requirements or instructions for making RAC configuration changes outside the standard
ODA deployment process. If you are concerned about the ability of your company to successfully complete all of the
engineering work required to build truly high availability RAC clusters, then ODAs may help provide a solution. The
expertise to successfully deploy RAC clusters is greatly reduced. This is a major advantage for companies of all sizes.
ODAs extend the ability to successfully deploy two-node RAC clusters to the masses, which is part of the reason that
ODAs are a solution for “RAC Without Tears.”
RAC One, a two-node RAC cluster, or a single instance database can be deployed during an ODA install. ODAs
deploy RAC clusters in a matter of hours and according to Oracle's best practices. Oracle builds the physical RAC
interconnect into the appliance. The quarterly automated patching process simplifies the process for keeping the
grid/clusterware and Oracle Homes patched with the latest PSU patches and bug fixes. These quarterly patches are
tested as a complete unit, along with the OS and firmware changes, making ODAs a great solution for maintaining
ongoing RAC stability.
■
the author has discussed raC installations on non-oDa systems with a number of small companies. Many
small and midsized companies simply don't have the resources to perform that sort of installation by themselves. this
includes the technical resources to research all of the raC requirements and the cost of buying additional equipment,
such as dedicated raC switches, for the interconnect traffic.
Note
While ODAs do a great job deploying and supporting RAC clusters, the need for understanding good RAC design
best practices for eliminating contention between nodes is still something that teams deploying RAC on any platform
need to be aware of. Also, a two-node cluster requires that one server is able to handle the entire processing load
during a node switchover. Supplementing RAC with Data Guard can alleviate the failover capacity concerns.
