Sei sulla pagina 1di 240

Database Administration Guide

Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows
For SAP Systems based on SAP Enhancement Package 1 for SAP NetWeaver 7.0

Document Version 1.00 September 8th, 2008 Public

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 2008 SAP AG. All rights


reserved.
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. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. 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. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. 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 Citrix Systems, Inc. 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 respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated 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.

Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address:
service.sap.com/instguides

Typographic

Conventions
Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation

Icons
Icon Meaning Caution Example Note Recommendation Syntax

Type Style Example Text

Example text

Emphasized words or phrases in body text, graphic titles, and table titles 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. 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. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.

EXAMPLE TEXT

Example text

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.

Example text

<Example text>

EXAMPLE TEXT

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..........................................................17 1.1.3.1.1.4 Deleting a Database Connection.................................................................20 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) ........................... 22

2 Performance ......................................................................................26
2.1 Performance: Partitions....................................................................... 26 2.2 Performance: Database ....................................................................... 28
2.2.1 Database: Buffer Pool.................................................................................................28 2.2.2 Database: Cache ........................................................................................................31 2.2.3 Database: Asynchronous I/O......................................................................................32 2.2.4 Database: Direct I/O ...................................................................................................33 2.2.5 Database: RealTime Statistics..................................................................................34 2.2.6 Database: Locks and Deadlocks ................................................................................35 2.2.7 Database: Logging......................................................................................................36 2.2.8 Database: Calls...........................................................................................................38 2.2.9 Database: Sorts ..........................................................................................................40 2.2.10 Database: XML Storage ...........................................................................................41

2.3 Performance: Schemas ....................................................................... 42 2.4 Performance: Buffer Pools.................................................................. 43


2.4.1 Buffer Pool ..................................................................................................................44 2.4.2 Buffer Pools: Asynchronous I/O..................................................................................47 2.4.3 Buffer Pools: Direct I/O ...............................................................................................48 2.4.4 Buffer Pools: XML Storage .........................................................................................49

2.5 Performance: Tablespaces.................................................................. 50


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

2.6 Performance: Tables............................................................................ 56 2.7 Performance: Applications.................................................................. 57


2.7.1 Applications: Application.............................................................................................59 2.7.2 Applications: Agents ...................................................................................................63 2.7.3 Applications: Assigned Agents ...................................................................................65 2.7.4 Applications: Agents Memory .....................................................................................66

September 2008

2.7.5 Applications: Buffer Pool.............................................................................................67 2.7.6 Applications: Direct I/O ...............................................................................................69 2.7.7 Applications: XML Storage .........................................................................................70 2.7.8 Applications: Locks and Deadlocks ............................................................................71 2.7.9 Applications: Calls.......................................................................................................73 2.7.10 Applications: Sorts ....................................................................................................74 2.7.11 Applications: Cache ..................................................................................................75 2.7.12 Applications: Unit of Work.........................................................................................76 2.7.13 Applications: Statement ............................................................................................76 2.7.14 Applications: Statement Text ....................................................................................78 2.7.15 Applications: SQL Workspace ..................................................................................80

2.8 Performance: SQL Cache .................................................................... 81 2.9 Performance: Lock Waits and Deadlocks .......................................... 85 2.10 Performance: Inplace Table Reorganization.................................... 87 2.11 Performance: History - Database...................................................... 89 2.12 Performance: History Tables.......................................................... 91 2.13 Performance: Performance Warehouse ........................................... 92
2.13.1 Performance Warehouse: Reporting ........................................................................93 2.13.2 Performance Warehouse: Configuration ..................................................................94

3 Space..................................................................................................97
3.1 Space: Automatic Storage................................................................... 97 3.2 Space: Tablespaces ............................................................................. 98
3.2.1 Maintaining Tablespaces ..........................................................................................101

3.3 Space: Containers.............................................................................. 106 3.4 Space: Tables and Indexes ............................................................... 106 3.5 Space: Single Table Analysis............................................................ 108 3.6 Space: Virtual Tables ......................................................................... 123 3.7 Space: History - Overview ................................................................. 124 3.8 Space: History - Database and Tablespaces ................................... 126 3.9 Space: History - Tables and Indexes ................................................ 128

4 Backup and Recovery.....................................................................130


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

5 Configuration...................................................................................131
5.1 Configuration: Overview.................................................................... 131 5.2 Configuration: Database Manager .................................................... 135 5.3 Configuration: Database.................................................................... 137
5.3.1 Maintaining the Database Configuration...................................................................139 5.3.2 Comparing Database Configuration Parameters for Several Database Partitions ..139

5.4 Configuration: Registry Variables (DB2 for Linux, UNIX, and Windows ................................................................................................... 140 5.5 Configuration: Parameter Changes .................................................. 140 5.6 Configuration: Database Partition Groups ...................................... 141
5.6.1 Maintaining Database Partition Groups ....................................................................142

5.7 Configuration: Buffer Pools .............................................................. 146


5.7.1 Maintaining Buffer Pools...........................................................................................146

September 2008

5.8 Configuration: Special Tables Regarding RUNSTATS.................... 149 5.9 Configuration: File Systems.............................................................. 151 5.10 Configuration: Data Classes ........................................................... 152
5.10.1 Maintaining Data Classes .......................................................................................153

5.11 Configuration: Monitoring Settings ................................................ 155 5.12 Configuration: Automatic Maintenance Settings .......................... 156
5.12.1 Configuring General Maintenance Settings............................................................157 5.12.2 Configuring Automatic Backup Settings .................................................................158 5.12.3 Configuring Automatic RUNSTATS Settings..........................................................161 5.12.4 Configuring Automatic REORG Settings ................................................................162

6 Jobs..................................................................................................166
6.1 Central Calendar................................................................................. 166
6.1.1 Using the Central Calendar ......................................................................................167

6.2 The DBA Planning Calendar.............................................................. 169


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

6.3 The DBA Log....................................................................................... 189 6.4 Back-End Configuration .................................................................... 190 6.5 The SQL Script Maintenance............................................................. 191

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

8 Diagnostics......................................................................................201
8.1 Diagnostics: Displaying the Audit Log............................................. 201 8.2 The EXPLAIN Function ...................................................................... 202
8.2.1 The EXPLAIN Function (New Web Browser-Based Version) ..................................202 8.2.2 The EXPLAIN Function (SAP GUI-Based Version)..................................................205 8.2.2.1 EXPLAIN Options................................................................................................206

8.3 Diagnostics: Missing Tables and Indexes ....................................... 209 8.4 Diagnostics: Deadlock Monitor......................................................... 211
8.4.1 Creating the Deadlock Monitor .................................................................................212

September 2008

8.4.2 Deadlock Monitor Analysis .......................................................................................213

8.5 Diagnostics: SQL Command Line..................................................... 217 8.6 Diagnostics: The Index Advisor........................................................ 217
8.6.1 Retrieving Index Recommendations.........................................................................218 8.6.2 Defining Virtual User-Defined Indexes......................................................................219 8.6.3 Validating Indexes Using the EXPLAIN Function .....................................................220 8.6.4 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 .................................................................... 226 8.13 Diagnostics: Dump Directory .......................................................... 228 8.14 Diagnostics: DB2 Help Center......................................................... 228

9 Workload Management...................................................................229
9.1 Workload Management: Workloads and Service Classes .............. 231 9.2 Workload Management: Critical Activities ....................................... 235 9.3 Workload Management: SAP WLM Setup Status ............................ 238

10 BI Administration ..........................................................................240
10.1 BI Administration: BI Data Distribution.......................................... 240 10.2 BI Administration: MDC Advisor..................................................... 240

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows
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.

September 2008

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 (Web Dynpro) [page 22]

September 2008

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

System landscape toolbar

Central system data

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

September 2008

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]

September 2008

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 Last Refresh DB Name Started DB Release Description Date and time when the screen data was last refreshed Name of database of the selected system Date and time when the database engine started Database release Date and time of last reset or checkpoint of the monitored data Note 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: Current Selection Since DBM Start Reset Since Reset

Last Reset/Checkpoint

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

September 2008

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.

September 2008

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

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

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.3.1 Configuring Systems for Remote Monitoring Using Remote Database Connections
Use 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.

September 2008

15

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. If required, enter the name of the RFC connection.

e.

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

Enter a description of your system. 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.

This function is only available for IBM DB2 for i.

If data for the central planning calendar is to be provided, select Collect Central Planning Calendar Data.

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

16

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 Remote Database Connections Description Name of database connection

This is a unique name that you can freely choose. DB Name DB Host DB Schema User Permanent Max. Connections Opt. Connections Name of database Name of database host Name of the database schema to be monitored Name of the connection user Specifies whether the connect user must be permanently available Maximum allowed number of open 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.

More Information: Adding a Database Connection Changing a Database Connection Deleting a Database Connection Testing a Database Connection

September 2008

17

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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. b. In the Database System field, specify the name of the database platform. In the Connection Maximum field, enter an appropriate 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. In the Connection Optimum field, enter an appropriate value. This value is a more flexible limit that can be exceeded. 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.

c. d.

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. In the Password field, enter a password for the connect user.

f.

18

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6. In the Connection Parameters table, specify the following additional database-specific attributes: Attribute Database Name Service Name Description Name of database 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 Schema Name Name of the remote database server Name of schema to be monitored

If you omit this field, the name of the specified connect user is used as default schema.

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


C...

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

September 2008

19

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

1.1.3.1.1.3 Testing a Database Connection Use 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


4. Call the DBA Cockpit. 5. In the system landscape toolbar, choose DB Connections. 6. 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.

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:

20

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

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.

September 2008

21

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Web Dynpro 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 BI). 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:
Common header area Top level navigation including second-level navigation Framework message window Detail navigation Central system data

System landscape selector

Content area

Favorite list Content detail area

22

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

23

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

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 area shows details that are related to some list display.

24

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 o o 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. 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 202] Diagnostics: SQL Command Line [page 217]

September 2008

25

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2 Performance
The following sections provide information on performance: Performance: Partitions [page 26] Performance: Database [page 28] Performance: Schemas [page 42] Performance: Buffer Pools [page 43] Performance: Tablespaces [page 50] Performance: Tables [page 56] Performance: Application [page 57] Performance: SQL Cache [page 81] Performance: Lock Waits and Deadlocks [page 85] Performance: Inplace Table Reorganization [page 87] Performance: History Database [page 89] Performance: History Tables [page 91] Performance: Performance Warehouse [page 92]

2.1 Performance: Partitions


In multi-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 Partition Description 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 Total size in KB of all buffer pools used for a partition Pools Data Logical Reads Index Logical Number of read accesses to data in the buffer pool Number of read accesses to index data in the buffer pool

