Database Administration Guide

Database Administration
Using the DBA Cockpit
IBM DB2 for Linux, UNIX,
and Windows
For SAP Systems based on Enhancement
Package 1 + 2 of SAP NetWeaver 7.0
Document Version 1.00 April, 2010

SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany
T +49/18 05/34 34 24
F +49/18 05/34 34 20
www.sap.com

 Copyright 2010 SAP AG. All rights

respective logos are trademarks or registered trademarks

reserved.

of SAP AG in Germany and in several other countries all

over the world. All other product and service names

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP AG. The
information contained herein may be changed without prior notice.

mentioned are the trademarks of their respective

companies. Data contained in this document serves
informational purposes only. National product
specifications may vary.

Some software products marketed by SAP AG and its distributors contain

proprietary software components of other software vendors.

These materials are subject to change without notice.

These materials are provided by SAP AG and its affiliated

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks

of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA,
AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries,
z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix,
i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or
registered trademarks of IBM Corporation.

companies ("SAP Group") for informational purposes

only, without representation or warranty of any kind, and
SAP Group shall not be liable for errors or omissions with
respect to the materials. The only warranties for SAP
Group products and services are those that are set forth in
the express warranty statements accompanying such
products and services, if any. Nothing herein should be
construed as constituting an additional warranty.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either
trademarks or registered trademarks of Adobe Systems Incorporated in

Document classification: PUBLIC

the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

Disclaimer
Some components of this product are based on Java.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open
Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,
VideoFrame, and MultiWin are trademarks or registered trademarks of

Any code change in these components may cause

unpredictable and severe malfunctions and is therefore
expressively prohibited, as is any decompilation of these
components.

Citrix Systems, Inc.

Any Java Source Code delivered with this product is
HTML, XML, XHTML and W3C are trademarks or registered
trademarks of W3C, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used
under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and

other SAP products and services mentioned herein as well as their

only to be used by SAPs Support Services and may not

be modified or altered in any way.

Typographic Conventions

Icons

Type Style

Description

Example Text

Words or characters quoted

from the screen. These include
field names, screen titles,
pushbuttons labels, menu
names, menu paths, and menu
options.

Caution

Cross-references to other
documentation

Syntax

Example text

Emphasized words or phrases

in body text, graphic titles, and
table titles

EXAMPLE TEXT

Technical names of system

objects. These include report
names, program names,
transaction codes, table
names, and key concepts of a
programming language when
they are surrounded by body
text, for example, SELECT and
INCLUDE.

Example text

Output on the screen. This

includes file and directory
names and their paths,
messages, names of variables
and parameters, source text,
and names of installation,
upgrade and database tools.

Example text

Exact user entry. These are

words or characters that you
enter in the system exactly as
they appear in the
documentation.

<Example
text>

Variable user entry. Angle

brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.

EXAMPLE TEXT

Keys on the keyboard, for

example, F2 or ENTER.

Icon

Meaning

Example
Note
Recommendation

Additional icons are used in SAP

Library documentation to help you
identify different types of information at
a glance. For more information, see
Help on Help
General Information
Classes and Information Classes for
Business Information Warehouse on
the first page of any version of SAP
Library.

Contents
Database Administration Using the DBA Cockpit: IBM DB2 for
Linux, UNIX, and Windows ................................................................ 8
1 The DBA Cockpit ................................................................................. 9
1.1 SAP GUI-Based User Interface ............................................................ 10
1.1.1 Central System Data .............................................................................................. 12
1.1.2 Maintenance Actions in the DBA Cockpit ............................................................... 13
1.1.3 Configuration of Systems for Remote Monitoring ................................................... 14
1.1.3.1 Configuring Systems for Remote Monitoring Using Remote Database
Connections ................................................................................................................. 15
1.1.3.1.1 Configuration of Database Connections ...................................................... 16
1.1.3.2 Configuring Systems for Remote Monitoring Using the System Landscape
Directory (SLD)............................................................................................................. 20

1.2 Web Browser-Based User Interface (Web Dynpro) ........................... 21

2 Performance ...................................................................................... 26
2.1 Performance: Partitions....................................................................... 26
2.2 Performance: Database ....................................................................... 27
2.2.1 Database: Buffer Pool ............................................................................................ 28
2.2.2 Database: Cache.................................................................................................... 30
2.2.3 Database: Asynchronous I/O ................................................................................. 31
2.2.4 Database: Direct I/O .............................................................................................. 32
2.2.5 Database: Real-Time Statistics............................................................................... 33
2.2.6 Database: Locks and Deadlocks............................................................................. 34
2.2.7 Database: Logging ................................................................................................. 35
2.2.8 Database: Calls ...................................................................................................... 37
2.2.9 Database: Sorts ..................................................................................................... 39
2.2.10 Database: XML Storage ....................................................................................... 40

2.3 Performance: Schemas ....................................................................... 41

2.4 Performance: Buffer Pools .................................................................. 42
2.4.1 Buffer Pool ............................................................................................................. 43
2.4.2 Buffer Pools: Asynchronous I/O ............................................................................. 46
2.4.3 Buffer Pools: Direct I/O .......................................................................................... 47
2.4.4 Buffer Pools: XML Storage ..................................................................................... 47

2.5 Performance: Tablespaces.................................................................. 49

2.5.1 Tablespaces: Buffer Pool........................................................................................ 49
2.5.2 Tablespaces: Asynchronous I/O ............................................................................ 51
2.5.3 Tablespaces: Direct I/O ......................................................................................... 52
2.5.4 Tablespaces: XML Storage .................................................................................... 53

2.6 Performance: Tables ............................................................................ 54

2.7 Performance: Applications .................................................................. 56
2.7.1 Applications: Application ......................................................................................... 58
2.7.2 Applications: Agents ............................................................................................... 61
2.7.3 Applications: Assigned Agents................................................................................ 63
2.7.4 Applications: Agents Memory ................................................................................. 65
2.7.5 Applications: Buffer Pool......................................................................................... 65
2.7.6 Applications: Direct I/O .......................................................................................... 67

April 2010

2.7.7 Applications: XML Storage ..................................................................................... 68

2.7.8 Applications: Locks and Deadlocks......................................................................... 69
2.7.9 Applications: Calls .................................................................................................. 71
2.7.10 Applications: Sorts............................................................................................... 72
2.7.11 Applications: Cache .............................................................................................. 73
2.7.12 Applications: Unit of Work.................................................................................... 74
2.7.13 Applications: Statement ....................................................................................... 74
2.7.14 Applications: Statement Text ................................................................................ 76
2.7.15 Applications: SQL Workspace............................................................................... 77

2.8 Performance: SQL Cache .................................................................... 78

2.9 Performance: Lock Waits and Deadlocks .......................................... 83
2.10 Performance: Inplace Table Reorganization .................................... 85
2.11 Performance: History - Database ...................................................... 87
2.12 Performance: History Tables.......................................................... 89
2.13 Performance: Performance Warehouse .......................................... 90
2.13.1 Performance Warehouse: Reporting .................................................................... 91
2.13.2 Performance Warehouse: Configuration .............................................................. 92

3 Space .................................................................................................. 95
3.1 Space: Automatic Storage................................................................... 95
3.2 Space: Tablespaces ............................................................................. 96
3.2.1 Maintaining Tablespaces ........................................................................................ 98

3.3 Space: Containers .............................................................................. 103

3.4 Space: Tables and Indexes................................................................ 104
3.5 Space: Single Table Analysis ............................................................ 106
3.6 Space: Virtual Tables ......................................................................... 120
3.7 Space: History - Overview ................................................................. 121
3.8 Space: History - Database and Tablespaces ................................... 123
3.9 Space: History - Tables and Indexes ................................................ 125

4 Backup and Recovery.................................................................... 127

4.1 Backup and Recovery: Backup Overview ........................................ 127
4.2 Backup and Recovery: Logging Parameters ................................... 127

5 Configuration ................................................................................... 128

5.1 Configuration: Overview .................................................................... 128
5.2 Configuration: Database Manager .................................................... 132
5.3 Configuration: Database.................................................................... 134
5.3.1 Maintaining the Database Configuration ............................................................... 135
5.3.2 Comparing Database Configuration Parameters for Several Database Partitions .. 136

5.4 Configuration: Registry Variables (DB2 for Linux, UNIX, and

Windows ................................................................................................... 137
5.5 Configuration: Parameter Changes .................................................. 137
5.6 Configuration: Database Partition Groups....................................... 138
5.6.1 Maintaining Database Partition Groups ................................................................. 140

5.7 Configuration: Buffer Pools .............................................................. 143

5.7.1 Maintaining Buffer Pools ....................................................................................... 144

5.8 Configuration: Special Tables Regarding RUNSTATS .................... 147

5.9 Configuration: File Systems .............................................................. 148

April 2010

5.10 Configuration: Data Classes ........................................................... 149

5.10.1 Maintaining Data Classes ................................................................................... 151

5.11 Configuration: Monitoring Settings ................................................ 152

5.12 Configuration: Automatic Maintenance Settings .......................... 153
5.12.1 Configuring General Maintenance Settings ......................................................... 155
5.12.2 Configuring Automatic Backup Settings .............................................................. 155
5.12.3 Configuring Automatic RUNSTATS Settings ....................................................... 158
5.12.4 Configuring Automatic REORG Settings ............................................................. 159

6 Jobs .................................................................................................. 163

6.1 Central Calendar................................................................................ 163
6.1.1 Using the Central Calendar.................................................................................. 164

6.2 The DBA Planning Calendar .............................................................. 166

6.2.1 Setting Up the DBA Planning Calendar ................................................................. 170
6.2.1.1 Scheduling an Action ...................................................................................... 172
6.2.1.2 Changing an Action......................................................................................... 173
6.2.1.3 Deleting an Action ........................................................................................... 174
6.2.1.4 Executing an Action ....................................................................................... 175
6.2.1.5 Displaying the Status of a Days Actions.......................................................... 175
6.2.1.6 Displaying Scheduled Actions ......................................................................... 175
6.2.1.7 Troubleshooting .............................................................................................. 176
6.2.1.8 Updating Statistics .......................................................................................... 177
6.2.1.9 Scheduling a REORGCHK for All Tables......................................................... 178
6.2.1.10 Reorganizing Tables ..................................................................................... 179
6.2.1.11 Database Backups ........................................................................................ 181
6.2.1.12 Archiving Log Files To Tape .......................................................................... 184
6.2.1.13 Scheduling Scripts ........................................................................................ 185
6.2.1.14 Running the NLS Cleanup Job ...................................................................... 185

6.3 The DBA Log....................................................................................... 186

6.4 Back-End Configuration .................................................................... 187
6.5 The SQL Script Maintenance ............................................................. 188

7 Alerts ................................................................................................ 191

7.1 Alerts: Database System Monitoring in CCMS ................................ 191
7.2 Alerts: Configuring Database System Monitoring........................... 192
7.3 Alerts: Alert Monitor ........................................................................... 193
7.4 Alerts: Alert Message Log ................................................................. 194
7.5 Alerts: Alert Configuration ................................................................ 196

8 Diagnostics ..................................................................................... 198

8.1 Diagnostics: Displaying the Audit Log ............................................. 198
8.2 The EXPLAIN Function ...................................................................... 199
8.2.1 The EXPLAIN Function (New Web Browser-Based Version) ................................. 199
8.2.2 The EXPLAIN Function (SAP GUI-Based Version) ............................................. 202
8.2.2.1 EXPLAIN Options .......................................................................................... 203

8.3 Diagnostics: Missing Tables and Indexes ...................................... 206

8.4 Diagnostics: Deadlock Monitor ......................................................... 207
8.4.1 Creating the Deadlock Monitor ............................................................................. 208
8.4.2 Deadlock Monitor Analysis ................................................................................... 209

April 2010

8.5 Diagnostics: SQL Command Line..................................................... 213

8.6 Diagnostics: Index Advisor ............................................................... 213
8.6.1 Retrieving Index Recommendations for the Dynamic SQL Cache ......................... 214
8.6.2 Retrieving Index Recommendations for a Single SQL Statement .......................... 217
8.6.3 Defining Virtual User-Defined Indexes .................................................................. 219
8.6.4 Validating Indexes Using the EXPLAIN Function .................................................. 220
8.6.5 Creating Indexes in the ABAP Dictionary .............................................................. 221

8.7 Diagnostics: Cumulative SQL Trace................................................ 222

8.8 Diagnostics: DBSL Trace Directory ................................................. 223
8.9 Diagnostics: Trace Status ................................................................ 223
8.10 Diagnostics: Database Notification Log........................................ 224
8.11 Diagnostics: Database Diag Log..................................................... 225
8.12 Diagnostics: DB2 Logs .................................................................... 227
8.13 Diagnostics: Dump Directory ......................................................... 228
8.14 Diagnostics: DB2 Information Center............................................. 228

9 Workload Management ................................................................... 229

9.1 Workload Management: Workloads and Service Classes .............. 231
9.2 Workload Management: Critical Activities ....................................... 234
9.3 Workload Management: SAP WLM Setup Status ............................ 237

10 BW Administration ........................................................................ 239

10.1 BW Administration: BW Data Distribution .................................... 239
10.2 BW Administration: MDC Advisor .................................................. 239
10.3 BW Administration: Administration and Monitoring of the NearLine Storage (NLS) Database .................................................................. 240
10.3.1 BW Administration: NLS Configuration................................................................ 240
10.3.2 BW Administration: NLS Overview ...................................................................... 242
10.3.3 Analyzing Single Tables of the BW and the NLS Database ................................. 243

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Database Administration Using the

DBA Cockpit: IBM DB2 for Linux, UNIX,
and Windows
Use
This document explains how you administer your database using the DBA Cockpit, which
allows you to monitor, control and configure your database. The DBA Cockpit [Page 9]
provides you with access to all the functions and indicators for monitoring and administration:
Checking system status and operation modes
Locating potential problems as quickly as possible
Early diagnosis of potential problems, for example, resource problems in the host or
database system, which could adversely affect the SAP system
Analyzing and tuning the SAP system and environment (host and database systems) to
optimize the throughput of the SAP system
Configuring the database

This document applies to SAP systems that are based on SAP Enhancement
Package 1 for SAP NetWeaver 7.0.
More Information
For more information about running an SAP system on DB2 for Linux, UNIX, and
Windows, choose the SAP on DB2 for LUW in the SDN pushbutton in the navigation
frame of the DBA Cockpit.
For DB2-specific information, see the respective IBM DB2 Information Center for your
database and the following IBM manuals:
IBM DB2 System Monitor Guide and Reference
IBM DB2Performance Guide

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1 The DBA Cockpit

The DBA Cockpit is a platform-independent tool that you can use to monitor and administer
your database. You access the DBA Cockpit by calling transaction DBACOCKPIT. Then, the
initial screen DBA Cockpit: System Configuration Maintenance appears.

Features
You can choose between the following user-interfaces:
SAP GUI-based user interface
Web browser-based user interface

Activities
You can use the DBA Cockpit to:
Navigate between different actions
Change to another action without closing the previous action and still hold all data
retrieved by this action
Handle central configuration
Monitor remote systems using remote database connections
To use the functions offered for remote monitoring, you must configure the system
you want to monitor. The local system is configured automatically when you start the
DBA Cockpit for the first time.
After having configured the connection and depending on the database, more actions
are required to configure the database monitor and to set up database administration.
Caution
For systems that are monitored using a remote database connection, constraints
depend on whether:
o

The database release of the remote system is compatible to the database

release of the local system.

You want to monitor an ABAP-only or a Java-only SAP system.

End of the caution.

More Information
SAP GUI-Based User Interface [ page 10]
Web Browser-Based User Interface [page 21]

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1 SAP GUI-Based User Interface

The entry screen of the DBA Cockpit using the GUI-based user interface is divided into the
following areas:

Application toolbar

Central system data

System landscape
toolbar

Action area
Navigation frame

Action message window

Framework message window

Application Toolbar
Provides a minimum of functions, for example, to display or hide the areas on the left side.
System Landscape Toolbar
Provides central functions to manage the system landscape, for example:
Access to system configuration where you configure and set up your system
landscape
Management of database connections
Lets you choose the system to monitor. Additional information about a distributed
database system is displayed if available.
Navigation Frame
Displays a tree structure divided at the top level into the main task areas of database
administration. These are, for example, performance monitoring, space management, and job
scheduling. Within each task area, there is a set of related action nodes.

10

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Central System Data

This area is common to most actions. It provides, for example, the following data:
Time of last refresh
Database startup time
Name of database
Action Area
Displays the details of the currently selected action.
Action Message Window
Only appears with certain actions and displays additional information that is related to the
selected action.
Framework Message Window
Displays the message window provided by the framework. Unlike the classic SAP GUI
messaging process, the framework message window contains a complete history of all
messages sent during the session.
In addition, you can:
Clean up the window by choosing the Clear Message Window pushbutton.
Collapse or expand or the window by choosing either the Minimize Message Window
or the Show Message Window pushbutton.
Check if a long text for a message is available by double-clicking the message or by
choosing Show Long Text.
Print the message text by choosing the Print Version pushbutton.
Note
Changes to the screen area sizes are user-specific and are restored when you next start the
DBA Cockpit.
End of the note.
More Information
Central System Data [page 12]
Maintenance Action in the DBA Cockpit [page 13]
Configuration of Systems for Remote Monitoring [page 14]

April 2010

11

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.1 Central System Data

Most of the DBA Cockpit screens provide a unique subscreen area displaying the central
system data of the selected screen:
Field

Description

Last Refresh

Date and time when the screen data was last refreshed

DB Name

Name of database of the selected system

Started

Date and time when the database engine started

DB Release

Database release
Date and time of last reset or checkpoint of the monitored data
Note

Last Reset/Checkpoint
This field is available only for actions that support Reset/Since
Reset or Set Checkpoint/Delta to Checkpoint.
End of the note.
The currently selected set of data. This is available for actions
that support Reset/Since Reset:
Since DBM Start
Reset
Current Selection

Since Reset
And for actions supporting checkpoints:
Current Configuration
Checkpoint Set
Delta to Checkpoint
Currently selected system
Note

System

This field is only available if the navigation frame has been hidden
using the Full Screen on/off function. In this case, you can select
the required system in this field.
End of the note.

12

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Partition of currently selected system

Note
Partition

This field is only available if the navigation frame has been hidden using the
Full Screen on/off function. In this case, you select the required partition in this
field.
End of the note.

1.1.2 Maintenance Actions in the DBA Cockpit

The DBA Cockpit provides a set of actions to monitor and to maintain the database. To be
able to perform these actions, the SAP user requires some additional authorizations.
The maintenance actions provided in the DBA Cockpit set locks to prevent parallel
processing. All changes to the database are recorded in an audit log file.
Authorization Check
When you start the DBA Cockpit or change to another system in the DBA Cockpit, an
authorization check is performed.
Granting of Database Permissions
To be able to access the database, the user used for remote monitoring must at least have
sufficient authorizations.
Local systems use the connect user for monitoring tasks. This user already has
sufficient permissions. If more authorizations are required for administrative actions, a
second connection using the database administration user is used.
Systems monitored via remote database connections use the user specified for the
database connections. This user must have sufficient authorizations.
Locking of Actions
For each maintenance action that you have selected using the DBA Cockpit, a lock is set for
the system being monitored. All locks are released when you exit the DBA Cockpit or when
you change to another system.
Auditing of Maintenance Actions

The following only applies to Oracle and IBM DB2 for Linux, UNIX, and
Windows.
When you make changes that affect database objects such as database configuration
parameters or tablespaces, an audit log is written. You can display this audit log in the DBA
Cockpit.
For more information, see Displaying the Audit Log.

April 2010

13

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.3 Configuration of Systems for Remote

Monitoring
To be able to use the DBA Cockpit to monitor remote systems, you have to configure those
systems in the DBA Cockpit. You can configure your database system either using database
information that is stored in the system landscape directory (SLD) for automatic generation
and update of system entries or manually using database connections and system entries.
You access the screen The DBA Cockpit: System Configuration Maintenance by choosing
System Configuration in the DBA Cockpit. A list of all monitored systems is displayed with an
icon showing the current status of a system. You can change the status of a system by
choosing Stop or Go.

In the event of severe errors, we recommend that you disable your system to
prevent further problems. After you have investigated and corrected the error,
you have to enable your system again.
Normally, when you start the DBA Cockpit, the local system is set as default system. To
change this setting, select a system from the list and choose Default System.

This setting only applies to the user currently logged on to the system. It is not a
system-wide setting.
You use one of the following methods to monitor a system remotely:
Remote database connections
This method uses additional connections. It is the main access method for monitoring
and administration tasks and is mandatory. You can specify remote connections for
any database and maintain the connections using the DBA Cockpit. For more
information, see Maintaining Database Connections.
RFC connection
For this method you have to assign an RFC connection to your system. RFC
connections are available for SAP ABAP systems only. You can use RFC connections:
As an optional access path for ABAP-related monitoring functions, for example,
for the consistency check of the ABAP Dictionary. That is, the DBA Cockpit uses
the RFC connection in parallel to the database connection for the same system.
MS SQL Server only:
For a database connection that is localized in another ABAP system. That is,
the DBA Cockpit can use the RFC connection together with the database
connection.

You can only maintain RFC connections with transaction SM59, not with the
DBA Cockpit.
More Information
Configuring Systems for Remote Monitoring Using Remote Database Connections
Configuring Systems for Remote Monitoring Using the System Landscape Directory (SLD)

14

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.3.1 Configuring Systems for Remote Monitoring Using

Remote Database Connections
You use this procedure to configure systems that you want to monitor using remote database
connections.

Depending on the database platform of the selected system, some options

might not be available. In this case, you cannot enter any data in the
corresponding fields.
Prerequisites
The system(s) you want to monitor must have a database release that is compatible
with the database release of your local database.
The user for the database connection must have sufficient database permissions. For
more information, see Maintenance Actions in the DBA Cockpit.
Procedure
Adding a System
...

1. Call the DBA Cockpit.

The screen DBA Cockpit: System Configuration Maintenance appears. It displays a list
of all systems available with a Stop, Go, or Inactive icon, which shows the current
system status.

When you start the DBA Cockpit for the first time, the local system is
automatically added to the list of all systems available. At least one system entry
is displayed.
2. Choose Add.
The screen Configuration: System Administration Add System Entry appears.
3. Specify the connection data as follows:
a. In the System field, enter the name of the system you want to monitor.

This name is a unique ID and does not need to be the SAP system ID. You can
choose any name except the SAP system ID of the local system, which is
reserved for the local system entry.
Except for the local system entry, Remote Database is already selected.
b. Select Database Connection.
Enter the name of the database connection. If the database connection does not
yet exist, you are directed to the DB Connections: Add Connection Entry screen
where you can specify all relevant data for the new connection. For more
information, see Configuration of Database Connections.
c. After you have saved your entries, you are redirected to the screen System
Administration Details.
d. If an additional RFC destination is used for special ABAP monitoring functions
or if the connection is initially routed using an RFC connection (MS SQL Server
only), select RFC Destination, too.

April 2010

15

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

e. If required, enter the name of the RFC connection.

After the connection data has been completed, it is displayed on the System Data tab
page. You can enter additional data on the Administration Data tab page as follows:
f. Enter a description of your system.
g. Depending on the database platform, select the options for how you want to
collect monitoring data:
If alerts are to be provided for the RZ20 alert monitor, select Collect Alert
Data.
If data about the performance or the size of database objects is to be
collected, select Collect Space and Performance History Data.
If the task of collecting monitoring data is running on the remote system,
select Data Collection by Remote System.
If data for the central planning calendar is to be provided, select Collect
Central Planning Calendar Data.
h. Save your changes.
Changing the Connection Parameters of a System
1. Perform step 1 as described above under Adding a System.
2. Select a system.
3. Choose Edit.
The screen Configuration: System Administration Change System Entry appears.
4. Enter your changes in the corresponding fields.
5. Save your changes.
Deleting a System Entry
...

1. Perform step 1 as described above under Adding a System.

2. Select a system.
3. Choose Delete.

1.1.3.1.1 Configuration of Database Connections

Purpose
This section describes how you set and maintain technical attributes for remote database
connections. The DBA Cockpit uses these connections for administration and monitoring or
for application programs that use secondary connections to external databases.

16

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Process Flow
...

1. You call the DBA Cockpit and choose DB Connections in the system landscape
toolbar.
The screen DBA Cockpit: Database Connections appears displaying a list of all
available database connection definitions grouped by database platform:
Column

Description

Remote Database
Connections

Name of database connection

This is a unique name that you can

freely choose.
DB Name

Name of database

DB Host

Name of database host

DB Schema

Name of the database schema to be monitored

User

Name of the connection user

Permanent

Specifies whether the connect user must be

permanently available

Max. Connections

Maximum allowed number of open connections

Opt. Connections

Optimal number of connections

By default, the database connections that are defined in the local system are displayed.
2. You are able to perform one of the following tasks:
You add database connections.
You change an existing database connection.
You delete a database connection.
You test a database connection.
See also:
Adding a Database Connection
Changing a Database Connection
Deleting a Database Connection
Testing a Database Connection

1.1.3.1.1.1 Adding a Database Connection

...

1. Call the DBA Cockpit.

2. In the system landscape toolbar, choose DB Connections.
3. Choose Add.
The screen DB Connections Add Connection Entry appears.

April 2010

17

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. In the Connection Name field, specify the name of the connection.

This name is a unique ID that you can choose freely except for names that are
reserved by SAP for generated connections. These can be, for example,
administrator connections or connections that are used by systems from the
system landscape directory (SLD).
5. Specify the database connection attributes as follows:
a. In the Database System field, specify the name of the database platform.
b. In the Connection Maximum field, enter an approprriate value. This value limits
the number of database connections that are currently held by the SAP system.
The SAP system does not let you exceed this limit.
c. In the Connection Optimum field, enter an appropriate value. This value is a
more flexible limit that can be exceeded.
d. If you want the connection to be mandatory for the SAP system, select
Permanent Connection. This parameter defines the availability of the database
connection.
It is then handled like the local default connection, that is, if this database
connection is not available for a work process, the work process of the SAP
system cannot run.

You should set this parameter only if this connection is absolutely required to
run your SAP system.
e. In the User Name field, enter the name of the connect user. Make sure that you
choose a user with the appropriate authorizations. For more information, see
Maintenance Actions in the DBA Cockpit.
f. In the Password field, enter a password for the connect user.
6. In the Connection Parameters table, specify the following additional database-specific
attributes:
Attribute

Description

Database Name

Name of database

Service Name

Name or number of the service

This value corresponds to the parameter
SVCENAME of the database manager configuration
(DBM) of the remote database.

Database Host

Name of the remote database server

Schema Name

Name of schema to be monitored

If you omit this field, the name of the

SAP connect user is used as schema.

18

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

To support new connection parameters and for support scenarios, you might
have to add connection parameters in an unchecked raw format. To be able to
do so, choose Guided Mode <-> Expert Mode and switch to the expert mode. In
the expert mode, you can enter connection parameters as a string instead of
using the guided mode. However, we do not recommend that you use the expert
mode.
7. To confirm your entries, choose Save.
Result
As soon as the connection has been specified, the DBA Cockpit connects automatically to the
newly added database system and displays data on the System Data tab page.

1.1.3.1.1.2 Changing a Database Connection

...

1. Call the DBA Cockpit.

2. In the system landscape toolbar, choose DB Connections.
Select a database connection entry and choose Edit.
The screen DB Connections Change Connection Entry appears.
3. Enter your changes in the appropriate fields as described in Adding a Database
Connection.
4. Save your changes.

1.1.3.1.1.3 Testing a Database Connection

You test a database connection to make sure that, for example, you entered the correct user
and password information as well as the correct technical connection data, such as host
name.
Procedure
...

1. Call the DBA Cockpit.

2. In the system landscape toolbar, choose DB Connections.
3. Select a system and choose Test.
The result is displayed in the message window below.

1.1.3.1.1.4 Deleting a Database Connection

...

1. Call the DBA Cockpit.

2. In the system landscape toolbar, choose DB Connections.
3. Select a system and choose Delete.

If the selected database connection is still in use by a system that is registered

in the DBA Cockpit, you cannot delete it.

April 2010

19

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.3.2 Configuring Systems for Remote Monitoring Using the

System Landscape Directory (SLD)
Use
The system landscape directory (SLD) contains data from all database systems available in
your system landscape. You can use this data to set up the system configuration in the DBA
Cockpit instead of setting it up manually.
When you set up the DBA Cockpit for the first time, you use this procedure to import the
appropriate data from the SLD. During production operation, you use the procedure to
synchronize the data between the SLD and the DBA Cockpit periodically.
Procedure
...

1. To import database connection data from the SLD, call the DBA Cockpit.
2. In the system landscape toolbar, choose System Configuration.
The screen The DBA Cockpit: System Configuration Maintenance appears.
3. Choose SLD System Import.
The SLD System Import screen appears. Depending on the system landscape, one or
more of the following nodes are displayed:
New Database Systems in the SLD
All database systems registered in the SLD that are so far unknown to the DBA
Cockpit are displayed.
Changed Systems From Earlier SLD Imports
All database systems for which the main data differs between the SLD and the
DBA Cockpit are displayed.
Systems No Longer Registered in the SLD
All systems that were originally imported from the SLD into the DBA Cockpit but
that are no longer registered in the SLD are displayed.
Systems Identical in the SLD and in the DBA Cockpit
All systems that are registered in the SLD and that are identical in the DBA
Cockpit are displayed.
Unsupported Database Systems in the SLD
All database systems that are registered in the SLD but not supported by the
DBA Cockpit are displayed.

Each database system is described as follows:

<Name (system ID) of the database system> on <main database
host> ( <database platform> )
The actions allowed for each database system are displayed in the second
column of the tree.
4. To import database system data, select the actions that you want to execute for the
selected database systems and choose Import. By default, only the import of new
database systems is selected.
The selected actions are executed. A short message for each executed action is
displayed in the message window below.

20

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Connection data that is retrieved from the SLD might not be complete for one of
the following reasons:
Depending on the data provided by a system to the SLD, some connection
data can be incomplete.
User or password data is generally not available via SLD.
When you establish the connection to an imported system, the DBA Cockpit
checks the completeness of a configured system. That is, if necessary, you are
prompted for user, password, and connection information.
If additional connection information is required, enter the required data
according to the maintenance dialog that is described in Configuration of
Database Connections.

1.2 Web Browser-Based User Interface (Web

Dynpro)
The Web browser-based user interface differs from the classical SAP GUI-based user
interface with regard to the overall screen layout and navigation, customizing of the user
interface and the provided functions.
To start the Web browser-based user interface, call the DBA Cockpit and choose Start
WebDynpro GUI, which starts the browser in a separate window. Like on the SAP GUI-based
user interface, the entry screen displays the list of the configured systems.
Caution
The Web browser-based user interface does not support all functions available
on the SAP GUI-based user interface; especially maintenance actions are not
provided. On the other hand, actions that have been introduced with DB2
Version 9.5 are available only on the Web browser-based user interface, for
example, workload management and performance warehouse (SAP NetWeaver
BW).
End of the caution.
Navigation and Screen Layout
The entry screen of the DBA Cockpit with the Web browser-based user interface is divided
into the following areas:

April 2010

21

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Common header area

Top level navigation including second-level navigation
Framew ork message w indow

Detail navigation

Central system data

System landscape
selector

Content area

Favorite list
Content detail area

Common Header Area

Provides a standard set of functions, for example, to refresh or to customize the layout.
Top Level Navigation Including Second-Level Navigation
In the top level navigation, you can switch between the following two areas:
Cross-system area
Provides information about the overall system landscape.
Database-specific area
Provides information about the selected database.
In the second-level navigation, the main task areas of database administration are
provided for this area, for example, performance monitoring, space management, and
job scheduling.

22

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Detail Navigation
Contains the main actions of the main task areas. Depending on the selected main action, a
subset of related actions is available.
Example
If you chose Performance in the top level navigation area, the following main actions are
available:
Inplace Table Reorganization
Performance Warehouse
Snapshots
History
If you choose Performance Warehouse, the subactions Reporting and Configuration become
available.
End of the example.
System Landscape Selector
Provides a quick overview of all configured systems. This area is described in more detail
under Customizing of the System Landscape Selector later in this section.
Favorite List
Contains a list of favorite links to special actions.
To provide quick access to specific actions, choose Personalize Add Favorite in the
common header area. An entry is added to your list of favorites. By choosing Personalize
Organize Favorites , you can rename or delete favorites.
Note
By default, the favorite list contains a link to the EXPLAIN Access Plan and to the SQL
Command Line. Both entries cannot be removed.
End of the note.
Framework Message Window
Displays the message window that is provided by the framework. Unlike the classic SAP GUI
message processing, this window contains a complete history of all messages that are sent
during the session.
In addition, you can:
Collapse or expand the window by choosing Expand Message Window or Collapse
Message Window.
Check if a long text for a message is available by double-clicking the message or by
choosing Details.

April 2010

23

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
By default, the message window is collapsed. When a new message is generated, it is
automatically expanded.
End of the note.
Central System Data
This area is common to most actions providing, for example, the time of the last refresh, the
startup time and the database name.
Content Area
Displays details of the currently selected action.
Content Detail Area
Only appears with certain actions and displays additional information that is related to the
selected action. Typically, this areas shows details that are related to some list display.
Customizing the System Landscape Selector
By default, all systems are displayed without any grouping or filtering. For each configured
system, the alert status, the name of the system and its database host is displayed. The
following menu buttons are available for the list of systems:
Refresh System Landscape
You can refresh the information about the available systems in the list.
Group Systems by Selected Criteria
You can customize the displayed list of systems by grouping them according to the
selected criteria:
o

Database Platform

Name

Custom

Alerts

To use a custom grouping, you must first define and add a custom group to the list.
To do so, choose Add Group... from the pop-up menu of the menu button Group
Systems by Selected Criteria. Specify a name for the custom group and assign the
systems of your choice.
As soon as you have added a custom group, the option Organize Groups becomes
available in the pop-up menu of the menu button Group Systems by Selected
Criteria, which lets you maintain an already existing group.

24

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Filter Systems by Selected Criteria

You can filter the list of available systems to show only those systems that match the
filter criteria. You filter, for example, by the alert status of the systems.
Search Systems
Provides an input field where you can search for a specific system in the list.
More Information
The EXPLAIN Function [page 199]
SQL Command Line [page 213]

April 2010

25

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2 Performance
The following sections provide information on performance:
Performance: Partitions
Performance: Database
Performance: Schemas
Performance: Buffer Pools
Performance: Tablespaces
Performance: Tables
Performance: Application
Performance: SQL Cache
Performance: Lock Waits and Deadlocks
Performance: Inplace Table Reorganization
Performance: History Database
Performance: History Tables
Performance: Performance Warehouse

2.1 Performance: Partitions

In mult partition database systems this overview screen provides a selection of performance
data that is related to each partition. You can use the information to identify performancecritical partitions before starting a more detailed analysis of your database.
You can access the Partition Overview screen by calling the DBA Cockpit and choosing
Performance Partitions in the navigation frame of the DBA Cockpit.
For each partition of your database system, the following information is displayed:
Column

Description

Partition

Number of the partition (only displayed in a multi partition database)

No. Buffer Pools

Number of buffer pools used for a partition

Total Size Buffer Pools Total size in KB of all buffer pools used for a partition
Data Logical Reads

Number of read accesses to data in the buffer pool

Index Logical Reads

Number of read accesses to index data in the buffer pool

26

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Number of read accesses to data on disk (I/O)

Data Physical Reads

The value includes the number of physical reads that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O servers).
Number of read accesses to index data on disk (I/O)

Index Physical Reads

Since index data is read only by the database manager agents, this
value includes the number of synchronously read index pages.

Avg. Phys. Read Time

(ms)

Average time in milliseconds required to read data from disk into the
buffer pool

Avg. Phys. Write Time

(ms)

Average time in milliseconds required to write data from the buffer

pool to disk

Executed SQL
Statements

Number of executed SQL statements (SELECT, INSERT, UPDATE,

DELETE)
Amount of application heap memory to be used for caching a
packages static and dynamic SQL statements

Package Cache Size

As of DB2 Version 5, each database agent accesses a global
cache.
Tells you whether or not the package or catalog cache is being used
Package Cache Quality
effectively. If the hit ratio of the package or catalog cache is greater
(%)
than 95%, the cache is performing well.
Note
If you double-click a line, database snapshot data is retrieved and displayed as described in
Performance: Database.

2.2 Performance: Database

The Database Snapshot screen provides an overview of the following critical database
performance indicators:
Buffer pool
Cache
Asynchronous I/O
Direct I/O
Real-time statistics
Locks and deadlocks
Logging

April 2010

