Database Reference
In-Depth Information
RAP Testing Phase VIII—Burnout Testing
This phase of the testing is to verify the overall health of both the application and the databases when the database
is constantly receiving transactions from the application. Using tools such as LoadRunner, a typical workload is
generated against the database for a period of 40-60 hours and the stability of the environment is monitored.
This phase of the testing is to verify any issues with application and database software components for memory leaks
and other failures. The data and statistics collected from the tests can also help in the final tuning of the database
and network parameters.
Creating an Application Testing Environment
One of the common mistakes found in the industry is not to have an environment similar to production for
development and performance testing of the application, as the performance of all database interactions is affected
by the size of the underlying database tables. The relationship between performance and table sizes is not always
predictable and is all based on the type of application and the functionality of the application being executed.
For example, in a data warehouse type of application, the database could be static between two data load periods;
and depending on how often data feeds are received, the performance of the database could be predictable. On the
other hand, the database could be linear in an OLTP (online transaction processing) application because data is
loaded in small quantities.
It is essential to ensure that database tables are as close to production size as possible. It may not be always
possible to create full replicas of production systems for performance testing; in these cases, we need to at least create
volumes sufficient to reveal any of the unexpected degradations caused by execution patterns. In such situations,
importing database optimizer statistics from the production environment could help produce similar execution plans
and similar response times.
When migrating from single instance configuration to a RAC environment or when making upgrades either to the
database version or the application version a use of Oracle Real Application Testing (RAT) should be considered. RAT
provides functionalities such as database replay and SQL Performance Analyzer, which allow replaying production
workloads in a test environment.
Note
oracle rat is discussed in detail in Chapter 5.
How Much to Tune?
Several database administrators or performance engineers look at the performance statistics with a high-powered
lens to find details that could be tuned. They spend countless hours day and night over performance issues,
microtuning the system. In spite of achieving response times stipulated by the business requirements, the DBA or
performance engineer goes into tuning the database to the nth degree with no return on improved performance.
Such micromanagement of the performance tier is what is referred to as compulsive tuning disorder (CTD; Oracle
Performance Tuning 101 by Gaja Krishna Vidyanathan, Kirtikumar Deshpande, and John Kostelac [Oracle Press,
1998]). CTD is caused by an absence of complete information that would allow you to prove conclusively whether
the performance of a given user action has any room for improvement ( Optimizing Oracle Performance by Carry
Millsap and Jeff Holt [O'Reilly, 2003]). If repeated tuning creates a disorder, how much is too much? This should
not be hard to define. Tuning should be made with goals in perspective, a good place to start is the SLA defined by
business; then, based on tests and user response or feedback, reasonable goals could be defined. Tuning should
not be an endless loop with no defined goals. When it's approached with no defined goals, then the DBA may get
infected by the CTD syndrome.
 
 
Search WWH ::




Custom Search