DB Admin Using DBA Cockpit IBM DB2 for Linux Unix Wind
description
Transcript of DB Admin Using DBA Cockpit IBM DB2 for Linux Unix Wind
Database Administration Guide
Database Administration UIa FEN
D
P
sing the DBA Cockpit: BM DB2 for Linux, UNIX, nd Windows
or SAP Systems based on SAP nhancement Package 1 for SAP etWeaver 7.0
ocument Version 1.00 – September 8th, 2008
ublic
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
Type Style Description
Example Text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options.
Cross-references to other documentation
Example text Emphasized words or phrases in body text, graphic titles, and table titles
EXAMPLE TEXT Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE.
Example text Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.
Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.
EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.
Icons
Icon Meaning
Caution
Example
Note
Recommendation
Syntax
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.
4 September 2008
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: Real–Time 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 5
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
6 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 Day’s 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 7
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
8 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 9
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.
o 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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
10 September 2008
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:
Action area
Action message window
Navigation frame
Framework message window
System landscape toolbar
Application toolbar
Central system data
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 11
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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
12 September 2008
1.1.1 Central System Data Most of the DBA Cockpit screens provide a unique subscreen area displaying the central system data of the selected screen:
Field Description
Last Refresh Date and time when the screen data was last refreshed
DB Name Name of database of the selected system
Started Date and time when the database engine started
DB Release Database release
Last Reset/Checkpoint
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.
Current Selection
The currently selected set of data. This is available for actions that support Reset/Since Reset:
• Since DBM Start
• Reset
• Since Reset
And for actions supporting checkpoints:
• Current Configuration
• Checkpoint Set
• Delta to Checkpoint
System
Currently selected system
Note
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 13
Partition
Partition of currently selected system
Note
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
14 September 2008
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)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 15
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
16 September 2008
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.
e. If required, enter the name of the RFC connection.
After the connection data has been completed, it is displayed on the System Data tab page. You can enter additional data on the Administration Data tab page as follows:
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 17
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 Description
Remote Database Connections
Name of database connection
This is a unique name that you can freely choose.
DB Name Name of database
DB Host Name of database host
DB Schema Name of the database schema to be monitored
User Name of the connection user
Permanent Specifies whether the connect user must be permanently available
Max. Connections Maximum allowed number of open connections
Opt. Connections Optimal number of connections
By default, the database connections that are defined in the local system are displayed.
2. You are able to perform one of the following tasks:
You add database connections.
You change an existing database connection.
You delete a database connection.
You test a database connection.
More Information:
• Adding a Database Connection
• Changing a Database Connection
• Deleting a Database Connection
• Testing a Database Connection
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
18 September 2008
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. In the Database System field, specify the name of the database platform.
b. 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.
c. In the Connection Optimum field, enter an appropriate value. This value is a more flexible limit that can be exceeded.
d. If you want the connection to be mandatory for the SAP system, select Permanent Connection. This parameter defines the availability of the database connection.
It is then handled like the local default connection, that is, if this database connection is not available for a work process, the work process of the SAP system cannot run.
You should set this parameter only if this connection is absolutely required to run your SAP system.
e. In the User Name field, enter the name of the connect user. Make sure that you choose a user with the appropriate authorizations. For more information, see Maintenance Actions in the DBA Cockpit.
f. In the Password field, enter a password for the connect user.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 19
6. In the Connection Parameters table, specify the following additional database-specific attributes:
Attribute Description
Database Name Name of database
Service Name Name or number of the service
This value corresponds to the parameter SVCENAME of the database manager configuration (DBM) of the remote database.
Database Host Name of the remote database server
Schema Name Name of schema to be monitored
If you omit this field, the name of the 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
20 September 2008
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:
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 21
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
22 September 2008
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:
Content area
Content detail area
Detail navigation
Framework message window
System landscapeselector
Common header area
Central system data
Favorite list
Top level navigation including second-level navigation
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 23
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
24 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 25
Customizing the System Landscape Selector
By default, all systems are displayed without any grouping or filtering. For each configured system, the alert status, the name of the system and its database host is displayed. The following menu buttons are available for the list of systems:
• Refresh System Landscape
You can refresh the information about the available systems in the list.
• Group Systems by Selected Criteria
You can customize the displayed list of systems by grouping them according to the selected criteria:
o Database Platform
o Name
o Custom
o 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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
26 September 2008
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 performance-critical partitions before starting a more detailed analysis of your database.
You can access the Partition Overview screen by calling the DBA Cockpit and choosing Performance Partitions in the navigation frame of the DBA Cockpit.
For each partition of your database system, the following information is displayed:
Column Description
Partition Number of the partition (only displayed in a multi-partition database)
No. Buffer Pools Number of buffer pools used for a partition
Total Size Buffer Pools Total size in KB of all buffer pools used for a partition
Data Logical Reads Number of read accesses to data in the buffer pool
Index Logical Number of read accesses to index data in the buffer pool
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 27
Column Description
Reads
Data Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Index Physical Reads
Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents, this value includes the number of synchronously read index pages.
Avg. Phys. Read Time (ms)
Average time in milliseconds required to read data from disk into the buffer pool
Avg. Phys. Write Time (ms)
Average time in milliseconds required to write data from the buffer pool to disk
Executed SQL Statements
Number of executed SQL statements (SELECT, INSERT, UPDATE, DELETE)
Package Cache Size
Amount of application heap memory to be used for caching a package’s 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.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
28 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 29
Field Description
Buffer Pools
Number Number of buffer pools
Total Size Total size in KB of all buffer pools
Buffer Quality
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
Data Hit Ratio Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk
Index Hit Ratio Indicates the frequency as a percentage at which index data is read from the buffer pool, rather than directly from the hard disk
No Victim Buffers Number of times an agent did not have a preselected victim buffer available
Average Time
Physical Reads Average time in milliseconds required to read data from disk into the buffer pool
Physical Writes Average time in milliseconds required to write data from the buffer pool to disk
Data
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Physical Writes
Number of write accesses to data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to data on disk (by agents)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
30 September 2008
Field Description
Synchronous Writes Number of write accesses to data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get data pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get data pages into the temporary tablespace
Index
Logical Reads Number of read accesses to index data in the buffer pool
Physical Reads Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents, this value includes the number of synchronously read index pages.
Physical Writes
Number of write accesses to index data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to index data on disk (by agents)
Synchronous Writes Number of write accesses to index data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get index pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get index pages into the temporary tablespace
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 31
2.2.2 Database: Cache To display information on the cache, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose Cache.
Field Description
Catalog Cache
Size
Maximum allowed size in KB for the catalog cache
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.
Quality
Indicates percentage at which the data is read from the catalog cache, rather than directly from the hard disk
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
Inserts Number of times that the system tried to insert table descriptor information into the catalog cache
Overflows Number of times that an insert into the catalog cache failed due to the catalog cache being full
High-Water Mark Largest size reached by package cache
Package Cache
Size
Maximum allowed size in KB for the package cache
The package cache contains access plans. The maximum allowed size is determined by database configuration parameter PCKCACHESZ.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
32 September 2008
Quality
Indicates percentage at which the data is read from the package cache, rather than directly from the hard disk
This is calculated using the following formula: (package cache lookups - package cache inserts) / package cache lookups *100
Lookups Number of times an application looked for a section in the package cache
Inserts Total number of times that an access plan was not available for use and had to be loaded into the package cache
Overflows Number of times that the package cache overflowed the bounds of its allocated memory
High-Water Mark Largest size reached by the package cache
2.2.3 Database: Asynchronous I/O To display information on I/O servers and I/O cleaners, call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Database.
The Database Snapshot screen appears.
2. Choose Asynchronous I/O.
Field Description
I/O
Number of I/O Servers Number of I/O servers that read data asynchronously from the hard disk into the buffer pool
Number of I/O Cleaners Number of I/O cleaners that write data asynchronously from the buffer pool to the hard disk
Average Time
Asynchronous Physical Reads
Average time in milliseconds required by the I/O servers to read a page from disk and write it to the buffer pool
Asynchronous Physical Writes
Average time in milliseconds required by the I/O cleaners to read a page from the buffer pool and write it to the hard disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 33
Data
Asynchronous Physical Reads
Number of data pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes
Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners)
Asynchronous Read Requests
Number of asynchronous data read requests
Index
Asynchronous Physical Reads
Number of index pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes
Number of index pages that were written asynchronously from buffer pool to disk (I/O cleaners)
Asynchronous Read Requests
Number of asynchronous index read requests
Data is read or written in pages. A page can be 4 KB, 8 KB, 16 KB, or 32 KB in size.
2.2.4 Database: Direct I/O To display information on direct I/O, call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Database.
The Database Snapshot screen appears.
2. Choose Direct I/O.
Field Description
Average Time
Direct Reads Average time in milliseconds required to read directly from disk
Direct Writes Average time in milliseconds required to write directly to disk
I/O
Direct Reads Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup)
Direct Writes Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
34 September 2008
Average I/O per Request
Direct Reads Average number of requests to read directly from disk
Direct Writes Average number of requests to write directly to disk
2.2.5 Database: Real–Time Statistics To display information on real-time statistics, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose Real-Time Statistics.
Field Description
Size of Statistics Cache Size of statistics cache in bytes
Number of Asynchronously Collected Statistics
Total number of successful asynchronous statistics collection activities
Number of Statistics Collections During Query Compilation
Total number of statistics collection activities for creating statistics by the system without table or index scan during query compilation
Time Spent During Query Compilation
Total time spent on creating statistics by system without table or index scan during query compilation in milliseconds
Number of Synchronously Collected Statistics
Total number of synchronous statistics collection activities during query compilation
Time Spent on Synchronous Statistics Collection Activities
Total time spent on asynchronous statistics collection activities in milliseconds
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 35
2.2.6 Database: Locks and Deadlocks To display information on locks and deadlocks, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose Locks and Deadlocks.
Field Description
Lock List
Size Database locks are managed in a list. This parameter determines the maximum length of the list (database configuration parameter LOCKLIST). The lock list is allocated dynamically.
In Use Current size of the lock list
Lock Waits
Total Total number of times that applications or connections waited for locks
Time Waited Total amount of elapsed time in milliseconds that applications waited for a lock to be granted
Average Time Waited Average time in milliseconds waited for a lock
Escalations
Lock Escalations
Number of times that locks have been escalated from several row locks to a table lock
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
Exclusive Lock Escalations
Number of times that locks have been escalated from several row locks to one exclusive table lock, or the number of times an exclusive lock on a row caused the table lock to become an exclusive lock
Exclusive locks are important to track since they can impact the concurrency of your data because other applications cannot access data held by an exclusive lock.
Locks
Locks Currently Held Total number of locks currently held by the applications
Deadlocks Number of deadlocks that have occurred
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
36 September 2008
Field Description
Detected Deadlock situations are recognized and resolved automatically by the database. The database configuration parameter lock escalations determines when a lock wait situation is resolved.
Lock Timeouts
Number of times that a request to lock an object timed out instead of being granted
Parameter lock escalations determines when a lock wait situation is resolved.
2.2.7 Database: Logging To display information on log files, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot appears.
2. Choose Logging.
Field Description
Log Files
Primary
Number of primary log files
The database configuration parameter LOGPRIMARY determines this value.
Secondary Number of secondary log files
The database configuration parameter LOGSECOND determines this value.
Size
Number of pages in each log file
The database configuration parameter LOGFILSIZ determines this value. Each page has 4 KB.
Total Log
Available to Database
Amount of primary log space in bytes in the database that is not being used by uncommitted transactions
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 37
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 Least Available Space
Node with the least amount of available log space in Bytes
Note
This field is only displayed for global snapshots over all partitions.
End of the note.
Application with Oldest Transaction
Application ID (that corresponds to the agent_id value from the application snapshot) of the application that has the oldest transaction
Secondary Log
Logs Currently Allocated
Total number of secondary log files that are currently being used for the database
Maximum Space Used Maximum amount of secondary log space used in bytes
Log Pages
Read Number of log pages read from disk
Written Number of log pages written to disk
Log Buffer Consumption
LSN Gap Percentage of log space held by dirty pages in relation to log space specified by parameter SOFTMAX
Restart Range Percentage of log space held that will have to be redone for crash recovery pages in relation to log space specified by parameter SOFTMAX
Log Buffer Quality
Log Buffer Hit Ratio Ratio of log data read from the buffer in relation to log data read from disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
38 September 2008
Log Buffer Overflows
Number of times that agents have to wait for log data to write to disk while copying log records into the log buffer
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 time per page in microseconds required to write log data to disk
Average Write Time/IO Average time per I/O in microseconds required to write log data to disk
Average Read Time/Page Average time per page in microseconds required to read log data from disk
Average Read Time/IO Average time per I/O in microseconds required to read log data from disk
2.2.8 Database: Calls To display information on calls, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose Calls.
Field Description
Rows
Read Number of data records that were read
Selected Number of data records that were selected
Index Quality Ratio of rows selected compared to the number of rows read
This ration indicates the quality of index accesses.
Deleted Number of data records that were deleted
Inserted Number of data records that were inserted
Selected Number of data records that were selected
Updated Number of data records that were updated
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 39
Field Description
Statements Executed
SELECT SQL Number of SELECT statements that were executed
UPDATE/INSERT/DELETE Number of UPDATE, INSERT, and DELETE statements that were executed
DDL Number of Data Definition Language (DDL) statements that were executed, for example, CREATE TABLE, CREATE VIEW, ALTER TABLE, and DROP INDEX
Elapsed Time (sec) Sum of the host execution times in seconds for all the statements that were executed
Elapsed Time (microsec) Remaining part of the above elapsed time in microseconds
Statements Attempted
COMMITs Number of COMMIT statements that have been attempted
Rollbacks Number of ROLLBACK statements that have been attempted
Automatic rollbacks caused by error situations or deadlocks are not included.
Dynamic SQL Number of dynamic SQL statements attempted
Static SQL Number of static SQL statements attempted
Failed SQL Number of attempted SQL statements that failed
Hash Joins
Total Total number of hash joins executed
Total Hash Loops Total number of times that a single partition of a hash join was larger that the available sort heap space
Overflows Number of times that hash join data exceeded the available sort heap space
Small Overflows Number of times that hash join data exceeded the available sort heap space by less than 10 %
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
40 September 2008
Post Threshold
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 configuration parameter sheapthres_shr.
This throttling significantly reduces the number of overflows over thesheapthres_shr limit in a system that is not properly configured. The data reported in this element only reflects hash joins using memory allocated from the shared sort heap.
2.2.9 Database: Sorts To display information on sorts, call the DBA Cockpit.
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose Sorts.
Field Description
Sort Heap
Total Size Amount of memory in KB available for each sort as defined in the database configuration parameter SORTHEAP (in pages)
Allocated Total number of allocated space of sort heap space for all sorts at the level chosen and at the time the snapshot was taken
Sort Time
Total Total time in milliseconds required for all sort processes
Average Average sort time in milliseconds
Sorts
Total Sorts Total number of sorts that have been executed
Sort Overflows
If the storage area allocated for sorting is not large enough, a sort overflow occurs. The hard disk is then used temporarily.
Active Sorts Number of sorts in the database that currently have a sort heap allocated
Post Threshold
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 41
Field Description
Sorts allocation for sorts is close to the limit set by database configuration parameter sheapthres_shr. This throttling significantly reduces the number of overflows over sheapthres_shr limit in a system that is not properly configured.
The data reported in this element only reflects sorts using memory allocated from the shared sort heap.
2.2.10 Database: XML Storage To display information on XML storage accesses, call the DBA Cockpit
1. In the navigation frame, choose Performance Database .
The Database Snapshot screen appears.
2. Choose XML Storage.
Field Description
Pool Data
Logical Reads
Indicates the number of data pages for XML storage objects (XDAs) that have been requested from the buffer pool (logical reads) for regular and large tablespaces
Physical Reads
Indicates the number of data pages for XML storage objects (XDAs) that have been read from the tablespace containers (physical reads) for regular and large tablespaces
Write Accesses
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk
Temporary Data
Logical Reads
Indicates the number of pages for XML storage objects (XDA) that have been requested from the buffer pool (logical reads) for temporary tablespaces.
Physical Reads
Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
42 September 2008
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.
Physical Writes
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk by either an asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for the pages being prefetched.
Read Requests
Indicates the number of asynchronous read requests for XML storage object (XDA) data
2.3 Performance: Schemas If more than one SAP component is installed within the same database, this overview screen provides a selection of performance data that is related to these components. You can use the information displayed to identify performance-critical components and the workload distribution among the components.
You can access the Performance: Schema Overview screen by calling the DBA Cockpit and choosing Performance Schemas in the navigation frame of the DBA Cockpit.
For each component (and partition if you are using a multi-partition database), the following information is displayed:
Column Description
User Name of connect user to identify the component
Partition Number of the partition (only displayed in a multi-partition database)
SAP Component Indicates if the connect user is related to a SAP component or another user that is just connected to the database
Data Logical Reads Number of read accesses to data in the buffer pool
Data Logical Reads (%)
Indicates the percentage of logical data read accesses for the component (and partition if you are using a multi-partition database)
Index Logical Reads Number of read accesses to index data in the buffer pool
Index Logical Reads (%)
Indicates the percentage of index logical data read accesses for the component (and partition if you are using a multi-partition database)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 43
Column Description
Data Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Data Physical Reads (%)
Indicates the percentage of physical data read accesses for the component (and partition if you are using a multi-partition database)
Index Physical Reads
Number of read accesses to index data on disk (I/O)
Since index data is only read by the database manager agents, this value includes the number of synchronously read index pages.
Index Physical Reads (%)
Indicates the percentage of index physical read accesses for the component (and partition if you are using a multi-partition database)
2.4 Performance: Buffer Pools The Buffer Pool Snapshot screen provides an overview of the following important key indicators of the buffer pool activity of your database and enables you to compare these key indicators:
• Buffer Pool Name
• Buffer Pool Size (KB)
• Automatic Size (Yes or No)
• Buffer Quality (%)
• Data Logical Reads
• Data Physical Reads
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
44 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 45
If you have selected more than one buffer pool, you can use the page buttons on the screen to navigate between them.
Field Description
Buffer Pool
Name Name of the buffer pool
Current Size
Size of the buffer pool in KB and in pages
Caution
If Automatic is selected, the buffer pool is automatically tuned (if DB2's Self Tuning Memory Management was activated).
End of the caution.
New Size Size of the buffer pool in pages after a database restart
Pages Left to Remove Number of pages that are still to be removed
Tablespace Use Count Number of tablespaces that belong to this buffer pool
Buffer Quality
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
Data Hit Ratio Indicates percentage at which only data (without index data) is read from the buffer pool, rather than directly from the hard disk
Index Hit Ratio Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk
Average Time
Physical Reads Average time in milliseconds required to read data from disk into the buffer pool
Physical Writes Average time in milliseconds required to write data from the buffer pool to disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
46 September 2008
Data
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Physical Writes
Number of write accesses to data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to data on disk (by agents)
Synchronous Writes Number of write accesses to data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get data pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get data pages into the temporary tablespace
Index
Logical Reads Number of read accesses to index data in the buffer pool
Physical Reads Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents, this value includes the number of synchronously read index pages.
Physical Writes
Number of write accesses to index data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to index data on disk (by agents)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 47
Synchronous Writes Number of write accesses to index data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get index pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get index pages into the temporary tablespace
2.4.2 Buffer Pools: Asynchronous I/O To display information on asynchronous I/O for your selected buffer pool(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Buffer Pools.
The Buffer Pool Snapshot screen appears.
2. To display more detailed information, select one or more buffer pools and choose Details.
A detail Buffer Pool Snapshot screen appears.
3. Choose Asynchronous I/O.
If you have selected more than one buffer pool, you can use the page buttons on the screen to navigate between them.
Field Description
Average Time
Asynchronous Physical Reads
Average time in milliseconds required by the I/O servers to read a page from disk and write it to the buffer pool
Asynchronous Physical Writes
Average time in milliseconds required by the I/O cleaners to read a page from the buffer pool and write it to the hard disk
Data
Asynchronous Physical Reads
Number of data pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes
Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners)
Asynchronous Read Requests
Number of asynchronous data read requests
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
48 September 2008
Index
Asynchronous Physical Reads
Number of index pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes
Number of index pages that were written asynchronously from buffer pool to disk (I/O cleaners)
Asynchronous Read Requests
Number of asynchronous index read requests
Data is read or written in pages. A page can be 4 KB, 8 KB, 16 KB, or 32 KB in size.
2.4.3 Buffer Pools: Direct I/O To display information on direct I/O for your selected buffer pool(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Buffer Pools.
The Buffer Pool Snapshot screen appears.
2. To display more detailed information, select one or more buffer pools and choose Details.
A detail Buffer Pool Snapshot screen appears.
3. Choose Direct I/O.
If you have selected more than one buffer pool, you can use the page buttons on the screen to navigate between them.
Field Description
Average Time
Direct Reads Average time in milliseconds required to read directly from disk
Direct Writes Average time in milliseconds required to write directly to disk
I/O
Direct Reads Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup)
Direct Writes Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load)
Average I/O per Request
Direct Reads Average number of requests to read directly from disk
Direct Writes Average number of requests to write directly to disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 49
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 Description
Pool Data
Logical Reads Indicates the number of data pages for XML storage objects (XDAs) that have been requested from the buffer pool (logical reads) for regular and large tablespaces
Physical Reads
Indicates the number of data pages for XML storage objects (XDAs) that have been read from the tablespace containers (physical reads) for regular and large tablespaces
Write Accesses
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk
Temporary Data
Logical Reads Indicates the number of pages for XML storage objects (XDA) that have been requested from the buffer pool (logical reads) for temporary tablespaces.
Physical Reads
Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces
Asynchronous I/O
Physical Reads
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
50 September 2008
Field Description
Physical Writes
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk by either an asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for the pages being prefetched.
Read Requests
Indicates the number of asynchronous read requests for XML storage object (XDA) data
2.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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 51
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 Description
Tablespace
Name Name of the tablespace
Buffer Quality
Buffer Pool Name of the buffer pool that is associated with the selected tablespace
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
Data Hit Ratio Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
52 September 2008
Field Description
Index Hit Ratio Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk
No Victim Buffer Number of times an agent did not have a preselected victim buffer available
Average Time
Physical Reads Average time in milliseconds required to read data from disk into the buffer pool
Physical Writes Average time in milliseconds required to write data from the buffer pool to disk
Data
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Physical Writes
Number of write accesses to data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to data on disk (by agents)
Synchronous Writes Number of write accesses to data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get data pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get data pages into the temporary tablespace
Index
Logical Reads Number of read accesses to index data in the buffer pool
Physical Reads Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents, this value includes the number of synchronously read index pages.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 53
Field Description
Physical Writes
Number of write accesses to index data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Synchronous Reads Number of read accesses to index data on disk (by agents)
Synchronous Writes Number of write accesses to index data on disk (by agents)
Temporary Logical Reads
Number of logical read requests that required I/O to get index pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get index pages into the temporary tablespace
2.5.2 Tablespaces: Asynchronous I/O To display information on asynchronous I/O for your selected tablespace(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Tablespaces.
The Tablespace Snapshot screen appears.
2. To display more detailed information, select one or more tablespaces and choose Details.
A detail Tablespace Snapshot screen appears.
3. Choose Asynchronous I/O.
If you have selected more than one tablespace, you can use the page buttons on the screen to navigate between them.
Field Description
Average Time
Asynchronous Physical Reads Average time in milliseconds required by the I/O servers to read a page from disk and write it into the buffer pool
Asynchronous Physical Writes Average time in milliseconds required by the I/O cleaners to read a page from the buffer pool and write it to the hard disk
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
54 September 2008
Data
Asynchronous Physical Reads Number of data pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes Number of data pages that were written asynchronously from buffer pool to disk (I/O cleaners)
Asynchronous Read Requests Number of asynchronous data read requests
Index
Asynchronous Physical Reads Number of index pages that were read asynchronously from disk and written to the buffer pool by the I/O servers (prefetch)
Asynchronous Physical Writes Number of index pages that were written asynchronously buffer pool to disk (I/O cleaners)
Asynchronous Read Requests Number of asynchronous index read requests
2.5.3 Tablespaces: Direct I/O To display information on direct I/O for your selected tablespace(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Tablespaces.
The Tablespace Snapshot screen appears.
2. To display more detailed information, select one or more tablespaces and choose Details.
A detail Tablespace Snapshot screen appears.
3. Choose Direct I/O.
If you have selected more than one tablespace, you can use the page buttons on the screen to navigate between them.
Field Description
Average Time
Direct Reads Average time in milliseconds required to read directly from disk
Direct Writes Average time in milliseconds required to write directly to disk
I/O
Direct Reads Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup)
Direct Writes Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 55
Average I/O per Request
Direct Reads Average number of requests to read directly from disk
Direct Writes Average number of requests to write directly to disk
2.5.4 Tablespaces: XML Storage To display information on XML storage for the selected tablespace(s), call the DBA Cockpit
1. In the navigation frame, choose Performance Tablespaces .
A detail Tablespace Snapshot screen appears.
2. To display more detailed information, select one or more tablespaces and choose Details.
A detail Tablespace Snapshot screen appears.
3. Choose XML Storage.
If you have selected more than one tablespace, you can use the page buttons on the screen to navigate between them.
Field Description
Pool Data
Logical Reads Indicates the number of data pages for XML storage objects (XDAs) that have been requested from the buffer pool (logical reads) for regular and large tablespaces
Physical Reads Indicates the number of data pages for XML storage objects (XDAs) that have been read from the tablespace containers (physical reads) for regular and large tablespaces
Write Accesses Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk
Temporary Data
Logical Reads Indicates the number of pages for XML storage objects (XDA) that have been requested from the buffer pool (logical reads) for temporary tablespaces.
Physical Reads Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces
Asynchronous I/O
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
56 September 2008
Field Description
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.
Physical Writes
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk by either an asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for the pages being prefetched.
Read Requests Indicates the number of asynchronous read requests for XML storage object (XDA) data
2.6 Performance: Tables The Table Snapshot screen displays information on all tables of the database, such as the number of rows read, the number of rows written, the number of accesses to rows that have been moved out of the page due to overflow (Overflow Access) and page reorganizations (Page Reorgs).
You can access the Table Snapshot screen by calling the DBA Cockpit and choosing Performance Tables in the navigation frame of the DBA Cockpit.
The following information is displayed:
Column Description
Table Schema Name of the schema
Table Name Name of the table
Partition Number of the partition (only displayed in a multi-partition database)
Table File ID File ID (FID) of the table
Table Type Type of table for which information is displayed, for example, user, system or temp
Rows Written Number of rows changed (inserted, deleted or updated) in the table
Rows Read Number of rows read from the table
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 57
Column Description
Overflow Access
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.
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.
Page Reorgs
Number of page reorganizations executed for the table
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
58 September 2008
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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 59
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
60 September 2008
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Application
PID Process ID of the database process belonging to a SAP work process
Handle
A system-wide unique ID for the application
On multi-partition database systems, this ID will be the same on every partition where the application may make a secondary connection. Several agent processes (DB2 agent) can be assigned to an application handle.
Connect Start Start time when the application connected to the database
Platform Operating system on which the client application is running
Host Host name of the application server where the application server is running
Name Name of application running at the client as known to the database manager or DB2 connect
Status
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.
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 61
Field Description
• Commit Active
The unit of work is committing its database changes.
• Rollback Active
The unit of work is rolling back its database changes.
• Recompiling
The database manager is compiling an SQL statement or precompiling a plan on behalf of the application.
• Request Interrupted
An interrupt of a request is in progress.
• Database Disconnect Pending
The application has initiated a database disconnect but the command has not yet completed executing. The application may not have explicitly executed the database disconnect command. The database manager will disconnect from a database if the application ends without disconnecting.
• Transaction prepared
The unit of work is part of a global transaction that has entered the prepared phase of the two-phase commit protocol.
• Transaction Heuristically
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
62 September 2008
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 Process ID of an SAP work process that made the connection to the database
Client Information
User ID
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 client’s system or workstation (for example, CICS EITERMID), if the sqleseti API was used in this connection.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 63
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
Accounting
The data passed to the target database for logging and diagnostic purposes, if the sqleseti API was used in this connection.
For ABAP systems: Name of the program executing the SQL statement
2.7.2 Applications: Agents Note
This tab page is only available if you are using the SAP GUI-based user interface of the DBA Cockpit.
End of the note.
To display information on agents for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Agents.
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Agents
Coordinator Agent PID
Process ID (UNIX systems) or thread ID (OS/2 or Windows systems) of the coordinator agent for the application
Currently Associated Number of agents currently associated with the application
Associated with This Appl. Number of agents participating in this application (high-water mark)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
64 September 2008
Stolen from Application
Number of agents removed from this application and subsequently used by another application
This only happens if the agent was not busy.
Times Used by Agent(s)
User CPU Time Total user CPU time in seconds consumed by agent(s)
System CPU Time Total system CPU time in seconds consumed by agent(s)
Idle Time Total idle time in seconds
Waited for Prefetch Total time in milliseconds waited for prefetch
Memory Pools Allocated to Agent
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
• 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 65
2.7.3 Applications: Assigned Agents Note
This tab page is only available if you are using the Web browser-based user interface of the DBA Cockpit.
End of the note.
To display information on agents for your selected application, call the DBA Cockpit.
1. Choose Performance Snapshots Applications .
The Applications screen appears.
2. Select an application from the list.
3. Choose the Assigned Agents tab page.
The following information is displayed on the Assigned Agents tab page:
Field Description
Agents
Coordinator Agent PID
Process ID (UNIX systems) or thread ID (Windows) of the coordinator agent for the application
Currently Associated Number of agents currently associated with the application
Associated with This Appl. Number of agents participating in this application (high-water mark)
Stolen from Application
Number of agents removed from this application and subsequently used by another application
This only happens if the agent was not busy.
Times Spent by Agent(s)
User CPU Time Total user CPU time in seconds consumed by agent(s)
System CPU Time Total system CPU time in seconds consumed by agent(s)
Idle Time Total idle time in seconds
Waited for Prefetch Total time in milliseconds waited for prefetch
Assigned Agents This table displays information about all agents that are the coordinator agent itself or agents working as a subagent for the coordinator agent:
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
66 September 2008
Field Description
• Partition
Partition number
• Agent Type
Type of the agent
• Nesting Level
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 67
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 Description
Partition Partition number
PID
Process ID (UNIX) of the agent
Note
On Windows, this is called thread ID.
End of the note.
Pool ID Type of memory pool
Current Size (KB) Current size of the memory pool
High-Water Mark (KB) Largest size of the memory pool since its creation
Configured Size (KB) Configured size of the memory pool
2.7.5 Applications: Buffer Pool
To display information on buffer pool activity for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Buffer Pool.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
68 September 2008
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Buffer Quality
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
Data Hit Ratio Indicates percentage at which data (without index data) is read from the buffer pool, rather than directly from the hard disk
Index Hit Ratio Indicates percentage at which index data is read from the buffer pool, rather than directly from the hard disk
Average Time
Physical Reads Average time in milliseconds required to read data from disk into the buffer pool
Physical Writes Average time in milliseconds required to write data from the buffer pool to disk
Data
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O Servers).
Physical Writes
Number of write accesses to data on disk (I/O)
It includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O Cleaners).
Temporary Logical Reads
Number of logical read requests that required I/O to get data pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get data pages into the temporary tablespace
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 69
Index
Logical Reads Number of read accesses to index data in the buffer pool
Physical Reads Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents this value contains the number of synchronously read index pages.
Physical Writes
Number of write accesses to index data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O Cleaners).
Temporary Logical Reads
Number of logical read requests that required I/O to get index pages into the temporary tablespace
Temporary Physical Reads
Number of physical read requests that required I/O to get index pages into the temporary tablespace
2.7.6 Applications: Direct I/O To display information on direct I/O for your selected application(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Applications.
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
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 Description
Average Time
Direct Reads Average time in milliseconds required to read directly from disk
Direct Writes Average time in milliseconds required to write directly to disk
I/O
Direct Reads Read accesses from disk that do not use the buffer pool (LONG VARCHAR fields, backup)
Direct Writes Write accesses to disk that do not use the buffer pool (LONG VARCHAR fields, restore, load)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
70 September 2008
Average I/O per Request
Direct Reads Average number of requests to read directly from disk
Direct Writes Average number of requests to write directly to disk
2.7.7 Applications: XML Storage To display information on XML storage for the selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose XML Storage.
Field Description
Pool Data
Logical Reads
Indicates the number of data pages for XML storage objects (XDAs) that have been requested from the buffer pool (logical reads) for regular and large tablespaces
Physical Reads
Indicates the number of data pages for XML storage objects (XDAs) that have been read from the tablespace containers (physical reads) for regular and large tablespaces
Write Accesses
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk
Temporary Data
Logical Reads
Indicates the number of pages for XML storage objects (XDA) that have been requested from the buffer pool (logical reads) for temporary tablespaces.
Physical Reads
Indicates the number of pages for XML storage objects that have been (XDA) read from the tablespace containers (physical reads) for temporary tablespaces
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 71
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.
Physical Writes
Indicates the number of times a buffer pool data page for an XML storage object (XDA) was physically written to disk by either an asynchronous page cleaner, or a prefetcher
A prefetcher may have written dirty pages to disk to create space for the pages being prefetched.
Read Requests
Indicates the number of asynchronous read requests for XML storage object (XDA) data
2.7.8 Applications: Locks and Deadlocks To display information on locks and deadlocks for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Locks and Deadlocks.
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Fields Description
Lock Waits
Total Total number of times that this application requested a lock, but had to wait because another application was already holding a lock on the data
Time Waited Total amount of elapsed time in milliseconds that this application has waited for a lock to be granted
Average Time Waited Average time in milliseconds waited for a lock
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
72 September 2008
Escalations
Lock Escalations
Number of times that locks have been escalated from several row locks to a table lock
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".
Exclusive Lock Escalations
Number of times that locks have been escalated from several row locks to one exclusive table lock, or the number of times an exclusive lock on a row caused the table lock to become an exclusive lock
Exclusive locks are important to track since they can impact the concurrency of your data because other applications cannot access data held by an exclusive lock.
Locks
Locks Currently Held Total number of locks currently held by the application
Deadlocks Detected
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.
Lock Timeouts
Number of times that a request to lock an object timed out instead of being granted
The database configuration parameter LOCKTIMEOUT determines when a lock wait situation is resolved.
Lock Timeout Value Value of the database configuration parameterLOCKTIMEOUT
Deadlock Event Monitor
Statement History List Size
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 73
2.7.9 Applications: Calls To display information on calls for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Calls.
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Rows
Deleted Number of data records that were deleted
Inserted Number of data records that were inserted
Selected Number of data records that were selected
Updated Number of data records that were updated
Statements Executed
SELECT SQL Number of SELECT statements that were executed
UPDATE/INSERT/DELETE Number of UPDATE, INSERT, and DELETE statements that were executed
DDL Number of Data Definition Language (DDL) statements that were executed, for example, CREATE TABLE, CREATE VIEW, ALTER TABLE, and DROP INDEX.
Statements Attempted
COMMITs Number of COMMIT statements that have been attempted
Rollbacks Number of ROLLBACK statements that have been attempted
Automatic rollbacks caused by error situations or deadlocks are not included.
Dynamic SQL Number of dynamic SQL statements attempted
Static SQL Number of static SQL statements attempted
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
74 September 2008
Field Description
Failed SQL Number of attempted SQL statements that failed
Hash Joins
Total Total number of hash joins executed
Total Hash Loops Total number of times that a single partition of a hash join was larger than the available sort heap space
Overflows Number of times that hash join data exceeded the available sort heap space
Small Overflows Number of times that hash join data exceeded the available sort heap space by less than 10 %
2.7.10 Applications: Sorts To display information on sorts for your selected application(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Applications.
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
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 Description
Sort Time
Total Total time in milliseconds required for all sort processes
Average Average sort time in milliseconds
Sorts
Total Sorts Total number of sorts that have been executed
Sort Overflows If the storage area allocated for sorting is not large enough, a sort overflow occurs. The hard disk is then used temporarily.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 75
2.7.11 Applications: Cache To display information on cache for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Cache.
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Catalog Cache
Quality
Indicates percentage at which the data is read from the catalog cache, rather than directly from the hard disk
This is calculated using the following formula: (catalog cache lookups - catalog cache insert) / catalog cache lookups * 100
Lookups Number of times that the catalog cache was referenced to obtain table descriptor information
Inserts Number of times that the system tried to insert table descriptor information into the catalog cache
Overflows Number of times that an insert into the catalog cache failed due to the catalog cache being full
Heap Full Number of times that an insert into the catalog cache failed due to the database heap being full
Package Cache
Quality
Indicates percentage at which the data is read from the package cache, rather than directly from the hard disk
This is calculated using the following formula: (package cache lookups - package cache inserts) / package cache lookups * 100
Lookups Number of times an application looked for a section in the package cache
Inserts Total number of times that a request section was not available for use and had to be loaded into the package cache
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
76 September 2008
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 Description
Unit of Work
Start Time Time that unit of work first required database resources
Stop Time Time that the most recent unit of work completed, which occurs when the database changes are committed or rolled back
Elapsed Time (s) Duration of unit of work in seconds
Elapsed Time (µs) Duration of unit of work in microseconds
Log Space Used Log space used in bytes in most recent unit of work
Completion Status Completion status of last transaction
Previous Unit of Work
Stop Time Previous time that the most recent unit of work completed, which occurs when the database changes are committed or rolled back
2.7.13 Applications: Statement To display information on performance data of the current SQL statements for your selected application(s), call the DBA Cockpit. ...
1. In the navigation frame, choose Performance → Applications.
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Statement.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 77
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Statement
Start Time Date and time when unit of work starts, the statement starts or a deadlock is detected
Stop Time Date and time when the statement stopped executing
Elapsed Time(s) Duration of unit of work in seconds
Elapsed Time (µsec) Duration of unit of work in microseconds
Rows
Rows Read Number of rows read from the table
Rows Written Number of rows changed (inserted, deleted or updated) in the table
Sort
Sort Overflow If the storage area allocated for sorting is not large enough, a sort overflow occurs. The hard disk is then temporarily used.
Total Sort Time Total time for all sort processes
Number of Statement Sorts Total number of sorts that have been executed
Data
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads Number of read accesses to data on disk
Temporary Logical Reads Number of logical read requests that required I/O to get data pages into the temporary tablespace
Temporary Physical Reads Number of physical read requests that required I/O to get data pages into the temporary tablespace
Index
Logical Reads Number of read accesses to data in the buffer pool
Physical Reads Number of read accesses to data on disk
Temporary Logical Reads Number of logical read requests that required I/O to get index pages into the temporary tablespace
Temporary Physical Reads Number of physical read requests that required I/O to get index pages into the temporary tablespace
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
78 September 2008
2.7.14 Applications: Statement Text To display information on the current SQL statements for your selected application(s), call the DBA Cockpit.
1. In the navigation frame, choose Performance Applications .
The Application Snapshot screen appears.
2. To display more detailed information, select one or more applications and choose Details.
A detail Application Snapshot screen appears.
3. Choose Statement Text.
If you have selected more than one application, you can use the page buttons on the screen to navigate between them.
Field Description
Statement
Type
Type of statement processed
Possible types are:
• Static SQL statement
• Dynamic SQL statement
• An operation other than an SQL statement, for example, a bind or precompile operation
Operation
Operation currently being processed or most recently processed (if none is currently running)
Possible operations are:
• SELECT
• PREPARE
• EXECUTE
• EXECUTE IMMEDIATE
• OPEN
• FETCH
• CLOSE
• DESCRIBE
• STATIC COMMIT
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 79
Field Description
• STATIC ROLLBACK
• FREE LOCATOR
• PREP_COMMIT
• CALL
• PREP_OPEN
• PREP_EXEC
• COMPILE
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.
Statement
Text of dynamic SQL statement that was being processed when the snapshot was taken
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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
80 September 2008
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 Description
Private Workspace
Lookups Number of times an application looked for an SQL section in the agent's private workspace
Inserts Inserts of SQL sections by an application into the private workspace
Overflows Number of times that the private workspace overflowed the bounds of its allocated memory
High-Water Mark Largest size reached by the private workspace
Shared Workspace
Lookups Number of times an application looked for an SQL section in the agent's shared workspace
Inserts Inserts of SQL sections by an application into the shared workspace
Overflows Number of times that the shared workspace overflowed the bounds of its allocated memory
High-Water Mark Largest size reached by the shared workspace
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 81
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 Description
Executions Number of times a statement has been executed
Total Execution Time Total execution time in milliseconds for a statement
Avg. Execution Time Average execution time in milliseconds for a statement
Rows Read Number of rows read for a statement
Rows Written Number of rows written by a statement
SQL Text (Case-Sensitive)
Search using either the wild card "*" or using a text string, for example, INSERT, to limit the number of statements displayed
Rows Read / Rows Processed
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
82 September 2008
When you have made your selections and chosen Continue, the result set is determined by filtering the snapshot results according to the selection criteria and the following information is displayed:
Field Description
Total Cache Sum
Execution Time Total execution time in milliseconds for an SQL statement
Rows Read Total number of rows read
Rows Written Total number of rows written
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 Description
SQL Text Text of a dynamic SQL statement that was in the SQL cache at the time of the snapshot
Executions
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
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 ( %)
Total Execution Time (milliseconds) divided by Total Cache Sum Execution Time (milliseconds)
Average Execution Time (ms)
Total Execution Time (in milliseconds) divided by Executions
Buffer Quality (%) Buffer quality for this statement in percent
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 83
Rows Read / Rows Processed
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. 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.
BP Gets / Rows Processed
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).
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
Average number of pages read from the buffer pool per execution of the statement.
Total User CPU Time (ms)
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 (ms)
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.
Rows Read
Number of 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 (%) Rows Read divided by Total Cache Sum Rows Read
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
84 September 2008
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 (%) Rows Written divided by Total Cache Sum Rows Written
SQL Sorts
Number of sorts that were necessary to execute the statement
You can use this value to determine whether new indexes are needed. Use EXPLAIN to check whether and which indexes were used when the selected statement was executed.
Sort Overflows Number of sort overflows
Total Sorts Total number of sorts
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].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 85
• 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>
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
86 September 2008
To display the last SQL statement that was executed by one of the agents, choose Last SQL Statement. The last SQL statement of the respective agent is displayed in the editor window at the bottom of the screen.
Tree Node Description
<Agent ID> Agent handle of the application waiting for the lock to be released
<Application Name> Name of the application waiting for the lock to be released
<Client Process ID> Process ID of the application requesting the lock
<Host> Host name of the server requesting the lock
Requested Lock Mode
Lock modes that the waiting application would like to set
The following lock modes are possible:
• 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
Current Lock Mode Lock mode held
Lock Object Type Type of object to be locked
Table Table on which/on whose record the lock is held
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 87
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 Description
Table Schema Table schema of the table that is currently being reorganized
Table Name Name of the table that is currently being reorganized
Partition Number of the partition (only displayed in a multi-partition database)
REORG Status
Status of the inplace table reorganization
Possible values are:
• Running
• Paused
• Suspended
• Completed
Progress % Progress of the reorganization
Start Date Start date of the inplace table reorganization
Start Time Start time of the inplace table reorganization
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
88 September 2008
Access Mode
Access mode for other users while the table reorganization is running
The following access modes are possible:
• READ
• WRITE
• NO ACCESS
Tablespace Name of the tablespace where the reorganization is performed
Note
If no active inplace table reorganization was found, the system displays the following message: No Inplace Table Reorganizations are running. Only the REORG activities since the database start are displayed. REORGs that were active before the database start are not displayed.
End of the note.
Depending on your requirements, you can customize the view on the Performance: Active Inplace Table Reorganizations screen using the following functions:
Pushbutton Function
Choose View
• Active Only
Only inplace table reorganizations with the status Started or Paused are displayed.
• All
All inplace table reorganizations are displayed including those with status Completed or Suspended.
Choose Data Source
• Since DB Start
Only inplace table reorganization that have been started after the last restart of the database manager are displayed.
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 89
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 Description
Partition Monitored partition (only displayed if you are using a multi-partition database)
Date Day when monitoring was performed
Avg. Phys. Read Time (ms)
Average physical read time
If you have chosen Total Day, this is the average of all measured average read times. If you have chosen Peak, this is the worst measured read time.
Avg. Phys. Write Time (ms)
Average physical write time
If you have chosen Total Day, this is the average of all measured average write times. If you have chosen Peak, this is the worst measured write time.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
90 September 2008
Data Logical Reads Number of read accesses to data in the buffer pool
Data Physical Reads
Number of read accesses to data on disk (I/O)
The value includes the number of physical reads that were performed synchronously (by the database manager agents) and asynchronously (by the I/O servers).
Data Physical Writes
Number of write accesses to data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
Index Logical Reads Number of read accesses to index data in the buffer pool
Index Physical Reads
Number of read accesses to index data on disk (I/O)
Since index data is read only by the database manager agents, this value includes the number of synchronously read index pages.
Index Physical Writes
Number of write accesses to index data on disk (I/O)
The value includes the number of physical writes that were performed synchronously (by the database manager agents) and asynchronously (by the I/O cleaners).
COMMIT Statements Total number of COMMIT statements that have been attempted
ROLLBACK Statements
Total number of ROLLBACK statements that have been attempted
Automatic ROLLBACKs caused by error situations or deadlocks are not included.
Lock Waits Total number of times that applications or connections waited for locks
Lock Wait Time (ms) Total elapsed time in milliseconds waited for a lock
Deadlocks Total number of deadlocks that have occurred
Lock Escalations Number of times that locks have been escalated from several row locks to a table lock
Exclusive Lock Escalations
Number of times that locks have been escalated from several row locks to one exclusive table lock, or the number of times an exclusive lock on a row caused the table lock to become an exclusive lock
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 91
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
92 September 2008
Column Description
Overflow Accesses
Number of read accesses to tables that resulted in overflow pages, that is, to records, which have been swapped from their original page.
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 Number of internal page reorganizations during INSERT operations
Note
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 93
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
94 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 95
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 Description
BI Server BI server where the database performance data is located
Managing DBA Cockpit This DBA Cockpit is allowed to change any data collectors or performance warehouse configuration for this database. By default, the DBA Cockpit of the Solution Manager system is used for this task.
Reporting Time Zone The performance data time-stamps are converted to one global time zone for all reports in SMD BI.
The Default checkbox is selected if the default value for your complete landscape is the same as the one specified for your system.
Web Reports
Here, you can configure the display on the Reporting screen. That is, you can view and modify the integrated BI BEx Web templates in the tree table. To modify some of these parameters, use the Edit, Add and Delete pushbuttons in the toolbar.
The main report categories appear and for each report category, you can view or modify the views by expanding the appropriate report category. These views appear as pushbuttons on the respective category tab page on the Reporting screen. To change the sequence within a category, use the Up or Down pushbuttons.
To display details about a view, simply select it in the table. The following parameters are displayed in the Details for Web Reports area below the table view:
Parameter Description
Report Specifies the name of the report
This text appears on the view pushbutton on a category tab page.
Description Detailed description for the report
This text appears as a tooltip for the pushbutton of the key indicator on a category tab page.
Category Specifies the report category.
Each category is represented on a separate tab page.
Web Report (Default) Technical name of the BI BEx Web templates
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
96 September 2008
Web Report (Day) Technical name of the BI BEx Web templates for granularity Day
Web Report (Month) Technical name of the BI BEx Web templates for granularity Month
Data Providers (Time) Specifies the data provider of the BI BEx Web templates with a time dimension. The drilldown of the time dimension is changed according to the selected granularity.
Active If selected, the report is available for performance analysis.
Default If selected, the report is executed as soon as the tab page is selected.
Database Name of database platform
Release (min) Minimum database release for this report
Release (max) Maximum database release for this report
Depending on your database platform, there might be more checkboxes available for database-specific features. If you select these checkboxes, the report is only displayed if the specific database features have been set up in the monitored database system.
Report Categories
Here, you can view and modify the categories for BI BEx Web templates of the reports that are displayed the Reporting screen. To modify some of these parameters, use the Edit, Add and Delete pushbuttons in the toolbar. To change the sequence of the categories on the Reporting screen, use the Up or Down pushbuttons.
The following parameters are displayed:
Parameter Description
Category Name of the category
Description Detailed description for the category
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 97
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 Description
Partition Number of database partition
Storage Path Full path name
FS ID ID of the related file system
FS Free Size (GB) Free size in GB that is available in the file system
FS Total Size (GB) Total size in GB that is available in the file system
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
98 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 99
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 Description
Tablespace Name Name of the tablespace
Partition Number of the database partition (only displayed in a multi-partition database)
Contents Contents of tablespace, for example, any data or temporary data
TS State Status of tablespace, for example, normal or load pending
KB Total Total space in KB used by the tablespace
Page Size Size of a page in bytes
No. Containers Number of containers
KB Free Total amount of free space
High-Water Mark Indicates the maximum value of used pages reached
Percent Used Used space in relation to available space
Pending Free Pages Number of free pages that are pending
DMS/SMS Tablespaces
Regardless whether you have chosen automatic storage management tablespaces or manual maintenance of DMS/SMS tablespaces during the SAP system installation, the following information is displayed for all DMS/SMS tablespaces that are maintained manually:
Column Description
Tablespace Name Name of the tablespace
Partition Number of the partition (only displayed in a multi-partition database)
TS Type Type of tablespace, for example, DMS or SMS
Contents Contents of tablespace, for example, any data or temporary data
TS State Status of tablespace, for example, normal or load pending
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
100 September 2008
Column Description
KB Total Total space in KB used by the tablespace
Page Size Size of a page in bytes
No. Containers Number of containers
KB Free Total amount of free space
High-Water Mark Indicates the maximum value of used pages reached
Percent Used Used space in relation to the available space
AUTORESIZE Indicates if the tablespace is enabled for automatic resizing
Pending Free Pages Number of free pages that are pending
Displaying Tablespace Details
Note
The following information applies to automatic storage management and DMS/SMS tablespaces.
End of the note.
To display more information on the tables or indexes of a tablespace, select one or more tablespaces and choose Contents. The Space: Tablespace Content screen appears displaying the following information:
Column Description
Tablespace Name Name of the tablespace
Schema Name of the schema
Name Name of the table or index
Type Type of object, for example, index, primary index or table
Maintaining Tablespaces
In addition, you can maintain tablespaces, that is, Change, Add or Delete them. For more information, see Maintaining Tablespaces [page 101].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 101
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 Description
Tablespace Maintenance
Name Name of the tablespace
Database Partition Group
Name of the partition group where the selected tablespaces is defined
A partition group defines a set of partitions.
Space
Total Total space in KB
This information is not displayed when creating tablespaces.
Used Fill level of the selected tablespace as a percentage
This information is not displayed when creating tablespaces.
Free Free space in KB
This information is not displayed when creating tablespaces.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
102 September 2008
Technical Settings
The following are fixed values that cannot be changed:
Field Description
Contents Describes, which kind of data will be stored in the tablespace, for example, regular data, large objects, temporary user objects or temporary system objects
Size of I/O Units
Page Size Page size in KB
Extent Size Extent size in KB
Space Management by
Database (DMS) The space of the tablespace containers is managed by the database.
System (SMS) The space of the tablespace containers is managed by the file system.
AutoStorage All the tablespace space is managed by the automatic storage management.
You can enter values in the following fields:
Field Description
Size of I/O Units
Prefetch Size Number of pages to be prefetched
Disk Performance
Overhead 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.
Transfer Rate Time to read one page into memory in milliseconds
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 103
Field Description
AUTORESIZE enabled
Tablespace containers are automatically extended by using the file systems where the containers are located.
Buffer Pool
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 Description
Settings
Initial Size Initial space allocated when a tablespace is created
Size
Current Size Displays the current size
Last Resize Date and time of last automatic resize
Last Resize Terminated with SQL Error
Note
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
104 September 2008
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.
Maximum Size
You can enter one of the following:
o NONE
If there is no maximum size limit
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 105
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]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
106 September 2008
3.3 Space: Containers You can access information on containers by calling the DBA Cockpit and choosing Space
Containers in the navigation frame of the DBA Cockpit. The Container Configuration screen appears.
The following information is displayed:
Column Description
Tablespace Name Name of the tablespace
Partition Number of the partition (only displayed in a multi-partition database)
Stripe Set Number of the strip set the container belongs to
Container Name Name of the container in which the tablespace is located
Type Type of the container, for example, disk or file
KB Total Total size of the container in KB
Pages Total Total amount of pages
Accessible Indicates whether the container is accessible (YES) or not (NO)
FS ID File system ID
FS Free Size (KB) Free space in the file system in KB
Maintaining Containers
You can maintain tablespace containers by selecting a line in the table on the Container Configuration screen and choosing Change, Add or Delete. The Tablespace Maintenance screen appears.
For more information, see Maintaining Tablespaces [page 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 Description
Filters
Tablespace Name Indicates the location of the table
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 107
Field Description
Table Name Name of the table
Table Size Size of the table
Flagged Tables If this flag is not set, only tables are displayed that have a recommendation for table or index reorganization.
Large RIDs If this flag is set, only tables are displayed that are located in large RID tablespaces but that have not been enabled for large RIDs.
Not Available If this flag is set, only tables are displayed that have the status not available.
REORG Pending If this flag is set, only tables are displayed that have the status REORG PENDING.
Index Type-1 If this flag is set, only tables are displayed that still have Type–1 indexes.
Load Status If this flag is set, only tables are displayed that have the status LOAD PENDING.
Row Compression If this flag is set, only tables are displayed that have been recommended for row compression.
Display Options
Sort by Sorts the tables by Size or Name
Maximum Number of Rows Number of rows to be displayed
Example
To display the first hundred tables with the largest size, choose Size in the Display Options group box and enter 100 in the Maximum Number of Rows field.
End of the example.
When you have made your selections and chosen OK, the Space: Table and Indexes screen appears with the following information:
Column Description
Schema Schema of the table, usually the user who created the table
Table Name Name of the table
Tablespace Name Tablespace to which the table currently belongs
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
108 September 2008
Column Description
F1 Overflows rows as a percentage
F2 Table size divided by allocated space as a percentage
F3 Full pages divided by allocated pages as a percentage
Table Flagged Indicates that table reorganization is recommended
Index Flagged Indicates that table reorganization is recommended because of REORGCHK recommendations for at least one of the table indexes
Size (KB) Table size
REORG Check Date
Date of the last REORG check, for example, the date when RUNSTATS ran using program dmdb6srp
REORG Check Time
Time of the last REORG check, for example, the time when RUNSTATS ran using program dmdb6srp
If you want to change the selection, choose Set Selection Criteria. The Selection Criteria dialog box appears and you can make your new selection.
To display detailed information on tables and indexes, double-click a table or choose Details. A detail screen is displayed with information on tables, indexes and table structures. You can directly access this screen by choosing Space Single Table Analysis in the navigation frame of the DBA Cockpit. For more information, see Space: Single Table Analysis [page 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 109
The following information is displayed:
Table and Index Details
Field Description
Name Name of the table
Schema Schema of table, that is usually the user who created the table
Information Available on the Individual Tab Pages
The following tab pages are available on the Space: Tables and Indexes Details screen:
• Table
• Indexes
• Table Structure
• RUNSTATS Control
• Index Structures
• RUNSTATS Profile
• Table Status
• Compression Status
The information displayed on the individual tab pages is described in more detail in the following sections.
Table
Field Description
REORG Check Statistics
Last REORG Check Date and time of the last REORG check, for example, the date and time when RUNSTATS ran using program dmdb6srp
Total Table Size Size of table in KB
Total Index Size Size of all indexes of the table in KB
Free Space Reserved Percentage of free space reserved in the tables’ allocated pages
This free space is taken into account by LOAD and REORG.
F1: Overflow Rows Overflow rows as a percentage
F2: Table Size / Allocated Space Table size divided by allocated space as a percentage
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
110 September 2008
Field Description
F3: Full Pages / Allocated Pages Full pages divided by allocated pages as a percentage
REORG Pending Indicates whether a REORG is pending for the table
Last REORG of Table Date and time when the last REORG ran
Runtime of Last REORG Runtime of the last REORG
System Catalog
Last RUNSTATS Date and time when the last RUNSTATS ran
Tablespace Name of the tablespace to which the table belongs
Cardinality Number of data records in the table
Counted Rows Number of rows that have been counted by a SELECT(*) statement
This information is only displayed if you choose Count.
Deviation
Deviation of the number of rows provided by RUNSTATS in the system catalog from the number of rows provided by a SELECT COUNT(*) statement
This information is only displayed if you choose Count.
Overflow Records
Number of records that have overflowed
Records overflow when a data record is updated and the new data record is larger than the old one or when a column is added to a table.
No. of Pages with Data Number of pages containing data
Total Number of Pages Total number of pages in the table
Pooled, Cluster or Import/Export Table
Caution
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 111
VOLATILE
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 DB2’s automatic RUNSTATS. In addition, statistics data, if available, is not used by the optimizer.
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 Indicates whether value compression is enabled for the table
Row Compression Indicates whether the table is compressed
Distributed Statistics Indicates whether the table has a distributed statistics or not
Indexes
Field Description
Index
Name Name of the index
Schema Schema of the index, that is usually the user who created the index
Tablespace Name of the tablespace to which the index belongs
Type Index type
REORG Check Statistics
Last REORG Check Date and time of the last REORG check, for example, the date and time when RUNSTATS ran using program dmdb6srp
Indexes Require Rebuild Indicates whether an index requires rebuild or not
Cardinality Number of entries in the index
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
112 September 2008
Field Description
Free Space Reserved Percentage of free space reserved in the index pages
This free space is taken into account by LOAD and REORG.
F4: Cluster Ratio Cluster ratio as a percentage
F5: Index Size / Allocated Space Index size divided by allocated space as a percentage
F6: No. Entries / No. Poss. Entries
Number of entries divided by the number of possible entries as a percentage
F7: Ratio of Deleted Index Entries Number of deleted entries in relation to total entries in index
F8: Ratio of Deleted Index Leafs
Number of deleted tree leafs in relation to total tree leafs of index tree
System Catalog
Last RUNSTATS Date and time when the last RUNSTATS ran
Number of Leaves Number of index leaves
Number of Levels Number of index levels
Sequential Pages Number of index leaves physically located on the hard disk sorted by index without large intervals between them
Density Relative density of the sequential pages as a proportion of the total number of index pages
100 % is the optimum value.
Cluster Ratio Degree of fragmentation of the index (100 % means no fragmentation and is the optimum value)
Cluster Factor Not currently calculated
The value is set to –1.
First Key Cardinality Number of different values in the first column of the index
First 2 Key Cardinality Number of different values in the first two columns of the index
First 3 Key Cardinality Number of different values in the first three columns of the index
First 4 Key Cardinality Number of different values in the first four columns of the index
Full Key Cardinality Number of different values in all columns of the index
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 113
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 Description
DB Column No. Number of the column in the database
DB Column Name Name of the column in the database
DB Type Data type of the column in the database
DB Length Length of the column in the database
The following information is only displayed for the local system and if the table is defined as a transparent table in the ABAP Dictionary:
Column Description
SAP Column Name Name of the column defined in the ABAP Dictionary
SAP Key Column is part of primary key defined in the ABAP Dictionary
SAP Type Data type of the column defined in the ABAP Dictionary
SAP Length Length of the column defined in the ABAP Dictionary
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
114 September 2008
RUNSTATS Control
For RUNSTATS Control, you have to take the following into consideration:
• Scheduling of RUNSTATS for a table
• Which types of statistics are gathered
Both scheduling and profiling depend on the configuration of automatic RUNSTATS. If automatic RUNSTATS is enabled, the following scheduling options are available:
Field Description
Statistics Attributes
Not VOLATILE (AutoRUNSTATS included)
The VOLATILE attribute is not set for this table and therefore the table will get statistics controlled by automatic RUNSTATS.
VOLATILE (AutoRUNSTATS excluded)
The VOLATILE attribute is set for this table. automatic RUNSTATS does not take this table into account.
If automatic RUNSTATS is not enabled, the following options are available instead:
Field Description
Scheduling
Automatically Statistics and REORGCHK calculations are gathered by CCMS jobs that are scheduled in the DBA Planning Calendar [page 169].
On User Request CCMS jobs do not process these tables automatically, that is RUNSTATS and REORGCHK must be explicitly scheduled by the user.
Statistics is out-of-date
Due to the monitored number of update activities, the statistics might be out-of-date. As a consequence, a RUNSTATS is recommended.
Deviation Deviation of the current size (cardinality) in the table statistics from the size that was estimated based on the monitored number of update activities
Collect Data for Application Monitor The table is monitored by the application monitor ST07.
Statistics Attributes
Statistics Statistics are gathered for this table. As soon as there are valid statistics the table will be marked as NOT VOLATILE in the system catalog.
No Statistics and Volatile The table is marked as VOLATILE and has no statistics.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 115
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 Description
Basic Basic statistics for the table
Distributed Statistics Distributed statistics for the table
None
No statistics for the table
Caution
Selecting this option does only freeze already existing old table statistics but not delete or invalidate them.
End of the caution.
Sampling of [ ] %of entries
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.
System (Page, Sampling)
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.
BERNOULLI (Row Sampling)
The data to be sampled is selected row by row.
Caution
This field is only active if you are using DB2 UDB for UNIX and Windows Version 8, FixPak 2 or higher.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
116 September 2008
Field Description
End of the caution.
Analyze Key Columns only Table statistics are gathered only for key columns of the table.
Index Analysis Method
Basic Basic statistics for the index
Detailed Statistics Detailed statistics for the index
Detailed Sampled Statistics Detailed statistics for the index using sampling
None
No statistics for the index
Caution
Selecting this option does only freeze already existing old index statistics but not delete or invalidate them.
End of the caution.
Index Structures
Column Description
Position Position of the column within the key
Order
Sort order of the column:
• A = ascending order
• D = descending order
DB Column Number Number of the column in the database
DB Column Name Name of the column in the database
DB Type Data type of the column in the database
DB Length Length of the column in the database
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 117
Note
The following information is only displayed for the local system and if the table is defined as a transparent table in the ABAP Dictionary:
Column Description
SAP Column Name Name of the column defined in the ABAP Dictionary
SAP Type Data type of the column defined in the ABAP Dictionary
SAP Length Length of the column defined in the ABAP Dictionary
End of the note.
If several indexes are defined on a table, you can use the page buttons on Index Structures to navigate between them.
RUNSTATS Profile
If a RUNSTATS was executed using the PROFILE option, this profile is stored in the system catalog and is displayed on the screen. The profile is the same as the RUNSTATS command that was executed with the SET PROFILE option.
Table Status
On this tab page, you find information about the size and status of tables and indexes provided by DB2's stored procedure ADMIN_GET_TABINFO:
Field Description
Physical Size
Data Objects
Amount of disk space in KB that is physically allocated for the table
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.
Long Objects Amount of disk space in KB that is physically allocated for long field data in a table
LOB Objects Amount of disk space in KB that is physically allocated for long field data in a table
XML Objects Amount of disk space in KB that is physically allocated for XML data in a table
Index Objects Amount of disk space in KB that is physically allocated for the indexes
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
118 September 2008
Field Description
Logical Size
Data Objects
Amount of disk space in KB that is logically allocated for the table
For MDC tables, this size includes the logical size of the block map object. This size represents the logical size of the base table only. Space that is consumed by LOB data, long data indexes and XML objects is reported by other fields described in the following.
Long Objects Amount of disk space in KB that is logically allocated for long field data in a table
LOB Objects Amount of disk space in KB that is logically allocated for long field data in a table
XML Objects Amount of disk space in KB that is logically allocated for XML data in a table
Index Objects Amount of disk space in KB that is logically allocated for the indexes
Availability and Other Technical Information
Available
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.
• YES
The table is available.
Note
Rollforward through an unrecoverable load makes a table unavailable.
End of the note.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 119
Inplace REORG Status
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
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.
Large RIDs
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.
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
120 September 2008
Large Slots
Indicates whether or not the table is using large slots (which allows more than 255 rows per page)
• YES
The table is using large slots.
• NO
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.
Type of Statistics
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.
• System asynchronously gathered
Statistics are gathered asynchronously by the system
The statistics have been collected automatically by DB2 by a background process and stored in the system catalogs.
• System synchronously gathered
Statistics are gathered synchronously by the system
• User gathered
Statistics are gathered by the user
• Undef
Unknown type or information that is not available for the current database release
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 121
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 Description
Compression Detail
Current Dictionary Size Current size of compression dictionary in bytes
Average Length of Compressed Rows Average length of compressed records in bytes
Average Compression Ratio by Row Average compression ratio by row
Average Length of Compressed and Uncompressed Rows
Average length of all rows (compressed and uncompressed) in bytes
Percentage of Compressed Rows from Total Number of Rows
Percentage of compressed rows compared to total number of rows
Approximate Percentage of Pages Saved (excl. LOBS)
Percentage of pages saved by compression
Note
Only data pages are taken into account.
End of the note.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
122 September 2008
Compression Check Results
Estimated Dictionary Size Estimated size of compression dictionary in bytes if table will be compressed
Estimated Saved Pages Estimated amount of pages in percent that will be saved after compression
Estimated Saved Bytes Estimated amount of bytes in percent that will be saved after compression
Rows too Small Number of rows that were too small to be used for compression calculation
Last Check Date and time of last compression check
Checking and Updating the Statistics
You can check the quality of the statistical information in the system catalog by entering a 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 123
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
124 September 2008
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 Empty
o Not volatile
o Does not have a partitioning key
o 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 125
The following information is displayed:
Databases and Tablespaces
Field Description
Tablespaces
Last Analysis Date and time of the last analysis
Total Number Total number of tablespaces in the database
Total Size Total size of all tablespaces in KB
Free Space Free space in all tablespaces in KB
Used Space Used space of all tablespaces as a percentage
Minimum Free Space in a Tablespace
Free space of the tablespace with the lowest amount of free space in KB
Maximum Used Space in a Tablespace
Used space of the tablespace with the highest fill level as a percentage
Database Partitions
Total Number Number of database partitions
The value displayed is only higher than 1 if you are using a multi-partition database.
Tables and Indexes
Field Description
Last Analysis Date and time of the last analysis
Total Number of Tables Total number of tables defined in the database
Total Size of Tables Total amount of used space of all tables defined in the database
Total Number of Indexes Total number of indexes defined in the database
Total Size of Indexes Total amount of used space of all indexes defined in the database
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
126 September 2008
Oldest REORG Check
Date and time of the oldest execution of the job REORGCHK for all tables
Latest REORG Check 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 Description
Tablespace Name
Name of the tablespace (only displayed if you have selected Tablespaces in the Object Selection field)
Partition Monitored partition - displayed only if you are using a multi-partition database
KB Total Amount of space in KB allocated
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 127
Column Description
Changes (KB Total)
Average change of KB Total
The average value depends on your selection in the Statistics field.
KB Used Used space in KB of the allocated space
Changes (KB Used) Average change of used space
% Used Percentage used of allocated space
KB Free Free space in KB of allocated space
Containers Number of containers belonging to the tablespace
Changes Containers Average change of number of containers
Tables and Indexes
Tables and Indexes
Column Description
Tablespace Name
Name of the tablespace (only displayed if you have selected Tablespaces in the Object Selection field)
Tables Number of tables
Changes Tables Average change of number of tables
Table (KB) Space used by tables
Changes Table (KB) Average change of space used by tables
Indexes Number of indexes
Changes Indexes Average change of number of indexes
Index (KB) Space used by indexes
Changes Index (KB) Average change of space used by indexes
If you want to display delta values between available measurements, select a row and choose Details. Alternatively, you can double-click the selected row. The table will be displayed again with the following difference: Columns with the heading Changes... are renamed with Delta...
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
128 September 2008
3.9 Space: History - Tables and Indexes Note
This function is only available if you have selected Collect History Data during the configuration of your database for remote monitoring. For more information, see Configuring Systems for Remote Monitoring Using Remote Database Connections.
End of the note.
You can access history data on tables and indexes by calling the DBA Cockpit and choosing Space History Tables and Indexes in the navigation frame of the DBA Cockpit.
A Set Selection Criteria dialog box appears in which you can limit the result set displayed according to the following criteria:
Field Description
Filters
Tablespace Name Name of the tablespace
Table or Index Name Name of the table or index
Table or Index Size Size of the table or index
Display Options
Sort by Sorts the tables or indexes by Growth, Size or Name
Maximum Number of Rows Number of rows to be displayed
Example
To display the first hundred tables or indexes with the highest growth, choose Growth in the Display Options group box and enter 100 in the Maximum number of rows field.
End of the example.
When you have made your selections and chosen OK, the History – Table and Index screen appears with the following information:
Column Description
Object Name Name of the table or index
Object Type Table or index
Tablespace Name Tablespace to which the objects belong
Size (KB) Size of the table or index
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 129
Column Description
Changes Size (KB) Average change of space used by table or indexes
REORG Check Date
Date of the last REORG check, for example, the date when RUNSTATS ran using program dmdb6srp
REORG Check Time
Time of the last REORG check, for example, the time when RUNSTATS ran using program dmdb6srp
If you want to display delta values between available measurements, select a row and choose Details. Alternatively, you can double-click the selected row. The table will be displayed again with the following difference: Columns with the heading Changes... are renamed with Delta...
If you want to change the selection criteria, choose Set Selection Criteria.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
130 September 2008
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
Database Backups
Contains information on 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.
Log Files Contains information on log files that have been moved from the log directory to the log archive or to a storage product, such as Tivoli Storage Manager (TSM)
If you want to display older information on database backups, change the value in the Display Days field in the Backup and Recovery: Overview group box.
4.2 Backup and Recovery: Logging Parameters You can access information on logging parameters by calling the DBA Cockpit and choosing
Backup and Recovery Logging Parameters in the navigation frame of the DBA Cockpit. The Logging Parameters screen appears.
This screen provides information on the logging parameters configured, such as size of log files, log retain status or user exit status. Furthermore, you can check the available space of the file systems where your database logs and the archived database logs are stored.
However, these directories are only displayed in the lower half of the screen if the monitored systems are SAP ABAP systems.
Caution
In a production system, the User Exit for Logging Status field must be set to YES.
If this is not the case, you risk losing data and the ability to roll forward your database if serious database problems occur.
End of the caution.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 131
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 Description
Database Instance
Name Name of the database instance
Partitionable Indicates whether or not the current instance is a partitionable database server instance
Number of Partitions
Number of database partitions
If the database environment is not partitioned, the value is 1.
Address Space Size of the current database instance in Bit (32 or 64)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
132 September 2008
Database Release
DB2-internal release number, as it is returned if you use the db2level command, for example, 03030106
Service Level Service level, as it is returned if you use the db2level command, for example, DB2® v8.1.1.80
Build Level Build level, as is returned if you use the db2level command, for example, n041021
PTF Program temporary fix (PTF) identifier, as it is returned if you use the db2level command, for example, U498350
Fix Pack Fix Pack number, as it is returned if you use the db2level command, for example, 9
Operating System
Name Name of the operating system
Version Version number of the operating system
Release Release number of the operating system
Host Name Name of the system
Total CPUs Total number of physical CPUs of the system
Configured CPUs Number of configured physical CPUs of the system
Total Memory Total amount of memory 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 Description
HADR Information
Connect Status
The current HADR connection status of the database
The following values are possible:
• CONGESTED
• CONNECTED
• DISCONNECTED
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 133
Local Host Local HADR host name
The value is displayed as a host name string or an IP address string, for example, 1.2.3.4.
Local Service Local HADR TCP service
The value is displayed as a service name string or a port number string.
Log Gap 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
Primary Log LSN Current log position of the primary HADR database
The log sequence number (LSN) is a byte offset in the log stream of the database.
Primary Log Page
Page number in the current log file indicating the current log position on the primary HADR database
The page number is relative to the log file, for example, page zero is the beginning of the file.
HADR Syncmode
The current HADR synchronization mode of the database
The following values are possible:
• ASYNC
• NEARSYNC
• SYNC
HADR Timeout Number of seconds without any communication from its partner server after which an HADR database server will consider that the connection between them has failed
Heartbeat Number of missed heartbeats on the HADR connection
If the database is in HADR primary or standby role, this element indicates the health of the HADR connection.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
134 September 2008
Connect Time
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
• 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.
Remote Host Host name of the HADR remote host
The value is displayed as a host name string or an IP address string, for example, 1.2.3.4.
Remote Instance Name of the HADR remote instance
Remote Service Remote HADR TCP service
This value is displayed as a service name string or a port number string.
HADR Role
Current HADR role of the database
The following values are possible:
• PRIMARY
• STANDARD
• STANDBY
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 135
HADR State
Current HADR state of the database
The following values are possible:
• DISCONNECTED
• LOCAL_CATCHUP
• PEER
• REM_CATCH_PEN
• REM_CATCHUP
Standby Log File Name of the current log file on the standby HADR database
Standby Log LSN Current log position of the standby HADR database
Log sequence number (LSN) is a byte offset in the log stream of the database.
Standby Log Page
Page number in the current log file indicating the current log position on the standby HADR database
The page number is relative to the log file, for example, page zero is the beginning of the file.
5.2 Configuration: Database Manager You can access information about the configuration of the database manager by calling the DBA Cockpit and choosing Configuration Database Manager in the navigation frame of the DBA Cockpit. The Configuration: Database Manager screen appears.
The following information is displayed as a tree structure:
Tree node Description
Common Common information about the database manager, for example, release level and CPU speed
Diagnostics Information about diagnostics
Default Monitor Switches Information about the default monitor switches of the database
Security - Groups Information about user groups of the database manager
Security – Authentication
Information about authentications of the database manager and on clients
Memory Information about the memory of the database manager
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
136 September 2008
Tree node Description
Agents Information about agents
Application Remote Interface Information about the database application remote interface (DARI)
Sync Point Manager Information about the configuration of the synchronization manager and the transaction manager
Transaction Manager Information about the transaction manager
Network Information about network characteristics such as communication protocols
Fast Communication Manager
Information about the Fast Communication Manager (FCM), that is, the configured communication in a multi-partition database
DB2 Discovery Information about the configuration of the discovery mode
Others Single parameters that are not accessible to the groups described above as well as parameters that are not known by the DBA Cockpit, for example, those of new database release
The database manager parameters are displayed with a short description and the technical name that was defined by DB2. If you need to change a parameter, use the following command:
UPDATE DATABASE MANAGER CONFIGURATION using <keyword> <value>
Note
In a multi-partition environment, the database manager parameters are the same for all partitions. Therefore, All is displayed in the Partition field in the Database Manager Configuration group box.
End of the note.
For more 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].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 137
5.3 Configuration: Database You can access information on database configuration by calling the DBA Cockpit and choosing Configuration Database in the navigation frame of the DBA Cockpit. The Configuration: Database screen appears.
The following information is displayed as a tree structure:
Tree node Description
Common Common information about the database, for example, release level and country code
Automatic Maintenance Information about the automatic maintenance switches
Optimization Information about optimization
I/O Information about I/O
Self-Tuning Memory Manager Information about the self-tuning memory manager
Database Shared Memory Information about the memory that is available for the database
Application Memory Information about the memory that is available for the application
Logging Information about log files and logging parameters
Log File Management Information about log file management parameters
Backup & Recovery Information about recovery availability and backups
TSM Information about Tivoli Storage Management (TSM)
Locks Information about locks, for example, the percentage of lock lists per application
Space Information about containers and tablespaces
Applications Information about applications that connect to the database
DB2 Data Links Manager Information about the DB2 Data Links Manager (DB2 Version 8 only)
High Availability Information about the system configuration is only displayed if you are running a high availability system.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
138 September 2008
Tree node Description
Others Single parameters that are not accessible to the groups described above as well as parameters that are not known by the DBA Cockpit, for example, those of a new database release
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 139
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
140 September 2008
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 Description
Parameter Active Displays the current values of the parameters
Parameter History Displays all recorded parameter changes made in the past
Parameter Type All Displays both database manager and database parameters
Parameter Type Database Displays database parameters only
Parameter Type DB Manager
Displays database manager parameters only
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 141
Option Description
Parameter Type Registry Displays registry variables only
When you have made your selection, the following information is displayed:
Column Description
Parameter Type
Defines whether the parameter is a database manager parameter or a database parameter
Parameter Name
Parameters in upper case indicate that the parameter is modifiable using DB2 CLP. Parameters in lower case indicate that the parameter is maintained by DB2 (read-only).
Partition Monitored partition – displayed only if you are using a multi-partition database
Date Date of the change
Time Time of the change
Parameter Value Value of the parameter currently set or set in the past
5.6 Configuration: Database Partition Groups You can access information on available database partition groups by calling the DBA Cockpit and choosing Configuration Database Partition Groups in the navigation frame of the DBA Cockpit. The Configuration: Database Partition Groups screen appears.
The following information is displayed:
Column Description
Database Partition Group Name of the database partition group
Partition Number of the partition
Status
Current status of the partition
The following values are possible:
• Status information not available
Displayed for database partition group IBMTEMPGROUP or if the status cannot be determined
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
142 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 143
Field Description
Partition Number of the partition
Status
Current status of the partition
The following values are possible:
o Status information not available
Displayed for database partition group IBMTEMPGROUP or if the status cannot be determined
o Partition not in partitioning map; containers not yet created
Partition has been created without containers and is not yet referenced in the partitioning map.
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 Partition in partitioning map; containers created
o 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 Description
Buffer Pool Name
Total space in KB
If you create tablespaces, this information is not displayed.
Buffer Pool Size (KB)
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).
Page Size Size of one buffer pool page in bytes
For detailed information on buffer pools, double-click the corresponding buffer pool.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
144 September 2008
Tablespaces
This tab page contains a list of all tablespaces that have been defined for the selected database partition group.
Field Description
Tablespace Name Name of the tablespace
Page Size Size of one tablespace page in bytes
For detailed information on tablespaces, double-click the corresponding tablespace.
2. To confirm your entries, choose Execute.
3. To apply changes, choose Partitions.
4. You can now add or delete partitions:
o To add partitions, choose Add Partition.
The system automatically suggests a new partition that has not yet been defined in the database partition group. You can modify this suggestion by manually selecting another partition.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 145
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
146 September 2008
5.7 Configuration: Buffer Pools You can access information on available buffer pools by calling the DBA Cockpit and choosing Configuration Buffer Pools in the navigation frame of the DBA Cockpit. The Configuration: Buffer Pools screen appears.
The following information is displayed:
Column Description
Buffer Pool Name Name of the buffer pool
Partition Number of the partition (only displayed if you are using a multi-partition database)
Size (Pages)
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).
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
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 147
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
Partition
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 (Pages) Displays the buffer pool size in pages or the value AUTOMATIC
Immediate Indicates that the buffer pool is created or changed immediately and not after the next system restart.
Field Description
Set size of all partitions to... (Pages)
Specifies the buffer pool size on all partitions
Note
This function is not supported for buffer pools that are enabled for DB2's self–tuning memory management
End of the note.
Page Size Size of one page in the buffer pool
Block Size Size of one block for blocked I/O in pages – displayed only if you are using DB2 Version 8
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
148 September 2008
Number of Block Pages Number of pages that are reserved for block I/O usage – displayed only if you are using DB2 Version 8
Use automatic buffer pool size on all database partitions starting with
Specifies that the buffer pool size is automatically maintained by DB2. You are able to specify a starting value regardless if the automatic buffer pool size was enabled before or if you are only 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 Description
Tablespace Name Name of the tablespace
Page Size Size of one tablespace page in bytes
For detailed information on tablespaces, double-click the corresponding tablespace.
For more information about tablespace maintenance, see Maintaining Tablespaces [page 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 149
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
150 September 2008
On the basis of the list displayed, you can check system catalog-related information against the DBSTATC control table.
The following information is displayed on the Configuration: Special RUNSTATS Settings and Volatile Tables screen:
Column Description
Table Schema Name of the schema to which the table belongs
Table Name Name of the database table
VOLATILE
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.
Active
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.
• 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 Indicates whether a RUNSTATS profile was set for the table
RUNSTATS Date Date of the last RUNSTATS in the system catalog table
RUNSTATS Time Time of the last RUNSTATS in the system catalog table
Cardinality Number of rows as calculated by the last RUNSTATS (–1 indicates that there are no statistics available)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 151
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 Description
Partition Number of the partition (only displayed if you are using a multi-partition database)
File System Name
Name of the file system
Both local and NFS file systems are displayed.
KB Total Total size of the file system in KB
KB Used Total amount used of the file system in KB
Percentage Used Used percentage of total size of the file system
KB Free Total amount free of the file system in KB
Percentage Free Free percentage of total size of the file system in KB
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
152 September 2008
Inodes Used Number of 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 Description
State
• Green:
No action required
• Yellow:
Indicates warnings
Recommendation
We strongly recommend that you take immediate action.
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?
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 153
Column 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?
Data Class Name of the data class known to the ABAB Dictionary
Data Tablespace Name of the tablespace where table data is stored
Index Tablespace Name of the tablespace where table indexes are stored
No. of Tables Number of tables within the related data tablespace
No. of Indexes Number of indexes within the related index tablespace
Category Category of the data class
Description Description of the data class
In addition, you can maintain data classes, that is, change, add or delete them. For more information, see Maintaining Data Classes [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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
154 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 155
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
156 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 157
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 Configuration Automatic Maintenance Settings in the navigation frame.
The screen Configuration: Automatic Maintenance Settings appears.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
158 September 2008
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
o Time of Automatic Maintenance
(Specifies the maintenance window directly or inverted.)
o Time
o Day of Week
o Day of Month
o 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 Configuration Automatic Maintenance Settings in the navigation frame.
The screen Configuration: Automatic Maintenance Settings appears.
3. Choose Automatic Backup.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 159
4. Specify the following parameters:
Parameter Description
General
Automatic backup is switched on / off Enables or disables the automatic backup function
Backup Operation Type
Specifies the type of backup (online or offline)
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.
Priority
Specifies the priority of the automatic backup over the other automatic maintenance features such as Automatic RUNSTATS or Automatic REORG
Note
1 means highest priority.
End of the note.
Starting Conditions
Optimize for Database Recoverability
Backups are created more frequently. Therefore, less time is required to recover the database. The following limits apply:
o Maximum time between backups: 1 day
o Maximum log space used between backups: 10 MB
Balance Between Recoverability and Performance
Indicates the balance between the number of backups and the time for recovery.
The following limits apply:
o Maximum time between backups: 7 days
o 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 Maximum time between backups: 30 days
o Maximum log space used between backups: 50 MB
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
160 September 2008
Customize
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
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 exceeds
If the time – since the last backup – exceeds the specified value, a backup is created.
Log space used since last full backup is more than If the log space exceeds the specified value, a backup is created.
Backup Media
File System The backup is created in the specified file systems.
If you choose File System, you also have to specify File Paths where the backup is to be created.
Tape Device The backup is created on tape.
If you choose Tape Device, you also have to specify the Number of Parallel Sessions.
TSM The backup is created and stored in IBM Tivoli Storage Manager (TSM).
If you choose TSM, you also have to specify File Paths.
XBSA The backup is created using the XBSA API for storing the data.
If you choose XBSA, you also have to specify the Number of Parallel Sessions.
Vendor Library
The backup is created and data is stored using a 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 161
5.12.3 Configuring Automatic RUNSTATS Settings 1. Call the DBA Cockpit.
2. Choose Configuration Automatic Maintenance Settings in the navigation frame.
The screen Configuration: Automatic Maintenance Settings appears.
3. Choose Automatic RUNSTATS.
4. You can set the following parameters:
Parameter Description
General
Automatic RUNSTATS is switched on / off Enables or disables the automatic RUNSTATS function
Maintenance Window Specifies that automatic RUNSTATS can only be performed in the online maintenance window
Priority
Specifies the priority of the automatic RUNSTATS over the other automatic maintenance features, such as Automatic REORG or Automatic Backup.
Note
1 means highest priority.
End of the note.
Parameters
SAP Default Criteria for Tables Excluded by Policy
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.
Note
A full editor for these filter criteria is not provided.
End of the note.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
162 September 2008
In addition, the following information is displayed for tables that are excluded from RUNSTATS:
Column Description
Tables Excluded from RUNSTATS
The excluded tables are divided into the following categories:
• Volatile Tables
Volatile tables are always excluded from automatic RUNSTATS. When you expand this node, the volatile tables are displayed.
• Tables Excluded 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
Volatile
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.
Profile Indicates whether a RUNSTATS profile was set for the table
RUNSTATS Date Date of the last RUNSTATS in the system catalog table
RUNSTATS Time Time of the last RUNSTATS in the system catalog table
Cardinality Number of rows as calculated by the last RUNSTATS (–1 indicates that there are no statistics available)
5.12.4 Configuring Automatic REORG Settings The automatic REORG checks regularly if tables or indexes require reorganization. This check is performed by the REORGCHK. The tables are always defragmented during the offline maintenance window. Only for indexes, you are able to specify if a reorganization is to be performed during the online or offline maintenance window.
Procedure
1. Call the DBA Cockpit.
2. Choose Configuration Automatic Maintenance Settings in the navigation frame.
The screen Configuration: Automatic Maintenance Settings appears.
3. Choose Automatic REORG.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 163
4. You can set the following parameters:
Parameter Description
General
Automatic REORG is switched off Enables or disables automatic REORG function
Index Reorganization Mode
Specifies a maintenance window for index reorganization.
Recommendation
We recommend that you reorganize indexes during the online maintenance window.
End of the recommendation.
Priority
Specifies the priority of the automatic REORG over the other automatic maintenance features, such as Automatic RUNSTATS or Automatic Backup.
Note
1 means highest priority.
End of the note.
Parameters
SAP Default Criteria for Tables Excluded by Policy
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
164 September 2008
Use a System Temporary Tablespace with Compatible Page Size
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.
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.
Maximum Table Size
Specifies the tables that are excluded from the automatic REORG because of their size
Recommendation
We recommend a maximum table size filter of 1,000,000 KB.
End of the recommendation.
Compression Data Dictionary
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.
Recommendation
We recommend that you rebuild the compression data dictionary.
End of the recommendation.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 165
In addition, the following information is displayed for tables that are excluded from an automatic REORG:
Column Description
Tables Excluded from REORG
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 by Size
When you expand this node, the tables with a size larger than the threshold are displayed.
Determining the table sizes online is much too expensive. To get the sizes of the tables, you have to schedule the job REORGCHK for all Tables in the DBA Planning Calendar.
Schema Name of database schema to which the table belongs
Table Flagged Indicates the table to be reorganized
Index Flagged Indicates the indexes to be reorganized
Table Size (KB) Size of table in KB
REORG Date Date when table was last reorganized
REORG Time Time when table was last reorganized
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
166 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 167
• 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 double-clicking 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
168 September 2008
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 FUD 2
4 FIB 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 Status
Light blue Planned
Dark blue Running
Green Finished successfully
Yellow Finished with warning
Red Finished with error
Dark yellow No longer available
Dark red Scheduling failed
2. To see a summary of the actions for a day, double-click the day header.
The system displays a summary of the actions and status for each system on the day you selected.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 169
5. To refresh the display for all systems, choose Remote Refresh.
You can remotely refresh the display as follows:
Method How the Refresh Runs
Run in Dialog Runs in dialog mode, which can take a long time, so not normally recommended
Start immediately Runs immediately in the background as a job
Schedule at Runs in the background at the time that you specify
We recommend that you schedule action Central Calendar Log Collector to run regularly, as described above in “Prerequisites”.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
170 September 2008
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 RFC-monitored 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 171
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 Actions Involved
Backup and recovery of the database
Note
The actions involved have an impact on the availability of the database.
End of the note.
• Full Database Backup into TSM
• Full Database Backup to Device
• Full Database Backup with Vendor Library
• Archive Log File to Tape
Running statistics for tables
Note
These actions are only available if the automatic RUNSTATS by DB2 is disabled.
The actions involved have an impact on the database performance.
End of the note.
• RUNSTATS and REORGCHK (DBSTATC)
• RUNSTATS and REORGCHK for All Tables
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
172 September 2008
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 top-bottom 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 left-right split view layout is available.
To change your preferred settings – that is, the layout and the view – choose Save Settings.
The calendar shows the actions that were scheduled using background processing. These actions are then automatically executed.
End of the note.
Once the action has run, the status is indicated using the following colors:
Color Meaning
Light blue The action has not yet started.
Dark blue The action has not yet finished.
Green The action has run successfully.
Yellow The action has finished with a warning.
Check the job log for details.
Red An error has occurred and the action was interrupted.
Check the job log for details and reschedule the action.
Dark yellow No more information is available.
Dark red Scheduling failed, that is, there is no status available and the action is overdue.
You can display the meaning of each color by choosing Legend.
Drag & Drop of Actions
You can move or copy actions within the calendar by using the drag & drop function.
More Information
Setting up the DBA Planning Calendar [page 173]
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 173
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
174 September 2008
• 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 Jobs DBA 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 175
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 Day’s 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 Double-click a calendar cell.
o Position the cursor on a calendar cell and choose Add.
o 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
176 September 2008
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
Recurrence Pattern
Interval for the action in weeks, days or hours
Depending on the selected recurrence pattern, you need to specify the pattern in more detail, that is, the days of the week for weeks and the hours of the day for a daily period. The action is repeated at the interval you enter. If you select Once only, the action is executed only once.
Recurrence Range
Range of time where the action recurs, that is for a specific time interval or for a limited number of occurrences
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 177
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 Jobs DBA Planning Calendar in the navigation frame of the DBA Cockpit.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
178 September 2008
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 Day’s 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 179
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
180 September 2008
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 DB2’s 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 181
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
182 September 2008
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
All Tables Specifies that the job is called for all tables
By default, this parameter is selected.
Selected Tables
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.
Note
Only choose this option if you require an up-to-date analysis for the selected tables.
End of the note.
With Compression Check
Analyzes the tables and checks for candidates to be compressed
By default, you should not activate this option on for the REORGCHK job that is scheduled weekly. For performance reasons, only perform compression checks in larger time-frames.
Minimum Table Size for Check
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 183
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 Description
Table Schema Name of the schema to which the table belongs
Table Name of the table
Offline
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
184 September 2008
Parameter Description
End of the note.
Online Schedules an online reorganization of the table
All Indexes 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 Description
Backup Mode
Online Access to the database is not blocked. The users can continue to work normally during the backup.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 185
Offline
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.
Incremental A cumulative (that is, incremental) backup image
An incremental backup image is a copy of all database data that has changed since the most recent successful full backup operation.
Incremental Delta
A non-cumulative (that is, delta) backup image
A delta backup image is a copy of all database data that has changed since the most recent successful backup operation.
Additional options
Compress The backup is to be compressed.
Include Logs
Note
Only choose this option if you want to perform an online backup.
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
186 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 187
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
188 September 2008
Note
The DB2 tape manager is used to archive log files to tape. Besides the standard parameters (for example, start time, date, number of log files to be saved and tape label), you can also specify the option of the tape manager to use for archiving log files:
o Double Store
o Overwrite Expired Tapes
o 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 189
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 Jobs DBA Log in the navigation frame of the DBA Cockpit.
The following information is displayed on the Jobs: DBA Action Log screen:
Column Description
Start Date Start date of action
Start Time Start time of action
End Date End date of action
End Time End time of action
Runtime Runtime in HH:MM:SS
Action Description of action
Return Code Return code of action
When you access the DBA log for the first time, the system displays the log information for the current week.
If you want to display information on previous weeks, double-click a day in the corresponding week in the calendar control.
If you only want to display certain log records, choose one of the following icons:
Icon Meaning
Total Total number of all log records
Errors Displays jobs that finished with an error. These jobs should be executed again
Warnings Displays jobs that finished with a warning
OK Displays log records of jobs that were completed without errors
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
190 September 2008
6.4 Back-End Configuration You can configure the back end of the DBA Planning Calendar to control the execution of background jobs. You can configure the back end for all systems, for selected database platforms, or for single systems only.
The system is configured by using the first available configuration from the following:
1. The system-specific configuration
2. The configuration for the database platform
3. The configuration valid for all platforms
4. The standard configuration – current user, selection of background server by background dispatcher, high priority
Configuration Steps
1. Call the DBA Cockpit and choose Jobs Back-End Configuration .
Note
Alternatively, choose Goto Back-End Configuration from the menu in the DBA 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
Background Server
Specifies the server, where scheduled jobs are executed
If no server is specified, the background job dispatcher dynamically selects the server.
Job Priority Specifies the priority of the job
If no priority is specified, jobs run with default priority (medium).
User Name of the user to execute the job
If no user is specified, the dialog user is used.
4. Save your changes.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 191
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
192 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 193
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 Access behavior of database buffers
o Lock behavior of the application, monitoring of deadlock situations and lock escalations
• Availability of backup and recovery mechanisms
o Last available backup
o Availability of the log files necessary to achieve the current state of the database from the last available backup.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
194 September 2008
• 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 195
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 List Selected Entries Edit (or Edit in the application toolbar).
The Monitoring: Tool Administration screen appears.
5. Choose Parameter.
6. Choose Tool Definitions Display Change (or Display Change in the application tool bar).
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 Method Execution Activate Background 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].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
196 September 2008
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 Alerts Alert Monitor in the 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 197
The checked parameters are displayed in the following colors depending on the type of message:
Message Type Color
Information Green
Warning Yellow
Error Red
Note
If a check resulted in a warning or an error, a short text is additionally displayed next to the parameter.
End of the note.
7.4 Alerts: Alert Message Log You can access an overview of the results of system monitoring by calling the DBA Cockpit and choosing Alerts Alert Message Log in the navigation frame of the DBA cockpit. The Alerts: Alert Message Log screen appears.
Only the most important data is displayed in the overview. The results are displayed as notes, warnings or errors and are ordered by log date as default.
You can use the list boxes in the Current Selection group box to limit the display to specific error levels, check categories, or partitions (only for multi-partition database systems). The 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
198 September 2008
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 Space management
o Performance
o Backup/restore
o SAP consistency
o Health
The checked parameters are displayed in the following colors depending on the type of message:
Message Type Color
Information Green
Warning Yellow
Error Red
If a check resulted in a warning or error, a short text is additionally displayed next to the parameter in the Open alerts view.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 199
7.5 Alerts: Alert Configuration DB2 database system monitoring has preconfigured check categories and parameters.
Caution
Only experienced users should make changes to the system check configuration.
End of the caution.
The initial screen of the database-specific configuration provides you with an overview of all the configuration entries.
You can access alert configuration by calling the DBA Cockpit and choosing Alerts Alert Configuration in the navigation frame of the DBA Cockpit. The Alert Configuration Overview screen appears.
On this screen, you can display details, sort entries, and make selections using the list boxes. In addition, you can activate or deactivate an entry by selecting the corresponding cell in the Active column.
Caution
If you deactivate an entry, there is no further notification of corresponding alerts.
End of the caution.
If you want to configure additional parameters, you can double-click a cell in the table or select a line and choose Details. The Alerts: Display Configuration screen appears providing the following information:
• Threshold
This tab page is divided into three group boxes showing the respective status:
o Normal State
o 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
200 September 2008
o 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.
o 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 201
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 Description
Date Start date of the action
Time Start time of the action
System Target system on which the action was performed
Action Type of action (name of the action in the DBA Cockpit)
Command Type of command (for example, ADD, DELETE or EDIT)
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
202 September 2008
Field Description
Object Name of the modified object (for example, database or tablespace name)
User Name of the SAP user who performed the action
From System System from where the action was performed
3. By default, the system displays all audit entries logged during the current week. If you want to display another week, double-click a day in the calendar.
To display more than one week, you can change the value in the field Number of Days.
4. To display the details of an action, select the corresponding action and choose Details.
In the lower half of the screen, the SQL statements that have been executed are displayed.
8.2 The EXPLAIN Function As of SAP Enhancement Package 1 for SAP NetWeaver 7.0, you can use the EXPLAIN function either in the new Web browser-based user interface or in the SAP GUI-based user interface of the DBA Cockpit.
More Information
• The EXPLAIN Function (New Web Browser-Based Version) [page 202]
• The EXPLAIN Function (SAP GUI-Based Version) [page 205]
8.2.1 The EXPLAIN Function (New Web Browser-Based 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 . Double–click an application and
choose the Statement Text tab page. If a statement is displayed, choose the EXPLAIN pushbutton to display the access plan.
For more information, see Applications: Statement [page 76].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 203
• 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 Description
Original Statement Displays the original SQL statement
Optimized Statement Displays the SQL statement that was rewritten by the DB2 optimizer
Access Plan Displays the access plan that was generated by the DB2 optimizer
EXPLAIN Snapshot
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.
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
204 September 2008
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 205
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 Description [O]/[I] Shows whether the operator acts as an outer/inner input branch
for a subsequent join operation
(<Partition>) Shows on which partition this operation was performed
This is only displayed if you are using a multi-partition database.
Non-volatile tables and indexes of non-volatile tables are displayed in blue. Volatile tables and indexes of volatile tables are displayed in orange.
For each index used in the access plan, the number of key columns, that means index fields that were really used within the access plan, is displayed.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
206 September 2008
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 Description
Details If no operator in the access plan is highlighted when choosing this option, a dialog box is displayed providing detailed information on the statement and each operator. This output is similar to the one of the DB2 command line tool db2exfmt. For more information, see the IBM documentation Administration Guide, Appendix I.
If operator no. 0 is highlighted, only the original statement and optimized statement are displayed in a separate dialog box.
If any other operator is highlighted, the system displays detailed information on the selected operator only.
Optimizer 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 207
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
208 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 209
Tree Info The following additional information is displayed or hidden:
• num_rows
Estimated number of rows (result set)
• tot_cost
Estimated total cost for this statement
• i/o_cost
Estimated I/O cost of the statement
This information is also included in the output information when you choose Details.
Edit When choosing this option, the system switches to an editor window in which you can modify the selected SQL statement and explain it again.
Source This option is only available when the statement contains a LOCATION comment, for example, when you call EXPLAIN using transaction ST05 → Trace list.
The location of the statement in the ABAP source code is displayed in a separate window.
This function is only available for the local system or ABAP systems for which an additional RFC destination has been assigned.
The Collect function is no longer available. To collect EXPLAIN data, use the db2support command line tool.
8.3 Diagnostics: Missing Tables and Indexes
This function is only available for local systems or for ABAP systems for which an additional RFC destination has been assigned.
You can find out whether tables or indexes are missing from either the database or the ABAP Dictionary by calling the DBA Cockpit and choosing Diagnostics → Missing Tables and Indexes in the navigation frame of the DBA Cockpit.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
210 September 2008
The results of the last consistency check are displayed in a tree structure that is grouped into the following sections:
Section Description
Objects missing from the database Objects that are defined in the ABAP Dictionary, but not found in the database
Unknown objects in the ABAP Dictionary
Objects that are found in the database, but not defined in the ABAP Dictionary
Inconsistent objects Results of the detailed comparison of the ABAP Dictionary and the database are displayed here
Other checks Different checks are performed here:
• It is checked whether the primary index of tables defined in the ABAP Dictionary was created uniquely on the database.
• Objects in the SAP system tables are checked, which cannot be described at all or which cannot be completely described in the ABAP Dictionary for technical reasons. If inconsistencies for these objects are detected, they are also displayed here. In general, additional information on the type of inconsistency will be provided.
Optional indexes Mismatch between ABAP Dictionary and database regarding secondary indexes
If the database structure has been changed since the last consistency check, choose Refresh.
For the local system you can:
• Create objects that are defined in the ABAP Dictionary, but not found in the database, by selecting the object and choosing Create on DB
• Display the definition of an object by double-clicking the object
To ensure consistency between ABAP Dictionary and database, the consistency check should be performed once a month or when database structure changes have happened.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 211
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 Drop 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
212 September 2008
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 Diagnostics Deadlock Monitor in the navigation frame of the DBA Cockpit.
The 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 DB2’s automatic storage management.
End of the recommendation.
6. Choose Create Monitor.
7. To start the deadlock monitor, choose Start Monitor.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 213
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:
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
214 September 2008
Locks Held
Column Description
Table Schema Name of the schema to which the table belongs
Table Name Name of the database table
Lock Mode Mode of the lock held
If the Lock Status is Waiting, this is the lock mode which the agent is intended to request.
Lock Object Type Type of object to be locked
Lock Status
Status of lock request:
• Granted
• Waiting
Lock Escalation Indicates if a lock request was made as part of a lock escalation
Lock Count Number of locks on the lock being held
Lock Hold Count
Number of holds placed on the lock
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 215
Statement History (per Agent)
Column Description
Last Use Time Timestamp when the statement was last executed
Statement Text
Displays the complete statement
If the statement does not fit completely in the column, choose Details or double-click the row to get the complete statement text.
Isolation This element shows the isolation value in effect for the statement while it was being run.
Opt. Level Optimization level
Query Degree
The query degree specifies the intra–partition parallelism for the execution of SQL statements.
Statement Type
Statement type:
• Dynamic
• Static
To display more detailed information, select a row and choose Details. Alternatively, you can double-click a field in a table row. As a result, the complete statement text is displayed in the editor window.
In addition, the values bound to the SQL statement at execution time are displayed:
Column Description
Val. Index Value index (parameter marker index) in the statement text
Val. Type Data type of the value
Data Data
Null Value is null.
Reopt Value is used for REOPT.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
216 September 2008
Statement History (per Deadlock)
To display the statement history of an entire deadlock situation, choose Statement History. The Diagnostics Deadlock Monitor – Statement History screen appears.
The following information is displayed:
Column Description
Last Use Time Timestamp when the statement was last executed
Agent ID ID of the agent that executed the SQL statement
Statement Text
Displays the complete statement
If the statement does not fit completely in the column, choose Details or double-click the row to get the complete statement text.
Isolation This element shows the isolation value in effect for the statement while it was being run.
Opt. Level Optimization level
Query Degree
The query degree specifies the intra–partition parallelism for the execution of SQL statements.
Statement Type
Statement type:
• Dynamic
• Static
To display more detailed information, select a row and choose Details. Alternatively, you can double-click a field in a table row. As a result, the complete statement text is displayed in the editor window.
In addition, the values bound to the SQL statement at execution time are displayed:
Column Description
Val. Index Value index (parameter marker index) in the statement text
Val. Type Data type of the value
Data Data
Null Value is null.
Reopt Value is used for REOPT.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 217
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].
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
218 September 2008
8.6.1 Retrieving Index Recommendations 1. Call the DBA Cockpit
2. Choose Diagnostics Index Advisor in the navigation frame of the DBA Cockpit.
The 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 Description
Index Name Name of index
Type
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.
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.
Exists
o Yes
Index exists in the database.
o No
Index is a virtual index.
Table Name Table on which the index is defined
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 219
Column Description
Schema Name of the index schema
Uniqueness
Specifies a unique rule:
o Primary Key
o Unique
o Duplicates Allowed
NLEAF Number of leaf pages
NLEVELS Number of index levels
Rev. Scans
o Yes
Index supports reverse scans.
o No
Index does not support reverse scans.
Columns Number of columns in the key plus the number of included columns if there have been any defined
INCLUDEs Number of included columns
Column Names List of column names
Note
If you do not want to display indexes that are not used, you can set a filter on the table accordingly.
End of the note.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
220 September 2008
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 screen, choose EXPLAIN and one of the following 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 221
• 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
222 September 2008
8.7 Diagnostics: Cumulative SQL Trace
This function is not available for systems monitored using a remote database connection.
You can access trace information on SQL statements by calling the DBA Cockpit and choosing Diagnostics → Cumulative SQL Trace in the navigation frame of the DBA Cockpit. The Diagnostics: Cumulative SQL Trace screen appears.
If you want to retrieve new data, choose Refresh.
The following information is displayed on the EXECUTE, PREPARE and FETCH times of SQL statements:
Column Description
Total Time Cumulative execution time of a statement
% Proportional execution time of one statement with regard to all executed statements
Count Number of executions
Time/Stmt Average execution time of one statement
Table Name of the table the SQL statements reads from
If the statement reads from more than one table, only the name of the first table 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 223
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 Description
DBSL Trace
Trace Level Specifies the amount of data to be traced The following trace levels are available:
• 2: Only statements are traced.
• 3: Statements and results are traced.
Number of I/O Records to Be Traced Number of result records to be traced for a statement
This value is only displayed if trace level 3 is activated.
Display Length for String/Raw Data Maximum output length
DBSL Trace Search String If provided, only SQL statements containing this string are traced.
DBSL Trace Minimum Time Limit If provided, only SQL statements with execution times higher than this time limit are traced.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
224 September 2008
Cumulative Trace
Trace Level Displays the trace level on the current application server
It is set to:
• 0: Trace switched off
• 1: Trace switched on
First Trace Entry Displays the start time of this trace if trace information already exists
Last Trace Entry Displays the end time of this trace if trace information already exists
Number of Entries Displays the number of entries in this trace if trace information already exists
Deadlock Trace
Detection Interval Only SQL statements running longer than this time are recorded for deadlock detection.
For each trace a status icon shows whether the trace is active or switched off.
In a local system you can activate or deactivate the trace function by clicking the status icon. You can also maintain trace parameters in a local system.
8.10 Diagnostics: Database Notification Log
This function is only available if the monitored database is DB2 Version 9.1 for Linux, UNIX, and Windows or lower. If your database is DB2 V9.5 for Linux, UNIX, and Windows or higher, see Diagnostics: DB2 Logs [page 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 225
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
226 September 2008
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 time–outs 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 227
The Diagnostics: DB2 Logs screen provides you with information about all relevant log files of DB2 including the following:
• The database diagnostic log (db2diag.log)
Note
Since DB2's automatic RUNSTATS had been introduced, the db2diag.log can rapidly grow in size up to several gigabytes – depending on the value of the DIAGLEVEL database configuration parameter. By default, the value of this parameter is 3. We therefore recommend that you regularly switch the db2diag.log using the automation function that is provided in the monitoring settings.
End of the note.
• The database notification log (<instance_name>.nfy)
• The statistics log
You can access the DB2 Logs by calling the DBA Cockpit and choosing Diagnostics DB2 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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
228 September 2008
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 229
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
230 September 2008
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
SAP_ABAPDIA_WL
Service SuperclassesService Subclasses
SAP_DIAGNOSTIC_WL
SAP_ABAPBTC_WL
SAP_ABAPSPO_WL
SAP_ABAPUPD_WL
SAP_ABAPUPD2_WL
SAP_JAVA_WL
SAP_ABAPDIA_SSC
SAP_ABAPBTC_SSC
SAP_ABAPSPO_SSC
SAP_ABAPUPD_SSC
SAP_ABAPUPD2_SSC
SAP_JAVA_SSC
SAP_DIAGNOSTIC_SSC
SAP_SC
Note
The workload SAP_DIAGNOSTIC_WL was created for usage in later releases. Currently, no work goes into this workload.
End of the note.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 231
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
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
232 September 2008
Overview
On this tab page, an overview of all configured workloads, service superclasses and their subordinate service classes on the database system are displayed. The hierarchy of service classes is displayed using the inheritance arrows that are known from UML diagrams.
Workloads
On this tab page, you can view details of all existing workloads. The following information is displayed:
Column Description
Position Evaluation order used for choosing a workload
Workload Name Name of the workload
Enabled
Workload state
The following states are possible:
• Green
The workload is enabled.
• Red
The workload is disabled.
DB Access Allowed Determines whether units of work (UOWs) that are associated with the workload are rejected or not
Service Class Name of the service subclass to which an UOW that is associated with this workload is assigned
Parent Service Class
Name of the service super class to which an UOW that is associated with this workload is assigned.
By selecting a workload, additional information on the selected workload is displayed on the following tab pages in the lower half of this screen:
• General
Displays details about the workload from the system catalog as well as the configuration for collecting statistics on the workload
• Connection Attributes
Displays all the attributes that associate an incoming activity with the selected workload.
For an activity to be associated with a certain workload, all the connection attributes of the incoming activity must match the definition of the workload (Boolean AND). If a single attribute type is specified more than once, this indicates that only one of them must match the activity (Boolean OR).
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 233
Service Classes
On this tab page, you can view details of existing service classes. The following information is displayed:
Column Description
Service Class Name of the service class
Enabled
State of service class
The following states are possible:
• Green
The workload is enabled
• Red
The workload is disabled
Agent Priority Graphical display of the thread priority of the agents in the service class.
Agent Priority (Remarks)
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.
Prefetch Priority Graphical display of the agent's prefetch priority in the service class.
Prefetch Priority (Remarks) Prefetch priority of the agents in the service class
When you select a single service class in the table, further details for this service class are displayed. You are able to retrieve monitoring information for all work that has been going on in that service class. You are also able to change the agent and prefetch priority of this service class.
The following tab pages are available:
• General
Displays details about the service class from the system catalog as well as the configuration for collecting statistics on the service class
For more information about how to change the agent or prefetch priority for a service class, see Changing Priorities of Service Classes later in this section.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
234 September 2008
• 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 Increase <Agent or Prefetcher> Priority
o Decrease <Agent or Prefetcher> Priority
o Inherit <Agent or Prefetcher> Priority from Parent Class (DEFAULT)
Resets the priority from its parent service class to the default value.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 235
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
236 September 2008
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 Description
Violation Time when the threshold violation occurred
Partition Database partition where the violation occurred
Predicate
Predicate that was violated
Note
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 Value that was exceeded, which violated the threshold predicate
Application ID Application ID of the activity that caused the violation
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 237
Column Description
Agent ID Agent ID of the activity that caused the violation
By default, the history of such a threshold violation is kept for two weeks. To delete all recorded threshold violations, choose the Reset Violation History pushbutton.
For more information about how to change the size of the violation history, see Performance Warehouse: Configuration [page 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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
238 September 2008
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
Workloads and Service Classes
Indicates if the SAP-proposed workloads and service classes have been set up:
• If they have not yet been set up, you can choose the Setup SAP Workloads and Service Classes pushbutton. A wizard appears that guides you through the setup process of the SAP-proposed workloads and service classes.
• If they have been set up, you can modify the enhanced prioritization scheme, which had been configured on the database system, by choosing the Modify Enhanced Prioritization Scheme pushbutton. If you want to drop the SAP workloads and service classes, choose the Drop SAP Workloads and Service Classes pushbutton.
Event Monitor Infrastructure
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.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
September 2008 239
WLM Event Monitors
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.
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.
Database Administration Using the DBA Cockpit: IBM DB2 for LUW
240 September 2008
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 BI Administration 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