®

Course Guide
Db2 11.1 Administration Workshop
for Linux
Course code CL207 ERC 2.0

IBM Training
 Preface

March 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, [Link], 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 [Link]/legal/[Link].
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, 2016 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-11
Document conventions ..................................................................................... P-13
Demonstrations ................................................................................................ P-14
Additional training resources ............................................................................ P-15
IBM product help .............................................................................................. P-16
Overview of Db2 11.1 ............................................................................ 1-1
Unit objectives .................................................................................................... 1-3
Db2 family product platforms .............................................................................. 1-4
Db2: The scalable database ............................................................................... 1-5
Examples of features and functions by Db2 LUW Editions ................................. 1-7
Db2 Direct Editions ............................................................................................. 1-8
Virtual Processor Core (VPC) ........................................................................... 1-10
Expand Db2 Ecosystem/Skills .......................................................................... 1-11
Operating systems supported by Db2 11.1 ....................................................... 1-12
Operating systems: Virtualization ..................................................................... 1-14
Db2 server connectivity options ........................................................................ 1-16
Streamlined upgrade process ........................................................................... 1-19
Preparing to install Db2 database servers ........................................................ 1-21
Db2 software installation methods .................................................................... 1-22
Db2 deployment options ................................................................................... 1-25
IBM Db2 Hosted ............................................................................................... 1-27
Target use-cases addressed by Db2 Hosted .................................................... 1-29
Db2 Connect .................................................................................................... 1-30
Unit summary ................................................................................................... 1-32
Db2 Command Line Processor (CLP) and GUI tools .......................... 2-1
Unit objectives .................................................................................................... 2-3
The Db2 CLP Command Line Processor............................................................ 2-4
CLP syntax ......................................................................................................... 2-5
Using CLP to list Db2 command options ............................................................ 2-6
Modes for using the Db2 CLP............................................................................. 2-7
Using an input file with the Command Line Processor ...................................... 2-10
The CLPPlus Command Line Processor .......................................................... 2-11
Example CLPPlus interactive SQL execution ................................................... 2-13
IBM Data Server Manager ................................................................................ 2-14
DSM uses stored database connection profiles ................................................ 2-16
Using IBM DSM to create and manage database objects ................................. 2-17

© Copyright IBM Corp. 1997, 2016 P-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Using DSM to generate and execute Db2 utilities ............................................. 2-18

Using DSM to edit and execute SQL scripts ..................................................... 2-19
Viewing query results with DSM ....................................................................... 2-20
Monitor database activity using DSM................................................................ 2-21
Unit summary ................................................................................................... 2-22
The Db2 database manager instance .................................................. 3-1
Unit objectives .................................................................................................... 3-3
What is an instance? .......................................................................................... 3-4
The database manager instance ........................................................................ 3-6
Create and drop an instance .............................................................................. 3-7
db2icrt command notes ...................................................................................... 3-9
Starting and stopping an instance .................................................................... 3-10
Db2 registry and environment variables ........................................................... 3-12
The db2set command ....................................................................................... 3-15
Checking Db2 registry variables using SQL...................................................... 3-17
Making changes to the database manager configuration.................................. 3-18
Instance configuration using Data Server Manager .......................................... 3-20
Demonstration 1: Create a new Db2 instance .................................................. 3-21
Unit summary ................................................................................................... 3-32
Creating databases and data placement ............................................. 4-1
Unit objectives .................................................................................................... 4-3
Create database overview .................................................................................. 4-4
Table space, container, extent, page .................................................................. 4-5
Writing to containers ........................................................................................... 4-6
Database storage requirements ......................................................................... 4-8
Storage management alternatives .................................................................... 4-10
CREATE DATABASE syntax............................................................................ 4-14
Completed by Db2 during database creation .................................................... 4-16
CREATE DATABASE examples....................................................................... 4-21
Db2 Native Encryption ...................................................................................... 4-23
Encryption Key Wrapping ................................................................................. 4-25
Db2 Native Encryption with a local key store .................................................... 4-27
Encryption and Enterprise Key Management.................................................... 4-29
Why consider a centralized key manager for encryption? ................................. 4-31
Native encryption using a centralized keystore ................................................. 4-32
Checklist to implement Db2 encryption with ISKLM based keystore: part 1 ...... 4-33
Checklist to implement Db2 encryption with ISKLM based keystore: part 2 ...... 4-34
Database components that are encrypted with Db2 native encryption.............. 4-35
IBM Global Security Kit..................................................................................... 4-36
Database path storage ..................................................................................... 4-37

© Copyright IBM Corp. 1997, 2016 P-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Default table space containers with Automatic Storage .................................... 4-40

System catalog tables and views ...................................................................... 4-41
Table space design limits: Row Identifiers ........................................................ 4-42
CREATE TABLESPACE syntax ....................................................................... 4-44
Storage groups (multi-temperature storage) ..................................................... 4-47
Creating a storage group .................................................................................. 4-49
Assigning a table space to a storage group ...................................................... 4-50
Managing storage groups using ALTER STOGROUP ...................................... 4-51
Query storage groups with SQL using the table function
ADMIN_GET_STORAGE_PATHS ................................................................... 4-52
Listing storage groups with the db2pd command.............................................. 4-54
Storage Management alternatives: Automatic .................................................. 4-55
ALTER TABLESPACE ..................................................................................... 4-57
Adding or dropping Automatic Storage paths ................................................... 4-59
Using the [Link] view ........................................................ 4-61
Using the db2pd command to list tablespace status and statistics.................... 4-62
Using the MON_GET_TABLESPACE function ................................................. 4-63
Additional Db2 System table spaces ................................................................ 4-64
Database buffer pools ...................................................................................... 4-66
Designing buffer pools ...................................................................................... 4-68
Maintain or List System Database Directory ..................................................... 4-70
Database configuration tools ............................................................................ 4-71
ACTIVATE and DEACTIVATE the database .................................................... 4-72
QUIESCE and UNQUIESCE the database ....................................................... 4-74
Demonstration 1: Creating databases and data placement .............................. 4-75
Unit summary ................................................................................................... 4-97
Creating database objects.................................................................... 5-1
Unit objectives .................................................................................................... 5-3
Db2 object hierarchy .......................................................................................... 5-4
CREATE SCHEMA ............................................................................................ 5-6
Set current schema ............................................................................................ 5-8
Using the Create Table statement ...................................................................... 5-9
Application temporary tables ............................................................................ 5-11
Example of a declared temporary table ............................................................ 5-13
Example of a created temporary table .............................................................. 5-14
Table partitioning .............................................................................................. 5-16
Example of a range partitioned table ................................................................ 5-17
What is Db2 with BLU Acceleration? ................................................................ 5-18
BLU Acceleration: Columnar storage................................................................ 5-20
Storage savings using BLU Acceleration .......................................................... 5-21
BLU Acceleration: Simple to implement and use .............................................. 5-22

© Copyright IBM Corp. 1997, 2016 P-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

What happens when you create a new column-organized table? ..................... 5-24
BLU Acceleration illustration 10TB query in seconds........................................ 5-25
Shadow Tables can be used to accelerate
Analytics query processing in an OLTP database........................................ 5-27
Shadow table characteristics ............................................................................ 5-28
Advances to column-organized tables with Db2 11.1 ....................................... 5-30
Demonstrating BLU single instance improvement ............................................ 5-31
BLU declared global temporary tables .............................................................. 5-32
Create View statement ..................................................................................... 5-33
Create Alias statement ..................................................................................... 5-35
Create index statements................................................................................... 5-37
Overview of referential integrity ........................................................................ 5-39
Referential integrity: CREATE TABLE statement ............................................. 5-41
Unique key considerations ............................................................................... 5-43
Check constraints: Definition ............................................................................ 5-45
Create a trigger statement ................................................................................ 5-47
Manage and query time-based data using temporal tables............................... 5-49
How to define a system-period temporal table .................................................. 5-51
Query using a system-period temporal table .................................................... 5-53
Example of an application-period temporal table .............................................. 5-54
Using an application-period temporal table ....................................................... 5-56
Data row compression summary ...................................................................... 5-58
Adaptive compression with Db2 ....................................................................... 5-60
How Does Adaptive Compression Work? Step 1.............................................. 5-62
How Does Adaptive Compression Work? Step 2.............................................. 5-63
db2look examples ............................................................................................ 5-64
Demonstration 1: Creating database objects .................................................... 5-67
Unit summary ................................................................................................... 5-79
Moving data ........................................................................................... 6-1
Unit objectives .................................................................................................... 6-3
Review INSERT statement ................................................................................. 6-4
EXPORT command syntax (Basic) ..................................................................... 6-5
EXPORT command example.............................................................................. 6-7
IMPORT command syntax (Basic) ..................................................................... 6-8
Import utility example ......................................................................................... 6-9
Differences between IMPORT and LOAD ........................................................ 6-10
Load processing phases................................................................................... 6-12
Load processing for column-organized tables .................................................. 6-14
LOAD command syntax (Basic)........................................................................ 6-15
LOAD scenario ................................................................................................. 6-18
Rules and methods for creating Exception Tables ............................................ 6-22

© Copyright IBM Corp. 1997, 2016 P-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Offline versus Online Load ............................................................................... 6-23

Table states ...................................................................................................... 6-25
Checking Load status: Load query ................................................................... 6-27
Load monitoring: LIST UTILITIES..................................................................... 6-28
Load Pending state: Recovering from LOAD failure ......................................... 6-29
Backup Pending state: COPY options .............................................................. 6-31
Set Integrity Pending table state ....................................................................... 6-34
SET INTEGRITY command syntax (Basic)....................................................... 6-36
Example - Running Set Integrity ....................................................................... 6-38
Meaningful steps for LOAD .............................................................................. 6-41
db2move utility ................................................................................................. 6-42
db2move COPY option ..................................................................................... 6-43
db2move COPY schema examples .................................................................. 6-45
Online Table Move stored procedure................................................................ 6-46
ADMIN_MOVE_TABLE: Processing phases .................................................... 6-47
ADMIN_MOVE_TABLE procedure methods..................................................... 6-48
Example: Move a table to a new table space.................................................... 6-50
Using ADMIN_MOVE_TABLE to convert row-organized tables
to a column-organized table ........................................................................ 6-51
New options for ADMIN_MOVE_TABLE with Db2 11.1 .................................... 6-54
Sample REPORT for ADMIN_MOVE_TABLE monitoring ................................. 6-55
Ingest utility - for continuous data ingest........................................................... 6-56
Ingest command examples - Insert ................................................................... 6-59
Ingest command examples - Update ................................................................ 6-60
INGEST utility - Configuration parameters ........................................................ 6-61
INGEST - Restart ............................................................................................. 6-63
Monitoring INGEST using INGEST LIST and INGEST GET STATS................. 6-67
When to use INGEST rather than LOAD .......................................................... 6-68
When to use LOAD rather than INGEST .......................................................... 6-69
Demonstration 1: Moving data .......................................................................... 6-70
Unit summary ................................................................................................... 6-79
Backup and recovery ............................................................................ 7-1
Unit objectives .................................................................................................... 7-3
Db2 Database recovery methods ....................................................................... 7-4
Introduction to database logging......................................................................... 7-6
Nonrecoverable database: Circular logging ........................................................ 7-8
Recoverable database: Archive logging ........................................................... 7-10
Location of Active log files ................................................................................ 7-12
Configure database logs: Parameters .............................................................. 7-13
Archiving logs to Local disks............................................................................. 7-17
Db2 recovery-related system files .................................................................... 7-19

© Copyright IBM Corp. 1997, 2016 P-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Backup Utility options (partial) .......................................................................... 7-22

The backup files ............................................................................................... 7-24
Syntax of the RESTORE command (partial) ..................................................... 7-26
Backup/restore table space considerations ...................................................... 7-28
Encryption options for BACKUP and RESTORE .............................................. 7-30
Db2 support for the NX842 Accelerator ............................................................ 7-32
Db2 backup compression performance results ................................................. 7-34
Using CATALOG STORAGE ACCESS commands
to define cloud storage access .................................................................... 7-35
Using a defined remote storage alias for a database backup ........................... 7-37
Roll forward pending state ................................................................................ 7-38
Syntax of the ROLLFORWARD command ....................................................... 7-39
ROLLFORWARD: How far? ............................................................................. 7-41
ROLLFORWARD: Tablespace ......................................................................... 7-43
Db2 RECOVER command ............................................................................... 7-45
High Availability Disaster Recovery: HADR ...................................................... 7-47
Support for multiple active standby databases ................................................. 7-49
Db2 pureScale feature architecture .................................................................. 7-52
Db2 additional recovery facilities ...................................................................... 7-53
Demonstration 1: Backup and recovery ............................................................ 7-55
Unit summary ................................................................................................... 7-66
Database maintenance, monitoring and problem determination ...... 8-1
Unit objectives .................................................................................................... 8-3
Database maintenance activities ........................................................................ 8-4
RUNSTATS command examples ....................................................................... 8-5
Using REORGCHK to find tables that would benefit from reorganization ........... 8-7
Using REORGCHK to find indexes that would benefit from reorganization......... 8-8
Reorg utility examples ........................................................................................ 8-9
Autonomic utilities ............................................................................................ 8-11
Monitoring a Db2 database .............................................................................. 8-13
db2pd - Monitor and troubleshoot Db2 ............................................................. 8-15
Using db2pd to check reorg statistics when a reorg fails to complete ............... 8-17
Using Db2 table functions in SQL statements for monitoring ............................ 8-18
Using the MON_GET_TABLE function for table performance statistics ............ 8-21
Monitoring wait times for active connections
using MON_GET_CONNECTION ............................................................... 8-22
LIST APPLICATIONS command ...................................................................... 8-23
dsmtop: Db2 text-based monitoring tool command ........................................... 8-24
dsmtop: tablespace activity and utilization display ............................................ 8-25
Db2 event monitors .......................................................................................... 8-26
CREATE and use an activities event monitor ................................................... 8-28

© Copyright IBM Corp. 1997, 2016 P-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Sample Activities Monitor report ....................................................................... 8-29

Db2 Optimizer .................................................................................................. 8-30
Design Advisor ................................................................................................. 8-32
Design Advisor: db2advis command................................................................. 8-34
Using Data Server Manager Tune option
to view query tuning recommendations ....................................................... 8-35
EXPLAIN facility tools ....................................................................................... 8-37
Data Server Manager - Visual Explain access plan for SQL ............................. 8-38
db2exfmt - detailed text explain report .............................................................. 8-39
Creating Explain tables..................................................................................... 8-40
Automatic database memory management ...................................................... 8-42
Monitoring Database memory usage
using the table function MON_GET_MEMORY_POOL ............................... 8-44
Configuration for Diagnostic files ...................................................................... 8-45
[Link] message examples ....................................................................... 8-47
Diagnostic Log Analysis tool: db2diag .............................................................. 8-49
First occurrence data capture (FODC).............................................................. 8-51
db2fodc - Db2 first occurrence data collection command ................................. 8-53
Obtaining a Db2 trace using db2trc .................................................................. 8-55
Demonstration 1: Using Db2 tools for performance .......................................... 8-56
Unit summary ................................................................................................... 8-67
Locking and concurrency..................................................................... 9-1
Unit objectives .................................................................................................... 9-3
Why perform locking? ......................................................................................... 9-4
Objects that might be locked .............................................................................. 9-6
Table lock modes ............................................................................................... 9-8
Row lock modes ............................................................................................... 9-11
Lock mode compatibility ................................................................................... 9-13
Selecting isolation levels .................................................................................. 9-16
Db2 and ANSI isolation levels: How anomalies are allowed or prevented ........ 9-20
Locking for read-only access ............................................................................ 9-21
How Currently Committed works for CS isolation ............................................. 9-23
LOCK TABLE statement................................................................................... 9-25
Setting LOCKLIST and MAXLOCKS to control Lock escalations ...................... 9-27
Lock wait and timeout ....................................................................................... 9-29
Using db2pd to look for active lock wait conditions ........................................... 9-31
Using Data Server Manager to view lock wait objects ...................................... 9-32
Deadlock causes and detection ........................................................................ 9-33
Monitoring active lock waits with SQL............................................................... 9-35
Using SQL to monitor Lock escalations, deadlocks and timeouts
for active connections .................................................................................. 9-36

© Copyright IBM Corp. 1997, 2016 P-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Lock Event Monitoring ...................................................................................... 9-37

Using SQL query with Locking Event monitor data ........................................... 9-40
Demonstration 1: Investigating Db2 locking ...................................................... 9-41
Unit summary ................................................................................................... 9-57
Security ............................................................................................. 10-1
Unit objectives .................................................................................................. 10-3
Authentication versus authorization .................................................................. 10-4
SYSADM authorization ..................................................................................... 10-7
DBADM authorization ....................................................................................... 10-9
SECADM authorization................................................................................... 10-11
Other limited Security authorizations .............................................................. 10-13
Possible methods to administer Db2 security ................................................. 10-18
Separating database security privileges ......................................................... 10-20
Db2 Security privilege hierarchies .................................................................. 10-22
GRANT statement: Table/view privileges syntax ............................................ 10-23
Using Database Roles for Security ................................................................. 10-24
Using System Groups for Security .................................................................. 10-25
Example of using Roles to manage authorizations ......................................... 10-26
Controlling use of schemas ............................................................................ 10-27
Protecting resources through programs.......................................................... 10-29
Privileges granted during CREATE DATABASE............................................. 10-30
Implicitly granted privileges ............................................................................ 10-32
System Catalog views for authorizations ........................................................ 10-33
Summary of row and column access control .................................................. 10-36
Example - CREATE PERMISSION ................................................................ 10-38
Create column mask ...................................................................................... 10-40
Example - CREATE MASK for a column ........................................................ 10-41
Security for database connections .................................................................. 10-42
How SSL is used for Db2 database connections ............................................ 10-44
SSL configuration for Db2 Servers ................................................................. 10-45
Database security for three-tier application systems....................................... 10-49
What is a trusted context? .............................................................................. 10-50
Trusted Context - Example ............................................................................. 10-52
Demonstration 1: Database security ............................................................... 10-53
Unit summary ................................................................................................. 10-61

© Copyright IBM Corp. 1997, 2016 P-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Course overview
Preface overview
This course teaches you to perform, basic database administrative tasks using Db2
11.1. These tasks include creating database objects like tables, indexes and views and
loading data into the database with Db2 utilities like LOAD and INGEST. Various
diagnostic methods will be presented, including using db2pd command options and
monitoring using SQL statements with Db2 monitor functions. Students will learn how to
implement automatic archival for database logs and how to recover a database to a
specific point in time using the archived logs. We will cover the locking performed by
Db2 and the effect the application isolation level has on locking and lock wait
conditions.
The lab demonstrations are performed using Db2 [Link] for Linux. For some lab tasks
students will have the option to complete the task using a Db2 command line processor
or using the graphical interface provided by IBM Data Server Manager.
Intended audience
This is an entry level course for Database Administrators and technical individuals who
plan, implement, and maintain Db2 11.1 for Linux, UNIX, and Windows databases.
Topics covered
Topics covered in this course include:
• Overview of Db2
• Db2 Command Line Processor (CLP) and GUI tools
• The Db2 database manager instance
• Creating databases and data placement
• Creating database objects
• Moving data
• Backup and recovery
• Database maintenance, monitoring and problem determination
• Locking and concurrency
• Security

© Copyright IBM Corp. 1997, 2016 P-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Preface

Course prerequisites
Participants should have the following skills:
• Use basic OS functions such as utilities, file permissions, hierarchical file system,
commands, and editor
• State the functions of the Structured Query Language (SQL) and be able to
construct DDL, DML, and authorization statements
• Discuss basic relational database concepts and objects such as tables, indexes,
views, and joins
• These skills can be developed by taking:
• DB2 SQL Workshop
• DB2 Fundamentals

© Copyright IBM Corp. 1997, 2016 P-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 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.

© Copyright IBM Corp. 1997, 2016 P-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 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:
• Creating a new Db2 instance
• Creating a new Db2 database and a set of storage objects to support the sample
tables used for this course
• Creating a set of database objects, including tables, indexes, views, referential
integrity and check constraints
• Loading sample data into the tables using Db2 utilities like LOAD and INGEST.
• Configuration of a Db2 database to archive the log files to support recovery of a
database, using commands like BACKUP and RECOVER.
• Using a Visual Explain tool to review the access plan and associated costs for a
SQL statement. Invoking the SQL tuning capabilities of the Data Server manager
to get recommendations for table indexes to reduce SQL processing costs.
Reorganize a table with the Db2 REORG utility to improve data access efficiency.
• Using Db2 diagnostic commands like db2pd to observe the locks acquired by
SQL statements and to investigate a lock wait condition between to concurrent
applications.
• Manage database security using a security administrator, the SECADM user,
creating database roles to grant database privileges and data access to users.
The demonstrations utilize Db2 [Link] on Linux. For many of the demonstration tasks,
students can choose to utilize a Db2 command line interface or the graphics interface
provided by the IBM Data Server Manager 2.1 software.

© Copyright IBM Corp. 1997, 2016 P-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 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:
[Link]
• Predictive and BI/Performance Management/Risk portfolio:
[Link]

© Copyright IBM Corp. 1997, 2016 P-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 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 • [Link]

software/analytics/training-
and-certification/
• Online support • [Link]
support/entry/portal/
Overview/Software
• IBM Web site • [Link]

© Copyright IBM Corp. 1997, 2016 P-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Overview of Db2 11.1

Overview of Db2 11.1

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 1 Overview of Db2 11.1

© Copyright IBM Corp. 1997, 2017 1-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Unit objectives
• Describe the system platforms supported by the Db2 Family of
products
• Compare the features available with different Db2 product editions
• Select the appropriate Db2 client software to support application client
or server systems
• Choose a method to install your Db2 product edition and plan
migrations of existing Db2 servers to the latest release
• Compare cloud-based Db2 options to a locally installed Db2 server

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 1-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 family product platforms

Db2
Operating Systems
 AIX
 Linux

Db2
 Windows
Db2

Db2 for z/OS Db2 for i

Db2 Db2

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 family product platforms

IBM Db2 is supported across diverse systems ranging from mainframes (Db2 for z/OS)
to distributed systems (formerly DB2 on Linux, Unix, and Windows).
This course is focused on the Db2 product which supports Linux, AIX and Windows
database servers on various different server types.
IBM Db2 for z/OS is still the undisputed leader for storing and harnessing mission
critical data. It remains the "gold standard" for system availability, scalability, security
and cost effectiveness. A majority of Fortune 500 companies, including the world’s top
banks, retailers and insurance providers trust Db2 for z/OS for storing their data.
Db2 for i is built into the operating system, and whereas most other database products
require costly add-ons for features, with Db2 for i it’s all there! As an extension of the
OS, administration is easy – you don’t even have to install it – its ready to go! Open
standard support including ANSI standard SQL, XML, JSON, [Link] and more provide
a multitude of development environments for application development. Analyze and
manage database performance through the provided tools that ship with the system!

© Copyright IBM Corp. 1997, 2017 1-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2: the scalable database

Db2 Advanced Enterprise Server Edition No CPU
Includes the functions and tools needed for large, complex enterprise or memory
environments, and is ideal for both transactional and data warehouse workloads. limits
Db2 Enterprise Server
Designed to meet the data server needs of midsize to large-size businesses and
is ideal for transactional and mixed workloads. It can be deployed on Linux, UNIX,
or Windows servers of any size, from one processor to hundreds of processors,
and on both physical and virtual servers.

Db2 Advanced Workgroup Edition 16 CPU

Includes the capabilities needed for medium-sized business environments, and is Cores,
ideal for both transactional and data warehouse workloads. 128GB
memory
Db2 Workgroup Server limits
Suitable for transactional database workloads in a departmental, workgroup, or
medium-sized business environment.

Db2 Express C 2 CPU

Provides all the core capabilities of DB2 at no charge. Easy to use and embed. Cores,
Db2 Express-C is a free, entry-level edition of the Db2 data server for the 16GB
developer and partner community. memory
Limits

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2: The scalable database

There are multiple Db2 database product editions, each with a unique combination of
features and functionality.
Db2 Advanced Enterprise Server Edition
Db2 Advanced Enterprise Server Edition is suitable for transactional, warehouse, and
mixed workloads. This edition has no processor, memory, or database size limits, which
makes it ideal for any size of workload. This edition includes all functions that are found
in the Db2 Enterprise Server Edition plus column-organized tables, in-memory
database, data compression, workload management, replication, and distributed
partitioning capability. This edition also comes with a full complement of warehouse
tools, and Data Server Manager Enterprise. This option installs only the Db2 server.
The included tools must be installed separately.
Db2 Advanced Workgroup Server Edition
Db2 Advanced Workgroup Server Edition is similar to the Db2 Advanced Enterprise
Server Edition, except that it places limits on processor and memory. This edition is the
data server of choice for deployment in a departmental, workgroup, or medium-sized
business environment. Db2 Advanced Workgroup Server Edition can be deployed in
Linux, UNIX, and Windows server environments and uses up to 16 cores and 128 GB
of memory.

© Copyright IBM Corp. 1997, 2017 1-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 Enterprise Server Edition

Db2 Enterprise Server Edition is suitable for transactional and mixed workloads. This
edition has no processor, memory, or database size limits, which makes it ideal for any
size of workload. This edition includes all functions that are found in Db2 Workgroup
Server Edition plus materialized query tables. This edition includes Data Server
Manager Base which requires a separate installation.
Db2 Workgroup Server Edition
Db2 Workgroup Server Edition is ideal for departmental, workgroup, or medium-sized
business environments. It includes all of the functionality that is needed to efficiently
process transactional workloads. This edition places limits on processor and memory
that makes it ideal for medium-sized workloads such as would be found in a
department. This edition includes Data Server Manager Base, which requires a
separate installation.
Db2 Express-C
Provides all the core capabilities of Db2 at no charge. Easy to use and embed.
Db2 Express-C is a free, entry-level edition of the Db2 data server for the developer
and partner community. It is designed to be up and running in minutes, is easy-to-use
and embed, includes self-management features, and embodies all of the core
capabilities of Db2 such as pureXML®. Solutions that are developed using Db2
Express-C can be seamlessly deployed using more scalable Db2 editions without
modifications to the application code.
Program changes:
• Db2 Express-C can be used for development and deployment at no charge, and
can also be distributed with third-party solutions without any royalties to IBM.
• It can be installed on physical or virtual systems with any amount of CPU and
RAM, and is optimized to use up to a maximum of 2 cores and 16GB of memory.
Db2 Express-C is refreshed at major release milestones and comes with online
community-based assistance. Users requiring more formal support, access to fix packs,
or additional capabilities such as high availability clustering and replication features, can
upgrade to other Db2 editions.

© Copyright IBM Corp. 1997, 2017 1-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Examples of features and functions by Db2 LUW Editions

Express C Workgroup Advanced Enterprise Advanced
Workgroup Server Enterprise

Data Compression
No No Yes No Yes
(row organized)
Db2 pureScale
No Yes(idle) Yes Yes(idle) Yes

HADR No Yes Yes Yes Yes

Column-organized
No No Yes No Yes
Tables (BLU)
Federation Db2 & Db2 &
Db2 LUW All All
Informix Informix
Temporal tables Yes Yes Yes Yes Yes
Data Partitioning
(MPP) No No Yes No Yes

Db2 Workload
Management No Offering Yes Offering Yes

Data Server Manager No Base Enterprise Base Enterprise

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Examples of features and functions by Db2 LUW Editions

The slide shows a comparison of the features and functions supported by the different
Db2 LUW editions. For a full list of functions for each edition, check the Db2 Knowledge
Center online.
The Advanced Enterprise and Workgroup allow full use of Db2 pureScale functionality.
The support for the Db2 Workgroup Server Edition and Db2 Enterprise Server Edition
on pureScale is only for one primary server and one standby server. The standby
server can only be used to perform administrative tasks, or be ready to take over from
the primary server in the event of planned or unplanned outages.

© Copyright IBM Corp. 1997, 2017 1-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 Direct Editions

• New Delivery Mechanism for Db2 licenses
 New license metrics to facilitate hybrid cloud deployments
 Acquire the product directly online (Passport Advantage)
 Option to deploy either on-premises or on cloud
• Two Versions depending on Requirements
 Db2 Direct Standard Edition 11.1
− Has all of the database features of Db2 Workgroup Server Edition
 Db2 Direct Advanced Edition 11.1
− Has all of the database features of Db2 Advanced Enterprise Server Edition
• Newly introduced simplified license metric, the Virtual Processor Core
(VPC) sold as a monthly license charge
• Predictable maintenance options:
 Enhancements and fixes approximately every four months
 A stable stream that only includes fixes once a year
Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 Direct Editions

Db2 Version V11.1 includes a new delivery mechanism for licensing.
The Db2 Direct Editions are intended to make it easier for a customer to acquire Db2
licenses for cloud deployments:
• New license metrics to facilitate hybrid cloud deployments
• Acquire the product directly online (Passport Advantage)
• Option to deploy either on-premises or on cloud
It does not matter where the customer places their Db2 server, on premise or cloud-
based. They are licensed by the number of Virtual Processor cores or vCPUs. The
license is totally flexible and can be moved between platforms without any change in
license fees. Note that this license is an OPEX (Operating Expense) license. The
customer is renting or leasing the Db2 license. The price includes the use of the product
as well as service and support. If the license is not renewed, the customer has no valid
license to run the database.

© Copyright IBM Corp. 1997, 2017 1-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

There are two Db2 Direct Editions, depending on what the database requirements are:
• Db2 Direct Standard Edition 11.1: has all of the database features of Db2
Workgroup Server Edition
• Db2 Direct Advanced Edition 11.1: has all of the database features of Db2
Advanced Enterprise Server Edition
Both of these licenses are sold as a monthly license charge using the Virtual Processor
Core (VPC) sold as a monthly license charge.
Customers can choose to maintain these databases with either a fix pack stream (about
every four months) which may contain new features and enhancements, or a stable
stream (about once a year) that contains only fixes.

© Copyright IBM Corp. 1997, 2017 1-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Virtual Processor Core (VPC)

• Virtual Processor Core
 VPC: Virtual Cores available to the operating system
−1 VPC for every VPC available to a virtual Servers Operating System, or 1 VPC
for each physical core of a non-partitioned physical server
− If the number of VPCs is greater than the physical cores, then you only need to
license the number of physical cores on the machine
− Minimum of 2 VPCs per deployment (1 VPC for idle/warm standby)

• Benefits to Customers
 Simplifies Processor and Sub-capacity Licensing
 Aligns to Cloud Hosted Solution Licensing standards across MSP’s
 Makes it easier for customers On-prem and in Cloud to stay in compliance

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Virtual Processor Core (VPC)

The Db2 Direct Editions require that the customer be aware of the number of cores that
are allocated to the virtual machine in order to determine the price of the license.
These virtual cores (VPCs) must be available to the operating system. The license
requirement is 1 VPC for every VPC available to the virtual operating system, with a
minimum of 2 VPCs required for any installation. A standby idle/warm machine that has
been configured for failover only requires a 1 VPC license.
In the event that the customer is able to determine what the physical hardware is that
the virtual machine is running on, they should not license more than the physical
number of cores. For instance, a processor chip may have two cores that enable
hyperthreading. This makes a guest operating system believe that it has access to four
VPCs. In this case, the customer should only acquire two licenses because there are
only two physical cores on the machine. For the vast majority of cloud systems, the way
that virtual machines are provisioned is based on VCPUs so Db2 Direct would follow
the same licensing mode.
There are a number of benefits to customers:
• Simplifies processor and sub-capacity licensing.
• Aligns to cloud hosted solution licensing standards across MSPs.
• Makes it easier for customers On-premises and in Cloud to stay in compliance.

© Copyright IBM Corp. 1997, 2017 1-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Expand Db2 Ecosystem/Skills

• New Db2 Developer-C Edition
 Freely downloadable just like Express-C
 Fully functional Db2 database server
− pureScale and DPF deployments
− Compression and BLU Acceleration

• Use Limitations
 For development and non-production only
 Unsupported edition (non-warranted)
 Environment limited usage:
−4 cores, 16GB of memory
− 100GB of data in user tablespaces

• Functional Differences from Db2 Developer Edition

 Excludes some “Supporting Programs”
− Cognos, IDA, WebSphere AS / MQ, DSM Enterprise

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Expand Db2 Ecosystem/Skills

© Copyright IBM Corp. 1997, 2017 1-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Operating systems supported by Db2 11.1

• New Operating System Support
 Power Linux LE (Little Endian)
− Red Hat Enterprise Linux (RHEL) 7.1+
− SUSE Linux Enterprise Server (SLES) 12
− Ubuntu 14.04 LTS

• Supported Operating Systems

 Intel 64-bit
− Windows 7, 8.1, 10, Windows Server 2012 R2
− Red Hat Enterprise Linux (RHEL) 6.7+, 7.1+
− SUSE Linux Enterprise Server (SLES) 11SP4+, 12
− CentOS 6.7, 7.1
− Ubuntu 14.04 LTS
 AIX Version 7.1 TL 3 SP5+
 zLinux
− Red Hat Enterprise Linux (RHEL) 7.1+
− SUSE Linux Enterprise Server (SLES) 12
Overview of Db2 11.1 © Copyright IBM Corporation 2017

Operating systems supported by Db2 11.1

Db2 Version 11.1 introduces support for Power Linux LE (Little Endian) which includes
support for pureScale. Db2 supports Power Linux LE with the following three operating
systems:
• Red Hat Enterprise Linux (RHEL) 7.1+
• SUSE Linux Enterprise Server (SLES) 12
• Ubuntu 14.04 LTS
Db2 Version 11.1 has also updated the operating systems that it supports. Note the
new requirements in the following list. Support for 32-bit server operating systems has
been eliminated for new instances in this release, so Windows 32-bit and Linux 32-bit
are no longer supported for the server editions but continue to be available as part of
the developer edition. 32-bit clients continue to be supported however.
Intel 64-bit:
• Windows 7, 8.1, 10, Windows Server 2012 R2
• Red Hat Enterprise Linux (RHEL) 6.7+, 7.1+
• SUSE Linux Enterprise Server (SLES) 11SP4+, 12
• CentOS 6.7, 7.1
• Ubuntu 14.04 LTS

© Copyright IBM Corp. 1997, 2017 1-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

AIX Version 7.1 TL 3 SP5+

zLinux
• Red Hat Enterprise Linux (RHEL) 7.1+
• SUSE Linux Enterprise Server (SLES) 12

© Copyright IBM Corp. 1997, 2017 1-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Operating systems: Virtualization

• IBM System z
 IBM Processor Resource/System Manager
 z/VM and z/KVM on IBM System z
• IBM Power
 IBM PowerVM and PowerKVM and IBM Workload Partitions on
IBM Power Systems
• Linux X86-64 Platforms
 Red Hat KVM
 SUSE KVM
• VMWare ESXi
• Docker container support – Linux only
• Microsoft
 Hyper-V
 Microsoft Windows Azure on x86-64 Windows Platforms only
• pureScale support on Power VM/KVM, VMWare, and KVM

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Operating systems: Virtualization

Db2 Version 11.1 supports a number of virtualization environments.
Virtualization can improve the utilization of processor/machine resources and also give
the customer an environment to test systems without having to invest in entire systems.
The following is a list of virtualized environments that Db2 11.1 supports:
• IBM System z
• IBM Processor Resource/System Manager
• z/VM and z/KVM on IBM System z
• IBM Power
• IBM PowerVM and PowerKVM and IBM Workload Partitions on
IBM Power Systems
• Linux X86-64 Platforms
• Red Hat KVM
• SUSE KVM
• VMWare ESXi
• Docker container support (Linux only)

© Copyright IBM Corp. 1997, 2017 1-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

• Microsoft
• Hyper-V
• Microsoft Windows Azure on x86-64 Windows Platforms only
Db2 pureScale systems support virtualization on Power VM/KVM, VMWare, and KVM.
You will note that pureScale is now supported in a virtualized environment and that
ROCE Adapters can now be virtualized in a VMWare environment (initially) so that
multiple nodes can share the same hardware adapter.

© Copyright IBM Corp. 1997, 2017 1-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 server connectivity options

Database IBM Data Server Client Db2 Servers

Administration Visual Tools (Data Studio)
and Replication Admin Tool
Application CLP
Development All Applications

IBM Data Server Runtime

Client
Replication CMD line
CLP
All Applications

Application IBM Data Server

Users Driver Package
All Applications IBM Data Server Driver
Db2 CLPPlus for JDBC and SQLJ
IBM Data Server Driver Java Applications
for ODBC and CLI

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 server connectivity options

IBM data server client and driver types
Several types of IBM® clients and drivers are available for the data server. Each client
and driver provides a particular type of support.
The IBM clients and drivers are as follows:
• IBM Data Server Driver Package(DS driver)
• IBM Data Server Driver for JDBC and SQLJ
• IBM Data Server Driver for ODBC and CLI
• IBM Data Server Runtime Client
• IBM Data Server Client
You can add Db2 Connect™ capability to any client or driver.
IBM Data Server Driver Package
The IBM Data Server Driver Package is a lightweight deployment solution that provides
runtime support for applications without the need to install the Data Server Runtime
Client or Data Server Client. This driver has a small footprint and is designed to be
redistributed by independent software vendors (ISVs) and to be used for application
distribution in mass deployment scenarios that are typical of large enterprises.

© Copyright IBM Corp. 1997, 2017 1-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

The IBM Data Server Driver Package includes the following capabilities:
• Db2® Command Line Processor Plus (CLPPlus), for dynamically creating,
editing, and running SQL statements and scripts.
• Support for applications that use ODBC, CLI, PHP, or Ruby to access databases.
• On Windows operating systems, support for applications that use .NET or
OLE DB to access databases. In addition, this driver package is available as an
installable image. Merge modules are available, which you can use to easily
embed the driver in a Windows Installer-based installation.
• Support for client applications and applets that are written in the Java™ language
using JDBC and for embedded SQL for Java (SQLJ).
• Support for running embedded SQL applications. No precompiler or bind
capabilities are provided.
• Application header files to rebuild the PHP, Ruby, Python, and Perl drivers. The
Python and Perl drivers are not available in the IBM Data Server Driver Package;
however, you can download and build these drivers by using the header files.
• Support for Db2 interactive CLI, by using the db2cli command. Support for
DRDA® traces, by using the db2drdat command.
• Support for IBM Informix® servers.
IBM Data Server Driver for JDBC and SQLJ
The IBM Data Server Driver for JDBC and SQLJ is the default driver for Java stored
procedures and user-defined functions. This driver provides support for Java client
applications and applets that use JDBC to access local or remote servers and that use
SQLJ for embedded static SQL in Java applications. This driver is a prerequisite for
IBM InfoSphere® Optim™ pureQuery® Runtime. This product provides static support
for Java client applications and applets and enables optimized data access by using the
pureQuery API. In addition, this product is supported by a full integrated development
environment (IDE) for Java database application development using IBM Data Studio.
IBM Data Server Driver for ODBC and CLI
The Data Server Driver for ODBC and CLI is a lightweight solution that is designed for
ISV deployments. This driver, also referred to as the CLI driver, provides runtime
support for applications using the ODBC API or CLI API, without the need to install the
Data Server Client or the Data Server Runtime Client. This driver is available only as a
tar file, not as an installable image. Messages are in English only.

© Copyright IBM Corp. 1997, 2017 1-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

IBM Data Server Runtime Client

To have command line processor (CLP) support and basic client support for running
and deploying applications, use the IBM Data Server Runtime Client. The IBM Data
Server Runtime Client provides a way to run applications on remote databases.
GUI tools are not shipped with the IBM Data Server Runtime Client.
Capabilities include the following:
• All the functionality of the IBM Data Server Driver Package, excluding
development tools and libraries.
• The Db2 command line processor for issuing commands. The CLP also provides
a basic way to remotely administer servers.
• The ASNCLP command-line program, for setting up and administering all
replication programs for Q replication and SQL replication.
• Support for common network communication protocols: TCP/IP and named
pipes.
• A smaller deployment footprint that requires less installation image size and less
required disk space than that of the IBM Data Server Client.
• A catalog that stores information for connecting to databases and servers.
IBM Data Server Client
For applications using Db2CI, use IBM Data Server Client. The IBM Data Server Client
includes all the functionality of the IBM Data Server Runtime Client, plus functionality for
database administration, application development using an API such as ODBC, CLI,
.NET, or JDBC., and client/server configuration.
Capabilities include the following:
• The ability to prune the IBM Data Server Client image to reduce the installation
image size on the Windows operating system.
• Replication tools to set up and administer all replication programs for Q
replication and SQL replication. These tools are the Replication Center, the
ASNCLP command-line program, and the Replication Alert Monitor tool. The
Replication Center is available only on Linux and Windows operating systems.
• First Steps documentation for new users.
• Visual Studio tools.
• Application header files.
• Precompilers for various programming languages.
• Bind support.
• Samples and tutorials.

© Copyright IBM Corp. 1997, 2017 1-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Streamlined upgrade process

• Upgrade directly from Version 9.7, 10.1 and 10.5 (3 releases back)
• Ability to roll-forward through database version upgrades
 Single-partition Db2 Enterprise Server Edition or Db2 pureScale
 Upgrading from Db2 Version 10.5 Fix Pack 7, or later
 Users are no longer required to perform an offline backup of existing
databases before or after they upgrade
 A recovery procedure involving roll-forward through database upgrade
now exists
• HADR environments can now be upgraded without the need to re-initialize
the standby database after performing an upgrade on the primary database
 For single-partition Db2 Enterprise Server Edition users upgrading from Db2
Version 10.5 Fix Pack 7, or later

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Streamlined upgrade process

If you have a Version 9.7, Version 9.8, Version 10.1, or Version 10.5 copy already
installed and you want to use Db2 Version 11.1 instead, you need to upgrade to
Version 11.1. Version 11.1 is a new version. You cannot apply a fix pack to upgrade
from a prior version to Version 11.1.
Upgrade is a recoverable operation:
• Roll forward recovery through database upgrade is now supported. This includes
the ability for an HADR standby to replay through log data written and shipped by
the primary database. Although database upgrade is now recoverable in all
configurations, only databases upgrading from Db2 Version 10.5 Fix Pack 7 or
later in single partition Enterprise Server Edition and pureScale configurations
can take advantage of the new recoverability support. In configurations using
multiple partitions, roll forward through a database upgrade is not supported. Roll
forward through a database upgrade is also not supported for databases
upgrading from Db2 Version 9.7, 10.1, and Db2 Version 10.5 Fix Pack 6 or
earlier.
• Avoid the need for an offline backup image during the upgrade procedure

© Copyright IBM Corp. 1997, 2017 1-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Database upgrade is now a recoverable event which means it is possible, depending

on your database environment, to avoid the need to take an offline database backups
before and after the database upgrade. For Db2 Version 10.5 Fix Pack 7 or later,
databases in configurations using single-partition Enterprise Server Edition or
pureScale, the ability to roll forward through a database upgrade is supported. In
configurations using multiple partitions, roll forward through a database upgrade is not
supported. Roll forward through a database upgrade is also not supported for
databases upgrading from Db2 Version 9.7, 10.1 and Db2 Version 10.5 Fix Pack 6 or
earlier.

© Copyright IBM Corp. 1997, 2017 1-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Preparing to install Db2 database servers

• Use the db2prereqcheck command to check the software and firmware
prerequisites of a specific Db2 version
• Installation prerequisites:
 Ensure that your system meets the necessary operating system, hardware,
software, communications, disk, and memory requirements
 There are different prerequisites for AIX, Linux, and Windows operating systems
• Disk and memory requirements:
 Ensure appropriate amount of disk space is available for Db2 environment
 Db2 Setup wizard provides dynamic size estimates based on the components
selected during a typical, compact, or custom installation
 On Linux and UNIX operating systems, 2 GB of free space in the /tmp directory is
recommended
 Memory requirements are affected by the size and complexity of your database
system, database activity, and the number of clients
 At a minimum, a Db2 database system requires 256 MB of RAM, 1 GB of RAM is
recommended for improved performance.

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Preparing to install Db2 database servers

Before installing Db2 database server, ensure that the necessary prerequisites are met,
such as disk, memory, and paging space requirements. There are also additional
prerequisites that depend on your operating system.
You can also install multiple Db2 copies on the same computer.
For Windows systems, there is a difference between installing one or multiple Db2
copies. Each Db2 copy can be at the same or different code levels. A Db2 copy is a
group of Db2 products that are installed at the same location.
For Linux and UNIX systems, each Db2 copy can be at the same or different code
levels. Root installation of Db2 products can be installed to an installation path of your
choice.
The IBM Knowledge Center for Db2 provides detailed pre-installation planning steps
for each of the supported operating system types.

© Copyright IBM Corp. 1997, 2017 1-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 software installation methods

Installation Method Windows UNIX / Linux

Db2 Setup Wizard Yes Yes
Install Using Response File Yes Yes
db2_install command No Yes
Payload File deployment No Yes

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 software installation methods

With Db2 11.1 you can install different Db2 product editions using the same installation
media files. You can update some Db2 editions to another one by just updating the
license file. You do not have to reinstall the Db2 database product.
The following list describes Db2 installation methods.
• Db2 Setup wizard
The Db2 Setup wizard is a GUI installer available on Linux, UNIX, and Windows
operating systems. The Db2 Setup wizard provides an easy-to-use interface for
installing Db2 database products and for performing initial setup and configuration
tasks.
The Db2 Setup wizard can also create Db2 instances and response files that can
be used to duplicate this installation on other machines.
On Linux and UNIX operating systems, an X server is required to display the Db2
Setup wizard.
Note: For non-root installations on Linux and UNIX operating systems, only one
Db2 instance can exist. The Db2 Setup wizard automatically creates the non-root
instance.

© Copyright IBM Corp. 1997, 2017 1-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

• Response file installation

A response file is a text file that contains setup and configuration values. The file
is read by the Db2 Setup program and the installation is performed according to
the values that have been specified.
A response file installation is also referred to as a silent installation.
Another advantage to response files is that they provide access to parameters
that cannot be set by using the Db2 Setup wizard.
On Linux and UNIX operating systems, if you embed the Db2 installation image
in your own application, it is possible for your application to receive installation
progress information and prompts from the installer in computer-readable form.
This behavior is controlled by the INTERACTIVE response file keyword.
There are a number of ways to create a response file:
• Using the response file generator
You can use the response file generator to create a response file that
replicates an existing installation. For example, you might install an IBM data
server client, fully configure the client, then generate a response file to
replicate the installation and configuration of the client to other computers.
• Using the Db2 Setup wizard
The Db2 Setup wizard can create a response file based on the selections you
make as you proceed through the Db2 Setup wizard. Your selections are
recorded in a response file that you can save to a location on your system. If
you select a partitioned database installation, two response files are
generated, one for the instance-owning computer and one for participating
computers.
One benefit of this installation method is that you can create a response file
without performing an installation. This feature can be useful to capture the
options required to install the Db2 database product. The response file can be
used at a later time to install the Db2 database product according to the exact
options you specified.
You can export a client or server profile with the db2cfexp command to save
your client or server configuration. Import the profile by using the db2cfimp
command. A client or server profile exported with the db2cfexp command can
also be imported during a response file installation by using the
CLIENT_IMPORT_PROFILE keyword.

© Copyright IBM Corp. 1997, 2017 1-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

You should export the client or server profile after performing the installation
and cataloging any data sources.
• Customizing the sample response files that are provided for each Db2
database product
An alternative to using the response file generator or the Db2 Setup wizard to
create a response file is to manually modify a sample response file. Sample
response files are provided on the Db2 database product DVD. The sample
response files provide details about all the valid keywords for each product.
• db2_install command (Linux and UNIX operating systems only)
The db2_install command installs all components for the Db2 database product
you specify with the English interface support. You can select additional
languages to support with the -L parameter. You cannot select or clear
components.
Although the db2_install command installs all components for the Db2 database
product you specify, it does not perform user and group creation, instance
creation, or configuration. This method of installation might be preferred in cases
where configuration is to be done after installation. To configure your Db2
database product while installing it, consider using the Db2 Setup wizard.
On Linux and UNIX operating systems, if you embed the Db2 installation image in
your own application, it is possible for your application to receive installation
progress information and prompts from the installer in computer-readable form.
This installation method requires manual configuration after the product files are
deployed.
Information: The command db2_install is deprecated and might be removed in a
future release.
• Payload file deployment (Linux and UNIX only)
This method is an advanced installation method that is not recommended for
most users. It requires the user to physically install payload files.
A payload file is a compressed tarball that contains all of the files and metadata
for an installable component.
This method is not supported for Db2 pureScale® installation.
This installation method requires manual configuration after the product files are
deployed.

© Copyright IBM Corp. 1997, 2017 1-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 deployment options

On Premises On Cloud

SOFTWARE APPLIANCE HOSTED MANAGED

Db2 DBaaS DBaaS
Db2 on Cloud
Db2 Warehouse Db2 Warehouse on
Db2 Hosted Cloud

CONTROL SIMPLICITY

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 deployment options

IBM gives you a lot of RDBMS deployment flexibility, which makes it perfect for
companies with hybrid cloud strategies.
The Db2 product provides editions that support software installation for on premises
servers, workstations or laptop systems.
IBM Db2 Hosted is an on-demand cloud service that delivers a Db2 multi-workload
SQL database in a cloud infrastructure. It offers robust performance and high
availability for mission-critical applications and analytics. The solution provides full
administrative access, and can eliminate the cost, complexity and risk of managing your
own infrastructure. IBM provisions and hosts the database server for you, but your
DBAs administer.
IBM Db2 Warehouse is a software-defined data warehouse for private clouds and
virtual private clouds that support Docker container technology. It is optimized for fast
and flexible deployment on your choice of hardware, with automated scaling to meet
agile analytic workloads. Fusing IBM Db2 and Netezza technologies, IBM Db2
Warehouse offers cloud elasticity combined with the simplicity of a software appliance.
The real power of IBM Db2 Warehouse is the high performing, analytics engine that
combines in-memory processing with in-database analytics across an MPP (massively
parallel processing) architecture.

© Copyright IBM Corp. 1997, 2017 1-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

IBM Db2 on Cloud (formerly dashDB for transactions) is a fully managed SQL cloud
database. It is configured and optimized for robust performance, and it provides a high
availability option to mitigate the effects of unplanned outages. The solution offers the
advanced features of an on-premises database without the cost, complexity and risk of
managing your own infrastructure.
IBM Db2 Warehouse on Cloud (formerly dashDB for analytics) is a fully managed
SQL database service in the cloud, optimized for analytic workloads. It is designed for
high performance at scale, utilizing technologies such as IBM BLU Acceleration,
embedded Netezza analytics and massively parallel processing. The easy-to-use web
console provides everything you need to quickly load data or migrate data, as Db2
Warehouse on Cloud works with supported Db2 drivers, and is compatible with Db2,
PDA, and Oracle.

© Copyright IBM Corp. 1997, 2017 1-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

IBM Db2 Hosted

• Provides a hosted Db2 environment that is
 Deployed on IBM SoftLayer (virtual private nodes/bare metal) or AWS
(virtual private nodes) cloud platform
 Administered by your organization's DBAs (all software including OS & database)
 Available via pay-as-you-go or subscription model (support included)

• Benefits include
 Convenience without the loss of control on cost effective infrastructure
 Five high performance hardware configurations and two database software tiers to match
capability and affordability needs
 BLU Acceleration
 Native encryption support included in all configurations ensuring data remains secure in
the cloud
 HADR for high availability and disaster recovery
 Unlimited ability to create databases to fully utilize the cloud infrastructure

• Deployment options
 Choice of cloud provider: SoftLayer or AWS
 Five t-shirt sized configurations: Small, Medium, Large, X-Large, 2X-Large
 Two versions of Db2 available: Workgroup Server Edition (Standard) and Advanced
Enterprise Server Edition (Advanced)

Overview of Db2 11.1 © Copyright IBM Corporation 2017

IBM Db2 Hosted

Db2 Hosted provides a complementary offering to on-premises databases, providing
the opportunity to scale without concern of physical infrastructure. Db2 Hosted currently
blends some of the characteristics of IaaS and PaaS. The customer selects the server
configuration based on needs. IBM will then create the VM and install Db2, then
address any subsequent VM security patches, management, and restore operations.
The customer is responsible for Db2 instance creation, HA setup, OS patches,
mandatory and optional Db2 patches (fix packs), upgrades, database backup and
restore, and setting up encryption.
Key features and benefits of IBM Db2 Hosted are:
• Accelerates and simplifies deployment. Take advantage of Db2 without the need
for an on-premises infrastructure.
• Native encryption included with all configurations. You're in control of your data,
even when it's not in your building. Leverage the benefits of infrastructure as a
service with the confidence of knowing your data is encrypted in flight, while in
use, and at rest.
• Optimizes performance and enhances security. Experience speed and reliability
with a private virtual machine or dedicated bare-metal.

© Copyright IBM Corp. 1997, 2017 1-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

• Five hardware configurations and two database editions to meet your business
demands. Keep infrastructure costs in line with the changing needs of the
business.
• Provides SQL compatibility support for Oracle Database applications.
Consider Db2 Hosted for a variety of operational and analytic workloads, from rapid
development and testing of new applications to deployment of production applications.
Choose Db2 Hosted when the time to deliver is short and resources and funding are
scarce. Decisions regarding platforms -- cloud or on-premises -- can often be made
after deployment.
Based on Db2 software, it comes with a preconfigured instance optimized for online
transaction processing applications. But while Db2 Hosted is configured to support the
creation and management of databases for online transaction processing applications,
it gives you the flexibility to create your own instances for analytic or mixed workloads.
Use of this offering reduces the time required for provisioning and deploying Db2 so
more resources can be devoted to developing new solutions and innovation.

© Copyright IBM Corp. 1997, 2017 1-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Target use-cases addressed by Db2 Hosted

Db2 Hosted is a great way to lift and shift an existing app to the cloud, but there are
other ways to take advantage of this offering as well:
Use Case Goal How Db2 Hosted Helps
Experiment in a cost effective
Take advantage of the latest environment that doesn’t take up data
Db2 technologies center space or management
Prototyping proof of bandwidth
concept (POC)
development projects Quickly demonstrate a positive ROI
Retain relevance to associated with IT projects
LOB initiatives
Manage year-to-year budget growth
Redundancy without Easy setup of secondary environment,
Mitigate risks for
building a new monthly charges, SoftLayer
unplanned downtime
data center data centers
Streamline initial move to cloud with
Leverage cloud to consolidate automated deployment, and use all of
Consolidation of sprawling on-premise systems your on-premises management
smaller on processes/tools.
premise databases
Take Advantage of a monthly
Reduce CAPEX
charge model

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Target use-cases addressed by Db2 Hosted

These are the typical use cases addressed by Db2 Hosted. However, it is not limited to
these particular use cases. It can pretty much be used however Db2 on-premises is
being used today.

© Copyright IBM Corp. 1997, 2017 1-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Db2 Connect

Db2 Connect client access to host

databases

• Db2 Connect's basic feature is providing a

direct connection to a host database from
desktop applications running on your
workstations.
• IBM Data Server Driver Package with Db2
Connect license is the simplest way to
provide this solution.
• Each workstation that has a client package
and Db2 Connect license installed can
establish a direct TCP/IP connection to:
• Db2 for z/OS
• IBM Db2 for IBM i
• Db2 servers.
• In addition, applications can connect to and
update multiple Db2 family databases in the
same transaction with the complete data
integrity provided by the two-phase commit
protocol.

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Db2 Connect
Db2 Connect™ provides connectivity to mainframe and midrange databases from
Linux, UNIX, and Windows operating systems. You can connect to Db2® databases on
the z/OS®, IBM® i, VSE, and VM operating systems and on IBM Power Systems™
hardware. You can also connect to databases that you did not create by using IBM
products if they are Distributed Relational Database Architecture™ (DRDA®)
compliant.
Db2 Connect is the industry-leading solution integrating System z®, System i® and
other enterprise data with client/server, web, mobile, and service-oriented architecture
applications. Db2 Connect delivers significant feature enhancements to improve
programmer productivity, provide a more robust infrastructure, and enable the
deployment of Db2 technology. Db2 Connect has several product offerings:
• Db2 Connect Enterprise Edition
• Db2 Connect Application Server Edition
• Db2 Connect Unlimited Edition for System z
• Db2 Connect Unlimited Edition for System i
• IBM Db2 Connect Application Server Advanced Edition
• IBM Db2 Connect Unlimited Advanced Edition for System z

© Copyright IBM Corp. 1997, 2017 1-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

It is strongly recommended that you use Db2 Connect client, notably the IBM data
server drivers and clients, instead of the Db2 Connect server. IBM data server drivers
and clients provide the same connection and application development functionality as
the Db2 Connect server. However, you can reduce complexity, improve performance,
and deploy application solutions with smaller footprints for your business users. Db2
Connect license files are required.

© Copyright IBM Corp. 1997, 2017 1-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 1 Overview of Db2 11.1

Unit summary
• Describe the system platforms supported by the Db2 Family of
products
• Compare the features available with different Db2 LUW product
editions
• Select the appropriate Db2 client software to support application client
or server systems
• Choose a method to install your Db2 product edition and plan
migrations of existing Db2 servers to the latest release
• Compare cloud-based Db2 options to a locally installed Db2 server

Overview of Db2 11.1 © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 1-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Db2 Command Line Processor (CLP) and GUI tools

Db2 Command Line

Processor (CLP) and
GUI tools

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

© Copyright IBM Corp. 1997, 2017 2-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Unit objectives
• Utilize the Db2 Command Line Processor to run Db2 commands, SQL
statements and command scripts
• Invoke the CLPPlus command line processor to connect databases
and to define, edit, and run statements, scripts, and commands
• List some of the ways IBM Data Server Manager can be used to
support Db2 database administration and SQL execution with Db2
servers

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 2-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

The Db2 CLP Command Line Processor

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

The Db2 CLP Command Line Processor

Through the Command Line Processor, you can issue:
• SQL statements
• XQuery statements (with the prefix XQUERY)
• Db2 commands
• OS system commands
The command line processor operates as follows:
• The CLP command (in either case) is typed at the command prompt.
• The command is sent to the command shell by pressing the ENTER key.
• Output is automatically directed to the standard output device.
• Piping and redirection are supported.
• The user is notified of successful and unsuccessful completion.
• Following execution of the command, control returns to the operating system
command prompt, and the user can enter more commands.
• When the CLP is called with a file input option, it will automatically set the
CLIENT APPLNAME special register to CLP filename.

© Copyright IBM Corp. 1997, 2017 2-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

CLP syntax

db2
option-flag db2-command
sql-statement
?

phrase
message
sql-state
class-code

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

CLP syntax
The db2 command starts the command line processor (CLP). The CLP is used to
execute database utilities, SQL statements and online help.
• option-flag - Specifies a CLP option flag.
• db2-command - Specifies a Db2 command, like BACKUP or REORG.
• sql-statement - Specifies an SQL statement.
• ? - Requests CLP general help.
• ? phrase - Requests the help text associated with a specified command or topic.
If the database manager cannot find the requested information, it displays the
general help screen.
• ? options - Requests a description and the current settings of the CLP options.
• ? help - Requests information about reading the online help syntax diagrams.
• ? message - Requests help for a message specified by a valid SQLCODE
(? sql10007n, for example).
• ? sqlstate - Requests help for a message specified by a valid SQLSTATE.
• ? class-code - Requests help for a message specified by a valid class-code.

© Copyright IBM Corp. 1997, 2017 2-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Using CLP to list Db2 command options

db2 ? REORG

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Using CLP to list Db2 command options

The slide shows how the command line processor can list the syntax and options for
Db2 commands.
The example shows options for a REORG command.

© Copyright IBM Corp. 1997, 2017 2-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Modes for using the Db2 CLP

Non-interactive mode

db2 connect to musicdb

db2 "select * from [Link]" more
(double quotes may be required)

Interactive mode

db2
db2=> connect to musicdb
db2=> select * from [Link]
Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Modes for using the Db2 CLP

Prefix all CLP commands or requests with db2, or use CLP in interactive mode by
typing db2 and then pressing Enter. In the interactive mode, the user can type CLP
commands without prefixing them by db2.
Tip: When using CLP without being in interactive mode on a Linux/UNIX
platform, remember to put quotes around the statement or command if special
characters are included.
To issue XQuery statements in CLP, prefix the statements with the XQUERY keyword.
Interactive mode does not allow you to do piping or other operating system functions at
the interactive CLP command level. To execute operating system commands without
quitting interactive mode, issue !<operating-system-command>.
In the interactive mode, the history of commands is displayed by entering history (or
shortened form h). Two variations are allowed:
• reverse (r) list in reverse order, in other words most recent first
• num (such as 5) limits the list to the last num history entries

© Copyright IBM Corp. 1997, 2017 2-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Examples, assuming that you first entered db2start, then a “list active databases”
command, and then you entered ? sql11111:
db2 => h
1 db2start
2 list active databases
3 ? sql11111
4 h
db2 => h r
5 h r
4 h
3 ? sql11111
2 list active databases
1 db2start
db2 => h r 3
6 h r 3
5 h r
4 h
There is also an edit (e) command which enables editing of a previous command.
You can edit the command using the number in the history list, for example e 2. If no
number is entered, the last command would be edited.
After having edited the command and closed the editor, the edited command is
displayed in the CLP window, and you will be asked:
Do you want to execute the above command ? (y/n)
If you enter y, the command as edited is executed.
With runcmd (r) you can re-run a previously executed command. You can do this using
the number from the history list, for example r 3. If no number is entered, the last
command is re-executed.
If a command that you are entering exceeds the limit allowed at the command prompt,
use a \ (backslash) (in Linux/UNIX) as the line continuation character. If you want a
blank space between the last character on the current line and the first character on the
next line, do not forget to code a blank space before the backslash. You might want to
use the CLP flag -t instead of the \ (backslash). It says that the CLP statement
terminates with a ; (semicolon).

© Copyright IBM Corp. 1997, 2017 2-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

In its output, CLP represents a SQL NULL value as a hyphen (-). If the column is
numeric, the hyphen is placed at the right of the column. If the column is not numeric,
the hyphen is at the left.
Note: In the interactive mode, OS commands cannot be used because of the prefix
db2 =>.

© Copyright IBM Corp. 1997, 2017 2-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Using an input file with the Command Line Processor

Edit [Link]

--comment: db2 -svtf [Link]

connect to sample;

create table tab3

(name varchar(20) not null,
phone char(40),
salary dec(7,2));

select * from tab3;

commit work;

connect reset;

db2 -svtf [Link] f: read statements from file

v: echo command text
t: file contains statement termination(;)
s: stop execution for errors
Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Using an input file with the Command Line Processor

The slide shows how the Db2 command line processor could be used to execute a
series of Db2 commands or SQL statements. You may have a large set of DDL
statements in a file that could crate many database objects, like tables, indexes and
views. The Db2 command line processor can be used to execute those statements
using the text file.
For example you could use an editor to create a file called [Link].
Comments are denoted with a line that starts with two hyphens (--).
A semicolon can be used to denote the end of a SQL statement if the file is executed
with the -t command option.
• In non-interactive mode, execute the file with db2 -svtf [Link]. Since db2 was
not coded in the input file, only Db2 commands can be coded in the input file.
• In non-interactive mode, the command to execute the commands in the input file
must be started with db2.
• The -s option says to stop execution if an error occurs.
• The -v option says to echo the current command on the monitor screen.
• The -t option says the statements end with a semicolon.
The -f option says the command input is read from an input file called [Link].

© Copyright IBM Corp. 1997, 2017 2-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

The CLPPlus Command Line Processor

• Support for establishing connections to databases when a database
user ID and password are provided.
• Buffer that can be used to store scripts, script fragments, SQL
statements, SQL PL statements, or PL/SQL statements for editing and
then execution. Text in the buffer can be listed, printed, edited, or run
as a batch script.
• Comprehensive set of processor commands can be used to define
variables and strings that can be stored in the buffer.
• Set of commands that retrieve information about the database and
database objects.
• Ability to store buffers or buffer output to a file.
• Multiple options for formatting the output of scripts and queries.
• Support for executing system-defined routines.
• Support for executing operating system commands.
• Option for recording the output of executed commands, statements, or
scripts.
Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

The CLPPlus Command Line Processor

Command line processor plus (CLPPlus) provides a command line user interface that
you can use to connect databases and to define, edit, and run statements, scripts, and
commands.
CLPPlus includes the following features:
• Support for establishing connections to databases when a database user ID and
password are provided.
• A buffer that can be used to store scripts, script fragments, SQL statements,
SQL PL statements, or PL/SQL statements for editing and then execution.
Text in the buffer can be listed, printed, edited, or run as a batch script.
• A comprehensive set of processor commands can be used to define variables
and strings that can be stored in the buffer.
• A set of commands that retrieve information about the database and database
objects.
• Ability to store buffers or buffer output to a file.
• Multiple options for formatting the output of scripts and queries.
• Support for executing built-in routines.

© Copyright IBM Corp. 1997, 2017 2-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

• Support for executing operating system commands.

• Option for recording the output of executed commands, statements, or scripts.
• The CLPPlus provides a complement to the functions provided by the command
line processor (CLP).
The CLPPlus only supports SERVER, SERVER_ENCRYPT, and KERBEROS
authentication.

© Copyright IBM Corp. 1997, 2017 2-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Example CLPPlus interactive SQL execution

Column statements can

set output format

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Example CLPPlus interactive SQL execution

The slide shows an example of a CLPPlus command line session.
The database connection was established through a series of prompts. The column
statements are used to limit the output size of several Db2 catalog table columns that
are much larger than the results that need to be displayed.
It is also possible to provide a connection string with the clpplus command to have the
database connection started initially.

© Copyright IBM Corp. 1997, 2017 2-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

IBM Data Server Manager

• IBM Data Server Manager (DSM) simplifies database
administrative tasks for both expert and novice users.
• With one simple IBM Data Server Manager server installation, you
can access multiple IBM data management platforms without the
need to install or update any client code.
• Data Server Manager consolidates information from multiple
systems in a single graphical interface that is accessible from any
standard web browser. The supported platforms include:
 IBM Db2 for Linux, UNIX and Windows
 IBM Db2 for z/OS
 IBM BigInsights
• IBM Data Server Manager is easy to deploy and helps IT staff
perform administrative and performance tasks easily and efficiently
with less manual effort

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

IBM Data Server Manager

IBM Data Server Manager helps administer, monitor, manage, and optimize the
performance of IBM data management platforms across the enterprise. It provides
database administrators (DBAs) and other IT staff with the information they need to
manage performance proactively and prevent problems before they impact the
business.
IBM Data Server Manager simplifies database administrative tasks for both expert and
novice users. With one simple IBM Data Server Manager server installation, you can
access multiple IBM data management platforms without the need to install or update
any client code. Data Server Manager consolidates information from multiple systems
in a single graphical interface that is accessible from any standard web browser. The
supported platforms include:
• IBM Db2
• IBM Db2 for z/OS
• IBM BigInsights
IBM Data Server Manager is easy to deploy and helps IT staff perform administrative
and performance tasks easily and efficiently with less manual effort:

© Copyright IBM Corp. 1997, 2017 2-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

• Reduce data management complexity with a simple, unified architecture and

integrated web console to help administer and maintain the health of databases
across the enterprise.
• Increase operational efficiency with scalable management to continually
enforce best-practice configuration settings to resolve problems faster and avoid
application outages.
• Meet Service Level Agreements and minimize business disruptions with
enhanced query tuning capabilities that help drill down into SQL performance
issues. Maintain compliance with enterprise security policies that can easily
extend access to new users.

Data Server Manager is available in two editions:

• IBM Data Server Manager Base Edition

Data Server Manager Base Edition offers database administration and basic
performance monitoring capabilities at no charge.
• IBM Data Server Manager Enterprise Edition
Data Server Manager Enterprise Edition offers advanced capabilities including
enhanced monitoring, centralized configuration management, refined
performance management and query tuning with expert advice. Data Server
Manager Enterprise Edition is packaged with Db2 advanced editions or Db2
Performance Management Offering for non-advanced Db2 Editions.

© Copyright IBM Corp. 1997, 2017 2-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

DSM uses stored database connection profiles

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

DSM uses stored database connection profiles

Data Server Manager uses connection profiles to perform database administration
tasks.
The connection profile includes the network information needed to access Db2
database servers, like TCP/IP host names and port numbers. The connection profile
can also include the user id and optionally the password that will be used to connect to
a database.

© Copyright IBM Corp. 1997, 2017 2-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Using DSM to create and manage database objects

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Using IBM DSM to create and manage database objects

Data Server Manager can be used to create and manage Db2 database objects like
tables and indexes.
You select the options and define object attributes using DSM to create the SQL
statements to define or alter objects.

© Copyright IBM Corp. 1997, 2017 2-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Using DSM to generate and execute Db2 utilities

1) Select the Db2

command options

2) Review and
edit generated
Db2 commands

3) Start command execution

or schedule processing for
another time

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Using DSM to generate and execute Db2 utilities

Data Server Manager can be used to generate Db2 commands like BACKUP,
RESTORE, and LOAD.
You can edit and save the generated Db2 commands. You can also execute the
commands immediately or schedule the utility processing for another time.
The slide shows a set of options for the BACKUP utility. The generated statements
include a set of Db2 commands used to deactivate a Db2 database for offline backup
processing.

© Copyright IBM Corp. 1997, 2017 2-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Using DSM to edit and execute SQL scripts

You can invoke SQL

Explain and Tuning
functions from this view

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Using DSM to edit and execute SQL scripts

With IBM Data Server Manager, you create, edit and execute SQL scripts. You can
also load previously saved scripts from a disk file.
When a script is executed DSM allows you to examine the returned results of SQL
statements or review any messages or SQL codes generated.
This same view can be used to invoke the visual explain tool or begin a SQL tuning
session where you can get suggestions to improve SQL execution efficiency.

© Copyright IBM Corp. 1997, 2017 2-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Viewing query results with DSM

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Viewing query results with DSM

When a SQL query produces a result, you can use DSM to scroll through the data
returned.

© Copyright IBM Corp. 1997, 2017 2-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Monitor database activity using DSM

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Monitor database activity using DSM

Real-time and historical monitoring
Data Server Manager can be configured to collect both real-time and historical metrics
for a database. DBAs can use historical information to discover trends or investigate
deviations from behavior that was observed in the past.
A time slider is provided, along with easy-to-select time frames to choose from. DBAs
can pick a time frame and then use the time slider to move, widen, or narrow the time
frame that they want to see.

© Copyright IBM Corp. 1997, 2017 2-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 2 Db2 Command Line Processor (CLP) and GUI tools

Unit summary
• Utilize the Db2 Command Line Processor to run Db2 commands, SQL
statements and command scripts
• Invoke the CLPPlus command line processor to connect databases
and to define, edit, and run statements, scripts, and commands
• List some of the ways IBM Data Server Manager can be used to
support Db2 database administration and SQL execution with Db2
servers

Db2 Command Line Processor (CLP) and GUI tools © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 2-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
The Db2 database manager instance

The Db2 database manager

instance

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

© Copyright IBM Corp. 1997, 2017 3-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Unit objectives
• Specify the key features of an instance
• Create and drop a Db2 instance
• Use db2start and db2stop commands to manage a Db2 instance
• Display and set Db2 registry variables
• Describe and modify the database manager configuration

The Db2 database manager instance © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 3-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

What is an instance?
Db2 PRODUCT
Instance_1 Instance_2

DBM CFG DBM CFG

DB CFG DB CFG

Catalog DB_1 LOG Catalog DB_3 LOG

DB CFG

Catalog DB_2 LOG

The Db2 database manager instance © Copyright IBM Corporation 2017

What is an instance?
An instance is a logical database manager environment where you catalog databases
and set configuration parameters. Depending on your needs, you can create more than
one instance on the same physical server providing a unique database server
environment for each instance.
For non-root installations on Linux and UNIX operating systems, a single instance is
created during the installation of your Db2 product. Additional instances cannot be
created.
You can use multiple instances to do the following:
• Use one instance for a development environment and another instance for a
production environment.
• Tune an instance for a particular environment.
• Restrict access to sensitive information.
• Control the assignment of SYSADM, SYSCTRL, and SYSMAINT authority for
each instance.
• Optimize the database manager configuration for each instance.
• Limit the impact of an instance failure. In the event of an instance failure, only one
instance is affected. Other instances can continue to function normally.

© Copyright IBM Corp. 1997, 2017 3-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Multiple instances will require:

• Additional system resources (virtual memory and disk space) for each instance.
• More administration because of the additional instances to manage.
The instance directory stores all information that pertains to a database instance. You
cannot change the location of the instance directory once it is created. The directory
contains:
• The database manager configuration file
• The system database directory
• The node directory
• The node configuration file ([Link])
• Any other files that contain debugging information, such as the exception or
register dump or the call stack for the Db2 database processes.
The visual shows that an Instance provides the foundation needed to support a Db2
database. An instance can support one or more databases. The instance provides
management of databases, while the database provides data management. Each
database has its own configuration, a set of catalog tables and a set of transaction logs.

© Copyright IBM Corp. 1997, 2017 3-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

The database manager instance

A database server could Multiple Db2 instances can run on
support multiple Db2 different Db2 software levels
instances
Database Server

A Db2 instance could A Db2 instance can

manage a single database manage multiple databases

Database Manager inst1 Database Manager inst2

Database 1 Database 1 Database 2

Tablespace A Tablespace B
Table 1 Table 2 Table 3 Table 4

connect to
Local User Application
Path+...
DB2INSTANCE designates
DB2INSTANCE=inst1 the 'current' instance
The Db2 database manager instance © Copyright IBM Corporation 2017

The database manager instance

The slide displays the use of multiple Db2 instances and show how a table will be
defined in a single Db2 database, which is defined in a single Db2 instance.
A Db2 database server may support multiple Db2 instances. Each Db2 database
belongs to a specific Db2 instance. In Db2 each relational table is defined in one or
more table spaces, which belong to a single Db2 database.
You may use one Db2 instance to support a production application, and use another
Db2 instance to support development or testing. The instances could be running on
different releases or fix pack levels of Db2.
A database name must be unique within an instance, but the same database name
could be used in another Db2 instance on the same database server.
There is the concept of the 'current' instance. The variable DB2INSTANCE defines the
current Db2 instance. This impacts command processing. For example the Db2
command GET DBM CFG will return the configuration of the current instance, and
UPDATE DBM CFG will change the options for the current instance.

© Copyright IBM Corp. 1997, 2017 3-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Create and drop an instance

• CREATE (different on Linux/UNIX and Windows):
 Prerequisites met?
 Creates the Instance
 Creates the SQLLIB subdirectory
 Creates needed directories in the SQLLIB subdirectory
 Creates the DBM CFG with defaults
db2icrt –u <fencedID> <instance_name> (UNIX/Linux)
db2icrt <instance_name> (Windows)

• DROP:
 Instance must be stopped and no applications are allowed to be connected
to the databases in this instance
 Does not remove (drop) databases
 Removes the Instance
db2idrop <instance_name>

The Db2 database manager instance © Copyright IBM Corporation 2017

Create and drop an instance

Although an instance is created as part of the installation of the database manager,
your business needs might require you to create additional instances.
If you belong to the Administrative group on Windows, or you have root user authority
on Linux or UNIX operating systems, you can add additional instances. The computer
where you add the instance becomes the instance-owning computer (node zero).
Ensure that you add instances on a computer where a Db2 administration server
resides. Instance IDs should not be root or have password expired.
Restrictions:
• On Linux and UNIX operating systems, additional instances cannot be created for
non-root installations.
• If existing user IDs are used to create Db2 instances, make sure that the
user IDs:
• are not locked
• do not have expired passwords
To add an instance using the command line, enter the command:
db2icrt instance_name.

© Copyright IBM Corp. 1997, 2017 3-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

When creating instance on an AIX server, you must provide the fenced user id; for
example:
DB2DIR/instance/db2icrt -u db2fenc1 db2inst1
When using the db2icrt command to add another Db2 instance, you should provide the
login name of the instance owner and optionally specify the authentication type of the
instance. The authentication type applies to all databases created under that instance.
The authentication type is a statement of where the authenticating of users will take
place.
To drop a root instance, issue the db2idrop command. To drop non-root instances, you
must uninstall your Db2 database product.
To remove a root instance using the command line:
1. Stop all applications that are currently using the instance.
2. Stop the Command Line Processor by running terminate commands in each
Command window.
3. Stop the instance by running the db2stop command.
4. Back up the instance directory indicated by the DB2INSTPROF registry
variable.
On Linux and UNIX operating systems, consider backing up the files in the
INSTHOME/sqllib directory (where INSTHOME is the home directory of the
instance owner). For example, you might want to save the database manager
configuration file, db2systm, the [Link] file, user-defined functions
(UDFs), or fenced stored procedure applications.
5. For Linux and UNIX operating systems only, log off as the instance owner and
log in as a user with root user authority.
6. Issue the db2idrop command. For example:
db2idrop InstName
where InstName is the name of the instance being dropped.
The db2idrop command removes the instance entry from the list of instances and
removes the sqllib subdirectory under the instance owner's home directory.

© Copyright IBM Corp. 1997, 2017 3-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

db2icrt command notes

• db2icrt command authorization
 Root user or non-root user authority is required on Linux and UNIX
operating systems
− Non-root user authority can be used if the Db2 software is installed by the non-root
user
 Local Administrator authority is required on Windows operating systems
• Linux and UNIX systems utilize an instance owner
 Instance owner is a system user id with the same name as the Db2 instance
 The primary group associated with the instance owner becomes the initial
SYSADM_GROUP for the instance
− The SYSADM_GROUP authorization is needed to create a Db2 database
 A fenced user id can be defined for an instance to limit system permissions
associated with 'fenced' stored procedures to enhance security

The Db2 database manager instance © Copyright IBM Corporation 2017

db2icrt command notes

System authorization is required to execute the db2icrt command.
On Linux and UNIX systems, the Db2 instance name must match a defined system
user id. This user is referred to as the instance owner. The files associated with the Db2
databases managed by the instance will be owner by this instance owner.
Db2 will initially set the Db2 Database Manager Configuration option,
SYSADM_GROUP to the primary group defined for the instance owner id.
A number of important privileges are associated with the operating system group
relative to this Db2 instance. The ability to create a Db2 database in the instance or
make changes to the instance configuration require the SYSADM_GROUP
membership.
On Linux and UNIX, the fenced user is used to run user defined functions (UDFs) and
stored procedures outside of the address space used by the Db2 database.

© Copyright IBM Corp. 1997, 2017 3-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Starting and stopping an instance

• To connect to a database, the Db2 instance must be started.
• If a Db2 instance is stopped, all databases in the instance are
unavailable for application connections.
• A db2stop command will fail to stop the Db2 instance if there are active
connections to any database unless the FORCE option is included:
db2stop force

db2start db2stop

The Db2 database manager instance © Copyright IBM Corporation 2017

Starting and stopping an instance

Starting the instance on UNIX and Linux systems:
You might need to start or stop a Db2 database during normal business operations. For
example, you must start an instance before you can perform some of the following
tasks: connect to a database on the instance, precompile an application, bind a
package to a database, or access host databases.
Before you start an instance on your Linux or UNIX operating system:
1. Log in with a user ID or name that has SYSADM, SYSCTRL, or SYSMAINT
authority on the instance; or log in as the instance owner.
2. Run the startup script as follows, where INSTHOME is the home directory of the
instance you want to use:
. INSTHOME/sqllib/db2profile (for Bourne or Korn shell)
source INSTHOME/sqllib/db2cshrc (for C shell) Procedure
To start the instance:
• From the command line, enter the db2start command. The Db2 database
manager applies the command to the current instance.
• From IBM Data Studio, open the task assistant for starting the instance.

© Copyright IBM Corp. 1997, 2017 3-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

On Windows based Db2 servers, in order to successfully launch the Db2 database
instance as a service, the user account must have the correct privilege as defined by
the Windows operating system to start a Windows service. The user account can be a
member of the Administrators, Server Operators, or Power Users group. When
extended security is enabled, only members of the DB2ADMNS and Administrators
groups can start the database by default.
By default, the db2start command launches the Db2 database instance as a Windows
service. The Db2 database instance on Windows can still be run as a process by
specifying the /D parameter on the db2start command. The Db2 database instance can
also be started as a service by using the Control Panel or the NET START command.
Stopping instances using db2stop:
You might need to stop the current instance of the database manager.
1. Log in or attach to an instance with a user ID or name that has SYSADM,
SYSCTRL, or SYSMAINT authority on the instance; or, log in as the instance
owner.
2. Display all applications and users that are connected to the specific database
that you want to stop. To ensure that no vital or critical applications are running,
list applications. You need SYSADM, SYSCTRL, or SYSMAINT authority for
this activity.
3. Force all applications and users off the database. You require SYSADM or
SYSCTRL authority to force users.
4. If command line processor sessions are attached to an instance, you must run
the TERMINATE command to end each session before running the db2stop
command.
5. From the command line, enter the db2stop command. The Db2 database
manager applies the command to the current instance.

© Copyright IBM Corp. 1997, 2017 3-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Db2 registry and environment variables

• Variables allow customization of the Db2 runtime processing to fit specific
application needs
• Variables for basic common configuration
 DB2COMM - must be set to TCPIP to enable tcp/ip client communication
db2set db2comm=tcpip
 DB2FODC - This registry variable controls a set of troubleshooting-
related parameters used in First Occurrence Data Collection (FODC)
• Some variables alter Db2 internal processing
 DB2_REDUCED_OPTIMIZATION can adjust Db2 optimization
processing
• DB2_WORKLOAD can be set to provide a specific grouping of several
registry variables with predefined settings
 DB2_WORKLOAD Values: 1C, CM, COGNOS_CS, FILENET_CM,
INFOR_ERP_LN, MAXIMO, MDM, SAP, TPM, WAS, WC, or WP
 When DB2_WORKLOAD is set to ANALYTICS, Db2 will configure
databases for BLU Acceleration processing with column-organized
tables

The Db2 database manager instance © Copyright IBM Corporation 2017

Db2 registry and environment variables

Db2 provides a number of registry variables and environment variables that you are
good to know to get up and running. Options can be set at the Global (server) or Db2
instance level.
Generally the instance must be restarted after changing registry variables.
Use the profile registries to control the environment variables from one computer.
Different levels of support are provided through the different profiles.
A Db2 database is affected by the following profile registries:
• The Db2 instance-level profile registry contains registry variables for an instance.
Values that are defined in this registry override their settings in the global registry.
• The Db2 global-level profile registry contains settings that are used if a registry
variable is not set for an instance. All instances that pertain to a particular copy of
Db2 Enterprise Server Edition can access this registry.
Most environment variables are set in the Db2 database profile registries by using the
db2set command. The few variables that are set outside the profile registries require
different commands depending on your operating system.

© Copyright IBM Corp. 1997, 2017 3-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

To use the db2set command, make sure you have the privileges that are required to set
registry variables.
• On Linux and UNIX operating systems, you must have the following privileges:
• SYSADM authority to set variables in the instance-level registry
• root authority to set variables in the global-level registry
• On Windows operating systems, you must have one of the following privileges:
• local Administrator authority
• SYSADM authority with the following conditions:
• If extended security is enabled, SYSADM users must belong to the
DB2ADMNS group.
• If extended security is not enabled, SYSADM users can make updates if the
appropriate permissions are granted to them in the Windows registry.
When you use the db2set command to set variables in the profile registries, you do not
need to restart your computer for variable values to take effect. However, changes do
not affect Db2 applications that are currently running or users that are active. The Db2
registry applies the updated information to Db2 server instances and Db2 applications
that are started after the changes are made.
You can set a variable at one or more of four levels: operating-system environment,
node instance, instance, and global. The Db2 database system uses this order of
precedence to access and resolve variable settings. If you already set the value of a
variable at the operating-system-environment level, an update to the value of the
variable does not take effect immediately, even if you use the -immediate parameter,
because the operating-system-environment level takes precedence over the registries.
Aggregate registry variables
Use an aggregate registry variable to group several registry variables as a configuration
that is identified by another registry variable name. Each registry variable that is part of
the group has a predefined setting. The aggregate registry variable is given a value that
is interpreted as declaring several registry variables.
The intention of an aggregate registry variable is to ease registry configuration for broad
operational objectives.
The only valid aggregate registry variable is DB2_WORKLOAD.

© Copyright IBM Corp. 1997, 2017 3-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Valid values for this variable are:

• 1C
• ANALYTICS
• CM
• COGNOS_CS
• FILENET_CM
• INFOR_ERP_LN
• MAXIMO
• MDM
• SAP
• TPM
• WAS
• WC
• WP
Starting with Db2 10.5, if most tables in your database are going to be column-
organized tables, set the DB2_WORKLOAD registry variable to ANALYTICS before
you create the database. Doing so helps to configure memory, table organization, page
size, and extent size, and enables workload management.

© Copyright IBM Corp. 1997, 2017 3-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

The db2set command

Command Result
db2set -lr Display all supported registry variables.
db2set -all Display all defined values for the current instance.

db2set -g DB2COMM=TCPIP Set the DB2COMM registry variable to TCPIP for all
instances pertaining to a particular installation.

db2set -i MYINST DB2COMM=TCPIP Set the DB2COMM registry variable to TCPIP only
for instance MYINST.

db2set -null DB2COMM Set the DB2COMM registry variable to null at the
default level. The default level is the instance level.

db2set DB2_ANTIJOIN= -immediate Delete the current value of the registry variable
DB2_ANTIJOIN so that it takes effect the next time
the SQL statement is compiled.

The Db2 database manager instance © Copyright IBM Corporation 2017

The db2set command

The visual shows examples of how the db2set command can be used to display, set
and reset the Db2 registry variables.
The following examples show how to issue the various parameters with the db2set
command:
• Display all defined instant profiles pertaining to a particular installation:
db2set -l
• Display all supported registry variables: db2set -lr
• Display all defined global variables that are visible to all instances pertaining to a
particular installation: db2set -g
• Display all defined variables for the current instance: db2set
• Display all defined values for the current instance: db2set -all
• Display all defined values for the DB2COMM registry variable for the current
instance: db2set -all DB2COMM
• Reset all defined variables for the instance INST on member 3:
db2set -r -i INST 3

© Copyright IBM Corp. 1997, 2017 3-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

• Set the DB2COMM registry variable to TCPIP for all instances pertaining to a
particular installation: db2set -g DB2COMM=TCPIP
• Set the DB2COMM registry variable to TCPIP only for instance MYINST:
db2set -i MYINST DB2COMM=TCPIP•
• Set the DB2COMM registry variable to null at the default level. The default level is
the instance level: db2set -null DB2COMM
• Delete the current value of the registry variable DB2_ANTIJOIN so that it takes
effect the next time the SQL statement is compiled:
db2set DB2_ANTIJOIN= -immediate

© Copyright IBM Corp. 1997, 2017 3-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Checking Db2 registry variables using SQL

• The ENV_GET_REG_VARIABLES table function returns the Db2
registry settings. Syntax:
>>-ENV_GET_REG_VARIABLES--(--member--)------------><

• For example, the registry variable DB2DBDFT, which specifies the

database alias name to use for implicit connections, is set to CORP_1.
db2set db2dbdft=CORP_1
db2start

• You can issue a query to show that registry variable setting:

select substr(reg_var_value,1,20) as VALUE, substr(reg_var_on_disk_value,1,20)
as ON_DISK_VALUE
from table(env_get_reg_variables(-1)) as T1
where reg_var_name = 'DB2DBDFT‘

 This query returns the following output:

VALUE ON_DISK_VALUE
-------------------- --------------------
CORP_1 CORP_1

The Db2 database manager instance © Copyright IBM Corporation 2017

Checking Db2 registry variables using SQL

Shown are examples of using the table function ENV_GET_REG_VARIABLES in a
SQL statement to list the active and on-disk setting for Db2 registry variables.
The ENV_GET_REG_VARIABLES table function returns the Db2 registry settings from
one or all database members.
The ENV_GET_REG_VARIABLES table function replaces the deprecated
REG_VARIABLES administrative view. The ENV_GET_REG_VARIABLES function is
different in that it allows for a single parameter value to denote a specific member to
query, and returns an addition result for the registry setting currently stored on disk.
Syntax:
>>-ENV_GET_REG_VARIABLES--(--member--)----------><

© Copyright IBM Corp. 1997, 2017 3-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Making changes to the database manager configuration

• Check the current DBM settings using the GET DBM CFG command
• Change DBM CFG options using the UPDATE DBM CFG command
db2 update dbm cfg using svcename 50000
• Some changes to the database manager configuration can not be
applied immediately. These changes become effective only after Db2 is
restarted using db2start
• To see which parameter changes took effect dynamically and which
ones did not, retrieve the DBM CFG and display the parameter details
using the following commands:
db2 attach to db2inst1
db2 get dbm cfg show detail
• Active and deferred DBM parameters can also be viewed using the
db2pd command -dbmcfg option
db2pd -dbmcfg

The Db2 database manager instance © Copyright IBM Corporation 2017

Making changes to the database manager configuration

You manage the database manager configuration file through the GET DBM CFG or
UPDATE DBM CFG command.
The SHOW DETAIL option of GET DBM CFG shows the current values of database
configuration parameters and the value of the parameters that will be used the next
time you start the database manager. The SHOW DETAIL clause requires an instance
attachment.
Some configuration parameters can be set to AUTOMATIC, allowing the database
manager to automatically manage these parameters to reflect the current resource
requirements. To turn off the AUTOMATIC setting of a configuration parameter while
maintaining the current internal setting, use the MANUAL keyword with the UPDATE
DATABASE CONFIGURATION command. If the database manager updates the value
of these parameters, the GET DB CFG SHOW DETAIL and GET DBM CFG SHOW
DETAIL commands will show the new value.
When a Db2 instance is created a new database manager configuration file with default
values is created for the instance. The instance configuration can be listed using the
Db2 command GET DBM CFG.

© Copyright IBM Corp. 1997, 2017 3-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

The DBM configuration can be updated using Db2 command UPDATE DBM CFG.
For example, the following command could be used to set the instance configuration
option SVCENAME, which sets the tcpip port number for client connections:
db2 update dbm cfg using svcename 5023

© Copyright IBM Corp. 1997, 2017 3-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Instance configuration using Data Server Manager

The Db2 database manager instance © Copyright IBM Corporation 2017

Instance configuration using Data Server Manager

Tools like IBM Data Studio and IBM Data Server Manager support listing and setting
database manager configuration options. These tools can also be used to stop and
restart the Db2 instance from a client system and to implement instance changes that
require restarting the instance.

© Copyright IBM Corp. 1997, 2017 3-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Demonstration 1
Create a new Db2 instance

• Run the db2icrt command to create a new Db2 database manager

instance.
• Issue db2set and db2 update commands to configure the Db2
instance.
• Utilize the db2start and db2stop commands to start and stop a Db2
instance.
• Run db2pd commands to check the Db2 instance configuration and
status.

The Db2 database manager instance © Copyright IBM Corporation 2017

Demonstration 1: Create a new Db2 instance

1:

© Copyright IBM Corp. 1997, 2017 3-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Demonstration 1:
Create a new Db2 instance
Purpose:
This demonstration will create a new Db2 instance that will support the
database that you will create and manage in the following demonstrations.
You will use the Db2 command line processor to create the new instance,
configure some of the instance level options, and issue commands to start
and stop the instance.

Task 1. Logon to the Linux system and create the Db2

instance, inst23.
In this demonstration you will create a new Db2 instance with a name of inst23. The
Linux system used for the lab exercise has a predefined user named inst23.
On Linux and UNIX systems, Db2 requires an 'instance owner', a system user logon
with the same name as the Db2 instance. You will use the system logon user name
inst23 to manage the Db2 instance and database for the lab exercises.
A system root user is required to issue the commands that create or drop a new Db2
instance. The user name is root, with a password of dalvm3 on the Linux system used
for this training.
You will start by using another Linux system logon, inst00, to get onto the Linux
system, but you will switch to the root user in order to create the Db2 instance. Once
the instance is created, you will logout from inst00 and logon as the owner of the new
instance, inst23.
1. Logon to the Linux system using the user id inst00, with a password of
ibm2blue.
You will use the Linux Terminal session to enter Db2 commands.
2. Right-click the empty Linux desktop, and then select Open in Terminal.
After the Db2 software was installed on the Linux system, a Db2 instance
named inst00 was created. This instance was used to create a sample
database named SAMPLE.
The IBM Data Server Manager software can be configured to store data into a
Db2 database for monitoring over a period of time. A second database named
DSMDATA was created and configured to support the DSM tool.
You are currently logged onto the Linux system as the instance owner, inst00.
This course does not utilize the SAMPLE database, but you may want to try
some Db2 commands or access the sample tables during the course time.

© Copyright IBM Corp. 1997, 2017 3-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

3. Enter the following commands in the Linux terminal session:

• db2 get instance
• db2 list db directory
• db2start
The current instance should be inst00. The two databases - SAMPLE and
DSMDATA - should be listed.
You will now create a new Db2 Database Manager Instance named inst23,
using the db2icrt command to create the instance.
The Db2 instance creation and maintenance is performed using a system root
user authority on UNIX and Linux based Db2 servers. Use the UNIX su
command to switch user to root.
4. Enter the following commands in the Linux terminal session:
• su - root
You will be prompted for the root user password (dalvm3)
Look at the instances that have been created using the db2ilist command.
You will be using the Db2 software that was installed in the disk path
/opt/ibm/db2/V11.1.
5. Enter the following commands in the Linux terminal session:
• /opt/ibm/db2/V11.1/instance/db2ilist
The Db2 instance owner is inst23, the default password is ibm2blue. This user
was created with a primary group name of adm01.
A second user ID, fenced23, was created for use by fenced procedures, to
keep these applications from having the full authority of the Db2 instance owner.

© Copyright IBM Corp. 1997, 2017 3-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

6. Enter the following commands using the Linux terminal session:

• /opt/ibm/db2/V11.1/instance/db2icrt -u fenced23 inst23
The output from this command will look similar to the following:
DB2 installation is being initialized.

Total number of tasks to be performed: 4

Total estimated time for all tasks to be performed: 309 second(s)

Task #1 start
Description: Setting default global profile registry variables
Estimated time 1 second(s)
Task #1 end

Task #2 start
Description: Initializing instance list
Estimated time 5 second(s)
Task #2 end

Task #3 start
Description: Configuring DB2 instances
Estimated time 300 second(s)
Task #3 end

Task #4 start
Description: Updating global profile registry
Estimated time 3 second(s)
Task #4 end

The execution completed successfully.

For more information see the DB2 installation log at

"/tmp/[Link].14455".
DBI1446I The db2icrt command is running.

DBI1070I Program db2icrt completed successfully.

© Copyright IBM Corp. 1997, 2017 3-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Task 2. Configure the new Db2 instance, inst23, to allow tcpip

application connections and define a specific
diagnostic data path.
The new Db2 instance has a DBM configuration with default settings.
The new instance, inst23 was configured by default to enable tcpip application
connections. A tcpip port number was set for application connections to the instance
using the SVCENAME option in the DBM configuration.
The db2set command can be used to verify the setting for the Db2 registry variable
DB2COMM, 'tcpip'.
You can check the installed software level of Db2 using the db2level command.
You must log out from the Linux image to discontinue the use of the inst00 user logon.
1. Click on the down arrow at the end of the menu at the top of the Linux desktop
area and select inst00 > Log out. When prompted, select Log Out.
Now you will log on the system using the Db2 Instance owner name inst23.
2. Log in as inst23. Use the password ibm2blue.
You will use the Linux Terminal session to enter Db2 commands.
3. Right-click the empty Linux desktop and select Open in Terminal.
4. Enter the following commands in a Linux terminal session.
• db2 get instance
• db2level
• db2 get dbm cfg | grep SVCENAME
• db2set -all
You need to issue the db2start command to activate the new Db2 instance. The
db2pd command with the -edus option can be used to list the active processes
and threads for a Db2 instance.
5. Start the Db2 command line processor by entering the following in the Linux
terminal.
• db2start

© Copyright IBM Corp. 1997, 2017 3-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

6. Enter the following command in the Db2 command line processor.

• db2pd -edus
The output from this command will look similar to the following:

Database Member 0 -- Active -- Up 0 days [Link] -- Date 2016-06-23-

12.16.04.152075

List of all EDUs for database member 0

db2sysc PID: 1361

db2wdog PID: 1359
db2acd PID: 1379

EDU ID TID Kernel TID EDU Name

USR (s) SYS (s)
===========================================================================
===========================================================================
21 140004441450240 1377 db2spmlw 0
0.000000 0.000000
20 140004445644544 1376 db2spmrsy 0
0.000000 0.080000
19 140004449838848 1375 db2resync 0
0.000000 0.050000
18 140004454033152 1374 db2tcpcm 0
0.000000 0.000000
17 140004458227456 1373 db2tcpcm 0
0.000000 0.000000
16 140004462421760 1372 db2ipccm 0
0.000000 0.000000
15 140004466616064 1370 db2wlmtm 0
0.150000 0.050000
14 140004470810368 1366 db2wlmt 0
0.000000 0.000000
13 140004475004672 1365 db2licc 0
0.000000 0.000000
12 140004479198976 1364 db2thcln 0
0.000000 0.000000
11 140004483393280 1363 db2alarm 0
0.010000 0.000000
1 140004223346432 1362 db2sysc 0
0.050000 0.360000

© Copyright IBM Corp. 1997, 2017 3-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

You can set a specific disk location to store the diagnostic files generated by the
new instance using the DIAGPATH configuration option. You can limit the
amount of diagnostic data using a series of rotating diagnostic log files using the
DIAGSIZE configuration option. You will need to restart the Db2 instance to
implement these changes. The db2pd command can be used to verify the
configuration settings.
7. Enter the following commands.
• mkdir $HOME/diag
• db2 update dbm cfg using diagpath $HOME/diag diagsize 20
• db2stop force
• db2start
• db2pd -dbmcfg | more
The output from this command will look similar to the following:
Database Member 0 -- Active -- Up 0 days [Link] -- Date 2016-06-23-
12.18.21.886195

Database Manager Configuration Settings:

Description Memory Value Disk Value
RELEASE 0x1400 0x1400
INSTANCE_USAGE DEFAULT DEFAULT
CPUSPEED(millisec/instruction) 1.417033e-07 1.417033e-07
COMM_BANDWIDTH(MB/sec) 1.000000e+02 1.000000e+02
NUMDB 32 32
NUMDB_INT NEEDS RECOMPUTE(32) NEEDS RECOMPUTE(32)
FEDERATED NO NO
TP_MON_NAME
DFT_ACCOUNT_STR
JDK_PATH (memory) /home/inst23/sqllib/java/jdk64
JDK_PATH (disk) /home/inst23/sqllib/java/jdk64
DIAGLEVEL 3 3
NOTIFYLEVEL 3 3
DIAGPATH (memory) /home/inst23/diag/
DIAGPATH (disk) /home/inst23/diag/
DIAGPATH_RESOLVED (memory) /home/inst23/diag/
DIAGPATH_RESOLVED (disk) /home/inst23/diag/
ALT_DIAGPATH (memory)

© Copyright IBM Corp. 1997, 2017 3-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

ALT_DIAGPATH (disk)
ALT_DIAGPATH_RESOLVED (memory)
ALT_DIAGPATH_RESOLVED (disk)
DIAGSIZE (MB) 20 20
DFT_MON_BUFPOOL OFF OFF
DFT_MON_LOCK OFF OFF
DFT_MON_SORT OFF OFF
DFT_MON_STMT OFF OFF
DFT_MON_TABLE OFF OFF
DFT_MON_TIMESTAMP ON ON
DFT_MON_UOW OFF OFF
HEALTH_MON OFF OFF
SYSADM_GROUP (memory) ADM01
SYSADM_GROUP (disk) ADM01
SYSCTRL_GROUP (memory)
SYSCTRL_GROUP (disk)
SYSMAINT_GROUP (memory)
SYSMAINT_GROUP (disk)
SYSMON_GROUP (memory)
SYSMON_GROUP (disk)
CLNT_PW_PLUGIN
CLNT_KRB_PLUGIN
GROUP_PLUGIN
LOCAL_GSSPLUGIN
SRV_PLUGIN_MODE UNFENCED UNFENCED
SRVCON_GSSPLUGIN_LIST
SRVCON_PW_PLUGIN
SRVCON_AUTH
AUTHENTICATION SERVER SERVER
ALTERNATE_AUTH_ENC
CATALOG_NOAUTH NO NO
TRUST_ALLCLNTS YES YES
TRUST_CLNTAUTH CLIENT CLIENT
FED_NOAUTH NO NO
DFTDBPATH (memory) /home/inst23
DFTDBPATH (disk) /home/inst23

© Copyright IBM Corp. 1997, 2017 3-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

MON_HEAP_SZ (4KB) AUTOMATIC(90) AUTOMATIC(90)

JAVA_HEAP_SZ (4KB) 2048 2048
AUDIT_BUF_SZ (4KB) 0 0
INSTANCE_MEMORY (% or 4KB) AUTOMATIC(781782) AUTOMATIC(781782)
RSTRT_LIGHT_MEM (4KB) AUTOMATIC(10) AUTOMATIC(10)
RSTRT_LIGHT_MEM_INT (4KB) NEEDS RECOMPUTE(0) NEEDS RECOMPUTE(0)
AGENT_STACK_SZ 1024 1024
BACKBUFSZ (4KB) 1024 1024
RESTBUFSZ (4KB) 1024 1024
SHEAPTHRES (4KB) 0 0
DIR_CACHE YES YES
ASLHEAPSZ (4KB) 15 15
RQRIOBLK (bytes) 65535 65535
UTIL_IMPACT_LIM 10 10
AGENTPRI SYSTEM SYSTEM
NUM_POOLAGENTS AUTOMATIC(100) AUTOMATIC(100)
NUM_INITAGENTS 0 0
MAX_COORDAGENTS AUTOMATIC(200) AUTOMATIC(200)
MAX_CONNECTIONS AUTOMATIC(MAX_COORDAGENTS)
AUTOMATIC(MAX_COORDAGENTS)
KEEPFENCED YES YES
FENCED_POOL AUTOMATIC(MAX_COORDAGENTS)
AUTOMATIC(MAX_COORDAGENTS)
NUM_INITFENCED 0 0
INDEXREC RESTART RESTART
TM_DATABASE 1ST_CONN 1ST_CONN
RESYNC_INTERVAL (secs) 180 180
SPM_NAME ibmclas3 ibmclas3
SPM_LOG_FILE_SZ 256 256
SPM_MAX_RESYNC 20 20
SPM_LOG_PATH
SVCENAME 50004 50004
DISCOVER SEARCH SEARCH
DISCOVER_INST ENABLE ENABLE
SSL_SVR_KEYDB (memory)
SSL_SVR_KEYDB (disk)
SSL_SVR_STASH (memory)

© Copyright IBM Corp. 1997, 2017 3-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

SSL_SVR_STASH (disk)
SSL_SVR_LABEL (memory)
SSL_SVR_LABEL (disk)
SSL_SVCENAME
SSL_CIPHERSPECS (memory)
SSL_CIPHERSPECS (disk)
SSL_VERSIONS (memory)
SSL_VERSIONS (disk)
SSL_CLNT_KEYDB (memory)
SSL_CLNT_KEYDB (disk)
SSL_CLNT_STASH (memory)
SSL_CLNT_STASH (disk)
MAX_QUERYDEGREE ANY ANY
INTRA_PARALLEL NO NO
FCM_NUM_BUFFERS (4KB) AUTOMATIC(4096) AUTOMATIC(4096)
FCM_NUM_CHANNELS AUTOMATIC(2048) AUTOMATIC(2048)
FCM_PARALLELISM AUTOMATIC(1) AUTOMATIC(1)
FCM_PARALLELISM_INT RECOMPUTE(1) 1
FCM_BUFFER_SIZE 32768 32768
FCM_BUFFER_SIZE_INT RECOMPUTE(32768) 32768
CONN_ELAPSE (secs) 10 10
MAX_CONNRETRIES 5 5
MAX_TIME_DIFF (mins) 60 60
START_STOP_TIME (mins) 10 10
WLM_DISPATCHER NO NO
WLM_DISP_CONCUR COMPUTED(8) COMPUTED
WLM_DISP_CPU_SHARES NO NO
WLM_DISP_MIN_UTIL 5 5
KCFD_CFG_SIGNATURE 24 27
COMM_EXIT_LIST (memory)
COMM_EXIT_LIST (disk)
KEYSTORE_TYPE NONE NONE
KEYSTORE_LOCATION (memory)
KEYSTORE_LOCATION (disk)

© Copyright IBM Corp. 1997, 2017 3-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

The database manager configuration contains settings and status information

for the Db2 instance. The Db2 command GET DBM CFG can be used to list
this information. Check the current default database path, DFTDBPATH setting
to see the default database path that would be used if a new database is
created.
8. Issue the following command.
• db2 get dbm cfg | grep PATH
The output from this command will look similar to the following:
Java Development Kit installation path (JDK_PATH) =
/home/inst23/sqllib/java/jdk64
Diagnostic data directory path (DIAGPATH) = /home/inst23/diag/
Current member resolved DIAGPATH = /home/inst23/diag/
Alternate diagnostic data directory path (ALT_DIAGPATH) =
Current member resolved ALT_DIAGPATH =
Default database path (DFTDBPATH) = /home/inst23
SPM log path (SPM_LOG_PATH) =
Now that you have created and configured the new Db2 instance, inst23, you
will use that instance to create a new database.
Results:
You created a new Db2 instance that will support the database that you will
create and manage in the following demonstrations. You used the Db2
command line processor to create the new instance, configured some of the
instance level options and issued commands to start and stop the instance.

© Copyright IBM Corp. 1997, 2017 3-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 3 Th e D b 2 d a t a b a s e m a n a g e r i n s t a n c e

Unit summary
• Specify the key features of an instance
• Create and drop a Db2 instance
• Use db2start and db2stop commands to manage a Db2 instance
• Display and set Db2 registry variables
• Describe and modify the database manager configuration

The Db2 database manager instance © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 3-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Creating databases and data placement

Creating databases and

data placement

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 4 Creating databases and data placement

© Copyright IBM Corp. 1997, 2017 4-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Unit objectives
• Plan the initial storage allocations for a database including catalog
tables and log files
• Create a new database using Db2 native encryption
• Explore the System Catalog tables and views
• Check and update Database configuration parameter settings
• Compare DMS and Automatic Storage management for table spaces
• Describe how to setup and manage a Db2 database with Automatic
Storage enabled
• Define Storage Groups to manage databases with different classes of
storage available
• Differentiate between table spaces, containers, extents, and pages
• Create and alter table spaces
• Use Db2 commands and SQL statements to display current table
space statistics and status information

Creating databases and data placement © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 4-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Create database overview

• Databases are created within a Database Manager instance
• Table spaces are a logical layer created within a database
• Tables are created within table spaces

Database Manager Instance

database 1 database 2

Tablespace A Tablespace B Tablespace A

Table 1 Table 2 Table 3 Table 4 Table 1 Table 2

Creating databases and data placement © Copyright IBM Corporation 2017

Create database overview

Each Db2 database manager instance can have one or more databases defined in it.
Each database can have three or more table spaces associated with it. The table
spaces are a logical level between the database and the tables stored in that database.
Table spaces are created within a database, and tables are created within table
spaces.
As discussed previously, one or more databases can reside in an instance. Db2 creates
three default table spaces in a database when it is created, and you can create
additional table spaces for the storage of your table, index, and long objects.

© Copyright IBM Corp. 1997, 2017 4-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Table space, container, extent, page

• Database objects like tables are assigned to table spaces
• When a new tablespace is created:
 a fixed page size is defined
 the Extent size is defined as a fixed number of pages
• Extents are allocated from Tablespace
containers
• Each container is associated
Container
with one tablespace
• Database objects are allocated
extents of pages Extent

Data
Page

Creating databases and data placement © Copyright IBM Corporation 2017

Table space, container, extent, page

With Db2 a table space is defined to have one or more containers.
An extent is a block of storage within a table space container. It represents the
number of pages of data that will be written to a container before writing to the next
container. When you create a table space, you can choose the extent size based on
your requirements for performance and storage management.
When selecting an extent size, consider the size and type of tables in the table space.
Disk space allocations in table spaces are made one extent at a time. As a table is
populated with data new extents are allocated as needed. The initial allocation of
extents for table space container storage occurs when the table space is created.
Extents are allocated to database objects assigned to the table space.

© Copyright IBM Corp. 1997, 2017 4-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Writing to containers
• DFT_EXTENT_SZ defined at database level
• EXTENTSIZE defined at table space level (2 – 256 pages)
• Data extents written in round-robin manner

Container 0 Container 1

0 2

Extent 1 3

Tablespace TBS

Creating databases and data placement © Copyright IBM Corporation 2017

Writing to containers
Db2 uses extents and multiple containers to store and retrieve data.
An extent is an allocation of contiguous space within a container of a table space.
Extents are allocated to a single database object and consist of multiple pages. The
default extent size is 32 pages, but a different value can be specified when creating a
table space.
Data for an object is stored on a container by extents. When data for an object is
written, the database system stripes the data across all the containers in the table
space based on the extent size.
DFT_EXTENT_SZ is a database configuration parameter. If you do not specify an
extent size when the table space is created, DFT_EXTENT_SZ will be used. The
default size for DFT_EXTENT_SZ is 32 pages. If you do not alter this value or explicitly
indicate an extent size when you create a table space, all your table spaces within the
database will have this default value. The range of values for DFT_EXTENT_SZ is
between two and 256 pages.
You can specify extent size at the table space level. This can be done at table space
creation with the parameter EXTENTSIZE. Carefully determine the correct size, as
once it is set for a table space, it cannot be altered. This size can have an impact on
space utilization and performance.

© Copyright IBM Corp. 1997, 2017 4-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The database manager will try to evenly distribute the table among containers. In doing
so, the database manager writes an extent of pages to each container before writing to
the next container. Once the database manager has written an extent to all the
containers allocated to a table space, it will write the next extent to the first container
written to in that table space. This round-robin process of writing to the containers is
designed to balance the workload across the containers of the table space.
Db2 utilities like BACKUP and LOAD are designed to perform I/O at the extent level, so
larger extents would require fewer I/O operations.
Db2 can use the extent as an efficient set of page data for reading groups of pages
when scanning a table or index. Db2 can pre-fetch extents of pages during scans to
reduce disk wait times.

© Copyright IBM Corp. 1997, 2017 4-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Database storage requirements

• Database Path:
 Database Control Files for each database
− Database Configuration file, Recovery History, Log Control files, Tablespace
Control file, Bufferpool Control file and others
 Initial location for database log files; default location is dftdbpath in DBM CFG, in
local file system
• Automatic Storage paths:
 Allow groups of tablespaces to be managed rather than managing each
independently
 If Automatic storage is enabled at least one path will be defined
 Initial Storage Paths can be defined when a database is created

• Default System table spaces:

 Use Automatic Storage management by default, if enabled, but can be defined to
use supported tablespace types
 SYSCATSPACE
− Contains Db2 System Catalog Tables
 TEMPSPACE1
− Provides storage for system temporary table
− Supports sorting for query results and creation of indexes
 USERSPACE1
− Provides an initial allocation for user defined database objects
− Use of this storage is granted to PUBLIC

Creating databases and data placement © Copyright IBM Corporation 2017

Database storage requirements

When a database is created several types of storage are required to support the
new database.
• Database Path
• A set of Database Control Files are needed for each database. The control files
include the Database Configuration file, the Recovery History, a set of Log
Control files, a Tablespace Control files, a Buffer pool Control files and others.
• A set of Database log files are needed to support each database
• The default location for the database path is defined by the dftdbpath
configuration option in the DBM CFG.
• The database path needs to be a local file system.
• Automatic Storage paths can be defined when a database is created to enable
automatic storage management for table spaces. Prior to Db2 10, a single set of
storage paths could be assigned to one database. Beginning with Db2 10.1,
multiple storage paths can be assigned to storage groups. This allows table
space storage to be managed at a level higher than the individual table. The initial
Automatic Storage Paths are defined when a database is created become the
initial default storage group for the database.

© Copyright IBM Corp. 1997, 2017 4-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• Each database is created with three default System Table spaces. If automatic
storage is enabled, Db2 will use Automatic Storage management, but these can
be defined to use any supported type of table space management. The three
table spaces are:
• SYSCATSPACE: Db2 catalog tables
• TEMPSPACE1: System Temporary tables, provide work space for sorting and
utility processing
• USERSPACE1: Initial table space for defining user tables and indexes
If you do not specify a different path for the database, it will use the dftdbpath DBM
configuration parameter, which defaults to the home directory of the instance owner on
Linux and UNIX systems, but to the drive where Db2 is installed on Windows.

© Copyright IBM Corp. 1997, 2017 4-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Storage management alternatives (1 of 2)

• Automatic Storage Managed:
 Administration has automatic definition of containers with standard names
 Disk space assigned from disk paths for a storage group
 Tracking of available space by storage group rather than each tablespace
 Multiple containers created using all available paths for the storage group
 Automatic Storage is enabled by default when a new database is created, or
added to an existing database
 Storage paths can be added or removed using ALTER STOGROUP
 Uses standard DMS and SMS under the covers:
− DMS used for REGULAR and LARGE table spaces
− SMS used for SYSTEM and USER TEMPORARY table spaces
 Table space allocation controlled by CREATE/ALTER options:
− INITIALSIZE:
Defaults to 32 MB
− AUTORESIZE: Can be set to YES or NO
− INCREASESIZE: Can be set to amount or percent increase
− MAXSIZE: Can define growth limits

Creating databases and data placement © Copyright IBM Corporation 2017

Storage management alternatives

The administration of table spaces using Automatic Storage is very easy. The CREATE
TABLESPACE syntax does not require the names of containers or the number of
containers to be defined. For Automatic Storage table spaces, the disk space is
assigned from a storage group. If no storage group is specified, a default storage group
will be used.
This allows the DBA to monitor available space at the storage group level instead of
each individual table space. As long as there is space available in one of the defined
Automatic Storage paths, a table space can be automatically extended by Db2. Smaller
databases may only want a single storage group for the database.
When a table space is created, Db2 can create multiple containers, using all of the
available storage paths, which helps performance for table and index scans.
Additional storage path(s) can be added using an ALTER STOGROUP statement, to
support growth over time.
Automatic Storage management actually uses DMS and SMS table spaces under the
covers. A DMS table space is used for REGULAR and LARGE table spaces, while
SMS is used for SYSTEM and USER TEMPORARY table spaces.

© Copyright IBM Corp. 1997, 2017 4-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The allocation of space for Automatic Storage table spaces can be controlled using the
options of CREATE and ALTER TABLESPACE, including:
• INITIALSIZE - Which defaults to 32 MB, if not specified.
• AUTORESIZE - Can be set to YES or NO, with YES being the default for Regular
and Large table spaces.
• INCREASESIZE - Can be set to a specific amount or percentage increase.
• MAXSIZE - Can be used to define a limit on growth for the table space.

© Copyright IBM Corp. 1997, 2017 4-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Storage management alternatives (2 of 2)

• DMS - Database Managed:
 Manually assigned space can be adjusted for the tablespace after it has
been created by adding or enlarging containers as well as decreasing or
deleting containers
 AUTORESIZE can be defined to handle increased demand for space
− Db2 can only automatically add space to the last stripe set
 Each table's storage objects can be split across multiple tablespaces
 Can be converted to Automatic Storage management
 Maximum size (8 TB 4K page, 64 TB 32K page) per tablespace (per
Partition) using a LARGE tablespace
• SMS - System Managed:
 Efficient for handling small temporary tables
 Temporary table spaces should be defined using automatic storage for
more flexible management
 Use of SMS for non-temporary tables was deprecated with 10.1

Creating databases and data placement © Copyright IBM Corporation 2017

For DMS management, the characteristics are:

• The disk space can be adjusted for the table space after it has been created by
adding or enlarging containers as well as decreasing or deleting containers, using
the ALTER TABLESPACE command.
• The AUTORESIZE option can be enabled for DMS table spaces to dynamically
increase the allocated disk space to handle greater than expected application
needs.
• A table's objects can be split across multiple table spaces. The index and large
object components of a table can be directed to other table spaces when the
table is created.
• Db2 has more direct control over storage allocation. Space can be reserved for
growth of critical application tables and indexes.
• Maximum size (8 TB 4K page, 64 TB 32K page) per Table space (per Partition)
using a Large DMS table space, which uses 6-byte Row IDs. Regular DMS table
spaces use 4-byte Row IDs, which can address up to 16 million pages. The 6-
byte Row IDs used for a Large table space provides a 4-byte page address and
two-bytes are used for the row offset within a data page. Indexes based on tables
in Large tablespaces will require 6 bytes per index entry to address the data rows.

© Copyright IBM Corp. 1997, 2017 4-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

System-managed storage
In an SMS (System-Managed Storage) table space, the operating system's file system
manager allocates and manages the space where the table is stored. The storage
model typically consists of many files, representing table objects, stored in the file
system space. The user decides on the location of the files, Db2 Database for Linux,
UNIX, and Windows controls their names, and the file system is responsible for
managing them. By controlling the amount of data written to each file, the database
manager distributes the data evenly across the table space containers. Each table has
at least one SMS physical file associated with it. When a table is dropped, the
associated files are deleted, so the disk space is freed. SMS table spaces do not have
a defined size limit.
Note that the SMS table space type has been deprecated in Version 10.1 for user-
defined permanent table spaces and might be removed in a future release. The SMS
table space type is not deprecated for catalog and temporary table spaces.
Since system and user temporary tablespaces can be managed with automatic storage
management, temporary tablespaces should be defined as automatic storage managed
rather than standard SMS managed.

© Copyright IBM Corp. 1997, 2017 4-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

CREATE DATABASE syntax

>>-CREATE--+-DATABASE-+----------------------------------------->
'-DB-------' .-PAGESIZE--4096-----------.
>--+--------------------------+--+------------------+----------->
>----database-name--+-----------------------------+-------------> '-PAGESIZE--integer--+---+-' '-NUMSEGS--numsegs-'
+-AT DBPARTITIONNUM-----------+ '-K-'
'-| Create Database options |-'
>--+-------------------------------+--+-------------+----------->
>--+-----------------------------------------------------------------+->< '-DFT_EXTENT_SZ--dft_extentsize-' '-RESTRICTIVE-'
'-ENCRYPT--+------------------------+--+------------------------+-'
'-| Encryption Options |-' '-| Master Key Options |-' >--+-----------------------------------------------------------------+-->
'-ENCRYPT--+------------------------+--+------------------------+-'
Create Database options '-| Encryption Options |-' '-| Master Key Options |-'

.-AUTOMATIC STORAGE--YES-. >--+---------------------------------------+-------------------->

|--+------------------------+-----------------------------------> '-CATALOG TABLESPACE--| tblspace-defn |-'
'-AUTOMATIC STORAGE--NO--'
>--+------------------------------------+----------------------->
>--+---------------------------------------------+--------------> '-USER TABLESPACE--| tblspace-defn |-'
| .-,---------. |
| V | | >--+-----------------------------------------+------------------>
'-ON----+-path--+-+--+----------------------+-' '-TEMPORARY TABLESPACE--| tblspace-defn |-'
'-drive-' '-DBPATH ON--+-path--+-'
'-drive-' >--+------------------------+----------------------------------->
'-WITH--"comment-string"-'
>--+-----------------------+------------------------------------>
'-ALIAS--database-alias-' >--+---------------------------------------------------------------------------------+-->
| .-DB ONLY----. |
>--+----------------------------------------------+-------------> '-AUTOCONFIGURE--+---------------------------------------+--APPLY--+-DB AND DBM-+-'
'-USING CODESET--codeset--TERRITORY--territory-' | .----------------------------. | '-NONE-------'
| V ||
>--+-----------------------------------------------+------------> '-USING----input-keyword--param-value-+-'
| .-SYSTEM---------------------. |
'-COLLATE USING--+-COMPATIBILITY--------------+-' >--+---------------+--------------------------------------------|
+-IDENTITY-------------------+ '-report-clause-'
+-IDENTITY_16BIT-------------+
+-language-aware-collation---+
+-locale-sensitive-collation-+
'-NLSCHAR--------------------'

Creating databases and data placement © Copyright IBM Corporation 2017

CREATE DATABASE syntax

The CREATE DATABASE command initializes a new database with an optional user-
defined collating sequence, creates the three initial table spaces, creates the system
tables, and allocates the recovery log file. When you initialize a new database, the
AUTOCONFIGURE command is issued by default.
Note: When the instance and database directories are created by the Db2 database
manager, the permissions are accurate and should not be changed.
When the CREATE DATABASE command is issued, the Configuration Advisor also
runs automatically. This means that the database configuration parameters are
automatically tuned for you according to your system resources. In addition, Automated
Runstats is enabled. To disable the Configuration Advisor from running at database
creation, refer to the DB2_ENABLE_AUTOCONFIG_DEFAULT registry variable. To
disable Automated Runstats, refer to the auto_runstats database configuration
parameter.
Adaptive Self Tuning Memory is also enabled by default for single partition databases.
To disable Adaptive Self Tuning Memory by default, refer to the self_tuning_mem
database configuration parameter. For multi-partition databases, Adaptive Self Tuning
Memory is disabled by default.

© Copyright IBM Corp. 1997, 2017 4-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

If no code set is specified on the CREATE DATABASE command, then the collations
allowed are: SYSTEM, IDENTITY_16BIT, language-aware-collation, and locale-
sensistive-collation (SQLCODE -1083). The default code set for a database is UTF-8. If
a particular code set and territory is needed for a database, the required code set and
territory should be specified in the CREATE DATABASE command.
Example 1: Creating a database on a UNIX or Linux operating system:
To create a database named TESTDB1 on path /DPATH1 using /DATA1 and /DATA2
as the storage paths defined to the default storage group IBMSTOGROUP, use the
following command:
CREATE DATABASE TESTDB1 ON '/DATA1','/DATA2' DBPATH ON
'/DPATH1'
Example 2: Creating a database on a Windows operating system, specifying
both storage and database paths:
To create a database named TESTDB2 on drive D:, with storage on E:\DATA, use the
following command:
CREATE DATABASE TESTDB2 ON 'E:\DATA' DBPATH ON 'D:'
In this example, E:\DATA is used as the storage path defined to the default storage
group IBMSTOGROUP.

© Copyright IBM Corp. 1997, 2017 4-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Completed by Db2 during database creation (1 of 2)

1. Creates database in the specified subdirectory (database path)
2. If Automatic storage is enabled a default storage group named
IBMSTOGROUP is created
3. Creates SYSCATSPACE, TEMPSPACE1, and USERSPACE1 table
spaces
4. Creates the system catalog tables and recovery logs
5. Catalogs database in local database directory and system database
directory
6. Stores the specified code set, territory, and collating sequence
7. Creates the schemas SYSCAT, SYSFUN, SYSIBM, and SYSSTAT
8. Binds database manager bind files to the database ([Link])
− Db2 CLI packages are automatically bound to databases when the databases are
created or migrated. If a user has intentionally dropped a package, then you must
rebind [Link].

Creating databases and data placement © Copyright IBM Corporation 2017

Completed by Db2 during database creation

When you create a database, the database manager:
1. Creates the database in the specified path (or default path)
2. If automatic storage is enabled, the defined storage paths will be assign to a
storage group named IBMSTOGROUP.
3. Creates SYSCATSPACE, TEMPSPACE1, and USERSPACE1 table spaces.
4. Creates the system catalog tables and recovery log.
5. Catalogs the database in the following database directories:
• Server's local database directory on the path indicated by path or, if the
path is not specified, the default database path defined in the database
manager system configuration file. A local database directory resides on
each operating system file system (Linux/UNIX) or drive (Windows) that
contains a database.
• Server’s system database directory for the attached instance. The resulting
directory entry will contain the database name and a database alias. If the
command was issued from a remote client, the client's system database
directory is also updated with the database name and alias.
• Creates a system or a local database directory if neither exists. If specified,
the comment and code set values are placed in both directories.

© Copyright IBM Corp. 1997, 2017 4-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

6. Stores the specified codeset, territory, and collating sequence. A flag is set in
the database configuration file if the collating sequence consists of unique
weights, or if it is the identity sequence.
7. Creates SYSCAT, SYSFUN, SYSIBM, and SYSSTAT schemata with SYSIBM
as the owner.
8. Binds previously defined database manager bind files to the database (these
are listed in the bind file [Link]).
Db2 CLI packages are automatically bound to databases when the databases
are created or migrated. If a user has intentionally dropped a package, then you
must rebind [Link].

© Copyright IBM Corp. 1997, 2017 4-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Completed by Db2 during database creation (2 of 2)

9. Grants the following privileges:
− ACCESSCTRL , DATAACCESS , DBADM and SECADM privileges to database
creator
− SELECT privilege on system catalog tables and views to PUBLIC
− UPDATE access to the SYSSTAT catalog views
− BIND and EXECUTE privilege to PUBLIC for each successfully bound utility
− CREATETAB, BINDADD, IMPLICIT_SCHEMA, and CONNECT authorities to
PUBLIC
− USE privilege on USERSPACE1 table space to PUBLIC
− Usage of the WLM workload for user class SYSDEFAULTUSERCLASS to PUBLIC
• When the RESTRICTIVE option is used, no privileges are
automatically granted to PUBLIC.

Creating databases and data placement © Copyright IBM Corporation 2017

When you create a database, default database level authorities and default object level
privileges are granted to you within that database.
9. The authorities and privileges that you are granted are listed according to the
system catalog views where they are recorded:
[Link]
The database creator is granted the following authorities:
• ACCESSCTRL
• DATAACCESS
• DBADM
• SECADM
In a non-restrictive database, the special group PUBLIC is granted the following
authorities:
• CREATETAB
• BINDADD
• CONNECT
• IMPLICIT_SCHEMA

© Copyright IBM Corp. 1997, 2017 4-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

[Link]
In a non-restrictive database, the special group PUBLIC is granted the following
privileges:
• SELECT on all SYSCAT and SYSIBM tables
• SELECT and UPDATE on all SYSSTAT tables
• SELECT on the following views in schema SYSIBMADM:
• ALL_*
• USER_*
• ROLE_*
• SESSION_*
• DICTIONARY
• TAB
[Link]
In a non-restrictive database, the special group PUBLIC is granted the following
privileges:
• EXECUTE with GRANT on all procedures in schema SQLJ
• EXECUTE with GRANT on all functions and procedures in schema SYSFUN
• EXECUTE with GRANT on all functions and procedures in schema SYSPROC
(except audit routines)
• EXECUTE on all table functions in schema SYSIBM
• EXECUTE on all other procedures in schema SYSIBM
[Link]
In a non-restrictive database, the special group PUBLIC is granted the following
privileges:
• EXECUTE on the following modules in schema SYSIBMADM:
• DBMS_DDL
• DBMS_JOB
• DBMS_LOB
• DBMS_OUTPUT
• DBMS_SQL

© Copyright IBM Corp. 1997, 2017 4-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• DBMS_STANDARD
• DBMS_UTILITY
[Link]
The database creator is granted the following privileges:
• CONTROL on all packages created in the NULLID schema
• BIND with GRANT on all packages created in the NULLID schema
• EXECUTE with GRANT on all packages created in the NULLID schema
In a non-restrictive database, the special group PUBLIC is granted the following
privileges:
• BIND on all packages created in the NULLID schema
• EXECUTE on all packages created in the NULLID schema
[Link]
In a non-restrictive database, the special group PUBLIC is granted the following
privileges:
• CREATEIN on schema SQLJ
• CREATEIN on schema NULLID
[Link]
In a non-restrictive database, the special group PUBLIC is granted the USE privilege on
table space USERSPACE1.
[Link]
In a non-restrictive database, the special group PUBLIC is granted the USAGE privilege
on SYSDEFAULTUSERWORKLOAD.
[Link]
In a non-restrictive database, the special group PUBLIC is granted the READ privilege
on schema global variables in the SYSIBM schema, except for the following variables:
• SYSIBM.CLIENT_ORIGUSERID
• SYSIBM.CLIENT_USRSECTOKEN

© Copyright IBM Corp. 1997, 2017 4-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

CREATE DATABASE examples

create database sales1 on /dbsales1
 Database Path: /dbsales1
 Automatic Storage Path: /dbsales1
create database sales2 automatic storage no on /dbsales2
 Database Path: /dbsales2
 Automatic Storage not enabled
create database sales3 on /dbauto3 dbpath on /dbsales3
 Database Path: /dbsales3
 Automatic Storage Path: /dbauto3
create database sales4 automatic storage yes
on /dbauto41,/dbauto42,/dbauto43
dbpath on /dbsales4
 Database Path: /dbsales4
 Automatic Storage Paths: /dbauto41, /dbauto42 and /dbauto43

Creating databases and data placement © Copyright IBM Corporation 2017

CREATE DATABASE examples

The slide shows several examples of the CREATE DATABASE commands, with or
without Automatic Storage enabled.
• create database sales1 on /dbsales1
The Database Path for this database would be /dbsales1. The database would
have Automatic Storage enabled with one Automatic Storage path, /dbsales1
being the same as the database path.
• create database sales2 automatic storage no on /dbsales2
The Database Path for this database would be /dbsales2. The database would
have Automatic Storage disabled. SMS table space management would be used
for the three system table spaces and the containers would use the database
path.
• create database sales3 on /dbauto3 dbpath on /dbsales3
The Database Path for this database would be /dbsales3. The database would
have Automatic Storage enabled with one Automatic Storage path, /dbauto3.

© Copyright IBM Corp. 1997, 2017 4-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• create database sales4 automatic storage yes on

/dbauto41,/dbauto42,/dbauto43 dbpath on /dbsales4
The Database Path for this database would be /dbsales4. The database would
have Automatic Storage enabled with three Automatic Storage paths, /dbauto41,
/dbauto42 and /dbauto43.

© Copyright IBM Corp. 1997, 2017 4-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Db2 Native Encryption

Encryption can be requested using the option on the CREATE DATABASE command
CREATE DATABASE mydb ENCRYPT;

• Provides data encryption at rest to assist businesses with security

and regulatory requirements
• Simple to deploy in cloud, software, or appliance
• Encrypts online data and backups
 Backups can also be compressed
• Transparent
• Built-in secure and transparent key management
• Compliant
 NIST SP 800-131 compliant cryptographic algorithms
 Uses FIPS 140-2 certified encryption
• Runs wherever Db2 runs!
 Exploits available hardware acceleration
Creating databases and data placement © Copyright IBM Corporation 2017

Db2 Native Encryption

Db2 Native Encryption encrypts your Db2 database, requires no hardware, software,
application, or schema changes, and provides transparent and secure key
management.
Encryption is the process of transforming data into an unintelligible form in such a way
that the original data either cannot be obtained or can be obtained only by using a
decryption process. It is an effective way of protecting sensitive information that is
stored on media or transmitted through untrusted communication channels. Encryption
is mandatory for compliance with many government regulations and industry standards.
In an encryption scheme, the data requiring protection is transformed into an
unreadable form by applying a cryptographic algorithm and an encryption key. A
cryptographic algorithm is a mathematical function that is used in encryption and
decryption processes. An encryption key is a sequence that controls the operation of a
cryptographic algorithm and enables the reliable encryption and decryption of data.

© Copyright IBM Corp. 1997, 2017 4-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Some data encryption solutions for protecting data at rest are suitable in cases of
physical theft of disk devices, and some can protect against privileged user abuse. With
native database encryption, the database system itself encrypts the data before it calls
the underlying file system to write that data to disk. This means that not only your
current data is protected, but also data in new table space containers or table spaces
that you might add in the future. Native database encryption is suitable for protecting
data in cases of either physical theft of disk devices or privileged user abuse.
A local or external key manager is typically used to manage the keys. A data encryption
key is the encryption key with which actual user data is encrypted. A master key is a
"key encrypting key": It is used to protect the data encryption key. Although the data
encryption key is stored and managed by the database, the master key is stored and
managed outside of the database.
The Db2 Version 10.5 Fix Pack 5 added native database encryption to the Db2
database server. This enhancement is easy to implement and provides secure local key
management that is based on Public Key Cryptography Standard #12 (PKCS#12). Db2
native encryption enables you to meet compliance requirements in a cost effective
manner.
Db2 Version 11.1 extends native encryption from the local key store to the enterprise
level, with the use of Key Management Interoperability Protocol (KMIP) 1.1, the industry
standard for key management. Support for external key managers is available with this
Db2 product, allowing users to manage key stores using external (and approved)
managers. Also supported is Hardware Security Module (HSM) through Enterprise Key
Management has been integrated with Db2 Version 11.1 to provide users with various
HSM options.

© Copyright IBM Corp. 1997, 2017 4-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Encryption Key Wrapping

• The process of encrypting one key with another key
• The key encrypting key is typically referred to as a Master Key (MK)
• The MK is typically stored separately from the data system
• The top drivers for this 2- tier encryption approach are:
 Security: Compromise of the data system does not mean compromise of
the data as the MK is stored outside the data system
 Performance: Complying with key rotation requirements does not mean
re-encrypting the actual data; only the Data Encryption Key (DEK) is re-
encrypted with a new MK
• Db2 Implements the industry standard 2-tier model
• Actual data is encrypted with a DEK
• DEK is encrypted with a MK

Creating databases and data placement © Copyright IBM Corporation 2017

Encryption Key Wrapping

Key Management is secure and transparent.
• Db2 Native Encryption uses a standard two-tier model for key management. The
Data Encryption Key (DEK) constitutes the first tier. The DEK is the actual key
used to perform data encryption. The DEK is then encrypted with a second key
and stored within the database (or backup image). The second key is called the
Master Key (MK) and constitutes the second tier. In the industry, this model is
referred to as envelope encryption. The MK is stored outside the database in a
Public-Key Cryptography Standards (PKCS#12) compliant keystore
Db2 Native Encryption encrypts both your online data and your backup images.
• To encrypt your online data, you need to create your database with the new
ENCRYPT option of the CREATE DATABASE command. By default, your
database encryption uses Advanced Encryption Standard (AES) in Cipher-Block
Chaining (CBC) mode with a 256 bits key. But other encryption algorithms and
key sizes are available. Every database has its own unique Data Encryption Key
(DEK). The encryption for backup images is independent of online database
encryption

© Copyright IBM Corp. 1997, 2017 4-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Db2 Native Encryption employs certified and compliant cryptography, and exploits
hardware acceleration for cryptographic operations.
• Certification and compliance are critical when it comes to encryption solutions.
Db2 Native Encryption uses FIPS 140-2 certified cryptographic modules.
Additionally, only cryptographic algorithms that are compliant with NIST SP 800 -
131 are employed by Db2 Native Encryption. Similarly, performance is critical for
database workloads. Db2 Native Encryption is capable of exploiting recent
innovations in processor technology such as the Intel AES-NI. This exploitation is
automatically detected and transparently exploited by Db2 Native Encryption

© Copyright IBM Corp. 1997, 2017 4-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Db2 Native Encryption with a local key store

• Initial support for Db2 Native
Encryption provided in Db2
10.5 fixpack 5
• IBM Global Security Kit
software is installed with
Db2 LUW
• A local keystore is created
to support a Db2 Instance
using the IBM GSK
• Public Key Cryptography
Standard #12 (PKCS#12)
• The keystore_type and
keystore_location
database manager
configuration parameters
are used to specify the type
and location of the keystore.

Creating databases and data placement © Copyright IBM Corporation 2017

Db2 Native Encryption with a local key store

Db2 Version 10.5 Fix Pack 5 added native database encryption to the Db2 database
server. This enhancement is easy to implement and provides secure local key
management that is based on Public Key Cryptography Standard #12 (PKCS#12). Db2
native encryption enables you to meet compliance requirements in a cost effective
manner.
A new master key is automatically added when you create an encrypted database
without specifying the MASTER KEY LABEL option on the CREATE DATABASE
command. The database manager uses this master key by default, but you can
optionally add a different master key.
Encrypted master keys are stored in a PKCS#12-compliant keystore, which is a storage
object for encryption keys that exists at the operating system level. In partitioned
database environments or Db2 pureScale environments, the keystore location must be
accessible to all members. There is at most one keystore per Db2 instance. The
keystore_type and keystore_location database manager configuration parameters are
used to specify the type and location of the keystore.

© Copyright IBM Corp. 1997, 2017 4-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The keystore password (in obfuscated form) can be stashed to a file that automatically
provides the password when required. The stash file can be read only by the file owner.
Not stashing the password enhances security if the instance owner account becomes
compromised. However, this additional security must be weighed against any
requirements that the Db2 instance can start without human intervention. If the
password is not stashed, you cannot access an encrypted database until you provide
the keystore password.
Implementing Db2 native encryption includes the following steps:
1. Create a keystore.
2. Add a database master key to the keystore
(or have the CREATE DATABASE command automatically create a master key).
3. Configure the Db2 instance with the new keystore.
4. If the password is not stashed, open the keystore by using the db2start command
with the OPEN KEYSTORE option.
5. Specify encryption parameters on the CREATE DATABASE command.
6. Specify encryption parameters on the BACKUP DATABASE and RESTORE
DATABASE or RECOVER DATABASE commands. For both encrypted and non-
encrypted databases, database backup images are automatically encrypted if the
encrlib and encropts database configuration parameters are set to a non-null
value. For encrypted databases, these parameters are set to the values that are
specified when the databases are created.
7. Rotate the database master key by calling the ADMIN_ROTATE_MASTER_KEY
procedure. Like user passwords, encryption keys should be changed regularly to
minimize risk if a key is compromised.

© Copyright IBM Corp. 1997, 2017 4-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Encryption and enterprise key management

• Db2 11.1 adds support for KMIP 1.1 centralized key
managers
 Validated on IBM’s Security Key Lifecycle Manager (ISKLM)

PKCS 12 Db2 Master Key DB2 10.5 fp5

KMIP 1.1 Centralized
Db2 Native Key Manager
Db2 Master Key
Db2 11.1
Encryption
Hardware Db2 V11.1.1.1
Security Module

The Key Management Interoperability Protocol (KMIP) is a communication

protocol that defines message formats for the manipulation of cryptographic keys
on a key management server.

Creating databases and data placement © Copyright IBM Corporation 2017

Encryption and Enterprise Key Management

Db2 Version 11.1 extends native encryption from the local key store to the enterprise
level, with the use of Key Management Interoperability Protocol (KMIP) 1.1, the industry
standard for key management.
The IBM software product, IBM Security Key Lifecycle Manager (ISKLM) can be used
with Db2 11.1 as an external key manager.
Support for external key managers is available with this Db2 product, allowing users to
manage key stores using external (and approved) managers. Also supported is
Hardware Security Module (HSM), although Enterprise Key Management has been
integrated with Db2 Version 11.1 to provide users with various HSM options.
A PKCS #11 keystore that is located on a system other than the Db2 server.

© Copyright IBM Corp. 1997, 2017 4-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The primary benefit of a PKCS #11 keystore is the protection it provides to encryption
keys. This protection is accomplished by imposing a restriction that keys never leave
the secure environment of the keystore. Data on disk is encrypted with a data
encryption key (DEK) that is stored with the database. The DEK, in turn, is encrypted by
a master key (MK), which is stored externally to the database. The DEK is sent to the
PKCS #11 keystore, where it is decrypted by the MK. The only exception to this
principle of keys not leaving the keystore is when migrating keys from a local keystore
file to a PKCS #11 keystore. In such cases, these keys are marked as external.
However, an immediate key rotation following migration will start to make use of
internally defined keys.

© Copyright IBM Corp. 1997, 2017 4-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Why consider a centralized key manager for encryption?

• Separation of the master key for encryption and the encrypted
database
 Native Encryption requires a local keystore for each Db2 instance
 May want to implement a central on-premises keystore to support multiple
cloud based database servers
• Simplifies management and backup of encryption master keys
 If you support many Db2 instances with encrypted databases you will need
to manage backup procedures for each local keystore
 Keystores need to be backed up at a minimum every time a key is added to
them, otherwise one incurs the risk of losing access to their data if the
keystore is corrupted.
• Simplifies implementation of HADR if primary and standby databases
can utilize a common centralized key manager

Creating databases and data placement © Copyright IBM Corporation 2017

Why consider a centralized key manager for encryption?

There are some advantages to using a centralized encryption key manager for Db2
databases.
• A centralized encryption key manager provides physical separation between the
data encryption key, which is stored on the database server, and the storage for
the master key. This separation could be used to provide a central on-premises
management of master keys for multiple cloud-based Db2 database servers.
• A centralized key manager could simplify management and backup operations for
the critical master key data if you need to support a large number of Db2
databases, compared to backups for the local keystore for each Db2 instance. It
is important to create a backup of the keystore each time a new master key is
added.
Using a centralized keystore makes it easier to implement native encryption for
HADR primary and standby databases. All of the primary and standby databases
can be configured to point to the same external key store.

© Copyright IBM Corp. 1997, 2017 4-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Native encryption using a centralized keystore

Creating databases and data placement © Copyright IBM Corporation 2017

Native encryption using a centralized keystore

The slide shows the components of a Db2 database using a centralized keystore for
data encryption.
Notice that this implementation requires both the local keystore on the database server
as well as the KMIP centralized keystore.
The central KMIP server holds the master key for encryption, while the local
keystore holds the SSL Certificates used for secure communications between the
local Db2 server and the KMIP server.

© Copyright IBM Corp. 1997, 2017 4-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Checklist to implement Db2 encryption with ISKLM based

keystore: part 1
• Install IBM SKLM software on server
• Create a local keystore for the Db2 instance using IBM GSK
 A local keystore is required on the Db2 server even if you intend to store
master keys in a centralized keystore.
• Configure SSL between a Db2 instance and ISKLM server
 On the Db2 server
− Create a SSL signer certificate in local keystore
− Extract the SSL signer certificate and securely transfer the file to the ISKLM
server
 On the ISKLM server
− Add the Db2 server certificate to the keystore
− Create a SSL signer certificate for the ISKLM server
− Extract the certificate to a file
− Securely transmit the centralized key manager certificate file to the Db2 server
 On the Db2 server
− Add the centralized key manager certificate to the local keystore.

Creating databases and data placement © Copyright IBM Corporation 2017

Checklist to implement Db2 encryption with ISKLM based keystore: part 1

This is a series of steps that you can utilize to implement an IBM Security Key Lifecycle
Manager (ISKLM)-based keystore for a Db2 11.1 database server.
• If ISKLM is not already in use, install the ISKLM software on a server. Since
ISKLM uses a Db2 database, you will also be creating a Db2 instance and
database on the server.
• You will need a local keystore for the Db2 instance that will manage the
encrypted Db2 database. The IBM GSK software, installed with Db2, will be used
to create the local keystore. The local keystore holds security certificates that
support secure communication with the ISKLM server.
• To store master keys in a centralized keystore with Db2 native encryption, you
need to set up SSL communication between the Db2 instance and the centralized
key manager.
• Create and extract an SSL signer certificate on the Db2 server using IBM GSK
commands.
• Add the SSL signer certificate from the Db2 server to the ISKLM keystore.
• Create and extract an SSL signer certificate on the ISKLM server using ISKLM
facilities.
• Add the SSL signer certificate from the ISKLM server to the local keystore
on the Db2 server.

© Copyright IBM Corp. 1997, 2017 4-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Checklist to implement Db2 encryption with ISKLM based

keystore: part 2
• Create a centralized keystore configuration file on the Db2 server
• Configure the Db2 instance Database Manager Configuration file
• On the Db2 server
− For a centralized keystore, set keystore_type to "KMIP"
− Set keystore_location to the absolute path and file name of the centralized
keystore configuration file
db2 update dbm cfg using keystore_type kmip
db2 update dbm cfg using
keystore_location /home/inst00/[Link]
− Restart the Db2 Instance

Creating databases and data placement © Copyright IBM Corporation 2017

Checklist to implement Db2 encryption with ISKLM based keystore: part 2

This continues the series of steps that you can utilize to implement an IBM Security Key
Lifecycle Manager (ISKLM)-based keystore for a Db2 11.1 database server.
• If ISKLM is not already in use, install the ISKLM software on a server. Since
ISKLM uses a Db2 database, you will also be creating a Db2 instance and
database on the server.
• Creating a centralized keystore configuration file. To store master keys in a
centralized keystore with Db2 native encryption, you need to create a
configuration file that lists details about the centralized keystore.
• Update the DBM configuration file for the Db2 instance.
• Set the keystore_type option to "KMIP"
• Set keystore_location to the absolute path and file name of the centralized
keystore configuration file
• Restart the Db2 instance for the configuration changes to take effect.

© Copyright IBM Corp. 1997, 2017 4-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Database components that are encrypted with Db2 native

encryption
• All user data in the database is encrypted
 All table spaces (system defined and user defined)
 All types of data in a table space (LOB, XML, etc. )
 All transaction logs including logs in the archives
 Backup images are encrypted by default if the database is encrypted
 LOAD COPY data
 LOAD staging files

Creating databases and data placement © Copyright IBM Corporation 2017

Database components that are encrypted with Db2 native encryption

The slide lists the database components that are encrypted when native encryption is
implemented for a database.
The encryption is applied to all system and user data in tablespaces, active and
archived log data, LOAD COPY, and LOAD staging files.
Database backup files will be encrypted by default, if the database is encrypted.

© Copyright IBM Corp. 1997, 2017 4-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

IBM Global Security Kit

• Db2 Native Encryption uses the IBM Global Security Kit (GSKit) for key
management and encryption
 Installed with Db2 in the sqllib/gskit directory
 GSKit libraries are used to encrypt/decrypt data, create store and manage
MKs
 FIPS 140-2 certified
 gsk8capicmd_64 is the command line tool used to manage the keystore

• Public Key Cryptography Standard (PKCS) #12:

 A password-protected keystore with a format for storing encryption keys
 Local keystore file
 Stores MKs
 Can use the same keystore for SSL certificates

Creating databases and data placement © Copyright IBM Corporation 2017

IBM Global Security Kit

Db2 native encryption uses the IBM Global Security Kit (GSKit) libraries.
GSKit is automatically included when you install the Db2 database system, and
when you install the 64-bit version of the Db2 server, the 32-bit GSKit libraries are
automatically included in the installation.

© Copyright IBM Corp. 1997, 2017 4-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Database path storage

Partition-global directory Member-specific directory
 The partition-global directory has the path:  The member-specific directory has the path:
your_instance/NODExxxx⁄SQLxxxxx your_instance/NODExxxx/SQLxxxx/
MEMBERxxxx
 /database/inst481/NODE0000/SQL00001:
 [Link]  /database/inst481/NODE0000/SQL00001
 [Link] /MEMBER0000:
 [Link]  db2event
 HADR  [Link]
 load  HADR
 LOGSTREAM0000 (Default database logs)  SQLBP.1
 MEMBER0000  SQLBP.2
 SQLDBCONF  SQLDBCONF
 SQLOGAB  SQLINSLK
 [Link].1  [Link].1
 [Link].2  [Link].2
 [Link]  [Link]
 SQLSGF.1  SQLTMPLK
 SQLSGF.2
 SQLSPCS.1  Local database Directory
 SQLSPCS.2 /database/inst481/NODE0000/sqldbdir:
 /database/inst481/NODE0000/SQL00001  sqldbbak
/LOGSTREAM0000:  sqldbdir
 [Link]  sqldbins
 [Link]
 [Link]

Creating databases and data placement © Copyright IBM Corporation 2017

Database path storage

Database directories and files
When you create a database, information about the database, including default
information, is stored in a directory hierarchy.
The hierarchical directory structure is created for you. You can specify the location of
the structure by specifying a directory path or drive for the CREATE DATABASE
command; if you do not specify a location, a default location is used.
In the directory that you specify as the database path in the CREATE DATABASE
command, a subdirectory that uses the name of the instance is created.
Within the instance-name subdirectory, the partition-global directory is created. The
partition-global directory contains global information associated with your new
database. The partition-global directory is named NODExxxx/SQLyyyyy, where xxxx is
the data partition number and yyyyy is the database token (numbered >=1).
Under the partition-global directory, the member-specific directory is created. The
member-specific directory contains local database information. The member-specific
directory is named MEMBERxxxx where xxxx is the member number.
In a Db2 pureScale environment, there is a member-specific directory for each
member, called MEMBER0000, MEMBER0001, and so on.

© Copyright IBM Corp. 1997, 2017 4-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

In a partitioned database environment, member numbers have a one-to-one mapping

with their corresponding partition number, therefore there is one NODExxxx directory
per member and partition. Member-specific directories are always named
MEMBERxxxx and they always reside under the partition-global directory.
An Enterprise Server Edition environment runs on a single member, and has one
member-specific directory, called MEMBER0000.
Partition-global directory
The partition-global directory has the path: your_instance/NODExxxx/SQLxxxxx
This directory contains the following files:
• Global deadlock write-to-file event monitor files that specify either a relative path
or no path at all.
• Table space information files. The files SQLSPCS.1 and SQLSPCS.2 contain
table space information. These files are duplicates of each other for backup
purposes.
• Storage group control files. The files SQLSGF.1 and SQLSGF.2 contain storage
group information associated with the automatic storage feature of a database.
These files are duplicates of each other for maintenance and backup purposes.
The files are created for a database when you create the database using the
CREATE DATABASE command or when you upgrade a nonautomatic storage
database to Db2 Version 10.1 or later.
• Temporary table space container files. The default location for new containers is
in They reside under <instance/NODExxxx/<db-name> directory. The files are
managed locally by each member. The table space file names are made unique
for each member by inserting the member number into the file name, for
example: /storage
path/SAMPLEDB/T0000011/[Link]/[Link]
• The global configuration file. The global configuration file, SQLDBCONF, contains
database configuration parameters that refer to single, shared resources that
must remain consistent across the database. Do not edit this file. To change
configuration parameters, use the UPDATE DATABASE CONFIGURATION and
RESET DATABASE CONFIGURATION commands.
• History files. The [Link] history file and its backup [Link]
contain history information about backups, restores, loading of tables,
reorganization of tables, altering of a table space, and other changes to a
database.

© Copyright IBM Corp. 1997, 2017 4-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• The [Link] file contains a history of table space changes at a log-file

level. For each log file, [Link] contains information that helps to identify
which table spaces are affected by the log file. Table space recovery uses
information from this file to determine which log files to process during table
space recovery. You can examine the contents of history files in a text editor.
• Logging-related files. The global log control files, [Link].1,
[Link].2, contain recovery information at the database level, for
example, information related to the addition of new members while the database
is offline and maintaining a common log chain across members. The log files
themselves are stored in the LOGSTREAMxxxx directories (one for each
member) in the partition-global directory.
• Locking files. The instance database lock files, SQLINSLK,and SQLTMPLK, help
to ensure that a database is used by only one instance of the database manager.
Automatic storage containers
Member-specific directory
The member-specific directory has the path: /NODExxxx/SQLxxxx/MEMBERxxxx
This directory contains objects associated with the first database created, and
subsequent databases are given higher numbers: SQL00002, and so on. These
subdirectories differentiate databases created in this instance on the directory that you
specified in the CREATE DATABASE command.
The database directory contains the following files:
• Buffer pool information files. The files SQLBP.1 and SQLBP.2 contain buffer pool
information. These files are duplicates of each other for backup purposes.
• Local event monitor files.
• Logging-related files. The log control files, [Link].1, its mirror copy
[Link].2, and [Link], contain information about the active
logs. In a Db2 pureScale environment, each member has its own log stream and
set of local LFH files, which are stored in each member-specific directory.
Note: Map the log subdirectory to disks that you are not using for your data. By
doing so, you might restrict disk problems to your data or the logs, instead of
having disk problems for both your data and the logs. Mapping the log
subdirectory to disks that you are not using for your data can provide a
substantial performance benefit because the log files and database containers do
not compete for movement of the same disk heads. To change the location of the
log subdirectory, use the newlogpath database configuration parameter.
• The local configuration file. The local SQLDBCONF file contains database
configuration information. Do not edit this file. To change configuration
parameters, use the UPDATE DATABASE CONFIGURATION and RESET
DATABASE CONFIGURATION commands.

© Copyright IBM Corp. 1997, 2017 4-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Default table space containers with Automatic Storage

CREATE DATABASE DSS ON /dbauto DBPATH ON /database

dbauto

inst20 DB2INSTANCE=inst20

NODE0000

DSS
T0000000 SYSCATSPACE
[Link]

T0000001 TEMPSPACE1
[Link]

T0000002 USERSPACE1
[Link]

Creating databases and data placement © Copyright IBM Corporation 2017

Default table space containers with Automatic Storage

If Automatic Storage is enabled when a new database is created, Db2 will use
Automatic Storage Management for the three system default table spaces. The number
of containers and the names will depend on the number of and names of the Automatic
Storage paths defined.
The example assumes that the database named DSS is created in the instance named
inst20 with a single Automatic Storage path defined, named /dbauto. The table space
SYSCATSPACE will only have containers on NODE0000. The other two table spaces.
USERSPACE1 and TEMPSPACE1 will have containers defined, but will not contain
any data.

© Copyright IBM Corp. 1997, 2017 4-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

System catalog tables and views

...
SYSCAT [Link]
Views
SYSSTAT [Link]
...

Refer to notes for actual table and view names.

Creating databases and data placement © Copyright IBM Corporation 2017

System catalog tables and views

A set of system catalog tables is created and maintained for each database. These
tables contain information about the definitions of the database objects and also
security information about the type of access users have to these objects.
The database manager creates and maintains two sets of catalog views. All of the
system catalog views are created when a database is created with the CREATE
DATABASE command. The catalog views cannot be explicitly created or dropped. The
views are within the SYSCAT schema and select privilege on all views is granted to
PUBLIC by default. A second set of views formed from a subset of those within the
SYSCAT schema contains statistical information used by the SQL Optimizer. The views
within the SYSSTAT schema contain some updateable columns.

© Copyright IBM Corp. 1997, 2017 4-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Table space design limits: Row Identifiers

• Standard RIDs • Large RIDs
 For tables in regular table spaces  For tables in large table spaces
(DMS or Automatic Storage)
 Also all SYSTEM and USER
temporary table spaces
8
4 64 4 TB
KB GB 128 KB 16
GB 256 TB
8 KB 8 KB 32
GB 512
TB
GB 64
16 KB 16 KB TB

32 KB 32 KB
Page
Page Table space size size
size Table space size

512M ~2K
16M 255 rows
4x109 rows pages 1.1x1012 rows
pages rows

Row ID (RID) 4 bytes Large Row ID (RID) 6 bytes

Creating databases and data placement © Copyright IBM Corporation 2017

Table space design limits: Row Identifiers

Storage limitations for regular table spaces
If a table space is created as a Regular table space, the 4-byte Row Identifiers used
place a limit on the size for Db2 tables and table spaces. The three bytes that are used
for page numbers, provides addressing for up to 16 million pages. The one byte used
for slot numbers, limits pages to at most 255 rows per page. That provides an overall
limit of about 4 billion rows.
The maximum storage for table and table spaces depends on the page size selected
for the table space. With 16 million pages, a 4 KB page table space would be limited to
64 Gigabytes of storage. Using 8 KB pages doubles the limit to 128 GB. With 16 KB
pages, the limit is 256 GB and a 32 KB page size allows up to 512 GB to be addressed.
For tables in SMS table spaces, the limit applies at the table level. For tables in DMS-
managed table spaces, the limit applies to the table space. So creating a table with 6
indexes in a DMS table space with 8 KB pages, would place a size limit for the table
and its indexes at 256 GB. Using DMS table spaces, the indexes for a table can be
stored in a different regular or large DMS table space, which would allow a large table
to use the full capacity of a DMS regular table space.

© Copyright IBM Corp. 1997, 2017 4-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Table space storage limits for Large table spaces

Large table spaces use 6-byte Row Identifiers that extend the limits for the size of Db2
tables and table spaces. With 6-byte RIDs, four bytes are used for page numbers,
providing addressing for up to 2 billion pages. The other two bytes are used for slot
numbers, allowing more rows to be stored per data page. That provides an overall limit
of about 1.1 trillion rows for a table.
The maximum storage for table and table spaces depend on the page size selected for
the table space. With 512 million pages, a 4 KB page table space would be limited to 8
Terabytes of storage. Using 8 KB pages doubles the limit to 16 Terabytes. With 16 KB
pages, the limit is 32 Terabytes and a 32 KB page size allows up to 64 Terabytes to be
addressed.
The 6-byte RIDs are used for LARGE DMS table spaces. The standard 4-byte RIDs will
continue to be used REGULAR DMS and SMS table spaces.
All System and User Temporary tables will be using the larger 6-byte Row Identifiers for
temporary data objects. This applies to SMS and DMS temporary table spaces.

© Copyright IBM Corp. 1997, 2017 4-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

CREATE TABLESPACE syntax (1 of 2)

LARGE
CREATE TABLESPACE tablespace-name
REGULAR
SYSTEM
TEMPORARY
USER PAGESIZE 4096

DATABASE PARTITION GROUP PAGESIZE integer

K
IN db-partition-group-name

AUTOMATIC STORAGE -USING STOGROUP--storagegroup-name- | size-attr.

MANAGED BY SYSTEM | system-containers |
DATABASE |database-containers | EXTENTSIZE num-pages
integer K
M
G

PREFETCHSIZE AUTOMATIC BUFFERPOOL bufferpool-name

num-pages
integer K
M
G
number-of-milliseconds NO FILE SYSTEM CACHING
OVERHEAD Inherit FILE SYSTEM CACHING

number-of-milliseconds DROPPED TABLE RECOVERY ON

TRANSFERRATE Inherit OFF
Creating databases and data placement © Copyright IBM Corporation 2017

CREATE TABLESPACE syntax

The slide shows a portion of the syntax used to create a table space.
The default for table space type is Large. The default table space management type is
automatic storage. With Db2 LUW 10, automatic storage table spaces can be assigned
a named storage group. This directs Db2 to assign the containers from a specific set of
containers that may have different device characteristics.
When a table space is created, the page size and extent size is fixed and cannot be
altered. Table spaces can be assigned to use a specific buffer pool that has a matching
page size.
The OVERHEAD and TRANSFERRATE provide performance estimates that will be
used by the Db2 optimizer to determine efficient access plans. The setting for
OVERHEAD and TRANSFERRATE can be set to be ‘inherited’ from the storage group
for automatic storage table spaces.

© Copyright IBM Corp. 1997, 2017 4-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

CREATE TABLESPACE syntax (2 of 2)

size-attributes:

AUTORESIZE YES INITIALSIZE int K INCREASESIZE int perc MAXSIZE int K

NO M K M
G M G
system-containers: G NONE

,
USING ( 'container-string' )
| on-db-partitions-clause |
database-containers:

USING | container-clause |
| on-db-partitions-clause |
container-clause:
,
( FILE 'container-string' num-pages )
DEVICE integer K
M
G
on-db-partitions-clause:
,
ON DBPARTITIONNUM ( db-partition-number1 )
DBPARTITIONNUMS TO db-partition-number2

Creating databases and data placement © Copyright IBM Corporation 2017

Some additional options that can be selected when creating a table space are as
follows:
• AUTORESIZE: Specifies whether or not the auto-resize capability of a DMS table
space or an automatic storage table space is to be enabled. Auto-resize able
table spaces automatically increase in size when they become full. The default is
NO for DMS table spaces and YES for automatic storage table spaces.
• INITIALSIZE integer K | M | G: Specifies the initial size, per database partition, of
an automatic storage table space. This option is only valid for automatic storage
table spaces. The integer value must be followed by K (for kilobytes), M (for
megabytes), or G (for gigabytes). Note that the actual value used might be slightly
smaller than what was specified, because the database manager strives to
maintain a consistent size across containers in the table space. Moreover, if the
table space is auto-resize able and the initial size is not large enough to contain
meta-data that must be added to the new table space, the database manager will
continue to extend the table space by the value of INCREASESIZE until there is
enough space. If the INITIALSIZE clause is not specified, the database manager
determines an appropriate value. The value for integer must be at least 48 K.

© Copyright IBM Corp. 1997, 2017 4-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• INCREASESIZE integer PERCENT or INCREASESIZE integer K | M | G:

Specifies the amount, per database partition, by which a table space that is
enabled for auto-resize will automatically be increased when the table space is
full, and a request for space has been made. The integer value must be followed
by:
• PERCENT to specify the amount as a percentage of the table space size at the
time that a request for space is made. When PERCENT is specified, the integer
value must be between 0 and 100 (SQLSTATE 42615).
• K (for kilobytes), M (for megabytes), or G (for gigabytes) to specify the amount in
bytes
• Note that the actual value used might be slightly smaller or larger than what
was specified, because the database manager strives to maintain consistent
growth across containers in the table space. If the table space is auto-resize
able, but the INCREASESIZE clause is not specified, the database manager
determines an appropriate value.
• MAXSIZE integer K | M | G or MAXSIZE NONE: Specifies the maximum size to
which a table space that is enabled for auto-resize can automatically be
increased. If the table space is auto-resize able, but the MAXSIZE clause is not
specified, the default is NONE.
• INTEGER
• Specifies a hard limit on the size, per database partition, to which a DMS table
space or an automatic storage table space can automatically be increased.
The integer value must be followed by K (for kilobytes), M (for megabytes), or
G (for gigabytes). Note that the actual value used might be slightly smaller
than what was specified, because the database manager strives to maintain
consistent growth across containers in the table space.
• NONE
• Specifies that the table space is to be allowed to grow to file system capacity,
or to the maximum table space size (described in "SQL and XML limits").
DMS managed table spaces require container definitions that include a specific size,
while SMS managed table spaces require container definitions with no size specified.

© Copyright IBM Corp. 1997, 2017 4-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Storage groups (multi-temperature storage)

Partitioned Table Sales

Partition 2012Q1 2011Q4 2011Q3 2011Q2 2011Q1 2010Q4 … 2006Q3

Table Space Table Space Table Space Table Space Table Space Table Space Table Space
Automatic 14 13 12 11 10 9
…
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

Creating databases and data placement © Copyright IBM Corporation 2017

Storage groups (multi-temperature storage)

Storage groups were introduced as a new type of database object with Db2 10. They
are only used for Automatic storage table spaces and can be used to add the ability to
direct automatic storage table spaces to a defined set of storage paths.
A storage group is a named set of storage paths where data can be stored. Storage
groups are configured to represent different classes of storage available to your
database system. You can assign table spaces to the storage group that best suits the
data. Only automatic storage table spaces use storage groups.
A table space can be associated with only one storage group, but a storage group can
have multiple table space associations. To manage storage group objects you can use
the CREATE STOGROUP, ALTER STOGROUP, RENAME STOGROUP, DROP and
COMMENT statements.
With the table partitioning feature, you can place table data in multiple table spaces.
Using this feature, storage groups can store a subset of table data on fast storage while
the remainder of the data is on one or more layers of slower storage. Use storage
groups to support multi-temperature storage which prioritizes data based on classes of
storage. For example, you can create storage groups that map to the different tiers of
storage in your database system. Then the defined table spaces are associated with
these storage groups.

© Copyright IBM Corp. 1997, 2017 4-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

When defining storage groups, ensure that you group the storage paths according to
their quality of service characteristics. The common quality of service characteristics for
data follow an aging pattern where the most recent data is frequently accessed and
requires the fastest access time (hot data) while older data is less frequently accessed
and can tolerate higher access time (warm data or cold data).
The priority of the data is based on:
• Frequency of access
• Acceptable access time
• Volatility of the data
• Application requirements

© Copyright IBM Corp. 1997, 2017 4-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Creating a storage group

• Use the CREATE STOGROUP statement to create a new storage
group
>>-CREATE--STOGROUP--storagegroup-name-------------------------->
.-,--------------.
V |
>--ON---'storage-path'-+--●------------------------------------->

>--+----------------------------------+--●---------------------->
'-OVERHEAD--number-of-milliseconds-'
>--+-----------------------------------------------+--●--------->
'-DEVICE READ RATE--number-megabytes-per-second-'

>--+--------------------------------+--●------------------------>
'-DATA TAG--+-integer-constant-+-'
'-NONE-------------'
>--+----------------+--●---------------------------------------><
'-SET AS DEFAULT-'
CREATE STOGROUP HIGHEND
ON '/dbe/filesystem1', '/db2/filesystem2' OVERHEAD 0.75 DEVICE READ RATE 500 ;

CREATE STOGROUP MIDRANGE ON 'D:\', 'E:\' SET AS DEFAULT ;

Creating databases and data placement © Copyright IBM Corporation 2017

Creating a storage group

Use the CREATE STOGROUP statement to create storage groups. Creating a storage
group within a database assigns storage paths to the storage group.
If you create a database with the AUTOMATIC STORAGE NO clause it does not have
a default storage group. You can use the CREATE STOGROUP statement to create a
default storage group.
Note: Although, you can create a database specifying the AUTOMATIC STORAGE NO
clause, the AUTOMATIC STORAGE clause is deprecated and might be removed from
a future release.
To create a storage group by using the command line, enter the following statement:
CREATE STOGROUP operational_sg ON '/filesystem1', '/filesystem2'
where operational_sg is the name of the storage group, and /filesystem1 and
/filesystem2 are the storage paths to be added.
Note: To help ensure predictable performance, all the paths that you assign to a
storage group should have the same media characteristics: latency, device read rate,
and size.

© Copyright IBM Corp. 1997, 2017 4-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Assigning a table space to a storage group

• A specific storage group can be selected with the USING STOGROUP
option of CREATE TABLESPACE

create tablespace tsp04

managed by automatic storage using stogroup app_data
initialsize 100 K maxsize none
extentsize 2;

• The database storage path defined when the database is created

named , IBMSTOGROUP
 This will be the default storage group for automatic storage table spaces
when USING STOGROUP is not specified
 The ALTER STOGROUP statement option SET AS DEFAULT can be used
to change which storage group is the default for a database

Creating databases and data placement © Copyright IBM Corporation 2017

Assigning a table space to a storage group

For automatic storage table spaces, the USING STOGROUP option allows a new table
space to be assigned to an existing storage group. This allows the database
administrator to select the subset of disk paths that would be used to allocate the
containers for an automatic storage table space. Db2 allows the same path to be
included in multiple storage groups.
If a database has storage groups, the default storage group is used when an automatic
storage managed table space is created without explicitly specifying the storage group.
When you create a database, a default storage group named IBMSTOGROUP is
automatically created. However, a database created with the AUTOMATIC STORAGE
NO clause, does not have a default storage group. The first storage group created with
the CREATE STOGROUP statement becomes the designated default storage group.
There can only be one storage group designated as the default storage group.
You can designate a default storage group by using either the CREATE STOGROUP
or ALTER STOGROUP statements. When you designate a different storage group as
the default storage group, there is no impact to the existing table spaces using the old
default storage group. To alter the storage group associated with a table space, use the
ALTER TABLESPACE statement.
You can determine which storage group is the default storage group by using the
[Link] catalog view.

© Copyright IBM Corp. 1997, 2017 4-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Managing storage groups using ALTER STOGROUP

• Use the ALTER STOGROUP statement to make changes to a
storage group
 Similar to database storage paths in previous releases
 New disk storage paths can be added
 Existing storage paths can be dropped
− Use ALTER TABLESPACE REBALANCE for each table space to release
containers on dropped path
>>-ALTER--STOGROUP--storagegroup-name--------------------------->
.-------------------------------------------------------.
| .-,--------------. |
V V | (1) |
>----+-ADD---'storage-path'-+------------------------+-----+---><
| .-,--------------. |
| V | |
+-DROP---'storage-path'-+-----------------------+
+-OVERHEAD--number-of-milliseconds--------------+
+-DEVICE READ RATE--number-megabytes-per-second-+
+-DATA TAG--+-integer-constant-+----------------+
| '-NONE-------------' |
'-SET AS DEFAULT--------------------------------'

Creating databases and data placement © Copyright IBM Corporation 2017

Managing storage groups using ALTER STOGROUP

You can use the ALTER STOGROUP statement to alter the definition of a storage
group, including setting media attributes, setting a data tag, or setting a default storage
group. The processing is similar to using ALTER DATABASE in previous releases, but
ALTER STOGROUP only changes one storage group. You can also add and remove
storage paths from a storage group.
If you add storage paths to a storage group and you want to stripe the extents of their
table spaces over all storage paths, you must use the ALTER TABLESPACE statement
with the REBALANCE option for each table space that is associated with that storage
group.
If you drop storage paths from a storage group, you must use the ALTER
TABLESPACE statement with the REBALANCE option to move allocated extents off
the dropped paths.
You can use the Db2 Work Load Manager (WLM) to define rules about how activities
are treated based on a tag that is associated with accessed data. You associate the tag
with data when defining a table space or a storage group.

© Copyright IBM Corp. 1997, 2017 4-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Query storage groups with SQL using the table function

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

2 record(s) selected.

Creating databases and data placement © Copyright IBM Corporation 2017

Query storage groups with SQL using the table function

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, and can be used to check the status of the database storage groups..
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.

© Copyright IBM Corp. 1997, 2017 4-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

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

© Copyright IBM Corp. 1997, 2017 4-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Listing storage groups with the db2pd command

• db2pd -db musicdb -storagegroups

Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date 2014-09-10-10.00.43.472063

Storage Group Configuration:

Address SGID Default DataTag Name
0x00007F94AC34C020 0 Yes 0 IBMSTOGROUP
0x00007F94B39A7440 1 No 0 APP_DATA

Storage Group Statistics:

Address SGID State Numpaths NumDropPen
0x00007F94AC34C020 0 0x00000000 1 0
0x00007F94B39A7440 1 0x00000000 1 0

Storage Group Paths:

Address SGID PathID PathState PathName
0x00007F94AC34C140 0 0 InUse /dbauto/path1
0x00007F94B39A8580 1 1024 NotInUse /dbauto/path2

Creating databases and data placement © Copyright IBM Corporation 2017

Listing storage groups with the db2pd command

The slide shows an example of the db2pd command report for storage groups. The
db2pd command can be used to get the current information about the storage groups
for a database.
The report lists all the defined storage groups for a database and includes the
designation of the default storage group and lists the paths assigned to each storage
group.

© Copyright IBM Corp. 1997, 2017 4-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Storage Management alternatives: Automatic

• Syntax for CREATE and ALTER TABLESPACE:
CREATE TABLESPACE <tsName> [MANAGED BY AUTOMATIC STORAGE]
[USING STOGROUP storagegroup-name ]
[INITIALSIZE integer {K|M|G}]
[AUTORESIZE {NO|YES}] [INCREASESIZE integer {PERCENT|K|M|G}]
[MAXSIZE {NONE | integer {K|M|G}}]

• Default initial size is 32 MB

• Default max size is none
• Default increase size is determined by Db2, which might change
over the life of the table space
• Examples:
CREATE TABLESPACE USER1 USING STOGROUP APP_DATA
CREATE TEMPORARY TABLESPACE TEMPTS
CREATE TABLESPACE MYTS INITIALSIZE 100 M MAXSIZE 1 G
CREATE LARGE TABLESPACE LRGTS INITIALSIZE 5 G AUTORESIZE NO
CREATE REGULAR TABLESPACE USER2 INITIALSIZE 500 M

Creating databases and data placement © Copyright IBM Corporation 2017

Storage Management alternatives: Automatic

The administration of table spaces using Automatic Storage is very easy. The CREATE
TABLESPACE syntax does not require the names of containers or the number of
containers to be defined. For Automatic Storage table spaces, the disk space is
assigned from a storage group. If no storage group is specified, a default storage group
will be used.
This allows the DBA to monitor available space at the storage group level instead of
each individual table space. As long as there is space available in one of the defined
Automatic Storage paths, a table space can be automatically extended by Db2. Smaller
databases may only want a single storage group for the database.
When a table space is created, Db2 can create multiple containers, using all of the
available storage paths, which helps performance for table and index scans.
Additional storage path(s) can be added using an ALTER STOGROUP statement, to
support growth over time.
Automatic Storage management actually uses DMS and SMS table spaces under the
covers. A DMS table space is used for REGULAR and LARGE table spaces, while
SMS is used for SYSTEM and USER TEMPORARY table spaces.

© Copyright IBM Corp. 1997, 2017 4-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The allocation of space for Automatic Storage table spaces can be controlled using the
options of CREATE and ALTER TABLESPACE, including:
• INITIALSIZE - Which defaults to 32 MB, if not specified.
• AUTORESIZE - Can be set to YES or NO, with YES being the default for Regular
and Large table spaces.
• INCREASESIZE - Can be set to a specific amount or percentage increase.
• MAXSIZE - Can be used to define a limit on growth for the table space.

© Copyright IBM Corp. 1997, 2017 4-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

ALTER TABLESPACE
• ALTER TABLESPACE can be used to change table space
characteristics:
 For all types table space management, you can adjust:
− Bufferpool assigned
− Prefetch size
− Overhead and Transfer rate I/O Costs
− File System Caching option
 For DMS-managed table spaces, you can:
− Use the ADD, DROP, RESIZE, EXTEND, REDUCE and BEGIN NEW STRIPE SET to
directly adjust container names and sizes.
− Use MANAGED BY AUTOMATIC STORAGE to convert to Automatic Storage
management
 For Automatic Storage-managed table spaces, you can:
− Use the REDUCE option to release unused disk space
− Use REBALANCE to reallocate containers when Automatic Storage paths are added or
dropped
 For DMS and Automatic Storage, you can:
− Change the MAXSIZE, INCREASESIZE and AUTORESIZE settings
 For Automatic Storage
− Change the storage group, USING STOGROUP
Creating databases and data placement © Copyright IBM Corporation 2017

ALTER TABLESPACE
The ALTER TABLESPACE statement is used to modify an existing table space in the
following ways:
• Add a container to, or drop a container from a DMS table space; that is, a table
space created with the MANAGED BY DATABASE option.
• Modify the size of a container in a DMS table space.
• Lower the high water mark for a DMS table space through extent movement.
• Add a container to an SMS table space on a database partition that currently has
no containers.
• Modify the PREFETCHSIZE setting for a table space.
• Modify the BUFFERPOOL used for tables in the table space.
• Modify the OVERHEAD setting for a table space.
• Modify the TRANSFERRATE setting for a table space.
• Modify the file system caching policy for a table space.
• Enable or disable auto-resize for a DMS or Automatic Storage table space.
• Rebalance a regular or large automatic storage table space.

© Copyright IBM Corp. 1997, 2017 4-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The privileges held by the authorization ID of the statement must include SYSCTRL or
SYSADM authority.
Starting with Db2 10.1, the ALTER TABLESPACE statement can be used with a
USING STOGROUP option to change the storage group for a table space. This causes
Db2 to assign a new set of containers in the target storage group and rebalance the
data into the new containers. The original containers will be deleted when the automatic
rebalance operation completes.

© Copyright IBM Corp. 1997, 2017 4-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Adding or dropping Automatic Storage paths

• New Automatic Storage paths can added to a storage group using the
ALTER STOGROUP
alter STOGROUP APP_DATA add storage on
‘/dbauto/path3’,’/dbauto/path4’
 Automatic Storage can be enabled in an existing database by creating the
first storage group, which becomes the default storage group
 Existing Automatic table spaces will grow using the previously assigned
storage paths until remaining space is used
 Newly created table spaces will begin to use all defined paths
 Individual table spaces can be altered using REBALANCE to spread data
over all storage paths
• Storage paths can also be removed using ALTER STOGROUP
alter STOGROUP IBMSTOGROUP drop storage on ‘/dbauto/path1’
 The dropped path will be in drop pending state until a ALTER
TABLESPACE with the REBALANCE option is used for each table space
with containers on the dropped path

Creating databases and data placement © Copyright IBM Corporation 2017

Adding or dropping Automatic Storage paths

New Automatic Storage paths can added to a database using the ALTER STOGROUP
command.
For example:
alter stogroup APP_DATA add storage on
‘/dbauto/path3’,’/dbauto/path4’
• Automatic Storage can be enabled in an existing database by creating a new
storage group, which will become the default storage group for the database.
• When new paths are added to a storage group, existing Automatic Storage table
spaces in that group, will grow using the previously assigned storage paths until
remaining space is used.
• Newly created table spaces will begin to use all defined paths
• Individual table spaces can be altered using REBALANCE to spread data over all
storage paths

© Copyright IBM Corp. 1997, 2017 4-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Storage paths can also be removed using ALTER STOGROUP.

alter STOGROUP IBMSTOGROUP drop storage on ‘/dbauto/path1’
The dropped path will be in drop pending state until a ALTER TABLESPACE with the
REBALANCE option is used for each table space with containers on the dropped path.

© Copyright IBM Corp. 1997, 2017 4-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Using the [Link] view

SELECT substr(tbspace,1,18) as tbspace, substr(definer,1,10) as definer,

tbspaceid, tbspacetype, datatype, sgname
from [Link]

TBSPACE DEFINER TBSPACEID TBSPACETYPE DATATYPE SGNAME

------------------ ---------- ----------- ----------- -------- ------------
SYSCATSPACE SYSIBM 0 D A IBMSTOGROUP
TEMPSPACE1 SYSIBM 1 S T IBMSTOGROUP
USERSPACE1 SYSIBM 2 D L IBMSTOGROUP
SYSTOOLSPACE inst28 3 D L IBMSTOGROUP
TSP01 inst28 4 D L APP_DATA
TSP02 inst28 5 D L -
TSP03 inst28 6 D L -
TSP04 inst28 7 D L APP_DATA
TSP05 inst28 8 D L APP_DATA
TSP06 inst28 9 D A IBMSTOGROUP

DMS managed tablespaces will not

be associated with a storage group

Creating databases and data placement © Copyright IBM Corporation 2017

Using the [Link] view

The sample query and result show how the view [Link] can be
used to get information about the table spaces in a database.
Notice that the three default table spaces are listed with a definer of SYSIBM. The
SGNAME column shows the storage group used for automatic storage table spaces.
The column TBSPACETYPE, is the type of table space.
• D = Database-managed space
• S = System-managed space
The column DATATYPE show the type of data that can be stored in this table space.
• A = All types of permanent data; regular table space
• L = All types of permanent data; large table space
• T = System temporary tables only
• U = Created temporary tables or declared temporary tables only

© Copyright IBM Corp. 1997, 2017 4-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Using the db2pd command to list

tablespace status and statistics

db2pd –db musicdb –tablespaces

Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date 05/03/2012

[Link]
Tablespace Configuration:
Address Id Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk ..Name
0x9396EEC0 0 DMS Regular 4096 4 Yes 4 1 1 ..SYSCATSPACE
0x93977C90 1 SMS SysTmp 4096 32 Yes 32 1 1 ..TEMPSPACE1
0x93982990 2 DMS Large 4096 32 Yes 32 1 1 ..USERSPACE1
0x95727700 3 DMS Large 4096 4 Yes 4 1 1 ..SYSTOOLSPACE
0x957B92B0 4 DMS Regular 4096 4 Yes 4 1 1 ..TSP01
0x957C58B0 5 DMS Large 4096 2 Yes 2 1 1 ..TSP02
0x957D8760 6 DMS Large 4096 8 Yes 8 1 1 ..TSP03
0x957E0EC0 7 DMS Large 4096 2 Yes 2 1 1 ..TSP04

Tablespace Statistics:
Address Id TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWM
0x9396EEC0 0 24576 24572 20696 0 3876 20696
0x93977C90 1 1 1 1 0 0 0
…..

Creating databases and data placement © Copyright IBM Corporation 2017

Using the db2pd command to list tablespace status and statistics

The db2pd command can be used to list the current status and usage of the table
spaces for an active database. The db2pd command would be run from the database
server by a user system the system administration authority defined for the Db2
instance.
The slide shows an example of a portion of the detailed table space report generated
by a db2pd command.

© Copyright IBM Corp. 1997, 2017 4-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Using the MON_GET_TABLESPACE function

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

---------- -------------------- -------------------- ---------------- --------------------
ASMTSPD 0 0 FILE_EXTENT_TAG 4512
ASMTSPD 1 0 FILE_EXTENT_TAG 4512
ASMTSPD 2 0 FILE_EXTENT_TAG 4512
DMSMTSPD 0 0 FILE_EXTENT_TAG 4000
DMSMTSPD 1 0 FILE_EXTENT_TAG 4000
DMSMTSPD 2 0 FILE_EXTENT_TAG 4000
DMSMTSPD 3 1 FILE_EXTENT_TAG 2000

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
Creating databases and data placement © Copyright IBM Corporation 2017

Using the MON_GET_TABLESPACE function

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.
The term high water mark refers to the highest allocated extent for a tablespace.
For example, a tablespace is defined as 25GB and used to load two tables. The first
table requires 5GB of storage. The second table allocates an additional 10GB of
storage. If the first table is dropped, the high water mark value would indicate 15GB, but
the space used would be reported as 10GB, with 15GB available free space.
Notice that in both examples the high water mark is significantly higher than the current
space used.

© Copyright IBM Corp. 1997, 2017 4-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Additional Db2 System table spaces

• The SYSTOOLSPACE table space is a user data table space used by the Db2
administration tools and some SQL administrative routines for storing historical data
and configuration information:
 ADMIN_COPY_SCHEMA procedure
 ADMIN_DROP_SCHEMA procedure
 ADMIN_MOVE_TABLE procedure
 ADMIN_MOVE_TABLE_UTIL procedure
 Administrative task scheduler
 ALTOBJ procedure
 Automatic Reorganization (including the db.tb_reorg_req health indicator)
 Automatic Statistics Collection (including the db.tb_runstats_req health indicator)
 Configure Automatic Maintenance wizard
 db2look command
 GET_DBSIZE_INFO procedure
 Storage Management tool
 SYSINSTALLOBJECTS procedure
• The SYSTOOLSTMPSPACE table space is a user temporary table space used by
the REORGCHK_TB_STATS, REORGCHK_IX_STATS and the ADMIN_CMD
stored procedures for storing temporary data.
Creating databases and data placement © Copyright IBM Corporation 2017

Additional Db2 System table spaces

SYSTOOLSPACE and SYSTOOLSTMPSPACE table spaces
The SYSTOOLSPACE table space is a user data table space used by the Db2
administration tools and some SQL administrative routines for storing historical data
and configuration information.
The following tools and SQL administrative routines use the SYSTOOLSPACE table
space:
• ADMIN_COPY_SCHEMA procedure
• ADMIN_DROP_SCHEMA procedure
• ADMIN_MOVE_TABLE procedure
• ADMIN_MOVE_TABLE_UTIL procedure
• Administrative task scheduler
• ALTOBJ procedure
• Automatic Reorganization (including the db.tb_reorg_req health indicator)
• Automatic Statistics Collection (including the db.tb_runstats_req health indicator)
• Configure Automatic Maintenance wizard

© Copyright IBM Corp. 1997, 2017 4-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• db2look command
• GET_DBSIZE_INFO procedure
• Storage Management tool
• SYSINSTALLOBJECTS procedure
The SYSTOOLSPACE table space is created the first time any of the tools and SQL
administrative routines listed previously are used. The db2look command,
administrative task scheduler, ALTOBJ, ADMIN_COPY_SCHEMA, and
ADMIN_DROP_SCHEMA procedures are exceptions; the SYSTOOLSPACE table
space must be created before you can use them.
The SYSTOOLSTMPSPACE table space is a user temporary table space used by the
REORGCHK_TB_STATS, REORGCHK_IX_STATS and the ADMIN_CMD procedures
for storing temporary data. The SYSTOOLSTMPSPACE table space will be created the
first time any of these procedures is invoked (except for ADMIN_CMD).

© Copyright IBM Corp. 1997, 2017 4-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Database buffer pools

• Databases have one buffer pool, IBMDEFAULTBP when the database
is created
 The page size is 4K unless CREATE DATABASE includes the PAGESIZE option
• Use the CREATE BUFFERPOOL statement to create a new buffer pool
>>-CREATE BUFFERPOOL--bufferpool-name--+-----------+------------>
'-DEFERRED--'
.-SIZE--1000--AUTOMATIC----------------.
>--+--------------------------------------+--●------------------>
+-SIZE--number-of-pages----------------+
| .-1000------------. |
'-SIZE--+-----------------+--AUTOMATIC-'
'-number-of-pages-'
>--●--+--------------------------+--●--------------------------><
'-PAGESIZE--integer--+---+-'
'-K-'
• Use ALTER BUFFERPOOL to change buffer pool size
• Table spaces must be assigned to a buffer pool with a matching
pagesize
 Use the BUFFERPOOL option of CREATE TABLESPACE to assign a buffer pool
 ALTER TABLESPACE can be used to change the assigned buffer pool

Creating databases and data placement © Copyright IBM Corporation 2017

Database buffer pools

A buffer pool is an area of main memory that has been allocated by the database
manager for the purpose of caching table and index data as it is read from disk. Every
Db2 database must have a buffer pool.
Each new database has a default buffer pool defined, called IBMDEFAULTBP.
Additional buffer pools can be created, dropped, and modified, using the CREATE
BUFFERPOOL, DROP BUFFERPOOL, and ALTER BUFFERPOOL statements.
The [Link] catalog view accesses the information for the buffer
pools defined in the database.
If there is sufficient memory available, the buffer pool can become active immediately.
By default new buffer pools are created using the IMMEDIATE keyword, and on most
platforms, the database manager is able to acquire more memory. The expected return
is successful memory allocation. In cases where the database manager is unable to
allocate the extra memory, the database manager returns a warning condition stating
that the buffer pool could not be started. This warning is provided on the subsequent
database startup. For immediate requests, you do not need to restart the database.
When this statement is committed, the buffer pool is reflected in the system catalog
tables, but the buffer pool does not become active until the next time the database is
started.

© Copyright IBM Corp. 1997, 2017 4-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

If you issue a CREATE BUFFERPOOL DEFERRED, the buffer pool is not immediately
activated; instead, it is created at the next database startup. Until the database is
restarted, any new table spaces use an existing buffer pool, even if that table space is
created to explicitly use the deferred buffer pool.

© Copyright IBM Corp. 1997, 2017 4-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Designing buffer pools

• Advantages of large buffer pools
 Frequently requested data pages to be kept in the buffer pool, which allows
quicker access.
 Fewer I/O operations can reduce I/O contention, thereby providing better
response time
 They provide the opportunity to achieve higher transaction rates with the same
response time.
• Considerations for using more than one buffer pool:
 Temporary table spaces can be assigned to a separate buffer pool to provide
better performance for queries, especially sort-intensive queries
 If data must be accessed repeatedly and quickly by many short update-
transaction applications, consider assigning the table space that contains the data
to a separate buffer pool.
 You can isolate data into separate buffer pools to favor certain applications, data,
and indexes..
 You can use smaller buffer pools for data that is accessed by seldom-used
applications, especially applications that require very random access into a very
large table.

Creating databases and data placement © Copyright IBM Corporation 2017

Designing buffer pools

Advantages of large buffer pools
Large buffer pools provide the following advantages:
They enable frequently requested data pages to be kept in the buffer pool, which allows
quicker access. Fewer I/O operations can reduce I/O contention, thereby providing
better response time and reducing the processor resource needed for I/O operations.
They provide the opportunity to achieve higher transaction rates with the same
response time.
They prevent I/O contention for frequently used disk storage devices, such as those
that store the catalog tables and frequently referenced user tables and indexes. Sorts
required by queries also benefit from reduced I/O contention on the disk storage
devices that contain temporary table spaces.
Use only a single buffer pool if any of the following conditions apply to your system:
• The total buffer pool space is less than 10 000 4-KB pages
• Persons with the application knowledge to perform specialized tuning are not
available
• You are working on a test system

© Copyright IBM Corp. 1997, 2017 4-68

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

In all other circumstances, and for the following reasons, consider using more than one
buffer pool:
• Temporary table spaces can be assigned to a separate buffer pool to provide
better performance for queries (especially sort-intensive queries) that require
temporary storage.
• If data must be accessed repeatedly and quickly by many short update-
transaction applications, consider assigning the table space that contains the data
to a separate buffer pool. If this buffer pool is sized appropriately, its pages have
a better chance of being found, contributing to a lower response time and a lower
transaction cost.
• You can isolate data into separate buffer pools to favor certain applications, data,
and indexes. For example, you might want to put tables and indexes that are
updated frequently into a buffer pool that is separate from those tables and
indexes that are frequently queried but infrequently updated.
• You can use smaller buffer pools for data that is accessed by seldom-used
applications, especially applications that require very random access into a very
large table. In such cases, data need not be kept in the buffer pool for longer than
a single query. It is better to keep a small buffer pool for this type of data, and to
free the extra memory for other buffer pools.

© Copyright IBM Corp. 1997, 2017 4-69

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Maintain or List System Database Directory

• CLP
db2 ? CATALOG DATABASE
CATALOG DATABASE database-name [AS alias] [ON path | AT NODE nodename]
[AUTHENTICATION {SERVER | CLIENT | ... | SERVER_ENCRYPT}]
[WITH "comment-string"]

db2 'CATALOG DATABASE ourdb AS TESTDB ON /database WITH "Test Database"'

db2 LIST DATABASE DIRECTORY

Database alias = TESTDB

Database name = OURDB
Local database directory = /database
Database release level = a.00
Comment = Test Database
Directory entry type = Indirect
Catalog database partition number = 4

Creating databases and data placement © Copyright IBM Corporation 2017

Maintain or List System Database Directory

The Db2 command line processor can be used to change directory entries in the
system database directory for a Db2 instance.
Within the database directory a database alias must be unique. The database name
does not have to be unique. A reason to catalog a local database is to change its alias,
which is the name by which users and programs identify the database. When a
database is created, its alias is the same as its name. The name by which users and
programs refer to a database can be changed without having to DROP and re-
CREATE the database.
You might want a database cataloged with more than one alias name.
The UNCATALOG command can be used to remove a database alias.

© Copyright IBM Corp. 1997, 2017 4-70

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Database configuration tools

db2 get db cfg for musicdb show detail

db2 update db cfg for musicdb using <parm> <value>
Creating databases and data placement © Copyright IBM Corporation 2017

Database configuration tools

The database configuration file is created when a Db2 database is created. The
parameters it contains affect resources at the database level. Values for many of these
parameters can be changed from the default values to improve performance or support
different application requirements.
The Db2 CLP or tools like IBM Data Server Manager might be used to get a listing of
the database configuration file. The GET DB CFG command will list the parameters
contained in the database configuration file.
The updateable parameters in the database configuration file can be changed using the
UPDATE DB CFG command, or using the IBM Data Server Manager tool.
The database territory, code set, country code, and code page are recorded in the
database configuration file. However, these parameters cannot be changed.
The db2pd command option -dbcfg can also be used to get the current options for an
active database. This shows the value active in memory and the current value in the
configuration disk file, which may take effect on the next database restart.

© Copyright IBM Corp. 1997, 2017 4-71

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

ACTIVATE and DEACTIVATE the database

• ACTIVATE DATABASE
 Activates the specified database and starts up all necessary database
services, so that the database is available for connection and use by any
application.
− Incurs the database startup processing
db2 activate db <db_name> user <user> using <password>

• DEACTIVATE DATABASE
 Databases initialized by ACTIVATE DATABASE can be shut down using the
DEACTIVATE DATABASE command, or using the db2stop command.
db2 deactivate db <db_name>

Creating databases and data placement © Copyright IBM Corporation 2017

ACTIVATE and DEACTIVATE the database

If a database has not been started, and a CONNECT TO (or an implicit connect) is
issued in an application, the application must wait while the database manager starts
the required database, before it can do any work with that database. However, once the
database is started, other applications can simply connect and use it without spending
time on its start up.
Database administrators can use ACTIVATE DATABASE to start up selected
databases. This eliminates any application time spent on database initialization.
Databases initialized by ACTIVATE DATABASE can be shut down using the
DEACTIVATE DATABASE command, or using the db2stop command.
If a database was started by a CONNECT TO (or an implicit connect) and subsequently
an ACTIVATE DATABASE is issued for that same database, then DEACTIVATE
DATABASE must be used to shut down that database. If ACTIVATE DATABASE was
not used to start the database, the database will shut down when the last application
disconnects.

© Copyright IBM Corp. 1997, 2017 4-72

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

ACTIVATE DATABASE behaves in a similar manner to a CONNECT TO (or an implicit

connect) when working with a database requiring a restart (for example, database in an
inconsistent state). The database will be restarted before it can be initialized by
ACTIVATE DATABASE. Restart will only be performed if the database is configured to
have AUTORESTART ON.
The application issuing the ACTIVATE DATABASE command cannot have an active
database connection to any database.

© Copyright IBM Corp. 1997, 2017 4-73

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

QUIESCE and UNQUIESCE the database

• QUIESCE DATABASE
 Forces all users off the current database
 In this mode, only users with authority in this restricted mode are allowed
to connect
db2 connect to proddb user dbaprod1
db2 quiesce db immediate

• UNQUIESCE DATABASE
 After administrative tasks are complete, use the UNQUIESCE command
to allow other users to connect to the database
 The UNQUIESCE command restores user access without necessitating
a shutdown and database restart
db2 unquiesce db

Creating databases and data placement © Copyright IBM Corporation 2017

QUIESCE and UNQUIESCE the database

The QUIESCE command forces all users off either the specified instance or database
across all members and puts them into a quiesced mode.
While the instance or database is in quiesced mode, you can perform administrative
tasks on it. After administrative tasks are complete, use the UNQUIESCE command to
activate the instance or database and allow other users to connect to the database.
In this mode, only users with authority in this restricted mode are allowed to attach or
connect to the instance or database. Users with SYSADM, SYSMAINT, and SYSCTRL
authority always have access to an instance while it is quiesced, and users with
SYSADM and DBADM authority always have access to a database while it is quiesced.

© Copyright IBM Corp. 1997, 2017 4-74

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Demonstration 1
Creating databases and data placement

• Create a new Db2 database with native encryption.

• Change some of the default database configuration options.
• Create a new Storage Group to support application storage.
• Create a set of tablespaces to support the database objects you plan
to create.
• Use SQL queries and db2pd commands to review the options and
disk storage associated with the new database.

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Demonstration 1: Creating databases and data placement

© Copyright IBM Corp. 1997, 2017 4-75

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Demonstration 1:
Creating databases and data placement
Purpose:
This demonstration will create a new Db2 database named MUSICDB that will
support the database objects that you will create and manage in the following
demonstrations. The new database will include Db2 native encryption. You
will create a new storage group and use Db2 commands and SQL queries to
investigate database storage.

Task 1. Logon to the Linux system and create the

Db2 database, MUSICDB.
In this demonstration you will create a new Db2 database with a name of MUSICDB.
The course uses a set of sample tables, so you will create a series of tablespaces to
provide the storage for those tables. The database will be created in the instance
inst23, created in the previous demonstration.
We are going to create an encrypted database, so we will need to create a local
keystore file and configure the Db2 instance options KEYSTORE_TYPE and
KEYSTORE_LOCATION to enable Db2 native encryption.
In most cases, the demonstration instructions will include step-by-step instructions to
perform each step using the IBM Data Server Manager tool. You will also have the
option to complete some tasks using a Db2 command line processor. Some commands
can only be executed using the Db2 command line processor.
1. Logon to the Linux system using the user id inst23, 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. (You may
have a terminal open from the previous demonstration. If so, you can use the
same one.)
A set of course files are located in the directory $HOME/ddl. Change to this
directory to make it easier to access these files that contain Db2 commands or
SQL statements. Check the current Db2 instance.

© Copyright IBM Corp. 1997, 2017 4-76

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

3. Enter the following commands using the Linux terminal session:

• cd $HOME/ddl
• db2 get instance
The current instance should be inst23.
We can use a command file named create_keystore.cmd to create a local
keystore for the Db2 instance. The IBM Global Security Kit command,
gsk9capicmd_64, is used to create the keystore named inst23keystore.p12
with a stashed password.
The file create_keystore.cmd includes the following command:
gsk8capicmd_64 -keydb -create -db inst23keystore.p12
-pw DB2luwPassw0rd -strong -type pkcs12 -stash;
We will need to set the DBM options KEYSTORE_TYPE and
KEYSTORE_LOCATION to enable Db2 native encryption. These two options
are linked, so they need to be updated using a single UPDATE DBM CFG
command.
4. Enter the following commands using the Linux terminal session:
• cat create_keystore.cmd
• ./create_keystore.cmd
• db2 update dbm cfg using KEYSTORE_TYPE pkcs12
KEYSTORE_LOCATION $HOME/ddl/inst23keystore.p12
• db2stop force
• db2start
The Data Server Manager software utilizes a service that must be started to use
the DSM tool. You will switch to the root user to start that service.
It is important to remember that you have not automated starting the DSM
service, so this must be done each time the Linux system is restarted. Use the
UNIX su command to switch user to root. You will also need to check to make
sure the Db2 instance, inst00, that supports the database DSMDATA is started.
Enter the following commands using the Linux terminal session:
• su - inst00
You will be prompted for the root user password (ibm2blue)
• db2start
• exit

© Copyright IBM Corp. 1997, 2017 4-77

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Now use root to start the DSM service.

• su - root
You will be prompted for the root user password (dalvm3)
The DSM software was installed in the disk path /root/ibmdsm/ibm-
datasrvrmgr.
• cd ibmdsm/ibm-datasrvrmgr/bin
• ./[Link]
It will take a couple of minutes to start. The output from this command will look
similar to the following:
......
dsserver_home: /root/ibmdsm/ibm-datasrvrmgr
port: 11080
[Link]: 11081
[Link]: 11082
SERVER STATUS: ACTIVE
Log: /root/ibmdsm/ibm-datasrvrmgr/logs/[Link]
Notice that the port number used to access the DSM service is listed - 11080.
Now you will exit from the root user to return to the instance owner inst23.
• exit
You will create the database using the CREATE DATABASE command, using
the Db2 command line processor. The database path /database will be used for
the new database, but the path /dbauto/path1 will be used for automatic
storage disk space. The encrypt option will instruct Db2 to create the database
using encryption with the keystore defined by the Db2 instance configuration.
5. Enter the following commands using the Linux terminal session:
• db2 create database musicdb on /dbauto/path1 dbpath on /database
encrypt
(database creation may take several minutes to complete)
• db2 connect to musicdb
Now that you have a database created, you will create a database connection
profile for the Data Server Manager tool. Check the database manager
configuration file to see what port number is assigned to the inst23 instance.
6. Enter the following commands using the Linux terminal session:
• db2 get dbm cfg | grep SVCE

© Copyright IBM Corp. 1997, 2017 4-78

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Task 2. Configure a database connection to the Db2 database

MUSICDB from Data Server Manager.
You will create a database connection profile for the new database, MUSICDB, to be
used by the Data Server Manager tool.
The IBM Data Server Manager tool, referred to as DSM, was installed on the class
system to provide a simple graphical interface to manage the Db2 database server.
Access to DSM is through a Web Browser. When the software was installed, a tcpip
port number was associated with the DSM service, 11080. Use the Firefox browser to
start the DSM application.
Open a Firefox Browser and select Bookmarks > Bookmarks Toolbar > Log in: IBM
Data Server Manager. Alternatively, you could type the following URL text to start
DSM, [Link]
When DSM was installed, a local user id and password were selected to be associated
with the application. For this course the following were configured:
Linux System user id: db2admin
User password: ibm2blue
Use this userid and password to logon to DSM.
1. On the left side of the DSM application, click Settings >
Manage Connections.
2. On the right, under Database Connection, click Add > Add a database
3. In the Add Database Connection window, make the following entries, scrolling
to access all fields, if required:
• Database connection name: MUSICDB
• Database name: MUSICDB
• Host name: ibmclass
• Port number: 50004 (Use the port number in the DBM configuration)
• Leave other options with the default values
4. Select the boxes labeled Enable operation and Enable data collection.
5. Click on *Credential, make the following entries for both the Operation
credentials and also the Data collecting credentials:
• User ID: inst23
• Password: ibm2blue
• Click on the box to Save credentials to repository

© Copyright IBM Corp. 1997, 2017 4-79

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

6. Scroll to the bottom, click Test Connection for each user/password

combination and wait for the response: 'The connection to MUSICDB was
successful'. Click OK.
7. Click OK to complete the connection.
Task 3. Change default database configuration options for the
new database MUSICDB.
The database creation sets configuration options to default values or automatically
configured values. You can make adjustments to these values to better match the
intended usage of the database.
At this point, you may choose to make database configuration changes using the
UPDATE DB CFG command using the Db2 command line processor or the Data
Server Manager tool. Follow the steps for your chosen tool only.
You will reconfigure the number of primary (Initial) and secondary (Additional) database
log files for the database.
3A. Use the Db2 command line processor.
1. Enter the following commands using the Linux terminal session.
• db2 connect to musicdb
• db2 update db cfg using logprimary 5 logsecond 10
The response includes the warning message SQL1363W, indicating that one or
more changes will not take effect until the database is restarted. In this case, the
LOGPRIMARY option cannot be changed dynamically.
• db2 get db cfg show detail | more
2. You can now skip to Task 4.

© Copyright IBM Corp. 1997, 2017 4-80

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

3B. Use the Data Server Manager tool.

You can use the DSM tool to review and make changes to the database configuration.
If you have not started the DSM application, start it now using the Firefox bookmark or
the URL http//localhost:11080. Use the following user and password for DSM:
Linux System user id: db2admin
User password: ibm2blue
Some database configuration changes can take effect immediately, while others
will require the database to be restarted.
1. Click Home on the left side of the DSM application.
The database name MUSICDB provides a drop down list to perform different
tasks.
2. Select Administer - Database from the drop-down list of the MUSICDB
database.
You may be prompted for a userid and password for the MUSICDB database
connection, use inst23 with a password of ibm2blue.
3. In the middle, under MUSICDB, click Configuration parameters.
4. In the DBCFG tab, expand Logging. (You may need to scroll to see it.)
5. Scroll down the list of logging related configuration options to locate
LOGPRIMARY and LOGSECOND. Make the following changes by entering
new values in the column Pending Value:
• LOGPRIMARY: 5
• LOGSECOND: 10 ; clear the Immediate checkbox.
The DSM tool generates a CALL for the ADMIN_CMD procedure with an
UPDATE DB CFG command to make these changes. The deferred option is
added to the command.
6. At the bottom, click Run.
Wait for the command to be processed (this may take several seconds).
The result should show that the command processing succeeded.

© Copyright IBM Corp. 1997, 2017 4-81

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Task 4. Create a new storage group to support

application storage.
The CREATE DATABASE command created one storage group, IBMSTOGROUP.
You will create a new storage group to support several of the automatic storage table
spaces.
The file $HOME/ddl/create_stogroup.ddl contains the CREATE STOGROUP
statement. The file contains the following statement text:
CREATE STOGROUP app_data ON '/dbauto/path2';
At this point, you may choose to create the storage group using the Db2 command line
processor or the Data Server Manager tool. Follow the steps for your chosen tool only.
4A. Use the Db2 command line processor.
7. Issue the following series of commands using the Db2 command line processor.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_stogroup.ddl
The db2pd command can be used to list the storage groups for an active
database.
• db2pd -db musicdb –storage
The output from this command will look similar to the following:
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] --
Date 2016-06-29-11.25.42.689263

Storage Group Configuration:

Address SGID Default DataTag Name
0x00007F5FAF281D80 0 Yes 0 IBMSTOGROUP
0x00007F5FD04A7000 1 No 0 APP_DATA

Storage Group Statistics:

Address SGID State Numpaths NumDropPen
0x00007F5FAF281D80 0 0x00000000 1 0
0x00007F5FD04A7000 1 0x00000000 1 0

Storage Group Paths:

Address SGID PathID PathState PathName
0x00007F5FAF2AF000 0 0 InUse /dbauto/path1
0x00007F5FD04A8000 1 1024 NotInUse /dbauto/path2
8. You can now skip to Task 5.

© Copyright IBM Corp. 1997, 2017 4-82

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

4B. Use the Data Server Manager tool.

You can use the DSM tool to create the new storage group.
1. Click the Home option on the left side of the DSM application.
You should see the database MUSICDB listed. The database name MUSICDB
provides a drop down list to perform different tasks.
2. Select Administer - Database from the drop down list of the MUSICDB
database.
If you are prompted for a userid and password for the MUSICDB database
connection; use inst23 with a password of ibm2blue.
3. Click Administer > Storage Objects > Storage Groups.
The storage group IBMSTOGROUP is the default storage group defined when
the database was created.
4. At the top left corner, click Create to open a list of options to define a new
storage group.
Enter the following values for the new storage group:
• Storage group name: APP_DATA
• Default storage group: NO
• Storage paths: /dbauto/path2
The DSM tool generates the CREATE STOGROUP statement that will define
the new storage group named APP_DATA, with one new path. Click on the +
next to Command to see the generated Db2 command text.
The command text should appear as follows:
CREATE STOGROUP APP_DATA ON '/dbauto/path2';
5. Select Run.
6. Wait for the command to be processed.
The result should show that the command processing succeeded.

© Copyright IBM Corp. 1997, 2017 4-83

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Task 5. Create a new tablespace to support application

objects.
You will create a new table space that has the following attributes:
• Table space name: TSP01
• Table Space Type: Large
• Buffer Pool: IBMDEFAULTBP (which is also the default)
• Table Space management: Automatic_Storage
• Storage group: APP_DATA
• Initial size: 1MB (256 4 KB pages)
• Container: File
• Table space extent size: 4
• AUTORESIZE:increase the size by 100 KB when more disk storage is needed.
• No maximum size will be specified.
At this point, you may choose to create the table space TSP01 using the Db2 command
line processor or the Data Server Manager tool. Follow the steps for your chosen tool
only.
5A. Use the Db2 command line processor.
The file $HOME/ddl/create_tablespace_tsp01.ddl contains the CREATE
TABLESPACE statement. The file contains the following statement text:
CREATE TABLESPACE TSP01 using stogroup APP_DATA
INITIALSIZE 1M INCREASESIZE 100 K
EXTENTSIZE 4 ;
1. Issue the following series of commands using the Db2 command line processor.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_tablespace_tsp01.ddl
The db2pd command can be used to list the tablespaces for an active
database.
• db2pd -db musicdb -tablespaces | more
2. You can now skip to Task 6.

© Copyright IBM Corp. 1997, 2017 4-84

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

5B. Use the Data Server Manager tool.

You can use the DSM tool to create the new tablespace, TSP01.
1. Select Administer > Storage Objects > Table Spaces. The system created
table spaces will be listed.
2. At the top left corner, click Create to open a list of options to define a new table
space. Enter the following values for the table space:
• Name: TSP01 (Use uppercase text)
• Accept the default values for Type of Data, Managed By, Buffer Pool and
Database partition Group.
• Storage group name: APP_DATA
• Extent size: 4
• Initial size: 1 M
• Increase size: 100 K
The DSM tool generates the CREATE TABLESPACE statement that will define
the new table space named TSP01. Click on the + next to Command to see the
generated Db2 command text.
The command text should be similar to the following:
CREATE TABLESPACE TSP01 MANAGED BY AUTOMATIC STORAGE
USING STOGROUP APP_DATA AUTORESIZE YES
INITIALSIZE 1 M INCREASESIZE 100 K
EXTENTSIZE 4
3. Click Run.
Wait for the command to be processed.
The result should show that the command processing succeeded.
4. If you refresh the Table Spaces list, you should see the new tablespace, TSP01
included in the list.

© Copyright IBM Corp. 1997, 2017 4-85

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Task 6. Create a set of new table spaces using a SQL file.

You will create a group of table spaces using a SQL file containing the CREATE
TABLESPACE statements.
The file $HOME/ddl/create_tablespaces.ddl contains five CREATE
TABLESPACE statements.
The file contains the following statement text:
create tablespace tsp02
managed by database
using (file 'tsp02' 128)
extentsize 2 autoresize yes maxsize 2 M;

create tablespace tsp03

managed by database
using (file 'tsp03' 1024)
extentsize 8 autoresize yes maxsize 10 M ;

create tablespace tsp04

managed by automatic storage using stogroup app_data
initialsize 100 K maxsize none
extentsize 2;

create tablespace tsp05 using stogroup app_data

initialsize 64 K maxsize 1 M
extentsize 2;

create regular tablespace tsp06

extentsize 4;
At this point, you may choose to create the table spaces using the Db2
command line processor or the Data Server Manager tool. Follow the steps for
your chosen tool only.

© Copyright IBM Corp. 1997, 2017 4-86

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

6A. Use the Db2 command line processor.

1. Issue the following series of commands using the Db2 command line processor.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_tablespaces.ddl
The LIST TABLESPACES command can be used to list the tablespaces for an
active database.
• db2 list tablespaces | more
2. You can now skip to Task 7.
6B. Use the Data Server Manager tool.
You can use the DSM tool to execute the SQL file containing the
CREATE TABLESPACE statements.
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/create_tablespaces.ddl.
3. Click Open.
4. Click OK to complete loading of the SQL text into the SQL editor.
Review the options specified for the five CREATE TABLESPACE statements.
5. Click Run > Run All, and then wait for the five SQL statements to be
processed.
The result should show that all five statements succeeded. You may click on
Log under VIEW RESULTS to review each statement execution.

© Copyright IBM Corp. 1997, 2017 4-87

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Task 7. Use Db2 commands and SQL queries to show table

space related information.
You can use Db2 commands, such as db2pd, and SQL queries to retrieve information
about the table spaces in a Db2 database.
The file [Link] uses a Db2 system view [Link] which shows
the disk paths currently used by a database.
The Db2 system catalog views can be used to list information about data objects, such
as table spaces. The view [Link] contains table space attributes.
Use the file select_tablespaces.sql to query information using this catalog view. The
selected fields that contain table space information are:
• TBSPACE: Name of primary table space for this table.
• DEFINER: Authid of table space creator.
• TBSPACEID: Internal table space identifier.
• TBSPACETYPE: Type of table space. D for DMS or S for SMS.
• DATATYPE: Type of data that can be stored in the table space. L for large table
spaces, A for Regular table spaces, or T for temporary table spaces.
• SGNAME: The storage group name for automatic storage table spaces.
Note: Using this view, table spaces managed by Automatic Storage will appear as DMS
for regular and large table spaces and SMS for temporary table spaces.
At this point, you may choose to execute the commands and SQL statements using the
Db2 command line processor or the Data Server Manager tool. Follow the steps for
your chosen tool only.

© Copyright IBM Corp. 1997, 2017 4-88

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

7A. Use the Db2 command line processor.

1. Issue the following series of commands using the Db2 command line processor.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf select_tablespaces.sql
The output from this command will look similar to the following:
select substr(tbspace,1,18) as tbspace,
substr(definer,1,10) as definer, tbspaceid, tbspacetype, datatype, sgname
from [Link]

TBSPACE DEFINER TBSPACEID TBSPACETYPE DATATYPE SGNAME

------------------ ---------- ----------- ----------- -------- ------------
SYSCATSPACE SYSIBM 0 D A IBMSTOGROUP
TEMPSPACE1 SYSIBM 1 S T IBMSTOGROUP
USERSPACE1 SYSIBM 2 D L IBMSTOGROUP
SYSTOOLSPACE SYSTEM 3 D L IBMSTOGROUP
TSP01 INST23 4 D L APP_DATA
TSP02 INST23 5 D L -
TSP03 INST23 6 D L -
TSP04 INST23 7 D L APP_DATA
TSP05 INST23 8 D L APP_DATA
TSP06 INST23 9 D A IBMSTOGROUP

10 record(s) selected.
Notice that the DMS managed tablespaces do not have an assigned storage
group. Each tablespace is assigned a unique tablespace ID by Db2.

© Copyright IBM Corp. 1997, 2017 4-89

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• db2 -tvf select_mon_get_cont.sql

The output from this command will look similar to the following:

select varchar(container_name, 80) as container_name,

varchar(tbsp_name, 20) as tbsp_name,
pool_read_time
from table(mon_get_container('', -2)) as t
order by tbsp_id

CONTAINER_NAME
TBSP_NAME POOL_READ_TIME
-------------------------------------------------------------------------------- -
------------------- --------------------
/dbauto/path1/inst23/NODE0000/MUSICDB/T0000000/[Link]
SYSCATSPACE 1123
/dbauto/path1/inst23/NODE0000/MUSICDB/T0000001/[Link]
TEMPSPACE1 0
/dbauto/path1/inst23/NODE0000/MUSICDB/T0000002/[Link]
USERSPACE1 1
/dbauto/path1/inst23/NODE0000/MUSICDB/T0000003/[Link]
SYSTOOLSPACE 37
/dbauto/path2/inst23/NODE0000/MUSICDB/T0000004/[Link]
TSP01 13
/database/inst23/NODE0000/SQL00001/tsp02
TSP02 42
/database/inst23/NODE0000/SQL00001/tsp03
TSP03 1
/dbauto/path2/inst23/NODE0000/MUSICDB/T0000007/[Link]
TSP04 15
/dbauto/path2/inst23/NODE0000/MUSICDB/T0000008/[Link]
TSP05 23
/dbauto/path1/inst23/NODE0000/MUSICDB/T0000009/[Link]
TSP06

10 record(s) selected.

Notice that the tablespaces using the APP_DATA storage group use a different
path from those in the default storage group.

© Copyright IBM Corp. 1997, 2017 4-90

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

• db2 -tvf [Link]

The output from this command will look similar to the following:
select substr(type,1,30) as db_path_type,
substr(path,1,50) as path_name
from [Link] order by 1

DB_PATH_TYPE PATH_NAME
------------------------------ --------------------------------------------
------
DBPATH /database/inst23/NODE0000/SQL00001/
DBPATH
/database/inst23/NODE0000/SQL00001/MEMBER0000/
DB_STORAGE_PATH /dbauto/path2/
DB_STORAGE_PATH /dbauto/path1/
LOCAL_DB_DIRECTORY /database/inst23/NODE0000/sqldbdir/
LOGPATH
/database/inst23/NODE0000/SQL00001/LOGSTREAM0000/
TBSP_CONTAINER /database/inst23/NODE0000/SQL00001/tsp03
TBSP_CONTAINER /database/inst23/NODE0000/SQL00001/tsp02

The result shows the disk locations that contain the components of the
database, including the log files, database control files and tablespace storage.
• db2pd -db musicdb -storage | more
The output from this command will look similar to the following:
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] --
Date 2016-06-29-11.25.42.689263

Storage Group Configuration:

Address SGID Default DataTag Name
0x00007F5FAF281D80 0 Yes 0 IBMSTOGROUP
0x00007F5FD04A7000 1 No 0 APP_DATA

Storage Group Statistics:

Address SGID State Numpaths NumDropPen
0x00007F5FAF281D80 0 0x00000000 1 0
0x00007F5FD04A7000 1 0x00000000 1 0

Storage Group Paths:

Address SGID PathID PathState PathName
0x00007F5FAF2AF000 0 0 InUse /dbauto/path1
0x00007F5FD04A8000 1 1024 InUse /dbauto/path2

© Copyright IBM Corp. 1997, 2017 4-91

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

The db2pd command report provides information about the two storage groups
currently defined for the MUSICDB database.
• db2pd -db musicdb -tablespaces | more
The output from this command will look similar to the following:
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] --
Date 2016-06-29-11.28.28.845978

Tablespace Configuration:
Address Id Type Content PageSz ExtentSz Auto Prefetch BufID
BufIDDisk FSC NumCntrs MaxStripe LastConsecPg RSE Name
0x00007F5FB49EAD40 0 DMS Regular 4096 4 Yes 4 1 1
Def 1 0 3 Yes SYSCATSPACE
0x00007F5FB49F8100 1 SMS SysTmp 4096 32 Yes 32 1 1
On 1 0 31 No TEMPSPACE1
0x00007F5FB4A054C0 2 DMS Large 4096 32 Yes 32 1 1
Def 1 0 31 Yes USERSPACE1
0x00007F5FB4A12880 3 DMS Large 4096 4 Yes 4 1 1
Def 1 0 3 Yes SYSTOOLSPACE
0x00007F5FD0E91740 4 DMS Large 4096 4 Yes 4 1 1
Def 1 0 3 Yes TSP01
0x00007F5FD0EA7360 5 DMS Large 4096 2 Yes 2 1 1
Def 1 0 1 Yes TSP02
0x00007F5FD0EB6EA0 6 DMS Large 4096 8 Yes 8 1 1
Def 1 0 7 Yes TSP03
0x00007F5FD0EC69A0 7 DMS Large 4096 2 Yes 2 1 1
Def 1 0 1 Yes TSP04
0x00007F5FD0ED6520 8 DMS Large 4096 2 Yes 2 1 1
Def 1 0 1 Yes TSP05
0x00007F5FD0EE6020 9 DMS Regular 4096 4 Yes 4 1 1
Def 1 0 3 Yes TSP06

Tablespace Statistics:
Address Id TotalPgs UsablePgs UsedPgs PndFreePgs
FreePgs HWM Max HWM State MinRecTime NQuiescers
PathsDropped TrackmodState
0x00007F5FB49EAD40 0 32768 32764 27496 0 5268
27496 27496 0x00000000 0 0 No n/a
0x00007F5FB49F8100 1 1 1 1 0 0
- - 0x00000000 0 0 No n/a
0x00007F5FB4A054C0 2 8192 8160 96 0 8064
96 96 0x00000000 0 0 No n/a
0x00007F5FB4A12880 3 8192 8188 144 0 8044
144 144 0x00000000 0 0 No n/a
0x00007F5FD0E91740 4 256 252 12 0 240
12 12 0x00000000 0 0 No n/a

© Copyright IBM Corp. 1997, 2017 4-92

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

0x00007F5FD0EA7360 5 128 126 6 0 120

6 6 0x00000000 0 0 No n/a
0x00007F5FD0EB6EA0 6 1024 1016 24 0 992
24 24 0x00000000 0 0 No n/a
0x00007F5FD0EC69A0 7 26 24 6 0 18
6 6 0x00000000 0 0 No n/a
0x00007F5FD0ED6520 8 16 14 6 0 8
6 6 0x00000000 0 0 No n/a
0x00007F5FD0EE6020 9 8192 8188 12 0 8176
12 12 0x00000000 0 0 No n/a

Tablespace Autoresize Statistics:

Address Id AS AR InitSize IncSize
IIP MaxSize LastResize LRF
0x00007F5FB49EAD40 0 Yes Yes 33554432 -1
No None None No
0x00007F5FB49F8100 1 Yes No 0 0
No 0 None No
0x00007F5FB4A054C0 2 Yes Yes 33554432 -1
No None None No
0x00007F5FB4A12880 3 Yes Yes 33554432 -1
No None None No
0x00007F5FD0E91740 4 Yes Yes 1048576 102400
No None None No
0x00007F5FD0EA7360 5 No Yes -4096 -1
No 2097152 None No
0x00007F5FD0EB6EA0 6 No Yes -4096 -1
No 10485760 None No
0x00007F5FD0EC69A0 7 Yes Yes 102400 -1
No None None No
0x00007F5FD0ED6520 8 Yes Yes 65536 -1
No 1048576 None No
0x00007F5FD0EE6020 9 Yes Yes 33554432 -1
No None None No

Tablespace Storage Statistics:

Address Id DataTag Rebalance SGID SourceSGID
0x00007F5FB49EAD40 0 0 No 0 -
0x00007F5FB49F8100 1 0 No 0 -
0x00007F5FB4A054C0 2 -1 No 0 -
0x00007F5FB4A12880 3 -1 No 0 -
0x00007F5FD0E91740 4 -1 No 1 -
0x00007F5FD0EA7360 5 0 No - -
0x00007F5FD0EB6EA0 6 0 No - -
0x00007F5FD0EC69A0 7 -1 No 1 -
0x00007F5FD0ED6520 8 -1 No 1 -
0x00007F5FD0EE6020 9 -1 No 0 -

© Copyright IBM Corp. 1997, 2017 4-93

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Containers:
Address TspId ContainNum Type TotalPgs UseablePgs PathID
StripeSet Container
0x00007F5FB49E3520 0 0 File 32768 32764 0
0 /dbauto/path1/inst23/NODE0000/MUSICDB/T0000000/[Link]
0x00007F5FB4A20000 1 0 Path 1 1 0
0 /dbauto/path1/inst23/NODE0000/MUSICDB/T0000001/[Link]
0x00007F5FB49E4580 2 0 File 8192 8160 0
0 /dbauto/path1/inst23/NODE0000/MUSICDB/T0000002/[Link]
0x00007F5FB49E4D20 3 0 File 8192 8188 0
0 /dbauto/path1/inst23/NODE0000/MUSICDB/T0000003/[Link]
0x00007F5FD0E9F000 4 0 File 256 252 1024
0 /dbauto/path2/inst23/NODE0000/MUSICDB/T0000004/[Link]
0x00007F5FD0EB5B00 5 0 File 128 126 -
0 /database/inst23/NODE0000/SQL00001/tsp02
0x00007F5FD0EC5640 6 0 File 1024 1016 -
0 /database/inst23/NODE0000/SQL00001/tsp03
0x00007F5FD0ED6000 7 0 File 26 24 1024
0 /dbauto/path2/inst23/NODE0000/MUSICDB/T0000007/[Link]
0x00007F5FD0EE5000 8 0 File 16 14 1024
0 /dbauto/path2/inst23/NODE0000/MUSICDB/T0000008/[Link]
0x00007F5FD0EF5000 9 0 File 8192 8188 0
0 /dbauto/path1/inst23/NODE0000/MUSICDB/T0000009/[Link]

The db2pd command report provides information about the tablespaces for the
MUSICDB database, including disk space usage, container assignments and
storage group usage.
2. You can now skip to the end of this demonstration.
7B. Use the Data Server Manager tool.
You can use the DSM tool to execute the SQL file containing the SQL query.
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Manually remove any SQL statements before you upload any new SQL.
3. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/select_tablespaces.sql.
4. Click Open.
5. Click on OK to complete loading the SQL text into the SQL editor.
Review the SQL query text.

© Copyright IBM Corp. 1997, 2017 4-94

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

6. Click Run All, and then wait for the SQL statement to be processed.
The result should show that the SQL statement succeeded. The result also
contains the query result in a columnar report.
7. Click on Result Set under View Results to review the report.
You will now utilize the SQL query text in the file
inst23/ddl/select_mon_get_tbsp.sql to retrieve table space information and
statistics.
8. Manually remove any SQL statements before you upload any new SQL.
9. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file
inst23/ddl/select_mon_get_tbsp.sql.
10. Click Open.
11. Click on OK to complete loading the SQL text into the SQL editor.
Review the SQL query text.
12. Click Run All, and then wait for the SQL statement to be processed.
The result should show that the SQL statement succeeded. The result also
contains the query result in a columnar report.
13. Click on Result Set under View Results to review the report.
Notice that the two DMS managed table spaces, TSP02 and TSP03, do not
have a storage group, since storage groups only apply to automatic storage
managed table spaces.
You will now utilize the SQL query text in the file
inst23/ddl/select_mon_get_cont.sql to retrieve a list of disk containers for
each table space in the database.
14. Manually remove any SQL statements before you upload any new SQL.
15. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file
inst23/ddl/select_mon_get_cont.sql.
16. Click Open.
17. Click on OK to complete loading the SQL text into the SQL editor.
Review the SQL query text.

© Copyright IBM Corp. 1997, 2017 4-95

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

18. Click Run All, and then wait for the SQL statement to be processed.
The result should show that the SQL statement succeeded. The result also
contains the query result in a columnar report.
19. Click on Result Set under View Results to review the report.
Use the SQL query text in the file inst23/ddl/[Link] to retrieve information
about the disk paths used to support components of this database.
20. Manually remove any SQL statements before you upload any new SQL.
21. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/[Link].
22. Click Open.
23. Click on OK to complete loading the SQL text into the SQL editor.
Review the SQL query text.
24. Click Run All, and then wait for the SQL statement to be processed.
The result should show that the SQL statement succeeded. The result also
contains the query result in a columnar report.
25. Click on Result Set under View Results to review the report.
The query result shows the disk locations that contain the components of the
database, including the log files, database control files and tablespace storage.
Results:
You created a new Db2 database named MUSICDB that will support the
database objects that you will create and manage in the following
demonstrations. You created a new storage group and a set of table spaces.
You used Db2 commands and SQL queries to investigate database storage.

© Copyright IBM Corp. 1997, 2017 4-96

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

Unit summary
• Plan the initial storage allocations for a database including catalog
tables and log files
• Create a new database using Db2 native encryption
• Explore the System Catalog tables and views
• Check and update Database configuration parameter settings
• Compare DMS and Automatic Storage management for table spaces
• Describe how to setup and manage a Db2 database with Automatic
Storage enabled
• Define Storage Groups to manage databases with different classes of
storage available
• Differentiate between table spaces, containers, extents, and pages
• Create and alter table spaces
• Use Db2 commands and SQL statements to display current table
space statistics and status information

Creating databases and data placement © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 4-97

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 4 Creating databases and data placement

© Copyright IBM Corp. 1997, 2017 4-98

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Creating database objects

Creating database objects

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 5 Creating database objects

© Copyright IBM Corp. 1997, 2017 5-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Unit objectives
• Describe the Db2 object hierarchy
• Create the following objects:
 Schema, Table, View, Alias, Index
• Review the use of temporary tables
• Explore the use and implementation of check constraints, referential
integrity and triggers
• Utilize BLU Acceleration, column-organized tables to improve analytics
query performance
• Explain the difference between system-period temporal tables and
Application-period temporal tables
• List the types of compression available for tables and indexes
• Use the db2look utility to export database structures for future use

Creating database objects © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 5-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Db2 object hierarchy

Instance 1 dbm configuration file

SYSCATSPACE
DB configuration file
Log Catalog
View1
Database 1 Log Database 2
View2
STOGRP1
TSAS1 TSDMSLRG1 SYSCATSPACE
Table1
Table4 Table3
Catalog

Index1 View1
TSDMSREG2

Index31
TSAS2 TSDMSLRG3 USERSPACE1

Table2 BLOBs Table2

Index32

Index2 IBMSTOGROUP

Creating database objects © Copyright IBM Corporation 2017

Db2 object hierarchy

Each Db2 instance has its own database manager configuration file. Its global
parameters affect the system resources allocated to Db2 for an individual instance. Its
parameters can be changed from the system default values to improve performance or
increase capacity, depending on the workstation configuration.
Each instance might have multiple databases. A relational database presents data as a
collection of tables. A table consists of a defined number of columns and any number of
rows. Each database includes a set of system catalog tables, which describe the logical
and physical structure of the data (like a table or view), or contain statistics of the data
distribution; a configuration file containing the parameter values allocated for the
database; and a recovery log with ongoing transactions and archival transactions.
Each table might have multiple indexes. Indexes might provide a faster way to access
table data. Each table might have multiple views. Views might be associated with more
than one base table.
The physical objects in a database are assigned to table spaces. When creating a
table, you can decide to have certain objects such as indexes and large object (LOB)
data kept separately from the rest of the table data. By default, all objects referencing a
table reside in the same table space where the table itself resides. A table space can
also be spread over one or more physical storage devices.

© Copyright IBM Corp. 1997, 2017 5-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

In the visual, two databases are shown.

For Database 1:
• The system catalog tables are in table space SYSCATSPACE.
• One storage group named STOGRP1 is defined which supports two table
spaces, TSAS1 and TSAS2.
• Table 1 and its one Index are in a automatic storage table space named TSAS1.
• Table 2 and its one Index are in a automatic storage table space named TSAS2.
• Tables 3 and Table 4 are both assigned to the Large DMS table space
TSDMSLRG1.
• Two Indexes for Table 3 are assigned to the Regular table space TSDMSREG2.
• The Large Object data or XML columns from Table 3 are assigned to the Large
table space TSDMSLRG3.
For Database 2:
• The system catalog tables are in table space SYSCATSPACE.
• The default storage group IBMSTOGROUP supports the two default table
spaces, SYSCATSPACE and USERSPACE1
• Table 2 is assigned to the automatic storage table space USERSPACE1.

© Copyright IBM Corp. 1997, 2017 5-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

CREATE SCHEMA
• A schema is a collection of named objects
• A schema is also a name qualifier
• The schema names 'INTERNAL' and 'EXTERNAL' make it easy to distinguish two
different SALES tables ([Link], [Link]).
• The schema name provides a way to group those objects logically, providing a way
to use the same natural name for several objects, and to prevent ambiguous
references to those objects.
• Schemas also enable multiple applications to store data in a single database without
encountering namespace collisions.
• A schema can contain tables, views, nicknames, triggers, functions, packages, and
other objects.
• A schema is itself a database object.
• The schema can be explicitly created using the CREATE SCHEMA statement, with
the current user or a specified authorization ID recorded as the schema owner.
CREATE SCHEMA PAYROLL
AUTHORIZATION DB2ADMIN DATA CAPTURE NONE ;

• A schema may also be implicitly created when another object is created, if the user
has IMPLICIT_SCHEMA authority
• A schema can be used to set a default DATA CAPTURE option for objects
Creating database objects © Copyright IBM Corporation 2017

CREATE SCHEMA
When the schema is explicitly created with the CREATE SCHEMA statement, the
schema owner is granted CREATEIN, DROPIN, ALTERIN privileges on the schema
with the ability to grant these privileges to other users.
A schema name or authorization name cannot begin with SYS.
While organizing your data into tables, it might also be beneficial to group tables (and
other related objects) together. This is done by defining a schema. Information about
the schema is kept in the system catalog tables of the database to which you are
connected. As other objects are created, they can be placed within this schema.
An authorization ID that holds DBADM authority can create a schema with any valid
schema name or authorization name. Any ID can explicitly create a schema that
matches the authorization ID of the statement.
When the schema is explicitly created with the CREATE SCHEMA statement, the
schema owner is granted CREATEIN, DROPIN, ALTERIN, GRANTIN privileges on the
schema with ability to grant to other users.
You can create a schema and include certain SQL statements with it (CREATE TABLE,
excluding typed tables and materialized query tables; CREATE VIEW statement,
excluding typed views; CREATE INDEX statement; COMMENT statement; GRANT
statement).

© Copyright IBM Corp. 1997, 2017 5-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

For example, the following is a single statement:

CREATE SCHEMA pers
CREATE TABLE ORG (
deptnumb SMALLINT NOT NULL,
deptname VARCHAR(14),
manager SMALLINT,
division VARCHAR(10),
location VARCHAR(13),
CONSTRAINT pkeydno PRIMARY KEY (deptnumb),
CONSTRAINT fkeymgr FOREIGN KEY (manager)
REFERENCES staff (id)
)
CREATE TABLE STAFF (
id SMALLINT NOT NULL,
name VARCHAR(9),
dept SMALLINT,
job VARCHAR(5),
years SMALLINT,
salary DECIMAL(7,2),
comm DECIMAL(7,2),
CONSTRAINT pkeyid PRIMARY KEY (id),
CONSTRAINT fkeydno FOREIGN KEY (dept)
REFERENCES org (deptnumb)
)
Thus, you can use a single statement to create two tables that are dependent on each
other, rather than having to create the first with Primary Key, the second with Primary
and Foreign Key, and then alter the first to add Foreign Key.
Unqualified object names in any SQL statement within the CREATE SCHEMA
statement are implicitly qualified by the name of the created schema.
Starting with Db2 10.1, you can use the DATA CAPTURE attribute with the CREATE
SCHEMA statement or set the dft_schemas_dcc database configuration parameter to
ON, to have all subsequently created tables inherit the DATA CAPTURE CHANGES
property.

© Copyright IBM Corp. 1997, 2017 5-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Set current schema

• Select from [Link]:
connect to musicdb user Keith;
select * from employee;

• Select from [Link]

set current schema = 'PAYROLL‘;
select * from employee;

Creating database objects © Copyright IBM Corporation 2017

Set current schema

When accessing data within Db2, unqualified references will be implicitly qualified with
the authorization ID that was used to connect to the database. You can override this by
setting the CURRENT SCHEMA. The initial value of the CURRENT SCHEMA special
register is equivalent to USER.
The example on the graphic shows that a user KEITH is connecting to the database. If
Keith issues a select against the EMPLOYEE table, the table that will be accessed will
be [Link]. If he sets his current schema to PAYROLL, then a select
against the EMPLOYEE table will be directed against the [Link] table.
Alternative syntax includes:
SET CURRENT SCHEMA = 'PAYROLL'
SET SCHEMA 'PAYROLL'
SET CURRENT SQLID 'PAYROLL'
Note that the use of the = is optional in all of these statements.
The value of the CURRENT SCHEMA special register is used as the schema name in
all dynamic SQL statements where an unqualified reference to a database object exists.

© Copyright IBM Corp. 1997, 2017 5-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Using the Create Table statement

connect to musicdb;
create table artists
(artno smallint not null,
name varchar(50) with default 'abc',
classification char(1) not null,
bio clob(100K) logged,
picture blob( 10M) not logged compact)

in dms01
index in dms02
long in dms03;

Creating database objects © Copyright IBM Corporation 2017

Using the Create Table statement

A table consists of data logically arranged in columns and rows. Db2 supports page
sizes of 4, 8, 16, and 32 KB. The number of columns, maximum row length, and
maximum table size vary by page size.
Regular table spaces use a 4-byte Row ID, which allows 16 million pages with up to
255 rows per page. Automatic storage and DMS-managed table spaces can be either
Regular or Large table spaces. Large table spaces use a 6-byte Row ID, and can store
up to 64TB of data.
A table with a 4K page could be as large as 64 GB in a regular table space or 8
Terabytes in a Large table space. Using a 32K page size would allow a table in a
Regular table space to be as large as 512GB or 64TB in a Large table space.
Tables are created using the SQL statement CREATE TABLE.
If no schema name is supplied with the table name, the value of the CURRENT
SCHEMA special register is used as the schema name.

© Copyright IBM Corp. 1997, 2017 5-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Table design concepts

When designing tables, you must be familiar with some related concepts.
Data types and table columns
When you create your table, you must indicate what type of data each column will
store. By thinking carefully about the nature of the data you are going to be managing,
you can set your tables up in a way that will give you optimal query performance,
minimize physical storage requirements, and provide you with specialized capabilities
for manipulating different kinds of data, such as arithmetic operations for numeric data,
or comparing date or time values to one another.
Generated columns
A generated column is defined in a table where the stored value is computed using an
expression, rather than being specified through an insert or update operation.
Hidden columns
When a table column is defined with the implicitly hidden attribute, that column is
unavailable unless it is explicitly referenced. For example, if a SELECT * query is run
against a table, implicitly hidden columns are not returned in the result table. An
implicitly hidden column can always be referenced explicitly wherever a column name
can be specified.
Auto numbering and identifier columns
An identity column provides a way for Db2 to automatically generate a unique numeric
value for each row that is added to the table.
Constraining column data with constraints, defaults, and null settings
Data often must adhere to certain restrictions or rules. Such restrictions might apply to
single pieces of information, such as the format and sequence numbers, or they might
apply to several pieces of information.
Primary key, referential integrity, check, and unique constraints
Constraints are rules that limit the values that can be inserted, deleted, or updated in a
table.
Unicode table and data considerations
The Unicode character encoding standard is a fixed-length, character encoding scheme
that includes characters from almost all of the living languages of the world.
For more information, refer to the SQL Reference manual.

© Copyright IBM Corp. 1997, 2017 5-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Application temporary tables

• Applications can utilize global temporary tables:
 Global temporary tables are stored in User temporary table spaces
 The associated data is deleted when the application connection ends
 Each connection accesses a private copy of the table, so it only sees data put
into the table by that one connection
 Normal table locking is not needed for global temporary tables since the data is
always limited to a single connection
 Declared Global Temporary table:
− These are defined during application execution using the
DECLARE GLOBAL TEMPORARY TABLE statement
− No Db2 Catalog information is required
− The schema for a declared global temporary table is always ‘SESSION’
 Created Global Temporary table:
− These are defined using a CREATE GLOBAL TEMPORARY TABLE statement with a
user selected schema
− The table and any associated indexes can be created before an application connection
starts, but only the catalog definition exists
− The catalog definition is used when the application references the table
− Each application connection still works only with the data it stores in the table
Creating database objects © Copyright IBM Corporation 2017

Application temporary tables

A declared temporary table is a temporary table that is only accessible to SQL
statements that are issued by the application which created the temporary table. A
declared temporary table does not persist beyond the duration of the connection of the
application to the database.
Use declared temporary tables to potentially improve the performance of your
applications. When you create a declared temporary table, Db2 does not insert an entry
into the system catalog tables, and, therefore, your server does not suffer from catalog
contention issues. In comparison to regular tables, Db2 does not lock declared
temporary tables or their rows. If your current application creates tables to process large
amounts of data and drops those tables once the application has finished manipulating
that data, consider using declared temporary tables instead of regular tables.

© Copyright IBM Corp. 1997, 2017 5-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

To use a declared temporary table, perform the following steps:

• Step 1: Ensure that a USER TEMPORARY TABLESPACE exists. If a USER
TEMPORARY TABLESPACE does not exist, issue a CREATE USER
TEMPORARY TABLESPACE statement. A USER TEMPORARY TABLESPACE
stores declared temporary tables. No user temporary table spaces exist when a
database is created. At least one user temporary table space should be created
with appropriate USE privileges to allow definition of declared temporary tables.
create user temporary tablespace usr_temp_ts managed by
system using ('c:\usrspace')
• Step 2: Issue a DECLARE GLOBAL TEMPORARY TABLE statement in your
application.
The definition on the graphic creates a user temporary table called T1. The user
temporary table is defined with columns that have exactly the same name and
description as the columns of the REAL_T1. The implicit definition only includes the
column name, data type, nullability characteristic, and column default value attributes.
All other column attributes including unique constraints, Foreign Key constraints,
triggers, and indexes are not defined. You can also specify column definitions as when
creating a persistent table. See the SQL Reference for more information.
If you specify a schema for your temporary table, it must be SESSION.

© Copyright IBM Corp. 1997, 2017 5-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Example of a declared temporary table

• A system administrator creates the user temporary table space
CREATE USER TEMPORARY TABLESPACE "USR_TEMP_TS"
PAGESIZE 4 K MANAGED BY AUTOMATIC STORAGE
BUFFERPOOL IBMDEFAULTBP ;
• The application uses SQL statements to declare and access the table
DECLARE GLOBAL TEMPORARY TABLE T1
LIKE REAL_T1
ON COMMIT DELETE ROWS
NOT LOGGED
IN USR_TEMP_TS;
INSERT INTO SESSION.T1
SELECT * FROM REAL_T1 WHERE DEPTNO=:mydept;
• /* do other work on T1 */
• /* when connection ends, table is automatically dropped */

Creating database objects © Copyright IBM Corporation 2017

Example of a declared temporary table

The DECLARE GLOBAL TEMPORARY TABLE statement defines a temporary table for
the current session. The declared temporary table description does not appear in the
system catalog. It is not persistent and cannot be shared with other sessions. Each
session that defines a declared global temporary table of the same name has its own
unique description of the temporary table. When the session terminates, the rows of the
table are deleted, and the description of the temporary table is dropped.
The privileges held by the authorization ID of the statement must include at least one of
the following:
• USE privilege on the USER TEMPORARY table space
• DBADM authority
• SYSADM authority
• SYSCTRL authority
When defining a table using LIKE or a fullselect, the privileges held by the authorization
ID of the statement must also include at least one of the following on each identified
table or view:
• SELECT privilege on the table or view
• CONTROL privilege on the table or view
• DATAACCESS authority

© Copyright IBM Corp. 1997, 2017 5-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Example of a created temporary table

• A system administrator creates the user temporary table space and
defines a global temporary table and indexes
CREATE USER TEMPORARY TABLESPACE "USR_TEMP_TS2"
PAGESIZE 4 K MANAGED BY AUTOMATIC STORAGE ;

CREATE GLOBAL TEMPORARY TABLE [Link]

LIKE [Link]
ON COMMIT DELETE ROWS
NOT LOGGED IN USR_TEMP_TS2;

CREATE INDEX APP1.DEPTIX1 ON [Link] (DEPTNO);

• The application uses SQL statements to reference the temporary table;

no DECLARE is needed
INSERT INTO [Link]
SELECT * FROM [Link] WHERE DEPTNO=:mydept;

SELECT * FROM [Link] WHERE LASTNAME = ‘STOPFER’

Creating database objects © Copyright IBM Corporation 2017

Example of a created temporary table

The CREATE GLOBAL TEMPORARY TABLE statement creates a description of a
temporary table at the current server. Each session that selects from a created
temporary table retrieves only rows that the same session has inserted. When the
session terminates, the rows of the table associated with the session are deleted.
The privileges held by the authorization ID of the statement must include either DBADM
authority, or CREATETAB authority in combination with further authorization, as
described here:
One of the following privileges and authorities:
• USE privilege on the table space
• SYSADM
• SYSCTRL
• Plus one of these privileges and authorities:
• IMPLICIT_SCHEMA authority on the database, if the implicit or explicit
schema name of the table does not exist
• CREATEIN privilege on the schema, if the schema name of the table refers to
an existing schema

© Copyright IBM Corp. 1997, 2017 5-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

When defining a table using LIKE or a fullselect, the privileges held by the authorization
ID of the statement must also include at least one of the following on each identified
table or view:
• SELECT privilege on the table or view
• CONTROL privilege on the table or view
• DATAACCESS authority

© Copyright IBM Corp. 1997, 2017 5-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Table partitioning
• Data organization scheme in which table data is divided across
multiple storage objects called data partitions or ranges:
 Each data partition is stored separately
 These storage objects can be in different table spaces, in the same table
space, or a combination of both
• Benefits:
 Easier roll-in and roll-out of table data
 Allows large data roll-in (ATTACH) or roll-out (DETACH) with a minimal
impact to table availability for applications
 Supports very large tables
 Indexes can be either partitioned (local) or non-partitioned (global)
 Table and Index scans can use partition elimination when access includes
predicates for the defined ranges
 Different ranges can be assigned to table spaces in different storage groups
for current data versus less used historical data
Creating database objects © Copyright IBM Corporation 2017

Table partitioning
Partitioned tables use a data organization scheme in which table data is divided across
multiple storage objects, called data partitions or ranges, according to values in one or
more table partitioning key columns of the table.
A data partition or range is part of a table, containing a subset of rows of a table, and
stored separately from other sets of rows. Data from a given table is partitioned into
multiple data partitions or ranges based on the specifications provided in the
PARTITION BY clause of the CREATE TABLE statement. These data partitions or
ranges can be in different table spaces, in the same table space, or a combination of
both. If a table is created using the PARTITION BY clause, the table is partitioned.
All of the table spaces specified must have the same page size, extent size, storage
mechanism (DMS or SMS), and type (REGULAR or LARGE), and all of the table
spaces must be in the same database partition group.
A partitioned table simplifies the rolling in and rolling out of table data and a partitioned
table can contain vastly more data than an ordinary table. You can create a partitioned
table with a maximum of 32,767 data partitions. Data partitions can be added to,
attached to, and detached from a partitioned table, and you can store multiple data
partition ranges from a table in one table space.
Indexes on a partitioned table can be partitioned or non-partitioned. Both non-
partitioned and partitioned indexes can exist together on a single partitioned table.

© Copyright IBM Corp. 1997, 2017 5-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Example of a range partitioned table

• The PARTITION BY RANGE clause defines a set of data ranges
CREATE TABLE [Link] ( ACCT_ID INTEGER NOT NULL ,
TELLER_ID SMALLINT NOT NULL ,
BRANCH_ID SMALLINT NOT NULL ,
BALANCE DECIMAL(15,2) NOT NULL ,
……….
TEMP CHAR(6) NOT NULL )
PARTITION BY RANGE (BRANCH_ID)
(STARTING FROM (1) ENDING (20) IN TSHISTP1 INDEX IN TSHISTI1 ,
STARTING FROM (21) ENDING (40) IN TSHISTP2 INDEX IN TSHISTI2 ,
STARTING FROM (41) ENDING (60) IN TSHISTP3 INDEX IN TSHISTI3 ,
STARTING FROM (61) ENDING (80) IN TSHISTP4 INDEX IN TSHISTI4 ) ;

CREATE INDEX PARTTAB.HISTPIX1 ON [Link] (TELLER_ID)

PARTITIONED ;
CREATE INDEX PARTTAB.HISTPIX2 ON [Link] (BRANCH_ID)
PARTITIONED ;

• In this example, the data objects and index objects for each data range are stored
in different table spaces
• The table spaces used must be defined with the same options, such as type of
management, extent size and page size

Creating database objects © Copyright IBM Corporation 2017

Example of a range partitioned table

The example shows a range partitioned table based on one column, BRANCH_ID.
The CREATE TABLE statement lists four data partitions, each using one table space for
the data object and another table space for the partitioned indexes on this table.
Once defined, a range cannot be altered. New empty ranges can be added using the
ALTER TABLE ADD option. A new range with data already loaded can be added to the
table using the ALTER TABLE ATTACH statement. A range can be removed from the
table using the ALTER TABLE DETACH statement.

© Copyright IBM Corp. 1997, 2017 5-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

What is Db2 with BLU Acceleration?

• Large order of magnitude benefits for analytic query processing
 Performance
 Storage savings
 Time to value
• New technology in Db2 for analytic queries
 CPU-optimized unique runtime handling
 Unique encoding for speed and compression
 Unique memory management
 Columnar storage, vector processing
 Built directly into the Db2 kernel
• Revolution or evolution
 BLU tables coexists with traditional row tables
− in same schema, storage, and memory
 Query any combination of row or BLU tables
 Easy conversion of tables to BLU tables
− Change everything, or change incrementally

Creating database objects © Copyright IBM Corporation 2017

What is Db2 with BLU Acceleration?

Db2 10.5 introduced a new feature called BLU Acceleration. This is a new technology
that has been developed by IBM and integrated directly into the Db2 engine. BLU
Acceleration is a new storage engine along with integrated runtime (directly into the
core Db2 engine) to support the storage and analysis of column-organized tables. The
BLU Acceleration processing is parallel to the regular, row-based table processing
found in the Db2 engine. This is not a bolt-on technology nor is it a separate analytic
engine that sits outside of Db2. Much like when IBM added XML data as a first class
object within the database along with all the storage and processing enhancements that
came with XML, now IBM has added column-organized tables directly into the storage
and processing engine of Db2.
Simply put, this is a column-organized table store in Db2. Along with this store are many
benefits including significantly improved performance, massive storage savings and
ease of implementation and ease of management.
This feature allows us to deliver on these performance and storage innovations while
also optimizing the use of main-memory, improving I/O efficiency and exploiting CPU
instructions and characteristics to enhance the value derived from your database
investments.

© Copyright IBM Corp. 1997, 2017 5-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

In a Db2 database you can:

• Convert all the tables from row-organized to column organization to fully utilize
BLU Acceleration.
• Convert some tables to utilize BLU Acceleration and gradually expand the use of
column-organized table over a period of time.
• Db2 can generate access plans for queries that access a mixture of row and
column organized tables.

© Copyright IBM Corp. 1997, 2017 5-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

BLU Acceleration: Columnar storage

• Db2 uses separate set of extents and pages for each column
 Each table column is assigned to a set of pages
 Each page is filled with data from a single column, the number of rows
with data in a page would vary
TSN
0 John Piconne 47 18 Main Street Springfield MA 01111
Susan Nakagawa 32 455 N. 1st St. San Jose CA 95113
1
Sam Gerstner 55 911 Elm St. Toledo OH 43601
2
Chou Zhang 22 300 Grand Ave Los Angeles CA 90047
3
TSN:
Mike Hernandez 43 404 EscuelaSt. Los Angeles CA 90033
Pamela Funk
Tuple
4 29 166 Elk Road #47 Beaverton OR 97075
Page
Rick Washington 78 5661 Bloom St. Raleigh NC 27605
5
Sequence Ernesto Fry 35 8883 Longhorn Dr. Tucson AZ 85701
Number 6 Whitney Samuels 80 14 California Blvd. Pasadena CA 91117
7 Carol Whitehead 61 1114 Apple Lane Cupertino CA 95014
8
9
10
11
…
Creating database objects © Copyright IBM Corporation 2017

BLU Acceleration: Columnar storage

Db2 allocates extents of pages for each column in a column-organized table. The page
size and extent size is fixed for each table, based on the table space assigned when
the CREATE TABLE statement is executed.
Each page will only contain data from a single column in the table. The number of rows
that share a page will vary.
The visual shows the concept of storing data columns on different pages. You will see
that compression techniques are used for every column of data. The visual shows
uncompressed data for ease of understanding.

© Copyright IBM Corp. 1997, 2017 5-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Storage savings using BLU Acceleration

• Multiple examples of data requiring substantially less storage
 95% smaller than uncompressed data size
 Fewer objects required – no storage required for indexes, aggregates, etc
• Multiple compression techniques
 Processing takes place on compressed data
• Compression algorithm adapts to the data

DB2 with BLU Accel.

Creating database objects © Copyright IBM Corporation 2017

Storage savings using BLU Acceleration

All BLU Acceleration, column-organized tables are stored in a compressed form.
The compression techniques used for BLU Acceleration not only save physical disk
storage and reduce read I/O requirements for scanning tables but also allow for very
efficient use of CPU resources.
The visual shows the reductions is storage requirements for several different types of
customer data using Db2 column-organized tables.
The three sets of bars show:
• The space requirements for uncompressed tables using Db2 10.1
• The space required for compressed table using Db2 10.1 adaptive compression.
• The space required for compress column-organized tables using Db2 10.5
A portion of the space saved using column-organized tables is the space that was used
for additional objects like indexes for the row-organized tables.

© Copyright IBM Corp. 1997, 2017 5-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

BLU Acceleration: Simple to implement and use

• A single Db2 registry variable can be used to implement Db2 BLU
acceleration
db2set DB2_WORKLOAD=ANALYTICS

• Setting DB2_WORKLOAD=ANALYTICS before a database is created

 Allow AUTOCONFIGURE to set database configuration and memory
allocations
 Sets database page size to 32K
• Setting DB2_WORKLOAD=ANALYTICS for an existing database
 Run AUTOCONFIGURE command
 Verify that sort heap, utility heap, and Buffer pools are large

Creating database objects © Copyright IBM Corporation 2017

BLU Acceleration: Simple to implement and use

Db2 column-organized tables add columnar capabilities to Db2 databases, which
includes data stored with column organization and vector processing of column data.
Using this table format with star schema data marts provides significant improvements
to storage, query performance, and ease of use through simplified design and tuning.
If the majority of tables in your database are going to be column-organized tables, set
the DB2_WORLOAD registry variable to ANALYTICS prior to creating the database.
Doing so helps to configure memory, table organization, page size, and extent size, and
enables workload management.
The recommended approach is to put as many tables into column-organized format as
possible, if the workload is entirely an analytics/OLAP workload.
These workloads are characterized by nonselective data access (that is, queries
access more than approximately 5% of the data), and extensive scanning, grouping,
and aggregation.
Workloads that are transactional in nature should not use column-organized tables.
Traditional row-organized tables with index access are generally better suited for these
environments.

© Copyright IBM Corp. 1997, 2017 5-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

In the case of mixed workloads, which include a combination of analytic query

processing and very selective access (involving less than 2% of the data), a mix of row-
organized and column-organized tables might be suitable.

© Copyright IBM Corp. 1997, 2017 5-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

What happens when you create a new

column-organized table?
• Use a standard CREATE TABLE statement
CREATE TABLE [Link] (
ID SMALLINT NOT NULL,
NAME VARCHAR(9),
. . . .
COMM DECIMAL(7,2) )
ORGANIZE BY COLUMN
IN TSPACED INDEX IN TSPACEI ;
• A system generated page map index is associated with the column-organized table
 The index contains one entry for each page in the table
 Index has a generated name like SQL130617115333860 and uses the schema
SYSIBM
• A system generated ‘synopsis table’ is associated with the column-organized table
 The synopsis table can be used as a ‘rough’ index to skip pages based on SQL
predicates
 A synopsis has a generated name like SYN130617110037170122_HISTORY
and uses the schema of SYSIBM
Creating database objects © Copyright IBM Corporation 2017

What happens when you create a new column-organized table?

To create a column-organized table, specify the ORGANIZE BY COLUMN clause on
the CREATE TABLE statement.
Column organized tables do not require traditional indexes to support efficient access to
the table data. When a column-organized table is created, Db2 creates a system
generated page map index. The index contains one entry for each page in the column-
organized table. The index is assigned a system generated name.
Column organized tables can also have a system generated ‘synopsis table’. The data
in the table is used as a rough index, to skip reading pages that Db2 when can
determines that none of the column data in the page will match an SQL predicate.
The synopsis table has a system generated name that is prefixed by ‘SYN’, and uses
the schema SYSIBM.

© Copyright IBM Corp. 1997, 2017 5-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

BLU Acceleration illustration 10TB query in seconds

• The System: 32 cores, 1TB memory, 10TB table with 100 columns and 10
years of data
• The Query: How many “sales” did we have in 2010?
SELECT COUNT(*) from MYTABLE where YEAR = ‘2010’
• The Result: In seconds or less as each CPU core examines the equivalent of
just 8MB of data
Data Data Data Data Data
Data
Data Data Data
Data Data Data

Actionable Compression Column Processing Data Skipping

reduces to 1TB reduces to 10GB reduces to 1GB
10TB data In-memory

Parallel Processing Vector Processing Scans as

32MB linear scan fast as Result in
on each core via 8MB through SIMD seconds or less

Data Data Data

Creating database objects © Copyright IBM Corporation 2017

BLU Acceleration illustration 10TB query in seconds

Prior to the implementation of Db2 with BLU Acceleration, the idea of being able to get
a query result from a large table with 10 terabytes of data in a second or less without
using indexes would seem impossible.
Here’s how the design components of Db2 with BLU acceleration could possibly
achieve this.
Assume the system has 32 processor cores and 1TB of memory. The table has 10TB
of raw application data, 100 columns that hold ten years of information.
A simple query might want to count sales for one year, 2010.
• First, the extreme compression on column-organized tables might reduce the raw
10TB of data into 1TB of storage.
• If the query only accesses one column, then the storage for 99 columns can be
bypassed, so the remaining one percent might be 10GB of data.
• Using the synopsis table to perform data skipping you may be able to bypass
reading the other 9 years, which in 90 percent, so the query now only needs 1GB
of the 10GB for the one column.

© Copyright IBM Corp. 1997, 2017 5-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

• Since the system has 32 CPUs the scan could be divided and processed in
parallel which would have 32MB processed by each CPU.
• If the column data is processed using vectors that handle four columns of data
per operation, the processing per CPU is now reduced to 8MB of data.
All the processing techniques could work together to reduce the query processing to an
amount of processing that could complete quickly.

© Copyright IBM Corp. 1997, 2017 5-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Shadow Tables can be used to accelerate Analytics query

processing in an OLTP database

Column-organized tables
Row-organized tables can
can process some SQL
process all SQL that
queries to improve
changes data and
SELECT statements performance
expected to perform well

Creating database objects © Copyright IBM Corporation 2017

Shadow Tables can be used to accelerate Analytics query processing in an OLTP

database
This slide shows how shadow tables can be used to accelerate analytics that are
directly run against transactional data as it happens.
Within the same Db2 database, you have both the main transactional row-organized
tables and their corresponding shadow tables which are copies of the source tables, but
in columnar format.
With this dual format architecture, transactional applications continue to optimally target
the main row-organized tables, while complex analytical queries are re-routed to the
corresponding shadow tables. Since the shadow tables are in columnar format, the
analytical queries are accelerated by an order of magnitude faster via BLU technology.
To maintain the shadow tables, the solution leverages Change Data Capture, an IBM
InfoSphere Data Replication product. Performance testing has shown that the latency
between the main transactional tables and the shadow tables can be as low as single
digit seconds, allowing analytics to act on as close to real time data as possible.
Since shadow tables are used to accelerate the analytics processing, any extra indexes
that were created just to speed up the analytic queries can be dropped. This may offset
any impact that the data replication to shadow tables may have on the transactional
workload.

© Copyright IBM Corp. 1997, 2017 5-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Shadow table characteristics

• A shadow table is a column-organized copy of a row-organized table
that includes all columns or a subset of columns.
• Shadow tables are implemented as materialized query tables (MQTs)
that are maintained by replication.
• Using shadow tables, you can get the performance benefits of BLU
Acceleration for analytic queries in an online transaction processing
(OLTP) environment.
• Shadow tables are maintained by IBM InfoSphere Change Data Capture
for Db2 LUW, a component of the InfoSphere Data Replication product.
 InfoSphere CDC asynchronously replicates DML statements that are applied on
the source table to the shadow table.
• By default, all applications access the source tables.
 Queries are automatically routed to the source table (row-organized) or the
shadow table (column-organized copy of the source table) based on estimated
costs
 A latency-based algorithm is available to prevent applications from accessing the
shadow table when the latency is beyond the user-defined limit.

Creating database objects © Copyright IBM Corporation 2017

Shadow table characteristics

A shadow table is a column-organized copy of a row-organized table that includes all
columns or a subset of columns. Shadow tables are implemented as materialized query
tables (MQTs) that are maintained by replication.
Using shadow tables, you can get the performance benefits of BLU Acceleration for
analytic queries in an online transaction processing (OLTP) environment. Analytical
queries against row-organized tables are automatically routed to shadow tables if the
replication latency falls within a user-defined limit.
BLU Acceleration enhances the performance of complex queries through a column-
organized architecture. By combining this enhanced performance for complex queries
with the efficiency of row-organized tables for OLTP queries, you can use shadow
tables to capitalize on the best of both worlds.
Shadow tables are maintained by IBM InfoSphere Change Data Capture for Db2, a
component of the InfoSphere Data Replication product. InfoSphere CDC
asynchronously replicates DML statements that are applied on the source table to the
shadow table.

© Copyright IBM Corp. 1997, 2017 5-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

By default, all applications access the source tables. Queries are automatically routed
to the source table (row-organized) or the shadow table (column-organized copy of the
source table) by using a latency-based algorithm that prevents applications from
accessing the shadow table when the latency is beyond the user-defined limit.
Shadow tables improve analytic query performance in OLTP environments without
having to add indexes for this purpose.

© Copyright IBM Corp. 1997, 2017 5-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Advances to column-organized tables with Db2 11.1

• BLU acceleration performance improvements:
 Sorting using fast parallel radix sort on compressed and encoded data
 Nested-loop join
 OLAP functions
 Native support for more scalar functions
 Advanced automatic query decorrelation
 Faster SQL MERGE
• Additional functional support for BLU acceleration:
 Declared global temporary tables
 IDENTITY and EXPRESSION generated columns
 NOT LOGGED INITIALLY
 Codepage 819

Creating database objects © Copyright IBM Corporation 2017

Advances to column-organized tables with Db2 11.1

Db2 Version 11.1 introduces significant enhancements to the BLU Acceleration core
technology. These enhancements include Nested-Loop Join (NLJN) support, advanced
decorrelation methods, faster SQL MERGE, enhancements to memory management,
further SIMD advances, industry-leading parallel sort, and increased SQL parallelism.
The industry-leading parallel sort algorithm leverages the latest innovations from the
IBM Thomas J. Watson Research Center. This parallel sort features a fast radix sort
with superior parallelism that is able to sort compressed and encoded data. Together,
these enhancements can increase BLU Acceleration performance by as much as two
times.
BLU Acceleration has also added SQL advances with richer functionality and
compatibility, including SQL compatibility with IBM PureData System for Analytics. This
compatibility enables native columnar online analytical processing for deep in-database
analytics, the analytic capabilities of PureData System for Analytics, wide rows, new
data types, logical character support, improved PostgreSQL compatibility, and a wide
variety of additional SQL functions being incorporated in Db2 Version 11.1.
Other enhancements include BLU Acceleration support for IDENTITY and
EXPRESSION generated columns, European Language support, and NOT LOGGED
INITIALLY support for column-organized tables.

© Copyright IBM Corp. 1997, 2017 5-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Demonstrating BLU single instance improvement

Db2 V11.1 on Intel Haswell EP
Reasons for Improvement
Query Throughput BD
Insights (800GB) Native BLU
• Native Sort
• Native OLAP (usually combined with sort)
1200 1.36x Evaluation • Enables query plans to remain as much as
possible within the columnar engine
1000
Queries Per Hour

800
600
Query Rewrite • Find areas to improve degree determination
400 Improvements and improve parallel use

200
0
DB2 V10.5 FP5 DB2 V11.1
• SORTHEAP used for building hash tables for
QpH 703.85 955.82 Improved JOINs, GROUP BYs, and other runtime work
SORTHEAP • Efficient use allows for more concurrent intra-
query and inter-query operations to coexist.
Utilization

Configuration Details

• 2 socket, 36 core Intel Xeon E5-2699 v3 @ 2.3GHz

• 192GB RAM
• BD Insights Internal Multiuser Workload 800GB

Creating database objects © Copyright IBM Corporation 2017

Demonstrating BLU single instance improvement

The slide shows an example of the performance gains demonstrated using an IBM
internal workload, comparing Db2 10.5 to Db2 11.1.
The workload is able to benefit from the following Db2 11.1 enhancements:
1. Native BLU evaluation - more of the processing is able to benefit from the
efficiencies in column-organized processing, including sort and OLAP function
handling.
2. Query Rewrite improvements - the Db2 optimizer rewrites the SQL queries to
improve utilization of parallel processing.
Improved SORTHEAP utilization - efficient use of sort memory allows for more
concurrent intra-query and inter-query operations to coexist.

© Copyright IBM Corp. 1997, 2017 5-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

BLU declared global temporary tables

• Support for a column-organized DGTT
• Supports all options except not logged on rollback preserve rows
• Can be DB partitioned
• No BLU support for created global temporary tables

DECLARE GLOBAL TEMPORARY TABLE

SESSION.CUST_TEMP (
"C_CUSTOMER_SK" INTEGER NOT NULL ,
"C_FIRST_NAME" CHAR(20 OCTETS) ,
"C_LAST_NAME" CHAR(30 OCTETS) ,
etc.
)
DISTRIBUTE BY HASH("C_CUSTOMER_SK") IN
USERTEMP1
ORGANIZE BY COLUMN NOT LOGGED;

Creating database objects © Copyright IBM Corporation 2017

BLU declared global temporary tables

Db2 11.1 supports declared global temporary tables that are column-organized.
The slide shows an example of the statement an application could use to define a
column-organized temporary table. This is supported in MPP partitioned databases as
well as single partition databases.

© Copyright IBM Corp. 1997, 2017 5-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Create View statement

CONNECT TO TESTDB;
CREATE VIEW EMPSALARY
AS SELECT EMPNO, EMPNAME, SALARY
FROM PAYROLL, PERSONNEL
WHERE EMPNO=EMPNUMB AND SALARY > 30000.00;

SELECT * FROM EMPSALARY

EMPNO EMPNAME SALARY

------ ----------------- ----------
10 John Smith 1000000.00
20 Jane Johnson 300000.00
30 Robert Appleton 250000.00

Creating database objects © Copyright IBM Corporation 2017

Create View statement

A view is an alternate representation of data from one or more tables. It can include
some or all of the columns contained in the tables on which it is defined.
To create a view, you must be connected to a database, either implicitly or explicitly,
and the base tables or views upon which the view is based must previously exist.
Views can be created using the SQL statement CREATE VIEW.
You must have SYSADM, DBADM, CONTROL, or SELECT privilege on each base
table to create a view.
Privileges on the base tables granted to groups are not checked to determine
authorization to create a view. However, if the base table has SELECT privilege given to
PUBLIC, a view could be created. In addition, you must have the IMPLICIT_SCHEMA
privilege or the CREATEIN privilege on the schema used.
Views might be used to exclude users from seeing certain data: rows or columns. The
WHERE clause used in the CREATE VIEW statement determines which rows might be
viewed by the user. The columns listed in the AS SELECT clause determine which
columns might be viewed by the user.
Views can also be used to increase the access rights to data for a special user group.

© Copyright IBM Corp. 1997, 2017 5-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Views might be used to improve performance. If a difficult SQL statement is to be used

by users, it might be advantageous to create a view that is coded to utilize an index, or
to ensure that a join is correctly coded.
Data for a view is not separately stored. The data is stored in the base tables.
When an object is dropped, views can become inoperative if they are dependent on
that object. To recover an inoperative view, determine the SQL statement that was
initially used to create the view. This information can be obtained from the
[Link] column. Recreate the view by using the CREATE VIEW
statement with the same view name. Use the GRANT statement to regrant all privileges
that were previously granted on the view. If you do not want to recover an inoperative
view, you can explicitly drop it with the DROP VIEW statement.
An inoperative view only has entries in the [Link] and [Link]
catalog views. All entries in the [Link], [Link], and
[Link] catalog views are removed.
CREATE VIEW view-name (column-name { ,column-name }) AS
fullselect
{ WITH [ CASCADED | LOCAL ] CHECK OPTION }
WITH CHECK OPTION specifies the constraint that every row that is inserted or
updated through the view must conform to the definition of the view. WITH CHECK
OPTION must not be specified if the view is read-only. If WITH CHECK OPTION is
specified for an updateable view that does not allow inserts, then the constraint applies
to update only. If WITH CHECK OPTION is omitted, the definition of the view is not
used in the checking of any insert or update operations that use the view. Some
checking might still occur during insert or update operations if the view is directly or
indirectly dependent on an another view that includes WITH CHECK OPTION.
CASCADED causes the constraints of all dependent views to also be applied.
LOCAL causes the constraints of only this view to be applied.
A view can be defined on a view.
A read-only view cannot be the object of an INSERT, UPDATE, or DELETE statement.
For more information, refer to the SQL Reference manual.

© Copyright IBM Corp. 1997, 2017 5-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Create Alias statement

• Cannot be the same as an existing table, view, or alias
• To create an alias of [Link] for the table
[Link]
 CREATE ALIAS [Link] FOR [Link];
• To create a public alias called TABS for the catalog view
[Link]
 CREATE PUBLIC ALIAS TABS FOR [Link]

Creating database objects © Copyright IBM Corporation 2017

Create Alias statement

The CREATE ALIAS statement defines an alias for a module, nickname, sequence,
table, view, or another alias. Aliases are also known as synonyms.
The keyword PUBLIC is used to create a public alias (also known as a public
synonym). If the keyword PUBLIC is not used, the type of alias is a private alias (also
known as a private synonym).
The definition of the newly created table alias is stored in [Link]. The
definition of the newly created module alias is stored in [Link]. The
definition of the newly created sequence alias is stored in [Link].
An alias can be defined for an object that does not exist at the time of the definition. If it
does not exist, a warning is issued (SQLSTATE 01522). However, the referenced object
must exist when a SQL statement containing the alias is compiled, otherwise an error is
issued (SQLSTATE 52004).
An alias can be defined to refer to another alias as part of an alias chain but this chain
is subject to the same restrictions as a single alias when used in an SQL statement. An
alias chain is resolved in the same way as a single alias. If an alias used in a statement
in a package, an SQL routine, a trigger, the default expression for a global variable, or a
view definition points to an alias chain, then a dependency is recorded for the package,
SQL routine, trigger, global variable, or view on each alias in the chain. An alias cannot

© Copyright IBM Corp. 1997, 2017 5-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

refer to itself in an alias chain and such a cycle is detected at alias definition time
(SQLSTATE 42916).
Resolving an unqualified alias name: When resolving an unqualified name, private
aliases are considered before public aliases.
Conservative binding for public aliases: If a public alias is used in a statement in a
package, an SQL routine, a trigger, the default expression for a global variable, or a
view definition, the public alias will continue to be used by these objects regardless of
what other object with the same name is created subsequently.
Creating an alias with a schema name that does not already exist will result in the
implicit creation of that schema provided the authorization ID of the statement has
IMPLICIT_SCHEMA authority. The schema owner is SYSIBM. The CREATEIN
privilege on the schema is granted to PUBLIC.
Syntax alternatives: The following syntax alternatives are supported for compatibility
with previous versions of Db2 and with other database products, SYNONYM can be
specified in place of ALIAS.

© Copyright IBM Corp. 1997, 2017 5-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Create index statements

• Create a unique index based on one column
CREATE UNIQUE INDEX [Link] ON [Link] (EMPNO ASC)
PCTFREE 10
Index statistics can
ALLOW REVERSE SCANS be collected during
PAGE SPLIT SYMMETRIC index creation
COLLECT SAMPLED DETAILED STATISTICS ;

• Create a non-unique index that will be used to cluster data sequence

CREATE INDEX ITEM ON STOCK (ITEMNO) CLUSTER ;

• Create a unique index based on one column that includes extra

columns to support index-only strategies
CREATE UNIQUE INDEX EMPIDX ON EMPLOYEE (EMPNO)
INCLUDE (LASTNAME, FIRSTNAME) ;

Creating database objects © Copyright IBM Corporation 2017

Create index statements

The visual shows several examples of statements used to create indexes.
Indexes can be created for many reasons, including: to allow queries to run more
efficiently; to order the rows of a table in ascending or descending sequence according
to the values in a column; to enforce constraints such as uniqueness on index keys.
You can use the CREATE INDEX statement, the IBM Data Server Manager, or the
db2advis Design Advisor command to create the indexes.
To create an index from the command line, use the CREATE INDEX statement.
For example:
CREATE UNIQUE INDEX EMP_IX
ON EMPLOYEE(EMPNO)
INCLUDE(FIRSTNAME, JOB)
The INCLUDE clause, applicable only on unique indexes, specifies additional columns
to be appended to the set of index key columns. Any columns included with this clause
are not used to enforce uniqueness. These included columns can improve the
performance of some queries through index only access. This option might:
• Eliminate the need to access data pages for more queries
• Eliminate redundant indexes

© Copyright IBM Corp. 1997, 2017 5-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

If SELECT EMPNO, FIRSTNAME, JOB FROM EMPLOYEE is issued to the table on

which this index resides, all of the required data can be retrieved from the index without
reading data pages. This improves performance.
When a row is deleted or updated, the index keys are marked as deleted and are not
physically removed from a page until cleanup is done some time after the deletion or
update is committed. These keys are referred to as pseudo-deleted keys. Such a
cleanup might be done by a subsequent transaction which is changing the page where
the key is marked deleted. Clean up of pseudo-deleted keys can be explicitly triggered
by using the CLEANUP ONLY ALL parameter in the REORG INDEXES command.

© Copyright IBM Corp. 1997, 2017 5-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Overview of referential integrity

• Place constraints between tables
• Constraints specified with Create and Alter table statements
• Database services enforce constraints: inserts, updates, deletes
• Removes burden of constraint checking from application programs
• Constraints can defined as ENFORCED or NOT ENFORCED
Department Table
DEPT DEPTNAME

Parent Table
R PRIMARY KEY = DEPT
E
S
T Employee Table
R EMPNO Dependent Table
NAME WKDEPT
I FOREIGN KEY = WKDEPT
C
T

Creating database objects © Copyright IBM Corporation 2017

Overview of referential integrity

Referential integrity is imposed by adding foreign key (or referential) constraints to table
and column definitions, and to create an index on all the foreign key columns. Once the
index and foreign key constraints are defined, changes to the data within the tables and
columns is checked against the defined constraint. Completion of the requested action
depends on the result of the constraint checking.
Referential constraints are established with the FOREIGN KEY clause, and the
REFERENCES clause in the CREATE TABLE or ALTER TABLE statements. There are
effects from a referential constraint on a typed table or to a parent table that is a typed
table that you should consider before creating a referential constraint.
The identification of foreign keys enforces constraints on the values within the rows of a
table or between the rows of two tables. The database manager checks the constraints
specified in a table definition and maintains the relationships accordingly. The goal is to
maintain integrity whenever one database object references another, without
performance degradation.
Constraints that are enforced by the database manager when records are inserted or
updated can lead to high amounts of system activity, especially when loading large
quantities of records that have referential integrity constraints. If an application has
already verified information before inserting a record into the table, it might be more
efficient to use informational constraints, rather than normal constraints.

© Copyright IBM Corp. 1997, 2017 5-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Informational constraints tell the database manager what rules the data conforms to,
but the rules are not enforced by the database manager. However, this information can
be used by the Db2 optimizer and could result in better performance of SQL queries.
To improve the performance of queries, you can add informational constraints to your
tables. You add informational constraints using the CREATE TABLE or ALTER TABLE
statement when you specify the NOT ENFORCED option on the DDL. Along with the
NOT ENFORCED option you can further specify the constraint to be either TRUSTED
or NOT TRUSTED.
NOT ENFORCED should only be specified if the table data is independently known to
conform to the constraint. Query results might be unpredictable if the data does not
actually conform to the constraint. You can also specify if the NOT ENFORCED
constraint is to be TRUSTED or NOT TRUSTED.
• TRUSTED: Informs the database manager that the data can be trusted to
conform to the constraint. This is the default option. This option must only be
used if the data is independently known to conform to the constraint
• NOT TRUSTED: Informs the database manager that the data cannot be trusted
to conform to the constraint. This option is intended for cases where the data
conforms to the constraint for most rows, but it is not independently known to
conform to the constraint. NOT TRUSTED can be specified only for referential
integrity constraints (SQLSTATE 42613).

© Copyright IBM Corp. 1997, 2017 5-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Referential integrity: CREATE TABLE statement

CREATE TABLE DEPARTMENT
(DEPTNO CHAR(3) NOT NULL,
DEPTNAME VARCHAR(29) NOT NULL,
MGRNO CHAR(6),
ADMRDEPT CHAR(3) NOT NULL,
LOCATION CHAR(16),
PRIMARY KEY (DEPTNO))
IN RESOURCE

CREATE TABLE EMPLOYEE

(EMPNO CHAR(6) NOT NULL PRIMARY KEY,
FIRSTNME VARCHAR(12) NOT NULL,
LASTNAME VARCHAR(15) NOT NULL,
WORKDEPT CHAR(3),
PHONENO CHAR(4),
PHOTO BLOB(10m) NOT NULL,
FOREIGN KEY DEPT (WORKDEPT)
REFERENCES DEPARTMENT ON DELETE NO ACTION)
IN RESOURCE

Creating database objects © Copyright IBM Corporation 2017

Referential integrity: CREATE TABLE statement

In this example, primary and foreign keys are used for a department number column.
For the EMPLOYEE table, the column name is WORKDEPT, and for the
DEPARTMENT table, the name is DEPTNO. The relationship between these two tables
is defined by the following constraints:
• There is only one department number for each employee in the EMPLOYEE
table, and that number exists in the DEPARTMENT table.
• Each row in the EMPLOYEE table is related to no more than one row in the
DEPARTMENT table. There is a unique relationship between the tables.
• Each row in the EMPLOYEE table that has a non-null value for WORKDEPT is
related to a row in the DEPTNO column of the DEPARTMENT table.
• The DEPARTMENT table is the parent table, and the EMPLOYEE table is the
dependent table.

© Copyright IBM Corp. 1997, 2017 5-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

The statement defining the parent table, DEPARTMENT, is:

CREATE TABLE DEPARTMENT
(DEPTNO CHAR(3) NOT NULL,
DEPTNAME VARCHAR(29) NOT NULL,
MGRNO CHAR(6),
ADMRDEPT CHAR(3) NOT NULL,
LOCATION CHAR(16),
PRIMARY KEY (DEPTNO))
IN RESOURCE
The statement defining the dependent table, EMPLOYEE, is:
CREATE TABLE EMPLOYEE
(EMPNO CHAR(6) NOT NULL PRIMARY KEY,
FIRSTNME VARCHAR(12) NOT NULL,
LASTNAME VARCHAR(15) NOT NULL,
WORKDEPT CHAR(3),
PHONENO CHAR(4),
PHOTO BLOB(10m) NOT NULL,
FOREIGN KEY DEPT (WORKDEPT)
REFERENCES DEPARTMENT ON DELETE NO ACTION)
IN RESOURCE
By specifying the DEPTNO column as the primary key of the DEPARTMENT table and
WORKDEPT as the foreign key of the EMPLOYEE table, you are defining a referential
constraint on the WORKDEPT values. This constraint enforces referential integrity
between the values of the two tables. In this case, any employees that are added to the
EMPLOYEE table must have a department number that can be found in the
DEPARTMENT table.
The delete rule for the referential constraint in the employee table is NO ACTION, which
means that a department cannot be deleted from the DEPARTMENT table if there are
any employees in that department.

© Copyright IBM Corp. 1997, 2017 5-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Unique key considerations

• Multiple keys in one table can be Foreign Key targets
CREATE TABLE [Link]
(EMPNO SMALLINT NOT NULL PRIMARY KEY,
NAME CHAR(20),
DRIVERLIC CHAR(17) NOT NULL,
CONSTRAINT DRIV_UNIQ UNIQUE(DRIVERLIC)
)IN TBSP1 ;

Unique indexes PAY.DRIV_UNIQ and [Link]

created Columns must be NOT NULL
• Deferral of unique checking until end of statement processing
 UPDATE EMPTAB SET EMPNO=EMPNO + 1

Creating database objects © Copyright IBM Corporation 2017

Unique key considerations

A unique constraint is the rule that the values of a key are valid only if they are unique
within the table. Unique constraints are optional and can be defined in the CREATE
TABLE or ALTER TABLE statement using the PRIMARY KEY clause or the UNIQUE
clause. The columns specified as a unique constraint must be defined as NOT NULL. A
unique index is used by the database manager to enforce the uniqueness of the key
during changes to the columns of the unique constraint.
A table can have an arbitrary number of unique constraints, with at most one unique
constraint defined as a Primary Key. A table cannot have more than one unique
constraint on the same set of columns.
A unique constraint that is referenced by the Foreign Key of a referential constraint is
called a parent key. When a unique constraint is defined in a CREATE TABLE
statement, a unique index is automatically created by the database manager and
designated as a primary or unique system-required index. When a unique constraint is
defined in an ALTER TABLE statement and an index exists on the same columns, that
index is designated as unique and system-required. If such an index does not exist, the
unique index is automatically created by the database manager and designated as a
primary or unique system-required index. CONSTRAINT constraint-name identifies the
constraint.

© Copyright IBM Corp. 1997, 2017 5-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

If this clause is omitted, an 18-character identifier, unique within the identifiers of the
existing constraints defined on the table, is generated by the system. When used with a
PRIMARY KEY or UNIQUE constraint, the constraint-name will be used as the name of
an index that is created to support the constraint if a unique index does not exist. If the
CONSTRAINT constraint-name clause is not used, the system-generated index will be
named [Link].
PRIMARY KEY provides a shorthand method of defining a Primary Key composed of a
single column. Thus, if PRIMARY KEY is specified in the definition of column C, the
effect is the same as if the PRIMARY KEY(C) clause is specified as a separate clause.
UNIQUE provides a shorthand method of defining a unique key composed of a single
column. Thus, if UNIQUE is specified in the definition of column C, the effect is the
same as if the UNIQUE(C) clause is specified as a separate clause.
The unique constraint clause defines a unique or Primary Key constraint.
CONSTRAINT constraint-name names the Primary Key or unique constraint.
UNIQUE(column-name, ...) defines a unique key composed of the identified columns.
The identified columns must be defined as NOT NULL.
If a column or set of columns is defined as being unique, and an update statement is
issued which updates a set of rows, Db2 will not check for uniqueness until all of the
rows have been updated (within the single statement). This will allow a statement like:
UPDATE EMPTAB SET EMPNO = EMPNO + 1
to execute successfully, even if there are consecutive values currently found in the
EMPTAB table (which would cause duplicate values within the table for a short duration,
during the processing of the UPDATE statement).

© Copyright IBM Corp. 1997, 2017 5-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Check constraints: Definition

CREATE TABLE SPEED_LIMITS

(ROUTE_NUM SMALLINT,
CANADA_SL INTEGER NOT NULL,
US_SL INTEGER NOT NULL
CHECK (US_SL <=65) ) ;

ALTER TABLE SPEED_LIMITS

ADD CONSTRAINT SPEED65
CHECK (US_SL <=65) ;

Creating database objects © Copyright IBM Corporation 2017

Check constraints: Definition

Column constraints can be defined using the SQL statements CREATE TABLE or
ALTER TABLE. The constraint name cannot be the same as any other constraint
specified within that statement, and must be unique within the table. [<marker>]
If the ALTER TABLE statement is used, existing data is checked against the new
constraint before the ALTER statement succeeds. If any rows exist that would violate
the constraint, the ALTER TABLE statement fails.
To add constraints to a large table, it is more efficient to put the table into the set
integrity pending state, add the constraints, and then check the table for a consolidated
list of violation rows. Use the SET INTEGRITY statement to explicitly set the set
integrity pending state. If the table is a parent table, set integrity pending is implicitly set
for all dependent and descendent tables.
When a table check constraint is added, packages that insert or update the table might
be marked as invalid.

© Copyright IBM Corp. 1997, 2017 5-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

The definition of the constraint allows basic WHERE clause constructs to be used:
• Basic comparisons (>, <, =, >=, and so on)
• BETWEEN
• LIKE
• IN
• Deterministic UDFs
Values can only be inserted or updated in the column if the result of the constraint test
resolves to True.
The definition of the constraint does not support:
• Subqueries
• Column functions
• Functions that are not deterministic
• Functions defined to have an external action
• User-defined functions defined with either CONTAINS SQL or READS SQL DATA
• Host variables or parameter markers
• Special registers (such as CURRENT DATE)
• References to generated columns other than the identity column
The constraint can be explicitly named when it is defined. If it is not named, Db2 will
create a name.
The ALTER TABLE statement can also be used to DROP constraints. For example:
ALTER TABLE SPEED_LIMITS DROP CONSTRAINT SPEED65
or
ALTER TABLE SPEED_LIMITS DROP CHECK SPEED65

© Copyright IBM Corp. 1997, 2017 5-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Create a trigger statement

• Example: a trigger could insert a new row into one tables if an update
on another table resulted in a column value falling below a defined
threshold.

CREATE TRIGGER [Link]

AFTER UPDATE
OF QTY ON [Link]
REFERENCING NEW AS N
FOR EACH ROW MODE DB2SQL
WHEN ([Link] <=5)
INSERT INTO [Link] VALUES ([Link], CURRENT TIMESTAMP) ;

Creating database objects © Copyright IBM Corporation 2017

Create a trigger statement

A trigger defines a set of actions that are executed with, or triggered by, an INSERT,
UPDATE, or DELETE clause on a specified table or a typed table.
Use triggers to:
• Validate input data
• Generate a value for a newly inserted row
• Read from other tables for cross-referencing purposes
• Write to other tables for audit-trail purposes
You can use triggers to support general forms of integrity or business rules. For
example, a trigger can check a customer's credit limit before an order is accepted or
update a summary data table.

© Copyright IBM Corp. 1997, 2017 5-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Benefits:
• Faster application development: Because a trigger is stored in the database, you
do not have to code the actions that it performs in every application.
• Easier maintenance: After a trigger is defined, it is automatically invoked when the
table that it is created on is accessed.
• Global enforcement of business rules: If a business policy changes, you only
need to change the trigger and not each application program.
A trigger body can include one or more of the following statements: INSERT, searched
UPDATE, searched DELETE, fullselect, SET Variable, and SIGNAL SQLSTATE. The
trigger can be activated before or after the INSERT, UPDATE, or DELETE statement to
which it refers.
Note: Starting in Db2 Version 10.1 the CREATE TRIGGER statement allows more
flexibility and functionality when creating triggers.
Multiple-event trigger support
The trigger event clause in the CREATE TRIGGER statement can now contain more
than one operation. The ability to use UPDATE, DELETE, and INSERT operations
together in a single clause means that the trigger is activated by the occurrence of any
of the specified events. One, two, or all three trigger events can be arbitrarily specified
in a CREATE TRIGGER statement. However, a trigger event cannot be specified more
than once.
Trigger event predicates identify trigger events
The trigger event predicates of UPDATING, INSERTING, and DELETING can be used
to identify the event that activated a trigger. Trigger event predicates can only be used
in the trigger action of a CREATE TRIGGER statement that uses a compound SQL
(compiled) statement.
FOR EACH STATEMENT restriction removed
The FOR EACH STATEMENT option is now supported in the CREATE TRIGGER
statement for PL/SQL triggers. You can create triggers that fire only one time per
statement irrespective of the number of rows affected.

© Copyright IBM Corp. 1997, 2017 5-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Manage and query time-based data using temporal tables

• Use temporal tables associated with Time Travel Query to assign
time-based state information to your data.
 Data in tables that do not use temporal support represents the present
 Data in temporal tables is valid for a period defined by the database system,
customer applications, or both
• System-period temporal tables
 Db2 can automatically store the history of a table
 The history table contains deleted rows or the original values of rows that
have been updated so you can query the past state of your data
• Application-period temporal tables
 You can also assign a date range to a row of data to indicate when it is
deemed to be valid by your application or business rules
• Bi-temporal tables
 Combine application-period (ATT) and system-period (STT) capabilities

Creating database objects © Copyright IBM Corporation 2017

Manage and query time-based data using temporal tables

You can use temporal tables to associate time-based state information with your data.
Data in tables that do not use temporal support are deemed to be applicable to the
present, while data in temporal tables can be valid for a period defined by the database
system, user applications, or both.
There are many business needs requiring the storage and maintenance of time-based
data. Without this capability in a database, it is expensive and complex to maintain a
time-focused data support infrastructure. With temporal tables, the database can store
and retrieve time-based data without additional application logic. For example, a
database can store the history of a table (deleted rows or the original values of rows
that have been updated) so you can query the past state of your data. You can also
assign a date range to a row of data to indicate when it is deemed to be valid by your
applications or business rules.
A temporal table records the period when a row is valid. A period is an interval of time
that is defined by two date or time columns in the temporal table. A period contains a
begin column and an end column. The begin column indicates the beginning of the
period, and the end column indicates the end of the period. The beginning value of a
period is inclusive, while the ending value of a period is exclusive. For example, a row
with a period from January 1 to February 1 is valid from January 1, until January 31 at
midnight.

© Copyright IBM Corp. 1997, 2017 5-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Two period types are supported:

System periods
• A system period consists of a pair of columns with database manager-
maintained values that indicate the period when a row is current. The begin
column contains a timestamp value for when a row was created. The end
column contains a timestamp value for when a row was updated or deleted.
When a system-period temporal table is created, it contains the currently
active rows. Each system-period temporal table is associated with a history
table that contains any changed rows.
Application periods
• An application period consists of a pair of columns with user or application-
supplied values that indicate the period when a row is valid. The begin column
indicates the time when a row is valid from. The end column indicates the time
when a row stops being valid. A table with an application period is called an
application-period temporal table.

© Copyright IBM Corp. 1997, 2017 5-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Query using a system-period temporal table

• Query the past: what trips were available on 03/01/2012 for less than $500?
 Current date = May 1, 2012
SELECT trip_name FROM travel FOR SYSTEM_TIME AS OF ’03/01/2012’
WHERE price < 500.00

• Query the present: what trips are currently available to Brazil?

SELECT trip_name FROM travel WHERE destination = ‘Brazil’

Defaults to the current table only

and functions as if you added
FOR SYSTEM TIME AS OF CURRENT DATE

• Query the past and the present: In 2011, how many different tours
were offered?
SELECT COUNT (DISTINCT trip_name) FROM travel
FOR SYSTEM_TIME BETWEEN ’01/01/2011’ AND ’01/01/2012’

Creating database objects © Copyright IBM Corporation 2017

How to define a system-period temporal table

This visual shows an example of the actual syntax required to configure a System-
period temporal table. The key syntax that is required for the base table (travel in this
example) to configure a system-period temporal table base-history table pair is the
definition of the three columns (sys_start, sys_end, and ts_start) indicated on the
CREATE TABLE statement.
In addition to the column definition, the CREATE TABLE contains the PERIOD
SYSTEM_TIME (sys_start, sys_end) keyword.
Next, the history table associated with the base table must be explicitly created. In this
example, the CREATE TABLE contains the "like" keyword followed by the base table
name (travel). Another option is to explicitly specify each column and data type for the
history table.
Note: The column names and data types must match the base table.
For the example shown, the history table (travel_history) is created in a separate
tablespace from the base "travel" table, as updates and deletes to the base table cause
writes to the history table as well.
Finally, the actual system-period temporal table base-history table pair is setup (and can
be used transparently by Db2) when an ALTER TABLE with the "ADD VERSIONING

© Copyright IBM Corp. 1997, 2017 5-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

USE HISTORY TABLE travel_history" option is issued against the database. The
system-period Temporal table is NOT operational until this final step is completed.
When dropping a system-period Temporal Table, you simply issue a DROP TABLE for
the base table and the associated history table is automatically dropped as well.
If you want to drop the base table and keep the history table, you must deactivate the
linkage between the base table and the history table with an ALTER TABLE base_table
DROP VERSIONING statement prior to issuing the DROP TABLE base_table
statement.
System-period temporal tables
A system-period temporal table is a table that maintains historical versions of its rows.
Use a system-period temporal table to store current versions of your data and use its
associated history table to transparently store your updated and deleted data rows.
A system-period temporal table includes a SYSTEM_TIME period with columns that
capture both the begin and the end times when the data in a row is current. The
database manager also uses the SYSTEM_TIME period to preserve historical versions
of each table row whenever updates or deletes occur. The database manager stores
these rows in a history table that is exclusively associated with a system-period
temporal table. Adding versioning establishes the link between the system-period
temporal table and the history table. With a system-period temporal table, your queries
have access to your data at the current point in time and the ability to retrieve data from
past points in time.
A system-period temporal table also includes a transaction start-ID column. This column
captures the time when execution started for a transaction that impacts the row. If
multiple rows are inserted or updated within a single SQL transaction, then the values
for the transaction start-ID column are the same for all the rows and are unique from the
values generated for this column by other transactions. This common start-ID column
value means you can use the transaction start-ID column to identify all the rows in the
tables that were written by the same transaction.

© Copyright IBM Corp. 1997, 2017 5-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Query using a system-period temporal table

• Query the past: what trips were available on 03/01/2012 for less than $500?
 Current date = May 1, 2012
SELECT trip_name FROM travel FOR SYSTEM_TIME AS OF ’03/01/2012’
WHERE price < 500.00

• Query the present: what trips are currently available to Brazil?

SELECT trip_name FROM travel WHERE destination = ‘Brazil’

Defaults to the current table only

and functions as if you added
FOR SYSTEM TIME AS OF CURRENT DATE

• Query the past and the present: In 2011, how many different tours
were offered?
SELECT COUNT (DISTINCT trip_name) FROM travel
FOR SYSTEM_TIME BETWEEN ’01/01/2011’ AND ’01/01/2012’

Creating database objects © Copyright IBM Corporation 2017

Query using a system-period temporal table

The discussion of system-period temporal tables concludes with some example queries
utilizing the same "travel" table and the data that was previously modified during earlier
examples of system-period temporal table operations.
For these examples, the current date is May 1, 2012.
The first query wants to find all trip names in the "travel" table that cost less than $500
as of the 03/01/2012. Since the 03/01/2012 date is less than the current date of
05/01/2012, Db2 will utilize both the base and history table for the query results. In this
type of query it is possible that the base table may not currently contain rows that match
the predicates but the history table contains rows that were valid on 03/01/2012 that
could be returned.
The second query is the typical Db2 SELECT statement that is returning the trip_name
column from the "travel" table where the destination is "Brazil". Since there is no "AS
OF", "BETWEEN", or "FROM" date specified in the query, In this case ONLY the base
table (travel) is queried. This behavior is identical to specifying "FOR SYSTEM _TIME
AS OF CURRENT DATE" on the SELECT statement.
The third query wants to determine the total number of tours that were offered at any
time during 2011. Since this SELECT has added the "FOR SYSTEM _TIME BETWEEN
‘01/01/2011’ AND ‘01/01/2012’" clause, Db2 will access both the base table and history
table to retrieve the query result.

© Copyright IBM Corp. 1997, 2017 5-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Example of an application-period temporal table

• The policy_info table stores the insurance coverage level for a customer
 The BUSINESS_TIME period-related columns (bus_start and bus_end) indicate
when an insurance coverage level is valid
 A PRIMARY KEY declaration is used when creating the policy_info table, ensuring
that overlapping periods of BUSINESS_TIME are not allowed.
 This means that there cannot be two versions of the same policy that are valid at
the same time.

CREATE TABLE POLICY_INFO

( POLICY_ID CHAR(4) NOT NULL,
COVERAGE INT NOT NULL,
BUS_START DATE NOT NULL,
BUS_END DATE NOT NULL,
PERIOD BUSINESS_TIME(BUS_START, BUS_END),
PRIMARY KEY(POLICY_ID, BUSINESS_TIME WITHOUT OVERLAPS)
);

Creating database objects © Copyright IBM Corporation 2017

Example of an application-period temporal table

Application-period temporal tables
An application-period temporal table is a table that stores the in effect aspect of
application data. Use an application-period temporal table to manage data based on
time criteria by defining the time periods when data is valid.
Similar to a system-period temporal table, an application-period temporal table includes
a BUSINESS_TIME period with columns that indicate the time period when the data in
that row is valid or in effect. You provide the begin time and end time for the
BUSINESS_TIME period associated with each row. However, unlike a system time-
period temporal table, there is no separate history table. Past, present, and future
effective dates and their associated business data are maintained in a single table. You
can control data values by BUSINESS_TIME period and use application-period
temporal tables for modeling data in the past, present, and future.
Creating an application-period temporal table results in a table that manages data
based on when its data is valid or in effect.

© Copyright IBM Corp. 1997, 2017 5-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

When creating an application-period temporal table, include a BUSINESS_TIME period

that indicates when the data in a row is valid. You can optionally define that overlapping
periods of BUSINESS_TIME are not allowed and that values are unique with respect to
any period. The example in the shows the creation of a table that stores policy
information for the customers of an insurance company.
In the example, a PRIMARY KEY declaration is used when creating the policy_info
table, ensuring that overlapping periods of BUSINESS_TIME are not allowed. This
means that there cannot be two versions of the same policy that are valid at the same
time.
Example:
CREATE TABLE policy_info
(
policy_id CHAR(4) NOT NULL,
coverage INT NOT NULL,
bus_start DATE NOT NULL,
bus_end DATE NOT NULL,
PERIOD BUSINESS_TIME(bus_start, bus_end),
PRIMARY KEY(policy_id, BUSINESS_TIME WITHOUT OVERLAPS)
);

© Copyright IBM Corp. 1997, 2017 5-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Using an application-period temporal table

• Query with FOR BUSINESS_TIME AS OF specified
SELECT policy_id, coverage, bus_start, bus_end
FROM policy_info
FOR BUSINESS_TIME AS OF '2008-07-15'
where policy_id = 'A123‘

• Query with FOR BUSINESS_TIME FROM...TO specified

SELECT policy_id, coverage, bus_start, bus_end
FROM policy_info
FOR BUSINESS_TIME FROM '2008-01-01' TO '2008-06-15'
where policy_id = 'A123‘

• The coverage for policy A123 shows an increase from 12000 to 16000
on July 1 (2008-07-01), but an earlier increase to 14000 is missing:
UPDATE policy_info
FOR PORTION OF BUSINESS_TIME
FROM '2008-06-01' TO '2008-08-01‘
SET coverage = 14000 WHERE policy_id = 'A123';

Creating database objects © Copyright IBM Corporation 2017

Using an application-period temporal table

When querying an application-period temporal table, you can include FOR
BUSINESS_TIME in the FROM clause. Using FOR BUSINESS_TIME specifications,
you can query the current, past, and future state of your data.
Time periods are specified as follows:
• AS OF value1 -
Includes all the rows where the begin value for the period is less than or equal to
value1 and the end value for the period is greater than value1.
• FROM value1 TO value2
Includes all the rows where the begin value for the period is greater than or equal
to value1 and the end value for the period is less than value2. This means that
the begin time is included in the period, but the end time is not.
• BETWEEN value1 AND value2
Includes all the rows where any time period overlaps any point in time between
value1 and value2. This means that the begin time and end time are both
included in the period.

© Copyright IBM Corp. 1997, 2017 5-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

The first example query uses the FOR BUSINESS_TIME AS OF clause to see if the
Policy A123 had coverage on a specific date 2008-07-15.
SELECT policy_id, coverage, bus_start, bus_end
FROM policy_info
FOR BUSINESS_TIME AS OF '2008-07-15'
where policy_id = 'A123'
The next example query uses the FOR BUSINESS_TIME BETWEEN...AND clause to
retrieve policy information for one Policy for a range of dates.
SELECT policy_id, coverage, bus_start, bus_end
FROM policy_info
FOR BUSINESS_TIME FROM
'2008-01-01' TO '2008-06-15'
where policy_id = 'A123'
Updating data in an application-period temporal table can be similar to updating data in
a regular table, but data can also be updated for specified points of time in the past,
present, or future. Point in time updates can result in rows being split and new rows
being inserted automatically into the table.
In addition to the regular UPDATE statement, application-period temporal tables also
support time range updates where the UPDATE statement includes the FOR PORTION
OF BUSINESS_TIME clause. A row is a candidate for updating if its period-begin
column, period-end column, or both fall within the range specified in the FOR PORTION
OF BUSINESS_TIME clause.
If for example the policy_info table contained coverage for policy A123 and included an
increase from 12000 to 16000 on July 1 (2008-07-01), but an earlier increase to 14000
is missing, the following UPDATE statement could be used:
UPDATE policy_info
FOR PORTION OF BUSINESS_TIME FROM '2008-06-01' TO '2008-08-01'
SET coverage = 14000
WHERE policy_id = 'A123';

© Copyright IBM Corp. 1997, 2017 5-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Data row compression summary

• COMPRESS option for CREATE and ALTER TABLE is used to specify
compression
• Compression uses a static dictionary:
 Dictionary stored in data object, about 100K in size
 Compression Dictionary needs to be built before a row can be compressed
 Dictionary can be built or rebuilt using REORG TABLE offline, which also
compresses existing data
 A dictionary is built automatically when a table reaches a threshold size
(about 2 MB). This applies to SQL INSERT as well as IMPORT and LOAD.
• Compression is intended to:
 Reduce disk storage requirements
 Reduce I/Os for scanning tables
 Reduce buffer pool memory for storing data
• Compression for Indexes, Temporary data and XML data is also
supported
Creating database objects © Copyright IBM Corporation 2017

Data row compression summary

You can use less disk space for your tables by taking advantage of the Db2 table
compression capabilities. Compression saves disk storage space by using fewer
database pages to store data.
Also, because you can store more rows per page, fewer pages must be read to access
the same amount of data. Therefore, queries on a compressed table need fewer I/O
operations to access the same amount of data. Since there are more rows of data on a
buffer pool page, the likelihood that needed rows are in the buffer pool increases. For
this reason, compression can improve performance through improved buffer pool hit
ratios. In a similar way, compression can also speed up backup and restore operations,
as fewer pages of need to be transferred to the backup or restore the same amount of
data.
You can use compression with both new and existing tables. Temporary tables are also
compressed automatically, if the database manager deems it to be advantageous to do
so.
There are two main types of data compression available for tables:
• Row compression.
• Value compression

© Copyright IBM Corp. 1997, 2017 5-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

For a particular table, you can use row compression and value compression together or
individually. However, you can use only one type of row compression for a particular
table.
Classic row compression, sometimes referred to as static compression, compresses
data rows by replacing patterns of values that repeat across rows with shorter symbol
strings.
The benefits of using classic row compression are similar to those of adaptive
compression, in that you can store data in less space, which can significantly save
storage costs. Unlike adaptive compression, however, classic row compression uses
only a table-level dictionary to store globally recurring patterns; it doesn't use the page-
level dictionaries that are used to compress data dynamically.
How classic row compression works
Classic row compression uses a table-level compression dictionary to compress data
by row. The dictionary is used to map repeated byte patterns from table rows to much
smaller symbols; these symbols then replace the longer byte patterns in the table rows.
The compression dictionary is stored with the table data rows in the data object portions
of the table.
What data gets compressed?
Data that is stored in base table rows and log records is eligible for classic row
compression. In addition, the data in XML storage objects is eligible for compression.
You can compress LOB data that you place inline in a table row; however, storage
objects for long data objects are not compressed.
Compression for temporary tables
Compression for temporary tables is enabled automatically with the Db2 Storage
Optimization Feature. Only classic row compression is used for temporary tables.
System temporary tables
When executing queries, the Db2 optimizer considers the storage savings and the
impact on query performance that compression of system-created temporary tables
offers to determine whether it is worthwhile to use compression. If it is worthwhile,
classic row compression is used automatically. The minimum size that a table must be
before compression is used is larger for temporary tables than for regular tables.
User-created temporary tables
Created global temporary tables (CGTTs) and declared global temporary tables
(DGTTs) are always compressed using classic row compression.
You can use the explain facility or the db2pd tool to see whether the optimizer used
compression for system temporary tables.

© Copyright IBM Corp. 1997, 2017 5-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Adaptive compression with Db2

• Adaptive compression is an enhancement to the classic row
compression
 Compress rows by using a combination of two types of dictionaries
− Global static table-level dictionary
− Local page-level dictionaries
TABLE
• Benefits
 Page level dictionaries adapt to data skew Db2 page Static
over a period of time Dynamic page
table
level
level dictionary
− No REORGs required to maintain high dictionary

compression ratio as data changes

Db2 page Db2 page
 Less disk space for data and logs
Dynamic page
− 2x
Dynamic page
storage savings for tables level dictionary level dictionary

over Classic Row Compression

− 5x-8x overall table compression
 Reduced I/O - Fewer pages to process

 Better compression ratios than Classic Row Compression

 Over time reduces need of a REORG to find locally recurring patterns

Creating database objects © Copyright IBM Corporation 2017

Adaptive compression with Db2

Adaptive compression
Adaptive compression, was introduced with Db2 10.1, improves upon the compression
rates that can be achieved using classic row compression by itself. Adaptive
compression incorporates classic row compression; however, it also works on a page-
by-page basis to further compress data. Of the various data compression techniques in
the Db2 product, adaptive compression offers the most dramatic possibilities for storage
savings.
How adaptive compression works
Adaptive compression actually uses two compression approaches. The first employs
the same table-level compression dictionary used in classic row compression to
compress data based on repetition within a sampling of data from the table as a whole.
The second approach uses a page-level dictionary-based compression algorithm to
compress data based on data repetition within each page of data. The dictionaries map
repeated byte patterns to much smaller symbols; these symbols then replace the longer
byte patterns in the table. The table-level compression dictionary is stored within the
table object for which it is created, and is used to compress data throughout the table.
The page-level compression dictionary is stored with the data in the data page, and is
used to compression only the data within that page.

© Copyright IBM Corp. 1997, 2017 5-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Turning adaptive compression on or off

You compress table data by setting the COMPRESS attribute of the table to YES. You
can set this attribute when you create the table by specifying the COMPRESS YES
option for the CREATE TABLE statement. You can also alter an existing table to use
compression by using the same option for the ALTER TABLE statement. After you
enable compression, operations that add data to the table, such as an INSERT, LOAD
INSERT, or IMPORT INSERT command operation, can use adaptive compression. In
addition, index compression is enabled for the table. Indexes are created as
compressed indexes unless you specify otherwise and if they are the types of indexes
that can be compressed.

© Copyright IBM Corp. 1997, 2017 5-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

How Does Adaptive Compression Work? Step 1

[1] California
• Step 1: Compression with static table level dictionary [2]
[3]
San
Jose
[4] Francisco
Christine Haas (408) 463-1234 555 Bailey Avenue San Jose California 95141 [5] Avenue
John Thompson (408) 463-5678 555 Bailey Avenue San Jose California 95141
[6] Street
Jose Fernandez (408) 463-1357 555 Bailey Avenue San Jose California 95141
Margaret Miller (408) 463-2468 555 Bailey
[7] Road
4400 NorthAvenue
1st San Jose California 95141
Bruce Kwan (408) 956-9876 Street
4400 North 1st San Jose California 95134
James Geyer (408) 956-5432 Street
4400 North 1st San Jose California 95134
Linda Hernandez (408) 956-9753 Street San Jose California 95134
Theodore Mills (408) 927-8642 650 Harry Road San Jose California 95134 Compression with
Susan Stern (408) 927-9630 650 Harry Road San Jose
San California 95134 global table static
James Polaski (415) 545-1423 425 Market Street SanFrancisco California 94105
John Miller (415) 545-5867 425 Market Street
dictionary
SanFrancisco California 94105
James Walker (415) 545-4132 425 Market Street SanFrancisco California 94105
Elizabeth Brown (415) 545-8576 425 Market Street SanFrancisco California 94105
Sarah Johnson (415) 545-1928 425 Market Street Francisco California 94105

Christine Haas (408) 463-1234 555 Bailey [5] [2][3] [1] 95141

• Table-level compression symbol John

[3]
Thompson
Fernandez
(408) 463-5678
(408) 463-1357
555 Bailey [5]
555 Bailey [5]
[2][3]
[2][3]
[1]
[1]
95141
95141

dictionary containing globally Margaret

Bruce
Schneider
Kwan
(408) 463-2468
(408) 956-9876
555 Bailey [5]
4400 North 1st [6]
[2][3]
[2][3]
[1]
[1]
95141
95134

recurring patterns James

Linda
Geyer
Hernandez
(408) 956-5432
(408) 956-9753
4400 North 1st [6]
4400 North 1st [6]
[2][3]
[2][3]
[1]
[1]
95134
95134

• Table-level dictionary can only be Theodore

Susan
Mills
Stern
(408) 927-8642
(408) 927-9630
650 Harry [7]
650 Harry [7]
[2][3]
[2][3]
[1]
[1]
95134
95134
James Polaski (415) 545-1423 425 Market [6] [2][4] [1] 94105
rebuilt during classic table REORG John Miller (415) 545-5867 425 Market [6] [2][4] [1] 94105
James Walker (415) 545-4132 425 Market [6] [2][4] [1] 94105
 Involves re-compressing all data Elizabeth Miller (415) 545-8576 425 Market [6] [2][4] [1] 94105
Sarah Johnson (415) 545-1928 425 Market [6] [2][4] [1] 94105

Creating database objects © Copyright IBM Corporation 2017

How Does Adaptive Compression Work? Step 1

Adaptive compression must always start with a Classic compression dictionary. This
compression dictionary is similar to prior versions of Db2. The STATIC dictionary
contains patterns of frequently used data that is found ACROSS the entire table. Either
a classic reorg must be used for existing tables to generate this STATIC dictionary, or
the dictionary gets built when a table hits a threshold of data (typically 1-2MB of data)
when using AUTOMATIC COMPRESSION.
A customer needs to be aware that altering a table to use ADAPTIVE compression will
cause the following:
1. Automatic dictionary creation will be done once about 2M of data is populated in
the table
2. All of the data in the table PRIOR to the STATIC dictionary being created will
not be “TABLE” compressed. They are eligible for ADAPTIVE compression
however
3. A full OFFLINE REORG will be required if you want to compress all of the data
in the table

© Copyright IBM Corp. 1997, 2017 5-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

How Does Adaptive Compression Work? Step 2

(1) ernandez

• Step 2: Compression w/ Page-Level Dictionaries (2) (408) 463-

Christine Haas (2)1234 (4)
(3) (408) 956-
Christine Haas (408) 463-1234 555 Bailey [5] [2][3] [1] 5141 John Thompson (2)5678 (4)
(4) 555 Bailey [5] [2][3] [1] 5141
John Thompson (408) 463-5678 555 Bailey [5] [2][3] [1] 5141 Ellen F(1) (2)1357 (4)
(5) 4400 North 1st [6] [2][3] [1] 5134
Ellen Fernandez (408) 463-1357 555 Bailey [5] [2][3] [1] 5141 Margaret Schneider (2)2468 (4)
Data page

Margaret Schneider (408) 463-2468 555 Bailey [5] [2][3] [1] 5141 Page level dictionary
Bruce Kwan (3)9876 (5)
Bruce Kwan (408) 956-9876 4400 North 1st [6] [2][3] [1] 5134
James Geyer (3)5432 (5)
James Geyer (408) 956-5432 4400 North 1st [6] [2][3] [1] 5134
Linda H(1) (3)9753 (5) (1) James
Linda Hernandez (408) 956-9753 4400 North 1st [6] [2][3] [1] 5134
(2) John
(3) Mill
[9]odore Mills (408) 927-8642 650 Harry [7] [2][3] [1] 5134
(4) (408) 927-
Susan Stern (408) 927-9630 650 Harry [7] [2][3] [1] 5134 [9]odore (3)s (4)8642 (6) (5) (408) 956-
James Polaski (415) 545-1423 425 Market [6] [2][4] [1] 4105 Susan Stern (4)9630 (6) (6) 650 Harry [7] [2][3] [1] 5134
Data page

John Miller (415) 545-9876 425 Market [6] [2][4] [1] 4105 (7) 425 Market [6] [2][4] [1] 4105
(1) Polaski (5)1423 (7)
James Walker (408) 956-4132 425 Market [6] [2][4] [1] 4105
(2) (3)er (5)9876 (7) Page level dictionary
[8] Miller (408) 956-8576 425 Market [6] [2][4] [1] 4105
(1) Walker (5)4132 (7)
Sarah Johnson (408) 956-1928 425 Market [6] [2][4] [1] 4105
[8] (3)er (5)8576 (7)
Sarah (2)son (5)1928 (7)

• Page-level compression dictionaries contain locally frequent patterns

• Page-level compression dictionary building and rebuilding is fully automatic
• Algorithm optimized for compressing data already compressed by
table-level dictionary
• Page-level compression dictionaries are stored as special records in
each page
Creating database objects © Copyright IBM Corporation 2017

How Does Adaptive Compression Work? Step 2

Once a STATIC dictionary is built, Db2 will create local page-level dictionaries. In the
case of individual pages, there may be recurring patterns that may not have been
picked up by the STATIC dictionary. This will also be the case as more data is added to
the table since new pages may contain patterns of data that did not exist when the
original STATIC dictionary was created.
This ADAPTIVE compression places a small dictionary on the page itself. The algorithm
will decide whether or not the savings of compression outweigh the costs of storing the
dictionary – similar to the way that STATIC compression may not compress rows on a
page. The actual process of creating the page dictionary is dependent on whether or
not a “threshold” is met. Rebuilding a page dictionary for every INSERT, UPDATE, or
DELETE will result in a very high amount of overhead. Instead, the algorithm checks to
see how “stale” the dictionary is and updates it when it believes that higher savings can
be achieved.

© Copyright IBM Corp. 1997, 2017 5-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

db2look examples
• To capture all of the DDL for a database (includes all tables, views, RI,
constraints, triggers, and so on):
db2look -d proddb -e -o [Link]
{Edit the output file and change the database name}
db2 -tvf [Link]

• To capture the DDL for one table in particular (table1 in this example):
db2look -d proddb -e -t table1 -o [Link]
{Edit the output file and change the database name}
db2 -tvf [Link]

• To capture the DDL for all of the tables belonging to a particular

schema (db2user in this example):
db2look -d proddb -e -z db2user -o [Link]
{Edit the output file and change the database name}
db2 -tvf [Link]

Creating database objects © Copyright IBM Corporation 2017

db2look examples
The db2look command extracts the Data Definition Language (DDL) statements that
are required to reproduce the database objects of a production database on a test
database. The db2look command generates the DDL statements by object type. Note
that this command ignores all objects under SYSTOOLS schema except user-defined
functions and stored procedures.
It is often advantageous to have a test system that contains a subset of the data of a
production system, but access plans selected for such a test system are not necessarily
the same as those that would be selected for the production system. However, using
the db2look tool, you can create a test system with access plans that are similar to
those that would be used on the production system. You can use this tool to generate
the UPDATE statements that are required to replicate the catalog statistics on the
objects in a production database on a test database. You can also use this tool to
generate UPDATE DATABASE CONFIGURATION, UPDATE DATABASE MANAGER
CONFIGURATION, and db2set commands so that the values of query optimizer-
related configuration parameters and registry variables on a test database match those
of a production database.

© Copyright IBM Corp. 1997, 2017 5-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

You should check the DDL statements that are generated by the db2look command
because they might not reproduce all characteristics of the original SQL objects. For
table spaces on partitioned database environments, DDL might not be complete if some
database partitions are not active. Make sure all database partitions are active using
the ACTIVATE DATABASE command.
Authorization
SELECT privilege on the system catalog tables.
In some cases, such as generating table space container DDL, you will require one of
the following authorities:
• SYSADM
• SYSCTRL
• SYSMAINT
• SYSMON
• DBADM
• EXECUTE privilege on the ADMIN_GET_STORAGE_PATHS table function
The db2look command can extracts DDL statements for the following database objects:
• Aliases
• Audit policies
• Check constraints
• Function mappings
• Function templates
• Global variables
• Indexes (including partitioned indexes on partitioned tables)
• Index specifications
• Materialized query tables (MQTs)
• Nicknames
• Primary key, referential integrity, and check constraints
• Referential integrity constraints
• Roles
• Schemas
• Security labels

© Copyright IBM Corp. 1997, 2017 5-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

• Security label components

• Security policies
• Sequences
• Servers
• Stored procedures
• Tables
Note: Values from column STATISTICS_PROFILE in the [Link]
catalog table are not included.
• Triggers
• Trusted contexts
• Type mappings
• User mappings
• User-defined distinct types
• User-defined functions
• User-defined methods
• User-defined structured types
• User-defined transforms
• Views
• Wrappers

© Copyright IBM Corp. 1997, 2017 5-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Demonstration 1
Creating database objects
• Create a set of tables using the Data Server Manager to build the
CREATE TABLE statement or using saved DDL in a file.
• Create indexes for tables using the CREATE INDEX statement.
• Create views and alias objects using SQL statements in a file.
• Create foreign key and check constraints for a table using SQL
statements in a file.
• Use the db2look utility to extract database object definitions from a
Db2 database.

Creating database objects © Copyright IBM Corporation 2017

Demonstration 1: Creating database objects

© Copyright IBM Corp. 1997, 2017 5-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Demonstration 1:
Creating database objects
Purpose:
This demonstration will create a group of database objects in the Db2
database named MUSICDB.

Task 1. Logon to the Linux system and start a terminal

session for running Db2 commands
1. Logon to the Linux system using the user id inst23, 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.
A set of course files are located in the directory $HOME/ddl. Change to this
directory to make it easier to access these files that contain Db2 commands or
SQL statements.
3. Enter the following commands using the Linux terminal session:
• cd $HOME/ddl
• db2 connect to musicdb
Task 2. Create the ALBUMS table.
At this point, you may choose to create the ALBUMS table by using the Db2 command
line processor or the Data Server Manager tool. Follow the steps for your chosen tool
only.
2A. Use the Db2 command line processor.
1. Use the file $HOME/ddl/create_table_albums.ddl to create the ALBUMS table
with a Primary key defined on the ITEMNO column.
The file contains the following statement text:
create table [Link]
(title varchar (50),
artno smallint not null,
itemno smallint not null)
in tsp04
index in tsp05;

alter table [Link] primary key (itemno) ;

© Copyright IBM Corp. 1997, 2017 5-68

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

2. Enter the following commands using the Linux terminal session:

• db2 -tvf create_table_albums.ddl
• db2 describe table [Link]
You can now skip to Task 3.
2B. Use the Data Server Manager tool.
You can use the Data Server Manager tool to create tables either by defining the table
definition or by running a SQL file that contains the Data Definition Language
statements.
Open a Firefox Browser and select Bookmarks > Bookmarks Toolbar > Log in: IBM
Data Server Manager. Alternatively, you could type the following URL text to start
DSM, [Link]
When DSM was installed, a local user id and password were selected to be associated
with the application. For this course the following were configured:
Linux System user id: db2admin
User password: ibm2blue
Use DSM to create a new table in the MUSICDB database.
1. If you are prompted for a userid and password for the MUSICDB database
connection, use inst23 with a password of ibm2blue.
2. Select Administer > Schemas from the options on the left.
The tables you will create will use a single schema name of MUSIC. You will
create the new schema named MUSIC.
The schemas created to support the new database will be listed.
3. At the top left corner, click Create to open a list of options to define a new
schema, and then enter the following values for the new schema:
Schema: MUSIC (use upper case)
Allow other options to take default values
The DSM tool generates the CREATE SCHEMA statement. Click on the (+)
next to the Command.
The command text should be the following:
CREATE SCHEMA "MUSIC";
4. At the bottom, click Run.
The result should show that the command processing succeeded.
5. Close the Create Schema tab.
Now you can create a table, ALBUMS, in the new schema, MUSIC.

© Copyright IBM Corp. 1997, 2017 5-69

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

6. Using the options on the left, click Administer >Tables.

7. At the top, click Create to open a list of options to define a new table.
8. Enter the following values for the PROPERTIES of the new table. You can use
the box next to a property to select from lists of valid responses.
Name: ALBUMS
Schema: MUSIC
Table space: TSP04
Index table space: TSP05
9. Under the Create Table tab, click Columns to define the table columns.
10. Click Add column to define a column, using:
Name: TITLE
Data Type: Varchar
Length: 50
11. Click Columns to return to the column list.
12. Click Add column to define a column, using:
Name: ARTNO
Data Type: Smallint
Nullable: No
13. Click Columns to return to the column list.
14. Click Add column to define a column, using:
Name: ITEMNO
Data Type: Smallint
Nullable: No
15. Click Constraints.
16. Click Add constraint to define a constraint, select Primary key as the
constraint type, using:
Name: ALBUM_ITEM
17. Click Add, and then select the column ITEMNO.
18. The DSM tool generates the CREATE TABLE statement and the ALTER
TABLE statement to add the primary key. Click on the (+) next to the
Command.

© Copyright IBM Corp. 1997, 2017 5-70

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

19. If the ALTER TABLE statement that adds the primary key includes the NOT
ENFORCED option select EDIT and remove this option.
20. Click Run > Run All.
The result should show that the command processing succeeded.
Task 3. Create a set of new tables using a SQL file.
You will create a group of tables using a SQL file containing the CREATE TABLE
statements.
At this point, you may choose to create the ALBUMS table by using the Db2 command
line processor or the Data Server Manager tool. Follow the steps for your chosen tool
only.
3A. Use the Db2 command line processor.
The file $HOME/ddl/create_tables.ddl contains five CREATE TABLE statements.
The file contains the following statement text:
create table [Link]
(artno smallint not null,
date date not null,
city varchar (25) not null with default)
in tsp04;

create table [Link]

(itemno smallint not null,
timestamp timestamp)
in TSP02;

create table [Link]

(artno smallint not null,
name varchar(50),
classification char(1) not null,
bio clob(100K) logged compact,
picture blob(500K) not logged compact,
primary key (artno))
in tsp01
index in tsp02
long in tsp03;

© Copyright IBM Corp. 1997, 2017 5-71

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

create table [Link]

(ITEMNO SMALLINT NOT NULL ,
TYPE CHAR(1) NOT NULL ,
PRICE DECIMAL(5,2) NOT NULL WITH DEFAULT ,
QTY INTEGER NOT NULL WITH DEFAULT,
SYS_START TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN
IMPLICITLY HIDDEN,
SYS_END TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END
IMPLICITLY HIDDEN,
TX_START TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION
START ID IMPLICITLY HIDDEN,
PERIOD SYSTEM_TIME (SYS_START,SYS_END) )
in tsp06;

CREATE TABLE MUSIC.STOCK_HISTORY LIKE [Link] IN tsp06;

ALTER TABLE [Link] ADD VERSIONING USE HISTORY TABLE

MUSIC.STOCK_HISTORY;
1. Enter the following commands using the Linux terminal session:
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_tables.ddl | more
• db2 list tables for schema music
You can now skip to Task 4.
3B. Use the Data Server Manager tool.
You can use the DSM tool to execute the SQL file containing the CREATE TABLE
statements.
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/create_tables.ddl.
3. Click Open, then OK to complete loading the SQL text into the SQL editor.
Review the options specified for the five CREATE TABLE statements.
The table [Link] will be defined as a System-period temporal table.
The table MUSIC.STOCK_HISTORY will be used as the history table for
[Link].
Notice the assignments of tables to table spaces.

© Copyright IBM Corp. 1997, 2017 5-72

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

For DMS and Automatic Storage Managed table spaces, multiple table spaces
can be used for the data, index and large object components of a single table.
Which table space(s) will be used for data, indexes and large objects for the
table STOCK? For CONCERTS? For ARTISTS?
4. Click Run > Run All and wait for the SQL statements to be processed.
The result should show that all of the statements succeeded. You may click on
Log under VIEW RESULTS to review each statement execution.
Task 4. Create index, view and alias objects for the
application tables.
Next you will create an index on the STOCK table based on the column ITEMNO.
You will also use the SQL statements in the file create_View_Alias.ddl to create view
and alias objects.
The file $HOME/ddl/create_stock_ix.ddl contains the CREATE INDEX statement.
The file contains the following statement text:
create index music.stockitem_ix on [Link](itemno) ;
The file $HOME/ddl/create_VIEW_ALIAS.ddl contains the following statements:
create view [Link] as select title, classification, name
from [Link] alb, [Link] art
where [Link] = [Link] ;

create view [Link] (type, itemno, totcost, totqty)

as select type, itemno, sum (price * qty), sum (qty)
from [Link] group by type, itemno;

create alias [Link] for [Link] ;

create alias [Link] for [Link] ;

At this point, you may choose to create the new index, view, and alias objects using the
Db2 command line processor or the Data Server Manager tool. Follow the steps for
your chosen tool only.

© Copyright IBM Corp. 1997, 2017 5-73

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

4A. Use the Db2 command line processor.

1. Enter the following commands using the Linux terminal session:
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_stock_ix.ddl
• db2 describe indexes for table [Link]
• db2 -tvf create_VIEW_ALIAS.ddl
• db2 list tables for schema music
You can now skip to Task 5.
4B. Use the Data Server Manager tool.
You can use the DSM tool to create the index, view and alias objects.
1. Select Administer > Indexes, from the options on the [Link] current index
objects will be listed.
2. Click Create to open a list of options to define a new index. Select the
[Link] table from the table list and click OK.
3. Enter the following values for the index:
Name: STOCKITEM_IX
Members: select Add, then select the ITEMNO column
Leave other options with default values
4. Click on the (+) next to the Command. The DSM tool generates the CREATE
INDEX statement that will define the new index named STOCKITEM_IX.
The command text should be similar to the following:
CREATE INDEX MUSIC.STOCKITEM_IX ON [Link] (ITEMNO ASC);
5. Click Run.
Wait for the command to be processed.
The result should show that the command processing succeeded.
If you refresh the index list, you should see the new index included in the list.
Now you will use DSM to execute the SQL statements in the file
create_VIEW_ALIAS.ddl to create view and alias objects.
6. Click Run SQL from the options on the left. Clear any SQL statements from the
editor that may remain from previous steps.
7. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/create_VIEW_ALIAS.ddl.

© Copyright IBM Corp. 1997, 2017 5-74

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

8. Click Open, then OK to complete loading of the SQL text into the SQL editor.
Review the options specified for the CREATE VIEW and CREATE ALIAS
statements.
9. Click Run > Run All and wait for the SQL statements to be processed.
In the result area you can click on Log to view messages. You should see that all of the
statements succeeded. You may click on Log under VIEW RESULTS to review each
statement execution.
Task 5. Create several table constraints and a trigger.
You will now create the following database objects:
A foreign key constraint for the ALBUMS table that references the ARTNO column of
the ARTISTS table.
A foreign key constraint for the STOCK table that references the ITEMNO column of the
ALBUMS table.
A check constraint for the CCTYPE column of the STOCK table.
A TRIGGER for the STOCK table that inserts a row into the REORDER table when the
QTY column of the STOCK table is updated with a value of 5 or less.
At this point, you may choose to create the database objects using the Db2 command
line processor or the Data Server Manager tool. Follow the steps for your chosen tool
only.
5A. Use the Db2 command line processor.
The file $HOME/ddl/create_ri.[Link] contains following statements.
alter table [Link] add constraint ARTNO_FK
foreign key (artno) references [Link] (artno)
on delete cascade on update no action;

alter table [Link]

foreign key ITEMNO_FK (itemno)
references [Link] on delete restrict;

alter table [Link]

add constraint cctype check (type in ('D', 'C', 'R'));
The file $HOME/ddl/create_trigger.ddl contains following statement.
create trigger [Link]
after update of qty on [Link]
referencing new as n
for each row
mode db2sql
when ([Link] <= 5)
insert into [Link] values ([Link], current timestamp);

© Copyright IBM Corp. 1997, 2017 5-75

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

1. Issue the following series of commands using the Db2 command line processor.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_ri_cc.ddl
• db2 -tvf create_trigger.ddl
You can now skip to Task 6.
5B. Use the Data Server Manager tool.
You can use the DSM tool to execute the SQL file containing the ALTER TABLE
statements to create referential integrity and check constraints.
1. On the left, click Run SQL Clear any SQL statements from the editor that may
remain from previous steps.
2. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/create_ri_cc.ddl.
3. Click Open.
4. Click OK to complete loading of the SQL text into the SQL editor.
Review the options specified for the SQL statements.
5. Click Run > Run All and wait for the SQL statements to be processed.
The result should show that all statements succeeded. You may click on Log
under VIEW RESULTS to review each statement execution.
You can use the file inst23/ddl/create_trigger.ddl in the SQL Editor to define a
new trigger. Clear any SQL statements from the editor that may remain from
previous steps.
6. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/ create_trigger.ddl.
7. Click Open then OK to complete the loading of the SQL text into the SQL
editor.
Review the options specified for the SQL statements.
The new trigger should be similar to the following:
create trigger [Link]
after update of qty on [Link]
referencing new as n
for each row
mode db2sql
when ([Link] <= 5)
insert into [Link] values ([Link], current timestamp);

© Copyright IBM Corp. 1997, 2017 5-76

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

8. Click Run > Run All and wait for the SQL statement to be processed.
The result should show that the command processing succeeded.
Task 6. Use the db2look command line tool to generate the
DDL statements to create database objects.
You will use the db2look tool to extract selected DDL statements from the MUSICDB
database.
1. Issue the following series of commands using the Db2 command line processor
to generate the DDL associated with the ALBUMS table and save the output in
a file named [Link]:
• cd $HOME/ddl
• db2look -d musicdb -e -z music -t albums -o [Link]
2. Review the generated statements placed into the file [Link], by issuing
the command:
• more [Link]
The file [Link] will contain DDL statements similar to the following:
-- This CLP file was created using DB2LOOK Version "11.1"
-- Timestamp: 8/17/2015 [Link] AM
-- Database Name: MUSICDB
-- Database Manager Version: DB2/LINUXX8664 Version 11.1.
-- Database Codepage: 1208
-- Database Collating Sequence is: IDENTITY
-- Alternate collating sequence(alt_collate): null
-- varchar2 compatibility(varchar2_compat): OFF

CONNECT TO MUSICDB;

------------------------------------------------
-- DDL Statements for Table "MUSIC "."ALBUMS"
------------------------------------------------

CREATE TABLE "MUSIC "."ALBUMS" (

"TITLE" VARCHAR(50 OCTETS) ,
"ARTNO" SMALLINT NOT NULL ,
"ITEMNO" SMALLINT NOT NULL )
IN "TSP04" INDEX IN "TSP05"
ORGANIZE BY ROW;

-- DDL Statements for Primary Key on Table "MUSIC "."ALBUMS"

© Copyright IBM Corp. 1997, 2017 5-77

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

ALTER TABLE "MUSIC "."ALBUMS"

ADD CONSTRAINT "ALBUM_ITEM" PRIMARY KEY
("ITEMNO");

-- DDL Statements for Foreign Keys on Table "MUSIC "."ALBUMS"

ALTER TABLE "MUSIC "."ALBUMS"

ADD CONSTRAINT "ARTNO_FK" FOREIGN KEY
("ARTNO")
REFERENCES "MUSIC "."ARTISTS"
("ARTNO")
ON DELETE CASCADE
ON UPDATE NO ACTION
ENFORCED
ENABLE QUERY OPTIMIZATION;

-- DDL Statements for Views

----------------------------
SET CURRENT SCHEMA = "INST23 ";
SET CURRENT PATH = "SYSIBM","SYSFUN","SYSPROC","SYSIBMADM","INST23";
create view [Link] as select title, classification, name
from [Link] alb, [Link] art
where [Link] = [Link];

COMMIT WORK;

CONNECT RESET;

TERMINATE;

Results:
You created a group of database objects in the Db2 database named
MUSICDB.

© Copyright IBM Corp. 1997, 2017 5-78

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

Unit summary
• Describe the Db2 object hierarchy
• Create the following objects:
 Schema, Table, View, Alias, Index
• Review the use of temporary tables
• Explore the use and implementation of check constraints, referential
integrity and triggers
• Utilize BLU Acceleration, column-organized tables to improve analytics
query performance
• Explain the difference between system-period temporal tables and
Application-period temporal tables
• List the types of compression available for tables and indexes
• Use the db2look utility to export database structures for future use

Creating database objects © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 5-79

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 5 Creating database objects

© Copyright IBM Corp. 1997, 2017 5-80

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Moving data

Moving data

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 U n i t 6 M o vi n g d a t a

© Copyright IBM Corp. 1997, 2017 6-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Unit objectives
• Discuss using the INSERT SQL statement to populate tables
• Explain the differences between IMPORT and LOAD processing
• Explain the EXPORT, IMPORT, and LOAD command options
• Create and use Exception Tables and Dump-Files
• Check table status using LOAD QUERY
• Describe the ANALYZE phase of LOAD command processing used for
loading BLU Acceleration, column-organized tables.
• Check the Load Pending and Set Integrity Pending status for a table
• Use the SET INTEGRITY command
• Discuss the db2move and db2look commands
• Use the ADMIN_MOVE_TABLE procedure to move a table to different
table spaces
• List some of the features of the Ingest utility for continuous data ingest
Moving data © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 6-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Review INSERT statement

• The SQL INSERT statement can insert one or more rows of data into
tables, nicknames, or views:
 SQL overhead is imposed, such as obeying RI, or Check Constraints, or
Uniqueness, or executing triggers.
 As INSERTs occur, the activity is also stored in logs
• The SQL INSERT might not be the best or fastest method to load
massive amounts of data into a database
Example inserts:

INSERT INTO ARTISTS (artno, name,classification)

values (100, 'Patti & Cart Wheels', 'S') ;

INSERT INTO EMPTEMP SELECT * FROM EMPLOYEE ;

Moving data © Copyright IBM Corporation 2017

Review INSERT statement

The INSERT statement inserts rows into a table, nickname, or view, or the underlying
tables, nicknames, or views of the specified fullselect. Inserting a row into a nickname
inserts the row into the data source object to which the nickname refers.
Inserting a row into a view also inserts the row into the table on which the view is based,
if no INSTEAD OF trigger is defined for the insert operation on this view. If such a
trigger is defined, the trigger will be executed instead.

© Copyright IBM Corp. 1997, 2017 6-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

EXPORT command syntax (Basic)

>>-EXPORT TO--filename--OF--filetype---------------------------->

>--+-----------------------+--+-----------------------+--------->
| .-,--------. | | .-,--------. |
| V | | | V | |
'-LOBS TO----lob-path-+-' '-LOBFILE----filename-+-'
>--+----------------------+--+-----------------------+---------->
| .-,--------. | | .-,--------. |
| V | | | V | |
'-XML TO----xml-path-+-' '-XMLFILE----filename-+-'
>--+-------------------------------+--+---------------+--------->
| .--------------. | '-XMLSAVESCHEMA-'
| V | |
'-MODIFIED BY----filetype-mod-+-'

>--+---------------------------------+-------------------------->
| .-,-----------. |
| V | |
'-METHOD N--(----column-name-+--)-'

>--+------------------------+----------------------------------->
'-MESSAGES--message-file-'

>--+-select-statement---------------------------------------+--><

+-XQUERY--xquery-statement- ------------------------------+

Moving data © Copyright IBM Corporation 2017

EXPORT command syntax (Basic)

The EXPORT command can be used to export data from a database to one of several
external file formats. The user specifies the data to be exported by supplying an
SQL SELECT statement.
File types that are supported include:
• DEL (delimited ASCII format), which is used by a variety of database manager
and file manager programs.
• IXF (Integration Exchange Format, PC version) is a proprietary binary format.
This file type can be used to move data between operating systems.
The MODIFIED BY options allow you to specify different items depending on the file
type being created. For example, for delimited output data, you can specify the
character string delimiter and the column delimiter. The Information Center can be used
to list all of the supported options.

© Copyright IBM Corp. 1997, 2017 6-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Some of the EXPORT command parameters include the following:

• LOBS TO lob-path
Specifies one or more paths to directories in which the LOB files are to be stored.
There will be at least one file per LOB path, and each file will contain at least one
LOB. The maximum number of paths that can be specified is 999.
• LOBFILE filename
Specifies one or more base file names for the LOB files. When name space is
exhausted for the first name, the second name is used, and so on. The maximum
number of file names that can be specified is 999.
• MODIFIED BY filetype-mod
Specifies file type modifier options.
• lobsinfile: lob-path specifies the path to the files containing LOB data.
• Xmlinsepfiles: Each XQuery Data Model (QDM) instance is written to a
separate file. By default, multiple values are concatenated together in the
same file.
• Lobsinsepfiles: Each LOB value is written to a separate file. By default,
multiple values are concatenated together in the same file.
• xmlnodeclaration: QDM instances are written without an XML declaration
tag. By default, QDM instances are exported with an XML declaration tag at
the beginning that includes an encoding attribute.
• Xmlchar: QDM instances are written in the character codepage. Note that the
character codepage is the value specified by the CODEPAGE file type
modifier, or the application codepage if it is not specified. By default, QDM
instances are written out in Unicode.
• Xmlgraphic: QDM instances are written in the graphic codepage. Note that
the graphic codepage is the graphic component of the value specified by the
CODEPAGE file type modifier, or the graphic component of the application
codepage if it is not specified. By default, QDM instances are written in
Unicode.
• MESSAGES message-file
Specifies the destination for warning and error messages that occur during an
export operation (the path must exist).

© Copyright IBM Corp. 1997, 2017 6-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

EXPORT command example

• Exports data from database tables to file
 SELECT statement can reference tables, views, alias and can include joins,
GROUP BY and ORDER BY
• Check message for error or warning messages
Db2
MUSICDB
EXPORT
[Link]
[Link]

db2 connect to musicdb

db2 export to [Link] of del
messages artmsg
select artno, name from [Link]
Moving data © Copyright IBM Corporation 2017

EXPORT command example

To export, you must have one of the following authorities:
• DATAACCESS authority
• CONTROL or SELECT privilege on each participating table or view
Any SELECT statement can be used to get the data to be exported.
When the SQL SELECT uses the form SELECT * FROM one table, the exported IXF
file would contain additional metadata, like the index definitions for the source table.
Some table types, like range partitioned tables will not generate metadata in an IXF
formatted file that could be used to recreate the original table definition.

© Copyright IBM Corp. 1997, 2017 6-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

IMPORT command syntax (Basic)

IMPORT FROM filename OF filetype

...
,
LOBS FROM lob-path
ALLOW NO ACCESS

ALLOW WRITE ACCESS

MODIFIED BY filetype-mod

COMMITCOUNT n/ RESTARTCOUNT n MESSAGES message-file

Automatic
INSERT INTO table-name
,
INSERT_UPDATE
REPLACE ( insert-column )
REPLACE_CREATE
CREATE INTO table-name | tblspace-specs |
,
( insert-column )

tblspace-specs

| |
IN tablespace-name
INDEX IN tablespace-name LONG IN tablespace-name
Moving data © Copyright IBM Corporation 2017

IMPORT command syntax (Basic)

The syntax of the IMPORT command is shown. More information on its options will be
shown via examples on the following pages.
As default during the import an exclusive (X) lock is on the target table. This prevents
concurrent applications from accessing table data. With the ALLOW WRITE ACCESS
option, the import runs in online mode. An intent exclusive (IX) is set on the target table.
This allows concurrent readers and writers to access the table data. ALLOW WRITE
ACCESS is not possible with the REPLACE, CREATE, or REPLACE_CREATE
options, or with buffered inserts. The import operation will periodically commit inserted
data to prevent lock escalation and to avoid running out of active log space. These
commits will be performed even if the COMMITCOUNT option was not used.
The COMMITCOUNT n/AUTOMATIC performs a commit after every n records. When
AUTOMATIC is specified, the import internally determines when a commit needs to be
performed. The import utility will commit for either one of two reasons:
• To avoid running out of active log space
• To avoid lock escalation
If ALLOW WRITE ACCESS option is specified and the COMMITCOUNT option is not
specified, the import utility will perform commits as if COMMITCOUNT AUTOMATIC
has been specified.

© Copyright IBM Corp. 1997, 2017 6-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Import utility example

db2 import from [Link] of ixf messages [Link]
insert into staff

SQL3150N The H record in the PC/IXF file has product "DB2 01.00", date
“20140220", and time "140848".

SQL3153N The T record in the PC/IXF file has name "myfile",

qualifier " ", and source " ".

SQL3109N The utility is beginning to load data from file "myfile".

SQL3110N The utility has completed processing. "58" rows were read from the
input file.

SQL3221W ...Begin COMMIT WORK. Input Record Count = "58".

SQL3222W ...COMMIT of any database changes was successful.

SQL3149N "58" rows were processed from the input file. "58" rows were
successfully inserted into the table. "0" rows were rejected.

Moving data © Copyright IBM Corporation 2017

Import utility example

The visual shows the IMPORT command that could be used to copy the data from an
IXF formatted file into a table. The INSERT mode would add the new rows to the table
leaving existing data in place.
The messages indicate the number of rows processed and include error messages if
some rows of data were rejected.

© Copyright IBM Corp. 1997, 2017 6-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Differences between IMPORT and LOAD

IMPORT LOAD
• Slow when moving large amounts • Faster for large amounts of data
of data • Tables and indexes must exist
• Creation of table/index supported • Load into tables only
with IXF format
• Existing data can still be seen by
• Import into tables, views, aliases read applications
• Option to ALLOW WRITE • Minimal logging; can make copy
ACCESS
• Triggers not fired
• All rows logged
• Unique constraints enforced
• Triggers fired • RI and check constraints via SET
• Constraints enforced INTEGRITY following load
• Inserts can use space freed by • LOAD builds new extents
deleted rows

Moving data © Copyright IBM Corporation 2017

Differences between IMPORT and LOAD

The Import utility performs SQL INSERTs, so its capabilities are similar to an
application program performing inserts. The Load utility formats extents of pages and
writes them directly into the database.
The IMPORT utility can create the target table, including indexes if the input is an IXF
formatted file. The LOAD utility adds data to an existing table and updates the table’s
indexes.
The ALLOW WRITE ACCESS option of the IMPORT utility can avoid a table level lock,
but the COMMITCOUNT option should be used to prevent lock escalation for larger
input files.
The LOAD utility allows concurrent reads from applications if the ALLOW READ
ACCESS option is used for a LOAD INSERT.
The IMPORT utility uses SQL INSERTS, which are normally logged, so the processing
is recoverable, but may consume too much database log space. The INSERT
processing of the IMPORT will enforce constraints and file any INSERT Triggers
defined for a table. The LOAD utility does minimal logging and is less likely to run out of
log space. The LOAD does not directly check constraints or fire triggers. The LOAD
utility will put a table into a SET INTEGRITY pending status to make sure the
constraints are checked before the new data can be accessed.

© Copyright IBM Corp. 1997, 2017 6-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The IMPORT utility can reuse space in a table’s data pages that was left when rows
where deleted. In general a LOAD utility creates new extents and will not try to use any
free space in existing pages.

© Copyright IBM Corp. 1997, 2017 6-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Load processing phases

• Analyze phase
 Applies only to column-organized table
 Used to build column compression dictionaries
• Load phase:
 Input records are read, formatted and written to the target table containers
and to the Load copy (optional)
 Index keys are inserted into sorts
• Build phase – Indexes are built
• Delete phase
 Duplicates are removed from unique indexes
• Index Copy phase
 If copy is needed to replace the index object with its shadow copy
(ALLOW READ ACCESS)

Moving data © Copyright IBM Corporation 2017

Load processing phases

The load utility is capable of efficiently moving large quantities of data into newly
created tables, or into tables that already contain data. The utility can handle most data
types, including XML, large objects (LOBs), and user-defined types (UDTs). The load
utility is faster than the import utility, because it writes formatted pages directly into the
database, while the import utility performs SQL INSERTs. The load utility does not fire
triggers, and does not perform referential or table constraints checking (other than
validating the uniqueness of the indexes).
The load process consists of distinct phases:
• Analyze Phase
The Analyze phase of load processing is only utilized when a column-organized
table is being loaded and the column dictionaries need to be built.
• Load Phase
During the load phase, data is loaded into the table, and index keys and table
statistics are collected, if necessary. Save points, or points of consistency, are
established at intervals specified through the SAVECOUNT parameter in the
LOAD command. Messages are generated, indicating how many input rows were
successfully loaded at the time of the save point.

© Copyright IBM Corp. 1997, 2017 6-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• Build Phase
During the build phase, indexes are produced based on the index keys collected
during the load phase. The index keys are sorted during the load phase, and
index statistics are collected (if the STATISTICS USE PROFILE option was
specified, and profile indicates collecting index statistics). The statistics are similar
to those collected through the RUNSTATS command.
• Delete Phase
During the delete phase, the rows that caused a unique or primary key violation
are removed from the table. These deleted rows are stored in the load exception
table, if one was specified.
• Index copy Phase
During the index copy phase, the index data is copied from a system temporary
table space to the original table space. This will only occur if a system temporary
table space was specified for index creation during a load operation with the
READ ACCESS option specified.

© Copyright IBM Corp. 1997, 2017 6-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Load processing for column-organized tables

This processing requires a
Pass 1 ANALYZE PHASE significantly larger amount
Only if dictionaries need to be built of database utility heap memory
compared to row organized tables
Build
Convert raw data histograms
Input from row-organized to track Build column
Source format to column- value compression
organized format frequency dictionaries

Pass 2 LOAD PHASE

User Table

Convert raw data Compress values.

from row-organized Build data pages.
Input Update synopsis Synopsis Table
format to column-
Source organized format Build keys for page
map index and any
unique indexes.
Index keys

Moving data © Copyright IBM Corporation 2017

Load processing for column-organized tables

When data is being loaded into a column-organized table, the first phase is the analyze
phase, which is unique to column-organized tables. The analyze phase occurs only if a
column compression dictionary needs to be built, which happens during a LOAD
REPLACE operation, a LOAD REPLACE RESETDICTIONARY operation, a LOAD
REPLACE RESETDICTIONARYONLY operation, or a LOAD INSERT operation (if the
column-organized table is empty). For column-organized tables, this phase is followed
by the load, build, and delete phases.
The index copy phase applies to row-organized tables only.

© Copyright IBM Corp. 1997, 2017 6-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

LOAD command syntax (Basic)

>>-LOAD--+--------+--FROM----+-filename-------+-+--------------->
'-CLIENT-' +-remotefilename-+
+-pipename-------+
+-device---------+
'-cursorname-----'
>--OF--filetype--+-------------------------+-------------------->
| .-,--------. |
| V | |
'-LOBS FROM----lob-path-+-'
>--+--------------------------------+--------------------------->
'-MODIFIED BY----file-type-mod-+-'
>--+--------------+--+-------------+--+-----------------+------->
'-SAVECOUNT--n-' '-ROWCOUNT--n-' '-WARNINGCOUNT--n-'
>--+------------------------+----------------------------------->
'-MESSAGES--message-file-'
>--+-INSERT---------------------------+------------------------->
| .-KEEPDICTIONARY------. |
+-REPLACE--+---------------------+-+
| +-RESETDICTIONARY-----+ |
| '-RESETDICTIONARYONLY-' |
+-RESTART--------------------------+
'-TERMINATE------------------------'

>--INTO--table-name--+-------------------------+---------------->
.-ALLOW NO ACCESS-----------------------------.
>--+---------------------------------------------+-------------->
'-ALLOW READ ACCESS--+----------------------+-'
'-USE--tablespace-name-'

Moving data © Copyright IBM Corporation 2017

LOAD command syntax (Basic)

The command syntax for the LOAD command provides a number of processing
options.
Some of the key LOAD command parameters are:
• CLIENT
Specifies that the data to be loaded resides on a remotely connected client. This
option is ignored if the load operation is not being invoked from a remote client.
This option is ignored if specified in conjunction with the CURSOR filetype.
FROM filename | remotefilename | pipename | device | cursorname
Specifies the file, pipe, device, or cursor referring to an SQL statement that
contains the data being loaded. If the input source is a file, pipe, or device, it
must reside on the database partition where the database resides, unless the
CLIENT option is specified.
A remotefilename refers to a file that is on remote storage, such as IBM
SoftLayer Object Storage or Amazon Simple Storage Service (S3), and is being
accessed using a storage access alias. The syntax of remote file names is:

DB2REMOTE://<alias>//<storage-path>/<file-name>

© Copyright IBM Corp. 1997, 2017 6-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• OF filetype
Specifies the format of the data:
• ASC (non-delimited ASCII format)
• DEL (delimited ASCII format)
• IXF (integrated exchange format, PC version), exported from the same or from
another Db2 table.
• CURSOR (a cursor declared against a SELECT or VALUES statement).
• MODIFIED BY filetype-mod
Specifies file type modifier options.
• SAVECOUNT n
Specifies that the Load utility should set consistency points after every n rows.
This value is converted to a page count, and rounded up to intervals of the extent
size.
• ROWCOUNT n
Specifies the number of n physical records in the file to be loaded. Allows a user
to load only the first n rows in a file.
• WARNINGCOUNT n
Stops the load operation after n warnings. Set this parameter if no warnings are
expected, but verification that the correct file and table are being used is desired.
• MESSAGES message-file
Specifies the destination for warning and error messages that occur during the
load operation.
• INSERT
One of four modes under which the Load utility can execute. Adds the loaded
data to the table without changing the existing table data.
• REPLACE
One of four modes under which the Load utility can execute. Deletes all existing
data from the table, and inserts the loaded data. The table definition and index
definitions are not changed.

© Copyright IBM Corp. 1997, 2017 6-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• RESTART
One of four modes under which the Load utility can execute. Restarts a
previously interrupted load operation. The load operation will automatically
continue from the last consistency point in the Load, Build, or Delete phase.
• TERMINATE
One of four modes under which the Load utility can execute. Terminates a
previously interrupted load operation, and rolls back the operation to the point in
time at which it started, even if consistency points were passed.
• INTO table-name
Specifies the database table into which the data is to be loaded. This table cannot
be a system table or a declared temporary table. An alias, or the fully qualified or
unqualified table name can be specified.
• FOR EXCEPTION table-name
Specifies the exception table into which rows in error will be copied. Any row that
is in violation of a unique index or a Primary Key index is copied. The exception
table must exist prior to LOAD.
• ALLOW NO ACCESS
Load will lock the target table for exclusive access during the load. The table state
will be set to Load In Progress during the load. ALLOW NO ACCESS is the
default behavior. It is the only valid option for LOAD REPLACE.
• ALLOW READ ACCESS
Load will lock the target table in a share mode. The table state will be set to both
Load In Progress and Read Access. Readers can access the non-delta portion of
the data while the table is being load.
• USE tablespace-name
If the indexes are being rebuilt, a shadow copy of the index is built in table space
tablespace-name and copied over to the original table space at the end of the
load during an INDEX COPY PHASE.
• LOCK WITH FORCE
The utility acquires various locks including table locks in the process of loading.
Rather than wait, and possibly timeout, when acquiring a lock, this option allows
load to force off other applications that hold conflicting locks on the target table.
Applications holding conflicting locks on the system catalog tables will not be
forced off by the Load utility. Forced applications will roll back and release the
locks the Load utility needs.

© Copyright IBM Corp. 1997, 2017 6-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

LOAD scenario

INPUT OUTPUT
[Link] [Link] [Link] [Link] [Link].000
10 ~~ 1 10 ~~ 1 30 ~~ 4 timestamp msg ... msg ... 20 ~~ -

50 7 timestamp msg 40 ~~ X
20 ~~ - 30 ~~ 3 ~~ 20 msg

30 ~~ 3 50 ~~ 6 ... ~ ~ ... ... ... 40 msg

30 ~~ 4 80 ~~ 8 ... ... ...

40 ~~ X not null, numeric column
Primary Key
50 ~~ 6 Rows not Loaded

50 ~~ 7 Table Exception Table

UNIQUE INDEX
80 ~~ 8

create tables/indexes 10 RID

obtain delimited input file in sorted format
create exception table 30 RID

db2 load from [Link] of del 50 RID

modified by dumpfile=<path>/[Link]
warningcount 100 messages [Link]
insert into [Link] for exception [Link] 80 RID
db2 load query table [Link]
examine [Link] file

examine [Link] exception table

Moving data © Copyright IBM Corporation 2017

LOAD scenario
In your LOAD scenario, you have created tables and indexes, sorted the input data (or
obtained it in sorted order), and created the exception table.
The LOAD exception table is a user-created table that mimics the definition of the table
being loaded. It is specified by the FOR EXCEPTION option in the LOAD command.
The table is used to store copies of rows that violate unique index rules.
FOR EXCEPTION indicates that any row that is in violation of a unique index rule will
be stored in the table indicated. In your example, [Link] will contain those rows. If
an exception table is not provided for the LOAD, and duplicate records are found, then
the LOAD will continue. However, only a warning message is issued about the deletion
of duplicate records, and the deleted duplicate records are not placed anywhere.
Other types of errors (for example, attempting to load a null into a column that is defined
as NOT NULL) will cause a message to be written to the messages file. The second
row in your example will cause this kind of warning in the message file. The
DUMPFILE=qualified-filename option will write any rejected row to the named file. The
name must be a fully qualified name on the server. The file will be created with a
partition number at the end; on a single partition database, this will be 000.

© Copyright IBM Corp. 1997, 2017 6-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The exception tables used with LOAD are identical to the ones used in the SET
INTEGRITY statement. They can be reused during checking with the SET INTEGRITY
statements. There are a number of rules for creating exception tables; you will see them
on the next visual.
In your example, cal is the owner/schema of the table.
To load data into a table, you must have one of the following:
• DATAACCESS
• LOAD privilege on the database, and
• INSERT privilege on the table when the Load utility is invoked in INSERT
mode
• INSERT and DELETE privilege on the table when the Load utility is invoked in
REPLACE mode
• INSERT privilege on the exception table, if used
Since you will typically be loading large amounts of data using the LOAD command, a
LOAD QUERY command can be used to check the progress of the LOAD process.
Options on the LOAD QUERY command allow you to indicate that you only want to see
summary information (SUMMARYONLY), or just the new information since the last
LOAD QUERY was issued (SHOWDELTA).
The best way to understand the Load utility is to look at an example. In this example,
you have these components:
• An input file, named [Link]: this is a delimited input file sorted according to the
values in the first column of the input data
• The table being loaded, named [Link]
• An exception table, named [Link]
• Two additional flat files: the messages file named [Link], and a file known as a
dump file, named [Link]
In the graphic, all of the objects are populated as if the commands have already taken
place. For sake of this discussion, consider that the tables are empty when you start,
and of course, [Link] and [Link] would be empty.
Look at the command area. For the Load command to succeed, you need to have
already created the tables that you want to load. Unlike the Import utility, the Load utility
cannot create the table as part of its operation. If you want the Load utility to create
index data, you must also have already created the indexes for the table.
If you want the data, which is stored in the table, to be stored in a particular sequence,
you should sort the input data prior to running the Load utility.

© Copyright IBM Corp. 1997, 2017 6-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Finally, you must have already created the exception table. Let's look at the
requirements for that. At this point, address the next two pages on the exception table,
then come back to this graphic.
The tables and indexes have been created; the exception table has been created.
Let’s look at the definition of the table you are loading, [Link]. The first column has
been defined as a Primary Key. The last column is defined as numeric, and does not
allow NULLs. When the exception table was created, the constraint of Primary Key was
not applied to the first column, but the last column is defined as numeric and not
allowing nulls.
Looking at the input data, you can see that there are a few records that might cause
problems. Specifically, row 20 will be a problem because it has a null in the last column
(that is what the dash in the last column is intended to represent). You also will have a
problem with row 40 because it has an alpha character in the last column (which is
defined in the table as numeric). You also have two row 30s and two row 50s. You’ll see
how those are handled as you go through the Load process.
Let’s look at the Load command. It indicates load from [Link]: the file you are
loading is [Link]. The of del indicates that the input data is delimited ASCII. The next
phrase indicates modified by dumpfile=[Link]. You looked at the fact that the
exception table is for unique key violations. The dump file is for records that violate the
definitions of the table. Messages should be written to [Link]. “warningcount 100”
indicates that if more than 100 warnings are received, the load should stop. This might
be a good setting if you think that the data is clean; then if, for example, you specify an
incorrect input file name, instead of having every record fail (which could take a very
long time with a large input file), after 100 invalid records, the load will fail.
The Load mode in this example is insert, or Load append. If there was data already
existing in the table, the existing data in the table will still be available while the load is
appending data to the rest of the table.
The command also indicates that exception rows should be put into the [Link]
exception table.
Let’s look at what happens as the data is processed.
The first record, record 10, will go into the [Link] table with no problem.
The next record, record 20, fails the parsing check, so the data will be put out to the
dumpfile, [Link]. A message will also be written to the messages file, [Link].
During the Load phase, both record 30s will be inserted into the table. Even though
they have duplicate keys, they will not be removed until the Build phase.
Record 40 fails the parsing check, so the data will be put out to the dumpfile, and a
message will be written to the messages file.

© Copyright IBM Corp. 1997, 2017 6-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Again, during the Load phase, both record 50s will be inserted into the table, and record
80 will be inserted in the table. At the end of the Load phase, all of the records in the
[Link] file except for the ones highlighted in yellow (20 and 40) will be in the [Link]
table.
Then the Build phase starts. Since there is a Primary Key, the Primary Key index will be
built.
During the Delete phase, the second record 30 and the second record 50 will be copied
from [Link] to [Link]. The second records will be deleted from [Link]. Note that
the first record is copied into the table with no problem. It is only the second and
subsequent records that are considered to be duplicate keys.
If a separate table space had been specified for rebuilding the index, the Delete phase
would be followed by the index copy phase: copying the rebuilt index from the
temporary table space to the index table space.
The set of commands also shows the Load query command.

© Copyright IBM Corp. 1997, 2017 6-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Rules and methods for creating Exception Tables

• The first n columns are the same
• No constraints and no trigger definitions
• n + 1 column TIMESTAMP
• n + 2 column CLOB (32 KB)
• user INSERT privilege

CREATE TABLE T1EXC LIKE T1 CREATE TABLE T1EXC AS

(SELECT T1.*,
ALTER TABLE T1EXC CURRENT TIMESTAMP AS TS,
ADD COLUMN TS TIMESTAMP CLOB('', 32767) AS MSG
ADD COLUMN MSG CLOB(32K) FROM T1)
DEFINITION ONLY

Moving data © Copyright IBM Corporation 2017

Rules and methods for creating Exception Tables

The first n columns of the exception table reflect the definition of the table being loaded.
All column attributes (type, length, and null ability attributes) should be identical. An
exception table cannot contain an identity column or any other type of generated column.
All the columns of the exception table should be free of any constraints and triggers.
Constraints include referential integrity and check constraints, as well as unique index
constraints that could cause errors on insert.
The n + 1 column of the exception table is an optional TIMESTAMP column. The
timestamp column in the exception table can be used to distinguish newly-inserted rows
from the old ones, if necessary.
The n + 2 column should be of type CLOB (32 KB) or larger. This column is optional but
recommended, and will be used to give the names of the constraints that the data
within the row violates.
No additional columns are allowed.
If the original table has generated columns (including the IDENTITY property), the
corresponding columns in the exception table should not specify the generated
property.
It should also be noted that a user invoking any facility (LOAD, SET INTEGRITY) that
might cause rows to be inserted into the exception table must have INSERT privilege
on the exception table.

© Copyright IBM Corp. 1997, 2017 6-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Offline versus Online Load

• ALLOW NO ACCESS
Lock Lock Load
requested granted commit

read/write read/write
Load allows no access

Time

• ALLOW READ ACCESS

Super Super
exclusive exclusive Load
Drain Drain lock lock commit
requested granted requested granted
read/write read
read
r/w
Load allows read access

Time

Moving data © Copyright IBM Corporation 2017

Offline versus Online Load

In most cases, the LOAD utility uses table-level locking to restrict access to tables. The
LOAD utility does not quiesce the table spaces involved in the load operation, and uses
table space states only for load operations with the COPY NO option specified. The
level of locking depends on whether the load operation allows read access. A load
operation in ALLOW NO ACCESS mode will use an exclusive lock (Z-lock) on the table
for the duration of the load. A load operation in ALLOW READ ACCESS mode acquires
and maintains a share lock (S-lock) for the duration of the load operation, and upgrades
the lock to an exclusive lock (Z-lock) when data is being committed.
Before a load operation in ALLOW READ ACCESS mode begins, the Load utility will
wait for all applications that began before the load operation to release locks on the
target table. Since locks are not persistent, they are supplemented by table states that
will remain even if a load operation is aborted. These states can be checked by using
the LOAD QUERY command. By using the LOCK WITH FORCE option, the LOAD
utility will force applications holding conflicting locks off the table into which it is trying to
load.
ALLOW NO ACCESS is the default option on the LOAD utility.

© Copyright IBM Corp. 1997, 2017 6-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Locking Behavior for Load Operations in ALLOW READ ACCESS Mode

At the beginning of a load operation, the LOAD utility acquires a share lock (S-lock) on
the table. It holds this lock until the data is being committed. The share lock allows
applications with compatible locks to access the table during the load operation. For
example, applications that use read-only queries will be able to access the table, while
applications that try to insert data into the table will be denied. When the LOAD utility
acquires the share lock on the table, it will wait for all applications that hold locks on the
table prior to the start of the load operation to release them, even if they have
compatible locks.
Since the LOAD utility upgrades the share lock to an exclusive lock (Z-lock) when the
data is being committed, there might be some delay in commit time while the LOAD
utility waits for applications with conflicting locks to finish.
Note: The load operation will not time out while it waits for the applications to release
their locks on the table.
LOCK WITH FORCE Option
The LOCK WITH FORCE option can be used to force off applications holding
conflicting locks on a table so that the load operation can proceed. If an application is
forced off the system by the Load utility, it will lose its database connection and an error
will be returned.
For a load operation in ALLOW NO ACCESS mode, all applications holding table locks
that exist at the start of the load operation will be forced.
For a load operation in ALLOW READ ACCESS mode, applications holding the
following locks will be forced:
• Table locks that conflict with a table share lock (for example, import or insert).
• All table locks that exist at the commit phase of the load operation.
When the COPY NO option is specified for a load operation on a recoverable database,
all objects in the target table space will be locked in share mode before the table space
is placed in backup pending state. This will occur regardless of the access mode. If the
LOCK WITH FORCE option is specified, all applications holding locks on objects in the
table space that conflict with a share lock will be forced off.

© Copyright IBM Corp. 1997, 2017 6-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Table states
• (Load pending, Set Integrity Pending)
• LOAD QUERY TABLE <table-name>
• Tablestate:
Normal
Set Integrity Pending
Load in Progress
Load Pending
Reorg Pending
Read Access Only
Unavailable
Not Load Restartable
Unknown
• Table can be in several states at same time
Tablestate:
Set Integrity Pending
Load in Progress
Read Access Only
Moving data © Copyright IBM Corporation 2017

Table states
In addition to locks, the LOAD utility uses table states to control access to tables. A
table state can be checked by using the LOAD QUERY command. The states returned
by the LOAD QUERY command are as follows:
• Normal: No table states affect the table.
• Set Integrity Pending: The table has constraints which have not yet been
verified. Use the SET INTEGRITY statement to take the table out of Set Integrity
Pending state. The LOAD utility places a table in Set Integrity Pending state when
it begins a load operation on a table with constraints.
• Load in Progress: There is a load operation in progress on this table.
• Load Pending: A load operation has been active on this table but has been
aborted before the data could be committed. Issue a LOAD TERMINATE, LOAD
RESTART, or LOAD REPLACE command to bring the table out of this state.
• Read Access Only: The table data is available for read access queries. Load
operations using the ALLOW READ ACCESS option place the table in read
access only state.

© Copyright IBM Corp. 1997, 2017 6-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• Reorg Pending: A REORG command recommended ALTER TABLE statement

has been executed on the table. A classic REORG must be performed before the
table is accessible again.
• Unavailable: The table is unavailable. The table can only be dropped or restored
from a backup. Rolling forward through a non-recoverable load operation will
place a table in the unavailable state.
• Not Load Restartable: The table is in a partially loaded state that will not allow a
load restart operation. The table will also be in Load Pending state. Issue a LOAD
TERMINATE or a LOAD REPLACE command to bring the table out of the Not
Load Restartable state. A table is placed in Not Load Restartable state when a
roll forward operation is performed after a failed load operation that has not been
successfully restarted or terminated, or when a restore operation is performed
from an online backup that was taken while the table was in Load in Progress or
Load Pending state. In either case, the information required for a load restart
operation is unreliable, and the Not Load Restartable state prevents a load restart
operation from taking place.
• Unknown: The LOAD QUERY command is unable determine the table state.
A table can be in several states at the same time. For example, if data is loaded into a
table with constraints and the ALLOW READ ACCESS option is specified, the table
state would be:
Tablestate:
Set Integrity Pending
Load in Progress
Read Access Only
After the load operation but before issuing the SET INTEGRITY statement, the table
state would be:
Tablestate:
Set Integrity Pending
Read Access Only
After the SET INTEGRITY statement has been issued, the table state would be:
Tablestate:
Normal

© Copyright IBM Corp. 1997, 2017 6-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Checking Load status: Load query

db2 load query table inst481.loadhist1
SQL3501W The table space(s) in which the table resides will not be placed in
backup pending state since forward recovery is disabled for the database.
SQL3109N The utility is beginning to load data from file
"/home/inst481/datamove/[Link]".
SQL3500W The utility is beginning the "LOAD" phase at time "05/12/2016
[Link].967160".
SQL3519W Begin Load Consistency Point. Input record count = "0".
SQL3520W Load Consistency Point was successful.
SQL3519W Begin Load Consistency Point. Input record count = "10248".
...
SQL3519W Begin Load Consistency Point. Input record count = "51450".
SQL3520W Load Consistency Point was successful.
SQL0289N Unable to allocate new pages in table space "LOADTSPD".
SQLSTATE=57011
SQL3532I The Load utility is currently in the "LOAD" phase.

Number of rows read = 51450

Number of rows skipped = 0
Number of rows loaded = 51450
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 51450
Number of warnings = 0

Tablestate:
Load Pending

Moving data © Copyright IBM Corporation 2017

Checking Load status: Load query

The LOAD QUERY command can be used to determine the table state. LOAD QUERY
can be used on tables that are not currently being loaded. For a partitioned table, the
state reported is the most restrictive of the corresponding visible data partition states.
For example, if a single data partition is in the Read Access Only state and all other
data partitions are in Normal state, the load query operation returns the Read Access
Only state. A load operation will not leave a subset of data partitions in a state different
from the rest of the table.
The sample LOAD QUERY report shows a table was being loaded and failed to
complete because there was not enough free space available in the tablespace. The
table remains in a LOAD PENDING state.

© Copyright IBM Corp. 1997, 2017 6-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Load monitoring: LIST UTILITIES

db2 LIST UTILITIES SHOW DETAIL
ID = 4
Type = LOAD
Database Name = MUSICDB
Member Number = 0
Description = [LOADID: 18.2016-05-12-02.48.55.850877.0 (11;4)]
[*LOCAL.inst481.120512063958] ONLINE LOAD DEL AUTOMATIC INDEXING INSERT NON-RECOVERABLE
INST481 .LOADHIST1
Start Time = 05/12/2016 [Link].869016
State = Executing
Invocation Type = User
Progress Monitoring:
Phase Number = 1
Description = SETUP
Total Work = 0 bytes
Completed Work = 0 bytes
Start Time = 05/12/2016 [Link].869085

Phase Number = 2
Description = LOAD
Total Work = 10000 rows
Completed Work = 10000 rows
Start Time = 05/12/2016 [Link].057958

Phase Number [Current] = 3

Description = BUILD
Total Work = 2 indexes
Completed Work = 2 indexes
Start Time = 05/12/2016 [Link].36690

Moving data © Copyright IBM Corporation 2017

Load monitoring: LIST UTILITIES

The LIST UTILITIES command displays to standard output the list of active utilities on
the instance. The description of each utility can include attributes such as start time,
description, throttling priority (if applicable), as well as progress monitoring information
(if applicable).
One of the following authorizations is needed:
• sysadm
• sysctrl
• sysmaint
• sysmon
Syntax:
>>-LIST UTILITIES--+-------------+-----------------------------
>< '-SHOW DETAIL-'
For active LOAD utilities, the LIST UTILITIES command can be used to see which
phase of LOAD processing is the current phase. During the LOAD phase, you can track
the number of rows processed. In the BUILD phase you can see how many indexes
have been completed.

© Copyright IBM Corp. 1997, 2017 6-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Load Pending state: Recovering from LOAD failure

• Restart the Load:
 Check Messages files
 Use Restart option
 Load operation automatically continues from last consistency point in Load
or Build phase
− or Delete phase if ALLOW NO ACCESS
• Replace the whole table
 LOAD ... REPLACE
• Terminate the Load:
 If LOAD ... INSERT, returns table to state preceding Load
• If LOAD ... REPLACE, table will be truncated to an empty state
 Create backup copy prior to Load to return to state preceding Load

Do not tamper with Load temporary files

Moving data © Copyright IBM Corporation 2017

Load Pending state: Recovering from LOAD failure

If the LOAD utility cannot start because of a user error, such as a nonexistent data file
or invalid column names, it will terminate and leave the table in a normal state.
If a failure occurs while loading data, you can restart the load operation from the last
consistency point (using the RESTART option), reload the entire table (using the
REPLACE option), or terminate the load (using the TERMINATE option). Specify the
same parameters as in the previous invocation so that the utility can find the necessary
temporary files.
A load operation that specified the ALLOW READ ACCESS option can be restarted
using either the ALLOW READ ACCESS option or the ALLOW NO ACCESS option. A
load operation that specified the ALLOW NO ACESS option can only be restarted using
the ALLOW NO ACCESS option. If the index object is unavailable or marked invalid, a
load restart or terminate in ALLOW READ ACCESS mode will not be permitted. If the
original load operation was aborted in the Index Copy phase, a restart operation in the
ALLOW READ ACCESS mode is not permitted because the index might be corrupted.

© Copyright IBM Corp. 1997, 2017 6-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

If a load operation in ALLOW READ ACCESS mode was aborted in the Load phase, it
will restart in the Load phase. If it was aborted in any phase other than the Load phase,
it will restart in the Build phase. If the original load operation was in ALLOW NO
ACCESS mode, a restart operation might occur in the Delete phase if the original load
operation reached that point and the index is valid. If the index is marked invalid, the
Load utility will restart the load operation from the Build phase.
Load REPLACE deletes all existing data from the table and inserts the loaded data.
Using load REPLACE and specifying an empty input file will truncate the table.
Terminating the load will roll back the operation to the point in time at which it started,
even if consistency points were passed. The states of any tables involved in the
operation return to normal, and all table objects are made consistent (index objects
might be marked as invalid, in which case index rebuild will automatically take place at
the next access). If the load operation being terminated is a Load REPLACE, the table
will be truncated to an empty table after the Load TERMINATE operation. If the load
operation being terminated is a Load INSERT, the table will retain all of its original
records after the Load TERMINATE operation.
The Load operation writes temporary files onto the server into a subdirectory of the
database directory by default (the location can be changed using a TEMPFILES PATH
temp-pathname parameter on the LOAD command). The temporary files written to this
path are removed when the load operation completes without error. These temporary
files must not be tampered with under any circumstances. Doing so will cause the load
operation to malfunction, and will place your database in jeopardy.

© Copyright IBM Corp. 1997, 2017 6-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Backup Pending state: COPY options

• When loading data and forward recovery is enabled:
 COPY NO (default)
− During load, Backup pending and Load in progress
− After load, Backup Pending
 COPY YES
− Load has made Copy not Backup pending
 NONRECOVERABLE
− No copy made and no backup required

Load Copy file naming conventions

[Link]

Type: 0=Full Backup

3=Table Space Backup
4 =Copy from Table Load

Moving data © Copyright IBM Corporation 2017

Backup Pending state: COPY options

If a load operation with the COPY NO option is executed in a recoverable database, the
table spaces associated with the load operation are placed in the Backup pending table
space state and the Load in progress table space state. This takes place at the
beginning of the load operation. The load operation might be delayed at this point while
locks are acquired on the tables within the table space.
When a table space is in Backup pending state, it is still available for read access. The
table space can only be taken out of Backup pending state by taking a backup of the
table space. Even if the load operation is aborted, the table space will remain in Backup
pending state because the table space state is changed at the beginning of the load
operation, and cannot be rolled back if it fails. The Load in Progress table space state
prevents online backups of a load operation with the COPY NO option specified while
data is being loaded. The Load in Progress state is removed when the load operation is
completed or aborts.
Note that if the database is a recoverable database, then terminating the load will not
eliminate the requirement to make a backup of the loaded table space.

© Copyright IBM Corp. 1997, 2017 6-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

When loading data, if forward recovery is enabled, there are three options to consider:
1. COPY NO (default) specifies that the table space in which the table resides will
be placed in backup pending state if forward recovery is enabled (that is,
logretain or userexit is on). COPY NO will also put the table space state into the
Load in Progress table space state. This is a transient state that will disappear
when the load completes or aborts. The data in any table in the table space
cannot be updated or deleted until a table space backup or a full database
backup is made. However, it is possible to access the data in any table by using
the SELECT statement.
2. COPY YES on the LOAD specifies that a copy of the changes made will be
saved. This copy is used during roll-forward recovery to recreate the changes to
the database done by LOAD. This option is invalid if forward recovery is
disabled. COPY YES slows the LOAD utility. If you are loading a lot of tables,
you might want to load all of the tables in the table space, then back it up.
3. NONRECOVERABLE specifies that the load transaction is to be marked as
non-recoverable and that it will not be possible to recover it by a subsequent roll
forward action. The roll forward utility will skip the transaction and will mark the
table into which data was being loaded as invalid. The utility will also ignore any
subsequent transactions against that table. After the roll forward operation is
completed, such a table can only be dropped or restored from a backup (full or
table space) taken after a commit point following the completion of the non-
recoverable load operation.
With this option, table spaces are not put into backup pending state following
the load operation, and a copy of the loaded data does not have to be made
during the load operation. This can be used to enable loading several tables in a
table space before performing a backup of the table space. It can also be used
with tables that are always loaded with LOAD... REPLACE since they could be
recovered by reloading.
If you do not create a copy, the LOAD will execute more quickly. You must also allow
for the disk space that an additional backup copy would take.
The name of the backup file has entries for the Type field to indicate what it represents.
There are three options:
• 0 for full database backup
• 3 for table space backup
• 4 for Copy from Table Load
If load is used with the nonrecoverable option, there is no requirement to take a
backup.

© Copyright IBM Corp. 1997, 2017 6-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

During a roll forward operation through a LOAD command with the COPY NO option
specified, the associated table spaces are placed in Restore pending state. To remove
the table spaces from Restore pending state, a restore operation must be performed. A
roll forward operation will only place a table space in the Restore pending state if the
load operation completed successfully.

© Copyright IBM Corp. 1997, 2017 6-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Set Integrity Pending table state

• Load turns OFF constraint checking:
 Leaves table in Set Integrity Pending state
 If parent table is in Set Integrity Pending, then dependents may also be in
Set Integrity Pending
 LOAD INSERT, ALLOW READ ACCESS
− Loaded table in Set Integrity Pending with read access
 LOAD INSERT, ALLOW NO ACCESS
− Loaded table in Set Integrity Pending with no access
 LOAD REPLACE, SET INTEGRITY PENDING CASCADE DEFERRED
− Loaded table in Set Integrity Pending with no access
 LOAD REPLACE, SET INTEGRITY PENDING CASCADE IMMEDIATE
− Loaded table and descendant Foreign Key tables are in Set Integrity Pending with
no access

Moving data © Copyright IBM Corporation 2017

Set Integrity Pending table state

Following a load operation, the loaded table might be in Set Integrity Pending state in
either READ or NO ACCESS mode if the table has table check constraints or referential
integrity constraints defined on it. If the table has descendent Foreign Key tables, they
might also be in Set Integrity Pending state.
If the loaded table has descendent tables, the SET INTEGRITY PENDING CASCADE
parameter can be specified to indicate whether the Set Integrity Pending state of the
loaded table should be immediately cascaded to the descendent materialized query
tables or descendent staging tables. SET INTEGRITY PENDING CASCADE does not
apply to descendent Foreign Key tables. If the loaded table has constraints as well as
descendent Foreign Key tables, and if all of the tables are in normal state prior to the
load operation, the following will result based on the load parameters specified:
• INSERT, ALLOW READ ACCESS, and SET INTEGRITY PENDING CASCADE
IMMEDIATE or DEFERRED
The loaded table will be placed in Set Integrity Pending state with read access.
Descendent Foreign Key tables will remain in their original states.

© Copyright IBM Corp. 1997, 2017 6-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• INSERT, ALLOW NO ACCESS, and SET INTEGRITY PENDING CASCADE

IMMEDIATE
The loaded table will be placed in Set Integrity Pending state with no access.
Descendent Foreign Key tables will remain in their original states.
• INSERT or REPLACE, ALLOW NO ACCESS, and SET INTEGRITY PENDING
CASCADE DEFERRED
Only the loaded table will be placed in Set Integrity Pending state with no access.
Descendent Foreign Key tables will remain in their original states.
• REPLACE, ALLOW NO ACCESS, and SET INTEGRITY PENDING CASCADE
IMMEDIATE
The table and all its descendent Foreign Key tables will be placed in Set Integrity
Pending state with no access.
Note: Specifying the ALLOW READ ACCESS option in a Load Replace operation will
result in an error.

© Copyright IBM Corp. 1997, 2017 6-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

SET INTEGRITY command syntax (Basic)

SET INTEGRITY ...
,
FOR table-name OFF

IMMEDIATE CHECKED
| exception-clause |

,
FOR table-name ALL IMMEDIATE UNCHECKED

FOREIGN KEY
CHECK

exception-clause
,
| FOR EXCEPTION IN table-name USE table-name |

Moving data © Copyright IBM Corporation 2017

SET INTEGRITY command syntax (Basic)

To remove the set integrity pending state, use the SET INTEGRITY statement. The
SET INTEGRITY statement checks a table for constraints violations, and takes the
table out of set integrity pending state. If all the load operations are performed in
INSERT mode, the SET INTEGRITY statement can be used to incrementally process
the constraints (that is, it checks only the appended portion of the table for constraints
violations).
For example:
db2 load from [Link] of ixf insert into table1
db2 set integrity for table1 immediate checked
Only the appended portion of TABLE1 is checked for constraint violations. Checking
only the appended portion for constraints violations is faster than checking the entire
table, especially in the case of a large table with small amounts of appended data.
Tip: Using IBM Data Studio Version 4.1, you can utilize the task assistant for setting
integrity. Task assistants can guide you through the process of setting options,
reviewing the automatically generated commands to perform the task, and running
these commands.

© Copyright IBM Corp. 1997, 2017 6-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

If a table is loaded with the SET INTEGRITY PENDING CASCADE DEFERRED option
specified, and the SET INTEGRITY statement is used to check for integrity violations,
the descendent tables are placed in set integrity pending state with no access. To take
the tables out of this state, you must issue an explicit request.

© Copyright IBM Corp. 1997, 2017 6-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Example - Running Set Integrity

BEFORE
[Link]
[Link] [Link]
TABNAME DEFINER STATUS CONST_ ACCESS_
CHECKED MODE 10 1 10 X

par cal C NYYY... R 30 3 10 Y

for cal C YNYY... R 50 6 20 Y

80 8 50 Z
AFTER
80 X
Primary Key
forexp 90 A
[Link]
20 Y timestamp msg
10 ~~ X Foreign Key
90 A timestamp msg
10 ~~ Y parexp
50 ~~ Z timestamp msg

80 ... X
db2 SET INTEGRITY for
[Link], [Link] IMMEDIATE CHECKED
FOR EXCEPTION
IN [Link] USE [Link],
IN [Link] USE [Link]

Moving data © Copyright IBM Corporation 2017

Example - Running Set Integrity

The STATUS flag of the [Link] entry corresponding to the loaded table
indicates the Set Integrity Pending state of the table. For the loaded table to be fully
usable, the STATUS must have a value of N and the ACCESS MODE must have a
value of F, indicating that the table is in normal state and fully accessible.
In the example on the graphic, both [Link] and [Link] have been loaded. They
both indicate that constraints need to be checked (STATUS = ‘C’). [Link] is a parent
table, and [Link] is its dependent. [Link] also has a check constraint defined on
one of its columns. In this case, both tables are in Set Integrity Pending status because
they have both been loaded.
The SET INTEGRITY statement is executed to check the constraints on both tables.
[Link] had two rows that did not have parent keys in [Link], so those rows were
moved to the FOREXP exception table. The [Link] table did not have any check
constraint violations, so there are no rows added to the PAREXP table as a result of
this SET INTEGRITY statement.

© Copyright IBM Corp. 1997, 2017 6-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

To remove the Set Integrity Pending state, use the SET INTEGRITY statement. The
SET INTEGRITY statement checks a table for constraint violations, and takes the table
out of Set Integrity Pending state. If all the load operations are performed in INSERT
mode, the SET INTEGRITY statement can be used to incrementally process the
constraints (that is, it will check only the appended portion of the table for constraint
violations). For example:
db2 load from [Link] of ixf insert into table1
db2 set integrity for table1 immediate checked
Only the appended portion of TABLE1 is checked for constraint violations. Checking
only the appended portion for constraint violations is faster than checking the entire
table, especially in the case of a large table with small amounts of appended data.
If a table is loaded with the SET INTEGRITY PENDING CASCADE DEFERRED option
specified, and the SET INTEGRITY statement is used to check for integrity violations
on the parent table, the descendent tables will be placed in Set Integrity Pending state
with no access when the SET INTEGRITY statement is issued. To take the descendent
tables out of this state, you must issue an explicit SET INTEGRITY request on the
descendent tables.
If the ALLOW READ ACCESS option is specified for a load operation, the table will
remain in read access state until the SET INTEGRITY statement is used to check for
constraint violations. Applications will be able to query the table for data that existed
prior to the load operation once it has been committed, but will not be able to view the
newly loaded data until the SET INTEGRITY statement has been issued.
Several load operations can take place on a table before checking for constraint
violations. If all of the load operations are completed in ALLOW READ ACCESS mode,
only the data that it existed in the table prior to the first load operation will be available
for queries.
One or more tables can be checked in a single invocation of this statement. If a
dependent table is to be checked on its own, the parent table cannot be in Set Integrity
Pending state. Otherwise, both the parent table and the dependent table must be
checked at the same time. In the case of a referential integrity cycle, all the tables
involved in the cycle must be included in a single invocation of the SET INTEGRITY
statement. It might be convenient to check the parent table for constraint violations
while a dependent table is being loaded. This can only occur if the two tables are not in
the same table space.
Use the load exception table option to capture information about rows with constraint
violations.

© Copyright IBM Corp. 1997, 2017 6-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The SET INTEGRITY statement does not activate any DELETE triggers as a result of
deleting rows that violate constraints, but once the table is removed from Set Integrity
Pending state, triggers are active. Thus, if you correct data and insert rows from the
exception table into the loaded table, any INSERT triggers defined on the table will be
activated. The implications of this should be considered. One option is to drop the
INSERT trigger, insert rows from the exception table, and then recreate the INSERT
trigger.

© Copyright IBM Corp. 1997, 2017 6-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Meaningful steps for LOAD

• Create tables and indexes
• Create exception tables
• Sort data
• Back up TS/DB (if using REPLACE)
• Consider freespace
• Load .... for Exception ... Savecount ... Warningcount...
• Examine [Link] and dumpfile (after LOAD completes)
• Examine exception tables (after LOAD completes)
• Back up table space if log retain=recovery and COPY NO
• Set Integrity for .... (only if table in Set Integrity Pending state)
• Update statistics (if necessary)

Moving data © Copyright IBM Corporation 2017

Meaningful steps for LOAD

The visual reviews a sequence of steps that might be used in loading tables with the
LOAD utility.
Sorting the input data for a LOAD allows you to control the sequence of the data rows in
the table and reduces the need to reorganize the table after loading data.
The LOAD utility options PAGEFREESPACE, INDEXFREESPACE and
TOTALFREESPACE can be used in the MODIFIED BY clause to set allocations for
free space by the LOAD utility.
When using the LOAD utility with the REPLACE option, the STATISTICS option can be
used to request the collection of statistics during load processing. This can be used to
avoid needing to run a RUNSTATS command following the LOAD processing. By
default, LOAD will not collect new table statistics.
If you specify STATISTICS USE PROFILE, this instructs load to collect statistics during
the load according to the profile defined for this table. This profile must be created
before load is executed. The profile is created by the RUNSTATS command. If the
profile does not exist and load is instructed to collect statistics according to the profile, a
warning is returned and no statistics are collected.

© Copyright IBM Corp. 1997, 2017 6-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

db2move utility
• Facilitates the moving/copying of large numbers
of tables between databases
• Can be used with db2look to move/copy
a database between different platforms
(for example, AIX to Windows).
• Usage: db2move <dbName> EXPORT/IMPORT/LOAD/COPY [options]
• EXPORT: The system catalogs are queried, a list of tables is
compiled (based on the options), and the tables are exported in
IXF format -- additionally, a file called [Link] is created
• IMPORT: The [Link] file is used to import the IXF files
created in the EXPORT step
• LOAD: The [Link] file is used to load the PC/IXF data files
created in the EXPORT step
• COPY: Duplicates schema(s) into a target database
Moving data © Copyright IBM Corporation 2017

db2move utility
The db2move command, when used in the EXPORT/IMPORT/LOAD modes, facilitates
the movement of large numbers of tables between Db2 databases located on
workstations. The tool queries the system catalog tables for a particular database and
compiles a list of all user tables. It then exports these tables in PC/IXF format. The
PC/IXF files can be imported or loaded to another local Db2 database on the same
system, or can be transferred to another workstation platform and imported or loaded to
a Db2 database on that platform. Tables with structured type columns are not moved
when this tool is used.
When used in the COPY mode, this tool facilitates the duplication of a schema.

© Copyright IBM Corp. 1997, 2017 6-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

db2move COPY option

• Copy one or more schemas between Db2 databases
 Uses a -co option to specify:
− Target Database:
"TARGET_DB <db name> [USER <userid> USING <password>]"
− MODE:
• DDL_AND_LOAD - Creates all supported objects from the source schema,
and populates the tables with the source table data. Default
• DDL_ONLY -Creates all supported objects from the source schema, but
does not repopulate the tables.
• LOAD_ONLY- Loads all specified tables from the source database to the
target database. The tables must already exist on the target.
− SCHEMA_MAP: Allows user to rename schema when copying to target
− TABLESPACE_MAP: Table space name mappings to be used
− Load Utility option: COPY NO or Nonrecoverable
− Owner: Change the owner of each new object created in the target schema

Moving data © Copyright IBM Corporation 2017

db2move COPY option

The db2move utility allows you to quickly make copies of a database schema. Once a
model schema is established, you can use it as a template for creating new versions.
Use the db2move utility with the -co COPY action to copy a single schema or multiple
schemas from a source database to a target database. Most database objects from the
source schema are copied to the target database under the new schema.
There are options of db2move that allow the creation of the objects, with or without the
data. The schema name can be the same or different in the target database. You can
also adjust the table spaces used to contain the copied objects in the target database.
The LOAD utility is used to move the object data from the source database to the target
database.

© Copyright IBM Corp. 1997, 2017 6-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The db2move utility attempts to copy all allowable schema objects except for 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

© Copyright IBM Corp. 1997, 2017 6-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

db2move COPY schema examples

• To duplicate schema schema1 Database dbsrc
from source database dbsrc
to target database dbtgt, issue:
db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt
USER myuser1 USING mypass1
db2move
• To duplicate schema schema1
from source database dbsrc
to target database dbtgt and
rename the schema to newschema1 on Database dbtgt
the target and map source table space ts1
to ts2 on the target, issue: Output files generated:
db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt [Link]
USER myuser1 USING mypass1 [Link]
SCHEMA_MAP ((schema1,newschema1)) [Link]
[Link]
TABLESPACE_MAP ((ts1,ts2), SYS_ANY))
These files are
timestamped.

Moving data © Copyright IBM Corporation 2017

db2move COPY schema examples

Example 1:
To duplicate schema schema1 from the source database dbsrc to the target database
dbtgt, issue:
db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt
USER myuser1 USING mypass1
Example 2:
To duplicate schema schema1 from the source database dbsrc to the target database
dbtgt and rename the schema to newschema1 on the target database, map the
source table space ts1 to ts2 on the target database, issue:
db2move dbsrc COPY -sn schema1 -co TARGET_DB dbtgt
USER myuser1 USING mypass1
SCHEMA_MAP ((schema1,newschema1))
TABLESPACE_MAP ((ts1,ts2), SYS_ANY))

© Copyright IBM Corp. 1997, 2017 6-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Online Table Move stored procedure

• The ADMIN_MOVE_TABLE procedure is designed to move data from
a source table to a target table with a minimal impact to application
access
 Changes that can be made using ADMIN_MOVE_TABLE:
− New Data, Index or Long table spaces, which could have a different page size,
extent size or type of table space management (like moving from SMS to
Automatic Storage)
− Data compression could be implemented during the move
− MDC clustering can be added or changed
− Range partitions can be added or changed
− Distribution keys can be changed for Database partitioned tables
− Columns can be added, removed or changed
− Convert a row-organized table to column-organized
 Multiple phased processing allows write access to the source table except
for a short outage required to swap access to the target table

Moving data © Copyright IBM Corporation 2017

Online Table Move stored procedure

Using the ADMIN_MOVE_TABLE procedure, you can move tables by using an online
or offline move. Use an online table move instead of an offline table move if you value
availability more than cost, space, move performance, and transaction overhead.
The ADMIN_MOVE_TABLE procedure allows you to move the data in a table to a new
table object of the same name (but with possibly different storage characteristics) while
the data remains online and available for access.
This utility automates the process of moving table data to a new table object while
allowing the data to remain online for select, insert, update, and delete access.
You can also generate a compression dictionary when a table is moved and reorganize
the target table.
Note: The ADMIN_MOVE_TABLE procedure can be used to convert a row-organized
table to columnar organization. It does not allow a column-organized table to be the
source table for processing.

© Copyright IBM Corp. 1997, 2017 6-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

ADMIN_MOVE_TABLE: Processing phases

SYSTOOLS.ADMIN_MOVE_TABLE

1 INIT PHASE tabschema tabname key value

Create triggers,target,
staging tables

SOURCE TARGET
TABLE 2 TABLE
COPY PHASE
c1 c2 … cn c1 c2 … cn
3
REPLAY PHASE

INSERT INSERT
c1 c2 … cn
Rows with
DELETE DELETE keys present
UPDATE in staging
UPDATE table are
Online Keys of re-copied
from source
Workload row changed table
by online 4 SWAP PHASE
workload
captured via STAGING Rename Target -> Source
triggers
TABLE
Moving data © Copyright IBM Corporation 2017

ADMIN_MOVE_TABLE: Processing phases

When you call the SYSPROC.ADMIN_MOVE_TABLE procedure, a shadow copy of
the source table is created (Phase 1 in the visual).
During the Copy phase, changes to the source table (updates, insertions, or deletions)
are captured using triggers and placed in a staging table (Phase 2 in the visual).
After the Copy phase is completed, the changes captured in the staging table are
replayed to the shadow copy (Phase 3 in the visual).
Following that, the stored procedure briefly takes the source table offline and assigns
the source table name and index names to the shadow copy and its indexes (Phase 4
in the visual). The shadow table is then brought online, replacing the source table. By
default, the source table is dropped, but you can use the KEEP option to retain it under
a different name.
Avoid performing online moves for tables without indexes, particularly unique indexes.
Performing an online move for a table without a unique index might result in deadlocks
and complex or expensive replay.

© Copyright IBM Corp. 1997, 2017 6-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

ADMIN_MOVE_TABLE procedure methods

• There are two methods of calling ADMIN_MOVE_TABLE:

 One method specifies the how to define the target table.
>>-ADMIN_MOVE_TABLE--(--tabschema--,--tabname--,---------------->

>--data_tbsp--,--index_tbsp--,--lob_tbsp--,--mdc_cols--,-------->

.-,-------.
V |
>--partkey_cols--,--data_part--,--coldef--,----options-+--,----->

>--operation--)------------------------------------------------><

 The second method allows a predefined table to be specified as the target

for the move.

>>-ADMIN_MOVE_TABLE--(--tabschema--,--tabname--,---------------->

.-,-------.
V |
>--target_tabname--,----options-+--,--operation--)-------------><

Moving data © Copyright IBM Corporation 2017

ADMIN_MOVE_TABLE procedure methods

There are two methods of calling ADMIN_MOVE_TABLE.
One method specifies the how to define the target table.
>>-ADMIN_MOVE_TABLE--(--tabschema--,--tabname--,----------------
>
>--data_tbsp--,--index_tbsp--,--lob_tbsp--,--mdc_cols--,--------
>
.-,-------.
V |
>--partkey_cols--,--data_part--,--coldef--,----options-+--,-----
>
>--operation--)------------------------------------------------
><

© Copyright IBM Corp. 1997, 2017 6-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The second method allows a predefined table to be specified as the target for the
move.
>>-ADMIN_MOVE_TABLE--(--tabschema--,--tabname--,----------------
>
.-,-------.
V |
>--target_tabname--,----options-+--,--operation--)-------------
><

© Copyright IBM Corp. 1997, 2017 6-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Example: Move a table to a new table space

CALL SYSPROC.ADMIN_MOVE_TABLE ( 'INST481', 'LOADHIST1',
'TSHISTM1','TSHISTM2','TSHISTM2',
NULL,NULL,NULL,NULL, 'COPY_USE_LOAD,FORCE','MOVE')
KEY VALUE
-------------------------------- -------------------------------
AUTHID INST481
CLEANUP_END 2016-05-12-02.58.44.712855
CLEANUP_START 2016-05-12-02.58.44.464132
COPY_END 2016-05-12-02.58.35.933404
COPY_OPTS LOAD,WITH_INDEXES,NON_CLUSTER
COPY_START 2016-05-12-02.58.29.844891
COPY_TOTAL_ROWS 110000
INDEXNAME LHIST1IX1
INDEXSCHEMA INST481
INDEX_CREATION_TOTAL_TIME 0
INIT_END 2016-05-12-02.58.28.012105
INIT_START 2016-05-12-02.58.24.682107
REPLAY_END 2016-05-12-02.58.43.853669
REPLAY_START 2016-05-12-02.58.35.939140
REPLAY_TOTAL_ROWS 0
REPLAY_TOTAL_TIME 3
STATUS COMPLETE
SWAP_END 2016-05-12-02.58.44.322158
SWAP_RETRIES 0
SWAP_START 2016-05-12-02.58.43.861629
UTILITY_INVOCATION_ID 0100000009000000080000000000000000002014051202582802481400000000
VERSION 10.05.0000

Moving data © Copyright IBM Corporation 2017

Example: Move a table to a new table space

The example shows a call to the ADMIN_MOVE_TABLE procedure to move a table to
a new set of table spaces. In this call there are no other changes requested for the
table.
The CALL does include the option COPY_USE_LOAD, which tells the procedure to
use the LOAD utility in the COPY phase rather than using SQL INSERTS. The MOVE
option tells Db2 to complete all of the processing phases as quickly as possible.
The procedure output includes statistics and start and end times for each processing
phase.

© Copyright IBM Corp. 1997, 2017 6-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Using ADMIN_MOVE_TABLE to convert row-organized

tables to a column-organized table
• The ADMIN_MOVE_TABLE procedure can be used to convert row-
organized tables to a column-organized table
• To indicate conversion to a column-organized table you can specify
ORGANIZE BY COLUMN as an option of ADMIN_MOVE_TABLE
For example:

call admin_move_table('TEST','ACCT2','AS2','AS2','AS2',
'ORGANIZE BY COLUMN', '','','','COPY_USE_LOAD','MOVE')

• Specify COPY_USE_LOAD option to move data using a LOAD utility

to generate the Column Dictionaries
• Target table could be pre-defined as a column-organized table
• Any Unique or Primary Key indexes on the source table will be added
to the column-organized target table as enforced Unique or Primary
Key constraints

Moving data © Copyright IBM Corporation 2017

Using ADMIN_MOVE_TABLE to convert row-organized tables to a column-organized

table
Using ADMIN_MOVE_TABLE to convert row-organized tables into column-organized
tables
Conversion can be achieved in either of the following two ways:
• By specifying a column-organized target table
• By specifying the ORGANIZE BY COLUMN clause as the organize_by_clause
parameter.
The ADMIN_MOVE_TABLE stored procedure remains online. When a row-organized
table is being moved into a column-organized table, applicable column-organized table
restrictions on queries (that is, limited isolation levels) start at the end of processing,
after the new table becomes visible to queries.
ADMIN_MOVE_TABLE requires triggers on the source table to capture changes.
Because triggers are currently not supported on column-organized tables, the source
table cannot be a column-organized table (SQL2103N).
Indexes on column-organized tables are not supported. ADMIN_MOVE_TABLE silently
converts primary key and unique indexes into primary key or unique constraints and
ignores all non-unique indexes.

© Copyright IBM Corp. 1997, 2017 6-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

You cannot use the ADMIN_MOVE_TABLE procedure to convert a row-organized

table into a column-organized table if the table contains unique indexes that are defined
on nullable columns. Create any unique constraints on the target table before you call
the ADMIN_MOVE_TABLE stored procedure.
ADMIN_MOVE_TABLE provides two call parameter options. In one mode, the
procedure call parameters define the changes to be made and the procedure creates
the target table.
For example to use the ADMIN_MOVE_TABLE stored procedure to convert the row-
organized STAFF table into a column-organized table.
Use the ADMIN_MOVE_TABLE stored procedure to convert the row-organized STAFF
table into a column-organized table without specifying a target table. The ORGANIZE
BY COLUMN clause must be specified as a parameter so that the target table is
created as a column-organized table.
CALL SYSPROC.ADMIN_MOVE_TABLE(
'OTM01COL',
'STAFF',
'',
'',
'',
'ORGANIZE BY COLUMN',
'',
'',
'',
'COPY_USE_LOAD',
'MOVE'
)

© Copyright IBM Corp. 1997, 2017 6-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

In the following example a table named TEST.ACCT2 is moved to a new tablespace

and converted to a column-organized table. The LOAD utility is used for the COPY
phase.
call admin_move_table('TEST','ACCT2','AS2','AS2','AS2'
,'ORGANIZE BY COLUMN', '','','','COPY_USE_LOAD','MOVE')
Result set 1
--------------
KEY VALUE
-------------------------------- ---------------------------------------
------------------------------------------------------------------------
-----------------
AUTHID INST20
CLEANUP_END 2013-06-26-12.13.36.463983
CLEANUP_START 2013-06-26-12.13.36.275748
COPY_END 2013-06-26-12.13.35.640270
COPY_OPTS
OVER_INDEX,LOAD,WITH_INDEXES,NON_CLUSTER
COPY_START 2013-06-26-12.13.21.951896
COPY_TOTAL_ROWS 1000000
INDEXNAME ACCT2ACCT
INDEXSCHEMA TEST
INDEX_CREATION_TOTAL_TIME 0
INIT_END 2013-06-26-12.13.21.537935
INIT_START 2013-06-26-12.13.19.632628
ORIGINAL_TBLSIZE 129280
REPLAY_END 2013-06-26-12.13.36.163455
REPLAY_START 2013-06-26-12.13.35.640947
REPLAY_TOTAL_ROWS 0
REPLAY_TOTAL_TIME 0
STATUS COMPLETE
SWAP_END 2013-06-26-12.13.36.229232
SWAP_RETRIES 0
SWAP_START 2013-06-26-12.13.36.164119
UTILITY_INVOCATION_ID
0100000006000000080000000000000000002013062612132153943900000000
VERSION 10.05.0000
23 record(s) selected.

© Copyright IBM Corp. 1997, 2017 6-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

New options for ADMIN_MOVE_TABLE with DB2 11.1

• REPORT
 The REPORT option can be used to monitor the progress of table moves
 Calculates a set of values to monitor the progress of a single or multiple
table moves
 Focus is the COPY and REPLAY phase of a running table move
 To get values for all table moves, tabschema and tabname must be NULL
or the empty string
• TERM
 The TERM option can be used to terminate a table move in progress
 Terminates a running or table move
 TERM will force off the application running the table move, roll back all open
transactions and set the table move to a well defined operational status
 From here, the table move can be cancelled or continued

Moving data © Copyright IBM Corporation 2017

New options for ADMIN_MOVE_TABLE with Db2 11.1

Starting with Db2 11.1, the ADMIN_MOVE_TABLE includes two new options: REPORT
and TERM.
• TERM: Terminates a running or killed table move. TERM will kill a running table
move, roll back all open transactions and set the table move to a well-defined
operation status. From here, the table move can be canceled or continued.
• REPORT: Calculates a set of values to monitor the progress of a single or
multiple table moves. Focus is the COPY and REPLAY phase of a running table
move. To get values for all table moves, tabschema and tabname must be NULL
or the empty string.

© Copyright IBM Corp. 1997, 2017 6-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Sample REPORT for ADMIN_MOVE_TABLE monitoring

call SYSPROC.ADMIN_MOVE_TABLE ( 'INST00','LOADHIST2' , NULL,NULL, 'REPORT')

STATUS AGENT_ID INIT_START

---------------------- -------------------- --------------------------
COPY 86 2016-04-28-15.19.17.136010

COPY_THROUGHPUT COPY_ECT
-------------------- --------------------------
51200 2016-04-28-15.27.19.000000

ROWS_STAGING REPLAY_THROUGHPUT INFLOW_STAGING OUTFLOW_STAGING

-------------------- -------------------- -------------------- --------------------
0 - 0 0
GROWTH_STAGING REPLAY_ECT
-------------------- --------------------------
- -

Report includes copy phase performance (rows/second)

and estimated completion time

Moving data © Copyright IBM Corporation 2017

Sample REPORT for ADMIN_MOVE_TABLE monitoring

The slide shows the ADMIN_MOVE_TABLE procedure call with a REPORT operation.
The primary focus for using REPORT is for the COPY and REPLAY phases that could
take an extended period of time to complete. The report includes the copy throughput
for the COPY phase, measured in table rows per second.

© Copyright IBM Corp. 1997, 2017 6-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Ingest utility - for continuous data ingest

• The ingest utility is a high-speed client-side DB2 utility that streams data from files and
pipes into DB2 target tables.
• The ingest utility ingests pre-processed data directly or from files output by ETL tools or
other means
• It can run continually and thus it can process a continuous data stream through pipes.
• The data is ingested at speeds that are high enough to populate even large databases
in partitioned database environments
• An INGEST command updates the target table with low latency in a single step
• Uses row locking, so it has minimal interference with other user activities on the same
table
• These ingest operations support the following SQL statements: INSERT, UPDATE,
MERGE, REPLACE, and DELETE
• Other important features of the ingest utility include:
 Commit by time or number of rows.
 Support for copying rejected records to a file or table, or discarding them
 Support for restart and recovery.
• The INGEST command supports the following input data formats:
 Delimited text
 Positional text and binary
 Columns in various orders and formats

Moving data © Copyright IBM Corporation 2017

Ingest utility - for continuous data ingest

The ingest utility, sometimes referred to as continuous data ingest, or CDI, is a high-
speed client-side Db2 utility that streams data from files and pipes into Db2 target
tables. Because the ingest utility can move large amounts of real-time data without
locking the target table, you do not need to choose between the data currency and
availability.
The ingest utility ingests pre-processed data directly or from files output by ETL tools or
other means. It can run continually and thus it can process a continuous data stream
through pipes. The data is ingested at speeds that are high enough to populate even
large databases in partitioned database environments.
An INGEST command updates the target table with low latency in a single step. The
INGEST utility uses row locking, so it has minimal interference with other user activities
on the same table.
With this utility, you can perform DML operations on a table using a SQL-like interface
without locking the target table. These ingest operations support the following SQL
statements: INSERT, UPDATE, MERGE, REPLACE, and DELETE.
The ingest utility also supports the use of SQL expressions to build individual column
values from more than one data field.

© Copyright IBM Corp. 1997, 2017 6-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Other important features of the ingest utility include:

• Commit by time or number of rows. You can use the commit_count ingest
configuration parameter to have commit frequency determined by the number of
written rows or use the default commit_period ingest configuration parameter to
have commit frequency determined by a specified time.
• Support for copying rejected records to a file or table, or discarding them. You
can specify what the INGEST command does with rows rejected by the ingest
utility (using the DUMPFILE parameter) or by Db2 (using the EXCEPTION
TABLE parameter).
• Support for restart and recovery. By default, all INGEST commands are
restartable from the last commit point. In addition, the ingest utility attempts to
recover from certain errors if you have set the retry_count ingest configuration
parameter.
The INGEST command supports the following input data formats:
• Delimited text
• Positional text and binary
• Columns in various orders and formats
In addition to regular tables and nicknames, the INGEST command supports the
following table types:
• multidimensional clustering (MDC) and insert time clustering (ITC) tables
• range-partitioned tables
• range-clustered tables (RCT)
• materialized query tables (MQTs) that are defined as MAINTAINED BY USER,
including summary tables
• temporal tables
• updatable views (except typed views)

© Copyright IBM Corp. 1997, 2017 6-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

A single INGEST command goes through three major phases:

1. Transport
The transporters read from the data source and put records on the formatter
queues. For INSERT and MERGE operations, there is one transporter thread
for each input source (for example, one thread for each input file). For UPDATE
and DELETE operations, there is only one transporter thread.
2. Format
The formatters parse each record, convert the data into the format that Db2
database systems require, and put each formatted record on one of the flusher
queues for that record's partition. The number of formatter threads is specified
by the num_formatters configuration parameter.
The default is (number of logical CPUs)/2.
3. Flush
The flushers issue the SQL statements to perform the operations on the Db2
tables. The number of flushers for each partition is specified by the
num_flushers_per_partition configuration parameter.
The default is max( 1, ((number of logical CPUs)/2)/(number of partitions) ).

© Copyright IBM Corp. 1997, 2017 6-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Ingest command examples - Insert

• The following example inserts data from a delimited text file with fields
separated by a comma (the default).
• The fields in the file correspond to the table columns.

INGEST FROM FILE my_file.txt

FORMAT DELIMITED
(
$field1 INTEGER EXTERNAL,
$field2 DATE 'mm/dd/yyyy',
$field3 CHAR(32)
)
INSERT INTO my_table
VALUES($field1, $field2, $field3);

Moving data © Copyright IBM Corporation 2017

Ingest command examples - Insert

The visual shows an example of an INGEST command that inserts data from a
delimited text file with fields separated by a comma (the default).
The fields in the file correspond to the table columns.
INGEST FROM FILE my_file.txt
FORMAT DELIMITED
(
$field1 INTEGER EXTERNAL,
$field2 DATE 'mm/dd/yyyy',
$field3 CHAR(32)
)
INSERT INTO my_table
VALUES($field1, $field2, $field3);

© Copyright IBM Corp. 1997, 2017 6-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Ingest command examples - Update

• The following examples update the table rows whose primary key
matches the corresponding fields in the input file.

INGEST FROM FILE my_file.txt

FORMAT DELIMITED
(
$key1 INTEGER EXTERNAL,
$key2 INTEGER EXTERNAL,
$data1 CHAR(8),
$data2 CHAR(32),
$data3 DECIMAL(5,2) EXTERNAL
)
UPDATE my_table
SET (data1, data2, data3) = ($data1, $data2, $data3)
WHERE (key1 = $key1) AND (key2 = $key2);
Moving data © Copyright IBM Corporation 2017

Ingest command examples - Update

The visual shows an example of a INGEST utility that could be used to update a table’s
rows whose primary key matches the corresponding fields in the input file.
INGEST FROM FILE my_file.txt
FORMAT DELIMITED
(
$key1 INTEGER EXTERNAL,
$key2 INTEGER EXTERNAL,
$data1 CHAR(8),
$data2 CHAR(32),
$data3 DECIMAL(5,2) EXTERNAL
)
UPDATE my_table
SET (data1, data2, data3) = ($data1, $data2, $data3)
WHERE (key1 = $key1) AND (key2 = $key2);

© Copyright IBM Corp. 1997, 2017 6-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

INGEST utility - Configuration parameters

Parameter Range Default Description

COMMIT_COUNT 0 to max 32-bit 0 Number of rows each flusher writes in a

integer single transaction before issuing a commit.

COMMIT_PERIOD 0 to 2,678,400 (31 1 second Number of seconds between committed

days) transactions.

NUM_FLUSHERS_ See below. See below. Number of flushers to allocate for each
database partition (0 means 1 flusher for all
PER_PARITITON partitions)
NUM_FORMATTERS 1 to max number max(1, (number The number of formatter threads.
of threads of logical
CPUs)/2)

PIPE_TIMEOUT 0 to 2,678,400 600 seconds The maximum number of seconds to wait for
seconds (31 days) (10 minutes) data when the input source is a pipe (0
means wait indefinitely).
RETRY_COUNT 0 to 1000 0 The number of times to retry a failed (but
recoverable) transaction.
RETRY_PERIOD 0 to 2,678,400 0 The number of seconds to wait before
seconds (31 days) retrying a failed (but recoverable)
transaction.
SHM_MAX_SIZE 1 to available 1 GB Max size of IPC shared memory in bytes.
memory

Moving data © Copyright IBM Corporation 2017

INGEST utility - Configuration parameters

You can set these configuration parameters to control how the INGEST utility performs
on your Db2 client.
• commit_count - This parameter specifies the number of rows each flusher writes
in a single transaction before issuing a commit.
• commit_period - Specifies the number of seconds between committed
transactions.
• num_flushers_per_partition - Specifies the number of flushers to allocate for each
database partition.
• num_formatters - Specifies the number of formatters to allocate.
• pipe_timeout - This parameter specifies the maximum number of seconds to wait
for data when the input source is a pipe.
• retry_count - Specifies the number of times to retry a failed, but recoverable,
transaction.
• retry_period - Specifies the number of seconds to wait before retrying a failed, but
recoverable, transaction.

© Copyright IBM Corp. 1997, 2017 6-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

• shm_max_size - Specifies the maximum size of Inter Process Communication

(IPC) shared memory in bytes. Because the INGEST utility runs on the client, this
memory is allocated on the client machine.
The setting of options using INGEST SET affects only later INGEST commands in the
same CLP session that share the same CLP backend process.
It does not affect INGEST commands in other CLP sessions or later CLP sessions that
use a different CLP backend process.
The following examples set INGEST options using the INGEST SET command:
db2 INGEST SET num_flushers_per_partition 5
db2 INGEST SET shm_max_size 2 GB

© Copyright IBM Corp. 1997, 2017 6-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

INGEST - Restart (1 of 2)
• By default ingest jobs are restartable
• If the utility terminates due to an error or a crash, you can use the job
ID to restart it from the last commit point
• The utility generates a job ID of the form
DB21001:[Link], where
 DB21001 refers to DB2 V10.1
 [Link] is the utility start time
 sssss is the tablespace ID (from the catalog) as a positive integer
 ttttt is the table ID (from the catalog) as a positive integer
• You can also specify a job ID on the RESTART parameter

Moving data © Copyright IBM Corporation 2017

INGEST - Restart
The INGEST utility considers a command to be complete when it reaches the end of
the file or pipe. Under any other conditions, the INGEST utility considers the command
incomplete. These can include:
• The INGEST command gets an I/O error while reading the input file or pipe.
• The INGEST command gets a critical system error from the Db2 database
system.
• The INGEST command gets a Db2 database system error that is likely to prevent
any further SQL statements in the INGEST command from succeeding (for
example, if the table no longer exists).
• The INGEST command is killed or terminates abnormally.
By default, all INGEST commands are restartable from the last commit point.
The INGEST command option, RESTART NEW job-ID, specifies that if the INGEST
command fails before completing, it can be restarted from the point of the last commit
by specifying the RESTART CONTINUE option on a later INGEST command.

© Copyright IBM Corp. 1997, 2017 6-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The job-ID is a string of up to 128 bytes that uniquely identifies the INGEST command.
This job-ID must be unique across all INGEST commands in the current database that
specified the RESTART option and are not yet complete. (These could be commands
that are still running or that failed before completing.) Once the INGEST command
completes, you can reuse the job-ID on the RESTART parameter of a later INGEST
command. If the job-ID is omitted, the ingest utility generates one.

© Copyright IBM Corp. 1997, 2017 6-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

INGEST - Restart (2 of 2)
• Restart information is stored in a separate table
([Link]) that you create once
(similar to explain tables)
 To create the restart table
CALL [Link]('INGEST', 'C', NULL, NULL)
 The table does not contain copies of the data, only some counters to keep
track of which records have been ingested
• Restart is designed to have minimal overhead
• You can also specify:
 RESTART CONTINUE to restart a previously failed job
(and clean up the restart data)
 RESTART TERMINATE to clean up the restart data from a failed job you
don't plan to restart
 RESTART OFF to suppress saving of restart information
(in which case the ingest job is not restartable)
Moving data © Copyright IBM Corporation 2017

By default, failed INGEST commands are restartable from the last commit point;
however you first need to create a restart table, which stores the information needed to
resume an INGEST command.
You have to create the restart table only once, and that table will be used by all
INGEST commands in the database.
The ingest utility will use this table to store information needed to resume an incomplete
INGEST command from the last commit point.
The restart table does not contain copies of the input rows, only some counters to
indicate which rows have been committed.
It is recommended that you place the restart table in the same tablespace as the target
tables that the INGEST utility updates. If this is not possible, you must ensure that the
tablespace containing the restart table is at the same level as the tablespace containing
the target table. For example, if you restore or roll forward one of the table spaces, you
must restore or roll forward the other to the same level. If the table spaces are at
different levels and you run an INGEST command with the RESTART CONTINUE
option, the ingest utility could fail or ingest incorrect data.
If your disaster recovery strategy includes replicating the target tables of ingest
operations, you must also replicate the restart table so it is kept in sync with the target
tables.

© Copyright IBM Corp. 1997, 2017 6-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

To create the restart table call the [Link] stored

procedure:
db2 "CALL [Link]('INGEST', 'C', tablespace-name,
NULL)"
Use the RESTART CONTINUE option of INGEST, RESTART CONTINUE job-ID, that
specifies that the ingest utility is to restart a previous INGEST command that specified
the RESTART NEW option and failed before completing. The job-ID specified on this
option must match the job-ID specified on the previous INGEST command. This
restarted command is also restartable.

© Copyright IBM Corp. 1997, 2017 6-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Monitoring INGEST using INGEST LIST and

INGEST GET STATS
=> INGEST LIST
Ingest job ID = DB2100000:20101116.123456.234567:34567:45678
Ingest temp job ID = 4
Database Name = MYDB
Input type = FILE
Target table = MY_SCHEMA.MY_TABLE
Start Time = 01/10/2012 [Link].773215
Running Time = [Link]
Number of records processed = 30,000
=> INGEST GET STATS FOR 4 EVERY 3 SECONDS
Ingest job ID = DB2100000:20101116.123456.234567:34567:45678
Database = MYDB
Target table = MY_SCHEMA.MY_TABLE
Overall Overall Current Current
ingest rate write rate ingest rate write rate Total records
(records/second) (writes/second) (records/second) (writes/second)
---------------- --------------- --------------- ---------------- ----------------
3333 65432 76543 87654 108765
3334 75432 86543 97654 118765
3335 85432 96543 107654 128765
etc (new row every 3 seconds until INGEST command ends)
Moving data © Copyright IBM Corporation 2017

Monitoring INGEST using INGEST LIST and INGEST GET STATS

The INGEST LIST command lists basic information about INGEST commands that are
being run by the authorization ID that is connected to the database. The ingest utility
maintains statistics for a maximum of 128 ingest jobs running at a time.
A separate CLP session is required to successfully invoke this command. It must be run
on the same machine that the INGEST command is running on.
The INGEST GET STATS command displays statistics about one or more INGEST
commands that are being run by the authorization ID that is connected to the database.
The ingest utility maintains statistics for a maximum of 128 ingest jobs running at a time.

© Copyright IBM Corp. 1997, 2017 6-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

When to use INGEST rather than LOAD

• Use INGEST when any of the following is true
 You need other applications to update the table while it is being loaded
 The input file contains fields you want to skip over
 You need to specify an SQL statement other than INSERT
 You need to specify an SQL expression (to construct a column value from
field values)
 You need to recover and continue on when the utility gets a recoverable
error

Moving data © Copyright IBM Corporation 2017

When to use INGEST rather than LOAD

The visual suggests several conditions that may influence the use of INGEST rather
than using the LOAD utility.
One main reason for selecting INGEST over LOAD is the reduced lock contention for
INGEST, since it does not force the target table into a read-only or exclusive table lock
for processing.
You may also want to use the options of INGEST like UPDATE or MERGE that are not
supported by a LOAD.

© Copyright IBM Corp. 1997, 2017 6-68

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

When to use LOAD rather than INGEST

• Use LOAD when any of the following is true
 You don't need other applications to update the table while it is being loaded
 You need to load a table that contains XML or LOB columns
 You need to load from cursor or load from a device
 You need to load from a file in IXF format
 You need to load a GENERATED ALWAYS column or SYSTEM_TIME
column with the data specified in the input file

Moving data © Copyright IBM Corporation 2017

When to use LOAD rather than INGEST

The visual suggests some conditions when a LOAD utility may be preferred to using the
INGEST utility.
Some of the reasons relate to unsupported functions for the INGEST utility, like an input
file in IXF format, or unsupported data types like LOB or XML columns.

© Copyright IBM Corp. 1997, 2017 6-69

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Demonstration 1
Moving data
• Use the Db2 IMPORT command to load data into a Db2 table.
• Run the INGEST command to efficiently load data into a Db2 table.
• Invoke the LOAD utility to process input files and load data into Db2
tables.
• Run SET INTEGRITY commands to resolve the set integrity pending
conditions resulting from loading data into tables with constraints
defined using a LOAD utility.

Moving data © Copyright IBM Corporation 2017

Demonstration 1: Moving data

© Copyright IBM Corp. 1997, 2017 6-70

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Demonstration 1:
Moving data
Purpose:
This demonstration uses several methods to load data into Db2 tables
including the IMPORT, INGEST and LOAD commands. You will use the SET
INTEGRITY statement to resolve constraint checking after using a LOAD
command.

Task 1. Use the IMPORT utility to load data into a table.

1. Logon to the Linux system using the user id inst23, 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.
A set of course files are located in the directory $HOME/ddl. Change to this
directory to make it easier to access these files that contain Db2 commands or SQL
statements. The data to be loaded into the ARTISTS table is in the delimited file named
$HOME/[Link]
At this point you may choose to use the Db2 command line processor or the Data
Server Manager tool. Follow the steps for your chosen tool only, to run the IMPORT
command to load data into the ARTISTS table.
1A. Use the Db2 command line processor.
1. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 IMPORT from $HOME/[Link] of del insert into [Link]

© Copyright IBM Corp. 1997, 2017 6-71

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

The output generated will look similar to the following:

import from $HOME/[Link] of del insert into [Link]

SQL3109N The utility is beginning to load data from file
"$HOME/[Link]".

SQL3110N The utility has completed processing. "79" rows were read
from the
input file.

SQL3221W ...Begin COMMIT WORK. Input Record Count = "79".

SQL3222W ...COMMIT of any database changes was successful.

SQL3149N "79" rows were processed from the input file. "79" rows
were
successfully inserted into the table. "0" rows were rejected.

Number of rows read = 79

Number of rows skipped = 0
Number of rows inserted = 79
Number of rows updated = 0
Number of rows rejected = 0
Number of rows committed = 79

2. You can now skip to Task 2.

1B. Use the Data Server Manager tool.
You can use the Data Server Manager tool to run Db2 utilities. IMPORT and LOAD can
be executed using the SQL Editor function. These utilities need to be invoked using the
ADMIN_CMD procedure interface.
Open a Firefox Browser and select Bookmarks > Bookmarks Toolbar > Log in: IBM
Data Server Manager. Alternatively, you could type the following URL text to start
DSM, [Link]
When DSM was installed, a local user id and password were selected to be associated
with the application. For this course the following were configured:
Linux System user id: db2admin
User password: ibm2blue

© Copyright IBM Corp. 1997, 2017 6-72

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Click Script > Open from Client. Clear any SQL statements from the editor
that may remain from previous steps.
3. Use the Browse button for the Open SQL Script window to locate and select
the file inst23/ddl/import_artists.sql.
4. Click Open.
5. Click OK to complete loading the SQL text into the SQL editor.
The CALL to the procedure SYSPROC.ADMIN_CMD, will be used to invoke the
IMPORT command. The INSERT option of IMPORT is being used.
Notice the MESSAGES ON SERVER option is included, which allows the
IMPORT to run from a client system but the generated messages are stored on
the database server.
6. Click Run > Run All and wait for the SQL CALL statement to be processed.
7. You may click on Result Set under VIEW RESULTS to review the returned
statistics from import processing. This shows that 79 data rows were read
from the file and inserted into the table [Link].
Task 2. Use the INGEST command to load data into a
Db2 table.
You can use the Linux terminal session to run the INGEST command to load data files
into a Db2 table. The Data Server Manager tool does not currently provide a method to
invoke the INGEST command.
The INGEST command uses a work table [Link] to save
command restart data.
The file cr_toolspace.ddl will be used to create this table prior to running the INGEST
command. This only needs to be performed once per Db2 database.
The file $HOME/ddl/ingest_albums.ddl contains the following INGEST
command:
ingest from file /home/inst23/[Link]
format delimited messages ingest_albums.txt
RESTART NEW 'ingest_alb' INSERT INTO [Link] ;

© Copyright IBM Corp. 1997, 2017 6-73

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

1. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf cr_toolspace.ddl
• db2 -tvf ingest_albums.ddl
After a few seconds, the output generated will look similar to the following:

ingest from file /home/inst23/[Link] format delimited messages

ingest_albums.txt RESTART NEW 'ingest_alb' INSERT INTO [Link]

Number of rows read = 264

Number of rows inserted = 264
Number of rows rejected = 0

SQL2980I The ingest utility completed successfully at timestamp

"08/18/2015
[Link].608177"
Task 3. Use the Db2 LOAD utility to load data into a table that
has a foreign key constraint defined.
Next you will utilize the Db2 LOAD utility to add data to the STOCK table. The ALBUMS
table and ARTISTS table contain the data added using the IMPORT utility and INGEST
in the previous tasks.
You will use the LOAD command in the file $HOME/ddl/load_stock1.ddl to invoke the
load processing.
CALL SYSPROC.ADMIN_CMD (
'LOAD FROM "/home/inst23/[Link]" of del
MODIFIED BY GENERATEDMISSING METHOD P (1,2,3,4) MESSAGES ON SERVER
INSERT INTO [Link] (ITEMNO,TYPE,PRICE,QTY) ' ) ;
The file $HOME/ddl/set_integrity_stock.sql will be used to run SET INTEGRITY to
perform constraint checking not performed by the LOAD utility.
You will use the Db2 command line processor to execute the LOAD and SET
INTEGRITY commands.

© Copyright IBM Corp. 1997, 2017 6-74

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

1. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf load_stock1.ddl
• db2 -tvf set_integrity_stock.sql
Task 4. Run a file containing a series of LOAD commands and
SET INTEGRITY statements.
You may want to periodically refresh or extend tables with new data. If you use the Db2
LOAD utility and the target tables include referential or check constraints, you will need
to run SET INTEGRITY statements following the load processing.
You will utilize a command script that contains LOAD commands and SET INTEGRITY
statements to load data into several tables.
It is normally a good idea to use exception tables during a LOAD operation. You have
been provided a script (named create_exception_tables.ddl) that will create exception
tables for ARTISTS and ALBUMS.
At this point, you may choose to use the Db2 command line processor or the Data
Server Manager tool, to perform the LOAD and SET INTEGRITY processing.
Follow the steps for your chosen tool only.
4A. Use the Db2 command line processor.
The file $HOME/ddl/load_tables_clp.ddl contains LOAD and SET INTEGRITY
statements that perform the following:
• LOAD data in the CONCERTS table using the REPLACE option, this table
does not have any constraints to be checked.
• LOAD data into the ARTISTS table using the REPLACE option.
• A SQL query that searches the [Link] view for any tables with set
integrity pending status.
• The SET INTEGRITY statement to check the ARTISTS and ALBUMS tables.
• The SET INTEGRITY statement to check the STOCK table.
• A second SQL query to verify that all set integrity pending states have been
resolved.

© Copyright IBM Corp. 1997, 2017 6-75

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

1. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf create_exception_tables.ddl
• db2 -tvf load_tables_clp.ddl
The output produced will look similar to the following:

LOAD FROM "/home/inst23/[Link]" OF del METHOD P (1, 2, 3)

MESSAGES load_concert.txt REPLACE INTO [Link] (ARTNO, DATE,
CITY)

Number of rows read = 10

Number of rows skipped = 0
Number of rows loaded = 10
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 10

load from "/home/inst23/[Link]" of del messages load_art.txt

replace into [Link] for exception [Link]

Number of rows read = 79

Number of rows skipped = 0
Number of rows loaded = 79
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 79

select substr(tabname,1,18), status, substr(const_checked,1,1) as

FK_CHECKED, substr(const_checked,2,1) as CC_CHECKED from
[Link] where status='C'

1 STATUS FK_CHECKED CC_CHECKED

------------------ ------ ---------- ----------
ARTISTS C Y Y

1 record(s) selected.

SET INTEGRITY FOR [Link], [Link] ALLOW NO ACCESS

IMMEDIATE CHECKED FOR EXCEPTION IN [Link] use [Link] ,
in [Link] use [Link]
SQL3601W The statement caused one or more tables to automatically
be placed
in the Set Integrity Pending state. SQLSTATE=01586

© Copyright IBM Corp. 1997, 2017 6-76

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

SET INTEGRITY FOR [Link] ALLOW NO ACCESS IMMEDIATE CHECKED

DB20000I The SQL command completed successfully.

select substr(tabname,1,18), status, substr(const_checked,1,1) as

FK_CHECKED, substr(const_checked,2,1) as CC_CHECKED from
[Link] where status='C'

1 STATUS FK_CHECKED CC_CHECKED

------------------ ------ ---------- ----------

0 record(s) selected.
2. You have now completed this lab exercise. Do not complete any other steps.
4B. Use the Data Server Manager tool.
You can use the DSM tool to execute a SQL file that includes LOAD and SET
INTEGRITY processing.
First you will execute the SQL file create_exception_tables.ddl that creates exception
tables for the ALBUMS and ARTISTS tables. These can be referenced by LOAD and
SET INTEGRITY to be able to complete processing if there are exceptions to table
constraints.
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Clear any SQL statements from the editor that may remain from previous steps.
3. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/
create_exception_tables.ddl.
4. Click Open.
5. Click on OK to complete loading the SQL text into the SQL editor.
Review the options specified for the SQL statements.
6. Click Run > Run All and wait for the SQL statements to be processed.
The result should show that all statements succeeded. You may click on Log
under VIEW RESULTS to review each statement execution.

© Copyright IBM Corp. 1997, 2017 6-77

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Now you will use DSM to execute the SQL file that will perform the following
steps:
• Use ADMIN_CMD to LOAD data in the CONCERTS table using the
REPLACE option, this table does not have any constraints to be checked.
• Use ADMIN_CMD to LOAD data into the ARTISTS table using the
REPLACE option.
• A SQL query that searches the [Link] view for any tables with
set integrity pending status.
• The SET INTEGRITY statement to check the ARTISTS and ALBUMS tables.
• The SET INTEGRITY statement to check the STOCK table.
• A second SQL query to verify that all set integrity pending states have been
resolved.
The ADMIN-CMD procedure calls allow the LOAD utility to be initiated by
applications like DSM.
7. Click Run SQL from the options on the left. Clear any SQL statements from the
editor that may remain from previous steps.
8. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/ load_tables.sql.
9. Click Open.
10. Click on OK to complete loading the SQL text into the SQL editor.
Review the series of statements.
11. Click Run > Run All and wait for the SQL statements to be processed.
Browse the Results view to make sure all of the processing completed
successfully.
12. You may click on Result Set under VIEW RESULTS to review LOAD statistics
showing the number of rows of data read and the number of rows loaded into
the table.
The SELECT statement following the loading of the [Link] table
shows that the placed the ARTISTS table in set integrity pending.
The two SET INTEGRITY statements resolve all set integrity pending states.
Results:
You utilized several methods to load data into Db2 tables, including the
IMPORT, INGEST and LOAD commands. You used SET INTEGRITY
statements to resolve set integrity pending states for tables that were loaded
using the LOAD utility.

© Copyright IBM Corp. 1997, 2017 6-78

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

Unit summary
• Discuss using the INSERT SQL statement to populate tables
• Explain the differences between IMPORT and LOAD processing
• Explain the EXPORT, IMPORT, and LOAD command options
• Create and use Exception Tables and Dump-Files
• Check table status using LOAD QUERY
• Describe the ANALYZE phase of LOAD command processing used for
loading BLU Acceleration, column-organized tables.
• Check the Load Pending and Set Integrity Pending status for a table
• Use the SET INTEGRITY command
• Discuss the db2move and db2look commands
• Use the ADMIN_MOVE_TABLE procedure to move a table to different
table spaces
• List some of the features of the Ingest utility for continuous data ingest
Moving data © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 6-79

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 U n i t 6 M o vi n g d a t a

© Copyright IBM Corp. 1997, 2017 6-80

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Backup and recovery

Backup and recovery

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 7 Backup and recovery

© Copyright IBM Corp. 1997, 2017 7-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Unit objectives
• Describe the major principles and methods for backup and recovery
• State the three types of recovery used by Db2
• Explain the importance of logging for backup and recovery
• Describe how data logging takes place, including circular logging and
archival logging
• Use the BACKUP, RESTORE, ROLLFORWARD and RECOVER
commands
• Perform a table space backup and recovery
• Restore a database to the end of logs or to a point-in-time
• Discuss the configuration parameters and the recovery history file and
use these to handle various backup and recovery scenarios
• Create an encrypted backup image to improve data security

Backup and recovery © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 7-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 Database recovery methods

Create offline Database level Backup at 1AM Db2 Logs
Database at 1AM
12
11 1
10
9
2
3
Log 1
8
7
6
5
4 Backup DB Db2 Database

Database Backup Log 2

Log 3
1 Table spaces
Crash Recovery
Log 4
11
12
1 Database at 3PM
10 2
9 3

Log 5
8 4
Restore DB
Db2 Database
7 5
6

Database Backup Log 6

2 Version Recovery Roll forward

3
Recovery
Table spaces
Backup and recovery © Copyright IBM Corporation 2017

Db2 Database recovery methods

You need to know the strategies available to you to help when there are problems with
the database. Typically, you will deal with media and storage problems, power
interruptions, and application failures. You need to know that you can back up your
database, or individual table spaces, and then rebuild them should they be damaged or
corrupted. The rebuilding of these objects is called recovery.
There are three types or methods of recovery:
• Crash Recovery
Crash Recovery uses the logs to recover from power interrupts or application
abends. This type of recovery is normally automated by using the default value
for the configuration parameter autorestart. If autorestart is not used, manual
intervention would be necessary to restart a database requiring crash recovery.
• Version or Restore Recovery
Version or Restore Recovery uses a backup image of the database to replace the
current data in the database. This type provides recovery from media, hardware,
operational, and software problems, but only to the point that the backup copy
was made. Therefore, the more frequent the backups, the more current the
recovered database will be.

© Copyright IBM Corp. 1997, 2017 7-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• Roll Forward Recovery

Roll Forward Recovery uses a backup copy of a database or table spaces to
replace the current data and then applies log records to recover changes made
after the backup image was created. This type provides recovery from media,
hardware, operational, and software problems, and the recovery can be to a point
in time or to the last committed unit of work. Roll forward recovery using a recent
backup will require fewer logs to be applied than a roll forward using an older
backup, so the frequency of backup will still be a consideration for the database
administrator.

© Copyright IBM Corp. 1997, 2017 7-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Introduction to database logging

Read Only Committed Update Uncommitted Update

Db2 Agent
200 new 300 new Logbufsz = # (4 KB)
Db2 Agent Log Buffer
Buffer pools
Db2 Agent 200 old 200 new
201 new 301 new
100 101 Logger

I/O Servers Page Cleaners

Table space Containers Log Files

Log Control
300 new 300 old Files
100 300 old 301 new 201 new
201 new 201 old
301 new 301 old
101 200 old

Backup and recovery © Copyright IBM Corporation 2017

Introduction to database logging

Db2 database applications update the database by sending the SQL statements
through a Db2 agent processing at the database server. Db2 uses buffer pools to store
the data and index pages from the table spaces in database shared memory. The
changes to the tables are stored in the buffer pools. To support database recovery the
changes are recorded as log records that contain both the old and new data from the
row. The Db2 logger process utilizes another database shared memory area, the log
buffer, to temporarily store the log records until they are written to the Db2 log files for
this database. The size of the log buffer is determined by the Db2 database
configuration parameter LOGBUFSZ. When an application issues a COMMIT SQL
statement, Db2 will insure that the log Buffer is written to the Log file before the
application is returned an SQL completion code.

© Copyright IBM Corp. 1997, 2017 7-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

In most cases, the database updates are asynchronously written to the table space
containers on disk by the Db2 page cleaners. The page cleaning processing is
triggered by several different conditions including the following:
• The percentage of the buffer pool pages that contain an updated or dirty pages
exceeds the changed page threshold value for the database,
CHNGPGS_THRESH.
• The buffer pool contains many changed pages, and an updated page is selected
as the location to read a new page from disk. This can be referred to as victim
page cleaning or dirty page steal cleaning.
• Db2 detects the buffer pool contains a large number of changed pages that would
require an extended crash recovery process, so some changed pages are written
to reduce the recovery time.
Prior to Db2 10.5, this threshold for crash recovery processing was defined using the
SOFTMAX database configuration parameter. Starting with Db2 10.5, the database
configuration option PAGE_AGE_TRGT_MCR can be used to define a specific time for
changed pages to be kept in the local buffer pool before they are persisted to table
space.
The figure shows that during processing of the applications SQL statements, the buffer
pool contains:
• Some read-only pages (100 and 101) that have not been changed.
• An uncommitted change (200) that has not been written to the container disk.
• An uncommitted change (201) that has been written to the container disk.
• A committed change (300) that has not been written to the container disk.
• A committed change (301) that has been written to the container disk.
In the slide, all of the committed changes (300 and 301), have been written to the Db2
log disk. One uncommitted change (201) has also been written to the log disk. Another
uncommitted change (200) is currently in the log buffer but has not been written to the
log disk.

© Copyright IBM Corp. 1997, 2017 7-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Nonrecoverable database: Circular logging

CFG
Db2 Database
Table spaces
Logger
Uncommitted Updates
Cannot be Written Over logarchmeth1 = OFF

[Link] [Link] [Link]

[Link]
Logprimary = 4

[Link] [Link] STOP

Db2 Log Directory Logsecond = 2

Backup and recovery © Copyright IBM Corporation 2017

Nonrecoverable database: Circular logging

Circular logging will use the number of primary log files specified via a configuration
parameter. The necessary log information is for in-process transactions. The log files
are used in sequence. A log file can be reused when all units of work contained within it
are committed or rolled back, and the committed changes are reflected on the disks
supporting the database.
If the database manager requests the next log in the sequence and it is not available for
reuse, a secondary log file will be allocated. After it is full, the next primary log file is
checked for reuse again. If it is still not available, another secondary log file is allocated.
This process continues until the primary log file becomes available for reuse or the
number of secondary log files permitted for allocation is exceeded.
Primary log files are allocated when the database is created, while secondary log files
are allocated as needed. Secondary log files are deallocated once the database
manager determines that they are no longer needed. Therefore, the database
administrator might elect to use the primary log files for typical processing, but permit
the allocation of secondary log files to permit periodic applications that have large units
of work. For example, submission of an IMPORT utility with a large commit count might
require the use of secondary log files. Supporting such applications via primary logs
would be wasteful of space, since all primary logs, whether used or not, are allocated
when the database is activated.

© Copyright IBM Corp. 1997, 2017 7-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

If Db2 cannot continue logging due to a log full condition, database activity will halt until
a log file becomes available.
The logpath should be able to contain the sum of the primary and secondary logs.
LOGPRIMARY + LOGSECOND must be less than or equal to 256. LOGFILSIZ has a
maximum of 16 million 4 KB pages. The total active log file size limit is 16 TB.
The number of primary and secondary log files must comply with the following:
If logsecond has a value of -1, logprimary <= 256.
If logsecond does not have a value of -1, (logprimary + logsecond) <= 256.
Important: Circular logging provides support for crash and version/restore recovery, but
does NOT support roll forward recovery.

© Copyright IBM Corp. 1997, 2017 7-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Recoverable database: Archive logging

Logarchmeth1 = LOGRETAIN
CFG
Db2 Database
DISK
TSM
Logger VENDOR
Table spaces USEREXIT

Offline Archive Logs Online Archive Logs

[Link]
[Link]
[Link]
[Link] [Link]
Manual
[Link]
[Link]
[Link] or
First Active Log
Automated
[Link]
[Link] [Link] [Link]
[Link]
[Link]
[Link]
[Link] [Link]

Active Logs Logprimary = 4

Db2 Log Directory Logsecond = 2
Backup and recovery © Copyright IBM Corporation 2017

Recoverable database: Archive logging

A Recoverable Db2 database implies that the Db2 logs are not being reused. Archive
Logging mode is activated either by setting the LOGARCHMETH1 database
configuration parameter to LOGRETAIN, DISK, TSM, VENDOR or USEREXIT. This
change places the database in Backup Pending status, which requires a full offline
database backup as a starting point for future recovery. Once activated, the database
produces a sequence of log files to record all database changes. Archive logging is
used specifically for roll forward recovery. Data that cannot be easily re-created should
be stored in a recoverable database. This includes data whose source is destroyed
after the data is loaded, data that is manually entered into tables, and data that is
modified by application programs or users after it is loaded into the database.
Db2 log files can be Active Logs, which are in the database log path directory and are
needed to support crash recovery, either due to uncommitted database updates or
database updates applied to the buffer pools that have not been written to the table
space containers by Db2 page cleaners.

© Copyright IBM Corp. 1997, 2017 7-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Archived logs can be:

• Online Archived logs: When changes in the active log are no longer needed to
support crash recovery but the log file is still located in the database log path
directory. These could be used to support a rollforward recovery at the database
or table space level.
• Offline archived logs: An archived log is said to be offline when it is no longer
found in the database log path directory. You can automate storing archived logs
in a location other than the database log path directory by setting the
logarchmeth1 and logarchmeth2 configuration parameters. Log files can also be
manually moved to another location using operating system commands.
To determine which log extents in the database log path directory are archived logs,
you need to determine the starting point for active logs, the ‘First Active log’, which
indicates the lowest numbered log that is active. Those logs with sequence numbers
less than loghead are online archived logs and can be moved.
You can check the value of ‘First Active log’ using the command line processor and the
GET DATABASE CONFIGURATION command to view the First active log file value.
You can also use the MON_GET_TRANSACTION_LOG table function in a SQL query
to return the FIRST_ACTIVE_LOG value.

© Copyright IBM Corp. 1997, 2017 7-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Location of Active log files

CFG
Db2 Database Table spaces

Logger db2 UPDATE DB CFG FOR TP1

Default Active Log path USING NEWLOGPATH /dblogs/TP1
Instance
NODE0000 Newlogpath
/dblogs/TP1/NODE0000/LOGSTREAM0000
SQL0000n

LOGSTREAM0000
[Link] [Link]
[Link]
[Link] Logfilsiz = # of (4 KB Blocks)
[Link]
[Link] [Link] [Link]

[Link]
[Link] Active Logs Logprimary = 4
Uses database path
Backup and recovery © Copyright IBM Corporation 2017

Location of Active log files

When a new Db2 database is created with the CREATE DATABASE command, the
Db2 log path is set to the LOGSTREAM0000 directory in the path with the other
database control files. It is good practice to isolate the location of the active Db2 log files
to a different disk than the database path so that loss of that one path would not create
a damaged database that could not be fully recovered. Use the UPDATE DB CFG
command to change the location of the Db2 logs. For example:
UPDATE DB CFG FOR TP1 USING NEWLOGPATH /dblogs/TP1
The next time the database activates, a new set of Db2 log files will be created and
formatted in the new directory. In a single or multiple database partition environment,
the database partition number, NODExxxx, is automatically appended to the path. This
is done to maintain the uniqueness of the log paths in multiple partition databases. The
log stream directory, LOGSTREAMxxx was added to support the Db2 pureScale
database environments, where each database member produces its own log stream.
For single partition, non-pureScale databases, this will be LOGSTREAM0000.

© Copyright IBM Corp. 1997, 2017 7-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Configure database logs: Parameters

Primary log files New log path
(LOGPRIMARY) + (NEWLOGPATH)
? ?
Secondary log files Mirror log path
(LOGSECOND) (MIRRORLOGPATH)

Log size Primary Log

(LOGFILSIZ) Archive Method
Y
N (LOGARCHMETH1)
E DEFAULT
O Secondary Log
Log Buffer S
(LOGBUFSIZ) Archive Method
(LOGARCHMETH2)

Overflow log path Dirty Page Cleaning

(OVERFLOWLOGPATH) Triggers
SOFTMAX and
? - ? PAGE_AGE_TRGT_MCR

Backup and recovery © Copyright IBM Corporation 2017

Configure database logs: Parameters

You can use the Information Center or the product documentation to review the detailed
options for database logging. Here are some of the basic options:
• Log archive method 1 (logarchmeth1), log archive method 2 (logarchmeth2)
These parameters cause the database manager to archive log files to a location
that is not the active log path. If you specify both of these parameters, each log
file from the active log path that is set by the logpath configuration parameter is
archived twice. This means that you will have two identical copies of archived log
files from the log path in two different destinations. If you specify mirror logging by
using the mirrorlogpath configuration parameter, the logarchmeth2 configuration
parameter archives log files from the mirror log path instead of archiving
additional copies of the log files in the active log path. This means that you have
two separate copies of the log files archived in two different destinations: one
copy from the log path and one copy from the mirror log path.

© Copyright IBM Corp. 1997, 2017 7-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• Log Buffer (logbufsz)

This parameter allows you to specify the amount of memory to use as a buffer for
log records before writing these records to disk. The log records are written to
disk when any one of the following events occurs:
• A transaction commits
• The log buffer becomes full
• Some other internal database manager event occurs.
Increasing the log buffer size can result in more efficient input/output (I/O) activity
associated with logging, because the log records are written to disk less
frequently, and more records are written each time. However, recovery can take
longer with a larger log buffer size value. As well, you may be able to use a higher
logbufsz setting to reduce number of reads from the log disk. (To determine if
your system would benefit from this, use the log_reads monitor element to check
if reading from log disk is significant.
• Log file size (logfilsiz)
This parameter specifies the size of each configured log, in number of 4-KB
pages.
There is a 16 TB logical limit on the total active log space per log stream that you
can configure. This limit is the result of the upper limit for each log file, which is 64
GB, and the maximum combined number of primary and secondary log files,
which is 256.
The size of the log file has a direct bearing on performance. There is a
performance cost for switching from one log to another. So, from a pure
performance perspective, the larger the log file size the better. This parameter
also indicates the log file size for archiving. In this case, a larger log file is size it
not necessarily better, since a larger log file size can increase the chance of
failure or cause a delay in log shipping scenarios. When considering active log
space, it might be better to have a larger number of smaller log files. For
example, if there are two very large log files and a transaction starts close to the
end of one log file, only half of the log space remains available.

© Copyright IBM Corp. 1997, 2017 7-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• Mirror log path (mirrorlogpath)

To protect the logs on the primary log path from disk failure or accidental deletion,
you can specify that an identical set of logs be maintained on a secondary
(mirror) log path. To do this, change the value of this configuration parameter to
point to a different directory. Active logs that are currently stored in the mirrored
log path directory are not moved to the new location if the database is configured
for rollforward recovery.
The mirrorlogpath parameter also has an effect on log archiving behavior, which
you can use to further improve resilience during rollforward recovery: When both
mirrorlogpath and logarchmeth2 are set, logarchmeth2 archives log files from the
mirror log path instead of archiving additional copies of the log files in the active
log path. You can use this log archiving behaviour to improve resilience, because
a usable, archived log file from the mirror log path might still be available to
continue a database recovery operation, even if a primary log file became
corrupted due to a disk failure before archiving.
• New log path (newlogpath)
The database logs are initially created in the following directory:
db_path/instance_name/dbname/NODE0000/LOGSTREAM0000. You can
change the location in which active log files are placed (and future log files will be
placed) by changing the value of this configuration parameter to point to a
different directory or to a device. Active logs that are currently stored in the
database log path directory are not moved to the new location if the database is
configured for rollforward recovery.
Because you can change the log path location, the logs needed for rollforward
recovery might exist in different directories or on different devices. You can
change the value of this configuration parameter during a rollforward operation to
allow you to access logs in multiple locations.
• Overflow log path (overflowlogpath)
This parameter can be used for several functions, depending on your logging
requirements. You can specify a location for the Db2 database manager to find
log files that are needed for a rollforward operation. It is similar to the
OVERFLOW LOG PATH option of the ROLLFORWARD command; however,
instead of specifying the OVERFLOW LOG PATH option for every
ROLLFORWARD command issued, you can set this configuration parameter
once. If both are used, the OVERFLOW LOG PATH option will overwrite the
overflowlogpath configuration parameter for that rollforward operation.

© Copyright IBM Corp. 1997, 2017 7-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

If logsecond is set to -1, you can specify a directory for the Db2 database
manager to store active log files retrieved from the archive. (Active log files must
be retrieved for rollback operations if they are no longer in the active log path).
If overflowlogpath is not specified, the Db2 database manager will retrieve the log
files into the active log path. By specifying this parameter you can provide an
additional storage resource where the Db2 database manager can place the
retrieved log files. The benefit includes spreading the I/O cost to different disks,
and allowing more log files to be stored in the active log path.
• Primary log files (logprimary)
This parameter specifies the number of primary logs of size logfilsiz that will be
created.
A primary log file, whether empty or full, requires the same amount of disk space.
Thus, if you configure more logs than you need, you use disk space
unnecessarily. If you configure too few logs, you can encounter a log-full
condition. As you select the number of logs to configure, you must consider the
size you make each log and whether your application can handle a log-full
condition.
If you are enabling an existing database for rollforward recovery, change the
number of primary logs to the sum of the number of primary and secondary logs,
plus one.
• Secondary logs (logsecond)
This parameter specifies the number of secondary log files that are created and
used for recovery, if needed.
If the primary log files become full, secondary log files (of size logfilsiz) are
allocated, one at a time as needed, up to the maximum number specified by this
parameter. If this parameter is set to -1, the database is configured with infinite
active log space. There is no limit on the size or number of in-flight transactions
running on the database. Infinite active logging is useful in environments that
must accommodate large jobs requiring more log space than you would normally
allocate to the primary logs.
• Softmax and PAGE_AGE_TRGT_MCR
These two options can be used to trigger buffer pool page cleaning to minimize
replay processing during a crash recovery. Softmax is configured as a
percentage of the log file size, so it is driven by the quantity of logging.
PAGE_AGE_TRGT_MCR is configured as a number of seconds that dirty pages
could remain in a buffer pool before they are written to the tablepsace disk.

© Copyright IBM Corp. 1997, 2017 7-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Archiving logs to Local disks

db2 update db cfg for salesdb using logarchmeth1 disk:/dbarchlcl

Path Includes:
– Instance Name
SALESDB
DB CFG INST1 – Database Name
Database
– Database Partition (NODExxxx)
db2 Log – Log Stream (LOGSTREAMxxxx)
Database
Active Logs
Manager – Current Log Chain
Directory

Local
Table Spaces
Recovery Archive Current Log Chain
History logs

/dbarchlcl/INST1/SALESDB/NODE0000/LOGSTREAM0000/C0000000

Backup and recovery © Copyright IBM Corporation 2017

Archiving logs to Local disks

The example shows a database that is configured to save log archives to a disk path.
For all db cfg parms that specify a path, there are no default values because Db2 is
unable to detect which disks are available to it in the system. Furthermore, it is ideal to
not store archived log files on the same disk as table space containers or the log path.
Such a configuration causes heavy strain on the disk and also consumes storage
space quickly. When dynamically updating the LOGARCHMETHx db cfg parms, the
change will take effect on the next log file to be archived. All previously archived log
files remain in their current location and any current archive operations will complete
using the old LOGARCHMETHx setting.
All paths specified for any log archive cfg parms must be fully qualified and created by
the user. Db2 must have at least read permission (write permission required if Db2 will
be writing log files to that path). When archiving log files, Db2 will append the instance
name, database name, the node number and the log stream (which will be
LOGSTREAM0000) to the archive and failover paths. This will allow a dbadmin to
execute the same configuration commands for each database in multiple instances,
and still ensure that each database will have a unique directory for its log file.

© Copyright IBM Corp. 1997, 2017 7-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

For the DISK option, Db2 will append a chain number in the form of CXXXXXXX (where
XXXXXXX is in the range 0000000 to 9999999) which will allow the Recovery File to
maintain separate locations for each log chain throughout the life of the database. As
such, the path cannot be longer than 206 characters in length (maximum path length -
instance name length - log file name length - node name length - maximum database
name length - chain name length - 4 slashes = 255 - 8 - 12 - 8 - 8 - 8 - 5 = 206).
For example, in a 1-node system where the LOGARCHMETH1 is set by the dbadmin to
DISK:/home/dbuser/archivedlogs for database DBX in instance DB2INST1, the log files
would actually be archived to
"/home/dbuser/archivedlogs/DB2INST1/DBX/NODE0000/LOGSTREAM0000/C0000000".
The log chain value will be incremented automatically by Db2 each time the database is
restored with the Db2 RESTORE utility. This will help to prevent accidental loss of older
log files if a Db2 database is recovered to a point in time.

© Copyright IBM Corp. 1997, 2017 7-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 recovery-related system files (1 of 2)

• Recovery History File - [Link]: Database Directory
 Created during Create Database command
Instance
 Updated by Db2 Utility execution:
− Back up database or table space
NODE0000
− Restore database or table space
− Roll forward database or table space
SQL0000n
− Load table
[Link]
− Reorg table [Link].1
− Db2 Log file archival [Link].2
− Create/Alter/Rename table space
− Quiesce table spaces for table MEMBER0000

− Drop Table (optional) [Link].1

[Link].2
 Included on each Db2 backup file
 db2 LIST HISTORY command

Backup and recovery © Copyright IBM Corporation 2017

Db2 recovery-related system files

Recovery History file
A recovery history file is created with each database and is automatically updated
whenever:
• A database or table spaces are backed up
• A database or table spaces are restored
• A database or table spaces are rolled forward
• A database is automatically rebuilt and more than one image is restored
• A table space is created
• A table space is altered
• A table space is quiesced
• A table space is renamed
• A table space is dropped
• A table is loaded
• A table is dropped (when dropped table recovery is enabled)

© Copyright IBM Corp. 1997, 2017 7-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• A table is reorganized
• On-demand log archiving is invoked
• A new log file is written to (when using recoverable logging)
• A log file is archived (when using recoverable logging)
• A database is recovered
The LIST HISTORY command lists entries in the database history records. The
database history records contain a record of recovery and administrative events.
Recovery events include full database and table space level backup, incremental
backup, restore, and rollforward operations. Additional logged events include create,
alter, drop, or rename table space, reorganize table, drop table, and load.

© Copyright IBM Corp. 1997, 2017 7-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 recovery-related system files (2 of 2)

• Log Control Files – [Link].1/2:
 Used during crash recovery
 Disk updated at end of each Log File
 Use SOFTMAX or PAGE_AGE_TRGT_MCR
to refresh pointers more often
 Included at end of each Db2 backup

Backup and recovery © Copyright IBM Corporation 2017

Log control files

When a database restarts after a failure, the database manager applies transaction
information stored in log files to return the database to a consistent state. To determine
which records from the log files need to be applied to the database, the database
manager uses information recorded in log control files.
Redundancy for database resilience
The database manager maintains two copies of the each member's log control file,
[Link].1 and [Link].2, and two copies of the global log control
file, [Link].1 and [Link].2, so that if one copy is damaged, the
database manager can still use the other copy.

© Copyright IBM Corp. 1997, 2017 7-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Backup Utility options (partial)

BACKUP DATABASE database-alias [USER username [USING password]]
[TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
[INCREMENTAL [DELTA]]
[USE {TSM | XBSA} [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}] | TO dir/dev
[ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess SESSIONS]
[OPTIONS {options-string | options-filename}]]
[WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
[COMPRESS COMPRLIB--name- | EXCLUDE COMPROPTS string ]
[ENCRYPT ENCRLIB--name | EXCLUDE ENCROPTS string ]
[UTIL_IMPACT_PRIORITY [priority]
[{INCLUDE | EXCLUDE} LOGS] [WITHOUT PROMPTING]

Backup and recovery © Copyright IBM Corporation 2017

Backup Utility options (partial)

Use the BACKUP DATABASE command to take a copy of the database data and store
it on a different medium. This backup data can then be used in the case of a failure or
damage to the original data. You can back up an entire database, database partition, or
only selected table spaces.
You do not need to be connected to the database that is to be backed up: the backup
database utility automatically establishes a connection to the specified database, and
this connection is terminated at the completion of the backup operation. If you are
connected to a database that is to be backed up, you will be disconnected when the
BACKUP DATABASE command is issued and the backup operation will proceed.
The database can be local or remote. The backup image remains on the database
server, unless you are using a storage management product such as Tivoli Storage
Manager (TSM) or Db2 Advanced Copy Services (ACS).
If you are performing an offline backup and if you have activated the database by using
the ACTIVATE DATABASE command, you must deactivate the database before you
run the offline backup.

© Copyright IBM Corp. 1997, 2017 7-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

If there are active connections to the database, in order to deactivate the database
successfully, a user with SYSADM authority must connect to the database, and issue
the following commands:
CONNECT TO database-alias
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS;
UNQUIESCE DATABASE;
TERMINATE;
DEACTIVATE DATABASE database-alias
Encrypt a database backup image
When you create an encrypted database, the encrlib and encropts database
configuration parameters are set such that subsequent database backup operations
use the native Db2 encryption library with options that were specified at database
creation time. In the following example, a database backup image is encrypted by using
the current (non-null) values of the encrlib and encropts configuration parameters.

© Copyright IBM Corp. 1997, 2017 7-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

The backup files

• File name for backup images on disk has:
 Database alias
 Type of backup (0=full, 3=table space, 4=copy from table load)
 Instance name
 Database Partition (DBPARTnnn, nnn is 000 for single partition DB)
 Timestamp of backup (YYYYMMDDHHMMS)
 Sequence number (for multiple files)
 MUSICDB.0.DB2.DBPART000. 20140522120112 .001
• Tape images are not named, but internally contain the same
information in the backup header for verification purposes
• Backup history provides key information in easy-to-use format

Backup and recovery © Copyright IBM Corporation 2017

The backup files

On all operating systems, file names for backup images created on disk consist of a
concatenation of several elements, separated by periods:
DB_alias.Type.Inst_name.[Link].Seq_num
For example:
STAFF.0.DB201.DBPART000.20140922120112.001
• Database alias - A 1- to 8-character database alias name that was specified
when the backup utility was invoked.
• Type - Type of backup operation, where: 0 represents a full database-level
backup, 3 represents a table space-level backup, and 4 represents a backup
image generated by the LOAD COPY TO command.
• Instance name - A 1- to 8-character name of the current instance that is taken
from the DB2INSTANCE environment variable.
• Database partition number - In single partition database environments, this is
always DBPART000. In partitioned database environments, it is DBPARTxxx,
where xxx is the number assigned to the database partition in the [Link]
file.

© Copyright IBM Corp. 1997, 2017 7-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• Time stamp - A 14-character representation of the date and time at which the
backup operation was performed. The time stamp is in the form
yyyymmddhhnnss, where:
• yyyy represents the year (1995 to 9999)
• mm represents the month (01 to 12)
• dd represents the day of the month (01 to 31)
• hh represents the hour (00 to 23)
• nn represents the minutes (00 to 59)
• ss represents the seconds (00 to 59)
• Sequence number - A 3-digit number used as a file extension.

© Copyright IBM Corp. 1997, 2017 7-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Syntax of the RESTORE command (partial)

RESTORE DATABASE source-database-alias | restore-options |
DB CONTINUE
ABORT
Restore options:

USER username TABLESPACE ONLINE

USING password ,

TABLESPACE ( tablespace-name )
ONLINE

HISTORY FILE
ONLINE

USE TSM TAKEN AT date-time

OPEN num-sessions SESSIONS
,

FROM directory
device

LOAD shared-library
OPEN num-sessions SESSIONS

TO target-directory INTO target-database-alias NEWLOGPATH directory

WITH num-buffers BUFFERS BUFFER buffer-size REPLACE EXISTING REDIRECT

...
WITHOUT ROLLING FORWARD WITHOUT PROMPTING

Backup and recovery © Copyright IBM Corporation 2017

Syntax of the RESTORE command (partial)

The simplest form of the Db2 RESTORE DATABASE command requires only that you
specify the alias name of the database that you want to restore.
For example:
db2 restore db sample
In this example, because the SAMPLE database exists and will be replaced when the
RESTORE DATABASE command is issued, the following message is returned:
SQL2539W Warning! Restoring to an existing database that is the same as the
backup image database. The database files will be deleted.
Do you want to continue ? (y/n) If you specify y, the restore operation should complete
successfully.
A database restore operation requires an exclusive connection: that is, no applications
can be running against the database when the operation starts, and the restore utility
prevents other applications from accessing the database until the restore operation
completes successfully. A table space restore operation, however, can be done online.
A table space is not usable until the restore operation (possibly followed by rollforward
recovery) completes successfully.

© Copyright IBM Corp. 1997, 2017 7-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

If you have tables that span more than one table space, you should backup and restore
the set of table spaces together.
When doing a partial or subset restore operation, you can use either a table space-level
backup image, or a full database-level backup image and choose one or more table
spaces from that image. All the log files associated with these table spaces from the
time that the backup image was created must exist.
You can restore a database from a backup image taken on a 32-bit level into a 64-bit
level, but not vice versa.
The Db2 backup and restore utilities should be used to backup and restore your
databases. Moving a fileset from one machine to another is not recommended as this
may compromise the integrity of the database.
Under certain conditions, you can use transportable sets with the RESTORE
DATABASE command to move databases. .
Important: In IBM Data Studio Version 4.1, you can use the task assistant for restoring
database backups. Task assistants can guide you through the process of setting
options, reviewing the automatically generated commands to perform the task, and
running these commands.

© Copyright IBM Corp. 1997, 2017 7-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Backup/restore table space considerations

• Recoverable Database - Roll-forward must be enabled
• Can choose to restore a subset of table spaces
• Generally best to put multiple spaces in one backup image:
 Makes table space recovery strategy easier
 Provides access to related tables spaces and coherent management of
these table spaces
• Handling of long/LOB/XML data requires a correlated strategy
• Point-in-time recovery is supported, but has requirements
• Faster recovery for Catalogs using Tablespace Level backup
• Critical business application tables should obviously be the focus of the
backup/restore, but other tables are needed in support of these tables

Backup and recovery © Copyright IBM Corporation 2017

Backup/restore table space considerations

In order to use table space level backup and restore, archive logging must be used.
A subset of table spaces can be restored from a database or table space backup
image.
One of the key reasons to use table space level recovery is to reduce the time of
backup and restore. This is accomplished by reducing the amount of data involved in
these processes. However, the database administrator should not strive to simply
minimize the amount of data in a backup. Although this could be accomplished by
placing a single table in its own table space, this would be likely to lead to a
management problem concerning backup and recovery.
If the table spaces associated with closely related tables are all contained in a single
backup, only the applications targeting the closely related tables are affected. In many
cases, such applications would be affected even if a single table in the group was
unavailable. This is especially true in the case of referentially constrained tables. You
should consider grouping the table spaces that support referential structures in a single
backup image.
The key is to reduce the amount of data involved in the event recovery; this is
necessary while controlling the impact on management of the backup/restore strategy.

© Copyright IBM Corp. 1997, 2017 7-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

LOB data and long field data can be placed in a table space that is separate from the
regular data. This is often desirable from a recovery standpoint because the frequency
of taking backups of the LOB data can be much less than that of the regular data. The
nature of LOB data is that it tends not to be updated frequently and it is large. However,
if a REORG of such a table and its LOB data is one of the actions recorded in the log
files through which you are rolling forward, you must have all table spaces relating to
the table in the backup, defeating one of your reasons to separate the data. The
solution is to establish new backups of the table spaces associated with such tables
AFTER a REORG that includes the LOB data.
Point-in-time recovery during roll forward is supported.
If the catalog tables are involved in a recovery situation, access to the entire database
is impacted. Therefore, it is good practice to maintain table space level backups of your
catalog tables. If you need to recover the catalog, the duration of the process will be
reduced if you can restore a table space backup instead of a database backup.
Application tables considered critical to the business should also be considered prime
candidates for table space recovery. The major reason is the reduction in downtime
provided through the table space backup/restore strategy.

© Copyright IBM Corp. 1997, 2017 7-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Encryption options for BACKUP and RESTORE

• ENCRLIB and ENCROPTS database configuration parameters are set
automatically for encrypted databases
• Backups of an encrypted database will be encrypted by default
• A non-encrypted database can produce an encrypted backup using the
ENCRYPT option of BACKUP
• A non-encrypted backup of an encrypted database can only be
produced if the ENCRLIB and ENCROPTS in the DB CFG are set to
NULL
• A backup image can be used to encrypt a new database using the
ENCRYPT option of RESTORE

Backup and recovery © Copyright IBM Corporation 2017

Encryption options for BACKUP and RESTORE

When you create an encrypted database, the encrlib and encropts database
configuration parameters are set such that subsequent database backup operations
use the native Db2 encryption library with options that were specified at database
creation time. In the following example, a database backup image is encrypted by using
the current (non-null) values of the encrlib and encropts configuration parameters.
db2 backup database ccards
The Db2 library that implements native backup encryption support is named [Link]
on Windows operating systems. On other platforms, the library name is libdb2encr, and
the library file name extension is operating system-dependent. To specify a different
library, or to specify the Db2 library when automatic encryption of backup images is not
enabled (that is, when the encrlib database configuration parameter is set to the null
value), use the ENCRLIB option on the BACKUP DATABASE command, as shown in
the following example:
db2 backup database ccards encrypt encrlib '[Link]'

© Copyright IBM Corp. 1997, 2017 7-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

The client wants to restore an encrypted backup image. By default, the encryption
library is stored within the backup image itself, but the client decides to specify an
encryption library by using the ENCRLIB option on the RESTORE DATABASE
command. And also by default, the RESTORE DATABASE command tries to decrypt
the data encryption key by using the master key that was used to encrypt the data
encryption key in the backup image. In the following example, an encrypted database
backup image is restored by using a specific master key label.
db2 restore database ccards encrlib '[Link]'
encropts 'Master Key
Label=[Link]'
Recover an encrypted database backup image into a new database
The client wants to recover an encrypted backup image. In the following example, an
encrypted database backup image is recovered into a new encrypted database. The
client has been making periodic backup copies of the history, so the USING HISTORY
FILE option is used to point to a specific version of the history file.
db2 recover database ccards
using history file (/home/user/myfiles/)
encrypt
cipher aes
key length 128
master key label [Link]

© Copyright IBM Corp. 1997, 2017 7-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 support for the NX842 Accelerator

• Db2 backup and log archive compression now support the NX842
hardware accelerator on POWER 7+ and POWER 8 processors
• Db2 BACKUPs require the use of a specific NX842 library
 backup database <dbname> compress comprlib libdb2nx842.a
• Backups can be compressed by default with NX842
 Registry variable DB2_BCKP_COMPRESSION has to be set to NX842
 Use the following backup command format:
 backup database <dbname> compress
• Log archive compression is also supported
 Update the database configuration parameter LOGARCHCOMPR1 or
LOGARCHCOMPR2 to NX842
 update database configuration for <dbname>
using LOGARCHCOMPR1 NX842
 Note: These two parameters can still take different values

Backup and recovery © Copyright IBM Corporation 2017

Db2 support for the NX842 Accelerator

By using the nest accelerator NX842 of POWER 7+ and POWER 8 processors, you
can achieve hardware compression for backup images and log archive files on AIX.
Prerequisites
• This solution is only supported on AIX. Minimum AIX levels are AIX V7 TL3 SP3
and AIX V6 TL9 SP3.
• Active Memory Expansion (AME) has to be licensed but must not be enabled.
This is a temporary restriction and not a technical limitation. In addition, Active
Memory Sharing (AMS) has to be deactivated on the logical partition (LPAR).
The CPU has to be a POWER 7+ or later. Remember, provided that the kernel
requirements are met, it is possible to recover using the backup images and log files
that were compressed with NX842 on previous POWER versions.

© Copyright IBM Corp. 1997, 2017 7-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Advantages of using this solution

• A very fast compression can be achieved through the special hardware
compression unit NX842 on POWER CPUs. The general CPU resources are not
used for this compression.
• The NX842 compression units are typically not used for AME on database
servers since deep row compression, adaptive compression and index
compression can make memory compression inefficient.
• The compression algorithm in hardware provides faster compression than the
common Db2® compression.
How to use this as backup
• To start a backup using the hardware compression, it is necessary to specify the
library:
backup database databasename compress comprlib
libdb2nx842.a
• The backups can be compressed by default with NX842. To achieve this the
registry variable DB2_BCKP_COMPRESSION has to be set to NX842.
Afterwards, issue the command: backup database database name
compress. The image will then be compressed using the NX842 hardware
compression.
Using the solution for log archive compression
The NX842 hardware compression can also be used for log archive compression. To
activate this, change the database configuration parameter LOGARCHCOMPR1 or
LOGARCHCOMPR2 to NX842 using this command:
update database configuration for databasename using
LOGARCHCOMPR1 NX842
Note: These two parameters can still take different values. For example, the common
Db2 compression can be used for LOGARCHCOMPR1 and NX842
compression for LOGARCHCOMPR2:
update database configuration for databasename using
LOGARCHCOMPR1 ON
update database configuration for databasename using
LOGARCHCOMPR2 NX842

© Copyright IBM Corp. 1997, 2017 7-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 backup compression performance results

• Preliminary results from early system testing
• About 50% Db2 backup size reduction compared to uncompressed
• Factor 2x less CPU consumption compared to Db2 compression
 Very significant reduction in CPU consumption
 Very significant reduction in elapsed time
 Maintains almost all of the compression storage benefits

Internal Tests at IBM Germany Research & Development

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary
depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload
processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.

Backup and recovery © Copyright IBM Corporation 2017

Db2 backup compression performance results

The slide shows the results of some performance tests when using the NX842
accelerator.
The tests compare a Db2 BACKUP with no compression to one with software
compression and one using the hardware-based compression. The bars show backup
file size, backup elapsed time, and restore elapsed time.
• Db2 backups are compressed to about 50 percent of what a normal backup
would be.
In addition, the CPU of the system is not used to do the compression, so the total CPU
overhead is reduced by a factor of 2.1.

© Copyright IBM Corp. 1997, 2017 7-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Using CATALOG STORAGE ACCESS commands to define cloud

storage access
• The CATALOG STORAGE ACCESS command creates an alias for accessing
remote storage
 IBM® SoftLayer® Object Storage
 Amazon Simple Storage Service (S3)
 Supported by the INGEST, LOAD, BACKUP DATABASE, or RESTORE
DATABASE commands.
• When you create a storage access alias, your remote storage account credentials
are safely stored in an encrypted keystore.
• The Db2 instance needs to be configured to support a keystore to be able to define
the remote storage
For example:

CATALOG STORAGE ACCESS ALIAS montrealprivate vendor softlayer

server [Link]
user SLOS482762-5:SL729462
password a1b635c2556681ddd8354daa2db1dbc88bb6da3311c8904319058a9434169c3
container container1 dbuser thomas

Backup and recovery © Copyright IBM Corporation 2017

Using CATALOG STORAGE ACCESS commands to define cloud storage access

The CATALOG STORAGE ACCESS command creates an alias for accessing remote
storage on IBM SoftLayer Object Storage or Amazon Simple Storage Service (S3)
directly with the INGEST, LOAD, BACKUP DATABASE, or RESTORE DATABASE
commands.
When you create a storage access alias, your remote storage account credentials are
safely stored in an encrypted keystore.
When you issue the CATALOG STORAGE ACCESS command, remote storage
account credentials are stored in a keystore:
• If the Db2 instance is already configured to store master keys in a keystore for
Db2 native encryption, then the same keystore will be used to store the remote
storage account credentials.
• If the instance is not configured for Db2 native encryption, then you must create a
keystore for the remote storage account credentials before you can create
storage access aliases.

© Copyright IBM Corp. 1997, 2017 7-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Command syntax
>>-CATALOG STORAGE ACCESS--ALIAS--alias-name-------------------->

>--VENDOR--+-SOFTLAYER-+--SERVER--+-DEFAULT--+------------------>
'-S3--------' '-endpoint-'

>--USER--storage-user-ID--PASSWORD--storage-password------------>

>--+--------------------------------+--+----------------+------->
'-CONTAINER--container-or-bucket-' '-OBJECT--object-'

>--+-----------------------+-----------------------------------><
'-+-DBGROUP--group-ID-+-'
'-DBUSER--user-ID---'

© Copyright IBM Corp. 1997, 2017 7-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Using a defined remote storage alias for a database backup

• Example using the alias called "montrealprivate" to back up the
database called "testdb"

db2 backup db testdb to

DB2REMOTE://montrealprivate/bkupDIR11/1453245697

Db2 Database

Db2 Engine

Db2
Backup
image

Backup and recovery © Copyright IBM Corporation 2017

Using a defined remote storage alias for a database backup

The slide shows how the remote storage alias, montrealprivate, defined in the previous
slide, could be used as the storage for a Db2 BACKUP command to store the backup
image.

© Copyright IBM Corp. 1997, 2017 7-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Roll forward pending state

• Roll forward pending is set as a result of:
 Restore of offline database backup omitting the command option
WITHOUT ROLLING FORWARD
 Restore of an online database backup
 Restore of any table space level backup
 Db2 detects media failure isolated at a table space
• Scope of pending state managed by Db2:
 Database in pending state will not permit any activity
 Table spaces in pending state will permit access to other table spaces

Backup and recovery © Copyright IBM Corporation 2017

Roll forward pending state

Roll forward pending is a state used by Db2 to protect the integrity of the database. This
state indicates that a roll-forward process is necessary to ensure consistency of the
data.
Roll forward pending can occur either at the database or at the table space level.
If the database is in a roll-forward pending state, no activity to the database is allowed.
If a table space is in a roll forward pending state, only that table space is unusable.
A database will be put into a roll-forward pending state when:
• Restoring an OFFLINE DATABASE backup and omitting the option WITHOUT
ROLLING FORWARD. This applies only to a database using archive logging.
• Restoring an ONLINE DATABASE backup.
A table space will be put into a roll forward pending state when a table space is
restored.
Under some conditions Db2 may detects a media failure and isolates it at the table
space level.

© Copyright IBM Corp. 1997, 2017 7-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Syntax of the ROLLFORWARD command

>>-ROLLFORWARD--+-DATABASE-+--database-alias-------------------->
'-DB-------'

>--+-------------------------------------------------------------------------------------+-->
| .-ON ALL DBPARTITIONNUMS-. .-USING UTC TIME---. |
+-TO--+-isotime--+------------------------+--+------------------+-+--+--------------+-+
| | '-USING LOCAL TIME-' | +-AND COMPLETE-+ |
| | .-ON ALL DBPARTITIONNUMS-. | '-AND STOP-----' |
| +-END OF BACKUP--+------------------------+-----------------+ |
| '-END OF LOGS--+----------------------------------+---------' |
| '-| On Database Partition clause |-' |
'-+-COMPLETE---------------------------+--+----------------------------------+--------'
+-STOP-------------------------------+ '-| On Database Partition clause |-'
+-CANCEL-----------------------------+
| .-USING UTC TIME---. |
'-QUERY STATUS--+------------------+-'
'-USING LOCAL TIME-'

>--+-------------------------------------------------------+---->
'-TABLESPACE--+-ONLINE--------------------------------+-'
| .-,---------------. |
| V | |
'-(----tablespace-name-+--)--+--------+-'
'-ONLINE-'

>--+------------------------------------------------------------------------+-->
'-OVERFLOW LOG PATH--(--log-directory--+----------------------------+--)-'
'-,--| Log Overflow clause |-'

>--+------------+----------------------------------------------->
'-NORETRIEVE-'

Backup and recovery © Copyright IBM Corporation 2017

Syntax of the ROLLFORWARD command

Authorization for this command requires SYSADM, SYSCTRL, or SYSMAINT.
ROLLFORWARD applies transactions recorded in the database log files.
The command needs to be invoked after a database or a table space backup has been
restored, or if any table spaces have been taken offline by the database due to a media
error.
Restore is the first phase of a complete roll forward recovery of a database or table
space.
After a successful database restore, a database that was configured for roll forward
recovery at the time the backup was taken enters a roll forward pending state, and is
not usable until the ROLLFORWARD command has been run successfully. If the
restore was for a table space, the table spaces restored are placed in a roll forward
pending state.
When the ROLLFORWARD DATABASE command is issued, if the database is in a
roll forward pending state, the database is rolled forward. If the database is not in a
roll forward pending state, all table spaces in the database in the roll forward pending
state are processed.
Another database RESTORE is not allowed when the roll forward process is running.

© Copyright IBM Corp. 1997, 2017 7-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Note: If you restored from a full OFFLINE database backup image, you can bypass the
roll-forward pending state during the recovery process. The RESTORE
DATABASE command gives you the option to use the restored database
immediately WITHOUT ROLLING FORWARD the database.
You CANNOT bypass the roll-forward phase when recovering at the table space level
or if you restore from a backup image that was created using the ONLINE option of the
BACKUP DATABASE command.

© Copyright IBM Corp. 1997, 2017 7-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

ROLLFORWARD: How far?

• END OF LOGS: (Apply as many changes as possible):
 Rollforward will apply all available logs beginning with the logs associated
with the backup that was restored
 Archived logs will be retrieved unless NORETRIEVE is specified
• Point-in-time (PIT): (Apply changes up to a specified time):
 Specified in Coordinated Universal Time (UTC) via command
 Specified in local time on server with USING LOCAL TIME
 Specified in local time on the client via GUI interface
 Format: [Link]
• END OF BACKUP: (Apply as few changes as possible):
 Allows a Database to be recovered from an online database backup and to
end the ROLLFORWARD processing at the earliest point where the
database is consistent.
 Recovery history file (RHF) shows logs associated with online backups

Backup and recovery © Copyright IBM Corporation 2017

ROLLFORWARD: How far?

The database administrator can clear a ROLLFORWARD PENDING condition by
issuing the ROLLFORWARD command. The point in time to which the roll forward
stage proceeds is also controllable by the administrator. An administrator can roll
forward to end of logs or to a specific point in time. Use the Coordinated Universal Time
(UTC) or local time on the server when roll forward is specified in a command.
The integrity of the database must be protected, therefore the earliest point in time at
which the roll forward stage can end is the end of the online backup image.
Table space point-in-time recovery must protect the integrity of the relationships that
exist between tables in the table spaces. These relationships include referentially
constrained tables and single tables that have objects contained in multiple table
spaces. A minimum roll forward time is kept at the table space level and can be
displayed with the LIST TABLESPACES command. A backup is required following a
point-in-time recovery of a table space.
The parameter isotime can be coded on the ROLLFORWARD command to identify a
particular point-in-time up to which the logs should be applied. This time is specified as
the ISO format of the coordinated universal time (UTC) or local time of the server.

© Copyright IBM Corp. 1997, 2017 7-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

The Coordinated Universal Time is used in log records so that the database manager
does not have a recovery dependency regarding daylight savings time or other local
time anomalies. However, this introduces a degree of complexity for the database
administrator. While backup images are identified via timestamps reflecting local time,
rolling forward (since it applies to logs) designates times in UTC format. If specifying
USING LOCAL TIME, care must be taken to indicate the time correctly, particularly if
Daylight Savings Time changes are close to the time of the roll forward.
In many cases, recovery will be desired to the most current point possible. Therefore,
the END OF LOGS option will be commonly used.
The TO END OF BACKUP option can be used with the RESTORE command.
The administrator can STOP / COMPLETE the roll forward process and allow access to
the database.
AND STOP / AND COMPLETE is a necessary parameter to permit the database
manager to roll back any transactions that are not complete after applying the log
records to the indicated point. This is true even if END OF LOGS is utilized. Otherwise,
the database will remain in ROLLFORWARD PENDING status.

© Copyright IBM Corp. 1997, 2017 7-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

ROLLFORWARD: Tablespace
• Table space point-in-time considerations:
 Minimum roll forward time maintained for each table space – requires roll
forward at least to the last DDL change (create, alter, drop) in a table space
 Table spaces are placed in backup pending when the roll forward completes
to insure future recoverability
 If you are rolling table spaces forward to a point in time, and a table is
contained in multiple table spaces, all of these table spaces must be rolled
forward simultaneously
 If you want to roll forward a table space to a point in time, and a table in the
table space participates in a referential integrity relationship with another
table that is contained in another table space, roll forward both table spaces
simultaneously to the same point in time.
− If you do not roll forward both table spaces, the child table in the referential
integrity relationship is placed in set integrity pending state at the end of the
rollforward operation.

Backup and recovery © Copyright IBM Corporation 2017

ROLLFORWARD: Tablespace
After a table space is restored, it is always in rollforward pending state. To make the
table space usable, you must perform rollforward recovery on it. In most cases, you
have the option of rolling forward to the end of the logs, or rolling forward to a point in
time. You cannot, however, roll table spaces containing system catalog tables forward
to a point in time. These table spaces must be rolled forward to the end of the logs to
ensure that all table spaces in the database remain consistent.
If you are rolling table spaces forward to a point in time, and a table is contained in
multiple table spaces, all of these table spaces must be rolled forward simultaneously.
If, for example, the table data is contained in one table space, and the index for the
table is contained in another table space, you must roll both table spaces forward
simultaneously to the same point in time.
If the data and the long objects in a table are in separate table spaces, and the long
object data was reorganized, the table spaces for both the data and the long objects
must be restored and rolled forward together. Take a backup of the affected table
spaces after the table is reorganized.

© Copyright IBM Corp. 1997, 2017 7-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

If you want to roll forward a table space to a point in time, and a table in the table space
is either:
• an underlying table for a materialized query or staging table that is in another
table space
• a materialized query or staging table for a table in another table space
then roll both table spaces forward to the same point in time. If you do not, the
materialized query or staging table is placed in set integrity pending state at the end of
the rollforward operation. The materialized query table needs to be fully refreshed, and
the staging table is marked as incomplete.
If you want to roll forward a table space to a point in time, and a table in the table space
participates in a referential integrity relationship with another table that is contained in
another table space, roll forward both table spaces simultaneously to the same point in
time. If you do not roll forward both table spaces, the child table in the referential
integrity relationship is placed in set integrity pending state at the end of the rollforward
operation. When the child table is later checked for constraint violations, a check on the
entire table is required. If any of the following tables exist, they are also placed in set
integrity pending state with the child table:
• any descendant materialized query tables for the child table
• any descendant staging tables for the child table
• any descendant foreign key tables of the child table

© Copyright IBM Corp. 1997, 2017 7-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 RECOVER command

• db2 recover database salesdb
 RECOVER command performs both RESTORE and
ROLLFORWARD command processing using
Recovery History file data.
 Can use Full or Incremental Database level backup
images
 Allows Partitioned DPF database to be recovered
using a single command Recovery History

 Database can be recovered to End of logs or a Archived Logs

point in time.
 RESTART option forces failed RECOVER command Backups
to redo RESTORE even if previous restore
completed
 USING HISTORY FILE option allows disaster
recovery with no existing database
 No table space level recovery options
Backup and recovery © Copyright IBM Corporation 2017

Db2 RECOVER command

The RECOVER DB command uses the information in the history file to determine the
backup image to use for the required point in time. The user does not need to specify a
particular backup image. If the required backup image is an incremental backup,
RECOVER will invoke incremental automatic logic to perform the restore. If table
spaces are put into restore pending state during the db rollforward, these table spaces
need to be resolved through additional restore and rollforward commands.
If a PIT is requested, but the earliest backup image in the history file is later than the
request PIT, the RECOVER command will return an error. Otherwise, the backup
image in the history file with the latest backup time prior to the requested PIT is used to
restore the database.
If END OF LOGS is requested, the most recent database backup image in the history
file is used.
The RECOVER command only performs database level recovery, no table space
recovery options are included. Some options of the RESTORE, ROLLFORWARD are
not provided by RECOVER. For example the REDIRECT option of RESTORE is not
included, so the database needs to be recovered using the same containers defined in
the backup image.

© Copyright IBM Corp. 1997, 2017 7-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

The default will be used for these options unless otherwise stated below.
• Single Partition: If a point in time is specified, the PIT info must exist in the
history file.
• Multi-Partitions: If a point in time is specified, all nodes must have info for the
required PIT. If not, there will be no recover operation performed on any node.
Multi-Partitions: RECOVER must be issued from the catalog node. Any prompting
from either the RESTORE or ROLLFORWARD phase will be returned to the catalog
node, and prompt must be answered here. The existing RESTORE/ROLLFORWARD
prompts ('c'/'d'/'t') will be used (see below).
Note: WITHOUT PROMPTING is the default for the RESTORE phase when using
RECOVER.
USING LOCAL TIME is the default for the ROLLFORWARD phase. This is different
than ROLLFORWARD, but is chosen as the default since this is more natural usage
from a customer point of view. The user will have to specify USING UTC TIME to have
the same behavior as ROLLFORWARD.
If the RECOVER completes with no errors, the rollforward STOP/COMPLETE logic will
be performed. If rollforward is started but does not reach the desired end of log/PIT,
then STOP/COMPLETE processing will not be performed.
If the backup image selected for use is an incremental backup, Db2 will invoke
automatic incremental code to perform the database restore. If there is an error
completing the INCREMENTAL AUTO restore, Db2 will perform an internal
"incremental abort" to end the restore operation.

© Copyright IBM Corp. 1997, 2017 7-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

High Availability Disaster Recovery: HADR

Clients

Network

Standby Db2
Primary Db2 Database Server
Database Server
Direct Database to
Database TCPIP Link

Standby Copy of
Primary Copy of Db2 Database
Db2 Database

Backup and recovery © Copyright IBM Corporation 2017

High Availability Disaster Recovery: HADR

The Db2 Data Server High Availability Disaster Recovery (HADR) feature is a database
replication feature that provides a high availability solution for both partial and complete
site failures. HADR protects against data loss by replicating data changes from a
source database, called the Primary, to a target database, called the Standby.
HADR might be your best option if most or all of your database requires protection, or if
you perform DDL operations that must be automatically replicated on the standby
database.
Applications can only access the current primary database. Updates to the standby
database occur by rolling forward log data that is generated on the primary database
and shipped to the standby database.
• A partial site failure can be caused by a hardware, network, or software (Db2
database system or operating system) failure.
• Without HADR, a partial site failure requires restarting the database
management system (DBMS) server that contains the database.
• The length of time it takes to restart the database and the server where it
resides is unpredictable. It can take several minutes before the database is
brought back to a consistent state and made available.

© Copyright IBM Corp. 1997, 2017 7-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• With HADR, the standby database can take over in seconds. Further, you can
redirect the clients that were using the original primary database to the
standby database (new primary database) by using automatic client reroute or
retry logic in the application.
• A complete site failure can occur when a disaster, such as a fire, causes the
entire site to be destroyed. Because HADR uses TCP/IP for communication
between the primary and standby databases, they can be situated in different
locations.
• For example, your primary database might be located at your head office in
one city, while your standby database is located at your sales office in another
city.
• If a disaster occurs at the primary site, data availability is maintained by having
the remote standby database take over as the primary database with full Db2
functionality.
• After a takeover operation occurs, you can bring the original primary database
back up and return it to its primary database status; this is known as failback.
With HADR, you can choose the level of protection you want from potential loss of data
by specifying one of three synchronization modes: synchronous, near synchronous, or
asynchronous.

© Copyright IBM Corp. 1997, 2017 7-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Support for multiple active standby databases (1 of 2)

Principal Standby

Primary Super async mode Auxiliary Standby

Auxiliary Standby

• HADR feature in multiple standby mode allows up to three standby

databases to be configured
• One Standby is designated the principal HADR standby database
• Any additional standby database is an auxiliary HADR standby
database

Backup and recovery © Copyright IBM Corporation 2017

Support for multiple active standby databases

Starting with Db2 10.1, the HADR function supports multiple standby databases.
In an HADR with multiple standbys environment, all of the standby databases are
directly connected to the primary. The databases are not daisy chained/cascading from
each other.
Each of the standbys in a multiple standby environment supports the Reads on
Standby feature.
A takeover (whether it be forced or non-forced) is supported from any standby. In other
words, any of the standbys can become the primary through a takeover. After the
takeover occurs, the database configuration parameters on the other standbys
(HADR_REMOTE_HOST, HADR_REMOTE_SVC, and HADR_REMOTE_INST) will
be automatically updated to point to the new primary.

© Copyright IBM Corp. 1997, 2017 7-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Support for multiple active standby databases (2 of 2)

• Both types of HADR standbys:
 Are synchronized with the HADR primary database through a direct TCP/IP
connection
 Support reads on standby
 Can issue a forced or non-forced takeover

• Other HADR enhancements

 Log spooling on the Standby database
 Delayed replay for a Standby database

Backup and recovery © Copyright IBM Corporation 2017

Several other HADR enhancements were made available with Db2 10.1. These can be
used in either single or multiple standby modes.
HADR log spooling
The high availability disaster recovery (HADR) log spooling feature allows transactions
on primary to make progress without having to wait for the log replay on the standby.
When this feature is enabled, log data sent by the primary is spooled, or written, to disk
on the standby, and that log data is later read by log replay.
Log spooling, which is enabled by setting the hadr_spool_limit database configuration
parameter, is an improvement to the HADR feature. When replay is slow, it is possible
that new transactions on the primary can be blocked because it is not able to send log
data to the standby system if there is no room in the buffer to receive the data. The log
spooling feature means that the standby is not limited by the size of its buffer. When
there is an increase in data received that cannot be contained in the buffer, the log
replay reads the data from disk. This allows the system to better tolerate either a spike
in transaction volume on the primary, or a slowdown of log replay (due to the replay of
particular type of log records) on the standby.

© Copyright IBM Corp. 1997, 2017 7-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

This feature could potentially lead to a larger gap between the log position on the
primary and the log replay on standby, which can lead to longer takeover time. You
should consider your spool limit setting carefully because the standby cannot start up
as the new primary and receive transactions until the replay of the spooled logs has
finished.
HADR delayed replay
HADR delayed replay helps prevent data loss due to errant transactions. To implement
HADR delayed replay, set the hadr_replay_delay database configuration parameter on
the HADR standby database.
Delayed replay intentionally keeps the standby database at a point in time that is earlier
than that of the primary database by delaying replay of logs on that standby. If an errant
transaction is executed on the primary, you have until the configured time delay has
elapsed to take action to prevent the errant transaction from being replayed on the
standby. To recover the lost data, you can either copy this data back to the primary, or
you can have the standby take over as the new primary database.
Delayed replay works by comparing timestamps in the log stream, which is generated
on the primary, and the current time of the standby. As a result, it is important to
synchronize the clocks of the primary and standby databases. Transaction commit is
replayed on the standby according to the following equation:
(current time on the standby - value of the hadr_replay_delay configuration parameter)
>= timestamp of the committed log record
You should set the hadr_replay_delay database configuration parameter to a large
enough value to allow time to detect and react to errant transactions on the primary.
You can use this feature in either single standby mode or multiple standby mode. In
multiple standby mode, typically one or more standbys stays current with the primary for
high availability or disaster recovery purposes, and one standby is configured with
delayed replay for protection against errant transactions. If you use this feature in single
standby mode, you should not enable IBM Tivoli System Automation for Multi-platforms
because the takeover will fail.

© Copyright IBM Corp. 1997, 2017 7-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 pureScale feature architecture

Automatic workload balancing

Cluster of Db2 nodes running

on Power or Intel servers

Cluster Caching
Facilities
Leverages the global lock and
memory manager technology
from z/OS

Database Members Integrated Cluster

Manager

InfiniBand or Ethernet & Db2

Cluster Services

Shared Data

Backup and recovery © Copyright IBM Corporation 2017

Db2 pureScale feature architecture

Based on industry leading System z data sharing architecture, Db2 pureScale
integrates IBM technologies to keep your critical systems available all the time.
It includes:
• Automatic workload balancing to ensure that no node in the system is over
loaded. Db2 will actually route transactions or connections to the least heavily
used server.
• Db2 pureScale is built on both Power and Intel servers
• The technology for globally sharing locks and memory is based on technology
from z/OS.
• Tivoli System Automation has been integrated deeply into Db2 pureScale. It is
installed and configured as part of the Db2 installation process and is
automatically configured to handle various hardware and software failures.
• The networking infrastructure leverages high speed Infiniband or Ethernet
connections and all additional clustering software is included as part of Db2
pureScale installation.
• The core of a Db2 pureScale system is a shared disk architecture based on IBM
GPFS.

© Copyright IBM Corp. 1997, 2017 7-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 additional recovery facilities (1 of 2)

• On-demand log archiving
 ARCHIVE LOG command
• Infinite active logs
 Setting LOGSECOND to -1
• Block transactions on log directory full
 Setting BLK_LOG_DSK_FUL
• Split mirror database copies:
 SET WRITE SUSPEND/RESUME commands
 db2inidb command modes:
− SNAPSHOT: Database copy for testing reporting
− STANDBY: Database copy to create standby database for quick recovery
− MIRROR: Use split mirror database copy instead of RESTORE

Backup and recovery © Copyright IBM Corporation 2017

Db2 additional recovery facilities

Some other database recovery facilities include:
• On-demand log archiving - the ARCHIVE LOG command
• Infinite active logs - setting LOGSECOND to -1 to allow unlimited secondary logs
• Block transactions on log directory full - the blk_log_dsk_ful database
configuration option.
• Split mirror database copies>:
• SET WRITE SUSPEND/RESUME commands
• db2inidb command modes:
• SNAPSHOT: Database copy for testing reporting
• STANDBY: Database copy to create standby database for quick recovery
• MIRROR: Use split mirror database copy instead of RESTORE

© Copyright IBM Corp. 1997, 2017 7-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Db2 additional recovery facilities (2 of 2)

• Incremental and delta database and table space backups
• Relocating a database or a table space:
 RESTORE UTILITY with REDIRECT option
 db2relocatedb command
• Full and partial database REBUILD support
 REBUILD option of RESTORE supports building a database using a set of
tablespace level backups
• Integrated Cluster Failover support using TSA
• The SNAPSHOT option of BACKUP and RESTORE can utilize fast
copying technologies of storage devices rather than standard disk
reads or writes

Backup and recovery © Copyright IBM Corporation 2017

Some additional Db2 LUW database backup and recovery facilities that may be used
with Db2 databases are:
• Incremental and delta database and table space backups
• Relocating a database or a table space
• RESTORE UTILITY with REDIRECT option
• db2relocatedb command
• Full and partial database REBUILD support
• Integrated Cluster Failover support - simple configuration of Db2 databases for a
highly available cluster using the IBM TSA for multi-platforms product.
• Using the SNAPSHOT option of BACKUP and RESTORE uses the fast copying
technology of a storage device to perform the data copying portion of the backup.

© Copyright IBM Corp. 1997, 2017 7-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Demonstration 1
Backup and recovery
• Create a backup image of a database including all of the table spaces.
• Configure a database to change from circular logging to enable archive
logging to make the database fully recoverable.
• Restore a database from a backup image and Roll forward a database
to perform point in time recovery using the RECOVER command.

Backup and recovery © Copyright IBM Corporation 2017

Demonstration 1: Backup and recovery

© Copyright IBM Corp. 1997, 2017 7-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Demonstration 1:
Backup and recovery
Purpose:
This demonstration utilizes the database MUSICDB to perform backup and
recovery related tasks. During this demonstration, you will prepare the
database for archival logging, create a backup image and recover the
database to a selected point in time. You will also configure the database log
space to handle applications with large transactions.

Task 1. Configure the available log space for a database.

1. Logon to the Linux system using the user id inst23, with a password of
ibm2blue.
You will use the Linux Terminal session to enter Db2 commands.
2. Right-click the empty Linux desktop, and then select Open in Terminal.
A set of course files are located in the directory $HOME/ddl. Change to this
directory to make it easier to access these files that contain Db2 commands or
SQL statements.
You will start by configuring the database with a small database log space to
test the effect on processing application requests that exceed the database log
space limits.
This task will be performed using the Db2 command line processor.
3. Enter the following commands using the Linux terminal session:
• cd $HOME/ddl
• db2 connect to musicdb
• db2 update db cfg using logprimary 3 logsecond 1 logfilsiz 6
The SQL1363W message indicates that at least one of the configuration
changes requires a database restart to take effect. In this case, LOGFILSIZ and
LOGPRIMARY cannot be changed dynamically.
The db2pd command can be used to show the current and any deferred
database configuration settings.

© Copyright IBM Corp. 1997, 2017 7-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

4. Enter the following commands using the Linux terminal session:

• db2pd -db musicdb -dbcfg | grep LOG
The command output will look similar to the following:
CATALOGCACHE_SZ (4KB) 300 300
LOGBUFSZ (4KB) 2149 2149
LOGFILSIZ (4KB) 1024 6
LOGPRIMARY 5 3
LOGSECOND 1 1
NEWLOGPATH (memory)
NEWLOGPATH (disk)
Path to log files (memory) /database/inst23/NODE0000/SQL00001/LOGSTREAM0000/
OVERFLOWLOGPATH (memory)
OVERFLOWLOGPATH (disk)
MIRRORLOGPATH (memory)
MIRRORLOGPATH (disk)
First active log file [Link] [Link]
BLK_LOG_DSK_FUL NO NO
BLOCKNONLOGGED NO NO
MAX_LOG 0 0
NUM_LOG_SPAN 0 0
LOGARCHMETH1 (memory) OFF
LOGARCHMETH1 (disk) OFF
LOGARCHCOMPR1 OFF OFF
LOGARCHOPT1
LOGARCHMETH2 (memory) OFF
LOGARCHMETH2 (disk) OFF
LOGARCHCOMPR2 OFF OFF
LOGARCHOPT2
LOGINDEXBUILD 0 0
LOG_DDL_STMTS NO NO
LOG_APPL_INFO NO NO

Now you will connect to the MUSICDB database and run two SQL command
files using the Db2 command line processor.
For the change processing, you will include the +C option to process the
statements as a single unit of work or transaction.
The Db2 command line processor will automatically commit each statement
processed by default. The +C option turns autocommit off, so that all of the
changes made by multiple statements must be retained in the Db2 active log
files to support rolling back the changes, if necessary.

© Copyright IBM Corp. 1997, 2017 7-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

5. Enter the following commands using the Linux terminal session:

• db2 force application all
• db2 terminate
• db2 connect to musicdb
• db2pd -db musicdb -logs
The command output will look similar to the following:
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date
2016-08-01-11.17.53.895624

Logs:
Current Log Number 0
Pages Written 0
Cur Commit Disk Log Reads 0
Cur Commit Total Log Reads 0
Method 1 Archive Status n/a
Method 1 Next Log to Archive n/a
Method 1 First Failure n/a
Method 2 Archive Status n/a
Method 2 Next Log to Archive n/a
Method 2 First Failure n/a
Log Chain ID 0
Current LSO 203441313
Current LSN 0x0000000000061370

Address StartLSN StartLSO State Size

Pages Filename
0x00007F51362748D0 0000000000000000 203441313 0x00000000 6 6
[Link]
0x00007F5136275B90 0000000000000000 203465769 0x00000000 6 6
[Link]
0x00007F5136275230 0000000000000000 203490225 0x00000000 6 6
[Link]

© Copyright IBM Corp. 1997, 2017 7-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

• db2 -tvf create_temp_stock.sql

• db2 +C -tvf stock_insert.sql
• db2 commit
• db2 terminate
The command output will look similar to the following:
set current schema music
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0964C The transaction log for the database is full. SQLSTATE=57011

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0964C The transaction log for the database is full. SQLSTATE=57011

delete from temp_stock

DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0964C The transaction log for the database is full. SQLSTATE=57011

Once your limited database log space is filled, the database changes fail with
the SQL0964 message indicating that “The transaction log for the database is
full”.
Use the Db2 command file increase_logs.ddl to allocate sufficient database
log space to process the database changes.

© Copyright IBM Corp. 1997, 2017 7-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

6. Enter the following commands using the Linux terminal session

• db2 connect to musicdb
• db2 -tvf increase_logs.ddl
• db2 terminate
Now will retry the command file containing the table changes.
You will include the +C option to process the statements as a single unit of work
or transaction.
7. Enter the following commands using the Linux terminal session:
• db2 connect to musicdb
• db2 +C -tvf stock_insert.sql
• db2 commit
• db2 terminate
The command output will look similar to the following:
set current schema music
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where itemno < 100
DB20000I The SQL command completed successfully.

delete from temp_stock

DB20000I The SQL command completed successfully.
The increased database log space allows the statements to process without
errors.

© Copyright IBM Corp. 1997, 2017 7-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Task 2. Database Recovery Support with Archive Logging.

In this section, you will implement archive logging. This will allow the database to be
more completely recovered, including the logged changes.
By default, your database MUSICDB is using circular logging which only supports
database level recovery to a previous backup copy. You will perform several sets of
database changes, and then perform a point-in-time database recovery to include some
of the changes. This could be used to handle application failures that cause tables to
contain incorrect data.
Switching from circular logging to archive logging requires an offline database backup in
order to establish the starting point where all new logged changes will be kept.
The disk location $HOME/archive will be used as the location to archive logs.
The disk location $HOME/backups will be used to store the database backup file.
1. Enter the following commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 UPDATE DATABASE CONFIGURATION USING logarchmeth1
"DISK:$HOME/archive" logprimary 3 logsecond 10 logfilsiz 1000
• db2 connect reset
• db2 force application all
• db2 terminate
• db2 deactivate database musicdb
• db2 BACKUP DATABASE MUSICDB TO $HOME/backups encrypt
Task 3. Generate multiple sets of table changes noting the
point in time for each change.
In this section you will perform several sets of changes, noting the current time when
each set completes. These changes are now being archived by Db2 automatically.
A script file named stock_insert2.sql contains two SQL statements.
• The INSERT statement adds a set of rows from the [Link] table to the
MUSIC.TEMP_STOCK table.
• A SELECT statement returns the current row count for the TEMP_STOCK table
and the current local date and time information.

© Copyright IBM Corp. 1997, 2017 7-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

At this point you may choose to use the Db2 command line processor or the Data
Server Manager tool, to execute the SQL script file that makes the changes to the table
TEMP_STOCK.
3A. Use the Db2 command line processor.
1. Enter the following commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf stock_insert2.sql
2. Record the following from the SQL result:
• Current Table size: ____________ (result 1)
• Local date: _____________ (result 1)
• Local time: _____________ (result 1)
The command output will look similar to the following:
set current schema music
DB20000I The SQL command completed successfully.

insert into temp_stock select itemno,type,price,qty from stock where TYPE = 'C'
DB20000I The SQL command completed successfully.

SELECT COUNT(*) AS CURRENT_SIZE, CURRENT DATE , CURRENT TIME FROM temp_stock

CURRENT_SIZE 2 3
------------ ---------- --------
259 09/16/2015 [Link]

1 record(s) selected.

3. Run the command file a second time to make additional logged changes and
note the results.
• db2 -tvf stock_insert2.sql
4. Record the following from the SQL result:
• Current Table size: ____________ (result 2)
• Local date: _____________ (result 2)
• Local time: _____________ (result 2)
5. You can now skip to Task 4.

© Copyright IBM Corp. 1997, 2017 7-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

3B. Use the Data Server Manager tool.

You will use the Data Server Manager tool to run the SQL scripts that perform the
database changes.
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Clear any SQL statements from the editor that may remain from previous steps.
3. Click Script > Open from Client. Use the Browse button for the SQL Script
window to locate and select the file inst23/ddl/stock_insert2.sql.
4. Click Open.
5. Click OK to complete loading of the SQL text into the SQL editor.
Review the SQL statements.
6. Click Run > Run All and then wait for the SQL statements to be processed.
7. Click on Result Set under VIEW RESULTS to review resulted returned by
the SELECT statement. Record the following from the SQL result:
• Current Table size: ____________ (result 1)
• Local date: _____________ (result 1)
• Local time: _____________ (result 1)
Now run the INSERT script a second time to generate a second set of logged
changes.
8. Click Run > Run All and then wait for the SQL statements to be processed.
9. Click on Result Set under VIEW RESULTS to review resulted returned by
the SELECT statement. Record the following from the SQL result:
• Current Table size: ____________ (result 2)
• Local date: _____________ (result 2)
• Local time: _____________ (result 2)
10. Log out from DSM now.

© Copyright IBM Corp. 1997, 2017 7-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Task 4. Recover the database to a specific point in time.

Now you will use the RECOVER database command to restore the MUSICDB
database to the point in time of the first execution of the insert SQL script. The
RECOVER DATABASE command will locate the required backup image using the
database recovery history file. A RESTORE DATABASE command would require the
backup location to be specified.
The recovery target time value is specified as a time stamp, a 7-part character string
that identifies a combined date and time.
The format is [Link] (year, month, day, hour, minutes,
seconds, microseconds).
db2 recover database musicdb to [Link]
(Use the Date and time recorded in Task 3 for the first execution).
1. Enter the following commands using the Linux terminal session.
• db2 terminate
• db2 force application all
Wait about 1 minute before trying to perform the 'recover' command - giving
time for the database to shut down.
• db2 recover database musicdb to [Link]
Use the Date and time recorded for the first execution of stock_insert2.sql
(Results 1).
The command output will look similar to the following:
Rollforward Status

Input database alias = musicdb

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-08-01-11.44.53.000000 Local

DB20000I The RECOVER DATABASE command completed successfully.

Now connect to the database and check the count of rows in the
MUSIC.TEMP_STOCK table. The count should match the number of rows
recorded for the first execution of the SQL insert script.

© Copyright IBM Corp. 1997, 2017 7-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

2. Issue the following series of commands using the Db2 command line processor.
• db2 connect to musicdb
• db2 “select count(*) from music.temp_stock“
• db2 terminate

Results:
You utilized the database MUSICDB to perform backup and recovery related
tasks, including configuring the database for archival logging, creating a
backup image and recovered the database to a selected point in time. You
also configured the database log space to handle applications with large
transactions.

© Copyright IBM Corp. 1997, 2017 7-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 7 Backup and recovery

Unit summary
• Describe the major principles and methods for backup and recovery
• State the three types of recovery used by Db2
• Explain the importance of logging for backup and recovery
• Describe how data logging takes place, including circular logging and
archival logging
• Use the BACKUP, RESTORE, ROLLFORWARD and RECOVER
commands
• Perform a table space backup and recovery
• Restore a database to the end of logs or to a point-in-time
• Discuss the configuration parameters and the recovery history file and
use these to handle various backup and recovery scenarios
• Create an encrypted backup image to improve data security

Backup and recovery © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 7-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Database maintenance, monitoring and problem determination

Database maintenance,
monitoring and problem
determination

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

© Copyright IBM Corp. 1997, 2017 8-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Unit objectives
• Plan the use of RUNSTATS, REORGCHK and REORG utilities for
maintaining database efficiency
• Configure the Db2 instance to set the location for diagnostic data and
message severity levels for basic problem analysis
• Describe the methods that can be used for monitoring database and
application activity including db2pd commands, Event Monitors and
using SQL statements to access statistics
• Describe the function of EXPLAIN and use this facility to assist basic
analysis
• Use the db2advis command to analyze a workload for potential
performance improvements
• Use the db2fodc command to collect diagnostic data for a system hang

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 8-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Database maintenance activities

• Collecting table and index statistics
 The RUNSTATS command collects statistics for tables and indexes that are
used to build efficient access plans
 New statistics can be manually collected when tables are loaded with new
data or application update and delete rows.
 The database can be configured to automatically collect new statistics
based on rates of changes and access
• Tables and indexes can be reorganized
 The REORG command can be used to reorganize table and indexes either
online or offline
 Reorganization may be used to improve the storage efficiency and reduce
access costs
 The REORGCHK command can be used to suggest tables and indexes that
would benefit from reorganization
 REORG can be used to implement compression for tables and indexes
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Database maintenance activities

Accurate table and index statistics are very important input to the Db2 optimizer that
selects efficient access plans for processing application requests. The RUNSTATS
command can be used to collect new table and index statistics. If a table is growing in
size or a new index is added, it is important to update the statistics to reflect these
changes. A Db2 database can be configured to automatically select table and indexes
that need new statistics.
The REORG utility can be used to reorganize tables and indexes to improve the
efficiency of the storage and also to reduce access costs. For example, if many rows
are deleted from a table, a large number of pages in the table may contain a few or no
data rows. The REORG utility can rebuild the table to utilize fewer pages, which saves
disk space and allows the table to be scanned with fewer I/O operations. The
REORGCHK command can be used to check a series of indicators and recommend
which tables or indexes would benefit from reorganization. The REORG utility can be
used to implement compression for existing tables and indexes and also to rebuild the
compression dictionary to reflect the current table data contents.

© Copyright IBM Corp. 1997, 2017 8-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

RUNSTATS command examples

• Collect basic statistics on the table and all indexes using sampling for
the detailed index statistics collection:
RUNSTATS ON TABLE employee AND SAMPLED DETAILED INDEXES ALL

• Collect table statistics on 1.5 percent of the data pages and index
statistics on 2.5 percent of the index pages. Both table data pages and
index pages are sampled:
RUNSTATS ON TABLE employee AND INDEXES ALL TABLESAMPLE SYSTEM(1.5)
INDEXSAMPLE SYSTEM(2.5)

• Collect statistics on table, with distribution statistics on columns empid,

empname and empdept and the two indexes Xempid and Xempname.
Distribution statistics limits are set individually for empdept, while the
other two columns use a common default:
RUNSTATS ON TABLE employee WITH DISTRIBUTION ON COLUMNS (empid,
empname, empdept NUM_FREQVALUES 50 NUM_QUANTILES 100) DEFAULT
NUM_FREQVALUES NUM_QUANTILES 10 AND INDEXES Xempid, Xempname

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

RUNSTATS command examples

The runstats utility collects the following information about tables and indexes:
• The number of pages that contain rows
• The number of pages that are in use
• The number of rows in the table (the cardinality)
• The number of rows that overflow
• For multidimensional clustering (MDC) and insert time clustering (ITC) tables, the
number of blocks that contain data
• For partitioned tables, the degree of data clustering within a single data partition
• Data distribution statistics, which are used by the optimizer to estimate efficient
access plans for tables and statistical views whose data is not evenly distributed
and whose columns have a significant number of duplicate values
• Detailed index statistics, which are used by the optimizer to determine how
efficient it is to access table data through an index
• Subelement statistics for LIKE predicates, especially those that search for
patterns within strings (for example, LIKE %disk%), are also used by the
optimizer

© Copyright IBM Corp. 1997, 2017 8-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The visual shows a few examples of RUNSTATS commands that can collect table and
index statistics.
To collect basic statistics on the table and all indexes using sampling for the detailed
index statistics collection:
RUNSTATS ON TABLE employee AND SAMPLED DETAILED INDEXES ALL
For large tables, you may decide to use sampling to collect statistics rather than
processing the full set of data. For example to collect table statistics on 1.5 percent of
the data pages and index statistics on 2.5 percent of the index pages, the following
RUNSTATS command could be used: ( Both table data pages and index pages are
sampled)
RUNSTATS ON TABLE employee AND INDEXES ALL TABLESAMPLE
SYSTEM(1.5)
INDEXSAMPLE SYSTEM(2.5)
In some cases, distribution statistics can be collected for tables that have non-uniform
distribution of data values. For example to collect statistics on table, with distribution
statistics on columns empid, empname and empdept and the two indexes Xempid and
Xempname. Distribution statistics limits are set individually for empdept, while the other
two columns use a common default:
RUNSTATS ON TABLE employee
WITH DISTRIBUTION ON COLUMNS (empid, empname, empdept
NUM_FREQVALUES
50 NUM_QUANTILES 100)
DEFAULT NUM_FREQVALUES 5 NUM_QUANTILES 10
AND INDEXES Xempid, Xempname

© Copyright IBM Corp. 1997, 2017 8-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using REORGCHK to find tables that would benefit from

reorganization
db2 reorgchk on schema auto

Table statistics:

F1: 100 * OVERFLOW / CARD < 5

F2: 100 * (Effective Space Utilization of Data Pages) > 70
F3: 100 * (Required Pages / Total Pages) > 80

SCHEMA NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG

------------------------------------------------------------------------------------
Table: AUTO.HIST1
AUTO HIST1 137619 0 4174 5427 - 9770949 0 44 76 -**
Table: AUTO.HIST2
AUTO HIST2 39612 0 1601 1602 - 2812452 0 43 99 -*-
Table: AUTO.HIST3
AUTO HIST3 136880 0 4918 4919 - 9718480 0 49 99 -*-
------------------------------------------------------------------------------------

* Indicates the potential for benefit

from reorganization

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using REORGCHK to find tables that would benefit from reorganization

The REORGCHK command returns statistical information about data organization and
can advise you about whether particular tables or indexes need to be reorganized.
The REORGCHK command can collect new statistics or use the current catalog
statistics to produce the report. The report can include one table, a schema of objects
or all tables.
REORGCHK calculates statistics obtained from eight different formulas to determine if
performance has deteriorated or can be improved by reorganizing a table or its indexes.
The visual shows the table statistics portion of a REORGCHK report for a schema with
three tables. Three formulas are calculated for each table, any table that exceeds the
recommended value is marked with ‘*’ to indicate some possible benefit from
reorganization.
In the sample report all three tables are below the target value for the F2 calculation
which indicates that the table has more pages than are needed to hold the current
number of data rows.

© Copyright IBM Corp. 1997, 2017 8-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using REORGCHK to find indexes that would benefit from

reorganization
Index statistics:

F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80

F5: 100 * (Space used on leaf pages / Space available on non-empty leaf pages) > MIN(50, (100 - PCTFREE))
F6: (100 - PCTFREE) * (Amount of space available in an index with one less level / Amount of space
required for all keys) < 100
F7: 100 * (Number of pseudo-deleted RIDs / Total number of RIDs) < 20
F8: 100 * (Number of pseudo-empty leaf pages / Total number of leaf pages) < 20

[Link] INDCARD LEAF ELEAF LVLS NDEL KEYS LEAF_RECSIZE NLEAF_RECSIZE

--------------------------------------------------------------------------------------------------
Table: RG.HIST1
Index: RG.HIST1IX1
137619 346 0 3 0 60728 4 4
Index: RG.HIST1IX2
137619 315 0 3 0 44671 4 4
Table: RG.HIST2
Index: RG.HIST2IX1
39612 337 0 3 0 25363 4 4
Table: RG.HIST3
Index: RG.HIST3IX1
136880 320 2 3 0 50 2 2

LEAF_PAGE_OVERHEAD NLEAF_PAGE_OVERHEAD F4 F5 F6 F7 F8 REORG

----------------------------------------------------------------
822 822 3 93 58 0 0 *----
822 822 3 93 64 0 0 *----
822 822 4 31 175 0 0 ***--
984 984 27 69 95 0 0 *----

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using REORGCHK to find indexes that would benefit from reorganization

The visual shows the index based portion of a sample REORGCHK report. It includes
statistics and calculations for each index of the selected tables. There are five
calculations performed for each index and any index that exceeds the recommended
limit for a formula is marked with a matching ‘*’.
All four indexes in the sample report have at least one indication that the index or table
may require reorganization. The F4 formula shows how well each index is clustered
based on the current sequence of the data rows. In order to improve this cluster ratio for
an index, the table data will need to be reorganized using this particular index selected
to recluster the table with the REORG utility. It is common when a table has several
indexes for one or more of the indexes to be flagged in the REORGCHK report as
unclustered, but as long as the index that has been selected to cluster the table is
efficiently clustered, no reorganization of the table is necessary.

© Copyright IBM Corp. 1997, 2017 8-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Reorg utility examples

• Reorganize a table and all indexes offline using a temporary table
space and rebuild the compression dictionary

reorg table rgcomp.history1 use tempspace1 resetdictionary

• Reorganize a table online
reorg table rg.hist2 index rg.hist2ix1 inplace allow write
access
• Reorganize the indexes for a table, online
reorg indexes all for table rg.hist2 allow write access

• Reorganize one partition of a range partitioned table

reorg table [Link] INDEX PARTTAB.HISTPIX2 on data
partition part0

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Reorg utility examples

Table reorganization
After many changes to table data, logically sequential data might reside on
nonsequential data pages, so that the database manager might need to perform
additional read operations to access data. Also, if many rows have been deleted,
additional read operations are also required. In this case, you might consider
reorganizing the table to match the index and to reclaim space.
You can also reorganize the system catalog tables.
Because reorganizing a table usually takes more time than updating statistics, you
could execute the RUNSTATS command to refresh the current statistics for your data,
and then rebind your applications. If refreshed statistics do not improve performance,
reorganization might help.

© Copyright IBM Corp. 1997, 2017 8-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The following factors can indicate a need for table reorganization:

• There has been a high volume of insert, update, and delete activity against tables
that are accessed by queries.
• There have been significant changes in the performance of queries that use an
index with a high cluster ratio.
• Executing the RUNSTATS command to refresh table statistics does not improve
performance.
• Output from the REORGCHK command indicates a need for table reorganization.
The REORG utility has many options. Tables can be reorganized online or offline. The
indexes for a table can also be reorganized to improve the efficiency of the index
objects.
The first example shown will reorganize the table rgcomp.history1offline, which will
rebuild all of the indexes defined for the table. The RESETDICTIONARY option is used
to force the REORG to create a new compression dictionary during its processing
rather than keeping the original dictionary. This would be done if the data in the table
has changed significantly and a new compression dictionary would produce better
compression results.
The second example reorganizes the table rg.hist2 using the index rg.hist2ix1 to
recluster the data. This is an online or inplace reorganization that allows applications to
read and write the table during REORG processing.
The third REORG utility example shows a reorganization for a range partitioned table
named [Link], where a single range is being reorganized based on the ON
DATA PARTITION option. Without the ON DATA PARTITION option all of the data
ranges in the range partitioned table would be reorganized, one at a time.

© Copyright IBM Corp. 1997, 2017 8-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Autonomic utilities
• Db2 databases can be configured to automatically perform database
maintenance:
 Periodic RUNSTATS ( Database CFG auto_runstats ) DEFAULT ON
− Real-time RUNSTATS ( Database CFG auto_stmt_stats ) DEFAULT ON
− Automatic Statistics collection for Statistical Views (Database auto_stats_views)
− Sampled Automatic RUNSTATS (Database auto_sampling )
 Automatic table and index reorganization ( Database CFG auto_reorg )
− Off by default for new databases
 Automatic database backup ( Database CFG auto_db_backup )
− Off by default for new databases
• Database level policies set time windows when processing is permitted
and utility options like table size limits for reorganization and tables to
include or exclude

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Autonomic utilities
The Db2 autonomic computing environment is self-configuring, self-healing, self-
optimizing, and self-protecting. By sensing and responding to situations that occur,
autonomic computing shifts the burden of managing a computing environment from
database administrators to technology.
Some autonomic database-level configuration parameters include:
• auto_runstats: This automated table maintenance parameter enables or
disables automatic table runstats operations for a database. A runstats policy (a
defined set of rules or guidelines) can be used to specify the automated behavior.
Statistics collected by the Runstats utility are used by the optimizer to determine
the most efficient plan for accessing the physical data. To be enabled, this
parameter must be set to On, and its parent parameters must also be enabled.
By default, this parameter is set to ON.
• auto_stmt_stats: This parameter enables and disables the collection of real-time
statistics. It is a child of the auto_runstats configuration parameter. This feature is
enabled only if the parent, auto_runstats configuration parameter, is also enabled.
For example, to enable auto_stmt_stats, set auto_maint, auto_tbl_maint, and
auto_runstats to ON. To preserve the child value, the auto_runstats configuration
parameter can be ON while the auto_maint configuration parameter is OFF. The
corresponding Auto Runstats feature will still be OFF.

© Copyright IBM Corp. 1997, 2017 8-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Assuming that both Auto Runstats and Auto Reorg are enabled, the settings are
as follows:
• You can disable both Auto Runstats and Auto Reorg features temporarily by
setting auto_tbl_maint to OFF. Both features can be enabled later by setting
auto_tbl_maint back to ON. You do not need to issue db2stop or db2start
commands to have the changes take effect.
By default, this parameter is set to ON.
• auto_reorg: This automated table maintenance parameter enables or disables
automatic table and index reorganization for a database. A reorganization policy
(a defined set of rules or guidelines) can be used to specify the automated
behavior. To be enabled, this parameter must be set to ON, and its parent
parameters must also be enabled.
By default, this parameter is set to OFF.
• auto_db_backup: This automated maintenance parameter enables or disables
automatic backup operations for a database. A backup policy (a defined set of
rules or guidelines) can be used to specify the automated behavior. The objective
of the backup policy is to ensure that the database is being backed up regularly.
The backup policy for a database is created automatically when the Db2 Health
Monitor first runs. By default, this parameter is set to OFF. To be enabled, this
parameter must be set to ON, and its parent parameter must also be enabled.
• auto_sampling: This parameter controls whether automatic statistics collection
uses sampling when collecting statistics for a large table. To enable the automatic
sampling, set auto_maint, auto_tbl_maint, auto_runstats and auto_sampling to
ON. If the automatic statistics collection is enabled, page-level sampling is used
and the sampling rate is determined automatically. Both data and index pages
are sampled for base tables as opposed to statistical views, which do not have
indexes..
• auto_stats_views: This parameter enables and disables automatic statistic
collection on statistical views. The statistics on statistical views are automatically
maintained when this parameter is set to ON.

© Copyright IBM Corp. 1997, 2017 8-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Monitoring a Db2 database

• Database monitoring is a vital activity for the maintenance of the
performance and health of your database
• Db2 collects information so you can perform the following types of tasks:
 Forecast hardware requirements based on database usage patterns.
 Analyze the performance of individual applications or SQL queries.
 Track the usage of indexes and tables.
 Pinpoint the cause of poor system performance.
 Assess the impact of optimization activities, for example, altering database
manager configuration parameters, adding indexes, or modifying SQL queries.
• Commands for monitoring: db2pd, LIST APPLICATIONS
• Monitoring using SQL statements
• Capture information for analysis using EVENT monitors
• Monitor with tools like Data Server Manager
• Use the dsmtop command to view current activity

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Monitoring a Db2 database

The term database monitoring refers to the tasks associated with examining the
operational status of your database.
Database monitoring is a vital activity for the maintenance of the performance and
health of your database management system. To facilitate monitoring, Db2 collects
information from the database manager, its databases, and any connected applications.
With this information you can perform the following types of tasks, and more:
• Forecast hardware requirements based on database usage patterns.
• Analyze the performance of individual applications or SQL queries.
• Track the usage of indexes and tables.
• Pinpoint the cause of poor system performance.
• Assess the impact of optimization activities (for example, altering database
manager configuration parameters, adding indexes, or modifying SQL queries).
There are two ways to monitor operations in your database. You can view information
that shows the state of various aspects of the database at a specific point in time. Or,
you can set up event monitors to capture historical information as specific types of
database events take place.

© Copyright IBM Corp. 1997, 2017 8-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

You can monitor your database operations in real-time using monitoring table functions.
For example, you can use a monitoring table function to examine the total amount of
space used in a table space. These table functions let you examine monitor elements
and metrics that report on virtually all aspects of database operations using SQL.
Event monitors capture information about database operations over time, as specific
types of events occur. For example, you can create an event monitor to capture
information about locks and deadlocks as they occur in the system. Or you might create
an event monitor to record when a threshold that you specify (for example the total
processor time used by an application or workload) is exceeded. Event monitors
generate output in different formats; all of them can write event data to regular tables;
some event monitors have additional output options.
IBM Data Server Manager helps administer, monitor, manage, and optimize the
performance of IBM data management platforms across the enterprise. It provides
database administrators (DBAs) and other IT staff with the information they need to
manage performance proactively and prevent problems before they impact the
business.
The dsmtop command is a simple text-based tool for monitoring, similar to the now
deprecated db2top command. The dsmtop command can monitor Db2 Version 10.1
and above. It is intended primarily for use on Linux and AIX, but will also run on,
Windows although with some limitations.

© Copyright IBM Corp. 1997, 2017 8-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

db2pd - Monitor and troubleshoot Db2

-applications -agents -transactions -bufferpools -logs -locks
-tablespaces -dynamic -static -fcm -mempools -memsets
-dbmcfg -dbcfg -catalogcache -sysplex -tcbstats -reorg
-recovery -reopt -osinfo -hadr -utiltiies -workloads
-workclasses -thresholds -serviceclasses -ha -statisticscache -wlocks
db2pd -db tp1 -bufferpools
Database Member 0 -- Database TP1 -- Active -- Up 0 days [Link] -- Date 02/06/2013 [Link]

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

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

db2pd - Monitor and troubleshoot Db2

The db2pd command is used for troubleshooting because it can return quick and
immediate information from the Db2 memory sets.
The tool collects information without acquiring any latches or using any engine
resources. It is therefore possible (and expected) to retrieve information that is changing
while db2pd is collecting information; hence the data might not be completely accurate.
If changing memory pointers are encountered, a signal handler is used to prevent
db2pd from ending abnormally. This can result in messages such as "Changing data
structure forced command termination" to appear in the output. Nonetheless, the tool
can be helpful for troubleshooting. Two benefits to collecting information without
latching include faster retrieval and no competition for engine resources.
The db2pd command can be used to look at the status and statistics for the
components of the database, like buffer pools and table spaces. The -dynamic report
shows the dynamic SQL statements currently in the package cache, while the -static
report shows the static SQL in package cache memory.

© Copyright IBM Corp. 1997, 2017 8-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

To use the db2pd command one of the following instance level authorities is needed:
• The SYSADM authority level.
• The SYSCTRL authority level.
• The SYSMAINT authority level.
• The SYSMON authority level.

© Copyright IBM Corp. 1997, 2017 8-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using db2pd to check reorg statistics when a reorg

fails to complete
db2pd –db MUSICDB -reorg
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date 2013-10-24-
09.23.24.781628

Table Reorg Information:

Address TbspaceID TableID PartID MasterTbs MasterTab TableName Type IndexID
TempSpaceID
0x00007F6C60937C78 11 4 n/a n/a n/a HIST1 Offline 1
11

Table Reorg Stats:

Address TableName Start End PhaseStart
0x00007F6C60937C78 HIST1 10/24/2013 [Link] 10/24/2013 [Link] 10/24/2013
[Link]

MaxPhase Phase CurCount MaxCount Status Completion

4 Build 1967 5426 Stopped

• Report shows REORG did not complete Build phase processing

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using db2pd to check reorg statistics when a reorg fails to complete

The db2pd command -reorg report can be used to show the progress of REORG
command processing. It can also be used to the point in processing where REORG
stopped execution due to some error.
The visual shows an example of the db2pd command -reorg report. The report shows
that a REORG stopped processing in the BUILD phase for a table named HIST1.

© Copyright IBM Corp. 1997, 2017 8-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using Db2 table functions in SQL statements for

monitoring (1 of 2)
• Use monitor table functions to collect and view data for systems,
activities, or data objects.
• Data for monitored elements are continually accumulated in memory
• You can choose to receive data for a single object (for example, a
table TABLE1) or for all objects
• Monitoring system information - Encompasses the complete volume of
work and effort expended by the data server to process application
requests
 For example using MON_GET_CONNECTION or MON_GET_DATABASE
• Monitoring activities -In the context of SQL statements, the term
activity refers to the execution of the section for a SQL statement
 For example using MON_GET_ACTIVITY_DETAILS or
MON_GET_PKG_CACHE_STMT

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using Db2 table functions in SQL statements for monitoring

Table functions for monitoring
You can access monitor data through a light-weight alternative to the traditional system
monitor. Use monitor table functions to collect and view data for systems, activities, or
data objects.
Data for monitored elements are continually accumulated in memory and available for
querying. You can choose to receive data for a single object (for example, service class
A or table TABLE1) or for all objects.
When using these table functions in a database partitioned 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. Using SQL,
you can sum the values across partitions to obtain the value of a monitor element
across partitions.
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.

© Copyright IBM Corp. 1997, 2017 8-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

• Monitoring activities using table functions

The activity monitoring perspective focuses on the subset of data server
processing related to executing activities. In the context of SQL statements, the
term activity refers to the execution of the section for a SQL statement.
• Other monitoring table functions
Besides table functions that return information about the system, activities, locks,
or data objects there are also table functions that return various types of
miscellaneous information. These functions include ones that return information
related to the fast communications manager (FCM), and about the status of table
space extent movement.

© Copyright IBM Corp. 1997, 2017 8-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using Db2 table functions in SQL statements for

monitoring (2 of 2)
• Monitoring data objects -The data object monitoring perspective
provides information about operations performed on data objects
 For example MON_GET_TABLE, MON_GET_INDEX and
MON_GET_BUFFERPOOL
• Monitor Locking - You can retrieve information about locks
 For example using MON_GET_LOCKS and MON_GET_APPL_LOCKWAIT
• Monitoring system memory
 You can retrieve information about system memory usage using
MON_GET_MEMORY_SET or MON_GET_MEMORY_POOL

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Additional Table functions for monitoring

• Monitoring data objects using table functions
The data object monitoring perspective provides information about operations
performed on data objects, which is tables, indexes, buffer pools, table spaces, and
containers.
• Monitoring locking using table functions
You can retrieve information about locks using table functions. Unlike request, activity
or data object monitor elements, information about locks is always available from the
database manager. You do not need to enable the collection of this information.
• Monitoring system memory using table functions
You can retrieve information about system memory usage using table functions.

© Copyright IBM Corp. 1997, 2017 8-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using the MON_GET_TABLE function for table

performance statistics

select varchar(tabname,15) as table,

varchar(tabschema,10) as schema,
rows_read, table_scans, rows_inserted, rows_updated from
table(MON_GET_TABLE('INST411',null,-1)) as mtab
where rows_read > 100 order by rows_read desc

TABLE SCHEMA ROWS_READ TABLE_SCANS ROWS_INSERTED ROWS_UPDATED

--------------- ---------- ----------- ------------- ------------- ------------
HISTORY INST411 1168373 5 3365 0
ACCT INST411 650174 4 0 3365
TELLER INST411 9730 0 0 3365
BRANCH INST411 3365 0 0 3365

4 record(s) selected.

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using the MON_GET_TABLE function for table performance statistics

The visual shows an example of a SQL query that uses the MON_GET_TABLE
function to return selected table statistics. This function can be used to get current
statistics for one table, a schema of tables or all tables that have been accessed by a
database.
With Db2 10 the statistics available for each table include information about lock waits
and the number of logical and physical pages read for data, index and XML pages.

© Copyright IBM Corp. 1997, 2017 8-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Monitoring wait times for active connections using

MON_GET_CONNECTION
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

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Monitoring wait times for active connections using MON_GET_CONNECTION

The visual shows a sample result from a SQL query that uses the Db2 table function
MON_GET_CONNECTION to retrieve some of the connection statistics showing
overall wait time and some specific sources for delaying the application requests.
In these examples the highest amounts of wait time for the currently active database
connections are POOL_READ_TIME (time spent waiting for reading pages into the
buffer pools) and LOG_DISK_WAIT_TIME (the time spent waiting for log records to be
written). These log write delays were associated with the COMMIT processing for these
applications which process many short update transactions.
In this example the active connections are not being delayed much by waits for locks.

© Copyright IBM Corp. 1997, 2017 8-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

LIST APPLICATIONS command

db2 LIST APPLICATIONS FOR DATABASE db_alias SHOW DETAIL

Auth Id Application Name Appl. Application Id

Handle
-------- -------------------- -------- ---------------------------
INST00 db2bp_32 78 *LOCAL.inst00.000327220543

Seq# Number of Coordinating Coordinating Status Status

Agents Node Number pid/thread Change Time
---- ---------- ------------ ------------ -------------- --------------
0001 1 0 230 UOW Waiting Not Collected

Node DBName DB Path

------- ------- --------------------------------------

0 MUSICDB /home/inst00/inst00/NODE0000/SQL00001/

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

LIST APPLICATIONS command

The LIST APPLICATIONS command displays an entry for each application connected
to a specific database or to all databases within the instance (the default).
The output shows the application program name, authorization ID (user name),
application handle, application ID, and the database name for each database
application.
If the SHOW DETAIL parameter is used, the output will also display the application's
sequence number, status, status change time, node, and database path.
One of the following authorities is needed to run the LIST APPLICATIONS command:
• SYSADM
• SYSCTRL
• SYSMAINT
• SYSMON

© Copyright IBM Corp. 1997, 2017 8-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

dsmtop: Db2 text-based monitoring tool command

• The dsmtop command is a simple text-based tool for monitoring, similar to the
now deprecated db2top command.
• dsmtop can monitor Db2 Version 10.1 and above.
• It is intended primarily for use on Linux and AIX, but will also run on, Windows
although with some limitations.
• The dsmtop command is a lightweight, low-overhead tool that works in a text-only
environment, such as a simple Unix command line.
 No web server and no need for a windowing environment.
 Monitoring is accomplished by using mon_get table functions.
• You can use the dsmtop command to see key performance indicators in the same
way that the db2top command worked.
• The dsmtop command provides:
 Sessions - See at a glance which connections are active, blocked, or idle.
 Running SQL - See a list of recently run statements. Drill down is provided to see the full
SQL text or run explain on a statement.
 Top Consumers - Find which connections or activities are consuming the most CPU, IO or
other resource.
 Time spent - Shows a breakdown of where the monitored database is spending time.
For example:
dsmtop -d gsdb -n localhost -r 50000 -u kdeck
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

dsmtop: Db2 text-based monitoring tool command

The dsmtop command is a simple text-based tool for monitoring, similar to the now
deprecated db2top command. The dsmtop command can monitor Db2® Version 10.1
and above. It is intended primarily for use on Linux and AIX®, but will also run on
Windows, although with some limitations.
The dsmtop command is a lightweight, low-overhead tool that works in a text-only
environment, such as a simple Unix command line. There is no Web server and no
need for a windowing environment. Monitoring is accomplished by using mon_get table
functions.
You can use the dsmtop command to see key performance indicators in the same way
that the db2top command worked. The dsmtop command provides:
• Sessions: See at a glance which connections are active, blocked, or idle.
• Running SQL: See a list of recently run statements. Drill down is provided to see
the full SQL text or run explain on a statement.
• Top Consumers: Find which connections or activities are consuming the most
CPU, IO or other resource.
Time spent: Shows a breakdown of where the monitored database is spending time.

© Copyright IBM Corp. 1997, 2017 8-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

dsmtop: tablespace activity and utilization display

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

dsmtop: tablespace activity and utilization display

The slide shows a sample dsmtop display that can be used to monitor the I/O activity
for tablespaces and also to check the storage allocations for database tablespace
storage.

© Copyright IBM Corp. 1997, 2017 8-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Db2 event monitors

The CREATE EVENT MONITOR statement defines a monitor that will
record certain events that occur when using the database, the definition of
each event monitor also specifies where the database should record the
events.
Examples of event monitor types:
• Activities – this can be used to capture the statistics for SQL statements executed
• Locking – can be used to track deadlocks, lock timeouts and lock waits
• Package cache – saves the statistics from dynamic and static statements when they
are removed from database memory
• Statistics – saves the statistics for various workload management categories, like
workloads and service classes
• Threshold violations – used to record workload management threshold violation
events that occur when using the database
• Unit of work. Record transaction level statistics when a unit of work completes
• Change History - can record events for changes to configuration parameters, registry
variables, and the execution of DDL statements and utilities.
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Db2 event monitors

Monitoring table functions and snapshot routines return the values of monitor elements
at the specific point in time the routine is run, which is useful when you want to check
the current state of your system. However, there are many times when you need to
capture information about the state of your system at exactly the time that a specific
event occurs. Event monitors serve this purpose.
Event monitors can be created to capture point-in-time information related to different
kinds of events that take place in your system. For example, you can create an event
monitor to capture information when a specific threshold that you define is exceeded.
The information captured includes such things as the ID of the application that was
running when the threshold was exceeded. Or, you might create an event monitor to
determine what statement was running when a lock event occurred.
The CREATE EVENT MONITOR statement defines a monitor that will record certain
events that occur when using the database. The definition of each event monitor also
specifies where the database should record the events.

© Copyright IBM Corp. 1997, 2017 8-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Several different types of event monitors can be created using this statement including
the following types:
• Activities. The event monitor will record activity events that occur when using the
database.
• Locking. The event monitor will record lock-related events that occur when using
the database.
• Package cache. The event monitor will record events related to the package
cache statement.
• Statistics. The event monitor will record statistics events that occur when using
the database.
• Threshold violations. The event monitor will record threshold violation events that
occur when using the database.
• Unit of work. The event monitor will record events when a unit of work completes.
• Change History - This type of event monitor can be used to track any changes to
the database and database manager configurations as well as the execution of
Db2 utilities like LOAD, online backups, REORG and RUNSTATS.

© Copyright IBM Corp. 1997, 2017 8-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

CREATE and use an activities event monitor

• To create an activities event monitor called wlmactivity that saves
information in a set of tables:
CREATE EVENT MONITOR wlmactivity
FOR ACTIVITIES WRITE TO TABLE
CONTROL (TABLE CONTROL_wlmactivity in tp1event ),
ACTIVITY (TABLE ACTIVITY_wlmactivity in tp1event ),
ACTIVITYSTMT (TABLE ACTIVITYSTMT_wlmactivity in tp1event ),
ACTIVITYVALS (TABLE ACTIVITYVALS_wlmactivity in tp1event );

• To begin collecting events with this event monitor

SET EVENT MONITOR wlmactivity STATE 1

• To stop collecting events with this event monitor

SET EVENT MONITOR wlmactivity STATE 0

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

CREATE and use an activities event monitor

Event monitors are database objects that need to be created.
The example shows an event monitor named wlmactivity, which is created to capture
activities, like SQL statement processing. This event monitor is defined as a WRITE TO
TABLE event monitor. The event monitor is defined to include specific table names and
table spaces for the set of tables associated with this event monitor.
The SET EVENT MONITOR statement can be used to start and stop collection of data
using an event monitor.

© Copyright IBM Corp. 1997, 2017 8-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Sample Activities Monitor report

SELECT wlm_activity.QUERY_CARD_ESTIMATE,
wlm_activity.ROWS_RETURNED,
abs(wlm_activity.QUERY_CARD_ESTIMATE - wlm_activity.ROWS_RETURNED) as
estimate_error,
wlm_activity.POOL_DATA_L_READS + wlm_activity.POOL_INDEX_L_READS as logical_reads,
wlm_activity.TOTAL_SORTS,
substr(wlm_stmt.STMT_TEXT,1,100) as sql_text

FROM ACTIVITYSTMT_WLMACTIVITY AS wlm_stmt,

ACTIVITY_WLMACTIVITY AS wlm_activity

WHERE wlm_stmt.APPL_ID = wlm_activity.APPL_ID

AND wlm_stmt.ACTIVITY_ID = wlm_activity.ACTIVITY_ID
AND wlm_stmt.UOW_ID = wlm_activity.UOW_ID
ORDER BY 3 DESC
QUERY_CARD_ESTIMATE ROWS_RETURNED ESTIMATE_ERROR LOGICAL_READS TOTAL_SORTS SQL_TEXT
-------------------- -------------- --------------- ---------------- ---------------- -----------------
9857 27694 17837 30208 1
SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE BRANCH_ID < 20 AND
103232 107634 4402 2401 2
SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE TELLER_ID BETWE
5136 1471 3665 743 2
SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE BRANCH_ID = 50
5136 1471 3665 743 2
SELECT * FROM HISTORY WHERE BRANCH_ID = 50 ORDER BY TELLER_ID ASC
5 18 13 53 1
SELECT * FROM HISTORY WHERE BRANCH_ID = 10 and teller_id = 200
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Sample Activities Monitor report

The sample query uses information from two of the tables associated with one
ACTIVITIES event monitor.
The query shows the number of rows estimated to be returned by the Db2 optimizer
before execution, the number of rows actually returned, some additional statistics like
sort operations and pages referenced as well as a portion of the SQL statement text.

© Copyright IBM Corp. 1997, 2017 8-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Db2 Optimizer
SQL STATEMENTS

Optimizer checks authorizations, determines

what data is requested, and from statistics,
determines an access plan

ALTERNATE
STATISTICS
COST Db2
ALGORITHMS CATALOG

Then selects one

The Optimizer Chooses:
The order in which tables are accessed
PACKAGE Which index to use
(Access Path) The join method
The type of scan required
Use of Materialized Query Tables

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Db2 Optimizer
When the query compiler optimizes query plans, its decisions are heavily influenced by
statistical information about the size of the database tables, indexes, and statistical
views. This information is stored in system catalog tables.
The optimizer also uses information about the distribution of data in specific columns of
tables, indexes, and statistical views if these columns are used to select rows or to join
tables. The optimizer uses this information to estimate the costs of alternative access
plans for each query.
Statistical information about the cluster ratio of indexes, the number of leaf pages in
indexes, the number of table rows that overflow their original pages, and the number of
filled and empty pages in a table can also be collected. You can use this information to
decide when to reorganize tables or indexes.
When it compiles an SQL or XQuery statement, the query optimizer estimates the
execution cost of different ways of satisfying the query.

© Copyright IBM Corp. 1997, 2017 8-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Based on these estimates, the optimizer selects an optimal access plan. An access
plan specifies the order of operations that are required to resolve an SQL or XQuery
statement. When an application program is bound, a package is created. This package
contains access plans for all of the static SQL and XQuery statements in that
application program. Access plans for dynamic SQL and XQuery statements are
created at run time.
There are three ways to access data in a table:
• By scanning the entire table sequentially
• By accessing an index on the table to locate specific rows
• By scan sharing
Rows might be filtered according to conditions that are defined in predicates, which are
usually stated in a WHERE clause. The selected rows in accessed tables are joined to
produce the result set, and this data might be further processed by grouping or sorting
of the output.

© Copyright IBM Corp. 1997, 2017 8-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Design Advisor
• Assists in finding the right indexes, MQTs or MDC:
 Based on workload
 Virtual indexes
• Reduce complexity of performance analysis and tuning
• db2advis command estimates benefits of suggested changes

New INDEXES ? Materialized

? Query Table

Multidimensional
Clustering
?
Tables

Distribution Key selection for

Table in a Partitioned Database ?
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Design Advisor
The Db2 Design Advisor is a tool that can help you significantly improve your workload
performance. The task of selecting which indexes, MQTs, clustering dimensions, or
partitions to create for a complex workload can be daunting. The Design Advisor
identifies all of the objects needed to improve the performance a particular workload
(can include SELECT, INSERT, UPDATE, and/or DELETE statements). Given a set of
SQL statements, it will generate recommendations for:
• New indexes
• New materialized query tables (MQTs)
• Conversion to multidimensional clustering tables (MDC)
• Repartitioning of tables
• Deletion of indexes and MQTs unused by the specified workload
You can decide to implement some or all of the recommendations immediately or
schedule them for a later time.
The Design Advisor can also help you to migrate from a single-partition database to a
multi-partitioned-environment.
For example, over a one month period of time your database manager might have to
process 1,000 INSERTs, 10,000 UPDATEs, 10,000 SELECTs, and 1,000 DELETEs.

© Copyright IBM Corp. 1997, 2017 8-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The information in the workload is concerned with the type and frequency of the SQL
statements over a given period of time. The advising engine uses this workload
information in conjunction with the database information to recommend indexes. The
goal of the advising engine is to minimize the total workload cost. This information is
written to the ADVISE_WORKLOAD table. With sufficient information/constraints, the
Design Advisor is able to suggest the appropriate actions to take for your tables.
You can execute the db2advis command from the command line, then the output is
printed to stdout by default and saved in the ADVISE_TABLE and ADVISE_INDEX
tables. Partitioning strategies can be found in the ADVISE_PARTITION table. The
RUN_ID value in all these tables corresponds to the START_TIME value in the
ADVISE_INSTANCE table for each execution of the Design Advisor.
To create the ADVISE_WORKLOAD and ADVISE_INDEX tables, run the
[Link] script found in the misc subdirectory of the sqllib subdirectory.

© Copyright IBM Corp. 1997, 2017 8-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Design Advisor: db2advis command

db2advis -d tp1 -i [Link] -disklimit 3 -o [Link] > [Link]
execution started at timestamp 2012-05-08-12.35.56.878972
found [5] SQL statements from the input file
Recommending indexes...
total disk space needed for initial set [ 5.780] MB
total disk space constrained to [ 3.000] MB
Trying variations of the solution set.
Optimization finished.
1 indexes in current solution
[5055.0000] timerons (without recommendations)
[3055.0000] timerons (with current solution) Estimated Performance
[39.56%] improvement Improvement
--
-- LIST OF RECOMMENDED INDEXES
-- ===========================
-- index[1], 0.403MB
CREATE INDEX "INST481 "."IDX1205081644270" ON "INST481 "."HISTORY"
("TELLER_ID" ASC, "BRANCH_ID" DESC) ALLOW REVERSE
Sample DDL for
SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ; Solutions
-- RECOMMENDED EXISTING INDEXES
-- ============================
-- RUNSTATS ON TABLE "INST481 "."HISTORY" FOR SAMPLED DETAILED INDEX "INST481 "."HISTIX1" ;
-- COMMIT WORK ;
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Design Advisor: db2advis command

The example shows the db2advis command line tool being used to evaluate indexes for
a set of SQL statements stored in a file. The -disklimit option is being used to restrict the
amount of disk space available for any new indexes.
The output shows that adding one new index can reduce the query cost by about 39%.
The DDL to create the new index and run the RUNSTATS utility are saved in a file for
editing.

© Copyright IBM Corp. 1997, 2017 8-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using Data Server Manager Tune option to view query

tuning recommendations (1 of 2)

Suggests collecting new statistics

and creating one new index

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Using Data Server Manager Tune option to view query tuning recommendations
The IBM Data Server Manager tool can be used to produce tuning recommendations
for single SQL statements or a SQL workload.
With Data Server Manager, DBAs and application developers can format SQL
statements so that they are easier to read, generate visual representations of access
plans, and get recommendations for collecting statistics or improving indexes.
Access plan graphs show where statements are using the most time and show where
tables are being scanned. Tuning advisors are also available to provide expert
recommendations about statistics, indexes, and performance improvement.
The slide shows an example report generated by DSM with tuning recommendations
for one SQL statement including:
• Collecting table and index statistics with the RUNSTATS command
• Creating one new index to improve table access efficiency

© Copyright IBM Corp. 1997, 2017 8-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Using Data Server Manager Tune option to view query

tuning recommendations (2 of 2)

Suggested RUNSTATS
command

Suggested DDL for new

index

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

The slide shows the recommended actions section of the tuning report generated by
Data Server Manager, including the RUNSTATS command text and CREATE INDEX
SQL statement to create one new index.

© Copyright IBM Corp. 1997, 2017 8-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

EXPLAIN facility tools

Requirements Visual SQL Access to db2exfmt db2expln
Explain Explain Tables

GUI interface
Text output
Quick and dirty static SQL
analysis
Static SQL supported

Dynamic SQL supported

CLI applications supported

Requires Explain Tables

Detailed optimizer
information
Suited for analysis of
multiple statements

Information available from

within application

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

EXPLAIN facility tools

The table summarizes the different tools available within the Db2 EXPLAIN facility and
their individual characteristics. Use this table to select the tool most suitable for your
environment and needs.
• Visual Explain tools allow for the analysis of access plan and optimizer
information from the EXPLAIN tables through a graphical interface. Tools like IBM
Data Server Manager can be used to view the access plans for SQL statements
in a visual format.
• The EXPLAIN Tables are accessible on all supported platforms and can contain
information for both static and dynamic SQL statements. You can access the
EXPLAIN tables using SQL statements, which allow for easy manipulation of the
output and comparisons of the same query over time.
• db2exfmt allows you to obtain reports from the Explain tables in a predefined
format.
• db2expln will allow you to see the access plan information that is stored in the
system catalog as part of a static package. It provides a text-based report on the
strategy Db2 will use to execute the statements. The command also support
generating the explain report from one or more dynamic SQL statements.

© Copyright IBM Corp. 1997, 2017 8-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Data Server Manager - Visual Explain access plan for SQL

Result with
costs

Object node Table Operator

Operator
(index) Reference related statistics
node

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Data Server Manager - Visual Explain access plan for SQL

Shown is an example of the Visual Explain view provided by tools like IBM Data Server
Manager.
The DSM Explain tool allows for the analysis of access plan and optimizer information
from the Explain tables through a graphical interface. Dynamic SQL statements can be
analyzed using the tool.
The Explain view provides an overview of the processing steps that will be used to
produce the result of the SQL statement. You can quickly see the method used to
access each table, if indexes will be used and how tables will be joined.
The flow of processing shown in the example starts at the bottom and moves upward.
The DSM Explain tool also provides alternate views of the access plan data. The cost
information on each operation is a cumulative estimated cost called timerons, which
blends cpu and I/O costs together.

© Copyright IBM Corp. 1997, 2017 8-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

db2exfmt - detailed text explain report

Original Statement:
Rows
------------------
RETURN
SELECT
( 1)
BRANCH_ID, Estimated result
TELLER_ID, cardinality Cost
I/O
ACCT_ID,
|
BALANCE,
ACCTNAME Estimated cost 162.025
FETCH
FROM [Link] Cumulative
( 2)
WHERE branch_id = 20 and
33.3962
teller_id between 100 and 180 Estimated I/O
4.89539
cost Cumulative
Access Plan: /---+----\
----------- 162.025 200000
Total Cost: 33.3962 IXSCAN TABLE: TEST
Query Degree: 1 ( 3) HISTORY
Cumulative Total Cost: 33.3962 13.7123 Q1
Cumulative CPU Cost: 536896 2
Cumulative I/O Cost: 4.89539 |
Cumulative Re-Total Cost: 0.227469 200000
Cumulative Re-CPU Cost: 437796 INDEX: TEST
Cumulative Re-I/O Cost: 0 HISTIX
Cumulative First Row Cost: 20.3397 Q1
Estimated Bufferpool Buffers: 5.89539
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

db2exfmt - detailed text explain report

The db2exfmt command produces a detailed explain report based on data in explain
tables.
The visual shows several sections form the detailed explain report generated using the
db2exfmt command.
The report includes the original SQL statement. The access plan report shows the
various operations that will be used to execute the SQL statement. The report includes
various cost and cardinality estimates.
The sample report results show that an estimated 162 rows will be returned from a
table [Link] with 200,000 rows of data. In this case the index [Link]
will be scanned to access the table.
The Cumulative Total Cost, 33.3962, in the sample report is based on timerons, which
combines the various resource costs, CPU, I/O and Network Communication into a
single measure.

© Copyright IBM Corp. 1997, 2017 8-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Creating Explain tables

• Sample DDL for Explain and Design Advisor provided in a file named
[Link]:
 Found in sqllib/misc
 Add IN <tablespace-name> to each CREATE TABLE

• Use SYSINSALLOBJECTS procedure

Syntax

>>-SYSINSTALLOBJECTS--(--tool-name--,--action--,---------------->
>--tablespace-name--,--schema-name--)--------------------------><

 To create a new set of explain tables

db2 CALL [Link](‘EXPLAIN','C', ‘TSEXPLAIN’, ‘DBA1’)

 To migrate a set of explain tables to a new release

db2 CALL [Link](‘EXPLAIN',‘M', NULL , ‘DBA1’)

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Creating Explain tables

The Explain tables capture access plans when the Explain facility is activated. The
Explain tables must be created before Explain can be invoked. You can create them
using one of the following methods:
• Call the [Link] procedure:
db2 CONNECT TO database-name
db2 CALL [Link]('EXPLAIN', 'C',
CAST (NULL AS VARCHAR(128)), CAST (NULL AS
VARCHAR(128)))
This call creates the explain tables under the SYSTOOLS schema. To create
them under a different schema, specify a schema name as the last parameter in
the call.
The visual shows an example of using the ‘M’ option to migrate an existing set
of explain table to match the currently installed product.

© Copyright IBM Corp. 1997, 2017 8-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

• Run the [Link] Db2 command file:

db2 CONNECT TO database-name
db2 -tf [Link]
This command file creates explain tables under the current [Link] is located
at the DB2PATH\misc directory on Windows operating systems, and the
INSTHOME/sqllib/misc directory on Linux and UNIX operating systems.
DB2PATH is the location where you install your Db2 copy and INSTHOME is
the instance home directory.

© Copyright IBM Corp. 1997, 2017 8-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Automatic database memory management

To enable self tuning memory management

db2 update db cfg using SELF_TUNING_MEM ON

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

db2 UPDATE DB CFG FOR SALESDB USING LOCKLIST AUTOMATIC

db2 ALTER BUFFERPOOL BP3 SIZE AUTOMATIC

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Automatic database memory management

Self-tuning memory simplifies the task of memory configuration by automatically setting
values for memory configuration parameters and sizing buffer pools. When enabled, the
memory tuner dynamically distributes available memory resources among the following
memory consumers: buffer pools, locking memory, package cache, and sort memory.
Self-tuning memory is enabled through the self_tuning_mem database configuration
parameter.
The following memory-related database options can be automatically tuned:
• database_memory - Database shared memory size
• locklist - Maximum storage for lock list
• maxlocks - Maximum percent of lock list before escalation
• pckcachesz - Package cache size
• sheapthres_shr - Sort heap threshold for shared sorts
• sortheap - Sort heap size

© Copyright IBM Corp. 1997, 2017 8-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Db2 provides a memory-tuning feature that simplifies the task of memory configuration
by automatically setting values for several memory configuration parameters. When
enabled, the memory tuner dynamically distributes available memory resources among
the following memory consumers: buffer pools, locking memory, package cache, and
sort memory.
The tuner works within the memory limits that are defined by the database_memory
configuration parameter. The value of this parameter can be automatically tuned as
well. When self-tuning is enabled (when the value of database_memory has been set to
AUTOMATIC), the tuner determines the overall memory requirements for the database
and increases or decreases the amount of memory allocated for database shared
memory, depending on current database requirements. For example, if current
database requirements are high and there is sufficient free memory on the system,
more memory is allocated for database shared memory. If the database memory
requirements decrease, or if the amount of free memory on the system becomes too
low, some database shared memory is released.
If the database_memory configuration parameter is not set to AUTOMATIC, the
database uses the amount of memory that has been specified for this parameter,
distributing it across the memory consumers as required. You can specify the amount
of memory in one of two ways: by setting database_memory to some numeric value or
by setting it to COMPUTED. In the latter case, the total amount of memory is based on
the sum of the initial values of the database memory heaps at database startup time.

© Copyright IBM Corp. 1997, 2017 8-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Monitoring Database memory usage using the table

function MON_GET_MEMORY_POOL
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

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Monitoring Database memory usage using the table function

MON_GET_MEMORY_POOL
The MON_GET_MEMORY_POOL table function retrieves metrics from the memory
pools contained within a memory set.
The visual 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.

© Copyright IBM Corp. 1997, 2017 8-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Configuration for Diagnostic files

DBM configuration parameters

NOTIFY LEVEL: (0-4, default 3) DIAGLEVEL: (0-4, default 3)
0 — No administrative notification 0 — No diagnostic data captured
messages captured
1 — Severe errors only
1 — Fatal or unrecoverable errors
2 — All errors
2 — Immediate action required
3 — All errors and warnings
3 — Important information, no
4 — All errors, warnings, and
immediate action required
informational messages
4 — Informational messages
DIAGPATH: Valid directory path, might contain
Notification file
Error log
Dump files
Trap files
DIAGSIZE: Can be used to limit size for diagnostic messages
• If DIAGSIZE is > 0 a set of diagnostic message files are used
• Naming used: [Link] and <instance>.[Link]
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Configuration for Diagnostic files

The visual show some of the Database Manager (DBM) configuration options that
control the location and severity levels for diagnostic messages and data for a Db2
instance.
NOTIFYLEVEL
This parameter specifies the type of administration notification messages that are
written to the administration notification log.
This applies to the Database server (DBM) with local and remote clients.
This configurable parameter is immediately changed (default value is 3).
On Linux and UNIX platforms, the administration notification log is a text file called
[Link]. On Windows, all administration notification messages are written to the
Event Log. The errors can be written by Db2, the Health Monitor, the Capture and
Apply programs, and user applications.

© Copyright IBM Corp. 1997, 2017 8-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Valid values for this parameter are:

• 0: No administration notification messages captured. (This setting is not
recommended.)
• 1: Fatal or unrecoverable errors. Only fatal and unrecoverable errors are logged.
To recover from some of these conditions, you might need assistance from Db2
service.
• 2: Immediate action required. Conditions are logged that require immediate
attention from the system administrator or the database administrator. If the
condition is not resolved, it could lead to a fatal error. Notification of very
significant, non-error activities (for example, recovery) might also be logged at this
level. This level will capture Health Monitor alarms.
• 3: Important information, no immediate action required. Conditions are logged
that are non-threatening and do not require immediate action but might indicate a
non-optimal system. This level will capture Health Monitor alarms, Health Monitor
warnings, and Health Monitor attentions.
• 4: Informational messages.
The administration notification log includes messages having values up to and including
the value of notifylevel. For example, setting notifylevel to 3 will cause the
administration notification log to include messages applicable to levels 1, 2, and 3.
DIAGLEVEL
This parameter specifies the type of diagnostic errors that will be recorded in the
[Link] file.
This applies to the Database server (DBM) with local and remote clients.
This configurable parameter is immediately changed (default value is 3).
Valid values for this parameter are:
• 0: No diagnostic data captured.
• 1: Severe errors only.
• 2: All errors.
• 3: All errors and warnings.
• 4: All errors, warnings and informational messages.
The diagpath configuration parameter is used to specify the directory that will contain
the error file, alert log file, and any dump files that might be generated, based on the
value of the DIAGLEVEL parameter.

© Copyright IBM Corp. 1997, 2017 8-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

[Link] message examples

2012-05-12-02.44.16.760595-240 E46785G1135 LEVEL: Error
PID : 14465 TID : 2877287328 PROC : db2sysc 0
INSTANCE: inst481 NODE : 000 DB : MUSICDB
APPHDL : 0-7 APPID: *LOCAL.inst481.120512063958
AUTHID : INST481 HOSTNAME: ibmclass
EDUID : 36 EDUNAME: db2lfrm0 0
FUNCTION: DB2 UDB, buffer pool services, sqlbAllocateExtent, probe:987
MESSAGE : ADM6044E The DMS table space "LOADTSPD" (ID "11") is full. If this is
an autoresize or automatic storage DMS tablespace, the maximum table space size
may have been reached or the existing containers or storage paths cannot grow any
more. Additional space can be added to the table space by either adding new
containers or extending existing ones using the ALTER TABLESPACE SQL statement.
If this is an autoresize or automatic storage DMS table space, additional space
can be added by adding containers to an autoresize table space or by adding new
storage paths to the storage group it is using.

2012-05-12-02.44.16.889302-240 I57251G525 LEVEL: Severe

PID : 14465 TID : 2896161696 PROC : db2sysc 0
INSTANCE: inst481 NODE : 000 DB : MUSICDB
APPHDL : 0-7 APPID: *LOCAL.inst481.120512063958
AUTHID : INST481 HOSTNAME: ibmclass
EDUID : 18 EDUNAME: db2agent (MUSICDB) 0
FUNCTION: DB2 UDB, database utilities, call_sqluvload, probe:1748
MESSAGE : Load Error: Load failed for table INST481 .LOADHIST1 in tablespace 11

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

[Link] message examples

The visual shows two example messages from a [Link] file.
The messages are formatted to include many standard data elements as well as some
sections that vary by message.
These messages include:
• The Db2 instance name
• The Db2 database name
• A time stamp when the message was created
• The message level indicates the severity of the condition that generated the error
• The application id
• The EDU (Engine dispatchable unit) name and id
• The Db2 internal function
• The message text

© Copyright IBM Corp. 1997, 2017 8-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The first message example was generated when all of the available space in a table
space was used. The message includes the table space name and table space id
number. The message text suggests how additional disk space may be allocated to
resolve the problem.
The second message was generated by the LOAD utility to indicate the load failed to
complete because of the problem with the named tablespace.

© Copyright IBM Corp. 1997, 2017 8-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Diagnostic Log Analysis tool: db2diag

• Command line tool for filtering and formatting [Link] files:
 Complex set of options, reflecting wide variety of filtering and analysis
 Ability to use grep-like filtering to reduce the number of records returned
• Changes to Db2 registry variables (db2set) and DB or DBM
configuration parameters are logged to [Link] file as event
records.
• To display severe errors logged for the last three days, enter: db2diag -
gi "level=severe" -H 3d
• To display all log messages not matching the pdLog pattern for the
funcname field, enter:
db2diag -g 'funcname!=pdLog'

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Diagnostic Log Analysis tool: db2diag

Analyzing db2diag log files using db2diag tool
The primary log file intended for use by database and system administrators is the
administration notification log. The db2diag log files are intended for use by IBM
Software Support for troubleshooting purposes.
Administration notification log messages are also logged to the db2diag log files using a
standardized message format.
The db2diag tool serves to filter and format the volume of information available in the
db2diag log files. Filtering db2diag log file records can reduce the time required to
locate the records needed when troubleshooting problems.
Example: Filtering the db2diag log files by database name
If there are several databases in the instance, and you want to only see those
messages which pertain to the database "SAMPLE", you can filter the db2diag log files
as follows:
db2diag -g db=SAMPLE

© Copyright IBM Corp. 1997, 2017 8-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Thus you would only see db2diag log file records that contained "DB: SAMPLE",
such as:
2006-02-15-19.31.36.114000-300 E21432H406 LEVEL: Error
PID : 940 TID : 660 PROC : [Link]
INSTANCE: DB2 NODE : 000 DB : SAMPLE
APPHDL : 0-1056 APPID: *LOCAL.DB2.060216003103
FUNCTION: DB2 UDB, base sys utilities, sqleDatabaseQuiesce, probe:2
MESSAGE : ADM7507W Database quiesce request has completed successfully.

© Copyright IBM Corp. 1997, 2017 8-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

First occurrence data capture (FODC)

• FODC is a facility to capture information on the first occurrence of a
Db2 server problem
• A package of information is created when a problem occurs on the Db2
server
• FODC package provided by customer to Db2 support
• db2support tool used to collect the package
• Helps maximize the chances that Db2 support will be able to help
resolve the problem after the first occurrence
• You can use the db2fodc command to perform a first occurrence data
collection

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

First occurrence data capture (FODC)

First occurrence data capture (FODC) collects diagnostic information about a Db2
instance, host or member when a problem occurs. FODC reduces the need to
reproduce a problem to obtain diagnostic information, because diagnostic information
can be collected as the problem occurs.
FODC can be invoked manually with the db2fodc command when you observe a
problem or invoked automatically whenever a predetermined scenario or symptom is
detected. After the diagnostic information has been collected, it is used to help
determine the potential causes of the problem. In some cases, you might be able to
determine the problem cause yourself, or involvement from IBM support personnel will
be required.
Once execution of the db2fodc command has finished, the db2support tool must be
executed to collect the resulting diagnostic files and prepare the FODC package to be
submitted to IBM Support. The db2support command will collect the contents of all
FODC package directories found or specified with the -fodcpath parameter. This is
done to avoid additional requests, from IBM Support for diagnostic information.
Diagnostic information can be gathered automatically in a first occurrence data
collection (FODC) package as the problem that affects an instance, host, or member is
occurring. The information in the FODC package can also be collected manually.

© Copyright IBM Corp. 1997, 2017 8-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

First occurrence data capture configuration (FODC) behavior, including the path used
to store the FODC package, is controlled by the DB2FODC registry variable, which can
be set persistently with the db2set command or changed dynamically (in-memory only)
through the db2pdcfg command. FODC behavior can also be customized by updating
the call-out scripts (COS) invoked during FODC.
First occurrence data capture (FODC) results in the creation of a FODC package
directory and subdirectories where diagnostic information is collected. The parent
package directory, subdirectories and files that get collected are collectively known as a
FODC package.
When an outage occurs and automatic first occurrence data capture (FODC) is
enabled, data is collected based on symptoms. The data collected is specific to what is
needed to diagnose the outage.

© Copyright IBM Corp. 1997, 2017 8-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

db2fodc - Db2 first occurrence data collection command

• db2fodc command can be used for manual first occurrence data
collection (FODC) on problems that cannot trigger automatic FODC,
such as hangs or severe performance problems.
 The db2fodc tool captures data, to be included in the FODC package, and places it
inside an FODC package directory
 Either in the default diagnostic path or in an FODC directory path you specify using
the -fodcpath parameter
• Examples:
 To collect data from a specific database:
− db2fodc –db SAMPLE -hang
− Data
collection is restricted to database SAMPLE. A new directory prefixed with
FODC_Hang_ is automatically created under the current diagnostic path.
 To collect data during a performance issue from a specific database using the full
collection script:
− db2fodc –db SAMPLE -perf full
− Data
collection is restricted to database SAMPLE. A new directory prefixed with
FODC_Perf_ is created under the current diagnostic path

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

db2fodc - Db2 first occurrence data collection command

The db2fodc utility captures symptom-based data about the Db2 instance to help
in problem determination situations. It is intended to collect information about potential
hangs, severe performance issues, and various types of errors.
The db2fodc command can be used for manual first occurrence data collection
(FODC) on problems that cannot trigger automatic FODC, such as hangs or severe
performance problems. It also can be used to collect data about index [Link]
db2fodc tool captures data, to be included in the FODC package, and places it inside
an FODC package directory, created either in the default diagnostic path or in an FODC
directory path you specify using the -fodcpath parameter.
The db2fodc tool supports additional manual collection types and supports
triggering automatic diagnostic data collection when a user-defined threshold condition
is exceeded.

© Copyright IBM Corp. 1997, 2017 8-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

To collect data during a potential hang without stopping the database manager:
db2fodc –hang -alldbs
• Default DB2FODC registry variables and parameters are used.
• A new directory prefixed with FODC_Hang_ is created under the current
diagnostic path (an error is generated if it already exists). db2cos_hang script is
executed to collect manual FODC data into one or more files, deposited into the
directory.
To collect data from a specific database:
db2fodc –db SAMPLE -hang
• Data collection is restricted to database SAMPLE. A new directory prefixed with
FODC_Hang_ is automatically created under the current diagnostic path. The
db2cos_hang script is executed to collect manual FODC data into the FODC
package stored in the directory.
To collect data during a performance issue from a specific database using the full
collection script:
db2fodc –db SAMPLE -perf full
• Data collection is restricted to database SAMPLE. A new directory prefixed with
FODC_Perf_ is created under the current diagnostic path. The db2cos_perf script
is executed to collect manual FODC data into one or more files, deposited into
the directory.

© Copyright IBM Corp. 1997, 2017 8-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Obtaining a Db2 trace using db2trc

• The db2trc command controls the trace facility provided with Db2.
• The trace facility records information about operations and formats this information
into a readable form.
• Keep in mind that there is additional processor usage when a trace is running so
enabling the trace facility might impact your system's performance.
• In general, IBM Software Support and development teams use Db2 traces for
troubleshooting
• It is important to know how to correctly turn on tracing and how to dump trace files,
just in case you are asked to obtain them.
• You will need one of SYSADM, SYSCTRL or SYSMAINT authority to use db2trc
• The following is an example of the common sequence of db2trc commands:
db2trc on -l 8M
db2trc clr
<Execute problem recreation commands>
db2trc dump [Link]
db2trc off
db2trc flw [Link] <filename>.flw
db2trc fmt [Link] <filename>.fmt
db2trc fmt -c [Link] <filename>.fmtc
Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Obtaining a Db2 trace using db2trc

The db2trc command controls the trace facility provided with Db2. The trace facility
records information about operations and formats this information into a readable form.
Keep in mind that there is additional processor usage when a trace is running so
enabling the trace facility might impact your system's performance.
In general, IBM Software Support and development teams use Db2 traces for
troubleshooting. You might run a trace to gain information about a problem that you are
investigating, but its use is rather limited without knowledge of the Db2 source code.
Nonetheless, it is important to know how to correctly turn on tracing and how to dump
trace files, just in case you are asked to obtain them.
Note: You will need one of SYSADM, SYSCTRL or SYSMAINT authority to use db2trc

© Copyright IBM Corp. 1997, 2017 8-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Demonstration 1
Using Db2 tools for performance
• Use an explain tool to analyze the access plan for an SQL statement.
• Create an index for a table to reduce processing costs for SQL.
• Invoke the Db2 Design Advisor to suggest new indexes for an SQL
workload.
• Use the Db2 RUNSTATS and REORG commands to reorganize a
table based on an index and collect new catalog statistics.

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Demonstration 1: Using Db2 tools for performance

© Copyright IBM Corp. 1997, 2017 8-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Demonstration 1:
Using Db2 tools for performance
Purpose:
This demonstration uses several Db2 tools and utilities to improve the
performance of a SQL query. You will use the Data Server Manager Visual
Explain tool to review the access plans and the estimated costs for
processing SQL statements. You will use the Db2 design advisor to suggest a
new index to reduce processing costs. You will execute a Db2 REORG utility
to reorganize a table to improve performance.

Task 1. Load a test table and create a set of explain tables for
query analysis.
1. Logon to the Linux system using the user id inst23, 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.
In this section, you will run a SQL script that creates and loads a Db2 table,
[Link], that will be used to analyze the performance of a test query.
You will also create a set of explain tables that can be used to support explain
tool access plan analysis. The file [Link] calls the SYSINSTALLOBJECTS
procedure to create a set of explain tables matching the current Db2 release.
3. Issue the following series of commands in the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 -tvf [Link]
• db2 -tvf create_testhist.ddl
The SQL statements show a sum from the QTY column for a set of rows before
and after the UPDATE processing.

© Copyright IBM Corp. 1997, 2017 8-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The output will look similar to the following:

CONNECT TO MUSICDB

Database Connection Information

Database server = DB2/LINUXX8664 [Link]

SQL authorization ID = INST23
Local database alias = MUSICDB

CREATE TABLE "TEST "."HISTORY" ( "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 CURRENT TIMESTAMP ,
"ACCTNAME" CHAR(20) NOT NULL , "TEMP" CHAR(6) NOT NULL ) IN "USERSPACE1"
DB20000I The SQL command completed successfully.

LOAD FROM /home/inst23/ddl/[Link] OF IXF REPLACE INTO [Link]

NONRECOVERABLE
SQL3109N The utility is beginning to load data from file
"/home/inst23/ddl/[Link]".

SQL3500W The utility is beginning the "LOAD" phase at time "07/25/2017

[Link].288578".

SQL3150N The H record in the PC/IXF file has product "DB2 02.00", date
"20120817", and time "154700".

SQL3050W Conversions on the data will be made between the IXF file code
page
"1252" and the application code page "1208".

SQL3153N The T record in the PC/IXF file has name "[Link]",

qualifier
"", and source " ".

SQL3519W Begin Load Consistency Point. Input record count = "0".

SQL3520W Load Consistency Point was successful.

SQL3110N The utility has completed processing. "200000" rows were read
from
the input file.

SQL3519W Begin Load Consistency Point. Input record count = "200000".

© Copyright IBM Corp. 1997, 2017 8-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

SQL3520W Load Consistency Point was successful.

SQL3515W The utility has finished the "LOAD" phase at time "07/25/2017
[Link].042465".

Number of rows read = 200000

Number of rows skipped = 0
Number of rows loaded = 200000
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 200000

RUNSTATS ON TABLE [Link]

DB20000I The RUNSTATS command completed successfully.

CONNECT RESET
DB20000I The SQL command completed successfully.

Task 2. Use the Explain SQL capability of Data Server

Manager to review the access plan and estimated
costs for processing a SQL statement.
The file inst23/ddl/query_history.sql will be used as a sample application SQL
statement.
You will use the DSM Explain tool to review the access plan for a SQL statement.
When DSM was installed, a local user profile was created, and associated to the
application: userid: db2admin, password: ibm2blue
1. Start DSM if not already started and select the MUSICDB database from the
database list at the top. On the left, click Run SQL.
2. Clear any SQL statements from the editor that may remain from previous steps.
3. Click Script > Open from Client.
4. Use the Browse button for the Open SQL Script window to locate and select
the file inst23/ddl/query_history.sql.
5. Click Open.
6. Click OK to complete loading of the SQL text into the SQL editor.
The SQL statement is a SELECT from the table [Link] with two
predicates, one on the BRANCH_ID column and one on the TELLER_ID
column.

© Copyright IBM Corp. 1997, 2017 8-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

7. Click Run > Explain to generate the access plan report. The Visual Explain
graph will appear in a new Web Browser tab.

8. Select the TBSCAN operation and look at the cost statistics that appear next to
the TBSCAN octagon. You may want to click on the (+) magnifier icon on the
left to increase the size of the access plan objects.
A TBSCAN operation will read every page in the table to produce the result.
Look at the following:
• Estimated Cardinality: _____________ (test result 162)
• Cumulative Total Cost: _____________ (test result 3,229)
• Cumulative I/O Cost : _____________ (test result 3,575)
Your results may be slightly different, but a test result produced the estimated
cardinality of 162 rows, and an estimated I/O cost of 3,575, which is the number
of pages in the table being accessed. There are 200,000 rows in the test table,
so the access plan will scan every row and only return about 162 rows of result.
You should be able to tune this query to run more efficiently.
9. Close the Visual Explain tab in the Web Browser.

© Copyright IBM Corp. 1997, 2017 8-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Task 3. Use the db2advis command to recommend additional

table indexes that could reduce processing costs for
the SQL query.
The db2advis command can be used to suggest changes, like adding new table
indexes that could reduce processing costs for an SQL workload.
You will utilize the SQL query from the file $HOME/ddl/query_history.sql, as the
workload to input to the db2advis command.
1. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2advis -d musicdb -i query_history.sql | more
The output will include results similar to the following:
execution started at timestamp 2017-07-25-11.07.01.240879
found [1] SQL statements from the input file
Recommending indexes...
total disk space needed for initial set [ 10.981] MB
total disk space constrained to [ 29.976] MB
Trying variations of the solution set.
1 indexes in current solution
[3234.0000] timerons (without recommendations)
[ 22.0000] timerons (with current solution)
[99.32%] improvement

--
--
-- LIST OF RECOMMENDED INDEXES
-- ===========================
-- index[1], 10.981MB
CREATE INDEX "INST23 "."IDX1707251507050" ON "TEST "."HISTORY"
("BRANCH_ID" ASC, "TELLER_ID" ASC, "ACCTNAME" ASC,
"BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS COLLECT SAMPLED
DETAILED STATISTICS;
COMMIT WORK ;

The db2advis report includes a recommendation to create one new index. A

CREATE INDEX statement is listed that is estimated to significantly reduce SQL
execution costs.

© Copyright IBM Corp. 1997, 2017 8-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

The suggested new index should look similar to the following:

CREATE INDEX "INST23 "."IDX1608151408110" ON "TEST "."HISTORY"
("BRANCH_ID" ASC, "TELLER_ID" ASC, "ACCTNAME" ASC,
"BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS COLLECT SAMPLED
DETAILED STATISTICS;
This index may be very efficient for processing this one SQL statement, but you
will create a simple two column index, on BRANCH_ID and TELLER_ID, that
will require less disk space.
You will use Data Server Manager to run the CREATE INDEX and RUNSTATS
statements, using the file, inst23/ddl/create_testhist_ix.ddl, that contains the
following commands:
create index [Link] on [Link] (branch_id, teller_id) ;
Call SYSPROC.ADMIN_CMD( 'runstats on table [Link] and indexes all
' ) ;
2. Using DSM, on the left, click Run SQL.
3. Clear any SQL statements from the editor that may remain from previous steps.
4. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/create_testhist_ix.ddl.
5. Click Open.
6. Click OK to complete loading the SQL text into the SQL editor.
7. Review the CREATE INDEX statement and the ADMIN_CMD procedure call
that is used to invoke the RUNSTATS processing.
8. Click Run > Run All and wait for the SQL statements to be processed.
Task 4. Use the Explain SQL capability of DSM to check the
access plan and estimated costs with the new index
in place.
You will be using the SQL in the file inst23/ddl/query_history.sql, which should still be
in a SQL Editor view in DSM. If not, open a new SQL Editor and upload the SQL text
from the file.
1. Click Run SQL from the options on the left. Clear any SQL statements from the
editor that may remain from previous steps.
2. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/query_history.sql.
3. Click Open.
4. Click OK to complete loading of the SQL text into the SQL editor.
5. Click Run > Explain to generate the access plan report. The Visual Explain
graph will appear in a new Web Browser tab.

© Copyright IBM Corp. 1997, 2017 8-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

6. Select the IXSCAN operation and look at the cost statistics that appear next to
the IXSCAN octagon. You may want to click on the (+) magnifier icon on the left
to increase the size of the access plan objects.
The new access plan utilizes the new index with an IXSCAN, or index scan
operation, followed by the FETCH to retrieve data rows using the index pointers.
7. Select the FETCH operation and look at the cost statistics that appear.

Look at the following:

• Estimated Cardinality: _____________ (test result 162)
• Cumulative Total Cost: _____________ (test result 699)
• Cumulative I/O Cost : _____________ (test result 103)
Your results may be slightly different, but a test result produced the estimated
cardinality of 162 rows, and estimated I/O cost at 103.
These estimated costs are much lower than those required for the table scan in
the previous access plan.
The relatively high I/O count, over 100, in order to read the estimated 162 rows
suggests that the data you need spans many pages.
8. Close the Visual Explain tab in the Web Browser.

© Copyright IBM Corp. 1997, 2017 8-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Task 5. Reorganize a table using a REORG utility.

The Db2 REORG utility can reorganize, by sorting a table's data rows to match the
sequence of an index. This is called a reclustering reorganization.
This type of reorganization can improve the performance of applications that need to
retrieve sets of rows using an index since the results may be located together in a
relatively small number of pages.
You will use DSM to invoke the table reorganization.
1. Click Administer > Tables on the left side of the DSM application.
The current table objects are listed.
2. Locate and select the table [Link]. You may need to resize the
schema and table columns. (You can enter '%HISTORY' in the filter to make it
easier to locate the table.)
3. Select Reorganize (which may be listed under the More Actions list).
4. Select these options:
• Reorganization Method: Classic
• Indexes, Table Spaces, and Dictionary: Reorganize by using an existing
index (the only index, [Link], is listed)
• Temporally store a copy of the reorganized table in a temporary
table space
• Leave other options with default values
5. The DSM tool generates the REORG TABLE command with a procedure call to
ADMIN_CMD. Click on the (+) next to Command to view the command text.
The command text should be similar to the following:
CALL SYSPROC.ADMIN_CMD ('REORG TABLE [Link] INDEX [Link]
USE TEMPSPACE1');
6. Click Run.
The result should show that the command processing succeeded.
7. Locate and select the table [Link] and click on the check box.
You need to collect new table and index statistics, so that the Db2 Optimizer
can accurately plan access to the newly reorganized table.
8. Select Collect Statistics (which may be listed under the More Actions list).
9. Click on the right pointing Arrow at the bottom.

© Copyright IBM Corp. 1997, 2017 8-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

10. Leave all of the options with default values, and then Click on the (+) next to
Command to view the command text.
11. Select Run.
The result should show that the command processing succeeded.
Task 6. Use the Explain SQL capability of DSM to recheck the
access plan and estimated costs after table
reorganization.
You will be using the SQL in the file inst23/ddl/query_history.sql which should still be
in a SQL Editor view in DSM. If not, open a new SQL Editor and upload the SQL text
from the file.
1. Click Run SQL from the options on the left. Clear any SQL statements from the
editor that may remain from previous steps.
2. Click Script > Open from Client. Use the Browse button for the Open SQL
Script window to locate and select the file inst23/ddl/query_history.sql.
3. Click Run > Explain to generate the access plan report. The Visual Explain
graph will appear in a new Web Browser tab.
The access plan utilizes the index with an IXSCAN, or index scan operation,
followed by the FETCH to retrieve data rows using the index pointers. The new
estimated costs are much lower with a reorganized table.
4. Select the FETCH operation and look at the cost statistics that appear.

© Copyright IBM Corp. 1997, 2017 8-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Look at the following:

• Estimated Cardinality: _____________ (test result 162)
• Cumulative Total Cost: _____________ (test result 33)
• Cumulative I/O Cost : _____________ (test result 4.9)
Your results may be slightly different, but a test result produced the estimated
cardinality of 162 rows with an estimated I/O cost at 4.9. These estimated costs
are much lower than those required for the index scan in the previous access
plan before the table was reorganized.
The relatively small count, about 5, shows that Db2 expects to find the rows in a
small number of pages, which drastically reduces the estimated costs.
Results:
You used several Db2 tools and utilities to improve the performance of a SQL
query. You invoked the Data Server Manager Visual Explain tool to review the
access plans and the estimated costs for processing SQL statements. You
used the Db2 design advisor to suggest a new index to reduce processing
costs. You executed a Db2 REORG utility to reorganize a table to improve
performance.

© Copyright IBM Corp. 1997, 2017 8-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

Unit summary
• Plan the use of RUNSTATS, REORGCHK and REORG utilities for
maintaining database efficiency
• Configure the Db2 instance to set the location for diagnostic data and
message severity levels for basic problem analysis
• Describe the methods that can be used for monitoring database and
application activity including db2pd commands, Event Monitors and
using SQL statements to access statistics
• Describe the function of EXPLAIN and use this facility to assist basic
analysis
• Use the db2advis command to analyze a workload for potential
performance improvements
• Use the db2fodc command to collect diagnostic data for a system hang

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 8-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 8 Database maintenance, monitoring and problem determination

© Copyright IBM Corp. 1997, 2017 8-68

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Locking and concurrency

Locking and concurrency

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 9 Locking and concurrency

© Copyright IBM Corp. 1997, 2017 9-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Unit objectives
• Explain why locking is needed
• List objects that can be locked
• Describe and discuss the various lock modes and their compatibility
• Explain four different levels of data protection
• Set isolation level and lock time out for current activity
• Explain lock conversion and escalation
• Describe the situation that causes deadlocks
• Create a LOCKING EVENT monitor to collect lock related diagnostics
• Set database configuration options to control locking event capture

Locking and concurrency © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 9-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Why perform locking?

Anomaly Description
Dirty Write A transaction modifies uncommitted data that was
modified by another transaction which has not yet
performed a COMMIT or ROLLBACK
Dirty Read A transaction reads data that was modified by
another transaction which has not yet performed a
COMMIT or ROLLBACK
Fuzzy Read A transaction that reads data does not see the same
Non-repeatable Read data which it had seen earlier.
Phantom Read A transaction that is reading data sees new data
later in the same transaction. This occurs when
another transaction inserts or updates data that
would satisfy the transactions query

Db2 Applications request an isolation level based on need to avoid these anomalies

Locking and concurrency © Copyright IBM Corporation 2017

Why perform locking?

Because many users access and change data in a relational database, the database
manager must be able both to allow users to make these changes and to ensure that
data integrity is preserved. Concurrency refers to the sharing of resources by multiple
interactive users or application programs at the same time.
The primary reasons why locks are needed are:
• Ensure data integrity. Stop one application from accessing or changing a record
while another application has the record locked for its use.
• Access to uncommitted data. Application A might update a value in the
database, and application B might read that value before it was committed. If the
value of A is not later committed, but backed out, calculations performed by B are
based on uncommitted (and presumably invalid) data. Of course, you might want
to read even uncommitted data, for example to get a rough count of the number
of records of a particular type without the guarantee of instantaneous precision.
You can use an Uncommitted Read (UR) isolation level to do this - you will see
more about this later.

© Copyright IBM Corp. 1997, 2017 9-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

The database manager controls this access to prevent undesirable effects, such as:
• Lost updates. Two applications, A and B, might both read the same row from the
database and both calculate new values for one of its columns based on the data
these applications read. If A updates the row with its new value and B then also
updates the row, the update performed by A is lost.
• Nonrepeatable reads. Some applications involve the following sequence of
events: application A reads a row from the database, then goes on to process
other SQL requests. In the meantime, application B either modifies or deletes the
row and commits the change. Later, if application A attempts to read the original
row again, it receives the modified row or discovers that the original row has been
deleted.
• Phantom Read Phenomenon. The phantom read phenomenon occurs when:
1. Your application executes a query that reads a set of rows based on some
search criterion.
2. Another application inserts new data or updates existing data that would
satisfy your application’s query.
3. Your application repeats the query from Step 1 (within the same unit of
work).
4. Some additional (phantom) rows are returned as part of the result set, but
were not returned when the query was initially executed (Step 1).

© Copyright IBM Corp. 1997, 2017 9-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Objects that might be locked

• Table space locks are mainly used
to control concurrent execution for
utilities like BACKUP, LOAD,
REORG Table
Lock
• For standard tables, Db2 will
acquire a table lock and might also Row Locks
perform row locking
Table
• For Multidimensional Cluster Lock
(MDC) tables, locking might also be Block
performed at the block (extent) Locks
level Row Locks Table
• For range-partitioned tables, Lock
locking might be performed at the Data Range
lock
data partition level
Row Locks

Locking and concurrency © Copyright IBM Corporation 2017

Objects that might be locked

Db2 will acquire locks on database objects based on the type of access and the
isolation level that is in effect for the connection or statement that accesses data.
Table space level locks are not always held by applications when they access Db2
data. These are used primarily by Db2 utilities to make sure that two incompatible
operations would not be performed at the same time. For example, an online BACKUP
will not run at the same time a LOAD utility is processing a table in the same table
space.
For standard Db2 tables, Db2 will acquire a lock at the table level based on the type of
access. A SELECT statement would need to acquire a lock that allows read access. A
UPDATE statement would acquire a table lock that permits write access.
In most cases, Db2 will acquire read and write locks at the row level, to allow many
applications to share access to the table. In some cases, based on the isolation level
and the amount of data that would be accessed, Db2 might determine that it is more
efficient to acquire a single table level lock and bypass row locking.

© Copyright IBM Corp. 1997, 2017 9-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

For Multidimensional Clustered (MDC) tables, data is stored and indexed at the block
(extent) level. Db2 can utilize block level locks for these tables to reduce the number of
locks that would be needed to protect an application access. For example, an MDC
table might have dimensions based on date and region columns. If the predicates for
the SQL statement indicate that all of the rows for a date range and selected products
will be retrieved, Db2 can use locks at the block level to avoid building a long list of row
locks.
For range-partitioned tables, Db2 can acquire locks at the data partition level to
supplement the table and row locks that might also be used. Their data partition locks
are also used for controlling access to the table when a new range is attached or an
existing range is detached.

© Copyright IBM Corp. 1997, 2017 9-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Table lock modes

IN Intent None
IS Intention Share

IX Intention eXclusive

SIX Share with Intention eXclusive

S Share

U Update

X eXclusive

Z superexclusive

Row Locking also used Strict Table Locking

(See next page)

Locking and concurrency © Copyright IBM Corporation 2017

Table lock modes

The lock modes listed above are used by Db2 at the table level and are defined:
• IN - Intent None: The lock owner can read any data in the table including
uncommitted data, but cannot update any of it. Other concurrent applications can
read or update the table. No row locks are acquired by the lock owner. Both table
spaces and tables can be locked in this mode.
• IS - Intention Share: The lock owner can read any data in the locked table if an
S lock can be obtained on the target rows. The lock owner cannot update the
data in the table. Other applications can read or update the table, as long as they
are not updating rows on which the lock owner has an S lock. Both table spaces
and tables can be locked in this mode.
• IX - Intention Exclusive: The lock owner can read and update data provided that
an X lock can be obtained on rows to be changed, and that a U or S lock can be
obtained on rows to be read. Other concurrent applications can both read and
update the table, as long as they are not reading or updating rows on which the
lock owner has an X lock. Both table spaces and tables can be locked in this
mode.

© Copyright IBM Corp. 1997, 2017 9-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

• SIX - Share with Intention Exclusive: The lock owner can read any data in the
table and change rows in the table provided that it can obtain an X lock on the
target rows for change. Row locks are not obtained for reading. Other concurrent
applications can read the table. Only a table object can be locked in this mode.
The SIX table lock is a special case. It is obtained if an application possesses an
IX lock on a table and requests an S lock, or vice versa. The result of lock
conversion in these cases is the SIX lock.
• S - Share: The lock owner and all concurrent applications can read but not
update any data in the table and will not obtain row locks. Tables can be locked in
this mode.
• U - Update: The lock owner can read any data in the table and can change data
if an X lock on the table can be obtained. No row locks are obtained. This type of
lock might be obtained if an application issues a SELECT...'for update'. Other
units of work can read the data in the locked object, but cannot attempt to update
it. Tables can be locked in this mode.
• X - Exclusive: The lock owner can read or update any data in the table. Row
locks are not obtained. Only uncommitted read applications can access the
locked object. Tables can be locked in this mode.
• Z - Super Exclusive: This lock is acquired on a table in certain conditions, such
as when the table is altered or dropped, or for some types of table reorganization.
No other concurrent application can read or update the table. Tables and table
spaces can be locked in this mode. No row locks are obtained.
The modes IS, IX, and SIX are used at the table level to SUPPORT row locks. They
permit row-level locking while preventing more exclusive locks on the table by other
applications.
The following examples are used to further clarify the lock modes of IS, IX, and SIX:
• An application obtains an IS lock on a table. That application might acquire a lock
on a row for read only. Other applications can also READ the same row. In
addition, other applications can CHANGE data on other rows in the table.
• An application obtains an IX lock on a table. That application might acquire a lock
on a row for change. Other applications can READ/CHANGE data on other* rows
in the table.
• An application obtains an SIX lock on a table. That application might acquire a
lock on a row for change. Other applications can ONLY READ other* rows in the
table.

© Copyright IBM Corp. 1997, 2017 9-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

The modes of S, U, X, and Z are used at the table level to enforce the strict table
locking strategy. No row-level locking is used by applications that possess one of
these modes.
The following examples are used to further clarify the lock modes of S, U, X, and Z:
• An application obtains an S lock on a table. That application can read any data in
that table. It will allow other applications to obtain locks that support read-only
requests for any data in the entire table. No application can CHANGE any data in
the table until the S lock is released.
• An application obtains a U lock on a table. That application can read any data in
that table, and might eventually change data in that table by obtaining an X lock.
Other applications can only READ data in the table.
• An application obtains an X lock on a table. That application can read and change
any or all of the data in the table. No other application can access data in the
entire table for READ* or CHANGE.
• An application obtains a Z lock on a table. That application can read and change
any or all of the data in the table. No other application can access data in the
entire table for READ or CHANGE.
The mode of IN is used at the table to permit the concept of Uncommitted Read. An
application using this lock will not obtain row-level locks.
* Denotes an exception to a given application scenario. Applications that use
Uncommitted Read can read rows that have been changed. More details regarding
Uncommitted Read are provided later in this unit.
Note: Some of the lock modes discussed are also available at the table space level.
For example, an IS lock at the table space level supports an IS or S lock at the
table level. However, further details regarding table space locking are not the
focus of this unit.

© Copyright IBM Corp. 1997, 2017 9-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Row lock modes

Minimum* Supporting
Row Lock
Table Lock

S Share IS
U Update IX
X eXclusive IX
W Weak exclusive IX
NS Next key Share IS
NW Next key Weak exclusive IX

Db2 does not need to acquire Row locks

if one of these locks is held at S, U, X, or Z
a higher level (table,block)

Locking and concurrency © Copyright IBM Corporation 2017

Row lock modes

The above modes are for row locks. The definitions are similar to the definitions for
corresponding table locks, except that the object of the lock is a row
• S - Share: The row is being READ by one application and is available for READ
ONLY by other applications.
• U - Update: The row is being READ by one application but is possibly to be
changed by that application. The row is available for READ ONLY by other
applications. The major difference between the U lock and the S lock is the
INTENT TO UPDATE. The U lock will support cursors that are opened with the
FOR UPDATE OF clause. Only one application can possess a U lock on a row.
• X - Exclusive: The row is being changed by one application and is not available
for other applications, except those that permit Uncommitted Read.
• W - Weak Exclusive: This lock is acquired on the row when a row is inserted into
a non-catalog table and a duplicate key for a unique index is encountered. The
lock owner can change the locked row. This lock is similar to an X lock except
that it is compatible with the NW lock.

© Copyright IBM Corp. 1997, 2017 9-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

• NS - Next Key Share: The lock owner and all concurrent applications can read,
but not change, the locked row. Only individual rows can be locked in NS mode.
This lock is acquired in place of a share (S) lock on data that is read with the RS
or CS isolation levels.
• NW - Next Key Weak Exclusive: This lock is acquired on the next row when a
row is inserted into the index of a non-catalog table. The lock owner can read, but
not change, the locked row. This is similar to X and NX locks, except that it is
compatible with the W and NS locks.
Row locks are only requested by applications that have supporting locks at the table
level. These supporting locks are the INTENT locks: IS, IX, and SIX.
* Denotes the least restrictive lock necessary. However, this does not imply that the
table lock listed is the only table lock that supports the row lock listed. For example, an
application that possesses an IX table lock could possess S, U, or X locks on rows.
Likewise, an application that possesses a SIX table lock could possess X locks on
rows.

© Copyright IBM Corp. 1997, 2017 9-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Lock mode compatibility

MODE OF LOCK B
MODE OF
LOCK A IN IS S
IX SIX U X Z
IN YES YES YES YES YES YES YES NO
IS YES YES YES YES YES YES NO NO
S YES YES YES NO NO YES NO NO
IX YES YES NO YES NO
Table Locks
NO NO NO
SIX YES YES NO NO NO NO NO NO
U YES YES YES NO NO NO NO NO
X YES NO NO NO NO NO NO NO
Z NO NO NO NO NO NO NO NO

LOCK MODE OF LOCK B

A
MODE S U X W NS NW
S YES YES NO NO YES NO
U YES NO NO NO YES NO
X NO NO NO NO NO NO
Row Locks NO NO NO NO YES
W NO
NS YES YES NO NO YES YES
NW NO NO NO YES YES NO
Locking and concurrency © Copyright IBM Corporation 2017

Lock mode compatibility

The symbols A and B in the above diagrams are used to represent two different
applications. The chart regarding table locks can be used to determine if the two
applications can run concurrently if they are requesting access to the same table with a
given lock mode.
For example, if application A obtains an IS lock against a given table, application B
could obtain an IN, IS, S, IX, SIX, or U lock against the same table at the same time.
However, an X or Z lock would not be permitted at the same time.
This particular example illustrates the concept of the IS lock acting as a supporting lock
for a lower level of locking. The only table locks that are not compatible are the X and Z
locks, which would require exclusive use of the table. The presence of the IS lock
indicates that a lower level of locking is required for this table, and the X or Z lock
request is not given.
Study of the chart simply reinforces the definitions of table and row lock modes
presented on the previous two pages. Review the row for IX under application A.
Assume that application A obtains an IX lock on the table Y. This lock indicates that the
application intends to obtain locks to support change at the row level. The application
will allow other rows to be read and updated, but will prevent access to the target rows
(with the exception of Uncommitted Read applications.)

© Copyright IBM Corp. 1997, 2017 9-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Examine each of the possible competing table locks that application B might request:
• IN: No row lock intention. This lock is compatible. There will be no contention
since application B is requesting Uncommitted Read. Even rows changed and
not committed by application A are available. (The Z lock is the only mode that is
not compatible with IN.)
• IS: Intent to lock for read only at the row level. This lock is compatible. There
might be contention at the row level if application A is changing the same row that
application B wants to read. The Row Locks table would need to be examined: if
application A has acquired an X or a W lock on the row that application B is
attempting to read, then application B will need to wait. Otherwise, the two
applications can proceed with concurrency.
• S: Share lock at the table level. This lock is NOT compatible, since the S lock
states that the entire table is available for READ ONLY by the application
possessing the lock and all other applications. The IX lock states an intent to
change data at the row level, which contradicts the requirement for READ ONLY.
Therefore, application B could not obtain the S lock.
• IX: Intent to lock for change at the row level. This lock is compatible. There might
be contention at the row level if application A is changing the same row that
application B wants to change. The Row Locks table would need to be examined:
if application A has acquired an X or a W lock on the row that application B is
attempting to change, then application B will need to wait. Otherwise, the two
applications can proceed with concurrency.
• SIX: The SIX lock states that a lock request for changing data might be required
at the row level for the application possessing the lock. In addition, the rest of the
table is available for READ ONLY applications. The IX lock implies change at the
row level as well. Application B could not obtain the SIX lock on the table
because of the S characteristic of the SIX lock, which is not compatible with the
IX lock already assumed owned by application A.
• U: Read with intent to update. This table level lock states that the application
possessing the lock might read any data, and might potentially exchange the U
lock for an X lock. However, until this exchange is done, other applications can
obtain locks supporting READ ONLY. Application B would NOT be able to obtain
the U lock at the same time that application A possessed an IX lock on the same
table.
• X: The application possessing this mode of lock on the table requires exclusive
use of the table. No other access, with the exception of Uncommitted Read
applications, is permitted. The IX lock possessed by application A would prevent
application B from obtaining an X lock.

© Copyright IBM Corp. 1997, 2017 9-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

• Z: The application possessing this mode of lock excludes all other access to the
table, including Uncommitted Read applications. Since application A has
obtained an incompatible lock (IX), application B would not be able to obtain the Z
lock at the same time.
The same type of statements could be logically derived for the other rows in the chart.
Many different applications could have compatible locks on the same object. For
example, ten transactions might have IS locks on a table, and five different transactions
might have IX locks on the same table. There is no concurrency problem at the table
level in such a scenario. However, there might be lock contention at the row level:
• The basic concept of the row lock matrix is that rows being READ by an
application can be READ by other applications, and that rows being changed by
an application are not available to other applications that use row locking.
Note that the U row lock is not compatible with another U row lock. Only one application
can read a row with the INTENT TO UPDATE. This U lock reduces the number of
deadlocks that occur when applications perform updates and deletes via cursors. When
a row is FETCHED using a cursor declared ...FOR UPDATE OF..., the U row lock is
used.

© Copyright IBM Corp. 1997, 2017 9-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Selecting isolation levels (1 of 2)

• An isolation level determines how data is locked or isolated from other
processes while the data is being accessed
• Db2 provides different levels of protection to isolate data:
 Uncommitted read (UR)
 Cursor stability (CS) – (default) locking behavior depends on
CUR_COMMIT in database configuration:
− ON: Read-only access will not acquire row level locks
− AVAILABLE: Applications can select currently committed mode to avoid row
locking
− DISABLE: Read-only access will acquire row level locks
 Read stability (RS)
 Repeatable read (RR)

Locking and concurrency © Copyright IBM Corporation 2017

Selecting isolation levels

The isolation level that is associated with an application process determines the degree
to which the data that is being accessed by that process is locked or isolated from other
concurrently executing processes. The isolation level is in effect for the duration of a
unit of work.
The isolation level of an application process therefore specifies:
• The degree to which rows that are read or updated by the application are
available to other concurrently executing application processes
• The degree to which the update activity of other concurrently executing
application processes can affect the application
• The isolation level for static SQL statements is specified as an attribute of a
package and applies to the application processes that use that package. The
isolation level is specified during the program preparation process by setting the
ISOLATION bind or precompile option.
• For dynamic SQL statements, the default isolation level is the isolation level that
was specified for the package preparing the statement. Use the SET CURRENT
ISOLATION statement to specify a different isolation level for dynamic SQL
statements that are issued within a session. For more information, see
"CURRENT ISOLATION special register".

© Copyright IBM Corp. 1997, 2017 9-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

• For both static SQL statements and dynamic SQL statements, the isolation-
clause in a select-statement overrides both the special register (if set) and the
bind option value. For more information, see "Select-statement".
• Isolation levels are enforced by locks, and the type of lock that is used limits or
prevents access to the data by concurrent application processes.
• Declared temporary tables and their rows cannot be locked because they are
only accessible to the application that declared them.
Note: The database configuration option CUR_COMMIT can be used to specify the
type of locking performed for read-only access is required with Cursor Stability
isolation level. The traditional Db2 locking performed for CS isolation is acquire
a single row level read lock for the current row being accessed. With the
currently committed method, these row locks are not acquired. If Db2 detects a
condition where a row that needs to be accessed was an uncommitted change,
the row data before the change is retrieved and returned instead.

© Copyright IBM Corp. 1997, 2017 9-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Selecting isolation levels (2 of 2)

• Isolation level can be specified for a session, a client connection, or
an application before a database connection, or for a specific SQL
statement:
 For embedded SQL: The level is set at bind time
 For dynamic SQL: The level is set at run time
 SELECT … WITH UR | CS | RS | RR
select * from [Link] with UR
 SET CURRENT ISOLATION
Set current isolation RS

Locking and concurrency © Copyright IBM Corporation 2017

Options for selecting the isolation level

• At the statement level:
Use the WITH clause. The WITH clause cannot be used on subqueries. The
WITH UR option applies to read-only operations only. In other cases, the
statement is automatically changed from UR to CS.
This isolation level overrides the isolation level that is specified for the package in
which the statement appears. You can specify an isolation level for the following
SQL statements:
• DECLARE CURSOR
• Searched DELETE
• INSERT
• SELECT
• SELECT INTO
• Searched UPDATE
Note: Isolation levels for XQuery statements cannot be specified at the
statement level.

© Copyright IBM Corp. 1997, 2017 9-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

• For dynamic SQL within the current session:

Use the SET CURRENT ISOLATION statement to set the isolation level for
dynamic SQL issued within a session. Issuing this statement sets the CURRENT
ISOLATION special register to a value that specifies the isolation level for any
dynamic SQL statements that are issued within the current session. Once set, the
CURRENT ISOLATION special register provides the isolation level for any
subsequent dynamic SQL statement that is compiled within the session,
regardless of which package issued the statement. This isolation level is in effect
until the session ends or until the SET CURRENT ISOLATION...RESET
statement is issued.
• At precompile or bind time:
For an application written in a supported compiled language, use the ISOLATION
option of the PREP or BIND commands. You can also use the sqlaprep or
sqlabndx API to specify the isolation level.
• If you create a bind file at precompile time, the isolation level is stored in the
bind file. If you do not specify an isolation level at bind time, the default is the
isolation level that was used during precompilation.
• If you do not specify an isolation level, the default level of cursor stability (CS)
is used.

© Copyright IBM Corp. 1997, 2017 9-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Db2 and ANSI isolation levels:

How anomalies are allowed or prevented

DB2 ANSI Dirty Dirty Fuzzy Read Phantom

Isolation Isolation Write Read Read
Uncommitted Read
Read Uncommitted
(UR) (Level 0)

Cursor Read
Stability Committed
(CS) (Level 1)

Read Repeatable
Stability Read
(RS) (Level 2)

Repeatable Serializable
Read (Level 3)
(RR)

Locking and concurrency © Copyright IBM Corporation 2017

Db2 and ANSI isolation levels: How anomalies are allowed or prevented
The Db2 isolation levels can be used to control the anomalies that an application could
experience.
Dirty Write: Lost updates. Since exclusive locks are used for all updates, regardless of
isolation level, Db2 will always prevent a second application from changing a row that
contains an uncommitted change.
Dirty Read: Access to uncommitted data. Only the UR isolation level allows
applications to access an uncommitted change in the database. All other isolation levels
prevent dirty reads.
Non-repeatable reads: Both RS and RR isolation levels hold read locks on all rows
retrieved until the transaction ends, so non-repeatable reads would be prevented.
Phantom Read Phenomenon: Only RR isolation level acquires the locks necessary to
prevent phantom reads from occurring.

© Copyright IBM Corp. 1997, 2017 9-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Locking for read-only access

Isolation Level Locking methods for Read-only access Access allowed to
uncommitted
changes
Uncommitted IN – Table lock Yes
Read No Row locks for Read-Only access
Uncommited rows accessed from buffer pool

Cursor Stability IS – Table lock No

No Row locks for Read-only access
Using Currently
Old version of rows with uncommitted changes read from log
Committed records

Cursor Stability IS - Table lock No

NS Row lock held on current row in result set
Not using
Lock wait used to delay access to uncommitted changes, in buffer
Currently pool.
Committed
Read Stability IS - Table lock No
NS Row locks held on result set until commit
Lock wait used to delay access to uncommitted changes, in buffer
pool.

Repeatable IS - Table lock No

Read S Row locks held on all rows accessed until commit
Lock wait used to delay access to uncommitted changes, in buffer
pool.
Locking and concurrency © Copyright IBM Corporation 2017

Locking for read-only access

The types of table and row locks used for read-only access will vary depending on the
isolation level that is in effect for the statement.
For Uncommitted Read (UR), Db2 will acquire the Intent None (IN) lock for the table
and will not acquire any row level locks. In this mode an uncommitted change made
read by the application.
For Cursor Stability (CS), the locking performed will depend on whether the currently
committed mode is being used.
• With currently committed on, Db2 will acquire the Intent Share (IS) lock for the
table and will not acquire any row level locks. If Db2 finds a row that has an
uncommitted change, the previous data will be read and returned.
• With currently committed off, Db2 will acquire the Intent Share (IS) lock for the
table and will acquire a NS row lock for the current row in a result. The lock is
released when the next row is accessed. If Db2 finds a row that has an
uncommitted change a lock wait condition will occur.
For Read Stability (RS), Db2 will acquire the Intent Share (IS) lock for the table and will
acquire a NS row lock for the current row in a result. These row locks will not be
released until the transaction is committed or rolled back. If Db2 finds a row that has an
uncommitted change a lock wait condition will occur.

© Copyright IBM Corp. 1997, 2017 9-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

For Repeatable Read (RR), Db2 will acquire the Intent Share (IS) lock for the table and
will acquire a S row lock for the any row that is accessed to produce the result. In some
cases Db2 might process a very large number of rows to produce a relatively small
result and in this mode a large number of row locks would be needed. These row locks
will not be released until the transaction is committed or rolled back. If Db2 finds a row
that has an uncommitted change a lock wait condition will occur.

© Copyright IBM Corp. 1997, 2017 9-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

How Currently Committed works for CS isolation

Application A Application B
Updates several rows Reads Committed rows using
New data in buffer pool log data when needed

200 new 300 new Log Buffer

Buffer pools
Read Only 200 old 200 new
201 new 301 new Committed
Log Reader
100 101 Update
Log Writer
Uncommitted
Update I/O Servers Page Cleaners
Active Log Files

100 300 new 300 old

300 old 301 new 201 new
201 new 201 old
301 new 301 old
101 200 old

Table space Archived logs will not be accessed

Containers to retrieve committed data row

Locking and concurrency © Copyright IBM Corporation 2017

How Currently Committed works for CS isolation

When an application makes changes to a row, that change is reflected immediately in
the data page that is in the buffer pool. The change is recorded in log records that are
placed in the log buffer in memory and then written to a log file.
With the Currently Committed option ON, Db2 handles the locking and data access for
read-only requests using cursor stability isolation differently.
In the visual, two applications are accessing a Db2 database.
Application A has performed some reads (row 100) and has also made several
changes (rows 200 and 201), and has not committed those changes. The log record
containing the change for row 200 is still in the log buffer, but the change to row 201
has already been written to a log file on disk.
Application B is running under cursor stability isolation and the Currently Committed
option is ON. Application needs to read and return the data from rows 101, 200, 201
and 300. The two rows 101 and 300 are currently in the buffer pool and there is not an
uncommitted change so those can be returned without using any row lock. Since the
versions of the rows 200 and 201 that are in the buffer pool contain changes that are
not yet committed, Db2 cannot allow application B to see those changes under cursor
stability rules.

© Copyright IBM Corp. 1997, 2017 9-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Rather than wait for the changes to be committed or rolled back, Db2 will access the
previous version of the row written in the log records and return that data to application
B. No row locks will be needed for these rows either.
The advantage is the performance gain from avoiding a lock wait and also from
reducing the need for locking memory.
This mode does require that the full previous version of a row is included in the log
record which might increase the amount of information logged. In some cases the
increased logging could impact overall database performance.
For supporting the currently committed locking option, Db2 will only access information
in the log buffer or from an active log file on disk. Db2 will not retrieve any archived log
files to support an application using Currently Committed mode and will switch to
acquire locks instead.

© Copyright IBM Corp. 1997, 2017 9-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

LOCK TABLE statement

IS IX

S X
S X
Database Manager
S determined strategy X

Application issues:
LOCK TABLE name
IN MODE

SHARE EXCLUSIVE
S X

—or—
Administrator alters table:
ALTER TABLE [Link]
LOCKSIZE {TABLE | ROW}
Locking and concurrency © Copyright IBM Corporation 2017

LOCK TABLE statement

Isolation level and access strategy are factors that affect the database manager when it
determines the locking strategy to use when reading or manipulating data. Generally,
intent locks at the table level, and row locking, are used to support transaction-oriented
applications.
However, the use of intent locking might not be appropriate for a given application.
The LOCK TABLE statement provides the application programmer with the flexibility to
lock a table at a more restrictive mode than requested by the database manager. Only
applications with a need for a more restrictive mode of lock should issue the LOCK
TABLE statement. Such applications could include report programs that must show
snapshots of the data at a given point in time, or data modifying programs that normally
do not make changes to significant portions of a table except during certain periods
such as for month-end processing.
• SHARE MODE allows other processes to SELECT data in the TABLE, but does
not allow INSERT, UPDATE, or DELETE operations.
• EXCLUSIVE MODE prevents any other processes from performing any operation
on the table, with the exception of Uncommitted Read applications.
Locks obtained via the LOCK TABLE statement are acquired when the statement is
executed. These locks are released by commit or rollback.

© Copyright IBM Corp. 1997, 2017 9-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

The table can also be altered to indicate the size (granularity) of locks used when the
table is accessed. If LOCKSIZE TABLE is indicated, then the appropriate share or
exclusive lock is acquired on the table, and intent locks (except intent none) are not
used. Use of this value might improve the performance of queries by limiting the
number of locks that need to be acquired. However, concurrency is also reduced since
all locks are held over the complete table.
Even though the intent lock strategy is common for typical transaction-oriented
applications, there are situations when strict table locking will be selected by the
database manager. For example, the isolation level of Repeatable Read combined with
an access strategy of TABLE SCAN or INDEX SCAN with no WHERE clause will be
supported with a strict table lock. If the strict table locking that results causes
unacceptable concurrency problems, the applications using Repeatable Read should
be examined to determine if a different access strategy can be used or if the isolation
level can be changed. Repeatable Read can be logically simulated, although the
application code required to do so might carry a high cost for development,
maintenance, or both.
Strict table locking cannot be avoided when issuing DDL against a table or index. When
possible, the database administrator should restrict submission of such statements to
periods of low activity.
In any case, strict table locks determined during the optimization process are
externalized by the Explain function.

© Copyright IBM Corp. 1997, 2017 9-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Setting LOCKLIST and MAXLOCKS to control

Lock escalations
LOCKLIST and MAXLOCKS can be configured as AUTOMATIC to use
Db2 self-tuning memory management

m e
a x

.
.........
locklist x c
l e
o e

.........
X
X c d
k e
maxlocks s d
X
IX X

ESCALATING APPLICATION OTHER APPLICATIONS

X
X
IX
l X
............

............
.
.........

locklist c f
k u
l l
i l
s
t

Locking and concurrency © Copyright IBM Corporation 2017

Setting LOCKLIST and MAXLOCKS to control Lock escalations

In order to service as many applications as possible, the database manager provides
the function of lock escalation. This process entails obtaining a table lock and releasing
row locks. The desired effect of the process is to reduce the overall storage requirement
for locks by the database manager. This will enable other applications to obtain locks
requested.
Two database configuration parameters have a direct impact on the process of lock
escalation:
• locklist: The number of 4 KB pages allocated in the database global memory for
lock storage. This parameter is configurable online.
The default value for locklist and maxlocks is AUTOMATIC, so the self-tuning
memory management routines can adjust the size of the locklist and maxlocks to
match the demands of the current workload.
• maxlocks: The percentage of the total locklist permitted by a single application.
This parameter is configurable online.

© Copyright IBM Corp. 1997, 2017 9-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Lock escalation can occur in two different situations:

• A single application requests a lock that will cause the application to exceed the
percentage of the total locklist as defined by maxlocks. The database manager
will attempt to free memory space by obtaining a table lock and releasing row
locks for the requesting application.
• An application triggers lock escalation because the total locklist is full. The
database manager will attempt to free memory space by obtaining a table lock
and releasing row locks for the requesting application. Note that the application
being escalated might or might not have a significant number of locks. The total
lock volume might be reaching a threshold because of high system activity where
no individual application has reached the limit established by maxlocks.
A lock escalation attempt can fail. If a failure occurs, the application for which escalation
has been attempted will receive a -912 SQLCODE. Such a return code should be
handled by the application.
Important: When LOCKLIST is set to AUTOMATIC, it is enabled for self-tuning. This
allows the memory tuner to dynamically size the memory area controlled by this
parameter as the workload requirements change. Because the memory tuner trades
memory resources between different memory consumers, there must be at least two
memory consumers enabled for self-tuning in order for self-tuning to be active
Although the value of locklist can be tuned together with the maxlocks parameter,
disabling self-tuning of the locklist parameter does not automatically disable self-tuning
of the maxlocks parameter. Enabling self-tuning of the locklist parameter automatically
enables self-tuning of the maxlocks parameter.
Automatic tuning of this configuration parameter will only occur when self-tuning
memory is enabled for the database (the SELF_TUNING_MEM configuration
parameter is set to ON.)

© Copyright IBM Corp. 1997, 2017 9-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Lock wait and timeout

Database CFG 12
option 30
9 3
locktimeout
6
I just want
-1 that one!
x x x
x x x

x
x LOCK x WAIT!
x
x HOG x
x
x x

If the application hogging the locks

does not COMMIT or ROLLBACK,
other applications wait until lock is
available or timeout exceeded

Applications can use the SET CURRENT LOCK TIMEOUT statement to override
the database configuration default.

Locking and concurrency © Copyright IBM Corporation 2017

Lock wait and timeout

Lock timeout detection is a database manager feature that prevents applications from
waiting indefinitely for a lock to be released.
For example, a transaction might be waiting for a lock that is held by another user's
application, but the other user has left the workstation without allowing the application to
commit the transaction, which would release the lock. To avoid stalling an application in
such a case, set the locktimeout database configuration parameter to the maximum
time that any application should have to wait to obtain a lock.
Setting this parameter helps to avoid global deadlocks, especially in distributed unit of
work (DUOW) applications. If the time during which a lock request is pending is greater
than the locktimeout value, an error is returned to the requesting application and its
transaction is rolled back. For example, if APPL1 tries to acquire a lock that is already
held by APPL2, APPL1 receives SQLCODE -911 (SQLSTATE 40001) with reason
code 68 if the timeout period expires. The default value for locktimeout is -1, which
means that lock timeout detection is disabled.
For table, row, data partition, and multidimensional clustering (MDC) block locks, an
application can override the locktimeout value by changing the value of the CURRENT
LOCK TIMEOUT special register.

© Copyright IBM Corp. 1997, 2017 9-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Information about lock waits and timeouts can be collected using the CREATE EVENT
MONITOR FOR LOCKING statement.
To log more information about lock-request timeouts in the db2diag log files, set the
value of the diaglevel database manager configuration parameter to 4. The logged
information includes the name of the locked object, the lock mode, and the application
that is holding the lock. The current dynamic SQL or XQuery statement or static
package name might also be logged. A dynamic SQL or XQuery statement is logged
only at diaglevel 4.
You can get additional information about lock waits and lock timeouts from the lock wait
information system monitor elements, or from the db.apps_waiting_locks health
indicator.
The database configuration option mon_lck_msg_lvl controls the logging of messages
to the administration notification log when lock timeout, deadlock, and lock escalation
events occur.
• With the occurrence of lock timeout, deadlock, and lock escalation events,
messages can be logged to the administration notification log by setting this
database configuration parameter to a value appropriate for the level of
notification that you want. The following list outlines the levels of notification that
can be set:
• 0 - Level 0: No notification of lock escalations, deadlocks, and lock timeouts is
provided
• 1 - Level 1: Notification of lock escalations
• 2 - Level 2: Notification of lock escalations and deadlocks
• 3 - Level 3: Notification of lock escalations, deadlocks, and lock timeouts
• The default level of notification setting for this database configuration
parameter is 1.

© Copyright IBM Corp. 1997, 2017 9-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Using db2pd to look for active lock wait conditions

• db2pd -db musicdb -wlock detail

Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date

2016-09-11-10.17.36.928742

Locks being waited on :

AppHandl [nod-index] TranHdl Lockname Type Mode Conv
Sts
679 [000-00679] 3 090004001B0001000000000052 RowLock ..X G
688 [000-00688] 11 090004001B0001000000000052 RowLock .NS W

CoorEDU AppName AuthID AppID TableNm

SchemaNm AppNode
523 db2bp INST28 *LOCAL.inst28.140911140857 STOCK
MUSIC ibmclass
554 db2bp USER28 *LOCAL.inst28.140911141135 STOCK
MUSIC ibmclass

Locking and concurrency © Copyright IBM Corporation 2017

Using db2pd to look for active lock wait conditions

The db2pd command can be used to produce a report showing current lock wait
conditions for a database.
The visual shows an example of the report generated. In this example one application
connection is waiting for an NS lock on a row. Another application currently holds the
exclusive X lock for the same row.
The detail sub-option for the db2pd -wlocks command displays the TableNm,
SchemaNm, and AppNode columns for application locks that are being waited on.

© Copyright IBM Corp. 1997, 2017 9-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Using Data Server Manager to view lock wait objects

Locking and concurrency © Copyright IBM Corporation 2017

Using Data Server Manager to view lock wait objects

The IBM Data Server Manager tool can be used to view lock wait conditions for a Db2
database.
The slide shows an example of the 'Locked Objects with Waiting Connections' view
showing an application connection waiting for a single row from a table.
Another view shows the applications as the 'blocker' and 'waiter' for locks.

© Copyright IBM Corp. 1997, 2017 9-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Deadlock causes and detection

APPLICATION A LOCKLIST APPLICATION B

UPDATE … artists UPDATE … albums

WHERE ARTNO = 10 A wait
WHERE ARTNO = 10

UPDATE … albums wait B UPDATE … artists

WHERE ARTNO = 10
WHERE ARTNO = 10

Db2 checks the locklist for wait

conditions that can create a
deadlock between two or more
applications

dlchktime 10000 milliseconds

Locking and concurrency © Copyright IBM Corporation 2017

Deadlock causes and detection

A deadlock occurs when applications cannot complete a unit of work due to conflicting
lock requirements that cannot be resolved until the unit of work is completed.
The visual illustrates the concept of deadlocks:
1. Application A obtains an X lock on a row in the ARTISTS table to process an
UPDATE statement.
2. Application B obtains an X lock on a row in the ALBUMS table to process an
UPDATE statement.
3. Application A, in the same unit of work, needs to update the row from the
ALBUMS table that is locked by Application B, so it waits for the lock to be
released.
4. Application B,in the same unit of work, needs to update the row from the
ARTISTS table that is locked by Application A, so it waits for the lock to be
released.
5. Db2 checks the locklist and finds the two applications waiting for locks that will
not be released because the holders are in a deadlock condition.
6. Db2 selects one the applications and forces it to rollback its work, which will
release its locks and allow the other application to proceed processing.

© Copyright IBM Corp. 1997, 2017 9-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Deadlock Detector
Deadlocks are handled by a background process called the deadlock detector. If a
deadlock is detected, a victim is selected, then the victim is automatically rolled back
and returned a negative SQL code (-911) and reason code 2. Rolling back the victim
releases locks and should allow other processes to continue.
The deadlock check interval (DLCHKTIME) defines the frequency at which the
database manager checks for deadlocks among all the applications connected to a
database.
• Time_interval_for_checking_deadlock = dlchktime
• Default [Range]: 10,000 (10 seconds) [1000-600,000]
• Unit of measure: milliseconds
dlchktime: Configuration parameter that sets the deadlock check interval. This value is
designated in milliseconds and determines the interval for the asynchronous deadlock
checker to wake up for the database. The valid range of values is 1000 to 600,000
milliseconds. Setting this value high will increase the time that applications will wait
before a deadlock is discovered, but the cost of executing the deadlock checker is
saved. If the value is set low, deadlocks are detected quickly, but a decrease in run-
time performance could be experienced due to checking. The default value
corresponds to 10 seconds. This parameter is configurable online.

© Copyright IBM Corp. 1997, 2017 9-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Monitoring active lock waits with SQL

select substr(lw.hld_application_name,1,10) as "Hold App", Who is holding the lock?

substr(lw.hld_userid,1,10) as "Holder",
substr(lw.req_application_name,1,10) as "Wait App",
substr(lw.req_userid,1,10) as "Waiter",
lw.lock_mode ,
lw.lock_object_type , Who is waiting on the lock?
substr([Link],1,10) as "TabName",
substr([Link],1,10) as "Schema",
lw.lock_wait_elapsed_time
as "waiting (s)" How long is the wait?
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

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Monitoring active lock waits with SQL

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.
The sample query shown shows the application names that are waiting for the lock and
holding the lock. The table associated with the lock and the type and mode of the lock
causing the wait are shown. The query also shows how long the application has been
waiting for the lock.

© Copyright IBM Corp. 1997, 2017 9-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Using SQL to monitor Lock escalations,

deadlocks and timeouts for active connections
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",
[Link] 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
-------------------- --------------------
0 0
0 0
0 209

Locking and concurrency © Copyright IBM Corporation 2017

Using SQL to monitor Lock escalations, deadlocks and timeouts for active connections
The MON_GET_CONNECTION table function can be used to monitor current
database connections for locking related issues.
The example query and output include:
• The number of locks currently held by the connection
• The number of lock escalations performed by the application since its connection
• The number of lock timeouts experienced by the application since its connection
• The number of deadlocks experienced by the application since its connection
• The total lock wait time for each connection

© Copyright IBM Corp. 1997, 2017 9-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Lock Event Monitoring: Part 1

• Db2 provides a LOCKING Event monitor that can be used to capture
diagnostic information
• The data collection can be configured at the database level:
 Deadlocks
− mon_deadlock - Controls the generation of deadlock events at the database
level for the Lock Event Monitor.
 Lock timeouts
− mon_locktimeout - Controls the generation of lock timeout events at the
database level for the Lock Event Monitor.
 Lock waits longer than a defined limit:
− mon_lockwait - Controls the generation of lock wait events at the database
level for the Lock Event Monitor.
− mon_lw_thresh - Controls the amount of time spent in lock wait before an
event for mon_lockwait is generated.
• Collection options for lock events can be set based on Db2 WLM
workload definitions
Locking and concurrency © Copyright IBM Corporation 2017

Lock Event Monitoring

A LOCKING Event Monitor can be used to capture descriptive information about lock
events at the time that they occur. The information captured identifies the key
applications involved in the lock contention that resulted in the lock event. Information is
captured for both the lock requestor (the application that received the deadlock or lock
timeout error, or waited for a lock for more than the specified amount of time) and the
current lock owner.
The information collected by the LOCKING Event Monitor can be written in binary
format to an unformatted event table or to a set of standard tables in the database.
The Lock Event Monitor replaces the deprecated deadlock event monitors (CREATE
EVENT MONITOR FOR DEADLOCKS statement and DB2DETAILDEADLOCK) and
the deprecated lock timeout reporting feature (DB2_CAPTURE_LOCKTIMEOUT
registry variable) with a simplified and consistent interface for gathering locking event
data, and adds the ability to capture data on lock waits.

© Copyright IBM Corp. 1997, 2017 9-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Two steps are required to enable the capturing of lock event data using the Lock Event
Monitor:
1. You must create a LOCKING EVENT monitor using the CREATE EVENT MONITOR
FOR LOCKING statement. You provide a name for the monitor.
2. You can collect data at the database level and affect all Db2 workloads by setting the
appropriate database configuration parameter:
• mon_lockwait: This parameter controls the generation of lock wait events. Best
practice is to enable lock wait data collection at the workload level.
• This can be set to NONE, WITHOUT_HIST, WITH_HISTORY or
HIST_AND_VALUES.
• The default is NONE.
• mon_lw_thresh: This parameter controls the amount of time spent in lock wait
before an event for mon_lockwait is generated.
• The value is set in microseconds, the default is 5000000 (5 seconds).
• mon_locktimeout: This parameter controls the generation of lock timeout
events. Best practice is to enable lock timeout data collection at the database
level if they are unexpected by the application. Otherwise enable at workload
level.
• This can be set to NONE, WITHOUT_HIST, WITH_HISTORY or
HIST_AND_VALUES.
• The default is NONE.
• mon_deadlock: This parameter controls the generation of deadlock events. Best
practice is to enable deadlock data collection at the database level.
• This can be set to NONE, WITHOUT_HIST, WITH_HISTORY or
HIST_AND_VALUES.
• The default is WITHOUT_HIST.
• The capturing of SQL statement history and input values incurs additional
overhead, but this level of detail is often needed to successfully debug a
locking problem.

© Copyright IBM Corp. 1997, 2017 9-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Lock Event Monitoring: Part 2

• Create a table based LOCKING Event Monitor
create event monitor MON_LOCKS for locking
write to table autostart

• Set database configuration options to control lock diagnostics.

For example, to collect data from lock waits longer than three seconds:

db2 update db cfg for salesdb using mon_lockwait with_history

db2 update db cfg for salesdb using mon_lw_thresh 3000000

• Use the LOCKING Event Monitor

set event monitor MON_LOCKS state 1

( run applications to generate locking events)

set event monitor MON_LOCKS state 0

Locking and concurrency © Copyright IBM Corporation 2017

The visual shows a CREATE EVENT MONITOR statement that could be used to
define a new Locking Event Monitor named mon_locks that would write lock event data
to a set of Db2 tables.
The following statement could be used:
create event monitor mon_locks for locking write to table autostart
This same Locking Event Monitor can also be used to collect deadlocks and lock
timeouts.
In order to collect information on any application that waits longer than three seconds
for a lock the database configuration options mon_lockwait and mon_lw_thresh could
be set. These can be configured online using the following statements.
db2 update db cfg for salesdb using mon_lockwait with_history
db2 update db cfg for salesdb using mon_lw_thresh 3000000
The visual shows how the SET EVENT MONITOR statement can be used to start and
stop the event monitor data collection.

© Copyright IBM Corp. 1997, 2017 9-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Using SQL query with Locking Event monitor data

select participant_no,
varchar(auth_id,10) as auth_id,
varchar(appl_name,20) as appl_name,
varchar(table_name,12) as tabname,
varchar(table_schema,12) as tabschema,
lock_object_type , participant_type ,
lock_status
from lock_participants_mon_locks
where event_type='LOCKTIMEOUT'

PARTICIPANT_NO AUTH_ID APPL_NAME TABNAME TABSCHEMA LOCK_OBJECT_TYPE PARTICIPANT_TYPE LOCK_STATUS

-------------- -------- --------- ------ --------- ---------------- ---------------- -----
1 USER20 db2bp STOCK MUSIC ROW REQUESTER 2
2 INST20 db2bp OWNER 0
1 USER20 db2bp STOCK MUSIC ROW REQUESTER 2
2 INST20 db2bp OWNER 0

4 record(s) selected

Locking and concurrency © Copyright IBM Corporation 2017

Using SQL query with Locking Event monitor data

The data collected using a LOCKING event monitor can be reviewed any time after the
locking event is recorded. This is very useful since many lock related problems occur
sporadically over an extended period of time.
The query uses one of the set of Db2 tables associated with the locking event monitor
to show information about each application involved in lock timeout events.

© Copyright IBM Corp. 1997, 2017 9-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Demonstration 1
Investigating Db2 locking
• Explain how SET ISOLATION can be used to select an isolation level
for an application and the effect that selection can have on results
returned for SQL statements.
• Use the db2pd commands to monitor locks being held by active
applications and current lock wait conditions.
• Monitor a lock wait condition using the Data Server Manager
application.
• Create a LOCKING event monitor to capture diagnostic information
about lock related events.

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Demonstration 1: Investigating Db2 locking

© Copyright IBM Corp. 1997, 2017 9-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Demonstration 1:
Investigating Db2 locking
Purpose:
This demonstration uses several SQL scripts to demonstrate the types of
locks used for processing SQL statements with different application isolation
levels. You will create and analyze a lock wait condition. A LOCKING event
monitor will be used to capture diagnostic data about lock related events.

Task 1. Monitor the locks acquired for a SQL UPDATE.

1. Logon to the Linux system using the user id inst23, 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.
In this section, you will run a SQL script that updates a Db2 table,
[Link], to understand the locks acquired for the UPDATE processing.
You will also observe the effect those locks can have on applications that need
to read the updated rows before the changes are committed.
The Db2 Command Line Processor can execute a series of SQL statements
with auto-commit turned off (the +C option). This allows the locks to be held
longer and is useful to your testing purposes.
You will grant SELECT access to the table [Link] by a user logon
user23. You will use this user to access the table for read purposes while a
portion of the table is locked for updates.
This task will be performed using the Db2 command line processor.
3. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 grant select on table [Link] to user user23
• db2 +C -tvf stock_update.sql
The SQL statements show a sum from the QTY column for a set of rows before
and after the UPDATE processing.

© Copyright IBM Corp. 1997, 2017 9-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

The output will look similar to the following:

SELECT sum(qty) from [Link] where itemno=10
1
-----------
109
1 record(s) selected.

update [Link] set qty = qty + 1 where itemno between 10 and 15

DB20000I The SQL command completed successfully.

SELECT sum(qty) from [Link] where itemno=10

1
-----------
112
1 record(s) selected.
The db2pd command can be used to show the locks currently held by Db2
applications for a database.
4. Issue the following command using the Linux terminal session.
• db2pd -db musicdb -locks | more
The command output will look similar to the following:

Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date

2016-08-23-10.24.39.935175

Locks:
Address TranHdl Lockname Type Mode Sts
Owner Dur HoldCount Att ReleaseFlg rrIID
0x00007FB6E63E6D80 3 090004002A000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6280 3 0900050038000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E6F80 3 0900040028000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6580 3 0900050036000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7200 3 0900040026000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6880 3 0900050034000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7400 3 0900040024000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6B80 3 0900050032000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7600 3 0900040022000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0

© Copyright IBM Corp. 1997, 2017 9-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

0x00007FB6E63E7800 3 0900040020000D000000000052 RowLock ..X G 3

1 0 0x00200000 0x40000000 0
0x00007FB6E63E7C00 3 090004001E000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E7A00 3 090004001C000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E5080 3 0900050041000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E5700 3 090005003F000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E5F00 3 090005003D000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E6080 3 090005003B000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E5600 3 090004002B000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E5500 3 0900050039000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E6E80 3 0900040029000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6380 3 0900050037000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7100 3 0900040027000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63DC200 3 41414141416641647CF81EA4C1 PlanLock ..S G 3
1 0 0x00000000 0x40000000 0
0x00007FB6E63E6680 3 0900050035000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7300 3 0900040025000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E6980 3 0900050033000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7500 3 0900040023000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E5300 3 0900050031000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7700 3 0900040021000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E7900 3 090004001F000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63DD980 3 090004001D000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E5D00 3 0900050042000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63DE100 3 090004001B000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E4E80 3 0900050040000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E5780 3 090005003E000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E4F80 3 090005003C000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0

© Copyright IBM Corp. 1997, 2017 9-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

0x00007FB6E63E6C80 3 090004002C000D000000000052 RowLock ..X G 3

1 0 0x00200000 0x40000000 0
0x00007FB6E63E5180 3 090005003A000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63E7B00 3 09000500000000000000000054 TableLock .IX G 3
1 0 0x00202000 0x40000000 0
0x00007FB6E63DD780 3 09000400000000000000000054 TableLock .IX G 3
1 0 0x00202000 0x40000000 0
5. Review the list of locks that were acquired to execute the SQL UPDATE.
• You should see a series of Exclusive (X) row locks and several table locks.
• You should see two Intent Exclusive (IX) table locks.
The UPDATE SQL statement updated the table [Link], so one Intent
Exclusive (IX) table lock is needed for that table. You defined the table
[Link] as a System period temporal table with a history table of
MUSIC.STOCK_HISTORY. The UPDATE of [Link] needs to update
the system history table, so an additional IX lock is needed for
MUSIC.STOCK_HISTORY.
Task 2. Processing SQL SELECT statements using different
locking isolation levels.
The execution of the stock update script in the previous task acquired a set of
locks that were not released by the Db2 command line processor. You could
use the COMMIT WORK statement to release those locks, but you want to run
several SQL SELECT scripts that use different locking isolation levels to see
how an application might be impacted by locks held by other applications
running at the same time.
You will need a second Db2 command line processor session to be able to start
a second database connection that can execute SQL scripts while the first
session continues to hold its row and table locks. You will connect to the
MUSICDB database using a different system userid, user23, to make it easier
to monitor the locking for each connection.
You will create a LOCKING event monitor to capture information about lock
waits and lock timeouts. On your Windows Database Server, a script file named
create_lock_monitor.sql contains the statements to create a LOCKING event
monitor and to activate the monitor. You will need to update the database
configuration to generate the diagnostic locking data that will be captured.

© Copyright IBM Corp. 1997, 2017 9-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

1. Issue the following series of commands using the Linux terminal session:
• db2 update db cfg using mon_lockwait without_hist
• db2 update db cfg using mon_locktimeout without_hist
• db2 -tvf create_lock_monitor.sql
The command output will look similar to the following:
create event monitor mon_locks for locking write to table autostart
DB20000I The SQL command completed successfully.

set event monitor mon_locks state 1

DB20000I The SQL command completed successfully.

select varchar(tabschema,10) as schema, varchar(tabname,40) as mon_table from

[Link] where evmonname = 'MON_LOCKS'

SCHEMA MON_TABLE
---------- ----------------------------------------
INST23 CONTROL_MON_LOCKS
INST23 LOCK_MON_LOCKS
INST23 LOCK_PARTICIPANTS_MON_LOCKS
INST23 LOCK_PARTICIPANT_ACTIVITIES_MON_LOCKS
INST23 LOCK_ACTIVITY_VALUES_MON_LOCKS

5 record(s) selected.

2. Issue the following series of commands using the Linux terminal session:
• db2 connect to musicdb
• db2 +C -tvf stock_update.sql
3. To start a second Linux terminal session, right-click the empty Linux desktop
and select Open in Terminal.

© Copyright IBM Corp. 1997, 2017 9-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

4. Using the second Linux terminal session, issue the following series of
commands:
• cd $HOME/ddl
• db2 connect to musicdb user user23 using ibm2blue
You will start by running the SQL script, stock_select_ur.sql. The script starts
by setting the special registers CURRENT LOCK TIMEOUT and CURRENT
ISOLATION. The statement SET CURRENT ISOLATION ur sets the locking
isolation level to Uncommitted Read, the lowest level for isolation. This allows
the connection to access data rows updated by other applications that have not
committed those changes.
5. Using the second Linux terminal session, issue the following command:
• db2 -tvf stock_select_ur.sql
The command output will look similar to the following:

set current lock timeout 300

DB20000I The SQL command completed successfully.

set current isolation ur

DB20000I The SQL command completed successfully.

select sum(qty) from [Link] where itemno = 10

1
-----------
115

1 record(s) selected.
The result for the sum(QTY) using isolation level UR reflects the changes made
by the uncommitted UPDATE in the other CLP session.
Next you will run the SQL script, stock_select_cs.sql. The script starts by
setting the special registers CURRENT LOCK TIMEOUT and CURRENT
ISOLATION. The statement SET CURRENT ISOLATION cs, sets the locking
isolation level to Cursor Stability, the default level for isolation. This does not
allow the connection to access data rows updated by other applications that
have not committed those changes, but Db2 can use special log records to
retrieve the data rows contents before the changes were made.

© Copyright IBM Corp. 1997, 2017 9-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

6. Using the second Linux terminal session, issue the following command:
• db2 -tvf stock_select_cs.sql
The command output will look similar to the following:
set current lock timeout 300
DB20000I The SQL command completed successfully.

set current isolation cs

DB20000I The SQL command completed successfully.

select sum(qty) from [Link] where itemno = 10

1
-----------
112

1 record(s) selected.

The result for the sum(QTY) using isolation level CS does not include the
changes made by the uncommitted UPDATE in the other CLP session.
Next you will run the SQL script, stock_select_rs.sql. The script starts by
setting the special registers CURRENT LOCK TIMEOUT and CURRENT
ISOLATION. The statement SET CURRENT ISOLATION rs sets the locking
isolation level to Read Stability. This isolation level requires row locks for any
row of data included in the SQL result. Since the UPDATE executed in the first
CLP session was not committed, the SELECT for that data in this second
session will cause a lock wait condition.
7. Using the second Linux terminal session, issue the following series of
commands:
• db2 connect to musicdb user user23 using ibm2blue
• db2 -tvf stock_select_rs.sql
The SELECT SQL statement cannot complete because row locks are needed
to produce the result that are held by the other CLP session. Right now, it
appears to have been successful.
You can use the db2pd command to look for active lock waits, but you will need
to run the command from the first CLP session.

© Copyright IBM Corp. 1997, 2017 9-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

8. Switching back to the first terminal session, issue the following command:
• db2pd -db musicdb -wlock
The command output will look similar to the following:
Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date
2016-08-23-10.32.18.917229

Locks being waited on :

AppHandl [nod-index] TranHdl Lockname Type Mode Conv
Sts CoorEDU AppName AuthID AppID
33 [000-00033] 3 090004001B000D000000000052 RowLock ..X G
22 db2bp INST23 *LOCAL.inst23.160823142824
51 [000-00051] 13 090004001B000D000000000052 RowLock .NS W
86 db2bp USER23 *LOCAL.inst23.160823143106

The db2pd command output shows that a row lock is held (G) by one user
connection, inst23, but a NS read lock is waiting (W) for the connection user
user23.
You can use the -lock report of db2pd to see the full list of locks held by the two
connections, including the lock that is being waited for.
9. Using the first terminal session, issue the following series of commands:
• db2pd -db musicdb -lock
The command output will look similar to the following:

Database Member 0 -- Database MUSICDB -- Active -- Up 0 days [Link] -- Date

2016-08-23-10.32.40.853187

Locks:
Address TranHdl Lockname Type Mode Sts
Owner Dur HoldCount Att ReleaseFlg rrIID
0x00007FB6E63EC280 3 090004002A000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63EC080 3 0900040028000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63EBE00 3 0900040026000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED600 3 090005000F000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EBC00 3 0900040024000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED400 3 090005000D000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EB800 3 0900040022000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED200 3 090005000B000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0

© Copyright IBM Corp. 1997, 2017 9-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

0x00007FB6E63EBA00 3 0900040020000D000000000052 RowLock ..X G 3

1 0 0x00200000 0x40000000 0
0x00007FB6E63ECF80 3 0900050009000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EB700 3 090004001E000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ECD80 3 0900050007000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC580 3 0900050043000B000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EB400 3 090004001C000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ECB80 3 0900050005000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC980 3 0900050003000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC780 3 0900050001000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC380 3 090004002B000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63EC180 3 0900040029000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63EBF00 3 0900040027000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED700 3 0900050010000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63DD480 3 41414141416641647CF81EA4C1 PlanLock ..S G 3
1 0 0x00000000 0x40000000 0
0x00007FB6E63DAD80 13 41414141416641647CF81EA4C1 PlanLock ..S G 3
1 0 0x00000000 0x40000000 0
0x00007FB6E63EBD00 3 0900040025000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED500 3 090005000E000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EBB00 3 0900040023000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63DAC00 13 02000000030000000100A032D6 VarLock ..S G 3
1 0 0x00000000 0x40000000 0
0x00007FB6E63ED300 3 090005000C000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63DD380 3 0900040021000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ED100 3 090005000A000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EB300 3 090004001F000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ECE80 3 0900050008000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EB600 3 090004001D000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63ECC80 3 0900050006000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0

© Copyright IBM Corp. 1997, 2017 9-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

0x00007FB6E63DCB00 3 090004001B000D000000000052 RowLock ..X G 3

1 0 0x00200000 0x40000000 0
0x00007FB6E63DAE00 13 090004001B000D000000000052 RowLock .NS W 3
0 0 0x00000000 0x00000000 0
0x00007FB6E63ECA80 3 0900050004000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC880 3 0900050002000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC680 3 0900050000000C000000000052 RowLock ..X G 3
1 0 0x00200008 0x40000000 0
0x00007FB6E63EC480 3 090004002C000D000000000052 RowLock ..X G 3
1 0 0x00200000 0x40000000 0
0x00007FB6E63E4C80 8 04000900000000000000000054 TableLock .IX G 8
1 1 0x00203000 0x40000000 0
0x00007FB6E63E8080 9 04000900000000000000000054 TableLock .IX G 9
1 1 0x00203000 0x40000000 0
0x00007FB6E63EB900 3 09000500000000000000000054 TableLock .IX G 3
1 0 0x00202000 0x40000000 0
0x00007FB6E63E4B00 8 04000800000000000000000054 TableLock .IX G 8
1 1 0x00203000 0x40000000 0
0x00007FB6E63E7E80 9 04000800000000000000000054 TableLock .IX G 9
1 1 0x00203000 0x40000000 0
0x00007FB6E63DDC00 3 09000400000000000000000054 TableLock .IX G 3
1 0 0x00202000 0x40000000 0
0x00007FB6E63DAE80 13 09000400000000000000000054 TableLock .IS G 3
1 0 0x00003000 0x00000001 0
0x00007FB6E63E4A80 8 04000700000000000000000054 TableLock .IX G 8
1 1 0x00203000 0x40000000 0
0x00007FB6E63E7E00 9 04000700000000000000000054 TableLock .IX G 9
1 1 0x00203000 0x40000000 0
0x00007FB6E63E4B80 8 04000600000000000000000054 TableLock .IX G 8
1 1 0x00203000 0x40000000 0
0x00007FB6E63E7F00 9 04000600000000000000000054 TableLock .IX G 9
1 1 0x00203000 0x40000000 0
0x00007FB6E63E4C00 8 04000500000000000000000054 TableLock .IX G 8
1 1 0x00203000 0x40000000 0
0x00007FB6E63E7F80 9 04000500000000000000000054 TableLock .IX G 9
1 1 0x00203000 0x40000000 0

The SQL command file included the SET CURRENT LOCK TIMEOUT
statement to limit the time that a SQL statement will wait for a lock, before a
SQL error return code is generated.

© Copyright IBM Corp. 1997, 2017 9-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

10. In the second Linux terminal session, wait for the lock timeout condition to
occur and the Db2 error message to be returned.
The command output will look similar to the following:
set current lock timeout 180
DB20000I The SQL command completed successfully.

set current isolation rs

DB20000I The SQL command completed successfully.

select sum(qty) from [Link] where itemno = 10

SQL0911N The current transaction has been rolled back because of a deadlock
or timeout. Reason code "68". SQLSTATE=40001

Task 3. Monitor a Db2 database for lock wait conditions using

the Data Server Manager.
In this section you use the Data Server Manager to monitor a lock wait condition
for a Db2 database.
You are going to be using the two Linux terminal session sessions that were
opened in the preceding tasks.
• One session uses the user inst23 to run a command file that updates the
[Link] table and holds those locks.
• The second session uses the user user23 to select rows that were locked by
the first connection.
1. Using the first terminal session, issue the following series of commands:
• db2 commit
• db2 connect to musicdb
• db2 +C -tvf stock_update.sql
Next you will run the SQL script, stock_select_rs.sql. Since the UPDATE
executed in the first CLP session was not committed, the SELECT for that data
in this second session will cause a lock wait condition.

© Copyright IBM Corp. 1997, 2017 9-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

2. Using the second Linux terminal session, issue the following series of
commands:
• db2 connect to musicdb user user23 using ibm2blue
• db2 -tvf stock_select_rs.sql
The SELECT SQL statement cannot complete because row locks are needed
to produce the result that are held by the other CLP session.
You will use the Data Server Manager tool to monitor lock wait conditions.
In Firefox, use the bookmark provided or use the URL [Link]
When DSM was installed, a local user id and password were selected to be
associated with the application. For this course the following were configured:
User id: db2admin
Password: ibm2blue
3. Logon to DSM.
4. Click Monitor on the left side of the DSM application.
5. Select Database from the options.
6. Click Locking from the menu options at the top.
The Blocking and Waiting Connections view shows that the user INST23 is
the blocker.
7. Use the arrow next to Blocker to expand the data and show the WAITER,
user23.
8. Select the Locked Objects with Waiting Connections view.
The data shown indicates that a row lock for the [Link] table is the
lock object for an active lock wait.
Wait for the lock timeout condition to occur and the Db2 error message to be
returned for the second CLP session with user USER23.
9. Sign Out to exit the Data Server Manager.

© Copyright IBM Corp. 1997, 2017 9-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Task 4. Analyze the data collected by a LOCKING event

monitor for locking related issues.
Next you will use a SQL script to review the locking information saved by the
LOCKING event monitor.
The file query_lock_events.sql contains the SELECT SQL statements that
use the tables associated with the LOCKING event monitor.
The SQL script has three SQL SELECT statements.
select event_id , event_type, event_timestamp
from lock_mon_locks ;

select participant_no,
varchar(auth_id,10) as auth_id,
varchar(appl_name,20) as appl_name,
varchar(table_name,12) as tabname,
varchar(table_schema,12) as tabschema,
lock_object_type , participant_type , lock_status
from lock_participants_mon_locks
where event_type='LOCKTIMEOUT' ;

select
participant_no, effective_isolation,
varchar(stmt_operation,20) as operation,
varchar(stmt_text,50) as sql_text
from lock_participant_activities_mon_locks
where event_type='LOCKTIMEOUT' ;
The first query uses the LOCK_MON_LOCKS table to show the type of each
locking event and the time stamp when the data was captured. There should be
at least one LOCKTIMEOUT and one or more LOCKWAIT events.
The next query looks at the LOCK_PARTICIPANTS_MON_LOCKS table to see
which user, application and table were associated with the lock timeout.
The third query uses the LOCK_PARTICIPANT_ACTIVITY_MON_LOCKS
table to see the SQL text and isolation level for the application that received the
lock timeout condition.
You should use the SET EVENT MONITOR command to stop collecting the
locking data.

© Copyright IBM Corp. 1997, 2017 9-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

1. Using the first Linux terminal session, issue the following series of
commands:
• db2 commit
• db2 connect to musicdb
• db2 set event monitor mon_locks state 0
• db2 -tvf query_lock_events.sql | more
The command output will look similar to the following:
select event_id , event_type, event_timestamp from lock_mon_locks

EVENT_ID EVENT_TYPE
EVENT_TIMESTAMP
-------------------- -------------------------------------------------------------
------------------------------------------------------------------- --------------
------------
1 LOCKWAIT
2017-08-01-15.43.57.377451
2 LOCKTIMEOUT
2017-08-01-15.46.52.707765
3 LOCKWAIT
2017-08-01-15.48.35.924257
4 LOCKTIMEOUT
2017-08-01-15.51.32.749114

4 record(s) selected.

select participant_no, varchar(auth_id,10) as auth_id, varchar(appl_name,20) as

appl_name, varchar(table_name,12) as tabname, varchar(table_schema,12) as
tabschema, lock_object_type , participant_type , lock_status from
lock_participants_mon_locks where event_type='LOCKTIMEOUT'

PARTICIPANT_NO AUTH_ID APPL_NAME TABNAME TABSCHEMA

LOCK_OBJECT_TYPE PARTICIPANT_TYPE LOCK_STATUS
-------------- ---------- -------------------- ------------ ------------ ---------
----------------------- ---------------- --------------------
1 USER23 db2bp STOCK MUSIC ROW
REQUESTER 2
2 INST23 db2bp - - -
OWNER -
1 USER23 db2bp STOCK MUSIC ROW
REQUESTER 2
2 INST23 db2bp - - -
OWNER -

© Copyright IBM Corp. 1997, 2017 9-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

4 record(s) selected.

select participant_no, effective_isolation, varchar(stmt_operation,20) as

operation, varchar(stmt_text,50) as sql_text from
lock_participant_activities_mon_locks where event_type='LOCKTIMEOUT'

PARTICIPANT_NO EFFECTIVE_ISOLATION OPERATION SQL_TEXT

-------------- ------------------- -------------------- --------------------------
------------------------
1 RS DML, Select (blockab select sum(qty) from
[Link] where itemno = 10
SQL0445W Value "DML, Select (blockable)" has been truncated. SQLSTATE=01004

1 RS DML, Select (blockab select sum(qty) from

[Link] where itemno = 10
SQL0445W Value "DML, Select (blockable)" has been truncated. SQLSTATE=01004

2 record(s) selected with 2 warning messages printed.

Results:
You created and analyzed a lock wait condition. A LOCKING event monitor
was used to capture diagnostic data about lock related events.

© Copyright IBM Corp. 1997, 2017 9-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

Unit summary
• Explain why locking is needed
• List objects that can be locked
• Describe and discuss the various lock modes and their compatibility
• Explain four different levels of data protection
• Set isolation level and lock time out for current activity
• Explain lock conversion and escalation
• Describe the situation that causes deadlocks
• Create a LOCKING EVENT monitor to collect lock related diagnostics
• Set database configuration options to control locking event capture

Locking and concurrency © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 9-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 9 Locking and concurrency

© Copyright IBM Corp. 1997, 2017 9-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Security

Security

Db2 11.1 Administration Workshop for Linux

© Copyright IBM Corporation 2017

Course materials may not be reproduced in whole or in part without the written permission of IBM.
 Unit 10 Security

© Copyright IBM Corp. 1997, 2017 10-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Unit objectives
• Use Db2 access control mechanisms to implement security within the
database
• Explain the tasks performed by the SYSADM user, the SECADM user
and a DBADM user
• Compare the use of database roles to user groups for security
• Describe privileges required for binding and executing an application
package
• Describe the difference between explicit privileges and implicit
privileges
• List the methods for implementing encryption for database connections
• List the advantages of creating a Trusted Context for a three-tier
application system

Security © Copyright IBM Corporation 2017

Unit objectives

© Copyright IBM Corp. 1997, 2017 10-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Authentication versus authorization

• Db2 uses a combination of: Authorization
 External security service Does Jon have
authorization to
 Internal access control information Mytable
perform SELECT
from MYTABLE?
• Authentication
 Identify the user
Authentication
− Check entered username and SELECT * FROM mytable Is this the right
password password for Jon?

 User/Password maintained by a
security facility outside of Db2
• Authorization: CONNECT TO sample
USER jon using pwd
 Check if authenticated user may
perform requested operation
 Performed by Db2 facilities
− Information
stored in Db2 catalog,
DBM configuration file
Security © Copyright IBM Corporation 2017

Authentication versus authorization

Access to an instance or a database first requires that the user be authenticated. The
authentication type for each instance determines how and where a user will be verified.
The authentication type is stored in the database manager configuration file at the
server. It is initially set when the instance is created. There is one authentication type
per instance, which covers access to that database server and all the databases under
its control.
The following authentication types are provided:
• SERVER: Specifies that authentication occurs on the server using local operating
system security. If a user ID and password are specified during the connection or
attachment attempt, they are compared to the valid user ID and password
combinations at the server to determine if the user is permitted to access the
instance. This is the default security mechanism.
Note:The server code detects whether a connection is local or remote. For local
connections, when authentication is SERVER, a user ID and password are not
required for authentication to be successful.

© Copyright IBM Corp. 1997, 2017 10-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• SERVER_ENCRYPT: Specifies that the server accepts encrypted SERVER

authentication schemes. If the client authentication is not specified, the client is
authenticated using the method selected at the server.
If the client authentication is SERVER, the client is authenticated by passing the
user ID and password to the server. If the client authentication is
SERVER_ENCRYPT, the client is authenticated by passing an encrypted user ID
and encrypted password.
If SERVER_ENCRYPT is specified at the client and SERVER is specified at the
server, an error is returned because of the mismatch in the authentication levels.
• CLIENT: Specifies that authentication occurs on the database partition where the
application is invoked using operating system security. The user ID and password
specified during a connection or attachment attempt are compared with the valid
user ID and password combinations on the client node to determine if the user ID
is permitted access to the instance. No further authentication will take place on
the database server. This is sometimes called single signon. If the user performs
a local or client login, the user is known only to that local client workstation.
• KERBEROS: Used when both the Db2 client and server are on operating
systems that support the Kerberos security protocol. The Kerberos security
protocol performs authentication as a third-party authentication service by using
conventional cryptography to create a shared secret key. This key becomes a
user’s credential and is used to verify the identity of users during all occasions
when local or network services are requested. The key eliminates the need to
pass the user name and password across the network as clear text. Using the
Kerberos security protocol enables the use of a single sign-on to a remote Db2
server.
Kerberos authentication works on Windows as follows:
1. A user logging on to the client machine using a domain account
authenticates to the Kerberos key distribution center (KDC) at the domain
controller. The key distribution center issues a ticket-granting ticket (TGT) to
the client.
2. During the first phase of the connection, the server sends the target principal
name, which is the service account name for the Db2 server service, to the
client. Using the server’s target principal name and the target-granting ticket,
the client requests a service ticket from the ticket-granting service (TGS)
which also resides at the domain controller. If both the client’s ticket-granting
ticket and the server’s target principal name are valid, the TGS issues a
service ticket to the client.
3. The client sends this service ticket to the server via the communication
channel (which might be, as an example, TCP/IP).

© Copyright IBM Corp. 1997, 2017 10-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

4. The server validates the client’s server ticket. If the client’s service ticket is
valid, then the authentication is completed.
It is possible to catalog the databases on the client machine and explicitly
specify the Kerberos authentication type with the server’s target principal
name. In this way, the first phase of the connection can be bypassed.
If a user ID and a password are specified, the client will request the ticket-
granting ticket for that user account and use it for authentication.
• KRB_SERVER_ENCRYPT: Specifies that the server accepts KERBEROS
authentication or encrypted SERVER authentication schemes. If the client
authentication is KERBEROS, the client is authenticated using the Kerberos
security system. If the client authentication is not KERBEROS, or the Kerberos
authentication service is not available, then the system authentication type is
equivalent to SERVER_ENCRYPT.
Note:The Db2 database system provides support for the Kerberos authentication
protocol on AIX, Solaris, Linux IA32 and AMD64, and Windows operating
systems. Also, both client and server machines must either belong to the same
Windows domain or belong to trusted domains. This authentication type should
be used when the server supports Kerberos and some, but not all, of the client
machines support Kerberos authentication.
Control login restrictions of connecting user on AIX server
By default, when a user is authenticated on an AIX server, Db2 checks the connecting
user’s local login restrictions before allowing the connection to proceed. The
Db2LOGINRESTRICTIONS registry variable permits Db2 to enforce alternative modes
of login restrictions.
If DB2LOGINRESTRICTIONS is not set, the default value is LOCAL.
The variable can be set to the following values:
• REMOTE: will only enforce remote login restrictions
• SU: Db2 will only enforce su restrictions (su in AIX is changing the ID during a
session)
• NONE: Db2 will not enforce any particular mode of login restrictions
• LOCAL: Db2 will only enforce local login restrictions
In all cases, Db2 still checks for the following error conditions:
• Expired account
• Locked account
• Invalid user

© Copyright IBM Corp. 1997, 2017 10-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

SYSADM authorization
• System Administrators: SYSADM
 Defined by SYSADM_GROUP in Instance (DBM) configuration
 System related functions:
− Update Instance DBM and Database Configurations
− Create or Drop a database
− Create, alter or drop table spaces
− Perform backup and recovery tasks
− Monitor performance and handle problem determination (db2pd)
− Start and Stop the instance
 No implied access to data
− Could be granted DATAACCESS by SECADM
 No implied ability to Grant and Revoke database and object level
privileges
− Could be granted ACCESSCTRL by SECADM

Security © Copyright IBM Corporation 2017

SYSADM authorization
A SYSADM user is defined using a named user group, SYSADM_GROUP, in the
instance configuration. A user included in the SYSADM group can perform the following
system administration tasks:
• Update the database and instance configurations
• Create a new database or drop an existing database
• Manage table spaces using the CREATE, ALTER or DROP statements
• Run the database recovery commands like BACKUP, RESTORE,
ROLLFORWARD and RECOVER
• Monitor instance level activity using GET SNAPSHOT commands and run the
db2pd command
• Control the instance including starting (db2start) and stopping (db2stop)
commands
Having SYSADM authority does not automatically allow the user to access data based
on tables or views. The DATAACCESS privilege could be granted by a SECADM user
to permit data access that was inherent in previous releases.

© Copyright IBM Corp. 1997, 2017 10-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

The SYSADM user also does not automatically have the authority to grant and revoke
database or object level privileges for any database in the instance. The
ACCESSCTRL privilege could be granted by a SECADM user to permit granting or
revoking privileges that were inherent in previous releases.
A SYSADM user does not have the authority to grant either DBADM or SECADM
authority to another user.
The SYSCTRL_GROUP, SYSMAINT_GROUP and SYSMON_GROUP user groups
were available to permit specific subsets of the SYSADM command authority.
In order to allow a system administrator to create a Db2 database and begin performing
any required task for that database, the SYSADM user that creates a new Db2
database is initially granted SECADM and DBADM authorities for that database
including the ACCESSCTRL and DATAACCESS authorities.

© Copyright IBM Corp. 1997, 2017 10-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

DBADM authorization
• Database Administrator: DBADM
 Can only be granted or revoked by the SECADM authority
 Can be granted to a user, a group, or a role but not PUBLIC
 Access to all data based on options WITH DATAACCESS
(default) or WITHOUT DATAACCESS
 Ability to Grant and Revoke database and object level privileges based on
options WITH ACCESSCTRL (default) or WITHOUT ACCESSCTRL
 Create and manage database event monitors
 Ability to run data-oriented utilities like REORG and RUNSTATS
 SQLADM authority and WLMADM authority are subsets of the DBADM
authority

Security © Copyright IBM Corporation 2017

DBADM authorization
DBADM authority can only be granted or revoked by the security administrator (who
holds SECADM authority) and can be granted to a user, a group, or a role. PUBLIC
cannot obtain the DBADM authority either directly or indirectly.
DBADM authority is an administrative authority for a specific database. The database
administrator possesses the privileges required to create objects and issue some
database commands. In addition, users with DBADM authority have SELECT privilege
on the system catalog tables and views, and can execute all system-defined Db2
routines, except audit routines.
Holding the DBADM authority for a database allows a user to perform these actions on
that database:
• Create, alter, and drop non-security related database objects
• Read log files
• Create, activate, and drop event monitors
• Query the state of a table space
• Update log history files
• Quiesce a table space

© Copyright IBM Corp. 1997, 2017 10-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• Reorganize a table
• Collect catalog statistics using the RUNSTATS utility
SQLADM authority and WLMADM authority are subsets of the DBADM authority.
WLMADM authority has the additional ability to grant the USAGE privilege on
workloads.

© Copyright IBM Corp. 1997, 2017 10-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

SECADM authorization
• Security Administrators: SECADM
 Must be granted by a SECADM user at the database level
 Can be granted to a user, a group, or a role
 PUBLIC cannot obtain the SECADM authority directly or indirectly
 The instance owner does not have SECADM authority by default
 Required to implement and manage security features:
− Label Based Access Control
− Define and manage database roles
− Database level audit management
− Trusted Contexts for three tiered applications
− Row and Column Access controls
 Has the ability to SELECT from the catalog tables and catalog views,
but cannot access data stored in user tables.
 Ability to Grant and Revoke database and object level privileges
 Ability to grant ACCESSCTRL, DATAACCESS, DBADM to users,
groups, or roles
 The creator of a database is the initial SECADM user for the new database
Security © Copyright IBM Corporation 2017

SECADM authorization
The SECADM authority is the primary security administration authority for a specific
database. This authority allows you to create and manage security-related database
objects and to grant and revoke all database authorities and privileges. Additionally, the
security administrator can execute, and manage who else can execute, the audit
system routines.
SECADM authority has the ability to SELECT from the catalog tables and catalog
views, but cannot access data stored in user tables.
SECADM authority can be granted only by the security administrator (who holds
SECADM authority) and can be granted to a user, a group, or a role. PUBLIC cannot
obtain the SECADM authority directly or indirectly.
SECADM authority gives a user the ability to perform the following operations:
• Create, alter, comment on, and drop:
• Audit policies
• Security label components
• Security policies
• Trusted contexts
• Manage Row and Column access controls

© Copyright IBM Corp. 1997, 2017 10-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• Create, comment on, and drop:

• Roles
• Security labels
• Grant and revoke database privileges and authorities
• Execute the following audit routines to perform the specified tasks:
• The SYSPROC.AUDIT_ARCHIVE stored procedure and table function
archive audit logs.
• The SYSPROC.AUDIT_LIST_LOGS table function allows you to locate logs of
interest.
• The SYSPROC.AUDIT_DELIM_EXTRACT stored procedure extracts data
into delimited files for analysis. Also, the security administrator can grant and
revoke EXECUTE privilege on these routines, therefore enabling the security
administrator to delegate these tasks, if desired. Only the security
administrator can grant EXECUTE privilege on these routines. EXECUTE
privilege WITH GRANT OPTION cannot be granted for these routines
(SQLSTATE 42501).
• Use of the AUDIT statement to associate an audit policy with a particular
database or database object at the server
• Use of the TRANSFER OWNERSHIP statement to transfer objects not owned by
the authorization ID of the statement
Note: No other authority gives these abilities. The instance owner does not have
SECADM authority by default. The creator of a database is the initial SECADM user
for the new database. Only the security administrator has the ability to grant other
users, groups, or roles the ACCESSCTRL, DATAACCESS, DBADM, and SECADM
authorities.

© Copyright IBM Corp. 1997, 2017 10-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Other limited Security authorizations (1 of 2)

• These Authorizations must be granted by a SECADM User:
 ACCESSCTRL:
− Authority required to grant and revoke privileges on objects within a specific
database
− ACCESSCTRL authority has no inherent privilege to access data stored in tables,
except the catalog tables and views
 DATAACCESS:
− Authority that allows access to data within a specific database
− It can be granted to a user, a group, or a role

Security © Copyright IBM Corporation 2017

Other limited Security authorizations

There are several additional administrator authorizations that allow selected privileges
to be granted. These can be used to allow different individuals or groups to perform
certain administrative roles without having additional unnecessary privileges.
ACCESSCTRL authority is the authority required to grant and revoke privileges on
objects within a specific database.
ACCESSCTRL authority has no inherent privilege to access data stored in tables,
except the catalog tables and views.
ACCESSCTRL authority can only be granted by the security administrator (who holds
SECADM authority).
It can be granted to a user, a group, or a role. PUBLIC cannot obtain the
ACCESSCTRL authority either directly or indirectly.

© Copyright IBM Corp. 1997, 2017 10-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

ACCESSCTRL authority gives a user the ability to perform the following operations:
• Grant and revoke the following administrative authorities, EXPLAIN, SQLADM
and WLMADM
• Grant and revoke the following database authorities, BINDADD, CONNECT,
CREATETAB, CREATE_EXTERNAL_ROUTINE,
CREATE_NOT_FENCED_ROUTINE, IMPLICIT_SCHEMA, LOAD and
QUIESCE_CONNECT
Grant and revoke all privileges on the following objects, regardless who granted the
privilege:
• Global Variable
• Index
• Nickname
• Package
• Routine (except audit routines)
• Schema
• Sequence
• Server
• Table
• Table Space
• View
• XSR Objects
• SELECT privilege on the system catalog tables and views
This authority is a subset of security administrator (SECADM) authority.
DATAACCESS is the authority that allows access to data within a specific database.
DATAACCESS authority can be granted only by the security administrator (who holds
SECADM authority).
It can be granted to a user, a group, or a role. PUBLIC cannot obtain the
DATAACCESS authority either directly or indirectly.

© Copyright IBM Corp. 1997, 2017 10-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

For all tables, views, materialized query tables, and nicknames it gives these authorities
and privileges:
• LOAD authority on the database
• SELECT privilege (including system catalog tables and views)
• INSERT privilege
• UPDATE privilege
• DELETE privilege
In addition, DATAACCESS authority provides the following privileges:
• EXECUTE on all packages
• EXECUTE on all routines (except audit routines)

© Copyright IBM Corp. 1997, 2017 10-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Other limited Security authorizations (2 of 2)

• These Authorizations can be granted by a SECADM User or a user
with ACCESSCTRL authority:
 SQLADM: The authority required to monitor and tune SQL statements
 EXPLAIN: Authority required to Explain query plans without gaining access
to data for a specific database
− EXPLAIN authority is a subset of the SQLADM authority
 WLMADM: Authority required to manage workload objects for a specific
database:
− Allowsyou to create, alter, drop, comment on, and grant and revoke access to
workload manager objects
− Subset of the database administrator authority, DBADM

Security © Copyright IBM Corporation 2017

SQLADM authority:
• The authority required to monitor and tune SQL statements.
• A subset of the database administrator (DBADM) authority.
• Can be granted by the security administrator (who holds SECADM authority) or a
user who possesses ACCESSCTRL authority.
• Can be granted to a user, a group, a role, or to PUBLIC.
• Gives a user the ability to perform the following functions:
• Execution of the following SQL statements:
• CREATE and DROP EVENT MONITOR
• EXPLAIN
• FLUSH EVENT MONITOR
• FLUSH OPTIMIZATION PROFILE CACHE
• FLUSH PACKAGE CACHE
• PREPARE
• REORG INDEXES/TABLE

© Copyright IBM Corp. 1997, 2017 10-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• RUNSTATS
• SET EVENT MONITOR STATE
• Execution of certain clauses of the following workload manager SQL
statements.
• SELECT privilege on the system catalog tables and views
• EXECUTE privilege on all system-defined Db2 routines (except audit routines)
EXPLAIN authority
• Authority required to explain query plans without gaining access to data for a
specific database.
• A subset of the database administrator authority and has no inherent privilege to
access data stored in tables.
• Can be granted by the security administrator (who holds SECADM authority) or
by a user who possesses ACCESSCTRL authority.
• Can be granted to a user, a group, a role, or to PUBLIC. It gives the ability to
execute the following SQL statements:
• EXPLAIN
• PREPARE
• DESCRIBE on output of a SELECT statement or of an XQuery statement
• EXPLAIN authority also provides EXECUTE privilege on the system-defined
explain routines.
• EXPLAIN authority is a subset of the SQLADM authority.
WLMADM authority is the authority required to manage workload objects for a specific
database.
This authority allows you to create, alter, drop, comment on, and grant and revoke
access to workload manager objects.
WLMADM authority can be granted by the security administrator (who holds SECADM
authority) or a user who possesses ACCESSCTRL authority. WLMADM authority can
be granted to a user, a group, a role, or to PUBLIC.
WLMADM authority is a subset of the database administrator authority, DBADM.

© Copyright IBM Corp. 1997, 2017 10-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Possible methods to administer Db2 security

One
SYSADM
User
Database creator also
Holds SECADM and DBADM

Individual Users with

Distinct Authority
A SYSADM user manages the System
A DBADM user manages the data
A SECADM user manages database security
Groups of Users with Distinct Authorities
Multiple Users defined in SYSADM_GROUP
SECADM granted to multiple users or a role
DBADM granted to multiple users or a role WITHOUT
ACCESSCTRL
Security © Copyright IBM Corporation 2017

Possible methods to administer Db2 security

There are many ways to administer Db2 security for a database.
For simple environments, a single user logon could hold all of the privileges needed to
perform any database related task. That user could be a SYSADM user, performing all
system level tasks. If that user creates a database, the userid will also be automatically
granted SECADM authority for the database and DBADM authority. This would allow
the one user to manage the database system, grant and revoke privileges and access
all of the data in the database.
In some cases, there might be a need to implement separate privileges for individual
users.
One user perform the system level functions as SYSADM, but not have access to data
or grant database permissions.
Another user might manage security as the SECADM for that database, granting any
privilege needed to support the applications, but not having access to data.
A third user might work as an application DBA using the DBADM authority to run utilities
and access data but lack the authority to grant privileges or perform system level
commands.

© Copyright IBM Corp. 1997, 2017 10-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

For larger environments the system administrator (SECADM), security administrator

(SECADM) and DBADM authorities could be set up using groups or roles allowing
individuals to be easily assigned and reassigned authorities based on current projects
and responsibilities.

© Copyright IBM Corp. 1997, 2017 10-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Separating database security privileges

• Assume the SYSADM user SYSA1 creates a new database TEST1,
during CREATE DATABASE processing:
 SYSA1 is granted SECADM
 SYSA1 is granted DBADM with ACCESSCTRL and DATAACCESS
• The user SECA1 needs to manage all security authorizations:
 As the only SECADM user SYSA1 must grant SECADM to SECA1
− GRANT SECADM ON DATABASE to user SECA1
 User SECA1 can now revoke the extra privileges from SYSA1
− REVOKE SECADM on database from user SYSA1
− REVOKE ACCESSCTRL,DATAACCESS on database
− from user SYSA1
• The user APPDBA1 needs to access and manage data objects
in the new database but will not manage security privileges
 User SECA1 must grant user APPDBA1 the required access privileges
− GRANT DBADM WITHOUT ACCESSCTRL on database to user APPDBA1
Security © Copyright IBM Corporation 2017

Separating database security privileges

It is possible to separate the database security privileges in a way that allows each
person to perform a portion of the administrative work without having unnecessary
privileges.
Assume that a SYSADM user with a logon id of SYSA1 creates a new Db2 database
named TEST1. During database creation Db2 would automatically grant SECADM and
DBADM with ACCESSCTRL and DATAACCESS to the SYSA1 user logon.
If all security administration work for the TEST1 database needs to be performed by
another user SECA1, the user SYSA1, as the initial SECADM user for the database
can grant SECADM to the SECA1 user. At this point either SYSA1 or SECA1 could
grant or revoke any privilege for the TEST1 database.
The user SECA1 can now revoke the database authorities from SYSA1 that are not
needed to perform the system tasks, which could include SECADM, ACCESSCTRL
and DATAACCESS.
The following statements could be used:
REVOKE SECADM on database from user SYSA1
REVOKE ACCESSCTRL,DATAACCESS on database from user SYSA1

© Copyright IBM Corp. 1997, 2017 10-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

If a user logon id of APPDBA1 needs to access and manage any data object in the
TEST1 database but that user will not need any authority to grant privileges the user
SECA1 can grant the application DBA the necessary authority using the following
statement:
GRANT DBADM WITHOUT ACCESSCTRL on database to user APPDBA1

© Copyright IBM Corp. 1997, 2017 10-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Db2 Security privilege hierarchies

Instance Level – defined in DBM CFG Table level privileges
 SYSADM_GROUP  Control
– SYSCTRL_GROUP – ALL
 SYSMAINT_GROUP  ALTER
– SYSMON_GROUP  SELECT
 INSERT
Database Level Task Authorities
 UPDATE
 SECADM
 DELETE
– ACCESSCTRL
 INDEX
 DATAACCESS
 REFERENCES
 DBADM
– WLMADM View level privileges For Routine
 Control Function or Method
– LOAD
– ALL  EXECUTE
– SQLADM
– EXPLAIN  SELECT
 INSERT
 DELETE Tablespace
Database level privileges  UPDATE  USE
 BINDADD
 CONNECT
 CREATETAB Package privileges Schema level
 Control privileges
 CREATE_EXTERNAL_ROUTINE
– BIND  ALTERIN
 CREATE_NOT_FENCED_ROUTINE
– EXECUTE  CREATEIN
 IMPLICIT_SCHEMA
 DROPIN
 QUIESCE_CONNECT
 CREATE_SECURE_OBJECTS
Security © Copyright IBM Corporation 2017

Db2 Security privilege hierarchies

The instance configuration allows groups of users to be designated for SYSADM,
SYSCTRL, SYSMAINT or SYSMON authority. These would apply to any database in
the instance.
The SECADM, ACCESSCTRL, DATAACCESS, DBADM, WLMADM, LOAD, SQLADM
and EXPLAIN privileges can be granted for each database.
The database privileges can also be granted:
• BINDADD
• CONNECT
• CREATETAB
• CREATE_EXTERNAL_ROUTINE
• CREATE_NOT_FENCED_ROUTINE
• IMPLICIT_SCHEMA
• QUIESCE_CONNECT
The visual shows the privileges that can be granted for Db2 tables, views, schemas,
packages, routines, functions, methods and table spaces.

© Copyright IBM Corp. 1997, 2017 10-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

GRANT statement: Table/view privileges syntax

PRIVILEGES

GRANT ALL
,

ALTER
CONTROL
DELETE
INDEX
INSERT
REFERENCES
,
( column-name )
SELECT
UPDATE
,
( column-name )

TABLE ,

ON table-name TO authorization-name
USER
view-name GROUP
ROLE
PUBLIC

WITH GRANT OPTION

Security © Copyright IBM Corporation 2017

GRANT statement: Table/view privileges syntax

The visual shows the syntax for granting privileges for tables and views.

© Copyright IBM Corp. 1997, 2017 10-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Using Database Roles for Security

• Database Roles are created and managed by a SECADM user for
each database
• Database Roles can be granted to a user, a group , to public or to
another role (role hierarchy)
• Access privileges based on roles can be used to create:
 Packages containing static SQL
 Views
 Materialized query tables (MQT)
 Triggers
 SQL Routines
• Roles can be used to define security for a Trusted Context used
for 3-tiered application systems
• Role definitions can be selected from System Catalog tables
• Database Role definitions can be captured using db2look
Security © Copyright IBM Corporation 2017

Using Database Roles for Security

Roles compared to groups
Privileges and authorities granted to groups are not considered when creating views,
materialized query tables (MQTs), SQL routines, triggers, and packages containing
static SQL. Avoid this restriction by using roles instead of groups.
Roles allow users to create database objects using their privileges acquired through
roles, which are controlled by the Db2 database system. Groups and users are
controlled externally from the Db2 database system, for example, by an operating
system or an LDAP server.

© Copyright IBM Corp. 1997, 2017 10-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Using System Groups for Security

• Groups are lists of users created and managed at the operating
system level by a system administrator
• Groups could be defined and stored on a LDAP server
• Access privileges granted through a group CAN NOT be used to
create:
 Packages containing static SQL
 Views
 Materialized query tables (MQT)
 Triggers
 SQL Routines

Security © Copyright IBM Corporation 2017

Using System Groups for Security

Groups provide a convenient means of performing authorization for a collection of users
without having to grant or revoke privileges for each user individually. Unless otherwise
specified, group authorization names can be used anywhere that authorization names
are used for authorization purposes.
In general, group membership is considered for dynamic SQL and non-database object
authorizations (such as instance level commands and utilities), but is not considered for
static SQL. The exception to this general case occurs when privileges are granted to
PUBLIC: these are considered when static SQL is processed.
Specific cases where group membership does not apply are noted throughout the Db2
documentation, where applicable.

© Copyright IBM Corp. 1997, 2017 10-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Example of using Roles to manage authorizations

• Mary, a SECADM user, creates a new role developer.
 create role developer
• Mary grants the new developer role to two programmers, John and
Carol:
 grant role developer to user john, user carol;
• Mary or a user with ACCESSCTRL can grant
access to some tables and views to the developer role:
 grant all on table [Link] to role developer ;
grant select on table [Link] to role developer ;
• If Carol moves to the software testing department, the security
administrator, Mary, can remove Carol from the developer role.
 revoke role developer from user carol;

Security © Copyright IBM Corporation 2017

Example of using Roles to manage authorizations

The following example shows how a database role could be defined and utilized to
manage security privileges.
1. Mary, a SECADM user, creates a new role developer, using the following
statement:
create role developer
2. Next, Mary grants the new developer role to two programmers, John and Carol:
grant role developer to user john, user carol;
3. Mary or a user with ACCESSCTRL can now grant access to some tables or
views to the developer role:
grant all on table [Link] to role developer ;grant
select on table [Link] to role developer ;
4. If Carol moves to the software testing department, the security administrator,
Mary, can remove Carol from the developer role:
revoke role developer from user carol;
If Mary tries to access database objects based on privileges that had been granted to
the developer role, those statements would fail.

© Copyright IBM Corp. 1997, 2017 10-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Controlling use of schemas

• Named collection of objects
• Forms high-order part of objects with a two part name, for example,
MEL.T1
• User with DBADM authority creates schema PAY for user MEL
 CREATE SCHEMA PAY AUTHORIZATION MEL
• Mel can create objects in schema pay
 CREATE TABLE PAY.T1 (COL1 INT)
• Mel can grant privileges to other users:
 GRANT CREATEIN ON SCHEMA PAY TO USER CAL
 GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA PAY TO GROUP
G1 WITH GRANT OPTION
• Achieving greater schema control:
 REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC
 GRANT IMPLICIT_SCHEMA ON DATABASE TO USER JON
Security © Copyright IBM Corporation 2017

Controlling use of schemas

A schema can be defined whenever it is desirable to group a set of objects. This
grouping might be based on objects for such things as an application, a group of
people, or an individual user. Other controlling mechanisms, such as Roles and Trusted
Context will be covered a bit later in the unit.
The schema is defined explicitly using the CREATE SCHEMA statement. An option
(AUTHORIZATION) on the CREATE SCHEMA statement allows owner specification at
the time the schema is created. A schema is defined to have an owner. The owner of
the schema is given the privilege to create objects using the schema name as the
object qualifier and to drop any objects that are defined in the schema (regardless of
definer). The schema owner also has the privilege to grant the privilege to create
objects in the schema or the privilege to drop objects from the schema to other users.
This means that the schema owner has the ability to manage objects in the schema
and might grant similar ability to manage those objects to others.
When a new database is created, PUBLIC is given IMPLICIT_SCHEMA database
authority. With this authority, any user can create a schema by creating an object and
specifying a schema name that does not already exist. SYSIBM becomes the owner of
the implicitly created schema and PUBLIC is given the privilege to create objects in this
schema.

© Copyright IBM Corp. 1997, 2017 10-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

If control of who can implicitly create schema objects is required for the database,
IMPLICIT_SCHEMA database authority should be revoked from PUBLIC. Once this is
done, there are only three ways that a schema object is created:
• Any user can create a schema using their own authorization name on a
CREATE SCHEMA statement.
• Any user with DBADM authority can explicitly create any schema which does not
already exist, and can optionally specify another user as the owner of the
schema.
• Any user with DBADM authority has IMPLICIT_SCHEMA database authority
(independent of PUBLIC) so that they can implicitly create a schema with any
name at the time they are creating other database objects.
SYSIBM becomes the owner of the implicitly created schema and PUBLIC has the
privilege to create objects in the schema.
A user always has the ability to explicitly create their own schema using their own
authorization name.

© Copyright IBM Corp. 1997, 2017 10-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Protecting resources through programs

UNIT TEST
PGM XX
CLP
DELETE
FUNCTION
FROM
EXEC SQL TEST
PAYROLL
DELETE FROM
PROMOTION
PAYROLL
WHERE ID=
HOSTV PRODUCTION

? BOB

GRANT EXECUTE ON PACKAGE XX TO BOB

Security © Copyright IBM Corporation 2017

Protecting resources through programs

An individual can EXECUTE a package without having the authority for the underlying
SQL statements.
Programs can be coded, tested, and installed to perform database tasks on behalf of
the program executor.
The authority to EXECUTE a program which performs some SQL statement does not
imply authority to perform the same SQL in an ad hoc environment, such as CLP or
using tools like IBM Data Studio.

© Copyright IBM Corp. 1997, 2017 10-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Privileges granted during CREATE DATABASE (1 of 2)

• CREATE DATABASE requires user to be in SYSADM_GROUP or
SYSCTRL_GROUP in DBM CFG
• User who creates a database is granted:
 ACCESSCTRL
 DATAACCESS
 DBADM
 SECADM

Security © Copyright IBM Corporation 2017

Privileges granted during CREATE DATABASE

Default privileges granted on creating a database
When you create a database, default database level authorities and default object level
privileges are granted to you within that database.
The authorities and privileges that you are granted are listed according to the system
catalog views where they are recorded:
• [Link]
The database creator is granted the following authorities:
• ACCESSCTRL
• DATAACCESS
• DBADM
• SECADM

© Copyright IBM Corp. 1997, 2017 10-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Privileges granted during CREATE DATABASE (2 of 2)

• If RESTRICTIVE option is NOT specified for CREATE DATABASE
then by default the following privileges are granted to PUBLIC:
 CREATETAB
 BINDADD
 CONNECT
 IMPLICIT_SCHEMA
 EXECUTE with GRANT on all functions and procedures in schemas SYSPROC and SQLJ
 BIND on all packages created in the NULLID schema
 EXECUTE on all packages created in the NULLID schema
 CREATEIN on schema SQLJ and NULLID
 USE on table space USERSPACE1
 SELECT access to the SYSIBM,SYSCAT and SYSSTAT catalog tables and views
 UPDATE access to the SYSSTAT catalog views
 USAGE privilege on SYSDEFAULTUSERWORKLOAD for workload management

Security © Copyright IBM Corporation 2017

In a non-restrictive database, the special group PUBLIC is granted the following

authorities:
• CREATETAB
• BINDADD
• CONNECT
• IMPLICIT_SCHEMA
• EXECUTE with GRANT on all functions and procedures in schemas SYSPROC
and SQLJ
• BIND on all packages created in the NULLID schema
• EXECUTE on all packages created in the NULLID schema
• CREATEIN on schema SQLJ and NULLID
• USE on table space USERSPACE1
• SELECT access to the SYSIBM,SYSCAT and SYSSTAT catalog tables and
views
• UPDATE access to the SYSSTAT catalog views
• USAGE privilege on SYSDEFAULTUSERWORKLOAD for workload
management

© Copyright IBM Corp. 1997, 2017 10-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Implicitly granted privileges

• GRANT DBADM:
 These authorities are part of DBADM authority. When DBADM authority is
revoked in these authorities are lost.
− BINDADD
− CONNECT
− CREATETAB
− CREATE_EXTERNAL_ROUTINE
− CREATE_NOT_FENCED_ROUTINE
− IMPLICIT_SCHEMA
− QUIESCE_CONNECT
− LOAD
• Create object (table, index, package)
 Internal GRANT of CONTROL to object creator.
• Create view
 Internal GRANT to intersection of creator's privileges on base tables to view
creator.

Security © Copyright IBM Corporation 2017

Implicitly granted privileges

In Db2 these authorities are part of DBADM authority. When DBADM authority is
revoked these authorities are lost.
• BINDADD
• CONNECT
• CREATETAB
• CREATE_EXTERNAL_ROUTINE
• CREATE_NOT_FENCED_ROUTINE
• IMPLICIT_SCHEMA
• QUIESCE_CONNECT
• LOAD
When a user creates a table, Db2 automatically grants the control privilege to the
creator.
When a user creates a view, Db2 will only grant privileges on the view that are held on
the base tables. If a user holds the select authority on a table, and they create a view
based on that table, they would still be limited to select access through that view.

© Copyright IBM Corp. 1997, 2017 10-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

System Catalog views for authorizations (1 of 2)

• [Link] - Lists the column privileges
• [Link] - Lists the database privileges
• [Link] - Lists the index privileges
• [Link] - Lists the module privileges
• [Link] - Lists the package privileges
• [Link] - Lists the server privilege
• [Link] - Lists the role privileges
• [Link] - Lists the routine (functions, methods, and
stored procedures) privileges

Security © Copyright IBM Corporation 2017

System Catalog views for authorizations

The visual lists the system catalog views that contain information about privileges
granting on various database objects.
If you do not want any user to be able to know what objects other users have access to,
you should consider restricting access to these catalog views.
Because the system catalog views describe every object in the database, if you have
sensitive data, you might want to restrict their access.
The following authorities have SELECT privilege on all catalog tables:
• ACCESSCTRL
• DATAACCESS
• DBADM
• SECADM
• SQLADM

© Copyright IBM Corp. 1997, 2017 10-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

In addition, the following instance level authorities have the ability to select from
[Link], [Link],
[Link], [Link], and [Link]:
• SYSADM
• SYSCTRL
• SYSMAINT
• SYSMON

© Copyright IBM Corp. 1997, 2017 10-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

System Catalog views for authorizations (2 of 2)

• [Link] - Lists the schema privileges
• [Link] - Lists the sequence privileges
• [Link] - Lists the authorization IDs for
which another authorization ID can act as a surrogate.
• [Link] - Lists the table and view privileges
• [Link] - Lists the table space privileges
• [Link] - Lists the variable privileges
• [Link] - Lists the workload privileges
• [Link] - Lists the XSR object privileges

Security © Copyright IBM Corporation 2017

© Copyright IBM Corp. 1997, 2017 10-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Summary of row and column access control

• Allows access only to subset of data useful for job task
 Leverages existing groups and roles
• Same output regardless of access method
 Data Studio, views, applications, etc.
• Data-centric and transparent to client application
• Less powerful mechanism than LBAC, but simpler to implement
• Ideal for
 Commercial applications
 Function-specific access control (vs. hierarchical)
 Use in compliance
• SECADM is the sole manager of security policy
• Two sets of rules
 Row access is restricted via permissions
 Column access is restricted via masks
Security © Copyright IBM Corporation 2017

Summary of row and column access control

Row and column access control (RCAC) overview
Db2 Version 10.1 introduced row and column access control (RCAC), as an additional
layer of data security. Row and column access control is sometimes referred to as fine-
grained access control or FGAC. RCAC controls access to a table at the row level,
column level, or both. RCAC can be used to complement the table privileges model.
To comply with various government regulations, you might implement procedures and
methods to ensure that information is adequately protected. Individuals in your
organization are permitted access to only the subset of data that is required to perform
their job tasks. For example, government regulations in your area might state that a
doctor is authorized to view the medical records of their own patients, but not of other
patients. The same regulations might also state that, unless a patient gives their
consent, a healthcare provider is not permitted access to patient personal information,
such as the patient's home phone number.
You can use row and column access control to ensure that your users have access to
only the data that is required for their work. For example, a hospital system running Db2
and RCAC can filter patient information and data to include only that data which a
particular doctor requires. Other patients do not exist as far as the doctor is concerned.

© Copyright IBM Corp. 1997, 2017 10-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Similarly, when a patient service representative queries the patient table at the same
hospital, they are able to view the patient name and telephone number columns, but the
medical history column is masked for them. If data is masked, a NULL, or an alternate
value is displayed, instead of the actual medical history.

© Copyright IBM Corp. 1997, 2017 10-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Example - CREATE PERMISSION

• The tellers in a bank can only CREATE PERMISSION
TELLER_ROW_ACCESS ON CUSTOMER
access customers from their FOR ROWS WHERE
own branch. VERIFY_ROLE_FOR_USER
(SESSION_USER,'TELLER') = 1 AND
• All tellers are members in role BRANCH = (SELECT HOME_BRANCH
TELLER. FROM INTERNAL_INFO
WHERE EMP_ID = SESSION_USER)
• The customer service ENFORCED FOR ALL ACCESS
representatives are allowed to ENABLE;
access all customers of the
bank. CREATE PERMISSION
CSR_ROW_ACCESS ON CUSTOMER
• All customer service FOR ROWS WHERE
representatives are members in VERIFY_ROLE_FOR_USER(SESSION_USE
R,'CSR') = 1
role CSR
ENFORCED FOR ALL ACCESS
ENABLE;

ALTER TABLE CUSTOMER ACTIVATE ROW

ACCESS CONTROL;

Security © Copyright IBM Corporation 2017

Example - CREATE PERMISSION

The visual shows an example of two CREATE PERMISSIONS statements that could
be used to implement row based access control.
The tellers in a bank can only access customers from their own branch. All tellers are
members in role TELLER. The customer service representatives are allowed to access
all customers of the bank. All customer service representatives are members in role
CSR. A row permission is created accordingly for each group of personnel in the bank
by a user with SECADM authority.
After row level access control is activated for table CUSTOMER, in the SELECT
statement the search conditions of both row permissions are merged into the statement
and they are combined with the logical OR operator to control the set of rows
accessible by each group.

© Copyright IBM Corp. 1997, 2017 10-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

For example:
CREATE PERMISSION TELLER_ROW_ACCESS ON CUSTOMER
FOR ROWS WHERE VERIFY_ROLE_FOR_USER
(SESSION_USER,'TELLER') = 1 AND
BRANCH = (SELECT HOME_BRANCH FROM INTERNAL_INFO
WHERE EMP_ID = SESSION_USER)
ENFORCED FOR ALL ACCESS
ENABLE;
CREATE PERMISSION CSR_ROW_ACCESS ON CUSTOMER
FOR ROWS WHERE VERIFY_ROLE_FOR_USER(SESSION_USER,'CSR') = 1
ENFORCED FOR ALL ACCESS
ENABLE;

© Copyright IBM Corp. 1997, 2017 10-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Create column mask

• To create a mask for a column
 CREATE the mask with visibility of column value determined by
case expression
 ENABLE or DISABLE the permission, determining if this access rule will be
implemented when column access control is enabled for the affected table
 ALTER table to ACTIVATE column access control

CREATE MASK m_name on t_name FOR COLUMN c_name RETURN

case-expression {disable/enable}

ALTER TABLE/VIEW table/view ACTIVATE COLUMN ACCESS CONTROL;

Result of case Determines if mask

expression is will be enabled when
returned in substitute ACTIVATE column
access control is
of column value access control
ACTIVATEd for table

Security © Copyright IBM Corporation 2017

Create column mask

You will now discuss how you would implement the column access control. Remember
that RCAC provides both column access and row access controls. Column access
control is implemented in the form of a mask, or lack thereof, on the data
This slide shows how you would define the column access control. Note that you have
three similar steps to those for defining row access control
• First you create the mask – you use CASE expressions to determine the result
• Second you ENABLE the permission
• Third (and again, as important as it was with row permissions) you must
ACTIVATE the permission on the table involved.
Note that the ability for someone to update a column with a mask on it will be based not
on the presence of a mask, but the presence of any row permission. Someone can
update the column data which is masked, even if they cannot see the masked data as
long as they have update permission on the table and the ability to see the row.

© Copyright IBM Corp. 1997, 2017 10-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Example - CREATE MASK for a column

• Role customer service CREATE MASK ACCOUNT_COL_MASK ON
[Link] FOR
representative (CSR) is allowed COLUMN ACCOUNT RETURN
to access account number CASE WHEN (VERIFY_ROLE_FOR_USER
information only when they are (USER, ‘CSR') = 1 AND
ROUTINE_SPECIFIC_NAME =
using the account update ‘ACCTUPDATE' AND
application. ROUTINE_SCHEMA = ‘ACCOUNTS'
AND
• This application is identified ROUTINE_TYPE = ‘P')
through stored procedure THEN ACCOUNT
[Link] ELSE 'xxxx-xxxx-xxxx-‘ ||
SUBSTR(ACCOUNT,16,4)
• If a CSR queries this data END
outside of this application, the ENABLE;
account information is masked
and the first 12 digits are ALTER TABLE [Link]
ACTIVATE COLUMN ACCESS CONTROL;
replaced with "x".

Security © Copyright IBM Corporation 2017

Example - CREATE MASK for a column

Column masks can be used to hide data returned to users or applications by column
unless they are permitted to view the data.
If the customer service representatives for a bank can access all clients in the banking
system, but, they are not permitted to view full account numbers unless they are using a
specific application.
The security administrator implements the following column mask so that a customer
service representative is restricted to view a result set that they are privileged to view:
The security administrator observes that even after creating a column mask, the data
can still be viewed by all employees. A column mask is not applied until it is activated
on the table for which it was defined.
The security administrator must activate the mask using the ALTER TABLE statement.

© Copyright IBM Corp. 1997, 2017 10-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Security for database connections

• The AUTHENTICATION option in the DBM CFG can be set to utilize
encryption:
 DATA_ENCRYPT authentication option uses Data Encryption Standard
(DES) with 56 bit encryption keys, to protect the userid, password and also
the data exchanged between the client and server
 SERVER_ENCRYPT authentication can use DES or AES encryption to
encrypt userid and password information sent by the client
• Db2 servers and clients can be configured to utilize Secure Socket
Layer (SSL) based connections

Security © Copyright IBM Corporation 2017

Security for database connections

One aspect of security for a database system is the need to protect user and password
information and possibly all application data being transferred between the application
system and a database server over a network.
The configuration setting for authentication in the DBM configuration file specifies and
determines how and where authentication of a user takes place.
If authentication is SERVER, the user ID and password are sent from the client to the
server so that authentication can take place on the server. The value
SERVER_ENCRYPT provides the same behavior as SERVER, except that any user
IDs and passwords sent over the network are encrypted.
A value of DATA_ENCRYPT means the server accepts encrypted SERVER
authentication schemes and the encryption of user data. The authentication works
exactly the same way as SERVER_ENCRYPT.

© Copyright IBM Corp. 1997, 2017 10-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

The following user data are encrypted when using this authentication type:
• SQL statements
• SQL program variable data
• Output data from the server processing an SQL statement and including a
description of the data
• Some or all of the answer set data resulting from a query
• Large object (LOB) streaming
• SQLDA descriptors
The DATA_ENCRYPT authentication option uses Data Encryption Standard (DES) with
56 bit encryption keys, to protect the userid, password and also the data exchanged
between the client and server.
You can encrypt the user ID and password using the Advanced Encryption Standard
(AES) algorithm with keys 256 bits long.
The user ID and password submitted for authentication to Db2 are encrypted when the
authentication method negotiated between the Db2 client and the Db2 server is
SERVER_ENCRYPT. The authentication method negotiated depends on the
authentication type setting of the authentication configuration parameter on the server
and the authentication requested by the client.
The choice of the encryption algorithm used to encrypt the user ID and password, either
DES or AES, depends on the setting of the alternate_auth_enc database manager
configuration parameter:
• NOT_SPECIFIED (the default) means that the server accepts the encryption
algorithm that the client proposes.
• AES_CMP means that if the connecting client proposes DES but supports AES
encryption, the server renegotiates for AES encryption. Downlevel clients that do
not support AES will still be able to connect using DES.
• AES_ONLY means that the server accepts only AES encryption. If the client
does not support AES encryption, the connection is rejected.

© Copyright IBM Corp. 1997, 2017 10-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

How SSL is used for Db2 database connections

Client System Db2 Database

Server
Encrypted
SSL Setup communication
SSL Setup
Based on Using TCP/IP Using GSkit
Client Type

Signer Digital
certificate certificates
database Import a Signer database
Certificate Extract a
Certificate Add or Create
Certificates
iKeyman tool

Security © Copyright IBM Corporation 2017

How SSL is used for Db2 database connections

The Db2 database system supports the use of Secure Sockets Layer (SSL) and its
successor, Transport Layer Security (TLS), to enable a client to authenticate a server,
and to provide private communication between the client and server by use of
encryption. Authentication is performed by the exchange of digital certificates.
Without encryption, packets of information travel through networks in full view of anyone
who has access. You can use SSL to protect data in transit on all networks that use
TCP/IP (you can think of an SSL connection as a secured TCP/IP connection).
The Db2 database system supports SSL, which means that a Db2 client application
that also supports SSL can connect to a Db2 database using an SSL socket. CLI, CLP,
and .Net Data Provider client applications and applications that use the IBM Data
Server Driver for JDBC and SQLJ (Type 4 connections) support SSL.
The IBM Global Security Kit (GSKit) libraries are installed with the Db2 server code to
provide SSL support. Some setup on the client and server systems is required to
enable the digital certificates to be stored and exchanged when the connections are
established.

© Copyright IBM Corp. 1997, 2017 10-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

SSL configuration for Db2 Servers (1 of 2)

• IBM Global Security Kit (GSKit) libraries are installed with Db2
• Use GSkit tools to set up key database for digital certificates
 Password is stored in a stash file
 Import the server digital certificate you purchased from a certificate authority
(CA) into the certificate database
• Set DB2COMM to include SSL
 db2set DB2COMM=tcpip,ssl (supports both SSL and TCPIP connections)

Security © Copyright IBM Corporation 2017

SSL configuration for Db2 Servers

To configure SSL support, first, you create a key database to manage your digital
certificates. These certificates and encryption keys are used for establishing the SSL
connections. Second, the Db2 instance owner must configure the Db2 instance for SSL
support.
1. Create a key database and set up your digital certificates.
• Use the GSKCapiCmd tool to create your key database. It must be a
Certificate Management System (CMS) type key database.
• The GSKCapiCmd is a non-Java-based command-line tool, and Java does
not need to be installed on your system to use this tool.
• You invoke GSKCapiCmd using the gskcapicmd command, as described in
the GSKCapiCmd User's Guide.
For example, the following command creates a key database called
[Link] and a stash file called [Link]:
gsk8capicmd_64 -keydb -create -db "[Link]" -pw
"myServerPassw0rdpw0" –stash
The -stash option creates a stash file at the same path as the key database,
with a file extension of .sth.

© Copyright IBM Corp. 1997, 2017 10-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• At instance start-up, GSKit uses the stash file to obtain the password to the
key database.
• When you create a key database, it is automatically populated with signer
certificates from a few certificate authorities (CAs), such as Verisign.
2. Add a certificate for your server to your key database. The server sends this
certificate to clients during the SSL handshake to provide authentication for the
server.
3. Extract the certificate you just created to a file, so that you can distribute it to
computers running clients that will be establishing SSL connections to your Db2
server.
4. To set up your Db2 server for SSL support, log in as the Db2 instance owner
and set the following configuration parameters and the Db2COMM registry
variable.
• Set the ssl_svr_keydb configuration parameter to the fully qualified path of
the key database file.
For example:
db2 update dbm cfg using SSL_SVR_KEYDB
/home/test/sqllib/security/keystore/[Link]
• If ssl_svr_keydb is null (unset), SSL support is not enabled.
• Set the ssl_svr_stash configuration parameter to the fully qualified path of the
stash file.
For example:
db2 update dbm cfg using SSL_SVR_STASH
/home/test/sqllib/security/keystore/[Link]
 If ssl_svr_stash is null (unset), SSL support is not enabled.
• Set the ssl_svr_label configuration parameter to the label of the digital
certificate of the server, which you added. If ssl_svr_label is not set, the
default certificate in the key database is used. If there is no default certificate
in the key database, SSL is not enabled.
For example:
db2 update dbm cfg using SSL_SVR_LABEL myselfsigned
 where myselfsigned is a sample label.

© Copyright IBM Corp. 1997, 2017 10-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

• Set the ssl_svcename configuration parameter to the port that the Db2
database system should listen on for SSL connections. If TCP/IP and SSL
are both enabled (the DB2COMM registry variable is set to 'TCPIP, SSL'),
you must set ssl_svcename to a different port than the port to which
svcename is set. The svcename configuration parameter sets the port that
the Db2 database system listens on for TCP/IP connections. If you set
ssl_svcename to the same port as svcename, neither TCP/IP or SSL will be
enabled. If ssl_svcename is null (unset), SSL support is not enabled.
Note: When the DB2COMM registry variable is set to 'TCPIP,SSL', if
TCPIP support is not properly enabled, for example due to the svcename
configuration parameter being set to null, the error SQL5043N is returned
and SSL support is not enabled.
• (Optional) If you want to specify which cipher suites the server can use, set
the ssl_cipherspecs configuration parameter. If you leave ssl_cipherspecs as
null (unset), this allows GSKit to pick the strongest available cipher suite that
is supported by both the client and the server. See Supported cipher suites
for information about which cipher suites are available.
5. Add the value SSL to the DB2COMM registry variable. For example:
db2set -i db2inst1 DB2COMM=SSL
 where db2inst1 is the DB2 instance name. The database manager
can support multiple protocols at the same time.
 For example, to enable both TCP/IP and SSL communication
protocols:
db2set -i db2inst1 DB2COMM=SSL,TCPIP
6. Restart the Db2 instance.

© Copyright IBM Corp. 1997, 2017 10-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

SSL configuration for Db2 Servers (2 of 2)

• Update DBM configuration:
 Set the ssl_svr_keydb configuration parameter to the fully qualified path of
the key database file.
db2 update dbm cfg using
SSL_SVR_KEYDB/home/db2/sqllib/security/ssl/[Link]
 Set the ssl_svr_stash configuration parameter to the fully qualified path of
the stash file.
db2 update dbm cfg using SSL_SVR_STASH
/home/db2/sqllib/security/ssl/[Link]
 Set the ssl_svr_label configuration parameter to the label of the digital
certificate of the server.
 Set the ssl_svcename configuration parameter to the port that the Db2
database system should listen on for SSL connections. Must not be equal to
SVCENAME port.
 Optionally, set options to select a ciphers suite:
− SSL_CIPHERSPECS: Allowed ciphers suite
− SSL_VERSIONS: Allowed SSL/TLS versions
Security © Copyright IBM Corporation 2017

© Copyright IBM Corp. 1997, 2017 10-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Database security for three-tier application systems

• For many three-tiered application systems:
 Individual Users are authenticated by the application server
 A common user name and password is used to connect to the Db2 server
which is unknown to the end user
 All database/SQL processing is performed using a single user name
 A set of database access privileges are granted to the common application
logon name to allow all aspects of application processing to be performed
 These characteristics can lead to over-granting privileges to a single user
name that could be misused to bypass security policies

Security © Copyright IBM Corporation 2017

Database security for three-tier application systems

The three-tiered application model extends the standard two-tiered client and server
model by placing a middle tier between the client application and the database server. It
has gained great popularity in recent years particularly with the emergence of Web-
based technologies and the Java 2 Enterprise Edition (J2EE) platform. An example of a
software product that supports the three-tier application model is IBM WebSphere
Application Server (WAS).
In a three-tiered application model, the middle tier is responsible for authenticating the
users running the client applications and for managing the interactions with the
database server. Traditionally, all the interactions with the database server occur
through a database connection established by the middle tier using a combination of a
user ID and a credential that identify that middle tier to the database server. In other
words, the database server uses the database privileges associated with the middle
tier's user ID for all authorization checking and auditing that must occur for any
database access, including access performed by the middle tier on behalf of a user.

© Copyright IBM Corp. 1997, 2017 10-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

What is a trusted context?

• A database object created by a SECADM user that defines a trust
relationship between a Db2 database and an external entity such as a
middle-tier server.
• The trust relationship is based on the following trust attributes:
 System authorization ID
 IP address (or domain name)
 Data stream encryption

Security © Copyright IBM Corporation 2017

What is a trusted context?

A trusted context is a database object that defines a trust relationship for a connection
between the database and an external entity such as an application server.
The trust relationship is based upon the following set of attributes:
• System authorization ID: Represents the user that establishes a database
connection
• IP address (or domain name): Represents the host from which a database
connection is established
• Data stream encryption: Represents the encryption setting (if any) for the data
communication between the database server and the database client
When a user establishes a database connection, the Db2 database system checks
whether the connection matches the definition of a trusted context object in the
database. When a match occurs, the database connection is said to be trusted.
A trusted connection allows the initiator of this trusted connection to acquire additional
capabilities that might not be available outside the scope of the trusted connection. The
additional capabilities vary depending on whether the trusted connection is explicit or
implicit.

© Copyright IBM Corp. 1997, 2017 10-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

The trusted context can only be created if the privileges held by the authorization ID of
the statement include SECADM authority.
The definition of a trusted context can designate a role for a specific authorization ID,
and a default role to be used for authorization IDs for which a specific role has not been
specified in the definition of the trusted context. This role can be used with a trusted
connection based on the trusted context, but it does not make the role available outside
of a trusted connection based on the trusted context.
When issuing a data manipulation language (DML) SQL statement using a trusted
connection, the privileges held by a context-assigned role in effect for the authorization
ID within the definition of the associated trusted context are considered in addition to
other privileges directly held by the authorization ID of the statement, or indirectly by
other roles held by the authorization ID of the statement.
The privileges held by a context-assigned role in effect for the authorization ID within
the definition of the associated trusted context are not considered for data definition
language (DDL) SQL statements. For example, to create an object, the authorization ID
of the statement must be able to do so without including the privileges held by the
context-assigned role.
When installing a new application that authenticates to Db2 using the same credentials
as an existing application on the same machine, and which takes advantage of a
trusted context, the new application might also take advantage of the same trusted
context object (inheriting the trusted context role, for example). This might not be the
security administrator's intention. The security administrator might want to turn on the
Db2 audit facility to find out what applications are taking advantage of trusted context
objects.

© Copyright IBM Corp. 1997, 2017 10-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Trusted Context - Example

• The statement creates a trusted context with these characteristics:
 The connection must be made from the IP address [Link] with a
userid of BERNARD
 The trusted context has a default role called appserv_role. This implies that
users working within the confines of this trusted context inherit the privileges
associated with role appserv_role.
 The application can make an explicit request to switch to two different user
IDs:
− When the current user of the connection is switched to user ID JOE, authentication
is not required.
− Authentication is required when the current user of the connection is switched to
user ID BOB.
CREATE TRUSTED CONTEXT APPSERVER
BASED UPON CONNECTION USING SYSTEM AUTHID BERNARD
DEFAULT ROLE APPSERV_ROLE ENABLE
ATTRIBUTES (ADDRESS '[Link]')
WITH USE FOR JOE WITHOUT AUTHENTICATION
BOB WITH AUTHENTICATION

Security © Copyright IBM Corporation 2017

Trusted Context - Example

The example defines a trusted context named APPSERVER.
Db2 would consider a connection to match the trusted context only if:
• The user name on the connection matches BERNARD
• The connection is made from the system with a tcpip ip address of [Link]
• Any type of encryption could be used. The default for encryption type is NONE.
The default security role of APPSERV_ROLE would be assigned to connections
matching this trusted context.
When the current user of the connection is switched to user ID JOE, authentication is
not required. However, authentication is required when the current user of the
connection is switched to user ID BOB.

© Copyright IBM Corp. 1997, 2017 10-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Demonstration 1
Database security
• Describe the default privileges that were granted to PUBLIC and the
database creator when the database was created.
• Implement a SECADM user for the database that does not have either
SYSADM or DBADM authorities.
• Grant privileges to individuals, groups, or roles.
• Compare the privileges that can be used to run utilities like LOAD,
IMPORT or RUNSTATS.

Database maintenance, monitoring and problem determination © Copyright IBM Corporation 2017

Demonstration 1: Database security

© Copyright IBM Corp. 1997, 2017 10-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Demonstration 1:
Database security
Purpose:
This demonstration allows the student to manage the security privileges of
the Db2 database to support different types of users. A security administrator
with the SECADM authority will be implemented. Another user will be given
the DBADM authority for this database. An application developer will be
granted specific privileges to support their assignment. Several database
roles will be created to provide access based on role membership, rather than
managing the authorizations at the user level.

Task 1. Granting specific privileges to a set of database

users.
In previous exercises you used the Db2 instance owner, inst23, to perform most of the
tasks. As a member of the SYSADM group for the instance, you used this logon to
create the MUSICDB database. As the database creator, inst23 was granted the
DBADM and SECADM authorities for the database. These combined privileges allowed
this user to perform all of the administration tasks for the MUSICDB database.
You are going to assign specific authorities to a list of users to see how Db2 security
checking is performed for processing Db2 commands and SQL statements.
You will use the following system user logons:
• dba23 - will be granted DBADM authority, but will not be granted ACCESSCTRL
• ctrl23 - will be granted SECADM authority as a new security administrator.
• user23 - will be granted various specific privileges to perform selected tasks as a
new developer.
1. Logon to the Linux system using the user id inst23, with a password of
ibm2blue.
You will use the Linux Terminal session to enter Db2 commands.

© Copyright IBM Corp. 1997, 2017 10-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

2. Right-click the empty Linux desktop and select Open in Terminal.

You will grant the system user logon ctrl23 the security administrator
(SECADM) authority for the database MUSICDB. The database creator, inst23,
is currently the only user with SECADM authority.
You can use the catalog view [Link] to check current database
authorizations. On your system a script file named select_dbauth.sql contains
the query statement.
The file select_dbauth.sql contains the following SQL text:
select varchar(grantee,12) as grantee,
varchar(grantor,12) as grantor,
connectauth,loadauth,dbadmauth,securityadmauth
from [Link];
This task will be performed using the Db2 command line processor.
3. Issue the following series of commands using the Linux terminal session.
• cd $HOME/ddl
• db2 connect to musicdb
• db2 grant secadm on database to user ctrl23
• db2 -tvf select_dbauth.sql
The output will look similar to the following:
GRANTEE GRANTOR CONNECTAUTH LOADAUTH DBADMAUTH SECURITYADMAUTH
------------ ------------ ----------- -------- --------- ---------------
INST23 SYSIBM N N Y Y
PUBLIC SYSIBM Y N N N
CTRL23 INST23 N N N Y

3 record(s) selected.
You will need a second Linux terminal session to be able to start a second
database connection that will be used by the security administrator, ctrl23. You
will connect to the MUSICDB database using a different system userid, ctrl23,
to make it easier to manage the security privileges for the database.
4. To start a second Linux terminal session, right-click the empty Linux desktop
and select Open in Terminal.

© Copyright IBM Corp. 1997, 2017 10-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

5. Using the second Linux terminal session, issue the following series of
commands.
• cd $HOME/ddl
• db2 connect to musicdb user ctrl23 using ibm2blue
Rather than grant the DBADM authority directly to the user dba23, you will
create a new database role named dba_role. This role can be used to define a
set of database authorizations that new staff can utilize as needed. The
WITHOUT ACCESSCTRL option will be used to provide broad access to table
data, but not allow users of this role to grant and revoke privileges. The new
security administrator can perform this work.
6. Using the second Linux terminal session, issue the following series of
commands:
• db2 create role dba_role
• db2 grant dba_role to user dba23
• db2 grant dbadm without accessctrl on database to role dba_role
The user system user23 does not have the SELECT authority for the table
[Link]. You could grant the authority to the user directly, but you will
grant the access to the developer role dev_role, so all the developers can
perform the access if needed. You will grant the SELECT privilege on the table
[Link] to the role dev_role.
7. Using the second Linux terminal session, issue the following series of
commands:
• db2 create role dev_role
• db2 grant dev_role to user user23
• db2 grant load on database to role dev_role
• db2 -tvf select_dbauth.sql
The output should look similar to the following:
GRANTEE GRANTOR CONNECTAUTH LOADAUTH DBADMAUTH SECURITYADMAUTH
------------ ------------ ----------- -------- --------- ---------------
INST23 SYSIBM N N Y Y
PUBLIC SYSIBM Y N N N
CTRL23 INST23 N N N Y
DBA_ROLE CTRL23 N N Y N
DEV_ROLE CTRL23 N Y N N

5 record(s) selected.

© Copyright IBM Corp. 1997, 2017 10-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Task 2. Use the newly defined security privileges to create

and access database objects.
Next you will use the new database administrator id, dba23, to access your database.
You will need a third Linux terminal session to be able to start a third database
connection that can execute SQL scripts and SQL statements. You will connect to
the MUSICDB database using a different system userid, dba23.
1. To start a third Linux terminal session, right-click the empty Linux desktop and
select Open in Terminal.
2. Using the third Linux terminal session, issue the following series of
commands:
• cd $HOME/ddl
• db2 connect to musicdb user dba23 using ibm2blue
Try to create a new table space using this database user.
3. Using the third Linux terminal session, issue the following command:
• db2 create tablespace testdata
The CREATE TABLESPACE fails with a SQL0552N message. The DBADM
database authority does not allow a user to create new table spaces. Currently
the inst23 user would need to perform that task.
The user dba23 can be used to create a new table and load data into the new
table.
Issue the following SQL statements using the third terminal session connected
as dba23.
4. Using the third Linux terminal session, issue the following series of
commands:
• db2 create table [Link] like [Link] in userspace1
• db2 “export to [Link] of del select * from [Link]“
• db2 “import from [Link] of del insert into [Link]“
• db2 runstats on table [Link]
• db2 runstats on table [Link]

© Copyright IBM Corp. 1997, 2017 10-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

As a DBADM user, you were able to access the table [Link], and
execute RUNSTATS commands for any table.
The user named user23 was placed in a role for developers named
dev_role. You can run some SQL statements using the user23 user to test
its ability to access data and perform development tasks.
Issue the following SQL statements using the third terminal session
connected as dba23.
5. Using the third Linux terminal session, issue the following series of
commands:
• db2 connect to musicdb user user23 using ibm2blue
• db2 create table test.album2 like [Link] in tsp01
The CREATE TABLE fails with a SQL0551N message. The user user23 does
not have the USE authority for the tablespace TSP01. When the database was
created, USE authority for the tablespace USERSPACE1 was granted to
PUBLIC. Create the new test table using the USERSPACE1 table space.
• db2 create table test.album2 like [Link] in userspace1
Now attempt to copy some rows from the table [Link] to the new test
table.
6. Using the third Linux terminal session, issue the following command:
• db2 “insert into test.album2 select * from [Link] where artno =
42 “
The INSERT fails with a SQL0551N message.
The user user23 does not have the SELECT authority for the table
[Link]. You could grant the authority to the user directly, but you will
grant the access to the developer role dev_role, so all the developers can
perform the access if needed. The security administrator will perform the task.
7. Using the second Linux terminal session, issue the following series of
commands:
• db2 grant select on table [Link] to role dev_role
• db2 grant select,update on table [Link] to role dev_role
You run some additional SQL statements using the user23 user to test its ability
to access data in the database.

© Copyright IBM Corp. 1997, 2017 10-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

8. Using the third Db2 command line window, issue the following series of
commands:
• db2 connect to musicdb user user23 using ibm2blue
• db2 “insert into test.album2 select * from [Link] where artno =
42 “
The INSERT is now successful. The user user23 now has the authority to
SELECT from the table [Link] as a member of the role dev_role. As
the creator of the table TEST.ALBUM2 the user has all SQL privileges for that
table.
Next, run the SQL statements in the script file test_user23.sql.
9. Using the third Db2 command line window, issue the following series of
commands:
• db2 connect to musicdb user user23 using ibm2blue
• db2 -tvf test_user23.sql | more
The output should look similar to the following:
select title from [Link] where itemno =97

TITLE
--------------------------------------------------
1962 - 1966

1 record(s) selected.

update [Link] set artno = 1 where itemno = 97

DB20000I The SQL command completed successfully.

delete from test.album2 where itemno = 97

DB20000I The SQL command completed successfully.

delete from [Link] where itemno = 97

DB21034E The command was processed as an SQL statement because it was not
a
valid Command Line Processor command. During SQL processing it returned:
SQL0551N "USER23" does not have the required authorization or privilege to
perform operation "DELETE" on object "[Link]". SQLSTATE=42501

© Copyright IBM Corp. 1997, 2017 10-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

runstats on table test.album2

DB20000I The RUNSTATS command completed successfully.

runstats on table [Link]

DB20000I The RUNSTATS command completed successfully.

drop table test.album2

DB20000I The SQL command completed successfully.
The only statement execution that failed security tests was the DELETE from
the table [Link]. The user user23, as a member of the role dev_role
was able to perform SELECT and UPDATE access to the table [Link]
that was created by the user dba23. As creator of the table TEST.ALBUM2, the
user user23 could perform any type of access and could drop the table.
Results:
You managed the security privileges of the Db2 database to support different
types of users. A security administrator with the SECADM authority was
implemented. Another user was given the DBADM authority for this database.
An application developer was granted specific privileges to support their
assignment. Several database roles were created to provide access based on
role membership rather than managing the authorizations at the user level.

© Copyright IBM Corp. 1997, 2017 10-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Unit 10 Security

Unit summary
• Use Db2 access control mechanisms to implement security within the
database
• Explain the tasks performed by the SYSADM user, the SECADM user
and a DBADM user
• Compare the use of database roles to user groups for security
• Describe privileges required for binding and executing an application
package
• Describe the difference between explicit privileges and implicit
privileges
• List the methods for implementing encryption for database connections
• List the advantages of creating a Trusted Context for a three-tier
application system

Security © Copyright IBM Corporation 2017

Unit summary

© Copyright IBM Corp. 1997, 2017 10-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 IBM Training

© Copyright IBM Corporation 2017. All Rights Reserved.