Testing for Availability - Expert Oracle RAC Performance Diagnostics and Tuning - page 76

■ this is a critical test and should not be compromised. all failure points should be tested until the expected re-
sults meet the business requirements and the slas for business continuum are achieved. a detailed sample spreadsheet
containing the failure points to be tested is provided in appendix D.

Note

Workshop
Before beginning this phase of testing, the business rules and SLA requirements of the application should be
reviewed. Based on the analysis, a test plan should be prepared covering all failure points. For verification and
documentation purposes, test cases and results should be recorded and maintained.

Step 1
The initial step is to set up the tests: for example, create use cases for all test scenarios. Identify complex areas of the
application and build test scripts to generate load for these areas. Tools such as LoadRunner or Real Application
Testing (RAT) can be useful for this purpose. Once the test cases have been identified, design a spreadsheet with the
appropriate columns; for example, the following template covers the basic level of testing (see Table 3-4 ).

Table 3-4. RAP III—Testing the Application for Availability

Test # Description # of Users Test Case & Functionality Description Statistics Status

Step 2
Using the LoadRunner scripts, generate user workload from the application once the required number of users is
loaded. Monitor the database for workload distribution and user definitions.
Once the desired workloads are reached, shutdown abort one of the instances or crash one of the nodes in the
cluster and observe the application behavior (see Table 3-5 ).

Table 3-5. RAP III—Testing the Application for Availability

Test # Description # of Users Test Case & Functionality Description Statistics Status

1 Baseline test 300 All app servers and &

db servers accessible

No users fail
over

Complete

2 Test 1 300 Shutdown abort instance 2 Users should

fail over

No users failed
over; instance
recovery time =
12 seconds

Error

On verifying the user connections, it was noticed that the connect descriptor was not rightly defined on the
application server. No failover policies or rules were defined. Second, the ONS server on the database server was
not aware of the participating clients and could not notify the application server of an instance crash. The lack of
these definitions caused connections to fail, and the user connections did not move/failover to one of the surviving
instances.