DB2 - IBM’s Relational DBMS

Day 1 Topics
Topics to be covered in this session
• Introduction to databases - covers their advantages and the types of
databases

• Relational database concepts - covers Properties, Terminology,

Normalization, Integrity rules and the E-R model
Introduction to Databases

What is Data ?
‘A representation of facts or instruction in a form suitable for
communication’ - IBM Dictionary

What is a Database ?
‘Is a repository for stored data’ - C.J.Date
Introduction to Database (contd...)

What is a database system ?

An integrated and shared repository for stored data or collection of
stored operational data used by application systems of some
particular enterprise.
Or
‘Nothing more than a computer-based record keeping system’.
Advantages of DBMS over File
Management System
• Data redundancy
• Multiple views
• Shared data
• Data independence (logical/physical)
• Data dictionary
• Search versatility
• Cost effective
• Security & Control
• Recovery restart & Backup
• Concurrency
 TYPES OF DATABASES (or Models)

• Hierarchical Model

• Network Model

• Relational Model

• Object-Oriented Model
Types of Databases (contd...)

HIERARCHICAL
• Top down structure resembling an upside-down tree
• Parent child relationship
• First logical database model
• Available on most of the Mainframe computers
• Example - IMS
Types of Database (contd...)

NETWORK
• Does not distinguish between parent and child. Any record type
can be associated with any number of arbitrary record types

• Enhanced to overcome limitations of other models but in reality,

there is minimal difference due to frequent enhancements

• Example - IDMS
Types of Database (contd...)
RELATIONAL
• Data stored in the form of tables consists of multiple rows and
columns.
• Examples - DB2, Oracle, Sybase, Ingres etc.

OBJECT -ORIENTED MODEL

• Data attributes and methods that operate on those attributes are
encapsulated in structures called objects
RELATIONAL DB CONCEPTS
Relational Properties
Why Relational ? - Relation is a mathematical term for a table -
Hence Relational database ‘is perceived’ by the users as a set of
tables.

• All data values are atomic.

• Entries in columns are from the same domain

• Sequence of rows (T-B) is insignificant

• Each row is unique

• Sequence of columns (L-R) is insignificant

Relational Concepts (Terminology)

• Relation : A table
• Tuple : Row contains an entry for each attribute
• Attributes : Columns or the characteristics that define the
entity
• Domain:. A range of values (or Pool)
• Entity : Some object about which we wish to store information
• Null : Represents an unknown/empty value
• Atomic Value: Smallest unit of data; the individual data value
Relational Concepts (contd...)
• Candidate key : Some attribute (or a set of attributes) that may
uniquely identify each row(tuple) in the relation(table)

• Primary key : The candidate key that is chosen for primary

attributes to uniquely identify each row.

• Alternate key :The above remaining candidate keys that were not
chosen as primary key can be alternate key.

• Foreign key :An attribute of one relation that might be a primary

key of another relation.
 Normalization (1NF - 5NF)
It is done to bring the design of database to a standardized mode or
(form)

• 1NF : All entities must have a unique identifier, or key, that can be
composed of one or more attributes. All attributes must be atomic and
non repeating.

• 2NF : Partial functional dependencies removed - all attributes that are

not a part of the key must depend on the entire key for that entity.
Normalization (contd...)

• 3NF : Transitive dependencies removed - attributes that are not a part

of the key must not depend on any non-key attribute.

• 4NF : Multi valued dependencies removed

• 5NF : Remaining anomalies removed

 Types of Integrity

• Entity Integrity : Is a state where no column that is part of a primary

key can have a null values.

• Referential Integrity : Is a state where every foreign key in the first

table must either match a primary key value in the second table or
must be wholly null.

• Domain Integrity : Integrity of information allowed in column

 Entity Relationship Model

• E-R model is a logical representation of data for a business area.

• Represented as entities, relationship between entities and attributes of

both relationships and entities.

• E-R models are outputs of analysis phase i.e they are conceptual
data models expressed in the form of an E-R Diagram.
E-R Model Example:

Example:
CUSTOMER Places ORDERS
ORDERS Has PRODUCTS

• Each order relates to only one customer (one-to-one)

• Many orders can contain many products (many-to-many)

• A CUSTOMER can place any number of orders (one-to-many)

E-R Model Example: (Contd..)

• In the above example CUSTOMER, Order & Product are called

ENTITIES.

• An Entity may transform into table(s).

• The unique identity for information stored in an ENTITY is called a

PRIMARY KEY. E.g... CUSTOMER-No uniquely identifies each
customer
 Entity As Table

A table essentially consists of

• Attributes, which define the characteristics of the table

• Primary key, which uniquely identifies each row of data

stored in
a table

• Secondary & Foreign Keys/indexes

 Entity As Table

Transforming Entity (CUSTOMER) into Table

Table ‘CUSTOMER’
Attributes - CUST_NO, CUST_NAME,
CUST-LOCATION, CUST_SSN, ORDER_NO...

Primary Key - CUSTOMER_NO

Secondary Key - CUST_SSN
Foreign-Key - ORDER_NO
 Developing Relationship

• For e.g.. CUSTOMER is related to Orders through ‘ORDER_NO’

which is the Foreign-key in CUSTOMER and Primary key in another
table say ORDER. So basically the relationship ‘Places’ is through the
ORDER_NO.

• The Relationships transform into Foreign Keys.

• As per the relational integrity the Primary-Key, ORDER_NO, for the

table ‘Orders’ can never be Null, while it can be so in the table
‘CUSTOMER’.
Developing Relationship (contd...)

