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 database—frequently causes this to happen.

Like other databases, IBM DB2 is negatively affected by poor application SQL. Bad SQL—like bad grammar—will 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 Software’s 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 application’s 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 Central’s 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 statement’s 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, let’s 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 statement’s 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');

SQssrtctsol

Teiaa

Visual Explain describing access path with object statistics.

13

QL Tuning from Quest uest Central’s SQL Tuning product addresses all four steps necessary to effectively tune SQL

tatements. The comprehensive tuning lab provides all the information needed to tune a SQL tatement. Step one provides users the ability to easily step through the graphical epresentation of the access plan, which includes a plain English translation to fully understand he access path. Expert tuning advice can assist with step two; determining what modifications an be made to a SQL statement to gain more efficient access. Providing scenarios fulfills step hree which is a method to test out any modifications without affecting the original SQL tatement. Lastly step four provides a compare engine, which can be invoked to compare the riginal SQL to one, or multiple scenarios to determine which SQL statement offered the owest resource usage.

his approach is the best SQL tuning technique for application developers and DBAs. This nvironment facilitates both the expert and the novice. The expert can use the access path nformation to gather all information necessary to analyze the SQL and use the scenario testing nd compare engine to test various modifications. The novice user can simply apply the advice nd immediately use the compare facility to see the results.

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 Quest’s 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 statement’s 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 Central’s 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 optimizer’s 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 Central’s 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 today’s 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.