OS_DBA

SAP® AG ��Neurottstr. 16 ��D-69190 Walldorf

SAP on IBM DB2 UDB forOS/390 and z/OS: Database

Administration Guide

Release 6 .20®

SAP Web Application Server

SAP on IBM DB2 UDB for OS/390 and z/OS: Database Administration Guide SAP AG

Copyright

ii March 2002

Copyright

Copyright 2002 SAP AG. All rights reserved.

No part of this documentation may be reproduced or transmitted in any form or for anypurpose without the express permission of SAP AG.

SAP AG further does not warrant the accuracy or completeness of the information, text,graphics, links or other items contained within these materials. SAP AG shall not beliable for any special, indirect, incidental, or consequential damages, including withoutlimitation, lost revenues or lost profits, which may result from the use of these materials.The information in this documentation is subject to change without notice and does notrepresent a commitment on the part of SAP AG in the future.

Some software products marketed by SAP AG and its distributors contain proprietarysoftware components of other software vendors.

Microsoft®, WINDOWS , NT® ,EXCEL and SQL-Server® are registered trademarksof Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2 , Parallel Sysplex®, MVS/ESA, AIX®,S/390®, OS/390®, OS/400®, AS/400®, iSeries, pSeries, xSeries, zSeries, z/OS®, AFP,Intelligent Miner; WebSphere®, Netfinity®, Tivoli®, Informix and Informix® DynamicServer are trademarks of IBM Corp. in USA and/or other countries.

OSF/Motif is a registered trademark of Open Software Foundation.

Oracle is a registered trademark of Oracle Corporation, California, USA.

UNIX® and X/Open® are registered trademarks of The Open Group.

SAP , R/2®, R/3®, mySAP.com®, RIVA®, ABAP , SAPoffice , SAPmail ,SAPaccess®, SAP-EDI , SAP ArchiveLink , SAP EarlyWatch®, SAP BusinessWorkflow , R/3 Retail® are registered trademarks of SAP AG

All rights reserved.

Documentation in the SAP Service Marketplace

You can find this documentation at the following address:

http://service.sap.com/instguides

SAP AG SAP on IBM DB2 UDB for OS/390 and z/OS: Database Administration Guide

Contents

March 2002 iii

Contents

Chapter 1: Introduction.................................................................................................1–1About this Guide .........................................................................................................1–2Required Knowledge ..................................................................................................1–3Terminology................................................................................................................1–3Features......................................................................................................................1–4

Chapter 2: Basics ..........................................................................................................2–1Stop and Restart Operations ......................................................................................2–2Central Navigation Tool ..............................................................................................2–4Authorization Profiles................................................................................................2–14Automated PTF Check .............................................................................................2–15Other Operations and Considerations ......................................................................2–25

Chapter 3: Performance Tuning Considerations........................................................3–1 Introduction ................................................................................................................3–2 Virtual Storage Considerations ..................................................................................3–3 Setting Optimal SAP Profile Values...........................................................................3–9 Customizing the SAP Objects Topology..................................................................3–10 Ensuring Optimal Access Paths ..............................................................................3–11 Clustering Index.......................................................................................................3–22 Locking Considerations ...........................................................................................3–24 Other Considerations...............................................................................................3–30

Chapter 4: Monitoring and Performance.....................................................................4–1 Setup of Database Performance Monitoring with RFCOSCOL.................................4–3 Database Performance Monitor...............................................................................4–14 Database Tools .......................................................................................................4–27 Tables and Indexes Monitoring ...............................................................................4–43 CCMS Monitor Set...................................................................................................4–53 SAPOSCOL for z/OS...............................................................................................4–64

Chapter 5 : Database Administration...........................................................................5–1 Backup and Recovery Options ..................................................................................5–3 JES Interface ...........................................................................................................5–21 DBA Planning Calendar...........................................................................................5–27

Chapter 6: Storage Management .................................................................................6–1 Changing the Database Layout .................................................................................6–2 Storage Parameters ..................................................................................................6–6 Space Management ................................................................................................6–22

Appendix A: Transaction Codes ................................................................................. A–1Transaction Codes .....................................................................................................A–2

Appendix B: Database Layout..................................................................................... B–1General Overview.......................................................................................................B–2Mapping Between the ABAP Dictionary and DB2.......................................................B–6

Appendix C: Environment Variables........................................................................... C–1Environment Variables............................................................................................... C–2

SAP on IBM DB2 UDB for OS/390 and z/OS: Database Administration Guide SAP AG

Typographic Conventions

iv March 2002

Typographic Conventions

This type style Represents

Interface Text Words or characters that appear on the screen. Thisincludes field names, screen titles, pushbuttons, menunames, and menu options.

Document Title Cross-references to other documentation

User Entry Exact user entry. These are words and characters thatyou enter exactly as they appear in the documentation.

<Variable User Entry> Variable user entry. Pointed brackets indicate that youreplace these words and characters with appropriateentries.

NAME Names of elements in the SAP System. These includereport names, program names, transaction codes, tablenames, ABAP language elements, file names, anddirectories.

KEY Keys on your keyboard. These include function keys(for example, F2) and the ENTER key, among others.

This icon Helps you identify

Note a note. Notes contain important information likespecial considerations or exceptions.

Examplean example. Examples help clarify concepts orprocedures.

Cautiona caution. Cautions help you avoid errors such as thosethat could lead to data loss.

SAP AG Introduction

Contents

March 2002 1–1

Chapter 1: Introduction

Contents

About this Guide............................................................................................................1–2

Required Knowledge.....................................................................................................1–3

Terminology ...................................................................................................................1–3

Features..........................................................................................................................1–4SAP Web Application Server Release 6.20................................................................1–4SAP Web Application Server Release 6.10................................................................1–4SAP R/3 Release 4.6C ...............................................................................................1–5SAP R/3 Release 4.6B ...............................................................................................1–5SAP R/3 Release 4.6A ...............................................................................................1–5SAP R/3 Release 4.5B ...............................................................................................1–5

Introduction SAP AG

About this Guide

1–2 March 2002

About this GuideFor the most up-to-date version of this guide, see the documentation in the SAP ServiceMarketplace at: http://service.sap.com/instguides.

Chapter 1: Introduction

• General information

• Features

Chapter 2: Basics

• Start and restart operations

• Authorization profiles

• Central navigation tool

• PTF check tool

Chapter 3: Performance Tuning Considerations

• Virtual storage considerations

• Ensuring optimal access paths

Chapter 4: Monitoring and Performance

• Monitoring and performance within the SAP system

• RFCOSCOL

• Database tools

• CCMS Monitor Set

Chapter 5: Database Administration

• Backup and recovery options

• JES interface

• DBA Planning Calendar

Chapter 6: Storage Management

• Modification of the database layout and storage parameters

• Naming conventions for database objects

• Administrative tasks, such as managing volume space

Appendix A: Transaction Codes

• Overview of transaction codes that are useful for the administration of the SAPsystem on DB2 UDB for OS/390 and z/OS

Appendix B: Database Layout

• Organization of the ABAP Dictionary at the DB2 UDB for OS/390 and z/OS level

Appendix C: Environment Variables

• Overview of important DB2-specific environment variables

SAP AG Introduction

March 2002 1–3

Note

Some sections use information provided by the IBM documentation SAP on IBM DB2UDB for OS/390 and z/OS: Planning Guide: SAP Web Application Server. Thisdocumentation is referred to as Planning Guide: SAP Web Application Server in thisdocumentation.

For more information on functions not described in this documentation, see the SAPOnline Documentation. Choose Help → SAP Library from the main menu in yourSAP System. Alternatively, you can access the help files on the OnlineDocumentation CD, supplied in the installation package.

Required Knowledge You need to be familiar with:

• z/OS (UNIX System Services, JCL, TSO)

• DB2 administration, SQL, SPUFI, DB2 utilities, such as REORG and RUNSTATS

• AIX, Solaris or Windows, LINUX

• The SAP system (ABAP Dictionary, conversion of tables, CCMS)

TerminologyThe following table lists terms that are used with a specific meaning in this guide.

Term Meaning

Database DB2 database objects are referred to as database.

DB2 Within this guide, DB2 UDB for OS/390 and z/OS is mostlyreferred to as DB2.

SAP database The complete data belonging to one SAP system is called SAPdatabase.

Stogroup DB2 UDB for OS/390 and z/OS storage groups are calledstogroups in this guide to distinguish them from SMS storagegroups in the Storage Management Subsystem (SMS).

Introduction SAP AG

Features

1–4 March 2002

Features

SAP Web Application Server Release 6.20

The following features are included in this guide for Release 6.20:

• MCOD allows you to place multiple SAP Systems in one database. The databaseadministration tools take this into account.

• The DB Performance Monitor uses RFCOSCOL to gather performance data.

• ICLI Alert Router has been abolished. RFCOSCOL serves as the database alert router.

• New features of DB2 V7, such as Real Time Statistics and the corresponding storedprocedure DSNACCOR are included.

• The work processes of SAP application servers can be actively redirected to adifferent DB2 subsystem. Transactions ST04 and DB2 enable you to initiate suchfailovers.

• The SAP system aims to ensure that the DB2 Accounting trace classes 2 and 3 and theperformance trace IFCID 318 are always switched on.

• Changes within the database layout (Appendix B):One database can now hold one multi-table tablespace (XSAP) or up to 100 single-table tablespaces. This significantly reduces the number of databases needed for anSAP system.

SAP Web Application Server Release 6.10

The following features are included in this guide for Release 6.10:

• Changes within the database layout (Appendix B):- LOB tablespaces, auxiliary tables and indexes to support LOB (large object) data

types- Schemata / creators other than SAPR3

• Modifications to the mass processing tool RSDB2MAS and the PTF check tool

• New transaction DB13C Central DBA Planning Calendar

• New ICLI client and DBSL traces

• DB2 PM no longer supported

• SAP Performance Monitor uses ICLI Performance Services to gather performancedata.

SAP AG Introduction

Features

March 2002 1–5

SAP R/3 Release 4.6C

The following features are included in this guide for Release 4.6C:

• Significant modifications to the mass processing tool RSDB2MAS and the PTF checktool

• Reduced number of data sets through using DB2’s new storage attribute DEFINEYES/NO (Appendix B)

SAP R/3 Release 4.6B

The following features are included in this guide for Release 4.6B:

• Transaction DB2 and central navigation tool

• PTF check Tool

SAP R/3 Release 4.6A

The following features are included in this guide for Release 4.6A:

• Direct adjustment of storage parameters in the database using transaction SE14.Instead of a table conversion, SQL statements of the form ALTER INDEX or ALTERTABLESPACE are performed, if possible.

• Improved DB2 code page support (the special characters “ # ” and “ $ ” are no longerused for tablespace and database names). For more information, see SAP Note116750.

• Usage of DB2’s new buffer pools BP8K0 and BP16K0

SAP R/3 Release 4.5B

The following features are included in this guide for Release 4.5B:

• Report RSDB2MAS

This report supports the mass processing function in the ABAP Dictionary. It allowsyou to select:- Empty and non-buffered tables for transfer into a multi-table tablespace- Non-empty, non-buffered tables for transfer into a tablespace of their own.

The selected tables can be entered for mass processing. See the section on "MassProcessing" for more information.

• Within transaction SE14:- Move tables to existing tablespaces. See the section "Moving Tables to Existing

Tablespaces" for more information.- Directly access index storage parameters. See the subsection "Display/Edit Index

Parameters" for more information.

SAP AG Basics

Contents

March 2002 2–1

Chapter 2: Basics

Contents

Stop and Restart Operations........................................................................................2–2Stopping and Restarting the SAP System ..................................................................2–2Maintaining the DB2 Subsystem.................................................................................2–2

Central Navigation Tool ................................................................................................2–4Performance Tuning ...................................................................................................2–4Storage Management .................................................................................................2–8Checks/ Settings.......................................................................................................2–10Traces/Logs..............................................................................................................2–12

Authorization Profiles .................................................................................................2–14

Automated PTF Check ................................................................................................2–15Overview...................................................................................................................2–15Additional Information Sources.................................................................................2–15Technical Details ......................................................................................................2–15Requirements ...........................................................................................................2–17Setup ........................................................................................................................2–17Performing the Check...............................................................................................2–18Analyzing the Output.................................................................................................2–22Troubleshooting........................................................................................................2–23Recommendations....................................................................................................2–24

Other Operations and Considerations ......................................................................2–25Scheduling SAP System Off-Hour Jobs ...................................................................2–25Printing......................................................................................................................2–25GUI Access...............................................................................................................2–25Database Access......................................................................................................2–25Hardware Failure ......................................................................................................2–26DB2 Schema ............................................................................................................2–27MCOD and CCMS ....................................................................................................2–27

Basics SAP AG

Stop and Restart Operations

2–2 March 2002


Stopping and Restarting the SAP System

To completely stop an SAP system, it is necessary to stop the application servers, theICLI server instances and, optionally, the associated DB2 subsystems of the SAP system.If the SAP system belongs to an MCOD landscape, only those DB2 subsystems can bestopped that do not serve other SAP systems.

To stop the SAP system:

1. Stop all SAP dialog instances

2. Stop the SAP central instance

3. Stop all running ICLI server instances of the SAP system

4. If you intend to stop the DB2 subsystem, stop all RFCOSCOL processes connectedto the subsystem

5. Stop the connected DB2 subsystems if they do not serve other SAP systems

Optionally, you can also skip stopping the SAP application servers and employ the“smooth” stop method of the ICLI server. This allows you to restart the SAP systemfaster since the buffers of the application servers do not have to be populated again. Fordetails on how to start and stop the ICLI server and its “smooth” stop feature, see theIBM documentation Planning Guide: SAP Web Application Server.

To restart the SAP system:

1. Start the required DB2 subsystems if not already active

2. Start the ICLI server instances of the SAP system

3. Start the SAP central instance

4. Start all SAP dialog instances

5. Start RFCOSCOL

Maintaining the DB2 Subsystem

To maintain the DB2 subsystem that is not part of a data sharing group:

1. Stop all SAP dialog instances.

2. Stop the SAP central instance.

This stops all DB2 threads and allows you to leave the ICLI server running.

3. Stop all RFCOSCOL processes connected to the DB2 subsystem.

4. Perform maintenance actions. Stop and start the DB2 subsystem if needed.

5. Start all SAP instances.

6. Start RFCOSCOL.

Optionally, you may again leave the SAP instances running and use the “smooth” stopmethod of the ICLI server.

SAP AG Basics


March 2002 2–3

To maintain a DB2 subsystem that is part of a data sharing group:

1. Redirect the work processes of all SAP instances, which are connected to that DB2subsystem, to different members. These members need to be capable of handling theadditional load.

2. Stop all RFCOSCOL processes connected to the DB2 subsystem.

3. Perform maintenance actions. Stop and start the DB2 subsystem if needed.

4. Redirect the moved work processes back to the DB2 subsystem.

5. Start RFCOSCOL.

The redirection of work processes is described in the section “Initiation of Failover toOther DB2 Subsystems” in the chapter “Monitoring and Performance”.

Basics SAP AG

Central Navigation Tool

2–4 March 2002

Central Navigation ToolThe SAP system provides a central navigation tool, which simplifies access to DB2-specific transactions and reports. The tool consists of the following sections:

• Performance tuning

• Storage management

• Checks and settings

• Traces and logs

These sections are described in more detail below.

To access the central navigation tool, call transaction DB2.

Performance Tuning

When you call transaction DB2, the screen Database Administration: DB2 UDB forOS/390 - Performance Tuning appears.

From this screen, you can select functions related to performance analysis and tuning.

The functions are grouped into four areas: Analysis, Tools, Alerts and Network.

SAP AG Basics


March 2002 2–5

Performance Tuning

The following tables give an overview of the functions, their alternative transactions, andgive a reference to where you can find more detailed information on these functions inthis guide.

Basics SAP AG


2–6 March 2002

Performance Tuning - Analysis

Function AlternativeTransaction

Detailed InformationSection Chapter

DB2 Subsystem Activity ST04 DB2 Subsystem Activity 4

Thread Activity ST04 Thread Activity 4

Cache Statement Statistics ST04 Cached StatementStatistics

4

Global Times ST04 Global Times 4

Installation Parameters ST04 Installation Parameters 4

Performance Tuning - Tools



DB2 Catalog Browser ST04 DB2C DB2 System Catalog 4

OS/390 System Log ST04 OS/390 System Log 4

DB2 Commands ST04 DB2 UDB for OS/390Commands

4

Buffer Pool Tuning ST04 DB2B Buffer Pool Tuning 4

Update Statistics DB20 Update Statistics 5

Explain Statement ST05 EXPLAIN 4

DBA Planning Calendar DB13 DBA Planning Calendar 5

Central Planning Calendar DB13C Central DBA PlanningCalendar

5

SAP AG Basics


March 2002 2–7

Performance Tuning - Alerts



Long-Running URs ST04 DB2U DB Alert Router 4

Deadlocks ST04 DB2D DB Alert Router 4

Timeouts ST04 DB2T DB Alert Router 4

Extents ST04 DB02 Extent Monitor 4

Active Log Shortage ST04 DB Alert Router 4

CCMS Monitor Set RZ20 CCMS Monitor Set 4

Performance Tuning - Network



Active DB Connections ST04 Tools 4

DB Connection List ST04 Tools 4

DB Alert Settings ST04 DB Alert Router 4

ICLI Diagnostics(not for application serveron OS/390)

ST04 ICLI Diagnostics 4

ICLI Ping(not for application serveron OS/390)

− ICLI Diagnostics 4

Basics SAP AG


2–8 March 2002

Storage Management

Call transaction DB2 and select Storage Mgt.

You can select functions on this screen to monitor and change storage attributes.

The functions are grouped into three areas: Database objects, Status, and Tools.

Storage Mgt.


SAP AG Basics


March 2002 2–9

Storage Mgt. - Database Objects



Edit SE14 Storage Parameters 6

Storage Mgt. - Status



Backups DB12 Backup and RecoveryOptions

5

Tables and Indexes DB02 Tables and IndexesMonitor

4

Storage Mgt. - Tools



DBA Planning Calendar DB13 DBA Planning Calendar 4

DB2 Catalog Browser ST04 DB2C DB2 System Catalog 4

DB2 Commands ST04 DB2 UDB for OS/390Commands

4

Mass Processing SE38 withRSDB2MAS

Mass Processing 6

Empty DB Objects SE38 withRSDB2CLN

Self-explanatory report −

Basics SAP AG


2–10 March 2002

Checks/ Settings

Call transaction DB2 and select Checks/settings.

This screen combines check utilities and transactions to modify and display settings.

These functions are combined into four areas: Checks, DB2 subsystem settings, R/3settings and DB performance monitor.

Checks/Settings


SAP AG Basics


March 2002 2–11

Checks/Settings - Checks



Dictionary – DB2 Catalog DB02 Checking Consistency 4

Missing Unique Indexes DB02 Checking Consistency 4

DB2 Subsystem DB16 DB System Check 4

Missing Fixes SE38 withRSDB2FIX

Automated PTF Check 2

SAP System Check SICK Checking Consistency 4

Checks/Settings - DB2 Subsystem Settings



Maintain CheckParameters

DB17 DB System Check 4

Installation Parameters ST04 Installation Parameters 4

Checks/Settings - SAP Settings



JCL Submission Service DB2J JES Interface 5

DB Alert Router ST04 DB Alert Router 4

Checks/Settings - DB Performance Monitor



SAP Collector Settings DB Performance Monitor 4

Basics SAP AG


2–12 March 2002

Traces/Logs

Call transaction DB2 and select Traces/logs.

From this screen, you can access different traces and logs. This is particularly useful ifyou have to analyze the cause of short dumps and database problems.

These functions are grouped into two areas: Traces and Logs.

Traces/Logs

SAP AG Basics


March 2002 2–13


Traces/Logs - Traces



System Trace ST01 − −

ICLI(not for application serveron OS/390)

ST04 ICLI Diagnostics 4

ABAP SE30 − −

SQL ST05 − −

DBSL − − −

IFI Data Collector − Performance Monitoring 4

The DBSL trace allows to trace each CLI statement. It should be only used by experts.Tracing can considerably impact the performance of the entire system.

Traces/Logs - Logs



SAP System Log SM21 − −

OS/390 System Log ST04 OS/390 System Log 4

Basics SAP AG

Authorization Profiles

2–14 March 2002

Authorization ProfilesThe following authorization profiles are delivered as standard for particular tasks in thetable and index monitor and the CCMS topics.

Authorization Profile Authorizations Permitted

S_DB2_DBADM

(Authorization profile of theDB2 UDB for z/OS databaseadministrator)

With this authorization, you can:

• Execute an ALTER on the secondary quantity of atablespace or index (tables and indexes monitor)

• Change and delete the JCL Jobs of any user (JESInterface)

• Change the TSO password of any user (JESInterface)

• Execute all DB2 commands, create, change anddelete new commands, (SAP performancemonitor)

• Execute SELECT on DB2 catalog tables (DB2 catalog browser)

• Switch an application server to a different DB2 data sharing member

S_DB2_COMM With this authorization, you can:

• Execute, change and delete all DB2 commands, create new commands (SAP performance monitor)

S_DB2_EXPC With this authorization, you can:

• Execute all DB2 commands, create, change and delete new commands, (SAP performance monitor) that have the command user ALLUSER

S_DB2_ALLU With this authorization, you can:

• Execute all DB2 commands that have the command user ALLUSER (SAP performance monitor)

Call transaction SU01 to give the appropriate authorization profile to a user.

SAP AG Basics

Automated PTF Check

March 2002 2–15

Automated PTF Check

Overview

It can be time-consuming to check whether all Authorized Program Analysis Reports(APARs) and Program Temporary Fixes (PTFs) required in SAP Note 81737 have beenapplied to an OS/390 system. You can simplify this task by using a tool thatautomatically performs all of the following steps:

1. Determination of the release and/or version of all software components (SAP system,SAP kernel, OS/390 system, and DB2 subsystem)

2. Extraction of all required PTFs from SAP Note 81737 and current fix level file

3. Determination of the status of all required PTFs within the OS/390 system

4. Output of missing PTFs and/or Function Module IDs (FMID)

Additional Information Sources

The following references provide additional information:

• SAP Note 81737 lists all PTFs required.

• SAP Note 183311 covers updates on the PTF check.

• SAP Note 103135 describes the installation of saposcol of rfcoscol.

Technical Details

The automated PTF check is based on the assumption that customers administer allOS/390 software components using IBM’s System Modification Program Extended(SMP/E). This OS/390 program keeps a record of all changes (for example, PTFs) tofunction modules in the Consolidated Software Inventory (CSI).

SMP/E also provides an interface (GIMAPI) that can be called by application programs toquery the contents of the CSI. For more information on SMP/E, see the IBMdocumentation SMP/E Reference and SMP/E User’s Guide).

SAP’s rfcoscol is able to connect to the GIMAPI interface and forward the SMP/E datato any SAP system that is linked to rfcoscol. The PTF check itself is performed byreport RSDB2FIX and runs on an SAP System that is called check system in thisdocumentation. The system to be checked is referred to as target system. The target andcheck system may be identical but it is also possible to choose one single SAP system tobe the check system for all other SAP installations at the customer site. This is feasiblebecause the check system connects to the target system and its OS/390 host using remotefunction calls (RFC). Also, it is not required that the check system runs on DB2.

Basics SAP AG

Automated PTF Check

2–16 March 2002

The technical details of the PTF check are illustrated in the following graphic.

PTF Check

Check System Target System

SAPNote

81737

FixLevelFile

Application server

S/390 host

Application server

Read

rfcoscol

SMP/E

DB2

OPEN MVS

VTAM

ICLI / embedded SQL

JES3

TCP/IPconnection

R/3connection

GIMAPI

SAP

Admin.Copy

LogOutput

RSDB2FIX

SAP Note 81737 is formatted in such a way that it can be used directly as input for thecheck report. You only have to download it to the application server of the check system.Additionally, SAP and IBM provide a file called fix level file on sapservX that containsa list of PTFs related to the latest put levels. Both files are uploaded by RSDB2FIX.

Alternatively, the check tool is able to automatically retrieve the most recent PTFinformation kept in SAP Note 81737 and the fix level file directly from SAPNet − R/3Frontend (formerly OSS) if a valid RFC connection exists. In that case, a download ofthese files to your PC or the application server is not required.

The target system’s kernel release as well as the versions of the DB2 and OS/390software used are determined via RFC. This information combined with the uploadedPTF information (SAP Note 81737 and fix level file) is subsequently used by RSDB2FIXto retrieve a list of required PTFs and FMIDs.

The kernel release is used to determine which ICLI PTF is required.

Finally, RSDB2FIX queries the status of each required FMID and PTF employingrfcoscol‘s connection to GIMAPI and SMP/E. PTFs that are not found with status“applied” or “superseded” are listed as “missing” in the output.

APARs that are not checked, because none of the associated FMIDs can be located in thegiven CSIs, are also written to the output.

SAP AG Basics

Automated PTF Check

March 2002 2–17

Requirements

Check System

The check report RSBD2FIX is part of SAP Web AS Release 6.10 and 6.20. It is alsopossible to import the report into any SAP System with SAP R/3 Release 3.0F to 4.6D.Transport files are provided on sapservX. For more information, see SAP Note 183311.

Target System

The requirements for the target system are:

• SAP R/3 Release 3.0F or higher

• OS/390 Version 2.6 or higher

• DB2 for OS/390 Version 5.1 or higher

Setup

Before starting the PTF check you have to set up your environment as follows:

1. Check the SMP/E settings.

The PTF check tool can only check entries in CSI. You have to make sure that theseCSI entries reflect exactly the status of the software that is actually running.

2. Select one of your SAP systems as the check system to perform the PTF check.

3. Update the check report RSDB2FIX in your check system if necessary. This isusually only required if the SAP R/3 release of your check system is 4.6D or lower.For more information, see SAP Note 359375.

4. Install rfcoscol with SAP R/3 Release 4.6D or higher on the OS/390 host. Formore information, see SAP Note 359375.

5. Make sure that the user that starts rfcoscol has read access to SMP/E’s CSI datasets.

6. Start rfcoscol on the OS/390 host with a connection to the check system. For moreinformation, see SAP Note 103135.

7. Establish an RFC connection from the check system to the rfcoscol running on theOS/390 host. For more information, see SAP Note 103135.

8. Establish an RFC connection from the check system to the target system. To do this:

a) Start the target system.

b) On your check system, call transaction SM59.

c) Choose Edit → Create.

d) Specify the name of the new “RFC destination” and “Connection type” “3”, and provide a “Description”.

e) Choose Enter.

f) Specify and save the “Technical settings” and the “Logon” data.

g) Check the new R/3 connection by choosing Test connection and Remote Logon.

9. Establish a connection to SAPNet − R/3 Frontend. (Optional)

Basics SAP AG

Automated PTF Check

2–18 March 2002

a) Log on to the check system and call transaction OSS1.

b) Choose Parameters → Technical Settings.c) Specify and save the Logon settings.d) Choose Log on, specify group 1_PUBLIC, and check whether the connection

works.

Performing the Check

Once you have completed the preparations described in section Setup, the PTF check canbe performed.

1. If the check system is not able to connect to SAPNet, you need to transfer SAP Note81737 and the current fix level file to a directory on the application server of thecheck system. To do this:

a) From SAPNet − R/3 Frontend, display the English version of SAP Note 81737.

b) Choose Note administration.

c) Choose Note → Download.

d) Choose Do not copy.

e) Specify data format ASC and file name on your presentation server.

f) Choose transfer.

g) Copy the downloaded file from your presentation server to the central instance of the check system (use FTP with transfer type ASCII).

h) Download the file fix<YYMMDD>.txt from sapservX directory ~ftp/general/R3server/abap/note.0183311 to the application server of the check system (use FTP with transfer type ASCII). It contains in machine readable format a list of all PTFs related to the current required service levels.

2. To access the PTF check tool, call one of the following transactions:

− Call transaction DB2, choose Checks/Settings → Missing Fixes.

− Call transaction SE38 and execute report RSDB2FIX.

The input screen of check report RSDB2FIX appears.

SAP AG Basics

Automated PTF Check

March 2002 2–19

Fix Check - Input Screen

Basics SAP AG

Automated PTF Check

2–20 March 2002

3. Enter the following input values:

Fix Check: Input Screen Values

File Name or Setting Input Value/Description

SAP Note 81737 Full path name of the file on the applicationserver that contains SAP Note 81737.See Performing the Check, step 1.g.

Fix level file (Optional) Full path name of the file on the applicationserver containing the put level information.See Performing the Check, step 1.h.

Log Name Name of the log to which the output iswritten. The pattern &R3&, &DATE& and&TIME& are substituted by the name of theR/3 destination, the date and the timerespectively.

SAP System (R/3) RFC destination of the target system. SeeSetup, step 8.

OS/390 Host (TCP/IP) RFC destination of the target system’sOS/390 host. See Setup, step 7.

SAPNet (R/3) SAPNet’s RFC destination. The defaultconnection SAPOSS is created by usingtransaction OSS1 (see Setup, step 9). Thetransaction can be accessed directly bychoosing Online Service System (OSS1).

SMP/E Settings The input depends on how SMP/E isconfigured in your environment. Specify thedata set and the zone for at least one CSIlibrary. The sample input in the Fix Check:Input Screen graphic represents anenvironment where all the DB2 functionmodules are administered in data setSMPE.DB261.CSI and zone TDB261,whereas the remaining software components(Open MVS, JES3, VTAM, and so on) arekept in data set SMPE.OS390.CSI and zoneTOS390.

Note that you cannot check GLOBAL or DLIBzones.

3. Choose Ping to check whether the associated RFC connection works.

4. Save the input as a variant (CTRL-S; use the target system ID as variant name). ThePTF check can then be easily repeated.

SAP AG Basics

Automated PTF Check

March 2002 2–21

5. Make sure that no other PTF check is currently running on the target system. If yourun PTF checks in parallel, there is no risk of damaging the SMP/E data. However,the results may be incorrect. You can execute report RSDB2FIX either online or as abackground job:

− Online

Choose Program → Execute . The program runs for several minutes. Therefore,it might be necessary to increase profile parameter abap/timeout to avoid atimeout.

− Background

Choose Program → Execute in background or define a background job usingtransaction SM36. For monitoring, call transaction SM37.

6. Output

The result logs can be displayed by choosing Display logs within the initial selectionscreen of RSDB2FIX. If RSDB2FIX is executed online, the result log is displayeddirectly after the check.

Basics SAP AG

Automated PTF Check

2–22 March 2002

Analyzing the Output

Analyze the output of the RSDB2FIX program.

All errors, warnings, and check results are reported to the output. If the report completessuccessfully, you find a list of missing PTFs and FMIDs at the end of the output.

• Below the section Check PTFs the following ouput might appear:

− No missing PTFs found.All PTFs required for the FMIDs found within the given SMP/E settings havebeen applied. Nothing needs to be done. If the fix level file was not used, only asubset of all required PTFs is checked and there might then be a number ofmissing PTFs.

− The following PFTs are missing.A list providing information on the missing PTFs and their associated FMID andAPAR is given. The list is ordered by FMID and APAR.Check the status of these missing PTFs. Maybe they are only needed undercertain circumstances. For example, the additional Required for... indicates that aPTF is only needed for certain SAP releases.For more information, see SAP Note 81737. Otherwise, apply the PTFs to yourOS/390 system.

• Below the section Check FMIDs the following output may appear:

− All APARs checked.This means that all APARs (and associated PTFs) could be checked. The SMP/Esettings specified in the input screen is complete. Note that if the fix level filewas not used, only a subset of all required APARs and PTFs is checked.

− The following APARs cannot be checked because none of the associated FMIDscould be located in the specified CSIs.The following list contains all APARs that could not be checked due to the factthat none of the associated FMIDs is active in the given SMP/E settings. It ispossible that the APAR refers to a product that is not installed in yourenvironment. This is, for example, the case if you use JES2 and the APAR isrelated to JES3.Check whether your input to RSDB2FIX is incomplete. If it is, you shouldcorrect the SMP/E settings on the input screen and run RSDB2FIX again.

SAP AG Basics

Automated PTF Check

March 2002 2–23

Troubleshooting

The following list helps you to solve some of the problems that might occur whenexecuting the RSDB2FIX program:

• Error message: SAPOSCOL is outdated (version >= 4.6C required) or not runningon OS/390. See SAP Note 183311 for details.

Install the latest versions of saposcol/rfcoscol/librfc provided on sapservXin files:

~ftp/general/R3server/abap/note.0183311/IBMOS390.PAX (EBCDIC)

~ftp/general/R3server/abap/note.0183311/OS39046C.PAX (ASCII)

• Error message: Report RSDB2FIX is outdated Please obtain current version. SeeSAP Note 183311 for details.

A hot package is provided.

• Error message: Version of SAP Note 0081737 is outdated. Please use currentversion.

Download the latest version of SAP Note 81737 and use it as input.

• Error message: SMP/E API failed. with GIM59605S ** ENQ FAILED OR SHAREDUSE OF ... FOR QUERY PROCESSING.

RSDB2FIX could not access SMP/E due to an SMP/E job or user session running inparallel.

• Error message: SMP/E API failed. with GIM44240I GIMVSMSG - THE VSAMERROR ANALYSIS OCCURRED...

Give read access for SMP/E’s CSI data sets to the user that starts rfcoscol.

Basics SAP AG

Automated PTF Check

2–24 March 2002

Recommendations

Uploading Input Files from PC

If RSBD2FIX is executed online, the input files can also be uploaded from thepresentation server. In that case you have to download SAP Note 81737 and fix level fileto the presentation server and specify the input parameters accordingly.

Omitting Fix Level File

Usually it is sufficient to check the put levels contained in file fix<YYMMDD>.txt onlyonce. After making sure that all PTFs belonging to certain put levels have been applied,you can reduce the PTF check to the PTFs listed in SAP Note 81737. In that case, leaveinput parameter Fix level file empty. This will reduce execution time.

Scheduling PTF Checks Regularly

Consider defining a background job within transaction SM36 that checks all yoursystems on a regular basis, for instance once a month. Each target system that is definedas a variant of report RSDB2FIX can form a step within this job. However, you mustmake sure that RSDB2FIX always uploads the latest versions of SAP Note 81737 and thefix level file. This is guaranteed if RSDB2FIX uploads the information directly fromSAPNet.

Checking PTF Level before an Upgrade

The PTF check does not depend on the system’s SAP release. Therefore, you can useRSDB2FIX before upgrading a system to check whether all PTFs required for the targetrelease are applied. Note, however, that the ICLI PTF required depends on the futurekernel release and therefore has to be checked manually.

Handling a Data Sharing Group

For a data sharing group, two cases can be distinguished. If the software level is identicalfor all members of a data sharing (DS) group and is managed within one central SMP/ECSI, it is sufficient to perform the PTF check for one member. Otherwise, you mustperform a PTF check for each member of the DS group. To do this:

1. Configure and start rfcoscol on each DS member.

2. For all rfcoscols, establish a dedicated TCP/IP connection (using transactionSM59) to the check system.

3. Execute RSDB2FIX for each DS member. Note that you must specify the TCP/IPconnection and the CSI libraries individually for each DS member.

Note

PTF checks cannot be run in parallel.

SAP AG Basics

Other Operations and Considerations

March 2002 2–25


Scheduling SAP System Off-Hour Jobs

Any SAP process can be run in either online or in background mode. The SAP systemprovides its own internal job definition for background processing. Scheduling can beaccessed by any user with the required SAP authorization. Background processing can bescheduled within the SAP system in a number of ways:

• At a specific date and time

• After a given event

• After a given job

• At certain intervals, for example: daily, weekly, or monthly

• Immediately

• For a specific application server

See the SAP Online Documentation for more information.

Printing

Print support is provided in the SAP system with a system of screens within thefunctional area of system administration. These screens enable the SAP systemadministrator to specify and manage:

• Printer output device identification

• Device type definition

• Standard print control

• Page formats and paper types

• Spool maintenance and control

• Character set maintenance

See the SAP online documentation for more information.

Other facilities for managing the print workload are available, including AFP. See theIBM documentation Planning Guide: SAP Web Application Server.

GUI Access

GUI access to the SAP system on DB2 UDB for z/OS is handled in the same manner,regardless of platform. Users log on to a workstation where the SAP GUI is installed, andthe user is then connected to an application server, which then provides access to data onthe database server.

Database Access

The SAP system controls all write access to the database. Native write access is notallowed and can destroy the data consistency.

Native read access is allowed. Confidential data is encrypted (for example, salaries).

Basics SAP AG


2–26 March 2002

Caution

If you intend to read data with an isolation level that causes locks to be requested (forexample, RS, RR), be aware that you might cause deadlocks and timeouts in theSAP system.

Hardware Failure

Plans to reduce the effects of unplanned downtime due to hardware, software, orcommunication failure must be implemented. These failures range from relatively minorincidents to major disasters, for instance:

• Database processor failure

• DASD or disk failure

• User data error

• Application server connection failure

• Database server/application server connection failure

• Failed node in an SP2

• Failed processor

Caution

In the SAP system environment, planning for these types of failures should be similarto conventional failure recovery planning, taking the following into consideration:Due to the highly integrated nature of the SAP data, any database recovery that istriggered by any type of failure must be performed with care in order to ensure thatthe recovered data is logically consistent. In a point-in-time recovery, any updateddata after the target point-in-time will be lost.

See also:

SAP Online DocumentationSAP Library → SAP Web Application Server → Computing Center Management System→ BC SAP High Availability

SAP AG Basics


March 2002 2–27

DB2 Schema

The variable <SCHEMA> is introduced for the DB2 schema name instead of thepreviously hard-coded name SAPR3.

MCOD and CCMS

In an MCOD installation, SAP systems let other SAP systems in the same DB2subsystem automatically know about their existence. During startup, it contacts andnotifies the other systems. This function is embedded in a program that runs every hour(RSDB2_COLLECT_HOURLY). The other SAP systems do not have to be started forthis notification to take place. SAP systems that are embedded in the DB2 subsystem at alater stage are also immediately advised of this system. If necessary, you can announcean SAP system manually by calling transaction DB2J.

SAP AG Performance Tuning Considerations

Contents

March 2002 3–1

Chapter 3: Performance Tuning Considerations

Contents

Introduction...................................................................................................................3–2