26

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Reads

Description

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 Average time in milliseconds required to read data from disk into the buffer pool Time (ms) Avg. Phys. Write Average time in milliseconds required to write data from the buffer pool to disk Time (ms) 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 As of DB2 Version 5, each database agent accesses a global cache. Package Cache Quality (%) Tells you whether or not the package or catalog cache is being used effectively. If the hit ratio of the package or catalog cache is greater than 95%, the cache is performing well.

Package Cache Size

Note If you double-click a line, a database snapshot data is retrieved and displayed as described in Performance: Database [page 28]. End of the note.

September 2008

27

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

2.2 Performance: Database


The Database Snapshot screen provides an overview of the following critical database performance indicators: Buffer Pool [page 28] Cache [page 31] Asynchronous I/O [page 32] Direct I/O [page 33] Real-Time Statistics [page 34] Locks and Deadlocks [page 35] Logging [page 36] Calls [page 38] Sorts [page 40] XML Storage [page 41]

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.

28

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Buffer Pools Number Total Size Buffer Quality Number of buffer pools

Description

Total size in KB of all buffer pools

Overall Buffer Quality

Indicates percentage at which the data is read from the buffer pool, rather than directly from the hard disk This is calculated using the following formula: (logical reads - physical reads) / (logical reads) * 100 Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk Indicates the frequency as a percentage at which index data is read from the buffer pool, rather than directly from the hard disk Number of times an agent did not have a preselected victim buffer available

Data Hit Ratio

Index Hit Ratio

No Victim Buffers Average Time Physical Reads

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

Physical Writes 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). Number of read accesses to data on disk (by agents)

Synchronous Reads

September 2008

29

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Synchronous Writes

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

Temporary Logical Number of logical read requests that required I/O to get data pages into the temporary tablespace Reads Temporary Physical Reads 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). Number of read accesses to index data on disk (by agents) Number of physical read requests that required I/O to get data pages into the temporary tablespace

Synchronous Reads Synchronous Writes

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

Temporary Logical Number of logical read requests that required I/O to get index pages into the temporary tablespace Reads Temporary Physical Reads 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. Number of physical read requests that required I/O to get index pages into the temporary tablespace

30

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 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 Number of times that the catalog cache was referenced to obtain table descriptor information Number of times that the system tried to insert table descriptor information into the catalog cache Number of times that an insert into the catalog cache failed due to the catalog cache being full Largest size reached by package cache Description

Inserts

Overflows High-Water Mark Package Cache

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

September 2008

31

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Inserts Number of times an application looked for a section in the package cache Total number of times that an access plan was not available for use and had to be loaded into the package cache Number of times that the package cache overflowed the bounds of its allocated memory Largest size reached by the package cache

Overflows High-Water Mark

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 I/O Number of I/O Servers

Description

Number of I/O servers that read data asynchronously from the hard disk into the buffer pool Number of I/O cleaners that write data asynchronously from the buffer pool to the hard disk

Number of I/O Cleaners

Average Time Asynchronous Physical Reads Asynchronous Physical Writes Average time in milliseconds required by the I/O servers to read a page from disk and write it to the buffer pool 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

32

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Data Asynchronous Physical Reads Asynchronous Physical Writes Asynchronous Read Requests Index Asynchronous Physical Reads Asynchronous Physical Writes Asynchronous Read Requests Number of index pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch) Number of index pages that were written asynchronously from buffer pool to disk (I/O cleaners) Number of asynchronous index read requests Number of data pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch) Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners) Number of asynchronous data 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 Average Time Direct Reads Direct Writes I/O Direct Reads

Description

Average time in milliseconds required to read directly from disk Average time in milliseconds required to write directly to disk

Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup) Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load)

Direct Writes

September 2008

33

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Average I/O per Request Direct Reads Direct Writes Average number of requests to read directly from disk Average number of requests to write directly to disk

2.2.5 Database: RealTime 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 Size of Statistics Cache Number of Asynchronously Collected Statistics Description Size of statistics cache in bytes 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 Number of Synchronously Collected Statistics Time Spent on Synchronous Statistics Collection Activities Total time spent on creating statistics by system without table or index scan during query compilation in milliseconds Total number of synchronous statistics collection activities during query compilation Total time spent on asynchronous statistics collection activities in milliseconds

34

September 2008

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 Lock List 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. Current size of the lock list Description

Size

In Use Lock Waits Total Time Waited Average Time Waited Escalations

Total number of times that applications or connections waited for locks Total amount of elapsed time in milliseconds that applications waited for a lock to be granted Average time in milliseconds waited for a lock

Number of times that locks have been escalated from several row locks to a table lock 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.

Exclusive Lock Escalations

Locks Locks Currently Total number of locks currently held by the applications Held Deadlocks Number of deadlocks that have occurred

September 2008

35

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Detected

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 The Database Snapshot appears. 2. Choose Logging. Field 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. Description Performance Database .

Total Log Available to Database Amount of primary log space in bytes in the database that is not being used by uncommitted transactions

36

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 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 ID (that corresponds to the agent_id value from the Application with Oldest application snapshot) of the application that has the oldest Transaction 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 Written Log Buffer Consumption LSN Gap Percentage of log space held by dirty pages in relation to log space specified by parameter SOFTMAX Percentage of log space held that will have to be redone for crash recovery pages in relation to log space specified by parameter SOFTMAX Number of log pages read from disk Number of log pages written to disk

Restart Range

Log Buffer Quality Log Buffer Hit Ratio Ratio of log data read from the buffer in relation to log data read from disk

September 2008

37

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

Log Buffer I/O Average Write Time/Page Average Write Time/IO Average Read Time/Page Average Read Time/IO Average time per page in microseconds required to write log data to disk

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

Average time per page in microseconds required to read log data from disk

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 Rows Read Selected Number of data records that were read Number of data records that were selected Ratio of rows selected compared to the number of rows read Index Quality This ration indicates the quality of index accesses. Deleted Inserted Selected Updated Number of data records that were deleted Number of data records that were inserted Number of data records that were selected Number of data records that were updated Description

38

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Statements Executed SELECT SQL UPDATE/INSERT/DELETE

Description

Number of SELECT statements that were executed Number of UPDATE, INSERT, and DELETE statements that were executed Number of Data Definition Language (DDL) statements that were executed, for example, CREATE TABLE, CREATE VIEW, ALTER TABLE, and DROP INDEX Sum of the host execution times in seconds for all the statements that were executed Remaining part of the above elapsed time in microseconds

DDL

Elapsed Time (sec) Elapsed Time (microsec) 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. Number of dynamic SQL statements attempted Number of static SQL statements attempted Number of attempted SQL statements that failed

Dynamic SQL Static SQL Failed SQL Hash Joins Total Total Hash Loops

Total number of hash joins executed Total number of times that a single partition of a hash join was larger that the available sort heap space Number of times that hash join data exceeded the available sort heap space Number of times that hash join data exceeded the available sort heap space by less than 10 %

Overflows

Small Overflows

September 2008

39

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Total number of hash joins that were throttled back by the sort memory throttling algorithm 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 Post Threshold 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 Sort Heap Total Size Amount of memory in KB available for each sort as defined in the database configuration parameter SORTHEAP (in pages) Total number of allocated space of sort heap space for all sorts at the level chosen and at the time the snapshot was taken Description

Allocated Sort Time Total Average Sorts

Total time in milliseconds required for all sort processes Average sort time in milliseconds

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

40

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Sorts

Description 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 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 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 Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk Description

Physical Reads Write Accesses Temporary Data Logical Reads Physical Reads

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

September 2008

41

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Asynchronous I/O Physical Reads 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

Physical Writes

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 multi-partition database), the following information is displayed: Column User Partition SAP Component Data Logical Reads Data Logical Reads (%) Index Logical Reads Index Logical Reads (%) Description Name of connect user to identify the component Number of the partition (only displayed in a multi-partition database) Indicates if the connect user is related to a SAP component or another user that is just connected to the database Number of read accesses to data in the buffer pool Indicates the percentage of logical data read accesses for the component (and partition if you are using a multi-partition database) Number of read accesses to index data in the buffer pool Indicates the percentage of index logical data read accesses for the component (and partition if you are using a multi-partition database)

42

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description 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 component (and partition if you are using a multi-partition database) Number of read accesses to index data on disk (I/O)

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

Index Physical Reads (%)

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

September 2008

43

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 [page 44] Asynchronous I/O [page 47] Direct I/O [page 48] XML Storage [page 49]

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. 3. Choose Buffer Pool.

44

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you have selected more than one buffer pool, you can use the page buttons on the screen to navigate between them. Field 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 Pages Left to Remove Tablespace Use Count Buffer Quality Indicates percentage at which the data is read from the buffer pool, rather than directly from the hard disk This is calculated using the following formula: (logical reads - physical reads) / (logical reads) * 100 Indicates percentage at which only data (without index data) is read from the buffer pool, rather than directly from the hard disk Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk Size of the buffer pool in pages after a database restart Number of pages that are still to be removed Description

Number of tablespaces that belong to this buffer pool

Overall Buffer Quality

Data Hit Ratio

Index Hit Ratio Average Time Physical Reads

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

Physical Writes

September 2008

45

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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). Number of read accesses to data on disk (by agents)

Synchronous Reads Synchronous Writes

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

Temporary Logical Number of logical read requests that required I/O to get data pages into the temporary tablespace Reads Temporary Physical Reads 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). Number of read accesses to index data on disk (by agents) Number of physical read requests that required I/O to get data pages into the temporary tablespace

Synchronous Reads

46

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Synchronous Writes Temporary Logical Reads Temporary Physical Reads

Number of write accesses to index data on disk (by agents) Number of logical read requests that required I/O to get index pages into the temporary tablespace Number of physical read requests that required I/O to get index pages into the temporary tablespace

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 Average Time Asynchronous Physical Reads Asynchronous Physical Writes Data Asynchronous Physical Reads Asynchronous Physical Writes Asynchronous Read Requests

Description

Average time in milliseconds required by the I/O servers to read a page from disk and write it to the buffer pool 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

Number of data pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch) Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners) Number of asynchronous data read requests

September 2008

47

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Index Asynchronous Physical Reads Asynchronous Physical Writes Asynchronous Read Requests Number of index pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch) Number of index pages that were written asynchronously from buffer pool to disk (I/O cleaners) 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.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 Average Time Direct Reads Direct Writes I/O Direct Reads Direct Writes Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup) Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load) Average time in milliseconds required to read directly from disk Average time in milliseconds required to write directly to disk Description

