DB2 Admin for SAP With ddbddExercises 20120810

11 2012 IBM Corporation

DB2 LUW 10.1 Administration for SAP

IBM Information Management Technology Ecosystem


DB2 LUW 10.1 Administration for SAP Chapters

1 Basics

DB2 LUW 10.1 Administration for SAP

2 Storage Management

3 Table and Index Maintenance

4 Log File Management

5 Database Backups

6 Recovery

7 Performance Monitoring and Tuning

8 Problem Analysis

9 Infrastructure Options


DB2 for LUW Optimized for SAP

Good Reasons for DB2

Partnership Joint SAP/IBM teams work together on all levels of the product

(development + testing, maintenance, support) Excellent collaboration between Walldorf and Toronto

Product Integration One product, one maintenance strategy, one-stop service All SAP relevant DB features are part of the SAP OEM license

Technology Innovation Joint technology roadmap Synchronized release cycles between IBM and SAP

SAP runs DB2 SAP IT is a very satisfied DB2 customer (more than 1200 systems) Biggest SAP business systems are running on DB2 for LUW

Joint development is a unique benefit of using DB2. Every database has a certain level of joint development with SAP. However, the development teams for DB2 and SAP are far more integrated than for other databases. This starts with development planning. DB2 developers are able to code into DB2, new features that are designed for future SAP functionality. As well, the development teams in the Toronto DB2 Software Lab and the Walldorf SAP Development Lab sit and work together in the same office space. The Toronto ISIS (IBM SAP Integration and Support) team is a jointly staffed team of IBM and SAP employees which sit amongst the DB2 developers. The SAP employees on that team have direct access to all of the DB2 source code, and are involved in the development and testing of DB2 internal code.

Throughout the DB2 development process, the lead architects have regular meetings to discuss product changes and feature development. The SAP architects review and approve the DB2 external APIs for all features that SAP plans to leverage. If SAP does not approve the external API, DB2 developers must implement changes to gain approval. This ensures that the new features of DB2 meet the requirements of SAP right from the start, and that these new features can be leveraged and used immediately in new SAP applications.

DB2 SAP customers also benefit from a more tightly integrated support model. SAP Active Global Support is always the first point of contact for an SAP customer, regardless of which database is being used. However, the SAP support organization partners much more closely with DB2 than with other database vendors. Active Global Support issues related to DB2 are routed to one of the two development labs, in Walldorf or Toronto. These support teams are jointly staffed with both DB2 and SAP employees within the SAP and IBM Development Labs. If a call is received by the ISIS team in Toronto, this team can sit with theDB2 developer who wrote the code in question, teleconference with the customer, and together analyze the problem with the DB2 source code in front of them on the computer screen. This level of SAP support and service is unique to DB2.


1 Basics Contents

DB2 Products & Versions

Basics

DB2 Essentials

DB2 Connect & Security

DB2 EDUs, Starting & Stopping

DB2 Configuration

DB2 Memory Management


Basics

At the end of this unit, you will be able to: Understand relationships and apply knowledge

about important definitions in DB2 Describe the DB2 processes and threads Describe DB2 directories and naming conventions Explain the user and security management Set and monitor the DB2 environment Understand the DB2 memory management

Objectives


1 Basics Contents


Basics

DB2 Essentials



DB2 Configuration



DB2 Products / Packages

DB2 for LUW Product Family

DB2 Everyplace(embedded in mobile solutions)

DB2 Express-C(free of charge)

DB2 Express Edition DB2 Workgroup Server Edition DB2 Enterprise Server Edition

(optional with DPF feature)

Used with SAP systems

IBM-Supported Platforms

IBM AIX on IBM Power Systems

HP-UX on IA-64 (and PA-RISC with DB2 V9.1 and earlier)

Solaris on UltraSPARC and x86-64

Linux on x86, x86-64 (and IA-64 with DB2 V9.1 and earlier)

Windows on x86, x86-64 (and IA-64 with DB2 V9.1 and earlier)

For-SAP supported combinations of hardware, OS, DB2 version, and SAP product version: See Product Availability Matrix (PAM) at

http://service.sap.com/pam

SAP does not support all potential combinations of DB2 software versions, hardware platforms, operating system and SAP product versions. For up-to-date availability information, see SAP Product Availability Matrix at http://service.sap.com/pam and platform information at http://service.sap.com/platforms .

DB2 Enterprise Server Edition (ESE) contains single-database-partition and multiple-database-partition features (Database Partitioning Feature = DPF).

Customers who purchased an IBM DB2 for LUW Advanced Enterprise Server Edition (AESE) from IBM and want to use it for SAP applications (based on SAP NetWeaver), should proceed as described in SAP Note 1598914.

SAP requires that you only use the database partitioning feature for systems with SAP BW technology as described in SAP Note 702175.

IBM provides a free version of DB2 Express Edition called DB2 Express-C. DB2 Express-C is designed to be used by partners and development communities for test, evaluation, and training purposes. DB2 Express-C can be run on up to 2 dual-core CPU servers, with up to 4 GB of memory, any storage system setup and with no restrictions on database size or any other artificial restrictions. You can download it at: http://www-306.ibm.com/software/data/db2/express .


DB2 Versions and SAP Kernel Releases

DB2 Version 8DB2 Version 9.1

DB2 for LUW Version

4.0B_EXT 4.5B_EXT 4.6D_EXT 6.403.1I_EXT

DB2 Version 9.5

SAP Kernel Releases

See SAP Note 101809 for: Supported combinations of database version and SAP kernel release SAP supported Fix Packs per database version

7.0x7.1x7.2x7.3x

DB2 Version 9.7DB2 Version 10.1

For current information about supported combinations of SAP software and the IBM DB2 database, refer to SAP Service Marketplace at http://service.sap.com/pam .

For information about end-of-service dates of DB2 databases declared by IBM, go to the IBM home page at http://www.ibm.comand search for document 1168270 .For the corresponding end-of-service information from SAP, read SAP Note 1168456 .

For information about SAP support of DB2 versions that have reached end-of-service, see SAP Note 677786 . Pay special attention to upgrade restrictions that apply to particular combinations. Not every potential combination can be reached by means of an SAP system installation. Corrections to DB2 software versions are delivered in the form of Fix Packs. A Fix Pack is a cumulative collection of all available

fixes up to a predefined level. Applying the latest Fix Pack level helps you to further improve the performance and stability ofyour DB2 database server.

Make sure that your database server is on a Fix Pack level according to the recommendations in SAP Note 101809. Use only Fix Packs from SAP Service Marketplace at: http://service.sap.com/swcenter-3pmain -> DB2 for Unix and Windows ->

DB2 Version Download -> Installation -> DB2/UDB .


V9.7FP3

DB2 Software Lifecycle

DB2V9.5GA

V9.5FP1

V9.5FP2a

V9.5FP4SAP

V9.5FP5SAP

V9.5FP6a

V9.5FP7

V9.7FP2SAP

V9.7FP3SAP

VersionFix Pack

. . .

. . .

InstallDB2 V9.5

FP1Apply

Fix PackFP4SAP

Upgrade toDB2 V9.7FP2SAP

ApplyFix PackFP5SAP ApplyFix Pack

FP3SAP

DB2 Software Shipment (with SAP)

Customer Software Maintenance - Examplet

DB2V9.7GA

Don't useIBM's orig.Fix Pack !

IBM ships DB2 software versions and version-related Fix Packs (FP). GA stands for the first shipment of a DB2 version ("General Availability"). SAP provides Fix Packs for their customers on SAP Service Marketplace (free of charge). Fix Packs with suffix "a" or "SAP"

contain SAP-specific corrections.Therefore, SAP customers should apply DB2 Fix Packs only from SAP Service Marketplace.

All Fix Packs are cumulative collections of fixes for a certain DB2 version. You do not need to apply them sequentially. As of DB2 V9.1, a Fix Pack image is also a full installation image. Therefore, you do not need to install a DB2 version's GA

image first. As of DB2 9.7, changing to a new database version is called a "database upgrade" (former name up to and including DB2 V9.5:

"database migration").

10


DB2 Software Maintenance

Install aDB2

Software Version

Upgrade to a

New DB2 Version

Done by the SAP installation tool (silent installation) Together with the DB2 CLI/JDBC driver software Described in the SAP installation guide

on SAP Service Marketplace

Done by IBM / SAP tools Using Fix Packs supplied on SAP Service Marketplace Must include the DB2 CLI/JDBC driver software Described in an SAP Note

for each DB2 version and platform family

Done by IBM / SAP tools Must include the DB2 CLI/JDBC driver software Described in the SAP Database Upgrade Guide

on SAP Service Marketplace and in a corresponding SAP Note

Apply a DB2

Fix Pack

You find installation guides for SAP products using the DB2 database on SAP Service Marketplace, for example under:http://service.sap.com/instguidesnw73 Installation Installation SAP NetWeaver Systems SAP NetWeaver 7.3 EHP1-based Systems - Installation Guides DB2 for Linux, UNIX, and Windows AIX ABAP.

See the following SAP Notes for the latest information about DB2 version upgrades (including the path to the database upgrade guide on SAP Service Marketplace):Note 1645684 - DB6: Upgrade to Version 10.1 of DB2 LUWNote 1332109 - DB6: Upgrade to Version 9.7 of DB2Note 1079000 - DB6: Migration to Version 9.5 of DB2Note 938522 - DB6: Migration to Version 9 of DB2