• To do transformations as described above we need a tool that will

provide a way of creating the tables, manipulate the data present in
these, create relationships, indexes, tablespace, indexspace and so
on.

• DB2 provides SQL which performs these functions. The next part
briefly deals with SQL and its functions. A detailed explanation will be
taken up later.
 Topics to be covered in this session

• SQL - all data object manipulation, creation and use, involve SQL’s.

• DB2 objects - Database, Tablespaces & Indexspaces - creation &

use, and other terminology's associated with databases.
An introduction to SQL
SQL or Structured Query Language is

• A Powerful language that performs the functions of data

manipulation(DML), data definition(DDL) and data control or data
authorization(DAL/DCL).

• A Non procedural language - the capability to act on a set of data

and the lack of need to know how to retrieve it. An SQL can perform
the functions of more than a procedure.

• The De Facto Standard query language for RDBMS

• Very flexible
SQL - Features

• Unlike COBOL or 4GL’s, SQL is coded without data-navigational

instructions. The data access paths are determined by the DBMS.
This is advantageous because the database knows better how it
has stored data than the user.

• What you want and not how to get it

• Set level processing & multiple row processing

 SQL - Types (based on the
functionality)

• Data Definition Language (DDL)

- Create, Alter and Drop

• Data Manipulation Language (DML)

- Select, Insert, Update and Delete

• Data Control Language (DCL)

- Grant and Revoke
 Topics dealt with in DB2 objects

• Storage Group , Databases, Tablespaces , Indexspaces

• Tables , Views , Index, Synonyms , aliases

The DB2 Object Hierarchy

Catlog
Stored Stored Stored Table
Stored table
table table table
Table Space

Catlog
Table
Stored table Stored table

Stored table
Index Space

Index
Index

Index

Catalog
User Database User Database
Database

Storage Gropu 1 Storage Gropu 2

 Storage Group

• It is a named collection of direct access volumes, all of the same

device type.

• Each table space and each index space normally has an associated
storage group.

• When a given space needs to be extended, storage is acquired from

the appropriate stogroup .
 Database

• A collection of logically related objects - like Tablespaces,

Indexspaces, Tables etc.

• It may occupy more than one disk space.

• In a given database, all the spaces need not have the same
storage group.
 Tablespaces

• Logical address space on secondary storage to hold one or more

tables.

• A ‘SPACE’ is basically an extendable collection of pages with each

page of size 4K or 32K bytes.

• It is the storage unit for recovery and reorganizing purpose.

• Three Type of Tablespaces - Simple, Partitioned & Segmented

 Simple Tablespace

• Can contain more than one stored table.

• Depending on application, storing more than one table might enable

faster retrieval for joins using these tables

• Usually only one is preferred. This is because a single page can

contain rows from all tables defined in the database.
 Segmented Tablespaces
• The space within the tablespace is divided into segments.

• A ‘Segment’ consists of a logically contiguous set of ‘n’ pages.

( where 4 < n < 64).

• Can contain more than one stored table, but in a segmented space.

• No segment is allowed to contain records for more than one table.

Partitioned Tablespaces

• Primarily used for very large tables.

• Only one table in a partitioned TS; 1 to 64 partitions/TS

• It is partitioned in accordance with value ranges for single or a

combination of columns. Hence these column(s) cannot be updated.

• Different partitions can be stored on different storage groups for

efficient access.
 INDEXSPACES
• Is to an index what a tablespace is to a table.

• The correspondence between index and indexspaces is one-to-

one.

• Indexspace are always 4KB in size.

 TABLES
• Tables are logical structures maintained by the database
manager.

• Tables are made up of columns and rows.

• At the intersection of every column and row is a specific data item

called a value.
Indexes

What is an Index ?
‘An index is an ordered set of pointers to rows of a base table’.
Or
‘An Index is a B-tree structure that orders the values of columns in
a table’

Why an Index ?
‘One can access data directly and more efficiently’
 Indexes (contd...)

• Each index is based on the values of data in one or more columns.

An index is an object that is separate from the data in the table.

• When you define an index using the CREATE INDEX statement, DB2
builds this structure and maintains it automatically.

• Indexes can be used by DB2 to improve performance and ensure

uniqueness.
 Other DB2 Objects

VIEWS
• It is a logical derivation of a table from other table/tables. A View does
not exist in its own right.

• They allow the same data to be seen by different users in different

ways

• In DB2 a view that is to accept an update must be derived from a

single base table
 DB2 Objects (contd...)

Aliases
• Mean ‘another name’ for the table.
• Aliases are used basically for accessing remote tables (in distributed
data processing), which add a location prefix to their names.
• Using aliases creates a shorter name.

Synonym
• Also means another name for the table, but is private to the user who
created it.
 DB2 Data types
• Char (n) 1 < n < 254 bytes
• Varchar(n) variable length
• Smallint 2 bytes +- 32 K
• Integer 4 bytes +- 2 GB
• Decimal(x,y) max 31 digits
• Date 0001-01-01
• Time 00:00:00
• Timestamp 0001-01-01-00.00.00.000000
Data Definition Language
CREATE
This statement is used to create various DB2 objects.

Create Table
Syntax : For Creating a Table
CREATE TABLE <tabname>
(Col1 datatype [not null [with default]] ….),
PRIMARY KEY(Columns) /
FOREIGN KEY col1 references tablename
on delete cascade/restrict/set null
[LIKE Table name / View name]
[IN Database.Tablespace Name ]
Data Definition Language
Create Table Parameters

