CL464GCourse Guide

®
Course Guide
Db2 11.1 Advanced
Database Administration
Course code CL464G ERC 1.0
IBM Training
Preface
June 2018
NOTICES
This information was developed for products and services offered in the USA.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for
information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to
state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any
non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America
The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these
changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the
program(s) described in this publication at any time without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of
those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information
concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available
sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the
examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and
addresses used by an actual business enterprise is entirely coincidental.
TRADEMARKS
IBM, the IBM logo, ibm.com, Db2 and pureScale are trademarks or registered trademarks of International Business Machines Corp., registered in
many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is
available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.
Adobe, and the Adobe logo, are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other
countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
© Copyright International Business Machines Corporation 2018.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
© Copyright IBM Corp. 1997, 2018 P-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Preface
Contents
Preface................................................................................................................. P-1
Contents ............................................................................................................. P-3
Course overview................................................................................................. P-9
Document conventions ..................................................................................... P-12
Demonstrations ................................................................................................ P-13
Additional training resources ............................................................................ P-14
IBM product help .............................................................................................. P-15
Advanced monitoring ........................................................................... 1-1
Unit objectives .................................................................................................... 1-3
Characteristics of in-memory metrics
used to support the monitor table functions ................................................... 1-4
Focus areas for in-memory metrics .................................................................... 1-6
In-memory metrics: System ................................................................................ 1-7
In-memory metrics: Data objects ........................................................................ 1-8
In-memory metrics: Activity perspective ............................................................. 1-9
Controls for collecting monitor data .................................................................. 1-10
Monitoring system information using table functions......................................... 1-12
Monitoring time spent waiting for resources...................................................... 1-14
Additional time-related metrics ......................................................................... 1-15
Additional wait times reported........................................................................... 1-16
Example of query using the XML document
returned by MON_GET_CONNECTION_DETAILS ..................................... 1-17
Monitoring administrative views simplify access to important metrics ............... 1-19
Monitoring performance with SQL: Buffer pools ............................................... 1-21
Monitoring performance with SQL: Sorts .......................................................... 1-22
Monitoring performance with SQL: Top dynamic SQL statements .................... 1-23
Monitoring performance with SQL: Long-running SQL ..................................... 1-24
Monitoring performance with SQL application wait times .................................. 1-26
Monitoring performance with SQL: Lock chains................................................ 1-27
Monitoring performance with SQL: Lock memory usage .................................. 1-28
Monitoring performance with SQL: Lock escalations, deadlocks and timeouts . 1-29
Monitoring performance with SQL queries that have a high prep time .............. 1-30
Monitoring performance with SQL: Costly table scans...................................... 1-31
Monitoring prefetch efficiency of applications ................................................... 1-33
Monitoring performance: Database memory usage .......................................... 1-34
Using MONITOR functions with database partitioning ...................................... 1-35
Monitor performance with SQL: Index usage with multiple database partitions 1-36

Preface
Monitor log space usage

with the table function MON_GET_TRANSACTION_LOG........................... 1-37
Monitor health: Oldest transaction holding log space........................................ 1-38
Monitor health: Table space size ...................................................................... 1-39
Database recovery: Split mirror copy planning ................................................. 1-40
Tracking monitor history ................................................................................... 1-41
Demonstration 1: Db2 advanced monitoring with SQL ..................................... 1-42
Unit summary ................................................................................................... 1-63
Db2 Table Space Management ............................................................. 2-1
Unit Objectives ................................................................................................... 2-3
DMS and Automatic Storage table space characteristics ................................... 2-4
DMS table spaces: Internal structure .................................................................. 2-6
Table space management: High Water Marks .................................................... 2-8
High Water Mark: Dropped table (Example 1) .................................................. 2-10
High Water Mark: Dropped table (Example 2) .................................................. 2-11
High Water Mark: Offline table REORG
with no temporary tablespace (Example 1) .................................................. 2-12
High Water Mark: Offline table REORG
with no temporary tablespace (Example 2) .................................................. 2-13
Using MON_GET_CONTAINER and
MON_GET_TABLESPACE to check space allocations ............................... 2-14
Db2 functions to reclaim unused storage .......................................................... 2-15
Reclaiming space using ALTER TABLESPACE with Automatic Storage ......... 2-16
Reclaimable Automatic Storage: Example 1 ..................................................... 2-18
Reclaimable Automatic Storage: Example 2 ..................................................... 2-19
Checking table spaces for reclaimable storage ................................................ 2-20
Reclaimable storage: Monitoring the processing .............................................. 2-21
Table space extent allocation: Example 1 ........................................................ 2-22
Table space maps: ALTER TABLESPACE ADD example ............................... 2-24
Monitoring the Rebalancer: LIST UTILITIES..................................................... 2-26
Rebalancer: db2diag.log Status messages ...................................................... 2-27
Extent Allocations using ALTER NEW STRIPE SET ........................................ 2-28
Moving a DMS managed tablespace
to new containers Online using ALTER TABLESPACE ............................... 2-29
Example of Auto-growth stopping for DMS ....................................................... 2-30
Using Storage Groups for Automatic storage table spaces............................... 2-33
Query storage groups with SQL using the table function
ADMIN_GET_STORAGE_PATHS ................................................................... 2-34
Listing storage groups with the db2pd command.............................................. 2-36
Changing the storage group for an Automatic Storage table space .................. 2-37
Tablespace rebalance can be suspended using ALTER TABLESPACE .......... 2-38

Preface
Monitoring extent movement for when the storage group is altered for a table
space ............................................................................................................... 2-39
Table space growth with Automatic Storage ..................................................... 2-40
Automatic Storage Rebalance to use newly added storage paths .................... 2-41
Dropping storage paths: Example .................................................................... 2-42
Converting a DMS table space to use Automatic Storage ................................ 2-44
Example converting a DMS managed tablespace to use Automatic storage .... 2-46
Unit summary ................................................................................................... 2-70
Db2 Database Memory Management ................................................... 3-1
Unit objectives .................................................................................................... 3-3
Db2 Database and Instance memory configuration ............................................ 3-4
Defining limits for memory usage ....................................................................... 3-7
Database shared memory .................................................................................. 3-9
Db2’s database memory model: Inside the set ................................................. 3-11
Database memory configuration options .......................................................... 3-12
Overflow Buffer can be used for dynamic memory configuration changes ........ 3-14
Overflow Buffer can be used to handle peak memory demands for some heaps . 3-
15
Database buffer pools ...................................................................................... 3-16
db2pd: Buffer Pools report................................................................................ 3-18
Online Memory configuration considerations .................................................... 3-19
Database heap memory ................................................................................... 3-20
Monitoring catalog cache.................................................................................. 3-22
Dynamic and Static SQL caching ..................................................................... 3-24
Check dynamic SQL cache stats with db2pd .................................................... 3-26
Monitoring the package cache .......................................................................... 3-27
Utility Heap memory: Util_Heap_SZ ................................................................. 3-29
Db2 Sorting methods ........................................................................................ 3-31
Database Shared Sort memory management................................................... 3-33
Monitoring sort performance and memory utilization ........................................ 3-34
Monitoring sort processing using SQL .............................................................. 3-36
Monitoring database shared sort memory using SQL ....................................... 3-37
db2mtrk: Memory tracker command ................................................................. 3-38
Database and Instance memory display: db2mtrk ............................................ 3-40
Monitoring the overall memory usage using the MON_GET_MEMORY_SET table
function............................................................................................................. 3-41
How does STMM work? ................................................................................... 3-42
STMM: In each tuning interval .......................................................................... 3-43
Automatic management of selected memory heaps ......................................... 3-45
STMM modes of operation ............................................................................... 3-46
STMM and the buffer pools .............................................................................. 3-48

Preface
STMM in action: BP sizes during tuning ........................................................... 3-49

STMM in action: Two databases on the same server ....................................... 3-50
STMM in action: Two databases on the same server – Results ....................... 3-51
STMM and Sort memory .................................................................................. 3-52
STMM and Lock memory ................................................................................. 3-54
STMM in action: Tuning an OLTP workload ..................................................... 3-55
STMM in action: OLTP workload results........................................................... 3-56
Configuration changes: Activating Self Tuning Memory.................................... 3-57
Configuration changes for STMM ..................................................................... 3-59
Configuration changes: Deactivating Self Tuning Memory................................ 3-61
Unit summary ................................................................................................... 3-76
Database rebuild support ..................................................................... 4-1
Unit objectives .................................................................................................... 4-3
Database restore options without using the REBUILD option ............................. 4-4
Example: Database partial copy without using REBUILD ................................... 4-7
REBUILD option for RESTORE .......................................................................... 4-9
Contents of Db2 database and table space backups ........................................ 4-11
Database disaster recovery using REBUILD .................................................... 4-13
Database recovery: Rebuild from TS backups.................................................. 4-15
Database partial copy using REBUILD ............................................................. 4-17
Database rebuild using one TS backup image ................................................. 4-19
Nonrecoverable database partial restore REBUILD.......................................... 4-21
Table space point in time recovery using REBUILD ......................................... 4-23
Considerations for using RESTORE with REBUILD ......................................... 4-25
Monitoring database rebuild ............................................................................. 4-29
LIST HISTORY for RESTORE with REBUILD .................................................. 4-30
Demonstration 1: Rebuilding a database .......................................................... 4-33
Unit summary ................................................................................................... 4-48
Db2 database and tablespace relocation ............................................ 5-1
Unit objectives .................................................................................................... 5-3
Backup image contents ...................................................................................... 5-4
Container information in a backup image ........................................................... 5-6
Db2 RESTORE: Container damaged ................................................................. 5-7
Redirected restore: Overview ............................................................................. 5-8
Step 1: Start the redirected restore ..................................................................... 5-9
Step 2a: Check tablespace ID and size ............................................................ 5-10
Step 2b: Check container information ............................................................... 5-11
Step 3: Set container definition ......................................................................... 5-12
Step 4: Complete restore processing................................................................ 5-13
Changing Automatic Storage paths .................................................................. 5-14

Preface
Generating a redirected restore script .............................................................. 5-15

Db2 RESTORE: Restore to disaster site .......................................................... 5-18
Converting a DMS table space to use Automatic Storage ................................ 5-19
ALTER TABLESPACE Add: After backup ........................................................ 5-21
Copying schemas of objects from one database to another using db2move .... 5-23
Copying schemas of objects from one database to another using RESTORE
with TRANSPORT ....................................................................................... 5-25
Objects that can be transported using the TRANSPORT option of RESTORE . 5-26
Transportable sets ............................................................................................ 5-28
Db2 RESTORE: TRANSPORT......................................................................... 5-30
Processing performed by RESTORE TRANSPORT ......................................... 5-31
db2relocatedb command .................................................................................. 5-32
Changing log-related options using db2relocatedb ........................................... 5-36
Using db2relocatedb after copying containers .................................................. 5-37
Copying a Db2 database to a new instance...................................................... 5-38
Run db2relocatedb in new instance after copy ................................................. 5-39
Demonstration 1: Db2 tablespace relocation and transportation....................... 5-40
Unit summary ................................................................................................... 5-56
Db2 Incremental backup ....................................................................... 6-1
Unit objectives .................................................................................................... 6-3
Database Backup and Recovery issues ............................................................. 6-4
Full versus Incremental backups ........................................................................ 6-6
Delta versus Incremental backups ...................................................................... 6-8
Incremental backup: Impact ............................................................................. 6-10
Mixed Delta and Incremental backups .............................................................. 6-12
Incremental backups with Circular logging ....................................................... 6-14
Incremental database backups ......................................................................... 6-15
Implementation of Incremental backup ............................................................. 6-16
Backup Utility options ....................................................................................... 6-17
Db2 Incremental BACKUP command examples ............................................... 6-18
Tracking updates to table spaces and pages.................................................... 6-19
Building a new Delta backup (Option 1)............................................................ 6-21
Building a new Incremental backup (Option 2) ................................................. 6-22
Using MON_GET_TABLESPACE to check incremental backup status
for tablespaces ............................................................................................ 6-23
Incremental backup: Read and Write I/O .......................................................... 6-25
Incremental Backup: db2diag.log ..................................................................... 6-27
Database design for Incremental backups ........................................................ 6-28
Incremental Restore: Overview ........................................................................ 6-30
RESTORE DATABASE command options ....................................................... 6-32
Incremental Restore: Automatic ....................................................................... 6-33

Preface
Incremental Restore Automatic: db2diag.log .................................................... 6-35

Incremental Restore: Manual............................................................................ 6-36
db2ckrst: Check Incremental Restore ............................................................... 6-38
Monitor Incremental Restore using LIST UTILITIES ......................................... 6-39
Incremental Restore: Rollforward table space .................................................. 6-40
Demonstration 1: Incremental Backup and Restore.......................................... 6-42
Unit summary ................................................................................................... 6-58

Preface
Course overview
Preface overview
This course provides detailed technical information on the management of Db2
database servers by database administrators. The following database management
skills will be covered:
• Perform advanced monitoring using the Db2 administrative views and routines in
SQL queries.
• Manage the disk space assigned in Database Managed Storage (DMS) and
Automatic Storage table spaces to optimize disk space utilization.
• Use SQL queries and Db2 commands to check the high water mark on table
spaces and to monitor a rebalance operation.
• Utilize the REBUILD option of RESTORE, which can build a database copy with
a subset of the tablespaces using either database or tablespace backup images.
• Plan and execute the TRANSPORT option of RESTORE to copy schemas of
objects between two Db2 databases.
• Create incremental database or tablespace level backups to reduce backup
processing time and backup image storage requirements.
• Implement automatic storage management for table spaces and storage groups
or enable automatic resize options for DMS managed table spaces to reduce
administration requirements and complexity.
• Describe the various types of database memory including buffer pools, sort
memory, lock memory and utility processing memory.
• Adjust database or Db2 instance configuration options to improve application
performance or processing efficiency.
• Implement Db2 Self Tuning Memory management for specific database memory
areas
The lab demonstrations are performed using Db2 11.1.2.2 for Linux.

Preface
Intended audience
This is an advanced course for DBAs and technical individuals who plan, implement,
and maintain Db2 11.1 databases.
Topics covered
Topics covered in this course include:
• Advanced Monitoring
• Db2 Table Space Management
• Db2 Database Memory Management
• Database rebuild support
• Db2 database and tablespace relocation
• Db2 Incremental Backup

Preface
Course prerequisites
Participants should have the following skills:
• Perform basic database administration tasks for a Db2 database server, including
using Db2 commands like BACKUP and RESTORE
• Utilize Structured Query Language (SQL) and be able to construct DDL, DML,
and authorization statements
• These skills can be developed by taking the course CL207 Db2 11.1
Administration Workshop for Linux

Preface
Document conventions
Conventions used in this guide follow Microsoft Windows application standards, where
applicable. As well, the following conventions are observed:
• Bold: Bold style is used in demonstration and exercise step-by-step solutions to
indicate a user interface element that is actively selected or text that must be
typed by the participant.
• Italic: Used to reference book titles.
• CAPITALIZATION: All file names, table names, column names, and folder names
appear in this guide exactly as they appear in the application.
To keep capitalization consistent with this guide, type text exactly as shown.

Preface
Demonstrations
Demonstrations format
Demonstrations are designed to provide hands on experience with some of the key
concepts and skills covered by the lecture content.
The demonstrations for this course include the following:
• Using the Db2 monitor functions and views to analyze a series of database
activities including disk space utilization, log space utilization and data access
efficiency.
• Using ALTER TABLESPACE commands to allocate disk space, reduce unused
disk space and convert a DMS managed tablespace to use automatic storage
management and to move a tablespace to new disks without losing access to the
data.
• Execute and measure the performance differences for a SQL workload with two
different database memory configurations.
• Utilize the REBUILD mode of the RESTORE utility to recover a subset of
database tablespaces using a set of tablespace level backup images.
• Run Db2 commands including db2relocatedb and a redirected RESTORE to
alter the files allocated for Db2 tablespaces. Use the TRANSPORT mode of
RESTORE to copy a set of database objects from one database to another.
• Create a set of Db2 backup images using full and incremental backups to
observe the savings in backup processing and backup storage requirements.
Perform an automatic incremental restore of a tablespace.
The demonstrations utilize Db2 11.1.2.2 on Linux.

Preface
Additional training resources

• Visit IBM Analytics Product Training and Certification on the IBM website for
details on:
• Instructor-led training in a classroom or online
• Self-paced training that fits your needs and schedule
• Comprehensive curricula and training paths that help you identify the courses
that are right for you
• IBM Analytics Certification program
• Other resources that will enhance your success with IBM Analytics Software
• For the URL relevant to your training requirements outlined above, bookmark:
• Information Management portfolio:
http://www-01.ibm.com/software/data/education/
• Predictive and BI/Performance Management/Risk portfolio:
http://www-01.ibm.com/software/analytics/training-and-certification/

Preface
IBM product help

Help type When to use Location
Task- You are working in the product and IBM Product - Help link
oriented you need specific task-oriented help.
Books for You want to use search engines to Start/Programs/IBM

Printing find information. You can then print Product/Documentation
(.pdf) out selected pages, a section, or the
whole book.
Use Step-by-Step online books
(.pdf) if you want to know how to
complete a task but prefer to read
about it in a book.
The Step-by-Step online books
contain the same information as the
online help, but the method of
presentation is different.
IBM on the You want to access any of the

Web following:
• IBM - Training and Certification • http://www-01.ibm.com/

software/analytics/training-
and-certification/
• Online support • http://www-947.ibm.com/
support/entry/portal/
Overview/Software
• IBM Web site • http://www.ibm.com

Preface

Advanced monitoring
Advanced monitoring
Db2 11.1 Advanced Database Administration
© Copyright IBM Corporation 2018

Course materials may not be reproduced in whole or in part without the written permission of IBM.
Unit 1 Advanced monitoring
© Copyright IBM Corp. 1997, 2018 1-2

Unit objectives
• Describe the infrastructure used to support monitoring
• Configure a database to collect the activity, request and object metrics
returned by the Monitoring Table functions
• Investigate current application activity that might indicate performance
problems using SQL statements
• Use the Db2-provided views and functions in SQL to evaluate efficient
use of database memory for locks, sorting and database buffer pools
• Check database health indicators, like log space available and table
space utilization using CLP queries using Monitor functions and views
Advanced monitoring © Copyright IBM Corporation 2018
Unit objectives

Characteristics of in-memory metrics used to support the

monitor table functions
• Overhead with all metrics active, for OLTP, about 3%
• Collection of metrics:
 Db2 Agent collects metrics locally during processing
 Agent rolls up metrics at logical break points during processing:
− Unit of work boundary
− Approximately every 10 seconds for long running transactions
• Access to monitor metrics:
 Data is queried directly from aggregates kept at the target accumulation
point
− No need to drill down to agent or application levels for accumulation
 SQL access is through trusted table functions with direct memory access
 Input arguments and predicates allow filtering of data at source to reduce
volumes and overhead of queries
− Functions allow request for a single table, table space or database connection to
be specified
Characteristics of in-memory metrics used to support the monitor table functions

The in-memory metrics used to support the current monitor functions were designed to
reduce the system overhead associated with collecting those metrics. A test performed
using an OLTP transaction system showed that about 3 percent overhead was added if
all of the new metrics were collected.
One method used to reduce the overhead is to have each Db2 agent collect the metrics
locally as the processing is performed. The information collected by each agent is rolled
up to the higher levels, like connection, workload and service subclass at logical
breakpoints like the end of a unit of work. For long-running transactions, the metrics get
rolled up on an interval of about 10 seconds. This keeps the statistics at the higher
levels close to the actual numbers but reduces the cost of tracking work at the higher
levels.
When monitor data is requested, it is reported directly from the higher levels of
aggregation rather than drilling down to each individual agent. SQL access to the in-
memory metrics is performed using a set of trusted functions with less processing
overhead.

Many of the monitor table functions provide call parameters that limit the scope of
processing for collecting metrics to a single occurrence. For example, the table function
MON_GET_TABLE can be called for information about one table.
MON_GET_CONNECTION can be used to access the current in-memory metrics for a
database connection.

Focus areas for in-memory metrics

• System:
 Provide total perspective of application work being done by database
system
 Aggregated through the WLM infrastructure
• Data objects:
 Provide perspective of impact of application work on data objects
 Aggregated through data storage infrastructure
• Activity:
 Provide perspective of work being done by specific SQL statements
 Aggregated through the package cache infrastructure
Focus areas for in-memory metrics

The Db2 relational monitoring interfaces are based on three basics views of the
database server.
With a 'system' view, all of the work performed is collected and then aggregated based
on the workload management infrastructure. The statistics for the current units of work
and connections can be retrieved. The accumulation of work performed for each WLM
workload or service subclass can also be accessed.
The data object view provides metrics for each table, index, buffer pool, and table
space in the database. Metrics at the table space container level are also available.
These container level statistics could be used to track the disk activity by container. In
some cases a performance problem might be shown using these container-level
metrics that would not be as clear when viewed at the table space level.
The activity view is also based on the workload management concepts. The metrics for
current activities, like SQL statements or LOAD utilities are available. The package
cache statistics provide a longer term view, providing the summary statistics for multiple
executions of both static and dynamic statements.

In-memory metrics: System
Connection Service Class Service Class

∑R ∑R ∑R
Workload Workload
Occurrence (UOW) Definition
∑R ∑R
• MON_GET_UNIT_OF_WORK
Request Metrics • MON_GET_UNIT_OF_WORK_DETAILS
• MON_GET_CONNECTION
• MON_GET_CONNECTION_DETAILS
Database Db2 Agent • MON_GET_SERVICE_SUBCLASS
Request Collects Data • MON_GET_SERVICE_SUBCLASS_DETAILS
• MON_GET_WORKLOAD
• MON_GET_WORKLOAD_DETAILS
Legend • MON_GET_DATABASE
ΣR = Accumulation of request metrics collected by agent • MON_GET_DATABASE_DETAILS
In-memory metrics: System

As application requests are processed by the database manager, the various statistics
are added to each level used for reporting.
The detailed processing metrics are added to the specific unit of work that generated
the database request. Each unit of work is added to the statistics for the connection
associated with the unit of work. The statistics are also added to the workload and
service subclass that the request was processed under.
With Db2 10.5 and later, database level statistics are also available, using
MON_GET_DATABASE and MON_GET_DATABASE_DETAILS.

In-memory metrics: Data objects
Buffer pool
Metrics
Buffer pool
Container
Metrics
Temp Table space

Table space Table space Table space
Container Table space Metrics
Row Data
LOB /Data
Index
Table XML Data
Table • MON_GET_TABLE
Metrics
• MON_GET_INDEX
Database
Db2 Agent
• MON_GET_BUFFERPOOL
Request
Collects Data • MON_GET_TABLESPACE
• MON_GET_CONTAINER
In-memory metrics: Data objects

As each database request is processed, the statistics are accumulated for each related
database object including:
• Each table accessed
• Each index utilized for a request
• The table spaces that were accessed for data, index, large object or XML data.
• Some requests could generate activity for temporary table spaces that would also
need to be accumulated.
• Statistics are tracked for each container within a table space. This would show if
one or more containers might be related to an I/O performance bottleneck.
• Each buffer pool accessed will also reflect the activity for the request.

In-memory metrics: Activity perspective
Activity WLM Activity Package Cache

Metrics ∑A ∑A
Db2 Agent Activity Level

Database
Request Collects Data
• MON_GET_ACTIVITY_DETAILS
• MON_GET_PKG_CACHE_STMT
• MON_GET_PKG_CACHE_STMT_DETAILS
Legend
ΣA = Accumulation of metrics from activity execution portion of request
In-memory metrics: Activity perspective

A request comes into an agent and is processed. If the request is related to an activity,
then the agent gathers the metrics from the start of activity execution and at regular
intervals aggregates them in the activity control block. When the activity completes,
those activity execution metrics are propagated to the package cache and aggregated
under the specific cached section that was executed (static and dynamic SQL).

Controls for collecting monitor data

Monitoring Table Functions Related Related
Database Level Workload Management
Configuration Setting
MON_GET_TABLE Always collected
MON_GET_INDEX
MON_GET_BUFFERPOOL mon_obj_metrics
MON_GET_TABLESPACE
MON_GET_CONTAINER
MON_GET_ACTIVITY_DETAILS mon_act_metrics COLLECT ACTIVITY

MON_GET_PKG_CACHE_STMT METRICS clause on
MON_GET_PKG_CACHE_STMT-DETAILS workloads
MON_GET_UNIT_OF_WORK mon_req_metrics COLLECT REQUEST
MON_GET_UNIT_OF_WORK_DETAILS METRICS clause on a
MON_GET_CONNECTION
service superclass
MON_GET_CONNECTION_DETAILS
MON_GET_SERVICE_SUBCLASS
MON_GET_SERVICE_SUBCLASS_DETAILS
MON_GET_WORKLOAD
MON_GET_WORKLOAD_DETAILS
MON_GET_DATABASE
MON_GET_DATABASE_DETAILS
Controls for collecting monitor data

With the new monitor elements and infrastructure, you can use SQL statements to
efficiently collect monitor data to determine whether specific aspects of the system are
working correctly and to help you diagnose performance problems, while incurring a
reasonable performance overhead. With the new access methods, you can get all the
data you need without using the snapshot interfaces. The increased monitoring
granularity gives you more control over the data collection process; collect the data you
want from the source you want
Monitoring information is collected about the work performed by your applications and
reported through table function interfaces at the following three levels:
System level
These monitoring elements provide details about all work being performed on
the system. Monitor-element access points include service subclass, workload
definition, unit of work, and connection as well as the database level.

Activity level
These monitor elements provide details about activities being performed on the
system (a specific subset of the work being performed on the system). You can
use these elements to understand the behavior and performance of activities.
Monitor-element access points include individual activities, and entries in the
database package cache.
Data object level
These monitoring elements provide details about the work being processed by
the database system within specific database objects such as indexes, tables,
buffer pools, table spaces, and containers, thereby enabling you to quickly
identify issues with particular data objects that might be causing system
problems. Monitor-element access points include buffer pool, container, index,
table, and table space.

Monitoring system information using table functions

• The system monitoring perspective encompasses all the work and
effort expended by the data server to process application requests.
• You can determine what the data server is doing as a whole or for
particular subsets of application requests.
• Table functions are provided in pairs:
 One for relational access, each monitor element is one column of data
 One (DETAILS) for XML access to monitor elements
• Use the following table functions for accessing current system
monitoring information:
 MON_GET_SERVICE_SUBCLASS and MON_GET_SERVICE_SUBCLASS_DETAILS
 MON_GET_WORKLOAD and MON_GET_WORKLOAD_DETAILS
 MON_GET_CONNECTION and MON_GET_CONNECTION_DETAILS
 MON_GET_UNIT_OF_WORK and MON_GET_UNIT_OF_WORK_DETAILS
 MON_GET_DATABASE and MON_GET_DATABASE_DETAILS
 MON_GET_ACTIVITY and MON_GET_ACTIVITY_DETAILS
Monitoring system information using table functions

The system monitoring perspective encompasses the complete volume of work and
effort expended by the data server to process application requests. From this
perspective, you can determine what the data server is doing as a whole as well as for
particular subsets of application requests.
Monitor elements for this perspective, referred to as request monitor elements, cover
the entire range of data server operations associated with processing requests.
Request monitor elements are continually accumulated and aggregated in memory so
they are immediately available for querying. Request monitor elements are aggregated
across requests at various levels of the workload management (WLM) object hierarchy:
by unit of work, by workload, by service class. They are also aggregated by connection.
Use the following table functions for accessing current system monitoring information:
• MON_GET_SERVICE_SUBCLASS and
MON_GET_SERVICE_SUBCLASS_DETAILS
• MON_GET_WORKLOAD and MON_GET_WORKLOAD_DETAILS
• MON_GET_CONNECTION and MON_GET_CONNECTION_DETAILS
• MON_GET_UNIT_OF_WORK and MON_GET_UNIT_OF_WORK_DETAILS
• MON_GET_DATABASE and MON_GET_DATABASE_DETAILS
• MON_GET_ACTIVITY and MON_GET_ACTIVITY_DETAILS

This set of table functions enables you to drill down or focus on request monitor
elements at a particular level of aggregation. Table functions are provided in pairs: one
for relational access to monitor data and the other for XML access to the monitor
elements.

Monitoring time spent waiting for resources

• Standard Wait time statistics:
 total_wait_time - Total wait time
 agent_wait_time - Agent wait time
 pool_read_time - Total buffer pool physical read time
 pool_write_time - Total buffer pool physical write time
 client_idle_wait_time - Client idle wait time
 direct_read_time - Direct Read Time
 direct_write_time - Direct write time
 fcm_recv_wait_time - FCM receive wait time
 fcm_send_wait_time - FCM send wait time
 ipc_recv_wait_time - Interprocess communication received wait time
 ipc_send_wait_time - Interprocess communication send wait time
 tcpip_recv_wait_time - TCP/IP receive wait time
 tcpip_send_wait_time - TCP/IP send wait time
 lock_wait_time - Time waited on locks
 log_disk_wait_time - Log disk wait time
 log_buffer_wait_time - Log buffer wait time
• Detailed Wait time statistics:
 audit_subsystem_wait_time - Audit subsystem wait time
 audit_file_write_wait_time - Audit file write wait time
 diaglog_write_wait_time - Diag log write time
 fcm_message_recv_wait_time - FCM message receive wait time
 fcm_message_send_wait_time - FCM message send wait time
 fcm_tq_recv_wait_time - FCM tablequeue receive wait time
 fcm_tq_send_wait_time - FCM tablequeue send wait time
Monitoring time spent waiting for resources

The visual lists the monitor elements that show how much time was spent waiting for
different reasons. These can be used to determine if a system might have a
performance bottleneck related to logging, disk I/Os, locking or network performance
problems.
The list of detailed wait times includes any wait times associated with writing diagnostic
messages or recording database audit records.
For Db2 partitioned databases, there are a series of statistics that show how much time
was spent waiting for data to be sent or received within the FCM component.

Additional time-related metrics

• Time metrics reported for:
 Connections
 Units of work
 Each Statement in the package cache
 WLM Workload
 WLM Service subclass
 WLM Activity
• For Sort Processing:
 total_section_sort_time - Total amount of time spent performing sorts
 total_section_sort_proc_time - Total amount of
processing (non-wait) time spent performing sorts while executing a section
• total_rqst_time - The total amount of time spent working on requests
• total_cpu_time - The total amount of CPU time used while within Db2.
Represents total of both user and system CPU time.
• total_act_time - The total amount of time spent executing activities.
• total_act_wait_time - Total time spent waiting within the Db2 database server,
while processing an activity
Additional time-related metrics

The time-related monitor statistics are accumulated for each unit of work, connection as
well as being added to the related workload, management workload, service class and
activity data. The statistics will also be added into the information associated with each
SQL statement stored in the database package cache.
To better understand the time spent performing sort operations there are two elements:
• total_section_sort_time indicates the total amount of time spent performing
sorts.
• total_section_sort_proc_time show the total amount of processing (non-wait)
time spent performing sorts while executing a section.
There are statistics that show the total amount of time working on requests
(total_rqst_time) and the total amount of CPU time consumed (total_cpu_time).
The MON_GET_ACTIVITY_DETAILS table function and
MON_GET_PKG_CACHE_STMT table function include the total amount of time spent
executing activities and the total time spent waiting during processing an activity.

Additional wait times reported

PREFETCH_WAIT_TIME The time an application spent waiting for an I/O server
(prefetcher) to finish loading pages into the buffer pool
PREFETCH_WAITS The number of times waited for an I/O server

(prefetcher) to finish loading pages into the buffer pool
TOTAL_EXTENDED_LATCH_WAIT_TIME The amount of time, in milliseconds, spent in

extended latch waits
TOTAL_EXTENDED_LATCH_WAITS The number of extended latch waits.
COMM_EXIT_WAIT_TIME Time spent waiting for the return from a communication

buffer exit library API function. The value is given in
milliseconds
COMM_EXIT_WAITS The number of times a communication buffer exit library

API function is called.
EVMON_WAIT_TIME The amount of time that an agent waited for an event

monitor record to become available.
EVMON_WAITS_TOTAL The number of times that an agent waited for an event

monitor record to become available.
Additional wait times reported

Db2 Version 10 and later provide these additional wait time related monitor elements.
The slide shows some new monitor elements that can be used to understand
application wait times, including prefetching data, waiting for Db2 latches and waits
associated with event monitoring.
For example, the monitor element comm_exit_wait_time shows the time spent waiting
for the return from a communication buffer exit library API function. The value is given in
milliseconds.

Example of query using the XML document returned by

• Display connections returning the highest volume of data to clients, ordered by rows
returned.
SELECT detmetrics.application_handle,
detmetrics.rows_returned,
detmetrics.tcpip_send_volume
FROM TABLE(MON_GET_CONNECTION_DETAILS(CAST(NULL as bigint), -2))

AS CONNMETRICS,
XMLTABLE (XMLNAMESPACES( DEFAULT 'http://www.ibm.com/xmlns/prod/db2/mon'),

'$detmetric/db2_connection' PASSING XMLPARSE(DOCUMENT CONNMETRICS.DETAILS)
as "detmetric“
COLUMNS "APPLICATION_HANDLE" INTEGER PATH 'application_handle',

"ROWS_RETURNED" BIGINT PATH 'system_metrics/rows_returned',
"TCPIP_SEND_VOLUME" BIGINT PATH 'system_metrics/tcpip_send_volume'
) AS DETMETRICS
ORDER BY rows_returned DESC
The following is an example of output from this query.
APPLICATION_HANDLE ROWS_RETURNED TCPIP_SEND_VOLUME

------------------ -------------------- --------------------
21 4 0
Example of query using the XML document returned by

Using XML to report monitor information provides improved extensibility and flexibility.
New monitor elements can be added to the product without having to add new columns
to an output table. Also, XML documents can be processed in a number of ways,
depending on your needs. For example:
• You can use XQuery to run queries against the XML document.
• You can use the XSLTRANSFORM scalar function to transform the document
into other formats.
• You can view their contents as formatted text using built-in
MON_FORMAT_XML_* formatting functions, or the XMLTABLE table function.

The Monitor table functions with names that end with _DETAILS produce XML
documents containing monitor elements. Examples of these table functions include:
• MON_GET_PKG_CACHE_STMT_DETAILS
• MON_GET_WORKLOAD_DETAILS
• MON_GET_CONNECTION_DETAILS
• MON_GET_SERVICE_SUBCLASS_DETAILS
• MON_GET_ACTIVITY_DETAILS
• MON_GET_UNIT_OF_WORK_DETAILS
• MON_GET_DATABASE_DETAILS
The slide shows an example of a query using the
MON_GET_CONNECTION_DETAILS monitor table function. The XMLTABLE function
is used to selectively present a set of monitor elements from the XML document in the
column named DETAILS in the form of a standard tabular result.

Monitoring administrative views simplify access to

important metrics
MON_BP_UTILIZATION Includes hit ratios and average read and write times for all
buffer pools.
MON_TBSP_UTILIZATION Includes hit ratios and utilization percentage for all table
spaces.
MON_LOCKWAITS Information about agents that are waiting to obtain locks in
the currently connected database.
MON_PKG_CACHE_SUMMARY Metrics returned are aggregated over all executions of the
statement.
MON_CURRENT_SQL Metrics for all activities that were submitted and have not
yet been completed.
MON_CURRENT_UOW Identifies long running units of work.
MON_SERVICE_SUBCLASS_SUMMARY Key metrics for all service subclasses.
MON_WORKLOAD_SUMMARY Key metrics for all workloads.

MON_CONNECTION_SUMMARY Key metrics for all connections.
MON_DB_SUMMARY Key metrics aggregated over all service classes.
Monitoring administrative views simplify access to important metrics

A set of administrative views that encapsulate key queries using the monitoring table
functions. The schema for these views is SYSIBMADM.
These provide many detailed metrics describing the database objects and environment.
To see the most important metrics in an easily readable format, you can use the new
monitoring administrative views. You can simply issue a SELECT * command to see
the main metrics from each table function, as well as some common calculated values,
like buffer pool hit ratios.
The following administrative views are available:
• MON_BP_UTILIZATION
• MON_TBSP_UTILIZATION
• MON_LOCKWAITS
• MON_PKG_CACHE_SUMMARY
• MON_CURRENT_SQL
• MON_CURRENT_UOW
• MON_SERVICE_SUBCLASS_SUMMARY

• MON_WORKLOAD_SUMMARY
• MON_CONNECTION_SUMMARY
• MON_DB_SUMMARY
For example, the MON_DB_SUMMARY administrative view returns key metrics
aggregated over all service classes in the currently connected database. It is designed
to help monitor the system in a high-level manner by providing a concise summary of
the database. The view includes information like IO_WAIT_TIME_PERCENT, which
shows the percentage of the time spent waiting within the Db2 database server that
was due to I/O operations. This includes time spent performing direct reads or direct
writes, and time spent reading data and index pages from the table space to the
bufferpool or writing them back to disk.

Monitoring performance with SQL: Buffer pools

SELECT substr(bp_name,1,30) as bp_name ,
pool_data_l_reads, pool_data_p_reads,
(100 * (pool_data_l_reads - pool_data_p_reads )) /( pool_data_l_reads )
as data_hit_pct,
pool_index_l_reads, pool_index_p_reads ,
(100 * (pool_index_l_reads - pool_index_p_reads )) /( pool_index_l_reads )
as index_hit_pct
FROM TABLE (MON_GET_BUFFERPOOL(NULL,-2) ) as tbuff Exclude the System
'Hidden'
where bp_name not like 'IBMSYSTEM%';
Buffer pools
BP_NAME POOL_DATA_L_READS POOL_DATA_P_READS DATA_HIT_PCT
------------------ -------------------- -------------------- -------------
IBMDEFAULTBP 813 229 71
CLPBUFFL 35172 2760 92
CLPBUFFS 41361 34649 16
POOL_INDEX_L_READS POOL_INDEX_P_READS INDEX_HIT_PCT

-------------------- ------------------- --------------
1116 408 63
64 21 67
103 76 26
Monitoring performance with SQL: Buffer pools

The example query uses the function MON_GET_BUFFERPOOL to return logical and
physical data and index page read counts and calculates hit ratios for each page type.
The system hidden buffer pools are excluded from the results.

Monitoring performance with SQL: Sorts

with dbcfg1 as (
Get the shared sort heap
select int(value) as sheapthres_shr threshold from the
from sysibmadm.dbcfg where name = 'sheapthres_shr' ) database config
select sheapthres_shr as "Shared_sort_heap" ,

sort_shrheap_allocated as "Shared_sort_allocated" ,
dec((100 * sort_shrheap_allocated)/sheapthres_shr,5,2)
as " % Sheap_alloc" ,
dec((100* sort_shrheap_top)/sheapthres_shr,5,2)
as " % Max Sheap_alloc" ,
sort_overflows as "Sort_Overflows",
total_sorts as "Total_Sorts"
from dbcfg1, table (MON_GET_DATABASE(-1)) AS MONDB
Shared_sort_heap Shared_sort_allocated % Sheap_alloc % Max Sheap_alloc

---------------- --------------------- -------------- ------------------
5024 4 0.00 40.00
Sort_Overflows Total_Sorts
-------------------- --------------------
14 49
Monitoring performance with SQL: Sorts

The common table expression accesses a view, SYSIBMADM.DBCFG, that lists all the
database configuration parameters. Each configuration parameter appears as one row
in the table, so the predicate, name = 'sheapthres_shr', is used to request the defined
size of the database shared sort heap.
The SELECT joins the value from the Database configuration to the statistics from the
table function MON_GET_DATABASE that relates to sort performance. Prior to Db2
10.5 the view SYSIBMADM.SNAPDB could be used for database sort statistics.
These statistics show the statistics for sorts using database shared memory. If the
Database Manager Configuration option SHEAPTHRES is not set to 0, then many sort
operations will be performed using private memory. The query shows the current and
maximum usage of the database shared memory heap for sorts. This area is also used
for hash joins and dynamic index anding operations.
The number of sort overflows can be compared to the total number of sorts to see if the
database configuration option sortheap may need to be increased.

Monitoring performance with SQL:

Top dynamic SQL statements
select num_executions as "Num Execs",
total_act_time as total_time,
(total_act_time / num_executions ) as "Avg Time (msec)",
Get the Dynamic SQL Stats
total_sorts as "Num Sorts",
from Package Cache
(total_sorts / num_executions ) as "Sorts Per Stmt",
total_section_sort_time,
substr(stmt_text,1,35) as "SQL Stmt" from
table ( MON_GET_PKG_CACHE_STMT('d',NULL,NULL,-1)) as dyn_cache where
num_executions > 0 and total_routine_time = 0
order by 2 desc fetch first 5 rows only
Num Execs TOTAL_TIME Avg Time (msec) Num Sorts Per Stmt
---------- -------------------- -------------------- ------------- --------------
5 3124 624 5 1
5 2070 414 5 1
5 2018 403 5 1
5 1240 248 5 1
5 281 56 5 1
TOTAL_SECTION_SORT_TIME SQL Stmt
----------------------- --------------------------------------------------
6 SELECT * from clpm.hist2 where acct_id between 10
600 SELECT * from clpm.hist2 order by balance desc
154 SELECT hist2.ACCT_ID, hist2.TELLER_ID, hist2.BRANC
546 SELECT * from clpm.hist1 order by balance desc
108 SELECT hist1.ACCT_ID, hist1.TELLER_ID, hist1.BRANC
Monitoring performance with SQL: Top dynamic SQL statements

This SQL query example shows how the WHERE clause and ORDER BY clause on a
SELECT statement can be effectively used to find the dynamic SQL statement statistics
that will be of the highest interest for performance reviews.
The monitor table function MON_GET_PKG_CACHE_STMT is used to retrieve the
statistics from SQL statements in the database package cache. The function can be
used to monitor the static and dynamic SQL statements stored in the package cache.
The example SQL includes the ‘d’ function call parameter to limit result to the dynamic
SQL statements.
The example query shows the top dynamic SQL statements based on highest total
activity time. These are the queries that should get focus to ensure they are well tuned.
The example query includes the number of sorts in the result, so that you can see if a
query is executed frequently and performs a lot of sorts, as these might be a good
candidate for adding a new index.
You might decide to use the Db2 design advisor to gather suggestions for reducing
processing costs for these SQL statements.

Monitoring performance with SQL: Long-running SQL

select varchar(application_name,15) as Appl_name ,
elapsed_time_sec as "Elapsed Seconds" ,
varchar(activity_state,20) as "Status ",
varchar(session_auth_id,10) as auth_id ,
total_cpu_time, rows_returned,
substr(stmt_text,1,30) as "SQL Statement"
from SYSIBMADM.MON_CURRENT_SQL
order by 2 desc
APPL_NAME Elapsed Seconds Status AUTH_ID TOTAL_CPU_TIME

--------------- --------------- -------------------- ---------- --------------------
db2bp 764 EXECUTING INST461 8000
db2bp 73 IDLE INST461 28000
db2bp 0 EXECUTING INST461 0
ROWS_RETURNED SQL Statement

-------------------- ------------------------------
0 update clpm.hist1 set balance=
777 select * from clpm.hist2 where
0 select varchar(application_nam
Monitoring performance with SQL: Long-running SQL

This query uses the administrative view, SYSIBMADM.MON_CURRENT_SQL, which
returns key metrics for all activities that were submitted on all members of the database
and have not yet been completed, including a point-in-time view of currently executing
SQL statements (both static and dynamic) in the currently connected database.
This can be used to find information about the current active SQL statements including
the time elapsed since this activity began, in seconds. You can also see the status of
the activity.
The activity_state can be used to understand what the activity is currently doing (for
example, is the activity stuck in a queue or waiting for input from the client).

Possible values include:

• CANCEL_PENDING
• EXECUTING
• IDLE
• INITIALIZING
• QP_CANCEL_PENDING
• QP_QUEUED
• QUEUED
• TERMINATING
• UNKNOWN
The query shows the count of rows returned and total_cpu_time which are good
indicators for SQL statements that are using large amounts of system resources.
In order to use this view, one of the following authorizations is required:
• SELECT privilege on the MON_CURRENT_SQL administrative view
• CONTROL privilege on the MON_CURRENT_SQL administrative view
• DATAACCESS authority

Monitoring performance with SQL application wait times

select application_handle as appl_id ,
total_wait_time , Check for total wait time
pool_read_time, pool_write_time, And most common
log_disk_wait_time, reasons for delays
lock_wait_time
from table(mon_get_connection(NULL,-1) )
order by total_wait_time
APPL_ID TOTAL_WAIT_TIME POOL_READ_TIME POOL_WRITE_TIME

-------------------- -------------------- -------------------- --------------------
247 486 292 1
248 166662 82517 5205
250 166702 83088 4695
249 166897 81330 5341
251 166953 82397 4840
LOG_DISK_WAIT_TIME LOCK_WAIT_TIME
-------------------- --------------------
0 0
73175 897
72975 718
74581 1059
74166 1158
Monitoring performance with SQL application wait times

The example query uses the MON_GET_CONNECTION table function to look at some
of the most common reasons for delays by the current application connections. This
could be used to see how much time the current application connections have spent
waiting for buffer pool read and write operations, log disk writes and also shows time
spent waiting for locks.
The sample report shows that most of the application wait time has been for either
reading pages into the buffer pool or writing log records to the Db2 system logs.
Even though the time spent waiting on buffer pool writes is not high, it still might be an
indication that the system could be running more efficiently, since this indicates that
page writes are being performed synchronously rather than asynchronously.

Monitoring performance with SQL: Lock chains

select substr(lw.hld_application_name,1,10) as "Hold App",
substr(lw.hld_userid,1,10) as "Holder", Who is holding the lock?
substr(lw.req_application_name,1,10) as "Wait App",
substr(lw.req_userid,1,10) as "Waiter",
lw.lock_mode , Who is waiting on the lock?
lw.lock_object_type ,
substr(lw.tabname,1,10) as "TabName",
substr(lw.tabschema,1,10) as "Schema",
How long is the wait?
lw.lock_wait_elapsed_time
as "waiting (s)"
FROM
SYSIBMADM.MON_LOCKWAITS lw ;
Hold App Holder Wait App Waiter LOCK_MODE LOCK_OBJECT_TYPE TabName Schema waiting (s)
---------- ---------- ---------- ---------- --------- ------------------ -------- ------- -----------
db2bp INST461 db2bp INST461 X TABLE HIST1 CLPM 61
Monitoring performance with SQL: Lock chains

This query shows any lock chains that currently exist. It shows the lock holder, the
application/user waiting on the lock, as well as the object locked and the length of time
the waiter has been waiting. It is not abnormal to see lock wait chains. What is
abnormal is to see lengthy waiting times. If you see long waits, you should look at what
the holding application is doing (what SQL statement and what the application status is)
to determine if the application is well tuned.
The MON_LOCKWAITS administrative view returns information about agents working
on behalf of applications that are waiting to obtain locks in the currently connected
database. It is a useful query for identifying locking problems. This administrative view
replaces the SNAPLOCKWAIT administrative view which is deprecated and might be
discontinued in a future release.
One of the following authorizations is required:
• SELECT privilege on the MON_LOCKWAITS administrative view
• CONTROL privilege on the MON_LOCKWAITS administrative view

Monitoring performance with SQL: Lock memory usage

WITH
dbcfg1 as ( select float(int(value) * 4096) as locklist
from sysibmadm.dbcfg where name = 'locklist' ) ,  Locklist is configured in
dbcfg2 as ( select float(int(value)) as maxlocks number of 4k pages.
from sysibmadm.dbcfg where name = 'maxlocks' )  Locklistinuse is
displayed in bytes.
select
dec((MDB.lock_list_in_use/locklist)*100,4,1) as "% Lock List",
dec((MDB.lock_list_in_use/(locklist*(maxlocks/100))*100),4,1)
as "% to Maxlock",
MDB.appls_cur_cons as "Number of Cons",
MDB.lock_list_in_use/MDB.appls_cur_cons
as "Avg Lock Mem Per Con (bytes)"
FROM DBCFG1, DBCFG2 , TABLE (MON_GET_DATABASE(-1)) AS MDB
% Lock List % to Maxlock Number of Cons Avg Lock Mem Per Con (bytes)
----------- ------------ -------------------- ----------------------------
29.9 59.9 3 819072
1 record(s) selected.
Monitoring performance with SQL: Lock memory usage

In the example, the administrative view, SYSIBMADM.DBCFG, is accessed twice, once
to get the size of the locklist database shared memory heap, and once to get the
configuration parameter, maxlocks.
Now the query can compare current lock memory usage, using the table function
MON_GET_DATABASE to the size of the locklist as configured in the db config
parameters. Prior to Db2 10.5 the view SYSIBMADM.SNAPDB could be used to
retrieve lock memory usage.
Maxlocks represents the percentage of the locklist that any one application can use
before a lock escalation from row to table locking would occur. If the amount of lock list
in use is below the maxlocks percentage of the total lock list, then no one application
can be causing an escalation. If the lock list in use is greater than the maxlocks percent
of the total locklist, then it is possible for one or more applications to be approaching a
lock escalation. By looking at the average lock memory per connection, you can get an
idea of approximately how much memory each application is using (but that assumes
each application is using the locklist uniformly which might not be true).

Monitoring performance with SQL:

Lock escalations, deadlocks and timeouts
Select substr(conn.application_name,1,10) as Application,
substr(conn.system_auth_id,1,10) as AuthID,
conn.num_locks_held as "# Locks",
conn.lock_escals as "Escalations",
conn.lock_timeouts as "Lock Timeouts",
conn.deadlocks as "Deadlocks",
(conn.lock_wait_time / 1000) as "Lock Wait Time"
from table(MON_GET_CONNECTION(NULL,-1)) as conn ;
APPLICATION AUTHID # Locks Escalations Lock Timeouts

----------- ---------- -------------------- -------------------- ------------------
db2bp INST461 2 0 0
db2bp INST461 2 1 0
db2bp INST461 3 0 0
Deadlocks Lock Wait Time

-------------------- -------------------- Note escalations for one
0 0 connection and extended
0 0 wait time for another
0 209 connection
Monitoring performance with SQL: Lock escalations, deadlocks and timeouts

In general, deadlocks, lock timeouts and lock escalations may cause application
problems and your application should be designed to avoid them. You should also have
sufficient lock memory to ensure escalations do not occur. You can use this query to
see if any of the current application connections have been involved in any of these lock
issues.
The SQL query uses the MON_GET_CONNECTION table function, which can be used
to look at the statistics for each connection including the current application and the
userid who is running the application.
The sample query result shows that one of the connections encountered a lock
escalation and another application connection has a significant amount of lock wait
time.

Monitoring performance with SQL queries that have a high

prep time
select num_executions, stmt_exec_time as total_exec_time,
(stmt_exec_time / num_executions ) as Avg_exec_time, prep_time ,
(( 100 * prep_time ) /(stmt_exec_time /num_executions)) as pct_prep,
substr(stmt_text,1,40) as "SQL_Text"
from TABLE (MON_GET_PKG_CACHE_STMT('d',NULL,NULL,-1)) as dyn_cache
where stmt_exec_time > 1000
order by prep_time desc
NUM_EXECUTIONS TOTAL_EXEC_TIME AVG_EXEC_TIME PREP_TIME
-------------------- -------------------- -------------------- --------------------
5 10888 2177 77
15 35577 2371 47
15 10601 706 1
15 7980 532 1
PCT_PREP SQL_Text
-------------------- ----------------------------------------
3 SELECT * from clpm.hist1 order by balanc
1 SELECT * from clpm.hist2 order by balanc
0 SELECT hist2.ACCT_ID, hist2.TELLER_ID, h
0 SELECT * from clpm.hist2 where acct_id
Monitoring performance with SQL queries that have a high prep time
You can examine the package cache to see how frequently a query is run as well as
the average execution time for each of these queries.
The MON_GET_PKG_CACHE_STMT table function returns a point-in-time view of
both static and dynamic SQL statements in the database package cache. In the
example, the ‘d’ call parameter limits the results to dynamic statements.
The query sorts the results based on the time required to prepare the statement. It
compares the statement compilation time, prep_time, to a calculated average execution
time.
If the time it takes to compile and optimize a query is almost as long as it takes for the
query to execute, you might want to look at the optimization class that you are using.
Lowering the optimization class might make the query complete optimization more
rapidly and, therefore, return a result sooner.
In some cases, a query might take a significant amount of time to prepare, but it is
executed thousands of times, without being prepared again. For these statements, the
optimization class might not be an issue.

Monitoring performance with SQL: Costly table scans

• High ratio of rows read to rows returned can indicate table scans
select varchar(session_auth_id,10) as Auth_id,

varchar(application_name,20) as Appl_name,
io_wait_time_percent as Percent_IO_Wait,
rows_read_per_rows_returned as Rows_read_vs_Returned
from SYSIBMADM.MON_CONNECTION_SUMMARY
AUTH_ID APPL_NAME PERCENT_IO_WAIT ROWS_READ_VS_RETURNED

---------- -------------------- --------------- ---------------------
INST461 db2bp 10.00 17202
INST461 db2batch 15.22 2
Monitoring performance with SQL: Costly table scans

The MON_CONNECTION_SUMMARY administrative view returns key metrics for all
connections in the currently connected database. It is designed to help monitor the
system in a high-level manner, showing incoming work per connection.
The metrics returned represent the accumulation of all metrics for requests that were
submitted by the identified connection across all members of the database.
The schema is SYSIBMADM.
One of the following authorizations is required:
• SELECT privilege on the MON_CONNECTION_SUMMARY administrative view
• CONTROL privilege on the MON_CONNECTION_SUMMARY administrative
view

This query returns information that may indicate that applications are performing large
table scans. The column ROWS_READ_PER_ ROWS_RETURNED shows the
average number of rows read from the table per rows returned to the application. If the
selectivity is low, then the application might be performing a table scan (perhaps
unnecessarily, if an index were available).
The result also shows the percentage of the time spent waiting within the Db2 database
server that was due to I/O operations. This includes time spent performing direct reads
or direct writes, and time spent reading data and index pages from the table space to
the bufferpool or writing them back to disk.

Monitoring prefetch efficiency of applications
SELECT pool_queued_async_data_reqs as Prefetch_Reqs,

pool_queued_async_data_pages as Prefetch_pages ,
( pool_queued_async_data_pages / pool_queued_async_data_reqs )
as Pages_per_prefetch
pool_failed_async_data_reqs as Failed_prefetch,
prefetch_wait_time , prefetch_waits
FROM TABLE(MON_GET_CONNECTION(NULL,-1)) AS c1
where application_name = 'db2bp‘ ;
PREFETCH_REQS PREFETCH_PAGES PAGES_PER_PREFETCH

-------------------- -------------------- --------------------
3573 28587 8
FAILED_PREFETCH PREFETCH_WAIT_TIME PREFETCH_WAITS

-------------------- -------------------- --------------------
0 711 143
Monitoring prefetch efficiency of applications

The example query uses the table function MON_GET_CONNECTION to retrieve
some monitor elements for database connections running a particular application.
The query returns the number of prefetch requests and calculates the average number
of pages read per prefetch. It also returns the number and total duration of waits for
prefetch operations.
The element pool_failed_async_data_reqs shows the number of times an attempt to
queue a data prefetch request was made but failed. One possible reason is the prefetch
queue is full.

Monitoring performance: Database memory usage

SELECT VARCHAR(MEMORY_POOL_TYPE,20) AS POOL_TYPE,
MEMORY_POOL_USED, MEMORY_POOL_USED_HWM
FROM TABLE (MON_GET_MEMORY_POOL ('DATABASE',NULL,NULL) ) AS TMEM
POOL_TYPE MEMORY_POOL_USED MEMORY_POOL_USED_HWM

-------------------- -------------------- --------------------
UTILITY 65536 65536
PACKAGE_CACHE 524288 917504
XMLCACHE 131072 131072
CAT_CACHE 393216 393216
BP 16908288 16908288
BP 52166656 52166656
BP 851968 851968
BP 589824 589824
BP 458752 458752
BP 393216 393216
SHARED_SORT 196608 262144
LOCK_MGR 2228224 2228224
DATABASE 60489728 60489728
Monitoring performance: Database memory usage

The MON_GET_MEMORY_POOL table function retrieves metrics from the memory
pools contained within a memory set.
The slide shows a sample report generated using MON_GET_MEMORY_POOL. The
function can be used to check current memory allocations and also to see the peak
usage of memory for each pool while the database was active.
This information can be helpful if the self-tuning memory management option has been
configured for a database.

Using MONITOR functions with database partitioning

• Using the MONITOR table functions in a partitioned database
environment, you can:
 Receive data for a single partition or for all partitions.
 If you choose to receive data for all partitions, the table functions return one
row for each partition.
− You can add the values across partitions to obtain the value of a monitor element
across partitions.
To list the activity on all tables accessed since the database was activated,
aggregated across all database members, ordered by highest number of reads.
SELECT varchar(tabschema,20) as tabschema, varchar(tabname,20) as tabname,

sum(rows_read) as total_rows_read,
sum(rows_inserted) as total_rows_inserted, sum(rows_updated) as
total_rows_updated,
sum(rows_deleted) as total_rows_deleted
FROM TABLE(MON_GET_TABLE('','',-2)) AS t Using -2 for member
GROUP BY tabschema, tabname
retrieves stats for
ORDER BY total_rows_read DESC
All Database partitions
Using MONITOR functions with database partitioning

Monitor table functions and views are routines with names that begin with "MON", such
as MON_GET_SERVICE_SUBCLASS or MON_GET_TABLE. When using the table
functions in a partitioned database environment, you can choose to receive data for a
single partition or for all partitions. If you choose to receive data for all partitions, the
table functions return one row for each partition. You can add the values across
partitions to obtain the value of a monitor element across partitions.
The example query listed would return cumulative statistics for Db2 table activity from
all database partitions. The ‘-2’ option for the member function call parameter would
include stats for all partitions but the GROUP BY clause would combine these statistics
into a single result row for each table.

Monitor performance with SQL:

Index usage with multiple database partitions
select varchar(mon.tabname,12) as table, Using -2 for member
member, retrieves stats for
varchar(cat.indname,14) as IX_Name, All Database partitions
mon.IID as Index_id,
mon.index_scans, mon.index_only_scans
from table(MON_GET_INDEX(NULL,NULL,-2)) as mon ,
SYSCAT.INDEXES as cat
where mon.tabname = cat.tabname
and mon.tabschema = cat.tabschema
and mon.iid = cat.iid
and mon.tabname in ('ACCT','HISTORY','BRANCH','TELLER')
order by mon.tabname
TABLE MEMBER IX_NAME INDEX_ID INDEX_SCANS INDEX_ONLY_SCANS
------------ ------ -------------- -------- -------------------- --------------
ACCT 1 ACCTINDX 1 1 1
HISTORY 1 HISTIX3 3 1 0
TELLER 0 TELLINDX 1 1 1
Monitor performance with SQL: Index usage with multiple database partitions
The example SQL query uses the MON_GET_INDEX Monitor table function to list the
cumulative statistics for all indexes defined on a specific set of application tables.
Using a ‘-2’ for the third function call parameter causes the table function to include all
database partitions.
The sample result shows that two of the tables have been accessed on database
partition 1, while the TELLER table has been accessed on database partition 0. The
indexes on these tables that exist but have not been utilized yet show an index scan
count of zero.

Monitor log space usage with the table function

MON_GET_TRANSACTION_LOG
select Amount of log used

int(total_log_used/1024/1024) as "Log Used (Meg)",
and free space
int(total_log_available/1024/1024) currently
as "Log Space Free (Meg)",
int((float(total_log_used) /
float(total_log_used+total_log_available))*100)
as "Pct Used",
int(tot_log_used_top/1024/1024) as "Max Log Used (Meg)",
Total and
int(sec_log_used_top/1024/1024) as "Max Sec. Used (Meg)",
int(sec_logs_allocated) as "Secondaries" secondary logs
from table (MON_GET_TRANSACTION_LOG(-2)) as tlogs ; high water marks
Log Used (Meg) Log Space Free (Meg) Pct Used Max Log Used (Meg) Max Sec. Used (Meg) Secondaries
-------------- -------------------- -------- ------------------ ------------------- -----------
12 3 76 12 10 14
Monitor log space usage with the table function MON_GET_TRANSACTION_LOG

A database log full condition effects all of the update transactions using the database.
This query checks the vital statistics for database log space, including how much is
currently being used and how much is still available. The High Water Mark for log space
usage is shown, so that you can properly set your log space parameters, logprimary,
logsecond and logfilsiz.
The MON_GET_TRANSACTION_LOG table function returns information about the
transaction logging subsystem for the currently connected database.
The query returns the current log space usage as well as a high water mark of
database log space usage.

Monitor health: Oldest transaction holding log space

select substr(uow.workload_occurrence_state,1,20) as "Status",
substr(uow.session_auth_id,1,10) as "Authid",
uow.application_handle as "Appl Handle",
int(uow.UOW_LOG_SPACE_USED/1024/1024) as "Log Used (M)",
uow.total_act_time as "Total Activity time(msec)", What is the application
holding the oldest
uow.total_act_wait_time as "Total Activity Wait time", active log record
uow.uow_start_time as "UOW Start Time" doing?
from table (MON_GET_TRANSACTION_LOG(-1)) as db,
table (MON_GET_UNIT_OF_WORK(NULL,-1)) as uow
where uow.application_handle = db.APPLID_HOLDING_OLDEST_XACT
Status Authid Appl Handle Log Used (M)

-------------------- ---------- -------------------- ------------
UOWWAIT INST461 66 10
Total Activity time(msec) Total Activity Wait time UOW Start Time
------------------------- ------------------------ --------------------------
770 66 2013-09-17-11.47.32.768302
Monitor health: Oldest transaction holding log space

If database monitoring indicates that a large amount of active database log space is
allocated, this example SQL query can be used to check which application has the
oldest transaction holding log space. That is, if this application were to commit, there
would be some log space freed up for other transactions to use. If this transaction has
been idle for some time, then perhaps the person running the application has updated
some rows, but has stepped out for a coffee without committing their transaction. It
might be necessary to force this application's transaction to rollback in order to avoid a
database log full condition.
The application id of the active transaction holding the oldest log record is retrieved
using the function MON_GET_TRANSACTION_LOG.
The application name and status come from the MON_GET_UNIT_OF_WORK table
function which includes the amount of log space used for the current unit of work.

Monitor health: Table space size

select substr(tbsp_name,1,30) as "Tablespace Name",
tbsp_type as "Type", substr(tbsp_state,1,20) as "Status",
Shows you how much
(tbsp_total_size_kb / 1024 ) as "Size (Meg)", free space and
( 100 - tbsp_utilization_percent ) as "% Free Space", percentage free
((( 100 - tbsp_utilization_percent ) * tbsp_usable_size_kb)
/ 100000 ) as "Meg Free Space"
FROM SYSIBMADM.MON_TBSP_UTILIZATION
Tablespace Name Type Status Size (Meg) % Free Space Meg Free Space
----------------- ---------- -------- ----------- ------------- ---------------
SYSCATSPACE DMS NORMAL 96 23.80 23.39
TEMPSPACE1 SMS NORMAL 0 0.00 0.00
USERSPACE1 DMS NORMAL 32 98.83 32.25
TSP01 DMS NORMAL 0 80.00 0.32
TSP07 SMS NORMAL 0 0.00 0.00
SYSTOOLSPACE DMS NORMAL 32 92.13 29.95
USERTEMP SMS NORMAL 0 0.00 0.00
CLPMTSP1 DMS NORMAL 62 78.18 49.98
CLPMTSP2 DMS NORMAL 62 77.88 49.79
Monitor health: Table space size

This query can be used to check the space utilization for each table space, including
the current size, percentage free space, and size of free space.
The MON_TBSP_UTILIZATION administrative view returns key monitoring metrics,
including hit ratios and utilization percentage, for all table spaces and all database
partitions in the currently connected database. It provides critical information for
monitoring performance as well as space utilization. This administrative view is a
replacement for the TBSP_UTILIZATION administrative view.

Database recovery: Split mirror copy planning

select substr(type,1,20) as type ,
substr(path,1,50) as path
FROM SYSIBMADM.DBPATHS
order by type
TYPE PATH
-------------------- --------------------------------------------------
DBPATH /database/inst461/NODE0000/SQL00001/
DBPATH /database/inst461/NODE0000/SQL00001/MEMBER0000/
DB_STORAGE_PATH /dbauto/path2/
DB_STORAGE_PATH /dbauto/path1/
LOCAL_DB_DIRECTORY /database/inst461/NODE0000/sqldbdir/
LOGPATH /database/inst461/NODE0000/SQL00001/LOGSTREAM0000/
TBSP_CONTAINER /database/inst461/NODE0000/SQL00001/DMSclpm4
TBSP_CONTAINER /database/inst461/NODE0000/SQL00001/DMSCLPM2
TBSP_CONTAINER /database/inst461/NODE0000/SQL00001/tsp03
TBSP_CONTAINER /database/inst461/NODE0000/SQL00001/tsp02
TBSP_DIRECTORY /database/inst461/NODE0000/SQL00001/sms/sms01/
Database recovery: Split mirror copy planning

The SYSIBMADM.DBPATHS administrative view returns the values for database paths
required for tasks such as split mirror backups. The information needs to be collected
from several sources, including table space statistics and the database configuration.
The TYPE column values are:
• TBSP_DEVICE - Raw device for a database managed space (DMS) table space.
• TBSP_CONTAINER - File container for a DMS table space.
• TBSP_DIRECTORY - Directory for a system managed space (SMS) table space.
• LOGPATH - Primary log path.
• LOGPATH_DEVICE - Raw device for primary log path.
• MIRRORLOGPATH - Database configuration mirror log path.
• DB_STORAGE_PATH - Automatic storage path.
• DBPATH - Database directory path.
• LOCAL_DB_DIRECTORY - Path to the local database directory.

Tracking monitor history
CREATE TABLE con_history as Create your own

( select current timestamp AS CURRENT_TIME, monitor
appls_in_db2, history tables
appls_cur_cons, agents_top
from TABLE (MON_GET_DATABASE(-1)) AS MONDB )
definition only
INSERT into con_history Populate them on a regular

basis to use for problem
SELECT current timestamp,
tracking or perf tuning
appls_in_db2,
appls_cur_cons,
agents_top
from TABLE (MON_GET_DATABASE(-1)) AS MONDB ;
Tracking monitor history

The monitoring statistics returned by the monitor table functions and views are in
memory and are lost when the database or instance stops.
A normal Db2 table can be created to store the monitor statistics so that you can track
what is happening over time with your database.
The visual shows how a table could be created using the DEFINITION ONLY clause
that matches the monitoring query that retrieves selected statistics using the
MON_GET_DATABASE table function.

Demonstration 1
Db2 advanced monitoring with SQL
• Monitor database buffer pool hit ratios using a command line query
• Check free space in DMS table spaces to see if the allocated disk
space needs to be increased or reduced
• Monitor database and application use of active log space with a
command line query
• Check the performance statistics for Dynamic SQL statements in the
database package cache using a query
• Utilize command line queries to investigate lock contention and the
utilization of database lock memory
Demonstration 1: Db2 advanced monitoring with SQL

Demonstration 1:
Db2 advanced monitoring with SQL
Purpose:
This demonstration will show you how to investigate and address several
common problems including lock waits and low buffer pool hit ratios using
command line queries that select from the Db2 monitor functions and views.
Task 1. Setup Database Manager and Database

Configurations.
In this demonstration, you will be using SQL statements with Db2 monitor functions and
views to monitor various Db2 database conditions. You will configure the database to
set the stage for those conditions.
Run the command file clpmstart to update the Database Configuration for the TP1
database.
The following configuration changes will be made:
• LOGFILSIZ : 200
• LOGPRIMARY : 3
• LOGSECOND : 2
• LOCKLIST : 20
• MAXLOCKS : 10
1. Logon to the Linux system using the user id inst464, with a password of
ibm2blue.
You will use the Linux Terminal session to enter Db2 commands.
2. Right-click the empty Linux desktop and select Open in Terminal.
3. Enter the following commands in the Linux terminal session:
• export PS1='$PWD Monitor > '
• cd $HOME/monitor
• db2start
• ./clpmstart

Use the Db2 command file, clpmontables.ddl, to create the buffer pools, table
spaces, tables and indexes that will be used for this demonstration. There are
two new buffer pools, CLPBUFFL has 5000 pages, while CLPBUFFS has 100
pages. There are two table spaces, CLPMTSP1 which uses the larger buffer
pool CLPBUFFL and CLPMTSP2 which uses the small buffer pool CLPBUFFS.
The tables CLMP.HIST1 and CLMP.HIST2 will be created to use the two table
spaces. The table CLPM.TELLER will be created in the CLPMTSP2 table
space.
The file contains the following DDL:
-- Create New tablespaceS, tables and indexes
CREATE BUFFERPOOL CLPBUFFL SIZE 5000 ;
CREATE BUFFERPOOL CLPBUFFS SIZE 100 ;
CREATE USER TEMPORARY TABLESPACE USERTEMP ;
CREATE REGULAR TABLESPACE clpmTSP1

MANAGED BY DATABASE USING (file 'DMSclpm1' 8000, FILE 'DMSCLPM2' 8000 )
EXTENTSIZE 8 bufferpool clpbuffl PREFETCHSIZE AUTOMATIC NO FILE SYSTEM CACHING
;
CREATE REGULAR TABLESPACE clpmTSP2

MANAGED BY DATABASE USING (FILE 'DMSclpm3' 8000, FILE 'DMSclpm4' 8000)
EXTENTSIZE 8 bufferpool clpbuffs PREFETCHSIZE AUTOMATIC NO FILE SYSTEM
CACHING ;
CREATE TABLE clpm.HIST1

(ACCT_ID INTEGER NOT NULL,
TELLER_ID SMALLINT NOT NULL,
BRANCH_ID SMALLINT NOT NULL,
BALANCE DECIMAL(15,2) NOT NULL,
DELTA DECIMAL(9,2) NOT NULL,
PID INTEGER NOT NULL,
TSTMP TIMESTAMP NOT NULL WITH DEFAULT,
ACCTNAME CHAR(20) NOT NULL,
TEMP CHAR(6) NOT NULL )
IN clpmTSP1 ;
CREATE TABLE clpm.TELLER

(TELLER_ID SMALLINT NOT NULL,
TELLER_NAME CHAR(20) NOT NULL,
TELLER_CODE CHAR(2) NOT NULL,
ADDRESS CHAR(30) NOT NULL,

TEMP CHAR(40) NOT NULL)

IN clpmtsp2;
CREATE INDEX clpm.HIST1IX1 ON clpm.HIST1 (ACCT_ID) cluster ;
CREATE INDEX clpm.HIST1IX2 ON clpm.HIST1 (BRANCH_ID,TELLER_ID) ;
CREATE TABLE clpm.HIST2 LIKE clpm.HIST1 IN clpmTSP2 ;
CREATE INDEX clpm.HIST2IX1 ON clpm.HIST2 (ACCT_ID) ;

CREATE INDEX clpm.HIST2IX2 ON clpm.HIST2 (BRANCH_ID,TELLER_ID) ;
4. In the monitor terminal session, issue the following commands:
• db2 connect to tp1
• db2 -tvf clpmontables.ddl
Use the command file, clpmloads, to load data into the three new tables and
collect the catalog statistics using RUNSTATS.
5. In the monitor terminal session, issue the following command:
• ./clpmloads
The output from this command will look similar to the following:
Database Connection Information
Database server = DB2/LINUXX8664 11.1.2.2

SQL authorization ID = INST464
Local database alias = TP1
load from savehist.del of del modified by pagefreespace=10 messages clpmload1.msg

replace into clpm.hist1 nonrecoverable
Number of rows read = 137619

Number of rows skipped = 0
Number of rows loaded = 137619
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 137619
load from savehist.del of del modified by pagefreespace=10 messages clpmload2.msg

replace into clpm.hist2 nonrecoverable


load from teller.del of del modified by pagefreespace=10 indexfreespace=0 messages

clpmload3.msg replace into clpm.teller nonrecoverable

DB20000I The RUNSTATS command completed successfully.

DB20000I The TERMINATE command completed successfully.
Task 2. Monitor the effective use of DMS table spaces.

Use the db2 command file, TablespaceSize.clp, to check the size and percentage of
free pages in each of the table spaces.
TablespaceSize.clp - reports on the current size and remaining free space for each
table space.
tbsp_type as "Type", substr(tbsp_state,1,20) as "Status",
(tbsp_total_size_kb / 1024 ) as "Size (Meg)",
( 100 - tbsp_utilization_percent ) as "% Free Space",
((( 100 - tbsp_utilization_percent ) * tbsp_usable_size_kb) / 100000
) as "Meg Free Space"
from sysibmadm.mon_tbsp_utilization
1. In the monitor terminal session, issue the commands:
• db2 -tvf TablespaceSize.clp > tbsize1.txt
• more tbsize1.txt

The SQL result will look similar to the following:

tbsp_type as "Type",
substr(tbsp_state,1,20) as "Status",
(tbsp_total_size_kb / 1024 ) as "Size (Meg)",
( 100 - tbsp_utilization_percent ) as "% Free Space",
((( 100 - tbsp_utilization_percent ) * tbsp_usable_size_kb) / 100000 ) as "Meg
Free Space"
from sysibmadm.mon_tbsp_utilization
Tablespace Name Type Status Size (Meg)

% Free Space Meg Free Space
------------------------------ ---------- -------------------- -------------------
- ---------------- ---------------------------------
SYSCATSPACE DMS NORMAL
128 11.46 15.01
TEMPSPACE1 SMS NORMAL
0 0.00 0.00
USERSPACE1 DMS NORMAL
32 13.34 4.35
TP1SMALL DMS NORMAL
4 92.55 3.77
TP1HIST DMS NORMAL
78 76.77 61.31
TP1ACCTD DMS NORMAL
78 64.31 51.20
TP1ACCTI DMS NORMAL
20 17.22 3.52
SYSTOOLSPACE DMS NORMAL
32 97.86 32.05
USERTEMP SMS NORMAL
0 0.00 0.00
CLPMTSP1 DMS NORMAL
62 78.18 49.98
CLPMTSP2 DMS NORMAL
62 77.88 49.79
Note the Percent of free space for the table spaces CLPMTSP1 and
CLPMTSP2.
CLPMTSP1: % Free space: _______
CLPMTSP2: % Free space: _______
Alter the table space CLPMTSP1, reducing the size of the two containers to
3000 pages each. Rerun the Db2 command file, TablespaceSize.clp, to check
the current size and percentage of free pages in each of the table spaces.


• db2 " alter tablespace clpmtsp1 resize (all containers 3000) "
• db2 -tf TablespaceSize.clp > tbsize2.txt
• more tbsize2.txt
Tablespace Name Type Status Size (Meg)
% Free Space Meg Free Space
------------------------------ ---------- -------------------- -------------------
- ---------------- ---------------------------------
SYSCATSPACE DMS NORMAL
128 11.46 15.01
TEMPSPACE1 SMS NORMAL
0 0.00 0.00
USERSPACE1 DMS NORMAL
32 13.34 4.35
TP1SMALL DMS NORMAL
4 92.55 3.77
TP1HIST DMS NORMAL
78 76.77 61.31
TP1ACCTD DMS NORMAL
78 64.31 51.20
TP1ACCTI DMS NORMAL
20 17.22 3.52
SYSTOOLSPACE DMS NORMAL
32 97.86 32.05
USERTEMP SMS NORMAL
0 0.00 0.00
CLPMTSP1 DMS NORMAL
23 41.72 9.98
CLPMTSP2 DMS NORMAL
62 77.88 49.79
The tablespace CLPMTSP1 percentage free space should have been reduced
compared to the first result.

Task 3. Monitor buffer pool activity for application workloads.

In this section, a series of three SQL SELECT statements will be run using the new
tables, CLPM.HIST1 and CLPM.HIST2. The table CLPM.HIST1 will be using the larger
buffer pool, CLPBUFFL, while CLPM.HIST2 will use the smaller buffer pool,
CLPBUFFS. One query will join the tables to the table CLPM.TELLER. The db2batch
utility will be used to execute this set of three queries, repeating the sequence twenty
times. The generated report will include minimum, maximum and average elapsed
times for each set of three SQL statements.
The three queries in the file batchq1.sql are as follows:
SELECT * from clpm.hist1 order by balance desc ;
SELECT * from clpm.hist1 where
acct_id between 10000 and 25000 ;
SELECT hist1.ACCT_ID, hist1.TELLER_ID, hist1.BRANCH_ID,
hist1.BALANCE,
TELLER.TELLER_NAME, TELLER.BRANCH_ID, TELLER.BALANCE
FROM CLPM.hist1 AS hist1, CLPM.TELLER AS TELLER
WHERE hist1.TELLER_ID = TELLER.TELLER_ID AND HIST1.BRANCH_ID < 30
ORDER BY TELLER.TELLER_NAME ASC ;
• db2 terminate
You will now open a second terminal window which will be used as the
application terminal.
2. Right-click the Linux desktop and select Open in Terminal.
3. In the (new) application terminal session, issue the commands:
• export PS1='$PWD App1 > '
• db2batch -d tp1 -f batchq1.sql

The summary at the end of the report should look similar to the following:
* Summary Table:
Type Number Repetitions Total Time (s) Min Time (s) Max Time (s)
Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- ---
------------ -------------- -------------- -------------
Block 1 20 10.812892 0.485360 1.280374
0.540645 0.525697 3593920 120
* Total Entries: 1
* Total Time: 10.812892 seconds
* Minimum Time: 10.812892 seconds
* Maximum Time: 10.812892 seconds
* Arithmetic Mean Time: 10.812892 seconds
* Geometric Mean Time: 10.812892 seconds
---------------------------------------------
* Timestamp: Wed Nov 09 2016 15:30:26 EST
Notice the minimum and maximum elapsed times for a set of three queries.
These queries use the table CLPM.HIST1. Run a second set of queries that
reference the table CLPM.HIST2 using db2batch.
4. In the application terminal session, issue the command:
* Summary Table:
--------- ----------- ----------- -------------- -------------- -------------- ---
------------ -------------- -------------- -------------
Block 1 20 77.854982 3.666034 4.262139
3.892749 3.889844 3593920 120
* Total Entries: 1
---------------------------------------------
Note the minimum and maximum elapsed times for a set of three queries.

Your results might vary from the example, but the use of a small buffer pool
would be expected to show:
• Longer execution times
• Reduced benefit in improved execution times as the queries were repeated.
Use the Db2 command file, Mon_bufferio.clp, to show buffer pool hit ratios for
each buffer pool. Use the UNIX vi editor to review the results.
Mon_bufferio.clp - reports on the buffer pool hit ratios for data and index page
requests.
select substr(bp_name,1,30) as bp_name ,
pool_data_l_reads, pool_data_p_reads,
(100 * (pool_data_l_reads - pool_data_p_reads )) /( pool_data_l_reads ) as
data_hit_pct,
pool_index_l_reads,pool_index_p_reads ,
(100 * (pool_index_l_reads - pool_index_p_reads )) /( pool_index_l_reads ) as
index_hit_pct
from table (mon_get_bufferpool(NULL,-2) ) as tbuff
where bp_name not like 'IBMSYSTEM%' and pool_data_l_reads > 0 and
pool_index_l_reads > 0
• db2 -tf Mon_bufferio.clp | tee clpm1.txt
------------------------------ -------------------- -------------------- -------------------
- -------------------- -------------------- --------------------
IBMDEFAULTBP 1300 260
80 1716 421 75
CLPBUFFL 139567 2760
98 185 21 88
CLPBUFFS 165692 138299
16 353 251 28
Notice the lower Data and Index hit ratios for the small buffer pool CLPBUFFS.
In the larger buffer pool CLPBUFFL, Db2 was able to keep more high use
pages in memory to improve the performance of the queries. The buffer pool
CLPBUFFS was too small to retain many of the pages that were read by the
repeating queries.
Increase the buffer pool CLPBUFFS to 5000 pages and rerun the second set of
db2batch queries to evaluate the performance improvement with a larger buffer
pool.
6. In the monitor terminal session, issue the command:
• db2 alter bufferpool clpbuffs immediate size 5000


* Summary Table:
--------- ----------- ----------- -------------- -------------- -------------- ---
------------ -------------- -------------- -------------
Block 1 20 10.664639 0.484065 1.264318
0.533232 0.518434 3593920 120
* Total Entries: 1
---------------------------------------------
• db2 -tf Mon_bufferio.clp | tee clpm2.txt
• more clpm2.txt
------------------------------ -------------------- -------------------- -------------------
- -------------------- -------------------- --------------------
IBMDEFAULTBP 1322 264
80 1744 430 75
CLPBUFFL 139567 2760
98 185 21 88
CLPBUFFS 305923 140990
53 524 267 49
The Data and Index Hit Ratios should have improved. The calculated
percentage includes all of the physical reads from the first db2batch runs with
the smaller buffer pool size, so the larger buffer pool will gradually produce a
better hit ratio percentage as more queries are run.

Task 4. Monitor Db2 log activity for application workloads.

In this section, the database logging activity will be monitored. First, you will increase
the number of secondary logs to 25 to allow larger update transactions, like the SQL in
the file update1.sql, to process. Use the Db2 command file, LogSpaceUsage.clp, to
display the current log space. To get information about the application that might be
causing a shortage of log space use the file OldTransHoldingLog.clp
LogSpaceUsage.clp: Reports the maximum database log space used as well as the
current log space used and available:
select int(total_log_used/1024/1024) as "Log Used (Meg)",
int(total_log_available/1024/1024) as "Log Space Free (Meg)",
int((float(total_log_used) /
float(total_log_used+total_log_available))*100) as "Pct Used",
int(sec_logs_allocated) as "Secondaries"
from table (MON_GET_TRANSACTION_LOG(-2)) as tlogs
OldTransHoldingLog.clp - reports the status of the application that is currently the
oldest update transaction in the database:
substr(uow.session_auth_id,1,10) as "Authid",
uow.application_handle as "Appl Handle",
int(uow.UOW_LOG_SPACE_USED/1024/1024) as "Log Used (M)",
uow.total_act_time as "Total Activity time(msec)",
uow.total_act_wait_time as "Total Activity Wait time",
uow.uow_start_time as "UOW Start Time"
• db2 update db cfg using logsecond 25
2. In the application terminal session, issue the commands:
• db2 +c -tvf update1.sql
The output should look similar to the following:
update clpm.hist1 set balance=balance+1 where branch_id > 3
DB20000I The SQL command completed successfully.


• db2 -tvf LogSpaceUsage.clp | tee clpm4.txt
select int(total_log_used/1024/1024) as "Log Used (Meg)",
int(total_log_available/1024/1024) as "Log Space Free (Meg)",
int((float(total_log_used) / float(total_log_used+total_log_available))*100) as
"Pct Used",
int(sec_logs_allocated) as "Secondaries"
from table (MON_GET_TRANSACTION_LOG(-2)) as tlogs
Log Used (Meg) Log Space Free (Meg) Pct Used Max Log Used (Meg) Max Sec. Used
(Meg) Secondaries
-------------- -------------------- ----------- ------------------ ---------------
---- -----------
18 2 86 18
16 22
At this point, a large percentage of the database log space defined has been
consumed by the uncommitted UPDATE statement.
• db2 -tvf OldTransHoldingLog.clp | tee clpm5.txt
substr(uow.session_auth_id,1,10) as "Authid", uow.application_handle as "Appl
Handle",
int(uow.UOW_LOG_SPACE_USED/1024/1024) as "Log Used (M)", uow.total_act_time as
"Total Activity time(msec)", uow.total_act_wait_time as "Total Activity Wait
time", uow.uow_start_time as "UOW Start Time"
Status Authid Appl Handle Log Used (M) Total Activity

time(msec) Total Activity Wait time UOW Start Time
-------------------- ---------- -------------------- ------------ ----------------
--------- ------------------------ --------------------------
UOWWAIT INST464 10502 18
3113 1225 2016-11-15-11.11.30.451676
--------- ----------- ----------- -------------- -------------- --------------

This report shows several important pieces of information, the amount of log
space being used by the oldest logged transaction and the current application
status.
Since Db2 must hold all of the database changes from the point of the oldest
transaction to the latest change in the active log space, an application that
enters a prolonged wait status might cause a database log full condition.
If a transaction remains uncommitted for an extended period of time, any
database crash recovery that would occur could take a long time to process all
of the changes from the start of the oldest transaction forward.
Now use a COMMIT statement to free up the logged changes by the application
and then recheck the amount of log space used.
• db2 commit
• db2 -tf OldTransHoldingLog.clp | tee clpm6.txt
Status Authid Appl Handle Log Used (M) Total Activity
time(msec) Total Activity Wait time UOW Start Time
-------------------- ---------- -------------------- ------------ ----------------
--------- ------------------------ --------------------------
The active log space was freed by the application's COMMIT.
There is currently no active transaction holding database log space so the
monitor query does not return any data results.

Task 5. Monitor locking activity for application workloads.

In this section, application locking activity will be monitored. A second application
command window will be started to allow lock contention to be simulated. The following
Db2 command files will be used to create reports
Mon_LockChains.clp - will be used to report information about an application that is
waiting on a lock.
substr(lw.hld_userid,1,10) as "Holder",
lw.lock_mode ,
lw.lock_object_type ,
lw.lock_wait_elapsed_time
as "waiting (s)"
from sysibmadm.mon_lockwaits lw ;
Mon_ConnectLock.clp - will be used to report on lock related events, like lock
escalations, timeouts and deadlocks.
from table(MON_GET_CONNECTION(NULL,-1)) as conn ;

LockMemoryUsage.clp - Will be used to report on the current usage of the memory in

the database locklist.
with
dbcfg1 as ( select float(int(value) * 4096) as locklist
from sysibmadm.dbcfg where name = 'locklist' ) ,
dbcfg2 as ( select float(int(value)) as maxlocks
from sysibmadm.dbcfg where name = 'maxlocks' )
select
dec((MDB.lock_list_in_use/(locklist*(maxlocks/100))*100),4,1) as "%
to Maxlock",
MDB.appls_cur_cons as "Number of Cons",
MDB.lock_list_in_use/MDB.appls_cur_cons
from dbcfg1, dbcfg2 , table (MON_GET_DATABASE(-1)) AS MDB
Mon_Locks.clp - Will be used to produce a summary of the locks currently held by
each application connection.
select application_handle,
varchar(lock_object_type,10) as object_type,
lock_mode, lock_status,
count(*) as lock_count
from table(MON_GET_LOCKS( NULL, -1)) AS monlocks
where lock_object_type in ('TABLE','ROW')
group by application_handle,lock_object_type,lock_mode,lock_status
order by application_handle,lock_object_type,lock_mode,lock_status
You will now open a second (application) terminal window for running
application SQL.
1. Right-click the Linux desktop and select Open in Terminal.
2. In the second (new) application terminal session, issue the commands:
• export PS1='$PWD App2 > '

3. In the first application terminal session, issue the commands:

• db2 connect reset
update clpm.hist1 set balance=balance+1 where branch_id between 10 and 15
4. In the second application terminal session, issue the command:
update clpm.hist1 set balance=balance+1 where branch_id = 1
The second application's UPDATE SQL statement does not complete. Use the
Db2 command file, LockChains.clp, to check to see if a lock wait condition is
the problem.
• db2 -tvf Mon_LockChains.clp | tee clpm7.txt
substr(lw.hld_userid,1,10) as "Holder",
lw.lock_mode , lw.lock_object_type ,
lw.lock_wait_elapsed_time as "waiting (s)"
from sysibmadm.mon_lockwaits lw
Hold App Holder Wait App Waiter LOCK_MODE LOCK_OBJECT_TYPE

TabName Schema waiting (s)
---------- ---------- ---------- ---------- --------- ----------------------------
---- ---------- ---------- -----------
db2bp INST464 db2bp INST464 X TABLE
HIST1 CLPM 150
This result shows that the second application is waiting for a lock on the table
CLPM.HIST1 and that an exclusive table lock (X) is held by another application.
The exclusive table lock might have been the result of a lock escalation. Use the
Db2 command file, Mon_ConnectLock.clp, to check if any lock escalations
have occurred.


• db2 -tvf Mon_ConnectLock.clp | tee clpm8.txt
from table(MON_GET_CONNECTION(NULL,-1)) as conn
APPLICATION AUTHID # Locks Escalations Lock Timeouts

Deadlocks Lock Wait Time
----------- ---------- -------------------- -------------------- -----------------
--- -------------------- --------------------
db2bp INST464 2 1
0 0 0
db2bp INST464 2 0
0 0 0
db2bp INST464 3 0
0 0 319
This result shows that one of the applications has experienced a lock
escalation.
Use the Db2 command file, LockMemoryUsage.clp, to check the current
status of locklist memory for the database.


• db2 -tvf LockMemoryUsage.clp | tee clpm9.txt
Log Used (Meg) Log Space Free (Meg) Pct Used Max Log Used (Meg) Max Sec. Used
(Meg) Secondaries
with dbcfg1 as ( select float(int(value) * 4096) as locklist from
sysibmadm.dbcfg where name = 'locklist' ) ,
dbcfg2 as ( select float(int(value)) as maxlocks
from sysibmadm.dbcfg where name = 'maxlocks' )
select
dec((MDB.lock_list_in_use/(locklist*(maxlocks/100))*100),4,1) as "% to Maxlock",
MDB.appls_cur_cons as "Number of Cons", MDB.lock_list_in_use/MDB.appls_cur_cons
from dbcfg1, dbcfg2 , table (MON_GET_DATABASE(-1)) AS MDB
----------- ------------ -------------------- ----------------------------
22.6 226.5 3 6186
You might wonder if there is a lock memory related problem, why is lock
memory utilization low?
The lock escalation process released a large number of row locks freeing a
large portion of the database lock memory by acquiring an exclusive table level
lock.
Use a SQL COMMIT to complete the transactions and release the locks.
• db2 commit
9. In the second application terminal session, issue the commands:
• db2 commit
In order to avoid the lock escalation and prevent the application lock wait,
increase the size of the locklist to 2000 pages and increase the percentage of
the locklist available for one application to 50%.
Run the same update SQL statements and check the lock status with the db2
queries.


• db2 update db cfg using locklist 2000 maxlocks 50
12. In the second application terminal session, issue the command:
The second application's UPDATE SQL statement now completes without the
lock wait. Use the Db2 command file, LockMemoryUsage.clp, to check the
current status of locklist memory for the database.
• db2 -tf LockMemoryUsage.clp | tee clpm10.txt
----------- ------------ -------------------- ----------------------------
29.9 59.9 3 819072
The increased lock memory and maximum lock storage per application allowed
the two update applications to run concurrently. No single application needed
over 50% of the increased locklist memory for its locks.
The MON_GET_LOCKS table function can be used to produce a summary of
the number of each type of lock held by the current database connections. Use
the Db2 command file, Mon_Locks.clp, to produce a summary of locks held by
each application.


• db2 -tvf Mon_Locks.clp | tee clpm11.txt
select application_handle,
varchar(lock_object_type,10) as object_type,
lock_mode, lock_status, count(*) as lock_count
from table(MON_GET_LOCKS( NULL, -1)) AS monlocks
where lock_object_type in ('TABLE','ROW')
group by application_handle,lock_object_type,lock_mode,lock_status
order by application_handle,lock_object_type,lock_mode,lock_status
APPLICATION_HANDLE OBJECT_TYPE LOCK_MODE LOCK_STATUS LOCK_COUNT

-------------------- ----------- --------- ----------- -----------
10609 ROW X G 8105
10609 TABLE IX G 1
10610 ROW X G 1435
10610 TABLE IX G 1
The two application connections are able to hold table and row locks for the
same table and continue to process without lock waits now.
Use a SQL COMMIT to complete the transactions and release the locks.
• db2 commit
16. In the second application terminal session, issue the commands:
• db2 commit
Use the Db2 command file, clpmonend.ddl, to reset the Db2 database
configuration and drop the table spaces, buffer pools and tables used during
this demonstration.
• db2 -tvf clpmonend.ddl
18. Close all terminals and then logout of the Linux operating system.
Results:
You used a set of SQL statements with Db2 monitor table functions and views
to monitor table space utilization, buffer pool efficiency, database log space
usage and application lock contention.

Unit summary
Unit summary


Db2 Table Space Management
Db2 Table Space Management

U n i t 2 D b 2 Ta b l e S p a c e M a n a g e m e n t

Unit objectives
• Monitor tablespace space allocations using SQL with
MON_GET_TABLESPACE and MON_GET_CONTAINERS functions
• ALTER a table space to handle High Water Mark related issues and
reclaim unused space from DMS and Automatic Storage table spaces
• Use the REBALANCE option to control container allocations for
Automatic Storage table spaces when changing storage paths
• Monitor the processing done by the Rebalancer using LIST UTILITIES
and db2pd commands
• Plan and implement changes to disk space allocations using ALTER
TABLESPACE options: ADD, EXTEND, RESIZE, DROP, and BEGIN
NEW STRIPE SET
• Convert a DMS-managed table space to use Automatic Storage
• Move a Tablespace from one storage group to another
Db2 Table Space Management © Copyright IBM Corporation 2018
Unit Objectives

DMS and Automatic Storage table space characteristics

• Db2 directly manages disk space allocation to objects using the table
space extent size
• Containers are either operating system files or raw devices(DMS):
 With DMS, table space capacity can be increased manually online by
adding new containers or extending existing ones using DDL
 Unused space can be manually reduced or eliminated online using DDL
 AUTORESIZE can be used to help avoid SQL -289 failures
• Data is striped across containers by extent
• Disk space is allocated at table space creation/extension time
 SMPs (Space Map Pages) keep track of what extents are used and which
are free
• Data objects are located by:
 OBJECT TABLE - Locates first extent in the object
 EMPs (Extent Map Pages) for the object - Locate other extents in the object
DMS and Automatic Storage table space characteristics

For DMS and Automatic storage table spaces Db2 directly manages the disk space
allocation as objects are created, extended, or dropped.
• The containers for DMS table spaces can be either operating system files or
raw devices. Raw devices can only be used for DMS tablespaces.
• With DMS you can increase table space capacity online by adding new
containers or extending existing ones using ALTER TABLESPACE DDL.
• You can decrease capacity online by shrinking or dropping containers online
using ALTER TABLESPACE DDL.
• The AUTORESIZE option can be used to help prevent the SQL code -289
failures when the table space is full, by automatically extended the table
space file containers. Autoresize is enabled by default for Automatic Storage
tablespaces and not enabled for DMS managed tablespaces.
• The data is striped across containers by extent to improve the I/O parallelism
when scanning data and index pages.

• The Disk space is allocated at table space creation (CREATE

TABLESPACE) OR extension (ALTER TABLESPACE) time. This can be
used to reserve space for critical applications or restrict growth for certain
table spaces.
• Db2 maintains SMPs (Space Map Pages) to keep track of what extents are
used and which are free.
The data objects are located using:
• The OBJECT TABLE - Locates first extent in the object.
• The EMPs (Extent Map Pages) for the object - Locate other extents in the
object.

DMS table spaces: Internal structure
Background – DMS table spaces What happens on disk after the following:
db2 create tablespace tb2 managed by
Table space (Logical) Address Map database using (file '/db2file1' 1024,
file '/db2file2' 2048)
0 Table space Header
extentsize 4 prefetchsize 8
1 First SMP Extent
db2 create table t1 in tb2
2 Object Table
db2 create table t2 in tb2
3 Extent Map for T1
4 First Extents of Data

/mydir1/. Container (Physical) Address Map
Pages for T1
5
6 Extent Map for T2
0
2
/mydir2/.
Tag
1
3
Tag
4 5
First Extent of Data Pages 6 7
7 for T2 8 9
10 11
8 Another Extent of Data 12 13
Pages for T1 14 15
508 509
31968 Second SMP Extent /db2file1
/db2file2
DMS table spaces: Internal structure

Here is an example of a CREATE TABLESPACE DDL statement for a DMS managed
table space.
db2 create tablespace tb2 managed by database
using (file '/db2file1' 1024, file '/db2file2' 2048)
extentsize 4 prefetchsize 8
The table space tb2 will have two containers, one file '/db2file1' with 1024 pages and
another file '/db2file2' with 2048 pages. The extent size is 4 pages, so prefetch size was
set to 8 pages to support parallel I/O of the two containers. The extents will be striped
across the two containers.
The first extent in the logical table space address map is a header for the table space
containing internal control information. The second extent is the first extent of space
map pages (SMP) for the table space. SMP extents are spread at regular intervals
throughout the table space. Each SMP extent is a bit map of the extents from the
current SMP extent to the next SMP extent. The bit map is used to track which of the
intermediate extents are in use.
The next extent following the SMP is the object table for the table space. The object
table is an internal table that tracks which user objects exist in the table space and
where their first extent map page (EMP) extent is located. Each object has its own

EMPs which provide a map to each page of the object that is stored in the logical table
space address map.
For each table object created, two extents are allocated to hold the extent map for that
object and one extent for storing data. Additional extents will be assigned to the tables
as needed.
Extents are never shared among the objects in a DMS table space, so small tables can
contain a number of empty pages, depending on the extent size defined for the table
space. The indexes for each table are treated as a group object, so all of the indexes
for one table will share a common extent map extent, rather than require one for each
index.

Table space management: High Water Marks

• TS High Water Mark is the highest
numbered page that is currently
allocated to some object or used
for internal space management.
• High Water Mark is NOT the
highest numbered page ever
used in the table space.
• HWM can be much higher than
the number of pages currently
in use due to dropped tables or
offline table REORG
• This effects both DMS and non-temporary Automatic Storage table spaces
 Limits ability to release currently unused space
 Increases amount of data, extents saved by BACKUP utility
• Db2 provides methods to reduce the HWM
 ALTER TABLESPACE LOWER HIGH WATER MARK
 ALTER TABLESPACE REDUCE MAX (Auto Storage)
Table space management: High Water Marks

One of the characteristics of DMS managed table spaces is the High Water Mark for
the table space. The High Water Mark for DMS table spaces can be monitored using
the table function MON_GET_TABLESPACE.
The table space High Water Mark is the highest numbered page that is currently
allocated to some object or used for internal space management. The High Water Mark
is not the highest numbered page ever used in the table space. It can increase or
decrease as Db2 manages the extents assigned to objects in the table space.
In some cases, the High Water Mark is equal to number of pages currently allocated in
the table space but it can also be much higher. When an Offline REORG utility is used
to reorganize a table and a temporary table space is not assigned, the High Water Mark
might increase or decrease significantly. Dropping a table might also cause the High
Water Mark to be greater than the number of pages currently in use.
In most cases, the High Water Mark has little or no impact on the use of the table space
to support applications. There are a few cases where the current High Water Mark
might become an issue for a DBA.
The ALTER TABLESPACE options LOWER HIGH WATER MARK and REDUCE can
be used to rearrange the extents in a table space to reduce the high water mark and
allow the unused disk space to be released.

The Db2 Backup utility copies the extents in DMS table spaces up to the High Water
Mark to the backup image. Any Redirected RESTORE of the table space must allocate
containers with space equal to or greater than the High Water Mark at the time of the
BACKUP, even though there might be many free extents included.

High Water Mark: Dropped table (Example 1)

Monitor using
Table space Header MON_GET_TABLESPACE Table space Header
SMP Extent 1
Total number of pages = 200 SMP Extent 1
Object Map Number of usable pages = 192 Object Map
Table1 Extent 0 Extent Map Number of used pages = 120 Table1 Extent 0 Extent Map
Table1 Extent 1 Number of free pages = 72
Table1 Extent 1
High water mark (pages) = 120
Table1 Extent 2
Table1 Extent 3
Table1 Extent 3
Table1 Extent 3
Table1 Extent 4
Table1 Extent 4
Table1 Extent 5
DROP TABLE2
Table1 Extent 5
Table2 Extent 0 Extent Map
Free
Table2 Extent 1
Free
Total number of pages = 200
Table2 Extent 2
Free
Number of usable pages = 192
Table2 Extent 3
Number of used pages = 88 Free
Table1 Extent 6 Number of free pages = 104 Table1 Extent 6
Table1 Extent 7 High water mark (pages) = 120 Table1 Extent 7
Free Extents
High Water Mark did NOT change Free Extents
Extent size 8 pages

This shows some of the monitor elements returned by MON_GET_TABLESPACE
before and after a DROP TABLE statement for one table was executed.
By dropping Table2, the 4 extents (32 pages) assigned to that table are now free, so
the number of used pages decreased from 120 to 88. The number of free pages
increase from 72 to 104. Those pages are now available to create a new table or to
extend the other table.
Notice that before the drop table the High Water Mark was 120, which was equal to the
number of used pages. The drop table did not change the table space High Water
Mark, because the page at the High Water Mark is still in use by the remaining table.


Monitor using
SMP Extent 1 Total number of pages = 200 SMP Extent 1
Object Map Number of usable pages = 192 Object Map
Number of used pages = 120
Table1 Extent 0 Extent Map Free
Number of free pages = 72
Table1 Extent 1 Free
DROP Table1
Table2 Extent 0 Extent Map Table2 Extent 0 Extent Map
Table2 Extent 1 Table2 Extent 1
Table2 Extent 2 Table2 Extent 2
Table2 Extent 3 number of free pages = 136
Table2 Extent 3
Table1 Extent 6 High water mark (pages) = 104 Free
Free Extents High Water Mark DOES change Free Extents
Extent size 8 pages


before and after a DROP TABLE statement for the other table in the table space was
executed.
By dropping Table1, the 8 extents (64 pages) assigned to that table are now free, so
the number of used pages decreased from 120 to 56. The number of free pages
increased from 72 to 136. Those pages are now available to create a new table or to
extend the other table.
Before the dropping the table, the High Water Mark was 120, which was equal to the
number of used pages. The dropped table did reduce the table space High Water Mark
from 120 to 104, because the page at the original High Water Mark was freed. The
current High Water Mark is higher than the number of used pages because there are
now 6 free extents (48 pages) below the point of the High Water Mark.

High Water Mark: Offline table REORG with no temporary

tablespace (Example 1)
Monitor using
SMP Extent 1 SMP Extent 1

Object Map Object Map
Table1 Extent 0 Extent Map Number of used pages = 72 Free
Table1 Extent 1 number of free pages = 120 Free

High water mark (pages) = 72 Free
Table1 Extent 2
REORG TABLE1
Free Total number of pages = 200 Table1 Extent 0 Extent Map
Free Number of usable pages = 192 Table1 Extent 1

Number of used pages = 64 Table1 Extent 2
Free
Free Table1 Extent 3
Free Free
Free Extents High Water Mark Increases Free Extents
Extent size 8 pages

High Water Mark: Offline table REORG with no temporary tablespace (Example 1)
before and after a REORG utility was used to reorganize the only table in a table space.
This is an offline REORG, with no temporary table space assigned.
For example:
db2 REORG TABLE TABLE1
If no temporary table space is assigned for the REORG, a new copy of the table is built
using additional extents from the table's table space. The original copy of the table
remains intact until the new copy is completed.
In this example, the reorganization was able to reduce the number of extents required
for TABLE1, so the number of used pages decreased from 72 to 64. The number of
free pages increased from 120 to 128. Those pages are now available to create a new
table or to extend TABLE1.
In this case, the original High Water Mark was 72, which was equal to the number of
used pages. The REORG increased the table space High Water Mark from 72 to 112,
because table data was copied to higher numbered extents. The current High Water
Mark is higher than the number of used pages because there are now 6 free extents
(48 pages) below the point of the High Water Mark.

High Water Mark: Offline table REORG with no temporary

tablespace (Example 2)
Monitor using
MON_GET_TABLESPACE
Table space Header Table space Header
SMP Extent 1 Total number of pages = 200 SMP Extent 1
Number of usable pages = 192 Object Map
Object Map
Free Table1 Extent 0 Extent Map
REORG Table1
Free Free
Free Free
Table1 Extent 0 Extent Map Free
Table1 Extent 1 Total number of pages = 200 Free
Table1 Extent 2 Number of usable pages = 192 Free

Free Free
Free Free
Free Extents High Water Mark Decreases Free Extents
Extent size 8 pages

High Water Mark: Offline table REORG With no temporary tablespace (Example 2)
before and after a REORG utility was used to reorganize the only table in a table space.
This is an offline REORG, with no temporary table space assigned.
For example:
db2 REORG TABLE TABLE1
Like the previous example, no temporary table space is assigned for the REORG, so
the new copy of the table is built using additional extents from the table's table space. In
this case, there were enough free extents below the High Water Mark to make the copy
of the table.
In this example, the reorganization did not reduce the number of extents required for
TABLE1, so the number of used pages remained 56 and the number of free pages
remained 136.
The original High Water Mark was 104 and there were a number of free extents below
that point in the table space. The extent holding the original High Water Mark was freed
by the reorganization so the High Water Mark decreased from 104 to 56, because table
data was copied to lower numbered extents. The current High Water Mark is now equal
to the number of used pages.

Using MON_GET_CONTAINER and MON_GET_TABLESPACE to

check space allocations
SELECT VARCHAR(TBSP_NAME,10) AS TBSP_NAME, CONTAINER_ID, STRIPE_SET ,
CONTAINER_TYPE, TOTAL_PAGES
FROM TABLE(MON_GET_CONTAINER(NULL,-1)) AS CONT WHERE TBSP_NAME IN ('DMSMTSPD','ASMTSPD')
ORDER BY TBSP_NAME,CONTAINER_ID
TBSP_NAME CONTAINER_ID STRIPE_SET CONTAINER_TYPE TOTAL_PAGES

USABLE_PAGES
---------- -------------------- -------------------- ---------------- --------------------
ASMTSPD 0 0 FILE_EXTENT_TAG 4512
DMSMTSPD 0 0 FILE_EXTENT_TAG 4000
SELECT VARCHAR(TBSP_NAME,20) AS TBSP_NAME, TBSP_TOTAL_PAGES AS TOTAL_PAGES,

TBSP_USED_PAGES AS USED_PAGES , (100 * TBSP_USED_PAGES / TBSP_TOTAL_PAGES ) AS
PCT_USED,
TBSP_PAGE_TOP AS HIGH_WATER_MARK, (100 * TBSP_PAGE_TOP / TBSP_TOTAL_PAGES ) AS PCT_HWM
FROM TABLE (MON_GET_TABLESPACE(NULL,-1)) AS TBSP WHERE TBSP_NAME IN
('DMSMTSPD','ASMTSPD') ORDER BY TBSP_NAME
TBSP_NAME TOTAL_PAGES USED_PAGES PCT_USED HIGH_WATER_MARK PCT_HWM

----------- ----------- ----------- --------- ----------------- ---------
ASMTSPD 13536 3176 23 10904 80
DMSMTSPD 14000 3176 22 10904 77
Using MON_GET_CONTAINER and MON_GET_TABLESPACE to check space

allocations
The slide shows SQL query examples that can be used to gather information on the
current space usage for table spaces, including the high water mark.
The first SQL query uses the table function MON_GET_CONTAINERS to retrieve the
number and size of the containers for two tablespaces.
The second query example uses the table function MON_GET_TABLESPACE to find
the allocation size, current space usage and also the current high water mark for two
tablespaces. Notice that in both example the high water mark is significantly higher than
the current space used.

Db2 functions to reclaim unused storage

• DMS and non-temporary Automatic Storage-managed table spaces
have an internal structure that allows extents to be remapped to lower
the high water mark
• For Automatic Storage table spaces, the REDUCE MAX option can be
used to release all unused space
db2 alter tablespace ASTS1 reduce max
• For DMS, it requires two steps to release the unused extents:

1. The High Water can be reduced to match the number of used extents
with the LOWER HIGH WATER MARK option
db2 alter tablespace DMSTS1 lower high water mark
2. Next the ALTER TABLESPACE options REDUCE, RESIZE or DROP can
be used to adjust the space assigned
db2 alter tablespace DMSTS1 reduce (all containers 100 M)
Db2 functions to reclaim unused storage

For a DMS or Automatic Storage table space you can use reclaimable storage to return
unused storage to the system for reuse. Reclaiming storage is an online operation; it
does not impact the availability of data to users.
You can reclaim the unused storage at any time by using the ALTER TABLESPACE
statement with the REDUCE option:
• For Automatic Storage table spaces, the REDUCE option has sub options to
specify whether to reduce storage by the maximum possible amount or by a
percentage of the current table space size.
• For DMS table spaces, first use the ALTER TABLESPACE statement with
the LOWER HIGH WATER MARK option, and then execute the ALTER
TABLESPACE statement with the REDUCE option and associated container
operation clauses.

Reclaiming space using ALTER TABLESPACE with

Automatic Storage
• When the REDUCE option of ALTER TABLESPACE is used for an
Automatic Storage table space:
 Empty containers can be dropped
 Db2 might move used extents to free space nearer the beginning of the table
space
 Containers can be re-sized
 You can specify the amount of space reduction:
− The maximum amount possible
− An amount that you specify in kilobytes, megabytes or gigabytes, or pages
−A percentage of the current size of the table space
− Ifyou do not specify an amount, the table space size is reduced as much as possible
without moving extents
 For table spaces with reclaimable storage, the High Water Mark can be reduced
• The LOWER HIGH WATER MARK option of ALTER TABLESPACE will
move the maximum number of extents in order to lower the high water
mark; however, no container re-sizing operations are performed.
Reclaiming space using ALTER TABLESPACE with Automatic Storage

When you reduce the size of an Automatic Storage table space, the database manager
attempts to lower the high water mark for the table space and reduce the size of the
table space containers. In attempting to lower the high water mark, the database
manager might drop empty containers and might move used extents to free space
nearer the beginning of the table space. Next, containers are re-sized such that total
amount of space in the table space is equal to or slightly greater than the high water
mark.
You can see which table spaces in a database support reclaimable storage using the
MON_GET_TABLESPACE table function.
You can reduce the size of an Automatic Storage space for which reclaimable storage is
enabled in a number of ways. You can specify that the database manager reduce the
table space by:
• The maximum amount possible
• An amount that you specify in kilobytes, megabytes or gigabytes, or pages
• A percentage of the current size of the table space.

In each case, the database manager attempts to reduce the size by moving extents to
the beginning of the table space, which, if sufficient free space is available, will reduce
the high water mark of the table space. Once the movement of extents has completed,
the table space size is reduced to the new high water mark.
If you do not specify an amount by which to reduce the table space, the table space
size is reduced as much as possible without moving extents. The database manager
attempts to reduce the size of the containers by first freeing extents for which deletes
are pending. (It is possible that some pending delete extents cannot be freed for
recoverability reasons, so some of these extents might remain.) If the high water mark
was among those extents freed, then the high water mark is lowered, otherwise no
change to the high water mark takes place. Next, the containers are re-sized such that
total amount of space in the table space is equal to or slightly greater than the high
water mark. This operation is performed using the ALTER TABLESPACE with the
REDUCE clause by itself.
If you only want to lower the High Water Mark, consolidating in-use extents lower in the
table space without performing any container operations, you can use the ALTER
TABLESPACE statement with the LOWER HIGH WATER MARK clause. This option
moves the maximum number of extents in order to lower the high water mark, however,
no container re-sizing operations are performed. This operation is performed using the
ALTER TABLESPACE with the LOWER HIGH WATER MARK clause by itself.
Once a REDUCE or LOWER HIGH WATER MARK operation is under way, you can
stop it by using the REDUCE STOP or LOWER HIGH WATER MARK STOP clause of
the ALTER TABLESPACE statement. Any extents that have been moved will be
committed, the high water mark will be reduced to it's new value and containers will be
re-sized to the new high water mark.

Reclaimable Automatic Storage: Example 1
ALTER
DROP Table2 TABLESPACE …
DROP Table3 REDUCE MAX
Internal tablespace metadata extents

Table1
Table2
Table3
Extent that is allocated to tablespace, but not to a table

This is an example of reducing an Automatic Storage table space by the maximum
amount possible.
The statement would simply be: ALTER TABLESPACE TS1 REDUCE MAX
In this case, the keyword MAX is specified as part of the REDUCE clause, indicating
that the database manager should attempt to move the maximum number of extents to
the beginning of the table space. This might be used when a table is loaded for read-
only access and no additional growth is expected, until the data is refreshed.

ALTER
TABLESPACE …
REDUCE 25
DROP Table2
PERCENT
DROP Table3
Internal tablespace metadata extents

Table1
Table2
Table3
Extent that is allocated to tablespace, but not to a table

This example illustrates reducing an Automatic Storage table space by a percentage of
the current table space size.
The command syntax is this case could be:
ALTER TABLESPACE TS1 REDUCE 25 PERCENT
This attempts to reduce the size of the table space TS1 to 75% of it's original size, if
possible.
This form might be used to reduce the current disk requirements for a table space, but
still retain some available free space for efficient growth.
During the extent consolidation process, extents that contain data are moved to unused
extents below the high water mark. After extents are moved, if free extents still exist
below the high water mark, they are released as free storage. Next, the high water
mark is moved to the page in the table space just after the last in-use extent.

Checking table spaces for reclaimable storage

select substr(TBSP_NAME,1,14) as TS_NAME ,
TBSP_TOTAL_PAGES as Total_pages,
TBSP_USED_PAGES as Used_pages ,
TBSP_PAGE_TOP as High_water_MARK ,
reclaimable_space_enabled
from table ( MON_GET_TABLESPACE ( NULL , -1 ) ) as ts
where TBSP_NAME NOT LIKE ('SYS%') and TBSP_TYPE = 'DMS'
TS_NAME TOTAL_PAGES USED_PAGES HIGH_WATER_MARK RECLAIMABLE_SPACE_ENABLED
-------------- -------------- -------------------- -------------------- -------------

USERSPACE1 8192 3264 3264 0
TP1DMSH 4608 3120 3120 0
TP1DMSAD 12000 6400 6400 0
TP1DMSAI 20000 7040 13984 1
MDCTSP1 8192 5760 5760 1
MDCTSP2 8192 2048 2048 1
• Use the MON_GET_TABLESPACE monitoring table function

• Look for table spaces with a HWM that is much higher than the number of used
pages
• Look for the reclaimable space attribute of ‘1’
Checking table spaces for reclaimable storage

The ability to use the new ALTER TABLESPACE options to lower the high water mark
depend on whether the table space supports reclaimable storage. The
MON_GET_TABLESPACE table function can be used to query various table space
statistics. The column RECLAIMABLE_SPACE_ENABLED can checked for a value of
‘1', indicating the table space supports reclaiming space.
The sample query listed is:
select substr(TBSP_NAME,1,14) as TS_NAME ,
TBSP_TOTAL_PAGES as Total_pages,
TBSP_USED_PAGES as Used_pages ,
TBSP_PAGE_TOP as High_water_MARK ,
reclaimable_space_enabled
from table ( MON_GET_TABLESPACE ( NULL , -1 ) ) as ts
where TBSP_NAME NOT LIKE ('SYS%') and TBSP_TYPE = 'DMS'
This query lists all DMS table spaces and excludes the system table spaces. The report
shows the total number of pages allocated, the number of pages used, the current high
water mark and whether storage could be reclaimed. The report could be used to locate
any table spaces that show a high water mark that is much higher than the number of
pages currently in use.

Reclaimable storage: Monitoring the processing

• Reducing the table space size is an online operation:
 Application DML and DDL can run concurrently
 Online Backup operations can not be processing the extents being
moved
− Backup can wait while a group of extents are moved
• Extent movement progress can be monitored using the Table function

MON_GET_EXTENT_MOVEMENT_STATUS()
TBSP_NAME TBSP_ID .... NUM_EXTENTS_MOVED NUM_EXTENTS_LEFT TOTAL_MOVE_TIME

--------- ------- ----------------- ---------------- ---------------
USERSPACE1 2 -1 -1 -1
TS1 3 4000 2000 60000
Reclaimable storage: Monitoring the processing

Reducing the size of table spaces through extent movement is an online operation. In
other words, data manipulation language (DML) and data definition language (DDL)
can continue to be run while the reduce operation is taking place. Some operations,
such as a backup or restore cannot run concurrently with extent movement operations;
in these cases, the process requiring access to the extents being moved (for example,
backup) waits until a (non-user-configurable) number of extents have been moved, at
which point the backup process obtains a lock on the extents in question, and continues
from there.
You can monitor the progress of extent movement operation with an SQL statement
using the DB MON_GET_EXTENT_MOVEMENT_STATUS table function.

Table space extent allocation: Example 1

CREATE TABLESPACE DMSTS1
MANAGED BY DATABASE USING (FILE 'DMSCONT1' 1000,
FILE 'DMSCONT2' 1000)
DMST1
EXTENTSIZE 8 ;
DMSCONT1 DMSCONT2
Container 0 Container 1
1000 pages 1000 pages
As new extents are allocated

Db2 assigns lowest numbered free Container 0 Container 1
extent Extent 0 Extent 1
Extent 2 Extent 3
Data for objects is balanced across
Extent 4 Extent 5
the containers
Extent 6 Extent 7
................ ................
Extent 246 Extent 247
Table space extent allocation: Example 1

In a Db2 database, pages in a DMS table space are logically numbered from 0 to (N-1),
where N is the number of usable pages in the table space.
The pages in a DMS table space are grouped into extents, based on the extent size,
and from a table space management perspective, all object allocation is done on an
extent basis. That is, a table might use only half of the pages in an extent, but the whole
extent is considered to be in use and owned by that object. One extent is used to hold
the container tag, and the pages in this extent cannot be used to hold data.
Because space in containers is allocated by extent, pages that do not make up a full
extent will not be used. For example, if you have a 205-page container with an extent
size of 10, one extent will be used for the tag, 19 extents will be available for data, and
the five remaining pages are wasted.
If a DMS table space contains a single container, the conversion from logical page
number to physical location on disk is a straightforward process where pages 0, 1, 2,
will be located in that same order on disk.

It is also a fairly straightforward process in the case where there is more than one
container and each of the containers is the same size. The first extent in the table
space (containing pages 0 to (extent size - 1)) will be located in the first container, the
second extent will be located in the second container, and so on. After the last
container, the process repeats in a round-robin fashion, starting back at the first
container.
For table spaces containing containers of different sizes, Db2 can not use a simple
round-robin approach for the entire range of space because some containers can hold
more than others.
The example shows a table space created with the following DDL:
CREATE REGULAR TABLESPACE DMSTS1
MANAGED BY DATABASE USING (FILE 'DMSCONT1' 1000, FILE 'DMSCONT2' 1000)
EXTENTSIZE 8 ;
The two containers are the same size (1000 pages), so there is one range (range 0)
with all extents striped across both containers (numbered 0 and 1). Each stripe,
therefore, has two extents.
There are 2000 total pages, but two extents of 8 pages each were used by Db2 for the
container tags, so there are 1984 pages left (numbered 0 to 1983).
The 1984 pages are in 248 extents (numbered 0 to 247), so the Max Extent shown is
247.

Table space maps: ALTER TABLESPACE ADD example
ALTER TABLESPACE DMSTS1 ADD (FILE 'DMSCONT3' 1000);
DMSCONT1 DMSCONT2
DMSCONT1 DMSCONT2 DMSCONT3
Container 0 Container 1 Container 2
1000 pages 1000 pages 1000 pages
Container 0 Container 1 Container 0 Container 1 Container 2

Extent 0 Extent 1 Extent 0 Extent 1 Extent 2

................ ................ ................ ................ ................
• When a new container is added to a DMS managed tablespace using ADD Db2
will rebalance extents automatically
• Rebalance stops at the HWM for the tablespace
• REBALANCE performed asynchronous to ALTER processing
Table space maps: ALTER TABLESPACE ADD example

In this example, we start with the first example table space that had two containers of
1000 pages each. As the objects in that table space begin to grow, it might be
necessary to add additional space.
One option is to add a third container as follows:
ALTER TABLESPACE DMSTS1 ADD (FILE 'DMSCONT3' 1000);
When the new container is added, it becomes part of the current stripe set, so Db2 will
rebalance the extents so that data is evenly spread among the containers of the stripe
set. The visual shows that extent number 2 needed to be moved from container 0 to the
new container number 2. The Maximum Extent increased from 247 to 371, because the
new container added 124 new extents (992 pages after using one extent for the new
container's tag).
What's not apparent is the work that Db2 had to do to get from the first table space map
to the one shown here after the ALTER.
In order to get from the original table space map shown to the new table space map
shown that results from the ALTER TABLESPACE processing, Db2 uses a utility called
the Rebalancer which moves extents one by one to reach the target table space extent
mapping.

The addition of the new container using the ADD option for this current example means
that Db2 needs to rebalance the existing data stored in the first two containers so that
the data is evenly spread across all three containers.
This is done starting at the lowest numbered extents up to the point of the current High
Water Mark for the table space. In the visual, it shows that Extent 2 is moved from
Container 0 to Container 2. Next, Extent 3 is moved from Container 1 to Container 0.
This continues, extent by extent, until the rebalancer reaches the table space High
Water Mark. Empty extents above the High Water Mark do not need to be processed,
but empty extents below the High Water Mark are moved.
Applications can continue to access the data in this table space while the rebalancer is
running.

Monitoring the Rebalancer: LIST UTILITIES
db2 list utilities show detail

ID = 21
Type = REBALANCE
Database Name = MUSICDB
Member Number = 0
Description = Tablespace ID: 12
Start Time = 09/23/2013 11:01:54.027168
State = Executing
Invocation Type = User
Throttling:
Priority = Unthrottled
Progress Monitoring:
Estimated Percentage Complete = 0
Total Work = 397 extents
Completed Work = 0 extents
Start Time = 09/23/2013 11:01:54.027408
db2 SET UTIL_IMPACT_PRIORITY FOR 21 TO 20
Monitoring the Rebalancer: LIST UTILITIES

Even though the ALTER TABLESPACE command seems to complete quickly, the
rebalancer utility processing triggered might take a long time to complete and perform a
large number of I/Os.
The Db2 command, LIST UTILITIES, can be used to check on the progress of a
Rebalancer utility that is currently active in the database. You can also use the -utilities
option of the db2pd command.
This example in the visual shows that the Rebalancer utility has just started processing.
It has will move 397 extents that require rebalancing in the table space with a ID of 12.
Notice that the LIST UTILITIES output shows that the rebalancer is running unthrottled.
If the DBM configuration option, UTIL_IMPACT_LIM, is set to a value less than 100, the
SET UTIL_IMPACT_PRIORITY command could be used to throttle the rebalancer
processing to limit the impact on other applications.

Rebalancer: db2diag.log Status messages

2013-09-24-11.23.55.275889-240 E93263E451 LEVEL: Warning
PID : 31445 TID : 140165699856128 PROC : db2sysc 0
INSTANCE: inst461 NODE : 000 DB : MUSICDB
HOSTNAME: ibmclass
EDUID : 71 EDUNAME: db2rebal (MUSICDB) 0
FUNCTION: DB2 UDB, buffer pool services, sqlb_fwd_rebalance, probe:5514
MESSAGE : ADM6058I Rebalancer for table space "DMSMTSPD" (ID "11") was
started.
2013-09-24-11.23.57.476180-240 I93715E465 LEVEL: Info

HOSTNAME: ibmclass
FUNCTION: DB2 UDB, buffer pool services, sqlb_fwd_rebalance, probe:6735
DATA #1 : <preformatted>
Table Space ID 11: Last extent moved was #997 and number of extents moved was #996.
2013-09-24-11.23.57.479433-240 E94181E453 LEVEL: Warning

HOSTNAME: ibmclass
FUNCTION: DB2 UDB, buffer pool services, sqlb_rebalance, probe:8623
MESSAGE : ADM6062I Rebalance for table space "DMSMTSPD" (ID "11") has been
completed.
Rebalancer: db2diag.log Status messages

The LIST UTILITIES and db2pd -utilities commands can be used to get information
about an active Rebalancer utility.
Once the processing has completed, there are messages in the db2diag.log file that
show when each Rebalancer utility starts and completes and the number of extents
processed. This could be helpful information if there was a question about a system
performance problem that happened previously. You could check to see if there was a
table space being rebalanced at that time.
These are considered at the Warning level for messages.

Extent Allocations using ALTER NEW STRIPE SET
ALTER TABLESPACE DMSTS1 BEGIN NEW STRIPE SET (FILE 'DMSCONT3' 1000)
DMSCONT1 DMSCONT2
DMSCONT1 DMSCONT2
Container 0 Container 1 Stripe Set 0
Stripe Set 1
DMSCONT3
Container 2
1000 pages
Set Container 0 Container 1 Container 2

• Extent Rebalancing is
0 Extent 0 Extent 1
not necessary:
0 Extent 2 Extent 3
• No data will be stored 0 Extent 4 Extent 5
in the new container 0 ................ ................
until the first two 0 Extent 246 Extent 247
containers are 1 Extent 248
completely filled.
1 .................
1 Extent 371
Extent Allocations using ALTER NEW STRIPE SET

When added a new container with the ADD option, we made additional extents
available to the DMS table space, but the rebalancer processing can require a large
number of I/Os. The EXTEND and RESIZE options can be used to change the current
file containers to add extents without rebalancing, but there might not be enough free
space available in the current file systems to increase the current containers.
The BEGIN NEW STRIPE SET option for ALTER TABLESPACE can be used to add
new containers to a DMS table space and bypass the rebalancer processing. This
makes the new space available as quickly as possible.
In the example, there are two file containers each with 1000 pages.
If the following SQL is used:
ALTER TABLESPACE DMSTS1 BEGIN NEW STRIPE SET (FILE 'DMSCONT3' 1000)
This will add a new container with 1000 pages to the table space.
Notice that the original containers are considered to be Stripe Set 0, while the new
container (container 2) is the only container assigned to the new the Stripe Set 1.
This new stripe set begins with extent 248 up to The Max Extent 371. No data will be
stored in the new container until the first two containers are completely filled.

Moving a DMS managed tablespace to new containers

Online using ALTER TABLESPACE
• A DMS managed tablespace could be moved to new containers online
using ALTER TABLESPACE commands
• First use ALTER TABLESPACE to add containers with sufficient space

for to HWM of TS
 Use BEGIN NEW STRIPE SET to defer rebalancing work
ALTER TABLESPACE DMSTS1 BEGIN NEW STRIPE SET
(FILE 'DMSCONT3' 1000 , FILE 'DMSCONT4' 1000 )
• Next DROP original containers to complete the move

ALTER TABLESPACE DMSTS1 DROP (FILE 'DMSCONT1' , FILE 'DMSCONT2' )
Moving a DMS managed tablespace to new containers Online using ALTER

TABLESPACE
You could move a DMS tablespace to a new set of containers using a BACKUP and
RESTORE with the REDIRECT option but that would require the tablespace to be
offline during the RESTORE processing.
You can use ALTER TABLESPACE commands to move a DMS tablespace while it
remains online.
The first example command uses ALTER TABLESPACE with the BEGIN NEW
STRIPE SET option to allocate the new containers, but a rebalance operation is not
required at this point.
To complete the data movement, the ALTER TABLESPACE with the DROP option can
be used to remove the original containers. The REBALANCE utility will be invoked to
move the extents to available space in the new containers.

Example of Auto-growth stopping for DMS
How do you kick start

Auto-resize auto-growth again?
table space C0 C1 1.Make more room
C0 C1 available on the file
created with C0 C1
Table Table system holding C1
2 containers
space space 2.Extend C0 by some
grows grows amount
3.Add a new stripe set
(recommended if #1
not possible)
1) 2) Extending C0 results 3)
Adding the new
in a new range being
stripe set here
C0 C1 C0 C1 created that holds C0 C1
results in a new
only that one
range being created
container. Hence,
in the tables space
auto-resize will only
map. Hence, auto-
extend that one C2 C3 resize will only
container.
extend these new
containers from here on.
Example of Auto-growth stopping for DMS

DMS table spaces are made up of file containers or raw device containers, and their
sizes are set when the containers are assigned to the table space. The table space is
considered full when all of the space within the containers has been used. You can add
or extend containers using the ALTER TABLESPACE statement, allowing more
storage space to be given to the table space.
DMS table spaces also have a feature called autoresize. As space is consumed in a
DMS table space that can be automatically resized, Db2 can extend one or more file
containers.
To enable the AUTORESIZE feature specify the AUTORESIZE YES clause as part of
the CREATE TABLESPACE statement:
CREATE TABLESPACE DMS1 MANAGED BY DATABASE
USING (FILE '/db2files/DMS1' 10 M) AUTORESIZE YES
You can also enable or disable the AUTORESIZE feature after a DMS table space has
been created by using the AUTORESIZE clause on the ALTER TABLESPACE
statement:
ALTER TABLESPACE DMS1 AUTORESIZE YES
ALTER TABLESPACE DMS1 AUTORESIZE NO

Two other attributes, MAXSIZE and INCREASESIZE, are associated with autoresize
table spaces.
Maximum size (MAXSIZE)
The MAXSIZE clause on the CREATE TABLESPACE statement defines the maximum
size for the table space. For example, the following statement creates a table space
that can grow to 100 megabytes (per partition if the database has multiple partitions):
USING (FILE '/db2files/DMS1' 10 M)
AUTORESIZE YES MAXSIZE 100 M
The MAXSIZE NONE clause specifies that there is no maximum limit for the table
space. The table space can grow until a file system limit or Db2's table space limit has
been reached (see the SQL Limits section in the SQL Reference). No maximum limit is
the default if the MAXSIZE clause is not specified when the AUTORESIZE feature is
enabled.
The ALTER TABLESPACE statement changes the value of MAXSIZE for a table space
that has AUTORESIZE already enabled. For example:
ALTER TABLESPACE DMS1 MAXSIZE 1 G
ALTER TABLESPACE DMS1 MAXSIZE NONE
If a maximum size is specified, the actual value that Db2 enforces might be slightly
smaller than the value provided because Db2 attempts to keep container growth
consistent. It might not be possible to extend the containers by equal amounts and
reach the maximum size exactly.
Increase size (INCREASESIZE)
The INCREASESIZE clause on the CREATE TABLESPACE statement defines the
amount of space used to increase the table space when there are no free extents within
the table space, and a request for one or more extents has been made. The value can
be specified as an explicit size or as a percentage. For example:
AUTORESIZE YES INCREASESIZE 5 M

AUTORESIZE YES INCREASESIZE 50 PERCENT
A percentage value means that the increase size is calculated every time that the table
space needs to grow, and growth is based on a percentage of the table space size at
that time. For example, if the table space is 20 megabytes in size and the increase size
is 50 percent, the table space grows by 10 megabytes the first time (to a size of 30
megabytes) and by 15 megabytes the next time.

If the INCREASESIZE clause is not specified when the AUTORESIZE feature is

enabled, the database manager determines an appropriate value to use, which might
change over the life of the table space. Like AUTORESIZE and MAXSIZE, you can
change the value of INCREASESIZE using the ALTER TABLESPACE statement.
If a size increase is specified, the actual value used by Db2 might be slightly different
than the value provided. This adjustment in the value used is done to keep growth
consistent across the containers in the table space.
In this slide, the dashed boxes represent file systems and the amount of space they
have available to them. As growth occurs (and this growth occurs at the same rate for
C0 and C1, keeping them at the same size), the file system holding C1 becomes full. At
this point, the table space will no longer grow automatically.
Case #1: In this case, free space is being made on the file system holding C1. This can
occur by deleting non-Db2 files that might exist, or by extending the file system in size
(platform dependent). Since C0 and C1 are the containers in the last range of the table
space map and there is now free space on each of the file systems holding them, when
an AUTORESIZE operation is attempted, it will be successful.
Case #2: In this case, container C0 is being extended by some amount of space
(minimum would need to be one extent). In doing this, a new range is added to the
table space map and this range will only include container C0. Therefore, when an
AUTORESIZE operation is attempted next by Db2, it will only attempt to grow container
C0. Because there is free space available on that file system, the container extension
should succeed.
Case #3: In this case, the user is deciding that they want to maintain the same amount
of striping so they add two new containers to the table space using the BEGIN NEW
STRIPE SET option of ALTER TABLESPACE. The result of this is that new space is
added to the table space and the data that currently exists in the table space will *not*
be rebalanced onto the new containers. And, of course, a new stripe set (which in this
case is a single new range) is added to the table space map. So, when an
AUTORESIZE operation is next attempted, it will try to resize those containers that are
in the last range of the map, which happens to be C2 and C3 in this case.

Using Storage Groups for Automatic storage table spaces
Partitioned Table Sales
Partition 2012Q1 2011Q4 2011Q3 2011Q2 2011Q1 2010Q4 … 2006Q3
Automatic Table Space 14 Table Space 13 Table Space 12 Table Space 11 Table Space 10 Table Space 9 … Table Space 1
Storage …
Table Space
spath: spath: /warm/fs1 spath: /cold/fs1

/hot/fs1 spath: /warm/fs2 spath: /cold/fs2
Storage spath: /cold/fs3
SG_HOT SG_WARM
Group SG_COLD
Physical Disk
SSD RAID Array FC/SAS RAID Array SATA RAID Array
Using Storage Groups for Automatic storage table spaces

Storage groups provide an extra layer of abstraction between table spaces and disk
devices.
You can group table spaces sharing similar characteristics into same group of storage
paths.
After you create storage groups that map to the different classes of storage in your
database management system, you can assign automatic storage table spaces to
those storage groups, based on which table spaces have hot or cold data.
You can dynamically reassign a table space to a different storage group as the data
changes or your business direction changes.
• SSD = Solid State Drive
• FC = Fiber Channel
• SAS = Serial Attached SCSI
• SATA = Serial ATA


ADMIN_GET_STORAGE_PATHS
SELECT VARCHAR(STORAGE_GROUP_NAME,20) AS STORAGE_GROUP,

STORAGE_GROUP_ID,
VARCHAR(DB_STORAGE_PATH,20) AS STORAGE_PATH,
DB_STORAGE_PATH_STATE,
(FS_TOTAL_SIZE / 1000000) AS TOTAL_PATH_MB,
(STO_PATH_FREE_SIZE / 1000000) AS PATH_FREE_MB
FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T1
STORAGE_GROUP STORAGE_GROUP_ID STORAGE_PATH DB_STORAGE_PATH_STATE

-------------------- ---------------- -------------------- ---------------------
IBMSTOGROUP 0 /dbauto/path1 IN_USE
APP_DATA 1 /dbauto/path2 IN_USE
TOTAL_PATH_MB PATH_FREE_MB
-------------------- --------------------
20940 5649
20940 5649

ADMIN_GET_STORAGE_PATHS
The ADMIN_GET_STORAGE_PATHS table function returns a list of automatic storage
paths for each database storage group, including file system information for each
storage path.
Syntax
>>-ADMIN_GET_STORAGE_PATHS--(--storage_group_name--,--member--)-><
The schema is SYSPROC.
Table function parameters
storage_group_name - An input argument of type VARCHAR(128) that
specifies a valid storage group name in the currently connected database when
this function is called. If the argument is NULL or an empty string, information is
returned for all storage groups in the database. If the argument is specified,
information is only returned for the identified storage group.
member - An input argument of type INTEGER that specifies a valid member in
the same instance as the currently connected database when calling this
function. Specify -1 for the current database member, or -2 for all database
members. If the NULL value is specified, -1 is set implicitly.

Authorization
One of the following authorities is required to execute the routine:
• EXECUTE privilege on the routine
• DBADM authority
• SQLADM authority

Listing storage groups with the db2pd command

• db2pd –db testdb –storagegroups
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days 00:09:09 -- Date
03/23/2012 09:13:49
Storage Group Configuration:

Address SGID Default DataTag Name
0x8F241740 0 Yes 0 IBMSTOGROUP
0x8F240490 1 No 0 SG_HIGH
0x90C39640 2 No 0 SG_LOW
Storage Group Statistics:

Address SGID State Numpaths NumDropPen
0x8F241740 0 0x00000000 2 0
0x8F240490 1 0x00000000 2 0
0x90C39640 2 0x00000000 2 0
Storage Group Paths:

Address SGID PathID PathState PathName
0x8F241850 0 0 InUse /dbauto/path1
0x8F241BF0 0 1 InUse /dbauto/path2
0x94F6F210 1 1024 InUse /dbauto/path1/sg_high
0x94F6F510 1 1025 InUse /dbauto/path2/sg_high
0x90C39750 2 2048 InUse /dbauto/path1/sg_low
0x90C39AF0 2 2049 InUse /dbauto/path2/sg_low
Listing storage groups with the db2pd command

The sample report was generated using the -storagegroups option of the db2pd
command.
The report shows the current default storage group and the paths assigned to each
storage group.

Changing the storage group for an Automatic Storage table

space
• An ALTER TABLESPACE statement can be used to move a table
space data to a new storage group
ALTER TABLESPACE TbSpc USING sg_target
• When the ALTER TABLESPACE is committed an implicit

REBALANCE operation is used to move the extents to new containers
and free the original containers
1. New containers are allocated on the target storage group’s storage paths.
2. All original containers are marked drop pending and new allocation
requests are satisfied from the new containers
3. A reverse rebalance is preformed, moving data off of the containers on the
paths being dropped
4. The containers are physically dropped
Changing the storage group for an Automatic Storage table space

When the table space is moved to the new storage group, the containers in the old
storage group are marked as drop pending. After the ALTER TABLESPACE statement
is committed, containers are allocated on the new storage group’s storage paths, the
existing containers residing in the old storage groups are marked as drop pending, and
an implicit REBALANCE operation is initiated. This operation allocates containers on
the new storage path and rebalances the data from the existing containers into the new
containers. The number and size of the containers to create depend on both the
number of storage paths in the target storage group and on the amount of free space
on the new storage paths. The old containers are dropped, after all the data is moved.
Moving a table space to a new storage group includes the following steps:
1. New containers are allocated on the target storage group’s storage paths.
2. All original containers are marked drop pending and new allocation request are
satisfied from the new containers.
3. A reverse rebalance is preformed, moving data off of the containers on the
paths being dropped.
4. The containers are physically dropped.

Tablespace rebalance can be suspended using ALTER

TABLESPACE
• You can explicitly suspend a table space rebalance operation that is in
progress during performance-sensitive periods and resume at a later
time
 To suspend the rebalance operation, issue the ALTER TABLESPACE
statement with the REBALANCE SUSPEND clause
db2 alter tablespace ts02 rebalance suspend
 The rebalance operation in placed in a suspended state
 The suspended state is persistent and the rebalance operation is restarted
upon database activation.
 To resume the operation, issue the ALTER TABLESPACE statement with
the REBALANCE RESUME clause
 You can monitor rebalance operations in progress using the
MON_GET_REBALANCE_STATUS table function.
• The implicit rebalance started when a table space is altered to a new
storage group can also be suspended
Tablespace rebalance can be suspended using ALTER TABLESPACE

The ALTER TABLESPACE statement has a clause that allows you to explicitly
suspend a rebalance operation that is in progress during performance-sensitive periods
and resume at a later time.
To suspend the rebalance operation, issue the ALTER TABLESPACE statement with
the REBALANCE SUSPEND clause. This places the operation into suspended state.
To resume the operation, issue the ALTER TABLESPACE statement with the
REBALANCE RESUME clause.
The suspended state is persistent and the rebalance operation is restarted upon
database activation.
You can monitor rebalance operations in progress using the
MON_GET_REBALANCE_STATUS table function.

Monitoring extent movement for when the storage group is

altered for a table space
• The MON_GET_REBALANCE_STATUS function can be used to
monitor rebalance processing when a table space is move to a new
storage group
select varchar(tbsp_name,20) as tbsp_name,

rebalancer_mode, rebalancer_status, rebalancer_extents_remaining,
rebalancer_extents_processed,
varchar(rebalancer_target_storage_group_name,20) as target_group
from table(mon_get_rebalance_status(NULL,-2)) as T1
TBSP_NAME REBALANCER_MODE REBALANCER_STATUS

-------------------- ------------------------------ -----------------
CLPMTSP1 FWD_REBAL_OF_2PASS ACTIVE
REBALANCER_EXTENTS_REMAINING REBALANCER_EXTENTS_PROCESSED TARGET_GROUP

---------------------------- ---------------------------- --------------------
741 41 SG_HIGH
Monitoring extent movement for when the storage group is altered for a table space
You can use the MON_GET_REBALANCE_STATUS table function to monitor the
progress of rebalance operations on a database.
This procedure returns data for a table space only if a rebalance operation is in
progress. Otherwise, no data is returned.
To monitor a table space rebalance operation:
Issue the MON_GET_REBALANCE_STATUS table function with the tbsp_name and
dbpartitionnum parameters:
SELECT
VARCHAR(TBSP_NAME, 30) AS TBSP_NAME,
DBPARTITIONNUM,
MEMBER,
REBALANCER_MODE,
REBALANCER_STATUS,
REBALANCER_EXTENTS_REMAINING,
REBALANCER_EXTENTS_PROCESSED,
REBALANCER_START_TIME
FROM TABLE(MON_GET_REBALANCE_STATUS(NULL,-2)) AS TRESULTS

Table space growth with Automatic Storage

Two storage paths The third storage To continue growing,
and a table space has path is not used by the table space must
a container on each the table space yet add a new stripe set
C0 C1 C0 C1 C0 C1
Third storage TS grows until New stripe set
path is added C0 can't grow added automatically
Only now is the To continue growing, C4 will grow as the

recently added storage the table space must table space grows
path utilized add a new stripe set from here on
C0 C1 C0 C1 C0 C1
TS grows until New stripe set
C2 C3 C2 can't grow C2 C3 added automatically C2 C3 Note: For
C4 simplicity, we're
just showing one
table space within
the database
Table space growth with Automatic Storage

This slide is intended to show how AUTORESIZE occurs in an Automatic storage-
managed table spaces. Like the AUTORESIZE behavior described earlier in this
presentation, containers in the last range of the table space map extend when an
AUTORESIZE operation is needed. However, once one of those containers cannot be
grown any further (usually due to a file system full error, but could also be the result of a
file system limitation (for example, there is a maximum container size) or a low ulimit
setting), the Storage Manager component within Db2 is queried for a new list of
containers to create. At this point, all of the storage paths are taken into consideration,
including recently added ones.

Automatic Storage Rebalance to use newly added storage

paths
ALTER TABLESPACE myts REBALANCE
High Water Mark
Two storage paths One New storage paths REBALANCE causes Db2 If table space is not growing
table space has a not used by the to create equal-sized rapidly, consider REDUCing
container on each path table space containers in new paths, it to make space available
immediately and redistribute extents to for other table spaces
them
p1 p2 p1 p2 p3 p4 p1 p2 p3 p4 p1 p2 p3 p4
C0 C1 C2 C3
C0 C1 C0 C1 C0 C1 C2 C3
ALTER TABLESPACE ...

ALTER STOGROUP… ALTER TABLESPACE ...
REDUCE
ADD ‘p3’,’ p4’ REBALANCE
(optional)
High Water Mark
The REBALANCE option can be used to cause Db2 to utilize new

storage paths for a specific table space to increase I/O parallelism
Automatic Storage Rebalance to use newly added storage paths

The slide shows how a database administrator could add new Automatic Storage paths
and direct Db2 to use utilize the additional storage.
1. An Automatic Storage table space, TS1 is created in a STOGROUP with two
balanced storage paths (p1 and p2). The table space is assigned two equal
sized containers (C0 and C1), one on each path.
2. Planning for growth, a database administrator might add two more Automatic
Storage paths to the STOGROUP (p3 and p4). The containers for the TS1 table
space would not be automatically effected by the new storage paths.
3. If the DBA decides that the table space TS1 would benefit from using the new
storage paths, the ALTER TABLESPACE TS1 REBALANCE statement would
cause Db2 to allocate two new containers (C2 and C3) on the new paths. The
size of the new containers would be equal to the size of the original containers.
Db2 would automatically rebalance the extents so that the data would be evenly
spread over all four storage paths. Having all four containers of an equal size
would allow the table space to continue to grow in a balanced manner.
4. If the table space TS1 is not expected to need the newly added space soon, an
ALTER TABLESPACE REDUCE function can be used to release either a
portion or all unused space.

Dropping storage paths: Example
p1 p2 p3 p1 p2 p3 p1 p3
ALTER TABLESPACE
TS1 TS1 REBALANCE TS1
C1 C2 C3 C1 C2 C3
C1 C3
C1 C2 C3 TS2 C1 C2 C3
ALTER TABLESPACE
TS2 REBALANCE
C1 C3 TS2
ALTER STOGROUP…
DROP ‘p2’
Drop Pending
Dropping storage paths: Example

The DROP option for the ALTER STOGROUP command specifies that one or more
storage paths are to be removed from the collection of storage paths defined for a
storage group. If table spaces are actively using a storage path being dropped, then the
state of the storage path is changed from "In Use" to "Drop Pending” and future use of
the storage path will be prevented.
Before the operation of dropping a storage path can be completed, any table space
containers on that path must be removed. If an entire table space is no longer needed,
you can drop it before dropping the storage path from the database. In this situation, no
rebalance is required. If, however, you want to keep the table space, a REBALANCE
operation is required. In this case, when there are storage paths in the "drop pending"
state, the database manager performs a reverse rebalance, where movement of
extents starts from the high water mark extent (the last possible extent containing data
in the table space), and ends with extent 0.

When the REBALANCE operation is run, the following takes place:

• A reverse rebalance is performed. Data in any containers in the "drop
pending" state is moved into the remaining containers.
• The containers in the drop pending state are dropped.
• If this is the last table space using the storage path, then the storage path is
dropped as well.
• If the containers on the remaining storage paths are not large enough to hold
all of the data being moved, the database manager might have to first create
or extend containers on the remaining storage paths before performing the
rebalance.

Converting a DMS table space to use Automatic Storage

• ALTER TABLESPACE can be used to convert a DMS table space to
an Automatic Storage table space without an outage:
 ALTER TABLESPACE … MANAGED BY AUTOMATIC STORAGE
 All new growth comes from the Automatic Storage paths
 Old (file or raw) containers can be removed using ALTER TABLESPACE
REBALANCE
• A REDIRECTED RESTORE can be used to convert DMS table spaces
to AUTOMATIC STORAGE table spaces
 SET TABLESPACE CONTAINERS … USING AUTOMATIC STORAGE

You can convert some or all of your database-managed space (DMS) table spaces in a
database to use Automatic Storage. Using Automatic Storage simplifies your storage
management tasks.
To convert a DMS table space to use Automatic Storage, use one of the following
methods:
• Alter a single table space. This method keeps the table space online but
involves a rebalance operation that takes time to move data from the non-
Automatic Storage containers to the new Automatic Storage containers.
• Issue the ALTER TABLESPACE statement, specifying the MANAGED BY
AUTOMATIC STORAGE clause for the table space that you want to convert.
New containers are added, but no extent movement is performed by this
operation.

• Issue the ALTER TABLESPACE statement again, this time specifying the
REBALANCE option. This option removes the original user-defined containers
so that all table space containers are managed by Automatic Storage. If you
do not specify the REBALANCE option now and issue the ALTER
TABLESPACE statement later with the REDUCE option, your Automatic
Storage containers will be removed. To recover from this problem, issue the
ALTER TABLESPACE statement, specifying the REBALANCE option.
• Use a redirected restore operation. If you are converting a single table space
with this method, you cannot access the table space while the operation is in
progress. If you are converting multiple table spaces, you cannot access the
entire database while the operation is in progress.
• Run the RESTORE DATABASE command, specifying the REDIRECT
parameter. If you want to convert a single table space, also specify the
TABLESPACE parameter:
RESTORE DATABASE database_name TABLESPACE table_space_name
REDIRECT
• Run the SET TABLESPACE CONTAINERS command, specifying the USING
AUTOMATIC STORAGE parameter, for each table space that you want to
convert:
SET TABLESPACE CONTAINERS FOR tablespace_id USING AUTOMATIC
STORAGE
• Run the RESTORE DATABASE command again, this time specifying the
CONTINUE parameter:
RESTORE DATABASE database_name CONTINUE
• Run the ROLLFORWARD DATABASE command, specifying the TO END
OF LOGS and AND STOP parameters: ROLLFORWARD DATABASE
database_name TO END OF LOGS AND STOP

Example converting a DMS managed tablespace to use

Automatic storage
• Use ALTER tablespace to convert management type
 A storage group could be specified
 Db2 will assign containers with sufficient space but will defer data
movement
 Original containers are still allocated and in use
alter tablespace dmsmtspd using stogroup sg1

managed by automatic storage
• Use ALTER tablespace rebalance to complete movement

 REBALANCE moves the extents to the AS based containers
 Original containers removed when rebalance completes
alter tablespace dmsmtspd rebalance
• Use ALTER tablespace REDUCE as needed to release unused space

Example converting a DMS managed tablespace to use Automatic storage

The ALTER TABLESPACE statement with the MANAGED BY AUTOMATIC
STORAGE option will convert the DMS table space into an Automatic Storage-
managed table space, by assigning new containers from the Automatic Storage paths.
The example ALTER command includes the USE STOGROUP option to select a
specific storage group.
When the ALTER completes, the originally assigned containers for the DMS table
space are not effected and no rebalancing of extents is needed.
The ALTER TABLESPACE command with the REBALANCE option triggers Db2 to
move the extents from the original containers in order to free the containers to be
removed.
You may also decide to use the ALTER TABLESPACE REDUCE command to release
unused space from the tablespace and make it available for other tablespaces using
the same storage paths.

Demonstration 1
• Db2 Tablespace Management
• Monitor the process of the DB2 rebalancer utility using the LIST UTILITIES command
• Enable the AUTORESIZE option for a DMS table space to grow the table space size based
on application demand
• Use SQL table functions to monitor tablespace space utilization
• Implement storage groups for automatic storage tablespaces and move a tablespace
between storage groups without losing access to the tables
• Compare management of DMS managed and Automatic storage managed tablespaces
• Use the ALTER TABLESPACE option BEGIN NEW STRIPE SET to add space to a DMS
table space without rebalancing the existing data extents
• Convert a DMS managed table space to utilize automatic storage management
• Use ALTER tablespace commands to reduce unused space in DMS and Automatic Storage
managed tablespaces.
• Adjust the space allocation for a DMS table space using the DROP and RESIZE options of
ALTER TABLESPACE

Demonstration 1
Db2 Tablespace Management
This demonstration allows you to manage the disk space allocated for tables
in a DMS managed and Automatic Storage managed table spaces.
Task 1. Setup new storage groups for Automatic Storage and

create DMS and Automatic Storage managed table
spaces.
You will compare the management of DMS managed tablespaces to Automatic Storage
managed tablespaces. You will create two new storage groups named SG1 and SG2,
so that we can see how a tablespace can be easily moved from one storage group to
another. You will also convert a DMS managed tablespace to utilize automatic storage
management. These advanced demonstrations are performed using command line
Linux and Db2 commands.
ibm2blue.
You will use the following files with SQL statements to create the storage
groups.
• stogroup1.ddl
create stogroup sg1
on '/home/inst464/dmsts/sg1path1',
'/home/inst464/dmsts/sg1path2' ;
• stogroup2.ddl
create stogroup sg2
on '/home/inst464/dmsts/sg2path1';
• db2start
• cd $HOME/dmsts
• db2 -tvf stogroup1.ddl
• db2 -tvf stogroup2.ddl

4. Use a db2pd command to list the storage groups, including the system default
storage group.
• db2pd -db tp1-storage
Database Member 0 -- Database TP1 -- Active -- Up 0 days 00:03:07 -- Date 2018-03-
08-09.19.09.574455
Storage Group Configuration:

Address SGID Default DataTag Name
0x00007F87DBE43820 0 Yes 0 IBMSTOGROUP
0x00007F87DBE43940 1 No 0 TP1SG1
0x00007F87F3E93000 2 No 0 SG1
0x00007F87F3E94000 3 No 0 SG2
Storage Group Statistics:

Address SGID State Numpaths NumDropPen
0x00007F87DBE43820 0 0x00000000 1 0
0x00007F87DBE43940 1 0x00000000 1 0
0x00007F87F3E93000 2 0x00000000 2 0
0x00007F87F3E94000 3 0x00000000 1 0
Storage Group Paths:

Address SGID PathID PathState PathName
0x00007F87DBE67000 0 0 InUse /dbauto/path1
0x00007F87DBE89000 1 1024 InUse /dbauto/path2
0x00007F87F3E96000 2 2048 NotInUse /home/inst464/dmsts/sg1path1
0x00007F87F3EEB000 2 2049 NotInUse /home/inst464/dmsts/sg1path2
0x00007F87F3E95000 3 3072 NotInUse /home/inst464/dmsts/sg2path1
First, you will create the DMS managed tablespace named DMSMTSPD, and
create two new tables DMSM.HIST1 and DMSM.HIST2 with indexes.
You will use the file dmstables.ddl to create the database objects.
dmstables.ddl
-- Create New DMS tablespace FOR DMS MANAGEMENT
CREATE REGULAR TABLESPACE DMSMTSPD

MANAGED BY DATABASE USING (FILE 'DMSCONT1' 4000, FILE 'DMSCONT2'
4000)
EXTENTSIZE 8 PREFETCHSIZE AUTOMATIC NO FILE SYSTEM CACHING ;
CREATE TABLE DMSM.HIST1



IN DMSMTSPD ;
CREATE INDEX DMSM.HIST1IX1 ON DMSM.HIST1 (ACCT_ID) ;

CREATE INDEX DMSM.HIST1IX2 ON DMSM.HIST1 (BRANCH_ID,TELLER_ID) ;
CREATE TABLE DMSM.HIST2

IN DMSMTSPD ;
CREATE INDEX DMSM.HIST2IX1 ON DMSM.HIST2 (ACCT_ID) CLUSTER ;
5. In the terminal session, issue the following command:

• db2 -tvf dmstables.ddl
Next you will create an automatic storage managed tablespace named
ASMTSPD, and create two new tables ASM.HIST1 and ASM.HIST2 with
indexes.
You will use the file asmtables.ddl to create the database objects.
asmtables.ddl
-- Create New Auto Storage tablespace and tables
CREATE REGULAR TABLESPACE ASMTSPD USING STOGROUP SG1

INITIALSIZE 20M INCREASESIZE 10 PERCENT
EXTENTSIZE 8 ;
CREATE TABLE ASM.HIST1



IN ASMTSPD ;
CREATE INDEX ASM.HIST1IX1 ON ASM.HIST1 (ACCT_ID) ;

CREATE INDEX ASM.HIST1IX2 ON ASM.HIST1 (BRANCH_ID,TELLER_ID) ;
CREATE TABLE ASM.HIST2

IN ASMTSPD ;
CREATE INDEX ASM.HIST2IX1 ON ASM.HIST2 (ACCT_ID) CLUSTER ;
• db2 -tvf asmtables.ddl
Use the SQL query in the file mon_cont1 to list the container information and
space utilization for the two new tablespaces.
• db2 -tvf mon_cont1.sql
select varchar(TBSP_NAME,20) As TBSP_NAME, container_id, stripe_set ,
container_type, total_pages, usable_pages, varchar(container_name,90) as
CONTAINER_NAME from table(mon_get_container(NULL,-1)) AS cont where TBSP_NAME IN
('DMSMTSPD','ASMTSPD') order by TBSP_NAME,container_id
TBSP_NAME CONTAINER_ID STRIPE_SET CONTAINER_TYPE

TOTAL_PAGES USABLE_PAGES CONTAINER_NAME
-------------------- -------------------- -------------------- ---------------- --
------------------ -------------------- ------------------------------------------
------------------------------------------------
ASMTSPD 0 0 FILE_EXTENT_TAG
2560 2552
/home/inst464/dmsts/sg1path1/inst464/NODE0000/TP1/T0000009/C0000000.USR
2560 2552
DMSMTSPD 0 0 FILE_EXTENT_TAG
4000 3992 /database/inst464/NODE0000/SQL00001/DMSCONT1

select varchar(TBSP_NAME,20) As TBSP_NAME, TBSP_TOTAL_PAGES as Total_pages,

TBSP_USED_PAGES as Used_pages , (100 * TBSP_USED_PAGES / TBSP_TOTAL_PAGES ) as
PCT_USED, TBSP_PAGE_TOP as High_water_MARK, (100 * TBSP_PAGE_TOP /
TBSP_TOTAL_PAGES ) as PCT_HWM from table (mon_get_tablespace(NULL,-1)) AS TBSP
where TBSP_NAME IN ('DMSMTSPD','ASMTSPD') order by TBSP_NAME
TBSP_NAME TOTAL_PAGES USED_PAGES PCT_USED

HIGH_WATER_MARK PCT_HWM
-------------------- -------------------- -------------------- -------------------
- -------------------- --------------------
ASMTSPD 5120 88
1 88 1
DMSMTSPD 8000 88
1 88 1
Use the LOAD utility to load data into the two tables, DMSM.HIST1 and
DMSM.HIST2 in the DMS managed tablespace and the tables ASM.HIST1 and
ASM.HIST2 in the automatic storage managed tablespace. Query the space
consumed by loading the tables using the query file mon_space.sql.
8. In the terminal session, issue the following commands:
• db2 -tvf dmsloads.ddl
• db2 -tvf asmloads.ddl
• db2 -tvf mon_space.sql
container_type, total_pages, usable_pages from table(mon_get_container(NULL,-1))
AS cont where TBSP_NAME IN ('DMSMTSPD','ASMTSPD') order by TBSP_NAME,container_id
TBSP_NAME CONTAINER_ID STRIPE_SET CONTAINER_TYPE TOTAL_PAGES

USABLE_PAGES
---------- -------------------- -------------------- ---------------- ------------
-------- --------------------
3736 3728
3736 3728
4000 3992
4000 3992



-------------------- -------------------- -------------------- -------------------
- -------------------- --------------------
ASMTSPD 7472 7240
96 7240 96
DMSMTSPD 8000 7240
90 7240 90
Notice that the automatic storage tablespace, ASMTSPD has automatically
increased in size to 7472 pages from 5120 pages.
The DMS tablespace, DMSMTSPD was not defined with AUTORESIZE
enabled, but the initial allocation was large enough to hold the data loaded.
You will use the ALTER STOGROUP command to add a third path to the first
storage group named SG1. As the tablespace ASMTSPD grows, this new path
will not be used unless space on the current paths is unavailable. This avoids
the need to rebalance extents. Use the command in the file altergroup1.ddl to
add the new path.
altergroup1.ddl
alter stogroup sg1
add '/home/inst464/dmsts/sg1path3' ;

• db2 -tvf altergroup1.ddl
The command file load3.ddl loads additional data into two tables, dmsm.hist2
and asm.hist2, in each of the tablespaces.
The load processing in the DMS managed tablespace will consume all of the
remaining allocated space and fail to complete. The load processing in the
automatic storage tablespace will complete normally.


• db2 -tvf load3.ddl
load from savehist.del of del modified by pagefreespace=20 rowcount 50000 messages
asmload3.msg insert into asm.hist2 nonrecoverable

SQL3107W At least one warning message was encountered during LOAD processing.
load from savehist.del of del modified by pagefreespace=20 rowcount 50000 messages

dmsload3.msg insert into dmsm.hist2 nonrecoverable
SQL0289N Unable to allocate new pages in table space "DMSMTSPD".
SQLSTATE=57011
SQL2980I The ingest utility completed successfully at timestamp "05/07/2014

10:45:42.530405"
The load for dmsm.hist2 fails to complete, with a SQL0289N message

indicating, DB2 was not able to allocate the required pages in the table space.
Use the SQL in the file mon_tsfree.sql to show the current table space
utilization.
• db2 -tvf mon_tsfree.sql

-------------------- -------------------- -------------------- -------------------
- -------------------- --------------------
ASMTSPD 9024 8432
93 8432 93
DMSMTSPD 8000 7984
99 7984 99

The tablespace ASMTSPD has increased in size to hold the additional data.
The tablespace DMSMTSPD is not enabled for AUTORESIZE so the load
processing could not complete.
The load processing can be restarted once the space allocation problem is
addressed.
You could just enable AUTORESIZE for the tablespace DMSMTSPD, but we
will first add a new container to manually increase the allocated space.
Use the Db2 command in the file dmsalter1.ddl to add a new container to the
DMSMTSPD tablespace. The container is the same size as the original
containers, so the total allocation is increased by 50 percent. The file also
includes the LIST UTILITIES command that can be used to show the rebalance
operation that is triggered by the addition of the new container.
• db2 -tvf dmsalter1.ddl
alter tablespace dmsmtspd add (file 'DMSCONT3' 4000)
list utilities show detail
ID = 78
Type = REBALANCE
Database Name = TP1
Member Number = 0
Start Time = 03/08/2018 12:16:48.917673
State = Executing
Throttling:
Start Time = 03/08/2018 12:16:48.917689
The LIST UTILITIES command sample output shows 998 extents, each with 8
pages, or 7984 pages need to be moved. This is the number of currently used
pages in the tablespace.

It is possible that in your test, the LIST UTILITIES starts before the
REBALANCE begins processing. You can run the command ‘db2 list utilities
show detail’ manually.
You will enable AUTORESIZE for the tablespace DMSMTSPD to handle
additional growth requirements automatically.
• db2 alter tablespace dmsmtspd autoresize yes
You can restart the failed load by running the command file dmsload4.ddl,
which includes the RESTART option of the LOAD utility to complete the
previously started load utility.
utilization.
• db2 -tvf dmsload4.ddl

-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 9024 8432
93 8432 93
DMSMTSPD 12000 8432
70 8432 70
The tablespace DMSMTSPD was able to handle the load processing with the
addition of the third container and is currently 70 percent utilized.
The rebalancer process triggered by adding a new container can generate a
large number of disk I/Os during its processing. If additional space is needed as
soon as possible, and the overhead of rebalancing needs to be avoided, a new
container can be added using the BEGIN NEW STRIPE SET option.
Use the Db2 command in the file dmsalter2.ddl to add a fourth container as a
new stripe set to avoid the rebalance processing.


Previously a third path was added to the storage group SG1 that the tablespace
ASMTSPD uses.
You can use the ALTER TABLESPACE REBALANCE operation to cause Db2
to balance the current storage containers for a tablespace across the available
paths. The file asm_rebalance.ddl contains the REBALANCE option for the
ASMTSPD tablespace and a LIST UTILITIES command to monitor the
rebalance processing.
• db2 -tvf asm_rebalance.ddl
alter tablespace asmtspd rebalance
ID = 80
Type = REBALANCE
Database Name = TP1
Member Number = 0
Start Time = 03/08/2018 12:35:59.863092
State = Executing
Throttling:
Start Time = 03/08/2018 12:35:59.863105
The LIST UTILITIES output shows 1054 extents, all 8,432 pages will be moved.
Use the SQL query in the file mon_cont1.sql to show the current containers and
space allocations.


stripe_set , container_type, total_pages, usable_pages,
varchar(container_name,90) as CONTAINER_NAME from
table(mon_get_container(NULL,-1)) AS cont where TBSP_NAME IN
('DMSMTSPD','ASMTSPD') order by TBSP_NAME,container_id

-------------------- -------------------- -------------------- ----------------
-------------------- -------------------- -------------------------------------
-----------------------------------------------------
4512 4504
4512 4504
4512 4504


-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 8432
62 8432 62
DMSMTSPD 14000 8432
60 8432 60

The tablespace ASMTSPD was assigned a third container with a size equal to
the other two containers, so it is now about 60 percent utilized.
You could use ALTER TABLESPACE REDUCE to free some extra disk space,
but leave the space allocated for now, in order to provide space for planned
table reorganizations.
If a REORG utility is run offline and no temporary table space is requested, the
reorganization will allocate additional pages from the table's table space.
Use the Db2 command file reorgs.ddl to reorganize two tables DMSM.HIST1
and ASM.HIST1.
utilization.
• db2 -tvf reorgs.ddl

-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 7816
57 10904 80
DMSMTSPD 14000 7816
55 10904 77
Running the REORG utilities decreased the number of used pages because the
tables were loaded with extra free space. The table space high water marks are
now much higher because new, higher numbered extents were allocated during
the REORG.
Drop two of the tables, DMSM.HIST2 and ASM.HIST2 using the statements in
the file droptables.ddl, and check the status of the table space using
mon_tsfree.sql command file.


• db2 -tvf droptables.ddl

-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 3176
23 10904 80
DMSMTSPD 14000 3176
22 10904 77
Dropping the two tables decreased the number of used pages in each of the
tablespaces.
The table space high water marks did not change because the highest allocated
extent is still used by another object in the table space.
Having the high water mark for these tablespaces is not always a matter of
concern. If you plan to use the free space for expanding existing objects or
adding new objects you do not need to do anything.
If you need to reclaim the space and reduce the size of the tablespace
containers, then the position of the high water marks does need to be
considered.
Task 2. Lowering the table space high water mark.
Remove two of the two containers that were previously allocated to the
tablespace DMSMTSPD, using the ALTER TABLESPACE DROP command.
The file dmsalter3.ddl contains the statement to drop two of the containers.
1. In the Linux terminal session, issue the commands:
alter tablespace dmsmtspd drop (file 'DMSCONT2', file 'DMSCONT3')
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL20170N There is not enough space in the table space "DMSMTSPD" for the

specified action. Reason code = "1". SQLSTATE=57059

SQL1611W No data was returned by Database System Monitor. SQLSTATE=00000
The current high water mark for the table space will not allow both containers to
be dropped.
You can use the LOWER HIGH WATER MARK option of the ALTER
TABLESPACE command to reduce the high water mark for the DMSMTSPD
table space. Use the dmsalter4.ddl command file to lower the high water mark
for the DMS tablespace and check the status of the table space using
mon_tsfree.sql command file.

-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 3176
23 10904 80
DMSMTSPD 14000 3176
22 3256 23
The ALTER TABLESPACE has reduced the High Water Mark for the
DMSMTSP table space by allocating lower numbered free extents and
releasing the higher numbered extents.
Now the ALTER TABLESPACE command that removes the two containers that
were previously added can be tried again. Use the file dmsalter3.ddl to drop the
containers and issue the LIST UTILITIES to monitor the rebalancer processing.


alter tablespace dmsmtspd drop (file 'DMSCONT2', file 'DMSCONT3')
ID = 83
Type = REBALANCE
Database Name = TP1
Member Number = 0
Start Time = 03/08/2018 13:47:35.387924
State = Executing
Throttling:
Start Time = 03/08/2018 13:47:35.387938
Check the tablespace containers using the SQL file mon_cont1.sql.

CONTAINER_NAME from table(mon_get_container(NULL,-1)) AS cont where TBSP_NAME
IN ('DMSMTSPD','ASMTSPD') order by TBSP_NAME,container_id

-------------------- -------------------- -------------------- ----------------
-------------------- -------------------- -------------------------------------
-----------------------------------------------------
4512 4504
4512 4504

4512 4504


-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 3176
23 10904 80
DMSMTSPD 6000 3176
52 3256 54
The DMSMTSPD tablespace now has two remaining containers, in two stripe
sets.
The DMSMTSPD table space status shows that almost 50% of the remaining
pages are free and the high water mark is not an issue.

Task 3. Convert the DMS managed tablespace to use

automatic storage management.
You can use the ALTER TABLESPACE command to convert the DMS managed
tablespace to use automatic storage management. This involves getting storage
containers from an automatic storage STOGROUP and releasing the manually
assigned containers. The first step is to have new automatic storage containers
allocated. The file dmsalter5.ddl contains the ALTER TABLESPACE command to
convert the management type to automatic storage, using the STOGROUP SG1 for
containers.
alter tablespace dmsmtspd using stogroup sg1 managed by automatic storage

Use the SQL query in mon_cont1.sql to show the containers assigned.
• db2 -tf mon_cont1.sql
CONTAINER_NAME from table(mon_get_container(NULL,-1)) AS cont where TBSP_NAME
IN ('DMSMTSPD','ASMTSPD') order by TBSP_NAME,container_id

-------------------- -------------------- -------------------- ----------------
-------------------- -------------------- -------------------------------------
-----------------------------------------------------
4512 4504
4512 4504
4512 4504

2728 2720
2728 2720
2728 2720


-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 13536 3176
23 10904 80
DMSMTSPD 14184 3176
22 3256 22
The DMSMTSPD tablespace now has five containers in three stripe sets. The
original two containers are still allocated, and three new containers have been
added, one for each path of the storage group SG1.
Next you will use the ALTER TABLESPACE REBALANCE command to release
the original DMS containers. The file dmsalter6.ddl contains the ALTER
TABLESPACE REBALANCE command and a LIST UTILITIES command to
show the rebalance processing that is triggered.
alter tablespace dmsmtspd rebalance
ID = 84
Type = REBALANCE

Database Name = TP1

Member Number = 0
Start Time = 03/12/2018 07:42:28.131673
State = Executing
Throttling:
Start Time = 03/12/2018 07:42:28.131703
This rebalance will move 407 extents, which covers the current high water mark
of 3176 pages.
Task 4. Move an automatic storage table space to a new
storage group.
You can use the ALTER TABLESPACE command to move an automatic storage
tablespace to a different storage group. This involves getting storage containers from
the new automatic storage STOGROUP and releasing the containers from the original
storage group. The first step is to have new automatic storage containers allocated. The
file asalter1.ddl contains the ALTER TABLESPACE command to assign the new
storage group, SG2 to the tablespace ASMTSPD.
• db2 -tvf asalter1.ddl
alter tablespace asmtspd using stogroup sg2
ID = 85
Type = REBALANCE
Database Name = TP1
Member Number = 0
Start Time = 03/12/2018 07:50:05.334760
State = Executing
Throttling:


Start Time = 03/12/2018 07:50:05.334773
This rebalance will move 2726 extents. Use the SQL query in mon_cont1.sql to
show the containers assigned.
-------------------- -------------------- -------------------- ----------------
-------------------- -------------------- -------------------------------------
-----------------------------------------------------
10912 10904
2728 2720
2728 2720
2728 2720

-------------------- -------------------- -------------------- ----------------
---- -------------------- --------------------
ASMTSPD 10912 3176
29 10904 99
DMSMTSPD 8184 3176
38 3256 39

The ASMTSPD tablespace now has one container, since the new storage
group, SG2 has only one path defined. This ALTER command assigned the
new container and released the containers from the original storage group.
No manual REBALANCE is required, but the high water mark has not changed,
so the allocation exceeds the current space required which is about 30 percent
of the allocated space.
Next you will use the ALTER TABLESPACE REDUCE MAX command to
release all unused space from the tablespace ASMTSPD. The file asalter2.ddl
contains the ALTER TABLESPACE command and a LIST UTILITIES command
to show if a rebalance is triggered.
• db2 -tvf asalter2.ddl
alter tablespace asmtspd reduce max

Use the SQL query in mon_cont1.sql to show the containers assigned and
tablespace usage statistics.
-------------------- -------------------- -------------------- ---------------- --
------------------ -------------------- ------------------------------------------
------------------------------------------------
3264 3256
2728 2720
2728 2720
2728 2720


-------------------- -------------------- -------------------- -------------------
- -------------------- --------------------
ASMTSPD 3264 3176
97 3256 99
DMSMTSPD 8184 3176
38 3256 39
The ASMTSPD tablespace now has one container that is just large enough to
hold the currently used space, and is 99 percent full, but since AUTORESIZE is
enabled, the tablespace can grow easily to handle increased storage
requirements.
Drop the table spaces DMSMTSPD and ASMTSPD and the STOGROUPs SG1
and SG2 using the command file dmsend.ddl.

• db2 -tvf dmsend.ddl
• db2 terminate
Results:
You performed series of ALTER TABELSPACE commands to manage both
DMS managed and Automatic Storage managed tablespaces. You monitored
the utilization of tablespace storage to improve storage efficiency.

Unit summary
• Monitor tablespace space allocations using SQL with
MON_GET_TABLESPACE and MON_GET_CONTAINERS functions
• ALTER a table space to handle High Water Mark related issues and
reclaim unused space from DMS and Automatic Storage table spaces
• Use the REBALANCE option to control container allocations for
Automatic Storage table spaces when changing storage paths
• Monitor the processing done by the Rebalancer using LIST UTILITIES
and db2pd commands
• Plan and implement changes to disk space allocations using ALTER
TABLESPACE options: ADD, EXTEND, RESIZE, DROP, and BEGIN
NEW STRIPE SET
• Convert a DMS-managed table space to use Automatic Storage
• Move a Tablespace from one storage group to another
Unit summary

Db2 Database Memory Management
Db2 Database Memory

Management

Unit 3 Db2 Database Memory Management

Unit objectives
• Describe memory heap usage for instance memory, database shared
memory and application memory
• Explain the management of database shared memory based on setting
the configuration option DATABASE_MEMORY to AUTOMATIC or a
specific number of pages
• Select the mode for managing data sort memory using SORTHEAP,
and SHEAPTHRES_SHR
• Monitor Db2 memory usage using the db2mtrk commands and SQL
statements
• Utilize the db2pd command for monitoring current database memory
usage
• Describe how STMM can be used to automatically manage database
shared memory heaps
• Implement Db2 Self Tuning Memory Management (STMM) for all or
selected database memory heaps
Db2 Database Memory Management © Copyright IBM Corporation 2018
Unit objectives

Db2 Database and Instance memory configuration
Instance level memory - INSTANCE_MEMORY A Box indicates:

MON_HEAP_SZ AUDIT_BUF_SZ FCM – FCM_NUM_BUFFERS Option Can NOT
be set to
FCM_NUM_CHANNELS AUTOMATIC
Database level memory - DATABASE_MEMORY

UTIL_HEAP_SZ PCKCACHESZ
SHEAPTHRES_SHR SORTHEAP
BUFFER POOLS LOCKLIST MAXLOCKS
DBHEAP CATALOGCACHE_SZ
Application memory - APPL_MEMORY

(limited by MAX_CONNECTIONS & MAXAPPLS)
APPLHEAPSZ AGENT_STACK_SZ JAVA_HEAP_SZ
STMTHEAP STAT_HEAP_SZ
Db2 Database and Instance memory configuration

The Db2 memory manager groups memory allocations from the operating system into
memory sets.
• DBMS - Database memory manager set. Most memory in this set is used for
basic infrastructure purposes, including communication services that are not
specific to a database. This memory set does not require any configuration,
although user-configurable memory from this set include the monitor heap size
(mon_heap_sz) and the audit buffer size (audit_buf_sz).
• DATABASE - Database memory set. Memory allocated from this set is generally
used for processing that is specific to a single database, but not specific to an
application. Examples of memory allocated from this set includes the buffer pools,
database heap, locklist, utility heap, package cache, catalog cache, and the
shared sort heap. This set can be configured through the database_memory
database configuration parameter. You can also use the self-tuning memory
manager (STMM) to tune this memory area.
• Application - Application memory set. Memory allocated from this set is generally
used for application-specific processing. Memory allocated from this set includes
application, statistics and statement heaps, and a non-configurable shared work
area. This set can be configured through the appl_memory database
configuration parameter.

• FMP -Fenced mode process memory set. Memory allocated from this set is used
for communications between agents and fenced mode processes. Memory
allocations from this set can be configured with the DB2_FMP_COMM_HEAPSZ
registry variable and the aslheapsz configuration parameter.
• FCM - Fast communication manager memory set. Memory allocated from this set
is used exclusively by the fast communications manager. Memory from this set
can be configured with the fcm_num_buffers and the fcm_num_channels
database manager configuration parameters.
The memory in a given memory set shares common attributes, such as the general
purpose for which the memory is used, its expected volatility, and what, if any
constraints there might be on its growth. For example, buffer pools are allocated from
the database memory set, and are allocated as long as the database is active.
Statement heaps are allocated from the application memory set on behalf of specific
SQL preparation requests from an application, and last only as long as the statement
compilation operation.
Within each memory set, specific areas of memory get assigned for purposes that are
generally related to the specific memory set type. For example, certain types of
database-level processing use memory from the database memory set; memory
required for the fast communications manager is allocated from the FCM memory set.

Db2 database memory configuration has simplified and many memory-related

configuration parameters have a default setting of AUTOMATIC.
• A single parameter, instance_memory, can be used to specify all of the memory
that the database manager is allowed to allocate from its private and shared
memory heaps.
• You can use the appl_memory configuration parameter to control the maximum
amount of application memory that is allocated by Db2 database agents to
service application requests. By default, its value is set to AUTOMATIC, meaning
that application memory requests are allowed if the total amount of memory
allocated by the database partition is within the instance_memory limits.
• You do not need to manually tune parameters used solely for functional memory.
• You can query how much total memory is currently being consumed by private
and shared memory heaps of the database manager using Db2 provided SQL
table functions. You can also use the db2mtrk command to monitor heap usage.
The ADMIN_GET_MEM_USAGE table function can be used to query overall
memory consumption.
• With the simplified application memory model, it is much easier to configure and
tune application memory when required.
• The default Db2 configuration requires much less tuning, an immediate benefit for
new instances.

Defining limits for memory usage

• INSTANCE_MEMORY in DBM CFG can be used to limit total database shared
and private memory allocations for the instance:
 Set INSTANCE_MEMORY to AUTOMATIC – Db2 sets instance limit to 75-95% of physical
RAM at db2start time.
 INSTANCE_MEMORY can be set to a specific value based on planned usage (production
vs. test)
• APPL_MEMORY in DB CFG controls the maximum amount of application memory
that is allocated by Db2 database agents to service application requests:
 When appl_memory is set to AUTOMATIC, the initial application memory allocation at
database activation time is minimal, and increases (or decreases) as needed.
 If appl_memory is set to a specific value, then the requested amount of memory is
allocated initially during database activation, and the application memory size does not
change.
• DATABASE_MEMORY in DB CFG can be set to AUTOMATIC on all platforms for
Self Tuning memory management
 Automatic growth is limited based on INSTANCE_MEMORY setting
Defining limits for memory usage

The DBM configuration option INSTANCE_MEMORY defines the overall limit for all of
the databases and connected applications running in the Db2 instance. The default
value of AUTOMATIC, sets a limit that would allow most of the system memory on the
database server to be used by the Db2 instance.
The database configuration option, APPL_MEMORY provides a method to specify a
specific limit to memory usage by connected applications. This would include those
areas that were previously considered either private or shared application memory.
Most of the memory settings for application memory that could cause some problems,
like statement heap, statistics heap and application heap size can all be set to
AUTOMATIC, which allows Db2 to increase memory areas as needed up to the limit of
the defined APPL_MEMORY setting.

instance_memory: Instance memory configuration parameter.

This parameter specifies the maximum amount of memory that can be allocated
for a database partition.The default value of instance_memory is AUTOMATIC,
meaning that its actual value is computed at database partition activation time
(db2start). The actual value used is between 75 percent and 95 percent of the
physical RAM on the system, divided by the number of configured local
database partitions in the instance. This value should be suitable for dedicated
database server systems.
If instance_memory is set to a specific value, and at least one active database
has an AUTOMATIC value for database_memory, and STMM is enabled for
that database, then STMM increases the database_memory size such that Db2
uses almost the entire amount of memory specified by instance_memory,
ensuring only that enough free instance_memory is available for functional
memory requests. In this scenario, STMM does not monitor free physical
memory on the machine, therefore, instance_memory must be configured
properly to ensure that paging will not occur.
appl_memory: Application Memory configuration parameter.
This parameter allows DBAs and ISVs to control the maximum amount of
application memory that is allocated by Db2 database agents to service
application requests. By default, its value is set to AUTOMATIC, meaning that
all application memory requests will be allowed as long as the total amount of
memory allocated by the database partition is within the instance_memory
limits.
When appl_memory is set to AUTOMATIC, the initial application memory
allocation at database activation time is minimal, and increases (or decreases)
as needed. If appl_memory is set to a specific value, then the requested amount
of memory is allocated initially during database activation, and the application
memory size does not change. If the initial amount of application memory
cannot be allocated from the operating system, or exceeds the
instance_memory limit, database activation fails with an SQL1084C error
(Shared memory segments cannot be allocated).

Database shared memory

Total Database Shared Memory defined by DATABASE_MEMORY
Automatic Management using STMM can be
selected for:
• Package Cache (pckcachesz)
Database Overflow Buffer • Sort Memory (sheapthres_shr and
sortheap)
DB Heap Catalog • Locklist (locklist and maxlocks)
Utility Heap
(log buffer) Cache • Buffer Pools
Management for other database heaps:

Package Sort
Locklist • For the Catalog Cache (catalogcache) a
Cache Memory
specific size is configured, but Db2 can
overflow requests to meet high demand
Buffer Pools
• For Utility Heap (util_heap_sz) and
Database Heap (dbheap) the default is
BP 1 BP 2 BP 3 BP 4
AUTOMATIC, but that means Db2 will
allocate memory as needed but memory
will not be added or removed by STMM.
Database shared memory

The Self Tuning Memory Manager can manage the database shared memory areas
that directly impact application performance. Multiple database buffer pools can be
difficult to optimize, so STMM can be used to increase or decrease the size of buffer
pools based on the current workload.
Shortages in locking memory can cause lock escalations which can impact concurrency
and application performance, so STMM can be used to increase or decrease the
memory available for locks. The database configuration parameters locklist and
maxlocks can be set by STMM and can be adjusted when the demand for lock
memory changes.
Another type of memory that can have a big impact on application performance is sort
memory, which is used to support Hash Joins, Merge Joins, Index ANDing as well as
normal internal sort operations. The configuration parameters sheapthres_shr and
sortheap can be set by STMM and adjusted when the demand for sort memory
changes.
STMM can also manage the database package cache size, which can vary in size
depending on the usage of static and dynamic SQL by the applications currently using
a Db2 database.

Some areas of database shared memory are not supported for management by STMM.
The database utility heap, defined by util_heap_sz, is critical to the performance of
Db2 utilities like Backup, Restore and the LOAD utility. Since these utilities do not run
continuously it would be difficult for STMM to predict the correct amount of memory
needed for the utilities. The LOAD utility was designed to self-optimize its performance
by acquiring a percentage of the currently available memory in the utility heap when it
starts processing. A similar automatic buffer calculation was also added for Backup and
Restore utilities. Since STMM cannot know when these utilities are scheduled to run, it
will be necessary for a DBA to configure the size of the utility heap, which can be
changed using Db2 commands. A DBA might decide to take memory from a large
buffer pool and assign it to the utility heap just before the scheduled LOAD processing
starts.
The database heap can be configured as AUTOMATIC, but this simply means that Db2
will grow this heap as needed to support the current workload, but STMM will take
memory from the database heap and use it to increase another heap.

Db2’s database memory model: Inside the set

• All memory inside the set is stored in heaps
• Inside the heaps:
 Each heap takes memory in 16 KB units from the set when needed:
− Counters are also maintained at the heap level to ensure that allocated heap size
is not exceeded
− Heap sizes can be exceeded in a small number of cases
• Package cache and Catalog Cache
 The heap manages free memory so that small allocations and deallocations
of memory don’t require new 16 KB segments from the set
 In general, heap memory is allocated as needed but in some cases, all of
the heap is allocated at database startup
− Buffer pools
− Locklist
Db2’s database memory model: Inside the set

The heaps basically are designed so that they can take memory from the set as
needed. Memory is allocated in 16 KB increments from the set when needed and
counters are used to track the total usage by each heap. Small allocations and
deallocations can be handled using free space in currently allocated memory. The
maximum size of each heap is limited by database configuration parameters or in the
case of buffer pools, the settings in the system catalogs.
There are some exception to the rule – package cache and catalog cache can exceed
the configured size if lack of memory will cause queries to fail.
When a database is active, but no utilities are running, there will be very little memory
allocated to the utility heap. When a LOAD utility completes processing, the memory
used is freed and given back to the set.
The locklist and all buffer pools remain allocated at their maximum defined size as long
as the database remains active. Even if there has been no activity in the table spaces
assigned to a buffer pool, it will get allocated at database startup and remain allocated
until the database is deactivated.

Database memory configuration options

• database_memory can be set to:
• AUTOMATIC:
 Db2 STMM adjusts DB shared
memory automatically Database Overflow Buffer
• Number of Pages: Size of overall
database shared memory can be DB Heap Catalog
Utility Heap
(log buffer) Cache
fixed
 Database Overflow buffer gets
Package Sort
memory remaining after other heaps Cache Memory
Locklist
are defined at startup

Buffer Pools
BP 1 BP 2 BP 3 BP 4
Database memory configuration options

The database_memory configuration parameter specifies the size of the database
memory set. The database memory size counts towards any instance memory limit in
effect. The setting must be large enough to accommodate the following configurable
memory pools: bufferpools, the database heap, the locklist, the utility heap, the package
cache, the catalog cache, the shared sort heap, and an additional minimum overflow
area of 5%.
The AUTOMATIC setting allows database memory to grow beyond its initial size if there
are unforeseen requirements beyond what the overflow provides. Dynamic
configuration changes made manually or by STMM to individual memory pools also
adjust the database memory size by a corresponding amount.
If STMM is enabled (The value of SELF_TUNING_MEM is ON), STMM controls the
overall database memory size. STMM takes into account the underlying configuration
requirements, including overflow, and the performance benefits of acquiring additional
available memory. Depending on the instance_memory setting, STMM tunes database
memory to avoid shortages of system and instance memory. You can use the
DB2_MEM_TUNING_RANGE variable to assign a percentage of memory that is left
available to satisfy volatile requirements.

When a database is activated, if there is insufficient system or instance memory to

support the starting configuration, any memory areas tuned by STMM are reduced to
accommodate existing memory constraints. This action is subject to enforced minimum
sizes.
You can assign a specific value to the database_memory configuration parameter.
However, the specified value should be large enough to support the minimum
configuration requirements.

Overflow Buffer can be used for dynamic memory configuration

changes
Overflow Buffer (Database_Memory - Other Allocations)
New Allocation
New Allocation
Catalog Cache Heap (CATALOGCACHE_SZ) Database Heap (DBHEAP)
Used Used Log Buffer

logbufsz
Package Cache (PCKCACHESZ)
Lock Manager Heap (Locklist)
Used Used
Utility Heap (util_heap_sz)) Shared Sort Heap (SHEAPTHRES_SHR)

Used
Database Buffer Pools
db2 update db cfg for salesdb using pckcachesz 20000 immediate

db2 alter bufferpool ibmdefaultbp immediate size 100000
Overflow Buffer can be used for dynamic memory configuration changes

The database configuration parameter DATABASE_MEMORY can be used to define
additional database shared memory that can be used to dynamically extend the size of
memory areas while the database remains active. It could also be used to create a new
buffer pool.
In the two examples, commands have been issued to change the size of the package
cache and to increase the size of the default buffer pool IBMDEFAULTBP.

Overflow Buffer can be used to handle peak memory demands

for some heaps
Overflow Buffer (Database_Memory - Other Allocations)
Post Threshold Sort
(Overflow) Memory
Catalog Cache Heap (CATALOGCACHE_SZ)

Database Heap (DBHEAP)
Used Used Log Buffer

logbufsz
Package Cache (PCKCACHESZ)
Lock Manager Heap (Locklist)
(Full)
Used
Utility Heap (util_heap_sz)) Shared Sort Heap (SHEAPTHRES_SHR)

(Full)
Database Buffer Pools
Lock Manager storage and Buffer Pools do not expand on demand but
these could be Managed by STMM
Overflow Buffer can be used to handle peak memory demands for some heaps
Db2 can use the database shared memory associated with the overflow buffer to
handle some unexpected demands for some of the database heaps. Db2 can use this
available database shared memory to extent the shared sort memory, the utility heap,
the package cache, catalog cache and the database heap. For example, if a Db2 LOAD
utility was started with a large DATA BUFFER defined and the utility heap did not have
enough free memory to satisfy the request size, the additional memory could be taken
from the overflow buffer.
Db2 will not extend buffer pools or the lock list memory in the same way, both of these
areas can be managed by self-tuning memory management if they are configured as
AUTOMATIC which allows their size to be adjusted gradually based on the current
workload.
In the example, if the current applications required larger amounts Package Cache
memory, Db2 would use pages from the overflow buffer, defined by
DATABASE_MEMORY to meet that demand. Extending the number of pages assigned
to those areas which might reduce the memory available to other parts of database
global memory.

Database buffer pools

• Each database has at least one buffer pool – IBMDEFAULTBP
• All buffer pools reside in shared memory (Database Global Memory)
• Size is specified on creation or alteration of buffer pool
• Size can be automatically self-tuned by STMM
• Maximum size:
 1,048,576 data pages (32-bit)
 2,147,483,647 data pages (64-bit)
• Allocated when database becomes active
• Pageable memory
• Page size must match associated table space: 4 KB, 8 KB, 16 KB, and 32 KB:
 For OLTP, recommend: 4 KB
 For DSS, recommend: 16-32 KB
 For column organized a 32K page size is recommended
• If Buffer Pool too small ==> additional disk accesses
• If Buffer Pool too large ==> waste of memory, longer search time in
Buffer Pool Descriptor Area
Database buffer pools

Each database has at least one buffer pool (IBMDEFAULTBP, which is created when
the database is created). Each database can have several buffer pools. The database
must have at least one buffer pool for each page size supported in table space. All of
the buffer pools reside in shared memory (Database Global Memory), which is available
to all applications that use the database. The memory is allocated on the machine
where the database is located. If the buffer pools are large enough to keep the required
data in memory, less disk activity will occur. If the buffer pools are not large enough, the
overall performance of the database can be severely degraded. Db2 can become I/O-
bound as a result of a high amount of disk activity (I/O) required to process the data
your application requires. OLTP applications are more severely impacted by having
smaller buffer pool space than DSS applications.
The size of a buffer pool can be set to AUTOMATIC to allow the self tuning memory
manager to dynamically increase or decrease a buffer pool based on the current
database workload.

All buffer pools are allocated when the first application connects to the database, or
when the database is explicitly activated. As an application requests data out of the
database, pages containing that data are transferred to one of the buffer pools from
disk. Pages are not written back to disk until the page is changed and one of the
following occurs:
• All applications disconnect from the database
• The database is explicitly deactivated
• The database quiesces (that is, all connected applications have committed)
• Its space is required for another page that needs to be read into the buffer pool
• A page cleaner is available (num_iocleaners) and is activated by Db2.
Buffer pool size is significant both in Warehouse as well as in an OLTP environment. In
Warehouse environments there is a significant dependence on prefetch. In an OLTP
environment there is typically repetitive access to indexes, and often also to data
pages. There is minimal overhead associated with each I/O server. This means that a
large buffer pool size can reduce disk activity, improving response time and throughput.
A rule of thumb is to strive for a sufficiently large buffer pool size for all important and
highly used objects (such as index pages) to remain in memory.

db2pd: Buffer Pools report
db2pd -db tp1 -bufferpools
Database Member 0 -- Database TP1 -- Active -- Up 0 days 00:28:44 -- Date 02/06/2013 15:45:43
Bufferpools:
First Active Pool ID 1
Max Bufferpool ID 4
Max Bufferpool ID on Disk 4
Num Bufferpools 8
Address Id Name PageSz PA-NumPgs BA-NumPgs BlkSize NumTbsp … Automatic

0x909EC9D0 1 IBMDEFAULTBP 4096 2000 0 0 5 … False
0x909F4D40 2 TP1H16K 16384 1000 0 0 2 … False
0x909FD0B0 3 TP1ADATA 4096 7000 0 0 1 … False
0x90A05420 4 TP1AINDX 4096 6000 0 0 1 … False
0x909CBC10 4096 IBMSYSTEMBP4K 4096 16 0 0 0 … False
0x909D3F80 4097 IBMSYSTEMBP8K 8192 16 0 0 0 … False
0x909DC2F0 4098 IBMSYSTEMBP16K 16384 16 0 0 0 … False
0x909E4660 4099 IBMSYSTEMBP32K 32768 16 0 0 0 … False
db2pd: Buffer Pools report

The example report shows a portion of a db2pd report for the buffer pools. The report
includes the current size of each buffer pool and some statistics regarding buffer pool
activity.

Online Memory configuration considerations

• If you CREATE or ALTER the size of a buffer pool using the IMMEDIATE
option
 If there is insufficient database shared memory, you will get a warning and the
action becomes deferred
• Allocating a new buffer pool or resizing an existing one may take a
noticeable amount of time due to overhead in allocating space
 The operation is synchronous, and the CLP session will be held
until it completes
• The optimizer is sensitive to the size of the buffer pool
• If you make major changes:
 Static SQL
− Rebind packages.
 Dynamic SQL:
− Access plans are cached.
−A FLUSH PACKAGE CACHE statement invalidates all plans in the cache; the plans are
complied next time they are used.
Online Memory configuration considerations

If you specify the IMMEDIATE option on the CREATE or ALTER BUFFERPOOL SQL
statements, or let the statement default to IMMEDIATE, and there is insufficient
database shared memory to make the change, a warning is returned and the requested
change is deferred to the next database activation.
Allocating a new buffer pool or resizing an existing one might take a noticeable amount
of time due to the overhead of reallocating memory space. These operation are
synchronous and control is not returned to the calling program until they are complete.
If you are using CLP, your CLP session is held until the operation completes.
To DROP a buffer pool, it cannot be in use by a table space. You must either drop the
table space or alter the table space to use another buffer pool, before you DROP the
buffer pool.
The optimizer is sensitive to the size of a buffer pool. For applications that contain static
SQL statements, the application will have to be rebound in order that the optimizer
consider the a new buffer pool size in its access plan selection. Because the access
plan for dynamic SQL statements might be cached, you might want to have these
rebound too. A FLUSH PACKAGE CACHE statement can be used to invalidate the
cached access plans. The next time the dynamic statement is used, it will be
recompiled by the optimizer which will consider the latest buffer pool size in its access
plan selection.

Database heap memory

• dbheap - database configuration parameter has a default value of
AUTOMATIC
 The database heap can increase as needed until either the database_memory
limit is reached, or the instance_memory limit is reached.
• Allocated as needed for:
 Space for the log buffer (logbufsz)
 Space for the control blocks for:
− Tables
− Indexes
− Table spaces
− Buffer pools
 Trusted contexts, Workload Management and Audit policy information is cached
in memory for fast processing.
 Data Row compression dictionary data is stored here when tables are accessed
• Allocated when database activates
• Range: 32 – 2,147,483,647 (default is AUTOMATIC)
Database heap memory

There is one database heap per database, and the database manager uses it on behalf
of all applications connected to the database. It contains control block information for
tables, indexes, table spaces, and buffer pools. It also contains space for the log buffer
(logbufsz) and temporary memory used by utilities. Therefore, the size of the heap will
be dependent on a large number of variables. The control block information is kept in
the heap until all applications disconnect from the database.
The minimum amount the database manager needs to get started is allocated at the
first connection. The data area is expanded as needed until either the configured upper
limit is reached, or, if set to AUTOMATIC, until all database_memory or
instance_memory, or memory for both, is exhausted.
The following formula can be used as a rough guideline when deciding on a value to
assign to the dbheap configuration parameter:
10K per tablespace + 4K per table + (1K + 4*extents used),
per range clustered table (RCT)

The dbheap value that you configure represents only a portion of the database heap
that is allocated. The database heap is the main memory area used to satisfy global
database memory requirements. It is sized to include basic allocations needed for the
startup of a database in addition to the dbheap value. Tools which report memory
usage such as Memory Tracker, Snapshot Monitor, and db2pd report the statistics of
this larger database heap. There is no separate tracking of the allocations that are
represented by the dbheap configuration parameter. Therefore, it is normal for the
statistics on database heap memory usage reported from these tools to exceed the
configured value for the dbheap parameter.

Monitoring catalog cache

The catalog cache is referenced whenever a table, view, or alias name is
processed during the compilation of an SQL statement
Table A-descriptor
Catalog Cache Lookups
catalogcache_sz Table B-descriptor (successful and unsuccessful)
View A-descriptor
Alias A-descriptor
Catalog Cache Inserts

(maximum)
Overflow Buffer
Catalog Cache (Database_Memory)
Catalog Cache Overflows
High Water Mark Catalog Cache
Entries
Monitoring catalog cache

You can monitor the catalog cache portion of database memory using a set of monitor
elements:
• Catalog Cache Lookups: The number of times that the catalog cache was
referenced to obtain table descriptor or authorization information. Usage: This
element includes both successful and unsuccessful accesses to the catalog
cache. The catalog cache is referenced whenever:
• A table, view, or alias name is processed during the compilation of an SQL
statement
• Database authorization information is accessed
• A routine is processed during the compilation of an SQL statement
The execution of Data Definition Language (DDL) SQL statements involving a
table, view, or alias will evict the table descriptor information for that object from
the catalog cache causing it to be re-inserted on the next reference. In addition,
GRANT and REVOKE statements for database authorization and execute
privilege of routines will evict the subject authorization information from the
catalog cache. Therefore, the heavy use of DDL and GRANT/REVOKE
statements might also increase the ratio.

• Catalog Cache Overflows: The number of times that the catalog cache
overflowed the bounds of its allocated memory. Usage: Use this element with
cat_cache_size_top to determine whether the size of the catalog cache needs to
be increased to avoid overflowing.
Catalog cache space is reclaimed by evicting table descriptor information for
tables, views, or aliases, or authorization information that is not currently in use by
any transaction.
If cat_cache_overflows is large, the catalog cache might be too small for the
workload. Enlarging the catalog cache might improve its performance. If the
workload includes transactions which compile a large number of SQL statements
referencing many tables, views, aliases, user-defined functions, or stored
procedures in a single unit of work, then compiling fewer SQL statements in a
single transaction might improve the performance of the catalog cache. Or if the
workload includes binding of packages containing many SQL statements
referencing many tables, views, aliases, user-defined functions, or stored
procedures, you can try splitting packages so that they include fewer SQL
statements to improve performance.
• Catalog Cache High Water Mark: The largest size reached by the catalog cache.
This element indicates the maximum number of bytes the catalog cache required
for the workload run against the database since it was activated. If the catalog
cache overflowed, then this element contains the largest size reached by the
catalog cache during the overflow. Check Catalog Cache Overflows to determine
if such a condition occurred.

Dynamic and Static SQL caching
Db2 Package Cache memory

User 1 Catalog
SQL
Section Section Section Section I/O Tables
Compiler
Section Section Section Section

Application
A
Section Section
User 2
Application
Dynamic SQL Cache Static SQL Cache B
User 3
Dynamic and Static SQL caching

Before an SQL request can be processed, it must be compiled. There are two types of
SQL: Static and dynamic.
• SQL, which is prepared in advance of being run, is called static SQL. Access
plans for this type of SQL are stored in the database. All the access plans for one
program are stored in a package. Each package is divided into sections which, in
most cases, correspond to an SQL statement.
• Dynamic SQL is compiled immediately before first run time. At run time, the
access plan is stored in the cache.
Both types of SQLs produce an access plan in order to execute the request.
Db2 uses a SQL cache for access plans. The aim of the SQL cache is to minimize the
amount of system catalog access required for sections of static SQL statements and to
maximize the sharing of sections for dynamic DML statements.
The SQL cache is composed of two parts:
• Static SQL cache: This part of the global cache will contain the package
frameworks and sections for any static SQL statements in a package.
• Dynamic SQL cache: This portion of the cache is dedicated to containing
sections for dynamic SQL statements.

The total amount of memory available for the global SQL cache is determined by the
value of the PCKCACHESZ configuration parameter. Sections of packages in the
global SQL cache reflect the status of the database. If objects (tables, indexes, aliases,
and so forth) in the database are changed, access plans might be invalidated. If this
happens, then all sections of the invalidated access plans residing in the cache are
flushed from memory.
The benefits of package caching are:
• Maximum reuse potential
• Preparation time is bypassed
• Reuse of loaded packages

Check dynamic SQL cache stats with db2pd
db2pd -db tp1 -dynamic
Database Member 0 -- Database TP1 -- Active -- Up 0 days 00:10:09 -- Date 12/06/2012 08:13:52
Dynamic Cache:
Current Memory Used 377694
Total Heap Size 2582528
Cache Overflow Flag 0
Number of References 18270
Number of Statement Inserts 14
Number of Statement Deletes 2
Number of Variation Inserts 6
Number of Statements 12
Dynamic SQL Statements:

Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0xA0C2CC60 199 1 1 1 3045 3045 UPDATE BRANCH SET
BALANCE =
BALANCE + ? WHERE BRANCH_ID = ?
0xA0D3B600 343 1 1 1 3045 3045 COMMIT
0xA0D37130 429 1 1 1 3045 3045 INSERT
INTO HISTORY(ACCT_ID, TELLER_ID, BRANCH_ID, BALANCE,
DELTA, PID, ACCTNAME, TEMP)
VALUES(?, ?, ?, ?, ?, ?, ?, ?)
Check dynamic SQL cache stats with db2pd

The dynamic report of the db2pd command includes information about the dynamic
SQL portion of the package cache for the database including:
• The hash anchor identifier.
• The statement identifier.
• The number of environments that belong to the statement.
• The number of variations that belong to the statement.
• The number of times that the statement has been referenced.
• The number of times that the statement has been executed.
• The text of the SQL statement.

Monitoring the package cache
Package Cache High Water Mark
Package cache
Overflows
DATABASE_MEMORY
Overflow Buffer
Monitoring the package cache

You can monitor the database package cache memory utilization using a set of monitor
elements.
• Package Cache Lookups: The number of times that an application looked for a
section or package in the package cache. At a database level, it indicates the
overall number of references since the database was started, or monitor data was
reset.
This counter includes the cases where the section is already loaded in the cache
and when the section has to be loaded into the cache.
In a concentrator environment where agents are being associated with different
applications, additional package cache lookups might be required as a result of a
new agent not having the required section or package available in local storage.
The package cache hit ratio tells you whether or not the package cache is being
used effectively. If the hit ratio is high (more than 0.8 the cache is performing well.
A smaller ratio might indicate that the package cache should be increased.

You might want to use this information at the database level to calculate the
average package cache hit ratio for all applications. You can also look at this
information at an application level to find out the exact package cache hit ratio for
a given application. It might not be worthwhile to increase the size of the package
cache in order to satisfy the cache requirements of an application that only
executes infrequently.
The static_sql_stmts and dynamic_sql_stmts counts can be used to help provide
information on the quantity and type of sections being cached.
• Package Cache Inserts: The total number of times that a requested section was
not available for use and had to be loaded into the package cache. This count
includes any implicit prepares performed by the system. In conjunction with
Package Cache Lookups, you can calculate the package cache hit ratio using the
following formula:
1 - (Package Cache Inserts / Package Cache Lookups)
• Section Lookups: Each agent has access to a shared SQL workspace where the
working copy of any executable section is kept. This counter indicates how many
times the SQL work area was accessed by agents for an application.
• Section Inserts: The working copy of any executable section is stored in a shared
SQL workspace. This is a count of when a copy was not available and had to be
inserted.
• Package Cache High Water Mark: The largest size reached by the package
cache.
This element indicates the maximum number of bytes the package cache
required for the workload run against the database since it was activated. If the
package cache overflowed, then this element contains the largest size reached
by the package cache during the overflow. Check Package Cache Overflows to
determine if such a condition occurred.

Utility Heap memory: Util_Heap_SZ

• Recommended to set to AUTOMATIC
 Automatic: allows utilities to consider database memory overflow as part of
the available utility heap in addition to the underlying configured value.
− When DB2_WORKLOAD=ANALYTICS, a minimum value of 1,000,000 rather than
5,000
 Fixed value: utilities do not consider database memory overflow as part of
the available utility heap.
• Utility Heap used for I/O Buffers for Db2 Utilities:
 LOAD:
− DATA_BUFFER – Defaults to 25% of available utility heap
− Very important for ANALYZE phase of LOAD when the dictionary data is
created for column organized tables
 Backup/Restore :
− [WITH num-buff BUFFERS] [BUFFER buffer-size]
− Defaults to 50% of available utility heap
 REORG:
− Dictionary Build for Row Compression uses 10 MB
− Index Reorg allowing WRITE ACCESS needs memory for special log records
Utility Heap memory: Util_Heap_SZ

The utility heap provides the buffers and work areas for Db2 utilities like BACKUP,
RESTORE, and LOAD.
The LOAD utility option DATA_BUFFER is used to request a specific amount of
memory from the utility heap to be used for load processing. If this option is not
specified, LOAD will acquire 25% of the currently available memory from the utility
heap. The complex load processing for MDC tables and Range Partitioned tables
requires additional memory from the utility heap to maintain good performance. If there
is only one LOAD utility running at a time, the default would only use about 25% of the
utility heap memory and leave 75% unused, so a larger DATA_BUFFER should be
specified to make use of this memory.
The buffers for the Backup and Restore utility are allocated from the utility heap. If the
WITH BUFFERS and BUFFER options are not specified, these utilities will allocate
50% of the currently available memory from the utility heap.
Some of the processing of the REORG utility use memory form the utility heap. If a
table uses the COMRESS option and a new dictionary is being built, a work area of
10MB is needed. When the REORG utility is used to reorganize the indexes for a table
with the ALLOW WRITE ACCESS option, the utility heap is used to hold the special log
records that are used to track index changes that occur while the new indexes are
being built.

The default value for util_heap_sz is subject to change by the Db2 Configuration
Advisor as part of database creation, which is run by default in a nonpartitioned
database environment. The Db2 Configuration Advisor sets the UTIL_HEAP_SZ
parameter to AUTOMATIC (minimum value of 5000) unless the registry variable
DB2_WORKLOAD=ANALYTICS, in which case it is set to AUTOMATIC (minimum
value of 1000000).
By default, the util_heap_sz parameter is set to AUTOMATIC. This AUTOMATIC
setting allows utilities to consider database memory overflow as part of the available
utility heap in addition to the underlying configured value. The underlying configured
value represents a reservation of database memory. When the reserved amount is fully
used, more utility heap memory is taken from database memory overflow.
When the util_heap_sz parameter is set to a fixed value, utilities do not consider
database memory overflow as part of the available utility heap. The fixed value
represents a reservation of database memory and normally guides the maximum
amount of memory that is used by utilities, but does not represent a hard limit. When
the reserved amount is fully used, more utility heap memory is taken from the database
memory overflow. Typically the reserved amount is never fully used unless the default
behavior of utilities is overridden.

Db2 Sorting methods

Rows to Sort Phase Sorted Rows
be sorted in SortHeap
Piped Sort
Overflow
Temp. Table
Non-piped Sort
Db2 Sorting methods

Guidelines for Sort Performance
Because queries often require sorted or grouped results, sorting is often required, and
the proper configuration of the sort heap areas is crucial to good query performance.
Sorting is required when:
• No index exists to satisfy a requested ordering (for example, a SELECT
statement that uses the ORDER BY clause).
• An index exists, but sorting would be more efficient than using the index.
• An index is created.
• An index is dropped, which causes index page numbers to be sorted.
Sorts can be requested by syntax on the SELECT statement (such as ORDER BY), but
sorts might be required by other items on the statement as well. The presence of a
GROUP BY, UNION, or DISTINCT in the statement might all require a sort to return the
correct data.

Sorting involves two steps:

1. A sort phase. A sort can be overflowed or non-overflowed. If the sorted data
cannot fit entirely into the sort heap, which is a block of memory that is allocated
each time a sort is performed, it overflows into temporary database tables. Sorts
that do not overflow always perform better than those that do.
2. Return of the results of the sort phase. The return can be piped or non-piped. If
sorted information can return directly without requiring a temporary table to store
a final, sorted list of data, it is a piped sort. If the sorted information requires a
temporary table to be returned, it is a non-piped sort. A piped sort always
performs better than a non-piped sort.
Whether or not a sort is piped, the sort time depends on a number of factors, including
the number of rows to be sorted, the key size, and the row width. If the rows to be
sorted occupy more than the space available in the sort heap, several sort passes are
performed, in which each pass sorts a subset of the entire set of rows. Each sort pass
is stored in a temporary table in the buffer pool. If there is not enough space in the
buffer pool, pages from this temporary table might be written to disk. When all the sort
passes are complete, these sorted subsets must be merged into a single sorted set of
rows. If the sort is piped, the rows are handed directly to Relational Data Services as
they are merged.
The following elements affect sort performance:
• The settings for the following database configuration parameters:
• Sort heap size, (sortheap), which specifies the amount of memory to be used
for each sort.
• Sort heap threshold (sheapthres) and the sort heap threshold for shared sorts
(sheapthres_shr), which control the total amount of memory for sorting
available across the entire instance for all sorts.
• Statements that involve a large amount of sorting
• Missing indexes that could help avoid unnecessary sorting
• Application logic that does not minimize sorting
• Parallel sorting, which improves the performance of sorts, but can only occur if
the statement uses intra-partition parallelism.

Database Shared Sort memory management

• With DBM option SHEAPTHRESH = 0, all SORTHEAP allocated from
database shared memory
• SHEAPTHRES_SHR must be set to AUTOMATIC or Number of pages:
 Can be increased or decreased dynamically
 Soft Limit: Can extend to Database Overflow based on current demand
App 3 App 2
(Degree 4) (Degree 2)
App 1
db2agent (Degree 1)
db2agent
db2agntp db2agntp db2agent
db2agntp
Database
db2agntp Shared sortheap sortheap sortheap sortheap
Memory
db2agntp sortheap Shared Sort Memory
sheapthres_shr (soft limit )
db2agntp
Other DB Buffer Pools
Shared Memory
Database Shared Sort memory management

If the Database Manager Configuration option SHEAPTHRES is set to 0, Db2
management for sort memory uses the shared database level sort memory for all
applications requests for sortheap based on the configuration option
SHEAPTHRES_SHR. The database configuration option SHEAPTHRES_SHR can be
dynamically increased or decreased while a database remains active.
The shared sort memory area is treated as a soft limit. Additional memory can be
acquired from the Database Overflow area if shared sort demand exceeds the defined
size for database shared sorts.
The configuration option SHEAPTHRES_SHR can be set to AUTOMATIC to allow the
Self Tuning Memory Manager to automatically adjust the size of database shared
memory when the application workload changes. This will be discussed in the next
lecture unit.

Monitoring sort performance and memory utilization

Sort related Monitor elements DB CFG
SHEAPTHRES_SHR = 9000
SORTHEAP = 1500
• Total section sorts
• Total section sort time (ms) Database Overflow Buffer
• Total section sort processing time sortheap sortheap
• Sort overflows Temp tables

Shared Sort Memory
sheapthres_shr
• Post shared threshold sorts sortheap sortheap sortheap
sortheap sortheap sortheap

Also monitor buffer pool logical and Buffer Pools
physical reads for temporary data pages
Other DB
Shared Memory
Monitoring sort performance and memory utilization

A number of monitor elements track various aspects of the sort operations performed
by the Db2 database server, including:
• total_sorts - The total number of sorts that have been executed
• total_section_sorts - Total number of sorts performed during section execution
• Use this element with the total_section_sort_time monitor element to calculate
the average amount of time spent performing sorts during section execution.
• At the activity and package cache levels, use this element to identify statements
which are performing large numbers of sorts. These statements may benefit from
additional tuning to reduce the number of sorts.
• total_section_sort_time - the Total amount of time spent performing sorts while
executing a section,
• total_section_sort_proc_time - Total amount of processing (non-wait) time spent
performing sorts while executing a section.

• sort_overflows - the total number of sorts that ran out of sort heap and may have
required disk space for temporary storage.
• post_shrthreshold_sorts - The total number of sorts that were throttled back by
the sort memory throttling algorithm. A throttled sort is a sort that was granted
less memory than requested by the sort memory manager.
These statistics can be examined for current activities, statements in package cache,
active connections and units of work or the accumulated numbers for workloads and
service classes.
You may also want to monitor buffer pool activity for temporary table pages to see if the
accesses to the temporary tables used to perform sorts are effectively using the buffer
pool memory to avoid excessive disk reads and writes.

Monitoring sort processing using SQL

SELECT varchar(workload_name,25) as workload ,
total_section_sorts , sort_overflows,
post_shrthreshold_sorts,
total_section_sort_time, total_section_sort_proc_time,
pool_temp_data_l_reads
FROM TABLE(MON_GET_WORKLOAD('SYSDEFAULTUSERWORKLOAD',-1) )
WORKLOAD TOTAL_SECTION_SORTS SORT_OVERFLOWS POST_SHRTHRESHOLD_SORTS

------------------------- -------------------- -------------------- -----------------------
SYSDEFAULTUSERWORKLOAD 6 1 0
TOTAL_SECTION_SORT_TIME TOTAL_SECTION_SORT_PROC_TIME POOL_TEMP_DATA_L_READS

----------------------- ---------------------------- ----------------------
22322 9394 7017
Monitoring sort processing using SQL

Sort related performance statistics could be retrieved for active SQL statements, active
connections or units of work. You could also query sort statistics for the statements in
the database package cache.
The sample query provides a summary of sort related statistics using the
MON_GET_WORKLOAD table function, which would include all application processing
performed in the default user workload since the database became active.
The sample query result shows that one sort operation exceeded the sortheap memory.
There were no post threshold sorts shown in the report, so the defined size of the
shared sort memory for the database was never exceeded.

Monitoring database shared sort memory using SQL
SELECT VARCHAR(MEMORY_POOL_TYPE,25) AS MEMORY_POOL,

MEMORY_POOL_ID,
MEMORY_POOL_USED , MEMORY_POOL_USED_HWM
FROM TABLE (MON_GET_MEMORY_POOL('DATABASE','TP1',-1)) AS M1
WHERE MEMORY_POOL_TYPE = 'SHARED_SORT'
MEMORY_POOL MEMORY_POOL_ID MEMORY_POOL_USED MEMORY_POOL_USED_HWM

------------------------- -------------------- -------------------- --------------------
SHARED_SORT 18 65536 10813440
Monitoring database shared sort memory using SQL

The slide shows an example SQL query and result, using the
MON_GET_MEMORY_POOL table function to show the current and maximum
memory allocations for the database.

db2mtrk: Memory tracker command
>>-db2mtrk--+-----+--+-----+--+-----+--+-----+--+-----+--------->
'- -i-' '- -d-' '- -p-' +- -m-+ '- -a-'
'- -w-'
>--+--------------------------+--+-----+--+-----+--------------><
'- -r--interval--+-------+-' '- -v-' '- -h-'
'-count-'
• Provides complete report of memory status, for instances,

databases and agents:
 Current size
 Maximum size (hard limit)
 Largest size (high water mark)
 Type (identifier indicating function for which memory will be used)
 Agent who allocated pool (only if the pool is private)
db2mtrk: Memory tracker command

The Memory tracker command, db2mtrk, provides a complete report of memory
status, for instances, databases and agents. This command outputs the following
memory pool allocation information:
• Current size
• Maximum size (hard limit)
• Largest size (high water mark)
• Type (identifier indicating function for which memory will be used)
• Agent who allocated pool (only if the pool is private)
• Application
Command Syntax:
>>-db2mtrk--+-----+--+-----+--+-----+--+-----+--+-----+--------->
'- -i-' '- -d-' '- -p-' +- -m-+ '- -a-'
'- -w-'
>--+--------------------------+--+-----+--+-----+--------------><
'- -r--interval--+-------+-' '- -v-' '- -h-'
'-count-'

Example
The following call returns database and instance normal values and repeats every 10
seconds:
db2mtrk -i -d -v -r 10

Database and Instance memory display: db2mtrk

Tracking Memory on: 2012/11/28 at 11:05:37
Memory for database: TP1
Backup/Restore/Util Heap is of size 65536 bytes

Package Cache is of size 196608 bytes
Other Memory is of size 131072 bytes
Catalog Cache Heap is of size 196608 bytes
Buffer Pool Heap (4) is of size 17563648 bytes db2mtrk –d –v
Buffer Pool Heap (3) is of size 26214400 bytes
Buffer Pool Heap (System 32k buffer pool) is of size 851968 bytes
Shared Sort Heap is of size 0 bytes
Lock Manager Heap is of size 393216 bytes
Database Heap is of size 50397184 bytes
Application Heap (54) is of size 131072 bytes
Applications Shared Heap is of size 262144 bytes
Total: 124190720 bytes
Database and Instance memory display: db2mtrk

The example shows a sample db2mtrk report for an active database. The system or
hidden buffer pools are included in this report.
The report returns the current memory allocated for each heap. Notice that the size
reported for shared sort memory is zero and the utility heap is very small. These
numbers indicate the memory usage not the configured sizes for these memory heaps.
Buffer pools will show the current configured size not the current use of a buffer pool.

Monitoring the overall memory usage using the

MON_GET_MEMORY_SET table function
SELECT varchar(memory_set_type,25) as memory_set,

varchar(db_name,20) as database,
memory_set_used , memory_set_used_hwm
FROM TABLE (MON_GET_MEMORY_SET(NULL,CURRENT_SERVER,-1)) as m1
MEMORY_SET DATABASE MEMORY_SET_USED MEMORY_SET_USED_HWM

------------------------- -------------------- -------------------- --------------------
DBMS - 57920 58112
FMP - 448 448
PRIVATE - 8704 9472
DATABASE TP1 134272 144704
APPLICATION TP1 1216 1600
Monitoring the overall memory usage using the MON_GET_MEMORY_SET table

function
You can examine memory usage at the level of memory sets, which are allocations of
memory from the operating system.
The MON_GET_MEMORY_SET table function retrieves metrics from the allocated
memory sets, both at the instance level, and for all active databases within the instance.
The parameters allow the selection of a particular memory set, or a particular database.
The memory sets listed are:
• DBMS - the Instance or Db2 database manager (DBM) memory set
• FMP - Fenced mode process (FMP) memory set, for the instance.
• PRIVATE - Private memory set, for the instance.
• DATABASE - Database memory set, per database.
• APPLICATION - Application memory set, per database. This set can be
configured through the appl_memory database configuration parameter.

How does STMM work?

• Uses heap specific system metrics
• Constantly monitors system to make
use of any free OS memory (only if
DATABASE_MEMORY is set to heap specific OS Memory
system metric statistics
AUTOMATIC)
• Works iteratively to determine an
optimal memory configuration for all
Memory
heaps
reallocation
 Iterative approach promotes stability algorithm
• Control algorithms help determine

interval length and prevent oscillations
Control
algorithms
How does STMM work?

The implementation of STMM required heap specific and system-level metrics to
monitor and adapt the memory usage for the database workload. The metrics that are
used in the db2mtrk and db2pd reports are adequate for manual tuning but for a
sophisticated memory management system like STMM, the additional metrics were
added to the database kernel to help manage memory allocations based on memory
usage for the entire system. STMM is constantly monitoring the system memory usage
to determine if a database's shared memory size should grow or shrink.
STMM was designed to work iteratively, making relatively small changes to memory
allocations and then checking the metrics on the next interval to see if additional
adjustments are needed. This approach is intended to provide consistently improved
performance rather than potentially causing problems by reacting too quickly to an
apparent change in workload and making a large change in memory allocations. The
iterative approach can also improve system stability.
STMM contains control algorithms to determine an appropriate interval for the next
evaluation of the system memory metrics. These are designed to avoid oscillations in
memory allocation.

STMM: In each tuning interval

• Tuner wakes up from sleep
• Determine if memory configuration is
sub-optimal
 Some heaps will be needy, others will
have more than enough memory YES Does any heap NO
• If DATABASE_MEMORY is being need more
tuned: Can memory be memory
 Determine whether OS has free taken from OS
NO
memory that can be used
 Use this memory to satisfy needy heaps
YES
• If DATABASE_MEMORY is not Take memory
being tuned or if taking memory from Find another heap
from OS and
the OS couldn’t satisfy all heaps to donate memory
 Take memory from heaps with more give to heap
to first heap
than enough and give to those that are
needy
• Continue until no more memory can Determine
be moved Go to sleep Tuning
 In each interval each heap can only frequency
grow by 50% or decrease by 20% End
Wake up
• Determine tuning frequency based
on workload Begin
STMM: In each tuning interval

The diagram shows some of the processing logic that STMM uses for each interval.
The first thing STMM does is to determine if any of the memory heaps are in need of
additional memory. Some heaps might need memory while others might have an
excess.
For example, activity in one buffer pool might be very high, but there are only a few
small sorts that are currently active.
If DATABASE_MEMORY is set to AUTOMATIC, then STMM will first try to acquire
memory for heaps that need more memory from free operating system memory. If
DATABASE_MEMORY is not set to AUTOMATIC or if the operating system does not
have available memory, then STMM will try to acquire the needed memory from heaps
that can be reduced in size.
In any one interval of STMM, a heap can only be increased by 50% or decreased by
20% of its current size. These limits were selected to limit the exposure to causing
problems by overreacting to a workload change. The reason that the limit on increase is
greater than the limit on decrease is that there is a greater risk involved in decreasing
the size of a heap than in increasing its size.

STMM will also decide on an appropriate interval to wait for the next evaluation. A
typical STMM interval is about 60 seconds, but can be shorter or longer depending on
the stability of the workload.

Automatic management of selected memory heaps

Mixture of Static and Automatic Memory Management
Automatic Static
Database Overflow Buffer Database Overflow Buffer
DB Heap Catalog DB Heap Catalog

Utility Heap Utility Heap
(log buffer) Cache (log buffer) Cache
Sort
Package Memory Package Sort
Cache Locklist Cache Memory
Locklist
Buffer Pools Buffer Pools
BP 1 BP 2 BP 3 BP 4 BP 1 BP 2 BP 3 BP 4
Automatic management of selected memory heaps

One of the key features for the Self Tuning Memory Manager is to give DBAs the
control to selectively turn on STMM to manage some parts of database shared memory
and to have some areas set by the DBA.
In the first example, self-tuning memory has been selectively enabled for sort memory,
lock memory and most of the buffer pools. One buffer pool is not being managed by
STMM. This might have been done because that buffer pool supports an application
that must have very high performance, but the transaction rate fluctuates, so the DBA
decided to dedicate some memory to that application.
In the second example, the DBA decided to have STMM manage all of the database
buffer pools, so STMM could move pages between the buffer pools to respond to
changes in application access to different tables and indexes. This could also benefit
applications that have varied demand for temporary tables for large sorts. In this
example, the sizes of sort memory, lock memory and the package cache have been set
by the DBA and will not be managed by STMM.

STMM modes of operation

• Works in two different modes:
 Tuning DATABASE_MEMORY parameter:
− Takes from and returns memory to the OS as necessary
− Total
amount of memory used by Db2 can grow over time, but is limited by
INSTANCE_MEMORY setting
• Requires only one heap for tuning
 No tuning of DATABASE_MEMORY parameter:
− Memory tuning still occurs but total memory used by database is constant
− For one heap to grow, another heap must shrink
• Requires two heaps to be able to tune
• Is able to tune multiple databases and instances on the same server
system at the same time
• Works in non-partitioned and in partitioned (DPF) environments
STMM modes of operation

The mode of operation for the Self Tuning Memory Manager depends on how the
database configuration parameter DATABASE_MEMORY is set. This parameter is
used to configure the overall size of database shared memory for a database.
If DATABASE_MEMORY is set to AUTOMATIC, then STMM can take memory from
the operating system and return operating system memory, allowing the total size of
shared memory for a database to grow or shrink over time based on workload
demands. In this mode, STMM would only need one database memory heap to be set
for automatic management. For example, a database that has one large buffer pool
could have STMM grow or shrink that one buffer pool by exchanging memory with the
operating system. Of course, multiple heaps could also be managed by STMM in this
mode.
If DATABASE_MEMORY is not set to AUTOMATIC, then the overall size of database
shared memory would be fixed. In this mode, memory would only be exchanged
between heaps that are configured for STMM management, which would require at
least two heaps to be STMM managed. STMM might decide to move memory between
buffer pools or between a buffer pool with low activity and sort memory based on the
current application workload needs, but it could not increase the total amount of
memory allocated for database shared memory.

When DATABASE_MEMORY is set to AUTOMATIC, STMM could be used to

automatically adjust the shared memory for multiple databases in the same or even
different Db2 instances to balance the available system memory when the database
workloads changed.
STMM can be used with single partition Db2 databases and also in more complex
environments like partitioned Db2 databases using the DPF feature.

STMM and the buffer pools

• Trades memory between buffer pools based on relative need
 Db2 STMM metrics determine where memory is most needed such that total
system time is reduced
• Zero, one or more buffer pools can be set to AUTOMATIC
 In newly created Db2 databases, all buffer pools default to AUTOMATIC
• Works with buffer pools of any page size
 Transfers from a buffer pool with 8K pages to one with 4K are 1:2
• Decreasing the buffer pools can take a lot of time:
 Must write out all dirty pages in memory being freed
 If pages are in use the resize may wait on locks
 A large percentage of tuning time could be spent on alter buffer pools
− Not necessarily a concern, just something to keep in mind
STMM and the buffer pools

One of the strengths of STMM is its ability to tune the memory allocated to multiple
buffer pools. If a database has more than five buffer pools it can be difficult to find an
optimal size for each buffer pool. The STMM metrics determine which buffer pools to
increase in size in order to reduce system overhead. Adding memory to a buffer pool
could improve the read hit ratio and decrease the read I/O activity, which could save the
CPU time required to perform the I/Os.
A DBA can configure one buffer pool, multiple buffer pools or no buffer pools for
automatic management by STMM. STMM can move memory between buffer pools with
different page sizes. Each page taken from a buffer pool with 8K pages would become
2 4K pages if moved to a buffer pool with 4K page size.
For newly created databases, the default size for buffer pools will be AUTOMATIC. A
buffer pool on a UNIX system will start with 1000 pages and then grow or shrink based
on STMM evaluation of the workload.
If STMM decides to decrease the size of a buffer pool, some additional time might be
required to complete the change. Any pages to be freed that contain changed data will
need to be written back to disk. There could be some delays, waiting for locks to be
released on the pages. This activity can lengthen the time it takes STMM to make the
memory size changes.

STMM in action: BP sizes during tuning

22000000
20000000
18000000
Phase 1 Phase 2 Phase 3
16000000
14000000
BP Size in pages
12000000
80 GB
10000000
8000000
6000000
4000000
2000000
0
23 :5 1
23 :3 1
23 :4 4
23 :5 5
0: 0
0: 0
0: 0
0: 0
1: 6
1: 3
2: 4
2: 2
3: 8
3: 3
3: 2
3: 9
3: 2
4: 2
4: 2
4: 2
4: 1
4: 6
5: 0
5: 8
5: 9
5: 8
5: 3
5: 8
2
:1
:0
:0
:5
:2
:1
:1
:5
:1
:2
:0
:2
:0
:1
:5
:4
:0
:1
:4
:4
:5
:4
:2
:0
:2
01
09
24
35
04
52
30
47
02
16
33
50
59
13
27
39
49
57
06
14
24
33
40
47
4
9
:2
:2
:3
:3
:4
23
Time
BP 1 BP2 BP3 BP4 BP 5 BP 6
STMM in action: BP sizes during tuning

In this test, STMM was tuning six buffer pools. The buffer pools started using a very
small portion of the 80 GB of system memory.
The tuning went through three basic phases. The first phase lasted 1.5 hours. All of the
buffer pools were increased in size, but one buffer pool, BP1 in the chart, grew much
larger than the rest and acquired a large percentage of the available memory. On
smaller systems with less memory, the first phase would have been much shorter.
The second phase, which lasted about 3.5 hours, STMM continued to make
adjustments to the size of the buffer pools as the workload analyzed. The largest buffer
pool continued to increase in size as STMM observed the benefits from adding more
memory.
In the third phase, the workload was stable so STMM began making small changes to
memory allocation when it was necessary.
So for, the given system and the OLTP workload, it took about five hours to reach a
close to optimal memory configuration.
If the work were to remain static, STMM could eventually be turned off.

STMM in action: Two databases on the same server

• Two databases running the same workload on the same host:
 Four clients looping through the 21 queries used in TPC-H
 15 GB databases
• Running on a machine with 32 GB of RAM
• Demand for memory for each database is equal
• One database is started first and allowed to use up all the memory
• Then, six hours later, the second database is started
 After both database run together, second database is stopped
• STMM should allow for proper sharing of memory…
STMM in action: Two databases on the same server

A test environment was set up with the following characteristics:
• There were two databases, each with 15 GB of data running on the same
system.
• Both databases were configured with DATABASE_MEMORY set to
AUTOMATIC to allow STMM to acquire and release OS Free memory.
• Each database was run with four connections using 21 queries from the TPC-H
benchmark.
• The system had 32 GB of memory.
• The memory demand for each database would be expected to be the same.
• One database was started and run for six hours, allowing it to consume most of
the system's memory.
• The second database was started after six hours, run for several hours and then
it was stopped leaving the first database running.
The results of the test are shown on the next slide.

STMM in action: Two databases on the same server – Results
7000000
Second
database
6000000
stopped
5000000
Second
Memory (in 4K Pages)
4000000 database
started
3000000
2000000
1000000
0
0 10000 20000 30000 40000 50000 60000 70000
Time (in seconds)
STMM in action: Two databases on the same server – Results

This graph shows how STMM would manage the available system memory between
two similar databases running on the same system.
The first database started with very small defined database shared memory usage and
grew slowly to acquire most of the system's memory. Since there was no competition
for the system memory, STMM would continue to add system free memory to be used
by the first database.
As soon as the second database was started, STMM running on the first database
began to release memory reducing the database shared memory size so that the
second database could increase its database shared memory. It took several hours for
STMM to reach the point where both databases had even memory allocations. The
exchange continued until STMM had configured the two databases with roughly equal
memory database shared memory sizes.
When the second database was stopped, STMM gradually increased the memory
allocated to the first database, eventually allowing it to regain most of the system's
memory.

STMM and Sort memory

• STMM can tune Sort Memory if the DBM CFG option SHEAPTHRES is
set to the default value of 0
 All sorts will use database shared memory defined by SHEAPTHRES_SHR:
− If
SHEAPTHRES_SHR is AUTOMATIC then overall sort memory is managed by
STMM and SORTHEAP must also be set to AUTOMATIC
− If
SHEAPTHRES_SHR is not AUTOMATIC then overall sort memory is fixed but
SORTHEAP may still be set to AUTOMATIC
− Changes in SORTHEAP can effect active sorts
STMM and Sort memory

Sort memory is allocated for several important types of processing, including Hash
Joins, Merge Joins, Multiple Index Anding as well as sort operations for running SQL
functions like ORDER BY and GROUP BY and CREATE INDEX. STMM can be used
to manage the total amount of memory available for these functions as well as the
setting of SORTHEAP, which regulates the memory available for each sort-memory
based function.
For STMM to automatically manage the memory used for sorting the DBM
configuration parameter, SHEAPTHRES needs to be set to 0. This implies that all sorts
running in the instance will use the database shared memory defined by
SHEAPTHRES_SHR.

If SHEAPTHRES_SHR is set to AUTOMATIC, then STMM will manage the shared

sort memory for the database and the total memory available for sort operations might
grow or shrink depending on the application workload. If SHEAPTHRES_SHR is set to
AUTOMATIC, then SORTHEAP, which defines the maximum memory size for a single
sort operation, must also be set to AUTOMATIC. This helps to avoid the following
conditions:
1. The available sort memory is underutilized because SORTHEAP is small and
there are not many concurrent sorts.
2. The available sort memory is over-utilized, either because SORTHEAP is too
large or there are a large number of concurrent sorts.
If SHEAPTHRES_SHR is NOT set to AUTOMATIC, STMM can still be used to
dynamically set an optimal size for SORTHEAP, if SORTHEAP is set to AUTOMATIC.
The default value is subject to change by the Db2 Configuration Advisor as part of
database creation, which is run by default in a nonpartitioned database environment.
The Db2 Configuration Advisor sets the value of the sortheap parameter to
AUTOMATIC (minimum value of 256) unless DB2_WORKLOAD=ANALYTICS, in
which case it is set to a minimum value of 32768 (not AUTOMATIC).

STMM and Lock memory

• Locklist:
 Locklist size can now be increased or decreased dynamically
• Maxlocks:
 Percent of locklist usage per connection can be set to AUTOMATIC
 Db2 can increase maxlocks to avoid lock escalations when overall locklist
usage is lower
 Maxlocks must be set to AUTOMATIC if LOCKLIST is configured as
AUTOMATIC
STMM and Lock memory

The database configuration option locklist can be increased or decreased dynamically
and set to AUTOMATIC.
When LOCKLIST is set to AUTOMATIC, STMM will also tune the value of
MAXLOCKS, increasing MAXLOCKS when the locklist memory is underutilized and
decreasing MAXLOCKS when the memory for locklist is close to its maximum size.
Db2 will not allow MAXLOCKS to be set to AUTOMATIC if LOCKLIST is not set to
AUTOMATIC.

STMM in action: Tuning an OLTP workload

• 370 clients running transaction processing workload
• Running on a machine with:
 128 GB of RAM
 2 TB database
 494 * 36 GB disks
• Workload is very sensitive to buffer pool sizing
• Each of the 13 buffer pools are started with 1000 pages
 1000 pages is the default size for a newly created buffer pool
• Workload is started and STMM begins tuning
• STMM should dramatically improve performance…
STMM in action: Tuning an OLTP workload

A performance test was run to see how STMM could tune a standard OLTP workload
starting with the Db2 default memory configuration.
The configurations was as follows:
• 370 clients running transactions
• 2 TB of data in the database
• 128 GB of system memory
• 494 disks, 36 GB of storage on each disk
• Database has 13 different buffer pools each starting at 1000 pages
• The workload is known to be sensitive to correct sizing for the buffer pools
The workload was started and allowed to run for a number of hours with STMM actively
tuning the Db2 memory heaps.

STMM in action: OLTP workload results

160000
Phase 1 Phase 2 Phase 3
150000
140000
130000
120000
110000
100000 300%
Transactions Per Minute
90000
80000
70000
60000
50000
40000
30000
20000
10000
1.5 hours 3.5 hours
0
22:54:42
23:07:14
23:19:44
23:32:14
23:44:44
23:57:14
0:09:44
0:22:15
0:34:45
0:47:15
0:59:45
1:12:15
1:24:45
1:37:16
1:49:46
2:02:16
2:14:48
2:27:18
2:39:49
2:52:19
3:04:49
3:17:19
3:29:49
3:42:19
3:54:50
4:07:20
4:19:50
4:32:20
4:44:50
4:57:20
5:09:50
5:22:20
5:34:51
Time
STMM in action: OLTP workload results

The initial performance for this workload running with the default memory settings was
about 47,000 transactions per minute. STMM was able to increase database
performance to about 140,000 transactions per minute, which is a 300% improvement
in performance over the defaults in a few hours of operation.
There are three distinct phases for STMM memory tuning. For this workload, it took
about 1½ hours for STMM to reach the initial optimized memory configuration. For the
next 3½ hours, STMM continues to monitor the workload making smaller adjustments
to allocations and testing the results. So, after about 5 hours, STMM reaches the point
where the memory tuning can be stopped because the application is stable and no
more changes seem necessary.

Configuration changes: Activating Self Tuning Memory

• Is ON by default for newly created Db2 databases
• Configuration parameter SELF_TUNING_MEM must be set to ON
 update db cfg for database <db_name> using self_tuning_mem on
• Set each parameter that you wish to tune to AUTOMATIC

 update db cfg for database <db_name> using locklist automatic
• For buffer pools, an alter bufferpool command is necessary

 alter bufferpool ibmdefaultbp size automatic
 Or for new buffer pools
− create bufferpool <bp_name> size automatic
• Feature can be turned on dynamically
Configuration changes: Activating Self Tuning Memory

In order to have STMM active for a database, a new database configuration parameter,
SELF_TUNING_MEM must be set to ON. This will be the default value when a new
database is created.
For example:
update db cfg for database sample using self_tuning_mem on
Set each memory heap that should have its size managed by STMM would need to be
set to AUTOMATIC.
This would include Package Cache (pckcachesz), Sort Memory (sheapthres_shr and
sortheap) and Locklist (locklist and maxlocks) in the database configuration.
For example:
update db cfg for database sample using locklist automatic
For buffer pools to be managed by STMM, an ALTER BUFFERPOOL command would
be needed.
For example:
alter bufferpool ibmdefaultbp size automatic

As we discussed earlier in the presentation, DATABASE_MEMORY can also be set to

AUTOMATIC to allow overall database shared memory to grow and shrink under
STMM control.

Configuration changes for STMM

• Self tuning memory trades memory between the different consumers
 Two or more consumers must be tunable for tuning to start:
−A parameter is tunable if it is set to AUTOMATIC
− The database_memory parameter is also tunable when set to a value
• To query whether or not the system is tuning:
 Connect to the database
 GET DB CFG SHOW DETAIL
 Check the value for SELF_TUNING_MEM:
− If set to ON (ACTIVE) then system is being tuned
− If set to OFF, or ON (INACTIVE) then system is not being tuned
• Current size of memory heaps can be listed
 GET DB CFG SHOW DETAIL
 SQL Query using SYSIBMADM.DBCFG
• Current buffer pool sizes can be displayed using db2mtrk, db2pd reports
or SQL query with MON_GET_MEMORY_POOL
Configuration changes for STMM

In order for STMM to be able to increase the size of a buffer pool or some other
memory heap, the memory needs to be taken from somewhere. Additional memory
could come from:
• The operating system free memory if DATABASE_MEMORY is set to
AUTOMATIC.
• The overflow buffer for the database, if DATABASE_MEMORY is set to a value
that exceeds the 20% reserved for the overflow buffer.
• One of the other heaps or buffer pools that are configured as AUTOMATIC.
To check on the status of STMM in a database you could connect to the database and
run the command:
db2 get db cfg show detail

Check the status of SELF_TUNING_MEM:

• ON (ACTIVE): Indicates that STMM is active and able to tune memory.
• ON (INACTIVE): Indicates that STMM is set ON, but is currently unable to tune
memory. This could indicate that there are not two memory consumers currently
set to AUTOMATIC, so it is not possible to exchange memory between
consumers. This might be the case if when a DBA decides to set the memory
heaps to a fixed size for some special processing and that the heaps will be
reconfigured to AUTOMATIC at a later time.
The current size of automatically tuned memory heaps can be displayed using the GET
DB CFG SHOW DETAIL report.
To list the current size for database buffer pools, you can use the db2mtrk command or
a SQL query using the MON_GET_MEMORY_POOL table function. The db2pd
command could also be used to show memory heap and buffer pool sizes.

Configuration changes: Deactivating Self Tuning Memory

• Two ways to turn STMM off:
 Set SELF_TUNING_MEM parameter to OFF:
update db cfg for database <db_name> using self_tuning_mem off
− Allows for turning STMM OFF and then ON while maintaining the same set of self
tuned parameters
 Turning an individual parameters to manual (or a value) will stop tuning for
that parameter:
update db cfg for database <db_name> using locklist manual
update db cfg for database <db_name> using locklist 1000
alter bufferpool <bp_name> size manual
alter bufferpool <bp_name> size 1000
• All updates can be done dynamically

 Update may be deferred (sqlcode 1363) in some cases
− Setting to value causes increase or decrease
Configuration changes: Deactivating Self Tuning Memory

It is possible to temporarily or permanently turn STMM memory tuning off for a
database. STMM can be stopped in the following ways:
1. Set the DB configuration parameter SELF_TUNING_MEM to OFF.
For example:
update db cfg for database sample using self_tuning_mem off
This allows for turning STMM OFF without changing the options for the self
tuned parameters. STMM could then be reactivated by changing
SELF_TUNING_MEM back to ON.
2. Turning individual parameters to manual (or a value) will stop tuning for that
parameter.
For example:
update db cfg for database sample using locklist manual
update db cfg for database sample using locklist 1000
alter bufferpool ibmdefaultbp size manual
alter bufferpool ibmdefaultbp size 1000

The setting of a buffer pool size or memory heap size to MANUAL implies that you want
the buffer pool or memory heap to remain at its current size and STMM tuning should
stop. This provides a convenient way to stop tuning a heap once the performance
results are acceptable.
In some cases, a SQLCODE 1363 might be returned indicating that the change could
not be accomplished and has been deferred until the next database activate. In most
cases, this is because an attempt was made to set a buffer pool or memory heap to a
larger size and that memory could not be acquired by Db2. In the case of locklist, the
code might be returned because there are too many current locks being used to reduce
the locklist to the requested size.
If all of the memory areas being tuned by STMM are set to a value or manual, then
STMM will not have additional tuning to perform.

Demonstration 1
Db2 database memory configuration
• Use the db2mtrk command and SQL statements to monitor database

memory utilization.
• Compare buffer pool activity statistics for SQL workloads using two
different database memory configurations.
• Monitor the database utility heap memory usage for loading data into
row organized and column organized tables.

Demonstration 1:
Db2 database memory configuration
Purpose:
This demonstration will look at the utilization of database memory and the
efficiency of processing both read and write SQL workloads with different
database memory configurations. You will also look at the memory used for
data loading for row organized and column organized tables.
Task 1. Set minimal memory allocations for the database and

load several test tables with data.
Important Note: This demonstration uses a database named TP1 which is loaded with
test tables in the Db2 instance inst464. You need to logon to the Linux system using
the instance owner id: inst464.
ibm2blue.
You will start by configuring the TP1 database with small memory allocations for
the buffer pools and sort memory
The file startcfg.cmd contains the statements to set the two buffer pools and
sort memory to fixed sizes. The self-tuning memory function will not adjust these
memory sizes automatically.


• cd $HOME/Db2memory
• db2start
• db2 -tvf startcfg.cmd
• db2 terminate
• db2 deactivate db tp1
• db2 activate db tp1
Check the TP1 database memory allocations using the db2mtrk command and
also run a SQL query using the file dbmemory.sql that shows current and peek
database memory usage.
• db2mtrk -d -v
Tracking Memory on: 2018/04/17 at 08:32:06
Memory for database: TP1
Backup/Restore/Util Heap is of size 65536 bytes

Package Cache is of size 262144 bytes
Other Memory is of size 196608 bytes
Catalog Cache Heap is of size 196608 bytes
Shared Sort Heap is of size 1310720 bytes
Lock Manager Heap is of size 21626880 bytes
Database Heap is of size 144244736 bytes


Applications Shared Heap is of size 393216 bytes
Total: 186253312 bytes
The two non-system buffer pools are 5MB each.
• db2 -tvf dbmemory.sql
select varchar(memory_pool_type,25) as memory_pool, memory_pool_id,
memory_pool_used , memory_pool_used_hwm
from table (mon_get_memory_pool('DATABASE','TP1',-1)) as m1
order by memory_pool_id

------------------------- -------------------- -------------------- --------------------
DATABASE 2 141888 141888
LOCK_MGR 4 21120 21120
UTILITY 5 64 64
PACKAGE_CACHE 7 1600 1600
CAT_CACHE 8 448 448
BP 16 5312 5312
BP 16 5312 5312
BP 16 1792 1792
BP 16 1536 1536
BP 16 1408 1408
BP 16 1344 1344
SHARED_SORT 18 2304 2560
XMLCACHE 93 192 192
You will create two test tables using the file memtables.ddl. One table uses row
organization, while the other is column organized.
Use the two files, loadrows.ddl and loadcols.ddl to execute the LOAD utility to
process the same input. Each load process will allocate database utility heap
memory for processing the input.


• db2 -tvf memtables.ddl
• db2 -tvf loadrows.ddl
load from hist200k.del of del modified by pagefreespace=20 messages rowload1.msg
replace into mem.rowhist nonrecoverable

select varchar(memory_pool_type,25) as memory_pool, memory_pool_id, memory_pool_used ,

memory_pool_used_hwm from table (mon_get_memory_pool('DATABASE','TP1',-1)) as m1 where
memory_pool_type='UTILITY'

------------------------- -------------------- -------------------- --------------------
UTILITY 5 128 20608
The sample output shows about 20MB of utility heap memory was used to
process the row organized table by the LOAD command.
• db2 -tvf loadcols.ddl
load from hist200k.del of del messages rowload1.msg replace into MEM.COLHIST
nonrecoverable



memory_pool_used_hwm from table (mon_get_memory_pool('DATABASE','TP1',-1)) as m1 where
memory_pool_type='UTILITY'

------------------------- -------------------- -------------------- --------------------
UTILITY 5 384 42048
Notice that the LOAD processing for the column organized table used more
than twice the memory in the utility heap. This is used by the ANALYZE phase
for loading a column organized table to build the column dictionary data.
Task 2. Run some SQL based workloads to collect various
performance metrics with different database memory
allocations.
Next you will run some SQL based workloads using the minimal memory allocations for
the buffer pools and sort memory.
The file ingestsamp.ddl uses the Db2 INGEST command to process inserts and
updates to a set of tables. This is a write intensive type of processing. The file
batch1.sql contains a set of SQL SELECT statements and db2batch utility control
statements that will be used to create a read-only workload for test purposes.
• db2 terminate
• db2 -tvf ingestsamp.ddl
truncate table history drop storage immediate
ingest set commit_count 5000

DB20000I The INGEST SET command completed successfully.
ingest from file sampledata.del format delimited ( $ackey integer external ,

$telkey integer external , $brkey integer external, $balance decimal(15,2)
external ) messages ingestsamp.txt restart off update inst464.acct set (balance) =
($balance) where acct_id = $ackey


Number of rows inserted = 0

08:50:46.962109"

external ) messages ingestsamp.txt restart off update inst464.branch set (balance)
= (balance + $balance) where branch_id = $brkey


08:50:48.587133"

external ) messages ingestsamp.txt restart off update inst464.teller set (balance)
= (balance + $balance) where teller_id = $telkey


08:50:50.032668"
ingest from file hist200k.del format delimited messages ingestsamp.txt restart

off insert into inst464.history


08:50:55.400549"
The db2batch command will be used to process the SQL statements ten times.

2. In the terminal session, issue the following command (results will take time):
• db2batch -d tp1 -f batch1.sql | more
Look at the summary report at the end of the db2batch output.
* Summary Table:
--------- ----------- ----------- -------------- -------------- -------------- ---
------------ -------------- -------------- -------------
Block 1 10 82.064361 7.379350 9.014193
8.206436 8.189336 1124740 250
* Total Entries: 1
---------------------------------------------
* Timestamp: Tue Apr 17 2018 08:52:54 EDT
The sample output show a total elapsed time of 82 seconds for the read-only
processing.
Use the file mon_bpios.sql to return some buffer pool read and write statistics
for the INGEST and db2batch workloads.
• db2 -tvf mon_bpios.sql
select substr(bp_name,1,15) as bp_name, total_physical_reads, data_physical_reads,
index_physical_reads from sysibmadm.mon_bp_utilization where bp_name not like
'IBMSYSTEM%'
BP_NAME TOTAL_PHYSICAL_READS DATA_PHYSICAL_READS INDEX_PHYSICAL_READS

--------------- -------------------- -------------------- ----------------------
IBMDEFAULTBP 455507 403880 51627
TP1H16K 22650 22603 47
select substr(bp_name,1,15) as bp_name, total_writes, sync_writes_percent from

sysibmadm.mon_bp_utilization where bp_name not like 'IBMSYSTEM%'

BP_NAME TOTAL_WRITES SYNC_WRITES_PERCENT

--------------- -------------------- -------------------
IBMDEFAULTBP 22312 4.95
TP1H16K 1149 5.48
The query results show physical read and write statistics for the two buffer
pools.
Use the file dbmemory.sql to show current database memory allocations.
• db2 -tvf dbmemory.sql
memory_pool_used_hwm from table (mon_get_memory_pool('DATABASE','TP1',-1)) as m1 order by
memory_pool_id

------------------------- -------------------- -------------------- --------------------
DATABASE 2 141888 141888
LOCK_MGR 4 21120 21120
UTILITY 5 64 576
CAT_CACHE 8 640 640
BP 16 5312 5312
BP 16 5312 5312
BP 16 1792 1792
BP 16 1536 1536
BP 16 1408 1408
BP 16 1344 1344
XMLCACHE 93 192 192
The buffer pools will remain a constant size. The shared sort memory in the
sample report used a maximum size of 4MB.
Next you will adjust the memory configuration for the two buffer pools and sort
memory and then rerun the SQL processing.


• db2 -tvf memorycfg2.cmd
• db2 terminate




09:07:27.222554"



09:07:28.675187"




09:07:30.058598"



09:07:36.066941"
• db2batch -d tp1 -f batch1.sql | more

Look at the summary report at the end of the db2batch output.
* Summary Table:
--------- ----------- ----------- -------------- -------------- -------------- ---
------------ -------------- -------------- -------------
Block 1 10 21.113119 2.009236 2.648720
2.111312 2.104445 1124740 250
* Total Entries: 1
---------------------------------------------
* Timestamp: Tue Apr 17 2018 09:09:49 EDT
The sample output show a total elapsed time of 21 seconds for the read-only
processing. The additional database memory should have reduced processing
time.
Use the file mon_bpios.sql to return some buffer pool read and write statistics
for the INGEST and db2batch workloads.


• db2 -tvf mon_bpios.sql
select substr(bp_name,1,15) as bp_name, total_physical_reads, data_physical_reads,
index_physical_reads from sysibmadm.mon_bp_utilization where bp_name not like
'IBMSYSTEM%'
BP_NAME TOTAL_PHYSICAL_READS DATA_PHYSICAL_READS INDEX_PHYSICAL_READS

--------------- -------------------- -------------------- ----------------------
IBMDEFAULTBP 11916 7218 4698
TP1H16K 27 14 13
select substr(bp_name,1,15) as bp_name, total_writes, sync_writes_percent from

sysibmadm.mon_bp_utilization where bp_name not like 'IBMSYSTEM%'
BP_NAME TOTAL_WRITES SYNC_WRITES_PERCENT

--------------- -------------------- -------------------
IBMDEFAULTBP 259 0.00
TP1H16K 651 2.30
The sample report shows significant reductions in buffer pool read and write
activity to perform the same application processing.
Use the file dbmemory.sql to show current database memory allocations.


• db2 -tf dbmemory.sql
------------------------- -------------------- -------------------- --------------------
DATABASE 2 141888 141888
LOCK_MGR 4 21120 21120
UTILITY 5 64 576
CAT_CACHE 8 640 640
BP 16 163328 163328
BP 16 214080 214080
BP 16 1792 1792
BP 16 1536 1536
BP 16 1408 1408
BP 16 1344 1344
XMLCACHE 93 192 192
Use the SQL in the file dropmemtables.ddl to drop the test tables used for this
demonstration and free the allocated space.
• db2 -tvf dropmemtables.ddl
• db2 terminate
Results:
You used a set of SQL statements with Db2 monitor table functions and views
to monitor table space utilization, buffer pool efficiency, database log space
usage and application lock contention.

Unit summary
• Describe memory heap usage for instance memory, database shared
memory and application memory
• Explain the management of database shared memory based on setting
the configuration option DATABASE_MEMORY to AUTOMATIC or a
specific number of pages
• Select the mode for managing data sort memory using SORTHEAP,
and SHEAPTHRES_SHR
• Monitor Db2 memory usage using the db2mtrk commands and SQL
statements
• Utilize the db2pd command for monitoring current database memory
usage
• Describe how STMM can be used to automatically manage database
shared memory heaps
• Implement Db2 Self Tuning Memory Management (STMM) for all or
selected database memory heaps
Unit summary

Database rebuild support
Database rebuild support

Unit 4 Database rebuild support

Unit objectives
• Review the considerations of using standard Db2 database recovery
options
• Explain the capabilities of the REBUILD option for the RESTORE
command
• List the types of information included in each Db2 backup image and
describe how it is used to support rebuilding a database
• Plan for supporting database and disaster recovery scenarios using
Db2 database and table space backups using the RESTORE
command with a REBUILD option
• Utilize LIST UTILITIES SHOW DETAIL to monitor progress of a
RESTORE utility during database rebuilding
Database rebuild support © Copyright IBM Corporation 2018
Unit objectives

Database restore options without using the REBUILD option

• Disaster Recovery Support:
 Required to perform RESTORE from Database level Backup first, so regular
Database level Backup is necessary
 Can not recover Database using only table space Backups
 Need to keep Db2 system logs from oldest backup time for full recovery
• Partial Database Restore for testing or other special recovery needs:
 Scenarios include Dropped Table space, Dropped Tables, Application
Recovery to PIT before Minimum Recovery time for table spaces
 Required restoration of all table spaces in Database
 All table space containers must be large enough to hold data from the
source database level backup
 Rollforward recovery would apply changes to all table spaces
 Once database is in a normal state, any table spaces not needed could be
dropped
 Result is No quick fixes for small problems
Database restore options without using the REBUILD option

Disaster Recovery Support
The Db2 Backup Utility can be used to create a Database Backup image that contains
all table spaces in the database. For recoverable databases, the Backup utility can also
be used to create table space backups that contain one or more selected table spaces.
In a typical disaster recovery scenario, the Restore command is used to recover the
database using saved backup images.
Using the Db2 recovery facilities that were available before REBUILD was
implemented, recovering a database for disaster recovery required a Database backup
image to be restored to initialize the database. Table space level backup images could
be used to supplement the recovery processing, but a database level recovery could
not be performed using only table space backups.
If table space level backups were used as part of the disaster recovery, two roll forward
operations were required, one at the database level and a second at the tablespace
level. First the database level roll forward would process all of the table spaces,
excluding those restored at the table space level. When the database rollforward is
completed a second roll forward would be needed to apply the logged changes to any
table spaces that were restored after the database level restore.

In order to recover a database completely to the most current transactions, all Db2
system logs from the time stamp of the database backup image forward to the most
current log file would be needed. In order to maintain database recoverability, regular
database level backups would need to be scheduled.
Partial Database Restore for testing or other special recovery needs
There are several recovery scenarios where it might be useful to recover a subset of
a Db2 database:
• Dropped Table Space: Once a table space is dropped, it cannot be restored
using a table space level restore. Prior to the RESTORE REBUILD option, the
only way to recover the table space would be to restore the entire database to a
point in time prior to the beginning of the transaction that dropped the table
space.
• Dropped Tables: Db2 has a dropped table recovery facility, but the process only
handles a single dropped table. If many tables are dropped by mistake a table
space level point in time recovery cannot be used to regain access to the data. A
database level recovery to a point in time can be used to recover the dropped
tables, but without a REBUILD option the recovery could be a lengthy process for
a large database.
• Application Recovery to a PIT before the current table space Minimum
Recovery time: Create, Alter, and Drop SQL statements change the minimum
recovery time stamp for the table spaces effected by the DDL. This insures that a
table space must be recovered to a point in time that keeps catalog definitions in
synch with the table space objects. There might be cases where an application
causes table changes in error and a point in time recovery for several table
spaces might be needed but more recent applications might have updated the
minimum recovery times for one or more table spaces past the point where
recovery is needed. In this case, a point in time recovery at the database level
must be used to get the table spaces back to the time stamp needed to correct
the data problems. Without the REBUILD option of the Db2 RESTORE utility, all
of the table spaces in the database would be recovered to the same time stamp.

• Application testing using a subset of table spaces: It is common to perform

tests that require some subset of the table spaces from a database. Without the
REBUILD option, the entire database would need to be restored and rolled
forward to the desired time. Once the database is fully recovered, any extra table
spaces could be dropped. In some cases, other utilities like DB2MOVE might be
used to help create a partial copy, but this involves loading or importing the tables
which would take a long time.
In all these scenarios, the requirement to perform a full database recovery could
mean recovering 100% of a large database when only 10% might actually be
required. This increases the time and system resources needed for the recovery.

Example: Database partial copy without using REBUILD

• Must restore and roll forward ALL table spaces first
AUTOTS1 SalesDB
SalesDB
SYSCATSPACE SYSCATSPACE
DMS02
DMS01 DMS02 DMS01 AUTOTS1
Backup
Database Backup Backup Backup
Copy for
SALESDB TS DMS01 TS DMS02 TS DMS01 testing
SUN MON TUE WED THU FRI SAT
1. RESTORE DATABASE SALESDB TAKEN AT Sunday

2. RESTORE DB SALESDB TABLESPACE(DMS01) TAKEN AT Friday
3. ROLLFORWARD DB SALESDB TO END OF LOGS AND STOP
4. ROLLFORWARD DB SALESDB TO END OF LOGS
TABLESPACE(DMS01) ONLINE
5. DROP TABLESPACE DMS02,AUTOTS1
Example: Database partial copy without using REBUILD

In this example the backup images available are the same as the ones in the
previous example, but this time some application testing needs to be done and all of
the necessary tables are in the table space DMS01.
To create a copy of the database a database restore is performed using the
following steps:
1. Restore the database using the database backup image from Sunday. The
database is now in a rollforward pending state. The database is restored using
a test system so a redirected restore is not necessary to alter container
definitions.
RESTORE DATABASE SALESDB TAKEN AT Sunday
2. Since DMS01 is the only table space that is needed, the latest table space
backup of DMS01 from Friday is used to minimize the time needed for
rollforward processing. Now DMS01 is in a table space rollforward pending
state.
RESTORE DB SALESDB TABLESPACE(DMS01) TAKEN AT Friday

3. Now a database rollforward applies the logged changes from Sunday to

Friday for all table spaces, except DMS01 which is bypassed. When this
completes, the database will now be in a normal state and connections will be
allowed, but the table space DMS01 remains unavailable.
ROLLFORWARD DB SALESDB TO END OF LOGS AND STOP
4. The last step is to use a table space rollforward to apply the logged changes
to DMS01. The rollforward will apply logged changes based on the time stamp
for the table space backup of DMS01 on Friday. The database control file
DB2TSCHG.HIS is used to skip log files that do not contain changes to the
DMS01 table space. When the command completes, all table spaces will be
available for application access.
ROLLFORWARD DB SALESDB TO END OF LOG TABLESPACE(DMS01)
ONLINE
5. Now that the database is fully available, the unnecessary table spaces DMS02
and AUTOTS1 can be dropped.

REBUILD option for RESTORE

• REBUILD options for RESTORE command:
 Allows Database rebuild from several table space backups
 May reduce frequency of Database backups
 Can REBUILD a full or partial database:
− Restore critical table spaces first and less critical ones later
− ALL table spaces in DATABASE at time a backup was taken
− ALL table spaces included in a selected table space backup
− All table spaces EXCEPT a list provided in the RESTORE command
− Specific Table space list in RESTORE command
>>-RESTORE--+-DATABASE-+--source-database-alias------------>
+-REBUILD WITH--+-+-ALL TABLESPACES IN DATABASE-+--+---------+-+-+ |
'-ALL TABLESPACES IN IMAGE----‘ '-EXCEPT—
+-TABLESPACE--+--- (----tablespace-name-+--)-'
REBUILD option for RESTORE

Database rebuild
Rebuilding a database is the process of restoring a database or a subset of its table
spaces using a set of restore operations. The functionality provided with database
rebuild makes Db2 more robust and versatile, and provides you with a more
complete recovery solution.
The ability to rebuild a database from table space backup images means that you
no longer have to take as many full database backups. As databases grow in size,
opportunities for taking a full database backup are becoming limited. With table
space backup as an alternative, you no longer need to take full database backups
as frequently. Instead, you can take more frequent table space backups and plan to
use them, along with log files, in case of a disaster.
In a recovery situation, if you need to bring a subset of table spaces online faster
than others, you can use rebuild to accomplish this. The ability to bring only a
subset of table spaces online is especially useful in a both test and production
environments.

Rebuilding a database involves a series of potentially many restore operations. A

rebuild operation can use a database image, or table space images, or both. It can
use full backups, or incremental backups, or both. The initial restore operation
restores the target image, which defines the structure of the database that can be
restored (such as the table space set and the database configuration). For
recoverable databases, rebuilding allows you to build a database that is
connectable and that contains the subset of table spaces that you need to have
online, while keeping table spaces that can be recovered at a later time offline.
The RESTORE utility includes a REBUILD option.
Some of the options for using REBUILD are:
• Can REBUILD a full or partial database
• Restore critical table spaces first and less critical ones later
• ALL table spaces in DATABASE at time a backup was taken
• ALL table spaces included in a selected table space backup image
• All table spaces EXCEPT a list provided in the RESTORE command
• Specific table space list in RESTORE command

Contents of Db2 database and table space backups
Backup Media Header

---------------------------------------------------------------------
Control Files (Database Metadata)
 List of table spaces
1. Backup start timestamp in current Backup
2. List of table spaces in backup
3. Recovery History File (db2rhist.asc)  List of Db2 Backups up
4. List of all table spaces in database at time of backup
5. Database (partition) Configuration (DB CFG)
to time of current backup
6. Buffer pool configuration file
----------------------------------------------------------------------  List of ALL table spaces
Data in requested table spaces and containers in Database
----------------------------------------------------------------------
at the time of current backup
Log File Header
Log Files needed to support Online Backup (Option)  Database Configuration
options at time of Backup
Contents of Db2 database and table space backups

Db2 database and table space backup images contain control information,
sometimes referred to as metadata, in addition to the pages from the table spaces.
The additional control files that are used to help Db2 rebuild a database include the
following:
• List of table spaces in backup: If this is a database backup, the list would
include all table spaces defined to the database at the time the backup was
taken. If this is a table space backup, the list would be just the table spaces that
were listed in the backup command. This list is used for the ALL TABLESPACES
IN IMAGE option of REBUILD.
• Recovery History File (db2rhist.asc): This is a copy of the recovery history file,
which has records of the database and table space backups. This could be used
to locate the latest backup image for the table spaces that are needed to rebuild
the database. The REPLACE HISTORY FILE option of the restore command will
force this copy of the recovery history to be stored on disk, otherwise the current
history file of any existing database would be used.

• List of all table spaces in database at time of backup: This includes the table
space and container information for every table space in the database at the time
of the backup. This is used for the ALL TABLESPACES IN DATABASE option to
establish a complete list for REBUILD, even though the target image might be a
table space backup.
• Database Configuration (DB CFG): The database configuration settings at the
time the backup was created are saved in the backup image. If a new database is
being created by the restore command or if an existing database with a different
database seed is being overlaid, this will be used to set the new database
configuration. If the restore is going to overlay a database with the same seed,
the current database configuration will be retained.

Database disaster recovery using REBUILD

• Necessary table spaces will be restored automatically based on
Recovery History data
AUTOTS1
Recovery
SalesDB History File
SYSCATSPACE
DMS01 DMS02
2
3 1
Backup Database
SALESDB TS DMS01 TS DMS02 TS DMS01 Fails!
1. RESTORE DB SALESDB
REBUILD WITH ALL TABLESPACES IN DATABASE TAKEN AT Friday
(Db2 Restores Friday, Sunday and Thursday)

(Only One ROLLFORWARD needed)
Database disaster recovery using REBUILD

This is the same disaster recovery situation that was explained earlier. At the time of
the database failure these backup images were available:
1. A Database level backup on Sunday. This could be online or offline.
2. A table space level backup of DMS01 on Tuesday.
3. A table space level backup of DMS02 on Thursday.
4. A more recent table space level backup of DMS01 on Friday.
The database needs to be restored on Friday evening. This time a Restore
command with the rebuild option will be used. The steps would be:
1. Issue a single Restore command with the REBUILD option pointing to the
latest backup image available, the table space backup of DMS01 from Friday.
RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN
DATABASE TAKEN AT Friday
The Restore Utility would use the complete list of table spaces in the database
at the time of the Friday table space backup of DMS01 to establish the list
table spaces needed to rebuild the database.
Using the target backup image the data for the table space DMS01 would be
restored. The recovery history file would be scanned to locate the most recent
backup image for the other table spaces.

The table spaces SYSCATSPACE and AUTOTS1 would be automatically

restored using the database backup image taken on Sunday. Next the table
space DMS02 would be restored automatically using the table space backup
from Thursday.
Now that all of the table spaces have been restored from some backup, the
Restore Utility is considered complete.
2. Now a single database rollforward can be used to apply the logged changes
from Sunday to Friday for ALL table spaces. The logs will be processed from
the oldest backup image used forward to the end of logs, but the starting point
for each table space would depend on the image used for that table space.
For example, the rollforward would only need to apply changes to DMS02
from Thursday and Friday.
When the command completes, all table spaces will be available for
application access.
This is a much simpler sequence of commands than those needed to perform a
similar recovery described earlier. In this case, only one backup image was
specifically selected, the others were automatically chosen. This is similar to the
processing of an automatic incremental restore.

Database recovery: Rebuild from TS backups

• Database Recovery using multiple table space backups
AUTOTS1
Recovery
SYSCATSPACE SalesDB History File
DMS01 DMS02
2 3 1
Backup
Backup
Backup
Database
TS AUTOTS1
TS DMS02
SYSCATSPACE
TS DMS02 Backup Fails !
DMS01 DMS01 TS DMS01
REBUILD WITH ALL TABLESPACES IN DATABASE TAKEN AT Friday
(Db2 Restores Friday, Tuesday and Thursday)

Database recovery: Rebuild from TS backups

This is a slightly different disaster recovery situation. In this case the database will
be rebuilt completely using table space backup images. At the time of the database
failure these backup images were available:
1. A Database level backup on Sunday. This could be online or offline.
2. A table space level backup of AUTOTS1 and SYSCATSPACE on Tuesday.
3. A table space level backup of DMS02 and DMS01 on Thursday.
4. A table space level backup of DMS01 on Friday.
The database needs to be restored on Friday evening. This time a Restore
command with the rebuild option will be used. The steps would be:
This is exactly the same command used in the previous example but the list of
backups available is different.
DATABASE TAKEN AT Friday
The Restore utility would use the complete list of table spaces in the database
at the time of the Friday table space backup of DMS01 to establish the list of
table spaces needed to rebuild the database.

Using the target backup image, the data for the table space DMS01 would be
backup image for each of the other table spaces.
The table spaces SYSCATSPACE and AUTOTS1 would be automatically
restored using the table space backup image from Tuesday. Next the table
space DMS02 would be restored automatically using the table space backup
from Thursday.
Now that all of the table spaces have been restored from some backup, the
Restore Utility is considered complete.
2. Again, a single database rollforward can be used to apply the logged changes
from Tuesday to Friday for ALL table spaces. Having the table space backup
of SYSCATSPACE and AUTOTS1 from Tuesday would reduce the number of
logs needed compared to the previous example.
When the command completes, all table spaces will be available for
application access.
So a complete database recovery has been performed using a single RESTORE
command and no database level backup image was used.

Database partial copy using REBUILD

• Can create a Database copy with a subset of table spaces
AUTOTS1
SalesDB SalesDB
DMS01 DMS02 DMS01
2
1
Copy for
Backup testing
SALESDB TS DMS01 TS DMS02 TS DMS01

REBUILD WITH TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Friday
(Db2 Restores Friday, and Sunday (just SYSCATSPACE TS)
OR
RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN DATABASE
EXCEPT TABLESPACE(AUTOTS1,DMS02) TAKEN AT Friday

Database partial copy using REBUILD

In this example, some application testing is scheduled for Saturday that only needs
tables in the DMS01 table space. The backup images available are the following:
1. A Database level backup on Sunday.
2. A table space level backup of DMS01 on Tuesday.
3. A table space level backup of DMS02 on Thursday.
4. A more recent table space level backup of DMS01 on Friday.
The database for testing will be restored on Friday evening. A Restore command
with the rebuild option will be used. The steps would be:
The command will include options to specify that only DMS01 and the catalog
table space SYSCATSPACE will be needed.
Either of the following two commands could be used:
RESTORE DB SALESDB REBUILD WITH
TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Friday
DATABASE EXCEPT TABLESPACE(AUTOTS1,DMS02) TAKEN AT Friday

The Restore utility would use the supplied list of table spaces provided in the
command to rebuild the database. SYSCATSPACE must always be included
for a partial database rebuild.
Using the target backup image, the data for the table space DMS01 would be
backup image for the SYSCATSPACE.
The table space SYSCATSPACE would be automatically restored using the
database backup image taken on Sunday.
Now that all of the table spaces requested have been restored from some
backup, the Restore utility is considered complete. The table spaces SMS01
and DMS02 are in a restore pending status and the containers for those table
spaces have not been allocated.
2. A single database rollforward can be used to apply the logged changes from
Sunday to Friday for the SYSCATSPACE table space. The rollforward would
only need to apply changes to DMS01 from Friday forward.
When the command completes, the table spaces SYSCATSPACE and DMS01
will be available for application access.
This is a much simpler sequence of commands than those needed to perform a
similar recovery without the REBUILD option. The time required to restore and apply
the logs to the table spaces that are not required has been eliminated and the disk
space required might be significantly reduced as well.

Database rebuild using one TS backup image

• Can create a partial database copy from one table space Backup
SYSCATSPACE
Backup AUTOTS1
TS DMS01
SalesDB SalesDB
SYSCATSPACE
SYSCATSPACE
DMS01 DMS02 DMS01

1
Backup Backup
Database Backup Backup TS DMS01
Copy for
SALESDB TS DMS01 TS DMS02 SYSCATSPACE testing
1. RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN IMAGE

TAKEN AT Friday
Database rebuild using one TS backup image

In the previous example, a partial database copy was built using the backup images
that were already available. A better solution would be to create a new table space
backup that only contains the table spaces that are needed for testing. So in this
case a table space backup that includes SYSCATSPACE and DMS01 is created on
Friday.
The database for testing will be restored on Friday evening. A Restore command
with the rebuild option will be used. The steps would be:
1. Issue a single Restore command with the REBUILD option using a target of
the table space backup of SYSCATSPACE and DMS01 taken on Friday. The
command will include options to specify that the database should only include
the table spaces contained in the backup image.
The following command could be used:
RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN IMAGE
TAKEN AT Friday
The Restore utility would use the list of table spaces in the header of the
backup image to rebuild the database. SYSCATSPACE must always be
included for a partial database rebuild.

Using the target backup image the data for both table spaces DMS01 and
SYSCATSPACE would be restored. No additional automatic restores would be
necessary.
Now that the table spaces requested have been restored using the single
backup image, the Restore Utility is considered complete. The table spaces
AUTOTS1 and DMS02 would actually be listed in a query result using
MON_GET_TABLESPACE but they would be in a restore pending status and
the containers for those table spaces have not been allocated.
2. A database rollforward would be used to apply the logged changes starting on
Friday for the two table spaces, SYSCATSPACE and DMS01. Changes to the
other table spaces would be ignored.
will be available for application access.
This technique would have two advantages:
1. The restore would take less time because only a single table space backup
needs to be restored. In the previous example, SYSCATSPACE was restored
by reading a full database backup image that might be very large.
2. The rollforward processing would be minimal, because only log files starting at
the time stamp of the table space backup on Friday would need to be
processed.

Nonrecoverable database partial restore REBUILD

• Nonrecoverable Database only allows Offline Database Backups
AUTOTS1
SalesDB SalesDB
DMS01 DMS02 DMS01
2 1
Backup Backup Backup

Copy for
Database Database Database testing
SALESDB SALESDB SALESDB
Incremental Incremental
1. RESTORE DB SALESDB REBUILD WITH ALL TABLESPACES IN DATABASE

EXCEPT TABLESPACE(AUTOTS1,DMS02) TAKEN AT Thursday
Database is now available, AUTOTS1 AND DMS02, are in DROP PENDING status
Nonrecoverable database partial restore REBUILD

A nonrecoverable Db2 database uses circular logging rather than archiving the logs
for use in rollforward processing. Only offline database backups are allowed for
nonrecoverable databases. This limits the options for using the Restore Utility
REBUILD option because no table space level backups can be used and the
rollforward command cannot be used to reprocess logged changes.
In this example, a nonrecoverable database named SALESDB has several backup
images available.
1. A Full offline Database backup taken on Sunday.
2. An Incremental offline Database backup taken on Tuesday.
3. A second Incremental offline Database backup taken on Thursday.

If an application test needs a database copy of SALESDB, but only needs tables in
the table space DMS01, a partial database rebuild can be performed using the
existing Db2 incremental backup images. The database for testing will be restored
on Friday evening. A Restore command with the rebuild option will be used. The
steps would be:
1. Issue a single Restore command with the REBUILD option using a target of
the incremental database backup taken on Thursday. The command will
include options to specify that the database should only include the table
spaces SYSCATSPACE and DMS01.
DATABASE EXCEPT TABLESPACE(AUTOTS1,DMS02) TAKEN AT
Thursday
The Restore utility would read the target backup image and find that it was an
Incremental database backup. Db2 would perform an automatic incremental
restore process. This would scan the recovery history to locate the necessary
backup images, which in this case would include the full database backup
taken on Sunday. The two backup images would be restored to bring the
database up to the point of the offline backup from Thursday, but only copy the
data from the selected table spaces, SYSCATSPACE and DMS01 to disk.
Now that the table spaces requested have been restored, the Restore utility is
considered complete. No rollforward is possible for a nonrecoverable
database, so the database is now available for access.
The table spaces AUTOTS1 and DMS02 would be listed in a query result
using the MON_GET_TABLESPACE function, but they would be in a drop
pending status and the containers for those table spaces have not been
allocated. Since nonrecoverable databases do not allow table space level
restores, there is no way to restore AUTOTS1 or DMS02. The DROP
TABLESPACE statement can be used to remove the table spaces from this
database copy. Having table spaces in drop pending status would not prevent
testing using tables in the DMS01 table space.

Table space point in time recovery using REBUILD

• Can restore catalogs and selected table spaces to any PIT
AUTOTS1
SYSCATSPACE SalesDB SalesDB
SYSCATSPACE Tuesday
DMS01 DMS02
DMS01
2
1
Backup
SALESDB TS DMS01 TS DMS02 TS DMS01
REBUILD WITH TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Tuesday
(Db2 Restores Tuesday, and Sunday (just SYSCATSPACE TS)
2. ROLLFORWARD DB SALESDB TO Tuesday AND STOP
Table space point in time recovery using REBUILD

There are a number of recovery scenarios where a table space point in time
recovery cannot be performed. Some examples are:
• A dropped table space
• A large number of Dropped tables
• When the point in time recovery required is a time stamp prior to the current
minimum recovery time for a table space
In these cases, the REBUILD option of RESTORE might be used to recover a
subset of table spaces in a new database that could be used to facilitate recovery
operations. For example, what if the table space DMS01 is accidentally dropped.
Since Db2 will not allow this table space to be restored using a table space restore,
a partial database recovery could be performed that would build a database copy
that would have the table space DMS01 and the Db2 catalogs back at a timestamp
just before the drop table space occurred. Other Db2 utilities like db2look, db2move,
export or load would then be able to capture and reload the lost tables.

In the example shown, an application error caused the tables in DMS01 to contain
invalid data some time on Tuesday. There is a need to get a copy of the
application's tables from the time just before the application started processing on
Tuesday. Applications have altered the objects in the DMS01 table space since
Tuesday so its current minimum recovery time is a timestamp with a date of Friday.
A Restore command with the rebuild option will be used. The steps would be:
1. Issue the Restore command with the REBUILD option using a target of a table
space backup of DMS01 taken on Tuesday, some time before the application
began processing. The command will include options to specify that the
database should only include the table spaces SYSCATSPACE and DMS01.
RESTORE DB SALESDB REBUILD WITH
TABLESPACE(SYSCATSPACE,DMS01) TAKEN AT Tuesday
Using the target backup image the data for the DMS01 table space would be
restored. The recovery history records would be used to locate the database
backup image taken on Sunday as the source for restoring the
SYSCATSPACE table space, which would be also be restored.
Now that the table spaces requested have been restored the Restore Utility is
considered complete. The table spaces AUTOTS1 and DMS02 would be listed
in a query result using MON_GET_TABESPACE, but they would be in a
restore pending status and the containers for those table spaces have not
been allocated.
2. A database roll forward would be used to apply the logged changes to the
SYSCATSPACE and DMS01 table spaces as needed up to a specified time
stamp. Changes to the other table spaces would be ignored. The point in time
specified would need to be at least to the end of the target backup image
specified in the RESTORE command.
ROLLFORWARD DB SALESDB TO Tuesday AND STOP
will be available for application access in the rebuilt database.

Considerations for using RESTORE with REBUILD (1 of 2)

• Backup image in RESTORE command is the Target for the rebuild:
 All other backups automatically restored will be ones that preceded the
target time.
 Backup Images taken from current recovery history file.
 Can use REPLACE HISTORY FILE option of RESTORE to copy recovery
history from target image
 Incremental and Delta backup images can be used for REBUILD
 SYSCATSPACE table space must ALWAYS be included for partial
database rebuilding
• Database is in Rebuild Phase when Restore command with REBUILD
option completes:
 Additional backups could be restored manually before roll forward starts
 Once ROLLFORWARD command is issued, the Rebuild phase is
completed
 Table spaces manually restored using a backup with a timestamp newer
than the target timestamp will require a second ROLLFORWARD for those
table spaces
Considerations for using RESTORE with REBUILD

When a RESTORE command is invoked with the REBUILD option, the Backup
image referred to in the command is considered the Target for the database rebuild.
This is very important to the processing done for rebuilding the database.
• All other backups automatically restored will be ones that preceded the target
time. This means that Db2 will scan the recovery history for the most recent
backup of the table spaces that will be in the rebuilt database and those backups
must have been taken some time before the backup image that was the target.
This is done to allow for a rollforward to a point in time that might be just after the
end of the target backup.
• The Backup Images that can be automatically restored will be listed in the current
recovery history file. This means that if the database REBUILD is going to overlay
an existing database, the recovery history from that database would provide the
list of backups that could be used. In some cases the REPLACE HISTORY FILE
option of RESTORE might be necessary to copy the recovery history data from
the target image to disk so that a valid list of backup images is available for
selection during rebuilding.

• When the processing for the RESTORE command with the REBUILD option
completes, the database is considered to be in a special Rebuild Phase. This
means that additional manual restores could be performed prior to starting the
rollforward. These might be necessary if one or more backup images could not be
located based on information in the recovery history. As long as the backup
images were from time stamps prior to the time stamp of the target backup, the
table spaces could still be recovered using a single database rollforward
command. If any of the manual backups had a time stamp greater than the target
time stamp, these table spaces would not be processed during the database
rollforward, but could be recovered using a table space level rollforward.
• Once the database rollforward command is issued, the Rebuild Phase is
considered complete. Any subsequent table space restores would require a table
space rollforward for recovery.
The target image can be an Incremental or Delta backup image. Db2 might restore
other incremental or delta backup images found in the recovery history file
automatically if they are the most recent copy of one of the required table spaces.
This will help to reduce rollforward processing. It is not necessary to include the
INCREMENTAL AUTOMATIC option on the RESTORE command if the target image
is an incremental or delta backup. If the INCREMENTAL option is specified without
AUTO or AUTOMATIC, it is assumed that a manual incremental restore is desired
for some reason. Since this might add considerable complexity, this is not
recommended.
The table space for the Db2 system catalogs, SYSCATSPACE table space must
always be included for partial database rebuilding.

Considerations for using RESTORE with REBUILD (2 of 2)

• For Partial Database REBUILD all Excluded table spaces will be in a
Restore Pending status:
 These table spaces can be restored later if needed
 DROP any table spaces that are not needed
 Excluded table spaces in nonrecoverable database will be in Drop Pending
• REBUILD can be used with Database Partitioning (DPF):
 Need to include SYSCATSPACE table space for CATALOG partition
 One RESTORE with REBUILD for each database partition
 Each rebuild would be based on the recovery history file for that partition
• REDIRECT option can be used to change table space containers:
 Table Space List is based on those in Database at the time of target image
 Only need to supply SET TABLESPACE containers for table spaces
included in a partial rebuild
 Automatic Storage table space containers could be altered using SET
STOGROUP PATHS statements
 REDIRECT GENERATE SCRIPT option can be used
When the RESTORE utility is used to rebuild a partial database, the database will
have a table space list equal to the table spaces contained in the database at the
time of the target backup image. Any table spaces excluded during the rebuilding of
the database will be in a Restore Pending status. These table spaces could be
restored once the database is available using online table space restores. If there is
not a need for the table spaces in the rebuilt copy of the database, those table
spaces could be dropped. If the database rebuild was done using a non-recoverable
database, the excluded table spaces will be left in a Drop Pending status and the
only option is to drop the table spaces. A database backup of the new database
cannot be made with any table space in a Restore Pending or Drop pending status.
A Db2 database that uses the Database Partitioning option DPF can also be
partially or fully rebuilt using the REBUILD option. In this case, there would be one
Restore Utility per database partition with the REBUILD option to get the database
to the point where the database rollforward processing could begin. Any partial
database rebuild would require the SYSCATSPACE table space to be included
when the catalog partition is rebuilt. Non-catalog partitions do not have the
SYSCATSPACE table space. There is one recovery history file for each database
partition, so the rebuild processing at each partition would be based on its recovery
history contents.

The RESTORE command with a REBUILD option can also include the REDIRECT
option to modify some or all of the container definitions in the rebuilt database. The
SET TABLESPACE CONTAINERS commands would only need to be run to assign
valid containers for the table spaces that will be included in a partial database
rebuild. The table space list for the database would be those table spaces that
existed at the time of the 'target' backup image. Any automatic storage table spaces
included would be automatically assigned new containers unless the table space
was excluded. For Automatic Storage group managed table spaces, SET
STOGROUP PATHS statements can adjust disk paths for automatic storage
containers.
A RESTORE command with the REDIRECT GENERATE SCRIPT option can be
used to create a file that would have a complete set of SET TABLESPACE
CONTAINERS commands, which can be easily edited to make sure all required
table spaces have valid containers.

Monitoring database rebuild

ID = 109
Type = RESTORE
Database Name = TP1
Member Number = 0
Description = automatic db rebuild USERSPACE1...
Start Time = 05/07/2016 10:57:57.130299
State = Executing
Phase Number = 1
Total Work = 25751552 bytes
Completed Work = 25751552 bytes
Start Time = 05/07/2016 10:57:57.130302
Phase Number [Current] = 2
Description = 20160507104343
Start Time = 05/07/2016 10:59:16.797215
Phase Number = 3
Description = 20160507104711
Start Time = Not Started
Monitoring database rebuild

A RESTORE with the REBUILD options could cause many backup images to be
restored automatically. The LIST UTILITIES SHOW DETAILS can be used to show
the current processing phase. It would also list the backup image timestamps that
would be part of the rebuild.
The sample output shown in the visual indicates that the second of three RESTORE
operations is currently being performed. The Description text includes the
timestamps for the backup images.

LIST HISTORY for RESTORE with REBUILD

• One record for each table space restore performed
• One record for each database restore with REBUILD
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ --------------

R D 20160507105757 R S0000000.LOG S0000018.LOG 20140507105116
----------------------------------------------------------------------------
Contains 6 tablespace(s):
00001 SYSTOOLSPACE
00002 TP1ACCTI
00003 TP1ACCTD
00004 TP1HIST
00005 TP1SMALL
00006 SYSCATSPACE
----------------------------------------------------------------------------
Comment: REBUILD TP1 WITH RF
Start Time: 20160507105757
End Time: 20140507105926
Status: A
----------------------------------------------------------------------------
LIST HISTORY for RESTORE with REBUILD

Since a RESTORE command with the REBUILD option might actually process a
large number of database and table space backup images during its processing, a
group of records will be written to the recovery history file for the database.
There will be one record written for each backup image that is processed to restore
one or more table spaces.
For example:
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log
Backup ID
-- --- ------------------ ---- --- ------------ ------------ ------
--------
R D 20060803144424001 F
20060803143742
-------------------------------------------------------------------
---------
00001 TP1HIST
-------------------------------------------------------------------
---------

Comment: RESTORE TP1 WITH RF

Start Time: 20060803144424
End Time: 20060803144537
Status: A
-------------------------------------------------------------------
---------
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup
ID
-- --- ------------------ ---- --- ------------ ------------ ------
--------
R P 20060803144537001 F
20060803140132
-------------------------------------------------------------------
---------
00001 TP1ACCTI
00002 TP1SMS
00003 USERSPACE1
00004 SYSCATSPACE
-------------------------------------------------------------------
---------
Start Time: 20060803144537
End Time: 20060803144554
Status: A
-------------------------------------------------------------------
---------
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup
ID
-- --- ------------------ ---- --- ------------ ------------ ------
--------
R P 20060803144554001 F
20060803143453
-------------------------------------------------------------------
---------
00001 TP1ACCTD

-------------------------------------------------------------------
---------
Start Time: 20060803144554
End Time: 20060803144604
Status: A
--------------------------------------------------------------
--------------
There will also be one record written that lists all of the table spaces restored during
the rebuilding of the database.
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log
Backup ID
-- --- ------------------ ---- --- ------------ ------------ ------
--------
R D 20060803144424 R S0000171.LOG S0000184.LOG
20060803143742
-------------------------------------------------------------------
---------
00001 TP1ACCTI
00002 TP1ACCTD
00003 TP1HIST
00004 TP1SMS
00005 USERSPACE1
00006 SYSCATSPACE
-------------------------------------------------------------------
---------
Start Time: 20060803144424
End Time: 20060803144605
Status: A
-------------------------------------------------------------------
---------

Demonstration 1
Rebuilding a database
• Utilize one or more table space level backup images to rebuild a

database using the REBUILD option of the RESTORE command.
• Recover a subset of the table spaces in a database using the
REBUILD option of the RESTORE utility.
• Review the records in the database recovery history file generated by
a database rebuild using the LIST HISTORY command.
Demonstration 1: Rebuilding a database

Demonstration 1:
Rebuilding a database
Purpose:
This demonstration will show you how to restore a database using a series of
table space level backup images. You will use the Db2 command line
processor to run BACKUP, RESTORE, and ROLLFORWARD commands that
initially recover a subset of a Db2 database. The remaining table space is later
recovered using a table space level restore.
Task 1. Create a series of table space backups that will be

used later to rebuild the database.
Important Note: This demonstration uses a database named TP1 which is loaded with
test tables in the Db2 instance inst464. You need to logon to the Linux system using
the instance owner id: inst464.
ibm2blue.
In order to rebuild a database using table space backup images, you will need
to create several table space level backups for the TP1 database. First, you will
list the table space names and storage management types. A SQL query can
be used to list this information.
The file listtbsp.sql contains a query that accesses the monitor function
MON_GET_TABLESPACE to get the names and characteristics of the table
spaces for the TP1 database.


• cd $HOME/bin
• db2start
• db2 -tvf listtbsp.sql
select substr(tbsp_name,1,24) as tbsp_name,
tbsp_id, tbsp_type,
case (tbsp_using_auto_storage) when 1 then 'Yes' else 'No' end
as Auto_Storage
from table(MON_GET_TABLESPACE('',-2)) as TBSP
order by tbsp_id
TBSP_NAME TBSP_ID TBSP_TYPE AUTO_STORAGE

------------------------ -------------------- ---------- ------------
SYSCATSPACE 0 DMS Yes
TEMPSPACE1 1 SMS Yes
USERSPACE1 2 DMS Yes
TP1SMALL 3 DMS Yes
TP1HIST 4 DMS No
TP1ACCTD 5 DMS No
TP1ACCTI 6 DMS Yes
SYSTOOLSPACE 7 DMS Yes
First, you will create a table space backup of the catalog table space,
SYSCATSPACE, the default user table space, USERSPACE1 and the system
utility table space SYSTOOLSPACE. Use the $HOME/backups/u4 directory for
this backup.
• db2 " backup db tp1
tablespace(syscatspace,userspace1,systoolspace) online to
$HOME/backups/u4 compress "
Record the date and time stamp returned by the Backup utility.
Run the command file newtab.ddl to create a new table named histcopy in the
USERSPACE1 table space and load some rows using INGEST. This will add a
new object, a table named histcopy, to the USERSPACE1 table space and
update the catalog tables in the SYSCATSPACE table space.


• db2 -tvf newtab.ddl
create table histcopy like history in userspace1
INGEST SET COMMIT_COUNT 5000

INGEST FROM FILE /home/inst464/bin/hist200k.del FORMAT DELIMITED messages

INGEST_msg.txt INSERT INTO inst464.HISTCOPY


10:45:42.530405"
select count(*) as histcopy_row_count from histcopy
HISTCOPY_ROW_COUNT
------------------
200000
Next create a backup for the table spaces that hold the ACCT table,
TP1ACCTD and TP1ACCTI. Also include the table space TP1SMALL that
holds the BRANCH and TELLER tables. Use the $HOME/backups/u4 directory
for this backup.
• db2 " backup db tp1 tablespace(tp1acctd,tp1accti,tp1small) online to
Next, you will use the command file ingestsamp.ddl to perform updates to the
ACCT, BRANCH, and TELLER tables using a set of transactions with the
INGEST utility.


external ) messages ingest1.txt restart off update inst464.acct set (balance) =


15:17:41.789689"

external ) messages ingest2.txt restart off update inst464.branch set (balance) =
(balance + $balance) where branch_id = $brkey


15:17:42.987018"

external ) messages ingest1.txt restart off update inst464.teller set (balance) =
(balance + $balance) where teller_id = $telkey


15:17:44.268137"
Now run a backup for the TP1HIST and TP1SMALL table spaces. Use the
$HOME/backups/u4 directory for this backup.


• db2 " backup db tp1 tablespace(tp1small,tp1hist) online to
Task 2. Rebuild the database using the REBUILD option of the
RESTORE Utility.
List the current table space container for all table spaces using the SQL
provided in the file listcontainers.sql.
• db2 -tvf listcontainers.sql
select tbsp_id as TS_ID,
substr(tbsp_name,1,20) as TS_name , container_type ,
substr(container_name,1,60) as container_name , total_pages
from table(mon_get_container('',-2)) as cont
order by tbsp_id, container_id
TS_ID TS_NAME CONTAINER_TYPE CONTAINER_NAME

TOTAL_PAGES
-------------------- -------------------- ---------------- -----------------------
------------------------------------- --------------------
0 SYSCATSPACE FILE_EXTENT_TAG
/dbauto/path1/inst464/NODE0000/TP1/T0000000/C0000000.CAT 32768
1 TEMPSPACE1 PATH
/dbauto/path1/inst464/NODE0000/TP1/T0000001/C0000000.TMP 1
2 USERSPACE1 FILE_EXTENT_TAG
/dbauto/path1/inst464/NODE0000/TP1/T0000002/C0000000.LRG 8192
3 TP1SMALL FILE_EXTENT_TAG
4 TP1HIST FILE_EXTENT_TAG
/database/inst464/NODE0000/SQL00001/tp1hist 5000
5 TP1ACCTD FILE_EXTENT_TAG
/database/inst464/NODE0000/SQL00001/tp1acctd 20000
6 TP1ACCTI FILE_EXTENT_TAG
7 SYSTOOLSPACE FILE_EXTENT_TAG

The RESTORE utility progress can be monitored using the LIST UTILITIES
command. A second terminal session will be needed to run the command while
the RESTORE UTILITY is processing.
Start a second terminal session and run the following command once. No
output is expected since there are no active utilities.
2. Open a second terminal session, and issue the following command:
• db2 list utilities show detail
The last table space backup image will be used as the target for the database
rebuild function of the RESTORE utility. The file lastbackupid.sql can be used
to list the most recent backup, using the SYSIBMADM.DB_HISTORY view. The
table space, USERSPACE1, will be excluded from the REBUILD operation to
demonstrate the option to restore a subset of the table spaces for a database.
The database will need to be deactivated before the RESTORE utility can be
started.
3. In the first terminal session, issue the following commands:
• db2 -tvf lastbackupid.sql
select start_time as backup_taken_at ,
substr(location,1,40) as backup_location , substr(tbspnames,1,80) as
table_spaces_in_backup
from sysibmadm.db_history
where operation = 'B' order by start_time desc fetch first 1 row only
BACKUP_TAKEN_AT BACKUP_LOCATION TABLE_SPACES_IN_BACKUP

--------------- ---------------------------------------- -------------------------
-------------------------------------------------------
20161031152233 /home/inst464/backups/u4 'TP1HIST', 'TP1SMALL'
• db2 force application all

• db2 terminate
• db2 "restore db tp1 rebuild with all tablespaces in database except
tablespace(userspace1) from $HOME/backups/u4 taken at timestamp"
(Use the timestamp returned by the recovery history query you just ran; refer to
Task 1, Step 8 for the same value. If prompted, enter "y" and press Enter.)

While the restore command is processing, switch to the other terminal session
and run the LIST UTILITIES command several times until you get information
returned.
4. In the second terminal session, issue the following command:
• db2 list utilities show detail
NOTE: If the restore has already been completed before you have entered the
db2 list utilities show detail command, you will not be able to see the following
output.
inst464@ibmclass:~/Desktop> db2 list utilities show detail
ID = 20
Type = RESTORE
Database Name = TP1
Member Number = 0
Description = automatic db rebuild USERSPACE1...
Start Time = 10/31/2016 15:35:58.004647
State = Executing
Phase Number = 1
Start Time = 10/31/2016 15:35:58.004652

Description = 20161031145240
Start Time = 10/31/2016 15:36:24.824038
Phase Number = 3
Description = 20161031150242
Notice that the descriptions show the backup timestamps for the backup images
that were selected by Db2 for the database rebuild.
The database TP1 is now in a rollforward pending status. Issue a rollforward
command to apply all of the logged changes to the TP1 database and allow
applications to gain access to the restored database.

In the first terminal session, issue the following commands:

• db2 rollforward db tp1 to end of logs and stop
The rollforward should complete, but a SQL1271W warning message is issued
because the table space USERSPACE1 was not recovered during this
processing.
Connect to the TP1 database and run a SQL query to check tablespace status
of all of the table spaces.
• db2 -tvf checktspall.sql
tbsp_id, substr(tbsp_state,1,40) as tbsp_state
from table( MON_GET_TABLESPACE(NULL,-2)) as montbsp
order by tbsp_id
TBSP_NAME TBSP_ID TBSP_STATE

------------------------ -------------------- --------------------------
SYSCATSPACE 0 NORMAL
TEMPSPACE1 1 NORMAL
USERSPACE1 2 RESTORE_PENDING
TP1SMALL 3 NORMAL
TP1HIST 4 NORMAL
TP1ACCTD 5 NORMAL
TP1ACCTI 6 NORMAL
SYSTOOLSPACE 7 NORMAL
Look for the following information in the report.
What is the Tablespace State of the USERSPACE1 table space?
The tablespace USERSPACE1 is in a RESTORE PENDING status, so it is
defined but not available for access.
Use the query in the file listcontainers.sql to check for any disk space
allocation associated with the table space USERSPACE1.


• db2 -tf listcontainers.sql

TOTAL_PAGES
-------------------- -------------------- ---------------- -----------------------
------------------------------------- --------------------
0 SYSCATSPACE FILE_EXTENT_TAG
/dbauto/path1/inst464/NODE0000/TP1/T0000000/C0000000.CAT 32768
1 TEMPSPACE1 PATH
/dbauto/path1/inst464/NODE0000/TP1/T0000001/C0000000.TMP 1
3 TP1SMALL FILE_EXTENT_TAG
4 TP1HIST FILE_EXTENT_TAG
/database/inst464/NODE0000/SQL00001/tp1hist 5000
5 TP1ACCTD FILE_EXTENT_TAG
/database/inst464/NODE0000/SQL00001/tp1acctd 20000
6 TP1ACCTI FILE_EXTENT_TAG
7 SYSTOOLSPACE FILE_EXTENT_TAG
Notice that no containers are listed for the USERSPACE1 table space, so no
disk space is currently allocated.
Use the LIST HISTORY command to show the records generated by the
rebuilding of the database by the previous RESTORE command. The records
will be at the end of the report with a operation type (Op) of R.


• db2 list history backup all for tp1
The output should include information similar to the following:

-- --- ------------------ ---- --- ------------ ------------ --------------
R D 20170824124856001 F 20170824124358
----------------------------------------------------------------------------
00001 TP1SMALL
00002 TP1HIST
----------------------------------------------------------------------------
Start Time: 20170824124856
End Time: 20170824124903
Status: A
----------------------------------------------------------------------------
EID: 24 Location:

-- --- ------------------ ---- --- ------------ ------------ --------------
R P 20170824124903001 F 20170824124027
----------------------------------------------------------------------------
00001 SYSTOOLSPACE
00002 SYSCATSPACE
----------------------------------------------------------------------------
Start Time: 20170824124903
End Time: 20170824124907
Status: A
----------------------------------------------------------------------------
EID: 25 Location:


-- --- ------------------ ---- --- ------------ ------------ --------------
R P 20170824124907001 F 20170824124215
----------------------------------------------------------------------------
00001 TP1ACCTI
00002 TP1ACCTD
----------------------------------------------------------------------------
Start Time: 20170824124907
End Time: 20170824124908
Status: A
----------------------------------------------------------------------------
EID: 26 Location:

-- --- ------------------ ---- --- ------------ ------------ --------------
R D 20170824124856 R S0000000.LOG S0000011.LOG 20170824124358
----------------------------------------------------------------------------
00001 SYSTOOLSPACE
00002 TP1ACCTI
00003 TP1ACCTD
00004 TP1HIST
00005 TP1SMALL
00006 SYSCATSPACE
----------------------------------------------------------------------------
Start Time: 20170824124856
End Time: 20170824124908
Status: A
----------------------------------------------------------------------------
EID: 27 Location:

There are four records at the end in the LIST HISTORY report that were
generated by the single RESTORE command with the REBUILD option. The
records all have R for restore in the Op column.
• The first record has an Obj type of D for database. This shows the two table
spaces, TP1SMALL and TP1HIST, being restored from the target backup
image.
• The next record has an Obj type of P for table space. This shows the
SYSCATSPACE and SYSTOOLSPACE table spaces being restored. Notice
that the table space USERSPACE1, which was included in that backup
image, was not restored.
• The next record also has an Obj type of P for table space. This shows the
TP1ACCTI and TP1ACCTD table spaces being restored. The backup image
selected was the most recent table space backup.
• The next record also has an Obj type of D for database, with an R in the
Type column, indicating a Database Rebuild type of restore. This shows all
of the table space names were included during the database rebuild. The
USERSPACE1 table space was not included.
Task 3. Complete the database recovery by restoring the
excluded table space, USERSPACE1.
The table space, USERSPACE1, was excluded during the database rebuild operation.
We could drop the table space now if the data is no longer needed. This might be done
if the rebuilt TP1 database was being used to test with a subset of the tables. The table
space, USERSPACE1, is currently in a Restore Pending status.
Use the RESTORE utility to recover the table space USERSPACE1 from the backup
image created in Task 1, Step 4. The SQL query in the file checktspu.sql can be used
to display the current table space status of USERSPACE1.
• db2 -tvf checktspu.sql

select substr(tbsp_name,1,14) as tbsp_name, tbsp_id,
substr(tbsp_state,1,40) as tbsp_state
from table( MON_GET_TABLESPACE('USERSPACE1',-2)) as montbsp

-------------- -------------------- -------------------------------
USERSPACE1 2 RESTORE_PENDING
• db2 " restore database tp1 tablespace(userspace1) online from
$HOME/backups/u4 taken at timestamp "
(Use the timestamp recorded in Section 1, Step 4)
• db2 -tvf checktspu.sql
select substr(tbsp_name,1,14) as tbsp_name, tbsp_id,
substr(tbsp_state,1,40) as tbsp_state
from table( MON_GET_TABLESPACE('USERSPACE1',-2)) as montbsp

-------------- -------------------- -------------------------------
USERSPACE1 2 ROLLFORWARD_PENDING
Now complete the recovery by applying the logged changes to the
USERSPACE1 table space using a ROLLFORWARD command. Make sure
that all table spaces in the database are in a normal status.


• db2 rollforward database tp1 to end of logs tablespace online
• db2 -tvf checktspall.sql
tbsp_id, substr(tbsp_state,1,40) as tbsp_state
from table( MON_GET_TABLESPACE(NULL,-2)) as montbsp
order by tbsp_id

------------------------ -------------------- ---------------------
SYSCATSPACE 0 NORMAL
TEMPSPACE1 1 NORMAL
USERSPACE1 2 NORMAL
TP1SMALL 3 NORMAL
TP1HIST 4 NORMAL
TP1ACCTD 5 NORMAL
TP1ACCTI 6 NORMAL
SYSTOOLSPACE 7 NORMAL
You can now drop the table HISTCOPY that was created at the beginning of
this demonstration.
• db2 drop table histcopy
6. Close both terminal windows and then logout of the Linux operating system.
Results:
You created a series of table space level backups and used them to rebuild a
database copy with one table space excluded. You were able to recover the
excluded table space using a table space level restore.

Unit summary
• Review the considerations of using standard Db2 database recovery
options
• Explain the capabilities of the REBUILD option for the RESTORE
command
• List the types of information included in each Db2 backup image and
describe how it is used to support rebuilding a database
• Plan for supporting database and disaster recovery scenarios using
Db2 database and table space backups using the RESTORE
command with a REBUILD option
• Utilize LIST UTILITIES SHOW DETAIL to monitor progress of a
RESTORE utility during database rebuilding
Unit summary

Db2 database and tablespace relocation
Db2 database and

tablespace relocation

Unit 5 Db2 database and tablespace relocation

Unit objectives
• Explain the facility of the Db2 RESTORE command to recover table
spaces to different containers
• Use the SET TABLESPACE CONTAINERS command to define new
containers during a redirected restore
• Utilize the SET STOGROUP PATHS command to change the storage
paths for automatic storage tablespaces in storage groups
• Plan the use of redirected restore as part of a disaster recovery
• Describe two methods that can be used to convert a DMS table space to
utilize Automatic Storage
• Use the GENERATE SCRIPT option of RESTORE to set up a command
script for a redirected restore operation
• Copy schemas from one database to another using the TRANSPORT
option of the RESTORE utility
• Use db2relocatedb when moving or copying Db2 databases with non-Db2
utilities
Db2 database and tablespace relocation © Copyright IBM Corporation 2018
Unit objectives

Backup image contents
Db2 Backup
Backup Media Header

--------------------------------------------------------------------------------------
Database Control Files:
• Backup start timestamp
• List of table spaces in backup
• Recovery History File (db2rhist.asc)
• List of all table spaces in database at time of backup
• Automatic storage paths
• Database (partition) Configuration (DB CFG)
• Buffer pool configuration file
---------------------------------------------------------------------------------------
Data in requested table spaces
---------------------------------------------------------------------------------------
Log File Header
Backup image contents

There are some key files in a backup image which you should know about when
recovering from a disaster.
In order to recover a database to a new site or recover from a situation where access to
the database and its control files has been lost, Db2 stores information in the backup
image in addition to the data being copied.
Each backup image starts with a media header followed by the database control files
which includes:
• The backup start time stamp
• A list of the table spaces contained in the backup
• A copy of the recovery history file, db2rhist.asc, which lists key utility and
database alterations prior to the start of this backup utility
• A list of all table spaces in the database at the time the backup was taken
• The automatic storage paths used by the database
• The database configuration file, which has all the options for this database or
partition of a partitioned database
• The buffer pool configuration file, sqllbp.x

Next is the data from the table spaces that were backed up.
At the end of the backup image is another control file, the Log File Header, or log
control files. It is used to place this backup in the sequence of database log files, and it
is used to set the starting point in the logs where a roll forward process must begin.

Container information in a backup image

db2ckbkp -t TP1.0.inst481.DBPART000.20160117192419.001
.................................
TP1HIST
tbspInImage: T
ID: 4
.................................
Container CB
Type: 6
TotalPages: 5000
UsablePages: 4992
# of OS rsvd bytes: 512
Page 0 offset: 131072
Tag offset: 512
Extent offset: 0
Name: /database/inst481/tp1hist
.................................
TP1ACCTD
tbspInImage: F
ID: 5
.................................
Container CB
Type: 6
TotalPages: 30000
UsablePages: 29888
# of OS rsvd bytes: 512
Page 0 offset: 262144
Tag offset: 512
Extent offset: 0
Name: /database/inst481/tp1acctd
.................................
Container information in a backup image

If you look at the options for a RESTORE command you will find the ability to specify
selected table space names, but there are no options to define table space containers.
The restore process reads the table space container definitions that are stored in the
backup image and automatically restores data to the same disk file or device.
You can use the backup check utility, db2ckbkp, to list the detailed table space
container information saved in the backup. This could be used at a disaster recovery
site to plan the recovery when information about the original database disk
configuration is not available.
The option '-t' displays table space details, including container information, for the table
spaces in the image.

Db2 RESTORE: Container damaged
backup database tp1 to... restore database tp1 from...

Restore Fails!
Db2 Backup
IBMSTOGROUP IBMSTOGROUP
SYSCATSPACE
SYSCATSPACE
TEMPSPACE1
TEMPSPACE1
DB2
Db2 Database Db2 Database
TP1HIST TP1HIST
X
/DBfs1/cont1 /DBfs2/cont2
file file
file file
APSTOGRP1 APSTOGRP1
Table space
Table space TSAP1
TSAP1
Containers
Containers TSAP2
TSAP2
Db2 RESTORE: Container damaged

During a database backup operation, a record is kept of all the table space containers
and automatic storage paths associated with the table spaces that are being backed
up.
During a restore operation, all containers listed in the backup image are checked to
determine if they exist and if they are accessible. If one or more of these containers or
storage paths are inaccessible because of media failure (or for any other reason), the
restore operation will fail. A successful restore operation in this case requires redirection
to different containers or new storage paths. Db2 supports adding, changing, or
removing table space containers for DMS managed table spaces and changes to
automatic storage paths.
Db2 can create directories and files during the restore operation if the file system or
device is accessible. If a UNIX file system is not mounted, or a disk cannot be accessed
by the system, then Db2 cannot complete the restore.
The slide shows a condition where one container for a DMS managed tablespace,
TP1HIST is offline, which causes a standard RESTORE to fail

Redirected restore: Overview
1) restore database tp1 from...

Db2 Backup .... redirect
2) set tablespace containers
for 4 using
IBMSTOGROUP
SYSCATSPACE
(file '/database/inst491/testhist2' 5000)
Db2 Database
TS id = 0
TEMPSPACE1
3) restore database tp1
TS id =1
continue
USERSPACE1 TP1HIST TS id =4
TS id =2
APSTOGRP1
DAMAGED
TSAP1 ts ID = 5 /database/inst491/testhist /database/inst491/testhist2

file file
TSAP2 ts ID = 6
New Table space Container
Redirected restore: Overview

Db2 supports adding, changing, or removing table space containers and changing
automatic storage paths during RESTORE processing.
You can redefine table space containers or automatic storage paths by invoking the
RESTORE DATABASE command and specifying the REDIRECT parameter.
The restore process is divided into three separate steps or phases:
1. The RESTORE command is issued to select the database or table spaces to
restore from the specified backup image, with the REDIRECT option included.
This causes Db2 to delay the restoring of the data from the backup until the
third phase.
2. In phase two, one or more SET TABLESPACE CONTAINERS commands can
be issued to redefine the containers to be used for a table space. During a
Database level RESTORE, SET STOGROUP PATHS statements could be
used to redefine automatic storage paths.
3. In phase three, the RESTORE command is issued with the CONTINUE option
to direct Db2 to restore the database or table spaces to the database with the
modified container definitions.
In the example, this would allow the restore to complete successfully even though one
of the original disks, /database/inst491/testhist could not be accessed.

Step 1: Start the redirected restore
db2 "restore db tp1 tablespace(tp1hist) online

from $HOME/backups taken at 20160117155148 redirect "
SQL1277W A redirected restore operation is being performed. During

a table space restore, only table spaces being restored can have
their paths reconfigured. During a database restore, storage group
storage paths and DMS table space containers can be reconfigured.
DB20000I The RESTORE DATABASE command completed successfully.
Step 1: Start the redirected restore

The first phase is initialization. The RESTORE command is issued to restore a
database or selected table spaces from the backup image specified in the FROM
clause. Db2 will read the header information from the backup image and check to see if
the table space containers that were present at the time of the backup are available.
The REDIRECT option tells Db2 to delay restoring any data extents to allow table
space containers to be altered.

Step 2a: Check tablespace ID and size

db2 list tablespaces
Tablespaces for Current Database
Tablespace ID = 0
Name = SYSCATSPACE
Type = Database managed space
Contents = All permanent data. Regular table space.
State = 0x0000
Detailed explanation:
Normal
. . . . . .
Tablespace ID = 4
Name = TP1HIST
Contents = All permanent data. Large table space.
State = 0x2003100
Restore pending
Storage must be defined
Restore in progress
Storage may be defined
Step 2a: Check tablespace ID and size

The LIST TABLESPACES and LIST TABLESPACE CONTAINERS commands can be
used to check table space information during RESTORE processing. The SET
TABLESPACE CONTAINERS command uses the table space ID rather than a table
space name, so the table space ID needs to be checked for any table spaces that need
to have container changes.
When table spaces are being restored online the MON_GET_TABLESPACE and
MON_GET_CONTAINER functions could be used in SQL statements to retrieve table
space statistics using another command line session.

Step 2b: Check container information
db2 list tablespace containers for 4 show detail
Tablespace Containers for Tablespace 4
Container ID = 0
Name = /database/inst491/testhist
Type = File
Total pages = 5000
Useable pages = 4928
Accessible = Yes
Step 2b: Check container information

The LIST TABLESPACE CONTAINERS command can be used to list the table space
size and container definitions. The command references the tablespace ID rather than
a tablespace name. The report includes the total number of pages defined for a table
space.

Step 3: Set container definition
db2 set tablespace containers for 4 using ((file ‘/database/inst491/testhist2’ 5000 ) )
DB20000I The SET TABLESPACE CONTAINERS command completed successfully.
Note: For DMS managed tablespace containers the SET TABLESPACE

CONTAINERS command will allocate and format the new containers which
can take considerable time if the containers are large.
Step 3: Set container definition

In the slide, the following command is shown:
set tablespace containers
for 4 using ((file '/database/inst491/testhist2' 5000 )
This command will define a new container for the table space with a table space ID of 4,
TP1HIST. This is a DMS table space, so file containers and raw device containers
could be specified.
Db2 would allow either more or fewer containers to be defined as long as there is
enough space allocated to complete the restore. For DMS table spaces, the amount
specified must be at least equal to the high water mark, the highest extent that contains
data to be restore for the table space. If the REORG utility is used to reorganize a table
in a DMS table space without using a temporary table space, this could set the high
water mark to a size twice the size of the table.

Step 4: Complete restore processing
db2 restore database tp1 continue
db2 rollforward db tp1 to end of logs tablespace online

Rollforward Status
Input database alias = tp1

Number of members have returned status = 1
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = -
Last committed transaction = 2016-05-15-13.57.30.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.
Step 4: Complete restore processing

To complete the redirected restore processing, use the RESTORE command with the
CONTINUE option. This will cause Db2 to restore the data extents from the backup
image using the modified containers.
For a recoverable database, the roll forward process is required to recover the
database or table space to a point following the original backup. In the example, the TO
END OF LOGS option is used to apply the latest logged updates to the restored table
space.
The table space would now be available for access using the modified containers.

Changing Automatic Storage paths

• Automatic Storage Table spaces can not be individually moved using
the REDIRECT option of RESTORE
• Automatic Storage table spaces can be reassigned new containers
during a database level RESTORE
• With Db2 multiple storage groups can be defined, the group
IBMSTOGROUP is created by default during CREATE DATABASE
 The storage paths assigned to a storage group can be changed during a
database redirected restore using a SET STOGROUP PATHS statement:
db2 set stogroup paths for IBMSTOGROUP

on '/dbauto/path1’, '/dbauto/path2'
Changing Automatic Storage paths

Automatic Storage managed table spaces cannot be individually moved using the
REDIRECT option of a RESTORE command.
Table spaces using AUTOMATIC Storage will reuse the containers defined at the time
of the backup image when a RESTORE is performed at the TABLESPACE level.
If a DATABASE level restore is performed, the automatic storage paths can be
redefined, which will cause new container assignments for the table spaces.
The Db2 feature of storage groups for automatic storage managed table spaces, allows
you to define multiple storage groups. The RESTORE utility with the REDIRECT can be
used with a database level restore and the SET STOGROUP PATHS statement can
assign new storage paths to a specific storage group, which would cause the table
spaces in that storage group to acquire new containers. No SET TABLESPACE
CONTAINERS commands are allowed or required for Automatic Storage managed
table spaces.
Any storage groups that have their paths redefined during a restore operation will not
have any changes to their storage paths or media attributes replayed during a
subsequent roll forward operation.

Generating a redirected restore script (1 of 3)

db2 restore db tp1 tablespace(TP1HIST) from /home/inst1/backups
redirect GENERATE SCRIPT rdirect.txt
RESTORE DATABASE TP1
-- USER <username>
-- USING '<password>' The Generated Script includes
TABLESPACE (
"TP1HIST" a RESTORE DATABASE command
)
-- ONLINE
FROM '/home/inst491/backups/lab7'
TAKEN AT 20160718095239
-- ON '/dbauto/path1'
-- DBPATH ON '<target-directory>'
INTO TP1
-- NEWLOGPATH '/dblogs/inst491/tp1/NODE0000/LOGSTREAM0000/'
-- WITH <num-buff> BUFFERS
-- BUFFER <buffer-size>
-- REPLACE HISTORY FILE
-- REPLACE EXISTING
REDIRECT
-- PARALLELISM <n>
-- COMPRLIB '<lib-name>'
-- COMPROPTS '<options-string>'
-- WITHOUT ROLLING FORWARD
-- WITHOUT PROMPTING
;
Generating a redirected restore script

To perform a redirected restore using a script:
Use the Restore utility to generate a redirected restore script. The Restore utility can be
invoked through the command line processor (CLP) or the db2Restore application
programming interface (API).
The following is an example of the RESTORE DATABASE command with the
REDIRECT option and the GENERATE SCRIPT option:
db2 restore db test from /home/jseifert/backups taken at 20140304090733
redirect generate script test_node0000.clp
This creates a redirected restore script on the client called test_node0000.clp.
Open the redirected restore script in a text editor to make any modifications that are
required.
You can modify:
• Restore options
• Automatic storage paths
• Container layout and paths
Run the modified redirected restore script. For example:
db2 -tvf test_node0000.clp


*****************************************************************************
-- ** storage group definition
-- ** Default storage group ID = 0
-- ** Number of storage groups = 2
-- *****************************************************************************
-- *****************************************************************************
-- ** Storage group name = IBMSTOGROUP
-- ** Storage group ID = 0
-- ** Data tag = None
-- *****************************************************************************
-- SET STOGROUP PATHS FOR IBMSTOGROUP
-- ;
-- *****************************************************************************
-- ** Storage group name = TP1SG1
-- *****************************************************************************
-- SET STOGROUP PATHS FOR TP1SG1
-- ON '/dbauto/path2' The Generated Script includes
-- ; SET STOGROUP PATHS
Statements to redefine storage groups
The example output includes SET STOGROUP PATHS statements for any automatic
storage groups in the database at the time of the backup.
These statements are marked as comments. The SET STOGROUP PATHS could only
be utilized if you perform a database level redirected restore.


*****************************************************************************
-- ** Tablespace name = TP1HIST
-- ** Tablespace ID = 4
-- ** Tablespace Type = Database managed space
-- ** Tablespace Content Type = All permanent data. Large table space.
-- ** Tablespace Page size (bytes) = 16384
-- ** Tablespace Extent size (pages) = 8
-- ** Using automatic storage = No
-- ** Storage group ID = -1
-- ** Source storage group ID = -1
-- ** Auto-resize enabled = Yes
-- ** Total number of pages = 5000
-- ** Number of usable pages = 4992
The Generated Script includes
-- ** High water mark (pages) = 64
SET TABLESPACE CONTAINERS
-- *****************************************************************************
SET TABLESPACE CONTAINERS FOR 4 Statements to redefine containers
-- IGNORE ROLLFORWARD CONTAINER OPERATIONS
USING (
FILE '/database/inst491/tp1hist' 5000
);
-- *****************************************************************************
-- ** start redirected restore
-- *****************************************************************************
RESTORE DATABASE TP1 CONTINUE;
The example output shows some of the information provided in comments for a table
space, including, the total number of pages, the high water mark and whether the table
space is managed by automatic storage.
Automatic Storage table space containers cannot be changed during a redirected
restore using the SET TABLESPACE CONTAINERS commands.

Db2 RESTORE: Restore to disaster site

restore database tp1 from...
backup database tp1 to...
Db2 Backup REDIRECT
set tablespace containers..
IBMSTOGROUP set stogroup paths…
SYSCATSPACE
TEMPSPACE1 Db2 Database
Db2 Database
TP1HIST
IBMSTOGROUP TP1HIST
SYSCATSPACE
/DBfs1/cont1 /DBfs2/cont2 TEMPSPACE1
file file
/DBfs2/cont1
APSTOGRP1
file
APSTOGRP1 TSAP1
TSAP1
TSAP2
TSAP2
Db2 RESTORE: Restore to disaster site

A redirected restore might be required when a Db2 backup image is restored to a
different system where there could be a different disk configuration. For example, if the
production system has 50 smaller capacity disks assigned and the disaster site has 20
larger capacity disks, the container definitions might need to be altered to fit the new
disk configuration.
Automatic storage groups can easily be redefined to allocate the tablespaces into
different storage paths.
In the slide, the tablespace TP1HIST used two smaller containers at the production
location and is planned to use one large container at the disaster site.
The redirected restore could also be used to restore a production database backup to a
test database on the same server to avoid the duplication of directory and file names on
the single server. The container names generated for automatic storage tablespaces
include the database name and would automatically avoid duplicate container names
when restored to a different database name or Db2 instance.
If you need to migrate a database to a new disk subsystem, you could use a redirected
restore to move all or a portion of the database.


1. ALTER TABLESPACE can be used to convert a DMS table space to
an Automatic Storage table space without an outage:
 ALTER TABLESPACE … MANAGED BY AUTOMATIC STORAGE [ USING
STOGROUP sg_name ]
 All new growth comes from the automatic storage paths
 Old (file or raw) containers can be removed using ALTER TABLESPACE
REBALANCE
ALTER TABLESPACE TSP12 MANAGED BY AUTOMATIC STORAGE
USING STOGROUP sg_medium
ALTER TABLESPACE TSP12 REBALANCE
2. A redirected RESTORE can be used to convert DMS table spaces to
AUTOMATIC STORAGE table spaces:
 The USING AUTOMATIC STORAGE option of the SET TABLESPACE
CONTAINERS will convert a DMS-managed table space to automatic
storage management using the default storage group
SET TABLESPACE CONTAINERS FOR 6 USING AUTOMATIC STORAGE

A Database Managed (DMS) table space can be converted to use Automatic Storage
management using two methods.
In order to minimize the loss of availability for a table space during the conversion, the
ALTER TABLESPACE command can be used to convert a database-managed table
space with user assigned containers to an Automatic Storage-managed table space.
This requires two steps.
• First, the ALTER TABLESPACE statement with the MANAGED BY AUTOMATIC
STORAGE option is used to change the table space definition to become an
Automatic Storage table space. The USING STOGROUP clause can be used to
assign the table space to a specific storage group. This will assign some new
containers to the table space from the Automatic Storage paths defined for the
storage group, but will retain the original file or raw device containers. The new
Automatic Storage containers will be added as a new stripe set so no rebalancing
will occur and any new space added by autoresize will take place in the
Automatic Storage paths. At this point, Db2 considers this an Automatic Storage
table space and will not permit any alteration that directly names containers like
the ALTER TABLESPACE ADD or DROP.

• Next, the ALTER TABLESPACE STATEMENT with the REBALANCE option can
be used to rearrange the extents in a way that releases the original non-
Automatic Storage containers. For example:
ALTER TABLESPCE TSP12 REBALANCE
DMS-managed table spaces can be converted to Automatic Storage management
using a a database or table space redirected restore. The SET TABLESPACE
CONTAINERS statement specifies USING AUTOMATIC STORAGE rather than listing
user assigned containers. The table space will be assigned to the default storage group
for the database.
SET TABLESPACE CONTAINERS FOR 6 USING AUTOMATIC STORAGE
There is no supported method to convert an Automatic Storage managed table space
to DMS management.

ALTER TABLESPACE Add: After backup (1 of 2)
BACKUP Table Space ALTER TABLESPACE DMS01 DMS01 ALL Containers

DMS01 Backup ADD ( file '/DBfs1/cont2' 10000) Inaccessible
Time 1 Time 2 Time 3
S0000021.log S0000022.log S0000023.log S0000024.log
Db2 Database Db2 Database Db2 Database
DMS01 DMS01
DMS01
X X
/DBfs1/cont1
file file
file
file file
ALTER TABLESPACE Add: After backup

The information stored in the backup image includes the container definitions at the
time of the backup. For DMS table spaces, an ALTER TABLESPACE can be used to
add additional container definitions to an existing table space. That ALTER
TABLESPACE is logged by Db2. If the table space is restored from the previous
backup image and a roll forward is performed that includes the log record for the
ALTER TABLESPACE, Db2 will redo the container creation as part of the roll forward.
In the example shown:
1. At Time 1, a backup of the table space DMS01 is created containing a single
container definition.
2. At Time 2, an ALTER TABLESPACE is executed to add a new container to the
table space, on the same disk as the first container.
3. At Time 3, a hardware problem occurs and the disk with both containers in now
inaccessible.
4. It is determined that a redirected restore will be used to recover from this
problem.

ALTER TABLESPACE Add: After backup (2 of 2)
ALTER TABLESPACE DMS01

Table Space
ADD ( file 'd:\dms01\cont2' 10000)
DMS01 Backup
X
S0000021.log S0000022.log S0000023.log S0000024.log
Db2 Database 1) restore database tp1 from... Db2 Database

.... redirect
DMS01 2) set tablespace containers

DMS01
for 3 using (file '/DBfs2/cont1' 20000)
X X IGNORE ROLLFORWARD CONTAINER OPERATIONS
/DBfs1/cont1
3) restore database tp1 continue
file /DBfs2/cont1
4) rollforward database tp1
/DBfs1/cont2 file
to end of logs
file tablespace(dms01) online
Since a table space container was added after the last backup image was created, the
roll forward process would normally redo the container definition. The loss of access to
the disk with both containers would prevent the roll forward from completing
successfully.
The SET CONTAINERS command has an option that will direct Db2 to either REPLAY
or IGNORE the container changes during the roll forward process. This option would
apply to the single table space defined in the command, new containers could still be
added to other table spaces during the roll forward.
In the example, the IGNORE ROLLFORWARD CONTAINER OPERATIONS option is
used to define a single container to be used for the restore and roll forward processing
and to bypass the container addition that was logged. This allows the redirected restore
process to complete recovery of the table space including all of the current log files.
The command syntax is:
>>-SET TABLESPACE CONTAINERS FOR--tablespace-id------->
>-----+----------------------------------------+------>
| .-REPLAY--. |
'--+-IGNORE--+---ROLLFORWARD CONTAINER OPERATIONS--'

Copying schemas of objects from one database to another

using db2move
• One or more schemas can be copied from one database to another

using the db2move COPY option:
 Table data is copied using LOAD utility processing
 Source and target databases can use different product platforms
− For example, from Db2 on Windows to Db2 on AIX
 Schemas can be renamed
 Options to create schema objects, create and load or just load data
 Alternate table spaces could be assigned
− Example - To duplicate schema schema1 from source database dbsrc to the target
database dbtgt, rename the schema to newschema1 on the target, and map
source table space ts1 to ts2 on the target, issue:
db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt

USER myuser1 USING mypass1
SCHEMA_MAP ((schema1,newschema1))
TABLESPACE_MAP ((ts1,ts2), SYS_ANY))
Copying schemas of objects from one database to another using db2move

The db2move command can be used to copy one or more schemas of database
objects between databases using the COPY option. The source and target database
names are supplied in the command. The two databases might be on different servers
using different Db2 platforms. The data is copied using a LOAD utility based on a cursor
rather than using external files.
Using this method the schemas could be renamed using the SCHEMA_MAP keyword.
The table space assignments could be adjusted using the TABLESPACE_MAP
keyword.
This utility attempts to copy all allowable schema objects with the exception of the
following types:
• Table hierarchy
• Staging tables (not supported by the load utility in multiple partition database
environments)
• Jars (Java routine archives)
• Nicknames
• Packages

• View hierarchies
• Object privileges (All new objects are created with default authorizations)
• Statistics (New objects do not contain statistics information)
• Index extensions (user-defined structured type related)
• User-defined structured types and their transform functions

Copying schemas of objects from one database to another

using RESTORE with TRANSPORT
• One or more schemas can be copied from one database to another

using the TRANSPORT option of RESTORE:
 The tables are copied from a backup image into one or more table spaces
 The objects (tables, indexes, views) and table spaces can not duplicate any
existing object in the target database
 Table spaces are restored using a RESTORE utility including the
TRANSPORT option
 A list of table spaces must be named using the TABLESPACE option
 The SCHEMA option is required to list the schema names to be transported
to the target database
 The target database must use a compatible platform for the source backup
image
− Db2 for Linux could not be restored on Db2 for Windows or AIX
Copying schemas of objects from one database to another using RESTORE with
TRANSPORT
Table spaces and SQL schemas can be restored as a set from one database to
another using transportable sets.
By using the RESTORE command with the TRANSPORT option, you can restore data
in a set of table spaces from a backup image into another existing database. You can
re-create database objects in the SQL schemas that reference the data in the restored
table spaces. The restored table spaces and SQL schemas can function as part of the
new database.
The objects being transported cannot duplicate any existing database objects in the
target database.
The list of table spaces must be specified in a TABLESPACE option when using the
TRANSPORT option. You must also list the schemas using the SCHEMA option.
Transporting a database schema involves taking a backup image of a database and
restoring the database schema to a different, existing database. When you transport a
database schema, the database objects in the transported schema are re-created to
reference the new database, and the data is restored to the new database.

Objects that can be transported using the TRANSPORT

option of RESTORE
• Tables, created global temporary tables, materialized query tables
• Views (standard and statistical views)
• The following types of generated columns:
 Expression
 Identity
 Row change timestamp
 Row change token
• User-defined functions, user-defined types, and generated functions
• The following types of constraints:
 Check
 Foreign Key
 Unique and primary
 Functional dependency
• Indexes
• Triggers
• Sequences
• Functions and procedures except for external routine executables
• Object authorizations, privileges, security, access control, and audit configuration
• Table statistics, profiles, and hints
• Packages
Objects that can be transported using the TRANSPORT option of RESTORE

When you transport data from a backup image to a different database, the physical and
logical objects contained in the table spaces being restored are re-created in the target
database, and the table space definitions and containers are added to the target
database.
The following logical objects are re-created:
• Tables, created global temporary tables, materialized query tables, and normal
and statistical views
• The following types of generated columns:
• Expression
• Identity
• Row change timestamp
• Row change token
• User-defined functions, user-defined types, and generated functions

• The following types of constraints:

• Check
• Foreign Key
• Unique and primary
• Functional dependency
• Indexes
• Triggers
• Sequences
• Functions and procedures except for external routine executables
• Object authorizations, privileges, security, access control, and audit configuration
• Table statistics, profiles, and hints
• Packages
The following components of a schema are not created on the target database:
• Aliases
• Created global variables
• Jobs
• Index extensions
• Hierarchical tables, typed tables, and typed views
• Nicknames
• Structured types
• Methods
• Servers
• Wrappers
• Functional mappings and templates
• OLE DB external functions
• Sourced procedures
• External routine executable files
• System catalogs
• Range-partitioned tables

Transportable sets
Following combinations of table spaces and schemas are valid transportable sets:
• Tablespace1 with schema1 and schema2
• Tablespace2 and tablespace3 with schema3
• Tablespace4, tablespace5, and tablespace6, with schema4 and schema5
• Combination of valid transportable sets also constitutes a valid transportable set:
 tablespace1, tablespace2, and tablespace3, with schema1, schema2, schema3
Transportable sets
A database schema must be transported in its entirety. If a table space contains both
the schema you want to transport, as well as another schema, you must transport all
data objects from both schemas. These sets of schemas that have no references to
other database schemas are called transportable sets. The data in the table spaces
and logical objects in the schemas in a transportable set reference only table spaces
and schemas in the transportable set. For example, tables have table dependencies
only on other tables in the transportable set.
The example shows the mapping of table spaces to database objects in different
schemas.
The following combinations of table spaces and schemas are valid transportable sets:
• tablespace1 with schema1 and schema2
• tablespace2 and tablespace3 with schema3
• tablespace4, tablespace5, and tablespace6, with schema4 and schema5

A combination of valid transportable sets also constitutes a valid transportable set:

• tablespace1, tablespace2, and tablespace3, with schema1, schema2, and
schema3
• The set tablespace4 and tablespace5 with schema4 is not a valid transportable
set because there are references between tablespace5 and schema5 and
between schema5 and tablespace6. The set requires tablespace6 with schema5
to be a valid transportable set.

Db2 RESTORE: TRANSPORT

db2 backup
database PROD
Tablespace(syscatspace, Database SYSCATSPACE
Db2 Backup
TSap1,TSap2) TEST
TSAP1
online to...
TSAP2
TST01 TST02 Test database

SYSCATSPACE Database
PROD
TSAP1 db2 restore db PROD
(schema TABLESPACES (TSAP1,TSAP2)
AP1) SCHEMA(AP1,AP2)
TRANSPORT into TEST
TSAP2 TSAP3 TSAP4
FROM ... REDIRECT
(schema
AP2) db2 set tablespace containers
for 4 using ……
Production Site db2 set tablespace containers
for 5 using ……
db2 restore db PROD continue
Db2 RESTORE: TRANSPORT

In this example, two database schemas are copied from the database named PROD to
the target database named TEST. The two schemas, AP1 and AP2 are stored in two
table spaces, TSAP1 and TSAP2 in the source database. An online table space backup
of the PROD database could include the two table spaces TSAP1 and TSAP2 as well
as the catalog tablespace SYSCATSPACE. A database backup could also be used.
The RESTORE command would refer to the source and target databases and list the
table spaces and schemas to be transported into the target database. The REDIRECT
option of the RESTORE command could be used to assign new table space containers
for use by the target database.

Processing performed by RESTORE TRANSPORT

• Backup image used for RESTORE with TRANSPORT option
 Can be either database or table space level
 Can be online or offline
• The transport operation consists of the following phases:
 Staging database creation:
− Temporary Database is used to extract schema definitions from source catalog
information
− A STAGE IN option may be used to set the staging database name
 Physical table space container restoration
 Roll forward processing:
− Used to redo or undo changes performed when using an online backup
− Log files included in backup image are used
− Similar to roll forward TO END OF BACKUP
 Schema validation
 Transfer of ownership of the table space containers
 Schema re-creation in target database
 Dropping the staging database (if the STAGE IN option is not specified)
Processing performed by RESTORE TRANSPORT

When transporting database schemas, a temporary database is created and named as
a part of the transport operation. The transport staging database is used to extract
logical objects from the backup image so that they can be re-created on the target
database. If logs are included in the backup image, they will also be used to bring the
staging database to a point of transactional consistency. The ownership of the
transported table spaces is then transferred to the target database.
The transport operation consists of the following phases:
1. Staging database creation.
2. Physical table space container restoration.
3. Rollforward processing - the log files included in an online backup image are
used to replay and undo any uncommitted changes produced during the backup
processing. This would be similar to performing a roll forward to the
END OF BACKUP.
4. Schema validation.
5. Transfer of ownership of the table space containers.
6. Schema re-creation in target database.
7. Dropping the staging database (if the STAGE IN option is not specified).

db2relocatedb command
After copying the files,
use db2relocatedb to: Instance inst1
1. Change database name Automatic Storage
2. Change database path Path(s) DB Directory
3. Change Db2 instance

4. Change Automatic Storage Path(s) SYSCATSPACE Db2
Database Active Logs
5. Change Log path
TEMPSPACE1
6. Change Table space container(s) PROD Archive Logs
7. Change additional log related paths
db2relocatedb -f filename Table space Table space
DMS02
DMS01
DB_NAME=oldName,newName
DB_PATH=oldPath,newPath
INSTANCE=oldInst,newInst
NODENUM=nodeNumber
LOG_DIR=oldDirPath,newDirPath
CONT_PATH=oldContPath1,newContPath1
STORAGE_PATH=oldStorPath1,newStorPath1
db2relocatedb command
Each Db2 database has a set of control files that identify the name of the database, the
instance name, the names of all table space containers, the automatic storage paths
and the various logging related paths. The Db2 RESTORE utility makes changes to
some of these files automatically. The db2relocatedb command can be used to update
this information when part of a Db2 database is relocated outside Db2's control.
This command renames a database, or relocates a database or part of a database (for
example, the container and the log directory) as specified in the configuration file
provided by the user. This tool makes the necessary changes to the Db2 instance and
database support files.
The target database must be offline before running the db2relocatedb command to
modify the control files and metadata of the target database.
The changes that the db2relocatedb command makes to files and control structures of
a database are not logged and are therefore not recoverable. A good practice is to
make a full backup after running the command against a database, especially if the
database is recoverable with log files being retained.

Authorization
None.
Command Syntax
db2relocatedb -f configFilename
Command Parameters
-f configFilename
Specifies the name of the file containing configuration information necessary for
relocating the database. This can be a relative or absolute filename. The format of the
configuration file is:
DB_NAME=oldName,newName
DB_PATH=oldPath,newPath
INSTANCE=oldInst,newInst
NODENUM=nodeNumber
LOG_DIR=oldDirPath,newDirPath
…
STORAGE_PATH=oldStoragePath1,newStoragePath1
STORAGE_PATH=oldStoragePath2,newStoragePath2
…
FAILARCHIVE_PATH=newDirPath
LOGARCHMETH1=newDirPath
LOGARCHMETH2=newDirPath
MIRRORLOG_PATH=newDirPath
OVERFLOWLOG_PATH=newDirPath
Where:
• DB_NAME Specifies the name of the database being relocated. If the database
name is being changed, both the old name and the new name must be specified.
This is a required field.
• DB_PATH Specifies the path of the database being relocated. This is the path
where the database was originally created. If the database path is changing, both
the old path and new path must be specified. This is a required field.
• INSTANCE Specifies the instance where the database exists. If the database is
being moved to a new instance, both the old instance and new instance must be
specified. This is a required field.
• NODENUM Specifies the node number for the database node being changed.
The default is 0.

• LOG_DIR Specifies a change in the location of the log path. If the log path is
being changed, then both the old path and new path must be specified. This
specification is optional if the log path resides under the database path, in which
case the path is updated automatically.
• CONT_PATH Specifies a change in the location of table space containers. Both
the old and new container path must be specified. Multiple CONT_PATH lines
can be provided if there are multiple container path changes to be made. This
specification is optional if the container paths reside under the database path, in
which case the paths are updated automatically. If you are making changes to
more than one container where the same old path is being replaced by a
common new path, a single CONT_PATH entry can be used. In such a case, an
asterisk (*) could be used both in the old and new paths as a wildcard.
• STORAGE_PATH Specifies a change in the location of one of the storage paths
for the database. Both the old storage path and the new storage path must be
specified. Multiple STORAGE_PATH lines can be given if there are several
storage path changes to be made. You can specify this parameter to modify any
storage path in all storage groups. However, you cannot specify this parameter to
modify the storage paths for an individual storage group.
• FAILARCHIVE_PATH Specifies a new location to archive log files if the
database manager fails to archive the log files to either the primary or the
secondary archive locations. You should only specify this field if the database
being relocated has the failarchpath configuration parameter set.
• LOGARCHMETH1 Specifies a new primary archive location. You should only
specify this field if the database being relocated has the logarchmeth1
configuration parameter set.
• LOGARCHMETH2 Specifies a new secondary archive location. You should only
specify this field if the database being relocated has the logarchmeth2
configuration parameter set.
• MIRRORLOG_PATH Specifies a new location for the mirror log path. The string
must point to a path name, and it must be a fully qualified path name, not a
relative path name. You should only specify this field if the database being
relocated has the mirrorlogpath configuration parameter set.
• OVERFLOWLOG_PATH Specifies a new location to find log files required for a
rollforward operation, to store active log files retrieved from the archive, and to
find and store log files required by the db2ReadLog API. You should only specify
this field if the database being relocated has the overflowlogpath configuration
parameter set.

Usage Notes:
If the instance that a database belongs to is changing, the following must be done
before running this command to ensure that changes to the instance and database
support files are made:
• If a database is being moved to another instance, create the new instance. The
new instance must be at the same release level as the instance where the
database currently resides.
• If the new instance has a different owner than the current instance, grant access
to the new instance owner.
• Copy the files and devices belonging to the databases being copied onto the
system where the new instance resides. The path names must be changed as
necessary. However, if there are already databases in the directory where the
database files are moved to, you can mistakenly overwrite the existing sqldbdir
file, thereby removing the references to the existing databases. In this scenario,
the db2relocatedb utility cannot be used. Instead of db2relocatedb, an alternative
is a redirected restore operation.
• Change the permission of the files/devices that were copied so that they are
owned by the instance owner.
When moving a database from a database path where more than one database
resides, the sqldbdir directory within that database path must be copied and not
moved. This directory is still needed in the old location for Db2 to locate the
databases that are not moving. After copying the sqldbdir directory to the new
location, a LIST DB DIRECTORY ON newPath command lists databases that were
not moved. These references cannot be removed and new databases with those
names cannot be created on this same path. However, databases can be created
with those names on a different path.
The db2relocatedb command cannot be used to move existing user created
containers for a table space that was converted to use automatic storage using the
ALTER TABLESPACE MANAGED BY AUTOMATIC STORAGE statement.
If the instance is changing, the command must be run by the new instance owner.

Changing log-related options using db2relocatedb

• You can specify additional keywords in the db2relocatedb command
configuration file that make it easier to relocate a database when the
log-related paths used are different:
 FAILARCHIVE_PATH=newDirPath
 LOGARCHMETH1=newDirPath
 LOGARCHMETH2=newDirPath
 MIRRORLOG_PATH=newDirPath
 OVERFLOWLOG_PATH=newDirPath
• You should only specify these fields if the database being relocated
has the matching configuration parameter set
• Note, the old path name is not specified for these
Changing log-related options using db2relocatedb

You can specify additional keywords in the db2relocatedb command configuration file
that make it easier to relocate a database when the paths used are different.
The db2relocatedb configuration file can contain new values for the mirrorlogpath,
failarchivepath, logarchmeth1, logarchmeth2, and overflowlogpath database
configuration parameters.
When you run the db2relocatedb command, the database configuration parameters of
the relocated database are updated with the values specified in the configuration file. If
you do not specify any of the new keywords, the relocated database maintains the
original parameters values.

Using db2relocatedb after copying containers

DB_NAME=prod
db2relocatedb -f newts DB_PATH=/db
Instance inst1 INSTANCE=inst1

CONT_PATH= /dbvol2/DB1/dms01, /dbvol3/DB1/dms1a
DB Directory
DB CFG
Log Control File /db/inst1/NODE0000/SQL00001
Recovery History
Table space files
/dbauto/path1/inst1/NODE0000/PROD/T0000000/C0000000.CAT
SYSCATSPACE
Db2 Database
/dbauto/path1/inst1/NODE0000/PROD/T0000001/C0000000.TMP
PROD TEMPSPACE1
/dbvol2/DB1/dms01
Table space Table space /dbvol3/DB1/dms1a
DMS01 DMS01
Active Logs /dblogs/DB1/logs
Using db2relocatedb after copying containers

The db2relocatedb command can be used to update a database configuration when
table space containers are moved using operating system file or disk volume copies.
For example:
The database PROD exists in the instance inst1 on the path /db.
The location of the table space container need to be changed as follows:
The DMS container /dbvol2/DB1/dms01 needs to be moved to
/dbvol3/DB1/dms1a
After the files has been moved to the new locations, the following configuration file
can be used with the db2relocatedb command to make changes to the database
files so that they recognize the new locations:
DB_NAME=prod
DB_PATH=/db
INSTANCE=inst1
CONT_PATH=/dbvol2/DB1/dms01,/dbvol3/DB1/dms1a

Copying a Db2 database to a new instance
Instance inst1 Database

/dbprd/inst1/NODE0000/SQL00001
/dbprd/DB1/dms01
Directory
IBMSTOGROUP
SYSCATSPACE APSTOGRP1
Db2 Database Table space
TEMPSPACE1 TSAP1 DMS01
PROD TSAP2
/dbprd/sysgrp
/dbprd/apgrp1
Active Logs /dblogs/DB1/logs
/dbtest/TEST/logs APSTOGRP1
Active Logs
IBMSTOGROUP TSAP1
SYSCATSPACE TSAP2
Db2 Database TEMPSPACE1
/dbtest/apgrp1 Table space
TEST
/dbtest/sysgrp DMS01
Database /tsdb/TEST/dms01
Directory
Instance inst2 /tsdb/inst2/NODE0000/SQL00001
Copying a Db2 database to a new instance

The db2relocatedb command can be used as part of copying a database from one
instance to another using non-Db2 utilities, like operating system file copy
commands.
For example:
• The database PROD exists in the instance inst1 and was created on the path
/dbprd. The database has two automatic storage groups defined,
IBMSTOPGROUP which uses the path /dbprd/sysgrp, APSTOGROUP which
uses the path /dbprd/apgrp1. A DMS managed table space uses the container
/dbprd/DB1/dms01.
• The database PROD is to be moved to a new system with a new database name
of TEST. The instance on the new system will be inst2 and the location of the
database path will be /tsdb.
• The TEST database needs two automatic storage groups defined,
IBMSTOPGROUP which will use the path /dbtest/sysgrp, APSTOGROUP will
uses the path /dbtest/apgrp1. The DMS managed table space DMS01 will use
the container /tsdb/TEST/dms01.
When moving the database, care must be taken to locate all of the database related
files in the paths planned.

Run db2relocatedb in new instance after copy
Instance inst1 Instance inst2

DB Directory DB Directory
TEMPSPACE1 TEMPSPACE1
Db2 Db2
Database Active Logs
Active Logs Database
PROD TEST
TSAP1 STOGROUP STOGROUP TSAP1
TSAP2 APSTOGRP1 APSTOGRP1 TSAP2
Table space
Table space
DMS01
DMS01
DB_NAME=PROD,TEST
db2relocatedb -f newdb DB_PATH=/dbprd,/tsdb
INSTANCE=inst1,inst2
LOG_DIR=/dblogs/PROD/logs,/dbtest/TEST/logs
CONT_PATH=/dbprd/DB1/dms01,/tsdb/TEST/dms01
STORAGE_PATH=/dbprd/sysgrp,/dbtest/sysgrp
STORAGE_PATH=/dbprd/apgrp1,/dbtest/apgrp1
Run db2relocatedb in new instance after copy

After the physical directories and files have been copied to their new locations, the
following configuration file can be used with db2relocatedb to make changes to the
database files so that they recognize the new locations:
DB_NAME=PROD,TEST
DB_PATH=/dbprd,/tsdb
LOG_DIR=/dblogs/PROD/logs,/dbtest/TEST/logs
CONT_PATH=/dbprd/DB1/dms01,/tsdb/TEST/dms01
STORAGE_PATH=/dbprd/sysgrp,/dbtest/sysgrp
STORAGE_PATH=/dbprd/apgrp1,/dbtest/apgrp1

Demonstration 1
Db2 tablespace relocation and transportation
• Plan and execute a redirected restore using Db2 commands

containers for a table space
• Covert DMS managed tablespaces to use Automatic Storage
management with a redirected restore.
• Use the LIST TABLESPACE command to check table space and
container status
• Utilize the db2relocatedb command to change the name of a container
for a table space
• Execute a redirected restore to transport a schema of database objects
and the set of tablespaces used by those objects into a different
database
Demonstration 1: Db2 tablespace relocation and transportation

Demonstration 1:
Db2 tablespace relocation and transportation
Purpose:
This demonstration will allow you how to perform several redirected restores.
One DMS managed table space will be restored to a different container.
Several DMS managed tablespaces will be converted to use automatic storage
management. You will utilize the TRANSPORT option of RESTORE to copy a
schema of objects in a set of table spaces to a second database. The
db2relocatedb command will be used to rename a container.
Task 1. Use db2relocatedb to change the name of a

tablespace container.
Important Note: This demonstration uses the database named TP1 loaded with test
tables in the Db2 instance inst464. You need to utilize the Linux system login to the
instance owner id: inst464.
ibm2blue.
You will create a set of test objects in three new tablespaces. Use the command files
testspace.ddl to create the new tablespaces. The tablespace TESTSMALL is defined
using automatic storage in the storage group TP1SG1. The other two tablespaces,
TESTHIST1 and TESTHIST2 are DMS managed tablespaces. If the current container
is renamed using the UNIX mv command, the db2relocatedb command can be used
to update the table space container definition for the TP1 database to reflect the change
made outside of Db2's control. This must be done with the database stopped.


• cd $HOME/bin
• db2 -tvf testspace.ddl
CREATE TABLESPACE TESTSMALL USING STOGROUP TP1SG1 INITIALSIZE 4M EXTENTSIZE 4
CREATE TABLESPACE TESTHIST1 MANAGED BY DATABASE USING (FILE

'/database/inst464/testhist1' 5000) EXTENTSIZE 64 PREFETCHSIZE 64 autoresize yes
CREATE TABLESPACE TESTHIST2 MANAGED BY DATABASE USING (FILE

'/database/inst464/testhist2' 5000) EXTENTSIZE 64 PREFETCHSIZE 64 autoresize yes
CONNECT RESET
TERMINATE
DB20000I The TERMINATE command completed successfully.
Next you will create a set of objects using the schema TEST in the three
tablespaces and load data into the tables. The file testtables.ddl contains the
necessary SQL.
• db2 -tvf testtables.ddl
CREATE TABLE TEST.BRANCH (BRANCH_ID SMALLINT NOT NULL primary key,
BRANCH_NAME CHAR(20) NOT NULL, BALANCE DECIMAL(15,2) NOT
NULL, AREA_CODE CHAR(4) NOT NULL, ADDRESS CHAR(30)
NOT NULL, TEMP CHAR(40) NOT NULL) IN TESTSMALL
CREATE TABLE TEST.TELLER (TELLER_ID SMALLINT NOT NULL primary key,

TELLER_NAME CHAR(20) NOT NULL, BRANCH_ID SMALLINT NOT
NULL, BALANCE DECIMAL(15,2) NOT NULL, TELLER_CODE CHAR(2)
NOT NULL, ADDRESS CHAR(30) NOT NULL, TEMP CHAR(40)
NOT NULL) IN TESTSMALL
CREATE TABLE TEST.HISTORY1 (ACCT_ID INTEGER NOT NULL, TELLER_ID

SMALLINT NOT NULL, BRANCH_ID SMALLINT NOT NULL, BALANCE
DECIMAL(15,2) NOT NULL, DELTA DECIMAL(9,2) NOT NULL, PID

INTEGER NOT NULL, TSTMP TIMESTAMP NOT NULL WITH DEFAULT,

ACCTNAME CHAR(20) NOT NULL, TEMP CHAR(6) NOT
NULL) IN TESTHIST1
CREATE INDEX TEST.H1INDEX ON TEST.HISTORY1 (ACCT_ID)

CREATE TABLE TEST.HISTORY2 (ACCT_ID INTEGER NOT NULL, TELLER_ID

SMALLINT NOT NULL, BRANCH_ID SMALLINT NOT NULL, BALANCE
DECIMAL(15,2) NOT NULL, DELTA DECIMAL(9,2) NOT NULL, PID
INTEGER NOT NULL, TSTMP TIMESTAMP NOT NULL WITH DEFAULT,
ACCTNAME CHAR(20) NOT NULL, TEMP CHAR(6) NOT
NULL) IN TESTHIST2
CREATE INDEX TEST.H2INDEX ON TEST.HISTORY2 (ACCT_ID)

The file loadtest.ddl will be used to load data into the test tables.
• db2 -tvf loadtest.ddl
load from hist200k.del of del messages ldhtest1.msg replace into test.history1
statistics yes copy no

load from hist200k.del of del messages ldhtest1.msg replace into test.history2

statistics yes copy no


INSERT INTO TEST.BRANCH SELECT * FROM inst464.BRANCH

INSERT INTO TEST.TELLER SELECT * FROM inst464.TELLER

Use the SQL query in the file testcontainers.sql to list the table space
containers for the three new tablespaces.
• db2 -tvf testcontainers.sql
select tbsp_id as TS_ID,
substr(tbsp_name,1,20) as TS_name ,
container_type , substr(container_name,1,80) as container_name
, total_pages
from table(mon_get_container(null,-2)) as cont
where tbsp_name like 'TEST%'
order by tbsp_id, container_id

TOTAL_PAGES
--------- ----------- -------------------- ---------------- ----------------------
------------------------ ------------
8 TESTSMALL FILE_EXTENT_TAG
9 TESTHIST1 FILE_EXTENT_TAG /database/inst464/testhist1
5000
5000
Create a database level offline backup before you begin to make changes to the
tablespace containers.


• db2 terminate
• db2 backup db tp1 to $HOME/backups/u5 compress
The db2relocatedb command can be used to update the table space container
definition for the TP1 database to reflect the change made outside of Db2's
control. This must be done with the database stopped. You will rename the
container for the DMS managed tablespace TESTHIST2, then use
db2relocatedb to reflect the name change in the database control files.
You can use the db2relocatedb generate option to create a database
configuration file for a Db2 database.
• db2relocatedb -g tp1config -d tp1
• cat tp1config
The generated configuration looks similar to the following:
DB_NAME=tp1,tp1
DB_PATH=/database,/database
NODENUM=0
STORAGE_PATH=/dbauto/path1,/dbauto/path1
STORAGE_PATH=/dbauto/path2,/dbauto/path2
CONT_PATH=/database/inst464/NODE0000/SQL00001/tp1hist,/database/inst464/NODE0000/S
QL00001/tp1hist
CONT_PATH=/database/inst464/NODE0000/SQL00001/tp1acctd,/database/inst464/NODE0000/
SQL00001/tp1acctd
CONT_PATH=/database/inst464/testhist1,/database/inst464/testhist1
CONT_PATH=/database/inst464/testhist2,/database/inst464/testhist2
LOG_DIR=/dblogs/inst464/tp1/,/dblogs/inst464/tp1/
LOGARCHMETH1=DISK:/home/inst464/archive/,DISK:/home/inst464/archive/
• db2stop force
• cd /database/inst464
• mv testhist2 testhist2_new
• cd $HOME/bin
The file relocatedms.ddl which will be used to alter the TESTHIST2 container
name in the Db2 table space definition files.


• cat relocatedms.ddl
The generated configuration will similar to the following:
DB_NAME=TP1
DB_PATH=/database
INSTANCE=inst464
CONT_PATH=/database/inst464/testhist2,/database/inst464/testhist2_new
11. Enter the following command in the Linux terminal session:
• db2relocatedb -f relocatedms.ddl
Files and control structures were changed successfully.
DBT1000I The tool completed successfully.
Restart the instance and connect to the TP1 database to check the new
container definition. Use the SQL query in the file testcontainers.sql to list the
table space containers.
• db2start
• db2 -tf testcontainers.sql
The output from this SQL will look similar to the following:
TOTAL_PAGES
--------- ----------- -------------------- ---------------- ----------------------
------------------------ ------------
5000
10 TESTHIST2 FILE_EXTENT_TAG /database/inst464/testhist2_new
5000
To verify access to the manually moved tablespace container, run the
RUNSTATS command for the Db2 table TEST.HISTORY2
• db2 runstats on table test.history2 and indexes all
• db2 terminate

Task 2. Change the container for a DMS table space and

convert a DMS table space using a redirected restore.
You can use the full database backup to perform a redirected restore of the two DMS
managed tablespaces TESTHIST1 and TESTHIST2. The tablespace TESTHIST1 will
be converted to use Automatic Storage management. The tablespace TESTHIST2 will
be assigned a new container name. These changes can be performed using online
tablespace restores. First activate the database TP1.
In order to change the container used for the TESTHIST2 table space using a
redirected restore, you need to get information on the current container for that
table space. Use the GENERATE SCRIPT option of the RESTORE command
to create a script for the redirected restore of the TESTHIST1 and TESTHIST2
table spaces.
• db2 " restore db tp1 tablespace(testhist1,testhist2) online from
$HOME/backups/u5 redirect generate script redirect.cmd "
• cat redirect.cmd
The output will include a complete sequence of commands that can be used to
perform a redirected restore. The script will look similar to the following:
-- *****************************************************************************
-- ** automatically created redirect restore script
-- *****************************************************************************
UPDATE COMMAND OPTIONS USING S ON Z ON TP1_NODE0000.out V ON;
SET CLIENT ATTACH_MEMBER 0;
SET CLIENT CONNECT_MEMBER 0;
-- *****************************************************************************
-- ** automatically created redirect restore script
-- *****************************************************************************
RESTORE DATABASE TP1
-- USER <username>
-- USING '<password>'
TABLESPACE (
"TESTHIST1"
, "TESTHIST2"
)
ONLINE
FROM '/home/inst464/backups/u5'
TAKEN AT 20161101133236

-- DBPATH ON '<target-directory>'
INTO TP1
-- NEWLOGPATH '/dblogs/inst464/tp1/NODE0000/LOGSTREAM0000/'
-- WITH <num-buff> BUFFERS
-- BUFFER <buffer-size>
-- REPLACE HISTORY FILE
-- REPLACE EXISTING
REDIRECT
-- PARALLELISM <n>
-- COMPRLIB '<lib-name>'
-- COMPROPTS '<options-string>'
-- WITHOUT ROLLING FORWARD
-- WITHOUT PROMPTING
;
-- *****************************************************************************
-- ** storage group definition
-- ** Default storage group ID = 0
-- ** Number of storage groups = 2
-- *****************************************************************************
-- *****************************************************************************
-- ** Storage group name = IBMSTOGROUP
-- *****************************************************************************
-- SET STOGROUP PATHS FOR IBMSTOGROUP
-- ;
-- *****************************************************************************
-- ** Storage group name = TP1SG1
-- *****************************************************************************
-- SET STOGROUP PATHS FOR TP1SG1
-- ;
-- *****************************************************************************
-- ** table space definition
-- *****************************************************************************
-- *****************************************************************************

-- ** Tablespace name = TESTHIST1

-- ** Tablespace Content Type = All permanent data. Large table
space.
-- *****************************************************************************
SET TABLESPACE CONTAINERS FOR 9
USING (
FILE '/database/inst464/testhist1' 5000
);
-- *****************************************************************************
-- ** Tablespace name = TESTHIST2
-- ** Tablespace Content Type = All permanent data. Large table
space.
-- *****************************************************************************
SET TABLESPACE CONTAINERS FOR 10
USING (
FILE '/database/inst464/testhist2' 5000
);

-- *****************************************************************************
-- ** start redirected restore
-- *****************************************************************************
RESTORE DATABASE TP1 CONTINUE;
-- *****************************************************************************
-- ** end of file
-- *****************************************************************************
During the redirected restore, the container for the TESTHIST2 table space will
be changed to a file named /database/inst464/testhist2_2. The size of the new
container will be the same as the original container. The TESTHIST1 table
space will be converted to use automatic storage.
First, restore the TESTHIST1 and TESTHIST2 table spaces using the
REDIRECT option to allow definition of new containers. Run the Db2
RESTORE command to restore the table space from backup in the
$HOME/backups/u5 directory
• db2 " restore db tp1 tablespace(testhist1,testhist2) online from
$HOME/backups/u5 redirect "
The command should complete with a message:
SQL1277W A redirected restore operation is being performed. During a table
space restore, only table spaces being restored can have their paths
reconfigured. During a database restore, storage group storage paths and DMS
table space containers can be reconfigured.
Check the table space status for TESTHIST1 and TESTHIST2 using the LIST
TABLESPACES command. Note the tablespace ID numbers.


• db2 LIST TABLESPACES | more
The output will include information similar to the following:
Tablespace ID = 9
Name = TESTHIST1
State = 0x2002100
Restore pending
Restore in progress
Tablespace ID = 10
Name = TESTHIST2
State = 0x2003100
Restore pending
Storage must be defined
Restore in progress
Convert the tablespace TESTHIST1 to utilize automatic storage management
using the SET TABLESPACE CONTAINER command.
• db2 " SET TABLESPACE CONTAINERS FOR 9 USING automatic
storage "
Note that there is no option in SET TABLESPACE CONTAINERS to assign a
storage group, so this tablespace will utilize the default storage group,
IBMSTOGROUP.
List the new container information for the TESTHIST1 table space using a LIST
TABLESPACE CONTAINERS command.


• db2 LIST TABLESPACE CONTAINERS FOR 9 SHOW DETAIL
Container ID = 0
Name =
/dbauto/path1/inst464/NODE0000/TP1/T0000009/C0000000.LRG
Type = File
Total pages = 5056
Accessible = Yes
Define a new container for the DMS managed, TESTHIST2 table space using
the SET TABLESPACE CONTAINER command.
• db2 " set tablespace containers for 10 using (file
'/database/inst464/testhist2_2' 5000) "
List the new container information for the TESTHIST2 table space using a LIST
TABLESPACE CONTAINERS command.
• db2 LIST TABLESPACE CONTAINERS FOR 10 SHOW DETAIL
Container ID = 0
Name = /database/inst464/testhist2_2
Type = File
Total pages = 5000
Accessible = Yes
Complete the restore process by issuing the RESTORE command with the
CONTINUE option and roll forward the table space to the end of the logs.


• db2 restore database TP1 continue
• db2 rollforward database tp1 to end of logs tablespace online
Rollforward Status
Input database alias = tp1

Number of members have returned status = 1
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = -
Last committed transaction = 2014-05-15-13.57.30.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.

Use the SQL in the file testcontainers.sql to show the current tablespace
containers assigned to the two tablespaces, TESTHIST1 and TESTHIST2.
• db2 -tf testcontainers.sql
TOTAL_PAGES
--------- ----------- -------------------- ---------------- ----------------------
------------------ ----------
9 TESTHIST1 FILE_EXTENT_TAG
10 TESTHIST2 FILE_EXTENT_TAG /database/inst464/testhist2_2
5000
• db2 terminate

Task 3. Use the TRANSPORT option of RESTORE to copy the

tablespaces used for a schema of objects into a test
database.
The objects created for the schema TEST reside in three distinct tablespaces,
TESTSMALL, TESTHIST1 and TESTHIST2. Create a new offline database backup of
the TP1 database. You can use the TRANSPORT option of RESTORE to copy those
tablespaces and the objects into a different database. You will create a database
named TEST to be the target database for the TRANSPORT.
• db2 terminate
• rm $HOME/backups/u5/*
• db2 backup db tp1 to $HOME/backups/u5 compress
• db2 create database test on /database (this may take a few minutes)
Use the TRANSPORT option of RESTORES to copy the three tablespaces,
TESTSMALL, TESTHIST1 and TESTHIST2 from the database backup image
into the database named TEST. You will use a redirected RESTORE to be able
to change the container assignments for the DMS managed tablespaces.
• db2 " restore db tp1 tablespace(testsmall,testhist1,testhist2)
schema(test) from /home/inst464/backups/u5 transport into test
redirect "
SQL1277W A redirected restore operation is being performed. During a table
space restore, only table spaces being restored can have their paths
reconfigured. During a database restore, storage group storage paths and DMS
table space containers can be reconfigured.
You will convert both DMS managed tablespaces TESTHIST1 and TESTHIST2
to automatic storage management.
• db2 set tablespace containers for 9 using automatic storage
• db2 set tablespace containers for 10 using automatic storage
Complete the RESTORE processing now that all of the tablespaces have
containers defined.


• db2 restore db tp1 continue
No ROLLFORWARD command is required. If an online backup image was
utilized, Db2 would use the included logs to make the restored tablespaces
consistent.
Connect to the TEST database and use the SQL statement in the file
testcontainers.sql to check the container assignments for the transported
copies of the tablespaces.
• db2 connect to test
• db2 -tvf testcontainers.sql
TOTAL_PAGES
--------- ----------- -------------------- ---------------- ----------------------
------------------ ----------
/database/inst464/NODE0000/TEST/T0000003/C0000000.LRG 1024
The tablespaces are all defined using automatic storage management. The
tablespace ID numbers are different in the target database than those in the
source database.
Use the command file unit5_end.cmd to drop the tablespaces used for the
TEST objects in the TP1 database and to drop the TEST database.
• db2 terminate
• unit5_end.cmd
7. Close the terminal and then logout of the Linux operating system
Results:
You used db2relocatedb to rename a table space container. You made table
space container changes, including converting DMS table spaces to use
Automatic Storage management during a redirected restore. You utilized the
TRANSPORT option of RESTORE to copy several table spaces and the
objects for a schema to a different database.

Unit summary
• Explain the facility of the Db2 RESTORE command to recover table
spaces to different containers
containers during a redirected restore
• Utilize the SET STOGROUP PATHS command to change the storage
paths for automatic storage tablespaces in storage groups
• Plan the use of redirected restore as part of a disaster recovery
• Describe two methods that can be used to convert a DMS table space to
utilize Automatic Storage
• Use the GENERATE SCRIPT option of RESTORE to set up a command
script for a redirected restore operation
• Copy schemas from one database to another using the TRANSPORT
option of the RESTORE utility
• Use db2relocatedb when moving or copying Db2 databases with non-Db2
utilities
Unit summary

Db2 Incremental backup
Db2 Incremental backup

Unit 6 Db2 Incremental backup

Unit objectives
• Plan a database recovery strategy that includes both full and
Incremental backups to reduce the duration and size of database
backups
• Implement a physical database design to take advantage of
Incremental backups of selected table spaces
• Check Tablespace trackmod status using SQL query with the
MON_GET_TABLESPACE table function
• Utilize an Incremental restore to recover a Db2 database or table
space from incremental backup images
• Use the LIST UTILITIES command to track the processing of an
Incremental backup or restore process
Db2 Incremental backup © Copyright IBM Corporation 2018
Unit objectives

Database Backup and Recovery issues
Sunday Mon Tue Wed Thu Fri Sat Sunday

Backups
• Time required for backups:

• Size of Database Full Table space
Full Database
Backups
Backup • I/O performance of backup media
• Space required for backups and Logs:
• Number of backup images retained
• Full database or Table space backups
• Number of logs needed to support recovery
• Use of BACKUP utility COMPRESS option
• Using LOGARCHCOMPR1/2 Database CFG options
to compress archived logs
• Time required for recovery:
• Time to restore backup images
• Time to roll forward logs since last backup
Logs
Database Backup and Recovery issues

As the size of databases, and particularly warehouses, continues to grow into the
multiple terabyte and petabyte range, the time and hardware resources required to
back up and recover these databases is growing substantially. There are a number of
important issues to be considered when planning the backup and recovery strategy for
a Db2 database.
Time Required for Backups: The time required to produce a backup image might
increase linearly with the size of the database being copied, so for very large databases
careful planning will be required to permit the backups to complete during the weekly
processing schedule. Another critical factor affecting the duration of a backup process
will be the I/O performance of the backup media used. If the backup will be stored on
disk, the performance of the server's I/O subsystem would be a limiting factor. If the
backups are stored on tape devices, the availability of the tape drives could delay the
backup processing. If server-based backup software like Tivoli Storage Manager is
used for backup storage, the network performance and utilization of the backup server
could lengthen the backup window.
To reduce the amount of time that the database is not available, consider using online
backup operations. You can only use an online backup image for recovery if you have
the logs that span the time during which the backup operation was running. Offline
backup operations are faster than online backup operations.

Space Required for Backups and Logs: Your database recovery plan might include
a combination of full database backups and incremental backup operations. You might
decide to take full database backups regularly to provide the fewest number of backup
images to manage. Table space backup images are useful for efficient recovery from
an isolated disk failure or an application error. You should also consider saving at least
two full database backup images and their associated logs as an extra precaution.
If a database contains large amounts of long field and large object (LOB) data, backing
up the database could be very time-consuming. The Backup Utility lets you back up
selected table spaces. If you use DMS table spaces, you can store different types of
data in their own table spaces to reduce the time required for backup operations. You
can keep table data in one table space, long field and LOB data in another table space,
and indexes in yet another table space. By storing long field and LOB data in separate
table spaces, the time required to complete a backup operation can be reduced by
choosing not to back up the table space containing the long field and LOB data. If the
long field and LOB data is critical to your business, backing up these table spaces
should be considered against the time required to complete the restore operation for
these table spaces.
Using the COMPRESS option of the BACKUP utility might significantly reduce the size
of each database backup. Depending on the system resources, using a compressed
backup could extend the backup duration based on increased CPU usage or reduce
backup time by reducing the number of I/Os required.
The LOGARCHCOMPR1 and LOGARCHCOMPR2 database configuration option
control compression for archived log files. These can be used to reduce storage
requirements for the archived logs, retained to support various recovery tasks.
Time required for recovery: The time required to recover a database is made up of
two parts: the time required to complete the restoration of the backup image(s); and, if
the database is enabled for forward recovery, the time required to apply the logs during
the roll forward operation. When formulating a recovery plan, you should take these
recovery costs and their impact on your business operations into account.
Testing your overall recovery plan will assist you in determining whether the time
required to recover the database is reasonable given your business requirements.
Following each test, you might want to increase the frequency with which you take a
backup. If roll forward recovery is part of your strategy, this will reduce the number of
logs that are archived between backups and, as a result, reduce the time required to roll
the database forward after a restore operation.
If you reorganize a table, you should back up the affected table spaces after the
operation completes. If you have to restore the table spaces, you will not have to roll
forward through the data reorganization.

Full versus Incremental backups

Backups
Full Database Full Table space

Backup Backups
Incremental (Cumulative)
Table space Backups
Logs
Full versus Incremental backups

Full database and table space backups are not always the best approach when dealing
with large databases, because the storage requirements for multiple copies of such
databases can be very large. Consider the following issues:
• When a small percentage of the data in a warehouse changes, it should not be
necessary to backup the entire database.
• Appending table spaces to existing databases and then taking only table space
backups is risky, because there is no guarantee that nothing outside of the
backed up table spaces has changed between table space backups.
Db2 supports incremental backup and recovery. An Incremental backup is a backup
image that contains only pages that have been updated since the previous backup was
taken. In addition to updated data and index pages, each incremental backup image
also contains all of the initial database metadata (such as database configuration, table
space definitions, database history, and so on) that is normally stored in full backup
images.

In the example, there are two database backup strategies:

Strategy 1: A full database backup image is created each Sunday and full table space
backups of critical table spaces are created each day. If these are large table spaces
and only a small percentage of the data changes each day, these backups will contain
mostly unchanged data.
Strategy 2: A full database backup image is created each Sunday and each day
incremental table space backups are created. These incremental backups are
cumulative, containing all the changed data since the last full backup. The incremental
backups will increase in size from day to day, but if a relatively small percentage of the
data changes each week, these backups will take less time and require less storage
space than the full backups. As a variation of this plan, the table space backups could
be replaced with a daily incremental database backup that would contain all the
changes to the database since the full database backup on Sunday. Any table spaces
that are read only will be skipped during the backup processing.

Delta versus Incremental backups

Backups
Delta Table space

Backups
Full Database
Backup
Table space Backups
Logs
Delta versus Incremental backups

Two types of incremental backup are supported:
• Incremental: An incremental backup image is a copy of all database data that
has changed since the most recent, successful, full backup operation. This is also
known as a cumulative backup image, because a series of incremental backups
taken over time will each have the contents of the previous incremental backup
image. The predecessor of an incremental backup image is always the most
recent successful full backup of the same object.
• Delta: A delta, or incremental delta, backup image is a copy of all database data
that has changed since the last successful backup (full, incremental, or delta) of
the table space in question. This is also known as a differential, or noncumulative,
backup image. The predecessor of a delta backup image is the most recent
successful backup containing a copy of each of the table spaces in the delta
backup image.
The key difference between incremental and delta backup images is their behavior
when successive backups are taken of an object that is continually changing over time.
Each successive incremental image contains the entire contents of the previous
incremental image, plus any data that has changed, or is new, since the previous
backup was produced. Delta backup images contain only the pages that have changed
since the previous image was produced.

In the example, the daily delta table space backups vary in size depending on the
amount of new database updates each day. The equivalent Incremental table space
backups will increase in size each day to include any newly updated pages. Changing
the same page multiple times will not increase the size of the backup images. Notice
that each delta backup points to the previous day's backup rather than back to the full
backup.
The use of the delta table space backups should reduce the time required for each daily
backup as well as the total space required to store the backup images. The Incremental
backup strategy might support faster recovery because only the full backup and the
single last Incremental backup images are restored, where using the delta backups for
recovery would require the entire set of delta backups to be restored over the full
backup to complete the recovery process.

Incremental backup: Impact

Backups
• Time required for backups:

• Skip reading unchanged table spaces
Full Table space Backups
• Only write changed pages to backup image
Backup
• Space required for backups and Logs:

• Only write changed pages
• Only need logs since latest incremental backup
• Time required for recovery:

• Restoring multiple backup images could take longer than
processing a single backup
• Log processing begins with most recent backup timestamp
Logs
Incremental backup: Impact

There are potentially some advantages and disadvantages to implementing incremental
or delta backups:
• Time required for backups: Db2 can detect which table spaces have not been
changed since the previous backup and can skip reading these table spaces,
which could save all the time normally spent reading these table spaces. Db2
also checks which pages have been updated since the previous backup and will
not write the unchanged pages to the backup, saving the I/O time for these
pages. The higher the percentage of unchanged pages, the greater the time
savings during backup.
• Space required for backups and Logs: Incremental backups only include the
changed data and index pages in the output image, which should reduce the size
of the backup storage requirement. Implementing Incremental backups might
allow more frequent backup copies and reduce the number of logs needed for
recovery.

• Time required for recovery: The time required for recovery using the
incremental backup images could in some cases take longer than recovering
using full backups. For example, recovery using an incremental table space
backup would require reading and restoring the incremental backup and the full
database or table space backup that it is based on compared to restoring a single
full table space backup. The smaller size of incremental backup images could
minimize the impact. Restoring a long sequence of delta backups could also
lengthen the restore processing.
• The roll forward will only require the logs since the last incremental backup, so to
optimize recovery time it might be necessary to schedule the incremental or delta
backups to minimize the number of Db2 logs needed for recovery. For example,
you could run an incremental or delta backup following a large update process to
avoid having to redo the associated logs during a recovery.

Mixed Delta and Incremental backups

Backups
Full Database Delta Table space
Backup Backups
Table space Backups
Logs
Mixed Delta and Incremental backups

This shows a sequence of daily backups with a mixture of backup options.
1. Sunday: A full database backup image is created to provide for a broad range
of recovery needs.
2. Monday: A delta backup of selected table spaces is created with the updates
for those table spaces since Sunday's full backup.
3. Tuesday: A second delta backup of the same set of table spaces contains just
the updates for those table spaces since the last delta backup on Monday. If
any of the table spaces were not changed on Monday, Db2 can bypass the
reading of those table spaces.
4. Wednesday: An incremental table space backup is taken for the same subset
of table spaces. This will include all the changes since Sunday's full database
backup. This backup would allow a recovery to be done without using the delta
backups from Monday and Tuesday.
5. Thursday: A third delta backup of the same set of table spaces contains just
the updates for those table spaces since the incremental backup on
Wednesday. If any of the table spaces were not changed on Thursday, Db2 can
bypass the reading of those table spaces.

6. Friday: An new incremental table space backup is taken for the same subset of
table spaces. This will include all the changes since Sunday's full database
backup. This backup would allow a recovery to be done without using any of the
backups since Sunday.
7. Saturday: A fourth delta backup of the same set of table spaces contains just
the updates for those table spaces since the incremental backup on Friday.
Mixing the use of incremental and delta backups could provide a balance between the
desire to minimize backup size and duration with the requirements to recover any
portion of the database efficiently.

Incremental backups with Circular logging

Backups
Incremental
Full Database DB Backup
Backup (offline)
(offline)
Logs
• Only database backups can be created, table space backups are not allowed.
• Backups must be created offline, with no concurrent access to the database.
• Following a restore, no roll forward can be performed.
Incremental backups with Circular logging

Incremental backups can be utilized with Db2 databases that are using circular logging.
The limitations imposed by using circular logs would still apply to any Incremental
backups:
• Only database backups can be created, table space backups are not allowed.
• Backups must be created offline, with no concurrent access to the database.
• Following a restore, no roll forward can be performed.
The advantage of using incremental backups in these databases would be to limit the
time that the database is unavailable to users and also to reduce the size of each
incremental backup image. With large databases that are mostly read only, it might be
feasible to create daily incremental backups where a daily full database backup is not
possible. This might reduce the amount of work lost when recovering the database.

Incremental database backups

Backups
Full Tablespace
Full DB backup
Backup
Incremental
DB backup
Logs
db2 backup DATABASE tp1 to....
db2 create TABLESPACE dms10........

db2 backup DATABASE tp1 incremental to.... FAILS!
db2 backup DATABASE tp1 TABLESPACE(dms10) to....
db2 backup DATABASE tp1 incremental to....Succeeds
Incremental database backups

For a database incremental backup to be taken, there must be a previous full backup of
the database. If any new table spaces have been created since the full database
backup, it will not be possible to create a database incremental backup image until at
least one full backup of each new table space is taken.
For example, a full database backup of the TP1 database is taken on Sunday. On
Monday, a new table space, DMS10, is created. If a database incremental backup was
requested on Tuesday, the Backup Utility would fail because no full backup image
exists for the new table space. In order to avoid taking another full database backup, a
full table space backup image of the new table space DMS10, could be taken. After the
table space backup completes, a database incremental backup would be allowed. For
the incremental backup image to be used in a later recovery, both the full database
backup from Sunday and the full table space backup of DMS10 would be required.

Implementation of Incremental backup

• Database configuration parameter TRACKMOD:
 NO: Incremental backups are not allowed (default)
 YES: Incremental backups are allowed:
− Table Space level - Change since last backup
− Page level - Last update LSN
• Full Database backup required
before first Incremental backup DB CFG TRACKMOD ON
Db2 Database
ASTS1
SYSCATSPACE
Table Space DMSHIST
Information Table Space
Table Space Information
Information
db2 UPDATE DB CFG FOR TP1 USING TRACKMOD ON
Implementation of Incremental backup

To enable the tracking of database updates, Db2 added the database configuration
parameter, trackmod, which can have one of two accepted values:
• NO: Incremental backup is not permitted with this configuration. Database page
updates are not tracked or recorded in any way. This is the default.
• YES: Incremental backup is permitted with this configuration. When update
tracking is enabled, the change becomes effective at the first successful
connection to any database in the instance.
A full database backup is necessary before an incremental backup can be taken.

Backup Utility options

>>-BACKUP--+-DATABASE-+--database-alias------------------------->
'-DB-------'
>--+-------------------------------------+---------------------->
'-USER--username--+-----------------+-'
'-USING--password-'
>--+----------------------------------------------------------------------------+-->
'-ON--+-+-DBPARTITIONNUM--+--| Partition number(s) |-------------------------+-'
| '-DBPARTITIONNUMS-' |
'-ALL DBPARTITIONNUMS--+-----------------------------------------------+-'
'-EXCEPT--+-DBPARTITIONNUM--+--| Partition number(s)
'-DBPARTITIONNUMS-'
>--+---------------------------------------+--+--------+-------->
| .-,---------------. | '-ONLINE-'
| V | |
'-TABLESPACE--(----tablespace-name-+--)-'
>--+------------------------+----------------------------------->
'-INCREMENTAL--+-------+-'
'-DELTA-'
Backup Utility options

This shows the options for a Db2 BACKUP command that control use of incremental
backups.
To create an incremental or cumulative backup image, the BACKUP command would
include the INCREMENTAL keyword. The incremental backup could be for a database
or selected table spaces. The backup could be online or offline.
To create a delta or noncumulative backup image, the BACKUP command would
include the INCREMENTAL DELTA keywords. The delta backup could be for a
database or selected table spaces. The backup could be online or offline.

Db2 Incremental BACKUP command examples

Backups
Full Table space Backups

Full DB
Backup Incremental (Cumulative)
Table space Backups
Delta Table space
Backups
1)db2 backup db tp1 to .....
2)db2 backup db tp1 tablespace(tp1hist) online incremental to .....
3)db2 backup db tp1 tablespace(tp1hist) online to .....
4)backup db tp1 tablespace(tp1hist) online incremental delta to .....
5)backup db tp1 tablespace(tp1hist) online incremental to ...
Db2 Incremental BACKUP command examples

Here are some examples of Db2 BACKUP commands creating a variety of backup
types.
1. The first backup is a full database backup.
2. This backup command includes the options ONLINE INCREMENTAL to create
a table space backup of the TP1HIST table space with all of the changes since
the full database backup.
3. This backup command does not include the option INCREMENTAL, so a full
table space backup of the TP1HIST table space will be created. This provides a
newer full table space image for subsequent incremental backups.
4. This backup command includes the options ONLINE INCREMENTAL DELTA
to create a table space backup of the TP1HIST table space with all of the
changes since the previous full table space backup.
5. This backup command includes the options ONLINE INCREMENTAL to create
a table space backup of the TP1HIST table space with all of the changes since
the previous full table space backup, which is currently the last full backup of
this table space.

Tracking updates to table spaces and pages

Backups
Delta
Full Incremental
Last backup ID LSN Last backup ID LSN

Last Full backup ID LSN Last Full backup ID LSN
Updated Since Backup Updated Since Backup
Table Space ASTS1 Table Space TP1HIST
Upd. LSN Upd. LSN Upd. LSN Upd. LSN
Logs
Tracking updates to table spaces and pages

When the TRACKMOD database configuration parameter is set to YES, Db2 begins to
maintain additional control information for each table space in the database. Db2 also
has control information on each data and index page that can be used to determine the
place in the Db2 logs when the last update to each page occurred.
For each table space, there will be status information that indicates if that table space
has undergone any modifications since the previous backup. There will also be a set of
markers for each table space, indicating the LSN and image time stamp of the last
successful full and incremental backups of each table space. If these markers indicate
that there have not been any changes to the table space since the predecessor of the
current backup, then none of the table space data will be read by the backup process.
Alternatively, if the marker indicates that there have been updates to the table space
since the previous backup, then that table space will be examined by the backup
processing to determine which pages need to be backed up.
The table space information is saved in the header of each backup and can be viewed
using the db2ckbkp command with the -o to display detailed information from the
database objects.
Note the information contains the time stamps and log LSNs for both the previous full
backup image and the last backup which in the example points to a newer incremental
backup image.

The final determination about whether a page is included in a backup image will be
done by inspecting the page change LSN on each page, and comparing this with the
LSN of this backup’s predecessor. If the page has been updated since the previous
backup, then it will be copied into the backup image. Otherwise, it will not.
Although minimal, the tracking of updates to the database can have an impact on the
run time performance of transactions which update or insert data. At run time,
whenever a page is written to disk after any modification to it, an additional overhead
will be incurred in order to track this modification in the manner described above. This
additional overhead will be an examination of the table space dirty flag in the table
space definition in memory. If this is the first modification to a clean table space, then
the table space definition will be updated and written to disk. Subsequent updates to the
same table space will inspect the tracking indicator, but will not require the additional
I/O.

Building a new Delta backup (Option 1)

Backups
Delta
Full Incremental

Logs
Building a new Delta backup (Option 1)

In the slide, the next backup taken on Saturday is a delta backup image for the two
table spaces ASTS1 and TP1HIST. Since the delta backup is noncumulative, the key
pointers are to the last backup, rather than the last full backup.
The ASTS1 table space has not had any updates since the last backup, Friday's delta
backup, so the Saturday backup can skip reading the ASTS1 table space entirely.
The TP1HIST table space has been updated since the last backup, so Db2 will scan
the entire table space. Only the pages with LSNs that are later than the last backup
need to be included in this new backup image. This might be a very small portion of the
TP1HIST table space so the backup can still be much smaller than a full table space
backup.

Building a new Incremental backup (Option 2)

Backups
Delta
Full
Incremental

Logs
Building a new Incremental backup (Option 2)

In the slide, the next backup taken on Saturday is an incremental backup image for the
two table spaces ASTS1 and TP1HIST. Since the incremental backup is cumulative,
the key pointers are to the Last Full Backup, rather than the Last Backup.
The ASTS1 table space has been updated since the last full backup, Sunday's full
database backup, so the Saturday backup must read all of the pages in the ASTS1
table space to check the update LSNs. Every page with an update LSN after last
Sunday's backup needs to be included in the backup image.
The TP1HIST table space has also been updated since the last full backup, so Db2 will
scan the entire table space. Only the pages with LSNs that are later than the full backup
need to be included in this new backup image. This might be a small percentage of the
TP1HIST table space so the backup can still be much smaller than a full table space
backup.

Using MON_GET_TABLESPACE to check incremental backup

status for tablespaces
SELECT SUBSTR(TBSP_NAME,1,24) AS TBSP_NAME, TBSP_ID,
SUBSTR(TBSP_STATE,1,40) AS TBSP_STATE,
TBSP_TRACKMOD_STATE
FROM TABLE( MON_GET_TABLESPACE(NULL,-2)) as MONTBSP
ORDER BY TBSP_ID
TBSP_NAME TBSP_ID TBSP_STATE TBSP_TRACKMOD_STATE

-------------- ---------- ------------- --------------------
SYSCATSPACE 0 NORMAL CLEAN
TEMPSPACE1 1 NORMAL CLEAN
USERSPACE1 2 NORMAL CLEAN
TP1SMALL 3 NORMAL DIRTY
TP1HIST 4 NORMAL ININCREMENTAL
TP1ACCTD 5 NORMAL DIRTY
TP1ACCTI 6 NORMAL CLEAN
SYSTOOLSPACE 7 NORMAL CLEAN
Using MON_GET_TABLESPACE to check incremental backup status for tablespaces

You can use the TBSP_TRACKMOD_STATE monitor element from the
MON_GET_TABLESPACE table function to determine the modification status of a
table space.
The status of a table space can be in one of the following states:
• CLEAN - No modifications occurred in the table space since the previous backup.
If an incremental or delta backup is executed at this time, no data pages from this
table space would be backed up.
• DIRTY - Table space contains data that needs to be picked up by the next
backup.
• ININCREMENTAL - Table space contains modifications that were copied into an
incremental backup. This state is in a DIRTY state relative to a full backup such
that a future incremental backup needs to include some pages from this pool.
This state is also in a CLEAN state such that a future delta backup does not need
to include any pages from this pool.
• READFULL - The latest table space modification state change was caused by a
dirty table space that is being read by a full backup that might not have completed
successfully, or is currently in progress.

• READINCREMENTAL - The latest table space modification state change was

caused by a dirty table space that is being read by an incremental backup that
might not have completed successfully, or is currently in progress.
• UNAVAILABLE - The trackmod configuration parameter is set to No. Therefore,
no table space modification status information is available.

Incremental backup: Read and Write I/O

• Database Reads for backup
 If any change in table space, read every tablespace page
• Write to backup image:
 All changed Data pages, Index pages, XML pages and Column Organized
pages changed since last backup
 All LOB and LF data must be copied to backup image
Last backup ID LSN Last backup ID LSN Last backup ID LSN

Last Full backup ID LSN Last Full backup ID LSN Last Full backup ID LSN
Updated Since Backup Updated Since Backup Updated Since Backup
data pages index pages

Table Space DMSD01 Table Space DMSI01 LOB data
Table Space DMSL01
Incremental backup: Read and Write I/O

In order to optimize the processing for Incremental backups, it is important to
understand which portion of the database or table space is read during the backup and
how much of the database or table space is written to the backup image.
If any updates have taken place for a table space, then the backup must read the entire
table space to check each page's last update LSN. This means that if a table space
contains several tables, a one-row update in a small table could force several very large
tables to be scanned during the backup. It would be more efficient to place large tables
that are read only in separate table spaces to avoid this processing. If the backup finds
that there have not been any changes in a table space since the previous backup, the
table space will be skipped.
Db2 will check the update LSN for each page in each table space that has been
updated to see if this page needs to be included in the backup.
The page level checking includes:
• Data pages
• Index pages
• XML pages
• Column organized pages

Db2 cannot detect whether LOB and Long field data have been updated so all of these
data types will be included in every Incremental backup. If the LOB data is not changed
often, placing the LOB data in a separate DMS Large table space might allow Db2 to
skip processing the entire DMS Large table space because Db2 does know if there
have not been any changes at the table space level.
Placing the data components and index portions of a table in separate table spaces
could allow Db2 to skip reading the index table space if the indexes have not been
updated when the data portion has been updated.

Incremental Backup: db2diag.log

2014-05-08-11.17.04.427748-240 E4799260E496 LEVEL: Info
INSTANCE: inst491 NODE : 000 DB : TP1
APPHDL : 0-41 APPID: *LOCAL.inst491.140508151656
AUTHID : INST491 HOSTNAME: ibmclass
EDUID : 51 EDUNAME: db2agent (TP1) 0
FUNCTION: DB2 UDB, database utilities, sqlubSetupJobControl, probe:1751
MESSAGE : Starting an online incremental db backup.
2014-05-08-11.17.04.490639-240 E4835076E556 LEVEL: Info

EDUID : 60 EDUNAME: db2bm.51.0 (TP1) 0
FUNCTION: DB2 UDB, database utilities, sqlubBMProcessData, probe:820
MESSAGE : Backing up tablespace
DATA #1 : Pool ID, PD_TYPE_POOL_ID, 2 bytes 5
DATA #2 : String, 8 bytes TP1ACCTD
2014-05-08-11.17.08.213214-240 E4874464E573 LEVEL: Info

MESSAGE : Incremental backup skipping tablespace
DATA #1 : Pool ID, PD_TYPE_POOL_ID, 2 bytes 6
DATA #2 : String, 8 bytes TP1ACCTI
Incremental Backup: db2diag.log

The Db2 Backup Utility will generate informational level messages in the db2diag.log
file for the instance, if the diaglevel DBM configuration parameter is set to 4.
The slide shows an example of the messages generated by an incremental backup.
There is a message that states:
"Incremental backup skipping tablespace"
This shows that the table space, TP1ACCTD, has changed since the last backup and
the Backup Utility will read its pages, but a tablespace used to store indexes,
TP1ACCTI has not changed and will be skipped by the incremental backup processing.

Database design for Incremental backups

• Put read only tables in table space(s) separated from tables that are
frequently changed
• Place infrequently updated LOB data in separate table space
• Run full backups after REORG because most of the pages will be
changed during REORG processing
• Define a range-partitioned table using multiple table spaces when
some ranges will be static while other ranges are updated or new
ranges are attached
Database design for Incremental backups

During database design, there are a number of Db2 options that can impact the
processing performed by an incremental backup. These choices need to be carefully
balanced against any impact to general or application database performance or
functionality.
Placing read-only tables in separate table spaces from tables that are updated allows
the Backup Utility to bypass reading potentially large portions of the database, without
losing recoverability.
Placing infrequently updated LOB data in a separate DMS table space might allow very
large LOB and Long field data to be skipped by the backup process. This is important
for LOB data because of the potential size and the lack of page level update tracking.
The offline Db2 REORG Utility will rebuild the pages in a table and will cause the table
and the indexes to have most of the pages marked as changed. It would be a good
idea to create a full backup after the REORG completes rather than an incremental
backup because the full backup will be the same size as the incremental backup and
the full backup provides for simpler recovery.

Range-partitioned tables allow defined ranges to be stored in different table spaces. For
some applications, this would allow those ranges that will not be updated to be stored in
a set of table spaces that Db2 can track as read-only, while the ranges that do contain
changes would be stored in another set of table spaces that would be included in an
incremental backup. This is especially useful for very large tables where new ranges
are added or attached and the existing data might be static.

Incremental Restore: Overview

Backups
Delta
Incremental
+ + +
Full Incremental Delta(s) Log(s)
Logs
Incremental Restore: Overview

A restore operation from incremental backup images always consists of the following
steps:
1. Identifying the incremental target image. The DBA must first determine the final
image to be restored, and request an incremental restore operation from the
Db2 Restore Utility. This image is known as the target image of the incremental
restore, because it will be the last image to be restored. An incremental restore
command against this image might initiate the creation of a new database with
the configuration and table space definitions from this target image. The
incremental target image is specified using the TAKEN AT parameter in the
RESTORE DATABASE command.
2. Restoring the most recent full database or table space image to establish a
baseline against which each of the subsequent incremental backup images can
be applied.
3. Restoring each of the required database or table space incremental backup
images, in the order in which they were produced, on top of the baseline image
restored in Step 2.

4. Repeating Step 3 until the target image from Step 1 is read a second time. The
target image is accessed twice during a complete incremental restore operation.
During the first access, only initial data is read from the image; none of the user
data is read. The complete image is read and processed only during the second
access. The target image of the incremental restore operation must be
accessed twice to ensure that the database is initially configured with the correct
history, database configuration, and table space definitions for the database that
will be created during the restore operation.
In cases where a table space has been dropped since the initial full database backup
image was taken, the table space data for that image will be read from the backup
images but ignored during incremental restore processing.

RESTORE DATABASE command options

>>-RESTORE--+-DATABASE-+--source-database-alias----------------->
'-DB-------'
>--+-| restore-options |-+-------------------------------------><

+-CONTINUE------------+
'-ABORT---------------'
restore-options
>--+--------------------------------------------------------------------------------------------------+-->
+-REBUILD WITH--+-+-ALL TABLESPACES IN DATABASE-+--+---------------------------------------+-+-----+
| | '-ALL TABLESPACES IN IMAGE----' '-EXCEPT--| rebuild-tablespace-clause |-' | |
| '-| rebuild-tablespace-clause |----------------------------------------------' |
'-+-TABLESPACE--+------------------------------------------------------------------+-+--+--------+-'
| | .-,---------------. | | '-ONLINE-'
| | V | | |
| '-(----tablespace-name-+--)--+-----------------------------------+-' |
| '-SCHEMA--+-----------------------+-' |
| | .-,-----------. | |
| | V | | |
| '-(----schema-name-+--)-' |
+-HISTORY FILE---------------------------------------------------------------------+
+-COMPRESSION LIBRARY--------------------------------------------------------------+
'-LOGS-----------------------------------------------------------------------------'
>--+----------------------------+------------------------------->
'-INCREMENTAL--+-----------+-'
+-AUTO------+
+-AUTOMATIC-+
'-ABORT-----'
RESTORE DATABASE command options

To restore a set of incremental backup images, specify the TAKEN AT time stamp
option on the RESTORE DATABASE command and include one of the following
options:
• INCREMENTAL AUTOMATIC: To have Db2 automatically determine which
backup images to restore in the correct sequence to reach the target backup
image specified in the TAKEN AT option. This uses the Recovery History file to
construct the list.
• INCREMENTAL: To begin a manual incremental restore that will complete when
the target image specified in the TAKEN AT option is restored by another
RESTORE command. One restore command is issued for each full or
incremental backup image required to rebuild the database or table space
forward to the target backup image.

Incremental Restore: Automatic

Delta
1. Read configurations in header of target backup Thu
2. Read Recovery History file to determine backups required

+
Full
Recovery Sunday
History file
3. Restore Full backup image
4. Restore Incremental backup image

+ Incremental
Wed
5. Restore target Delta backup image

db2 RESTORE DB TP1 TABLESPACE(TP1DMS)
+ Delta
Thu
ONLINE INCREMENTAL AUTOMATIC
FROM /home/inst49/backups/thursday TAKEN AT 20140820124217
Backups
Incremental Restore: Automatic

To restore a set of incremental backup images, specify the TAKEN AT time stamp
option on the RESTORE DATABASE command. Specify the time stamp for the last
image that you want to restore. In the example:
db2 RESTORE DB TP1 TABLESPACE(TP1DMS)
ONLINE INCREMENTAL AUTOMATIC
FROM /home/inst49/backups/thursday TAKEN AT 20140820124217
This will result in the Db2 Restore Utility performing each of the following steps
automatically.
1. During the initial phase of processing, the backup image with time stamp
20140820124217 is read, and the Restore Utility verifies that the database, its
history, and the table space definitions exist and are valid.
2. During the second phase of processing, the database history is queried to build
a chain of backup images required to perform the requested restore operation. If
for some reason this is not possible, and Db2 is unable to build a complete
chain of required images, the restore operation terminates and an error
message is returned.
3. Restore the full backup image that is used as the starting point for this
incremental restore process. In the example, this is a full database backup
taken on Sunday.

4. Restore the cumulative incremental backup image taken on Wednesday.

With an Automatic Incremental Restore, only one restore command is issued.
Limitations to Automatic Incremental Restore:
• If you renamed a table space since the backup you want to restore from and you
issue a table space level restore using the new name, the required chain of
backup images using the database history will not be generated correctly and an
error will occur.
For example:
db2 backup db sample —><ts1>
db2 backup db sample incremental —><ts2>
db2 rename tablespace from userspace1 to t1
db2 restore db sample tablespace ('t1') incremental automatic taken at
<ts2>
Suggested workaround: Use manual incremental restore.
• If you drop a database, the database history will be deleted. If you restore the
dropped database, the database history will be restored to its state at the time of
the restored backup and all history entries after that time will be lost. If you then
attempt to perform an automatic incremental restore that would need to use any
of these lost history entries, the RESTORE Utility will attempt to restore an
incorrect chain of backups and will return an out of sequence error.
For example:
db2 backup db sample —><ts1>
db2 backup db sample incremental —><ts2>
db2 backup db sample incremental delta —><ts3>
db2 backup db sample incremental delta —><ts4>
db2 drop db sample
db2 restore db sample incremental automatic taken at <ts2>
db2 restore db sample incremental automatic taken at <ts4>
Suggested workarounds:
• Use manual incremental restore.
• Restore the history file first from image <ts4> before issuing an automatic
incremental restore.

Incremental Restore Automatic: db2diag.log

2014-05-08-11.43.15.041953-240 E18361227E514 LEVEL: Info
FUNCTION: DB2 UDB, database utilities, sqludautController, probe:1666
Restoring user data from image 20140508110819.
2014-05-08-11.43.16.126258-240 E18452352E514 LEVEL: Info

2014-05-08-11.43.16.935831-240 E18550280E514 LEVEL: Info

Incremental Restore Automatic: db2diag.log

The Db2 Restore Utility will generate informational level messages in the db2diag.log
file for the instance if the diaglevel DBM configuration parameter is set to 4.
The slide shows an example of selected messages generated by an automatic
incremental restore. Each backup image that is processed is listed following the
message "Restoring user data from image ".

Incremental Restore: Manual
Delta
1. RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE
Thu
INCREMENTAL FROM /home/inst49/backups/thursday
TAKEN AT 20140820124217
+
Full
Recovery 2. RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE Sunday
History file INCREMENTAL /home/inst49/backups/sunday
TAKEN AT 20140816012005 +
Incremental
3. RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE Wed
INCREMENTAL FROM d:\cf49\backups\wednesday
TAKEN AT 20140819020700
+
Delta
4. RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE
Thu
INCREMENTAL FROM /home/inst49/backups/thursday
TAKEN AT 20140820124217
Backups
Incremental Restore: Manual

If you attempt an automatic Incremental restore, the database history is queried to build
a chain of backup images required to perform the requested restore operation. If for
some reason this is not possible, and Db2 is unable to build a complete chain of
required images, the restore operation terminates and an error message is returned. In
this case, an automatic restore will not be possible, and you will have to proceed with a
manual restore procedure.
The process for manually restoring a set of incremental images is functionally identical
to the automatic incremental restore. The difference between this method and an
automatic incremental restore being that the user must issue a restore command with
the correct image time stamp during each step.
A manual Incremental restore requires a sequence of restore commands. The first
restore command specifies the target Incremental backup image and includes the
INCREMENTAL option but no AUTOMATIC option. One restore command is then
issued for each full, incremental, or delta backup image that will be used, from the
oldest to the latest, each including the INCREMENTAL option. The last restore
command will be just like the one that started the process, using the time stamp of the
target backup image for the TAKEN AT time stamp.

In the example:
1. The first restore command refers to the Delta table space backup taken on
Thursday to begin the manual incremental restore.
RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE INCREMENTAL FROM
/home/inst49/backups/thursday TAKEN AT 20140820124217
2. The next command restores the TP1DMS table space from the full database
backup taken on Sunday.
RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINEINCREMENTAL
/home/inst49/backups/sunday TAKEN AT 20140816012005
3. The next command restores the TP1DMS table space pages that were included
in the Incremental table space backup taken on Wednesday. The delta backups
from Monday and Tuesday are not needed because the incremental backup is
cumulative.
RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINEINCREMENTAL FROM
d:\cf49\backups\wednesdayTAKEN AT 20140819020700
4. The last command restores the TP1DMS table space pages that were included
in the delta backup from Thursday. This was the target image for the manual
incremental restore, so the restore process is complete.
RESTORE DB TP1 TABLESPACE(TP1DMS) ONLINE INCREMENTAL FROM
/home/inst49/backups/thursday TAKEN AT 20140820124217
It is highly recommended that you not use the FORCE option on the PRUNE
HISTORY command. The default operation of this command prevents you from
deleting history entries that might be required for recovery from the most recent, full
database backup image, but with the FORCE option, it is possible to delete entries
that are required for an automatic restore operation.

db2ckrst: Check Incremental Restore
db2ckrst -d TP1 -t 20140508113152 -r tablespace -n TP1HIST
Suggested restore order of images using timestamp 20140508113152 for

database tp1.
====================================================================
restore db tp1 tablespace ( TP1HIST ) incremental taken at 20140508113152
====================================================================
====================================================================
Recovery
History file
db2ckrst: Check Incremental Restore

The command, db2ckrst, or Check Incremental Restore Image Sequence, queries the
database history and generates a list of time stamps for the backup images required for
an incremental restore operation. This can be used to see the set of backup images
that will be used during an automatic incremental restore, or to generate a simplified
restore syntax for a manual incremental restore, that only includes a subset of the
restore options. The database history must exist in order for this utility to be used. If the
database history does not exist, specify the HISTORY FILE option in the RESTORE
command before using this utility.

Monitor Incremental Restore using LIST UTILITIES

ID = 13
Type = RESTORE
Database Name = TP1
Member Number = 0
Description = automatic incremental tablespace TP1HIST...
Start Time = 05/08/2014 11:43:14.874047
State = Executing
Phase Number = 1
Start Time = 05/08/2014 11:43:14.874050
Phase Number = 2
Description = 20140508110819
Start Time = 05/08/2014 11:43:15.041918
Current Step
Description = 20140508111656
Start Time = 05/08/2014 11:43:16.126243
Phase Number = 4
Description = 20140508112654
. . . . . . .
Monitor Incremental Restore using LIST UTILITIES

The LIST UTILITIES command can be used to track the progress of an incremental
restore operation. The output includes a list of phases for each backup image that will
be restored.
The example shows that four backup images will be processed to restore the TP1HIST
table space. The Restore Utility needs to scan the header of the target image as a first
step. This has completed. The command shows that the restore is currently in Phase 3.
The backup image IDs are listed in the Description for each phase.

Incremental Restore: Rollforward table space

Backups
Delta TS
Full TS Backup
Backup
Incremental
TS Backup
Logs
Incremental
Restores
+ +
Incremental Delta
Full TS TS TS
Rollforward
+ Table space
Logs
db2 ROLLFORWARD DB TP1 TO END OF LOGS TABLEPSPACE(TP1HIST) ONLINE

Incremental Restore: Rollforward table space

After a table space is restored, it is always in a rollforward pending state. To make the
table space usable, you must perform roll forward recovery on it. You have the option of
rolling forward to the end of the logs, or rolling forward to a point in time.
When using a full database or table space restore, it is clear that the roll forward
process will begin at the point in the logs associated with the restored backup image. It
might be confusing in an Incremental recovery as to which restored backup determines
the starting point for a roll forward because a series of backup images are involved in
the restore process that can include database and table space full and incremental
images.
The incremental restore process will be treated like a full restore of the table space at
the point of the target incremental image; (the backup specified in the TAKEN AT
clause of the first manual incremental restore command or the single automatic
incremental restore command). The log control information from the target incremental
image will set the roll forward start time for the table space.

In the example, a damaged table space has been restored using an incremental restore
that included:
1. The full table space backup taken on Sunday.
2. The incremental table space backup taken on Wednesday.
3. The delta table space backup taken on Thursday.
The following rollforward command is issued:
db2 ROLLFORWARD DB TP1 TO END OF LOGS TABLEPSPACE(TP1HIST) ONLINE
The roll forward process will begin with the logs associated with the delta backup from
Thursday and continue through to the most current active logs.
One of the key advantages to utilizing incremental backups is the ability to reduce the
number of logs processed during the rollforward recovery by taking more frequent
backups while limiting the time and space required for the backups.

Demonstration 1
Incremental Backup and Restore
• Plan and implement an effective recovery strategy that includes

Incremental backups
• Use the Db2 Backup utility to back up a database or table spaces with
the Incremental or Delta options
• Use the db2ckrst command output to get a list of backup images
needed for an incremental restore process
• Execute the Db2 Restore utility with the Incremental option either in
automatic mode to recover table spaces
• Utilize the db2diag.log messages to understand the processing of an
incremental backup or restore
Demonstration 1: Incremental Backup and Restore

Demonstration 1:
Incremental Backup and Restore
Purpose:
To utilize the three modes for Db2 backups: Full, Incremental, and Delta at the
database and table space level. You will check the size of each backup image
produced and the portion of the database read to produce each backup to
help quantify the benefits of using these options. You will also perform an
Incremental restore in automatic mode.
Task 1. Prepare the database TP1 for Incremental backup and

restore.
ibm2blue.
A series of backup images will be created, including Full database, Incremental
database, Incremental table space, and Delta table space backups. You will
make note of the time stamps of each backup, the size of each backup image,
and the amount of data read from the Db2 database. This information will be
cross referenced with Db2 generated messages to provide a better
understanding of the Incremental Backup and Restore facilities.
• cd $HOME/bin
• db2start
• db2 UPDATE DBM CFG USING DIAGLEVEL 4
• rm $HOME/sqllib/db2dump/db2diag.log
The use of Incremental backups requires the database configuration parameter
TRACKMOD be set to ON. Update the database configuration for the TP1
database to set the TRACKMOD parameter to ON.


• db2 UPDATE DB CFG FOR TP1 USING TRACKMOD ON
You will check the database read activity of the BACKUP utility using the
direct_reads monitor element returned by MON_GET_DATABASE table
function. You will create a work table named bkstats that will be used to save
the database count for direct reads before each BACKUP command. The file
cr_bkstats.ddl creates the work table.
• db2 -tvf cr_bkstats.ddl
create table bkstats
( id int not null, dir_read_start
bigint not null, dir_read_now
bigint not null ) in userspace1
insert into bkstats values (1 , 0, 0)

The Incremental backup option requires a full backup image as the starting
point of recovery. Run the Db2 BACKUP command to back up the TP1
database using the $HOME/backups/u6 directory, do not include the
INCREMENTAL option. Use the file bkstart.sql to save the current count for
direct reads.
• db2 -tvf bkstart.sql
update bkstats
set dir_read_start =
(select direct_reads from table (mon_get_database(-2)) as mondb ) where id = 1
select dir_read_start as direct_read_before_backup from bkstats where id = 1
DIRECT_READ_BEFORE_BACKUP
-------------------------
6452


• db2 " BACKUP DATABASE TP1 ONLINE TO $HOME/backups/u6
BUFFER 250 COMPRESS EXCLUDE LOGS "
Make a note of the backup time stamp for backup 1.
To determine the size of the backup images, issue the UNIX ls command. To
get a count of the Direct Reads performed by the BACKUP utility, use the SQL
statements in the file bkend.sql.
• db2 -tvf bkend.sql
• ls -l $HOME/backups/u6
The output from the last two commands will look similar to the following:
update bkstats
set dir_read_now = (select direct_reads from table (mon_get_database(-2)) as
mondb )
where id = 1
select
(dir_read_now - dir_read_start) as direct_reads_since_start
from bkstats where id = 1
DIRECT_READS_SINCE_START
------------------------
391350
total 44032
-rw-------. 1 inst464 adm01 45088768 Apr 26 06:44
TP1.0.inst464.DBPART000.20180426064439.001
Note the size of the backup and the number of Direct Reads in the results table
for backup 1. In the example above, the size would be 45 MB and the number
of Direct Reads is 391K.
The Db2 database statistic Direct Reads shows the amount of data read outside
the Db2 buffer pools. Direct reads are in units, the smallest being a 512 byte
block. The Backup and Restore utilities use the database utility Heap rather
than the buffer pools so the read I/Os for backups are counted as Direct Reads.

Task 2. Update the database TP1 and use Incremental

backup images.
Use the Db2 command file ingesttabs.ddl to make logged changes to four
tables using INGEST commands. This will mark the changed table spaces and
changed pages for these tables.
• db2 -tvf ingesttabs.ddl




09:57:24.248698"



09:57:25.769858"




09:57:27.269296"



09:57:36.289841"
Invoke the Db2 Backup utility with the INCREMENTAL option, to back up the
TP1 database pages that were updated since the full database backup. Run the
Db2 BACKUP command to back up the TP1 database using the
$HOME/backups/u6 directory, with the INCREMENTAL option. Use the file
bkstart.sql to save the current count for direct reads.
• db2 -tf bkstart.sql
• db2 " BACKUP DATABASE TP1 ONLINE INCREMENTAL to
$HOME/backups/u6 BUFFER 250 COMPRESS EXCLUDE LOGS "
Check the size of this backup image, issue the UNIX ls command. To get a
count of the Direct Reads performed by the BACKUP utility, use the SQL
• db2 -tf bkend.sql
------------------------
366452

total 64064
-rw-------. 1 inst464 adm01 45088768 Apr 26 06:44
TP1.0.inst464.DBPART000.20180426064439.001
-rw-------. 1 inst464 adm01 20512768 Apr 26 10:02
TP1.0.inst464.DBPART000.20180426100237.001
Notice the size of the backup and the number of Direct Reads for backup 2. In
the example above, the size of the incremental database backup image was 20
MB, which is significantly smaller than the full backup. The number of Direct
Reads is only slightly smaller, because the largest tablespaces needed to be
examined page by page.
Check the messages generated in the db2diag.log file by the Incremental
backup. Use the db2diag command to filter the diagnostic log messages and
list the informational messages associated with the incremental backups.
• db2diag -gi message:=back | more
The output from this command will include messages similar to the following:
2018-04-26-10.02.38.312004-240 E2944206E496 LEVEL: Info
FUNCTION: DB2 UDB, database utilities, sqlubSetupJobControl, probe:1907
MESSAGE : Starting an online incremental db backup.
2018-04-26-10.02.38.376647-240 E2988210E556 LEVEL: Info

DATA #1 : Pool ID, PD_TYPE_POOL_ID, 2 bytes
5
DATA #2 : String, 8 bytes
TP1ACCTD
2018-04-26-10.02.38.376930-240 E2988767E534 LEVEL: Info



MESSAGE : Using backupLSN
DATA #1 : SQLP_LSN8, PD_TYPE_SQLP_LSN8, 8 bytes
0000000000656ADA
2018-04-26-10.02.38.383093-240 E2994822E555 LEVEL: Info

4
TP1HIST
2018-04-26-10.02.38.383395-240 E2995378E534 LEVEL: Info

0000000000656ADA
2018-04-26-10.02.38.385925-240 E2998690E573 LEVEL: Info

MESSAGE : Incremental backup skipping tablespace
6
TP1ACCTI
2018-04-26-10.02.38.392362-240 E3003634E560 LEVEL: Info



0
SYSCATSPACE
2018-04-26-10.02.38.392653-240 E3004195E534 LEVEL: Info

0000000000656ADA
2018-04-26-10.02.38.393673-240 E3005241E559 LEVEL: Info

2
USERSPACE1
2018-04-26-10.02.38.393960-240 E3005801E534 LEVEL: Info

0000000000656ADA
2018-04-26-10.02.39.425860-240 E3012450E561 LEVEL: Info



7
SYSTOOLSPACE
2018-04-26-10.02.39.426230-240 E3013012E534 LEVEL: Info

0000000000656ADA
2018-04-26-10.02.40.580310-240 E3021919E556 LEVEL: Info

3
TP1SMALL
2018-04-26-10.02.40.580677-240 E3022476E534 LEVEL: Info

0000000000656ADA
2018-04-26-10.02.45.647953-240 E3139040E459 LEVEL: Info



FUNCTION: DB2 UDB, database utilities, sqlubcka, probe:1080
MESSAGE : Backup complete.
The table space TP1ACCTI was skipped. The TP1ACCTI table space contains
the Indexes for the ACCT table and the table changes to the ACCT table did not
require index changes.
Use the Db2 command file ingesttabs.ddl to make additional logged changes to
four tables using INGEST commands.
• db2 -tf ingesttabs.ddl
Create an Incremental Delta backup of the two table spaces TP1HIST and
TP1ACCTD. This backup will only contain the updates since the previous
incremental database backup. Run the Db2 BACKUP command to back up the
table spaces TP1HIST and TP1ACCTD using the $HOME/backups/u6
directory, with the INCREMENTAL DELTA option.
Use the file bkstart.sql to save the current count for direct reads.
• db2 " BACKUP DATABASE TP1 TABLESPACE(TP1ACCTD,TP1HIST)
ONLINE INCREMENTAL DELTA to $HOME/backups/u6 BUFFER 250
COMPRESS EXCLUDE LOGS "
------------------------
92244

[inst464@ibmclass bin]$ ls -l $HOME/backups/u6 | tee $HOME/output/u6out9.txt

total 71096
-rw-------. 1 inst464 adm01 45088768 Apr 26 06:44
TP1.0.inst464.DBPART000.20180426064439.001
-rw-------. 1 inst464 adm01 20512768 Apr 26 10:02
TP1.0.inst464.DBPART000.20180426100237.001
-rw-------. 1 inst464 adm01 7200768 Apr 26 13:24
TP1.3.inst464.DBPART000.20180426132422.001
Notice the size of the backup and the number of Direct Reads for backup 3. In
the example above, the size of the incremental database backup image was 7
MB, which is significantly smaller than the previous incremental database level
backup. The number of Direct Reads is smaller because only two tablespaces
needed to be examined page by page.
Run a script that will update a portion of the History table rows. The script
tp1uphst contains the following SQL UPDATE statement that will update
history rows for 10 percent of the accounts:
update history set balance = balance +1 where acct_id = (acct_id /
10) * 10
• tp1uphst
Create another Incremental Delta backup of the two table spaces TP1HIST and
TP1ACCTD. This backup will only contain the updates to the History table from
the SQL update just executed. Run the Db2 BACKUP command to back up the
table spaces TP1HIST and TP1ACCTD using the $HOME/backups/u6
directory, with the INCREMENTAL DELTA option.
Use the file bkstart.sql to save the current count for direct reads.
• db2 " BACKUP DATABASE TP1 TABLESPACE(TP1ACCTD,TP1HIST)
ONLINE INCREMENTAL DELTA to $HOME/backups/u6 BUFFER 250
COMPRESS EXCLUDE LOGS "


------------------------
34900
[inst464@ibmclass bin]$ ls -l $HOME/backups/u6

total 76128
-rw-------. 1 inst464 adm01 45088768 Apr 26 06:44
TP1.0.inst464.DBPART000.20180426064439.001
-rw-------. 1 inst464 adm01 20512768 Apr 26 10:02
TP1.0.inst464.DBPART000.20180426100237.001
-rw-------. 1 inst464 adm01 7200768 Apr 26 13:24
TP1.3.inst464.DBPART000.20180426132422.001
-rw-------. 1 inst464 adm01 5152768 Apr 26 13:37
TP1.3.inst464.DBPART000.20180426133732.001
Note the size of the backup and the number of Direct Reads for backup 4. In
the example above, the size of the incremental tablespace backup image was 5
MB, which is slightly smaller than the previous incremental tablespace backup.
The number of Direct Reads is smaller because only one tablespace needed to
be examined page by page.

Task 3. Update the database TP1 and use Incremental

backup images.
The DB2 Incremental Restore has two modes of operation:
• In Incremental Automatic mode, DB2 will read the target image backup and
the Recovery History file to select the set of backup images that will be used
to recover the database or table spaces. The restore process will then
automatically invoke the commands to restore the previous backup images,
including the full backup that is required to provide a starting point for the
process.
• In Incremental Manual mode, a series of DB2 RESTORE commands are
issued with the Incremental option to rebuild the database or table space.
This might be necessary if the recovery history file does not contain all of the
information necessary to perform the recovery automatically.
The db2ckrst command can be used to see which backup images would be
used in automatic mode to recover a database or table space. Run the
db2ckrst command to see the sequence of backup images that would be used
to recover the TP1HIST table space if it became unusable.
• db2ckrst -d tp1 -t yyyymmddhhmmss -r tablespace -n tp1hist
(where yyyymmddhhmmss is the time stamp from the last delta backup 4, from
the previous Task)
The output from this command will be similar to the following:
for
database tp1.
====================================================================
====================================================================
Notice that the target backup image, the last Delta backup 4 occurs twice, first
to get the header information, and lastly to read the backup data. The full
database backup 1, is used as the starting point for restoring the data. Next the
last Incremental database backup 2, will be restored. Next the first Delta table
space backup 3 is restored and finally the last Delta table space backup 4, will
be restored.
Run the Restore utility to recover the TP1HIST table space in Incremental
Automatic mode using the last Delta backup 4.


• db2 " RESTORE DATABASE TP1 TABLESPACE(TP1HIST) ONLINE
INCREMENTAL AUTOMATIC from $HOME/backups/u6 TAKEN AT
yyyymmddhhmmss "
(where yyyymmddhhmmss is the time stamp from the last delta backup 4)
Execute the ROLLFORWARD command to apply the log changes since the last
backup.
• db2 " ROLLFORWARD DB TP1 TO END OF LOGS
TABLESPACE(TP1HIST) ONLINE "
To verify the sequence of backup image processing during the Incremental
Automatic restore of the TP1HIST table space, check the messages generated
in the db2diag.log file by the Incremental restore. Use the db2diag command to
filter the diagnostic log messages and list the informational messages
associated with the incremental restore.
• db2diag -gi data:=image | more
The output from this command will include messages similar to the following:
2018-04-27-10.25.13.085374-240 E12503269E498 LEVEL: Info
Restoring initial target image.
2018-04-27-10.25.13.262832-240 E12565622E514 LEVEL: Info

2018-04-27-10.25.14.101404-240 E12652368E514 LEVEL: Info



2018-04-27-10.25.14.656863-240 E12730082E514 LEVEL: Info

2018-04-27-10.25.15.079817-240 E12806084E514 LEVEL: Info

Drop the work table used to collect direct read counts and deactivate the TP1
database.
• db2 drop table bkstats
• db2 terminate
Results:
You created a series of full and incremental backups for the database and
selected tablespaces and used them to perform and automatic incremental
restore for one specific tablespace. You used the db2ckrst command to
produce a list of backup images that would be needed to perform an
incremental restore.

Unit summary
Unit summary

IBM Training
© Copyright IBM Corporation 2018. All Rights Reserved.

CL464GCourse Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CL464GCourse Guide

Uploaded by

Copyright:

Available Formats

®

© Copyright IBM Corp. 1997, 2018 P-2

© Copyright IBM Corp. 1997, 2018 P-3

Monitor log space usage

© Copyright IBM Corp. 1997, 2018 P-4

© Copyright IBM Corp. 1997, 2018 P-5

STMM in action: BP sizes during tuning ........................................................... 3-49

© Copyright IBM Corp. 1997, 2018 P-6

Generating a redirected restore script .............................................................. 5-15

© Copyright IBM Corp. 1997, 2018 P-7

Incremental Restore Automatic: db2diag.log .................................................... 6-35

© Copyright IBM Corp. 1997, 2018 P-8

© Copyright IBM Corp. 1997, 2018 P-9

© Copyright IBM Corp. 1997, 2018 P-10

© Copyright IBM Corp. 1997, 2018 P-11

© Copyright IBM Corp. 1997, 2018 P-12

© Copyright IBM Corp. 1997, 2018 P-13

Additional training resources

© Copyright IBM Corp. 1997, 2018 P-14

IBM product help

Books for You want to use search engines to Start/Programs/IBM

IBM on the You want to access any of the

• IBM - Training and Certification • http://www-01.ibm.com/

© Copyright IBM Corp. 1997, 2018 P-15

© Copyright IBM Corp. 1997, 2018 P-16

Db2 11.1 Advanced Database Administration

© Copyright IBM Corporation 2018

© Copyright IBM Corp. 1997, 2018 1-2

Advanced monitoring © Copyright IBM Corporation 2018

© Copyright IBM Corp. 1997, 2018 1-3

Characteristics of in-memory metrics used to support the

Characteristics of in-memory metrics used to support the monitor table functions

© Copyright IBM Corp. 1997, 2018 1-4

© Copyright IBM Corp. 1997, 2018 1-5

Focus areas for in-memory metrics

Advanced monitoring © Copyright IBM Corporation 2018

Focus areas for in-memory metrics

© Copyright IBM Corp. 1997, 2018 1-6

In-memory metrics: System

Connection Service Class Service Class

Advanced monitoring © Copyright IBM Corporation 2018

In-memory metrics: System

© Copyright IBM Corp. 1997, 2018 1-7

In-memory metrics: Data objects

Temp Table space

Advanced monitoring © Copyright IBM Corporation 2018

In-memory metrics: Data objects

© Copyright IBM Corp. 1997, 2018 1-8

In-memory metrics: Activity perspective

Activity WLM Activity Package Cache

Db2 Agent Activity Level

Advanced monitoring © Copyright IBM Corporation 2018

In-memory metrics: Activity perspective

© Copyright IBM Corp. 1997, 2018 1-9

Controls for collecting monitor data

MON_GET_ACTIVITY_DETAILS mon_act_metrics COLLECT ACTIVITY

Advanced monitoring © Copyright IBM Corporation 2018

Controls for collecting monitor data

© Copyright IBM Corp. 1997, 2018 1-10

© Copyright IBM Corp. 1997, 2018 1-11

Monitoring system information using table functions

Monitoring system information using table functions

© Copyright IBM Corp. 1997, 2018 1-12

© Copyright IBM Corp. 1997, 2018 1-13