There is one SAP Note describing the installation of Fix Packs for each DB2 version and platform family (Windows / UNIX+Linux), for example the following:Note 1363169 - DB6: Installing fix packs for DB2 V9.7 (UNIX + Linux)Note 1363170 - DB6: Installing fix packs for DB2 V9.7 (Windows)

After the initial installation of the DB2 software using the SAP installation tool, dont forget to apply the respective DB2 licenses. SAP customers with a DB2 OEM license issued by SAP are allowed to download and apply these licenses from SAP Service Marketplace as described in SAP Note 816773 - DB6: Installing an SAP OEM license.

11


Checking the Current DB2 Level db2level

db2prd> db2leveldb2levelDB21085I Instance "db2prd" uses "64" bits and DB2 code release"SQL09072" with level identifier "08030107".Informational tokens are "DB2 v9.7.0.2", "special_24281", "IP23082_24281",and Fix Pack "2".Product is installed at "/db2/db2prd/db2_software".

DB2 Software Bit-Level

IBM Build Level IdentifierImportant:

Check against SAP Note 101809.

Fix Pack LevelIn some cases different from the

original SAP Fix Pack level identifier

DB2 Software Version

DB2 Software Installation Path

The DB2 command db2level provides information about the actual DB2 software version, DB2 fix pack level including build level, and the directory where the software has been installed.

Important: To make sure that your software is on a level supported by SAP, check the IBM build level identifier against SAP Note101809.

12


Checking DB2 Installations on a Machine db2ls

db2prd> db2lsdb2lsInstall Path Level Fix Pack Special Install No. Install Date ...-----------------------------------------------------------------------------------

/opt/ibm/db2/V9.1 9.1.0.3 3 Tue Sep 12 .../db2/db2dev/db2_software 9.7.0.0 0a Thu Aug 20 .../db2/db2prd/db2_97_fp2 9.7.0.2 2 1 Wed Sep 1 ...

db2prd> db2ls db2ls --q q --p p --b /db2/db2prd/db2_97_fp2b /db2/db2prd/db2_97_fp2Product Response File ID Level Fix Pack Product Description-----------------------------------------------------------------------------------

ENTERPRISE_SERVER_EDITION 9.7.0.2 2 DB2 Enterprise Server Edition

db2prd> db2ls db2ls q q --a a --b /db2/db2prd/db2_97_fp2b /db2/db2prd/db2_97_fp2Feature Response File ID Level Fix Pack Feature Description-----------------------------------------------------------------------------------

...

DB2_PRODUCT_MESSAGES_EN 9.7.0.2 2 Product Messages - EnglishBASE_CLIENT 9.7.0.2 2 Base client supportJAVA_RUNTIME_SUPPORT 9.7.0.2 2 Java Runtime Support ...

DB2 Software Installations on a Machine

Products

Featuresincl. hidden

features

Command db2ls provides information about DB2 software installations on a machine. As of DB2 V9.1, DB2 products are installed from archive files and therefore cannot be queried using operating system native

utilities (such as rpm or lslpp). Use the DB2 command db2ls to query

the install path of each DB2 software installation on a machineincluding DB2 version, release and Fix Pack level (also for pre-DB2 V9.1 releases)

installed DB2 products (only), using option -p installed features of a DB2 software installation (option a lists hidden features, too)

db2ls is available on UNIX and Linux only. If the db2ls executable cannot be found in your search path list, start it from the /db2/db2/db2_software/install directory. db2ls exploits DB2's global registry file (root installations: /var/db2/global.reg or /var/opt/db2/global.reg on HP-UX; non-root

installations: $HOME/sqllib/global.reg).If db2ls is not available, use command db2greg dump instead and interpret the output line(s) starting with "S" (software installation).

13


1 Basics Contents


Basics

DB2 Essentials



DB2 Configuration


14


DB2 for LUW Naming Conventions

Product Name:IBM DB2 for Linux, UNIX, and Windows

Commonly Used Abbreviations:IBM DB2 for LUW * DB2 LUW * DB2

Other IBM Database Products:IBM DB2 for z/OSIBM DB2 for i (former DB2 for AS/400)

Former names (used as synonyms in SAP Notes, IBM and SAP documentation, and on certain Web pages):

DB2 UDB (Universal Database; also used with DB2 for z/OS and DB2 for i !)DB2 Common Server (DB2 CS)DB2/6000

Internal Abbreviation:DB6

DB2DB4

Use this term for searching in SAP Corporate

Portal

SAP's abbreviation DB6 has been derived from the legacy product name "DB2/6000". The first DB2 for LUW platform supported by SAP was AIX on IBM RS/6000 (the later pSeries Power Systems).

Be careful with findings under the search term "DB2" in SAP Corporate Portal and on IBM Web pages such as www.redbooks.ibm.com. They could be related to IBM DB2 for z/OS, the database solution for IBM mainframe systems.

"DB6" and "DB2 for LUW" are only internal abbreviations and not used in official SAP product documentation.

15


Architectural Overview

ApplicationProcesses(local / remote)

DB

Se

rver

(E

xam

ple:

O

n a

Sin

gle

Mac

hin

e)Work ProcessWork ProcessWork Process

db2agent db2agent

db2agntpdb2agntpdb2agntp

BufferPool(s)LogBuffer

db2loggw db2loggrdb2pfchrdb2pfchrdb2pfchr

db2pfchr db2pclnrdb2pclnrdb2pclnr

StorageSubsystem

CoordinatorAgents

Parallel Sub-Agents

Memory Areas

DB2 ServicesManaging I/O(Log Writer / Reader,Prefetchers,Page Cleaners)

db2agent

...

...

...

/log_dir /sapdataN

As an architectural overview, the picture combines a selection of important DB2 processes / threads (rounded rectangles), memory areas (barred boxes), and computing resources (CPUs, storage units) together with their dependencies.

For simplicity reasons, you see a DB2 database server on a single machine. One of the key design points of DB2's architecture is to exploit all resources available to DB2 (CPU, memory, I/O) within both a

single query and across different queries, in order to achieve superior performance and scalability. SQL requests, database utilities, and database services run in parallel in order to fully utilize all resources. The rounded rectangles represent DB2 engine dispatchable units (EDUs). EDUs are implemented as threads (all within a single

process) on all platforms as of DB2 V9.5, and as processes on Linux and UNIX up to DB2 V9.1 . An application is assigned to a dedicated coordinator agent (EDU name: db2agent), which coordinates the processing for that

application and communicates with it. Applications can also be assigned to a set of subagents (db2agnt[d]p or db2agnts), which work together on individual database requests, coordinated by a coordinator agent.

All agents are managed with a pooling algorithm that minimizes the number of creations / destructions of agent EDUs. The log writer EDU (db2loggw) ensures that all changes of data (data manipulation changes, data definition changes, storage

configuration changes) are reported in log files on disk immediately. Prefetchers (db2pfchr) and page cleaners (db2pclnr) are designed to minimize or eliminate I/O waits that can occur, when agents

themselves must read or write data into or down from the buffer pools. The prefetchers' main duty is to ensure that agents doing scans do not have to wait for disk I/O. Agents send asynchronous

read-ahead requests to a common prefetch queue, and the prefetchers use big-block or scatterd read I/Os to bring the requested pages into the buffer pool.

The page cleaners are service EDUs that, under certain conditions, are triggered to "clean" (flush to disk) "dirty" pages (changed pages).

16


Statement Processing: Involved Layers

SAP AS ABAP

Work ProcessWork ProcessWork Process

Dynpro Processor

ABAP Processor

Database Interface

DB6 Database Support Layer 1)

DB2 Call Level Interface - CLIDB2 Instanceand Database

db2agentdb2agentdb2agent

Transformation ofSAP Open SQL calls intoDB2-specific SQL calls

1) Database support layer (DBSL);DB6-specific SAP component;aka "Database Shared Library"

Execution ofABAP Code bySAP work processes

The slide shows a simplified schema of the technical layers involved in the execution of SQL requests processed by an ABAP application server.

SAP ABAP processor and SAP Dynpro processor are responsible for interpreting ABAP program code and managing the I/O processing with the SAP user interface.

SQL requests are first processed in the SAP Database Interface (DBI). The DBI is SAP's database independent interface layer for SQL processing.

The DBI sends SQL requests to the SAP Database Support Layer (DBSL) for database-specific processing.The Database Support Layer is also referred to as "Database Shared Library" (DBSL).For each database vendor, SAP provides a separate database support layer.

The SAP database interface together with the SAP DB6-DBSL transforms SAP Open SQL requests into DB2-specific calls of the DB2 call level interface (CLI).CLI operations are calls of routines like SQLAllocHandle, SQLExtendedPrepare, SQLExecute, SQLFetch, and SQLFreeStmt.

17


Statement Processing: Select

Work ProcessSELECT mandt, bname, ustypFROM sapprd.usr02WHERE mandt = '100' and bname = 'DDIC'

0 SELECT STATEMENT Estimated Costs = 7,586E+00 timerons 1 RETURN

2 FETCH USR02 3 IXSCAN USR02~0 #key columns: 2db2agent

db2pfchr

Buffer Pool

Containers

Passing statement to agentLooking for execution plan in package cache;creating plan if needed (= preparation)Looking for page(s) in buffer poolReading page(s) into buffer pool if needed(by prefetcher or by agent)Fetching data from buffer poolReturning result set to application

11

22

33

44

55

66

1122

3344

55

66