• Foreign Key references dbname.table

• Eg. Table1 references table2(target) - Table2’s Primary key is the

foreign key defined in Table1

• The conditions that can be used are CASCADE, RESTRICT & SET
NULL (referential constraint for the foreign key definition)

• Inserting (or updating ) rows in the target is allowed only if there are
no rows in the referencing table
 Data Definition Language

Create Index
• Create [unique] index indexname
on tablename (col1 [desc], ….)
[using stogroup stgrp1]
[bufferpool BPn]
[close yes/no]
[freepage N]
[pctfree N]
Data Definition Language

Create other objects…..

CREATE VIEW <Viewname> (<columns>)

AS Subquery (Subquery - SELECT FROM
other Table(s))

CREATE ALIAS <Aliasname> FOR <Tablename>

CREATE SYNONYM <Synonymname> FOR <Tablename>

 Data Definition Language

ALTER
This statement is used for altering all DB2 objects

ALTER TABLE <Tablename>

ADD Column Data-type [ not null with default]

• Alter allows primary & Foreign key specifications to be changed

• It does not support changes to width or data type of a column or
dropping a column
Data Definition Language (contd...)

DROP
This statement is used for dropping all DB2 objects

Syntax : For dropping a table

DROP TABLE <Tablename>
 Effects of Drop table

• All indexes, views and synonyms are dropped.

• Contents of the table are lost.
• Referential constraints that involve the table are dropped.
• Will not drop a table created in partitioned tablespace.
 Topics to be covered in this session

• More SQL - Insight into the DML statement Select

• Simple Queries
• Functions
• Complex Queries
• Other DML statements Insert, Update and Delete
SQL - Selection & Projection

• Select retrieves a specific number of rows from a table

• Projection operation retrieves a specified subset of columns(but all
rows) from the table

E.g.. : SELECT CUST_NO, CUST_NAME

FROM CUSTOMER;

• The WHERE clause defines the Predicates for the SQL operation.
• The above WHERE clause can have multiple conditions using AND
& OR .
Other Clauses
Many other clauses can be used in conjunction with the
WHERE clause to code the required predicate, some are :-

• Between / Not Between

• In / Not In

• Like / Not Like

• IS NULL / IS NOT NULL

SELECT using a range :

Between Clause
E.g. SELECT CUST_NO, CUST_NAME, CUST_ADDR FROM
CUSTOMER
WHERE CUST_NO BETWEEN 1000 AND 2000;

In Clause
E.g. SELECT CUST_NO, CUST_NAME, CUST_ADDR FROM
CUSTOMER
WHERE CUST_NO IN(1000, 1001,1002);
Select clause (contd...)
Like Clause
E.g. SELECT CUST_NO, CUST_NAME, CUST_ADDR
FROM CUSTOMER
WHERE CUST_ID like/not like ‘425%’

Note :- ‘_’ for a single char ; ‘%’ for a string of chars

Escape ‘\’ - escape char; if precedes ‘_’ or ‘%’ overrides their meaning
Select clause (contd...)

NULL Clause : To check null the syntax is ‘IS NULL’

E.g. SELECT CUST_NO, CUST_NAME, ORDER_NO

WHERE ORDER_NO IS NULL;

However if there are null values for ORDER_NO, then these are
always evaluated as a ‘Not True’ condition in a Query.
Order by and Group by clauses :

• Order by sorts retrieved data in the specified order; uses the WHERE
clause

• Group by operator causes the table represented by the FROM clause

to be rearranged into groups, such that within one group all rows have
the same value for the Group by column (not physically in the
database). The Select clause is applied to the grouped data and not to
the original table.

Here ‘HAVING’ is used to eliminate groups, just like WHERE is used

for rows.
 Functions

Types are two :

• Column Function

• Scalar Function
 Column Functions

• Compute from a group of rows aggregate value for a specified

column(s)

• AVG, COUNT, MAX, MIN, SUM

 Scalar Functions

• Are applied to a column or expression and operate on a single value.

• CHAR, DATE, DAY(S), DECIMAL, DIGITS, FLOAT, HEX, HOUR,

INTEGER, LENGTH, MICROSECOND, MINUTE, MONTH, SECOND,
SUBSTR, TIME, TIMESTAMP, VALUE, VARGRAPHIC, YEAR
Complex SQL’s

• One terms a SQL to be complex when data that is to be

retrieved comes from more than one table

• SQL provides two ways of coding a complex SQL

1. Subqueries and
2. Joins
 Subqueries

• Nested Select statements

• Specified using the IN(or NOT IN) predicate, equality or non-equality

predicate(‘=‘ or ‘<>‘) and comparative operator(<, <=, >, >=)

• When using the equality, non-equality or comparative operators, the

inner query should return only a single value
 Subqueries (contd...)

• The nested loop statements gives the user the flexibility for querying
multiple tables

• A specialized form is Correlated Subquery - the nested select

statement refers back to the columns in previous select statements
Joins

OUTER JOIN : For one or more tables being joined, both matching and
non-matching rows are returned. Duplicate columns may be
eliminated
The non-matching columns will have nulls in them.

INNER JOIN: Here there is a possibility one or more of the rows from
either or both tables being joined will not be included in the table that
results from the join operation
Other DML Statement’s

INSERT

E.g..: INSERT INTO Tablename(column1,

column2, column3 ,......)
VALUES( value1, value2, value3 ,........)

If any column is omitted in an INSERT statement and that column is

NOT NULL, then INSERT fails; if null it is set to null
 DML statements (contd...)

