DB2 Subsystem

Assign high Dispatching priority for DB2 started task. ssidMSTR and ssidDBRM. Move Critical Modules to LPA and VLF to reduce the search and load time. Ensure optimum block size for DB2 load libraries.

Bufferpool
Buffer pools are areas of virtual storage that temporarily store pages of table spaces or indexes. Maximum Bufferpool size is 1.6 GB Till V5, 10 32k and 50 4k Bufferpools Data is written back to DASD only when DB2 takes a check point or write threshold is reached If Hyper pool is available, data is moved to hyper pool temporarily.

Bufferpool Tuning
DB2 can handle larger buffer pool efficiently Larger buffer pool will result in higher HIT ratio which will reduce no of I/Os. If total BP size is more than real+expanded storage, oldest pages will be migrated to auxiliary storage and subsequent fetch to those pages will led to page fault. Larger BP will reduce the I/O contention for most frequently accessed DASD devices. Like Device containing catalogs, sort TS etc

Bufferpool Allocation Guidelines

Allocate separate BP for TS and IX. Allocate separate BP for frequently accessed and updated TS To improve the performance of sort-sensitive queries, use different BP for work work files Provide separate BP for big and frequently access TS

EDM POOL
EDM POOL contains DBD, SKCT, SKPT, AUTH CACHE for Plans not with CACHESIZE(0) and Skeleton for Dynamic SQLs if caching is enabled. During execution of application, DBDs for all databases in use needs to be in EDM pool and all plan and package also needs to be in EDM pool If Dynamic SQL caching is enabled, prepared SQL will reside in EDM pool and next time the same SQL need not be prepared.

EDM POOL
With allocation of CACHE for plan, you can reduce the processing time necessary to check user authorization. Generally DBD size will be 25% of EDM pool size More number of objects(TS,T,IX and RI) means larger DBD More SQLs in a plan means larger SKCT and SKPT

EDM POOL
If EDM POOL size is too small, it will result in increased I/O activity on db2 directories - DBD01, SCT01 and SPT01 Concurrency will be reduced as it can not accommodate all used DBD, SKPT, SKCT, CACHE for plan auth and dynamic SQLs To have improved performance, along with all used ones, most frequently used DBDs, SKPTs and SKCTs should reside in EDM POOL. EDM pool is not enough, error is sent to

Sort Pool
Sort Area is required for sorting application data before data is returned to the application process Sorting is performed using logical sort work file Logical sort work file is allocated in buffer Pool of the physical sort work file, created in DSNDB07 database Each sort can use maximum of 140 logical files and each user can use max of 255 logical files There can be many to many relationship between logical and physical sort files.

RID POOL
RID POOL IS REQUIRED FOR FOLLOWING PROCESSING - LIST PREFETCH, MULTIPLE INDEX SCAN and HYBRID JOIN RID POOL is also used when DB2 enforces unique keys while updating multiple rows Maximum RID POOL size is 1000MB and no RID POOL storage is allocated until and unless storage is actually needs If there is not enough RID pool available, SQL may revert to table space scan.

Storage Group Definition

Storage group is used to group the volumes, to be used by DB2 objects(TS and IX) The concurrently accessed big tables or partitions of a tables should be assigned different storage groups to minimize DASD contention during data access Try to allocate different storage groups for the tables to be recovered in parallel to speed up the recovery process minimizing contention wait time.

Database Definition
Design database to include objects in such a way that DBD size is not very high and no of database access by an application is less. Only TS,T,IX and RI contributes towards DBD size. And max no of objects in a database is 32767 Try to put all the objects accessed by concurrent applications in minimum number of databases. This will reduce I/O to bring the DBD to EDM pool.

Tablespace Definition
There are three types of TS - SIMPLE, SEGMENTED and PARTITIONED Tablespace is created in a database. One VSAM LDS DS is created for each simple or segmented TS and for each partition of a partitioned TS

Simple Tablespace
Simple TS facilitates rows from multiple tables in it to reside on same DB2 page. It is useful for smaller tables and for the tables, to be used by online applications as they do handle smaller amount of data. When pages are brought in demand to BP for one application, data for other tables is also brought which could be immediately used by another application. Should be very careful in using this type

Simple Tablespace
Disadvantages As rows are mixed in page, it takes more time to scan rows pertaining to a table in demand Holding a page level lock, will lock rows of other table. Even though a table is dropped or rows from a table is deleted, space could not be claimed until and unless REORG is performed on TS

Segmented tablespaces
More than one tables reside on same TS but each of them will have a discrete set of pages. Advantages : Locking a table or pages of table, does not affect other tables in the same TS When a table for TS is dropped , space could be claimed immediately without doing REORG even. Allows more than one table. Can help you avoid to reach max no of concurrent datasets open. Hence DCB area requirement is less