Average I/O per Request Direct Reads Direct Writes Average number of requests to read directly from disk Average number of requests to write directly to disk

48

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 Pool Data Indicates the number of data pages for XML storage objects (XDAs) that Logical Reads have been requested from the buffer pool (logical reads) for regular and large tablespaces Physical Reads 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. Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces 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 Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk Description

Physical Reads Asynchronous I/O Physical Reads

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.

September 2008

49

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

Physical Writes

Read Requests

Indicates the number of asynchronous read requests for XML storage object (XDA) data

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.

50

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 [page 51] Asynchronous I/O [page 53] Direct I/O [page 54] XML Storage [page 55]

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. 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 Tablespace Name 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 This is calculated using the following formula: (logical reads - physical reads) / (logical reads) * 100 Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk Name of the tablespace Description

Overall Buffer Quality

Data Hit Ratio

September 2008

51

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Index Hit Ratio

Description Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk Number of times an agent did not have a preselected victim buffer available

No Victim Buffer Average Time Physical Reads

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

Physical Writes 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). Number of read accesses to data on disk (by agents)

Synchronous Reads Synchronous Writes Temporary Logical Reads Temporary Physical Reads Index Logical Reads

Number of write accesses to data on disk (by agents) Number of logical read requests that required I/O to get data pages into the temporary tablespace Number of physical read requests that required I/O to get data pages into the temporary tablespace

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.

52

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description 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). Number of read accesses to index data on disk (by agents)

Synchronous Reads Synchronous Writes Temporary Logical Reads Temporary Physical Reads

Number of write accesses to index data on disk (by agents) Number of logical read requests that required I/O to get index pages into the temporary tablespace 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. 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 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 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 Description

Asynchronous Physical Writes

September 2008

53

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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) Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners) Number of asynchronous data read requests

Asynchronous Physical Writes

Asynchronous 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) Number of index pages that were written asynchronously buffer pool to disk (I/O cleaners) Number of asynchronous index read requests

Asynchronous Physical Writes Asynchronous 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. If you have selected more than one tablespace, you can use the page buttons on the screen to navigate between them. Field Average Time Direct Reads Direct Writes I/O Direct Reads Direct Writes Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup) Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load) Average time in milliseconds required to read directly from disk Average time in milliseconds required to write directly to disk Description

54

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Average I/O per Request Direct Reads Direct Writes Average number of requests to read directly from disk 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 Pool Data 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 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 Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk Description

Logical Reads

Physical Reads

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. Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces

Physical Reads

Asynchronous I/O

September 2008

55

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

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

Physical Reads

Physical Writes

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 Table Schema Table Name Partition Table File ID Table Type Rows Written Rows Read Name of the schema Description

Name of the table Number of the partition (only displayed in a multi-partition database) File ID (FID) of the table Type of table for which information is displayed, for example, user, system or temp Number of rows changed (inserted, deleted or updated) in the table

Number of rows read from the table

56

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description 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 108]. End of the note.

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

September 2008

57

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Cancelling an Activity If you discover activities in the application snapshot 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 this 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 this activity by selecting it and choosing the Cancel pushbutton. If the activity is successfully cancelled, the SQL-error SQL4725N with status SQLSTATE 57014 is returned to the cancelled 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 more detailed information by selecting one or more applications and choosing Details. A detail Application Snapshot screen appears with information on: Application [page 59] Agents [page 63] 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. End of the note. Assigned Agents [page 63]

58

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note This tab page is only available if you are using the Web browser-based user interface. End of the note. Agents Memory [page 66] Note This tab page is only available if you are using the Web browser-based user interface. End of the note. Buffer Pool [page 67] Direct I/O [page 69] XML Storage [page 70] Locks and Deadlocks [page 71] Calls [page 73] Sorts [page 74] Cache [page 75] Unit of Work [page 76] Statement [page 76] Statement Text [page 78] SQL Workspace [page 80]

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.

September 2008

59

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you have selected more than one application, you can use the page buttons on the screen to navigate between them. Field Application PID Process ID of the database process belonging to a 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. Start time when the application connected to the database Operating system on which the client application is running Host name of the application server where the application server is running Name of application running at the client as known to the database manager or DB2 connect Current status of the application. Possible values are: Database Connect Pending The application has initiated a database connection but the request has not yet completed. Database Connect Completed The application has initiated a database connection and the request has completed. Status 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. Description

Connect Start Platform Host Name

60

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Commit Active

Description

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

September 2008

61

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description

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 TABLESPACE request.

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

Agent PID Client Information Client user ID that is generated by the transaction manager and provided to the server, if the sqleseti API is used. For ABAP systems: Name of the SAP user Workstation Identifies the clients system or workstation (for example, CICS EITERMID), if the sqleseti API was used in this connection. Process ID of an SAP work process that made the connection to the database

User ID

62

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Application

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

Accounting

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. 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 Agents Coordinator Agent PID Currently Associated Associated with This Appl. Process ID (UNIX systems) or thread ID (OS/2 or Windows systems) of the coordinator agent for the application Number of agents currently associated with the application Description

Number of agents participating in this application (high-water mark)

September 2008

63

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 System CPU Time Idle Time Waited for Prefetch Total user CPU time in seconds consumed by agent(s) Total system CPU time in seconds consumed by agent(s) Total idle time in seconds Total time in milliseconds waited for prefetch This table displays information with only one entry per memory pool allocated to this application. The table contains the following columns: Partition Partition number PID Process ID (UNIX) or thread ID (Windows) of the agent Memory Pools Allocated to Agent 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

64

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Agents Coordinator Agent Process ID (UNIX systems) or thread ID (Windows) of the coordinator agent for the application PID Currently Associated Associated with This Appl. Number of agents currently associated with the application Description

Number of agents participating in this application (high-water mark) Number of agents removed from this application and subsequently used by another application This only happens if the agent was not busy.

Stolen from Application

Times Spent by Agent(s) User CPU Time System CPU Time Idle Time Waited for Prefetch Assigned Agents Total user CPU time in seconds consumed by agent(s) Total system CPU time in seconds consumed by agent(s) Total idle time in seconds 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:

September 2008

65

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Partition Partition number Agent Type Type of the agent Nesting Level

Description

Nesting level of the agent Entity Entity of the agent

State 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

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.

66

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Partition number Process ID (UNIX) of the agent Note On Windows, this is called thread ID. End of the note. Pool ID Current Size (KB) High-Water Mark (KB) Configured Size (KB) Type of memory pool Current size of the memory pool Largest size of the memory pool since its creation Configured size of the memory pool Description

PID

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. A detail Application Snapshot screen appears. 3. Choose Buffer Pool.

September 2008

67

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you have selected more than one application, you can use the page buttons on the screen to navigate between them. Field Buffer Quality Indicates percentage at which the data is read from the buffer pool, rather than directly from the hard disk This is calculated using the following formula: (logical reads - physical reads) / (logical reads) * 100 Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk Description

Overall Buffer Quality

Data Hit Ratio

Index Hit Ratio Average Time Physical Reads

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

Physical Writes 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). Number of logical read requests that required I/O to get data pages into the temporary tablespace Number of physical read requests that required I/O to get data pages into the temporary tablespace

Temporary Logical Reads Temporary Physical Reads

68

September 2008

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). Number of logical read requests that required I/O to get index pages into the temporary tablespace Number of physical read requests that required I/O to get index pages into the temporary tablespace

Temporary Logical Reads Temporary Physical Reads

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. 3. 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 Average Time Direct Reads Direct Writes I/O Direct Reads Direct Writes Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup) Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load) Average time in milliseconds required to read directly from disk Average time in milliseconds required to write directly to disk Description

September 2008

69

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Average I/O per Request Direct Reads Direct Writes Average number of requests to read directly from disk 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 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 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 Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk Description

Physical Reads Write Accesses Temporary Data Logical Reads Physical Reads

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

70

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Asynchronous I/O Physical Reads 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

Physical Writes

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 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 Total amount of elapsed time in milliseconds that this application has waited for a lock to be granted Description

Time Waited

Average Time Average time in milliseconds waited for a lock Waited

September 2008

71

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Escalations Number of times that locks have been escalated from several row locks to a table lock 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 Lock Escalations 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 Total number of locks currently held by the application Held Number of deadlocks that have occurred. Deadlock situations are recognized and resolved automatically by the database 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 Deadlock Event Monitor Statement History List Size 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. Value of the database configuration parameterLOCKTIMEOUT

Deadlocks Detected

72

September 2008

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 Rows Deleted Inserted Selected Updated Statements Executed SELECT SQL UPDATE/INSERT/DELETE Number of SELECT statements that were executed Number of UPDATE, INSERT, and DELETE statements that were executed Number of Data Definition Language (DDL) statements that were executed, for example, CREATE TABLE, CREATE VIEW, ALTER TABLE, and DROP INDEX. Number of data records that were deleted Number of data records that were inserted Number of data records that were selected Number of data records that were updated Description

DDL

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. Number of dynamic SQL statements attempted Number of static SQL statements attempted

Dynamic SQL Static SQL

September 2008

73

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Failed SQL Hash Joins Total Total Hash Loops

Description Number of attempted SQL statements that failed

Total number of hash joins executed Total number of times that a single partition of a hash join was larger than the available sort heap space Number of times that hash join data exceeded the available sort heap space Number of times that hash join data exceeded the available sort heap space by less than 10 %

Overflows

Small Overflows

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. 3. Choose Sorts. If you have selected more than one application, you can use the page buttons on the screen to navigate between them. Field Sort Time Total Average Sorts Total Sorts Sort Overflows Total number of sorts that have been executed If the storage area allocated for sorting is not large enough, a sort overflow occurs. The hard disk is then used temporarily. Total time in milliseconds required for all sort processes Average sort time in milliseconds Description

74

September 2008

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 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 Number of times that the system tried to insert table descriptor information into the catalog cache Number of times that an insert into the catalog cache failed due to the catalog cache being full Number of times that an insert into the catalog cache failed due to the database heap being full Description

Inserts

Overflows

Heap 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 Inserts Number of times an application looked for a section in the package cache Total number of times that a request section was not available for use and had to be loaded into the package cache

September 2008

75

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. 3. 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 Unit of Work Start Time Stop Time Time that unit of work first required database resources Time that the most recent unit of work completed, which occurs when the database changes are committed or rolled back Duration of unit of work in seconds Duration of unit of work in microseconds Log space used in bytes in most recent unit of work Completion status of last transaction Description

Elapsed Time (s) Elapsed Time (s) Log Space Used Completion Status 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.

76

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