• If the column is defined as NOT NULL BY DEFAULT, it is set to that

default value

• Omitting the list of columns is equivalent to specifying all values

 DML statements (contd...)

UPDATE

E.g.. UPDATE tablename

SET Columnname(s) = scalar expression
WHERE [ condition ]

• Single or Multiple row updates

• Update with a Subquery
DML statements (contd...)

DELETE

E.g. DELETE FROM Tablename

WHERE [condition ];

• Single or multiple row delete or deletion of all rows

 QMF - Query Management Facility

• It is an MVS- and VM- based query tool

• Allows end users to enter SQL queries to produce a variety of reports

and graphs as a result of this query

• QMF queries can be formulated in several ways : by direct SQL

statements, by means of relational prompted query interface or by
query-by-example (QBE). QBE is similar to SQL in some ways but
more user friendly
 SPUFI - SQL Processing Using File
Input

• Supports the online execution of SQL statements from a TSO terminal

• Used for developers to check SQL statements or view table details

• SPUFI menu contains the input file in which the SQL statements are
coded, option for default settings and editing and the output file.
 Reference Book
• DB2 developer’s Guide - Craig S. Mullins

• A Guide to DB2 - C.J. Date

• IBM Manuals
1. SC26-4889 DB2 Application Programming and SQL Guide
2. SC26-4890 DB2 SQL Reference
Day 2 - Topics
 Using DB2 In An Application Program
• SQL statement can be embedded in application programming
languages like COBOL.
Comparison of a DB2/VSAM program
DB2 Tables do not require file references,such as

1. SELECT/ASSIGN statement in the ENVIRONMENT

DIVISION.

2. FD statement in the DATA DIVISION.

3. JCL DD statements for the table(s).

Whereas, VSAM files require above file references.

 Comparison (Contd..)
• DB2 manages all physical file operations.Tables need not be
opened or closed within a program, the way it is required for
VSAM files.

• DB2 program access data at the column level;whereas,VSAM

program access data at the record level.

• Error handling is better in DB2.

Embedded SQL
Application programming using DB2

Application environments supporting DB2 :

• IMS(Batch/Online), CICS, TSO(Batch/Online)

• CAF - Call Attach Facility

• All DB2 application types can execute concurrently

• Host Language support - COBOL, PL/1, C, Fortran or

Assembly Lang
 Embedded SQL
Steps involved in creating a DB2 application

Coding the application

Using Embedded SQL
Using Host variables (DCLGEN)
Using SQLCA
Pre-compile the program
Compile & link edit the program
Bind
 Embedded SQL
Embedded SQL statements

They are delimited with

EXEC SQL
[………]
END-EXEC.

It is like the file I/O.

Normally the embedded SQL statements contain the host variables

coded with the INTO clause of the SELECT statement.
 Embedded SQL
• E.g. EXEC SQL
SELECT Empno, Empname
INTO :H-empno, :H-empname
FROM EMPLOYEE
WHERE empno = 1001
END-EXEC.
Host variables in COBOL DB2 Program
Host Variables

• These are variables(or rather area of storage) defined in the

host language to use the predicates of a DB2 table. These
are referenced in the SQL statement.

• A means of moving data from and to DB2 tables.

• DCLGEN produces host variables, the same as the columns

of the table.

• General coding format is :FieldName .

Host Variables (contd...)
Host variables can be used

• In WHERE Clause of Select, Insert, Update & Delete

• ‘INTO’ Clause of Select & Fetch statements

• As input of ‘SET’ Clause of Update Statements

• As Input for the ‘VALUES’ Clause of Insert statements

 Host Variables (contd...)
E.g.

EXEC SQL
SELECT Cust_No, Cust_name, Cust_addr
INTO :H-CUST-NO,
:H-CUST-NAME,
:H-CUST-ADDR
FROM CUSTOMER
WHERE CUST_NO = :H-CUST-NO
END-EXEC.
About Table Declaration
DCLGEN

DCLGEN , a DB2 utility, produces host variables named as same as

column name.

Prepares the structure of the table in a COBOL copybook.

The copybook contains a ‘SQL DECLARE TABLE’ statement along

with a working storage host variable definition for the table.
 DCLGEN (Contd…)
• INCLUDE statement is coded to copy DCLGEN outputs into the
program’s working storage section.

• The general statement format is

EXEC SQL
INCLUDE source code name
END-EXEC.
 SQL Communication Area
SQLCA

• Is a source code structure made up of several fields by

means of which DB2 communicates with application

program.

• Is used by DB2 to communicate to program the response

from last SQL statement executed.

• Must be copied into working storage section using include

statement . The format is
EXEC SQL
SQLCA (contd...)
Structure of the SQLCA (for COBOL)
01 SQLCA.
05 SQLCAID PIC X(8).
05 SQLCABC PIC S9(9) COMP
05 SQLCODE PIC S9(9) COMP
05 SQLERRM.
:
05 SQLWARN.
10 SQLWARN0 PIC X(1).
:
10 SQLWARNA PIC X(1).
10 SQLSTATE PIC X(5).
 DB2 Program Preparation

SOURCE Pre-compiler
PROGRAM MODIFIED
SOURCE
DCLGEN CODE

DBRM BIND
PACKAGE COMPILER
BIND
PLAN PACKAGE OBJECT
CODE
PLAN
DB2 LINK-
DB2 DIRECTORY
CATALOG EDIT

LOAD
MODULE
 DB2 Program Execution
PRECOMPILE

