DB2 Editions

Express 9 / Express C-9 Workgroup 9 Enterprise 9

Free edition Subscription Subscription
Linux, Windows Linux, Windows Linux, Windows
32 & 64 bit platforms 32 & 64 bit platforms 32 & 64 bit platforms
1-2 CPU server 1-4 CPU server No Limit
4 GB RAM memory 16 GB RAM memory No limit
No MQTs, Query Parallelism No MQTs, Query Parallelism Included MQTs, Query
or Multidimensional Clustering or Multidimensional Clustering Parallelism or
(MDC) (MDC) Multidimensional Clustering
(MDC)

Administration and Development tools

Tool Command Description

DB2 Enterprise Relational Database Management System
DB2 Control Center db2cc GUI database master console, control,
DB2 Web Query Tool management, auto login, recovery, etc.
DB2 Recovery Expert
DB2 High Perf Unload
DB2 Performance Expert
DB2 Command Editor db2ce GUI level line oriented & script saving database
Access
DB2 Command Line db2 OS level line oriented database access
Processor
DB2 Configuration db2ca Node cataloging & connecting, networking
Assistant
DB2 Visual Explain Query db2exfmt Database event info. collection & analysis
analysis & visual explains db2expln
DB2 Table Editor Forms creation, development, usage
Developer Suite
DB2 Query Patroller Query & session monitoring
DB2 Developer Stored procedure & other object development
Workbench
Visual Age Family Java & web development & object modeling
WebSphere Studio
Net.Data
IBM Content Manager
DB2 Data Warehouse Data Warehouse building , data movement,
Manager Management
DB2 Data Propagator
IBM Data Refresher
WebSphere Inf. Integrator
Vality Integrity Data cleansing
Information Catalog Metadata sourcing
DB2 OLAP Server OLAP, data marts, cubes
Data Warehouse Center
QMF Reporting in all its forms
DB2 Web Query Tool for
Multiplatforms
DB2 Intelligent Miner Data mining
DB2 OLAP Server Miner
DB2 Database Architecture

Local client communicates with UDB server using shared memory and semaphores.
Remote client communicates using protocol such as NPIPE, TCP/IP, NetBIOS, and SNA.

On the server side, communication and data transfer activity is performed by Engine
Dispatchable Unit (EDU). EDUs are shown as circle or group of circles in above diagram. It runs
as a process on UNIX.

A set of sub agents is assigned to particular client application request. Multiple sub agents can be
assigned if the machine where server resides has multiple processors or is part of partitioned
database. All agents and sub agents are managed using pooling algorithm that minimizes the
creation and destruction of EDUs.

Page Cleaner and Prefetchers are common type of EDUs.

Prefetchers retrieve data from the disk and move it to buffer pool before applications need data.
Agents of the application send asynchronous read-ahead request to a common pre-fetch queue.
Pre cleaners move the data from buffer pool back to disk. Page cleaners are backgrouind EDU
independent of application agents. They look for pages in the buffer pool that are no longer
needed and write the pages to disk.
DB2 Memory Organization

Database Shared Memory (also known as Database Global Memory) is allocated when a
database is activated or connected to for the first time. This memory is used across all
applications that might connect to the database. Database Shared Memory can be controlled by
the database_memory configuration parameter.

Many different memory areas are contained in database shared memory including:

 Buffer pools
 Lock list
 Database heap - and this includes the log buffer .
 Utility heap
 Package cache
 Catalog cache

Application shared memory (also known as application global memory) is allocated when an
application connects to a database only in a partitioned database environment, or in a non-
partitioned database with intra-parallelism enabled, or if the connection concentrator is enabled.
This memory is used by agents that do the work requested by clients connected to the database.

Agent/local application shared memory. This memory is used for SQL request and response
communications between an agent and its client application.
DB2 Table spaces

Table space is logical grouping of memory areas in database.

Default table spaces in DB2:

1) Catalog table space

