db2 udb performance tuning guidelines

Network Appliance Inc.

1

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

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 UDB’s minimum hardware requirements. This document provides a set of guidelines that can be used to modify DB2 UDB’s basic configuration in such a way that overall database performance will be improved.

TECHNICAL REPORT

Netw

ork Appliance, a pioneer and

industry leader in data storage technology, helps organizations understand and m

eet com

plex technical challenges with

advanced storage solutions and global data m

anagement strategies.


2

TECHNICAL REPORT

Table of Contents

1. List of Figures and Tables 3

2. An Overview of Performance Tuning and the Purpose of this Technical Report 4

3. DB2 Universal Database Concepts (Performance-Related) 5

3.1. Instances 5

3.2. Databases 6

3.3. Buffer Pools 6

3.3.1. A Word about I/O Page Cleaners 6

3.4. Tablespaces 8

3.4.1. System-Managed Space (SMS) Tablespaces 8

3.4.2. Database-Managed Space (DMS) Tablespaces 8

3.4.3. Containers 9

4. Configuring DB2 Instances and Databases 10

4.1. The DB2 Database Manager Instance Configuration 10

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

4.2. The DB2 Database Configuration 14

4.2.1. Viewing/Changing the Value of a DB2 Database Configuration Parameter 15

4.3. The Configure Performance Wizard 17

4.4. The db2AutoConfig() Application Programming Interface (API) 18

5. Registry and Environment Variables 19

5.1. Viewing/Changing the Value of a DB2 Registry/Environment Variable 22

6. Buffer Pools and Performance 24

7. Tablespaces and Performance 25

7.1. Page Size 25

7.2. Extent Size 25

7.3. Prefetch Size 26


3

TECHNICAL REPORT

7.4. Determining the Optimum Extent Size to Use 26

7.5. Determining the Optimum Prefetch Size to Use 27

7.6. An Example Extent and Prefetch Size Calculation 27

7.7. Splitting Data across Multiple Tablespaces 28

7.8. A Word about db2empfa 28

8. System Catalog Statistics and Performance 28

8.1. The Run Statistics Utility 29

8.2. When to Use the Run Statistics Utility 30

9. Conclusion 31

10. References 32


4

TECHNICAL REPORT

1. List of Figures and Tables Figure 1 – DB2’s hierarchic relationship among systems, instances, and databases.

Figure 2 – Relationship between buffer pools, tablespaces, and databases.

Figure 3 – Invoking the Configure Instance dialog from DB2’s Control Center.

Figure 4 – The Configure Instance dialog.

Figure 5 – Invoking the Configure Database dialog from DB2’s Control Center.

Figure 6 – The Configure Database dialog.

Figure 7 – Invoking the Configure Performance Wizard from DB2’s 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


5

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 can’t 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 time–even 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.


6

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 report—the 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.)


7

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 DB2’s 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.


8

TECHNICAL REPORT

Figure 1) DB2’s 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, you’ll 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.


9

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 tablespaces—tablespaces 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 system’s 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 system’s 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 special-purpose 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.


10

TECHNICAL REPORT

Additional differences between SMS tablespaces and DMS tablespaces can be seen in Table 1.

Characteristics SMS Tablespaces DMS Tablespaces

The number of storage locations (containers) used can be increased after the tablespace has been created

No Yes

Each storage location (container) used must be the same size Yes No

Storage location (container) size can be changed after the tablespace has been created

No Yes

Index data for a table can be stored in a separate tablespace No Yes

Long data for a table can be stored in a separate tablespace No Yes

A single table can span multiple tablespaces No Yes

Storage space is only allocated when it is needed Yes No

Tablespace can span multiple disks Yes Yes

Extent size can be changed after tablespace has been created No No

Prefetch size can be changed after tablespace has been created Yes Yes

A single tablespace cannot have more than 16,777,215 pages No Yes

Table 1) Characteristics of SMS and DMS tablespaces

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.


11

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 application’s 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


12

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 Value Range / Default Description

agentpri 41 – 125 4k Pages 41 – 128 4k Pages 0 – 6 4k Pages

Default: -1

Specifies the execution priority that will be assigned to DB2 Database Manager processes and threads on a particular workstation.

aslheapsz 1 – 524,288 4k Pages

Default: 15

Specifies the size (in pages) of the memory shared between a local client application and a DB2 Database Manager agent.

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.

fcm_num_anchors

-1, 128 – fcm_num_rqb

Default: -1

Specifies the number of Fast Communications Manager (FCM) message anchors used. Agents use the message anchors to send messages among themselves.

fcm_num_buffers

128 – fcm_num_rqb 4k Buffers

Default: 512, 1024, or 4096

Specifies the number of 4k buffers that are used for internal communications (messages) among the nodes in an instance.

fcm_num_connect

-1, 128 – fcm_num_rqb

Default: -1

Specifies the number of FCM connection entries available. Agents use connection entries to pass data among themselves.

fcm_num_rqb 128 – 120,000 250 – 2,097,152

Default: 256, 512, 2048 or 10,000

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.

intra_parallel SYSTEM, YES, NO

Default: NO

Specifies whether or not the DB2 Database Manager instance can use intrapartition parallelism.

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.

max_querydegree

ANY, 1 – 32 767

Default: ANY

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


13

TECHNICAL REPORT

single node.

num_poolagents -1, 0 – maxagents

Default: -1

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

Rqrioblk 4096 – 65,535 Bytes

Default: 32,767

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

sheapthres 250 – 2,097,152 4k Pages

Default: 10,000 or 20,000

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

