Introduction to DB2 Architecture and Components

 DB2 is IBM’s Relational Database Management System for MVS
operating system.
 DB2 can access other sub systems like IMS, CICS transaction
managers, or by TSO for batch jobs.
 DB2 uses a centralized operational Data Dictionary.
Introduction to DB2

 The data definition, data control and data manipulation,
authorizations are performed by the Structured Query Language
(SQL).
 DB2 provides full data security, data integrity and data recovery
functions.
 DB2 is designed to be fast, efficient and easy to use.
 One of the main objectives of DB2 is to reduce application design
and development efforts.
 DB2 runs on 5 different Address Spaces.
Introduction to DB2

DB2 subsystem comprises of 5 address spaces namely
 DSNMSTR
 DSNDBM1
 IRLMPROC
 DSNDIST
 DSNSPAS
Address Spaces

DSNMSTR (System Services):
 controls to other to other MVS sub-systems like IMS, CICS, TSO.
 supports system startup, operation, communication and
shutdown.
 collects system statistics for performance, auditing and
accounting.
 performs commit, rollback, checkpoint, maintaining recovery log.
DB2 Address Spaces

DSNDBM1 (Database Services) :
 supports definition, updation and retrieval of DB2 Data.
IRLMPROC (Locking Services):
 to control concurrent access to data and to maintain data
integrity, provided by DB2 address space IRLM.
DB2 Address Spaces

DSNDIST (Database Services) :
 takes care of remote access database located at different places
and subsystems.
DSNSPAS
 it provides an isolated environment in which to execute stored
procedures.
DB2 Components

DB2 Objects
There are two types of elements or objects
Data Objects
Created, accessed and manipulated by the
users, but maintained by DB2
System Objects
Controlled and used by DB2

DB2 Objects
Data Objects
 Tables
 Indexes
 Views
 Tablespaces
 Databases
 Storage Groups
System Objects
 DB2 Catalog
 DB2 Directory
 Active & Archive Logs
 Boot Strap Data Set
 Buffer Pools
 Locks

Storage Groups:
A DB2 storage group is a set of volumes on DASD, the
volumes hold the data sets in which tables and indexes are
actually stored. The description of a storage group names
the group and identifies its volumes and the VSAM catalog
that records the data sets.
Default storage group SYSDEFLT.
Data Objects

Database:
A Set of DB2 objects (tables, indexes, tablespaces & views)
One database for one application recommended
Default Database is DSNDB04
A single database can contain all the data associated with
one application or with a group of related applications.

Tablespaces:
A table space can consist of a number of VSAM data sets.
Data sets are VSAM LDS.
Table spaces are divided into equal-sized units, called pages,
You can specify page size for the data; the default page size
is 4 KB.
Depending on the type of data you are going to store
determine the table space type. There are three types of
table space.
simple, segmented or partitioned

Table Space - Simple
A simple table space can contain more than one table, rows
of different tables can get mixed up in a single page.
concurrency will be affected due to mixing of rows from
different tables.
space occupied by deleted objects does not become usable
immediately.

Table space - Segmented
With segmented table spaces, the available space is divided
into groups of pages called segments, each the same size.
Each segment contains rows from only one table. To search
all the rows for one table, it is not necessary to scan the
entire table space, but only the segments that contain that
table.

Table Space - Partitioned
Primarily used for very large table. Numpart parameter
specifies the number of partitions.
Different partitions can be stored on different storage groups
of efficient access.
With a partitioned table space, the available space is divided
into separate units of storage called partitions.
One table can be stored in a partitioned table space, number
of partitions can be between 1 to 254).

Tables
Tables are logical structures maintained by DB2. Tables are made up of
columns and rows. Some types of tables include:
 Parent Table
 Dependent Table

Data Objects-Index
An index is an ordered set of pointers to the data in a DB2 table.
The index is stored separately in index space.
Each index is based on the values of data in one or more columns of a table.
After creating an index, DB2 maintains the index.

Data Objects - View
It is a virtual table defined by the select statement.
A view can include all or some of the columns from one or more base tables,
can also be based on other views or on a combination of views and tables.

DB2 Catalog (DSNDB06)
The DB2 catalog consists of tables of data about everything defined to
the DB2 system, including table spaces, indexes, tables, copies of table
spaces and indexes, storage groups, and so forth.
When an object is created, altered or dropped, a row is inserted, updated
or deleted in the Catalog.

Directory (DSNDB01)
The DB2 directory contains information used by DB2 during normal
operation, this data cannot be accessed using SQL.
It contains information required to start DB2, and their activities and utilities
in the DB2 environment.

Directory (DSNDB01)
The directory consists of a set of DB2 tables stored in five table spaces
namely
1.Skeleton Cursor Tablespace (SKCT)
2.Skeleton Package Table space (SKPT)
3.SYSLGRNX
4.SYSUTILX
5.DBD01

Active & Archive Logs
 DB2 records all data changes and significant events in active logs as
they occur. In case of failure, it uses this data to recover the lost
information.
 When the active log is full, DB2 copies the contents of the active log
to a DASD or magnetic tape data set called archive logs.

Buffer Pools
 Buffer Pools are areas of virtual storage which DB2 uses during
execution of an application program or an interface SQL, to
temporarily store pages of tablespace

Bootstrap Dataset
 Contains inventory of all active and archive log datasets.
 During installation of DB2, two BSDS datasets are
created, kept in different volumes.

Locks
 DB2 guarantees data integrity by using several locking
mechanisms. These strategies permits multiple users
from multiple environments to access and modify data
concurrently without lose of data integrity.
 DB2 supports locking at three levels. Table Space Level,
Table Level and Page Level.
 DB2 uses locks to control concurrency & prevent
inconsistent data.
 IRLMPROC will take care of the locking services

Create stogroup HEXSG
volumes (SMS001,SMS002)
vcat DSN610;
Storage Groups

Create database HEXDB
stogroup HEXSG
buffer pool BP01;
Database

CREATE TABLESPACE HEXTS
IN HEXDB
USING STOGROUP HEXSG
PRIQTY 10
SECQTY 10
NUMPARTS/SEGSIZE
LOCK SIZE row/page/table
PCTFREE n
BUFFERPOOL BP01;
Table Space

Create table employee
(eno integer,
ename varchar(10))
in database.tablespace;
Tables

CREATE INDEX IDX
ON EMPLOYEE (EMPNO ASC);
Index

CREATE VIEW VDEPT AS
SELECT DEPTNO,DEPTNAME,MGRNO
FROM userid.DEPT;
View

 An alias is a substitute for the three-part name of a table or view.
 It is a pointer to another table.
 The alias can be up to 18 characters long, qualified by an owner ID.
 The table could be located on a remote site.
CREATE ALIAS TESTTAB FOR locationname.userid.EMP;
Alias

An alternative name for a table or view.
Synonyms can only be used to refer to objects at the subsystem in which
the synonym is defined.
Eg : CREATE SYNONYM DEPT FOR userid.DEPT;
Synonym

 Database Design
 SPUFI
 SQL
 Referential Integrity
 DB2, DSN Commands
 Bind
 DCLGEN

Structured Query Language (SQL)
SQL is a high level language that provides a greater degree of abstraction
than procedural languages.
It is fashioned so that the programmer can specify what data is needed
but need not specify how to retrieve it.

Ways of executing SQL's
Foreground
Using SQL Processor Using File Input (SPUFI)
Using Query Management Facility (QMF)
Background
By embedding them in application programs written in C, Cobol, Fortran,
Assembler, PL/1, etc.

Data Definition Language (DDL)
DDL - Data Definition Language statements to define or create the
objects of a database.
CREATE, ALTER, DROP

Data Manipulation Language (DML)
DML - Data Manipulation Language statements to manipulate data in
tables.
SELECT, INSERT, DELETE, UPDATE

Data Control Language (DCL)
DCL - Data Control Language statements to GRANT and REVOKE
authorization to user resources.

Referential Integrity Rules
Referential Integrity defines the relationships among different columns
and tables in a relational database.
It is called referential integrity because the values in one column or set of
columns must match the values in a related column or set of columns.
A mechanism that ensures data integrity between tables related by
Primary & Foreign Keys

Insert Rules
When inserting a row with the foreign key, DB2 checks the values of
the foreign key columns against the value of the primary key columns
in the parent table.
A new Primary Key can be inserted as long as it is unique.

Update Rules
When updating foreign key values DB2 performs same checks as when
it is inserting a row with a foreign key.

Delete Rules
Cascade: When a row of the parent table is deleted, any related rows in the
dependent table are also deleted.
Restrict: Rows of parent table that have dependent rows cannot be deleted
Set Null: When a row of a parent is deleted, the corresponding values of
the foreign key in any dependent rows are set to null.

