TECHNICAL REPORT

DB2 Universal Database Enterprise Edition V7.2 Basic Performance Tuning Guidelines
Roger E. Sanders, IBM A.T.E., C.S.E., C.S. DB2 UDB Network Appliance, Inc. November 2002 TR3222

TECHNICAL REPORT Network Appliance, a pioneer and industry leader in data storage technology, helps organizations understand and meet complex technical challenges with advanced storage solutions and global data management strategies.

Abstract When DB2 Universal Database (DB2 UDB) is first installed, it is configured such that it is guaranteed to run on any system that meets minimum hardware requirements. As a result, the basic configuration provided must be tuned in order to achieve optimum performance on systems that exceed DB2 UDBs minimum hardware requirements. This document provides a set of guidelines that can be used to modify DB2 UDBs basic configuration in such a way that overall database performance will be improved.

Network Appliance Inc.

TECHNICAL REPORT

Table of Contents
1. 2. 3. 3.1. 3.2. 3.3. 3.3.1. 3.4. 3.4.1. 3.4.2. 3.4.3. 4. 4.1. 4.1.1. 4.2. 4.2.1. 4.3. 4.4. 5. 5.1. 6. 7. 7.1. 7.2. 7.3. List of Figures and Tables An Overview of Performance Tuning and the Purpose of this Technical Report DB2 Universal Database Concepts (Performance-Related) Instances Databases Buffer Pools A Word about I/O Page Cleaners Tablespaces System-Managed Space (SMS) Tablespaces Database-Managed Space (DMS) Tablespaces Containers Configuring DB2 Instances and Databases The DB2 Database Manager Instance Configuration Viewing/Changing the Value of a DB2 Database Manager Configuration Parameter The DB2 Database Configuration Viewing/Changing the Value of a DB2 Database Configuration Parameter The Configure Performance Wizard The db2AutoConfig() Application Programming Interface (API) Registry and Environment Variables Viewing/Changing the Value of a DB2 Registry/Environment Variable Buffer Pools and Performance Tablespaces and Performance Page Size Extent Size Prefetch Size 3 4 5 5 6 6 6 8 8 8 9 10 10 12 14 15 17 18 19 22 24 25 25 25 26

Network Appliance Inc.

TECHNICAL REPORT

7.4. 7.5. 7.6. 7.7. 7.8. 8. 8.1. 8.2. 9. 10.

Determining the Optimum Extent Size to Use Determining the Optimum Prefetch Size to Use An Example Extent and Prefetch Size Calculation Splitting Data across Multiple Tablespaces A Word about db2empfa System Catalog Statistics and Performance The Run Statistics Utility When to Use the Run Statistics Utility Conclusion References

26 27 27 28 28 28 29 30 31 32

Network Appliance Inc.

TECHNICAL REPORT

1. List of Figures and Tables Figure 1 DB2s hierarchic relationship among systems, instances, and databases. Figure 2 Relationship between buffer pools, tablespaces, and databases. Figure 3 Invoking the Configure Instance dialog from DB2s Control Center. Figure 4 The Configure Instance dialog. Figure 5 Invoking the Configure Database dialog from DB2s Control Center. Figure 6 The Configure Database dialog. Figure 7 Invoking the Configure Performance Wizard from DB2s Control Center. Figure 8 The first page of the Configure Performance Wizard. Figure 9 Tablespace containers and extents.

Table 1 Characteristics of SMS and DMS tablespaces. Table 2 DB2 Database Manager instance configuration parameters that can impact performance. Table 3 DB2 database configuration parameters that can impact performance. Table 4 DB2 registry/environment variables that can have an impact on performance. Table 5 Options recognized by the db2set command.

2. An Overview of Performance Tuning and the Purpose of this Technical Report What is performance and how do you go about improving it? In its simplest terms, performance is the way a computer system behaves while it is executing a given operation. Performance is measured in terms of system response time, throughput, and availability and it can be affected by the resources that are available in a system as well as how well those resources are used and shared. If a system suffers from poor performance, there are often many ways in which it can be tuned. However, because there is such a variety of tuning options available, tuning should only be done with a specific goal in mind. For example, a tuning goal might be to obtain faster system response times or higher throughput without degrading service to your users or increasing processing costs. And because tuning should be performed in an organized, concise manner, tuning should be done with a specific tuning plan in mind. A good approach to performance tuning is outlined in the following set of guidelines: 1. Check for Hardware and Software Problems Some performance problems can be corrected simply by applying service packs to your software, by upgrading your hardware, or both. Why spend the time and effort monitoring and tuning other parts of your system when a simple service may resolve the problem? a. Understand the Problem Before You Upgrade Your Hardware

Network Appliance Inc.

TECHNICAL REPORT

Even if it seems that additional storage space or processor power could improve performance immediately, take the time to understand where the bottlenecks are. You might choose to add more NICs to a system only to find out that the system does not have the processing power to exploit them. 2. Consider the Whole System You cant tune one aspect of a system without affecting at least one other part of that system. So before you make any changes, consider how those changes will affect the system as a whole. 3. Measure and Reconfigure by Levels Do not tune more than one level of your system at a timeeven if you are sure all the changes you plan to make will be beneficial, you will have no way to evaluate how much each change contributed to any performance improvements seen. Conversely, if you are wrong and performance goes down instead of up, you will not know which particular change had the negative impact on performance. In a database server environment, the following list of levels within a system can be used as a guide: Hardware Operating system Communications software Database SQL statements Applications

