Application Performance Tuning

for DB2 OS/390 and z/OS

By Deb Jenson















2

Table of Contents

Executive Summary.................................................................................................................................3
Introduction: Why SQL Tuning?.............................................................................................................3
Structured Query Language (SQL).........................................................................................................4
Access Paths ......................................................................................................................................4
Access Types .....................................................................................................................................5
Join Methods......................................................................................................................................6
Nested Loop Join........................................................................................................................... 6
Merge Scan Join............................................................................................................................ 7
Hybrid Join.................................................................................................................................... 8
Execution Results...............................................................................................................................9
Objects ...............................................................................................................................................9
Tuning Environment .............................................................................................................................10
Native DB2 Utilities..............................................................................................................................10
DB2 Explain ....................................................................................................................................11
Visual Explain..................................................................................................................................12
SQL Tuning from Quest ........................................................................................................................13
SQL Statement Information.............................................................................................................14
Access Path Analysis .......................................................................................................................14
Advice..............................................................................................................................................16
Scenario Testing...............................................................................................................................17
Compare Engine...............................................................................................................................17
Summary .............................................................................................................................................18
Quest Software......................................................................................................................................19
About the Author...................................................................................................................................19


3

Application Performance Tuning for DB2 OS/390 and z/OS
By Deb Jenson

Executive Summary
Databases are at the foundation of a business computing architecture that often includes web
servers, application servers, client workstations, application logic, networks, and other
components. The database acts as the data server, and can quickly turn into an application
bottleneck if a problem occurs. In many cases, newly developed applications pass quality
assurance tests, but go on to fail in production because of scalability problems. Poorly written
Structured Query Language (SQL)the language used by the applications to retrieve and store
data in a databasefrequently causes this to happen.
Like other databases, IBM DB2 is negatively affected by poor application SQL. Bad SQL
like bad grammarwill still communicate the required message, but takes longer to interpret
and understand, thus resulting in a much slower response. Application SQL must be tuned to
optimize performance and maximize the return on an often-significant investment in business
technology. Effective SQL tuning requires users to collect and analyze specific information,
including offending SQL code, SQL access plan, target object statistics, and dependent object
relationships. Using the native DB2 utilities to gather this information is time-consuming and
requires the use of several different tools, making iterative tuning a difficult process. Quest
Softwares SQL Tuning product, part of Quest Central for DB2, allows application developers
and DBA's to quickly gather information needed to make tuning decisions within an iterative
analysis session. The expert advice function assists users by recommending corrections and
rewriting a selected SQL statement based on the accepted recommendation. The improved
application performance and return on investment generated by the SQL Tuning product
directly benefits the business and the information technology infrastructure.

Introduction: Why SQL Tuning?
A variety of factors can affect overall performance of production applications. For example,
business demands may require room for additional users, support for new customers or web
access. The application is affected by technical factors such as network bandwidth, memory
constraints and database performance. Regardless of the applications business and technical
demands, performance and availability must continue to meet user expectations. To improve
application performance, IT staff may purchase additional hardware or tune the application.
While periodic hardware upgrades are necessary to support growing applications, tuning should
be the primary method to improve performance. Tuning not only addresses the application, but
improves the cost-benefit ratio of the system as well. Although the majority of tuning efforts
are spent at the operating system and database level, the largest performance gains are obtained
from tuning the application.
Applications that use SQL to retrieve data in a database are the best candidates for tuning.
Since a relatively small number of SQL statements consume the majority of resources, SQL
tuning often results in significant performance improvements. However, SQL tuning can be
complex. It requires an understanding of DB2 SQL processing, the collection of specific
information about each SQL statement, and iterative analysis. While the native DB2 utilities
can be used to assist with SQL tuning, they possess significant limitations.

4

Quest Centrals SQL Tuning product eases the complexity of SQL tuning. The product is
designed to assist both the novice and the expert by providing a robust SQL tuning environment
complete with proven expert advice and tuning recommendations. The access path analysis
provides in-context object statistics and English like translation. The tuning recommendations
are invaluable when determining what can be done to reduce statement costs. Providing an
environment to test and compare SQL statements completes the solution.
Structured Query Language (SQL)