If you have selected more than one application, you can use the page buttons on the screen to navigate between them. Field Statement Start Time Stop Time Elapsed Time(s) Elapsed Time (sec) Rows Rows Read Rows Written 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 time for all sort processes Total number of sorts that have been executed Number of rows read from the table Number of rows changed (inserted, deleted or updated) in the table Date and time when unit of work starts, the statement starts or a deadlock is detected Date and time when the statement stopped executing Duration of unit of work in seconds Duration of unit of work in microseconds Description

Total Sort Time Number of Statement Sorts Data Logical Reads Physical Reads Temporary Logical Reads

Number of read accesses to data in the buffer pool Number of read accesses to data on disk Number of logical read requests that required I/O to get data pages into the temporary tablespace Number of physical read requests that required I/O to get data pages into the temporary tablespace

Temporary Physical Reads

Index Logical Reads Physical Reads Temporary Logical Reads Number of read accesses to data in the buffer pool Number of read accesses to data on disk Number of logical read requests that required I/O to get index pages into the temporary tablespace Number of physical read requests that required I/O to get index pages into the temporary tablespace

Temporary Physical Reads

September 2008

77

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

Operation currently being processed or most recently processed (if none is currently running) Possible operations are: Operation SELECT PREPARE EXECUTE EXECUTE IMMEDIATE OPEN FETCH CLOSE DESCRIBE STATIC COMMIT

78

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field STATIC ROLLBACK FREE LOCATOR PREP_COMMIT CALL PREP_OPEN PREP_EXEC COMPILE

Description

Blocking Cursor

Indicates if the statement that is executed is using a blocking cursor (YES) or not (NO) 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 and ABAP systems that have an additional RFC destination assigned. End of the note. More Information The EXPLAIN Function [page 202]

September 2008

79

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 Private Workspace Lookups Inserts Overflows Number of times an application looked for an SQL section in the agent's private workspace Inserts of SQL sections by an application into the private workspace Number of times that the private workspace overflowed the bounds of its allocated memory Description

High-Water Mark Largest size reached by the private workspace Shared Workspace Lookups Inserts Overflows Number of times an application looked for an SQL section in the agent's shared workspace Inserts of SQL sections by an application into the shared workspace Number of times that the shared workspace overflowed the bounds of its allocated memory

High-Water Mark Largest size reached by the shared workspace

80

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 Executions Total Execution Time Avg. Execution Time Rows Read Rows Written Description Number of times a statement has been executed Total execution time in milliseconds for a statement

Average execution time in milliseconds for a statement Number of rows read for a statement Number of rows written by a statement

SQL Text (Case- Search using either the wild card "*" or using a text string, for example, INSERT, to limit the number of statements displayed Sensitive) 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) 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.

Rows Read / Rows Processed

September 2008

81

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Total Cache Sum Execution Time Rows Read Rows Written 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 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 You can use this value together with Executions to identify the statements that would benefit from further analysis. Total Execution Time (milliseconds) divided by Total Cache Sum Execution Time (milliseconds) Total execution time in milliseconds for an SQL statement Total number of rows read Total number of rows written Description

Executions

Total Execution Time Total Execution Time ( %) Average Execution Time (ms)

Total Execution Time (in milliseconds) divided by Executions

Buffer Quality Buffer quality for this statement in percent (%)

82

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. Huge 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. 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 / Execution Total User CPU Time (ms) Average number of pages read from the buffer pool per execution of the statement. Total user CPU time in milliseconds for a statement 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 This value together with total execution time and total user CPU 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 in order to obtain the result set. Rows Read divided by Total Cache Sum Rows Read

Total System CPU Time (ms)

Rows Read (%)

September 2008

83

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Rows Written Rows Written (%)

Number of rows that were changed (inserted, deleted or modified) in a table High values might indicate that you should update statistics using RUNSTATS. Rows Written divided by Total Cache Sum Rows Written 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. Number of sort overflows Total number of sorts

Sort Overflows Total Sorts 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 system and ABAP systems that have an additional RFC destination has been 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 202].

84

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 217].

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>

September 2008

85

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 <Agent ID> <Application Name> <Client Process ID> <Host> Description Agent handle of the application waiting for the lock to be released Name of the application waiting for the lock to be released Process ID of the application requesting the lock 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 Current Lock Mode Lock Object Type Table IS: intention share lock IX: intention exclusive lock 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

Lock mode held Type of object to be locked Table on which/on whose record the lock is held

86

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

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 Table Schema Table Name Partition Description Table schema of the table that is currently being reorganized Name of the table that is currently being reorganized Number of the partition (only displayed in a multi-partition database) Status of the inplace table reorganization Possible values are: REORG Status Progress % Start Date Start Time Running Paused Suspended Completed

Progress of the reorganization Start date of the inplace table reorganization Start time of the inplace table reorganization

September 2008

87

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Access mode for other users while the table reorganization is running The following access modes are possible: Access Mode Tablespace 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. 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 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 additonally 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. Function READ WRITE NO ACCESS

Name of the tablespace where the reorganization is performed

88

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

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 Partition Date Description Monitored partition (only displayed if you are using a multi-partition database) Day when monitoring was performed

Average physical read time Avg. Phys. Read If you have chosen Total Day, this is the average of all measured average Time (ms) read times. If you have chosen Peak, this is the worst measured read time. Average physical write time Avg. Phys. Write If you have chosen Total Day, this is the average of all measured average Time (ms) write times. If you have chosen Peak, this is the worst measured write time.

September 2008

89

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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). Number of read accesses to index data in the buffer pool Number of read accesses to index data on disk (I/O)

Index Logical Reads

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

Index 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). Total number of COMMIT statements that have been attempted Total number of ROLLBACK statements that have been attempted

COMMIT Statements

ROLLBACK Statements

Automatic ROLLBACKs caused by error situations or deadlocks are not included. Total number of times that applications or connections waited for locks Total elapsed time in milliseconds waited for a lock Total number of deadlocks that have occurred Number of times that locks have been escalated from several row locks to a table lock 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

Lock Waits Lock Wait Time (ms) Deadlocks Lock Escalations

Exclusive Lock Escalations

90

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

91

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

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

Number of internal page reorganizations during INSERT operations

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

2.13 Performance: Performance Warehouse


Use 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 Business Intelligence (BI) system. This SAP BI system is used by the Solution Manager Diagnostics (SMD) back-end of an SAP Solution Manager system. SMD already uses this SAP BI to store workload data of SAP applications. To configure the extraction of data into the SMD BI, you use the SMD Setup Wizard.

92

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Based on this architecture, the DBA Cockpit uses SAP BI 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. 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 93] Performance Warehouse: Configuration [page 94]

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 drop-down 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 drop-down 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.

September 2008

93

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

94

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. Depending on your database platform, the displayed selection of values can vary. The following parameters are displayed for all database platforms: Parameter BI Server Managing DBA Cockpit Description BI server where the database performance data is located 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. The performance data time-stamps are converted to one global time zone for all reports in SMD BI.

Reporting Time Zone

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

September 2008

95

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Web Report (Day) Web Report (Month) Data Providers (Time)

Technical name of the BI BEx Web templates for granularity Day Technical name of the BI BEx Web templates for granularity Month 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. If selected, the report is available for performance analysis. If selected, the report is executed as soon as the tab page is selected. Name of database platform Minimum database release for this report Maximum database release for this report

Active Default Database Release (min) Release (max)

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 Category Description Description Name of the category Detailed description for the category

96

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

3 Space
The following sections provide information on space: Space: Automatic Storage [page 97] Space: Tablespaces [page 98] Space: Containers [page 106] Space: Tables and Indexes [page 106] Space: Single Table Analysis [page 108] Space: Virtual Tables [page 123] Space: History - Overview [page 124] Space: History - Database and Tablespaces [page 126] Space: History - Tables and Indexes [page 128]

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 Partition Storage Path FS ID FS Free Size (GB) FS Total Size (GB) Description Number of database partition Full path name ID of the related file system Free size in GB that is available in the file system Total size in GB that is available in the file system

September 2008

97

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.

98

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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: Column Tablespace Name Partition Contents TS State KB Total Page Size No. Containers KB Free High-Water Mark Percent Used Pending Free Pages Name of the tablespace Number of the database partition (only displayed in a multi-partition database) Contents of tablespace, for example, any data or temporary data Status of tablespace, for example, normal or load pending Total space in KB used by the tablespace Size of a page in bytes Number of containers Total amount of free space Indicates the maximum value of used pages reached Used space in relation to available space Number of free pages that are pending Description

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 Tablespace Name Partition TS Type Contents TS State Name of the tablespace Number of the partition (only displayed in a multi-partition database) Type of tablespace, for example, DMS or SMS Contents of tablespace, for example, any data or temporary data Status of tablespace, for example, normal or load pending Description

September 2008

99

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column KB Total Page Size No. Containers KB Free High-Water Mark Percent Used AUTORESIZE

Description Total space in KB used by the tablespace Size of a page in bytes Number of containers Total amount of free space Indicates the maximum value of used pages reached Used space in relation to the available space 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 Tablespace Name Schema Name Type Name of the tablespace Name of the schema Name of the table or index Type of object, for example, index, primary index or table Description

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

100

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

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 Tablespace Maintenance Name Name of the tablespace Name of the partition group where the selected tablespaces is 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. Description

Database Partition Group

September 2008

101

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Technical Settings The following are fixed values that cannot be changed: Field 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

Contents

Size of I/O Units Page Size Extent Size Space Management by Database (DMS) The space of the tablespace containers is managed by the database. System (SMS) AutoStorage The space of the tablespace containers is managed by the file system. All the tablespace space is managed by the automatic storage management. Page size in KB Extent size in KB

You can enter values in the following fields: Field Size of I/O Units Prefetch Size Disk Performance Displays I/O controller overhead and disk seek and latency time in milliseconds 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. Number of pages to be prefetched Description

Overhead

102

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field AUTORESIZE enabled Buffer Pool

Description Tablespace containers are automatically extended by using the file systems where the containers are located.

Name

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 146].

For more information on 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. End of the note. 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 Settings Initial Size Size Current Size Last Resize Displays the current size 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. Initial space allocated when a tablespace is created Description

September 2008

103

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

You can enter values in the following fields: Settings Increase Size Size in KB or in percent by which the 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 o 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 To add containers, choose Add. 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.

104

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 4. Add containers. If you are using a multi-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 152]

September 2008

105

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Tablespace Name Partition Stripe Set Container Name Type KB Total Pages Total Accessible FS ID FS Free Size (KB) Name of the tablespace Number of the partition (only displayed in a multi-partition database) Number of the strip set the container belongs to Name of the container in which the tablespace is located Type of the container, for example, disk or file Total size of the container in KB Total amount of pages Indicates whether the container is accessible (YES) or not (NO) File system ID Free space in the file system in KB Description

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 101].

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 Filters Tablespace Name Indicates the location of the table Description