4. Change One Parameter at a Time For the same reasons that you should tune only one system level at a time, you should change only one configuration parameter at a time. 5. Put Fallback Procedures in Place Before You Start Because some changes you make while tuning for performance may actually degrade rather than improve system performance, you need to be prepared to back out every change made. Note: If you are using Network Appliance filers to accommodate your DB2 storage, an excellent way to back out changes would be to take a Snapshot copy of the filer volume that the database is stored on before each change is made, and then restore the volume with SnapRestore if the change turns out to be detrimental to performance. For further information on Network Appliance Snapshot and SnapRestore technology, please refer to the technical report entitled SnapMirror and SnapRestore: Advances in Snapshot Technology (http://www.netapp.com/tech_library/3043.html), which is available on the Network Appliance Web site.

Network Appliance Inc.

TECHNICAL REPORT

6. Do Not Tune Just for the Sake of Tuning Tuning should be performed to relieve identified constraints. If you tune resources that are not the primary cause of a performance problem, there will be little or no noticeable effect until the primary problem has been resolved. Furthermore, such actions can actually make subsequent tuning work more difficult. 7. Remember the Law of Diminishing Returns The greatest returns in performance tuning usually come from your initial efforts. Subsequent changes typically produce smaller and smaller benefits and require more and more effort. As you can see, tuning a system can be quite involved and volumes could be written (and often have been) on tuning each system level. Because the subject is quite complex, no single paper can really teach you everything you need to know in order to tune a system for optimum performance. However, a single paper can cover the basics needed to tune one level of a system and that is the main purpose of this technical reportthe goal of this paper is to provide you with basic information you can use to tune the database level of a system when DB2 UDB is the database being used. 3. DB2 Universal Database Concepts (Performance-Related) Before you can tune the database level of a DB2 Universal Database system to achieve optimum performance, you must understand how DB2 UDB is structured and you must know how DB2 stores and manages data. This section is designed to provide a basic overview of the concepts you should understand before you attempt to tune a DB2 UDB system. 3.1. Instances DB2 Universal Database sees the world as a hierarchy of several different types of objects. Workstations on which DB2 Universal Database has been installed are known as system objects, and they occupy the highest level of this hierarchy. System objects can represent systems that are accessible to other DB2 clients or servers within a network, or they can represent stand-alone systems that neither have access to nor can be accessed from other DB2 clients or servers. When DB2 Universal Database is installed on a particular workstation (or system), program files for the DB2 Database Manager are physically copied to a specific location on that workstation, and one instance of the DB2 Database Manager is created and assigned to the system as part of the installation process. (Instances comprise the next level in the object hierarchy.) If needed, additional instances of the DB2 Database Manager can be created for a particular system; however, in most configurations, only one instance exists. The default instance for a particular system is defined by the DB2INSTANCE environment variable. Anytime a new instance is created, that instance references the DB2 Database Manager program files that were stored on that workstation during the installation process; thus, each instance behaves like a separate installation of DB2 Universal Database, even though all instances within a particular system share the same binary code. And even though all instances share the same physical code, each can be run concurrently with the others and each has its own environment, which can be modified by altering the contents of its configuration file. (We will examine the contents of the DB2 Database Manager configuration file in Section 4.1. The DB2 Database Manager Instance Configuration.)

Network Appliance Inc.

TECHNICAL REPORT

Every instance controls access to one or more databases. (Databases make up the third level in the object hierarchy.) Every database within an instance is assigned a unique name, has its own set of system catalog tables (which are used to keep track of objects that are created in the database), and has its own configuration file. (We will examine the contents of the database configuration file in Section 4.2. The DB2 Database Configuration.) Figure 1 shows DB2s hierarchic relationship among systems, instances, and databases. 3.2. Databases In its simplest form, a DB2 Universal Databasedatabase is a set of related objects. In fact, when you create a DB2 UDB database, you are establishing an administrative relational database entity that provides an underlying structure for an eventual collection of related objects (such as tables, views, indexes, and so on). This underlying structure consists of a set of system catalog tables (along with a set of corresponding views), a set of tablespaces in which both the system catalog tables and the eventual collection of database objects will reside, and a set of files that will be used to handle database recovery and other bookkeeping details. As we saw earlier, multiple databases can be defined within a single instance and each database has its own configuration file, which allows characteristics of the database, such as memory usage and logging, to be fine-tuned to improve overall database performance. 3.3. Buffer Pools A buffer pool is an area of main memory that has been allocated to the DB2 Database Manager for the purpose of caching table and index data pages as they are created or read from disk. Using a set of heuristic algorithms, the DB2 Manager Database loads pages of data that it thinks are needed or are about to be needed to resolve a query into one or more buffer pools, and it moves pages of data that it thinks are no longer needed back to disk. This improves overall system performance because data can be accessed much faster from memory than from disk. (The fewer times the DB2 Database Manager needs to perform disk I/O, the better the performance.) When a new database is created, one buffer pool, named IBMDEFAULTBP, is also created as part of the database initialization process. On UNIX/Linux platforms, this buffer pool consists of 1,000 4k (kilobyte) pages of memory; on Windows and OS/2 platforms, this buffer pool consists of two hundred and fifty 4k pages of memory. 3.3.1. A Word about I/O Page Cleaners Over time, as pages accumulate in the buffer pool, it becomes full. If the pages in the buffer pool are unmodified, this does not pose a problem because one of the unmodified pages will be overwritten the next time a new page is read. However, if a large amount of data in a table is modified by a single transaction, many data pages in the buffer pool may have been modified but not yet written to disk (such pages are known as dirty pages). Since DB2 cannot overwrite dirty pages in the buffer pool, these dirty pages must be flushed to disk storage before additional pages can be read if the buffer pool is full. Such situations will cause a noticeable decrease in performance.

Network Appliance Inc.

TECHNICAL REPORT

Figure 1) DB2s hierarchic relationship among systems, instances, and databases In this illustration, two instances (DB2_DEV and DB2_PROD) exist on one server (DB_SERVER), and two databases (PAYABLE and RECEIVABLE) exist within each instance. Both instances share the same binary code; however, each has its own configuration file. Likewise, each database within each instance has its own configuration file.

To prevent a buffer pool from becoming full, page cleaner agents are used to flush modified pages to disk at a predetermined interval (by default, when the buffer pool is 60% full in Section 4.2 The DB2 Database Configuration, youll see how this can be changed by modifying the value of the chngpgs_thresh database configuration parameter). This guarantees that one or more buffer pool pages will be available for future read operations.

Network Appliance Inc.

TECHNICAL REPORT

3.4. Tablespaces Mapping a logical database design to physical storage that is available to a system is one of the first tasks that must be performed whenever a new database is created. Such mappings are accomplished through the use of tablespacestablespaces control where data in a database is physically stored on a system and they provide a layer of indirection between the database itself and the container objects in which the actual data resides. By default, each time a new database is created, the following three tablespaces are created and associated with the buffer pool IBMDEFAULTBP as part of the database initialization process: A catalog tablespace named SYSCATSPACE, which is used to store the system catalog tables and views associated with the database A user tablespace named USERSPACE1, which is used to store all user-defined objects (such as tables, indexes, and so on) along with user data A temporary tablespace named TEMPSPACE1, which is used to store temporary tables that might be created in order to resolve a query

Additional tablespaces can be created, modified, and deleted as needed. Regardless of how they are created, all tablespaces are classified according to how their storage space is managed: A tablespace can be either a system-managed space (SMS) or a database-managed space (DMS) tablespace. 3.4.1. System-Managed Space (SMS) Tablespaces With system-managed space (SMS) tablespaces, the operating systems file manager is responsible for allocating and managing the storage space used by the tablespace. SMS tablespaces typically consist of several individual files (representing data objects such as tables and indexes) that are stored in the file system. The tablespace creator designates where these files are to be stored, the DB2 Database Manager controls when they are created, and the operating systems file manager manages how they are physically stored on disk. Unless otherwise specified, all tablespaces are created as SMS tablespaces by default. Note: SMS tablespaces can be used in Network Appliance filer environments that are configured to use NFS, CIFS, and SAN. 3.4.2. Database-Managed Space (DMS) Tablespaces With database-managed space (DMS) tablespaces, the tablespace creator (and in some cases, the DB2 Database Manager) is responsible for allocating the storage space used and the DB2 Database Manager is responsible for managing its usage. Essentially, a DMS tablespace is an implementation of a specialpurpose file system that has been designed specifically to meet the needs of the DB2 Database Manager. The tablespace creator designates one or more locations where this special-purpose file system is to be created, along with the amount of memory that has been (or that is to be) allocated for each. The DB2 Database Manager reserves the amount of space specified, allocates it if appropriate, and manages its use. DMS tablespaces are usually more efficient than SMS tablespaces, but often a database administrator must monitor them closely to ensure they do not run out of storage space. Note: DMS tablespaces can be used in Network Appliance filer environments that are configured to use NFS, CIFS, SAN, and DAFS.