The slide shows a simplified schema of the execution of an SQL SELECT statement (read-only processing): The SAP work process sends the statement to its associated DB2 agent. The SQL statement is transformed into an execution plan by the DB2 optimizer. During this preparation, the optimizer takes

statistical data and DB2 configuration information into account to find the optimal way to data.If the statement has been executed before, the execution plan is probably already in the package cache and can be re-used.

During statement execution, the agent tries to read the data to be selected from the buffer pool (in-memory work).If the index and data pages needed are not in the buffer pool, they have to be read from storage (physical read). This can be done by one or several prefetchers (if the amount of data to be read is large) or by the agent himself (if a small result set is expected).

The agent selects the data requested by the application by fetching it from the pages in the buffer pool and returns the result set to the application process (SAP work process).

18


Statement Processing: Update

Work ProcessUPDATE sapprd.usr03SET telnr = '06227747474'WHERE mandt = '100' and bname = 'DDIC'

0 UPDATE STATEMENT Estimated Costs = 1,515E+01 timerons 1 RETURN

2 UPDATE 3 FETCH USR03

4 IXSCAN USR03~0 #key columns: 2db2agent

db2pclnr

Buffer Pool

Containers

Passing statement to agentLooking for execution plan in packagecache; creating plan if neededLooking for page(s) in buffer poolReading page(s) into buffer pool if needed(usually by agent)Updating data in buffer pool and writingchange to log buffer (simultaneously)Writing log record to log fileReturning confirmation to applicationWriting changed page(s) to container(s)(asynchronously)

11

22

33

88

55

77

1122

3344

55

66

LogFile

db2loggw66

Log Buffer

55

44

77

88

The slide shows a simplified schema of the execution of an SQL UPDATE statement (data manipulation processing): The SAP work process sends the statement to its associated DB2 agent. The SQL statement is transformed into an execution plan by the DB2 optimizer. During this preparation, the optimizer takes

statistical data and DB2 configuration information into account to find the optimal way to data.If the statement has been executed before, the execution plan is probably already in the package cache and can be re-used.

During statement execution, the agent tries to read the data to be updated from the buffer pool (in-memory work).If the index and data pages needed are not in the buffer pool, they have to be read from storage (physical read). This is usually done by the agent.

Updating the data in the buffer pool and logging this change in form of a log record in the log buffer happens simultaneously. Although the process of flushing log records from the log buffer to the log file is an asynchronous operation, it must happen

shortly after the log records arrive in the log buffer.There are three conditions that trigger the writing of new log records from log buffer to the current active log file:

(1) An application performs a COMMIT SQL statement. (2) One second has elapsed. (3) The log buffer is full.

After log writing, the agent returns a confirmation of the update to the application process (SAP work process). Changed (= "dirty") pages in the buffer pool must be written back to storage sometime. This happens asynchronously, preformed

by the DB2 page cleaners.There are three conditions that trigger the writing of changed pages from the buffer pool to the containers of the respective tablespace:

(1) The maximum amount of log space that should be read during crash recovery has been reached (DB CFG parameter SOFTMAX).

(2) The maximum percentage of changed (un-written) pages has been reached in the buffer pool (DB CFG parameter CHNGPGS_THRESH).

(3) No free pages are available in the buffer pools for further inserts or updates.In this case, victim page cleaning is started.

19


SAP and DB2 System Layout Rules

SAP System(1 n Application Servers)

SAPSID PRD

DB2 Instance db2prd

DB2 Database

DBSID PRD

"DB2 Instance"= "Database Manager"

= "DBM"

One DB2 instance canmanage several databases

- not used by SAP

DB2 Software Copy

Several instances canshare one DB2 software copy

- not used by SAP

SAP System 2(in an MCOD Scenario)

SAPSID XYZ

1

Default Relation

1

1

1

The slide shows a default constellation of an SAP system on DB2: Each SAP system uses one DB2 instance. A DB2 instance is also called DB2 database manager. A DB2 instance represents several services and memory areas that are needed to operate DB2 databases. In SAP

environments, each DB2 instance contains only one database. With SAP NetWeaver installation tools as of release 7.0 and DB2 V9.1, every SAP system uses its own copy of the DB2

for LUW ESE software. With SAP MCOD scenarios (multiple components - one database), several SAP components (systems) share one

database (respectively one DB2 instance contains one DB2 database). Each component in an MCOD scenario uses its own database schema (AS ABAP example: schema SAPPRD and schema SAPXYZ).

20


Storage Concepts

DB2 Tablespace Storage Types Used by SAP for:

DMS Database Managed Storage

Pre-allocated space for database objects in containers

Containers are files in file systems or space on raw devices

Preferably several containers per DMS tablespace

Other concepts based on DMS:Autoresize tablespacesAutomatic Storage tablespaces

SMS System Managed Storage

Database objects stored as single files in directories

Files grow and shrink as needed

Preferably several directories per SMS tablespace

Standard Data and Index TablespacesExamples:PRD#BTABDPRD#BTABI

Temporary TablespacesExample:PSAPTEMP16

Data of a BTAB table like TST01 is stored in the 4 containers of

tablespace PRD#BTABD

Data of a temporary table is stored in form of 4 temp. files in the 4 directories of temporary

tablespace PSAPTEMP16

Storage Example

Logical database objects like tables or indexes must be stored somehow on a physical storage layer. If you use DMS, the data of a tablespace is stored in containers on file system level or on raw devices. If you use SMS, the data of a tablespace is saved in directories, and for each object, the database creates one file per directory.

Those files grow and shrink depending on the amount of data contained in the table / index. DMS is the default tablespace storage type for data and index tablespaces. SMS is the default tablespace storage type for

temporary tablespaces.

21


SAP System PRD

DB2 Instance db2prd

DB2 Database PRD

Tablespace PRD#BTABD

Table TST01

Table BALHDR

Table TBTCO

. . .

Container 000 in /sapdata1/




Containers of DMS TablespacePRD#BTABD

Layout + Storage Overview: Example

SAP systems on DB2 databases use several tablespaces to store database objects of different categories:#BTABD: tables and Long Field / LOB objects of category "Transaction Data"#BTABI: indexes of category "Transaction Data"#STABD: tables and Long Field / LOB objects of category "Master Data"#STABI: indexes of category "Master Data"#DDICD: tables and Long Field / LOB objects of category "ABAP Dictionary Data"#DDICI: indexes of category "ABAP Dictionary Data"etc.

Each permanent tablespace uses a certain number of containers to store its data. During a standard SAP NetWeaverinstallation, your specification of sapdata directories determines how many containers a tablespace consists of.

22


Storage Locations on UNIX and Linux

/

/opt/IBM/db2/V10.1

/db2

/db2/db2prd

/db2/db2prd/db2_software

/db2/PRD

/db2/PRD/log_dir

/db2/PRD/log_archive

/db2/PRD/db2dump

/db2/PRD/db2prd

/db2/PRD/sapdata1 sapdataN

DB2 Software: IBM Default Directory(Not Used by SAP)

Home Directory of db2prd

DB2 Software as of SAPinst 7.0 SR3

Contains the Database Directory

Active LogsLogs Archived on Disk (Example, No Default Directory)DB2 Diagnostic Path

DB2 Data (Container Files)

Root Directory

/db2/db2prd/sqllib DB2 Instance Directory

On UNIX / Linux systems, the DB2 software is installed by default in a directory like /opt/IBM/db2/V10.1 . This also applied to installations with legacy versions of SAPinst.

As of SAP basis release 7.0 SR3, the SAP installation tool installs the DB2 software under the home directory of db2 in /db2/db2/db2_software . This directory structure together with the software installation mode as of DB2 Version 9 allows you to install multiple copies of the DB2 software on one machine.

DB2 instance data is stored in the directory /db2/db2/sqllib and its subdirectories. The database directory is located in /db2//db2/NODExxxx/SQL00001 . The data files of the database are stored in directories like /db2//sapdata1/NODExxxx ...

/db2//sapdataN/NODExxxx (standard DMS concept), and /db2//sapdata1/db2/NODExxxx//Tyyyyyyy /db2//sapdataN/db2/NODExxxx//Tzzzzzzz (automatic storage concept).

Files of temporary objects (SMS concept) are stored by default in subdirectories of the sapdataN locations. With former SAP basis releases, files of temporary objects had been stored under /db2//saptemp1/NODExxxx/temp16 or /db2//sapdatat .

The DB2 active log files are written to /db2//log_dir/NODExxxx . Active log files are copied to an archiving destination as soon as they are filled. A commonly used archiving location on disk is

/db2//log_archive . DB2 diagnostic information is stored in /db2//db2dump and its subdirectories. On UNIX and Linux, you can change to

this directory using the alias cddump.

23


Storage Locations on Windows

X:

X:\Program Files\IBM\sqllib

X:\db2

X:\db2\db2prd

X:\db2\db2prd\db2_software

X:\db2\PRD

X:\db2\PRD\log_dir

X:\db2\PRD\log_archive

X:\db2\PRD\db2dump

X:\db2\PRD\db2prd

X:\db2\PRD\sapdata1 sapdataN

DB2 Software: IBM Default Directory(Not Used by SAP)

Home Directory of db2prd

DB2 Software as of SAPinst 7.0 SR3

Contains the Database Directory

Active LogsLogs Archived on Disk (Example, No Default Directory)DB2 Diagnostic Path

DB2 Data (Container Files)

Any Drive / Partition Specification