There is only one catalog table space per database. It is created when the CREATE
DATABASE command is issued. SYSCATSPACE catalog table space holds the system
catalog tables.
2) Regular table spaces
Regular table spaces hold table data and indexes. It can also hold long data such as
Large Objects (LOBs) unless they are explicitly stored in long table spaces. A table and
its indexes can be segregated into separate regular table spaces, if the table spaces are
database managed space (DMS). At least one regular table space must exist for each
database. The default is named USERSPACE1 when the database is created.
3) System temporary table spaces
System temporary table spaces are used to store internal temporary data required during
SQL operations such as sorting, reorganizing tables, creating indexes, and joining tables.
At least one must exist per database. The default created with the database is named
TEMPSPACE1.

Other table spaces in DB2:

1) Long table spaces

Long table spaces are used to store long or LOB table columns and must reside in DMS
table spaces. They can also store structured type columns or index data. If no long table
space is defined, then LOBs will be stored in regular table spaces. Long table spaces are
optional.
2) User temporary table spaces
User temporary table spaces store declared global temporary tables. No user temporary
table spaces exist when a database is created. At least one user temporary table space
should be created to allow definition of declared temporary tables. User temporary table
spaces are optional.

Single table space can span several containers. Container is made of data pages. Number of
pages that the database writes to container before using different container is called extent size.
Table space management

Table spaces can be managed two different ways:

System managed space (SMS)

SMS table spaces are managed by the operating system. Containers are defined as regular
operating system files and they are accessed via operating system calls. The regular operating
system functions will handle the following:
- I/O will be buffered by the operating system
- space will be allocated according to the operating system conventions, and
- the table space is automatically extended when it is necessary.
However, containers cannot be dropped from SMS table spaces, and adding new ones is
restricted to partitioned databases. The three default table spaces explained in the previous
section are SMS.

Database managed space (DMS)

DMS table spaces are managed by DB2. Containers can be defined either as files (which will be
fully allocated with the size given when the table space is created) or devices. DB2 will manage
as much of the I/O as the allocation method and the operating system will allow. Extending the
containers is possible by using the ALTER TABLESPACE command. Unused portions of DMS
containers can be also released.

Container and extents in table space

Buffer Pool

Buffer pool are areas of database server memory where database pages of user table data, index
data and catalog data are temporarily moved and can be modified.

Data can be accesses much faster from buffer pool than from disk. Adequate buffer pool size
improves performance by reducing I/O and carrying out most of the work in memory.

Default IBMDEFAULTBP buffer pool is created which is shared by all table spaces. More buffer
pool can be added later of different size.

LONG VARCHAR, BLOB, CLOB data types are directly referred from disk using non-buffered IO.

Table space can only be associated with one Buffer pool but one Buffer pool can be used for
more than one table space.

Page size of the buffer pool should be same or grater than Page size of table space associated
with it. Default Buffer pool page size is 4KB. The size can be 8KB, 16KB, and 32KB etc.

Indexes (Unique, non-Unique, Clustered)

Unique Index
DB2® uses unique indexes to ensure that no identical key values are stored in a table.
When you create a table that contains a primary key, you must create a unique index for that
table on the primary key. DB2 marks the table as unavailable until the explicit creation of the
required indexes. You cannot define a foreign key unless the corresponding primary key already
exists and has a unique index defined on it.

Non Unique Index

Use non-unique indexes to improve the performance of data access when the values of the
columns in the index are not necessarily unique.

Clustered Indexes
In Clustered indexes order of the rows in the table is in the same physical order as the desired
result set. Clustered indexes allow for a more linear access pattern to data pages and more
effective pre fetching, and help avoid sorts. It leads to longer inserts, but quicker selects.
Tips for Cluster Index
- Do not create clustered indexes on volatile tables as the index will not be used.
- For best performance, create the index over small data types (like integer and char(10)),
unique columns, and columns most often used in range searches.
- Increasing free space on data and index pages to about 15-35 (instead of the default 10
for PCTFREE) for high volumes of inserts.
- For heavily insert Tables, use a single dimension MDC table (perhaps using a generated
column like idcolumn/1000 or INT (date)/100). This will cause the data to be block
indexed (on the dimension) rather than on the row. The resulting index is smaller and log
contention is significantly reduced during insert.

Use ALLOW REVERSE SCANS to allow for an index to be scanned bi-directionally, which
means quicker retrieval of ascending and descending result sets. This has no negative
performance impact since the index structure does not change internally to support this feature.

