Database Reference
In-Depth Information
Chapter 5
Real Application Testing
Today's Internet-based computing has created several challenges to the computing industry. The expansion of the
global economy has increased workloads and user activities. Transactions can originate from any part of the world
while the final persistence of the data into storage media happens in some unknown location millions of miles
away. The expectations, irrespective of where the data is finally stored, either in the city or in some remote unknown
location, require high response times.
In supporting increased user activities or increased number of users as the demand for Internet-based
computing expands, more powerful infrastructure with high speed processors are being engineered. This means that
the older systems that currently support production systems get replaced with newer technology.
Equally challenging to the increased workload and demand for Internet systems that provide higher response
times, is the migration of systems from one technology to another.
In an
N
-tier computing model, there are several areas where bottlenecks can occur; and response times are
measured taking into consideration the entire life cycle of a transaction. However, the primary area of concern is
almost always found to be where the rubber meets the road, the database. Here the rubber is the SQL operations,
and the road is the physical database. The performance of the persistence layer is extremely critical for the overall
performance of any system, Internet, the old client server, the data warehouse, or even the space navigation systems.
Whereas performance of the persistence layer in any enterprise architecture is important, it's even more critical
that this performance measurement is maintained or improved as systems are migrated to new technologies or when
additional functionality is added to the systems.
The previous two chapters discussed various types of testing and how they all play an important role in the
success of any RAC implementation. Testing performance and scalability of the application was discussed in Chapter 4.
Scalability of the application is possible only if the persistence layer to the database also scales.
Testing the persistence layer without including the overhead of the application will help identify concurrency
issues with SQL statements and DML operations. These queries can then be optimized and tested again before
adding the overhead of the application and business logic. This also helps to create a baseline, which further helps
to determine if the application interface to the database is slower and directing efforts to optimize the application.
Oracle provides a tool called “database replay” to help understand impact to the overall performance of the
environment when changes are made to the system and infrastructure. Whereas alternative methods can easily be
developed using perl and other utilities, in this chapter, an attempt is being made to discuss the database replay tool
from Oracle.
Persistence layer scalability tests should be performed against a copy of the production schema (on the new
hardware platform) that contains the actual data from the current live production environment. The purpose of this
test is to tune the instance and the database for application workloads not interfacing the business application. For
such a test, an extract of the SQL queries from the application could be used; or tools available in the market, such as
Real Application Testing (RAT), could be used.
Search WWH ::
Custom Search