X:\db2\db2prd\sqllib DB2 Instance Directory

SAP installations on Microsoft Windows use a similar directory structure compared to installations on UNIX / Linux. During the installation process using SAPinst, the user is prompted for the drive locations of the directories listed on this slide.

You can put several of the directories on the same drive, depending on the system usage.

24


DB2 Log File Archiving

11

A log file is filled up with log information.11

22 If the log file is full, the db2logmgr copies the log file to the log archive destination.

33

The next log file is filled up with log information.33

t t22

log_dir

Log ArchiveDestination

log_dir

Log ArchiveDestination

S000

0201

.LO

G

S000

0202

.LO

G

S000

0203

.LO

G

S000

0201

.LO

G

S000

0202

.LO

G

S000

0203

.LO

G

S000

0204

.LO

G

S000

0201

.LO

G

S000

0202

.LO

G

S000

0201

.LO

G

S000

0202

.LO

G

S000

0203

.LO

Gdb

2lo

gmgr

If you are using log archiving, the log manager attempts to archive active logs as they are filled. When archiving, the log manager copies the log file, but the log file might still be active and needed for normal rollback

processing. This method allows you to copy log data to a save location as fast as possible.

25


1 Basics Contents


Basics

DB2 Essentials



DB2 Configuration


26


Ways of Accessing DB2

SQL APIs

Database Engine

Administration /Monitoring Tools

Control Center - db2cc

Data Studio

Development Tools

SAP DBA Cockpit

SAP Performance WH

. . .

Command LineProcessor - CLP

db2 > _

Interactive SQL

Commands

Applicationsusing

Java JDBC

APIs

.NET

Embedded SQL

Call Level Interface

. . .

XML

DB2 supports numerous interfaces for users, applications, and tools to access data from the database, or to manage the database system.

The most import interface is SQL access. SQL structured query language is the industry standard to access a relational database. Users can retrieve data or manipulate data or data definitions by submitting an SQL statement directly from the command line processor (CLP), or indirectly from applications or tools.

DB2 also supports Application Programming Interfaces (APIs) such as Java JDBC, the Call Level Interface (CLI), XML storage structures, .NET, or native DB2 admin APIs.

The DB2 database system can be administered using DB2 commands from CLP, or using admin tools such as IBM Data Studio for DB2, SAP's DBA Cockpit, DB2 Control Center, or other third-party tools.As of DB2 10.1, the DB2 Control Center tools and all related components such as wizards and advisors are discontinued.

The command clpplus starts command line processor plus (CLPPlus).After starting CLPPlus, you can issue CLPPlus commands, connect to databases, define and run SQL statements and database commands, and run scripts that contain SQL statements and commands.CLPPlus provides a command line interface that helps database administrators to apply knowledge gained from other database products.

SAP recommends using the CLP and transaction DBACOCKPIT for administration purposes.

27


SAP Application Server ABAP Connect to DB2

SAP Application Server ABAP

SAP Dispatcherdisp+work[.exe]

. . .

SAP Work Processdisp+work[.exe]

SAP DBSLdbdb6slib.[o,so,sl,dll]

DB2 CLIlibdb2.[o,a,sl], db2cli.dll

External SAP Executables

With DBSL AccessR3trans, tp, R3load,R3ldctl, R3szchk,saplicense, ...

SAP DBSLdbdb6slib.[o,so,sl,dll]

DB2 CLIlibdb2.[o,a,sl], db2cli.dll

Without DBSL Accessdb6util, dmdb6*,

brdb6*, ...

DB2 API + CLIlibdb2.[o,a,sl], db2cli.dll

Schema:sap

or sapsr3

Database

The slide outlines which components of an SAP Application Server (AS) ABAP connect to the DB2 database. You see the SAP work processes and several additional SAP executables (tools, utilities) establishing a database connect.

On each SAP application server there is one dispatcher process forking the work processes and coordinating their work.A user request is received by the dispatcher first, and then assigned to an available work process. The work process executes the application logic, processes the queries of the user and returns the result to the user.

SAP ABAP applications use the database-independent SAP OPEN SQL language for data access. OPEN SQL needs to be translated to native SQL that is understood by the DB2 database. This translation is done by the Database Support Layer (DBSL; also referred to as Database Shared Library).

SAP provides a DBSL specially for DB2 for LUW (library example: dbdb6slib.o). The DBSL uses the DB2 Call Level Interface (CLI / CLI driver) to access the DB2 database. DB2 Call Level Interface is IBM's callable SQL interface to DB2 database servers. It is a 'C' and 'C++' application programming

interface for relational database access that uses function calls to pass dynamic SQL statements as function arguments. For more information about the DB2 CLI driver, see SAP note 1091801 and refer to the article "The New DB2 Client Setup in

SAP Systems with DB2 for Linux, UNIX, and Windows" in the SCN. External SAP executables such as tp, R3trans or R3load use the SAP DBSL and the CLI. Tools like db6util do not use OPEN

SQL and therefore do not need the DBSL. They connect to the database using the CLI driver only. SAP installations based on basis releases prior to 7.0 SR3 used a client software (the so-called DB2 runtime client or "fat client")

instead of the CLI driver (also known as "thin client"). See SAP Note 1091801 for information about how to convert your SAP system from a DB2 runtime client to a DB2 CLI driver.

28


CLI Driver Usage Details

SAP Central Systemon DB Server

DB2 Database

TCP/

IP

Host A

SAP RemoteApplication Server

TCP/I

P

Host B

DB2 CLI

/usr/sap/PRD/SYS/global/db6

db2dump

db2diag.log

jdbc

db2cli.ini CLI Configuration File

CLI Diagnostic Path

Diagnostic Log of CLI

JDBC Driver Directory

AIX_64 CLI Driver Directory

CLIDirectory

Structures:

DB2 CLI

For legacy installations using the DB2 runtime client,see SAP Note 1091801

Both SAP central systems on the DB2 database server host and remote application servers of an SAP AS ABAP installation utilize the DB2 CLI driver to execute SQL requests on the database.