INCLUDE can be used to include additional non-indexed columns in the index page to promote
index-only access and avoid data page fetches.
TYPE-2 INDEXES drastically reduce next-key locking, allow for index columns greater than 255
bytes by default, allow for both online REORG and RUNSTATS, and support the new
multidimensional clustering ability. All new indexes in v8 will be created as type-2 except when
there was already a (pre-migration) type-1 index defined on the table. Use REORG INDEXES to
convert type-1 to type-2 indexes.

Isolation level and locking

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 therefore specifies:
 The degree to which the rows read and updated by the application are available to
other concurrently executing application processes.
 The degree to which the update activity of other concurrently executing application
processes can affect the application.

Depending on the type of lock, this limits or prevents access to the data by concurrent application
processes. (Declared temporary tables and their rows cannot be locked because they are only
accessible to the application that declared them.)

Three general categories of locks:

o Share
Limits concurrent application processes to read-only operations on the data.
o Update
Limits concurrent application processes to read-only operations on the data, if these
processes have not declared that they might update the row. The database manager
assumes that the process currently looking at a row may update it.
o Exclusive
Prevents concurrent application processes from accessing the data in any way. Does not
apply to application processes with an isolation level of uncommitted read, which can
read but not modify the data.

Locking occurs at the base table row. The database manager, however, can replace multiple row
locks with a single table lock. This is called lock escalation.

The DB2(R) Universal Database database manager supports four isolation levels. Regardless of
the isolation level, the database manager places exclusive locks on every row that is inserted,
updated, or deleted. Thus, all isolation levels ensure that any row that is changed by this
application process during a unit of work is not changed by any other application processes until
the unit of work is complete.

The isolation levels are:

 Repeatable Read (RR)
This level ensures that:
o Any row read during a unit of work is not changed by other application processes until the
unit of work is complete. The rows are read in the same unit of work as the corresponding
OPEN statement. Use of the optional WITH RELEASE clause on the CLOSE statement
means that any guarantees against non-repeatable reads and phantom reads no longer
apply to any previously accessed rows if the cursor is reopened.
o Any row changed by another application process cannot be read until it is committed by
that application process.
The Repeatable Read level does not allow phantom rows to be viewed (see Read Stability).
In addition to any exclusive locks, an application process running at the RR level acquires at
least share locks on all the rows it references. Furthermore, the locking is performed so that
 the application process is completely isolated from the effects of concurrent application
processes.
 Read Stability (RS)
Like the Repeatable Read level, the Read Stability level ensures that:
o Any row read during a unit of work is not changed by other application processes until the
unit of work is complete. The rows are read in the same unit of work as the corresponding
OPEN statement. Use of the optional WITH RELEASE clause on the CLOSE statement
means that any guarantees against non-repeatable reads no longer apply to any
previously accessed rows if the cursor is reopened.
o Any row changed by another application process cannot be read until it is committed by
that application process.
Unlike Repeatable Read, Read Stability does not completely isolate the application process
from the effects of concurrent application processes. At the RS level, application processes
that issue the same query more than once may see additional rows caused by other
application processes appending new information to the database. These additional rows are
called phantom rows.
For example, a phantom row can occur in the following situation:
o Application process P1 reads the set of rows n that satisfy some search condition.
o Application process P2 then inserts one or more rows that satisfy the search
condition and commits those new inserts.
o P1 reads the set of rows again with the same search condition and obtains both the
original rows and the rows inserted by P2.
In addition to any exclusive locks, an application process running at the RS isolation level
acquires at least share locks on all the qualifying rows.
 Cursor Stability (CS)
Like the Repeatable Read level, the Cursor Stability level ensures that any row that was
changed by another application process cannot be read until it is committed by that
application process.
Unlike Repeatable Read, Cursor Stability only ensures that the current row of every
updatable cursor is not changed by other application processes. Thus, the rows that were
read during a unit of work can be changed by other application processes.
In addition to any exclusive locks, an application process running at the CS isolation level
acquires at least a share lock on the current row of every cursor.
 Uncommitted Read (UR)
For SELECT INTO, FETCH with a read-only cursor, fullselect in an INSERT, row fullselect in
an UPDATE, or scalar fullselect (wherever it is used), the Uncommitted Read level allows:
o Any row read during a unit of work to be changed by other application processes.
o Any row changed by another application process to be read, even if the change has
not been committed by that application process.
For other operations, rules associated with the CS level apply.