DB2 UDB, like all relational database management systems (RDBMS), contains a SQL
processing engine that provides an interface to the database functions. SQL statements are
generally categorized into three groups:
Data Definition Language (DDL) These statements are used to define and manage the
data structures administered by the database manager. DDL statements are generally
considered to be the CREATE, ALTER, and DROP commands. Database objects such as
tables, views and indexes are created, altered and dropped with these statements.
Data Control Language (DCL) These statements are used to provide security within the
database. DCL statements are generally considered to be the GRANT and REVOKE
commands. Users of the database are granted or revoked permission to access objects and
data with DCL commands.
Data Manipulation Language (DML) These statements are used to manage the data
stored within the database. DML commands are generally considered to be the SELECT,
INSERT, UPDATE, and DELETE commands. Application data is selected, inserted,
updated or deleted with DML commands; they are the most commonly used commands in
application programming.

Of these three types, performance tuning is only concerned with DML statements. DML
commands are the most frequently used by applications and have the greatest flexibility for
interpretation. DDL and DCL statements, on the other hand, consist of rigid syntax that cannot
be tuned. One notable exception is when DDL statements contain DML statements, such as the
CREATE VIEW command, which is based on a DML SELECT statement.

Access Paths
The SQL statement is the focal point of tuning efforts, so the developer or DBA must first
identify a target statement and collect supporting detail. SQL tuning can be done either
proactively, during development; or reactively, in response to poor performance. Proactive
statement tuning results in higher quality applications, but it requires discipline for developers
to evaluate each statement that is used in an application. Reactive tuning is equally challenging,
because detective work is required to identify the offending SQL statements that are degrading
an application.
Once a statement is identified, supporting details must be gathered as well. Most importantly,
the SQL access plan must be obtained, since it describes how the database is processing the
statements request. IBM provides a method called explain which is used for generating
access plans. Once an explain is executed the SQL statement access paths are stored in a DB2
table called a plan table. This plan table must be queried to determine the access path chosen
for a DB2 query. The plan table contains detailed information about the access path. The most
critical information to understand is the various access types and join methods. Since the

5

information stored in the plan tables are codes that describe these access types and join
methods, deciphering the rows in the plan table can quickly become overwhelming.

Access Types


The following is a list of some of the access types provided by the plan table.
Tablespace Scan All pages within the tablespace are retrieved. This occurs when a
suitable index does not exist to satisfy a query or if all rows are required. This access is
identified by ACCESSTYPE = R.
Matching Index Scan Is used when the predicate matches either the leading column or
columns of a selected index. The predicate provides filtering; only specific index pages and
data pages are used to access the data. This access is identified by MATCHCOLS>0.
Multiple Index Access Used when more than one index is used to satisfy data access.
Row ID (RID) lists are constructed from the multiple indexes and unions of the RID lists
produce a list of qualified RIDS to retrieve the result rows. This access is identified by
ACCESSTYPE = M, MX, MI, or MU.
In-List Index Scan Is a special case of the matching index scan in which a single
indexable IN predicate is used as a matching equal predicate. This access is identified by
ACCESSTYPE = N.
Non-matching Index Scan Is used when the predicate does not match any columns in
the index. This scan cannot be used to filter the data and is used in cases where optimize
for n rows is used or when multiple tables exist in a nonsegmented tablespace. This access
is identified by ACCESSTYPE = I and MATCHCOLS = 0.
Index Only Access Used when no data page retrieval is necessary, all predicate and
requested column information is found within the index. This access is identified by
INDEXONLY = Y.
One Fetch Access Requires only one row be retrieved. This is the best access available
and only applies when a MIN or MAX column function is used. This access is identified
by ACCESSTYPE = I1.


6

Determining the access type requires reviewing the accesstype, matchcols, indexonly, and
prefetch columns. Understanding access type is only a fraction of the information needed to
determine the full access path. Data from tablespace scans can trigger sequential prefetch and
data from index retrieval can trigger list prefetch. These prefetch methods allow DB2 to read
the data in advance to prevent wait times while the data is being retrieved.
Join Methods
When multiple tables are requested within a single SQL statement, DB2 must perform a join.
When joining tables, the access type (tablespace scan or index scan) defines how each single
table will be accessed, understanding the join method defines how the result sets from multiple
tables will be combined to deliver a unified result set back to the requestor. While more than 2
tables can be joined together in a single SQL statement, DB2 will always perform the join
operation in a series of steps. Each step joins only 2 tables together and a composite table is
passed to the next step in the series. The plan tables will describe how these tables are joined
together and the order in which each table is accessed. Using the following SQL statement as
an example, lets explore the various join methods:
SELECT
A.EMPNO, A.EMPNAME, A.DEPTNO, B.DEPTNAME
FROM
EMPLOYEE A, DEPARTMENT B
WHERE
A.DEPTNO = B.DEPTNO