106

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Table Name Table Size Flagged Tables Name of the table Size of the table

Description

If this flag is not set, only tables are displayed that have a recommendation for table or index reorganization. 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. If this flag is set, only tables are displayed that have the status not available. If this flag is set, only tables are displayed that have the status REORG PENDING. If this flag is set, only tables are displayed that still have Type1 indexes. If this flag is set, only tables are displayed that have the status LOAD PENDING. If this flag is set, only tables are displayed that have been recommended for row compression.

Large RIDs

Not Available

REORG Pending

Index Type-1

Load Status

Row Compression Display Options Sort by Maximum Number of Rows Example

Sorts the tables by Size or Name Number of rows to be displayed

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 Schema Table Name Tablespace Name Description Schema of the table, usually the user who created the table Name of the table Tablespace to which the table currently belongs

September 2008

107

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column F1 F2 F3 Table Flagged Index Flagged Size (KB)

Description Overflows rows as a percentage Table size divided by allocated space as a percentage Full pages divided by allocated pages as a percentage Indicates that table reorganization is recommended Indicates that table reorganization is recommended because of REORGCHK recommendations for at least one of the table indexes Table size

REORG Check Date of the last REORG check, for example, the date when RUNSTATS ran Date using program dmdb6srp REORG Check Time of the last REORG check, for example, the time when RUNSTATS ran Time 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 108]. 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.

108

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed: Table and Index Details Field Name Schema Name of the table Schema of table, that is usually the user who created the table Description

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 REORG Check Statistics Last REORG Check Total Table Size Total Index Size Date and time of the last REORG check, for example, the date and time when RUNSTATS ran using program dmdb6srp Size of table in KB Size of all indexes of the table in KB Percentage of free space reserved in the tables allocated pages Free Space Reserved This free space is taken into account by LOAD and REORG. F1: Overflow Rows F2: Table Size / Allocated Space Overflow rows as a percentage Table size divided by allocated space as a percentage Description

September 2008

109

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field F3: Full Pages / Allocated Pages REORG Pending Last REORG of Table Runtime of Last REORG System Catalog Last RUNSTATS Tablespace Cardinality

Description Full pages divided by allocated pages as a percentage Indicates whether a REORG is pending for the table Date and time when the last REORG ran Runtime of the last REORG

Date and time when the last RUNSTATS ran Name of the tablespace to which the table belongs Number of data records in the table Number of rows that have been counted by a SELECT(*) statement

Counted Rows This information is only displayed if you choose Count. 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.

Deviation

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.

110

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 recreated during an upgrade or a table conversion are always marked as VOLATILE as long as there are not yet valid statistics available. End of the note. Value Compression Row Compression Distributed Statistics Indicates whether value compression is enabled for the table

Indicates whether the table is compressed

Indicates whether the table has a distributed statistics or not

Indexes Field Index Name Schema Tablespace Type REORG Check Statistics Last REORG Check Indexes Require Rebuild Cardinality Date and time of the last REORG check, for example, the date and time when RUNSTATS ran using program dmdb6srp Indicates whether an index requires rebuild or not Number of entries in the index Name of the index Schema of the index, that is usually the user who created the index Name of the tablespace to which the index belongs Index type Description

September 2008

111

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field

Description 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 F5: Index Size / Allocated Space F6: No. Entries / No. Poss. Entries F7: Ratio of Deleted Index Entries F8: Ratio of Deleted Index Leafs System Catalog Last RUNSTATS Number of Leaves Number of Levels Sequential Pages Date and time when the last RUNSTATS ran Number of index leaves Number of index levels Number of index leaves physically located on the hard disk sorted by index without large intervals between them 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 First 2 Key Cardinality First 3 Key Cardinality First 4 Key Cardinality Full Key Cardinality Number of different values in the first column of the index Number of different values in the first two columns of the index Number of different values in the first three columns of the index Number of different values in the first four columns of the index Number of different values in all columns of the index Cluster ratio as a percentage Index size divided by allocated space as a percentage Number of entries divided by the number of possible entries as a percentage Number of deleted entries in relation to total entries in index Number of deleted tree leafs in relation to total tree leafs of index tree

Density

112

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 DB Column No. Description Number of the column in the database Name of the column in the database Data type of the column in the database Length of the column in the database

DB Column Name

DB Type

DB Length 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 SAP Column Name

Description Name of the column defined in the ABAP Dictionary Column is part of primary key defined in the ABAP Dictionary Data type of the column defined in the ABAP Dictionary Length of the column defined in the ABAP Dictionary

SAP Key

SAP Type

SAP Length

September 2008

113

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

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

If automatic RUNSTATS is not enabled, the following options are available instead: Field Scheduling Automatically Statistics and REORGCHK calculations are gathered by CCMS jobs that are scheduled in the DBA Planning Calendar [page 169]. CCMS jobs do not process these tables automatically, that is RUNSTATS and REORGCHK must be explicitly scheduled by the user. Due to the monitored number of update activities, the statistics might be out-of-date. As a consequence, a RUNSTATS is recommended. Deviation of the current size (cardinality) in the table statistics from the size that was estimated based on the monitored number of update activities The table is monitored by the application monitor ST07. Description

On User Request Statistics is out-ofdate

Deviation

Collect Data for Application Monitor 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. The table is marked as VOLATILE and has no statistics.

No Statistics and Volatile

114

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. The following table lists the table analysis methods that you can specify if you chose Customized Settings for the collection of statistics: Field Basic Distributed Statistics Basic statistics for the table 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 Caution This field is only active if you are using DB2 UDB for UNIX and Windows Version 8, FixPak 2 or higher. End of the caution. The data to be sampled is selected page by page. Caution This field is only active if you are using DB2 UDB for UNIX and Windows Version 8, FixPak 2 or higher. End of the caution. 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. Description

Sampling of [ ] %of entries

System (Page, Sampling)

September 2008

115

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field End of the caution.

Description

Analyze Key Columns Table statistics are gathered only for key columns of the table. only Index Analysis Method Basic Detailed Statistics Detailed Sampled Statistics Basic statistics for the index Detailed statistics for the index Detailed statistics for the index using sampling 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: Order DB Column Number DB Column Name DB Type DB Length A = ascending order D = descending order

Number of the column in the database Name of the column in the database Data type of the column in the database Length of the column in the database

116

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 SAP Column Name SAP Type SAP Length 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. Description Name of the column defined in the ABAP Dictionary Data type of the column defined in the ABAP Dictionary Length of the column defined in the ABAP Dictionary

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 Physical Size Amount of disk space in KB that is physically allocated for the table Data Objects For multi dimensional 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. Amount of disk space in KB that is physically allocated for long field data in a table Amount of disk space in KB that is physically allocated for long field data in a table Amount of disk space in KB that is physically allocated for XML data in a table Amount of disk space in KB that is physically allocated for the indexes Description

Long Objects

LOB Objects

XML Objects Index Objects

September 2008

117

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Logical Size

Description

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. Amount of disk space in KB that is logically allocated for long field data in a table Amount of disk space in KB that is logically allocated for long field data in a table Amount of disk space in KB that is logically allocated for XML data in a table Amount of disk space in KB that is logically allocated for the indexes

Long Objects

LOB Objects

XML Objects Index Objects 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 will be 0. Available YES The table is available. Note Rollforward through an unrecoverable load makes a table unavailable. End of the note.

118

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. EXECUTING NULL This value is only possible if no inplace reorganization has been performed on the table. PAUSED

Inplace REORG Status

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 will not allow a load restart. Otherwise, the value NO is returned. 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.

September 2008

119

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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. Blocks Pending Cleanup Indicates the number of blocks pending cleanup for MDC tables. For non-MDC tables this value will always be 0. The following values are possible: System fabricated Statistics are gathered by the system without a table or an index scan These statistics are stored in memory and are different from what is stored in the system catalogs. This is a temporary state and eventually full statistics will be gathered by DB2 and stored in the system catalog. Type of Statistics 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 System asynchronously gathered Statistics are gathered asynchronously by the system NO

120

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Here, 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 Compression Detail Current Dictionary Size Average Length of Compressed Rows Average Compression Ratio by Row Average Length of Compressed and Uncompressed Rows Percentage of Compressed Rows from Total Number of Rows Current size of compression dictionary in bytes Average length of compressed records in bytes Average compression ratio by row Average length of all rows (compressed and uncompressed) in bytes Percentage of compressed rows compared to total number of rows Percentage of pages saved by compression Approximate Percentage of Pages Saved (excl. LOBS) Note Only data pages are taken into account. End of the note. Description

September 2008

121

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Compression Check Results Estimated Dictionary Size Estimated size of compression dictionary in bytes if table will be compressed Estimated amount of pages in percent that will be saved after compression Estimated amount of bytes in percent that will be saved after compression Number of rows that were too small to be used for compression calculation Date and time of last compression check

Estimated Saved Pages

Estimated Saved Bytes

Rows too Small Last Check

Checking and Updating the Statistics You can check the quality of the statistical information in the system catalog by entering a 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 169]. 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.

122

September 2008

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 will be 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.

September 2008

123

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 the being dropped and recreated as virtual tables. If you choose Convert Empty Tables, a background job is scheduled that checks each table if it is: o o o o Empty Not volatile Does not have a partitioning key Not using MDC tables

Tables that meet these conditions are dropped and recreated 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. End of the caution.

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.

124

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The following information is displayed: Databases and Tablespaces Field Tablespaces Last Analysis Total Number Total Size Free Space Used Space Minimum Free Space in a Tablespace Maximum Used Space in a Tablespace Database Partitions Number of database partitions Total Number The value displayed is only higher than 1 if you are using a multi-partition database. Date and time of the last analysis Total number of tablespaces in the database Total size of all tablespaces in KB Free space in all tablespaces in KB Used space of all tablespaces as a percentage Free space of the tablespace with the lowest amount of free space in KB Used space of the tablespace with the highest fill level as a percentage Description

Tables and Indexes Field Last Analysis Total Number of Tables Total Size of Tables Description Date and time of the last analysis Total number of tables defined in the database 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

September 2008

125

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Oldest REORG Check Latest REORG Check

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

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 169]. 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 Tablespace Name Partition KB Total Description Name of the tablespace (only displayed if you have selected Tablespaces in the Object Selection field) Monitored partition - displayed only if you are using a multi-partition database Amount of space in KB allocated