27

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Calls
Sorts
XML storage
You can access the Database Snapshot screen by calling the DBA Cockpit and choosing
Performance Database in the navigation frame of the DBA Cockpit.
The Database Snapshot screen is the initial screen of the SAP database monitor for DB2 for
Linux, UNIX, and Windows. The system displays values collected since the database was
started. If the database is shut down, the values are deleted.
Note
The values displayed are not really meaningful until the database has been running for some
time. The longer the database has been running, the more useful the values.
End of the note.

2.2.1 Database: Buffer Pool

To display an overview of buffer pool information, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Buffer Pool.
Field

Description

Buffer Pools
Number

Number of buffer pools

Total Size

Total size in KB of all buffer pools

Buffer Quality
Indicates percentage at which the data is read from the buffer
pool, rather than directly from the hard disk
Overall Buffer Quality
This is calculated using the following formula: (logical reads physical reads) / (logical reads) * 100
Data Hit Ratio

Indicates percentage at which data (without index data) is read

from the buffer pool, rather than directly from the hard disk

Index Hit Ratio

Indicates the frequency as a percentage at which index data is

read from the buffer pool, rather than directly from the hard disk

No Victim Buffers

Number of times an agent did not have a preselected victim

buffer available

28

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Average Time
Physical Reads

Average time in milliseconds required to read data from disk into

the buffer pool

Physical Writes

Average time in milliseconds required to write data from the

buffer pool to disk

Data
Logical Reads

Number of read accesses to data in the buffer pool

Number of read accesses to data on disk (I/O)

Physical Reads

The value includes the number of physical reads that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O servers).
Number of write accesses to data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to data on disk (by agents)

Synchronous Writes

Number of write accesses to data on disk (by agents)

Temporary Logical Reads

Number of logical read requests that required I/O to get data

pages into the temporary tablespace

Temporary Physical Reads

Number of physical read requests that required I/O to get data

pages into the temporary tablespace

Index
Logical Reads

Number of read accesses to index data in the buffer pool

Number of read accesses to index data on disk (I/O)

Physical Reads

Since index data is read only by the database manager agents,

this value includes the number of synchronously read index
pages.
Number of write accesses to index data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to index data on disk (by agents)

April 2010

29

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Synchronous Writes

Number of write accesses to index data on disk (by agents)

Temporary Logical Reads

Number of logical read requests that required I/O to get index

pages into the temporary tablespace

Temporary Physical Reads

Number of physical read requests that required I/O to get index

pages into the temporary tablespace

Note
Data is read or written in pages. A page can be 4 KB, 8 KB, 16 KB, or 32 KB in size.
Unless otherwise specified, no distinction is made between synchronous and asynchronous
accesses.
End of the note.

2.2.2 Database: Cache

To display information on the cache, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Cache.
Field

Description

Catalog Cache
Maximum allowed size in KB for the catalog cache

Size

The catalog cache is accessed each time a transaction accesses a

table, view, or alias. The cache is allocated dynamically from the
heap.
The maximum allowed size is determined by database
configuration parameter CATALOGCACHE_SZ.
Indicates percentage at which the data is read from the catalog
cache, rather than directly from the hard disk

Quality
This is calculated using the following formula: (catalog cache
lookups - catalog cache inserts) / catalog cache lookups * 100
Lookups

30

Number of times that the catalog cache was referenced to obtain

table descriptor information

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Inserts

Number of times that the system tried to insert table descriptor

information into the catalog cache

Overflows

Number of times that an insert into the catalog cache failed due to
the catalog cache being full

High-Water Mark

Largest size reached by package cache

Package Cache
Maximum allowed size in KB for the package cache
The package cache contains access plans. The maximum allowed
size is determined by database configuration parameter
PCKCACHESZ.

Size

Indicates percentage at which the data is read from the package

cache, rather than directly from the hard disk
Quality
This is calculated using the following formula: (package cache
lookups - package cache inserts) / package cache lookups *100
Lookups

Number of times an application looked for a section in the package

cache

Inserts

Total number of times that an access plan was not available for
use and had to be loaded into the package cache

Overflows

Number of times that the package cache overflowed the bounds of

its allocated memory

High-Water Mark

Largest size reached by the package cache

2.2.3 Database: Asynchronous I/O

To display information on I/O servers and I/O cleaners, call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Database.

The Database Snapshot screen appears.

2. Choose Asynchronous I/O.
Field

Description

I/O
Number of I/O Servers

April 2010

Number of I/O servers that read data

asynchronously from the hard disk into the
buffer pool

31

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Number of I/O Cleaners

Number of I/O cleaners that write data

asynchronously from the buffer pool to the
hard disk

Average Time
Asynchronous Physical
Reads

Average time in milliseconds required by

the I/O servers to read a page from disk
and write it to the buffer pool

Asynchronous Physical
Writes

Average time in milliseconds required by

the I/O cleaners to read a page from the
buffer pool and write it to the hard disk

Data
Asynchronous Physical
Reads

Number of data pages that were read

asynchronously from disk and written to the
buffer pool by the I/O servers (prefetch)

Asynchronous Physical
Writes

Number of data pages that were written

asynchronously from buffer pool to disk (I/O
cleaners)

Asynchronous Read
Requests

Number of asynchronous data read

requests

Index
Asynchronous Physical
Reads

Number of index pages that were read

asynchronously from disk and written to the
buffer pool by the I/O servers (prefetch)

Asynchronous Physical
Writes

Number of index pages that were written

asynchronously from buffer pool to disk (I/O
cleaners)

Asynchronous Read
Requests

Number of asynchronous index read

requests

Data is read or written in pages. A page can be 4 KB, 8 KB, 16 KB, or 32 KB in

size.

2.2.4 Database: Direct I/O

To display information on direct I/O, call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Database.

The Database Snapshot screen appears.

2. Choose Direct I/O.
Field

Description

Average Time
Direct Reads

32

Average time in milliseconds required to

read directly from disk

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Direct Writes

Average time in milliseconds required to

write directly to disk

I/O
Direct Reads

Read accesses from disk that do not use

the buffer pool (LONG VARCHAR fields,
backup)

Direct Writes

Write accesses to disk that do not use the

buffer pool (LONG VARCHAR fields,
restore, load)

Average I/O per Request

Direct Reads

Average number of requests to read

directly from disk

Direct Writes

Average number of requests to write

directly to disk

2.2.5 Database: Real-Time Statistics

To display information on real-time statistics, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Real-Time Statistics.
Field

Description

Size of Statistics Cache

Size of statistics cache in bytes

Number of Asynchronously
Collected Statistics

Total number of successful asynchronous statistics

collection activities

Total number of statistics collection activities for creating

Number of Statistics Collections
statistics by the system without table or index scan during
During Query Compilation
query compilation
Time Spent During Query
Compilation

Total time spent on creating statistics by system without

table or index scan during query compilation in milliseconds

Number of Synchronously
Collected Statistics

Total number of synchronous statistics collection activities

during query compilation

Time Spent on Synchronous

Statistics Collection Activities

Total time spent on synchronous statistics collection

activities in milliseconds

April 2010

33

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.2.6 Database: Locks and Deadlocks

To display information on locks and deadlocks, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Locks and Deadlocks.
Field

Description

Lock List

Size

Database locks are managed in a list. This parameter determines

the maximum length of the list (database configuration parameter
LOCKLIST). The lock list is allocated dynamically.

In Use

Current size of the lock list

Lock Waits
Total

Total number of times that applications or connections waited for

locks

Time Waited

Total amount of elapsed time in milliseconds that applications

waited for a lock to be granted

Average Time Waited

Average time in milliseconds waited for a lock

Escalations
Number of times that locks have been escalated from several row
locks to a table lock
Lock Escalations

Exclusive Lock
Escalations

If the maximum allowed length of the lock list is reached, row

locks are converted to table locks to save space in the lock list.
This process is called lock escalations
Number of times that locks have been escalated from several row
locks to one exclusive table lock, or the number of times an
exclusive lock on a row caused the table lock to become an
exclusive lock
Exclusive locks are important to track since they can impact the
concurrency of your data because other applications cannot
access data held by an exclusive lock.

Locks
Locks Currently Held

Total number of locks currently held by the applications

Deadlocks Detected

Number of deadlocks that have occurred

34

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Deadlock situations are recognized and resolved automatically by
the database. The database configuration parameter lock
escalations determines when a lock wait situation is resolved.
Number of times that a request to lock an object timed out instead
of being granted

Lock Timeouts
Parameter lock escalations determines when a lock wait situation
is resolved.

2.2.7 Database: Logging

To display information on log files, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot appears.

2. Choose Logging.
Field

Description

Log Files
Number of primary log files
Primary

The database configuration parameter LOGPRIMARY

determines this value.
Number of secondary log files

Secondary

The database configuration parameter LOGSECOND

determines this value.
Number of pages in each log file

Size

The database configuration parameter LOGFILSIZ

determines this value. Each page has 4 KB.

Total Log
Available to Database

Amount of primary log space in bytes in the database that is

not being used by uncommitted transactions

Used by Database

Total amount of primary log space in bytes currently used in

the database

Maximum Space Used

Maximum amount of primary log space used in bytes

April 2010

35

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Node with the least amount of available log space in Bytes

Node with Least Available

Space

Note
This field is only displayed for global snapshots over all
partitions.
End of the note.

Application with Oldest

Transaction

Application ID (that corresponds to the agent_id value from

the application snapshot) of the application that has the oldest
transaction

Secondary Log
Logs Currently Allocated

Total number of secondary log files that are currently being

used for the database

Maximum Space Used

Maximum amount of secondary log space used in bytes

Log Pages
Read

Number of log pages read from disk

Written

Number of log pages written to disk

Log Buffer Consumption

LSN Gap

Percentage of log space held by dirty pages in relation to log

space specified by parameter SOFTMAX

Restart Range

Percentage of log space held that will have to be redone for

crash recovery pages in relation to log space specified by
parameter SOFTMAX

Log Buffer Quality

Log Buffer Hit Ratio

Ratio of log data read from the buffer in relation to log data
read from disk
Number of times that agents have to wait for log data to write
to disk while copying log records into the log buffer

Log Buffer Overflows

36

This value is incremented per agent per incident. For example,

if two agents attempt to copy log data while the buffer is full,
then this value is incremented by two.

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Log Buffer I/O

Average Write Time/Page

Average time per page in microseconds required to write log

data to disk

Average Write Time/IO

Average time per I/O in microseconds required to write log

data to disk

Average Read Time/Page

Average time per page in microseconds required to read log

data from disk

Average Read Time/IO

Average time per I/O in microseconds required to read log

data from disk

2.2.8 Database: Calls

To display information on calls, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Calls.
Field

Description

Rows
Read

Number of data records that were read

Selected

Number of data records that were selected

Deleted

Number of data records that were deleted

Inserted

Number of data records that were inserted

Updated

Number of data records that were updated

Ratio of rows read from the base table compared to rows
processed, which can be either rows returned to the application
(SELECT statements) or rows written (UPDATE, INSERT,
DELETE statements)

Rows Read / Rows

Processed

A value of 1 indicates an optimal access to the requested data.

High values indicate statements with an inefficient access.
Note
End of the note.
This metric is only available if your database is DB2 V9.5 for

April 2010

37

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Linux, UNIX, and Windows Fix Pack 1 or higher.
Average number of pages read from the buffer pool per rows
processed, which can be either rows returned to the application
(SELECT statements) or rows written (UPDATE, INSERT,
DELETE statements)

BP Gets / Rows Processed

Note
This metric is only available if your database is DB2 V9.5 for
Linux, UNIX, and Windows Fix Pack 1 or higher.
End of the note.

Statements Executed
SELECT SQL

Number of SELECT statements that were executed

UPDATE/INSERT/DELETE

Number of UPDATE, INSERT, and DELETE statements that

were executed

DDL

Number of Data Definition Language (DDL) statements that

were executed, for example, CREATE TABLE, CREATE VIEW,
ALTER TABLE, and DROP INDEX

Elapsed Time (sec)

Sum of the host execution times in seconds for all the

statements that were executed

Elapsed Time (microsec)

Remaining part of the above elapsed time in microseconds

Statements Attempted
COMMITs

Number of COMMIT statements that have been attempted

Number of ROLLBACK statements that have been attempted

Rollbacks

Automatic rollbacks caused by error situations or deadlocks are

not included.

Dynamic SQL

Number of dynamic SQL statements attempted

Static SQL

Number of static SQL statements attempted

Failed SQL

Number of attempted SQL statements that failed

38

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Hash Joins
Total

Total number of hash joins executed

Total Hash Loops

Total number of times that a single partition of a hash join was

larger that the available sort heap space

Overflows

Number of times that hash join data exceeded the available sort
heap space

Small Overflows

Number of times that hash join data exceeded the available sort
heap space by less than 10%
Total number of hash joins that were throttled back by the sort
memory throttling algorithm

Post Threshold

A throttled hash join is a hash join that was granted less memory
than requested by the sort memory manager. A hash join is
throttled back when the memory allocation from the shared sort
heap is close to the limit set by database configuration
parameter sheapthres_shr.
This throttling significantly reduces the number of overflows over
thesheapthres_shr limit in a system that is not properly
configured. The data reported in this element only reflects hash
joins using memory allocated from the shared sort heap.

2.2.9 Database: Sorts

To display information on sorts, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose Sorts.
Field

Description

Sort Heap
Total Size

Amount of memory in KB available for each sort as defined in

the database configuration parameter SORTHEAP (in pages)

Allocated

Total number of allocated space of sort heap space for all

sorts at the level chosen and at the time the snapshot was
taken

April 2010

39

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Sort Time
Total

Total time in milliseconds required for all sort processes

Average

Average sort time in milliseconds

Sorts
Total Sorts

Total number of sorts that have been executed

Sort Overflows

If the storage area allocated for sorting is not large enough, a

sort overflow occurs. The hard disk is then used temporarily.

Active Sorts

Number of sorts in the database that currently have a sort

heap allocated

Post Threshold Sorts

Total number of sorts that were throttled back by the sort

memory throttling algorithm. A throttled sort is a sort that was
granted less memory than requested by the sort memory
manager. A sort is throttled back when the memory allocation
for sorts is close to the limit set by database configuration
parameter sheapthres_shr. This throttling significantly
reduces the number of overflows over sheapthres_shr limit
in a system that is not properly configured.
The data reported in this element only reflects sorts using
memory allocated from the shared sort heap.

2.2.10 Database: XML Storage

To display information on XML storage accesses, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Database

The Database Snapshot screen appears.

2. Choose XML Storage.
Field

Description

Pool Data

40

Logical Reads

Indicates the number of data pages for XML storage objects (XDAs)
that have been requested from the buffer pool (logical reads) for
regular and large tablespaces

Physical Reads

Indicates the number of data pages for XML storage objects (XDAs)
that have been read from the tablespace containers (physical reads)
for regular and large tablespaces

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk

Write Accesses
Temporary Data

Logical Reads

Indicates the number of pages for XML storage objects (XDA) that
have been requested from the buffer pool (logical reads) for
temporary tablespaces.

Physical Reads

Indicates the number of pages for XML storage objects that have
been (XDA) read from the tablespace containers (physical reads) for
temporary tablespaces

Asynchronous I/O

Physical Reads

Physical Writes

Indicates the number of XML storage object (XDA) data pages that
have been read in from the tablespace containers (physical reads)
by asynchronous engine dispatchable units (EDUs) for all types of
tablespaces.
Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk by either an
asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for
the pages being prefetched.

Read Requests

Indicates the number of asynchronous read requests for XML

storage object (XDA) data

2.3 Performance: Schemas

If more than one SAP component is installed within the same database, this overview screen
provides a selection of performance data that is related to these components. You can use
the information displayed to identify performance-critical components and the workload
distribution among the components.
You can access the Performance: Schema Overview screen by calling the DBA Cockpit and
choosing Performance Schemas in the navigation frame of the DBA Cockpit.
For each component (and partition if you are using a mult partition database), the following
information is displayed:
Column

Description

User

Name of connect user to identify the component

Partition

Number of the partition (only displayed in a multi partition

database)

April 2010

41

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

SAP Component

Indicates if the connect user is related to an SAP component or

another user that is just connected to the database

Data Logical Reads

Number of read accesses to data in the buffer pool

Data Logical Reads (%)

Indicates the percentage of logical data read accesses for the

component (and partition if you are using a multi partition
database)

Index Logical Reads

Number of read accesses to index data in the buffer pool

Indicates the percentage of index logical data read accesses for

Index Logical Reads (%) the component (and partition if you are using a multi partition
database)
Number of read accesses to data on disk (I/O)
Data Physical Reads

The value includes the number of physical reads that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O servers).

Indicates the percentage of physical data read accesses for the

Data Physical Reads (%) component (and partition if you are using a multi partition
database)
Number of read accesses to index data on disk (I/O)
Index Physical Reads

Index Physical Reads

(%)

Since index data is only read by the database manager agents,

this value includes the number of synchronously read index pages.
Indicates the percentage of index physical read accesses for the
component (and partition if you are using a multi partition
database)

2.4 Performance: Buffer Pools

The Buffer Pool Snapshot screen provides an overview of the following important key
indicators of the buffer pool activity of your database and enables you to compare these key
indicators:
Buffer Pool Name
Buffer Pool Size (KB)
Automatic Size (Yes or No)
Buffer Quality (%)
Data Logical Reads
Data Physical Reads

42

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Index Logical Reads

Index Physical Reads
Temporary Data Logical Reads
Temporary Data Physical Reads
Temporary Index Logical Reads
Temporary Index Physical Reads
You can access the Buffer Pool Snapshot screen by calling the DBA Cockpit and choosing
Performance Buffer Pools in the navigation frame of the DBA Cockpit.
You can display more detailed information by selecting one or more buffer pools and
choosing Details. A detail Buffer Pool Snapshot screen appears with information on:
Buffer pools
Asynchronous I/O
Direct I/O
XML storage
Displaying the History of the Buffer Pool Quality
To retrieve information about the past changes to the size and quality of the selected buffer
pool, choose History.
Caution
To be able to display a value history, the function must be switched on first by selecting
Collect History Data when you configured your database for remote monitoring. For more
information, see Configuring Systems for Remote Monitoring Using Remote Database
Connections.
End of the caution.
The result for a parameter is displayed in a separate window. By default, the value history
information is displayed as a chart. By choosing List, you can switch to a tabular view. To limit
the history time frame, choose From or To.

2.4.1 Buffer Pool

To display information on buffer pool activity for your selected buffer pool(s), call the DBA
Cockpit.
1. In the navigation frame, choose

Performance

Buffer Pools

The Buffer Pool Snapshot screen appears.

2. To display more detailed information, select one or more buffer pools and choose
Details.
A detail Buffer Pool Snapshot screen appears.

April 2010

43

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3. Choose Buffer Pool.

If you have selected more than one buffer pool, you can use the page buttons on the screen
to navigate between them.
Field

Description

Buffer Pool
Name

Name of the buffer pool

Size of the buffer pool in KB and in pages
Caution

Current Size
If Automatic is selected, the buffer pool is automatically tuned (if
DB2's Self Tuning Memory Management was activated).
End of the caution.
New Size

Size of the buffer pool in pages after a database restart

Pages Left to Remove

Number of pages that are still to be removed

Tablespace Use Count

Number of tablespaces that belong to this buffer pool

Buffer Quality
Indicates percentage at which the data is read from the buffer
pool, rather than directly from the hard disk
Overall Buffer Quality
This is calculated using the following formula: (logical reads physical reads) / (logical reads) * 100
Data Hit Ratio

Indicates percentage at which only data (without index data) is

read from the buffer pool, rather than directly from the hard disk

Index Hit Ratio

Indicates percentage at which index data is read from the buffer

pool, rather than directly from the hard disk

Average Time
Physical Reads

Average time in milliseconds required to read data from disk into

the buffer pool

Physical Writes

Average time in milliseconds required to write data from the buffer

pool to disk

Data
Logical Reads

Number of read accesses to data in the buffer pool

Physical Reads

Number of read accesses to data on disk (I/O)

44

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
The value includes the number of physical reads that were
performed synchronously (by the database manager agents) and
asynchronously (by the I/O servers).
Number of write accesses to data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to data on disk (by agents)

Synchronous Writes

Number of write accesses to data on disk (by agents)

Temporary Logical Reads

Number of logical read requests that required I/O to get data

pages into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get data

pages into the temporary tablespace

Index
Logical Reads

Number of read accesses to index data in the buffer pool

Number of read accesses to index data on disk (I/O)

Physical Reads

Since index data is read only by the database manager agents,

this value includes the number of synchronously read index pages.
Number of write accesses to index data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to index data on disk (by agents)

Synchronous Writes

Number of write accesses to index data on disk (by agents)

Temporary Logical Reads

Number of logical read requests that required I/O to get index

pages into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get index

pages into the temporary tablespace

April 2010

45

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.4.2 Buffer Pools: Asynchronous I/O

To display information on asynchronous I/O for your selected buffer pool(s), call the DBA
Cockpit.
...

1. In the navigation frame, choose Performance

Buffer Pools.

The Buffer Pool Snapshot screen appears.

2. To display more detailed information, select one or more buffer pools and choose
Details.
A detail Buffer Pool Snapshot screen appears.
3. Choose Asynchronous I/O.
If you have selected more than one buffer pool, you can use the page buttons on the screen
to navigate between them.
Field

Description

Average Time
Asynchronous Physical
Reads

Average time in milliseconds required by the I/O

servers to read a page from disk and write it to the
buffer pool

Asynchronous Physical
Writes

Average time in milliseconds required by the I/O

cleaners to read a page from the buffer pool and
write it to the hard disk

Data
Asynchronous Physical
Reads

Number of data pages that were read

asynchronously from disk and written to the buffer
pool by the I/O servers (prefetch)

Asynchronous Physical
Writes

Number of data pages that were written

asynchronously from buffer pool to disk (I/O
cleaners)

Asynchronous Read
Requests

Number of asynchronous data read requests

Index
Asynchronous Physical
Reads

Number of index pages that were read

asynchronously from disk and written to the buffer
pool by the I/O servers (prefetch)

Asynchronous Physical
Writes

Number of index pages that were written

asynchronously from buffer pool to disk (I/O
cleaners)

Asynchronous Read
Requests

Number of asynchronous index read requests

Data is read or written in pages. A page can be 4 KB, 8 KB, 16 KB, or 32 KB in

size.

46

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.4.3 Buffer Pools: Direct I/O

To display information on direct I/O for your selected buffer pool(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Buffer Pools.

The Buffer Pool Snapshot screen appears.

2. To display more detailed information, select one or more buffer pools and choose
Details.
A detail Buffer Pool Snapshot screen appears.
3. Choose Direct I/O.
If you have selected more than one buffer pool, you can use the page buttons on the screen
to navigate between them.
Field

Description

Average Time
Direct Reads

Average time in milliseconds required to read

directly from disk

Direct Writes

Average time in milliseconds required to write

directly to disk

I/O
Direct Reads

Read accesses from disk that do not use the

buffer pool (LONG VARCHAR fields, backup)

Direct Writes

Write accesses to disk that do not use the

buffer pool (LONG VARCHAR fields, restore,
load)

Average I/O per Request

Direct Reads

Average number of requests to read directly

from disk

Direct Writes

Average number of requests to write directly

to disk

2.4.4 Buffer Pools: XML Storage

To display information on XML storage accesses for the selected buffer pool(s), call the DBA
Cockpit.
1. In the navigation frame, choose

Performance

Buffer Pools

The Buffer Pool Snapshot screen appears.

2. To display more detailed information, select one or more buffer pools and choose
Details.
A detail Buffer Pool Snapshot screen appears.

April 2010

47

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3. Choose XML Storage.

If you have selected more than one buffer pool, you can use the page buttons on the
screen to navigate between them.
Field

Description

Pool Data

Logical Reads

Indicates the number of data pages for XML storage objects

(XDAs) that have been requested from the buffer pool (logical
reads) for regular and large tablespaces

Physical Reads

Indicates the number of data pages for XML storage objects

(XDAs) that have been read from the tablespace containers
(physical reads) for regular and large tablespaces

Write Accesses

Indicates the number of times a buffer pool data page for an

XML storage object (XDA) was physically written to disk

Temporary Data

Logical Reads

Indicates the number of pages for XML storage objects (XDA)

that have been requested from the buffer pool (logical reads) for
temporary tablespaces.

Physical Reads

Indicates the number of pages for XML storage objects that have
been (XDA) read from the tablespace containers (physical
reads) for temporary tablespaces

Asynchronous I/O

Physical Reads

Physical Writes

Indicates the number of XML storage object (XDA) data pages

that have been read in from the tablespace containers (physical
reads) by asynchronous engine dispatchable units (EDUs) for all
types of tablespaces.
Indicates the number of times a buffer pool data page for an
XML storage object (XDA) was physically written to disk by
either an asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space
for the pages being prefetched.

Read Requests

48

Indicates the number of asynchronous read requests for XML

storage object (XDA) data

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.5 Performance: Tablespaces

The Tablespace Snapshot screen provides an overview of the following tablespace activities
of your database:
Tablespace Name
Partition (DPF systems only)
Buffer Quality (%)
Avg. Physical Read Times (ms)
Avg. Physical Write Time (ms)
Data Logical Reads
Data Physical Reads
Index Logical Reads
Index Physical Reads
You can access the Tablespace Snapshot screen by calling the DBA Cockpit and choosing
Performance Tablespaces in the navigation frame of the DBA Cockpit.
The screen displays buffer pool activity and direct access information for each tablespace
defined for the SAP database.
You can display more detailed information by selecting one or more tablespaces and
choosing Details. A detail Tablespace Snapshot screen appears with information on:
Buffer pool
Asynchronous I/O
Direct I/O
XML storage
Buffer Pool and Asynchronous I/O provide information on buffer pool access.
Direct I/O and XML Storage provide information on direct accesses, in other words, I/O
activity that does not use the buffer pool (for example, access to LONG VARCHAR columns
or backup).

2.5.1 Tablespaces: Buffer Pool

To display information on buffer pool activity for your selected tablespace(s), call the DBA
Cockpit.
1. In the navigation frame, choose

Performance

Tablespaces

The Tablespace Snapshot screen appears.

April 2010

49

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2. To display more detailed information, select one or more tablespaces and choose
Details.
A detail Tablespace Snapshot screen appears.
3. Choose Buffer Pool.
If you have selected more than one tablespace, you can use the page buttons on the screen
to navigate between them.
Field

Description

Tablespace
Name

Name of the tablespace

Buffer Quality
Buffer Pool

Name of the buffer pool that is associated with the selected

tablespace
Indicates percentage at which the data is read from the buffer pool,
rather than directly from the hard disk

Overall Buffer Quality

This is calculated using the following formula: (logical reads physical reads) / (logical reads) * 100
Data Hit Ratio

Indicates percentage at which data (without index data) is read from

the buffer pool, rather than directly from the hard disk

Index Hit Ratio

Indicates percentage at which index data is read from the buffer

pool, rather than directly from the hard disk

No Victim Buffer

Number of times an agent did not have a preselected victim buffer

available

Average Time
Physical Reads

Average time in milliseconds required to read data from disk into the
buffer pool

Physical Writes

Average time in milliseconds required to write data from the buffer

pool to disk

Data
Logical Reads

Number of read accesses to data in the buffer pool

Number of read accesses to data on disk (I/O)

Physical Reads

50

The value includes the number of physical reads that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O servers).

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Number of write accesses to data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to data on disk (by agents)

Synchronous Writes

Number of write accesses to data on disk (by agents)

Temporary Logical
Reads

Number of logical read requests that required I/O to get data pages
into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get data

pages into the temporary tablespace

Index
Logical Reads

Number of read accesses to index data in the buffer pool

Number of read accesses to index data on disk (I/O)

Physical Reads

Since index data is read only by the database manager agents, this
value includes the number of synchronously read index pages.
Number of write accesses to index data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O cleaners).

Synchronous Reads

Number of read accesses to index data on disk (by agents)

Synchronous Writes

Number of write accesses to index data on disk (by agents)

Temporary Logical
Reads

Number of logical read requests that required I/O to get index pages
into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get index

pages into the temporary tablespace

2.5.2 Tablespaces: Asynchronous I/O

To display information on asynchronous I/O for your selected tablespace(s), call the DBA
Cockpit.
...

1. In the navigation frame, choose Performance

Tablespaces.

The Tablespace Snapshot screen appears.

April 2010

51

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2. To display more detailed information, select one or more tablespaces and choose
Details.
A detail Tablespace Snapshot screen appears.
3. Choose Asynchronous I/O.
If you have selected more than one tablespace, you can use the page buttons on the screen
to navigate between them.
Field

Description

Average Time
Asynchronous Physical Reads

Average time in milliseconds required by the I/O

servers to read a page from disk and write it into
the buffer pool

Asynchronous Physical Writes

Average time in milliseconds required by the I/O

cleaners to read a page from the buffer pool and
write it to the hard disk

Data
Asynchronous Physical Reads

Number of data pages that were read

asynchronously from disk and written to the buffer
pool by the I/O servers (prefetch)

Asynchronous Physical Writes

Number of data pages that were written

asynchronously from buffer pool to disk (I/O
cleaners)

Asynchronous Read Requests

Number of asynchronous data read requests

Index
Asynchronous Physical Reads

Number of index pages that were read

asynchronously from disk and written to the buffer
pool by the I/O servers (prefetch)

Asynchronous Physical Writes

Number of index pages that were written

asynchronously buffer pool to disk (I/O cleaners)

Asynchronous Read Requests

Number of asynchronous index read requests

2.5.3 Tablespaces: Direct I/O

To display information on direct I/O for your selected tablespace(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Tablespaces.

The Tablespace Snapshot screen appears.

2. To display more detailed information, select one or more tablespaces and choose
Details.
A detail Tablespace Snapshot screen appears.
3. Choose Direct I/O.

52

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you have selected more than one tablespace, you can use the page buttons on the screen
to navigate between them.
Field

Description

Average Time
Direct Reads

Average time in milliseconds required to read

directly from disk

Direct Writes

Average time in milliseconds required to write

directly to disk

I/O
Direct Reads

Read accesses from disk that do not use the

buffer pool (LONG VARCHAR fields, backup)

Direct Writes

Write accesses to disk that do not use the buffer

pool (LONG VARCHAR fields, restore, load)

Average I/O per Request

Direct Reads

Average number of requests to read directly

from disk

Direct Writes

Average number of requests to write directly to

disk

2.5.4 Tablespaces: XML Storage

To display information on XML storage for the selected tablespace(s), call the DBA Cockpit
1. In the navigation frame, choose

Performance

Tablespaces

A detail Tablespace Snapshot screen appears.

2. To display more detailed information, select one or more tablespaces and choose
Details.
A detail Tablespace Snapshot screen appears.
3. Choose XML Storage.
If you have selected more than one tablespace, you can use the page buttons on the
screen to navigate between them.
Field

Description

Pool Data

Logical Reads

Indicates the number of data pages for XML storage objects

(XDAs) that have been requested from the buffer pool (logical
reads) for regular and large tablespaces

Physical Reads

Indicates the number of data pages for XML storage objects

(XDAs) that have been read from the tablespace containers
(physical reads) for regular and large tablespaces

April 2010

53

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field
Write Accesses

Description
Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk

Temporary Data

Logical Reads

Indicates the number of pages for XML storage objects (XDA)

that have been requested from the buffer pool (logical reads) for
temporary tablespaces.

Physical Reads

Indicates the number of pages for XML storage objects that have
been (XDA) read from the tablespace containers (physical reads)
for temporary tablespaces

Asynchronous I/O

Physical Reads

Physical Writes

Indicates the number of XML storage object (XDA) data pages

that have been read in from the tablespace containers (physical
reads) by asynchronous engine dispatchable units (EDUs) for all
types of tablespaces.
Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk by either an
asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space
for the pages being prefetched.

Read Requests

Indicates the number of asynchronous read requests for XML

storage object (XDA) data

2.6 Performance: Tables

The Table Snapshot screen displays information on all tables of the database, such as the
number of rows read, the number of rows written, the number of accesses to rows that have
been moved out of the page due to overflow (Overflow Access) and page reorganizations
(Page Reorgs).
You can access the Table Snapshot screen by calling the DBA Cockpit and choosing
Performance Tables in the navigation frame of the DBA Cockpit.
The following information is displayed:
Column

Description

Table Schema

Name of the schema

Table Name

Name of the table

54

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Partition

Number of the partition (only displayed in a multi partition

database)

Table File ID

File ID (FID) of the table

Table Type

Type of table for which information is displayed, for example,

user, system, or temp

Rows Written

Number of rows changed (inserted, deleted, or updated) in the

table

Rows Read

Number of rows read from the table

Number of accesses (reads and writes) to overflowed rows of
the table
Overflowed rows indicate that data fragmentation has
occurred. If this number is high, you may be able to improve
table performance by reorganizing the table using the REORG
utility, which cleans up this fragmentation.

Overflow Access
Note
Pay particular attention to this column. If the value in this
column is very high, you should consider reorganizing the
table.
End of the note.
Number of page reorganizations executed for the table
Page Reorgs

Too many page reorganizations can result in less than optimal

insert performance. You can use the REORG TABLE utility to
reorganize a table and eliminate fragmentation.

Note
If you double-click a line, detailed table analysis data is displayed as described in Space:
Single Table Analysis [page 106].

April 2010

55

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7 Performance: Applications

The Application Snapshot screen displays the following performance data for every DB2
application, that is, for every SAP work process. The information displayed helps you to
determine which work processes are placing the highest load on the database:
Partition (only DPF systems)
User
Appl. Handle
Agent PID
Appl. Name
Appl. PID
Appl. Host Name
Application Status
Buffer Quality (%)
Data Logical Reads
Index Logical Reads
You can access the Application Snapshot screen by calling the DBA Cockpit and choosing
Performance Applications in the navigation frame of the DBA Cockpit.
Capturing or Canceling an Activity
If you discover activities that are running very long on the Performance: Application Snapshot
screen, you can do one of the following:
Capture detailed information about the execution of an activity as follows:
1. Select the activity and choose the Capture pushbutton.
2. In the DBA Cockpit, choose

Workload Management

Critical Activities

On the Critical Activities screen, activities that have been captured manually
are displayed with the value MANUAL in the Predicate column.
Note
To find manually captured activities more easily, use the filter function of the
list viewer.
End of the note.
As soon as you select on of the activities, details of the execution of the captured
activity are displayed.
Cancel an activity by selecting it and choosing the Cancel pushbutton.

56

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If the activity is successfully canceled, the SQL-error SQL4725N with status

SQLSTATE 57014 is returned to the canceled application.

Note
This feature is available only if the currently monitored database version is at least DB2
Version 9.5.
End of the note.
Displaying Details on Applications
You can display detailed information by selecting one or more applications and choosing
Details. A detail Application Snapshot screen appears with information on:
Application
Agents
Note
This tab page is only available if you are using the SAP GUI-based user interface. It
also contains information that you can also find on the Assigned Agents and on the
Agents Memory tab pages on the Web browser-based user interface.
Assigned Agents
Note
This tab page is only available if you are using the Web browser-based user
interface.
Agents Memory
Note
This tab page is only available if you are using the Web browser-based user
interface.
Buffer Pool
Direct I/O
XML Storage
Locks and Deadlocks
Calls
Sorts
Cache
Unit of Work

April 2010

57

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Statement
Statement Text
SQL Workspace

2.7.1 Applications: Application

To display information on applications, call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Application.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Application
PID

Process ID of the database process belonging to an SAP work

process
A system-wide unique ID for the application

Handle

On multi partition database systems, this ID will be the same on

every partition where the application may make a secondary
connection. Several agent processes (DB2 agent) can be
assigned to an application handle.

Connect Start

Start time when the application connected to the database

Platform

Operating system on which the client application is running

Host

Host name of the application server where the application server

is running

Name

Name of application running at the client as known to the

database manager or DB2 connect
Current status of the application. Possible values are:

Status

Database Connect Pending

The application has initiated a database connection but
the request has not yet completed.

58

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Database Connect Completed
The application has initiated a database connection and
the request has completed.
Unit of Work Executing
The database manager is executing requests on behalf
of the unit of work.
Unit of Work Waiting
The database manager is waiting on behalf of the unit of
work in the application. This status typically means that
the system is executing in the application's code.
Lock Wait
The unit of work is waiting for a lock. After the lock is
granted, the status is restored to its previous value.
Commit Active
The unit of work is committing its database changes.
Rollback Active
The unit of work is rolling back its database changes.
Recompiling
The database manager is compiling an SQL statement
or precompiling a plan on behalf of the application.
Request Interrupted
An interrupt of a request is in progress.
Database Disconnect Pending
The application has initiated a database disconnect but
the command has not yet completed executing. The
application may not have explicitly executed the
database disconnect command. The database manager
will disconnect from a database if the application ends
without disconnecting.
Transaction prepared
The unit of work is part of a global transaction that has
entered the prepared phase of the two-phase commit
protocol.
Transaction Heuristically

April 2010

59

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Committed The unit of work is part of a global
transaction that has been heuristically committed.
Transaction Heuristically Rolled Back
The unit of work is part of a global transaction that has
been heuristically rolled-back.
Transaction Ended
The unit of work is part of a global transaction that has
ended but hast not yet entered the prepared phase of
the two-phase commit protocol.
Creating Database
The agent has initiated a request to create a database
and that request has not yet completed.
Restarting Database
The application is restarting a database in order to
perform crash recovery.
Restoring Database
The application is restoring a backup image to the
database.
Backing Up Database
The application is performing a "fast load" of data into
the database.
Data Fast Load
The application is performing a "fast load" of data into
the database.
Data Fast Unload
The application is performing a "fast unload" of data
from the database.
Wait to Disable Tablespace
The application has detected an I/O error and is
attempting to disable a particular tablespace. The
application has to wait for all other active transactions on
the tablespace to complete before it can disable the
tablespace.
Quiescing a Tablespace
The application is performing a QUIESCE

60

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
TABLESPACE request.
Wait for Remote Partition The application is
waiting for a response from a remote partition in a
partitioned database instance.

Agent
Process ID of an SAP work process that made the connection to
the database

PID
Client Information

Client user ID that is generated by the transaction manager and

provided to the server, if the sqleseti API is used.

User ID

For ABAP systems: Name of the SAP user

Workstation

Application

Identifies the clients system or workstation (for example, CICS

EITERMID), if the sqleseti API was used in this connection.
Identifies the server transaction program performing the
transaction, if the sqleseti API was used in this connection.
For ABAP systems: Name of the SAP transaction

Accounting

The data passed to the target database for logging and

diagnostic purposes, if the sqleseti API was used in this
connection.
For ABAP systems: Name of the program executing the SQL
statement

2.7.2 Applications: Agents

Note
This tab page is only available if you are using the SAP GUI-based user interface of the DBA
Cockpit.
End of the note.
To display information on agents for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

April 2010

61

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Agents.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Agents
Coordinator Agent PID

Process ID (UNIX systems) or thread ID (OS/2 or Windows

systems) of the coordinator agent for the application

Currently Associated

Number of agents currently associated with the application

Associated with This Appl.

Number of agents participating in this application (high-water

mark)

Stolen from Application

Number of agents removed from this application and

subsequently used by another application
This only happens if the agent was not busy.

Times Used by Agent(s)

User CPU Time

Total user CPU time in seconds consumed by agent(s)

System CPU Time

Total system CPU time in seconds consumed by agent(s)

Idle Time

Total idle time in seconds

Waited for Prefetch

Total time in milliseconds waited for prefetch

This table displays information about memory pools allocated
to this application. The table contains the following columns:
Partition
Partition number

Memory Pools Allocated to

Agent

PID
Process ID (UNIX) or thread ID (Windows) of the
agent
Pool ID
Type of memory pool
Current Size (KB)

62

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Current size of the memory pool
High-Water Mark (KB)
Largest size of the memory pool since its creation
Configured Size (KB)
Configured size of the memory pool

2.7.3 Applications: Assigned Agents

Note
This tab page is only available if you are using the Web browser-based user interface of the
DBA Cockpit.
End of the note.
To display information on agents for your selected application, call the DBA Cockpit.
1. Choose

Performance

Snapshots

Applications

The Applications screen appears.

2. Select an application from the list.
3. Choose the Assigned Agents tab page.
The following information is displayed on the Assigned Agents tab page:
Field

Description

Agents
Coordinator Agent PID

Process ID (UNIX systems) or thread ID (Windows) of the

coordinator agent for the application

Currently Associated

Number of agents currently associated with the application

Associated with This Appl.

Number of agents participating in this application (high-water

mark)

Stolen from Application

Number of agents removed from this application and

subsequently used by another application
This only happens if the agent was not busy.

April 2010

63

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Times Spent by Agent(s)

User CPU Time

Total user CPU time in seconds consumed by agent(s)

System CPU Time

Total system CPU time in seconds consumed by agent(s)

Idle Time

Total idle time in seconds

Waited for Prefetch

Total time in milliseconds waited for prefetch

This table displays information about all agents that are the
coordinator agent itself or agents working as a subagent for the
coordinator agent:
Partition
Partition number
Agent Type
Type of the agent
Nesting Level
Nesting level of the agent
Entity
Entity of the agent
State

Assigned Agents
Indicates whether an agent is associated or active
TID
Thread ID of the agent
Service Class
Service class the agent is assigned to
Event Type
Type of event that was last processed by the agent
Event Object
Object of the event that was last processed by the agent
Event State
State of the event that was last processed by the agent

64

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7.4 Applications: Agents Memory

Note
This tab page is only available if you are using the Web browser-based user interface of the
DBA Cockpit.
End of the note.
To display information on agents for your selected application, call the DBA Cockpit.
1. Choose

Performance

Snapshots

Applications

The Applications screen appears.

2. Select an application from the list.
3. Choose the Agents Memory tab page.
The following information is displayed in the Memory Pools Allocated to Agent screen area:
Column
Partition

Description
Partition number
Process ID (UNIX) of the agent
Note

PID

On Windows, this is called thread ID.

End of the note.
Pool ID

Type of memory pool

Current Size (KB)

Current size of the memory pool

High-Water Mark (KB)

Largest size of the memory pool since its creation

Configured Size (KB)

Configured size of the memory pool

2.7.5 Applications: Buffer Pool

To display information on buffer pool activity for your selected application(s), call the DBA
Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.

April 2010

65

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

A detail Application Snapshot screen appears.

3. Choose Buffer Pool.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Buffer Quality
Indicates percentage at which the data is read from the buffer pool,
rather than directly from the hard disk
Overall Buffer Quality
This is calculated using the following formula: (logical reads
physical reads) / (logical reads) * 100
Data Hit Ratio

Indicates percentage at which data (without index data) is read

from the buffer pool, rather than directly from the hard disk

Index Hit Ratio

Indicates percentage at which index data is read from the buffer

pool, rather than directly from the hard disk

Average Time
Physical Reads

Average time in milliseconds required to read data from disk into

the buffer pool

Physical Writes

Average time in milliseconds required to write data from the buffer

pool to disk

Data
Logical Reads

Number of read accesses to data in the buffer pool

Number of read accesses to data on disk (I/O)

Physical Reads

The value includes the number of physical reads that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O Servers).
Number of write accesses to data on disk (I/O)