Network Appliance Inc.

TECHNICAL REPORT

Additional differences between SMS tablespaces and DMS tablespaces can be seen in Table 1.
Characteristics The number of storage locations (containers) used can be increased after the tablespace has been created Each storage location (container) used must be the same size Storage location (container) size can be changed after the tablespace has been created Index data for a table can be stored in a separate tablespace Long data for a table can be stored in a separate tablespace A single table can span multiple tablespaces Storage space is only allocated when it is needed Tablespace can span multiple disks Extent size can be changed after tablespace has been created Prefetch size can be changed after tablespace has been created A single tablespace cannot have more than 16,777,215 pages
Table 1) Characteristics of SMS and DMS tablespaces

SMS Tablespaces No

DMS Tablespaces Yes

Yes No

No Yes

No No No Yes Yes No Yes No

Yes Yes Yes No Yes No Yes Yes

Regardless of how they are managed, tablespaces are classified according to the type of data they have been designed to hold. Tablespaces that contain nonvolatile user data are referred to as regular SMS or DMS tablespaces. (Indexes are also stored in regular tablespaces.) Tablespaces that contain non-volatile long data (long varying-length character data or large object (LOB) data) are referred to as long tablespaces. Only DMS tablespaces can be created as long tablespaces. Tablespaces that contain only volatile data are referred to as temporary tablespaces. Temporary tablespaces are classified as either system or user: system temporary tablespaces are used to store internal temporary data that is required during SQL operations such as sorting, reorganizing tables, index creation, and table joins. User temporary tablespaces are used to store declared global temporary tables that, in turn, are used to store application-specific temporary data. 3.4.3. Containers Every tablespace is made up of at least one container, which is essentially an allocation of physical storage that the DB2 Database Manager is given unique access to. Containers provide a way of defining what location on a specific storage device will be made available for storing database objects. A container can be a directory (such containers are known as PATH containers), a file (known as FILE containers), or a raw device (known as DEVICE containers). When FILE containers are used, a specific file size must be specified, and when DEVICE containers are used, a device size must be specified and the device specified must already exist on the system. A single tablespace can span many containers, but each container can belong to only one tablespace. Figure 2 illustrates the relationship between buffer pools, tablespaces, and containers.

Network Appliance Inc.

10

TECHNICAL REPORT

Figure 2) Relationship between buffer pools, tablespaces, and databases

It is important to note that SMS tablespaces can reference PATH containers while DMS tablespaces can reference FILE or DEVICE containers, but never PATH containers. Furthermore, in Network Appliance filer DB2 environments that are configured to use NFS and CIFS, only PATH and FILE containers are supported; in Network Appliance filer DB2 environments that are configured to use DAFS, only DEVICE containers are supported; and in Network Appliance filer environments that are configured to use SAN, all three types of containers are supported. 4. Configuring DB2 Instances and Databases The Performance Tuning Starting Point DB2 Universal Database uses an extensive array of configuration parameters to control how system resources are allocated and utilized. In most cases, the default values provided for these configuration parameters are sufficient to meet an applications needs. However, because the default values provided are oriented toward database systems that have relatively small amounts of memory and that act as dedicated database servers, overall system and database performance can usually be greatly improved by changing the value of one or more configuration parameters. In fact, DB2 Database Manager instance and/or DB2 database configuration parameter values should always be modified if your database environment contains one or more of the following: Large databases Databases that normally service large numbers of concurrent connections One or more special applications that have high performance requirements A special hardware configuration Unique query and/or transaction loads

Network Appliance Inc.

11

TECHNICAL REPORT

Unique query and/or transaction types

4.1. The DB2 Database Manager Instance Configuration Each DB2 Database Manager instance configuration is comprised of 89 different parameters. Some of these parameters can have a significant impact on performance while others have little or no impact whatsoever. The DB2 Database Manager configuration parameters that can have the greatest impact on performance are shown in Table 2.
Parameter agentpri Value Range / Default 41 125 4k Pages 41 128 4k Pages 0 6 4k Pages Default: -1 aslheapsz 1 524,288 4k Pages Default: 15 dos_rqrioblk 4096 65,535 Default: 4096 Specifies the DOS requester I/O block size (which controls the size of the I/O blocks that are allocated on both the client and the server workstations). This parameter is only applicable on DOS clients, including DOS clients running under OS/2. Specifies the number of Fast Communications Manager (FCM) message anchors used. Agents use the message anchors to send messages among themselves. 4k Specifies the number of 4k buffers that are used for internal communications (messages) among the nodes in an instance. Specifies the size (in pages) of the memory shared between a local client application and a DB2 Database Manager agent. Description Specifies the execution priority that will be assigned to DB2 Database Manager processes and threads on a particular workstation.

fcm_num_anchor s

-1, 128 fcm_num_rqb Default: -1

fcm_num_buffer s

128 fcm_num_rqb Buffers

Default: 512, 1024, or 4096 fcm_num_connec t -1, 128 fcm_num_rqb Default: -1 fcm_num_rqb 128 120,000 250 2,097,152 Default: 256, 512, 2048 or 10,000 intra_parallel SYSTEM, YES, NO Default: NO java_heap_sz 0 4096 4k Pages Default: 512 Specifies the maximum size of the heap used by the Java interpreter. For nonpartitioned database systems, one heap is allocated for the instance; for partitioned database systems, one heap is allocated for each database partition server. Specifies the maximum degree of parallelism used for any SQL statement executing on this instance of the DB2 Database Manager. For a multinode system, this parameter applies to the degree of parallelism used within a Specifies whether or not the DB2 Database Manager instance can use intrapartition parallelism. Specifies the number of FCM request blocks used. Request blocks are the media through which information is passed between the FCM daemon and an agent. Specifies the number of FCM connection entries available. Agents use connection entries to pass data among themselves.

max_querydegre e

ANY, 1 32 767 Default: ANY

Network Appliance Inc.

12

TECHNICAL REPORT