Create Table (PARENT):
CREATE TABLE EMPTAB (EMPNO INTEGER PRIMARY KEY NOT NULL
EMPNAME CHAR(25) NOT NULL
DESIG CHAR(25) NOT NULL
SALARY DECIMAL(7,2)
DOB DATE NOT NULL
IN HEXDB.HEXTS
Create Table (CHILD):
CREATE TABLE HEXCHD (DNO NTEGER PRIMARY KEY NOT NULL,
ENAME CHAR(15),
EMPNO INTEGER , FOREIGN KEY
(ENO) REFERENCES EMPTAB ON DELETE CASCADE)
IN HEXDB.HEXTS;

Preparation Steps
SOURCE
DB2 PRECOMPILE SQLNON SQL
COMPILE & LNKEDIT
DB2 BIND
LOAD MOD PLAN
CATALOG
* *
* *
* =TIMESTAMP
DBRM

DB2 Precompile Comments
Separates SQL from Non-SQL (Database Request Module)
Checks for errors
Timestamps both outputs

BIND Comments
Checks for errors, using DB2 catalog
Checks authorization
Develops Access strategy for each statement
Stores strategies as plan

Pre-compiler Functions:
Program used: DSNHPC
INPUT  EMBEDDED SQL PROGRAM
OUTPUT
Modified source
DBRMLIB – Database Request Module

Compile
Program Used: IGYCRCTL
INPUT  Modified Source Program; OUTPUT  OBJ Module

Link Edit
Program Used: IEWL
INPUT  OBJ Module; OUTPUT  Load Module
Process:
 The executable load module is produced
 Places the timestamp written from the precompiler step in the
load module.

Bind
Program Used: IKJEFT01
INPUT  DBRM LIB produced in precompiler step
OUTPUT  PLAN

Function: Reads the SQL statements from DBRMs and produces
a mechanism to access data from tables.
Parameters given while binding:
1. Owner, Qualifier
2. Action (REPLACE/ADD)
3. Isolation (CS/RR)
4. Acquire (USE/DEALLOCATE)
5. Release (COMMIT/DEALLOCATE)
6. Validate (BIND/RUN)
7. Explain
8. Flag.

Owner:
Name of the owner who created the PLAN
Qualifier:
Name where the table reside
Action:
Add or Replace the existing plan
Isolation:
This determines the mode of page locking implemented by the
programs as it runs.

CS – Cursor Stability:
Releases the page locks as soon as another page is accessed
or an COMMIT is issued. Improves concurrency.
RR – Repeatable Read (DEFAULT):
Releases the page locks only when a COMMIT is issued.

Acquire & Release Options:
These options of BIND or REBIND are used to specify when
DB2 is to lock the tables or tablespaces and when to release.
Acquire (Allocate)/Release (Deallocate)
This option avoids deadlocks by locking the resources at the
beginning. This option is opted when efficiency is more
important than concurrency.

Acquire (Use)/Release (Deallocate)
The object is locked only when it is needed while running and
unlocked only when the plan terminates.
Acquire (Use)/Release (Commit)
A table or tablespace is locked only when needed. The lock is
released when a COMMIT or ROLLBACK statement is issued or
the application process terminates. This can increase the
frequency of the deadlocks.

Validate:
Method of checking for the existence and validity for DB2 access
tables and authorization
Bind:
Validates at Bind time; Run – Validates at run time.
Flag:
Returns informational, warning, error and completion messages.

Bind
Bind reads SQL statements from DBRM s and produces a
method to access data as directed by the SQL statements being
bound.
It stores this access method as Plan

Two types of Binds –
BIND PLAN, BIND PACKAGE

BIND PACKAGE accepts a DBRM as input and produces a
SINGLE package.
A package is not executable. Packages should be bound into a
plan before executing.
Output of BIND PLAN is the application plan containing the
executable logic giving the access path to DB2 data.
BIND also performs Syntax checking of SQL statements,
Checking of the DB2 table and column catalog Information,
Authorization Validation.

Compile & Link Edit
• Modified source program produced by the DB2 pre-compiler
is the input for COBOL compiler.
 Compiled source code is given as input to Linkage editor.
 Linkage editor produces the executable load module.
 Appropriate DB2 host language interface module must be
included in the link-edit step.

Running a DB2 Program
 Program preparation steps will produce two separate physical
components- DB2 Plan, Link-Edited Load Module.
 To run an Application program containing SQL statements, the
name of the Plan should be specified.
 At execution time, DB2 checks for the compatibility of the Plan
and the load module by comparing the TIMESTAMP.
 DB2 programs can be executed in
 Batch / TSO, Using Call Attach Facility, CICS

Source Program
Modified Source
Non-SQL
Object Program
Link Edit
Compilation
Load Module
DB2 Precompiler or
Host-Language
Compiler
DBRM
Bind PackageDB2 Catalog Bind Plan
Plan
SQL

DB2 Address Spaces
MVS
DSNMSTR DSNDBM1 IRLMPROC
DB2 DB2 DB2
starts starts
or
connects
System Services Data Base Services Locking Services
BSDS LOG CAT DIR

DSNMSTR (System Services):
 DB2 cannot start unless the system services address space
DSNMSTR is able to allocate the DB2 Boot Strap Data Set
(BSDS) and all of the active log datasets.
 supports system startup, operation, communication and
shutdown.
 collects system statistics for performance, auditing and
accounting.
DB2 Address Spaces

DSNDBM1 (Database Services) :
 Supports definition, updation and retrieval of DB2 Data.
 Entire database services are taken care by this address
space
IRLMPROC (Locking Services):
 to control concurrent access to data and to maintain data
integrity, provided by DB2 address space IRLM.
DB2 Address Spaces

DSNDIST (Database Services) :
 takes care of remote access database located at different
places and subsystems.
DSNSPAS
 it provides an isolated environment in which to execute
stored procedures.
DB2 Address spaces

DB2 Address space Functions
System Service
Address space
==============
Create and maintain
connections
Logging to
active/archive logs
BSDS Processing
Accounting/Stats/
performance traces
Startup/shutdown/
Checkpointing/recov
ery
Database Service
Address space
==============
Data space
management
Relational
management
Buffer management
Locking via IRLM
IRLM
Address space
==============
Locking Services
Data Consistency
Data Integrity

DB2 System Objects
 DB2 Catalog
 DB2 Directory
 Active & Archive Logs
 Boot Strap Data Set
 Buffer Pools
 Locks

32K ROWS
DB2 Directory & Catalog Relationships
DB2
DIRECTORY
DB2
CATALOG
DB2
TEMP. DB
DSNDB01 DSNDB06 DSNDB07
DIRECTORY
TABLES
CATALOG
TABLES
4K ROWS
Every database objects (including the catalog and directory objects) is
described in the catalog and directory database.
DSNDB04 is the default database. It is where objects will reside if their creator
doesn’t explicitly name another database.

The DB2 catalog consists of tables of data about everything
defined to the DB2 system, including table spaces, indexes,
tables, copies of table spaces and indexes, storage groups, and so
forth.
The default catalog database is DSNDB06
When an object is created, altered or dropped, a row is inserted,
updated or deleted in the catalog tables.

To record the name of the structure, its owner, its creator, its type
( alias, table or view ), the name of its table space, and the name
of its database, DB2 inserts a row into the catalog table
SYSIBM.SYSTABLES.
To record the name of the table to which the column belongs, its
length, its data type and its sequence number in the table. DB2
inserts rows into SYSIBM.SYSCOLUMNS for each column of the
table.

To record that the owner of the table has all privileges on the
table, DB2 inserts a row into table SYSIBM.SYSTABAUTH.
During BIND, the new plan will reside in the directory and be
described in the catalog

Directory (DSNDB01)
The DB2 directory contains information used by DB2 during
normal operation, this data cannot be accessed using SQL.
Default directory database : DSNDB01
It contains information required to start DB2, and their
activities and utilities in the DB2 environment.

Directory (DSNDB01)
The directory consists of a set of DB2 tables stored in five table
spaces namely
1.Skeleton Cursor Tablespace (SKCT)
2.Skeleton Package Table space (SKPT)
3.SYSLGRNX
4.SYSUTILX
5.DBD01

Directory (DSNDB01)
1.Skeleton Cursor Tablespace (SKCT) : Is the Skeleton cursor
tablespace , which contains the internal form of SQL
statements contained in an application. When you bind a plan,
DB2 creates a skeleton cursor table in SCT02
2. Skeleton Package Table space (SKPT) : It is a Skeleton
Package tablespace, which is created when you bind a package

Directory (DSNDB01)
3. SYSLGRNX : Is the log range tablespace, used to track the
opening and closing of tablespaces, indexes or partitions. By
tracking this information and associating it with relative byte
address(RBAs) as contained in the DB2 log, Db2 can reduce
recovery time by reducing the amount of log that must be
scanned for a particular table space, indexes or partition.

Directory (DSNDB01)
4. SYSUTILX : Is the system utilities tablespace, which contains
a row for every utility job that is running. The row stays until
the utility is finished. If the utility terminates without
completing, DB2 uses the information in the row when you
restart the utility

Directory (DSNDB01)
5. DBD01 : Is the database descriptor (DBD) tablespace, which
contains internal information, called database (DBDs), about
the database existing within DB2.

Bootstrap Dataset
 BSDS is the table of content into the Db2 active and
archive logs, it describes the structure of the
physical log. It allows DB2 to determine which log
dataset to use to retrieve any particular log record.
 Contains inventory of all active and archive log
datasets.
 During installation of DB2, two BSDS datasets are
created, kept in different volumes.

 Identical pair (strongly recommended) of VSAM
KSDS
 Defined at DB2 installation and intialized by
CHANGE LOG INVENTORY utility
 Placement recommendation
- Separate volumes
Bootstrap Dataset
dsn610.BSDS01 dsn610.BSDS02

BSDS can be manually updated by CHANGE LOG
INVENTORY (DSNJU003) utility.
NEWLOG…
- Adds Active or Archive log data set
- Specify STARTRBA and ENDRBA when replacing an
existing dataset
DELETE…
- Deletes Active or Archive log data set
Updating the BSDS

CRESTART…
- Creates or Cancels a Conditional Restart Control
Record (CRCR).
It is very important that you use the CRESTART
parameter with the greatest caution.
Updating the BSDS

BSDS automatically updated by DB2.
- SYSTEM TIMESTAMP updated at:
- STOP DB2
- Active log dataset switch
- Log output buffer wrap
- Single BSDS mode (error condition)
BSDS Contents

- UTILITY TIMESTAMP updated at last Change Log
Inventory
- HIGHEST RBA WRITTEN (approximate)
- HIGHEST RBA OFFLOADED
DB2 uses the system time stamp to be sure that the
two copies of your BSDS are synchronized. DB2 simply
refuses to start if the system timestamps aren’t
identical in the two copies of the BSDS.
BSDS Contents

 DSNZPARM defines total size of Log Buffers
 BSDS describes active and archive log data sets
 Active log dataset reusable after offload to Archive
 DUAL logging recommended for both Active and Archive Logs
Physical Implementation
BOOTSTRAP
DATASETS
ACTIVE
LOGS
ARCHIVE
LOGS

Active & Archive Logs
 DB2 records all data changes and significant events
in active logs as they occur. In case of failure, it uses
this data to recover the lost information.
 When the active log is full, DB2 copies the contents of
the active log to a DASD or magnetic tape data set
called archive logs.

Buffer Pools
 Buffer Pools are areas of virtual storage which DB2
uses during execution of an application program or
an interface SQL, to temporarily store pages of
tablespace
 When an application program accesses a row of a
table, DB2 retrieves the page containing that row and
places the page in a buffer.

Buffer Pools
 If the needed data is already in a buffer, the
application program rows not have to wait for it to be
retrieved from DASD, significantly reducing the cost
of retrieving the page

Buffer Pools
 There are about 80 bufferpools available :
0 – 49 4 KB bufferpools
10 8 KB bufferpools

There are several options for where buffer pools reside:
Strictly within DB2's DBM1 primary address space. This
option offers the best performance, but limits the
amount of space to 1.6 GB.
Partly within the DBM1 address space, but using
extended storage (ESO hiperspace) for infrequently
updated data. Using extended storage expands the
storage capacity to 1.6 GB of primary and 8 GB of
extended storage. DB2 must move the data back into
the
DBM1 address space to address it.
Solely within an MVS data space. Data spaces greatly
expand capacity and are provided to position DB2 for
future S/390 processor enhancements that will

Buffer pools in data spaces: A buffer pool in a data
space can support up to 8 million buffers. For a 32 KB
buffer pool, that is 256 gigabytes of virtual storage.

Log Buffers
Output buffer = 40K – 4000K bytes (OUTBUFF=400)
Input buffer = 28K – 60K bytes (INBUFF=28)
……….
Each buffer page is 4K in size
Output buffers used for writing to the active log
Input buffers used for reading from the active or archive logs

Locks
A lock associate a DB2 resource with an application
Process in a way that affects how processes can access
the same resources
To preserve data integrity, application acquires locks
Implicitly, under DB2 control. It is not necessary for a
Process to request a lock explicitly to conceal
Uncommitted data. Therefore you need not do anything
about DB2 locks.

DSNZPARM
 DSNZPARM module provides parameters for DB2
execution
 - START DB2 PARM (DSNZPARM)
 To create DSNZPARM member, run installation job
DSNTIJUZ, Stop/Start DB2

DSN is the DB2 command processor and executes as a TSO
command processor.
BIND Builds an application package or plan
DCLGEN Produces declarations for tables or views
DSN Starts a DSN session
END Ends the DSN session
FREE Deletes an application package or plan
REBIND Updates an application package or plan
RUN Executes an application program
SPUFI Executes the SQL Processor Using File Input
DSN commands

-DISPLAY BUFFERPOOL
Displays information about the buffer pools
-DISPLAY DATABASE
Displays status information about DB2 databases
--START DATABASE
Makes the specified database available for use
-START DB2
Initializes the DB2 subsystem (can be issued only from an MVS
console)
DB2 commands

DB2 Utilities
Types of Utilities
- Online & Standalone Utilities
Control Card
Invoking JCL using procedure DSNUPROC

DB2 ONLINE UTILITIES
► MODIFY
► REORG
► LOAD
► QUIESCE

• Catalog Manipulation Utilities:
– MODIFY
– RUNSTATS
• Data Organization Utilities:
– LOAD
– REORG

MODIFY
MODIFY utility deletes records of specific date or
specific age from the SYSIBM.SYSCOPY catalog
table,SYSIBM.SYSLGRNX directory table and entries
from the DBD.

MODIFY
SYSIBM.SYSCOPY :
It is a DB2 catalog table which contains information needed
for recovery. DB2 makes an entry in this table whenever you
run Full Image/Incremental copies of the tablespace.

MODIFY
SYSIBM.SYSLGRNX :
This is a DB2 directory log range tablespace used to track the
opening and closing of tablespaces. By tracking this
information DB2 can reduce recovery time .

MODIFY
DBD (DataBase Descriptor) :
DBDs in the DB2 directory tablespace DBD01, which contains
the internal information about the databases existing within
DB2.

MODIFY- Output
MODIFY deletes image copy rows from
SYSIBM.SYSCOPY and SYSIBM.SYSLGRNX.

MODIFY-Authorization
IMAGCOPY privilege for the database to
run MODIFY
DBADM, DBCTRL, or DBMAINT authority
for the database
SYSCTRL or SYSADM authority

MODIFY-Example
For the table space HEXDBS.HEXTS1 delete all
SYSCOPY records older than 90 days
MODIFY RECOVERY
TABLESPACE HEXDBS.HEXTS1 DELETE AGE(90)

• REORG:
– Used when mass deletions occur.
– Retrieval of data due to “SELECT” is slow as
empty spaces occur. Hence, to avoid this REORG
is used
– It reorganizes the data for fast retrieval

REORG Tablespace
The REORG TABLESPACE utility reorganizes a
table space to improve access performance
and reclaim fragmented space

REORG-Output
Data gets organised in more efficient manner.
If the table space reorganised with COMPRESS
YES attribute, then the data is compressed
when reloaded.

REORG-Authorization
REORG privilege for the database
DBADM or DBCTRL authority for the
database
SYSCTRL / SYSADM authority

REORG-Example
REORG TABLESPACE
HEXDBS.HEXTS1
UNLOAD EXTERNAL
UNLDDN(SYSREC)
PUNCH DDN(SYSPUNCH)

REORG Tablespace
SYSPUNCH :
It contain structure of the tables in the tablespace
SYSREC :
It contain unloaded data

• LOAD:
– Used for mass insertions like duplicating data and its
structure
– Use LOAD to load one or more tables of a table spaces

• LOAD:
– LOAD loads records into the tables
– If the table space already contains data, you can
choose whether you want to add the new data to the
existing data or replace the existing data.
RESUME Yes – loads records into non empty TS
RESUME No – loads records into an empty TS

LOAD-Output
A loaded table space
A discard file of rejected records

LOAD-Authorization
Ownership of the table
LOAD privilege for the database
database

LOAD-Example
LOAD DATA
RESUME YES
INTO userid.Tablename
( DSPINDEX POSITION (2) CHAR(2),
LINENO POSITION (6) CHAR(2),
DSPLINE POSITION (80) CHAR(79) )

QUIESCE
Establishes a Quiesce point (the current log RBA) for a
table space or list of tablespaces and records it in the
SYSIBM.SYSCOPY Catalog Table.

QUIESCE
A successful QUIESCE improves the probability of
successful RECOVER or COPY, should be run
frequently between regular executions of COPY to
establish regular recovery points for future point in
time recovery.

QUIESCE-Authorization
IMAGCOPY privilege for the database
DBADM, DBCTRL, or DBMAINT authority for
the database

QUIESCE-Output
Writes changed pages from the table
spaces to DASD. The catalog table
SYSIBM.SYSCOPY records the current RBA
and the timestamp of the quiesce point.
A row with ICTYPE Q is inserted into
SYSCOPY for each table space quiesced.

QUIESCE-Example
QUIESCE
TABLESPACE HEXDBS.HEXTS
TABLESPACE HEXDBS.HEXTS1

RUNSTATS
RUNSTATS gathers summary information
about the characteristics of data in table
spaces, indexes, and partitions and records
this information in the DB2 catalog.
DB2 uses it to select access paths to data
during the bind process.

RUNSTATS-Authorization
STATS privilege for the database
DBADM, DBCTRL, or DBMAINT authority for
the database
SYSCTRL or SYSADM authority.

RUNSTATS-Output
RUNSTATS updates the DB2 catalog table with
table space or index space statistics or prints a
report. The information updated by RUNSTATS
is used by DB2 to select access paths to the
data.

RUNSTATS-Example
RUNSTATS TABLESPACE HEXDBS.HEXTS1

Data Consistency Utilities
- CHECK DATA
Backup Utilities
- FULL IMAGE COPY
- INCREMENTAL COPY
- MERGE COPY
- REPORT
- STOSPACE

DB2 UTILITIES
• There are two types of DB2 utilities:
–Online utilities
–Stand-alone utilities

DB2 UTILITIES
• DB2 online utilities run as standard MVS
batch jobs, and they require DB2 to be
running. They invoke DB2 control facility
services directly

DB2 UTILITIES
• The stand-alone utilities execute as batch
jobs independent of DB2. They can be
invoked only by means of MVS JCL

• Common DB2 online utilities include:
–COPY
–MERGECOPY
–LOAD
–CHECK
–MODIFY
–QUIESCE

• Common DB2 online utilities include:
–RUNSTATS
–REORG
–REPORT
–REPAIR
–STOSPACE
–RECOVER

DB2 STANDALONE UTILITIES
Common DB2 standalone utilities are:
– DSN1COPY
– DSNLOGP
– DSN1PRINT
– DSNJLOGF
– DSNJU003
– DSNJU004

• Utilities for Database Management:
– CHECK Utility: Checks for integrity and
consistency of data
• Consistency of data(Referential integrity)
• Check constraints are looked upon(Constraint
integrity)
• Consistency of indexes

CHECK DATA
• The CHECK utility checks table spaces for
violation of referential constraints, and also
test whether indexes are consistent with the
data they index.
• CHECK optionally deletes rows and violation
of referential constraints and copies them to
an exception table.

AUTHORIZATION
• STATS privilege for the database
• DBADM, DBCTRL or DBMAINT authority for
the database
• SYSCTRL or SYSADM authority

OUTPUT
• CHECK DATA optionally deletes rows that
violate referential or table check constraints.
• A row that violates one or more constraints is
copied, once to and exception table.
• On successful execution, CHECKDATA resets
the CHECK pending status.

EXAMPLE
CHECK DATA TABLESPACE HEXDB.HEXTS FOR
EXCEPTION IN MASTER USE EXMASTER IN
DETAIL USE EXDETAIL
DELETE YES

• Two types of Backup:
–Full Image Backup: Taking backup of all pages
in a table space, partition, or data set
–Incremental Image Backup: Taking backup of of
pages that have been modified since the last
use of the COPY utility

• Utilities for Backup include:
–COPY
–MERGECOPY

COPY
The COPY online utility creates image copies of
a table space.
These copies are used by the RECOVER
TABLESPACE utility when recovering a table
space to the most recent time or to a previous
time.

COPY - Authorization
DBADM, DBCTRL, or DBMAINT authority
for the data base

COPY-Output
- Image copy of Tablespace taken on
sequential data sets.
- Rows in the SYSIBM.SYSCOPY catalog table
that describe the image copy data sets
available to the RECOVER TABLESPACE
utility.

Before Running COPY
To run COPY Tablespace should not be
under
- Check Pending Status
- Recovery Pending Status

COPY- Example
Copy Tablespace DBname.Tsname
Full NO

MERGECOPY
The MERGECOPY merges image copies produced by
COPY or copies produced by the LOAD or REORG
utilities.
It can merge several incremental copies of a
tablespace to make one incremental copy.
It can also merge incremental copies with a full
image copy to make a new full image copy.

MERGECOPY-Authorization
- IMAGCOPY privilege for the database
- DBADM, DBCTRL, or DBMAINT authority
for the Database
- SYSCTRL or SYSADM authority.

MERGECOPY-Output
Output from the MERGECOPY utility consists
of one of the following:
- A new Single Incremental Image Copy
- A new Full Image Copy.

MERGECOPY-Types
Creating a new full Image Copy - Merging all
incremental image copies with the full image copy to
form a new full image copy.
Creating Single Incremental Image Copy Merging all
incremental image copies into single incremental
image copy, but does not merge them with the full
image copy.

MERGECOPY-Example
MERGECOPY
TABLESPACE DSN8D51P.DSN8S51C
COPYDDN (COPY1,COPY2)
NEWCOPY YES

REPORT
Provides information about Tables and Table
spaces in a Referential Structure
Information necessary for recovering a Table
space can be obtained.

REPORT-Output
REPORT TABLESPACESET output consists of the
names of all table spaces in the table space set you
specify. It also lists all tables in the table spaces
and all tables dependent upon those tables.

REPORT-Output
REPORT RECOVERY output consists of the recovery
history from the SYSIBM.SYSCOPY catalog table, log
ranges from the SYSIBM.SYSLGRNX catalog table,
and volume serial numbers where archive log data
sets from the BSDS reside.

REPORT-Authorization
RECOVERDB privilege for the database
database

REPORT-Example
For REPORTing Referentially Related Table
Spaces in the table space set
containing table space DSN8D51A.DSN8S51E.
REPORT TABLESPACESET
TABLESPACE DSN8D51A.DSN8S51E

STOSPACE
The STOSPACE online utility updates DB2
catalog columns that indicate how much
space is allocated for storage groups and
related table spaces and indexes.

STOSPACE-Output
The output from STOSPACE gives new
values in SPACE, STATSTIME columns of
number of Catalog Tables.

STOSPACE-Authorization
To execute this utility, the privilege must
include one of the following:
STOSPACE privilege
SYSCTRL or
SYSADM authority

STOSPACE-Example
For Updating the DB2 catalog SPACE
columns for storage group DSN8G510.
STOSPACE STOGROUP DSN8G510

RECOVER TABLESPACE
The RECOVER TABLESPACE online utility recovers data to
the current state or to a previous point in time.
The largest unit of data recovery is the table space, the
smallest is the page. RECOVER TABLESPACE recovers an
entire table space, a partition or data set.

DB2 Address spaces
DB2 System Objects

RECOVER TABLESPACE
You recover data from image copies of an object and from
log records containing changes to the object. If the most
recent full image copy data set is unusable, and there are
previous image copy data sets existing in the system, then
RECOVER uses the previous image copy data sets.

RECOVERY UTILITY
DB2 Data Image CopyCopy Utility
SYSIBM.SYSCOPY

RECOVERY UTILITY
• Represents the snapshot of tablespace
• Row inserted into SYSIBM.SYSCOPY
• Recovery is done for two reasons:
– System Failure
– Application Logic Error

RECOVER TABLESPACE
Authorization
RECOVERDB privilege for the database.
DBADM or DBCTRL authority for the database.

RECOVER TABLESPACE
Output
Output from RECOVER TABLESPACE consists of recovered
data.
(either a table space, partition or data set or page within a
table space).

RECOVER TABLESPACE
Example
Recovering table spaces HEXDBS.HEXTS1 and HEXDBS.HEXA to
their Quiesce point.
RECOVER TABLESPACE
HEXDBS.HEXTS1
TORBA X'000007425468'

RECOVER INDEX
RECOVER INDEX recreates indexes from the table that they
reference.
Because the data needed to recover an index is in the table
space on which the index is based, you do not need image
copies of indexes.

RECOVER INDEX
Authorization
RECOVERDB privilege for the database
DBADM or DBCTRL authority for the database

RECOVER INDEX
Example
RECOVER INDEX
(HEXADB.INDX1)

TOLOGPOINT X'byte-string'
Specifies a point on the log to recover to. Specify either
an RBA or an LRSN value.
The LRSN is a string of 12 hexadecimal characters and
is reported by the DSN1LOGP utility. The value must be
greater than the LRSN value when Version 4 started.

LOGONLY
Recovers the target objects from their existing data sets
by applying only log records to the data sets. DB2
applies all log records that were written after a point that
is recorded in the data set itself.
Use the LOGONLY option when the data sets of the
target objects have already been restored to a point of
consistency by another process offline, such as DFSMS
Concurrent Copy.

Resetting RECOVER pending or REBUILD pending
status
Several possible operations on a table space can place
the table space in the RECOVER pending status and the
index space in REBUILD pending
status.

The status can be turned off in several ways, listed
below:
Recover the table space, index space, or partition.
Use REBUILD INDEX to rebuild the index space from
existing data.
Use the LOAD utility, with the REPLACE option, on the
table space or partition.
Run REORG INDEX SORTDATA on the affected index.

Point in Time Recovery
9:00 pm
9:20 pm
8:45 am
9:10 am
COPY TSA
RUN PROGRAM XYZ
…DISCOVERS XYZ
UPDATED DATA IN ERROR!!
RESTORE LAST IMAGE COPY
Point in Time Recovery is also known as Partial Recovery. This type of
recovery restores the tablespace (s) to a previous point. The entire
tablespace is restored to the selected point. It is not possible to back out
specific transactions.

Security
• Security component of the DB2 sub system
controls the access to its data and its
resources
• One of the ways that DB2 controls access to
data is through the use of identifiers

Security
• There are three types of identifiers:
• Primary Authorization Ids
• Secondary Authorization Ids
• SQL IDs

Primary Authorization Ids
• Generally it is the primary authorization ID that
identifies a specific process
• For example, in the process initiated through the
TSO attachment facility, the primary authorization
ID is identical to the TSO logon ID
• A trace record identifies the process by that ID

Secondary Authorization Ids
• Secondary authorization IDs, which are optional, can
hold additional privileges available to the process
• A secondary authorization ID is often a Resource
Access Control Facility (RACF) group ID
• For example, a process can belong to a RACF group that
holds the LOAD privilege on a particular database. Any
member of the group can run the LOAD utility to load
table spaces in the database

SQL IDs
• An SQL authorization ID (SQL ID) holds the
privileges exercised when issuing certain
dynamic SQL statements
• If an authorization ID of a process has
SYSADM authority, then the process can set
its SQL ID to any authorization ID

Security
• Within DB2, a process can be represented by a
primary authorization ID and possibly one or
more secondary Ids
• A privilege allows a specific function/action,
sometimes, on a specific object
• An explicit privilege has a name and is held as the
result of an SQL GRANT or REVOKE statement

PRIVILEGES
• There are many explicit privileges
• We group them into privileges over:
– Tables
– Plans
– Packages
– Databases
– DB2 System

PRIVILEGES – TABLES
• ALTER: ALTER TABLE to change the table
definitions
• DELETE: DELETE to delete rows
• INDEX: CREATE INDEX to create index on
the table
• INSERT: INSERT to insert rows

PRIVILEGES – TABLES
• REFERENCES: ALTER (or) CREATE TABLE to add (or)
remove a referential constraint referring to the
named table (or) a list of columns in the table
• SELECT: SELECT to retrieve data from the table
• UPDATE: UPDATE to update all columns (or)
specific list of columns
• GRANT ALL on a table can grant all table privileges
listed above

PRIVILEGES – PLAN
• BIND:BIND, REBIND, FREEPLAN to bind (or)
free the plan
• EXECUTE: RUN to use the plan when running
the application

PRIVILEGES – Database
• CREATETAB: The CREATE TABLE statement,
to create tables in the database
• CREATETS: The CREATE TABLESPACE
statement, to create table spaces in the
database

• DISPLAYDB: The DISPLAY DATABASE
command, to display the database status
• DROP: The DROP and ALTER DATABASE
statements, to drop or alter the database

• LOAD: The LOAD utility, to load tables in the
database
• RECOVERDB: The RECOVER and REPORT
utilities, to recover objects in the database
and report their recovery status

• REORG: The REORG utility, to reorganize
objects in the database
• STARTDB The START DATABASE command,
to start the database

• REPAIR: The REPAIR and DIAGNOSE utilities
(except REPAIR DBD and DIAGNOSE WAIT)
to generate diagnostic information about,
and repair data in, objects in the database

• STATS: The RUNSTATS and CHECK utilities,
to gather statistics and check indexes and
referential constraints for objects in the
database
• STOPDB: The STOP DATABASE command, to
stop the database

PRIVILEGES – DB2 System
• ARCHIVE
– The ARCHIVE LOG command, to archive the current
active log
– DISPLAY ARCHIVE command, to give information
about input archive
– SET ARCHIVE command, to control allocation and
deallocation of tape units for archive processing.

• BINDADD: The BIND subcommand with the
ADD option, to create new plans and packages

• CREATEALIAS: The CREATE ALIAS statement,
to create an alias for a table or view name
• CREATEDBA: The CREATE DATABASE
statement, to create a database and have
DBADM authority over it

• CREATESG: The CREATE STOGROUP
statement, to create a storage group
• STOPALL: The STOP DB2 command, to stop
DB2

DB2 STAND-ALONE UTILITIES
DB2 LOCKS

DB2 STAND-ALONE UTILITIES
• The stand-alone utilities execute as batch jobs
independent of DB2. They can be invoked only by means
of MVS JCL
• It doesn’t require DB2 to be running.

DB2 UTILITIES
• Common DB2 standalone utilities include:
– DSN1COPY
– DSN1PRINT
– DSNJLOGF
– DSN1LOGP
– DSNJU003
– DSNJU004

DSN1PRNT
With the DSN1PRNT stand-alone utility, you can print:
- DB2 VSAM data sets that contain table spaces or
index spaces
- Image copy data sets

Conversion : HPGOBID into DBID & PSID
HPGOBID : Is 4 byte long. The first 2 byte contain DBID and the remaining byte
contain PSID.
Example : If HPGOBID : 011D0018, then DBID = 011D and PSID = 0018.
Below describe the conversion of hex value of the HPGOBID to its corresponding
decimal value.
DBID 0 1 1 D
D x 160 + 1 x 161 + 1 x 162 + 0 x 163
PSID 0 0 1 8
8 x 160 + 1 x 161 + 0 x 162 + 0 x 163

DSN1COPY
With the DSN1COPY stand-alone utility, you can copy:
- DB2 VSAM data sets to sequential data sets
- DSN1COPY sequential data sets to DB2 VSAM data sets
- DB2 image copy data sets to DB2 VSAM data sets
- DB2 VSAM data sets to other DB2 VSAM data sets
- DSN1COPY sequential data sets to other sequential data sets

DSN1COPY Options
FULLCOPY
Specifies that a DB2 full image copy of your data is to be used as input. The
FULLCOPY parameter requires SYSUT2 (output data set) must be a DB2 VSAM
data set.
INCRCOPY
Specifies that an incremental image copy of the data is used as input.
INCRCOPY requires that the output data set (SYSUT2) be a DB2 VSAM data
set.

DSN1COPY Options
OBIDXLAT
Specifies that OBID translation must be done before the DB2
data set is copied. This parameter requires additional input
from the SYSXLAT file by using the DD cards. DSN1COPY can
only translate up to 500 record OBIDs at a time.

RECOVERING DROPPED OBJECT
USING DSN1COPY
Steps To Be Followed
1.Drop already created table (EG : SALES)
2.Run DSN1PRINT Stand Alone Utility
For the data set that contains the dropped table, run DSN1PRNT with the
FORMAT option. Record the HPGOBID and PGSOBD . (For later use
with DSN1COPY, record the DBID, the PSID, and the OBIDs of all the
tables contained in the table space)

RECOVERING DROPPED OBJECT
USING DN1COPY
Steps To Be Followed
3. Use the SQL CREATE statement to re-create the table and any indexes on
the table. (EG : Sale1)
4. Find the new OBID for the table by querying the SYSIBM.SYSTABLES
catalog table.
SELECT NAME, OBID FROM SYSIBM.SYSTABLES
WHERE NAME='SALE1’ AND CREATOR='MVSYS05';

5. Run DSN1COPY with the OBIDXLAT option to perform the
OBID translation and to copy the data from the work data
set(image copy) to DB2 VSAM data set. Use the original
OBIDs you recorded in step 2 and the new OBID you
recorded in step 4 as the input records for the translation file
(SYSXLAT).
6. Convert DB2 VSAM dataset to a PS dataset.Because You
Cannot use a VASM dataset for Recovery.

7. Delete or Rename old image copy dataset.(3.4 option)
8. Rename the new translated PS to old image copy dataset
name (Because SYSIBM.SYSCOPY contain old image copy
dataset)
9. Recover using New image Copy Data set.

DSNJLOGF
When writing to an active log data set for the first time, DB2
must reformat a VSAM control area before writing the log
records.
The new DSNJLOGF utility avoids this delay by reformatting
the active log data sets before bringing them on-line to DB2.

DSN1LOGP
The DSN1LOGP utility formats the contents of the recovery
log for display.
There are two report formats:
- A detail report of individual log records. This information
helps IBM Support Center personnel analyze the log in detail.

DSN1LOGP
- A summary report helps you
- Perform a conditional restart
- Resolve indoubt threads with a remote site
- Detect problems with data propagation.
You can specify the range of the log to process and select
criteria within the range to limit the records in the detail
report. For example, you can specify:
- One or more units of recovery identified by URID
- A single database.

DSNJU004 (Print Log Map)
The Print Log Map (DSNJU004) utility lists the following
information:
- Log data set name, log RBA association, and log LRSN for
both copy1 and copy2 of all active and archive log data sets
- Active log data sets that are available for new log data
- Status of all conditional restart control records in the
bootstrap data set
- Contents of the queue of checkpoint records in the
bootstrap data set

- The communication record of the BSDS, if one exists
- Contents of the quiesce history record
- System and utility timestamps
- Contents of the checkpoint queue

DB2 STANDALONE UTILITIES
• DSNJU003(Change Log Inventory)
– DSNJU003 stand-alone utility changes the bootstrap data
sets (BSDSs)
– Add or delete checkpoint records
– Supply passwords for archive logs and DB2 system data
bases
– Create a conditional restart control record to control the
next start of the DB2 subsystem

Catalog Tables
DB2 & Other Environment

What is Catalog?
The DB2 catalog consists of tables of data about
everything defined to the DB2 system. The DB2
catalog is contained in system database DSNDB06.
When you create, alter, or drop any structure, DB2
inserts, updates, or deletes rows of the catalog that
describe the structure and tell how the structure
relates to other structures.

The catalog tables describe such things as table
spaces, tables columns, indexes, privileges,
application plans and packages. Authorized users
can query the catalog; however, it is primarily
intended for use by DB2 and is therefore subject to
change. All catalog tables are qualified by SYSIBM.
Do not use this qualifier for user-defined tables.

Some important Catalog Tables:
SYSIBM.SYSTABLES
SYSIBM.TABLESPACE
SYSIBM.DATABASE
SYSIBM.SYSCOLUMNS
SYSIBM.SYSFIELDS
SYSIBM.SYSFOREIGNKEYS
SYSIBM.SYSCOPY
SYSIBM.SYSUSERAUTH

SYSIBM.SYSTABLES
SYSTABLE contains row for every table, view and alias
of DB2 systems

SYSIBM.SYSTABLES
Syntax:
SELECT*
FROM SYSIBM.SYSTABLES
WHERE NAME=‘HEXATB’
AND CREATOR=‘HEXA01’;

SYSIBM.SYSTABLES
NAME : Name of the table , view or alias
CREATOR : Authorization ID of the owner of the
table, view or alias
Type : Type of object
A : Alias
T : Table
G : Temporary table
V : View
X : Auxillary table

SYSIBM.SYSTABLES
DNAME : Database name where the table or
view resides for an temporary table ,
the value is DSNDB06
TSNAME : Tablespace name where the table or
view resides. For an temporary table,
the value is SYSPKAGE.

SYSIBM.SYSTABLES
DBID : Internal identifier of the database
OBID : Internal identifier of the table
COLCOUNT : No of columns in the table or view.
NPAGES : Total number of pages on which the
rows of the table appear.

SYSIBM.SYSTABLES
IBMREQD : Whether the row came from the
basic machine- readable material
(MRM) tape:
N No
Y Yes
PARENTS : The no. of relationships in which the
table is a dependent.
CHILDREN : The no. of relationships in which the
table is a parent.

SYSIBM.SYSTABLESPACE
This table contains a row for every tablespace. Each
row gives the information like name of the tablespace,
its creator, the name of the database to which it
belongs, its OBID, DBID, PSID, Name of the Buffer Pool
used for the table space, Number of partitions in the
tablespace, lock size of the table space, status of the
table space (like its in check pendind status or available
etc.,) and other information.

Syntax:
SELECT * FROM SYSIBM.SYSTABLESPACE
SELECT * FROM SYSIBM.SYSTABLESPACE
WHERE TSNAME=’HEXATS’

NAME : Name of the table space
CREATOR : Authorization ID of the owner of the
table space
DBNAME : Name of the database which contain
the tablespace
which contain the table space
OBID : Internal identifier of the table space
descriptor

PSID : Internal identifier of the table space
page set descriptor
BPOOL : Name of the buffer pool used for the
table space
PARTITIONS: Name of the partitions of the table
space
LOCKRULE : Lock size of the table space
P – Page, R – Row,
S – Table space, T - Table

PGSIZE : Size of pages in the table
space in Kilo bytes.
ERASERULE : Whether the data set has to be
erased when dropped.
STATUS : Availability of the table space
A : Available
P : Table space in
check pending
status

N : No of tables defined in the table
space.
SEGSIZE : No of pages in each segment of the
segmented table space
CREATEDBY: Primary authorization id of the user
who has created the table space

SYSIBM.SYSDATABASE
This table contains one row for each database, except
for database DSNDB01.
Each row gives information like Database Name,
Creator, Name of the Default Storage Group, Default
Buffer Pool, DBID, Type of Database GD (blank if
database is not a work file & W for work file) and other
information.

SYSIBM.SYSDATABASE
Syntax:
SELECT * FROM SYSIBM.SYSDATABASE
SELECT * FROM SYSIBM.SYSDATABASE
WHERE NAME=’DBNAME’

SYSIBM.SYSDATABASE
NAME : Name of the database
CREATOR : Authorization Id of the owner of the
database
STGROUP : Name of the default store group for
the database
BPOOL : Name of the default buffer
pool of the table space.

SYSIBM.SYSDATABASE
TYPE : Type of database
blank : Database is not a work file DB
W : Database is a work file DB. The
database is DSNDB07
TIMESTAMP : Timestamp of the database.

SYSIBM.SYSCOLUMNS
This table contains one row for every column of each
table and view. Each row gives information like name of
the column, Name of the table or view which contains
the column., Owner of the table or view, Numeric place
of the column in the table or view, The type of the
column specified in the definition of the column
(INTEGER, SMALLINT, etc.,), whether column contains
null values or not and other information.

SYSIBM.SYSCOLUMNS
Syntax:
SELECT * FROM SYSIBM.SYSCOLUMNS
SELECT NAME, TBNAME, COLTYPE, LENGTH, NULLS,
DEFAULT
FROM SYSIBM.SYSCOLUMNS WHERE
TBNAME='DEPT'
AND TBCREATOR = 'DSN8510';

SYSIBM.SYSCOLUMNS
NAME : Name of the column
TBNAME : Name of the table or view which
contain the column
TBCREATOR: Authorization id of the owner
of the table or view
that created the column
COLNO : Numeric place of column in the view
COLTYPE : Data type information

SYSIBM.SYSCOLUMNS
LENGTH : Length attributes of the column
SCALE : Scale of decimal data.
NULLS : Whether the column can contain null
values
UPDATES : Whether the column can be updated
STATSTIME : If RUNSTATS updated the statistics,
the date and time when it was last
invoked.

SYSIBM.SYSFIELDS
This table contains one row for every column that has a
field procedure. Each row gives information like owner
of the table that contain the table, Name of the table that
contain the column, Numeric place of this column in the
table, Name of the column, Data type of the encoded
values in the field, The length attribute of the field &
other information.

SYSIBM.SYSFIELDS
NAME : Name of the column
TBNAME : Name of the table or view which
contain the column
TBCREATOR: Authorization id of the owner of the
table or view that created the column
COLNO : Numeric place of column in the view
FLDTYPE : Data type information

SYSIBM.SYSFIELDS
LENGTH : Length attributes of the column
SCALE : Scale of decimal data.
FLDPROC : For the row describing the field
procedure, the name of the
procedure.
WORKAREA: For the row describing the field
procedure, the size, in bytes, of the
work area required for the encoding
and decoding

This table contains one row for every column of every
foreign key. Its give information like owner of the table
that contain the column, Name of the table that contain
the column, Constraint name for the constraint for
which the column is part of the foreign key, Name of the
column, Numeric place of the column in that table,
Numeric place of the column in the foreign key,
Whether the row came from basic machine- readable
material tape.

Syntax:
SELECT A.RELNAME, A.CREATOR, A.TBNAME,
B.COLNAME, B.COLNO
FROM SYSIBM.SYSRELS A,
SYSIBM.SYSFOREIGNKEYS B
WHERE A.REFTBCREATOR = 'DSN8610' AND
A.REFTBNAME = 'PROJ'
AND A.RELNAME = B.RELNAME ORDER BY
A.RELNAME, B.COLNO;

CREATOR : Authorization id of the owner of the
table that contains the column
TBNAME : Name of the table that contains the
column
RELNAME : Constraint name of the constraint for
which the column is part of the
foreign key.
COLNAME : Name of the column

COLNO : Numeric place of the column in its
table
COLSEQ : Numeric place of the column in the
foreign key
IBMREQD : Whether the row came from the
basic machine readable material
(MRM) type
N No
Y Yes

SYSIBM.SYSCOPY
This table contains information needed for recovery. It
gives information like Name of the Database, Table
space, Data set number within the table space,
Operation Type (ALTER TABLE,COPY FULL YES etc.,),
Date of the entry, Device Type the copy is on,
SHRLEVEL parameter on COPY & other information.

SYSIBM.SYSCOPY
Syntax:
SELECT DBNAME, TSNAME, ICTYPE FROM
SYSIBM.SYSCOPY

SYSIBM.SYSCOPY
DBNAME : Name of the database
TSNAME : Name of the target table space or
index space
DSNUM : Data set number within the table
space. For partitioned table space,
the value corresponds to the
partition number for a single
partition copy.

SYSIBM.SYSCOPY
ICTYPE : Type of operation
A Alter
B Rebuild index
D Check data
F Full Image copy
I Incremental copy
Q Quiesce
R Reorg

SYSIBM.SYSCOPY
ICDATE : Date of entry
START_RBA: A 48-bit positive integer that contain
the LRSN of a point in the DB2
recovery log.
FILESEQNO : Type file sequence number of the
copy
DEVTYPE : Device type of the copy is on.
DSNAME : For “I” or “F”, DSNAME contains the
data set name.

SYSIBM.SYSCOPY
ICTIME : The time at which the row was
inserted.
SHRLEVEL : SHRLEVEL parameter on COPY
C Change
R Reference
DSVOLSER : The volume serial number of the
dataset

SYSIBM.SYSUSERAUTH
This table contains Records the system privileges held
by users. It gives the information like who granted the
privileges, Authorization ID of the user that holds the
privileges, Date the privileges were granted, Time the
privileges were granted, Authorization level of the user
from whom the privileges were received, Whether the
GRANTEE can use the BIND subcommand with the ADD
option, Whether the GRANTEE can create databases
and automatically receive DBADM authority over the
new databases & other information

SYSIBM.SYSUSERAUTH
Syntax:
SELECT GRANTEE FROM SYSIBM.SYSUSERAUTH
WHERE SYSADMAUTH <> ' '

SYSIBM.SYSUSERAUTH
GRANTOR : Authorization ID of the user
who granted the privileges.
GRANTEE : Application id of the user who
holds the privileges
NAME : Database name
DATEGRANTED : Granted Date
TIMEGRANTED : Granted Time

SYSIBM.SYSUSERAUTH
CREATETABAUTH: Whether the grantee can
create a table within the
database.
G Privilege held with the
GRANT option
Y privilege held without
the GRANT NO option
CREATETSAUTH: Whether the grantee can
create a table space within
database

SYSIBM.SYSUSERAUTH
DBADMAUTH : Whether the Grantee can
create database and
automatically receive DBADM
authority over the
new database.
DISPLAYAUTH : Whether the Grantee can use
the display command
RECOVERAUTH : Whether the Grantee can use
the recover command
GRANTEDTS : When the Grant statement was
issued

DB2 Environment for OS/390
DB2 operates as a formal subsystem of OS/390.
DB2 utilities run in the batch environment, and
applications that access DB2 resources can run in the
batch, TSO, IMS or CICS environments.
IBM provides attachment facilities to connect DB2 to
each of these environments.

DB2 Environment for OS/390
The DB2 database management system operates as a
formal subsystem of the OS/390 operating system.
DB2 processes can be executed in several different
address space regions within OS/390, such as IMS or
CICS.

Attachments
Attachments, facilities provide the interface between
DB2 other environments. These facilities include CICS,
IMS, TSO, CAF, and RRS.

DB2 with CICS (Customer Information Control System)
CICS is an application server that provides online
transactions management for applications. In order to
connect to DB2 from this environment you can use the
CICS attachment facility. This attachment facility allows
access to DB2 data from the CICS environment.
A CICS application can access both DB2 and CICS data
and in the event of a failure, CICS coordinates the
recovery between DB2 and CICS.

Once the DB2 subsystem has been started, DB2 can be
operated from a CICS terminal. DB2 and CICS can be
started independently of each other. The connection
can also be made to be automatic.
The following figure shows the relationship between
CICS and DB2.

DB2 with IMS (Information Management Systems)
IMS is a database computing system that includes a
hierarchical database manager, transaction manager,
and middleware products for access to the IMS
database and transactions. In order to connect to DB2,
you can use the IMS attachment facility. This facility
receives and interprets requests for access to DB2 data
via exit routines in the IMS subsystems. IMS can
connect automatically to DB2 without operator
intervention.

You can make DB2 calls from IMS applications by using
embedded SQL statements. DB2 also provides the
database services for IMS dependent regions with the
IMS attachment facility. In an IMS batch environment,
there is support for DL/I batch jobs to have access to
both IMS (DL/I) and DB2 data.

IMS will also coordinate recoveries between DB2 and
IMS in the event of a failure. You also have the option to
include DB2 in the IMS Extended Recovery Facility
(XRF) recovery scenario.
The following figure shows relationship between IMS
and DB2.

DB2 with TSO (Time Sharing Option)
TSO allows for interactive time sharing capabilities from
remote terminals. In order to connect to DB2, you can
use the TSO CAF (Call Attachment Facility) and the RRS
(Resource Recovery Services).
Using TSO, you can bind application plans & packages
and execute several online functions to DB2. Application
programs and databases can be created, modified, and
maintained via the TSO attach. You can run in either the
foreground or batch when accessing DB2.

Access to two different command processors is allowed
when using TSO:
DSN Command Processor
DB2 Interactive (DB2I)

The DSN command processor runs as a TSO command
processor using the attachment facility. It provides an
alternative method for executing programs in a TSO
environment that accesses DB2. This processor can be
invoked from the foreground by issuing a TSO command
or from batch by invoking the TMP (Terminal Monitor
Program) from an MVS batch job passing the commands
in the SYSTIN data set to TMP. When DSN is running and
DB2 is up, you can issue DB2 or DSN command.

The DB2I is comprised of ISPF panels that allow for an
interactive connection to DB2 and invokes the DSN
command processor. With this processor you can invoke
utilities, issue commands, and run SQL statements.
The TSO attachment facilities, is used by the majority of
TSO applications.
The following figure shows the relationship between DB2
and TSO.

CAF (Call Attach Facility)
The call attach facility is a DB2 facility used for
application programs that run under TSO or MVS batch.
The CAF is an alternative to the DSN command
processor and provides greater control over the
execution environment.

RRSAF
(Recoverable Resource Services Attachment Facility)
RRSAF is a DB2 sub-component that uses OS/390
Transaction Management and Recoverable Resource
Manager Services to coordinate resource commitment
between DB2 and all other resource managers that also
use OS/390 RRS in an OS/390 subsystem.

DB2 and TSO
TSO allows the users to interact with MVS/ZOS using an
online interface that is either screen or panel driven. The
ISPF provides the mechanism for communicating by
panels, which is the common method for interaction
between TSO and application users.

DB2 and TSO
By using TSO, we can bind the application plans and
packages and execute several online functions of DB2.
Application programs and database can be created,
modified, and maintained via the TSO attach. This can
run in either the foreground or batch when accessing
DB2.

DB2 and TSO
TSO is one of the environment from which DB2 data can
be accessed by two different command processors i.e.
DSN Command Processor and DB2 Interactive (DB2I)
The DSN command processor runs as a TSO command
processor using the attachment facility. It provides an
alternative method for executing programs in a TSO
environment that accesses DB2 data.

DB2 and TSO
The DB2I is comprised of ISPF panels that allow for an
interactive connection to DB2 and invokes the DSN
command processor. With this processor we can invoke
utilities, issue commands, and run SQL statements.
The following figure shows the relationship between DB2
and TSO

 Performance Monitoring
 RLST
 Managing DB2
 Monitoring Tools
 Optimizer
 Performance Tuning
 Explain Function
 Plan Table

Performance Monitoring / Tuning
Performance tuning should be undertaken to improve the
cost benefit ratio of the system and resource utilization.
The Database Administrator should gather information
regarding the usage of database. An Application
Programmer may also require SQL statement execution
information regarding SQL statement.
THE various DB2 facilities provide monitoring and
gathering information for tuning process.

Performance Tuning
In application side, the SQL’s can be tuned to make them
more efficient and avoid redundancy.
It is better to structure the SQL, so that they perform only
the necessary operations.

Performance Tuning
On the database side, the major enhancements can be
done to the definitions of tables, indexes and the
distribution of table space and index space.
The application run statistics are obtained from EXPLAIN
or DB2PM report.

RLST
When system resources are shared among transactions,
end user queries, and batch programs, it is important to
control how those resources are used. You need to
separate data and set priorities carefully. Emphasize
resource use, performance, concurrency, or data
security.
The number of I/Os and I/O elapsed times are also
important performance considerations in a database
system. When you design your database, you should
optimize the number of I/Os by using an efficient buffer
pool design, and minimize I/O elapsed times by carefully
selecting the placement of the DB2 data sets.

Controlling Resource Usage
DB2 includes a resource limit facility (governor), which
helps control the use of DB2 resources. Other facilities,
such as MVS workload management (SRM and WLM),
complement the DB2 governor.

Restricted activity on the RLST:
While the governor is active, you cannot execute the
following SQL statements on the RLST, or the table space
and database in which the RLST is contained:
DROP DATABASE
DROP INDEX
DROP TABLE
DROP TABLESPACE
RENAME TABLE

RLST (Resource Limit Tables)
DB2’s resource limit facility (governor) lets you perform
the following activities:
Set warning and error thresholds by which the governor
can inform users (via your application programs)
that a certain processing limit might be exceeded for a
particular dynamic SELECT, INSERT, UPDATE, or
DELETE statement. This is called predictive governing.

Reactive Governing
Stop a currently executing dynamic SQL statement
(SELECT, INSERT, UPDATE, or DELETE) that exceeds the
processor limit that you have specified for that
statement.

Resource Limit Tables
Use one or more resource limit specification tables
(RLSTs) to give governing information to DB2.
RLST can reside in any database; however, because a
database has some special attributes while the resource
limit facility is active, it is best to put RLSTs in their own
database.
When you install DB2, installation job DSNTIJSG creates
a database, table space, table and descending index for
the resource limit specification.
DSNRLST is the default database for RLST.

Populating RLST
Use the SQL statements INSERT, UPDATE, and DELETE
to populate the resource limit specification table.

Starting and Stopping RLST
Activate any particular RLST by using the DB2 command
START RLIMIT ID=xx where xx is the 2-character
identifier you specified on the name DSNRLSTxx. This
command gives you the flexibility to use a different RLST.
Only one RLST can be active at a time. At installation
time you can specify which is the default RLST to be
used each time DB2 started.

Managing DB2
Managing DB2 deals with various DB2 design issues,
emphasizing those related to performance. It also
introduces data sharing concepts.
To manage DB2, use RUNSTATS statistics to determine
when to reorganize a pageset.

Managing DB2
The physical design options will have a major impact on
the resource consumption of DB2 system. Some of the
options are
DDL options
Changing performance options

Changing Performance Options
Changes possible through alter Modify free space
Changes requiring create Creating new index
Changes requiring drop / create
(data movement)
Redefining columns
Changes affecting programming Re-designing tables

Changes Possible via Alter
STOGROUP VOLUMES
TABLESPACE
INDEX
LOCKSIZE
BUFFERPOOL
CLOSE YES/NO
PCTFREE
FREEPAGE
STOGROUP / VCAT
PRI QTY / SEC QTY
ERASE
COMPRESS
INDEX TYPE 1 OR 2
TABLE ADD COLUMNS
PRIMARY KEY
FOREIGN KEY
CHECK CONSTRAINTS

Tablespace Considerations – Type
Partitioned
- large table
- exploit parallelism I/O and CPU (define table
has been partitioned)
- logical partitioning of data
Segmented (use 32 to 64 pages)
- one or multiple tables
- don’t mix RI structures
Simple
- not recommended

Index Considerations - DEFER
 Dataset allowed
 Index not built
 Index placed in recovery pending
 Index built more efficiently
- DEFER NO: less concurrency
- No Other DDL, No Dynamic, No BIND, No Utilities.

PRIQTY and SECQTY
 Avoid secondary allocation
 Allocation amount determines pre-formatting (CYL or
TRK)

CLOSE Recommendations
 Specify CLOSE NO for performance critical table-
spaces and index-spaces
 Before accessing any table-space or index-space
outside of DB2 (e.g. DSN1COPY), - STOP DATABASE
(…) SPACENAM (…)

Locking - Overview
To control locking, the DBA should establish guidelines
that instruct the other functions how they should use the
options.
Locking is impacted by all functions involved in DB2.

RUNSTATS
Statistics used by
- DB2: access path selection
- user: determine space utilization, need to REORG?
When:
- a table is loaded, an index is created
- a tablespace is reorganized
- after extensive updates, inserts or deletions
- periodically provide data needed to decide on REORG

RUNSTATS
The RUNSTATS statistics will be used for DBA to
determine whether the Tablespace or Index needs to be
reorganized.

RUNSTATS or UPDATE
You can create tablespace, tables, indexes without
populating the tablespaces, update statistics to look like
your production system, and obt`ain valid EXPLAIN and
your access paths.
Authorization required:
SYSADM, DBADM for DSNDB06, or UPDATE privilege on
particular catalog tables / columns.

Access Path & Optimization
The optimization is done at the time of execution of SQL
statement and at the time of Binding process.
The method used to retrieve data from table is called
Access Path.

Performance Monitoring
It is based on two aspects:
- Application Performance
- System Objects Performance
It describes how the Optimizer works
DB2 Access Path
The Explain Functions & Plan Table
I/O & CPU Parallelism and Accounting Cost

Application Performance
 Optimizer
 Access Path
 Join Techniques
 Plan Table & Explain

Optimizer
The main objective of optimizer is attempts to choose
the least expensive access path that will be used to
execute an SQL statement. This decisions will be based
on a number of inputs.
- Statistics
- Defined Objects
- Default Assumptions
- Available Hardware Structure
- Structure of SQL Statement

Optimizer
The optimizer also determines table / table space lock
modes required by each SQL statement.
The decision on access path is based on
- The filter factor
- column statistics
- table statistics
- where clause
- defaults
* How many rows will be return in certain selection
criteria. The result of this assumption is the Filter Factor.

Optimizer
- Available Indexes
- Sort Costs
- Data Organization
- Processor Speed and other system considerations

Optimizer Catalog Statistics
SYSIBM.SYSTABLES SYSIBM.SYSINDEXPART SYSIBM.SYSTABLESPACE
SYSIBM.SYSCOLUMNS
SYSIBM.SYSTABSTATS
SYSIBM.SYSINDEXES
SYSIBM.SYSCOLDIST
Parsed SQL Statement
No. of active pages
Limit Key
No. of rows
No. of pages
Pct. of rows compressed
Clustering Information
No. of distinct keys
No. of leaf pages
No. of levels
Index column value
Percent rows with value
OPTIMIZER
No. of rows
No. of pages
2nd highest value
2nd lowest value
No. of distinct values

Data Organization
DB2 expects every table should have an index. All table
rows are in indexed sequence.
SYSIBM.SYSINDEX (CLUSTER RATIO)

Table Scan
In a segmented table space with more than one table,
DB2 will only scan pages of the tables in the FROM
clause. Whereas in the simple table space with more than
one table, DB2 may scan all pages of the table space
regardless of which table they belong to.
Example:
Select * from Address where Postal_Code=‘123’
Result:
Read all pages

Matching Index Scan
The matching index scan will use the columns in the
index to determine which row qualify. The pages in the
table space will only be read if a qualifying row is
detected in the index.
Example:
Select * from Address where Street=‘Mount Road’

Matching Columns
A predicate matches an index when the columns in the
predicate are an initial substring of the set of columns in
the index key.
The more matching columns the fewer will be the rows
processed and pages read.
Example:
index on (JOBCODE,SERVICE,SALARYCODE)

Matching Columns
Predicate Matching
JOBCODE = 97 AND YES (3 Cols)
SERVICE = 20 AND
SALARYCODE = 56
SERVICE = 20 AND
SALARYCODE < 56 NO

Column Choices for Indexes
- Primary key (required)
- Foreign keys
- Columns in ‘WHERE’ clause
- Columns in ‘JOIN’ operations
- Columns used in ‘ORDER BY’ and ‘GROUP BY’
Sort Costs
- Minimize sorting
- Minimize number of qualified rows returned to the
application

Explain Function
When we create a plan, package or SQL statements are
bound, the output appears in a table called
PLAN_TABLE.
Explain helps as an optimizer and provide the access
path selection of DB2.
DB2 will write the access path of each explainable
statement into the PLAN_TABLE when you Bind / Rebind
a Plan or Packages with EXPLAIN (YES).

Explain Function
There are two ways to populate the PLAN_TABLE
- Executing the SQL statement EXPLAIN
By executing SQL statement, specify a single explainable
SQL statement in the FOR clause dynamically in SPUFI.

Explain Function
- Binding with the option EXPLAIN (YES)
Populate PLAN_TABLE by executing the SQL statement,
EXPLAIN (YES) invokes the DB2 optimizer and rows get
inserted into user created PLAN_TABLE.
EXPLAIN (YES) is recommended for BIND and developer
should have a private PLAN_TABLE in that ID.

PLAN_TABLE
To obtain EXPLAIN output, each user must have own
PLAN_TABLE.
CREATES USERID.PLAN_TABLE
SELECT * FROM PLAN_TABLE
Explain PLAN SET QUERYNO = 125 FOR SQL-
STATEMENT
BIND AND REBIND EXPLAIN (YES)

PLAN_TABLE – Reporting Sequence
For a PLAN
(Information about the Query)
Select * from PLAN_TABLE
Where APPLNAME=…
Order by
QUERYNO, QBLOCKNO, PLANNO
MIXOPSEQ

PLAN_TABLE – Reporting Sequence
For a PACKAGE
(Information about the Load Module)
Select * from PLAN_TABLE
Where PROGNAME=… and COLLID=… and VERSION=…
Order by
QUERYNO, QBLOCKNO, PLANNO
MIXOPSEQ

Some of the Columns in PLAN_TABLE
QUERYNO, QBLOCKNO,
APPLNAME, PROGNAME,
PLANNO, METHOD, CREATOR, TNAME, TABNO,
ACCESSTYPE, MATCHCOLS, ACCESSCREATOR,
ACCESSNAME, INDEXONLY, TSLOCKMODE,
TIMESTAMP, REMARKS, VERSION, COLLID

Some of the Columns in PLAN_TABLE
QBLKNO : 1 for single table SELECT
PLANNO : 1 for single table SELECT
METHOD : 0 for the first table accessed
TNAME : name of the table accessed
ACCESSTYPE : access through an index
ACCESSNAME : name of the index used
INDXONLY : access to data is needed
SORTIND : sort performed or not
TSLOCKS : page or row locks used

Introduction to DB2 Architecture and Components

Introduction to DB2 Architecture and Components

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Introduction to DB2 Architecture and Components

Similar to Introduction to DB2 Architecture and Components (20)

More from Skillwise Group

More from Skillwise Group (20)

Recently uploaded

Recently uploaded (20)

Introduction to DB2 Architecture and Components