Question: I am implementing my first RAC
database and I'm charged with performing the Oracle system testing.
How is RAC system testing different from standard Oracle database
testing? What types of testing is done when implementing RAC
databases? Are there best practices for testing Oracle RAC
Answer: First, make sure
that you have created an Oracle
environment, with multiple development instances, a test
instance, and a full-sized QA instance. These the areas of
Oracle system testing include functional testing, stress testing,
failover testing and disaster recovery testing.
Unless you have extensive experience testing every possible
Oracle recovery scenarios, it's an Oracle best practice to
hire an expert to perform all of your Oracle testing and
certify that the system tests have been performed properly.
It's a critical testing best practice to perform all of these
tests prior to rolling-out the database in production:
- Functional testing: Functional
testing is done with the end-users prior to roll-out.
Functional testing involves a screen-by-screen walk-through and
a sign-off on the functionality by the end-user manager.
- Stress testing: The stress test is a
performance benchmark done immediately before production
roll-out and it involves imploding the system with transactions
to see how many transactions per seconds can be done before you
see a drop in response time. See these important notes on
Oracle stress testing best practices. Stress testing
also reveals the system bottleneck, which in a well-tuned
database, will only appear under heavy load.
- Failover testing: Failover testing is
used in RAC databases, Streams systems, Data Guard
databases and any replicated database. For RAC testing, a
failover test ensures that
transparent application failover (TAF) is working properly.
This is done by connecting to each node (using the local
tnsnames.ora) and killing the node (by dong a kill -9 of the
pmon process), and watching the transaction fail over to
the backup node.
- Disaster Recovery testing: Due to the
expense, disaster recovery testing is the most commonly omitted
test, and failing to do this test has put more than one Oracle
shop out of business. All databases need to test their
disaster recovery plan, and this is done by turning-off your
primary database and allowing the system to be resurrected at a
remote disaster site. In some systems you can use
extended RAC using dark fiber for disaster recovery testing.
You can also use RMAN for disaster recovery testing.
By the time your are ready to roll-out a database, all of the
Oracle testing steps should be completed.
the best practices for testing system changes.
I highly recommend the
Benchmarking" for more details on conducting and
interpreting Oracle benchmarks.
This book is
written by numerous Oracle tuning experts and shows a
complete methodology for Oracle system testing.
Get the Complete
Oracle SQL Tuning Information
The landmark book
SQL Tuning The Definitive Reference" is
filled with valuable information on Oracle SQL Tuning.
This book includes scripts and tools to hypercharge Oracle 11g
performance and you can
for 30% off directly from the publisher.