db2 v8.1 for linux, unix, and windows database ......db2 v8.1 for linux, unix, and windows database...

DB2 V8.1 for Linux, UNIX, and Windows DatabaseAdministration Certification: Monitoring DB2 activityGet ready for the exam

Skill Level: Introductory

Drew Bradstock ([email protected])DB2 ConsultantIBM

20 May 2003

This tutorial will cover the different options a DBA has for tuning and configuring theirDB2 environments. This is the fourth tutorial in a series of six that you can use to helpprepare for the DB2 V8.1 for Linux, UNIX, and Windows Database AdministrationCertification (Exam 701).

Section 1. Introduction

What this tutorial is about

Tuning and configuring a DB2® database can be a complex process that sometimesoverwhelms new DBAs. There are, however, a great number of tools, functions, andapplications included with DB2 that make this task much simpler. The release ofDB2 V8.1 includes new tools and information and improves the usability of existingperformance resources.

This tutorial has been designed to assist you with your studying for the DB2 V8.1 forLinux, UNIX®, and Windows™ Database Administration exam (#701). It focuses onPart 4 of the exam, entitled "Monitoring DB2 Activity." The tutorial will cover thedifferent options a DBA has for tuning and monitoring their DB2 environments. It isbroken down into a series of sections with each focussing on what information orconfigurations are available. At the beginning of every section is a list of objectivesthat you should achieve before you move on to the next section.

All references to DB2 in this tutorial refer to DB2 UDB V8.1 for Linux, UNIX, and

Monitoring DB2 activity© Copyright IBM Corporation 1994, 2007. All rights reserved. of 58

mailto:[email protected]

http://www.ibm.com/legal/copytrade.shtml

Windows, and do not apply to other platforms.

Who should use this tutorial

You should take this tutorial if you want to learn more about measuring and tuningthe performance of DB2.

This tutorial has been written for DB2 database administrators who have a basicunderstanding of DB2. It will also be useful for developers who want to be able tounderstand introductory performance and monitoring information for DB2. Bothgroups of individuals should have a good knowledge of SQL.

Software requirements

To complete the steps in this tutorial, you will need to have a version of DB2 UDBV8.1 installed on a system. Many of the tools and functions described in the tutorialare new to V8.1, so DB2 V7.1 or V7.2 cannot be used.

You can download a free trial version of DB2 Universal Database™ from thedeveloperWorks downloads page.

The SAMPLE database should also be created. An application called db2sampl canbe found in the DB2 home directory db2HomeDirectory/bin. Running thisapplication will create the database SAMPLE and populate it with base data.

Documentation

Throughout the tutorial there are references to documentation in Adobe AcrobatPDF format. You can download the documentation separately from the PersonalEdition. This documentation can also be downloaded as a series of HTML files.Check out the Resources to see where the different DB2 documents can be found inthe PDF files.

Section 2. Capturing snapshots

What are snapshots?

DB2 snapshots are point-in-time views into what DB2 is doing and how it isperforming. They are used in the performance tuning of instances, databases, andapplications running on DB2. The information returned from a snapshot is acombination of cumulative information and data that applies only to a single moment.

developerWorks® ibm.com/developerWorks

Monitoring DB2 activity of 58 © Copyright IBM Corporation 1994, 2007. All rights reserved.

http://www-128.ibm.com/developerworks/downloads/

http://www-306.ibm.com/software/data/db2/udb/support/manualsv8.html


So why should I use them?

Snapshots are the only method you have to view a large amount of the behavior ofDB2. There are tools built into V8.1 that allow you to track the memory usage of theinstances and databases. These tools often do not give you information that isdetailed enough. Snapshots are actually used by all the third-party analysis toolsthat run on DB2. The tools are simply constantly taking snapshots and parsing thedata into an easily viewed format.

What types of snapshots are there?

Each type of snapshot captures a different set of data about DB2.

• Database

• Table space

• Tables

• Buffer pools

• Locks

• Database Manager

• Applications

These are covered in detail later in this section.

Objectives for this section:

1. Understand what snapshots are

2. Learn how to take a snapshot

3. Know what types of snapshots are available

4. Understand when to take which type of snapshot

5. Practice working with snapshot information

How are snapshots taken?

A snapshot can be taken by using an API call in a program or from the commandline.

API call

Snapshot information can be returned from a function call in a program. Thisinformation can then be parsed and used by an application. The syntax for all theAPI snapshot calls is beyond the scope of this tutorial. Further information on the

ibm.com/developerWorks developerWorks®



API calls can be found in the DB2 System Monitor Guide and Reference. Chapter 3,entitled "Using the snapshot monitor," has a section entitled "Snapshot Monitor APIrequest types" that has all the information you should need.

Command line

Normally, the snapshot data is called from the command line and dumped into a textfile for future analysis. Often, people will write scripts to take snapshots on regularintervals to observe the behavior of a database, or to assist in performance tuning.

Here's the command syntax:

Let's look at some example snapshot commands to see how this syntax works.Here's a command for a database snapshot:

db2 get snapshot for database on drew_db




Here's a command for a dynamic SQL snapshot, redirected to a file:

db2 get snapshot for dynamic sql on drew_db > dynSnap.drew_db

Here's a command for an application snapshot for all applications:

db2 get snapshot for all applications

Note: This snapshot will be taken on all applications currently connected to theinstance and not just those for a particular database even if you are currentlyconnected to one.

Here's a command for a buffer pool snapshot on the fourth node in a partitioneddatabase:

db2 get snapshot for bufferpools on drew_db at dbpartitionnum 3

Note: The dbpartitionnum field is used to specify the partition at which thesnapshot should be taken. Even if you have connected to a partition other than 0,the snapshot will still be taken for the 0 node unless otherwise specified.

What memory is used?

The MON_HEAP_SZ variable in the database configuration specifies how muchmemory is set aside for the snapshots and event monitors.

Turning snapshots on and off

The monitoring of DB2 is not turned on by default, but instead has to be set at theconnection or instance level. There are a series of monitor switches that determine ifa type of data element is monitored. There is also a memory heap set aside forcontaining the information stored for monitoring.

Method 1: Setting monitor switches at the instance level

Setting the monitor switches at the instance level will affect all users connected toany databases in that instance.

Here are the monitor switches

• DFT_MON_STMT: Statement monitor (used for dynamic SQL)

• DFT_MON_TABLE: Table monitors

• DFT_MON_LOCK: Lock monitor




• DFT_MON_BUFPOOL: Buffer pool monitors

• DFT_MON_SORT: Sort monitoring

• DFT_MON_UOW: Unit of work information

• DFT_MON_TIMESTAMP: Tracks timestamp information

The values of these switches are stored in the database manager configurationinformation. Here are the database manager configuration parameters:

The monitor switches are set just like any other instance configuration parameter:

db2 update dbm cfg using monitorSwitch [ON | OFF]

Here's an example:

db2 update dbm cfg using DFT_MON_SORT ON

Method 2: Setting the monitor switches at an application level

The monitor switches can also be set at an application level; setting the switches inthis way will only apply to a particular application. If you use the method listed belowat a command prompt or Command Window, then the changes will only beapplicable to that particular prompt window.

Here are the switch names:

• Bufferpool

• Lock

• Sort

• Statement

• Table

• Timestamp

• UOW




Use this command to list the switches:

db2 get monitor switches

And use this command to set the switches:

db2 update monitor switches using switchName [ON | OFF]

Here's a comparison of the scope of the changes of the switches:

Note: You may have noticed that the syntax of setting the monitor switches is verysimilar to that for setting the instance and database parameters. The vast majority ofthe configuration commands have identical syntax, with the only difference being theparameters.

Scope of the snapshots




It is important to understand what information is being returned to you with thesnapshots and when the monitoring begins. The switches can be set dynamically atboth instance and application levels, and both affect the monitoring of connectionsdifferently.

If the monitor switches are turned on after an application has already connected,then the information will only be captured for all actions after the switch has beenturned on, as the following diagram illustrates:

In this example, Application A has already connected to the database before themonitor switches are turned on. When the first snapshot, Snap1, is taken, noinformation will be returned by the database, as the monitor switches have not beenturned on. When the second snapshot, Snap2, is taken, information on bothApplication A and Application B will be captured.

Resetting the switches

The monitor switches can be reset to null or 0 for all values by executing thefollowing command:

db2 reset monitor [ALL | for database databaseName] [at dbpartitionnum partitionNum]

Where databaseName is the name of the database and partitionNum is thenode number.

Here's an example:

db2 reset monitor for database drew_db

Database snapshots

The snapshots have been broken up into separate topics but there is still a fair




amount of information that is repeated in each. The most commonly used snapshotsare the database and dynamic SQL snapshots. (For more on the latter, see DynamicSQL snapshots.)

The database snapshot captures summary information about the database. Theinformation in this snapshot contains an aggregate of almost all the data in all theother snapshots. The snapshot's data is a summary since the monitor switches havelast been reset.

This is the most frequently used snapshot, and most performance problems areobvious from the information in this snapshot. The database snapshot containsinformation on:

• Connections

• DB2 agents

• Locks

• Sorting

• Total buffer pool activity

• SQL activity

• SQL statement volume

• Log usage

• Cache usage

• Hash joins

Here's the command for this type of snapshot

db2 get snapshot for database on databaseName

And here's some typical output:

Connection InformationHigh water mark for connections = 1Application connects = 1Secondary connects total = 0Applications connected currently = 1

DB2 AgentsAppls. executing in db manager currently = 0Agents associated with applications = 1Maximum agents associated with applications = 1Maximum coordinating agents = 1

LocksLocks held currently = 0Lock waits = Not CollectedTime database waited on locks (ms) = Not CollectedLock list memory in use (Bytes) = 792Deadlocks detected = 0Lock escalations = 0




Exclusive lock escalations = 0Agents currently waiting on locks = 0Lock Timeouts = 0

SortingTotal Private Sort heap allocated = 0Total Shared Sort heap allocated = 0Shared Sort heap high water mark = 0Total sorts = 0Total sort time (ms) = 0Sort overflows = 0Active sorts = 0

Total Bufferpool ActivityBuffer pool data logical reads = 25Buffer pool data physical reads = 8Asynchronous pool data page reads = 0Buffer pool data writes = 0Asynchronous pool data page writes = 0Buffer pool index logical reads = 43Buffer pool index physical reads = 23Asynchronous pool index page reads = 0Buffer pool index writes = 0Asynchronous pool index page writes = 0Total buffer pool read time (ms) = 162Total buffer pool write time (ms) = 0

SQL ActivityCommit statements attempted = 0Rollback statements attempted = 0Dynamic statements attempted = 0Static statements attempted = 0Failed statement operations = 0Select SQL statements executed = 0Update/Insert/Delete statements executed = 0DDL statements executed = 0

SQL statement volumeRows deleted = 0Rows inserted = 0Rows updated = 0Rows selected = 0Rows read = 9

Log UsageLog space available to the database (Bytes) = 7140000Log space used by the database (Bytes) = 0Maximum secondary log space used (Bytes) = 0Maximum total log space used (Bytes) = 0Secondary logs allocated currently = 0Log pages read = 0Log pages written = 0

Cache UsagePackage cache lookups = 0Package cache inserts = 0Package cache overflows = 0Package cache high water mark (Bytes) = 118968Application section lookups = 0Application section inserts = 0Catalog cache lookups = 2Catalog cache inserts = 2Catalog cache overflows = 0Catalog cache high water mark = 0

Hash JoinsNumber of hash joins = 0Number of hash loops = 0Number of hash join overflows = 0Number of small hash join overflows = 0

Database manager snapshots




The database manager snapshot captures information specific to the instance level.The information centers on the total amount of memory allocated to the instance andthe number of agents that are currently active on the system.

Here's the command for this type of snapshot:

db2 get snapshot for database manager

A partial list of the fields available is included in this sample output:

Agent InfoHigh water mark for agents registered = 6High water mark for agents waiting for a token = 0Agents registered = 6Agents waiting for a token = 0Idle agents = 5

Sort InformationPrivate Sort heap allocated = 0Private Sort heap high water mark = 256Post threshold sorts = 0Piped sorts requested = 6Piped sorts accepted = 6

Table snapshots

The table snapshot contains information on the usage and creation of all tables. Thisinformation is quite useful in determining how much work is being run against a tableand how much the table data changes. This information can then be used to decidehow your data should be physically laid out.

Here's the command for this type of snapshot

db2 get snapshot for tables on drew_db

And here's some typical table snapshot output:

Table ListTable Schema = DREWKBTable Name = SYSITable Type = UserRows Read = 3Rows Written = 0Overflows = 0Page Reorgs = 0

Table space and buffer pool snapshots

The table space and buffer pool snapshots contain similar information. The table




space snapshot returns information on the layout of the table space and how muchspace is being used. The buffer pool snapshots contains information on how muchspace is currently allocated for the buffer pool and how much space will be allocatedwhen the database is next reset. Both snapshots contain a summary of the way inwhich data is accessed from the database. This access could be done from a bufferpool, direct from tables on disk, or through a direct read or write for LOBs or LONGobjects.

Here's the commands for these types of snapshots:

db2 get snapshot for tablespaces on drew_dbdb2 get snapshot for bufferpools on drew_db

And here's some typical output:

Tablespace InformationTablespace name = STORAGE1Tablespace ID = 3Tablespace Type = System managed spaceTablespace Content Type = Any dataTablespace Page size (bytes) = 4096Tablespace Extent size (pages) = 8Tablespace Prefetch size (pages) = 8Buffer pool ID currently in use = 1Buffer pool ID next startup = 1Tablespace State = 0x'00000000'Detailed explanation:

NormalTotal number of pages = 159Number of usable pages = 159Number of used pages = 159Minimum Recovery Time =Number of quiescers = 0Number of containers = 1

Bufferpool InformationNode number = 0Tablespaces using bufferpool = 4Alter bufferpool information:Pages left to remove = 0Current size = 250Post-alter size = 250

Common InformationThe common information given on data usage is very complex and is not requiredunless advanced performance tuning is being performed.Buffer pool data logical reads = 39Buffer pool data physical reads = 14Buffer pool data writes = 0Buffer pool index logical reads = 63Buffer pool index physical reads = 37

This information can be used to determine the buffer pool hit ratio, as illustrated inthe figure below:




The ratio indicates how often the data is found in the buffer pools instead of havingto be read a table saved on disk.

Lock snapshot

The lock snapshot is very useful in determining what locks an application currently isholding or what locks another application is waiting on. The snapshot lists allapplications on the system and the locks that each is holding. Each lock is given anunique identifier number, as are the applications.

Here's the command for this type of snapshot:

db2 get snapshot for locks on drew_db

And here's a sample of the lock snapshot output:

Application InformationApplication handle = 26Application ID = *LOCAL.DB2.00B807181746Sequence number = 0006Application name = db2bp.exeAuthorization ID = DREWKBApplication status = UOW WaitingStatus change time = 03-28-2003 00:39:57.259727Application code page = 1252Locks held = 2Total wait time (ms) = 125

Lock InformationLock Name = 0x02000200000000000000000054Lock Attributes = 0x00000000Release Flags = 0x00000001Lock Count = 1Hold Count = 0Lock Object Name = 2Object Type = TableTablespace Name = USERSPACE1Table Schema = DREWKBTable Name = LOCKTABMode = S

Dynamic SQL snapshots

The dynamic SQL snapshot is used extensively to determine how well SQLstatements are performing. This snapshot summarizes the behavior of the differentdynamic SQL statements that are run. The snapshot does not capture static SQLstatements, so anything that was prebound will not show up in this list.

The snapshot is an aggregate of the information concerning the SQL statements. If aSQL statement is executed 102 times, then there will be one entry with the summaryof the total behavior of the 102 executions. If even a single letter is different, therewill be more than one entry.




For example, for these two commands:

SQL 1: SELECT * FROM dynTab WHERE name = 'a'SQL 1: SELECT * FROM dynTab WHERE name = 'A'

There will be two entries in the dynamic SQL snapshot.

For these two commands:

SQL 1: SELECT * FROM dynTab WHERE name = ?SQL 1: SELECT * FROM dynTab WHERE name = ?

Even if the statement is executed with a different value of the parameter marker ?,there will still be only one entry, because the SQL statement was identical. In thisexample there will only be one entry in the snapshot for the statement.

Here's some sample SQL snapshot object information:

Number of executions = 3Number of compilations = 1Worst preparation time (ms) = 15Best preparation time (ms) = 15Internal rows deleted = 0Internal rows inserted = 0Rows read = 6Internal rows updated = 0Rows written = 0Statement sorts = 0Total execution time (sec.ms) = 0.038913Total user cpu time (sec.ms) = 0.000000Total system cpu time (sec.ms) = 0.000000Statement text = select * from locktab with RR

Note: Don't forget that these values are the total of all executions of the statement.

Using the SQL snapshot functions

Previously, the output from the snapshots could only be accessed using APIs orpassed into a text file using a command line. All of the different snapshots now havetable functions which contain all their fields. The table function takes the output fromthe snapshot and parses it into a table, which can then be accessed using SQL. Forsnapshots that do not contain multiple similar elements, such as the data from thedatabase snapshot, the table will only have one row. Snapshots with multiple similarobjects, such as the Dynamic SQL snapshot, will have one row for each object.

A detailed description of the Snapshot table functions can be found in the DB2 PDFdocument System Monitor Guide and Reference.

Here's an example:

SELECT *




FROM TABLE( SNAPSHOT_APPL( cast (NULL as VARCHAR), -1))as SNAPSHOT_APPL

Using dynamic SQL snapshots to find slow SQL

The example below illustrates a very useful technique for finding the SQL statementthat is taking the most time in the database:

SELECT stmt_text, total_exec_time, num_executionsFROM TABLE( SNAPSHOT_DYN_SQL('DREW_DB', -1)) as dynSnapTabORDER BY total_exec_time descFETCH FIRST 1 ROW ONLY

This second example finds the five SQL statements with the worst averageexecution time:

SELECT stmt_text,CASE WHEN num_executions = 0

THEN 0ELSE (total_exec_time / num_executions)

END avgExecTime,num_executions

FROM TABLE( SNAPSHOT_DYN_SQL('DREW_DB', -1)) as dynSnapTabORDER BY avgExecTime descFETCH FIRST 5 ROWS ONLY

Section 3. Capturing event monitor data

What are event monitors?

Snapshots are used to examine DB2 at one precise moment and aggregateperformance information. Event monitors, on the other hand, are used to monitor theperformance of DB2 over a fixed period of time. Event monitors examine transitionevents in the database and consider each event as an object. This allows a verydetailed analysis of DB2's behavior.

The information that can be captured by an event monitor is similar to the snapshots.Multiple monitors can be run at once and each monitor can also capture informationon more then one type of event. This allows different administrators to monitordifferent activities independent of one other.

The event monitors can capture information on:

• Databases




• Tables

• Deadlocks

• Table spaces

• Buffer pools

• Connections

• Statements

• Transactions

The information from the event monitors can be written to:

• SQL tables

• Files

• Pipes


1. Understand what event monitors are

2. Learn how to take an event monitor

3. Know what types of event monitors are available

4. Understand when to take which type of event monitor

5. Practice working with event monitor information

How are event monitors taken?

An event monitor first has to be created. Its information is then stored in the catalogtable so that it can be reused later. The syntax of the create event monitorcommand is outlined below. The syntax diagrams have been taken from the DB2documentation in the SQL Reference in the "Create Event Monitor" section ofChapter 5, "Statements" (see Resources).




The event monitor has a number of complex options. The key options are:

1. What will be monitored?

2. Where will the output go?

3. What conditions will be used?

Types of monitors

Each event monitor keeps track of a certain type of transition. The event types alsorecord their information at different times. A complete description of the eventmonitor properties can be found in the DB2 document System Monitor Guide andReference (see Resources).




• Database: An event of database information is recorded when the lastapplication disconnects from the database.

• Tables: All active table events will be recorded when the last applicationdisconnects from the database. An active table is one which has beenaltered or created since the database was activated. The monitorcaptures the number of rows read and written to the table.

• Deadlocks: A deadlock event is recorded immediately when a deadlockoccurs. This monitor also has an additional option, with details. Theoption will capture additional information, such as what SQL was beingexecuted when the deadlock occurred and what locks were held by theapplication that encountered the deadlock. The information captured bythe monitor focuses on the locks involved in the deadlock and theapplications that own them.

• Buffer pools: A buffer pool event is recorded when the last applicationdisconnects from the database. The information captured contains thetype and volume of use of the buffer pool, use of pre-fetchers and pagecleaners, and whether or not direct I/O was used.

• Table spaces: A table space event is recorded when the last applicationdisconnects from the database. This monitor captures the sameinformation as the buffer pool monitor, but the information is summarizedat a table space level.

• Connections: A connection event is recorded whenever an applicationdisconnects from the database.

• Transactions: A transaction event is recorded whenever a transactionfinishes. The event will be written out whenever a commit or rollbackoccurs. The monitor captures all of the individual statement data and alsoinformation about the transaction, such as its start and stop time.

Event monitor output

The event monitor output can be directed in three different ways:

1. Files. The event monitor output can be written out to one or more files.Two parameters control the amount of space used by the monitor. Oncethe space limit is reached, the event monitor will automatically flush allevents and stop itself. The default setting of both parameters is NONE,which indicates that there is no limit. The parameters are:

• MAXFILESIZE: Maximum size of the output file. This is measured in4 KB pages.

• MAXFILES: Maximum number of files that will be written to.

2. Pipes. The output can be written to a named pipe that you create. The




name of the pipe must be given, but it does not need to exist when theevent monitor is created. It must, however, exist when the event monitoris started.

3. Tables. The output is written out to one or more tables that exist in thedatabase. Each monitor element in the event monitor is mapped to a tableof the same name. The individual events are then inserted as rows. Acomplete description of all the tables and their columns can be found inthe SQL Reference , under the "Create Event Monitor" overview inChapter 5, "Statements" (see Resources).

Event conditions

The event monitors can be set to only record an event when certain conditions aremet. This is useful if you want to record information selectively. The WHERE clausecan be used to check the values of application IDs (APPL_ID), authorization ID(AUTH_ID), and application name (APPL_NAME). Equality predicates such as >, <,and = can be used in addition to LIKE and NOT LIKE. Multiple conditions can beused as well with AND and OR operators.

Here's an example:

WHERE APPL_NAME = 'javaw.exe'AND AUTH_ID LIKE '12%'OR APPL_NAME NOT LIKE 'db2bp%'

Turning monitors on and off

Event monitors can be turned on and off at any time. The event monitor statevalue represents whether or not the event monitor is running.

Here's the command to turn a monitor on or off:

db2 set event monitor eventMonitorName state [0|1]

The eventMonitorName is the name of the created event monitor. 0 will turn themonitor off and 1 will turn it on.

The current state of the monitor can be determined by using an SQL command. TheDB2 catalog tables also contain information about the created event monitors.

SQL command

The SQL function EVENT_MON_STATE returns the state of an event monitor basedon the specified name. Here's an example of this SQL command (the table used isan empty table commonly used as a placeholder):




SELECT EVENT_MON_STATE('drewTest) FROM SYSIBM.SYSDUMMY1

Catalog tables

There is a table, SYSIBM.SYSEVENTMONITORS, and a view on that table,SYSCAT.EVENTMONITORS, that contain information on the event monitors thathave been created. SQL queries can be run against these tables to determine thestate of the monitors:

SELECT evmonname, target_type, target,FROM syscat.eventmonitorswhere evmonname LIKE 'drew%'

The autostart options

The autostart option in the command to create an event monitor commandindicates that the event monitor is started automatically whenever the database isstarted.

Flushing the event monitors

Event monitor data can also be flushed to disk. This is useful if you would like torecord information such as database events that are only normally written when allconnections have been terminated. Here's an example command:

db2 flush event monitor eventMonitorName

Using event monitors

The event monitors should be used for the monitoring of very specific events or shortworkloads. They are designed to give you very specific information to allow you todiagnose a problem or behavior of your database or application. Unlike snapshots,event monitors have an extremely heavy impact on performance of DB2. This is dueto the amount of information that is written out for every single event object. Thestatement monitor has a heavy performance impact due to all the extra work thedatabase engine has to perform for each query: instead of being able to just executea query, the DB2 engine also has to write out all the characteristics and runtimeinformation for the query. This information has to written to a text file, which furtherslows things down.

Use the file size limits to control the amount of disk space that the event monitoroutput will take up. If you are monitoring a high-volume OLTP system, the output canquickly grow to hundreds of megabytes. Normally the event monitors are started andstopped using scripts so that you can compare the results based on the time theyran and not on the amount of time before the files filled up with event data. This willallow you to compares apples to apples to see if any changes you have made havefixed your problem.




Deadlock monitoring

One of the most common uses for the event monitors is to capture deadlockinformation. If a monitor is not used, it is almost impossible to determine exactlywhat locks and applications were involved in a deadlock, because when a deadlockoccurs, one of the applications involved is rolled back and all its locks are released.

The deadlock monitor traps information on all the applications and their locks. Theprecise SQL statement that caused the deadlock can now also be captured. Don'tforget that the application that DB2 labels as the cause of the deadlock is the lastapplication involved. The real cause of the deadlock may actually be a transactionthat was started much earlier by another application. Make sure you examine all thelocks and applications involved to determine what the problem is.

Here's an example deadlock monitor:

CREATE EVENT MONITOR DEADLOCK_DBFOR DEADLOCKSWRITE TO FILE 'deadlock_db'MAXFILES 1MAXFILESIZE NONEAUTOSTART

The deadlock event monitor does not write out a lot of data and occurs sporadically,so it is acceptable to not have a file size limit. The command above will create anevent monitor, DEADLOCK_DB, that will start whenever the database is started andwrite its information out to a file.

SQL monitoring

The second most commonly used purpose for an event monitor is to keep track ofSQL statements. The SQL monitor is quite useful because it traps both dynamic andstatic SQL statements. This is essential if an application makes use of precompiledSQL statements that would not be captured using a SQL snapshot.

An event is recorded for every SQL statement that is executed. The properties ofeach statement, such as the number of rows read, selected, deleted, etc., isrecorded, and is not presented as an aggregate total as it is in a snapshot. Theexecution timeframe and start and stop times are recorded as well. This allowsdetailed analysis of transactions and of how the execution of SQL by one applicationaffects the execution of SQL by others.

The SQL monitor can also be used to find poorly executing code; you can do so bysearching on individual execution times if the output is put into a table. Due to thevolume of information and performance overhead of running a SQL monitor, thistechnique it should only be used for short tests or problem determination, and not ina production environment.

Here's an example:




CREATE EVENT MONITOR BARFOR STATEMENTSWRITE TO TABLESTMT(TABLE drewkb.stmtTab)includes(rows_read,rows_written_stmt_text)

This command captures statement information and outputs it into a table calleddrewkb.stmtTab. This table will be created dynamically by DB2. The table could thenhave SQL run against it to determine which SQL read the most rows if, for instance,you were trying to find SQL that may not be using an index.

db2eva tool

There is a graphic utility, db2eva, that will parse the output of the event monitors.This is essential if you are working with statement or transaction data, since you mayhave thousands of events to deal with. The tool only works with event monitors thathave had their output directed to files. The previous release of the tool for DB2 V7.2worked directly against the event monitor output files.

Here's the command to start this tool:

db2eva [db databaseName] [evm eventMonitorName]

And here is db2eva's initial selection screen:

You may receive an error when you first open this tool if you have not alreadycaptured connection monitor data. The error in the following figure will be shown ifyou try and select any of the monitor types for which you have not capturedinformation. The message indicates that the tool cannot find the table with theinformation stored in it for the monitor.




Each screen differs based on the type of monitor data captured. All of the rows canbe drilled down through for more detailed information. Subsections of the SQL caneven be retrieved and examined if the option was specified with the statementmonitor.

Here's a sample statement screen:




Here's some sample statement data elements:

Complete documentation can be found in the DB2 documentation in CommandReference , in Chapter 1, "System Commands" (see Resources).

Section 4. Analyzing SQL with Explains

Overview

So, you've figured out that one of your SQL statements is running horribly. What doyou do about it? DB2 offers you a number of different tools to find out exactly what ishurting your performance. Each of the tools is slightly different, but they all look at anExplain of what the SQL is doing.

The Explain of the SQL is a graphical or text-based breakdown of how and whenevery component of your SQL statement is being performed. This includes suchbasic information as:




• Tables being accessed

• Indexes being used

• When data is joined

• When data is sorted

The Explain also captures much more complex information, which is quite useful inbreaking down exactly what is happening with the SQL:

• Table and index cardinality

• Order of tables and indexes being joined

• Cardinality of the results sets

• What fields are being selected in each section of the query

• Sort methods

• Timeframe of each section of the SQL


1. Be able to identify how to analyze SQL in DB2

2. Be able to use each tool to analyze your SQL

3. Understand what tools are available and when to use each one

Understanding Explain information

The most important concept you need to master to understand Explain information isthe timeron. A timeron is the unit of measurement used by the DB2 optimizer for theamount of time and resources that a query will take to complete. The timeron is acombination of time, CPU utilization, I/O, and other factors. Due to the changingvalues of these parameters, the number of timerons needed to execute a query isdynamic and can change from execution to execution. The timeron is also aninvented unit of measurement, and there is not a formula that can be used totranslate the number of timerons to the time in seconds that a query will take toexecute. The timeron will be the unit you use to determine if one query executionpath is faster then another. Don't worry if the number of timerons of a query variesby ten or twenty between compilations, as this could easily be due to changes inCPU activity, disk activity, or database usage.

SQL translation

All SQL that is executed by the database first has to be compiled. This is done byreducing the query down to an algebraic statement that the DB2 optimizer can thenanalyze. This algebraic statement is referred to as the query graph model, and is




worked with throughout the optimization process. The figure below lists the stages ofoptimization and parsing each query passes through before it is executed.

The final output of the optimization process is an access plan. The access plan isthe path and steps that DB2 will take to execute a query. This information will bewhat is displayed by all the Explain tools. Access plans appear at first to be quitecomplicated, but with some practice you will find that they are very easy tounderstand and analyze.

Plans can be examined in one of three forms:

• Visual tree model: The plan is shown in a GUI that allows you to pointand click on different components of the tree to drill down into moredetailed information. The tree is a series of different colored symbols,each with a specific meaning, that are displayed as a tree graph. Thevisual tree model can be examined using the DB2 Visual Explain tool. It isthe easiest tool to work with for beginners, since it displays lessinformation at once; also, the GUI is easier to use to find the informationyou need about a specific section.

• Text tree model: The plan is shown as an ASCII text-based tree graphmodel. All of the different sections of the SQL query are drawn asdifferent text shapes and then connected using text lines. The shape ofthe tree is identical to the one shown in the visual tree model. The textmodel can be difficult to read if the SQL is very complex, since the text




lines will wrap and distort the model. This often occurs if you are viewingthe text output using simple text editors such as vi for UNIX. If you importthe file into a text editor with better functionality, then the diagram will beeasy to view. The text tree model is displayed using db2exfmt,dynexpln, and db2expln, which we'll discuss in subsequent panels.

• Text information: The text information includes all of the specific detailsabout how the query is executed and about the statistics and fieldselection that the optimizer used to determine the access plan. Theinformation can be quite detailed, depending on the Explain tool used. Asummary of the table statistics is included at the end of the output to allowyou to understand what the optimizer's assumptions and optimization datawas. All of the information in the text section of the Explain output can befound in the Visual Explain tool by drilling down through the componentsof the query.

Visual Explain

The Visual Explain tool is called from the DB2 Control Center. To access it, open theDB2 Control Center, find and open the database that you want to run the SQLagainst. Right-click on the database name and select Explain SQL, as illustrated inthe figure below.




The new menu asks for the SQL that you would like to Explain. There are a numberof other options available:

• Get: Allows you to open text files where you have stored SQL.

• Save: Saves the SQL statement you are working with to a text file.

• Query number: Allows you to assign a specific labeled number to thequery.

• Query tag: An alphanumeric label for the query.

• Optimization level: Sets the optimization level of the query (seeOptimization level).

• Populate columns: This option will store the access plan information in aseries of tables in your database. This will allow you to view the access




plan and explain information later without having to recompile the SQLstatement.

Once the SQL has been executed successfully, a new menu will open that will showyou the access plan for the query. A smaller window labeled Overview will also becreated. This window will highlight with a blue rectangle the part of the access planthat you are viewing. This is handy when you are working with very large andcomplex queries and it is difficult to grasp which section you are currently looking at.There is a slide bar on the left side of the main window that allows you to control thezoom. This only affects the view and does not give you any additional information.




Every component of the access plan can be clicked to reveal more detailedinformation on the component. It is a good idea to try clicking through all the differentobject types to get comfortable with the query information that you have available.




Visual Explain components

There are a small number of Visual Explain components that you need tounderstand to work with the tool. All of the component explanations on this panel aregoing to be based on the example below:




Table object node

The table object indicates the table with which the query section is working. Theobject can be drilled down on to view the statistics of the table. This information canthen be further drilled down for index, clustering, and referencing column data. Inthis example, there are two table objects in the picture: TBC.SALESFACT andTBC.PRODUCT.

Index object node

The index object indicates the name of the index. The index object is alwaysattached to the table that it is scanning. In this example, the index name is MAR1and it is on the table TBC.MARKET.




Operator node

The operator node object indicates that an action is being performed on the object(s)that point to it. These actions include sorting and retrieving of data, joining tables orresult sets, and scanning data. Each operation is clearly labeled. In this examplethere are three different actions being performed. Two of the tables are having tablescans performed, one index is being scanned, and two data sets are being joinedusing the hashjoin algorithm.

Return node

The final object is the result set object. This object contains summary informationabout the query and what is being returned from the completed SQL. The timeronvalue of the object is the total length measurement of the time in timerons needed tocomplete the query.




Query information

There are a number of key parameters that greatly affect how a query will executeand how DB2 will compile it.

Parameter values

The Visual Explain tool has all of the parameters that affect the query compilationsummarized in one menu. The text-based tools have the list of parameter valuessummarized at the beginning of the output file. A full explanation of each parametercan be found in the DB2 documentation Administration Guide: Performance underthe Database Manager and database configuration sections (see Resources).

Here is the optimization parameter menu option:

Here is the optimization parameter list:




Let's look at these parameters in some detail.

• AVG_APPLS (average applications): This parameter indicates theaverage number of applications that will be running concurrently againstthe database. DB2 uses this information to determine how heavily the sortspace and buffer pools will be used and how much space the query willlikely be able to use.

• SORTHEAP (sort heap): The sort heap is the amount of space availablein memory to perform a sort. If the sort requires more memory then isavailable for a sort heap, then part of the sort data will have to be pagedto disk. This can have a very negative impact on performance, so sortsshould be kept in memory as much as possible.

• LOCKLIST (lock list): This indicates the amount of memory available forDB2 to store locking information for each application. If the lock list spaceis quite small, then DB2 may have to escalate some locks to allow roomfor all the locks being held by the applications.

• MAXLOCKS (maximum lock list percentage): This parameter controls




what percentage of the total lock list space one application can have. If anapplication tries to use up too much memory by having too many openlocks, DB2 will escalate some of the locks to free up space in the lock list.

• NUM_FREQVALUES (number of frequency values): The number offrequency values is used by the DB2 Runstats utility to control how manyof the most frequent values DB2 will keep in memory. This information isused by the optimizer to determine what percentage of the total result seta predicate in a WHERE clause will eliminate.

• NUM_QUANTILES (number of data quantiles): The number of quantilesis used by the DB2 Runstats utility to control how many quantiles arecaptured for column data. Increasing the number of quantiles will giveDB2 more information on the distribution of data in the database.

• DBHEAP (database heap): The database heap controls the amount ofmemory available for database object information. The objects includeindexes, tables, buffer pools, and table spaces. The event monitors andlog buffer information is also stored here.

• CPUSPEED (CPU speed): This parameter is the speed of the computer.If the value is set to -1, then a CPU speed measurement program is usedby DB2 to determine the proper setting.

• BUFFPAGE and buffer pool size: The optimizer uses the size of theavailable buffer pools in its optimization data. Increasing or decreasingthe buffer pool size can have a significant impact on the access plan.

Optimization level

The most important parameter that affects the access plan is the optimization level.This field tells the optimizer how much effort and what techniques it should used todetermine the access plan. A higher level will cause the optimizer to use morecomplex algorithms and algebraic analysis -- and much more time -- to generate thefinal plan.

Each optimization class uses a different subset of all the rules and statistics. A verydetailed description of these levels can be found in the DB2 documentation SQLReference in Chapter 5, "Statements," in the section "Set Current QueryOptimization" (see Resources). A short summary of each optimization level isincluded below.

• 0 -- Use a minimal amount of optimization

• 1 -- Use a degree of optimization roughly comparable to DB2/6000Version 1, plus some additional low-cost features not found in Version 1

• 2 -- Use features of opt class 5, but with a simplified join algorithm

• 3 -- Perform a moderate amount of optimization; similar to the queryoptimization characteristics of DB2 for MVS/ESA




• 5 -- Use a significant amount of optimization; with Heuristic Rules (default)

• 7 -- Use a significant amount of optimization; without Heuristic Rules

• 9 -- Use all available optimization techniques

A general rule of thumb is to use the following optimization levels for the differentquery workloads:

• Very simple OLTP: 0 or 1. For queries that require very little optimizationand rely heavily on primary key index searches or very simple joins.

• OLTP: 1. For simple queries that involve a small number of tables andjoins involved indexes on the tables.

• Mixed OLTP and reporting: 5. For a workload that involves complexOLTP or reports involving many complex joins on multiple tables.

• Very complex data mining or decision support: 9. Queries that requiresignificant analysis of data statistics and can run for a long time (over aminute) should use the highest optimization level. The optimization willtake much longer but the improvements that can be found in the accessplan normally outweigh the extra compilation time.

Explain table format command

The db2exfmt tool processes information that has been inserted into the Explaintables. These tables are used by DB2 to record all the information on the differentcomponents of the SQL and the optimization information. When you used the VisualExplain tool, the tables were created automatically for you. If you use the text toolsfirst, then you will have to run a script to create them first. Execute the commandlisted below in the misc subdirectory of the home directory of the db2 instance towhich you are attached. All of the tables and indexes will be created for you.

Here's the Explain table error message:

And here's the appropriate command:

db2 connect to databaseNamedb2 -tvf EXPLAIN.DDL

The db2exfmt tool is different in that it works with information that has already beencaptured and then presents it in an easy-to-read format. After that is complete,




populate the explain tables.

Capturing Explain information

The easiest method to capture Explain information is to store your SQL in a text fileand then run it from the DB2 Command Line Processor (CLP) in Windows or fromthe command line in UNIX or Linux. DB2 has a variable, CURRENT EXPLAINMODE, that determines if Explain information is captured. This variable can be set tohave DB2 populate the Explain tables whenever a query is executed. Here's theappropriate command to do so:

db2 SET CURRENT EXPLAIN MODE [no | yes | explain]

And here are the potential values for CURRENT EXPLAIN MODE:

• NO: This is the default; the query is executed normally

• YES: The query is executed normally and the explain information iscaptured as well

• EXPLAIN: The query is not executed but the explain information ispopulated into the tables

Here's an example:

Using the tool

db2exfmt has a large number of options that allow you to pick the Explainstatements that you would like to work with. You can also control what information isshown. The easiest method is to use all of the defaults, which will then cause thetool to return information on the most recently explained statement:




Here's sample query summary output:

And here's sample query tree information:




Using the db2expln and dynexpln tools

The db2expln tool can be called from the command line to obtain the access planfor the query. However, this tool does not return optimizer information. Thedynexpln tool is useful for explaining dynamic queries that do not use parametermarkers. Information on both tools can be found in the DB2 document AdministrationGuide: Performance in Chapter 7, "SQL Explain Facility" (see Resources).

db2expln

This utility is normally used to analyze SQL statements that are stored in static SQLpackages. However, it can also be used to execute SQL dynamically using thefollowing parameters:

• -database -- Name of the database to connect to

• -statement -- Enclose the statement in quotes to execute a dynamicSQL statement




• -stmtfile fileName -- A file containing a list of SQL statements to beexecuted

• -terminal -- Directs the output to the screen

• -output fileName -- Directs the output to the specified filename

Here's an example command for this tool:

db2expln -database drew_db -statement "select * from syscat.tables" -terminal

And here's the sample output:

dynexpln




The dynexpln tool has been kept for backwards compatibility with earlier versionsof DB2. You can use the dynamic options of db2expln to perform all of thefunctions of db2expln. When you use db2expln, the statement is prepared as areal dynamic SQL statement and the access plan is generated from the SQL cache.The dynexpln tool prepares the statement as static SQL, which does not give asaccurate an access plan and does not allow parameter markers.

Troubleshooting SQL

Entire books have been written on how to improve SQL, but here are a few keypoints that you should keep in mind when you begin working with the Explain tools.

Use of indexes. Is the query using the indexes you expect? Make sure that tablescans are not occurring on tables you thought had indexes on them. This informationcan easily be found by looking at the access plan diagram. If the indexes do exist,then check to see what the cardinality or order of the index keys are. It is often notwhat you expected.

Table cardinality and use of 'SELECT *'. Sometimes the DB2 optimizer willdecide that it is faster to scan an entire table due to the number of columns that youare bringing back. Perhaps the table is quite small, or perhaps it's just not efficient toscan an index and then return a large number of rows that return all the columns ofthe table. Try to only return the columns that you actually need. Take a look at whatcolumns are being returned in each section of the query to see if you really needthem and see if that is why a table scan is occurring.

Optimization level is too low. Many DBAs lower the optimization level to 1 toreduce the amount of time required for query preparation. Sometimes, raising theoptimization level to 5 will allow the optimizer to find a better access plan without youhaving to create a new index to improve performance. This value can easily beadjusted in the Visual Explain tool when you explain a query. It can also be changedat the command line using the following command:

db2 set current query optimization [0|1|2|3|5|7|9]

Section 5. Using the Health Center and MemoryVisualizer

Overview

The Memory Visualizer and the Health Center are two new tools that are includedwith DB2 V8.1. The Memory Visualizer gives you the ability to easily monitor and




record the memory usage of an instance, its databases, and the applications that areconnected to them. The Health Center allows you to monitor the health of thedatabases in the background without having to constantly check on them.


1. Be able to run the Memory Visualizer and Health Center tools.

2. Understand the different options and screens in each.

3. Understand why and how the tools should be used.

Using the Memory Visualizer

DB2 V8.1 has a new tool included with the Control Center that gives you the abilityto observe how memory is actually being allocated in real-time. In previous releasesof DB2, it was difficult to figure out how effectively the memory being allocated to theheaps was being used. The new Memory Visualizer allows all of the memoryallocated to the instance and its databases to be observed in a graphical format.

This tool is called at an instance level. In the Control Center, find and select theinstance and right-click it. Select View memory usage.




The tool will track the current memory allocation for almost all the memory heaps.The top half of the tool is used to display the exact values of the parameters. Youcan also select the parameters that will be graphed in the memory utilization graph.The refresh intervals allow you to control how often the tool samples the databasefor information about the memory heaps. If you are looking at a system where exactinformation is needed about a certain workload or behavior, then the refresh agecould be set to a very small value, such as five seconds. If you are just using thistool to monitor behavior of the database in a production environment, then a longerrefresh age of five or ten minutes may be fine.




The output from the tool can also be saved to a file. You can open this file later andthe exact parameter value in addition to the plotted graphs of the data. All of thesefiles are given the extension of mdf. Initially the plot will be empty when you open asaved file. If you select a parameter, then the graphical data you captured on it willappear.

Why should I use Memory Visualizer?

Memory Visualizer gives you access to much more information than before. Certainparameters within DB2 were often tuned by trial and error, and it was difficult toknow how much space was really being used. This lead to memory being wasteddue to over-allocation.

In addition to providing memory visualization, the tool also allows you to set alarmson the values of the parameters. The output of the alarms will be written to a filecalled threshold, which is in the same directory as db2diag.log. This directoryis in the instance home directory. The location varies depending on what youselected when you created the instance.




DB2 Health Center

The Health Center is another new tool added to DB2 8.1. The DB2 Health Center isa convenient tool to monitor the health and performance of multiple databases fromone panel. The tool can be used to determine if:

• There are sufficient resources, such as free memory, table spacecontainers, or logging storage, to accomplish tasks

• Resources are used efficiently

• Tasks complete within acceptable periods of time or without significantdegradation in performance

• Resources or database objects are not left indefinitely in unusable states

The warnings given by the Health Center can then be combined with the informationfrom the other DB2 Center tools to help to identify and correct any problems.

Opening the Health Center




The Health Center can be opened using its own icon in the program menu or fromwithin one of the other GUI Center tools.

To open it from the Control Center, click Tools => Health Center.

To open it from the program menu:

Using the Health Center

The Health Center has an easy-to-use interface that displays only the selected levelof severity for the database problems. In the upper left corner of the tool there arefour icons, which are used to select the severity level.




The four options are:

1. Shows instances and databases in an alarm state only.

2. Shows instances and databases in either an alarm or warning state.

3. Shows instances and databases in any of the following states: alarm,warning, and attention.

4. Shows instances and databases in any of the following states: alarm,warning, attention, and normal. You can also view databases andinstances that cannot be monitored.

Activating the Health Monitor

The Health Monitor has to be started before monitoring can occur. This is done byright-clicking on the instance and selecting Start Health Monitor.

Adding alerts

The Health Center has predefined default values determining the parameters andlevels for which an alarm or warning message will be given. The alerts are definedby right-clicking the desired database or instance. Select Configure=>DatabaseHealth Indicator Settings to open the parameter alert menu. The warning andalarm levels can be set in this menu.




A parameter has to be enabled for the Health Center return messages about itswarning and alarms. Clicking Enable will open a new menu with options on what todo if the event occurs.

Alert options




The alert options allow you to run a specific DB2 task or to execute a script that youhave created on the system. There are a number of settings that you can control,such as the name of the script, the ID under which it should run, and whether thescript is a DB2 command script or an OS script.

The task option works in conjunction with the task scheduler tool. To use this option,you have to install the Database Tools Catalog at installation time. The taskscheduler can be used to set up DB2 tasks to run such as Runstats, Reorg, or adatabase backup. Multiple tasks and scripts can be executed for any one alarm orwarning. This gives you more flexibility in how you handle certain situations.

Section 6. Leveraging the DB2 Governor and the QueryPatroller

Overview

There are two main tools produced by IBM for DB2 that allow you to monitor andcontrol the execution of SQL against your databases. The DB2 Governor is used tocontrol what priority users and applications have for executing their SQL. The DB2Query Patroller provides query and resource management for decision supportsystems. The tool accepts, analyzes, prioritizes, and can schedule all the queriesthat pass through your system.


1. Understand what query monitoring tools are available

2. Understand when to use the DB2 Governor and the Query Patroller




What is the DB2 Governor?

The DB2 Governor is used to monitor a user's activity and, if required, takeappropriate actions. It collects statistics on a regular basis defined by a configurationfile. The Governor then evaluates the statistics against a set of rules that are alsodefined in the configuration file. Based on these rules, the Governor may change theapplication's priority, or force the application off the database.

When is it used?

The Governor is used in large production environments where many queries arerunning against large databases. These queries can take a very long time if they arebeing used for data mining or decision support systems (DSS). The governor allowsyou to assign a higher priority to queries that need to be finished soon or to lower thepriority of queries taking up too much resources. A separate instance of the governoris run against each instance that you are monitoring.

Documentation

A full description of the DB2 Governor can be found in the DB2 documentation inAdministration Guide: Performance in Chapter 9, "Using the governor" (seeResources).

Using the Governor

The Governor is controlled by a configuration file, where the rules of the system arestored. These rules are used to determine if the priority of the application running theSQL needs to be changed. If a rule is activated, then the Governor performs thespecified action, such as reducing the priority of the application or forcing it off thedatabase.

Starting the Governor

A daemon must be started for each database that you would like monitored. Thedaemon can be started from the command line using the following command:

db2gov start databaseName configFile logFile

Stop the daemon with the following command:

db2gov stop databaseName

Here's an example of these commands in action:

db2gov start drew_db govrules.cfg gov.logdb2gov stop drew_db




Configuration file

The configuration file is used to store all the rules that the governor daemon will useto control the applications. Here are some of the file's syntax requirements:

• Comments are delimited inside braces ({ }).

• Most entries can be specified in uppercase, lowercase, or mixed-casecharacters. The exception is the application name, specified as anargument to the applname rule, which is case sensitive.

• Each rule ends with a semicolon (;).

DB2 Governor rules

Required rules

You must specify a rule about when the daemon should wake up to monitor thedatabase. This rule includes information on which database to monitor, CPU usage(not available with Windows), and the sleep interval between monitoring.

A sample rule:

interval 30; dbname drew_db; account 45;

This rule would activate the daemon every 30 seconds. If an interval value is notgiven, the default value of 120 seconds is used. The database in the example is thedrew_db database, and the CPU information will be examined every 45 seconds.

The clauses for the rules must be entered in a specific order as detailed below:

• desc (optional): A comment about the rule, enclosed in quotation marks.

• time (optional): The time during the day when the rule is evaluated.

• authid (optional): One or more authorization IDs under which theapplication executes statements.

• applname (optional): The name of the executable or object file thatconnects to the database. This name is case sensitive.

• setlimit: The limits that the governor checks. These can be one ofseveral, including CPU time, number of rows returned, idle time, and soon.

• action (optional): The action to take if a limit is reached. If no action isspecified, the governor reduces the priority of agents working for theapplication by 10 when a limit is reached. Actions against the application




can include reducing its agent priority, forcing it to disconnect from thedatabase, or setting scheduling options for its operations.

Some more example rules:

desc "Restrict the Unit of Work to be less then 30 minutes"setlimit uowtime 1800 action force;

desc 'Slow the use of the java tools down for the training user'authid trainingapplname javaw.exesetlimit cpu 5 locks 100 rowssel 1000;

desc "Increase the priority of an important application so it always completes quickly"applname importantApp .exesetlimitcpu 1locks 1rowssel 1action priority -20;

desc "During day hours do not let anyone run for more than 10 seconds"time 8:30 17:00setlimit cpu 10action force;

What is the DB2 Query Patroller?

The DB2 Query Patroller provides query and resource management for decisionsupport systems. The tool accepts, analyzes, prioritizes, and can schedule all thequeries that pass through your system. Once the queries are completed, the userswill also be notified. This functionality is extremely useful in a large environmentwhere the queries may take hours to complete or different departments may havedifferent priorities or uses of the system.

The Query Patroller will also perform load balancing by redirecting work to theappropriate database partitions to ensure that one is not being used too heavily. Thetool is used only with the multiple partition option for DB2 ESE in an SMP or MMPenvironment.

With the latest revision, IBM has completely rearchitected DB2 Query Patroller fromthe ground up, integrating the query governing functionality into a DB2 QueryPatroller Center similar to the DB2 Control Center and providing an easy-to-use userinterface. The Query Patroller is completely server-based with no client softwarerequired.

Who should use the Query Patroller?

The Query Patroller tool is used by DBAs who administer large databases and datawarehouses. These systems are quite large and have many users running complexqueries against them. Without the Query Patroller, it is difficult to manage all theSQL being run against the systems.

Documentation




The Query Patroller is included as part of the DB2 Warehouse Manager tool (seeResources).

Section 7. Conclusion

Summary

Having finished this tutorial, you should now have achieved the following objectives:

1. Understand what snapshots are

2. Learn how to take a snapshot

3. Know what types of snapshots are available

4. Understand when to take which type of snapshot

5. Practice working with snapshot information

6. Understand what event monitors are

7. Learn how to take an event monitor

8. Know what types of event monitors are available

9. Understand when to take which type of event monitor

10. Practice working with event monitor information

11. Be able to identify how to analyze SQL in DB2

12. Be able to use each tool to analyze your SQL

13. Understand what tools are available and when to use each one

14. Be able to run the Memory Visualizer and Health Center tools.

15. Understand the different options and screens in each.

16. Understand why and how the tools should be used.

17. Understand what query monitoring tools are available

18. Understand when to use the DB2 Governor and the Query Patroller




You are now ready to take Part 4 of the exam. Good luck!




Resources

Learn

• Check out the other parts of the DB2 V8.1 Database Administration certificationprep series.

• All of the documents that are referenced in this tutorial can be downloaded fromthe DB2 Web page at: DB2 Universal Database V8.1 Documentation

• The following table maps the name of the DB2 Documentation to thecorresponding PDF file.Documentation PDF Name Link

Administration Guide:Performance

db2d3.pdf Document Link

Command Reference db2no.pdf Document Link

System Monitor Guideand Reference

db2fo.pdf Document Link

Complete SQL Reference db2s0.pdf No link available online

SQL Reference 1 db2s1.pdf Document Link

SQL Reference 2 db2s2.pdf Document Link

Quick Beginnings for DB2Clients

db2it.pdf Document Link

• The Query Patroller is included as part of the DB2 Warehouse Manager tool.

• Download aself-study course for experienced relational database programmerswho'd like to know more about DB2.

• Stay current with developerWorks technical events and webcasts.

Get products and technologies

• Build your next development project with IBM trial software, available fordownload directly from developerWorks.

Discuss

• Participate in the discussion forum for this content.

About the author

Drew BradstockDrew Bradstock works as a DB2 consultant for IBM. His department is responsiblefor the migration of applications from other RDBMSs to DB2. He has previouslyworked with the DB2 Performance department and specializes in the design andperformance tuning of large-scale benchmarks and proofs of concept. When notgetting the best out of DB2, he's training for his first triathlon. You can reach Drew at



http://www.ibm.com/developerworks/db2/library/tutorials/db2cert/701_prep.html?S_TACT=105AGX11&S_CMP=tut

http://www.ibm.com/developerworks/db2/library/tutorials/db2cert/701_prep.html?S_TACT=105AGX11&S_CMP=tut

http://www-306.ibm.com/software/data/db2/udb/support/manualsv8.html

http://www-306.ibm.com/software/data/db2/datawarehouse/

http://www.ibm.com/software/data/db2/ct10crs/

http://www.ibm.com/developerworks/offers/techbriefings/?S_TACT=105AGX11&S_CMP=tut

http://www.ibm.com/developerworks/downloads?S_TACT=105AGX11&S_CMP=tut

http://www-128.ibm.com/developerworks/community/


[email protected].



mailto:[email protected]


db2 v8.1 for linux, unix, and windows database ......db2 v8.1 for linux, unix, and windows database...

Documents