• The SQL statements coded in the host language must first be translated
by DB2 precompiler for compilation as host language statement.

• Searches all the SQL statements and DB2 related INCLUDE members
and comments out every SQL statement in the program

• The SQL statements are replaced by a CALL to the DB2 runtime

interface
module, along with parameters.

• All SQL statements are extracted and put in a Database Request Module
(DBRM) .
 DB2 Program Execution
PRECOMPILE (Contd….)

• Places a timestamp in the modified source and the DBRM so that

these are tied. If there is a mismatch in this a runtime error of ‘-
818‘, timestamp mismatch occurs.

• All DB2 related INCLUDE statements must be placed between

EXEC SQL & END EXEC keywords for the precompiler to
recognize them.
 DB2 Program Execution
COMPILE & LINK

• Modified precompiler COBOL output is compiled.

• Compiled source is link edited to an executable load module.

 DB2 Program Execution
BIND

• A type of compiler for SQL statements.

• It reads the SQL statements from the DBRM and produces a
mechanism to access data (in an efficient manner) as directed by the
SQL statements being bound.

•Checks syntax, checks for correctness of table & column definitions

against the catalog information & performs authorization validation.

•DB2 must be active during Bind.

 DB2 Program Execution
PLAN

• A plan is an executable module containing the access path logic

provided by the DB2 optimizer.

•An application plan can be composed of one or more DBRMs and

packages.

• Every DB2 application requires an application plan.

• Plans are created using the DB2 subcommands BIND PLAN.

 DB2 Program Execution
PACKAGE

•It is a single bound DBRM with optimized access paths.

•A package can not be executed until it is bound into a plan.Therefore

it is included into the package list of a plan, which then executes.

•Only the package of a particular program need to be re-bound if SQL

within it has changed.
 DB2 Program Execution
DISADVANTAGES OF PLAN

• If an individual DBRM needed to be re-compiled for any reason,

the entire PLAN had to be re-compiled & re-bound.

•Adding a new DBRM to an existing PLAN require a re-compilation

& re-bind of the entire PLAN.

•If multiple PLANS involved same DBRM, & if it ever needed to be

re-compiled, then the all the relevant PLANS had to be re-compiled
& re-bound.
 DB2 Program Execution
ADVANTAGES OF PACKAGE

• Only the package of a particular program need to be re-bound if

SQL within it has changed.

• It is possible to add new packages to an existing plan without

having the need to do a plan re-bind.

• Versioning
 DB2 Program Execution
BIND TYPES

•BIND PLAN : accepts as input one or more DBRMs and outputs an

application plan containing executable logic representing optimized
access paths to DB2 data.

•BIND PACKAGE : accepts as input a single DBRM and produces a

single package containing the optimized access path. The PLAN in this
case contains a reference to the physical location of the package(s).
 DB2 Program Execution
BIND COMMAND
The general BIND Command Format is : -
BIND PLAN (PLAN-NAME)
MEMBER (DBRM-MEMBER-NAME,…….)
LIBRARY (DBRM-LIBRARY-NAME,…….)
ACTION (ADD / REPLACE)
RETAIN (NO / YES)
VALIDATE (RUN / BIND)
ACQUIRE (USE / ALLOCATE)
RELEASE (COMMIT / DEALLOCATE)
ISOLATION (RR / CS)
FLAG (I / W / E / C)

DBRM DB2
LIBRARY CATALOG
BIND
Data Base Physical Storage
access PLAN Characteristics
requests
Day 3 - Topics
 Topics to be covered in this session

• Cursors

• Null Indicator

• Application development guidelines

• Isolation Levels

• Performance Considerations
 Cursors
• Cursor is a mechanism by which DB2 allows an application
program to retrieve a set of (multiple) rows and processes the set
one row at a time.

• DB2 uses cursors to navigate through a set of rows returned by an

embedded SQL SELECT statement.

• Cursor can be compared to a pointer.

• In Application Program, if SELECT returns more than one row ,

then CURSOR must be used.
 Cursors (contd...)
The four (4) Cursor control statements are –

• Declare : name assigned for a particular SQL statement

• Open : readies the cursor for row retrieval; sometimes builds the
result table. However it does not assign values to the host
variables

• Fetch : returns data from the results table one row at a time and
assigns the value to specified host variables

• Close : releases all resources used by the cursor

 Cursors (contd...)
DECLARE

E.g. - For the Declare statement

EXEC SQL
DECLARE EMPCUR CURSOR FOR
SELECT Empno, Empname,Dept, Job
FROM EMP
WHERE Dept = 'D11'
FOR UPDATE OF Job
END-EXEC.
 Cursors (contd...)
OPEN
E.g. - For the Open statement

EXEC SQL
OPEN EMPCUR
END-EXEC.
 Cursors (contd...)
FETCH
E.g. - For the Fetch statement

EXEC SQL
FETCH EMPCUR
INTO :Empno, :Empname, :Dept, :Job
END-EXEC.
 Cursors (contd...)
CLOSE
E.g. - For the Close statement

EXEC SQL
CLOSE EMPCUR
END EXEC.
 Cursors (contd...)
WHENEVER

E.g. - For the Whenever Clause

EXEC SQL
WHENEVER NOT FOUND
Go To Close-EMPCUR
END EXEC.

Note :- Not recommended for use in application programs

 Cursors (contd...)
UPDATE

E.g. - For the Update statement using cursors

EXEC SQL
UPDATE EMP
Set Job = :New-job
WHERE current of EMPCUR
END EXEC.
 Some facts about Cursor