Table 2) DB2 Database Manager instance configuration parameters that can impact performance

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 DB2’s Control Center (Version 7.x)

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


14

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)


15

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 Identifies the DB2 Database Manager configuration parameter (by keyword) whose value is to be modified.

Value 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 Value Range (Default) Description

avg_appls 1 – maxappls

Default: 1

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.

buffpage 2 – 524,288 4k Pages

Default: 250 or 1000

Specifies the size (in pages) of the buffer pool that is used to store and manipulate data read from the database.

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.

dft_degree -1, 1 – 32,767

Default: 1

Specifies the default value for the CURRENT DEGREE special register and the DEGREE bind option.

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.


16

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.

num_iocleaners 0 – 255

Default: 1

Specifies the number of asynchronous page cleaners that are used by a database.

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.

pckcachesz -1, 32 – 64,000 4kPages

Default: -1

Specifies the amount of application heap memory that will be used for caching packages.

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.


17

TECHNICAL REPORT

Figure 5) Invoking the configure database dialog from DB2’s 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 Identifies the database (by its alias) that configuration parameter values are to be obtained for.

Parameter Identifies the DB2 Database Manager configuration parameter (by keyword) whose value is to be modified.

Value Identifies the new value that is to be assigned to the DB2 Database Manager configuration parameter specified.


18

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 UDB’s 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,


19

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 DB2’s 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.


20

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)

Description Platform

DB2_AVOID_PREFETCH ON, OFF

Default: OFF

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

All

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


21

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.

Windows

DB2CHKPTR ON, OFF

Default: OFF

Specifies whether or not pointer checking for input is to be performed.

All

DB2_DARI_LOOKUP_ALL ON, OFF

Default: OFF

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.

All

DB2_EXTENDED_OPTIMIZATION ON, OFF

Default: OFF

Specifies whether or not the query optimizer will use optimization extensions to improve query performance.

All

DB2MEMDISCLAIM YES, NO

Default: Null

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.

AIX

DB2MEMMAXFREE 4,000,000 – 256,000,000 bytes

Default: Null

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.)

AIX

DB2_MMAP_READ 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.

AIX

DB2_MMAP_WRITE ON, OFF

Default: OFF

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.

AIX

DB2_NO_PKG_LOCK ON, OFF

Default: OFF

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

All


22

TECHNICAL REPORT

may choose to work in a “no package lock” mode.

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

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.

Windows

DB2NTPRICLASS R, H, (any other value)

Default: Null

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)

Windows

DB2NTWORKSET Positive number, Positive number

Default: 1,1

Specifies the minimum and maximum working set size available to DB2. By default, when Windows NT is not in a paging situation; a process’s 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.

Windows

DB2_OVERRIDE_BPF A positive number of 4k pages

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.

All

DB2PRIORITIES Values are platform-dependent

Controls the priorities of DB2 processes and threads. All


23

TECHNICAL REPORT

DB2_RR_TO_RS 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.

All

DB2_SORT_AFTER_TQ YES, NO

Default: NO

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.

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=*

*, Null

Default: Null

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

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

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.

All

DB2_HASH_JOIN YES, NO

Default: NO

Specifies whether or not a hash join is a possible join method to use when compiling a data access plan.

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>>


24

TECHNICAL REPORT

<-all> <-null> <-r [Instance] <NodeNumber>> <-n [DASNode] <-u [UserID] <-p [Password]>>> <-l | -lr> <-v> <-ul | -ur> <-h | -?>

where:

Variable Identifies the registry or environment variable whose value will be displayed, set, or removed.

Value 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.

Instance Identifies the instance profile that the registry or environment variable specified is associated with.

NodeNumber Identifies a specific node that is listed in the file db2nodes.cfg.

DASNode Identifies the name of the node where the remote DB2 Administration Server instance resides.

UserID Identifies the authentication ID that will be used to attach to the DB2 Administration Server instance.

Password Identifies the password (for the authentication ID) that will be used to attach to the DB2 Administration Server instance.

Table 5 describes the other options shown with this command.

Command Option Description

-g Indicates that a global profile variable will be displayed, set, or removed.

-i Indicates that an instance profile variable will be displayed, set, or removed.

-all 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]

-null 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.)

-r Indicates that the profile registry for the given instance is reset.

-n Indicates that a remote DB2 Administration Server instance node name is specified.

-u Indicates that an authentication ID that will be used to attach to the DB2 Administration Server instance is specified.

-p Indicates that a password for the authentication ID specified is provided.

-l Indicates that all instance profiles will be listed.

-lr Indicates that all registry variables supported will be listed.


25

TECHNICAL REPORT

-v Indicates that verbose mode will be used.

-ul Indicates that user profile variables will be accessed. (Only valid on Windows operating systems.)

-ur Indicates that user profile variables will be refreshed. (Only valid on Windows operating systems.)

-h or -? 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 operations—data 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


26

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


27

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 time—this 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 complex—in 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.


28

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 tablespace—as 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


29

TECHNICAL REPORT

Max Extent Size = 524288 / 8192 = 64 Min Prefetch Size = (6 * 2) * 3 = 12 * 3 = 36 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 tablespace—provided 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


30

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 database—changes 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 Identifies the name of the table that statistical information will be collected and updated for.

IndexName 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:


31

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 rough-tune 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 process—the hardware, operating system, communications software, SQL statements, and applications used must also be tuned in order to achieve optimum performance.


32

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.

db2 udb performance tuning guidelines

Documents

db2 universal database

db2 instances

overall database performance

database dialog

optimum performance

performance wizard

db2 udb network appliance

db2 udbs basic configuration