Nested Loop Join



1. Employee Table (outer) is read sequentially. First row contains deptno = 500
2. Department table (inner) is scanned until deptno = 500 is found
3. Rows are merged and data is stored in the composite table

7

4. Steps 1 thru 3 are repeated for all the rows in the outer table

The nested loop join will require the inner table to be scanned for each row read by the
outer table. The nested loop join is highly efficient when the inner table has few pages
to scan. Additional situations where nested loop join is efficient:

Small number of rows in the inner table
Clustering index on join columns of inner table
Predicates filter the number of qualifying rows in the inner table

Merge Scan Join




1. Employee Table is read in the order of the join column, which is deptno. In this example
the data was clustered by deptno, however, DB2 may invoke a sort if needed.
2. Department Table is sorted by deptno. This is necessary since the Employee is providing
the deptno as the join column.
3. Each table is read sequentially and the rows are matched.
4. Merge the inner and outer table rows and store in composite table
5. Step 3 and 4 are repeated for all rows


8

The merge scan join differs from the nested loop join in the fact that each table is only
read once. The sorted join columns allow these tables to be matched up sequentially.
The merge scan join is efficient under these conditions:

Large quantity of qualifying rows in both the inner and outer tables
No matching indexes on the join columns
Few columns are selected on the inner table

Hybrid Join



9


1. Employee Table (outer) is read in the order of the join column, which is deptno. In this
example the data was clustered by deptno, however, DB2 may invoke a sort if needed.
2. Read the index on Department Table (inner) containing the deptno. Obtain the RID
associated with the matching deptno from the Employee Table.
3. Merge the results of the Employee Table data and the Department Index RIDs into an
intermediate phase 1 table.
4. Sort intermediate phase 1 table and create both a sorted RID list and an intermediate phase
2 table.
5. Using the sorted RID list, utilize list prefetch to obtain the data from the Department Table
(inner).
6. Merge the results of the intermediate phase 2 table with the information obtained from step
5 to create the final composite table.

The hybrid scan method only applies to inner joins and requires that an index exist on
the join column of the inner table. The hybrid join uses a list prefetch method to obtain
the rows of the inner table, as opposed to a scan. The hybrid scan is most efficient
when:

inner table index contains a low cluster ratio
outer table has duplicate qualifying rows

Execution Results
Execution results are another required supporting detail, but these are much easier to collect
and interpret. Tuning a SQL statement often requires rewriting or restructuring the query. When
attempting to improve performance by restructuring, it is easy to accidentally impair the
statements result. The execution results of a modified statement should be compared against
the results of the original to ensure that the correct data is still being returned.

Objects
The objects involved with a SQL statement heavily influence the choices the DB2 optimizer
will make when determining access paths. When DB2 is determining the most efficient access
type, the optimizer will analyze the predicates involved. The predicates are used to filter out
unwanted data. DB2 will actually apply a filter factor to each predicate. The filter factor is a
number between 0 and 1 and defines how many rows will satisfy a particular predicate. The
filter factor combines the following information to determine this qualification:
The literal value in the predicate
The operator involved in the predicate
Statistics on the column

The first two variables can be controlled when writing the predicate, the third variable is
controlled by statistics found in the DB2 catalog. The statistics are updated using a utility
called Runstats. It is imperative that these statistics accurately reflect the data. In production it
is important to ensure runstats are kept up to date, in a test environment these statistics can be
updated to accurately reflect the data expected when this SQL statement is moved to
production. Upon optimization if DB2 cannot find statistics in the catalog for the objects

10

referenced in the statement, DB2 will use default values, which will not accurately reflect the
data.
Tuning Environment
An efficient SQL tuning environment provides assistance when analyzing why a particular
access path was chosen, but more importantly provides the ability to experiment with a SQL
statement. Displaying access path and object information is necessary to help analyze why a
particular access path was chosen, displaying this information in context is essential. However,
that is only the first step when tuning a SQL statement.
The second step is determining a solution. A tuning environment that provides the user with
expert advice is especially helpful in reducing the time spent determining the right solution.
Providing this expert advice is possible because the DB2 SQL optimizer simply operates based
upon an extensive set of rules. Once the tuning environment is made "aware" of these rules, it
can then anticipate the impact of a statement and recommend corrections to improve
performance.
The third step is testing the solution. The tuning environment needs a method where the
original SQL statement can be preserved while a copy of that SQL statement is modified,
applying the solution. The tuning environment must also maintain separate access path
information for each iteration of the SQL statement.
The final step is comparing the modified SQL to the original SQL statement to determine if any
performance improvements were made. This compare engine must be robust enough to
compare not only machine resources and response time, but also the data results to ensure the
SQL statement is bringing back the same result set.
This tuning environment should allow for multiple iterations of testing, allowing many
variations of the SQL statement to be made and compared. This follows any traditional
experiment, start with a baseline (original SQL), modify that baseline, and compare the results
of the modifications against each other and the baseline.