Comparison of isolation levels

The following table summarizes information about isolation levels.
  UR CS RS RR
Can the application see uncommitted
changes made by other application Yes No No No
processes?
Can the application update uncommitted
changes made by other application No No No No
processes?
Can the re-execution of a statement be
affected by other application processes? Yes Yes Yes No
See phenomenon P3 (phantom) below.
   UR CS RS RR
Can "updated" rows be updated by other
No No No No
application processes? See Note 1 below.
Can "updated" rows be read by other
application processes that are running at an No No No No
isolation level other than UR?
Can "updated" rows be read by other
application processes that are running at Yes Yes Yes Yes
the UR isolation level?
Can "accessed" rows be updated by other
application processes? See phenomenon Yes Yes No No
P2 (nonrepeatable read) below.
Can "accessed" rows be read by other
Yes Yes Yes Yes
application processes?
Can "current" row be updated or deleted by
See Note 2 See Note 2
other application processes? See No No
below. below.
phenomenon P1 (dirty-read) below.
Notes:
1. The isolation level offers no protection to the application if the application is both
reading and writing a table. For example, an application opens a cursor on a table
and then performs an insert, update, or delete operation on the same table. The
application may see inconsistent data when more rows are fetched from the open
cursor.
2. If the cursor is not updatable, with CS the current row may be updated or deleted by
other application processes in some cases. For example, buffering may cause the
current row at the client to be different than what the current row actually is at the
server.
Examples of Phenomena:
P1
Dirty Read. Unit of work UW1 modifies a row. Unit of work UW2 reads that row
before UW1 performs a COMMIT. If UW1 then performs a ROLLBACK, UW2
has read a nonexistent row.
P2
Nonrepeatable Read. Unit of work UW1 reads a row. Unit of work UW2
modifies that row and performs a COMMIT. If UW1 then re-reads the row, it
might receive a modified value.
P3
Phantom. Unit of work UW1 reads the set of n rows that satisfies some search
condition. Unit of work UW2 then INSERTs one or more rows that satisfies the
search condition and performs a COMMIT. If UW1 then repeats the initial read
with the same search condition, it obtains the original rows plus the inserted
rows.

REORG indexes / table:

Reorganizes index or a table.
Index option reorganizes all indexes defined on a table by rebuilding the index data into un-
fragmented, physically contiguous pages. CLEANUP ONLY option performs cleanup without
rebuilding index.
Table option reorganizes table by reconstructing rows to eliminate fragmented data, and by
compacting information.
RUNSTATS (FOR INDEXES & AND INDEXES):
Updates statistics about the physical characteristics of a table and the associated indexes. These
characteristics include number of records, number of pages, and average record length. The
optimizer uses these statistics when determining access paths to the data.
It is recommended to run the RUNSTATS command:
 On tables that have been modified considerably (for example, if a large number of
updates have been made, or if a significant amount of data has been inserted or deleted
or if LOAD has been done without the statistics option during LOAD)
 On tables that have been reorganized (using REORG, REDISTRIBUTE DATABASE
PARTITION GROUP)
 When a new index has been created.
 Before binding applications whose performance is critical.
 When the prefetch quantity is changed

REBIND
After performing a REORG and RUNSTATS, you will want to REBIND all database packages so
that their static SQL can take advantage of the most recent system stat.

Performance Improvement

http://www.ibm.com/developerworks/data/library/techarticle/dm-0404mcarthur/

MDC
http://www.ibm.com/developerworks/data/library/techarticle/dm-0404mcarthur/

Partitioning
http://www.ibm.com/developerworks/data/library/techarticle/dm-0404mcarthur/
Diff between Oracle and DB2 and Teradata

Category Oracle DB2

Storage Logical Block -> Extent -> Segment -> Table Data Page -> Container -> Table
space -> Database space -> Database

Storage Physical Block -> Data File Data Page -> Container
Tablespaces Locally Managed SMS
Bigfile DMS
Temporary
Default (SYSTEM, SYSAUX) (Catalog, Temp, System) SMS
Indexes Unique Unique
Non-unique Non unique
Partitioning Clustering
Function based
Bit map
Optimizer Rules bases Cost based
Cost based