single node. num_poolagents -1, 0 maxagents Default: -1 Rqrioblk 4096 65,535 Bytes Default: 32,767 sheapthres 250 2,097,152 4k Pages Default: 10,000 or 20,000
Table 2) DB2 Database Manager instance configuration parameters that can impact performance

Specifies the size to which the agent pool is allowed to grow.

Specifies the size (in bytes) of the communication buffer used between remote applications and their database agents on the database server.

Specifies the limit on the total amount of memory (in pages) available for sorting across the entire DB2 Database Manager instance.

When tuning a DB2 Database Manager instance for performance, the configuration parameters shown in Table 2 should always be modified first.

Figure 3) Invoking the Configure Instance dialog from DB2s Control Center (Version 7.x)

4.1.1. Viewing/Changing the Value of a DB2 Database Manager Configuration Parameter

Network Appliance Inc.

13

TECHNICAL REPORT

The value of one or more DB2 Database Manager configuration parameters can be viewed and/or changed using the Configure Instance dialog, which is invoked by selecting the Configure action from the Instances menu found in the Control Center (a Java-based graphical user interface). Figure 3 shows the Control Center menu items that must be selected in order to activate the Configure Instance dialog; Figure 4 shows how the Configure Instance dialog typically looks after it has been activated. The value of all configuration parameters for a particular DB2 Database Manager instance can also be viewed by attaching to that instance and executing the GET DATABASE MANAGER CONFIGURATION command, either from the Command Center or from the Command Line Processor. The syntax for this command is: GET [DATABASE MANAGER | DB MANAGER | DBM] [CONFIGURATION | CONFIG | CFG]

Figure 4) The Configure Instance dialog (Version 7.x)

Network Appliance Inc.

14

TECHNICAL REPORT

The value of one or more DB2 Database Manager configuration parameters can be changed by executing the UPDATE DATABASE MANAGER CONFIGURATION command, either from the Command Center or from the Command Line Processor. The syntax for this command is: UPDATE [DATABASE MANAGER | DB MANAGER | DBM] [CONFIGURATION | CONFIG | CFG] USING [Parameter] [Value] <IMMEDIATE | DEFERRED> where: Parameter Value Identifies the DB2 Database Manager configuration parameter (by keyword) whose value is to be modified. Identifies the new value that is to be assigned to the DB2 Database Manager configuration parameter specified.

For example, when executed, the following UPDATE DATABASE MANAGER CONFIGURATION command will change the value of the numdb DB2 Database Manager configuration parameter to 4: UPDATE DBM CFG USING NUMDB 4 4.2. The DB2 Database Configuration Each DB2 database configuration is comprised of 76 different parameters and, just like the DB2 Database Manager instance configuration parameters, some of these parameters can have a significant impact on performance while others have little or no impact whatsoever. The database configuration parameters that can have the most significant impact on performance are shown in Table 3.
Parameter avg_appls Value Range (Default) 1 maxappls Default: 1 Description Specifies the average number of active applications that normally access the database. This parameter is used by the SQL optimizer to help estimate how much buffer pool memory will be available for the chosen access plan at application run time. Specifies the size (in pages) of the buffer pool that is used to store and manipulate data read from the database.

buffpage

2 524,288 4k Pages Default: 250 or 1000

chngpgs_thresh

5 99% Default: 60

Specifies the level (percentage) of pages that must be changed before the asynchronous page cleaners used by DB2 will be started if they are not already active. Specifies the default value for the CURRENT DEGREE special register and the DEGREE bind option.

dft_degree

-1, 1 32,767 Default: 1

locklist

4 60,000 4k Pages Default: 25, 50, or 100

Specifies the maximum amount of storage (in pages) that will be allocated for the lock list.

logbufsz

4 4096 4kPages Default: 8

Specifies the number of pages that are used to buffer log records before they are written to disk. This buffer is allocated from the database heap.

Network Appliance Inc.

15

TECHNICAL REPORT

maxlocks

1 100 Default: 10 or 22

Specifies the maximum percentage of the lock list that any application program can use.

mincommit

1 25 Default: 1

Specifies the number of SQL commits that can be grouped for the database. Better control of I/O and log activity can be achieved by grouping SQL commits. Specifies the number of asynchronous page cleaners that are used by a database.

num_iocleaners

0 255 Default: 1

num_ioservers

1 255 Default: 3

Specifies the number of I/O servers for a database. I/O servers are used on behalf of database agents to perform prefetch I/O and asynchronous I/O needed by utilities such as backup and restore. Specifies the amount of application heap memory that will be used for caching packages.

pckcachesz

-1, 32 64,000 4kPages Default: -1

seqdetect

YES, NO Default: YES

Specifies whether or not sequential detection for the database is enabled.

sortheap

16 524,288 Default: 256

Specifies the number of private memory pages that are available for each sort operation in an application program.

Table 3) DB2 database configuration parameters that can impact performance

When tuning a DB2 database for performance, it is always a good idea to start by making adjustments to the configuration parameters shown in Table 3. 4.2.1. Viewing/Changing the Value of a DB2 Database Configuration Parameter The value of one or more DB2 database configuration parameters can be viewed and/or changed using the Configure Database dialog, which is invoked by selecting the Configure action from the Databases menu found in the Control Center. Figure 5 shows the Control Center menu items that must be selected in order to activate the Configure Database dialog; Figure 6 shows how the Configure Database dialog typically looks after it has been activated. The value of all configuration parameters for a particular database can also be viewed by attaching to that instance and executing the GET DATABASE CONFIGURATION command, either from the Command Center or from the Command Line Processor. The syntax for this command is: GET [DATABASE | DB] [CONFIGURATION | CONFIG | CFG] FOR [DatabaseAlias] where: DatabaseAlias Identifies the database (by its alias) that configuration parameter values are to be obtained for.

Network Appliance Inc.

16

TECHNICAL REPORT

Figure 5) Invoking the configure database dialog from DB2s Control Center (Version 7.x)

The value of one or more database configuration parameters can be changed by executing the UPDATE DATABASE CONFIGURATION command, either from the Command Center or from the Command Line Processor. The syntax for this command is: UPDATE [DATABASE | DB] [CONFIGURATION | CONFIG | CFG] FOR [DatabaseAlias] USING [Parameter] [Value] <IMMEDIATE | DEFERRED> where: DatabaseAlias Parameter Value Identifies the database (by its alias) that configuration parameter values are to be obtained for. Identifies the DB2 Database Manager configuration parameter (by keyword) whose value is to be modified. Identifies the new value that is to be assigned to the DB2 Database Manager configuration parameter specified.

Network Appliance Inc.

17

TECHNICAL REPORT

For example, when executed, the following UPDATE DATABASE CONFIGURATION command will change the value of the autorestart database configuration parameter for the SAMPLE database to OFF: UPDATE DB CFG FOR SAMPLE USING AUTORESTART OFF

Figure 6) The configure database dialog (Version 7.x)