• The cursor described in previous slides is non-scrollable cursor. It
always moves sequentially forward in result table.

• When cursor is opened, the cursor is positioned before the first

row in result table.

• When first FETCH is executed, the cursor is positioned on first

row. With subsequent FETCH , it moves forward one row.

• After execution of positioned DELETE or UPDATE, the cursor

stays at the current row of result table.
 Facts ..(Contd)
• If CURRENT DATE, CURRENT TIME, CURRENT TIMESTAMP
special registers are used in cursor,DB2 determines values in
those special registers only when it OPEN the cursor. The values
obtained at OPEN time are used during all subsequent fetches.

• When a COMMIT is issued , the CURSOR gets closed in

application program. While declaring CURSOR , WITH HOLD
option can be used to avoid closing of cursor.
 Scrollable CURSOR
• To make a cursor scrollable, it is required to be declared as
scrollable.

• Declaring a scrollable cursor: To indicate that a cursor is

scrollable, you declare it with the SCROLL keyword.

EXEC SQL DECLARE C1 SCROLL CURSOR FOR

SELECT DEPTNO,DEPTNAME,MGRNO
FROM DEPT
ORDER BYDEPTNO
END-EXEC.
Positions for a scrollable cursor
Keyword in FETCH statement

• BEFORE Before the first row

• FIRST or ABSOLUTE+1 At the first row
• LAST or ABSOLUTE -1 At the last row
• AFTER After the last row
• ABSOLUTE 1 To an absolute row
number, from before the
first row forward or from
after the last row backward
• CURRENT At the current row
• NEXT or RELATIVE +1 To the next row (default)
 Examples for FETCH..
To fetch the fifth row of the result table in scrollable
CURSOR, use a FETCH statement like this:

EXEC SQL
FETCH ABSOLUTE +5 C1
INTO :HVDEPTNO,:DEPTNAME,:MGRNO
END-EXEC.

|
 Isolation Level
• The isolation level associated with an application process defines the
degree of isolation of that application process from other concurrently
executing application processes. The isolation level of an application
process, P, therefore specifies:

1. The degree to which rows read and updated by P are available to

other concurrently executing application processes
2. The degree to which update activity of other concurrently
executing application processes can affect P.

The isolation level is specified as an attribute of a package and

applies to the application processes that use the package. The
isolation level is specified in the program preparation process.
Different Isolation Level
The isolation levels are:

• Repeatable Read (RR)

• Read Stability (RS)

• Cursor Stability (CS)

• Uncommitted Read (UR)

Isolation Level Comparison
Comparison

UR CS RS RR
Can the application s ee uncommitted changes made by other Yes No No No
application proces s es ?
Can the application update uncommitted changes made by other No No No No
application proces s es ?

Can the re-execution of a s tatement be affected by other Yes Yes Yes No

application proces s es ?

Can "updated" rows be updated by other application proces s es ? No No No No

Can "updated" rows be read by other application proces s es that No No No No

are running at an is olation level other than UR?

Can "updated" rows be read by other application proces s es that Yes Yes Yes Yes
are running at the UR is olation level?

Can "acces s ed" rows be updated by other application Yes Yes No No

proces s es ?

Can "acces s ed" rows be read by other application proces s es ? Yes Yes Yes Yes
Application development guidelines

• Code modular DB2 programs and make them as small as possible

• Use unqualified SQL statements; this enables movement from one

environment to another(test to production)

• Never use ‘Select *’ in an embedded SQL program;

• Use joins rather than subqueries

 Application development guidelines
(contd...)

• Use WHERE clause and filter out data

• Use cursors when fetching multiple rows, though they add

overheads

• Use FOR UPDATE OF clause for UPDATE or DELETE with

cursor - this ensures data integrity.

• Use Inserts minimally ; use LOAD utility instead of INSERT, if the

inserts are not application dependent
 Performance Considerations
• Use the EXPLAIN utility to determine if indexes are being used
• Avoid numeric conversions
• Avoid character string padding
• Avoid an arithmetic expression in a predicate
• Do not use the SUBSTR function or concatenating columns in a
predicate
• Specify the same data type, precision, and scale when comparing
column values against host variables and literals
 Performance Considerations
• Avoid using DISTINCT
• Code predicates on indexed columns
• Use ORDER BY only when sequence is important
• Use BETWEEN rather than <= and >=
• Use IN instead of LIKE
• Joins instead of sub-queries
• Use LOCK TABLE with caution
• Periodically COMMIT WORK in batch update programs
 Handling Nulls
NULL Indicator

• To select or Insert a column that can be set to null, it must have an

indicator variable called null indicator.

• To determine the value of any nullable column , a host variable

and an indicator column are required.
 Null Indicator Values.
• The indicator variable contains one of the following values
to indicate a columns null status:

1. A –ve number indicates that the column has been set to null.
2. The value of 2 indicates that the column has been set to null as a
result of data conversion error.
3. A +ve or zero value indicates that the column is not null.
4. The indicator variable contains original length of column in case
of truncation during retrieval of data into host variable not large
enough.
 Example for Null Indicator
05 H-CUST-ADD-IND PIC S9(4) COMP.
:
:
EXEC SQL
FETCH CUR1
INTO :H-CUST-NO,
:H-CUST-NAME,
:H-CUST-ADDR1,
:H-CUST-ADDR2:H-CUST-ADD-IND
END-EXEC.
 Few SQL Codes …