Segmented tablespace
Disadvantages : LOAD with REPLACE, RECOVERY, COPY and REORG operate on entire TS. So this could have negative impact on data availability.

Partitioned tablespace
Partition tablespace is for massive tables. DB2 V5, DB2 LARGE partitioned TS can have 254 partitions and each part can hold 4GB of data. So 1TB data per partitioned TS. Each partitioned table needs a clustering index on the partitioning key.

Partitioned tablespace
Advantages : Partitioned TS allows utility to work at part level. So availability of data is high If table size is more than 2GB, we need not break the tables. Partitioned TS can accommodate 1TB Big jobs could be broken into several jobs and each one of them will be working on a partition affecting other jobs Query parallelism works efficiently on partitioned TS

Partitioned tablespace
Advantages : It is good for Growing database Disadvantages : For each partition, a VSAM LDS will be created. Hence DB2 opens more datasets for partitioned table processing You much have a partitioning key and a clustering index during definition. So partition is created long before it is actually used.

PCTFREE/FREEPAGE
PCTFREE is to keep a certain percent of a page free and FREEPAGE is to keep certain percentage of a pages free Define TS with appropriate PCTFREE and FREEPAGE where lot of insertion occurs during days operation. As in general practice REORG is run during house keeping. Higher value may result wastage of space

CLOSE YES/NO
Specifies whether or not the data sets are eligible to be closed when the table space is not being used and the limit on the number of open data sets is reached. Define frequently accessed tablespace with CLOSE=NO to save open time of LDS datasets. Once max no of open datasets (DSMAX) is reached, DB2 abruptly will close 25% of open datasets. DSMAX value is 20,000.

COMPRESS YES/NO
COMPRESS YES will enable data compression and compression dictionary resides on TS. Compression will result in saving storage but data needs to be decompressed every time compressed data is fetched. Run DSN1COMP to find out compression effectiveness.

PRIQTY/SECQTY
Unit of allocation is in KB. DB2 will allocate as number of 4K and 32K pages. DB2 can not handle datasets which has gone beyond 119 extents REORG to convert secondary qty to primary qty.

Table Definition
Have the VARCHAR fields towards end of the table for performance reason if you have EDITPROC, VALIDPROC and FIELDPROC, make sure that they do not suffer from performance problem. In case mass insertion into table, it is better not to have any RI definition. It is better to handle that in application.

Index Definition
Use TYPE 2 index to have better concurrency Design the ordering of the columns in index as desired in the application Avoid sorting of big table defining appropriate index and sometime clustered index. Too many index on a table will slow down the performance as it has to update so many indexes and build them. Clustered index will result in less number of locks

DB2 Lock
LOCKSIZE is TS,T,PART,PAGE and ROW Bigger LOCKSIZE will yield better performance as CPU and Storage requirement are less. But concurrency will suffer Smaller LOCKSIZE will result better concurrency but suffer from performance So it is question of trade-off between concurrency and performance Use smaller LOCKSIZE (ROW-level) for online application

DB2 Lock
Use bigger LOCKSIZE (PAGE -level) for BATCH application LOCKSIZE could be explicitly specified during TS/IX creation or left to DB2 to decide using LOCKSIZE ANY For partition level locking, use LOCKPART YES during creation of TS LOCKSIZE is decided by DB2, lock escalation /Demotion may occur.

DB2 Lock Modes

For simple tablespace, Table level locking is not possible as rows from multiple tables will be together. Modes of lock for ROW and PAGE level locking - S (Share), U (Update) and X (Exclusive) Modes of lock for Tablespace and Tables - IS(Intent Share), IX(Intent Exclusive), S(Share), U(Update), SIX(Share with Intent exclusive) and X(Exclusive) When a row/page is locked, TS/T/PART is also

DB2 Lock Escalation

If ROW/PAGE lock is used and maximum number of locks in TS reaches LOCKMAX, DB2 will escalate the lock to TABLE level for segmented TS and TS level lock for nonsegmented tablespace Use LOCKMAX as 0 to stop lock escalation. It is used by DB2 to balance between concurrency and performance LOCKS PER USER(Installation parameter) should be big enough.

DB2 Lock Duration

For TS/T/PART table Locking, it is controlled by BIND parameter ACQUIRE and RELEASE. For ROW/PAGE level locking, DB2 acquires lock only when it is needed and never held after the commit point.

Glossary
BP DASD DBD DS IX LDS LPA RI RID SKCT SKPT SQL T TS VLF VSAM Buffer Pool Direct Access Storage Device Database Descriptor Dataset Index Linear VSAM Dataset Link Package Area Referential Integrity Row Identifier Skeleton Cursor Table Skeleton Package Table Structured Query Language Table Tablespace Virtual Look aside Facility Virtual Storage Access Method