4.3. The Configure Performance Wizard With such a broad range of configuration parameters to choose from, deciding where to begin making changes can be a difficult choice. Fortunately, if a system has been configured to support DB2 UDBs Control Center, using the Configure Performance Wizard can eliminate some of the guesswork. . If you have had the opportunity to use one in the past, you are probably already aware that a wizard is a sequenced set of dialogs that are designed to guide a user through the steps needed to perform a complex task. The dialogs (often referred to as pages) that make up the wizard are normally accessed in the order that they have been sequenced; thus, they orchestrate a step one, step two, step three,

Network Appliance Inc.

18

TECHNICAL REPORT

input scenario. The nine dialogs/pages that make up the Configure Performance Wizard are designed to capture specific information about the typical transaction workload a database is expected to handle and to assist with performance tuning by recommending/making changes to configuration parameters based on the information provided. Figure 7 shows the Control Center menu items that must be selected in order to activate the Configure Performance Wizard; Figure 8 shows what the first page of this wizard looks like.

Figure 7) Invoking the Configure Performance Wizard from DB2s Control Center (Version 7.x)

4.4. The db2AutoConfig() Application Programming Interface (API) Because any configuration changes produced by the Configure Performance Wizard will almost always result in better performance, this wizard should be used first, before any other performance tuning attempts are made. But what if your system is not configured to support the DB2 UDB Control Center and the Configure Performance Wizard is unavailable? Unfortunately, there is no equivalent DB2 command. However, there is an API that, when called from an application program, will perform the same tasks as the Configure Performance Wizard. This API, named db2AutoConfig(), must be coded in a high-level programming language (such as C and C++) source code file and the same information that is collected by the Configuration Performance Wizard must be provided as input to this API.

Network Appliance Inc.

19

TECHNICAL REPORT

Figure 8) The first page of the Configure Performance Wizard (Version 7.x)

5. Registry and Environment Variables In addition to DB2 Database Manager instance and database configuration parameters, DB2 UDB utilizes several registry and environment variables to configure the system where DB2 UDB has been installed. Most registry/environment variables do not have any significant impact on performance; the registry/environment variables that can have an impact on performance are shown in Table 4.
Registry/Environment Variable Value Range (Default) ON, OFF Default: OFF DB2_BIN_SORT YES, NO Default: YES Specifies whether or not a new sort algorithm that reduces the CPU time and elapsed time for sort operations is to be used. This new algorithm extends the extremely efficient integer sorting technique of DB2 UDB to data types such as BIGINT, CHAR, VARCHAR, FLOAT, and DECIMAL, as well as combinations of these data types. AIX Description Platform

DB2_AVOID_PREFETCH

Specifies whether or not prefetching should be used during crash recovery.

All

Network Appliance Inc.

20

TECHNICAL REPORT

DB2BPVARS

Path Default: Null

Specifies the location of a file that contains parameter values that are to be used when tuning buffer pools. Supported parameters include: NT_SCATTER_DMSFILE, NT_SCATTER_DMSDEVICE, and NT_SCATTER_SMS. For each of these parameters, the default value is 0 (or OFF); and the possible values include: 0 (or OFF) and 1 (or ON). Each parameter is used to turn scatter read on/off for the respective type of tablespace containers used and each can only be enabled (turned ON) if DB2NTNOCACHE is set to ON in the system registry. Specifies whether or not pointer checking for input is to be performed. Specifies whether or not the UDB server will perform a catalog lookup for all DARIs and stored procedures before looking in the function subdirectory of the sqllib subdirectory; and in the unfenced subdirectory of the function subdirectory of the sqllib subdirectory. Specifies whether or not the query optimizer will use optimization extensions to improve query performance. Specifies whether or not the AIX operating system is to stop paging memory so that it no longer occupies any real storage. Setting DB2MEMDISCLAIM to YES tells DB2 UDB to disclaim some or all memory once freed, depending on the value specified with the DB2MEMMAXFREE registry/environment variable. If DB2MEMMAXFREE is null, then all of the memory is disclaimed once freed. If DB2MEMMAXFREE is given a value, then only some of the memory is disclaimed once freed (up to the value given in DB2MEMMAXFREE). This ensures that the memory is made readily available for other processes as soon as it is freed. Specifies the amount of free memory that is to be retained by each DB2 agent. (IBM recommends that if you use this feature, you specify a value of 8MB.)

Windows

DB2CHKPTR

ON, OFF Default: OFF

All

DB2_DARI_LOOKUP_ALL

ON, OFF Default: OFF

All

DB2_EXTENDED_OPTIMIZATION

ON, OFF Default: OFF

All

DB2MEMDISCLAIM

YES, NO Default: Null

AIX

DB2MEMMAXFREE

4,000,000 256,000,000 bytes Default: Null

AIX

DB2_MMAP_READ

ON, OFF Default: OFF

DB2_MMAP_WRITE

ON, OFF Default: OFF

DB2_NO_PKG_LOCK

ON, OFF Default: OFF

Used in conjunction with DB2_MMAP_WRITE to allow DB2 to use mmap as an alternate method of I/O. In most environments, mmap should be used to avoid operating system locks when multiple processes are writing to different sections of the same file. Used in conjunction with DB2_MMAP_READ to allow DB2 to use mmap as an alternate method of I/O. In most environments, mmap should be used to avoid operating system locks when multiple processes are writing to different sections of the same file. Specifies whether or not the Global SQL Cache is to operate without the use of package locks in order to protect cached package entries. (Package locks are internal system locks.) To improve performance (because acquiring and freeing locks takes time), you

AIX

AIX

All

Network Appliance Inc.

21

TECHNICAL REPORT

DB2NTMEMSIZE

Numeric value Default: (See below) Database Kernel (DBMS): 16,777,216 Parallel FCM Buffers (FCM): 22,020,096 Database Admin GUI (DBAT): 33,554,432 Fenced Stored Procedures (APLD): 16,777,216

may choose to work in a no package lock mode. Windows NT requires that all shared memory segments be reserved at DLL initialization time in order to guarantee matching addresses across processes. DB2NTMEMSIZE allows you to override the DB2 defaults on Windows NT if necessary, however, in most situations, the default values should be sufficient.

Windows

DB2NTNOCACHE

ON, OFF Default: OFF

Specifies whether or not the operating system will cache DB2 files. This applies to all data except for files that contain LONG FIELDS or LOBS. Eliminating system caching allows more memory to be available to the database so that the buffer pool or sortheap can be increased. Sets the priority class for the DB2 instance (program DB2SYSCS.EXE). There are three priority classes available: NORMAL_PRIORITY_CLASS (the default priority class) REALTIME_PRIORITY_CLASS (R) HIGH_PRIORITY_CLASS (H) Specifies the minimum and maximum working set size available to DB2. By default, when Windows NT is not in a paging situation; a processs working set can grow as large as needed. However, when paging occurs, the maximum working set that a process can have is approximately 1MB. DB2NTWORKSET allows you to override this default behavior. Specifies the size of the buffer pool, in pages, that is to be created at database activation, or the first time a connection is established. This registry/environment variable is useful when failures resulting from memory constraints occur during database activation or the first time a connection is established. Such a memory constraint could arise either because of a real memory shortage (which is rare); or, because of an attempt by the DB2 Database Manager to allocate large, inaccurately configured buffer pools. Controls the priorities of DB2 processes and threads.