• -181 The string representation of a date-time value is not a valid date-
time value
• -205 Column-name is not a column of table table-name
• -208 The order by clause is invalid because column name is not part of
the result table
• -407 An update or insert value is null, but the object column column-
name cannot contain null values
• -501 The cursor identified in a fetch or close statement is not open
• -502 The cursor identified in an open statement is already open
 Few SQL Codes
• -504 The cursor name cursor-name is not defined
• -551 The auth-id does not have the privilege to perform operation
operation on object object-name
• -811 The result of an embedded select statement is a table of more than
one row, or the result of the sub-query of a basic predicate is more than
one value
• -818 The pre-compiler-generated timestamp x in the load module is
different from the bind timestamp y
• -904 Unsuccessful execution caused by an unavailable resource.
• -911 The current unit of work has been rolled back due to deadlock or
timeout.
Day 4 - Topics
Topics to be covered in this session
• Utilities
• Security and DCL
• Locking
• Catalog Tables
• Optimizer
• Performance Tuning
 Db2 - Utilities

• Check
• Copy/MergeCopy
• Recover
• Load
• Reorg
• RunStats
• Explain
 Db2 Utilities : Check
• Checks the integrity of DB2 data structures.

• Checks the referential integrity between two tables and also checks
DB2 indexes for consistency.

• Can delete invalid rows and copies them to an exception table.

• Use CHECK DATA when loading a table without specifying the

‘ENFORCE CONSTRAINTS’ option or after the partial recovery of
tablespaces in a referential set.
 Db2 Utilities : Copy
• Used to create an imagecopy for the complete tablespace or a
partition of the tablespace - full imagecopy or incremental imagecopy.

• Every successful execution of COPY utility places in the table

SYSIBM.SYSCOPY, atleast one row that indicates the status of the
imagecopy.
 Db2 Utilities : MergeCopy
• The MERGECOPY utility combines multiple incremental image copy
data sets into a new full or incremental image copy data set
 Db2 Utilities : Recover
• Restore DB2 tablespaces and indexes to a specific instance.

• Data can be recovered for single page, pages that contain I/O errors,
a single partition or an entire tablespace.

• Indexes are always recovered from the actual table data, not from
image copy and log data, as in the case of tablespace recovery.

• Standard unit of recovery is a Tablespace.

 Db2 Utilities : Load
• To accomplish bulk inserts into DB2 table.

• Can replace the current data or append to it .i.e. LOAD DATA

REPLACE or LOAD DATA RESUME(S).

• If a job terminates in any phase of LOAD REPLACE the utility has to

be terminated and rerun.

• If a job terminates in any phase other than UTILINIT(which sets up

and initializes the LOAD utility), the tablespace must be first restored
using the full RECOVER, if LOG NO option of the LOAD was
mentioned. After the tablespace is restored, the error is to be
corrected, the utility terminated and the job rerun.
 Db2 Utilities : Reorg
• If a job terminates in any phase other than UTILINIT(which sets up
and initializes the LOAD utility), the tablespace must be first restored
using the full RECOVER, if LOG NO option of the LOAD was
mentioned.

• After the tablespace is restored, the error is to be corrected, the utility

terminated and the job rerun.
 Db2 Utilities : RunStats
• Collects statistical information for DB2 tables, tablespaces, partitions,
indexes, and columns.

• It can place this information in the catalog tables with DB2 optimizer
statistics or DBA monitoring statistics or with all statistics that have
been gathered.

• It can be used on specific SQL queries without updating the current

usable statistics.
 Db2 Utilities
ReOrg Job Stream
• The total reorg schedule should include a Runstats job or step : to
record current tablespace and index statistics to DB catalog.

• Two copy steps for each tablespace being reorganized : so that data
is recoverable. The second copy job is required after the REORG if it
was performed with a LOG NO option.

• After a REORG is run with LOG NO option, DB2 turns on the copy
pending status flag for tablespaces specified in the REORG.

• When LOG NO parameter is specified it is better to take a imagecopy

of the tablespace being reorganized immediately after REORG.

• A REBIND job for all plans using tables in any of the tablespaces
being organized.
 Db2 Utilities : Explain
• This feature can be used to obtain the details about the access paths
chosen by the DB2 optimizer for SQL statements.

• Used specifically for performance monitoring.

• When EXPLAIN is requested the access paths that the DB2 chooses
are put in coded format into the table PLAN_TABLE, which is created
in the default database.

• To EXPLAIN a single SQL statement precede that SQL statement with

the EXPLAIN Command
EXPLAIN ALL SET QUERYNO = integer
FOR SQL statement

• The other method is specifying EXPLAIN YES with the Bind command
 Db2 Utilities : Explain (contd..)
• The information provided include the type of access of particular
tables used in the SQL or Package or Plan, the order in which the
tables or joined in a JOIN, whether SORT is required and so on.

• Since the EXPLAIN results are dependent on the DB catalog, it is

better to run RUNSTATS before running a EXPLAIN.

• Then PLAN_TABLE is to be queried to get the required information.

 Db2 Security and DCL
• DB2 security is provided internal to DB2 using the DCL.

• The two (2) DCL statements used are:

 Grant.
 Revoke.
 Db2 Security and DCL
GRANT
• Grants privileges on different DB2 objects such as the Tables, Views,
Plans, Packages, Databases etc. to the required set of users.

• Is used to grant Use privileges to user on requirement.

• Is also used to grant system privileges to select few users.

• User with a SYSADM privilege will be responsible for overall control of

the system.
 Db2 Security and DCL
Syntax : GRANT <privileges> TO <users/PUBLIC>
[WITH GRANT OPTION]