126

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Changes (KB Total) KB Used Changes (KB Used) % Used KB Free Containers Changes Containers Average change of KB Total

Description

The average value depends on your selection in the Statistics field. Used space in KB of the allocated space Average change of used space Percentage used of allocated space Free space in KB of allocated space Number of containers belonging to the tablespace Average change of number of containers

Tables and Indexes Tables and Indexes Column Tablespace Name Tables Description Name of the tablespace (only displayed if you have selected Tablespaces in the Object Selection field) Number of tables

Changes Tables Average change of number of tables Table (KB) Changes Table (KB) Indexes Space used by tables Average change of space used by tables Number of indexes

Changes Indexes Average change of number of indexes Index (KB) Changes Index (KB) Space used by indexes 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...

September 2008

127

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 Filters Tablespace Name Table or Index Name Table or Index Size Display Options Sort by Maximum Number of Rows 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 Object Name Object Type Tablespace Name Size (KB) Name of the table or index Table or index Tablespace to which the objects belong Size of the table or index Description Sorts the tables or indexes by Growth, Size or Name Number of rows to be displayed Name of the tablespace Name of the table or index Size of the table or index Description

128

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Changes Size (KB) REORG Check Date REORG Check Time

Description Average change of space used by table or indexes Date of the last REORG check, for example, the date when RUNSTATS ran using program dmdb6srp 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.

September 2008

129

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 [page 130] Backup and Recovery: Logging Parameters [page 130]

4.1 Backup and Recovery: Backup Overview


You can access the Overview screen by calling the DBA Cockpit and choosing Backup and Recovery Backup Overview in the navigation frame of the DBA Cockpit. The following information is displayed: Tab Description Contains information on database backups Database Backups 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)

Log Files

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. End of the caution.

130

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5 Configuration
The following sections provide information on configuration: Configuration: Overview [page 131] Configuration: Database Manager [page 135] Configuration: Database [page 137] Configuration: Registry Variables [page 140] Configuration: Parameter Changes [page 140] Configuration: Database Partition Groups [page 141] Configuration: Buffer Pools [page 146] Configuration: Special Tables Regarding RUNSTATS [page 149] Configuration: File Systems [page 151] Configuration: Data Classes [page 152] Configuration: Monitoring Settings [page 155] Configuration: Automatic Maintenance Settings [page 156]

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 Database Instance Name Partitionable Name of the database instance Indicates whether or not the current instance is a partitionable database server instance Number of database partitions If the database environment is not partitioned, the value is 1. Size of the current database instance in Bit (32 or 64) Description

Number of Partitions Address Space

September 2008

131

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Database Release Service Level

DB2-internal release number, as it is returned if you use the db2level command, for example, 03030106 Service level, as it is returned if you use the db2level command, for example, DB2 v8.1.1.80 Build level, as is returned if you use the db2level command, for example, n041021 Program temporary fix (PTF) identifier, as it is returned if you use the db2level command, for example, U498350 Fix Pack number, as it is returned if you use the db2level command, for example, 9

Build Level

PTF

Fix Pack Operating System Name Version Release Host Name Total CPUs Configured CPUs Total Memory

Name of the operating system Version number of the operating system Release number of the operating system Name of the system Total number of physical CPUs of the system Number of configured physical CPUs of the system Total amount of memory fn 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 HADR Information The current HADR connection status of the database The following values are possible: Connect Status CONGESTED CONNECTED DISCONNECTED Description

132

September 2008

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

Log Gap

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

If the database is in HADR primary or standby role, this element indicates the health of the HADR connection.

September 2008

133

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

Remote Instance

134

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Current HADR state of the database The following values are possible: HADR State Standby Log File DISCONNECTED LOCAL_CATCHUP PEER REM_CATCH_PEN REM_CATCHUP

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 Common Diagnostics Default Monitor Switches Security - Groups Security Authentication Memory Description Common information about the database manager, for example, release level and CPU speed Information about diagnostics Information about the default monitor switches of the database Information about user groups of the database manager Information about authentications of the database manager and on clients Information about the memory of the database manager

September 2008

135

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tree node Agents Information about agents

Description

Application Remote Information about the database application remote interface (DARI) Interface Sync Point Manager Transaction Manager Network Fast Communication Manager DB2 Discovery Information about the configuration of the synchronization manager and the transaction manager Information about the transaction manager Information about network characteristics such as communication protocols Information about the Fast Communication Manager (FCM), that is, the configured communication in a multi-partition database Information about the configuration of the discovery mode 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

Others

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 detailed 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 139].

136

September 2008

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 Common Automatic Maintenance Optimization I/O Self-Tuning Memory Manager Database Shared Memory Application Memory Logging Log File Management Backup & Recovery TSM Locks Space Applications DB2 Data Links Manager High Availability Description Common information about the database, for example, release level and country code Information about the automatic maintenance switches Information about optimization Information about I/O Information about the self-tuning memory manager

Information about the memory that is available for the database

Information about the memory that is available for the application Information about log files and logging parameters Information about log file management parameters

Information about recovery availability and backups Information about Tivoli Storage Management (TSM) Information about locks, for example, the percentage of lock lists per application Information about containers and tablespaces Information about applications that connect to the database Information about the DB2 Data Links Manager (DB2 Version 8 only) Information about the system configuration is only displayed if you are running a high availability system.

September 2008

137

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tree node

Description 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

Others

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 139]. 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 139]. For more detailed information on 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.

138

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

139

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 contains 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 Parameter Parameter Active History Description Displays the current values of the parameters Displays all recorded parameter changes made in the past Displays both database manager and database parameters Displays database parameters only Displays database manager parameters only

Parameter Type Parameter Type Parameter Type

All Database DB Manager

140

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Option Parameter Type Registry

Description Displays registry variables only

When you have made your selection, the following information is displayed: Column Parameter Type Parameter Name Partition Date Time Parameter Value Description Defines whether the parameter is a database manager parameter or a database parameter 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 (read-only). Monitored partition displayed only if you are using a multi-partition database Date of the change Time of the change 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. The following information is displayed: Column Description

Database Partition Name of the database partition group Group Partition Number of the partition Current status of the partition The following values are possible: Status Status information not available Displayed for database partition group IBMTEMPGROUP or if the status cannot be determined

September 2008

141

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column

Description Partition not in partitioning map; containers not yet created Partition has been created without containers and is not yet referenced in the partitioning map. 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 142].

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

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

142

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

Description

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.

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 Total space in KB If you create tablespaces, this information is not displayed. Size of the buffer pool in KB Buffer Pool Size (KB) 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 Description

Page Size

For detailed information on buffer pools, double-click the corresponding buffer pool.

September 2008

143

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Tablespaces This tab page contains a list of all tablespaces that have been defined for the selected database partition group. Field Tablespace Name Page Size Name of the tablespace Size of one tablespace page in bytes Description

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. o To delete partitions, select one or more lines in the table and choose Delete Partition.

5. To confirm your entries, choose Execute. 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.

144

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

145

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Buffer Pool Name Partition Name of the buffer pool 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 43]. Page Size (Byte) Size of one buffer pool page in bytes Description

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 146].

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

146

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure 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. 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 Displays the buffer pool size in pages or the value AUTOMATIC (Pages) Immediate Field Indicates that the buffer pool is created or changed immediately and not after the next system restart. 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 End of the note. Page Size Block Size Size of one page in the buffer pool Size of one block for blocked I/O in pages displayed only if you are using DB2 Version 8

Partition

September 2008

147

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 DB2. You are able to specify a starting value regardless if the pool 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 142]. Tablespaces This tab page contains a list of all tablespaces that use this buffer pool. Column Tablespace Name Page Size Name of the tablespace Size of one tablespace page in bytes Description

For detailed information on tablespaces, double-click the corresponding tablespace. For more information about tablespace maintenance, see Maintaining Tablespaces [page 101]. 2. To confirm your entries, choose Execute. 3. To apply changes, choose Technical Settings or Database Partition Groups. 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.

148

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 will be executed. This area is automatically filled and refreshed if any changes were applied correctly.

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

September 2008

149

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Table Schema Table Name Description Name of the schema to which the table belongs Name of the database table Indicates whether the table is flagged as VOLATILE in the system catalog or not 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 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. Active R No RUNSTATS is run by any CCMS program. The only exception is that you use program dmdb6srp and explicitly specify the table. A RUNSTATS may be run by CCMS programs. This information is only relevant if CCMS RUNSTATS is enabled. Profile RUNSTATS Date RUNSTATS Time Cardinality Indicates whether a RUNSTATS profile was set for the table Date of the last RUNSTATS in the system catalog table

VOLATILE

Time of the last RUNSTATS in the system catalog table Number of rows as calculated by the last RUNSTATS (1 indicates that there are no statistics available)

150

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 Both local and NFS file systems are displayed. Total size of the file system in KB Total amount used of the file system in KB

File System Name KB Total KB Used

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

September 2008

151

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Number of 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.

Inodes 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. The following information is displayed: Column Green: No action required Yellow: Indicates warnings Recommendation We strongly recommend that you take immediate action. State End of the recommendation. Red: 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? Description

152

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Data Class Data Tablespace Index Tablespace No. of Tables

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

Name of the data class known to the ABAB Dictionary Name of the tablespace where table data is stored

Name of the tablespace where table indexes are stored Number of tables within the related data tablespace

No. of Indexes Number of indexes within the related index tablespace Category Description Category of the data class 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 [page 153].

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

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

September 2008

153

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 get 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 will not be 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. 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.

154

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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]. Procedure 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. 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 will be 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.

September 2008

155

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

156

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. End of the note. 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 [page 157]. End of the note. 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 [page 157] Configuring Automatic Backup Settings [page 158] Configuring RUNSTATS Settings [page 161] Configuring Automatic REORG Settings [page 162]

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.

September 2008

157

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

158

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. Specify the following parameters: Parameter General Automatic backup is switched on / off Enables or disables the automatic backup function 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: o o Maximum time between backups: 1 day Maximum log space used between backups: 10 MB Description

Optimize for Database Recoverability

Indicates the balance between the number of backups and the time for recovery. Balance Between Recoverability and Performance The following limits apply: o o Maximum time between backups: 7 days Maximum log space used between backups: 25 MB

Optimize for Database Performance

Fewer backups are created. Therefore, more time to recover the database is required. The following limits apply: o o Maximum time between backups: 30 days Maximum log space used between backups: 50 MB

September 2008

159

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

When you choose this option, you are able to customize the following parameters: o Number of full backups is less than Minimum number of backups Customize o Time since last full backup exceeds <value> 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 If the time since the last backup exceeds the specified value, a backup is created. exceeds Log space used since last If the log space exceeds the specified value, a backup is created. full backup is more than 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 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 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.