Windows

DB2NTPRICLASS

R, H, (any other value) Default: Null

Windows

DB2NTWORKSET

Positive number, Positive number Default: 1,1

Windows

DB2_OVERRIDE_BPF

A positive number of 4k pages

All

DB2PRIORITIES

Values are platformdependent

All

Network Appliance Inc.

22

TECHNICAL REPORT

DB2_RR_TO_RS

YES, NO Default: NO

DB2_SORT_AFTER_TQ

YES, NO Default: NO

Specifies whether or not the RR isolation level is to be downgraded to RS for user tables. If your applications do not require RR semantics, this registry/environment variable can be used to reduce the next-key lock contention problems that can sometimes occur under RR. Specifies how the DB2 optimizer works with directed table queues in a partitioned database environment when the receiving end requires the data to be sorted, and the number of receiving nodes is equal to the number of sending nodes. When this registry/environment variable is set to NO, the DB2 optimizer tends to sort at the sending end and merge the rows at the receiving end; when set to YES, the DB2 optimizer tends to transmit the rows unsorted, not merge at the receiving end, and sort the rows at the receiving end after receiving all the rows. Specifies whether or not DB2 is to use parallel I/O while reading or writing data from and to tablespace containers even if the tablespace only contains one container.

All

All

DB2_PARALLEL_IO Important: This registry/environment variable should always be set to the following when using Network Appliance filers for DB2 storage: DB2_PARALLEL_IO=* DB2_STRIPED_CONTAINERS Important: This registry/environment variable should always be set to the following when using Network Appliance filers for DB2 storage: DB2_STRIPED_CONTAINERS=ON DB2_HASH_JOIN

*, Null Default: Null

All

ON, Null Default: Null

Specifies whether or not the tablespace container ID tag is to take up a partial or a full RAID disk stripe. When using RAID devices for table space containers, it is suggested that the table space be created with an extent size that is equal to, or a multiple of, the RAID stripe size. However, because of the one-page container tag, the extents will not line up with the RAID stripes, and it may be necessary to access more physical disks than would be optimal during an I/O request unless this registry/environment variable is set to ON. Specifies whether or not a hash join is a possible join method to use when compiling a data access plan.

All

YES, NO Default: NO

All

Table 4) DB2 registry/environment variables that can have an impact on performance

Because changes made to registry and environment variables impact the entire system, such changes should be carefully considered before they are made. After changing the value of a registry variable, the DB2 Database Manager must be stopped and then restarted before the changes will take effect; after changing the value of any environment variable, the system must be rebooted before the changes will take effect.

5.1. Viewing/Changing the Value of a DB2 Registry/Environment Variable The value of one or more DB2 registry/environment variables can be viewed or changed by executing the db2set system command from the Command Line Processor. The syntax for this command is: db2set <[Variable] = [Value]> <-g> <-i [Instance] <NodeNumber>>

Network Appliance Inc.

23

TECHNICAL REPORT

<-all> <-null> <-r [Instance] <NodeNumber>> <-n [DASNode] <-u [UserID] <-p [Password]>>> <-l | -lr> <-v> <-ul | -ur> <-h | -?> where: Variable Value Identifies the registry or environment variable whose value will be displayed, set, or removed. Identifies the value that will be assigned to the registry or environment variable specified. If no value is specified, but a registry or environment variable is specified, the registry or environment specified is deleted. Identifies the instance profile that the registry or environment variable specified is associated with. Identifies a specific node that is listed in the file db2nodes.cfg. Identifies the name of the node where the remote DB2 Administration Server instance resides. Identifies the authentication ID that will be used to attach to the DB2 Administration Server instance. Identifies the password (for the authentication ID) that will be used to attach to the DB2 Administration Server instance.

Instance NodeNumber DASNode UserID Password

Table 5 describes the other options shown with this command.

Command Option -g -i -all Description Indicates that a global profile variable will be displayed, set, or removed. Indicates that an instance profile variable will be displayed, set, or removed. Indicates that all occurrences of the local environment variables as defined in the following are displayed: The environment, denoted by [-e] The node-level registry, denoted by [-n] The instance-level registry, denoted by [-i] The global-level registry, denoted by [-g] Indicates that the value of the variable at the specified registry level will be set to NULL. (This avoids having to look up the value in the next registry level, as defined by the search order.) Indicates that the profile registry for the given instance is reset. Indicates that a remote DB2 Administration Server instance node name is specified. Indicates that an authentication ID that will be used to attach to the DB2 Administration Server instance is specified. Indicates that a password for the authentication ID specified is provided. Indicates that all instance profiles will be listed. Indicates that all registry variables supported will be listed.

-null -r -n -u

-p -l -lr

Network Appliance Inc.

24

TECHNICAL REPORT

-v -ul -ur -h or -?

Indicates that verbose mode will be used. Indicates that user profile variables will be accessed. (Only valid on Windows operating systems.) Indicates that user profile variables will be refreshed. (Only valid on Windows operating systems.) Indicates that help information for the db2set command will be displayed. If this option is specified, all other options are ignored and help information is displayed.

Table 5) Options recognized by the db2set command

For example, when executed, the following db2set system command will display all values that have been defined for the DB2COMM registry/environment variable: db2set all DB2COMM Note: If the db2set command is executed without options, a list of every registry/environment variable that has been set, along with its value, will be returned. 6. Buffer Pools and Performance Earlier, we saw that a buffer pool is an area of main memory that has been allocated to the DB2 Database Manager for the purpose of caching table and index data pages as they are read from disk and/or modified in response to a query. The main purpose of buffer pools is to improve overall database performance by reducing disk input/output operationsdata can be accessed much faster from memory than from disk. In fact, aside from configuration settings, how buffer pools are created and used is the single most important area where database performance can be improved. So just how are buffer pools used? When a row of data in a table is first accessed, the DB2 Database Manager places the page that contains that data into a buffer pool before passing it on to the application or user that requested it. From that moment on, every available buffer pool is searched each time data is requested. If the requested data is found on a page that has been stored in a buffer pool, it is immediately passed to the appropriate application or user. If the requested data does not exist in a buffer pool, the DB2 Database Manager retrieves it from the disk and copies it to a buffer pool before passing it on. Once a page has been copied to a buffer pool, that page stays in the buffer pool until the database is shut down, or until the space that is occupied by that page is needed to store another page. In the latter case, the page that is to be removed from the buffer pool in order to make room for the new page is selected by examining the following: When the page was last referenced The likelihood that the page will be referenced again The page type Whether or not the page in memory has been changed but has not yet been written to disk (When changed pages are written to disk, they are not removed from memory unless the space they occupy is needed to store other pages.)