Virtual Storage Considerations...................................................................................3–3 Recommendations.....................................................................................................3–3 Virtual Storage Usage Estimates...............................................................................3–4 Monitoring ..................................................................................................................3–8

Setting Optimal SAP Profile Values ............................................................................3–9

Customizing the SAP Objects Topology..................................................................3–10

Ensuring Optimal Access Paths ...............................................................................3–11

Clustering Index..........................................................................................................3–22

Locking Considerations.............................................................................................3–24

Other Considerations.................................................................................................3–30 Buffer Pool Tuning...................................................................................................3–30 Dynamic Statement Caching ...................................................................................3–30

Performance Tuning Considerations SAP AG

Introduction

3–2 March 2002

IntroductionPerformance monitoring and tuning in the SAP system environment is a complex andchallenging task. This chapter is intended to be a collection of tuning steps that haveshown to be notably relevant and beneficial with respect to SAP Systems. Depending onyour requirements, additional tuning steps will be necessary.

To evaluate the effects of tuning and to detect the development of new bottlenecks andperformance deficiencies, you need to establish a base for performance evaluation. Thiscan be done by collecting and storing the performance data over a longer period of time,but most importantly before and after any tuning activities.

Most of the aspects documented in the section “Pre-SAP-installation performance tuningconsiderations” in the IBM documentation Planning Guide: SAP Web Application Servershould be observed after installation as well.

The following is a short summary:

• Apply the recommended service to the z/OS and DB2 code levels.

• Utilize WLM to prioritize work according to your objectives.

• Monitor and tune the ICF catalog performance.

• Observe the required and highly recommended DB2 system parameters.

The system parameters that are categorized as recommended initial values should beadjusted based on the site-specific workload.

• Switch off unnecessary traces.

The only traces that should be active in addition to those recommended in the sectionDB2 Setup in the SAP installation documentation are:– DB2 Statistics trace class 3. This trace should be active all the time.– DB2 Accounting trace classes 2 and 3. These classes should be active most of the

time. Only during major imports of data, for example, Client Copy or at times ofhigh overall CPU utilization of the system can you consider switching off theaccounting class 2 trace.

– DB2 performance trace IFCID 318 This trace provides valuable data for thestatement scope statistics.

The SAP system aims to ensure that the DB2 Accounting trace classes 2 and 3 andthe performance trace IFCID 318 are always on. For more information, see thesection “Automatic Start of DB2 Traces” in the chapter “Monitoring andPerformance”.

• Maintain the recommended SAP profile parameters settings.

The following sections describe some of the considerations that are relevant afterthe installation of your SAP system and for daily usage of the component.


Virtual Storage Considerations

March 2002 3–3

Virtual Storage ConsiderationsDynamic statements caching and long running DB2 threads are characteristics of SAPsystem environments that place a significant stress on the virtual storage in one of theDB2 address spaces, DBM1.This section provides estimates on storage consumption bymost of the resources typically used in the SAP system as well as hints and tips forvirtual storage planning, monitoring, and tuning.

Recommendations

To avoid problems related to the excessive usage of virtual storage, the fiverecommendations presented below should be observed.

1. Stay current with DB2 service level, particularly fixes and enhancements in the areaof storage usage. In general, that means:– Apply cumulative preventative maintenance, usually two to four times a year.– On a monthly basis, apply HIPERs marked as pervasive and HIPERs relevant to

your workload.– Note that the DB2 PTFs that are critical for SAP system environments are documented in SAP Note 81737.

2. Do not overcommit virtual storage by specifying inappropriate parameters thatinfluence its usage. The following is not an exhaustive list of consumers of the DBM1storage, but it represents the most important ones:– Threads Storage– Dynamic Statements Cache Storage– Open Data Sets– Compression Dictionary– System Storage – Buffer Pools– EDM Pool– RID Pool– Storage CushionThe storage consumption for each of these resources is influenced by theircorresponding parameters settings. See the section Virtual Storage Usage Estimatesfor more details. In any case, make sure you leave at least 250 to 300 MB free abovethe line in DBM1 as “headroom” for performance tuning, workload growth, andservice ability.

3. Do not overcommit virtual storage by placing more than one production system in thesame DB2 subsystem. With production systems, the MCOD scheme is only applicablein DB2 data sharing environments with dedicated DB2 members.

4. Set the DB2 system parameters as follows:– CONTSTOR = YES– SPRMSTH = 1048576.

You can do this by editing the macro DSN6SPRC in the library SDSNMACS. Locate the line & SPRMSTH SETC ‘2097152’ and update the size to 1048576. Then re-assemble and link the file DSNZPARM by submitting the job DSNTIJUZ.



3–4 March 2002

Note that some DB2 PTFs may undo the changes and you may have to reset the parameters.

5. Activate the SAP profile parameters rdisp/wp_auto_restart andrdisp/noptime to periodically recycle SAP work processes. That will cause the de-allocation of the corresponding DB2 threads and, consequently, the release of theassociated storage. Initially set the values to 86400 and 87000, respectively. See SAPNote 182207 for additional details on the usage of these parameters.

6. Regularly monitor virtual storage usage.RMF provides historical and snapshot reporting on the virtual storage. You can use itto detect trends and determine if there is enough storage left for increasing DB2 pools(buffer pools, EDM pool, and so on) to increase overall system performance.

Virtual Storage Usage Estimates

In many cases in the calculations that follow, the constants and parameters values areaverage values that are likely to match most SAP system installations. Be aware,however, that the exact values depend on the particular workload characteristics and canvary. The information presented here should therefore be regarded as “ballparkestimates” of the virtual storage usage.

Thread Storage

Let T be the number of allocated threads. If the DB2 subsystem manages only the SAPSystem (which is strongly recommended in any case), the number of allocated threadswill be equal to the total number of configured SAP work processes. Note that T is notnecessarily equal to the value of system parameter IDBACK which is typically somewhatlarger to allow for a possible increase in the number of SAP work processes withoutrestarting DB2 and other batch connections. The total amount of storage that needs to bereserved for the allocated threads is calculated as follows:

thread storage = T * 1.3 MBAn important assumption is that the system parameter CONTSTOR is set to YES and thevalue of SPRMSTH in the macro DSN6SPRC is set to 1048576.

Dynamic Statements Cache Storage

Let M be the larger of these two:

• MAXKEEPD * 1.1

• Maximum number of statements whose skeletons ( SKDS) can be cached in theEDM Pool. As a rule, assume that the average SKDS size is 10 KB.

The total amout that needs to be reserved for this storage is calculated as follows:

dynamic statements cache storage = M * 4K + MAXKEEPD * 1.1 *18 KB



March 2002 3–5

We recommend that you start with MAXKEEPD = 10000 and adjust it downwards basedon the monitoring of virtual storage usage and local cache hit ratio. For EDM Pool, werecommend that you use a data space to store the SKDSs, for example, to set DB2 systemparameter EDMDSPAC to a value of 100000. Adjust it upwards based on the monitoringof the global cache hit ratio. If you run multiple ICLI server instances, we recommend toassociate them with the same user ID. For more information, see “User ID to run theICLI server and the DB Alert Router” in the IBM documentation Planning Guide: SAPWeb Application Server, to avoid multiple EDM Pool cache entries for the identicalstatement.

Storage for Open Data Sets

The total amount that needs to be reserved for this storage is calculated as follows:storage for open data sets = DSMAX * 1.5K where DSMAX is the system parameter thatcontrols the number of concurrently opened data sets. We recommend that you setDSMAX to 6000.

Storage for Compression Dictionaries

Let C be the number of compressed data sets that are opened at a time. The total amountthat needs to be reserved for this storage is calculated as follows: storage for compressiondictionaries = c * 64 KB.

The value of 64 KB is the upper limit of the compression dictionary size (the size couldalso be 4, 8, 16, or 32 KB). Note that this amount can be significant if most of yourtablespaces are compressed, especially after processes that open lots of data sets (such asClient Copy). Therefore, consider compressing only those tablespaces where there is asignificant savings in DASD (and other benefits of compression) and bear in mind that itcomes with the price in virtual storage.

System Storage

There is a fixed amount of storage that DB2 needs for its operations.It varies dependingon whether data sharing is used or not:

No data sharing: 231 MB

Data sharing: 312 MB

Buffer Pools

The amount of storage consumed by the DB2 buffer pools depends on how large theyhave been configured by the user. The size of individual buffer pool is controlled by thesystem parameter VPSIZE that is specified for each buffer pool separately. VPSIZEspecifies how many pages (page size can be 4 KB, 8 KB, 16 KB and 32 KB) should begiven to a particular buffer pool. So, when calculating the amount of storage occupied bya buffer pool, multiply its VPSIZE by its page size. Note that buffer pools can reside indata spaces which could be a significant relief for the DBM1 address space.Nevertheless, we do not recommend using data spaces for buffer pools unless they arefully backed by the real storage. Using hiperpools is a very efficient way of reducing theDBM1 virtual storage shortage exposure. Therefore, if necessary, reduce the size ofvirtual pools and define large hiperpools but make sure to back them with sufficient



3–6 March 2002

expanded storage. The DBM1 address space contains some control structures that residethere regardless of whether virtual (primary) pools, hiperpools or data spaces are used forbuffer pools.

The amount of storage for these structures is calculated as follows:

For virtual pools and data spaces: VPSIZE * 128 bytes

For hiperpools: HPSIZE * 56 bytes

If you use data spaces, there is an additional amount of 10 to 40 MB that needs to bereserved in DBM1.

EDM Pool

The size of EDM Pool is defined by the user using the system parameter EDMPOOL. Notethat the skeletons of dynamic statements can be moved from the EDM Pool into a dataspace. The system parameter EDMDSPAC controls the size of the data space.

RID Pool

This pool is used for list prefetch and multiple index access processing. Its size isspecified using the system parameter MAXRBLK.

Storage Cushion

In extreme situations, when the virtual storage utilization is critically high, DB2 triggersa process that releases lots of storage. This process has a considerable CPU overhead, soyou should try to avoid its frequent occurrences. The threshold at which the process istriggered is a function of the maximum number of open data sets (DSMAX), themaximum number of allocated threads (CTHREAD) and maximum number of DDFthreads (MAXDBAT). For a rough estimate, use the following calculation:

(40000 + (DSMAX * 500) + (20*(CTHREAD + MAXDBAT) * 2000)) / (1024*1024)

If free storage in DBM1 is equal to or lower than this value, the storage cushion processwill be triggered. Obviously, you should take care to avoid overallocating any of theconstituent parameters as it unnecessarily increases exposure of frequently hitting thethreshold.



March 2002 3–7

Example

This example demonstrates estimating the storage usage and determining how muchof it we can assign to buffer pools. Assume that there are 300 SAP work processesand the relevant system parameters are set as follows:

• EDMPOOL = 60M• EDMDSPAC = 100M• MAXKEEPD = 10000 • DSMAX = 6000• MAXRBLK = 100M• IDBACK = 320• CTHREAD = 350• MAXDBAT = 0• The DB2 system is non-data sharing.• The number of compressed, concurrently opened data sets = 50.

The amount of storage that should be reserved is:

• Threads Storage: 300 * 1.3 MB = 390 MB• Dynamic Statements Cache Storage: 11000 * 4KB + 11000 * 18KB = 242MB• Open Data Sets: 6000 * 1.5 KB = 8.8 MB• Compression Dictionary: 50 * 64KB = 3.2 MB• System Storage: 231 MB• EDM Pool: 60 MB• RID Pool: 100 MB• Storage Cushion: 16.3 MB

which makes a total of around 1052 MB. Therefore, the available storage for bufferpools is 2032 MB - 1052 MB = 980 MB. If we allocate 100000 4 KB page buffers,2000 8 KB page buffers, 1000 16 KB page buffers, and 1000 32 KB page buffers invirtual pools and assign the corresponding hiperpools with three times as many pages,the DBM1 storage demand will increase as follows:

10000 * 4 KB = 390.6 MB2000 * 8 KB = 15.6 MB1000 * 16 KB = 15.6 MB1000 * 32 KB = 31.3 MB104000 * 128 KB = 12.7 MB312000 * 56 KB = 16.7 MB

which makes a total of 482.5 MB (apparent inconsistencies in the use of units in theseequations are due to the fact that here the settings, and not the values, have beenstated). You should never exhaust all of the available storage as some of it is used forsmaller, but still important storage pools. Also, the sizes given for the threads storageand dynamic statements cache storage can occasionally be exceeded, in which caseyou need some reserve.



3–8 March 2002

Monitoring

Regular monitoring of the virtual storage usage can help you avoid situations wheresevere storage shortages are encountered. The RMF Monitor I Virtual Storage: PrivateArea report provides historical view of virtual storage usage and identifies potentialstorage shortages. Use the following calculation to find out the amount of storageavailable above the 16 MB line: Available storage = X-Y-Z, where

X = REGION ASSIGNEDY = MAX LSQA/SWA/229/230 PAGES ALLOCATEDZ = MAX USER REGION PAGES ALLOCATED

The following graphic is an example of the relevant RMF report. The values used in theabove calculation are in italics. In this particular example, the amount of availablestorage is 1862 - 1273 - 21.7= 567.3 MB.


Setting Optimal SAP Profile Values

March 2002 3–9

Setting Optimal SAP Profile ValuesThere are numerous SAP profile parameters that are extremely important for awell-performing SAP system component. The sizes of application server storageareas for buffering SAP objects and the number and type of work processes areonly a couple of them that clearly indicate the importance of setting them correctly.The SAP online documentation provides lots of details on these parameters; SAPBasis consultants and EarlyWatch service are likely to set or recommend the valuesthat are optimal for the circumstances characteristic for your installation.

In any case, make sure that these selected SAP parameters have the followingvalues:

rsdb/prefer_fix_blocking = 1rsdb/prefer_in_itab_opt = 1rsdb/prefer_union_all = 1rsdb/max_blocking_factor = 10rsdb/min_blocking_factor = 3rsdb/max_in_blocking_factor = 35rsdb/min_in_blocking_factor = 6

The SAP profile parameters are contained in /usr/sap/.../SYS/profile


Customizing the SAP Objects Topology

3–10 March 2002

Customizing the SAP Objects TopologyAfter the installation of a SAP system component, there is a large number of datasets backing thousands of related DB2 tablespaces and index spaces. For a detaileddescription of how the SAP tables and indexes map into the DB2 stogroups,databases, and tablespaces, see Chapter “Storage Management”. It is very likely that thetables/indexes-to-volumes mapping will not be optimal for your DASD. For example,two or more heavily used tables or indexes may reside on the same volume, causingDASD contention and long I/O times when accessing the tables and indexes.

Unless your DASD subsystem supports contention-reducing features such as ESSParallel Access Volume and Multiple Allegiance, you should find out which tablesand indexes are most frequently accessed in your environment and isolate them onseparate volumes. Call transaction ST10 to determine the access frequency andpattern on a per-table basis.

In general, SAP data compresses very well. For more details on how to decidewhether to compress a tablespace and how to do it, see the IBM documentation DB2 forOS/390 and z/OS Administration Guide.


Ensuring Optimal Access Paths

March 2002 3–11

Ensuring Optimal Access PathsThe DB2 Optimizer is cost-based. The access path for a given statement isinfluenced by the:

• Statistics for tables referenced in the statement and associated objects such astablespaces, indexes and columns

• Size of the buffer pool

• Central processor model

The statistics are stored in a number of DB2 catalog tables. DB2 provides a utility,RUNSTATS, that collects the necessary statistics and updates the catalog. Thestatistics collected by RUNSTATS can also be used as an indicator whether atablespace or index should be reorganized, and for calculating the spacerequirements for a table.

The most important questions related to the use of RUNSTATS are:

• When is RUNSTATS due?

• What RUNSTATS options should be used?

• Will updating catalog statistics with RUNSTATS ensure optimal access path?

The following sections address these questions and give practical advice onmaintaining the catalog statistics in SAP System environments. For full details onRUNSTATS and other DB2 utilities referenced here, see DB2 for OS/390 UtilityGuide and Reference.



3–12 March 2002

When is RUNSTATS due?

Stale statistics are one of the most common reasons for DB2 not selecting theoptimal access path for a given statement. For example, the table’s size andcardinalities of its columns can significantly change as a result of heavy insertactivity. If RUNSTATS has not been run after such an activity, the input into theDB2 Optimizer access path selection process is outdated and that can result in aless than optimal access path.

So, why not schedule RUNSTATS very frequently? Well, it does not come for free.It consumes a considerable amount of CPU that might not be available at anygiven time. And, on the other hand, running it indiscriminately on all the tablestoo frequently does not necessarily result in better input for access path selection.For example, the statistics for a large, static table might not change enough to warrantspending CPU on refreshing it, for example, in this case setting the values to what theyalready were. Also, if RUNSTATS is run on all the tables, it opens all theunderlying data sets and a number of them (close to the system parameterDSMAX) remain open thus affecting the amount of available storage as well as arestart after an abnormal termination and shutdown times.

SAP transaction ST10 is a very useful tool for monitoring workload on a per-tablebasis. Its output is a list of tables and the operations statistics for the tables, suchas the number of inserts, updates and deletes for various time intervals: sincestartup, today, previous day, this week, previous week, this month, previousmonth. You can use these statistics to assess which tables need RUNSTATS: ingeneral those with a considerable number of changes (relative to the table’s size)since the last time RUNSTATS was done.

Also, the SAP CCMS Monitor Set (transaction RZ20) identifies tables withstale or missing catalog statistics. It is based on the same data transaction thatST10 uses as its source. See the section “CCMS Monitor Set” in the chapter “Monitoringand Performance.

An alternative way of deciding if RUNSTATS is due on a particular object is to runthe COPY utility with the CHANGELIMIT REPORTONLY option. This produces areport (without actual copying) that includes the percentage of pages changedsince the last time an image copy was taken. Of course this method assumes that aRUNSTATS is run every time an image copy is taken.



March 2002 3–13

RUNSTATS should be scheduled at the following occasions:

• As soon as convenient for the tables with a considerable number of changes.

• After the initial load, migration and upgrade. There is a separate step in the SAPsystem installation procedure where RUNSTATS is performed for all the tablesin the system. This is the time when RUNSTATS should be run for catalog tablesas well, because of a large number of new data base objects.

• If Batch Input is used to import data into the system, it is important to doRUNSTATS not only after, but also at least once (in the first quarter, not too soonafter the start) during the process. Namely, Batch Input includes queries as wellas inserts and the queries need current statistics in order to use optimal accesspaths.

• For the tablespaces and indexes that have just been reorganized. The mostefficient way to accomplish this is an inline RUNSTATS execution (the REORG’sSTATISTICS option).

• For the tablespaces and indexes that have just been recovered.

• For the newly created indexes. If the index is created using the REBUILD utility,consider inline RUNSTATS invocation.

• For newly created and populated tables. You can identify tables for whichRUNSTATS was never executed by checking the STATSTIME catalog column: thevalue is ’0001-01-01.00.00.00.000000’ for tables with no RUNSTATS.

• To invalidate cached statements. The cached statements are implicitly invalidatedevery time a RUNSTATS TABLESPACE is run on the tablespace that contains thetables referenced by these cached statements. A statement is invalidated in orderto let the Optimizer reprepare it and take into account some new informationthat was not available the first time the statement was prepared.

Some typical cases are:

– A new index is created. Note that it is not enough to run RUNSTATS INDEX only: you need to run RUNSTATS TABLESPACE for the corresponding tablespace.

– The catalog statistics have been manually updated to influence the Optimizer access path selection. In this case you have to preserve the catalog statistics, so run RUNSTATS TABLESPACE UPDATE NONE.

What RUNSTATS options should be used?

In general, the following RUNSTATS specifications are recommended for collectingand updating catalog statistics:

• For all the tables in a given tablespace:

RUNSTATSTABLESPACE tablespace nameINDEX (ALL)



3–14 March 2002

KEYCARDTABLE(ALL)SAMPLESHRLEVEL(CHANGE)

• For a single table in a given tablespace:

RUNSTATSTABLESPACE tablespace nameINDEX (index1 name, index2 name, ...)KEYCARDTABLE(table name)SAMPLESHRLEVEL(CHANGE)

• For a given index:

RUNSTATSINDEX (index name)KEYCARDSHRLEVEL(CHANGE)

For most SAP Systems the above specified RUNSTATS options providethe catalogstatistics necessary for selecting the optimal access path. However, for SAP BW,additional catalog statistics can be beneficial. This isthe frequency distribution forcombinations of concatenated key columns.It iscollected if the RUNSTATSFREQVALoption is specified. These statistics are also beneficial for some statements where ABAPhints are used.

On some rare occasions even more detailed statistics are necessary. This isfrequency distribution for any individual column (not only the first column in akey) and for concatenations of non-key columns. There is an IBM tool, DSTATS,that provides this functionality. It is available by contacting the IBM service.

DB2 allows you to collect catalog statistics inline within the REORG and REBUILDINDEX utilities. This feature is requested by the STATISTICS keyword followed byusual RUNSTATS options) on the REORG and REBUILD specifications.

If you need to run RUNSTATS for a large number of objects, consider runningmultiple RUNSTATS jobs in parallel. Note that running RUNSTATS jobs in parallelcan reveal an error in the z/OS setup: Scheduler Work Area (SWA) must bedefined above the 16 MB line.



March 2002 3–15

Will updating catalog statistics with RUNSTATS ensure optimalaccess paths?

The answer is: yes, in a large majority of cases. However, there are some importantexceptions that must be addressed by maintaining the statistics by updating thecatalog ’manually’, for example, by using the UPDATE statement. These cases includesomespecial purpose tables that have to be accessed in a particular way regardless oftheir catalog statistics. The access path considerations for these cases are describedin the section “Access path considerations for special SAP tables”.Special considerations also apply to so-called volatile tables. If RUNSTATS isexecuted on a table that is empty or very small (occupying just few pages), thestatistics collected at that time can be very misleading if the table subsequentlygets heavily inserted. This can often happen on the tables with transient data, orany kind of queue tables in general. Other examples are tables that get archivedand significantly reduced in size, but only temporarily. Batch Input is also prone tosuch problems, since the tables are typically empty initially, and get inserted veryrapidly while queries are operating on them during the process. A wrong accesspath can also cause a heavy lock contention, including deadlocks.

Fortunately, we can avoid most of these problems by telling the Optimizer to use aheuristic approach instead of cost based optimization if, and only if, the tables are‘small’ (say less than 10 pages) or empty. For such a table the following access pathshould be selected:

If there is an index that has at least one matching column for given statement’spredicates, a tablespace scan should be avoided. If there are more than one such anindex, choose the one with the largest number of matching columns. If there are stillmore than one qualifying, then choose the one that provides ordering (if applicable).No list prefetch nor sequential prefetch should be selected.

The way to achieve this is simple: you only need to set the DB2 system parameterNPGTHRSH. Its value is taken into account during access path selection. For agiven table, if NPAGES is less than the NPGTHRSH value, an index access for thetable will be preferred over a tablespace scan. The recommended value is 10.

The most complicated case where RUNSTATS itself is not good enough is thestatements with a large impact of host variables values. Namely, in most SAPproducts, especially in the core applications, the statements are prepared withoutknowing the values of host variables. Consequently, the frequency distribution ofcolumn values is not useful and is not used in the access path selection process(this is why we do not in general request collecting these statistics). As a result, theOptimizer might not select the most efficient access path. If that is the case, theproblem statement should be modified by a so-called hint. These hints ensure thatthe Optimizer prepares the problem statement at the time when the host variablevalues are known.

The hint is specified by adding any of the ABAP clauses SUBSTITUTE LITERALSor SUBSTITUTE VALUES (see SAP Note 129385 for full details). If the access path



3–16 March 2002

does not improve even after specifying the hint, collect the additional catalogstatistics (by specifying the RUNSTATS FREQVAL option). In some rare cases evenmore detailed statistics might be needed (collected via DSTATS).

Access path considerations for special SAP tables

The following special SAP tables need to be accessed in a special way:

• Asynchronous update protocol tables: VBHDR, VBMOD and VBDATA.

• TRFC and QRFC tables: ARFCSDATA, ARFCSSTATE, ARFCRDATA,ARFCRSTATE, TRFCQDATA, TRFCQSTATE, TRFCQOUT, TRFCQIN, andTRFCQINS.

• SAP cluster tables. A complete list of these tables is returned by the query:SELECT * FROM <SCHEMA>.DDNTTWHERE TABFORM = ’T’ AND TABTYPE = ’C’ WITH UR

• ABAP export/import tables, also called ABAP clusters. A complete list of thesetables is returned by the query:

SELECT TBNAME FROM SYSIBM.SYSCOLUMNS XWHERE TBCREATOR=’<SCHEMA>’AND NAME = ’CLUSTD’AND COLNO = (SELECT MAX(COLNO) FROM SYSIBM.SYSCOLUMNSWHERE TBCREATOR = ’<SCHEMA>’AND TBNAME = X.TBNAME)

All of these special tables must be accessed in a particular way in order tominimize deadlock occurrences and optimize their performance. Their optimalaccess path should not be cost based (like for a large majority of other tables) but amatching index scan with neither sort nor list prefetch. If the tables are notaccessed as described above, there is a possibility of increased lock contentionincluding deadlocks. It is also likely that a less than optimal access path will beselected.



March 2002 3–17

To make sure that these tables are accessed properly, their catalog statistics need tobe maintained using the following corrective catalog updates:

UPDATE SYSIBM.SYSTABLESSET CARDF=-1, NPAGES=-1, PCTROWCOMP=-1

WHERE CREATOR=’<SCHEMA>’ AND NAME IN (list of specialtables);UPDATE SYSIBM.SYSINDEXES

SET CLUSTERRATIO=100, CLUSTERRATIOF=1,FIRSTKEYCARDF=-1, FULLKEYCARDF=-1, NLEAF=-1, NLEVELS=-1

WHERE TBCREATOR=’<SCHEMA>’ ANDTBNAME IN (list of special tables);

UPDATE SYSIBM.SYSCOLUMNSSET COLCARDF=-1, HIGH2KEY=’’, LOW2KEY=’’

WHERE TBCREATOR=’<SCHEMA>’ AND TBNAME IN (list of special tables);

DELETE FROM SYSIBM.SYSCOLDISTWHERE TBOWNER=’<SCHEMA>’ AND TBNAME IN (list of specialtables);UPDATE SYSIBM.SYSTABLESPACE

SET NACTIVEF=0, NACTIVE=0

WHERE CREATOR=’<SCHEMA>’AND NAME IN (SELECT TSNAME FROM SYSIBM.SYSTABLES

WHERE CREATOR=’<SCHEMA>’AND NAME IN (list of special tables))

AND DBNAME IN (SELECT DBNAME FROM SYSIBM.SYSTABLESWHERE CREATOR=’<SCHEMA>’AND NAME IN (list of special tables));

UPDATE SYSIBM.SYSTABSTATSSET CARD=-1, CARDF=-1, NPAGES=-1

WHERE OWNER=’<SCHEMA>’AND TSNAME IN (SELECT TSNAME FROM SYSIBM.SYSTABLES

WHERE CREATOR=’<SCHEMA>’ AND NAME IN (list of special tables))

AND DBNAME IN (SELECT DBNAME FROM SYSIBM.SYSTABLES WHERE CREATOR=’<SCHEMA>’ AND NAME IN (list of special tables));

Whenever you run RUNSTATS on the tablespaces that include these tables, youmust update the corresponding catalog statistics using the statements above.Therefore, the best practice is to perform the updates only once and keep thevalues by never running RUNSTATS on these tablespaces again. To determinewhether the tablespaces should be reorganized, run RUNSTATS but use optionsUPDATE NONE REPORT YES. This ensures that the indicators that signal a needfor reorganization will be collected and presented in the RUNSTATS report, but thecatalog statistics will not be updated.

Some of the special tables share multi-table tablespaces with other, regular tables.When you run RUNSTATS on these tablespaces to collect the statistics for theregular tables, you have to run the corrective catalog updates for the special tables afterRUNSTATS was run, using the statements above.



3–18 March 2002

Note that all of the aspects described here are taken into consideration whenRUNSTATS is scheduled by means of the SAP DBA Planning Calendar (transactionDB13).

Optimizing access to VBHDR, VBMOD, and VBDATA

The asynchronous update protocol tables (VBHDR, VBMOD, VBDATA) have aspecial purpose in the SAP System and are generally very frequently accessed.Consequently, it is very important to ensure an optimal performance for thestatements that refer to the tables.

There are three major areas in tuning the VB protocol tables. They are described inthe following sections.

Ensuring optimal access paths for the statements accessing the tables

As the tables VBHDR, VBMOD, and VBDATA belong to the category of ’special’SAP tables, the relevant details are described in “Access path considerations forspecial SAP tables” in the IBM documentation Planning Guide: SAP Web ApplicationServer.

In addition, ensure that only one index is defined for each of the VB protocol tables(VBHDR, VBMOD, and VBDATA). This is the primary index created when an SAP Systemis installed. Determine if any additional indexes are defined on the tables by checking:

• the ABAP DictionaryCall transaction SE11 and enter the name of a VB protocol table. On thenext panel, choose Indexes. If any index other than the primary oneexists, delete it.

• the DB2 CatalogUse the query:

SELECT TBNAME, NAME, UNIQUERULE FROM SYSIBM.SYSINDEXES WHERE TBCREATOR=’<SCHEMA>’ AND

TBNAME IN (’VBMOD’,’VBHDR’,’VBDATA’)ORDER BY TBNAME, NAME;

There should be only one index for each of the tables. It can be identified by theindex name suffix (it is .0. for primary index) and by the UNIQUERULE valueequal to “P”.

Assigning the VB protocol tables to dedicated buffer pools

When the SAP system is installed, all SAP tables, including the VBprotocol tables (VBDATA, VBHDR, VBMOD), are assigned to common buffer poolsand VBDATA is defined with a page size of 32 KB.

It is highly recommended to assign the VB protocol tables to a separate buffer poolwhose attributes match the tables’ access pattern.

Here is the procedure to accomplish this objective (note that some of the steps arealso required for partitioning the VB protocol tables; see “Partitioning VB protocoltables”):



March 2002 3–19

1. Make sure the SAP system is unavailable to others during the procedure.

2. Call transaction SE16 to check whether the update tables VBHDR,VBMOD, and VBDATA are empty. If they are not, process all of the outstandingupdates with SAP transaction SM13. You cannot continue with the subsequentsteps until all of the outstanding updates have been processed!

3. Import the transport KDOK000668 into your system. It is located in the directorysapservX:~ftp/general/R3server/abap/note.0122599, files: KDOK000668,KDOR000668.

As a result, the length of the domain VBDATA is shortened to 3800 characters

so that it fits into a tablespace with a 4 KB page size and each of the tables isisolated in a 4 KB tablespace of its own.