TSM

160

September 2008

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 General Automatic RUNSTATS is switched on / off Maintenance Window Enables or disables the automatic RUNSTATS function 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. Description

September 2008

161

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: Tables Excluded from RUNSTATS Volatile Tables Volatile tables are always excluded from automatic RUNSTATS. When you expand this node, the volatile tables are displayed. 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 RUNSTATS Date RUNSTATS Time Cardinality Indicates whether a RUNSTATS profile was set for the table Date of the last RUNSTATS in the system catalog table Time of the last RUNSTATS in the system catalog table 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.

162

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. You can set the following parameters: Parameter General Automatic REORG is switched off Enables or disables automatic REORG function Specifies a maintenance window for index reorganization. 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 That is, all table filters in the policy are disabled and the parameters are changed according to the SAP recommendations. Note A full editor for these filter criteria is not provided. End of the note. Description

Index Reorganization Mode

SAP Default Criteria for Tables Excluded by Policy

September 2008

163

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

164

September 2008

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 Table Flagged Index Flagged Table Size (KB) REORG Date REORG Time Name of database schema to which the table belongs Indicates the table to be reorganized Indicates the indexes to be reorganized Size of table in KB Date when table was last reorganized Time when table was last reorganized

September 2008

165

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6 Jobs
The following sections provide information on: Central Calendar [page 166] The DBA Planning Calendar [page 169] The DBA Log [page 189] Back-End Configuration [page 190] The SQL Script Maintenance [page 191]

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.

166

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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:

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

1. 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. 2. You define the systems you want to monitor in the DBA Cockpit by setting the flag Collect Central Planning Calendar Data for each system. 3. You regularly check the results using the Central Calendar. 4. 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.

September 2008

167

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Procedure
...

1. Start the Central Calendar from the DBA Cockpit by choosing Jobs Central Calendar. 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:

3 4

FUD FIB

2 1

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 Light blue Dark blue Green Yellow Red Dark yellow Dark red Status Planned Running Finished successfully Finished with warning Finished with error No longer available 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. 3. 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. 4. To refresh the display for the system from which you called the Central Calendar, choose Refresh.

168

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

5. To refresh the display for all systems, choose Remote Refresh. You can remotely refresh the display as follows: Method Run in Dialog Start immediately Schedule at How the Refresh Runs Runs in dialog mode, which can take a long time, so not normally recommended Runs immediately in the background as a job 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. 6. If required, you can customize the calendar display as follows:
{

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.

Switch to day, week, or month view by choosing Administration View Day, Administration View Week, or Administration View Month. 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. Features Initial Screen The initial screen of the DBA Planning Calendar is divided into three frames that are described in the following.

September 2008

169

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. o External Actions These are plannable actions that have not been started via the DBA planning calendar but manually or by external job schedulers. o All Actions These are all plannable actions, regardless how they have been scheduled. o 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.

170

September 2008

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. Running statistics for tables Note These actions are only available if the automatic RUNSTATS by DB2 is disabled. The actions involved have an impact on the database performance. End of the note. Reorganization of tables and tablespaces Note 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 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 183]. Note This action is available only if the automatic REORG by DB2 is disabled. End of the note. REORGCHK for All Tables RUNSTATS and REORGCHK (DBSTATC) RUNSTATS and REORGCHK for All Tables Actions Involved

Full Database Backup into TSM Full Database Backup to Device Full Database Backup with Vendor Library Archive Log File to Tape

September 2008

171

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 173]. 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 Light blue Dark blue Green The action has not yet started. The action has not yet finished. 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 Dark red No more information is available. Scheduling failed, that is, there is no status available and the action is overdue. Meaning

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 drag & drop function. More Information Setting up the DBA Planning Calendar [page 173]

172

September 2008

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 190]. 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.

September 2008

173

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 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. Jobs DBA

174

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

More Information Scheduling an Action [page 175] Changing an Action [page 176] Deleting an Action [page 177] Executing an Action [page 178] Displaying the Status of a Days Actions [page 178] Displaying Scheduled Actions [page 179] Troubleshooting [page 180] Updating Statistics [page 180] Scheduling a REORGCHK for All Tables [page 181] Reorganizing Tables [page 183] Database Backup [page 184] Archiving Log Files To Tape [page 187] Scheduling Scripts [page 188]

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

September 2008

175

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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. Range of time where the action recurs, that is for a specific time interval or for a limited number of occurrences

Recurrence Range 5. Caution

6. The system warns you if there is a conflict with an existing action, but it does not prevent you from inserting the new action. 7. 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. 8. End of the caution. 9. 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.

176

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 179]. End of the note. 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 175]

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 179]. 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.

September 2008

177

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

6.2.1.4 Executing an Action


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

178

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

179

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

180

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 108] except Number of Parallel Jobs. 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 will significantly reduce the amount of time for the job execution. End of the caution.

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 128]. End of the note. Recommendation The job REORGCHK for All Tables must run once a week. End of the recommendation.

September 2008

181

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 By default, you should not activate this option on for the REORGCHK job Check 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 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

Minimum Table Size for Check

182

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 2. Specify the following parameters: Parameter Table Schema Table Description Name of the schema to which the table belongs 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. 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. o Keep Dictionary If you select this option, a compression dictionary is kept and not rebuilt. Note This option is valid only for compressed tables.

Offline

September 2008

183

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Parameter End of the note. Online All Indexes

Description

Schedules an online reorganization of the table Schedules a reorganization of all indexes only

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 with Vendor Library 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 Backup Mode Online Access to the database is not blocked. The users can continue to work normally during the backup. Description

184

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Note This option is no longer supported and is only 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. 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.

Offline

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

September 2008

185

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

186

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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://www.sdn.sap.com/irj/sdn/db6 SAP on DB2 for Linux, UNIX and Windows Knowledge Center Key Topics Administration

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.

September 2008

187

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 o 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://www.sdn.sap.com/irj/sdn/db6 SAP on DB2 for Linux, UNIX, and Windows Knowledge Center Key Topics Administration . End of the note.

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 [page 191]. End of the note.

188

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Start Date Start Time End Date End Time Runtime Action Return Code Start date of action Start time of action End date of action End time of action Runtime in HH:MM:SS Description of action Return code of action Description

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. If you only want to display certain log records, choose one of the following icons: Icon Total Errors Total number of all log records Displays jobs that finished with an error. These jobs should be executed again Meaning

Warnings Displays jobs that finished with a warning OK Displays log records of jobs that were completed without errors

September 2008

189

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Note Alternatively, choose Planning Calendar. End of the note. 2. In the Selected Scope group box, choose the scope of the configuration entry. 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. Goto Back-End Configuration from the menu in the DBA Jobs Back-End Configuration .

190

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

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.

September 2008

191

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

192

September 2008

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 [page 193] Alerts: Configuring Database System Monitoring [page 194] Alerts: Alert Monitor [page 196] Alerts: Alert Message Log [page 197] Alerts: Alert Configuration [page 199]

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 o Access behavior of database buffers Lock behavior of the application, monitoring of deadlock situations and lock escalations

Availability of backup and recovery mechanisms o o Last available backup Availability of the log files necessary to achieve the current state of the database from the last available backup.

September 2008

193

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 194] Alerts: Alert Message Log [page 197] Alerts: Alert Configuration [page 199]

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. o Background monitoring

Configuration of DB2-specific parameters

194

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 . 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 on specifying these additional parameters, see Alerts: Alert Configuration [page 199]. Method Execution Activate Background

September 2008

195

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. Note You are able to directly display the message log for a certain alert by double-clicking the corresponding item. End of the note. 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 Alerts Alert Monitor in the

196

September 2008

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 Information Warning Error 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. Green Yellow Red Color

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

September 2008

197

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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: o o o o o 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 Information Warning Error Green Yellow Red Color

If a check resulted in a warning or error, a short text is additionally displayed next to the parameter in the Open alerts view.

198

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 o Normal State Warning Limited operation, for example, with reduced performance o 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.

September 2008

199

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

200

September 2008

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 201] The EXPLAIN Function [page 202] Diagnostics: Missing Tables and Indexes [page 209] Diagnostics: Deadlock Monitor [page 211] Diagnostics: SQL Commands [page 217] Diagnostics: The Index Advisor [page 217] 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 226] 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 Date Time System Action Command Start date of the action Start time of the action Target system on which the action was performed Type of action (name of the action in the DBA Cockpit) Type of command (for example, ADD, DELETE or EDIT) Description

September 2008

201

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Field Object User

Description Name of the modified object (for example, database or tablespace name) 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 202] The EXPLAIN Function (SAP GUI-Based Version) [page 205]

8.2.1 The EXPLAIN Function (New Web BrowserBased Version)


You can use the Web browser-based EXPLAIN to review the access plan 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 database-specific area of the Web browser-based user interface, choose Performance Snapshots Applications . Doubleclick 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: Statement [page 76].

202

September 2008

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 SQL Cache . Select a statement from the list and choose the EXPLAIN pushbutton. For more information, see Performance: SQL Cache [page 81].

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 Original Statement Optimized Statement Access Plan Description Displays the original SQL statement

Displays the SQL statement that was rewritten by the DB2 optimizer Displays the access plan that was generated by the DB2 optimizer Displays the output of the EXPLAIN snapshot Note 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.

EXPLAIN Snapshot

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. You can: Display or hide quick 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

September 2008

203

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 o Operator <Name of operator> Displays details for the selected operator o Catalog Information (Optional) Displays details for the respective catalog object of the selected operator o 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. 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.

204

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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: Statement [page 76] 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 81] 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. 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 [O]/[I] (<Partition>) Description Shows whether the operator acts as an outer/inner input branch for a subsequent join operation 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, is displayed.

September 2008

205

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 206].

More Information: For additional information on the EXPLAIN function, see SAP Note 400938. For more general 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 Details Description 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 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.

206

September 2008

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.

September 2008

207

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.

208

September 2008

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

Source

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.

September 2008

209

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

The results of the last consistency check are displayed in a tree structure that is grouped into the following sections: Section Objects missing from the database Unknown objects in the ABAP Dictionary Inconsistent objects Description Objects that are defined in the ABAP Dictionary, but not found in the database Objects that are found in the database, but not defined in the ABAP Dictionary Results of the detailed comparison of the ABAP Dictionary and the database are displayed here 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

Other checks

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.

210

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. 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 [page 212]. You analyze deadlock monitor information [page 213]. 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 . Note If you want to move the deadlock monitor tables into a different tablespace, you must drop the deadlock monitor and recreate it. End of the note. Monitor Drop