Native DB2 Utilities
IBM does provide some assistance in the area of analyzing the access path, step one in the
process of tuning SQL. IBM provides two methods to assist in presenting the access path the
DB2 optimizer has chosen for a given SQL statement. These methods focus solely on
displaying the access path and are not intended to provide a SQL tuning environment.
Ambitious application developers and DBA's looking to address problem SQL using the IBM
native methods may be discouraged, finding that these products do little to assist them. These
tools are described below.

11



DB2 Explain
The primary function of the explain is to provide access path information for select statements.
Information regarding delete, update, and insert statements are somewhat limited in
information. For SQL statements referencing a single table, the explain can describe whether
table or index access will be used to retrieve the information and what I/O methods will be
used. The explain will also describe join methods and the order in which tables will be
referenced for SQL statements referencing multiple tables table.
Before an explain can be executed, the DB2 plan tables must be created to hold the results of
the explain. Issuing an explicit explain on a single SQL statement or using the explain
parameter on a bind package or plan will populate the plan table with explain information.
Below is an example of the information found in the plan table when running an explain on the
following SQL statement:
SELECT
A.EMPNO, A.FIRSTNME, A.LASTNAME,
A.WORKDEPT, B.DEPTNAME
FROM
DSN8710.EMP A,
DSN8710.DEPT B
WHERE
B.DEPTNO = A.WORKDEPT
AND
A.EMPNO IN
(SELECT C.EMPNO FROM DSN8710.EMPPROJACT C
WHERE C.PROJNO = 'MA2112');



Interpreting the plan table is difficult at best. Without the table and index definitions, it would
be impossible to analyze this access path. The results of the explain can be translated into the
following:
1. EMPPROJACT table is the first table accessed using an index only scan on
XEMPPROJACT1. Using SPUFI, it can be determined that XEMPPROJACT1 is a unique
index based on multiple columns. PROJNO is the first column of the index and that is how
the data is being accessed.
2. The results of retrieving the EMPPROJACT table are sorted to remove duplicates and to
satisfy the IN predicate, or in this case the results are sorted by PROJNO.

12

3. EMP is the outer table of a nested loop join with the DEPT table. This table is being
accessed using a matching index scan because of the IN predicate. The XEMP1 index is
retrieving data in the order of DEPT.
4. DEPT is the inner table of a nested loop join with the EMP table. Because this is the inner
table it will be scanned each time a new outer row (EMP) is retrieved. This table is being
accessed using a matching index scan on XDEPT1. XDEPT1 is indexed on WORKDEPT,
and the data is being retrieved by that column.
5. Results are presented back to the user.

The results of this explain leave a lot of unanswered questions. Simple questions such as how
many rows are in these tables?, or what columns exist for an index? are left unanswered by
the explain. Again the reason is the explain was not designed as a SQL tuning tool, it was
designed simply to present the access path the DB2 optimizer chose for this SQL statement.

Visual Explain
Visual Explain provides a graphical interface to display the contents of the plan table. In
addition viewing object statistics and index columns are also available. This tool provides a
much easier method for analyzing the access path DB2 has chosen for a particular SQL
statement. Again this tool addresses only step one in the SQL tuning process.
Since Visual Explain is using the explain process, the same requirements with the explain still
exist; plan tables must be created and the explain command must be executed. However, the
advantage of Visual Explain is that the product will dynamically create plan tables and
automatically issue the explain command. This makes setting up the explain environment
much easier. Keep in mind that this tool only provides a description of the access path and the
associated object statistics. The product does not offer the ability to modify the SQL and
compare the results. Below is an example of the same access path described above in the
explain section. Notice that Visual Explain will create an access path graph for each query
block.

