DB2 Bootcamp HOLs Workbook v20120418

IBM Software
Information Management
DB2® 10 for Linux®, UNIX® and Windows®

Bootcamp
Hands-On Labs Workbook
V2012-04-18
Table of Contents
DB2 FUNDAMENTALS AND DATA STUDIO.......................................... 3
MULTI - TEMPERATURE DATA MANAGEMENT....................................33
DB2 ESSENTIAL MAINTENANCE & PRACTICAL AUTONOMICS...... 51
DB2 BACKUP AND RECOVERY............................................................... 86
DB2 STORAGE OPTIMIZATION........................................................... 124
DB2 RANGE PARTITIONING................................................................. 148
TEMPORAL DATA MANAGEMENT...................................................... 174
ENABLING OPENBRAVO TO DB2 1 0 ................................................... 199
DB2 SECURITY........................................................................................ 228
ROW AND COLUMN ACCESS CONTROL............................................ 257
CONTINUOUS DATA INGEST............................................................... 276
WORKLOAD MANAGEMENT................................................................ 294
DB2 10 for Linux, UNIX and Windows Course Workbook Page 2 of 335.
IBM Software
Information Management Technology Ecosystem
DB2® Fundamentals and Data Studio

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 Suggested Reading .............................................................................................................................................................................3
3 About this Lab......................................................................................................................................................................................3
4 Environment Setup Requirements.....................................................................................................................................................3
5 Initial Steps...........................................................................................................................................................................................4
5.1 The SAMPLE Database...................................................................................................................................................................................... 4
6 Launch IBM Data Studio .....................................................................................................................................................................5

7 Data Studio General Layout ...............................................................................................................................................................7
8 Working with Databases in Data Studio............................................................................................................................................8
8.1 Connecting to a database ................................................................................................................................................................................... 8
8.2 Browsing Database Objects.............................................................................................................................................................................. 11
8.3 Administering with Task Assistants................................................................................................................................................................... 15
8.4 Managing Database Changes .......................................................................................................................................................................... 17
8.5 Working with SQL ............................................................................................................................................................................................. 20
8.5.1 Visual Explain ................................................................................................................................................................................... 24
8.5.2 Exporting Results.............................................................................................................................................................................. 27
9 Summary ............................................................................................................................................................................................28
10 Cleanup...............................................................................................................................................................................................28
DB2 Fundamentals and Data Studio

© Copyright IBM Corp. 2012. All rights reserved Page 2 of 30
IBM Software
1 Introduction
DB2 for Linux, UNIX and Windows is a relational database management system developed by IBM®. Since its inception, DB2
has received constant enhancements in areas such as compression, autonomics, security, XML data handling, manageability,
and performance.
With the advent of IBM Data Studio comes a major advance in the way DB2 developers and administrators alike carry out their
day to day functions. Historically, depending on the tasks to be completed, it was common to switch back and forth between
disparate tools such as Control Center, Health Monitor, Developer Workbench, and even the DB2 Command Line Processor
(CLP).
IBM Data Studio version 3.1.1 changes all this, facilitating DB2 administration, design, development, and monitoring all within an
integrated Eclipsed-based environment. By leveraging the power of Data Studio, users are certain to enjoy increased
productivity as they find themselves able to perform a majority of their tasks within a single environment.
In this lab, you will explore the basic concepts of DB2 with Data Studio 3.1.1 from the perspective of both a developer and a
database administrator.
2 Suggested Reading
IBM Data Studio version 3.1 Information Center: http://publib.boulder.ibm.com/infocenter/dstudio/v3r1/index.jsp
3 About this Lab

By the end of this lab, you will be able to:
• Familiarize with the layout and navigation of Data Studio
• Establish a database connection
• Browse database objects
• Leverage task assistants to carry out administrative tasks
• Manage database changes with change plans
• Create and execute SQL statements using Data Studio’s SQL Editor
• Analyze data access plans using Visual Explain
• Export query results for later use
4 Environment Setup Requirements

To complete this lab you will need the following:
1. DB2 10 Bootcamp VMware® image
2. VMware Workstation 6.5 or later

IBM Software
5 Initial Steps
1. Start the VMware image by clicking the button in VMware Workstation.

2. At the login prompt, log in with the following credentials :
• Username : db2inst1
• Password : password
3. Open a terminal window by right-clicking on the Desktop and choosing the Open Terminal item.
Figure 1 – Open in Terminal on Desktop
4. Ensure that the DB2 Database Manager has been started by issuing the following
db2start
A message like the following should be displayed to if the DB2 Database Manager had not been started yet:
db2inst1@db2v10:~/Desktop> db2start
12/14/2011 16:36:11 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
5.1 The SAMPLE Database
The SAMPLE database can be used for various purposes like testing your own applications, or trying different features of DB2
using the provided sample programs. During this lab, we will use the SAMPLE database for demonstrating various features of
DB2 that makes it easy to understand the technology.

IBM Software
Once the sample database is created, you will notice:

• Organizational schema for non-XML data and
• Purchase order schema for XML data is created.
The data and database objects are created using a real time environment on a small scale.
1. Use the DB2 command db2sampl to create a sample database that we will be using in the subsequent sections. Enter
the following command in the terminal window:
db2sampl –sql –xml –name DB2FUND
Note: -sql: creates tables, triggers, functions, procedures, and populates the tables with data.
-xml: creates tables with columns of data type XML, creates indexes on the XML columns, registers XML schemas, and
populates these tables with data including XML document values.
-name: defines the database name.
The following message should be displayed, indicating that the DB2FUND database has been created:
db2inst1@db2v10:~/Desktop> db2sampl -sql -xml -name DB2FUND
Creating database "DB2FUND"...

Connecting to database "DB2FUND"...
Creating tables and data in schema "DB2INST1"...
Creating tables with XML columns and XML data in schema "DB2INST1"...
'db2sampl' processing complete.
6 Launch IBM Data Studio
1. Double click ‘IBM Data Studio’ on the Desktop.
Figure 2 – IBM Data Studio on Desktop

IBM Software
2. If this is the first time Data Studio is launched, it may take a moment. Click OK to accept the default workspace.
Figure 3 – Select a workspace
3. By default, the Database Administration perspective is opened. Your workspace should look like the following :
Figure 4 – IBM Data Studio workspace

IBM Software
7 Data Studio General Layout

Since Data Studio is built on the Eclipse framework, it has a similar structure that consists of perspectives and views. As
mentioned earlier, the default perspective is Database Administration. In this perspective, three sections are central to Data
Studio:
• Administration Explorer
• Object List
• Properties / Results view
Figure 5 – Data Studio layout overview
Note: Perspective defines the initial set and layout of the components in your screen. Each perspective provides a set of
functionality aimed at accomplishing a specific type of task or works with specific types of resources.
For instance, the “Database Administration” perspective allows you carry on administrative tasks, while the “Query
Tuning” perspective provides the tools for you to optimize SQL queries.
Views are screen components that present information and allows you to navigate through the system. Eg: “Administration
Explorer”and “SQL Results” views.

IBM Software
Note: in case if you are not in Database Administration perspective, change it using at the upper right
corner of your Data Studio workspace.
If you are familiar with Control Center, which has been deprecated since DB2 9.7, the following table shows the mapping of the
main display areas between Control Center and Data Studio.
Control Center Data Studio Purpose

Object Tree Administration Explorer view Connect to databases and navigate through different database
object types, including DB2 pureScale members and CFs
Content pane Object List area Lists database objects. In Data Studio, several tabs can be
open for different purposes.
Content Details pane Properties view After selecting an object, its properties can be seen in this area.
Data Studio can have multiple tabs in this area for different
purposes.
8 Working with Databases in Data Studio
8.1 Connecting to a database

Before you can do anything productive, a connection must be established to a database. The Administration Explorer view is
central in Data Studio, where users can perform many administrative tasks including connecting to a database. If DB2
databases have already been catalogued on the machine where Data Studio is installed, the database connection profiles would
automatically be created by default when Data Studio is launched. Since you have created the DB2FUND database in the “Initial
Steps” section, you should be able to see it in Administration Explorer.
1. In Administration Explorer, expand the folder All Databases until you see DB2FUND.
Figure 6 – Data connection profiles

IBM Software
2. Still in Administration Explorer, right click DB2FUND and select Connect.
Figure 7 – Connect to a database
Note: To connect to a remote database, users can click on the toolbar in the Administration Explorer view, select
, fill in required fields, and connect. The new database connection will be available in the
Administration Explorer view.
3. In the pop-up dialog, fill in the connection details as follows :

• Database : DB2FUND
• Host : localhost
• Port number : 50001
• User name : db2inst1

IBM Software
Figure 8 – Database Connection dialog
4. Click OK.
5. After a connection has been successfully established, expand the db2inst1 instance folder in Administration Explorer,
you should see this icon beside the DB2FUND database, which indicates a connected database. Disconnected
databases are listed with . Expanding the DB2FUND database folder will list supported database object types, as
seen in the following screen capture :

IBM Software
Figure 9 – Connected database with supported database object types
8.2 Browsing Database Objects
Now that you have connected to database DB2FUND, let’s see how you can browse database objects in Data Studio.
In the Administration Explorer, database objects are grouped by type, and they are displayed as folders. Clicking any folder will
have its content automatically displayed in the Object List area. We’ll use tables as an example.
1. Expand DB2FUND in Administration Explorer, click the Tables folder. The list of content is automatically displayed in
the Object List area on the right.
Figure 10 – List of tables in DB2FUND

IBM Software
Notice that the current path and the total number of objects are
shown at bottom of the view.
2. Click on the EMPLOYEE table in the Object List, its properties are automatically displayed in the Properties view at the
bottom of your workspace, and they are read-only. The information displayed is dependant on the type of the database
object you select. For tables, you can view properties such as columns definition, privileges, table spaces used, etc.
Figure 11 – Properties view
At the top of the Object List area, you can see a multi-purpose navigation bar. It consists of the following sections:
• Web-browser-like back / forward navigation.
• Breadcrumb navigation, which facilitates moving through the hierarchy of objects.
• “Create new object” button .
• In-place search function. Simply type the object name or part of it, and the list would be dynamically updated.
Wildcard characters ‘%’ and ‘_’ (underscore) are supported.
• Options to sort, filter, refresh objects list.
Figure 12 – Object List navigation bar
3. Clicking any of the arrows on the current path would give you a list of all objects at that hierarchical level. For example,
click the arrow next to gives you access to all objects at the DB2FUND database level.

IBM Software
Figure 13 – List of objects in database DB2FUND using the navigation bar
The in-place search feature allows users easily find a particular object they look for.
4. Using the navigation bar, move to the “Table Name Search” field (since we were looking at tables in DB2FUND) and
type ‘E%E’. All tables with a name that starts with E and ends with E are returned.
Figure 14 – Using in-place search feature to quickly find database objects
5. Remove ‘E%E’ to bring back the complete list of tables.

6. To browse the data in a table, you can right click on a table in the Object List area and select Browse Data from the
context menu. Right click on the table EMPLOYEE and select the option “Browse Data” . A new tab
opens in the Object List area with the records in the table displayed.

IBM Software
Figure 15 – Browsing data in EMPLOYEE table
Note: When using the option “Browse Data”, the data is read-only.
Note: By default in Data Studio 3.1, the maximum number of records to be displayed is set to 500. To change this behavior, on the
top menu bar in Data Studio, go to Window > Preferences > Data Management > SQL Development > SQL Results View Options.
To modify individual records in a table, a simple way is the Edit Data option.
7. Move back to the DB2FUND tab. Right click on the EMPLOYEE table and select the option . A new tab is
opened just like browsing data, but this time the records can be modified. Double click the phone number cell for
employee Michael Thompson, change the number from 3476 to 3477, and then press enter.
The modified cell is highlighted. Now the EMPLOYEE table should look like the following:
Figure 16 – Editing data

IBM Software
Notice that an asterisk (*) has been added to the tab name. This is to indicate that you have uncommitted changes in
that editor.
8. Click at the upper right corner of the tab to deploy changes to the target database. Click “Yes” to confirm. Then a
message should appear notifying you that the data change has been successfully committed.
Figure 17 – Changes committed
9. Click OK to close the dialog

The result, as well as the exact command(s) executed, can also be seen in the SQL Results view at the bottom of your
Data Studio workspace.
Figure 18 – SQL Results view
8.3 Administering with Task Assistants
As mentioned earlier, right clicking on an object would bring out a context-based menu of administrative tasks. If you then select
a particular task, a dialog may appear in a tab in the Object List area to help you execute the task you want; such dialogs are
called Task Assistants in Data Studio. If you are familiar with DB2 Control Center, task assistants work in a similar fashion as
the wizards and advisors. Since task assistants appear in tabs, multiple task assistants can be open simultaneously. This means
that you can navigate to other parts of Data Studio then come back to the task assistants that you opened earlier.
We will take the “Run Statistics” task assistant as an example to illustrate how task assistants help database administrators in
managing databases. This task assistant updates statistics about the characteristics of a table and/or associated indexes, or
statistical views. These characteristics include number of records, number of pages, and average record length. The optimizer
uses these statistics when determining access paths to retrieve the data.

IBM Software
1. Go to the list of tables. Right click table SALES, go to Manage, select Run Statistics.
Figure 19 – Run statistics menu

The task assistant opens in a new tab.
Figure 20 – Task assistant dialog for run statistics

IBM Software
As it is number labeled in the above screen capture, a task assistant dialog consists of 4 sections: Connection, Settings,
Command, and Messages.
1. Connection: shows database connection details
2. Settings: specifies options for the database commands to be run
3. Command: displays the generated commands for the selected settings. Users can edit these generated
commands before execution or save them for later use
4. Messages: shows the status of executing the commands
2. You can review the generated command to be run in the Command section. For this exercise, we keep the auto-
generated commands, click to execute the commands.
As the commands are being executed, status messages will be displayed in the Messages section. When the
commands finished executing, the Messages section displays the overall result.
Figure 21 – Task assistant execution result in Messages section
The result can also be seen in the SQL Results view.
8.4 Managing Database Changes
In Data Studio, all changes made to a database are first collected in a “Change Plan” in the local workspace. A database can
have multiple change plans, but only one plan can be active at a time, which means that changes are added to the current active
plan. When a change plan is active, the Object List area includes an additional toolbar for the plan. A change plan remains
active until the user deploys the changes to the target database, closes the plan to work on it later, or makes another plan the
active plan. The list of change plans for the database can be found in the Change Plans folder in Administration Explorer.
For simplicity, we’ll alter a table as an example.
1. Go back to the list of tables. Right click on table EMPLOYEE and select . The properties of the table should be
displayed in the Properties view. You can now make changes directly in this view and deploy them.
2. Navigate to the Columns tab in the Properties view

IBM Software
Figure 22 – Altering table definition in Properties view
3. Click to add a new column. A new column with default name “Column1” is added at the bottom of the list. Click its
name and change it to LOCATION.
4. Click its data type, and select VARCHAR from the drop-down menu.
Figure 23 – Change the data type of a column
5. Change the length of the column from 5 to 20.

6. The position of a column can be changed as well. While the newly added LOCATION column is still highlighted, click
until it is placed directly under WORKDEPT.
The final LOCATION column should look like the one below:
Figure 24 – New LOCATION column in table EMPLOYEE

IBM Software
As you are making changes to the EMPLOYEE table, a change plan is created in Data Studio. This can be verified by the
additional toolbar for change plans in the Object List area.
Figure 25 – Toolbar for change plans
A change plan is created with a default name of “Default Change Plan timestamp”, where the timestamp has the form yyyy-mm-
dd hh-mm-ss.
In the Object List, icons indicate whether objects for the active change plan are being created ( ), altered ( ), or dropped ( ).
For example, the delta icon on the left of the EMPLOYEE table indicates that the table has been altered.
Icons on the change plan toolbar and their actions:

Icon Description
Shows the number of changes that are currently in the change plan. You can click the
linked number to display the list of changes for the change plan.
For the list of objects that are currently displayed in the Object List, moves the focus to
the next object that is being changed in the current change plan.
For the list of objects that are currently displayed in the Object List, moves the focus to
the previous object that is being changed in the current change plan.
Generates the DDL to implement the changes in the change plan and displays the
generated DDL in the Review and Deploy dialog.
Saves any newly defined changes to the change plan.
Closes the change plan. If any changes have not been saved, you are prompted to
save or discard the changes when the change plan is closed.
Before deploying changes, you can compare the object before and after the changes.
7. Click the altered EMPLOYEE table and go to the Properties view.
8. In the Properties view, click to compare both versions. A new window appears and the changes are outlined.

IBM Software
Figure 26 – Compare object before and after changes
Note: options such as generating a difference report, an impact analysis report, etc. are available on the toolbar.
9. Close the Compare window.
10. Then, in the Object List area, click the red icon on the change plan toolbar to close
the plan. Finally, select Save. The change plan you just created has been saved in your local workspace so you can
continue working on it in the future.
Note: changes you made in your change plan are kept local in your workspace. They do not affect the actual target database.
11. Go to Administration Explorer, expand the database folder DB2FUND and click Change Plans. The change plan you
just saved should be listed in the Object List area.
8.5 Working with SQL
In Data Studio, the SQL Script Editor offers development and debugging capabilities for database routines. It also provides
syntax highlighting, content assist, and several other well integrated tools to facilitate database application development.
1. In Administration Explorer, ensure that database DB2FUND is selected. On the menu bar, click and select
“New SQL Script”.
Figure 27 – Create a new SQL script

IBM Software
The editor is opened as a new tab in the Object List area.
Figure 28 – SQL Editor
There are 4 tabs at the upper half of the editor to provide users with more options:
• Configuration: specify execution environment, commit control, error control, etc.
• Validation: validate syntax against a specific data server, set statement terminator, etc.
• Special Registers: specify values for CURRENT SCHEMA and CURRENT PATH special registers.
• Performance Metrics: specify an Optim Performance Manager profile for gathering performance metrics.
The integrated toolbar at the top provides convenient links to tools such as: Visual Explain, Tuning, Import / Export,
Job Manager, etc.
Some useful keyboard shortcuts you can use in the editor:

• Content Assist: Ctrl + Space
• Content Tip: Shift + Ctrl + Space
• Format SQL: Ctrl + Shift + F
• Toggle Comment: Ctrl + /
2. In the editor, enter the following SQL statement:

select * from department;

IBM Software
Before executing the query, you can ask Data Studio to properly format your query.
3. Inside the editor, press CTRL+SHIFT+F on your keyboard, or right click within the editor and select
from the context menu. Your query should be transformed into the following format:
Figure 29 – Formatted SQL statement
4. Right click at the margin of the editor and select Show Line Numbers. This feature is especially useful if you have many
lines of SQL statements.
Figure 30 – Show line numbers
5. Press F5 on your keyboard or click the Run SQL icon to execute your statement.
The query result is displayed in the SQL Results view. The Status tab shows the status of the query execution. The
Result tab shows actual data records returned by your query. You can also view the history of all previously executed
commands in the left panel of the “SQL Results” tab.

IBM Software
Figure 31 – Result of executed SQL statement
6. Toggle the icon at the top right of the SQL Results view to display the query result in text mode. This is especially
useful if you need to copy and paste the results to an external text editor.
Figure 32 – Result of executed SQL statement in text mode
7. To display query results in a single tab, i.e. not to make the execution status tab the default opening tab, toggle the
button.
8. Execute the query again by pressing button. This time you should see the results right away.

IBM Software
Figure 33 – Result displayed in a single tab
9. Toggle the icon again to turn off the text mode and display the results in the graphical tabular format.
8.5.1 Visual Explain
You can use Visual Explain to view the access plan generated by DB2’s SQL compiler as a graph. You can use the information
in the graph to tune your SQL queries for better performance. The nodes in the graph represent tables and indexes and each
operation on them. The links between the nodes represent the flow of data.
1. We want to find out which department has contributed how many sales. Clear your previous SQL statements in the
editor and enter the following SQL statement.
SELECT d.deptno, d.deptname, SUM(s.sales) as total_sales
FROM sales s INNER JOIN employee e ON s.sales_person = e.lastname
INNER JOIN department d ON d.deptno = e.workdept
GROUP BY d.deptno, d.deptname
ORDER BY d.deptno;
2. To view the access plan diagram of this query, click the Open Visual Explain icon on the integrated toolbar to
open Visual Explain. In the pop-up window, keep the default values, click Finish.
3. The diagram is then displayed in the Access Plan Diagram view at the lower section in your workspace. Double-click
the tab to maximize the view.

IBM Software
Figure 34 – Visual Explain
The Access Plan Diagram view has three sections:

• The toolbar on the top contains the following buttons:
Button Action
Open a saved diagram
To open the Access Plan Diagram view so that you can open a saved
diagram, select Window > Show View > Other. In the Show View window,
select Data > Access Plan Diagram.
Save the diagram
Note: On Linux, Visual Explain appends the extension .xml to the file name
automatically.
View the SQL or XPATH statement
Zoom in
Zoom out
Scale the diagram to fit the Canvas
Flip the diagram horizontally

IBM Software
Flip the diagram vertically
Print the entire diagram or only a portion that you selected
• The left-side area contains three panes:

o The Overview of Diagram pane helps you to navigate through a diagram.
o The Description of Selected Node pane lists the data elements and the associated predicates of the
selected node.
o The Search for Node pane lets you search for a node in a diagram.
• The right-side area contains the Canvas, which displays the access plan graph. These graphs show the
operations that are required by data servers to derive the results of SQL, XPATH, or XQUERY statements.
The access plan graph consists of a tree displaying nodes. These nodes represent:
o Tables, shown as rectangles
o Indexes, shown as diamonds
o Operators, shown as octagons (8 sides). TQ operators, shown as parallelograms
o Table functions, shown as hexagons (6 sides).
Numbers displayed on each node represent cost, which is the estimated total resource usage necessary to
execute the access for a statement or an element of a statement. Cost is derived from a combination of CPU
cost (in number of instructions) and I/O (in numbers of seeks and page transfers).The unit of cost is the
timeron. A timeron does not directly equate to any actual elapsed time, but gives a rough relative estimate of
the resources (cost) required by the database manager to execute two plans for the same query. The cost
shown in each operator node of an access plan graph is the cumulative cost, from the start of access plan
execution up to and including the execution of that particular operator. It does not reflect factors such as the
workload on the system or the cost of returning rows of data to the user.
Clicking on a node in the access plan graph would reveal detailed information about that node.
4. Minimize the Access Plan Diagram view by double-clicking again the tab.
5. In the SQL Editor, press F5 on your keyboard or click to execute this statement. The query result is displayed in the
SQL Results view.

IBM Software
Figure 35 – Sales by department query result
8.5.2 Exporting Results
Exporting data is a way to output data to a spreadsheet or other formats for sharing, archiving, or further calculations.
1. Export this result set by right-clicking in the Result1 tab, select Export, then select Current Result
Figure 36 – Context menu to export query result
2. Enter “/home/db2inst1/query_result” in the File Name field, and select CSV File as the Format. The file extension .csv
will automatically be appended to the file name when you select the CSV file format.

IBM Software
Figure 37 – Export Result dialog

3. Click Finish.
File query_result.csv is saved at /home/db2inst1/ in your file system.
9 Summary
IBM DB2 for Linux, UNIX and Windows is an industry-leading database management system that has constantly delivered new
features to address ever-increasing demands and requirements on data. Database administrators and application developers
can reap immediate benefits from using DB2.
IBM Data Studio is a comprehensive database management tool that allows administrators and developers to effectively work
with DB2 databases.
In this lab, you have learned how to leverage Data Studio to perform basic tasks on DB2 such as:
• Establish a database connection
• Browse database objects
• Leverage task assistants to carry out administrative tasks
• Manage database changes with change plans
• Create and execute queries in SQL
• Analyze data access plan using Visual Explain
• Export query result for later use
10 Cleanup

IBM Software
1. To clean your environment after completing the exercise, right-click on DB2FUND database in the Administration
Explorer view and select Disconnect.
2. Next, close Data Studio and switch back to the terminal window that you have been using so far.
3. Finally, execute the commands below. Use “password” as password.
su –
cd /home/db2inst1/Documents/LabScripts/Fundamentals/setup
./cleanup.sh
4. If you would like to redo this lab in the future, please execute the following commands in a terminal window as root:
cd /home/db2inst1/Documents/LabScripts/Fundamentals/setup
./config.sh

IBM Software
© Copyright IBM Corporation 2012

All Rights Reserved.
IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada
IBM, the IBM logo, ibm.com and Tivoli are trademarks or registered
trademarks of International Business Machines Corporation in the
United States, other countries, or both. If these and other
IBM trademarked terms are marked on their first occurrence in this
information with a trademark symbol (® or ™), these symbols indicate
U.S. registered or common law trademarks owned by IBM at the time
this information was published. Such trademarks may also be
registered or common law trademarks in other countries. A current list
of IBM trademarks is available on the Web at “Copyright and
trademark information” at ibm.com/legal/copytrade.shtml
Other company, product and service names may be trademarks or

service marks of others.
References in this publication to IBM products and services do not

imply that IBM intends to make them available in all countries in which
IBM operates.
No part of this document may be reproduced or transmitted in any form

without written permission from IBM Corporation.
Product data has been reviewed for accuracy as of the date of initial
publication. Product data is subject to change without notice. Any
statements regarding IBM’s future direction and intent are subject to
change or withdrawal without notice, and represent goals and
objectives only.
THE INFORMATION PROVIDED IN THIS DOCUMENT IS

DISTRIBUTED “AS IS” WITHOUT ANY WARRANTY, EITHER
EXPRESS OR IMPLIED. IBM EXPRESSLY DISCLAIMS ANY
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE OR NON-INFRINGEMENT.
IBM products are warranted according to the terms and conditions of

the agreements (e.g. IBM Customer Agreement, Statement of Limited
Warranty, International Program License Agreement, etc.) under which
they are provided.

IBM Software
Multi-Temperature Data Management

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 About this Lab......................................................................................................................................................................................3
2.1 Environment Setup Requirements ...................................................................................................................................................................... 3
2.2 Preparing for the lab ........................................................................................................................................................................................... 3
3 Create and Manage Storage Groups .................................................................................................................................................4

3.1 DB2’s Default Storage Group – IMBSTOGROUP .............................................................................................................................................. 5
3.2 Create a Storage Group...................................................................................................................................................................................... 6
3.3 Choose a Different Storage Group as Default .................................................................................................................................................... 7
3.4 Associate a Table space to a Storage Group ..................................................................................................................................................... 8
3.4.1 Create new Table space..................................................................................................................................................................... 8
3.4.2 Move Table space to a new Storage Group ....................................................................................................................................... 9
3.5 Add/ Remove Storage Paths from a Storage Group .......................................................................................................................................... 9
3.5.1 Add storage paths to a storage group ................................................................................................................................................ 9
3.5.2 Remove storage path from a storage group ..................................................................................................................................... 10
3.6 Drop a Storage Group....................................................................................................................................................................................... 11
4 Multi-temperature Storage................................................................................................................................................................14
4.1 Create Storage Groups and Table Spaces for Q1 and Q2 ............................................................................................................................... 14
4.2 Start of the New Quarter ................................................................................................................................................................................... 15
5 Summary ............................................................................................................................................................................................17
6 Cleanup...............................................................................................................................................................................................17
Multi-temperature Data Management

IBM Software
1 Introduction
With data increasing at an exponential rate, management of the volumes of information in data warehouses is ever more critical.
There is a strong tendency for a relatively small proportion of data, within data warehouses, to be frequently accessed or be hot
data. Most of the data stored is infrequently access or cold data. This classification of multi-temperature data poses considerable
challenges for optimization of storage management. As the data warehouse consumes increasing amounts of storage,
optimizing the use of fast storage becomes increasingly important in managing storage costs.
The multi-temperature database storage feature in DB2 version 10 introduces a new way of prioritizing data and all activities
touching the data. It allows users to manage multiple tiers of storage devices effectively by introducing the concept of storage
groups.
2 About this Lab

In this lab you will explore the new concept of Storage Groups introduced in DB2 10. You learn how the automatic storage
management capabilities of the DB2 database manager significantly reduce the management costs associated with storage.
Currently, you can only specify a single set of storage paths for an automatic storage managed database. This restricts the
efficient use of drives of different speed and performance for data of varying priority. Through the usage of storage groups, the
user is allowed to group together storage paths for devices with similar characteristics and can control where the data resides.
This lab illustrates the ease in administration and management of storage groups and migration to start using storage groups.
2.1 Environment Setup Requirements

• DB2 10 VMware® image

• VMware Workstation 6.5 or later
2.2 Preparing for the lab
1. Start the VMware image by clicking the button in VMware Workstation if it is not already on.
2. Login to the VMware virtual machine using the following information:
• User: db2inst1
• Password: password
3. Open a terminal window by right-clicking on the Desktop area and choose the “Open in Terminal” item.

IBM Software
Figure 1: Open terminal

4. Start the DB2 server
db2start
5. The file paths to be assigned to storage groups through out the lab have already been created. Navigate to the folder
that contains all the storage paths used within this lab:
cd /home/db2inst1/mtsdb/
Figure 2: List of storage paths created
6. All scripts used during the lab reside within the LabScripts folder. Navigate to the following location:
cd /home/db2inst1/Documents/LabScripts/Multi_Temp_Storage/
3 Create and Manage Storage Groups

The distribution of data into various classes of storages can be done using storage groups introduced in DB2 10.
A storage group is a new layer of abstraction encompassing table spaces. It acts as a named set of storage paths where data
can be stored and can be configured to represent different classes of storage. Each storage group can have its own unique
characteristics, and you can define which table spaces reside within each storage group.
In this section, we will demonstrate how to create and alter the characteristics of a storage group. To demonstrate how to create
and manage storage groups we will perform a series of operations on the database MTSDB, which we have created for your
convenience.

IBM Software
3.1 DB2’s Default Storage Group – IMBSTOGROUP
When you create a database, a default storage group named IBMSTOGROUP is automatically created. This storage group is
created within the storage paths that were specified at the time of the database creation. There can only be one storage group
designated as the default storage group.
NOTE: 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
1. Connect to the database MTSDB

db2 connect to MTSDB
2. To view the default, IBMSTOGROUP storage group, execute the following SQL statements.
db2 "SELECT VARCHAR(STORAGE_GROUP_NAME, 30) AS STOGROUP,
VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH
FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-2)) AS T"
The ADMIN_GET_STORAGE_PATHS function returns a list of automatic storage paths for each database storage
group, including file system information for each storage path. /db2fs is the storage path specified as the storage path
for the default storage group.
db2inst1@db2v10:~> db2 "SELECT VARCHAR(STORAGE_GROUP_NAME, 30) AS STOGROUP,
VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-2)) AS
T"
STOGROUP STORAGE_PATH
------------------------------ ----------------------------------------
IBMSTOGROUP /home/db2inst1
1 record(s) selecte
Figure 3: storage path for the default IBMSTOGROUP
This default storage group is used when an automatic storage managed table space is created without explicitly
specifying the storage group.
3. To view the table spaces automatically created for the MTSDB database, within IBMSTOGROUP, execute the following
command. You will see that all table spaces created within the database reside in the DB2 default storage group.
db2 "SELECT varchar(tbsp_name, 30) as tbsp_name, storage_group_name FROM
TABLE(MON_GET_TABLESPACE('',-2)) AS t WHERE t.tbsp_using_auto_storage = 1 and
t.storage_group_name = 'IBMSTOGROUP'"

IBM Software
TBSP_NAME STORAGE_GROUP_NAME
------------------------------ --------------------------------------------------------------------------------------------------------------------------------
SYSCATSPACE IBMSTOGROUP
TEMPSPACE1 IBMSTOGROUP
USERSPACE1 IBMSTOGROUP
IBMDB2SAMPLEREL IBMSTOGROUP
IBMDB2SAMPLEXML IBMSTOGROUP
SYSTOOLSPACE IBMSTOGROUP
6 record(s) selected.
Figure 4: Table spaces created by default within IBMSTOGROUP
3.2 Create a Storage Group

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
In this sub-section, we will create new storage groups and specify their media attributes which distinguish each group by its
quality of service characteristics. SG_HIGH caters to fast devices such as solid state storage devices while midrange
performance devices such as fiber channel disks can be assigned to SG_MEDIUM for efficient usage of your physical storage.
1. Create two different storage groups each with its own media attributes.
db2 "create stogroup sg_high on '/home/db2inst1/mtsdb/fastpath1' device read
rate 500 overhead 0.75"
db2 "create stogroup sg_medium on '/home/db2inst1/mtsdb/medpath1'"
When no media attributes are defined, DB2 uses the following defaults.
Media Attribute Default Setting
Data Tag NONE
Device Read Rate 100 MB/sec
Overhead 6.725 ms
Attention: as all storage paths are defined on the same machine, this lab will not show the performance aspect
of data accessed on storage groups with varying performance characteristics
2. View the newly created storage groups along with the storage paths specified.

IBM Software

VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH FROM
TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T"

VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS
T"
------------------------------ ----------------------------------------
SG_HIGH /home/db2inst1/mtsdb/fastpath1
SG_MEDIUM /home/db2inst1/mtsdb/medpath1
Figure 5: Storage paths for new Storage Groups
3.3 Choose a Different Storage Group as Default

You can designate a default storage group of your choice, 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.
1. Alter the SG_HIGH storage group and assign it as the new default storage group.
db2 alter stogroup sg_high set as default
Any new automatic storage table space created will be assigned to this storage group, unless a storage group
assignment was specified, at the time of creation.
db2inst1@db2v10:~> db2 alter stogroup sg_high set as default

DB20000I The SQL command completed successfully.
Figure 6: Assign SG_HIGH as the new Default Storage Group
2. Create a table space without specifying a storage group. It will be placed in SG_HIGH
db2 create tablespace tbsp_test_default
3. Now check the table spaces residing within the storage group SG_HIGH using the MON_GET_TABLESPACE
administrative view. It provides table space metrics and can be used to verify the table spaces assigned to particular
storage groups.
t.storage_group_name = 'SG_HIGH'"

IBM Software
------------------------------ ------------------------------------
TBSP_TEST_DEFAULT SG_HIGH
Figure 7: table space placed in new default storage group
3.4 Associate a Table space to a Storage Group
In this sub-section we will demonstrate how to associate a table space to a storage group. A new table space can be assigned
to a storage group using the CREATE TABLESPACE statement or an existing table space can be associated using the ALTER
TABLESPACE statement to specify or change the storage group the table space uses.
3.4.1 Create new Table space
We will create a new table space TBSPC_HIGH and assign it to the SG_HIGH storage group. This table space has the option to
inherit the media attributes from the storage group or specify its own.
1. Execute the CREATE TABLESPACE statement

db2 create tablespace tbspc_high using stogroup sg_high overhead inherit
transferrate inherit
In the statement above, we have chosen to inherit the media attributes of the storage group. The automatic storage
table space created, inherits the overhead and transfer rate attributes from the storage group it is assigned to. When a
table space inherits the transfer rate, the storage group’s device read rate (sg_high: 500 MB/sec) is converted to
milliseconds per page read, using the page size setting of the table space.
db2inst1@db2v10:~> db2 create tablespace tbspc_high using stogroup sg_high overhead

inherit transferrate inherit
Figure 8: Assign tbspc_high to the storage group sg_high
2. To check if this table space has been correctly assigned to the storage group SG_HIGH, execute the statement from
section 3.3, step 3. The newly added table space is shown in the result below.
------------------------------ ----------------------------------
TBSP_TEST_DEFAULT SG_HIGH
TBSPC_HIGH SG_HIGH
Figure 9: tbspc_high is assigned the storage group sg_high

IBM Software
3.4.2 Move Table space to a new Storage Group
Pre-existing table spaces can be moved to a different storage group. In this scenario we will show you how an existing table
space can be converted to start using a new storage group. We will be converting the existing table space
IBMDB2SAMPLEXML which currently resides within the storage group; IBMSTOGROUP
1. Use the ALTER TABLESPACE statement below to move an existing table space to a different storage group.
db2 "ALTER TABLESPACE IBMDB2SAMPLEXML USING STOGROUP sg_medium"
After the ALTER TABLESPACE statement is committed, containers are allocated on the new storage group’s storage
paths, the existing containers residing in the old storage group are marked as drop pending, and an implicit
REBALANCE operation is initiated. This operation allocates containers on the new storage path and rebalances the
data from the existing containers into the new containers. Once the move is complete, the old containers are dropped.
2. To verify the move is complete, check the storage group assignment of the table space by calling the
MON_GET_TABLESPACE administrative view.
t.storage_group_name = 'SG_MEDIUM' "
db2inst1@db2v10:~> db2 "SELECT varchar(tbsp_name, 30) as tbsp_name, storage_group_name

FROM TABLE(MON_GET_TABLESPACE('',-2)) AS t WHERE t.tbsp_using_auto_storage = 1 and
t.storage_group_name = 'SG_MEDIUM' "
------------------------------ -------------------------------------------------------
IBMDB2SAMPLEXML SG_MEDIUM
Figure 10: IBMDB2SAMPLEXML has successfully moved to storage group SG_MEDIUM
3.5 Add/ Remove Storage Paths from a Storage Group

A storage group can be modified to add or remove storage paths as the need arises. The ALTER STOGROUP statement allows
for the addition or removal of storage paths. We will use the table space from the previous example that now resides within the
storage group SG_MEDIUM.
3.5.1 Add storage paths to a storage group

1. Add storage paths to the storage group SG_MEDIUM by issuing the following ALTER STOGROUP statement.
db2 "ALTER STOGROUP sg_medium add '/home/db2inst1/mtsdb/medpath2',
'/home/db2inst1/mtsdb/medpath3'"
Attention: All paths assigned to a storage group should have similar media characteristics: underlying disks,
latency, device read rate, and size. Non-uniform media characteristics may result in performance inconsistency.

IBM Software
After adding one or more storage paths to the storage group, you can optionally use the ALTER TABLESPACE
statement to rebalance table spaces to immediately start using the new storage paths. Otherwise, the new storage
paths are used only when there is no space in the containers on the existing storage paths.
2. To determine the table spaces which require an explicit REBALANCE, you can issue the command shown in 3.4.2 to
list the table spaces within the storage group SG_MEDIUM. You do not have to re-execute this command, as we know
that the table space IBMDB2SAMPLEXML resides within this storage group.
Rebalance the data within the table space.
db2 "ALTER TABLESPACE IBMDB2SAMPLEXML REBALANCE"
db2inst1@db2v10:~> db2 "ALTER TABLESPACE IBMDB2SAMPLEXML REBALANCE"

Figure 11 Rebalance issued for IBMDB2SAMPLEXML
3.5.2 Remove storage path from a storage group
When intending to drop a storage path, you must rebalance all permanent table spaces that use the storage path. The rebalance
is needed to move data off the path to be dropped. In this situation, the rebalance operation moves data from the storage path
that you intend to drop to the remaining storage paths and keeps the data striped consistently across those storage paths,
maximizing I/O parallelism. To demonstrate this procedure, we will proceed to drop the newly added storage path.
1. To drop storage paths from a storage group, issue the following ALTER STOGROUP statement:
db2 "ALTER STOGROUP sg_medium drop '/home/db2inst1/mtsdb/medpath3'"
db2inst1@db2v10:~> db2 "ALTER STOGROUP sg_medium drop '/home/db2inst1/mtsdb/medpath3'"

SQL2095W Storage path "/home/db2inst1/mtsdb/medpath3" is in the drop pending
state because one or more automatic storage table spaces reside on the path.
SQLSTATE=01691
Figure 12: Drop-pending state for storage path after being dropped
2. The following command shows you the storage path marked as DROP_PENDING
VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH, DB_STORAGE_PATH_STATE AS STATE
FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T WHERE T.STORAGE_GROUP_NAME =
'SG_MEDIUM'"
db2inst1@db2v10:~> db2 "SELECT VARCHAR(STORAGE_GROUP_NAME, 30) AS STOGROUP, VARCHAR(DB_STORAGE_PATH,
40) AS STORAGE_PATH, DB_STORAGE_PATH_STATE AS STATE FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T
WHERE T.STORAGE_GROUP_NAME = 'SG_MEDIUM'"
STOGROUP STORAGE_PATH STATE

------------------------------ ---------------------------------------- ----------------
SG_MEDIUM /home/db2inst1/mtsdb/medpath1 IN_USE
SG_MEDIUM /home/db2inst1/mtsdb/medpath2 IN_USE
SG_MEDIUM /home/db2inst1/mtsdb/medpath3 DROP_PENDING
Figure 13: Storage path shown in DROP_PENDING State

IBM Software
3. To remove the path, rebalance the containers of the storage path being dropped. To determine all the affected
permanent table spaces in the database that have containers residing on a "Drop Pending" path, call the
MON_GET_TABLESPACE administrative view. (not shown)
Once the table spaces have been identified, you can perform the following statement for each of the table spaces listed:
db2 "ALTER TABLESPACE IBMDB2SAMPLEXML REBALANCE"
After the rebalance operation is complete, /home/db2inst1/mtsdb2/medpath3 is removed from the storage
group.
4. To confirm that the storage path was dropped, verify the assigned storage paths for storage group SG_MEDIUM
VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH FROM
TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T
WHERE T.STORAGE_GROUP_NAME = 'SG_MEDIUM'"
------------------------------ ----------------------------------------
Figure 14: Storage path medpath3 has been dropped
3.6 Drop a Storage Group

When your storage management needs require you to remove a storage group, you need to determine if that storage group is in
use. Prior to the drop, all its table spaces need to be assigned to another storage group.
Attention: You cannot drop the current Default Storage Group
1. Find the table spaces that are using the storage group. In our case we are going to drop SG_MEDIUM and it currently
holds the IBMDB2SAMPLEXML table space, as shown in the previous sections.
In the case of temporary table spaces residing within the storage group, you would be required to drop the temporary
table spaces and re-create them within the target storage group, where the data is being transferred to.
2. In earlier operations, we have not shown a way to monitor the rebalance activity for the data movement involved in
assigning a table space to a different storage group.
The next sequence of steps showcases monitoring of the rebalance activity for the table space being moved. Follow the
series of steps outlined.
a. Open a new Terminal, by Right-Clicking on the Desktop screen.

IBM Software
Figure 15: Launch new terminal

b. Connect to the database MTSDB
db2 connect to mtsdb
c. Copy the following statement to monitor the rebalance activity for the storage group to be dropped. Do not execute
the command, at this time. The result will show a rebalance status of Active, while data is being moved over to
the target storage group.
db2 "SELECT tbsp_name, rebalancer_source_storage_group_name as sg_source,
rebalancer_target_storage_group_name as sg_target, rebalancer_status as
status from table(mon_get_rebalance_status('',-2)) as T WHERE
T.REBALANCER_SOURCE_STORAGE_GROUP_NAME= 'SG_MEDIUM'"
An empty result state indicates that the table space has finished moving to the new target storage group.
d. In the previous Terminal, enter the ALTER TABLESPACE command to assign the table space to a different
storage group. In this case, we return the table space to its original storage group.
db2 "ALTER TABLESPACE IBMDB2SAMPLEXML USING STOGROUP IBMSTOGROUP"
e. In quick succession, execute both commands on their respective terminals. You will see the following output for the
Rebalance query, when the ALTER TABLE SPACE command begins execution.

IBM Software
Figure 16: Data is being rebalanced on the target storage group
f. When you execute the REBALANCE query again, you will notice an empty state with no record. The move is
complete.
g. To verify this, you can execute the ADMIN_GET_STORAGE_PATHS command, showcased in the earlier section;
3.2 step 2. You will see that SG_MEDIUM is no longer in use. The result is shown below for your convenience.

VARCHAR(DB_STORAGE_PATH, 40) AS STORAGE_PATH FROM TABLE(ADMIN_GET_STORAGE_PATHS('',-1)) AS T"
------------------------------ ----------------------------------------
SG_HIGH /home/db2inst1/mtsdb/fastpath1
Figure 17: SG_MEDIUM is no longer in use

3. In the current terminal window, proceed to drop the storage group SG_MEDIUM.

IBM Software
db2 DROP STOGROUP SG_MEDIUM

4. Close the current terminal by clicking on the button, on the top right corner of the window.
4 Multi-temperature Storage
Having covered the basics involved in managing storage groups and table spaces within them, we proceed to a scenario where
storage of data is managed leveraging the concepts introduced in the earlier sections. We illustrate the use of storage groups
with multi-temperature data.
Assume that you are the DBA for a business that does most of its processing on current-fiscal-quarter data. This business has
enough solid-state drive (SSD) capacity to hold data for an entire quarter and enough Fiber Channel-based (FC) and Serial
Attached SCSI (SAS) drive capacity to hold data for the remainder of the year.
You then take the following actions:

• Create two storage groups for the two types of storage within your organization
• Create table spaces for data accumulated within each quarter
• Assign the table space containing the data for the current quarter to the SG_HOT storage group
• Assign the table space containing the data for the previous quarters to the SG_WARM storage group
4.1 Create Storage Groups and Table Spaces for Q1 and Q2

In this section you will create all the necessary database objects required in this scenario. The following script creates the two
storage groups SG_HOT and SG_WARM. The table spaces for Q1 and Q2 are created and populated with sales data for each
quarter.
1. Navigate to the folder containing the script
cd /home/db2inst1/Documents/LabScripts/Multi_Temp_Storage
2. Execute the following script:
db2 -tvf Create_Grps_Tbspcs_Q1Q2.sql
You can scroll through the output of this script to see the newly created database objects. Upon completion, you will have
two new table spaces. Each table space resides in a storage group created to cater to its frequency of access requirements.

IBM Software
Figure 18: Excerpt from the script output

Attention: You might notice that some rows failed, this is due to the data set containing rows out of the date
range required for the Q1 and Q2 quarters. These rows can be ignored.
4.2 Start of the New Quarter

As the third quarter sales data is available, data is attached to the existing partitioned table. The one set of the new quarter
requires for data to be moved between storage groups. To do this, data for the previous quarter is moved to the slower storage,
SG_WARM and a new table space for Q3 is created within the faster storage group SG_HOT.
• Move q2_tbsp to the slower storage group

• Create new table space q3_tbsp for data accumulated for the third and current quarter
• Assign the table space containing the data for the current quarter to the SG_HOT storage group
• Create a Recent_Sales table and populate with data for Q3
• Attach the data within Recent_Sales data to the Sales table as a partition of data for Q3
1. An ALTER TABLESPACE statement is used to move the existing table space q2_tbsp to SG_WARM.
db2 "ALTER TABLESPACE q2_tbsp USING STOGROUP SG_WARM"
2. To monitor the move of data, you can follow step 2 of section 3.6. The output is shown below.

IBM Software
db2inst1@db2v10:~/Documents/LabScripts/Multi_Temp_Storage> db2 "SELECT VARCHAR(tbsp_name, 30) AS

tbsp_name, storage_group_name FROM TABLE(MON_GET_TABLESPACE('',-2)) AS t WHERE
t.tbsp_using_auto_storage = 1 AND t.storage_group_name = 'SG_WARM'"
------------------------------ ------------------------------------------------------------------
Q1_TBSP SG_WARM
Q2_TBSP SG_WARM
Figure 19: q2_tbsp is rebalanced on storage group sg_warm

3. Execute the following script to create the new table space for Q3 and populate it with data as outlined above:
db2 -tvf createQ3tbsp.sql
You can scroll through the output of this script to see the newly created database objects. Upon completion, you will
have a new table space within the storage group SG_HOT.
Figure 20: Excerpt from the script output

This concludes the process of moving data between storage groups as it ages within an organization. As the data
residing in q2_tbsp grew less important, it was moved to slower storage. Faster storage being used for storage group
SG_HOT was reserved for the current quarter q3_tbsp.
4. Execute the following command to retrieve the final storage group configuration.
t.storage_group_name = 'SG_HOT' or t.storage_group_name = 'SG_WARM'"

IBM Software
db2inst1@db2v10:~/Documents/LabScripts/Multi_Temp_Storage> db2 "SELECT varchar(tbsp_name, 30) as

tbsp_name, storage_group_name FROM TABLE(MON_GET_TABLESPACE('',-2)) AS t WHERE
t.tbsp_using_auto_storage = 1 and t.storage_group_name = 'SG_HOT' or t.storage_group_name =
'SG_WARM'"
------------------------------ ----------------------------------------------------------------------
----------------------------------------------------------
Q1_TBSP SG_WARM
Q2_TBSP SG_WARM
Q3_TBSP SG_HOT
Figure 21: Organization of table spaces among storage groups
5 Summary
The intent of this lab was to acquaint the user with the new concepts introduced in DB2 10. Multi-temperature data management
allows the user to configure the database in a manner which optimizes the use of fast storage and effectively reduces storage
costs. The addition of storage groups as sets of storage paths with similar qualities now allows the user to map different classes
of storage according to their respective performance and reliability requirements.
To further improve the performance of data, the power of data tags and the new data-centric view for workloads can be
leveraged. Different table spaces within the same storage group can be prioritized based on their data tag values.
6 Cleanup
1. To clean your environment after completing the exercise, execute the command below. Use “password” as password.
su –
cd /home/db2inst1/Documents/LabScripts/Multi_Temp_Storage/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/Multi_Temp_Storage/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
DB2® Essential Maintenance & Practical Autonomics

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 About this Lab......................................................................................................................................................................................3
3 Basic Set up and Start of Lab.............................................................................................................................................................3
3.2 Preparation Step ................................................................................................................................................................................................. 4
3.3 Launching Data Studio........................................................................................................................................................................................ 4
3.4 The LABDB Database......................................................................................................................................................................................... 6
4 Configuration Advisor.........................................................................................................................................................................7
4.1 Optimize Database Using Configuration Advisor................................................................................................................................................ 7
5 REORGCHK, REORG and RUNSTATS ..............................................................................................................................................8

5.1 REORGCHK ....................................................................................................................................................................................................... 9
5.2 Reorganizing Tables/Indexes (REORG)............................................................................................................................................................. 9
5.3 Updating Optimizer Statistics (RUNSTATS) ..................................................................................................................................................... 10
6 Set Up Automatic Maintenance for the LABDB Database.............................................................................................................11

6.1 Connect to the LABDB Database ..................................................................................................................................................................... 11
6.2 Selecting Automatic Maintenance Options ....................................................................................................................................................... 13
6.3 Selecting the Online Maintenance Window ...................................................................................................................................................... 15
6.4 Selecting the Offline Maintenance Window ...................................................................................................................................................... 17
6.5 Perform Maintenance Selection against LABDB .............................................................................................................................................. 19
6.6 Enabling Utility Throttling .................................................................................................................................................................................. 21
7 Design Advisor ..................................................................................................................................................................................22

7.1 Create the Explain Tables................................................................................................................................................................................. 22
7.2 Design Advisor Recommendations................................................................................................................................................................... 22
7.3 Executing the Query and Seeing Buffer Pool Memory Changes ...................................................................................................................... 27
8 Self-Tuning Memory Manager (STMM) ............................................................................................................................................28

8.1 Connect to the LABDB Database and Examine the Database Configuration Parameters............................................................................... 28
9 Data Movement Tools (optional exercise).......................................................................................................................................30

9.1 EXPORT Utility ................................................................................................................................................................................................. 30
9.2 IMPORT Utility .................................................................................................................................................................................................. 31
9.3 LOAD Utility ...................................................................................................................................................................................................... 32
9.4 INGEST Utility................................................................................................................................................................................................... 33
10 Summary ............................................................................................................................................................................................33
11 Cleanup...............................................................................................................................................................................................33
DB2 Essential Maintenance & Practical Autonomics

IBM Software
1 Introduction
Today's business challenges require that databases be optimized for the best possible performance. The database engine must
be highly tuneable and easily configurable for the best performance regardless of the skill level of the DBA. To face these
challenges, DB2 comes with a rich set of autonomic features for tuning the configuration parameters adaptively and accurately.
2 About this Lab

In this lab, you will explore some of the autonomic computing capabilities of DB2 that help reduce skill requirements while
ensuring reliability and availability of your mission critical environment. After completing this lab, you will be able to use the
following tools:
• Configuration Advisor
• REORGCHK, REORG and RUNSTATS
• Utility Throttling
• Automatic Maintenance
• Design Advisor
• Self-Tuning Memory Manager (STMM)
• Data Movement Tools
The exercises in this lab are designed to give you a good idea of the features available with DB2 autonomics. Note that this lab
will not necessarily cover the approach you would take to initially configure a data server; however, it will give you a good idea of
some necessary steps required to use each of these useful autonomic features.
3 Basic Set up and Start of Lab

The lab consists of a series of tasks, each highlighting one or more concepts of the DB2 Practical Autonomics described in the
introduction.
Some of the commands and queries required to perform certain parts of certain tasks are quite long. In order to avoid having to
type these longer commands, we have provided you with scripts for some of these tasks. They are located in the
/home/db2inst1/Documents/LabScripts/Autonomics directory.
To complete this lab you will require the following:


IBM Software
3.2 Preparation Step
2. At the login prompt, login with the following credentials:
• Username: db2inst1
3. Open a terminal window as follows by right-clicking on the Desktop and choosing the Open in Terminal item.
Figure 1 – Opening a Terminal
3.3 Launching Data Studio
1. Double-click on the IBM Data Studio icon on the Desktop.
Figure 2 – IBM Data Studio Desktop Icon

2. In the Select a workspace dialog, accept the default path and click OK.

IBM Software
Figure 3 – Workspace Launcher
3. Data Studio should now start in the Database Administration perspective as shown below.
Figure 4 – IBM Data Studio, Database Perspective

IBM Software
If you are not in Database Administration perspective, you can easily change the perspective of Data Studio by click the
Open Perspective button as shown below and selecting Database Administration from the list.
Figure 5 – Changing Perspectives
3.4 The LABDB Database
Throughout this lab we will be working with a database named LABDB that contains several table spaces and is managed by
automatic storage. We will use this database to describe all of the autonomics components described above by executing
various queries on this database throughout the lab. This database has already been set up and is ready to use.
1. Open up a new terminal window or use the terminal window from the beginning of the lab.
2. Change your current directory to the directory containing all the scripts for this lab:
cd /home/db2inst1/Documents/LabScripts/Autonomics
3. Use gedit to view the contents of the create_db_labdb.sql script by executing the following command:
gedit create_db_labdb.sql &
The following should display:
drop db labdb;
create db labdb on /db2fs/db2inst1/sp1 , /db2fs/db2inst1/sp2 using codeset UTF-8
territory US;
connect to labdb;
create schema vps;
create schema dupvps;
create bufferpool VPSBUFF immediate size automatic pagesize 16k;
create tablespace VPSLARGE pagesize 16k managed by database using (file
'/db2fs/db2inst1/tempspace' 300) bufferpool VPSBUFF AUTORESIZE YES;
create tablespace vpsspc1 pagesize 16k managed by automatic storage autoresize yes
bufferpool VPSBUFF;
create tablespace vpsspc2 pagesize 16k managed by automatic storage bufferpool
VPSBUFF;
create tablespace vpsspc3 pagesize 16k managed by automatic storage bufferpool
VPSBUFF;
update dbm cfg using SHEAPTHRES 0;
Note:
• Automatic Storage is enabled by default when creating a database unless it is explicitly turned off.
• The database manager SHEAPTHRES parameter is set to zero. This is to enable sort memory tuning
(SORTHEAP) for optimal configuration parameter settings when using the configuration advisor.

IBM Software
4 Configuration Advisor
DB2 configuration parameters play an important role in performance as they affect the operating characteristics of a database or
database manager. The Configuration Advisor makes recommendations on the initial settings for configuration parameters that
can be easily adopted by inexperienced administrators or fine-tuned by more experienced administrators. We will see in this
section how the Configuration Advisor (invoked via the AUTOCONFIGURE command) can generate values for various
performance critical parameters.
4.1 Optimize Database Using Configuration Advisor
A good place to start with this database is to run the AUTOCONFIGURE command on a database which will recommend
enablement of the Self Tuning Memory Manager (STMM). We will be covering STMM later in this lab.
Although when a database is created, the Configuration Advisor runs automatically, explicitly invoke the Configuration Advisor
using the command below.
1. Execute the following two commands in a terminal:
db2 connect to labdb
db2 "AUTOCONFIGURE APPLY DB AND DBM"
More configuration parameters are available for the AUTOCONFIGURE command; however, by not specifying them, the
defaults are accepted. The following should output:
Former and Applied Values for Database Manager Configuration
Description Parameter Former Value Applied Value

-------------------------------------------------------------------------------------------------
Application support layer heap size (4KB) (ASLHEAPSZ) = 15 15
No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = AUTOMATIC AUTOMATIC
Enable intra-partition parallelism (INTRA_PARALLEL) = NO NO
Maximum query degree of parallelism (MAX_QUERYDEGREE) = 1 1
Agent pool size (NUM_POOLAGENTS) = AUTOMATIC(100) AUTOMATIC(100)
Initial number of agents in pool (NUM_INITAGENTS) = 0 0
Max requester I/O block size (bytes) (RQRIOBLK) = 32767 32767
Sort heap threshold (4KB) (SHEAPTHRES) = 0 0
Former and Applied Values for Database Configuration
Description Parameter Former Value Applied Value

-------------------------------------------------------------------------------------------------
Default application heap (4KB) (APPLHEAPSZ) = 256 256
Catalog cache size (4KB) (CATALOGCACHE_SZ) = 30 300
Changed pages threshold (CHNGPGS_THRESH) = 80 80
Database heap (4KB) (DBHEAP) = 1200 4465
Degree of parallelism (DFT_DEGREE) = 1 1
… … = … …
Note: These results may vary since the system defaults are being used by the AUTOCONFIGURE statement.
Also, the above command can be executed anytime if you feel your system performance is not optimized to its
maximum capabilities.
2. Restart the instance for the changes to take affect by issuing the following commands in the terminal:

IBM Software
db2 FORCE APPLICATION ALL

db2stop
db2start
Note: We issued the first command to force/release all applications (users) off the database for proper
restart of the instance.
You can view and verify the database and database manager configuration parameters by issuing the statements GET DB
CFG and GET DBM CFG respectively.
5 REORGCHK, REORG and RUNSTATS

Before you continue with the rest of this lab, you need to load sample data into LABDB. To achieve this, a script has been
written for this task.
1. In the terminal window, ensure that you are in directory /home/db2inst1/Documents/LabScripts/Autonomics, execute
script PopulateDB.sh as the following
./PopulateDB.sh
2. You will be prompted for some information regarding the size of the relational data that you would like to load. For this
particular section in the lab we will input 100MB as the amount of data that we would like to insert into our database.
Size of Relational Data (MBs):
100
After some time, the following should display, indicating that everything has been processed successfully:
- Summary -
OLTP Size: 100
XML Size: 0
User: db2inst1
Pass: password
Port: 50001
Creating data tables...[DONE]

Starting OLTP Data Creation...[DONE]
Loading data into tables...[DONE]
Performing integrity check...[DONE]
Creating indexes...[DONE]
Creating stored procedures...[DONE]
LABDB Database population completed.
Removing flatfiles...[DONE]
LABDB Database population completed.
All DB2 commands have been logged to VPS_Setup.log
All of the above steps should complete successfully, with the [DONE] tag beside them

IBM Software
5.1 REORGCHK
The REORGCHK command interrogates database metadata and statistics on the database to determine and report on if tables or
indexes, or both, need to be reorganized or cleaned up.
You will run the REORGCHK command twice. The first time you will use the current statistics for the database then you will supply
an option that will update the statistics before checking to see if a REORG or cleanup is recommended.
1. Run the reorgchk command to verify whether reorganizing the table is necessary.
db2 REORGCHK CURRENT STATISTICS ON TABLE vps.stock
2. Results show that the table does not require a reorg. But a reorg was being recommended for one of the indexes F4.
F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80
… …
CLUSTERRATIO or normalized CLUSTERFACTOR (F4) will indicate REORG is necessary

for indexes that are not in the same sequence as the base table. When multiple
indexes are defined on a table, one or more indexes may be flagged as needing
REORG. Specify the most important index for REORG sequencing.
3. The UPDATE STATISTICS parameter calls the RUNSTATS routine first to update table and index statistics, and then
uses the updated statistics to determine if table or index needs reorganization. Enter the following command on a single
line.
db2 REORGCHK UPDATE STATISTICS ON TABLE vps.stock
Both files show similar results for both commands. This is due to the fact that a small table with relatively simple
statistics has been checked for reorganization.
Note: You should note that updating the statistics at the wrong time can result in moderate to significant
resource contention on your system. An alternate approach would be to enable automatic statistics collection.
This will ensure that statistics are accurate, current and run with an internally capped limit (about 7%) on the
amount of resources it will consume. The RUNSTATS command when run on its own has an option to run with
throttled resource consumption (Utility Impact Priority). It can also employ sampling techniques to reduce its
impact while maintaining accuracy. The update statistics command will use the default setting for updating
statistics and has no throttling available, but it is a pretty fast way to update statistics for all tables or all tables
in a particular schema.
5.2 Reorganizing Tables/Indexes (REORG)
The REORG command is used to reorganize (defragment) an index or a table.
INDEX
Reorganizing indexes rebuilds the index’s leafs eliminating deleted RIDs, reclaiming space and possibly reducing the number of
levels in structure of the index.
IBM Software
1. Execute the following in the terminal window to reorganize all indexes for table INVENT.
db2 REORG INDEXES ALL FOR TABLE vps.invent
A successful message should appear
DB20000I The REORG command completed successfully.
TABLE
Running a reorg for a table, reconstructs, or rebuilds the rows, compacting the table, eliminating fragmented and unused space.
In addition, if your table is defined with row compression ON, you can rebuild the data compression dictionary and recompress
the data based on the new dictionary. Lastly a reorganization of a table can be used to physically sort the data according to a
specified clustering index to improve performance.
2. Execute the following in the terminal window to reorganize table INVENT.
db2 REORG TABLE vps.invent
A successful message similar to the one above should be displayed.
5.3 Updating Optimizer Statistics (RUNSTATS)
Database statistics should be gathered regularly as required and preferably in a throttled mode so as to not use excessive
resources in the process. There are other special circumstances when you may want to explicitly run an update of a table’s and
indexes’ statistics:
1. After a table had a lot of updates like a batch update for a new column.
2. A reload of data or after you reorganize the table.
You can base the statistics on a sample or a percentage of the data in a table or an index. DB2's RUNSTATS command offers
two types of sampling: Bernoulli and System. Bernoulli sampling evaluates a sample set of rows from the table. System
sampling evaluates a sample set of data pages. System sampling introduces less overhead than Bernoulli sampling but may not
produce as accurate results when your data is highly clustered since it may sample pages where data is clustered such that
statistics are skewed
1. Enter the following command in your terminal window to update STOCK 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.
db2 "RUNSTATS ON TABLE vps.stock AND INDEXES ALL TABLESAMPLE SYSTEM(1.5)

INDEXSAMPLE SYSTEM(2.5) "
A successful message should appear
DB20000I The RUNSTATS command completed successfully.

IBM Software
6 Set Up Automatic Maintenance for the LABDB Database

DB2 provides automatic maintenance capabilities for performing database backups, keeping statistics current and reorganizing
tables and indexes as necessary. Performing maintenance activities on your databases is essential to ensure that it is optimized
for performance and recoverability. Enablement of the automatic maintenance features is controlled using the automatic
maintenance database configuration parameters. These are a hierarchical set of switches to allow for simplicity and flexibility in
managing the enablement of these features.
Automatic maintenance is enabled by default however, only the automatic RUNSTATS feature is ON by default.
Configure Automatic Maintenance for other maintenance activities like BACKUP, REORG, STATS_PROF and PROF_UPD by
following the sections below.
6.1 Connect to the LABDB Database
1. Go back to Data Studio and connect to the LABDB database by navigating to the Administration Explorer on the top left
hand side of Data Studio. Navigate under All Databases > localhost > 5001 to find the LABDB database. Right-click on
LABDB and click Connect.
Figure 6 – Connecting to a Database

In the Properties for LABDB window, specify the following credentials:
• Host: localhost
• Portnumber: 50001

IBM Software
2. After the connection has successfully completed, launch DB2 Automatic Maintenance by right-clicking on the LABDB
artefact and select Set Up and Configure > Configure Automatic Maintenance….
Figure 7 – Selecting to Configuring Automatic Maintenance

3. The Configure Automatic Maintenance LABDB tab will appear.

IBM Software
Figure 8 – Configuring Automatic Maintenance Window
6.2 Selecting Automatic Maintenance Options
Configure Automatic Maintenance by following the below steps:

1. Read the Introduction section at the top of the tab to learn about DB2 automatic maintenance. If not already selected,
click on the Options menu item to receive a list of all maintenance options that could be activated.

IBM Software
Figure 9 – Options for Automatic Maintenance

2. Select the maintenance activities that you wish to automate. In this case, select all activities by clicking the radio box
beside the name (AUTO_MAINT, AUTO_DB_BACKUP, AUTO_TBL_MAINT, AUTO_REORG, AUTO_STATS_PROF,
AUTO_PROF_UPD, AUTO_RUNSTATS, AUTO_STMT_STATS). As mentioned in the introduction, some of these are
already selected because they are activated by default when creating a database.

IBM Software
Figure 10 – Selecting Automatic Maintenance Options
Note: If AUTO_MAINT is turned off then all other options will become disabled. This is because this option is
necessary for the others to be active, hence the hierarchy. A similar situation occurs for the AUTO_TBL_MAINT
option and AUTO_REORG, AUTO_STATS_PROF, AUTO_PROF_UPD, AUTO_RUNSTATS, and AUTO_STMT_STATS.
6.3 Selecting the Online Maintenance Window
By defining the online maintenance window we will be able to select a time when the maintenance activities can be performed
while the database is online. This is only used when DB2 determines that maintenance is necessary.
1. Select the Online Maintenance Window menu option to receive the following screen.

IBM Software
Figure 11 – Selecting the Online Maintenance Window

2. Select the Create or update the maintenance window checkbox to select a time slot.
3. Specify any Start Time and Duration for the online maintenance activity. You can also specify the Days of the week or
Days of the Month for these activities to run. Select any days/months you would like.

IBM Software
Figure 12 – Selecting the Online Maintenance Window Options

For the purpose of this document we selected:
• Start time: 12:00:00 AM
• Duration (number of hours): 2
• Days of the week: Friday, Saturday and Sunday
• Days of the month: All
Review the maintenance windows you have selected.
6.4 Selecting the Offline Maintenance Window

IBM Software
It is also possible to define an offline maintenance window to perform maintenance on the database when it goes offline.
1. Select the Offline Maintenance Window menu option to receive the following screen.
Figure 13 – Selecting the Offline Maintenance Window

2. Select the Create or update the maintenance window checkbox to select a time slot.
3. Specify any Start Time and Duration for the online maintenance activity. You can also specify the Days of the week or
Days of the Month for these activities to run. Select any days/months you would like.

IBM Software
Figure 14 – Selecting the Online Maintenance Window Options

For the purpose of this document we selected:
• Start time: 4:00:00 AM
• Duration (number of hours): 1
• Days of the week: Sunday
• Days of the month: All
Review the maintenance windows you have selected.
6.5 Perform Maintenance Selection against LABDB

IBM Software
All of the selections defined in the previous sections have not yet been committed. Make sure that you are satisfied with all of
your selections and perform the following steps:
1. Click on the link located underneath the Settings header. This will allow you to see the code
that will be executed against the database.
Figure 15 – Preview Command
2. Click to perform these actions against the database.

All actions should complete successfully.

IBM Software
Figure 16 – Run Command

We have now succeeded in setting up regular maintenance activities such as backups, table reorganizations, and
statistics collection for the database. These maintenance activities will run only if needed. As an example, a backup of a
database will not initialize unless there has been changes in data or configuration on the database.
6.6 Enabling Utility Throttling
Utility throttling regulates the performance impact of maintenance utilities so that they can run concurrently during production
periods. The throttling system ensures that the throttled utilities are run as frequently as possible without violating the impact
policy. You can throttle statistics collection, backup operations, rebalancing operations, and asynchronous index cleanups. Let’s
execute a command to limit the impact of these utilities, and view the current configuration for the LABDB database.
1. Execute the following two commands in a terminal window:
db2 update dbm cfg using util_impact_lim 10

db2 get dbm cfg
Specifying a util_impact_lim (impact policy) value of 10 signifies that a throttled backup invocation will not impact the
workload by more than 10 percent. The following output should display (note that this is not the entire output) the new
value:

IBM Software
Figure 17 - UTIL_IMPACT_LIM set to 10
7 Design Advisor
The task of selecting which indexes, MQTs, clustering dimensions, or database partitions to create for a complex workload can
be quite daunting. The Design Advisor identifies all of the objects needed to improve the performance of the workload.
7.1 Create the Explain Tables
Create Explain tables to capture access plans when the Explain facility is activated. The Explain tables must be created before
Explain can be invoked.
1. Issue the following two commands:
cd /home/db2inst1/sqllib/misc
db2 -tvf EXPLAIN.DDL
All commands should execute successfully.
Note: DB2 must be started and a connection to the LABDB database must exist for this procedure to
execute successfully.
7.2 Design Advisor Recommendations
The Design advisor can be used to get recommendations to tune individual SQL statements or a workload of statements. The
Design Advisor analyzes a specified workload and considers factors such as the type of workload statements, the frequency
with which a particular statement occurs, and characteristics of your database to generate recommendations that minimize the
total cost to run the workload.
1. Change back to the directory containing all of the lab scripts:

cd /home/db2inst1/Documents/LabScripts/Autonomics
2. View and execute the initDB2advis.sql script to create duplicate tables of existing ones that will be used for this section.
db2 –tvf initDB2advis.sql
Creation of all tables and indexes should execute successfully. We will now use Visual Explain to see the Query plan
and table scans required for a particular query. We will then use Design Advisor to see if we can improve the amount of
time it takes to execute this query by creating indexes.

IBM Software
3. In Data Studio, click on database LABDB, from within the Administration Explorer. Then, click New on the menu bar
and select New SQL Script from within this menu.
Figure 18 – Opening New SQL Script

4. Copy the following query into the text box:
SELECT c_first, d_name FROM dupvps.dupdealcust, dupvps.dupcustomer,
dupvps.dupdealer WHERE f_c_id=c_id AND f_d_id=d_id AND d_id=548

IBM Software
Figure 19 – SQL Query Textbox
5. After inputting the above statement, click on the Visual Explain icon from within this menu.
Figure 20 – Selecting Visual Explain
The Visual Explain screen lets you view the access plan for explained SQL or XQuery statements as a graph. You can
use the information available from the graph to tune your queries or create objects within your database for better
performance.

IBM Software
Accept the defaults in the pop-up by clicking Finish. A diagram like the following should appear in the Access Plan
Diagram view at the lower half of your Data Studio workspace. Click node RETURN in the graph to reveal the
cumulative total cost of the access plan.
Figure 21 – Access Plan

Note: Cost is derived from a combination of CPU cost (in number of instructions) and I⁄O (in numbers of
seeks and page transfers). The unit of cost is timeron. A timeron does not directly equate to any actual elapsed
time, but gives a rough relative estimate of the resources (cost) required by the database manager to execute
two plans for the same query.
We can see from the graph that a table scan on DUPDEALCUST is done. We can now invoke the Design Advisor to
see if there are any suggestions that can help us improve this query plan.
6. Invoke the Design advisor by executing the following command in the terminal window:
db2advis -d labdb -s "SELECT c_first, d_name FROM dupvps.dupdealcust,
dupvps.dupcustomer, dupvps.dupdealer WHERE f_c_id=c_id AND f_d_id=d_id AND
d_id=548"
Design Advisor is used to suggest the necessary things to help us improve performance. An output similar to the
following should display:

IBM Software
…
Optimization finished.
3 indexes in current solution
[641.0000] timerons (without recommendations)
[428.0000] timerons (with current solution)
[33.23%] improvement
--
--
-- LIST OF RECOMMENDED INDEXES
-- ===========================
-- index[1], 0.884MB
CREATE INDEX "DB2INST1"."IDX1112072206560" ON "DUPVPS "."DUPDEALCUST"
("F_D_ID" ASC, "F_C_ID" ASC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
-- index[2], 0.013MB
CREATE INDEX "DB2INST1"."IDX1112072206490" ON "DUPVPS "."DUPDEALER"
("D_ID" ASC, "D_NAME" DESC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
…
Note: Sizes of the recommended indexes are provided for convenience.
We will now create the recommended indexes and confirm the improvement in the query plan by executing the
crt_index_recmd.sql script.
7. Execute the crt_index_recmd.sql script in DB2 by issuing the following command:
db2 –tvf crt_index_recmd.sql
8. View the new execution plan for the query by going through steps 3-5.
Figure 22 - Access Plan comparison: before and after
You can the see the query plan is better since DB2 has avoided a table scan and the total cost, timerons, has
significantly decreased.

IBM Software
7.3 Executing the Query and Seeing Buffer Pool Memory Changes
Now that we have optimized the database for that particular query, let’s execute this query and use memory tracker to see what
happens with the buffer pools and all other memory components as this query is executed.
Let’s start by decreasing the current size of the buffer pool to something very small (1.3 MB).
1. Execute the command below to change the buffer pool size and immediately take snapshot of the memory.
db2 alter bufferpool vpsbuff immediate size 50 automatic; db2mtrk –d >
bfr_query.snap;
Note: db2mtrk is a memory tracker command used to provide complete report of memory status, for
instances, databases, agents, and applications.
2. Use gedit to view the bfr_query.snap file:
Memory for database: LABDB
utilh pckcacheh other catcacheh bph (2) bph (1)

64.0K 512.0K 128.0K 832.0K 1.3M 4.6M
bph (S32K) bph (S16K) bph (S8K) bph (S4K) shsorth lockh
832.0K 576.0K 448.0K 384.0K 192.0K 56.9M
dbh apph (711) apph (465) apph (462) apph (461) apph (460)
58.7M 128.0K 192.0K 64.0K 64.0K 64.0K
apph (459) apph (458) apph (457) apph (456) appshrh

128.0K 64.0K 64.0K 64.0K 832.0K
Note: This is system dependent and therefore your values may be slightly different.
BPH (2) should be the VPSBUFF buffer pool associated with the LABDB database. We can verify this by executing
SELECT * FROM SYSCAT.BUFFERPOOLS which provides the ID of each buffer pool.
During creation we used the SIZE AUTOMATIC clause for the buffer pool meaning that it is allowed to expand if needed.
Let’s see how this buffer pool will expand when we run the select query from the pervious section.
3. Execute the query by issuing the following command from the terminal:
db2 "SELECT c_first, d_name FROM dupvps.dupdealcust, dupvps.dupcustomer,
dupvps.dupdealer WHERE f_c_id=c_id AND f_d_id=d_id AND d_id=548"
This query should return all of the records with these specifications.
4. We can now check how the BP memory allocation has changed during this query:
db2mtrk -d > after_query.snap

IBM Software
5. Use gedit to view the after_query.snap file. Something similar to the following output should display:
Memory for database: LABDB
utilh pckcacheh other catcacheh bph (2) bph (1)

64.0K 768.0K 128.0K 832.0K 16.2M 4.6M
bph (S32K) bph (S16K) bph (S8K) bph (S4K) shsorth lockh
832.0K 576.0K 448.0K 384.0K 192.0K 56.9M
dbh apph (758) apph (465) apph (462) apph (461) apph (460)
58.7M 128.0K 192.0K 64.0K 64.0K 64.0K
apph (459) apph (458) apph (457) apph (456) appshrh

128.0K 64.0K 64.0K 128.0K 896.0K
Therefore, it is evident that this buffer pool has increased in size to accommodate the query that was being performed.
8 Self-Tuning Memory Manager (STMM)

Self tuning memory 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 between several memory
consumers including sort, package cache and lock list areas and buffer pools.
STMM can be enabled for all of the major memory consumers within DB2 or it can be individually enabled for each of the
following memory consumers:
• Buffer pools (controlled by the ALTER BUFFERPOOL and CREATE BUFFERPOOL statements)
• Package cache (controlled by the pckcachesz configuration parameter)
• Locking memory (controlled by the locklist and maxlocks configuration parameters)
• Sort memory (controlled by the sheapthres_shr and the sortheap configuration parameters)
• Database shared memory (controlled by the database_memory configuration parameter)
In this section of the lab, we will enable STMM for the LABDB database and explore a few of the related database configuration
parameters.
8.1 Connect to the LABDB Database and Examine the Database Configuration Parameters
1. Launch a terminal window or use one that is already open.

2. Connect to the LABDB database by issuing the following commands:
db2 FORCE APPLICATION ALL
The connection to the database should now be established.
3. Look at the database configuration parameters for the LABDB database. Execute the following command:

IBM Software
db2 get db cfg for labdb show detail | more

Database Configuration for Database labdb
Description Parameter Current Value Delayed Value

-----------------------------------------------------------------------------------------------------
----------
Database configuration release level = 0x0f00
Database release level = 0x0f00
Database territory = US
Database code page = 1208
Database code set = UTF-8
Database country/region code = 1
Database collating sequence = IDENTITY IDENTITY
Alternate collating sequence (ALT_COLLATE) =
Number compatibility = OFF
Varchar2 compatibility = OFF
Date compatibility = OFF
Database page size = 4096 4096
Statement concentrator (STMT_CONC) = OFF OFF
Discovery support for this database (DISCOVER_DB) = ENABLE ENABLE
… … … … …
--More--
Note:
• Description: Description of the database configuration parameter.
• Parameter: Name of database parameter.
• Current Value: Current value of the database parameter that is active.
• Delayed Value: Delayed value of the database parameter which will be applied the next time the instance is
started.
4. Press the space bar to scroll down until you see the section regarding STMM similar to the below screen.

IBM Software
Self tuning memory (SELF_TUNING_MEM) = ON (Active) ON

Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(77792) AUTOMATIC(78440)
Database memory threshold (DB_MEM_THRESH) = 10 10
Max storage for lock list (4KB) (LOCKLIST) = AUTOMATIC(12064) AUTOMATIC(12064)
Percent. of lock lists per application (MAXLOCKS) = AUTOMATIC(98) AUTOMATIC(98)
Package cache size (4KB) (PCKCACHESZ) = AUTOMATIC(398) AUTOMATIC(398)
Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = AUTOMATIC(260) AUTOMATIC(260)
Sort list heap (4KB) (SORTHEAP) = AUTOMATIC(52) AUTOMATIC(52)
Database heap (4KB) (DBHEAP) = AUTOMATIC(4465) AUTOMATIC(4465)

Catalog cache size (4KB) (CATALOGCACHE_SZ) = 300 300
Log buffer size (4KB) (LOGBUFSZ) = 2149 2149
Utilities heap size (4KB) (UTIL_HEAP_SZ) = 13137 13137
Buffer pool size (pages) (BUFFPAGE) = 1000 1000
SQL statement heap (4KB) (STMTHEAP) = AUTOMATIC(2048) AUTOMATIC(2048)
Default application heap (4KB) (APPLHEAPSZ) = AUTOMATIC(256) AUTOMATIC(256)
Application Memory Size (4KB) (APPL_MEMORY) = AUTOMATIC(10016) AUTOMATIC(10000)
Statistics heap size (4KB) (STAT_HEAP_SZ) = AUTOMATIC(4384) AUTOMATIC(4384)
Note: STMM is already enabled for the LABDB database. This is because the following are enabled by default
during database creation:
• The value of the SELF_TUNING_MEM database parameter is ON (Active) which means STMM is enabled.
• Notice that the value of the DATABASE_MEMORY database parameter is AUTOMATIC. STMM can dynamically
ask for and give back memory to the operating system.
• Notice that the memory consumers that we have enabled for STMM all shows database parameter of value
AUTOMATIC.
5. Enter “q” to exit this view or hit the space bar until you have scrolled through the output on screen.
To enable self tuning memory for buffer pools, you have to set the buffer pool size to AUTOMATIC. You can do this
using the ALTER BUFFER POOL statement for existing buffer pools or the CREATE BUFFER POOL statement for new
buffer pools. In this lab, we’ve already seen the automatic buffer pool increase in size when we used the db2mtrk
command to check the memory status. This was seen in the previous section.
Note:
Changes resulting from self-tuning operations are recorded in memory tuning log files that are located in the
stmmlog subdirectory. These log files contain summaries of the resource demands from each memory consumer
during specific tuning intervals, which are determined by timestamps in the log entries.
In this exercise, the STMM logs are stored at /home/db2inst1/sqllib/db2dump/stmmlog/
9 Data Movement Tools (optional exercise)
9.1 EXPORT Utility
The export utility extracts data using an SQL select or an XQuery statement, and places that information into a file. You can use
the output file to move data for a future import or load operation or to make the data accessible for analysis.

IBM Software
The following items are mandatory for a basic export operation:

• The path and name of the operating system file in which you want to store the exported data
• The format of the data in the input file. Export supports IXF and DEL data formats for the output files.
• A specification of the data that is to be exported
1. Change directory to the “output” directory in your terminal window.

cd /home/db2inst1/Documents/LabScripts/Autonomics/output
2. Issue the following command to export data from table CAR.
db2 "EXPORT TO car.txt OF DEL MESSAGES msgs.txt SELECT * FROM vps.car"
Note: DEL (Delimited ASCII format) is a format of data in the output file car.txt. Warning and error messages occurred
during an export operation will be stored in msgs.txt.
A message similar to the following should be displayed after successful execution of the command:
~/Documents/LabScripts/Autonomics/output> db2 "EXPORT TO car.txt OF DEL MESSAGES

msgs.txt SELECT * FROM vps.car"
Number of rows exported: 132008
3. You can look into car.txt for all exported records by using gedit or msgs.txt for any warning message. Close the gedit
editor after you have finished viewing the files.
9.2 IMPORT Utility
The IMPORT utility populates a table, typed table, or view with data using an SQL INSERT statement. If the table or view
receiving the imported data already contains data, the input data can either replace or be appended to the existing data. The
IMPORT utility inserts data from an external file with a supported file format into a table, hierarchy, view or nickname. Like export,
import is a relatively simple data movement utility. It can be activated by issuing CLP commands, by calling the ADMIN_CMD
stored procedure, or by calling its API, db2Import, through a user application.
1. Change directory to the “input” directory in your terminal window.

cd /home/db2inst1/Documents/LabScripts/Autonomics/input
2. Issue the following command to import data into table ORDER.

db2 "IMPORT FROM order.txt OF DEL ALLOW WRITE ACCESS COMMITCOUNT 10 INSERT
INTO vps.order"

IBM Software
Note:
ALLOW WRITE ACCESS: runs import in the online mode. An intent exclusive (IX) lock on the target table is acquired
when the first row is inserted. This allows concurrent readers and writers to access table dat.
COMMITCOUNT: performs a COMMIT after every n records are imported. When a number n is specified, import performs
a COMMIT after every n records are imported.
A message similar to the following should be displayed after successful execution of the command:
… …
SQL3149N "51" rows were processed from the input file. "51" rows were successfully
inserted into the table. "0" rows were rejected.
Number of rows read = 51

Number of rows skipped = 0
Number of rows inserted = 51
Number of rows updated = 0
Number of rows rejected = 0
Number of rows committed = 51
9.3 LOAD Utility
The LOAD utility is best suited to situations where performance is your primary concern. It is faster then the IMPORT utility
because it writes formatted pages directly into the database rather than using SQL INSERTS. The load utility also allows you the
option to not log the transactions. Load operations can fully exploit resources such as memory and multiple processors.
The LOAD, like the EXPORT and IMPORT utilities, is cross platform compatible. This utility can be used as an alternative to the
import utility. Use the LOAD utility if you want to move large quantities of data into empty tables or tables that already contain
data.
To demonstrate how the LOAD utility is used, you’ll use the utility to import data into the database.
1. In terminal, start the LOAD utility by executing the command below. Note that the LOAD command should be entered
on a single line.
cd /home/db2inst1/Documents/LabScripts/Autonomics/input
db2 load from order2.txt of del savecount 500 messages ../output/load.msg
insert into vps.order cpu_parallelism 2;

IBM Software

Number of rows loaded = 14996
Number of rows deleted = 0
The table was placed in the Set Integrity Pending state at the beginning of a load operation. After the load operation is
complete, the SET INTEGRITY statement must be used to take the table out of Set Integrity Pending state.
2. In terminal, execute the command below to bring the table out of set integrity pending state.
db2 SET INTEGRITY FOR VPS.ORDER IMMEDIATE CHECKED;
9.4 INGEST Utility
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.
10 Summary
You can see by now that DB2’s autonomic features help to make database administration as easy and low-cost as possible. By
automating tasks such as memory allocation (Self Tuning Memory), storage management (Automatic Maintenance and
Automatic storage features) and business policy maintenance, DB2 is able to perform many management tasks itself, freeing up
DBAs to focus on new projects.
11 Cleanup
1. To clean your environment after completing the exercise, right-click on LABDB database in the Administration
db2 force application all

IBM Software
su -
cd /home/db2inst1/Documents/LabScripts/Autonomics/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/Autonomics/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
DB2® Backup & Recovery

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 Basic Set up and Start of Lab.............................................................................................................................................................3
2.2 Preparation Step ................................................................................................................................................................................................. 3
2.3 Launching Data Studio........................................................................................................................................................................................ 4
2.4 Preparing the Database ...................................................................................................................................................................................... 6
3 DB2 Recovery Parameters..................................................................................................................................................................6

3.1 Listing Database Configuration Parameters ....................................................................................................................................................... 7
3.2 Configure Database for Recovery....................................................................................................................................................................... 7
3.3 Restart the Database .......................................................................................................................................................................................... 8
4 Backup and Restore Modes and Types...........................................................................................................................................11

4.1 Full Online Backup............................................................................................................................................................................................ 11
4.2 Restore from Online Backup............................................................................................................................................................................. 13
4.3 Restore from Offline backup ............................................................................................................................................................................. 16
4.4 Database Roll-forward to a Point in Time ......................................................................................................................................................... 18
4.5 Table Space Roll-forward to a Point in Time .................................................................................................................................................... 21
5 Incremental Backup and Restore.....................................................................................................................................................21

5.1 Incremental Restore.......................................................................................................................................................................................... 21
6 Check Backup Command .................................................................................................................................................................21

7 Summary ............................................................................................................................................................................................21
8 Cleanup...............................................................................................................................................................................................21
DB2 Backup & Recovery

IBM Software
1 Introduction
An effective backup and recovery solution is critical for organizations to be protected against hardware/ software failures. Power
interruptions, storage problems, or application failures can render a database useless, requiring a different recovery action for
each of these failure scenarios. DB2 for LUW has a rich set of flexible backup and recovery features that make it easy for the
user to backup and recover their data.
2 About the lab

This lab demonstrates some of the main backup and recovery features in DB2. It walks you through the recovery parameters
used during a recovery operation along with demonstrating the different ways of backing up the database. At the end of this lab,
you should have a good appreciation of DB2 recovery architecture and how to leverage it. Moreover, it also provides guidance
on how to automate most of the tasks to make a database administrator’s job simple.

3.1 Preparation Step
Note: You many skip this section if you have already started your VM and DB2 instance in a previous lab
session.
3. Open a terminal window as follows by right-clicking on the Desktop and choosing the Open in Terminal item.

IBM Software
Figure 1 - Opening a Terminal
3.2 Launching Data Studio
1. Double-click on the IBM Data Studio icon on the Desktop.
Figure 2 – IBM Data Studio Desktop Icon

2. In the Select a workspace dialog, accept the default and click OK.

IBM Software
Figure 3 – Workspace Launcher

3. Data Studio will now start in the Database Administrator perspective as shown below.
Figure 4 –Database Administration perspective

IBM Software
4. From Data Studio, under the Database Administration perspective and within the Administration Explorer, expand
the nodes All Databases > localhost > db2inst1. Right click on the DS2 database and Connect.
Figure 5 – Connect to Database
In the Properties for DS2 window, specify the following credentials:

You can also optionally tick the Save password check box so you don’t need to re-enter this information every time you
connect to the database. Click OK.
3.3 Preparing the Database
In this lab, you will be working with the DS2 database. It has three user defined table spaces. The following table provides the
relationship between the table space and tables they contain. All tables are created under the DS2 schema.
TABLESPACE TABLES or objects

CUSTTBS CUSTOMERS, CUST_HIST
ORDERTBS ORDERS, ORDERLINES
MISCTBS PRODUCTS, INVENTORY, CATEGORIES, REORDER
4 DB2 Recovery Parameters

In DB2, there are several parameters and commands available to the user to control recovery behaviour. The default
configurations may not meet your requirements. It is recommended that default recovery configuration parameters be updated to
better suit your recovery needs. Backup images and archived transactional log files are used to perform recovery.
You have the flexibility to decide where to store these objects, for how long, etc. Therefore, one of the first things you should do
before taking any backups is to update database configuration to match your needs. In this section we will look at important
database recovery parameters and configure them appropriately.

IBM Software
4.1 Listing Database Configuration Parameters
1. From the terminal, issue the following command:
db2 connect to DS2

db2 get db cfg for DS2 | grep LOG
Record the values for database parameter in the following table:
Database Parameter Value

LOGFILSIZ
LOGPRIMARY
LOGSECOND
LOGBUFSZ
NEWLOGPATH
LOGARCHMETH1
4.2 Configure Database for Recovery
4.2.1 LOGFILSIZ
It is the size of each transactional log file and it is given in 4KB pages. The default size is 1000 pages or 3.9 MB, which implies it
can hold up to 3.9 MB of transactional data.
For the purposes of this exercise, make it smaller because transaction rate is low.
1. Issue the following command:
db2 update db cfg using logfilsiz 500
Note: SQL 1363W is returned on issuing the command; it indicates that the database needs to be reactivated
for the parameter change to take effect.
This message will be returned for most of the commands in this section. The last step in this section is to restart the
database for all the configuration changes to take effect.
4.2.2 LOGPRIMARY AND LOGSECOND
LOGPRIMARY is the number of primary log files. By default LOGPRIMARY is 3, therefore if you have 3 log files worth of
uncommitted transactions, any new transactions would start utilizing the secondary log files.
LOGSECOND is the number of secondary log files. You can have this configured to accommodate spikes in transactional
activity. By default LOGSECOND is 2 and it has a special setting of -1 which indicates infinite logging space, more on that later.
Set LOGPRIMARY to 6 and LOGSECOND to 2.
1. Issue the following commands from terminal:

IBM Software
db2 update db cfg using LOGPRIMARY 6

db2 update db cfg using LOGSECOND 2
4.2.3 LOGBUFSZ
It is the memory buffer for log records. This is where all log records get written in memory before getting flushed to disk. Default
of 256 (4KB) pages is small for most scenarios. Set the LOGBUFSZ to 512.
1. Issue the following command from the terminal:
db2 update db cfg using LOGBUFSZ 512
4.2.4 NEWLOGPATH
Log path is a directory location on the server where the log files get created. By default it is in the same location as the database
control files.
1. Change the log path by issuing the following command:
db2 update db cfg using NEWLOGPATH /home/db2inst1/dblogs
4.2.5 LOGARCHMETH1, LOGARCHMETH2 AND FAILARCHPATH
By default, when a new database is created; it is configured for circular logging. Circular logging causes log files to be reused in
a circular fashion with no history of log files preserved. For example, if you have LOGPRIMARY set to 5, after the 5th file is used
up, DB2 will start reusing the first log file, considering it is available. With circular logging only crash recovery and offline
backups are possible. In order to take online backups and perform roll-forward recovery, the database needs to be enabled for
archival logging.
1. Enable database for archival logging and provide an archival location by issuing the following commands from the
terminal window:
db2 update db cfg using logarchmeth1 'disk:/home/db2inst1/logarch'
This enables the database for archival logging and at the same time sets the archival location. We specified a disk
location but it could be TSM server or another vendor API library.
LOGARCHMETH2 is a secondary log archival method. If this path is specified, log files will be archived to both this destination
and the destination specified by LOGARCHMETH1. FAILARCHPATH is yet another layer of protection. If both archival methods
fail, database will try to archive to this location. Leave these two parameters blank for this exercise.
4.3 Restart the Database
1. Issue the following commands from Linux terminal to shutdown and restart the database:
db2 force applications all

db2 terminate
db2 deactivate db DS2

IBM Software
2. From Data Studio, under the Database Administration perspective and within the Administration Explorer, expand
the nodes All Databases > localhost > db2inst1. Right click on the DS2 database and Connect.
In the Properties for DS2 window, specify the following credentials:

You can also optionally tick the Save password check box so you don’t need to re-enter this information every time you
connect to the database. Click OK.
Figure 7 – Unsuccessful connection
This message is received because archival logging has just been enabled, which by design puts the database in
BACKUP PENDING mode. This mode indicates that you need to do a full backup of the database before accessing it.
Recall that once archival logging is enabled for the database, roll forward recoveries can be performed. However, roll

IBM Software
forward recovery can only be performed once a backup image has been restored and database is placed in Roll
Forward Pending status. For this reason, a backup operation is imposed after setting archival logging.
3. Right click on the DS2 database, Back Up and Restore > Back Up….
Figure 8 – Opening the Back Up task assistant
4. Within the Back up DS2 tab, select the Backup Image settings, and click Add… to specify a backup location.
Figure 9 – Specifying where to store the backup image
5. Select the newly added backup location as shown above and click the Browse… button. Navigate to
/home/db2inst1/backups and press Ok to select this location.

IBM Software
6. Click on . This will allow you to see the command to be executed. You might have to expand the
task assistant window to view the command displayed at the bottom.
BACKUP DATABASE DS2 TO "/home/db2inst1/backups" EXCLUDE LOGS WITHOUT

PROMPTING ;
7. Click Run button to execute the command. You will be requested to provide connection details for DS2.
8. The results of the backup command are provided in the SQL results pane at the bottom right of the screen.
Backup successful. The timestamp for this backup image is : <T1>
Every time there is a successful backup in DB2, a backup image timestamp is also returned. The Restore utility uses this
timestamp to differentiate between multiple available backup images.
Note: Timestamp is dumped in the following format: yyyymmddhhmmss. Note the timestamp for the backup as T1
Time Label Timestamp

T1
Now the database should be connectable.
5 Backup and Restore Modes and Types

Backup and restore utilities are very flexible, allowing you to run backups at different object levels and in different modes. One of
the simplest backups is the full offline database backup that was taken at the end of the previous exercise. The term “offline”
here signifies that the database is offline with no applications connected and no activity in the database. The term “full” refers to
the fact that entire database was backed up. We will see in next sections that it is possible to backup just a subset of the
database. For example, one could backup only a single table space or a group of table spaces.
5.1 Full Online Backup
We have already taken a full offline backup in previous section. Now we’ll take a full online backup of database DS2.
1. Go back to the terminal and connect to the DS2 database and verify there is a connection to the database by issuing
the following commands:
db2 connect to DS2

db2 list applications
Output from command above should look something like:
Auth Id Application Appl. Application Id DB # of

Name Handle Name Agents
-------- -------------- ---------- ------------------------------------------------------- -------- -----
DB2INST1 db2bp 81 *LOCAL.db2inst1.111222224624 DS2 1

IBM Software
2. Now try to perform a back up using Data Studio in the same way as we did in the previous section. Then select a
location for the backup (as shown below) and click Run.
Figure 10 – Specifying where to store the backup image
The following error should be returned. The command failed as an offline backup is being performed while the database
is online due to the connection in the terminal.
SQL1035N The database is currently in use. SQLSTATE=57019
3. To take an online backup, first connect to the DS2 database from Data Studio (Right click DS2 > Connect)
4. Open the Back Up task assistant by following the directions outlined in step 2.
5. Repeat the same procedure as before to add the backup location: within the Back up DS2 tab.
6. Also, under the Backup Options settings, verify that Online is selected within the Availability section.

IBM Software
Figure 11 – Selecting online backup mode
7. Click on the . This will allow you to see the command to be executed.
BACKUP DATABASE DS2 ONLINE TO "/home/db2inst1/backups" EXCLUDE LOGS WITHOUT

PROMPTING ;
8. Click the Run button to execute the command.
Backup attempt should now be successful. Note the timestamp, it will be referred to as T2 in the next section.

T2
5.2 Restore from Online Backup
In this section, we will demonstrate the ease of restoring your database from a backup.
1. Go back to the terminal, issue the following command to close all database connections:
Make sure you are still connected to the DS2 database through Data Studio. Open the Restore task assistant by right
clicking on the DS2 database, Back Up and Restore > Restore….

IBM Software
Figure 12 – Opening the Restore task assistant
2. Under the Restore Objects settings, navigate to the Backup image section, and select the backup image to restore
which corresponds to timestamp T2. T2 is the timestamp for the online backup taken in previous section.
Figure 13 – Selecting Backup Image to Restore
RESTORE DATABASE DS2 FROM "/home/db2inst1/backups" TAKEN AT <T2> WITHOUT

PROMPTING;
4. Click Run to execute the command.
5. The deployment status of the command is displayed in the Restore Database DS2 tab.
a. The command has been executed successfully but with a warning. This warning is ok; essentially it is stating
that you are overwriting an existing database.
b. The attempt to connect to the database fails. If we try connecting again (through Data Studio), we receive the
following message:

IBM Software
Figure 14 – Unsuccessful connection message
When an online backup is taken, any activity that may be going on during the online backup is recorded into the
database transaction logs. Therefore, once you restore from an online backup there is a mandatory step needed to do a
Roll Forward operation to a minimum Point in Time before the database can be made available.
6. In Data Studio, open the Roll Forward task assistant by right clicking on the DS2 database, Back Up and Restore >
Roll Forward….
Figure 15 – Opening the Roll Forward task assistant
7. Under the Roll-forward Final State settings, within the Final state options section, select Complete the roll-forward
operation and return to the active state.

IBM Software
Figure 16 – Choosing the Final State for the Database
8. Click on . The COMPLETE keyword at the end of ROLLFORWARD command indicates that
once all available logs have been applied the database should be made available for user connections.
ROLLFORWARD DATABASE DS2 TO END OF LOGS AND COMPLETE;
9. Click the Run button to execute the command. You will be prompted to connect to the database, enter database
password.
Output should look similar to the following:
Rollforward Status
Input database alias = DS2
Number of members have returned status = 1
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000000.LOG - S0000000.LOG
Last committed transaction = 2011-12-22-22.51.06.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.
Note: Rollforward status is set to NOT PENDING, meaning that database has been taken out of roll forward pending
state and it is now connectable.
5.3 Restore from Offline backup
Restoring from an offline backup is simpler, as there is no hard requirement to perform a roll forward but you can do one if
needed. Let us restore the database from an offline backup image taken at T1. If you do not recall, you can always check the
Recovery history file to find the backup timestamp.
1. Go back to the terminal and issue the following command:
db2 list history backup all for database DS2

IBM Software
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

-- --- ------------------ ---- --- ------------ ------------ --------------
B D 20111222174229001 F D S0000000.LOG S0000000.LOG
----------------------------------------------------------------------------
Contains 6 tablespace(s):
00001 SYSCATSPACE
00002 USERSPACE1
00003 CUSTTBS
00004 MISCTBS
00005 ORDERTBS
00006 SYSTOOLSPACE
----------------------------------------------------------------------------
Comment: DB2 BACKUP DS2 OFFLINE
Start Time: 20111222174229
End Time: 20111222174231
Status: A
----------------------------------------------------------------------------
EID: 10 Location: /home/db2inst1/backups
Note “Timestamp” for the backup image and use it in restore operation as follows:
2. Connect to the DS2 database from Data Studio and open the Restore Database task assistant
3. Within the Restore Database tab, navigate to the Restore Objects settings. From the Backup image section, select
the offline backup image which corresponds to timestamp T1.
Figure 17 - Selecting Backup Image to Restore
4. Under the Restore Options settings, within the Roll-forward options, select the check box “Do not put the database
in roll forward pending state after restore”.

IBM Software
Figure 18 – Selecting Roll-forward options

ROLLING FORWARD WITHOUT PROMPTING;
Note: When restoring an offline backup image, a roll forward is not mandatory. Therefore, the clause WITHOUT ROLLING
FORWARD is allowed in the restore command. This is useful when a roll forward is not needed and restore can finish in just
one step. After restore finishes, you are able to connect without having to do a roll forward explicitly.
5.4 Database Roll-forward to a Point in Time
We briefly touched upon the Roll-forward task assistant in the last section. Roll-forward is the process of applying transaction log
files after a restore has been performed. For example, last backup was taken Sunday and the database was lost on the following
Tuesday. Once the backup from Sunday is restored, transactions in log files need to be applied in order to recover transactions
that were done after the backup. This is achieved by rolling forward to “END OF LOGS”.
There might be a situation where it is not desired to apply all the transactions. For example, a large set of records are deleted
from the database mistakenly by the user. In such a case, in order to recover all the deleted records, rolling forward to a POINT
IN TIME before the deletions took place would be more appropriate.
1. Create an online database backup exactly as we did in the previously using the same backup location. Refer to section
5.1 if needed.
2. Note the time stamp returned by the backup command. It will be needed for the restore operation later on. We’ll refer to
this timestamp as T3.

T3
3. Go back to the terminal window and check the number of rows in the ORDERS table:
db2 connect to DS2

db2 "select count(*) from DS2.ORDERS"

IBM Software
The expected number of rows in the ORDERS table is 12000.
4. Run “date” command and note the time stamp before issuing a delete statement, it will be needed for point in time
recovery. This timestamp will be referred to as T4 within this section. Issue the following command:
date

T4
5. Now run the following commands to delete some of the data in the ORDERS table:
db2 "delete from DS2.ORDERS where orderdate > date('11/30/2004')"
6. Check the count again:
Imagine these rows were deleted mistakenly and they need to be recovered. This can be done by restoring from the
backup image taken at T3.
7. First close the connections from the terminal:

db2 terminate
8. Make sure you are still connected to the DS2 database through Data Studio and than open the Restore task assistant
by right clicking on the DS2 database, Back Up and Restore > Restore….
9. Under the Restore Objects settings, within the Backup image section, select the backup image to restore which
corresponds to timestamp T3. T3 is the timestamp of the online backup taken previously in this section:

IBM Software

PROMPTING;
Now that the database is restored, roll forward to a point in time before the delete statement was issued, which in this case
is T4.
12. Open the Roll Forward task assistant by right clicking on the DS2 database, Back Up and Restore > Roll Forward….
13. Under the Roll-forward Type settings, within the Type of roll-forward operation section, select A point in time
specified in local time.
Figure 20 – Selecting Type of Roll-Forward Operation
14. Also, under the Restore Objects settings, within the Backup image section, specify the transaction time which
corresponds to timestamp T4.
Figure 21 – Rolling Forward to a Point in Time Specified in Local Time
15. Click on . This will allow you to see the command to be executed.
ROLLFORWARD DATABASE DS2 TO <T4> USING LOCAL TIME;
Note: timestamp for roll forward has to be provided in this format: yyyy-mm-dd-hh.mm.ss.
Output from roll forward:

IBM Software
Rollforward Status
Member ID = 0
Rollforward status = DB working
Next log file to be read = S0000005.LOG
Log files processed = S0000000.LOG - S0000004.LOG
Last committed transaction = 2011-12-23-10.50.43.000000 Local
Lastly, take database out of the roll-forward pending status.
17. Open the Roll-forward task assistant by right clicking on the DS2 database, Back Up and Restore > Complete Roll
Forward….
Figure 22 – Opening the Complete Roll Forward Task assistant
18. Leave the defaults and click . This will allow you to see the command to be executed.
CONNECT RESET;
ROLLFORWARD DATABASE DS2 COMPLETE ;
20. Go back to the terminal and check the number of rows in the ORDERS table again:
db2 connect to DS2

The expected number of rows in the ORDERS table is 12000, which means the deleted rows have been recovered.
This was possible because the roll-forward was done up to a time before the delete statement was issued, thus all
transactions since the backup was taken were applied except the delete statements in question

IBM Software
If an “end of logs” roll forward was done in this case, it would have also replayed the delete statement, thereby deleting
the rows again.
21. Issue following command in any open terminals:
db2 terminate
5.5 Table Space Roll-forward to a Point in Time
Backups can be performed at either the database level or at the table space level. In large environments, it may not be desirable
to perform a full database backup. You may have some table spaces where data is static and other table spaces where data
changes regularly. With the table space backups you can backup only subsets of a database. If there is a requirement to only
backup tables individually, it can be achieved by placing only 1 table per table space and then backing up the table spaces.
5.5.1 Take an Online Table Space Backup
We take the same scenario in the last section of recovering deletes, however in this case table space backups will be used to
perform recovery. Take a table space backup of ORDERTBS table space. This table space contains the ORDERS table. Do the
following to verify:
1. Connect to the DS2 database from Data Studio. Under the DS2 database node within Administration Explorer, click on
Tables as shown:

IBM Software
Figure 23 – Listing DS2 Tables
2. Than within the DS2 tab check the Regular Tablespace column corresponds to table ORDERS to verify the associated
table space:
Figure 24 – Verifying Associated Table space
3. Connect to the DS2 database from Data Studio and open the Backup task assistant (Right click DS2 > Back Up and
Restore > Back Up…).
4. Under the Backup Type settings, within the Type of backup section, select the Back up selected table spaces radio
button.

IBM Software
Figure 25 – Selecting the Type of Backup
5. Also under the Backup Type settings, within the Table spaces section, select the ORDERTBS table space.
Figure 26 – Selecting Table Spaces to Backup
6. Within the Back up DS2 tab, select the Backup Image settings, and click Add… to specify a backup location.
BACKUP DATABASE DS2 TABLESPACE ( ORDERTBS ) ONLINE TO

"/home/db2inst1/backups" EXCLUDE LOGS WITHOUT PROMPTING ;
9. Note the timestamp of this backup, it will be referred to as T5.

T5
10. Go back to the terminal window and list directory for the backups:
ls –ltrh ~/backups
Output should look similar to the following:
total 550M
-rw------- 1 db2inst1 db2grp1 183M 2011-12-22 17:42 DS2.0.db2inst1.DBPART000.20111222174229.001
-rw------- 1 db2inst1 db2grp1 8.6M 2011-12-26 20:00 DS2.3.db2inst1.DBPART000.20111226200017.001

IBM Software
From the output two things should be noted. First, the latest backup image is smaller compared to the others since it
contains only the data for ORDERTBS table space. Second, the backup type in the file name is 3 instead of 0 like the
others: DS2.3.db2inst1.DBPART000.<timestamp>.001
Note: Backup images have the following naming convention:.
<Database name>.<Backup type>.<instance name>.<database partition number>.<catalog partition

number>.<timestamp>.<sequence
Backup number>
images have the following naming convention:
Backup type:
<Database 0 for full database
name>.<Backup backup; 3 for name>.<database
type>.<instance 4 for backup
table space backup;partition generated by LOAD…COPY
number>.<catalog partition INTO
command
number>.<timestamp>.<sequence number>
11. Check the number of rows in the ORDERS table:
db2 connect to DS2

12. Run date command and note the time stamp before issuing the delete statement, it will be needed for point in time
recovery. It will be referred to as T6.
date

T6
13. Run the following commands to delete some of the data in the ORDERS table:
db2 "delete from DS2.ORDERS where orderdate > date('11/30/2004')"
14. Check the count again:
Instead of restoring and disrupting the entire database, we can restore only the ORDERTBS table space backup taken
at T5.
15. First terminate the connection on the open terminal.
db2 terminate
5.5.2 Restore and Rollforward to Point in Time for Table ORDERTBS
The transactions carried out after the backup require a roll forward to be performed on the table space after the restore
operation is carried out. This sub-section shows how a restore and roll forward are carried out on the table space
ORDERTBS
IBM Software
1. Connect to the DS2 database from Data Studio and open the Restore task assistant.
2. Under the Restore Objects settings, within the Restore objects section, select the Restore the selected table
spaces radio button and than select ORDERTBS from the Table spaces list.
Figure 27 – Selecting Restore Objects
3. Also under the Restore Objects settings, within the Backup image section, select the backup image which
RESTORE DATABASE DS2 TABLESPACE ( ORDERTBS ) FROM "/home/db2inst1/backups"

TAKEN AT <T5> WITHOUT PROMPTING;

IBM Software
6. After table space restore, database is available but ORDERTBS table space is in roll forward pending. To demonstrate
this, issue the following command:
db2 connect to DS2

db2 list tablespaces
Name = ORDERTBS
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0080
Detailed explanation:
Roll forward pending
Roll forward the ORDERTBS table space to timestamp T6 which was prior to the time the delete statement was issued:
8. Under the Roll-forward Type settings, within the Type of roll-forward operation section, select A point in time
specified in local time.
9. Also, under the Restore Objects settings, within the Backup image section, specify the transaction time which
Figure 29 - Rolling Forward to a Point in Time Specified in Local Time
10. Under the Roll-forward Scope settings, select the Roll the selected table spaces forward radio button and select the
ORDERTBS table space.

IBM Software
Figure 30 – Specifying the Scope of the Roll-Forward Operation
11. Under the Roll-forward Final State settings, within the Final state options section, select Complete the roll-forward
operation and return to the active state.
ROLLFORWARD DATABASE DS2 TO <T6> USING LOCAL TIME AND COMPLETE TABLESPACE (
ORDERTBS ) ONLINE;
Since the roll-forward operation was performed until a point in time before the delete operation had taken place, deleted rows
should have been recovered. Check the count:
db2 connect to DS2

db2 terminate
6 Incremental Backup and Restore

IBM Software
So far we have looked at full database and table space backups. As database sizes grow larger it can be quite costly to run full
backups, both in terms of storage for the backup images and time required to execute the backups. This is where incremental
backups come in.
In order to use the incremental backup functionality, database has to be enabled for it. This is done by turning the TRACKMOD
database configuration parameter on. When TRACKMOD is turned on, database keeps track of table spaces that have been
modified. When an incremental backup command is issued, it will skip the table spaces that have not been modified since last
backup.
1. From Data Studio, right click on the (connected) DS2 database, Set Up and Configure > Configure….
Figure 31 – Opening the Configure Task assistant
2. Under the Configure Parameters settings, use the Filter to search for the parameter TRACKMOD. Double click on the
parameter and use the drop down menu to change the Pending Value to ON.

IBM Software
Figure 32 – Modifying Database Configuration Parameters
CONNECT TO DS2;
UPDATE DB CFG USING TRACKMOD ON DEFERRED ;
CONNECT RESET;
5. Disconnect from the database and re-connect to perform a full backup. Incremental backups require a full backup to act
as a reference point for incremental changes.
6. Open the backup Task Assistant:

a. Under the Backup Image settings, select the backup location /home/db2inst1/backups
b. Under the Backup Options settings, verify that Online is selected within the Availability section
7. Click on . This will allow you to see the command to be executed. Click the Run button to
execute the command.
BACKUP DATABASE DS2 ONLINE TO "/home/db2inst1/backups" EXCLUDE LOGS WITHOUT

PROMPTING ;

T7 …

IBM Software
9. Make changes to ORDERS which resides in ORDERTBS and CUSTOMERS table which resides in CUSTTBS. From
terminal window run:
db2 connect to DS2

db2 "update DS2.ORDERS set tax=tax*1.05 where orderdate > date('11/30/2004')
"
db2 "update DS2.CUSTOMERS set income=income*0.9 where income > 90000"
10. With the database enabled for incremental backups, an incremental backup can be now taken to just include the
changes made. Ensure you are connected to the DS2 database from Data Studio
11. Open the Back Up task assistant:

a. Under the Backup Image settings, click Add… to specify a backup location.
b. Under the Backup Options settings, verify that Online is selected within the Availability section.
c. Also under the Backup Options settings, within the Backup type section, select the Incremental radio button
to back up data that has changed since the last full backup:
Figure 33 – Selecting incremental backup type
12. Click on the . This will allow you to see the command to be executed. Click the Run button to
BACKUP DATABASE DS2 ONLINE INCREMENTAL TO "/home/db2inst1/backups" EXCLUDE

LOGS WITHOUT PROMPTING ;

T8
14. Check the backups directory for size of this incremental backup image. Issue this command:
ls –ltrh ~/backups
…
15. Image backup size is much smaller than prior full backups because it contains only the changes since last full backup.
Note that any table space that was not modified since the last full backup, will be skipped in incremental database
backups. In this case it only backed up changes in the two table spaces ORDERTBS and CUSTTBS.
Make further changes to table ORDERS. Issue the following command:

IBM Software
db2 connect to DS2

db2 "update DS2.ORDERS set tax=tax*1.05 where orderdate >
date('10/30/2004')"
Incremental backups can also be taken at table space level. Since the only change in the database was against the
ORDERS table in ORDERTBS, let’s back up the ORDERTBS table space.
Note: Recall that incremental backup backs up all changes since the last full backup. With the incremental delta
option, only changes since the last backup (either incremental or full) will be backed up.
16. Ensure you are connected to the DS2 database from Data Studio and open the Back Up task assistant:
a. Under Backup Type, within the Type of backup section, select Back up selected table spaces radio button.
b. In the table spaces section, select the ORDERTBS table space.
c. Under the Backup Image settings, specify a backup location.
d. Under the Backup Options settings, within the Backup type section, select the Delta radio button to back up
data that has changed since the most recent backup:
Figure 34 – Selecting incremental delta backup type
17. Click on . This will allow you to see the command to be executed. Click the Run button to
BACKUP DATABASE DS2 TABLESPACE ( ORDERTBS ) ONLINE INCREMENTAL DELTA TO

Note the timestamp of this backup, it will be referred to as T9.

… …
T9
… …
18. Run more updates against the CUSTOMERS table, from terminal session issue:
db2 connect to DS2

db2 "update DS2.CUSTOMERS set income=income*0.9 where income > 80000"
19. Take incremental backup of CUSTTBS table space. Ensure you are connected to the DS2 database from Data Studio
and open the Back Up task assistant
a. Under the Backup Type settings, select the Back up selected table spaces radio button. Then within the
Table spaces section, select the CUSTTBS table space.
b. Select a backup location from the Backup Image settings
c. Backup Options: Select Incremental from the Backup type section.

IBM Software
20. Click on the . This will allow you to see the command to be executed, and click RUN.
BACKUP DATABASE DS2 TABLESPACE ( CUSTTBS ) ONLINE INCREMENTAL TO

Note the timestamp of this backup, it will be referred to as T10.

… …
T10
Note: we only took an incremental backup and not an incremental delta backup; this would cover all the changes made
since the full database backup in CUSTTBS table space.
6.1 Incremental Restore
When restoring from incremental backups, the right sequence of full, incremental and incremental delta backups has to be
applied. This can become very complex very quickly in a real environment. For this reason, there is an AUTOMATIC option
available with the restore command such that DB2 figures out the right sequence for applying backups and then applies them.
There is also a MANUAL option available, but AUTOMATIC option is highly recommended.
1. Restore ORDERTBS table space using the incremental backups up to the last image. “db2ckrst” utility is available to
see what backup images will be applied, prior to actually running the automatic restore.
db2ckrst -d DS2 -t <T9> -r tablespace ORDERTBS
T9 is the timestamp for the last delta backup image of ORDERTBS.
Suggested restore order of images using timestamp T9 for

database ds2.
====================================================================
restore db ds2 tablespace ( ORDERTBS ) incremental taken at T9
restore db ds2 incremental taken at T9
====================================================================
This output is showing that last incremental delta image will be read first to get the control and header information only (T9).
Then the table space ORDERTBS will be restored from the full backup image (T7). Following, that first incremental image will be
applied (T8). Lastly, the incremental delta image will be read again, this time applying the data in the delta image (T9)..
Note: The backup image that is being restored to is read twice; once in the beginning to obtain control information and
decide how far the restore has to go and then again at the end to apply the data in last image.
2. Now, let’s restore ORDERTBS to the last delta backup image. Make sure you are still connected to the DS2 database
through Data Studio and than open the Restore task

IBM Software
a. Under the Restore Objects settings, select the Restore the select table spaces radio button than select
ORDERTBS from the Table spaces list.
b. Also under the Restore Objects settings, within the Backup image section, select the backup image to restore
which corresponds to timestamp T9.
c. Under the Restore Options settings, select the Allow other applications to connect to the database radio
button, as shown below.
Figure 35 – Restore option to “Allow other applications to connect to the database”
3. Click on the . This will allow you to see the command to be executed and click RUN.
RESTORE DATABASE DS2 TABLESPACE ( ORDERTBS ) ONLINE INCREMENTAL AUTOMATIC

FROM "/home/db2inst1/backups" TAKEN AT <T9> WITHOUT PROMPTING;
ORDERTBS will now be in roll forward pending because it has been restored. Take it out of RF pending:
5. Under the Roll-forward Scope settings, select the Roll the selected table spaces forward radio button and select the
ORDERTBS table space.
6. Click on the . This will allow you to see the command to be executed and click RUN.
ROLLFORWARD DATABASE DS2 TO END OF LOGS TABLESPACE ( ORDERTBS ) ONLINE;
Output from successful roll forward command:

Rollforward Status
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = -
Last committed transaction = 2011-12-28-11.47.58.000000 Local
7. ORDERTBS should now be available and online. Verify using following commands:
db2 connect to DS2

db2 list tablespaces
IBM Software
Similarly, let’s restore CUSTTBS to latest incremental backup:
1. Make sure you are still connected to the DS2 database through Data Studio and than open the Restore task assistant
a. Within Restore Objects settings, select the Restore the select table spaces radio button than select
CUSTTBS.
b. Within the Backup image section, select the backup image to restore which corresponds to timestamp T10.
c. Under the Restore Options settings, select the Allow other applications to connect to the database radio
button.
2. Click on . This will allow you to see the command to be executed. Click RUN
RESTORE DATABASE DS2 TABLESPACE ( CUSTTBS ) ONLINE INCREMENTAL AUTOMATIC

FROM "/home/db2inst1/backups" TAKEN AT <T10> WITHOUT PROMPTING;
T10 is the timestamp for the last incremental backup image of CUSTTBS.
3. CUSTTBS should now be in Roll forward pending. Open the Roll Forward task assistant:
a. Under the Roll-forward Scope settings, select the Roll the selected table spaces forward radio button and
select the CUSTTBS table space:
4. Click on the . This will allow you to see the command to be executed, and RUN.
ROLLFORWARD DATABASE DS2 TO END OF LOGS AND COMPLETE TABLESPACE ( CUSTTBS )

ONLINE;
CUSTTBS should now be online and available.
5. Close the connection from data studio. Go to the terminal and close all connections to DS2

db2 terminate
7 Check Backup Command

The check backup command (db2ckbkp) can be used to test the integrity of a backup image and to determine whether or not
the image can be restored. It can also be used to display the metadata stored in the backup header.
1. At its default configuration, db2ckbkp only verifies if the image is good. For instance, issue the following command with
any one of the backup images taken (you find the backup image name by listing out the ~/backups directory.):
cd ~/backups
db2ckbkp DS2.3.db2inst1.DBPART000.<TIMESTAMP>.001
The following should output if image verification is successful:

IBM Software
[1] Buffers processed: ##############################################
Image Verification Complete - successful.
2. You can optionally use the “-h” argument to display media header information including the name and path of the image
expected by the restore utility. For example:
db2ckbkp -h DS2.3.db2inst1.DBPART000.<TIMESTAMP>.001
=====================
MEDIA HEADER REACHED:
=====================
Server Database Name -- DS2
Server Database Alias -- DS2
Client Database Alias -- DS2
Timestamp -- 20120116155426
Database Partition Number -- 0
Instance -- db2inst1
Database Configuration Type -- 0
Sequence Number -- 1
Database Member ID -- 0
Release ID -- F00
Database Seed -- 929C6DE2
DB Comment's Codepage (Volume) -- 0
DB Comment (Volume) --
DB Comment's Codepage (System) -- 0
DB Comment (System) --
Authentication Value -- -1
Backup Mode -- 1
Includes Logs -- 0
Compression -- 0
Backup Type -- 3
Backup Gran. -- 48
Merged Backup Image -- 0
Status Flags -- 20
System Cats inc -- 0
Catalog Partition Number -- 0
DB Codeset -- UTF-8
DB Territory -- US
LogID -- 1326744538
LogPath -- /home/db2inst1/dblogs/NODE0000/LOGSTREAM0000/
Backup Buffer Size -- 4460544
Number of Sessions -- 1
Platform -- 12
The above output contains a lot of important information. Just to highlight a few above, we can see if the backup image
is online or offline; an incremental or an incremental delta backup; whether it is a compressed or uncompressed image,
etc.

IBM Software
i.e.,:
Backup Mode -- 0 represents an offline backup
Backup Mode -- 1 represents an online backup
Backup Gran -- 0 represents a full backup
Backup Gran -- 16 represents an incremental backup
Backup Gran – 48 represents an incremental delta backup
Compression – 0 represents an uncompressed backup
Compression -- 1 represents a compressed backup
3. For details about other options, run db2ckbkp with no arguments or check the IBM Information Center.
db2ckbkp
8 Summary
With Database Backup and Recovery in DB2, you can increase application availability and ensure resiliency with reliable
subsystem backups and point-in-time recovery. This lab outlined some of the main backup and recovery features found within
DB2. By now, you should have a basic understanding of DB2 recovery architecture and how to use it with the new Data Studio
tool to make your life as a database administrator simpler.
9 Cleanup
To clean your environment after completing the exercise, if you would like to redo this lab in the future, please execute the
following in a terminal window:
cd ~/Documents/LabScripts/Backup/setup/
./cleanup_script.sh
exit

IBM Software

DISTRIBUTED “AS IS” WITHOUT ANY WARRANTY,
EITHER
EXPRESS OR IMPLIED. IBM EXPRESSLY DISCLAIMS
ANY
© Copyright IBM Corporation 2012 WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
All Rights Reserved. PARTICULAR PURPOSE OR NON-INFRINGEMENT.
IBM Canada IBM products are warranted according to the terms and
8200 Warden Avenue conditions of
Markham, ON the agreements (e.g. IBM Customer Agreement, Statement
L6G 1C7 of Limited
Canada Warranty, International Program License Agreement, etc.)
under which
IBM, the IBM logo, ibm.com and Tivoli are trademarks or they are provided.
registered
trademarks of International Business Machines Corporation
in the
IBM trademarked terms are marked on their first occurrence
in this
information with a trademark symbol (® or ™), these
symbols indicate
U.S. registered or common law trademarks owned by IBM
at the time
this information was published. Such trademarks may also
be registered or common law trademarks in other countries.
A current list of IBM trademarks is available on the Web at
“Copyright and trademark information” at
ibm.com/legal/copytrade.shtml
Other company, product and service names may be

trademarks or service marks of others.
References in this publication to IBM products and services

do not imply that IBM intends to make them available in all
countries in which
IBM operates.
No part of this document may be reproduced or transmitted

in any form
Product data has been reviewed for accuracy as of the date

of initial
publication. Product data is subject to change without notice.
Any
statements regarding IBM’s future direction and intent are
subject to
change or withdrawal without notice, and represent goals
and objectives only.

IBM Software
DB2® Storage Optimization

f
Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
3 About this Lab......................................................................................................................................................................................3
4 DB2 Storage Optimization ..................................................................................................................................................................4
4.2 Preparing for the lab ........................................................................................................................................................................................... 4
4.3 Examine Table Properties................................................................................................................................................................................... 5
4.4 Inline Large Object (LOB) Data........................................................................................................................................................................... 7
4.5 Run Sample Workload ........................................................................................................................................................................................ 9
4.6 Estimate Compression Savings ........................................................................................................................................................................ 13
4.7 Enable Classic Row Compression.................................................................................................................................................................... 14
4.8 Inspecting Compression Results ...................................................................................................................................................................... 16
4.9 Run Sample Workload on Compressed Data ................................................................................................................................................... 17
4.10 Applying Adaptive Compression ....................................................................................................................................................................... 19
5 Summary ............................................................................................................................................................................................22
6 Cleanup...............................................................................................................................................................................................22
DB2 Storage Optimization

IBM Software
1 Introduction
Every business model looks for the best way to minimize production costs in order to maximize profits. One of the most
prominent features introduced in DB2 is the ability to perform row compression. The goal of row compression is to reduce
database storage needs. When using this feature, DB2 is able to shrink row sizes by building and utilizing a compression
dictionary, which is used as an alphabet to compress the rows of data in the database tables. Since more data can reside on a
data page, fewer data pages are allocated per table. The net effect is a reduced rate of storage consumption which may lead to
fewer disks needed when allocating storage requirements. Since disk storage is one of the most expensive components on any
data server, this feature can significantly reduce Total Cost of Ownership (TCO).
As part of the Storage Optimization feature, DB2 allows row compression of regular SQL data types, XML data, index
compression, temporary table compression, and new in DB2 10, adaptive compression further enhances the benefits of classic
row compression.
2 Suggested Reading
Best Practices: Deep Compression
http://www.ibm.com/developerworks/data/bestpractices/deepcompression/
DB2 Deep Compression – Best Practices and Customer Experiences

http://www.channeldb2.com/events/db2-deep-compression-best
3 About this Lab

In this lab, we will be taking a closer look at the various compression techniques available including row compression (available
since DB2 9), XML XDA compression (available since DB2 9.7), index compression (available since DB2 9.7), LOB inlining
(available since DB2 9.7), and the adaptive compression feature new to DB2 10. You will also learn the basics on how to enable
different compression technologies for a table and collect various statistics
• Examine table properties
o Make use of the available table function ADMIN_GET_TAB_INFO to see the physical sizes of the different data
objects (relational data, XML and LOB data, and indexes).
• Inline LOB column
o Get an estimate of the maximum length required to inline a particular LOB column.
• Run sample workload against table
o Use Data Studio to run a workload and view the access plan of the DB2 Optimizer.
• View compression estimates
o Use the available table functions to view an estimate of the possible savings when row compression is enabled
(includes XML and index compression).
• Apply Static and Adaptive compression
o Compress tables
o Examine table properties post-compression
o Run sample workload post-compression

IBM Software
4 DB2 Storage Optimization



2. Right-click on the Desktop area and choose the “Open in Terminal” option:
Figure 1 - Open a new terminal
3. As the user db2inst1, enter the following command in the terminal window to start the database instance. Make sure
the instance is started successfully.
db2start
The Database Manager is now started and we can begin the exercises by inspecting the available tables and data.
There are three pre-created tables for this exercise as described below:
• CUSTOMERS – This is a large table that contains customer data such as names, address, phone number, date of
purchase, an XML document, which describes the purchase in detail, and a text document (stored in the table as a
CLOB value), for each customer. The number of rows in the table is 100,000.
• CUSTOMERS_ARCH – This is a small table that contains similar data as in the table described above but is very
small in cardinality – only 30 rows.

IBM Software
• CODES – A relatively large table with about 50,000 rows, which contains coding information for about 50,000
customers. The data included is numerical.
To see the description of these tables and understand the data types of the included columns, connect to CUSTINFO
and view the tables.
4. Connect to the CUSTINFO database by issuing the command below.

db2 connect to custinfo
5. Type the following commands in the terminal to view the columns’ data type and size within the pre-created tables.
db2 describe table customers
db2 describe table customers_arch
db2 describe table codes
6. To improve search on the large table CUSTOMERS, let’s create some indexes on the table. Create an index on the
CUSTOMER_NAME column and another index on the XML data, which would point to the
/PurchaseOrder/itemDetails/item/partid node.
A script has been provided for your convenience. Change to the directory where the scripts and data files for this lab are
located. Type the following command in the terminal:
cd /home/db2inst1/Documents/LabScripts/Compression
7. Issue the command below in the terminal window:

less create_indexes.sql
You should see the commands that create the relational and XML indexes. Press the “space bar” to scroll down and
press “q” to exit the view.
8. Issue the following command to create the indexes:

db2 -tvf create_indexes.sql
You should see a successful output for both commands.
We have now prepared our data and in the next section we will examine the properties of each table.
4.3 Examine Table Properties
We will now use the various techniques available to view compression statistics for the tables as well as table properties. After
we have examined the statistics, we will make a decision on how to optimize the storage for the CUSTINFO database.
The administrative table function SYSPROC.ADMIN_GET_TAB_INFO provides a method to retrieve table size and state
information that is not currently available in the catalog views. It can be used to retrieve significant information about tables.
Some of the information pieces include the actual physical storage that relational, XML, and large object data occupy on disk.
We can use this information to calculate the overall table size. Based on this we can determine if there is a need to use
compression to reduce the overall storage and possibly improve performance of queries.
1. Check the tables sizes by executing the following command

IBM Software
db2 -tvf get_table_properties.sql
Figure 2 – Physical size of tables according to ADMIN_GET_TAB_INFO
Notice the TOTAL_SIZE column:

• The largest table is the CUSTOMERS table, which contains 100,000 rows and around 418MB in size.
• The second largest is the CUSTOMERS_ARCH table, with 10,000 rows, and it is about 42MB.
• The smallest table is our CODES table, which is only around 1MB.
There are no indexes on the CODES table. The indexes on the CUSTOMERS_ARCH table are system-required and
the ones on the CUSTOMERS table are a mix of system-required and the two indexes we created in the previous
section. Notice the different sizes for the relational, XML, and LOB data.
For your reference, the next table has the table sizes from above. You’ll use these to compare the compression results
later in this lab.
Note: The values below might differ, slightly, from your results depending on your current environment.
Column name CUSTOMERS CUSTOMERS_ARCH CODES

REL_DATA_SIZE 26880 2944 1152
INDEX_SIZE 17920 1024 0
LOB_SIZE 313856 31616 0
XML_SIZE 59904 6656 0
REL_DICT_SIZE 0 0 0
XML_DICT_SIZE 0 0 0
TOTAL_SIZE (KB) 418560 42240 1152
2. Now, check if these tables are enabled for compression, by executing the following statement in your terminal window.
db2 "select tabname, compression from syscat.tables where tabschema = 'DB2INST1'"

IBM Software
Figure 3 - Compression not enabled
The result shows that compression is not activated on any of the three tables since the value for the COMPRESSION
column is N.
4.4 Inline Large Object (LOB) Data
LOBs can be quite large in size (from some kilobytes up to 2GB in DB2), and are generally stored separately from the base table,
in a location managed by the database manager. When retrieving such objects, DB2 fetches the page with the relational data,
and uses the LOB descriptor stored within the table row to locate the LOB on the system. This process results in an additional
I/O operation to access the LOB itself.
To simplify the manipulation of smaller LOBs, DB2 9.7 introduced the ability to have LOB data that falls below a size threshold to
be inlined within the base table rows. This reduced the overhead of retrieving LOBs separately as these LOBs could then be
fetched with the base table data and cached in the bufferpool.
In addition, inlining LOBs within a base table row, qualifies them for row compression. DB2 cannot compress LOB values that
are stored in the separate LOB storage area. By inlining the LOB values, we get better performance and improved compression
of data within the system.
We will demonstrate how to inline LOB values using the CUSTOMERS table. The first step is to know what inline length to
specify. DB2 provides a table function called ADMIN_EST_INLINE_LENGTH, which can estimate the inline length required to
inline data stored in an XML or LOB column. We will use it to determine the approximate inline length for the CLOB column in
the CUSTOMERS table.
1. Execute the provided script as shown below, to receive an estimate of the maximum record inline length.
db2 -tvf get_max_estimate_reclength.sql
You should see an output similar to the one shown below. The returned value (5408) is the largest length that can be
specified to inline the column DATA.
Figure 4- Estimate maximum record inline length
2. Alter the table CUSTOMERS to add an inline length for the DATA column.

IBM Software
db2 "alter table customers alter data set inline length 5408"
The command should report a successful status, as shown below.
Figure 5 - Set inline length
With the above ALTER TABLE command, LOB inlining has been enabled, although the existing LOB data has not been
moved as part of the command. To move LOB data, a table reorg is to be performed on the LOB data. With the inline
length set to 5408, all LOBs that are smaller than 5408 bytes will be inlined within the base table rows.
3. Execute both commands below in your terminal. The commands might take a few seconds to complete because of the
size of the table.
db2 reorg table customers longlobdata
db2 runstats on table db2inst1.customers for indexes all
Figure 6 - REORG and RUNSTATS on table CUSTOMERS
4. Check the table properties again using the get_table_properties.sql script to see how data storage has changed.
db2 –tvf get_table_properties.sql
Figure 7 - CUSTOMERS table property after REORG and Runstats
Notice the LOB_SIZE column value for the CUSTOMERS table. It is only 1MB compared to the initial value of 313MB
(section 4.3). Most of the LOB values were inlined, increasing the REL_DATA_SIZE in physical size. The reorganization
of the LOB data has resulted in some of the system-required indexes to be reduced in size, reducing the TOTAL_SIZE
of the data as well.
Record the column values for the three tables here and compare them to your previous recordings.

IBM Software

REL_DATA_SIZE
INDEX_SIZE
LOB_SIZE
XML_SIZE
REL_DICT_SIZE
XML_DICT_SIZE
TOTAL_SIZE(KB)
4.5 Run Sample Workload
For our reference, we will run a sample workload and use the Visual Explain utility to check the estimated execution cost. This
estimated execution cost will be used in later sections to compare the effect that various compression techniques have on query
performance.
1. Open up Data Studio by clicking on the “IBM Data Studio” icon on the desktop.
Figure 8 - Open Data Studio

2. Click OK to accept the default workspace.
Figure 9 - Select the default workspace
3. By default, the Database Administration perspective is opened. Your workspace should look like the following :

IBM Software
Figure 10 - Data Studio Workspace
4. In the Administration Explorer, expand the folder All Databases and subfolders until you see CUSTINFO. Right click
on CUSTINFO and select Connect.
Figure 11 - Connecting to CUSTINFO database
5. In the pop-up dialog, fill in the connection details as follows, and click Ok.
• Database : CUSTINFO
• Host : localhost
• Port number : 50001
• User name : db2inst1

IBM Software
Figure 12 - Connection properties dialog
6. Now that you’re connected to the CUSTINFO database, open a new SQL Editor. In the Administration Explorer, first
make sure the CUSTINFO database is selected by clicking on it. Then click on New > New SQL Script.
Figure 13 - Create new SQL script
7. In the SQL editor, time in the following SQL statement and press F5 (or click on the top-right of the SQL Editor) to
execute the query.
SELECT * FROM CUSTOMERS;

IBM Software
Figure 14 - Run SQL command

8. At the bottom of the Data Studio screen, in the SQL Results pane, you should see a Successful result message.
Figure 15 - SQL execution succeeded.
9. In the SQL Editor, click the Open Visual Explain button . The button is next to the ‘ button.
10. Keep the default settings in the configuration window that pops up, click Finish and wait until the utility completes
execution.
11. Double click on the Access Plan Diagram tab to expand the bottom pane of Data Studio to see the results:
Figure 16 - Expand the Access Plan Diagram pane
12. Click on the RETURN operator. Note the estimated cost to execute the query and record it. It should be something
close to 33722.1 timerons.

IBM Software
Figure 17 - Cumulative total cost before compression
13. Restore the Access Plan Diagram window to its original size by clicking the button and minimize Data Studio so we
can continue to work with our data. We will come back to it in a little while.
4.6 Estimate Compression Savings
Now we are going to estimate the compression savings if we were to enable row compression on our various tables. For that,
we’ll make use of the table function SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO. This function provides a variety of
estimates, some of which include an estimated percentage of how many pages could be saved, an estimated percentage of how
many bytes would be saved, as well as overall estimated record length after compression. This information is reported for both
relational and XML data. The estimate provides an analysis of both static and adaptive compression.
With regards to indexes, another table function is made available to users to estimate index compression savings –
SYSPROC.ADMIN_GET_INDEX_COMPRESS_INFO.
1. Execute the following script in your terminal window to estimate relational and XML data savings.
db2 -tvf estimate_compression_results.sql > estimateResults.txt
2. To view the output of the compression estimate, open the estimateResults.txt file using gedit.
gedit estimateResults.txt &
Figure 18 - Estimate compression results for both relational and XML data
The result of the compression estimate run against the DB2INST1 schema shows that most of the savings are related
to the CUSTOMERS table.
• 77% relational data page savings and 79% XML data page savings using static compression
• 81% relational data page savings and 79% XML data page savings using adaptive compression.

IBM Software
The CUSTOMERS_ARCH table has similar estimation results as it has similar data to the CUSTOMERS table but it
only has ~ 10,000 records in cardinality compared to the 100,000 records in the CUSTOMERS table. The CODES table
only reports 1% relational data page savings. This was expected since the table contains random numerical data and
with very few repeating patterns for row compression to take much affect.
Based on these results, we will enable compression on the CUSTOMERS and CUSTOMERS_ARCH table, in the next
section. CUSTOMERS_ARCH table will not have any significant benefit due to its small size, however we will still
enable compression to see how its total physical size changes compared to the previously recorded results. The
CODES table is left as is.
3. Next, you will estimate Index compression savings. Close your gedit editor and execute the following script in your
terminal window.
db2 -tvf idx_compression_results.sql
Figure 19 - Estimate index compression
When running the table function to estimate index compression savings, we notice very little or no savings on the
ITEMID index. One of the system-required indexes and NAMEINDEX both see relatively good improvement with 12%
and 32% data page savings respectively. Since Index Compression is automatically enabled with Row Compression,
any new indexes will automatically be compressed. However, existing indexes need to be altered to enable
compression. We will demonstrate this on the user created index; NAMEINDEX.
The ITEMID index may not be compressed well as it contains information that is not contained within the base data, and
may not be added to the relational dictionary.
4.7 Enable Classic Row Compression
We will now enable classic row compression as we decided in the previous section for the CUSTOMERS and
CUSTOMERS_ARCH tables. Since these tables are pre-populated with data, we can’t make use of the Automatic Dictionary
Creation; therefore we will need to perform an offline reorg after we enable compression.
1. Enable row compression by executing the following commands in your terminal window:
db2 alter table customers compress yes static
db2 alter table customers_arch compress yes static
db2 alter index DB2INST1.NAMEINDEX compress yes

IBM Software
Figure 20 - Enable classic row compression on CUSTOMERS and CUSTOMERS_ARCH tables
All commands should report a successful status. At this point compression is enabled on our tables and the index
‘NAMEINDEX’. If we continue to load data, ADC will kick in at a certain point and create a dictionary based on the data
that already exists but the sampling data will not be compressed. Since we have a lot of data in our CUSTOMERS table,
we want to perform an offline reorg on the tables to create a dictionary and compress all rows.
2. Execute the following commands in your terminal window to reorganize relational table data.
db2 reorg table customers
db2 reorg table customers_arch
Figure 21 - Reorg on tables CUSTOMERS and CUSTOMERS_ARCH
The relational dictionaries for both CUSTOMERS and CUSTOMERS_ARCH tables should now be created and
relational data and indexes should be compressed.
3. Execute the following commands in your terminal window to reorganize XML table data and indexes related to both
CUSTOMERS and CUSTOMERS_ARCH tables.
db2 reorg table customers longlobdata
db2 reorg table customers_arch longlobdata
db2 reorg indexes all for table customers
db2 runstats on table db2inst1.customers and indexes all
Figure 22 - REORG operation on XML data and Index

The XML dictionary is now created and the XML data is compressed in the XML Data Area.

IBM Software
4.8 Inspecting Compression Results
In this section we will use the available tools to see how our data compressed.
1. Let’s see what the actual savings were for data and indexes as reported by the two compression table functions.
Execute the following script in your terminal. To view results, launch the result file in gedit. The attributes with ‘_Current’
reflect the actual compression results
db2 -tvf estimate_compression_results.sql > estimateResultsAfterComp.txt
gedit estimateResultsAfterComp.txt &
Figure 23 - Inspect compression results
You will find that executing the script after enabling compression has changed its output. You will notice that
ROWCOMPMODE now has an S against the tables with compression enabled. The character ‘S’ represents static
compression. To see the total data page savings achieved by using static compressions, refer to the column
“PCTPAGESSAVED_CURRENT”. It can be observed that 77% of XML data pages and 76% of relational data pages
from the CUSTOMERS table were saved and 77 % and 63% data pages, respectively, from the CUSTOMERS_ARCH
table.
2. Let’s see how the physical sizes of the different database objects changed. Execute the get_table_properties.sql script
again as follows:
Figure 24 - Inspect table sizes
Now take a look at the physical sizes of the various database objects, including the total size of the CUSTOMERS table,
the table has shrunk to nearly half the original size. The inlined LOB objects being included in the compression process
further reduced the overall table size.
3. Record the column values for the three tables and compare them to your previous recordings.

IBM Software

REL_DATA_SIZE
INDEX_SIZE
LOB_SIZE
XML_SIZE
REL_DICT_SIZE
XML_DICT_SIZE
TOTAL_SIZE(KB)
4. Let’s see how the indexes were compressed. Execute the following script in your terminal.
db2 -tvf idx_compression_results.sql
Figure 25 - Examine index compression results
The actual index compression results are better than expected; the NAMEINDEX has been compressed with 42%
pages saved. You can see that it has been compressed by the INDEX_COMPRESSED attribute having changed to ‘Y’.
All other indexes remain uncompressed with estimates provided for one of the system indexes.
5. Now execute the RUNSTATS command to update the statistics in order to be able to leverage the performance
increase in Visual Explain in the following steps.
db2 runstats on table db2inst1.customers
Figure 26 - RUNSTATS on table CUSTOMERS
4.9 Run Sample Workload on Compressed Data
We can now run the same workload as in section 3.5 and see how the query performs after data has been compressed.
1. Bring back the Data Studio that we minimized to the taskbar, and run the same script again by, navigating to the SQL
editor and either pressing f5 or clicking on the “Run SQL” button.
At the bottom of the Data Studio screen, in the SQL Results pane, you should see a Successful result message.

IBM Software
Figure 27 - Check workload result
2. Next, in the SQL Editor, click the Open Visual Explain button .
3. Click Finish in the configuration window, which pops up and wait until the utility has finished executing. Finally, expand
the bottom pane of Data Studio to see the results.
Figure 28 - Expand Visual Explain pane
Note that the time it takes DB2 to perform the workload is now close to 6768.34 timerons compared to the 33722.1
timerons as reported by Visual Explain before classic row compression was enabled on the table. Not only did we save
on storage by enabling compression, but we also improved the performance of the query.
BEFORE AFTER
Figure 29 Comparative cumulative total cost BEFORE and AFTER classic compression

IBM Software
4.10 Applying Adaptive Compression
DB2 10 has further improved on classic row compression by introducing a new hybrid compression technique, referred to as
adaptive compression. Adaptive compression offers the most dramatic possibilities for storage savings by leveraging classic row
compression and also working on a page-by-page basis to further compress data.
Up until now, you have been using static compression in order to examine performance and storage benefits. You will now
apply adaptive compression. This section of the lab will have you upgrade a specific table from using static compression to
adaptive compression, and analyze the results afterwards.
1. Switch back to the command line terminal and inspect the current CUSTOMER table properties by executing the script
below.
Figure 30 - Inspect CUSTOMER table properties

Take note of the CUSTOMERS table relational data size and total size.
2. Next, execute the script below to inspect the estimated savings on the current CUSTOMERS table. The current savings
showcase the savings achieved using static compression. Expand the screen to properly view the output.
db2 -tvf compare_static_adaptive.sql
Figure 31 - Estimated adaptive compression savings in CUSTOMERS table
You will notice that the estimated PCTPAGESSAVED_ADAPTIVE is higher than the current static compression values.
This is due to the fact that adaptive compression uses two compression approaches. It first uses 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.
3. Take note of the columns PCTPAGESSAVED_CURRENT, and AVGROWSIZE_CURRENT.
Column name Value

IBM Software
PCTPAGESSAVED_CURRENT
AVGROWSIZE_CURRENT
4. Next, apply adaptive compression on the CUSTOMERS table by executing the script below.
db2 alter table customers compress yes adaptive
db2 reorg table customers
db2 runstats on table customers and indexes all
Figure 32 - Enable adaptive compression on CUSTOMERS table

5. Then, inspect the table properties to check the new results after applying adaptive compression.
db2 –tvf get_table_properties.sql
Figure 33 -Inspect table properties after applying adaptive compression
Notice that the relational data size has been further compressed, thereby promoting a reduction in the total size of the
table.
6. Finally, inspect the savings after applying adaptive compression.
db2 –tvf compare_static_adaptive.sql
Figure 34 -Compare static compression vs. adaptive compression

Notice there are additional savings in the amount of pages stored, as well as a reduction of the average row size.
Performing adaptive compression results in 86% page savings, more than was estimated. Performing Adaptive
compression led to 10% increase in savings when compared to the earlier results from static compression.
7. Now, inspect the performance benefits of adaptive compression. Bring back the Data Studio that we minimized to the
taskbar. Navigate to the SQL editor and run the same SQL script by pressing F5 or clicking on .
At the bottom of the Data Studio screen, in the SQL Results pane, you should see a Successful result message.

IBM Software
Figure 35 - Check workload result
8. Next, In the SQL Editor, click the Open Visual Explain button .
9. Click Finish in the configuration window, which pops up and wait until the utility has finished executing. Finally, expand
the bottom pane of Data Studio to see the results.
Figure 36 - Expand Visual Explain pane Deleted: 39
Note that the time it takes DB2 to perform the workload is now close to 6433 timerons compared to the 33722.1 and
6768.34 timerons as reported by Visual Explain with no compression techniques, and classic row compression
respectively. Not only did we save on storage but we also improved the speed of the query by enabling adaptive
compression, thereby illustrating the performance advantages of this new technology.

IBM Software
No compression Classic row Adaptive row

compression compression
Figure 37 – Comparative cost between no compression, classic row compression and adaptive compression Deleted: 40
5 Summary
This concludes the DB2 Storage Optimization lab. In this lab, we performed several operations including demonstrating various
compression techniques that DB2 employs, as well as compressing different data types including relational, xml, large object,
and index data. We examined the compression and performance savings by using various tools and built-in DB2 functions that
perform detailed reporting such as the Visual Explain tool and the ADMIN_GET_TAB_COMPRESS_INFO function. Finally, we
also had a look at the new adaptive compression feature in DB2 10 and the additional storage and performance savings that can
be achieved through its use.
With industry-leading compression technologies, DB2 not only allows greater savings in storage cost, it also improves
performance as queries on a compressed table needs fewer I/O operations to access the same amount of data.
6 Cleanup
1. Right-click on CUSTINFO database from within the Data Source Explorer and select Disconnect.
Figure 38 - Close CUSTINFO database connection Deleted: 41
1. Close Data Studio and switch back to the terminal window that you have been using so far, and then execute the
command below to clean your environment after completing the exercise. Use ‘password’ as password.
su –
cd /home/db2inst1/Documents/LabScripts/Compression/setup
./cleanup.sh

IBM Software
cd /home/db2inst1/Documents/LabScripts/Compression/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
DB2® Range Partitioning

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 About this Lab......................................................................................................................................................................................3
4 DB2 Range Partitioning Basics and Setup .......................................................................................................................................3
4.2 Initial Steps ......................................................................................................................................................................................................... 3
4.3 Inspecting the Database, Table Spaces and Range Partitioned Table .............................................................................................................. 4
4.4 Examine Table Spaces ....................................................................................................................................................................................... 9
4.5 Create Materialized Query Table ........................................................................................................................................................................ 9
4.6 Load Table Data into the Range Partitioned Table........................................................................................................................................... 12
5 Attaching a Partition .........................................................................................................................................................................18

5.1 Examining Creation of Staging Table ............................................................................................................................................................... 19
5.2 Load Table Data into Staging Table ................................................................................................................................................................. 19
5.3 Attach New Partition ......................................................................................................................................................................................... 21
6 Detaching a Partition.........................................................................................................................................................................23
6.1 Detach Partition ................................................................................................................................................................................................ 23
7 Summary ............................................................................................................................................................................................25
8 Clean up..............................................................................................................................................................................................25
DB2 Range Partitioning

IBM Software
1 Introduction
DB2 10 contains innovative features for delivering information on demand and scaling databases to new levels. The Table
(Range) Partitioning capabilities in DB2 provide a number of advantages including better query performance, improved large
table manageability, and increased availability for data roll-in/roll-out. The Large Row Identifier (RID) allows for creation of tables
and indexes that are terabytes in size. Together these features enable the ability to create and easily manage databases with
virtually unlimited capacity, and are especially beneficial in large data-warehousing environments.
2 About this Lab

This lab will cover a wide range of features and functionalities related to DB2 range partitioning, including the following:
• Creating range partitioned tables
• Examining table spaces
• Materialized query tables
• Loading data into partitioned ranges
• Attaching and detaching partitions
• Enhancements to SET INTEGRITY command
3 Suggested Reading
Table partitioning in DB2 (developerWorks article)
http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja2/index.html
Best Practices: Physical Database Design

http://www.ibm.com/developerworks/data/bestpractices/databasedesign/
4 DB2 Range Partitioning Basics and Setup


4.2 Initial Steps
2. At the login prompt, log in with the following credentials:

IBM Software
3. Open a terminal window by right-clicking on the Desktop and choosing the Open in Terminal item.
Figure 1 - Open a new Terminal window
4. Ensure that the DB2 Database Manager has been started by issuing the following command at the prompt:
db2start
Attention: This command will only work if you logged in as the user db2inst1. If you accidentally logged in as
another user, then type su - db2inst1 at the command prompt. Password: password.
4.3 Inspecting the Database, Table Spaces and Range Partitioned Table
We have provided you with a script, which creates a database, the needed table spaces and the range-partitioned table that you
will work with in this portion of the lab. The script has already been executed so there is no need to run it again. However, it
would be beneficial to understand the partitioned environment you are working with.
1. Change your working directory to the folder containing the script mentioned.
cd /home/db2inst1/Documents/LabScripts/RangePartition
2. Take a look at the script using your favorite editor. Note how the database, table spaces, and table are being created:
less createDBandTable.sql
Note: You can use the arrow keys to scroll up and down in the script and type the letter “q” to exit anytime.
The script creates a database named RANGE, 16 table spaces and all tables:
Table Space Name(s) Table Space Use

TBLSPC0 – TBLSPC6 Partitioned Data

IBM Software
TBLSPC0I – TBLSPC6I Partitioned Indexes

NOPART Non-partitioned version of CAR_ORDER table
MQTTS Materialized Query Tables used for the lab
Figure 2 – Table space Name/Use
The name of the main partitioned table that we will be working with is CAR_ORDER. The table is partitioned on each year and
each partition is stored in a separate table space. Indexes defined on the table are also partitioned, each partitioned in a
designated table space. As we will see this becomes very beneficial when the DB2 optimizer creates an access plan for queries
that only involve data in specific partitions, only those data and index partitions are accessed when returning the result set.
Another table, YR_2006, is created in this script which will be used for attaching partitions to the CAR_ORDER table as a new
partition later in the lab.
A non-partitioned table, CAR_ORDER_NOPART identical to the CAR_ORDER table is also created. This table will be used in
an exercise that will emphasize the benefits of partition elimination.
The following is a logical representation of the CAR_ORDER table that we have just created. All of the data starting from the
beginning of 2000 to the end of 2005 will be split-up into ranges by year and will be put in the 6 table spaces TBLSPC0 -
TBLSPC5. Each partition (data and index) is stored in a specific table space. Since table spaces can be assigned to dedicated
storage, each partition can effectively have its own dedicated storage components.
TBLSPC0 TBLSPC1 TBLSPC2 TBLSPC3 TBLSPC4 TBLSPC5
Y2000 Data Y2001 Data Y2002 Data Y2003 Data Y2004 Data Y2005 Data
TBLSPC0i TBLSPC1i TBLSPC2i TBLSPC3i TBLSPC4i TBLSPC5i
Y2000 Y2001 Y2002 Y2003 Y2004 Y2005

Indexes Indexes Indexes Indexes Indexes Indexes
Figure 3 – Mapping of Partitions to Table Spaces
3. Let’s have a look at the definition of the table and the data partitions. Click on ‘”IBM Data Studio” icon on desktop.

IBM Software
Figure 4 – Opening IBM Data Studio
4. In the Select a workspace dialog, accept the default path and click OK.
Figure 5 – Creating a Workspace
5. Data Studio will now start in the Database Administration perspective as shown below.

IBM Software
Figure 6 – Data Studio Database Administration Perspective
6. Expand the Database Connections in the Administration Explorer menu on the left-hand side, right-click on the RANGE
database and click Connect.
• User: db2inst1

IBM Software
Figure 7 – Connecting to a database
7. Once successfully connected, in the Administration Explorer view, expand the following nodes by clicking the icons
beside them: RANGE > Tables.
8. Select the CAR_ORDER table to view its details in the Properties tab on the bottom.
9. Click on Data Partitions in the menu to view the data partitions for this table.
Figure 8 – Data Partitions for table CAR_ORDER

IBM Software
You should see 6 data partitions named “Y2000” to “Y2005” similar to the picture above. You will continue to use Data Studio
throughout the rest of the exercises, therefore you should leave it open after you have finished analyzing the Data Partitions.
4.4 Examine Table Spaces

A script that reports the number of used pages in each table space in the RANGE database has been provided for you. This
script can be executed at any time during this lab. Let’s perform our first check on the table spaces by issuing the following
commands:
1. Open a new terminal window by right clicking on the Desktop and selecting Open in Terminal.
2. Execute the showTablespaces.sh script by typing the following:
./showTablespaces.sh > tb_examine1
3. Open the file tb_examine1 using your favorite text editor and take a look at this output.
less tb_examine1
One thing to note is the low page usage for MQTTS. This is because the MQTTS table space has no data objects defined
or built yet. Press ‘q’ on keyboard to exit the less utility.
4.5 Create Materialized Query Table

A materialized query table (MQT) is a table whose definition and data are defined by a query. MQTs can significantly improve
the performance of queries as the optimizer can rewrite queries to use MQT’s summarized data instead of accessing the base
tables.
Since range partitioned tables usually hold a large amount of data, the use of MQT based on this kind of table is common in
warehouse environments. In order for you to experience the dependency between an MQT and their base tables, we will create
an MQT that is based on the CAR_ORDER table.
1. Open the history.sql file containing the necessary commands to create this table by clicking on File at the top menu and
selecting Open File…

IBM Software
Figure 10 – Open File
2. In the popup window navigate to /home/db2inst1/Documents/LabScripts/RangePartition/history.sql.
3. After selecting the file “history.sql”, press OK. You will see the following create table statement in the command panel:
Figure 11 – history.sql
4. Press F5 to execute the SQL statement.
5. You will be prompted to confirm the database that you would like to run these commands against. Select the RANGE
database from the list and click Finish.

IBM Software
6. Check that the command you have entered above is executed without errors by looking at the bottom result panel:
Figure 14 – Result of SQL Query
7. Close the history.sql command window after examining the output by clicking on the “X” button at the top right-hand corner
of the window.
Figure 15 – Close File

IBM Software
8. Navigate to RANGE > MQTs in the Administration Explorer view. Right-click MQT and select “Refresh”. You should now
see the HISTORY table.
Figure 16 – MQTs
4.6 Load Table Data into the Range Partitioned Table

We have created the tables CAR_ORDER and the dependent MQT HISTORY table. We are now ready to load some data into
the CAR_ORDER table. This section will also show the use of SET INTEGRITY command through Data Studio and the
command line to take tables out of a check pending state after using the LOAD UTILITY.
1. In Data Studio, within the Administration Explorer view, navigate to RANGE > Tables. You will see the CAR_ORDER
table within this list. If you cannot navigate here, make sure you reconnect to the database.
2. Right-click on the CAR_ORDER table and select the Load option, then select With Load Utility.

IBM Software
Figure 17 – Load Delimited File
3. You can either navigate using Browse or directly input the following input files path:
/home/db2inst1/Documents/LabScripts/RangePartition/ORDER.TBL
Figure 18 – Select File to Load
4. After entering this path click “Run” to start the load of data from the flat file ORDER.TBL into the table “CAR_ORDER”.

IBM Software
Figure 19 – Run Load Operation
5. Make sure that all records have been successfully loaded into the database.
Figure 20 – Load Query Result
6. Close the Load Table CAR_ORDER tab in the main view by clicking its icon.
Now that we have loaded the data, the CAR_ORDER table is in Set Integrity Pending No Access state. We must use the Set
Integrity command check its constraints and bring the table back online.
7. Navigate to the “CAR_ORDER” table as done previously, right-click on the table and select “Manage > Set Integrity…”.

IBM Software
Figure 21 – Set Integrity
8. Leave all options as defaults and press “Run” to start the set integrity.
Figure 22 – Run Set Integrity
9. Ensure that the operation finished without errors in the “SQL Results” window and in the Messages tab.
Figure 23 – Result of Set Integrity Operation

IBM Software
10. Close the Set Integrity CAR_ORDER tab in the main view by clicking its icon.
Now the CAR_ORDER table is back online and we can inspect its contents. Right-click on the CAR_ORDER table to bring
up the menu and select Browse Data within the menu. Note that only the first 500 rows of the table are fetched.
Figure 24 – Browse CAR_ORDER data
Figure 25 – Browse CAR_ORDER Data
11. We will now perform the same action to set the integrity of the HISTORY table. Open one of your previously used command
terminals and issue the following command:

IBM Software
db2 CONNECT TO RANGE

db2 SET INTEGRITY FOR HISTORY ALLOW NO ACCESS IMMEDIATE CHECKED
Figure 26 – SET INTEGRITY operation
12. Take this opportunity to query the status of the table spaces. Execute the following:
less tb_examine2
Notice how the data from the table has been spread across the table spaces (TBLSPC0 – TBLSPC5). Since we have not
yet defined indexes no pages are required by the index table spaces.
Now that we have run Set Integrity against the HISTORY MQT, we can inspect its contents in a similar manner to that of the
CAR_ORDER table. Remember, this table is located under RANGE > MQTs.
14. Right click the HISTORY table and select “Browse Data”.
Figure 27 - Browse history table
The output should look similar to the following:

IBM Software
Figure 28 – Browse HISTORY MQT Data
5 Attaching a Partition
After completion of this section of the exercise the student will be able to:
• Load data into a staging table with a table space for partitioned index defined.
• Alter the CAR_ORDER table to attach data from the staging table as a new partition.
• Explore data availability enhancements.
The following is a logical representation of loading data into the staging table YR_2006 and attaching the table as a new data
partition in the range-partitioned table CAR_ORDER and then setting the integrity:
YR_2006 TABLE
Figure 29 – Attach Partition

IBM Software
5.1 Examining Creation of Staging Table
1. Before loading data into the staging table YR_2006, take a look again at the createDBandTable.sql script, and note how
the staging table is defined. Note how the “index in” clause is specified in the CREATE TABLE statement for the staging
table YR_2006. When the staging table is attached any partitioned indexes defined on the CAR_ORDER table will be
created for the new partition. Indexes are actually built when the SET INTEGRITY command is run.
less createDBandTable.sql
Note: If the “index in” clause was not specified, the index partition for the new data partition would be created in the same table
space as the corresponding data partition.
2. Run the create_index.sql script to create an index on the CAR_ORDER tables.
db2 -tvf create_index.sql
5.2 Load Table Data into Staging Table
1. Load some data into the “YR_2006” table. Using Data Studio, right click the YR_2006 table and select “Load” > “With Load
Utility”.
Figure 30 – Load into Staging Table
2. Enter the input file path for the load operation by either navigate using Browse or directly input the following input files path:
/home/db2inst1/Documents/LabScripts/RangePartition/yr_06.TBL

IBM Software
Figure 31 – Select Load File
3. Click “Run” to start the load of data from the “YR_06.TBL” flat file into table “YR_2006”.
Figure 32 – Run Load Operation
A message on the result view should indicate that these commands have executed successfully.
4. Inspect the data that was loaded by right clicking on YR_2006 and select Browse Data.
Note that you did not need to run SET INTEGRITY as there are no constraints nor indexes defined on the YR_2006 table,
hence the table is brought online right after the LOAD command is executed.
Figure 33 – Browse Data in Staging Table

IBM Software
5. Take this opportunity to go back to the terminal window to display the table space page usage and execute the following:
less tb_examine3
Note the number of used pages for TBSPC6 has increased as data was loaded.
5.3 Attach New Partition

The staging table YR_2006 now has data in it and is ready to be attached as a partition to the CAR_ORDER table.
With DB2 10, when attaching a new data partition using ALTER TABLE … ATTACH/ADD PARTITION, the target partitioned
table remains online. Dynamic queries running under the Read Stability (RS), Cursor Stability (CS), or Uncommitted Read (UR)
continue to have access to the table.
1. Execute the following command in a command terminal:
db2 connect to RANGE

db2 "ALTER TABLE CAR_ORDER ATTACH PARTITION Y2006 STARTING '2006-01-01'
INCLUSIVE ENDING '2006-12-31' FROM yr_2006"
The newly attached data with date range 01/01/2006 to 12/31/2006 is not yet visible in the CAR_ORDER table because it is
not yet validated by the SET INTEGRITY statement. The SET INTEGRITY statement is necessary to verify that the newly
attached data is within the defined range.
2. If you wish to test it, before running SET INTEGRITY, run the following query. It will not return any rows at this point, as the
new data partition is still under Set Integrity Pending state.
db2 "select * from car_order where date > '2006-01-01' "
In previous DB2 releases, the table would be taken out of set integrity pending state by performing a SET INTEGRITY…
IMMEDIATE CHECKED command, thus performing the required integrity processing on the table.
What if data integrity checking, including range validation and other constraints checking, can be done through application
logic that is independent of the data server before an attach operation? Starting in DB2 10, the newly attached data can be
made available for use much sooner.
You can optimize the data roll-in process by using the SET INTEGRITY…ALL IMMEDIATE UNCHECKED statement to skip
range and constraints violation checking. In this case, the data partition is brought out of Set Integrity Pending state, and the
new data is available for applications to use immediately, as long as there are no non-partitioned indexes on the target table.
Otherwise, the SET INTEGRITY… ALL IMMEDIATE UNCHECKED is automatically converted to a SET INTEGRITY…
IMMEDIATE CHECKED, consequently triggering the required integrity processing on the table.
3. Considering the data in the attached partition was previously checked, use the following commands to set the integrity on
both CAR_ORDER and HISTORY tables without performing integrity processing:

IBM Software
db2 SET INTEGRITY FOR CAR_ORDER ALL IMMEDIATE UNCHECKED

db2 SET INTEGRITY FOR HISTORY ALL IMMEDIATE UNCHECKED
Note: Although the MDC is taken out of the check pending state, it is not refreshed, that is, the 2006 data is not showing in
HISTORY. To refresh the MDC, the following procedure must be followed:
db2 SET INTEGRITY FOR CAR_ORDER OFF CASCADE IMMEDIATE
db2 SET INTEGRITY FOR CAR_ORDER IMMEDIATE CHECKED
db2 SET INTEGRITY FOR HISTORY IMMEDIATE CHECKED
Switch back to Data Studio to perform the rest of the commands below.
4. Right-click the Tables folder, select Refresh. Navigate to the “CAR_ORDER” table, click the “PROPERTIES” tab, and
select the Data Partitions menu option.
Notice that there is a new partition “Y2006” listed.
Figure 34 – Result of Attach Operation
5. Close the CAR_ORDER tab in the main view by clicking its icon. Notice that the staging table “YR_2006” no longer exists!
It has become a data partition in the range-partitioned table CAR_ORDER.
6. Take this opportunity to go back to the terminal window to display the table space page usage and execute the following:
Note how the number of “Used Pages for TBSPC6I has increased significantly this time, due to the building of the
partitioned index.
7. Since we are in the terminal, we can also execute the SELECT statement used before which will now allow us to view the
newly attached data with date range 01/01/2006 to 12/31/2006 in the CAR_ORDER table.
db2 "select * from db2inst1.car_order where date > '2006-01-01' "

IBM Software
6 Detaching a Partition
The following is a logical representation of the detach operation. The detached partition becomes a separate table and the data
is no longer available in the partitioned table.
CAR_ORDER TABLE
TBLSPC1 TBLSPC2 TBLSPC3 TBLSPC4 TBLSPC5

PART0 PART1 PART2 PART3 PART4
DETACH
TBLSPC0
YR_2000
Figure 34 – Detach Partition
6.1 Detach Partition

We will now detach one of the partitions from the CAR_ORDER table.
1. Execute the following command in the same terminal used for the previous statements:
db2 "ALTER TABLE CAR_ORDER DETACH PARTITION Y2000 INTO yr_2000"
2. You must perform set integrity on the HISTORY table since the YR_2000 is a dependent table which needs to be
incrementally maintained with respect to the detached data partition so it is initially inaccessible. Use the following
command to set the table integrity:
db2 SET INTEGRITY FOR HISTORY ALLOW NO ACCESS IMMEDIATE CHECKED
3. In Data Studio, right-click the Tables folder, select Refresh. Navigate to the CAR_ORDER table, click on the table and
select the Data Partitions option from the menu within the Properties view. In the window, notice that the “Y2000” partition
is no longer listed because it has been detached into a standalone table “YR_2000”.

IBM Software
Figure 35 – yr2000 partition detached to YR_2000 table
4. Now inspect the YR_2000 table that has been detached from the CAR_ORDER table. Right-click on the “YR_2000” table
and select “Browse data”. Notice that the data with year 2000 dates are located in the YR_2000 table.

IBM Software
Figure 36 – YR_2000 table data
7 Summary
By now, you will have experienced the benefits of implementing DB2’s range partitioning features. You now understand how
range partitioning can allow for quick roll-in and roll-out of data and near limitless scalability. Furthermore, you have touched
upon features and functionalities such as materialized query tables, SET INTEGRITY statements and index creation.
8 Clean up
1. To clean your environment after completing the exercise, if you would like to redo this lab in the future, please right-click
on RANGE database, select Disconnect, close Data Studio and execute the commands below in a terminal. Use
“password” as password.
su -
cd /home/db2inst1/Documents/LabScripts/RangePartition/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/RangePartition/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
Temporal Data Management

Hands-On Lab
IBM Software
Table of Contents
1 Introduction............................................................................................................................................................................................3
2 About This Lab.......................................................................................................................................................................................3
3 Environment Setup Requirements.......................................................................................................................................................3
3.1 Login to the Virtual Machine ............................................................................................................................................................................. 3
4 System-Period Temporal Tables..........................................................................................................................................................4

4.1 Creating a System-Period Temporal Table ...................................................................................................................................................... 4
4.2 Creating the History Table ................................................................................................................................................................................ 6
4.3 Enable Versioning for the Pair of Base and History Table................................................................................................................................ 7
4.4 Manipulating Data in System-Period Temporal Tables .................................................................................................................................... 7
4.4.1 Inserting Data into a System-Period Temporal Table........................................................................................................................... 7
4.4.2 Updating a System-Period Temporal Table.......................................................................................................................................... 9
4.4.3 Deleting Data from a System-Period Temporal Table .......................................................................................................................... 10
4.4.4 Querying a System-Period Temporal Table ......................................................................................................................................... 10
4.4.4.1 SYSTEM_TIME AS OF clause ............................................................................................................................................................. 11
4.4.4.2 SYSTEM_TIME FROM …TO… clause ................................................................................................................................................ 12
5 Application-Period Temporal Tables ...................................................................................................................................................12

5.1 Creating an Application-Period Temporal Table............................................................................................................................................... 13
5.2 Temporal Data Management with Business Time ............................................................................................................................................ 14
5.2.1 Inserting into an Application-Period Temporal Table............................................................................................................................ 14
5.2.2 Updating and Querying Application-Period Temporal Tables .............................................................................................................. 14
5.2.3 Deleting data for portions of Business Time in an Application-Period Temporal Table........................................................................ 16
6 Bitemporal Tables .................................................................................................................................................................................17

6.1 Update a Bitemporal table ................................................................................................................................................................................ 17
6.2 Querying a Bitemporal Table ............................................................................................................................................................................ 18
7 Playing with Time ..................................................................................................................................................................................19

7.1 Setting the Current Time Registry Variable ...................................................................................................................................................... 19
7.1.1 CURRENT TEMPORAL BUSINESS_TIME.......................................................................................................................................... 19
7.1.2 CURRENT TEMPORAL SYSTEM_TIME ............................................................................................................................................. 20
7.2 Finding the Previous Version of a Row............................................................................................................................................................. 20
7.2.1 Using the History Table ........................................................................................................................................................................ 20
7.2.2 Using the Base Table ........................................................................................................................................................................... 20
OPTIONAL EXERCISES................................................................................................................................................................................21
8 Constraints on the History Table for System-Period Temporal Tables (optional)..........................................................................21
9 Altering a Table with Versioning Enabled (optional) .........................................................................................................................21
9.1 Adding a Column .............................................................................................................................................................................................. 21
9.2 Dropping Objects .............................................................................................................................................................................................. 22
9.2.1 Dropping a Table .................................................................................................................................................................................. 22
9.2.2 Dropping a Column............................................................................................................................................................................... 23
10 Summary ................................................................................................................................................................................................24
11 Cleanup...................................................................................................................................................................................................24
Temporal Data Management in DB2

IBM Software
1 Introduction
Pericles, a great Athenian statesman, once said “Time is the wisest counsellor of all”. This saying is as true today as was in
Ancient Greece. Time plays a key role in allowing organizations to better understand themselves. Organizations use the history
of stored data along with the study of how that data transforms over time, to better understand the impact they make. More so, in
recent years, stricter governance and compliance policies have created a greater need for organizations to learn from “time” and
to be aware of the accuracy of their data. Along with compliance, tracking time also allows organizations to manage the aspect
of time for their business information, such as ‘effective dates for an insurance policy’. In an effort to allow organizations to
accomplish this, IBM has developed greater awareness of time within DB2.
Prior to this release, database professionals had to create complex triggers or use application logic to manage time-dependent
conditions. With DB2’s new temporal data management technology, database professionals can, now, track and query these
conditions using newly introduced table design options, query syntax and semantics. Thus alleviating the need to go through
complex application logic and giving developers the control to ensure consistent handling of time-related events across the
system.
DB2’s temporal data management introduces several new concepts. System time involves tracking when changes are made to
the state of a table; such tables are referred to as system-period temporal tables (STT). Business time involves tracking the
effective dates of certain business conditions, also referred to as “application time”. Tables tracking application/business time
are referred to as application-period temporal tables (ATT). Some organizations might require tracking both types of temporal
data in a single table; such tables would be considered bitemporal (BTT). This hands-on lab introduces you to these key
concepts and capabilities of DB2’s temporal data management.
2 About This Lab

To help you understand DB2’s temporal data management support, this lab walks you through a simple application scenario and
its sample data. The scenario involves a library system responsible for tracking resources that are checked out from the library.
Using this scenario, the lab demonstrates how to enable temporal data management along with the process of using its key
concepts.
Throughout the lab, each of the different types of temporal tables will be created and scenarios highlighting the ways to track
and query data based on time will be demonstrated. After all of the fundamentals are covered, some specific advanced
scenarios will be discussed– such as finding the previous version of a row.

• DB2 10 Bootcamp VMware® image
3.1 Login to the Virtual Machine
1. Start the VMware image. Use the login credentials below when prompted:
• User: db2inst1

IBM Software
2. Open a terminal window by right-clicking on the Desktop and choosing the “Open Terminal” item:
Figure 1: Open a new Terminal window
3. Start the Database Manager by issuing the following command:

db2start
4 System-Period Temporal Tables

System time tracks the changes made to the data of the table. This allows querying the data historically. The subsequent
sections demonstrate how to use system time and how to implement it.
In the upcoming example, a LOANS table is created as a STT. The current status of each resource is stored in the LOANS table
and the past historical data is stored in the LOANS_HISTORY table.
4.1 Creating a System-Period Temporal Table
Use the following steps to create a system-period temporal table (STT):
1. Open IBM Data Studio by double clicking the icon on the desktop. Use the default workspace.
Figure 2: Open Data Studio and use the default workspace

IBM Software
2. Open the create script for the system-period temporal base table. In Data Studio, click menu File > Open File on the
top left hand corner.
3. Navigate to the /home/db2inst1/Documents/LabScripts/Temporal directory and open the file named
System_Base.sql. When prompted, press Ok to use the default statement terminator (semi-colon).
CREATE TABLE LOANS (
id INT primary key not null,
Title VARCHAR(255),
BorrowerID INT,
Duration INT,
Renewable CHAR(1),
sys_start TIMESTAMP(12) GENERATED ALWAYS
AS ROW BEGIN NOT NULL,
sys_end TIMESTAMP(12) GENERATED ALWAYS
AS ROW END NOT NULL,
trans_start TIMESTAMP(12) GENERATED ALWAYS
AS TRANSACTION START ID IMPLICITLY HIDDEN,
PERIOD SYSTEM_TIME (sys_start, sys_end)
);
Attention: All commands are denoted by the text within the grey shaded area.
4. Ensure you will execute the query against the TEMPORAL database by right-clicking inside the SQL Editor of Data
Studio.
5. Select ‘Use Database Connection’, click TEMPORAL and then click Finish.
6. Enter the credentials in the Properties pane – user name: db2inst1 password: password, save this information for
future connections.
Figure 3: Enter the credentials to connect to the TEMPORAL database

IBM Software
7. Execute the script by pressing the run button in Data Studio, or press F5 while the cursor is inside the SQL Editor.
Figure 4: Execute the script against the TEMPORAL database
4.2 Creating the History Table

1. Open a new SQL Editor by clicking New > New SQL Script in the Administration Explorer view (Figure 5).
Attention: All subsequent instructions consider that you have a clear SQL editor. Please clear the previous command before
moving on to the next one.
2. We’ll create the history table using a CREATE TABLE statement with the LIKE clause. This ensures that the history
table has the same columns as the base table.
Type in the following statements. The first one creates the history table whereas the second statement selects from the
newly created table. Execute the commands by pressing F5. When prompted, select the connection to the TEMPORAL
database.
CREATE TABLE LOANS_HISTORY LIKE LOANS;

SELECT * FROM LOANS_HISTORY;
Note: When executing multiples commands at a time like the instructions above, to see individual results, expand the result entry
by clicking the triangle (see the SQL Results tab in Figure 5) and then click the command you wish to see the results for. The results are
shown in the Result tab on the bottom-right corner (by default it is on the status tab).

IBM Software
expand results for

multiple queries
Figure 5: Create the history table and verify that it has been created properly
4.3 Enable Versioning for the Pair of Base and History Table
After the tables are created, we need to add versioning to establish the link between the system-period temporal table and the
history table. Once versioning is enabled, DB2 automatically copies old versions of the data to the corresponding history table.
1. Enable versioning by altering the base table. Type the following into the SQL Editor and execute it.
ALTER TABLE LOANS ADD VERSIONING USE HISTORY TABLE LOANS_HISTORY;
4.4 Manipulating Data in System-Period Temporal Tables
4.4.1 Inserting Data into a System-Period Temporal Table
Inserting new data into a STT is no different than inserting into a regular table.
1. In Data Studio, select File -> File Open, and navigate to open the insert_resources_sys.sql script. It resides in the
following directory: /home/db2inst1/Documents/LabScripts/Temporal/. Notice these are regular SQL INSERT
statements.
2. Execute the script (press F5) against the TEMPORAL database (refer to Section 4.1 on selecting connections to the
database).

IBM Software
Figure 6: Insert data into the STT
3. Inspecting the LOANS table will reveal that the SYS_START and SYS_END columns have been automatically set with
timestamp values. Execute the SELECT statement below in a clear SQL Editor.
SELECT * FROM LOANS;
Figure 7: SYS_END time values were automatically set by DB2
The values in the SYS_START column indicate when the row became current. In this case, that’s the timestamp when
the rows were inserted.
The values in the SYS_END column indicate when the row was no longer current. In this scenario, all rows have the
value Dec. 30, 9999 00:00:00.0. This indicates that the data is current, i.e. it has not been updated or deleted.

IBM Software
4.4.2 Updating a System-Period Temporal Table
When rows are updated in a STT, DB2 transparently copies the old versions of the modified rows to the appropriate history table.
Updating a STT is no different than a regular table; hence it does not require use of special syntax from applications or users.
In this example, a book “DB2 WORKS FOR YOU” has now become renewable and the change in status has to be updated in
the LOANS table. Upon executing the update statement, DB2 automatically creates a history of the state change in the history
table, LOANS_HISTORY. Comparing the history table before the transaction and after the transaction will reveal that DB2
transparently recorded the change in the state of the data.
1. Query the LOANS_HISTORY table to see its current contents by executing the statement below in the previously
created SQL Editor. There should be nothing in the table as no data has been modified in the STT.
2. Execute the update command below to set the “DB2 Works For You” to renewable, i.e. set the value of column
RENEWABLE to ‘Y’. Please type the query exactly as indicated below to make sure the proper row is modified.
UPDATE LOANS
SET renewable ='Y '
WHERE title = 'DB2 Works For You ';
3. Inspect the current table (LOANS) to see the changed values. Note that the SYS_START value of the row has been
updated and modified accordingly. It is now set to the time when the update was performed.
Figure 8: Results with recently updated value
Query the LOANS_HISTORY table again to confirm that DB2 has copied the old version of the updated row.

IBM Software
Figure 9: Expiry time to signify the change in state

Note the values of SYS_START and SYS_END. They indicate when that version of the row was current.
Note: Querying historical data, makes it possible to retrieve all previous states of the data and reconstruct the various changes.
4.4.3 Deleting Data from a System-Period Temporal Table
Similar to the update operation, DB2 automatically removes data from the current table while transparently recording the change
of state in the corresponding history table.
1. Suppose all entries for the person with BORROWERID = 25 are to be deleted. The library will purge this information
from their currently borrowed resources within the LOANS table. Execute the DELETE statement below:
DELETE FROM LOANS
WHERE borrowerid = 25;
2. The changes in state are again logged in the history table. Inspecting the LOANS_HISTORY table reveals that all
deleted rows can now be found in it.
Figure 10: Deleted rows were automatically moved to history table
4.4.4 Querying a System-Period Temporal Table
Querying a temporal table does not require any complex programming. The syntax and semantics of basic SELECT statements
can still be used. In this case, you will be querying only the current data in the base table.

IBM Software
Additionally, you can return results for a specific point or period of time. Those results can include current and historical values.
For that purpose, there are three supported period specifications when querying system-period temporal tables.
• FOR SYSTEM_TIME AS OF <value1> : Allows querying of data as of a certain point in time

• FOR SYSTEM_TIME FROM <value1> TO <value2> : Allows querying of data between the two specified points in
time, using the inclusive, exclusive approach (the start time is included in the query, while the end time is not).
• FOR SYSTEM_TIME BETWEEN <value1> AND <value2> : Allows querying of data between the range of
start/end time, using the inclusive, inclusive approach (both ends of the range are included in the query)
4.4.4.1 SYSTEM_TIME AS OF clause
Suppose the library wants to take account of all loan transactions as of a specific point in time. Using temporal data
management, you view the state of the table at the specified time. In our case, as all transactions pertain to the current date, we
will have to specify a particular timestamps as the point in time.
1. To specify a valid timestamp as the point in time, record the SYSTEM_START time specified for the ‘DB2 WORKS FOR
YOU’ row within the LOANS_HISTORY table. Right-click on the record within the Results tab and select copy row.
Figure 11: Copy the row, to retrieve a valid timestamp for the AS OF query
2. Paste the row values into the SQL Editor (press Ctrl + V) to extract the SYSTEM_START timestamp.
3. To search, simply include FOR SYSTEM_TIME AS OF « TIME1 » in the criteria area of a query after the table selection.
Using the criterion, instructs the database to fetch everything adhering to this criterion, including the entries in the
history table.
SELECT * FROM LOANS
FOR SYSTEM_TIME AS OF '2012-01-09 11:08:31 565697'
Paste the recorded timestamp in place of the example shown in here

IBM Software
Figure 12: Copy the row to retrieve a valid timestamp for the AS OF query
It can be seen from the above result set that at the specified point in time:
• The book ‘DB2 Works for You’ had yet to be marked renewable.
• The transactions for BORROWERID=25 were yet to be deleted.
This shows that you can query the state of your data at any point in time, to easily track how the data transforms over time.
This proves to be invaluable during audits.
Note: The time specified within the AS OF clause is exclusive i.e. the query pulls records with SYSTEM_TIME up to the specified
time.
4.4.4.2 SYSTEM_TIME FROM …TO… clause

Suppose the library wants to take account of the loan transaction history for BORROWERID = 25. Using DB2’s temporal data
management, this information is easily available. You can simply include FOR SYSTEM_TIME FROM« TIME1 » TO« TIME2 »
in the criteria area of a query after the table selection.
1. Execute the query below to select from the base table, fetching everything for the current date. Remember that DB2
uses an inclusive-exclusive time period for this clause, hence why we’re specifying “CURRENT DATE + 1 DAY”.
SELECT *
FROM LOANS
FOR SYSTEM_TIME FROM
CURRENT DATE TO CURRENT DATE +1 DAY
WHERE BORROWERID = 25
ORDER BY sys_end;
Figure 13: Query returns all (deleted) loans for BORROWERID= 25.
The result set shows that the records are fetched using both the base and history table. The history table entries end_time has
changed to denote the changes made in the base table. Using the FROM…TO… period specification in the above example,
you can query older versions of data along with the current table data.
The time period specification; BETWEEN…AND… works similarly to the above mentioned FROM… TO…, however, its range of
start/end times uses an inclusive, inclusive approach (i.e. both times are used within the search criteria).
5 Application-Period Temporal Tables

While SYSTEM_TIME is a great way to manage compliance and auditing requirements within a company, there are times when
a company also needs to manage the aspect of time in relation to their business information, such as the "validity periods" of
certain business data. This concerns the real-world time dimension of their business (i.e. business time) as opposed to a

IBM Software
system-generated history of data changes (system time). ATTs allow companies to manage the past, present and future
effective dates for their business data within a single table, using BUSINESS_TIME.
Note: Unlike SYSTEM_TIME, BUSINESS_TIME periods are provided by the user/ application. DB2 does not generate the start/end
times. It only assists in transparently managing the temporal data.
In our library system scenario, when an item is on loan from the library and not overdue – there is no fee for borrowing the item;
however, upon exceeding the due date, a service fee may be incurred. Using an ATT to manage the valid business-time periods
for the loans makes management of the loan system, considerably easy.
5.1 Creating an Application-Period Temporal Table

Unlike system time, business time does not require the use of a history table. The syntax to declare business time periods is
similar to that of the system time periods. Instead of the keyword SYSTEM_TIME, the keyword BUSINESS_TIME is used.
1. To create the LOAN_POLICY table, open (File > Open File…) and execute the script Business_Table.sql in the
/home/db2inst1/Documents/LabScripts/Temporal/ directory.
The first section of the script will create a regular table, and the second portion will alter the table to add the business
time columns, transforming the LOAN_POLICY table into an ATT.
ATTs can also be created in one step with all the required fields specified in the CREATE statement. Here we decided
to break it in two steps to highlight the use of the ALTER statement to convert a regular table into an ATT.
CREATE TABLE LOAN_POLICY (

id INT NOT NULL,
Media varchar (255),
Renewable CHAR(1),
Fee INT
);
ALTER TABLE LOAN_POLICY

ADD bus_start DATE NOT NULL DEFAULT CURRENT DATE
ADD bus_end DATE NOT NULL DEFAULT '9999-12-30'
ADD PERIOD BUSINESS_TIME (bus_start, bus_end)
ADD PRIMARY KEY (id,BUSINESS_TIME WITHOUT OVERLAPS);
Note: THE DEFAULT is not required within the CREATE TABLE statement for an ATT. When using the ALTER statement
during the conversion of an existing table to an ATT, a DEFAULT value has to be specified for the bus_start and bus_end dates.
They are new NON- NULLABLE columns being added to an existing table.
The LOAN_POLICY table will be used to store information about a library’s loan policy with its effective business start and end
dates. The PERIOD BUSINESS_TIME clause instructs DB2 to use the specified columns to track the start/end times for each
row.
The BUSINESS_TIME WITHOUT OVERLAPS option in the primary key definition signifies that rows with the same key do not
have overlapping periods of business time i.e. there can not be two versions of the same loan policy in effect at any given point
in time.

IBM Software
5.2 Temporal Data Management with Business Time

5.2.1 Inserting into an Application-Period Temporal Table
1. Populate the table by opening and executing the insert_resources_bus.sql script found in the following directory:
/home/db2inst1/Documents/LabScripts/Temporal.
2. Query the contents of the LOAN_POLICY by executing:
SELECT * FROM LOAN_POLICY;
Figure 14: Successful execution – newly inserted records with their business times.
If you inspect the INSERT statements, you will notice that, unlike STTs, we provided values for the period business time
columns.
The business time values must be explicitly set as it is a business condition that is justified by the end user. Pay closest attention
to the Video Game entries. Notice that although they share the same primary key, they appear several times in the table. This is
allowed because the business times create different pockets of time in which each one of these entries is valid.
5.2.2 Updating and Querying Application-Period Temporal Tables
When updating an entry, it is important to take into consideration the rows that are affected alongside the time span for which
the update should alter.
1. The library needs to update their policies due to rising operational costs. The fees for all medium need to be increased
by an amount of 5. Execute the following statement:
UPDATE LOAN_POLICY SET fee = fee + 5;
2. Then run the following query to see the changes. You’ll notice that ALL entries were updated.

IBM Software
Figure 15: Successful execution
3. The new FOR PORTION OF BUSINESS_TIME clause provides additional control over updating data linked to a
business time. Using it, the library can restrict an update to rows in a specific business time period.
In the following scenario, the library has noticed, in the 3rd quarter of the year, video game rentals are in higher demand,
especially during between July-August. To adjust for this, they increase the penalty of late returns by another 15 dollars
during this period. Update the LOAN_POLICY table to reflect this change.
Attention: In the code below, please substitute YYYY with the current year (eg: 2012).
UPDATE LOAN_POLICY
FOR PORTION OF BUSINESS_TIME FROM
DATE ('YYYY-6-01')
TO
DATE ('YYYY-6-01') + 3 Months
SET fee = fee + 15
WHERE id = 4;
4. Check the changes by executing the following query:

UPDATED row
NEW row
Figure 16: Changed only portion that fits the period specified.
The above results show that not only did DB2 update the fee for the media record corresponding to the months which fall
between July and August; it also splits the row into two rows to signify the change in policy once the portion of time has past.

IBM Software
The fee for the video game falls back to 55 after the month of August (BUS_END date is exclusive). DB2 adjusts the effects of
the update statement automatically, ensuring that the time dimension of the data remains consistent. This way the user need
only worry about specifying the portion in time where data is to be valid, DB2 manages the changes in state required to update
and maintain the validity periods of the data across its lifespan.
5.2.3 Deleting data for portions of Business Time in an Application-Period Temporal Table
Similar to insertion, data can be deleted for portions of business time. DB2 ensures that the appropriate information from the row
is preserved for the time periods not being affected by the delete statement.
1. Assume CDs are no longer being offered as part of the library program, they were too costly to maintain and were not
efficient. Instead of simply flagging the policy inactive, the library wants to purge the policy from the table. Execute the
following statement to remove the record corresponding to media “CD”.
DELETE FROM LOAN_POLICY
WHERE media = 'CD';
2. Confirm that the loan policy for CDs has been removed.
Since the DELETE statement didn’t have any restrictions on the business period, the statement would have deleted ALL entries
related to CDs if there were many of them. Just like updates, we can restrict the effect of a DELETE to specific periods of
business time.
3. Consider the library will no longer lend out Video Games during the period between May and September to promote
outdoor activity. This period intersects multiple rows and like updates, DB2 will automatically adjust the business time
values of the records to fit the changes.
a. First review the values.
SELECT *
FROM LOAN_POLICY
WHERE ID = 4
ORDER BY bus_start;
Figure 17: Reviewing the existing policies.
b. Delete the Video Game loan policies for the period of May - August. Remember to replace YYYY with the
appropriate year.
DELETE FROM LOAN_POLICY
FOR PORTION OF BUSINESS_TIME FROM
DATE ('YYYY-05-01')
TO

IBM Software
DATE ('YYYY-09-01')
WHERE ID = 4;
c. Check the final result by executing:

SELECT * FROM LOAN_POLICY
WHERE ID = 4
ORDER BY bus_start;
MONTHS
MAY to
AUGUST
DELETED
Figure 18: Final results after the DELETE statement was executed.
The Video Game loan policy for the BUS_START/ BUS_END time of April/June was automatically changed to reflect the delete
statement. The BUS_END time was changed from 2012-06-01 to 2012-05-01. The records for the business period falling
between May and August were deleted entirely.
6 Bitemporal Tables
Bitemporal tables allow you to track and manage both dimensions of time – System as well as Business. Using bitemporal
tables, companies can become a virtual time machine, having access to their data and its state at any point in time – past,
present or future. This gives companies the ability to not only track the history of changes made by transactions against a
business condition such as an insurance policy but also be able to manage the validity periods of those policies.
6.1 Update a Bitemporal table

In this section, we will demonstrate how to create a bitemporal table as well as query a table using both system and business
time.
4. Open and execute the script Bitemporal_Table.sql in Data Studio under the directory
/home/db2inst1/Documents/LabScripts/Temporal. This script will modify the existing LOAN_POLICY table to allow
for system time to be tracked by adding the necessary additional columns, creating the history table and enabling
versioning.
Note: Refer to Section 5.1, Step # 3 to initiate a connection to the database.
5. Business is good for our library, so we need to add new policies and make changes to the existing ones.
Open and execute the script Insert_Bitemporal.sql in Data Studio under the directory
/home/db2inst1/Documents/LabScripts/Temporal/. This script will :
• Add a new loan policy for Blu Ray discs
• Make updates to the Blu Ray policy for the summer months
6. Check the current status of the Blu Ray loan policy by executing:

IBM Software

WHERE ID = 5;
Figure 19: Several entries for BLU_RAY are available

7. Now, check the history table to see what has been updated:
SELECT *
FROM LOAN_POLICY_HISTORY
WHERE ID = 5;
added due to change in bus_start month added due to change in fee policy
Figure 20: Entries in the history table.
The above example illustrates the effects of an update statement on a bitemporal table. The time period changes to the
LOAN_POLICY table are reflected using business time, while system time tracks the changing versions of data in the history
table.
6.2 Querying a Bitemporal Table
The librarian wants to report on all changes made to the ‘Blu-Ray’ loan policies that are effective during the first half of the year.
For that, we need to make use of both system and business time querying capabilities.
1. Execute the following query below. Remember to replace YYYY with the current year.

FOR SYSTEM_TIME FROM CURRENT DATE TO CURRENT DATE + 1 DAYS
FOR BUSINESS_TIME FROM DATE('YYYY-01-01') TO DATE('YYYY-07-01')
WHERE ID = 5;

IBM Software
Figure 21: All current and historical entries
Notice that records were retrieved from both the base table and the history table, but only for those records that were valid
in the first half of the year.
Notice that even though the last record was valid until before 01-Sep, it was valid since 01-Jun, which satisfies the query
criteria of being valid during the business time period specified.
7 Playing with Time
As mentioned in earlier sections, DB2’s temporal data management capabilities allow you to ‘travel in time’. Along with querying
data at any given point in time, there is a new registry setting that allows existing applications to run queries against data from a
certain point in time, without using the ATT and STT SQL syntax we demonstrated before. This creates the illusion of having
transported to a given point in time, either in the past or future.
7.1 Setting the Current Time Registry Variable

Suppose a large set of queries or reports are run against a specific point in time; in the past or future. It would be considerably
convenient to set DB2’s CURRENT TIME to correspond to that point in time, avoiding re-work of queries or other efforts such as
creating views. DB2 helps accomplish this by allowing the use of two special registers; CURRENT TEMPORAL
BUSINESS_TIME and CURRENT TEMPORAL SYSTEM_TIME, to set a database session to a specific point in time.
7.1.1 CURRENT TEMPORAL BUSINESS_TIME
The CURRENT TEMPORAL BUSINESS_TIME special register is used to set business time to a specific value, which will affect
queries and DML operations such as update, delete etc. Setting this register causes DB2 to re-write all queries and operations
using the clause FOR BUSINESS_TIME AS OF <value>.
1. Verify the total number of records within the LOAN_POLICY table for comparison by executing:
SELECT COUNT(*) FROM LOAN_POLICY;
2. Run both statements below at the same time (use your mouse to select both of them and press F5) and see that the
number of rows has changed.
SET CURRENT TEMPORAL BUSINESS_TIME = CURRENT DATE + 3 MONTHS;
SELECT * FROM LOAN_POLICY ORDER BY BUS_START;
Figure 22: Data within LOAN_POLICY is reflected as of 3 months from now

The results show the state of the table and the corresponding validity period of its data, as of 3 months from now. This
allows us to query the table as if we had traveled forward in time by 3 months.
3. To reset the registry value, execute:
SET CURRENT TEMPORAL BUSINESS_TIME = NULL;

IBM Software
7.1.2 CURRENT TEMPORAL SYSTEM_TIME
We will not be going through an example for the special register for system time. The register is set the same way as the
business time register. However, when the CURRENT TEMPORAL SYSTEM_TIME register is set to any value except NULL, no
DML operations can be performed against the table.
Note: You can either set a system time (business time) special register or use the SYSTEM_TIME (BUSINESS_TIME) specific time
periods in SQL statements, but NOT both at the same time
7.2 Finding the Previous Version of a Row

There will be times when quickly finding the previous version of a row will be useful and necessary. There are many ways to
accomplish such a task, some of which are demonstrated below.
7.2.1 Using the History Table

1. Simply search the history table for the latest version of an entry that is being searched for.
SELECT *
WHERE ID = 5
AND sys_end = (SELECT MAX (sys_end)
WHERE ID = 5);
Figure 23: Previous version of the current row.
7.2.2 Using the Base Table

1. Select everything from the base table from the earliest possible DB2 time to the latest possible DB2 time and fetch the
first two rows only. Remember to replace YYYY with the current year.
SELECT *
FROM LOAN_POLICY
FOR SYSTEM_TIME BETWEEN '0001-01-01' AND '9999-12-30'
FOR BUSINESS_TIME AS OF 'YYYY-02-02'
WHERE ID = 5
ORDER BY sys_start DESC
FETCH FIRST 2 ROWS ONLY;

IBM Software
CURRENT VERSION
PREVIOUS VERSION
Figure 24: Previous version of the data, using the base table.
Note: When using Application-Period Temporal Tables, ensure that the record is unique by also specifying business time date (or
the most granular value within the periods defined.)
OPTIONAL EXERCISES
8 Constraints on the History Table for System-Period Temporal Tables

(optional)
A unique key on the base table is typically not reciprocated onto the history table due to the fact that there are certain operations,
such as UPDATE, that would allow for multiple instances of certain rows. Querying the history table may be beneficial and useful
in many situations, as demonstrated above.
1. To define the same unique indexes on a history as on its base table, one or both of the columns of SYSTEM_TIME
period are to be included in the declaration. In the example below, it would be SYS_START or SYS_END, in the
definition of the UNIQUE index. Create an index to check insertion of overlapping system times into the history table
CREATE UNIQUE INDEX IDX_RESOURCE
ON LOANS_HISTORY (id, sys_end);
9 Altering a Table with Versioning Enabled (optional)

The history table is an exact replica of the base table and when the base table definition is altered, the history table will need to
automatically mimic the changes that are performed on the current table.
In the example, the library committee now wishes to know who authorized the lending of each resource, but the current definition
does not capture that information.
In order to achieve this, both the base and the history table definitions must be altered.
9.1 Adding a Column

To add a column, the syntax does not differ from that of normal SQL syntax.
1. Add an APPROVER column of type VARCHAR(255) to the table LOANS.

IBM Software
ALTER TABLE LOANS

ADD COLUMN approver varchar(255);
2. The resulting tables, both LOANS and LOANS_HISTORY now each have an additional column APPROVER. Verify this
by issuing a select query to each table individually from fresh SQL Editors.
Figure 25: The base table with the additional column.
Figure 26: The history table with the same additional column.
9.2 Dropping Objects

One must always take care when dropping objects in a database, whether it is an index, a column or a table, especially when
dropping an object with versioning enabled. The base table and history table are linked together and in this sense, altering the
base table should be reciprocated onto the next.
9.2.1 Dropping a Table
The database administrator wishes to prevent and accidental dropping of the LOANS table.
1. Protect the LOANS table by altering the table as follows:.
Note: The RESTRICT ON DROP attribute may also be added to existing tables using an alter table statement.

IBM Software
ALTER TABLE LOANS_HISTORY ADD RESTRICT ON DROP;

2. Try to drop the LOANS table. Since the tables have versioning enabled, they will act as a single unit, which prevents
one from dropping either table as long as one is protected.
DROP TABLE LOANS;
Figure 27: Drop cannot proceed successfully.

3. In order to drop the protected table, the RESTRICT ON DROP attribute must be dropped or the versioning link must be
severed. Sever the versioning link and drop the LOANS table.
ALTER TABLE LOANS DROP VERSIONING;
DROP TABLE LOANS;
Note: If instead, one removed the attribute RESTRICT ON DROP, when dropping the base table, both the base AND the history
will BOTH be dropped.
Figure 28: Drop is successful after disabling versioning.
9.2.2 Dropping a Column
It is not possible to drop a column from a table with versioning enabled. This is due to the fact that RESTRICT ON DROP cannot
be applied to columns and to protect accidental dropping of columns with adverse effects, DB2 requires the versioning to be
disabled prior to dropping a column.

IBM Software
1. The library no longer allows renewals so the column is not needed anymore. To save some space, the column is asked
to be removed to ensure it’s not used (contrary to what the DBA says, the committee is adamant about altering the
schema).
ALTER TABLE LOAN_POLICY DROP COLUMN renewable;
The column cannot be dropped because the tables act as a single unit and there is no way of explicitly protecting the
column from accidental deletion.
Figure 29: The drop will fail.

2. To actually drop the column, as a good practice – first lock the table, or there may be temporarily some data that is not
correctly propagated through to the history table. Afterwards, break the link and drop the columns necessary then
proceed to reinstate versioning.
3. For simplicity, open and execute the file col_drop.sql from the /home/db2inst1/Documents/LabScripts/Temporal/
folder. It contains all statements necessary to drop the column and restoring the linkage between the base and history
tables.
4. Query the LOAN_POLICY table, the RENEWABLE column has been dropped.
Note: Ensure auto-commit is not on if done in a real environment (for the purpose of this lab, it is fine to have it on). This is due to
the fact that the lock will not be held if auto-commit is on.
10 Summary
With the introduction of System-period Temporal Tables, Application-period Temporal Tables and Bitemporal tables, DB2 offers
a powerful and easy way to take control of time-based data. Using simple yet refined SQL enhancements, DB2 allows database
professionals to efficiently manage temporal data, saving time and effort spent on hard-coding time awareness into applications.
Chasing down data changes is now only a simple query away and management of time dependant business conditions takes a
few keystrokes to implement. Gained from this lab was the knowledge to utilize these features and administer them. All of these
features aim to not only manage time, but to help save time and costs for the end user.
11 Cleanup
1. To clean your environment after completing the exercise, right-click on TEMPORAL database in the Administration
su -
cd /home/db2inst1/Documents/LabScripts/Temporal/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/Temporal/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
Migrating OpenBravo® to DB2® 10

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 About this Lab......................................................................................................................................................................................3
2.1 Environment Setup Requirements...................................................................................................................................3
2.2 Preparing for the lab ........................................................................................................................................................3
2.3 Outline .............................................................................................................................................................................4
3 Creating the DB2 Database ................................................................................................................................................................4
4 Moving Database Objects...................................................................................................................................................................6
4.1 The IBM Data Movement Tool.........................................................................................................................................6
4.1.1 Operation Overview ............................................................................................................................................................................ 6
4.2 Tool Configuration ...........................................................................................................................................................7
4.3 Testing connection to DB2 database...............................................................................................................................9
4.4 Extracting DDL and Data ...............................................................................................................................................10
4.5 Executing the DDL and Importing the Data ...................................................................................................................12
4.5.1 Checking for Errors – DDL Execution............................................................................................................................................... 14
4.5.2 Checking for Errors – Data Loading ................................................................................................................................................. 14
5 Creating Procedural Objects ............................................................................................................................................................17

5.1 Executing PL/SQL code in DB2 9.7...............................................................................................................................17
5.2 Functions .......................................................................................................................................................................20
5.2.1 Recursive function not supported ..................................................................................................................................................... 20
5.3 Views .............................................................................................................................................................................21
5.4 Stored Procedures.........................................................................................................................................................22
5.4.1 VARCHAR2 Length Limit.................................................................................................................................................................. 22
5.4.2 Untyped NULL Values in a SELECT List.......................................................................................................................................... 22
5.4.3 “SELECT * ” and GROUP BY Clause............................................................................................................................................... 23
5.5 Triggers..........................................................................................................................................................................24
6 Enabling your Application Code ......................................................................................................................................................24
6.1 DB2 JDBC Driver & Connection String..........................................................................................................................24
6.1.1 Changing JDBC Driver and Connection String................................................................................................................................. 24
6.1.2 Adding the DB2 JDBC Driver to Classpath....................................................................................................................................... 25
6.2 Testing the Application ..................................................................................................................................................26
7 Summary ............................................................................................................................................................................................27
8 Cleanup...............................................................................................................................................................................................27
IBM Software
1 Introduction
Applications within an organization tend to be aligned with a particular database vendor. As business requirements change and
organizations try to switch vendors to take advantage of lower prices, better technology, or a better partnership, they find
themselves held hostage by their earlier choice. Legacy code that requires extensive rewrite, non-standard practices or
proprietary features make the switch difficult. In addition, the skill set for one product cannot be transferred to another very easily.
DB2 database dramatically lowers the barriers for applications written for Oracle® when enabling them to DB2. This provides
customers the ability to choose a DBMS based on its merits rather than application history. With DB2, you do not need to port an
application anymore. You merely enable the application with minimal changes.
2 About this Lab

This lab demonstrates the ease of enabling your Oracle applications to DB2, thanks to the compatibility features available since
DB2 9.7. These features simplify the task of migrating applications written for other relational database vendors to DB2. To
prove the efficacy of these features, this hands-on lab will guide you through the porting of OpenBravo, a real world web-based
open source Enterprise Resource Planning (ERP) system (www.openbravo.com) that uses Oracle as a backend database.
In a step by step approach, you will use the IBM Data Movement tool to automate several of the steps required for enabling an
application to DB2. Also, we provide a list of workarounds for a small set of PL/SQL features not yet supported in DB2.


User: db2inst1
Password: password
2. Open a terminal window by right-clicking on the Desktop area and choose the “Open in Terminal” item.
IBM Software
Figure 1: Open terminal
2.3 Outline
This lab is divided into the following four sections, as described below:
Section 3 – Create the DB2 database
1. Enable compatibility features for Oracle
2. Issue the CREATE DATABASE command
Section 4 – Move DB schema and data from Oracle database to DB2
1. Extract DDL for the database objects and base data from the Oracle source database
2. Create the database schema (tables, constraints, etc) onto the DB2 database
3. Load data into DB2 database
Section 5 – Create PL/SQL routines in the DB2 database
1. Use PL/SQL support in DB2 to create the Stored Procedures, UDFs and triggers.
2. Explore some typical modifications to accommodate unsupported PL/SQL features.
Section 6 – Enable your application code
1. Modify your application to connect to DB2.
2. Test the application and make necessary adjustments.
You will be using IBM Data Movement Tool and DB2 Command Line Processor (CLP) to carry out the migration tasks.
3 Creating the DB2 Database
IBM Software
Prior to creating the database, the compatibility features for DB2 need to be enabled. These features reduce the complexity and
time required to enable applications from different vendors. To make the DB2 environment more compatible with the Oracle
database management system environment, you can set the DB2_COMPATIBILITY_VECTOR registry variable within DB2.
To enable all of the supported Oracle compatibility features, set the registry variable to the value ORA; using a terminal window,
enter the following commands:
1. Enable all compatibility features
db2set DB2_COMPATIBILITY_VECTOR=ORA
2. Verify the new setting; db2set displays the current compatibility vector setting for the instance.
db2set
3. Stop the DB2 server
db2stop force
4. Start the DB2 server
db2start
5. Create the database with all compatibility features for Oracle enabled. Issue the command below.
db2 create database OB2 on /db2fs pagesize 32 K
Attention: The PAGESIZE option sets the default page size to 32 KB that will be used when creating buffer
pools and table spaces. This is done to accommodate Oracle’s larger row length.
6. After database creation, check that the compatibility features are enabled for your database by listing the database
configuration parameters.
db2 get db cfg for OB2 | grep compat
Figure 2: Compatibility features for OB2 database
7. Next step is to set the auto-revalidation parameter for your database to DEFERRED_FORCE. This way you can deploy
objects out of the dependency order. It is also recommended to adjust the rounding behavior to match that of Oracle.
db2 connect to ob2
db2 update db cfg using AUTO_REVAL DEFERRED_FORCE
db2 update db cfg using DECFLT_ROUNDING ROUND_HALF_UP
db2 terminate
IBM Software
4 Moving Database Objects
In this section, you will use the IBM Data Movement tool (IDMT) to move your database objects and data from an Oracle
database to a target DB2 database. IDMT is a very simple and powerful tool designed to easily move data and database objects
from various sources. In this section we focus on the non procedural objects like tables, sequences and views.
4.1 The IBM Data Movement Tool

The IBM Data Movement tool is designed to help migrating from different databases vendors to DB2 for Linux, UNIX and
Windows and DB2 on z/OS v8 or later. The tool helps enabling applications from various DBMS to run on DB2 as is, with very
little changes. Currently the tool supports migration from the following databases vendors:
• Oracle
• Microsoft SQL Server
• Microsoft Access
• Sybase Adaptive Server Enterprise
• MySQL
• PostgreSQL
• Ingres
Requirements:
• Java 1.5 or later on your target server
• JDBC drivers for your source database and DB2
4.1.1 Operation Overview

Here we provide an overview of what can be done using this tool. During this lab we will walk you through each one of these
steps.
1. Configuration
a. Set up the connection parameters for source and target databases.
2. DDL and Data Extraction
a. Extract the DDL statements for the objects in the source schema.
b. Extract the table data and store it in text files for later import into the target DB2 database.
c. Automatic incompatible data type mapping to the most appropriate DB2 data type.
Attention: Extracted DDL statements for PL/SQL objects are not converted to DB2’s SQL PL syntax.
3. Database Objects Creation and Data Loading – There are three different ways of deploying the extracted objects in
DB2.
Deciding which option to choose to deploy data is based upon the data and objects movement requirements. You can
utilize the scripts generated by IDMT during the extraction process or use interactive deploy.
IBM Software
• Executing scripts generated by IDMT is useful for all non-procedural objects (tables, constraints, indexes, sequences,
etc.) and loading data.
o Database Objects Creation and Data Loading – The “db2gen” script executes the DDL statements against
the target DB2 database. This script can also be used for data load or a separate script can be generated for
that purpose. More detail will follow in the following sub-sections.
o PL/SQL Objects Creation – “db2plsql_functions.db2”, “db2plsql_procedures.db2”, “db2plsql_triggers.db2” and
others create the procedural objects for the database.
• Using Interactive Deployment option is a good choice when you are also deploying PL/SQL objects such as triggers,
functions, procedures, and PL/SQL packages.
• Deploy DDL/DATA using command line script db2gen.
For the purpose of this lab, we will demonstrate two of the above mentioned options. The db2gen script will be used to
deploy non-procedural objects and data with the Deploy DDL/Data button and the interactive deploy feature will be utilized
for procedural objects such as functions, procedures and triggers.
4.2 Tool Configuration

To use IDMT for moving the database objects and data from Oracle DB2, it needs to be configured to connect to both databases.
Attention: Steps marked with a ■ in the following sections cannot be executed. These steps require an Oracle
server that is not provided as part of this environment. Instead, the instructions will show you the results of these
steps.
1. Prior to initializing IDMT, the database user responsible for deploying database objects and data requires the right
permissions. DBADMIN access is required for the user bravousr, to successfully migrate objects to DB2, using IDMT.
To do so, execute the command below in the command line terminal.
db2 connect to ob2
db2 "GRANT DBADM on DATABASE to USER BRAVOUSR"
2. Go to the directory where IBM Data Movement Tool is installed. If you list the files in this directory you will notice the
tool files (IBMDataMovementTool.*) and Oracle’s JDBC driver files are present. This is all you need to get started.
cd /home/db2inst1/Documents/LabScripts/EnablingOpenBravo/IBMDataMovementTool
Figure 3: Files within the IBMDataMovementTool folder
IBM Software
3. Run the tool. The GUI screen will open where you can specify the details about the source and destination databases.
./IBMDataMovementTool.sh &
4. You will have to provide the following values:
Source – Oracle Database Target DB2 Database
Vendor Oracle DB2 LUW with Compatibility Mode
Any value other than an Oracle server is
Server Name localhost
not provided with the lab
Port Number 1521 50001
Database Name OB OB2

User ID bravousr bravousr
Password password password
The JDBC drivers are located at
Oracle will require 3 files: ojdbc14.jar,
<DB2 home>/java
xdb.jar and xmlparserv2.jar (the last 2
files are only necessary if your (Eg: /opt/ibm/db2/V10.1/java) DB2 will
JDBC Drivers database contains XML data). require 2 files: db2jcc4.jar and
db2jcc_license_cu.jar.
Click the button besides the text
field to select the JAR files Click the button besides the text
field to select the JAR files.
Figure 4: Locating the JDBC drivers for each database vendor
Use the default value provided.

Output Directory It can be changed to any directory when extracting. Please be advised that the
directory has room for all the extracted database objects and data
Check both “DDL” and “Data Movement” options since we want to migrate both
Migration
database objects and data.
IBM Software
After setting up the tool for extraction, your settings should resemble the screenshot shown below.
Figure 5: IBM Extract screen
4.3 Testing connection to DB2 database

1. To test your DB2 connection parameters, click on “Connect to DB2”. If the connection is successful the tool shows the
instance name and the settings for some of the compatibility features.
Figure 6: DB2 database with compatibility features enabled
2. ■ To retrieve the list of source schemas, you should click the “Connect to ORACLE” button. You will not see details as
shown in Figure 5, since there is no Oracle server available. Figure 7 is an example of what you would see when a
connection is successfully established.
a. A list with all available schemas is displayed
IBM Software
b. The “Extract DDL/Data” button is now enabled
Note: The steps marked with a ■ cannot be executed. The steps and corresponding images are outlined for
learning purposes
Figure 7: Selection of source schemas
3. ■ An option is provided to select the schemas intended for migration to DB2. All schemas can be moved or as in the
case for this lab, a particular schema can be chosen for migration to DB2.
4.4 Extracting DDL and Data

1. ■ After connecting to the Oracle database, click on “Extract DDL and Data” button to start the extraction. Expected
output is shown below.
Figure 8: Extract DDL/ Data
2. ■ After clicking the “Extract DDL and Data” button, the GUI screen switches to the “View File” tab, where you can see
the progress of the extraction.
IBM Software
Figure 9: Extraction in progress

The GUI will show the success message once the extraction is completed.
Figure 9 Extraction completed
3. As result, several files are created in the specified Output Directory.

a. *.SQL: contain DDL statements created using DB2 syntax. This includes the tables DDL and related objects
(indexes, constraints, etc), and the LOAD commands for importing the data.
b. *.DB2: contain the PL/SQL code for the various objects extracted from the source database.
c. *.SH: scripts that you will use to deploy the objects into the target DB2 database.
Some directories are created as well.
d. DATA: contains the text files with data extracted from each table of the source database.
e. DUMP: it will be used during the data loading phase to store rows that could not be imported into the DB2 database.
f. MSG: it will be used during the data loading phase to store the messages produced by DB2’s LOAD utility.
4. You can click on the View Script/Output button to check the contents of generated scripts, DDL, data or the output log
file. Then, go back to Extract / Deploy tab after checking the output.
IBM Software
Figure 10: Open Script/Output to view
4.5 Executing the DDL and Importing the Data
As mentioned in the earlier section, there are three different ways of executing the DDL and deploying the extracted objects in
DB2. All three will be utilized in the following sections.
• Click the Deploy DDL/DATA button from the GUI screen
• Go to the Interactive Deploy tab and deploy objects in step-by-step process
• Deploy DDL/DATA using command line script db2gen
1. Using the first option to deploy non-procedural objects using the script generated by IDMT, we will run the db2gen
script by clicking on the Deploy DDL/Data button to deploy objects.
Figure 11: Confirm running deployment script
2. The following pop-up will appear, asking to run the db2gen.sh script. This script executes the previously extracted DDL
statements from the *.sql files to create sequences, tables and associated objects, such as indexes, primary keys,
constraints, etc. It will also import the extracted data using DB2’s LOAD. Click on this YES to create the database
objects.
IBM Software
Figure 12: Confirm running deployment script
3. The deployment results can be viewed in the View file tab. The operation is complete after the foreign keys are
deployed. Please note that this operation might take some minutes. Note that the progress animation ( ) will
disappear as soon as the operation is complete.
Figure 13: Results of deployment of extracted DDLs
The script creates the database schema by running the DDL statements listed below. It also imports the data from the
text files into the DB2 database using the LOAD utility.
• db2tsbp.sql – to create the buffer pools and table spaces
• db2tables.sql – to create the TABLES
• db2default.sql – to create the DEFAULT constraints
• db2sequences.sql – to create the SEQUENCES.
• db2load.sql – to load the DATA extracted from the Oracle database.
• db2check.sql – to create the CHECK constraints
• db2cons.sql – to create PRIMARY KEYS, INDEXES and UNIQUE INDEXES
IBM Software
• db2uniq.sql – to create the UNIQUE constraints

• db2fkeys.sql – to create all foreign keys
4.5.1 Checking for Errors – DDL Execution

The next step is to check for errors. There are two log files that you need to analyze: “db2gen.log” with the output of DDL
execution, and “db2gen_LOAD.log” with the output of the LOAD utility.
1. Open another terminal, by right-clicking on the desktop. Then navigate to the migr folder containing all the extracted
information from the Oracle database.
cd /home/db2inst1/Documents/LabScripts/EnablingOpenBravo/migr
2. Execute the command below to view the contents of “db2gen.log”:

gedit db2gen.log &
To help with this task, we have included a small program to parse the output and give you a list of errors and warnings
generated. You can run this using the checkerrors.sh script located at “opt/IBMDataMovementTool”
cd ../IBMDataMovementTool/
./checkerrors.sh DDL
/home/db2inst1/Documents/LabScripts/EnablingOpenBravo/migr/db2gen.log
Figure 14: db2gen's errors and warnings

The errors/warnings generated by the DDL deployment within the db2gen script, in our case, do not require special
attention and the database schema was successfully created. In the next section, we will verify the errors associated
with loading data.
4.5.2 Checking for Errors – Data Loading

Now we will look for errors in the “db2gen_LOAD.log” file. It contains the output of the data loading phase.
For each execution of the LOAD command you will get an output like the one below. Below, the result of a successful execution
is shown, where the LOAD utility reads 16 rows from the text file, then loads and commits all of them.
IBM Software

To find out how to resolve load errors follow the following steps.
1. Open the db2gen_LOAD.log file and go to line 4373. You will find the LOAD command to import data into the
AD_USER table.
cd ../migr/
gedit db2gen_LOAD.log &
2. From the output (lines 4375-4380) you can see that some of the rows were rejected by the LOAD utility.
3. The rows were for table AD_USER. To verify the error and rows rejected open the message file and dump file
generated by the load command.
gedit msg/bravouser_ad_user.txt &
gedit dump/bravouser_ad_user.txt.* &
Figure 15: Load errors for table BRAVO_AD_USER

The error shown in the above mentioned files is caused by a UNIQUE constraint issue with the USERNAME column in
the AD_USER table.
Oracle allows multiple NULL values to be inserted in a column that is part of a UNIQUE constraint. In DB2 UNIQUE
constraints are not defined over ‘nullable’ columns. The IBM Data Movement Tool made the USERNAME column NOT
NULL in order to create the UNIQUE constraint.
To fix this error, we will remove the UNIQUE constraint from our schema.
4. Close the files open within the text editor – gedit.
IBM Software
5. Remove (or comment out) the UNIQUE constraint for DB2. Open the “db2uniq.sql” file within the migr directory, and
look for the UK1_AD_USER constraint (around line 129). Comment out the ALTER TABLE statement. Save your
changes.
gedit db2uniq.sql &
Figure 16: Comment out UK1 _AD_USER

6. Change the column definition for the table AD_USER to nullable.
Open the “db2tables.sql” file and look for the CREATE TABLE clause for the AD_USER table (around line 2535).
Remove the NOT NULL clause for the USERNAME column. Save your changes.
gedit db2tables.sql &
Figure 17: Change the username column definition

7. To recreate the table and its constraints, you drop and rerun the DDL scripts, individually, from the command line or
resolve them through the interactive deploy feature. To reduce effort, we will rerun the earlier db2gen script. This results
in the fastest way to recreate the required table and related objects. This time, you will get several errors stating objects
are already defined, except for the AD_USER table as it has been dropped. The table will generate correctly since you
modified the “db2tables.sql” file.
db2 connect to ob2
db2 drop table bravousr.ad_user
db2 terminate
./db2gen.sh
8. Navigate to IBM Data Movement Tool’s main directory.
cd ../IBMDataMovementTool/
9. On checking the output of the data loading operation. This time there should be no errors.
./checkerrors.sh db2load
/home/db2inst1/Documents/LabScripts/EnablingOpenBravo/migr/db2gen_LOAD.log
IBM Software
Figure 18: No errors detected by the ‘checkerrors’ script
5 Creating Procedural Objects

In this section, you will explore the PL/SQL support in DB2 to create Openbravo’s user defined functions and stored procedures
coded in PL/SQL.
5.1 Executing PL/SQL code in DB2 9.7

Within DB2, you can compile and execute PL/SQL code in any of the interfaces where SQL PL is supported. It does not have to
convert to DB2 SQL/PL.
It is important to note that even though DB2 has support for PL/SQL code, you can not mix PL/SQL and DB2’s SQL PL syntax in
the same statement. Separate statements using both SQL PL and PL/SQL syntax can be used inside the same session.
Here is an example of a script running both PL/SQL and SQL PL code:
#Executing a PL/SQL anonymous block

DECLARE
current_date DATE := SYSDATE;
BEGIN
dbms_output.put_line( current_date );
END
@
#Executing DB2 SQL PL code

CREATE PROCEDURE up_salary(IN rating SMALLINT)
LANGUAGE SQL
BEGIN
IF (rating = 1)
THEN UPDATE employee SET salary=salary*1.2
END IF;
END
@
IBM Software
In this section we start creating Openbravo’s procedural objects in DB2. We will utilize the interactive deploy feature of the IBM
Data Movement tool, for deploying these procedural objects. Interactive deploy is used to deploy all objects within the database.
In our case, we deployed all non-procedural objects using the dbgen.sh script,
1. Click on the Interactive Deploy tab on the GUI.
2. Click on the folder icon to choose the source directory where all the objects are to be retrieved from. In our case, it is
/home/db2inst1/Documents/LabScripts/EnablingOpenBravo/migr
Folder Icon
Figure 19: Open the migration directory
Figure 20: Interactive Deploy tab displaying the db objects tree
The database object tree will become populated with all the database objects.
3. As the deployment process begins, you will notice that the objects deployed successfully are marked with a check
mark sign and failed objects are marked with a red stop icon.
4. Now, we will deploy all objects in the tree to the database. This includes functions, views, triggers and procedures.
The objects already present in the database remain unchanged.
IBM Software
a. To do this, go to File > Execute all statements or click on the corresponding button from the GUI, as
shown below.
O meu
Figure 21: Interactive Deployment of all db objects
5. At the end of the deployment, you can see the summary of the deployed objects in a table on the bottom right of the
panel.
Attention: Prior to investigating the errors, re-deploy all objects to ensure that some objects which might
have failed due to dependency issues get correctly deployed.
a. To view error details of the failing objects, you can right-click object in the results pane and select ‘Get
detailed error message’.
IBM Software
Figure 22: Errors resulting in deploying all db objects
Figure 23: Displaying errors details
5.2 Functions
In this section, we discuss how to resolve issues with functions outlined by the deployment summary in the previous section
Attention: When re-deploying an object. The above deployment summary is lost. To view the error message again for the object,
right-click on the object, choose “deploy selected objects to db2”. The above window pane would refresh with the selected object’s
deployment status.
5.2.1 Recursive function not supported

Function: BOM_PRICESTD
Error: SQL0727N
An error occurred during implicit system action type "3".Information
returned for the error includes SQLCODE "-20481", SQLSTATE "429C3"and message tokens
"BRAVOUSR.BOM_PRICESTD". LINE NUMBER=44. SQLSTATE=56098
Reason:
DB2 9.7 does not support the use of recursive functions.
Solution:
You will need to replace the recursive function call with a dynamic SQL statement that invokes the same function, thus
simulating the behavior of the recursive call.
1. Click on the object BOM_PRICESTD in the objects tree pane on the left, the display pane will show the source code for
the function. Declare a new variable called “v_Stmt” to store the value of the dynamic statement in the declaration
section (around line 9).
v_Stmt VARCHAR2(512);
2. Comment out the recursive function call (line 30).
IBM Software
-- v_ProductPrice:=BOM_PriceStd(CUR_BOM.M_ProductBOM_ID,
PriceList_Version_ID);
3. Just before the commented code, add the following to execute your dynamic statement. Notice that the result of the
statement is stored INTO v_ProductPrice and 2 parameters are provided, just like in the original recursive function call.
v_Stmt := 'SET ? = BOM_PriceStd(:1, :2)';
? is the parameter marker specifying the :1 and :2 are the

variable receiving the result. This is set to parameters for this
receive the function result in the original dynamic statement.
code.
v_Stmt := 'SET ? = BOM_PriceStd(:1, :2)';

EXECUTE IMMEDIATE v_Stmt INTO v_ProductPrice USING
CUR_BOM.M_ProductBOM_ID, PriceList_Version_ID;
4. After making the changes above, re-deploy the function by right-clicking on BOM_PRICESTD and selecting Deploy
selected objects to DB2. You will see the following result.
Figure 24: Displaying errors details
5.3 Views
In our case there are no failing views. If views do fail, it might due to the fact that they are dependant on the functions that have
not been successfully created. These views are marked invalid as the functions they depend on were not created at the time of
deployment. On re-deploying the views DB2 tries to revalidate the functions.
• Select all failing views by pressing down on CTRL while you select them.
• Then right-click on one of the selected view and click on Deploy selected Objects to DB2 or alternatively click on the
button at the top menu bar
Deploy Selected
Objects to DB2
Figure 25: Deploy Selected Objects

• The revalidation would be successful since issues with the functions would be resolved and you can use the views
without any problems.
IBM Software
5.4 Stored Procedures

In this section we will discuss how to resolve failing stored procedures. The initial summary of deployment shows that 3 stored
procedures have failed. In the next subsections, we will show you how you can fix them.
5.4.1 VARCHAR2 Length Limit

Stored Procedure: AD_TABLE_IMPORT
Error: SQL0604N The length, precision, or scale attribute for column, distinct type,
structured type, array type, attribute of structured type, routine, cast target
type, type mapping, or global variable "VARCHAR2(32767)" is not valid. LINE
NUMBER=59. SQLSTATE=42611
Reason:
In Oracle, VARCHAR2 data type has a maximum size of 32767. DB2 internally maps the VARCHAR2 data type to the
VARCHAR data type. The VARCHAR data type in DB2 has a maximum length of 32672.
Solution:
Change the length to 32672.
1. Click on the AD_TABLE_IMPORT stored procedure. Change the VARCHAR2 length to 32672 on line 59
v_varchar2 VARCHAR2(32672) ;
2. Re-deploy the object by right-clicking on the stored procedure in the object tree and selecting “Deploy selected
objects in DB2”
5.4.2 Untyped NULL Values in a SELECT List

Stored Procedure: M_RAPPEL_INVOICE_CREATE
Error: SQL0789N
The data type for parameter or variable "RAPPELINVOICED" is not supported
in the SQL routine. LINE NUMBER=237. SQLSTATE=429BB
Reason:
RAPPELINVOICED is a result column of a SELECT statement that is a result of an untyped NULL value expression. DB2 can
not resolve the expression type of the NULL value from the SELECT list.
Solution:
Use a cast expression to the return type for the expression in question.
1. Click on M_RAPPEL_INVOICE_CREATE under Procedures in the object tree
2. Cast the NULL expression to integer. On line 251
IBM Software
Figure 26: Cast NULL as INTEGER

3. After making the change, re-deploy the function by right-clicking on the object and selecting “Deploy selected objects
in DB2”. You will see that the stored procedure is deployed successfully.
5.4.3 “SELECT * ” and GROUP BY Clause

Stored Procedure: T_REPLENISH_CREATE
Error: SQL0119N An expression starting with "AD_CLIENT_ID" specified in a SELECT
clause, HAVING clause, or ORDER BY clause is not specified in the GROUP BY clause
or it is in a SELECT clause, HAVING clause, or ORDER BY clause with a column
function and no GROUP BY clause is specified. LINE NUMBER=54. SQLSTATE=42803
Reason:
When using the GROUP BY clause, DB2 requires any simple column expression in the SELECT list to appear in the GROUP
BY clause. Since this is a “SELECT * FROM” statement, all columns should be declared in the GROUP BY to make it valid, but
this would change the logic of the statement.
Solution:
Instead of adding columns to the GROUP BY clause, add any one of the columns from the GROUP BY list. This will still work
because the SELECT statement is part of a EXISTS clause, i.e. the result values are not used anyway.
1. Click on T_REPLENISH_CREATE. In the source code window pane, replace “*” for ANY of the columns from the
GROUP BY list. Line 57-65
AND EXISTS
(SELECT pp.M_Product_ID Replace * with a column from GROUP BY
FROM M_Product_PO pp
WHERE M_Product_PO.M_Product_ID=pp.M_Product_ID
AND M_Product_PO.C_BPartner_ID=pp.C_BPartner_ID
GROUP BY pp.M_Product_ID,
pp.C_BPartner_ID
HAVING COUNT(*)=1
)
IBM Software
2. Re-deploy the object by right-clicking on the stored procedure in the object tree and selecting “Deploy selected
objects in DB2”
5.5 Triggers
Now we move on to enable the PL/SQL triggers to DB2 database. You will find that all triggers get deployed. Since DB2 9.7 fp5,
DB2 supports combined action triggers.
6 Enabling your Application Code
At this point you have all your database objects created in DB2 and ready to be used by your application. The next step is to
change your application in order to access the DB2 server.
This part of the process varies depending on the programming language and which database interface you use to communicate
with the database server.
Openbravo ERP is a web-based Java application that uses JDBC as the API to access the database server. Since JDBC is a
standardized, database-agnostic1 API, modifying the application to access the DB2 server is very straightforward. The only
necessary changes are:
• Modify the code so that the application loads the DB2 JDBC driver instead of the Oracle JDBC driver;
• Change the connection string to the format accepted by the DB2 driver;
• Include the DB2 JDBC driver to the set of libraries the application uses.
The rest of the application’s Java code should remain unchanged and you can proceed to testing your system with DB2.
6.1 DB2 JDBC Driver & Connection String
You will be using the Apache Tomcat server (installed at “/opt/tomcat”) to host Openbravo ERP. The Openbravo ERP
application has already been conveniently deployed to Tomcat at “/opt/tomcat/webapps/openbravo”.
6.1.1 Changing JDBC Driver and Connection String
Fortunately, Openbravo ERP uses properties files to store the JDBC driver name and the connection string used to connect to
the database, you only need to replace these values in the appropriate files, avoiding recompiling the application. You will need
to edit 2 files: “dbCon5.xml” and “XmlPool.xml”.
The name of the DB2 JDBC driver type 4 is “com.ibm.db2.jcc.DB2Driver”
The JDBC connection string for the DB2 JDBC driver has the following format “jdbc:db2://<server>:<port>/<databaseAlias>”
1. Switch to directory “/opt/tomcat/webapps/openbravo/WEB-INF”.
cd /opt/tomcat/webapps/openbravo/WEB-INF
2. Open file “XmlPool.xml” for editing.
gedit XmlPool.xml &
3. Edit the parameters below with the following values:
1
Database-agnostic means that the same code written using the API classes and methods can be used to access difference database vendors.
IBM Software
• dbDriver : com.ibm.db2.jcc.DB2Driver
• dbServer: jdbc:db2://localhost:50001/ob2
Figure 27: File XmlPool.xml after edition

4. Save file XmlPool.xml
5. Open file “dbCon5.xml” for editing.
gedit dbCon5.xml &
6. Edit the attributes below with the following values:
• driver : com.ibm.db2.jcc.DB2Driver
• URL : jdbc:db2://localhost:50001/ob2:user=bravousr; password=password;
Figure 28: File dbCon5.xml after edition
7. Save file dbCon5.xml
6.1.2 Adding the DB2 JDBC Driver to Classpath

Openbravo ERP is now configured to access the DB2 server but you still need to add the DB2 JDBC driver JAR file to the
application’s classpath. This way the application can load the driver’s classes at runtime.
JAR file containing the DB2 JDBC driver:
• <DB2_install_dir>\java\db2jcc.jar (supports JDBC 3.0 and earlier)
• <DB2_install_dir>\java\db2jcc4.jar (supports JDBC 4.0 and later functions, as well as JDBC 3.0 and earlier functions)
1. Copy the DB2 JDBC driver JAR file along with its license JAR file to the WEB-INF\lib directory of the application. Tomcat will
automatically add any JAR files in this directory to the application’s classpath at execution time.
cp /opt/ibm/db2/V10.1/java/db2jcc.jar /opt/tomcat/webapps/openbravo/WEB-INF/lib
IBM Software
cp /opt/ibm/db2/V10.1/java/db2jcc_license_cu.jar
/opt/tomcat/webapps/openbravo/WEB-INF/lib
6.2 Testing the Application
You have everything in place now, so let’s start testing the application.
1. Open a new terminal window by right-clicking on your desktop and selecting “Open Terminal”.
2. Switch to root user. The password is “password”.
su -
3. Start the tomcat server.
/opt/tomcat/bin/startup.sh
Figure 29: Starting Tomcat server

4. Open Firefox browser. Menu “Computer Firefox”.
5. Click the Openbravo link located at the toolbar at the top; or alternatively, enter this URL at the address
bar on Firefox: http://localhost:8080/openbravo/ The login screen will be loaded. It might take a while to load the page at first
because the application is still initializing.
6. Login using the following credential (both username and password are case-sensitive):
• Username: Openbravo
• Password: openbravo
IBM Software
Figure 30: Openbravo ERP login page

7. You are now successfully logged into the system and can use the menu on the left hand side to navigate through the
application.
Figure 31: Openbravo ERP main screen

7 Summary
With the information provided in this lab you should be able to enable most of your Oracle applications to DB2. The next steps
involve executing your application’s test plans to make sure all the functionalities are working properly against DB2.
As you saw during this lab, DB2 10 introduces several enhancements that make the enablement process much smoother and
straightforward, even for those with little or no knowledge of DB2. In cases where your application relies on some Oracle
features without a corresponding counterpart built within DB2, you will need to develop a workaround, for example to create
UDFs or procedures that mimic the missing functionality. Although the Java code itself does not need to be modified, you might
still find it necessary to make changes to the SQL statements that your application executes.
In case your application uses other interfaces such as ADO .NET or ODBC, please refer to the DB2 Information Center; section
“Database Application Development” for more information on how to develop using a particular programming language/interface
for DB2.
8 Cleanup
If you want to run this lab again, execute the commands below to drop all newly created database objects and reset the lab
environment:
1. To clean your environment after completing the exercise, execute the command below. Use “password” as password.
IBM Software
su –
cd /home/db2inst1/Documents/LabScripts/EnablingOpenBravo/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/ EnablingOpenBravo/setup
./config.sh
IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.
IBM Software
DB2® Security
Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
3 About this Lab......................................................................................................................................................................................3
5 Basic Setup ..........................................................................................................................................................................................3
6 Authentication......................................................................................................................................................................................4
6.1 Where Does Authentication Take Place? ........................................................................................................................................................... 4
6.2 Specifying Authentication Type........................................................................................................................................................................... 5
7 Authorization......................................................................................................................................................................................11
7.1 Authorities ......................................................................................................................................................................................................... 11
7.1.1 System-level Authorities ................................................................................................................................................................... 11
7.1.2 Database-level Authorities................................................................................................................................................................ 12
7.2 Privileges .......................................................................................................................................................................................................... 12
7.3 Granting and Revoking Authorities and Privileges ........................................................................................................................................... 13
7.3.1 Adding a new user ............................................................................................................................................................................ 13
7.3.2 Granting Database Privileges ........................................................................................................................................................... 14
7.3.3 Object-level Authorities..................................................................................................................................................................... 16
7.4 Using Views to Define Granular Privileges ....................................................................................................................................................... 19
7.4.1 Creating a View ................................................................................................................................................................................ 20
8 Roles ...................................................................................................................................................................................................23
8.1 Creating Roles .................................................................................................................................................................................................. 23
9 Summary ............................................................................................................................................................................................27
10 Cleanup...............................................................................................................................................................................................28
DB2 Security
IBM Software
1 Introduction
Database security is of utmost importance today. Your database may allow customers to purchase products over the Internet, or
it may contain historical data used to predict business trends. In order to protect your data, it is crucial to control who has access
to your database and limit the operations that the user can perform on the data.
A database security plan should define:

• Who is allowed access to the instance and/or database
• Where and how a user's password will be verified
• The authority level that a user is granted
• The commands that a user is allowed to run
• The data that a user is allowed to read and/or alter
• The database objects a user is allowed to create, alter, and/or drop
2 Suggested Reading
DB2 Security and Compliance Solutions for Linux, UNIX, and Windows (Redbook)
http://www.redbooks.ibm.com/abstracts/sg247555.html
DB2 Best Practices: IBM Data Server Security

http://www.ibm.com/developerworks/data/bestpractices/security/
3 About this Lab

In this lab, you will learn how to control access to the instance, how to control access to the database itself, and finally how to
control access to the data and data objects within the database.
• Grant and revoke authorities to/from users

• Grant and revoke privileges to/from users
• Create roles
• Grant and revoke roles to/from users

5 Basic Setup
2. At the login prompt, log in with the following credentials:
DB2 Security
IBM Software
3. Open a terminal window by right-clicking on the Desktop and choosing the Open in Terminal item:
Figure 1 - Open a new Terminal window
4. Start the Database Manager by issuing the following command:
db2start
6 Authentication
When you first attempt to access an instance or database, the authentication system will try to determine if you are who you say
you are. By default, DB2 works closely with the authentication mechanism of the underlying operating system to verify your user
IDs and passwords. DB2 can also use third-party authentication facilities such as Kerberos or LDAP server to authenticate users.
By using an external authentication system, DB2 does not need to store a redundant set of passwords and sensitive credentials.
This minimizes security vulnerabilities and hacker attacks.
6.1 Where Does Authentication Take Place?
Authentication type defines where and how authentication will take place. This is specified by the AUTHENTICATION
parameter in the database manager configuration file on the server. Thus all the databases in an instance will have the same
authentication type. On the client, the authentication type is specified when a remote database is cataloged.
Authentication Type Description

SERVER All authentications take place at the server. When you connect to a database, you will have to
include your user ID and password. This information will then be verified against the credentials
at the server’s operating system.
SERVER_ENCRYPT This is similar to SERVER authentication type where authentication occurs at the server, but the
password is encrypted by DB2 at the client before it is sent to the server for authentication.
CLIENT Authentication occurs at the client’s operating system.
DB2 Security
IBM Software
KERBEROS Authentication occurs at the server and is handled by a Kerberos server. The KERBEROS
authentication type is available if both the DB2 server and client operating systems support
Kerberos. The Kerberos security protocol uses conventional cryptography to create a shared
secret key which becomes the credentials used to verify the identity of the user. This eliminates
the need to pass a user ID and password across the network.
KRB_SERVER_ENCRYPT This authentication type is the same as KEBREOS, except it will use SERVER_ENCRYPT if the
client does not support Kerberos security system. If none of these options are available, the
client will receive a connection error and will not be able to connect.
DATA_ENCRYPT Authentication occurs at the server and its behavior is similar to SERVER_ENCRYPT. In this
type of authentication, not only is the password encrypted, but also all user data is encrypted
during transmission between the client and the server.
DATA_ENCRYPT_CMP This type of authentication is identical to DATA_ENCRYPT. However, this setting provides
compatibility to those clients who do not support DATA_ENCRYPT authentication and will
instead connect using SERVER_ENCRYPT so user data will not be encrypted.
GSSPLUGIN Authentication occurs at the server using an external GSS-API plug-in. If the client’s
authentication type is not specified, the server will send a list of server-supported plug-ins to the
client. These plug-ins are listed in the SRVCON_GSSPLUGIN_LIST database manager
configuration parameter. The client then selects the first plug-in found in the client plug-in
directory from the list. If the client does not support any plug-in in the list, the client is
authenticated using the KERBEROS authentication method.
GSS_SERVER_ENCRYPT Authentication occurs at the server using either the GSSPLUGIN or the SERVER_ENCRYPT
authentication method. Authentication uses a GSS-API plug-in and if the client does not support
any of the plug-ins found in the server-supported plug-ins list, the client is authenticated using
KERBEROS. If the client does not support the Kerberos security protocol, the client is
authenticated using the SERVER_ENCRYPT authentication method.
6.2 Specifying Authentication Type
In this section, you will experience how authentication is easily managed through Data Studio.
1. Double-click the IBM Data Studio icon on the Desktop.
Figure 2 - IBM Data Studio icon
2. Click OK to accept the default workspace.
DB2 Security
IBM Software
Figure 3 - Workspace Launcher
3. Locate the Administration Explorer view. Expand All Databases > localhost > db2inst1. Right-click on the SECLAB
database and select Connect.
Figure 4 – Connect to SECLAB database
4. Login with the following credentials:

• User: db2inst1
5. After a connection has been established, right click on DB2INST1 and select Configure.
DB2 Security
IBM Software
Figure 5 - Configuring the instance
6. If the connection profile popup appears, select SECLAB and click OK.
Figure 6 – Select SECLAB connection profile
7. Select the Instance Tab. Locate the AUTHENTICATION parameter. Double-click the correspondent Pending Value
field and select the SERVER_ENCRYPT authentication. Notice you can not use the Immediate option, therefore you
must restart the instance after changing the authentication type of the db2inst1 instance.
DB2 Security
IBM Software
Figure 7 - Select SERVER Authentication type
8. Click on button to apply the changes. Check the execution status on the SQL Results tab.
Figure 8 - SQL Results tab
9. Click to close the Configure Parameters window.

10. Right-click on db2inst1 and select Stop. A new Stop Instance db2inst1 tab will open.
Figure 9 - Stop db2inst1 instance
DB2 Security
IBM Software
11. Use the following credentials when prompted and click Finish.
• User: db2inst1
12. Select the first option (force the applications off), then click to execute the db2stop command. Check the SQL
Results tab for errors. If a warning dialog appears to inform you that databases, such as SECLAB, have been
disconnected, click OK to close the dialog.
Figure 10 - Stop db2inst1 instance
13. Now start the db2inst1 instance again. Right-click on db2inst1 and select Start.
Figure 11 - Start db2inst1 instance
14. Use the same credentials to execute the command and click Finish.
• User: db2inst1
15. Click to execute the db2start command. Check the SQL Results tab to confirm the command was executed
with success.
DB2 Security
IBM Software
Figure 12 - db2isnt1 instance restarted
16. Now you must reconnect to the SECLAB database. Just like before, right-click the SECLAB database and select
Connect. Login with the following credentials:
• User: db2inst1
17. After a connection has been established, right click on DB2INST1 and select Configure.
Figure 13 - Configure db2inst1 instance
18. If the connection profile popup appears, select SECLAB and click OK.
19. Select the Instance Tab. Locate the AUTHENTICATION parameter. Notice the authentication value has changed to
SERVER_ENCRYPT.
DB2 Security
IBM Software
Figure 14 - SERVER_ENCRYPT authentication is now in use
7 Authorization
After a user has been authenticated, authorization serves as the second security mechanism which determines what operations
a user can perform, and which data objects that user can access within a database or instance. The set of permissions granted
to users can come from privileges, authorities, roles, user groups and label-based access control (LBAC) credentials.
Administrative authorities group together certain privileges so that users can perform functions at the database or instance level.
A privilege is a permission to perform an action or task. For instance, privileges define the objects that a user can create or drop
and commands that a user can use to access objects like tables, views, indexes, and packages.
Roles can group together a set of privileges, so these can be assigned to users through the role instead of individually.
LBAC uses security labels to control who has read/write access to individual rows and columns of a table.
Note: LBAC capabilities are not covered in this hands-on lab.
7.1 Authorities
Authorities are needed for managing databases and instances and can be divided into two groups:
• System-level authorities
• Database-level authorities
7.1.1 System-level Authorities
System level authorities enable you to perform instance-wide functions, such as creating and upgrading databases, managing
table spaces, and monitoring activity and performance on your instance. These authorities are granted through the database
manager configuration and can only be assigned to user groups defined at the operating system level.
Below you will find the list of system-level authorities and their descriptions.
Database-level Authority Description
DB2 Security
IBM Software
SYSADM for users managing the instance as a whole

SYSCTRL for users administering a database manager instance
SYSMAINT for users maintaining databases within an instance
SYSMON for users monitoring the instance and its databases
By default, on Linux systems, the SYSADM group is set to the primary group of the instance owner: DB2GRP1. On Windows,
members of the local Administrators group are all granted SYSADM authority.
1. Using the Configure Parameters tab previously open, type SYSADM_GROUP in the filter text field. As soon as you
start typing, you will notice that Data Studio dynamically filters the parameters. You should see the SYSADM_GROUP
parameter below the filter text box.
Figure 15 - SYSADM Group
2. Click on the ‘X’ to close the “Configure Parameters” tab.
`
Figure 16 - Close the "Configure Parameters" tab
7.1.2 Database-level Authorities
Database level authorities enable you to perform functions within a specific database, such as granting and revoking privileges,
inserting, selecting, deleting and updating data, and managing workloads.
The database-level authorities are: ACCESSCTRL, BINDADD, CONNECT, CREATETAB, CREATE_EXTERNAL_ROUTINE,

CREATE_NOT_FENCED_ROUTINE, DATAACCESS, DBADM, EXPLAIN, IMPLICIT_SCHEMA, LOAD, QUIESCE_CONNECT,
SECADM, SQLADM, WLMADM.
7.2 Privileges
A privilege is a permission to perform an action or task. They can be obtained in three different ways:
• Explicitly: These are the privileges explicitly granted to a user/group/role using the GRANT command.
DB2 Security
IBM Software
• Implicitly: When a user creates a database object, that user will implicitly receive all privileges for that object. For
example, when a user creates a database, that user implicitly receives DBADM authority for that database.
• Indirectly: An indirect privilege is usually associated with a package. When a user is given permission to execute a
package, the user may not have privileges to access the objects used by the package. Therefore, the user will be
indirectly given these privileges temporary in order to execute the package.
7.3 Granting and Revoking Authorities and Privileges
So far, you have been issuing all database commands as the instance administrator (db2inst1) which has privileges to access all
the utilities, data, and database objects within DB2. It is important that users be only given privileges that are necessary to
complete their tasks.
In the following scenario, a new member (USERDEV) has joined your team. We will look at how to assign specific authorities
and privileges to him to safeguard the security of the database.
USERDEV is an application developer and as such he requires SELECT, INSERT, UPDATE, and DELETE privileges to access
the various tables in the database. USERDEV should also be able to add new packages to the database and execute them;
therefore, he needs BINDADD authority.
7.3.1 Adding a new user
1. Open a terminal window by right-clicking on the Desktop and choosing the Open in Terminal item:
Figure 17 - Open a new terminal window
As mentioned before, DB2 relies on the OS authentication mechanism, so we need to create the new users and groups
at the operating system level.
2. In the terminal window, execute the commands below to: 1) Log in as root user (use ‘password’ as password); 2) Add
a new user called USERDEV; 3) Change USERDEV’s password to ‘password’.
su -
useradd userdev
DB2 Security
IBM Software
passwd userdev
exit
Figure 18 - Add new USERDEV user and set its password
When the new user is added, this user he has no authorities or privileges other than those defined in the PUBLIC group.
3. Try to connect to SECLAB database as USERDEV.

db2 CONNECT TO SECLAB USER userdev USING password
Figure 19 – USERDEV does not have privileges to connect to SECLAB database
7.3.2 Granting Database Privileges
1. Switch to Data Studio. In the Administration Explorer, expand SECLAB > Users and Groups. Right-click on Users and
select Create User.
Figure 20 - Create a new database user
2. In the Properties view, input userdev into the Name field and select the Privileges option.
DB2 Security
IBM Software
Figure 21 - Define user name
3. The Connect should be already selected. Check the BINDADD and CREATETAB privileges as well.
Figure 22 - Grant database privileges to user USERDEV
4. Next, locate the toolbar on the top right corner ( ) and click on the Review and Deploy Changes
button ( ). Ignore the warnings and click OK.
The Review and Deploy screen will display the commands that were generated to apply the desired changes.
Figure 23 – Commands to be executed
DB2 Security
IBM Software
5. Select the Run radio option and click Finish.
Figure 24 – Select Run and click Finish
6. Check the SQL Results tab to ensure the commands were executed without errors.
Figure 25 – No errors reported on SQL Results table
USERDEV has now privileges to connect, bind a package and create tables in the SECLAB database.
7. Switch to the previously open terminal window. Try again to connect to SECLAB database as USERDEV.
db2 CONNECT TO SECLAB USER userdev USING password
Figure 26 - USERDEV now has privileges to connect to SECLAB database
7.3.3 Object-level Authorities
USERDEV must be able to query and modify the table EMPLOYEE.
1. In the same terminal window, try to query the EMPLOYEE table. You will notice that USERDEV does not have
privileges on EMPLOYEE table.
db2 "SELECT * FROM DB2INST1.EMPLOYEE"
DB2 Security
IBM Software
Figure 27 - USERDEV does not have SELECT privilege on employee table
2. Go back to Data Studio and locate the SECLAB database on the Administration Explorer view. Select the Tables
folder. Data Studio will list all SECLAB tables into the main view. Locate the Filter text box and type EMPLOYEE into
the text box. Notice that Data Studio’s dynamic filter will display the EMPLOYEE table.
Figure 28 - Locating EMPLOYEE table
3. Right click on EMPLOYEE table and select the Manage Privileges option.
Figure 29 - Select "Manage Privileges” option
4. Locate the USERDEV and tick the SELECT, INSERT, UPDATE and DELETE privileges.
Figure 30 - Select privileges to user USERDEV
Note: a single tick means the user has that privilege. Double-tick means the user has that privilege with the ability to
GRANT the privilege to other users (WITH GRANT OPTION).
DB2 Security
IBM Software
button ( ). Again, ignore the warnings and click OK.
Figure 31 – Commands to be executed
6. Select the Run option and click the Finish button.
Figure 32 - Applying the changes to the database
7. Finally, check the SQL Results tab to ensure the commands were executed without errors.
Figure 33 - No errors on the commands execution
USERDEV now has the privilege to interact with the SECLAB database.
8. Switch back to the terminal and try the same query again user USERDEV. You will notice that the operation will now
succeed.
db2 "SELECT * FROM DB2INST1.EMPLOYEE"
DB2 Security
IBM Software
Figure 34 – User USERDEV querying the EMPLOYEE table
7.4 Using Views to Define Granular Privileges
There are three ways in which access to specific portions of data in a table can be restricted: views, Label-Based Access
Control (LBAC) and the new Row and Column Access Control (RCAC). The use of LBAC and RCAC is beyond the scope of this
lab, so we will instead focus on the implementation of views.
Views are virtual tables (computed dynamically and not stored explicitly) that are derived from one or more tables or views.
They can be used to provide a customized subset of data to the users, allowing them to see different presentations of the same
set of data or hide data to which a user should not have access. Views can perform delete, insert, update operations or be read-
only.
The strategy to provide granular data access using views is as follows:
DB2 Security
IBM Software
• Create a view that returns the portion of the data that the user should have access to.
• Grant the user access to the view.
• Revoke from the user access to the base table.
7.4.1 Creating a View
We would like to create a view that returns a directory of only those who are in department E11. This view will contain only first
name, last name, phone number, and job role.
1. Switch back to Data Studio, right-click the Views folder and select Create View option.
Figure 35 - Creating a view
2. Select the DB2INST1 schema and click OK.
Figure 36 – Select DB2INST1 schema
The new view will be added at the bottom of the list and you will be able to define its definitions using the Properties
view. Select the General tab, enter E11INFO, and then select the SQL tab.
DB2 Security
IBM Software
Figure 37 - Edit the new view
3. Type the following SELECT statement to the Expression field, and then press the Update button to check the syntax.
SELECT FIRSTNME, LASTNAME, PHONENO, JOB FROM EMPLOYEE WHERE WORKDEPT='E11'
Figure 38 - Create E11INFO view
button ( ). The Review and Deploy screen will display the commands generated to reflect the desired changes.
DB2 Security
IBM Software
Figure 39 – E11INFO view SQL statement
The view E11INFO is now created and a user issuing a select statement against the view will see only the four columns
defined.
7. In Administration Explorer, on the menu bar, click and select New SQL Script:
Figure 42 - Create a new SQL script
8. In the editor, enter the SQL statement below and press to execute the statement.
select * from e11info;
DB2 Security
IBM Software
Figure 43 - Query E11INFO view
From now on, any new users that require access only to employees of department E11 can be granted access to the
E11INFO view instead of the EMPLOYEE base table.
8 Roles
A role is a database object that may group together one or more privileges and can be assigned to users, groups, PUBLIC or to
other roles via a GRANT statement. Roles simplify the administration and management of privileges.
8.1 Creating Roles
Consider now that your team is expanding and more application developers have joined in. Since all developers share the same
access requirements, roles can be used instead of managing privileges individually to each user.
The security administrator holds the authority to create, drop, grant, revoke, and comment on a role.
1. Switch back to Data Studio and expand the Users and Groups folder on Administration Explorer View. Then, right
click on Roles and select Create Role.
Figure 44 - Create a view
2. Name the role Developer and click on the Privileges tab.
DB2 Security
IBM Software
Figure 45 - Name the Developer view
3. Grant BINDADD, CONNECT and CREATETAB privileges on database.
4. Find the Table tab on the top. You might need to use the show list button ( ) if tab is not be visible.
Figure 46 - Database privileges
5. Click on the grant new privilege button ( ), expand the db2inst1 schema, select the EMPLOYEE table and click OK.
Notice that the EMPLOYEE table is now visible in the Privileges tab.
6. Grant SELECT, INSERT, UPDATE and DELETE on Employee table:
Figure 47 Employee table privileges
button ( ). The Review and Deploy screen will display the commands that were generated to apply the desired
changes.
DB2 Security
IBM Software
Figure 48 – Employee role SQL statement
The role Developer is now created. Now you must grant the role Developer to user USERDEV.
10. Click on the Users folder, right click on USERDEV and select Alter.
DB2 Security
IBM Software
Figure 51 - Altering USERDEV permissions
Note that USERDEV is now in edit ( ) mode.
11. Click on the Roles tab, then click on the grant new privilege button ( ).
Figure 52 - Grant new role to use USERDEV
12. Select Grant on the role Developer and click OK.
Figure 53 - Select GRANT on role Developer
button ( ).
DB2 Security
IBM Software
Figure 54 – Grant developer role to user USERDEV
The role Developer is now granted to user USERDEV. As more developers join the team, the Developer role can be
assigned to them in the same manner we did for USERDEV. In the future, if developers require any changes to their
security access, the security administrator can simply modify the privileges of the Developer role. All users associated
to this role will automatically inherit the new privileges.
9 Summary
This lab presented an overview of the basic security mechanisms in DB2 for LUW.
Before connecting to a DB2 database, users must be authenticated, i.e. their user ID and password are validated. DB2 does not
store user/password information in the database. Instead, it relies on an external authentication mechanism, by default the OS
authentication mechanism.
After a user is authenticated, DB2 performs an authorization check, where the database manager verifies if the user is
authorized to perform the requested operations on specific data objects. Users can be granted specific privileges, authorities or
DB2 Security
IBM Software
roles. DB2 also allows you to create your own database roles to bundle several privileges together so you can grant them at
once to a user, group or role.
10 Cleanup
1. To clean your environment after completing the exercise, right-click on SECLAB database, select Disconnect. Close
Data Studio and execute the commands below. Use “password” as password.
su –
cd /home/db2inst1/Documents/LabScripts/Security/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/Security/setup
./config.sh
DB2 Security
IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.
DB2 Security
IBM Software
Row and Column Access Control

Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................3
2 Objective...............................................................................................................................................................................................3
4 Laboratory Setup .................................................................................................................................................................................3
5 Implementing Row and Column Access Control on IBMCARD Database.....................................................................................4
5.1 Initial Steps ......................................................................................................................................................................................................... 6
5.2 Database Authorities........................................................................................................................................................................................... 7
5.3 Implementing Row Permissions.......................................................................................................................................................................... 7
5.4 Implementing Column Masks............................................................................................................................................................................ 12
5.5 Verifying the Restrictions .................................................................................................................................................................................. 14
5.6 Adding a New Customer ................................................................................................................................................................................... 15
5.7 Updating Customers’ Options ........................................................................................................................................................................... 16
5.8 Other Operations .............................................................................................................................................................................................. 17
6 Summary ............................................................................................................................................................................................18
7 Cleanup...............................................................................................................................................................................................18

IBM Software
1 Introduction
In order to comply with various government regulations, companies need to implement rules to ensure that information is
adequately secured. As a result, individuals should only be allowed to access the subset of data needed to perform their tasks.
DB2 10 introduces a new feature called Row and Column Access Control (RCAC). RCAC acts as an additional layer of data
security by controlling access to a table at the row level, column level, or both, complementing the table privileges model.
RCAC has several advantages over existing mechanisms. For example, no database user is exempted from the RCAC rules.
This means that even higher-level authorities, such as users with DATAACCESS authority, are not exempt from these rules.
RCAC also ensures that table data is protected regardless of how that table is accessed. Regardless of whether the data is
accessed via direct SQL, application logic, ad-hoc query tools, report generation tools, or even browsing through IBM Data
Studio, all users are subject to RCAC rules. A further advantage of the RCAC solution is that no application changes are
required to take full advantage of this additional layer of data security. Consequently, the feature is transparent to existing
applications.
The RCAC feature represents an important shift in paradigm; it is no longer about what data is being asked, but rather who is
asking for the data. Depending on who requested data, result sets for the same query can differ immensely.
2 Objective
The exercises in this laboratory are designed to help you understand how Row and Column Access Control works, and what
steps are required to implement data access restrictions with it.
By the end of this laboratory, you will be able to:

• Understand how DB2’s Row and Column Access Control feature works
• Implement row permissions
• Implement column masks

4 Laboratory Setup
The lab’s users have already been set up for you, along with the database and tables required for the lab. This lab uses five
users: ADAM, JILL, PAMELA, ERIC and ANTHONY. Each of their passwords has been set to “password”. The database that
has been created is named IBMCARD. There are two tables in this database: CUSTOMER and MARKETINGCHOICE.

IBM Software

5 Implementing Row and Column Access Control on IBMCARD Database

The following scenario presents the IBMCARD Corporation, a national organization with a large and active list of customers. The
company uses DB2’s Row and Column Access Control feature to ensure that their database policies reflect government
regulatory requirements for privacy and security, as well as management business objectives.
The CUSTOMER table stores individual customer information.
This scenario considers the following columns within the CUSTOMER table:
Column Description
SSN The customer’s social security number.
NAME The customer’s name.
ADDRESS The customer’s address.
CARD_NUMBER The customer’s credit card number.
PHONE The customer’s phone number.
BALANCE The customer’s balance.
MGR_ID The customer’s primary care account manager database ID.
Table 1 – CUSTOMER table
The MARKETINGCHOICE table stores individual customer information, which decides whether a customer wants to participate
in IBMCARD’s marketing programs.
This scenario considers the following columns within the MARKETINGCHOICE table:
Column Description
SSN The customer’s social security number is used to match customers with their
choices.
VALUE The decision made by the customers about the marketing program.
For example, the row (123-45-6789, yes) says that customer with SSN 123-45-
6789 agrees to receive marketing information.
Table 2 – MARKETINGCHOICE table

IBM Software
It is important for the data in IBMCARD’s database systems to be secure and only be accessible by privileged users. The first
column outlines the policies and the challenges faced by the IBMCARD organization, while the second column outlines the
feature of RCAC that best addresses the challenge.
RCAC feature that addresses the security

Security challenge
challenge
Limiting column access to only privileged Column masks can be used to filter or hide
users. sensitive data from JILL.
For example, JILL from the marketing

department is not permitted to view sensitive
customer or personal data (i.e. social security
numbers or credit limits)
Limiting row access to only privileged users. Row permissions can be implemented to
control which row can be seen by ERIC.
For example, ERIC the account manager can
only see customer information for her own
customers.
Restricting data on a need-to-know basis. Row permissions can help with this challenge
as well by restricting table level data at the
user level.
Table 3 – How DB2’s Row and Column Access Control feature secures information
In this scenario, a number of different people create, secure and use IBMCARD data. Each person has different user rights and
database authorities. Internal and external access to data is based on the separation of duties to users who access the data and
their data access privileges. IBMCARD created the following database roles to separate these duties:
Role name Role description

MARKETING For marketing operators. Can read name and phone if authorized. No
access to value column.
ACCOUNTING For accountants. All access.
MEMBERSHIP For membership officers. Can read and write all except credit card
balances.
Table 4 – Roles and descriptions
The following people create, secure, and use IBMCARD data:
Name Duties
ADAM IBMCARD Chief Security Administrator. He holds the SECADM authority
JILL IBMCARD Marketing Department. He belongs to the MARKETING role.
ERIC IBMCARD Accounting Department. He belongs to the ACCOUNTING role.
PAMELA IBMCARD Accounting Department. She belongs to the ACCOUNTING role.
ANTHONY IBMCARD Membership Manager. He belongs to the MEMBERSHIP role.
Table 5 – Users and duties

IBM Software
5.1 Initial Steps

The tables, users and data necessary for this lab have already been created. In order to avoid any typos when
executing SQL statements every script required by this lab has already been created for you.
3. Right click the desktop and select “Open in Terminal”.

4. Navigate to /home/db2inst1/Documents/LabScripts/RCAC directory by executing the command below:
cd /home/db2inst1/Documents/LabScripts/RCAC
5. Start DB2:
db2start
6. During this laboratory, you will use a single terminal which contains several tabs. Each tab will be used for a specific
user in the database. In order to open the command line tabs, execute the command below.
Use “password” as password.
./OPEN_TABS
7. Select the tab labeled DB2INST1. This tab will be used to prepare the IBMCARD environment for this laboratory.
8. Navigate to /home/db2inst1/Documents/LabScripts/RCAC directory by executing the command below:
9. The script 01_PREPARE_IBMCARD_ENVIRONMENT creates the roles described and then assigns the proper
permissions to each one of them.
In order to view the script, execute the command below:
less 01_PREPARE_IBMCARD_ENVIRONMENT
--Creating roles and granting authority

CREATE ROLE MARKETING;
CREATE ROLE ACCOUNTANT;
CREATE ROLE MEMBERSHIP;
GRANT ROLE MARKETING TO USER JILL;
GRANT ROLE ACCOUNTANT TO USER ERIC;
GRANT ROLE ACCOUNTANT TO USER PAMELA;
GRANT ROLE MEMBERSHIP TO USER ANTHONY;
--Grant authority
GRANT SELECT, UPDATE ON TABLE IBMCARD.CUSTOMER TO ROLE ACCOUNTANT;
GRANT SELECT, INSERT ON TABLE IBMCARD.CUSTOMER TO ROLE MEMBERSHIP;
GRANT UPDATE (SSN, NAME, ADDRESS, PHONE, CARD_NUMBER) ON TABLE
IBMCARD.CUSTOMER TO ROLE MEMBERSHIP;
GRANT SELECT ON TABLE IBMCARD.CUSTOMER TO ROLE MARKETING;
GRANT INSERT, SELECT, DELETE, UPDATE ON TABLE IBMCARD.MARKETINGCHOICE TO ROLE
MEMBERSHIP;

IBM Software
10. After looking at the code, press “q” to exit the script. Next, connect to the database and run this script by executing the
following commands:
db2 connect to IBMCARD
db2 -tvf 01_PREPARE_IBMCARD_ENVIRONMENT
The roles are now created and the proper permissions are assigned to each database user.
5.2 Database Authorities
Security administration and the security administrator (SECADM) role play important parts in securing both the CUSTOMER
table and company data at IBMCARD.
At IBMCARD, the management team decided to create a role for administering access to their data. The team also decided that
even users with DATAACCESS authority are not allowed to view protected personal data by default.
The management team selects ADAM to be the sole security administrator for IBMCARD. From now on, ADAM controls all data
access authority. With this authority, ADAM defines security rules such as row permissions, column masks, and whether
functions and triggers are secure or not. These rules are used to control user access to data on the system.
1. To do so, execute the following commands in the command line:

db2 GRANT SECADM ON DATABASE TO USER ADAM;
ADAM now becomes the sole authority to grant data access to others within and outside IBMCARD.
5.3 Implementing Row Permissions
Row permissions are one of the functions provided by DB2’s row and column access control feature. These are used to restrict
or filter rows based on the user who has logged on to the database. At IBMCARD, the row permissions create a record
restriction on the CUSTOMER table.
ADAM, IBMCARD’s Security Administrator, must connect to the database, so that he can create row permissions and activate
row access control in the CUSTOMER table.
In order to create row permissions and column masks, ADAM must be able to alter the CUSTOMER table definition.
1. Execute the following command to grant ALTER TABLE permission to ADAM.

db2 GRANT ALTER ON TABLE IBMCARD.CUSTOMER TO USER ADAM;
2. Next, select the tab labeled ADAM (the security administrator) and execute the following command in order to connect
to IBMCARD database as ADAM:
db2 CONNECT TO IBMCARD USER ADAM USING password;
3. Navigate to /home/db2inst1/Documents/LabScripts/RCAC directory by executing the command below.

ADAM will implement the following permissions to restrict who can see any given row on a need-to-know basis:

IBM Software
• Each user belonging to the ACCOUNTANT role is permitted to view the data of the customers under his
responsibility, but not the data of customers who are under other accountants.
• Users belonging to the MEMBERSHIP role can access all CUSTOMER information.
• Users belonging to the MARKETING role are allowed to access the information of only those customers who
opted for receiving marketing calls.
Before creating the permissions, let’s make sure all users have access to customers’ information.
4. Select the tab labeled PAMELA (accountant) and execute the following command in order to connect to IBMCARD
database as PAMELA:
db2 CONNECT TO IBMCARD USER PAMELA USING password;
5. Then, execute the following SQL statement to retrieve the customers’ information:
db2 "SELECT * FROM IBMCARD.CUSTOMER";
SSN NAME ADDRESS PHONE CARD_NUMBER BALANCE MGR_ID

----------- ---- --------------- ------------ ------------------- -------- ------
123-55-1234 Max 21 John Street 905-413-2311 1234-5678-9012-3456 89.70 ERIC
123-58-9812 Mike 98 Yonge Street 905-232-5633 3459-5344-6452-1234 8.30 PAMELA
123-11-9856 Sam 50 Rogers Street 905-413-2457 4335-5633-5673-9634 40.00 ERIC
123-19-1454 Dug 76 Dallas Street 905-331-1445 7647-9246-2345-3452 76.00 PAMELA
4 Record(s) selected
PAMELA is able to retrieve all customers’ information. However, according the new rules, PAMELA must only see her
own customers.
6. Select the tab labeled ANTHONY (membership manager) and execute the following command in order to connect to
IBMCARD database as ANTHONY:
db2 CONNECT TO IBMCARD USER ANTHONY USING password;

----------- ---- --------------- ------------ ------------------- -------- ------
4 Record(s) selected.
ANTHONY is able to retrieve all customers’ information.

8. ANTHONY is also responsible for defining which customers will participate in IBMCARD’s marketing programs. So, let’s
check which customers opted for receiving marketing calls.

IBM Software
Execute the following SQL statement to retrieve the customers’ information:

db2 "SELECT C.SSN, C.NAME, M.VALUE FROM IBMCARD.CUSTOMER C,
IBMCARD.MARKETINGCHOICE M WHERE C.SSN = M.SSN";
SSN NAME VALUE

----------- ---- -----
123-55-1234 Max yes
123-58-9812 Mike no
123-11-9856 Sam yes
123-19-1454 Dug no
So far, only Sam and Max opted to receive marketing calls, therefore JILL, IBMCARD’s marketing operator, shouldn’t
be able to retrieve Mike and Dug’s information.
9. Select the tab labeled JILL (marketing operator) and execute the following command in order to connect to IBMCARD
database as JILL:
db2 CONNECT TO IBMCARD USER JILL USING password;

----------- ---- ---------------- ------------ --------- -------- --------- ------
JILL is able to retrieve all customers’ information.
11. ADAM starts implementing permissions for the ACCOUNTANT role by creating the
02_CREATE_PERMISSION_ACCOUNTANT script.
Go back to the tab labeled ADAM (belonging to ADAM the security administrator) and execute the command below to
review the script created:
less 02_CREATE_PERMISSION_ACCOUNTANT
CREATE PERMISSION ROW_ACCESS_ACCOUNTANT ON IBMCARD.CUSTOMER

-------------------------------------------------------
-- Accounting information:
-- ROLE ACCOUNTANT is allowed to access his or her customers’ rows
------------------------------------------------------------
FOR ROWS WHERE
(VERIFY_ROLE_FOR_USER(SESSION_USER, 'ACCOUNTANT') = 1
AND

IBM Software
IBMCARD.CUSTOMER.MGR_ID = SESSION_USER)
ENFORCED FOR ALL ACCESS
ENABLE;
12. Now press “q” to exit the script. Run the script by executing the following command:
db2 -tvf 02_CREATE_PERMISSION_ACCOUNTANT
The permission is created in the database but the row permission feature is not activated. Therefore you won’t see the
correct results yet. We will activate row access control after creating all permissions.
13. Then, ADAM implements the permission for MEMBERSHIP role by creating the
03_CREATE_PERMISSION_MEMBERSHIP script. In order to view the script, execute the command below:
less 03_CREATE_PERMISSION_MEMBERSHIP
CREATE PERMISSION ROW_ACCESS_MEMBERSHIP ON IBMCARD.CUSTOMER

-------------------------------------------------------
-- ROLE MEMBERSHIP is allowed to access all rows.
------------------------------------------------------------
FOR ROWS WHERE
(VERIFY_ROLE_FOR_USER(SESSION_USER,'MEMBERSHIP') = 1)
ENABLE;
db2 -tvf 03_CREATE_PERMISSION_MEMBERSHIP
15. Next, ADAM implements the permission for MARKETING role by creating the
04_CREATE_PERMISSION_MARKETING script. In order to view the script, execute the command below:
less 04_CREATE_PERMISSION_MARKETING
CREATE PERMISSION ROW_ACCESS_MARKETING ON IBMCARD.CUSTOMER
-------------------------------------------------------
-- MARKETING are allowed to access the rows where the customers
-- opted for receiving marketing calls.
------------------------------------------------------------
FOR ROWS WHERE
(VERIFY_ROLE_FOR_USER(SESSION_USER, 'MARKETING') = 1 AND
EXISTS (
SELECT 1 FROM IBMCARD.MARKETINGCHOICE C
WHERE IBMCARD.CUSTOMER.SSN = C.SSN AND C.VALUE = 'yes'))
ENABLE;

IBM Software
db2 -tvf 04_CREATE_PERMISSION_MARKETING
The permissions are created in the database.
Finally, Adam activates the row access control feature in the IBMCARD database.
17. Execute the following alter statement to activate row access control on table Customer:
db2 ALTER TABLE IBMCARD.CUSTOMER ACTIVATE ROW ACCESS CONTROL;
All permissions are now activated in the customer table. All data in IBMCARD.CUSTOMER table is now protected.
18. Switch to the tab labeled PAMELA (accountant) and execute the following SQL statement to retrieve the customers’
information:

----------- ---- ---------------- ------------ --------- -------- --------- ------
You may recall that the last time PAMELA ran this command; she could see all data in the table. This time, PAMELA is
now allowed to retrieve only her costumers’ records. Row access control has been successful!
19. Then, switch to the tab labeled ANTHONY (membership manager) and execute the following SQL statement to retrieve
the customers’ information:

----------- ---- ---------------- ------------ --------- -------- --------- ------
As can be seen, ANTHONY is still able to retrieve all customers’ information. According to our earlier model, this is as
expected.
20. Finally, switch to the tab labeled JILL (marketing operator) and execute the following SQL statement to retrieve the
customers’ information:

IBM Software

----------- ---- ---------------- ------------ --------- -------- --------- ------
As we would expect from our earlier model, JILL is now allowed to retrieve only customers who opted for receiving
marketing calls.
5.4 Implementing Column Masks
Later, ADAM is asked by management to protect the customers’ balance information. The BALANCE column must only be
accessible to the users in the ACCOUNTANT role.
ADAM restricts data access on the IBMCARD database by using column masks, a part of DB2’s row and column access control
feature. Column masks hide data returned to users unless they are permitted to view the data.
ADAM creates the 05_CREATE_COLUMN_MASK_BALANCE script, which implements column masks such that a user in each
role is restricted to view a result set that they are privileged to view.
1. As ADAM must create the column mask, switch back to the tab labeled ADAM (security administrator) and view the
script by executing the command below:
less 05_CREATE_COLUMN_MASK_BALANCE
--Create a Column MASK ON BALANCE column on the IBMCARD.CUSTOMER table

CREATE MASK BALANCE_MASK ON IBMCARD.CUSTOMER FOR
------------------------------------------------------------
-- Role ACCOUNTING is allowed to access the full information
-- on column BALANCE.
-- Other roles accessing this column will strictly view a
-- zero value.
------------------------------------------------------------
COLUMN BALANCE RETURN
CASE WHEN VERIFY_ROLE_FOR_USER(SESSION_USER,'ACCOUNTING') = 1
THEN BALANCE
ELSE 0.00
END
ENABLE;
db2 -tvf 05_CREATE_COLUMN_MASK_BALANCE
A column mask is not applied until it is activated on the table for which it was defined. Therefore, the security
administrator (ADAM) must now activate the column access control.

IBM Software
3. Execute the following command in the command line:

db2 ALTER TABLE IBMCARD.CUSTOMER ACTIVATE COLUMN ACCESS CONTROL;
Let’s check if the changes were correctly applied in the database. As ANTHONY has the MEMBERSHIP role, he
shouldn’t be able to see the clients’ balance information.
4. Switch to the tab labeled ANTHONY (membership manager) and execute the following SQL statement to retrieve the

----------- ---- ---------------- ------------ --------- -------- --------- ------
As expected by our model above, ANTHONY is not able to retrieve customers’ balance information. He simply sees a
balance of 0.00.
Moreover, ADAM is asked by management to implement the following restrictions:

• Hide the social security number of customers. Only people in an ACCOUNTING or MEMBERSHIP role can view
the SSN column.
• Protect the customer’s card number. Only people in an ACCOUNTING or MEMBERSHIP roles can view the card
number.
• Protect the customer’s telephone number. The information in the PHONE column can only be viewed by people in a
MARKETING role where the customer has agreed to receive marketing information. The phone number must be
available for ACCOUNTING, MEMBERSHIP and CUSTOMER roles.
In order to implement the above restrictions, ADAM created the following scripts:
• 06_CREATE_COLUMN_MASK_SSN
• 07_CREATE_COLUMN_MASK_CARD_NUMBER
5. In order to view each script, switch to the tab labeled ADAM (security administrator) and execute the commands below.
Press “q” to exit the script before moving to the next one.
less 06_CREATE_COLUMN_MASK_SSN
CREATE MASK IBMCARD.SSN_MASK ON IBMCARD.CUSTOMER FOR

----------------------------------------------------
-- Social Security Number contact information:
-- Roles CUSTOMER, MEMBERSHIP, and ACCOUNTING are allowed

IBM Software
-- to access the full information on SSN column. Other roles accessing

-- these columns will strictly view a masked value.
-----------------------------------------------------
COLUMN SSN RETURN
CASE WHEN
VERIFY_ROLE_FOR_USER(SESSION_USER,'CUSTOMER') = 1 OR
VERIFY_ROLE_FOR_USER(SESSION_USER,'MEMBERSHIP') = 1 OR
VERIFY_ROLE_FOR_USER(SESSION_USER,'ACCOUNTING') = 1
THEN SSN
ELSE CHAR('XXX-XX-' || SUBSTR(SSN,8,4))
END
ENABLE;
less 07_CREATE_COLUMN_MASK_CARD_NUMBER
CREATE MASK IBMCARD.CARD_NUMBER ON IBMCARD.CUSTOMER FOR

--------------------------------------------------------
-- Customer's credit card information:
-- Roles MEMBERSHIP, and ACCOUNTANT are allowed
-- to access the full information on PHONE column.
-- Role MARKETING is allowed to access customers' phone
-- information if the customer agreed to participate
-- IBMCARD's marketing programs.
----------------------------------------------------
COLUMN CARD_NUMBER RETURN
CASE WHEN
VERIFY_ROLE_FOR_USER(SESSION_USER,'ACCOUNTING') = 1 OR
VERIFY_ROLE_FOR_USER(SESSION_USER,'MEMBERSHIP') = 1
THEN CARD_NUMBER
ELSE CHAR('XXXX-XXXX-XXXX-' || SUBSTR(CARD_NUMBER,16,4))
END
ENABLE;
6. Go to the tab labeled ADAM (security administrator) and execute the following command:
db2 -tvf 06_CREATE_COLUMN_MASK_SSN
7. Execute the corresponding command:
db2 -tvf 07_CREATE_COLUMN_MASK_CARD_NUMBER
5.5 Verifying the Restrictions
ADAM observes that after creating these column masks, the data is only viewable to intended users. The CUSTOMER table has
already had column access control activated.
1. In order to verify the restrictions are applied, go to the tab labeled ANTHONY (membership manager) and execute the
following SQL statement to retrieve the customers’ information:

IBM Software

----------- ---- ---------------- ------------ --------- -------- --------- ------
As expected, ANTHONY is still able to retrieve the customers’ SSN and CARD_NUMBER information.
2. Switch to tab labeled JILL (marketing operator) and execute the following SQL statement to retrieve the customers’
information:

----------- ---- ---------------- ------------ ------------------- --------- ------
XXX-XX-1234 Max 21 John Street 905-413-2311 XXXX-XXXX-XXXX-3456 0.0 ERIC
XXX-XX-9856 Sam 50 Rogers Street 905-413-2457 XXXX-XXXX-XXXX-9634 0.0 ERIC
The SSN, CARD_NUMBER and BALANCE columns are now masked and JILL, who is a marketing operator, can’t see
this information anymore.
3. Finally, switch to the tab labeled PAMELA (accountant) and execute the following SQL statement to retrieve the

----------- ---- ---------------- ------------ --------- -------- --------- ------
PAMELA is still able to retrieve all information from his costumers.
5.6 Adding a New Customer
Melanie is a new customer, and her records must be added to the IBMCARD database. A user with the required security
authority must create the new record for Melanie. ANTHONY, with the MEMBERSHIP role, enrolls Melanie as a new member
and assigns PAMELA as her account manager. ANTHONY created the ADD_CUSTOMER_MELANIE script to add Melanie to
the IBMCARD database.

IBM Software
1. Select the tab labeled ANTHONY (membership manager). Navigate to /home/db2inst1/Documents/LabScripts/RCAC

directory by executing the command below.
2. In order to view the script, execute the command below:
less 08_ADD_CUSTOMER_MELANIE
INSERT INTO IBMCARD.CUSTOMER VALUES('987-65-4321', 'Melanie', '02 Main

Street', '905-283-7435', '5432-8765-1234-0987', 60.00, 'PAMELA');
INSERT INTO IBMCARD.MARKETINGCHOICE VALUES('987-65-4321', 'no');
db2 -tvf 08_ADD_CUSTOMER_MELANIE
4. ANTHONY confirmed that Melanie was added to the database by querying the same from the CUSTOMER table in the
IBMCARD database:
db2 "SELECT * FROM IBMCARD.CUSTOMER WHERE NAME ='Melanie'";

----------- ---- ---------------- ------------ ------------------- -------- ------
987-65-4321 Melanie 02 Main Street 905-283-7435 5432-8765-1234-0987 0.0 PAMELA
As the row and column access control feature is still activated and Melanie opted to not receive any marketing calls,
therefore JILL (the marketing operator) shouldn’t be able to see Melanie’s information.
5. In order to verify this, select the tab labeled JILL (marketing operator) and execute the following command:

----------- ---- ---------------- ------------ ------------------- -------- ------
JILL is not able to retrieve Melanie’s information.
5.7 Updating Customers’ Options
Let us say that Melanie called ANTHONY from IBMCARD Membership department, to change her marketing choice so that she
can now receive marketing offers.
1. Switch back to the tab labeled ANTHONY (membership officer) and execute the following command in order to update
Melanie’s information:

IBM Software
db2 "UPDATE IBMCARD.MARKETINGCHOICE SET value = 'yes' WHERE ssn = '987-65-

4321'";
2. Then, select the tab labeled JILL (marketing operator) and execute the following command:

----------- ---- ---------------- ------------ ------------------- -------- ------
XXX-XX-4321 Melanie 02 Main Street 905-283-7435 XXXX-XXXX-XXXX-0977 0.0 PAMELA
After the update, JILL is now able to see Melanie’s information Therefore she can now call Melanie to offer marketing
programs.
5.8 Other Operations
As RCAC only allows users to access the subset of data that is needed to perform their tasks.
Let’s see what happens when PAMELA, an IBMCARD accountant, tries to update the balance of all customers in IBMCARD
database.
1. To do so, select the tab labeled PAMELA (accountant) and execute the following command:
db2 "UPDATE IBMCARD.CUSTOMER SET BALANCE = 100.00";
This operation should change all clients’ balance to 100.00, but as PAMELA only has access to his customers, the other
customers who are managed by other accountants (for example, ERIC) won’t be affected by PAMELA’s operation.
2. Execute the following command to verify the balance on PAMELA’s customers:

----------- ---- ---------------- ------------ ------------------- -------- ------
XXX-XX-1234 Max 21 John Street 905-413-2311 XXXX-XXXX-XXXX-3456 100.0 PAMELA
XXX-XX-9856 Sam 50 Rogers Street 905-413-2457 XXXX-XXXX-XXXX-9634 100.0 PAMELA
XXX-XX-4321 Melanie 02 Main Street 905-283-7435 XXXX-XXXX-XXXX-0977 100.0 PAMELA
3. Now, let’s verify the balance of Eric’s customers. Select the tab labeled ERIC (accountant) and execute the following
command in order to connect to IBMCARD database as ERIC:
db2 CONNECT TO IBMCARD USER ERIC USING password;
4. Then, execute the following SQL statement to retrieve ERIC’s customers’ information:

IBM Software

----------- ---- ---------------- ------------ --------- -------- --------- ------
As expected, PAMELA’s update action didn’t affect ERIC’s customers.
You can try the same operation using the “DELETE” command instead of “UPDATE”. The behavior will be the same.
Only the data visible to each user will be affected by their actions.
6 Summary
You can see by now that DB2 Row and Column Access Control is a powerful feature that can help your business secure its
critical information. By acting as an additional layer of data security, it can allow access-control at the row level, column level or
both without having the need to modify your already existing application. Over the course of this laboratory, you have seen how
efficient and easy it is to create and implement row permissions and column masks. You have also seen that even higher-level
authorities, such as users with DATAACCESS authority, are not exempt from these rules, regardless of how that table is
accessed. The best part may be that this is just a subset of all that the DB2 Row and Column Access Control feature can do.
7 Cleanup
1. To clean up your environment for the next lab, go to the first tab (belonging to DB2INST1, the database administrator)
and run the commands below. Use “password” as password.
db2 force application all;
su -
cd /home/db2inst1/Documents/LabScripts/RCAC/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/RCAC/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
Continuous Data Ingest

Hands-On Lab
IBM Software
Table of Contents
1 Introduction 3
2 About this Lab 3
3 Environment Setup Requirements 3
4 Initial Steps 3
5 Utility Configuration 4
6 Ingesting Data 5
7 Monitoring Ingest Operations 6
8 Handling Data Errors 8
9 Recovering Failed INGEST Command 11
10 Data Manipulation with Ingest Utility 13
11 Sample CDI Project 16
12 Summary 17
13 Cleanup 17

IBM Software
1 Introduction
The ingest utility, or CDI (Continuous Data Ingest), is a high-speed client-side DB2® utility capable of streaming data from files
and pipes into DB2 target tables. Unlike the import and load utilities, the ingest utility does not lock target tables when moving
large amounts of real-time data, so you don’t have to choose data availability at the expense of data concurrency. Data is
ingested at speeds high enough to populate even large tables in partitioned database environments without affecting data
availability. Therefore business decisions can be taken based on the most recent data, leading to effective business intelligence.
2 About this Lab

• Understand basic concepts of the ingest utility
• Complete necessary ingest-related tasks
• Run the ingest utility
• Handle rejected data
• Restart failed INGEST commands
• Manipulate data being ingested
• Automate script to continuously ingest data

1. DB2 10 VMware® image
2. VMware Workstation 6.5 or later
4 Initial Steps
1. Start the VMware image by clicking the button in VMware.

3. Open a terminal by right-clicking on the Desktop and select Open in Terminal.

IBM Software
Figure 1 – Open in Terminal on Desktop
4. Ensure that the DB2 Database Manager has been started by issuing the following
db2start
A message like the following should be displayed to indicate that the DB2 Database Manager has been started:
db2inst1@db2beta3:~/Desktop> db2start
01/05/2012 14:36:11 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
5 Utility Configuration
By default, failed INGEST commands are restartable from the last commit point. A restart table needs to be created before
running the ingest utility to capture information needed to resume a failed ingest operation, otherwise you will receive an error
message notifying you that the command issued is not restartable. The ingest utility uses this table to store information needed
to resume an incomplete INGEST command.
1. A connection needs to be established to the INGEST database first. Issue the following command in the terminal.
db2 CONNECT TO INGEST
2. Enter the following command in the terminal to create a restart table:

db2 "CALL SYSPROC.SYSINSTALLOBJECTS('INGEST', 'C', NULL, NULL)"
After the command is successfully executed, a status of 0 is returned and table SYSTOOLS.INGESTRESTART is created.

IBM Software
There are a few configuration parameters specifically designed for the INGEST utility. These parameters can be set with the
INGEST SET command. The setting 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 sessions or later sessions that use a different CLP
backend process. In this section, you will set commit_count and commit_period configuration parameters for the
environment of this lab.
3. Set commit_count parameter to 1000.

db2 INGEST SET commit_count 1000
Note: commit_count specifies the number of rows each flusher writes in a single transaction before issuing a commit. It
should be a number multiple of 1000. The default value is 0.
4. Set commit_period to 0.
db2 INGEST SET commit_period 0
Note: commit_period specifies the number of seconds between committed transactions. The default value is 1. If
commit_period is set to 0, the commit_count configuration parameter is used.
Note: in this lab, we choose to commit transactions based on the number of rows only.
6 Ingesting Data
1. Change directory to /home/db2inst1/Documents/LabScripts/CDI, where the scripts needed for this lab are stored.
cd /home/db2inst1/Documents/LabScripts/CDI/
2. Now that you have set the configuration parameters, you are ready to ingest data. Ingest all 100,000 records from the
pre-populated file ingest_data_100k to table SALES.
db2 "INGEST FROM FILE './ingest_data_100k' FORMAT DELIMITED INSERT INTO
sales"
When the INGEST command starts executing, you will see a message like the following, where the timestamp indicates
the exact time at which the ingest utility is started and the job ID is a unique number that identifies the INGEST
command being run. In the case of an execution failure, you can use this ID to restart the failed operation from the last
commit point.
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 "INGEST FROM FILE './ingest_data_100k'
FORMAT DELIMITED INSERT INTO sales"
SQL2979I The ingest utility is starting at "01/06/2012 09:26:00.324748".
SQL2914I The ingest utility has started the following ingest job:
"DB21001:20120106.092600.324748:00002:00016".

IBM Software
When the ingest operation finishes executing, a summary is displayed in the terminal like the one below:
FORMAT DELIMITED INSERT INTO sales"
SQL2914I The ingest utility has started the following ingest job:
"DB21001:20120106.092600.324748:00002:00016".

SQL2980I The ingest utility completed successfully at timestamp "01/06/2012

09:26:41.993099"
7 Monitoring Ingest Operations
There are a number of ways to monitor an ingest operation:

• The INGEST LIST command provides basic information about all currently running INGEST commands.
• The INGEST GET STATS command provides more detailed information about a specific INGEST command or all
currently running INGEST commands.
• You can also query monitor elements by using an interface such as the MON_GET_CONNECTION table function
In this lab, you will experiment the INGEST LIST and INGEST GET STATS commands.
1. You will re-use table SALES to ingest more data. So truncate the SALES table first by issuing the following command:
db2 TRUNCATE TABLE SALES REUSE STORAGE IMMEDIATE
2. To monitor INGEST operations, you need a separate session but it must be run on the same machine that the INGEST
command is running on. In the terminal that you have been using so far, click File on the top menu bar, then select
Open Terminal.
Figure 2 – Open a new terminal

IBM Software
3. The second terminal should open in the same /home/db2inst1/Documents/LabScripts/CDI directory as the first terminal.
You need to connect to the INGEST database in the second terminal as well.
db2 CONNECT TO INGEST
4. In the next few steps, you will need to use both terminal windows at the same time, one for running INGEST commands,
and the other one for monitoring the commands. So timing could play a factor in the monitoring result you get.
Switch back to the first terminal, where you ran your first INGEST command. Issue the following command to ingest
200,000 records from file ingest_data_200k into SALES. This time, instead of letting the ingest utility generate a job ID
for you, you will add a RESTART NEW option in the command to attach a customized ID so that it’s more convenient to
remember and use.
db2 "INGEST FROM FILE './ingest_data_200k' FORMAT DELIMITED RESTART NEW
'job1' INSERT INTO sales"
Note: The job ID you specify can be up to 128 bytes. Because the string uniquely identifies an INGEST command, it must
be unique across all concurrently running INGEST commands that specified the RESTART NEW option in the current database.
5. When the INGEST command starts executing, i.e. after the ingest utility starting timestamp is displayed, switch to the
second terminal, then issue command INGEST LIST.
db2 INGEST LIST
A summary like the following should be displayed with the basic information about the running INGEST command, such
as the number of records that have been processed thus far.
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 INGEST LIST
Ingest job ID = job1

Ingest temp job ID = 1
Database Name = INGEST
Target table = DB2INST1.SALES
Input type = FILE
Start Time = 01/06/2012 15:08:39.288403
Running Time = 00:00:06
Number of records processed = 33000
DB20000I The INGEST LIST command completed successfully.
6. To get more detailed information about the running INGEST commands, INGEST GET STATS should be used. Switch
to the first terminal and ingest data again by issuing the following command:

IBM Software
7. Like before, when the INGEST command starts executing, switch to the second terminal, then issue command below:
db2 "INGEST GET STATS FOR 'job2' EVERY 2 SECONDS"
You will see that the statistics about the INGEST operation gets updated every 2 seconds on the screen until the
operation finishes executing. Depending on the performance of the machine you run this lab on, the output should look
similar to the following:
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 "INGEST GET STATS FOR 'job2' EVERY 2

SECONDS"
Ingest job ID = job2

Database Name = INGEST
Target table = DB2INST1.SALES
Overall Overall Current Current

ingest rate write rate ingest rate write rate
(records/second) (writes/second) (records/second) (writes/second) Total records
----------------- ----------------- ----------------- ----------------- -----------------
7317 0 43905 0 0
14129 250 34566 1000 2000
12566 400 6314 1000 4000
12475 500 12021 1000 6000
12953 714 15819 2000 10000
12500 1062 9327 3500 17000
11111 1388 0 4000 25000
10000 2000 0 7500 40000
10000 2000 0 7500 40000
9090 2409 0 6500 53000
8333 2625 0 5000 63000
7692 3000 0 7500 78000
7142 3464 0 9500 97000
6666 4900 0 25000 147000
6250 6218 0 26000 199000
5882 5882 0 500 200000
DB20000I The INGEST GET STATS command completed successfully.
8 Handling Data Errors
The ingest utility supports copying rejected records to a file or table, or discarding them. A record can be rejected due to
errors such as out-of-range numeric values, incompatible data types, or invalid date format. You can specify what the
INGEST command does with rows rejected by the ingest utility (using the DUMPFILE option) or by DB2 (using the
EXCEPTION TABLE option). Note that rejected records do not cause the INGEST command to fail, the command would
continue with the remaining records from the source input. In this section, you will explore how the ingest utility handles
rejected records using the DUMPFILE option.
1. In your first terminal, truncate the table SALES by issuing the following command:

IBM Software
2. Ingest data from file ingest_data_excp into table SALES with command:
db2 "INGEST FROM FILE './ingest_data_excp' FORMAT DELIMITED DUMPFILE
'./rejected.txt' MESSAGES './messages.txt' RESTART NEW 'job3' INSERT INTO
sales"
Note: Parameter DUMPFILE specifies that rows rejected by the formatters are to be written to the specified file. If this
parameter is not specified, the ingest utility issues an error message for each rejected row, but does not save the row anywhere.
If you specify this parameter and any rejected input records contain sensitive data, these records appear in the dump file. You
must protect the file from unauthorized access as needed.
Note: Parameter MESSAGES specifies the file to receive informational, warning, and error messages.
After the INGEST command is finished, you should see messages like the ones below. Note that the warning messages
are saved in file messages.txt.
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 "INGEST FROM FILE './ingest_data_excp'

FORMAT DELIMITED DUMPFILE './rejected.txt' MESSAGES './messages.txt' RESTART NEW 'job3'
INSERT INTO sales"

SQL2901I The ingest utility completed at timestamp "01/06/2012

18:01:14.788771". Number of errors: "2". Number of warnings: "0". Message
file: "./messages.txt".
As the result shows, 2 of the records were rejected. The exact errors are saved in
/home/db2inst1/Documents/LabScripts/CDI/messages.txt.
3. Issue the following command to view the generated messages in messages.txt.
gedit messages.txt &
4. It is stated that record at line 10 and at line 990 from the source file were invalid.

IBM Software
Figure 3 – Ingest utility messages file
5. The exact rejected records were saved in the dump file rejected.txt. So instead of looking through the source file for the
incorrect records, you can look into the dump file. Issue the following command to open file rejected.txt to view the
rejected records.
gedit rejected.txt &

IBM Software
Figure 4 – Ingest utility rejected records dump file
The dump file confirms the error messages in messages.txt. ‘2011-13-07’ is an invalid date and ‘one’ is not an integer.
6. In rejected.txt, change 2011-13-07 to 2011-12-07, and change one to 1.

7. Click File, then select Save.
8. Switch to your first terminal, issue the following command to ingest the corrected records.
db2 "INGEST FROM FILE './rejected.txt' FORMAT DELIMITED MESSAGES
'./messages.txt' RESTART NEW 'job4' INSERT INTO sales"
The command is executed successfully and a message similar to the following is displayed:
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 "INGEST FROM FILE './rejected.txt' FORMAT

DELIMITED MESSAGES './messages.txt' RESTART NEW 'job4' INSERT INTO sales"


19:14:03.110825"
9 Recovering Failed INGEST Command

An INGEST command is considered complete when it reaches the end of the source file or pipe. Under any other conditions, the
ingest utility considers the command incomplete. These can include:
• an I/O error while reading the input file or pipe

IBM Software
• a critical system error from the DB2 database system

• 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
If an INGEST command fails, you can choose to restart it by reissuing the command with the RESTART CONTINUE option. The
ingest utility would then start the operation from the last commit point. In this section, you will learn how this can be done with a
simulated abnormal termination of the command.
1. First, issue the truncate command below to clean up the table SALES.
2. In the first terminal, issue the following command to start ingesting data.
3. When the INGEST command starts executing, i.e. after the ingest utility starting timestamp is displayed, in the same
terminal, press ctrl+c on your keyboard until the command is interrupted.
A message notifying you that the command was interrupted and has exited is displayed.

FORMAT DELIMITED RESTART NEW 'job5' INSERT INTO sales"
SQL2914I The ingest utility has started the following ingest job: "job5".
^C^C^C^C^C^C^C^CSQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014
SQL2965I The following warning or error occurred issuing the SQL "INSERT"
statement on table "DB2INST1.SALES".
SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014
SQL2977I Because of the previous error, the ingest utility will exit.

SQL2902I The ingest utility completed at timestamp "01/06/2012

22:23:01.275383". Number of errors: "2". Number of warnings: "0".
4. As you have created the restart table in section Utility Configuration in this lab, information about the failed INGEST
command is saved in that table and will be used by the ingest utility to restart the command. You can verify this by
doing a SELECT on table SYSTOOLS.INGESTRESTART. In our case, a record for job with ID ‘job5’ should be stored.
db2 'SELECT * FROM SYSTOOLS.INGESTRESTART'

IBM Software
5. Still in the first terminal, where you just run the failed INGEST command, reissue the command with the RESTART
CONTINUE option.
db2 "INGEST FROM FILE './ingest_data_200k' FORMAT DELIMITED RESTART CONTINUE
This time, the ingest utility should complete and return a successful message. Note that the total number of inserted
records from both INGEST commands equals the total number of records in the source file ingest_data_200k, which is
200,000 records.

FORMAT DELIMITED RESTART CONTINUE 'job5' INSERT INTO sales"
SQL2914I The ingest utility has started the following ingest job: "job5".


22:28:45.557416"
10 Data Manipulation with Ingest Utility

The ingest utility allows DML operations to be performed on a target table using a SQL-like interface without locking the 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.
Let’s go through a simple example to demonstrate this capability by increasing the products inventory in the INGEST database.
1. Take a look at the data currently in table INVENTORY by issuing the SQL query below in your first terminal:
db2 'SELECT * FROM INVENTORY'
The query should return results similar to the following:
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 'SELECT * FROM INVENTORY'
PID QUANTITY LOCATION

---------- ----------- -------------------------------------------------------------------
-------------------------------------------------------------
100-100-01 5 -
100-101-01 25 Store
100-103-01 55 Store
100-201-01 99 Warehouse

IBM Software
2. The source file /home/db2inst1/Documents/LabScripts/CDI/ingest_inventory contains the data to update product

inventory. To view the content of the file, issue the following command:
gedit ingest_inventory &
Note that the file:

• uses | as the delimiter instead of a comma
• does not have the same column definitions as INVENTORY and the columns are in different order
• does not have all the products that exist in table INVENTORY
• has products that do not belong to INVENTORY
Figure 5 – ingest_inventory source file
What you want to update is the inventory of products with ID 100-101-01, 100-103-01 and 100-201-01. Their inventory
count should be changed by 10, 8, and -15 respectively
A script containing the command is already created to update the inventory count. Note that only the Quantity column of
the matching products should be updated.
3. You can verify the command by issuing the command below:
gedit ingest_ETL.sh &

IBM Software
Figure 6 - ingest_ETL.sh file

4. Execute the ingest_ETL.sh script to update the quantity column in the inventory table.
./ingest_ETL.sh
After the INGEST command finishes executing, a message like the following should be displayed.
Figure 7 - ingest_ETL script output
Note that, as expected, record at line 4 in file ingest_inventory was rejected, which is the product with ID 999-987-10.

IBM Software
5. Run the following query against table INVENTORY again, you’ll notice that the quantity for products 100-101-01, 100-
103-01, and 100-201-01 have been updated.
db2 'SELECT * FROM INVENTORY'
db2inst1@db2v10:~/Documents/LabScripts/CDI> db2 'SELECT * FROM INVENTORY'
PID QUANTITY LOCATION

---------- ----------- -------------------------------------------------------------------
100-100-01 5 -
100-101-01 35 Store
100-103-01 63 Store
100-201-01 84 Warehouse
11 Sample CDI Project

As mentioned in the introduction of this hands-on-lab, the ingest utility is capable of continuously ingesting data from input
sources into DB2 target tables with minimal impact on data concurrency. In this section, you will experiment this by using an
automated script to continuously ingest data until the source files are exhausted.
A script has already been prepared for this exercise. It performs the following tasks in order:
• Check the input directory for new source files
• Prepare an INGEST command for each source file found
• Execute the INGEST command
• Process the return code, move processed source files to a success directory or a failed directory
The script is located at /home/db2inst1/Documents/LabScripts/CDI/sample_project/ingest_files.sh. The script is self-explanatory

as it is extensively commented. Display the script content if you are interested in its implementation.
When the script is running, it does not generate any output to the standard output. However, all actions will be recorded in log
files stored at /home/db2inst1/Documents/LabScripts/CDI/sample_project/logs/, and in messages.txt stored at
/home/db2inst1/Documents/LabScripts/CDI/sample_project/.
Six sample data input files have been generated to use with the script. They contain data for the SALES table. These files are
located at /home/db2inst1/Documents/LabScripts/CDI/sample_project/input/, which is the directory where the script
ingest_files.sh will fetch new source files from.
As the script executes, successfully processed source files will be moved to /sample_project/input/success, and failed source
files will be moved to /sample_project/input/failed/.
As long as there exists a source file in /sample_project/input/, the script will automatically process it. When there is no more
source file to process, the script will exit. In this particular exercise, we demonstrate with only 6 input files, but it could be a
continuous stream of incoming data. Thus, with the INGEST utility, real-time data warehousing can be achieved at a high rate
while queries are running against your data warehouse.

IBM Software
1. Truncate table SALES as it will be used again as the target table.

2. In your first terminal, where you ran the previous INGEST commands, change directory to
/home/db2inst1/Documents/LabScripts/CDI/sample_project.
cd /home/db2inst1/Documents/LabScripts/CDI/sample_project/
3. Execute ingest_files.sh. Two arguments are required to run the script, database username and password. In our case,
they are db2inst1 and password.
./ingest_files.sh db2inst1 password
4. When the script finishes executing, all successfully processed source files are moved to
/home/db2inst1/Documents/LabScripts/CDI/sample_project/input/success. Open the logs or messages.txt for detailed
information regarding the INGEST operations.
In a production environment, you can use a similar setup to continuously process incoming input data and ingest it into your
target database while keeping your database available to concurrent user workloads. The ingest utility allows movement of real-
time data with minimal impact on data availability.
12 Summary
The ingest utility ingests data directly or from files and pipes into DB2 tables. It can run continually and thus it can process a
continuous data stream through pipes. 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.
In this lab, you were presented with an overview of ingest-related tasks, ingesting data, monitoring ingest operations, handling
data errors, restarting a failed ingest operation, manipulating data during ingest, and a sample on how to automate continuous
data ingest from source files to a target table.
13 Cleanup
1. To clean your environment after completing the exercise, execute the commands below. Use “password” as password.
su –
cd /home/db2inst1/Documents/LabScripts/CDI/setup
./cleanup.sh
cd /home/db2inst1/Documents/LabScripts/CDI/setup
./config.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
Workload Management
Hands-On Lab
IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................4
3 About this Lab......................................................................................................................................................................................5
5 Getting Started with Basic Monitoring ..............................................................................................................................................6
5.1 Running Activities ............................................................................................................................................................................................... 6
5.2 View and Send In-Memory Statistics .................................................................................................................................................................. 7
5.3 View Service Class Statistics Collected by the Event Monitor.......................................................................................................................... 10
5.4 View Activity Information................................................................................................................................................................................... 10
5.5 Reset the Database for the Next Section.......................................................................................................................................................... 11
6 Isolation Activities Using Service Classes and Workloads ..........................................................................................................11

6.1 Reset In-Memory Statistics and Enable Activity Event Monitor ........................................................................................................................ 11
6.2 Run Workloads ................................................................................................................................................................................................. 11
6.3 View Workload and Service Class Statistics..................................................................................................................................................... 12
6.4 View Activity Data Collected ............................................................................................................................................................................. 12
6.5 Reset for the Next Section ................................................................................................................................................................................ 13
7 Assigning Resources to Service Class and New Tiered Approach .............................................................................................13

7.1 Snapshot of Completing Work in the Current System ...................................................................................................................................... 14
7.2 Create Threshold for Service Class to Remap Work that Takes Longer .......................................................................................................... 15
7.3 Run Activities and View Changes in Mapping .................................................................................................................................................. 15
7.4 Reset for Next Steps......................................................................................................................................................................................... 16
8 Using Thresholds to Control Rogue Activities and Using the Threshold Violation Monitor.....................................................16
8.1 Create Workload and Threshold Violation Event Monitor ................................................................................................................................. 16
8.2 Run Some Activities.......................................................................................................................................................................................... 17
8.3 View the Threshold Violation Event Monitor ..................................................................................................................................................... 17
8.4 View Information of the Activity that Violated the Threshold............................................................................................................................. 18
8.5 Reset for the Next Section ................................................................................................................................................................................ 18
9 Differentiating Activities by Activity Type.......................................................................................................................................18

9.1 Enable Activity Event Monitor ........................................................................................................................................................................... 19
9.2 Create a Work Class Set and a Database Work Action Set ............................................................................................................................. 19
9.3 Run Activities and View Work Action Set Statistics .......................................................................................................................................... 19
9.4 View Activity Data Collected ............................................................................................................................................................................. 20
9.5 Reset for Next Steps and Disable Work Actions and Workloads ..................................................................................................................... 20
10 WLM Dispatcher.................................................................................................................................................................................20
10.1 Creating the CPU shares and CPU limits ......................................................................................................................................................... 21
10.2 Execute the TE Workloads to Stress the CPU.................................................................................................................................................. 22
10.3 Set the Instance Configuration to Enable WLM Dispatcher and CPU Limit ..................................................................................................... 25
Workload Management
IBM Software
10.4 CPU Shares Behaviour..................................................................................................................................................................................... 26

10.4.1 Hard CPU Shares ............................................................................................................................................................................................. 26
10.4.2 Soft CPU Shares............................................................................................................................................................................................... 27
10.4.3 Across Databases............................................................................................................................................................................................. 28
11 Summary ............................................................................................................................................................................................29
12 Cleanup...............................................................................................................................................................................................30
13 Appendix ............................................................................................................................................................................................30
13.1 Workloads ......................................................................................................................................................................................................... 30
13.2 Service Classes ................................................................................................................................................................................................ 31
13.2.1 Prioritization and resource control .................................................................................................................................................................... 31
13.2.2 Subclasses........................................................................................................................................................................................................ 32
13.3 Thresholds ........................................................................................................................................................................................................ 33
13.3.1 Threshold actions.............................................................................................................................................................................................. 34
13.4 Work classes & Work class sets ....................................................................................................................................................................... 35
13.5 Work actions & Work action sets ...................................................................................................................................................................... 36
13.6 Monitoring ......................................................................................................................................................................................................... 37
13.6.1 Real-time monitoring......................................................................................................................................................................................... 37
13.6.2 Historical monitoring ......................................................................................................................................................................................... 39
13.6.3 Historical Analysis ............................................................................................................................................................................................. 41
Workload Management
IBM Software
1 Introduction
In a typical database environment, there is a wide range of database activities that can flood the data server. There are short
transactional updates to a warehouse, (potentially) long reports, batch loading of data, applications calling stored procedures, to
name a few. These activities can come from numerous sources such as different users, business units, applications, multi-tier
servers, and even DB2 itself.
At times, all the database activity can cause the data server to perform unexpectedly. In order to keep control of the data server
workload, a comprehensive approach to workload management (WLM) is critical. An effective workload management
environment can be broken down into four basic stages: understanding business goals, identification of work that the goals are
established around, managing the workload to meet the goals, and monitoring the workload.
A good understanding of the business goals you are looking to meet for this system is important. For example, there are updates
to the database from cash registers around the country and it is critical to have a fast response time in order to prevent
customers from having to wait; you have a set of daily reports that have to be completed by 9 AM every morning for a review
meeting.
Once the goals are established, the next stage of WLM is the identification of activities that you will be trying to manage. The
wider the range of options for identification, the more likely you will be able to isolate the work you will be managing. Examples
of methods of identification include by source (e.g. an application or user ID that submitted a query) or by type (e.g. load
commands or queries that are read-only).
Figure 1: Stages of WLM.
The third stage of WLM is the management of activities in order to meet the business goals. This would include any mechanism
that can affect how an activity is executed. For example, CPU or I/O resources could be made available to a set of queries,
activity concurrency can be limited, or resource intensive activities could be simply stopped.
The final stage of WLM is the ability to monitor the state of activities on the data server. If you have taken the time to establish
business goals for the environment, then it is important to have the mechanisms in place to determine whether those goals are
met (e.g. if you have response time goals, then you need to be able to determine what the average response time is). It is also
important to have monitoring functionality available to identify problem areas and understanding what activities are running on
the system.
Monitoring information is also very useful in determining if there are modifications required to the identification or management
stages. It is a good idea to use some monitoring information before the initial configuration to validate the approach used in
identification. For example, the activity information available from the monitoring should contain enough details about its source
or type to help with the identification process.
Workload Management
IBM Software
In DB2, there are a number of new feature to help with managing the data server workload. The exercises in this lab are
designed to help you get more familiar with these features so that you can get an idea of the tools you have at your disposal to
build and effective workload management system.
The main design goals for DB2 WLM were to allow our customers to identify incoming work and isolate the work in an execution
environment so that resource consumption can be controlled in order to meet the business goals. Resources (such as CPU)
could be controlled explicitly or implicitly by controlling the work requests themselves.
There are a number of other WLM concepts discussed during the presentation which are covered in further detail in the
Appendix of this document.
2 Suggested Reading
Best Practices for DB2 for Linux®, UNIX®, and Windows®
Contains series of white papers, including one about WLM for Linux, Unix, and Windows
https://www.ibm.com/developerworks/db2/bestpractices/
DB2 Workload Manager for Linux, UNIX, and Windows

Contains a copy of the IBM Redbook on WLM for Linux, Unix, and Windows
http://www.redbooks.ibm.com/abstracts/sg247524.html
IBM DB2 Information Center for Linux, UNIX, and Windows

Contains full documentation for all features within WLM
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/index.jsp
Frequently Asked Questions about DB2 Workload Management

Contains FAQ for WLM
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.wlm.doc
/doc/c0052604.html
Business Intelligence and Performance Management

Contains information about IBM Data Warehousing and Business Intelligence
http://www-306.ibm.com/software/data/db2bi/
3 About this Lab

The exercises in this lab are designed to showcase features available in DB2 workload management. Note that this lab will not
necessarily cover the approach you would take to initially configure a data server using WLM. It is designed to walk you through
several features available and demonstrate the capabilities introduced with the WLM dispatcher, new in DB2 10. The lab
outlines the steps involved in setting up the environment and using the CPU scheduling technology.
Other sources of material that would be useful in understanding WLM can be found in the Suggested Reading section.
A more in-depth introduction about WLM concepts can be found in the Appendix of this document.

• DB2 10 VMware® Image
Workload Management
IBM Software
5 Getting Started with Basic Monitoring

In this section we demonstrate the basic types of monitoring information that can be obtained from the default workload and
service class objects.
In DB2, a default user workload (SYSDEFAULTUSERWORKLOAD) and a default user service class
(SYSDEFAULTUSERCLASS) are always created for each database.
These default objects can be used to take advantage of the workload management monitoring features without having to create
any user defined workloads or service classes. If no user defined workloads and service classes are created, all user activities
will be associated with these default objects.
Two event monitors, DB2ACTIVITIES and DB2STATISTICS were created already for use to collect activity information for
default workload and service class on activities and statistics respectively.
5.1 Running Activities

1. Right-click on the desktop and select Open in Terminal
Figure 2: Open a terminal to input terminal commands.
2. There are two scripts, located in the /home/db2inst1/Documents/LabScripts/WLM directory, which will be used to
generate workloads. These workloads are work1.db2 and work2.db2. These scripts must be executed in a terminal.
Open a terminal by right-clicking anywhere on the screen and select “Open Terminal”. Type the following commands
to execute the workloads. Each script will take a few moments to run so please be patient.
cd /home/db2inst1/Documents/LabScripts/WLM
db2 connect to WLM
db2 -o -tvf work1.db2
Workload Management
IBM Software
Attention: Please ensure the user is db2inst1 when executing these commands unless otherwise noted.
5.2 View and Send In-Memory Statistics

To retrieve the in-memory service class statistics that were collected, DB2 provides a table function named
WLM_GET_SERVICE_SUBCLASS_STATS, which appears in the view_inmem_stats.sql script in the following directory;
/home/db2inst1/Documents/LabScripts/WLM.
1. Open Data Studio by double clicking the icon on the desktop screen. Use the default workspace when prompted.
Figure 3: Icon on desktop.

2. Open the script view_inmem_stats.sql in the /home/db2inst1/Documents/LabScripts/WLM directory and run the
script against the WLM database.
Click menu File and then “Open File”. Navigate to the correct directory and select the script. Use the default
terminator – the semicolon “;”.
Figure 4: Open the script via the File menu "Open".
3. Connect to the WLM database by right-clicking anywhere inside the SQL Editor and choose “Use Database
Connection”. Select WLM and click Finish. Enter the credentials – user: db2inst1 password: password. Click
“Save Password” for future reference. After the connection is successfully established, run the script by pressing F5
while the cursor is inside the SQL Editor or press the “Run SQL” button.
Workload Management
IBM Software
Figure 5: Connect to a database and execute a script in an SQL Editor.

4. After running the script, open the Results pane, which is located in the bottom right hand corner of the screen. This
is where all of the results of the scripts will be displayed.
Figure 6: Results pane displaying results of script execution.

5. After viewing these statistics we can use WLM_COLLECT_STATS stored procedure to send the in-memory statistics
for all WLM objects to the active statistics event monitor.
Run the SQL in a fresh SQL Editor against the WLM database. For all future SQL statements that need a fresh SQL
Editor, simply clear the contents of the SQL Editor by selecting the old script and deleting the contents.
Workload Management
IBM Software
Figure 7: Execute the script in a fresh SQL Editor.
CALL SYSPROC.WLM_COLLECT_STATS();
6. Re-run the first script, view_inmem_stats.sql against WLM, to view the statistics. The stored procedure run in step 5
will reset all in-memory statistics.
Figure 8: All the statistics were reset.
Workload Management
IBM Software
5.3 View Service Class Statistics Collected by the Event Monitor
Next we will view the service class aggregate activity information that was collected after the work scripts were performed.
1. Execute the view_svcclass_stats.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against

the WLM database. Every time statistics are sent to the event monitor, a statistics record will be created for each
WLM object.
Figure 9: View service class aggregate activity.
5.4 View Activity Information

Information about every individual activity associated with the default user workload was also collected by the activities event
monitor by using the COLLECT ACTIVITY DATA clause on the default workload. This activity information can be viewed using
a query like the one below.
1. Run the view_activity_info.sql under the /home/db2inst1/Documents/LabScripts/WLM directory against the WLM
database.
A script executed in the terminal is what is denoted as “Command Line Processor” (CLP) command. The
CLIENT_APP_NAME column has “CLP work1.db2” since the workload was run via the CLP.
Figure 10: Commands run from the CLP.
Workload Management
IBM Software
5.5 Reset the Database for the Next Section

1. Execute the reset_dflt.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against the WLM
database, to prepare the database for the next section.
6 Isolation Activities Using Service Classes and Workloads

In this section of the lab we will demonstrate how to use some of the WLM monitoring features to determine the workload that
activities are being mapped to and get information about activities being run in a service class and under a workload.
As we saw in the previous sections, all activities in DB2 are assigned to a workload and run in a service class. If no user defined
service classes are created, activities are run in the default subclass, SYSDEFAULTSUBCLASS, under the default user service
class, SYSDEFAULTUSERCLASS, and if no user defined workloads are created, activities are run under the default user
workload, SYSDEFAULTUSERWORKLOAD.
Two service super classes were created: WORK1_SC and WORK2_SC. In addition, two workloads, WORK1_WL and
WORK2_WL are assigned respectively to each one of the super classes associated to the client app names “CLP work1.db2”
and “CLP work2.db2”.
6.1 Reset In-Memory Statistics and Enable Activity Event Monitor
1. Enable the event monitor for activities and reset the in-memory statistics by utilizing the WLM_COLLECT_STATS
stored procedure. Run this script in a new SQL Editor against the WLM database in Data Studio.
SET EVENT MONITOR DB2ACTIVITIES STATE 1;
CALL SYSPROC.WLM_COLLECT_STATS();
Figure 11: Enable event monitor for activities.
6.2 Run Workloads
1. Minimize Data Studio and return to the terminal. Execute the two workloads work1.db2 and work2.db2 in the
terminal. Please refer to section 5.1 for detailed instructions.
db2 connect to WLM
Workload Management
IBM Software
6.3 View Workload and Service Class Statistics
1. Return to Data Studio. Use the WLM_GET_WORKLOAD_STATS table function to view workload statistics to
determine which workload the applications are being associated with. Run the script in a fresh SQL Editor against
the WLM database.
SELECT SUBSTR (WORKLOAD_NAME,1,22) AS WL_DEF_NAME,
WLO_COMPLETED_TOTAL, CONCURRENT_WLO_ACT_TOP
FROM TABLE (WLM_GET_WORKLOAD_STATS (CAST (NULL AS VARCHAR (128)), -2))
AS WLSTATS;
Figure 12: Applications associated to workloads.
2. Clear the SQL editor and run the following script to use the WLM_GET_SERVICE_SUBCLASS_STATS table
function which shows the service class the activities are being run under.
Notice the activities that completed under the WORK1_SC due to the WORK1_WL workload mapping and activities
completed under the WORK2_SC due to the WORK2_WL mapping.
SELECT VARCHAR (SERVICE_SUPERCLASS_NAME, 30) SUPERCLASS,
VARCHAR (SERVICE_SUBCLASS_NAME, 23) SUBCLASS,
COORD_ACT_COMPLETED_TOTAL COORDACTCOMP
FROM TABLE (WLM_GET_SERVICE_SUBCLASS_STATS('', '',-1)) AS T;
Figure 13: Results of the WLM_GET_SERVICE_SUBCLASS_STATS table function.
6.4 View Activity Data Collected
Next we will query the activity table for information on the activities that have been run. We will notice that only activities from
both work1.db2 and work2.db2 have been collected since data collection was specified during the definition of the workloads.
Workload Management
IBM Software
1. Clear the editor and run the following statement against the WLM database to view the activity data collected.
SELECT SUBSTR (WORKLOADNAME, 1, 20) WL_DEF_NAME,
SUBSTR (APPL_NAME,1,20) APPL_NAME,
SUBSTR (ACTIVITY_TYPE, 1, 10) ACT_TYPE
FROM SYSIBM.SYSWORKLOADS, ACTIVITY_DB2ACTIVITIES
WHERE WORKLOADID = WORKLOAD_ID;
Figure 14: Activity data collected.
6.5 Reset for the Next Section
1. Run the reset_monitor.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against the WLM
database to reset the statistics for the next section.
7 Assigning Resources to Service Class and New Tiered Approach

As stated in earlier sections, system resources are allocated and controlled by using service classes. With priority aging, the
priority of an activity can be changed by moving the activity from one service class to another service class. Activities are moved
when a threshold with a REMAP ACTIVITY action is violated, that is, they are moved based upon a pre-determined use of a
specific resource such as processor time or rows read.
After an activity is mapped to a new service class, it continues to run with the new resource constraints applied; therefore, we
now have the ability to remap an activity from one subclass to another within the same service class and allocate a higher/lower
CPU/IO priority as desired.
A service super class named WORK_RE_MAP was created with buffer pool priority set to low. This controls the buffer pool
priority of pages fetched by activities in this service class. Pages fetched with higher buffer pool priority are less likely to be
swapped out than pages fetched with lower priority.
In addition, a service class HIGH_PRI, created under the super class WORK_RE_MAP has an agent priority of -10. This means
that the relative processor priority of queries is much higher than others (in a relative sense, since negative values on
UNIX/LINUX specifies a higher priority). In addition we are also collecting aggregate request data for this subclass in order to be
able to view CPU execution times later.
Lastly, a workload WORKLOAD_REMAP maps all queries coming from the remap_work.db2 workload.
Workload Management
IBM Software
Figure 15: Pictorial depiction of service classes and workloads created.
7.1 Snapshot of Completing Work in the Current System
Run some work on the database by executing the remap_work.db2 script; however, while the workload is running, try opening
and closing several applications (for example, double click the Firefox icon and close the browser then opening other program
and closing them). By doing so, one can gauge the reaction of the system, whether it be sluggish, or normal.
1. Execute the remap_work.db2 workload against the WLM database from the terminal. Please refer to section 5.1 for
detailed instructions.
db2 -o -tvf remap_work.db2
You should notice that everything seems to open and close alright. This is because everything is being executed in
the SYSDEFAULTSUBCLASS, which does not have the AGENT PRIORITY increased.
2. Return to Data Studio and use the WLM_GET_SERVICE_SUBCLASS_STATS function to ensure that everything
was properly executed.
Execute the view_remaps.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against the WLM
database.
Figure 16: All 5 queries were executed within the SYSDEFAULTSUBCLASS.
Workload Management
IBM Software
7.2 Create Threshold for Service Class to Remap Work that Takes Longer
We will now create the threshold that will remap any activities that take longer than 1 second of CPU time to remap to the
HIGH_PRI subclass within the WORK_RE_MAP service class.
1. Execute the create_remap_thres.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against the

WLM database. The script will add an additional service class to remap activities that take longer than 1 second of
CPU time.
Figure 17: Pictorial depiction of the WORK_RE_MAP service class.
7.3 Run Activities and View Changes in Mapping

Investigate the new mappings just created by running the workload remap_work.db2 again. While the workload is running, open
and close several applications, such as Firefox, to once again gauge the response of the system. It should be noted that the
system should appear to be slightly slower compared to the first time this was done. This is due to the fact that AGENT
PRIORITY was increased for the HIGH_PRI subclass and therefore, the queries are using more of the CPU.
1. Before continuing, reset the statistics to ensure a fresh start. Execute the reset_monitor.sql script in the
/home/db2inst1/Documents/LabScripts/WLM directory against the WLM database from Data Studio.
2. Minimize Data Studio and move to the terminal. Execute the remap_work.db2 workload against the WLM database
from a terminal. Please refer to section 5.1 for detailed instructions. During this time, open and close several
applications to view the response of the system.
db2 -o -tvf remap_work.db2
3. Use the same view_remaps.sql script open within the SQL editor. If closed, Re-open the script from the following
directory; /home/db2inst1/Documents/LabScripts/WLM and review the results to see the changes that have occurred.
Even though the response of the system was slightly more sluggish, the overall time the query took was reduced. In
addition, there should be queries that were remapped into the HIGH_PRI subclass.
Workload Management
IBM Software
Figure 18: Remapped workload.
7.4 Reset for Next Steps
We will drop the threshold since we are no longer using it during the lab and clean up the event monitor table, and call
WLM_COLLECT_STATS() to reset the statistics.
1. Execute the script reset_remap.sql in the /home/db2inst1/Documents/LabScripts/WLM directory against the WLM
database to accomplish the reset.
8 Using Thresholds to Control Rogue Activities and Using the Threshold

Violation Monitor
Thresholds are used to detect resource misuse or the beginning of system overload. They help establish limits over the
consumption of a specific resource. If a threshold is violated, a specified action can be triggered. The support actions are:
1. STOP EXECTUION – Stop processing the activity that caused the threshold to be violated
2. CONTINUE – Continue processing
3. Collect information about the activity that violated the threshold – this action can be combined in conjunction with the
CONTINUE or STOP EXECTUTION actions.
Regardless of whether an activity that violates a threshold is stopped or allowed to continue running, a record of the violation is
written to an active THRESHOLD VIOLATIONS event monitor (assuming one is defined in advance). As we will see, the record
contains information such as which threshold was violated, the time of the violation, and the threshold action.
In the following section, it will be demonstrated how thresholds can be used to detect or prevent rogue (“runaway”)
queries/activities which use unexpectedly high amount of resources.
8.1 Create Workload and Threshold Violation Event Monitor

Create and enable a write-to-table event monitor that will be used to capture the threshold violation information and a workload
that will map all activities run from the workth.db2 script. The work1_sc service class already exists and it was used in section 6.
Create a workload such that all activities run from the workth.db2 will get mapped to the work1_sc service class. Then create
two thresholds for the service class that will help eliminate rogue queries.
Workload Management
IBM Software
1. Execute the create_threvio.sql script found in the /home/db2inst1/Documents/LabScripts/WLM directory against

the WLM database within Data Studio.
8.2 Run Some Activities

Next run some work activities against the database, some of which violate the threshold upper bound defined in the previous
step.
1. Return to the terminal. Execute the workth.db2 workload against the WLM database in a terminal. Please refer to
section 5.1 for detailed instructions.
db2 -o -tvf workth.db2
Figure 19: Statements that violate the thresholds defined will fail with an error of SQL4712N/SQL STATE 5U026.
8.3 View the Threshold Violation Event Monitor

Since every threshold violation is collected by the THRESHOLD VIOLATIONS event monitor, you can query this information by
issuing regular SQL statements against the threshold violation monitor table.
1. Navigate back to Data Studio and execute view_threvio.sql script found in the
/home/db2inst1/Documents/LabScripts/WLM directory against the WLM database to view the event monitor.
Workload Management
IBM Software
Figure 20: Threshold violation event monitor query results.
8.4 View Information of the Activity that Violated the Threshold

Activity information is collected for any activity that violates a threshold that is defined with a COLLECT clause. The
view_viol_act.sql script below contains this command.
1. Execute the view_viol_act.sql script found in the /home/db2inst1/Documents/LabScripts/WLM directory against the
WLM database to view the results of the script.
Figure 21: The activities that violated the th_estcost threshold are not shown because the COLLECT ACTIVITY
DATA clause was not specified so no activity data was collected.
8.5 Reset for the Next Section

Disable the event monitors that were enabled and clean up the activity event monitor tables and the threshold violation table.
1. Execute the cleanup_thres.sql script found in the /home/db2inst1/Documents/LabScripts/WLM directory against the
WLM database to prepare for the next section.
9 Differentiating Activities by Activity Type

Work action sets are used to apply an action to an activity based on what the activity is doing rather than who submitted it (as is
done with workloads).
The following section demonstrates how a work action set can be used to:
• Collection information about activities of a certain type

• Apply a threshold to activities of a certain type
• Isolate Activities of a certain type by mapping them to a specific service subclass
Actions can be applied to either:
• Database activities of a certain type (using a database work action set)

• Activities of a certain type in a particular service class (using a service class work action set).
Workload Management
IBM Software
Attention: There are other actions that can be applied, such as collecting statistics for activities of a certain type that are not
covered in this task which can be found in the Appendix.
9.1 Enable Activity Event Monitor
1. Enable some of the event monitors for activities that were created previously. Execute the command in a fresh SQL
Editor against the WLM database. For detailed instructions, refer to Section 5.2.
SET EVENT MONITOR DB2ACTIVITIES STATE 1;
9.2 Create a Work Class Set and a Database Work Action Set
Create a work class set containing work classes that will represent the specific types of activities we are interested in. This work
class set will be used in conjunction with work action sets to perform actions on the selected types of activities. Below is an
example that creates a work class set containing work classes of all possible types in DB2; however, specific activity types of
work class sets could be created to only contain that one work class.
In order to perform a particular action on activities of a specific type (such as apply a threshold or collect activity information) a
database work action set could be used. Create a work action set at the database level that contains work actions for the
specific work class representing the type of activities that should be isolated. For this example, assume they want to collect
activity data for all DDL, READ and LOAD activities that run on the system. In addition, stop any large read activity from running.
For this task, a large read activity will be defined as any select statement that has an estimated cost (in timerons) of greater than
10000.
1. Execute the create_was_wcs.sql script in the /home/db2inst1/Documents/LabScripts/WLM/ directory against the

WLM database. This will create the work class set, and work action set described above and defined below.
Work Action name Work Class Work Action Type Details

collect_load_wa load_wc ACTIVITY DATA WITH DETAILS AND VALUES
COLLECTION
collect_ddl_wa ddl_wc ACTIVITY DATA WITH DETAILS AND VALUES
COLLECTION
collect_read_wa read_wc ACTIVITY DATA WITH DETAILS AND VALUES
COLLECTION
stop_large_read_wa read_wc THRESHOLD WHEN ESTIMATEDSQLCOST > 10000 STOP
EXECUTION
9.3 Run Activities and View Work Action Set Statistics
1. Generate some activities by running the work1.db2 and work3.db2 scripts in the
/home/db2inst1/Documents/LabScripts/WLM directory. Open a terminal and execute the scripts. Refer to section 5.1
for more detailed instructions.
db2 connect to WLM
Workload Management
IBM Software
2. Use the WLM_GET_WORK_ACTION_SET_STATS table function to access the work action set stats in memory to
get the number of times specific activity types have been run. Open and execute the view_wa_stats.sql script in the
/home/db2inst1/Documents/LabScripts/WLM directory against the WLM database in Data Studio. Notice that running
the query shows only the load_wc, read_wc, and ddl_wc since they are the only ones that have an applicable work
action. The remaining activities are counted under the wildcard ‘*’.
Figure 22: WLM_GET_WORK_ACTION_SET_STATS table function query results.
9.4 View Activity Data Collected

Information about individual DDL, READ and LOAD activity was collected by the activities event monitor, due to the specification
of the COLLECT ACTIVITY DATA work action that was applied to the ddl_wc, read_wc, and the load_wc work classes. To get
some information about each activity such as the activity text and what service class it ran under, perform the query provided in
get_more_wa_info.sql script in Data Studio.
1. Execute the get_more_wa_info.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory against the
WLM database. Notice that one of the activities has an SQLCODE of SQL4712. This indicates execution of the
activity was stopped due to a threshold violation. The threshold defined for the stop_large_read_wa work action will
prevent any SELECT statement with an estimated cost of greater than 10000 timerons from executing.
Figure 23: Some statements prevented due to their estimated cost being greater than 10000 timerons.
9.5 Reset for Next Steps and Disable Work Actions and Workloads
1. Execute the script reset_before_histo.sql script in the /home/db2inst1/Documents/LabScripts/WLM directory
against the WLM database to disable the work actions and workloads in Data Studio.
2. Close Data Studio.
10 WLM Dispatcher
The WLM Dispatcher is an instance level CPU scheduling technology inside of DB2. This allows for the control of CPU
resources allocated to various service classes. The resources are controlled by hard CPU shares, soft CPU shares and/or CPU
limits.
Workload Management
IBM Software
In this exercise, 3 service classes – SC_WD1 with 6000 hard CPU shares, SC_WD2 with 6000 soft CPU shares, and SC_WD3
with 6000 hard CPU shares are used; furthermore, the aforementioned classes reside under a super class SC_SUPERCLASS
with a CPU limit of 15%. All of these will be created within the WLMD database. Attach the W_WD1, W_WD2, and W_WD3
workloads to the service classes SC_WD1, SC_WD2, and SC_WD3 respectively. This is summarized within the diagram below.
Attention: Please note the databases addressed are now WLMD and WLMD2, and not WLM.
Figure 24: Visual depiction of the service classes.
Note the split between the two databases – this is using the assumption that there are only two competing service classes – and
that they are both created using the default values of 1000 shares. If there were no competing shares, SC_WD1, SC_WD2 and
SC_WD3 would be free to take 100% and spilt it amongst themselves for entitlement.
10.1 Creating the CPU shares and CPU limits
3. Navigate back to the terminal. Connect to the WLMD database and create all of the objects mentioned above by
executing the script create_WMD.sql found in the /home/db2inst1/Documents/LabScripts/WLM directory.
db2 connect to WLMD
db2 -tvf create_WMD.sql
Figure 25: Execute the create_WMD.sql script.
Attention: As this exercise is extremely sensitive to hardware and other processes running, do not open any other program,
unless instructed, to conserve resources.
Workload Management
IBM Software
10.2 Execute the TE Workloads to Stress the CPU
1. Start the Technology Explorer (TE) by double-clicking the TE shortcut icon on the desktop.
2. Once inside, connect to the WLMD databases by double-clicking the row with the corresponding databases. Enter
“password” as the password when prompted; leave the rest of the fields as default.
Figure 26: Enter "password" to connect to the database.
3. Connect to the WLMD2 in the same fashion; the password is again “password”.
4. Once connected, both of the databases should have a light blue checkmark beside them to signify they have been
authenticated.
Figure 27: Connected to both WLMD and WLMD2.

5. Click “Tools” from the File menu just below the browser toolbar. Select “Workload MultiUser Driver” from the drop
down list.
Workload Management
IBM Software
Figure 28: Open Workload MultiUser Driver.

6. First click the WL1 workload from the list, and click the status (icon represented by concentric circles). Once it loads,
click the large green play button slightly to the right of the workload list. The workload graph should be moving to
signify that there indeed is a workload running.
Figure 29: Workload WL1 running.
Workload Management
IBM Software
7. Minimize the browser by going up and clicking the small horizontal bar.
Figure 30: Minimize the browser.

8. Open a terminal and execute the cpu_util_all_sc.sql script in the /home/db2inst1/Documents/LabScripts/WLM
directory. This script will show how much total CPU power was used by a certain service class for 10 seconds
represented by a percentage. The SC_WD1 workload should have used some CPU power, since it is the only
workload running. This script uses the MON_SAMPLE_SERVICE_CLASS_METRICS table function to return the
values.
Note: Wait 10 seconds for this query to respond – it takes values over 10 seconds to report. Maximize the terminal window
for better readability.
db2 connect to WLMD

db2 -tf cpu_util_all_sc.sql
Figure 31: CPU utilization by each service class.

9. Return to the browser and repeat step 6 to start both the WL2 and WL3 workloads. The machine should become
slightly sluggish, be patient with the system as it is being worked quite hard at this point.
Figure 32: Start WL2 and WL3 as well.

10. Return to the terminal and execute the cpu_util_all_sc.sql script again. This time the SC_WD1, SC_WD2, and
SC_WD3 service classes should all have CPU utilizations.
Hint: Press the up arrow on the cursor pad to show the last executed command.
Workload Management
IBM Software
Figure 33: Notice the utilization is over the defined limit.

11. There is a slight problem at the moment – the workloads are not limiting! A quick check of the instance configuration
will show that indeed, the WLM dispatcher is not enabled at the moment.
db2 get dbm cfg | grep 'WLM dispatcher'
Figure 34: Dispatcher not enabled.

12. Stop all of the workloads – by entering the browser and clicking the big red circle with an X in it. It will reset all the
workloads. Once they are reset – they should return to being empty bulls-eyes (an empty circle within a circle).
Figure 35: Stop the workloads.
10.3 Set the Instance Configuration to Enable WLM Dispatcher and CPU Limit
1. Return to the terminal and enable WLM dispatcher and set the minimum utilization to 2%. Once updated, restart
DB2 to make the changes take effect and reconnect to the database WLMD.
db2 update dbm cfg using wlm_dispatcher yes
db2 update dbm cfg using wlm_disp_cpu_shares yes
db2 update dbm cfg using wlm_disp_min_util 2
db2stop
db2start
db2 connect to WLMD
db2 get dbm cfg | grep 'WLM dispatcher'
Workload Management
IBM Software
Figure 36: Setting the appropriate settings.

2. Restart WL1 and WL2 from the browser by clicking the empty bulls-eye and clicking the large green play button for
both workloads.
Figure 37: Restart WL1 and WL2.

3. Return to the terminal and execute the cpu_util_all_sc.sql script again. The workloads are now limited to 15% and
as evenly split as possible. The discrepancy is due to the fact that we are taking values in points in time, over a
longer period of time; it will be noticeable that the average indeed is spilt with the values specified.
Figure 38: The limit is being enforced, and so are the shares.
10.4 CPU Shares Behaviour
10.4.1 Hard CPU Shares

SC_WD1 was created with hard shares; this means that even if there are resources available, as long as there is a competing
workload it will not be able to utilize those free shares. A competing workload in this case is defined as a workload that will take
more than 2% of CPU power as noted when the WLM_DISP_MIN_UTIL attribute was set to 2.
1. Navigate back to Technology Explorer. Tweak the workload by clicking into the WL2 workload and click the icon
beside CLIENT THINK TIME. Type “60ms” into the box to slow the workload down a bit. This should still keep it
above the 2% utilization but due to many factors it may or may not. If required to tweak the workload to reach
desired results, the smaller the number – the higher the workload (smaller breaks between transactions). The graph
should start to dip to signify the reduction in the workload.
Workload Management
IBM Software
Figure 39: Adjust the workload.
Note: Due to the dependency on hardware configuration, it may require a bit of tweaking in order to reach desired values.
2. Return to the terminal and remove the CPU limit by setting the limit to 100% and decreasing the number of hard
shares allocated to WL1 to 500.
db2 "alter service class SC_SUPERCLASS CPU LIMIT 100"
db2 "alter service class SC_WD1 under SC_SUPERCLASS HARD CPU SHARES 500"
3. Execute the cpu_util_all_sc.sql script again. Notice the WL2 is not using the full 7.5% allocated to the service class;
however, due to the fact that WL1 was defined using hard shares, it cannot utilize the free shares that are already
available. This is shown via the fact it cannot allocate more than its ESTIMATED_CPU_ENTITLEMENT. The CPU
entitlement is calculated based on the number of shares the service class has, divided by the number of shares that
are in contention.
Note: Workloads under the minimum utilization are not considered contending workloads and will not contribute to the calculation
Figure 40: Cannot exceed defined limit even with resources available.
10.4.2 Soft CPU Shares

In this scenario, SC_WD2 has been created with soft shares (the roles are reversed) and it will be demonstrated that soft shares
allow for the service class to go beyond the defined limit even if there is a competing workload – as long as there are resources
available.
1. Increase the workload from WL2 by setting the CLIENT THINK TIME value to 8ms and decrease the workload of
WL1 by setting the CLIENT THINK TIME value to 60ms.
Attention: Ensure that the setting CLIENT THINK TIME value is kept at 60ms for workload WL1
2. Return to the terminal and set the soft shares of SC_WD2 to 500, and the hard shares of SC_WD1 to 6000.
db2 "alter service class SC_WD2 under SC_SUPERCLASS SOFT CPU SHARES 500"
Workload Management
IBM Software
db2 "alter service class SC_WD1 under SC_SUPERCLASS HARD CPU SHARES 6000"
3. Execute the cpu_util_all_sc.sql script again. As SC_WD2 is using soft cpu shares, it is allowed to utilize the free
resources that SC_WD1 freed up and its utilization exceeds past its ESTIMATED_CPU_ENTITLEMENT.
Figure 41: May exceed allocated limit when resources available.
10.4.3 Across Databases
As noted, WLM Dispatcher is an instance level control; therefore, it is possible to control service classes defined in other
databases relative to this one as well.
1. Execute the script create_WMD2.sql found in the /home/db2inst1/Documents/LabScripts/WLM directory against the
WLMD2 database. This script will create a service class “SC_SUPERCLASS_LIM” associated to the WL4 workload
with 800 hard CPU shares.
db2 connect to WLMD2
db2 -tvf create_WMD2.sql
Figure 42: CPU entitlement assuming all shares are fully utilized.
2. Navigate to TE and stop the workload WL2.

3. Start the WL4 workload.
Workload Management
IBM Software
Note: Due to high CPU usage, the system may now appear sluggish.
4. You should have only WL1 and WL4 running at this point.
5. Execute the cpu_util_all_sc.sql script again and take a look at the values. The service class
SC_SUPERCLASS_ LIM is not able to utilize more than 44% of the CPU resources, which is the maximum CPU
entitlement for this service class.
Figure 43: Controlling the CPU usage over different databases.

6. Return to the browser and stop WL1 by clicking the big red X again.
7. Return to the terminal and execute the cpu_util_all_sc.sql script again and now it is shown that the
SC_SUPERCLASS_LIM is taking more than 44% of resources available. This is due to the fact that there are no
more competing service classes and SC_SUPERCLASS_LIM may take all available resources required.
Figure 44: May now fully utilize available resources due to no more competing service classes.
8. Stop WL4 now and close TE (the browser).
11 Summary
There were many different concepts introduced and demonstrated in this lab. The use of various event monitors, views, and
table functions allow for the user to be able to see what is going on within the database. Armed with that information, one could
set up various thresholds, work actions and other objects to control and contain different actions within the database to ensure
that the workload intentions are defined by the user, rather than dictated by the workload.
The CPU scheduling technology, introduced in DB2 10 allows for the control of the CPU usage using hard CPU shares, soft
CPU shares and CPU limits. The WLM dispatcher allows the user to reside within the comfort of DB2 while having the capability
to direct workloads and resource consumption.
Workload Management
IBM Software
This lab only scratched the surface of workload management, providing an introduction to several features within DB2’s
Workload Management and the newly added WLM Dispatcher. For further insight into this valuable topic refer to the appendix
and suggested readings..
12 Cleanup
1. To cleanup this lab, execute the following script. The password is “password”.
su –
cd /home/db2inst1/Documents/LabScripts/WLM/setup
./cleanup.sh
2. If you would like to redo this lab, please execute the following script in a terminal as root.
cd /home/db2inst1/Documents/LabScripts/WLM/setup
./config.sh
13 Appendix
The following will provide you with an overview of the various concepts within WLM used throughout the lab above and
discussed in the accompanying presentation.
13.1 Workloads
A workload can be defined to identify incoming work based on its source so that it can later be properly managed. Connections
are assigned to a workload based on the following connection attributes:
Attribute Description
application name The name of the application that is connected to the database.
system The authorization ID that is connected to the database.

authorization ID
session The authorization ID that is set in the current session of the database
authorization ID connection. Useful when a connection is maintained for a long period of
time but user ID attributes need to change.
group of session The group to which a session authorization ID belongs to.

authorization ID
Workload Management
IBM Software
role of session The DB2 role to which the session authorization ID belongs to.
authorization ID
client user ID The client user ID. Useful in an environment where an application server
or tool uses connection pooling to connect to a database with a single
user ID representing a large number of clients.
client application The client application name. Useful when the application that established
name the database connection did so on behalf of the client application.
client workstation The client workstation name. Useful when you need to isolate work from
name a specific workstation.
client accounting A user-defined accounting string. Useful when you need to isolate work
string based on your own custom criteria.
The workload is evaluated and assigned at the unit of work (UOW) boundary, at which time a new workload occurrence is
started. A workload occurrence consists of one or more units of work within a database connection that are associated to a
workload. It is quite likely that multiple connections have similar attributes that result in multiple workload occurrences based on
the same workload definition. Workload re-evaluation occurs at the beginning of each UOW in the event that the value of a
connection attribute or the workload definition itself changes during the UOW. This re-evaluation might result in the connection
being associated with a new workload, creating a different workload occurrence. It is possible that multiple workload definitions
include a given activity. In this case, the first workload defined that includes the activity is the one that is used. You can
therefore manipulate the order of workload definitions to ensure that the proper workload is chosen.
In DB2, if no custom-defined workload is found during workload evaluation, all database connections are assigned to the default
workload.
13.2 Service Classes

A service class is defined within an execution environment in which work can run. This environment can include available
resources and various execution thresholds.
When you define a workload, you must indicate the service class where work associated with that workload runs. There is
always a default service class, which ensures that all data server work executes inside a given service class.
13.2.1 Prioritization and resource control
When you create a service class, you can define a number of resource controls:
Workload Management
IBM Software
Control Description
Agent This control sets a CPU priority level for the agent threads running within a
Priority service class. This priority flows through to the operating system as a relative
(delta) priority to other threads and processes running in the class.
Prefetch For heavy I/O work involving prefetching, this control is useful for mapping work
Priority to one of three prioritized prefetch queues (high, medium, and low).
Buffer pool This control allows sets the buffer pool priority of pages fetched by activities in
Priority this service class. Pages fetched with higher buffer pool priority are less likely to
be swapped out than pages fetched with lower priority.
External This control allows a workload to have some of its resources controlled by an
WLM tag external workload manager such as the AIX Workload Manager (currently, the
only supported external workload manager). The tag flows through the agent to
the external workload manager and maps to a resource group defined with the
manager.
13.2.2 Subclasses
You can divide a service class into multiple service subclasses. Define these in cases where the granularity found in a service
class does not adequately map to the resource goals that you need for that service class. For example, if the Operations and
Finance departments share a data server, you could define two service classes to account for resource allotment for each
department. Also, if the Operations department regularly runs custom reports and batch ETL processing, and the batch jobs
need to be constrained so they do not interfere with the reports, you could define service subclasses to which you assign the
batch and ETL workloads. Each subclass could define appropriate resource controls so that the custom Operations reports have
priority.
The service super class remains the highest tier for work, but service subclasses are the only place where activities run. This
distinction is important to note, especially when you look at some of the information available through the workload management
monitoring features discussed later on. Each service super class has a default service subclass defined to run activities that you
do not assign to an explicitly defined subclass. Additionally, you can define only a single level of subclasses (that is, you cannot
define a subclass under another subclass, only under a service super class).
The following figure is an example of a custom workload management configuration using workloads and service classes:
Workload Management
IBM Software
As user requests to enter the data server, they are identified as belonging to a given workload and assigned to a service super
class or subclass.
13.3 Thresholds
Resource controls are one way to try to meet your defined goals. At times, work comes in that might exceed your normal
expectations (for example, a query that is returning hundreds of thousands of rows), consuming valuable resources at the
expense of all of the other work running on the system. Threshold objects could be created to look for these types of exceptions
and trigger actions if thresholds are exceeded.
The following table provides the list of thresholds that can be defined:
Threshold Used to Detect Description
Elapsed Time Jobs that are taking abnormally long to Controls the amount of time that any given activity can spend from
complete. submission to completion in the DB2 data server (execution time
and idle time).
CPU Time in Jobs that are taking abnormally long to Controls the maximum processor time across service subclass
Seconds complete.
Idle Time Inefficient use of data server resources and Controls the amount of time that a connection idles, not working on
unexpected wait conditions. behalf of user requests. Use to detect
Estimated Cost Potentially resource-heavy SQL (identifying Controls DML activities that the DB2 optimizer determines to have a
poorly written SQL). large estimated cost.
Workload Management
IBM Software
Rows Returned When the amount of data returned exceeds a Controls the number of rows returned when executing SQL.
reasonable volume.
SQL Rows Read In Amount of data read exceeds a reasonable Controls the number of rows read when executing various SQL
Seconds volume. statements.
Temporary Space Disproportionate amount of temporary space Controls the amount of temporary table space a given activity can
usage. consume on a partition.
Aggregate Temporary Disproportionate amount of aggregate Controls aggregate usage of temporary table space for activities
Space temporary space usage. across service classes
Concurrent Workload Large amount of work from a specific source Controls the number of active occurrences of a workload that can
Occurrences overwhelming a data server. run on a coordinator partition at the same time.
Total Database Partition becoming overloaded with Controls the number of database connections to a given partition
Partition Connections connections. that can be established at the same time.
Total Service Class Partition connections linked to a service class. Controls the number of database connections to a given partition for
Partition Connections work executing within a given service class at the same time.
Concurrent Workload Workload from dominating overall data server Controls the number of individual activities that can run within a
Activities activity. workload.
Concurrent Database Limit work within an individual workload Controls the number of individual activities that can run within a
Activities occurrence. workload occurrence.
CPU Cost in Seconds Limit work Controls the maximum amount of combined user and system
processor time that an activity can use on a particular database
partition while the activity is running.
These thresholds can be divided into different categories. The first set of thresholds deal with activity limits, where the controls
pertain to the impact that an activity can have on how the data server is running. Excess time, abnormally high volumes of data
returned, and abnormally high amounts of resources consumed are warning flags that potentially troublesome activities could be
using up resources that they are not supposed to. The next set of thresholds deals with concurrency control and is meant to look
for cases where you need to consider limiting the number of certain activities running at the same time to reduce their impact on
the data server.
13.3.1 Threshold actions
The kind of actions that can be taken when a threshold is exceeded depends on the threshold itself.
Collect data
When a threshold is exceeded, there is always some form of data collected. By default, the fact that a threshold was exceeded
is recorded in the event monitor. You might want more detail, though, so on each threshold definition, you can request that more
Workload Management
IBM Software
data be captured, such as information about individual activities, the statement text, the compilation environment, and even the
input data values.
Stop execution
A common action when a threshold breach occurs is to stop the activity from executing. In this case, an error code is returned to
the submitting application indicating that the threshold was exceeded.
Continue execution
In some cases, stopping the execution of the activity is too harsh a measure. It might be better for business to allow the activity
to continue to run and collect the relevant data for a DBA to perform future analysis to determine how to prevent this condition
from happening again. In this case, no error code is returned to the submitting application.
Queue activities
In some cases, there is the option to queue activities if there is too much work running. Rather than stopping activities (or
connections), you can queue them. Queuing can be quite an effective method of resource control and throughput management
with very little impact to the submitting applications (because they wait for the activity to complete and are unaware the activity is
queued). You can specify the maximum size of the queue, and if the queue size is exceeded, the stop execution action takes
effect.
Queuing makes sense only for thresholds that are considered predictive, where an action decision can be made before activity
execution starts. This includes some of the concurrency thresholds: in particular, the total service class partition connections and
the concurrent database activities. If an activity is queued, no error code is returned to the submitting application. The application
waits as if the activity were running until the activity is taken off the queue for execution and eventually completes.
For example, consider the case where you set a threshold to allow a maximum of 500 concurrent database activities plus 100
that can be queued and you currently have exactly 500 activities running. A query is then submitted that represents activity
number 501. That query remains in a queued state until one of the currently running activities completes. The application that
submitted the query is oblivious to the fact the query was put into a queued state. Queries continue to queue until there is a total
of 600 concurrent queries. Any additional queries are stopped, and an error code is returned to the submitting application.
13.4 Work classes & Work class sets

In addition to using connection attributes that focus on the source of the activities, you can identify activities based on the type of
work through the creation of a work class. Work classes are grouped into a work class set. You can set up a work class to
identify the following types of work:
Workload Management
IBM Software
- CREATE - GRANT
- ALTER -
REVOKE
- DROP
- COMMENT
- SELECT - INSERT - DECLARE GLOBAL
- XQuery - UPDATE TEMPORARY TABLE
- DELETE - REFRESH TABLE
- MERGE - RENAME
- SET INTEGRITY
Work classes also introduce predictive identification for DML work (or READ and WRITE statements). Predictive identification is
very useful because it provides information about database activities that can be used to take action before they start consuming
resources on the data server.
You can also identify activities by using the schema name of the procedure invoked by a CALL statement. Based on workload
attributes and work class types, you can identify work and prepare it for the next stage, the management of the work.
13.5 Work actions & Work action sets

As described earlier, you can define work classes to represent activities of a certain type. A work action provides an action
that can be applied to a work class. A work action set can contain one or more work actions that can be applied to activities
in either a specific super class or to the database as a whole. For a work class to be active and have activities assigned to
it, there must be a work action defined for the work class.
If you define a work action set for a database, there are several types of actions that you can apply to activities that fall
within a work class:
• Prevent execution
• Collect activity data
• Count activity
For example, perhaps you want to prevent SQL from returning more than 100 000 rows. You can define a single work class
for a work action set that identifies SQL READ statements and then apply a work action with a threshold that represents a
threshold that would stop execution if the number of rows returned is more than 100 000.
Workload Management
IBM Software
Typically, the work action maps an activity to a specific service subclass and that subclass has thresholds defined on the
subclass to help manage the activity.
13.6 Monitoring
Monitoring validates assumptions that you made about data server capacity, it determines what is going on in the system, it
allows you to identify problem areas, and it enables you to drill down into specific areas to find useful data for solving the
problems.
Workload management monitoring allows you to access real-time operational data (such as a list of running workload
occurrences, a list of the activities running within a service class or the average response times for activities executing in a
service class) by using table functions to access in-memory data. New event monitors capture detailed activity information
(per service class, work class, or workload or when a threshold is exceeded) and aggregate activity statistics for historical
analysis.
13.6.1 Real-time monitoring
With the workload definitions and the service classes and thresholds, there is a unique opportunity to collect various sets of
information internal to the DB2 workload manager. This data includes statistics that represent the current activity on the system
that can help determine usage patterns and resource allocation and identify problem areas.
The method for accessing the real-time monitor data is through DB2 table functions. Table functions provide access to a set of
data that exists inside a DB2 database (such as the workload management statistics) as a virtual DB2 table against which you
can execute a SELECT statement. This offers you the ability to write applications to query data and analyze it just as if it were
any physical table on the data server.
General statistical information is available at a number of different levels, including the ones described in the following table:
Workload Management
IBM Software
Objects for which Description of statistics returned

statistics are returned
Service super classes The WLM_GET_SERVICE_SUPERCLASS_STATS table function

shows summary statistics across partitions at the service super class
level: namely, high water marks for concurrent connections (useful
when determining peak workload activity).
Service subclasses The WLM_GET_SERVICE_SUBCLASS_STATS table function shows

summary statistics across partitions at the service subclass level (all
activities run in service subclasses). Statistics include numbers of
activities and average execution times (useful when looking at general
system health and distribution of activities across service classes and
partitions).
Workloads The WLM_GET_WORKLOAD_STATS table function shows summary

statistics across partitions at the workload level. This includes high
water marks for concurrent workload occurrences and numbers of
completed activities (useful when monitoring general system health or
drilling down to identify problem areas).
Work action sets The WLM_GET_WORK_ACTION_SET_STATS table function shows

summary statistics across partitions at the work action set level:
namely, the number of activities assigned to a work action set and the
related work class name (useful for understanding the effectiveness of
a work action set and understanding the types of activities executing on
the system)..
WLM queues The WLM_GET_QUEUE_STATS table function shows summary

statistics across partitions for the WLM queues used for their
corresponding thresholds. Statistics include the number of queued
activities (current and total) and total time spent in a queue (useful
when querying current queued activity or validating that a threshold is
correctly defined: excessive queuing might indicate that a threshold is
too restrictive and very little queuing might indicate that a threshold is
not restrictive enough or not needed).
Statistics are only useful if the time period during which they are collected is meaningful. Collecting statistics over a very long
time might be less useful if it becomes difficult to identify changes to trends or problem areas because there is too much old
data. Thus, there is the ability to reset statistics at any time.
In addition to table functions that return statistics, there are table functions that return data sets of information about the work
that is currently executing on a system. This information about work is available at various levels:
Workload Management
IBM Software
Objects for which Description

information is
collected
Workload occurrence The WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES

table function returns a list of workload occurrences, across partitions,
assigned to a service class. For each workload occurrence there is
information about the current state and the connection attributes used to
assign the workload to the service class and activity statistics indicating
activity volume and success rates.
Service class agents The WLM_GET_SERVICE_CLASS_AGENTS table function returns a list

of database agents associated with a service class or an application
handle. Information returned also shows the current state of the agent,
the action that the agent is performing, and the status of that action.
Workload occurrence The WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES table

activities function returns a list of current activities associated with a workload
occurrence. For each activity, information is available about the current
state of the activity (for example, executing or queued), the type of
activity (for example, LOAD, READ, DDL), and the time at which the
activity started.
Activity details The WLM_GET_ACTIVITY_DETAILS table function returns details about

an individual activity. One detail returned is the activity type; depending
on that type, a set of additional data is returned. For example, for SQL
activities, information is available about the statement text, package data,
cost estimates, and rows returned or modified. Details about the isolation
level and CPU times are also available.
One important thing to remember is that because there are default workloads and service classes on the data server, monitoring
capabilities exist from the moment that you install the DB2 data server. These can be a great help in kick starting or validating
the identification stage of workload management by helping to isolate sources of activities that you can use to create workloads
and the service classes to which you can assign them.
13.6.2 Historical monitoring
In addition to the table functions, DB2 Workload Manager uses event monitors to capture information that might be of use in the
future. Three new event monitors have been added for DB2 WLM, each for a different purpose:
Activity event monitor: This monitor captures information about individual activities in a service class, workload, or work
class or activities that violated a threshold. The amount of data that is captured for each activity is configurable and should be
considered when you determine the amount of disk space and the length of time required to keep the monitor data. A common
use for activity data is to use it as input to tools such as db2advis or to obtain access plans (from the explain utility) to help
determine table, column, and index usage for a set of queries.
Workload Management
IBM Software
Threshold violations event monitor: This monitor captures information when a threshold is exceeded. It indicates what
threshold was exceeded, the activity that was the source of the exception, and what action was taken when it occurred (i.e. was
the activity stopped or allowed to continue).
Statistics event monitor: This monitor serves as a low-overhead alternative to capturing detailed activity information by
collecting aggregate data (for example, the number of activities completed and average execution time). However, if you use
aggregates, you can lose information about the distribution of activities, which you can mitigate by using histograms. More than
simply a way to determine statistics such as the average response time, histograms help you to understand what kind of
variance in the response time your users are experiencing (an average response time of 2 seconds might seem great, but if the
users don’t know whether response time is sub second or a couple of minutes, that leads to frustration). DB2 workload
management offers a number of histograms to represent the distribution of activities over their entire life cycle or the time that
they were executing.
The figure below shows the different monitoring options available to access workload information, table functions to access real-
time statistics and activity details and historical information captured as efficient aggregates or detailed information for individual
activities:
Workload Management
IBM Software
13.6.3 Historical Analysis
To help with analyzing resource consumption and the effectiveness of your database design, a historical analysis tool is provided
to look at the activity information collected in the activity event monitor and generate details on different users accessing tables
and columns as well as which tables, columns, and indexes are being used.
The WLM Historical Analysis Tool is composed of 2 Perl scripts: wlmhist.pl (to generate the historical data) and wlmhistrep.pl
(to produce the usage reports). These scripts can be found in the sqllib/samples/perl directory.
Workload Management
IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.
Workload Management

DB2 Bootcamp HOLs Workbook v20120418

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 Bootcamp HOLs Workbook v20120418

Uploaded by

Copyright:

Available Formats

IBM Software

DB2® 10 for Linux®, UNIX® and Windows®

DB2 FUNDAMENTALS AND DATA STUDIO.......................................... 3

MULTI - TEMPERATURE DATA MANAGEMENT....................................33

DB2 ESSENTIAL MAINTENANCE & PRACTICAL AUTONOMICS...... 51

DB2 BACKUP AND RECOVERY............................................................... 86

DB2 STORAGE OPTIMIZATION........................................................... 124

DB2 RANGE PARTITIONING................................................................. 148

TEMPORAL DATA MANAGEMENT...................................................... 174

ENABLING OPENBRAVO TO DB2 1 0 ................................................... 199

DB2 SECURITY........................................................................................ 228

ROW AND COLUMN ACCESS CONTROL............................................ 257

CONTINUOUS DATA INGEST............................................................... 276

WORKLOAD MANAGEMENT................................................................ 294

DB2® Fundamentals and Data Studio

6 Launch IBM Data Studio .....................................................................................................................................................................5

DB2 Fundamentals and Data Studio

3 About this Lab

4 Environment Setup Requirements

DB2 Fundamentals and Data Studio

1. Start the VMware image by clicking the button in VMware Workstation.

Figure 1 – Open in Terminal on Desktop

5.1 The SAMPLE Database

DB2 Fundamentals and Data Studio

Once the sample database is created, you will notice:

db2inst1@db2v10:~/Desktop> db2sampl -sql -xml -name DB2FUND

Creating database "DB2FUND"...

'db2sampl' processing complete.

6 Launch IBM Data Studio

1. Double click ‘IBM Data Studio’ on the Desktop.

Figure 2 – IBM Data Studio on Desktop

DB2 Fundamentals and Data Studio

Figure 3 – Select a workspace

Figure 4 – IBM Data Studio workspace

DB2 Fundamentals and Data Studio

7 Data Studio General Layout

Figure 5 – Data Studio layout overview

DB2 Fundamentals and Data Studio

Control Center Data Studio Purpose

8 Working with Databases in Data Studio

8.1 Connecting to a database

Figure 6 – Data connection profiles

DB2 Fundamentals and Data Studio

2. Still in Administration Explorer, right click DB2FUND and select Connect.

Figure 7 – Connect to a database

3. In the pop-up dialog, fill in the connection details as follows :

DB2 Fundamentals and Data Studio

Figure 8 – Database Connection dialog

DB2 Fundamentals and Data Studio

Figure 9 – Connected database with supported database object types

8.2 Browsing Database Objects

Figure 10 – List of tables in DB2FUND

Figure 11 – Properties view

Figure 12 – Object List navigation bar

DB2 Fundamentals and Data Studio

Figure 13 – List of objects in database DB2FUND using the navigation bar

Figure 14 – Using in-place search feature to quickly find database objects

5. Remove ‘E%E’ to bring back the complete list of tables.

DB2 Fundamentals and Data Studio

Figure 15 – Browsing data in EMPLOYEE table

Figure 16 – Editing data

DB2 Fundamentals and Data Studio

Figure 17 – Changes committed