September 2008

211

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Deadlock Monitor in the navigation frame of the DBA

Diagnostics

Deadlock Monitor

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. 5. On the second screen of the dialog box, choose the tablespace where the deadlock monitor tables should reside. The drop-down 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.

212

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

September 2008

213

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Locks Held Column Table Schema Description Name of the schema to which the table belongs

Table Name Name of the database table Mode of the lock held Lock Mode If the Lock Status is Waiting, this is the lock mode which the agent is intended to request. Type of object to be locked Status of lock request: Lock Status Lock Escalation Lock Count Granted Waiting

Lock Object Type

Indicates if a lock request was made as part of a lock escalation 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

214

September 2008

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. This element shows the isolation value in effect for the statement while it was being run. Optimization level The query degree specifies the intrapartition parallelism for the execution of SQL statements. Statement type: Statement Type Dynamic Static

Isolation Opt. Level Query Degree

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 Val. Index Val. Type Data Null Reopt Description Value index (parameter marker index) in the statement text Data type of the value Data Value is null. Value is used for REOPT.

September 2008

215

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 Last Use Time Agent ID Description Timestamp when the statement was last executed 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. This element shows the isolation value in effect for the statement while it was being run. Optimization level The query degree specifies the intrapartition parallelism for the execution of SQL statements. Statement type: Statement Type Dynamic Static

Isolation Opt. Level Query Degree

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 Val. Index Val. Type Data Null Reopt Description Value index (parameter marker index) in the statement text Data type of the value Data Value is null. Value is used for REOPT.

216

September 2008

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 an SQL commands that manipulate data, an error occurs End of the note.

8.6 Diagnostics: The 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. You access the index advisor by calling the DBA Cockpit and choosing Diagnostics Index Advisor in the navigation frame. Activities You use the index advisor to perform one of the following actions: To determine and recommend new virtual indexes that do not yet exist On the basis of a given SQL statement, the DB2 Design Advisor determines and recommends new virtual indexes that could improve the performance of the query before the query is executed. For more information, see Retrieving Index Recommendations [page 218]. To create user-defined virtual indexes You use the recommended values that are provided by the DB2 Design Advisor, to create an index specifically tailored for 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 Thus, you can check if the virtually defined indexes would improve the performance of the query. For more information, see Validating Indexes Using the EXPLAIN Function [page 220].

September 2008

217

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

8.6.1 Retrieving Index Recommendations


1. Call the DBA Cockpit 2. Choose The Diagnostics Index Advisor in the navigation frame of the DBA Cockpit.

Diagnostics

Index Advisor

screen appears.

3. In the SQL Statement editor field, enter the SQL statement that you want to investigate. 4. Choose Recommend Indexes. 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 result is displayed in the following table: Column Index Name Name of 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. o 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 o Recommended Index is recommended by the DB2 Design Advisor. Recommended indexes that do not exist are candidates for new indexes to be created. Note Existing indexes are displayed with a green background color. Virtual indexes are displayed with a red background color. End of the note. o Exists o No Index is a virtual index. Table Name Table on which the index is defined Yes Index exists in the database. Description

218

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Schema Name of the index schema Specifies a unique rule: o Uniqueness o o NLEAF NLEVELS Unique Primary Key

Description

Duplicates Allowed

Number of leaf pages Number of index levels o Yes Index supports reverse scans.

Rev. Scans o No Index does not support reverse scans. Columns INCLUDEs 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. Number of columns in the key plus the number of included columns if there have been any defined Number of included columns List of column names

8.6.2 Defining Virtual User-Defined Indexes


In addition to the indexes that the DB2 Design Advisor recommends, you are also able to define virtual user-defined indexes and validate their use by calling the EXPLAIN function. Procedure 1. Call the DBA Cockpit. 2. Choose Diagnostics Index Advisor in the navigation frame of the DBA Cockpit.

3. In the SQL Statement editor field, enter the SQL statement that you want to investigate.

September 2008

219

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

4. Choose Add Virtual Index. The Define Virtual Index dialog box appears. To define the user-defined index, proceed as follows: 1. Enter the schema and the table on which you want define the virtual index. 2. Choose Load Table Columns. The column names of the given table are displayed in the Table Columns List field. 3. To define index columns, either choose Add Column to Index or Remove Column From Index. 4. If you want the virtual index to be unique, select Unique. 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 Add. 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. If you want to remove all user-defined indexes, choose Remove User-Defined Indexes. End of the note. Result You can now use the EXPLAIN [page 202] function to validate existing, recommended and newly created user-defined indexes.

8.6.3 Validating Indexes Using the EXPLAIN Function


Procedure On the Diagnostics Index Advisor options from the drop-down 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. screen, choose EXPLAIN and one of the following

220

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Existing and recommended indexes Indexes that are known from the system catalog and indexes recommended by DB2 are used to build the access plan.

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 appears displaying the access plan that the DB2 optimizer considers to be the most efficient one.

8.6.4 Creating Indexes in the ABAP Dictionary


Note This function is not available for systems 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 updating or inserting data 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 that has already been virtually defined. 2. Choose Create Index in ABAP Dictionary (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. Note After the index has successfully been created, you can decide if you want to schedule a RUNSTATS for the affected table. End of the note.

September 2008

221

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Total Time % Count Time/Stmt Table Description Cumulative execution time of a statement Proportional execution time of one statement with regard to all executed statements Number of executions Average execution time of one statement 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 will be 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 205]. 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.

222

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 on 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 DBSL Trace Trace Level Specifies the amount of data to be traced The following trace levels are available: Number of I/O Records to Be Traced 2: Only statements are traced. 3: Statements and results are traced. Description

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 DBSL Trace Search String DBSL Trace Minimum Time Limit

Maximum output length If provided, only SQL statements containing this string are traced. If provided, only SQL statements with execution times higher than this time limit are traced.

September 2008

223

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Cumulative Trace Trace Level Displays the trace level on the current application server It is set to: First Trace Entry Last Trace Entry Number of Entries Deadlock Trace Detection Interval Only SQL statements running longer than this time are recorded for deadlock detection. 0: Trace switched off 1: Trace switched on

Displays the start time of this trace if trace information already exists Displays the end time of this trace if trace information already exists Displays the number of entries in this trace if trace information already exists

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 226]. 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. 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

224

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 226]. 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

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.

September 2008

225

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 155]. End of the note. More Information IBM DB2 Administration Guide

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.

226

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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

You can access the DB2 Logs by calling the DBA Cockpit and choosing Logs in the navigation frame of the DBA Cockpit.

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

September 2008

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


To directly access information about DB2 in the Internet, choose Diagnostics DB2 Help Center in the navigation frame of the DBA Cockpit. The DB2 help center for your database release is displayed.

228

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

9 Workload Management
Workload management was introduced with 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 Workload management is supported as of DB2 Version 9.5 for Linux, UNIX, and Windows. 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.

End of the note. 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. End of the note. 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 238]. 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.

September 2008

229

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. The following figure provides an overview of the proposed set of workloads and service classes:

Workloads

Service Subclasses

Service Superclasses

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_SC

SAP_ABAPUPD2_WL

SAP_ABAPUPD2_SSC

SAP_JAVA_WL

SAP_JAVA_SSC

SAP_DIAGNOSTIC_WL

SAP_DIAGNOSTIC_SSC

Note The workload SAP_DIAGNOSTIC_WL was created for usage in later releases. Currently, no work goes into this workload. End of the note.

230

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 238]. More Information Workload Management: Workloads and Service Classes [page 231] Workload Management: Critical Activities [page 235] Workload Management: SAP WLM Setup Status [page 231]

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

September 2008

231

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 Position Workload Name Description Evaluation order used for choosing a workload Name of the workload Workload state The following states are possible: Enabled 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 Name of the service subclass to which an UOW that is associated with this workload is assigned Name of the service super class to which an UOW that is associated with this workload is assigned. Green

Service Class Parent Service Class

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

232

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Service Classes On this tab page, you can view details of existing service classes. The following information is displayed: Column Service Class Name of the service class State of service class The following states are possible: Enabled The workload is enabled Red The workload is disabled Agent Priority Graphical display of the thread priority of the agents in the service class. Thread priority of the agents in the service class in relation to the normal priority of DB2 threads The value DEFAULT indicates that the thread priority was inherited from the parent service class. Graphical display of the agent's prefetch priority in the service class. Prefetch priority of the agents in the service class Green Description

Agent Priority (Remarks)

Prefetch Priority Prefetch Priority (Remarks)

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.

September 2008

233

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Statistics Displays monitoring information that is related to the service class To switch the time frame for which monitoring data is aggregated, choose the Choice pushbutton. 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 o 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 o 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: 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 o 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.

234

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 agent or prefetch priorities can significantly decrease the performance of some workloads. End of the caution.

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

September 2008

235

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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 238]. End of the note. Threshold Violations In this screen area, a history of threshold violations on the database system is displayed: Column Violation Partition Description Time when the threshold violation occurred 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 57]. End of the note. Violated Value Application ID Value that was exceeded, which violated the threshold predicate

Application ID of the activity that caused the violation

236

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

Column Agent ID

Description 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 94]. 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 are executed within the activity are displayed. If more than one SQL statement is 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. 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. End of the note.

September 2008

237

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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. End of the note. 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.

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 monitor tables, tablespace SAPEVENTMON was introduced. Event Monitor Infrastructure 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.

238

September 2008

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

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.

September 2008

239

Database Administration Using the DBA Cockpit: IBM DB2 for LUW

10 BI Administration
The following sections provide information on BI administration: BI Administration: BI Data Distribution [page 240] BI Administration: MDC Advisor [page 240]

10.1 BI Administration: BI 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 BI Data Distribution wizard. You can access the BI Data Distribution wizard by calling the DBA Cockpit and choosing Wizards: BI Data Distribution in the navigation frame of the DBA Cockpit. For detailed information about the steps to perform, see the screens of the BI Data Distribution wizard.

10.2 BI Administration: MDC Advisor


The MDC advisor is a DB2 tool that proposes multi dimensional clustering (MDC) settings for tables using queries executed on the table. You use the MDC advisor to collect SAP BI reporting queries for an InfoProvider, that is, for InfoCubes and DataStore objects. The MDC Advisor analyzes the collected SAP BI 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. More Information For more information about to how use the MDC advisor, see How to Use the MDC Advisor in the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows at: https://www.sdn.sap.com/irj/sdn/db6 SAP on DB2 for Linux, UNIX and Windows Knowledge Center SAP BI with IBM DB2 LUW BI Administration

240

September 2008

Potrebbero piacerti anche