By default, DB2 Universal Database creates one buffer pool (named IBMDEFAULTBP) of an appropriate size for the platform used whenever a database is created. (On UNIX/Linux platforms, this buffer pool

Network Appliance Inc.

25

TECHNICAL REPORT

consists of one thousand 4k (kilobyte) pages of memory; on Windows and OS/2 platforms, this buffer pool consists of two hundred and fifty 4k pages of memory.) Additional buffer pools can be created by selecting the appropriate action from the Buffer Pools menu found in the Control Center or by executing the CREATE BUFFERPOOL SQL statement. Since buffer pools play a significant part in database performance, an important question to ask when tuning for performance is How many buffer pools are needed and how should they be used? In most environments, the number of buffer pools that can be used effectively is dependent on the amount of memory available. If the total amount of memory available is only capable of holding ten thousand 4k pages (or less), it is often better to use a single buffer pool. However, if the amount of memory available is much greater, you should consider creating individual buffer pools for each of the following: Every temporary tablespace used Every tablespace that contains tables that arecomprised of data that is accessed consistently and repeatedly by many short-duration update transactions/applications Every tablespace that contains tables and indexes that are updated frequently Every tablespace that contains tables and indexes that are queried frequently but are updated infrequently Every tablespace that contains data that is accessed by applications that are used infrequently Any tablespace that contains data and indexes you want to favor

7. Tablespaces and Performance It was mentioned earlier that tablespaces control where data in a database is physically stored on a system and that DMS tablespaces are usually more efficient than SMS tablespaces. In addition to how a tablespace is managed, three other tablespace characteristics must be taken into consideration when designing a database for optimum performance. These characteristics are: Page size Extent size Prefetch size

7.1. Page Size With DB2 UDB, data is transferred between tablespace containers and buffer pools in discrete blocks that are called pages. (The memory reserved to buffer a page transfer is called an I/O buffer.) The actual page size used by a particular tablespace is determined by the page size of the buffer pool the tablespace is associated with. Four different page sizes are available: 4k, 8k, 16k, and 32k. By default, all three tablespaces that are created as part of the database creation process are assigned a 4k page size. However, many DB2 UDB performance-testing scenarios use tablespaces and buffer pools that have been assigned an 8k page size. 7.2. Extent Size An extent is a unit of space within a container that makes up a tablespace. When a tablespace spans multiple containers, data associated with that tablespace is written to each of its respective containers in a round-robin fashion; the extent size of a tablespace represents the number of pages of table data that are to be written to one container before moving to the next container in the list. This helps balance data

Network Appliance Inc.

26

TECHNICAL REPORT

across all containers that belong to a given tablespace (assuming all extent sizes specified are equal). Figure 9 illustrates how extents are used to balance data across multiple containers.

Figure 9) Tablespace containers and extents

7.3. Prefetch Size Prefetching is a technique that the DB2 Database Manager uses to retrieve (fetch) pages of data that it thinks a user is about to need into one or more buffer pools before requests for the data are actually made. Thus, the prefetch size of a tablespace identifies the number of pages of table data that are to be read in advance of the pages currently being referenced by a query, in anticipation that they will be needed to resolve the query. The overall objective of sequential prefetching is to reduce query response timethis can be achieved if page prefetching can occur asynchronously to query execution. Sequential prefetches read consecutive pages into the buffer pool before they are needed. List prefetches however, are more complexin this case the DB2 optimizer attempts to optimize the retrieval of randomly located data. The amount of data being prefetched determines the amount of parallel I/O activity. Ordinarily the database administrator should define a prefetch value large enough to allow parallel use of all of the available containers, and therefore all of the physical devices used.

Network Appliance Inc.

27

TECHNICAL REPORT

7.4. Determining the Optimum Extent Size to Use Just as performance can usually be greatly improved by changing the default values provided for one or more configuration parameters, performance can often be improved by overriding the default extent and prefetch sizes provided when a tablespace is created. (By default, all tablespaces are created with an extent size and prefetch size of 32 pages.) Instead of using the default values provided, you can quickly determine the best extent and prefetch size to use for a tablespace for a given system configuration by solving the following equation: Number of data disks used by the tablespace * 4096 (bytes) Min Extent Size = ----------------------------------------------------------_ Tablespace Page Size (in bytes)

524288 (bytes) Max Extent Size = ---------------------------------------------------------Tablespace Page Size (in bytes)

The optimum extent size to use should be a value that is somewhere between the minimum extent size and the maximum extent size calculated. It is important to remember that more is not necessarily better. Ideally you should find the optimum extent size to use by starting with the minimum extent size calculated and working your way up to the maximum extent size calculated, running performance tests, and evaluating the results with each setting used. 7.5. Determining the Optimum Prefetch Size to Use Once you have decided on an extent size to use, the prefetch size to use can be determined by solving the following equation: Min Prefetch Size = (Extent Size * Number Of Containers Used) * Factor where: Factor is some constant number, usually 3. Unlike with extent sizes, with prefetch sizes in most cases more is usually better. Note: Prefetch sizes can be changed after a tablespace has been created; however, extent sizes cannot. Therefore, it is important that the appropriate extent size for a production tablespace be determined before data is written to a tablespaceas long as a tablespace is empty, it can easily be dropped and recreated, which is the only way the extent size for a tablespace can be changed. 7.6. An Example Extent and Prefetch Size Calculation Using the formulas just discussed, if you want to create a tablespace that uses 8k pages, has 2 containers, and spans 12 data disks on a Network Appliance filer, the starting extent size and prefetch size to use could be calculated as follows: Min Extent Size = (12 * 4096) / 8192 = 49152 / 8192 = 6

Network Appliance Inc.

28

TECHNICAL REPORT

Max Extent Size = Min Prefetch Size

524288 / 8192 =

= =

64 12 * 3 = 36

(6 * 2) * 3