SELECT
A.EMPNO, A.FIRSTNME, A.LASTNAME,
A.WORKDEPT, B.DEPTNAME
FROM
DSN8710.EMP A,
DSN8710.DEPT B
WHERE
B.DEPTNO = A.WORKDEPT
AND
A.EMPNO IN
(SELECT C.EMPNO FROM DSN8710.EMPPROJACT C
WHERE C.PROJNO = 'MA2112');


13





SQL Tuning from Quest
Quest Centrals SQL Tuning product addresses all four steps necessary to effectively tune SQL
statements. The comprehensive tuning lab provides all the information needed to tune a SQL
statement. Step one provides users the ability to easily step through the graphical
representation of the access plan, which includes a plain English translation to fully understand
the access path. Expert tuning advice can assist with step two; determining what modifications
can be made to a SQL statement to gain more efficient access. Providing scenarios fulfills step
three which is a method to test out any modifications without affecting the original SQL
statement. Lastly step four provides a compare engine, which can be invoked to compare the
original SQL to one, or multiple scenarios to determine which SQL statement offered the
lowest resource usage.
This approach is the best SQL tuning technique for application developers and DBAs. This
environment facilitates both the expert and the novice. The expert can use the access path
information to gather all information necessary to analyze the SQL and use the scenario testing
and compare engine to test various modifications. The novice user can simply apply the advice
and immediately use the compare facility to see the results.


Visual Explain describing access path with object statistics.

14


SQL Statement Information
The SQL Tuning component allows the user to work with SQL statements from a variety of
sources. The simplest method entails directly typing the statement into the component or
loading the contents of a SQL file; this proves to be most beneficial to application developers
looking to quickly tune SQL queries during the development phase. Because Quests SQL
Tuning product is a client-based solution, copy and paste will also bring SQL into the product.

Access Path Analysis
Once a statement has been entered into the tuning session, an explain on the query is performed
to generate the statements access path. The access path display is designed to translate the
multiple rows and cryptic codes found in the plan table into a format that is easily understood.
The display also color codes potentially high cost access steps. Side by side with the access
path are the object statistics to immediately provide pertinent information such as; number of
rows in a table, indexes on a table, columns found in an index. The access plan can be viewed
in various formats; list, tree, or graph. The access path can be traversed with the up/down
arrows and will display the object statistics in context with the access path step. For example,
when the access path is highlighted on a matching index scan, the table and index along with
the associated columns are highlighted as well. In addition, a brief English description of each
step is provided on the same display. The explain statistics also provide processor cost required
to execute the query. The following illustration is an example of the following SQL statement.

SELECT
A.EMPNO, A.FIRSTNME, A.LASTNAME,
A.WORKDEPT, B.DEPTNAME
FROM
DSN8710.EMP A,
DSN8710.DEPT B
WHERE
B.DEPTNO = A.WORKDEPT
AND
A.EMPNO IN
(SELECT C.EMPNO FROM DSN8710.EMPPROJACT C
WHERE C.PROJNO = 'MA2112');

15



Quest Centrals SQL Tuning component makes access path and object statistics available on one
display for easy access path analysis.

The access path provided by the SQL Tuning product immediately detects steps in the access
path that could be potentially costly. In this example the sort is colored red to highlight a
potential high cost. By traversing through the access path and looking at the matching index
scan on the EMP table, the product displays in-context the associated table, index and the
columns provided by that index. This display prevents the user from running additional reports
to determine object information essential in determining the most efficient access. The access
path display provides three views:
List View details contents of the access path in a simple list format
Tree View displays access path contents in a Windows Explorer-style tree
especially useful for large and complicated statements (shown above)
Graph View this access path display, which is similar to the Visual Explain, this
view is useful to visualize processing order

The Plan Statistics display provides detailed optimizer arguments, decrypted and described in
plain English terms for each step of the access plan. These arguments provide insight about the
optimizers access decisions that control activities like direction of table access, table joins,
locking and prefetch usage.


16

Plan Dependencies display all objects involved in the SQL statement and their dependencies.
The user can quickly identify the existence of object statistics and immediately determine the
last time the statistics were updated. Object dependencies and relationships are presented, since
identifying referential integrity constraints, triggers, and dependent objects involved with a
SQL statement is particularly important. Each relationship and dependency has an impact on
the decisions made by the SQL optimizer.
Statement execution results provide further feedback while tuning SQL statements. Verifying
query output is especially important since the goal is to tune the statement, but not at the
expense of correct results. It is best to confirm that any newly tuned statements still achieve the
same results as the original.

