Oracle Performance Testing Principle

The following list describes some simple rules for performance testing an application. If correctly documented, this provides important information for the production application and the capacity planning process after the application has gone live.

1.Use the Automatic Database Diagnostic Monitor (ADDM) and SQL Tuning Advisor for design validation

2.Test with realistic data volumes and distributions
All testing must be done with fully populated tables. The test database should
contain data representative of the production system in terms of data volume and
cardinality between tables. All the production indexes should be built and the
schema statistics should be populated correctly.

3.Use the correct optimizer mode
All testing should be performed with the optimizer mode that will be used in
production. All Oracle research and development effort is focused upon the query
optimizer, and therefore the use of the query optimizer is recommended.

4.Test a single user performance
A single user on an idle or lightly-used system should be tested for acceptable
performance. If a single user cannot achieve acceptable performance under ideal
conditions, it is impossible there will be acceptable performance under multiple
users where resources are shared.

5.Obtain and document plans for all SQL statements
Obtain an execution plan for each SQL statement, and some metrics should be
obtained for at least one execution of the statement. This process should be used to
validate that an optimal execution plan is being obtained by the optimizer, and the
relative cost of the SQL statement is understood in terms of CPU time and physical
I/Os. This process assists in identifying the heavy use transactions that will
require the most tuning and performance work in the future.

6.Attempt multiuser testing
This process is difficult to perform. accurately, because user workload and profiles
might not be fully quantified. However, transactions performing DML statements
should be tested to ensure that there are no locking conflicts or serialization
problems.

7.Test with the correct hardware configuration
It is important to test with a configuration as close to the production system as
possible. This is particularly important with respect to network latencies, I/O
sub-system bandwidth, and processor type and speed. A failure to do this could
result in an incorrect analysis of potential performance problems.

8.Measure steady state performance
When benchmarking, it is important to measure the performance under steady
state conditions. Each benchmark run should have a ramp-up phase, where users
are connected to the application and gradually start performing work on the
application. This process allows for frequently cached data to be initialized into
the cache and single execution operations—such as parsing—to be completed
prior to the steady state condition. Likewise, at the end of a benchmark run, there
should be a ramp-down period, where resources are freed from the system and users cease work and disconnect.

(Refers to the Oracle Performance Tuning Guide)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12361284/viewspace-462881/，如需轉載，請註明出處，否則將追究法律責任。