Based on the information provided, the tablespace specified should be created initially with an extent size of 6 and a prefetch size of 36. Testing should then be done to verify whether or not these are the optimum settings to use. 7.7. Splitting Data across Multiple Tablespaces If you look closely at how most data is stored in a DB2 UDB database, you will find that it is stored as three distinct and separate objects: regular user data is stored as a data object, index data associated with indexes that have been defined on the table is stored as an index object, and long field data is stored as a long field object. (Long field objects only exist if the table contains one or more long data columns LONG VARCHAR, LONG VARGRAPHIC, BLOB, CLOB, and/or DBCLOB.) Each of these objects is stored separately and each can be stored in its own individual tablespaceprovided DMS tablespaces are used. By default, all three objects are stored in the same tablespace; however, performance can often be improved by storing regular data in one tablespace, corresponding index data in a second tablespace, and long data in another tablespace. 7.8. A Word about db2empfa Because the file system, rather than the DB2 Database Manager, manages SMS tablespaces, the file system is responsible for the allocation of additional storage space as it is needed. By default, SMS tablespaces are expanded one page at a time. However, in certain workloads (for example, when performing a bulk insert operation) it might be desirable to have storage space allocated in extents rather than pages. This is where the db2empfa utility comes in. When the db2empfa utility is run, the multipage_alloc database configuration parameter (which is a read-only configuration parameter) is set to YES, which in turn, causes DB2 UDB to expand SMS tablespaces one extent at a time, rather than one page at a time. The db2empfa utility can be found in the bin subdirectory of the sqllib directory in which the DB2 UDB product was installed. 8. System Catalog Statistics and Performance Whenever a database is created, a special set of tables, known as the system catalog tables, is constructed and initialized as part of the creation process. The DB2 Database Manager uses the system catalog tables of a database to keep track of the following information: Table/index definitions Column data types Defined constraints Object dependencies Object privileges

A set of system catalog views is created along with the system catalog tables and these views are typically used to access the data stored in the system catalog tables. The system catalog views are designed to use a more consistent naming convention than their underlying system catalog tables and most are read-only. Thus, insert, update, and delete operations cannot be performed against the majority

Network Appliance Inc.

29

TECHNICAL REPORT

of the system catalog views. Instead, the contents of one or more system catalog tables that the system catalog views reference are modified by the DB2 Database Manager each time: A new object (such as a table or index) is created Authorizations/privileges are granted or revoked Statistical information is collected for a table Packages are bound to the database

8.1. The Run Statistics Utility Whenever an SQL statement is sent to the DB2 Database Manager for processing, the DB2 Optimizer reads the system catalog tables to determine, among other things, the size of each table referenced by the statement, the characteristics of the columns that are referenced by the statement, and whether or not indexes have been defined for the table(s) that are referenced by the statement. Using this information, the DB2 Optimizer estimates the costs of each data access path that could be used to satisfy the needs of the SQL statement and recommends the best access path to take. A key element in the system catalog tables the DB2 Optimizer uses is the set of statistics that have been gathered about the data contained in the databasechanges in the statistics can result in a change in the access path chosen. Thus, if the information needed by the DB2 Optimizer is missing or out-of-date, the optimizer may choose an access plan that will cause the SQL statement to take longer to execute than is necessary. Having valid information available becomes more crucial as the complexity of the SQL statement increases; when only one table (that has no indexes defined for it) is referenced, there are only a limited number of choices available to the DB2 Optimizer. However, when several tables (each of which has one or more indexes defined) are referenced, the number of choices available to the DB2 Optimizer increases dramatically. Unfortunately, this statistical information is not automatically kept up-to-date. Instead, it has to be generated periodically by running the Run Statistics (RUNSTATS) utility. The Run Statistics utility can be invoked by executing the RUNSTATS command, either from the DB2 Command Center or from the DB2 Command Line Processor. The syntax for this command is: RUNSTATS ON TABLE [TableName] <WITH DISTRIBUTION | WITH DISTRIBUTION AND <DETAILED> INDEXES ALL | WITH DISTRIBUTION AND <DETAILED> INDEX [IndexName]> <SHRLEVEL [CHANGE | REFERENCE]> or RUNSTATS ON TABLE [TableName] <[AND | FOR] <DETAILED> INDEXES ALL | [AND | FOR] <DETAILED> INDEX [IndexName]> <SHRLEVEL [CHANGE | REFERENCE]> where: TableName IndexName Identifies the name of the table that statistical information will be collected and updated for. Identifies the name of the index that statistical information will be collected and updated for.

For example, when executed, the following command will update the statistical information stored in the system catalog tables for the table named DEFAULT.EMPLOYEE:

Network Appliance Inc.

30

TECHNICAL REPORT

RUNSTATS ON TABLE DEFAULT.EMPLOYEE WITH DISTRIBUTION AND INDEXES ALL SHRLEVEL CHANGE It is important to note that the Run Statistics utility does not produce output information. However, its results can be seen by querying the CARD, OVERFLOW, NPAGES, and FPAGES columns of the system catalog table SYSCAT.TABLES. (If the values of these columns are set to -1, statistical information has not been produced for the object identified by that particular row.) 8.2. When to Use the Run Statistics Utility So just how often should the statistics for a table be collected? Ideally, the Run Statistics utility should be used to update the statistics for tables as soon as possible after any of the following events occur: A large number of insert, update, or delete operations have been performed against a table An import operation is performed against a table A load operation is performed against a table One or more columns are added to an existing table A new index is created for a table A table has been reorganized

It is important to note that whenever statistics for a table are collected/updated, all packages that reference the table should be rebound so the DB2 Optimizer can evaluate the new statistics to produce access plans for the SQL statements they contain. Failure to rebind packages can result in dynamic SQL operations that perform faster than static SQL operations, where the opposite should hold true.

9. Conclusion DB2 Universal Database is a complex relational database management system and tuning a DB2 UDB system for optimum performance can be a lengthy process. At a minimum, the Configuration Performance Wizard or an application that calls the db2AutoConfig() API should be used to roughtune any database that uses the default configuration. Once such a rough-tune has been performed, tuning can continue by adjusting the DB2 Database Manager instance and database configuration parameters that have the highest impact on performance. Specific registry/environment variables can also be set to enhance overall performance. And finally, choosing the proper tablespace type, extent size, and prefetch size as well as keeping system catalog statistics up-to-date round out the basics of database-level performance tuning. Tuning the database level of any system is only one piece of the system tuning processthe hardware, operating system, communications software, SQL statements, and applications used must also be tuned in order to achieve optimum performance.

Network Appliance Inc.

31

TECHNICAL REPORT

10. References Roger E. Sanders, All-in-One DB2 Administration, McGraw-Hill/Osborne, 2002, ISBN 0-07-213375-9 June Gu & others, DB2 UDB Exploitation of NAS Technology, IBM Redbooks, 2002, ISBN 0-7384-2522-2

Network Appliance, Inc. 2002 Network Appliance, Inc. All rights reserved. Specifications subject to change without notice. NetApp, the Network Appliance logo, SnapMirror, and SnapRestore are registered trademarks and Network Appliance, Snapshot, andThe evolution of storage are trademarks of Network Appliance, Inc. , in the U.S. and other countries. UNIX is a registered trademark of The Open Group. Linux is a registered trademark of Linus Torvalds. Windows is a registered trademark of Microsoft Corporation. Java is a trademark of Sun Microsystems, Inc. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.

Network Appliance Inc.

32