4. Check whether each of the tables VBHDR, VBMOD, and VBDATA has beenplaced in a separate 4 KB tablespace. If this is not the case, use SAP transactionSE14 to isolate them manually (see also Chapter 4 .Database Management.,section .Isolating and Combining Tables.

5. Stop the VBHDR, VBMOD, and VBDATA tablespaces by stopping theirassociated databases.

6. Assign the tablespaces and indexes to an unused buffer pool, for example BP4:ALTER TABLESPACE database-name.tablespace -name BUFFERPOOL BP4

7. Start the databases again.

8. Set the buffer pool parameters:ALTER BUFFERPOOL(BP4) VPSIZE(1000) VPSEQT(10) DWQT(70) VDWQT(50)

After you have made the changes, monitor the buffer pool (BP4). If any of thecritical thresholds are reached, apply the buffer pool tuning techniques describedin the SAP Note 82953 ,for example, decrease the deferred ‘write’ thresholds.

Partitioning VB protocol tables

This step is considered an advanced tuning procedure that is especially beneficialin data sharing environments. In non-data sharing environments it should beapplied when the performance related to the VB protocol tables is not satisfactoryeven after the two procedures described above have been performed.

1. Make sure the SAP System is unavailable to others during the procedure.

2. Call transaction SE16 to check whether the update tables VBHDR,VBMOD, and VBDATA are empty. If they are not, process all of the outstandingupdates with SAP transaction SM13. You cannot continue with the subsequentsteps until all of the outstanding updates have been processed!

3. If you have not done so yet, import the transport KDOK000668 into your systemand check whether the VB protocol tables have been isolated in their owntablespaces (see “Assigning the VB protocol tables to dedicated buffer pools” in the IBM documentation Planning Guide: SAP Web Application Server).



3–20 March 2002

4. Partition the VB protocol tables.Partioning is actively supported by transaction SE14 (see section“Partitioning Tables”, but since VBHDR, VBMOD, and VBDATA are multiplex tables, they cannot be converted. Consequently, you have to proceed as follows:

• Call transaction SE14.

• Choose Delete database table.

• Choose Storage parameters.

• Specify and save the storage parameters for the partitioning of the table. As apartitioning index use VBDATA’s primary key (index ID = ’0’). This primarykey encompasses the IP address of the application server.

Note that the IP address (in hexadecimal code) of the application server (andnot its name) is written to the primary key field VBKEY.

Here is an example:

There are four applications servers for the dialog processes. Their IPaddresses are as follows: 155.56.94.121 (hex 9B.38.5E.79), 155.56.94.121(hex 9B.38.5E.7A), 155.56.94.123 (hex 9B.38.5E.7B) , and 155.56.94.124(hex 9B.38.5E.7C). The system number is 11.

This results in the following mapping between the application server and theupdate key:155.56.94.121 -> ’9B385E7911...’155.56.94.121 -> ’9B385E7A11...’155.56.94.123 -> ’9B385E7B11...’155.56.94.124 -> ’9B385E7C11...’

Accordingly, you should use the following attributes for the partitioning:PART 1 VALUES(’9B385E7911’)PART 2 VALUES(’9B385E7A11’)PART 3 VALUES(’9B385E7B11’)PART 4 VALUES(X’FF’)

Also, specify buffer pool BP4 for each VB tablespace and index.

On the initial screen of transaction SE14, select Create database table.

5. Set the buffer pool parameters:ALTER BUFFERPOOL(BP4) VPSIZE(1000) VPSEQT(10) DWQT(70) VDWQT(50)

6. Change the SAP profile:dynp/trans_id_format=2

7. The following recommendations apply to data sharing environments only:

For the new tablespaces, set the storage attribute LOCKPART to YES.



March 2002 3–21

Establish proper affinity between VB* table partitions and application servers. For a setof application processes that are connected to a DB2 data sharing member, define thecorresponding update processes on the application servers that are also connected to thevery same data sharing member. The easiest way to achieve this is to disable update logon dispatch balancing and define the update processes at the same application serverwhere the corresponding dialog processes are defined. The related profile parametersshould be set as follows:

rdisp/vb_dispatching = 0

rdisp/vb_included_server = no entry (for example, blank)

rdisp/vbname = name of the local application server

for example, replacement variable $(rdisp/myname)

Note, however, that this method could create a bottleneck if the update workprocesses defined at an application server cannot service the load generatedat that application server or, in the worst case, if that application server goesdown. If you need to address this, use the method (so-called multiplexing)described in SAP Note 109515.


Clustering Index

3–22 March 2002

Clustering IndexBad transaction response times can be caused by excessive I/O for specific statements

When a row is inserted in a table, DB2 tries to place it nearby the rows that have similarkey value for the index known as the clustering index. Placing the rows in this mannergreatly improves subsequent retrievals of range of rows that are accessed using theclustering index. Namely, in this case the rows can be read with fewer I/O operations: thepages read are likely to contain more rows that need to be retrieved and moreover DB2can maximize effects of its sequential prefetch feature.

Obviously, there can be only one clustering index. When SAP defines tables and indexesit is not known which of them should be defined as clustering because the usage andaccess patterns to the tables is mostly customer specific. So, SAP makes an arbitrarychoice and specifies that the primary index (index 0) is clustering. In most cases thatproved to be optimal choice. But there are exceptions. It is possible that a table isaccessed index-sequentially and mostly via an index that is not clustering.That results in less than optimal response times for these statements. The index-sequential access occurs in most cases for the range predicates (BETWEEN, >,<),predicates that include only a prefix of an index or for accesses through a non-uniqueindex. You can identify these statements in the ST04’s Cached Statements output. If theyhave relatively large average response times and these times are caused by I/Osuspensions, you should consider the following recommendations.

If there are statements that access a table index-sequentially through an index that is notdefined as clustering and this is a predominant way that table is accessed, theperformance can be improved by specifying that particular index as clustering. You needto drop the existing clustering index and the index that you want to specify as clusteringand then recreated them with changed clustering attribute. After that you shouldreorganize the corresponding tablespace.

This process is not done using the ABAP Dictionary but natively within DB2. Because ofthis it needs to be done very carefully. You need to ensure that the indexes are createdwith identical key fields and exert special attention to the primary index. Namely, itguarantees the uniqueness in the table and forgetting to recreate it can lead to datainconsistency problems. Therefore we strongly recommend that the process is done byan experienced DB2 DBA who understands all the ramifications. After having re-createdtable and indexes in the database you should check the consistency of these databaseobjects with transaction SE14 ‘Extras→Database object→Check’.

There is a special situation where the ABAP Dictionary can be used to change theclustering attributes. It involves table partitioning. Namely, partitioning is supported byDDIC and as part of defining the partitioning index (this index must be clustering) theclustering attribute can be changed (if the partitioning index is not the primary index).For details on how to partition tables, see section “Storage Parameters” in chapter“Storage Management”.

Note that a transport or SAP release upgrade that would change the structure of the tablein such a way that the table needs to be recreated would reinstate the primary index as theclustering index. In this case you would need to repeat the process of changing the


Clustering Index

March 2002 3–23

clustering index. This does not apply to partitioned tablespaces for which all theattributes including clustering are preserved.The bottom line is that you should consider this tuning step only if you understand theabove described considerations and there are statements that would be significantlyimproved through tablespace reclustering.


Locking Considerations

3–24 March 2002

Locking ConsiderationsThe following points need to be observed in order to avoid locking problems suchas long suspensions, timeouts, and deadlocks.Parameter settings

Ensure that the following recommendations are observed for the locking-relatedparameters and options:

• System parameters

– NUMLKUS = a value between 500000 and 20971520– PC = YES– DEADLOK = 5,1– IRLMRWT = 600– XLKUPDLT = YES– RELCURHL = YES– SMFSTAT=1,3– EVALUNC=YES (applies to DB2 V7 only)

• Bind options

– ISOLATION=UR– CURRENTDATA=YES– RELEASE(COMMIT)

• DDL options– LOCKSIZE=ROW– LOCKMAX=1000000 (for NUMLKUS > 1000000, otherwise adjust it

accordingly)– LOCKPART=YES

Lock Escalations

Applications that perform massive updates and deletes and do not commitfrequently can potentially accumulate a large number of locks. This regularly has anegative effect on the overall system performance and throughput. The reasons aremultifold:

• Increased lock waits due to contentions with other concurrently runningtransactions and programs, which can result in time-outs and deadlocks.

• Increased paging.

• Increased CPU consumption.

• Potentially severe availability exposure in case of an extremely high number oflocks requested and held:

– The IRLM (the DB2 lock manager) can manage up to approximately 8000000concurrently held locks. Once this limit is reached, the report or transactionthat requests additional locks will be abnormally terminated with the’resource unavailable’ symptom (SQL return code -904). In many cases this is



March 2002 3–25

the very application process that accumulated all these locks and performed a large number of updates that now need to be backed out, for example, the

application must do a rollback. Consequently, the back out process takes very long (much longer than the time the application spent until it abended). During this longtime, the affected resources (including the IRLM itself!) cannot be accessed byother transactions and reports.

– In data sharing environments the number of locks held concurrently isadditionally limited by the size of the Coupling Facility (CF) lock structurewhich must be resident in the central storage (therefore, it is, like IRLM,currently limited to 2 GB). Furthermore, the storage allocated to the lockstructure is shared by the Lock Hash Table and the Record List Entries (RLE)sections. The initial split in terms of relative storage allocation is eitherexplicitly specified by means of the parameter IRLM HASH

IRLM 2.1 APAR PQ44114) or controlled by an internal IRLM algorithm. Themaximum number of modify locks related to database update processing thatcan be concurrently held and propagated to the CF is limited by the size of the RLEsection. The actual number of modify locks that can be held in a given RLE section sizeis dependent on the CF Level and the level of z/OS (for more details, seehttp://www.ibm.com/servers/eserver/zseries/pso/cftable.html). For example, if the CFlock structure size is 256 MB, the number of propagated locks that can be concurrentlyheld might be around 1650000. Once such a limit is reached (or, more precisely, 90% ofthe limit values), new modify lock requests will be rejected and application processeswill abnormally terminate with -904. Like in the IRLM storage exhaustion, long and verydisruptive backouts would follow.

– If the DB2 subsystem abnormally terminates for any reason, the restart wouldtake very long time if a large number of locks were held at the time of theabend.

Furthermore, in data sharing environments, where a single subsystem failuredoes not result in an outage, the large number of modified locks, for example,propagated to the CF, held would affect the entire sysplex. Namely, it ispossible that the surviving members do not have the storage capacity to holdretained locks for the failed member.

The exposure of encountering these problems is likely to increase in time becausethe growth of the database will result in mass updating, non-committingtransactions and reports requesting and holding ever more locks.

The problems can be prevented by ’lock limit aware’ application coding and byusing DB2 means to reduce the number of locks held concurrently. Most SAPdelivered programs are written in such a way. The problems are more likely to beencountered with user-written programs, which need to be reviewed to ensure anappropriate commit frequency.

In addition, DB2 also provides mechanisms for limiting the number of locksconcurrently held: the system parameters NUMLKUS and NUMLKTS, and thetablespace attribute LOCKMAX. The system parameter NUMLKUS sets a limit onthe number of locks any individual DB2 thread can hold. Once this limit is



3–26 March 2002

reached, the program that accumulated these locks will terminate with sqlcode-904. The maximum value for NUMLKUS is 2097152 (make sure that DB2 APARPQ52651 has been applied) and it is recommended to use it as an initial, first-cutvalue. Setting a lower value for NUMLKUS helps you to detect offendingprograms earlier and is especially recommended for test systems. In mostproduction systems (except the Retail component), a lower value for NUMLKUS isacceptable, but it should not be lower than 500000.

The system parameter NUMLKTS sets the default for the tablespace attributeLOCKMAX. If the number of locks on a particular tablespace exceeds theLOCKMAX value, these locks will be replaced by a single tablespace-scope lock(note that the LOCKMAX is enforced on a per thread, per tablespace basis). Thisprocess is called lock escalation and it can eliminate the occurrence of IRLM andCF lock structure exhaustion.On the other hand, lock escalations do not necessarily address all lock contentionproblems. They can lead to deadlocks, but it is very likely that the deadlock victim(the process that needs to backout) is a process for which the backout is least

expensive. This addresses the issue of long backouts caused by IRLM or CF lockstructure exhaustion. Another challenging aspect of lock escalations is coming up with anoptimal value for LOCKMAX. This is very customer-specific and depends on theparticular workload and the available central storage resources. If set too high, it allowsthe transactions and reports to hold too many locks, which leads to the problemsdescribed earlier. If set too low, it causes lock escalations too frequently, with theresulting negative consequences.

For example, if LOCKMAX is set too low, it might happen that an application processthat has acquired more than LOCKMAX locks triggers a lock escalation that in turncannot be successfully executed because other applications are holding non-compatiblelocks.

After the timeout period, the escalation triggering application process would receive a -913 (timeout) and would need to rollback. Had the LOCKMAX value been higher, theapplication might have completed without lock escalation.

With NUMLKUS set to 2097152, we recommend using an initial, first-cut value of1000000 for LOCKMAX. This value can be adjusted by the customers dependingon the above described site-specific considerations and the NUMLKUS setting.As said earlier, holding a large number of locks is not recommended. The lockescalation mechanism helps avoid serious consequences, but it is still the bestapproach to identify the transactions and reports that requested and held so manylocks and try to change these applications, for example,by inserting commits if theapplication logic allows it) to reduce the number of locks held. For SAP-writtenprograms, open an SAP problem message, for user-written programs, talk to theapplication developers.

There are a number of ways to identify these critical transactions and tablespaces:

• Monitor the maximum number of locks that are held by individual DB2 threads.Transaction ST04 provides the Thread Activity: Thread List panel where asnapshot of the currently opened DB2 threads is reported. One of the columns is



March 2002 3–27

’Max Locks Held’, which reports the maximum number of locks held by thethread at any time since its allocation. Sort the thread list by that column in adescending order and investigate the corresponding work processes for whichtransactions, reports and tables have been involved in acquiring and holdinglarge number of locks. Transaction SM66 displays which tables are beingaccessed by which work process.

• Monitor fields Executions, Getpages, Rows Processed and Rows Examined bythe individual update, delete and insert statements reported in the ST04 CachedStatements Statistics panels. This could can help you determine whichtablespaces need special attention.

• Monitor the number of changes per table in transaction ST10. Again it canserve as a hint on where to go next.

• The long-running, non-committing units of recovery do not necessarily hold alarge number of locks, but are definitely worth furter investigation. They can bedetected by using the system parameter UR CHECK FREQ on panel DSNTIPB.

(ZPARM URCHKTH), which specifies the number of checkpoint cycles tocomplete before DB2 issues a warning message to the console andinstrumentation record 313 for an uncommitted unit of recovery. For example, if yourcheckpoint cycle is every 10 to 15 minutes, specify 1 for the value of UR CHECKFREQ.The SAP CCMS Monitor Set (transaction RZ20) identifies long-runningunits of recovery. For more information, see the chapter “Monitoring and Performance”.

• Every time an escalation occurs, DB2 message DSNI031I is written to the z/OSconsole. The message identifies the tablespace and thread for which escalationoccurred. From the thread information fields you can identify which applicationserver and which work process were involved in the escalation and from herewhich transaction or report triggered it.Apart from enabling lock escalation you should ensure that the IRLM and CF aresized to maximize the number of locks that can be concurrently held. For theIRLM, specify PC=YES in the IRLM start up procedure and set the IRLM regionsize to zero.In data sharing environments, you additionally need to consider the couplingfacility lock structure size. The CF lock structure is split between the Lock HashTable and Record List Entries sections where only the latter is relevant in terms ofthe number of modify locks that can be concurrently held. The split can beexplicitly specified by means of the IRLM parameter HASH and the INITSIZEvalue for the LOCK1 structure in the CFRM policy (make sure that the IRLM 2.1APAR PQ44114 has been applied).The difference between INITSIZE and HASH is the storage allocated for themodified locks, for example, the RLE section. Once the RLE section size isdetermined, you should adjust the lock escalation trigger parameter (LOCKMAX) foryour tablespaces. You can calculate the maximum LOCKMAX value that makessense for given INITSIZE and HASH values based on the fact that a single lock entryin the RLE takes approximately 160 bytes, but it will vary based on CF Level andlevel z/OS. For example,, if you set INITSIZE to 384 MB and HASH to 128, the RLE



3–28 March 2002

section size will be 256 MB, and it can hold approximately 1650000 lock entries(rounded down for safety). Therefore, setting the LOCKMAX value higher thanthat would not shield you from exhausting the structure even by a single threadaccessing a single tablespace.

The actual INITSIZE and HASH values you will use depend on the amount ofavailable central storage on the CF allowing for structure failover from thealternate CF.

Note that the entire lock structure must be backed by the central storage. Ofcourse, keeping the number of false contentions small (directly affected by the sizeof the Hash Table) should be another objective, but that is beyond the scope of thistext.

Identify Long-Running Read-Only Reports

As we have seen in the previous section, not committing regularly in the updatetransactions and reports has a negative impact on the overall system. However,application programmers often do not consider that even read-only transactionsand reports need to be committed regularly in order to improve the overallconcurrency in the system. This is because some locks are acquired withinread-only processes as well and these locks are released only at commits.

For example, pageset intent locks and so-called claims are acquired at differentphases of statements prepare and execute time. In general, they do not affectconcurrent DML statements. However, the concurrent DDL statements, some DB2commands, and utilities can be negatively affected. Also, some tables are readusing the Read Stability isolation level (cluster tables and pool tables) whichacquires shared locks. The shared locks are not compatible with concurrentupdaters and can result in lock contentions including deadlocks and timeouts.

Typical problems that can be expected in an environment with long-runningread-only transactions and reports that do not commit regularly are:

• Lock suspensions during the switch phase of the online REORG.This is because the REORG waits for read-only transactions/reports to commitin order to move them over to the reorganized data. During the wait (that canend up in a timeout), other transactions are queuing up behind the REORG,which results in a system performance degradation.DB2 V7 introduces significant enhancements in REORG processing (RETRY,RETRY_DELAY, DRAIN_WAIT, FASTSWITCH) which improve its concurrencywith other transactions.

• STOP DATABASE failures.These commands are sometimes used to quiesce access to a particular databaseor tablespace, for example, while re-assigning a tablespace to a different buffer pool.

• Timeouts and deadlocks.



March 2002 3–29

Deteriorating Dynamic Statements Cache hit ratioThis is because if the non-committing transaction/report accesses tables frommany different databases, the associated DBDs are taking up the EDM Poolspace that would otherwise be used for the skeletons of cached statements. Thiseffect can be eliminated if the cached statements are stored in the EDM Pooldata space (see the Dynamic Statement Caching section).

Regular commits (recommended frequency is approximately one per minute) needto be included in both the long-running read-only and update transactions andreports. If a particular cursor needs to be open for a long time, consider using theWITH HOLD option in order to preserve the cursor position across commits. Thiswill not release the claim on the tablespace referenced in the cursor, for example, onlineREORG on that particular tablespace still needs to wait in the SWITCH phase, butit will make all other objects available in that unit of recovery.

You cannot use DB2 means to identify long-running, non-committing read-only

reports. You need to monitor the running transactions on the application server site(for example, transaction SM66) and identify those that occupy a particular work processfor a long time. Such reports are most often found in user-written transactions andbatch reports. The best practice is to change these reports by inserting commits ifthe application logic allows it. For SAP written programs, open an SAP problemmessage, for user-written programs, talk to the application developers.

Various Considerations

Avoid lock contention caused by inappropriate access paths. See “Ensuring optimalaccess paths” and “Optimizing access to VBHDR, VBMOD, and VBDATA” forrecommendations on how to achieve the objective. Avoid application server buffering forthe tables with frequent updates. That not only adds to the cost of bufferresynchonizations, but can cause heavy lock contentions.

Call SAP transaction ST04 for monitoring locking events including snapshots ofcurrent locking conflicts across the system. se the SAP CCMS Monitor Set (transactionRZ20) or transaction ST04 to dentify timeouts and deadlocks. For more information, seeChapter “Monitoring and Performance”.


Other Considerations

3–30 March 2002

Other Considerations

Buffer Pool Tuning

Buffer pools are among the most important objects in DB2 performance monitoringand tuning. After the installation of a SAP system component, all of the tablespaces arebacked by some predefined buffer pools. The recommended initial buffer pool parametersettings are sufficient for the installation and functional verification of the product, butthey are not optimal in terms of performance.

This guide contains detailed steps which the customers should perform to tune DB2buffer pools for optimal performance. For more information, see “Buffer Pool Tuning”under “Database Tools” in the chapter “Monitoring and Performance”.

Dynamic Statement Caching

Caching of the dynamic SQL statements is the key ingredient of a well-performingSAP System component. The following parameters need to be set to optimize thisfeature’s performance:

• System parameter CACHEDYN=YES

• Sufficiently large EDM poolThere are two DB2 system parameters that control its size, EDMPOOL and EDMDSPAC.The former should be set to 60 MB, which should ensure good hit ratios for objectsother than cached statements. The latter is used for the cached statements only and werecommend setting it to 100 MB. You need to monitor the global cache hit ratio(reported in the Dynamic Statements Cache panel of the DB2 Subsystem Activitymonitor, transaction ST04). If it is consistently lower than 95 %, increase EDMDSPACin increments of 20 MB (do not oversize it because it results in overcommitting of thereal storage and increased system paging). If you start multiple ICLI server instances,make sure that all of them use the same user ID. Namely, the identical SQL statementthat is prepared by two different user IDs results in two cache entries instead of one.

• System parameter MAXKEEPD specifies how many prepared statements arekept across all of the threads. We recommend that you start with 10000.

• Make sure that the delivered packages and plans that are used by the SAP system arebound with KEEPDYNAMIC(YES).

��

��

� ��

��

��

�� !"�#��#$%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%��& General Overview......................................................................................................4–3 Installation of RFCOSCOL ........................................................................................4–3 Configuration of RFCOSCOL ....................................................................................4–4 Configuration of the RFC Connection........................................................................4–6 Specification of Configuration Parameters in Transaction DB2 ................................4–7 Additional Configuration Steps in an MCOD Environment ......................................4–10 Starting RFCOSCOL ...............................................................................................4–11 Stopping RFCOSCOL..............................................................................................4–12 Troubleshooting.......................................................................................................4–12

�� %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%�� DB2 Subsystem Activity...........................................................................................4–15 Lock Waits...............................................................................................................4–18 Global Times ...........................................................................................................4–18 Thread Activity .........................................................................................................4–19 Cached Statement Statistics ...................................................................................4–20 Installation Parameters............................................................................................4–22 Automatic Start of DB2 Traces................................................................................4–22 DB Alert Router........................................................................................................4–23

�� '��(� %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%��) Initiation of Failover to Other DB2 Subsystems.......................................................4–27 DB2 System Catalog ...............................................................................................4–27 z/OS System Log.....................................................................................................4–28 DB2 UDB for z/OS Commands ...............................................................................4–29 Buffer Pool Tuning...................................................................................................4–31 EXPLAIN..................................................................................................................4–39 DB System Check ...................................................................................................4–40 ICLI Diagnostics.......................................................................................................4–42

�' �(�� *��+��%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%��& Requirements ..........................................................................................................4–43 Tables and Indexes Monitor ....................................................................................4–44 Checking Consistency .............................................................................................4–47 Database Space Statistics.......................................................................................4–47 Detailed Information on Tablespaces ......................................................................4–47 Detailed Information on Indexes..............................................................................4–48 Detailed Information on Tables................................................................................4–49 Extent Monitor..........................................................................................................4–49 Volume Free Space.................................................................................................4–50 Troubleshooting.......................................................................................................4–51

�� %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%��,& CCMS Monitor Set for DB2 V6 ................................................................................4–53 CCMS Monitor Set for DB2 V7 ................................................................................4–58

��#��#$��-.#�%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%��/� Installing SAPOSCOL..............................................................................................4–64

��

�� !"�#��#$

��

Displaying Data ........................................................................................................4–65

��

�� !"�#��#$

� �� &

�� !"�#��#$

�� (�#0��0�

DB2 collects a broad range of performance indicators on a wide variety of aspects. Itmakes them available via its IFI (Instrumentation Facility Interface) interface. Theperformance data that is most relevant to SAP systems is provided by the SAP integratedDatabase Performance Monitor, which is transaction ST04. That monitor employs theRFCOSCOL to collect DB2 performance data via the IFI interface. With regard toperformance monitoring, RFCOSCOL serves three purposes. First, it provides currentsnapshot information of the overall system. Secondly, it allows you to submit DB2commands. Thirdly, it catches database alerts that are raised by DB2 and propagatesthem to the SAP system. To ensure functioning of these features it is important that thereis always an RFCOSCOL running. This especially enables proper performance monitoring.For details on DB2 trace classes and the IFI interface, see the IBM documentation �� .

To be able to work with database performance monitoring, you have to complete someconfiguration steps, which are described in more detail in the following sections:

• Specify the necessary parameters to run RFCOSCOL

• Create the appropriate RFC connection in SM59

• Specify the configuration parameters in DB2

��*�� (( ��!"�#��#$

You can install RFCOSCOL, the corresponding database request module, and the RFClibrary for z/OS using SAPinst. For more details about the installation, see the SAPinstallation documentation.

For the application server on z/OS, the RFCOSCOL is supplied as part of the kernel, and isstarted automatically when you start the SAP system.

If you have chosen not to install RFCOSCOL, the database request module, and the RFClibrary for z/OS in the recommended way using SAPinst, see SAP Note 426863.

It is recommended that you install RFCOSCOL in a separate directory. However, you cancopy the RFCOSCOL in the start directory of the SAPOSCOL and share one RFCOSCOLbetween SAPOSCOL and database performance monitoring.

1��

When you install RFCOSCOL, ensure that the appropriate permission bits are set:- EXECUTE permission for the RFCOSCOL for the user ID that starts it- READ permission for the database request module for the user ID that binds it.

��

�� !"�#��#$

��

�� !"�#��#$

Generally, there should be a dedicated RFCOSCOL for each DB2 subsystem andfor each SAP system. Such an architecture ensures that there are no dependencies andside-effects between different SAP systems. Also, it is simple to manage.

However, SAP systems can also share an RFCOSCOL. This option might be appealingwith MCOD landscapes. Moreover, if several DB2 subsystems reside on the same LPAR,they can be monitored by a common RFCOSCOL. Conversely, multiple rfcoscols can alsoserve a single SAP system. The advantage of such a topology is that multiple requestscan be processed in parallel.

To support SYSPLEX failover, you can specify an RFC destination to an RFCOSCOL foreach logical database connection as defined in the connection profile (see SAPinstallation guides). This enables the SAP application server to automatically use theRFCOSCOL that is in charge of the DB2 subsystem to which the application server iscurrently connected.

On start, the RFCOSCOL reads the saprfc.ini file which configures the RFCconnection in detail. The saprfc.ini should reside in the same directory as theRFCOSCOL. Either create a saprfc.ini or if already one exists, you can modify this one.The following parameters are important for use and should be configured:- DEST=<destination>- TYPE=R- PROGID=<program_ID>- GWHOST=<gateway_host>- GWSERV=<gateway_service>

The variables are described in the table below:

��

<destination> Name of your choice (case-sensitive)Recommended value: <SAPSID>

<program_ID> Name of your choice (case-sensitive)Recommended value: <dbhostname>.rfcoscol

<gateway_host> IP address or host on which the SAP gateway is running

<gateway_service> Service or port number of the SAP gateway

If you specify a service entry, verify that the corresponding entry is madein /etc/services.

1��

One saprfc.ini file can contain configurations for several RFC connections, whichmeans that it can be used as ini file by different RFCOSCOLs.The individual RFC connection specifications are separated by the DEST parameter.

��

�� !"�#��#$

� �� ,

To start RFCOSCOL properly, two environment variables must be set:

• STEPLIB

The STEPLIB environment variable must be set to the DB2 load library <sdsnload_library>.

• LIBPATH

RFCOSCOL uses the RFC library for z/OS. The LIBPATH environment variable mustbe extended to contain also the directory <rfcoscol_dir> in which the RFClibrary resides.

The following environment variables are recommended:

• RFCOSCOL _RETRY

If this variable is set, RFCOSCOL will retry to connect to the gateway if theconnection cannot be established.

• RFC_INI

Path to the saprfc.ini configuration file. Default is saprfc.ini in the localdirectory.

• RFC_TRACE_DIR

Path to directory to which RFCOSCOL writes trace files. Default is the local directory.

1��

The user ID to start the RFCOSCOL must have EXECUTION permission for the RFClibrary.

The variables are described in the following table:

��

<sdsnload_load> Name of DB2 load library

<rfcoscol_dir> Path of directory in which the RFCOSCOL resides. Forthe applicaton server on z/OS, this is/usr/sap/<SID>/SYS/exe/run

Both environment variables can be set either in a start script of the RFCOSCOL or in theuser environment. How to start RFCOSCOL with a start script is described in more detailin ’Starting RFCOSCOL’.

��

�� !"�#��#$

��/ � ��

�� !"��

In transaction SM59, the corresponding RFC connection is set up with the followingparameters:- RFC destination name The RFC destination name is a freely chosen name to identify this RFC connection- Connection type The connection type must be ’T’ which indicates a TCP/IP connection- Program ID The program ID specified in SM59 must match the parameter PROGID in the

saprfc.ini file- Activation type The activation type must be ’Registered Server Program’.

To test the recently created RFC connection in transaction SM59,you must start the RFCOSCOL, see ’Starting the RFCOSCOL’. As soon as the RFCOSCOLis started, the RFC connection should work properly.

When you want to use several application servers connected to one and the same DB2subsystem for monitoring and you want to use only one RFCOSCOL, you can direct yourRFC connection to the application server which has an RFC connection open to theRFCOSCOL.In this case you have to specify the gateway options (gateway host and gateway service)in SM59 for those Application Server which have no RFC connection to an RFCOSCOL. Itis not possible to connect directly to the RFCOSCOL that is already connected to adifferent application server, since a RFCOSCOL accepts only requests from oneapplication server.

1��

Be aware that in this case you are dependent on the running of the application serverwhich is used as a gateway. As soon as you stop either the gateway application serverot the corresponding RFCOSCOL, you will lose your connection and you are no longerable to monitor database performance.

��

�� !"�#��#$

� �� )

�� '� �� 2�

Call transaction DB2 and choose �� and go to SAP Collector Settings. Onthis panel you can specify configuration parameters and administer RFCOSCOL.

The required configuration parameters are as follows:

��

Destination for For each database name the RFC destination name asspecified in transaction SM59 for the RFC connectionof the RFCOSCOL

Plan name Name of the plan that RFCOSCOL will use, name of yourchoice

Collection ID Collection ID that the RFCOSCOL is going to use for thisSAP system; the default is the SCHEMA name, but youcan change it.

��

�� !"�#��#$

��3 � ��

Number of users Maximum number of concurrent usersRecommended value: 5

HFS path ofRFCOSCOL

Directory in which the RFCOSCOL and thecorresponding database request module(DBRM.db2cldb) resides.

SAP Collector userID

User ID of the user that starts RFCOSCOL

When the parameters have been specified and saved, you must bind the database requestmodule against the DB2 subsystem by making use of the appropriate button. This bind isnecessary, since for DB performance monitoring the RFCOSCOL issues SQL statementsagainst the connected DB2 subsystem. The database request module, which is releasedtogether with the RFCOSCOL, must have been put in the same directory as the RFCOSCOL,otherwise the execution of the generated BIND job will fail. As soon as you change thedirectory in which the RFCOSCOL and the corresponding database request module islocated, or as soon as you want to use a different level of the RFCOSCOL residing in adifferent directory, you have to change the name of the directory accordingly. As for thebind, the information about RFCOSCOL and the corresponding database request moduleare taken from the specified directory.

Prerequisites for the submission of jobs are that the z/OS password of the SAP user andthe general profile parameters are maintained in the JES Interface (transaction DB2J).This applies both to the user ID submitting the GRANT job and to the user ID bindingthe database request module.

In addition the user ID submitting the BIND job for the first time must have DB2SYSADM authority. For rebinds with the same job, you can use the user ID that startsthe RFCOSCOL, since all necessary DB2 authorization rights are already granted to thisuser, if you have once submit the GRANT job. If you choose to use a different user ID tosubmit the BIND job, neither a user ID having the DB2 SYSADM authority nor the userID starting the RFCOSCOL, make sure that this user has the appropriate DB2 authorizationrights to bind a plan and a package.

You have to resubmit the BIND job, when the database request module is changed. Thisis always the case when a new RFCOSCOL level is installed.

1��

As soon as you change the plan name, or the collection ID, or the user ID that startsthe RFCOSCOL, you have to resubmit the BIND job using the new settings.

When the plan is bound, you must grant the appropriate DB2 authorization rights, forexample, for a specified plan and collection ID to the user ID that starts the RFCOSCOL

��

�� !"�#��#$

� �� 4

by making use of the appropriate button. Also the user ID which starts the RFCOSCOLrequires the MONITOR1 and MONITOR2 privilege to collect trace data. The TRACEprivilege to start the monitor trace needs to be granted to the user ID as well.

In addition the user ID submitting the GRANT job must habe DB2 SYSADM authority.You do not need to resubmit the GRANT job if only the RFCOSCOL is replaced.

1��

But as soon as you change the plan name, or the collection ID, or theuser ID that starts the RFCOSCOL, you have to resubmit the GRANT job usingthe new settings. When you do not resubmit the GRANT job, RFCOSCOL will failwith DB2 authority problems.

When you run the GRANT job and permission problems were detected with the user IDsubmitting the grants, ensure that the READ permission is set for the database requestmodule.

If the automatically created jobs do not exactly match your requirements, you maychange the job skeletons in the JES interface. The names of these jobs areSAPCLGRANT and SAPCLBIND.If you want to execute these jobs directly on z/OS, you can download themby choosing �� → �� as a local file from the menu.

The configuration parameters plan name and collection ID are not only usedfor bind or grant purposes, but also used during the collection of performance data.They are passed to the RFCOSCOL which uses them for the DB2 connection. Thereforethey must be changed accordingly, if the user wants to switch between differentRFCOSCOL setups.

Since some requests to collect performance data are very resource intensive, theserequests can be limited. The maximum number of concurrent users can be specified andadjusted to your needs.

([DPSOH

SAP system SP1 with mysrv1 application server and system number 01. Therelevant DB2 subsystem MDB2 is running on the OS/390 host, ms3901.

RFCOSCOL is started with the IFISP1 destination. The relevant entry in thesaprfc.ini file is:DEST= B4MTYPE= RPROGID= mydbhost.rfcoscolGWHOST= mysrv1GWSERV= sapgw01

In the /etc/services file the corresponding entry for ’sapgw01’ must bemade.

��

�� !"�#��#$

��

In transaction SM59 the RFC connection ’IFICOL_MS3901’ is created as TCP/IPconnection with the program ID ’ificol’.

In transaction DB2 Checks/Settings the destination ’IFICOL_MS3901’ isspecified for the subsystem MDB2.

The database request module (DBRM.db2cldb) must be correspondingly bound tothe subsystem MDB2 with the plan name SAPCLP and the collection CLIDP.

�� (�� #��5�0��

If you run multiple SAP systems in one database (MCOD) and want to monitorthem with a single RFCOSCOL, a package needs to be bound per SAP system and allthe collections (= package lists) need to share a common plan. Note that this requireschanges to the predefined BIND and GRANT jobs. Assume that in an MCOD landscapewith two SAP systems, you have SAP system 1 and SAP system 2. The SAP system 2 isused as gateway to the RFCOSCOL. The BIND statement of the plan would be as follows:

BIND PLAN (<ifi_plan>) OWNER (<sapsidadm_system>) -PKLIST (<sap_system1>.*, <sap_system2>.*) -ACTION(REPLACE) RETAIN ISOLATION(UR) DYNAMICRULES(RUN) -ACQUIRE(USE) RELEASE(COMMIT) -CURRENTDATA(NO) KEEPDYNAMIC(YES) -SQLERROR(CONTINUE)

The variables are described in the following table:

��

<ifi_plan> Name of plan used by RFCOSCOL

<sap_system1> Name of collection of SAP system 1Recommended value: C<SAPSID><REL>, for example,CB4M620.

<sap_system2> Name of collection of SAP system 2

<sapsidadm_system> User ID of the sapsidadm user of SAP system

Also, additional privileges are necessary. They can be granted by issuingthe following commands:

GRANT EXECUTE ON PACKAGE <sap_system1>.* TO<sapsidadm_system>;GRANT PACKADM ON COLLECTION <sap_system1> TO<sapsidadm_system>;

As a last step, the RACF definitions need to be enhanced. The ID of theuser who started the RFCOSCOL (here: <sapsidadm_system 2>) has to beauthorized for all RACF secondary groups of an MCOD landscape (see the IBMdocumentation� !��"�� #�$��%%!��).

��

�� !"�#��#$

� ��

The RFC connection in SM59 for SAP system 1 must be configured in the way that theSAP system 2 is used as gateway. Hence when you create the RFC connection, specify inaddition to the parameters described in ’Configuration of the RFC connection’ thegateway host and the gateway service. As soon as the RFCOSCOL for SAP system 2 is upand the application server is running, you can test the RFC connection.

1��

Be aware that in this case you are dependent on the running of the application serverwhich is used as gateway. As soon as you stop either the gateway application serverto the corresponding RFCOSCOL, you will lose your connection and you are no longerable to monitor database performance.

�� !"�#��#$

The RFCOSCOL itself is started with the following command:

nohup rfcoscol -D<destination> &

The -D option refers to the DEST parameter of the saprfc.ini file. When theRFCOSCOL is invoked, it searches the saprfc.ini file for a matching DEST parameter.If the parameter is found, it reads all subsequent parameters up to the next DESTparameter, if another one is specified.

1��

For more details about the RFCOSCOL parameters, the description ofthe variables, and the environment variables, see ’Configuration of RFCOSCOL’.

Both the necessary environment variables and the RFCOSCOL start command canbe put in a script file, which is used for start up.

Create the file containing the following commands:#!/bin/shexport STEPLIB=<sdsnload_library>export LIBPATH=$LIBPATH:/<rfcoscol_dir>export RFCOSCOL_RETRY=1cd <rfcoscol_dir>nohup ./rfcosocl -D<destination> &

Before you execute the start script:- Change the start script to an executable by using the command chmod- Ensure that the user ID used to invoke the start script has the EXECUTE permission

If you do not want to use a start script file or the saprfc.ini file, the RFCOSCOL can beinvoked directly by specifying the following command line parameters:

��

�� !"�#��#$

��

nohup rfcoscol -a<program_ID> -g<gateway_host> -x<gateway_service> &

The command line option -a corresponds to the PROGID parameter of thesaprfc.ini file, the option -g to the GWHOST parameter, and the -x option to theGWSERV parameter.

1��

When you start RFCOSCOL directly, do not forget to set the two environmentvariables.

��!"�#��#$

To stop the RFCOSCOL, issue the kill command:kill <pid>

When you issue the kill command, not only RFCOSCOL is closed down, but theassociated statistic trace is also stopped. A kill -9 is not recommended since it forcestermination of the process and does not allow any cleanup work,for example, stoppingthe associated statistic trace) to be done by the RFCOSCOL before terminating. Only if thenormal kill does not work you should use kill -9 to stop the RFCOSCOL.

��'��(��

Analyze the error message in the SYSLOG (SM21) and in the db2cl.<pid>.trc tracefile. The trace file is stored in the start directory of RFCOSCOL. If the dB connect wassuccessful, you can also display the trace file from transaction DB2. Choose Traces/LogsIFI Data Collector Show Trace. At this point, the trace level can also be dynamically setfor the IFI Data Collector of RFCOSCOL. If you call RFCOSCOL using ST04, RFCOSCOLdisplays its own version number in the db2cl.<pid>.trc trace file. Check your pathfor RFCOSCOL and if an explicit path cannot be used, check whether the execution bitsare set.

Check that the environment variable LIBPATH contains the path to the DLL librfccm.

��

�� !"�#��#$

� �� &

��

DSNTIAR could notbe loaded

STEPLIB not set Check STEPLIB

SQLCODE -923 notfound

Plan name Check plan name in DB2J

��

��

CL_ASYN_NO 0(Def),1 Alert not started if value set to 1

CL_TRACE 0(Def) to 5 Trace level. Setting a trace canimpair the performance of the datacollector

��

� � ��

��

�� The DB2 performance indicators are made available at different levels of reporting byRFCOSCOL:- Subsystem-wide scope: This includes performance data for the DB2 resources that are shared by all of DB2 users, for example, buffer pools and logging.- Thread-wide scope: The thread-wide monitoring is very useful if you are looking at a specific SAP work process, for example, a long-running batch job, and its consumption of DB2 resources. This is due to the static relation between an SAP

work process and its associated DB2 thread.- Statement-wide scope: For each SQL statement cached, DB2 maintains a number of

performance indicators. This data presents a prime source of performance monitoring and tuning indicators.

Moreover, the DB Performance Monitor includes a set of panels that display the currentDB2 system parameters. The correct system parameters are crucial for the efficientoperation and performance of SAP Systems.

While the integrated DB2 monitor is a very good vehicle for monitoring DB2in SAP system environments, it lacks some of the features available in stand-alone DB2monitors. For example, reporting the subsystem-wide statistics data for any given period(DB2 PM Statistics report set) or post-processing of various DB2 performance traces(DB2 PM Record Trace report set) should be obtained by other means.

1��

In the DB performance monitor area, both the ICLI Performance Services and theICLI Alert Router are no longer available.

The RFCOSCOL connects to the DB2 subsystem for which the performance datashould be gathered. Most of the collected data is only available if DB2 monitor traceclass 1 is active. For that reason, RFCOSCOL starts that trace class, if not already active.Moreover, the SAP system aims to ensure that the DB2 Accounting classes 2 and 3 andthe performance trace IFCID 318 are always on. For more information, see the section“Automatic Start of DB2 Traces” in this chapter. As soon as a request for performancedata comes in, the RFCOSCOL calls DB2 via the IFI interface. The collected data isexamined and written into regular tables which are owned by the SAP system. Then thecalling transaction reads this data from the corresponding tables.

To avoid heavily increasing tables, the content of the tables are automatically deleted.

For details on DB2 trace classes and the IFI interface, see the IBM documentation ��.

To access the DB performance monitor, choose:

&��!��→��→�'��→� ��→��$��→��(

or call transaction ST04.

��

� � ��

� �� ,

The ��$�� !(��"��)�� screen appears.

All ST04 functions can also be accessed by calling transaction DB2. For moreinformation, see Chapter “Basics”.

��2��6��06

For information about the overall DB2 database performance, choose ��$�(��( on the initial screen of the performance monitor. The ��$�(��("��*�+��)��, screen (shown on the next page) displaysimportant DB2 statistics, counters, percentages and ratios.

��

� � ��

��/ � ��

��

� � ��

� �� )

Most of the DB2 statistics field values increase while the DB2 subsystem is running. Assoon as DB2 is started, the accumulation process begins and it continues until the DB2subsystem is stopped.

The data is displayed in one of three forms:

• Accumulated valuesValues summed up over the measurement period.

• Current valuesValues at the current time.

• High water mark valuesMaximum value the counter has reached since the time the DB2 subsystem wasstarted the last time.

Values can be displayed for two measurement periods:

• Since DB2 start

• Since reset

When you choose ��$�(��( in the ��$�� !(��"��)��screen, the system displays the data since the DB2 subsystem start bydefault.

1��

The type of period measured you select remains the same for all subscreens of the��$�(��( screen.

The following standard functions are available:

��

��

-�� Sets the reset time to the current time. All accumulated values areset to zero.

�� The period measured is the duration between the previouslydetermined reset time and the current time.

�� The period measured is the duration between the time thesubsystem was started and the current time.

.�� Generates a list with important data for the DB2 subsystem. Thislist can be downloaded to your PC or printed.

��

� � ��

��3 � ��

�� (��2��6��06

For information on specific areas you can choose, for example, ��%��!��( or/.��(. The detail screens have the same functions (-��, ��, and so on)as the screen ��$�(��("��*.

From the ��$�(��(�"�� !�.�� screen, you can access detailedinformation on a specific buffer pool by selecting the buffer pool and choosing ��!�.

��$��7�8 �

To see all the lock waits within your DB2 subsystem, choose .��*��in the��$�(��("��* screen.

The .��#�� screen displays a list of all wait situations (that is, a thread waits for aresource locked by another thread). This list shows the locked resource, the holder of thisresource and the waiter for all wait situations.

��(�� (�'��

This function displays the times as the average for all threads as a percentage for theactivity time and the time spent in DB2. Additionally, you get the average times of thedifferent kinds of suspension in milliseconds.

To be able to display global times, the accounting trace classes 1, 2, and 3 must be active.They are automatically started during SAP System startup. They can also be startedmanually by issuing the following command:

START TRACE (ACCTG) CLASS(1,2,3)This command is among the pre-defined commands of the ‘DB2 commands’ section oftransaction ST04.

1��

All the values are global times that have been calculated as the averages of allthreads. Extreme values of a single thread may influence the averages displayed forall threads considerably if there is a low number of threads.

The times displayed can help guide your investigation into application performance andtuning.

��

� � ��

� �� 4

��'�� 06

To display the list of active threads connected to the DB2 subsystem you are monitoring,choose &��( in the ��$�� !(��"��)��. Thelist of active threads is refreshed when you call this screen.

The measurement period is between the DB2 subsystem start and the last time the threadlist has been refreshed.

As with the global times the thread-level time information also relies on the accountingtraces 1,2 and 3 being on.

��2��'�� 8��7��

An SAP work process exists for each DB2 thread. The correlation between an SAP workprocess and its corresponding DB2 thread is established by the host name of theapplication server and the work process number. If there is no uniqueness, you can usethe IP address to identify the application server. Note that this information is alsoavailable via the DISPLAY TRACE command.

1��

To obtain a relation between the SAP work process and the SAP system user orprogram that is correlated to the DB2 thread, call transaction SM50 (processoverview).

You can select any thread listed and use one of the following functions:

��

��

��%��!��0 Displays all buffer pools used by the selected thread in themeasurement period.For information on read and write activity both to and from aspecific buffer pool, select this buffer pool and choose ��!�.

.��( Displays locking information on the selected thread.Locking problems can be further investigated by choosing .�� or !��*��, to examine resources locked by or waitedfor by the thread monitored.

.��*�� Displays a list of resources that the selected thread is waiting for.

.��

Displays a list of the resources locked by the selected thread.

��.�� : The system displays data sharing lockingcounters.

/.��( Displays number of times SQL statements are executed whenprocessing a DB2 application.

��

� � ��

��

The sections�&��!��'. (Data Manipulation Language) and &��!��. (Data Control Language) display information for each thread.&��!��. (Data Definition Language) shows a table containing thenumber of executions performed by various DDL SQL statementsfor each of the applicable object types.

/.�� Displays information about the current SQL statement beingexecuted by the monitored thread. If you need to see all the details ofthe access path for that statement, choose 12%!��.

��%�� . The system displays all active group bufferpools and related counters.

&�� Displays various times for processing in DB2 and out of DB2 andsuspension times.

Displays the response times of various actions performed by theselected thread. The times displayed can help guide yourinvestigation into application performance and tuning. Theircollection depends on accounting trace classes 2 and 3.

Most of the thread field values are accumulated. As soon as the thread is started, theaccumulation process begins and it continues until the thread terminates.

To display current thread-specific data in all screens, choose -��.

At any time, data from the same point in time is shown on all thread detail screens. Thismeans you can examine a specific thread in detail with data referring to the same point intime.

To display important information for a specific thread, select the thread in the thread listand choose .��. You can download or print the information displayed.

��

This function provides monitoring capability for the prepared SQL statements that residein the dynamic statement cache. The information about the cached statements will begathered during their preparation and execution.

��'� ��*"�*��&�3

Statistics information for cached statements is invaluable for performance tuning on thelevel of individual SQL statements. This information is only collected if the DB2performance trace IFCID 318 is turned on.Therefore,at SAP system startup this trace is automatically turned on. By subsequentlystopping and restarting IFCID 318, any statistics that were previously collected forexisting statements in the cached will be cleared. If a DB2 system executes dynamic SQLstatements from the dynamic SQL statement cache while the IFCID 318 is off, DB2 willreturn a record for any qualifying statements in the cache, but most of the statistics fieldsfor those records will show all zeros.

��

� � ��

� ��

��"(��

You can select any of the following statistics fields for filtering. DB2 will then returninformation about the statements that have the highest values in the selected field.

�� !��

��

Number of executions

Number of buffer reads

Number of getpages

Number of rows examined

Number of rows processed

Number of sorts

Number of index scans

Number of tablespace scans

Number of parallel groups

Number of buffer writes

You can additionally provide a threshold value for the statistics fields. DB2 will thenreturn information about all statements that exceed the given value for the selectedstatistics field.

��9$�� '�+� ��5+�( ��"��

The records displayed provide identifying information, statistics, and part of the SQLstatement text. Due to the potential size of the SQL statement text, only the first 60 bytesare shown. If you want to see the entire statement text for a particular statement, clickthis statement text. If you need to see all the details of the access path for the statement,choose 12%!��.

For more information, see the EXPLAIN section under &��!� in this chapter.

��( ��9$�� 2��

With DB2 V7 a correlation of SQL statements and ABAP source code is beingestablished for those statements, which are embedded in ABAP programs. It is possibleto navigate directly from an SQL statement to the ABAP source code that has initiatedthe dynamic preparation of the statement. For MCOD landscapes it is recommended toexploit the navigation feature only for the ‘own’ statements of an SAP System.

��

� � ��

��

��*�� (( ��

To display the installation parameters of the DB2 subsystem, choose one of thefollowing:

• Choose�3��!!��%�� on the ��$�� !(��"��)�� screen.

• Call transaction ST04 or DB2 and choose 3��!!��%��0

The first tab provides an overview of the most relevant parameters. All the SAP specificparameters, which are described in the SAP WAS 6.20 Installation Guide, are presentedon that screen.You can display more detailed information on the following subset of parameters:

• Buffer pools

• Data sharing

• Storage

• Tracing

• Locking

• Protection and data definition

• Logging

• Application programming defaults

• DDF

• Miscellaneous

To generate a list of the installation parameters, choose�.��0 Their values can bedownloaded or printed.Since the PTF status of a DB2 subsystem is not obvious, and to help you tokeep your system at the latest maintenance level, the database monitor provides adiagnostic function.A menu item ’DISPLAY MEPL’ is provided. When you activate this button, theDB2 utility DIAGNOSIS is called via the Stored Procedure DSNUTILS with the option’DISPLAY MEPL’. The result, the module entry point list (MEPL), is then displayed inraw format.

�� 2��'� ��

The SAP System tries to ensure that the relevant DB2 traces (besides monitor trace class1) are always on. These traces are an invaluable source of performance indicators, whichallow to tune the DB2 subsystem upfront and to get appropriate diagnostics informationin case of performance problems. Thus, there is a periodic job(RSDB2_COLLECT_HOURLY) that accomplishes this task. It runs at the startup of theSAP System and once every hour. Its goal is to start both accounting trace classes 1,2 and3 and IFCID 0318 of performance trace class 30. If the job determines that accountingtrace class 2 has been stopped, it does not restart that trace though.For exceptional circumstances it may be advisable to turn off these traces and to makesure that they are not restarted by the SAP System. You can accomplish this on panel

��

� � ��

� �� &

‘SAP Collector Settings’ in transaction DB2. Entering �"�� in the command field ofthat screen disables the automatic start of the traces. By entering �"� it is enabledagain.

��2��(��!��

RFCOSCOL also serves as database alert router that catches DB2 alerts via the IFIinterface of DB2. Since catching exception events is a waiting task, the RFCOSCOL startsa separate alert router thread for each DB2 subsystem and for each schema. This threadexclusively listens to DB2 alerts.

Each alert router thread connects to the DB2 subsystem for which the exception eventsshould be collected and starts an appropriate statistics trace. The statistic trace isassigned to an OP buffer, into which DB2 writes the exception events. When an eventoccurs, DB2 informs the alert router thread that read the OP buffer. After this call, theOP buffer is emptied by DB2.

1��

Be aware that there are only eight DB2 OP buffers per DB2 subsystem. Monitorprograms- such as the RFCOSCOL- allocate OP buffers exclusively. To be able to runthe database alert router, you must ensure that at least one OP buffer is unassigned.

1��

If you run multiple SAP systems (MCOD) in a DB2 subsystem, you must ensure thatfor each SAP system you want to catch exception events an OP buffer is unassigned.

1��

Automatic start of an alert router thread can be prohibited by using the correspondingenvironment variable.

The alert router thread reformats the exceptions events data and saves the data in specificDB2 tables for later display.

Immediately, the database alerts become visible in transactions ST04 and DB2. Theremay be short delay until the alerts are integrated into the CCMS Monitor Set (transactionRZ20) though. That is due to the fact that new alerts are fed into the CCMS Monitor Setby a periodic job. This job is normally executed every five minutes. Thus, the maximumdelay is five minutes. The database alerts are kept for 30 days and then deleted.

��

� � ��

��

The alert router thread catches all exceptions events of the DB2 subsystemand exception events belonging to non-SAP data that may coexist in the samesubsystem. Also in a data sharing environment the alert router threadcatches exceptions of all members in the same data sharing group. In addition in anMCOD environment you get the exception events of all SAP systems.

1��

Be aware, since the exception event transactions do not filter, the scope of theexception events is larger than the SAP system you are running on. The advantage ofsuch a behaviour is that you have a single resource for monitoring.

��5+��50��

There are different types of event:

• Deadlocks

• Timeouts

• Active log shortages

• Long-running units of recovery (LRUR)

• Data set extents

For the long-running units of recovery (LRUR), the amount of time, which is required toroll back DB2 units of work, depends on the number of DB2 logs written. That impliesthat long-running units of work that accomplish a lot of UPDATE, INSERT or DELETEactivity are rolled back slowly. Those entities are called long-running units of recovery(UR). Transactions are rolled back for example if the application explicitly issues theSQL ROLLBACK statement or at restart of DB2 when DB2 previously abended. Thenegative effects of long-running URs particularly are that they restrict access to theaffected resources during rollback and that they prolong DB2 restart times. This kind ofalert is raised when DB2 detects long-running URs depending on the ZPARMsURCHKTH and URLGWTH (DB2 V7 only). For details on these ZPARMs, see the SAPinstallation documentation.

�� 2��(��!��

When invoked by the SAP system, RFCOSCOL starts an alert router thread. If RFCOSCOLworks for multiple SAP systems, it starts a thread for each DB2 subsystem and for eachschema. If a corresponding thread has already been started, no new attempts to start it areaccomplished. The SAP System (or more particular the reportRSDB2_COLLECT_HOURLY) initiates the start of the alert router thread at startup ofthe SAP System and periodically every hour. Also, the alert router thread can be startedmanually. To accomplish this, go to the section DB Alert Router in transactions ST04 orDB2 and choose '��!!(��!��-��.

��

� � ��

� �� ,

To check if the DB alert router is running:

1. Call transaction ST04 or DB2.

2. Choose Thread Activity

3. Sort the column plan name.If the alert router is running, a corresponding DB2 thread with a plan name specifiedfor RFCOSCOL is displayed.

�� (6��

From the CCMS monitor set, you can access the following analysis monitors:

��

Deadlocks DB2D −

Timeouts DB2T −

Active log shortages − RSDB2LOGSHORT

LRURs DB2U −

Extents DB02 −

1��

All monitors listed above are also accessed by calling transaction ST04 or DB2.

In the monitors, you can analyze the details of an event. You can select a timeperiod and display events that occurred during that time. To display a hierarchicallist of the events, choose ��%!�(. For detailed information on an event, double-click an entry.

��2��(��

The alert router has the following standard settings for extent alert threshold values:

• Low threshold = 25

• High threshold = 80

If the low threshold is exceeded, a yellow alert for each new extent of the data sets above25 will be shown in the CCMS Monitor Set (transaction RZ20). If the high threshold isexceeded, a red alert will be shown in the CCMS Monitor Set.

To react to this alert, you can choose the analysis tool in the CCMS Monitor Set, forexample, by double-clicking on the node. This leads you to the extent monitor(transaction DB02). It is possible to change the secondary quantity and to alter it fromthe extent monitor.

��

� � ��

��/ � ��

Under normal circumstances, these settings should be sufficient. If you want to changethe low and high threshold values of the extent alerts:


2. Choose DB Alert Settings.

3. Choose Change. This enables you to change the low and high threshold values.

��(��' �(��5��(��*��

SAP provides a program that automatically deletes table entries of database alerts that areolder than 30 days. The program is set to run once every day. You can also delete thealerts in the alert monitor. This does not, however, delete the table entries in the historytable and this means you can display events for up to 30 days even after the alert hasbeen deleted.

��

� � ��'��(�

� �� )

�� '��(�

��*� ��" (�0��#��2��6��

In DB2 data sharing topologies there may arise the need to redirect the work processes ofan SAP application server to a different DB2 member of the data sharing group. Onescenario is that a specif member is supposed to undergo maintenance and thus has to bestopped. Optimally, this operation should not be noticeable to end users. Therefore, theSAP application server offers the capability to dynamically reconnect its work processesto a different DB2 member. The configuration options are described in the SAPinstallation guides.

To actually initiate the reconnection to a different DB2 subsystem, go to transaction DB2or ST04. There you can both inspect for each work process the currently connecteddatabase host and redirect the work processes. By invoking “Active DB Connections” thestatus quo of work process to database host mapping is displayed. Note that the databasenames, which are specified for the work processes, are neither DB2 subsystem nor DB2member names. Instead they are the “logical” names of the database connection as theyhave been specified in the connection profile.

The ��.�� shows all possible logical connections for the application server.Among others, it gives the DB2 SSID of the logical connection and the z/OS system onwhich the DB2 subsystem is running. By double-clicking a connection the workprocesses of the application server are reconnected to the subsystem, which is specifiedby the connection. To use this feature sensibly, make sure that the rdisp/noptimeprofile parameter is between 120,for example, two minutes and 600, for example tenminutes. This guarantee that all work processes are moved within this time. Otherwise,rarely used work processes may not be activated and, consequently, not moved either.

The parameter rdisp/noptime only causes all the work processes to be activated in theinterval given. If there is no work to be performed, they are immediately deactivated.This should hence not be a problem during normal operation.

��2��6�� (��

To access the DB2 catalog browser, call one of the following transactions:

• Transaction DB2C.

• Transaction DB2 or ST04 and choose ��!��$��*��.

You use SQL statements to access parts of the catalog:

1. Enter your statement.

2. Choose 12��0

3. The result is displayed as a list.

��

� � ��'��(�

��3 � ��

1��

Only SELECT statements on tables created by SYSIBM are allowed. This ensuresthat user access to tables is restricted to read-only mode and access is limited to theDB2 catalog.

A maximum of 36 statements can be executed with this transaction.

You can only enter statements one at a time. Statements must not end with a semi-colon.

The SQL statement is sent directly to the DBMS and does not undergo any furtherchecks. Any errors in the SQL statement will lead to a database error, which results in ashort dump. The dump is the normal response to any errors in the statement.

The query result is displayed as a list. Depending on the query, this table can becomevery wide and may exceed the maximum table width. If this happens, you will beprompted to modify the output. You can restrict the maximum length of character fields.You can also use 4��!��!�� to deactivate the columns you do not need to display.You can also select how many rows you want to display in the list. Choose '�2��*��!��and specify the number of rows. To clear statements from the screen,choose �!��.

��-.#��6��$��

To display z/OS system logs, choose one of the following:

• Choose ��(��.�� on the ��$�� !(��"��)��screen.

• Call transaction DB2 and choose ��(��.��.

1��

This function is not available under JES3, since the program to get the system log(SDSF) does not exist. However, if you have a third-party-product working similar toSDSF, that is, a program that writes the console output into a partitioned data set, youcan adjust the JCL job template. To do this, use the JES Interface and edit the jobGET_CONSOLE created by SAPR3.

You need TSO access to display z/OS system logs. Both TSO and SAP system usernames must be identical.

A sequential data set for the upload of z/OS jobs must exist with the followingcharacteristics:

��" -��" 5�-��!��" 6��!��" �7��

��

� � ��'��(�

� �� 4

Enter the name of this data set and the name of the SDSF HASPINDX using transactionDB2J.

��2��:�2��-.#��

��- ��(��2��:�2��-.#��

SAP provides some DB2 UDB for z/OS commands.

These commands can only be changed with the authorization profiles S_DB2_COMM orS_DB2_DBADM.

You can, however, create, change, and delete your own DB2 UDB for z/OS commandswith the authorization profiles S_DB2_EXPC or S_DB2_DBADM. In addition, you candecide when creating a command whether S_DB2_ALLU or S_DB2_EXPC is necessary forits execution with these authorization profiles.

With the authorization profile S_DB2_ALLU you can only execute DB2 UDB for z/OScommands that have the “command user” ALLUSER.

For more information about the default authorization profiles, see the section on“Authorization Profiles” in chapter “Basics”.

��*� (��

To display the initial �� "��!�� screen8 choose one of thefollowing:

• Choose ��→��(��→��'��→� ��→��$��→��(�→��

• Call transaction ST04 or DB2 and choose ��0

1��

Executing a DB2 UDB for z/OS command from the SAP System produces the sameresult as executed from the z/OS system log.

��

� � ��'��(�

��&� � ��

�� 2��:�2��-.#��

The following functions are available:

��

12�� Select a command and choose 12��. The next screen displays theresult of the command.

��%!�( Select a command and choose ��%!�(.

�� Select a command and choose ��. Make your changes and choose��. You may also delete a command here.

Note that you can execute the changed command in the �� "��screen #�� saving it.

�� Choose ��. Make the necessary entries and choose ��.

Note that you can execute the new command in the �� "��screen�#�� saving it.

To return to the initial screen from the subsequent �� "��%!�(��9�*�� screens, choose ��!��.

��

� � ��'��(�

� �� &�

��2��(�'��

One of the most important objects in DB2 performance monitoring and tuning are bufferpools. After SAP system installation, all the tablespaces and all the indexes are backedby some predefined buffer pools as described in the � �3��!!��. Thedelivery of a pretuned setup is impossible because customer environments are so specialthat a general solution cannot be applied. The recommended initial buffer pool attributesare sufficient for the functional verification of the product, but they are not optimal interms of performance.

The following describes what you should do to tune DB2 buffer pools for optimalperformance.

To tune the buffer pools in the SAP system environment, the administrator has to:

• Establish a base for performance evaluation

• Create a &�%�&�$!��.��

• Isolate the tables in their own tablespaces

• Determine tables-to-buffer pools mapping

• Determine buffer pools attributes

Each of these steps is described in more detail below.Be aware that this procedure works on the tables of one SAP System only. With MCOD,the procedure needs to be accomplished for each system. If the topology is such that eachSAP System is equipped with a dedicated set of bufferpools, it is required to reflect thisin table DB2BPTUNE. The table contents of this table can be altered by means of theData Browser (transaction SE16).

1��

Buffer pool tuning is an iterative process. Therefore, regularly perform the describedprocedure to:

• Base your tables-to-buffer pools assignments on a sample typical for yourinstallation

• Detect changes in the workload

• Adjust the buffer pool attributes (sizes, thresholds).

��5� �(�� 2 �� 50 (� ��

To evaluate the effects of tuning and detect development of new bottlenecks andperformance deficiencies, you need to establish a base for performance evaluation. Thiscan be done by collecting and storing the performance data over a longer period of time,but most importantly before and after any tuning activities.

��

� � ��'��(�

��&� � ��

The following data can be used to identify changes in the workload and throughput:

• Number of getpages per reporting interval

• Number of buffer updates per reporting interval

• CPU utilization

The following data can be used to detect reaching critical thresholds:

• Prefetch disabled due to no storage or no engines

• Asynchronous write disabled due to no engines

• Data Manager critical threshold

• Sort merge passes degraded

• Work file prefetch disabled

The most common reasons for reaching the thresholds are:

• Reducing VPSIZE too much

• Setting VPSEQT too low

• Setting deferred write thresholds too high

In such cases, reverse the negative effect by appropriate adjustments.

The following data can be used to check if storage is overcommitted:

• Hiperpool read/write failures

• Page-ins for read and write

• z/OS paging activity

The following data can be used to measure effectiveness of the tuning:

• Overall hit ratio, which is derived as:

(total getpages - total pages read)/total getpages

where total pages read = total synchronous reads + pages read by sequential prefetch + pages read by dynamic prefetch + pages read by list prefetch

• Random hit ratio, which is derived as:(random getpages - random synchronous reads)/random getpages

• Read rate, which is derived as:(total synchronous reads + all type prefetch reads) per interval

• Hiperpool pages read vs hiperpool pages written, where all types of reads and writesneed to be taken into account

• Hiperpools read ratio, which is a number between the two expressions:- (synchronous reads + pages read with ADMF + pages read without

ADMF)/interval- (synchronous reads + pages read with ADMF/32 + pages read without

ADMF/32)/interval

• Buffer updates per pages written

• Pages written per write I/O, which is derived as:pages written/(synchronous writes + asynchronous writes)

��

� � ��'��(�

� �� &&

• Write rate, which is derived as:(synchronous writes + asynchronous writes)/interval

• z/OS DASD and Cache activity ratios

�� '��' �(�� - ��$�

The buffer pool tuning tool DB2B helps you to create the top tables categorization list.This includes determining which tables are referenced most often, what is the accesspattern, and what is the current table size.

1. Call one of the following transactions:Transaction DB2BTransaction ST04 or DB2 and choose ��%��!��.

2. Table categorization is based on the data from transaction ST10. Statistics areavailable for various time intervals such as ��%, %��(, and %��*��.Choose the interval that most closely represents your typical workload. Exclude timeperiods in which activities are done that are not performed as a daily routine, such asclient copy or a large transport.

3. To display the top tables categorization list, choose &�$!��.

Sort the list with the ��4��:��( column to identify the top 20 to 30 entries.

The columns are named as follows:

− 12��Executes = Fetch + Update + Insert + Delete

− ��Changes = 100*(Update + Insert + Delete)/Executes

− ��&(%�If RowsAffected/Executes > 5Then AccessType = sequentialElse AccessType = random

− ��4��:AccessFrequency = max(Executes,RowsAffected)

− &�$��If (NPAGES > 250 AND RECLENGTH < 4056) OR (NPAGES > 30 AND RECLENGTH > 4056)Then Size = largeElse Size = small

��

� � ��'��(�

��&� � ��

− ��(The ��( is a table attribute that describes what kind of access istypically done for the table. It also takes into account the table size.

�� $��

$��

C1 AccessType=Sequential, Changes<10%

C2 AccessType=Sequential, Changes>10%

C3 AccessType=Random, Changes<10%, TabSize=small

C4 AccessType=Random, Changes<10%, TabSize=large

C5 AccessType=Random, Changes>10%, TabSize=small

C6 AccessType=Random, Changes>10%, TabSize=large

C7 Insert and/or Delete only

C8 This is a category reserved for VBLOG, VBDATA, VBHDR, andVBMOD because of a particular access pattern for these tables.

CT Catalog

K2 C2, C5-C8 tables with 32 KB pages

K3 C1, C3, C4 tables with 32 KB pages

L2 C2, C5-C8 tables with 8 KB pages

L3 C1, C3, C4 tables with 8 KB pages

M2 C2, C5-C8 tables with 16 KB pages

M3 C1, C3, C4 tables with 16 KB pages

N1 Non-categorized tables with 16 KB pages




NI Non-categorized indexes

W3 32 KB page work files

W4 4 KB page work files

��

� � ��'��(�

� �� &,

As the number of getpages is not available within the ST10 output (and is alsoimportant for categorizing tables) the procedure makes an assumption that there is agetpage for each row returned. This is another reason for regular buffer poolmonitoring and adjusting the initial settings that are based on the ST10 output only.

− ��0�� SAP and IBM recommend the following initial mapping:

%��&�&' ��

' �� "�(� ��BP0 Catalog

BP1 4 KB page work files

BP2 Non-categorized 4 KB page tables

BP3 Indexes for non-categorized tables

BP4 Category C8 tables and indexes








BP8K0 Non-categorized 8 KB tables

BP8K1 C2, C5-C8 8 KB tables

BP8K2 C1, C3, C4 8 KB tables

BP16K0 Non-categorized 16 KB tables

BP16K1 C2, C5-C8 16 KB tables

BP16K2 C1, C3, C4 16 KB tables

BP32K Non-categorized 32K-page tables

BP32K1 32 KB page work files

BP32K2 Category C2, C5, C6, C7, and C8 32 KB page tables

BP32K3 Category C1, C3, and C4 32 KB page tables

You can change a buffer pool proposal that is provided used for a tablespace directlyfrom the table categorization screen if you do not want to accept the suggested setting.The buffer pool must be active.To do this:

1. ALTER the buffer pool under ��0�� .

2. Select the entry from the tables categorization screen and choose �!��&

An ALTER TABLESPACE statement is generated and executed.

��

� � ��'��(�

��&/ � ��

1��

You can only change a buffer pool of a tablespace when the tablespace is stopped. Atpresent, this can only be done manually. If you do not stop the tablespace, you get aruntime error with SQL error -626.

To be able to execute the ALTER TABLESPACE command, the user <SAPSID>adm orICLIRUN needs one of the following DB2 authorizations:

• SYSADM

• SYSCTRL

• USE privilege for the buffer pool

��*��( ��' �(��'��# ��' �(��

Tablespace rather than table is the object of most DB2 utilities (most notably REORG).Also, the buffer pool assignment is done on a tablespace basis. DB2 monitoring is bettersupported for tablespaces than tables. This is why it is better to isolate frequentlyaccessed and/or large tables in their own tablespaces.

At installation time a large number of tables are already isolated in their own tablespaces.However, for some sites there could be additional tables that need to be isolated. Also,consider partitioning of the tables that are likely to grow very large. Refer to Chapter“Storage Management”, section “Changing Storage Parameters” for details on how to dothis.

��2��(��

The size of the buffer pools depends on the amount of available central and expandedstorage (if hiperpools are used), the number of SAP systems and other non-SAP systemworkload that is performed in the same CEC. Therefore, only relative sizes can be givenunder the assumption that a fixed amount of central storage is allocated to the SAPSystem. If there is extended storage that is available for use, consider utilizing it forhiperpools where applicable. The buffer pool attributes depend on the category of tablesthat are assigned to the buffer pool.

The �� !�� table gives an example of buffer pool definitions. Considerthese settings as an initial iteration only in a continuous exercise of the buffer poolsmonitoring and tuning. Use DB2 performance monitors to examine all the relevantindicators of buffer pools efficiency such as hit ratios, critical thresholds reached, writeratios and so on. Based on these indicators and new samples of ST10, adjust buffer poolassignments and parameters to achieve optimal performance. Be particularly aware ofhitting critical thresholds and overcommitting central or expanded storage.

It is important to understand that transaction DB2B is not a perfect source of indicatorsabout tables' access patterns. For example, very random access, treadmill effects, andbuffer update reference patterns cannot be detected without using additional techniques.A work-around is to temporarily isolate a table with an unusual or unexpected accesspattern into its own buffer pool and use buffer pool statistics that is now implicitly

��

� � ��'��(�

� �� &)

applicable to that table for better understanding of the access pattern. To access bufferpool tuning, call transaction DB2B and choose Simulate BP settings. Enter how muchcentral storage is available for all buffer pools that are used by the SAP system.

The sizes represent the state after the tables that account for 80% of accesses have beenreassigned from the initial buffer pool setting as described in � �3��!!��. Asthe entire procedure is most likely to be iterative (20-30 tables at a time) you need toadjust the values accordingly.

The following is an example of buffer pool settings based on 300 MB central storage forbuffer pools and 300 MB central storage for hiperpools.

' ��

'� $�� 936,=( 936(47 ':47 9':47 +36,=( +36(47 &$67

BP0 Catalog 2000 50 50 10 0

BP1 Sort work files 5000 100 70 50 0

BP2 Non-cat. 4 KBtables

4000 40 30 5 8000 40 YES

BP3 IndexesBP2,BP32K

6000 40 30 5 12000 40 YES

BP4 C8 tables andindexes

1000 10 70 50 0


1000 30 10 5 0


7000 30 40 10 0


8000 30 40 10 0


7000 30 20 5 14000 30 YES


8000 30 20 5 16000 30 NO


5000 60 50 10 0


4000 60 20 5 8000 60 YES

BP8K0 Non-cat. 8 KBtables

200 40 50 30 400 40 YES

BP8K1 C2, C5 - C88 KB tables

500 40 40 10 0

BP8K2 C1, C3, C48 KB tables

300 40 30 5 600 40 YES

BP16K0 Non-cat. 16 KBtables

200 40 50 30 400 40 YES

��

� � ��'��(�

��&3 � ��


500 40 40 10 0

BP16K2 C1, C3, C416 KB tables

300 40 30 5 600 40 YES

BP32K Non-cat. 32 KBtables

400 40 50 30 800 40 YES

BP32K1 32 KB page workfiles

100 100 70 50 0


900 40 40 10 0

BP32K3 C1, C3, C4,32 KB tables

600 40 30 5 1200 40 YES

Depending on the number of tables in a buffer pool, the VDWQT can be different towhat is recommended earlier. Set it so that the number of tables is slightly larger than theratio DWQT/VDWQT. If there is only one table in the buffer pool, setVDWQT=DWQT.

To modify your buffer pool settings, call transaction DB2B.

1. Select the buffer pools you want to change on the �� !�� screen.

2. Make your changes to the settings and choose �!�� .

1��

The buffer pool settings are not applicable for R3SETUP. Use the sizes andparameters as recommended in the IBM documentation� !��"�� #�$�%%!��.

To be able to execute this command, the user <SAPSID>adm orICLIRUN needs one of the following DB2 authorizations:

• SYSOPR

• SYSCTRL

• SYSADM

��

� � ��'��(�

� �� &4

��5;�$�*1

The EXPLAIN function uses DB2 EXPLAIN which uses a special table, PLAN_TABLE,that stores the results of the EXPLAIN function. If no PLAN_TABLE exists, the EXPLAINfunction creates :

• Plan table <SCHEMA>.PLAN_TABLE

• Statement table <SCHEMA>.DSN_STATEMENT_TABLE

These two tables are located in a tablespace whose name is generated by DB2. Thecorresponding database is called SYOOX<CCC>, where �CCC� are three randomlygenerated characters.

1��

At present, the statement table is not exploited.

If an SAP system user uses the EXPLAIN function, the statement is explained into theplan table and the resulting rows are read and deleted. The query number 1548979326used is always the same. You should not use this query number if you intend to use DB2EXPLAIN directly. The enqueues are used to make sure that multiple users of explainare serialized properly.

There are two views on the PLAN_TABLE:

• Standard view (plan table data expressed as user-friendly text)

• Expert view (content of the plan table)

If you run SAP BW or SAP APO and the default DB2 parallelism degree is 1, you havethe possibility to dynamically turn on parallelism for the explanation of the access pathof each individual SQL statement.

You can access EXPLAIN in the following ways:

• Call ST05 and choose 1��/.��.

• Call transaction DB2 and choose 12%!��.

• Call transaction ST04 and choose �� or &��(

��

� � ��'��(�

��

1��

If you have problems using EXPLAIN within the SAP System (duplicate records,invalid SELECT statement when reading the plan table), the <SCHEMA>.PLAN_TABLEis probably not defined correctly.

You can solve this problem by dropping the databases and/or tablespaces that contain<SCHEMA>.PLAN_TABLE and <SCHEMA>.DSN_STATEMENT_TABLE or deleting allentries from these tables. Then retry the EXPLAIN within the SAP system.

Statements used by the EXPLAIN function to create the tablespace and are listed in theIBM documentation ��)�� .

��2��6��7

The DB System Check was originally designed to monitor the state of the database and tobe used as a collection point for error messages and warnings that pertain to the database.With the introduction of the CCMS monitor set, the DB System Check has lost a lot of itsimportance. For this reason, DB System Check is only partially implemented on DB2UDB for z/OS.

DB System Check allows you to check the installation parameters of your DB2subsystem against a set of suggested default values. The suggested values can be changedby the user and, depending on the significance of the change, may result in warnings orerror messages.

These are passed on and recorded automatically in the CCMS monitor set.

�� 7��

To maintain check parameters, call one of the following transactions:

Call transaction DB17.

Call transaction DB2 and choose ��→'��%��.

The system displays which DB2 installation parameters need to be checked. Theparameter values included in the list are the ones recommended in the � �3��!!��0

To change a check parameter, choose '��(��*. In the single parameter maintenancescreen you can make changes to any of the modifiable fields and to the error message andcorrective action texts.

Some parameters �� be changed. These parameters can only be set to active orinactive. However, it is always possible to edit error and corrective action messagesbelonging to a parameter.

The last modification you make is always recorded. If you want to return to the last savedversion, choose the screen entry. Alternatively, choose � ��! to return to thedefault parameter.

��

� � ��'��(�

� ��

��!��(��2��6��7

To view the results of the DB System Check, call one of the following transactions:

Call transaction DB16.

Call transaction DB2 and choose ��→��$�(��.

To run a report that checks the parameters against the specified values in DB17, choose ��. The report produces a list that informs you whether there is an error, awarning or whether the parameter is OK.

To display statistics, double-click an item in the list.

To display a summary, choose ��(.

To see details of the warning or error, choose ��!�. The warning or error message, theplanned and actual values, and a corrective action message are displayed.

The warnings are automatically copied from the DB System Check to the CCMS MonitorSet Overview.

1��

If you delete logs in the DB System Check, the corresponding record in the alertmonitor is �� affected. This means you might have to delete the corresponding alertsin the CCMS monitor set separately.

��

� � ��'��(�

��

��*�$*��

1��

The ICLI trace section does not apply for application servers on z/OS.

1��

The ICLI trace should only be used by experts. Tracing can considerably impact theperformance of the entire system.

You can use the following ICLI diagnostic means:

• ICLI server trace

To display an overview of the files in the log directory on the ICLI server, choose��* ��.

To display the contents of a trace file, select one or more files and choose ��*��!��.

• ICLI server message level

• ICLI client trace

• Network statistics

• ICLI ping

• ICLI server communications trace

This function enables you to start traces on the ICLI server and the ICLI client traceonline without stopping the SAP System. You can choose the kind of trace you want bysetting the appropriate number.

For more information on the different traces, see the F1 help and the IBM documentation !��"�� #�$��%%!��0

��

' �(�� *��+��

� �� &

��' �(�� *��+��The tables and indexes monitor provides status information on the following topics:

• Number and size of tables, indexes and tablespaces

• Detailed information on any one of these

• Consistency checks between the ABAP Dictionary and the database

��!�<��

��=� �� *��((��

The tables and indexes monitor collects size and status information about the tables,tablespaces, and indexes of the SAP System or- with MCOD- of all SAP Systems withinan MCOD landscape. It gets some of this information directly from the DB2 catalog, forexample the number of tables. However, some information has to be collected at theoperating system level, for example all space information.

Therefore, some of the information presented by the monitor is obtained using z/OSutilities (LISTCAT function of the IDCAMS program). To do this, a JCL job that performsa LISTCAT over the whole subsystem is generated, uploaded to the host and submittedfrom within the SAP System. It may take some time until the job has been finished andthe output of the JCL job has been transferred to the SAP System. FTP is used to transferthis job to the host.

��!�<��"'�

See the prerequisites in section ;1�3�� in Chapter 5.

��!�<��>�$�>��

The JCL job is generated from a job template by substituting given profile parametervalues for certain variables. You must enter these profile parameter values before z/OSjobs can be submitted from the SAP System.

For the tables and indexes monitor, you must enter the JES hold output class before z/OSjobs can be submitted from the SAP System. Use the JES Interface, function ��!� ��, to enter this value.

1��

We recommend that you also maintain all other profile parameters. See section ;13�� for more information.

��

' �(�� *��+��

��

��' �(�� *��+��

��8��( 6��*�� "��?�'��!��2��

� ��

The information provided in the tables and indexes monitor is not collected by themonitor itself. The initial screen is empty. You must choose the -�� button atleast once to be able to display data.

To display current values when needed, you can refresh the initial screen on request.Choosing -�� immediately releases program RSDB2T2M as a background job. Thisjob invokes the previously mentioned LISTCAT function.

This feature is not to be used for regular updates of the displayed information. Instead theprogram should be scheduled periodically to provide reliable history information.

By default, the LISTCAT output file is deleted from the application server after dataanalysis. You can prevent the file from being deleted by entering KEEP in the commandfield on the initial screen of transaction DB02. This affects only the next -�� run.

��:�� ((6

Use the DBA Planning Calendar to update the data periodically. For more information,see the section “DBA Planning Calendar” in chapter “Database Administration”.

��*� (��

To access the ��$��%��"��$!��2�� initial screen, choose one of thefollowing:

• Choose ��→�(��→�'��→� ��→��$��→�&�$!��3��2��

• Call transaction DB02.

• Call transaction DB2 and choose &�$!�� 2��.

��

' �(�� *��+��

� �� ,

�� !��%��)��

��*�� ( 6��*� (��

The following information is listed under�� (��"

• ��(��DB2 indicates you are running the SAP system on DB2 UDB for OS/390 and z/OS.

• � ��(��3��Name of the SAP systems residing in the database. The graphic shows an MCODsystem (Multiple Components in One Database) with three systems named M5C,M5D and KDF in the same subsystem. If you do not use MCOD, there will still beonly one name shown.

1��

Under rare circumstances, there will be one or more entries in the style ofSCHEMA=schema-name,for example, SCHEMA=SAPR3. The systems, to whom thecorresponding entries belong, did not broadcast their existence to the other systemsyet. You should log on to the corresponding system and call transaction DB2J. Theentry should be updated automatically and is visible with the correct name the nexttime you display the ��$��%��"��$!��2�� initial screen. Formore information concerning this broadcast, see the section “MCOD and CCMS” inthe chapter “Basics”.

��

' �(�� *��+��

��/ � ��

• ��!(��Date and time of the last update of the initial screen, that is, date and time of the laststart of program RSDB2T2M.

The following information is listed under ��:

• &��!��$��Number of tablespaces in the subsystem.

• &��!��+more exactly, high allocated RBA,Allocated space of the VSAM data sets representing tablespaces, summed over alltablespaces in the subsystem.

• &��!��+more exactly, high allocated RBA - high used RBA,Difference of allocated and used space of the VSAM data sets representingtablespaces, summed over all tablespaces in the subsystem.

1��

The total amount of storage needed is larger due to unusable space on the tracks. Formore information, see the IBM documentation ��)��0

The following information is listed under ��:

• &��!��$��Number of indexes in the subsystem.

• &��!��(more exactly, high allocated RBA)Allocated space of the VSAM data sets representing indexspaces, summed over allindexspaces in the subsystem.

• &��!��(more exactly, high allocated RBA-high used RBA)Difference of allocated and used space of the VSAM data sets representingindexspaces, summed over all tablespaces in the subsystem.

• '��$��<� ��(��3�=Number of indexes defined in the ABAP Dictionary, but non-existing in thedatabase. Exceptions registered in table DBCHK are considered.

• '�� (��<� ��(��3�=Number of indexes existing on the database and created by <SCHEMA> but notdefined in the ABAP Dictionary. Exceptions registered in table DBCHK areconsidered.

The following information is listed under ��"

• &��!��$��Number of tables in the subsystem.

��

' �(�� *��+��

� �� )

• &��!��Used space of the VSAM data sets representing tablespaces, summed over alltablespaces in the subsystem.

• '��$��<� ��(��3�=Number of tables defined in the ABAP Dictionary, but non-existing in the database.Exceptions registered in table DBCHK are considered.

• '�� (��<� ��(��3�=Number of tables existing on the database and created by <SCHEMA> but not definedin the ABAP Dictionary. Exceptions registered in table DBCHK are considered.

��7��6

To check the consistency between the database and the ABAP Dictionary or to displaymore detailed information about database objects, choose �� in the ��$�� "�&�$!��3��2�� screen.

You can choose between the following options:

• '��:��2��Provides a check on existence and uniqueness of indexes in the ABAP Dictionary aswell as in the database. In this respect this is a subset of the ��$��↔��(check, but it automatically rechecks and presents up-to-date information. Thisrecheck is faster than the recheck in the ��$��↔��( check.

• ��$��↔��(Performs a consistency check between the database and the ABAP Dictionaryconcerning tables, indexes and views. You have the choice between displaying theinformation of a prior check, or doing a lengthy recheck. It is possible to create itemsthat are missing from the database.

• � �(��Calls transaction SICK, which checks the consistency between the SAP kernel andthe database concerning items, such as release number, character set and somecritical structure definitions like SYST, T100, TSTC, TDCT or TFDIR.

The above checks can also be accessed by calling transaction DB2 and choosing��.

��

To display the database space statistics, choose %�� in the ��$�� "�&�$!��3��2�� screen.

This function provides a history of database space information as shown on the initialscreen. You can choose between a daily, weekly or monthly view on the data.

�� (��*�� ' �(��

To display detailed information on tablespaces, choose ��!��!(�� under&�$!��%�� in the ��$�� "�&�$!��3��2�� screen.

A list of all tablespaces in the subsystem is provided as well as size information on anyone of them. The number of tablespaces displayed is limited to the set maximum number

��

' �(�� *��+��

��3 � ��

of hits in the Data Browser. To enter the selection criteria for the tablespace list, choose��!(�� → 9�*��!��. You can change the number of displayed tablespacesunder Data Browser settings. All settings entered in this screen are user-specific and arepermanently valid in the Data Browser. Double-click a line of the list for more detailedinformation on the selected tablespace. You can choose the following options:

• &�$!��2��

A list of all tables contained in the selected tablespace is generated. Double-click aline to display detailed information on the table and its indexes.

• ��!��!(��

Information on the selected tablespace as provided by the DB2 catalog tablessysibm.systablespace and sysibm.systablepart is shown. In addition, thereis storage information available (for example, number of extents, primary andsecondary quantity, allocated and free space, list of volumes) as returned by theLISTCAT function. Since the catalog entry giving the number of pages is updated bythe RUNSTATS utility, date and time of the last RUNSTATS are also provided.

• >��(

The size of the selected tablespace is listed in intervals of days, weeks or months asdesired.

To display information on the dynamics of tablespace sizes, choose %��under &�$!��%�� in the ��$�� "�&�$!��3��2�� screen. You canchoose between ��(, *�� or �� as the unit of time. Tablespaces only appear in thelist if they were subject to any changes in allocated or free space, or the number ofextents. The space history for a selected tablespace can be accessed by double-clickingthe list.

�� (��*�� *��+��

To display detailed information on indexes, choose ��!��!(�� under 3��2�� inthe ��$�� "�&�$!��3��2�� screen.

A list of all indexes in the subsystem is provided as well as size information on any oneof them. The number of indexes displayed is limited to the set maximum number of hitsin the Data Browser. To enter the selection criteria for the indexes list, choose ��!(�� → 9�*��!��. You can change the number of displayed indexes under DataBrowser settings. All settings entered in this screen are user-specific and are permanentlyvalid in the Data Browser. Double-click a line of the list for more detailed information onthe selected index.

• ��!��!(��

Information on the selected index as provided by the DB2 catalog tablessysibm.sysindex and sysibm.sysindexpart is shown. In addition, there isstorage information available (for example, number of extents, primary andsecondary quantity, allocated and free space, list of volumes) as returned by the

��

' �(�� *��+��

� �� 4

LISTCAT function. Since the catalog entry giving the number of pages is updated bythe RUNSTATS utility, date and time of the last RUNSTATS are also provided.

To display a list of missing indexes, that is, indexes defined in the ABAP Dictionary thatdo not exist on the database and vice versa, choose '��2��.

�� (��*�� ' �(��

To display detailed information on tables, choose ��!��!(�� under &�$!��in the��$�� "�&�$!��3��2�� screen.

This function generates a list of tables in the subsystem. A selection screen gives you theoption of limiting the range to tables, tablespaces and databases matching a given pattern.To display more information on the selected table, double-click the list.

You can choose the following options:

• ��!��!(��

Returns information on the table and all its indexes as provided by the DB2 catalogtables sysibm.systables and sysibm.sysindexes.The size of the table is approximated by the product of the number of pagescontaining data and the pagesize. Since the catalog entry giving the number of pagesis updated by the RUNSTATS utility, date and time of the last RUNSTATS are alsoprovided.

• ��

Shows type and length of all columns of the selected table as defined in the ABAPDictionary and created on the database, respectively.

��5+��

You can access the extent monitor by choosing one of the following:

Choose 12��'��in the initial screen of the table and index monitor

Call transaction DB2 or ST04 and choose 12��.

��5+��

The threshold levels in the extent monitor are taken from the DB Alert Settings. Bydefault, the low threshold is 25 and the high threshold is 80.

The extent monitor shows a table of all tablespaces and indexes in the subsystem that atthe time of the last run of the LISTCAT job showed more extents than specified underlow threshold. (See also “DB Alert Settings”).

In order to get the very latest extent information, RFCOSCOL in its role as database alertrouter is exploited (see ‘DB Performance Monitor’). It sends specific exception events,such as data set extents to the SAP System. These events are incorporated into the tableshown in the extent monitor.

The objects are split into two levels of urgency, according to the number of extents:

• ��(�6:Number of extents >= high threshold

��

' �(�� *��+��

��,� � ��

If the number of extents exceeds the high threshold, a reorganization will berequired.

• ��(��:high threshold > number of extents >= low thresholdThe object is marked for observation. You may have to increase the secondaryquantity.

The objects are specified using their name and the database (for tablespaces, type TS) orthe creator (for indexes, type IX). For partitioned tablespaces or indexes the affectedpartition is identified, otherwise the �� column contains a 0. For tablespaces orindexes that have several data sets, the data set in question is identified in the ��column by its last qualifier.

�� 6�9� �6

1��

"��users with the authorization profile S_DB2_DBADM (DB2 UDB for OS/390 andz/OS database administrator) can change the size of the secondary quantity from theextent monitor. Page sets that belong to a different SAP system cannot bemanipulated that way.

The ��:�( column shows the current size of the secondary quantity in KB. Tochange this value, select the corresponding lines in the table, enter the required size inthe field 9�*��:�(, and choose �!��%��. If successful the column ��:�(shows the new (changed) value, the column .��.&1- contains the date of the lastchange (directly after the last change, that is, the current date). The column 12�0�$��shows the number of extents before the last change (initial: 0), so that you can see howquickly the tablespace or index occupies new extents after ALTER.

��@�(��"��

You can use this function to see how much freespace there still is on a volume.

1. Call transaction DB02.

2. Choose 5�!��%��0

3. Enter the required volume on the following screen.

An z/OS job is generated and executed under your user ID. This obtains theinformation directly from the z/OS host.

1��

See the information on the SAP system user ID and TSO password in the section“Monitoring Tables and Indexes”, subsection “Requirements”.

��

' �(�� *��+��

� �� ,�

After executing the job, whose runtime depends on the size of the volume, you will seethe freespace on the volume in cylinders, as well as the number of free data set controlblocks (DSCBS) on the volume.

��'��(��

This information is taken from SAP Notes.

�� A �6��

The refresh job has been executed, some values are displayed, but all values for the space information are 0.

��

The JCL job that gathers the space information has probably been aborted.

If you do not specify any profile parameters, the submission of the JCL job is aborted and you find an entry in the system log. The system log entry will also be written if any errors occur in the JCL submission service. Since there is no space information available in this case, you get the initial values for the tablespace sizes, that is, 0.

�� (��

Check the system log and make sure that all your profile parameters have been maintained with the JES Interface (transaction DB2J).

.

��A �6��

The refresh job fails. The return code of the LISTCAT job is 8.

��

At least one of the data sets the LISTCAT job has processed has been migraged byHSM.

�� (��

Change the JCL skeleton LISTCAT_LEVEL in the JES interface (transaction DB2J). Replace the parameter ‘ALLOC’ with ‘ALL’. This enables LISTCAT to cope with migrated data sets (NON-VSAM). However the size of the job output more than doubles with this parameter. If you are sure that your job has failed due to migrated data sets, you could also consider using ‘maxcc= 0’ and keeping ‘ALLOC’.

��

' �(�� *��+��

��,� � ��

��A �6��

The DB02 refresh job executes without errors, that is, transferring the job to the host runs smoothly, as does the execution of the job. Nevertheless, no size specifications are delivered back about tablespaces and index spaces.

��

The MSGLEVEL=(1,1) specification or something equivalent is missing in the jobheader of the JCL Interface (Transaction DB2J). This means that the actual size information from the LISTCAT job are not collected. The result file on the application server is, therefore, only a few KB large.

�� (��

Add the MSGLEVEL=(1,1) specification or something equivalent into the job header. This will enable the LISTCAT job to also return the size information for page sets.

��

��

� �� ,&

��

��2��@/

To access the CCMS monitor set, choose one of the following transactions:

• Call transaction RZ20.

• Call transaction DB2 and choose ��'��.

You can access the monitors using the standard SAP CCMS Monitor Templates or usingyour own monitor that you have customized to display selected elements of the monitortree structure. For more information on the CCMS monitor set,for example, forcustomization, see the SAP Online Documentation.

The following tree elements under ��$�� → <3�= → ��)��!��$�� are being used:

• P��→��Tables needing a RUNSTATS

• P��→�!�� (

Refer to section DB Alert Router

• -��(�→��!!��%��DB2 installation parameters that differ from the required or recommended values.Refer to section ��(��.

• S%�� → �� → ��$!��%��

Tablespaces needing reorganization

• S%�� → �� → ��2Indexes needing reorganization

• S%��→��2��Tablespaces or indexes that exceed the extent thresholds. See the section “DB AlertRouter”.

• >��!�� → O$?��

The database objects, which are in some restricted state, are listed here in the formatDBName. TSName for tablespace and DBName.IndexspaceName for indexes.

• >��!�� → ��!��

Active log shortages. Refer to section ��!��-��.

• >��!�� → ��!��

Refer to section ��!��-��.

• >��!�� → ��

Refer to section ��!��-��.

��

��

��,� � ��

• B��%��→�$��%Tablespaces with no backup

1��

The following nodes always exists in the CCMS monitor set. Do �� delete them.

• -��(→��!!��$��%→��!(�(DO NOT DEL)

Program that runs an automatic daily check. The tool checks whether a page setrequires RUNSTATS, REORG or COPY processing.

• -��(→��!!��$��%→��!(�+��9�&��1.,Program that runs every hour. The tool checks whether the objects are in ��mode.

• -��(→��!!��$��%→@��+��9�&��1.,Program that runs every five minutes. It updates database alerts that have beenreported by the database alert router (RFCOSCOL).

Please be aware, that each of these nodes collects at most 20 single alerts. If any ofthe nodes exceed 20 alerts, there will be one collective alert displayed instead,mentioning that there are many alerts. You can display all these alerts using theanalysis tool, for example, by double-clicking on the collective alert.

��!:1�'�'��

This checks whether update statistics (RUNSTATS) should be recommended for any of thetables. Tables that qualify for update statistics are displayed and entered into tableDBSTATC at the run of RUNSTATS needed with the TOBDO flag set to X.

Alerts are only raised if the �� flag in the DBSTATC table is �� set to N for the tableconcerned. If only a few tables (less than 20) are affected, an alert is shown for eachindividual table. If more tables are affected, a single collective alert is displayed toinform the user that RUNSTATS is recommended for a number of tables. You can displaythese tables using the analysis tool.

The check tool relies on regular (hourly) runs of the monitor job RSCOLL00Collector_for_Performance (refer to SAP Note 12103). This job collects table statisticsfrom which the amount of change in a table, in other words, the sum of all inserts,updates, and deletes can be determined. Days on which there is no information availableare identified with zero changes. This situation can occur when the monitor job did notrun or when a day is too far back in the past, and no history information is available forthat day.

��

��

� �� ,,

([DPSOH

Table X underwent significant changes on 25.09., but was not changed after that date.Table statistics for Table X were collected between 28.09. and 30. 09. In this case, thedecision logic would determine that the table does not require RUNSTATS, althoughthis would in fact be necessary. However, if you make sure that the check is done atregular intervals, you should not encounter any problems.

An alert is raised in the alert monitor for the following tables:

• Tables, where the STATSTIME field in SYSIBM.SYSTABLES is initial

• Tables, where a certain number of changes have occurred.We recommend running RUNSTATS when the following conditions are both met:

− The absolute number of changes is greater than 50

− At least 15% of the table content in terms of rows has been changed (number ofall entries in a table is in column CARDF in SYSIBM.SYSTABLES)

1��

If you want to exclude tables from this procedure, you can set the �� flag to N inthe DBSTATC table in maintenance transaction SM30. In other words, an alert is onlyraised when the �� flag in the DBSTATC table is �� set to N for a table.

��!5#!��

The RSDB2RIT program runs once every day and checks which tablespaces and indexesneed to be reorganized. The tablespaces to be reorganized are entered in table DB2REOTSand the indexes are entered in table DB2REOIX. Indexes in a tablespace that is to bereorganized are not entered in table DB2REOIX because these indexes are automaticallyreorganized with REORG TABLESPACE.

��!�� -�� ' �(��

The RSDB2RIT program accesses the DB2 catalog tables SYSIBM.SYSTABLEPART andSYSIBM.SYSTABLESPACE and determines which tablespaces should be reorganizedusing the following indicators:

• CARDF > 0

• 100 * (NEARINDREF + FARINDREF) / CARDF > 10

The program also accesses the DB2 catalog tables SYSIBM.SYSINDEXPART,SYSIM.SYSINDEXES and SYSIBM.SYSTABLES and determines which indexspacesshould be reorganized using the following indicators:

• CARDF > 0

• (NEAROFFPOSF + FAROFFPOSF) * 100 / CARDF > 10

• CLUSTERING = ‘Y’

��

��

��,/ � ��

The tablespaces and indexspaces to be reorganized are then listed in the DB2REOTStable, which has the following columns:

• DBNAME: Database name of the tablespace

• TSNAME: Tablespace name of the tablespace

• TSPARTS: Partition of the tablespace

• NOREORG: Flag whether tablespace is to be excluded from REORG

• NEEDREORG: Flag whether tablespace needs a REORG

��!�� -�� *��+

The RSDB2RIT program accesses the DB2 catalog tables SYSIBM.SYSINDEXPART,SYSIM.SYSINDEXES and SYSIBM.SYSTABLES and determines which indexes should bereorganized. A LEAFDIST value of more than 200 is used to indicate that an index needsto be reorganized.

The DB2REOIX table contains the indexes to be reorganized and has the followingcolumns:

• IXCREATOR: Creator name of the index

• IXNAME: Name of the index

• IXPARTS: Partition of the index

• NOREORG: Flag whether index is to be excluded from REORG

• NEEDREORG: Flag whether index needs a REORG

��!�� - ��*��

You can access reorganization information in the DB2REOTS or the DB2REOIX table.

To access these tables, call transaction SE16 and enter the name of the table.

In the NOREORG column you can determine whether a tablespace or index in generalshould be excluded from REORG. If you enter 9 (for 9�) for a tablespace or index, noREORG is executed on this tablespace or index. If you enter A (for A1) a REORG isexecuted. A is the default value.

The tablespaces or indexes that need to be reorganized are set to A (for A1) in theNEEDREORG column. Once a REORG has been executed on the tablespace or index, thevalue is set to 9 (for 9�,0

In other words, if NOREORG and NEEDREORG both are set to A(for A1).

1��

If you schedule the REORG from outside the SAP system, the value is not set to 9 (for9�).

The CCMS monitor set (transaction RZ20) lists the database name and the tablespacename for the tablespace, and the creator and the index name for the index when there arefewer than 20 tablespaces or indexes. If more than 20 tablespaces or indexes areaffected, a single collective alert is displayed to inform the user that REORG is

��

��

� �� ,)

recommended for a number of tablespaces or indexes. You can display them using theanalysis tool.

��1��2 �7��

The RSDB2BCKCOLL program checks whether there are any tablespaces with OWNER<SCHEMA> without a backup using the Control Center stored procedure DSNACCAV.The Control Center has to be installed and requires additional GRANTS. For moreinformation, see SAP Note 388676.

All tablespaces and indexspaces that have no backup older than one day are displayed intwo tables.

You can display these tables using the analysis tool. See the section on the CCMSBackup Monitor for more information.

��!��

The RSDB2RTC program displays which tablespaces and indexspaces are in -��mode using the Control Center stored procedure DSNACCAV. The Control Center hasto be installed and requires additional GRANTS. For more information, see SAP Note388676.

All tablespaces and indexspaces that are in -�� mode are displayed in two tables.

��

��

��,3 � ��

��2��@)

To access the CCMS monitor set, choose one of the following transactions:

• Call transaction RZ20.

• Call transaction DB2 and choose ��'��.

You can access the monitors using the standard SAP CCMS Monitor Templates or usingyour own monitor that you have customized to display selected elements of the monitortree structure. For more information on the CCMS monitor set, for example, forcustomization, see the SAP Online Documentation.

The following tree elements under ��$�� → <3�= → ��)��!��$�� are being used:

• B��%��→�$��%Tablespaces with no backup

• P��→��Tables needing a RUNSTATS

• P��→!��(Refer to section DB Alert Router

• -��(�→��!!��%��DB2 installation parameters that differ from the required or recommended values.Refer to section ��(��.

• S%��→��2��Tablespaces or indexes that exceed the extent thresholds. See the section “DB AlertRouter”.

• S%�� → �� → ��$!��%��, S%�� →�� → ��2

Tablespaces and indexes needing reorganization

• >��!�� → O$?��The database objects, which are in some restricted state, are listed here in the formatDBName. TSName for tablespace and DBName.IndexspaceName for indexes.

• >��!�� → ��!��Active log shortages. Refer to section DB Alert Router.

• >��!�� → ��!��Refer to section ��!��-��.

• >��!�� → ��Refer to section ��!��-��.

• ��%��→$��%Tablespaces with no backup.

��

��

� �� ,4

1��

The following nodes always exist in the CCMS monitor set. Do �� delete them.

• -��(→��!!��$��%→��!(�+��9�&��1.,Program that runs an automatic daily check. The tool checks whether RUNSTATSREORG or BACKUP is needed or whether there are tablespaces that do not have abackup.

• -��(→��!!��$��%→��!(�+��9�&��1.,Program that runs every hour. The tool checks whether the objects are in ��mode.

• -��(→��!!��$��%→@��+��9�&��1.,Program that runs every five minutes. It updates database alerts that have beenreported by the database alert router (RFCOSCOL).

Please be aware, that each of these nodes collects at most 20 single alerts. If any ofthe nodes exceed 20 alerts, there will be one collective alert displayed instead,mentioning that there are many alerts. You can display all these alerts using theanalysis tool, for example, by double-clicking on the collective alert.

��!� (�'�� 2��@��)

Beginning with DB2 V7, Real Time Statistics (RTS) are collected for easy andinexpensive detection of database objects needing some DBA intervention. The collecteddata include a large number of statistics values such as the number of rows inserted,deleted, changed since the last RUNSTATS, REORG or COPY. DB2 always generatesin-memory statistics for each tablespace and indexspace. When the statistics is to beexternalized, DB2 examines the in-memory data, calculates the new totals, updates thenew real-time statistic tables with the new totals and resets the in-memory data. Thisprocess is an asynchronous task. The tables where the real-time statistics is stored areSYSIBM.TABLESPACESTATS and SYSIBM.INDEXSPACESTATS in theDSNRTSDB.DSNRTSTS tablespace.

The data collected in the RTS is examined by a stored procedure named DSNACCOR,which recommends running a utility based on complex calculations with this data. WithDB2 V7, the SAP system utilizes DSNACCOR instead of keeping track of changes itself.

��

��

��/� � ��

1��

The benefit of DSNACCOR is that also objects not belonging to SAP or belonging todifferent SAP systems in an MCOD environment (see chapter “Basics”, section„MCOD and CCMS“) are respected in the calculations. Be aware that you will get alarger number of alerts.

The steps necessary for correct installation of RTS and DSNACCOR are described in theSAP installation guides. For more information on both subjects, see the IBMdocumentation ��)��57�)��!��(��-��.

Using DSNACCOR, you can tune the thresholds for recommendation yourself:


2. Choose ��!��.

3. Choose ��. This enables you to change all the thresholds DSNACCOR uses.Under normal circumstances, the default settings should be sufficient. For moreinformation on each of the values and its role in the calculation for recommendations,refer to the online help and to the IBM documentation �� 57)��!��(��-��.

��

��

� �� /�

��!:1�'�'��

This checks whether update statistics (RUNSTATS) should be recommended for any of thetablespaces. Tablespaces that qualify for update statistics are displayed and entered intotable DBSTATC at each run of RUNSTATS needed with the TOBDO flag set to X.

Alerts are only raised if the �� flag in the DBSTATC table is �� set to N for thetablespace concerned. If only a few tablespaces (less than 20) are affected, an alert isshown for each individual tablespace. If more tablespaces are affected, a single collectivealert is displayed to inform the user that RUNSTATS is recommended for a number oftablespaces. You can display these tablespaces using the analysis tool, for example, bydouble-clicking the alert.

1��

If you want to exclude tablespaces from this procedure, you can set the �� flag toN in the DBSTATC table in maintenance transaction SM30. In other words, an alert isonly raised when the �� flag in the DBSTATC table is �� set to N for a tablespace.

With DB2 V7, DSNACCOR also provides a possibility to prevent alerts on a tablespaceor indexspace via the exception table. We also support this feature, and so you have thechoice which one of the tables DBSTATC or exception table to use. We recommendusing the exception table, since it will prevent treatment also for objects not belonging tothis SAP system and for any of the other utilities. For installation of the DSNACCORexception table, refer to the SAP installation documentation.

You can specify any tablespace or indexspace by inserting its name into column NAMEand its database name into column DBNAME. You can insert any string into columnQUERYTYPE or you can leave it empty.

The SAP system recognizes the keywords RUNSTATS, REORG and COPY forexclusion of the respective utility. Take care to separate each keyword from the otherswith a space. For REORG you may specify single partitions, for which REORG isexcepted by specifying REORG= n1, n2,…,nm where n is a partition number. Make surethere is no space between the numbers and the comma. The sequence of the numbersdoes not matter.

([DPSOH

You want to exclude partitioned tablespace TESTDB.TESTTS from RUNSTATS,COPY and also from REORG on partitions 1, 3, 7 and 13. Issue the following SQLcommand in SPUFI:

INSERT INTO DSNACC.EXCEPT_TBL(dbname, name, querytpye)VALUES(‘TESTDB’, ‘TESTTS’, ‘RUNSTATS REORG=1,3,13,7 COPY’)

The SAP system will automatically fill the exception table with a predefined set oftablespaces on which RUNSTATS is not recommended and the corresponding

��

��

��/� � ��

indexspaces. For more information, see the section “When RUNSTATS is due” inChapter “Performance Tuning Considerations”. If you insert other tablespaces, theindexspaces of the indexes on tables in that tablespace (associated indexspaces) areadded automatically with the same QUERYTYPE. The SAP system will only add them ifthey are not yet inserted. This means that if you change the QUERYTYPE column of atablespace in the exception table, the entry of the associated indexspaces will not beautomatically updated. You must do this manually. The corresponding associatedindexspaces can be identified in the columns ASSOCDB and ASSOCTS.

When leaving QUERYTYPE empty of inserting a string containing no keywords, theSAP system treats this as if keywords RUNSTATS and REORG were defined.

��!5#!��

The RSDBA_COLLECT_DAILY program, that runs once every day with default settings,checks which tablespaces and indexes need to be reorganized by invoking DSNACCOR.The tablespaces to be reorganized are entered in table DB2REOTS and the indexes areentered in table DB2REOIX. Indexes in a tablespace that is to be reorganized are notentered in table DB2REOIX because these indexes are automatically reorganized withREORG TABLESPACE.

��!�� - ��*��

You can access reorganization information in the DB2REOTS for tablespaces or theDB2REOIX table for indexes. To access these tables, call transaction SE16 and enter thename of the corresponding table.

In the NOREORG column you can determine whether a tablespace or index in generalshould be excluded from REORG. If you enter 9 (for 9�) for a tablespace or index, noREORG is executed on this tablespace or index. If you enter A (for A1) a REORG isexecuted. A is the default value.

You can achieve the same result by inserting the name of the tablespace resp. indexspaceinto DSNACCOR exception table. For installation and use of the DSNACCOR exceptiontable, see the IBM documentation �� 57�)��!��(��-��.

The tablespaces or indexes that need to be reorganized are set to A (for A1) in theNEEDREORG column. Once a REORG has been executed on the tablespace or index,the value is set to 9 (for 9�,0

1��

If you schedule the REORG from outside the SAP system, the value in theNEEDREORG column is not set to 9 (for 9�). It will only be reset after the next runof RSDBA_COLLECT_DAILY program.

��

��

� �� /&

The CCMS monitor set (transaction RZ20) lists the database name and the tablespacename for the tablespace, and the creator and the index name for the index when there arefewer than 20 tablespaces or indexes. If more than 20 tablespaces or indexes are affected,a single collective alert is displayed to inform the user that REORG is recommended fora number of tablespaces or indexes. You can display them using the analysis tool, forexample, by double-clicking the alert.

��1��2 �7��

The RSDBA_COLLECT_DAILY program checks whether there are any tablespaces orindexes defined with COPY YES in the subsystem without a backup using the storedprocedure DSNACCOR.

You can display the result set using the analysis tool, for example by double-clicking thealert. See the section on the CCMS Backup Monitor for more information.

��!��

The RSDBA_COLLECT_HOURLY program checks whether there are any tablespaces orindexspaces in the subsystem in -�� mode using the stored procedure DSNACCOR.

You can display the result set using the analysis tool, for example, by double-clicking thealert.

��

��#��#$��-.#�

��/� � ��

��#��#$��-.#�SAP on DB2 UDB for OS/390 and z/OS includes the SAP operating system collector(SAPOSCOL). SAPOSCOL for z/OS is different to operating system collectors on otherplatforms. Specific features are described below.

1��

You should always use the latest SAPOSCOL for z/OS. Refer to SAP Note 103135.

See the SAP Online Documentation for general information on the operating systemcollector.

��:��#��#$��-.#�

SAPOSCOL provides information that can assist in detecting resourcebottlenecks. It runs as a z/OS UNIX System Services process and gets selectedperformance data from the RMF Monitor II (SMF records 79) snapshots. SAPOSCOLsamples the data every 10 seconds and generates hourly statistics for the last 24 hopurs.The data is stored in the shared memory where it is accessed by another process calledRFCOSCOL.

This process can read the most recent snapshot, the previous snapshot, and the hourlydata and pass it back to the SAP application server using a remote function call(RFC), for example, to the user who requested the data via SAP transaction OS07, orOS06. A periodically scheduled SAP batch job moves the performance data into adatabase table.The data is available for a month and can be accessed by calling transaction OS07or OS06.

��*�� ((��#��#$

The following files in z/OS UNIX System Services (OpenEdition) are needed to collectsystem operating data:

• saposcol

• rfcoscol

• librfccm.dll and saprfc.ini

• start_oscol (Start script)

In addition, the RFC DLL librfc must be installed and specified in the environmentvariable LIBPATH. These requirements are usually met after installation of the SAPsystem and after (optional) installation of SAPOSCOL.

Also, an RFC destination must have been defined in the SAP system and declared as theSAPOSCOL destination. This is done automatically when the application server is started.

��

��#��#$��-.#�

� �� /,

�� (�*�� (( �� '��(��

To install SAPOSCOL manually and for troubleshooting, see the SAP installationdocumentation, Appendix “SAPOSCOL, RFCOSCOL and RFC Library for z/OS” or��*+,*,-.

��6��*��

To obtain configuration information about your system from the initial screen, choose��!��!(�� and (��3��. If your system is running in a SYSPLEXenvironment, you will see all the systems in the SYSPLEX. Selecting one of the systemspresents you with the LPARs of the CPU in question, provided that system is run inPR/SM mode. If your system is not part of a SYSPLEX, you can choose (��3�� to access information about LPAR distribution directly.

��B��$5;��

SAPOSCOL for z/OS collects its data for each system in the SYSPLEX in which it was started,except for LAN, filesystem and Top CPU processes stats, that can only be collected for the system where the SAPOSCOL process is running. It is a requirement for SYSPLEX support that RMFMonitor I (or a compatible product that supports SYSPLEX Gathering Services) isrunning on all SYSPLEX systems using option(SMFBUF(SPACE(32M),RECTYPE(70:78)).

From the initial screen, you can choose any system in the SYSPLEX from the list. Todisplay the list, choose ��(��. The data for the chosen system is displayed onthe initial screen. You can also access history data from the current system.

��6��

You can monitor more than one SAP system using just one SAPOSCOL process if theassociated databases are running on the same system or in the same SYSPLEXenvironment.

Choose SAP systems from the initial screen to obtain a list of SAP systems, each with itscorresponding DB2 subsystem ID and the name of the database server. When thefunction is called for the first time, the current system does not have the entry for thedatabase server. At this point, SAPOSCOL determines which SAP system ID is associatedwith which DB2 subsystem. SAPOSCOL uses this information to locate where DB2 isrunning. When you choose the �� option, the DB server name is updated at the nextSAPOSCOL interval (usually after approximately ten seconds).

To add additional SAP systems to this list, choose �� (�� and enter the systemID and the associated DB2 subsystem ID. After one SAPOSCOL interval, the databaseserver of the new SAP system is displayed in the list.

��( 6��

To display data collected by SAPOSCOL in the SAP system, call transaction OS06 orOS07. When you call the transaction, a dialog box with available SAPOSCOL destinationsis displayed. Entries are listed as ��%��!_<��%> where <��%> is the parametername specified for the TCP/IP connection to the database host dbs/db2/hosttcp.

��

��#��#$��-.#�

��// � ��

When you choose an entry, the initial SAPOSCOL screen for z/OS appears. This screenhas the following title:

-��+<��%��!��=,��'��"�<�%��(��=

The following tables list the values are displayed in the initial SAPOSCOL screen forz/OS:

��

��#��#$��-.#�

� �� /)

�� .��/��

��

�� )�+(��, System CPU utilization. In a PR/SM logical partition:LPAR view. In native mode: same as �� )+��,

�� )�+��, z/OS view of CPU utilization

��

��

��0�(�� -�� System-wide paging rate

&��!�%0�%�� Rate (number per second) of pages swapped in duringprevious interval

&��!�%0�%�� Rate of pages swapped out during last interval

��%0�%�� Rate of private area (VIO + non-VIO) pages paged induring previous interval. This includes single pages andfirst page of each block.

��%0�%�� Like ��%0�%�� for paged out pages

�!��%0�%�� Rate of private area (VIO + non-VIO) pages paged in, inblocks, not including the first page

9��$��$!�� Number of blocks paged in from AUX (private) duringprevious interval

��

��#��#$��-.#�

��/3 � ��

�)��

��

��2%�� Rate of pages sent to expanded storage during previousinterval

��2% Rate of pages migrated from expanded storage toauxiliary storage during previous interval

��$��

��

>��)3�� Highest unreferenced interval count (UIC) taken at thelast snapshot

12%�� Time a page resides in expanded storage before itmigrates to auxiliary storage, taken at the last snapshot

��!��!0 Total number of frames on all currently availableframe queues, taken at the last snapshot

12%��!0 Number of expanded storage frames currentlyavailable and not in use, taken at the last snapshot

0��1��2

��

�� Rate of all IP packets received during the previousinterval

�� Rate of all IP packets sent during the previous interval

1�� Rate of IP packets that could not be received due to anerror during the previous interval

1�� Rate of IP packets that could not be sent due to anerror during the previous interval

��!!�� Always 0, not collected on z/OS

��=��6��

To display history data from the initial screen, choose ��!��!(�� and � ), ��, �� or .�9�under� ��. This provides access to data collected inthe previous 24 hours.

��

��#��#$��-.#�

� �� /4

��

You can monitor address spaces allocated to a specific SAP system using SAPOSCOL forz/OS. You can access information and resources that each address space needs or hasassigned to it.

To obtain a list of address spaces that are associated with an SAP system:

1. Select an entry from the list of SAP systems.

2. Choose ��!�.

Among these are the address spaces that belong to DB2. If an SAP system has not beenadded to the SAP systems list explicitly, the display will also include address spaces thathold threads in DB2. This applies, for example, to the ICLI and the DB alert router.

The following table lists the display fields and their meaning. All times and numbersrefer to the last interval.

��

;�$�� Name of the job

3�&�� Transaction residency time (swapped in time)

��&�� Transaction out time (ready and not ready)

�� Device connect time used by the job in milliseconds

&�� TCB time

-� SRB time

� ) Processor time (TCB+SRB) in milliseconds

�3� Number of pages swapped in

�� Number of pages swapped out

-��! Average number of real frames

��!�* Number of fixed frames below 16 megabytes

�� Number of private fixed frames

1B� Number of EXCP

If you need detailed information about additional address spaces, choose ��%�� and enter the name of the address space. If data about an address space are nolonger needed, you can mark the entry in the list and delete it by choosing ��!��%��.

��

��

��

��

��

�� !��"�#��$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$��% General Overview......................................................................................................5–3 Backup.......................................................................................................................5–5 Online Backup ...........................................................................................................5–5 Offline Backup ...........................................................................................................5–6 Backup Procedure: Recommendations.....................................................................5–9 CCMS Backup Monitor with DB2 V6 .......................................................................5–10 CCMS Backup Monitor with DB2 V7 .......................................................................5–12 Recovery..................................................................................................................5–14 Recovery to the Current State .................................................................................5–14 Recovery to a Prior Point in Time............................................................................5–14

�&'��(��)�� $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$�� Profile Parameters...................................................................................................5–21 SYSPLEX Failover Support .....................................................................................5–22 Prerequisites............................................................................................................5–22 Listing z/OS jobs......................................................................................................5–22 Creating and Saving z/OS JCL Jobs .......................................................................5–23 Changing z/OS JCL Jobs ........................................................................................5–23 Deleting z/OS JCL Jobs...........................................................................................5–23 Displaying z/OS JCL Jobs .......................................................................................5–23 Entering a TSO Password .......................................................................................5–23 Creating and Changing an Individual Jobcard.........................................................5–24 Submitting z/OS JCL Jobs Asynchronously ............................................................5–24 Execution Type ........................................................................................................5–24 Checking the Status of the Job................................................................................5–24 Deleting the Job Output on z/OS and on the Client.................................................5–25 Displaying the Job Output........................................................................................5–25 Cleaning Up the JES joblog Directory .....................................................................5–26

��*��+��*��$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$��, Preparations for Using the DBA Planning Calendar ................................................5–27 Plannable Actions ....................................................................................................5–28 Basic Functions .......................................................................................................5–29 How the DBA Planning Calendar Works .................................................................5–30 Using the DBA Planning Calendar...........................................................................5–31 Support of SYSPLEX Failover .................................................................................5–31 Backup.....................................................................................................................5–31 Recovery..................................................................................................................5–32 Rebuild Index...........................................................................................................5–32 Reorganization.........................................................................................................5–33 Update Statistics (RUNSTATS)...............................................................................5–34 Updating the Table and Index Monitor.....................................................................5–36 Restarting Jobs........................................................................................................5–36 Displaying the DB2 Utility Status .............................................................................5–37 Checking the Results of Actions..............................................................................5–37 Adjusting the jobs ....................................................................................................5–38

��

�� !��"�#��

��

Central DBA Planning Calendar ..............................................................................5–39

��

�� !��"�#��

�� %

�� !��"�#��For the most up-to-date information on Backup and Recovery Options, see SAP Note83000.

��*�#!��!��-

Backup and recovery are processes that ensure that an SAP database can be reinstatedwith minimal disruption in operations after any kind of hardware, software, operationalor environmental error or downtime. These processes are a crucial factor in the systemavailability and reliability and need careful assessment of their requirements,understanding of the processes, and skillful planning, developing and practicing of theprocedures.

Some of these processes are done automatically by DB2 UDB for OS/390 and z/OSwithout any outside intervention, such as recovering the SAP database to its consistentstate just before an z/OS system crash or DB2 UDB for OS/390 and z/OS abnormaltermination. Automatic recovery happens at the next DB2 UDB for OS/390 and z/OSstart. For other processes, there are integrated tools in DB2 UDB for OS/390 and z/OS,some of which can be optionally enhanced with z/OS hardware and software features thatcan be used for building efficient and reliable backup and recovery procedures.

The backup and recovery procedures need to be set up by database administrators foreach individual SAP database. Their characteristics depend on:

• System availability requirements

• Rate of change of the SAP database

• SAP database size

• Hardware and software resources

Basically, the higher the value of any of the first three factors, the more demanding thebackup and recovery procedures.

.��

An SAP database includes all the tablespaces, indexes and DB2 UDB for OS/390 andz/OS catalog and directory entries (practically all the catalog and directorytablespaces and indexes) that are pertinent to the SAP system. From the viewpoint ofoperational and semantic integrity, an SAP database as a whole needs to beconsidered a single unit of recovery. In other words, if a single SAP tablespace needsto be recovered to a point in time, all other SAP tablespaces and indexes need to beeither also recovered to the same point in time, or already be at the state that they hadat the time. A prior point in time recovery is an example when the entire SAPdatabase might need to be recovered, while a recovery to the current state is anexample when only damaged tablespaces and indexes must be recovered; the rest isalready at the current level.

��

�� !��"�#��

��/ ��

Some general recommendations relevant to backup and recovery in the SAP systemenvironments are:

• ��− Understand DB2 UDB for OS/390 and z/OS backup and recovery processes.− Assess the factors that influence the characteristics of the backup and recovery

processes.− Develop procedures for all kinds of backup and recovery situations that might

arise in your installation.− Practice these procedures at a time when it does not interfere with normal

operations.− The recovery to a prior point in time is more complicated if you allow critical,

non-SAP applications to be managed by the same DB2 UDB for OS/390 andz/OS subsystem (or DB2 UDB for OS/390 and z/OS data sharing group) as yourSAP database. Although this does not apply to the recovery to the current pointin time (normally much more frequent than the former), we recommenddedicating a DB2 UDB for OS/390 and z/OS subsystem or DB2 UDB for OS/390and z/OS data sharing group to an SAP database only.

• �� − Use dual logging for the active log, archive log, and bootstrap data sets.− Place the copies of the active log data sets and bootstrap data sets on different

DASD volumes.− Do not discard archive logs that are more recent than the earliest consistent copy

of any SAP tablespace, or even older than that, depending on your need for aprior point in time recovery.

− Consider producing multiple backup copies.− Keep level backups to extend the interval within which it is possible to perform a

prior point in time recovery. This also reduces the impact of backup data setswhich might be damaged (inconsistent).

− Avoid backing up tablespaces that contain inconsistent data (intra-page datainconsistency). Use the DSN1COPY, DSN1CHKR and CHECK INDEX utilities todetect such inconsistencies in the users and catalog/directory tablespaces.

− Make backups of the DB2 UDB for OS/390 and z/OS catalog and directory,especially after the activities that involve a lot of DDL, such as R3load,transport, SAP upgrade.

− To speed up recovery, use more and larger active logs, consider archiving todisk, or be sure to have enough tape drives. Also, keep the buffer pools and logbuffers at the values recommended for the SAP system (in other words, large).

��

�� !��"�#��

��

The following sections present a summary of backup and recovery options that could beused in the SAP system environment. See the following DB2 UDB for OS/390 and z/OSdocumentation for more information:

• �� , Section “Operation and Recovery”

• ��

• ��

• ��

��

The appropriate backup process is a key factor for data recovery. In simple terms, therecovery process consists of selecting a backup of the tablespace and applying all thechanges (recorded in the log) that occurred between the time the backup was taken andthe time the recovery is requested to. Theoretically, DB2 for OS/390 and z/OS couldrecover the tablespace from the log only, but this is not recommended.

The main characteristics of a backup process are:

• Frequency, in other words, how often a tablespace is backed up

• Tools used to produce backups

The optimal backup process is a trade-off between its usage of resources (CPU, DASD,tapes) and increased contention with other concurrent activities in the system on onehand, and the speed of recovery on the other. The shorter the log apply phase, the fasterthe recovery. Frequent backups of all of the data pages containing committed rows only,provide the fastest recoveries. However, this has a higher cost in resources and impedesthe concurrent activity in the system to an extent that might not be acceptable.

There are two main types of backup. In this documentation these are referred to as �� and ��.

��#�*��

A tablespace online backup is a copy of the tablespace during which continuous,concurrent read/write activity on the tablespace is allowed. Therefore, except for a smallprocessor and DASD overhead, the online backup has no impact on the concurrent SAPactivities.

As it can contain uncommitted data, such a backup alone is never enough for thetablespace recovery. DB2 UDB for OS/390 and z/OS complements it with the log.

In DB2 UDB for OS/390 and z/OS terms, it is a sharelevel change full image copy of thetablespace. An important aspect of the online backup is the “incremental” online backup.This is a copy of only those tablespace data pages that have been changed since the lastbackup.

The DB2 COPY utility with the SHRLEVEL(CHANGE) option is an efficient tool forcreating online backups. Other COPY options are:

• FULL

Specifies whether a full (YES) or incremental (NO) image copy is to be created.

��

�� !��"�#��

��0 ��

• CHANGELIMIT

Allows you to let DB2 decide whether to take a full or incremental image copy,depending on the number of pages changed since the last image copy. Werecommend you use the CHANGELIMIT specification where only one value isspecified.

• COPYDDN and RECOVERYDDN

Allow you to create up to four identical copies of the tablespace.

��#))*��

A tablespace offline backup is a copy of the tablespace during which concurrent writeactivity on the tablespace is �� allowed. As a result, all the data is in committed statuswhich means that this backup alone could be used for the tablespace recovery, but only tothe point in time at which the offline backup was taken.

.��

Offline does not mean that either the DB2 subsystem or the SAP system must beoffline. The concurrent read/write activity can continue on all other tablespaces, aswell as read only on the tablespace being backed up. However, for the tablespacesthat are heavily updated by many concurrent users and in that sense consideredcentral to the SAP database, preventing the write access during the offline backup canbe extremely disruptive to the entire SAP system. This particularly applies if themethod for taking the offline backup is not fast enough.

In DB2 UDB for OS/390 and z/OS terms, it is a sharelevel reference full image copy ofthe tablespace. Like the online backup, the offline backup can also be “incremental”only.

The DB2 COPY utility with the SHRLEVEL(REFERENCE)option is an efficient tool forcreating offline backups. The FULL, CHANGELIMIT, COPYDDN and RECOVERYDDNoptions are applicable as well. Another option for this purpose is CONCURRENT, whichcan significantly reduce the time during which the tablespace is unavailable for writeactivity.

A special type of offline backup is an SAP database offline backup. This is a set ofcopies of all of the tablespaces and DB2 catalog and directory taken during the timewhen no write activity is allowed in the system. This is a very restrictive way of backingup the data and should be used only where the SAP operations can afford such adowntime (for example, if there are some periods of no activity). On the other hand, theSAP database offline backups provide excellent prior point in time recovery targets.

DB2 and z/OS offer a number of ways to implement such a backup:

��

�� !��"�#��

�� ,

��#))*��-��"

You can perform an offline backup as follows:

1. Make sure that no users with update intentions are present in the system. You cancheck this using the following commands:

START DATABASE (*) ACCESS(RO)START DATABASE (DSNDB01) ACCESS(UT)START DATABASE (DSNDB06) ACCESS(UT)

If there are plans bound with RELEASE (DEALLOCATE) that access thedatabases, you must stop them (with the STOP command) before starting themfor read-only access.If a non-native DB2 tool, such as RAMAC Virtual Array Snapshot, performs thenext step, you must quiesce the database. Use the DB2 QUIESCE utility with theWRITE (YES) option.

2. Run the DB2 COPY utility:COPY TABLESPACE tspace1COPY TABLESPACE tspace2.

. list all the SAP and DB2 for OS/390 and z/OS catalog and directorytablespaces.COPY TABLESPACE DSNDB01.SYSUTILCOPY TABLESPACE DSNDB06.SYSCOPYCOPY TABLESPACE DSNDB01.SYSLGRNX

To speed up the process, create a number of COPY jobs that can be run in parallel.The elapsed time can be improved significantly if you group the tablespaces in a waythat reduces DASD path contention.

Another possibility is to make a non-DB2 registered copy of all the tablespaces andindexspaces by using the RAMAC Virtual Array Snapshot feature, where available.This is the fastest method to copy the data, but makes recovery more complicated.See the IBM documentation �� for more information.

3. Restart the DB2 databases to allow normal access.

��

�� !��"�#��

��1 ��

��#))*��-��"

Another example of creating an offline backup of the SAP database uses CONCURRENTCOPY:

COPY TABLESPACE tspace1

TABLESPACE tspace2

.

. list all the SAP and DB2 catalog and directory tablespaces

. except SYSUTIL, SYSCOPY and SYSLGRNX .

CONCURRENT

COPY TABLESPACE DSNDB01.SYSUTIL CONCURRENT

COPY TABLESPACE DSNDB06.SYSCOPY CONCURRENT

COPY TABLESPACE DSNDB01.SYSLGRNX CONCURRENT

This method does not need the separate quiesce and restart steps. The database activitywill be quiesced and made available again automatically. However, be aware that theconcurrent copy might fail in the phase of “hardening” the data (physical copy), in otherwords, after the logical copy has successfully completed and the SAP database is madeavailable for read and write. In this case, the copy as a whole has not succeeded and theoffline backup has not been created. After removing the cause of the problem you need torepeat the process.

You can also create an offline backup of the SAP database by DFSMSdss DUMP orCOPY functions.

��

�� !��"�#��

�� 2

��

Each SAP system installation should choose a backup procedure that is optimal to itsparticular needs and conditions. The following are recommendations for a backupprocedure that should be used initially by all the SAP system installations and adjustedlater according to the specific needs and conditions.

• After a successful SAP system installation or upgrade (R3SETUP, R3up, SystemCopy) or a prior point in time recovery, make an offline backup of the SAP database.

Consider this a mandatory step.

• If the operations schedule allows, make occasional offline backups of the SAPdatabase. If there is not enough time available to back up the entire SAP database,make offline backups of the heavily updated and critical tablespaces.

This is not a mandatory step, but is nevertheless highly recommended. Offlinebackups are very efficient targets for a prior point in time recovery, especially iftaken by a tool that copies both tablespaces and indexspaces (such as RVASnapShot, or DFSMSdss).

• For any SAP system, catalog and directory tablespace regularly create onlinebackups. How often the backup should be taken and whether it is full or incremental,depends on the tablespace’s change rate. As a starting point, we recommend that yourun the backup jobs every 1-2 days and specify CHANGELIMIT(10). Once youcategorize your tablespaces into heavily, moderately, or lightly updated tablespaces,you can change the frequency of their backups to daily, weekly, or monthly,respectively. You can use transaction ST10 to categorize tables by their accesspattern.

Producing regular online backups is a mandatory step of any backup procedure.

.��

With the CHANGELIMIT option you might end up with seldomly created full backups,which is not efficient from the recovery point of view. For this reason, make sure youhave a full backup created periodically by specifying FULL(YES) orCHANGELIMIT(0). Also consider running the MERGECOPY utility that consolidates afull backup and a number of incremental backups into a new, more recent full backup.

A separate procedure should be developed for a disaster recovery. There are numerousways and tools to implement the procedure. As that exceeds the scope of thisdocumentation, see the IBM documentation for more information.

��

�� !��"�#��

��

��-��30

The SAP system provides the CCMS backup monitor.

To access the initial screen, choose :

��→��→�� →� ��→� �! ��

��4��

To display several backup lists, choose the appropriate function under �! ��in the �� ! ��"�#$��$��%�� ! �� screen. Theselists only contain tablespaces owned by <SCHEMA> or SYSIBM.

��

��

&�� ! �� The last successful backup of each tablespace is shown. The datenext to &�� '��'�! �� on the #$��$��%�� ! �� screen refers to the oldest backup within this report.In the case of partitioned tablespaces, the last complete tablespacebackup and the last single partition backups performed after thatare listed. The backups are displayed with the database name,tablespace name, and timestamp. Information is only shown fortablespaces for which backups have been performed. For adescription of the different columns, refer to the table below.

�! ��$��$��% All backups stored in table SYSIBM.SYSCOPY are shown andterminated copies are highlighted. The backups are displayed withthe database name, tablespace name, and timestamp.

��$�� Partially recovered tablespaces are displayed. Partially recoveredtablespaces have been recovered to a point in time using theRECOVER utility with the option TORBA or TOCOPY. If this onlyapplies to a few tablespaces, the data may be inconsistent due tological dependencies between tables. See the IBM documentation� (��#�)*+,�� and � (��#�)*+,�� for more information.The tablespaces are displayed with the database name, tablespacename, and timestamp.

�'��%�� '�! �

This function displays all database and tablespaces that have nobackup.

Once a day, the object requiring a backup are determined and reported to the CCMSMonitor Set (see ‘CCMS Monitor Set’). Instead of determining these objects again, theCCMS Backup Monitor uses that information. If an analysis is supposed to take placeimmediately, a background job can be scheduled by choosing -�%��.

��

�� !��"�#��

��

��

��*�5��

Several functions can be applied to each of these backup lists:

• Online help is available for each column except ICTYPE.

• Any column of the output list may be sorted by positioning the cursor on the reportfield and choosing ��.

• A detailed view is available for any line by double-clicking the line. This displays allcolumns of that line in SYSIBM.SYSCOPY .

This monitor displays the backup history by reading the relevant data from the catalogtable SYSIBM.SYSCOPY. Backups performed with tools that do not report to this tablewill not appear in the CCMS backup monitor.

��

The columns displayed in the �� ! ��"�&�� '�� ! ��"��%�� screen are described in more detail in the Online Help.

For more information, see the IBM documentation � (��#�)*+,�� and � (��#�)*+,��.&��.

��

�� !��"�#��

��

��-��3,

The SAP system provides the CCMS backup monitor.To access the initial screen, choose:

��→��→�� →�� → �! ��

��4��

To display several backup lists, choose the appropriate function under Backupinformation in the CCMS Backup Monitor - Overview of Backup Status screen. Theselists can only contain tablespaces owned by SAP or SYSIBM and tablespaces in thedirectory database DSNDB01.

��

��

&�� ! �� The last successful backup of each tablespace is shown. The datenext to &�� '��'�! �� on the #$��$��%�� ! �� screen refers to the oldest backup within this report.In the case of partitioned tablespaces, the last complete tablespacebackup and the last single partition backups performed after thatare listed.All columns for that row in SYSIBM.SYSCOPY are listed.Information is only shown for tablespaces for which backups havebeen performed. For a description of the different columns, refer toonline help.

�! ��$��$��% All backups stored in table SYSIBM.SYSCOPY are shown with allcolumns. For a description of the different columns, refer to theOnline help..

��$�� Partially recovered tablespaces are displayed. Partially recoveredtablespaces have been recovered to a point in time using theRECOVER utility with the option TORBA or TOCOPY. If this onlyapplies to a few tablespaces, the data may be inconsistent due tological dependencies between tables. See the IBM documentation� (��#�)*+,�� and � (��#�)*+,�� for more information.

�'��%�� '�! �

This function displays all database and tablespaces that have nobackup.

This monitor displays the backup history by reading the relevant data from the catalogtable SYSIBM.SYSCOPY . Backups performed with tools that do not report to this tablewill not appear in the CCMS backup monitor.The values in the �'��%�� '�! � monitor stem from stored procedureDSNACCOR, which uses real time statistics. For details see chapter “Monitoring andPerformance”, section “CCMS Monitor Set for DB2 V7”.

��

�� !��"�#��

�� %

Once a day, the object requiring a backup are determined and reported to the CCMSMonitor Set (see ‘CCMS Monitor Set’). Instead of determining these objects again, theCCMS Backup Monitor uses that information. If an analysis is supposed to take placeimmediately, a background job can be scheduled by choosing -�%��.

��

The columns displayed in the �� ! ��are described in the Online Help.

For more information, see the IBM documentation � (��#�)*+,��/)#�� and � (��#�)*+,��.&��.

��

�� !��"�#��

��/ ��

�� !��"

The DB2 utility RECOVER is used to recover data. It allows you to recover DB2 objects ofvarious granularity: tablespaces, indexes, partitions, individual data sets, and individualpages. The RECOVER utility can recover data to the following states:

• State captured in a particular backup (the TOCOPY option)

• State at the time corresponding to a �elative �yte ddress (the TORBA option) or a�og �ecord �equence !umber (the TOLOGPOINT option)

.��

RBA is used in non-data sharing and LRSN in data sharing environments.

• Current state by not specifying any of the above options.

The RECOVER utility also has the LOGONLY option, which allows you to recover the datausing the log only starting with a backup that is created outside of the DB2 control (forexample, RVA SnapShot).

�� !��"��

A recovery to the current state is generally less demanding and usually needed moreoften than a prior point in time recovery. A typical example of this is a DASD volumefailure that resulted in a loss of all or some of the data on the volume. The procedure inthis case is to find out which tablespaces and indexes had resided on the volume andrecover only these tablespaces and indexes, or even only the partitions or individual datasets that are affected. The rest of the system is already at the current state (from theoperational and semantic integrity viewpoint) and need not be recovered.

�� !��"��6� �

This type of recovery is used to reinstate the SAP database at some previous point intime. All the changes that had occurred after that time will be lost and the system willappear as it was at that time in the past. The decision to bring the system back in timemust be carefully considered. The typical situation when a prior point in time recoverymight be needed is an application program logic error that introduced unwanted changesinto the system that could not be “reverse engineered”. In some cases, the prior point intime recovery and the loss of data associated with it can be avoided by writing“compensating transactions”. This can only be done by highly skilled specialists withindepth knowledge in both the SAP system as an integrated system and the problemapplication area. In all other cases a prior point in time recovery is the only safe course ofaction.

��

�� !��"�#��

��

There are different methods to accomplish a prior point in time recovery of an SAPdatabase:

• Recovery to the state at the time an offline backup of the SAP database was created

• Recovery to the state at the time the SAP database was quiesced

In most cases the SAP database must be recovered in exactly the same order as describedin the IBM documentation � (��#�)*+,�� 0 ChapterRECOVER TABLESPACE, Section “Recovering Catalog and Directory Objects”. Afterrecovering the SAP tablespaces, RECOVER INDEX must be used to recover all the SAPindexes. Exceptions are recoveries to an offline backup taken by copying the entire set oftablespaces and indexspaces underlying data sets (for example, by RVA SnapShot orDFSMSdss DUMP or COPY) in which case a simple restore of the copied data setscompletes such a recovery.

You can speed up any of these methods by splitting the job into multiple parallelrecovery streams and avoiding the DASD path contention, but observe the restrictionsdocumented in the IBM documentation � (��#�)*+,�� .Also, the SAP system should be stopped and access to DB2 either restricted to recoverjobs only by START DB2 ACCESS(MAINT), for example, or completely denied (STOPDB2), depending on the recovery method used.

Which of the recovery method will be used depends on:

• How fast the data must be available again

• How far back you can afford to recover the system to, prior to the point when thesystem got damaged

• Availability of offline backups

• Whether indexspaces were included in the backup

• Availability of quiesce points.

��

�� !��"�#��

��0 ��

�� !��"�-��*� ��

Recovery with conditional restart is the least obstructive to everyday operations in termsof preparation for a prior point in time recovery of the SAP database.

The main characteristics of this method are that neither offline backups nor quiescepoints need to be provided, which makes it the prime choice in 24 by 7 SAPenvironments. It can also bring the system closest to the time when the SAP database isknown to be semantically and operationally consistent.

The method consists of the following steps:

1. Determine which RBA or LRSN approximates the time T you want to bring thesystem back to. The process differs depending on whether you are operating in a datasharing environment or not:− ��

Translate the time T (given as a timestamp) into its STCK format, that is, theLRSN to which you want to restart the data sharing group.

− !��"�� Determine which log data set covers the interval that contains time T by usingthe print log map (DSNJU004) utility. Run DSN1LOGP SUMMARY on the aboveidentified log data set and determine which RBA is the closest to the time T.Make sure the RBA is a multiple of 4096.

You can speed up the process using the following procedure. It applies to both thedata sharing and non-data sharing environments:

Create a small tablespace that is not used for anything else and frequently run theQUIESCE utility on it (you can automate this task). For each execution, the utilitywill create an entry in the SYSCOPY table, which can be used later to quickly identifyan RBA or LRSN that will approximate the time you want to bring the system backto. In the case of RBA, make sure it is a multiple of 4096. The frequency of theQUIESCE utility execution depends on how close the actual time needs to beapproximated by the RBA or LRSN. The outdated SYSCOPY entries can be removedby the MODIFY utility.

2. Stop DB2.

3. Copy BSDS and all the logs that contain RBAs (or LRSNs) that are later than thosedetermined in Step 1. This will allow you to repeat the recovery in case you decideyou want to recover the data again, but to a later point in time.

4. Use DSNJU003 to create a conditional restart record.− For data sharing, specify ENDLSRS = LRSN determined in Step 1.− For non-data sharing, specify ENDRBA = RBA determined in Step 1.

Leave all other CRESTART options as default.

5. Update system parameters (panel DSNTIPS) and specify DEFER ALL. This optionmeans that all the objects that were in the start state at the RBA or LRSN specified inStep 4 will not be started at the next DB2 start, but placed in a recovery pendingstate.

6. Start DB2.

��

�� !��"�#��

�� ,

7. Recover all the objects including indexspaces (in the prescribed order) to the ��#, in other words, with no TOCOPY nor TORBA/TOLOGPOINT.

In some cases, recovery of DSNDB01, SYSUTILX or SYSCOPY may fail with00E40119. In that case, use the following procedure:a) Identify image copies of these objects that are earlier than the requested prior

point in time.b) Run DSN1COPY to recover the tablespaces from image copies.c) Run RECOVER with the LOGONLY option.d) Recover indexes on the recovered objects.

8. Make an offline backup of the SAP database.

.��

In some very special cases that should never be exercised without indepth expertise inSAP Web Application Server and applications (regularly with a direct SAPinvolvement), a prior point in time recovery consists of writing compensatingtransactions for some tables and recovering only a subset of the SAP database. Insuch cases the conditional restart method cannot be used on the target system, but itcan still play a role in the overall recovery. In other words, the conditional restartrecovery method can be performed on a system that is a copy (auxiliary or temporary)of the target system, and only selected tablespaces brought back to the target system.

�� !��"��6� ��#))*��)��-��

This is the simplest and fastest prior point in time recovery method, but it is also the mostrestrictive.

It requires you to create offline backups of the SAP database. This potentially causeslarge periods of system unavailability that some SAP system installations cannot tolerate.Moreover, depending on the backup frequency, it can take the system much further backthan necessary. For example, if the offline backups of the SAP database are scheduledweekly on Sundays, and the data was damaged on Friday, all the changes made from thelast Sunday to Friday would be lost.

This method can be implemented by the TOCOPY option of the RECOVER utility, RVASnapShot snap back, DFSMSdss RESTORE and so on, depending on how the offlinebackup was created.

��

�� !��"�#��

��1 ��

�� !��"��6� ��-��7��

Recovery to the state at the time the SAP database was quiesced depends on theexistence of “system quiesce points”. These are the points in time when there are nouncommitted update transactions in the system. Such a point is represented by thecorresponding RBA (or LRSN). There are a number of ways to quiesce the SAPdatabase, here listed from the least to the most restrictive to the concurrent SAP systemactivity:

• ARCHIVE LOG MODE(QUIESCE) TIME(n) command

After the command is issued, the new update transactions wait for the commandcompletion. The command is successfully completed if all the update transaction thatwere running at the time when the command was issued were committed before thetime specified in the TIME option expired. Otherwise, the command fails and thequiesce point has not been established.

The TIME value should be 5-10 seconds lower than the resource timeout installationparameter value. That will prevent timeouts on the transactions that are queued afterthe ARCHIVE LOG command. A convenient way to specify the TIME value is to omitthe option and accept the default that corresponds to the QUIESCE PERIODinstallation parameter, provided the parameter is set according to the aboveconsideration.

Although this approach is likely to be the least disruptive to the concurrent SAPsystem activity, its downside is possible multiple failures of the ARCHIVE LOGcommand. These result in an inability to establish quiesce points and cumulativelyhave a bad effect on the concurrent update activity.

The RBA value that corresponds to in this way established quiesce point is recordedin the bootstrap data sets (BSDS) and on the OS/390 console.

��

�� !��"�#��

�� 2

• QUIESCE utility

The utility accepts a tablespace name as an argument, which means that all the SAPand DB2 catalog and directory tablespaces (except SYSUTILX that must be quiescedalone at the end) need to be specified within the same utility execution to establish anSAP database wide quiesce point. The requirement disqualifies this method ofestablishing quiesce points if your SAP database consists of more than 1165tablespaces. This is the maximum number of tablespaces the QUIESCE utility canprocess in a single execution.

Similarly for the ARCHIVE LOG command, the utility suspends all the new updatetransactions and waits for the already running ones to commit. Unlike the ARCHIVELOG command, this wait period can neither be dynamically changed nor made shorterthan the resource timeout installation parameter. It is calculated as a product of theresource timeout value and the UTILITY TIMEOUT installation parameter. Thehigher the utility timeout value, the higher the probability of transactions timeouts.On the other hand, the lower the utility timeout value, the higher the probability ofthe utility timeout, and failure to establish a quiesce point.

The RBA value that corresponds to a quiesce point established in this way isrecorded in the SYSIBM.SYSCOPY table.

• START DATABASE ACCESS(RO) command

Perform the following command sequence:START DATABASE(*) ACCESS(RO)START DATABASE(DSNDB06) ACCESS(RO)START DATABASE(DSNDB01) ACCESS(RO)

wait till the commands are successfully completedARCHIVE LOG MODE(QUIESCE)

only to record the corresponding RBASTART DATABASE(DSNDB01) ACCESS(RW)START DATABASE(DSNDB06) ACCESS(RW)START DATABASE(*) ACCESS(RW)

• STOP DB2 MODE(QUIESCE)

This method is the most restrictive for concurrent SAP system activity. Thecorresponding RBA is recorded as the SHUTDOWN CHECKPOINT in the BSDS and on theOS/390 console.

Once a quiesce point has been established, the SAP database can be recovered to thatpoint if needed. The TORBA or TOLOGPOINT options of the RECOVER utility should beused.

��

�� !��"�#��

��

�� "

The method “Recovery to the State at the Time the SAP Database was Quiesced” is moreadvantageous than the method “Recovery to the State at the Time an Offline Backup ofthe SAP Database was Created”. This is because establishing a quiesce point is lessdisruptive to the SAP system than creating an offline backup of the SAP database.Therefore, it is more likely that the recovery will be possible to a point that is closer tothe required time and the loss of data will be reduced. On the other hand, establishingfrequent quiesce points may impair performance, which is not acceptable for some SAPsystem installations.

��

&'��(��)��

��

��&'��(��)��The JES Interface (transaction DB2J or transaction DB2 → ��!)��→�1�&� '��$��) enables you to submit and monitor any z/OS JCL job from withinthe SAP system. It serves not only as a standalone transaction, but also as an interfaceused by other transactions.

��)�*��

We recommend that you enter values for �� profile parameters that can be maintainedwith the ��function of the JES Interface. For example, you mustmaintain the profile parameter values before z/OS jobs can be submitted from the SAPsystem.

The following table lists some of the profile parameters:

��#� � ��

� (�� '�� Library that contains program DSNTIAD

��&��0��#��&��0��&��2��3

Optional parameters. If not specified, the defaults of thecorresponding ACS routine are used.

4� �� Overwrites the value defined in ��&��, if needed

�� Partitioned data set for uploading z/OS jobs. It mustexist.You may also specify the job names and membernames for jobs to be uploaded.

��→��

Sequential data set for the requested part of the z/OS systemlog. It must exist. It will be overwritten if requested again.The format must be as follows:

#��/��: PS�� : VB�� : 133 ��! ��/�: 27930

.��

These parameters are used by all authorized SAP system users.

��

&'��(��)��

��

��8��4'9�5��*�!��

Under ��, you maintain the following parameters for the DB2 hosts:

• JES held output class

• DB2 load library

• DB2 run library

• Plan of program DSNTIAD

��:��• � ��$ �#

To use the JES Interface, a user needs as a minimum requirement authorization fordatabase administration, in other words, the profile S_A.ADMIN must be entered forthe administrator. The additional profile S_DB2_DBADM authorizes the administratorto change any user’s JCL jobs and the TSO password.

• �� $ �#The user needs to be authorized to run the job submitted on the database system.

• %&��$ �#The communication between the SAP system and the z/OS host is realized usingFTP. To establish a connection, you must make sure that:

− You have TSO access and a TSO user ID

− Your SAP system user ID is identical to the TSO user ID (create a new SAP system user ID if necessary)

− The system knows your TSO password (call transaction DB2J and choose ��%�� to enter your password)

− A restriction of the FTP submission service is that the jobcard must begin with ‘//<tso user id><job sign> ...’. This limits the length of the user ID to seven characters/digits.

− You have authorization to submit JCL jobs

− The user needs authority to create and read data sets under its own high level qualifier (HLQ) on the default volume.

��4��+�;<#��=�

Specify an SAP system user ID in the �� field of the initial screen of the JESInterface to display a list of all existing z/OS jobs created by this user.

To see all existing z/OS jobs in the SAP system, choose &��5'�.

��

&'��(��)��

�� %

��+��!��+�;<#��&�4�&�

To create a job, enter a job name and choose ��.

The character strings ‘$$$’ and ‘*’ are not allowed in job names. An empty string as jobname is also not valid.

You are then prompted to specify one sign to distinguish your job on the z/OS side. Thissign will be appended to your user ID at runtime to build up your job card ( ’//<userid><job sign> .....).

Choose �� to access the SAP editor. The variable $JOBHEAD is already inserted inyour text. It will be replaced by a user specific jobcard at runtime. How to create a user-specific jobcard is described in the section ��$�� 1'��on the following page. Type in the JCL job and choose �$� to save the job andleave the editor.

��+��+�;<#��&�4�&�

To change a job, select an existing job and choose ��. Enter a job sign and choose�� to access the editor.

If you are neither the creator of the selected job nor the DB2 database administrator(authorization profile S_DB2_DBADM), the editor appears in read-only mode.

��*��+�;<#��&�4�&�

To delete a job, select an existing job and choose ��5' in the 67�� menu. Youare only allowed to delete your own jobs unless you have the authorization profileS_DB2_DBADM.

��*�"��+�;<#��&�4�&�

To display a job, select an existing job and choose ��. All variables (for example,$JOBHEAD) are replaced by the real values.

��'��+��6�#��-��

If you submit a JCL job the FTP service logs you on to TSO. To establish the connectionyour TSO password must be known to the system. To avoid you having to enter apassword each time you submit a job, your TSO password (and user ID) is saved in anencrypted way. If there is no valid password stored in the SAP system, you will beprompted to enter your TSO password.

You can also choose ��%�� to create/change your TSO password. This is necessary,if you want to submit z/OS jobs via the DBA Planning Calendar. The administrator withthe profile S_DB2_DBADM is allowed to change any user's TSO password.

��

&'��(��)��

��/ ��

��+��+��+��(��!��*�&��

The user specific jobcard is used to replace the variable $JOBHEAD in the JCL job text. Ifyou do not create your own jobcard, the following default is used:

//$USER$SUFFIX JOB USER=$USER,CLASS=B,MSGCLASS=X,

//MSGLEVEL=(1,1)

The variable $USER will be replaced by the SAP system user ID and the variable$SUFFIX will be replaced by the <job sign> which you define by creating a job. If youchoose 1'��0 the SAP editor is called with a default jobcard. You can change thisjobcard if you want. For example, you may add the SYSAFF parameter.Make sure yousave your changed jobcard by choosing �$�.

For each DB2 host, a separate jobcard can be specified.

.��

Ensure that there are no empty lines in your jobs.

�� +�;<#��&�4�&��"��*"

To submit a JCL job, select an existing job and choose � '�� or �� and � '��.

The FTP service logs you on TSO with your SAP system user ID (the first seven bytes ofyour user ID are used). The FTP submission service does not wait until the JCL job isfinished. You get control immediately after submitting the JCL job on z/OS. The statusof your job is registered as � '�� in the SAP system.

��'>��6"��

You can choose between the following execution types: JCL and stored procedures.

The system has stored procedures set as default.

To access the screen:

1. Call transaction DB2J.

2. Choose ��.

The /)#��1'�� screen appears.

3. Choose 67�� .

You can now change between JCL and stored procedures using the radio buttons.

4. Save your changes.

��+��)��&�

You can monitor the status of your z/OS jobs by choosing 1'�� . A list of z/OS jobssubmitted by SAP system user(s) appears, providing the following information:

��

&'��(��)��

��

��#��!�# � ��

1'�� SAP system name of the z/OS job

1'� z/OS job identifier

� '��'� User ID of the user who has submitted the job

� '�� Day when the job was submitted

� '�� Time when the job was submitted

�� Status of the z/OS job after submission or last refresh

Possible values of the �� field are:

'��

� '�� Directly after submission

�!�%� No information found on z/OS about the job

��$� Job still active on z/OS

�� Job has finished on z/OS

�� No z/OS initiator assigned to the job. Maybe noinitiator started for the CLASS used by that job.

�� z/OS job assigned to an initiator, but all initiatorsstarted for the CLASS used by that job are busy.

By choosing �� the status information of all jobs displayed on the list are refreshed.

To display the status of z/OS jobs submitted by other SAP system users, change the userID in the � '��'� field and choose ��1'�.

��*��+��&��#��;<#��*��

To delete the z/OS job output and the status information of the job, select one or morejobs and choose �� . The status information on the job, the job output on thez/OS side and the job output on the client side is then deleted. You can only delete thejobs you have submitted unless you have the authorization profile S_DB2_DBADM.

��*�"��+��&��#��

To display the job output:

1. Select one or more lines in the status list.

2. Choose �� .

This displays a list of output files belonging to your selected jobs. It contains thefollowing information about the output files:

��

&'��(��)��

��0 ��

��#��!�# � ��

1'�� SAP name of the z/OS job

8�� File name on the client side. The file name containsthe z/OS job ID and an extension numberedconsecutively

��/� Size of the file in bytes on the client side

�� Date when the file was transported from z/OS to theclient side

�� Time when the file was transported from z/OS to theclient side

Usually the file with the highest consecutive number of an z/OS job contains the mostrelevant information.

To display the file contents:

1. Select one or more lines of the list.

2. Choose ��.

��*��+�?��&'��=�*�+��"

The JCL Submission Service uses FTP as the JES interface. The JCL jobs are first of allplaced as file *.jcljob* on the application server in the directory:AIX: /usr/sap/<SID>/SYS/global/JESjoblogNT: \usr\sap\<SID>\SYS\global\JESjoblog

From there the jobs are loaded onto the z/OS host using FTP and are either executedthere or placed in a partitioned data set.

The job output is then in turn transferred to the JES joblog directory using FTP.

To display the contents of the directory, choose 67�� → ��...

You can display the contents of selected files by choosing 8�� → ��, and candelete the files by choosing 8�� → �� if required.

��

��*��+��*��

�� ,

��*��+��*��Some database administration tasks are very time-consuming, or can only be carried outwhen the database is in a particular state. Other tasks must be repeated regularly, forexample backups. You can schedule and coordinate these tasks using the SAP system’sDBA Planning Calendar.

To use the DBA Planning Calendar, choose one of the following:

• Choose � �� → �� from the CCMS menu.

• Call transaction DB13.

• Call transaction DB2 and choose � ��.

• Call transaction DB13 and choose � ��.

Actions can be scheduled in advance using background processing. These actions arethen executed automatically.

��)��?��+��*��+��*��

All database administration tasks must be secure. Therefore, authorization checks mustbe made for certain operations in the SAP system, in the database system and on the z/OShost.

• � ��$ �#In the SAP system( a user needs authorization for database administration andbackground job scheduling to use the DBA Planning Calendar.

The administrator must have the authorizations S_RZL_ADMIN and S_BTCH_ALL,which are included in the operator profile S_A.ADMIN.

• �� $ �#The user must be authorized to run the DB2 utility corresponding to a certainadministration task.

See the DB2 UDB for z/OS documentation �� for moreinformation.

• %&��)� �See section “JES Interface” for how to set up z/OS specifics.

.��

You must maintain �� your profile parameters with the JES Interface (transactionDB2J, function ��).

Jobs generated from the DBA Planning Calendar are partly based on the data from thetable and index monitors (DB02). Make sure that the table and index monitor data isregularly updated.

The size information gathered by transaction DB02 is used for data set allocation, forexample, in REORG and COPY jobs.

��

��*��+��*��

��1 ��

��*��*��

The DBA Planning Calendar’s main function is to specify starting times and parametersfor database actions, which then run without interaction with the administrator. You needto make sure that the necessary resources are available before execution time.

The following plannable actions are currently realized for DB2 UDB for z/OS:

• �! ��'��2� ��3

• ��'�! ��'��2��3

• ��$��'��

• ��$��7

• ��' ��7

• #��6#��'��

• #��6#��7

• #��6#�� '��

• #��6#�� 7��

• ��'5��

• ��'5��

• ��-��'5��%��

• �� ,( (tables and indexes monitor)

��

��*��+��*��

�� 2

��5��

The following basic functions can be executed:

�� "�

�� %�� Double-click the day on which the actionis to be started. The system prompts you tospecify parameters for the action. You canassign a certain time delay (in weeks) toavoid having to plan repeated actions morethan once.

Except for the update of transaction DB02,you can schedule any action either forexecution on the z/OS host or upload acorresponding z/OS job into a partitioneddata set on the host and use an externalscheduler. The desired mode is one of theparameters to be specified.

�� Select an action and change it.

�� 7�� Select an action and choose ��.Unsuccessful actions are highlighted inred in the calendar.

��

Click the header for a day and choose�� to display the parameters and�� to change the parameters of anaction.

�� The current day’s actions can be startedimmediately.

�� Select a specific day and then the actionyou want to delete. Choose ��. Thisfunction is only possible for futureactions.

��'�� Double-click the header of the day onwhich the action was aborted. Position thecursor on the relevant action and choose��. Choose a date and time for therestart. The job can be executed directlyfrom the SAP system or simply loadedinto a partitioned data set on the z/OShost. In this case, it is possible to manuallychange the job before execution.

��

��*��+��*��

��%� ��

Check regularly that the scheduled actions are running correctly. The calendar allowsyou to display and check the status of an action. A job log is generated which containsdetails of the background jobs used. Unsuccessful actions are displayed in the DBAPlanning Calendar in a different color.

All scheduled actions can also be initiated immediately if you define the starting point as��. The actions then run using background processing. This enables you toexecute an action manually if, for example, the planned action was unsuccessful.

��@�-��*��+��*��A��

At the scheduled time, an SAP background job starts which in turn generates an z/OSJCL job performing the administration task. There is an z/OS job template (these arefound in the JES Interface) for each action which is created by the SAP system userSAPR3. It is adapted to the customer specific configuration by substituting current valuesfor several parameters. Since this implies profile parameter values, make sure that youmaintain �� profile parameters with the JES Interface (transaction DB2J), function��.

Once the JCL job has been generated, it is written to the file<date>_<time>_<application server>_<system number>_w<work processid>.jcljob01 on the application server:

AIX: /usr/sap/<SID>/SYS/global/JESjoblog/Windows: \usr\sap\<SID>\SYS\global\JESjoblog\

An FTP connection from the application server to the z/OS host is established using theSAP system user ID (which therefore has to be identical to the TSO user ID) and theTSO password entered with the JES Interface (transaction DB2J).

The JCL job is then transferred to the host and either stored in a partitioned data set orexecuted. The background process waits until the z/OS job has finished. After that, thejob output is transferred back to the application server to a file<userid>_<application server>_<system number>_w<work processid>.result in the same directory as above, and it is deleted on the z/OS host. Thebackground process then continues working.

For each action in the DBA Planning Calendar, you can define a separate job andmember name for upload.

To do this, choose �� → ��.

For more information, see the section “JES Interface”

.��

This only applies for uploading jobs. When submitting jobs, the user ID plus onecharacter is taken because this is required by FTP.

��

��*��+��*��

�� %�

��?��+��*��+��*��

To display the status of a day’s actions, choose the header for a day.

Scheduled actions can be changed or deleted. Executed actions can only be displayed.

Unsuccessful or interrupted actions are shown in red in the calendar and, if there are onlyunsuccessful or interrupted actions, the header for this day is also highlighted in red.

In the scheduling overview, you can see if any logs were written for an action. Byselecting a certain schedule, you can survey the action logs or background job log bychoosing �� and 1'��. These functions detail all logs written on the day youhave selected. Note that the job of “Updating the table and index monitor” does not writelogs.

��)��8��4'9�5��*�!��

During generation of jobs, the DBA Planning Calendar checks which host system isrunning. The data from that host is then taken for the job.

For more information on failover, see the SAP installation documentation.

��

The DBA Planning Calendar gives you the option of making a complete backup (fullimage copy) or an incremental backup (incremental image copy) of all tablespaces in thesubsystem. The incremental backup is only supported in the variant with aCHANGELIMIT threshold. Whilst a backup job is running, other programs have read-writeaccess to the relevant tablespace (SHRLEVEL CHANGE). If the SAP system is part of anMCOD landscape, a backup of the entire MCOD landscape is automatically performed.

.��

For MCOD, simultaneous backups on several SAP systems, which have beenscheduled on different SAP systems, must be avoided in all cases, as these can causeJCL jobs to terminate.

The number of jobs running in parallel is controlled with a profile parameter. If thisvalue is higher than one, an additional job is generated, which separates the directorytables SYSIBM.SYSCOPY, SYSIBM.SYSUTILX and SYSIBM.SYSLGRNX from the otherobjects to avoid locking conflicts.

If you make the backup directly from the SAP system, this job is executed automaticallyonce the other jobs have run. However, if you use the upload function, you have toorganize the job sequence manually. The separate job, named either FICPYSYS (fullimage copy) or IICPYSYS (incremental image copy), is located in the PDS specified forthe upload. Make sure that this job is only executed after the other COPY jobs have run,otherwise locking conflicts could result.

��

��*��+��*��

��%� ��

Generically generated backup jobs require a volume management system that can assigndata sets to certain volumes in a flexible way. z/OS’s functions are not sufficient for this.The Storage Management Subsystem (SMS) must be used.

The data sets created during the copy have the following naming convention:<high level qualifier>.<database>.<tablespace>.IC<nnnnnn> where

n is a number. The primary and secondary allocation of the copy datasets are at most12000 tracks. Also note that each JES job step encompasses no more than 400 DD-statements.

The following profile parameters for backup exist. You maintain these with the JESInterface (transaction DB2J) function ��:

• �� :

− 9��$��: ��− ��&��2��3− ��#��&��2��3− ��&��2��3

− 4� ��

• COPY-specific parameters (choose �#�;):− Number of parallel jobs− �� :

Percentage of the changed pages of a tablespace, above which a full copy, not anincremental copy, is made. For more information, see the IBM documentation� (�� /)#�� <

.��

The backup jobs use data from the table and index monitor.

�� !��"

If required, damaged SAP tablespaces or indexes can be recovered to the current status.Ifit is a partitioned table/indexspace, you have the opportunity to specify a single partitionwhich should be recovered. Recovery to a prior point in time is not possible for anindividual tablespace for consistency reasons.

�� *��(��>

If required, damaged SAP indexes can be rebuilt. In this case, the index is deleted and anew one is created. This can be done using �� or 1�&. The system has�� set as default. To change between stored procedure and JCL, calltransaction DB2J and choose �� → �7�� .

��

��*��+��*��

�� %%

�� +��;��

.��

Before scheduling a REORG job, you should make sure, that you have a reasonablyrecent backup of the system for disaster recovery.

The REORG job allows the reorganization (by partition, if required) of an SAP tablespaceor index during online operation. This means you have both read and write access duringthe reorganization (SHRLEVEL CHANGE). However, note that for LOB tablespaces, anonline REORG is not possible and therefore SHRLEVEL NONE is defined. If at least one ofthe tablespaces, you intend to reorganize, is a LOB tablespace, you are informed. Werecommend that you upload the job to z/OS and submit it only during a maintenancewindow, when the SAP system is down.If the number of extents of the corresponding data sets is larger than four, then the actualREORG is proceded by an ALTER on the primary and secondary quantity as a separate jobstep, so that the table or indexspace shows a maximum of four extents after thereorganization. The primary quantity is chosen to be twice as big as the secondaryquantity. As many sort work and data work datasets are provided as needed.

When performing an online reorganization of a tablespace (not an index), you need tocreate a mapping table (see the IBM documentation � (�� /)#�� ). Inthe first job step, a tablespace DSNDB04.QT<nnnnnn> with the stogroup MAPZZQAA isgenerated. <nnnnnn> is a six digit number. In this tablespace, a table QT<nnnnnn> witha unique index QX<nnnnnn> is created. After successful reorganization, DROPTABLESPACE DSNDB04.QT<nnnnnn> is executed.

.��

For the CREATE statements to run without error, make sure that the stogroupMAPZZQAA exists.

.��

The names QT<nnnnnn> or QX<nnnnnn> are reserved for this application. Do notcreate any tablespaces, tables or indexes with these names.

��

��*��+��*��

��%/ ��

The following profile parameters exist for the reorganization. You maintain these withthe JES Interface (transaction DB2J), function ��:

• Storage Parameters: − 9&. − ��&�� (��) − ��#��&�� (��) − ��&�� (��) − 4� ��

Overwrites the value defined in ��&��0�if necessary.

• General:

− � (�� '��Library containing the program DSNTIAD

− Plan of program DSNTIAD

• REORG-specific parameter (choose �6#��):− Size of work data sets relative to unload data set:

Space requirement grows with the number of indexes; default 2, increase ifnecessary

.��

The REORG jobs use data from the table and index monitor.

REORG ALL indexes and tablespaces uses the same parameters as a single REORG.

��?��B ?.�6�6�C

From the DBA Planning Calendar you can update the statistical information for one or allSAP tablespaces or for those tablespaces for which a RUNSTATS is recommended. Seealso section ��-��.

Many RUNSTATS options are not valid for LOB tablespaces. More precisely, theRUNSTATS jobs for these tablespaces only specify the tablespace name andSHRLEVEL(CHANGE). Other options are ignored when specified. If you run RUNSTATSon a tablespace that owns one or more auxiliary LOB tablespaces then SAP will alsotrigger RUNSTATS on these auxiliary tablespaces.

��

��*��+��*��

�� %�

There are several tablespaces, whose statistics should not be updated to make the DB2optimizer favor an index-based access (see also section �� (��). These are excluded automatically from any update for all SAP tables andrecommended SAP tables. If you have a special reason to update statistics for a certaintablespace that falls into the above category, you have to schedule an ��'5�� and specify the table or tablespace. A dialog box appears promptingyou for confirmation.

.��

Tables DB2NORUN, DBSTATC and DSNACCOR exception table

For several reasons, you might want to exclude tablespaces from the process ofupdating statistics and raising alerts.

To exclude tablespaces from consideration in ��'5��2��-��&&3 and ��-��'5<��%��2��-��&6��3 you have to insert the tablespace name and database name into tableDB2NORUN using transaction SE16 or manually using SPUFI.

In addition, table DBSTATC can also be used to exclude tables from ��-��&6��. As soon as the ��46 flag in DBSTATC is set to N, no alert will be raisedon this table. This implicitly excludes tables from ��-��&6��.

In other words, setting the ��46 flag in table DBSTATC only covers ��-��&6��, excluding tablespaces from ��-��&& is only possible viaDB2NORUN.

When the statistics for the excluded tablespace are not maintained, they continue toraise alerts. If you want to suppress this behaviour, you must set the ��46 flag inDBSTATC to N for all tables within this excluded tablespace.

With DB2 V7, SAP exploits real time statistics and stored procedure DSNACCOR(see chapter “Monitoring and Performance”, section CCMS Monitor Set for DB2V7). Its exception table will exclude any tablespace or indexspace in the subsystemfor consideration for alerts on utility runs. Concerning the comparision betweenDBSTATC and DB2NORUN, it behaves the same way like setting the ACTIVE flagin DBSTATC to N, but you are also allowed to specify indexspaces. In addition tothis benefit, you are no longer restricted to objects within that special SAP system,what may be interesting if you run MCOD or have non-SAP objects apart fromsystem catalog in the subsystem.

There are four parameters concerning RUNSTATS to be maintained in function �� of the JES interface (transaction DB2J):

• - �'��5'� (under RUNSTATS)

You can choose the number of jobs to be executed in parallel, speeding up theprocess.

• &%)�� )��%��(under RUNSTATS)

��

��*��+��*��

��%0 ��

You can choose between three levels of accuracy (low, medium, high). These differin the percentage of lines examined in the table(s). You can set the default level ofaccuracy and the corresponding percentages.

• 67�� (under EXECUTION TYPE)

There are two ways to execute an ��'5��: using JCL orstored procedure. For more information on the installation of stored procedures, seethe �� .

• ��-�� (General parameters section)

For more information on the RUNSTATS utility, see chapter 4 ��'��,section RUNSTATS.

Alternatively, the statistics for a single SAP table can be updated using transactionDB20. This transaction also provides three levels of accuracy. It employs JCL to runRUNSTATS. The JCL job is executed synchronously. In addition, with transaction DB20it is possible to count the total number of rows in a table.

��?��+��6�*��(��>��

The data of the table and index monitor should be updated at regular intervals. So that allCCMS actions can be scheduled centrally, the update of the table and index monitor hasbeen included in the functions of the DBA Planning Calendar.

See the section “Monitoring Tables and Indexes” for more information.

�� +�&�

The JCL jobs started from the DBA Planning Calendar or loaded onto the z/OS host canbe aborted for different reasons, for example, not enough disk space. Some DB2 utilities(COPY, REORG TABLESPACE, REORG INDEX, RECOVER INDEX, REBUILDINDEX, RECOVER TABLESPACE) allow you to restart the job that was aborted. TheDBA Planning Calendar supports this option. Restart allows you to either execute the jobimmediately or load it onto the z/OS host, where it is possible to make changes manuallyto the JCL job before execution.

Normally, you generate Restart jobs using the Restart method RESTART(PHASE).However, if you want to use RESTART(CURRENT), you must use the upload option andadapt the job on the z/OS host.

To restart an aborted job (once you have cleared the error), double-click the header of theappropriate day, place the cursor on the aborted action and choose ��. The SAPsystem determines the Utility ID of the chosen action and checks whether the databaserecognizes a stopped utility with the relevant Utility ID. If this is the case, you canschedule the restart job as described above. Otherwise, an error message is displayed.

��

��*��+��*��

�� %,

��*�"��+��?��*��"��

To display the status of all DB2 utilities jobs, choose � (� �� on the initialscreen.

��+�� *��)��

All actions except “Updating the table and index monitor”scheduled in the DBAPlanning Calendar generate logs, and also give the user details of the results of an action.Background jobs are used to schedule actions and these background jobs generate joblogs. You can view all the information using the DBA Planning Calendar. In addition, allprevious update statistics actions can be displayed.

Select the header for a day to display the status of a scheduled action. This statusinformation is then displayed:

��

��96� The action has been scheduled, but the scheduled time has not yet beenreached.

#= The action has been completed successfully.

6��#� The action has terminated abnormally.

-<� No log giving information about the status of the action is available.It is possible that the action is currently being executed.

��6 The action was executed until the maximum runtime was reached.

>��- The action ended with a warning.

��-� The action was canceled.

� #�� The action was aborted.

Unsuccessful actions are highlighted in red in the DBA Planning Calendar.

If the submission of an z/OS job fails, you can find the error information in the job log.In this case, the SAP job is shown as �� in the DBA Planning Calendar.

If the submission of the z/OS job is successful, you can choose �� to get allinformation about the job. By choosing ��0 a list will be shown where you findthe submitted JCL job on z/OS, the z/OS JES job ID and the SAP name of the job.

To display the z/OS job output, double-click the action and choose 16��5'� �� . Thez/OS job output list is displayed immediately if the list is available on z/OS.

If you need information about the status of the z/OS job, double-click the action andchoose 16��.

��

��*��+��*��

��%1 ��

��=��+��=�

It is possible to adjust the job skeletons that are used in the DBA planning calendar tosuit your individual requirements. This allows you to use brandnew features of DB2utilities that are useful for your shop.To adjust a job skeleton for the DBA planning calendar, proceed as follows:

• Call transaction DB2J (JCL Management Entry).

• Choose ��5'� to display all jobs.

• Select a job whose skeleton you would like to modify. The names of the jobs are self-explanatory, for example the skeleton of the RUNSTATS job for an individual table(or tablespace) is called RUNSTATS_TABLE. Note that the job must firstly beselected in the list and then chosen by selecting the button ‘Select job’.

• Choose �� to go to an editor in which you can make changes to the skeleton.However, keep the rough structure of the job, as the internal parsing routines willotherwise not be able to deal with the skeleton.

• For example, a section of the RUNSTATS_TABLE skeleton looks as follows:

RUNSTATS TABLESPACE $DB.$TS TABLE($TB)

SAMPLE($SAMP) COLUMN(ALL) INDEX($IX)

SHRLEVEL(CHANGE)

In order to use the history option introduced with DB2 V7, you can change theskeleton here as follows:

RUNSTATS TABLESPACE $DB.$TSTABLE($TB)SAMPLE($SAMP)COLUMN(ALL)INDEX($IX)SHRLEVEL(CHANGE)HISTORY ALL

• Save the changes. They are taken into account the next time the relevant job is run.

��

��*��+��*��

�� %2

��*��*��+��*��

The Central DBA Planning Calendar creates a single point of control for managingmultiple databases in SAP system environments. It manages different types and versionsof database systems. Generally, it also enables the administration of non-SAP databases.However, DB2 UDB for z/OS databases can only be managed if they are SAP databases.The Central Planning Calendar can be especially beneficial for managing MCODlandscapes.

To use the Central DBA Planning Calendar, choose one of the following:

• Call transaction DB13C

• Call transaction DB2- Section Performance Tuning- choose ��.

��)��?��+��*��*��+��*��

To manage a remote database using the Central DBA Planning Calendar, you need to setup an RFC connection to the system where the database is located using transactionSM59. The user specified for the RFC connection needs to have a valid TSO equivalentbecause the TSO user is used to submit scheduled JCL jobs.Use DB13C, menu item configuration, to determine which systems to be displayed. Usefor example ‘add systems’ to define the systems to be displayed in the calendar or usechange or delete to update the list of systems.Select “configuration - copy system” if you want to add systems which are alreadydefined in the repository. See the SAP online documentation for more details.

�� )��*�"

To refresh the display of the system from which the Central DBA Planning Calendar hasbeen called, choose &�� on DB13C. The display for all remote systems can berefreshed using button “Remote”. Three options are offered:

− Execute in Dialog (runs in dialog, takes a long time)− Start in Background (runs immediately as background job)− Schedule as Job (the scheduled jobs run "��$ at the specified time)The execution state of the refresh jobs can be monitored on the local system by selecting‘Display job log’.

��*��&�

To schedule actions, you select a database. This implicitly calls the DBA PlanningCalendar of the selected database.You can only schedule DBA actions of the database of the selected system. If a DBAaction has been specified, you are prompted to select the database systems of the sametype for which you want to schedule this action as well. This facilitates the scheduling ofidentical DBA actions on multiple databases. You can update or delete planned actionsfor remote systems on the Central Planning Calendar.

��

��*��+��*��

��/� ��

.��

The DBA Planning Calendar of each database is also capable of running on SAPsystems that make use of a different database.

��

You can monitor DBA actions for the database of the systems that have been registeredusing the Central Planning Calendar. The user interface of central and local DBAPlanning Calendar are very similar. The main difference is that the central versions isonly for viewing DBA actions by systems (from here you can easily switch to localversion). The local version shows actions for one system. You can schedule, change,delete or execute actions there.

The Central Planning Calendar shows only jobs which have been submitted from“DB13C - Local Calendar”. Jobs submitted directly on the local Planning Calendar of aremote system are NOT shown when using “DB13 - Local Calendar” for that system.They can only be monitored using DB13 on the remote system directly.

You can use DB13C, menu item “Calendar - Calendar Display” to customize the screento your needs. The number of weeks to be displayed and the number of lines per weekcan be changed and saved.

For each day, DB13C provides a summary of the DBA actions of each registered system.The number of actions and the number of actions with the highest status severity aredisplayed for each system. Status color-coding for each system indicates if actions havebeen executed successfully.By double-clicking an entry, you can display all actions for the databases.

See the SAP online documentation for more information on the Central PlanningCalendar.

��5��

You can monitor DBA actions for the databases that have been registered using theCentral DBA Planning Calendar.

For each day, it provides a summary of the DBA actions of each database. By double-clicking an entry, you can display all actions for that database.

To schedule actions, you select a database. This implicitly calls the DBA PlanningCalendar of the selected database.

.��

The DBA Planning Calendar of each database is also capable of running on SAPsystems that make use of a different database.

��

��*��+��*��

�� /�

You can only schedule DBA actions of the selected database. If a DBA action has beenspecified, you are prompted to select the database systems of the same type for whichyou want to schedule this action as well. This facilitates the scheduling of identical DBAactions on multiple databases.

SAP AG Storage Management

Contents

March 2002 6–1

Chapter 6: Storage Management

Contents

Changing the Database Layout ...................................................................................6–2 Creating Tables and Indexes.....................................................................................6–2 Modifying Tables and Indexes ...................................................................................6–3 Moving Tables ...........................................................................................................6–4 Rules for Self-Defined Objects ..................................................................................6–5

Storage Parameters......................................................................................................6–6 General Overview......................................................................................................6–6 Editing Storage Parameters ......................................................................................6–7 Changing the Source of Storage Parameters............................................................6–9 Special Actions ..........................................................................................................6–9 Directly Changing Storage Attributes.......................................................................6–10 Moving Tables to Existing Tablespaces ..................................................................6–10 Isolating and Combining Tables ..............................................................................6–11 Partitioning Tables ...................................................................................................6–12 Handling Large Tables.............................................................................................6–15 Mass Processing .....................................................................................................6–16 Incremental Conversion...........................................................................................6–20 Troubleshooting.......................................................................................................6–20

Space Management ....................................................................................................6–22 Adding Volume Space .............................................................................................6–22 Handling the Number of VSAM Extents ..................................................................6–23 Data Compression...................................................................................................6–23

Storage Management SAP AG

Changing the Database Layout

6–2 March 2002

Changing the Database LayoutFor information on how the DB2 database is organized in an SAP system environment,see Appendix B.

Creating Tables and Indexes

Tables

When a new table is created, either by using transaction SE11 or during an upgrade or atransport, the SAP system automatically performs all the necessary steps (for example,creation of database and tablespace if needed). The algorithm depends on the actualbuffering attributes of the table:

• Non-buffered tables

The table is put into a newly created single-table tablespace to allow for individualmonitoring and tuning.

• SAP buffered table

If a multi-table tablespace (#SAP or XSAP) with less than 100 tables can be foundwith a matching database name (determined by data class, size category, bufferingattributes) and page size, it is used. Otherwise a new multi-table tablespace XSAP in adifferent database is created.

In both cases, default storage parameters are taken from tables TADB2 and TGDB2 ifthey are not hard-coded within the SAP system. For multi-table tablespaces the primaryand the secondary quantities obtained from table TGDB2 are multiplied by 100 and 20respectively.

Primary Indexes

Primary indexes are considered to be an integral part of a table. Therefore, they can onlybe created and dropped with the associated table. The default storage parameters of anindex are defined in tables IADB2 and IGDB2. Be aware that primary indexes are linkedto their base table with an additional:

ALTER TABLE ... ADD PRIMARY KEY (...)

Secondary Indexes

If the base table already exists, the primary and secondary quantities are calculated fromthe respective values of the table’s primary index or the table itself if there is no primaryindex. Otherwise, the default storage parameters are taken from tables IADB2 andIGDB2.



March 2002 6–3

Modifying Tables and Indexes

Tables

If the column definitions of a table have been changed, either by a transport or intransaction SE11, the SAP activation process analyzes the modifications andsubsequently decides how to act on the database table to achieve consistency betweenDDIC and DB. If a statement is feasible (for example, if a new table field needs to beadded or a VARCHAR field is extended) it is executed. (A check before activationindicates if ALTER TABLE will be used or not.) Otherwise, the SAP system performs thefollowing steps:

1. All non-partitioned indexes on the table are dropped.

2. All views on the table are dropped.

3. The original table is renamed by adding the prefix QCM (for example, TESTTABbecomes QCMTESTTAB).

4. A database and tablespace are provided.

5. The new DB table including its primary index are created according to the newDDIC definition of the table. A temporary table name is used to avoid that this tableis erroneously accessed during the conversion. This name consists of a prefix(QCM8) and the first twelve characters of the table name (for example,QCM8TESTTAB).

6. The contents of the original table are transferred to the new table (INSERT / SELECTadjusting types and formats).

7. The original table that has been renamed is dropped (including its database andtablespace if they become empty).

8. The newly created database table is renamed to its final name (QCM8TESTTAB →TESTTAB).

9. All secondary indexes are created.

This process is called table conversion.

Primary Indexes

Changes to the key definition of primary indexes are handled in the following way:

• Deleting a key field of a non-partitioned index

A table conversion is triggered. This is done to ensure the uniqueness of the newprimary index.

• Adding a key field of a non-partitioned index

DROP and re-CREATE of the primary index.

• Partitioned index

If the primary index is partitioned, every key modification (addition or deletion of akey field) triggers a table conversion.



6–4 March 2002

Secondary Indexes

Changes in the definition of secondary indexes are limited to adding or deleting a keyfield. Two cases have to be distinguished:

• Non-partitioned indexes

The modifications result in a DROP and subsequent re-CREATE of the index using thenew key definition.

• Partitioned indexes

Partitioned indexes cannot be dropped. The SAP system creates an additional non-partitioned index with the same index ID but a different separator (either "∼ " or "^").

From now on, the SAP system considers the original partitioned index to be anexternal index, which is not defined in the DDIC.

If the partitioned index is:- non-unique, no further action needs to be taken. The SAP system is able to

handle a partitioned index that is not defined in the DDIC.- unique, it puts a constraint on the table which is not known to the DDIC.

Therefore, you should partition the table anew using another index that is definedin the DDIC (see subsection "Move Table to Partitioned Tablespace").Alternatively, you can trigger a conversion using transaction SE14 and chooseEdit → Force conversion. The partitioned index is then recreated as a non-unique index with a new name: <TABLENAME>∼ #. (for example: TESTTAB∼ #)

Moving Tables

You can use tools available in the SAP system to move tables:

1. Call transaction SE14 and specify the table name.

2. Choose Edit.

3. Choose Goto → Storage parameter and proceed to the DB2 UDB for OS/390 andz/OS-specific part of transaction SE14.

4. Modify the storage parameters of the table and related objects (details on how to dothis are given below).

5. Choose Goto → Back and return to the database-independent part of transactionSE14.

6. Specify the Processing Type and choose Extras → Force conversion to trigger atable conversion.

Note

The SAP system provides tools to process many tables at a time, for example, tomove empty tables to multi-table tablespaces. For more information, see the section"Mass Processing".


March 2002 6–5

Rules for Self-Defined Objects

Caution

The SAP system is able to handle additional stogroups (not listed in tables TADB2 andIADB2) and self-defined databases and tablespaces that contain SAP tables. It is forexample possible to:

• Create a segmented or partitioned tablespace and move an SAP table to this newtablespace using DB2 means (SPUFI or an equivalent product) or transactionSE14.

• Combine a self-defined stogroup with a tablespace that contains SAP tables(using ALTER TABLESPACE and REORG)

However, you have to satisfy the following rules to guarantee full SAP functionality:

• The creator (also called schema) of all self-defined objects needs to be the onedefined during the installation process (usually this is SAPR3).

• When creating stogroups, use the following name ranges:

− SAPY* and SAPZ* if the creator is SAPR3

− <SAPSID>Y* and <SAPSID>Z* if the creator is not SAPR3 (for example, ABCYAD, ABCZ1D or ABCZ1I if the SAP system ID is ABC)

• For databases you should use the name ranges Y* and Z*.

• Use tablespace names different from #SAP or XSAP and create tablespaces indatabases named Y* or Z*.

• Use the CCSID ASCII option when creating tables.

• Always check the consistency of tables, views, and indexes that you worked onusing transaction SE14. Choose Extras → Database object → Check .

Note:

If you perform a homogeneous system copy using SAP tools (SAPinst, R3load,R3ldctl, R3szchk), self-defined DB2 stogroups, databases, and tablespaces are notmigrated to the target system. In that case, for all tables, tablespace and database, thenaming convention is applied as described in Appendix B, Database Layout.


Storage Parameters

6–6 March 2002

Storage Parameters

General Overview

Transaction SE14 provides means to modify and save storage parameters of tables,indexes, and tablespaces. To access the initial screen, choose one of the following:

• Call transaction SE14 and choose Edit → Storage parameter (for tables/tablespaces)or Edit → Indexes → Storage parameter (for indexes)

• Call transaction DB2 and choose Storage Mgt. Specify a table name or an index’sbase table and its index ID, and choose Edit.

In the following description, only the first access path is usually specified.

When the SAP system creates a new table and its database and tablespace, the storageparameters are taken from one of the following sources:

1. Saved parameters (abbreviated: SVD)

These are storage parameters that have been edited and saved using transactionSE14. The SAP system uses table DDSTORAGE as the storage medium.

2. Status in the DB2 database (abbreviated: DBS)

This parameter setting reflects the current situation on the database and is read fromsystem tables such as SYSIBM.SYSTABLES, SYSIBM.SYSTABLESPACE, orSYSIBM.SYSTABLEPART.

3. Default (abbreviated: CMP)

Some default parameters are defined in tables TADB2, TGDB2, IADB2, and IGDB2;others are hard-coded (for example, BUFFERPOOL or CCSID ASCII).

The SAP system applies the following logic. If saved parameters (source: SVD) areavailable, they are used. Otherwise, the system uses the current status on the database(source: DBS) to determine the storage parameters of the target DB2 objects, in particularthe tablespace. If the table does not exist, default values are taken. For indexes, thealgorithm is similar. Saved storage parameters are always preferred to the current statusin the database, which is preferred to the default values.


Storage Parameters

March 2002 6–7

Editing Storage Parameters

To edit storage parameters, call transaction SE14.

Displaying Table Attributes

To display table storage attributes:

1. Choose Edit → Storage parameter.

The initial screen displays important table parameters.− Name of tablespace and database− Estimated table size from RUNSTATS data (if the table exists and has been

analyzed by RUNSTATS)− Partitioned index and limitkey information if the table is partitioned

You can perform the following actions:− Collect limitkey data

(Choose Goto → Limitkey data).− Specify a new tablespace

(Choose Single-table, Partitioned, Multi-table, or Existing in edit mode).− Edit/display related DB2 objects

(Choose Goto → Tablespace / Indexes / Partitioning index / LOB objects).− Display background jobs that have been started within transaction SE14

(Choose Goto → Background jobs).

See the following subsections for more information.

2. To return to the initial screen of transaction SE14, choose Goto → Back .

If storage parameters have been edited, a dialog box asks whether your changesshould be saved.

Switching to Edit Mode

In edit mode, you can change storage parameters. You can switch to edit mode bychoosing Attributes → Display <-> Change.

Displaying/Editing Tablespace Parameters

To display or edit tablespace parameters:

1. Choose Goto → Tablespace .

2. Choose Goto → Back to return to the initial screen.

Displaying/Editing Index Parameters

To display or edit index parameters:

1. Choose Goto → Indexes .

A list of all indexes defined on the table is displayed.

2. Select Index and choose Goto → Index .

3. Choose Goto → Back .


Storage Parameters

6–8 March 2002


Steps 2 and 3 are omitted if the table has only one index.

You can also directly access the screen that displays index parameters:


2. Choose Edit.

3. Choose Indexes

4. Select the index.

5. Choose Continue.

4. Choose Goto → Storage parameter .

Displaying/Editing Partitioned Index Parameters

To display or edit partitioned index parameters:

1. Choose Goto → Partitioning Index .


Displaying/Editing LOB Objects

To display or edit database objects that are related to a LOB table field (LOB tablespacesor auxiliary tables and their indexes):

1. Choose Goto → LOBs.

A list of all LOB fields is displayed

2. Select one of the LOB fields (or LOB field partitions if the base table is partitioned).

3. Choose LOB tablespace or LOB index to display/edit storage attributes.

4. Choose Goto → Back.


Note

After editing storage parameters within transaction SE14, you have to perform thefollowing steps to adjust table, tablespace, database, and indexes in the database:

1. Choose Attributes → Save .

2. There are two ways to adjust the DB table using a table conversion.

a) Choose Attributes→ Adjust in database to start a background job.

b) Choose Goto → Back and Extras → Force conversion . Here, processingtype Direct means that online processing is also possible.

See the following sections for more information.


Storage Parameters

March 2002 6–9

Changing the Source of Storage Parameters

Storage parameters of tables and indexes can be retrieved from different sources:

Default Storage Parameters

Choose Source → Default .

Current Status in Database

Choose Source → Status in database.

If the table does not exist, default parameters are displayed (source: CMP). The systemalso displays a size estimate of the table (pagesize × number of pages determined byRUNSTATS), if RUNSTATS results are available.

Saved Storage Parameters

Choose Source → Saved .

If no parameters have been saved, the status on the database is displayed (source: DBS).

Special Actions

Triggering Table Conversions

1. On screen “DB2/390 Storage Attributes: Table” choose: Source → Saved .

The storage parameters that have been saved for this table are displayed. If no storedparameters are displayed, you cannot initiate a table conversion.

2. To trigger the table conversion, choose Attributes → Adjust in database.

3. Specify the start time and choose Save .

4. To monitor the conversion job, choose Goto → Background jobs .

Displaying Current Background jobs

Within transaction SE14 you can start the following background jobs:

• Table conversion (see last subsection)

Job name: DB-TABL[TABLE NAME]

• Collection of limitkey data (described below)

Job name: DB2-[TABLE NAME]>[INDEX ID]>[NUMPARTS]

Transaction SE14 provides a direct link to transaction SM37, which displays the statusand the logs of background jobs:

1. Choose Goto → Background jobs .


Displaying Object Logs

On screen DB2/390 Storage Attributes: Table or DB2/390 Storage Attributes: Index,choose Goto → Object log.

The most recent action log is displayed.


Storage Parameters

6–10 March 2002

Incremental Conversion

On screen DB2/390 Storage Attributes: Table, choose Goto → Incremental conversion.

For more details on how to employ this feature, see section “Incremental Conversion”below.

Directly Changing Storage Attributes

Some storage attributes of tablespaces and indexes can be changed directly in thedatabase without performing a table conversion, for example, primary or secondaryquantity or stogroup. The actions are slightly different for tablespaces and indexes.

Index


2. Choose Edit.

3. Choose Indexes..., specify index and choose Storage parameters.

4. Choose Attributes → Display <-> Change .

5. Modify index parameters.

6. Choose Attributes → Save; Attributes → Adjust in database .

Tablespace


2. Choose Edit and Storage parameters.

3. Choose Attributes → Display <-> Change; Goto → Tablespace .

4. Modify tablespace parameters.

5. Choose Goto → Back .

6. Choose Attributes → Save; Attributes → Adjust in database .

Note

For both indexes and tablespaces, the SAP system subsequently performs SQLstatements of the form ALTER INDEX or ALTER TABLESPACE. Note that for moststorage parameters you need to run the DB2 utility REORG in addition to adjust thedata in the database. LOB tablespaces and indexes of auxiliary tables cannot bealtered.

Moving Tables to Existing Tablespaces

To move a table to an already existing tablespace:

1. In edit mode, choose Existing .

The source is now REV (Revised/Not Saved).


Storage Parameters

March 2002 6–11

2. Specify the database’s and tablespace’s names.

3. Choose Attributes → Save to save the target tablespace.

4. To trigger the conversion, choose Attributes → Adjust in database .

Isolating and Combining Tables

The following actions work equally for tables in single-table, multi-table, and partitionedtablespaces.

A table should be moved to a single-table tablespace if it:

• Needs to be reorganized frequently

• Is accessed very often

• Becomes very large

• Grows rapidly in size.

Database performance would decline considerably if tables are kept in a multi-tabletablespace in these cases.

On the other hand, tables in a single-table tablespace, which are only small and rarelyaccessed may be moved to multi-table tablespaces to simplify database administration.

Moving a Table to a Single-Table Tablespace

1. In edit mode, choose Single-Table.

The source is now REV (Revised/Not Saved).

2. Edit tablespace and index storage parameters (optional).

3. Return to the initial screen.

4. Choose Attributes → Save to save the table parameters.


Moving a Table to a Multi-Table Tablespace

1. In edit mode, choose Multi-Table .

2. Edit tablespace and index storage parameters (optional).


4. Choose Attributes → Save to save the table parameters.



Storage Parameters

6–12 March 2002

Partitioning Tables

To partition a table:

1. Check whether the planned partitioning key is accessed by any UPDATE statementwithin the SAP system:

a) In transaction SE11 choose Utilities → Where-used list .b) Select Programs and continue.c) Search for the string "UPDATE" in the expanded where-used list.

If fields of the partitioning key are modified in a UPDATE statement, each call of thisstatement locks the complete table. Therefore, you should consider using a differentindex for partitioning.

2. Collect limitkey data. (This step is optional.)

3. Move table to partitioned tablespace.

Steps 2 and 3 are described in more detail below.

Collecting Limitkey Data

This transaction enables to collect limitkey data, which can be used to partition a table. Itperforms an ordered select on the key fields of the chosen index and thereby determines alimitkey setting, which splits the table into parts of equal size.

1. Choose: Goto → Limitkey Data .

The latest limitkey data is displayed, if available.

2. Enter Index ID and number of partitions.

3. Choose: Limitkey Data → Collect .

4. Choose Yes in the dialog box Start batch job to collect limitkey data?.

5. Specify start time and choose Save .

6. To monitor the background job, choose Goto → Background jobs .

Depending on the size of the table the runtime of the background job may range froma few minutes to several hours.


Displaying Limitkey Data

1. Choose: Goto → Limitkey Data .

The latest limitkey data is displayed, if available.

2. Enter Index ID and number of partitions.

3. Limitkey data is displayed, if available.



Storage Parameters

March 2002 6–13

Moving a Table to a Partitioned Tablespace

1. In edit mode, choose Partitioned .

If the table is already partitioned, move on to Step 5.

2. Dialog box: Use collected limitkey data?No: A dialog box appears that lists all indexes. Choose a partitioning index,move on to Step 5, and enter limitkey values manually.Yes: Continue to Step 3.

3. Display/collect limitkey data (see subsection "Collect Limitkey Data").

4. To return to the initial screen, choose Goto → Back .

Dialog box: Use current limitkey data for partitioning.

Yes: Current limitkey data is used to initialize storage parameters of partitionedindex.

No: Current limitkey data is not used.

5. Edit tablespace and index storage parameters. In particular, check the limitkeyspecifications.

Caution

No checks of the limitkey specifications are made in the SAP system. Therefore, youhave to make sure that your entries fit the DB2 requirements.

1. The constants are specified in ascending order. Be aware that only the first 40bytes are taken into account.

2. All values must correspond to the table’s column definitions (data type, length,precision).

3. For the last partition specify a high value. For example, ’’ or X’FF’.

For more information, see the IBM documentation SQL Reference.



8. To initiate the table conversion, choose Attributes → Adjust in database .


Storage Parameters

6–14 March 2002

Changing the Limitkey Specifications of a Partitioned Table

1. Call transaction SE14 and choose Indexes... and select the partitioning index.

2. Choose Storage parameters and enter the DB2 specific part of transaction SE14.

3. Choose Attributes → Display <-> Change .

4. Modify the limitkey specifications below column Values .


6. Choose Attributes → Adjust in database . The SAP system executes SQL statements of the form:

ALTER INDEX ... PART ... VALUES (...)

to adjust the limitkey specifications in the database.

7. Execute the DB2 utility REORG on the partitioned tablespace to adjust the table data according to the new limitkey specifications.

Changing the Number of Partitions

1. In edit mode, edit the number of partitions and the limitkey specifications.

2. Choose Attributes → Save.

3. To initiate the table conversion, choose Attributes → Adjust in database .

4. Execute the DB2 utility RUNSTATS on the partitioned tablespace.

Deleting Limitkey Data

1. Choose Goto → Limitkey Data .

2. Choose Limitkey Data → Delete .

3. Answer Yes in the dialog box Limitkey data will be deleted! Continue?.

Subsequently, all the table’s limitkey data that has been collected so far is deleted.


Storage Parameters

March 2002 6–15

Handling Large Tables

If a table needs to be partitioned or isolated, you should use DB2 utilities to move thedata if the table:

• Has more than 1 million entries

• Is larger than 100 MB

In these cases a standard and even an incremental conversion would take too much time.(Both procedures use SQL SELECT-INSERT to perform the data transfer.) Thereforeperform the following steps:

1. Determine the number of rows:

a) Enter the table name in transaction SE16 and choose Table → Table contents.

b) Choose Edit → Number of entries.

2. Create a quiesce point for the entire subsystem (for example, with -STOP DB2).Also, recommended are previous full image copies for all SAP data, to accelerate aRECOVERY if necessary.

Make sure that afterwards no write accesses to the subsystem are carried out apartfrom the actions described here.

3. In transaction SE14, choose Edit → Storage parameters to modify the table’s storageparameters (for details, see the preceding sections). Do not initiate a tableconversion!

4. Save the new storage parameters (choose Attributes → Save).

5. Copy the table’s contents to a sequential data set using DB2 utilities (for example,DSNTIAUL or REORG with option UNLOAD EXTERNAL).

6. Recreate the table (Activate and adjust database with option Delete data intransaction SE14). The SAP system uses the saved storage parameters when creatingdatabase, tablespace, table, and indexes.

7. Reload saved table contents into the newly created table (option: LOG NO).

8. As a first backup carry out a full image copy of the tablespace. This also cancels theCopy Pending status.

9. Check the number of entries using transaction SE16 (see Step 1).


Storage Parameters

6–16 March 2002

Mass Processing

The SAP system provides a DB2 UDB for OS/390 and z/OS-specific mass processingtool.

To access the tool, choose one of the following:

• Call transaction SA38 and execute program RSDB2MAS

• Call transaction DB2 and choose Storage Mgt → Mass processing.

The following input screen appears:


Storage Parameters

March 2002 6–17

The input values of RSDB2MAS fall into two categories:

• FilterHere you specify filter criteria:

− Maximum number of hits limits the number of tables selected for subsequentprocessing

− Within Table you can specify selection criteria for the table name

− The radio buttons Empty, Isolated in own tablespace, Buffered by R/3,Tablespace data set exists, and Index data set exists provide additional selectioncriteria (wild card “*”, Yes and No are possible options; if you choose “*” therelated selection criteria is not considered).

• Intended action

Within this area the intended action has to be chosen. For instance, if you want toisolate tables in a tablespace of their own, choose single-table tablespace.

You can also specify the usage of DEFINE YES/NO. This is a DB2/390 storageattribute, which allows users to create tablespaces or indexes with an option to deferthe physical creation of underlying VSAM data sets until the very first write (that is,SQL Insert or LOAD utility).

If you choose Reduce number of databases, the system recreates single-tabletablespaces in existing databases (up to 100 tablespaces in accordance to the namingconvention). This option is helpful if you plan to add SAP systems to an existinginstallation (MCOD installation) and need to overcome the limitations of the olddatabase layout (1:1 relationship between database and tablespace with a maximumnumber of 65279 databases per DB2/390 subsystem).

After specifying the input values, choose Program → Execute. Subsequently, the SAPsystem lists tables that meet the selection criteria specified within the input screen.

The five columns E, I, B, T, and X correspond to the input criteria Empty, Isolated in owntablespace, Buffered by R/3 and Tablespace data set exists, and Index data set exists.Entry X in one of these five columns means Yes.

The Status column lists the conversion progress, once a mass processing request has beenentered. Also, information is displayed on whether a table is partitioned or currentlyprocessed by ICNV. The following actions are possible:

• Function key F2: Displays a table’s storage attributes

• Schedule requests: Enters selected tables for mass processing with the intendedaction (here: recreation in tablespace of same type with storage parameter DEFINENO).

Note

Schedule requests triggers a standard table conversion with the Database Utility(transaction SE14). Therefore you have to make sure that the scheduled tables aresmaller than 50 MB and that they are not accessed by any other user during theconversion process. Otherwise, consider performing an Incremental Conversion(details below).


Storage Parameters

6–18 March 2002

The tool automatically activates all reports associated with the selected tables. Thisway, you do not have to get by with long-running compile processes afterwards.

• Delete requests: Delete selected tables from mass processing. This is only possiblefor tables whose conversion has not yet started.

• Add to ICNV: Add selected tables to the worklist of the Incremental Conversion(ICNV). For subsequent processing choose Goto → Incremental conversion or calltransaction ICNV. For details, refer to section “Incremental Conversion” below or tothe online documentation within transaction ICNV.

• Goto → Database log: The latest database log of the selected table is displayed.

• Goto → Database utility (or function key F2): Either the Database Utility(transaction SE14) or the Incremental Conversion (transaction ICNV) is accessed.

• Goto → General mass processing: Calls the mass processing screen withintransaction SE14.

• Goto → Incremental conversion: Calls transaction ICNV (Incremental Conversion).

• Goto → Log overview: Calls utility to display all logs.

• Goto → Background jobs: Displays background jobs related to RSDB2MAS.


Storage Parameters

March 2002 6–19

Troubleshooting

RSDB2MAS issues system log message D40 (RSDB2MAS: conversion of tablexxx cancelled) if the conversion of a table fails. In that case, call transaction SE14and choose DB requests → Terminated to analyze and resolve the problem.

Reducing the Number of Data Sets

RSDB2MAS is particularly useful if you want to reduce the number of VSAM data sets.The following procedure applies for empty tables isolated in their own tablespace.

1. Call transaction SA38 and execute report RSDB2MAS.

2. Specify:

Maximum number of hits 500

Table (empty)

Empty YES

Isolated in own tablespace YES

Buffered by R/3 *

Tablespace data exists YES

Index data set exists *

3. Choose:- Recreate in tablespace of same type- with DEFINE NO- and Reduce number of databases

4. The SAP system lists up to 500 empty tables with existing tablespace data sets.Select all tables and choose Schedule requests to enter them for mass processing.Subsequently, all selected tables are recreated using the storage attribute DEFINENO. The system accumulates up to 100 single-table tablespaces into one database.

5. Repeat steps 1 to 4 until the list of selected tables is empty.

For tables in multi-table tablespaces a different procedure should be applied:

1. Call transaction SA38 and execute report RSDB2MAS.

2. Specify:

Maximum number of hits 100000

Table (empty)

Empty YES

Isolated in own tablespace NO

Buffered by R/3 *

Tablespace data exists *

Index data set exists YES

3. Choose:

− Recreate in tablespace of same type

− with DEFINE NO


Storage Parameters

6–20 March 2002

4. The SAP system lists up to 500 empty tables located in multi-table tablespaces.Select all tables and choose Schedule requests to enter them for mass processing.Subsequently, all selected tables are recreated using the storage attribute DEFINENO. In most cases only the indexes are affected by the attribute DEFINE NO becausethese tables are recreated in existing tablespaces if possible.

5. Repeat steps 1 to 4 until the list of selected tables is empty.

Incremental Conversion

In contrast to the standard table conversion within transaction SE14 the incremental tableconversion (ICNV) permits that tables can still be used by the system throughout the datatransfer. As a result, there is much more time available for the data transfer and muchlarger sets of data can be converted. Operation in production mode is only disturbedbriefly when you initialize the conversion and when you switch to the new table. Thereare two ways to access this tool:

• On screen DB2/390 Storage Attributes: Table, choose Goto → Incrementalconversion.

• Call transaction ICNV.

Online documentation on how to perform an incremental conversion is provided withinthe initial screen of transaction ICNV (info button). The main steps are as follows:

1. Within transaction SE14 edit and save the table´s storage attributes.

2. Call transaction ICNV and choose Edit → Add table to add a table to the ICNV worklist.

3. Subsequently, perform the actions described in the online documentation (chooseShort description → Ad hoc).

Troubleshooting

If a table conversion fails, there is no data loss. During the conversion process theoriginal table is renamed (<TABNAME> → QCM<TABNAME>). The renamed table is onlydeleted after completing successfully all conversion steps.

The error processing should involve the following steps:

1. Analyze the problema) Call transaction SE14. On the initial screen the following message is displayed:

Request: "Adjust"b) Choose Analyze Adjustment to analyze the error.c) Check the ICLI.*.err file for SQL errors.

2. Continue adjustment

To continue the conversion, you must perform the following steps.a) Remove the cause of the problem.

In some cases, the storage parameters have to be adjusted (for instance limitkeyspecifications). This can be done by editing and resaving the storage parameters(source: SVD).


Storage Parameters

March 2002 6–21

Also, it is possible that a stogroup is full and additional volumes need to beadded. Then ALTER STOGROUP ... ADD VOLUME (...) enables acontinuation.

b) Select Processing Type in transaction SE14 and choose Continue adjustment.Subsequently, the table conversion continues.


Space Management

6–22 March 2002

Space Management

Adding Volume Space

Full Stogroup

If a stogroup becomes full, any transaction that writes data to tables associated with thatstogroup will fail and DB2 returns an appropriate SQLCODE. In that case, you need toadd additional volume(s) to the full stogroup by executing the SQL statements:

ALTER STOGROUP<FULL_STOGROUP> ADD VOLUMES(<VOLID_NEW1>,<VOLID_NEW2>,...)

You need to specify the volume IDs <VOLID_NEW1>, <VOLID_NEW2>, and so on, of thevolumes added.

Full Volume

You do not need to take immediate measures if a single volume becomes full without theassociated stogroups running out of space since the stogroups then use alternativevolumes.

As a precaution, you may add additional volumes to the respective stogroups by changingthe database layout as follows:

1. Find all stogroups pointing to the full volume. To do this, execute the SQL statement:

SELECT SGNAME FROM SYSIBM.SYSVOLUMES WHERE VOLID=<VOLID_OLD>

specifying the volume ID <VOLID_OLD> of the full volume.

2. Add additional volume(s) to all selected stogroups as described above in “FullStogroup”.


Space Management

March 2002 6–23

Handling the Number of VSAM Extents

If a tablespace reaches the maximum number of 255 VSAM extents (since OS/390 2.4),perform the following steps:

1. Increase the primary and secondary quantity using ALTER TABLESPACE. Oneoption is to change these quantities so that less than 20 will be used.

2. Apply the utility REORG TABLESPACE to the relevant tablespace.

See the IBM documentation DB2 for OS/390 Administration Guide for more information.

Note

Using the VSAM utility IDCAMS, you should regularly check that the number oftablespace extents remains well below the maximum of 255.

Data Compression

In many cases, using data compression can significantly reduce the amount of DASDspace necessary to store the data. Important points are listed below:

To enable data compression, specify COMPRESS YES on CREATE or ALTERTABLESPACE.

As the LOAD utility is not regularly used in the SAP system, you should run a REORGutility after each major tablespace population step such as R3Load or batch input. Thisreclaims the free space and restores clustering after a major data import.

Note

The data is not compressed until a compression dictionary is built, which is done bythe LOAD and REORG utilities only.

• Data compression advantages include:− Better DASD space utilization− Higher buffer pool hit ratios− Fewer I/Os− Fewer getpage operations

• Data compression disadvantages include:− Higher P-lock contention (data sharing only)− CPU overhead (in general)

• Define more freespace (PCTFREE and FREEPAGE) for the compressed tablespacesthat contain frequently updated tables. This will reduce page overflows and result inbetter performance and less frequent reorganizations.


Space Management

6–24 March 2002

Note

The freespace induced by data compression does not apply to the indexspacesbecause indexes are not compressed.

• Take extra care with the tables that have row lengths close to the page limit (4 KBand 32 KB). In most cases, the contents of these rows are random bit sequences thatdo not compress well and it is likely that even after compression not more than onerow will fit into a page.

• To check whether compressing a tablespace will bring benefits, you can runDSN1COMP on the tablespace.

• You can determine how effective data compression is by using compression reports(DSN1COMP before compression and a REORG report after compression) and catalogstatistics (PAGESAVE in SYSTABLEPART and PCTROWCOMP in SYSTABLES andSYSTABSTATS).

• As all the character data in the SAP database is defined with variable length, thebenefits of compressing the data might not be enough to justify the associated CPUoverheads.

For more information, see the DB2 for OS/390 V6 library.

SAP AG Transaction Codes

Contents

March 2002 A–1

Appendix A: Transaction Codes

Contents

Transaction Codes ....................................................................................................... A–2

Transaction Codes SAP AG

Transaction Codes

A–2 March 2002

Transaction CodesThe following table gives an overview of transaction codes that are useful in theadministration of the SAP system on DB2 UDB for OS/390 and z/OS.

Transaction Codes

Transaction Code Description

DB02 Tables and Indexes Monitor

DB03 Database Parameters

DB12 Backup Monitor

DB13 DBA Planning Calendar

DB13C Central DBA Planning Calendar

DB2 Central navigation tool

DB2B Buffer pool tuning

DB2C DB2 Catalog Browser

DB2D Deadlocks

DB2J JES Interface

DB2T Timeouts

DB2U Long-running units of recovery

DB2X Check availability of DB2/390 utilities

OS06 saposcol

OS07 saposcol

RZ20 Alert Monitor

S001 ABAP Workbench

SA38 ABAP Program Execution

SE11 ABAP Dictionary

SE14 Database Utility

SE16 Data Browser

SE17 General Table Display

SE30 ABAP Runtime Analysis (SQL statement compare)

SE38 ABAP Editor

SE80 Repository Browser

SE84 Repository Information System

SM04 Current users on current server

SAP AG Transaction Codes

Transaction Codes

March 2002 A–3

SM13 Update Records

SM21 System Log: Local Analysis

SM31 Table Maintenance

SM37 Background job list

SM39 Background Job Information

SM50 Work Process Overview

SM51 Server Overview

SM59 RFC Destinations

SMGW Gateway Monitor

SPO1 Spooler

ST02 Tuning Summary

ST03N Workload Analysis

ST04 Database Performance Monitor

ST05 Trace Requests

ST06 Operating System Overview

ST08 Network Monitoring

ST10 Table Call Statistics

ST11 Trace Logs

ST22 ABAP Dump Analysis

STUN Remote Database Monitoring

SU01 User Maintenance

SU50 View/set user defaults

SU53 Unauthorized transactions

SAP AG Database Layout

Contents

March 2002 B–1

Appendix B: Database Layout

Contents

General Overview ......................................................................................................... B–2Requirements .............................................................................................................B–2SAP Technical Settings ..............................................................................................B–3Basic Concept.............................................................................................................B–5

Mapping Between the ABAP Dictionary and DB2 ..................................................... B–6DB2 Objects ...............................................................................................................B–6Examples..................................................................................................................B–11Compatibility .............................................................................................................B–13

Database Layout SAP AG

General Overview

B–2 March 2002

General Overview

Requirements

The SAP system requires that the structure and the names of transparent tables and viewsare identical in the ABAP Dictionary (DDIC) and in the DB2 database (DB). Also, indexkey definitions must be the same in both. The names of DB indexes have to be formed byconcatenating the table name, a separator (either "^" or "∼ "), and the SAP index name.

There are no other specific SAP-specific requirements on how to name or organize theassociated DB2 objects tablespace, database, and stogroup. In principle, all tables couldbe created with implicit tablespaces in the default database DSNDB04 using stogroupSYSDEFLT. However, this would have a negative impact on performance and databaseadministration.

Additional requirements have to be taken into consideration.

• General requirements− High-end performance− Efficient monitoring and administration− Unlimited use of DB2 code pages

• DB2 for OS/390 requirements− Not more than 100 tables per database

(considered optimal in terms of performance and operation)− Efficient application of DB2 utilities, such as RUNSTATS, REORG, and COPY− Flexible and simple naming convention that is non-destructive to customer

modifications

• OS/390 requirements

If the Storage Management Subsystem (SMS) manages the extensions of DB2 datasets the following requirements are important:− To support SMS the OS/390 data set names of tablespaces and indexspaces

[VCAT].DSNDBD.[DATABASE].[TABLESPACE].[SUFFIX][VCAT].DSNDBD.[DATABASE].[INDEXSPACE].[SUFFIX]

should be used as carriers of storage-relevant SAP system information. See thesubsection "SAP Technical Settings" for more information.

− If the SAP system needs to move a table to a newly created tablespace, the newdatabase and tablespace names should be such that there is no need to changedata set qualifiers in the ACS routines.

The above requirements lead to the database layout described in this appendix.


General Overview

March 2002 B–3

SAP Technical Settings

The SAP technical settings of a table allow you to categorize the table according to itsspace requirements (usage/growth), I/O rates, and so on. You can specify the followingtechnical attributes using transactions SE13 or SE11:

• Data class (TABART)

The data class is a table’s attribute that describes the use of a table. For example, itallows you to differentiate between a table with master data and a table withtransactional data. Each data class has an associated 2-character ID (Storage ID) thatis used internally by the SAP system to construct the names of DB2 databases.The data class is also directly mapped to DB2 stogroups.

Table 1 lists available data classes and the corresponding storage IDs and DB2stogroups.

• Size category (TABSIZE)

The size category (between 0 and 4) describes the estimated space requirements of atable. A higher number identifies a larger table.

• Buffering

SAP’s table buffering is one of the most important performance tuning mechanisms.Under certain circumstances tables are stored locally on each application server. Thetime consuming process of repeatedly accessing the database is thus avoided. Thefollowing types of buffering are possible:- Full buffering

In case of read access, the entire table is loaded into the SAP buffer.- Generic buffering

The generic key is defined as a part of the primary key. During the access of arecord from a table that is generically buffered, all records whose generic keyfields correspond to this record are loaded on the application server.

- Single-record bufferingOnly those records actually being accessed are loaded on the application server.

Note

There is no relation at all between buffering in SAP’s buffering on the applicationserver and DB2’s buffering using buffer pools.


General Overview

B–4 March 2002

Data Classes (schema SAPR3)Data class(TABART)

StorageID

Datastogroup

Indexstogroup

Description

Customer APPL0 A0 SAPSTD SAPSTI Master data, transparent tables

data APPL1 A1 SAPBTD SAPBTI Transaction data, transparent tables

APPL2 A2 SAPPOD SAPPOI Organization and Customizing

USER U0 SAPU1D SAPU1I User tables

USER1 U1 SAPU1D SAPU1I User tables

System CLUST CL SAPCLD SAPCLI Cluster tables (not visible to the user)

data POOL PO SAPPOD SAPPOI Pooled tables (not visible to the user)

SDIC DI SAPDID SAPDII ABAP Dictionary tables

SDOCU DO SAPDOD SAPDOI Documentation

SLOAD LO SAPLOD SAPLOI Screen and report load programs

SPROT PR SAPPRD SAPPRI Spool and logs

SLDEF LD SAPELD SAPELI Repository switch

SLEXC LX SAPELD SAPELI Repository switch

SSDEF SD SAPESD SAPESI Repository switch

SSEXC SX SAPESD SAPESI Repository switch

SSRC SO SAPSOD SAPSOI Source for screens and reports

TEMP TM SAPPRD SAPPRI Temporary tables


General Overview

March 2002 B–5

Basic Concept

The mapping between tables defined in the ABAP Dictionary and DB2 tables (plusrelated objects: tablespace, database, and stogroup) is governed by the following basicrules that are applied during SAP system installation and runtime:

• A table that is not SAP buffered at creation time is placed into a dedicated, single-table tablespace.

• A table that is SAP buffered at the time of creation is placed into an existing or a newmulti-table tablespace, which will hold a maximum of 100 tables.

• For each multi-table tablespace there is only one database and vice versa.In contrast to earlier releases, one database holds now up to 100 single-tabletablespaces. This is to reduce the number of databases needed for the SAP systemand to allow a larger number of SAP systems in an MCOD (multi-component ondatabase) installation.

• A table and its indexes belong to the two separate DB2 storage groups thatcorrespond to the table’s data class (TABART).

See the following section for information on the naming and the storage parameters ofDB2 objects.


Mapping Between the ABAP Dictionary and DB2

B–6 March 2002

Mapping Between the ABAP Dictionary and DB2The naming convention described in the following is illustrated for an exemplary list oftables and related DB2 objects in the subsection "Examples". See the graphic "Structureof Database Layout" and the table "Naming Convention (Examples)".

DB2 Objects

Stogroups

In this documentation, the term stogroup is used to refer to a DB2 storage group. Thisavoids any confusion that could arise due to using the same term, storage group, in tworelated products, DB2 and Data Facility Storage Management Subsystem (DFSMS).

A DB2 stogroup identifies a list of DASD volumes that hold data stored in DB2tablespaces and indexspaces. For a given stogroup the corresponding volume names areeither stored in the DB2 catalog or associated to the stogroup by means of DFSMS ACSroutines.

There is a fixed number of stogroups defined for an SAP system. They are closely relatedto the data class (TABART). The relation is static and specified in the SAP tables TADB2and IADB2. Two cases have to be distinguished:

• If the creator/schema associated with the SAP system is SAPR3 the stogroup entriesin table TADB2 and TGDB2 are used without any change.

• Otherwise, the first 3 characters SAP of the stogroup entries in tables TADB2 andTGDB2 are substituted by the SAP system ID<SAPSID> when generating a CREATETABLESPACE or CREATE INDEX statement. For instance, if the <SAPSID> is ABCsome of the stogroups used are ABCBTD, ABCCLI, or ABCU1D.

All DB2 stogroups used by an SAP system are associated with the same IntegratedCatalog Facility Catalog (parameter VCAT within CREATE STOGROUP statement).

During runtime no additional stogroups are created. One or more data classes areassigned to a pair of stogroups. One is designated for tables (suffix "D" for data), and onefor indexes (suffix "I"). This allows you to assign separate sets of volumes for data andindexes to avoid DASD contention. See the "Data Classes" table for a complete list ofthe DB2 stogroups used by the SAP system.

The naming convention can be used in your ACS routines if you use SMS-managed datasets. In that case, SAP and IBM recommend that you add the stogroup’s own name to itslist of volumes using:

ALTER STOGROUP <STOGRP> ADD VOLUME (<STOGRP>)

This is possible because DB2 does not check the existence of the volumes in theVOLUMES clause. That way you pass the stogroup name to the ACS routine, whicheffectively means passing the information on whether the subject data set is going tostore data or indexes.



March 2002 B–7

Databases

In the environment of an SAP system installation, DB2 database is an object thatconsists of a DB2 tablespace and all the indexes on the tables contained in thetablespace. Specifically, for a single-table tablespace, the database includes one table andall its indexes.

There are only a few DB2 commands for database control: DISPLAY DATABASE, STOPDATABASE, START DATABASE. The real value of this DB2 object in the SAP systemenvironment is in its name; it carries all the technical settings of the contained tables. Fora given table the associated database name is constructed as follows:

[STORAGEID][TABSIZE][BUFFER]X[ABC]

where the parameters have the following meaning:

Parameter Meaning

[STORAGEID] SAP data class identified by 2 characters A0, A1, A2, and soon. The unique relation between data class and storage ID isdefined in the SAP table TADB2 and described in the "DataClasses" table.

[TABSIZE] SAP size category (1 digit: 0,1,2,3,4) [BUFFER] Actual buffering on the application server at creation time (1

digit): - 0 = no buffering - 1 = full buffering - 2 = generic buffering - 3 = single-record buffering

X Placeholder for future developments (earlier releases use ‘# ’as a placeholder)

[ABC] 3 random characters ([A-Z][0-9])

With the naming convention in mind you can determine a table’s technical settings bylooking at the appropriate DB2 catalog table (SYSIBM.SYSTABLES), or, moreimportantly, at the underlying data set name (remember that the database name is aconstituent part of the underlying data set name). That allows you to control the physicalplacement of tables and indexes, for example, by passing the technical setting details toan ACS routine.



B–8 March 2002

Tablespaces

DB2 tablespace is a common name for one or more data sets used to store a single ormultiple tables. In an SAP system installation, SAP’s type of buffering on the applicationserver is the only criterion for deciding whether a tablespace stores a single or multipletables. If a given table is not SAP buffered at creation time, it is stored in a dedicatedtablespace that does not contain any other table. Otherwise, the table is put in multi-tabletablespace.

The reasons for this division are as follows:

• In principle, all tables that are not buffered on the application server are likely to beaccessed frequently via INSERT and UPDATE. Each of them is a possible candidatefor tuning efforts. However, efficient DB2 monitoring and tuning requires that thetable is isolated in its own tablespace. Since isolating a large table means down-timeand considerable administrative effort, SAP and IBM decided to deliver all non-buffered tables in single-table tablespaces.

• If a table is buffered on the application server, there are only rare DB read accesses.Furthermore, inserts and updates are rather unlikely. They are combined in multi-table tablespaces because DB2 monitoring and tuning of these tables is either lessimportant or of no use.

A multi-table tablespace holds up to 100 tables. The name "XSAP" is assigned to this typeof tablespace ( up to SAP R/3 Release 4.5B the default name "#SAP" was used.) For asingle-table tablespace, the system determines the tablespace name by taking the firstseven characters of the associated table name. Naming space qualifiers "/.../" areignored (naming qualifiers are used by SAP and partner companies for add-on products).The character "_" is replaced by "X".

The database and tablespace name of a table in a single-table tablespace are only slightlymodified if the table needs to be converted due to structural changes, for example, duringan upgrade. In that case, the character "X" is appended to the tablespace name. Therefore,if you use the qualifier

[VCAT].DSNDBD.[DATABASE].[TABLESPACE]*.[SUFFIX]

in your ACS routines, there is no need to adjust these routines after a table conversion.

Example

DSN00X.DSNDBD.U140XPOI.OURTAB*.I0001.A001

for table /IBM/OURTAB listed in the "Naming Convention (Examples)" table uniquelyfinds the two alternatives:

DSN00X.DSNDBD.U140XPOI.OURTAB.I0001.A001

DSN00X.DSNDBD.U140XPOI.OURTABX.I0001.A001



March 2002 B–9

Both multi- and single-table tablespaces are initially defined using the default storageparameters:

• LOCKSIZE ROW

• LOCKMAX 1000000

• CCSID ASCII

The following parameters depend on the table’s page size:

Page Sizes and Their Parameters

Page Size BUFFERPOOL PCTFREE FREEPAGE

4 KB BP2 20 16

8 KB BP8K0 10 31

16 KB BP16K0 5 31

32 KB BP32K 5 0

The parameter SEGSIZE is calculated from the table’s size catagory:

SEGSIZE = 8 × TABKAT + 4

For more information, see the subsection "SAP Technical Settings".

Other default parameters, such as primary and secondary quantity, or stogroups arespecified in the SAP system tables TADB2 and TGDB2. For multi-table tablespaces theprimary and secondary quantities in table TGDB2 are multiplied by 100 and 20respectively to meet larger space requirements.

Note

The default primary quantity for tablespaces is always at least equal toPAGESIZE × ( 2 × SEGSIZE + 2 )to make sure that an empty tablespace allocates only the first extent.

Indexspaces

Each DB2 index occupies its own DB2 indexspace placed in the DB2 database thatcontains the base table of the index. Default values for stogroups or primary andsecondary quantities are defined in table IGDB2. Other parameters are initially defined asfollows:

• BUFFERPOOL BP3

• PCTFREE 10

• FREEPAGE 10



B–10 March 2002

LOB Objects

From SAP Web AS Release 6.10 and higher, table columns that have the DB2 data typesCLOB and BLOB are used within an SAP system. If a LOB column is added to a table or atable with a LOB column is created, the ABAP Dictionary automatically generates anadditional table column named #ROW with type ROWID GENERATED ALWAYS.Furthermore, the following database objects are created for each LOB column andpartition:

• The LOB tablespace is created in the base table’s database with the following name: L[TABNAME5][LK]With:

− [TABNAME5] = first 5 characters of the table’s name− [LK] = 2 random characters ([A-Z] [0-9])The default storage attributes are as follows:− STOGROUP = table’s default data stogroup− PRIQTY 200 SECQTY 10240 GBPCACHE SYSTEM− BUFFERPOOL BP40 LOG YES LOCKMAX 0 LOCKSIZE LOB

• For the auxiliary table the following naming convention is applied:#[COLNAME14][MNO]With:

− [COLNAME14] = first 14 characters of the column’s name− [MNO] = 3 random characters ([A-Z][0-9])

• The index on auxiliary table is created with the same name as the auxiliary tableusing the following storage parameters:

− STOGROUP = table’s default index stogroup− PRIQTY 16 SECQTY 10240 FREEPAGE 10 PCTFREE 10 GBPCACHE CHANGED

− BUFFERPOOL BP40 PIECESIZE 2097152 K

For example, if the non-partioned table LOBTSTTAB has a LOB column namedTESTLOBCOL, the naming of the related LOB objects could be as follows:

• LOB tablespace LLOBTS5A

• Auxiliary table #TESTLOBCOL8ZH with index #TESTLOBCOL8ZH

Creator / Schema

Caution

The creator of each DB2 object belonging to an SAP system needs to be the same.The creator ( or schema) has to be specified during the installation of a system(default is SAPR3).Therefore, you need to initiate any DDL statement that deals with SAP objects and issubmitted directly on the database (for example, using SPUFI) with:

SET CURRENT SQLID = ’<SCHEMA>’;

Always use the CCSID ASCII option when creating tables.



March 2002 B–11

Examples

The following table and graphic illustrate the naming conventions outlined above forsome exemplary tables.

Note

XTAB represents the example of a table that has been converted at least once aftercreation. Therefore, the related tablespace’s name contains the suffix "X".

Naming Convention (Examples)

Table DataClass

Size Buffered onapplicationserver?

Database Tablespace Stogroups

MYTABLE USER1 0 0 (no) U100X3HJ MYTABLE SAPU1DSAPU1I

TABLE_1 USER1 0 0 (no) U100X3HJ TABLEX1 SAPU1DSAPU1I

OURTABL APPL0 4 2 (generic) A042XKJH XSAP SAPATDSAPATI

XTAB APPL2 4 0 (no) A240XF23 XTABX SAPPODSAPPOI

YTAB APPL2 2 3 (single) A223XFGH XSAP SAPPODSAPPOI

TADIR SDIC 3 1 (fully) DI31X23J XSAP SAPDIDSAPDII

/IBM/OURTAB USER1 4 0 (no) U140XPOI OURTAB SAPU1DSAPU1I

Table(continued)

Data Set Names (Catalog Name DSN00X)

MYTABLE DSN00X.DSNDBD.U100X3HJ.MYTABLE.I0001.A001

TABLE_1 DSN00X.DSNDBD.U100X3HJ.TABLEX1.I0001.A001



B–12 March 2002

OURTABLE DSN00X.DSNDBD.A042XKJH.XSAP.I0001.A001

XTAB DSN00X.DSNDBD.A240XF23.XTABX.I0001.A001

YTAB DSN00X.DSNDBD.A223XFGH.XSAP.I0001.A001

TADIR DSN00X.DSNDBD.DI31X23J.XSAP.I0001.A001

/IBM/OURTAB DSN00X.DSNDBD.U140XPOI.OURTAB.I0001.A001

Structure of Database Layout

tablespace

database

table/index

storage ID

stogroup

volume

A240XF23

XTABX

A2

APPL2data class SDIC

DI

A223XFGH

XSAP

DI31X23J

XSAP

SAPPOD SAPPOI SAPDID SAPDII



March 2002 B–13

Compatibility

Upgraded Systems

The database layout described here differs considerably from the layout implemented forSAP R/3 releases earlier than 4.5A. If your system is upgraded to SAP R/3 Release 4.5Aor higher, the new layout is only applied to:

• New tables

• Existing tables in multi-table tablespaces that need to be recreated due to structuralchanges

If an already isolated table and its tablespace have to be recreated, it is kept isolated evenif the table is SAP buffered or the tablespace and database name are different from thecurrent naming convention. All storage parameters of the original tablespace are reused.The new database and tablespace names are formed by adding or substituting "X" as thelast character. Thus, all administrative efforts (extending primary and secondaryquantities, compressing, tuning, and so on) are preserved.

Name Range Occupied by SAP Systems

If there are various applications running in the same DB2 subsystem, it is important toknow the name range occupied by an SAP system:

• Creator

The creator of all DB2 objects created and used by the SAP system is the same.

• Stogroups

In CREATE TABLESPACE and CREATE INDEX statements, the SAP system only usesstogroups that are listed in tables TADB2 and IADB2.

When changing storage parameters of tablespaces in transaction SE14 you may alsoemploy self-defined stogroups.

• Databases

The first two characters of a new database name are always taken from columnSTORAGEID in table TADB2. Tables and indexes are placed exclusively intodatabases and tablespaces that were created by the SAP systems dedicated creator.

Customers can add new data classes, storage IDs, and stogroups to the SAP tables TADB2and IADB2. For details, see SAP Notes 46272 and 163449 and Chapter 4, “Rules forSelf-Defined Objects”.



B–14 March 2002

Storage Parameter Define No

The installation and upgrade processes create tablespaces and indexes with optionDEFINE NO. That means that the underlying data sets are not created until the first row isinserted into the corresponding table. For most SAP system installations sites a largenumber of tables remain empty, which means that a significant number of data sets willnot be created. This is beneficial for many database administration tasks as well as forthe DASD space utilization.

After installation or upgrade, the DB2 for OS/390-specific mass processing toolRSDB2MAS allows you to recreate tablespaces and indexes with storage option DEFINENO. For more information, see Chapter 4, section “Mass Processing”.

Caution

The objects created with DEFINE NO are fully supported by all the functions withinthe SAP system.

Potential problems may arise if you use third party tools that do no have support forthe new kind of objects. Check with your tool provider if the tools implement thenecessary support.

SAP AG Environment Variables

Contents

March 2002 C–1

Appendix C: Environment Variables

Contents

Environment Variables................................................................................................. C–2

Environment Variables SAP AG

Environment Variables

C–2 March 2002

Environment VariablesThe following table lists important environment variables needed in an SAP system onDB2 UDB for OS/390 and z/OS.

For additional information, call transaction RZ11, specify the profile parameter andchoose Display.


Environment Variable Profile Parameter Description

SAPSYSTEM SAPSYSTEMNAME SAP system name

SAPDBHOST SAPDBHOST TCP/IP address ofdatabase host

DIR_LIBRARY DIR_LIBRARY Full path name ofDatabase Interfaceshared library

dbms_type dbms/type Specifies databasetype (for example,DB2)

DBS_DB2_SSID dbs/db2/ssid Database AttachName used by theICLI server to attachto the DB2subsystem

R3_PORT db2/db2/icli_port ICLI connection port(used by Upgradeonly!)

dbs_db2_schema dbs/db2/schema Owner of databaseobjects for thiscomponent

SQL_TRACE dbs/db2/sql_trace Switch for SQL trace

dbs_db2_con_profile dbs/db2/con_profile Connection profilefor DB2/390

RSDB_ICLILIBRARY rsdb/icli_library Full path name ofICLI client sharedlibrary (not forapplication server onz/OS)

ICLI_TRUSTED_CONNECTIONS dbs/db2/icli_trusted_connections

Specifies the use of asecure connection(not for applicationserver on z/OS)

SAP AG Environment Variables


March 2002 C–3

STEPLIB − STEPLIB (used onlyby application serveron z/OS)

DBS_DB2_PLANNAME dbs/db2/planname Plan name fordynamic SAPdatabase interface(only for applicationserver on z/OS)

DBS_DB2_HOSTTCP dbs/db2/hosttcp FTP host

RSDB_RECO_SYNC_ALL_SERVER rsdb/reco_sync_all_server Activatessynchronization ofall applicationservers duringdatabase reconnect

SQL_TRACE dbs/db2/sql_trace Sets SQL trace

ICLI_CLIENT_TRACE dbs/db2/icli_client_trace Sets ICLI client trace(not for applicationserver on z/OS)

RSDB_DB2PSLIBRARY rsdb/db2ps_library Performance ServiceLibrary (only forapplication server onz/OS)

RDISP_NOPTIME rdisp/noptime Sets noptimeparameters (fordetails, see thedocumentation intransaction RZ11)

DBS_DB2_SINGLE_TABSPACE dbs/db2/single_tabspace Enforce one-to-onerelation betweendatabase andtablespace, if set to 1

Environment Variables SAP AG


C–4 March 2002

Environment Variables (for Standby System)

Environment Variable Profile Parameter Description

RSDB_DB2HOSTSTANDBY rsdb/db2_host_standby Database host

DBS_DB2_SSID_STANDBY dbs/db2/ssid_standby Database AttachName

DBS_DB2_PLANNAME_STANDBY dbs/db2/planname_standby Plan name (only forapplication server onOS/390)

RSDB_DB2PORTSTANDBY rsdb/db2_port_standby ICLI connectionsport

DBS_DB2_HOSTTCP_STANDBY dbs/db2/hosttcp_standby FTP host

SAP AG SAP on DB2 UDB for OS/390 and z/OS: Database Administration Guide

Index

March 2002 Index-1

Index

AAdding

volume space, 6–22Authorization profiles, 2–14

BBacking up

offline, 5–6online, 5–5

Background processingSAP System, 2–25

CCCMS

backup monitor, 5–10 SAP and DB2 for OS/390 and z/OS, 4–1Central Planning Calendar, 5-39Changing database layout

partitioning tables, 6–15separating a table, 6–6

CommandsDB2 for OS/390 and z/OS, 4–29

Compressionof data, 6–23

Creatorof DB2 objects, B–10

DData compression, 6–23Database administration

DBA Planning Calendar, 5–27Database layout

changing, 6–2creator of DB2 objects, B–10

DB2 UDB for z/OScommands, 4–29

DB2 subsystemmaintaining, 2–2

DB2 System Catalog, 4–27DB Alert Router, 4-23DB Performance Monitor, 4-14Displaying

z/OS system log, 4–28

EEXPLAIN

plan table, 4–39

HHandling

number of VSAM extents, 6–23

IICLI Diagnostics, 4-42Incremental Conversion, 6-20Indexes

monitoring, 4–43Installation parameters monitoring, 4–22Interface JES interface, 5-21

MMaintaining

DB2 subsystem, 2–2Mass Processing, 6-16MCOD, 2-27; 4-10; 4-31; 4-45; 4-60Monitoring

installation parameters, 4–22performance, 4–3; 5–27SAP and DB2 for OS/390 and z/OS, 4–1statement cache statistics, 4–20tables/indexes, 4–43thread activity, 4–19

NNumber of VSAM extents

handling, 6–23

OOS/390 and z/OS system log

displaying, 4–28

PPartitioning tables

SAP on DB2 UDB for OS/390 and z/OS: Database Administration Guide SAP AG

Index

Index-2 March 2002

changing database layout, 6–15Performance

monitoring, 4–3; 5–27Performance monitor

installation parameters, 4–22statement cache statistics, 4–20thread activity, 4–19

Performance monitor:, 4–18Plan table

EXPLAIN, 4–39Planning Calendar

database administration, 5–27Printing SAP System, 2–25PTF Check, 2-15

RRFCOSCOL Installation, 4-3 Configuration, 4-4 Starting, 4-11 Stopping, 4-12SAP system

background processing, 2–25printing, 2–25stopping /restarting, 2–2

Recovering, 5–14to a prior point in time, 5–14to the current state, 5–14

RestartingSAP system, 2–2

RUNSTATSupdating statistics, 5–34

SSAPOSCOL, 4-64Separating a table

database layout, 6–6Space management

volume space, 6–22Statement cache statistics

monitoring, 4–20Stogroup

full stogroup, 6–22Stopping

SAP system, 2–2

TTables

creating, 6–2monitoring, 4–43partitioning, 6–15separating, 6–6

Terminologydatabase administration guide, 1–5; 3–10; C–4

Thread activitymonitoring, 4–19

Transaction codes, A–1

UUpdating statistics

RUNSTATS, 5–34

VVolume

full volume, 6–22Volume space

adding, 6–22full stogroup, 6–22full volume, 6–22management, 6–22

VSAM extentshandling the number of VSAM extents, 6–23

OS_DBA

Documents

sap earlywatch

sap businessworkflow

sap archivelink

walldorf sap

cominstguidessap ag

sap ag neurottstr

express permission of

sap service marketplaceyou