In SAP environments, the CLI is configured to communicate with the database using TCP/IP protocol (locally and remotely). The SAP installation tool SAPinst installs the CLI driver software under the SAP global directory (on UNIX / Linux:

/usr/sap//SYS/global/db6). Since this location is a central one (usually mounted via NFS as directory /sapmnt//global), the CLI driver software is installed once per SAP system (and OS type) only.

Since the DB2 call level interface software has only a small footprint on an application server machine, the CLI driver is also referred to as "thin client".

The SAP utility sapcpe (automatic adjustment of locally installed executables) automatically ensures that a local copy of the CLI driver library is stored and (when necessary) refreshed on each remote SAP instance.

Similar to the handling of the CLI driver, SAP manages a copy of the DB2 JDBC driver in a subdirectory jdbc of the SAP global directory. The JDBC driver is used by SAP Application Server Java (see next slide).

29


SAP Application Server Java Connect to DB2

J2EE Application Server

Java Dispatcherjlaunch.exe

Server Processjlaunch.exe

Open SQL for Java

DB2 JDBC Type 4db2jcc.jar

Central Instance

Message Server- List of dispatchers- Load balancing between

Java instances

Application Thread

Enqueue Server- Synchronization within

the Java cluster- Lock management

Standalone Tools

StandaloneLog Viewer

JCmon

Standalone Tools

Config Tool

DB2 JDBC Type 4db2jcc.jarSchema:

sapdbor sapsr3db

Database

Application Thread

On an SAP J2EE Application Server, the application threads within a server process run Java applications using Open SQL for Java.

The server process connects to the database using the DB2 JDBC driver. JDBC is an application programming interface (API) that Java applications use to access relational databases. The SAP Config Tool directly connects to the database using the DB2 JDBC driver. SAP only supports the DB2 JDBC type 4 driver.

30


TCP/IP Connect and IPC Connect

Work Process

db2tcpcm

db2agent

db2sysc[ ]

11

22

33

Listening on theport of service

sapdb2

Idle agentused or newagent started

Continuouscommunicationon an arbitrarily

chosen port

TCP/IP Connect IPC Connect

db2bp

db2ipccm

db2agent

11

22

33

Connect from CLPinternally createsa db2bp process

using IPC

Idle agentused or newagent started

Continuouscommunicationover memory

ASL Heapin AgentSharedMemory

TCP/IP connects: As already stated, SAP components like work processes or transport utilities connect to the database over TCP/IP using

the CLI driver. The responsible listener EDU (running on DB2 instance level) is db2tcpcm (TCPIP communication manager). db2tcpcm is continuously listening for connect requests on the TCP port associated with service name sapdb2,

as configured in the database manager configuration using parameter SVCENAME . Another prerequisite for TCP/IP connects to the database is the profile registry setting DB2COMM=TCPIP (SAP default). Whenever an application process tries to connect to a database over TCP/IP, it contacts the listener on the predefined

port. The listener provides an agent for the requestor (in a process-based version of DB2, the agent process is started by the DB2 system controller process db2sysc).

A direct communication between the application process and its agent is established on an arbitrarily chosen free TCP port.

The db2tcpcm listener EDU is now free to serve other communication requests. IPC connects:

Inter-process communication (IPC) allows local applications to connect to the database using a shared memory area. IPC is not used by SAP components anymore, even if they are local (on the machine where the DB2 database resides).

IPC communication is typically used if you run administrative commands or SQL statements using DB2's command line processor (CLP).

Every local database connect from the CLP creates a db2bp process on OS level (DB2 backend process) that contacts the IPC listener EDU (db2ipccm) through a message queue owned by db2ipccm. The listener provides an agent for the requestor.

A direct communication between the db2bp process and its agent is established using a memory portion called application support layer (ASL) heap in the agent/application shared memory set.

The db2ipccm listener EDU is now free to serve other local communication requests. A db2agent is either retrieved from the DB2 agent pool or, if no idle agent is available, it is created as a separate EDU. The

number of idle agents in the pool is defined with DBM CFG parameter NUM_POOLAGENTS. The maximum number of agents is defined with DBM CFG parameter MAXAGENTS.

To list all applications currently connected to your database, issue commanddb2 list applications [for db ] [show detail]

31


db2prd> grep sapdb2 /etc/servicessapdb2PRD 60000/tcp # SAP DB2 Communication Port

TCP/IP Connect Details

11

22

33

TCP/IP Port of the Application

Arbitrary Port

Work Process

db2tcpcm

db2agent

Listener Port: sapdb2

11

22

33

Connect Request

Socket CreationCommunicationApplication - Agent

db2prd> db2 list applicationsAuth Application Appl. Application IdId Name Handle------- ----------- ------ --------------------------------

SAPPRD disp+work 26 10.17.202.235.39358.11051314193SAPPRD disp+work 19098 10.17.202.235.40918.11062208304

DBM CFG:SVCENAME = sapdb2PRDdb2cli.ini:Servicename=60000Profile Registry:DB2COMM=TCPIP

For a TCP/IP database connection, the following scenario applies:1. The application sends a connection request from an arbitrary socket to the database server (port name

sapdb2).2. A new socket is created on an arbitrary port for the db2agent.3. The db2agent responds on the new socket and communication is established.

During the installation process, the SAP installation tool sets the DBM CFG variable SVCENAME to sapdb2. Furthermore, the profile registry variable DB2COMM is set to TCPIP, which is a common prerequisite for TCP/IP communication with the database. In the client configuration file db2cli.ini, a corresponding entry is created with the keyword Servicename, followed by the listener port number.

32


Who's Connected?

db2prd> db2 list applicationsdb2 list applicationsAuth Application Appl. Application Id DB # ofId Name Handle Name Agents------- ----------- ------ -------------------------------- ---- ------

SAPPRD disp+work 26 10.17.202.235.39358.11051314193 PRD 1SAPPRD disp+work 19098 10.17.202.235.40918.11062208304 PRD 1SAPPRD disp+work 32 10.17.202.235.39364.11051314193 PRD 1SAPPRD disp+work 20466 10.17.202.235.40942.11062223410 PRD 1SAPPRD disp+work 25 10.17.202.235.39357.11051314193 PRD 1SAPPRD disp+work 38 10.17.202.235.39370.11051314193 PRD 1SAPPRD disp+work 31 10.17.202.235.39363.11051314193 PRD 1SAPPRD disp+work 37 10.17.202.235.39369.11051314193 PRD 1SAPPRD disp+work 30 10.17.202.235.39362.11051314193 PRD 1DB2PRD db2bp 35425 *LOCAL.db2prd.110701114625 PRD 1...

Local (IPC) Connect from CLP

TCP/IP Connect of an SAP Work Process

How to force a disconnect:db2 "force application (35425)"

To list all applications currently connected to your database, issue the commanddb2 list applications [for db ] [show detail]

TCP/IP connects show an application ID, consisting of the database host's IP address, the arbitrarily chosen TCP port number, and a connection timestamp.

IPC connect entries in the application list are identified by an application ID starting with "*LOCAL", followed by the instancename and a connection timestamp.

Some DB2-internal service EDUs establish an internal connect to the database (examples: db2wlmd the workload manager statistics collector, db2stmm the self tuning memory manager, db2taskd the background database task distributor, db2evm* -several event monitor EDUs).Depending on your DB2 software version, these EDUs might be displayed only with the SHOW DETAIL option of the LISTAPPLICATIONS command.DB2-internal database connects are identified by an application ID starting with "*LOCAL", followed by the database name and a connection timestamp.

Every connection to the database is identified by a unique application handle number.Use this number to explicitly force a disconnect of the respective application from the database.

33


DB2 Command Line Processor CLP

CLP

CommandMode

InteractiveInput Mode

BatchMode

db2prd:> db2 get dbm cfgdb2prd:> db2 "select * from t02"db2prd:> db2 "? backup"db2prd:> db2 "? SQL2412"

db2prd:> db2db2 => list db directorydb2 => select * from t01db2 => ? reorgdb2 => ? CLI0104E

db2prd:> db2 tvf /x/script.sql

The DB2 command line processor (CLP) is used to execute database commands / utilities and SQL statements and to access help information about command syntax and message codes.

The db2 command starts the CLP in interactive input mode (characterized by a db2 => input prompt) or is used as a command prefix in command mode. If you want to run commands / statements in batch mode, db2 option f allows to specify an input file with DB2 commands or SQL statements to be executed.

On Windows, the command db2cmd opens a CLP-enabled DB2 window and initializes the DB2 command line environment. For more information about the DB2 CLP, refer to "Command line processor features" and the following topics in the DB2

information center. In command mode, you have to hide special characters like *, ? or () from the OS command interpreter. To do this, put the whole

expression (except db2) in double quotes. You can control CLP behavior using CLP command options. To list the current CLP command options, enter:

db2 list command options To change CLP command options

set environment variable DB2OPTIONS (UNIX example: export DB2OPTIONS='-c -es -t' meaning auto-commit; display SQLSTATE instead of SQLCODE info; statement termination using semicolon) or

specify command line option flags together with the db2 command (examples: -c auto-commit; +c no auto-commit; -v verbose; -s stop on error) or

overwrite all default CLP command options, environment settings, and option flag settings using:db2 update command options using c OFF s ON (no auto-commit; stop on error)

For more information about CLP options, refer to "CLP options" in the DB2 information center. You can obtain online help about command syntax and message codes using the question mark.

34


Admin and Monitoring Workbench: DBA Cockpit

DBA Cockpit SAP'sAdministration and

Monitoring Interface to DB2 Performance Monitoring

(Snapshots and History) Space Monitoring and

Management Backup and Recovery Configuration Changes

and Check DBA Job Maintenance Diagnostics and Alert

Monitoring BW Administration Tasks

SAP recommends usingDBA Cockpit or the DB2 CLPfor database administration

and monitoring

SAP NetWeaver integrates a comprehensive database administration and monitoring interface to DB2, called the SAP DBA Cockpit.As of NetWeaver 7.02, the WebDynpro version of DBA Cockpit is the recommended database administration interface (although the SAPGUI cockpit version is still available for compatibility reasons).

The DBA Cockpit on DB2 for LUW allows you to monitor, control and configure your database. It provides access to all functions and indicators for locating and diagnosing potential problems that could adversely affect the SAP system, as well as means for analyzing and tuning the database in order to optimize the throughput of the SAP system.

To call up the interface, enter transaction code DBACOCKPIT (or ST04). A back switch to the SAPGUI version of DBA Cockpit is possible using the button "Switch to SAPGUI". However, note that the

latest monitoring and administration features (like time-spend metrics, parameter check etc.) are only available in the WebDynproversion of DBA Cockpit.

DBA Cockpit can be configured to monitor and maintain remote databases. For example, with a central DBA Cockpit in a system landscape (equipped with the latest development and correction level), you can remotely manage DB2 databases of SAP systems (AS ABAP and AS Java) and of non-SAP systems. Ideally, this central DBA Cockpit can be established on a central SAP Solution Manager system.

Depending on the version of DBA Cockpit and of the database to be monitored / managed, certain data collectors together with storage locations for collected data are automatically implemented in the affected database.

For more information about the DBA Cockpit, refer to the SAP help portal:http://help.sap.com/saphelp_nw2004s/helpdata/en/e1/4a2842bfa75233e10000000a155106/content.htmor see the paper "SAP DBA Cockpit" on SAP SDN:http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/10a5f238-d09a-2c10-9a8a-d0a64f6a506b?QuickLink=index&overridelayout=true

35


Statement Execution from DBA Cockpit

DBA Cockpit: Diagnostics SQL Command Line

Designed to execute SQL statements (except those for data modification),but also for some administrative commands

The DBA Cockpit offers an interface to the CLP, which allows administrators to run SQL statements and some administrative commands.

To access the interface, select Diagnostics -> SQL Command Line. The administrative commands that can be executed through this interface are the ones supported by the ADMIN_CMD stored

procedure. (This procedure is used by applications to run administrative commands using the SQL CALL statement.)For more information about CLP commands supported by the ADMIN_CMD procedure (and thus executable on the "SQL Command Line"), refer to "ADMIN_CMD" in the DB2 information center.

If you try to modify data using an SQL statement on the "SQL Command Line", you will receive an error message like "Modifying statements are not allowed".

36


DB2 Main Security Mechanisms

Database System

Authentication ChecksAccess to DB2

controlled by OS specific facilities:Verification of the user's identity

Operating System orExternal Facilities

for Identity Checking

Authorization ChecksAccess within DB2

controlled by the database manager:Verification of the user's permissionto work with DB resources and data

Database System

Database Manager Mechanismsfor Authority / Privilege

Checking

DB2 utilizes two security levels to control access to database data and functions: Authentication is the control of access to DB2 (verification of the user's identity) managed by facilities of the OS or by

external facilities like LDAP. Authorization is the control of access to resources / operations and data within DB2 (verification of authority /

privileges) managed by the database manager.With each user request, there might be more than one authorization check, depending on the objects and operations involved.

37


R3trans

DB2 Authentication in SAP Environments (ABAP)

Work Process

11

22

...

SAP PWD File,contains encrypted

passwords of admand sap

Update( / Create)

33 db2 connect to user sap using

RequestPWD of

sap

Decrypt+ Receive

PWD PWD Storageon OS Level

Update using API

Work ProcessDatabaseManager

Database

44

dscdb6.conf dscdb6upSAP PWD Utility,

to be run asadm

With DB2 for LUW,OS users connectto the database.

Standard DB connect userof AS ABAP

is sap .

Authentication Type (from DBM CFG):AUTHENTICATION = SERVER_ENCRYPT

DB2 uses operating system features for authentication: users, groups, and the respective routines for their validation. The SAP installation program SAPinst creates three users (on OS level) for an SAP ABAP system:

db2 - DB2 instance owner and DB2 admin user (not used by SAP applications for accessing the database) adm - SAP administrator user (occasionally used for database connects) sap (also: sapr3, sapsr3) - SAP database connect user and schema owner

SAP kernel components as work processes and transport utilities must connect to the DB2 database.To avoid an interactive logon, SAP components read an (encrypted) password from a password file and use it to access the database.

The SAP DB2 password file is stored as/usr/sap//SYS/global/dscdb6.conf (database security component for db6 configuration file).It contains the encrypted passwords of the SAP administrator user adm and of the database connect user sap (or sapr3 or sapsr3).

You can re-create the password file using the SAP DB2 password utility dscdb6up (update password utility; to be run as user adm):

dscdb6up -create To update the password of adm or sap in the password file and on OS level, enter:

dscdb6up If the password of one of these users has been changed with OS means (e.g. during a periodical password maintenance), a

subsequent change in the password file using dscdb6up is necessary. In SAP systems based on SAP NetWeaver 7.0 SP 13 or lower, in order to read passwords from the dscdb6.conf file, you need

an encryption / decryption key.This key is stored using the environment variable DB2DB6EKEY. The value of DB2DB6EKEY must be identical on all application servers and on the SAP system database server(s). DB2DB6EKEY is requested and set during the installation of your SAP system. The default value is .In SAP systems based on SAP NetWeaver 7.0 SR3 (SP 14 or higher), the DB2DB6EKEY environment variable is no longer used. Under these circumstances, the dscdb6.conf file contains a third line with a timestamp.

SAP's default authentication type (declared using DBM CFG parameter AUTHENTICATION) is SERVER_ENCRYPT .SERVER_ENCRYPT means that authentication takes place on the database server; user IDs and passwords are encrypted (by DB2 means) when being sent from the client to the server.

38


Authorization

DB2 Authorization in SAP Environments (ABAP)

Administrative Authorities Privileges= groups of privileges (databaserelated) and control over databasemanager operation

= single permissions for a user orgroup, enabling to create / accessdatabase objects

CONTROLSELECT

UPDATE

Database-Level:DBADM

System-Level: (= Instance-Level)SYSADM

SYSCTRL

SYSMAINT

SYSMON

...

...

SYSADM_GROUP

SYSCTRL_GROUP

SYSMAINT_GROUP

SYSMON_GROUP

= dbadm

= dbctl

= dbmnt

= dbmon

db2

adm

sap/sapr3 /sapsr3

sap/sapr3 /sapsr3

Authoritypermitted by

group membership

RelatedDBM CFGparameter

AssignedOS user group

(by SAPinst)

RelatedOS user

= group member

not explicitlyused by SAP

usedup to NW

7.01

usedas of NW

7.02

DB2 authorization can be broken down into two categories: privileges and authorities. A privilege defines a single permission for a user or group (or special group PUBLIC), which enables users to create or access

database objects (such as databases, schemas, tablespaces, tables, views, indexes). Privileges are stored in the database catalog.Because SAP ABAP systems provide their own mechanisms for controlling access to data, privileges on single tables etc. are not used by default in AS ABAP environments.

Authorities provide a method of grouping privileges and control over database manager operations. Database-specific authorities are stored in the database catalog; system authorities are associated with group membership, and the group names that are associated with the authority levels are stored in the database manager configuration file for a given instance.

You can list the authorities of to the logged-in user by issuing the command:db2 get authorizations

Note: As of DB2 V9.7, the GET AUTHORIZATION command functionality is discontinued. To retrieve authorities information for an authorization ID, use the AUTH_LIST_AUTHORITIES_FOR_AUTHID table function instead.

Direct authorities are those granted by a "db2 grant " command. Indirect authorities have been permitted implicitly by a group membership.

The SAP installation tool only grants a few direct authorities to the users created during installation (e.g. the database-specific authority DBADM for user adm). Most of the administrative authorities are permitted by a group membership.

The four system-level authorities (granted by group membership) are: SYSADM (system administrator) authority

The SYSADM (system administrator) authority provides control over all the resources created and maintained by the database manager. The system administrator possesses all the authorities of SYSCTRL, SYSMAINT, and SYSMON authority. The user who has SYSADM authority is responsible both for controlling the database manager, and for ensuring the safety and integrity of the data.

SYSCTRL authorityThe SYSCTRL authority provides control over operations that affect system resources. For example, a user with SYSCTRL authority can create, update, start, stop, or drop a database. This user can also start or stop an instance, but cannot access table data. Users with SYSCTRL authority also have SYSMON authority.

SYSMAINT authorityThe SYSMAINT authority provides the authority required to perform maintenance operations on all databases associated with an instance. A user with SYSMAINT authority can update the database configuration, backup a database or table space, restore an existing database, and monitor a database. Like SYSCTRL, SYSMAINT does not provide access to table data. Users with SYSMAINT authority also have SYSMON authority.

SYSMON (system monitor) authorityThe SYSMON (system monitor) authority provides the authority required to use the database system monitor.

The SAP database connect user sap possesses its authority to access all application data by its ownership of the objects (schema ownership). SYSMAINT (or SYSMON) authority does not permit access to database objects.

SAP installations based on DB2 versions as of DB2 V9.7 also apply SECADM authority to the DB2 administrator user db2.Take this into account if you perform a homogeneous system copy using a new DBSID (see SAP Note 1386320).

DB2 also provides the highly sophisticated method of label-based access control (LBAC). LBAC uses security policies to let the security administrator decide exactly who has write access and who has read access to individual rows and individual columns. LBAC is not yet used by SAP.

39


DB2 Authentication in SAP Environments (Java)

Connect user in an SAP Java environment is sapdb

Java connect user information is stored in file SecStore.propertiesin directory /usr/sap//global

/security/data(encrypted)

SecStore.propertiescontent can only be read and modified by the SAP Config Tool

After a password change on OS level, you must perform the respective update in the Secure Store using the Config Tool

40


DB2 Authorization: Details

SYSCAT. DBAUTHSYSCAT. COLAUTHSYSCAT. INDEXAUTHSYSCAT. LIBRARYAUTHSYSCAT. MODULEAUTHSYSCAT. PACKAGEAUTHSYSCAT. PASSTHRUAUTHSYSCAT. ROLEAUTH

Administrative Authorizations for Current User

Direct SYSADM authority = NODirect SYSCTRL authority = NODirect SYSMAINT authority = NODirect DBADM authority = YESDirect CREATETAB authority = NODirect BINDADD authority = NODirect CONNECT authority = NODirect CREATE_NOT_FENC authority = NODirect IMPLICIT_SCHEMA authority = NODirect LOAD authority = NODirect QUIESCE_CONNECT authority = NODirect CREATE_EXTERNAL_ROUTINE authority = NODirect SYSMON authority = NO

Indirect SYSADM authority = NOIndirect SYSCTRL authority = YESIndirect SYSMAINT authority = NOIndirect DBADM authority = NOIndirect CREATETAB authority = NOIndirect BINDADD authority = NOIndirect CONNECT authority = NOIndirect CREATE_NOT_FENC authority = NOIndirect IMPLICIT_SCHEMA authority = NOIndirect LOAD authority = NOIndirect QUIESCE_CONNECT authority = NOIndirect CREATE_EXTERNAL_ROUTINE authority = NOIndirect SYSMON authority = NO

SYSCAT. ROUTINEAUTHSYSCAT. SCHEMAAUTHSYSCAT. SEQUENCEAUTHSYSCAT. TABAUTHSYSCAT. TBSPACEAUTHSYSCAT. VARIABLEAUTHSYSCAT. WORKLOADAUTHSYSCAT. XSROBJECTAUTH

Example:db2prd:> db2 "select * from syscat.dbauth"

You can list authorities granted / assigned to a certain user. Example:prdadm:> db2 get authorizations

Most privileges on database objects areimplicitly permitted by schema ownership:

sap (ABAP connect user) orsapdb (Java connect user)

own all SAP tables, indexes, and views

Privileges are stored in DB2 catalog tables(0 n entries for each database object):

Direct authorities are those granted by a "db2 grant " command. Indirect authorities have been permitted implicitly by a group membership.

The SAP database connect user sap / sapdb creates all ABAP / Java database objects under its user name(as schema name). sap / sapdb possesses the authority to access all application data by its schema ownership.

Note: As of DB2 V9.7, the GET AUTHORIZATION command functionality is discontinued. To retrieve authorities information for an authorization ID, use the AUTH_LIST_AUTHORITIES_FOR_AUTHID table function instead.

For more information about the SECADM authority and related actions during a homogeneous system copy as of DB2 V9.7, see SAP Note 1386320.

41


Role-Based Security and Separation of Duties

Role-Based Security Concept for Database Users Optionally Available as of Enhancement Package 3

of SAP NetWeaver 7.0 on DB2 for LUW 9.7

Separationof Duties

Change Tracking Separation of Duties Remote Monitoring

DB

Bob Eva Tin

DB Admin. Users DB Monitoring User /DB Admin. User

Tracking

BusinessData

Monitor.Data etc.

SAP Solution ManagerUsers

Remote DB

RestrictedAuthority

NamedUsers

Bob Eva

SAP introduces an new role-based security concept for database users on DB2 for LUW 9.7 in Enhancement Package 3 of SAP NetWeaver 7.0.The "Separation of Duties" concept is an additional option for customers with distributed administrative responsibilities.

Role-Based Security Concept The new role-based concept provides different roles for monitoring and administration. These roles can be used to

restrict the user privileges according to the organizational tasks. No individual person holds more privileges than required.

The roles are:SAPAPP access to business data for the connect user sap or sapdbSAPTOOLS database administrator privileges for the DB administrator db2 or named DB admin usersSAPMON authorities to access the SAP monitoring infrastructure for DBA Cockpit and to perform lifecycle management on the SAP monitoring infrastructure for technical monitoring users

Instead of GRANTing individual authorities to a single administrator user during installation (SAP default method), the new SAPTOOLS role is created. This role is automatically assigned to the database administrator during the installation or you assign the role to your (named) administrator users afterwards.

Role SAPMON is included in SAPAPP and SAPTOOLS (because SAP ships DBA Cockpit as part of all SAP NetWeaverbased systems and both the applications and the administrators require monitoring information).

Change Tracking In an SAP system you have a single administrator user by default (DB2 administrator db2, SAP administrator

adm). If all database administrators share the default technical account and password, it is impossible to track the changes or activities of the individual administrators.

With individual administrator users, individual tracking of administrative activities is ensured. Separation of Duties

In a standard SAP scenario, database administrators hold the (DB2) DATA ACCESS authority and therefore they can access the data of all tables. "Separation of Duties" means the removal of DATA ACCESS authority from all users.

In this scenario, the business application role SAPAPP still implies access to the business data due to the ownership of the tables (schema ownership). Roles SAPTOOLS and SAPMON only permit access to monitoring interfaces and performance history tables. This way, administrators can perform their duties without having access to business data.

Restricted Remote Monitoring In SAP Solution Manager, remote database connections are used to manage the databases in the system landscape. With SAP Solution Manager 7.1 SP3, the new authorization object S_DBCON is available. Only database administrators

with the authorizations of this authorization object are able to access remote databases for monitoring. The S_DBCON authorization object can be used to manage authorization for each database connection individually for each user.

The S_DBCON authorization object provides another security layer in addition to the role-based security concept and the separation of duties.

In sum, you can combine the S_DBCON authorization object, the role-based security, and the separation of duties as follows:

The S_DBCON authorization object to restrict access to remote databases The SAPTOOLS and SAPMON roles to restrict user privileges on the database according to organizational tasks The separation of duties to ensure that users on your SAP Solution Manager cannot read business data using

the remote database connection

42


Role-Based Security and SAP Solution Manager

SAPTOOLS and S_DBCON (SAP Default Setup) SAPMON and S_DBCON Separation of duties, SAPTOOLS and S_DBCON Separation of duties, SAPMON and S_DBCON

SolutionManager

AuthorizationScenarios

SAP Managed System SAP Solution Manager 7.1

DBA Cockpit

History-Based Back-End

DBA Cockpit

History-Based Back-End

SAP S_DBCON Authorities

DB

DB2 Authorities (Roles)

sap

db2(Role SAPMON / SAPTOOLS)

db2

SAPAPP, SAPTOOLS, SAPMON

The S_DBCON authorization object protects the DBA Cockpit, especially in your SAP Solution Manager system. Possible authorization scenarios are:

SAPTOOLS and S_DBCON (SAP Default Setup) You use a database connection user with SAPTOOLS authorization to enable monitoring and administration. Additionally, you can use the SAP S_DBCON authorization concept to assign the monitoring and/or

administration authorities per remote database to different users on your SAP Solution Manager 7.1 SP3 (or higher). This enables the highest flexibility in the separation of the authorities for various users.

SAPMON and S_DBCON The users specified in the remote database connections in your SAP Solution Manager have SAPMON

authorization only. The functionality of your Solution Manager is then automatically restricted to pure monitoring. This applies to all

users in the Solution Manager system. You can also restrict the monitoring authorizations with S_DBCON individually. Then, you cannot use

administrative functions in your DBA Cockpit. Separation of duties, SAPTOOLS and S_DBCON

In this scenario, you have database connections in your SAP Solution Manager which can be used for monitoring and administration.

Additionally, you can use the SAP S_DBCON authorization concept to assign the monitoring and/or administration authorities per remote database to different users on your SAP Solution Manager.

Due to separation of duties, no user on your Solution Manager can read business data using the remote database connection.

Separation of duties, SAPMON and S_DBCON The users specified in the remote database connections in your SAP Solution Manager have SAPMON

authorization only. The functionality of the SAP Solution Manager is then automatically restricted to pure monitoring. This applies to

all users in the Solution Manager system. You can still restrict the monitoring authorizations with S_DBCON individually. You cannot use administrative

functions in your DBA Cockpit. Due to separation of duties, no user on your SAP Solution Manager can read business data using the remote

database connection.

43


Role-Based Security Activation

System withUser-Specific

GRANTs(Traditional Setup)

System UsingDatabase Roles

(SAPTOOLS,SAPMON)

System UsingDatabase Rolesand Separation

of Duties

db6_update_db -enable_roles

db6_update_db -activate_sod

db6_update_db -deactivate_sod

(no return)

Status B also reachedby new SAP installations as of

EHP3 of SAP NetWeaver 7.0

AA

BB

CC

DATA ACCESS authoritymust be removed manually

from SAP default users

IncludingDatabase Role

SAPAPP

SAP provides the db6_update_db.[sh|bat] tool to change the authorization concept. If you just execute the db6_update_db tool (for example after a DB2 version upgrade), it does not change the authorization

concept. It always enforces / repairs the concept the database is configured for (traditional system with user specific GRANTs / authorizations concept based on database roles).

Using specific options of the db6_update_db tool, you can deliberately change the database authority concept: Enable Database Roles using the -enable_roles option:

It creates the new database roles and changes the GRANTs to the new database roles. It also assigns the database roles to the users. There is no way back to the user-specific GRANTs system.

Enable Separation of Duties using the -activate_sod option:The -enable_roles action is always (automatically) executed before the separation of duties activation since separation of duties relies on the database roles concept.

Disable Separation of Duties using the -deactivate_sod option:As result, the database uses still the database roles concepts but not the separation of duties concept.

All new SAP installations starting with Enhancement Package 3 for SAP NetWeaver 7.0 enable the new role-based security concept.This means that SAPINST already creates the roles and does not perform single user GRANTs anymore. It also assigns the SAP default users to their appropriate database role.The same can be done using the db6_update_db script after an SAP system upgrade.In both ways, the removal of DATA ACCESS is not done by default. This is an explicit step the customer has to do manually. This requires an additional user with SECADM authority.

4444


Use CLP

1. Log on another terminal window as user db22. Find out the new db2 version, platform, fix pack level and installation path db2level3. List all applications running db2 list applications4. List all db2 commands db2 \?5. Get help text for a specific db2 command db2 \? get snapshot6. Get help text for an SQL error code db2 \? SQL1024

Use DBACOCKPIT

1. Log on SAP GUI 2. Go to transaction DBACOCKPIT3. Logon as BWUSER and click the Database N4S tab (top left)4. Navigate through some of the DBACOCKPIT menu items along the top and on the left5. List all running applications Performance -> Snapshots -> Applications

Exercise 1.1 Accessing DB2

All Unix User IDs have passw0rd as the passwordSAP System ID () is N4S (so db2 = db2n4s)SAP User BWUSER has also passw0rd

4545


1. Use CLP

1. Move to db2 terminal window2. Whats the current instance name (or instance owner)? echo $DB2INSTANCE3. Wheres the instance home directory? echo $INSTHOME4. Whats the database name? db2 list db directory5. Wheres the database directory?6. Whats the SAP schema? echo $dbs_db6_schema7. Whats under the directory /db2/?8. How to connect to database? db2 connect to 9. Whats the current kernel level? db2 "select * from sap.svers"10. How many tables in the entire database? db2 "select count(*) from syscat.tables where type='T'"11. How many tables belong to SAP ABAP stack? db2 "select count(*) from syscat.tables where

tabschema = 'SAP' and type='T'"12. Disconnect from the N4S database db2 connect reset

2. Use DBACOCKPIT

1. Find the largest tables from Space -> Tables and Indexes -> Top Space Consumers2. Execute the above SQL SELECT statements in Favorites -> SQL Command Line

Exercise 1.2 Database Objects

4646


1. Use CLP

1. Switch user adm2. Where is the password file for SAP users?3. Look at the file dscdb6.conf to see if this is the new type of encrypted file

cat /usr/sap/N4S/SYS/global/dscdb6.conf. Is there a third line with a timestamp?4. Whatre the instance level authorities, and who are assigned to them?

db2 get dbm cfg | grep GROUP5. Check the OS group definition cat /etc/group6. Whats the authentication type? db2 get dbm cfg | grep AUTHENTICATION2. Use DBACOCKPIT

Can you try to use DBACOCKPIT to find out the above information?Hint check DBM CFG parameters in:

Configuration -> Database Manager -> Security -> Groups

Exercise 1.3 Security

4747


1. Use CLP

1. List node directory db2 list node directory1. There is no NODE directory defined because this is a central (local) system

2. List database directory db2 list db directory3. Whats the setting of DB2COMM? db2set DB2COMM4. Whats the TCP/IP port number used by db2? db2 get dbm cfg | grep SVCENAME,

then grep for the service name in /etc/services5. Find out whether N4S system is using traditional DB2 client or DB2 CLI Driver, also check

the configuration information in db2cli.ini file.

2. Use DBACOCKPIT

Can you try to use DBACOCKPIT to find out some of the above information?Hint check Configuration -> Database Manager -> Network

Configuration -> Registry Variables -> DB2_WORKLOAD

Exercise 1.4 Communication

48


1 Basics Contents


Basics

DB2 Essentials



DB2 Configuration


49


DB2 EDUs Processes / Threads

Per Instance:db2sysc[s.exe]*

db2syscdb2tcpcmdb2ipccmdb2acd*

db2wdog*

Per Connection:

...

db2agentdb2agntp

...

Per Database:

db2loggrdb2logmgrdb2pfchrdb2pclnr

db2stmm

...

db2loggw

...

...

db2dlock

System ControllerProcess

Main System ControllerTCP/IP ListenerIPC ListenerAutonomic ComputingDaemon Processincl. Health Monitor

Watchdog Process(UNIX, Linux only)

db2fmp*

Coordinator AgentSubagents (optional)

Fenced Mode ProcessCLP Backend ProcessPWD Check Processes(UNIX, Linux only)

Log WriterLog ReaderLog File ManagerPrefetchersPage CleanersDeadlock DetectorSelf-TuningMemory Manager

...

*) These EDUs are processes,even in a thread-based concept

Displayed using:db2prd:> db2pd edusdb2prd:> db2_local_psanyone:> ps ef | grep db2X:\> db2stat (Windows)

db2bp*db2ckpwd* ...

DB2 processes and threads are called "engine dispatchable units" (EDUs). On UNIX and Linux up to and including DB2 V9.1, EDUs are processes. On Windows and on all other platforms as of DB2 V9.5, most of the EDUs are threads within the DB2 system controller process db2sysc

(db2syscs.exe on Windows). Exceptions are marked with an (*). The slide only shows an abstract of important DB2 EDUs. Short description of EDUs:

db2sysc[s.exe] core process of a DB2 instance; in a thread based concept, the db2sysc process contains all DB2 threads db2sysc main system controller EDU; handles critical DB2 server events db2tcpcm TCP/IP listener EDU (one per configured protocol); listening for TCP/IP connection requests db2ipccm IPC listener EDU (inter-process communication); listening for local clients' connection requests db2acd autonomic computing daemon process; hosts the health monitor, automatic maintenance utilities, and the administrative

task scheduler (formerly known as db2hmon) db2wdog watchdog process; monitors and handles abnormal EDU terminations on UNIX and Linux db2agent DB2 "worker" EDU; performs requests on behalf of an application; coordinator, if parallel subagents work on a request;

usually connected to a database (or idle, or attached to an instance) db2agntp subagent EDU; supporting a coordinator agent in partitioned database environments or with intra-partition parallelism

enabled db2fmp fenced mode process; executing fenced stored procedures and user-defined functions; might be a multi-threaded

process db2bp backend process of the command line processor (CLP); persistent background process of the CLP that holds a user's

connection to the database db2ckpwd authentication checker process; checking user ID and password against the operating system when an application

connects (on UNIX and Linux) db2loggw log writer EDU; writes log records from the log buffer to the current active log file db2loggr log reader EDU; reading from and manipulating log files to handle transaction processing (i.e. rollback) and recovery

(i.e. restart recovery, rollforward) db2logmgr log file manager EDU; managing log files (e.g. create, archive, retrieve) for a recoverable database db2pfchr prefetcher EDU; reading data and index information from storage into the buffer pool(s) on behalf of applications

(asynchronously, "read-ahead", performing big-block I/O) db2pclnr buffer pool page cleaner EDU; asynchronously writing changed ("dirty") pages from the buffer pool(s) back to storage db2dlock deadlock detector EDU; scanning the lock list for deadlock conditions, resolving them by choosing a victim transaction

and rolling it back db2stmm self-tuning memory manager (STMM) EDU; tuning database memory-related memory parts (dynamically)

For more information, see "The DB2 process model" in the DB2 information center and the DB2 V8.1 article "Everything You Wanted to Know About DB2 Universal Database Processes" in the IBM DB2 developerWorks(http://www.ibm.com/developerworks/data/library/techarticle/0304chong/0304chong.html).

50


DB2 EDUs Example DB2 V9.7 on UNIX, Linux

db2acd*db2wdog*

...

db2fmp*db2bp*

db2ckpwd*

db2loggrdb2loggr

db2logmgrdb2logmgr

db2pfchrdb2pfchr

db2pclnrdb2pclnr

db2stmmdb2stmm

...

db2loggwdb2loggw

...

...

db2dlockdb2dlock

db2sysc*

db2syscdb2sysc

db2tcpcmdb2tcpcm

db2ipccmdb2ipccm

db2agentdb2agent

db2agntpdb2agntp ...

...

...

On Windows and on all other platforms as of DB2 V9.5 most

of the DB2 EDUs are threads within the DB2 system controller

process db2sysc(db2syscs.exe on Windows).

*) These EDUs are processes,even in a thread-based concept

...

Displayed using:ps ef | grep db2

Displayed using:db2pd edus

...

51


DB2 Startup Processing

startsapScript

startdbScript

db2start

db2 activatedatabase

Inst

ance

Level

db2wdog

db2acd

db2syscdb2fmp

db2ipccmdb2tcpcmdb2sysc

# startsap db

startdb

# startsap r3

...

Work ProcessWork Process

Work Process

Con

nec

tLe

vel

db2agent

db2agentdb2agent

Dat

abas

eLe

veldb2loggr

db2logmgr

db2loggw

db2pfchr

db2pclnr

db2stmm

...

...

db2dlock

...

Dispatcher

initiatescontains

sapstart

11

22

33

SAP ABAP systems on UNIX / Linux are started by user adm using the SAP startup script startsap . The script checks the availability of database and SAP system and when required calls the SAP startup script for the

database: startdb . SAP's startdb script first starts the DB2 instance (also called database manager) using the db2start command.

The DB2 instance includes service EDUs like listeners, controllers, and monitoring EDUs. Afterwards, the DB2 database is activated using the following command:

db2 activate database This kind of database activation explicitly starts the database service EDUs including the log writer, log reader, log file manager, prefetchers, page cleaners etc.

When the startdb script has finished successfully, the startsap script continues (if requested) with the activation of the AS ABAP system by executing the respective startsap r3 section of the script. This calls the SAP instance startup program sapstart which brings up the SAP dispatcher (first disp+work process).

The SAP dispatcher himself forks the SAP work processes. The work processes connect to the database where they get assigned to a coordinator agent db2agent .

52


Memory Allocation During Startup Processing

Inst

ance

Level

db2wdog

db2acd

db2syscdb2fmp

db2ipccmdb2tcpcmdb2sysc

...

Con

nec

tLe

veldb2agent

db2agentdb2agent

Dat

abas

eLe

veldb2loggr

db2logmgr

db2loggw

db2pfchr

db2pclnr

db2stmm

...

...

db2dlock

...

11

22

33

Limit of overallDB2 memory usage:INSTANCE_MEMORY

InstanceRelatedParts

Database Shared Memory

(DATABASE_MEMORY)

AgentPrivateMemory

...

The maximum value of the overall DB2 memory usage is controlled by the DBM CFG parameter INSTANCE_MEMORY. When the DB2 instance is started, the per-instance memory, also known as database manager shared memory, is allocated.

Specifically instance-related memory parts are, for example, the monitor heap, the audit buffer, and the pool of FCM (fast communication manager) buffers.

As of DB2 V9.5, the INSTANCE_MEMORY limit also includes all other DB2 related memory areas: database shared memory, agent private memory, application global memory, and agent / local application shared memory.

When the DB2 database is activated or started, the per-database memory is allocated. The per-database memory is also called database shared memory or database global memory. The maximum size of the per-database memory can be controlled by the DB CFG parameter DATABASE_MEMORY. This memory is used concurrently by all applications of the database.

The most important memory areas that reside in the database shared memory are the database heap and buffer pool(s). The sizes of these memory areas are related to each other. Other memory areas are the lock list, the package cache, and the catalog cache.

When a db2agent EDU is allocated to an application, the agent will allocate its agent private memory. This memory contains memory heaps especially for application processing (e.g. sort heaps for agent / application private sorts).

Because large SAP database servers run many db2agent EDUs (note that the memory consumption is directly related to the number of connected applications), the per-agent memory consumption should not be underestimated.

53


DB2 Shutdown Processing

stopsapScript

stopdbScript

db2deactivatedatabase

db2stop Inst

ance

Level

Documents

DB2 Admin for SAP With ddbddExercises 20120810