Advice
The SQL Tuning product will also assist with determining possible solutions to reduce the cost
of the SQL statement. The advice examines every part of the SQL statement and offers
informed tuning recommendations. With the click of a button, the component then rewrites the
SQL statement to implement the selected advice. The advice provided by Quest reduces the
analysis time required in determining solutions to reduce SQL statement cost.

Advice window provides suggested advice and associated advice actions. Choosing the apply advice
generates new SQL with the incorporated advice.

In this example the same SQL statement described above provided several advice suggestions.
The advice describing changing the subquery to a join is chosen. Since the sort was highlighted
as the potentially high cost step and the access statistics indicate that the data was sorted to

17

remove duplicates, possibly rewriting this statement as a join may remove the need for the sort,
thus reducing the cost of execution.

Scenario Testing
The SQL Tuning product provides a robust tuning environment that lets the user work with
multiple scenarios of a base SQL statement. The scenario capability lets the user keep the target
statement in its original form with modifications placed in separate scenarios. Scenarios can be
based on manual statement modifications or generated from the component's tuning advice.
Similar to a science experiment, the original SQL statement remains intact as a baseline. Each
scenario is then designed to incorporate a modified version of that SQL. Multiple scenarios
allow the user to determine exactly which modification had the most impact on the SQL
statement. Each scenario maintains a separate access plan and object statistics.


Quest Centrals SQL Tuning access path display.

In this example, a new scenario was created applying the advice, the query was rewritten using
a join rather than a subquery. The original subquery remains intact in the original SQL
scenario, and a new scenario titled Join was created to contain the new join statement. By
viewing the access path it can be immediately determined that the sort is no longer necessary to
retrieve the result set.

Compare Engine
Along with scenario testing, the SQL tuning product contains a powerful compare engine.
Modifying the SQL to tune the access path is useful, but the bottom line is determining the cost

18

associated with each SQL statement. The compare engine uses CPU cost and elapsed time to
identify and illustrate the statement that will result in the most significant improvement.
Additionally, each aspect of the scenario can be compared; the SQL text, access path, and the
execution results.


Comparison of two scenarios. The original SQL statement contains a subquery, the Join scenario
contains the same query written as a join.

In this example we compared our original SQL statement containing the subquery with the new
join statement. Instantaneously we can determine that using the join reduced the CPU costs by
approximately 75% and reduced the response time by 30%. Comparing the access plans
confirms the differences; in this case an additional join was added and the sort was eliminated.

Summary
Quest Central for DB2 SQL Tuning is the only complete SQL tuning product available today.
In the example provided the product followed each step of the SQL tuning process to
successfully tune the offending SQL by:
Step 1: Analyzing the access path and detecting a data sort.
Step 2: Reviewed the advice and determined the statement could be rewritten as a join
Step 3: Created a new scenario with the join statement and ran the explain
Step 4: Compared the join statement to the subquery

19

RESULTS: Reduced the CPU cost by 75% and reduced response time by 30%

The product correlates all the necessary statement and object information in a complete tuning
environment that is specifically designed for access path analysis, determining a solution,
testing that solution and comparing the results. The SQL Tuning product guides the user
through the tuning process with intelligent advice that suggests statement modifications to
improve performance, and even rewrites SQL statements to implement the selected advice.
Quest Central is an easy and efficient solution that is critical to your application infrastructure.
Optimized application SQL creates higher-quality applications, increasing return on investment
and providing the user with improved application response time.
Quest Software
Quest Software, Inc. is a leading provider of performance management solutions designed to
maintain the integrity of mission-critical business transactions and maximize the performance
of enterprise applications. Our solutions address the needs of todays 24x7x365 businesses
where demands on the information technology infrastructure are high and tolerance for
downtime is low.
Founded in 1987, Quest Software now helps more than 100,000 users achieve the best possible
performance from their enterprise systems so the end user experience is a positive one. Based
in Irvine, California, Quest Software has offices worldwide and over 1,000 employees. For
more information, visit www.quest.com.
About the Author
Deb Jenson is the Director of DB2 Development with Quest Software. She is responsible for
the overall development and strategic direction of DB2 database productivity tools. Deb has 12
years experience working with DB2 as both a DBA and with various software vendors. Prior to
Quest Software she was a VP of Development at Platinum Technology.























2001 Quest Software, Inc. All rights reserved. Quest Central is a trademark of Quest Software. All other brands or
product names are trademarks or registered trademarks of their respective owners.