Physical Writes

It includes the number of physical writes that were performed

synchronously (by the database manager agents) and
asynchronously (by the I/O Cleaners).

Temporary Logical
Reads

Number of logical read requests that required I/O to get data pages
into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get data

pages into the temporary tablespace

66

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Index
Logical Reads

Number of read accesses to index data in the buffer pool

Number of read accesses to index data on disk (I/O)

Physical Reads

Since index data is read only by the database manager agents this
value contains the number of synchronously read index pages.
Number of write accesses to index data on disk (I/O)

Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents) and
asynchronously (by the I/O Cleaners).

Temporary Logical
Reads

Number of logical read requests that required I/O to get index

pages into the temporary tablespace

Temporary Physical
Reads

Number of physical read requests that required I/O to get index

pages into the temporary tablespace

2.7.6 Applications: Direct I/O

To display information on direct I/O for your selected application(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Applications.

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
Choose Direct I/O.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Average Time
Direct Reads

Average time in milliseconds required to read

directly from disk

Direct Writes

Average time in milliseconds required to write

directly to disk

I/O
Direct Reads

Read accesses from disk that do not use the

buffer pool (LONG VARCHAR fields, backup)

Direct Writes

Write accesses to disk that do not use the buffer

pool (LONG VARCHAR fields, restore, load)

April 2010

67

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Average I/O per Request

Direct Reads

Average number of requests to read directly

from disk

Direct Writes

Average number of requests to write directly to

disk

2.7.7 Applications: XML Storage

To display information on XML storage for the selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose XML Storage.
Field

Description

Pool Data

Logical Reads

Indicates the number of data pages for XML storage objects (XDAs)
that have been requested from the buffer pool (logical reads) for
regular and large tablespaces

Physical Reads

Indicates the number of data pages for XML storage objects (XDAs)
that have been read from the tablespace containers (physical reads)
for regular and large tablespaces

Write Accesses

Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk

Temporary Data

68

Logical Reads

Indicates the number of pages for XML storage objects (XDA) that
have been requested from the buffer pool (logical reads) for temporary
tablespaces.

Physical Reads

Indicates the number of pages for XML storage objects that have been
(XDA) read from the tablespace containers (physical reads) for
temporary tablespaces

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Asynchronous I/O

Physical Reads

Physical Writes

Indicates the number of XML storage object (XDA) data pages that
have been read in from the tablespace containers (physical reads) by
asynchronous engine dispatchable units (EDUs) for all types of
tablespaces.
Indicates the number of times a buffer pool data page for an XML
storage object (XDA) was physically written to disk by either an
asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for
the pages being prefetched.

Read Requests

Indicates the number of asynchronous read requests for XML storage

object (XDA) data

2.7.8 Applications: Locks and Deadlocks

To display information on locks and deadlocks for your selected application(s), call the DBA
Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Locks and Deadlocks.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Fields

Description

Lock Waits

Total

Total number of times that this application requested a lock, but

had to wait because another application was already holding a
lock on the data

Time Waited

Total amount of elapsed time in milliseconds that this application

has waited for a lock to be granted

Average Time Waited

Average time in milliseconds waited for a lock

April 2010

69

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Fields

Description

Escalations
Number of times that locks have been escalated from several row
locks to a table lock
Lock Escalations

Exclusive Lock
Escalations

If the maximum allowed length of the lock list is reached, row

locks are converted to table locks to save space in the lock list.
This process is called "lock escalation".
Number of times that locks have been escalated from several row
locks to one exclusive table lock, or the number of times an
exclusive lock on a row caused the table lock to become an
exclusive lock
Exclusive locks are important to track since they can impact the
concurrency of your data because other applications cannot
access data held by an exclusive lock.

Locks
Locks Currently Held

Total number of locks currently held by the application

Number of deadlocks that have occurred. Deadlock situations are
recognized and resolved automatically by the database

Deadlocks Detected
The database configuration parameter DLCHKTIME determines
when a lock wait situation is resolved.
Number of times that a request to lock an object timed out instead
of being granted
Lock Timeouts
The database configuration parameter LOCKTIMEOUT determines
when a lock wait situation is resolved.
Lock Timeout Value

Value of the database configuration parameterLOCKTIMEOUT

Deadlock Event Monitor

Statement History List

Size

70

When a detailed deadlock event monitor with history is running,

this element reports the number of bytes being used from the
database monitor heap (HON_HEAP_S) to keep track of the
statement history list entries.

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7.9 Applications: Calls

To display information on calls for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Calls.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Rows
Deleted

Number of data records that were deleted

Inserted

Number of data records that were inserted

Selected

Number of data records that were selected

Updated

Number of data records that were updated

Statements Executed
SELECT SQL

Number of SELECT statements that were executed

UPDATE/INSERT/DELETE

Number of UPDATE, INSERT, and DELETE statements that

were executed

DDL

Number of Data Definition Language (DDL) statements that were

executed, for example, CREATE TABLE, CREATE VIEW,
ALTER TABLE, and DROP INDEX.

Statements Attempted
COMMITs

Number of COMMIT statements that have been attempted

Number of ROLLBACK statements that have been attempted

Rollbacks

Automatic rollbacks caused by error situations or deadlocks are

not included.

Dynamic SQL

Number of dynamic SQL statements attempted

Static SQL

Number of static SQL statements attempted

April 2010

71

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field
Failed SQL

Description
Number of attempted SQL statements that failed

Hash Joins
Total

Total number of hash joins executed

Total Hash Loops

Total number of times that a single partition of a hash join was

larger than the available sort heap space

Overflows

Number of times that hash join data exceeded the available sort
heap space

Small Overflows

Number of times that hash join data exceeded the available sort
heap space by less than 10%

2.7.10 Applications: Sorts

To display information on sorts for your selected application(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Applications.

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
Choose Sorts.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Sort Time
Total

Total time in milliseconds required for all sort processes

Average

Average sort time in milliseconds

Sorts
Total Sorts

Total number of sorts that have been executed

Sort Overflows

If the storage area allocated for sorting is not large enough,

a sort overflow occurs. The hard disk is then used
temporarily.

72

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7.11 Applications: Cache

To display information on cache for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Cache.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Catalog Cache
Indicates percentage at which the data is read from the catalog cache,
rather than directly from the hard disk
Quality
This is calculated using the following formula: (catalog cache lookups catalog cache insert) / catalog cache lookups * 100
Lookups

Number of times that the catalog cache was referenced to obtain table
descriptor information

Inserts

Number of times that the system tried to insert table descriptor

information into the catalog cache

Overflows

Number of times that an insert into the catalog cache failed due to the
catalog cache being full

Heap Full

Number of times that an insert into the catalog cache failed due to the
database heap being full

Package Cache
Indicates percentage at which the data is read from the package
cache, rather than directly from the hard disk
Quality
This is calculated using the following formula: (package cache lookups
- package cache inserts) / package cache lookups * 100
Lookups

Number of times an application looked for a section in the package

cache

Inserts

Total number of times that a request section was not available for use
and had to be loaded into the package cache

April 2010

73

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7.12 Applications: Unit of Work

To display information on units of work for your selected application(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Applications.

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
Choose Unit of Work.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.

Field

Description

Unit of Work
Start Time

Time that unit of work first required database resources

Stop Time

Time that the most recent unit of work completed, which

occurs when the database changes are committed or
rolled back

Elapsed Time (s)

Duration of unit of work in seconds

Elapsed Time (s)

Duration of unit of work in microseconds

Log Space Used

Log space used in bytes in most recent unit of work

Completion Status

Completion status of last transaction

Previous Unit of Work

Stop Time

Previous time that the most recent unit of work

completed, which occurs when the database changes are
committed or rolled back

2.7.13 Applications: Statement

To display information on performance data of the current SQL statements for your selected
application(s), call the DBA Cockpit.
...

1. In the navigation frame, choose Performance

Applications.

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Statement.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.

74

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Statement
Start Time

Date and time when unit of work starts, the

statement starts or a deadlock is detected

Stop Time

Date and time when the statement stopped

executing

Elapsed Time(s)

Duration of unit of work in seconds

Elapsed Time (sec)

Duration of unit of work in microseconds

Rows
Rows Read

Number of rows read from the table

Rows Written

Number of rows changed (inserted, deleted, or

updated) in the table

Sort
Sort Overflow

If the storage area allocated for sorting is not

large enough, a sort overflow occurs. The hard
disk is then temporarily used.

Total Sort Time

Total time for all sort processes

Number of Statement Sorts

Total number of sorts that have been executed

Data
Logical Reads

Number of read accesses to data in the buffer

pool

Physical Reads

Number of read accesses to data on disk

Temporary Logical Reads

Number of logical read requests that required

I/O to get data pages into the temporary
tablespace

Temporary Physical Reads

Number of physical read requests that required

I/O to get data pages into the temporary
tablespace

Index
Logical Reads

Number of read accesses to data in the buffer

pool

Physical Reads

Number of read accesses to data on disk

Temporary Logical Reads

Number of logical read requests that required

I/O to get index pages into the temporary
tablespace

Temporary Physical Reads

Number of physical read requests that required

I/O to get index pages into the temporary
tablespace

April 2010

75

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.7.14 Applications: Statement Text

To display information on the current SQL statements for your selected application(s), call the
DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose Statement Text.
If you have selected more than one application, you can use the page buttons on the screen
to navigate between them.
Field

Description

Statement
Type of statement processed
Possible types are:
Type

Static SQL statement

Dynamic SQL statement
An operation other than an SQL statement, for example, a
bind or precompile operation
Operation currently being processed or most recently processed (if
none is currently running)
Possible operations are:
SELECT
PREPARE
EXECUTE

Operation

EXECUTE IMMEDIATE
OPEN
FETCH
CLOSE
DESCRIBE
STATIC COMMIT

76

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
STATIC ROLLBACK
FREE LOCATOR
PREP_COMMIT
CALL
PREP_OPEN
PREP_EXEC
COMPILE
Indicates if the statement that is executed is using a blocking cursor
(YES) or not (NO)

Blocking Cursor
If data is transferred in blocks and not row by row, the performance of
the corresponding query will be improved.
Text of dynamic SQL statement that was being processed when the
snapshot was taken
Statement

It can also be the text of the statement that was most recently
processed, if no statement was being processed at the time when the
snapshot was taken.

If a statement is displayed, you can choose EXPLAIN to list the access plan for the statement
execution. This function provides a detailed analysis of expensive SQL statements.
Note
To display the ABAP source program where the statement was defined, choose Source. An
editor screen appears, which contains the related source.
However, this function is only available for local system or ABAP systems that have an
additional RFC destination assigned.
End of the note.
More Information
The EXPLAIN Function [page 199]

2.7.15 Applications: SQL Workspace

To display information about the current SQL workspace for your selected application(s), call
the DBA Cockpit.
1. In the navigation frame, choose

Performance

Applications

The Application Snapshot screen appears.

April 2010

77

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2. To display more detailed information, select one or more applications and choose
Details.
A detail Application Snapshot screen appears.
3. Choose SQL Workspace.
Field

Description

Private Workspace
Lookups

Number of times an application looked for an SQL section in the

agent's private workspace

Inserts

Inserts of SQL sections by an application into the private workspace

Overflows

Number of times that the private workspace overflowed the bounds of

its allocated memory

High-Water Mark

Largest size reached by the private workspace

Shared Workspace
Lookups

Number of times an application looked for an SQL section in the

agent's shared workspace

Inserts

Inserts of SQL sections by an application into the shared workspace

Overflows

Number of times that the shared workspace overflowed the bounds of

its allocated memory

High-Water Mark

Largest size reached by the shared workspace

2.8 Performance: SQL Cache

The SQL Cache Snapshot displays information on SQL statements that are executed very
often and stored in the SQL cache of your system. This information helps you to identify
those SQL statements that consume a large number of resources. You can also determine
whether fine-tuning of those statements is necessary to improve the performance of the
database.
You can access the SQL Snapshot screen by calling the DBA Cockpit and choosing
Performance SQL Cache in the navigation frame of the DBA Cockpit.

78

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Depending on your system, the snapshot can give you a wide range of information, which
might lead to a very large result set. After the snapshot has been taken and before the results
are displayed, the Selection Criteria dialog box appears where you can limit the result set
displayed according to the following selection criteria:
Field

Description

Executions

Number of times a statement has been executed

Total Execution Time

Total execution time in milliseconds for a statement

Avg. Execution Time

Average execution time in milliseconds for a statement

Rows Read

Number of rows read for a statement

Rows Written

Number of rows written by a statement

SQL Text (CaseSensitive)

Search using either the wild card "*" or using a text string, for
example, INSERT, to limit the number of statements displayed
Ratio of rows read from the base table compared to rows
processed, which can be either rows returned to the application
(SELECT statements) or rows written (UPDATE, INSERT, DELETE
statements)

Rows Read / Rows

Processed

A value of 1 indicates an optimal access to the requested data.

High values indicate statements with an inefficient access.
Note
This metric is only evaluated if your database is DB2 V9.5 for
Linux, UNIX, and Windows Fix Pack 1 or higher.
End of the note.

When you have made your selections and chosen Continue, the result set is determined by
filtering the snapshot results according to the selection criteria and the following information is
displayed:
Field

Description

Total Cache Sum

Execution Time

Total execution time in milliseconds for an SQL statement

Rows Read

Total number of rows read

Rows Written

Total number of rows written

April 2010

79

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
The data displayed under Total Cache Sum table refers to the entire SQL cache and not only
to the currently selected result set.
End of the note.
The result set is displayed in a table:
Column
SQL Text

Description
Text of a dynamic SQL statement that was in the SQL cache at
the time of the snapshot
Number of times a statement was executed

Executions

This value helps you to identify which statements are executed

very often. A high number of executions does not necessarily
mean that a statement is using an excessive amount of
resources. You should also check the number of rows read and
rows written. If you find relatively high values here, choose
EXPLAIN to check whether indexes are not being efficiently used
or whether indexes are missing.
Total execution time in milliseconds for a statement

Total Execution Time

You can use this value together with Executions to identify the
statements that would benefit from further analysis.

Total Execution Time ( %)

Total Execution Time (milliseconds) divided by Total Cache Sum

Execution Time (milliseconds)

Average Execution Time

(ms)

Total Execution Time (in milliseconds) divided by Executions

Buffer Quality (%)

Buffer quality for this statement in percent

Ratio of rows read from the base table compared to rows
processed, which can be either rows returned to the application
(SELECT statements) or rows written (UPDATE, INSERT, DELETE
statements)

Rows Read / Rows

Processed

A value of 1 indicates an optimal access to the requested data.

High values indicate statements with an inefficient access.
Note
End of the note.
This metric is only available if your database is DB2 V9.5 for
Linux, UNIX, and Windows Fix Pack 1 or higher.

80

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Average number of pages read from the buffer pool per rows
processed, which can be either rows returned to the application
(SELECT statements) or rows written (UPDATE, INSERT, DELETE
statements)
BP Gets / Rows
Processed

Note
This metric is only available if your database is DB2 V9.5 for Linux,
UNIX, and Windows Fix Pack 1 or higher.
End of the note.

BP Gets / Executions

Average number of pages read from the buffer pool per execution
of the statement
Total user CPU time in milliseconds for a statement

Total User CPU Time

(ms)

This value together with the total execution time gives you
information on the longest running statements.
Total system CPU time in milliseconds for a statement

Total System CPU Time This value together with total execution time and total user CPU
(ms)
time helps you to identify statements that use an excessive number
of resources.
Number of rows read

Rows Read

You can use this value to identify statements that would benefit
from additional indexes. Use EXPLAIN to analyze the statement.
The given value does not necessarily correspond to the number of
rows of the result set of the SQL statement. The Rows Read value
shows the number of rows that needs to be read to obtain the
result set.
Number of rows that were changed (inserted, deleted, or modified)
in a table

Rows Written
High values might indicate that you should update statistics using
RUNSTATS.
Number of sorts that were necessary to execute the statement
SQL Sorts

You can use this value to determine whether new indexes are
needed. Use EXPLAIN to check whether and which indexes were
used when the selected statement was executed.

Sort Overflows

Number of sort overflows

Total Sorts

Total number of sorts

April 2010

81

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
If no hits are found, the result set is empty and nothing is displayed.
End of the note.
The following functions are available for further actions:
Refresh
Set Selection Criteria
When you choose Set Selection Criteria, the Selection Criteria dialog box appears
again and you can make further evaluations based on the already taken snapshot
data.
Source
To display the ABAP source program where the statement was defined, choose
Source. An editor screen appears, which contains the related source.
Note
This function is only available for local systems or ABAP systems that have an
additional RFC destination assigned.
End of the note.
EXPLAIN
To display detailed performance analysis, you can display the access plan for the
SQL statement by choosing EXPLAIN. For more information, see The EXPLAIN
Function [page 199].
Index Advisor
To improve the performance of a query, you can retrieve recommendations about
useful indexes using the index advisor. In addition, you are able to design new virtual
indexes that can be validated before they are actually created. For more information,
see The Index Advisor [page 213].

82

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.9 Performance: Lock Waits and Deadlocks

The system searches for lock waits indicating that at least one process is locked by the lock
on another process. A request waits for a resource (a database table or a row of a table) that
is locked exclusively by another user.
You can access the Lock Waits and Deadlocks screen by calling the DBA Cockpit and
choosing Performance Lock Waits and Deadlocks in the navigation frame of the DBA
Cockpit.
All recorded lock waits and deadlocks are displayed in a tree structure. For each lock wait or
deadlock situation that has been detected, the Lock Wait or Deadlock node is displayed as
well as the date and time when the lock wait or deadlock situation occurred. If you open the
subnodes of a deadlock or lock wait node, a hierarchical structure appears displaying the
following information:
<Lock wait or deadlock>
o

Agent <Agent ID> (<Application Name>) waiting for Agent <Agent ID>
Client Process ID: <Process ID>
Host: <Host>
Lock Agent is waiting for:
Table: <Schema>.<Table>
Lock Object Type: <Lock Object Type>
Current Lock Mode: <Lock Mode>
Requested Lock Mode: <Lock Mode>

To display the last SQL statement that was executed by one of the agents, choose Last SQL
Statement. The last SQL statement of the respective agent is displayed in the editor window
at the bottom of the screen.
Tree Node

Description

<Agent ID>

Agent handle of the application waiting for the lock to be released

<Application Name>

Name of the application waiting for the lock to be released

<Client Process ID>

Process ID of the application requesting the lock

<Host>

Host name of the server requesting the lock

Lock modes that the waiting application would like to set
The following lock modes are possible:

Requested Lock Mode

IS: intention share lock
IX: intention exclusive lock

April 2010

83

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tree Node

Description
S: share lock
SIX: share with intention exclusive lock
X: exclusive lock
IN: intent none
Z: super exclusive lock
U: update lock
NS: next key share lock
NX: next key exclusive lock
W: weak exclusive lock
NW: next key weak exclusive lock

Current Lock Mode

Lock mode held

Lock Object Type

Type of object to be locked

Table

Table on which/on whose record the lock is held

Caution
Lock wait situations are recognized by DB2. Database parameter LOCKTIMEOUT specifies
how many seconds the system must wait before automatically resolving a lock wait situation.
If LOCKTIMEOUT is set to -1, lock wait situations are not resolved.
End of the caution.
Caution
DB2 recognizes deadlocks automatically using parameter DLCHKTIME that specifies the time
period during which the system analyzes lock situations or deadlocks.
End of the caution.

84

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.10 Performance: Inplace Table Reorganization

Inplace table reorganization allows you to access tables while they are being reorganized.
To get an overview of inplace table reorganizations that are currently running or that have
been interrupted, call the DBA Cockpit and choose Performance Inplace Table
Reorganization . The Performance: Active Inplace Table Reorganizations screen appears.
The information is displayed in the following table:
Column

Description

Table Schema

Table schema of the table that is currently being reorganized

Table Name

Name of the table that is currently being reorganized

Partition

Number of the partition (only displayed in a multi partition database)

Status of the inplace table reorganization
Possible values are:
Running

REORG Status
Paused
Suspended
Completed
Progress %

Progress of the reorganization

Start Date

Start date of the inplace table reorganization

Start Time

Start time of the inplace table reorganization

Access mode for other users while the table reorganization is running
The following access modes are possible:

Access Mode

READ
WRITE
NO ACCESS

Tablespace

Name of the tablespace where the reorganization is performed

Note
If no active inplace table reorganization was found, the system displays the following
message: No Inplace Table Reorganizations are running. Only the REORG
activities since the database start are displayed. REORGs that were active before the
database start are not displayed.

April 2010

85

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

End of the note.

Depending on your requirements, you can customize the view on the Performance: Active
Inplace Table Reorganizations screen using the following functions:
Pushbutton

Function
Active Only
Only inplace table reorganizations with the status Started or
Paused are displayed.

Choose View
All
All inplace table reorganizations are displayed including
those with status Completed or Suspended.
Since DB Start
Only inplace table reorganization that have been started after
the last restart of the database manager are displayed.
Choose Data Source

Incl. History File

This option additionally reads the DB2 history file. Thus, the
data of inplace table reorganizations that were started before
the last restart of the database manager is also retrieved.

Activities
You can perform the following actions for an inplace reorganization:
Pause
Select a running inplace reorganization and choose Pause.
Resume
Select a paused inplace table reorganization and choose Resume.
Suspend
Select any inplace table reorganization and choose Suspend.
As a result of any of these actions, the list of active inplace table reorganizations is refreshed.

86

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.11 Performance: History - Database

Note
History data is only available if you have selected Collect History Data when you configured
your database for remote monitoring. For more information, see Configuring Systems for
Remote Monitoring Using Remote Database Connections.
End of the note.
The system provides a day-by-day trend analysis of database activity. You can check the
workload of the days and display the workload peak of a single day.
You can access the Performance History Database screen by calling the DBA Cockpit and
choosing Performance History Database in the navigation frame of the DBA Cockpit.
An overview of all days monitored is displayed:
Column

Description

Partition

Monitored partition (only displayed if you are using a multipartition database)

Date

Day when monitoring was performed

Average physical read time

Avg. Phys. Read Time (ms)

If you have chosen Total Day, this is the average of all

measured average read times. If you have chosen Peak, this
is the worst measured read time.
Average physical write time

Avg. Phys. Write Time (ms)

If you have chosen Total Day, this is the average of all

measured average write times. If you have chosen Peak, this
is the worst measured write time.

Data Logical Reads

Number of read accesses to data in the buffer pool

Number of read accesses to data on disk (I/O)

Data Physical Reads

The value includes the number of physical reads that were

performed synchronously (by the database manager agents)
and asynchronously (by the I/O servers).
Number of write accesses to data on disk (I/O)

Data Physical Writes

The value includes the number of physical writes that were

performed synchronously (by the database manager agents)
and asynchronously (by the I/O cleaners).

Index Logical Reads

Number of read accesses to index data in the buffer pool

Index Physical Reads

Number of read accesses to index data on disk (I/O)

April 2010

87

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
Since index data is read only by the database manager
agents, this value includes the number of synchronously read
index pages.
Number of write accesses to index data on disk (I/O)

Index Physical Writes

COMMIT Statements

The value includes the number of physical writes that were

performed synchronously (by the database manager agents)
and asynchronously (by the I/O cleaners).
Total number of COMMIT statements that have been
attempted
Total number of ROLLBACK statements that have been
attempted

ROLLBACK Statements
Automatic ROLLBACKs caused by error situations or
deadlocks are not included.
Lock Waits

Total number of times that applications or connections waited

for locks

Lock Wait Time (ms)

Total elapsed time in milliseconds waited for a lock

Deadlocks

Total number of deadlocks that have occurred

Lock Escalations

Number of times that locks have been escalated from several

row locks to a table lock

Exclusive Lock Escalations

Number of times that locks have been escalated from several

row locks to one exclusive table lock, or the number of times
an exclusive lock on a row caused the table lock to become
an exclusive lock

If you choose Total Day in the field Workload in the Performance History - Database group
box, the total workload of this day is displayed. The value displayed is calculated using
formula maximum value - minimum value. Database restarts are taken into consideration.
If you choose Peak in the field Workload in the Performance History - Database group box,
the maximum of all measured values is displayed.
You can display details for one specific day by double-clicking a field or selecting a row and
choosing Details. A detail screen appears with the following information:
Snapshot
The measured values of the selected day are displayed.
Interval
The delta values of the measurements, which are provided under Snapshot, are
displayed.

88

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you select a particular day, snapshots of the database activity are displayed in a two-hour
cycle.
Note
If the database is restarted during one day, the interval displayed after the restart does not
equal the delta of two measurements because the counter was reset during the restart. In this
case the absolute value of the last measurement is displayed.
End of the note.

2.12 Performance: History Tables

Note
History data is only available if you have selected Collect History Data when you configured
your database for remote monitoring. For more information, see Configuring Systems for
Remote Monitoring Using Remote Database Connections.
End of the note.
The system provides a day-by-day trend analysis of table activity. You can access the
Performance: History Tables screen by calling the DBA Cockpit and choosing
Performance History Tables in the navigation frame.
An overview of the monitored days is displayed:
Column

Description

Table Schema

Name of the schema to which the table belongs

Table Name

Name of the table

Rows Written

Number of rows written

Rows Read

Number of rows read

Number of read accesses to tables that resulted in overflow
pages, that is, to records, which have been swapped from their
original page.

Overflow Accesses

Note
If there is a high number of overflow accesses in comparison to
total read accesses, the table is a candidate for reorganization.
End of the note.

Page Reorgs

April 2010

Number of internal page reorganizations during INSERT

operations

89

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
If you want to display history data that is cumulated by day, week or month, choose the
appropriate option from the dropdown list in the Statistics field.
End of the note.

2.13 Performance: Performance Warehouse

You can analyze performance data of your database system using the Performance
Warehouse. To access the Performance Warehouse, call the DBA Cockpit and choose
Performance
Performance Warehouse.
The following content areas are available in the Performance Warehouse:
Reporting
By default, the Reporting content area is displayed.
Configuration

If you are using the SAP GUI-based user interface, the application starts in a
separate Web browser.
Integration
The Performance Warehouse is part of the DBA Cockpit.
Prerequisites
An SAP Solution Manager system with Solution Manager Diagnostics (SMD) enabled is
required.
Features
In the Performance Warehouse, all relevant performance indicators that are collected by the
DBA Cockpit are stored in an SAP NetWeaver BW system. This BW system is used by the
Solution Manager Diagnostics (SMD) back end of an SAP Solution Manager system. SMD
already uses this SAP NetWeaver BW to store workload data of SAP applications. To
configure the extraction of data into the SMD BI, you use the SMD Setup Wizard.
Based on this architecture, the DBA Cockpit uses SAP NetWeaver BW technology to provide
reports for performance analysis, which you can customize according to your needs. All
collected data has a time dimension, so you can analyze the database performance for any
point in time or over a specified time frame.

90

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Almost all reports are displayed as a chart to visualize the key performance indicators (KPIs).
In addition, there is also a detailed table view. To navigate within these reports, you can use
the SAP BI drilldown feature. Violations to performance thresholds are highlighted based on
predefined SAP BI exceptions to make you immediately aware of performance issues.
By default, the Performance Warehouse is delivered with predefined content that you can use
to create your own reports according to your needs.
More Information
Performance Warehouse: Reporting [Page 91]
Performance Warehouse: Configuration [Page 92]

2.13.1 Performance Warehouse: Reporting

You use the data provided on the Reporting screen to analyze database performance
problems in the present or the past. To access the Reporting screen of the Performance
Warehouse, call the DBA Cockpit and choose Performance
Performance Warehouse
Reporting.

If you are using the SAP GUI-based user interface, a separate Web browser
opens for this application.
Specifying the Time Frame
To display detailed reports, you first have to specify the time frame for which you want to
analyze data by defining the following:
Granularity
You can choose between Hour, Day or Month. Depending on your selection, the values
for your time frame might change.
Time Frame
If you choose Custom Selection from the dropdown list, you can manually enter the
starting and ending time for your analysis. To activate your custom selection, choose
Apply Filter. For any other selection from the dropdown list, the reports are
automatically refreshed.
The reports are categorized and for each category there is one tab page. On every tab page,
you find a button row for the reports. Every pushbutton in the button row represents a specific
view on the database performance, for example, I/O, Prefetcher, Sort Heap, etc.
Displaying a Report
To display a report, choose the appropriate view pushbutton on the respective tab page.

The availability of the tab pages and of the pushbuttons on each tab page can
vary depending on the selected system. Some reports are only available if
special database features are enabled.

April 2010

91

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The reports consist of two sections:

In the upper section, a chart is displayed to visualize the key performance indicators.
The chart provides a subset of the key columns from the detail table view.

The chart display is optional and not available for all available views.
In the lower section, a detailed table view is available.
You can drill down your reports by either using the context menu of a column header in the
Detail: <Category View> screen area or by specifying the respective value using the
pushbuttons in the Detail: Navigation screen area. Here, you can also add and remove
columns or key figures, or you can set filters on columns.
In addition, there are predefined exceptions (for example, Chart: Exceptions or Details:
Exceptions) for almost all reports on key performance indicators. The used thresholds are
based on Early Watch Alerts and each violation to these thresholds is displayed in red.

If you want to reset a report to its initial state, choose Reset Report in the central
system area.

2.13.2 Performance Warehouse: Configuration

You configure all configuration parameters that are related to the performance warehouse on
the Configuration screen. For example, you can configure the framework, the templates used
for the reports and the report categories.
The DBA Cockpit uses BI Business Explorer (BEx) Web templates to analyze the
performance data that is stored in the Solution Manager Diagnostics (SMD) BI. You can
create your own BI BEx Web templates based on this data and integrate new BI BEx Web
templates into the performance warehouse.
You can access the Configuration screen of the performance warehouse by calling the DBA
Cockpit and choosing Performance
Performance Warehouse
Configuration.

If you are using the SAP GUI-based user interface, a separate Web browser
opens for this application.
On the screen Performance Warehouse: Configuration, the following tab pages are available:
Configuration
Web Reports
Report Categories
Configuration
Here, you can view or modify the configuration parameters of the performance warehouse for
the monitored system. To modify some of these parameters, use the Edit, Save, and Cancel
pushbuttons in the toolbar.

92

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Depending on your database platform, the displayed selection of values can vary. The
following parameters are displayed for all database platforms:
Parameter

Description

BI Server

BI server where the database performance data is located

Managing DBA Cockpit

This DBA Cockpit is allowed to change any data collectors or

performance warehouse configuration for this database. By
default, the DBA Cockpit of the Solution Manager system is
used for this task.

Reporting Time Zone

The performance data time-stamps are converted to one global

time zone for all reports in SMD BI.

The Default checkbox is selected if the default value for your complete
landscape is the same as the one specified for your system.
Web Reports
Here, you can configure the display on the Reporting screen. That is, you can view and
modify the integrated BI BEx Web templates in the tree table. To modify some of these
parameters, use the Edit, Add, and Delete pushbuttons in the toolbar.
The main report categories appear and for each report category, you can view or modify the
views by expanding the appropriate report category. These views appear as pushbuttons on
the respective category tab page on the Reporting screen. To change the sequence within a
category, use the Up or Down pushbuttons.
To display details about a view, simply select it in the table. The following parameters are
displayed in the Details for Web Reports area below the table view:
Parameter

Description

Report

Specifies the name of the report

This text appears on the view pushbutton on a category tab
page.

Description

Detailed description for the report

This text appears as a tooltip for the pushbutton of the key
indicator on a category tab page.

Category

Specifies the report category.

Each category is represented on a separate tab page.

Web Report (Default)

Technical name of the BI BEx Web templates

Web Report (Day)

Technical name of the BI BEx Web templates for granularity

Day

Web Report (Month)

Technical name of the BI BEx Web templates for granularity

Month

Data Providers (Time)

Specifies the data provider of the BI BEx Web templates with a

time dimension. The drilldown of the time dimension is changed
according to the selected granularity.

Active

If selected, the report is available for performance analysis.

Default

If selected, the report is executed as soon as the tab page is

selected.

April 2010

93

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Database

Name of database platform

Release (min)

Minimum database release for this report

Release (max)

Maximum database release for this report

Depending on your database platform, there might be more checkboxes

available for database-specific features. If you select these checkboxes, the
report is only displayed if the specific database features have been set up in the
monitored database system.
Report Categories
Here, you can view and modify the categories for BI BEx Web templates of the reports that
are displayed the Reporting screen. To modify some of these parameters, use the Edit, Add,
and Delete pushbuttons in the toolbar. To change the sequence of the categories on the
Reporting screen, use the Up or Down pushbuttons.
The following parameters are displayed:
Parameter

Description

Category

Name of the category

Description

Detailed description for the category

94

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3 Space
The following sections provide information on space:
Space: Automatic Storage
Space: Tablespaces
Space: Containers
Space: Tables and Indexes
Space: Single Table Analysis
Space: Virtual Tables
Space: History - Overview
Space: History - Database and Tablespaces
Space: History - Tables and Indexes

3.1 Space: Automatic Storage

Note
This function is only available if you enabled your database for automatic storage during the
SAP system installation.
End of the note.
You can access information on automatic storage file systems of the database by calling the
DBA Cockpit and choosing Space Automatic Storage in the navigation frame of the
DBA Cockpit. The Space - Display Automatic Storage screen appears displaying all the
storage paths that are available for the storage management of the database.
For each storage path, the following information is displayed:
Column

Description

Partition

Number of database partition

Storage Path

Full path name

FS ID

ID of the related file system

FS Free Size (GB)

Free size in GB that is available in the file system

FS Total Size (GB)

Total size in GB that is available in the file system

April 2010

95

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
If you want to add or delete a storage path, choose the Display <-> Change pushbutton. The
Space Change Automatic Storage screen appears and only the information about Partition
and Storage Path is displayed.
To switch to the display mode, choose the Display <-> Change pushbutton again.
End of the note.
Adding or Deleting a Storage Path for a Tablespace
1. On the Space: Change Automatic Storage screen, choose Add.
A new line is added to the list.
2. Enter the complete path name of the new storage path and press Enter.
3. Choose Execute.
Note
If you want to delete a storage path, select one from the list and choose Delete.
End of the note.
In the lower half of the Space: Change Automatic Storage screen, an editor is displayed that
shows the generated SQL statement(s) that will be executed. This area is automatically filled
and refreshed if any changes were applied correctly.

3.2 Space: Tablespaces

You can access information on space for tablespaces by calling the DBA Cockpit and
choosing Space Tablespaces in the navigation frame of the DBA Cockpit. The Space:
Tablespace Configuration screen appears.
During the installation of your SAP system you specified one of the following options for the
maintenance of tablespaces:
Automatic Storage
DB2 automatically allocates and extends tablespace containers in the file system.
DMS/SMS Tablespaces
You manually allocate containers for tablespaces. The extension of the
corresponding containers can be performed either manually or automatically.
Depending on your choice, the corresponding screen(s) appear(s) in the DBA Cockpit.
Automatic Storage Tablespaces
If you enabled your database for automatic storage management during the SAP system
installation, the following table displays information about all tablespaces that are part of
automatic storage management:

96

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

Tablespace Name

Name of the tablespace

Partition

Number of the database partition (only displayed in a multi

partition database)

Contents

Contents of tablespace, for example, any data or temporary

data

TS State

Status of tablespace, for example, Normal or Load Pending

KB Total

Total space in KB used by the tablespace

Page Size

Size of a page in bytes

No. Containers

Number of containers

KB Free

Total amount of free space

High-Water Mark (KB)

Indicates the maximum value of used pages reached

Percent Used

Used space in relation to available space

Pending Free Pages

Number of free pages that are pending

DMS/SMS Tablespaces
Regardless whether you have chosen automatic storage management tablespaces or manual
maintenance of DMS/SMS tablespaces during the SAP system installation, the following
information is displayed for all DMS/SMS tablespaces that are maintained manually:
Column

Description

Tablespace Name

Name of the tablespace

Partition

Number of the partition (only displayed in a multi partition

database)

TS Type

Type of tablespace, for example, DMS or SMS

Contents

Contents of tablespace, for example, any data or temporary

data

TS State

Status of tablespace, for example, Normal or Load Pending

KB Total

Total space in KB used by the tablespace

Page Size

Size of a page in bytes

April 2010

97

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

No. Containers

Number of containers

KB Free

Total amount of free space

High-Water Mark (KB)

Indicates the maximum value of used pages reached

Percent Used

Used space in relation to the available space

AUTORESIZE

Indicates if the tablespace is enabled for automatic resizing

Pending Free Pages

Number of free pages that are pending

Displaying Tablespace Details

Note
The following information applies to automatic storage management and DMS/SMS
tablespaces.
End of the note.
To display more information on the tables or indexes of a tablespace, select one or more
tablespaces and choose Contents. The Space: Tablespace Content screen appears
displaying the following information:
Column

Description

Tablespace Name

Name of the tablespace

Schema

Name of the schema

Name

Name of the table or index

Type

Type of object, for example, index, primary index, or table

Maintaining Tablespaces
In addition, you can maintain tablespaces, that is Change, Add or Delete them. For more
information, see Maintaining Tablespaces.

3.2.1 Maintaining Tablespaces

Using the tablespace list on the Space: Tablespace Configuration screen, you can maintain
tablespace entries as follows:
Change tablespace settings and containers
Add new tablespaces
Delete tablespaces

98

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure
Changing Tablespaces
1. On the Space: Tablespace Configuration screen, choose Change. The Space:
Tablespace Maintenance Change Tablespace screen appears. The following
information is displayed:
Field

Description

Tablespace
Maintenance
Name

Name of the tablespace

Name of the partition group where the selected tablespaces are

Database Partition Group defined
A partition group defines a set of partitions.
Space
Total space in KB
Total
This information is not displayed when creating tablespaces.
Fill level of the selected tablespace as a percentage
Used
This information is not displayed when creating tablespaces.
Free space in KB
Free
This information is not displayed when creating tablespaces.
Technical Settings
The following are fixed values that cannot be changed:
Field

Contents

Description
Describes, which kind of data will be stored in the tablespace, for
example, regular data, large objects, temporary user objects, or
temporary system objects

Size of I/O Units

Page Size

Page size in KB

Extent Size

Extent size in KB

Space Management by
Database (DMS)

April 2010

The space of the tablespace containers is managed by the

database.

99

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

System (SMS)

The space of the tablespace containers is managed by the file

system.

AutoStorage

All the tablespace space is managed by the automatic storage

management.

You can enter values in the following fields:

Field

Description

Size of I/O Units

Prefetch Size

Number of pages to be prefetched

Disk Performance
Displays I/O controller overhead and disk seek and latency time in
milliseconds
Overhead
This value is used to determine the cost of I/O during query
optimization.
Time to read one page into memory in milliseconds
Transfer Rate

This value is used to determine the cost of I/O during query

optimization.

Recovery

Dropped Tables

Dropped tables in the specified tablespace may be recovered using

the RECOVER TABLE ON option of the ROLLFORWARD
command.

AUTORESIZE enabled

Tablespace containers are automatically extended by using the file

systems where the containers are located.

Buffer Pool
By default, the buffer pools are displayed that match the page size
of the tablespace. If required, you can add a new buffer pool. For
more information, see Maintaining Buffer Pools [page 144].

Name

For more information about the technical settings, see the IBM documentation SQL
Reference.
Note
By default, DB2 9 for Linux, UNIX, and Windows uses large object tablespaces.
After you have upgraded your database from DB2 Version 8 to DB2 9, you
might also want to convert your regular tablespaces into large object
tablespaces. To do so, select a tablespace and choose Convert to LOB. The job
is scheduled as a background job.

100

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Storage Parameters
For tablespaces that are completely managed by automatic storage management or
that have at least AUTORESIZE enabled, the following fixed values are displayed:
Field

Description

Settings
Initial Size

Initial space allocated when a tablespace is created

Size
Current Size

Displays the current size

Last Resize

Date and time of last automatic resize

Note

Last Resize Terminated

with SQL Error

This field only appears if the last automatic resize failed. Date
and time when the automatic resize failed.
End of the note.
The SQL error is displayed in the lower half of the Space:
Tablespace Maintenance screen.

You can enter values in the following fields:

Settings
Increase Size

Size in KB or in percent by which the a tablespace is extended if

it has become full.
You can enter one of the following:
o

NONE
If there is no maximum size limit

Maximum Size

Absolute value

If an upper threshold is specified that shall not be

exceeded by automatic extensions
If you specify NONE, you allow DB2 to extend containers until
they occupy all file systems where the containers are located.
Containers
If a tablespace is not managed by automatic storage management, you can add or
delete containers:
o

April 2010

To add containers, choose Add.

101

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The system automatically suggests a default path where the container is

located. However, you can modify that path by manually editing the line.
Caution
Adding or changing containers might result in rebalancing, which has a heavy
impact on system performance.
End of the caution.
At least one container must be available for each partition. If you are using a
multi partition database, you need to add containers for all partitions of the
corresponding partition group. If you have to change container sizes, we
recommend that you use Resize all containers to ensure a balanced
distribution of data on the different containers.
Caution
Different container sizes might result in bad performance of the database.
End of the caution.
o

To delete containers, select one or more lines in the table and choose
Delete.

2. To apply changes, choose either Technical Settings or Containers.

3. To confirm your entries, choose Execute.
Adding Tablespaces
1. On the Space: Tablespace Configuration screen, choose Add.
The Space: Tablespace Maintenance Add Tablespace screen appears.
2. Specify a name and a partition group.
Recommendation
We recommend that you use uppercase letters for the tablespace name. Using
lowercase letters or special characters makes accessing the selected tablespace with
the DB2 command line processor less comfortable.
End of the recommendation.
3. Enter the technical settings. By default, the system displays SAP's recommendations.

102

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. Add containers.
If you are using a muli partition database, you must add containers for all partitions of
the corresponding database partition group.
Caution
This step does not apply to tablespaces managed by automatic storage
management.
End of the caution.
5. To confirm your entries, choose Add.
Deleting Tablespaces
1. On the Space: Tablespace Configuration screen, select a tablespace.
2. Choose Delete.
The Space: Tablespace Maintenance DeleteTablespace screen appears.
3. To delete the selected tablespace, choose Delete.
Caution
You cannot delete tablespaces that are still used by the SAP system, that is, if they
are related to some data class. You must delete the data class before deleting the
tablespace.
End of the caution.
SQL Statements
In the lower half of the Space: Tablespace Maintenance screen, an editor is displayed that
shows the generated SQL statement(s) that will be executed. This area is automatically filled
and refreshed if any changes were applied correctly.
More Information
Configuration: Data Classes [page 149]

3.3 Space: Containers

You can access information on containers by calling the DBA Cockpit and choosing Space
Containers in the navigation frame of the DBA Cockpit. The Container Configuration
screen appears.
The following information is displayed:
Column

Description

Tablespace Name

Name of the tablespace

Partition

Number of the partition (only displayed in a multi partition database)

April 2010

103

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

Stripe Set

Number of the strip set the container belongs to

Container Name

Name of the container in which the tablespace is located

Type

Type of the container, for example, disk or file

KB Total

Total size of the container in KB

Pages Total

Total amount of pages

Accessible

Indicates whether the container is accessible (YES) or not (NO)

FS ID

File system ID

FS Free Size (KB)

Free space in the file system in KB

Maintaining Containers
You can maintain tablespace containers by selecting a line in the table on the Container
Configuration screen and choosing Change, Add, or Delete. The Tablespace Maintenance
screen appears.
For more information, see Maintaining Tablespaces [page 98].

3.4 Space: Tables and Indexes

You can access information on space for tables and indexes by calling the DBA Cockpit and
choosing Space Tables and Indexes in the navigation frame of the DBA Cockpit.
A Selection Criteria dialog box appears in which you can limit the result set displayed
according to the following criteria:
Field

Description

Filters
Tablespace Name

Indicates the location of the table

Table Name

Name of the table

Table Size

Size of the table

Flagged Tables

If this flag is not set, only tables are displayed that have a
recommendation for table or index reorganization.

Large RIDs

If this flag is set, only tables are displayed that are located in large
RID tablespaces but that have not been enabled for large RIDs.

104

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Not Available

If this flag is set, only tables are displayed that have the status not
available.

REORG Pending

If this flag is set, only tables are displayed that have the status
REORG PENDING.

Index Type-1

If this flag is set, only tables are displayed that still have Type1
indexes.

Load Status

If this flag is set, only tables are displayed that have the status LOAD
PENDING.

Row Compression

If this flag is set, only tables are displayed that have been
recommended for row compression.

Display Options
Sort by

Sorts the tables by Size or Name

Maximum Number of
Rows

Number of rows to be displayed

Example
To display the first hundred tables with the largest size, choose Size in the Display Options
group box and enter 100 in the Maximum Number of Rows field.
End of the example.
When you have made your selections and chosen OK, the Space: Table and Indexes screen
appears with the following information:
Column

Description

Schema

Schema of the table, usually the user who created the table

Table Name

Name of the table

Tablespace Name

Tablespace to which the table currently belongs

F1

Overflows rows as a percentage

F2

Table size divided by allocated space as a percentage

F3

Full pages divided by allocated pages as a percentage

Table Flagged

Indicates that table reorganization is recommended

Index Flagged

Indicates that table reorganization is recommended because of

April 2010

105

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
REORGCHK recommendations for at least one of the table indexes

Size (KB)

Table size

REORG Check Date

Date of the last REORG check, for example, the date when RUNSTATS
ran using program dmdb6srp

REORG Check Time

Time of the last REORG check, for example, the time when RUNSTATS
ran using program dmdb6srp

If you want to change the selection, choose Set Selection Criteria. The Selection Criteria
dialog box appears and you can make your new selection.
To display detailed information on tables and indexes, double-click a table or choose Details.
A detail screen is displayed with information on tables, indexes, and table structures. You can
directly access this screen by choosing Space Single Table Analysis in the navigation
frame of the DBA Cockpit. For more information, see Space: Single Table Analysis [page
106].
Note
The data displayed is based on a set of database tables that have been filled by the job
REORGCHK for all Tables. This job must have been scheduled using the DBA Planning
Calendar. If the job is not running, no current data is available.
End of the note.

3.5 Space: Single Table Analysis

You can access detailed information on a single table and maintain table statistics by calling
the DBA Cockpit and choosing Space Single Table Analysis in the navigation frame of
the DBA Cockpit. The Space: Tables and Indexes Details screen appears.
The following information is displayed:
Table and Index Details
Field

Description

Name

Name of the table

Schema

Schema of table, that is usually the user who created the table

106

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Information Available on the Individual Tab Pages

The following tab pages are available on the Space: Tables and Indexes Details screen:
Table
Indexes
Table Structure
RUNSTATS Control
Index Structures
RUNSTATS Profile
Table Status
Compression Status
The information displayed on the individual tab pages is described in more detail in the
following sections.
Table
Field

Description

REORG Check Statistics

Last REORG Check

Date and time of the last REORG check, for example, the date
and time when RUNSTATS ran using program dmdb6srp

Total Table Size

Size of table in KB

Total Index Size

Size of all indexes of the table in KB

Free Space Reserved

Percentage of free space reserved in the tables allocated

pages
This free space is taken into account by LOAD and REORG.

F1: Overflow Rows

Overflow rows as a percentage

F2: Table Size / Allocated

Space

Table size divided by allocated space as a percentage

F3: Full Pages / Allocated

Pages

Full pages divided by allocated pages as a percentage

REORG Pending

Indicates whether a REORG is pending for the table

Last REORG of Table

Date and time when the last REORG ran

Runtime of Last REORG

Runtime of the last REORG

April 2010

107

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

System Catalog
Last RUNSTATS

Date and time when the last RUNSTATS ran

Tablespace

Name of the tablespace to which the table belongs

Cardinality

Number of data records in the table

Counted Rows

Number of rows that have been counted by a SELECT(*)

statement
This information is only displayed if you choose Count.

Deviation

Deviation of the number of rows provided by RUNSTATS in

the system catalog from the number of rows provided by a
SELECT COUNT(*) statement
This information is only displayed if you choose Count.
Number of records that have overflowed

Overflow Records

Records overflow when a data record is updated and the new

data record is larger than the old one or when a column is
added to a table.

No. of Pages with Data

Number of pages containing data

Total Number of Pages

Total number of pages in the table

Caution

Pooled, Cluster or
Import/Export Table

This information only applies to SAP systems (ABAP only).

End of the caution.
Indicates whether this table is defined as a pooled table, a
cluster or an import/export table in the ABAP Dictionary.
Indicates whether the table is flagged as VOLATILE in the
system catalog or not
If the table is flagged as VOLATILE, statistics are not
gathered by DB2s automatic RUNSTATS. In addition,
statistics data, if available, is not used by the optimizer.

VOLATILE
Note
Newly created tables and tables that were dropped or recreate during an upgrade or a table conversion are always
marked as VOLATILE as long as there are not yet valid
statistics available.

108

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
End of the note.

Value Compression

Indicates whether value compression is enabled for the table

Row Compression

Indicates whether the table is compressed

Distributed Statistics

Indicates whether the table has a distributed statistics or not

Indexes
Field

Description

Index
Name

Name of the index

Schema

Schema of the index, that is usually the user who created the
index

Tablespace

Name of the tablespace to which the index belongs

Type

Index type

REORG Check Statistics

Last REORG Check

Date and time of the last REORG check, for example, the date
and time when RUNSTATS ran using program dmdb6srp

Indexes Require Rebuild

Indicates whether an index requires rebuild or not

Cardinality

Number of entries in the index

Percentage of free space reserved in the index pages

Free Space Reserved

This free space is taken into account by LOAD and REORG.
F4: Cluster Ratio

Cluster ratio as a percentage

F5: Index Size / Allocated

Space

Index size divided by allocated space as a percentage

F6: No. Entries / No. Poss.

Entries

Number of entries divided by the number of possible entries

as a percentage

F7: Ratio of Deleted Index

Entries

Number of deleted entries in relation to total entries in index

F8: Ratio of Deleted Index

Number of deleted tree leafs in relation to total tree leafs of

April 2010

109

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field
Leafs

Description
index tree

System Catalog
Last RUNSTATS

Date and time when the last RUNSTATS ran

Number of Leaves

Number of index leaves

Number of Levels

Number of index levels

Sequential Pages

Number of index leaves physically located on the hard disk

sorted by index without large intervals between them

Density

Relative density of the sequential pages as a proportion of

the total number of index pages
100% is the optimum value.

Cluster Ratio

Degree of fragmentation of the index (100% means no

fragmentation and is the optimum value)
Not currently calculated

Cluster Factor
The value is set to 1.
First Key Cardinality

Number of different values in the first column of the index

First 2 Key Cardinality

Number of different values in the first two columns of the

index

First 3 Key Cardinality

Number of different values in the first three columns of the

index

First 4 Key Cardinality

Number of different values in the first four columns of the

index

Full Key Cardinality

Number of different values in all columns of the index

Note
If the value displayed in field Full Key Cardinality is the same as the one displayed in field
Cardinality, the index is a unique index. Every record in the table can be accessed using that
index.
End of the note.

110

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If several indexes are defined on a table, you can use the page buttons on Index to navigate
between the different indexes.
Table Structure
Column

Description

DB Column No.

Number of the column in the database

DB Column Name

Name of the column in the database

DB Type

Data type of the column in the database

DB Length

Length of the column in the database

The following information is only displayed for the local system and if the table is defined as a
transparent table in the ABAP Dictionary
Column

Description

SAP Column Name

Name of the column defined in the ABAP

Dictionary

SAP Key

Column is part of primary key defined in the

ABAP Dictionary

SAP Type

Data type of the column defined in the ABAP

Dictionary

SAP Length

Length of the column defined in the ABAP

Dictionary

RUNSTATS Control
For RUNSTATS Control, you have to take the following into consideration:
Scheduling of RUNSTATS for a table
Which types of statistics are gathered
Both scheduling and profiling depend on the configuration of automatic RUNSTATS. If
automatic RUNSTATS is enabled, the following scheduling options are available:
Field

Description

Statistics Attributes
Not VOLATILE
(AutoRUNSTATS included)

The VOLATILE attribute is not set for this table and therefore
the table will get statistics controlled by automatic RUNSTATS.

VOLATILE (AutoRUNSTATS The VOLATILE attribute is set for this table. automatic
excluded)
RUNSTATS does not take this table into account.

April 2010

111

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If automatic RUNSTATS is not enabled, the following options are available instead:
Field

Description

Scheduling

Automatically

Statistics and REORGCHK calculations are gathered by CCMS

jobs that are scheduled in the DBA Planning Calendar [page
166].

On User Request

CCMS jobs do not process these tables automatically, that is

RUNSTATS and REORGCHK must be explicitly scheduled by the
user.

Statistics is out-of-date

Due to the monitored number of update activities, the statistics

might be out-of-date. As a consequence, a RUNSTATS is
recommended.

Deviation

Deviation of the current size (cardinality) in the table statistics

from the size that was estimated based on the monitored
number of update activities

Collect Data for Application

Monitor

The table is monitored by the application monitor ST07.

Statistics Attributes

Statistics

Statistics are gathered for this table. As soon as there are

valid statistics the table will be marked as NOT VOLATILE in
the system catalog.

No Statistics and Volatile

The table is marked as VOLATILE and has no statistics.

If you want to execute a RUNSTATS, you can choose one of the following options:
Use Profile
This option is only available if a RUNSTATS profile has been set before. By choosing
this option, a RUNSTATS is performed using exactly the same settings as specified in
the profile.
Customized Settings
If you want to determine how the statistics are collected, you can choose Customized
Settings.

112

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following table lists the table analysis methods and index analysis methods that you can
specify if you chose Customized Settings for the collection of statistics:
Field

Description

Table Analysis Method

Basic

Basic statistics for the table

Distributed Statistics

Distributed statistics for the table

No statistics for the table
Caution

None
Selecting this option does only freeze already existing
old table statistics but not delete or invalidate them.
End of the caution.
Percentage of entries to be used for sampling
Sampling of [ ] %of entries

Caution
This field is only active if you are using DB2 UDB for
UNIX and Windows Version 8, FixPak 2 or higher.
The data to be sampled is selected page by page.

System (Page, Sampling)

Caution
This field is only active if you are using DB2 UDB for
UNIX and Windows Version 8, FixPak 2 or higher.
The data to be sampled is selected row by row.

BERNOULLI (Row Sampling)

Caution
This field is only active if you are using DB2 UDB for
UNIX and Windows Version 8, FixPak 2 or higher.

Analyze Key Columns only

Table statistics are gathered only for key columns of the

table.

Index Analysis Method

Basic

Basic statistics for the index

Detailed Statistics

Detailed statistics for the index

Detailed Sampled Statistics

Detailed statistics for the index using sampling

April 2010

113

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
No statistics for the index
Caution

None
Selecting this option does only freeze already existing
old index statistics but not delete or invalidate them.
End of the caution.

Index Structures
Column
Position

Description
Position of the column within the key
Sort order of the column:
A = ascending order

Order

D = descending order
DB Column Number

Number of the column in the database

DB Column Name

Name of the column in the database

DB Type

Data type of the column in the database

DB Length

Length of the column in the database

Note
The following information is only displayed for the local system and if the table is defined as a
transparent table in the ABAP Dictionary:
Column

Description

SAP Column Name

Name of the column defined in the ABAP Dictionary

SAP Type

Data type of the column defined in the ABAP Dictionary

SAP Length

Length of the column defined in the ABAP Dictionary

End of the note.

If several indexes are defined on a table, you can use the page buttons on Index Structures
to navigate between them.

114

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

RUNSTATS Profile
If a RUNSTATS was executed using the PROFILE option, this profile is stored in the system
catalog and is displayed on the screen. The profile is the same as the RUNSTATS command
that was executed with the SET PROFILE option.
Table Status
On this tab page, you find information about the size and status of tables and indexes
provided by DB2's stored procedure ADMIN_GET_TABINFO:
Field

Description

Physical Size
Amount of disk space in KB that is physically allocated for the table
Data Objects

For multi dimensional clustering tables (MDC tables), this size

includes the size of the block map object. This size represents the
physical size of the base table only. Space that is consumed by
LOB data, long data, indexes, and XML objects is reported by
other fields as described in the following.

Long Objects

Amount of disk space in KB that is physically allocated for long

field data in a table

LOB Objects

Amount of disk space in KB that is physically allocated for long

field data in a table

XML Objects

Amount of disk space in KB that is physically allocated for XML

data in a table

Index Objects

Amount of disk space in KB that is physically allocated for the

indexes

Logical Size
Amount of disk space in KB that is logically allocated for the table
Data Objects

For MDC tables, this size includes the logical size of the block map
object. This size represents the logical size of the base table only.
Space that is consumed by LOB data, long data, indexes, and XML
objects is reported by other fields described in the following.

Long Objects

Amount of disk space in KB that is logically allocated for long field

data in a table

LOB Objects

Amount of disk space in KB that is logically allocated for long field

data in a table

April 2010

115

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

XML Objects

Amount of disk space in KB that is logically allocated for XML data

in a table

Index Objects

Amount of disk space in KB that is logically allocated for the

indexes

Availability and Other

Technical Information
Indicates the status of the table
The following values are possible:
No
The table is not available and all other output information
that relates to the size and state is 0.
Available

YES
The table is available.
Note
Rollforward through an unrecoverable load makes a table
unavailable.
End of the note.
Current status of an inplace table reorganization on the table
The following values are possible:
ABORTED
The inplace table reorganization is in PAUSED state but
unable to resume. A STOP is required.

Inplace REORG Status

EXECUTING
NULL
This value is only possible if no inplace reorganization has
been performed on the table.
PAUSED
Read Access Only

If the table is read-only, the value is YES. Otherwise, the value is

NO.

No Load Restart

The value YES indicates that the table is in partially loaded state
that does not allow a load restart. Otherwise, the value NO is
returned.

116

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Indicates if or not a table is using large row IDs (RIDs) (4-byte

page number, 2-byte slot number)
The following values are possible:
YES
The table is using large RIDs.
Large RIDs

NO
The table is not using large RIDs.
PENDING
The table supports large RIDs (that is, the table is in a
large tablespace) but at least one of the indexes for the
table has not yet been reorganized or rebuilt. Therefore,
the table is still using 4-byte RIDs, which means that action
must be taken to convert the table or indexes.
Indicates whether or not the table is using large slots (which allows
more than 255 rows per page)
YES
The table is using large slots.
NO

Large Slots
The table is not using large slots.
PENDING
The table supports large slots (that is, the table is in a large
tablespace) but there has not yet been an offline table
reorganization or a table truncation operation. Therefore,
the table is still using a maximum of 255 rows per page.
Indicates the number of blocks pending cleanup for MDC tables.
Blocks Pending Cleanup
For non-MDC tables this value is always 0.
The following values are possible:
System fabricated
Statistics are gathered by the system without a table or an
index scan.
Type of Statistics
These statistics are stored in memory and are different
from the statistics that are stored in the system catalog.
This is a temporary state and eventually full statistics are
gathered by DB2 and stored in the system catalog.
System asynchronously gathered

April 2010

117

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Statistics are gathered asynchronously by the system.

The statistics have been collected automatically by DB2 by
a background process and stored in the system catalogs.
System synchronously gathered
Statistics are gathered synchronously by the system.
User gathered
Statistics are gathered by the user.
Undef
Unknown type or information that is not available for the
current database release
Note
The physical sizes returned consider full extents allocated for the appropriate object and
include the Extent Map Page (EMP) extents for objects created in DMS tablespaces.
The logical size is the amount of space that is known for this table. It might be less than the
amount of space that is physically allocated to hold object data for the table, for example, in
case of a logical table truncation. The logical size returned considers full extents that are
logically allocated for the object and, for objects created in DMS tablespaces, an estimate of
the EMP extents.
End of the note.
Compression Status
On this tab page, you can find information about compression. Current compression details
are only available if the table has already been compressed. Compression checks are only
available if either the compression check has been explicitly performed by using the
Compression Check button or the job REORGCHK for all tables has been scheduled before
with the option With Compression Check.
Field

Description

Compression Detail
Current Dictionary Size

Current size of compression dictionary in bytes

Average Length of Compressed Rows

Average length of compressed records in bytes

Average Compression Ratio by Row

Average compression ratio by row

Average Length of Compressed and

Uncompressed Rows

Average length of all rows (compressed and

uncompressed) in bytes

Percentage of Compressed Rows from

Total Number of Rows

Percentage of compressed rows compared to total

number of rows

118

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description
Percentage of pages saved by compression

Approximate Percentage of Pages Saved

(excl. LOBS)

Note
Only data pages are taken into account.

Compression Check Results

Estimated Dictionary Size

Estimated size of compression dictionary in bytes

if table will be compressed

Estimated Saved Pages

Estimated amount of pages in percent that will be

saved after compression

Estimated Saved Bytes

Estimated amount of bytes in percent that will be

saved after compression

Rows too Small

Number of rows that were too small to be used for

compression calculation

Last Check

Date and time of last compression check

Checking and Updating the Statistics

You can check the quality of the statistical information in the system catalog by entering a
table name and a schema in the Table and Index Details group box and by choosing Count.
This counts the current number of rows in the table. Afterwards two additional fields, Counted
Rows and Deviation in %, are displayed on the Table tab page. If the deviation is more than
15%, you should perform a RUNSTATS on this table. You can do this by choosing either of the
following options:
RUNSTATS in Dialog
RUNSTATS in the Background
In this case, you switch to the DBA Planning Calendar with a planning proposal for a
single table RUNSTATS and with all parameters preset according to the RUNSTATS
control parameters. For more information, see The DBA Planning Calendar [page
166].
Recommendation
For larger tables, we strongly recommend that you run RUNSTATS in the background.
End of the recommendation.
Caution
Be aware that running RUNSTATS might have an impact on the system performance.
End of the caution.

April 2010

119

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

In case of RUNSTATS in dialog and RUNSTATS in the background, the RUNSTATS can be
performed based on the changeable parameters that you specified on the RUNTSTATS
Control tab page. If you have modified any of the control parameters, the RUNSTATS
Execution dialog box appears. You can choose one of the following options:
Use modified parameters
Caution
Be aware when choosing this option, you have to take into account that the statistics
are overwritten by an automatically triggered RUNSTATS job if you had previously
selected Automatically by CCMS on the RUNSTATS Control tab page.
End of the caution.
Use active parameters
Use modified parameters and save (If automatic RUNSTATS is enabled, this option is
not available.)

3.6 Space: Virtual Tables

An SAP system contains thousands of empty tables consuming a lot of space in the DB2
tablespaces. These empty tables also generate an additional load on database administration
tasks and autonomic features, for example, automatic RUNSTATS and automatic REORG.
Each empty table uses:
One EMP extent
One data extent
Two extents for the index object
One page for each index
Two extents for LONG field object
Four extents for LOB object
A simple empty table with a primary key requires five to11 extents, which translates into 160
KB to 352 KB on a tablespace with a page size of 16 KB and with an extent size of 2. To save
this unnecessary allocated space, you can replace these empty tables with views, which are
called virtual tables in this context. On the first WRITE operation on such a virtual table, this
virtual table is automatically replaced with a table by the SAP system.
You can access the screen Space: Virtual Tables screen by calling the DBA Cockpit and
choosing Space Virtual Tables in the navigation frame of the DBA Cockpit.

120

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

On the screen Space Virtual Tables the following tab pages are available:
Virtual Tables
Contains a list of all virtual tables that exist in your SAP systems
To materialize a single or multiple tables, select one or more tables and choose
Materialize.
Candidates for Virtualization
Displays a list of tables that are candidates for being dropped and re-created as
virtual tables. If you choose Convert Empty Tables, a background job is scheduled
that checks each table if it is:
o

Empty

Not volatile

Does not have a partitioning key

Not using MDC tables

Tables that meet these conditions are dropped and re-created as virtual tables.
Note
The use of virtual tables is transparent to the ABAP Dictionary.
End of the note.
Caution
Before you drop tables and re-create them as virtual tables, make sure that you have read
SAP Note 1151343.

3.7 Space: History - Overview

Note
This function is only available if you have selected Collect History Data when you configured
your database for remote monitoring. For more information, see Configuring Systems for
Remote Monitoring Using Remote Database Connections.
End of the note.
You can access the History - Overview screen by calling the DBA Cockpit and choosing
Space History Overview in the navigation frame of the DBA Cockpit. The History
Overview screen appears.

April 2010

121

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed:

Databases and Tablespaces
Field

Description

Tablespaces
Last Analysis

Date and time of the last analysis

Total Number

Total number of tablespaces in the database

Total Size

Total size of all tablespaces in KB

Free Space

Free space in all tablespaces in KB

Used Space

Used space of all tablespaces as a percentage

Minimum Free Space in a

Tablespace

Free space of the tablespace with the lowest amount of free

space in KB

Maximum Used Space in a

Tablespace

Used space of the tablespace with the highest fill level as a

percentage

Database Partitions
Number of database partitions
Total Number

The value displayed is only higher than 1 if you are using a

multi partition database.

Tables and Indexes

Field

Description

Last Analysis

Date and time of the last analysis

Total Number of Tables

Total number of tables defined in the database

Total Size of Tables

Total amount of used space of all tables defined in the

database

Total Number of Indexes

Total number of indexes defined in the database

Total Size of Indexes

Total amount of used space of all indexes defined in the

database

Oldest REORG Check

Date and time of the oldest execution of the job REORGCHKfor

all tables

Latest REORG Check

Date and time of the latest execution of the job REORGCHK for
all tables

122

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The job to collect the database and tablespace history and the job to collect tables and
indexes history are triggered by the standard performance collector job
SAP_COLLECTOR_FOR_PERFMONITOR. You can display the schedule of these two jobs
in the DBA Planning Calendar by choosing Jobs DBA Planning Calendar in the DBA
Cockpit. In the Category group box you can choose DB Collectors. The default setting is DBA
Actions.
Caution
Calculating table values with outdated statistics can result in inaccurate values. To calculate
update statistics including the calculation of table sizes, use the DBA Planning Calendar
[page 166].
End of the caution.

3.8 Space: History - Database and Tablespaces

Note
This function is only available if you have selected Collect History Data when you configured
your database for remote monitoring. For more information, see Configuring Systems for
Remote Monitoring Using Remote Database Connections.
End of the note.
You can access history data on the database and tablespaces by calling the DBA Cockpit
and choosing Space History Database and Tablespaces in the navigation frame of
the DBA Cockpit. The History Database and Tablespaces screen appears. By default, the
database history is displayed.
To switch to the tablespace history, select Tablespaces in the Object Selection field. The
following information is displayed:
Space
Column

Description

Tablespace Name

Name of the tablespace (only displayed if you have selected

Tablespaces in the Object Selection field)

Partition

Monitored partition - displayed only if you are using a multi

partition database

KB Total

Amount of space in KB allocated

Average change of KB Total

Changes (KB Total)

KB Used

April 2010

The average value depends on your selection in the Statistics

field.
Used space in KB of the allocated space

123

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

Changes (KB Used)

Average change of used space

% Used

Percentage used of allocated space

KB Free

Free space in KB of allocated space

Containers

Number of containers belonging to the tablespace

Changes Containers

Average change of number of containers

Tables and Indexes

Tables and Indexes
Column

Description

Tablespace Name

Name of the tablespace (only displayed if you have selected

Tablespaces in the Object Selection field)

Tables

Number of tables

Changes Tables

Average change of number of tables

Table (KB)

Space used by tables

Changes Table (KB)

Average change of space used by tables

Indexes

Number of indexes

Changes Indexes

Average change of number of indexes

Index (KB)

Space used by indexes

Changes Index (KB)

Average change of space used by indexes

If you want to display delta values between available measurements, select a row and
choose Details. Alternatively, you can double-click the selected row. The table will be
displayed again with the following difference: Columns with the heading Changes... are
renamed with Delta...

124

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3.9 Space: History - Tables and Indexes

Note
This function is only available if you have selected Collect History Data during the
configuration of your database for remote monitoring. For more information, see Configuring
Systems for Remote Monitoring Using Remote Database Connections.
End of the note.
You can access history data on tables and indexes by calling the DBA Cockpit and choosing
Space History Tables and Indexes in the navigation frame of the DBA Cockpit.
A Set Selection Criteria dialog box appears in which you can limit the result set displayed
according to the following criteria:
Field

Description

Filters
Tablespace Name

Name of the tablespace

Table or Index Name

Name of the table or index

Table or Index Size

Size of the table or index

Display Options
Sort by

Sorts the tables or indexes by Growth, Size or Name

Maximum Number of Rows

Number of rows to be displayed

Example
To display the first hundred tables or indexes with the highest growth, choose Growth in the
Display Options group box and enter 100 in the Maximum number of rows field.
End of the example.
When you have made your selections and chosen OK, the History Table and Index screen
appears with the following information:
Column

Description

Object Name

Name of the table or index

Object Type

Table or index

Tablespace Name

Tablespace to which the objects belong

Size (KB)

Size of the table or index

April 2010

125

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

Changes Size (KB)

Average change of space used by table or indexes

REORG Check Date

Date of the last REORG check, for example, the date when
RUNSTATS ran using program dmdb6srp

REORG Check Time

Time of the last REORG check, for example, the time when
RUNSTATS ran using program dmdb6srp

If you want to display delta values between available measurements, select a row and
choose Details. Alternatively, you can double-click the selected row. The table will be
displayed again with the following difference: Columns with the heading Changes... are
renamed with Delta...
If you want to change the selection criteria, choose Set Selection Criteria.

126

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4 Backup and Recovery

The following sections provide information on backup and recovery:
Backup and Recovery: Backup Overview
Backup and Recovery: Logging Parameters

4.1 Backup and Recovery: Backup Overview

You can access the Overview screen by calling the DBA Cockpit and choosing
Recovery Backup Overview in the navigation frame of the DBA Cockpit.

Backup and

The following information is displayed:

Tab

Description
Contains information on database backups

Database
Backups

Log Files

The screen is divided into two frames. The left frame provides information on
database backups done in the past. If you want to display detailed information
on a database backup, double-click the field. The details are displayed in the
right frame.
Contains information on log files that have been moved from the log directory to
the log archive or to a storage product, such as Tivoli Storage Manager (TSM)

If you want to display older information on database backups, change the value in the Display
Days field in the Backup and Recovery: Overview group box.

4.2 Backup and Recovery: Logging Parameters

You can access information on logging parameters by calling the DBA Cockpit and choosing
Backup and Recovery Logging Parameters in the navigation frame of the DBA Cockpit.
The Logging Parameters screen appears.
This screen provides information on the logging parameters configured, such as size of log
files, log retain status or user exit status. Furthermore, you can check the available space of
the file systems where your database logs and the archived database logs are stored.
However, these directories are only displayed in the lower half of the screen if the monitored
systems are SAP ABAP systems.
Caution
In a production system, the User Exit for Logging Status field must be set to YES.
If this is not the case, you risk losing data and the ability to roll forward your database if
serious database problems occur.

April 2010

127

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5 Configuration
The following sections provide information on configuration:
Configuration: Overview
Configuration: Database Manager
Configuration: Database
Configuration: Registry Variables
Configuration: Parameter Changes
Configuration: Database Partition Groups
Configuration: Buffer Pools
Configuration: Special Tables Regarding RUNSTATS
Configuration: File Systems
Configuration: Data Classes
Configuration: Monitoring Settings
Configuration: Automatic Maintenance Settings

5.1 Configuration: Overview

You can access general information about the database instance by calling the DBA Cockpit
and choosing Configuration Overview in the navigation frame of the DBA Cockpit. The
Configuration: Overview screen appears.
The following information is displayed:
Group Box

Description

Database Instance
Name

Name of the database instance

Partitionable

Indicates whether or not the current instance is a partitionable

database server instance
Number of database partitions

Number of Partitions
If the database environment is not partitioned, the value is 1.

128

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Address Space

Size of the current database instance in Bit (32 or 64)

Database Release

DB2-internal release number, as it is returned if you use the db2level

command, for example, 03030106

Service Level

Service level, as it is returned if you use the db2level command, for

example, DB2 v8.1.1.80

Build Level

Build level, as is returned if you use the db2level command, for

example, n041021

PTF

Program temporary fix (PTF) identifier, as it is returned if you use the

db2level command, for example, U498350

Fix Pack

Fix Pack number, as it is returned if you use the db2level command,

for example, 9

Operating System
Name

Name of the operating system

Version

Version number of the operating system

Release

Release number of the operating system

Host Name

Name of the system

Total CPUs

Total number of physical CPUs of the system

Configured CPUs

Number of configured physical CPUs of the system

Total Memory

Total amount of memory in the system in MB

If the system has been installed as a high availability disaster recovery (HADR) system, the
following additional information is displayed:
Group Box

Description

HADR Information
The current HADR connection status of the database
The following values are possible:
Connect Status

CONGESTED
CONNECTED
DISCONNECTED

April 2010

129

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Local HADR host name

Local Host

The value is displayed as a host name string or an IP address

string, for example, 1.2.3.4.
Local HADR TCP service

Local Service

Log Gap

The value is displayed as a service name string or a port number

string.
Running average of the gap between the primary log sequence
number (LSN) and the standby log LSN
The gap is measured in bytes.

Primary Log File

Name of the current log file on the primary HADR database

Current log position of the primary HADR database

Primary Log LSN

The log sequence number (LSN) is a byte offset in the log stream
of the database.
Page number in the current log file indicating the current log
position on the primary HADR database

Primary Log Page

The page number is relative to the log file, for example, page zero
is the beginning of the file.
The current HADR synchronization mode of the database
The following values are possible:
HADR Syncmode

ASYNC
NEARSYNC
SYNC

HADR Timeout

Number of seconds without any communication from its partner

server after which an HADR database server will consider that the
connection between them has failed
Number of missed heartbeats on the HADR connection

Heartbeat

130

If the database is in HADR primary or standby role, this element

indicates the health of the HADR connection.

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If the database is in HADR primary or standby role, the meaning of

this field depends on the value of the Connect Status field. The
following values are possible:
CONNECTED
Displays the connection time
CONGESTED
Displays the time when the congestion began
Connect Time

DISCONNECTED
Displays the disconnection time
If there had been no connection since the HADR engine
dispatchable unit (EDU) was started, the connection status is
reported as Disconnected and the HADR EDU startup time is used
for the disconnection time.
Since HADR connect and disconnect events occur relatively
seldom, the time is collected and reported even if the
DFT_MON_TIMESTAMP switch is off. This element should be
ignored if the database's HADR role is STANDARD.
Host name of the HADR remote host

Remote Host

Remote Instance

The value is displayed as a host name string or an IP address

string, for example, 1.2.3.4.
Name of the HADR remote instance
Remote HADR TCP service

Remote Service

This value is displayed as a service name string or a port number

string.
Current HADR role of the database
The following values are possible:

HADR Role

PRIMARY
STANDARD
STANDBY

April 2010

131

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Current HADR state of the database

The following values are possible:
DISCONNECTED
HADR State

LOCAL_CATCHUP
PEER
REM_CATCH_PEN
REM_CATCHUP

Standby Log File

Name of the current log file on the standby HADR database

Current log position of the standby HADR database

Standby Log LSN

Log sequence number (LSN) is a byte offset in the log stream of

the database.
Page number in the current log file indicating the current log
position on the standby HADR database

Standby Log Page

The page number is relative to the log file, for example, page zero
is the beginning of the file.

5.2 Configuration: Database Manager

You can access information about the configuration of the database manager by calling the
DBA Cockpit and choosing Configuration Database Manager in the navigation frame of
the DBA Cockpit. The Configuration: Database Manager screen appears.
The following information is displayed as a tree structure:
Tree node

Description

Common

Common information about the database manager, for

example, release level and CPU speed

Diagnostics

Information about diagnostics

Default Monitor Switches

Information about the default monitor switches of the database

Security - Groups

Information about user groups of the database manager

Security Authentication

Information about authentications of the database manager

and on clients

132

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tree node

Description

Memory

Information about the memory of the database manager

Agents

Information about agents

Application Remote Interface

Information about the database application remote interface

(DARI)

Sync Point Manager

Information about the configuration of the synchronization

manager and the transaction manager

Transaction Manager

Information about the transaction manager

Network

Information about network characteristics such as

communication protocols

Fast Communication
Manager

Information about the Fast Communication Manager (FCM),

that is, the configured communication in a multi partition
database

DB2 Discovery

Information about the configuration of the discovery mode

Others

Single parameters that are not accessible to the groups

described above as well as parameters that are not known by
the DBA Cockpit, for example, those of new database release

The database manager parameters are displayed with a short description and the technical
name that was defined by DB2. If you need to change a parameter, use the following
command:
UPDATE DATABASE MANAGER CONFIGURATION using <keyword> <value>
Note
In a multi partition environment, the database manager parameters are the same for all
partitions. Therefore, All is displayed in the Partition field in the Database Manager
Configuration group box.
End of the note.
For more information about these parameters, see the IBM DB2 online documentation.
In addition, you can maintain the database configuration parameters. For more information,
see Maintaining the Database Configuration [page 135].

April 2010

133

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.3 Configuration: Database

You can access information on database configuration by calling the DBA Cockpit and
choosing Configuration Database in the navigation frame of the DBA Cockpit. The
Configuration: Database screen appears.
The following information is displayed as a tree structure:
Tree node

Description

Common

Common information about the database, for example, release

level and country code

Automatic Maintenance

Information about the automatic maintenance switches

Optimization

Information about optimization

I/O

Information about I/O

Self-Tuning Memory
Manager

Information about the self-tuning memory manager

Database Shared Memory

Information about the memory that is available for the database

Application Memory

Information about the memory that is available for the

application

Logging

Information about log files and logging parameters

Log File Management

Information about log file management parameters

Backup & Recovery

Information about recovery availability and backups

TSM

Information about Tivoli Storage Management (TSM)

Locks

Information about locks, for example, the percentage of lock

lists per application

Space

Information about containers and tablespaces

Applications

Information about applications that connect to the database

DB2 Data Links Manager

Information about the DB2 Data Links Manager (DB2 Version 8

only)

High Availability

Information about the system configuration is only displayed if

you are running a high availability system.

Others

Single parameters that are not accessible to the groups

described above as well as parameters that are not known by
the DBA Cockpit, for example, those of a new database release

134

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The database parameters are displayed with a short description and the technical name that
was defined by DB2. If you need to change a parameter, use the following command:
UPDATE DATABASE CONFIGURATION for <system> using <keyword> <value>
Note
In multi partition environment, the parameters can vary for each partition. For more
information about how to compare the configuration of several database partitions, see
Comparing Database Configuration Parameters For Several Database Partitions [page 136].
End of the note.
Caution
Depending on your database release level, some tree nodes might not be visible or might
added to the view.
End of the caution.
In addition, you can maintain the database configuration parameters. For more information,
see Maintaining the Database Configuration [page 135].
For more information about these parameters, see the IBM DB2 online documentation.
Displaying the Parameter Value History
Caution
To be able to display a value history, the function must be switched on first by selecting
Collect History Data when you configured your database for remote monitoring. For more
information, see Configuring Systems for Remote Monitoring Using Remote Database
Connections.
End of the caution.
For parameters that are affected by the self-tuning memory manager, you can display a value
history by choosing Show Value History on the Configuration: Database screen.
The result for a parameter is displayed in a separate window. By default, the value history
information is displayed as a chart. By choosing List, you can switch to a tabular view. To limit
the history time frame, choose From or To.

5.3.1 Maintaining the Database Configuration

On the Configuration: Database or Configuration: Database Manager screen, you can
maintain configuration parameters as follows:
1. Double-click the parameter that you want to change.
Detailed information about this parameter is displayed in a new group box in the
lower part of your screen.

April 2010

135

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
If a parameter cannot be changed, the Display <-> Change icon is not displayed.
End of the note.
2. Choose Display <-> Change and enter the new configuration parameter values.
Note
Some configuration parameters are enabled for automatic value adjustment. In this
case, the checkbox AUTOMATIC is displayed. If you select AUTOMATIC, the value
will automatically be maintained by DB2.
End of the note.
3. To check your entries, choose Check Input.
In the lower half of the Configuration: Database Maintain or Configuration:
Database Manager Maintain screen, an editor is displayed that shows the
generated CLP commands that are based on your input. This area is automatically
filled and refreshed whenever you choose Check Input.
4. To confirm your entries, choose Execute.

5.3.2 Comparing Database Configuration Parameters

for Several Database Partitions
1. On the Configuration: Database screen, choose Compare Partitions.
The Select Partitions dialog box appears.
2. Select the database partitions that you want to compare and choose Compare.
The database configuration parameters for the selected database partitions are
displayed in a table. The values that differ from one another are marked blue.
Note
By default, only the parameters that differ from one another are displayed. If you want
to display all parameters, choose Filter.
End of the note.

136

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.4 Configuration: Registry Variables (DB2 for

Linux, UNIX, and Windows
You can access information about DB2 registry variables by calling the DBA Cockpit and
choosing Configuration Registry Variables in the navigation frame of the DBA Cockpit.
The Configuration: Registry Variable screen appears displaying the information as a tree
structure. Aggregate variables are displayed as a folder that contain all the registry variables
affected by the aggregate variable.
Note
The variables that are affected when setting an aggregate variable, such as DB2_WORKLOAD,
are grouped in folders. If the value of such a variable has been manually overwritten, it is
marked yellow.
End of the note.
The Scope variable indicates the level at which the DB2 registry variable acquires its value.
These levels are as follows:
Instance
Global
Environment

5.5 Configuration: Parameter Changes

This screen displays current and previous settings of the DB2 database manager
configuration parameters and the DB2 database configuration parameters, together with the
respective date of change.
You can access information on parameter changes by calling the DBA Cockpit and choosing
Configuration Parameter Changes in the navigation frame of the DBA Cockpit. The
Configuration: Parameter Changes screen appears.
In the Parameter Changes group box, you can select from the following options:
Option

Description

Parameter

Active

Displays the current values of the parameters

Parameter

History

Displays all recorded parameter changes made in the

past

Parameter Type

All

Displays both database manager and database

parameters

Parameter Type

Database

Displays database parameters only

April 2010

137

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Option
Parameter Type

DB Manager

Parameter Type

Registry

Description
Displays database manager parameters only
Displays registry variables only

When you have made your selection, the following information is displayed:
Column

Description

Parameter Type

Defines whether the parameter is a database manager

parameter or a database parameter

Parameter Name

Parameters in upper case indicate that the parameter is

modifiable using DB2 CLP. Parameters in lower case
indicate that the parameter is maintained by DB2 (readonly).

Partition

Monitored partition displayed only if you are using a

multi partition database

Date

Date of the change

Time

Time of the change

Parameter Value

Value of the parameter currently set or set in the past

5.6 Configuration: Database Partition Groups

You can access information on available database partition groups by calling the DBA
Cockpit and choosing Configuration Database Partition Groups in the navigation frame
of the DBA Cockpit. The Configuration: Database Partition Groups screen appears.

138

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed:

Column

Description

Database Partition Group

Name of the database partition group

Partition

Number of the partition

Current status of the partition
The following values are possible:
Status information not available
Displayed for database partition group
IBMTEMPGROUP or if the status cannot be determined
Partition not in partitioning map;
containers not yet created
Partition has been created without containers and is
not yet referenced in the partitioning map.

Status
Partition not in partitioning map;
containers created
Partition and containers have been created, but
partition is not yet referenced in the partitioning map.
Partition in partitioning map;
containers created
Partition will be dropped after next
redistribution
For more information, see the DB2 Administration
Guide.
The list of database partition groups contains all database partition groups of which the
selected partition is a member. If you choose All in the Partition field, all available database
partition groups will be displayed.
In addition, you can maintain database partition groups, that is change, add or delete them.
For more information, see Maintaining Database Partition Groups page 140].

April 2010

139

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.6.1 Maintaining Database Partition Groups

Using the list of database partition groups on the Configuration: Database Partition Groups
screen, you can maintain database partition group entries as follows:
Change database partition groups, that is add or remove partitions
Add new database partition groups
Delete database partition groups
Redistribute database partition groups
Changing Database Partition Groups
1. On the Configuration: Database Partition Groups screen, choose Edit.
The Configuration: Database Partition Group Change screen appears.
The following information is displayed:
Partitions
This tab page contains a list of all partitions of the database partition group.
Field

Description

Partition Number of the partition

Current status of the partition
The following values are possible:
o

Status information not available

Displayed for database partition group IBMTEMPGROUP or if the status
cannot be determined

Partition not in partitioning map; containers not

yet created
Partition has been created without containers and is not yet referenced in
the partitioning map.

Status
o

Partition not in partitioning map; containers

created
Partition and containers have been created, but partition is not yet
referenced in the partitioning map.

o
o

Partition in partitioning map; containers created

Partition will be dropped after next
redistribution
For more information, see the DB2 Administration Guide.

140

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Buffer Pools
This tab page contains a list of all buffer pools that have been defined for the selected
database partition group.
Column
Buffer Pool
Name

Description
Total space in KB
If you create tablespaces, this information is not displayed.
Size of the buffer pool in KB

Buffer Pool
Size (KB)

Page Size

A value of 1 indicates that the default buffer pool size parameter from the
database configuration is used (parameter BUFFPAGE).
Size of one buffer pool page in bytes

For detailed information on buffer pools, double-click the corresponding buffer pool.
Tablespaces
This tab page contains a list of all tablespaces that have been defined for the
selected database partition group.
Field

Description

Tablespace Name

Name of the tablespace

Page Size

Size of one tablespace page in bytes

For detailed information on tablespaces, double-click the corresponding tablespace.

2. To confirm your entries, choose Execute.
3. To apply changes, choose Partitions.
4. You can now add or delete partitions:
o

To add partitions, choose Add Partition.

The system automatically suggests a new partition that has not yet been
defined in the database partition group. You can modify this suggestion by
manually selecting another partition.

To delete partitions, select one or more lines in the table and choose Delete
Partition.

5. To confirm your entries, choose Execute.

April 2010

141

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Adding Database Partition Groups

1. On the Configuration: Database Partition Groups screen, choose Add.
The Configuration: Database Partition Group Add screen appears.
Note
By default, all available partitions are listed to be part of the new database partition
group. Choose Delete Partition if you want to reduce this list.
End of the note.
2. Specify a name for the new database partition group.
Recommendation
We recommend that you use uppercase letters for the database partition group
name. Using lowercase letters or special characters makes accessing the selected
database partition group with the DB2 command line processor less comfortable.
End of the recommendation.
3. To confirm your entries, choose Add.
Deleting Database Partition Groups
1. On the Configuration: Database Partition Groups screen, select a database partition
group.
2. Choose Delete.
The Configuration: Database Partition Group Delete screen appears.
3. To delete the selected database partition group, choose Delete.
Caution
You cannot delete database partition groups that contain tablespaces that are still
being used by the SAP system.
You must delete the tablespaces first.
End of the caution.
Redistributing Database Partition Groups
Note
You can only redistribute database partition groups that have the status Partition not in
partitioning map; containers created.
End of the note.
1. On the Configuration: Database Partition Groups screen, select a database partition
group.
2. Choose Redistribute.

142

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

A scheduling screen of the DBA Planning Calendar appears.

3. Define if you want to redistribute the database partition group immediately or at a
later point in time.
SQL Statements
In the lower half of the Configuration: Database Partition Group screen, an editor is displayed
that shows the generated SQL statement(s) that will be executed. This area is automatically
filled and refreshed if any changes were applied correctly.

5.7 Configuration: Buffer Pools

You can access information on available buffer pools by calling the DBA Cockpit and
choosing Configuration Buffer Pools in the navigation frame of the DBA Cockpit. The
Configuration: Buffer Pools screen appears.
The following information is displayed:
Column

Description

Buffer Pool Name Name of the buffer pool

Partition

Number of the partition (only displayed if you are using a multi partition
database)
Size of the buffer pool in KB. A value of 1 indicates that the default buffer
pool size parameter from the database configuration is used (parameter
BUFFPAGE).

Size (Pages)

AUTOMATIC indicates that the selected buffer pool is tuned by DB2's self
tuning memory management (STMM).
If one of these special values is displayed and you want to see the real
size of the buffer pool, you should use the buffer pool snapshot [page 42].

Page Size (Byte)

Size of one buffer pool page in bytes

The list of buffer pools contains all buffer pools that have been defined for the selected
partition. If you choose ALL in the Partitions field, all available buffer pools will be displayed.
In addition, you can maintain buffer pools, that is change, add or delete them. For more
information, see Maintaining Buffer Pools [page 144].

April 2010

143

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.7.1 Maintaining Buffer Pools

Using the buffer pool list on the Configuration: Buffer Pools screen, you can maintain buffer
pool entries as follows:
Change buffer pools, that is add or remove partitions, resize or control the use of
extended storage
Add new buffer pools
Delete buffer pools
Changing Buffer Pools
1. On the Configuration: Buffer Pools screen, choose Edit.
The screen Configuration: Buffer Pool Maintenance Change Buffer Pool appears.
The following information is displayed:
Technical Settings
This tab page provides a set of all technical attributes:
Column

Description
Partitions that have been defined for the selected buffer pool. The
list depends on the selection of database partition groups. You
can modify the size of the buffer pool on selected partitions or set
the size for all partitions by using the field Set size on all partition
to.

Partition

Caution
In a multi partitioned environment, you can define exception
entries by which the size of the buffer pool on this partition is
different from its size for all other partitions. To remove this entry,
choose Remove Exception Entry next to the Immediate checkbox.
End of the caution.

Buffer Pool Size (Pages)

Displays the buffer pool size in pages or the value AUTOMATIC

Immediate

Indicates that the buffer pool is created or changed immediately

and not after the next system restart.
Field

Description
Specifies the buffer pool size on all partitions

Set size of all partitions

to... (Pages)

Note
This function is not supported for buffer pools that are enabled for
DB2's selftuning memory management

144

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
End of the note.

Page Size

Size of one page in the buffer pool

Block Size

Size of one block for blocked I/O in pages displayed only if you
are using DB2 Version 8

Number of Block Pages

Number of pages that are reserved for block I/O usage

displayed only if you are using DB2 Version 8

Specifies that the buffer pool size is automatically maintained by

Use automatic buffer pool
DB2. You are able to specify a starting value regardless if the
size on all database
automatic buffer pool size was enabled before or if you are only
partitions starting with
switching this feature on.
Database Partition Groups
This tab page contains a list of all database partition groups to which the buffer pool
is related. A buffer pool can be related to all available partitions or to a set of
partitions defined by database partition groups. If the buffer pool is not already
defined on all partitions, you can select further database partition groups.
For detailed information on database partition groups, double-click the corresponding
database partition group.
For more information about the maintenance of database partition groups, see
Maintaining Database Partition Groups [page 140].
Tablespaces
This tab page contains a list of all tablespaces that use this buffer pool.
Column

Description

Tablespace Name

Name of the tablespace

Page Size

Size of one tablespace page in bytes

For detailed information on tablespaces, double-click the corresponding tablespace.

For more information about tablespace maintenance, see Maintaining Tablespaces
[page 98].
2. To confirm your entries, choose Execute.
3. To apply changes, choose Technical Settings or Database Partition Groups.

April 2010

145

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Adding Buffer Pools

1. On the Configuration: Buffer Pools screen, choose Add.
The Configuration: Buffer Pool Maintenance Add Buffer Pool screen appears.
Note
By default, all available partitions are listed to be related to the new buffer pool. If you
want to reduce this list, go to the Database Partition Groups tab page and select
option On Selected Database Partition Groups and choose database partition groups
from the list.
End of the note.
2. Specify a name for the new buffer pool.
Recommendation
We recommend that you use uppercase letters for the buffer pool name. Using
lowercase letters or special characters, makes accessing the selected database
partition group with the DB2 command line processor less comfortable.
End of the recommendation.
3. Enter the technical settings such as the page size.
4. To confirm your entries, choose Add.
Deleting Buffer Pools
1. On the Configuration: Buffer Pools screen, select a buffer pool.
2. Choose Delete.
The Configuration: Buffer Pool Maintenance Delete Buffer Pool screen appears.
3. To delete the selected buffer pool, choose Delete.
SQL Statements
In the lower half of the Configuration: Buffer Pool screen, an editor is displayed that shows
the generated SQL statement(s) that are executed. This area is automatically filled and
refreshed if any changes were applied correctly.

146

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.8 Configuration: Special Tables Regarding

RUNSTATS
You can access information on tables with special RUNSTATS characteristics by calling the
DBA Cockpit and choosing Configuration Special Tables Regarding RUNSTATS in the
navigation frame of the DBA Cockpit.
There are two categories of tables that are treated by the optimizer in a special way due to
their characteristics:
Tables marked as VOLATILE in the system catalog
A volatile table is a table whose content can vary from a few entries to very large
amount of entries at lifetime, that is, statistics data is often out-of-date and may result
in wrong access plans by the optimizer. These tables should be marked as
VOLATILE and should have no statistics at all.
Tables with RUNSTATS control parameters that are not in accordance with the CCMS
standards, for example, special scheduling pattern, different kind of RUNSTATS or
tables that have a profile that may influence automatic RUNSTATS
On the basis of the list displayed, you can check system catalog-related information against
the DBSTATC control table.
The following information is displayed on the Configuration: Special RUNSTATS Settings and
Volatile Tables screen:
Column

Description

Table Schema

Name of the schema to which the table belongs

Table Name

Name of the database table

Indicates whether the table is flagged as VOLATILE in the system
catalog or not

VOLATILE
If the table is flagged as VOLATILE, statistics are not used by the
optimizer.
Type of entry in control table DBSTATC
The following entries are displayed:
N

Active

No RUNSTATS is run by any CCMS program. This status

corresponds to the VOLATILE attribute of a database table,
which prevents the query optimizer from using statistics.
R
No RUNSTATS is run by any CCMS program. The only
exception is that you use program dmdb6srp and explicitly
specify the table.

April 2010

147

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
A
RUNSTATS may be run by CCMS programs.
This information is only relevant if CCMS RUNSTATS is
enabled.

Profile

Indicates whether a RUNSTATS profile was set for the table

RUNSTATS Date

Date of the last RUNSTATS in the system catalog table

RUNSTATS Time

Time of the last RUNSTATS in the system catalog table

Cardinality

Number of rows as calculated by the last RUNSTATS (1 indicates

that there are no statistics available)

Note
If automatic RUNSTATS is not enabled, proceed as follows:
To receive correct results, the RUNSTATS and REORGCHK for all Tables job should have
run at least once.
End of the note.

5.9 Configuration: File Systems

Note
This function is not available for systems monitored using a remote database connection.
End of the note.
The information displayed on this screen helps you to determine how much free space is
available in your file systems to extend tablespaces.
You can access the information by calling the DBA Cockpit and choosing Configuration
File Systems in the navigation frame of the DBA Cockpit. The Configuration: File
Systems screen appears.

148

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed:

Column
Partition

Description
Number of the partition (only displayed if you are using a multi
partition database)
Name of the file system

File System Name

Both local and NFS file systems are displayed.
KB Total

Total size of the file system in KB

KB Used

Total amount used of the file system in KB

Percentage Used

Used percentage of total size of the file system

KB Free

Total amount free of the file system in KB

Percentage Free

Free percentage of total size of the file system in KB

Number of inodes used

Inodes Used

Inodes Used (%)

Inodes are needed to save files in the file system. For each
directory of files a minimum of one inode is used.
Percentage of inodes used

5.10 Configuration: Data Classes

Note
This function is only available for SAP ABAP systems.
End of the note.
The technical settings of SAP tables define data classes that need to be related to database
tablespaces.
You can access the list of available data classes by calling the DBA Cockpit and choosing
Configuration Data Classes in the navigation frame of the DBA Cockpit. The
Configuration: Data Classes screen appears.

April 2010

149

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed:

Column

Description
Green:
No action required
Yellow:
Indicates warnings
Recommendation
We strongly recommend that you take immediate action.
End of the recommendation.
Red:

State

Indicates errors
Immediate action required
The following errors are checked:
Is there a related tablespace for data?
Does the data tablespace exist in the database?
Is there a related tablespace for indexes?
Does the index tablespace exist in the database?
Does the name of the tablespace comply with the naming
conventions for the customer namespace?
Is there a description for the data class?

Data Class

Name of the data class known to the ABAB Dictionary

Data Tablespace

Name of the tablespace where table data is stored

Index Tablespace

Name of the tablespace where table indexes are stored

No. of Tables

Number of tables within the related data tablespace

No. of Indexes

Number of indexes within the related index tablespace

Category

Category of the data class

Description

Description of the data class

In addition, you can maintain data classes, that is change, add or delete them. For more
information, see Maintaining Data Classes.

150

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.10.1 Maintaining Data Classes

Using the data class list on the Configuration: Data Classes screen, you can maintain data
classes as follows:
Change data classes
Add new data classes
Delete data classes
Changing Data Classes
1. On the Configuration: Data Classes screen, choose Edit.
The Change Data Class dialog box appears.
2. If required, change the description.
3. Change the tablespace assignment.
4. To confirm your changes, choose Save.
Caution
Changing the related tablespaces does not affect already existing tables. It will only
influence new tables.
End of the caution.
Adding Data Classes
1. On the Configuration: Data Classes screen, choose Add.
The Add Data Class dialog box appears.
2. Specify a name for the data class using the naming conventions for customer-defined
data classes. If you do not follow these naming conventions, you might receive an
error message.
Caution
Keep in mind that not defining data classes according to the naming conventions has
an impact on future upgrades of your system.
Such entries are not recognized as customer entries and will be lost during the
upgrade.
End of the caution.
Note
You cannot enter a value in the Category field. It always has the value USR.
End of the note.

April 2010

151

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3. Enter a meaningful description.

4. Select a data and index tablespace from the list box.
5. To confirm your entries, choose Add.
Deleting Data Classes
1. On the Configuration: Data Classes screen, choose Delete.
The Delete Data Class dialog box appears.
2. To confirm your entries, choose Delete.
Caution
A data class cannot be deleted if it is used by any table.
End of the caution.

5.11 Configuration: Monitoring Settings

You can use this function to configure the monitoring tools themselves. The following
functions are available:
You can check the user-defined function libraries (UDFs).
Normally, these are automatically configured when you start the DBA Cockpit for a
system for the first time. If the DBA Cockpit recognizes any problem with the UDF
installation of the selected system during its initialization, an error message is
displayed and the CCMS Configuration screen appears automatically.
You can change the retention periods for history data.
These settings are evaluated only if you have selected Collect History Data during
the configuration of your database for remote monitoring. For more information, see
Configuring Systems for Remote Monitoring Using Remote Database Connections
[page 15].
Checking the User-Defined Function Libraries
1. Call the DBA Cockpit.
2. In the navigation frame, choose

Configuration

Monitoring Settings

The Configuration: Monitoring Tool Settings screen appears.

3. Choose UDF Configuration.
The cataloged path and version of the UDF library is displayed. The DBA Cockpit
assumes that this path is the path to the executables of the SAP system as it was
created during the standard installation procedure. The UDF version that is displayed
corresponds to the current patch number of the UDF library db6pmudf.

152

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Caution
If you change the path, keep in mind that the DBA Cockpit only accepts paths that
contain the SAP system ID or an empty path. If you do not indicate a path, DB2
assumes that the UDFs are located in the DB2 UDF library. Any other path that does
not comply with these rules are automatically changed when you start the DBA
Cockpit. The DBA Cockpit then assumes that the UDFs are located in the directory
where the SAP kernel is located.
End of the caution.
4. To test the current path, choose Test.
In case of problems, error messages are displayed during the test. These are
typically some SQL error messages, which indicate, for example, that the UDFs were
not found under the specified path or that the user does not have the required
authorizations.
You must save your changes before you can run the next test.
Changing the Retention Periods for History Data
1. Call the DBA Cockpit.
2. In the navigation frame, choose

Configuration

Monitoring Settings

The Configuration: Monitoring Tool Settings screen appears.

3. Choose History Data.
The values displayed are set by default.
4. To change the values, choose Display<->Change.
5. If you want to switch the DB2 diag log automatically to restrict the size of it to a
manageable value, choose Switch Weekly.
The DB2 diag log is saved under a new name with a timestamp and a new DB2 diag
log is created.
6. If you want to collect history data on a dedicated background server, specify a server
in the Server for Data Collection field.
7. Save your changes.

5.12 Configuration: Automatic Maintenance

Settings
Using DB2's automatic maintenance functions, you prepare the database for automatic
administration. In addition, you should check the settings from time to time to make sure that
they meet the requirements of your production system.

April 2010

153

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Features
You can configure the following functions:
Automatic Backup
Automatic RUNSTATS
Automatic REORG
Activities
To use automatic maintenance for your database, call the DBA Cockpit and choose
Configuration Automatic Maintenance Settings in the navigation frame of the DBA
Cockpit. The screen Configuration: Automatic Maintenance Settings appears.
By default, the General tab page is displayed where you specify the maintenance windows
during which automatic maintenance is performed by DB2.
Note
In this context, online and offline does not mean the state of the database itself
but the time frame with only low activity (online) or no activity (offline) on the
database.
You can specify the following maintenance windows:
Online Maintenance Window
Time frame with only low activity on the database. For example, during an online
maintenance window, you can still be connected to the database.
Offline Maintenance Window
Time frame with no activity on the database. For example, during an offline
maintenance window, neither connections to the database are allowed nor updates
for tables and indexes while they are being reorganized.
Note
Since the tab pages for specifying the online and the offline maintenance
windows are identical, they are only described once. For more information, see
Configuring General Maintenance Settings [page155].
Furthermore, you attach the required function, for example, Automatic REORG, to one of the
maintenance windows. DB2 then decides if any action is required and triggers the correct
action automatically.
More Information
Configuring General Maintenance Settings [page155]
Configuring Automatic Backup Settings [page 155]
Configuring RUNSTATS Settings [page 158]
Configuring Automatic REORG Settings [page 159]

154

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.12.1 Configuring General Maintenance Settings

1.

Call the DBA Cockpit.

2. Choose
frame.

Configuration

Automatic Maintenance Settings

in the navigation

The screen Configuration: Automatic Maintenance Settings appears.

Note
To be able to use the automatic maintenance function, Automatic maintenance is
switched on must be selected on the General tab page.
End of the note.
3. Specify the following parameters:
o

Online maintenance window is enabled or Offline maintenance windows is

enabled

Time of Automatic Maintenance

(Specifies the maintenance window directly or inverted.)

Time

Day of Week

Day of Month

Month of Year

Caution
The definition of all time-related parameters is combined by AND. Therefore, a valid
maintenance window must meet all definitions.
End of the caution.
In the footer of the maintenance window, the actions that are registered for this maintenance
window are displayed as well as whether they are switched on or off.

5.12.2 Configuring Automatic Backup Settings

1. Call the DBA Cockpit.
2. Choose
frame.

Configuration

Automatic Maintenance Settings

in the navigation

The screen Configuration: Automatic Maintenance Settings appears.

3. Choose Automatic Backup.

April 2010

155

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. Specify the following parameters:

Parameter

Description

General
Automatic backup is switched
Enables or disables the automatic backup function
on / off
Specifies the type of backup (online or offline)
Backup Operation Type

When performing an online backup, you are still able to access

the database during the online maintenance window. When
performing an offline backup within the offline maintenance
window, you cannot access the database.
Specifies the priority of the automatic backup over the other
automatic maintenance features such as Automatic
RUNSTATS or Automatic REORG

Priority

Note
1 means highest priority.
End of the note.

Starting Conditions
Backups are created more frequently. Therefore, less time is
required to recover the database. The following limits apply:
Optimize for Database
Recoverability

Maximum time between backups: 1 day

Maximum log space used between backups:

o
10 MB

Indicates the balance between the number of backups and the

time for recovery.
Balance Between
Recoverability and
Performance

The following limits apply:

Maximum time between backups: 7 days

Maximum log space used between backups:

o
25 MB

Fewer backups are created. Therefore, more time to recover

the database is required. The following limits apply:
Optimize for Database
Performance

Maximum time between backups: 30 days

Maximum log space used between backups:

o
50 MB

156

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

When you choose this option, you are able to customize the
following parameters:
Number of full backups is less than

Minimum number of backups

Customize

Time since last full backup exceeds <value>

o
days

Maximum time between backups

o

Log space used since last full backup is more

than <value> MB
Maximum log space between two backups

Number of full backups is

less than

If the number of backups is less than the specified value, a

backup is created.

Time since last full backup

exceeds

If the time since the last backup exceeds the specified

value, a backup is created.

Log space used since last full If the log space exceeds the specified value, a backup is
backup is more than
created.
Backup Media
The backup is created in the specified file systems.
File System

If you choose File System, you also have to specify File Paths
where the backup is to be created.
The backup is created on tape.

Tape Device

TSM

If you choose Tape Device, you also have to specify the

Number of Parallel Sessions.
The backup is created and stored in IBM Tivoli Storage
Manager (TSM).
If you choose TSM, you also have to specify File Paths.
The backup is created using the XBSA API for storing the
data.

XBSA
If you choose XBSA, you also have to specify the Number of
Parallel Sessions.
The backup is created and data is stored using a vendor
library.
Vendor Library

April 2010

If you choose Vendor Library, you also have to specify the

Location (that is, a path and file name of the library) and the
Options.

157

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5.12.3 Configuring Automatic RUNSTATS Settings

1. Call the DBA Cockpit.
2. Choose
frame.

Configuration

Automatic Maintenance Settings

in the navigation

The screen Configuration: Automatic Maintenance Settings appears.

3. Choose Automatic RUNSTATS.
4. You can set the following parameters:
Parameter

Description

General
Automatic RUNSTATS is
switched on / off

Enables or disables the automatic RUNSTATS function

Maintenance Window

Specifies that automatic RUNSTATS can only be performed in the

online maintenance window
Specifies the priority of the automatic RUNSTATS over the other
automatic maintenance features, such as Automatic REORG or
Automatic Backup.

Priority

Note
1 means highest priority.
End of the note.

Parameters
If you select this checkbox, you enable the SAP default criteria,
that is that no tables are excluded from automatic RUNSTATS by
the policy filter.
SAP Default Criteria for
Tables Excluded by Policy

Note
A full editor for these filter criteria is not provided.
End of the note.

158

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

In addition, the following information is displayed for tables that are excluded from RUNSTATS:
Column

Description
The excluded tables are divided into the following categories:
Volatile Tables
Volatile tables are always excluded from automatic
RUNSTATS. When you expand this node, the volatile tables
are displayed.

Tables Excluded from

RUNSTATS

Tables Excluded by Policy

Within the policy, there are some filter criteria for tables to
be excluded from automatic RUNSTATS. When you expand
this node, the excluded tables are displayed.
Schema

Name of the schema to which the table belongs

Indicates whether the table is flagged as VOLATILE in the system
catalog or not

Volatile
If the table is flagged as VOLATILE, statistics are not used by the
optimizer.
Profile

Indicates whether a RUNSTATS profile was set for the table

RUNSTATS Date

Date of the last RUNSTATS in the system catalog table

RUNSTATS Time

Time of the last RUNSTATS in the system catalog table

Cardinality

Number of rows as calculated by the last RUNSTATS (1 indicates

that there are no statistics available)

5.12.4 Configuring Automatic REORG Settings

The automatic REORG checks regularly if tables or indexes require reorganization. This check
is performed by the REORGCHK. The tables are always defragmented during the offline
maintenance window. Only for indexes, you are able to specify if a reorganization is to be
performed during the online or offline maintenance window.
Procedure
1. Call the DBA Cockpit.
2. Choose
frame.

Configuration

Automatic Maintenance Settings

in the navigation

The screen Configuration: Automatic Maintenance Settings appears.

3. Choose Automatic REORG.

April 2010

159

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. You can set the following parameters:

Parameter

Description

General
Automatic REORG is
switched on/off

Enables or disables automatic REORG function

Specifies a maintenance window for index reorganization

Index Reorganization
Mode

Recommendation
We recommend that you reorganize indexes during the online
maintenance window.
End of the recommendation.
Specifies the priority of the automatic REORG over the other
automatic maintenance features, such as Automatic RUNSTATS
or Automatic Backup.

Priority

Note
1 means highest priority.
End of the note.

Parameters
Enables the SAP default filter criteria for tables that are to be
excluded from automatic REORG

SAP Default Criteria for

Tables Excluded by Policy

That is, all table filters in the policy are disabled and the
parameters are changed according to the SAP
recommendations.
Note
An editor for these filter criteria is not provided.
End of the note.

160

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you select this option, a copy of the table or index is created

in the temporary tablespace and the table or index is copied to
the original tablespace.
Use a System Temporary
Tablespace with Compatible
Page Size

Since temporary tablespaces in SAP systems are SMS

tablespaces, the required space for defragmentation will be
available after the reorganization.
Recommendation
We recommend that you use a system temporary tablespace.
End of the recommendation.
Specifies the tables that are excluded from the automatic
REORG because of their size

Maximum Table Size

Recommendation
We recommend a maximum table size filter of 1,000,000 KB.
End of the recommendation.
Specifies if you want to keep or rebuild the compression data
dictionary
A rebuild of the data dictionary could lead to a better
compression ratio but means additional time during
reorganization.

Compression Data Dictionary

Recommendation
We recommend that you rebuild the compression data
dictionary.
End of the recommendation.

April 2010

161

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

In addition, the following information is displayed for tables that are excluded from an
automatic REORG:
Column

Description
The excluded tables are divided into the following categories:
Tables Excluded by Policy
Within the policy, there are some filter criteria for tables
to be excluded from the automatic REORG. When you
expand this node, the excluded tables are displayed.

Tables Excluded from

REORG

Tables Excluded by Size

When you expand this node, the tables with a size larger
than the threshold are displayed.
Determining the table sizes online is much too
expensive. To get the sizes of the tables, you have to
schedule the job REORGCHK for all Tables in the DBA
Planning Calendar.

Schema

Name of database schema to which the table belongs

Table Flagged

Indicates the table to be reorganized

Index Flagged

Indicates the indexes to be reorganized

Table Size (KB)

Size of table in KB

REORG Date

Date when table was last reorganized

REORG Time

Time when table was last reorganized

162

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6 Jobs
The following sections provide information on:
Central Calendar
The DBA Planning Calendar
The DBA Log
Back-End Configuration
The SQL Script Maintenance

6.1 Central Calendar

Use
The Central Calendar is part of the DBA Cockpit in the SAP system. It gives you a single
point from which to manage database administration (DBA) actions in an integrated SAP
environment. The actions available differ according to the database platform but the method
of use is the same. Examples of actions are backups, database system checks, and so on.

The Central Calendar is only for viewing DBA actions by system.

However, you can easily switch to the DBA Planning Calendar for any SAP
system registered in the DBA Cockpit to plan that is, schedule, change,
delete, or execute DBA actions.
The Central Calendar gives you a single point from which to manage:
Databases of different types and versions on remote SAP systems
Databases for different versions of the SAP system
Databases of non-ABAP SAP systems
Integration
The Central Calendar runs with all database platforms delivered as a standard part of the
SAP system and supported by SAP (except DB2 for i5/OS, which has good equivalent tools).
Features
You can manage in real time systems directly administered from the system where the
DBA Cockpit is running as well as remote systems, including non-ABAP systems.
You can quickly check the color-coded status for each system to see if actions have
executed successfully.
You can quickly check the number of actions and number of actions with the highest
status severity for each system, as shown in the following example:

April 2010

163

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The entry for February 2007 in the cell for Thursday February, 08 is:
3 FUD 2
On system FUD for Thursday 8th January 2007 (in the past), there were 3
actions planned, 2 of which had the highest status severity. For example, the
highest status severity might be Warning, in which case the entry is displayed
with a yellow background.
Activities
...

On the system where you normally run the DBA Cockpit, you plan a regular job in the
DBA Planning Calendar to update the results from remote systems using the action
Central Calendar Log Collector. For example, you plan this job to run daily at 06:00.
You define the systems you want to monitor in the DBA Cockpit by setting the flag
Collect Central Planning Calendar Data for each system.
You regularly check the results using the Central Calendar.
If you need to schedule, change, delete, or execute actions, you switch to the DBA
Planning Calendar.
For more information, see Using the Central Calendar.

6.1.1 Using the Central Calendar

Use
You can use the Central Calendar in the DBA Cockpit to view actions on all the databases of
your SAP Systems.
Prerequisites
You have defined the systems to be displayed in the Central Calendar by doubleclicking the required system in the screen DBA Cockpit: System Configuration
Maintenance and selecting Collect Central Planning Calendar Data.
For more information, see Configuring Systems for Remote Monitoring Using Remote
Database Connections.
In an ABAP system, make sure that you schedule the jobs for the remote database in
the central monitoring system. Jobs that have been scheduled in the remote system
are not displayed.
In the DBA Planning Calendar of the DBA Cockpit where you call the Central Calendar,
you have planned the action Central Calendar Log Collector to run regularly. This
collects information from the defined remote systems for display in the Central
Calendar.
For more information, see Setting Up the DBA Planning Calendar.

164

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure
...

1. Start the Central Calendar from the DBA Cockpit by choosing Jobs
Calendar.

Central

The Central Calendar is displayed. If you have already run or planned actions, you see
entries by day, one for each system.
Here is an example of entries for Thursday February, 08 affecting two systems, FUD
and FIB:

FUD

FIB

On system FUD for Thursday 8th January, there were three actions planned, two
of which had the highest status severity. For example, the highest status
severity for FUD might be Finished with warning, in which case the entry for
FUD is displayed with a yellow background. This means that two actions ended
with a warning.
On system FIB for the same day, there were four actions planned, one of which
ended with the highest severity. For example, the highest severity for FIB might
be Finished with error, in which case the entry for FIB is displayed with a red
background. This means that one action ended with an error.
The following table shows the color-coded statuses in the Central Calendar, which you
can also see by choosing Legend:
Color

Status

Light blue

Planned

Dark blue

Running

Green

Finished successfully

Yellow

Finished with warning

Red

Finished with error

Dark yellow

No longer available

Dark red

Scheduling failed

2. To see a summary of the actions for a day, double-click the day header.
The system displays a summary of the actions and status for each system on the day
you selected, as in the following example:

System

Total

No
longer
available

FUD

FIB

Scheduled

Running

Finished

Warning

Error

2
3

3.

April 2010

165

Overdue

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. To see the individual actions for a system, double-click the entry for the system on the
required day.
You see the relevant day in the DBA Planning Calendar. You can perform all usual
functions in the DBA Planning Calendar.
5. To refresh the display for the system from which you called the Central Calendar,
choose Refresh.
6. To refresh the display for all systems, choose Remote Refresh.
You can remotely refresh the display as follows:
Method

How the Refresh Runs

Run in Dialog

Runs in dialog mode, which can take a long time, so

not normally recommended

Start immediately

Runs immediately in the background as a job

Schedule at

Runs in the background at the time that you specify

We recommend that you schedule action Central Calendar Log Collector to run
regularly, as described above in Prerequisites.
7. If required, you can customize the calendar display as follows:
a. Specify a factory calendar in Calendar ID.
Holidays are displayed in the same background color as weekend days. This in
no way restricts the planning of actions in the DBA Planning Calendar.
b. Switch to day, week, or month view by choosing Administration
Administration
View Week, or Administration
View Month.

View Day,

c. Choose Save Settings and change Number of Weeks or Entries per Day in the
display.

6.2 The DBA Planning Calendar

You use the DBA Planning Calendar to automate database administration actions that have
to be performed regularly. You are able to schedule operations such as online backups, have
them automatically performed, and then check that the operation was successful.
The main function of the DBA Planning Calendar is to define the start times and parameters
for database actions. Since these actions run without administrator interaction, you have to
make sure in advance that the necessary resources are available.
Integration
The DBA Planning Calendar is part of the Computing Center Management System (CCMS).
You can start it from the DBA Cockpit.

166

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Features
Initial Screen
The initial screen of the DBA Planning Calendar is divided into three frames that are
described in the following.
Left Frame
The frame on the left contains all information and parameters to select the set of actions to be
displayed. You can:
Select the system from which you want to read planning data.
Select the category of an action:
o

DBA Actions
These are plannable actions.

External Actions
These are plannable actions that have not been started via the DBA planning
calendar but manually or by external job schedulers.

All Actions
These are all plannable actions, regardless how they have been scheduled.

DB Collectors
These are actions that are automatically selected by the system to collect, for
example, data on performance or history and are only available for RFCmonitored systems.

Select the week to be displayed using the calendar control

The default is the current week. To navigate to another week, double-click the week
you want to display.
Select a factory calendar
Specifying a factory calendar only has an impact on the calendar display. Holidays
are the same color as weekend days. It does not result in any restrictions for planned
actions.

April 2010

167

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Action Pad
The frame on the right contains the following list of all plannable actions that are currently
available for DB2 for Linux, UNIX, and Windows:
Task Area
Backup and recovery of the database
Note
The actions involved have an impact
on the availability of the database.
End of the note.

Actions Involved
Full Database Backup into TSM
Full Database Backup to Device
Full Database Backup with Vendor Library
Archive Log File to Tape

Running statistics for tables

Note
These actions are only available if the
automatic RUNSTATS by DB2 is
disabled.

RUNSTATS and REORGCHK (DBSTATC)

RUNSTATS and REORGCHK for All Tables

The actions involved have an impact

on the database performance.
End of the note.
REORG and RUNSTATS of Flagged Tables
REORG of Tables in Tablespace(s)
REORG and RUNSTATS for Single Table
Reorganization of tables and
tablespaces
Note
The actions involved have an impact
on the database performance.
End of the note.

Automatic REORG
This action depends on data provided by
action REORGCHK for all Tables. If the latter
is not scheduled, the action will not work
properly. For more information, see
Reorganizing Tables [page 179].
Note
This action is available only if the automatic
REORG by DB2 is disabled.
End of the note.
REORGCHK for All Tables

Most actions that you can schedule using the DBA Planning Calendar should normally be
scheduled as a recurring action. You can set up your DBA Planning Calendar using the
pattern setup function as described in Setting Up the DBA Planning Calendar [page 170].

168

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Calendar Frame
The calendar can be displayed with either a weekly, daily, or monthly view using either a topbottom layout or left-right split view layout. To change the layout, choose Administration
Left-Right Split View or Top-Bottom Split View Layout. To change, for example, from a
weekly view to a daily or monthly view, choose the corresponding button in the application
toolbar.
Note
You can only change the layout for the week or month view. For the day view, only the leftright split view layout is available.
To change your preferred settings that is, the layout and the view choose Save Settings.
The calendar shows the actions that were scheduled using background processing. These
actions are then automatically executed.
End of the note.
Once the action has run, the status is indicated using the following colors:
Color

Meaning

Light blue

The action has not yet started.

Dark blue

The action has not yet finished.

Green

The action has run successfully.

The action has finished with a warning.

Yellow
Check the job log for details.
An error has occurred and the action was interrupted.
Red
Check the job log for details and reschedule the action.
Dark yellow

No more information is available.

Dark red

Scheduling failed, that is, there is no status available and the action
is overdue.

You can display the meaning of each color by choosing Legend.

Drag & Drop of Actions
You can move or copy actions within the calendar by using the copy function drag and drop.
More Information
Setting up the DBA Planning Calendar [page 170]

April 2010

169

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6.2.1 Setting Up the DBA Planning Calendar

You need to set up the DBA Planning Calendar because when you start your system for the
first time there are no actions planned.
The most important thing when setting up the DBA Planning Calendar is to choose a pattern
of actions covering your regular database administration (DBA) needs, specifying any
required action parameters and taking account of any dependencies between actions. You
must also consider that there are a number of database-related jobs that are not controlled by
the DBA Planning Calendar but which you must take into account when scheduling regular
actions.
The jobs involve:
Collection of database performance history data done every two hours starting at
00:00
Monitoring of database and database manager configuration changes done daily on
8.00 am, 01.00 pm and 7.00 pm
Collection of database and tablespace history data done daily at 7:00 am and 8.00
pm
Collection of tables and indexes space history data done weekly on Sunday at 12.00
pm
Caution
Some of the actions available have an impact on database performance and
availability. Check the start and end times of scheduled actions to make sure that
they do not impact each other and that they do not impact other activities in your
system.
You cannot perform all required DBA actions from the DBA Planning Calendar or the
DBA Cockpit. For more information on actions that you must perform with the SAP
system down, such as offline database backup, see the SAP Database
Administration Guide for your database
End of the caution.
Optionally, you can configure the back end of the DBA Planning Calendar to be able to
control the execution of background jobs. For more information, see Back-End Configuration
[page 187].
Prerequisites
Check the following before you start using the DBA Planning Calendar:
SAP system authorizations
Check that you have authorization for DBA and background job scheduling, which is
provided by profiles S_RZL_ADMIN and S_BTCH_ALL.
Check that external programs are able to run on the database server so that actions
affecting the database can be performed from other application servers.

170

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Database system authorizations

Check that actions requiring authorization to connect to the database are permitted.
Some actions, such as online backup, require higher levels of authorization.
Before scheduling database backups, see the information on how to back up the
database in the SAP Database Administration Guide for your database.
Hardware and backup media
Check that you have enough hardware (such as tape drives) and backup media
(such as tapes) for the backup strategy you intend to use.
You make sure that the media are initialized and ready so that the operator does not
have to interrupt scheduled backup runs. For example, check that tapes are already
in the specified tape drive or tape changer. You might require different tape drives for
database backups and log backups.
Procedure
1. Start the DBA Planning Calendar from the DBA Cockpit by choosing
Planning Calendar

Jobs

DBA

2. Choose Pattern Setup.

The Add Planning Patterns dialog box appears providing a list of actions that you can
schedule with this function.
Note
A set of recommended actions is already preselected by default. You may change
this selection set, for example, if you want to use TSM for backup and archiving
instead of backup and archive to devices.
End of the note.
3. Follow the wizard to set up a pattern of recurring actions to cover your regular DBA
needs.
You can navigate between the actions in the pattern by choosing Next and Previous.
4. When you have finished defining the pattern, choose Save on the last screen to enter
the pattern into the DBA Planning Calendar.
Caution
When you start using the DBA Calendar in production operation, you must check daily that
scheduled actions have been executed correctly.
End of the caution.
More Information
Scheduling an Action [page 172]
Changing an Action [page 173]
Deleting an Action [page 174]

April 2010

171

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Executing an Action [page 175]

Displaying the Status of a Days Actions [page 175]
Displaying Scheduled Actions [page 175]
Troubleshooting [page 176]
Updating Statistics [page 177]
Scheduling a REORGCHK for All Tables [page 178]
Reorganizing Tables [page 179]
Database Backup [page 181]
Archiving Log Files To Tape [page 184]
Scheduling Scripts [page 185]

6.2.1.1 Scheduling an Action

1. To add new actions to the DBA Planning Calendar, you can use one of the following
options:
o

Double-click a calendar cell.

Position the cursor on a calendar cell and choose Add.

Drag and drop an action from the action pad into a calendar cell.

Note
You can also use drag and drop to move actions within the calendar. If you want to
copy an action, keep the CTRL key pressed while using drag & drop.
End of the note.
A dialog box appears with the details of an action.
2. If you chose the first or second option in the first step, you can select the action you
want to schedule from the group box Action Description. In the Planned Start field,
you can enter date and time when the action is to start. If you are entering an action
for today and want to start the action immediately, choose Execute.
If you chose the final option in the first step, the corresponding action is already listed
as default.
The parameters for the required action are displayed under Action Parameters. They
vary depending on the action.
3. On the Action Parameters tab page, change or enter the basic parameters for the
action.

172

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. On the Recurrence tab page, enter a recurrence pattern.

Parameter

Description
Interval for the action in weeks, days or hours

Recurrence
Pattern

Depending on the selected recurrence pattern, you need to specify the pattern
in more detail, that is the days of the week for weeks and the hours of the day
for a daily period. The action is repeated at the interval you enter. If you select
Once only, the action is executed only once.

Recurrence
Range

Range of time where the action recurs, that is for a specific time interval or for
a limited number of occurrences

Caution
The system warns you if there is a conflict with an existing action, but it does not
prevent you from inserting the new action.
You must decide whether the actions might conflict in terms of database access
or performance. The system does not check for conflicts between actions with
identical start times, but checks for actions within a range of approximately 30
minutes.
5. To schedule the action, choose Add.
Result
The schedule of the DBA Planning Calendar is updated.

6.2.1.2 Changing an Action

This section tells you how to change an action in the DBA Planning Calendar.
If you want to change a recurring action, the changes only affect recurrences of the action in
the future. The action is split into two actions, one describing the old action, and one the new
action.
Prerequisites
If you want to change an action, it must be in the state Planned (that is, not already
executed).
Note
If an action has already been executed, you can only display it. For more information, see
Displaying Scheduled Actions [page 175].
End of the note.

April 2010

173

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure
1. Call the DBA Cockpit
2. Choose
Cockpit.

Jobs

DBA Planning Calendar

in the navigation frame of the DBA

3. Position the cursor on a calendar cell and choose Edit.

A dialog box with the action parameters and recurrence pattern appears.
4. Apply your changes and activate them by choosing either Change Current
Occurrence or Change All Occurrences.
More Information
Scheduling an Action [page 172]

6.2.1.3 Deleting an Action

Prerequisites
If you want to delete an action from the DBA Planning Calendar, it must be in the state
Planned (that is, not already executed).
Note
If an action has already been executed, you can only display it. For more information, see
Displaying Scheduled Actions [page 175].
End of the note.
Procedure
1. Call the DBA Cockpit.
2. Choose

Jobs

DBA Planning Calendar

in the navigation frame.

3. Double-click a calendar cell or position the cursor on a calendar cell and choose
Delete.
A dialog box appears with a list of all actions to be deleted, where you can decide if
you want to delete only a single occurrence of a recurring action or all occurrences.
4. To delete an action, choose Delete.

174

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6.2.1.4 Executing an Action

You might have to reschedule an action, for example, after an action has failed or if there is a
resource bottleneck that needs immediate reaction.
Procedure
...

1. Double-click the action you want to re-execute.

The Display Details of Action dialog box appears where you can check the action
parameters.
2. Choose Execute.

If you are sure that the action parameters are correct, you only need to position
the cursor on the action and choose Execute.
Result
The action is rescheduled starting at the current time.

6.2.1.5 Displaying the Status of a Days Actions

1. Double-click the header cell for a particular day.
The display switches to the day view. All scheduled actions are displayed.
Note
Unsuccessful or interrupted actions are shown in red.
End of the note.
2. If you want to view other days, select a new day by double-clicking a day on the
calendar control at the left side of the screen.
3. To return to the week view, choose Week.

6.2.1.6 Displaying Scheduled Actions

From the DBA Planning Calendar, you can view all action-related information. This includes:
Action parameters
Job logs if the action has already run
These logs provide detailed information on the results of an action.
Recurrence patterns
The status of an action is indicated by the color of the calendar cell where an action is
inserted.

April 2010

175

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure
Select the action by double-clicking a calendar cell or by positioning the cursor on a cell and
choosing Action Details.
The Display Details of Action dialog box appears. In the Action Description group box,
scheduling information and the return status of the finished action is displayed.
Action Parameters
The system displays tablespaces containing tables and indexes that need to be reorganized.
Recurrence
This tab page only appears if the action is part of a recurring action.
Caution
The timestamp is used to assign logs to scheduled actions. An action log is assigned to the
action that has the same type and the closest corresponding timestamp. In some cases, for
example, if no background work process is available, the action is delayed and even
postponed until after the next scheduling time. Unfortunately, this means that the action log is
then assigned to the next scheduling time and the original scheduling time log is incorrect.
This is the case if the logs for the previous schedules are displayed for the next schedule of
the same type.
End of the caution.
Job Log
The background processing job log generated by the action is displayed under Job Log. All
messages that have been written by the background job are also displayed.
To display long texts, if any are available, double-click a message.
Program Log
Some actions write log files onto the database server. If such a program log exists, it is
displayed on this tab page.

6.2.1.7 Troubleshooting
Since any action scheduled in the DBA Planning Calendar can fail, you must at least check
the more critical actions such as database backups.
Procedure
1. To check whether the background job was executed correctly, consult the job log. If
no job log exists, the background job was probably not started.
For more details, call transaction SM37 and display the job overview.

176

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
The names of all jobs scheduled in the DBA Planning Calendar start with DBA. The
job log also tells you whether an external program was started.
End of the note.
2. If you are sure that the background job ran successfully, consult the job log or
program log (if available).
3. After you have corrected the error, execute the action manually using Execute,
making sure there are no conflicts with other scheduled actions.
Note
If you want to completely clean up your jobs, choose the Cleanup pushbutton. This deletes all
jobs, all scheduling data, and all related protocol records. It also resets the DBA Planning
Calendar to its initial state.
We recommend that you clean up after an SAP system upgrade or if jobs have become
corrupt.
End of the note.

6.2.1.8 Updating Statistics

You can use the DBA Planning Calendar to schedule an update of the database statistics. In
general, DB2 updates the database statistics automatically using its automatic RUNSTATS
function.
If the automatically maintained statistics need to be up-to-date or if a different type of
statistics other than DB2s default is required, you can schedule the job RUNSTATS and
REORGCHEK for Single Table using the DBA Planning Calendar. This job performs a
RUNSTATS for a single table or a set of tables that is specified by a name using wildcards.
Recommendation
Since the RUNSTATS can affect system performance in case of large tables, we recommend
that you schedule the job RUNSTATS and REORGCHEK for Single Table to run outside
normal working hours, for example, on Sundays.
End of the recommendation.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose RUNSTATS and
REORGCHEK for Single Table and drag and drop it in the calendar frame.
The Schedule a New Action dialog box appears.
2. Specify the required parameters.
The parameters that you have to specify are the same as for RUNSTATS Control as
in described in Space: Single Table Analysis [page 106] except Number of Parallel
Jobs.

April 2010

177

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

By setting the value for Number of Parallel Jobs higher than one, the RUNSTATS job
can be parallelized if there are enough system resources available (for example,
background processes and the appropriate number of processors). Doing so results
in additional jobs that are scheduled by the regular DB13 job and which perform the
RUNSTATS on tables in parallel. The SAP system makes sure that the number of
parallel jobs does not exceed the number of available background processes.
Caution
However, you have to handle the parameter Number of Parallel Jobs with care
because starting more jobs can have a high impact on the overall system
performance even though it significantly reduces the amount of time for the job
execution.

6.2.1.9 Scheduling a REORGCHK for All Tables

You can use the DBA Planning Calendar to schedule an overall check of all tables using the
job REORGCHK for All Tables.
Note
REORGCHK for All Tables is a prerequisite for the analysis of table and index details.
Without scheduling this job, the analysis of tables and indexes in the Space task area will not
work correctly. The REORGCHK for All Tables job also provides size information that is used
to track the growth of tables and indexes. For more information, see Space: History -Tables
and Indexes [page 125].
End of the note.
Recommendation
The job REORGCHK for All Tables must run once a week.
End of the recommendation.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose REORGCHK for all Tables
and drag and drop it in the calendar frame.
The Schedule a New Action dialog box appears.
2. Specify the required parameters:
Parameter

Description
Specifies that the job is called for all tables

All Tables
By default, this parameter is selected.

178

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Specifies that this job is restricted to a set of tables

If you choose this option, you also have to specify the Table
Schema and Table Name.
Selected Tables

Note
Only choose this option if you require an up-to-date analysis for
the selected tables.
End of the note.
Analyzes the tables and checks for candidates to be compressed

With Compression Check

By default, you should not activate this option for the REORGCHK
job that is scheduled weekly. For performance reasons, only
perform compression checks in larger time-frames.
Defines the minimum size limit for checking how much space can
be saved by compressing the table.
Recommendation

Minimum Table Size for

Check

We recommend that you set this limit to prevent too small tables
that do not benefit from row compression from being checked.
End of the recommendation.
Note
You can only specify this value if you have chosen With
Compression Check.
End of the note.

Maximum Runtime

Restricts the runtime of this job

6.2.1.10 Reorganizing Tables

You can use the DBA Planning Calendar to schedule a reorganization of a set of tables. In
general, DB2 reorganizes the tables using its automatic REORG function. If a reorganization is
required that is not covered by automatic REORG, for example, table compression, you can
schedule the job REORG and RUNSTATS for Set of Tables using the DBA Planning
Calendar.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose REORG and RUNSTATS
for Set of Tables and drag and drop it in the calendar frame.
The Schedule a New Action dialog box appears.

April 2010

179

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2. Specify the following parameters:

Parameter

Description

Table Schema

Name of the schema to which the table belongs

Table

Name of the table

Schedules an offline reorganization.
Optionally, you can also specify the following parameters:
o

Use Temporary Tablespace

If you select this option, a temporary tablespace is
used for the reorganization.
Note
If no temporary tablespace is used for the REORG, it is
performed in the tablespace where the table or index
resides. You must make sure that there is enough free
space in this tablespace (approximately the size of the
table or index). If this tablespace already has a high
I/O load, we recommend that you use a temporary
tablespace for performance reasons.

Offline

End of the note.

o

With Long Fields and LOB Data

If you select this option, long field and LOB data areas
are also reorganized.

Keep Dictionary
If you select this option, a compression dictionary is
kept and not rebuilt.
Note
This option is valid only for compressed tables.
End of the note.

180

Online

Schedules an online reorganization of the table

All Indexes

Schedules a reorganization of all indexes only

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6.2.1.11 Database Backups

A database backup is a complete copy of your database. To be able to restore the database
to a consistent state that is as up-to-date as possible, you have to perform database backups
on a regular basis.
Integration
You can perform database backups using the DBA Planning Calendar by calling the DBA
Cockpit and choosing Jobs DBA Planning Calendar in the navigation frame of the DBA
Cockpit.
Depending on the storage device that you are using, you can choose one of the following
jobs from the action pad:
Full Database Backup into TSM
You back up the database to Tivoli Storage Manager (TSM).
Full Database Backup to Device
You back up the database to a specified tape or disk.
Full Database Backup with Vendor Library
You back up the database to any other vendor storage management product.
Snapshot Backup
You back up the database using the fast copying technology of a storage device.
Activities
When scheduling one of the jobs mentioned above, the Schedule a New Action dialog box
appears. On the Action Parameter tab page, you can specify the following:
Parameter

Description

Backup Mode
Online

Access to the database is not blocked. The users can continue to

work normally during the backup.
Note

Offline

This option is no longer supported and is displayed only for upward

compatibility reasons.
Backup jobs that have this option are automatically performed as
online backups with the Include Logs option.
End of the note.

April 2010

181

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Backup Type
Full

The complete database is backed up.

A cumulative (that is, incremental) backup image

Incremental

An incremental backup image is a copy of all database data that has

changed since the most recent successful full backup operation.
A non-cumulative (that is, delta) backup image

Incremental Delta

A delta backup image is a copy of all database data that has

changed since the most recent successful backup operation.

Additional Options
Compress

The backup is to be compressed.

Note
Only choose this option if you want to perform an online backup.

Include Logs

End of the note.

Only those log files are included in the backup that are required to
get a consistent database. Any further log files are not taken into
consideration.

Caution
The following options are available for downward-compatibility reasons and we strongly
recommend that you do not set them:
Number of Buffers
Buffer Size
Parallelism
End of the caution.
Backup Considerations
When performing a backup, you should consider the following:
Regardless of the selected backup mode, you can only restore the database if you
have at least one valid full backup.
To restore the database completely and to bring the system up-to-date, you have to
roll in the log files that were generated after the backup was performed.

182

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The database may be local or remote. The backup, however, remains on the
database server unless a storage management product, for example, Tivoli Storage
Manager (TSM), is used.
After an online backup, DB2 forces the currently active log files to be closed and as a
result they are archived. Thus, an online backup has a complete set of archived log
files that are available for database recovery.
Backup of a Multi-Partition Database
You have to back up partition by partition. Therefore, you have to schedule backup jobs for
each partition.
In a multi partition database system, keep a copy of file db2nodes.cfg with any backup
copy that you take. This copy of file db2nodes.cfg is used as a safety copy in case of
possible damage to the original file.
Note
As of DB2 Version 9.5 for Linux, UNIX, and Windows and higher, a single system view
backup is available that performs the backup for all database partitions in one job. You can
use this option by choosing the value All for the database partition on the Schedule a New
Action dialog box.
End of the note.
Frequency of Backups and Time Required
You should take full database backups on a regular basis, regardless of how often log files
are archived. A current full backup means that there are fewer archived log files that you have
to apply in case of a database recovery. Thus, the amount of time that is required by the
ROLLFORWARD utility to recover the database decreases. In addition, the chance of a log file
not being available (for example, due to data corruption or data loss) also decreases.
To reduce the amount of time that the database is not available, we recommend that you
consider performing online backups.
Note
You can only use an online backup for recovery if the database log files that were created
during the online backup are available.
End of the note.
Advanced Backup Techniques
The following list provides information on advanced backup techniques:
Incremental or delta backups
To reduce the backup and restore time, you can use incremental or delta backups.
For more information, see the IBM manual Data Recovery and High Availability Guide
and Reference.

April 2010

183

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Backup of a file system copy using the db2inidb tool

For more information about the db2inidb tool and its use as a mirror for a backup
based on a file system, see the Database Administration Guide: SAP on IBM DB2 for
Linux, UNIX, and Windows.
Standby database for backup purposes
For more information about how to use the db2inidb tool to create a standby
database for backup purposes, see the Database Administration Guide: SAP on IBM
DB2 for Linux, UNIX, and Windows.
More Information
Database Administration Guide: SAP on IBM DB2 for Linux, UNIX, and Windows at:
http://service.sap.com/instguidesnw
Database-Specific Guides

<Your SAP NetWeaver Release>

Operations

6.2.1.12 Archiving Log Files To Tape

You can archive log files to tape using the job Archive Log Files to Tape in the DBA Planning
Calendar.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose Archive Log Files to Tape
and drag and drop it in the calendar frame.
The Schedule a New Action dialog box appears.
2. Specify the required parameters.
Note
The DB2 tape manager is used to archive log files to tape. Besides the standard
parameters (for example, start time, date, number of log files to be saved and tape
label), you can also specify the option of the tape manager to use for archiving log
files:
o

Double Store

Overwrite Expired Tapes

Eject Tape at End of Operation

For more information about these options and how to use them, see the Database
Administration Guide SAP on IBM DB2 for Linux, UNIX, and Windows at:
http://service.sap.com/instguidesnw
Operations Database-Specific Guides

<Your SAP NetWeaver Release>

.

End of the note.

184

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6.2.1.13 Scheduling Scripts

You can use scripts to schedule time-consuming and non standard database administration
tasks using the job CLP Script.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose CLP Script and drag and
drop it in the calendar frame.
The Schedule a New Action dialog box appears.
2. Specify SQL statements directly as job parameters.
Note
Alternatively, you can use scripts that have been created before. For more
information, see SQL Script Maintenance.
End of the note.

6.2.1.14 Running the NLS Cleanup Job

Note
The following section only applies if you are using a near-line storage (NLS) database for
your local BW system.
End of the note.
When data is reloaded from the NLS database into the BW system, it continues to exist in the
NLS database. It is marked, however, as invalidated. To remove this invalidated data and to
reduce the space consumption in the NLS database, you can use the NLS Cleanup job in the
DBA Planning Calendar.
Procedure
1. In the Action Pad of the DBA Planning Calendar, choose NLS Cleanup and drag and
drop it in the calendar frame.
The Schedule a New Action dialog box appears.
2. In the NLS Connection field, choose an existing NLS connection.
3. In the InfoProvider field, choose the name of the InfoProvider.
Caution
If you do not specify an InfoProvider, the cleanup is performed for all InfoProviders.
To run the job for many InfoProviders with similar names, you can use the wildcard
character *.
End of the caution.

April 2010

185

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

More Information
For more information about reloading data from the NLS database into the BW system, see
the separate document Enabling an SAP NetWeaver BW to Use IBM DB2 for Linux, UNIX,
and Windows as Near-Line Storage at:
http://service.sap.com/instguidesnw <Your SAP NetWeaver Release>
Installation - SAP NetWeaver Systems

Installation

6.3 The DBA Log

The DBA log provides information on protocol records written by all database-related
programs of the CCMS and SAP-DB2 admin tools.
You can access the DBA log by calling the DBA Cockpit and choosing
in the navigation frame of the DBA Cockpit.

Jobs

DBA Log

The following information is displayed on the Jobs: DBA Action Log screen:
Column

Description

Start Date

Start date of action

Start Time

Start time of action

End Date

End date of action

End Time

End time of action

Runtime

Runtime in HH:MM:SS

Action

Description of action

Return Code

Return code of action

When you access the DBA log for the first time, the system displays the log information for
the current week.
If you want to display information on previous weeks, double-click a day in the corresponding
week in the calendar control.

186

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you only want to display certain log records, choose one of the following icons:
Icon

Meaning

Total

Total number of all log records

Errors

Displays jobs that finished with an error. These jobs should be executed again

Warnings Displays jobs that finished with a warning

OK

Displays log records of jobs that were completed without errors

6.4 Back-End Configuration

You can configure the back end of the DBA Planning Calendar to control the execution of
background jobs. You can configure the back end for all systems, for selected database
platforms, or for single systems only.
The system is configured by using the first available configuration from the following:
1. The system-specific configuration
2. The configuration for the database platform
3. The configuration valid for all platforms
4. The standard configuration current user, selection of background server by
background dispatcher, high priority
Configuration Steps
1. Call the DBA Cockpit and choose

Jobs

Back End Configuration

Note
Alternatively, choose
Planning Calendar.

Goto

Back End Configuration

from the menu in the DBA

End of the note.

2. In the Selected Scope group box, choose the scope of the configuration entry.

April 2010

187

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3. In Background Dispatching group box, choose appropriate values as follows:

Field

Meaning
Specifies the server, where scheduled jobs are executed

Background
Server

If no server is specified, the background job dispatcher dynamically

selects the server.
Specifies the priority of the job

Job Priority
If no priority is specified, jobs run with default priority (medium).
Name of the user to execute the job
User
If no user is specified, the dialog user is used.
4. Save your changes.

6.5 The SQL Script Maintenance

You use the function SQL Script Maintenance to manage your own DB2 scripts.
Integration
The SQL Script Maintenance is part of the Computing Center Management System (CCMS).
You can access it using the DBA Cockpit.
Activities
To access the SQL Script Maintenance, call the DBA Cockpit and choose Jobs SQL
Script Maintenance . The Jobs: SQL Script Maintenance screen appears and all the scripts
located on your local monitoring system are displayed.
You can perform one of the following actions:
Display an existing SQL script
Edit an existing SQL script
Delete an existing SQL script
Add a new SQL script
Execute an existing SQL script

188

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Displaying an SQL Script

To display an existing SQL script in detail, choose one entry from the list and choose Display.
The Jobs: SQL Script Editor Display Script screen appears.
Besides reading the script, you can also perform the following actions:
Switch to the editing mode by choosing Display <-> Change and save the script
under a new name by choosing Save as...
Execute the script.
Access the detail data of another script by entering its name in the Script Name field.
Editing an SQL Script
To edit an existing SQL script, choose one entry from the list of scripts and choose Edit. The
Jobs: SQL Script Editor Edit Script screen appears.
Besides modifying the script according to your requirements and saving it under a new name,
you can also perform the following actions:
Switch to the displaying mode by choosing Display <-> Change.
Execute the script.
Access the detail data of another script by entering its name in the Script Name field.
Deleting an SQL Script
To delete a SQL script, choose one entry from the list of scripts and choose Delete.
Adding a New SQL Script
1. To add a new script, choose Add.
The Jobs: SQL Script Editor Add Script screen appears.
2. Enter a name in the Script Name field and start editing.
3. Choose Save.
Executing an SQL Script
1. To execute an existing SQL script, choose one entry from the list of scripts and
choose Execute.
The Execute SQL Script dialog box appears.
2. In the Execute SQL Script on System field, enter the name of the SAP system where
you want the script to be executed.
3. To confirm your entry, choose Execute again.
The Jobs: SQL Script Editor Display Script screen appears showing an editor in the
lower half of the screen where the result is displayed.

April 2010

189

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note
From each of the above mentioned screens, you can return to the Jobs: SQL Script
Maintenance screen by choosing Back.
End of the note.
Note
As an alternative to the SQL Script Maintenance function, you can also use the DBA
Planning Calendar to execute a script by using the action SQL Script.
End of the note.

190

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

7 Alerts
The following sections provide information about alerts:
Alerts: Database System Monitoring in CCMS
Alerts: Configuring Database System Monitoring
Alerts: Alert Monitor
Alerts: Alert Message Log
Alerts: Alert Configuration

7.1 Alerts: Database System Monitoring in

CCMS
The alert monitor analyzes and maintains configuration and snapshot data of DB2 for Linux,
UNIX, and Windows. It checks the contents of the admin database mirrored in the SAP
system. If these checks find critical situations, for example, if given thresholds are exceeded,
alerts are raised. This enables early recognition of critical situations by the database
administrator.
Integration
The monitoring functions are fully integrated into the new alert monitor and monitoring
architecture.
Features
The following categories of information are currently monitored:
Disk space of the tablespaces and file systems required for the database system
Parameters relevant to performance
o

Access behavior of database buffers

Lock behavior of the application, monitoring of deadlock situations and lock

escalations

Availability of backup and recovery mechanisms

April 2010

Last available backup

Availability of the log files necessary to achieve the current state of the
database from the last available backup.

191

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Configuration parameters
Availability data of tablespaces and containers
Recommendation
We recommend that you check the information displayed on database system
monitoring daily in the alert monitor.
End of the recommendation.
More Information
Alerts: Configuring Database System Monitoring [page 192]
Alerts: Alert Message Log [page 194]
Alerts: Alert Configuration [page 196]

7.2 Alerts: Configuring Database System

Monitoring
DB2 database system monitoring has preconfigured check categories and parameters.
Caution
Only experienced users should make changes to the system check configuration.
End of the caution.
There are two complementary tools available for configuring database system monitoring:
Configuration using general alert monitoring consisting of:
o

Automatic e-mail notification

The central, automated notification function informs you of an alert by e-mail.
If you want to be notified as soon as an alert is raised, you have to define
yourself as a recipient of mails generated by this function.

Background monitoring

Configuration of DB2-specific parameters

Procedure
Enabling Automatic E-Mail Notification
1. Call transaction RZ21.
The Monitoring: Settings and Tool Maintenance screen appears.
2. Choose Tool Definition and then Display Overview.
3. Scroll through the list until you find CCMS_OnAlert_Email.

192

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. Select this entry and choose

application toolbar).

List

Selected Entries

Edit

(or Edit in the

The Monitoring: Tool Administration screen appears.

5. Choose Parameter.
6. Choose Tool Definitions
tool bar).

Display Change

(or Display Change in the application

7. In the SENDER line in the Parameter value column, enter a valid user for your SAP
system.
8. In the RECIPIENT line in the Parameter value column, enter a valid user for your
SAP system who will be notified in the event of an alert.
9. Save your changes.
Activating Background Monitoring
1. Call transaction RZ21.
2. Choose Technical Infrastructure
Dispatching .

Method Execution

Activate Background

Caution
If you do not enable your system for background monitoring, the system will not be
monitored at all.
End of the caution.
Configuring DB2-Specific Parameters
You can specify additional parameters, for example, assignment of logged values for given
alerts.
For more information about specifying these additional parameters, see Alerts: Alert
Configuration [page 196].

7.3 Alerts: Alert Monitor

You can choose one of the following options to retrieve information about alerts:
To get a short overview of alert situations, choose
navigation frame of the DBA Cockpit.

Alerts

Alert Monitor

in the

Note
You are able to directly display the message log for a certain alert by double-clicking
the corresponding item.
End of the note.

April 2010

193

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

To start a detailed analysis, call transaction RZ20 and choose SAP CCMS Monitor
Templates Database DB2 Universal Database for NT/UNIX in the tree structure
CCMS monitor sets.
Note
If you want to use transaction RZ20 for remote database systems, choose SAP
CCMS Monitor Templates Remote Database DB2 for Linux, UNIX, and Windows
.
End of the note.
Data Displayed in the Alert Monitor Tree
Regardless of the view variant you choose, information about the following is displayed:
Space management
Performance
Backup/restore
SAP consistency
Health
The checked parameters are displayed in the following colors depending on the type of
message:
Message Type

Color

Information

Green

Warning

Yellow

Error

Red

Note
If a check resulted in a warning or an error, a short text is additionally displayed next to the
parameter.
End of the note.

7.4 Alerts: Alert Message Log

You can access an overview of the results of system monitoring by calling the DBA Cockpit
and choosing Alerts Alert Message Log in the navigation frame of the DBA cockpit.
The Alerts: Alert Message Log screen appears.
Only the most important data is displayed in the overview. The results are displayed as notes,
warnings, or errors and are ordered by log date as default.
You can use the list boxes in the Current Selection group box to limit the display to specific
error levels, check categories, or partitions (only for multi partition database systems). The

194

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Objects and Attributes fields enable restrictions to single attributes. Additionally, you can
specify a time period for which the messages are displayed. The messages of the last seven
days are displayed as default.
You can display more detailed information by selecting a line and choosing Details. The
Alerts: Alert Message Details screen appears. If you have selected more than one line, you
can use the page buttons on the screen to navigate between them.
The detail screen is divided into the following group boxes:
Alert Message Details
Complete description of the attribute as displayed in the alert monitor tree
Logged Data
Information on the message, for example, type of error, reported value, and date and
time when it occurred
Description
Description of the type of error and which value or parameter is being monitored
Deleting Alert Messages
You can delete messages from any given time period by selecting a line and choosing
Delete. If you choose Delete without selecting a line, a dialog box appears. In the Date field,
you can specify the date from which you want all messages to be deleted. You can also enter
the category or partition as selection criteria.
It is also possible to delete a selected alert message in the detail screen.
Caution
To ensure that the log table does not get too large, automatic clean-up programs run and
delete entries older than 30 days.
End of the caution.
Displaying Data in the Alert Monitor Tree
1. Call transaction RZ20.
The Alert Monitor Set screen appears.
2. Expand SAP CCMS Monitor Templates and double-click Database.
3. Expand DB2 Universal Database for NT/UNIX.
4. You can display information on:

April 2010

Space management

Performance

Backup/restore

SAP consistency

Health

195

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The checked parameters are displayed in the following colors depending on the type
of message:
Message Type

Color

Information

Green

Warning

Yellow

Error

Red

If a check resulted in a warning or error, a short text is additionally displayed next to

the parameter in the Open alerts view.

7.5 Alerts: Alert Configuration

DB2 database system monitoring has preconfigured check categories and parameters.
Caution
Only experienced users should make changes to the system check configuration.
End of the caution.
The initial screen of the database-specific configuration provides you with an overview of all
the configuration entries.
You can access alert configuration by calling the DBA Cockpit and choosing Alerts Alert
Configuration in the navigation frame of the DBA Cockpit. The Alert Configuration Overview
screen appears.
On this screen, you can display details, sort entries, and make selections using the list boxes.
In addition, you can activate or deactivate an entry by selecting the corresponding cell in the
Active column.
Caution
If you deactivate an entry, there is no further notification of corresponding alerts.
End of the caution.
If you want to configure additional parameters, you can double-click a cell in the table or
select a line and choose Details. The Alerts: Display Configuration screen appears providing
the following information:
Threshold
This tab page is divided into three group boxes showing the respective status:
o

Normal State

Warning
Limited operation, for example, with reduced performance

196

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Error
Normal operation is endangered if the error is not corrected.

In each of these group boxes you can configure three values according to which the
system is monitored:
o

Relational operators
You can specify how the defined comparison value should be compared with
the current given value. In addition to the relational operators, you may enter
whether a value should lie inside of or outside of a range of values. A full
colon ( : ) must separate the two values. You may also specify whether or not
discrete values are within a set of explicit values. Semicolons ( ; ) must
separate such values.

Comparison value
You can specify a value, a list of values or a value range depending on the
operator. This value will later be compared with the current measured value.

Unit of measurement of the comparison value

You can specify the unit of measurement of the comparison value. This is
important for time values, which are normally calculated internally in seconds,
to be correctly converted before comparison.
Additionally, you can specify whether or not you want to receive an automatic
e-mail notification in the event of an alert.
Note
Values do not need to be entered for every operation status. However, you
must make sure that the sum of comparison values must cover every
possible value. If this is not the case, a special alert is triggered with the
following message:
There is no configuration entry for the logged value
End of the note.

General (RZ21)
This tab page displays the scheduling data from the basic alert monitor configuration.
The values are displayed here for completeness. It is not possible to make changes
in this transaction. You can make changes using the general maintenance function
(transaction RZ21) in the alert monitor.
Administration
This tab page displays the user that made the last changes and tells you whether this
entry is currently active.
After you have made your changes, save them. Changes take effect immediately.

April 2010

197

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8 Diagnostics
The following sections provide information on diagnostics:
Diagnostics: Displaying the Audit Log [page 198]
The EXPLAIN Function [page 199]
Diagnostics: Missing Tables and Indexes [page 206]
Diagnostics: Deadlock Monitor [page 207]
Diagnostics: SQL Commands [page 213]
The Index Advisor [page 213]
Diagnostics: Cumulative SQL Trace [page 222]
Diagnostics: DBSL Trace Directory [page 223]
Diagnostics: Trace Status [page 223]
Diagnostics: Database Notification Log [page 224]
Diagnostics: Database Diag Log [page 225]
Diagnostics: DB2 Logs [page 227]
Diagnostics: Dump Directory [page 228]
Diagnostics: DB2 Help Center [page 228]

8.1 Diagnostics: Displaying the Audit Log

You can track changes to the database made from the DBA Cockpit and to the monitoring
setup using the maintenance actions provided in the DBA Cockpit. Changes made from
outside for example, using native database commands are not displayed here.
Procedure
1. Call the DBA Cockpit.
2. In the navigation frame, choose

Diagnostics

Audit Log

The Diagnostics: Audit Log screen appears. The audit log consists of the following
fields:
Field

198

Description

Date

Start date of the action

Time

Start time of the action

System

Target system on which the action was performed

Action

Type of action (name of the action in the DBA Cockpit)

Command

Type of command (for example, ADD, DELETE, or EDIT)

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

Object

Name of the modified object (for example, database or

tablespace name)

User

Name of the SAP user who performed the action

From System

System from where the action was performed

3. By default, the system displays all audit entries logged during the current week. If you
want to display another week, double-click a day in the calendar.
To display more than one week, you can change the value in the field Number of
Days.
4. To display the details of an action, select the corresponding action and choose
Details.
In the lower half of the screen, the SQL statements that have been executed are
displayed.

8.2 The EXPLAIN Function

As of SAP Enhancement Package 1 for SAP NetWeaver 7.0, you can use the EXPLAIN
function either in the new Web browser-based user interface or in the SAP GUI-based user
interface of the DBA Cockpit.
More Information
The EXPLAIN Function (New Web Browser-Based Version) [page 199]
The EXPLAIN Function (SAP GUI-Based Version) [page 202]

8.2.1 The EXPLAIN Function (New Web BrowserBased Version)

You can use the Web browser-based EXPLAIN to review the access plans of all SELECT,
INSERT, UPDATE, or DELETE statements.
You can access the Web browser-based version of the EXPLAIN function as follows:
In the navigation frame of the SAP GUI-based user interface of the DBA Cockpit,
choose Diagnostics EXPLAIN (New Version) A Web browser opens and
displays the screen EXPLAIN Access Plan. Enter an SQL statement and choose the
EXPLAIN pushbutton.
In the Favorites list of the Web browser-based user interface, choose Explain Access
Plan.

April 2010

199

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

In the database-specific area of the Web browser-based user interface, choose

Performance Snapshots Applications . Double-click an application and
choose the Statement Text tab page. If a statement is displayed, choose the
EXPLAIN pushbutton to display the access plan.
For more information, see Applications: Statements [page 74].
In the database-specific area of the Web browser-based user interface, choose
Performance Snapshots SQL Cache . Select a statement from the list and
choose the EXPLAIN pushbutton.
For more information, see Performance: SQL Cache [page 78].
Note
The statements might contain optional comments,such as --OPTLEVEL( <optlevel> ) -QUERY_DEGREE(< query_degree> --LOCATION( <report> , <position> ). If
no comments are specified, the statements are explained using the default <optlevel> and
the default <query_degree> for the work process.
End of the note.
If a statement was explained successfully, information about the SQL statement text is
provided on the following tab pages:
Tab Page

Description

Original Statement

Displays the original SQL statement

Optimized Statement

Displays the SQL statement that was rewritten by the DB2

optimizer

Access Plan

Displays the access plan that was generated by the DB2

optimizer
Displays the output of the EXPLAIN snapshot
Note

EXPLAIN Snapshot

The EXPLAIN Snapshot tab page is only available if the

monitored database is DB2 Version 9.5 for Linux, UNIX, and
Windows or higher.
End of the note.

Using the Access Plan

The access plan shows all database operations that are performed when the statement is
executed. It is displayed as a graphical tree and each node in the tree represents an operator
of the access plan.

200

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

You can:
Display or hide details of an operator by choosing the Open Node or Close Node icon
on the respective node
Expand or collapse subtrees by choosing the Show Child Node icon or the Hide Child
Node icon respectively
View operation details by double-clicking an operator in the graphical tree
Global details about an operator are displayed on the following tab pages:
o

General
Displays global details about the access plan

Operator <Name of operator>

Displays details for the selected operator

Catalog Information (Optional)

Displays details for the respective catalog object of the selected operator

Predicates (Optional)
Displays filter predicates for the selected operator

Search for operators in a complex statement by choosing Find Nodes for Labels
Open an extra navigation window for complex access plans by choosing Toggle
Navigation Window
Print the graphic by choosing Print the Current Model
Configure the graphic before you print it by choosing Configure the Printout
Display or hide the quick details of all operators by choosing Collapse or Expand
Display global details about the access plan by choosing View Details
Display information about the JNet version used (can be required by SAP Support) by
choosing the help button
Note
For each index used in the access plan, the number of key columns that were really used
within the access plan is displayed. In the appropriate tool tip, the used index field names are
also displayed.
Volatile tables and indexes of volatile tables are marked with an extra volatile label. To
change and re-explain the SQL statement, choose Edit Statement.
End of the note.

April 2010

201

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Changing the DB2 Optimizer Configuration

If you want to change the DB2 optimizer parameters, choose the Optimizer pushbutton. With
this function, you can temporarily change the OPTIMIZER LEVEL, the QUERY DEGREE,
and the VOLATILE flag for all tables referred to in the query. In addition, DB2 experts are
able to specify optimization guidelines.
User Interface Settings
If you want to change the user interface of the Web browser-based user interface, choose the
Settings pushbutton.

8.2.2 The EXPLAIN Function (SAP GUI-Based

Version)
You can use this function to explain all SELECT, INSERT, UPDATE, or DELETE statements.
The statements might contain optional comments such as --OPTLEVEL( <optlevel> ) -QUERY_DEGREE(< query_degree> --LOCATION( <report> , <position> ). If no
comments are specified, the statements are explained using the default <optlevel> and default
<query_degree> for the work process.
Accessing the EXPLAIN
You can call the EXPLAIN function in the following ways:
Call the DBA Cockpit and choose Diagnostics
EXPLAIN in the navigation frame of
the DBA Cockpit. On the Diagnostics: EXPLAIN screen, enter an SQL statement
manually and choose Explain.
Call the DBA Cockpit and choose Performance
Applications in the navigation frame
of the DBA Cockpit. For more information, see Applications: Statements [page 74].
Call the DBA Cockpit and choose Performance
SQL Cache in the navigation frame
of the DBA Cockpit. For more information, see Performance: SQL Cache [Page 78]
Call the DBA Cockpit and choose Diagnostics
Cumulative SQL Trace in the
navigation frame of the DBA Cockpit. For more information, see Diagnostics:
Cumulative SQL Trace [Page 222].
Call transaction ST05 and choose Enter SQL statement. Enter an SQL statement
manually and choose Explain.
If a statement cannot be explained, the ERROR: Check SQL Statement screen
appears providing a detailed error message and the possibility to modify the statement.
To continue, choose Explain Again.
Call transaction ST05 and choose Trace list. Select one statement and choose Explain.
Displaying the Access Plan of a Statement
If a statement was explained successfully, the Display Execution Plan for SQL Statement screen
appears, providing information on the SQL statement text, the OPTLEVEL and QUERY_DEGREE that
was used to explain this statement, and the access plan.
The access plan generated by the DB2 optimizer is displayed as a tree structure. It consists of all
database operations that will be performed when the statement is executed.

202

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The estimated execution time is displayed in timerons (arbitrary IBM time unit). All operators are
numbered, starting with zero. Operators can have the following extensions:
Extension

Description

[O]/[I]

Shows whether the operator acts as an outer/inner input branch

for a subsequent join operation

(<Partition>)

Shows on which partition this operation was performed

This is only displayed if you are using a multi partition database.

Non-volatile tables and indexes of non-volatile tables are displayed in blue. Volatile tables
and indexes of volatile tables are displayed in orange.
For each index used in the access plan, the number of key columns, that means index fields
that were really used within the access plan, are displayed.
For further analysis of the displayed information, you can choose from various options in the
application tool bar. For more information, see EXPLAIN Options [Page 203].
See also:
For more information about the EXPLAIN function, see SAP Note 400938.
For more information, see the IBM documentation: Administration Guide: Chapter 26, SQL
Explain Facility.

8.2.2.1 EXPLAIN Options

On the Display Execution Plan for SQL Statement screen, the following options are available:
Option

Description

Details

If no operator in the access plan is highlighted when choosing

this option, a dialog box is displayed providing detailed
information on the statement and each operator. This output is
similar to the one of the DB2 command line tool db2exfmt.
For more information, see the IBM documentation
Administration Guide, Appendix I.
If operator no. 0 is highlighted, only the original statement and
optimized statement are displayed in a separate dialog box.
If any other operator is highlighted, the system displays
detailed information on the selected operator only.

Optimizer

April 2010

The access plan may vary depending on the optimizer

parameters specified. When you choose this button, the
Change Query Optimization dialog box appears where you
can change the parameters OPTIMIZER LEVEL, QUERY
DEGREE, and the flag VOLATILE for the tables used in the
access plan. To explain the statement with new parameters,
choose Explain Again.

203

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

DB Catalog

With this option, you can display system catalog information

on tables and indexes that are shown in the access plan. The
following information is displayed:
For a table:
Selected information from table SYSCAT.TABLES is
displayed. Additionally, all indexes of the table are displayed
with their index columns.
For an index:
Selected information from table SYSCAT.INDEXES for this
index is displayed. Additionally, selected information from
table SYSCAT.COLUMNS is displayed for all index
columns.
Depending on whether you have selected a table or an index,
the following buttons are available:
Table
Displays selected information from table
SYSCAT.TABLES
Additionally, all indexes of the table are displayed with
their index columns.
Columns
Displays selected information from table
SYSCAT.COLUMNS for all table columns
Indexes
Displays information from table SYSCAT.INDEXES for all
indexes of the table as well as information from table
SYSCAT.COLUMNS for all index columns
Update Statistics
Updates the catalog statistics for the table
If the catalog statistics were updated successfully, the
field <stats-time> is displayed in green.
Table
Displays selected information from table
SYSCAT.TABLES
Additionally, all indexes of the table are displayed with
their index columns.

204

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Dictionary

With this option, you can display the ABAP Dictionary

structure (definition) of a table by selecting the table in the
access plan.
If you do not select a table in the access plan, the ABAP
Dictionary structure (definition) of the first dictionary object of
the SQL statement is displayed.
With this option, you can display the structure of views, even
though views never appear in the access plan.

This function is not available for systems

monitored using a remote database connection.
Test Execution

This option is only available, if a:

SELECT statement is explained using transaction ST05
Trace list, the parameter values for all parameter
markers of the statement are provided and the operation
is other than PREPARE
SELECT statement without parameter markers is
explained
When you use the EXPLAIN function, the entered SQL
statement is only prepared and the access plan of the
optimizer is chosen because of the system catalog statistics.
On the basis of this information the optimizer estimates the
costs for the execution of this statement.
However, the estimated costs may not correspond to the real
execution time. Reasons for this might be bad statistics, a bad
database layout or problems of the optimizer itself.
The Test Execution option measures the real execution time
and provides other snapshot data, such as the number of
buffer pool accesses and sorts for the selected statement.
When the statement is executed, the parameter markers are
replaced by the actual parameter values. A dialog box appears
where you can change these values to investigate the
dependence of the execution time from these values.
The result of several test executions of the same statement
can vary because, for example, the buffer pool may already
contain data that is necessary for the execution.

This function is not available for systems

monitored using a remote database connection.

April 2010

205

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tree Info

The following additional information is displayed or hidden:

num_rows
Estimated number of rows (result set)
tot_cost
Estimated total cost for this statement
i/o_cost
Estimated I/O cost of the statement
This information is also included in the output information
when you choose Details.

Edit

When choosing this option, the system switches to an editor

window in which you can modify the selected SQL statement
and explain it again.

Source

This option is only available when the statement contains a

LOCATION comment, for example, when you call EXPLAIN
using transaction ST05
Trace list.
The location of the statement in the ABAP source code is
displayed in a separate window.

This function is only available for the local system

or ABAP systems for which an additional RFC
destination has been assigned.

The Collect function is no longer available. To collect EXPLAIN data, use the
db2support command line tool.

8.3 Diagnostics: Missing Tables and Indexes

This function is only available for local systems or for ABAP systems for which
an additional RFC destination has been assigned.
You can find out whether tables or indexes are missing from either the database or the ABAP
Dictionary by calling the DBA Cockpit and choosing Diagnostics
Missing Tables and
Indexes in the navigation frame of the DBA Cockpit.
The results of the last consistency check are displayed in a tree structure that is grouped into
the following sections:
Section

Description

Objects missing from the

database

Objects that are defined in the ABAP

Dictionary, but not found in the database

206

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Unknown objects in the ABAP

Dictionary

Objects that are found in the database, but not

defined in the ABAP Dictionary

Inconsistent objects

Results of the detailed comparison of the ABAP

Dictionary and the database are displayed here

Other checks

Different checks are performed here:

It is checked whether the primary index
of tables defined in the ABAP Dictionary
was created uniquely on the database.
Objects in the SAP system tables are
checked, which cannot be described at
all or which cannot be completely
described in the ABAP Dictionary for
technical reasons.
If inconsistencies for these objects are
detected, they are also displayed here. In
general, additional information on the
type of inconsistency will be provided.

Optional indexes

Mismatch between ABAP Dictionary and

database regarding secondary indexes

If the database structure has been changed since the last consistency check, choose
Refresh.
For the local system you can:
Create objects that are defined in the ABAP Dictionary, but not found in the database,
by selecting the object and choosing Create on DB
Display the definition of an object by double-clicking the object

To ensure consistency between ABAP Dictionary and database, the consistency

check should be performed once a month or when database structure changes
have happened.

8.4 Diagnostics: Deadlock Monitor

The deadlock monitor records and analyzes deadlocks. Deadlocks occur when two or more
applications lock each other. Each application is waiting for the other to release the lock. DB2
automatically detects and resolves the deadlocks after a specified time period. This time
period is specified by database configuration parameter DLCHKTIME.
The data recorded provides detailed information about all involved database transactions. In
addition, you can display the complete statement history of each transaction including the
values that are bound to each statement.
Caution
Due to the detailed information that the deadlock monitor provides for each transaction,
activating it can have a considerable impact on the system performance.
End of the caution.

April 2010

207

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Integration
The deadlock monitor is part of the Computing Center Management System (CCMS). You
can access the deadlock monitor by calling the DBA Cockpit and choosing Diagnostics
Deadlock Monitor in the navigation frame of the DBA Cockpit.
Activities
You can perform the following actions:
If it does not exist yet, you first have to create a deadlock monitor.
You analyze deadlock monitor information.
You stop the deadlock monitor by choosing Stop Monitor.
You reset the deadlock monitor by choosing Reset. The recorded data is deleted and
you can restart analyzing new deadlock situations.
You drop the deadlock monitor and all related tables by choosing
Monitor .

Monitor

Drop

Note
If you want to move the deadlock monitor tables into a different tablespace, you must
drop the deadlock monitor and re-create it.
End of the note.

8.4.1 Creating the Deadlock Monitor

As long as the system cannot find an existing deadlock monitor, the message No Deadlock
Monitor found on system <system_name> is displayed.
You then need to create and start the deadlock monitor.
Procedure
1. Call the DBA Cockpit.
2. Choose
Cockpit.
The

Diagnostics

Diagnostics

Deadlock Monitor

Deadlock Monitor

in the navigation frame of the DBA

screen appears.

3. Choose Create Deadlock Monitor.

The Create Deadlock Monitor: Introduction dialog box appears.
4. Choose Continue.
Note
If you are using DB2 Version 8 FixPak 10 or higher, you can also specify the buffer
size of the deadlock monitor.
End of the note.

208

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5. On the second screen of the dialog box, choose the tablespace where the deadlock
monitor tables should reside. The dropdown list displays all the tablespaces that are
currently available.
Recommendation
The deadlock monitor works with an internal buffer that is allocated in the monitor
heap of the database. If this buffer runs out of space or if the deadlock monitor gets
flushed by the user, the recorded data is written to disk.
Depending on the system workload, the deadlock monitor tables can grow up to
several GB in size. We therefore recommend that you use a separate tablespace
managed by DB2s automatic storage management.
End of the recommendation.
6. Choose Create Monitor.
7. To start the deadlock monitor, choose Start Monitor.

8.4.2 Deadlock Monitor Analysis

When you have created and started the deadlock monitor, the following information is
displayed on the Diagnostics: Deadlock Monitor screen:
The main view
Locks held
Statement history (per agent)
Statement history (per deadlock)
Main View
All recorded deadlocks are displayed using a tree structure. For each recorded deadlock, the
root node Deadlock Victim: <rolled back application name> is displayed as well as the date
and time when the deadlock was detected.
If you open the subnodes of a root node, a hierarchic structure appears displaying data as
follows:
Deadlock Victim <Application Name of rolled-back Agent>
o

Agent <Agent ID> (<Application Name>) waiting for Agent <Agent ID>
Client Process ID: <Process ID>
Host: <Host>
Authorization ID:<DB2 User>
Lock Agent is waiting for:
Table: <Schema>.<Table>

April 2010

209

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Lock Object Type: <Lock Object Type>

Lock Current Mode: <Lock Mode>
Requested Lock Mode : <Lock Mode>
Displaying Agent Details
To display further details about the agents involved, choose Agent Details. The Diagnostics
Deadlock Monitor Agent Details screen appears. The following information is displayed:
Locks Held
Column

Description

Table Schema

Name of the schema to which the table belongs

Table Name

Name of the database table

Mode of the lock held

Lock Mode

Lock Object Type

If the Lock Status is Waiting, this is the lock mode that the agent is
intended to request.
Type of object to be locked
Status of lock request:

Lock Status

Granted
Waiting

Lock Escalation

Indicates if a lock request was made as part of a lock escalation

Lock Count

Number of locks on the lock being held

Number of holds placed on the lock

Lock Hold Count

Holds are placed on the locks by cursors registered with the WITH
HOLD clause and some DB2 utilities. Locks with holds are not released
when transactions are committed.

Lock Attributes

Lock attributes

210

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Statement History (per Agent)

Column
Last Use Time

Description
Timestamp when the statement was last executed
Displays the complete statement

Statement Text

If the statement does not fit completely in the column, choose Details or
double-click the row to get the complete statement text.

Isolation

This element shows the isolation value in effect for the statement while it
was being run.

Opt. Level

Optimization level

Query Degree

The query degree specifies the intrapartition parallelism for the

execution of SQL statements.
Statement type:

Statement Type

Dynamic
Static

To display more detailed information, select a row and choose Details. Alternatively, you can
double-click a field in a table row. As a result, the complete statement text is displayed in the
editor window.
In addition, the values bound to the SQL statement at execution time are displayed:
Column

Description

Val. Index

Value index (parameter marker index) in the statement text

Val. Type

Data type of the value

Data

Data

Null

Value is null.

Reopt

Value is used for REOPT.

April 2010

211

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Statement History (per Deadlock)

To display the statement history of an entire deadlock situation, choose Statement History.
The Diagnostics Deadlock Monitor Statement History screen appears.
The following information is displayed:
Column

Description

Last Use Time

Timestamp when the statement was last executed

Agent ID

ID of the agent that executed the SQL statement

Displays the complete statement

Statement Text

If the statement does not fit completely in the column, choose Details
or double-click the row to get the complete statement text.

Isolation

This element shows the isolation value in effect for the statement while
it was being run.

Opt. Level

Optimization level

Query Degree

The query degree specifies the intrapartition parallelism for the

execution of SQL statements.
Statement type:

Statement Type

Dynamic
Static

To display more detailed information, select a row and choose Details. Alternatively, you can
double-click a field in a table row. As a result, the complete statement text is displayed in the
editor window.
In addition, the values bound to the SQL statement at execution time are displayed:
Column

Description

Val. Index

Value index (parameter marker index) in the statement text

Val. Type

Data type of the value

Data

Data

Null

Value is null.

Reopt

Value is used for REOPT.

212

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.5 Diagnostics: SQL Command Line

This screen provides a virtual DB2 command line processor.
You can access it by calling the DBA Cockpit and choosing Diagnostics SQL Command
Line in the navigation frame. The Diagnostics: SQL Command Line screen appears.
If you enter any SQL command, the output is returned by the DB2 command line processor.
You can also execute CLP commands that are supported by the ADMIN_CMD stored
procedure. The data is displayed in the same way as the corresponding CLP commands.
Note
If you enter SQL commands that manipulate data, an error occurs.
End of the note.

8.6 Diagnostics: Index Advisor

To improve the performance of queries, you can retrieve recommendations about useful
indexes using the index advisor. In addition, you are able to design new virtual indexes that
can be validated before they are actually created.
You can access the index advisor using one of the following user interfaces:
Web browser-based interface
In your Favorites list, choose Index Advisor. The application starts in a separate Web
browser.
SAP GUI-based user interface
In the navigation frame of the DBA Cockpit, choose
. The Diagnostics: Index Advisor screen appears.

Diagnostics

Index Advisor

Activities
You use the index advisor to perform one of the following actions:
To evaluate the SQL statements in the dynamic SQL cache by receiving
recommendations for potential new indexes that might improve the overall system
performance
Based on the current content of the dynamic SQL cache, the DB2 Design Advisor
determines and recommends new indexes that might improve the overall system
performance.
For more information, see Retrieving Index Recommendations on the Dynamic SQL
Cache [page 214].

April 2010

213

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

To determine and recommend new virtual indexes for a single SQL statement
On the basis of a given SQL statement, the DB2 Design Advisor determines and
recommends new indexes that might improve the performance of the query.
For more information, see Retrieving Index Recommendations for a Single SQL
Statement [page 217].
To create user-defined virtual indexes
If you are not satisfied with the recommendations of the DB2 Design Advisor, you
create a virtual index specifically tailored to your requirements. For more information,
see Defining Virtual User-Defined Indexes [page 219].
To include the indexes in the EXPLAIN function when explaining a query
You can check, for example, if the virtually defined indexes would improve the
performance of a query. For more information, see Validating Indexes Using the
EXPLAIN Function [page 220].

8.6.1 Retrieving Index Recommendations for the

Dynamic SQL Cache
Note
This application is only available in the Web browser-based user interface.
End of the note.
1. On the Index Advisor screen, choose the SQL Cache radio button in the Advisor
Mode area.
2. Choose the Recommend Indexes pushbutton.
A background job starts. The DB2 Design Advisor analyses the current content of the
dynamic SQL cache and the background job returns the results as soon as the DB2
Design Advisor has finished its analysis.
The user interface remains in read-only mode while the analysis is still running. To
check for results, you can either choose the Update pushbutton, or wait until it is
automatically checked for results every 60 seconds.

214

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The results are displayed in the following table:

Column

Description

Index Name Name of the index

o

Existing (not-used)
Index exists in the system catalog, but for the investigated SQL query it
is not identified as usable by the DB2 optimizer.

Recommended
Index is recommended by the DB2 Design Advisor. Recommended
indexes that do not exist are candidates for new indexes to be created.
Note
Indexes are displayed with the following background colors:

Type

Green
Recommended index that already exists and that the DB2
optimizer would use
White
Existing index that is, however, not appropriate for the
respective SQL statement
Red
Recommended index that does not yet exist
End of the note.
o

Yes
Index exists in the database.

Exists
o

No
Index is a virtual index.

Table Name Table on which the index is defined

Schema

Name of the index schema

Specifies a unique rule:
o

Primary Key

Unique

Duplicates Allowed

Uniqueness

April 2010

215

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description

NLEAF

Number of leaf pages

NLEVELS

Number of index levels

o

Yes
Index supports reverse scans.

Rev. Scans
o

No
Index does not support reverse scans.

Columns

Number of columns in the key plus the number of included columns if there
have been any defined

INCLUDEs

Number of included columns

Column
Names

List of column names

3. To retrieve more information about which SQL statement would benefit from the
recommended indexes, select an index from the list.
The details are displayed in the following table in the content detail area:
Column

Description

SQL
Statement

Name of the SQL statement that is in the dynamic package cache and that
would benefit from the index

Frequency

Number of times the statement has been executed since it has entered the
dynamic SQL cache

Cost Saving

Estimated cost savings in percent after the index was created

Cost Before

Estimated SQL cost in timerons before the index was created

Cost After

Estimated SQL cost in timerons after the index was created

You can find the complete output of the DB2 design on the Advisor Output tab page.
The complete output also includes the estimated space requirements of each
recommended index.
Note
If you do not want to display indexes that are not used, you can set a filter on the
table accordingly.
End of the note.

216

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.6.2 Retrieving Index Recommendations for a Single

SQL Statement
1. On the Index Advisor screen, enter the SQL statement that you want to investigate in
the SQL Statement editor field.
Note
In the Web browser-based user interface, you first have to choose the Single
Statement radio button. Otherwise, the editor field where you can enter the SQL
statement does not become available.
End of the note.
2. Choose the Recommend Indexes pushbutton.
The DB2 Design Advisor evaluates existing indexes on the affected tables. If the DB2
Design Advisor cannot find an appropriate index in the system catalog, the tool
recommends one or more indexes that might improve the performance of the query.
The results are displayed in the following table:
Column
Index Name

Description
Name of the index
o

Existing (not-used)
Index exists in the system catalog, but for the investigated SQL
query it is not identified as usable by the DB2 optimizer.

User-Defined
Index has been virtually defined by the user to determine whether
such an index could be used to improve the query performance.
Those indexes do not exist in the system catalog.

Type

Recommended
Index is recommended by the DB2 Design Advisor.
Recommended indexes that do not exist are candidates for new
indexes to be created.
Note
Indexes are displayed with the following background colors:
Green
Recommended index that already exists and that the DB2
optimizer would use
White
Existing index that is, however, not appropriate for the
respective SQL statement

April 2010

217

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
Red
Recommended index that does not yet exist
End of the note.
o

Yes
Index exists in the database.

Exists
o

No
Index is a virtual index.

Table Name

Table on which the index is defined

Schema

Name of the index schema

Specifies a unique rule:
o

Primary Key

Unique

Duplicates Allowed

Uniqueness

NLEAF

Number of leaf pages

NLEVELS

Number of index levels

o

Yes
Index supports reverse scans.

Rev. Scans
o

No
Index does not support reverse scans.

Columns

Number of columns in the key plus the number of included columns if

there have been any defined

INCLUDEs

Number of included columns

Column Names

List of column names

Note
If you do not want to display indexes that are not used, you can set a filter on the
table accordingly.
End of the note.

218

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.6.3 Defining Virtual User-Defined Indexes

Caution
If you are using the Web Browser-based user interface, you can only perform the following
steps if the Single Statement radio button is selected in the Advisor Mode area of the Index
Advisor screen.
End of the caution.
If the index recommendations provided by the DB2 Design Advisor do not meet your
requirements, you can also define virtual user-defined indexes. In addition, you can validate
their use by calling the EXPLAIN function.
Prerequisites
You have already retrieved index recommendations for a single SQL statement [page 217].
Procedure
On the Index Advisor screen, choose Add Virtual Index. Depending on your user interface,
perform the following steps:
SAP GUI-Based User Interface
1. In the Define Virtual Index dialog box, enter the schema and the table on which you
want to define the virtual index.
2. Choose the Load Table Columns pushbutton.
The column names of the appropriate table are displayed in the Table Columns List
field.
3. To define index columns, either choose the Add Column to Index or the Remove
Column From Index pushbutton.
4. If you want the virtual index to be unique, select the Unique checkbox.
Note
By default, all new virtual indexes are created with the Allow Reverse Scans option
on database level. However, in the ABAP Dictionary, you cannot define this option for
new virtual indexes.
End of the note.
5. To continue, choose the Add pushbutton.
The new user-defined virtual index is added to the list of indexes.

April 2010

219

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Web Browser-Based User Interface

1. On the Diagnostics: Index Advisor dialog box, enter the schema and the table on
which you want to define the virtual index.
2. If you want the virtual index to be unique, select the Unique checkbox.
Note
By default, all new virtual indexes are created with the Allow Reverse Scans option
on database level. However, in the ABAP Dictionary, you cannot define this option for
new virtual indexes.
End of the note.
3. Choose the Index Columns pushbutton.
The column names of the appropriate table are displayed in the Table Columns List
field.
4. To define index columns, either choose the Add Column to Index or the Remove
Column from Index pushbutton.
5. To continue, choose the Add Virtual Index pushbutton.
The new user-defined virtual index is added to the list of indexes.
Note
User-defined indexes are always displayed with a red background color because they do not
really exist like the recommended indexes. If you want to remove all user-defined indexes,
choose the Remove User-Defined Indexes pushbutton.
End of the note.
Result
You can now use the EXPLAIN [page 199] function to validate existing, recommended, and
newly created user-defined indexes.

8.6.4 Validating Indexes Using the EXPLAIN Function

Procedure
On the Index Advisor screen, choose EXPLAIN and one of the following options from the
dropdown list:
Only existing indexes
This option corresponds to the normal EXPLAIN function that is known from the SQL
cache. Only indexes that are known from the system catalog are used to build the
access plan.
Existing and recommended indexes
Indexes that are known from the system catalog and indexes that are recommended
by DB2 are used to build the access plan.

220

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Existing, recommended, and user-defined indexes

Indexes that are known from the system catalog and all virtual indexes
(recommended and user-defined) are used to build the access plan.
Result
A new dialog window or Web browser appears displaying the access plan that the DB2
optimizer considers to be the most efficient one.

8.6.5 Creating Indexes in the ABAP Dictionary

Note
This function is not available for systems that are monitored using a remote database
connection.
End of the note.
You use the following procedure to create an index in the ABAP Dictionary that has been
virtually defined before but does not yet exist.
Recommendation
Additional indexes require additional space and need to be maintained when data is updated
or inserted in a table. We recommend that you only create additional indexes if they really
can improve the performance of queries that put a heavy load on your database.
End of the recommendation.
Procedure
1. On the Index Advisor screen, choose an index (user-defined or recommended) that
does not yet exist.
2. Choose the Create Index in ABAP Dictionary pushbutton (that is located next to the
Index Name column).
The Create Index in ABAP Dictionary dialog box appears.
3. Enter a description for the index and choose Create.
The index is created in the ABAP Dictionary.
After the index has successfully been created, you can decide if you want to schedule
a RUNSTATS for the affected table.
Note
If the index to be created is extending an existing unique index (including primary keys) with
one or more INCLUDE columns, you have to replace the existing index with a new index
instead of creating a new one.

April 2010

221

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

In this case, the Replace Existing Unique Index dialog box appears instead of the Create
Index in ABAP Dictionary dialog box. If you replace the existing index, the system replaces
the index only on database level. This means that no changes are applied to the ABAP
Dictionary. The replacement is automatically scheduled as an SQL script in the DBA Planning
Calendar.
End of the note.

8.7 Diagnostics: Cumulative SQL Trace

This function is not available for systems monitored using a remote database
connection.
You can access trace information on SQL statements by calling the DBA Cockpit and
choosing Diagnostics
Cumulative SQL Trace in the navigation frame of the DBA Cockpit.
The Diagnostics: Cumulative SQL Trace screen appears.
If you want to retrieve new data, choose Refresh.
The following information is displayed on the EXECUTE, PREPARE, and FETCH times of
SQL statements:
Column

Description

Total Time

Cumulative execution time of a statement

Proportional execution time of one statement with regard

to all executed statements

Count

Number of executions

Time/Stmt

Average execution time of one statement

Table

Name of the table the SQL statements reads from

If the statement reads from more than one table, only the
name of the first table is displayed on this screen. The
other names are displayed under Statement Information
on the detail screen.

SQL Statement

Complete SQL statement

If you want to display more detailed information, double-click a line or select a line and
choose Details. The Cumulative SQL Trace - Details screen appears providing information
on:
Statement Information
Displays the complete SQL statement, the application server where the statement was
executed and a list of all ABAP reports in which the statement can be found
Time Histograms
Displays the distribution times of the selected SQL statement
If you want to display the access plan for the execution of a single statement, select a line
and choose Explain. This function provides a detailed analysis of expensive SQL statements.
For more information, see The EXPLAIN Function [Page 202].

222

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

To display the ABAP source program where the statement was defined, choose one entry in
the list of ABAP reports. An editor screen appears, which contains the related source.

Since all trace data remains permanently in the database, you should delete
obsolete data before starting a new trace. To do this, choose Delete on the
Diagnostics: Cumulative SQL Trace screen.
For information on how to activate the cumulative SQL trace function, see SAP Note 139286.

8.8 Diagnostics: DBSL Trace Directory

This function is not available for systems monitored using a remote database
connection.
You can access information on the sequential DBSL trace and the DBSL deadlock trace by
calling the DBA Cockpit and choosing Diagnostics
DBSL Trace Directory in the navigation
frame of the DBA Cockpit.
By default, the trace files are stored in the following directories:
UNIX: /tmp/TraceFiles
Windows: <DRIVE>:\usr\sap\TraceFiles
For more information about DBSL trace files, see the following SAP Notes:
SAP Note 31707 for information on the sequential DBSL trace
SAP Note 175036 for information on the DBSL deadlock trace

8.9 Diagnostics: Trace Status

This function is only available for local systems.
You can access information on the current trace status trace by calling the DBA Cockpit and
choosing Diagnostics
Trace Status in the navigation frame of the DBA Cockpit.
The following information is displayed:
Field

Description

DBSL Trace
Trace Level

Specifies the amount of data to be traced

The following trace levels are available:
2: Only statements are traced.
3: Statements and results are traced.

April 2010

223

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Number of I/O Records to Be Traced

Number of result records to be traced for

a statement
This value is only displayed if trace level 3
is activated.

Display Length for String/Raw Data

Maximum output length

DBSL Trace Search String

If provided, only SQL statements

containing this string are traced.

DBSL Trace Minimum Time Limit

If provided, only SQL statements with

execution times higher than this time limit
are traced.

Cumulative Trace
Trace Level

Displays the trace level on the current

application server
It is set to:
0: Trace switched off
1: Trace switched on

First Trace Entry

Displays the start time of this trace if trace

information already exists

Last Trace Entry

Displays the end time of this trace if trace

information already exists

Number of Entries

Displays the number of entries in this

trace if trace information already exists

Deadlock Trace
Detection Interval

Only SQL statements running longer than

this time are recorded for deadlock
detection.

For each trace a status icon shows whether the trace is active or switched off.
In a local system you can activate or deactivate the trace function by clicking the
status icon. You can also maintain trace parameters in a local system.

8.10 Diagnostics: Database Notification Log

This function is only available if the monitored database is DB2 Version 9.1 for
Linux, UNIX, and Windows or lower. If your database is DB2 V9.5 for Linux,
UNIX, and Windows or higher, see Diagnostics: DB2 Logs [Page 227].
The DB2 notification log file is an error notification issued by the system when a severe error
occurs. The <instance_name>.nfy file is an ASCII file that contains information logged by
DB2. It is located in the directory specified by the DIAGPATH database manager configuration
parameter. The <instance_name>.nfy file can be quite large.

224

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

To avoid unnecessary system workload, you can restrict the amount of data that is processed
on your screen by defining a time range and a severity level according to your requirements.
You can access the Database Notification Log by calling the DBA Cockpit and choosing
Diagnostics
Database Notification Log in the navigation frame of the DBA Cockpit. To
display more details of a log entry, double-click the corresponding log entry.

The <instance_name>.nfy file grows continuously. When it becomes too

large, we recommend that you save it to a different file and delete the original
file.
More Information
IBM DB2 Administration Guide

8.11 Diagnostics: Database Diag Log

Note
This function is only available if the monitored database is DB2 Version 9.1 for Linux, UNIX,
and Windows or lower. If your database is DB2 V9.5 for Linux, UNIX, and Windows or higher,
see Diagnostics: DB2 Logs [page 227].
End of the note.
The db2diag.log file is an ASCII file that contains diagnostic information logged by DB2. It
is located in the directory specified by the DIAGPATH database manager configuration
parameter.
Recommendation
We recommend that you use a text editor to view the file on the machine where you suspect
a problem has occurred.
End of the recommendation.
The db2diag.log file contains the following information:
The location of the error being reported
Application identifiers allow to match up entries pertaining to an application in the
db2diag.log file.
A diagnostic message explaining the reason for the error
The messages usually begin with DIA.
Any available supporting data, such as SQLCA data structures and pointers to the
location of any extra dump or trap files

April 2010

225

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

There are two types of entries in the db2diag.log file:

Administrative events
These entries are valuable, since they indicate whether actions such as backups and
restores started and finished.
Error information
This information is only useful if you are trying to analyze an external symptom or if
you have already determined the error and are looking for more information.
Example
If an application receives an unexpected SQL code or if a database crashes, the file
can contain error information including pointers to dump files.
If the database is behaving normally, this type of information is not important and can
be ignored.
End of the example.
You can access the Database Diag Log by calling the DBA Cockpit and choosing
Diagnostics Database Diag Log in the navigation frame of the DBA Cockpit. The diag
log can be quite large. To avoid unnecessary system workload, you can restrict the amount of
data that is processed on your screen by defining a time range and a severity level according
to your requirements. To display more details of a log entry, double-click the corresponding
log entry.
Caution
Reading information from the db2diag.log is very time-expensive. Make sure that you
choose your time range and severity level carefully. Otherwise, SAP GUI timeouts can occur.
End of the caution.
Note
Since automatic RUNSTATS has been introduced by DB2, the db2diag.log rapidly grows in
size up to several gigabytes depending on the value of the DIAGLEVEL database
configuration parameter. By default, the value of this parameter is 3. We therefore
recommend that you regularly switch the db2diag.log using the automation function that is
provided in the monitoring settings [page 152].
End of the note.
More Information
IBM DB2 Administration Guide

226

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.12 Diagnostics: DB2 Logs

Note
This function is only available if the monitored database is DB2 Version 9.5 for Linux, UNIX,
and Windows or higher. If your database is DB2 V9.1 for Linux, UNIX, or Windows or lower,
refer to the following sections:
Diagnostics: Database Notification Log [page 224]
Diagnostics: Database Diag Log [page 225]
End of the note.
The Diagnostics: DB2 Logs screen provides you with information about all relevant log files of
DB2 including the following:
The database diagnostic log (db2diag.log)
Note
Since DB2's automatic RUNSTATS had been introduced, the db2diag.log can
rapidly grow in size up to several gigabytes depending on the value of the
DIAGLEVEL database configuration parameter. By default, the value of this
parameter is 3. We therefore recommend that you regularly switch the db2diag.log
using the automation function that is provided in the monitoring settings.
End of the note.
The database notification log (<instance_name>.nfy)
The statistics log
You can access the DB2 logs by calling the DBA Cockpit and choosing
Logs in the navigation frame of the DBA Cockpit.

Diagnostics

DB2

To avoid unnecessary system workload, you can restrict the amount of data that is processed
on your screen by specifying the following in the Filter group box:
A Log Facility
A Record Type
The minimum impact level (Impact)
A time range (Messages From / To)
After you have made your selection, choose the Find pushbutton. Information according to
the specified values is displayed including the appropriate DB2 component. To display
additional details about a log entry, double-click an entry in the list.
More Information
IBM DB2 Administration Guide

April 2010

227

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.13 Diagnostics: Dump Directory

The dump directory contains the following files:
DB2 diag log (db2diag.log)
DB2 notification log (<instance_name>.nfy)
DB2 dump files
User exit log and error files
Trace files
The system displays the content of the directory specified by the Diagnostic Data Directory
Path (diagpath). This path is configured within the database manager configuration.
You can access the dump directory by calling the DBA Cockpit and choosing Diagnostics
Dump Directory in the navigation frame of the DBA Cockpit.
If you want to display the content of an error log or a trace file, double-click the file.

8.14 Diagnostics: DB2 Information Center

To directly access information about DB2 in the Internet, choose Diagnostics DB2
Information Center in the navigation frame of the DBA Cockpit. The DB2 Information Center
for your database release is displayed.

228

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

9 Workload Management
Workload management is supported as of DB2 Version 9.5 for Linux, UNIX, and Windows. It
lets you distinguish and prioritize different types of work on the database. Workloads identify
the submitters of work by connection properties and assign incoming work to the service
classes. You use service classes to monitor and control resource consumption of the different
workloads.
Note
Setting up workload management is optional. If no workload management has been
configured, the database does not distinguish different types of work as known from previous
DB2 releases.
Accessing Workload Management in the DBA Cockpit
To access workload management, call the DBA Cockpit and choose Workload Management.
The following content areas are available:
Workloads and Service Classes
Critical Activities
SAP WLM Setup Status
Note
If you are using the SAP GUI-based user interface, the application starts in a
separate Web browser. By default, the Workloads and Service Classes content area
appears.
Workload Management in an SAP Environment
If you want to use workload management in an SAP environment, there is a proposed set of
workloads and service classes. To implement this proposed set of workloads and service
classes, use the guided procedure as described in Workload Management: SAP WLM Setup
Status [page 237].
A dedicated workload for each work process type in an SAP environment distinguishes
between different workloads on the database. Each workload is assigned to its own service
class. Therefore, you are able to monitor and prioritize each workload separately. The
following work process types are available in an SAP environment:
ABAP dialog
ABAP batch
ABAP spool
ABAP updater (primary and secondary)
Java (if available)
All work coming from outside the SAP system still resides in the default workload and default
service class of DB2.

April 2010

229

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following figure provides an overview of the proposed set of workloads and service
classes:

Workloads

Service Subclasses

SAP_ABAPDIA_WL

SAP_ABAPDIA_SSC

SAP_ABAPBTC_WL

SAP_ABAPBTC_SSC

SAP_ABAPSPO_WL

SAP_ABAPSPO_SSC

SAP_ABAPUPD_WL

SAP_ABAPUPD_SSC

SAP_ABAPUPD2_WL

SAP_ABAPUPD2_SSC

SAP_JAVA_WL

SAP_JAVA_SSC

SAP_DIAGNOSTIC_WL

SAP_DIAGNOSTIC_SSC

Service Superclasses

SAP_SC

Note
The workload SAP_DIAGNOSTIC_WL was created for usage in later releases.
Currently, no work goes into this workload.
End of the note.
Extended Workload Management with the Enhanced Prioritization Scheme
In addition to the workload management setup that is based on the type of work processes,
you can create one additional workload and service class using the enhanced prioritization
scheme. The enhanced prioritization scheme allows you to create one group consisting of
one of the following:
SAP users
SAP transactions
SAP application servers
You can monitor and prioritize this special group separately from the workloads that are
based on types of work processes.
For more information, see Workload Management: SAP WLM Setup Status [page 237].

230

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

More Information
Workload Management: Workloads and Service Classes [page 231]
Workload Management: Critical Activities [page 234]
Workload Management: SAP WLM Setup Status [page 237]

9.1 Workload Management: Workloads and

Service Classes
You use the data provided on the Workloads and Service Classes screen to get an overview
of the workload management configuration of the database system. In addition, you can
monitor service classes and maintain their priorities. To access the Workloads and Service
Classes screen, call the DBA Cockpit and choose Workload Management Workloads
and Service Classes .
Note
If you are using the SAP GUI-based user interface of the DBA Cockpit, the application starts
in a separate Web browser.
End of the note.
The following tab pages are available:
Overview
Workloads
Service Classes
Overview
On this tab page, an overview of all configured workloads, service superclasses, and their
subordinate service classes on the database system are displayed. The hierarchy of service
classes is displayed using the inheritance arrows that are known from UML diagrams.
Workloads
On this tab page, you can view details of all existing workloads. The following information is
displayed:
Column

Description

Position

Evaluation order used for choosing a workload

Workload Name

Name of the workload

Workload state

Enabled
The following states are possible:
Gree n

April 2010

231

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description
The workload is enabled.
Red

The workload is disabled.

DB Access Allowed

Determines whether units of work (UOWs) that are associated with the
workload are rejected or not

Service Class

Name of the service subclass to which an UOW that is associated with

this workload is assigned

Parent Service Class

Name of the service super class to which an UOW that is associated

with this workload is assigned.

By selecting a workload, additional information on the selected workload is displayed on the

following tab pages in the lower half of this screen:
General
Displays details about the workload from the system catalog as well as the
configuration for collecting statistics on the workload
Connection Attributes
Displays all the attributes that associate an incoming activity with the selected
workload.
For an activity to be associated with a certain workload, all the connection attributes
of the incoming activity must match the definition of the workload (Boolean AND). If a
single attribute type is specified more than once, this indicates that only one of them
must match the activity (Boolean OR).
Service Classes
On this tab page, you can view details of existing service classes. The following information is
displayed:
Column
Service Class

Description
Name of the service class
State of service class
The following states are possible:
Green

Enabled
The service class is enabled.
Red
The service class is disabled.

232

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Graphical display of the thread priority of the agents in the service

class

Agent Priority

Thread priority of the agents in the service class in relation to the

normal priority of DB2 threads
Agent Priority (Remarks)
The value DEFAULT indicates that the thread priority was inherited
from the parent service class.
Prefetch Priority

Graphical display of the agent's prefetch priority in the service

class

Prefetch Priority
(Remarks)

Prefetch priority of the agents in the service class

When you select a single service class in the table, further details for this service class are
displayed. You are able to retrieve monitoring information for all work that has been going on
in that service class. You are also able to change the agent and prefetch priority of this
service class.
The following tab pages are available:
General
Displays details about the service class from the system catalog as well as the
configuration for collecting statistics on the service class
For more information about how to change the agent or prefetch priority for a service
class, see Changing Priorities of Service Classes later in this section.
Statistics
Displays monitoring information that is related to the service class
To switch the time frame for which monitoring data is aggregated, choose the
corresponding menu button indicating the time frame you have chosen. To analyze
slowdowns in the service class, you can also choose between different types of
diagrams:
o

Activity Execution Time Histogram

Displays the history of the histogram for the execution times of all activities
that were executed in the service class for the selected time frame

Activity Lifetime Histogram

Displays the history of the histogram for the lifetimes of all activities that were
executed in the service class for the selected time frame

Activity Queue Time Histogram

Displays the history of the histogram for the queue times of all activities that
were executed in the service class for the selected time frame

For more information about the histogram types and all other monitoring counters
provided here, see Workload Management Monitor Elements in the IBM DB2 V9.5
Information Center at:

April 2010

233

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.
mon.doc/doc/r0051833.html
Changing Priorities of Service Classes
By changing agent priorities or prefetch priorities of certain service classes, you can distribute
database resources among different types of workloads as follows:
1. On the Service Classes tab page, select one entry from the table.
The General tab page and the Statistics tab page are displayed in the lower half of
the screen.
2. On the General tab page, choose the Change Prioritization pushbutton.
3. To adjust the agent priority or prefetch priority, use one of the following pushbuttons:
o

Increase <Agent or Prefetcher> Priority

Decrease <Agent or Prefetcher> Priority

Inherit <Agent or Prefetcher> Priority from Parent Class (DEFAULT)

Resets the priority from its parent service class to the default value.

4. To save your changes, choose the Apply Changes pushbutton.

Note
If you do not want to apply the changes, choose the Reject Changes pushbutton.
End of the note.
Caution
If not chosen carefully, changing the agent or prefetch priority can significantly decrease the
performance of some workloads.

9.2 Workload Management: Critical Activities

On the Critical Activities screen, you can define thresholds for database activities on the
database system. In addition, you can gather information about threshold violations for later
analysis. To access the Critical Activities screen, call the DBA Cockpit and choose
Workload Management Critical Activities .
Note
If you are using the SAP GUI-based user interface of the DBA Cockpit, the application starts
in a separate Web browser.
End of the note.

234

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The Critical Activities screen is divided into three areas:

Threshold Configuration
Threshold Violations
Threshold Violation Details
Note
Threshold Violation Details appears only if you selected a threshold violation from the
list.
End of the note.
Threshold Configuration
In this screen area, all defined thresholds for the database system are displayed and you can
use the following functions:
Enable or disable a threshold by selecting a line from the list and choosing the
Enable / Disable Threshold pushbutton.
Create a threshold by selecting a line from the list and choosing the Create Threshold
pushbutton.
A wizard appears that guides you through the creation of a threshold.
Drop a threshold by selecting a line from the list and choosing the Drop Threshold
pushbutton.
Note
If the WLM event monitors have not yet been created on the database, you can do so by
choosing the Set Up the WLM Event Monitors pushbutton. A wizard appears that guides you
through the creation of a WLM event monitor.
The DB2 database uses the WLM event monitor tables to store statistical data on activities
that occur on the database. For more information, see Workload Management: SAP WLM
Setup Status [page 237].
End of the note.

April 2010

235

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Threshold Violations
In this screen area, a history of threshold violations on the database system is displayed:
Column

Description

Violation

Time when the threshold violation occurred

Partition

Database partition where the violation occurred

Predicate that was violated
Note

Predicate

Activities with the value MANUAL were captured manually on the

Application Snapshot screen.
For more information, see Performance: Applications [page 56].
End of the note.

Violated Value

Value that was exceeded, which violated the threshold predicate

Application ID

Application ID of the activity that caused the violation

Agent ID

Agent ID of the activity that caused the violation

By default, the history of such a threshold violation is kept for two weeks. To delete all
recorded threshold violations, choose the Reset Violation History pushbutton.
For more information about how to change the size of the violation history, see Performance
Warehouse: Configuration [page 92].
Threshold Violation Details
In this screen area, details about a selected threshold violation are displayed.
The following tab pages are available:
General
On this tab page, details about the activity that violated the threshold as well as about
the execution statistics for that particular activity are displayed.
SQL Statement(s)
On this tab page, the SQL statement that was executed within the activity is
displayed. In case of nested statement calls, for example, during the execution of
stored procedures, more than one SQL statement can be available. You can retrieve
additional information about the bind values and further details on a single SQL
statement as follows:
1. On the SQL Statement(s) tab page, select one statement from the list.
2. To retrieve a newly generated access plan of the selected SQL statement,
choose the EXPLAIN pushbutton.

236

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The new access plan is displayed in a separate window.

3. To retrieve the current access plan as it exists in the SQL cache of the DB2
engine, choose the Section EXPLAIN pushbutton.
The current access plan is displayed in a separate window.
Note
To be able to retrieve the Section EXPLAIN, the DB2 registry variable
DB2_DUMP_SECTION_ENV has to be set to ON.
For more information, see SAP Note 1227225.

9.3 Workload Management: SAP WLM Setup

Status
The SAP WLM Setup Status screen provides you with an overview of the workload
management configuration in your SAP system. To access the SAP WLM Setup Status
screen, call the DBA Cockpit and choose Workload Management SAP WLM Setup
Status .
Note
If you are using the SAP GUI-based user interface of the DBA Cockpit, the application starts
in a separate Web browser.
The following information is displayed:
Area

Description
Indicates if the SAP-proposed workloads and service classes
have been set up:

Workloads and Service

Classes

If they have not yet been set up, you can choose the
Setup SAP Workloads and Service Classes pushbutton.
A wizard appears that guides you through the setup
process of the SAP-proposed workloads and service
classes.
If they have been set up, you can modify the enhanced
prioritization scheme, which had been configured on the
database system, by choosing the Modify Enhanced
Prioritization Scheme pushbutton. If you want to drop the
SAP workloads and service classes, choose the Drop
SAP Workloads and Service Classes pushbutton.

Event Monitor
Infrastructure

April 2010

Indicates the availability of tablespace SAPEVENTMON and

database partition group SAPEVENTMONGRP
The history of the monitoring information for workload
management is collected by DB2 event monitors. For all event

237

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Area

Description
monitor tables, tablespace SAPEVENTMON was introduced.
To be able to distribute the event monitor tables if the database
system is using the database partitioning feature (DPF),
database partition group SAPEVENTMONGRP was introduced
containing tablespace SAPEVENTMON.
If the database partition layout changes, you must redistribute
the event monitor tables over all partitions by choosing the
Redistribute Event Monitor Infrastructure pushbutton.
Indicates if the WLM event monitors already exist and if the
stored procedure that cleans the event monitor tables was
scheduled. By default, event monitor data is kept for two weeks.
For more information, see Performance Warehouse:
Configuration.

WLM Event Monitors

If the WLM event monitors have not yet been created on the
database, you can do so by choosing the Setup WLM Event
Monitors pushbutton. A wizard appears that guides you through
the creation of a WLM event monitors.
Alternatively, you can choose the Activate Event Monitors or
Deactivate Event Monitors pushbutton to control the collection of
monitoring information in the event monitor tables. If you want to
drop the event monitors and the appropriate tables, choose the
Drop WLM Event Monitors pushbutton.

238

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

10 BW Administration
The following sections provide information on BW administration:
BW Administration: BW Data Distribution
BW Administration: MDC Advisor

10.1 BW Administration: BW Data Distribution

During the SAP system installation, you can add additional database partitions either using
SAPinst or manually using db2start. Before the partitions that you have added can become
active, you have to perform the following actions:
Change the assignment of database partition(s) to database partition group(s)
Define tablespace containers on the new database partition
Determine if and when the affected tablespaces will be redistributed
To perform these tasks, you use the BW Data Distribution wizard.
You can access the BW Data Distribution wizard by calling the DBA Cockpit and choosing
BW Data Distribution in the navigation frame of the DBA Cockpit.
For more information about the steps to perform, see the screens of the BW Data Distribution
wizard.

10.2 BW Administration: MDC Advisor

The MDC advisor is a DB2 tool that proposes multidimensional clustering (MDC) settings for
tables using queries executed on the table. You use the MDC advisor to collect BW reporting
queries for an InfoProvider, that is, for InfoCubes and DataStore objects. The MDC Advisor
analyzes the collected BW reporting queries and returns a proposal for MDC settings for the
fact tables of an InfoCube and for the active table of a DataStore object. Based on this MDC
proposal, you can change the clustering of the analyzed InfoProvider using transaction RSA1
in your SAP system.
You access the MDC advisor by calling the DBA Cockpit and choosing
MDC Advisor in the navigation frame.

BW Administration

More Information
For more information about the MDC advisor, see the Database Administration Guide: SAP
NetWeaver Business Warehouse 7.0 and Higher Administration Tasks: IBM DB2 for Linux,
UNIX, and Windows at:
http://service.sap.com/instguidesnw
Database-Specific Guides

April 2010

<Your SAP NetWeaver Release>

Operations

239

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

10.3 BW Administration: Administration and

Monitoring of the Near-Line Storage (NLS)
Database
Near-line storage (NLS) is a new category of data persistency that is similar to archiving. The
overall goal is to take read-only data out of the BW database and to store it in an additional
near-line storage DB2 database. The database server and the storage devices of the nearline storage solution can be separated from the SAP NetWeaver database hardware but you
can still access the separated data transparently from an SAP NetWeaver BW system (in the
following referred to as BW system).
Using the NLS database includes the following administrative tasks:
Configuring the NLS database as a monitored system in the DBA Cockpit
For more information, see Configuration of Systems for Remote Monitoring [page 14].
Configuring the database connections that are required to access the NLS database
from the local BW system using the NLS Configuration screen in the DBA Cockpit
Note that this task is an extension to the standard database connection maintenance.
For more information, see BW Administration: NLS Configuration [page 240].
Monitoring the BW objects of which data has been archived to the NLS database
using the NLS Overview screen in the DBA Cockpit
On this screen, you can monitor the space consumption of BW objects in both the
SAP NetWeaver Business Warehouse database and in the related NLS database.
For more information, see BW Administration: NLS Overview [page 242].
Cleaning up invalidated data in the NLS database using the NLS Cleanup job in the
DBA Planning Calendar
For more information, see Running the NLS Cleanup Job [page 185].

10.3.1 BW Administration: NLS Configuration

Note
This screen is only available for a local BW system.
End of the note.
The BW Administration NSL Configuration screen provides you with an overview of all NLS
databases that are connected to your SAP NetWeaver Business Warehouse system.
To access the BW Administration NLS Configuration screen, call the DBA Cockpit and
choose BW Administration NLS Configuration in the navigation frame.

240

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

A table of all configured NLS connections is displayed providing the following information:
Column

Description

Connection Name Name of the database connection that is used to access the database
DB Name

Name of the assigned NLS database

DB Server

Name of the host where the NLS database is installed

Schema Name

Name of the NLS database schema

User Name

Name of the database user that is used to connect to the NLS database

To maintain your NLS configurations, you can use the following pushbuttons from the
application toolbar:
To create a new NLS configuration entry, choose Add.
To change an existing NLS configuration, choose Change.
To delete an existing NLS configuration, choose Delete.
To perform these tasks, the standard maintenance screen for the configuration of database
connections [page 16] is used.
In all cases, a dialog box appears with a detailed maintenance screen for the database
connection related to the NLS database. To check the availability of the NLS connection,
choose Test Connection. The result of the connection test appears in the action message
window in the lower half of the screen.
Note
If you create the NLS connection using directly the database connection maintenance
functions without the NLS Configuration screen, the configuration data for the NLS
connection is not created. Make sure you use the NLS Configuration screen.
End of the note.
More Information
Adding a Database Connection [page 17]
Changing a Database Connection [page 19]
Deleting a Database Connection [page 19]
Testing a Database Connection [page 19]

April 2010

241

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

10.3.2 BW Administration: NLS Overview

Note
This screen is only available for a local BW system.
End of the note.
The BW Administration NLS Overview screen provides you with an overview of
InfoProviders that are connected to an NLS database. You can use the information on this
screen to analyze the space consumption of an InfoProvider in the BW database in
comparison to the remote NLS database. In addition, you can update the configuration of
your BW queries so that they automatically read data from the NLS database.
To access the BW Administration NLS Overview screen, call the DBA Cockpit and choose
BW Administration NLS Overview in the navigation frame. To specify which
InfoProviders are displayed, enter the required data in the following input fields and choose
the Apply pushbutton:
InfoProvider Name
InfoProvider Size (KB)
NLS Connection
NLS Size
The following table displays all InfoProviders that meet the specified selection criteria:
Column
InfoProvider Name

Description
Name of the InfoProvider
Total size of all database tables of the InfoProvider in KB
Note

InfoProvider Size
(KB)

This size information is not newly calculated but retrieved from values
that were previously provided by the REORGCHK for All Tables job
and might therefore not be accurate. If you do not run the
REORGCHK for All Tables job, the displayed value is -1.
For more information, see Scheduling a REORGCHK for All Tables
[page 178].

NLS Connection

Name of the NLS connection

NLS Name

Name of the NLS database schema

242

April 2010

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Total size of all database tables of the InfoProvider in the NLS

database
Note
NLS Size

This value is only available if the NLS database has been configured
and properly set up for monitoring in the DBA Cockpit.
For more information, see Configuration of Systems for Remote
Monitoring [page 14] and Scheduling a REORGCHK for All Tables
[page 178].

Query Enabled

Indicates whether the BW queries of the InfoProvider have been

enabled to read data from the NLS database

Enabling BW Queries to Use the Near-Line Storage Database

By choosing the Enable Queries pushbutton, you activate the Query Enabled option of an
InfoProvider. That is, the configuration of all BW queries of a single InfoProvider is updated
and the queries are enabled to also read data from the NLS database. After a data archiving
process has been created for an InfoProvider, the new property Read Near-Line Storage as
well is assigned to the BW queries. A BW query with this property reads data both from the
BW database and from the NLS database. If the Read Near-Line Storage as well property is
not assigned, the NLS data is not used to build the query results.
Displaying Details of InfoProviders
To display detailed information about an InfoProvider, double-click an InfoProvider, or select it
and choose the Details pushbutton. The NLS Details screen appears displaying details of the
InfoProviders in two tables:
In the left table, the schema name, table name, and size of the database tables that are
associated with the InfoProvider in the BW database are displayed. The right table displays
the same information for the database tables representing the InfoProvider in the NLS
database.

10.3.3 Analyzing Single Tables of the BW and the NLS

Database
To analyze a single table of an InfoProvider, double-click an InfoProvider in the left table on
the NLS Details screen, or select the InfoProvider and choose the Details pushbutton. The
Space: Table and Indexes Detail screen appears providing detailed technical information, for
example, about the structure of the selected table, its indexes, and the tablespaces used.

April 2010

243

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Caution
If you want to analyze a single NLS table, you cannot navigate to the Space: Single Table
Analysis screen by double-clicking a table cell in the right table of the NLS Details screen.
Instead, proceed as follows:
1. Select the NLS database system from the Currently Selected System dropdown list in
the system landscape toolbar of the DBA Cockpit.
2. In the navigation frame, choose

Space

Single Table Analysis

3. On the Space: Tables and Indexes Details screen, enter the schema and the table
name of the NLS table in the appropriate fields.
End of the caution.
For more information, see Space: Single Table Analysis [page 106].

244

April 2010