E.g. GRANT SELECT, UPDATE(NAME, NO)

ON Table EMPL To A, B, C (or PUBLIC);

GRANT EXECUTE ON PLAN PLANA To USER;

Db2 Security and DCL
• Some table (or View) privileges are :
 Select, Update, Delete and Insert.

• Privileges specific to Tables are:

 Alter & Index (create).

• There are no specific DROP privileges; the table can be dropped

by its owner or a SYSADM.

• A user having authority to grant privilege to another, also has the

authority to grant the privilege with “with the GRANT Option”.
 Db2 Security and DCL
REVOKE
• Revoke is primarily used to revoke the privileges given to a user on
specific Objects.
• The user granting the privileges has the authority to Revoke also.
• It is not possible to be column specific when revoking an Update
privilege.
• Revoke is primarily used to revoke the privileges given to a user on
specific Objects.
• The user granting the privileges has the authority to Revoke also.
• It is not possible to be column specific when revoking an Update
privilege.
 Db2 Security and DCL
Syntax : REVOKE <privileges> FROM <user/PUBLIC>

E.g. REVOKE ALL ON Table EMPL

FROM A, B, C (or PUBLIC);

REVOKE Bind ON PLAN PLANA FROM USER;

 Db2 Locking
• Why Locking ?
‘Locking is used to provide multiple user access to the same system’.
• How does DB2 manage locking ?
DB2 uses locking services provided by an MVS subsystem
called the IMS Resource Lock Manager(IRLM).

The above is based on Transaction Processing - the system

component that provides this is ‘TRANSACTION MANAGER’
COMMIT & ROLLBACK are key methods of implementing
this.
 Db2 Locking : Explicit Locking
• The SQL statement LOCK TABLE.

• The ISOLATION parameter on the BIND PACKAGE command - the

two possible values are RR(‘Repeatable Read’) & CS(‘Cursor
Stability’).

• CS is the value specified if the application program is used in an

online environment.

• The tablespace LOCKSIZE parameter - physically DB2 locks data in

terms of pages or tables or tablespaces. This parameter is specified in
‘CREATE or ALTER Tablespace’ option ‘LOCKSIZE’. The options are
‘Tablespace’, ‘Table’, ‘Page’ or ‘Any’.
 Db2 Locking : Explicit Locking
• The ACQUIRE/RELEASE parameters on the BIND PLAN command
specifies when table locks(which are implicitly acquired by DB2) are to
be acquired and released.

Types :
– ACQUIRE
• Use
• Allocate
– RELEASE
• Commit
• Deallocate
 Db2 Locking
• Db2 support locking at three levels:
– Table Space
– Table
– Page

• Locks cannot be taken at a lower level, without compatible higher-

level lock is also being taken.
 Db2 : Catalog Tables
• Repository for all DB2 objects - contains 43 tables.

• Each table maintains data about an aspect of the DB2 environment.

• The data refers to information about tablespaces, tables, indexes,

privileges, on utilities run on DB2 and so on E.g. :
SYSIBM.SYSTABLES, SYSINDEXES/SYSCOLUMNS ......’
 Db2 : Catalog Tables
• When standard DB2 SQL is used, the DB2 catalog is either accessed
or updated. e.g.. When a ‘CREATE TABLE’ statement is issued the
catalog tables SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS &
SYSIBM.SYSFIELDS are updated.

• However the DB2 catalog is semi active only. This is because updates
to number of rows, the physical order of the rows for a set of keys and
the like are updated only after running a RUNSTATS utility.

• DB2 catalog is integrated - DB2 catalog and DB2 DBMS are inherently
bound together.
Db2 : Catalog Tables
It is nonsubvertible - DB2 catalog cannot be updated behind DB2’s
back. i.e. if a table of 10 columns is created, it is not possible to go
and change the number of columns directly on the catalog to 15. It has
to be done using the standard SQL statements for dropping and
recreating the table .
Db2 : Catalog Tables

All catalogue tables have a table qualifier of ‘SYSIBM’ –

• SYSIBM.SYSTABLESPACE – Table spaces in DB2

• SYSIBM.SYSTABLES – All tables in DB2
• SYSIBM.SYSTABAUTH – Table Authorization
• SYSIBM.SYSCOLUMNS – Columns of all tables with attributes
• SYSIBM.SYSVIEWS – All views definitions
• SYSIBM.SYSPLAN – Plans in DB2
• SYSIBM.SYSPLANAUTH – Plan Authorization
• SYSIBM.SYSINDEXES – Indexes created on tables
 Db2 : Optimizer
• Analyzes the SQL statements and determines the most efficient way
to access data - gives Physical data independence.
• It evaluates the following factors : CPU cost, I/O cost, DB2 catalog
statistics & the SQL statement.
• It estimates CPU time, cost involved in applying predicates, traversing
pages and sorting.
• It estimates the cost of physically retrieving and writing the data.
• The information pertaining to the state of the tables that will be
accessed by the SQL statements are provided by the Catalog.
 Db2 : Performance Tuning
• The performance of an application can be monitored and enhanced in
the application, as well as at the database level.
• In application side the SQL’s can be tuned to make them more
efficient, and avoid redundancy.
• It is better to structure the SQLs so that they perform only the
necessary operations.
• On the database side, the major enhancements can be done to the
definitions of tables, indexes & the distribution of tablespace and
indexspace.
• The application run statistics are obtained from EXPLAIN or DB2PM
(DB2 Performance Monitor) report.
Questions??