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
databases?
Answer: First, make sure
that you have created an Oracle
testing
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
geographically
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.
Also see
the best practices for testing system changes.
 |
I highly recommend the
book "Oracle
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. |
|
|
 |
|
Guarantee your Success!
Oracle is the
world's most complex, robust and flexible database, considered
impossible to master without a mentor.
That's why all BC
Oracle trainers are working professionals, experts in Oracle who
share their tips and secrets. |
|
| |
|
Burleson is the American Team
Note:
This Oracle
documentation was created as a support and Oracle training reference for use by our
DBA performance tuning consulting professionals.
Feel free to ask questions on our
Oracle forum.
Verify
experience!
Anyone
considering using the services of an Oracle support expert should
independently investigate their credentials and experience, and not rely on
advertisements and self-proclaimed expertise. All legitimate Oracle experts
publish
their Oracle
qualifications.
Errata?
Oracle technology is changing and we
strive to update our BC Oracle support information. If you find an error
or have a suggestion for improving our content, we would appreciate your
feedback. Just
e-mail:
 and include the URL for the page.
Copyright ? 1996 - 2012
All rights reserved.
Oracle ?
is the registered trademark of Oracle Corporation.
|
|
