Database Transition: Informix Dynamic Server to DB2 Universal

ibm.com/redbooks

Database Transition:Informix Dynamic Serverto DB2 Universal Database

Chuck BallardCindy MunnsMary Schulte

Mark ScrantonNora Sokolof

Uwe Weber

The transition process, planning, guidelines, and examples

DB2 Migration Toolkit for Informix makes it easier

Data and application considerations

Front cover

http://www.redbooks.ibm.com/


Database Transition: Informix Dynamic Server to DB2 Universal Database

December 2004

International Technical Support Organization

SG24-6367-00

© Copyright International Business Machines Corporation 2004. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

First Edition (December 2004)

This edition applies to Version 8.2 of DB2 Universal Database, Version 9.4 of Informix Dynamic Server (IDS), and Version 1.3 of the DB2 Migration Toolkit for Informix.

Note: Before using this information and the product it supports, read the information in “Notices” on page xiii.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Contents abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The project environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 DB2: A high-level overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Architectures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 Defining an instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Informix Dynamic Server instance architecture. . . . . . . . . . . . . . . . . 142.1.2 DB2 Universal Database instance architecture. . . . . . . . . . . . . . . . . 15

2.2 Allocating memory to an instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 IDS memory allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.2 DB2 memory allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.1 Context switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.2 IDS processes and threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.3 DB2 processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4 Allocating disk space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.1 IDS disk allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.2 DB2 disk allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.5 Cost-based optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5.1 IDS query optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.5.2 DB2 query optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6 Parallelism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.7 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 3. Planning the transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.1 Tasks and activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.1 Readiness assessment and scope . . . . . . . . . . . . . . . . . . . . . . . . . . 533.1.2 Tool evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.3 Estimating project duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

© Copyright IBM Corp. 2004. All rights reserved. iii

3.2 Data conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.1 Preparation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.2 Data conversion process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2.3 Time planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2.4 The database structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.2.5 Data movement approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.2.6 DB2 Information Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.2.7 Modifying the application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2.8 Database objects and interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3 After the transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1 IDS and DB2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1.1 Knobs, configuration, and tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.1.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.1.3 Granularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.1.4 Database manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.5 Dynamic parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.6 Cataloging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.7 Client access to DB2 instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2 Configuration methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.2.1 DB2 configuration methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2.2 Configuration Advisor and AUTOCONFIGURE . . . . . . . . . . . . . . . . 75

4.3 Configuration files and objects overview . . . . . . . . . . . . . . . . . . . . . . . . . . 794.3.1 Environment variables and the profile registry . . . . . . . . . . . . . . . . . 804.3.2 DB2 registry and environment variables . . . . . . . . . . . . . . . . . . . . . . 824.3.3 DB2 configuration files and objects. . . . . . . . . . . . . . . . . . . . . . . . . . 864.3.4 Configuring DB2 clients and servers. . . . . . . . . . . . . . . . . . . . . . . . . 894.3.5 Configuring a connection using the Configuration Assistant. . . . . . . 904.3.6 Configuring the client using profiles . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.7 Automating the rollout of DB2 clients . . . . . . . . . . . . . . . . . . . . . . . . 93

4.4 Client-to-server communications protocols . . . . . . . . . . . . . . . . . . . . . . . . 944.4.1 Configuring TCP/IP on the client using the CLP . . . . . . . . . . . . . . . . 954.4.2 Configuring a client-to-server connection . . . . . . . . . . . . . . . . . . . . . 954.4.3 Setting the DB2COMM registry variable . . . . . . . . . . . . . . . . . . . . . . 964.4.4 Cataloging the TCP/IP node on the client . . . . . . . . . . . . . . . . . . . . . 974.4.5 Cataloging databases using the CLP . . . . . . . . . . . . . . . . . . . . . . . . 984.4.6 Testing the client to server connection using the CLP . . . . . . . . . . . 99

4.5 Configuring the instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.5.1 Page size or sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.5.2 Table spaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.5.3 Buffer pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.5.4 Logical logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

iv Database Transition: Informix Dynamic Server to DB2 Universal Database

4.5.5 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapter 5. Instance and database operations . . . . . . . . . . . . . . . . . . . . . 1335.1 Instance operation modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.1.1 Online mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.1.2 Offline mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.1.3 Quiescent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.1.4 Creating and dropping the instance . . . . . . . . . . . . . . . . . . . . . . . . 136

5.2 Modifying the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.2.1 Working with the DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375.2.2 Viewing and updating the configuration using Control Center . . . . 1385.2.3 Managing buffer pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.3 Managing database storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455.3.1 Table spaces and containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465.3.2 Monitoring table space and container storage . . . . . . . . . . . . . . . . 1525.3.3 Transactions and logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

5.4 Backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645.4.1 Recovery types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645.4.2 Backup and restore methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

5.5 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765.5.1 HADR implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765.5.2 Log mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855.5.3 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865.5.4 Online split mirror and suspended I/O support . . . . . . . . . . . . . . . . 187

Chapter 6. SQL considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896.1 SELECT issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906.2 ROWID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1926.3 MATCHES predicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1926.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.5 Substring notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.6 SQLCODE and no rows found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.7 SQLSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.8 Built-in functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.9 SQL access to system catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1986.10 Quotation marks and character strings . . . . . . . . . . . . . . . . . . . . . . . . . 1996.11 Concatenation behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1996.12 Implicit casting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2016.13 Deferred constraint checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2016.14 Set operators: UNION, INTERSECT, and MINUS . . . . . . . . . . . . . . . . 2026.15 Multi-database access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.16 LOAD and UNLOAD statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.17 Temporary tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Contents v

6.18 Compound SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.19 INSERT cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.20 Isolation levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2066.21 Optimizer directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2076.22 Creating and altering tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.23 Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.24 Primary key definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2096.25 Constraint naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2096.26 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.27 DDL usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Chapter 7. DB2 Migration Toolkit for Informix . . . . . . . . . . . . . . . . . . . . . 2137.1 The MTK for Informix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

7.1.1 Features and functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2147.1.2 Recommendations for use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

7.2 Technical overview of the MTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2187.2.1 The graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2197.2.2 The migration process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

7.3 How to install and execute the MTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307.3.1 Using the MTK with manual deployment to DB2 UDB . . . . . . . . . . 231

Chapter 8. An MTK tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Part I: Core database migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2438.1 Create a project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2438.2 Work with the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

8.2.1 Specify Source tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2458.2.2 Convert tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2498.2.3 Refine tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2538.2.4 Other common migration considerations . . . . . . . . . . . . . . . . . . . . 2588.2.5 Generating Data Transfer Scripts tab . . . . . . . . . . . . . . . . . . . . . . . 2638.2.6 Deploy to DB2 tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

8.3 Summary of best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Part II: Database application object migration . . . . . . . . . . . . . . . . . . . . . . . . 2758.4 Procedure, function, and trigger migration . . . . . . . . . . . . . . . . . . . . . . . 275

Chapter 9. Access methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2879.1 Indexing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

9.1.1 Basic index comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2889.1.2 DB2 index expansions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2939.1.3 Type I and type II indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2979.1.4 Index reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2979.1.5 Functional indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

9.2 Advanced access methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2999.2.1 Materialized query tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

vi Database Transition: Informix Dynamic Server to DB2 Universal Database

9.2.2 Multidimensional cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3059.3 Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

9.3.1 Optimizer analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3109.3.2 Optimizer directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Chapter 10. Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32510.1 Object names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32610.2 Data type mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32710.3 Disk considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32910.4 Character types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

10.4.1 Truncation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32910.4.2 NCHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33010.4.3 VARCHAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33010.4.4 TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

10.5 Numerical types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33110.5.1 Numerical limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33110.5.2 DECIMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33210.5.3 MONEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33310.5.4 SERIAL and SERIAL8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

10.6 Date and time types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33510.6.1 DATE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33510.6.2 DATETIME, TIME, and TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 33610.6.3 INTERVAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

10.7 LOB data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33810.8 BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33810.9 Collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33810.10 SEQUENCE objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33910.11 NULL values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34010.12 FLOAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34010.13 REAL or SMALLFLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34110.14 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Chapter 11. Extensibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34311.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34411.2 Understanding extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34411.3 Feature mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34511.4 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

11.4.1 IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34711.4.2 DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

11.5 Available IDS DataBlades and DB2 Extenders . . . . . . . . . . . . . . . . . . . 34911.6 Other resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

11.6.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34911.6.2 Guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Contents vii

11.6.3 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35011.6.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35011.6.5 Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Chapter 12. Application conversion considerations . . . . . . . . . . . . . . . . 35312.1 Key considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35412.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35412.3 Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

12.3.1 Static and dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35612.3.2 Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

12.4 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36112.4.1 Savepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

12.5 Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36412.5.1 Types of locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36512.5.2 Lock escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36812.5.3 Deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

12.6 Isolation levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36912.6.1 Repeatable Read (RR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37112.6.2 Read Stability (RS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37112.6.3 Cursor Stability (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37212.6.4 Uncommitted Read (UR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

12.7 Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37212.7.1 Non-Scroll Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37412.7.2 Scroll Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37412.7.3 Update Cursor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37412.7.4 Insert Cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

12.8 Stored procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37512.8.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37612.8.2 Languages and interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37612.8.3 Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

12.9 Programming language considerations. . . . . . . . . . . . . . . . . . . . . . . . . 38512.9.1 ESQL/C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38512.9.2 JDBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38712.9.3 ODBC/CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38812.9.4 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39012.9.5 Large objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39012.9.6 SQLCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39212.9.7 SQLDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

12.10 Development integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39712.10.1 IBM WebSphere Studio Application Developer. . . . . . . . . . . . . . 39712.10.2 Microsoft .NET add-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Chapter 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

viii Database Transition: Informix Dynamic Server to DB2 Universal Database

13.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40213.1.1 Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40213.1.2 Roles and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40413.1.3 Security levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

13.2 Client/server security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41413.3 Authentication methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

13.3.1 LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41713.3.2 PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Chapter 14. Administrative operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 41914.1 Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

14.1.1 Buffer pool tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42114.1.2 Process tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42414.1.3 Quick-start tips for performance tuning . . . . . . . . . . . . . . . . . . . . . 425

14.2 Tools and wizards included with DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 42714.2.1 Control Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42714.2.2 Command Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42914.2.3 Task Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43314.2.4 SQL Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43814.2.5 Visual Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43914.2.6 Development Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44114.2.7 Configuration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44214.2.8 Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44314.2.9 Health Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44514.2.10 Replication Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44514.2.11 License Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44614.2.12 Information Catalog Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44714.2.13 Data Warehouse Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44814.2.14 Web administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44914.2.15 Wizards, advisors, and launchpads . . . . . . . . . . . . . . . . . . . . . . 449

14.3 Optional tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45014.3.1 DB2 Performance Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45114.3.2 DB2 Recovery Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45214.3.3 DB2 High Performance Unload. . . . . . . . . . . . . . . . . . . . . . . . . . . 45314.3.4 DB2 Test Database Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . 45314.3.5 DB2 Table Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45514.3.6 DB2 Web Query Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

14.4 Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45614.4.1 Exporting and importing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45714.4.2 Database reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46814.4.3 Database statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47414.4.4 Schema extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47814.4.5 Maintaining database integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

Contents ix

14.4.6 Throttling utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48314.4.7 Validating a backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

14.5 Other administrative operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48514.5.1 Configuring automatic maintenance . . . . . . . . . . . . . . . . . . . . . . . 48514.5.2 Working with databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48914.5.3 Working with tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49214.5.4 Command line processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

14.6 Monitoring tools and advisors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49914.6.1 Health check tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49914.6.2 Memory Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50514.6.3 Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50614.6.4 Event monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50614.6.5 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51114.6.6 Activity Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51614.6.7 DB2 Performance Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51814.6.8 The db2pd utility, an onstat equivalent . . . . . . . . . . . . . . . . . . . . . 51814.6.9 Diagnostic files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52814.6.10 Error message and command help . . . . . . . . . . . . . . . . . . . . . . . 530

Appendix A. Configuration variables and parameters. . . . . . . . . . . . . . . 533General registry variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534System environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539Database manager configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Appendix B. Informix source and object definitions . . . . . . . . . . . . . . . . 551

Appendix C. Additional resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553Pre-transition planning and estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554General transition questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554Transition consulting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554DB2 UDB training and education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555Useful Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558IBM Press Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

System requirements for downloading the Web material . . . . . . . . . . . . . 560How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

x Database Transition: Informix Dynamic Server to DB2 Universal Database

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Contents xi

xii Database Transition: Informix Dynamic Server to DB2 Universal Database

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2004. All rights reserved. xiii

TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX®AT®DataBlade™DB2 Connect™DB2 Extenders™DB2 Universal Database™DB2®developerWorks®DRDA®Eserver®

Everyplace®ibm.com®IBM®IMS™Informix®iSeries™Lotus®MVS/ESA™OS/390®OS/400®

pSeries®QMF™Redbooks (logo) ™Redbooks™Tivoli®VisualAge®WebSphere®z/OS®

The following terms are trademarks of other companies:

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

xiv Database Transition: Informix Dynamic Server to DB2 Universal Database

Preface

This IBM Redbook is primarily intended for use by IBM Business Partners and clients. We discuss approaches for transitioning from IBM Informix® Dynamic Server (IDS) Version 9.4 to IBM DB2® Universal Database™ (UDB). The information is applicable to the multiplatform versions of DB2 UDB, such as AIX®, versions of UNIX®, and Linux®. This book does not include information related to IBM Eserver® zSeries or iSeries™ environments.

We include overviews of the IDS and DB2 UDB product architectures to familiarize you with the framework design and major components of each environment. This provides a foundation for understanding the environments as we discuss the functions and features applicable to transitioning.

To aid in the transition, IBM has provided the DB2 Migration Toolkit for Informix (MTK). The MTK provides data mapping between the environments and includes the capability to convert and migrate the data from IDS to DB2 UDB.

The team that wrote this redbookThis redbook was produced by a team of specialists from around the world. Four of the team members worked locally at the International Technical Support Organization, San Jose Center, and one team member worked remotely in White Plains, New York, with a San Jose-based project manager.

© Copyright IBM Corp. 2004. All rights reserved. xv

Figure 1 Local team members: Chuck Ballard driving, and in the back seat (left to right) Mark Scranton, Mary Schulte, Uwe Weber, and Cindy Munns

Chuck Ballard is a Project Manager at the International Technical Support Organization in San Jose, California. He has more than 35 years experience, holding positions in the areas of Product engineering, sales, marketing, technical support, and management. His expertise is in the areas of database, data management, data warehousing, business intelligence, and process re-engineering. He has written extensively about these subjects, taught classes, and presented at conferences and seminars worldwide. Chuck has both a bachelor’s degree and a master’s degree in Industrial Engineering from Purdue University.

Cindy Munns is a Certified IT Specialist in the Software Group. She has more than 20 years of IT industry experience, focusing on database technology on a wide variety of platforms (DB2 and Informix, plus many others), business intelligence, and content management. Cindy serves as a member of the IBM IT Specialist Professional Certification Board, Informix Architecture Board, and DB2 Field Technical Advisory Council and is the IBM Liaison to the Southern California Informix User's Group. She has a BA, Magna Cum Laude, in Fine Arts/Economics and an MBA in Information Systems from New York University.

xvi Database Transition: Informix Dynamic Server to DB2 Universal Database

Mary Schulte has worked with Informix products for more than 18 years. She was an Informix developer for four years until joining Informix in 1991. There she served as consultant, trainer, and pre-sales engineer. Presently, she is a Certified IT Specialist for IBM, working in Dallas, Texas, supporting both Informix and DB2 customers. Her areas of expertise include C programming and application development. She holds a bachelor’s degree in Computer Science from Texas A&M University and a master’s degree in Business from the University of Texas at Dallas.

Mark Scranton is a Principal Consultant/Trainer. He joined Informix in 1995, focusing on IDS and XPS, primarily in the areas of performance tuning, configuration, and internal architecture. Mark now also focuses on DB2 UDB. He has published IDS CBTs and an IBM developerWorks paper Bringing IDS Internals to the Surface and was a contributing author of The Informix Handbook. Mark is a frequent speaker at User Conferences and Local User Groups, received the Informix International User Group (IIUG) 2003 Directors Award, and is the IIUG 2004 Advocacy Director.

Uwe Weber is an IT Specialist working on the Technical Sales Team for the IBM Software Group in Munich, Germany. Uwe joined Informix in 1998 as an educator in the Informix environment. He moved into the Technical Sales division after the IBM acquisition in 2001, where he provides advice and support to Informix customers in Central EMEA. He is an Informix-certified Professional, an IBM-certified DB2 DBA, and a DB2 Application Developer.

Nora Sokolof was a remote team member. She is a Certified Consulting Brand Sales IT Specialist with the IBM DB2 Migration Team (SMPO). Nora has been with IBM for almost 20 years and has held positions as a DB2 UDB, Informix, Oracle, and PeopleSoft Development DBA. In her seven years with the SMPO, Nora has assisted hundreds of customers with their migrations to DB2 from Oracle, PeopleSoft, and Informix. She is also the author of the Transitioning from IBM Informix to DB2 UDB - Database

Comparisons and Migration Topics white paper and is co-author of the IBM Redbook Planning for a Migration of PeopleSoft 7.5 from Oracle/UNIX to DB2 for OS/390, SG24-5648.

Additional contributorsAssistance and cooperation was also received from others, and we recognize them in this section.

From IBM locations worldwide:Omkar Nimbalkar, Informix Product Management and Marketing, Menlo Park, California

Preface xvii

Tom Christopher, Manager, DB2 Migration Toolkit product development, Silicon Valley Lab, San Jose, CaliforniaJean-Jacques Daudenarde, Database Migration Tools, Silicon Valley Lab, San Jose, CaliforniaJessica Escott, Manager of DB2 Tools Development, DB2 Development Lab, Toronto, CanadaDebra LaVergne, Data Migration Tools, Silicon Valley Lab, San Jose, CaliforniaJeff McMahon, Resolution Team Engineer, Lenexa, KansasJacques Roy, WW Sales Support for IDS and DB2, Denver, ColoradoArt Sammartino, Certified Consulting I/T Specialist, White Plains, New YorkDwaine R. Snow, Product Manager, DB2 Competitive Technology, Silicon Valley Lab, San Jose, California

From the ITSO, Austin Center:Elizabeth Barnes, Editor

From the ITSO, San Jose Center:Mary Comianos, Operations and CommunicationsDeanna Polm, Residency AdministrationEmma Jacobs, Graphics Designer

Become a published authorJoin us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcomeYour comments are important to us!

xviii Database Transition: Informix Dynamic Server to DB2 Universal Database

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

� Use the online Contact us review redbook form found at:

ibm.com/redbooks

� Send your comments in an Internet note to:

[email protected]

� Mail your comments to:

IBM® Corporation, International Technical Support OrganizationDept. QXXE Building 80-E2650 Harry RoadSan Jose, California 95120-6099

Preface xix



http://www.redbooks.ibm.com/contacts.html

xx Database Transition: Informix Dynamic Server to DB2 Universal Database

Chapter 1. Introduction

The business environment today is changing at an ever-increasing rate. We must be flexible enough to change with it if we are to meet customer demands and shareholder expectations. This is the only way to enable growth and maintain business leadership. These changes can include such things as changing business processes, engaging new markets, developing and purchasing new business software, and maintaining a flexible and dynamic support infrastructure.

This redbook is all about change, specifically to your IT support infrastructure, and in particular, to your database management system (DBMS), the foundation of that infrastructure. It is critical to have a DBMS that can house, organize, manage with integrity and deliver to you, on demand, the data that is collected and stored by your organization. But, in addition, your DBMS also needs to change with the business requirements. And, it needs to be enabled to a robust set of tools and applications that will enable the change and growth in your organization.

IBM DB2 Universal Database (UDB) is a leading DBMS and enjoys the support of many applications, solution components, and technologies. DB2 UDB has a broad base of customers and a long history of leading capabilities and high customer satisfaction. DB2 is a performance leader, a highly scalable DBMS capable of supporting the largest customer data volumes with a robust set of very powerful capabilities.

IBM Informix Dynamic Server (IDS) has also enjoyed a history of quality, performance, and robust capabilities. As you are aware, IBM acquired Informix.

1

© Copyright IBM Corp. 2004. All rights reserved. 1

IBM announced plans to continue support and enhancement of IDS and major Informix software products. IBM will integrate Informix compatibility features into DB2 UDB based on the feedback of our customers and Business Partners. To continue the history of excellent support for the IDS customer base and to enable them to grow and take advantage of available and planned software products, IBM is also supporting the capability to transition to DB2 UDB for those who choose to do so.

For Informix customers who are considering a transition, we recommend that you do so only when the result provides better value to you. We believe that you will gain maximum benefit if that transition is to DB UDB. Therefore, we provide information and tools to help make the transition to DB2 an easy and successful process. That is the objective of this book. As an example, we provide information about both DB2 UDB and IDS to help you understand the similarities and differences so that you can develop a detailed and robust transition plan.

2 Database Transition: Informix Dynamic Server to DB2 Universal Database

1.1 Contents abstractThis section includes a brief description of the topics presented in this book and how they are organized. The information presented includes some high-level product overviews, but is primarily oriented to detailed technical discussions of DB2 UDB and IDS. Depending on your interest, level of detail, and job responsibility, you might want to be selective of the sections where you focus your attention. We organized this book to enable that selectivity.

Our focus is on providing information to help as you develop a plan and then execute the transition from IDS to DB2 UDB.

Let us get started with a brief overview of the book contents:

� Chapter 1 is a brief introduction and statement of the objectives and scope of this book. It also provides a brief description of the chapter contents to help direct your reading priorities. Then, we get started quickly with a description of the book project environment and an overview of DB2 UDB.

� Chapter 2 provides a comprehensive discussion of the DB2 architecture and describes how it relates to the IDS architecture. Topics covered include the basic structural components of memory, processes, and disk and their management.

� Chapter 3 describes some of the steps to take in planning the transition. It includes discussion of product similarities and differences, application considerations, and hardware considerations.

� Chapter 4 outlines the configuration options as they apply to both IDS and DB2. We describe these from both client and server perspectives.

� Chapter 5 describes the management of an instance and database operations. We include an overview of memory and database storage management. Backup, recovery, and high availability are also covered, including the new High Availability Disaster Recovery (HADR) feature in DB2 UDB Version 8.2 that uses much of the IDS High Availability Data Replication (HDR) technology.

� Chapter 6 describes SQL considerations and how to handle the differences between IDS and DB2. We discuss SELECT variations, variations in the use of cursors, built-in functions, and differences in DDL syntax, error handling, and string manipulation, and SET statements.

� Chapter 7 documents the DB2 Migration Toolkit for Informix (MTK), a tool that automates the process of migrating your schema objects and data from IDS to DB2. The MTK is the recommended method of converting DDL and data, because it creates and runs scripts that can greatly reduce conversion time when compared to manual methods.

Chapter 1. Introduction 3

� Chapter 8 gives you a detailed tutorial of how to use the DB2 Migration Toolkit for Informix. We used an enhanced version of the stores_demo database, which is shipped with IDS. We suggest you use this tutorial to help familiarize yourself with the operation of the MTK.

� Chapter 9 reviews access and optimization methods used by DB2. This chapter includes explanations of index types and a discussion of how the optimizer works, as well as use of query plan analysis tools, such as Visual Explain.

� Chapter 10 covers data types and data movement. In this chapter, we compare and contrast IDS and DB2 object types and limits. We also provide an overview of the various data migration methods that can be used in addition to the DB2 Migration Toolkit for Informix.

� Chapter 11 provides an overview of extensibility in IDS and the equivalent functionality in DB2. Both IDS and DB2 provide the ability for you to define your own data types and functions. Here, we also review the use of selected IDS DataBlades and DB2 Extenders™.

� Chapter 12 discusses application conversion considerations. We include topics such as transactions, locking, isolation levels, cursors, stored procedures, triggers, and environment-specific considerations such as JDBC, ESQL/C, and ODBC.

� Chapter 13 examines key aspects of security, such as user security, authorities and privileges, and client/server security.

� Chapter 14 documents other resources you should consider when planning the transition, such as training, migration services, and Web materials.

� Chapter 15 chronicles administrative operations. We documented some of the typical DBA activities, for example, comparing the use of IDS and DB2 utilities, such as loading and unloading data, validating data integrity, and maintaining data organization. We also provide a brief overview of the tools for working with DB2 and review DB2 monitoring tools and advisors and diagnostics.

� Appendix A provides tables and examples of configuration information, such as environment variables and registry variables.

� Appendix B provides a summary of the source and object definitions used in testing the DB2 Migration Toolkit for Informix. This is good reference information when going through the MTK Tutorial.

� Appendix C contains a list of the Informix source/object definitions.


1.2 The project environmentThe objective of this book is to provide information that can help IDS customers understand, plan for, and execute a transition to DB2 UDB in the easiest manner possible. Throughout this book, we compare and contrast IDS and DB2 in order to provide a better understanding and to help you leverage your knowledge of IDS. For example, you should be aware of the rich graphical assistants (GUI) in DB2 that can be used to speed administrative and development tasks. Most of the graphical interfaces provide the option of viewing syntax to give you flexibility and choice. Where possible, we demonstrate features using the GUI, and at the end of each example, we show the syntax. After you have mastered the use of the GUI, you can even copy and save command syntax and revert to using command line programming if you so choose.

Our test environment consisted of the following:

� Hardware and operating system: IBM Eserver pSeries® 650 running AIX 5L Version 5.2, with eight CPUs and four 128 GB disks. Some client testing (such as with DB2 Control Center tools) was performed on a Microsoft® Windows® 2000 client. Note that the transition process described also applies to DB2 on Linux, other versions of UNIX (such as HP and Sun Solaris), and Microsoft Windows. However, it does not apply to DB2 on either the z/OS® or iSeries platforms.

� DB2 Version 8.2 Enterprise Server Edition. We used a beta version of this release level, so some of the screens might differ from what you see in the formal Version 8.2 release of the product.

� Informix Dynamic Server Version 9.40.FC3.

� Informix Client/SDK Version 2.81.FC2.

� DB2 Migration Toolkit for Informix (MTK) Version 1.3.

The following topics are beyond the scope of this book, and although we might briefly mention them, are not discussed in any detail:

� Informix Extended Parallel Server (XPS) to DB2 UDB with the Distributed Partitioning Facility (DPF).

� Transitioning from earlier versions of Informix servers, such as Informix SE and Informix Online.

� Informix 4GL migration.

Note: In this book, we only include considerations for a transition from IDS Version 9.40 to DB2 UDB Version 8.2.


� Syntax details. Where possible, we cover basic syntax, but you should expect to refer to the product manuals for more details.

� Performance tuning. This is a topic can be very specific to each particular implementation. Look for other IBM Redbooks about performance tuning by visiting the ITSO Web site.

1.3 DB2: A high-level overviewThe DB2 information management software portfolio provides the functionality you need to enable your on demand business. DB2 encompasses a broad range of products under the DB2 brand. For this discussion, we cover the highlights of DB2 UDB products that pertain to IDS users who are making the transition.

At the core of the DB2 portfolio is the DB2 UDB database server. IBM DB2 Version 8 for Linux, UNIX, and Windows is leading the evolution of the relational database. DB2 is the database of choice for the development and deployment of critical solutions such as:

� e-business � Business intelligence � Content management � Enterprise resource planning � Customer relationship management

Innovative manageability DB2 greatly reduces the complexity of data management by simplifying, automating, or eliminating many tasks traditionally associated with maintaining an enterprise-class database. Some of these advances represent steps toward the implementation of the Self-Managing and Resource Tuning (SMART) project and toward making full autonomic computing a reality for database implementations. Some examples of innovative manageability include:

� Configuration Advisor puts the knowledge of a seasoned DBA at your fingertips.

� Health Center/monitor keeps your database functioning and provides real-time alerts to a variety of interfaces, such as e-mail and pagers.

� Memory Visualizer lets you dynamically view and control DB2 memory usage.

� Advisors deliver expert advice about optimizing database access.

� Simplified management of large-scale partitioned databases.

� Automated database maintenance, including database statistics and reorganization.


Integrated information DB2 provides a strong foundation of information integration technologies, including federation, replication, Web services, and XML. With DB2 built-in capabilities, you can query, update, and replicate data across DB2 and IDS data sources. This is a key capability for those transitioning to DB2. Information integration technologies include:

� Federated Web services give you the ability to publish and consume data from various sources, such as another DBMS and XML.

� XML productivity tools simplify integrating XML, giving you the ability to store, retrieve, and decompose XML structures.

� Enriched data type support, such as IDS. DB2 provides rich type support for spatial data, text data, and flat files. Tools that enable these capabilities include the DB2 Spatial Extender, DB2 Net Search Extender, and DB2 Data Links Manager.

Robust foundation for 24x7 operationsIDS customers have traditionally placed great emphasis on around-the-clock operations. With DB2, IBM has taken that premise and integrated key IDS operational features into DB2.

Examples include:

� High Availability Disaster Recovery (HADR) is new with V8.2 and is based on the Informix implementation of HDR. It enables you to fail over your DB2 environment to a backup environment in the event of an outage, without relying on external software.

� Connection Concentrator for more user scalability. The Connection Concentrator is included with DB2 and is the functional equivalent to IDS MaxConnect in that it provides for multiple user sessions over fewer physical connections, thus conserving system resources.

� Dynamic parameter configuration enables you to reconfigure key parameters without having to bring down the database or instance.

� In-place online reorganization.

� Online load.

� Online storage management.

� Mobility on demand feature. DB2 Universal Database customers can easily extend their solutions to include mobile data by leveraging the new mobility on demand capability available with DB2 Universal Database V8.1 Fix Pack 4. The mobility on demand capability, based on DB2 Everyplace® technology, includes the high-performance, robust DB2 Everyplace database and a powerful synchronization solution for use with an existing DB2 UDB


deployment. This enables wireless and pervasive devices to occasionally run connected to DB2 applications.

Integrated business intelligence Business intelligence capabilities and performance are key strengths of DB2. The philosophy is to identify features for query performance and drive them directly into the database engine, greatly speeding response time. As examples:

� Multidimensional data clustering (MDC) improves performance of complex queries by storing table data physically clustered in blocks, according to common values of multiple columns.

� Advisors that analyze your data and schema, and then recommend appropriate indexes and Materialized Query Tables (precomputed physical views of data based on a query) for improved performance with less administrative effort.

Enhanced application development productivityDB2 offers an extensive toolkit for building applications. These application development tools focus on maximizing programmer productivity by providing support for major application frameworks popular with both Java™ and Microsoft application programmers. Capabilities include:

� DB2 Development Center for creating server-side objects, such as stored procedures in SQL or Java, and user-defined functions in SQL, MQ, and XML.

� New with Version 8.2, DB2 does not require a C++ compiler to create SQL stored procedures.

� IBM WebSphere® integration.

� Microsoft integration includes add-ins for Visual Studio, .NET, and Visual Studio development products (Visual Basic, Visual C++, and InterDev).

� Enhanced drivers for applications written to .NET, ADO, ODBC, OLE DB, DB2 CLI, JDBC, and SQLJ programming interfaces.

DB2 packagingDB2 UDB is packaged in a variety of configurations, depending on your requirements. Here, we focused on DB2 UDB Enterprise Server Edition (DB2 UDB ESE). Table 1-1 on page 10 provides a brief description of each of the editions and their equivalent IDS versions. Keep in mind that the versions are equivalent, but not the same, that is, different versions have different features.


For further information, refer to the IBM Web site. A helpful article for this topic is “Which distributed edition of DB2 Version 8 is right for you?” available at:

http://www.ibm.com/developerworks/db2/library/techarticle/0211zikopoulos/0211zikopoulos.html

DB2 UDB Enterprise Server Edition (DB2 UDB ESE) DB2 UDB Enterprise Server Edition (ESE) is roughly equivalent to IDS Enterprise Edition. ESE is designed to meet the database server needs of mid-size to large-size businesses and can be deployed in Linux, UNIX, and Windows environments. The ESE feature set, scalability, reliability, and availability provides the ideal foundation for building data warehousing, transaction processing, and Web-based solutions, as well as a backend for packaged solutions such as ERP, CRM, or SCM. In addition, ESE offers connectivity and integration for other enterprise DB2 and Informix data sources. The ESE package includes:

� DB2 Enterprise Server Edition � DB2 Administration Client (Administration tools)� DB2 Run-Time Client � IBM Developer Kit, Java Technology � Distributed Debugger for Java Stored Procedures � Audio, Image, and Video Extenders � WebSphere Studio Site Developer Advanced (trial) � WebSphere MQ � QMF™ for Windows (trial) � Data Management Tools (Try & Buy)

DB2 UDB ESE with DPF DB2 UDB ESE with Distributed Partitioning Facility (DPF) is roughly equivalent to IDS XPS. The database partitioning feature gives ESE customers the ability to partition a database within a single server or across a cluster of servers. The DPF capability provides the customer with multiple benefits, including scalability to support very large databases and complex workloads and increased parallelism for administration tasks.

Other DB2 editionsTable 1-1 on page 10 lists the additional versions of DB2,and their Informix equivalents.



Table 1-1 DB2 products and their Informix equivalents

DB2 IDS Comment

Enterprise Server Edition Enterprise Edition

ESE with Distributed Partitioning Feature

Informix XPS

Workgroup Server Edition IDS Workgroup Edition Designed for deployment in a departmental or small business environment that involves a small number of internal users. Can be deployed in Linux, UNIX, and Windows environments on systems with up to four CPUs.

Universal Developer’s Edition

IDS + Client/SDK, single user

Single application developer package for designing, building, and prototyping applications for deployment on any of the DB2 client or server platforms.

DB2 Express IDS Workgroup Edition One to two CPUs, Linux and Windows only. Note that DB2 Express must meet stringent requirements for silent installation and low administration, and as a result, is not an exact equivalent to IDS.

Personal Developer’s Edition

IDS + Client/SDK, single user (could be Workgroup Edition)

Enables a developer to design and build single user desktop applications, Windows and Linux only. There is no access to other servers.

Personal Edition IDS, single user (could be Workgroup Edition)

Single user database version, Linux and Windows only.


Chapter 2. Architectures

In this chapter, we describe the architectures of the IBM Informix Dynamic Server (IDS) and DB2 Universal Database (DB2 UDB) relational database management system (RDBMS) products. Understanding the product architectures is critical in preparation for the transition from IDS to DB2. We compare and contrast those architectures at a medium-to-low level of detail, which includes, but is not limited to, memory sizing, process considerations, and disk (data storage) allocation.

Although mentioned briefly in this chapter, it is not our intention to cover the full configuration of either product. However, additional details about configuration can be found in Chapter 4, “Configuration” on page 67. It is also beyond the scope of this book to include performance tuning topics. We do briefly touch upon some performance tuning considerations, but the topic is not discussed at any substantial depth. Performance tuning will certainly need to be considered after the transition, but it is a function of each customer’s particular environment.

Both IDS and DB2 share many similar concepts, components, and architectural structures, but these products also have significant differences. These differences must be taken into consideration during the transition process.

The terminologies of IDS and DB2 will vary slightly in some areas and more significantly in others. The objectives of this chapter are to describe the terminology used, the component definitions, and to promote a common understanding.

2


In this chapter, we discuss each topic in the following format:

� Introduction to topic area, with minor comparisons for clarity

� Topic description relative to the IDS architecture

� Topic description relative to the DB2 architecture

A dilemma typically encountered in a discussion of this type is finding common terms for what we will be describing. For example, in this chapter, we describe the architecture and components of database management systems. Specifically, we refer to an actual implementation of the database management systems, both IDS and DB2. Customers and developers often refer to such implementations in a variety of terms such as servers, engines, online systems, database servers, instances, or even simply as databases. For this book, we use the term instance.

Given that, our first task is to define what we really mean when we say instance.


2.1 Defining an instanceWe define an instance (of an RDBMS) as the physical instantiation of that RDBMS in a computer. But, what is it really? An instance is then defined to consist of three basic components: memory, processes, and disk. This is a common definition for any RDBMS, including both IDS and DB2. Figure 2-1 depicts and describes these components.

Figure 2-1 High-level instance architecture

Both IDS and DB2 use these common components, but their implementations are different. For example, in IDS, many structures are shared by across the instance. This is very different from a DB2 instance where many structures and processes are per database. The IDS memory and process footprint is more fixed in size than a DB2 instance. Although in IDS there are portions and segments that can grow, this should not be necessary, depending on adequate initial configuration and predicted activity growth. With DB2, processes can be spawned for many reasons such as connection growth or databases creation. This can cause the DB2 memory or process footprint to grow dramatically depending on the configuration. There are configuration choices, however, that will help preallocate memory structures, processes, or disk so that the size is more predictable or more contained.

In the next sections, we discuss the components of each of the IDS and DB2 instances.

inst

ance

Computer

memory

processes

One or more shared memory segmentsallocated to that instance. The allocation of these segments can be dynamic for some types of segments, or a pre-allocation of memory.

One or more processes that do the tasks requested by the instance. The allocation of these processes can be dynamic or pre-allocated, depending on the type of process.

Disk is a storage facility that contains persistent instance structures to hold data. The allocation of these structures can be dynamic or pre-allocated, depending on the type of disk allocation.

diskdisk

Chapter 2. Architectures 13

2.1.1 Informix Dynamic Server instance architectureThe high-level IDS architecture can be seen in Figure 2-2. Note that this figure could be illustrating an environment of one user or several thousand users. The footprint of the instance could grow if needed either dynamically or manually by the DBA. But, if the initial instance configuration was large enough, the instance size would not have to change to accommodate the large range of users.

Figure 2-2 High-level IDS instance architecture

We describe both the IDS and DB2 instance details in subsequent sections of this chapter.

IDS can have from one to 256 instances on a single computer, as can DB2. Figure 2-3 on page 15 shows a high-level view of two IDS instances on a single computer.

virtualsegmentvirtual

segment

Computer

logical log

logical log

logical log

oninit oninit oninit

root dbspace

Instance1

physical log

mem

oryprocesses

residentsegment

disk

virtualsegment(s)

messagesegment(s)

oninit

sysmasterdatabase

sysutilsdatabase

Three shared memory segments: resident, virtual, message. Not all IDS engines will have just three segments.

oninit The oninit processes, more commonly known as VPs, or virtual processors.

One dbspace, the rootdbs. This dbspaceis built by default the first time the instance is built.

databasetablespace

rootreservedpages

tablespacetablespace

oninit oninit oninit oninitoninit


Figure 2-3 The IDS architecture: Two instances

2.1.2 DB2 Universal Database instance architecture With DB2, each instance can have one or more databases. Each instance has one database manager configuration file. In addition, each database has its own database configuration file, catalog tables, logs, reserved buffer pool area, and table spaces. Table spaces can be regular, long (for LOB data), user temporary, and system temporary. Tuning parameters, resource management, and logging can differ for each database in the instance and can be controlled at the database level. Configuration parameters at the instance and database level can be set using the Control Center.

Temporary table spaces store temporary tables that are created and managed by the database management system for sorting and other DBMS activities. By default, one temporary table space, TEMPSPACE1, is created. However, additional temporary table spaces can be created at different page sizes (for example, 4 KB, 8 KB, 16 KB, 32 KB). Temporary objects are allocated to temporary table spaces in a round-robin fashion. A default user temporary table space is not created with the installation.

ComputerInstance1m

emory

processes

residentsegment

disk

virtualsegment

messagesegment

logical loglogical loglogical log

root dbspace

Instance2

physical log

residentsegment

virtualsegment

msgsegment

sysmasterdatabase

sysutilsdatabase

mark dbspace

databasekids

table joshua

table jacob

table jarrod

logical log

logical log

logical log

root dbspace

physical log

sysmasterdatabase

sysutilsdatabase

table jordan index aly



oninit oninit oninit

oninit oninit oninitoninit

oninit oninit oninitoninitthreads

threads


The DB2 instance: Differences in architectureThe DB2 instance has many similar components to IDS. There are, however, at least three major differences from a high-level architectural point-of-view:

� The DB2 Administration Server (DAS): This is a special type of instance that is typically created when a DB2 instance is first created. The purpose of the DAS is to allow remote administration tools, such as the DB2 Control Center, access to a DB2 instance.

� Memory allocation: This is done at the database manager and instance level, but also at a lower-level granularity, such as per connection, application, or database. More details in can be found in 2.2.2, “DB2 memory allocation” on page 21.

� Process allocation: DB2 has many processes that are allocated, both dynamically and at instance startup. This is very different from the IDS instance where the processes are preallocated and are not increased unless by a DBA.

Figure 2-4 on page 17 shows a high-level view of a DB2 instance on a computer.

Note: The DAS does not have to be running to use a DB2 instance. But, if the DBA wants to administer an instance remotely through tools such as the DB2 Control Center, the DAS does need to be started.

There will only be one DAS on each computer that handles all instances.


Figure 2-4 DB2 architecture: One instance

The DB2 architecture shown in Figure 2-4 has the following components:

� One DAS DB2 Administration Server

� One instance with a database manager

� Two databases, database1 and database2

� The following allocations for each database:

– Processes

– log buffers and log files

– Buffer pools: two for database2, and one for database1

– Table spaces:

• Default table spaces (built when instance is created), syscatspace, userspace1, and tempspace1 for both databases

• Table and index table spaces for database2, fact_table, and fact_index

Primarylog filesPrimarylog files

database1

IBMDEFAULTBPBuffer Pool

mem

oryprocesses

disk

database2

Computer

DB2 instanceD

AS (DB

2 Administration Server)

syscatspacetablespace

userspace1tablespace

tempspace1tablespace


fact_tabletablespace(4 KB page)


IBMDEFAULTBPBuffer Pool

fact_table buffer pool(4 KB page)

processes processes

Primarylog filesPrimarylog files



2.2 Allocating memory to an instanceThe memory allocated to an instance is a key configuration setting, particularly for acceptable performance. With both the IDS and DB2 instances, many memory structures are preallocated and fixed and cannot be modified dynamically. Therefore, it is critical to allocate sufficient memory to those fixed structures.

The DB2 instance will typically require more memory than an IDS instance for the processes, buffer pools, and associated tasks. This topic, discussed in the next section, is very critical for the full understanding of DB2 and will also help in the transition effort.

2.2.1 IDS memory allocationThis section describes memory allocation for IDS. To aid in understanding, refer to the visual of memory allocation depicted in Figure 2-5. IDS shared memory is divided into memory segments that consist of three portions: the resident portion, the virtual portion, and the message portion.

Figure 2-5 IDS memory allocation

Segment descriptionsThe IDS instance will have a minimum of two shared memory segments: one resident and one virtual. The message portion is optional, but one or more is typically present. However, if there are no shared memory connections configured, there will not be a message portion.

Resident portionThe resident portion is a fixed size portion that contains many structures. The significant structures for the resident portion are:

� Buffer cache (BUFFERS): A single, fixed-size set of memory buffers that are 2 KB or 4 KB fixed size. The buffer cache will hold the majority of IDS data pages read from disk for sharing among users. Pages that are read through a light scan are not held in the buffer cache. A light scan is a type of read where pages are placed in private memory buffers. This type of read is typically used, for example, in data warehousing applications.

memorysegments

buffer cache/LRUSlocks

physical log bufferslogical log buffers

shared memory connections

sessions poolsmisc memory poolsPDQ environment

light scans/appends

Resident Portion Virtual Portion(s) [ Message Portion(s) ]


� Locks (LOCKS): A structure that is used to enforce locking in IDS.

– Pre-IDS V9.2: There is a single lock structure allocated in the resident segment, and it cannot be changed without stopping and starting the instance.

– IDS V9.2 and later: A single lock structure is still allocated initially in the resident portion. If the instance needs more locks, it will attempt to allocate additional locks structures in the virtual segment if memory is available, up to a defined limit.

� Log buffers (LOGBUFF/PHYSBUFF): Sixteen-page memory buffers that collect either pages or records that will be sent to either the logical log files or physical log file.

� Least recently used queues (LRUS): One to many LRU queues for managing pages in the buffer cache with respect to modifications and dirtiness. The LRUS identify the least recently used pages for stealing or replacing that page after synchronization to disk.

– Pre-IDS V9.4: The buffer cache pages are managed by LRU and by priority based on the specific page type.

– IDS V9.4 and later: The high end of a queue is managed by FIFO, and the low end is managed by LRUS. The high end of the queue holds the most accessed pages since last checkpoint. The FIFO method is the same method as used in DB2.

Virtual portionThe virtual portion contains any shared information in the database server that can grow or shrink, or be allocated or deallocated (memory pools). The number of segments in the virtual portion can grow as needed during the life of the database server. If the instance needs more memory, it can request additional virtual segments if available. The instance retains these segments (does not release them automatically) until the next computer or instance reboot. The most significant structures found in the virtual portion are:

� Session pools: For each connection, a session is created, including the session control block (SCB), thread control block (TCB), and RSAM thread control block (RSTCB). These control blocks hold session information for that session. When the application or user disconnects, the memory pools are freed and available for another use.

� Miscellaneous memory pools: Pools for operations such as sorting, data dictionary cache, stored procedure cache, and PDQ allocations.

� Light scan buffers: Private buffers into which data is read for read-only queries. Typically used in data warehousing.


� Light append buffers: Used for loading data through the High Performance Loader Express (HPL Express). Using HPL enables the bypassing of the BUFFERS and LRUS overhead in the resident segment.

Message portionThe message portion contains message buffers that are used for local and shared memory connections. These are connections originating on the same computer as the instance. The segments in this portion have read/write permissions for all users. The significant structures in the message segment or segments are:

� Client-side message buffers: Buffers for the client connections to use when making requests to the instance through a shared memory connection.

� Server-side message buffers: Buffers for the instance to use when passing results back to the client shared memory connection.

Process memory footprintWith the IDS instance, the processes are referred to as virtual processors, or VPs. Initially, a number of VPs of different classes are allocated when the instance starts. (For more information about VPs, see Table 2-1 on page 28.) VPs can also be added or dropped dynamically, depending on the class of VP.

After these processes are allocated, the process space for the instance is fixed. The multithreaded architecture keeps that process space fixed. The existing VPs control the thread switching within the process space. The control blocks for the thread can grow and shrink. But this is done in the virtual segment or segments of the instance, which is also already allocated. Although the IDS instance can add virtual segments of memory, it does not automatically allocate or spawn additional processes. Figure 2-6 on page 21 depicts how the process space (in the center portion of the diagram) remains fixed within IDS as the lightweight threads switch on and off the process or VP.


Figure 2-6 Multithreaded architecture thread context switch

2.2.2 DB2 memory allocationA major difference between memory allocation for IDS and DB2 is that with IDS almost all memory structures are shared across the instance, among all users, among all databases. For DB2, many of the memory structures are allocated at much finer granularities, such as per database manager, per each database, per each application/connection, and per agent memory, as shown in Figure 2-7.

Figure 2-7 DB2 shared memory architecture

Database shared memory is allocated in full at first connection to the database by an application or when the database is activated.

Thread Content

Program Counter Stack Pointer

Register Contents

Thread Content

Program Counter Stack Pointer

Register Contents

Shared Memory

stackstack

Process Space

textstackdata

Each thread has a pointer into the text

of the process.

Shared Memory Database Manager

Database1Shared Memory Database2

Shared Memory

Private Memory

Private Memory

Private Memory

Private Memory

Application Shared Memory

Application1 Group Shared Memory

Application2 Group Shared Memory

Application Shared Memory

Agent Agent Agent Agent


Database manager shared memoryAlso known as instance shared memory, this memory is used by DB2 to manage the activities of all connections for all databases associated with an instance. This includes the following:

� Monitor heap: Holds database system monitor data.

� Audit buffer size: Holds audit data if auditing is enabled.

Database manager shared memory is allocated in full at instance start time (db2start) and deallocated when it is stopped (db2stop).

Database shared memoryAlso known as database global memory, this memory is used by DB2 to manage the activities of all connections to a specific database associated with an instance. This includes the following:

� Buffer pools: Hold table and index pages when they are read from disk.

� Database heap: Holds space for many items such as temporary memory for utilities, event monitor buffers, and log buffers.

� Utility heap: Specifies the maximum amount of memory that can be used for utilities such as backup, restore, and load (including load recovery).

This area of memory can also contain temporary overflows from the package cache and from the catalog cache.

� Lock list: Specifies the amount of memory allocated to store all locks held by all applications concurrently connected to this database. This is the total amount of locks that can used by all concurrent applications per each database.

� Catalog cache: Specifies the amount of memory used to cache system catalog information.

� Package cache: Specifies the amount of memory used to cache sections for both static and dynamic SQL statements.

� Shared sort memory: Specifies an upper limit on the amount of database shared memory.

Database shared memory is allocated in full at the first connection to the database, or when the database is activated, and deallocated when the database is deactivated.

Application group and application shared memoryApplication group shared memory and application shared memory are used by all agents (both coordinating and subagents) that work for an application. This


memory is also used to store descriptor information for declared temporary tables.

This memory is only allocated when either the database manager configuration parameter INTRA_PARALLEL is set, or connection concentrator is enabled (database manager configuration parameters MAX_CONNECTIONS is greater than MAX_COORDAGENTS). All engine dispatchable units1 (EDUs) working on behalf of a particular application are attached to an application shared memory region for that application. In addition, all EDUs working on behalf of a particular application are attached to the application group shared memory region for the application group of which that application is a member.

This memory is allocated incrementally when an application starts and is deallocated when the application completes.

Agent private memoryAgent private memory consists of a number of individual heaps. This memory is used to manage a number of activities such as compiling, sorting and servicing of UDFs and stored procedures. Each EDU has its own private memory.

Different components of agent private memory are allocated on a demand basis, and deallocated as soon as their task is complete. Agent private memory is allocated for an agent when the agent is assigned as the result of a connect request, and deallocated when the agent terminates.

Agent and application shared memoryThis memory (the database manager configuration parameter is lheapsz) is attached by coordinating agents servicing local applications and is used for SQL request and response communications. It represents a communication buffer between the local applications and its associated agent and is allocated as shared memory by each database agent that is started.

In addition to its role as a communication buffer, it is also used for the following two other purposes:

� To determine the I/O block size when a blocking cursor is opened

� To determine the communication size between agents and db2fmp processes, which might be a user-defined function or a fenced stored procedure

This memory is allocated when the database manager agent process is started for the local application and deallocated when the database manager process is terminated.

1 EDU is the same as a DB2 agent: A process or thread that does work for the instance.


DB2 agentsDB2 agents include coordinator agents and subagents and are the most common type of DB2 processes that carry out the bulk of SQL processing on behalf of applications. DB2 assigns a coordinator agent with an application, and this agent coordinates the communication and processing for an application.

The notion of pooling agents at the database level was added in DB2 Version 8.1. In reality, the database level idle pool consists of one or more pools for particular groups of applications. Initially, when a system starts up, there is only one application group. As more connections are added, DB2 creates additional application groups and creates an idle pool for each new application group; this is done automatically and transparently by DB2.

There are typically 100-200 applications per application group.

Buffer poolsA buffer pool is an area of memory into which pages from disk are temporarily moved from disk storage. DB2 agents read and modify data pages in the buffer pool. The buffer pool is a key influencer of overall database performance, because data can be accessed much faster from memory than from a disk. If more of the data needed by applications is present in the buffer pool, less time would be needed to access this data, thereby improving performance.

Buffer pools can be defined with varying page sizes, including 4 KB, 8 KB, 16 KB, and 32 KB.

Block-based buffer poolsIn DB2 Version 8, prefetching on certain platforms can be improved by creating block-based buffer pools.

By default, buffer pools are page-based, which means that contiguous pages on disk are prefetched into non-contiguous pages in memory. Sequential prefetching can be enhanced if contiguous pages can be read from disk into contiguous pages within a buffer pool.

DB2 prefetching code recognizes when a block-based buffer pool is available and will use block I/Os to read multiple pages into a continuous buffer pool in a single I/O, thereby significantly improving the performance of prefetching.

Note: If intra-partition parallelism is disabled (this is the default), the coordinator agent performs all the application requests. If intra-partition parallelism is enabled, DB2 assigns a set of subagents to the application to work on processing the application requests.


A block-based buffer pool consists of both a page area and a block area:

� The page area is required for non-sequential prefetching workloads. � The block area consists of blocks where each block contains a specified

number of contiguous pages, referred to as the block size.

2.3 ProcessesFor this book, we chose a UNIX-based platform for the instance. In the following sections, we discuss the instance processes from that perspective.

One of the most expensive operations for a computer is to switch, or swap, a process that is currently on a physical processor with another process whose turn it is to run. Part of that switching is what has been known as a context switch, where the context, or details, of the running process, including data, stack, and registers, are retained and stored away temporarily to allow a new processes context to be moved onto the physical processor.

A major architectural step achieved by IDS with Version 6 and 7 was the multithreaded architecture. This architecture brought many performance advantages to the product. One of those advantages was what became known as lightweight thread switching, where tasks could be executed as a result of a switching of the thread context versus a process context switch. This was much more inexpensive and, therefore, faster. This helped in the scaling of the product (more concurrent users) and dramatically reduced the process memory footprint required for many concurrent users.

The next few sections describe context switching from two perspectives: process-based context switching and thread-based lightweight context switching. It is important to understand the differences when moving from IDS to DB2 as an aid in instance configuration.

2.3.1 Context switchingAn area that is discussed quite often when considering IDS and DB2 architectures is the notion of multithreaded and single-threaded. From a purely technical point of view, this discussion is really based on context switching and the relationship to the architecture or architectures.

The objective of this chapter is not to compare and contrast this notion from a performance perspective. We simply want to illuminate the architectural details of each approach. This should help in the understanding of resources required for each product, which in turn, will help greatly in configuration considerations.


Process-based context switchingThe traditional, or most common type of context switch, is when a process wants to run. It relies on the operating system (OS) to schedule it onto a physical processor, or CPU. Some texts refer to this as a heavyweight context switch, although it could also be considered simply as more of a normal, or traditional, context switch.

Figure 2-8 shows an example of a process-based context switch controlled by the operating system. This is true with both DB2 and IDS. Again, it is an operating system choice as to which process runs on a physical processor.

Figure 2-8 UNIX process-based context switching

Figure 2-9 on page 27 shows a different view of a process-based context switch. This example shows how the oninit process competes for CPU time with other processes, regardless of process type. For illustration purposes, this diagram shows how oninit might behave on a one CPU configuration.

physical cpuprocess unix process

process.B

process.Z

waiting process list

process.D

context switch

process.Tprocess.Yprocess.X

process.Dis put on CPUprocess.A process.C

process.Ayeilds

cpu1 cpu2 cpu3

UNIX


Figure 2-9 Process-based context switch showing the IDS oninit process

2.3.2 IDS processes and threadsThis section describes the types of IDS processes and threads.

The IDS virtual processorIn IDS, a virtual processor (VP) is a process that is designed to do work similar to a physical processor on a computer. While a processor is responsible for managing processes on the system, a VP is responsible for managing threads. A thread is the portion of a process that is responsible for a particular set of tasks. A running thread is responsible for determining when to yield so that another thread has a chance to run on the VP.

IDS will have many VPs allocated to the instance, and these will fall into specific classes, or types, of VPs.

Table 2-1 on page 28 shows the IDS VP classes.

oninitp2

p1p1

oninit

CPU Usage Over Time

Processes

p4p5

p2

Context Switches


Table 2-1 IDS processes: VPs

Classes Description

CPU(configurable)

All user threads and some threads for the server system run on VPs in this class. No blocking system calls are allowed on this VP, such as activities that read and write from disk or wait for messages from the application. These can be increased or decreased as needed while the instance is up.

AIO(configurable)

The asynchronous I/O (AIO) VP performs disk I/O to cooked chunks and to raw devices when kernel I/O is not turned on, including disk reads and writes needed for SQL statements, checkpoints, and other I/O activities. The number of AIO VPs can be configured by the administrator. More AIO VPs can be added when the server is running.

classname(configurable)

Definable by the DBA. This class of virtual processor runs user-defined routines in a thread-safe manner so that if the routine fails, the instance is unaffected.

JVP(configurable)

Executes Java user-defined routines (UDRs). Contains the Java Virtual Machine (JVM). A JVP has the same capabilities as a CPU VP. Multiple JVPs can exist in the same database server to allow parallel invocations of Java UDRs.

SHM(configurable)

The shared memory class handles the task of polling for new connections using the shared memory method of communication to the application. It also handles incoming messages from the application. The number of shared memory VPs can be configured before the server is started. If the shared memory method of communication is not used, no SHM VP is started.

STR(configurable

The stream-pipe class handles communications by sending and receiving messages through operating system stream mechanisms. The number of stream-pipe VPs can be configured before the server is started. If the stream pipe method of communication is not used, no STR VP is started.

TLI(configurable)

The TLI class handles polling tasks for the TLI programming interface for TCP/IP or IPX/SPX communication with the application. The number of TLI VPs can be configured before the server is started. If TCP/IP with TLI is not used, no TLI VP is started.

SOC(configurable)

The SOC class handles polling tasks for the TCP/IP Berkeley sockets method of communication with the application. The number of SOC VPs can be configured before the server is started. If TCP/IP with sockets is not used, no SOC VP is started.

PIO(not configurable)

The PIO VP runs threads for the server that performs writes to the physical log on disk. The PIO VPs are automatically allocated when the server is started. One PIO VP is usually allocated. If the dbspace with the physical log is mirrored, two PIO VPs are allocated.

LIO(not configurable

The LIO VP runs internal threads for the server that perform writes to the logical log on disk. The LIO VPs are automatically allocated when the server is started. One LIO VP is usually allocated. If the dbspace with the logical log is mirrored, two LIO VPs are allocated.


The IDS threadIDS has been a multithreaded architecture since Version 7 was released in the early 1990s. The physical entity known as a thread consists of a set of structures, or control blocks. These are:

� Session control block (SCB): Contains information about the session. When you first connect, the database server creates a session for you, which means that it creates a session control block.

� Thread control block (TCB): Contains information about the thread. There is one thread control block for every thread running in the database server.

� RSAM thread control block (RSTCB): Certain threads running in a database server need access to a layer of IDS called RSAM, which handles disk I/O requests, index management, page management, buffer management, and data replication. Some system threads and all of the user threads (spawned for a session) need an RSAM thread control block.

Now, we focus on how the context-switching takes place for a multithreaded architecture.

Thread-based context switchingThe switching of the oninit process onto and off of physical CPUs is still controlled by the OS. However, the IDS instance controls when a thread will yield to another ready thread. This is called a “context switch,” but it is at the thread level, not the process level. Simply put, the thread context has been switched, but not the entire process context. This is also referred to as “lightweight context switching.” Figure 2-10 on page 30 shows IDS context switching at the thread level.

ADM(not configurable)

The ADM class handles the timer. The timer is used to time any activity that should occur for a certain period of time. For example, some threads go to sleep for a certain number of seconds. It is the timer’s responsibility to mark the time for these threads. Only one ADM VP is started by the server.

OPT(not configurable)

The OPT VP class is responsible for transferring BLOB data to a staging area to be read by the optical subsystem. The optical subsystem is only used if IBM Informix-OnLine/Optical is installed. One OPT VP is allocated if the STAGEBLOB parameter in the configuration file has an entry.

Classes Description


Figure 2-10 IDS thread-based context switching

Figure 2-11 on page 31 depicts a lower-level view of thread switching.

The following list describes the steps shown in Figure 2-11 on page 31:

1. After the thread decides to yield, it places its state information in the series of control block structures listed earlier in this chapter.

2. Next, it must put a pointer to itself on one of the wait queues, sleep queue, or ready queue, depending on why the thread is yielding.

3. The running thread notifies the next thread waiting in the ready queue. (Actually there are multiple ready queues, one for each priority.) After the thread ID of the waiting thread is determined, the running thread can get the program counter of the waiting thread.

4. Finally, the thread performs the actual context switch in the process. The code in the thread switching functions is straightforward. It must simply:

a. Flush the context of the currently running thread to its stack.

b. Load the context for the next thread to run from its stack.

t2t1t1

t3

Virtual Processor Usage Over Time

Threads

Thread context switches

t4t5

t3t2

A virtual processor is a process called

oninit

CPU Time

Processes


Figure 2-11 IDS thread context switching

2.3.3 DB2 processesDB2 has processes that are allocated for the database manager (instance), the database, or the requesting connection. Typically, they are called agents, or engine dispatchable units (EDUs). In many cases, agents are spawned as needed, or might migrate to other connections if needed and not being used.

Process modelFigure 2-12 on page 32 shows a detailed view of the DB2 process model. Notice that many processes are per instance or per database. This is very different from IDS, where all processes, or VPs, are shared by across the instance. In IDS V9, VPs can be defined for specific user-defined routines (UDRs) and might be available to only a specific set of applications or users. It is helpful to know the names and functions of these processes, because they might help in problem diagnosis. For example, high CPU utilization for a particular DB2 process might pinpoint the need for a reconfiguration of a particular database manager or database configuration parameter.

physical cpuprocess unix process

oninitprocess process.B

oninitprocess

wait queue

thread-1yielding

thread-1 contextthread-1 context

thread-2 contextthread-2 contextthread-1

thread 8

thread 6

thread-1

thread 8

thread 6

ready queue

thread 7

thread 9

thread-2

thread 7

thread 9

thread-2

controlblocks

pointer tothread-1

thread-1state info

1

3

2 4a

UNIX

4b


Figure 2-12 DB2 process model

All of the DB2 processes are under the UNIX process model. See Figure 2-8 on page 26.

db2agent and db2agntpAll connection requests from client applications, whether they are local or remote, are allocated a corresponding coordinator agent (db2agent). When the coordinator agent is created, it performs all database requests on behalf of the application.

Agent poolAgent creation and destruction is an expensive operation, and DB2 provides an agent reuse mechanism by implementing an agent pool to which agents or subagents are released when an application completes. These agents or subagents are then available to be reused for requests for coordinator agents on behalf of a client program, or for subagents on behalf of existing coordinator agents.

The following tables describe some of the more important processes visible during the different states of a DB2 instance.

User processes

DB2 processes

Per-connection processes

Per-active database processes

Per-Instance Processes

Per-request process

Remote client machine

Application C

SQL CONNECT TO PROD

Application A

SQL CONNECT TO TEST

Application B

SQL CONNECT TO TEST

Application C

Application A

Application B

Database PROD

Database TEST

Shared memory, semaphores

Per-instance processes

db2tcpcm

db2ipccm

db2pclnr

db2pfchr

db2pclnr

db2pfchr

db2agent

db2agntp

db2agnta

db2agent

db2agent

. . .

db2agntp

db2agntp

db2agntp

db2agntp

TCPIP

db2bm, db2med, etc

db2dari

db2udfp

db2wdog db2gds

db2agent

Fenced UDF processes

Fenced stored procedure processes

db2resyn db2dart

db2cart

Coordinator agent

Active subagents

Pool of idle subagents associated with this application

db2sync

db2loggr db2dlock

db2loggr db2dlock


Table 2-2 describes processes per instance when there are no connections or active databases.

Table 2-2 DB2 processes per instance: No connections and no active databases

Table 2-3 describes additional processes per instance when there are connections present.

Table 2-3 Additional DB2 processes per instance with connections

Process name

Brief description

db2cart Determines when a log file can be archived and invokes the user exit to do the actual archiving. There is one db2cart process per instance, but it only runs if there is at least one database in the instance that has USEREXIT enabled.

db2fmtlg Preallocates log files in the log path when the database is configured with LOGRETAIN ON and USEREXIT OFF.

db2gds The DB2 global daemon spawner process that starts all DB2 EDUs (processes) on UNIX. There is one db2gds per instance or database partition.

db2disp The DB2 agent dispatcher process, which dispatches client connections between the application assigned to the client connection and the available coordinating agents. This process only exists when the connection concentrator is enabled.

db2sysc The main DB2 system controller or instance. Without this process, the database server cannot function.

db2wdog The DB2 watchdog handles abnormal terminations; this only applies to UNIX.

db2govd The DB2 governor, which is a reactive governing process. If the DB2 governor is enabled, this process takes snapshots at the interval specified in the governor configuration file and checks the snapshots against all configured rules. If a rule is broken, it takes the specified action.

Process name

Brief description

db2agent DB2 coordinator agent, which performs all database requests on behalf of an application.

db2agnsc The parallel recovery agent, which is used during roll forward and restart recovery to perform the actions from the logs in parallel.


Table 2-4 describes processes for each active database, in addition to the instance and connection processes.

Table 2-4 Additional DB2 processes for each active database

db2agnta An idle subagent that was used in the past by a coordinator agent and is still associated to that coordinating agent process.

db2agntp A subagent that is currently performing work on behalf of the coordination agent with which it is associated. This subagent is enabled when the INTRA_PARALLEL database manager configuration parameter is set to YES.

db2ipccm IPC communication manager is the interprocess communication listener for local client connections.

db2tcpcm TCP communication manager works as a communication listener for TCP/IP connection requests.

db2tcpdm Communication listener for TCP/IP Discovery requests. Discovery requests are made by the configuration assistant when it searches the network for remote DB2 servers and their databases.

db2snacm SNA/APPC communication manager, which works as a communication listener for SNA/APPC connection requests.

Process name

Brief description

db2dlock Local deadlock detector; there is one per database partition. It scans the lock list and looks for deadlock conditions.

db2estor Used to copy pages between the database buffer pools and extended storage.

db2event The event monitor process. There is one db2event process per active event monitor, per active database. These processes capture the defined “events” and write them to the output file specified for the event monitor.

db2loggr The database log reader, which reads the database log files during transaction processing, restart recovery, and roll-forward operations.

db2loggw The database log writer, which flushes the log records from the log buffer to the log files on disk.

db2pclnr The buffer pool page cleaners, which asynchronously write dirty pages from the buffer pool or pools back to disk.

Process name

Brief description


2.4 Allocating disk spaceBoth IDS and DB2 have similar approaches to the allocation of disk space for any kind of storage, such as tables, indexes, and log files. There are some considerable differences, however, that will be valuable for the transitioning process from IDS to DB2. One difference is the terminologies. Some terms are the same for different structures, while others are different for identical structures. When planning the transition from IDS to DB2, having a shared base, or foundation knowledge of disk structures, can expedite the effort of the transition.

Figure 2-13 on page 36 shows the disk structure for IDS and DB2. It depicts a high-level view of terms and their application. The only disk term not fully illustrated in this figure is BLOB space due to the large variety of implementation choices.

db2pfchr The buffer pool prefetchers, which read data and index pages from disk into the database buffer pool or pools before it is read on behalf of applications.

db2logts This process is used for collecting historical information about which logs are active when a table space is modified. This information is recorded in the DB2TSCHG.HIS file in the database directory. It is used to speed up table space roll-forward recovery.

Process name

Brief description


Figure 2-13 Disk terms for IDS and DB2

Table 2-5 shows a more detailed comparison of IDS and DB2 disk terms. Although Figure 2-13 will be very helpful from a high-level viewpoint, having more details will help the fine tuning of the configuration of the DB2 instance.

Table 2-5 Disk terms comparison

Disk term IDS DB2

page All pages are of the same fixed size, 2 KB or 4 KB, in IDS.a The page size is based on IDS product port, and not the platform or hardware page size.

The basic unit of input/output. For IDS V9.4 and earlier, this page size is either 2 KB or 4 KB fixed size for all instance structures and cannot be changed.One reason that DB2 has multiple pages sizes is to accommodate different row sizes.


chunk One or more contiguous pages on disk allocated to a dbspace. Can be raw space or “cooked files” (part of a mounted file system).IDS V7.x -> IDS V9.3 max. chunk size:(size + offset) <= 2 gigabytesIDS V9.4+ max. chunk size: (size + offset) <= 4 terabytes

N/A

extent One or more pages from a chunk. Can be free or allocated, and can be used for tables, indexes, or log files, for example.

One or more pages from a container allocated to the instance. Can be free or allocated, and can be used for table space or index.

container N/A One or more contiguous pages on disk allocated to a table space.Can be raw space or “cooked files” (part of a mounted file system).

dbspace A logical collection of one or more chunks.

N/A

table space A collection of one or more extents for a table, partition, or fragment.

A logical collection of containers/disk storage.

BLOB spacesb

� BLOB space: A structure that contains BLOBc data types of TEXTd or BYTEe. Available in IDS V7 -> V9.x.

� sbspace (SMART BLOB space): A structure that contains BLOBs of type CLOBf or BLOB. Available in IDS 9 or later.

Large object table spaces (LOB).

a. BLOBpages are logically configurable, which means that, for example, aBLOBpage of size 500 is actually 500 2 KB or 4 KB pages.b. BLOBs can also be stored in a table (IN TABLE syntax), although it is not themost common approach.c. BLOB: Binary large object.d. TEXT: Large amounts of text data.e. BYTE: Images, video, pictures, for example.f. CLOB: Character large object.

Disk term IDS DB2


2.4.1 IDS disk allocationEach dbspace is composed of physical storage called chunks. Chunks are either raw devices or files, typically known as cooked files. Cooked files are files that are part of a mounted file system, for example, UNIX File System (UFS). Chunks can be added to a dbspace when more space is required. Indexes can be stored in separate dbspaces from data. IDS has a concept of a table space, but in IDS, it has a different meaning than the DB2 table space.

BLOB spaces (IDS V7.3) are used for storing the large binary objects of data types BYTE and TEXT. BLOB spaces are not logged or placed in buffers but accessed directly from disk. Sbspaces (IDS V9) are used for storing BLOBs and CLOBs. In IDS, BLOBs can be stored in table meaning that LOB data can be stored together with the row data on the same extents in the dbspace. This type of BLOB is logged and buffered and is not suitable for use when BLOB sizes are large. A third type of LOB that is supported by IDS V7.3 is of the type where the pointer to the LOB is stored on the database and the actual lob data is stored outside the database in some type of file system.

Data is not distributed across chunks automatically by IDS. In order to distribute data across physical storage, a fragmented table with several dbspaces must be created and the type of fragmentation must can be specified.

IDS disk allocation is very important for performance of the IDS engine. As of IDS V9.4, the instance has the maximum storage capacity of 128 petabytes, composed of 32,767 chunks at 4 TB each. Therefore, the IDS product has greatly expanded storage capacity in IDS V9.4.

The default dbspace: rootdbsWhen creating an instance with IDS, only one dbspace, the root dbspace (rootdbs), is created. Figure 2-14 on page 39 shows the structures created.


Figure 2-14 IDS default rootdbs structures

The structures that are created in the rootdbs are:

� Root reserved pages: Twelve pages that keep track of configuration parameters, logs, checkpoint information, dbspace information, chunk information, and archive information.

� Table space table space: A table that keeps track of all table/table spaces in the rootdbs.

� Database table space: A single table for the entire engine that keeps track of all the databases in the engine.

� Sysmaster database: This primarily contains views that point to shared memory structures.

� Sysutils database: This is predominantly empty when the instance is first created. This database is used by the ON-bar product only. ON-bar is one of the backup and restore utilities available in IDS.

� Physical log: This is used to capture the first before-images of changed pages and for physical recovery.

� Logical logs: Between 3 and 32,767 logical logs that are used to capture data manipulation language (DML) and data definition language (DDL) information for changed pages. Used for logical recovery. (For definitions, see “Abbreviations and acronyms” on page 565.)

2.4.2 DB2 disk allocationDB2 disk allocation is very similar to IDS in many respects, but a DBA will find that there are some significant differences both in terms of initial setup and on-going maintenance of the DB2 instance.

Reserved pages

Chunk freelist

Table space table space

logical logs (3 min)

physical log

database table space

sysmasterdatabase

sysutilsdatabase


The physical space within a database is organized into a collection of table spaces. Each table space consists of a collection of containers, each of which is either a directory in the file system, a physical file, or a raw device. When a table is created, it is assigned to a table space. An extent contains data for only one table, and all extents are the same size. After the initial extent fills, all additional extents are created on each additional container in the table space in a round-robin fashion. DB2 automates the striping of data across disks. Distributing data in this way enables parallel input and output and optimizes performance. Large objects can be stored in special table spaces named LONG.

Table space typesTwo types of table spaces are available: SMS and DMS. System Managed Space (SMS) table spaces are managed by the operating system and Database Managed Space (DMS) are managed by DB2. SMS table spaces are better suited for smaller tables where performance is not a prime consideration and where they are also easier to maintain. The space in an SMS table space is defined as a directory and is not preallocated. Data can be added as long as there is enough physical space available. More than one directory can be assigned to the table space. With the SMS type table space, data, indexes, and large objects are all stored in the same table space. For IDS customers who are familiar with Informix Standard Engine, the file structure and allocation behavior of SMS table spaces is very similar to that of Standard Engine.

DMS table spaces are better suited for large data where performance is a key factor. Containers are added to DMS table spaces in the form of a file or physical disk device. The space is preallocated and fixed in size. Additional containers can be added to support growth. In addition, DMS containers can be resized and extended when necessary. DMS table spaces support the separation of data, indexes, and large objects.

DB2 provides two types of GUI panels to assist the DBA in table space creation: the Create Table Space wizard and the Create Table Space notebook.

SMS and DMS table spacesThe following points contrast SMS and DMS table spaces:

� Object allocated:

– An SMS table space is created using directory containers.

– A DMS table space is created using either file containers or device containers.

� Managed by:

– SMS is system managed space (managed by the operating system).

– DMS is database managed space (managed by DB2).


Advantages of an SMS table spaceAn SMS table space has the following advantages:

� Space is not allocated by the system until it is required.

� Creating a table space requires less initial work, because you do not have to predefine the containers.

Advantages of a DMS table spaceA DMS table space has the following advantages:

� The size of a table space can be increased by adding or extending containers, using the ALTER TABLESPACE statement. Existing data can be automatically rebalanced across the new set of containers to retain optimal I/O efficiency.

� A table can be split across multiple table spaces, based on the type of data being stored.

Figure 2-15 on page 42 depicts the default table space layout in DB2.

Tip: You might want to separate your table data for performance reasons, or to increase the amount of data stored for a table.

For example, you could have a table with 64 GB of regular table data, 64 GB of index data, and 2 TB of long data. If you are using 8 KB pages, the table data and the index data can be as much as 128 GB. If you are using 16 KB pages, it can be as much as 256 GB. If you are using 32 KB pages, the table data and the index data can be as much as 512 GB.

If all table data is in a single table space, a table space can be dropped and redefined with less overhead than dropping and redefining a table.

In general, a well-tuned set of DMS table spaces will outperform SMS table spaces.


Figure 2-15 DB2 default table space layout

Figure 2-16 depicts the physical table space layout.

Figure 2-16 DB2 physical table space layout

2.4.3 LoggingBoth IDS and DB2 have a number of log buffers and log files for capturing to disk groups of changes made to pages in memory. The overall objective of logging is to provide the ability to replay or recover changes made in memory if the instance should fail. The approaches are very similar, but the implementations are significantly different between IDS and DB2.

IDS loggingIDS logs changes made to instance objects for recovery and restore purposes. IDS logs the following categories:

� Physically logged: The first before image of changed buffer cache pages

System table space SYSCATSPACE

Container SQLT0000.0

Temp table space TEMPSPACE1


User table space USERSPACE1


Extents

pagepage

ON path/drive

NODE0000

SQL00001

SQLT0000.0

SQLT0001.0

SQLT0002.0

Physical Structure (Containers)

Logical Structure (Table spaces)

USERSPACE1

TEMPSPACE1

SYSCATSPACE


� Logically logged: To objects from the logical log buffers:

– Data manipulation language (DML) for logged databases

– Data definition language (DDL) for all databases

– DDL for the engine: checkpoint information, extent allocations, adding a dbspace, for example.

Figure 2-17, “IDS log buffer flushing” on page 43 shows the log structures used by IDS.

Figure 2-17 IDS log buffer flushing

Log filesThe following list shows the types of log files in IDS:

� Physical log file (one only): Receives pages flushed from the physical log buffers.

� Logical log files (three minimum, 32,767 maximum): Receives pages flushed from the logical log buffers.

Computer

logical log

logical log

some dbspace

Instance1

mem

oryproc

disk

logical log buffers

resident segment

physical log buffers

logical log physical log

flush

buffer cache

changes to pagesbefore image pages

Physical log buffers: (Two memory buffers of 16 pages each by default.) Captures the first before image of changed buffer cache pages. At some point, the current buffer must be flushed to the physical log file on disk. While the flushing is taking place, the other physical log buffer is used.

Logical log buffers: (Three memory buffers of 16 pages each by default.) Captures changes to objects. At some point, the current buffer must be flushed to a logical log on disk. While this flushing is taking place, one of the other logical log buffers is used.

Flushing occurs when an application connected to an unbuffered log databaseissues a COMMIT WORK, or the current log buffer is full.


IDS database modesIDS has three different log modes of databases:

� Non-logged database: Does not capture DML; therefore, logical recovery is impossible. This is recovery of transaction information as close as possible to the point of the instance failure. The before image is captured through the physical log, but only DDL is captured through the logical logs. Recovery occurs back to the last known point of physical consistency, which in most cases, is the point of last checkpoint. DDL is captured for this type of datbase.This is the default for database creation. Explicit transactions (BEGIN WORK/COMMIT WORK) are not possible.

� Logged database: Captures DML and DDL for this specific database through the physical and logical logs. Logical recovery is possible. Explicit transactions (BEGIN WORK/COMMIT WORK) are possible. If a BEGIN WORK is passed by the application, the instance wraps the transaction in a BEGIN WORK/COMMIT WORK. This is known as a singleton transaction.

� ANSI database: All DML and DDL are captured. Any SQL is always in a transaction. Logging cannot be turned off for this type of database. This database is the only type of database that DB2 has available.

DB2 logging and database modesDB2, like IDS, must at some point log to disk the changes made to memory pages to facilitate recovery of a failed instance. DB2 has log buffers that are flushed to log files on disk similar to IDS, although the implementation is very different. Figure 2-18 on page 45 shows the log buffers and files for two different databases. Recall that with DB2, each database has its own set of log buffers and files, while with IDS, log buffers and files are shared across the instance.

Important: In IDS V9.2 or earlier, logical logs must be added manually if more are needed. A level-0 archive must also be taken prior to availability.

In IDS V9.3 and later, dynamic logging can be enabled by the DBA. In this case, logical logs can be added automatically by the instance if chunk space is available. If logs are added, the instance retains these, that is, they are not freed up when they are no longer needed.


Figure 2-18 DB2 log buffer flushing

DB2 uses a logging approach similar to IDS, with some significant differences:

� Log files are allocated at the database level, one set per database. (This is very different than IDS.)

� DB2 does not have a physical log file.

The logging mode of a database cannot be turned off. The database can initially be created with NOT LOGGED INITIALLY, (this disables logging for CREATE TABLE or ALTER TABLE statements, so no logging activity is captured) but the logging would have to be turned on prior to usage.

Types of log filesThe following list shows the types of log files with DB2:

� Primary log files: A fixed amount of storage allocation. These files are preallocated at the first connection to the database.

� Secondary log files: Allocated one at time as needed (up to the value of the LOGSECOND parameter) when the primary log files become full.

database manager

Primarylog fileslog files

database1

IBMDEFAULTBPbuffer pool

mem

oryprocesses

disk

database2

Computer

DB2 instanceD

B2 Adm

inistration Serversyscatspacetablespace




fact_tabletablespace(4 KK page)

IBMDEFAULTBPbuffer pool

fact_table buffer pool

(4 KB page)

Primarylog fileslog files

fact_indextablespace

log buffers log buffers

flush onCOMMIT

Log buffer flushing occurs when a transaction COMMITs or a group of transactions COMMIT; or the log buffer is full, or some other internal database event occurs.

Primary

flush onCOMMIT

Secondarylog filesSecondary

log files


Types of loggingTypes of logging include:

� Circular logging: Supports non-recoverable databases. This type of logging uses only the log files that are found as “active” in the instance.

� Archival logging: As a log file becomes inactive, it is archived. This type of logging supports roll-forward recovery. There are three types of log files that this method uses:

– Active: Contains information for transactions that have not been committed or rolled back, as well as those transactions that have been committed or rolled back, but changes have not been written to disk yet.

– Online archived: A log that is not needed anymore and is considered closed. This log though still resides in the ACTIVE log subdirectory.

– Offline archived: These logs have been moved from the ACTIVE log subdirectory manually, or by a USEREXIT that calls a user exit program when a log file is ready for archiving. These logs can simply be moved out of the current ACTIVE log directory or moved to tape, for example.

2.5 Cost-based optimizationBoth DB2 and IDS have cost-based optimizers that determine query costs based on statistics stored in catalog tables.

2.5.1 IDS query optimizationFor IDS, the optimization level is set using:

� SET OPTIMZATION HIGH/LOW- SQL statement.

� OPTCOMPIND environment variable, SQL statement, or instance-wide configuration parameter. OPTCOMPIND is used to influence the optimizer to select a different join method. For more information about this setting, see Chapter 4, “Configuration” on page 67.

Optimization or access path selection for static SQL is determined each time an application is invoked and is not stored before runtime. Static or dynamic SQL can be reused if use of the SQL cache area is enabled and set on for a session. Catalog statistics are updated using the update statistics utility with three options, high, medium, and low. These options enable the DBA to manage distribution statistics for specific columns and for various levels of granularity.

Note: Roll-forward recovery is not available with circular logging.


2.5.2 DB2 query optimizationFor DB2, there are seven levels of optimization. The QUERYOPT parameter is used to specify the optimization level for static SQL and is done with the PREP or BIND command.

Like IDS, DB2 has a query rewrite feature; the order of tables in a join are not important, because the optimizer will rewrite the order for the optimal access path. Catalog statistics are updated using the runstats utility. If an application uses static SQL, the access paths that are generated at bind time by using the statistics in the catalogs are stored with the SQL executable code on the database. If an application uses dynamic SQL, the access path is generated at runtime by using the statistics recorded in the catalog tables. Dynamic caching of the SQL executable might allow for quick reuse of the optimized code.

2.6 ParallelismDB2 and IDS both support two types of parallelism: parallelism within a database instance and parallelism between database instances. The former most commonly runs on a symmetric multiprocessor (SMP) machine in which multiple processors share common memory and disks. The latter usually involves a collection of processors, each of which has its own main memory and disks that are not shared with other processors. Informix XPS and DB2 are both a shared nothing architecture.

Intra-parallelismWith intra-parallelism on an SMP machine, multiple processes can serve a given user simultaneously. The optimizer generates access plans containing multiple threads that can be active simultaneously during processing of an SQL statement. In addition, both products facilitate parallel I/O by fragmenting or striping (round-robin) data across multiple storage devices. Unless the storage device is RAID, striping of data in IDS is a task performed by the DBA, and in DB2, it is handled automatically by the database management system.

IDSIDS uses parallel data query (PDQ) to control parallelism or the number of threads generated. To make the most efficient use of PDQ parallelism with IDS, values for the number of scan threads, memory size, number of queries, and the query’s priority should be set. The four parameters in the ONCONFIG file that must be set are DS_MAX_QUERY, DS_MAX_SCANS, DS_TOTAL_MEMORY,

Important: For this book, we only focus on intra-parallelism, or parallelism within the same instance.


and MAX_PDQPRIORITY. Several environmental variables can also be set to enhance PDQ processing.

DB2For a DB2 database to exploit this type of parallelism, the database manager configuration parameter INTRA_PARALLEL must be set to YES. When performing a PREP or a BIND, the DEGREE parameter can be set to a specific integer indicating the number of threads to be generated, or it can be set to ANY.

If set to ANY, the optimizer determines the number of threads to generate. Each thread might be processed by a separate processor. The degree for dynamic SQL can be specified by setting the CURRENT DEGREE register. The default value for DEGREE is controlled by a database configuration parameter named DFT_DEGREE.

2.7 High availabilityFor concerns of high availability, both IDS and DB2 offer one or more types of data replication, and IDS offers database-level mirroring.

IDS replicationThere are two types of replication:

� High Availability Data Replication (HDR): This type is enabled by sending the logical logs from the primary server to the secondary server where all the changes are applied. The primary server is able to be updated, and the secondary server is read-only. If the primary server fails, users can be redirected to the secondary server. HDR functionality will soon be incorporated into DB2.

� Enterprise Replication: This type supports peer-to-peer replication with the update anywhere feature and is similar to DB2 replication.

DB2 replicationWith the release of DB2 V8.2, replication has been enhanced greatly. In DB2, the new replication is called HADR, or High Availability Data Replication. HADR mirrors much of the functionality of IDS HDR.

High Availability Disaster Recovery DB2 High Availability Disaster Recovery (HADR) is a data replication feature that provides a high-availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary, to a target database, called the standby. A partial site failure can be caused by a hardware, network, or software (DB2 or operating


system) failure. Without HADR, the database management system (DBMS) server or the machine where the database resides has to be rebooted.

The length of time it takes to restart the database and the machine where it resides is unpredictable. It can take several minutes before the database is brought back to a consistent state and made available. With HADR, the standby database can take over in seconds. Further, you can redirect the clients that were using the old primary database to the standby database (new primary database) by using automatic client reroute or retry logic in the application.

A complete site failure can occur when a disaster, such as a fire, causes the entire site to be destroyed. Because HADR uses TCP/IP for communication between the primary and standby databases, the databases can be situated in different locations.

If a disaster occurs at the primary site, data availability is maintained by having the remote standby database take over as the primary database with full DB2 functionality. After a takeover operation occurs, you can bring the original primary database back up and return it to its status of primary database; this is known as failback.

With HADR, you can choose the level of protection you want from potential loss of data by specifying one of three synchronization modes: synchronous, near synchronous, or asynchronous. HADR allows the standby database to take over as the primary database with full DB2 functionality. It is also possible for the original primary database to be brought back up and returned to its status of primary database.

When a failure occurs on the primary database, you can initiate a takeover operation on the standby database, which then becomes the new primary. Because the standby database is already online, failover can be accomplished very quickly, resulting in minimal down time.

After the failed old primary is repaired, it can rejoin the HADR pair as a standby database if the two copies of the database can be made consistent. After the original primary database is reintegrated into the HADR pair as the standby database, a failback operation can be performed so that the original primary database is once again the primary database.

MirroringMirroring is a critical high-availability feature that helps maintain a mirror copy of critical data. Both products have some level of mirroring available.


IDS mirroringIDS can mirror at the dbspace level. This is allowed on any dbspace, including a dbspace with the physical or logical logs.

DB2 mirroringDB2 mirroring cannot be done at the table space level; it is performed outside of the database at the hardware level.

DB2 does support mirroring of the transaction logs.

Some IDS customers are still using IDS mirroring at the dbspace level. DB2 does not have this ability; mirroring should be done at the hardware level.

Split image backups DB2 supports the increased availability of data by allowing you to split a mirrored copy of data and make that mirrored copy available for other types of processing, including backups, or available to other servers. To exploit this storage capability, DB2 has delivered two new features. Suspended I/O supports continuous system availability while providing for online split mirror handling of the database. By suspending I/O to disk, DB2 will ensure that the split mirror copy maintains its integrity. The db2inidb utility operates on the mirrored copy and provides the following opportunities for making data available:

� Creating a transaction consistent database copy for reporting purposes

� Maintaining a mirrored copy, synchronized with the primary database

� Creating an offline backup using the mirrored copy of the database

Note: Some customers are still using IDS mirroring, although the majority of the customers have chosen to use hardware-level mirroring.

Important: Addressing the mirroring functionality is very important to the transition. If a customer is currently using IDS mirroring, those mirrored dbspaces are, in most cases, critical to the environment. When moving to DB2, the customer needs to ensure that hardware-level mirroring is implemented.


Chapter 3. Planning the transition

As with any project, transitioning from IDS to DB2 requires good planning to be successful. This chapter introduces the common concepts involved in planning for such a transition and the available tools and resources. It is intended to be a high-level overview to help you get started in your planning process. The actual details of most of the transition activities are included in the subsequent chapters of this book.

The transition will involve more than just transitioning the data from one DBMS to another. Therefore, there are many other associated activities to be considered as part of the overall project plan. Some examples include:

� Education and training of IT� Transition planning, testing, and verification� Migration of the actual data� Migration and modifications to the data schemas and metadata� Evaluation, selection, and testing of auxiliary tools� Changes to the applications� Consideration and use of new software, utilities, and administration tools� Performance tuning� Backup, restore, and recovery requirements� Resource requirements, including people and hardware� Availability requirements and service-level agreements� Plans for delays and possible fallback� Consulting and services requirements

3


One of the most helpful tools available is the IBM DB2 Migration Toolkit for Informix (MTK). There is an introduction to the MTK in Chapter 7, “DB2 Migration Toolkit for Informix” on page 213, and detailed information about how to install, configure, and use the MTK in Chapter 8, “An MTK tutorial” on page 241. We encourage you to take a serious look at the MTK as a key transition tool to use.

In addition, there are IBM services resources available to assist with planning, estimating the cost, and performing the actual transition. These are trained and experienced resources that understand the process and can, therefore, save you significant time and effort.


3.1 Tasks and activitiesTypical transition planning tasks include planning for activities that occur even before moving the data. For example, it might be a good time to consider architectural or structural changes you have thought about. However, use caution; making multiple, major changes during a transition exposes you to the potential for increased and complex issues. If you have time, it is typically better to only make one change at a time. Some of the typical steps to consider are:

1. A readiness assessment2. Tool evaluation and selection3. Defining the scope of the project and the process steps4. Estimating durations of the process steps5. Planning the project6. Allocating resources

Each project is different, but there are some factors that are good indicators of the overall effort. For example, for applications that frequently use stored procedures, the number and complexity of the stored procedures to be converted will greatly affect the length of the application transition. The same applies to the use of special data types and large objects. Another area might be the use of times and dates. Each DBMS has different internal format and display techniques. Physical requirements, such as the use of raw and cooked disk areas, spaces, and nodes, can also represent a large amount of work, especially if the data will grow significantly over time.

A transition plan can be as simple as a spreadsheet that lists the primary tasks along with some of the associated information for each task, such as start date, end date, elapsed time, dependencies, and who is responsible. There are also project planning tools available that are specifically designed to plan and track projects. These tools let you assign tasks, establish dependencies among the various steps (for example, you cannot start testing until you move the database structure and the test data), and chart the original plan against in-process and completed activities.

3.1.1 Readiness assessment and scopePlanning a transition project begins with an assessment of the environment, the size of the project, and an understanding of the resources that can be used.

An accurate profile of the system architecture is key to success. Considerations that require attention include:

� What characterizes the workload type mix: OLTP, or OLAP and decision support (data warehousing)?

Chapter 3. Planning the transition 53

� What languages are used for the applications? For example, Java, C, C++, and Visual Basic.

� What is the target operating environment? Specifically, such things as the operating system, version, release, and fix pack level.

� What is the server target hardware platform? For example, IBM Eserver pSeries, HP/Compaq, and Sun.

� What is the typical configuration of the database server? For example, the number of boxes, number of CPUs, size of RAM, and disk capacity.

3.1.2 Tool evaluationAlthough a migration can be performed without the help of tools, IBM has created one for you: the DB2 Migration Toolkit for Informix (MTK). It is specifically designed to make the transition from IDS as fast and as easy as possible. There might be special circumstances that also warrant the use of a third-party tool in conjunction with the MTK. That will be part of the evaluation and selection process.

The DB2 MTK can be used to generate DDL scripts to create database objects such as tables, indexes, views, triggers, stored procedures, and user-defined functions. It aids in moving data from IDS to DB2. For example, it can either connect directly to the source system and perform its own extraction of the DDL, or it can use a syntax valid SQL script extracted by other tools such as dbschema. For information purposes, in addition to IDS, the MTK also supports transitioning from Oracle, Sybase, and Microsoft SQL Server. For more information about the MTK, see Chapter 7, “DB2 Migration Toolkit for Informix” on page 213 and Chapter 8, “An MTK tutorial” on page 241.

3.1.3 Estimating project durationAn accurate estimation of the project activity durations includes considerations about the scope of project and needed resources and knowledge of the products, applications, and transition plan.

The MTK can also be used as an assessment tool to determine the complexity of the migration. Using the MTK in this manner will, for example, reveal stored procedures or SQL that might require manual intervention. However, a good working knowledge of the MTK is mandatory. Estimating the duration of activities also greatly depends on the skill level of those performing the work.

The cost of new software and migration tools should also be considered when estimating the total project cost. For example, the MTK is provided free of


charge, and DB2 can also be significantly less than competitive products. Contact your IBM Sales Representative for more details.

Training costs, for IT staff and for end users, should also be factored into the project plan. For example, a good course for experienced DBAs is the IBM “Fast Path to DB2 for Experienced Relational DBAs,” Course Code CF281. See the IBM Training Web site for more details:

http://www.ibm.com/services/learning/

In addition, hardware requirements must also be planned if your existing data server does not have the capacity to run the existing IDS instance, the DB2 MTK, and DB2 simultaneously.

The IBM Software Migration Project Office (SMPO) can provide sizings nd estimates. Contact the SMPO at:

http://www.ibm.com/software/solutions/softwaremigration/

3.2 Data conversionData conversion is a critical task in a transitioning project, because you must ensure that all data will be moved to the target database with integrity and in a timely manner. There are a number of processes to help with this, including:

� Using the MTK to generate scripts and files or move data online

� Exporting IDS data manually to flat file and importing or loading to DB2

� Exporting the data through pipes

� Using DB2 Information Integrator

� Using an alternative data conversion product

3.2.1 Preparation overviewIn this section, we briefly discuss the steps required to prepare the DB2 target environment to receive the data from the IDS source. The steps include installation of DB2, instance and database creation, and table space planning. Before attempting DB2 installation, we strongly recommend that you to read the installation instructions provided in the IBM DB2 UDB Quick Beginnings for DB2 Servers, GC09-4836. See your IBM Representative for this document and the latest fix packs for DB2.




The tasks required to prepare the DB2 environment include:

1. DB2 V8 installation: The first task is to decide which edition of DB2 fits your business requirements. The application assessment step provides you the base criteria for selection. Regardless of the platform, you need to verify whether or not the system satisfies hardware and software requirements. For the DB2 installation process, we used both AIX and Windows as the platforms for the installation in this book. Installing DB2 ESE on a platform such as Sun Solaris and HPUX requires the modification of the operating system kernel parameters. A system reboot is required afterward.

2. Additional software requirements: There are software considerations when running a database environment. These considerations will revolve around the type of applications accessing the database. If database development is desired, the proper versions of the different software components, such as C or Java compilers, must also be installed on the server.

3. Instance and database creation: The next task is to create a DB2 instance and database. You need to consider details such as instance and database location, required user IDs, and permission requirements.

4. Table space planning: After the database has been created, it becomes ready for object creation, which is space planning for the data. DB2 allows for two types of table spaces, System Managed Space (SMS), which is maintained by the system, and Data Managed Space (DMS), which is maintained by the DB2 administrator. If you are satisfied with the way the data is organized in the source database, you can look for the compatible way to organization the data in the DB2 database. This is also an opportunity for you to change the way the data is placed, which can have an impact on the performance and maintenance. The DB2 manuals IBM DB2 UDB Administration Guide: Planning, SC09-4822, and IBM DB2 UDB Administration Guide: Performance, SC09-4821, provide detailed information.

3.2.2 Data conversion processThe data conversion process can become quite complex depending on the degree of customization. Before defining a transfer method, you should test with only with a portion of the data to validate the selected method. The tests can include a number of potential situations. Therefore, we highly recommend that you start early with testing.

Some of the typical tasks of a test phase include:

� Calculating the source data size and space needed for unloading files to disk

� Selecting the tools and the conversion method

� Testing the conversion using the chosen method with small amount of data


With the results of some simple testing, you should be able to:

� Estimate the time for the complete data conversion process

� Create a plan for the development environment conversion

� Create a plan for the production environment conversion

� Schedule the transition dates and duration

The following items can influence the time and complexity of the process:

� Volume of data and data changes: The more data you have to move, the more time you need. Consider the data changes, as well as such potential issues as time stamp conversions.

� System availability: You can execute the data movement activities either while the production system is down, or while the business process is running by synchronizing the source and target databases. The strategy you choose will drive the determination of whether you need less or more time.

� Hardware resources: Be aware that you might need up to three times the disk space during the data movement for:

– The source data in IDS– The unloaded data stored in the file system– The data loaded into the target DB2

3.2.3 Time planningAfter testing the data movement and choosing the proper tool and strategy, you should create a detailed time plan that includes some of the following tasks:

� Learn and test selected data movement tools� Implement or modify scripts for data unload and load� Unload data from IDS� Load data to DB2� Back up target database� Test loaded data for completeness and consistency� Modify and switch to applications, including database interfaces� Plan a fallback process

One of the more sensitive environments is a production system with a high-availability requirement. Figure 3-1 on page 58 depicts one approach for moving data to the target database in a high-availability environment. The dark areas represent new data, and the lighter areas represent data that has been converted and moved. If possible, export the data from a standby database or mirror database to minimize the impact on the production environment. The some of the tasks to be considered include:

1. Create scripts that export all data up to a defined time stamp.


2. Create scripts that export changed data since the last export. This includes new data and deleted data.

3. Repeat step 2 until all data is moved to the target database.

4. Define a fallback strategy and prepare fallback scripts.

Figure 3-1 Data movement strategy in a high-availability environment

When the data is completely moved to the target database, you can switch the application and database. Prepare a well-defined rollout process for the applications and allow time for unplanned incidents.

3.2.4 The database structureBefore data can be moved, the differences in database structures must be considered. These differences could be a result of a different interpretation of SQL standards or the addition or omission of particular functions. The differences can often be fixed syntactically, but in some cases, you must add functions or modify the application.

One way to describe a database structure is with an entity-relationship (ER) model of the data. This model describes the meaning of each entity, the relationships that exist, and the attributes. From this model, the SQL data definition language (DDL) statements that can be used to create a database can be captured. If the database structure is already in the form of ER metadata (that is, an ER modeling tool was used in the design of the system), it is often possible to have the modeling tool generate a new set of DDL that is specific to DB2. Otherwise, the DDL from the current system must be captured and then modified into a form that is compatible with DB2. After the DDL is modified, it can be

IDS

datamovement

time

IDS IDS

DB2 DB2 DB2


loaded and executed to create a new database (tables, indexes, and constraints) in DB2.

There are three approaches that can be used to move the structure of a DBMS:

� Manual: Create the structure in DB2, by hand and manually adjust for issues.

� Metadata transport: Extract the metadata (often called the schema) and import it to DB2.

� Migration tools: Use a tool to extract the structure, adjust it, and then implement it in DB2.

3.2.5 Data movement approachesThere are a number of ways to accomplish data movement during the process. We give a brief overview of some of them in the following list:

� Through flat files: Before writing data into flat file, ensure that the maximum file size of your operating system is big enough to hold the exported files. On UNIX systems, this is typically accomplished with the ulimit command. The data can then be loaded or imported into DB2 with any tool or application desired.

� Using the MTK: In 8.2.5, “Generating Data Transfer Scripts tab” on page 263, we explain how to use the MTK to generate scripts for data unload and data load, as well as the correlation of scripts and table definitions of the source and target. The MTK enables you to move data through its GUI online and without generated scripts. When moving data online, the MTK does not use the generated scripts when deploying the load/import from the GUI.

� With named pipes: As described in 3.2.2, “Data conversion process” on page 56, you might need additional disk space to execute the data movement process. To avoid the required extra space for the flat files when using UNIX-based systems, you can use named pipes. To use this function, the writer and reader of the named pipe must be on the same machine. In addition, you must create the named pipe on a local file system before exporting data from the IDS database.

Because the named pipe is treated as a local device, there is no need to specify that the target is a named pipe. The following steps show an AIX example:

a. Create a named pipe:

mkfifo /u/dbuser/mypipe

b. Use this pipe as the target for the data unload operation:

<data unload routine> > /u/dbuser/mypipe


c. Load the data into DB2 from the pipe:

<data load routine> < /u/dbuser/mypipe

The commands in steps b and c only show the principle of using the pipes.

� Third-party tools: There is another class of tools called extraction, transformation, and load (ETL) tools. These tools are specifically designed for taking data out of a source, transforming or translating it, and then loading it into a target. There are several third-party tools that work with both IDS and DB2, including Ascential DataStage and Informatica PowerMart.

3.2.6 DB2 Information IntegratorDB2 Information Integrator is a technology that enables DB2 to federate disparate data sources. Federation means that data can reside in different sources, but can appear as a single source.

In a high-availability environment, you might have to move the data during production activity. A practical solution is the replication facility of the DB2 Information Integrator.

IBM DB2 Information Integrator provides integrated, real-time access to diverse data as though it were a single database, regardless of where it resides. As a result, you are able to hold the same data both in IDS and in DB2. You are then free to switch to the new DB2 database when the functionality of the ported database and application is guaranteed.

The DB2 replication server, formerly known as DB2 data propagator, now known as DB2 SQL replication, lets users manage data movement strategies between mixed relational data sources, including distribution and consolidation models.

Data movement can be managed one table at a time, such as for data warehouse loading during batch windows, or with transaction consistency for data that is never offline. It can be automated to occur on a specific schedule, at designated intervals, continuously, or as triggered by events. Transformation can be applied inline with the data movement through standard SQL expressions and stored procedure execution. For porting data, you can use the replication server to support data consolidation, moving data from IDS to DB2.

For more information about replication, see the IBM Redbook A Practical Guide to DB2 UDB Data Replication V8, SG24-6828, and the IBM DB2 Information Integrator Developer's Guide Version 8, SC18-7359.

Note: It is important to start the pipe reader after starting the pipe writer. Otherwise, the reader will find an empty pipe and exit immediately.


3.2.7 Modifying the applicationAlthough transitioning the database structure and objects can be automated to some extent, application code changes will require manual conversion for the most part. If all database interaction is restricted to a database access layer, the scope and complexity of necessary changes is well-defined and manageable. However, when database access is not isolated to a database access layer (that is, it is distributed throughout application code files, contained in stored procedures or triggers or both, or used in batch programs that interact with the database), the effort required to convert and test the application code depends on how distributed the database access is and on the number of statements in each application source file that require conversion.

It is important to first migrate the database structure (DDL) and database objects (stored procedures, triggers, and user-defined functions). It is then useful to populate the database with a test set of data so that the application code can be ported and tested incrementally.

Few tools are available to transition actual application code, because much of the work is dependent on vendor-specific issues. These issues include adjustments to logic to compensate for differing approaches to transaction handling, join syntax, use of special system tables, and use of internal registers and values. Manual effort is normally required to make and test these adjustments. Often, proprietary functions used in the source DBMS will have to be emulated under DB2, usually by creating a DB2 user-defined function or stored procedure, or both, with the same name as the proprietary one being ported. This way, any SQL statements in the application code that call the proprietary function in question will not need to be altered. The DB2 MTK is equipped with some of the most commonly used vendor-specific functions and will automatically create a DB2-equivalent function (or stored procedure) during the migration process.

Another issue when porting high-level language code (such as C, C++, Java, and COBOL) involves compiler differences. Modifications to the application code might be required if a different compiler, object library, or both are used in the DB2 environment. This might be caused by the selection of a different hardware or OS platform. It is vital to fully debug and test such idiosyncrasies before moving a system into production.

Note: The new IBM DB2 Q-Replication mechanism is currently for DB2 only and does not work with IDS. SQL Replication, conversely, can be used with IDS.


3.2.8 Database objects and interfacesIn this section, we describe database objects and interfaces that will be encountered during the modification of the applications

Database objectsDatabase objects (stored procedures, triggers, and user-defined functions) are part of the application logic that is contained within the database. Most of these objects are written in a language that is very specific to the source DBMS, or are written in a higher-level language that then must be compiled and somehow associated or bound to the target DBMS for use.

Capturing the database objects can often occur at the same time that the database structure is captured if the objects are written in an SQL-like procedural language and stored within the database. To do this, you would use one of the porting and migration tools. For those objects written in higher-level languages, such as Java or C, capture and import means transferring the source files to the DB2 system and finding a compatible compiler and binding mechanism.

Stored procedures and triggers will have to be converted manually unless the tool used to extract the objects understands the stored procedure languages of both the source DBMS and DB2. The DB2 MTK is an example of a tool that can aid in the conversions of stored procedures and triggers. However, you can expect inconsistencies between the dialects of procedural languages, including how data is returned, how cursors are handled, and how looping logic is or is not used.

Objects that are written in high-level languages must usually be dealt with manually. If embedded SQL is included in the objects, it can be extracted and run through a tool that might be able to help convert the SQL code to be compatible with DB2. After that, each section can be replaced and then compiled with the modified high-level code.

After the conversion is completed, some adjustments will probably still be required. Issues such as identifier length might still need to be addressed. This can be done manually, by looking at statistics such as all database names over a certain length, and then doing a global search and replace on the names that appeared, or by using a tool such as the DB2 MTK that understands what to look for and how to fix it.

Note: The conversion of objects will require testing. This might mean that test data will be needed and must be populated into the database structure before testing can occur.


Database interfacesApplications that connect to the source database using a standardized interface driver, such as ODBC and JDBC, usually require few changes to work with DB2. In most cases, simply providing the DB2 supported driver for these interfaces is enough for the application to run with a DB2 database.

There are certain circumstances where the DB2-supported driver for an interface does not implement or support one or more features specified in the interface standard. It is in these cases where you must take action to ensure that application functionality is preserved after the transition. This usually involves changing application code to remove references to the unsupported functions and either replacing them with supported ones, or simulating them by other means.

Applications that use specialized or native database interfaces will require application code changes. Such applications can be ported using the DB2 native CLI interface, or by using a standardized interface such as ODBC or JDBC. If porting to CLI, many native database-specific function calls will need to be changed to the CLI equivalents. This is not usually an issue, because most database vendors implement a similar set of functions. The DB2 CLI is part of the SQL standard, and the mappings of functions between other source DBMSs and DB2 CLI can be found in the applicable DB2 porting guide.

DB2 also provides a library of administrative functions for applications to use. These functions are used to develop administrative applications that can administer DB2 instances, backup and restore databases, import and export data, and perform operational and monitoring functions. These administrative functions can also be run from the DB2 command line processor (CLP), Control Center, and scripts.

Some of the common interfaces used with DB2 include:

� JDBC and SQLJ: DB2 provides several JDBC drivers to write dynamic SQL programs in Java. DB2 provides support for the Type 2, Type 3, and Type 4 drivers.

SQLJ offers developers a way to write static SQL programs using Java. SQLJ programs generally outperform their JDBC counterparts, because the query access plans of executable statements have been optimized before runtime.

� Embedded SQL (static and dynamic): DB2 provides programmers the option of writing applications with SQL statements directly embedded within the host language. The SQL statements provide an interface to the database while the host language provides facilities to perform the application logic. DB2 supports several host languages, including C/C++, FORTRAN, COBOL, and Java (SQLJ). Programmers have the option of using static or dynamic SQL, depending on the nature of the application.


� ODBC: The Microsoft ODBC standard provides a set of APIs for accessing a specific vendor database. Vendors must supply their own driver that implements a subset of the API for accessing the database. The DB2 CLI driver can be used on its own to access a DB2 database or as an ODBC driver. DB2 conforms to most of the Level 3 compliance level for ODBC.

� ADO and OLE DB: Microsoft ActiveX Data Objects provide a set of methods for accessing data from a wide variety of data sources, including relational databases, HTML, video, text, and just about any other source of data. Access to the data is handled by ADO and is accessed through a service such as OLE DB or ODBC. In order to use OLE DB with DB2, you must first download the newest driver from the OLE DB Web page.

� Microsoft .NET: .NET is the new Microsoft development platform that competes with the J2EE standard. The .NET framework programming model enables developers to build Web-based applications, smart client applications, and XML Web services applications that expose their functionality programmatically over a network using standard protocols such as SOAP and HTTP. Full support for the .NET standard for DB2 is on the way. Currently, IBM is offering a .NET driver program for developers interested in writing applications using the .NET standard.

� Perl DB: DBI is an open standard API that provides database access for client applications written in Perl. DBI defines a set of functions, variables, and conventions that provide a platform-independent database interface.

� DB2 CLI: The DB2 CLI driver implements most of the function set defined in the ODBC standard, as well as additional functionality specific to DB2. This interface offers more available functionality than do the other non-embedded and driver options.

� Stored procedures: Another popular method of interfacing with the database is through stored procedures. Stored procedures can be written in DB2 SQL procedural language, or in an external programming language such as C/C++ or Java. Restricting database access through stored procedures offers numerous benefits such as a reduction in network traffic (all processing takes place on the server) and providing an additional layer of isolation between the application code and business logic.


3.3 After the transitionIn addition to the fundamentals of database administration, do not forget these other key administrative functions:

� Backup and recovery: To prevent loss of data, you should have an adequate strategy for saving the data in your databases and for being able to restore it in case of a failure or error. The larger the amount of data you have, the longer and more sophisticated your strategy will become, especially if you need your database always online.

� Replication: The DB2 replication feature enables you to transfer data between systems for the purpose of building new data stores and duplicating all, or some, of the original data in another DBMS.

� High availability: This ensures that your data sources are always available for use, even if there is a hardware or software failure. This concept is closely related to the backup and recovery process and is often implemented at the same time.

� Federation: Federation allows access to data in numerous, heterogeneous data stores from one query. This section introduces the federation concepts and guides you to resources that will assist in creating a federated design.

This has been a brief overview of some of the alternatives available and considerations for transitioning. IBM also has a full set of offerings available to help you. If you would like IBM to perform some or all of your transition activities, contact your IBM Representative.


Chapter 4. Configuration

This chapter is intended to help in the configuration of the DB2 instance or instances prior to transitioning from IDS.

IDS and DB2 will prove to be similar in many areas, but they also are significantly different in other areas. Having a good understanding of the architecture of DB2 (see Chapter 2, “Architectures” on page 11) will help tremendously with configuration challenges and tasks.

This chapter does not intend to make recommendations for ongoing performance tuning, but intends to express best practices for initial configuration. Of course, some configuration choices inherently influence the performance of the DB2 instance. In these cases, we make comments with regards to performance implications.

For more details about the syntax and creation of objects in DB2, refer to Chapter 5, “Instance and database operations” on page 133.

4


4.1 IDS and DB2 configurationIDS and DB2 configuration are very similar in many ways. However, there are many significant differences. This section describes the similarities and differences a high level.

4.1.1 Knobs, configuration, and tuningA DB2 instance has many more “knobs” (configuration files and parameters) for configuration and tuning than an IDS instance. Some customers view this as a positive feature, because this gives the DBA more choices. But other customers and developers view this as more of a possibility to get into trouble. Having many choices is good if there is a good understanding of what each parameter does. If a DBA blindly wanders in and sets configuration parameters, the results would mirror the DBA’s actions, that is, the results would be rather random and unpredictable.

4.1.2 CommandsThere is more verbosity to the DB2 configuration commands as compared to IDS. This will become less of a concern to you as the DB2 product is used more over time and as you learn the commands. There are also other ways to address this issue, such as using operating system command aliases, using DB2 built-in abbreviations, or using the DB2 GUI Control Center.

4.1.3 GranularityWhen configuring or tuning DB2, the DBA might notice that many more “knobs” (configuration files and tuning parameters) are at the individual database, table, or connection level, while with IDS, many configuration files and tuning parameters are shared among all users at the instance level.

Other than “knobs,” a few other examples of where DB2 is different from IDS in granularity include:

� Logical logs: In DB2, if the instance has more than one database, each database will have its own set of logical logs. IDS has one set of logical logs per instance.

� Configuration files: In DB2, each database will have a configuration file that can be configured and tuned independently of other databases. IDS has one configuration file per instance.


� Buffer pools: In DB2, each table space (data or index) can have a buffer pool. If there are multiple page sizes in the database, each table space will have a buffer pool. Currently, IDS has one uniform buffer pool per instance.

4.1.4 Database managerDB2 has the concept of a database manager that houses all the databases. This is also known as the instance. The database manager, or DBM, also has its own configuration file that is different from individual database configuration files. This concept is very useful, because it enables you to tune each database independently from each other and from the instance.

However, in IDS, different databases within the instance do not have their own set of configuration files and parameters. Databases might be created with different settings such as “log mode,” but still, they do not have their own separate set of configuration parameters. The onconfig file has settings for the instance that affects every user and database. It does not, however, have configuration parameters for each database.

4.1.5 Dynamic parametersWith IDS, in some cases, the instance must be bounced before parameter changes can take effect. The term bounced indicates that the instance is taken offline and then brought back online.

With DB2, three different levels of configuration must be considered:

� Database manager (DBM) configuration parameters: These are typically considered instance-level parameters and might require an instance bounce.

� Registry profile settings: These settings can be changed without stopping and restarting the instance.

� Database (DB) configuration parameters: When changing most of these settings, only the database must be stopped and restarted, not the entire instance.

4.1.6 CatalogingThis term takes on two very distinct meanings within DB2. Many times the system tables are referred to as system catalogs in the same way as with IDS.

Note: Some of the settings for these three different types of parameter levels still require an instance stop and a restart before they take effect. Consult the documentation.

Chapter 4. Configuration 69

“Cataloging” is also used a great deal in the configuration of clients, databases, and DB2 nodes. There is even a catalog command that is associated with these configuration tasks.

4.1.7 Client access to DB2 instancesWith IDS, for a client to access an IDS instance, the connectivity is typically through the $INFORMIXSERVER environment variable. After this is set to point to a valid sqlhosts file entry, the client can access the instance.

DB2 relies more on the client cataloging the remote node and database. Many methods are available to do this task, and we describe some of them in subsequent sections of this chapter.

Keep in mind that cataloging can be done manually, or automatically using Discovery, but only if the DB2 instances are configured to support Discovery. There are many ways to configure Discovery. We provide more details about Discovery in the subsequent sections of this chapter.

4.2 Configuration methodsWe do not cover IDS configuration methods in full detail, because it is assumed that you are already familiar with them. However, the following list gives a brief summary:

� Command line: IDS users have typically preferred to use the command line approach to configuration, which is a more standard approach for UNIX users.

� The onmonitor utility (menu-driven): For many years, IDS had a character-based, menu-driven utility called onmonitor available for configuration. The tool was not widely used by advanced users, who normal chose the command line for configuration.

� The Informix Enterprise Command Center (IECC): Informix, at one point, developed a GUI product called the Informix Enterprise Command Center (IECC). This product never reached its full potential, and eventually the project was cancelled.

� Informix Server Administrator (ISA): This is a Web-based configuration and administration utility that allows DBAs to control and configure many engines from one browser window.


4.2.1 DB2 configuration methodsDB2 has more knobs that can be used to build and administer an instance. DB2 also has a broader choice of configuration tools and utilities.

Command lineThe DB2 product has command line utilities for configuration. Again, IDS administrators might find the commands themselves very verbose. But over time, this will ease, because the usage will seem less cumbersome. A DBA can also alias or script the commands to be more “friendly” if needed.

GUI tools For many years, DB2 users in the UNIX or Microsoft Windows environments had access to many GUI tools for administration, monitoring, and configuration. DB2 V8.2 continues with this tradition in that there are new tools and many improvements of the existing tools. GUI tools are one of the greatest strengths of DB2.

The DB2 Control CenterThe DB2 Control Center is a very powerful utility for configuring DB2. Figure 4-1 on page 72 shows a high-level view of the DB2 Control Center. See Chapter 14, “Administrative operations” on page 419 for further details about the use of Control Center.

Important: The DB2 tools, such as the Control Center, should not be likened to the Informix product IECC from the past. The DB2 tools are much more robust, intelligent, and highly useful for DBA and administrators.

Tip: For almost every choice within the DB2 GUI tools, there is a command line equivalent that can be displayed. This is an excellent way to learn commands and obtain exact command line syntax.


Figure 4-1 The DB2 Control Center

DB2 Control Center wizardsOne area of strength in DB2 is the Control Center wizards. For configuration of the instance and databases, there are a number of these wizards that are very useful. Figure 4-2 on page 73 shows a list of the wizards.


Figure 4-2 DB2 Control Center wizards

Using the Control Center for command generationA very valuable use of the DB2 Control Center is the ability to derive the CLP command for an operation. You can simply point-and-click the operation requested. For almost every operation, there is a “Show SQL” button that will display the actual syntax. This could be very valuable to an IDS administrator not comfortable with some of the verbose DB2 commands. For example, assume a new DB2 DBA wants to create an SMS table space called NJ_Tablespace, with a number of characteristics (to be covered in later sections). After using the Control Center and selecting the specific options, a “Show SQL” button is presented, as depicted in Figure 4-3 on page 74.

Tip: Use the Control Center to derive the command line syntax for a particular operation.


Figure 4-3 Control Center generation of SQL command

Example 4-1 documents the command derived by the Control Center.

Example 4-1 Deriving commands with the Control Center

CONNECT TO MARK;CREATE REGULAR TABLESPACE NJ_TABLESPACE PAGESIZE 4 K MANAGED BY SYSTEM USING ('/home/marks/large_pb' ) EXTENTSIZE 32 OVERHEAD 12.67 PREFETCHSIZE 32 TRANSFERRATE 0.18 BUFFERPOOL IBMDEFAULTBP DROPPED TABLE RECOVERY ON;COMMENT ON TABLESPACE NJ_TABLESPACE IS 'NJ''s Tablespace';CONNECT RESET;

The Configuration AssistantPreviously known as the DB2 Client Configuration Assistant, the new DB2 Configuration Assistant has been tightly integrated with the Control Center and is enhanced with many new features, such as:

� The ability to invoke the Control Center from the Configuration Assistant

� The option to configure both local and remote servers, including DB2 Connect™ servers

� The ability to create configuration templates without affecting the local configuration


� Import and export capabilities for exchanging configuration templates with other systems

� Improved response time for Discovery requests, along with the option to refresh the list of discovered objects at any time

� The ability to view and update applicable database manager configuration parameters and DB2 registry variables

Figure 4-4 shows the DB2 Configuration Assistant.

Figure 4-4 The DB2 Configuration Assistant

4.2.2 Configuration Advisor and AUTOCONFIGUREThe Configuration Advisor wizard can be invoked from the Control Center by selecting Tools → Wizards → Configuration Advisor. The wizard presents a series of windows with questions regarding your environment and application workload, and then generates a window showing suggested parameter settings, as shown in Figure 4-5 on page 76.


Figure 4-5 Configuration Advisor wizard

Example 4-2 on page 77 shows the script generated for the sample database by the Configuration Advisor using most (but not all) of the default settings.

Note: Configuration Advisor executes on the target DB2 system and performs auto discovery of the target DB2 environment’s available resources before coming up with its recommendations for the various configuration parameters.


Example 4-2 Database manager and database configuration parameters set

UPDATE DATABASE CONFIGURATION FOR SAMPLE USING APP_CTL_HEAP_SZ 128;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING BUFFPAGE 118915;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING CATALOGCACHE_SZ 343;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING CHNGPGS_THRESH 60;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING DBHEAP 600;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOCKLIST 50;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOGBUFSZ 65;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOGFILSIZ 1024;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOGPRIMARY 3;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOGSECOND 0;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING MAXAPPLS 40;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING MAXLOCKS 60;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING MINCOMMIT 1;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING NUM_IOCLEANERS 1;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING NUM_IOSERVERS 4;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING PCKCACHESZ 859;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING SOFTMAX 120;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING SORTHEAP 192;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING STMTHEAP 2048;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING DFT_DEGREE 1;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING DFT_PREFETCH_SZ 32;UPDATE DATABASE CONFIGURATION FOR SAMPLE USING UTIL_HEAP_SZ 39638;UPDATE DATABASE MANAGER CONFIGURATION USING SHEAPTHRES 1140;UPDATE DATABASE MANAGER CONFIGURATION USING INTRA_PARALLEL OFF;UPDATE DATABASE MANAGER CONFIGURATION USING MAX_QUERYDEGREE 1;UPDATE DATABASE MANAGER CONFIGURATION USING MAXAGENTS 400;UPDATE DATABASE MANAGER CONFIGURATION USING NUM_POOLAGENTS 400;UPDATE DATABASE MANAGER CONFIGURATION USING NUM_INITAGENTS 0;UPDATE DATABASE MANAGER CONFIGURATION USING FCM_NUM_BUFFERS 4096;UPDATE DATABASE MANAGER CONFIGURATION USING FCM_NUM_RQB 0;CONNECT TO SAMPLE;ALTER BUFFERPOOL IBMDEFAULTBP SIZE 118915;COMMIT;CONNECT RESET;

The autoconfigure command delivers the same results as the Configuration Advisor wizard by accepting the same input through the options listed and described in Table 4-1 on page 78. The autoconfigure command calculates and displays the optimum values for the buffer pool size, database configuration, and

Note: These recommendations should be validated through actual measurements in regression test environments before committing the changes in the production environment.


database manager configuration parameters, with the option of applying these recommended values immediately.

The AUTOCONFIGURE option can also be used with the CREATE DATABASE command to configure databases as soon as they are created. This feature calculates and displays initial values for the buffer pool size, database configuration, and database manager configuration parameters, with the option of applying these recommended values.

Example 4-3 shows the syntax for the AUTOCONFIGURE option.

Example 4-3 AUTOCONFIGURE from the command line

AUTOCONFIGURE [USING config-keyword value [{config-keyword value}...]][APPLY {DB ONLY | DB AND DBM | NONE}]

config-keyword: MEM_PERCENT, WORKLOAD_TYPE, NUM_STMTS, TPM, ADMIN_PRIORITY, IS_POPULATED NUM_LOCAL_APPS, NUM_REMOTE_APPS, ISOLATION, BP_RESIZEABLE.

There are many options and settings for the AUTOCONFIGURE utility. Table 4-1 shows these options, values, and their explanations.

Table 4-1 AUTOCONFIGURE configuration keywords

Keyword Valid values Default value

Explanation

mem_percent 1-100 80 Percentage of memory to dedicate. If other applications (other than the operating system) are running on this server, set this to less than 100.

workload_type simple, mixed, complex

mixed Simple workloads tend to be I/O intensive and mostly transactions, while complex workloads tend to be CPU intensive and mostly queries.

num_stmts 1-1,000K 10 Number of statements per unit of work.

tpm 1-200,000 60 Transactions per minute.

admin_priority performance, recovery, both

both Optimize for better performance (more transactions per minute) or better recovery time.

is_populated yes, no yes Is the database populated?


For more details about the autoconfigure command, refer to IBM DB2 UDB Command Reference, SC09-4828.

4.3 Configuration files and objects overviewIDS and DB2 have roughly similar configuration files and objects, but there are some significant differences. Figure 4-6 on page 80 shows a high-level view of the configuration files and objects.

num_local_apps 0-5000 0 Number of connected local applications.

num_remote_apps 0-5,000 10 Number of connected remote applications.

isolation RR, RS, CS, UR

RR Isolation level of applications connecting to this database (Repeatable Read, Read Stability, Cursor Stability, Uncommitted Read).

bp_resizeable yes, no yes Are buffer pools resizable?

Keyword Valid values Default value

Explanation


Figure 4-6 Configuration files and objects

Some of the configuration objects shown in Figure 4-6 can be modified dynamically and take effect immediately.

When changing parameters with IDS, the DBA typically edits the $ONCONFIG file directly, and often an instance stop and restart is necessary. However, which parameters require an instance stop and restart is not obvious. The DBA must know whether this is necessary or not.

With DB2, the DBA modifies one of the configuration files through the command line commands, not by direct editing. If it is necessary to stop and restart the instance, or deactivate and activate a database, the DBA is notified of this by the command.

4.3.1 Environment variables and the profile registryEnvironment and registry variables control your database environment.

You can use the Configuration Assistant (db2ca) to configure configuration parameters and registry variables.

Users on UNIX operating systems with system administration (SYSADM) authority for a given instance can update registry values for that instance.

Computerkernelparameters

environmentvariables

registryprofilevariables

configurationparameters(onconfig)

sqlhostsfile

databasemanager (DBM)configurationparameters

database (DB)configurationparameters

DB2

Instance

databaselog mode:not logged, logged,mode ANSI

Database

IDS

DB2 Directories:• System Database Directory• Local Database Directory• Node Directory• DCS Directory• Administration Node Directory

IDS Directories:• $INFORMIXDIR


Windows users do not need SYSADM authority to update registry variables. Use the db2set command to update registry variables without rebooting; this information is stored immediately in the profile registries. The DB2 registry applies the updated information to DB2 server instances and DB2 applications started after the changes are made.

When updating the registry, changes do not affect the currently running DB2 applications or users. Applications started following the update use the new values.

Using the profile registry allows for centralized control of the environment variables. Different levels of support are now provided through the different profiles. Remote administration of the environment variables is also available when using the DB2 Administration Server.

There are four profile registries:

� The DB2 Instance Level Profile Registry: The majority of the DB2 environment variables are placed within this registry. The environment variable settings for a particular instance are kept in this registry. Values defined in this level override their settings in the global level.

� The DB2 Global Level Profile Registry: If an environment variable is not set for a particular instance, this registry is used. This registry has the machine-wide environment variable settings. In DB2 UDB ESE, one global-level profile exists at each machine.

� The DB2 Instance Node Level Profile Registry: This registry level contains variable settings that are specific to a partition (node) in a multipartition environment. Values defined in this level override their settings at the instance and global levels.

� The DB2 Instance Profile Registry: This registry contains a list of all instance names recognized by this system. You can see the complete list of all the instances available on the system by running the db2ilist command.

Note: There are DB2 environment variables, DB2INSTANCE and DB2NODE, that cannot be stored in the DB2 profile registries. On some operating systems, the set command must be used in order to update these environment variables. These changes are in effect until the next time the system is rebooted. On UNIX platforms, the export command can be used instead of the set command.


4.3.2 DB2 registry and environment variablesThis section lists DB2 registry and environment variables that you might need to know about to get up and running. Each variable has a brief description. Some variables might not apply to your environment.

The registry and environment variables that you might need to know include:

� To display help information for the command, use:

db2set ?

� To view a list of all supported registry variables, use:

db2set -lr

� To change the value for a variable in the current or default instance, use:

db2set registry_variable_name=new_value

� To list all defined registry variables for the current or default instance, use:

db2set

� To list all defined registry variables in the profile registry, use:

db2set -all

� To show the value of a registry variable in the current or default instance, use:

db2set registry_variable_name

� To show the value of a registry variable at all levels, use:

db2set registry_variable_name -all

� To change a registry variable for in the current or default instance, use:

db2set registry_variable_name=new_value

� To change a registry variable default for all databases in the instance, use:

db2set registry_variable_name=new_value -i instance_name

� To change a registry variable default for a particular partition in an instance, use:

db2set registry_variable_name=new_value -i instance_name node_number

Note: Whether the DB2 environment variables, DB2INSTANCE, DB2NODE, DB2PATH, and DB2INSTPROF, are stored in the DB2 profile registries depends on your operating system. To update these environment variables, use the set command. These changes are in effect until the next time the system is rebooted. On UNIX platforms, you can use the export command instead of the set command. You must set the values for the changed registry variables before you execute the DB2START command.


� To change a registry variable default for all instances in the system, use:

db2set registry_variable_name=new_value -g

� If you use the Lightweight Directory Access Protocol (LDAP), you can set registry variables in LDAP using:

To set registry variables at the user level within LDAP, use:

db2set -ul

To set registry variables at the global level within LDAP, use:

db2set -gl user_name

� When running in an LDAP environment, it is possible to set a DB2 registry variable value in LDAP such that its scope is global to all machines and all users that belong to a directory partition or to a Microsoft Windows NT® domain. Currently, there are only two DB2 registry variables that can be set at the LDAP global level: DB2LDAP_KEEP_CONNECTION and 4DB2LDAP_SEARCH_SCOPE.

For example, to set the search scope value at the global level in LDAP, use:

db2set -gl db2ldap_search_scope = value

Where the value can be local, domain, or global.

Notes:

� There is a difference between the -g option, which is used to set DB2 registry variables at the machine global level, and the -gl option, which is specific to the LDAP global level.

� The user level registry variable is only supported on Windows when running in an LDAP environment.

� Variable settings at the user level contain user-specific variable settings. Any changes to the user level are written to the LDAP directory.

� The parameters -i, -g, -gl, and -ul cannot be used at the same time in the same command.

� Some variables will always default to the global-level profile. They cannot be set at the instance or node level profiles, for example, DB2SYSTEM and DB2INSTDEF.

On UNIX, you must have system administration (SYSADM) authority to change registry values for an instance. Only users with root authority can change parameters in global-level registries.


� To reset a registry variable for an instance back to the default found in the global profile registry, use:

db2set -r registry_variable_name

� To reset a registry variable for a node in an instance back to the default found in the Global Profile Registry, use:

db2set -r registry_variable_name node_number

� To delete a variable's value at a specified level, you can use the same command syntax to set the variable, but specify nothing for the variable value. For example, to delete the variable's setting at the node level, enter:

db2set registry_variable_name= -i instance_name node_number

� To delete a variable's value and to restrict its use, if it is defined at a higher profile level, enter:

db2set registry_variable_name= -null instance_name

This command will delete the setting for the parameter you specify and restrict high-level profiles from changing this variable's value (in this case, the DB2 global-level profile). However, the variable you specify could still be set by a lower-level profile (in this case, the DB2 node-level profile).

Setting environment variables on UNIX systemsWe strongly recommend that all DB2-specific registry variables be defined in the DB2 profile registry. If DB2 variables are set outside of the registry, remote administration of those variables is not possible.

On UNIX operating systems, you must set the system environment variable DB2INSTANCE.

The scripts db2profile (for the Korn shell) and db2cshrc (for the Bourne shell or C shell) are provided as examples to help you set up the database environment. You can find these files in insthome/sqllib, where insthome is the home directory of the instance owner.

These scripts include statements to:

� Update a user's path with the following directories:

– insthome/sqllib/bin

– insthome/sqllib/adm

– insthome/sqllib/misc

� Set DB2INSTANCE to the default local instance_name for execution.


An instance owner or SYSADM user can customize these scripts for all users of an instance. Alternatively, users can copy and customize a script, and then invoke a script directly or add it to their .profile or .login files.

To change the environment variable for the current session, issue commands similar to the following:

� For the Korn shell:

DB2INSTANCE=inst1; export DB2INSTANCE

� For the Bourne shell:

export DB2INSTANCE=<inst1>;

� For the C shell:

setenv DB2INSTANCE <inst1>

In order for the DB2 profile registry to be administered properly, the following file ownership rules must be followed on UNIX operating systems:

� The DB2 Instance Level Profile Registry file is located under INSTHOME/sqllib/profile.env.

The access permissions and ownership of this file should be:

-rw-rw-r-- <db2inst1> <db2iadm1> profile.env

Where <db2inst1> is the instance owner, and <db2iadm1> is the instance owner's group.

INSTHOME is the home path of the instance owner.

� The DB2 Global Level Profile Registry is located under:

– /var/db2/<version_id>/default.env for AIX, Solaris, and Linux operating systems (where <version_id> is the current version)

– /var/opt/db2/<version_id>/default.env for the HP-UX operating system (where <version_id> is the current version)


-rw-rw-r-- <Instance_Owner> <Instance_Owner_Group> default.env

In order to modify a global registry variables, a user must be logged on as root.

Note: Except for PATH and DB2INSTANCE, all other DB2-supported variables must be set in the DB2 profile registry. To set variables that are not supported by DB2, define them in your script files, userprofile and usercshrc.


� The DB2 Instance Node Level Profile Registry is located under INSTHOME/sqllib/nodes/<node_number>.env.

The access permissions and ownership of the directory and this file should be:

drwxrwsr-w <Instance_Owner> <Instance_Owner_Group> nodes -rw-rw-r-- <Instance_Owner> <Instance_Owner_Group> <node_number>.env

INSTHOME is the home path of the instance owner.

� The DB2 Instance Profile Registry is located under:

– /var/db2/<version_id>/profiles.reg for AIX, Solaris, and Linux operating systems (where <version_id> is the current version)

– /var/opt/db2/<version_id>/profiles.reg for the HP-UX operating system (where <version_id> is the current version)


-rw-r--r-- root system profiles.reg

4.3.3 DB2 configuration files and objectsDB2 does not have specific files that can be edited with your favorite UNIX editor. The configuration files are updated through a command line or Control Center command.

DB2 directoriesAccess to both local and remote databases uses entries in the DB2 directories. Directories hide the requirement for the user to know where a database actually resides. The five directories are:

� System database directory: The system database directory resides in the SQLDBDIR subdirectory in the instance directory and is used to catalog both local and remote databases.

� Local database directory: The local database directory resides in every drive or path that contains a database. It is used to access local databases in that subdirectory.

� Node directory: Each database client has a node directory. It contains entries for all instances that the client will access, including information about the network connection to the instance. If multiple instances exist on a remote machine, each instance must be cataloged as a separate node before you are able to access any information with the instance.

� DCS directory: The directory holds the connection information for DRDA® host databases. This directory only exists if DB2 Connect is installed on your system.


� Administrative node directory: This directory contains one definition for each remote system that is known to a DB2 client.

Database manager configuration fileThe database manager, or DBM, configures the instance. These settings affect all databases and users connecting to this instance of DB2.

To view the configuration for a database manager, there are two choices:

db2 get database manager configuration

Or:

db2 get dbm cfg

The full output from these commands is in the command log file.

Figure 4-7 Using grep to view configuration parameters

Updating configuration parametersTo update configuration parameters for the instance, use the following syntax:

UPDATE DATABASE MANAGER CONFIGURATION USING parametername value

Or:

UPDATE DBM CFG USING parametername value

Tip: Many IDS DBAs have “complained” about the long list of parameters that are presented when asking to view the configuration files. A very simple way to make this simpler is by using the grep command to only return the parameters you want. The -i options makes it case-insensitive. For example, to return on the parameters for the database manager that include “agents”, use:

db2 get dbm cfg | grep -i agents

Figure 4-7 shows this.


Example 4-4 shows the update of the util_impact_lim parameter, which enables the database administrator to limit the performance degradation of a throttled utility on the workload. Here, we set util_impact_lim to a value of 5, which means that invoking any throttled utility will not impact the workload by more than 5%.

Example 4-4 Updating a database manager configuration parameter

cindym:/home/db2inst2/sqllib> db2 update dbm cfg using util_impact_lim 5DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

To reset instance configuration values to their defaults, use the command:

RESET DATABASE MANAGER CONFIGURATION (Or RESET DBM CFG)

Database configuration fileThe commands for database configuration parameters are:

GET DATABASE CONFIGURATION (or GET DB CFG) [ FOR database_name ]

For example:

DB2 GET DB CFG FOR ifmx2db2

The output is shown in Example 4-5.

To reset database configuration values to their defaults, use the command:

RESET DATABASE CONFIGURATION (or RESET DB CFG)

To update a database configuration parameter, use the command:

UPDATE DATABASE CONFIGURATION USING parametername value

Or:

UPDATE DB CFG USING parametername value

Example 4-5 Update to database configuration file

db2inst2:/home/db2inst2> db2 update db cfg for ifmx2db2 using softmax 120DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.SQL1363W One or more of the parameters submitted for immediate modification were not changed dynamically. For these configuration parameters, all applications must disconnect from this database before the changes become effective.

Viewing and updating your configuration using APIsYou can view and update configuration parameters using an application program interface (API) from within an application program, such as C or Java. This is a


convenient way of making temporary configuration changes to suit your application environment. For more details about configuration parameters, including their use with the above methods, refer to IBM DB2 UDB Administration Guide: Performance, SC09-4821.

4.3.4 Configuring DB2 clients and serversIn this section, we describe how you can configure DB2 clients and servers.

Client setupThere are a variety of methods for configuring client applications to access DB2. With the exception of applications that use a JDBC Type 4 driver to communicate to the database, client software is required. This is the same as for IDS.

Prior to configuring communications for the client, you will first need to install the appropriate client software. It is useful to note that the install process includes an unattended option that provides automation for installing remote clients using a response file. For further details, see Chapter 4 of the IBM DB2 UDB Installation and Configuration Supplement, GC09-4837. For this project, we assume that you have already installed the client software.

Configuring remote access to a server databaseAfter you have installed the DB2 client, you can configure DB2 to access remote databases individually on each client workstation through several methods.

The basic configuration tasks are:

1. Configure the server for TCP/IP.

2. Update the server’s services file with the DB2 service name and port number.

3. Configure the client.

If you installed DB2 using the db2setup command, the server is already configured for TCP/IP. If not, you will need to first issue the commands set DB2COMM=TCPIP and update dbm cfg using svcename servicename on the server. (For more details, refer to 4.4, “Client-to-server communications protocols” on page 94 of this chapter and also the IBM DB2 UDB Installation and Configuration Supplement, GC09-4837.)

You can set up the client using one of the following four methods:

� Use the Configuration Assistant tool.

� Import profiles using the Configuration Assistant Tool. A client profile contains database information that was cataloged on another client system. This is a useful method of propagating client information to multiple computers.


� Use the DB2 Control Center tool.

� Use the command line. With this method, you will need to use the catalog command for the remote node and database:

– The CATALOG NODE command specifies the protocol information about how to connect to the host or to the server.

– The CATALOG DATABASE command catalogs the remote database name and assigns it a local alias.

– The CATALOG DCS command specifies that the remote database is a host or OS/400® database. (This command is only required for DB2 Connect Personal or Enterprise Editions.)

– The CATALOG ODBC DATA SOURCE command registers the DB2 database with the ODBC driver manager as a data source. See IBM DB2 UDB Command Reference, SC09-4828, for details.

4.3.5 Configuring a connection using the Configuration Assistant

DB2 provides a Configuration Assistant (CA) to help with the configuration process. In this section, we describe how to use this assistant.

Using Discovery to identify and set up databasesYou can use the Discovery feature of the Configuration Assistant to search a network for databases and establish a connection.

PrerequisitesBefore you configure a connection to a database using Discovery:

� Ensure that you have a valid DB2 user ID.

� If adding a database to a system that has a DB2 server or DB2 Connect server product installed, ensure that you have a user ID with SYSADM or SYSCTRL authority for the instance.

ProcedureTo add a database to your system using Discovery, perform the following steps:

1. Log on to the system with a valid DB2 user ID.

2. Start the CA. The CA can be started using one of the following methods:

– From the Start menu on Windows systems.

Restriction: A DB2 Administration Server (DAS) must be running and enabled for the Discovery feature of the Configuration Assistant to return information about DB2 systems.


– From an icon on Linux systems. The icon is only available from the instance owner's environment; otherwise, it must be made available using the db2icons command.

– With the db2ca command on Windows and Linux systems.

3. On the CA menu bar, under Selected, choose Add a database using wizard.

4. Select the Search the network option and click Next.

5. Double-click the folder beside Known Systems to list all the systems known to your client.

6. Click the plus [+] sign beside a system to get a list of the instances and databases on it. Select the database that you want to add and then click Next.

7. Enter a local database alias name in the Database alias field and optionally enter a comment that describes this database in the Comment field.

8. If you are planning to use ODBC, register this database as an ODBC data source. ODBC must be installed to perform this operation.

9. Click Finish. You are now able to use the database you added. Click Close to exit the CA.

Configuring a connection If you have the information for the database you want to connect to and the server upon which it resides, you can manually enter all of the configuration information. This method is analogous to entering commands through the command line processor; however, the parameters are presented graphically.

PrerequisitesBefore you configure a connection to a database using the CA:

� Ensure that you have a valid DB2 user ID.

� If adding a database to a system that has a DB2 server or DB2 Connect server product installed, ensure that you have a user ID with SYSADM or SYSCTRL authority for the instance.

ProcedureTo add a database to your system manually using the CA, perform the following steps:

1. Log on to the system with a valid DB2 user ID.

2. Start the CA. The CA can be started using one of the following methods:

– From the Start menu on Windows systems.


– From an icon on Linux systems. The icon is only available from the instance owner's environment; otherwise, it must be made available using the db2icons command.

– With the db2ca command on Windows and Linux systems.

3. On the CA menu bar, under Selected, choose Add a database using wizard.

4. Select the Manually configure a connection to a database option and click Next.

5. If you are using Lightweight Directory Access Protocol (LDAP), select the option that corresponds to the location where you would like your DB2 directories to be maintained. Click Next.

6. Select the option that corresponds to the protocol that you want to use from the Protocol list.

If DB2 Connect is installed on your machine, and you select TCP/IP or APPC, you have the option to select The database physically resides on a host or OS/400 system. If you select this option, you will have the option of selecting the type of connection that you want to make to the host or OS/400 database:

– To make a connection through a DB2 Connect gateway, select the Connect to the server via the gateway option.

– To make a direct connection, select the Connect directly to the server option.

Click Next.

7. Enter the required communication protocol parameters and click Next.

8. Enter the database alias name of the remote database that you want to add in the Database name field and a local database alias name in the Database alias field.

If you are adding a host or OS/400 database, enter the Location name for an OS/390® or z/OS database, the RDB name for an OS/400 database, or the DBNAME for a VSE or VM database in the Database name field. Optionally, add a comment that describes this database in the Comment field.

Click Next.

9. If you are planning to use ODBC, register this database as an ODBC data source. ODBC must be installed to perform this operation

10.Click Finish. You are now able to use this database. Select the Exit menu action to close the CA.


4.3.6 Configuring the client using profilesAnother automated method to configure a DB2 client to access remote instances is using access profiles. With profiles, you do not need to provide any detailed information. This method is typical when configuring a large number of clients.

There are two types of profiles:

� Server access profiles: Created from DB2 servers and contain information about all the instances and databases the DB2 server has cataloged.

� Client access profiles: Used for duplicating the cataloged databases or the client settings from one client to another, or both.

4.3.7 Automating the rollout of DB2 clientsIf you plan to roll out multiple copies of DB2 clients with identical configurations, you can create a batch file that will run your customized script.

For example, consider the following sample batch file, myscript.bat, depicted in Example 4-6. It is used to run the script file.

Example 4-6 Sample batch file: myscript.bat

@echo offclsdb2cmd catmvs.bat

The db2cmd command initializes the DB2 environment, and the catmvs.bat file calls the batch job of the same name.

Example 4-7 depicts a sample catalog script file, catmvs.bat, that could be used to add databases to a DB2 Connect Personal Edition workstation.

Example 4-7 catmvs.bat script file

db2 catalog tcpip node tcptst1 remote mvshost server 446 db2 catalog database mvsdb at node tcptst1 authentication dcs db2 catalog dcs database mvsdb as mvs_locator db2 catalog system odbc data source mvsdb db2 terminate exit

ProcedureYou can either send these files to your client workstations manually, or use SMS and have the script execute automatically after the installation and reboot have


completed. To create another SMS package with the catalog script, perform the following steps:

1. Start the Microsoft Systems Management Server (SMS) Administrator. The Open SMS window opens.

2. Select the Packages window type and click OK. The Packages window opens.

3. Select File → New from the menu bar. The Package Properties window opens.

4. Enter a name for your new package, for example, batchpack.

5. Enter a comment about the package, for example, Package for batch file.

6. Click the Workstations button. The Setup Package for Workstations window opens.

7. Enter the source directory. Ensure that the source directory is a location that both the server and the client have access to and that contains the batch file that is to be run from the client workstation.

8. Under the Workstation Command Lines section, click New. The Command Line Properties window opens.

9. Enter a command name.

10.Enter the command line.

11.Select the platforms that should be supported in the Supported Platforms section.

12.Click OK.

13.Click Close.

14.Click OK.

Distribute this package in the same way as an installation package.

4.4 Client-to-server communications protocolsYou will need to configure communications for both the server and client. DB2 supports several protocols such as TCP/IP, NetBIOS, and APPC. For this project, we used TCP/IP. As with IDS, DB2 also uses a service name and port number for TCP/IP communications, although it does not use a sqlhosts file.


4.4.1 Configuring TCP/IP on the client using the CLPThis task describes how to configure TCP/IP on the client using the command line processor (CLP).

PrerequisitesBefore you configure TCP/IP on the client:

� Ensure that TCP/IP is functional on the DB2 client. To establish a client to server connection, TCP/IP must also be functional on the DB2 server. To check TCP/IP functionality, type hostname to retrieve the host name of the local machine and then ping the host name.

� Ensure that you have identified the following parameter values:

– Host name (hostname) or IP address (ip_address) of the server machine

– Connection service name (svcename) or port number/protocol (port_number/tcp), or both

– Node name (node_name)

ProcedureTo configure TCP/IP communications between your DB2 client and DB2 server, perform the following steps:

1. Resolve the server's host address.

2. Update the services file on the DB2 client.

3. Configure the client-to-server connection.

4.4.2 Configuring a client-to-server connectionResolving a server host address is part of the main task of configuring TCP/IP on the client using the CLP.

The client will use the host address of the DB2 server to establish a connection. If your network has a name server, or if you plan to directly specify an IP address of the server, you can proceed to cataloging the TCP/IP node. If a domain name server does not exist on your network, you can directly specify a host name that maps to the IP address of the server in the local hosts file. If you are planning to support a UNIX client that is using Network Information Services (NIS), and you are not using a domain name server on your network, you must update the hosts file located on your NIS master server.

Table 4-2 on page 96 lists the locations of the local hosts and services files.


Table 4-2 Locations of the local hosts and services files

4.4.3 Setting the DB2COMM registry variableThe DB2COMM registry variable allows you to set communication protocols for the current DB2 instance. You must ensure that your DB2COMM DB2 registry variable is set to the appropriate protocol. You can use the db2set command to view and set DB2 registry variables.

ProcedureTo update the DB2COMM DB2 registry variable, perform the following steps:

1. From a command prompt, type the db2set -all command to display the registry variables that have already been set for your current instance. The output should be similar to that shown in Example 4-8.

Example 4-8 Display registry variables

C:\>db2set -all[e] DB2PATH=C:\Program Files\SQLLIB[i] DB2INSTPROF=C:\PROGRA~1\SQLLIB[i] DB2COMM=TCPIP[g] DB2_DOCCDPATH=C:\Program Files\SQLLIB\[g] DB2SYSTEM=SHAYER[g] DB2PATH=C:\Program Files\SQLLIB[g] DB2INSTDEF=DB2[g] DB2ADMINSERVER=DB2DAS00

2. Ensure that DB2COMM=<protocol>, where protocol represents the appropriate protocol, is set to the protocol or protocols you want.

3. If the DB2COMM registry variable is not set:

– For TCP/IP, enter the db2set DB2COMM=TCPIP command.

– For NetBIOS, enter the db2set DB2COMM=NETBIOS command.

– For both, enter the db2set DB2COMM=TCPIP,NETBIOS command.

4. Restart the database server by issuing the db2stop command and then the db2start command.

Operating system Directory

Windows 98/Windows ME windows

Windows NT/Windows 2000/Windows X:P/Windows Server 2003

%SystemRoot%\system32\drivers\etc where %SystemRoot% is a system defined environment variable

UNIX /etc


5. Run the db2set -all command again to verify that the command was successful and that the DB2COMM registry variable is properly set.

4.4.4 Cataloging the TCP/IP node on the clientCataloging the TCP/IP node adds an entry to the DB2 client's node directory to describe the remote node, the chosen node_name, and the hostname. This entry specifies the chosen alias (node_name), the hostname (or ip_address), and the svcename (or port_number) that the client will use to access the remote host.

ProcedureTo catalog a TCP/IP node, perform the following steps:

1. Log on to the system as a user with system administrative (SYSADM) or system controller (SYSCTRL) authority. You can also log on to the system without these authority levels if you have the catalog_noauth option set to ON.

2. If you are using a UNIX client, set up the instance environment and invoke the DB2 command line processor. Run the startup script as follows:

– For the Bash, Bourne, or Korn shell:

. INSTHOME/sqllib/db2profile

– For the C shell:

source INSTHOME/sqllib/db2cshrc

Where INSTHOME is the home directory of the instance.

3. Catalog the node by entering the following commands from a db2 prompt:

db2 => catalog tcpip node node_name remote hostname|ip_address\db2 => server service_name|port_number [remote_instance instance_name] [system system_name] [ostype os_type]db2 => terminate

Where system is the system name of the remote server, and ostype is the operating system of the remote server system.

For example, to catalog the remote host myserver on the node called db2node, using the service name server1, enter the following from a db2 prompt:

db2 => catalog tcpip node db2node remote myserver server server1db2 => terminate

Note: Specifying the remote_instance, system, and ostype values is optional, but recommended for users who want to use the DB2 tools. The service_name used on the client does not have to be the same as the one on the server. However, the port numbers that they map to must match.


To catalog a remote server with the IP address 9.21.15.235 on the node called db2node, using the port number 3700, enter the following from a db2 prompt:

db2 => catalog tcpip node db2node remote 9.21.15.235 server 3700db2 => terminate

The next step is to catalog the database on the client.

4.4.5 Cataloging databases using the CLPThis task describes how to catalog a database using the CLP.

Before a client application can access a remote database, the database must be cataloged on the client. When you create a database, the database is automatically cataloged on the server with a database alias that is the same as the database name unless a different database alias was specified. The information in the database directory, along with the information in the node directory (unless cataloging a local database where a node is not needed), is used on the DB2 client to establish a connection to the remote database.

PrerequisitesBefore you catalog the database:

� You need a valid DB2 user ID.

� If you are cataloging a database on a system that has a DB2 server or DB2 Connect product installed, the user ID must have system administrative (SYSADM) or system controller (SYSCTRL) authority on the instance.

� The following parameter values are applicable when cataloging a remote database:

– Database name

– Database alias

– Node name

– Authentication type (optional)

– Comment (optional)

� The following parameter values are applicable when cataloging a local database:

– Database name

– Database alias

Note: The terminate command is needed to refresh the directory cache.


– Authentication type (optional)

– Comment (optional)

Local databases can be uncataloged and re-cataloged at any time.

ProcedureTo catalog a database on the client, perform the following steps:

1. Log on to the system with a valid DB2 user ID. If you are cataloging a database on a system that has a DB2 server or DB2 Connect server installed, log on to this system as a user with system administrative (SYSADM) or system controller (SYSCTRL) authority on the instance.

2. Update the Your Value column in the Parameter values worksheet for cataloging a database.

3. If you are using DB2 on a UNIX platform, set up the instance environment. Run the startup script as follows:


INSTHOME/sqllib/db2profile



Where INSTHOME is the home directory of the instance.

4. Start the DB2 command line processor. You can do this by issuing the db2 command from a DB2 command window.

5. Catalog the database by entering the following commands in the command line processor:

catalog database database_name as database_alias at\node node_name authentication auth_value

For example, to catalog a remote database called sample so that it has the local database alias mysample, on the node db2node, enter the following commands:

catalog database sample as mysample at node\db2node authentication server terminate

The next step is to test the client-to-server connection.

4.4.6 Testing the client to server connection using the CLPAfter cataloging the node and the database, you should connect to the database to test the connection.


PrerequisitesEnsure that you meet the following prerequisites:

� The database node and database must be cataloged before you can test the connection.

� The values for userid and password must be valid for the system on which they are authenticated. By default, authentication takes place on the server.

� Start the database manager by entering the db2start command on the database server (if it was not already started).

ProcedureTo test the client to server connection, perform the following steps:

1. If you are using a UNIX client, run the startup script as follows:


. INSTHOME/sqllib/db2profile



Where INSTHOME represents the home directory of the instance.

2. Using the CLP, enter the following command on the client to connect to the remote database:

connect to database_alias user userid

For example, enter the following command:

connect to mysample user jsmith

You will then be prompted to enter your password.

If the connection is successful, you will receive a message showing the name of the database to which you have connected. A message similar to the example show in Example 4-9.

Example 4-9 Connecting to a database

Database Connection InformationDatabase server = DB2/NT 8.1.0SQL authorization ID = JSMITHLocal database alias = mysample


You are now able to work with the database. For example, to retrieve a list of all the table names listed in the system catalog table, enter the following SQL command:

select tabname from syscat.tables

An implicit connection occurs when you issue an SQL statement without being connected to any database. To define a default database, run the db2set db2dbdft = <dbname> command. After running this command, you can, for example, run the db2 get * from <table> command without first connecting to a database. This command will use the value defined in db2dbdft. To connect to a database other than the default, you must use the connect command to explicitly connect to the database of your choice.

When you are finished using the database connection, enter the connect reset command to end the database connection.

4.5 Configuring the instanceIn this section, we discuss the parameters used to configure a DB2 instance.

4.5.1 Page size or sizesA DB2 instance can use multiple page sizes for different database objects and their associated buffer pools. In many cases, there are inherent performance advantages to having multiple page sizes, but the primary reason for having multiple page sizes is that a data row cannot span pages with DB2. For example, if the table space created has a 4 KB page size, any table or index that is created in that table space must have a row size of less than 4 KB (minus page or row level overhead). If a table’s row size needs to grow beyond the maximum row size of the page size, the table should be dropped, a new table space and buffer pool created with a larger page size, and the table then reloaded.

Space requirements for user table dataBy default, table data is stored on 4 KB pages. Each page (regardless of page size) contains 68 bytes of overhead for the database manager. For a 4 KB page, this leaves 4028 bytes to hold user data (or rows), although no row on a 4 KB page can exceed 4005 bytes in length. Unlike IDS, a row will not span multiple pages. You can have a maximum of 500 columns when using a 4 KB page size.

Table data pages do not contain the data for columns defined with LONG VARCHAR, LONG VARGRAPHIC, BLOB, CLOB, or DBCLOB data types. Each row, for tables with such columns contains a descriptor locating the actual data for these columns.


Rows are usually inserted into a table in first-fit order. Space is searched (using a free space map) for the first available space that is large enough to hold the new row. When a row is updated, it is updated in place unless there is insufficient space left on the page to contain it. If this is the case, a record is created in the original row location that points to the new location.

The number of 4 KB pages for each user table in the database can be estimated by calculating:

Round down (4028/(average row size + 10)) = records_per_page

Next, insert the result into:

(number_of_records/records_per_page) * 1.1 = number_of_pages

Where the average row size is the sum of the average column sizes, and the factor of “1.1” is for overhead.

You also have the option to create buffer pools or table spaces that have an 8 KB, 16 KB, or 32 KB page size. All tables created within a table space of a particular size have a matching page size. Maximums based on page size are shown in Table 4-3.

Table 4-3 Maximum row length by page size

Page size rationaleHaving a larger page size facilitates a reduction in the number of levels in any index. If you are working with online transaction processing (OLTP) applications, which perform random row reads and writes, a smaller page size is better, because it wastes less buffer space with undesired rows. If you are working with decision support system (DSS) applications, which access large numbers of consecutive rows at a time, a larger page size is better, because it reduces the number of I/O requests required to read a specific number of rows. An exception

Note: This formula only provides an estimate. The accuracy of the estimate is reduced if the record length varies because of fragmentation and overflow records.

Page size Maximum # of columns

Maximum row size

4 KB 500 4,005

8 KB 1,012 8,101

16 KB 1,012 16,293

32 KB 1,012 32,677


occurs when the row size is smaller than the page size divided by 255. In such a case, there is wasted space on each page.

4.5.2 Table spacesA table space is a storage structure containing tables, indexes, large objects, and long data. They enable you to assign the location of database and table data directly into containers. This enables flexible configuration, which can also result in improving performance. A container can be a directory name, a device name, or a file name.

When a database is created, three default table spaces are also created, as depicted in Figure 4-8 on page 104. The DBA has options about the creation of these table spaces. If no options are used for the table spaces, they are created as:

� Catalog table space: One catalog table space that contains all of the system catalog tables for the database. This table space is called SYSCATSPACE, and it cannot be dropped.

� User table space: One or more user table spaces that contain all user-defined tables. By default, one table space, USERSPACE1, is created. You can specify a table space name when you create a table.

� Temporary table space or spaces: One or more temporary table spaces that contain temporary tables. Temporary table spaces can be system temporary table spaces or user temporary table spaces. A database must have at least one system temporary table space; by default, one system temporary table space called TEMPSPACE1 is created at database creation time.

Important: DB2 and IDS both only allow a maximum of only 255 rows per data page.


You should define a single SMS temporary table space with a page size equal to the page size used in the majority of your user table spaces. This should be adequate for typical environments and workloads.

Figure 4-8 Default table spaces for a database

Extent sizeThe extent size for a table space represents the number of pages of table data that will be written to a container before data will be written to the next container. When selecting an extent size, you should consider:

� The size and type of tables in the table space:

Space in DMS table spaces is allocated to a table one extent at a time. As the table is populated and an extent becomes full, a new extent is allocated.

Important: If a database uses more than one temporary table space, and a new temporary object is needed, the optimizer will choose an appropriate page size for this object. That object will then be allocated to the temporary table space with the corresponding page size. If there is more than one temporary table space with that page size, the table space will be chosen in a round-robin fashion. In most circumstances, we do not recommend that you have more than one temporary table space of any one page size.

If queries are running against tables in table spaces that are defined with a page size larger than the 4 KB default (for example, an ORDER BY on 1012 columns), some of them might fail if temp space is required and there are no temporary table spaces defined with the larger page size. You might need to create a temporary table space with a larger page size (8 KB, 16 KB, or 32 KB). Any data manipulation language (DML) statement could fail unless there exists a temporary table space with the same page size as the largest page size in the user table space.

DB2 instance

table space 0 SYSCATSPACE

table space 1 TEMPSPACE1

table space 2 USERSPACE1

database1


Space in SMS table spaces is allocated also one extent at a time, but only if you have enabled multipage file allocation.

A table is made up of the following separate table objects:

– A data object. This is where the regular column data is stored.

– An index object. This is where all indexes defined on the table are stored.

– A long field object. This is where long field data, if your table has one or more LONG columns, is stored

– Two LOB objects. If your table has one or more LOB columns, they are stored in these two table objects:

• One table object for the LOB data

• A second table object for metadata describing the LOB data

– A block map object for multidimensional tables.

Each table object is stored separately, and each object allocates new extents as needed. Each table object is also paired with a metadata object called an extent map that describes all of the extents in the table space that belong to the table object. Space for extent maps is also allocated one extent at a time.

The initial allocation of space for a table, therefore, is two extents for each table object. If you have many small tables in a table space, you might have a relatively large amount of space allocated to store a relatively small amount of data. In such a case, you should specify a small extent size, or use an SMS table space, which allocates pages one at a time.

If, however, you have a very large table that has a high growth rate, and you are using a DMS table space with a small extent size, you could have unnecessary overhead related to the frequent allocation of additional extents.

� The type of access to the tables: If access to the tables includes many queries or transactions that process large quantities of data, prefetching data from the tables might provide significant performance benefits.

� The minimum number of extents required: If there is not enough space in the containers for five extents of the table space, the table space will not be created.

SMS table spacesSystem Managed Space (SMS) table spaces store data in operating system files. The data in the table spaces is striped by extent across all the containers in the system. An extent is a group of consecutive pages defined to the database. Each table in a table space is given its own file name that is used by all containers. The file extension denotes the type of the data stored in the file. To spread the space


use evenly across all containers in the table space, the starting extents for tables are placed in a round-robin fashion across all containers. Such distribution of extents is particularly important if the database contains many small tables.

In an SMS table space, space for tables is allocated on demand. This expansion is done a single page at a time by default. However, in certain work loads such as bulk inserts, you can improve performance with the db2empfa tool to tell DB2 to expand the table space in groups of pages or extents. The db2empfa tool is located in the bin subdirectory of the sqllib directory. When you run the db2empfa tool, the multipage_alloc database configuration parameter is set to Yes.

DMS table spacesWith Database Managed Space (DMS) table spaces, the database manager controls the storage space. A list of devices or files is selected to belong to a table space when the DMS table space is defined. The space on those devices or files is managed by the DB2 database manager. As with SMS table spaces and containers, DMS table spaces and the database manager use striping by extent to ensure an even distribution of data across all containers.

DMS table spaces differ from SMS table spaces in that for DMS table spaces, space is allocated when the table space is created and not allocated when needed.

Also, the placement of data can differ on the two types of table spaces. For example, consider the need for efficient table scans: It is important that the pages in an extent are physically contiguous. With SMS, the file system of the operating system decides where each logical file page is physically placed. The pages might, or might not, be allocated contiguously, depending on the level of other activity on the file system and the algorithm used to determine placement. With DMS, however, the database manager can ensure the pages are physically contiguous, because it interfaces with the disk directly.

As with SMS table spaces, DMS file containers can take advantage of file system prefetching and caching. However, DMS table spaces cannot.

Note: SMS table spaces can take advantage of file system prefetching and caching.

Important: When all space in a single container in an SMS table space is allocated to tables, the table space is considered full, even if space remains in other containers. You can add containers to an SMS table space only on a partition that does not yet have any containers.


Recommendations:

� Unlike SMS table spaces, the containers that make up a DMS table space do not need to be close to being equal in their capacity. However, we recommend that the containers are equal, or close to equal, in their capacity. Also, if any container is full, any available free space from other containers can be used in a DMS table space.

� When working with DMS table spaces, you should consider associating each container with a different disk. This allows for a larger table space capacity and the ability to take advantage of parallel I/O operations.

Although the default table spaces will be created when a database is created, you can specify the types of containers to be used for these table spaces. Table 4-4 shows the recommendations for the type of table space to create for each default table space:

Table 4-4 Recommendations for default table spaces

Note: There is an exception to the general statement regarding contiguous placement of pages in storage. There are two container options when working with DMS table spaces: raw devices and files. When working with file containers, the database manager allocates the entire container at table space creation time. A result of this initial allocation of the entire table space is that the physical allocation is typically, but not guaranteed to be, contiguous even though the file system is doing the allocation. When working with raw device containers, the database manager takes control of the entire device and always ensures the pages in an extent are contiguous.

Table space Usage Preferred type

SYSCATSPACE Used to store the system catalog tables for the database. These tables contain data about the database structures: where they are and how they are used (very similar to the IDS system catalog for the database).

SMS.

TEMPSPACE1 Used by the instance when system temporary space is needed in the database (internal sorts and index builds).

SMS.

USERSPACE1 Used to store user data tables and indexes.

Must be DMS if you are partitioning data separate from the indexes.


Comparison of SMS and DMS table spacesThere are a number of trade-offs to consider when determining which type of table space you should use to store your data.

� Advantages of an SMS table space:

– Space is not allocated by the system until it is required.

– Creating a table space requires less initial work, because you do not have to predefine the containers.

� Advantages of a DMS table space:

� The size of a table space can be increased by adding or extending containers, using the ALTER TABLESPACE statement. Existing data can be automatically rebalanced across the new set of containers to retain optimal I/O efficiency.

� A table can be split across multiple table spaces, based on the type of data being stored:

– Long field and LOB data

– Indexes

– Regular table data

Performance considerationsYou might want to separate your table data for performance reasons, or to increase the amount of data stored for a table. For example, you could have a table with 64 GB of regular table data, 64 GB of index data, and 2 TB of long data. If you are using 8 KB pages, the table data and the index data can be as much as 128 GB. If you are using 16 KB pages, it can be as much as 256 GB. If you are using 32 KB pages, the table data and the index data can be as much as 512 GB. Also be aware of the following points as you design:

� The location of the data on the disk can be controlled if this is allowed by the operating system.

� If all table data is in a single table space, a table space can be dropped and redefined with less overhead than dropping and redefining a table.

� In general, a well-tuned set of DMS table spaces will outperform SMS table spaces.

In most cases, small personal databases are easiest to manage with SMS table spaces. However, for large, growing databases, you will probably only want to use SMS table spaces for the temporary table spaces and catalog table space, and separate DMS table spaces, with multiple containers, for each table. In

Note: On Solaris, DMS table spaces with raw devices are strongly recommended for performance-critical workloads.


addition, you will probably want to store long field data and indexes on their own table spaces.

If you choose to use DMS table spaces with device containers, you must be willing to tune and administer your environment.

How containers are added and extended in DMS table spacesWhen a table space is created, its table space map is created, and all of the initial containers are lined up such that they all start in stripe 0. This means that data will be striped evenly across all of the table space containers until the individual containers fill up. (See “Example: Creating one table space with three containers” on page 112.)

The ALTER TABLESPACE statement lets you add a container to an existing table space or extend a container to increase its storage capacity.

Adding a container that is smaller than existing containers results in an uneven distribution of data. This can cause parallel I/O operations, such as prefetching data, to perform less efficiently than they otherwise could on containers of equal size.

When new containers are added to a table space or existing containers are extended, a rebalance of the table space data might occur.

A single table space can span several containers. It is possible for multiple containers (from one or more table spaces) to be created on the same physical disk (or drive). For improved performance, each container should use a different disk. Figure 4-9 on page 110 illustrates the relationship between tables and table spaces within a database and the containers associated with that database.


Figure 4-9 Table spaces and tables within a database

The EMPLOYEE and DEPARTMENT tables are in the HUMANRES table space, which spans containers 0, 1, 2, and 3. The PROJECT table is in the SCHED table space in container 4. This example shows each container existing on a separate disk.

Figure 4-10 on page 111 shows the HUMANRES table space with an extent size of two 4 KB pages, and four containers, each with a small number of allocated extents. The DEPARTMENT and EMPLOYEE tables both have seven pages and span all four containers.

Important: The database manager attempts to balance the data load across containers. As a result, all containers are used to store data. The number of pages that the database manager writes to a container before using a different container is called the extent size. Also, the database manager does not always start storing table data in the first container.


Figure 4-10 Containers and extents

Rebalancing containers within table spacesThe process of rebalancing when adding or extending containers involves moving table space extents from one location to another, and it is done in an attempt to keep data striped within the table space.

Access to the table space is not restricted during rebalancing; objects can be dropped, created, populated, and queried as usual. However, the rebalancing operation can have a significant impact on performance. If you need to add more than one container, and you plan on rebalancing the containers, you should add them at the same time within a single ALTER TABLESPACE statement to prevent the database manager from having to rebalance the data more than once.

The table space high-water mark plays a key part in the rebalancing process. The high-water mark is the page number of the highest allocated page in the table space. For example, a table space has 1000 pages and an extent size of 10, resulting in 100 extents. If the forty-second extent is the highest allocated extent in the table space, this means that the high-water mark is 42 * 10 = 420 pages. This is not the same as used pages, because some of the extents below the high-water mark might have been freed up such that they are available for reuse.

Before the rebalance starts, a new table space map is built based on the container changes made. The rebalancer will move extents from their location determined by the current map into the location determined by the new map. The rebalancer starts at extent 0, moving one extent at a time until the extent holding the high-water mark has been moved. As each extent is moved, the current map is altered one piece at a time to look like the new map. At the point that the rebalance is complete, the current map and new map should look identical up to


the stripe holding the high-water mark. The current map is then made to look completely like the new map, and the rebalancing process is complete. If the location of an extent in the current map is the same as its location in the new map, the extent is not moved, and no I/O takes place.

When adding a new container, the placement of that container within the new map depends on its size and the size of the other containers in its stripe set. If the container is large enough such that it can start at the first stripe in the stripe set and end at (or beyond) the last stripe in the stripe set, it will be placed that way (see “Example: Adding a new container (one table space with four containers)” on page 113). If the container is not large enough to do this, it will be positioned in the map such that it ends in the last stripe of the stripe set (see “Example: Adding a new container (one table space with four containers)” on page 113). This is done to minimize the amount of data that needs to be rebalanced.

Example: Creating one table space with three containersIf you create a table space with three containers and an extent size of 10, and the containers are 60, 40, and 80 pages, respectively (6, 4, and 8 extents), the table space will be created with a map that can be diagrammed as shown in Figure 4-11 on page 113.

Note: In the following examples, the container sizes do not take the size of the container tag into account. The container sizes are very small and are used for the purpose of illustration; they are not recommended container sizes. The examples show containers of different sizes within a table space, but you are advised to use containers of the same size.


Figure 4-11 One table space with three containers

Example: Adding a new container (one table space with four containers)

If an 80-page container is added to the table space in the previous example, the container is large enough to start in the first stripe (stripe 0) and end in the last stripe (stripe 7). It is positioned such that it starts in the first stripe. The resulting table space can be diagrammed as shown in Figure 4-12 on page 114.


Figure 4-12 One table space with four containers

If the high-water mark is within extent 14 (in Figure 4-12), the rebalancer will start at extent 0 and will move all of the extents up to and including 14. The location of extent 0 within both of the maps is the same, so this extent does not need to move. This is the same for extents 1 and 2. Extent 3 does need to move, so the extent is read from the old location (second extent within container 0) and written to the new location (first extent within container 3). Every extent after this up to and including extent 14 will be moved. After extent 14 has been moved, the current map will be made to look like the new map and the rebalancer will terminate.

If the map is altered such that all of the newly added space comes after the high-water mark, a rebalance is not necessary, and all of the space is available immediately for use. If the map is altered such that some of the space comes after the high-water mark, the space in the stripes above the high-water mark will be available for use. The rest will not be available until the rebalance is complete.

Example: Extending a containerIf you decide to extend a container, as depicted in this example, the function of the rebalancer is similar. If a container is extended such that it extends beyond the last stripe in its stripe set, the stripe set will expand to fit this, and the following stripe sets will be shifted out accordingly. The result is that the container will not extend into any stripe sets following it.

Consider the table space from “Example: Creating one table space with three containers” on page 112. If you extend container 1 from 40 pages to 80 pages, the new table space appear as depicted in Figure 4-13 on page 115.


Figure 4-13 Extending container 1 from 40 to 80 pages

Example: Adding a containerThe next step in our sequence of examples is to add another container to an existing table space.

Consider the table space from “Example: Creating one table space with three containers” on page 112. If a 50-page (5-extent) container is added to it, the container will be added to the new map in the following way. The container is not large enough to start in the first stripe (stripe 0) and end at or beyond the last stripe (stripe 7), so it is positioned such that it ends in the last stripe. The result is depicted in Figure 4-14 on page 116.


Figure 4-14 A new container is added (container 3)

To extend a container, use the EXTEND or RESIZE option on the ALTER TABLESPACE statement. To add containers and rebalance the data, use the ADD option on the ALTER TABLESPACE statement. If you are adding a container to a table space that already has more than one stripe set, you can specify which stripe set you want to add to. To do this, you use the ADD TO STRIPE SET option on the ALTER TABLESPACE statement. If you do not specify a stripe set, the default behavior will be to add the container to the current stripe set. The current stripe set is the most recently created stripe set, not the one that last had space added to it.

Any change to a stripe set might cause a rebalance to occur to that stripe set and any others following it.

You can monitor the progress of a rebalance by using table space snapshots. A table space snapshot can provide information about a rebalance such as the start time of the rebalance, how many extents have been moved, and how many extents need to move.

Without rebalancing (using stripe sets)If you add or extend a container, and the space added is above the table space high-water mark, a rebalance will not occur.

Adding a container will almost always add space below the high-water mark. In other words, a rebalance is often necessary when you add a container. There is an option to force new containers to be added above the high-water mark, which


enables you to choose not to rebalance the contents of the table space. An advantage of this method is that the new container will be available for immediate use. The option not to rebalance applies only when you add containers, not when you extend existing containers. When you extend containers, you can only avoid rebalancing if the space you add is above the high-water mark. For example, if you have a number of containers that are the same size, and you extend each of them by the same amount, the relative positions of the extents will not change, and a rebalance will not occur.

Adding containers without rebalancing is done by adding a new stripe set. A stripe set is a set of containers in a table space that has data striped across it separately from the other containers that belong to that table space. You use a new stripe set when you want to add containers to a table space without rebalancing the data. The existing containers in the existing stripe sets remain untouched, and the containers you are adding become part of a new stripe set.

To add containers without rebalancing, use the BEGIN NEW STRIPE SET option on the ALTER TABLESPACE statement.

Example: Adding containers without rebalancingIf you have a table space with three containers and an extent size of 10, and the containers are 30, 40, and 40 pages (3, 4, and 4 extents, respectively), the table space can be diagrammed as shown in Figure 4-15.

Figure 4-15 Three containers, two of the same size

Example 4-11 on page 127 describes how to add two containers of the same size.

Example: Adding two containers of different sizesWhen you add two new containers that are 30 pages and 40 pages (3 and 4 extents, respectively) with the BEGIN NEW STRIPE SET option, the existing


ranges will not be affected, and instead, a new set of ranges will be created. This new set of ranges is a stripe set and the most recently created one is called the current stripe set. After the two new containers have been added, the table space will look similar to Figure 4-16.

Figure 4-16 Two new containers added

If you add new containers to a table space, and you do not use the TO STRIPE SET option with the ADD clause, the containers will be added to the current stripe set (the highest stripe set). You can use the ADD TO STRIPE SET clause to add containers to any stripe set in the table space. You must specify a valid stripe set.

4.5.3 Buffer poolsIn the section, we discuss buffer pools. It describes buffer pool management, their relation to table spaces, and how to create them.

Buffer pool managementA buffer pool is memory used to cache table and index data pages as they are read from disk or modified. The buffer pool improves database system performance by allowing data to be accessed from memory instead of from disk. Because memory access is much faster than disk access, the less often the

Important: DB2 tracks the stripe sets using the table space map, and adding new containers without rebalancing will generally cause the map to grow faster than when containers are rebalanced. When the table space map becomes too large, you will receive error SQL0259N when you try to add more containers.


database manager needs to read from or write to a disk, the better the performance. Because most data manipulation takes place in buffer pools, configuring buffer pools is the single most important tuning area. Only large objects and long field data are not manipulated in a buffer pool.

When an application accesses a row of a table for the first time, the database manager places the page containing that row in the buffer pool. The next time any application requests data, the database manager looks for it in the buffer pool. If the requested data is in the buffer pool, it can be retrieved without disk access, resulting in faster performance.

Memory is allocated for the buffer pool when a database is activated or when the first application connects to the database. Buffer pools can also be created, dropped, and resized while the database is manager is running. If you use the IMMEDIATE keyword when you use ALTER BUFFERPOOL to increase the size of the buffer pool, memory is allocated as soon as you enter the command if the memory is available. If the memory is not available, the change occurs when all applications are disconnected and the database is reactivated. If you decrease the size of the buffer pool, memory is deallocated at commit time. When all applications are disconnected, the buffer pool memory is deallocated.

To ensure that an appropriate buffer pool is available in all circumstances, DB2 creates small buffer pools, one with each page size: 4 KB, 8 KB, 16 KB, and 32 KB. The size of each buffer pool is 16 pages. These buffer pools are hidden from the user. They are not present in the system catalogs or in the buffer pool system files. You cannot use or alter them directly, but DB2 uses these buffer pools in the following circumstances:

� When a buffer pool of the required page size is inactive because not enough memory was available to create it after a CREATE BUFFERPOOL statement was executed with the IMMEDIATE keyword.

A message is written to the administration notification log. If necessary, table spaces are remapped to a hidden buffer pool. However, performance could be drastically reduced.

� When the ordinary buffer pools cannot be brought up during a database connect.

This problem is likely to have a serious cause, such as an out-of-memory condition. Although DB2 will be fully functional because of the hidden buffer

Note: To reduce the necessity of increasing the size of the dbheap database configuration parameter when buffer pool sizes increase, nearly all buffer pool memory, which includes page descriptors, buffer pool descriptors, and the hash tables, comes out of the database shared memory set, and so the buffer pool is sized automatically.


pools, performance will degrade drastically. You should address this problem immediately. You receive a warning when this occurs, and a message is written to the administration notification log.

Pages remain in the buffer pool until the database is shut down, or until the space occupied by a page is required for another page. The following criteria determine which page is removed to bring in another page:

� How recently the page was referenced.

� The probability that the page will be referenced again by the last agent that looked at it.

� The type of data on the page.

� Whether the page was changed in memory but not written out to disk. (Changed pages are always written to disk before being overwritten.)

In order for pages to be accessed from memory again, changed pages are not removed from the buffer pool after they are written out to disk unless the space is needed.

Relationship between table spaces and buffer poolsEach table space is associated with a specific buffer pool. The default buffer pool is IBMDEFAULTBP. If another buffer pool is to be associated with a table space, the buffer pool must exist (it is defined with the CREATE BUFFERPOOL statement), it must have the same page size, and the association is defined when the table space is created (using the CREATE TABLESPACE statement). The association between the table space and the buffer pool can be changed using the ALTER TABLESPACE statement.

Having more than one buffer pool enables you to configure the memory used by the database to improve overall performance. For example, if you have a table space with one or more large (larger than available memory) tables that are accessed randomly by users, the size of the buffer pool can be limited, because caching the data pages might not be beneficial. The table space for an online transaction application might be associated with a larger buffer pool so that the data pages used by the application can be cached longer, resulting in faster response times. Care must be taken in configuring new buffer pools.

Important: Because pages can be read into a buffer pool only if the table space page size is the same as the buffer pool page size, the page size of your table spaces should determine the page size that you specify for buffer pools.

You cannot alter the page size of the buffer pool after you create it. You must create a new buffer pool with a different page size.


Creating a buffer poolYou can create new buffer pools for use by the database manager. Buffer pools improve database system performance immediately.

The page sizes specified for your table spaces should determine the page sizes that you choose for your buffer pools. The choice of page size used for a buffer pool is important, because you cannot alter the page size after you create a buffer pool.

PrerequisitesThe authorization ID of the statement must have SYSCTRL or SYSADM authority. Before you create a new buffer pool, resolve the following questions:

� What buffer pool name will you use?

� Will the buffer pool be created immediately, or created following the next time that the database is deactivated and reactivated?

� Do you want to associate the buffer pool with a subset of all database partitions that make up the database?

� What values do you want to associate with the parameters controlling the size of the buffer pool, including the page size and the total size of the buffer pool based on the number of pages?

� Do you want to use extended storage, block-based support, or neither?

ProcedureTo create a new buffer pool, perform the following steps:

1. Select BPNAME from SYSCAT.BUFFERPOOLS to get the list of buffer pool names that already exist in the database.

2. Choose a buffer pool name that is not currently found in the result list. The name must not begin with the characters “SYS” or ”IBM”.

3. Determine the characteristics of the buffer pool you are going to create.

4. Ensure that you have the correct authorization ID to run the CREATE BUFFERPOOL statement.

5. Run the CREATE BUFFERPOOL statement.

Important: The storage required for all the buffer pools must be available to the database manager when the database is started. If DB2 is unable to obtain the required storage, the database manager will start up with default buffer pools (one each of 4 KB, 8 KB, 16 KB, and 32 KB page sizes) and issue a warning.


4.5.4 Logical logsThe logical logs in DB2 have characteristics similar to the logical logs in IDS. Primarily, they are responsible for capturing logical changes to data or the instance and enabling the ability to do “logical recovery” if configured to do so.

IDS added “dynamic logging” in later releases of Versions 7.3 and in 9.3. This feature allows the instance to add logical logs dynamically if possible. In earlier releases of IDS, if a logical log was added, a level-0 archive would have to be performed.

DB2 has had the “dynamic logging” feature for many releases, but it is implemented differently than in IDS. The initial allocation of the logical logs for DB2 is also different than IDS.

DB2 and logical logsIn DB2 Version 8.2, there are 27 database configuration parameters related to the logical logs. Figure 4-17 shows these configuration parameters.

Figure 4-17 Database log configuration parameters

Important: DB2 does not have a physical log file. The physical log file is an important element of “physical recovery” for an IDS instance. For more information about a “physical recovery” in DB2, see 5.4, “Backup and recovery” on page 164.


While IDS has many logical logs that are shared by all instance objects, DB2 has one or two sets of logical log files per database:

� Primary logs: The initial allocation of logical logs for a database. The configuration parameter LOGPRIMARY represents the maximum number of primary logical logs that will be allocated for the database.

� Secondary logs: Subsequent dynamic allocation of logical logs if the primary logs become full. The configuration parameter LOGSECOND represents the maximum number of secondary log files that will be allocated dynamically if needed.

Example 4-10 Primary and secondary log files

Number of primary log files (LOGPRIMARY) = 5Number of secondary log files (LOGSECOND) = 2

Log files default locationWhen the instance is created, the ”primary” set of logical logs are created in a default location. This location can be changed if desired. Figure 4-18 shows the path to the default log file or files location.

Figure 4-18 Log file path description

Note: Although in this example the user name and the instance name is “db2inst2”, the user name and the instance name do not have to be the same.

Path to log files = /home/db2inst2/db2inst2/NODE0000/SQL00011/SQLOGDIR/

home directory for

user db2inst2

instance name

default instance directory

database directory

default logfiles directory


Overflow log path (overflowlogpath) This parameter can be used for several functions, depending on your logging requirements. You can specify a location for DB2 to find log files that are needed for a rollforward operation. It is similar to the OVERFLOW LOG PATH option of the ROLLFORWARD command; however, instead of specifying the OVERFLOW LOG PATH option for every ROLLFORWARD command issued, you can set this configuration parameter once. If both are used, the OVERFLOW LOG PATH option will overwrite the overflowlogpath configuration parameter for that rollforward operation.

If logsecond is set to -1, you can specify a directory for DB2 to store active log files retrieved from the archive. (Active log files must be retrieved for rollback operations if they are no longer in the active log path.)

If the overflowlogpath parameter is not specified, DB2 will retrieve the log files into the active log path. By specifying this parameter, you can provide additional resource for DB2 to store the retrieved log files. The benefits include spreading the I/O cost to different disks and allowing more log files to be stored in the active log path.

If you have configured a raw device for the active log path, the overflowlogpath parameter must be configured if you want to set logsecond to -1.

To set the overflowlogpath parameter, specify a string of up to 242 bytes. The string must point to a path name, and it must be a fully qualified path name, not a relative path name. The path name must be a directory, not a raw device.

Primary logs (logprimary) This parameter specifies the number of primary logs of size logfilsz that will be created.

A primary log, whether empty or full, requires the same amount of disk space. Therefore, if you configure more logs than you need, you use disk space unnecessarily. If you configure too few logs, you can encounter a log-full condition. As you select the number of logs to configure, you must consider the size you make each log and whether your application can handle a log-full condition. The total log file size limit on active log space is 256 GB.

If you are enabling an existing database for rollforward recovery, change the number of primary logs to the sum of the number of primary and secondary logs,

Note: In a partitioned database environment, the node number is automatically appended to the path. This is done to maintain the uniqueness of the path in multiple logical node configurations.


plus 1. Additional information is logged for LONG VARCHAR and LOB fields in a database enabled for rollforward recovery.

Secondary logs (logsecond) This parameter specifies the number of secondary log files that are created and used for recovery, if needed.

If the primary log files become full, secondary log files (of size logfilsiz) are allocated, one at a time as needed, up to the maximum number specified by this parameter. If this parameter is set to -1, the database is configured with infinite active log space. There is no limit on the size or number of in-flight transactions running on the database.

Space requirements for log filesYou will require 32 KB of space for log control files. You will also need at least enough space for your active log configuration, which you can calculate as follows:

(logprimary + logsecond) * (logfilsiz + 2 ) * 4096

Where:

– logprimary is the number of primary log files, defined in the database configuration file.

– logsecond is the number of secondary log files, defined in the database configuration file; in this calculation, logsecond cannot be set to -1. (When logsecond is set to -1, you are requesting an infinite active log space.)

– logfilsiz is the number of pages in each log file, defined in the database configuration file.

– 2 is the number of header pages required for each log file.

– 4096 is the number of bytes in one page.

If the database is enabled for circular logging, the result of this formula will provide a sufficient amount of disk space.

Note: The userexit database configuration parameter must be enabled in order to set logsecond parameter to -1.

If this parameter is set to -1, crash recovery time might be increased, because DB2 might need to retrieve archived log files.


If the database is enabled for rollforward recovery, special log space requirements should be taken into consideration:

� With the logretain configuration parameter enabled, the log files will be archived in the log path directory. The online disk space will eventually fill up unless you move the log files to a different location.

� With the userexit configuration parameter enabled, a user exit program moves the archived log files to a different location. Extra log space is still required to allow for:

– Online archived logs that are waiting to be moved by the user exit program

– New log files being formatted for future use

If the database is enabled for infinite logging (that is, you set logsecond to -1), the userexit configuration parameter must be enabled, so you will have the same disk space considerations. DB2 will keep at least the number of active log files specified by logprimary in the log path, so you should not use the value of -1 for logsecond in the formula shown in the calculation. Ensure that you provide extra disk space to allow the delay caused by archiving log files. If you are mirroring the log path, you will need to double the estimated log file space requirements.

Log mirroringIf you are concerned that your active logs might be damaged (as a result of a disk crash), you should consider using a new DB2 configuration parameter, MIRRORLOGPATH. This specifies a secondary path for the database to manage copies of the active log.

The MIRRORLOGPATH configuration parameter allows the database to write an identical second copy of log files to a different path. We recommend that you place the secondary log path on a physically separate disk (preferably one that is also on a different disk controller). In this way, the logs, the log disks, and the controller cannot be single points of failure.

When MIRRORLOGPATH is first enabled, it will not actually be used until the next database startup. This is similar to the NEWLOGPATH configuration parameter.

If there is an error writing to either the active log path or the mirror log path, the database will mark the failing path as “bad,” write a message to the administration notification log, and write subsequent log records to the remaining “good” log path only. DB2 will not attempt to use the “bad” path again until the current log file is completed. When DB2 needs to open the next log file, it will verify that this path is valid, and if so, will begin to use it. If not, DB2 will not attempt to use the path again until the next log file is accessed for the first time. There is no attempt to synchronize the log paths, but DB2 keeps information


about access errors that occur so that the correct paths are used when log files are archived. If a failure occurs while writing to the remaining “good” path, the database shuts down.

4.5.5 DatabasesWhen creating a database with DB2, there are many more configuration options available to the DBA than with IDS.

Example 4-11 shows the create database command with only two options: one for the PATH of the directory structure created, and one setting the default extent size (in pages).

Example 4-11 Database creation with PATH and EXTENT SIZE option

db2 create database test_db on /home/marks/test_db dft_extent_sz 100DB20000I The CREATE DATABASE command completed successfully.

There are three table spaces created by default as a result of the create database command, as shown in Figure 4-8 on page 104. However, many options can be included when creating the database to change characteristics of the default table spaces. For more details, see 4.5.2, “Table spaces” on page 103.

TablesWhen creating tables, you can create them without specifying a table space for storage. In this case, they will be created in the default table space for that database. Or, you can specify a table space for this table. You can also specify a buffer pool to be associated with the table space. Therefore, it is possible to have a buffer pool and table space associated with just one table.

To create a table, perform the following steps. The commands are depicted in Example 4-12 on page 128.

1. Create a buffer pool with a 4 KB page size.

2. Create a table space, attaching the buffer pool from step 1 to that table space.

3. Create the table in that table space, and create an index in a separate table space.


Example 4-12 Create table

CONNECT TO IFMX2DB2;CREATE BUFFERPOOL XPAD_BUFFERPOOL IMMEDIATE SIZE 1000 PAGESIZE 8 K ;CONNECT RESET;

CONNECT TO IFMX2DB2;CREATE REGULAR TABLESPACE UW1_TABLESPACE PAGESIZE 8 K MANAGED BY SYSTEM USING ('/home/db2inst2/UW1_container' ) EXTENTSIZE 128 PREFETCHSIZE 128 BUFFERPOOL UW1_BUFFERPOOL DROPPED TABLE RECOVERY ON;COMMENT ON TABLESPACE UW1_TABLESPACE IS 'Dummy tablespace';CONNECT RESET;

CONNECT TO IFMX2DB2;CREATE TABLE DB2INST2.AWESOME ( RUDDER BIGINT NOT NULL , CONSTRAINT CC1093451089622 PRIMARY KEY ( RUDDER) , CONSTRAINT CC1093451107418 CHECK (RUDDER > 0) ENFORCED ENABLE QUERY OPTIMIZATION ) IN UW1_TABLESPACE INDEX IN IDXTBS_1 ;CONNECT RESET;

To see the table spaces for this instance, you can use the DB2 command line processor, as shown in Figure 4-19 on page 129.

Important: If you want to separate the index pages and the data pages, it must be done during the CREATE TABLE statement. Unlike IDS, it cannot be done in the CREATE INDEX statement.

Recall also that the table space type must be DMS to separate indexes from data.


Figure 4-19 List table spaces from the command line

Now, use the new db2pd command. This command is similar to the IDS onstat command. The output is shown in Figure 4-20.

Figure 4-20 The db2pd table spaces listing

You can also see the output using the Control Center, as shown in Figure 4-21.

$ db2 connect to ifmx2db2$ db2 list tablespaces


Figure 4-21 Table spaces in the Control Center

Table typesDB2 supports table types. Each type of table has characteristics that make it useful when working in a particular business environment. For each table that you use, consider which table types would best suit your needs.

The following list describes the various table types:

� Regular tables: Implemented as a heap.

� Append mode tables: Regular tables that are optimized primarily for INSERTs.

Append mode tables are suitable where you need to add new data and retrieve existing data, such as where you are dealing with customer accounts in a banking environment. There you record each change to the account through debits, credits, and transfers. You also have customers who want to review the history of changes to that account.

� Multidimensional clustering (MDC) tables: Implemented as tables that are physically clustered on more than one key, or dimension, at the same time.

Multidimensional clustering tables are used in data warehousing and large database environments. Clustering indexes on regular tables support single-dimensional clustering of data. MDC tables provide the benefits of data clustering across more than one dimension.


� Range-clustered tables (RCT): Implemented as sequential clusters of data that provide fast, direct access.

Range-clustered tables are used where the data is tightly clustered across one or more columns in the table. The largest and smallest values in the columns define the range of possible values. You use these columns to access records in the table.

� Regular tables with indexes: The “general purpose” table choice.

Figure 4-22 summarizes the differences between regular tables, append mode tables, regular tables with an index, multidimensional clustering tables with an index, and range-clustered tables.

Figure 4-22 Table type comparison

Long dataIn this section, we describe considerations when using long data. Long data is stored differently than other data types, so you must take this into account as you determine space requirements.

Long field data is stored in a separate table object that is structured differently than the storage space for other data types.

Data is stored in 32 KB areas that are broken into segments whose sizes are “powers of two” times 512 bytes. (Therefore, these segments can be 512 bytes, 1024 bytes, 2048 bytes, and so on, up to 32 768 bytes.)


Long field data types (LONG VARCHAR or LONG VARGRAPHIC) are stored in a way that enables free space to be reclaimed easily. Allocation and free space information is stored in 4 KB allocation pages, which appear infrequently throughout the object.

The amount of unused space in the object depends on the size of the long field data and whether this size is relatively constant across all occurrences of the data. For data entries larger than 255 bytes, this unused space can be up to 50%of the size of the long field data.

If character data is less than the page size, and it fits into the record along with the rest of the data, the CHAR, GRAPHIC, VARCHAR, or VARGRAPHIC data types should be used instead of the LONG VARCHAR or LONG VARGRAPHIC data types.


Chapter 5. Instance and database operations

In this chapter, we describe the key aspects of instance and database operations. Topics covered include instance operation and creation, configuration changes, managing database and log storage, backup and recovery, and high availability. Where possible, we provide extensive examples in order to familiarize you with the operational aspects of DB2. You will see in this chapter that much of the operation of DB2 can be done using the graphical interface. However, you can also choose to use the command line. Where this is the case, the GUI will create the syntax that you can then modify.

5


5.1 Instance operation modesDB2 and IDS have similar operating modes: online, offline, and quiescent. What differs is that DB2 administrators do not need to explicitly initialize the instance for first use, that is, oninit -i. In the following sections, we explore the operating modes of DB2, their implications, and differences with IDS.

5.1.1 Online modeIn DB2, the db2start command starts the current database manager instance background processes on a single database partition or on all the database partitions defined in a partitioned database environment. Start DB2 at the server before connecting to a database, precompiling an application, or binding a package to a database.

When the db2start command is executed, the system reads the value of DB2INSTANCE and starts the specified database manager instance. DB2 reads the DBM configuration file and sets up UNIX processes, called agents, and memory control structures to allow communication with the instance. Database manager global shared memory is allocated and remains allocated until the database manager is stopped, using the db2stop command. This area contains information that the database manager uses to manage activity across all database connections. When the first application connects to a database, both global and private memory areas are allocated.

Connecting, database activation, and terminationUnlike IDS, an instance can be active, but the database within the instance will not be unless a user either connects to the database using the connect command or an explicit activate command is issued. This means that memory usage for the overall instance might be lower, because inactive databases do not consume memory resources. To connect to the database, use the connect command as follows:

db2 connect to databasename user username using userpassword

For example:

db2 connect to idstodb2 user micky using mypwd

If a database is not yet running, the connect command will start the database and then establish a connection for the application issuing the command. After the database is running, any additional applications can connect and subsequently disconnect from the database, including the initial connection. The database will remain running as long as there is at least one connection attached to it. When all the applications have disconnected from the database,


the database will automatically shutdown.To explicitly end a connection, issue the db2 terminate command.

Instance attachmentAt the instance level, the administrator who wants to perform instance-level maintenance must use the attach command to initiate operations with that instance. Although multiple database connections can be maintained at a given time, only one attach can be in effect. For example:

db2 attach to nodename user username using userpassword

If ATTACH has not been executed, instance-level commands are executed against the current instance, specified by the DB2INSTANCE environment variable. To disconnect from an instance, simply issue the detach command.

5.1.2 Offline modeThe db2stop command terminates the DB2 instance. However, the instance will not stop unless all active processes are terminated. If you try to issue a db2stop command under this condition, you will get the following error:

07/18/2004 16:18:52 0 0 SQL1025N The database manager was not stopped because databases are still active.SQL1025N The database manager was not stopped because databases are still active.

You can override this error by using the db2stop force command. This is similar to the onmode -k command in IDS.

5.1.3 Quiescent modeQuiescent mode restricts new users from connecting and enables the administrator to perform maintenance activities. This is equivalent to the IDS onmode -s command. The following command forces all users off the specified instance, database, or both and puts it into a quiesced mode:

quiesce instance instancename / quiesce database databasename

In quiesced mode, users cannot connect from outside of the database instance. After administrative tasks are complete, use the following command to activate the instance and database and allow other users to connect to the instance or database, but avoid having to shut down and perform another database or instance start:

unquiesce instance instancename / unquiesce database databasename

Chapter 5. Instance and database operations 135

In this mode, only users with authority in this restricted mode are allowed to attach or connect to the instance or database. Users with SYSADM, SYSMAINT, and SYSCTRL authority always have access to an instance while it is quiesced, and users with SYSADM authority always have access to a database while it is quiesced.

Deactivating the databaseYou can choose to deactivate the database and release resources with the deactivate database command:

deactivate database databasename

Issuing a db2stop command, which stops the instance, will also deactivate all databases under that instance.

5.1.4 Creating and dropping the instanceSimilar to oninit -i command, the db2icrt command creates and configures the database manager instance on the server. Only the user, root, has authority to run this command. As part of this process, the environment variable DB2INSTANCE is set to the name of the database manager instance, and PATH is set to include the path to the DB2 UDB binary files. A new directory, sqllib, is created in the $HOME directory of the user specified as the SYSADM.

If it is a new installation, a DAS is created. The communications protocols that are supported on the server are examined, and entries are made in the operating system services file to allow communications with the DAS and the database manager instance.

Finally, the files necessary to set environment variables are created. The first of these two files is db2profile (or db2bashrc or db2cshrc, depending on your shell), which sets the default environment variables. This file is often overwritten by new versions of DB2 UDB or by fix packs. Do not make any changes to it. The second file is called userprofile and is provided for your use to set environment variables unique to your installation. It will not be overwritten by new versions of DB2 UDB or by fix packs. The db2drop command drops the DB2 instance.

For our testing, we used the default instance that was created when DB2 was installed. For more information about the syntax usage of the db2icrt command, refer to IBM DB2 UDB Command Reference, SC09-4828.


5.2 Modifying the configurationUnlike IDS, many configuration changes can be made while the instance, database, or both are online and without having to recycle the engine. More than 50 configuration parameters can now be set online as of Version 8.1. Refer to Chapter 4, for a list of parameters. Changes to these configurable online configuration parameters take immediate effect without the need to stop and start the instance or deactivate and activate the database. You no longer have to disconnect users when you fine-tune your system, giving you more flexibility for deciding when to change the configuration.

Examples of parameters that can be set online include memory heaps such as CATALOGCACHE_SZ, PCKCACHESZ, STMTHEAP, SORTHEAP, and UTIL_HEAP_SZ. Other parameters such as LOCKLIST size, MAXLOCKS, and DLCHKTIME (dead lock check time) will enable you to adjust the locking characteristics of your database system, which can improve performance. You can choose to defer a change to a configurable online configuration parameter so that the configuration change will be made at the next instance start or database activation. A SHOW DETAIL option is available in the GET DATABASE CFG and GET DATABASE MANAGER CONFIGURATION commands that will list both the current value and the value that will be used at the next instance start or database activation. In some cases, you can set the parameter you are configuring to automatic, and DB2 will then adjust its value automatically as workload on the system changes. For example, setting MAXAPPLS to automatic means that there is no limit to the maximum number of applications, except when memory is exhausted.

Recall from Chapter 4 that database manager configuration parameters are stored in a file named db2systm. Database configuration parameters are stored in a file named SQLDBCONF. These files cannot be directly edited and can only be changed or viewed through a supplied API or by a tool that calls that API. This is unlike IDS, which allows you to edit the onconfig file.

There are several methods of viewing, updating, and resetting configuration parameters. In Chapter 4, we outlined the command line and API methods. In this chapter, we provide an example using the Control Center graphical interface. All the methods shown apply to both the instance and database configuration.

5.2.1 Working with the DASAs you will recall from “The DB2 instance: Differences in architecture” on page 16, the DB2 Administration Server (DAS) provides administration services to remote clients and scheduling services. Although the DAS is automatically created at installation time and is automatically started when the system boots,


you can also manually create, start, stop, list, and remove the DAS. In IDS, each instance operates autonomously; there is no concept of a DAS.

The DAS is the connection between the GUI tools on the client and those on the server. If the DAS is not installed or has been stopped, you cannot connect to the database or databases using the GUI tools. Because there can be only one DAS running on the server, multiple instances and versions of DB2 UDB, such as V8.1 or V8.2, connect through the same DAS.

Some customers do not want to use the GUI administration tools, and their applications connect through JDBC (GUI uses ODBC), so they do not create the DAS. Most customers want the GUI interface, however.

To manually create the DAS:

� For UNIX, use:

dascrt -u dasuser

� For Intel®, use:

db2admin create /user:username /password:password

To start and stop the DAS, use:

db2admin startdb2admin stop

To list the DAS, use:

db2set -g DB2ADMINSERVER

To remove the DAS:

� For UNIX, use:

dasdrop

� For Intel, use:

db2admin drop

5.2.2 Viewing and updating the configuration using Control CenterWithin the Control Center, the Configure Instance option can be used to set the database manager configuration parameters on either a client or a server. The Configure Database option can be used to alter the value of database configuration parameters. The DB2 Control Center also provides the Configuration Advisor to recommend optimal configuration values based on the responses you provide to a set of questions, such as the workload and the type of transactions that run against the database. For more details, see Chapter 14.


Figure 5-1 contains an example showing configuration of the instance. To access this option, select the instance name from the Control Center and right-click Configure Parameters, as shown in Figure 5-1. After you make this selection, you will be promoted for your user ID and password. Note that you must have the appropriate level of instance or database authority to update the configuration.

Figure 5-1 Configuring parameters for an instance

Next, you will be shown a list of the available configuration parameters, which are conveniently categorized into areas such as applications, communications, diagnostic, and monitor. In this example, we are going to update the snapshot parameter to capture buffer pool information, DFT_MON_BUFFPOOL. (Unlike IDS where all diagnostics are turned on and an onstat command will retrieve them at the desired level of detail, you have the ability in DB2 to specify the level of detail and type of data for capturing database monitoring statistics. With DB2, if the appropriate switches are not turned on, this data will not be available.) Scroll down the list of parameters until you see DFT_MON_BUFFPOOL, click the value column for this item, and then click the +++ symbols next to the current value of OFF. You will then be presented with a window that prompts you to change the value of Monitor Buffer Pools to On, and whether you want this change to be dynamic (the Update when available option). Here, we select both options, as shown in Figure 5-2 on page 140.


Figure 5-2 Updating monitor buffer pools configuration parameter

Click OK, and you will be returned to the parameters list window. Notice in Figure 5-3 on page 141 that there are now two differences from what you saw earlier. First, there is now a Pending Value for DFT_MON_BUFPOOL, indicating that a change is pending. After the command is executed, the new value will be updated (it has not been run yet). Second, the Show Command button is no longer unavailable. Click the Show Command, and the Control Center will display the command syntax needed to update the configuration.


Figure 5-3 Update configuration parameter command syntax

You can also save the syntax by clicking Save. You can save it as a file or as a task in the Task Center. Click the Close button and then OK to save the configuration changes.

5.2.3 Managing buffer poolsBuffer pools are a critically important memory component and are the single most important element for good performance. As you will recall from Chapter 2, a buffer pool is memory used to cache table and index data pages as they are being read from disk or being modified. Because memory access is much faster than disk access, the less often the database manager needs to read from or write to a disk, the better the performance. Only large objects and long field data are not manipulated in a buffer pool. DB2 buffer pools are similar to IDS BUFFERS, except that with DB2, buffer pools are assigned to individual databases, instead of the instance.


With DB2, every database must have at least one buffer pool. One default buffer pool, IBMDEFAULTBP, is created when the CREATE DATABASE command is processed.

Creating a buffer pool Before you create a new buffer pool, resolve the following questions:

� What buffer pool name will you use? Issue the SELECT BPNAME FROM SYSCAT.BUFFERPOOLS command to get the list of buffer pool names that already exist in the database. The name must not begin with the characters “SYS” or “IBM”.

� Is the buffer pool to be created immediately, or created the next time that the database is deactivated and reactivated?

� What values do you want to associate with the parameters controlling the size of the buffer pool, including the page size and the total size of the buffer pool based on the number of pages?

� Do you want to use extended storage, block-based support, or neither? Using block-based buffer pools improves performance for sequential prefetching. If extended storage is enabled, it can be used as a secondary cache for pages that are evicted from the buffer pool. For more information, refer to IBM DB2 UDB Administration Guide: Performance, SC09-4821.

Memory is allocated for the buffer pool when a database is activated or when the first application connects to the database. Buffer pools can also be created, dropped, and resized while the database manager is running. If you use the IMMEDIATE keyword when you use the ALTER BUFFERPOOL command to increase the size of the buffer pool, memory is allocated as soon as you enter the command if the memory is available. If the memory is not available, the change occurs when all applications are disconnected and the database is reactivated. If you decrease the size of the buffer pool, memory is deallocated at commit time. When all applications are disconnected, the buffer pool memory is deallocated.

To create a buffer pool, you can use either the CREATE BUFFERPOOL command or use the Control Center tool. In Figure 5-4 on page 144, we show an example of creating a buffer pool named bp1 for the database Micky using the Control Center.

Important: The page sizes specified for your table spaces should determine the page sizes that you choose for your buffer pools. The choice of page size used for a buffer pool is important, because you cannot alter the page size after you create a buffer pool.


To create a the bp1 buffer pool, we performed the following steps:

1. Select the database where you will add the buffer pool.

2. Next, expand the list of Systems by clicking the + symbols, and locate the node and instance where the database resides.

Here the node (system) is GREENLAND, and the instance is GREEN1, which is the alias for DB2INST2. You can identify instances using alias names to avoid confusion with having the same instance name on more than one system.

3. After you locate the database, expand it to view the list of available objects. Objects you can work with in this view, in addition to buffer pools, include tables, views, triggers, table spaces, and even federated objects, such as IDS tables.

4. Right-click Buffer Pools, select Create, and the Create Buffer Pool dialog box opens. In this example we entered bp1 for the name, an 8 KB page size, 5000 as the number of pages allocated, and selected the Create bufferpool immediately option.

5. Click Show SQL to view the SQL. You can then copy the syntax to the Command Editor or save it to a file or save it to Task Center. The Task Center gives you the capability to run the syntax immediately or to use the scheduler, which is part of DB2.

You will also notice in Figure 5-4 on page 144 in the lower-right corner that the Control Center summarizes key indicators for the database, such as database status, date of last backup, amount of disk space allocated, and status of database maintenance. This provides a useful summary of the state of the database.


Figure 5-4 Create buffer pool example

After a buffer pool has been created, it can be associated with one or more table spaces. This is done with the CREATE TABLESPACE command, which we discuss in 5.3, “Managing database storage” on page 145.

Altering a buffer poolBuffer pools can be resized to accommodate your changing memory requirements. This can be accomplished using the Control Center GUI or through the command line. Figure 5-5 on page 145 illustrates decreasing the bp1 buffer pool we previously created to 4000 8k pages.


To resize the buffer pool, we performed the following steps:

1. Right-click the buffer pool name bp1, and select the Alter option. The Alter Buffer Pool dialog box opens.

Notice that you cannot change either the buffer pool name or page size after the buffer pool has been created.

2. In this example, we chose the Alter bufferpool immediately option to have the changes take place as soon as possible, instead of having to restart the database. We also clicked Show SQL to display the ALTER BUFFERPOOL syntax. As with the other examples, you can copy the syntax to the Command Editor, or save the SQL to a file or to the Task Center.

Figure 5-5 Alter buffer pool example

5.3 Managing database storageIn DB2, there are two areas of storage management to be concerned with: database disk management and log file management. Chapter 4 discussed table spaces and containers in details, along with best practices for setting up your environment. In this section, we discuss how to set up and manage storage for


data, as well as storage for transaction logging and maintaining database integrity.

5.3.1 Table spaces and containersAs you will recall from Chapter 4, DB2 database data is managed within table spaces and containers, which are similar to the IDS concept of dbspaces and chunks. Table spaces can be of two types: System Managed Space (SMS) or Database Managed Space (DMS). An SMS table space is created using directory containers. The DMS table space is created using either file containers or device containers. Device containers are similar to IDS raw disk.

Creating and altering table spaces and containersThe syntax and process to create table spaces is similar, whether using DMS or SMS.

The basic parameters needed to explicitly create a table space are the table space name, how it is managed, and the container or containers. Optionally, you can specify the use of the table space, such as regular or user-temporary. You can also optionally specify page size, extent size, prefetch size, and buffer pool name. In DB2 UDB, sizes can be entered in four different units:

� Integer: pages� Integer K: kilobytes� Integer M: megabytes� Integer G: gigabytes

By contrast, IDS uses kilobytes.

Figure 5-6 on page 147 shows an example of creating a DMS table space using a file.

To create a new table space, perform the following steps.

1. Select and right-click Tablespaces. The Create Table Space Wizard dialog box opens.

2. Enter the table space name; here, we use harry. You can optionally enter a comment. Click Next.

Important: The SMS table space is full as soon as any one of its containers is full. Therefore, it is important to have the same amount of space available to each container.


Figure 5-6 Creating a DMS table space

3. Now, specify the type of table space to create, as shown in Figure 5-7 on page 148. We choose Regular, because we will be storing table data in this table space.


Figure 5-7 Table space type

4. Next, we proceed through a series of windows that will help construct the appropriate CREATE TABLESPACE statement, such as specifying the buffer pool (the bp1 we created earlier), containers to be used (chunks in IDS), page size, extent size, disk performance specifications, and disk space to be used for this table space. Figure 5-8 on page 149 summarizes the options we selected.


Figure 5-8 Table space options

5. Clicking Show SQL to display the SQL statement, which you can then save or copy for future use.

Use the ALTER TABLESPACE statement to modify an existing table space. You can make the following changes:

� Add a container to, or drop a container from, a DMS table space.

� Modify the size of a container in a DMS table space.

� Modify the following parameters: PREFETCHSIZE, BUFFERPOOL, OVERHEAD, or TRANSFERRATE.

� Modify the file system caching policy for a table space.

When new containers are added to a table space or existing containers are extended, a rebalance of the table space data might occur. See 14.4.6, “Throttling utilities” on page 483 for a discussion of rebalancing and the implications.

Adding a container that is smaller than existing containers results in a uneven distribution of data. This can cause parallel I/O operations (such as prefetching data) to perform less efficiently than they otherwise could on containers of equal


size. Also remember that you cannot add containers to SMS table spaces except by using redirected restore.

With a DMS table space, you can drop a container from the table space or reduce the size of a container. You use the ALTER TABLESPACE statement to accomplish this. Dropping or reducing a container will only be allowed if the number of extents being dropped by the operation is less than or equal to the number of free extents above the high-water mark in the table space. This is necessary, because page numbers cannot be changed by the operation, and therefore, all extents up to and including the high-water mark must sit in the same logical position within the table space. Therefore, the resulting table space must have enough space to hold all of the data up to and including the high-water mark. In the situation where there is not enough free space, you will receive an error immediately upon execution of the statement.

Recall from Chapter 4 that the high-water mark is the page number of the highest allocated page in the table space. For example, a table space has 1000 pages and an extent size of 10, resulting in 100 extents. If the forty-second extent is the highest allocated extent in the table space, that means that the high-water mark is 42 * 10 = 420 pages. This is not the same as used pages, because some of the extents below the high-water mark might have been freed up such that they are available for reuse.

In Figure 5-9 on page 151, we add another container to the table space harry by right-clicking the table space name and selecting the Alter Table Space option. Click the Containers tab, and you can then select the directory in which to create the new container. We label the container harryts2.


Figure 5-9 Alter table space

Click OK. You can then use the Show SQL button again to display the ALTER TABLESPACE syntax, as depicted in Figure 5-10 on page 152.


Figure 5-10 Alter table space syntax

5.3.2 Monitoring table space and container storageTwo methods are available to help you understand how much disk space you are using for the database objects. You can use either DB2 commands or the Storage Management tool. We discuss both topics in the following sections.

Monitoring table space storage from the command lineWithin DB2 UDB, you can use the DB2 command list tablespaces show detail to view the table space type, page allocation and usage, extent size, page size, number of containers for all table spaces, and the table space state. You will first need a database connection to do so. Keep in mind that if you are using an SMS table space, all of the allocated pages are shown as used, and the free page value is not applicable. If you just want summary information, you can also use the list tablespaces command.

Example 5-1 on page 153 depicts the detailed output from the list tablespaces show detail command.


Example 5-1 The db2 list tablespaces show detail output

cindym:/home/cindym> db2 list tablespaces show detail

Tablespaces for Current Database

Tablespace ID = 0 Name = SYSCATSPACE Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 5649 Useable pages = 5649 Used pages = 5649 Free pages = Not applicable High water mark (pages) = Not applicable Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 32 Number of containers = 1

Tablespace ID = 1 Name = TEMPSPACE1 Type = System managed space Contents = System Temporary data State = 0x0000 Detailed explanation: Normal Total pages = 1 Useable pages = 1 Used pages = 1 Free pages = Not applicable High water mark (pages) = Not applicable Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 32 Number of containers = 1

Tablespace ID = 2 Name = USERSPACE1 Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 5 Useable pages = 5


Used pages = 5 Free pages = Not applicable High water mark (pages) = Not applicable Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 32 Number of containers = 1

Tablespace ID = 3 Name = DATATBS_1 Type = Database managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 65536 Useable pages = 65520 Used pages = 31424 Free pages = 34096 High water mark (pages) = 40080 Page size (bytes) = 4096 Extent size (pages) = 16 Prefetch size (pages) = 16 Number of containers = 1

Tablespace ID = 4 Name = IDXTBS_1 Type = Database managed space Contents = Any data State = 0x0000 Detailed explanation: Normal Total pages = 32768 Useable pages = 32752 Used pages = 48 Free pages = 32704 High water mark (pages) = 48 Page size (bytes) = 4096 Extent size (pages) = 16 Prefetch size (pages) = 16 Number of containers = 1

Tablespace ID = 5 Name = SYSTOOLSPACE Type = System managed space Contents = Any data State = 0x0000 Detailed explanation: Normal


Total pages = 2 Useable pages = 2 Used pages = 2 Free pages = Not applicable High water mark (pages) = Not applicable Page size (bytes) = 4096 Extent size (pages) = 32 Prefetch size (pages) = 32 Number of containers = 1

In Example 5-1 on page 153, you can see details for six table spaces, with table space IDs that begin at 0 (note that IDS begins dbspace numbering from 1). Three default table spaces are shown. They are SYSCATSPACE, for system objects, TEMPSPACE1, for temporary usage, and USERSPACE1, for user data. All three table spaces are defined as system managed storage (SMS). SYSTOOLSPACE is a table space used for automatic statistics collection, and DATATBS_1 and IDXTBS_1 are database managed storage (DMS) and were defined by the user to hold table data and index data, respectively.

To find more information, you can use the DB2 command list tablespace containers for tablespace_number show detail. You can obtain the table space number for a container from the list tablespaces show detail command listed previously. This provides the path to the storage container. With this information, you can view the container using system tools, such as ls -al or du -k -s directory_name.

Table space statesThe state of the table space indicates its current status. This is similar to the hexadecimal flags output for dbspaces from the onstat -d command in IDS, shown in Figure 5-11 on page 156.


Figure 5-11 The onstat -d output

State in DB2 is a hexadecimal value indicating the current table space state. The state of a table space is composed of the hexadecimal sum of its state values. For example, if the state is “quiesced: EXCLUSIVE” and “Load pending”, the value is 0x0004 + 0x0008, which is 0x000c. The db2tbst (get tablespace state) command can be used to obtain the table space state associated with a given hexadecimal value. Example 5-2 shows the bit definitions listed in sqlutil.h.

Example 5-2 DB2 table space states

0x0 Normal0x1 Quiesced: SHARE0x2 Quiesced: UPDATE0x4 Quiesced: EXCLUSIVE0x8 Load pending0x10 Delete pending0x20 Backup pending0x40 Roll forward in progress0x80 Roll forward pending0x100 Restore pending0x100 Recovery pending (not used)0x200 Disable pending0x400 Reorg in progress0x800 Backup in progress0x1000 Storage must be defined0x2000 Restore in progress

IBM Informix Dynamic Server Version 9.40.FC3 -- On-Line -- Up 2 days 02:09:37

-- 2591472 Kbytes

Dbspaces

address number flags fchunk nchunks flags owner name

700000080183e58 1 0x60001 1 1 N B informix rootdbs

700000080497780 2 0x68001 2 1 N SB informix s9_sbspc

700000080497900 3 0x60001 3 1 N B informix idxdbs

700000080497a80 4 0x60001 4 1 N B informix dbs1

4 active, 2047 maximum

Chunks

address chunk/dbs offset size free bpages flags pathname

700000080184028 1 1 0 16384 9460 PO-B /usr/informix/chunks/940/chunk1

…

7000000804975e8 4 4 0 16000 23 PO-B /usr/informix/chunks/chunk3

4 active, 32766 maximum

Expanded chunk capacity mode: always

onstat –d flags


0x4000 Offline and not accessible0x8000 Drop pending0x2000000 Storage may be defined0x4000000 StorDef is in 'final' state0x8000000 StorDef was changed prior to rollforward0x10000000 DMS rebalancer is active0x20000000 TBS deletion in progress0x40000000 TBS creation in progress0x8 For service use only

Referring back to Example 5-1 on page 153, we see that for table space ID 4, IDXTBS_1, the state was 0x0000, or normal.

The Storage Management toolThe Storage Management tool provides you with the ability to monitor database storage, including table spaces, containers, tables, and indexes.

Using the tool, you can:

� Display table space container statistics including size, total pages, and usable pages.

� Display table statistics such as number of rows and table space name.

� Set thresholds for data skew, space usage, and index cluster ratio. If a target object exceeds a specified threshold, the icons beside the object and its parent object in the Storage Management view are marked with a warning flag, indicated by a yellow triangle, or an alarm flag, indicated by a red circle.

� Take snapshots of storage objects. When a table space snapshot is taken, statistical information is collected from the system catalogs and database monitor for tables, indexes, and containers defined under the scope of the given table space. This information can be used for trend analysis.

When a database or database partition group snapshot is taken, statistical information is collected for all the table spaces defined in the given database or database partition group. To launch the tool for an entire database, select and right-click the database name in Control Center, and then select Manage Storage. Figure 5-12 on page 158 shows a chart displaying a historical analysis of the table space DATATBS_1. You will notice that the space increased slightly at 3:03PM. This was due to creation of an additional table in this table space. Also notice the red circle indicators on several of the table spaces, such as

Note: In order to see accurate storage data for databases in the Storage Management view, you must have up-to-date table statistics.


SYSCATSPACE. These indicate that space has exceeded our defined thresholds.

Figure 5-12 Storage Management tool

5.3.3 Transactions and logsBoth IDS and DB2 UDB support many variations of logging at the database level. Although the objective is the same, physical and logical recovery of changes to the instance and databases, the implementation of the logging is very different. We explain each approach in the following sections.

Transaction logging occurs at the database level in DB2 UDB and can be enabled differently for each database in the instance. Unlike IDS, DB2 uses a single set of logs. In DB2, UDB logging must be either circular or archival. The option of NO LOG, which is available with IDS, does not exist in DB2 UDB, although you can use the NOT LOGGED INITIALLY option on the CREATE

Note: Typically, you will not want to set up thresholds for system managed storage table spaces, because with SMS, the space will always be viewed as full, and the Percent Used indicator will show 100%, because the space grows with usage. It is still helpful to monitor SMS spaces, because your charts will show growth in the actual size over time and provide you with a helpful view of overall data usage.


TABLE statement to avoid logging transactions on an initial table create/load. With this option, any changes made to the table by an Insert, Delete, Update, Create Index, Drop Index, or Alter Table operation in the same unit of work in which the table is created are not logged.

An IDS database can be created WITH LOG, NOT LOGGED, or ANSI-compliant transaction logging mode. DB2 uses ANSI-compliant logging. With DB2, you do not need to mark the beginning of a transaction; you only need to mark the end. Transactions begin implicitly with the first SQL statement executed and end with a COMMIT or ROLLBACK. Note that using the IDS BEGIN WORK syntax will result in an error in DB2.

IDS uses a combination of a physical log and logical log for database recovery. The physical log contains an image of the page prior to change, and the logical log records the transaction. DB2 UDB implements write-ahead logging in which the changed data is always written to the log files before the change is committed. DB2 UDB logs changes in its log files, including the old version of the data.

Managing logsThe number of logs to configure, their sizes, and other parameters affecting logging are set in the IDS ONCONFIG configuration file and in DB2 using database configuration parameters. Both DB2 and IDS support configurations that can dynamically extend the logs (using secondary logs) when log space is exhausted. DB2, by default, stores log files in the directory specified by the database configuration parameter LOGPATH. However, this parameter is only informational, the database configuration parameter NEWLOGPATH parameter should be used to indicate a different location. Log files can be system files or raw devices. You can control the number and size of the DB2 log files with the LOGPRIMARY, LOGSECOND, and LOGFILSIZ database parameters. Consult the IBM DB2 UDB Administration Guide: Performance, SC09-4821, for details.

The DB2 transaction log is an important part of the backup and recovery processes. The transaction log records all committed changes to the database and it is used to bring the database to a consistent point after a power failure. It can also be used to restore a database to its current state after media failure or application failure.

A total size of 256 GB is supported for logging. In addition to the primary logs, DB2 UDB also uses a number (between 0 and 126) of secondary logs as specified in the LOGSECOND parameter. Secondary logs do not occupy permanent file space, but are allocated one at a time as needed and deallocated as they are not needed. Secondary logs are used when the primary logs fill up and more log space is required. Infinite active logging is also new in DB2 Version 8. Its allows an active unit of work to span the primary logs and archive logs,


effectively allowing a transaction to use an infinite number of log files. Without infinite active log enabled, the log records for a unit of work must fit in the primary log space. Infinite active log is enabled by setting LOGSECOND to -1. Infinite active log can be used to support environments with large jobs that require more log space than you would normally allocate to the primary logs.

Another important configuration parameter, BLK_LOG_DSK_FUL, enables you to specify that DB2 should not fail when running applications on disk full condition from the active log path. When you enable this option, DB2 will retry every five minutes, enabling you to resolve the full disk situation and allowing the applications to complete.

The amount of space (in bytes) required for primary log files is:

(LOGPRIMARY * (LOGFILSIZ + 2) * 4096) + 8192

The amount of space (in bytes) required for primary and secondary log files is:

(LOGPRIMARY + LOGSECOND) * (LOGFILSIZ + 2) * 4096) + 8192

You need to monitor the log storage directory to ensure that you have enough file system space to hold the logs.

Logging modesDB2 has two main logging modes: non-recoverable, and recoverable.

When a database is created, the default logging mode is non-recoverable, which is also known as circular logging. When circular logging is used, the log files are reused and overwritten when more space is needed. This type of logging is similar to setting the IDS logical log backup device to NULL.

The implications are that, with the exception of a system crash (where DB2 will perform crash recovery, which means undoing in-flight transactions and restoring the database to consistency), you must recover your database from a full offline backup. You cannot roll forward completed transactions that are contained in archive logs, but are not part of the offline backup. Circular logging is used to protect against power failure and by applications to roll back uncommitted changes if a processing error occurs. When this type of logging is enabled, both the LOGARCHMETH1 and LOGARCHMETH2 parameters are set to OFF. Only offline, full database backups can be performed with this type of logging.

The recovery logging mode is used for databases that require recovery at a transaction level. With this mode, logs are not reused, but are maintained online until they are archived. This type of logging provides all the protection of circular logging plus additional recovery benefits. The online and archived logs can be used, along with the last full backup, to recover a database back to the current state just before a media or application failure. The database backup can be


performed online or offline and can be a full database backup or a selected table space backup. Recovery of a database can be performed to the last current committed transaction before the failure or to some specific point in time using the ROLLFORWARD utility. Also, with this type of logging, recovery can be performed on a table space basis.

There are several options for how logs are archived with this mode. You can archive to disk, tape, use tape management software such as IBM Tivoli® Storage Manager, use third-party APIs, or write your own user exit. The processing of the primary logs is controlled by setting the LOGARCHMETH1 parameter. Secondary logs are controlled by setting the LOGARCHMETH2 parameter. For more information, refer to IBM DB2 UDB Data Recovery and High Availability Guide and Reference, SC09-4831.

DB2 UDB supports log mirroring and is enabled by setting the MIRRORLOGPATH database configuration parameter.

To configure database logging, perform the following steps:

1. Right-click the database to be configured, and select Configure Database Logging. You will be presented with a wizard that takes you through the required selections, as shown in Figure 5-13 on page 162.

2. Select the type of logging to be used. The current database, IFMX2DB2, has circular logging enabled. We are going to change this to archive logging (recoverable).


Figure 5-13 Configuring a database for recovery

3. Next, choose the location and size or your logs and mirrors (if using mirrors), the location of your backup, and any performance options by following the prompts. Here, we are archiving our logs to the file system (DISK), with a primary archive path of /tempcd/ifmx2db2a, a mirror log path of /tempcd/ifmx2db2m, a failure archive path of /tempcd/ifmx2db2f, with five primary and two secondary logs, each 1024 4k pages.

In this next example, depicted in Figure 5-14 on page 163, we show the resulting commands.


4. First, we connect to the database, issue a quiesce to stop activity, and then update the database configuration to reflect the new archiving method and path. When changing the type of logging, you must first backup the database before use. The wizard also automatically issues the backup. Note that the database will be taken offline for the backup, because circular logging does not allow online backups.

Figure 5-14 Configuring recovery logging: Summary page


5.4 Backup and recoveryDB2 has a rich architecture for defining and managing backup and recovery tasks. A database can become unusable because of hardware or software failure, or both. Each failure scenario requires a different recovery action. It is critical to protect your data against the possibility of loss by having a well-rehearsed recovery strategy in place, just as you did with IDS. As you make the transition from IDS to DB2, you should consider:

� Will the database be recoverable?

� How much time can be spent recovering the database?

� How much time will pass between backup operations?

� How much storage space can be allocated for backup copies and archived logs?

� Will table space level backups be sufficient, or will full database backups be necessary?

� Should I configure a standby system, either manually or through high availability disaster recovery (HADR)? HADR is discussed in 5.5, “High availability” on page 176.

Your overall strategy should also include procedures for recovering command scripts, applications, user-defined functions (UDFs), stored procedure code in operating system libraries, and load copies.

In the next section, we examine the major components of DB2 for backup and recovery and, where possible, compare them to IDS concepts.

5.4.1 Recovery typesThe concept of a database backup for DB2 is the same as for IDS: taking a copy of the data and then storing it on a different medium in case of failure or damage to the original. The simplest case of a backup involves shutting down the database to ensure that no further transactions occur and then simply backing it up. You can then rebuild the database if it becomes damaged or corrupted in some way.

Important: In DB2 Version 8.2, DB2 no longer requires the user of a user exit to archive logs. Also, the LOGARCHMETH1 and LOGARCHMETH2 parameters replace the LOGRETAIN and USEREXIT parameters that were used prior to V8.2. LOGRETAIN and USEREXIT are still available to maintain upward compatibility.


In DB2, the rebuilding of the database is called recovery. There are three types of recovery: version recovery, crash recovery, and rollforward recovery.

Version recoveryVersion recovery is the restoration of a previous version of the database, using an image that was created during a backup operation. Version recovery is equivalent to performing a physical restore in IDS.

Crash recoveryCrash recovery is the automatic recovery of the database if a failure occurs before all of the changes that are part of one or more units of work (transactions) are completed and committed. This type of recovery is equivalent to IDS fast recovery. DB2 performs crash recovery by rolling back incomplete transactions and completing committed transactions that were still in memory when the crash occurred. Crash recovery is performed automatically when required. Recovery log files and the recovery history file are created automatically when a database is created. These log files are important if you need to recover data that is lost or damaged.

As discussed in the previous section, each database includes recovery logs, which are used to recover from application or system errors. In combination with the database backups, they are used to recover the consistency of the database right up to the point in time when the error occurred. The recovery history file contains a summary of the backup information that can be used to determine recovery options if all or part of the database must be recovered to a given point in time. It is used to track recovery-related events such as backup and restore operations, among others. This file is located in the database directory.

The table space change history file, which is also located in the database directory, contains information that can be used to determine which log files are required for the recovery of a particular table space. You cannot directly modify the recovery history file or the table space change history file; however, you can delete entries from the files using the PRUNE HISTORY command. You can also use the rec_his_retentn database configuration parameter to specify the number of days that these history files will be retained.

Data that is easily recreated can be stored in a non-recoverable (circular logging) database, as discussed in “Logging modes” on page 160. When circular logging is enabled, the only logs that are kept are those required for crash recovery. These logs are known as active logs, and they contain current transaction data. Version recovery using offline backups is the primary means of recovery for a non-recoverable database. Such a database can only be restored offline. It is restored to the state it was in when the backup image was taken and rollforward recovery is not supported.


Rollforward recoveryRollforward recovery is the reapplication of transactions recorded in the database log files after a database or a table space backup image has been restored. Rollforward recovery is the equivalent of applying the logical logs in IDS.

When using a recoverable, or archiving enabled, database, both active logs and archived logs (which contain committed transaction data) can be used for recovery. This is known as rollforward recovery. Using the ROLLFORWARD utility, after you restore the online backup, you can then roll the database forward and apply transactions that took place after the backup by using the active and archived logs. You can roll forward to either a specific point in time, or to the end of the active logs.

For recoverable databases, backup operations can be performed either offline or online (online meaning that other applications can connect to the database during the backup operation). Online table space restore and rollforward operations are supported only if the database is recoverable. If the database is non-recoverable, database restore and rollforward operations must be performed offline. During an online backup operation, rollforward recovery ensures that all table changes are captured and reapplied if that backup is restored.

If you have a recoverable database, you can back up, restore, and roll individual table spaces forward, rather than the entire database. When you back up a table space online, it is still available for use, and simultaneous updates are recorded in the logs. When you perform an online restore or rollforward operation on a table space, the table space itself is not available for use until the operation completes, but users are not prevented from accessing tables in other table spaces.

Automated backup operations Because it can be time-consuming to determine whether and when to run maintenance activities such as backup operations, you can use the Configure Automatic Maintenance wizard to do this for you. With automatic maintenance, you specify your maintenance objectives, including when automatic maintenance can run. DB2 then uses these objectives to determine if the maintenance activities need to be done and then runs only the required maintenance activities during the next available maintenance window (a user-defined time period for the running of automatic maintenance activities). You can still perform manual backup operations when automatic maintenance is configured. DB2 will only perform automatic backup operations if they are required. For more information, see 14.5.1, “Configuring automatic maintenance” on page 485.


5.4.2 Backup and restore methodsAs with IDS, you can perform both full and incremental backups and restores. An incremental backup is a backup image that contains only pages that have been updated since the previous backup was taken. In addition to updated data and index pages, each incremental backup image also contains all of the initial database metadata (such as database configuration, table space definitions, database history, and so on) that is normally stored in full backup images.

Two types of incremental backup are supported:

� Incremental: An incremental backup image is a copy of all database data that has changed since the most recent, successful, full backup operation. This is also known as a cumulative backup image, because a series of incremental backups taken over time will each have the contents of the previous incremental backup image. The predecessor of an incremental backup image is always the most recent successful full backup of the same object. This is the equivalent of an IDS Level 0 archive.

� Delta: A delta, or incremental delta, backup image is a copy of all database data that has changed since the last successful backup (full, incremental, or delta) of the table space in question. This is also known as a differential, or non-cumulative, backup image. The predecessor of a delta backup image is the most recent successful backup containing a copy of each of the table spaces in the delta backup image.

The key difference between incremental and delta backup images is their behavior when successive backups are taken of an object that is continually changing over time. Each successive incremental image contains the entire contents of the previous incremental image, plus any data that has changed, or is new, since the previous full backup was produced. Delta backup images contain only the pages that have changed since the previous image of any type was produced.

Combinations of database and table space incremental backups are permitted in both online and offline modes of operation. Be careful when planning your backup strategy, because combining database and table space incremental backups implies that the predecessor of a database backup (or a table space backup of multiple table spaces) is not necessarily a single image, but could be a unique set of previous database and table space backups taken at different times. The history file will help you to decide the best approach for recovery.

To rebuild the database or the table space to a consistent state, the recovery process must begin with a consistent image of the entire object (database or table space) to be restored, and must then apply each of the appropriate incremental backup images in the order described in the following section.


BackupThe simplest form of the DB2 backup database command requires only that you specify the alias name of the database that you want to back up, for example:

backup db ifmx2db2

If the command completes successfully, you will have acquired a new backup image that is located in the path or the directory from which the command was issued. It is located in this directory because the command in this example does not explicitly specify a target location for the backup image.

Figure 5-15 on page 169 shows an example of running an offline backup using the backup wizard. The wizard guides you through a series of windows to determine the appropriate options. In this example, we are performing a compressed database backup. Because this database is enabled with circular logging and is nonrecoverable, an offline backup is being performed. The backup location is to a file system in the /home/db2/backups directory. The tunable parameters, such as number and size of buffers, are configured for you, although you have the option to change them. The final SQL shows you the syntax generated.


Figure 5-15 Database backup

Note that log files can also be included in the backup image. If you are using a database with recovery enabled, you will have other backup options, such as performing an incremental or delta backup and performing the backup online instead of offline.

If you want to enable incremental backups, you will need to set the database configuration parameter, TRACKMOD, to YES, by issuing the command:

UPDATE DB CONFIG USING TRACKMOD YES

RecoveryThere are two methods for database recovery. The first, uses the RESTORE command, combined with the ROLLFORWARD command. The second, uses the new RECOVER command. We discuss both in this section.


RESTORE and ROLLFORWARD commandsBefore we recover a database, it is important to first understand the recovery history file. A recovery history file contains the history of backup and restore events and is created with each database. It is automatically updated whenever any database object is backed up, restored, rolled forward, when table spaces are created, altered or dropped, or when a table is loaded, dropped, or reorganized.

You can use the summarized backup information in this file to recover all or part of a database to a given point in time. The information in the file includes:

� An identification (ID) field to uniquely identify each entry � The part of the database that was copied and how � The time the copy was made � The location of the copy (stating both the device information and the logical

way to access the copy) � The last time a restore operation was done � The time at which a table space was renamed, showing the previous and the

current name of the table space � The status of a backup operation: active, inactive, expired, or deleted � The last log sequence number saved by the database backup or processed

during a rollforward recovery operation

To see the entries in the recovery history file, use the History tab in the Journal, or issue the LIST HISTORY command from the command line. Figure 5-16 on page 171 depicts the history for the IFMX2DB2 database, showing a backup, table loads, table space creates, and table drops.


Figure 5-16 Example history file for the IFMX2DB2 database

Every backup operation (database, table space, or incremental) includes a copy of the recovery history file. The recovery history file is linked to the database, and therefore, dropping a database deletes the recovery history file. Restoring a database to a new location restores the recovery history file. Restoring does not overwrite the existing history recovery file unless the file that exists on disk has no entries. If that is the case, the database history will be restored from the backup image.

If the current database is unusable or not available, and the associated recovery history file is damaged or deleted, an option on the RESTORE command allows only the recovery history file to be restored. The recovery history file can then be


reviewed to provide information about which backup to use to restore the database.

The simplest form of the DB2 RESTORE DATABASE command requires only that you specify the alias name of the database that you want to restore. For example:

db2 restore db ifmx2db2

In this example, because the IFMX2DB2 database exists, the following message is returned:

SQL2539W Warning! Restoring to an existing database that is the same as the backup image database. The database files will be deleted. Do you want to continue? (y/n)

If you specify “y”, and a backup image for the IFMX2DB2 database exists, the restore operation should complete successfully.

A database restore operation requires an exclusive connection. That is, no applications can be running against the database when the operation starts, and the restore utility prevents other applications from accessing the database until the restore operation completes successfully. A table space restore operation, however, can be done online. A table space is not usable until the restore operation (followed by rollforward recovery) completes successfully. In addition, you can perform restores across like-endian operating systems. This means that you can restore between AIX, Solaris, and HP-UX, and from Windows to Windows, and Linux to Linux.

In this example, we do a full database restore on database micky.

To restore the database using the Control Center, perform the following steps:

1. Right-click the database to be restored, and select Restore. You will be presented with a wizard that guides you through a series of questions.

2. First, choose the kind of restore to be performed: restore to existing, restore to new database (a redirected restore), or restore history file. If you choose redirected restore, you will be prompted for the name of the new database, and location for database and logs after the restore. Our example will restore to an existing database.

In the next step, DB2 will look at the history file to determine what backups you have available for restore. Remember that if you are using circular logging, you can only restore a full backup; no rollforward is allowed. We have enabled micky for recovery, so we will restore the backup and then roll forward through the logs.

In this example, shown in Figure 5-17 on page 173, we have two backups listed. We choose the backup from 8/17/04 at 12:20:15 PM.


Figure 5-17 Restore: selecting the backup image

You can also choose to redirect, or resize table space containers during restore.

3. Next, you will be prompted to either restore only, or restore and rollforward. You can roll forward to point in time, either to local time or Greenwich Mean Time (GMT), or to the end of the logs. We roll forward to end of logs.

The wizard also presents other options, such as whether to restore the logs or not, and performance options (we leave these as recommended). If you choose a full restore, you can restore the entire database or a selected table space. In this example, depicted in Figure 5-18 on page 174, we restore the entire database micky. We are presented with the list of backup images. We select the most current, 8/17/04 5:19:31 PM. Note that since the last backup was performed, a new table, Kaitlyn, was created, and data inserted. After we restore the backup, we also roll forward through the logs to restore the table and following transactions. We do not change the containers and we will restore the database and roll forward to end of logs.


Figure 5-18 Restore with rollforward

When the restore is complete, you will receive a list of informational messages indicating completion, as shown in Figure 5-19 on page 175.


Figure 5-19 Successful restore

Recover database commandThe new RECOVER DATABASE command combines the functionality of the RESTORE DATABASE and ROLLFORWARD DATABASE commands. When you use this command, you specify the point-in-time to which you want the database recovered. You do not need to indicate which database backup image must be restored or which log files are required to reach the specified point-in-time. The RECOVER DATABASE command also supports recovery operations to the end of the log files.

You should not be connected to the database that is to be recovered. The recover database utility automatically establishes a connection to the specified database. This connection is terminated at the completion of the recover operation. The following example shows how to use the RECOVER DATABASE command through the CLP:

db2 recover db micky


5.5 High availabilityAs you will recall from 2.7, “High availability” on page 48, DB2 has a variety of mechanisms for maintaining highly available databases. Each option meets different needs. In this section, we explore the implementation of several of these, including high availability disaster recovery (HADR) and mirroring.

5.5.1 HADR implementationAs you will recall from “High Availability Disaster Recovery” on page 48, HADR is a feature that was introduced to DB2 with Version 8.2. Modelled after IDS HDR, HADR is a database replication feature that provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary, to a target database, called the standby. A database that does not use HADR is referred to as a standard database. Note that while HDR with IDS is implemented at the instance level, HADR with DB2 is implemented at the database level.

DB2 HADR applications can only access the current primary database, while IDS applications can use the standby database in read-only mode. As with IDS, updates to the standby database occur by rolling forward log data that is generated on the primary database and shipped to the standby database. HADR can be set up using the Control Center GUI or from the command line.

The following scenario shows HADR set up and configuration.

As a prerequisite, you must configure your primary and standby environments:

� Configure your primary database with archive logging. This is a requirement for HADR (for instructions about how to do this, see “Logging modes” on page 160. In this example, we created an instance called db2prime.

� Create and configure a standby instance with TCP/IP communications enabled. This is a standard database instance created using the db2icrt command. You do not need to create a database for this instance; one will be created for you as part of the HADR configuration wizard. Our standby instance is called db2ha.

To set up and configure HADR:

1. In Control Center, select the database you want to configure by right-clicking, and then selecting High Availability Disaster Recovery- Set Up. The HADR introduction window opens. Click Next.

2. Identify the primary instance and database name, as shown in Figure 5-20 on page 177. Here the primary database is called FAMILY.


Figure 5-20 HADR step 2: Confirm primary database

3. Identify a standby instance and database population method. In this example, shown in Figure 5-21 on page 178, the standby instance is db2ha. You can create and populate the standby database from a backup image of the primary, through another database that already exists, or through a split image (for more information about creating a split image, see 5.5.4, “Online split mirror and suspended I/O support” on page 187). In our example, we will restore the standby database through a backup image.


Figure 5-21 HADR step 3: Select a standby database and initialization method

4. Identify the backup image to be used and select further backup options. The set up wizard will probe the history file to obtain a list of valid backups. As shown in Figure 5-22 on page 179, we select the backup taken at 8:06:32 PM on 8/17/04. Click Next and provide further options if you choose. Click Next again. (We skipped the options window.)


Figure 5-22 HADR step 4: Identify a backup image to populate the standby database

5. Configure TCP/IP communication parameters for the primary and secondary including HADR service names and port numbers for each instance. As shown in Figure 5-23 on page 180, we used the default values.


Figure 5-23 HADR step 5: Configure communications

6. Configure the client reroute. Unlike IDS, DB2 has automatic client reroute, which will reroute the instance connection automatically in the event of failure. As shown in Figure 5-24 on page 181, we are prompted for client reroute host and port numbers. In this example, we used the default values.


Figure 5-24 HADR step 6: Configure the client reroute

7. Specify the type of synchronization you want to implement. The three choices, synchronous, near synchronous, and asynchronous, all have advantages and disadvantages. For more information, see IBM DB2 UDB Data Recovery and High Availability Guide and Reference, SC09-4831. In this example, shown in Figure 5-25 on page 182, we chose synchronous. We also changed the connection period timeout from 120 to 60 seconds.


Figure 5-25 HADR step 7: Configure the synchronization and timeout parameters

8. Review your selections and start HADR. This window, shown in Figure 5-26 on page 183, summarizes the options we have chosen and starts HADR. Click Finish to initiate HADR.


Figure 5-26 HADR step 8: Start HADR

Next, a progress window opens, indicating the completion of each step, as shown in Figure 5-27 on page 184. You will also receive a message that “HADR database configuration completed successfully”.


Figure 5-27 HADR successful initialization

After HADR is set up, you can then monitor HADR by right-clicking the database from the Control Center and selecting High Availability Disaster Recovery- Manage. In Figure 5-28 on page 185, we see that the primary and standby databases are enabled to HADR. We also see that the log gap is 10 bytes. This is because a transaction was just issued against the primary to insert a row into a table, but it has not yet been applied to the standby. From this window, you can also stop HADR or issue a takeover. Issuing a takeover means that you switch roles between primary and standby databases.


Figure 5-28 HADR status

5.5.2 Log mirroringDB2 supports log mirroring at the database level, while with IDS, you can mirror not only logs but also any dbspace. Mirroring log files helps protect a database from accidental deletion of an active log and data corruption caused by hardware failure. The DB2 configuration parameter, MIRRORLOGPATH, specifies a secondary path for the database to manage copies of the active log, mirroring the volumes on which the logs are stored.The MIRRORLOGPATH configuration parameter allows the database to write an identical second copy of log files to a different path. We recommend that you place the secondary log path on a physically separate disk (preferably one that is also on a different disk controller). That way, the disk controller cannot be a single point of failure.

When MIRRORLOGPATH is first enabled, it will not actually be used until the next database startup. This is similar to the NEWLOGPATH configuration parameter. If there is an error writing to either the active log path or the mirror log path, the database will mark the failing path as bad, write a message to the administration notification log, and write subsequent log records to the remaining


good log path only. DB2 will not attempt to use the bad path again until the current log file is completed. When DB2 needs to open the next log file, it will verify that this path is valid, and if so, will begin to use it. If not, DB2 will not attempt to use the path again until the next log file is accessed for the first time. There is no attempt to synchronize the log paths, but DB2 keeps information about access errors that occur so that the correct paths are used when log files are archived. If a failure occurs while writing to the remaining good path, the database shuts down.

5.5.3 ReplicationDB2 UDB supports both SQL replication and queue replication to provide high availability. These functions maintain logically consistent copies of database tables at multiple locations. In addition, they provide flexibility and complex functionality, such as support for column and row filtering, data transformation, and updates to any copy of a table, and they can be used in partitioned database environments. DB2 replication is similar to IDS replication in this regard. Unlike IDS, DB2 offers two choices for replication, using SQL and using queues. The queue version of replication is targeted more at the needs of high availability. DB2 embeds WebSphere MQ technology for guaranteed message delivery.

For more information, see IBM DB2 Information Integrator Replication and Event Publishing Guide and Reference, SC18-7568.

Replication versus HADRFigure 5-29 on page 187 shows a comparison of HADR and queue-based replication. Each method offers advantages, so choose the method that best fits your requirements. If you absolutely need zero loss replication, HADR is the best fit. However, if you require read or read-write access to the secondary, you will want to choose queue replication.


Figure 5-29 HADR versus queue replication

5.5.4 Online split mirror and suspended I/O supportAs mentioned in Chapter 2, you can create a split mirror image of your database as a snapshot or clone, standby, or backup image. Frequently, this is achieved with the use of disk hardware or third-party packages that create a split mirror or snapshot of the database.

A split mirror is an instantaneous copy of the database that can be made by mirroring the disks containing the data and splitting the mirror when a copy is required. Disk mirroring is the process of writing all of your data to two separate hard disks, with one being the mirror of the other. Splitting a mirror is the process of separating the primary and secondary copies of the database.

If you would rather not back up a large database using the DB2 backup utility, you can make copies from a mirrored image by using suspended I/O and the split mirror function. This approach also eliminates backup operation overhead from the production machine and is a fast way to clone systems. Use the db2inidb command in conjunction with the suspend and resume commands to do this.


The SNAPSHOT option specifies that the mirrored database will be initialized as a clone of the primary database. You can then use this clone for testing or as a point-in-time failover environment. When you use the STANDBY option, the database will be placed in rollforward pending state. New logs from the primary database can be fetched and applied to the standby database. The standby database can then be used in place of the primary database if it goes down. The MIRROR option specifies that the mirrored database is to be used as a backup image which can be used to restore the primary database.

To clone a database using split mirror, perform the following steps:

1. Suspend I/O on the primary database:

db2 set write suspend for database

2. Use appropriate operating system-level commands to split the mirror or mirrors from the primary database.

3. Resume I/O on the primary database:

db2 set write resume for database

4. Catalog the mirrored database on the secondary system.

5. Start the database instance on the secondary system:

db2start

6. Initialize the mirrored database on the secondary system:

db2inidb database_alias as snapshot

Note: By default, a mirrored database cannot exist on the same system as the primary database. It must be located on a secondary system that has the same directory structure and uses the same instance name as the primary database. If the mirrored database must exist on the same system as the primary database, you can use the db2relocatedb utility or the RELOCATE USING option of the db2inidb command to accomplish this.


Chapter 6. SQL considerations

Although both IDS and DB2 support SQL standards, they both support extensions to those standards. There are both overt and subtle ramifications to SQL differences.

Some of the topics we discuss in this chapter include:

� SELECT and cursor issues

� Built-in functions

� DDL syntax

� Error handling

� String manipulation

� Various SET statements

6


6.1 SELECT issuesThe SELECT statement is one of the most widely used and most flexible SQL statements. There are many aspects of SELECT, and obviously, some of these will differ between IDS and DB2.

SELECT FIRSTBoth IDS and DB2 enable you to specify that only n number of rows are to be returned by a SELECT statement. They use different placement and words to specify this however:

� IDS:

SELECT FIRST n ...

� DB2:

SELECT ... FETCH FRIST n ROWS

SELECT cursors Consider the following SELECT cursors.

� SELECT FOR UPDATE

In IDS, for log mode ANSI databases, all cursors are update cursors by default. In IDS, for logged, non-mode ANSI databases, cursors must be explicitly defined FOR UPDATE. DB2 also requires FOR UPDATE wording.

In DB2, for cursors that are not used for update, you might want to consider adding the DB2 FOR READ ONLY wording to the cursor syntax. This clarifies the usage of the cursor and allows DB2 to avoid overly pessimistic locking.

� Cursors WITH HOLD

In both IDS and DB2, by default, open cursors are closed upon the termination of a transaction. Also, both IDS and DB2 allow cursors to be declared WITH HOLD to override this behavior.

In IDS, declaring a cursor WITH HOLD will hold a cursor open through any transaction end, both a COMMIT and a ROLLBACK. In DB2, WITH HOLD holds a cursor open only through a COMMIT.

Tip: DB2 cursors do not operate exactly the same as IDS cursors and they provide many options. We highly recommend that you read the DB2 documentation regarding SELECT statements and cursors.


Outer joinsIDS supports the same ANSI outer join syntax that is supported by DB2. The IDS original join support, OUTER, is the equivalent of a left outer join. The simple IDS wording, OUTER, is equivalent to a LEFT OUTER JOIN. DB2 does not support this stand-alone OUTER wording. As such, IDS OUTER wording must be converted to the ANSI syntax that DB2 supports.

� IDS:

SELECT.customer_num,c.lname, c.company, c.phone, u.call_dtime, u.call_descr FROM customer c, OUTER cust_calls u WHERE c.customer_num = u.customer_num

� IDS and DB2:

SELECT c.customer_num, c.lname, c.company, c.phone, u.call_dtime, u.call_descr FROM customer AS c LEFT OUTER JOIN cust_calls AS u ON c.customer_num = u.customer_num;

DECODE functionIDS supports both the DECODE function and the ANSI standard CASE statement. DB2 does not support the DECODE function, but supports the CASE statement. The CASE expression can be substituted for the DECODE function.

GROUP BYIDS supports a GROUP BY clause with either the column name or an ordinal number corresponding to the column position in the SELECT list. Currently, DB2 only supports the column name and not an ordinal number.

UNIQUE Both IDS and DB2 support the DISTINCT function in SELECT statements. IDS, however, also supports the UNIQUE keyword. DB2 does not support this syntax.

Stored procedure SELECTIDS supports the calling of a stored procedure from within a SELECT list:

SELECT marks_stored_procedure(col1) from tab1

DB2 does not support the calling of a stored procedure from within a SELECT list. However, DB2 does support the calling of user-defined functions.

Tip: DB2 closes cursors whenever a ROLLBACK occurs, regardless of WITH HOLD status.

Chapter 6. SQL considerations 191

Transitioning from IDS to DB2When transitioning from IDS to DB2, there are several options:

� DB2 user-defined functions can be written entirely in SQL. If you have an IDS stored procedure that simply executes some SQL, CREATE it as user-defined function rather than a stored procedure.

� Convert your stored procedure to a DB2 stored procedure under a different name. Create a DB2 user-defined function with the same name as your IDS stored procedure. Have this user-defined function call the stored procedure. The SELECT would call the user-defined function, which would call the stored procedure.

� Rewrite the stored procedure logic into a user-defined function in C or Java.

6.2 ROWIDROWID is a row addressing mechanism used internally by IDS. Although an internal function, ROWID is exposed to IDS users for use in applications.

DB2 uses its own addressing mechanism and, therefore, does not support ROWID specifically. You can, however, simulate the ROWID functionality in DB2. For each table requiring ROWID, add an integer column to that table named rowid. Assign the column the IDENTITY attribute. The IDENTITY attribute will generate unique values. For more information, see 10.5.4, “SERIAL and SERIAL8” on page 333.

6.3 MATCHES predicateFor wildcard matching in SELECT WHERE clauses, IDS supports both the ANSI standard LIKE syntax and a MATCHES syntax. DB2 supports only the ANSI standard LIKE syntax.

Table 6-1 MATCHES versus LIKE syntax

The syntax is:

� For IDS:

SELECT * FROM books WHERE title MATCHES “Atlas Shrug*”UPDATE cars SET name = “Corvette” where description MATCHES “C?”

One of any character None or many of any character

MATCHES ? *

LIKE _ %


� For IDS and DB2:

SELECT * FROM books WHERE title LIKE “Atlas Shrug*”UPDATE cars SET name = “Corvette” WHERE description LIKE “C?”

6.4 CommentsBoth IDS and DB2 support double dashes (--) for line-by-line comments.

Both IDS and DB2 support C-style /**/ delimiters around multiline comments.

IDS also supports curly braces ({}) for multiline comments. DB2 does not support this. For these, you should change to /* and */. For example:

-- these are line by line-- IDS or DB2 comments

{ this is a multiline IDScomment }

/* this is a multiline IDS or DB2comment */

6.5 Substring notationBoth IDS and DB2 support the SUBSTR(col, start, length) function. IDS also supports a column substring notation, col[start,end]. DB2 does not support this syntax. If you use the column function, you would need to change to an equivalent SUBSTR function.

The following substring notations are equivalent:

� For IDS:

col[start,end]

� For IDS and DB2:

SUBSTR(col,start,end-start+1)

6.6 SQLCODE and no rows foundIn IDS log mode ANSI databases and in DB2, the engine sets SQLCODE TO 100 (no rows found) for SELECTs that find no rows to return, DELETEs that find no rows to delete, UPDATEs that find no rows to update, and INSERT INTO/SELECT FROMs that find no rows to insert.


In IDS logged, non-mode ANSI databases and unlogged databases, SQLCODE is set to 100 (no rows found) only for SELECTs that find no rows to return. For DELETEs, UPDATEs, and INSERTs that execute correctly, but do not find rows to operate on, SQLCODE is set to 0.

Error and exception handling is very important to applications. It is possible that your application checks for no rows found conditions on SELECT statements only and not the other DML statements, simply because the condition has no impact on the application logic. If this is the case, a change in no rows found behavior will have minimal impact.

6.7 SQLSTATEThe SQLSTATE variable consists of two parts:

� A two-character error class that identifies the general classification of the error

� A three-character error subclass that identifies a specific type of error within a general error class

IDS and DB2 use many common SQLSTATE codes, but there are some that might be specific to IDS or DB2. Hopefully, your application has error and exception handling. If so, you will want to check for any proprietary error codes the application examines.

The ANSI standard method for error handling is the GET DIAGNOSTICS statement.

6.8 Built-in functionsTable 6-2 depicts both IDS and DB2 built-in functions. Remember that for cases where an exact duplicate, DB2 built-in function does not exist for a specific IDS function, you can always create your own user-defined function. These functions can be written from scratch, or you can use other similar, but existing DB2 functions along with customization to achieve the desired result.

Table 6-2 Function mapping

IDS function DB2 equivalent Comments

ABS ABS

AVG AVG


CARDINALITY

CHAR_LENGTH LENGTH Note1

COUNT COUNT

CURRENT CURRENT TIMESTAMP or CURRENT DATE

DATE DATE

DAY DAY

DBSERVERNAME CURRENT SERVER

DECODE CASE

EXTEND Note 4

HEX HEX

INITCAP

LENGTH LENGTH Note 1

LOWER LOWER

LPAD

MAX MAX

MDY

MIN MIN

MOD MOD

MONTH MONTH

NVL COALESCE or VALUE

ROUND ROUND

RPAD

STDEV STDEV

SUBSTR SUBSTR

SUM SUM

TODAY CURRENT DATE



Notes:

1. In IDS, LENGTH returns the number of bytes in a column excluding trailing spaces (except for BLOB and TEXT where it does include trailing spaces). For single-byte character sets, such as English, this equates to the number of characters in a column, because each character is one byte.

CHAR_LENGTH, however, returns the number of logical characters in a column excluding trailing spaces. For double-byte character sets, this might be different from the number of bytes. For single-byte character sets, CHAR_LENGTH is still the same as LENGTH.

The DB2 LENGTH function, by definition, behaves like the IDS CHAR_LENGTH function, not the IDS length function. When using single-byte character sets, because one character equals one byte, you can still use the DB2 LENGTH function because it returns the same value as the IDS LENGTH function.

2. IDS uses a singular TRIM function to trim leading spaces, trailing spaces, or both. This is done with a parameter to the TRIM function. DB2, however, uses LTRIM to trim leading spaces on the left, and the RTRIM function to trim trailing spaces on the right. The equivalent conversions are:

– For IDS:TRIM(LEADING, col1)TRIM(TRAILING, col1)

– For DB2:LTRIM(col1)RTRIM(col2)

TO_CHAR TO_CHAR Note 4

TO_DATE TO_DATE Note 4

TRIM LTRIM and RTRIM Note 2

TRUNC TRUNC

UPPER UPPER

USER CURRENT USER

VARIANCE VARIANCE

WEEKDAY DAYOFWEEK(date) -1 Note 3

YEAR YEAR



If your IDS application uses TRIM extensively, you might consider creating a DB2 user-defined function named TRIM that emulates the functionality of the IDS TRIM.

3. The closest equivalent of the IDS WEEKDAY function is the DB2 DAYOFWEEK function.

Be aware of the IDS and DB2 day of week numbering difference. If your application uses SQL exclusively to manipulate dates, this might not be an issue for you, because all DB2 SQL functions will work consistently on the same DB2 day of week numbering scheme.

If your application uses custom logic where you have specifically mentioned the day of week number, you can do one of the following:

– Apply the minus one factor to the DAYOFWEEK function call to match results to your existing application logic.

– Change your application logic, adding 1, to reflect the values that DB2 DAYOFWEEK will return.

– Create a simple DB2 user-defined function and use it as you have been using the IDS weekday function. We recommend this if you use weekday extensively. See Example 6-1.

Example 6-1 Weekday user-defined function

CREATE FUNCTION weekday (d DATE)RETURNS INTLANGUAGE SQLCONTAINS SQLBEGIN ATOMICRETURN dayofweek(d)-1;

END@

4. TO_DATE and TO_CHAR

Both IDS and DB2 provide TO_DATE and TO_CHAR functions for converting character strings and date data types. The TO_CHAR function converts a date value into a character string representation, and the TO_DATE function converts a character string representation of a date into a date value.

Tip: Both IDS and DB2 count the days of week starting on Sunday. IDS counts Sunday as 0, while DB2 counts Sunday as 1.

Note: In DB2, user-defined functions written in SQL are optimized along with the instigating SQL. As such, they are not invoked through the normal UDF function call interface. As a result, they are very efficient.


Both functions in both databases use a format_string parameter as a template for performing the conversion. There is no commonality between the two format strings, however.

IDS accepts format parameters preceded by % (percent sign) that are position dependent:

SELECT TO_CHAR(begin_date, '%A %B %d, %Y %R') FROM tab1

DB2 accepts format strings as:

INSERT INTO in_tray (received) VALUES(TO_DATE(‘1999-12-31 23:59:59’,’YYYY-MM-DD HH24:MI:SS’));

Refer to IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, for more information regarding the TO_DATE and TO_CHAR format parameters. Note that to ease transition efforts, DB2 user-defined functions can be used in place of the built-in TO_DATE and TO_CHAR.

6.9 SQL access to system catalogsBoth IDS and DB2 allow SQL access to the system catalog.

Aside from structural differences in the catalogs themselves, it should be noted that DB2 stores information differently in the catalogs than IDS. DB2 folds the names of objects stored in the catalog to uppercase; IDS does not. It is important to remember this when SELECTing rows from the catalog with a WHERE clause. As always, SQL wording itself is case insensitive; data, however, is case sensitive.

In IDS, if you create a table called tab1 with CREATE TABLE tab1, it is stored in the system catalogs as tab1. If you wanted to query the catalog for tab1, you would say WHERE name=”tab1”.

In DB2, even if you create tab1 with CREATE TABLE tab1, tab1 is stored in the catalog as TAB1 (note the uppercase). To query the catalog for information about this table, you would now need to say WHERE name=’TAB1’ (note the uppercase and the single quotation marks)


6.10 Quotation marks and character stringsIDS supports the use of both single and double quotation marks around character strings:

SELECT * FROM state WHERE name = “Texas”SELECT * FROM books WHERE author = ‘Carlton Doe’SELECT * FROM games WHERE name = “Fishin’ Fever”

DB2 supports only single quotation marks. Care must be taken for cases where the character strings themselves contain single quotation marks. For these, you must use double, single quotation marks.

SELECT * FROM state WHERE name = ‘Texas’SELECT * FROM books WHERE author = ‘Carlton Doe’SELECT * FROM games WHERE name = ‘Fishin’’ Fever’

6.11 Concatenation behaviorBoth IDS and DB2 support CONCAT and || (two vertical bars) as synonyms for the concatenation operator. Be aware of the result data type and length differences between IDS and DB2. For DB2, refer to IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845. In this reference, there is an extensive table showing the result data type and length for the various combinations of operands. For example, concatenating a CHAR(m) and a CHAR(n) produces a VARCHAR(m+n) in DB2 if (m+n) > 254, while IDS produces a CHAR(m+n) for (m+n) up to 2000.

Another difference in CONCAT behavior occurs when nulls are involved. In DB2, if either operand is null, the result is null. In IDS, a null is treated as a zero-length string, so it does not cause a concatenation of a null to produce null result. If your application implements string concatenation, you should investigate the possibility of null occurrences and their potential impact on concatenation output. You might want to investigate using the COALESCE or VALUE function to override null values. The following examples show this:

CREATE TABLE t(c1 VARCHAR(5));INSERT INTO t VALUES ('zyx');INSERT INTO t VALUES (null);SELECT 'abc' || 'def' || c1 FROM t;

In IDS, the result of the above SELECT is:

abcdefzyxabcdef


In DB2, the result is:

abcdefzyx(null result)

To have the DB2 result match the IDS results, change the SELECT to either of the functions shown in Example 6-2 (which change nulls to empty strings).

Example 6-2 DB2 COALESCE and VALUE functions

SELECT 'abc' || 'def' || COALESCE(c1,'') FROM t;SELECT 'abc' || 'def' || VALUE(c1,'') FROM t;

In the output of SELECT statements in both IDS and DB2, by default, the null values of a column appear last when that column is ordered in ascending sequence, and first when ordered in descending sequence. The IDS SELECT statement allows nulls first or nulls last to be specified as a way to override the default. DB2 does not provide this syntax, but a way to obtain a similar result is to use COALESCE() to convert null to the empty string, which is at the opposite end of the collating sequence from null. See Example 6-3.

Example 6-3 Using COALESCE to control null sort order in DB2

(a) SELECT lname FROM t ORDER BY lname ASC; -- nulls last(b) SELECT COALESCE(lname,’’) FROM t ORDER BY 1 ASC; -- nulls first(c) SELECT COALESCE(lname,’’) as lname FROM t ORDER BY lname ASC; -- nulls first

(d) SELECT lname from t ORDER BY lname DESC; -- nulls first(e) SELECT COALESCE(lname,’’) FROM t ORDER BY 1 DESC;-- nulls last(f) SELECT COALESCE(lname,’’) AS lname FROM t ORDER BY lname DESC; -- nulls last

With the approach shown in Example 6-3, you have to be careful, because the application actually sees empty strings returned, not nulls. If that must be avoided, you can keep the original column in the SELECT list and order on the coalesced form of it, as in this altered version of the Example 6-3 query (f) shown in Example 6-4.

Example 6-4 Altered version of Example 6-3

(g) SELECT lname, COALESCE(lname,’’) AS lname_no_nulls FROM t ORDER BY lname_no_nulls DESC; -- nulls last


6.12 Implicit castingIDS supports implicit casting where possible. For example, you can concatenate a string with a number, because IDS implicitly casts the number into a character string prior to the concatenation:

SELECT cust_num || lastname FROM customer

Other types of implicit casting takes place in IDS, such as casting dates to integers for performing arithmetic on DATEs and string manipulations on numbers.

DB2 does not support implicit casting between data types, but requires explicit casting. The following example is of an implicit cast in IDS and an explicit cast in DB2. The results of these SELECT statements would be the string “123”.

CREATE TABLE t (c1 INTEGER);INSERT INTO t VALUES (12345);� IDS:

SELECT SUBSTR(c1,1,3) FROM t;� DB2:

SELECT INTEGER(SUBSTR(CHAR(c1),1,1)) FROM t;

6.13 Deferred constraint checkingIn IDS, referential integrity checking can be deferred to the end of a transaction with the SET CONSTRAINTS DEFERRED statement. With constraints deferred, during the course of a transaction, IDS allows that constraints not be satisfied. However, constraints are checked and enforced at the end of the transaction.

DB2 does not support transactional deferred constraint checking or the creation of violations tables used with constraint checking. You can temporarily suspend and reactivate constraint checking for a table with the SET INTEGRITY statement. Doing so turns off constraint checking for the entire table, not just for rows affected by a particular transaction, and puts the table in a limited access check pending state.

Note: DB2 will perform implicit promotion of data types of the same type. For example, when joining a SMALLINT to a BIGINT, DB2 would implicitly promote the SMALLINT to a BIGINT before the join.


6.14 Set operators: UNION, INTERSECT, and MINUSSet operators can be used to combine result sets in both IDS and DB2. The differences between the products are:

� DB2 supports the ALL option on each operator, allowing duplicates to be preserved. IDS allows ALL only on UNION.

� MINUS is not supported by DB2. The DB2 equivalent is EXCEPT (without the ALL option).

6.15 Multi-database accessBoth IDS and DB2 support access to tables from individual databases within a single instance from a single SQL statement such as a joined SELECT. This is a built-in capability of both IDS and DB2.

6.16 LOAD and UNLOAD statementsThe IDS dbaccess supports two loading statements, LOAD and UNLOAD. These statements are not officially classified as SQL statements, but are, in fact, loading utilities. The LOAD and UNLOAD statements are not supported in other Informix tools besides dbaccess.

The situation is similar in DB2. The DB2 CLP (analogous to dbaccess) also supports invocation of the LOAD utility. There is not, however, a corresponding UNLOAD utility in DB2.

Dbaccess scripts frequently use the LOAD and UNLOAD statements. When transitioning to DB2, these statements must be replaced by the CLP using the LOAD statement, with other DB2 utilities, IMPORT and EXPORT, or with both.

Tip: When using DB2, you must configure the database to use the built-in multi-database access feature. It is not automatically available.

Tip: Both IDS and DB2 offer a selection of data movement utilities, each of which have their own particular behaviors and options. It is beyond the scope of this book to discuss all the details. We highly recommend that you consult the IBM DB2 UDB Data Movement Utilities Guide and Reference, SC09-4830, before choosing DB2 loading and unloading mechanisms.


6.17 Temporary tablesIn IDS, there are two types of temporary tables, implicit and explicit.

ImplicitIDS customers often use temporary tables for complex SQL processing. Data is selected and placed in what is called an implicit temporary table. This data is then later selected out of the implicit temporary table and manipulated further. SELECTing information in two steps can yield results more complex than is possible in one step. The temporary tables are known as implicit, because there is no explicit table creation statement and the structure of the temp table is implied by what is SELECTed into it. See Example 6-5.

Example 6-5 IDS implicit temp table

SELECT * from orders WHERE order_num < 525648 INTO TEMP y WITH NO LOGSELECT * FROM y GROUP BY 2 ORDER BY 1

DB2 does not support such implicit temporary tables. However, DB2 allows SELECTs from table expressions, which might negate the need for an implicit temp table. Table expressions are SELECT results that look like tables. You can SELECT from table expressions instead of from tables. Table expressions can be several levels deep and complex. Each can have their own column lists, joins to other tables, and GROUP BY clauses. See Example 6-6 and Example 6-7.

Example 6-6 DB2 SELECT with table expression

SELECT * FROM (SELECT * FROM orders WHERE order_num < 525648) as y

Example 6-7 DB2 SELECT with table expression

WITHpaylevel AS

(SELECTempno, YEAR(hiredate) AS hireyear,edlevel, salary+bonus+comm AS TOTAL_PAYFROM employeeWHERE edlevel > 16 ),

paybyed (educ_level, year_of_hire, avg_total_pay) AS(SELECT edlevel, hireyear, AVG(total_pay)FROM paylevelGROUP BY edlevel, hireyear,)


SELECT empno, EDLEVEL, year_of_hire, TOTAL_PAY, avg_total_payFROM paylevel, PAYBYEDWHERE edlevel=educ_levelAND hireyear, = year_of_hireAND total_pay < avg_total_pay;

ExplicitDB2 does support the explicit creation of temporary tables.

When defining an explicit temporary table, if you want the temporary table to look like a permanent table, you can use LIKE wording:

CREATE TEMP TABLE y LIKE ordersINSERT INTO y SELECT * from orders WHERE order_num < 525648

If you are selecting a subset of columns or mixture of table columns into a temporary table, you can use the DEFINITION ONLY clause to avoid having to specify exact data types. See Example 6-8.

Also, in DB2, when a transaction commits, all rows are deleted from any temporary tables created during that transaction. This is not the behavior of IDS. This might or might not affect your application. If you need to override the default behavior, use the ON COMMIT PRESERVE ROWs wording. See Example 6-8.

Example 6-8 DB2 explicit temporary table

DECLARE GLOBAL TEMPORARY TABLE marys.temptab1 AS(SELECT c1, c2, c3, c4 FROM tab1)DEFINITION ONLYON COMMIT PRESERVE ROWSNOT LOGGEDIN usertempsp1;

In IDS, if temporary tables are placed in a temp dbspace, they are automatically not logged. You can, however, place temporary tables in any dbspace. Temporary tables placed in regular dbspaces can be logged.

In DB2, you can have system temp space and user temp space. Temporary tables must be placed in user temp space, not system temp space, and you must use the NOT LOGGED wording to prevent logging against the temporary table.

Unlike IDS, DB2 does not place entries in the system catalog tables for temporary tables. This is unlikely to affect most applications.


6.18 Compound SQLBoth IDS and DB2 support compound SQL. SQL is compound when two or more SQL statements are bundled together and sent to the database instance as a unit.

IDS supports compound SQL in a prepared statement simply by placing semicolons between statements. IDS does guarantee that the statements will complete in the order specified. As such, longer running statements might finish last in the compound group regardless of placement within the group. Most likely this is not significant to the application.

IDS compound SQL statements are atomic, meaning that they execute as a unit. If one statement in the compound group fails, the whole group fails. It does not act as a formal independent transaction, but is still governed by the application’s transaction.

DB2 also supports compound SQL, but with a more verbose syntax. See Example 6-9.

Example 6-9 DB2 compound SQL

EXEC SQLBEGIN COMPOUND ATOMIC STATIC

INSERT INTO org (dept, deptname, location) VALUES (:dn,:dname,:dloc);UPDATE employee SET dept =:dn WHERE empnum > :empnum;

END COMPOUND;

DB2 supports atomic compound SQL and also not atomic compound SQL. Not atomic means that the compound SQL does not act as a unit. The changes made by successful statements within the compound SQL statement remain effective even if some individual statements are not successful. As in Example 6-9, you must specify ATOMIC or NOT ATOMIC.

6.19 INSERT cursorsIDS uses a concept of INSERT cursors to process batch INSERTs into a table. DB2 supports batch INSERTs, but does not support the IDS INSERT cursor method using PUT and FLUSH.

In DB2, you accomplish batch inserts by simply specifying multiple values lists in the INSERT statement, as shown in Example 6-10 on page 206.


Example 6-10 DB2 batch INSERT

INSERT INTO customer (fname, lname) VALUES (‘Uwe’, ‘Weber’), (‘Mark’,’Scranton’), (‘P.’,’Frampton’),(‘Mutt’, ‘Bonkey’);

6.20 Isolation levelsLocking isolation level affects the behavior of SQL statements. In IDS, default isolation behavior is dependent on the database type. Table 6-3 shows the IDS database types and the default isolation levels.

Table 6-3 IDS database types and default isolation levels

DB2 does not use database types. All DB2 databases are of the same type with a default isolation of cursor stability (CS). Both IDS and DB2 enable you to override the default isolation level.

Unless your application explicitly directs the isolation level, a transition to DB2 will cause a natural change in locking behavior. If you have an IDS non-log mode ANSI database, your default isolation level will, go from committed read to cursor stability (a more restrictive isolation level). If you have an IDS unlogged database, your default isolation level will go from dirty read to cursor stability (a very significant change). Depending on your application, you might find an increase in overall database locking requirements; therefore, you might need to increase lock resources.

Both IDS and DB2 support a SET ISOLATION LEVEL statement. IDS uses a “TO” wording, while DB2 supports usage of the equal sign (=).

The DB2 equivalent of the IDS dirty read isolation level is called uncommitted read. Many IDS applications set isolation to dirty read. For compatibility reasons, DB2 now supports dirty read wording as a substitute for uncommitted read.

� For IDS:

SET ISOLATION TO DIRTY READ

Database type Default isolation level

Unlogged DIRTY READ

Logged, non-mode ANSI COMMITTED READ

Log mode ANSI REPEATABLE READ


� For DB2:

SET ISOLATION = DIRTY READ SET ISOLATION = UNCOMMITTED READ

6.21 Optimizer directivesIDS supports optimizer directives, sometimes known as “hints,” in SELECT statements. Often, these hints are directives to the optimizer regarding what not to do, rather than telling the optimizer what to do. DB2 does not support such directives within individual SQL statements.

If you have used double dash (--) or C style (/**/) notation to specify IDS optimizer directives, these directives will simply be ignored by DB2, because they appear to DB2 as comments. See 6.4, “Comments” on page 193. Curly braces ({ }), however, are not supported as DB2 comments. If you have optimizer directives specified within curly brace ({ }) comments, they must be removed. For more information regarding optimizer directives, see 9.3.2, “Optimizer directives” on page 319.

Both IDS and DB2, however, support a programmatic SET OPTIMIZATION statement to influence decisions made by the optimizer. IDS supports HIGH and LOW wording, while DB2 requires that the optimization be set to one of many possible numerical values. Also, DB2 requires the usage of the CURRENT keyword and the equal sign (=).

� For IDS:

SET OPTIMIZATION LOW

� For DB2:

SET CURRENT OPTIMZATION = 3

Tip: DB2 also supports specifying the isolation level of a particular SQL statement by using a WITH UU | RR | CS | RS clause at the end of the SELECT statement.

Note: DB2 only allows programmatic override of isolation on dynamic SQL statements. Static SQL statements contained in packages will use the isolation set at package creation/bind time. Static SQL isolation cannot be changed at runtime.


6.22 Creating and altering tablesCreating and altering tables in IDS is very similar to creating and altering tables in DB2. There are some exceptions, such as:

� Column data types cannot be changed after creation, except increasing length of varchar.

� You cannot explicitly fragment tables using expressions or in a round-robin fashion.

� You cannot drop a column.

� You specify a table space name rather than a dbspace name.

� You can associate tables with particular buffer pools.

� You must precede the constraint definition with the constraint name. See 6.25, “Constraint naming” on page 209.

� You cannot alter a table to add a NOT NULL constraint.

In DB2, you should plan table layout carefully. DB2 has restrictions about the objects that can be altered, added, or dropped after table creation. See IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, for the complete syntax of ALTER TABLE. For example, you cannot ATLER a table to add a NOT NULL constraint after a table is created.

6.23 SynonymsDB2 supports synonyms; however, they are called aliases. For compatibility reasons, DB2 supports the usage of the keyword SYNONYM in the CREATE statement.

In IDS log mode ANSI databases and in DB2, all aliases are private and must be accessed using the alias owner syntax:

� For IDS:

SELECT * FROM synonym_name

Note: DB2 only allows programmatic override of optimization on dynamic SQL statements. Static SQL statements contained in packages will use the optimization set at package creation/bind time. Static SQL optimization cannot be changed at runtime.


� For DB2:

SELECT * FROM mary.alias_name

Because they are private, privileges must be granted for others to use DB2 aliases. DB2 does not support public aliases. Therefore, public/private toggle is not required or supported.

In IDS logged, non-mode ANSI databases and unlogged databases, synonyms are public by default, but can be made private using the PRIVATE keyword in the CREATE SYNONYM statement. If you are using this feature, the PRIVATE syntax is no longer required and should be removed. Synonyms are private by default in DB2, thus this verbiage is not required or supported.

Also, a DB2 alias can only refer to local database objects. DB2 uses nicknames (which are very similar to aliases) to refer to remote objects. Creating nicknames is part of the federated database feature, which is a built-in capability of DB2.

6.24 Primary key definitionsNeither IDS and DB2 allow any part of a primary key to contain a null value. IDS, in fact, implicitly assumes the NOT NULL constraint on primary keys and does not require an explicit definition. For clarity, DB2 does not make this assumption and thus requires the explicit definition of a NOT NULL constraint.

� For IDS:

CREATE TABLE manufact (manu_code CHAR(3) PRIMARY KEY)

� For DB2:

CREATE TABLE manufact (manu_code CHAR(3) PRIMARY KEY NOT NULL)

6.25 Constraint namingThere is a minor difference in the syntax for naming referential integrity constraints. IDS requires custom constraint names after the constraint type, while DB2 requires custom constraint names before the constraint type:

� For IDS:

CREATE TABLE t (c2 SMALLINT NOT NULL, c3 CHAR(40) NOT NULL,PRIMARY KEY (c2) CONSTRAINT pk_col2);

Tip: When using DB2, you must configure the database to use the built-in federated feature. It is not automatically available.


� For DB2:

CREATE TABLE t (c2 SMALLINT NOT NULL,c3 CHAR(40), CONSTRAINT pk_col2 PRIMARY KEY (c2));

6.26 TriggersTriggers are used to start an action if a certain event occurs. Events that can be caught by a trigger are INSERT, UPDATE and DELETE statements processed on a table or view.

The assembly of a DB2 trigger is similar to an IDS trigger. A DB2 trigger has a unique name, a definition of what event on a table or view it should be executed, correlation names for a row (NEW and OLD), and finally the action that has to be performed if the trigger has been fired. Figure 6-1 shows you the complete CREATE TRIGGER syntax.

Figure 6-1 DB2 CREATE TRIGGER statement

SELECT triggersIDS supports SELECT triggers. With this feature, a DBA can specify actions that are to occur when SELECTs on particular tables are executed. This feature is often used to call stored procedures or INSERT a row into a audit table.

DB2 does not support SELECT triggers. You will want to consider moving SELECT trigger actions into the instigating applications themselves. For

CREATE TRIGGER trigger-name NO CASCADE BEFORE

INSTEAD OFAFTER

INSERT

column-nameOF,

UPDATEDELETE

ON table-nameview-name

ASOLD correlation-name

ASNEW correlation-name

ASOLD_TABLE correlation-name

ASNEW_TABLE correlation-name

REFERENCING DEFAULTS NULL

FOR EACH ROWFOR EACH STATEMENT

MODE DB2SQL( search condition )WHEN

SQL procedure statement


example, if a stored procedure is called on a SELECT in your application, add an EXECUTE stored procedure statement to your application after the SELECT. If a row is INSERTed into a row for audit purposes, add the same INSERT statement to the application after the INSERT.

With DB2, you can achieve some level of query auditing for warehousing-type applications with the DB2 Query Patroller product, which is very similar to Informix I-Spy. Neither of these auditing tools are recommended for ongoing use with high volume OLTP applications, however.

In certain situations, you might consider using a DB2 table function to achieve behavior similar to SELECT triggers. Using table functions, however, requires a change in the instigating SELECT wording and, therefore, might not be practical. DB2 table functions are a special type of function that return data in table format and replace the table name in a SELECT.

Consider the situation where it is required to log access to an employee table for auditing purposes. You would want to trigger an INSERT into an audit table every time the table is accessed. In IDS, the trigger definition and instigating SELECT might look similar to this:

CREATE TRIGGER emptrig1 ON SELECT FROM emp INSERT into audittab(current, “emp”, USER, “select”);SELECT * FROM emp WHERE empid = “5631”;

To achieve this with DB2, the following table function would replace the trigger and the instigating SELECT would change:

CREATE FUNCTION emp (a_empid INTEGER) RETURNS TABLE(empid INTEGER, name VARCHAR(20), salary DEC(10,2)) MODIFIES SQL DATA RETURN SELECT empid, name, salary FROM NEW TABLE(

INSERT INTO audit(tstamp, tabname, user, data) INCLUDE(empid INTEGER, name VARCHAR(20), salary DEC(10,2))SELECT CURRENT TIMESTAMP, ‘EMP’, USER, ‘EMPID: ‘|| CHAR(empid), Empid, name, salaryFROM emp WHERE empid = a_empid) AS I

SELECT emp.* FROM TABLE(emp(5631)) AS emp

BEFORE statement triggersIDS allows the definition of triggers that occur:

� Once AFTER the entire group of rows, that is, the after statement

� Once AFTER each row

� Once BEFORE each row

� Once BEFORE the entire group of rows, that is, the before statement


DB2 allows the definition of triggers that occur:

� Once AFTER the entire group of rows, that is, the after statement

� Once AFTER each row

� Once BEFORE each row

DB2 does not support a before statement triggers. However, in cases were only a single row is processed, a before statement trigger is actually analogous to a before row trigger. If your database has defined before statement triggers, but your application only operates upon single rows, you might be able to change the before statement triggers to before row triggers. Before row triggers are supported in DB2.

Disabling triggersDB2 does not support the disabling and enabling of triggers. To emulate such behavior, triggers must be dropped and recreated.

6.27 DDL usageIDS uses certain utilities to perform some database administration activities. These utilities are not SQL interfaces, but are command line utilities. For example, in IDS, you use the onspaces command to create a dbspace.

DB2, as a general rule, relies more on the SQL DDL interface to perform administrative functions. For example, in DB2, a table space is created with a CREATE TABLESPACE command in the SQL CLP.


Chapter 7. DB2 Migration Toolkit for Informix

In this chapter, we introduce you to the DB2 Migration Toolkit for Informix. When referring to it throughout this book, we use the abbreviation MTK.

We describe the MTK and its particular functions and features. This is a technical overview and includes information about implementation and deployment to help as you prepare to transition from IDS to DB2 UDB.

Database migrations vary in size and complexity due to the countless number of database designs that have been implemented and used. As a result, each database migration has a unique set of issues and challenges. However, there are technical elements that are common to all database applications, and it is this quality that advocates the development and use of migration tools to facilitate the migration process. The DB2 Migration Toolkit for Informix, better known as the MTK, was designed by IBM to do just that. Although the MTK cannot automatically resolve all of the possible migration issues, it can simplify and manage many of the conversion tasks and guide you in the right direction.

7


7.1 The MTK for Informix The MTK was developed as a joint venture by the IBM Silicon Valley Lab in California and the IBM Watson Research Laboratory in Hawthorne, New York. The MTK can also be used to migrate from Oracle, Sybase, and SQL Server databases, as well as from IDS.

This product is free of charge and can be downloaded from the IBM Web site. In this chapter, we discuss MTK Version 1.3 for IDS only. The chapter includes information about the following topics:

� MTK features and functionality

� A technical overview of the MTK

� How to install and execute the MTK

� Using MTK with manual deployment to DB2

7.1.1 Features and functionalityThe MTK can be used to migrate database objects, SQL, and data from an IDS source database to a DB2 UDB target database. It supports the following source databases:

� Informix Dynamic Server (IDS) Version 7.3� Informix Dynamic Server (IDS) Version 9.x� Extended Parallel Server (XPS) Version 8.4 (for those constructs that are a

subset of IDS)

On the target side, MTK supports the following databases:

� DB2 UDB Version 7.2 EE/EEE with Fix Pack 6 or later� DB2 UDB Versions 8.1 and 8.2 for Linux, UNIX, and Microsoft Windows� DB2 UDB for IBM Eserver iSeries Versions 5.2 and 5.3.

As an overview, the following lists outline the important features and functionality of the MTK.

Translation of objects and SQL:

� Tables

– Maps data types except for collections and other complex data types

– Includes primary and foreign keys, unique, check and null constraints

– With some limitations on SQL used in check constraints

Note: IDS releases prior to Version 7.3 are only partially supported.


– Includes schema names

� Views

With some limitations

� Indexes

Regular only

� SPL routines (functions and procedures)

Translated to SQL PL with some limitations

� Triggers


� Synonyms

� Sequences

� SQL statements


� Built-in functions

With some exceptions (for example, Char_length, range, and dbinfo)

Translation for some of the options used with the following data definition statements for supported objects:

� Create� Alter� Drop

Converts the following transaction control statements:

� Set isolation� Commit� Rollback

Performs these additional migration tasks:

� Extracts object definitions directly from IDS system tables

� Imports object definitions from SQL scripts sourced by external methods (for example, dbschema scripts and manually created scripts)

� Generates data extract scripts

� Generates data load or import scripts

� Generates scripts to move data using named pipes

� Automates the migration of data (including LOBs)

� Automates the deployment of database objects

Chapter 7. DB2 Migration Toolkit for Informix 215

� Generates DB2 source scripts for manual deployment of objects

� Maps a subset of IDS SQLCODEs to DB2 SQLCODEs

� Creates a DB2 database with supporting table spaces (SMS) and buffer pools

� Executes the runstats utility after data migration

� Performs referential integrity checking on migrated data

� Performs dynamic conversions of individual SQL and DDL statements using the interactive SQL Translator feature

� Allows for manual override of selected data types

� Allows for renaming of tables (including columns) and indexes

� Tracks, logs, and reports the status of object translations, data movement, DDL changes, and deployment

With MTK V1.3, the following IDS components are not translated or migrated:

� Temporary tables� ROWID� Table or index fragments (converts to unfragmented tables and indexes)� Dbspaces� Connect statement� SPL global variables� SPL trace or debug statements� Dbinfo � Instead of triggers� SQL statements that access IDS catalog tables� Grants� User IDs� Authorities� Collections or other complex data types� GK indexes� External routines written in C or Java� SQL application code or scripting languages� Dynamic SQL statements� Database administrative commands � UNLOAD FROM and LOAD TO DB access statements� Optimizer directives

7.1.2 Recommendations for useThis section provides some recommendations for using the MTK, relative to installation, configuration, and deployment.

Note: Support of these items might change with future releases of the MTK.


MTK installation and configuration The MTK can be installed on:

� Microsoft Windows (NT 4.0, 2000, XP Professional)� AIX (4.3.3.0 or later)� Linux (tested on Mandrake V8.1 with pdksh installed)� Sun Solaris (5.7)� HP-UX (v11i) platforms.

MTK configurationsThere are several MTK configurations that can be used:

� Option 1: The MTK, the IDS server, and the DB2 server are all installed on the same machine.

This is a configuration often used on Windows when testing the MTK.

� Option 2: The MTK, the IDS server, and the DB2 server are each located on separate machines.

For example, locate the MTK on Windows, and IDS and DB2 on separate UNIX machines.

This configuration is convenient for object conversions, but requires that there is sufficient disk space on Windows for data extract files. In addition, if you want to automate the migration of your data, your data cannot include LOBs. If neither of these is the case, then with this configuration, the MTK data transfer scripts can be used to migrate the data manually.

� Option 3: The MTK is installed on the same machine as the IDS server; DB2 is installed on a separate machine.

Though possible, we do not recommend this for real-life migration projects.

� Option 4: The MTK is installed on the same machine as the DB2 server; IDS is installed on a separate machine.

This is the suggested configuration for a real-life migration project. This configuration supports the MTK automated data movement of LOBs.

All four configurations require that database connectivity is established between the MTK and the IDS server and between the MTK and the DB2 server. For options 2, 3, and 4, network connectivity must also exist between the IDS server machine and the DB2 server machine.

Note: If you are also migrating data and you want to use the MTK GUI to automate the movement of the data, be sure to install the MTK on a system that has sufficient disk space for the data files.


The recommended configuration for a migration project is option 4 (the MTK is installed on the same machine as the DB2 server). The reasons for this are:

� When migrating LOB data using the MTK GUI, the MTK must be installed on the same machine as the DB2 server. LOB data cannot be loaded over the network using client-side load.

� If deploying to a local database, the MTK can create the database for you.

� For option 3, in a real-world migration project, it is unlikely that the MTK will be allowed to be installed on the same machine as the production IDS server.

� There is no real benefit to placing the MTK anywhere other than on the DB2 machine. Although the data extraction phase takes longer than the load phase, this is primarily due to data transformation processing that takes place while building data extract files.

Deployment to DB2 We recommend that during the development and unit testing phase of your project, you let the MTK create your database and deploy your objects to DB2. The MTK will create a database with default parameters and create SMS table spaces and buffer pools to get you started quickly.

For the system testing, performance testing, and cut-over to production phases, we recommend that you build and deploy your database manually with the help of the scripts that are generated by the MTK. This will enable you to tune the physical design of your database to meet the processing needs of your applications.

ISV migrations We do not recommend that you use the MTK to convert independent software vender (ISV) schema definitions:

� Most ISVs supply their own conversion tools, and some require that their tool be used, or the migrated database will not be certified.

� MTK data type mappings might not match the ISVs specifications.

The MTK can be used to prototype the conversion of customizations made to ISV SQL, including procedures and triggers; however, the tables that the procedures and triggers depend on must also be converted in the MTK.

7.2 Technical overview of the MTK In this section, we provide some of the technical details about the MTK. This section will provide a good basis of understanding of the functions and capabilities of the MTK.


7.2.1 The graphical user interfaceThe MTK GUI, depicted in Figure 7-1 on page 220, presents five tabs, each of which represents a specific task in the conversion process. The tabs are organized from left to right and are named:

� Specify Source� Convert� Refine� Generate Data Transfer Scripts� Deploy to DB2

The menu bar contains Application, Project, Tools, and Help:

� Application: Enables you to set up your preferences, such as an editor.

� Project: Enables you to start a new project or open an existing project.

� Tools: From here, you can launch the SQL Translator, reports, and the log.

� Help: The MTK Online Help text describing error messages and how to use the generated data movement scripts to manually migrate the data.

7.2.2 The migration processThe five tabs in the MTK user interface represent the five steps in the migration process.

Now, we describe the five migration steps.

Specify Source stepIf you click the Extract button to specify that the source of the objects for conversion will be an IDS database, a database connection must be established. The easiest way to do this is to use a JDBC connection. The JDBC driver required for this connection is provided with MTK in the ifxjdbc.jar file. The required steps to supply the information that is requested by panel is described in Figure 8-3 on page 247.

An ODBC connection can also be used provided that you are running IDS and MTK on a Windows platform. You can set up an ODBC data source for your IDS database by using Administrative Tools from Control Panel.

You can also click the Import button to specify that the source to your conversion is an external SQL script file containing IDS object definitions or SQL statements.

Note: Refer to Chapter 8, “An MTK tutorial” on page 241 for a step-by-step tutorial about how to use MTK in the migration process.


Figure 7-1 Specify source

Convert and Refine stepsThe next two steps, Convert and Refine, are used together and usually require several passes. During the Convert step, you can convert the database objects, including procedures, functions, and triggers; if you used an SQL script as input to the conversion, you can also convert SQL statements. The files generated by this phase will be used by the MTK to automatically deploy to DB2, or can be manually deployed to DB2 using the DB2 command line processor (CLP).

During the Refine step, you have a chance to review translation information, warnings, and errors for your conversion. You can then make modifications and run Convert again.

How the Translator worksThe converter (also referred to as the Translator) is written in Java and uses Another Tool for Language Recognition (ANTLR) as its parsing engine. The converter is a language translator that operates much like a compiler for a conventional programming language. It takes as input a sequence of IDS SQL scripts and generates a corresponding DB2 SQL script as output. It also


generates metadata information about each IDS object definition and corresponding generated DB2 object definition. The metadata is encoded in the XML-based Metadata Interchange (XMI) format for easy reuse. The metadata information summarizes important properties about source objects and is used by the MTK to generate an overview of source and target objects in the Refine step (where the results of the translation are reported).

An IDS SQL script is a sequence of SQL statements and SPL commands. The SQL statements are translated as they are encountered in the script. Therefore, the order in which IDS objects are defined in the source script is critical for proper conversion. The converter requires that an object is defined before it is used. Queries of an object cannot be translated if the object has not yet been defined. When the source of the object definitions are extracted (using the MTK) directly from the system catalogs, the object definitions are in dependency order. When the source of the object definitions are imported into the MTK from an external file, some manual reordering to satisfy dependencies might be required.

For each DB2 UDB statement generated in a converted script or stored procedure, the converter will normally copy the corresponding IDS statement as a comment preceding the generated target statement. See Example 7-1.

Example 7-1 Converter output

--| create table mytab--| (dte datetime year to day default datetime(2000-01-01) year to day;

CREATE TABLE mytab (dte DATE DEFAULT '2000-01-01-00.00.00.000000')!

This annotation makes it easier to understand how the generated code relates to the source and how to perform manual refinement of the generated code if necessary. If an error occurs during the conversion, the error message will appear after the source code, and any invalid DB2 statement that results from the error will be commented out. If you prefer to not see the commented source in the output file, you can disable it in the MTK.

In some cases, because of identifier length restrictions (for example, indexes, constraints, and triggers), the converter will generate truncated target names for some source objects. The converter generates new names such that they do not conflict with preexisting names; however, the name generation process depends on the order in which object definitions occur in a script. As a result of the renaming process, if the converter is used to convert two scripts separately which that the same object definitions but in different orders, the resulting target scripts might contain inconsistently renamed target objects.


Translating tables, indexes, and viewsThis phase of the translation is the most straightforward. The MTK converts DDL with very little manual intervention required. However, the MTK does not convert dbspaces. You will need to manually develop a script to create your DB2 table spaces. You can then edit your DB2 table DDL to assign table spaces to your tables and indexes and add other DDL changes to optimize performance. You should then deploy the DDL manually to DB2.

In the beginning phase of your conversion, you can use the MTK to automatically deploy your tables and indexes and create the table spaces for you.

Translating built-in functionsThe MTK comes with pre-written DB2 user-defined functions that match the functionality of many IDS built-in functions.

There are three possible scenarios when converting IDS built-in functions to DB2 SQL:

� An IDS built-in function has an equivalent DB2 function. In this case, function calls are mapped directly to DB2 SQL.

� An IDS built-in function does not have an equivalent DB2 function, but a similar DB2 function is available.

� An IDS built-in function has no DB2 equivalent. In most of these cases, a DB2 SQL or Java UDF is provided by the MTK to provide similar functionality.

The user-defined functions (UDFs) that are packaged with the MTK are contained in the INFX schema. They can be found in the MTK installation directory in files named mtkinfx.udf and infxUDFs.jar.

MTK automatically installs the Java and SQL UDFs during the Deploy to DB2 step. The DEPLOY_yourprojectname_UDF.log file contains information about the success or failure of the UDF deployment.

An example of a Java UDF packaged with the MTK is the System function. The System function is used to translate SPL procedures using the SYSTEM command to equivalent functionality in DB2 procedures.

Example 7-2 on page 223 shows the function definition.


Example 7-2 System function

CREATE FUNCTION INFX.system(cmd varchar(2000)) RETURNS INT EXTERNAL NAME 'infx.udfjar:com.ibm.db2.tools.mtk.mtkinfxudf.infxUDFs.os_cmd' LANGUAGE java PARAMETER STYLE JAVA DETERMINISTIC FENCED NOT NULL CALL NO SQL NO EXTERNAL ACTION NO SCRATCHPAD NO FINAL CALL ALLOW PARALLEL NO DBINFO!

Example 7-3 shows the java code.

Example 7-3 Java code

public static int os_cmd(String cmd) {Runtime rt = Runtime.getRuntime();Process p=null;int success = 0;try {

p = rt.exec(cmd);}catch (IOException e) {

success = -1;}return (success);

}

Translating functions and proceduresThe conversion of functions and procedures will generally require more manual intervention than the conversion of tables and indexes. However, the MTK will provide you with a quick start for these conversions.

The MTK translates the IDS Create function and Create procedure to DB2 functions and procedures based on the following rules:

� IDS procedures with no return values are translated to DB2 UDB procedures.

� Functions and procedures with multiple return values are translated as DB2 UDB procedures, with additional OUT parameters for the return values.


� Functions with a single return value are translated to DB2 UDB functions unless they contain any specific feature that will require them to be translated as DB2 UDB procedures. For more information, see the exercises about migrating functions and procedures in “Part II: Database application object migration” on page 275.

IDS functions and procedures (collectively called routines) contain statements of the form RETURN…WITH RESUME, which are called cursor functions, because they return a series of values to the caller. In SPL, these functions must be called from a FOREACH statement. On the application side, a cursor is declared to contain the results of the routine call, and then FETCH is used to retrieve the results. MTK translates cursor functions to DB2 stored procedures that return a result set using cursor processing or a FOR loop.

The MTK does not convert GLOBAL variables found in SPL routines. The easiest way to migrate these to DB2 is to convert global variables to INOUT parameters for all procedures that require them. Another method to convert global variables is to make use of the DB2 declared global temporary tables to share data between procedures within a session.

Generate Data Transfer Scripts stepThe Generate Data Transfer Scripts step involves two tasks:

� Generating scripts that transform IDS data into DB2 format and extract the data to a file

� Generating scripts to read the data from a file and load the data into DB2

The MTK builds SELECT statements with built-in functions to transform IDS data and extract the data into files, as shown in Example 7-4.

Example 7-4 SELECT statement

SELECT customer_num, TO_CHAR(call_dtime,'%Y-%m-%d-%H.%M.00.000000'), user_id, call_code, call_descr, TO_CHAR(res_dtime,'%Y-%m-%d-%H.%M.00.000000'), res_descr from cust_calls;

The MTK uses the DB2 Load or Import utility to load the data into DB2. As previously mentioned, with the MTK, the transformation and extraction phase generally takes more execution time than loading the data into DB2.

Note: For more information about how this is implemented with DB2, see the exercises about migrating functions and procedures in “Part II: Database application object migration” on page 275.


In order to understand the script generation step more fully, some background information about how the MTK migrates data is helpful. There are two ways that data can be deployed to DB2 with MTK:

� Automatic transfer using the Deploy to DB2 tab from the MTK GUI

� Manual transfer (no MTK GUI involved) by installing and executing scripts that were generated by the MTK

The scripts can be used for two methods of data transfer:

– A staged approach using intermediate files

– Piping the data using named pipes

If the data migration is performed using the Deploy to DB2 step from the GUI, data will be migrated automatically by the MTK. For this to occur, there must be sufficient disk space available on the machine where the MTK is installed. The data can be loaded into a local DB2 database or to a remote DB2 database provided there is a client connection to the remote DB2 server.

If data is to be migrated to a remote DB2, and there is not enough disk space on the MTK machine, or if the data includes LOBs, the data transfer scripts can be used to migrate the data. To migrate the data manually using MTK-generated scripts:

� The source IDS machine must be accessible through the network to the DB2 machine.

� The data transfer scripts generated by the MTK must be installed as directed in the Help accessed from the MTK menu bar.

Deploy to DB2 stepIn this step, you use the MTK GUI to automatically:

1. Create your objects on DB2

2. Extract your data from IDS

3. Load your data to DB2

You can use the MTK GUI to deploy to either a local or remote DB2 UDB database. However, as previously mentioned, the following restrictions apply:

� The MTK cannot automate the creation of a remote DB2 database.

� There must be sufficient disk space on the MTK machine for migrating data.

� LOB data can only be loaded into a local DB2.

Note: We do not recommend that you extract IDS data on one system and transport the data files over the network to the DB2 system for loading.


Here are some additional things to know about the Deploy to DB2 step:

� A DB2 UDB database name has a limit of eight characters.

� During deployment, the connection to DB2 uses a Java native driver, and your DB2 server must be configured properly for Java 1.3.1.

� Before you can deploy to a remote DB2, you must also establish DB2 client connectivity with the server using the DB2 Catalog Database and Catalog Node commands.

� The user-defined functions packaged with MTK are automatically created on the DB2 database.

� To deploy objects and data to a previously created database, the user ID must have DBADM authority.

� If you are deploying procedures to DB2 UDB V8.1 or earlier releases, you must have a C compiler installed on the same machine as DB2.

� If you are using the MTK GUI to deploy the data, the data is unloaded into a directory that is local to where the MTK is installed.

� Before you can deploy using the MTK, you must first generate the scripts from the Generate Data Transfer Scripts step.

� When a database is created by the MTK, a buffer pool and three table spaces are created with a page size of 32 KB. This is to provide enough space for the deployment of tables with any row length. However, a 32 KB page size might not be optimal for tables with a smaller row length. Therefore, before deploying your database into production, adjust the table space sizes accordingly. For each (table space) page size used, there must be at least one buffer pool with the same page size created.

� The default collating behavior between DB2 UDB and IDS is different. There is an option on the Deploy tab that enables you to select a collating sequence for the DB2 database. The default collating sequence for DB2 is SYSTEM. After SQL and data are deployed to DB2, run tests to determine whether to modify DB2 UDB to use the IDENTITY collating sequence.

� If data is loaded, the integrity of the data is checked and the runstats utility is executed.

� Two files are produced at the end of the deployment process:

– The DB2 deployment log: Output generated by DB2 for each statement or command executed.

Note: With DB2, an entire row must fit on a single page, and no row chaining is allowed. This is unlike IDS where a row can be longer than the page size used.


– The Verification Report: The results of the deployment in report format.

� After deployment completes, you can go back to the Generate Data Transfer Scripts tab and view the SELECT statements that were used to extract the data from IDS tables and view the data.

To see a view of the data extraction information, refer to Figure 7-2.

Figure 7-2 View of data extraction information

To see a sample of the extracted data, refer to Figure 7-3 on page 228.


Figure 7-3 Sample of extracted data

Connecting to a remote DB2 UDB databaseIf you are using the MTK to deploy to a remote DB2 UDB database, you must first establish connectivity to access the remote database. This is done on the client machine where the MTK is installed. Before doing this, first Telnet to the remote database server and run:

db2 list database directory

This lists the local databases on that server. Verify that the database you need to access has been created.

Next, on your local DB2 machine, issue two commands:

db2 catalog tcpip node node_alias remote ip_address server service_ namedb2 catalog db dbname as alias_name at node node_alias

Where:

� node_alias can be any eight-character name.� ip_address is the IP address of the remote server.� service_name is the service name for the remote server (port number can

also be used).� alias_name is any eight-character name that refers to the remote DB2

database.


To test your connection to the remote DB2, enter the following from your local machine:

db2 connect to alias_name user userid using password

Where:

� alias_name is the database you have just cataloged.� userid and password are a user ID and password that have been created at

the remote server.

Loading data to a remote DB2 You might also find that before using the MTK to perform a client-side Load to the remote DB2, you will have to bind a file to add an additional package on the remote DB2. This can be done as follows:

1. From your local DB2 system, connect to the remote DB2:

db2 connect to alias_name user userid using password

2. Bind the file named db2ucktb.bnd found on your local DB2 system:

db2 bind db2ucktb.bnd blocking all grant public

Configuring a C++ compiler for a DB2 UDB version earlier than 8.2If you are using DB2 V8.2, a C++ compiler is not required for deploying SQL stored procedures. If you are using a DB2 version prior to V8.2, a C++ compiler is required:

� Windows: After you have installed Microsoft Visual C++, you need to point DB2 to the directory where the compiler has been installed. You can do it by issuing the following command:

db2set DB2_SQLROUTINE_COMPILER_PATH="installation path for compiler".

Use the following command to verify that the DB2 registry variable has been set:

db2set -all

� AIX: If you have installed the IBM VisualAge® C++ 5.0 compiler, the DB2 registry variables have been preconfigured to use the compiler.

If you are using the IBM C for AIX 5L Version 5.0 compiler, enter the following as one command to set the DB2 registry variable:

db2set DB2_SUBROUTINE_COMPILE_COMMAND=xlc_r -I$HOME/sqllib/include SQLROUTINE_FILENAME.c -bE:SQLROUTINE_FILENAME.exp -e SQLROUTINE_ENTRY -o SQLROUTINE_FILENAME -L$HOME/sqllib/lib -ldb2


7.3 How to install and execute the MTKThe MTK can be downloaded from the IBM Web site, available at:

http://www.ibm.com/software/data/db2/migration/mtk/

Hardware requirementsThe hardware requirements for installing and executing the MTK for Informix are:

� Disk space:

– 50 MB for installation– 5 MB per project– Additional space varies by the number of source script files and data

� Memory:

– 512 MB (minimum)– Processor speed for Windows platforms: 300 MHz

Software requirementsThe requirements by platform are:

� Microsoft Windows platforms:

To deploy SQL stored procedures prior to DB2 UDB V8.2, Microsoft Visual C++ Version 5 or later must be installed.

� UNIX platforms:

To deploy SQL stored procedures prior to DB2 UDB V8.2, a C++ compiler must be installed. The GNU compiler can be used.

Java 1.3.1 must be installed and added to the system $PATH environmental variable in .profile. For example on AIX, perform the following:

export PATH=/usr/java131/bin:/usr/java131/jre/bin:$PATH

If Java 1.3.1 is not installed on your machine, you can download it from:

http://www6.software.ibm.com/dl/lxdk/lxdk-p

Installation procedureThe requirements by platform include:

� On Windows platforms:

a. Unzip and extract the package. Run setup.exe. The installation will default to the C:\MTK directory.

b. Run the installation shield wizard and follow its instructions. Then, to launch the MTK, select Start → Programs → IBM DB2 Migration toolkit → toolkit.


http://www.ibm.com/software/data/db2/migration/mtk/

http://www6.software.ibm.com/dl/lxdk/lxdk-p

� On UNIX platforms:

a. Log in with the user ID you will use to install the MTK. Do not install as root. Install MTK using a user ID in the db2admin group (SYSADM authority).

b. Verify that the DB2 $INSTHOME environment variable is set up to point to your DB2 instance directory and that it is properly exported when you start. For example, in the Korn shell, enter:

Export INSTHOME=/home/db2inst2Echo $INSTHOME

c. Download or copy the MTK into a newly created directory, and expand the package. For example, on AIX, to uncompress db2mtk_version_aix.tar.Z, use the following command:

tar -xvf db2mtk_version_aix.tar

d. Launch the MTK from the directory in which it was installed by entering:

./MTKMain

7.3.1 Using the MTK with manual deployment to DB2 UDBIn this section, we describe how you can use the MTK in a manual deployment scenario.

Instance and database creationYou can have DB2 UDB create the DB2 instance automatically while installing DB2 UDB. You also can create the DB2 instance manually after the installation is completed. On AIX, the DB2 instance can be created by executing the db2setup program used to install DB2, or manually through the command line by issuing the db2icrt command, or by using the Control Center provided by DB2.

Using the db2setup and db2isetup utilitiesUsing the db2setup utility provides an easy way to create a DB2 instance. As root, perform the following steps:

1. Launch the db2setup utility.

2. Select the Create a new DB2 instance or Set up an existing DB2 instance option.

Note: For further instructions, refer to the readme file packaged with the MTK installation files or to the Release Notes, which can be found on the Web site.


3. This window enables you to configure the DB2 administration server and user used as a repository for the GUI administration tools provided with DB2, such as the Control Center. The default value for this user is dasusr1 with a default home directory of /home/dasusr1.

4. Select the Instance setup option and the Create DB2 instance - 32 bit option.

For a single partition instance, choose the first option.

5. On the Set User Information for the DB2 Instance Owner window, you need to identify a system user who will be the instance owner. If you choose a new user, specify the name of the user and the password. The default values are user db2inst1 and group db2grp1. You also have to specify the home directory for this user, for example, /home/db2inst1. By default, any databases created under this instance will be created in this directory unless otherwise specified. Both the user and the home directory will be created by the installer.

6. The Set User Information for the Fenced User window enables you to specify the user’s user name and password. The default user is db2fenc1 assigned to group db2fgrp1 in home directory /home/db2fenc1.

7. The Tools Catalog window is for preparing the DB2 tools catalog on the server. Select the Do not prepare the DB2 tools catalog on this computer option if you do not need the tools catalog installed.

8. Finally, set the administrator contact information, and click Finish.

As part of the instance creation, the installer will create all three users identified mainly as db2inst1, db2fenc1, and dasadm1. If you do not want to use the default user IDs, you can create the user IDs and groups ahead of time and use the IDs during creating the instance. The installer will also add the following entry to the /etc/services file in order to allow communication from DB2 clients:

db2c_db2inst1 50000

Where db2c_db2inst1 indicates the service name, and 50000 indicates the port number. Subsequent instances can be created on the same server simply by invoking the /opt/IBM/db2/V8.1/instance/db2isetup utility and going through the steps just described.

Using DB2 commandsWe can also create a DB2 instance manually by performing the following steps:

1. Log in to the AIX system as root.


2. Create the necessary groups for DB2 instance owner, administration server, and fenced ID using the following commands:

groupadd db2grp1groupadd db2fenc1groupadd dasadm1

3. Create the DB2 instance user ID, administration server user ID, and fenced ID and assign them to their respective groups using the following commands:

useradd -g db2grp1 -d /home/db2inst1 db2inst1 -p my_passworduseradd -g db2fenc1 -d /home/db2fenc1 db2fenc1 -p my_passworduseradd -g dasadm1 -d /home/dasusr1 dasusr1 -p my_password

4. Issue the command:

db2icrt -u db2fenc1 db2inst1

5. Edit the /etc/services file and add the following entries:

db2c_db2inst1 50000/tcp #DB2 port for remote clientsdb2idb2inst1 50001/tcp #interrupt ports for DB2 1.x clients

6. Log in as the instance owner and update the database manager configuration (dbm cfg) file to reflect the service name in the /etc/services file with:

update dbm cfg using SVCENAME db2c_db2inst1

7. Set up the default communication protocol:

db2set -i db2inst1 -i DB2COMM=TCPIP

8. Set the instance to auto-start with the system if desired:

db2set - i db2inst1 DB2AUTOSTART=TRUE

At this point, the server is ready to create the database. To do a database connectivity test, you can create a sample database in four easy steps:

1. Log in to the AIX system as the instance owner db2inst2.

2. Execute the command db2sampl located in the sqllib/bin directory under the home directory of the DB2 instance. The db2sampl executable is a script that automatically creates a small database called SAMPLE.

3. Connect to the SAMPLE database by issuing the db2 connect command. In our example, the command becomes:

db2 connect to sample

This should display a the following connection confirmation on the screen:

Database server = DB2/6000 8.2.0SQL authorization ID = DB2INST2Local database alias = SAMPLE

4. To see the results, issue a SQL query such as:

db2 "select * from staff"


A DB2 database can either be created by the Control Center or by using the command line. In order to create a DB2 database manually, perform the following steps:

1. Log in to the AIX system as the instance owner db2inst2.

2. Because DB2 allows for one instance to have multiple databases, we always recommend that you attach to the desired instance before the create database command is issued:

db2 attach to instance_name

Where the instance name in our case is db2inst2.

3. Issue the create database command. The simplest create database command can take the form:

db2 "create database my_database on /db_path"

This command creates a database and the following three table spaces:

– SYSCATSPACE to store system catalog tables– USERSPACE1 to store user-defined objects– TEMPSPACE1 to store temporary objects

These table spaces can be viewed by issuing the command:

db2 list tablespaces

There are many options that can be included in the database command. You can see some of the available options in Example 7-5. Also refer to the IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, for more details about the create database command.

Example 7-5 Create database command

CREATE DATABASE my_db ON /db_path ALIAS warehouse_db USING CODESET code_set TERRITORY US COLLATE USING SYSTEM USER TABLESPACE MANAGED BY SYSTEM USING ('/user_tablespace_path') CATALOG TABLESPACE MANAGED BY SYSTEM USING ('/catalog_tablespace_path') TEMPORARY TABLESPACE MANAGED BY SYSTEM USING ('/temp_tablespace_path')

In Example 7-5, the default value for db_path is the home directory of the instance owner db2inst2 /home/db2inst2.


Table space planningDB2 UDB allows for two types of table spaces, System Managed Space (SMS) and Database Managed Space (DMS). Both types of table spaces have containers or data files associated with them. In this section, we discuss both types of table spaces. For a summary of the differences of both types of table spaces, refer to Table 7-1 on page 236.

There are three categories of table spaces:

� Regular table spaces that can store regular, index, and long data. However, this type of table spaces is not optimized for long type data.

� Large table spaces designed to store long character or LOB type data.

� Temporary table spaces designed to store temporary tables. A user cannot define a table in a temporary table space.

SMS table spaceThis type of table space stores its containers in the form of operating system directories. Because this type of table spaces cannot be resized manually, enlarging the underlying file system would then increase the size of the table space. SMS table spaces acquire more space only when needed.

There are a few advantages of creating SMS table spaces, such as ease of creation and maintenance. The main disadvantage of an SMS table space is that it can only be created as regular or temporary and cannot store long data types.

DMS table spaceThe containers associated with a DMS table space are either operating system files or raw devices. A DMS table space can be resized manually with the ALTER TABLESPACE command using the RESIZE option. The database administrator

Note: If you are manually creating a database to migrate to rather than letting the MTK create it during deployment, ensure that you use the following DB2 commands:

db2 update database manager configuration using keepdari nodb2stop forcedb2start

Run these commands each time you create a new instance. Otherwise, the MTK will run these commands for you.

Note: Only users with SYSADM or SYSCTRL authority can create table spaces.


decides the location of containers belonging to the table space and when to add containers. A DMS table space can be defined as regular, large, or temporary.

Differences between SMS and DMS table spacesTable 7-1 illustrates the differences between the two types of table spaces.

Table 7-1 SMS and DMS table space differences

When planning for table spaces, you should consider the table space size, type, and the placement on the physical drive. Migration time is a good time to redesign the table spaces of your database if you have been considering it. IDS chunks are most similar to the DB2 UDB DMS table space container.

Creating table spacesThe command used to create a table space can be used in the following form:

CREATE Tablespace_data_type TABLESPACE Tablespace_name PAGESIZE Integer K MANAGED BY Tablespace_type USING Container_path

Where:

� Tablespace_data_type indicates if a table space is regular, large, or temporary.

� Tablespace_name indicates the name of the table space.

� Integer indicates the size of a memory page in KB.

� Tablespace_type indicates either SYSTEM or DATABASE for SMS and DMS table spaces, respectively.

� Container_path indicates the path and name of a container.

Table space feature SMS DMS

Can dynamically increase the number of containers in a table space

No Yes

Can store indexes for a table in a separate table space No Yes

Can store long data for a table in a separate table space No Yes

One table can span multiple table spaces No Yes

Space allocated only when needed Yes No

Table space can be placed on different disks Yes Yes

Extent size can be changed after creation No No


The following examples show some DB2 commands to use when working with table spaces. Example 7-6 shows the command to create a regular table space.

Example 7-6 Create a table space command

CREATE REGULAR TABLESPACE EMP_TBSmanaged by database using ('/db2/user_data' 25600);

Example 7-7 shows the syntax used to create a table space used to store long objects in a DB2 database.

Example 7-7 Create a table space of type large

CREATE LARGE TABLESPACE lob_tbsMANAGED BY DATABASE USING (FILE '/db2/lob/user_lobs' 25600);

Example 7-8 shows the syntax used to create a table space used to store the indexes in a DB2 database.

Example 7-8 Create a table space to store indexes

CREATE TABLESPACE ind_tbs MANAGED BY DATABASE USING (FILE'/db2/indx/user_indx' 25600);

In order to obtain information about existing table spaces, the DBA can issue the following command from the CLP:

db2 list tablespaces

If detailed information is required, the following command can be issued:

db2 list tablespaces show detail

Security considerationsDB2 UDB uses existing operating system users as database users. On an environment such as AIX, users are simply added to specific operating system groups and are authenticated at the operating system level.

Note: DB2 supports page sizes of 4, 8, 16, and 32 KB. If you are creating tables with row sizes wider than 4 KB (for tables without LOBs), you must create a table space with a page size large enough to support the width of that table. You must also create a buffer pool using the same page size as your table space if one does not already exist. Buffer pools are created using the CREATE BUFFERPOOL statement.


DB2 provides two levels of security to users. The first is called an authority. It bundles specific privileges over the database in its entirety, such as creating a database, creating a table space, and performing backup and recovery tasks. The second is called a privilege, which allows a user to access, create, or manipulate a specific database object in the database such as a table, view, or index. The instance owner, however, has extra authority at the instance level.

DB2 UDB authoritiesAn authority in DB2 UDB is defined as a group in AIX, and granting a specific user this authority simply means that this user is assigned to this group in the /etc/group file. The levels of authorities in DB2 UDB are classified as follows:

� SYSADM: Administrative authority. System administrators are given full privileges over the entire DB2 instance. SYSADM cannot be granted with an SQL statement.

� SYSCTRL: System control authority. System controllers are given full privileges for managing the system, but are not allowed access to data. SYSCTRL cannot be granted with an SQL statement.

� SYSMAINT: System maintenance authority. System maintainers are given a subset of privileges to manage the system. SYSMAINT cannot be granted with an SQL statement.

� DBADM: Administrative authority. Database administrators have control over an individual database. DBADM can be granted with an SQL statement.

� LOAD: The LOAD authority is granted in the database level. Users with LOAD authority can load data to a table. To load data to a table, the INSERT privilege on the table is also required. Depending on the load activity, the UPDATE and DELETE privilege on the table might also needed.

DB2 UDB privilegesDatabase privileges are granted in the database through the SQL command GRANT. Privileges are stored in the system catalog tables within the database.

There are three types of privileges: ownership, individual, and implicit:

� Ownership or CONTROL privileges: In most cases, the database user who creates a database object is automatically granted the CONTROL privilege. This privilege permits the user to grant other database users certain privileges on this object. The GRANT privilege can be granted through the GRANT statement.

� Individual privileges: A classic example of this type of privilege is the SELECT, INSERT, UPDATE, and DELETE privileges.

� Implicit privilege: This is a sub-privilege that is automatically granted to a user when that user is granted a high-level privilege.


Grant command syntaxThe syntax to use the Grant or Revoke command is as follows:

GRANT privilege ON object_name TO USER usernameREVOKE privilege ON object_name FROM username

Example 7-9 includes examples of granting database privilege and table access authority to a user.

Example 7-9 Granting create table privilege to user smith

GRANT CREATETAB TO USER smith;GRANT INSERT ON emp_table TO USER smith;

Creating DB2 database usersIn DB2 UDB, users are created at the operating system level using operating system commands and utilities.

For example, if we need to create a new database user called db2usr and grant the user select, insert, and update privileges on table accounts in an AIX environment, we need to perform the following steps:

1. Log in to the AIX server as root and create a group:

mkgroup id=995 accttab

2. Create a user and assign that user to group accttab:

mkuser id=1001 pgrp=accttab groups=accttab home=/home/db2user db2user

3. Edit the .profile file for user db2usr and add the db2profile path to it, and then execute the .profile in order to reflect the changes:

. /db2/home/db2inst2/sqllib/db2profile

. ./.profile

4. Log in to the AIX server as the instance owner or any authorized user and connect to the database:

su - db2inst2db2 connect to sample

5. Grant the desired privileges to the group:

db2 "grant select, insert, update on accounts to group accttab"

6. Log in as user db2user, connect to database sample, and issue an SQL statement against table accounts:

su - db2userdb2 connect to sampledb2 "select * from db2inst2.staff"


Chapter 8. An MTK tutorial

We designed this chapter as a tutorial and use coding examples so that you can follow along and walk through the important features of the DB2 Migration Tool Kit for Informix (MTK). Although no tutorial can prepare you for all the issues you might potentially encounter, this one will help you to become more prepared to handle the different classes of conversion issues that might arise during the process.

We present the tutorial in two parts:

� Part 1 illustrates how to migrate a core database that includes:

– Tables (creates and alters)– Indexes– Constraints– Data transfer script creation– Data movement– Deployment to DB2

� Part 2 illustrates how to migrate database application objects that include:

– SPL routines– Triggers– Deployment to DB2

Views are also often part of a core database migration. However, for this tutorial, views are not included.

8


How to use the tutorialThe tutorial is based on the stores_demo database that is delivered with IDS Version 9.4. Because the stores_demo database, as installed, does not contain triggers and SPL routines, to enhance the exercise, we added one new table, one trigger, two functions, and one procedure to the database. A list of the IDS source object definitions is included in Appendix B, “Informix source and object definitions” on page 551. Script files containing the source code can also be downloaded from the Redbooks Web site (see Appendix D, “Additional material” on page 559). These scripts can be used to construct a database identical to the one used in this tutorial. However, it is not a requirement to construct the database to get value from the tutorial. The process can be followed by referring to the figures used with the tutorial.

The tutorial, for the most part, is transparent to the operating system and hardware used. Any portion of the tutorial that is dependent on platform-specific features will be noted as such.

Getting startedBefore beginning, the following software product installations are required:

1. DB2 UDB Version 8.2 (with an instance created)

2. MTK for Informix installed on the same machine as DB2 UDB V8.2 (required for LOB data movement)

3. An IDS V9.x server that is accessible from where the MTK is installed, with an IDS stores_demo database (optional but suggested)

Note: The MTK is continually being enhanced to support additional IDS features. This chapter was written using MTK Version 1.3, which was the most current version available at the time of this writing. Future versions of the MTK will exhibit advanced capabilities and behavior and, therefore, might eliminate some types of manual intervention demonstrated in this chapter.

Note: If you are using a DB2 UDB V8.1 target database, a C compiler needs to be installed on the machine where DB2 SQL PL procedures will be deployed. If you do not have a C compiler installed, you will be able to translate SPL routines, but not deploy them on DB2.

Refer to Chapter 7, “DB2 Migration Toolkit for Informix” on page 213 for specific information about how to download, configure, install, and begin execution of the MTK and how to set up a C compiler for DB2 UDB V8.1.


Part I: Core database migrationIn this part of the chapter, we discuss the migration of the core database. In Part II, we discuss the migration of application objects.

The first time you run the MTK, you will see the following options:

� View a quick product overview� Quickly convert a database using the wizard� Launch the DB2 Migration Toolkit product

To begin, click Launch the DB2 Migration Toolkit product.

8.1 Create a projectThe first panel that opens is the Create new project panel, as shown in Figure 8-1 on page 244.

To create a project, perform the following steps:

1. Create a new project called Tutorial1.

2. On the lower-left side of the panel, select Informix Dynamic Server as the source database.

3. On the lower-right side of the panel, select the DB2 database that you will use as the target for this conversion. Select either:

– DB2 V8.2 for Linux, UNIX, Windows (preferred)– DB2 V8.1 for Linux, UNIX, Windows

Chapter 8. An MTK tutorial 243

Figure 8-1 Create new project panel

8.2 Work with the projectAfter your project is created, you are presented with the MTK user interface, as shown in Figure 8-2 on page 245. You will notice five tabs at the top of the panel:

� Specify Source� Convert� Refine

Note: If at any time during your implementation you would like to see a description for a button or any other item on a panel, you can place your cursor over that item and a message box with a description of that item will appear.


� Generate Data Transfer Scripts� Deploy to DB2

Each tab represents a phase of the migration process, and we discuss each in turn.

8.2.1 Specify Source tabThe Specify Source tab enables you to specify the data source to be migrated. You will notice that there are two buttons:

� Import� Extract

Figure 8-2 Specify Source tab

The MTK can extract database object definitions directly from the IDS catalog tables or import database object definitions from existing text scripts.


For this tutorial, we extract directly from a database just as you would in a real migration. If you do not have an IDS database, then select Import and import the DDL from a file.

Using the Extract capability, it is possible to:

� Extract only a subset of objects into its own file, for example, only tables into a tables.src file and only functions into a functions.src file. This is a recommended best practice.

� Automatically resolve dependencies, for example, when extracting a view also determine and extract needed tables and when extracting a table also extract the primary key.

� Extract each procedure and trigger to its own text file.

Tables and indexes are generally the easiest to migrate. We do this first, because all other objects, such as functions, procedures, and triggers, depend on table definitions.

Click the Extract button to begin the process of extracting the DDL into the project.

Before you can extract the DDL you must first connect to the IDS database. The Connect to Database panel opens next, as shown in Figure 8-3 on page 247. For your connection, use the native JDBC driver provided with the MTK. Select the Use native JDBC driver option. Enter the information needed to establish a connection to the IDS server and click OK. The required information is:

� IDS database name� IP address of the host machine where the IDS server is installed� Port number for the IDS server� IDS server name� User ID and password with authority to extract IDS catalog information

Note that on Windows, an ODBC or a JDBC connection can be used.

Figure 8-3 on page 247 shows an example of the values to be inserted. Enter the values that are specific to your system and click OK.

Note: Data manipulation statements (DML), such as SELECT, INSERT, UPDATE, and DELETE, can also be translated when imported by way of script files. However, the table definitions that the DML depends on must be translated first.


Figure 8-3 Connect to Database panel

Upon a successful connection, a graphical extract tree structure representing all installed IDS databases opens, as shown in Figure 8-4 on page 248. Expand the tree for the stores_demo database and view all of its contents. You should see 11 tables, 3 procedures, and 1 trigger.

For this tutorial, we only extract the tables. If you select the check box next to tables, you will notice that a new table, named itemslog, has been added to the schema that is delivered for stores_demo. This table was added to support a trigger that will be converted in “Part II: Database application object migration” on page 275 of this tutorial. In that section, we revisit this capability and extract the procedures and trigger previously discussed.


Figure 8-4 Extract tree structure

Take note of the Extract grant statements option. Selecting this option will extract all the grant definition statements. However, the MTK will not convert or deploy them. This feature is helpful when reconstructing grants for DB2, but the deployment of grants will need to be performed manually.

Next, we name this conversion task tables. To do that, enter tables into the File name box and click the Extract button.

After you have extracted the objects, your connection is lost. However, you can always go back and extract the additional objects that existed at the time of the extraction. You only need to click the Connect to Database button to connect to the database again if you have added new objects to the database after the extraction was performed.

On the next panel, take a moment to familiarize yourself with the contents of this script by clicking the View button. Refer to Figure 8-5 on page 249. For our tutorial, it contains SQL (DDL) with the following IDS-specific constructs:

� Connect to database statement� Create table statements with text, byte, nchar, datetime year to minute, serial,

interval, and money data types� Alter table statements to add primary and foreign keys� Create index statements


Figure 8-5 Script contents

To continue to the next step, click the Convert tab.

8.2.2 Convert tabWe are now ready start the conversion. To do this, we use the Convert tab to display the Convert panel, as shown in Figure 8-6 on page 250. The left side of the panel lists the IDS source files (denoted as type .src). The right side of the panel is where the translated files for DB2 (denoted as type.db2) will be listed after the conversion has been run. In the middle of the panel, you will see the Convert button, which initiates a conversion of the currently selected source file

Note: You can also view the DDL, which is located in Appendix B, “Informix source and object definitions” on page 551.


on the left. To start the conversion, highlight the tables.src file on the left. Be careful to select the correct file when more than one source file is displayed.

Figure 8-6 Convert tab

There are some optional features to note on the Convert tab. Recall that help text will appear when the cursor is placed over each feature.

� The Default source schema pull-down provides following three values from which to select:

– from_first_object: The schema name found on the first object in the file is omitted from the converted file (no user entry allowed).

– Specify schema for all objects: The schema name for source objects is included in the converted file (no user entry allowed).

– database name:schema name: User entry is allowed for this option. Specifying a “database name:schema name” is useful when converting a file containing objects from more than one schema or more than one database because it lets you control which database:schema combination will be removed from the output object names.

� Advanced Options: These are used to control the characteristics of the conversion file that will be output. For example, by default, the source IDS object definitions are written as comments in the translation file; this can be disabled. Also, drop statements can be added before create statements to ease repeated deployment.


� Global Type Mapping: Click this button to view the MTK default data type mappings and to override those default mappings identified with an edit icon. Refer to Figure 8-7 on page 252 to see the mappings. After the data type mapping has been changed, the effect is global to all conversions within the project.

� Previous Conversions: Click the Reload button when you want to make a previous conversion the active conversion again. This will enable the viewing of all files associated with the conversion without performing the conversion again.

Before you start the conversion and click the Convert button, there are two modifications that need to be performed:

1. View the tables.src file and find the nchar(255) data type in the msgs table. By default, the MTK will convert the nchar to the DB2 vargraphic data type. However, unlike nchar, the vargraphic data type only supports double-byte data. If your DB2 is using a single-byte codeset, you must map nchar[128.] to the DB2 varchar or deployment of this table will fail. To do this, go into Global Type Mapping button and click the edit icon for vargraphic; select varchar from the pull-down list and click Apply. The length of varchar will default to the length of the nchar data type.


Figure 8-7 Global type mapping

2. View the table.src file again and using double-dashes comment the second create index statement for the msgs table, as indicated in Example 8-1. Remember to save the change.

Example 8-1 Create Index

CREATE INDEX “nsokolof”.idxmsgs_enus ON “nsokolof”.msgs (message);--CREATE INDEX “nsokolof”.idxmsgs_frfr ON “nsokolof”.msgs (message);

DB2 will not allow two indexes to be created on the same column within one table. If the index is left uncommented, the CREATE will fail during deployment.

Now click the Convert button. When conversion completes, the MTK automatically takes you to the Refine tab. At the refine stage, you have the


opportunity to review errors, warnings, and other information associated with the translation.

8.2.3 Refine tabThe Refine tab has two main panels. On the left panel, you see the messages tree. On the right panel, more information about the currently selected tree node is displayed. When you select the root tree node, you see a summary of the errors encountered, listed in order of decreasing importance. You would typically use the summary information to target the most critical migration issues first.

Expand the messages tree in the left pane for Translator Warning and Translator Information to view all message numbers generated, as shown in Figure 8-8 on page 254. Each message number also provides a short description for that message type (for example, “Message Number: 24: NOT NULL constraint is added…"). Next expand each message number to see a list of occurrences by line number for each message type and select a line number.


Figure 8-8 Translator messages

On the right pane, you will see two sub-tabs, as shown in Figure 8-9 on page 255:

� Source file: tables.src

The original IDS extract file

� DB2 file: tables.db2

The translation made by the MTK for DB2

Note: Your line numbers might vary slightly.


Figure 8-9 Source type

Click the Source file sub-tab and the MTK will bring you to the line in the source file that corresponds to the line number you selected. Refer to Figure 8-10, which depicts the IDS source file at line number 39.

Figure 8-10 Source file line selection

Click the DB2 file sub-tab to see the same line in the translation file and the translation made by the MTK. Refer to Figure 8-11 on page 256, which is a view of the translation file for DB2 at line number 39. For Message Number 24, you should see that the MTK added the NOT NULL constraint to the primary keys of each DB2 table. DB2 requires that the NOT NULL constraint is explicitly stated


for all columns that make up the primary key. IDS does not require that the NOT NULL constraint is explicitly stated.

Figure 8-11 DB2 line translation

Take some time to examine the Translator Information messages that were generated during the REFINE step. Click the Message Help button on the upper-right side of the Refine panel to display additional message help text. Also notice that the source IDS DDL is included in the DB2 translation file as comments.

Be sure to note the Translation Rate message at the bottom of the tree. In this tutorial, the rate is 100%, indicating that all of the statements in the extract script are accounted for and translated without error.

For future reference, the most frequently encountered translation messages that Refine generates are:

� Translator Information

� Translator Warning

� Translator Error


� Input Script Error

Select the Help menu on the MTK menu bar for a detailed description of each message category and the message numbers that can be generated. The MTK Help offers very useful information related to the toolkit and should be reviewed. Figure 8-12 shows this menu option.

Figure 8-12 Help menu

A word about making manual changesIn this example, the MTK automatically compensated for IDS-specific DDL constructs, and, except for the two changes made in the Convert step, no other manual intervention was required. However, most likely, during the conversion process, as we will see in “Part II: Database application object migration” on page 275, some manual intervention is frequently required.

When manual intervention is related to DDL, always make the change within the MTK or to the source file and run the Convert step again. All table changes must be made through the MTK or it might affect how the MTK later extracts and deploys data.

An exception to this rule is when:

� It is the final step in the translation process, because running the Convert step again will remove all manual changes made to the translation file.

� You are adding table spaces, or other physical database design changes, to the DDL in the translation file and deploying the script manually outside of the MTK. We discuss this further in “MTK and DB2 table spaces” on page 260.

For procedures, functions, and triggers, the manual change can be made either to the source or the translation file. When making a change to the translation file, it should be the final step in the translation process. Running the Convert step again will remove all manual changes made to the translation file.

Congratulations! This ends your first MTK refine. Review the translation file to see how the MTK converted IDS data types to DB2. Table 8-1 on page 258 summarizes these changes. You can also see the translation file in Appendix B, “Informix source and object definitions” on page 551.


Table 8-1 Translations

8.2.4 Other common migration considerationsIn this section, we discuss some additional common migration considerations.

Renaming object namesA common warning message that you will likely see in your migrations is about index name lengths. In DB2, index names are limited to 18 characters. The MTK will compensate by automatically shortening the name of any index longer than 18 characters. Usually, renaming indexes is harmless, because applications generally do not need to reference indexes by name.

But perhaps you have a standard naming convention for object names, and the name suggested by the MTK was not appropriate. You can provide a different name for any migrated object by performing the following steps:

1. If the Go to Source Object button is highlighted (as shown in Figure 8-13 on page 259), click this button to take you to a panel where you can see both the Informix object name and the DB2 object name, as shown in Figure 8-14 on page 260. If the Go to Source Object button is not highlighted, you can also get there by selecting the Informix tab on the bottom-left side of the panel shown in Figure 8-11 on page 256.

IDS DB2 UDB

nchar(255) varchar(255)

interval day to day decimal(15,0)

money(8,2) decimal(8,2)

text clob(2G) not logged

byte blob(2G) not logged

datetime year to minute timestamp

serial integer generated by default as identity not null


Figure 8-13 Source object example

2. In the panel shown in Figure 8-14 on page 260, you can select any object to rename by expanding the graphical tree structure on the left side of the panel and highlighting that object.

3. When you have highlighted the object that you want to rename, click the edit icon on the right side of the panel, and a window opens for you to provide a new name for the object.

4. Type in the new index name and click Apply to apply the name for the index.


Figure 8-14 Renaming objects

5. For the change to take effect, we need to return to the Convert tab and click the Convert button again. The Convert button will reread the original source file and apply any changes defined to generate a new tables.db2 file.

The previous tables.db2 file is discarded and a new tables.db2 file is generated. You are again taken to the Refine tab of the MTK. The effects of renaming an object persist for the lifetime of the project.

MTK and DB2 table spacesYou will notice that the dbspaces were not converted. IDS dbspaces definitions do not map exactly to DB2 table space definitions due to fundamental architecture differences. Also, dbspace definitions that might be optimal in IDS might not be optimal for DB2.

Furthermore, if the source table and index DDL used in this tutorial had contained the in dbspace clause, this clause would have been ignored by the MTK during translation.


Example 8-2 Create table DDL

CREATE TABLE t2 (c1, c2, ….)IN tablespacenameINDEX IN index_tbspace_name;CREATE INDEX ix_name ON t2 (c1);

Because the MTK does not map dbspaces to DB2 table spaces, assigning converted tables and indexes to table spaces is a manual process and requires editing of the final translation file.

Tables with rows longer than 4 KBWhen you create a database in DB2, the default table space uses a 4 KB page size. The maximum row size that can be used in a 4 KB page size is 4005 bytes.

If you are converting tables with a row size wider than 4005 bytes, the MTK will automatically create a table space and associated buffer pool to support this wider row size for you. The additional table space and buffer pool is created as part of the deployment process in the tool. Your translated DB2 script remains unchanged. Therefore, if you were to deploy the tables.db2 file manually from the DB2 command line processor (CLP), a table wider than 4005 bytes would fail to be created. In this case, you would first have to create the additional buffer pool and table space yourself.

Note that the Deployment phase generates a report listing tables and their row lengths, as shown in Figure 8-15 on page 262.

Note: In DB2, the table space for indexes is specified with the create table statement rather than the create index statement. So, if you were to migrate this from the DB2 Command Center or CLP, the DDL would look similar the one shown in Example 8-2:

Recommendation: In your own migrations, accept the translated DDL as is and use it for unit testing of routines and triggers. Revisit the placement of indexes and their table spaces when ready to create the production database or perform system and performance testing, or both.

Recommendation: Make a note of such a case if you encounter it in your own migrations. At some point, usually during a performance exercise, you can determine the appropriate table space or spaces and buffer pool or pools to create.


Figure 8-15 Table list

Other useful featuresThis section describes additional features of MTK of which you should be aware.

Deploying MTK scripts manuallyAll DB2 scripts generated by the MTK use the exclamation mark rather than a semicolon as the end-of-statement delimiter. If you run these scripts manually from the CLP, you need to use the commands shown in Example 8-3 to indicate that the exclamation mark is the terminating delimiter.

Example 8-3 Script delimiter commands

db2 connect to dbname (where dbname is a manually created database)db2 -td! -vf <filename> -z <log file>

Viewing the Changes ReportAll changes made through the MTK, such as data type mappings and renaming objects, are tracked for you on a project basis. You can view these changes using the Changes Report, which can be accessed from the MTK menu bar under Tools. Figure 8-16 shows the Changes Report menu item.

Figure 8-16 Tools menu

Click the Tools tab. Click the Changes Report selection. You will then be presented with the report, an example of which is shown in Figure 8-17 on page 263.


Figure 8-17 Changes Report

8.2.5 Generating Data Transfer Scripts tabThe Generate Data Transfer Scripts tab generates:

� IDS scripts to extract data to flat files from an IDS database� DB2 scripts to load and import data into a DB2 database� Scripts to move data using named pipes

In your migration project, if you use SQL statements to seed (that is, to initialize with small amounts of inserted data) the database, you should convert those statements using the MTK instead, and you can skip this section entirely. But for the purpose of this tutorial, it is best to read this section regardless.

This step creates scripts that can be used by the current machine or on another machine (Windows or UNIX) to perform the deployment. To move the scripts to another machine and deploy the scripts manually, refer to the Help on the MTK menu for further instructions. This is very useful when the volume of the data precludes using the machine where the MTK is located.

DB2 data loading optionsThere are two methods to load data quickly from flat files into DB2: IMPORT and LOAD, as shown in Figure 8-18.

Figure 8-18 Data loading options

Note: A common misconception is that data is moved from IDS to DB2 at this point. To be clear, no data is actually moved at this point - only the scripts are generated. In fact, there is not even a connection to either source or target database.


The MTK supports both loading options:

IMPORT High-speed loader using SQL. IMPORT reads data from a flat file and generates appropriate INSERT statements. COMMIT frequency can be reduced to improve performance. Because INSERT is used, constraints are enforced, and triggers are activated. Performance of this method is largely determined by the buffer pool size. Logging is performed.

LOAD Higher-speed loader using lower-level techniques. LOAD reads data from a flat file and loads data at the data page level. Because SQL is not used, triggers are not activated as rows are loaded. Performance of this method is largely determined by the utility heap size. Logging is not performed.

DB2 LOAD/IMPORT modeAfter selecting the loading option, you are prompted to select the LOAD/IMPORT mode, as shown in Figure 8-19.

Figure 8-19 LOAD/IMPORT mode

LOAD and IMPORT tools can replace existing data or insert new data when loading data into DB2. Either option will work.

File formatNow, select the file format, as shown in Figure 8-20.

Figure 8-20 File format

The MTK supports both ASCII delimited (DEL) and ASCII positional (ASC) files. In most cases, the default (ASC) will work fine. The DEL format might require

Recommendation: In most cases, you should be using the LOAD utility, because you want to move the data from IDS as it is, without triggers activating.


less disk space for extracted flat files, but you might encounter difficulties in selecting a unique column delimiter, depending on your data.

Directory for Data ExtractionThis path specifies where the data extracted from IDS will be stored. Be sure to choose a device with sufficient disk space.

Advanced OptionsDepending on the data load method (LOAD or IMPORT), you will see a different menu for Advanced Options. The options you select can affect overall performance of the data migration process.

Create Scripts buttonThis button initiates creation of data movement scripts, which are used by the MTK in the next step of the migration. Figure 8-21 on page 266 shows an example of the transfer files generated.

The following types of files are generated:

� Files used to extract data from the source database:

– DataMove_filename_data.bat– DataMove_filename_data.sh

� A file with examples of statements used to select and convert data from the source database:

– DataMove_filename.qry

� Files used to execute the load data into DB2:

– DataMove_filename_db2.bat– DataMove_filename_db2.sh

� Files that contain DB2 load scripts:

– DataMove_filename.bat– DataMove_filename.sh

� A file to move data using named pipes:

– DataMove_filename_pipe.sh


Figure 8-21 Data transfer files

8.2.6 Deploy to DB2 tabAfter you have generated the data transfer scripts, you are ready to deploy DDL and data to DB2. Click the Deploy to DB2 tab.

Deployment is a three-part process:

1. Create objects in DB2 by launching the converted script.

2. Extract data from source database to flat files.

3. Deploy data from flat files to DB2.

Deploy tables and indexes to DB2Perform the following steps for the deployment:

1. First, specify the conversion name, as shown in Figure 8-22 on page 267. In this case, the conversion name is tables (tables.db2) and is the only deployable conversion at this time. If you have completed function, trigger, and procedure migrations also, the pull-down menu will have more conversions from which to choose.


Figure 8-22 Deploy to DB2 tab: Conversion

2. Next, select the DB2 target. The database can be local or remote. The MTK can deploy the migrated DDL to an existing database or create a new database. For this tutorial, we deploy our DDL to a new database called DB2store. If your target database is local, you can use the (Re)create option. If your database is remote, you must first manually create your database on that system and catalog the remote database in the local DB2 instance. Also, note that although IDS allows a database name to be longer than eight characters, DB2 has a name limit of eight characters.

3. For now, we are only creating the DB2 database objects from the migrated DDL (the first part of the three part deployment process). Therefore, make sure that only the Launch tables.db2 in the database option is selected.

4. Click the Deploy button to create the migrated tables in the DB2store database.


5. When the deployment completes, a Verification report opens to show you the results of table and index creation, as shown in Figure 8-23. Confirm that everything deployed properly.

Figure 8-23 Verification report

If there are no errors in the Verification report, you have successfully deployed your tables and indexes to DB2 and are ready to extract and load data into DB2.

Migrating the dataDeploying data is generally very easy with the MTK. We describe the best practices of deploying DDL and data.

At the bottom of the Deploy to DB2 tab, three options are available:

� Launch <conversion file >.db2 in the database

� Extract and store data on this system

� Load data to target database using general scripts

You might be tempted to select all three, as illustrated in Figure 8-24 on page 269, but we do not recommend it.


Figure 8-24 Deployment choices

Deployment best practicesWhen you perform your actual migration, we recommend that you proceed with the deployment as described in the following steps to give you more control and to avoid too much activity in one step:

1. Start by selecting the first option, Launch tables.db2 in the database, as shown in Figure 8-25, and click Deploy. This creates tables and other objects and gives you a chance to review the verification reports.

Figure 8-25 Deployment option 1

2. When you are comfortable with the results of the previous step, proceed to the second option, Extract and store data on this system, as shown in Figure 8-26. Click Deploy again to perform data extraction to flat files.


3. If the extraction completed successfully, select the third option, Load data to target database using generated scripts, as shown in Figure 8-27 on page 270, and click the Deploy button. This will load the data into DB2 from the flat files created in the previous step.



4. When the deployment completes, a Verification report, as shown in Figure 8-28, launches to show the results. Check the report for errors. If everything completes without errors, you have successfully migrated the data.



You can view the MTK log, which records MTK activities by time stamp, to check the elapsed time for the data load and other processes.

Also, review the DB2 deploy log and note that the MTK invoked the DB2 runstats utility after loading the data. The runstats utility is comparable to the IDS update statistics command.

As you will see when you are migrating functions, triggers, and procedures, you will simply repeat step 1 above for each of those scripts. You will not have to perform step 2 or 3 again.

Additional featuresThis section describes some additional features of the MTK.

SQL TranslatorNow that you have successfully migrated the objects and data, we can examine another very useful feature of the MTK, the SQL Translator. From the MTK menu bar, select Tools → SQL Translator, as shown in Figure 8-29.

Figure 8-29 SQL Translator menu option

The SQL Translator can be used for ad hoc translations from IDS SQL to DB2 SQL. Before you can translate an IDS SQL statement, you must first point the MTK to the converted table definition statements on which the SQL statement depends. To do this, ensure that the default Use all files of current conversion

Note: The Catalog table in DB2 contains CLOB and BLOB data (converted from TEXT and BYTE in IDS). The MTK must be installed on the same machine as DB2 to deploy the loading of LOB data. BLOB and CLOB data is unloaded into files that are separate from the rest of the table data. Prior to DB2 V8, each BLOB or CLOB value for a table was unloaded into a separate file. With DB2 V8, all BLOB or CLOB values for a table are unloaded into a single file.


is selected from the pull-down list. Type the following IDS SQL statement into the top half of the panel, as shown in Figure 8-30, and click Convert:

select substr(stock_num, 1,1) from items;

Figure 8-30 SQL Translator

Examine the bottom portion of the panel to see how the MTK converted this statement to DB2.

DB2 does not support implicit casting. Therefore stock_num, which is defined as a SMALLINT in the ITEMS table, must first be converted into a character value using the CHAR function before the SUBSTR function can be applied. The output of the SQL Translator is:

SELECT INFX.SUBSTR(CHAR(stock_num)1,1) FROM items!

Use the SQL Translator to assist with the conversion of SQL found within application code. The SQL Translator can be used to translate IDS DML and DDL statements including create procedure, function, and trigger.


Running the MTK debuggerFrom the OS command line in the default MTK installation directory (the C:\MTK directory on Windows and a user-named directory on UNIX), start the debugger by executing:

MTKMain -debug

Run the MTK task that you are attempting to debug and view the MTK log (mtk.log) to see logged messages at a more granular level.

8.3 Summary of best practicesThe following are some best practices to observe when using the MTK:

� The MTK always translates by parsing a text input file. Even if no IDS source database is available, it supports using a user-provided input file for migration. If you have an IDS source database, the MTK extracts the DDL from the database into a text file from which to translate.

� When extracting objects for migration, do not try to do too much in one step. In the example we provided, we start with tables and related items (such as indexes and constraints) only. Consider migrating tables, triggers, functions, and procedures separately. If your database is very large, you might want to further divide your migration effort by the functional components of the application.

� Some objects might require renaming if the name is greater than 18 characters. Within REFINE, you have the opportunity to override the default name mapping if you want.

� Every time you click the Convert button, the MTK rereads the input file, applies user-defined changes, and generates an entirely new output file.

� Primary keys require columns to be non-nullable in DB2. Unique keys only allow one null value per column.

� The MTK might not be able to provide REFINE capability for some warnings or errors. You can manually change the input file to suit your needs and click the Convert button again. This applies to any objects that have problems converting, not only tables.

� An index dbspace clause in IDS is not directly convertible to DB2. In DB2, it is the CREATE TABLE statement that specifies the table space for the table index.

� During MTK deployment, the tool will automatically create table spaces and buffer pools for tables that have row sizes in excess of 4005 bytes. Deciding how and which additional table spaces and buffer pools to create should be part of a performance tuning exercise.


� After you have a clean conversion, you can reduce the use of commenting in the output file by disabling it in the Advanced Options.

� Insert statements can be used to populate your tables with a few rows of test data. This practice has been referred to as seeding. If your application seeds the database with initial data using INSERT statements, data extraction and deployment might not be necessary. Instead, you can convert the INSERT statements directly.

� If your source database is small, you can have the MTK create a database for the initial deployment. However, if the database is large, you should pre-create the database and do some initial tuning before deployment (table space layout, utility heap (if using LOAD), and buffer pools (if using IMPORT).

� When you deploy to DB2, do not deploy everything at once. Start with DDL and ensure that all objects were created successfully before proceeding with data. Then, perform data extraction and data deployment as separate steps.


Part II: Database application object migrationNow that the table DDL has been migrated, database application objects, such as SPL routines (functions and procedures) and triggers, can be migrated. Application object migration tends to be more involved, but the MTK makes this task far more manageable.

Before starting, be sure that the three routines and one trigger, created previously in this tutorial, are created on your stores_demo database.

8.4 Procedure, function, and trigger migrationThis section describes the steps required to migrate procedures, functions, and triggers. We migrate some samples as part of this tutorial to better familiarize you with the process. Let us get started.

To migrate procedures, functions, and triggers, perform the following steps:

1. In the same project that we used to convert the tables (Part I: Core database migration), click the Specify Source tab at the top of the panel.

2. Expand the tree for Procedures and Triggers, as shown in Figure 8-31 on page 276. You should see the following objects:

– get_order– stockdel– upd_items_p2e. insert_trig

3. Extract the procedures and triggers in two separate steps. Be sure to clear the Tables check box.

a. To extract the procedures, select the Procedures check box, name the extract file procedures, and select the Create one file per stored procedure option. Click the Extract button.

Note: By selecting the Create one file per stored procedure option, each routine will be extracted into a separate file. This will simplify the conversion process later.


Figure 8-31 Extract

b. To extract the trigger, select the Triggers check box, name the extract file trigger, and select the Do not include option. (Be sure to clear the Procedures check box). Figure 8-32 shows this. Click the Extract button.

Figure 8-32 Extract procedure

4. Briefly familiarize yourself with the routines and trigger by clicking the View button. The contents have some conversion issues, which are highlighted in bold.

– The get_order function is shown in Example 8-4.

Example 8-4 Get order

CREATE FUNCTION get_order (ord_num INT) RETURNING VARCHAR(10), DATE;DEFINE po VARCHAR(10);DEFINE ord_dt DATE;FOREACH cursor1 FOR

SELECT po_num, order_date INTO po, ord_dt FROM ordersWHERE order_num > ord_num

RETURN po, ord_dt WITH RESUME;END FOREACH

Note: By selecting the Do not include option, you will exclude trigger dependencies from the extract file. In this case, you have already converted the itemslog table, which this trigger depends on.


END FUNCTION;

– The stockdel function is shown in Example 8-5.

Example 8-5 Stock delete

CREATE FUNCTION stockdel (snumb smallint) RETURNING INT;DEFINE srows INT;DELETE FROM stock WHERE STOCK_NUM = snumb;LET srows = DBINFO('sqlca.sqlerrd2');RETURN srows;END FUNCTION;

c. The upd_items_p2 procedure is shown in Example 8-6.

Example 8-6 Update item

CREATE PROCEDURE upd_items_p2 (old_qty int);DEFINE new_qty INT;LET new_qty = (SELECT SUM(quantity) FROM items);IF new_qty > old_qty + 1.50 THEN

RAISE EXCEPTION -746, 0, 'Not Found';END IFEND PROCEDURE;

d. The insert_trig trigger is shown in Example 8-7.

Example 8-7 Create trigger

CREATE TRIGGER insert_trig INSERT ON itemsBEFORE(INSERT INTO itemslog (item_num, order_num, stock_num, manu_code, quantity, total_price)SELECT item_num, order_num, stock_num, manu_code, quantity, total_price FROM items);

5. Click the Convert tab.

6. To convert the routines and trigger, we must first set the context of the migration because each function, procedure, and trigger references tables from the conversion in “Part I: Core database migration” on page 243. Click the Context button.

7. In the Set Context panel, shown in Figure 8-33 on page 278, indicate to the MTK that your next conversion will have dependencies on tables by clicking the single arrow (>) to send the tables.src file to the right side of the panel. Click OK to close the window.


Figure 8-33 Set Context

8. Return to the Convert tab.

You should notice that the context indicator (context) now appears next to the tables.src file. Before starting, click the Advanced Options button and select the options shown in Figure 8-34. This will make the .db2 translation file cleaner and easier to read.

Figure 8-34 Advanced Options

9. We can now proceed with the conversion, using the following steps:

a. Select the get_order.src file.

b. Click the Convert button.

This will begin converting the routines to DB2 and take you to the Refine tab. We now begin refining the migration the same way we refined conversion of tables and indexes, by working through the messages tree.


10.Expand the messages tree, as shown in Figure 8-35.

Figure 8-35 Messages tree

This is a new class of error. Translator Error means that in some situations the MTK cannot be sure that the translation was correct and manual intervention might be required; the user needs to validate the translation. This differs from the Translator Warning, which indicates that the MTK has automatically made a translation decision.

On the right pane, click the Source File tab and then the DB2 file tab to get more specific information. Example 8-8 shows what you should see when the DB2 file tab is selected.

Example 8-8 Sample FUNCTION

--| CREATE FUNCTION get_order (ord_num INT) RETURNING VARCHAR(10), DATE;--| DEFINE po VARCHAR(10);--| DEFINE ord_dt DATE;--| FOREACH cursor1 FOR--| SELECT po_num, order_date INTO po, ord_dt FROM orders--| WHERE order_num > ord_num--| RETURN po, ord_dt WITH RESUME;--| END FOREACH--| END FUNCTION;

--*[300094]"C:\MTK_INFX\projects\Tutorial1\nsokolof_get_order.src"(6:1)-(14:13)This UDF is translated to DB2 as a Procedure--*[400144]"C:\MTK_INFX\projects\Tutorial1\nsokolof_get_order.src"(6:1)-(14:13)Translation of cursor function may not be correct

CREATE PROCEDURE get_order (ord_num INTEGER )LANGUAGE SQLBEGIN

DECLARE GLOBAL TEMPORARY TABLE result_table(value1 VARCHAR(10),value2 DATE

) WITH REPLACE ON COMMIT PRESERVE ROWS NOT LOGGED; BEGIN

Note: Your line numbers might vary slightly.


DECLARE po VARCHAR(10);DECLARE ord_dt DATE;DECLARE temp_cursor CURSOR WITH HOLD WITH RETURN TO CALLER FOR SELECT *

FROM SESSION.result_table;FOR cursor1_LOOP AS cursor1 CURSOR FOR SELECT po_num, order_date

FROM ordersWHERE order_num > ord_num

DOSET ord_dt = order_date; SET po = po_num;BEGININSERT INTO SESSION.result_table VALUES (po, ord_dt);END;

END FOR; end_func:OPEN temp_cursor;

END;END!

For now, we will assume that the translation is correct and we will validate this further during deployment when DB2 builds the procedure. There are a few other things that you should notice about this translation:

– The function has been translated to a procedure.

– The FOREACH loop has been translated to a FOR loop.

– A global temporary table named SESSION.result_table is declared.

– The results of the FOR loop are inserted into the global temporary table.

– The RETURNING clause and the RETURN WITH RESUME has been replaced by declaring and opening a cursor on the global temporary table to return data to the calling program.

Functions will be converted to procedures if you use any of the following items:

– INSERT, UPATE, or DELETE statements

– Calls to stored procedures

– Cursor processing

– Savepoints, commit, or rollback

– temporary tables

– More than one value is returned

– Exception handling

When a function is converted to a procedure, the RETURNING clause is usually converted to a DB2 procedure using OUT parameters. In this case,


because a result set of many rows, rather than a single set of values, is returned, the data is returned using a cursor.

11.Go back to the Convert tab and select stockdel.src for the next conversion. In the Refine tab, expand the messages tree to that shown in Figure 8-36.

Figure 8-36 Messages tree

12.This message indicates that the MTK did not perform the translation for DBINFO('sqlca.sqlerrd2'). In this case, you will need to finish the translation manually. To do this, you should make modifications to the translation file. Return to the Convert tab, click View to view stockdel.db2, and edit the procedure, as shown in bold in Example 8-9.

Example 8-9 Sample procedure

--|CREATE FUNCTION stockdel (snumb smallint) returning INT;--| DEFINE srows INT;--| DELETE FROM stock WHERE STOCK_NUM = snumb;--| LET srows = DBINFO('sqlca.sqlerrd2');--| RETURN srows;--| END FUNCTION;

CREATE PROCEDURE stockdel (snumb SMALLINT, OUT RETURN_VAL INTEGER ) SPECIFIC get_diagLANGUAGE SQLBEGINDECLARE srows INTEGER;DELETE FROM stockWHERE stock_num = snumb;GET DIAGNOSTICS srows = ROW_COUNT; SET RETURN_VAL = srows;RETURN 0;END!

Note: DB2 Functions only return a single value and are always invoked from an SQL statement. If functions are used within IDS applications, and those functions are converted to DB2 as procedures, application changes might be required.


You should notice the following:

– The function has been translated to a procedure because of the DELETE statement.

– The RETURNING clause has been translated to an OUT parameter.

– DBINFO('sqlca.sqlerrd2') has been converted to the DB2 equivalent, GET DIAGNOSTICS srows = ROW_COUNT.

After making your changes, be sure to save the file and do not run Convert again or you will lose your edits. You will deploy this file together with the other translated files later.

13.Highlight the next routine for conversion, the upd_items_p2.src file. Click Convert and review the messages on the Refine tab.

You should again see a Translator Error message. Expand the message, select the line number for the statement that the MTK cannot translate, and select the DB2 file tab to view the problem. You should see the information shown in Example 8-10.

Example 8-10 Update items

--| CREATE PROCEDURE upd_items_p2(old_qty int); --| define new_qty INT; --| let new_qty = (select sum(quantity) from items); --| if new_qty > old_qty + 1.50 then --| raise exception -746,0,'Not Found'; --| end if --| end procedure;

CREATE PROCEDURE upd_items_p2 (old_qty INTEGER ) LANGUAGE SQL BEGIN

DECLARE new_qty INTEGER; SET new_qty = (SELECT SUM(quantity) FROM items); IF new_qty > old_qty + 1.50 THEN

--*[500005]"C:\MTK_INFX\projects\Tutorial1\nsokolof_upd_items_p2.src"(10:6)-(10:40)This feature is not translated.

SIGNAL (unknown) SET MESSAGE_TEXT = 'Not Found'; END IF;

END!

14.The MTK is not able to complete the translation for the IDS Raise Exception statement, which uses the error code -746, indicating that this is a customized error message. The DB2 equivalent is the Signal statement, but a customized SQLSTATE code must be selected to complete the statement. With DB2, a customized SQLSTATE code can start with numbers from 7 to 9. To complete the translation return to the Convert tab, edit the upd_items_p2.db2 file, and


replace “(unknown)” with the SQLSTATE code shown in Example 8-11. Save the file for deployment later.

Example 8-11 SQLSTATE

SIGNAL SQLSTATE '99002' SET MESSAGE_TEXT = 'Not Found';

15.Highlight the last file for conversion, the trigger.src file. Click Convert and view the messages on the Refine tab, as shown in Figure 8-37.

Figure 8-37 Trigger report

These messages indicate that there is problem with the BEFORE definition for the trigger for DB2. Take a look at this trigger again in Example 8-12.

Example 8-12 Trigger

CREATE TRIGGER insert_trig INSERT ON items BEFORE (INSERT INTO itemslog (item_num, order_num, stock_num, manu_code, quantity, total_price) SELECT item_num, order_num, stock_num, manu_code, quantity, total_price FROM items);

DB2 supports BEFORE and AFTER triggers with FOR EACH ROW and AFTER triggers with FOR EACH STATEMENT. DB2 does not support a BEFORE trigger FOR EACH STATEMENT. In addition, with DB2, a BEFORE trigger cannot have an INSERT, UPDATE, OR DELETE statement within the trigger body. Therefore, as you can see, there are two problems with translating this trigger to DB2:

– This trigger is essentially a BEFORE statement trigger.

– This trigger contains an INSERT statement.

You might be able to solve this translation problem by changing BEFORE to AFTER in the trigger. Edit the trigger.src file, save the change, click Convert again, and review the messages on the Refine tab.

Note: In many cases, it is safe to convert the BEFORE trigger into an AFTER trigger in the source script and reconvert, but you should determine this based on your knowledge of the application. For more information, refer to Chapter 6, “SQL considerations” on page 189.


In Refine, you should see that there are no translation problems related to changing this BEFORE trigger to an AFTER trigger. Example 8-13 shows the translated trigger.

Example 8-13 Trigger

CREATE TRIGGER insert_trig AFTER INSERT ON itemsFOR EACH STATEMENT MODE DB2SQL BEGIN ATOMICINSERT INTO itemslog(item_num, order_num, stock_num, manu_code, quantity, total_price)SELECT x0.item_num, x0.order_num, x0.stock_num, x0.manu_code, x0.quantity,

ROUND(x0.total_price, 2) FROM items x0;END!

Now that the routines and trigger have been translated, you can deploy them to DB2 by performing the following steps:

1. Click the Deploy to DB2 tab.

2. From the Conversion name list, select the translation file for the first object you will deploy in any order. In this case, order is not important, because there are no dependencies between the objects.

3. Ensure that the target database name indicates DB2STORE. Leave the default values for all other settings.

4. Click Deploy.

Repeat steps 1-4 for each object translated.

After each deployment completes, check the Verification report. You should see that each procedure and the trigger have been created successfully in DB2. Figure 8-38 shows an example of the report.



Migration of routines and triggers: Lessons learnedThe following list summarizes the lessons we learned by migrating routines and triggers with the MTK:

� Whenever feasible, extract routines and triggers into separate files to simplify the conversion effort.

� Limit the copying of source code in the Advanced Options to generate an easier to read output file.

� When a project involves multiple files, you might need to identify dependencies by setting the context of the migration using the Set Context button.

� When the MTK identifies a construct in a routine or trigger that cannot be converted, manual intervention is required. Changes can be made to either to the source or translation file depending on the nature of the change. If changes are made to the translation file, do not run Convert again.

� In some cases, a translation problem might not be detected until the deployment to DB2.

� When RETURN WITH RESUME is translated to DB2, a declared global temporary table (DGTT) is often used to store the results set, and a cursor-select on the DGTT is used to return the data to the calling program.

� When an IDS function cannot be converted to a DB2 function, the MTK will automatically convert it to a stored procedure and also resolve dependencies that might exist between it and other procedures and functions.

� A DB2 function can only return a single value and can only be invoked from an SQL statement.

� When a function is converted to a stored procedure, application changes might be required in the calling program.

� You can switch back and forth between conversions using the Reload button.

Note: To view a Verification report other than the current report just generated after deployment, click the Convert tab. From Previous Conversions, select the name of the past conversion from the list and click Reload. This will make all files of the past conversion available for viewing, including the Verification report. Next, click the Deploy tab, and on the right side of the panel, double-click Verify_conversion_name.html. The Verification report from a previous conversion opens.

In addition, cumulative migration reports can be viewed from the MTK menu by selecting Tools → Migration Reports.


� BEFORE triggers that use INSERT, UPDATE, or DELETE statements are not supported in DB2. A common workaround is to convert them to AFTER triggers.

� BEFORE statement triggers are not supported by DB2. When converting these manually to AFTER triggers, be sure to evaluate this change based on your knowledge of the application.


Chapter 9. Access methods

Fast access to data is a critical requirement for any application system. It is crucial for maintaining user satisfaction and providing added value to the business processes. The topic of data access can be discussed from two perspectives. First, access to data typically represents the longest steps in a solution scenario. Therefore, minimizing the time to access data can result in significant decreases in response time for the users. One approach, out of many, is to buffer as much data as possible in memory.

Second, the volumes of data collected and stored by an enterprise today are many times growing at an exponential rate. Therefore, there is typically always much more data on disk than can be buffered in memory for fast access. It is very important, therefore, for the database engine to provide access method techniques that enable the data to be accessed quickly and efficiently.

In this chapter, we describe the types of access methods that DB2 offers to retrieve data efficiently. The topic is discussed from a logical (software) view, rather than a physical data storage and access view. Therefore, issues regarding how to organize physical disks is not included. However, you should note that this is also a very important consideration for enabling faster data access and thus improving performance.

9


9.1 Indexing strategiesIndexes provide an effective way to access data. Instead of scanning the entire table to locate some particular data elements, an index references only the data page where the desired data can be found. That is, the index points directly to the appropriate data page without the requirement to access each page to determine whether or not the desired data is located there. Both DB2 and IDS implement their indexing schemas using B+ trees.

9.1.1 Basic index comparisonThe general syntax for creating indexes is common for both IDS and DB2. An example of that syntax is shown in Example 9-1.

Example 9-1 Basic create index syntax in DB2 and IDS

CREATE [UNIQUE] INDEX <name> ON <table>(<columns>)

The basic naming rules for creating indexes are also common. For example, an index name must be unique for a database, the identifier (the name of the index) must not be longer than 128 characters, and special characters are not allowed in the index name.

In contrast to IDS, DB2 allows indexing columns greater than 255 characters. The limitation of column width in DB2 is 1024 characters. Keep in mind that it is not always ideal to index very large columns. The larger the indexed column, the less performance the index has. This because the size of the index tree also grows larger when using large columns, requiring more time to process the additional data.

Index placementIn IDS, it is a common practice to separate the index pages from the data. This is done by specifying a dbspace at index creation time. DB2 also enables you to place an index into a different table space. But in contrast to IDS, the index table space is specified at table creation time, not at index creation time, as shown in Example 9-2 on page 289. All indexes for a given table will go in the specified table space.


Example 9-2 Separating index and data pages

CREATE TABLE t1 (col1 INTEGER,col2 CHAR (10)

)IN tbs1INDEX IN idxtbs1;

CREATE INDEX idx1 ON t1 (col1);

You must use Database Managed Spaces (DMS) table spaces in order to separate data and index. Both the table space for the data and the table space where the index pages are stored must be DMS table spaces. Only this type of table space enables you to separate the index from the data; the System Managed Spaces (SMS) do not support this.

Clustered indexFor performance reasons, you might to decide to create a clustered index. The syntax to create a clustered index in DB2 is slightly different from IDS, as shown in Example 9-3.

Example 9-3 Creating a clustered index

CREATE [UNIQUE] INDEX <name> ON <table> (<columns>)CLUSTER

DB2 clustered indexes attempt to insert new rows physically close to the rows for which the key values of this index are in the same range. Therefore, the PCTFREE option becomes important, because it influences the future quality of a clustered index when new rows are inserted (see the following section about FILLFACTOR and PCTFREE).

The quality of the cluster index is represented in the system catalog table syscat.indexes. The value of CLUSTERRATIO determines the quality of the clustered index. The higher the value, the better the cluster. In contrast to IDS, this value is maintained dynamically by DB2. This means that there is no need to execute the runstats command (the DB2 counterpart of the IDS update statistics command), necessary to update the quality of the information.

If the quality of a clustered index becomes poor, you have to reorganize the index. Since DB2 Version 8.1, it is possible to perform this administrative task online. Even if users are working with the index, you can start a reorganization of that index. For more information, see “Index reorganization” on page 473.

Chapter 9. Access methods 289

FILLFACTOR and PCTFREEThe IDS parameter FILLFACTOR advises the database engine about how much space should be reserved within index leaf pages for upcoming INSERT statements. DB2 has a similar parameter called PCTFREE. The default value is set to 10. This means that 10% of the space in an index page is to be reserved for future modifications. Keep in mind that DB2 has different page sizes. The syntax for this parameter is slightly different in IDS, as Example 9-4 demonstrates.

Example 9-4 Index with PCTFREE

CREATE [UNIQUE] INDEX <name> ON <table> (<columns>)PCTFREE [0..99]

Space requirements for indexesIndexes might improve response times, but there is a trade-off for that improvement. Indexes are database objects that consume disk space. When migrating an existing database environment, there is a great opportunity to plan the sizings of database objects, such as indexes, correctly. Because you already have the data, you do not have to estimate how much data might occur. Better calculations lead to more effective data storage and thus better performance.

An example equation to calculate the index sizes is:

2 * r * (i + 9)r: number of rows in tablei: key size (bytes)

When the index is being created, it consumes temporary disk space. You should estimate how much temporary space is required. You can estimate this using the following formula:

3.2 * r * (i + 9)r: number of rows in tablesi: key size (bytes)

For these equations, unique indexes are assumed. If the calculation is made with indexes that allow duplicates, you must add 5 bytes per row. In addition, if the index allows null values, add one byte per row for the null indicator.

Be aware that these equations provide only estimates. Therefore, you must validate the estimates before using them.

Example 9-5 on page 291 shows the output of an IDS oncheck -pT command on a table with 2,046,118 rows. You can use the information provided by the oncheck


command to perform a calculation of the estimated index size in DB2 and compare it to the real IDS index sizes.

Example 9-5 IDS oncheck -pT output for information about index sizes

TBLspace Usage Report for dbidx:informix.t1

Type Pages Empty Semi-Full Full Very-Full ---------------- ---------- ---------- ---------- ---------- ---------- Free 14 Bit-Map 1 Index 7307 Data (Home) 0 ---------- Total Pages 7322

Unused Space Summary

Unused data slots 0 Unused bytes per data page 4 Total unused bytes in data pages 0

Home Data Page Version Summary

Version Count

0 (current) 0

Index Usage Report for index t1_idx1 on dbidx:informix.t1

Average Average Level Total No. Keys Free Bytes ----- -------- -------- ---------- 1 1 24 3784 2 24 303 427 3 7282 280 415 ----- -------- -------- ---------- Total 7307 281 415

If you create an index using the DB2 Control Center Create Index wizard, you can also get an estimate of the index sizes. Click Estimate Size in the wizard. A new window opens. In this window, enter the number of rows of the table and click Refresh, as shown in Figure 9-1 on page 292.


Figure 9-1 Estimating the index size using the Create Index wizard

Deleting index entriesAs with IDS, DB2 index entries are not deleted immediately if a delete SQL statement is executed. Instead, the deletion of an index entry will be processed as follows:

� During key insertion, keys that are marked deleted and are known to be committed are cleaned up if such a cleanup might avoid the need to perform a page split and prevent the index from increasing in size.

� During key deletion, when all keys on a page have been marked deleted, an attempt is made to find another index page where all the keys are marked deleted and all those deletions have committed. If such a page is found, it is deleted from the index tree.

� If there is an X lock on the table when a key is deleted, the key is physically deleted instead of just being marked deleted. During this physical deletion, any deleted keys on the same page are also removed if they are marked deleted and known to be committed.


9.1.2 DB2 index expansionsIn the IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, you can find the complete CREATE INDEX command syntax. There are more options and parameters to the syntax than with IDS. The following sections provide common examples of these.

Include optionBoth IDS and DB2 allow key-only reads. These are reads from the database where all the columns in the SELECT list are available through an index. Key-only reads are very efficient because there is no need to access data pages.

In IDS, it was not uncommon for users to add extra columns to unique indexes in order to facilitate key-only reads. These columns would not affect the uniqueness at all. The problem with this practice is that the more columns you add into a composite index, the bigger each index entry will grow at all levels of the index.

DB2 allows you to include columns (see the general syntax in Example 9-6) into a unique index that are found at leaf level only.

Example 9-6 DB2 index with INCLUDE expansion

CREATE UNIQUE INDEX idx_name ON tab_name (col_list)INCLUDE (col_list)

The creation of an include index is shown in Example 9-7. First, a table with two columns is created. Col1 is unique and used for query qualification, but col2 is added to the index for a key-only read.

Example 9-7 Creation of an ordinary composite index

CREATE TABLE t1 (col1 INTEGER,col2 CHAR (3));

INSERT INTO t1 (col1, col2) VALUES (10, ‘IKE’);INSERT INTO t1 (col1, col2) VALUES (11, ‘DOO’);...INSERT INTO t1 (col1, col2) VALUES (19, ‘TOR’);

CREATE UNIQUE INDEX t1_idx1 ON t1 (col1, col2);

Figure 9-2 on page 294 shows the index created in Example 9-7.

Note: Include indexes are allowed for unique indexes only.


Figure 9-2 Schematic view of a composite index

Look at INCLUDE indexes in Example 9-8. The column list of the CREATE INDEX statement does not include the column col2 any longer, but it appears at the end of the statement in the INCLUDE option. Figure 9-3 on page 295 illustrates the logical structure of the include index.

Example 9-8 DB2 index with the INCLUDE option

CREATE UNIQUE INDEX t1_idx ON t1 (col1)INCLUDE col2

IKE10DOO11SEA12

END19SHE20TOR21

IKE13SOO14THE15<=

THE15TOR21

<=SEA12THE15

<=BOA18TOR21

HOT16EOF17BOA18


Figure 9-3 Schematic view of an include index

Notice that the included column is stored at leaf level only, and it is still possible to use this index for queries by the unique col1 column. If a query selects both columns col1 and col2, it is possible to get a key-only select without reading data pages.

Using this technique can increase performance and save index disk capacity.

MINPCTUSED parameterAn index tree is as dynamic as the data changes in the corresponding table. Index leaf pages are split into two new leaf pages if the original leaf page becomes full. If a leaf page becomes empty, because rows have been deleted from the corresponding table, both DB2 and IDS try to compact two leaf pages together into one.

The MINPCTUSED parameter defines at what percentage a leaf page is declared empty and thus subject for compression. The default value for this parameter is 0%, which means that a index leaf page must be completely empty before a reverse split occurs. You can set the MINPCTUSED parameter up to 99%, as shown in Example 9-9 on page 296, but we recommend that you do not use values higher than 50%.

IKE10DOO11SEA12

END19SHE20TOR21

IKE13SOO14THE15<=

1521

<=1215

<=1821

HOT16EOF17BOA18


Example 9-9 DB2 index with the MINPCTUSED parameter

CREATE INDEX <name> ON <table> (<columns>)MINPCTUSED [0..99]

ALLOW REVERSE SCANS optionIndexes are a good instrument to speed-up queries that perform sorts. As in IDS, DB2 index leaf pages are implemented by a double-linked list. That allows access the data in both ascending and descending order.

Unlike IDS, when you create an index in DB2, you must specify what sort sequence the index should support. If you do not specify the sorting sequence, the index follows ascending sorting. When ALLOW REVERSE SEQUENCE is specified in the CREATE INDEX statement (see Example 9-10), the index also can be used for inverse sorting.

The default is DISALLOW REVERSE SCANS.

Example 9-10 DB2 index with the ALLOW REVERSE SCANS option

CREATE INDEX <name> ON <table> (<columns>) ALLOW REVERSE SCANS

COLLECTDB2 allows collection of statistical information of an index during creation time, as demonstrated in Example 9-11. Therefore, there is no need to execute a runstats command after the index has been created.

There are three options when adding the COLLECT parameter:

� STATISTICS: Collects basic statistic information about the index.

� DETAILED STATISTICS: Creates a distribution curve of the index data.

� SAMPLED DETAILED STATISTICS: Creates a sample distribution curve of the index data.

Example 9-11 DB2 index with the COLLECT STATISTICS option

CREATE INDEX <name> ON <table> (<columns>)COLLECT [ [SAMPLED] DETAILED ] STATISTICS;

Indexes and constraintsWhen you create primary key or foreign key, or both, constraints on columns, a corresponding index is necessary for these columns. If an index does not exist, the database will create one for you. These kinds of indexes are called implicit indexes.


Both IDS and DB2 use implicit indexes. If you want to make sure that these implicit indexes are stored in a different table space than the data, you have to create the index manually first before the actual constraint is created. Example 9-12 demonstrates this procedure.

Example 9-12 DB2 index used by a constraint

CREATE TABLE orders (order_num INTEGER NOT NULL,order_date DATE,customer_num INTEGER NOT NULL

);CREATE UNIQUE INDEX pkidx ON orders (order_num);CREATE INDEX fkidx ON orders (customer_num);ALTER TABLE orders

ADD CONSTRAINT pkorders PRIMARY KEY (order_num);

ALTER TABLE ordersADD CONSTRAINT fkorders

FOREIGN (customer_num) REFERENCES customer;

9.1.3 Type I and type II indexesIn the evolution of DB2, the index mechanism has changed. Prior to Version 6 of DB2, only one type of index was used. Version 8.1 of DB2 introduced type II indexes. Type II indexes use a different locking strategy that provides better concurrency and enables you to use columns greater than 255 characters. Type II indexes are needed when using multidimensional clusters (see 9.2.2, “Multidimensional cluster” on page 305) or if you want to perform online index reorganizations.

If you set up DB2 from scratch, you do not need to know about the differences between type I and type II indexes, because every newly created index is a type II index. However, both types can coexist.

The DB2 evolution from type I to type II indexes is very analogous to the index technology change from Informix Online 5.x to Informix Dynamic Server 6 (which is the predecessor to IDS Versions 7 and 9).

9.1.4 Index reorganizationDB2 Version 8.1 introduced online index reorganization. This feature enables you to perform the reorganization of an index even if users are on the system. It is not only possible to run the reorganization continuously online, you can also interrupt it and then continue the process as needed. See Chapter 14, “Administrative operations” on page 419 for further details.


9.1.5 Functional indexesFunctional indexes allow IDS to return function results based on column values very quickly. The result set, which is generated by a function, is virtualized in a temporary table where the engine is able to build an index. The function has to be deterministic (NOT VARIANT); otherwise, an index cannot be built, because the result set is constantly changing. Example 9-13 demonstrates the IDS use of functional indexes.

Example 9-13 IDS use of functional indexes

CREATE TABLE t1 (col1 CHAR (20),col2 INTEGER

);

CREATE FUNCTION halve (in_value FLOAT)RETURNING FLOATWITH (NOT VARIANT);

RETURN in_value / 2;END FUNCTION;

CREATE INDEX func_idx ON t1 (halve (col2));

First, a table is created. Next, a function is created that divides the in_value parameter by two. Finally, an index has been built for the result that is returned by the halve function.

The purpose of the functional index is to omit actual calculation at select. For this example, this might seem trivial, but for more complex calculations, the compute savings could be significant. The rows that match the filter are referenced by the functional index. Of course, the performance advantage is offset by more disk space use.

DB2 does not support functional indexes, but you can emulate the precomputation by using a shadow column that holds the precalculated value. The shadow column uses an auto-generated value that takes the function as a default value. Example 9-14 on page 299 shows an example of how to use auto-generated columns.


Example 9-14 DB2 table with auto-generated shadow column

CREATE TABLE t1 (col1 CHAR (20),col2 INTEGER,col3 INTEGER NOT NULL GENERATED ALWAYS AS (halve (col2))

);

CREATE INDEX t1_col3_idx1 ON t1 (col3);

The optimizer can now access the table through the index on the shadow column if it makes sense to do so. Instead of calling the function in the SQL statement, however, you must address the specific column with the precalculated values directly.

Under special circumstances, you might be also able to use a materialized query table (MQT) to map a functional index to DB2. See 9.2.1, “Materialized query tables” on page 299 for more details.

9.2 Advanced access methodsDB2 provides some unique methods to efficiently fetch data. The methods introduced in this section are particularly appropriate for data warehouses, but they are also useful in OLTP environments. Whether these methods enhance your environment depends on the nature of the queries and the availability of resources.

9.2.1 Materialized query tablesMaterialized query tables (MQTs) or automated summary tables (ASTs) provide a precalculated result of a query.

At first look, an MQT might appear similar to a view. Like views, MQTs are related to a SELECT statement whose result is passed to the caller. Contrary to a view, however, an MQT stores the result of the SELECT statement physically on disk when created; it is not resolved at SELECT time. If an MQT is specified by a client or chosen by the optimizer, the data is not retrieved from the underlying tables. This can accelerate your queries quite a bit, especially if the query that makes up the MQT contains complex and resource-intensive statements. Because the result set that is returned by the MQT is already calculated, no run-time calculations are necessary.

An MQT is represented by a real table, but the optimizer handles MQTs in a special way. Whether an MQT is chosen by the optimizer or not depends on a


few requirements. You should always look at the optimizer explanation to find out what query plan was created (see 9.3, “Optimizer” on page 308).

Creating of materialized query tablesMQTs are created with the general syntax shown in Example 9-15.

Example 9-15 DB2 syntax for creating an MQT

CREATE TABLE <name> AS (SELECT <definition of MQT>

)DATA INITIALLY DEFERREDREFRESH <DEFERRED / IMMEDIATE><ENABLE / DISABLE> QUERY OPTIMIZATIONMAINTAINED BY <SYSTEM / USER>

The following list provides a brief description of the options used in Example 9-15:

� SELECT definition clause: The SELECT statement in the parenthesis makes up the MQT. There are also some SQL statements and features that cannot be used with an MQT, such as:

– References to temporary or typed tables– References to system catalog– DATALINK data type– Large objects– Functions that have EXTERNAL ACTION or are written in SQL

� DATA INITIALLY DEFERRED: When the MQT has just been created, data is not loaded into it. The data is loaded into the MQT by the execution of a REFRESH TABLE command.

� REFRESH: The data stored in the MQT depends on the table or tables that are used within the MQT. Most likely, the data of the base tables is subject to change. The question is when should the changes be reflected in the MQT. The REFRESH option offers the following choices:

– DEFERRED: The data in the MQT is not updated automatically. The update occurs with the execution of a REFRESH TABLE command.

– IMMEDIATE: As soon the data in the base tables changes, the MQT data is also updated.

� QUERY OPTIMIZATION: The query optimization defines how the optimizer can include the MQT for query plan calculations and has the following options:

– ENABLE: This is the default. The optimizer is allowed to use the MQT for query optimization.


– DISABLE: The optimizer is not allowed to use the MQT for query optimization, but the MQT can be used directly for queries.

� MAINTAINED BY: This option identifies the type of modifications allowed on an MQT.

– SYSTEM: This is the default. The MQT data can only be modified by the REFRESH TABLE statement.

– USER: A client is allowed to modify the data of the MQT using DML statements. A REFRESH TABLE command is not permitted against a user-maintained MQT.

Prerequisites for MQTWhether the optimizer chooses an MQT or refers to the base tables depends on a few prerequisites that have to be fulfilled:

� Costs: The optimizer performs an estimation of which is the best way to fetch the data. Even if there is a MQT that seems as though it should be the fastest way to access the data, the optimizer follows its own rules and might elect not to use the MQT. Do not be surprised, however, if costs are less by accessing data through the base tables. However, always look at the query plan.

� QUERY OPTIMIZATION: Make sure that the MQT is created with the query optimization enabled.

� REFRESH AGE: For REFRESH DEFERRED MQTs, the CURRENT REFRESH AGE special register must be set to ANY, as shown in Example 9-16. This setting informs the optimizer that any version of the MQT can be used to determine the answer to the query. The age of the data will not be a concern. REFRESH IMMEDIATE MQTs are always current and are candidates for optimization regardless of the setting of the CURENT REFRESH AGE.

Example 9-16 Changing the refresh age

SET CURRENT REFRESH AGE ANY

� Dynamic SQL: The optimizer will choose an MQT instead of using the base tables only from dynamic SQL statements. Static SQL statements will never be candidates for rerouting to an MQT.

� Optimization class: DB2 supports different levels of optimization aggressiveness. To let the optimizer consider an MQT for a query, the database configuration parameter DFT_QUERYOPT has to be set to 2, 5, 7, or 9. You can also adjust the query optimizer class on transaction level, as shown in Example 9-17 on page 302.


Example 9-17 Changing DB2 query optimization for a single session

SET CURRENT QUERY OPTIMIZATION [2, 5, 7, 9]

MQT routingFigure 9-4 shows the decision tree of the optimizer. The first prerequisite for using an MQT (other than those previously mentioned) is that the optimizer is able to rewrite the query. Query rewriting means that the optimizer has recognized other possible query paths to choose. Even if the optimizer has rewritten the query, it still might not use the MQT if the costs for the query with the MQT is higher than with the base tables.

Figure 9-4 MQT routing

Example 9-18 on page 303 shows the usage of an MQT and how it is chosen by the optimizer. You should compare the Optimized Statement section and the costs of the query plans (“The db2exfmt utility” on page 315 describes the db2exfmt utility). Although the first query must run against the base table (no MQT had been created), the second query (with a FROM clause that specifies the data is to be read from the base table) is rerouted to the MQT. The costs estimated by the optimizer are lower when fetching data from the MQT than those of the base table. The two costs we refer to are in a large, bold (in red if viewed online) font to make it easy to compare the costs.

DB2 Optimizer DB2 Optimizer

DB2 Query Rewrite

Rewrite?

MQT Cheaper?

No

No

Yes

Yes

Base Tables MQT


Example 9-18 Demonstration of MQT and query plan comparison

db2 “CREATE TABLE basetable (col1 INTEGER

)”

# table is populated with 2,046,118 rows

db2 “EXPLAIN PLAN FORSELECT col1, SUM (twice (col1)), COUNT (*)FROM basetableWHERE twice (col1) BETWEEN 1000 AND 1000000 GROUP BY col1 HAVING SUM (twice (col1)) > 10000”

db2exfmt -d ifmx2db2 -1Optimized Statement:-------------------SELECT Q3.$C0 AS "COL1", Q3.$C1, Q3.$C2FROM (SELECT Q2.$C0, SUM("DB2INST2"."TWICE"(Q2.$C0)), COUNT(*) FROM (SELECT Q1.COL1 FROM DB2INST2.BASETABLE AS Q1 WHERE ("DB2INST2"."TWICE"(Q1.COL1) <= 1000000) AND (1000 <= "DB2INST2"."TWICE"(Q1.COL1))) AS Q2 GROUP BY Q2.$C0) AS Q3WHERE (10000 < Q3.$C1)

Access Plan:----------- Total Cost: 18997.2

db2 “CREATE TABLE mqt AS (SELECT col1, SUM (twice (col1)), COUNT (*)FROM basetableWHERE twice (col1) BETWEEN 1000 AND 1000000 GROUP BY col1 HAVING SUM (twice (col1)) > 10000”

)DATA INITIALLY DEFERREDREFRESH DEFERREDENABLE QUERY OPTIMIZATIONMAINTAINED BY SYSTEM;”

# runstats omitted

db2 “REFRESH TABLE mqt”


db2 “EXPLAIN PLAN FORSELECT col1, SUM (twice_col1), COUNT (*)FROM basetableWHERE twice_col1 BETWEEN 1000 AND 1000000GROUP BY col1HAVING SUM (twice_col1) > 10000”

db2exfmt -d ifmx2db2 -1Optimized Statement:-------------------SELECT Q1.COL1 AS "COL1", Q1.TWICE_COL1, Q1.THE_COUNTFROM DB2INST2.MQT AS Q1

Access Plan:----------- Total Cost: 5511.81

MQT refreshingWhen accelerating queries by using MQTs, there are trade-offs. Of course, space is required for the MQT, but another issue is the timeliness of the data. Every time a data row is inserted into one of the base tables, the data in the MQT cannot be refreshed, so it becomes old. Therefore, whether or not using an MQT is acceptable will depend on your business requirements.

There are advanced methods to keep the MQT data up to date, such as using incremental refreshes. To avoid a full refresh of an MQT, you can use the refresh table command, as shown in Example 9-19.

Example 9-19 Refresh table command

REFRESH TABLE <tablename> INCREMENTAL;

DB2 will try to refresh only the differences between base tables and MQT. Refer to IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, for further information.

When to use MQTsThe design of good materialized query tables requires adequate up-front planning and analysis. The designer needs to be familiar with the query workload to identify patterns of table access, aggregation, and summarization.

When deciding whether or not to create a materialized query table, consider the following questions:

� Will the MQT significantly increase performance?


� Will many queries benefit? Will the most frequent or most critical or most expensive and long running queries benefit?

� Will the MQT offer resource savings: communication, I/O, and CPU?

� Is the loss of disk space that will contain the MQT and its indexes a worthwhile trade for the performance that will be gained?

� What is the cost of updating or refreshing the MQT?

� What are the patterns for accessing groups of tables for aggregation and for grouping requirements?

� How current does the data in the MQT need to be? Does it need to be up-to-the-minute?

� For MQTs that are maintained in real time, will automatic updates be too slow?

� In a partitioned environment, will collocation of data provide any benefit?

� What will be the logging requirement when large MQTs are refreshed?

� Should the MQT be system or user maintained?

9.2.2 Multidimensional clusterA multidimensional cluster (MDC) is a technique to group data on disk. Example 9-20 shows the general syntax to create an MDC.

Example 9-20 Syntax to create an MDC

CREATE TABLE <name> (<column_list>

)ORGANIZED BY (<column_list>);

Example 9-20 demonstrates that an MDC is a type of table. The data of the table is physically separated into blocks differentiated by columns defined in the ORGANZED BY clause, called dimensions. The data blocks (dimensions) are indexed using a block index. Every time a query uses one of these dimensions in its WHERE clause (filter), the data can be retrieved using a block index.

MDC separates data depending on a value of a column. The behavior is also seen in IDS when using table fragmentation by expression. In fact, using an MDC is a kind of fragmentation in IDS terms. However, an MDC does not spread the data over several table spaces. The data is organized in blocks within one table space.

If you create an MDC, you should have a special look at the extent sizes that are specified by a table space. The size of an extent equals the size of an MDC


block. There should be enough space within one extent/block to accept all rows that should belong to that block. If a block becomes full, additional blocks are allocated on disk. Ideally, the goal should be to have only one block per data group, but having small number of blocks per group is still acceptable. You should be careful about the number of dimensions you specify, however. As guideline, the more dimensions you have, the smaller the blocks are. The extreme case of this would be if every row is represented by its own block that contains only that row. This scenario should be avoided.

Example 9-21 demonstrates how to create a two-dimensional MDC. The data of the sales table is separated by the dimensions (columns) region and year. Figure 9-5 on page 307 depicts a visualization of that MDC.

A speciality use of MDCs is shown in the second query of Figure 9-5 on page 307. The query uses two dimensions of the MDC in its filter. Here, ANDing of the block indexes is used to retrieve the desired data group. Of course, it is also possible to retrieve the desired data group by using the block index ORing.

Example 9-21 Two-dimensional MDC

CREATE TABLE sales (sales_id INTEGER,sales_rep CHAR (3),region CHAR (1), -- E, N, S or Wyear INTEGER -- 2002, 2003, 2004, ...

)ORGANIZED BY (year, region);


Figure 9-5 Visualization of a two-dimensional MDC

In Example 9-22, we show an example of the syntax of an MDC. It shows that the data of this table is to be organized by three criteria. The data is separated into different blocks divided by year, quarter, and region. The advantage of creating data blocks is that if the query selects data using a filter on the dimensioned columns, a whole block of data can be read from disk. Contrary to a clustered index (see “Clustered index” on page 289), the need for disk-spread will not occur if the blocks are big enough.

Example 9-22 Syntax of a multidimensional cluster

CREATE TABLE sales (order_num INTEGER,customer_num INTEGER,year SMALLINT, -- 2001, 2002, ...quarter CHAR (2), -- Q1, Q2, Q3, Q4region CHAR (1) -- N, S, W, E

ORGANIZE BY DIMENSION (year, quarter, region))

Figure 9-6 on page 308 shows you a visual demonstration of the table created in Example 9-22.

E

N

S

W

{

Block Indexyear dimension

Blo

ck In

dex

regi

on d

imen

sion

2003 20042002

{

SELECT *FROM salesWHERE year = 2004;

SELECT *FROM salesWHERE year = 2002 AND region = ’N’;

Result of query =

Result of query =


Figure 9-6 Block access using a multidimensional cluster

An MDC is administrated by the database engine. It uses a block index to access the data. A block index is a special index of what is contained in each block. However, not every row is recorded within the index, so the index is small. Therefore, index lookups performed with the block index are even faster than regular index lookups.

When using MDCs, regular indexes on the dimension columns or other columns of the table behind them are still allowed and might be necessary. You can create and duplicate an index on the customer_num column, as shown in Example 9-21 on page 306.

9.3 OptimizerThe optimizer is the part of a database engine that is responsible for creating query plans. A query plan describes how to obtain the data from disk, what indexes can be used, and what join method can be employed. If the optimizer comes to a suboptimal decision, a client might experience relatively poor performance.


The optimization process is one of the last elements in a chain of events proceeding actual SQL statement execution. Figure 9-7 on page 310 shows what steps are performed when an SQL statement is submitted by a client to the engine. For a detailed discussion of each step, see IBM DB2 UDB Administration Guide: Performance, SC09-4821.

As with IDS, the DB2 optimizer is a cost-based optimizer. Cost-based optimizers require that you provide the optimizer with accurate statical information. You must run a runstats command (the IDS update statistics command counterpart) to collect these statistics.


Figure 9-7 Steps performed by the SQL compiler

9.3.1 Optimizer analysesOne of the most important parts of performance tuning is to be able to read and understand what query plans the optimizer has created. IDS offers the SET

ExplainTables

ExecutablePlan

VisualExplain

db2exfmtTool

db2explnTool

CheckSemantics

RewriteQuery

PushdownAnalysis

OptimizeAccess Plan

Remote SQLGeneration

GenerateExecutable Code

Execute Plan

Parse Query

SQL Compiler

SQL Query

QueryGraphModel

AccessPlan


EXPLAIN statement or dynamic explain (IDS V9.40) that creates a file (sqexplain.out) where the optimizer information is found.

DB2 has various tools that enable you to analyze query plans generated by the optimizer.

PreparationsIn DB2, before any kind of optimizer analyses can be performed a special set of tables (explain tables) has to be created in each database. You can find the file that holds the necessary DDL to create the explain tables in $INSTHOME/sqllib/misc/EXPLAIN.DDL (see Example 9-23). After the tables have been created, you can proceed with your optimizer analyses.

Example 9-23 Creating the explain tables

$ db2 -tf $INSTHOME/sqllib/misc/EXPLAIN.DDL

******* IMPORTANT **********

USAGE: db2 -tf EXPLAIN.DDL

******* IMPORTANT **********

DB20000I The UPDATE COMMAND OPTIONS command completed successfully.DB20000I The SQL command completed successfully.[...]DB20000I The SQL command completed successfully.

Visual ExplainVisual Explain is part of the DB2 Control Center. This tool lets you enter any SQL statement to be analyzed.To use Visual Explain, perform the following steps:

1. Open Visual Explain. Start the DB2 Control Center, and select Selected → Explain SQL from the menu, as shown in Figure 9-8 on page 312.


Figure 9-8 Open Visual Explain from DB2 Control Center

2. Enter an SQL statement. If you did not establish a connection to a database yet, you must authenticate yourself against the database instance.

After successful authentication, a new window opens, as shown in Figure 9-9 on page 313, and you are able to enter an SQL statement.

In the Explain SQL Statement window, there are four adjustable elements:

– Query number: A query identification number.

– Query tag: This tag is a reference used within the system catalog.

– Optimization class: Set the optimization class for this query. For more details, see 9.3.2, “Optimizer directives” on page 319.

– Populate all columns in Explain tables: Select the Populate all columns in the Explain tables option if you want all the columns of the explain tables to be populated from the dynamic explain; otherwise, only the few columns needed by Visual Explain are populated from the dynamic explain.


In addition, you can open or save a SQL file by clicking the Get and Save buttons, respectively.

Figure 9-9 Explain SQL Statement in Visual Explain (DB2 Control Center)

3. After you enter the SQL statement and set the parameters, click OK to retrieve the graphical presentation of the query plan, as shown in Figure 9-10 on page 314. The colored boxes represent each step in the path that the optimizer has chosen.


Figure 9-10 Query plan generated by Visual Explain

If you are interested in a particular step of the path, simply double-click that box. A detailed explanation of what was done in that step appears in a new window, as shown in Figure 9-11 on page 315.


Figure 9-11 Details of an optimizer step shown by Visual Explain

The db2exfmt utilityTo analyze query plans from the command line, consider the db2exfmt utility. This utility gives you the same information that you get from the Visual Explain tool, but the information is written into a flat file (or standard out).

Before you can start analyzing an SQL statement with the db2exfmt utility, you have to create the SQL explanation first. This is done by prepending the words EXPLAIN PLAN FOR to the actual SQL statement.

The explain file that is generated by the db2exfmt utility contains very detailed information about the steps chosen by the optimizer. You will see that the information is a lot more detailed than the explain file, which is generated by the IDS SET EXPLAIN statement. Most parts in the file are self-explanatory, especially if you are already familiar with terms such as costs or join methods.


For more information about the db2exfmt utility, see IBM DB2 UDB Administration Guide: Performance, SC09-4821.

Example 9-24 demonstrates the whole procedure to create an explain file with the db2exfmt utility.

Example 9-24 Creating an optimizer EXPLAIN with the db2exfmt utility

$ cat orditem.sqlEXPLAIN PLAN FOR SELECT o.order_num, customer_num, order_date FROM orders o, items i WHERE o.order_num = i.order_num ORDER BY ship_date DESC;

$ db2 -tsvf orditem.sqlEXPLAIN PLAN FOR SELECT o.order_num, customer_num, order_date FROM orders o, items i WHERE o.order_num = i.order_num ORDER BY ship_date DESCDB20000I The SQL command completed successfully.

$ db2exfmt -d ifmx2db2 -1 -o orditem.explDB2 Universal Database Version 8.1, 5622-044 (c) Copyright IBM Corp. 1991, 2002Licensed Material - Program Property of IBMIBM DATABASE 2 Explain Table Format ToolConnecting to the Database.Connect to Database Successful.Output is in orditem.expl.Executing Connect Reset -- Connect Reset was Successful.

The db2expln utilityThe purpose of the db2expln utility is primarily to extract query plans from packages. For more information about packages, see 12.3, “Packages” on page 355.

Because the query plans of packages are created at compile time, there is potentially a risk of reduced performance if the query plan is out of date. The db2expln utility is able to analyze the query plan of a package. It also informs you of the isolation level or optimization class of a package.

Example 9-25 on page 317 demonstrates a small ESQL/C application that contains static SQL. The static SQL (line 26) is taken into the bind file and thus optimized at compile time.


Example 9-25 DB2 ESQL/C sample application with a single, static SQL statement

+1 #include <stdio.h>+2 #include <string.h>+3 #include <sql.h>+4+5+6 int main ()+7 {+8 EXEC SQL BEGIN DECLARE SECTION;+9 sqlint32 rowcount;+10 char dbname[9];+11 char uid[9];+12 char pwd[9];+13 EXEC SQL END DECLARE SECTION;+14+15 struct sqlca sqlca;+16+17 rowcount = 0;+18 strcpy (dbname, "ifmx2db2");+19 strcpy (uid, "db2inst2");+20 strcpy (pwd, "idssonstnix");+21+22 printf ("Conneting %s as user %s.\n", dbname, uid);+23 EXEC SQL CONNECT TO :dbname USER :uid USING :pwd;+24+25 EXEC SQL+26 SELECT COUNT (*) INTO :rowcount FROM syscat.tables;+27+28 printf ("syscat.table contains %d rows.\n", rowcount);+29+30 EXEC SQL DISCONNECT ALL;+31 return 0;+32 }

After the application has been precompiled, compiled, and bound to the database, you can run the db2expln utility, as shown in Example 9-26.

Example 9-26 Query plan of package “connect”

db2expln -d ifmx2db2 -schema db2inst2 -package connect

DB2 Universal Database Version 8.1, 5622-044 (c) Copyright IBM Corp. 1991, 2002Licensed Material - Program Property of IBMIBM DB2 Universal Database SQL Explain Tool

DB2 Universal Database Version 8.1, 5622-044 (c) Copyright IBM Corp. 1991, 2002Licensed Material - Program Property of IBMIBM DB2 Universal Database SQL Explain Tool


******************** PACKAGE ***************************************

Package Name = "DB2INST2"."CONNECT" Version = ""

Prep Date = 2004/08/04 Prep Time = 16:08:15

Bind Timestamp = 2004-08-04-16.08.15.320760

Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 9

Partition Parallel = No Intra-Partition Parallel = No

SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "DB2INST2"

-------------------- SECTION ---------------------------------------Section = 1

SQL Statement:

SELECT COUNT (*)INTO :H00001 FROM syscat.tables

Section Code Page = 1252

Estimated Cost = 0.068944Estimated Cardinality = 1.000000

Access Table Name = SYSIBM.SYSTABLES ID = 0,2| Index Scan: Name = SYSIBM.IBM137 ID = 6| | Regular Index (Not Clustered)| | Index Columns:| | | 1: TID (Ascending)| | | 2: FID (Ascending)| #Columns = 0| #Key Columns = 0| | Start Key: Beginning of Index| | Stop Key: End of Index| Index-Only Access| Index Prefetch: None| Lock Intents| | Table: Intent Share| | Row : Next Key Share


| Sargable Index Predicate(s)| | Predicate Aggregation| | | Column Function(s)Aggregation Completion| Column Function(s)Return Data to Application| #Columns = 1

End of section

9.3.2 Optimizer directivesIf you have evaluated your query plans, you might want to advise the optimizer to choose another path. In IDS, you can do this with optimizer directives. The directives are embedded in SQL directly. Another method to let the optimizer choose a different execution path is to change the onconfig parameter OPTCOMPIND.

DB2 does not support optimizer directives. Therefore, you are not able to advise the optimizer what join technique or index is to be used. DB2 has a parameter similar to OPTCOMPIND, however. The database configuration parameter DFT_QUERYOPT defines how aggressively the optimizer behaves. The database configuration parameter sets the default optimization for all queries against that database. See Example 9-27.

Example 9-27 Query optimization database wide

UPDATE DATABASE CFG FOR <dbname> USING DFT_QUERYOPT = [0, 1, 2, 3, 5, 7, 9]

Some queries or sessions might need a higher degree of optimization. Sessions can set their own query optimization levels with the SET CURRENT QUERY OPTIMIZATION SQL command, as shown in Example 9-28.

Example 9-28 Query optimization for a single session

SET CURRENT QUERY OPTIMIZATION = [0, 1, 2, 3, 5, 7, 9]

The higher the value of the optimization classes, the more aggressively the optimizer will proceed.


You can specify one of the following optimizer classes when you compile an SQL query.

Optimization class 0This optimization class has the following characteristics:

� Minimal optimization.� Non-uniform distribution statistics are not considered by the optimizer. � Only basic query rewrite rules are applied. � Greedy join enumeration occurs. � Only nested loop join and index scan access methods are enabled. � List prefetch and index ANDing are not used in generated access methods. � The star-join strategy is not considered.

This class should only be used in circumstances that require the lowest possible query compilation overhead. Query optimization class 0 is appropriate for an application that consists entirely of very simple dynamic SQL statements that access well-indexed tables.

Optimization class 1This optimization class has the following characteristics:

� Non-uniform distribution statistics are not considered by the optimizer. � Only a subset of the query rewrite rules are applied. � Greedy join enumeration occurs. � List prefetch and index ANDing are not used in generated access methods

although index ANDing is still used when working with the semi-joins used in star-joins.

Optimization class 1 is similar to class 0 except that merge scan joins and table scans are also available.

Optimization class 2This class directs the optimizer to use a degree of optimization significantly higher than class 1, while keeping the compilation cost significantly lower than

Note: The SET CURRENT QUERY OPTIMIZATION statement only affects dynamic SQL (see 12.3.1, “Static and dynamic SQL” on page 356).

To specify an optimization level for static SQL, you must pass it to the BIND statement at bind time in the QUERYOPT parameter (see 12.3.2, “Bind” on page 358).


classes 3 and above for complex queries. This optimization class has the following characteristics:

� All available statistics, including both frequency and quantile non-uniform distribution statistics, are used.

� All query rewrite rules are applied, including routing queries to materialized query tables, except computationally intensive rules that are applicable only in very rare cases.

� Greedy join enumeration is used. � A wide range of access methods are considered, including list prefetch and

materialized query table routing. � The star-join strategy is considered, if applicable.

Optimization class 2 is similar to class 5 except that it uses Greedy join enumeration instead of dynamic programming. This class has the most optimization of all classes that use the Greedy join enumeration algorithm, which considers fewer alternatives for complex queries, and therefore consumes less compilation time than classes 3 and above. We recommend class 2 for very complex queries in a decision support or online analytic processing (OLAP) environment. In such environments, specific queries are rarely repeated exactly, so a query access plan is unlikely to remain in the cache until the next occurrence of the query.

Optimization class 3This class requests a moderate amount of optimization. This class comes closest to matching the query optimization characteristics of DB2 for MVS/ESA™, OS/390, or z/OS. This optimization class has the following characteristics:

� Non-uniform distribution statistics, which track frequently occurring values, are used if available.

� Most query rewrite rules are applied, including subquery-to-join transformations.

� Dynamic programming join enumeration, as follows: – Limited use of composite inner tables – Limited use of Cartesian products for star schemas involving lookup tables

� A wide range of access methods are considered, including list prefetch, index ANDing, and star joins.

This class is suitable for a wide range of applications. This class improves access plans for queries with four or more joins. However, the optimizer might fail to consider a better plan that might be chosen with the default optimization class.


Optimization class 5This class directs the optimizer to use a significant amount of optimization to generate an access plan. This optimization class has the following characteristics:

� All available statistics are used, including both frequency and quantile distribution statistics.

� All of the query rewrite rules are applied, including the routing of queries to materialized query tables, except for those computationally intensive rules that are applicable only in very rare cases.

� Dynamic programming join enumeration, as follows: – Limited use of composite inner tables – Limited use of Cartesian products for star schemas involving lookup tables

� A wide range of access methods are considered, including list prefetch, index ANDing, and materialized query table routing.

When the optimizer detects that the additional resources and processing time are not warranted for complex dynamic SQL queries, optimization is reduced. The extent or size of the reduction depends on the machine size and the number of predicates.

When the query optimizer reduces the amount of query optimization, it continues to apply all the query rewrite rules that would normally be applied. However, it does use the Greedy join enumeration method and reduces the number of access plan combinations that are considered.

Query optimization class 5 is an excellent choice for a mixed environment consisting of both transactions and complex queries. This optimization class is designed to apply the most valuable query transformations and other query optimization techniques in an efficient manner.

Optimization class 7This class directs the optimizer to use a significant amount of optimization to generate an access plan. It is the same as query optimization class 5 except that it does not reduce the amount of query optimization for complex dynamic SQL queries.

Optimization class 9This class directs the optimizer to use all available optimization techniques. These include:

� All available statistics � All query rewrite rules � All possibilities for join enumerations, including Cartesian products and

unlimited composite inners


� All access methods

This class can greatly expand the number of possible access plans that are considered by the optimizer. You might use this class to find out whether more comprehensive optimization would generate a better access plan for very complex and very long-running queries that use large tables. Use Explain and performance measurements to verify that a better plan has actually been found.

Figure 9-12 shows the impact on the query plan using different optimization classes.

Figure 9-12 Query plans with optimization classes 0 and 5

Optimization class 0

Optimization class 5


Chapter 10. Data types

In this chapter, we discuss data type issues. Although IDS and DB2 support the same types of data in general terms, each has particulars specific to the implementation. Most of these particulars are internal and will not overtly affect your application. However, some of them certainly can if you use them. This chapter will make you aware of these potential issues.

10


10.1 Object namesVersion 9 of IDS has support for long object names. The implementation of long object names is such that you can use long names for any type of database object name. DB2 supports long names for some objects, but not all. See Table 10-1.

If you were using Version 7 of IDS and upgraded to Version 9 of IDS and have not taken advantage of long object names, or you are currently using Version 7 of IDS now, you should not encounter problems in this area.

Table 10-1 Maximum object name lengths

If you used long object names in IDS, when moving to DB2, you must physically shorten the object names in the DDL. Even if the first n characters of the object

Object type IDS Version 9 DB2 Version 8.2

User 32 30

Constraint name 128 18

Correlation name 128 128

Cursor name 128 18

Host identifier 128 255

Schema name 32 30

Database name 128 8

Statement name 128 18

Column name 128 30

Table name 128 128

View name 128 128

Stored procedure name 128 128

Synonym/alias 128 128

User-defined type 128 18

User-defined function 128 18

Tablespace/dbpace name 128 18

Trigger 128 18

Index name 128 18


name are unique, the DB2 command line processor will not accept more than the maximum.

10.2 Data type mappingTable 10-2 shows equivalent data types in IDS and DB2.

Table 10-2 IDS and DB2 data type mapping

IDS data type Space requirement

DB2 data type Space requirement

CHAR(n) n<=32,767 CHAR(n)VARCHAR(n)LONG VARCHAR(n)

n<=254n<=32,672n<=32,700

VARCHAR(255) 1 byte per row overhead

VARCHAR(32,672) 4 byte overhead, 2 with value compression

LVARCHAR(2000) 1 byte per row overhead

VARCHAR(32,672) 4 byte overhead, 2 with value compression

NCHAR(n) GRAPHIC(127) Up to 127, 2 byte characters. <=254 bytes total. Long vargraphic also available.

TEXT Up to 2 GB CLOB(2GB)VARCHAR(32,672) LONG VARCHAR(32,700)

CLOB Up to 4 TB CLOB Up to 2 GB

INTEGER,INT 4 bytes INTEGER, INT 4 bytes

INT8 10 bytes BIGINT 8 bytes

SMALLINT 2 bytes SMALLINT 2 bytes

DECIMAL(p,s), DEC(p,s)p<= 32 digits

s is odd: (p+4)/2s is even (p+3)/2

DEC(p,s), DECIMAL(p,s) p <= 31 digits

p/2+1

Chapter 10. Data types 327

COLLECTIONS Varies Not applicable. See Chapter 11, “Extensibility” on page 343.

DECIMAL(p) See FLOAT FLOAT 8 bytes

FLOAT 8 FLOAT 8 bytes

SMALLFLOAT 4 REAL 4 bytes

DOUBLE PRECISION

8 DOUBLE PRECISION

8 bytes

MONEY Like DECIMAL(16,2)

DEC(p,s), DECIMAL(p,s) p <= 31 digits

p/2+1

BYTE Up to 2 GB BLOB(n) VARCHAR for bit dataLONG VARCHAR for bit data

Up to 2 GB

BOOLEAN 1 byte Use CHAR(1) or SMALLINT

DATETIME(depends on precision length) (YYYY-MM-DD HH:MM:SS.nnnnn)

(total digits)/2+1 DATETIMETIMESTAMP (YYYY-MM-DD-HH.MM.SS.nnnnnn)

TIMESTAMP 10 bytes

DATE 4 DATE (MM/DD/YYYY- USA)

4 bytes

DATETIME (hours to secs)

(total digits)/2+1 TIME 8 bytes

SERIALSERIAL8

4 or 10 bytes INTEGER with IDENTITY* BIGINT with IDENTITY

4 or 8 bytes

INTERVAL (total digits)/2+1 DECIMAL See “INTERVAL” on page 337.

IDS data type Space requirement

DB2 data type Space requirement


10.3 Disk considerationsDB2 supports 4 KB, 8 KB, 16 KB, and 32 KB page sizes. Table limits are determined based on the page size, as shown in Table 10-3. For a full list of limits in DB2, see “Appendix A. SQL Limits” in IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845.

Table 10-3 Maximums per page size

10.4 Character typesIn this section, we discuss the various character types supported and provide descriptions.

10.4.1 TruncationIn IDS log mode ANSI databases and in DB2, when an inserted value exceeds the maximum length of column, an error is returned: Truncation is not supported. For IDS logged, non-mode ANSI databases and unlogged databases, truncation automatically occurs if an inserted value exceeds the maximum, and no error is returned.

Table limits 4 KB page 8 KB page 16 KB page 32 KB page

Maximum length of a row including all overhead

4005 8101 16,293 32,677

Most columns in a table 500 1012 1012 1012

Maximum size of a table (per partition)

64 GB 128 GB 256 GB 512 GB

Maximum size of index (per partition)

64 GB 128 GB 256 GB 512 GB

Maximum size of a DMS table space

64 GB 128 GB 256 GB 512 GB

Most elements in a SELECT list

500 1012 1012 1012

Maximum index key length

1024 1024 1024 1024

Most columns in an index key

16 16 16 16


It is possible that your IDS application uses host variables that are of generic size and no checking is done for size limits. For these applications, you might see an increase in INSERT/UPDATE failure, because the application might be attempting to process strings that are too long.

10.4.2 NCHARAlthough the NCHAR data type maps to the DB2 GRAPHIC data type, there are storage differences.

The IDS NCHAR data type can be used for single-byte or double-byte characters. IDS uses the codepage to determine if the NCHAR string is required to store single-byte or double-byte data. NCHAR columns that store single-byte data will use less disk space than NCHAR columns that store double-byte data.

With the DB2 GRAPHIC data type, DB2 always assumes the data is double byte and thus allocates double the length specified.

If your IDS database has been defined with NCHAR columns, but you are not using the NLS functionality, you might investigate moving to a DB2 CHAR or VARCHAR to avoid the extra disk consumption.

10.4.3 VARCHARIDS allows specification of minimum preallocated space for VARCHARs with a reserve parameter:

CREATE TABLE spoonman (c1 VARCHAR(max,reserve))

The reserve signals IDS to reserve a certain amount space for VARCHAR columns when rows are INSERTed. Even if the value for that column is null, or its length is less than the reserve, the reserve space is still allocated. This is useful for when columns are initially INSERTed empty, but UPDATEd later. Having the

Tip: Unless you have been using the IDS log mode ANSI database, a change in character truncation might have significant application ramifications.

Tip: If your application does not check for failed INSERT/UPDATE errors, you might experience truncation failures and might not be aware of it. You might be losing data.

Tip: If your IDS application stores single-byte characters in NCHAR columns, with DB2 VARGRAPHIC, your disk space requirements will double.


reserve allows the row to stay in place and avoid row chaining with a forward pointer.

DB2 does not support preallocation of space for VARCHARs, and thus the two-parameter declaration is not supported. Also, DB2 does not use row chaining, but instead uses a system of variable page size to accommodate larger rows. See 4.5, “Configuring the instance” on page 101.

10.4.4 TEXTThe IDS TEXT data type contains only printable characters. One possible character contained within a TEXT value might be a carriage return character.

The DB2 load utility, by default, uses a carriage return as a row delimiter. Therefore, when moving IDS TEXT data with imbedded carriage returns to DB2 VARCHAR, multiple rows might result, because the DB2 load utility assumes the carriage returns are row delimiters.

To resolve this situation, set the delprioritychar file type modifier on the load command to change the priority from row delimiter to character delimiter. When doing this, if a row delimiter is found within a character stream, the character stream delimiter will take priority over the row delimiter, thus not splitting the row.

10.5 Numerical typesBoth IDS and DB2 support the basic numerical data types. There are differences, however, in specialized numerical types and the detailed handling of all these types.

10.5.1 Numerical limitsTable 10-4 on page 332 shows the numerical limits for IDS and DB2. In most cases, these limits are identical or off by small amounts because of implementation differences.

Tip: In DB2, VARCHAR types are the only types that you can alter with the ALTER command.


Table 10-4 Database numerical limits

10.5.2 DECIMALThe IDS DECIMAL data type has a maximum precision of 32. The DB2 DECIMAL data type has a maximum precision of 31. IDS and DB2 have some significant differences regarding the default scale and rounding that you should note.

In IDS, if a column is declared as a DECIMAL, with no precision and scale, it defaults to a precision of 16. DB2 defaults to 5. When moving to DB2, you should take care to specify a DECIMAL precision. Doing so will guarantee that your existing data will fit.

It is a good idea to specify the precision of your DECIMAL data types.

Data type IDS limit DB2 limit

Smallest INTEGER -2 147 483 647 -2 147 483 648

Largest INTEGER +2 147 483 647 +2 147 483 647

Smallest BIGINT -9 223 372 036 854 775 807

-9 223 372 036 854 775 808

Largest BIGINT 9 223 372 036 854 775 807 +9 223 372 036 854 775 807

Smallest SMALLINT -32 767 -32 768

Largest SMALLINT +32 767 +32 767

Largest decimal precision (p)

32 31

Largest/Smallest DOUBLE value

17 significant digits, floating point, based on hardware limits

+/- 1.79769E+308

Smallest positive/negative DOUBLE value

17 significant digits, floating point, based on hardware C double

+/-2.225E-307

Largest/Smallest REAL value

Approximately 9 significant digits, floating point, based on hardware C float

+/-3.402E+38

Smallest positive/negative REAL value

Approximately 9 significant digits, floating point, based on hardware C float

+/-1.175E-37


In IDS, a DECIMAL data type without a scale such as DEC(9) is represented internally as a FLOAT. In DB2, a DECIMAL data type specified with a precision but without a scale, defaults to DEC(9,0), which is not a floating point number. If your application is using the IDS floating point behavior, make sure to convert to a floating point number or specify a specific scale for the DECIMAL column.

In IDS, when a value of 123.456 is inserted into a DEC(3,2) column, IDS rounds the second decimal place value and stores 123.46. In DB2, when a value of 123.456 is inserted into a DEC(3,2) column, DB2 truncates the second decimal place value and stores 123.45. Obviously, this can have significant implications on monetary or financial applications, or both.

10.5.3 MONEY Internally, IDS supports the MONEY data type with a DECIMAL data type. However, a column defined as MONEY(n) (with no scale) maps to a default scale of 2, in effect, a DEC(16,2). As discussed 10.5.2, “DECIMAL” on page 332, in DB2, a DEC(n) (with no scale) defaults to a scale of 0, not a floating point number. For this reason, users with columns defined as MONEY(n) (with no scale) should take care to add a scale of 2 when changing this to a decimal definition, DEC(n,2).

The prominent feature of the IDS MONEY data type is that it provides automatic handling of currency symbols and formatting and is integrated with locales. If this functionality is required in DB2, you can create a user-defined type named MONEY and provide the associated user-defined functions to generate appropriate formatting.

10.5.4 SERIAL and SERIAL8The SERIAL data type can map to DB2 by using a numeric data type with the IDENTITY column attribute. IDENTITY can be used with SMALLINT, INTEGER, BIGINT, and DECIMAL. When defining a column as IDENTITY, unique, sequential numeric values will be generated for every row that is inserted.

The IDS SERIAL data type has several specific behaviors that can be duplicated in DB2:

� In IDS, if you insert a row to a table with a SERIAL column, but do not address the SERIAL column in the column and value lists, IDS will still assign a SERIAL value for you:

CREATE TABLE t(id SERIAL,c1 CHAR(20))

Tip: For DECIMAL types, IDS rounds, while DB2 truncates.


In the following example, IDS will generate a SERIAL value for the column id, even though id was not mentioned in the column and value lists:

INSERT INTO t (c1) VALUES (“Phil White”)

In DB2, use the GENERATED BY DEFAULT syntax along with the IDENTITY definition. DB2 will generate a value for the column unless a value is explicitly provided for the column either by INSERT or LOAD:

CREATE TABLE t(id INTEGER GENERATED BY DEFAULT AS IDENTITY,c1 CHAR(20))

In the following example, as in IDS, the system will generate an IDENTITY value for the column id, even though id was not mentioned in the column and value lists:

INSERT INTO t (c1) VALUES (“Phil White”)

� In IDS, if you insert a row and supply a value of 0 for the SERIAL column as a placeholder, IDS will still generate a sequential number.

INSERT INTO t VALUES(0, “John Galt”)

In DB2, use the wording DEFAULT instead:

INSERT INTO t VALUES(DEFAULT, “John Galt”)

� As with IDS, you can specify the starting value for the IDENTITY column:

CREATE TABLE t (id INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1), c1 CHAR(20))

� In most cases, IDS users have UNIQUE indexes defined on SERIAL columns, although uniqueness is not required. This is also the case with DB2.

� IDS uses an internal counter to track the next SERIAL number assigned. Unless otherwise specified, this is always one more than the last value assigned. If the last row assigned skipped values, the next row will still go to the next value. In most cases, this could cause a gap in serial values.

CREATE TABLE t(id SERIAL,c1 CHAR(20))INSERT INTO t VALUES (0,"Alex”) -- id column l be assigned 1INSERT INTO t VALUES (5,”Geddy”) --id column will be assigned 5INSERT INTO t VALUES (0,”Niel”) --id column will be assinged 6

In DB2, you have more control over a similar, internal counter, but the counter must be set manually with the RESTART command:

CREATE TABLE t (id INTEGER GENERATED BY DEFAULT AS IDENTITY, c1 CHAR(20));INSERT INTO t VALUES (DEFAULT,’Alex’) --id column will be assigned 1INSERT INTO t VALUES (5,’Geddy’) --id column will be assinged 5INSERT INTO t VALUES (DEFAULT,’Niel’) --id column will be assigned 2ALTER TABLE t ALTER id RESTART WITH 6--internal counter = 6INSERT INTO t VALUES (DEFAULT,’Tom’) --id column will be assigned 6


� In IDS programming, the SQLCA record, the SQL Communications Access record, contains information from IDS about the last SQL statement executed by a program. After an INSERT, to programmatically obtain the value assigned to a SERIAL column, the program would simply look at the SQLCA record at some point after executing the table INSERT in question, but before executing some other SQL statement. As long as the program checks the SQLCA record prior to executing further SQL, the SQLCA will still contain the assigned value:

$INSERT INTO experts(lname) VALUES (“Scranton”);.../* other program logic here, no SQL though */...x=sqlca.sqlerrd[1];

In DB2 use the IDENTITY_VAL_LOCAL built-in function. Its usage is more analogous to using the IDS dbinfo function. The IDENTITY_VAL_LOCAL function returns the most recently assigned value for an identity column, where the assignment occurred as a result of a single row INSERT statement using a VALUES clause. Note that the IDENTITY_VAL_LOCAL results can be affected by other events, especially triggers. If you are transitioning from IDS using SQLCA, we highly recommend that you consult the DB2 manuals regarding the exact behavior of IDENTITY_VAL_LOCAL.

10.6 Date and time typesDATE is a basic type in both IDS and DB2. The two RDBMs, however, have different implementations concerning the storage of time and date plus time.

Refer to the following URL for a short article intended for those who are new to DB2 and want to understand how to manipulate dates and times:

http://www7b.software.ibm.com/dmdd/library/techarticle/0211yip/0211yip3.html

10.6.1 DATEDB2 supports many formats for DATEs. It supports ISO, EUR, USA, and JIS formats. Dates can be input with any of the four formats. The default format is USA format, but this can be determined by the date format defined at installation time.

Tip: DB2 supports entry of dates in four-digit year format only. There is no default century functionality as provided by IDS DBCENTURY.



10.6.2 DATETIME, TIME, and TIMESTAMPFor storing date plus time values or just time values, IDS uses one data type, DATETIME. The precision of what is stored is defined by qualifiers. Example 10-1 shows examples of various IDS DATETIME definitions with qualifiers.

Example 10-1 IDS DATETIME definitions

DATETIME HOUR TO SECOND(5) DATETIME YEAR TO DAYDATETIME YEAR TO SECOND(2)

In DB2, there is not one, single counterpart data type to the IDS DATETIME data type. While IDS uses one configurable type, DB2 uses two predefined types: TIME and TIMESTAMP. These types are of fixed units, and you cannot reduce precision.

If you are using an IDS DATETIME YEAR TO DAY, the DB2 DATE format might be the most analogous data type to use. You might consider moving to a DATE rather than a TIMESTAMP.

If using the DB2 load utility to load IDS time stamps, you can set the dateformat or timestamp format file type modifier to specify the format of the incoming date or datetime values. By doing this, DB2 can translate the input values into formats that it can load.

If you are using IDS DATETIME with qualifiers that are a subset of a full time stamp, for example, MONTH TO HOUR, you have several options, all of which might have impact on application handling and disk storage requirements:

� Expand to full TIMESTAMP. You might decide to expand the time you track to the full time stamp, including the entire date and the entire time. As in the MONTH TO HOUR example, this would mean tracking years, minutes, and seconds in addition to what is already there. This would have an impact on loading your existing IDS data into DB2, because you would have to provide additional information prior to insertion. You would have to generate or assign year information for existing data. Minutes and seconds could be assigned 0.

� Use a character string. If you are storing a subset of a full time stamp and do not want to expand to a full time stamp, you could choose to store the information in a character string. This might be acceptable if you do not manipulate dates and do not require use of date-based, built-in functions.

� Create a user-defined type. This could be a user-defined type that is derived from the base TIMESTAMP date type, but that provides for input and output of a TIMESTAMP subset.


In DB2, when inserting data into a TIMESTAMP column, specifying all 6 microseconds is not required. At a minimum, YYYY-MM-DD HH.MM.SS must be specified. When retrieving dates, the format is the default format that is specified at installation time. This format can be temporarily overridden for specific SQL statements in several ways:

� Using the CHAR function

This example shows how a default ISO date format can be converted to the USA format:

SELECT empno, CHAR(hiredate, USA) FROM emp

� Using DB2 built-in date and time arithmetic and casting

This example shows the use of the DAYS built-in function to convert a date into days:

SELECT * FROM orders WHERE DAYS(ship_date) – DAYS(order_date) > 5

10.6.3 INTERVAL IDS offers an INTERVAL data type that represents a span of time. The INTERVAL data type supports input and output of intervals as character strings. INTERVALS, however, are internally stored as decimal numbers; therefore, they are best mapped to a DB2 DECIMAL type. DB2 does not support an INTERVAL data type.

Example 10-2 shows an example of an IDS INTERVAL data type.

Example 10-2 IDS INTERVAL

INTERVAL(123456 13:07:56) DAY(6) TO SECOND

This value is stored in the IDS database as the decimal number 123456130756, where the digits are the various components of INTERVAL.

You might want to examine how the MTK translates IDS INTERVAL values. When using the MTK to transition INTERVALs to DECIMAL, the MTK normalizes the internal representation to a total number of seconds value. Therefore, the DB2 value in seconds for the above example is:

123456*86400 + 13*3600 +7*60 +56

Example 10-3 on page 338 shows an example of how this type of translation would affect an INTERVAL DEFAULT.


Example 10-3 IDS and DB2 INTERVAL with DEFAULT

(IDS) CREATE TABLE t(i INTERVAL DAY (6) TO SECOND DEFAULT INTERVAL (2 0:0:56) DAY (6) TO SECOND NOT NULL)(DB2)CREATE TABLE t(i DECIMAL (20,5) DEFAULT 172856 NOT NULL)

The IDS INTERVAL data type not only provides storage for intervals but also special character string input and output support for intervals. This might impact your application.

DB2 does provide wording to support interval manipulation of dates and times in SQL, for example:

SELECT col1 FROM tab1 WHERE CURRENT DATE < (date1 + 10 YEARS)

10.7 LOB data typesIDS uses TEXT, BYTE, BLOB, and CLOB data types for large character and binary data. DB2 has comparable data types, CLOB(n) and BLOB(n). Unlike IDS, DB2 requires that the maximum length for the CLOB or BLOB value be specified when the column is defined; n must be specified. The maximum length of the DB2 CLOB and BLOB data types are 2 GB.

10.8 BOOLEANIDS BOOLEAN data types are not supported by DB2. You could convert BOOLEAN data types to CHAR(1) or SMALLINT and use values to flag true and false conditions. We recommend that you create a check constraint on these columns to ensure consistent domains, either T and F or 1 and 0.

10.9 CollectionsIDS supports several data types that are considered collections. This includes sets, multisets, and lists. These data types allow the storage of multiple items within a row.

DB2 does not support collections. Customers requiring lists associated with rows should consider creating lookup tables with appropriately defined referential integrity relationships.


See also Chapter 11, “Extensibility” on page 343.

10.10 SEQUENCE objectsSEQUENCE objects are new in IDS V9.40. Unlike SERIAL data types that generate a sequence of numbers for a table, a SEQUENCE is independent of a table and rows in a table. Both IDS and DB2 support SEQUENCES although there are some differences in the implementations (see Example 10-4):

� The syntax of the CREATE SEQUENCE statement is nearly identical in IDS and DB2. The only exception is that IDS specifies the attributes NOCYCLE, NOORDER, and NOCACHE as a single key word, while the same attributes in DB2 are two words separated by a space, NO CYCLE, NO ORDER, and NO CACHE.

� The syntax to drop a sequence in DB2 is DROP SEQUENCE <sequence name> RESTRICT. The RESTRICT keyword is not used in IDS.

� In both IDS and DB2, a reference to the NEXTVAL of a sequence increments the sequence and returns that new value. Multiple references to NEXTVAL in the same statement all return the same value.

� IDS supports CURRVAL and NEXTVAL, while DB2 supports PREVVAL and NEXTVAL. IDS uses CURRVAL as a way of obtaining the most recently generated sequence value without causing a new value to be generated. In DB2, PREVVAL returns the sequence value from the previous successful NEXTVAL reference.

� References to NEXTVAL and CURRVAL in IDS have the form “sequence_name.NEXTVAL” (or CURRVAL). The DB2 equivalent is “NEXTVAL FOR sequence_name” (or PREVVAL FOR sequence_name).

Example 10-4 SEQUENCE

For IDS and DB2:create table dept (deptno smallint not null, deptname varchar(36) not null, mgrno char(6), admrdept smallint not null,llocation char(30));create sequence dept_seq start with 500 increment by 1 cache 20;

For IDS:insert into dept values(dept_seq.nextval,'SALES',‘Eddie',50,'Downtown');insert into dept values(dept_seq.nextval,'MARKETING','Alex',100,'Midtown');insert into dept values(dept_seq.nextval,'ACCOUNTING','Sammy',150,'Uptown');

For DB2:insert into dept values (nextval for dept_seq,'SALES','Eddie',50,'Downtown');insert into dept values (nextval for dept_seq,'MARKETING','Alex',100,'Midtown');


insert into dept values (nextval for dept_seq,'ACCOUNTING','Sammy',150,'Uptown');

For IDS and DB2:select * from dept order by deptno;

deptno 500deptname SALESmgrno Eddieadmrdept 50location Downtown

deptno 501deptname MARKETINGmgrno Alexadmrdept 100location Midtown

deptno 502deptname ACCOUNTINGmgrno Sammyadmrdept 150location Uptown

10.11 NULL valuesIn Table 10-4 on page 332, as in most cases, the IDS limit values are one less, because IDS internally uses the extreme largest and smallest values to track NULL conditions.

DB2 uses an extra byte of storage for a NULL indicator. In DB2, for each column defined with a NOT NULL constraint, one extra byte of storage is required. If you have a large table, with a large number of columns with NOT NULL constraints defined, the impact of this extra byte could be significant. You should factor this in when planning storage.

Aside from internal storage, IDS and DB2 manipulate NULL values the same way. The presence of NULL values in columns affects joins and arithmetic (that is, the results of a calculation with a NULL value is NULL).

10.12 FLOATBoth IDS and DB2 support a FLOAT data type. There are, however, differences.


The IDS FLOAT data type stores double-precision floating point numbers with up to 16 significant digits. When declared FLOAT(n), the value of n must be a whole number between 1 and 14 to specify precision.

The DB2 FLOAT data type is either single-precision or double-precision depending on the integer value specified when defining the column. The value of the integer is 1 to 53, with 1 through 14 specifying single-precision and 25 through 53 indicating double-precision. DB2 will also accept REAL for single-precision and both DOUBLE and DOUBLE-PRECISION to define double-precision.

10.13 REAL or SMALLFLOATIDS implements REAL as a synonym for SMALLFLOAT. SMALLFLOAT stores single-precision floating point numbers with eight significant digits. This data type can be mapped to the DB2 data type FLOAT(8).

10.14 LimitsIn Table 10-5, we provide a chart of miscellaneous limits in DB2.

Table 10-5 DB2 limits

Limit Value

Longest SQL statement length, in bytes 65,535

Longest authorization name (can only be single-byte characters)

30

Longest constraint name 18

Longest correlation name 128

Longest condition name 64

Longest cursor name 18

Longest external program name 8

Longest host identifier 255

Longest schema name 30

Longest server (database alias) name 8

Longest statement name 18


Longest unqualified column name 30

Longest unqualified package name 8

Longest unqualified table name, view name, stored procedure name, nickname, or alias

28

Longest unqualified user-defined type, user-defined function, buffer pool, table space, node group, trigger, or index name

18

Limit Value


Chapter 11. Extensibility

In this chapter, we provide a very high-level overview of some of the extensibility capabilities of IDS and DB2. We discuss type mappings, function mappings, available DataBlades, and further resources.

11


11.1 IntroductionBoth IDS and DB2 have their origins as relational databases. Relational databases store related data as columns and rows in tables with relationships defined between the tables, thus the term relational database.

In the late 1990s, commercial databases were augmented with some of the characteristics of object-oriented databases, creating what are termed object-relational databases. Both IDS and DB2 are object-relational databases. This technology is sometimes also referred to as extensibility because it extends the functionality of the relational database.

The majority of both IDS and DB2 customers have not deployed a custom usage of extensibility. Most customer implementations are of vendor-supplied extensibility packages (IDS DataBlades and DB2 Extenders). Extensibility technology is often positioned as technology just for handling multimedia and Web data, although it is much more powerful than just that.

It is beyond the scope of this book to deliver an in-depth analysis of transitioning specific object-relational features. We have, however, included a feature mapping of the technology and a list of analogous DataBlades and Extenders.

11.2 Understanding extensibilityDatabase extensibility can provide a business advantage to people who know how to use it. The key is to find out how to adapt the database to fit your solution instead of compromising your design to fit the database.

Stored procedures, triggers, and check constraints are forms of extensibility, because they add processing power to the database engine. The object-relational model adds capabilities for new types and new functions among other things. You can extend the power of SQL by providing new ways to sort, group, and compare data. Here are four major benefits you are looking for when using extensibility:

� Eliminate large data transfer

� Simplify or improve processing

� Provide common business processing to multiple applications

� Eliminate the need to develop custom user interfaces

In 11.6, “Other resources” on page 349, we provide a list of book references and example code that can help you better understand how to take advantage of database extensibility and give your company a business advantage.


11.3 Feature mappingBoth IDS and DB2 are powerful implementations of object-relational technology. DB2 supports most of the capabilities of IDS and visa versa. There are some exceptions, however. The following tables show functional comparisons.

Table 11-1 shows the user-defined types available.

Table 11-1 Types

IDS DB2

Named row typeInheritance: yes

Structured typeInheritance: yes

Column typeInheritance: no

Column typeInheritance: yes

Table typeInheritance: yesDispatch: dynamicOIDs: noREF/DEREF: no

Table typeInheritance: yesDispatch: staticOIDs: yesREF/DEREF: yes

Unnamed row type: no Unnamed row type: yes

Distinct type: yes Distinct type: yes

Opaque type: yes Opaque type: not available, best emulated with DB2 distinct type of VARCHAR FOR BIT DATA or BLOB

Federated type mapping: no Federated type mapping: yes

Multirep: yes Multirep: yes

Set: yes Set: no

Multiset: yes Multiset: no

List: yes List: no

Chapter 11. Extensibility 345

Table 11-2 shows the user-defined function capabilities available in IDS and DB2.

Table 11-2 Functions

Table 11-3 shows the capabilities of IDS and DB2 regarding indexing.

Table 11-3 Indexing

IDS DB2

User-defined functions and routinesScalarIterator

User-defined functionsScalar functionsTable functions

Iterator functions Table functions

Overload standard aggregation by overloading standard math and comparison operators

No

User-defined aggregates on distinct, opaque, and row types

No

Function overloading: yes Function overloading: yes

Procedure overloading: yes Procedure overloading: yes (only by number of arguments, not by type)

Cast: yes Cast: yes

IDS DB2

B-tree: yes B-tree: yes

Virtual index interface: yes Virtual index interface: no

R-tree: yes R-tree: no, use Grid

Functional index: yes Functional index: no(Consider using DB2 automatic summary tables.)

Gist: yes Gist: no


Finally, in Table 11-4, we present the access methods used by DB2 and IDS.

Table 11-4 Access methods

11.4 TerminologyIn this section, we discuss the terminology used with DB2 and IDS.

11.4.1 IDSThe following list defines some of the IDS terms used:

Opaque A type implemented as a C structure and a set of C routines that allow the database server to support the type. It is an encapsulated data type that is not based on an IDS built-in data type and thus cannot be supported by native database code. Similar to a C++ class.

Distinct type A user-defined data type that is based on a built-in IDS data type. Similar to the DB2 user-defined distinct data type.

Collection A group of elements of the same type stored and manipulated within a single row.

Row type A group of fields that are defined under a single type. Can be assigned to a table or column. Similar to the DB2 structured types for table and columns.

SIMPLE LOB TEXT and BYTE up to 2 GB in size. Does not support random access to the data or partial transfer. Stored in BLOB spaces.

SMART LOB CLOB and BLOB. Allows seek, read from, and write to segments of the object. Stored in sbspaces. APIs are provided with ESQL/C for access of SMART objects.

IDS DB2

Virtual table interface Yes No(Some SELECT behavior might be achievable using DB2 table functions.)

Virtual index interface Yes No


User-defined functions and routinesA callable section of code that is registered to the database and is written in SPL, C or Java. Can be invoked from an SQL statement or another routine.

DataBlade™ modules A packaging of user-defined types and routines that operate upon those types. DataBlade modules are installed and registered with the database.

11.4.2 DB2The following list defines some of the DB2 terms used:

Structured type Stored as a row in a table. Similar to the IDS row type.

Structured type columns A column with a hierarchical structure containing one or more sub-attributes, each of which contains a name and data type of its own.

Typed tables A table defined using a structured type.

User-defined functions A callable section of code that is registered to the database and written in C, C++, Java, COBOL, OLE, OLEDB, or .NET.

Scalar function Invoked from SQL and returns a single value.

Table function Used in the FROM clause of an SQL statement. Returns data in row format. Enables any external source of data to look like a table and can be manipulated like a read-only view.

Internal procedures Written in the SQL procedure language and contained in the CREATE PROCEDURE statement.

External procedures A server application written in C, C++, Java, COBOL, and Microsoft Visual Basic. External procedures are registered to the database using CREATE PROCEDURE.

Stored procedure builder A GUI to aid in rapid development of stored procedures and user-defined functions. Assists in estimating performance costs.

Large objects CLOB and BLOB support up to 2 GB and also support random access and partial transfer.

SQL extenders A packaging of data types and routines that enable you to store and manipulate complex data types such as image, video, text, and spatial.


11.5 Available IDS DataBlades and DB2 ExtendersTable 11-5 shows the IDS DataBlades and DB2 Extenders available from IBM. Note that third-party products are also available, as well as freeware products on IBM developerWorks® (http://www.ibm.com/developerworks/db2).

Table 11-5 IDS DataBlades and analogous DB2 Extenders

11.6 Other resourcesThere are many existing resources for further, detailed information about the extensibility topic and tools within DB2 to help build user-defined functions.

11.6.1 ToolsPart of the DB2 Development Center is a stored procedure and user-defined function builder (Figure 11-1 on page 350). The tool is very helpful in generating procedure and function signatures and checking syntax.

IDS DataBlades DB2 Extenders

Excalibur Text Search DataBlade Text Extender andNet Search Extender

Time Series

NAG

Spatial (2D spatial) Spatial Extender (2D spatial)

Geodetic DataBlade (3D spatial + time) Geodetic Extender (3D spatial + time)

Image Foundation AIV Extender (Audio Image Video)

Video Foundation AIV Extender (Audio Image Video)

Web Not available, consider using JavaServer Pages

Refer to 11.6.4, “Articles” on page 350, Generating XML from IDS 9.x

XML Extender


http://www.ibm.com/developerworks/db2

Figure 11-1 DB2 Development Center

11.6.2 GuidesThese guides are also relevant as further information sources:

� IBM Informix DataBlade API Programmer’s Guide

http://publib.boulder.ibm.com/epubs/pdf/ct1t7na.pdf

� IBM DB2 UDB Application Development Guide: Programming Server Applications, SC09-4827

11.6.3 TrainingFor further information, consider the DB2 UDB Advanced Programming, Course Code CF114, training course.

11.6.4 ArticlesThese articles are also relevant as further information sources:

� “Using the Node Data Type to Solve Problems with Hierarchies in DB2 Universal Database” by Jacques Roy, February 2003

http://www7b.software.ibm.com/dmdd/library/techarticle/0302roy/0302roy.html




� “Generating XML from IDS 9.x,” by Jacques Roy, February 25, 2003

http://www7b.software.ibm.com/dmdd/zones/informix/library/techarticle/0302roy/0302roy2.html

� “Using GUIDs with IDS 9.x,” by Jacques Roy, January 29, 2004

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0401roy/index.html

11.6.5 BooksThese books are also relevant as further information sources:

� Roy, J., Informix Dynamic Server.2000: Server-Side Programming in C, Prentice Hall PTR, 1999, ISBN 013013709X

� Roy, J., et al., Open-Source Components for Informix Dynamic Server 9.x, Pearson Education, 2001, ISBN 0130428272

� Brown, P., Object-Relational Database Development: A Plumber's Guide, Prentice Hall PTR, 2000, ISBN 0130194603




Chapter 12. Application conversion considerations

Applications are the interfaces between a user and the database engine. They map the business needs and processes into electronic information.

In this chapter, we provide you with information about general application conversion considerations and some of the specific application development differences of DB2 and IDS.

12


12.1 Key considerationsLike the database transition itself, the simplicity of an application transition to another database backend depends on several items. It is not only the programming language of the application that determines the transition process; the conceptional setup of an application is one the most important prerequisites to achieve a smooth application transition. If the user interface, business logic, and database access are well-defined and separated, there is a good chance to adapt the application to the new backend without changing the whole source code.

Typically, in any application transition effort, there will be changes to the application. Relational database systems have existed for a long time, and unfortunately for the developer, every database system has its own specialties and capabilities that an application programmer will want to use, such as for performance and ease of use. Therefore, an application transition can become much more difficult than a database transition.

If you have a look at the world of programming languages that provide a link to a database, few standards have been established. As a good example, consider Java and JDBC. If you are using JDBC to connect your IDS database, the application should run against DB2 without any changes. But, for example, if you use the extended BLOB classes (SMART BLOBs) that the Informix JDBC driver provides, you will have to change your application, at least at that section of the application where the BLOB is processed. Yes, IDS supports the JDBC standard, but also offers extensions to that standard. It is typically the developers’ responsibility to determine whether or not the extensions will be used.

In spite of these concerns, companies have demonstrated many times before that application transitions are possible. The key question is not “Is a transition possible?” but “How much resource is required for a transition project?”

12.2 PlanningAn ultimate transition plan cannot be found here. Applications are too different to have a master, or one-size-fits-all, plan. Instead, you will find in this section some hints and considerations for when you are planning an application transition. The following list presents a few, with some associated questions to think about:

� Programming language

– Is an interface for DB2 available?

– Is the interface for DB2 on the specific hardware available?


– Provides the language-specific and interface-specific database features. Do I have to deal with such extensions and find workarounds?

� Personnel

– If a team performs the transition, be sure roles and responsibilities are clearly defined.

– Are the application developers familiar with DB2 application development? Consider the time needed (thus costs) to train the developers.

– Some applications needs administration, just as with the database engine. Is the administration of your application database related?

� Estimates

– Build a list of differences in the interfaces.

– Perform an estimate of how long it could take to implement the differences of the interfaces.

� Database

– You have to be aware of some differences between DB2 and IDS that are not application-specific but need attention within an application, such as locks and transaction behavior.

� Testing

– Develop a test plan. Determine the important parts of the application.

– Testing an application is an iterative process within the whole phase of the transition process. Do you have a test environment, consisting of personnel, hardware, and software?

– Define the responsibilities.

� Distribution

– Many companies use a software distribution tool to supply clients with new or updated software. Will DB2 clients fit into the distribution?

– Is it possible to distribute the software by a incremental rollout, or will the new application used by all users from one day to another? Realize the consequences of this and develop a plan.

12.3 PackagesThe package concept is something completely new for an IDS application developer. Packages contains the static SQL statement of an application that runs against DB2. It is not the actual SQL statement that is stored within a package, but the query plan.

Chapter 12. Application conversion considerations 355

The understanding of packages is important when working with embedded SQL languages, such as ESQL/C. The query plan in the package is created at compile time. Therefore, the quality of the query plan depends on the accuracy of the optimizer statistics at compile time.

A package is represented by a file, called the bind file, that is created during the precompile procedure.

If you wrote an application that contains static SQL, passing the package to the database is mandatory. The application will not run against the database until the package is known to the database (see 12.3.2, “Bind” on page 358).

Figure 12-1 depicts the whole procedure from the source code (ESQL/C in our example) to the database-ready application.

Figure 12-1 Steps to perform from source code to application

12.3.1 Static and dynamic SQLIf you talk about static and dynamic SQL in IDS, you would define the terms static and dynamic as:

Static SQL An SQL string that is constructed within the application with the knowledge of the type of SQL statement (such as SELECT, INSERT, and SET ISOLATION), how many columns to proceed (if there are any), and in case of a DML statement, what table or tables, or at least the table structure, with which you are working.

EXEC SQL CONNECTEXEC SQL SELECT

if (oltp && ids) {/* don’t trans… */

}EXEC SQL PREARE

while (true) {EXEC SQL FETCH

if (sqlca.sqlcode …}

source.sqc

pre-compile

BINDV810üa $8L\l|!$$BDB2INST2CONNECT gAsHRJIUÈ!$"EGINDECLARE SECTIONEND DECLARE SECTION-CONNECT TO :H00002 USER :H00003 USING :H000042SELECT COUNT (*) INTO :H00001 FROM syscat.tables!

source.bnd

static char sqla_program_id[162] ={

0,42,68,65,75,65,73,65,67,79,78,78,69,67,84,32,103,65,115,72,

82,74,73,85,48,49,49,49,49,32,50,32,0,8,68,66,50,73,78,83,

source.c

bind

compile

010101010000101001010100101010101010010010101010101101010101010010101010010100101011010100101010101010010101010101001010010101001010101010010101001011010100010101010100010100100101001010010010010010010100101001010100010101001010101001010010010100101010

a.out

Package in database


Dynamic SQL An SQL string that is constructed within the application without any knowledge of tables or columns, or both. Even the type of the SQL statement might be unknown to the application. Dynamic SQL statements are typically processed using the SQL Dynamic Area (SQLDA) structure.

DB2 defines the terms Static SQL and Dynamic SQL slightly differently:

Static SQL The structure of an SQL statement is fully know at precompile time. The only information that can be specified at runtime are values for any host variables referenced by the statement. However, host variable information, such as data types, must still be precompiled.

Dynamic SQL The structure of an SQL statement is fully unknown at precompile time and is evaluated at runtime. Every SQL string constructed and stored in a variable within the application is considered dynamic.

In IDS, you would consider the following SQL statement as static SQL:

EXEC SQL DECLARE mycur CURSOR FORSELECT COUNT (*) FROM systables;

In addition, you would also consider the following SQL statement as static SQL:

strcpy (myhostvar, “SELECT colname FROM syscolumns WHERE colname NOT LIKE ‘sys%’”

EXEC SQL PREPARE mypstmt FROM :myhostvar;

However, DB2 handles the second SQL statements as dynamic SQL. The SQL string does not appear explicitly in an EXEC SQL line. It is copied into a host variable first and passed to the EXEC SQL line.

There might be situations where it is up to the programmer to use static SQL or dynamic SQL because both techniques are possible. If a decision has to be made as to which kind of SQL should be used, refer to the Dynamic SQL section in IBM DB2 UDB Application Development Guide: Programming Client Applications, SC09-4826.

Figure 12-2 on page 358 shows an overview of programming interfaces and their use of static and dynamic SQL.


Figure 12-2 Overview of DB2 programming interfaces

12.3.2 BindBinding is the procedure when passing a bind file to the database, where it is called a package. To bind a package, you have to have the necessary privileges (BIND) to perform this operation.

A bind file has been created by the precompile step. It contains the static SQL information that you use in your application (see Example 12-1).

Example 12-1 Creating a bind file

$ db2 prep assign.sqc

LINE MESSAGES FOR assign.sqc------ -------------------------------------------------------------------- SQL0060W The "C" precompiler is in progress. SQL0091W Precompilation or binding was ended with "0" errors and "0" warnings.$ ls -l assign.bnd-rw-r--r-- 1 db2inst2 db2grp1 616 Aug 13 13:17 assign.bnd


The BIND command is a powerful statement. Example 12-2 demonstrates the possible options for the BIND command. For a complete explanation, see IBM DB2 UDB Command Reference, SC09-4828.

Example 12-2 DB2 BIND syntax

BIND {filename | @filelist} [ACTION {ADD | REPLACE [RETAIN {YES | NO}][REPLVER version-id]}] [BLOCKING {UNAMBIG | ALL | NO}][CLIPKG number-of-packages] [COLLECTION collection-id][DATETIME {DEF | USA | EUR | ISO | JIS | LOC}][DEGREE {1 | degree-of-parallelism | ANY}][DYNAMICRULES {RUN | BIND | INVOKERUN | INVOKEBIND | DEFINERUN | DEFINEBIND}][EXPLAIN {NO | YES | REOPT | ALL} [EXPLSNAP {NO | YES | REOPT | ALL}][FEDERATED {NO | YES}] [FUNCPATH schema-name [ {,schema-name} ... ]][GENERIC string] [GRANT {authid | PUBLIC}] [GRANT_GROUP group-name][GRANT_USER user-name] [INSERT {BUF | DEF}][ISOLATION {CS | RR | UR | RS | NC}] [MESSAGES message-file][OWNER authorization-id][QUALIFIER qualifier-name] [QUERYOPT optimization-level][REOPT {NONE | ONCE | ALWAYS}][SQLERROR {NOPACKAGE | CHECK | CONTINUE}] [VALIDATE {RUN | BIND}][SQLWARN {NO | YES}] [STATICREADONLY {NO | YES}][TRANSFORM GROUP transform-group]

RebindThe bind file contains the static SQL statements of your application. During the bind process, the query plans of the SQL are calculated. The calculation of query plans depends on the statistical information that is provided by runstats. REBIND will recalculate the query plans of the static SQL in your application based on the actual statistics. Figure 12-3 shows the REBIND syntax.

In general, it is good practice to rebind a package after runstats is executed. Doing so will guarantee that the static SQL statements in the application will use the most appropriate query plan.

Figure 12-3 REBIND syntax diagram

Depending on the number of packages you have in your database, the rebind process can become an administrative issue. To keep it simple, you can use the

REBINDPACKAGE

package-nameVERSION version-name

RESOLVE ANYCONSERVATIVE


db2rbind command, as shown in Example 12-3. The db2rbind command rebinds all existing packages, meaning it will recalculate all query plans in a database.

Example 12-3 Syntax of db2rbind

Usage: db2rbind database-alias -l logfile [all -u userid -p password][-r {conservative|any}]

Viewing a bind fileAfter the bind file has been created, you might be interested in what SQL statements it contains. The knowledge of the contents of a bind file can also be interesting because you might have received a bind file from a third-party vendor whose application you are using.

The db2bfd command is the tool of choice when displaying the content of a bind file from command line. Example 12-4 shows the syntax of the db2bfd command.

Example 12-4 Syntax of db2bfd

Usage: db2bfd [ [-b] [-h] [-s] [-v] ] <filespec>

Where: <filespec> is a V7 or V8 bind file

Options: -b = display bind file header -h = display this information -s = display SQL statements -v = display host variable declarations

In Example 12-5, you can see the output of the db2bfd command that is executed.

Example 12-5 Sample output of the db2bfd command

$ db2bfd -s connect.bnd

connect.bnd: SQL Statements = 8

Line Sec Typ Var Len SQL statement text---- --- --- --- --- --------------------------------------------------------- 8 0 5 0 21 BEGIN DECLARE SECTION 14 0 2 0 19 END DECLARE SECTION 24 0 19 3 45 CONNECT TO :H00002 USER :H00003 USING :H00004 26 1 0 1 50 SELECT COUNT (*) INTO :H00001 FROM syscat.tables 33 2 11 1 24 PREPARE PID FROM :H00005 35 2 3 0 28 DECLARE MYCUR CURSOR FOR PID 36 2 4 0 10 OPEN MYCUR 38 0 19 0 14 DISCONNECT ALL


Package versionsDB2 Version 8 introduced the possiblilty to have more than one package for the same application in a database. The advantage of this is that applications can work with a proven version while others are testing a new version of a package. The versioning of packages is reflected by additional parameters in all the above bind utilities and statements.

12.4 TransactionsBoth IDS and DB2 support transactions in terms of the ACID capabilities. ACID is an acronym for the following terms:

� Atomic

� Consistency

� Isolated

� Durable

IDS has different kinds of databases that use a different mechanism that determines how and when to write transaction records (log records) to disk. These are non-logging databases, buffered and unbuffered logging database, and log-mode ANSI databases.

DB2 is aware of only two techniques for handling transactions, and they are write/log transactions to disk or do not write/log transactions to disk. The latter is even a special case. You have to switch to that mode explicitly, because every DB2 database logs transactions. The deactivating of the logging is done for the same reasons you would do it when working with IDS, such as for loading a large amount of data into a table.

When moving an application that runs against a non-logging IDS database, you have to implement transaction handling into the application.

Another difference between IDS and DB2, concerning transactions is the transaction scope. In IDS, you start a transaction by typing BEGIN WORK. DB2 is not aware of this SQL statement. In DB2, every SQL statement is arranged in a transaction (except when you have switched transaction login off). As soon you end a transaction using COMMIT or ROLLBACK, a new transaction is started automatically. This behavior can also be recognized in IDS when working with a log-mode ANSI database. Example 12-6 on page 362 contains the ESQL/C source code that demonstrates the behavior of DB2 transactions. The remarkable part in the program is that a ROLLBACK SQL statement is executed without any BEGIN WORK statement. The transaction has been started implicitly after the database is connected.


Example 12-6 Sample program demonstrating DB2 transactions

#include <stdio.h>#include <string.h>#include <sql.h>

int main (){EXEC SQL BEGIN DECLARE SECTION; char dbname[9]; char uid[9]; char pwd[9];

sqlint32 col1; char col2[11];

sqlint32 rowcount; EXEC SQL END DECLARE SECTION;

struct sqlca sqlca;

strcpy (dbname, "ifmx2db2"); strcpy (uid, "db2inst2"); strcpy (pwd, "db2rules");

printf ("Conneting %s as user %s.\n", dbname, uid); EXEC SQL CONNECT TO :dbname USER :uid USING :pwd;

EXEC SQL SELECT COUNT (*) INTO :rowcount FROM lindi; printf ("Table 'lindi' contains %d rows.\n", rowcount);

col1 = 10; strcpy (col2, "Hello"); EXEC SQL INSERT INTO lindi VALUES (:col1, :col2); printf ("New record inserted into table 'lindi'\n");

EXEC SQL SELECT COUNT (*) INTO :rowcount FROM lindi; printf ("Table 'lindi'contains %d rows.\n", rowcount);

EXEC SQL ROLLBACK; printf ("Rollback executed.\n");

EXEC SQL SELECT COUNT (*) INTO :rowcount FROM lindi; printf ("Table 'lindi'contains %d rows.\n", rowcount);

EXEC SQL DISCONNECT ALL; return 0;}


Example 12-7 shows the output of the example.

Example 12-7 Output of example

Conneting ifmx2db2 as user db2inst2.Table 'lindi'contains 6 rows.New record inserted into table 'lindi'Table 'lindi'contains 7 rows.Rollback executed.Table 'lindi'contains 6 rows.

12.4.1 SavepointsSavepoints are a transactional extension of DB2. Savepoints enable you to roll back a transaction, not completely, but to a well-defined point with the transaction flow. In Figure 12-4, we show a schematic diagram of how the savepoint affects a transaction.

Figure 12-4 Transaction flow when rolling back a transaction to a savepoint

It is possible to set several savepoints and doing so will enable you to roll back to different states of the transaction flow in your application. You can always roll back to a savepoint that was set before the actual position in the transaction flow. After a transaction has been rolled back to a savepoint, you cannot roll back the transaction flow to a savepoint that has been set after the savepoint you currently have reached. Example 12-5 on page 364 presents a schematic illustration of this behavior.

t

tx starts tx endssavepoint sp1

insertupdate

delete delete

updatedelete

insert update

ROLLBACK

ROLLBACK TO SAVEPOINT sp1


Figure 12-5 Multiple savepoint with rollback commands

Figure 12-6 shows the syntax of how to set a savepoint in an application. It demonstrates how to use a savepoint in an application.

Figure 12-6 Syntax to set a savepoint in DB2

12.5 LocksLocks are placed on any type of database object to ensure data consistency. For example, IDS allows you to lock the complete database at the highest level and a data row on the lowest level. Depending on the operation to be performed on the corresponding database object, the lock might not only be set for a client (in the way of usual business operations), but also for administration reasons, such as table reorganization or index rebuild.

tx1current

tx1start

tx1end

savepoint sp1

savepoint sp2

savepoint sp3

t = application flow

tx1 = transaction flow

rollb

ack

to s

p3

rollb

ack

to s

p2

rollb

ack

to s

p1

rollb

ack

to s

p3

SAVEPOINTUNIQUE

savepoint-name

ON ROLLBACK RETAIN CURSORSON ROLLBACK RETAIN LOCKS


DB2 also has different levels of lock placement, which are similar to the IDS levels. Example 12-1 shows you a comparison of DB2 and IDS lock levels.

Table 12-1 Comparison of IDS and DB2 lock levels

12.5.1 Types of locksIDS is aware of three different types of base locks:

� S: Shared lock

� U: Update (promotable) lock

� X: Exclusive lock

The type of lock set depends on the type of SQL statement and what isolation level has been set. In general, every SQL statement that modifies data causes an X lock on the corresponding database object. Shared locks are set when an SQL statement reads an object. Update locks are set when an application is using an UPDATE CURSOR (see 12.7.3, “Update Cursor” on page 374). This type of lock is also known as promotable lock. In a sense, it behaves like a shared lock, but this lock has the ability to be transformed into an exclusive lock.

From a application development point of view, these three types of locks are the more interesting ones. You will also find these types of locks in DB2. Fortunately, the name and the behavior is also the same in DB2.

As with IDS, DB2 is also aware of other locks, but these locks are more used for internal processing. Table 12-3 on page 369 shows a complete list of DB2 locks.

IDS DB2

Database Database

N/A Table space

Table Table

Page N/A

Row Row

Index Index


Table 12-2 Complete list of DB2 locks

Lock type Objects affected Description

IN (Intent None)

Table spaces, blocks,tables

The lock owner can read any data in the object, including uncommitted data, but cannot update any of it. Other concurrent applications can read or update the table.

IS (Intent Share)

Table spaces, blocks,tables

The lock owner can read data in the locked table, but cannot update this data. Other applications can read or update the table.

NS (Next Key Share)

Rows The lock owner and all concurrent applications can read, but not update, the locked row. This lock is acquired on rows of a table, instead of an S lock, where the isolation level of the application is either RS or CS. NS lock mode is not used for next-key locking. It is used instead of S mode during CS and RS scans to minimize the impact of next-key locking on these scans.

S (Share)

Rows, blocks,tables

The lock owner and all concurrent applications can read, but not update, the locked data.

IX (Intent Exclusive)

Table spaces, blocks, tables

The lock owner and concurrent applications can read and update data. Other concurrent applications can both read and update the table.

SIX (Share with Intent Exclusive)

Tables, blocks

The lock owner can read and update data. Other concurrent applications can read the table.

U (Update)

Rows, blocks, tables

The lock owner can update data. Other units of work can read the data in the locked object, but cannot update it.

NW(Next Key Weak Exclusive)

Rows When a row is inserted into an index, an NW lock is acquired on the next row. For type 2 indexes, this occurs only if the next row is currently locked by an RR scan. The lock owner can read, but not update the locked row. This lock mode is similar to an X lock, except that it is also compatible with W and NS locks.

X (Exclusive)

Rows, blocks, tables, buffer pools

The lock owner can both read and update data in the locked object. Only uncommitted read applications can access the locked object.


How to set locksAlthough locks are set implictly when modifying a row, you can explicitly lock a table or database. The reasons for locking an entire table might be the same as in IDS, such as for the bulk load of a table or for administrative issues.

To lock a table, you can use the same syntax as with IDS, as shown in Figure 12-7.

Figure 12-7 DB2 and IDS LOCK TABLE syntax

As known from IDS, an entire database can be locked explicitly when the database is connected. DB2 enables you to lock a database either in share or exclusive mode:

Share Another user can connect the database, but is not allowed to lock the database in exclusive mode. This is the default when you do not specify a lock mode.

Exclusive The database is locked exclusively, which means that no other user can access the database. With IDS, a user with the same user ID that has locked the database has still access to the database.

W(Weak Exclusive)

Rows This lock is acquired on the row when a row is inserted into a table that does not have type 2 indexes defined. The lock owner can change the locked row. To determine if a duplicate value has been committed when a duplicate value is found, this lock is also used during insertion into a unique index. This lock is similar to an X lock, except that it is compatible with the NW lock. Only uncommitted read applications can access the locked row.

Z (Super Exclusive)

Table spaces, tables

This lock is acquired on a table in certain conditions, such as when the table is altered or dropped, an index on the table is created or dropped, or for some types of table reorganization. No other concurrent application can read or update the table.

Lock type Objects affected Description

LOCK TABLE table-namenick-name

IN EXCLUSIVE MODESHARE


To connect to a database, you can use the syntax shown in Figure 12-8.

Figure 12-8 Connect database statement in DB2 with lock mode

12.5.2 Lock escalationLock escalation is an internal mechanism that reduces the number of locks held. In a single table, locks can be escalated to a table lock from many row locks, or for multidimensional clustering (MDC) tables from many row or block locks. Lock escalation occurs when applications hold too many locks of any type. Lock escalation can occur for a specific database agent if the agent exceeds its allocation of the lock list. Such escalation is handled internally; the only externally detectable result might be a reduction in concurrent access on one or more tables.

In an appropriately configured database, lock escalation occurs infrequently. For example, lock escalation might occur when an application designer creates an index on a large table to increase performance and concurrency, but a transaction accesses most of the records in the table. In this case, because the database manager cannot to predict how much of the table will be locked, it locks each record individually instead of locking only the table either as S or X. In this case, the database designer might consult with the application designer and recommend a LOCK TABLE statement for this transaction.

Occasionally, the process receiving the internal escalation request holds few or no row locks on any table, but locks are escalated because one or more processes hold many locks. The process might not request another lock or access the database again except to end the transaction. Then, another process might request the lock or locks that trigger the escalation request.

12.5.3 DeadlocksDeadlocks occur if several sessions are locking themselves mutually. The deadlock detection of IDS behaves well and defines what session is rejected.

DB2 contains also a deadlock detection. However, it is not deterministic regarding which session is rejected if a deadlock occurs.

CONNECT TO database-name IN MODESHAREEXCLUSIVE


12.6 Isolation levelsIsolation levels controls when and what kind of locks are set on a database object such as a row, page, or table. DB2 implements the SQL ANSI requirements.

Table 12-3 shows a comparison of IDS and DB2 isolation levels. In the following sections, we provide more detailed descriptions of the isolation levels.

Table 12-3 IDS and DB2 isolation level

The default isolation level for IDS logged databases (non-log mode ANSI) is Committed Read. Most applications will use this standard mode, because the need of lock resources is relatively small with relatively high transaction encapsulation. DB2 has no exact equivalent to Committed Read, but an alternative isolation level to consider in DB2 might be Read Stability.

Default isolation levelBecause DB2 does not deal with different types of databases (such as no logging, buffered/unbuffered, or log mode ANSI), there is only one default isolation level. If you do not specify something different, the default isolation level is Cursor Stability.

How to set an isolation levelIDS has its own SQL statement to change between the isolation levels (SET ISOLATION TO). DB2 offers different techniques for changing the isolation level.

Changing the isolation level in SQLTo set or change the isolation level for a single statement, you should use the WITH clause at the end of a Select sql statement.

if you would like to change the isolation level for the duration of a entire transaction (unit of work or UOW), you can use the SET ISOLATION statement.

IDS DB2

Repeatable Read (RR) Repeatable Read (RR)

Cursor Stability (CR) Cursor Stability (CR)

N/A Read Stability (RS)

Committed Read (CR) N/A

Dirty Read (DR) Uncommitted Read (UR)


Example 12-8 on page 370 shows you the variants to change the isolation levels in SQL.

Example 12-8 Changing the isolation levels in SQL

SELECT <columns>FROM <tables> ... WITH {UR|RR|CS|RS};

SET ISOLATION={UR|RR|CS|RS};

Changing the isolation level in packagesIf a application package has been created, you will bind it against a database. When using the BIND command, you can also specify the default isolation level for this package. All SQL statements of this package will run in the isolation level you specified, except those that set their own isolation level (see “Changing the isolation level in SQL” on page 369). Example 12-9 demonstrates the impact of using the ISOLATION option when binding a package.

Example 12-9 Changing the isolation level in packages

$ db2 BIND connect.bnd ISOLATION UR;$ db2expln -d ifmx2db2 -schema db2inst2 -package connect -t

DB2 Universal Database Version 8.1, 5622-044 (c) Copyright IBM Corp. 1991, 2002Licensed Material - Program Property of IBMIBM DB2 Universal Database SQL Explain Tool[...]******************** PACKAGE ***************************************

Package Name = "DB2INST2"."CONNECT" Version = ""

Prep Date = 2004/08/04 Prep Time = 16:08:15

Bind Timestamp = 2004-08-06-13.02.59.275670

Isolation Level = Uncommitted Read Blocking = Block Unambiguous Cursors Query Optimization Class = 9

Partition Parallel = No Intra-Partition Parallel = No

SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "DB2INST2"

-------------------- SECTION ---------------------------------------[...]


12.6.1 Repeatable Read (RR) This isolation level ensures that:

� Any row read during a unit of work is not changed by other application processes until the unit of work is complete. The rows are read in the same unit of work as the corresponding OPEN statement. Use of the optional WITH RELEASE clause on the CLOSE statement means that any guarantees against non-repeatable reads and phantom reads no longer apply to any previously accessed rows if the cursor is reopened.

� Any row changed by another application process cannot be read until it is committed by that application process.

The Repeatable Read level does not allow phantom rows to be viewed. See 12.6.2, “Read Stability (RS)” on page 371.

In addition to any exclusive locks, an application process running at the RR level acquires at least share locks on all the rows it references. Furthermore, the locking is performed so that the application process is completely isolated from the effects of concurrent application processes.

12.6.2 Read Stability (RS) Like the Repeatable Read level, the Read Stability level ensures that:

� Any row read during a unit of work is not changed by other application processes until the unit of work is complete. The rows are read in the same unit of work as the corresponding OPEN statement. Use of the optional WITH RELEASE clause on the CLOSE statement means that any guarantees against non-repeatable reads no longer apply to any previously accessed rows if the cursor is reopened.

� Any row changed by another application process cannot be read until it is committed by that application process.

Unlike Repeatable Read, Read Stability does not completely isolate the application process from the effects of concurrent application processes. At the RS level, application processes that issue the same query more than once might see additional rows caused by other application processes appending new information to the database. These additional rows are called phantom rows.

For example, a phantom row can occur in the following situation:

1. Application process P1 reads the set of rows n that satisfy some search condition.

2. Application process P2 then inserts one or more rows that satisfy the search condition and commits those new inserts.


3. P1 reads the set of rows again with the same search condition and obtains both the original rows and the rows inserted by P2.

In addition to any exclusive locks, an application process running at the RS isolation level acquires at least share locks on all the qualifying rows.

12.6.3 Cursor Stability (CS) Like the Repeatable Read level, the Cursor Stability level ensures that any row that was changed by another application process cannot be read until it is committed by that application process.

Unlike Repeatable Read, Cursor Stability only ensures that the current row of every Update Cursor is not changed by other application processes. Therefore, the rows that were read during a unit of work can be changed by other application processes.

In addition to any exclusive locks, an application process running at the CS isolation level acquires at least a share lock on the current row of every cursor.

12.6.4 Uncommitted Read (UR) For SELECT INTO, FETCH with a read-only cursor, fullselect in an INSERT, row fullselect in an UPDATE, or scalar fullselect (wherever it is used), the Uncommitted Read level allows:

� Any row read during a unit of work to be changed by other application processes.

� Any row changed by another application process to be read, even if the change has not been committed by that application process.

For other operations, rules associated with the CS level apply.

12.7 CursorsCursors are an instrument to transfer data rows from the database engine to the application. The principle of cursors in IDS and DB2 is very similar. You can find the different types of cursors in both IDS and DB2 (with the exception of Insert Cursors). The following sections describe some additional features about DB2 cursors.


When working with a cursor in DB2, you have also to perform several steps to establish a cursor construction in your application. For example:

1. Declare the cursor: The declaration of cursors introduces the cursor into your application. When declaring a cursor, you typically associate the cursors name with a SELECT statement. See Figure 12-9.

Figure 12-9 DB2 syntax to declare a cursor

A DB2 cursor provides a WITH HOLD extension as IDS cursors do. However, the behavior of the DB2 cursor is different when ending a transaction:

– COMMIT: Cursor remains open.– ROLLBACK: Cursor is closed.

2. Open the cursor: If the cursor is opened, the associated SQL statement is executed. Now, the cursor is read to retrieve the data. If the cursor you are working with is a Scroll Cursor, a temporary table has to be created. See Figure 12-10.

Figure 12-10 Open cursor syntax in DB2

3. Fetching rows: Typically, the rows are fetched in a loop. Depending on the kind of the cursor, other operations to address the row you want to fetch are possible.

To test if there are more rows to process, an sqlca.sqlcode (SQLCODE) is checked against the value of 100 (SQLNOTFOUND). The behavior is identical in IDS and DB2. See Figure 12-11 on page 374.

DECLARE cursor-nameWITH HOLD TO CALLER

TO CLIENT

select-statementstatement-name

FOR

WITH RETURN

OPEN cursor-name

USING host-variable

USING DESCRIPTOR descriptor-name

,


Figure 12-11 Fetch row syntax in DB2

4. Close the cursor: After the rows has been processed, and the cursor is no longer needed, the cursor can be closed. If the cursor is a Scroll Cursor, the temporary table is dropped.

5. Free the cursor: IDS cursors have to be freed to release all allocated resources. This is not necessary when working with DB2 cursors. Allocated resources are freed when the cursor is closed.

12.7.1 Non-Scroll CursorThe Non-Scroll Cursor is a simple type of cursor. It enables the fetching of rows in one read direction. If a row has been read by the cursor, and you are going to read again, the cursor has to be reopened again.

12.7.2 Scroll CursorA Scroll Cursor enables you to read data rows in every direction. IDS allows you to use relative or absolute offsets passed to the FETCH statement. Contrary to a Non-Scroll Cursor, a Scroll Cursors needs a copy of the actual data. This is typically implemented by using a temporary table.

If your application is written using embedded SQL, DB2 does not support a Scroll Cursor. You have to use a local copy of the data you process.

Applications written in ODBC/CLI or Java/JDBC can call the built-in functions and methods provided to use a Scroll Cursor.

12.7.3 Update CursorAn Update Cursor enables you to manipulate a row that has just been fetched.

The declaration of an Update Cursor is identical to the conventional cursor. However, the corresponding SELECT statement for the cursor is extended with a FOR UPDATE clause.

The FOR UPDATE clause identifies the columns that can be updated in a subsequent positioned UPDATE statement. Each column name must be unqualified and must identify a column of the table or view identified in the first

FETCH cursor-nameFROM

INTO host-variableUSING DESCRIPTORdescriptor-name

,


FROM clause of the fullselect. If the FOR UPDATE clause is specified without column names, all updatable columns of the table or view identified in the first FROM clause of the fullselect are included.

Example 12-10 demonstrates the use of Update Cursors in a pseudo code snippet.

Example 12-10 Use of a DB2 Update Cursor (pseudo code)

DECLARE cur1 CURSOR FORSELECT customer_num, lname, fnameFROM customerWHERE customer_num BETWEEN 120 AND 125

FOR UPDATE;

LOOPFETCH cur1 INTO [hostvariables];

UPDATE customerSET lname = ‘Webba’,

fname = ‘Hanne’WHERE CURRENT OF cur1;

12.7.4 Insert CursorIDS Insert Cursors are used to achieve better performance when inserting rows. In particular, batch jobs can benefit by this type of cursor. Because not every new row is sent to the database engine (but stored in a buffer on the client side of the connection), the overhead is smaller. If this buffer becomes full, or at your request, it is flushed to the database.

DB2 currently does not support Insert Cursors. You can, however, achieve a similar behavior by using an array of data rows allocated by the SQLDA structure, or by using a Batch Insert (see 6.19, “INSERT cursors” on page 205).

12.8 Stored proceduresStored procedures are, as the name implies, small pieces of code stored within a database. The main purpose of stored procedures is to encapsulate business needs into a database routine.

Stored procedures have several advantages if used correctly. One of the advantages is that you can program within a procedure. In pure SQL, this is this not possible, because SQL is a language based on set theories and does not provide structures such as IF-THEN-ELSE conditions or loops.


DB2 provides you stored procedures, as does IDS. However, there are some differences in the terminology that might confuse an IDS stored procedure programmer. In 12.8.1, “Terminology” on page 376, we explain these differences. In 12.8.2, “Languages and interfaces” on page 376, we provide you with an overview how stored procedures can be developed in DB2. Finally, 12.8.3, “Invocation” on page 384 explains what special features DB2 offers when calling a stored procedure from a client.

12.8.1 TerminologyWhen talking about stored procedures, you should consider the following categories. There are user-defined routines (UDR) to which stored procedures belong and user-defined functions (UDF). A function returns (per definition) exactly one value, while a routine and procedure can return a result set.

Figure 12-12 depicts a graphical view of what set can be returned by functions and procedures.

Figure 12-12 Return types of procedures and functions

The DB2 use of the term “stored procedure” will typically mean UDF and UDR, except for referring to those written in SQL/PL.

12.8.2 Languages and interfacesRoutines and functions can be written in SQL, C/C++, and Java. There is no general advice regarding which language is best to use. It depends on you needs and environment. When creating a routine in DB2, you will find similarities to IDS.

SQL and SQL/PLStored procedures and functions can be written in SQL. However, SQL does not provide some necessary constructs, such as loops. DB2 expands SQL with SQL/PL, which is the programming language for SQL.

Possible return types of functions:

Possible return types of procedures:

Ø

Ø , ,,,

,


SQL/PL provides more features than the stored procedure language (SPL) that is used by IDS. The advantage of SQL/PL over SPL is that you can work with dynamic statements using PREPARE. In some sense, the semantics of SQL/PL are more comparable with Informix 4GL than with SPL. In Example 12-11, we show a procedure written in SQL/PL.

Example 12-11 SQL/PL procedure example

CREATE PROCEDURE bump_salary_if (IN deptnumber SMALLINT)LANGUAGE SQLBEGIN DECLARE SQLSTATE CHAR(5); DECLARE v_salary DOUBLE; DECLARE v_years SMALLINT; DECLARE v_id SMALLINT; DECLARE at_end INT DEFAULT 0; DECLARE not_found CONDITION FOR SQLSTATE '02000';

DECLARE C1 CURSOR FOR SELECT id, CAST(salary AS DOUBLE), years FROM staff; DECLARE CONTINUE HANDLER FOR not_found SET at_end = 1;

OPEN C1; FETCH C1 INTO v_id, v_salary, v_years; WHILE at_end = 0 DO IF (v_salary < 2000 * v_years) THEN UPDATE staff SET salary = 2150 * v_years WHERE id = v_id; ELSEIF (v_salary < 5000 * v_years) THEN IF (v_salary < 3000 * v_years) THEN UPDATE staff SET salary = 3000 * v_years WHERE id = v_id; ELSE UPDATE staff SET salary = v_salary * 1.10 WHERE id = v_id; END IF; ELSE UPDATE staff SET job = 'PREZ' WHERE id = v_id; END IF; FETCH C1 INTO v_id, v_salary, v_years; END WHILE; CLOSE C1;END


Another important difference between IDS and DB2 SQL procedures is the parameter handling. DB2 follows the ANSI standard using IN, OUT, and INOUT clauses in the procedure parameter list. IDS partially introduced this standard in Version 9.40. The definitions of those parameters are:

IN Identifies the parameter as an input parameter to the procedure. Any changes made to the parameter within the procedure are not available to the calling SQL application when control is returned. The default is IN.

OUT Identifies the parameter as an output parameter for the procedure.

INOUT Identifies the parameter as both an input and output parameter for the procedure.

DB2 SQL/PL expansionsIn this section, we provide a short overview of which additional features can be found in DB2 SQL/PL and which are not supported by IDS SPL, respectively.

CursorsWhile an IDS procedure offers a FOREACH loop to fetch rows from a SELECT statement, DB2 enables you to work with a real cursor in your procedure. Of course, cursors have to be declared, opened, and closed. See Example 12-13 on page 379 and Example 12-14 on page 380.

If the result set produced by the corresponding SELECT statement of a cusor has to be returned to the procedure caller, you have to specify the WITH RETURN clause.

Example 12-12 shows you the declaration of cursors in DB2.

Example 12-12 Declaration of DB2 procedure cursors

DECLARE c1 CURSOR FOR SELECT ...

DECLARE c2 CURSOR WITH RETURN FORSELECT ...

Note: If you create SQL/PL stored procedure on DB2 prior to Version 8, a C compiler is required. SQL/PL procedures translated into C code have to be compiled. The compiler is invoked by the database engine.


LoopsIn DB2, you can find special types of loops. The loops are used to iterate over a result set generated by a SELECT statement. In fact, the behavior of these loops is comparable to the FOREACH loop in IDS procedures. The types of loops are:

LOOP/ITERATE The LOOP construct is an endless loop. Within the loop, you will check some conditions and make a decision whether to exit the loop (LEAVE) or start over (ITERATE).

REPEAT This kind of loop will end if the cursor for the corresponding SELECT statement raises the NOT FOUND condition. You have to install a SIGNAL handler to catch the NOT FOUND condition.

FOR The FOR loop is very similar to the FOREACH loop in IDS. When using the FOR loop, you also declare a SELECT statement in the loop head. Therefore, you do not have to deal with cursor.

The LOOP and the REPEAT loops use a label in the beginning. The label names a loop that you can refer to when jumping out off the loop, for example. Naming a loop provides more readable code, particularly when working with nested loops. Example 12-13 shows the DB2 LOOP construct.

Example 12-13 Using the DB2 LOOP construct

[...]DECLARE cust_cur CURSOR FOR

SELECT fname, lname FROM customer;

OPEN cust_cur;loop_label:LOOP

FETCH cust_cur INTO ...IF condition THEN

ITERATE loop_label;ELSEIF

LEAVE loop_label;END IF;

END LOOP;[...]

Example 12-14 on page 380 shows use of the REPEAT construct.


Example 12-14 Using the DB2 REPEAT construct

[...]DECLARE at_end SMALLINT DEFAULT 0;DECLARE not_found CONDITION FOR SQLSTATE ’02000’;DECLARE CONTINUE HANDLER FOR not_found

SET at_end = 1;DECLARE cust_cur CURSOR FOR

SELECT fname, lname FROM customer;

OPEN cust_cur;repeat_label:REPEAT

FETCH cust_cur INTO ...UNTIL at_end > 0END REPEAT repeat_label;[...]

Error handlingDB2 uses a signal handler to deal with error conditions that can occur in a procedure. Errors are raised by the database engine or by your procedure. You have the ability to raise errors to inform the procedure called that something unpredictable has happened.

Example 12-15 demonstrates the installation of a signal handler. For example, dividing by zero in line 15, would cause a run-time error producing SQLSTATE 22003 (value out of range) if no additional action was taken. Because the zero value is caught by the IF condition in line 12, dividing by zero will not occur. But to inform the caller that this circumstance has occurred, a signal called overflow is raised. This signal has been defined in line 7. Line 8 defines what has to be done if this signal is raised somewhere in the procedure. It raises a signal by itself (SQLSTATE 22375, which is for user-defined exceptions) and returns a message to the caller.

Example 12-15 Installing a signal handler in DB2 procedures

+1 CREATE PROCEDURE divide (IN numerator INTEGER,+2 IN denominator INTEGER,+3 OUT result INTEGER)+4 LANGUAGE SQL+5 READS SQL DATA+6 BEGIN+7 DECLARE overflow CONDITION FOR SQLSTATE '22003';+8 DECLARE CONTINUE HANDLER FOR overflow RESIGNAL SQLSTATE value '22375'+9 SET MESSAGE_TEXT = 'Division by zero.';+10+11+12 IF denominator = 0 THEN


+13 SIGNAL overflow;+14 ELSE+15 SET result = numerator / denominator;+16 END IF;+17 END@

Executing the divide procedure, as shown in Example 12-15 on page 380, would return the output depicted in Example 12-16.

Example 12-16 Output of raised signals from a DB2 procedure

db2 "call divide (4, 2, ?)"

Value of output parameters -------------------------- Parameter Name : RESULT Parameter Value : 2

Return Status = 0

db2 "call divide (4, 0, ?)"SQL0438N Application raised error with diagnostic text: "Division by zero.". SQLSTATE=22375

C/C++ functionsDB2 enables you to write a user-defined function in C/C++. The function’s appearance is like a conventional C function, with a few extras. If you want to use a C function as a DB2 UDF, you have to compile the C code and build a shared library that containes this function. Of course, the shared library can contain functions that can be used in DB2.

Example 12-17 is a UDF that demonstrates a C function performing a bit ANDing of two integer values.

Example 12-17 A user-defined function written in C

+1 #include <sqludf.h>+2+3 void SQL_API_FN BITAND (SQLUDF_INTEGER *word1,+4 SQLUDF_INTEGER *word2,+5 SQLUDF_INTEGER *out_word,+6 SQLUDF_SMALLINT *word1_ind,+7 SQLUDF_SMALLINT *word2_ind,+8 SQLUDF_SMALLINT *out_word_ind,+9 SQLUDF_TRAIL_ARGS)+10 {+11 if (*word1_ind == -1 || *word2_ind == -1) { /* NULL values */


+12 *out_word_ind = -1; /* => result NULL */+13 }+14 else { /* bit ops */+15 *out_word_ind = 0;+16 *out_word = *word1 & *word2;+17 }+18 }

A C function that is to be a DB2 UDF has to fulfill some prerequisites:

� Return type SQL_API_FN SQL_API_FN is a macro that specifies the return type and calling convention for a C/C++ function, which can vary across supported operating systems. They are declared in sqlsystm.h. This macro is required when you write C/C++ routines.

� Function signature. DB2 provides different parameter styles for a function. The style in Example 12-17 on page 381 is called SQL. This style requires pointers to the input and output parameters and indicator variables for NULL values (also pointers). The data types of the parameters are also C macros to encapsulate a proper SQL - C data type mapping. Examples of other possible parameter styles are GENERAL and DB2SQL. Refer to the CREATE PROCEDURE section in IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, for further details.

� SQLUDF_TRAIL_ARGS is a macro defined in sqludf.h that defines the trailing arguments for a routine. This includes pointers to the SQLSTATE, fully qualified function name, function specific name, and message text.

The C function in Example 12-17 on page 381 is stored in a file called bitops.c. Perform the following steps to create an DB2 UDF:

1. Compile the function. In Example 12-18, a GNU compiler on AIX has been used to compile the file and then to create the shared library.

Example 12-18 Compiling a DB2 C UDF

gcc -I$HOME/sqllib/include -c bitops.c

2. Build the shared library. After the object file that contains the C UDF has been created, a shared library is constructed. Example 12-19 show the command to do that.

Example 12-19 Create a shared library for the DB2 C UDF

gcc -shared -L$HOME/sqllib/lib -ldb2 bitops.o -o libbitops.so


3. Create the UDF. If the shared library has been built, the UDF can be created in a database. In it, you can find the SQL syntax to create the UDF. The UDF head defines the name of the UDF and what function parameters are expected. Furthermore, the data type of the return value is defined. The EXTERNAL line specifies where the shared library can be found and what symbol in the library has to be used to call the function later. Some of the other parameters that appear in the CREATE FUNCTION statement are optional, and others are mandatory. For a full description of these parameters, refer to the CREATE FUNCTION section in IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845. Example 12-20 depicts the creation of a function in DB2.

Example 12-20 Create a function in DB2

CREATE FUNCTION bitand (INTEGER, INTEGER) RETURNS INTEGER EXTERNAL NAME '/home/db2inst2/uwestuff/libmyfoo.so!bitand' LANGUAGE C PARAMETER STYLE SQL DETERMINISTIC NOT FENCED NULL CALL NO SQL NO EXTERNAL ACTION

Java functionsThe process of creating a UDF written in Java is similar to the process for creating a UDF in C. Instead of building a shared library, you create a JAR file where the class of the function resides. It is also possible to pass a single class file to the CREATE FUNCTION statement. Example 12-21 demonstrates how to create a Java UDF.

Example 12-21 Example of a Java UDF

import java.sql.SQLException;

public class JavaUDF {

public static double product (double in1, double in2) throws SQLException {

return in1 * in2; }}


The class JavaUDF, with its method product, is compiled into byte code. After the class file has been created, you can pack the class into a JAR file or use the class file to directly create a UDF.

Example 12-22 shows the SQL statement to create the Java UDF within the database.

Example 12-22 Create a Java UDF in DB2

CREATE FUNCTION product (DOUBLE, DOUBLE ) RETURNS double LANGUAGE java PARAMETER STYLE java NO SQL DETERMINISTIC RETURNS NULL ON NULL INPUT NO EXTERNAL ACTION EXTERNAL NAME '/home/db2inst2/uwestuff/JavaUDF.product';

12.8.3 InvocationIn IDS, you have two ways to execute a procedure or function, either EXECUTE PROCEDURE or CALL. DB2 is also aware of the CALL statement. However, CALL will execute procedures only. If you want to execute a function, you have to use the VALUES clause or embed the function in a SELECT statement. Figure 12-13 depicts the syntax of a DB2 CALL.

Figure 12-13 DB2 syntax of CALL

If you call a procedure with an OUT argument in the signature, from the command line, you have to place a question mark at the corresponding position. The results of the output parameters is printed to standard out. (See Example 12-16 on page 381.)

If a procedure with OUT arguments is called from another procedure, you have to use a variable as a procedure argument to retrieve the result, as shown in Example 12-23 on page 385.

CREATE TRIGGER trigger-name NO CASCADE BEFORE

INSTEAD OFAFTER

INSERT

column-nameOF,

UPDATEDELETE


Example 12-23 DB2 nested procedure call

+1 CREATE PROCEDURE nested (OUT result INTEGER)+2 LANGUAGE SQL+3 READS SQL DATA+4 BEGIN+5 CALL divide (4, 2, result);+6 END

12.9 Programming language considerationsIn this section, we present some general information regarding certain programming languages and their database interfaces. This is not an exhaustive discussion, but simply provides you with some information to be aware of when porting an application from IDS to DB2.

12.9.1 ESQL/CESQL/C is one of the most popular programing language interfaces found in the Informix environment. ESQL/C lets the programmer write SQL statements in the C source code.

A precompiler is needed to convert the SQL statements into regular C-function calls. After the conversion, the resulting C file can be compiled into an executable or library. Example 12-24 demonstrates the steps to take to create an ESQL/C application in DB2 (see also Example 12-1 on page 356).

Example 12-24 Steps to perform from source code to application

$ db2 connect to ifmx2db2Database Connection Information

Database server = DB2/6000 8.2.0 SQL authorization ID = DB2INST2 Local database alias = IFMX2DB2

$ db2 prep myexample.sqc bindfile

LINE MESSAGES FOR myexample.sqc------ -------------------------------------------------------------------- SQL0060W The "C" precompiler is in progress. SQL0091W Precompilation or binding was ended with "0" errors and "0" warnings.

$ db2 bind myexample.bnd


LINE MESSAGES FOR myexample.bnd------ -------------------------------------------------------------------- SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings.

$ gcc -I$HOME/sqllib/include -L$HOME/sqllib/lib -ldb2 myexample.c -o myexample

When working with ESQL/C, there are some basic operations to perform in both IDS and DB2. In the following section, we discuss the similarities and differences of the interfaces.

Host variablesC variables that have to be used in SQL statements are called host variables. The are declared in a special section of an application, called the declare section. The way host variables are declared is identical in IDS and DB2, as shown in Example 12-25.

Example 12-25 Host variable declaration in DB2 ESQL/C

[...]EXEC SQL BEGIN DECLARE SECTION;

sqlint32 rowcount;char dbname[9];

EXEC SQL END DECLARE SECTION;[...]

Even if the declaration of host variables is identical, you should be aware of some differences in what types of variables you are allowed to declare in the section.

Integer variablesIf you want to declare an integer variable, you have to use sqlint32 or sqlint16. The C-int-variables are not accepted by the DB2 precompiler.

Pointer (C strings)In IDS, you can declare a pointer to a C string, as shown in Example 12-26.

Example 12-26 Dynamic C string declaration in Informix

EXEC SQL BEGIN DECLARE SECTION;char *mycstr;

EXEC SQL END DECLARE SECTION;

DB2 allows you the same declaration, but it has a different meaning. This does not declare a pointer to the first character of a null-terminated C string. It declares


a pointer to a single char. To achieve a similar behavior as in IDS, you have to deal with the SQLDA structure that allows dynamically created C string host variables.

AssignmentsAs with IDS, you can assign values to host variables in the declare section. You should have a special look at the C string declarations and assignments in Example 12-27.

Example 12-27 DB2 version of assignments in the declare section

EXEC SQL BEGIN DECLARE SECTION;sqlint32 colint = 42; /* ok */char *ptrchar1 = “I’m invalid.”; /* wrong */char arrchar1[] = “I’m invalid, too.”; /* wrong */char arrchar2[128] = “I’m fine.”; /* ok */

EXEC SQL END DECLARE SECTION;

C structuresThe declaration of C structures in DB2 is slightly different than in IDS. It is not neccesary to name a C structure, but you need to name the variable that represents the C structure, as shown in Example 12-28.

Example 12-28 Using C structures in DB2 ESQL/C

EXEC SQL BEGIN DECLARE SECTION;struct {

sqlint32 col1;char col2[11];

} mystruct;EXEC SQL END DECLARE SECTION;[...]EXEC SQL INSERT INTO mytable (:mystruct);[...]

TypedefThe reserved C keyword typedef is not allowed in declare sections at all.

12.9.2 JDBCIf your application is written in JDBC, it might be relatively simple to port this application to DB2. Conceptually, only a few changes have to be performed.

You should be aware that DB2 delivers a JDBC Type 4 driver with Version 8. However, you still can find a Type 2 and Type 3 JDBC driver. The JDBC driver types have different URLs, as shown in Table 12-4 on page 388.


Table 12-4 DB2 JDBC drivers

Connection stringThe connection string for the DB2 JDBC driver is, of course, different from the IDS version. Example 12-29 shows this.

Example 12-29 Establishing a JDBC connection against a DB2 database

import java.sql.*;

class rsetClient {public static void main (String args []) throws SQLException {

// Load DB2 JDBC application drivertry {

Class.forName("COM.ibm.db2.jdbc.app.DB2Driver");}catch (Exception e) {

e.printStackTrace();}// Connect the databaseConnection conn =

DriverManager.getConnection("jdbc:db2:dbname","uid","pwd");}

}

12.9.3 ODBC/CLIDB2 Call Level Interface (DB2 CLI) is the IBM callable SQL interface to the DB2 family of database servers. It is a C and C++ application programming interface for relational database access that uses function calls to pass dynamic SQL statements as function arguments. It is an alternative to embedded dynamic SQL. But unlike embedded SQL, DB2 CLI does not require host variables or a precompiler.

DB2 CLI is based on the Microsoft Open Database Connectivity (ODBC) specification and the International Standard for SQL/CLI. These specifications

JDBC type URL

Type 2 COM.ibm.db2.jdbc.app.DB2Driver(only for applications)

Type 3 (deprecated) COM.ibm.db2.jdbc.net.DB2Driver (only for applets)

Type 4 com.ibm.db2.jcc.DB2Driver (for applications and applets)


were chosen as the basis for the DB2 Call Level Interface in an effort to follow industry standards and to provide a shorter learning curve for those application programmers already familiar with either of these database interfaces. In addition, some DB2-specific extensions have been added to help the application programmer specifically exploit DB2 features.

The DB2 CLI driver also acts as an ODBC driver when loaded by an ODBC driver manager. It conforms to ODBC 3.51.

Setting up the CLI environmentRuntime support for DB2 CLI applications is contained in all DB2 UDB clients. Support for building and running DB2 CLI applications is contained in the DB2 Application Development (DB2 AD) Client.

The CLI/ODBC driver will auto bind on the first connection to the database, provided the user has the appropriate privilege or authorization. The administrator might want to perform the first connect or explicitly bind the required files.

Procedure In order for a DB2 CLI application to successfully access a DB2 database:

1. Ensure that the DB2 CLI/ODBC driver was installed during the DB2 client install.

2. Catalog the DB2 database and note if the database is being accessed from a remote client. On the Windows platform, you can use the CLI/ODBC settings GUI to catalog the DB2 database.

3. Optional: Explicitly bind the DB2 CLI/ODBC bind files to the database with the command:

db2 bind ~/sqllib/bnd/@db2cli.lst blocking all messages cli.msg \grant public

On the Windows platform, you can use the CLI/ODBC settings GUI to bind the DB2 CLI/ODBC bind files to the database.

4. Optional: Change the DB2 CLI/ODBC configuration keywords by editing the db2cli.ini file, located in the sqllib directory on Windows, and in the sqllib/cfg directory on UNIX platforms.

On the Windows platform, you can use the CLI/ODBC settings GUI to set the DB2 CLI/ODBC configuration keywords.


12.9.4 C++Informix offers a proprietary C++ API that provides classes and methods to access an IDS database. Behind the scenes, the C++ API is a wrapper that maps the non-object-orientated Informix ESQL/C to an object-orientated environment.

The Informix C++ API does not support access to DB2.

You should consider using DB2 ESQL/C, which also allows embedding into C++, or use ODBC/CLI functions.

12.9.5 Large objectsLarge objects (such as a binary large object, or BLOB) are data types that can store a variable length of any type of data. IDS defines two different types of BLOBs: SIMPLE BLOBs (Versions 7 and 9) and SMART BLOBs (Version 9 only).

Both types of IDS BLOBs are differentiated into two subtypes of large objects. BYTE and TEXT are subtypes of SIMPLE BLOBs, while BLOB and CLOB are subtypes of SMART BLOBs. This differentiation is made for developers or users. If you work with a TEXT or CLOB, it means that this column contains printable information. When working with a BYTE or BLOB, it indicates that a column of such type can contain any binary information.

DB2 also supports large objects. In the following sections, we explain how to react when an IDS large object has to be converted to DB2. Table 10-2 on page 327 shows the data type mappings of large objects.

IDS uses a loc_t structure to handle SIMPLE BLOBs. When working with SMART BLOBs, a special type of host variable is used, which is similar to the DB2 declaration of large objects.

If you declare a large object in DB2 you have three different declaration techniques, as described in the following three sections.

LOB host variableSelect the entire LOB value into a host variable. The entire LOB value is copied from the server to the client. This method is inefficient and sometimes not feasible. Host variables use the client memory buffer, which might not have the capacity to hold larger LOB values. Example 12-30 on page 391 shows this method.


Example 12-30 Using the DB2 LOB host variable

EXEC SQL BEGIN DECLARE SECTION;SQL TYPE IS CLOB (1k) myclob;sqlint16 myclob_ind;

EXEC SQL END DECLARE SECTION;[...]EXEC SQL DECLARE cur1 CURSOR FOR

SELECT clobcolumn FROM mytab;

EXEC SQL OPEN cur1;EXEC SQL FETCH cur1 INTO :myclob:myclob_ind;[...]printf (“length of clob: %d\n”, myclob.length);[...]

Consider the following declaration:

SQL TYPE IS CLOB (1k) myclob;

This declaration results in a C structure:

static struct myclob_t { sqluint32 length; /* length of data */char data[1024]; /* the actual data */

} myclob;

LOB locator host variableSelect only a LOB locator into a host variable. The LOB value remains on the server, and the LOB locator moves to the client. If the LOB value is very large and is needed only as an input value for one or more subsequent SQL statements, it is best to keep the value in a locator. The use of a locator eliminates any client/server communication traffic needed to transfer the LOB value to the host variable and back to the server. Example 12-31 shows this method.

Example 12-31 Using the DB2 LOB locator host variable

EXEC SQL BEGIN DECLARE SECTION;SQL TYPE IS CLOB_LOCATOR my_locator;

EXEC SQL END DECLARE SECTION;[...]EXEC SQL FREE LOCATOR :my_locator;


SQL TYPE IS CLOB_LOCATOR my_locator;


This declaration results in a C variable declaration:

sqlint32 my_locator; /* LOB handle */

LOB file host variableSelect the entire LOB value into a file reference variable. The LOB value (or a part of it) is moved to a file at the client without going through the application memory, as shown in Example 12-32.

Example 12-32 Using the DB2 LOB file host variable

EXEC SQL BEGIN DECLARE SECTION;SQL TYPE IS BLOB_FILE myfile;

EXEC SQL END DECLARE SECTION;[...]strcpy (myfile.name, “blob.dat”);myfile.name_length = strlen (myfile.name);myfile.file_options = SQL_FILE_OVERWRITE;[...]EXEC SQL SELECT blobcolumn INTO :myfile ...


SQL TYPE IS BLOB_FILE myfile;

This declaration results in a C structure:

struct {sqluint32 name_length; /* length of file name */sqluint32 data_length; /* write file (SELECT): bytes written */

/* read file (INSERT): how many byes to read */sqluint32 file_options; /* SQL_FILE_READ, SQL_FILE_CREATE, */

/* SQL_FILE_OVERWRITE, SQL_FILE_APPEND */char name[255]; /* file name */

} myfile;

12.9.6 SQLCAThe SQL Communication Area is a standardized interface that is used by an application to exchange non-user data information with the database engine.

Even if the SQLCA structure is standardized, database vendors tend to expand the structure. Therefore, you might have to handle some differences between IDS and DB2 SQLCA structures.

Table 12-5 on page 393 shows all elements of the DB2 SQLCA structure in a generalized form. The data types noted are SQL data types. Of course,


depending on the programming interface you use, appropriate data types are provided.

Table 12-5 DB2 SQLCA structure description

Name Data type Field value

sqlcaid CHAR(8) An easy to identify field for storage dumps containing SQLCA. The sixth byte is 'L' if line number information is returned from parsing an SQL procedure body.

sqlcabc INTEGER Contains the length of the SQLCA (136 bytes).

sqlcode INTEGER Contains the SQL return code. The code means:

0: Successful execution (although one or more SQLWARN indicators might be set).

positive: Successful execution, but with a warning condition.

negative: Error condition.

sqlerrml SMALLINT Length indicator for sqlerrmc, in the range 0 through 70. 0 means that the value of sqlerrmc is not relevant.

sqlerrmc VARCHAR (70) Contains one or more tokens, separated by X'FF', that are substituted for variables in the descriptions of error conditions.

This field is also used when a successful connection is completed.

When a NOT ATOMIC compound SQL statement is issued, it might contain information about up to seven errors.

sqlerrp CHAR(8) Begins with a three-letter identifier indicating the product, followed by five digits indicating the version, release, and modification level of the product. For example, SQL08010 means DB2 Universal Database Version 8 Release 1 Modification Level 0.

If SQLCODE indicates an error condition, this field identifies the module that returned the error.

This field is also used when a successful connection is completed.


sqlerrd ARRAY Six INTEGER variables that provide diagnostic information. These values are generally empty if there are no errors, except for sqlerrd(6) from a partitioned database.

sqlerrd(1) INTEGER If connection is invoked and successful, this contains the maximum expected difference in length of mixed character data (CHAR data types) when converted to the database code page from the application code page. A value of 0 or 1 indicates no expansion; a value greater than 1 indicates a possible expansion in length; a negative value indicates a possible contraction. On successful return from an SQL procedure, this contains the return status value from the SQL procedure.

sqlerrd(2) INTEGER If connection is invoked and successful, this contains the maximum expected difference in length of mixed character data (CHAR data types) when converted to the application code page from the database code page. A value of 0 or 1 indicates no expansion; a value greater than 1 indicates a possible expansion in length; a negative value indicates a possible contraction. If the SQLCA results from a NOT ATOMIC compound SQL statement that encountered one or more errors, the value is set to the number of statements that failed.



sqlerrd(3) INTEGER If PREPARE is invoked and successful, this contains an estimate of the number of rows that will be returned. After INSERT, UPDATE, DELETE, or MERGE, this contains the actual number of rows that qualified for the operation. If compound SQL is invoked, this contains an accumulation of all sub-statement rows. If CONNECT is invoked, this contains 1 if the database can be updated, or 2 if the database is read only. If the OPEN statement is invoked, and the cursor contains SQL data change statements, this field contains the sum of the number of rows that qualified for the embedded INSERT, UPDATE, DELETE, or MERGE operations.If CREATE PROCEDURE for an SQL procedure is invoked, and an error is encountered when parsing the SQL procedure body, this contains the line number where the error was encountered. The sixth byte of sqlcaid must be 'L' for this to be a valid line number.

sqlerrd(4) INTEGER If PREPARE is invoked and successful, this contains a relative cost estimate of the resources required to process the statement. If compound SQL is invoked, this contains a count of the number of successful sub-statements. If CONNECT is invoked, this contains 0 for a one-phase commit from a down-level client; 1 for a one-phase commit; 2 for a one-phase, read-only commit; and 3 for a two-phase commit.

sqlerrd(5) INTEGER Contains the total number of rows deleted, inserted, or updated as a result of both:� The enforcement of constraints after a successful

delete operation � The processing of triggered SQL statements from

activated triggers If compound SQL is invoked, this contains an accumulation of the number of such rows for all sub-statements. In some cases, when an error is encountered, this field contains a negative value that is an internal error pointer. If CONNECT is invoked, this contains an authentication type value of 0 for server authentication; 1 for client authentication; 2 for authentication using DB2 Connect; 3 for DCE security services authentication; and 255 for unspecified authentication.



sqlerrd(6) INTEGER For a partitioned database, contains the partition number of the partition that encountered the error or warning. If no errors or warnings were encountered, this field contains the partition number of the coordinator node. The number in this field is the same as that specified for the partition in the db2nodes.cfg file.

sqlwarn ARRAY A set of warning indicators, each containing a blank or W. If compound SQL is invoked, this contains an accumulation of the warning indicators set for all sub-statements.

sqlwarn0 CHAR(1) Blank if all other indicators are blank; contains W if at least one other indicator is not blank.

sqlwarn1 CHAR(1) Contains W if the value of a string column was truncated when assigned to a host variable. Contains N if the null terminator was truncated. Contains A if the CONNECT or ATTACH is successful, and the authorization name for the connection is longer than 8 bytes.

sqlwarn2 CHAR(1) Contains W if null values were eliminated from the argument of a function.

sqlwarn3 CHAR(1) Contains W if the number of columns is not equal to the number of host variables.

sqlwarn4 CHAR(1) Contains W if a prepared UPDATE or DELETE statement does not include a WHERE clause.

sqlwarn5 CHAR(1) Reserved for future use.

sqlwarn6 CHAR(1) Contains W if the result of a date calculation was adjusted to avoid an impossible date.

sqlwarn7 CHAR(1) Reserved for future use.

If CONNECT is invoked and successful, contains 'E' if the DYN_QUERY_MGMT database configuration parameter is enabled.

sqlwarn8 CHAR(1) Contains W if a character that could not be converted was replaced with a substitution character.

sqlwarn9 CHAR(1) Contains W if arithmetic expressions with errors were ignored during column function processing.



12.9.7 SQLDAAn SQL descriptor area (SQLDA) is a collection of variables required for execution of the SQL DESCRIBE statement. The SQLDA variables are options that can be used by the PREPARE, OPEN, FETCH, and EXECUTE statements. An SQLDA communicates with dynamic SQL. It can be used in a DESCRIBE statement, modified with the addresses of host variables, and then reused in a FETCH or EXECUTE statement.

SQLDAs are supported for all languages, but predefined declarations are provided only for C, REXX, FORTRAN, and COBOL.

The meaning of the information in an SQLDA depends on its use. In PREPARE and DESCRIBE, an SQLDA provides information to an application program about a prepared statement. In OPEN, EXECUTE, and FETCH, an SQLDA describes host variables.

Because the entire explanation of how to work with the SQLDA structure is beyond of this book, refer to the DB2 Application Programming Guide for common server V2, S20H-4643, the DESCRIBE section of IBM DB2 UDB SQL Reference Volume 2 V8.2, SC09-4845, and online guides, available at:

http://publib.boulder.ibm.com/infocenter/db2v8luw/topic/com.ibm.db2.udb.doc/admin/r0001030.htm

12.10 Development integrationDB2 comes with several integration packages that enable you to extend your existing development environment. In this section, we describe a few of them.

12.10.1 IBM WebSphere Studio Application DeveloperIn the DB2 Development Center, you can write stored procedures (Java and SQL). The Development Center is also available as a WebSphere Studio Application Developer plug-in that enables you to integrate the DB2 procedure development (see Figure 12-14 on page 398).

sqlwarn10 CHAR(1) Contains W if there was a conversion error when converting a character data value in one of the fields in the SQLCA.

sqlstate CHAR(5) A return code that indicates the outcome of the most recently executed SQL statement.



http://publib.boulder.ibm.com/infocenter/db2v8luw/topic/com.ibm.db2.udb.doc/admin/r0001030.htm

Figure 12-14 DB2 Procedure Builder integrated into WebSphere

12.10.2 Microsoft .NET add-inThis add-in enables you to develop stored procedures in a Microsoft .NET environment. This add-in is part of the DB2 Personal Developer Edition. See Figure 12-15 on page 399.


Figure 12-15 DB2 add-in for Microsoft .NET environment


Chapter 13. Security

Security has become a very important issue over the last few years. Countless attacks from the Internet have caused significant problems that have resulted in very high costs to many companies. Modern software must be armed against these and other attacks. Fortunately, DB2 supports several types of security constructs.

In this chapter, we describe some of the differences in DB2 security when compared with IDS. We also include a discussion about a number of security features that DB2 provides.

13


13.1 ConceptsSecurity constructs such as user and group authentication, password encryption, and alternative authentication methods are common with both DB2 and IDS and thus should not be a problem during transition. DB2 also offers a few additional security levels, but most of the privileges are comparable to those known by IDS.

When discussing security, two terms must be clarified:

Data encryption Sensitive data is stored encrypted on a storage device or is transmitted to a sender/receiver cryptographically secured.

Authentication Only permitted personnel are allowed to log on to sensitive servers, such as a database engine.

In the subsequent sections, we discuss the IDS and DB2 security mechanisms.

13.1.1 AuthoritiesDB2 contains predefined authorities that are comparable to those of IDS, such as DBA and RESOURCE. If a user belongs to one of these authorities, that user automatically gets a set of special privileges. When you work with DB2 authorities, you must keep in mind that DB2 authorities belongs to an instance or to a database, or to both.

The following list describes all authorities known by DB2:

� SYSADM: System administration authority. SYSADM authority is the highest level of authority and has control over all the resources created and maintained by the database manager. SYSADM authority includes all the authorities of DBADM, SYSCTRL, and SYSMAINT and the authority to grant or revoke DBADM authorities.

� SYSCTRL: System control authority. SYSCTRL authority is the higher level of system control authority and applies only to operations affecting system resources. It does not allow direct access to data. This authority includes privileges to create, update, or drop a database; to stop an instance or a database; and to create or drop a table space.

� SYSMAINT: System maintenance authority. SYSMAINT authority is the second level of system control authority. A user with SYSMAINT authority can perform maintenance operations on all databases associated with an instance. It does not allow direct access to data. This authority includes privileges to update database configuration files; to back up a database or a table space; to restore an existing database; and to monitor a database.


� SYSMON: Defines the group name with system monitor (SYSMON) authority for the instance. Users having SYSMON authority at the instance level give them the ability to take database system monitor snapshots of a database manager instance or its databases.

� DBADM: Database administration authority. DBADM authority is the administrative authority specific to a single database. This authority includes privileges to create objects, issue database commands, and access the data in any of its tables through SQL statements. DBADM authority also includes the authority to grant or revoke CONTROL and individual privileges.

Figure 13-1 provides a graphical depiction of the DB2 authorities.

Figure 13-1 Hierarchy of DB2 authorities

Authorities are set within the DB2 registry. Therefore, you cannot pass an authority through an SQL GRANT statement, but you have to use the DB2 command line processor or the DB2 Control Center.

The authorities can also be viewed, as shown in Example 13-1 on page 404.

SYSMON(System Monitor Administrator)

DBADM(Database Administrator)

SYSMAINT(System Maintenance Administrator)

SYSCTRL(System Resouce Administrator)

SYSADM(System Administrator)

Database users with privileges

Chapter 13. Security 403

Example 13-1 Location of authority assignment

db2 get dbm cfg...Unit of work (DFT_MON_UOW) = OFF Monitor health of instance and databases (HEALTH_MON) = ON

SYSADM group name (SYSADM_GROUP) = DB2GRP1 SYSCTRL group name (SYSCTRL_GROUP) = SYSMAINT group name (SYSMAINT_GROUP) = SYSMON group name (SYSMON_GROUP) =

Client Userid-Password Plugin (CLNT_PW_PLUGIN) = Client Kerberos Plugin (CLNT_KRB_PLUGIN) =...

13.1.2 Roles and groupsIDS enables you to create database-specific user groups, called roles. After a role has been defined, users are assigned to the role and further permissions are granted to the role.

DB2 is aware of groups and calls them just that, groups. But in contrast to IDS, groups are not defined at database level but at operating system (OS) level. DB2 uses OS groups.

Another difference between DB2 and IDS regarding groups is that with DB2 you do not have to execute the SET ROLE SQL command to assign a user to a group role in order to inherit the permissions of a group. A user inherits all permissions of a group automatically, because the user login group is already known.

The permissions to a group are granted and revoked similar to IDS. Example 13-2 shows the commands to do so.

Example 13-2 Grant and revoke permissions to and from a group

GRANT CONNECT ON DATABASE TO <groupname>;REVOKE CONNECT ON DATABASE FROM <groupname>;

PublicThe purpose of the PUBLIC group is the same as in IDS. Every user is assigned to this group. By that, we mean that all users who are known to the operating system, independent of what authentication method is used.


As with IDS, you must be careful when working with this group. If not administered closely, a security hole can be produced. Example 13-3 shows a situation where the permission are not set as you might expect. That is, user u1 is still allowed to select data from table t1, because this user is part of the group PUBLIC.

Example 13-3 Is user u1 allowed to select table t1?

# uid=db2inst1db2=> create database ifmx2db2=> connect to ifmx2db2=> create table t1 (col1 int)=> grant connect on database to public=> grant select on table t1 to u1=> grant select on table t1 to public=> revoke select on table t1 from u1

13.1.3 Security levelsBoth IDS and DB2 apply security on different database objects. You can have specific privileges on tables and other specific privileges on the columns of that table.

As with IDS, GRANT and REVOKE SQL statements are used to assign privileges to a user. The following sections list those privileges with their description.

Default privilegesDB2 does not grant default privileges as IDS does. If you grant database CONNECT privilege to a user, the user does not automatically have permission to query any table in the database. All subsequent privileges have to be configured manually. You will find that DB2 is more restrictive in this area than IDS.

Database privileges The syntax to administer database privileges in DB2 is slightly different than in IDS. Figure 13-2 on page 406 shows the syntax to grant database privileges.


Figure 13-2 Database privileges syntax

See Example 13-4 for an example of the Grant and Revoke commands.

Example 13-4 Granting and revoking permissions

GRANT CONNECT ON DATABASE TO mark;REVOKE CONNECT ON DATABASE FROM nora;

DB2 offers more specific privileges than IDS. Some of these additional privileges are not covered here, because IDS has nothing comparable, so they are, therefore, not relevant to a discussion on transitioning.

Figure 13-3 on page 407 provides a good overview of the privileges and how the relate. We describe most of those privileges in this section to give you a good understanding of them.


Figure 13-3 Privileges overview

The applicable privileges and their descriptions are:

� BINDADD: Grants the authority to create packages. The creator of a package automatically has the CONTROL privilege on that package and retains this privilege even if the BINDADD authority is subsequently revoked.

� CONNECT: Grants the authority to access the database.

� CREATETAB: Grants the authority to create base tables. The creator of a base table automatically has the CONTROL privilege on that table. The creator retains this privilege even if the CREATETAB authority is subsequently revoked. There is no explicit authority required for view creation. A view can be created at any time if the authorization ID of the statement used to create the view has either a CONTROL or SELECT privilege on each base table of the view.

� CREATE_EXTERNAL_ROUTINE: Grants the authority to register external routines. Care must be taken that routines so registered will not have adverse side effects. (For more information, see the description of the THREADSAFE clause on the CREATE or ALTER routine statements.) After an external routine has been registered, it continues to exist, even if CREATE_EXTERNAL_ROUTINE is subsequently revoked.

SYSADMSYSCTRL

SYSMONSYSMAINT

TABLESPACEUSE

DATABASEDBADM

CONNECT

IMPLICIT_SCHEMA

BINDADD

CREATETABCREATE_NOT_FENCED

LOAD

SCHEMACREATEINALTERINDROPIN

PACKAGECONTROL

EXECUTEBIND

TABLE (VIEW)

CONTROL

ALL

ALTER

INSERT

UPDATESELECT

CONTROLINDEX

REFERENCES

SEQUENCEUSE

ROUTINEEXECUTE


� CREATE_NOT_FENCED_ROUTINE: Grants the authority to register routines that execute in the database manager’s process. Care must be taken that routines so registered will not have adverse side effects. (For more information, see the description of the FENCED clause on the CREATE or ALTER routine statements.) After a routine has been registered as not fenced, it continues to run in this manner, even if CREATE_NOT_FENCED_ROUTINE is subsequently revoked. CREATE_EXTERNAL_ROUTINE is automatically granted to an authorization name that is granted CREATE_NOT_FENCED_ROUTINE authority.

� IMPLICIT_SCHEMA: Grants the authority to implicitly create a schema. It enables any user to create a schema implicitly by creating an object using a CREATE statement with a schema name that does not already exist. SYSIBM becomes the owner of the implicitly created schema, and PUBLIC is given the privilege to create objects in this schema.

� DBADM: Grants the database administrator authority and all other database authorities. A database administrator has all privileges against all objects in the database and can grant these privileges to others.

� LOAD: Grants the authority to load in this database. This authority gives a user the right to use the LOAD utility in this database. SYSADM and DBADM also have this authority by default. However, if a user only has LOAD authority (not SYSADM or DBADM), the user is also required to have table-level privileges. In addition to the LOAD privilege, the user is required to have:

– INSERT privilege on the table for LOAD with mode INSERT, TERMINATE (to terminate a previous LOAD INSERT), or RESTART (to restart a previous LOAD INSERT)

– INSERT and DELETE privilege on the table for LOAD with mode REPLACE, TERMINATE (to terminate a previous LOAD REPLACE), or RESTART (to restart a previous LOAD REPLACE)

– INSERT privilege on the exception table, if such a table is used as part of LOAD

� QUIESCE_CONNECT: Grants the authority to access the database while it is quiesced.

Index privilegesAl with IDS, in DB2, there is a privilege for controlling indexes. We show the syntax of the commands in Figure 13-4 on page 409. CONTROL grants the

Note: All other database authorities are implicitly and automatically granted to an authorization name that is granted DBADM authority.


privilege to drop the index. This is the CONTROL authority for indexes, which is automatically granted to creators of indexes.

Figure 13-4 GRANT and REVOKE index syntax

Package privilegesPackages contain static SQL statements which are executed by an application. Before an application can run against a DB2 database, the application specific package has to be bound/registered in the database. Figure 13-5 shows the syntax for the grant or revoke of a package privilege. In 12.3, “Packages” on page 355, we provide a description of packages.

Figure 13-5 GRANT and REVOKE package syntax

TOGRANT CONTROL ON INDEX index-name authorization-name

PUBLIC

GROUPUSER

,

REVOKE CONTROL ON INDEX index-name FROM authorization-name

PUBLIC

GROUPUSER

,

GRANT package-id

,

ON PACKAGEschema-name.CONTROL

EXECUTE

BIND

TO authorization-name

PUBLIC

GROUPUSER

,

WITH GRANT OPTION

REVOKE package-id

,

ON PACKAGEschema-name.CONTROL

EXECUTE

BIND

FROM authorization-name

PUBLIC

GROUPUSER

,

BY ALL


The following is a list of the privileges:

� BIND: Grants the privilege to bind a package. The BIND privilege allows a user to re-issue the BIND command against that package, or to issue the REBIND command. It also allows a user to create a new version of an existing package. In addition to the BIND privilege, a user must hold the necessary privileges on each table referenced by static DML statements contained in a program. This is necessary, because authorization on static DML statements is checked at bind time.

� CONTROL: Grants the privilege to rebind, drop, or execute the package and extend package privileges to other users. The CONTROL privilege for packages is automatically granted to creators of packages. A package owner is the package binder, or the ID specified with the OWNER option at bind/precompile time. BIND and EXECUTE are automatically granted to an authorization name that is granted the CONTROL privilege. CONTROL grants the ability to grant the above privileges (except for CONTROL) to others.

� EXECUTE: Grants the privilege to execute the package.

� WITH GRANT OPTION: Allows the specified authorization name to GRANT the privileges to others. If the specified privileges include CONTROL, the WITH GRANT OPTION applies to all of the applicable privileges except for CONTROL (SQLSTATE 01516).

Routine privilegesRoutine is a collective term for stored procedures, functions, and methods. It is irrelevant to privileges and the programming language in which a routine has been created. EXECUTE grants the privilege to run the identified user-defined function, method, or stored procedure.

Schema privilegesA schema is a namespace where database objects are consolidated. A database can have many schemas. Figure 13-6 on page 411 depicts the syntax for granting and revoking schema privileges.


Figure 13-6 GRANT and REVOKE schema syntax

The following is a list of the schema privileges that can be granted or revoked.

� ALTERIN: Grants the privilege to alter or comment on all objects in the schema. The owner of an explicitly created schema automatically receives ALTERIN privilege.

� CREATEIN: Grants the privilege to create objects in the schema. Other authorities or privileges required to create the object (such as CREATETAB) are still required. The owner of an explicitly created schema automatically receives the CREATEIN privilege. An implicitly created schema has the CREATEIN privilege automatically granted to PUBLIC.

� DROPIN: Grants the privilege to drop all objects in the schema. The owner of an explicitly created schema automatically receives the DROPIN privilege.

Sequence privilegesThe sequence syntax is depicted in Figure 13-7, and the sequence privilege that can be granted or revoked is USAGE, which grants the privilege to reference a sequence using nextval-expression or prevval-expression.

Figure 13-7 GRANT and REVOKE sequence syntax

GRANT schema-name

,

ON SCHEMACREATEINDROPIN

ALTERIN

TO authorization-name

PUBLIC

,

WITH GRANT OPTION

REVOKE schema-name

,

ON SCHEMACREATEINDROPIN

ALTERIN

FROM authorization-name

PUBLIC

,

BY ALLGROUPUSER

USERGROUP

GRANT USAGE ON SEQUENCE sequence-name TO PUBLIC

REVOKE USAGE ON SEQUENCE sequence-name FROM PUBLIC


Table, view, and nickname privilegesMost of the table privileges found here are identical to the those of IDS and are described in the following list:

� ALL (ALL PRIVILEGES): Grants all the appropriate privileges, except CONTROL, on the base table, view, or nickname named in the ON clause. If the authorization ID of the statement has CONTROL privilege on the table, view, or nickname, or DBADM or SYSADM authority, all the privileges applicable to the object (except CONTROL) are granted. Otherwise, the privileges granted are all those grantable privileges that the authorization ID of the statement has on the identified table, view, or nickname. If ALL is not specified, one or more of the keywords in the list of privileges must be specified.

� ALTER: Grants the privilege to:

– Add columns to a base table definition.– Create or drop a primary key or unique constraint on a base table.– Create or drop a foreign key on a base table.– Create or drop a check constraint on a base table.– Create a trigger on a base table.– Add, reset, or drop a column option for a nickname.– Change a nickname column name or data type.– Add or change a comment on a base table or a nickname.

The REFERENCES privilege on each column of the parent table is also required.

� CONTROL: Grants:

– All of the appropriate privileges in the list, that is:

• ALTER, CONTROL, DELETE, INSERT, INDEX, REFERENCES, SELECT, and UPDATE to base tables

• CONTROL, DELETE, INSERT, SELECT, and UPDATE to views

• ALTER, CONTROL, INDEX, and REFERENCES to nicknames

• The ability to grant the above privileges (except for CONTROL) to others

– The ability to drop the base table, view, or nickname. This ability cannot be extended to others on the basis of holding the CONTROL privilege. The only way that it can be extended is by granting the CONTROL privilege itself and that can only be done by someone with SYSADM or DBADM authority.

– The ability to execute the runstats utility on the table and indexes.

– The ability to issue the SET INTEGRITY statement against a base table, materialized query table, or staging table.


The definer of a base table, materialized query table, staging table, or nickname automatically receives the CONTROL privilege.

The definer of a view automatically receives the CONTROL privilege if the definer holds the CONTROL privilege on all tables, views, and nicknames identified in the full select.

� DELETE: Grants the privilege to delete rows from the table or updatable view.

� INDEX: Grants the privilege to create an index on a table, or an index specification on a nickname. This privilege cannot be granted on a view. The creator of an index or index specification automatically has the CONTROL privilege on the index or index specification (authorizing the creator to drop the index or index specification). In addition, the creator retains the CONTROL privilege even if the INDEX privilege is revoked.

� INSERT: Grants the privilege to insert rows into the table or updatable view and to run the IMPORT utility.

� REFERENCES: Grants the privilege to create and drop a foreign key referencing the table as the parent. If the authorization ID of the statement has one of:

– DBADM or SYSADM authority.

– CONTROL privilege on the table.

– REFERENCES WITH GRANT OPTION on the table, and then the grantee or grantees can create referential constraints using all columns of the table as parent key, even those added later using the ALTER TABLE statement. Otherwise, the privileges granted are all those grantable column REFERENCES privileges that the authorization ID of the statement has on the identified table. The privilege can be granted on a nickname, although foreign keys cannot be defined to reference nicknames.

� REFERENCES (column-name,...): Grants the privilege to create and drop a foreign key using only those columns specified in the column list as a parent key. Each column name must be an unqualified name that identifies a column of the table identified in the ON clause. Column level REFERENCES privilege cannot be granted on typed tables, typed views, or nicknames (SQLSTATE 42997).

� SELECT: Grants the privilege to:

– Retrieve rows from the table or view.– Create views on the table.– Run the EXPORT utility against the table or view.


� UPDATE: Grants the privilege to use the UPDATE statement on the table or updatable view identified in the ON clause. If the authorization ID of the statement has one of:

– DBADM or SYSADM authority.– CONTROL privilege on the table or view.– UPDATE WITH GRANT OPTION on the table or view, and then the

grantee or grantees can update all updatable columns of the table or view on which the grantor has with grant privilege as well as those columns added later using the ALTER TABLE statement. Otherwise, the privileges granted are all those grantable column UPDATE privileges that the authorization ID of the statement has on the identified table or view.

� UPDATE (column-name,...): Grants the privilege to use the UPDATE statement to update only those columns specified in the column list. Each column name must be an unqualified name that identifies a column of the table or view identified in the ON clause. Column level UPDATE privilege cannot be granted on typed tables, typed views, or nicknames (SQLSTATE 42997).

Table space privilegesThe table space privileges involve actions on the table spaces in a database. The following are the privileges that can be used:

� USE: Grants the privilege to specify or default to the table space when creating a table. The creator of a table space automatically receives USE privilege with the grant option.

� OF TABLESPACE: Identifies the table space on which the USE privilege is to be granted. The table space cannot be SYSCATSPACE (SQLSTATE 42838) or a system temporary table space (SQLSTATE 42809).

13.2 Client/server securityIn a client/server environment, your data might also require protection as it is being transmitted over a network between the participants. To protect your data, you can choose to encrypt the data before it is transmitted. IDS introduced client/server encryption in Version 9.40.

DB2 UDB introduces client/server encryption in Version 8.2. To use client/server encryption, you have to enable the feature at the instance level. For an example of how to do that, see Example 13-5.

Example 13-5 DB2 encryption

Database manager authentication (AUTHENTICATION) = DATA_ENCRYPT


DB2 offers two different settings for client/server encrypted communication:

� DATA_ENCRYPT: All clients must use data encryption.

� DATA_ENCRYPT_CMP: Clients can use data encryption. The mode is for compatibility reasons.

The encryption method is a 56-bit DES.

As an alternative, you can also encrypt transmitted data in DB2 by choosing a hardware solution. For example, you can encrypt data using an SSH tunnel, as described in the next section.

Encryption through an SSH tunnelRemote shells usually do not provide an encrypted link to the opponent. Neither the data nor password are sent encrypted. This might be a security problem when the data is crossing the Internet especially.

Secure Shell (SSH) provides an encrypted connection. All data that is sent over the connection established by the SSH is encrypted. SSH is not only a Telnet replacement, but it also allows port forwarding (tunneling). Because of this, many types of software often uses the tunneling mechanism to achieve encryption. DB2 can use SSH, too.

Depending on the network environment you are working with, DB2 offers several topologies where the SSH tunnel can be used. The following subsections give you an impression about how DB2 and SSH can be combined.

Two-tier SSH tunnel architectureFigure 13-8 shows a two-tier client/server encryption using SSH.

Figure 13-8 Two-tier client/server encryption using SSH

SSH

Listening at 13131 (local host)

DB2 client

Forwarding to 13131 (server host)

SSH

Listening at 13131 (remote host)

DB2 client

Forwarding to 60012 (localhost)

Encrypted Data


This two-tier architecture requires an installation of the SSH package on the client and the server host. Therefore, the administration of such an environment can become problematic if the there is a large number of clients.

This example assumes that the DB2 instance is listening at network port 60012. Under normal circumstances, a client would try to connect this port directly. But when using an SSH tunnel, the client will connect a local SSH instead. The local SSH will forward the request of the client to the server host. Of course, there has to be an SSH installed, too. Because the data that is sent by the client host is encrypted, an SSH on the server host has to decrypt the data.

If the SSH on the server host is receiving the data, it decrypts it and forwards the data to the DB2 port. See Example 13-6.

Example 13-6 Activating port forwarding on the client side

ssh localhost -g -L 13131:greenland:13131

The above command line statement creates the first half of the SSH tunnel. All connections that try to open a socket at port 13131 are forwarded to host greenland port 13131. Next, the second half of the SSH tunnel has to be created.

Example 13-7 Activating port forwarding on the server side

ssh -localhost -g -L 13131:localhost:60012

If the SSH tunnel has been established, a DB2 client can be created. See Example 13-8 and Example 13-9.

Example 13-8 DB2 instance prepared for using the SSH tunnel

# uid=rootdb2icrt -a server -u db2fenc1 -p 60012 db2enc

# uid=db2encdb2set db2comm=tcpipdb2startdb2 create database secrets

Example 13-9 DB2 client using the SSH tunnel

db2 catalog tcpip node greenlnd remote localhost server 13131 \ remote_instance db2enc ostype aix

db2 catalog database secrets at node greenlnd


Three-tier SSH tunnel architectureThe three-tier architecture is more flexible than the two-tier SSH tunnel architecture. Because there is no need to install the SSH software package on the client and server, the three-tier architecture is easier to administer. If connection parameters are subject to change, or additional instances are installed, the modifications must be done at two servers at the most.

However, three-tier is not as secure as two-tier architecture. There is an unencrypted part of the connection. Therefore, a three-tier architecture is not practical for every environment. Figure 13-9 shows the three-tier SSH tunnel architecture.

Figure 13-9 Three-tier SSH tunnel architecture

13.3 Authentication methodsThis section describes the authentication methods that are available.

13.3.1 LDAPIDS introduced LDAP support in Version 9.40. Using LDAP enables you to administer user accounts at a central place (LDAP server). You no longer need to create users on the database server machine.

DB2 also includes LDAP support.

SSHSSH

Computer 1 Computer 2

DB2 client DB2 server

SSH Box 1 SSH Box 2

Encrypted Data

Fire

wal

l

Fire

wal

l

Unencrypted Data

Unencrypted Data


The directory service can also be used to store database catalog information in a central place.

13.3.2 PAMAuthentication through Pluggable Authentication Module (PAM) was introduced in IDS Version 9.40. PAM enables you to write your own methods to authenticate a user. IDS Version 9.40 and DB2 Version 8.2 are both aware of PAM. Examples of how to write your own authentication module are in the samples directory under security/plugins.


Chapter 14. Administrative operations

As you make the transition to DB2 from IDS, it is critical to understand how to administer the database. In this chapter, we provide an overview of the major administrative activities, including extensive examples. Topics that we cover include performance tuning, the graphical tools and wizards, system and database utilities, monitoring tools and advisors, and diagnostics.

14


14.1 Performance tuningTuning a server instance and a database must begin as part of installation and development before the data is laid out on disk and before the very first lines of code are written. This part of design is too often omitted, unfortunately, or left until after the system is operational and problems have already surfaced. Our discussion of performance and tuning here is intended to get you ahead of the curve and to give you a basic introduction to tuning DB2. We suggest you also refer to the IBM Redbook DB2 UDB ESE V8 non-DPF Performance Guide for High Performance OLTP and BI, SG24-6432. This book offers an exhaustive review of tuning with DB2, and we highly recommend it.

Regardless of the database, the discipline of tuning is the same. It begins with defining specific and measurable performance objectives, measuring them, and then making adjustments. The emphasis in this section is on DB2 UDB features that you will use throughout the life of your server and for which you need to plan. The key factors that you do have some control over are:

� Application design: Moving an existing design from one environment to another without adapting it is generally not recommended.

� Database design: Using the features of the database software to implement a logical design (tables, columns) and physical design (and thus placement of tables and indexes).

� Server architecture: Using the features and parameters of your server to the best effect.

There are two basic places in DB2 UDB for performance tuning: the instance and the database. However, they differ in their approach to performance tuning. In IDS, you tune the instance from the operating system point of view, controlling the resources allocated overall to the instance. The database is then tuned based on the layout of data, table schema, indexes, and the like. In DB2 UDB, performance tuning for the instance is still based on the operating system resource usage, and the database tuning is somewhat based on data layout, table schema, and indexes. Unlike IDS, each database can then be tuned to use a specific part of the resources allocated to the instance. As an example, in IDS, you allocate the buffer pool for the instance, no matter how many databases are in it. Also, transaction logging is accomplished using instance-wide logs. In DB2 UDB, each database has its own buffer pools and its own set of logs. These can be tuned differently for each database.

The DB2 UDB database has a significantly greater capacity (and complexity) for tuning than IDS, which results in a greater degree of control over the use of system resources.


Even though the configuration names and settings might be different, a database engine is a database engine, and both IDS and DB2 UDB are tuned by manipulating the same three components: memory, disk, and processes.

14.1.1 Buffer pool tuningAs with IDS, it is critical to tune memory appropriately. There are several parameters that control how memory is allocated and when it is flushed. As with IDS, you will need to experiment to determine the appropriate settings. To make your job easier, look at the “Quick-start tips for performance tuning” on page 425, and use the Configuration Advisor. In this section, we discuss some of the most important configuration parameters that are associated with buffer pool tuning.

The more active pages of the database that can be retained in memory, the better the query performance. Therefore, the larger the buffer pool the better. However, a buffer pool that is too large could cause memory paging at the OS level, so a guideline is to allocate the largest buffer pool that is possible without causing paging. In DB2 UDB, buffer pools are part of the database and not part of the instance, as they are for IDS. Each database has one default buffer pool with a size of 1000 pages for UNIX systems and 250 pages for Windows systems. Additional buffer pools can be created using the CREATE BUFFERPOOL statement, and if the SIZE value is set to -1, the BUFFPAGE value is used to size the buffer pool. For example, the following SQL statement creates a buffer pool with a size defined by the BUFFPAGE value:

CREATE BUFFERPOOL bp_mypool SIZE -1

After a buffer pool has been created, its size remains stable unless it is altered by the ALTER BUFFERPOOL statement. For example, the following SQL statement changes the size of the buffer pool to 20,000 pages:

ALTER BUFFERPOOL bp_mypool SIZE 20000

As you will recall from “Buffer pools” on page 24, buffer pools are created with a specific page size. Each table space needs a buffer pool with the same page size, so it is important to ensure that you have created sufficient buffer pools. You should also decide how many buffer pools are optimal. There are trade-offs in deciding whether to have one or multiple buffer pools.

With 32-bit versions of DB2, there is a limit on the total size of the buffer pools that can be defined regardless of the available real memory. No such restrictions apply to 64-bit versions of DB2, where real memory limits that cause operating system paging are most likely the problem with defining large buffer pools. The advantages of a single buffer pool are that it exploits efficient page management algorithm of DB2 to maintain a high buffer hit ratio by keeping the most active pages and important pages, such as index pages in memory, while migrating less

Chapter 14. Administrative operations 421

frequently used pages to disk. Having one buffer pool also requires no tuning after its size is chosen. The main disadvantage of a single buffer pool is that you cannot discriminate in favor of table spaces requiring high priority access with potentially low access rates when there are lower priority table spaces with higher activity rates using the same buffer pool.

The advantages and disadvantages of multiple buffer pools are the opposite of those for a single buffer pool. Multiple buffer pools offer greater flexibility for prioritizing the I/O performance of different table spaces, but require constant monitoring and tuning to keep them performing optimally.

If you decide to use more than one buffer pool, there are two recommended methods:

� Define at least three buffer pools: a smaller one for randomly accessed tables, a larger one for the rest of the tables, and a larger one for all the indexes. This prevents the tables that are randomly accessed from thrashing the main buffer pool and also separates out data pages from index pages.

� Define at least two buffer pools: one for all of the static tables, and a another for the data and index pages. This configuration allows the static tables to be retained in memory, and the most active data and index pages are also retained.

To view read and write cache rates, you can use either snapshots (see 14.6.5, “Snapshots” on page 511) or the optional DB2 Performance Expert tool (see 14.6.7, “DB2 Performance Expert” on page 518).

Other database configuration parameters that influence buffer pool performance are CHNGPGS_THRESH, NUM_IOCLEANERS, and SOFTMAX. These control how frequently and when buffer pool pages are written to disk.

The CHNGPGS_THRESH database configuration parameter is equivalent to the IDS parameter LRU_MAX_DIRTY and is the percentage of modified pages that can exist before page cleaner processes are triggered. After this value is exceeded in any one buffer pool, page cleaning begins. Because there is no equivalent to the IDS parameter LRU_MIN_DIRTY, page cleaning continues until all of the modified buffer pool pages in every buffer pool are synchronized with disk. The range for this parameter is 5 to 99, and the default is 60.

If CHNGPGS_THRESH is set too high, the buffer pool fills up with modified pages faster than the asynchronous page cleaning processes can clean them back to disk. Should the buffer pool become full, the database agent processes that normally only handle SQL processing must take over the process of page cleaning. When this occurs, the least-recently-used page in the pool is declared a victim (is stolen) and is cleaned back to disk by the database agent as asynchronous. Your goal should be to avoid victim pages, because they


negatively impact performance. This is similar to the concept of foreground writes occurring in IDS.

If CHNGPGS_THRESH is set too low, modifications to the pages are not allowed to accumulate before they are written out to disk, and excessive I/O operations are performed. You can monitor for victim pages by creating an event monitor using the CREATE EVENT MONITOR BUFFERPOOLS statement and then analyzing the results by using the system monitor GUI tool or the db2evmon command line tool.

The NUM_IOCLEANERS configuration parameter is equivalent to the IDS parameter CLEANERS and is the number of page cleaning processes that are allocated at database startup. These are the processes that are triggered when the CHNGPGS_THRESH is exceeded. The guideline is to set this parameter to one or two more than the number of physical disks on which the database resides. The range for this parameter is from 0 to 255, and the default is 1.

The SOFTMAX configuration parameters is the percentage of logical log files that can be filled between soft checkpoints before DB2 begins to clean the buffer pool pages back to disk. For example, if SOFTMAX is set to 200, then 200% of logical log files (or two logs) are filled between SOFTMAX soft checkpoints in the logical log files. This is similar to the IDS concept of a checkpoint, except that in DB2 UDB, the interval is measured in log space used instead of seconds of time. Table 14-1 summarizes the page cleaning mechanisms for IDS.

Table 14-1 IDS page cleaning

Table 14-2 summarizes the page cleaning mechanisms for DB2.

Table 14-2 DB2 page cleaning

Process name Chunk writes LRU writes Foreground writes

Triggering conditions

Checkpoint LRU_MAX_DIRTY BUFFERS full

Process type Page cleaner Page cleaner SQL exec

Process activity Log pages Asynchronous pages

Victim pages

Triggering conditionsa

SOFTMAX CHNGPGS_THRESH

Buffer pool full

Process type Page cleaner Page cleaner Agent


As a summary:

� Larger buffer pools are better.� Set CHNGPGS_THRESH lower if victim/dirty page steals occur.� Set NUM_IOCLEANERS to one or two more than the number of physical

drives.

For further reference, see IBM DB2 UDB Administration Guide: Performance, SC09-4821. There is also an article on the IBM developerWorks Web site called “DB2 Basics: Table Spaces and Buffer Pools,” available at:

http://www.ibm.com/developerworks/db2/library/techarticle/0212wieser/0212wieser.html

14.1.2 Process tuningIn IDS, the number of processes is mainly controlled by the three configuration parameters NUMAIOVPS, NUMCPUVPS, and NETTYPE. Because DB2 UDB is a database engine that uses multiple agents (processes), there are numerous configuration parameters that control the quantity of the processes running.

With DB2, the database manager parameter MAXAGENTS limits the maximum number of processes that are available to perform requests from all of the applications connected to all of the databases on the instance. At the database level, the parameter MAXAPPLS limits the number of applications that can be connected to the database at one time. Setting MAXAPPLS to automatic has the effect of allowing any number of connected applications. DB2 will dynamically allocate the resources it needs to support new applications.

If you do not want to set this parameter to automatic, the value of this parameter must be equal to or greater than the sum of the connected applications, plus the number of these same applications that might be concurrently in the process of completing a two-phase commit or rollback. Then, add to this sum the anticipated number of in-doubt transactions that might exist at any one time.

The value of MAXAGENTS should be at least the sum of the values for MAXAPPLS in each database allowed to be accessed concurrently.

a. In DB2 UDB, there is not a specific name for each type of page cleaningactivity. For example, asynchronous pages can include log pages de-pending on how the log pages were cleaned to disk (either synchronouslyor asynchronously). Victim pages are always called either victim pages orstolen pages.



14.1.3 Quick-start tips for performance tuningWhen you start a new instance of DB2, consider the following suggestions for a basic configuration:

Use the Configuration Advisor in the Control Center to get advice about reasonable beginning defaults for your system configuration parameters. The defaults shipped with DB2 will be tuned for your unique hardware environment by using the Configuration Advisor as a baseline. Gather information about the hardware at your site so that you can answer the wizard questions. You can apply the suggested configuration parameter settings immediately or let the wizard create a script based on your answers and run the script later. For more information about the Configuration Advisor, see 4.2.2, “Configuration Advisor and AUTOCONFIGURE” on page 75.

Use other wizards in the Control Center and Client Configuration Assistant for performance-related administration tasks. These tasks are usually those in which you can achieve significant performance improvements by spending spend a little time and effort. Other wizards can help you improve performance of individual tables and general data access. These wizards include the Create Database, Create Table, Index, and Configure Multisite Update wizards. The Health Center provides a set of monitoring and tuning tools.

Use the Design Advisor tool from the Control Center or use the db2advis command to find out what indexes, materialized query tables, multidimensional clustering tables, and database partitions will improve query performance.

Design AdvisorThe DB2 Design Advisor is a tool that can help you significantly improve your workload performance. The task of selecting which indexes, materialized query tables (MQTs), clustering dimensions, or 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 your workload. Given a set of SQL statements in a workload, the Design Advisor will generate recommendations for indexes, MQTs, conversion to multidimensional clustering (MDC) tables, and deletion of indexes and MQTs unused by the specified workload. You can have the Design Advisor implement some or all of these recommendations immediately or schedule them for a later time.

Using either the Design Advisor GUI or the command line tool, the Design Advisor can help simplify database design and workload performance tuning. While designing your database, use the Design Advisor to generate design alternatives in a test environment. You can also use it to evaluate indexes, MQTs, MDC tables, or partitioning strategies that have been generated manually.


After your database is set up, use the Design Advisor to improve the performance of a particular statement or workload. You can also improve general database performance, using the performance of a sample workload as a gauge. We suggest that you create a workload based on the most frequently executed queries, which you can identify by using the Activity Monitor (discussed in 14.6.6, “Activity Monitor” on page 516). To access the Design Advisor, select your database from the object hierarchy in Control Center, right-click, and select Design Advisor.

Activate database commandUse the ACTIVATE DATABASE command to start databases. In a partitioned database, this command activates the database on all partitions and avoids the startup time required to initialize the database when the first application connects.

Consult the summary tables that list and briefly describe each configuration parameter available for the database manager and each database. These summary tables contain a column that indicates whether tuning the parameter results in high, medium, low, or no performance changes, either for better or for worse. Use this table to find the parameters that you might tune for the largest performance improvements.

Runstats and reorgOther activities that have a critical impact on performance are database statistics and data organization. Statistics are used by the optimizer to make access path decisions for data retrieval. The runstats utility is used to update these statistics and should be run on a regular basis. The runstats utility is one of the most important maintenance activities for maintaining optimal system performance and should be one of the first things to check should performance suddenly degrade. For a complete discussion about the runstats utility, see 14.4.3, “Database statistics” on page 474. You can also have DB2 perform runstats for you based on automatic maintenance that you set up.

Database organization is also critical for good performance. Data rows and or indexes that are physically out of order will result in additional I/O and thus additional response time. You can reorganize your database, index, or both either yourself or enable automatic maintenance and have the system run reorgs when necessary. For more information, see 14.4.2, “Database reorganization” on page 468 and 14.5.1, “Configuring automatic maintenance” on page 485.

Note: If you use the ACTIVATE DATABASE command, you must shut down the database with the DEACTIVATE DATABASE command. The last application that disconnects from the database does not shut it down.


14.2 Tools and wizards included with DB2DB2 is rich in tools and graphical assistants to make your job easier. Many of the recent features that have been added to DB2 are centered around the concept of self-managing and resource tuning (SMART). In this section, we introduce the DB2 tools available to you. All the tools in this section are all accessible from the the Control Center.

14.2.1 Control CenterAs introduced in “The DB2 Control Center” on page 71, the Control Center is the main administration environment for DB2 and contains capabilities that extend beyond the IDS tools, such as dbaccess, the former Informix Enterprise Command Center (IECC) tool, Server Studio, or Informix Server Administrator (ISA). The Control Center and its companion tools, such as the Command Editor and SQL Assist, provide equivalent, plus additional, capabilities from a unified operating environment. The Control Center is written in Java, which means that it can run from most any platform that has a JDK (check the DB2 readme to verify the supported Java releases). Use the Control Center to manage and administer systems, DB2 Universal Database instances, databases, and database objects such as tables and views. From the Control Center, you can also open other centers and tools to help you optimize queries, jobs, and scripts, perform data warehousing tasks, create stored procedures, and work with DB2 commands.

The following are some of the key tasks that you can perform with the Control Center:

� Add DB2 UDB systems, federated systems such as IDS, DB2 UDB for z/OS and OS/390 systems, IMSysplexes, instances, databases, and database objects to the object tree.

� Manage database objects. You can create, change, and drop databases, table spaces, tables, views, indexes, triggers, and schemas. You can also manage users.

� Manage data. You can load, import, export, and reorganize data. You can also gather statistics and run queries.

� Perform preventive maintenance by backing up and restoring databases or table spaces.

� Configure and tune instances and databases.

� Manage database connections, such as DB2 Connect servers and subsystems.

� Manage DB2 UDB for z/OS and OS/390 subsystems.

� Manage applications.


� Analyze queries using Visual Explain to view at access plans.

Figure 14-1 on page 429 shows the Control Center, with a screen capture of the overview window. On the left panel, you will see a list of both local and remote DB2 systems, also known as nodes. The system cmsmunns1 is local to the Windows 2000 environment and contains one instance, DB2. This instance has three databases, dwctrldb, sample, and toolsdb. Greenland is the remote AIX environment. Under greenland, there is one instance called green1. Notice that this is the alias name for instance db2inst2. Green1 has several databases defined to it: Iifmx2db2, micky, and uwe01.

The panels on the right typically will display details from the item highlighted on the left. In this example, we highlighted the ifmx2db2 database. In the lower-right corner, you will see the details about this database, including the status, last backup, database disk utilization, health, which is not yet configured, and maintenance, which is not yet automated. From this window, you can also access additional functions, such as listing connected applications, running queries, backups, and monitoring.

At the top of the window, under the main menu, you will see the Tools option. This option provides you with access to a variety of tools, many of which are described here.


Figure 14-1 Control Center overview window

14.2.2 Command EditorLike the IDS dbaccess utility, the Command Editor is an interface for running SQL queries and operating system commands. Use the Command Editor to generate, edit, execute, and manipulate SQL statements and DB2 commands, to work with the resulting output, and to view a graphical representation of the access plan for explained SQL statements.

The Command Editor is available as two different interfaces. It can be opened as part of the Control Center (embedded) from the Tools menu, or in a stand-alone view. Both versions offer the same set of functions and both enable you to open multiple Command Editors. In Figure 14-2 on page 430, we show the creation of a distinct data type called rebecca, and then the subsequent copying of the generated code into the Command Center.


Figure 14-2 Create data type example showing the Copy to Command Editor button

Click the Copy to Command Editor button to copy the SQL text to the Command Editor, and then launch you into the Command Editor environment, as shown in Figure 14-3 on page 431. To execute the SQL, click the green triangle symbol, located under the Commands label. In the lower half of Command Center, you will see informational and error messages. Here, we see that the command was successful.

Note: We also added a user ID and password to the Connect string, showing that you can also edit the pasted text and customize it to your needs.


Figure 14-3 Command Center execution example

Figure 14-4 on page 432 shows a query that joins the customers and orders tables, with the resulting output messages. Note that these tables were migrated from IDS to DB2 using the DB2 Migration Toolkit for Informix (MTK).


Figure 14-4 Query example output using the Command Editor

To view the result set, click the Query Results tab, as shown in Figure 14-5 on page 433. Note the Add Row and Delete Row buttons. With the query output window, you can update your data, if so authorized. Clicking the columns will sort them. You can also copy and export the data to an external file with the Edit and Selected tabs, using a variety of options, such as file delimiters and formats.


Figure 14-5 Query result set example

14.2.3 Task CenterUse the Task Center to create, schedule, and run tasks. There is no equivalent facility in IDS. You can create the following types of tasks:

� DB2 scripts that contain DB2 commands

� OS scripts that have operating system commands

� Grouping tasks that contain other tasks

Task schedules are managed by a scheduler, included with DB2, while the tasks are run on one or more systems, called run systems. You define the conditions for a task to fail or succeed with a success code set. Based on the success or failure of a task, or group of tasks, you can run additional tasks, disable scheduled tasks, and other actions. You can also define notifications to send after a task completes. You can send an e-mail notification to people in your contacts list, or you can send a notification to the Journal. The Task Center is launched either from the Control Center Tools menu option or a stand-alone view.


Figure 14-6 shows an example of a script that issues a LIST TABLESPACES command at a 10-minute interval.

Figure 14-6 Task Center: Define a new task to check table spaces

We have defined a new task called “check tablespace”. It is a DB2 command script, running on the system greenland, under instance db2inst2. Figure 14-7 on page 435 shows the script, which we can provide by clicking the Command Script tab, and either typing in the script or importing it from a file (note that the password is not displayed here but has been entered).


Figure 14-7 Task Center sample command script

Next, we provide the schedule for this task, as shown in Figure 14-8 on page 436. You can run the task once or schedule it on a repeating basis. Here, we run the task every 10 minutes beginning August 11, 3:32 p.m. You can also create lists of specific schedules and then create tasks for those schedules, which are useful for performing daily, weekly, or monthly maintenance.


Figure 14-8 Enabling the schedule in the Task Center

Next, click the Notification tab, as shown in Figure 14-9 on page 437. Here, we provide a message to specific people, to the Journal, or to both as to the success or failure of our script. In this example, we use the default message and send it to the Journal, which documents database activities and messages (see 14.2.8, “Journal” on page 443 for more information about the Journal).


Figure 14-9 Task completion notification

At this point, you can also identify further task actions you want to take based on the success or failure of the job, such as running additional tasks, or enabling or disabling the schedule. Click OK to save the task.

After the task is running, you can then obtain information about its progress by highlighting the task and selecting Task → Show Progress from the main menu. You can also right-click the task to obtain task results and statistics. Figure 14-10 on page 438 shows the output from the check table spaces task, using the Show Results option. Notice how the Journal message has been filled in with the appropriate values. Also notice that the time of the last run is 4:22, the most recent execution of this task.


Figure 14-10 Task output messages

14.2.4 SQL AssistUse SQL Assist to create SQL statements, similar to the IDS utility dbaccess. SQL Assist can be launched from the SQL icon in the Command Editor. With SQL Assist, you can create SQL SELECT statements, including complex statements such as JOINs. In some environments, you can also use SQL Assist to create INSERT, UPDATE, or DELETE statements. Figure 14-11 on page 439 shows the use of SQL Assist to create a SELECT that uses a JOIN of the customer and orders tables. When multiple tables are selected in the tool, you can then request that join columns be suggested and syntax generated. We also added an additional WHERE clause on order_num. The bottom section of the window shows the generated syntax based on the options chosen.


Figure 14-11 Sample SQL Assist output

14.2.5 Visual ExplainVisual Explain shows you a graphic of the access plan for explained SQL statements. This represents the graphical equivalent of the IDS SET EXPLAIN output, which is normally stored in sqexplain.out. You can use the information available from the graph to tune your SQL queries for better performance. An access plan graph shows:

� Tables (and their associated columns) and indexes

� Operators (such as table scans, sorts, and joins)

� Table spaces and functions

� Total estimated cost and number of rows retrieved (cardinality)

In addition, Visual Explain displays the statistics that were used at the time of optimization. You can then compare these statistics to the current catalog statistics to help you determine whether rebinding the package might improve performance. You can determine whether or not an index was used to access a table. If an index was not used, Visual Explain can help you determine which columns might benefit from being indexed.

Visual Explain is particularly useful for viewing the effects of performance tuning techniques by comparing the before and after versions of the access plan graph


for a query. Figure 14-12 is an example of Visual Explain output for the query shown in Figure 14-11 on page 439.

Figure 14-12 Sample Visual Explain output

For more details about Visual Explain, refer to 9.3.1, “Optimizer analyses” on page 310.


14.2.6 Development CenterThe DB2 Development Center provides an easy-to-use interface for developing routines such as stored procedures and user-defined functions (UDFs). The IDS Data Blade Development Kit (DBDK) provides some of these capabilities, such as the ability to create user-defined functions. Using Development Center wizards, it is easy to perform your development tasks. With the Development Center, you can create, build, and deploy Java and SQL stored procedures and user-defined functions (UDFs) using SQL, WebSphere MQ, XML, or even OLEDB. An integrated debugger helps you to debug SQL stored procedures. The Development Center also provides DB2 development add-ins for a variety of application development tools, including WebSphere and Microsoft Visual Studio.NET. With the add-ins, you can easily access the features of the Development Center and other DB2 centers from your development environment, making it easy for you to develop and incorporate server-side objects. Figure 14-13 shows the plug-in for WebSphere Studio Application Developer, used to create a stored procedure.

Figure 14-13 DB2 Development Center plug-in for WebSphere Studio

Figure 14-14 on page 442 is a graphic showing the DB2 Development Center plug-in for .NET. Developers now have access to DB2 objects directly from their development environment.


Figure 14-14 DB2 Development Center plug-in for Microsoft Visual Studio .NET

14.2.7 Configuration AssistantUse the Configuration Assistant to configure and maintain the database objects that you will be using. Configuration Assistant is similar to the IDS setnet32 program. Unlike IDS, which requires client configuration at an instance level, DB2 requires that you configure access to each database from your DB2 client before you can work with it. You must configure your DB2 clients so that they can work with the available objects. From the Configuration Assistant, you can work with existing database objects, add new ones, bind applications, set database manager configuration parameters, and import and export configuration information. For more information, refer to 4.3.5, “Configuring a connection using the Configuration Assistant” on page 90.


14.2.8 JournalThe Journal provides the ability to view historical information about tasks, database actions and operations, messages, and notifications. The Journal is the focal point for viewing historical information generated within the Control Center and its components. It provides an equivalent of the IDS onstat -m function plus additional capabilities.

The Task History page shows the task history records for each of the available scheduler systems. Recall from 14.2.3, “Task Center” on page 433 that tasks are activities you have run using the Task Center. From the Refresh options field, select the amount of time between automatic page refreshes. The default is No automatic refresh. Figure 14-15 is an example that shows the tasks we scheduled from the Task Center.

Figure 14-15 Journal Task History

The Database History tab, as shown in Figure 14-16 on page 444, shows the database recovery history records for each of the available databases. Notice that for database micky, we have run several backups and dropped a few tables.


Figure 14-16 Journal Database History

Figure 14-17 on page 445 shows the message records issued by the DB2 administration tools on the local system. To delete the message records, highlight them and right-click, or use the Selected menu to remove only the selected records or all records.


Figure 14-17 Journal Database Messages

Lastly, the Notification Log tab shows the notification log records for the selected instance.

14.2.9 Health CenterThe Health Center is a graphical administration tool designed to support management-by-exception. The Health Center monitors and provides alert states of all instances and their databases and recommended resolution actions for current alerts. For more information about the Health Center, see 14.6.1, “Health check tools” on page 499.

14.2.10 Replication CenterThe DB2 Replication Center is a tool that you can use to set up and administer your replication environment. The Replication Center supports administration for DB2-to-DB2 replication environments, and administration for replication between DB2 and non-DB2 relational databases, such as IDS. The Replication Center is part of the Control Center set of tools. You can use the Replication Center to set up the three types of replication that DB2 supports: SQL replication, queue replication, and event publishing. You can specify unidirectional and bidirectional replication with one or more servers. Use the Replication Center to:

� Create replication control tables � Register replication sources


� Create subscription sets and add subscription set members to subscription sets

� Operate the Capture program � Operate the Apply program � Monitor the replication process

Figure 14-18 shows the setup launchpad for configuring Q replication.

Figure 14-18 Q replication setup wizard

For more information about the Replication Center, refer to IBM DB2 Information Integrator Replication and Event Publishing Guide and Reference Version 8 Release 2, SC18-7568.

14.2.11 License CenterThe management of licenses for your DB2 UDB) products is done primarily through the License Center. From the License Center, you can check the license information, statistics, registered users, and current users for each of your installed products. The License Center can be accessed from the Tools menu in Control Center. There is no equivalent component for IDS.


When the Control Center cannot be used, the db2licm Licensed Management Tool command performs basic license functions. With this command, you are able to add, remove, list, and modify licenses and policies installed on your local system. The example below shows the system Greenland with DB2 Enterprise Server Edition installed. The version Informix shows Stinger (the beta version of DB2 Version 8.2 used when the test was run). The license has an expiration date of November 30, 2004, because this is a “try and buy” copy of the software. The processor licensing status shows a violation. The reason for this violation is that only one of eight processors on the machine have been licensed. After you have received your license entitlement from your IBM Account Representative, you can update the processor limit by choosing the License → Change option, as shown in Figure 14-19.

Figure 14-19 DB2 License Center

14.2.12 Information Catalog CenterThe Information Catalog Center provides you with the ability to manage descriptive data, also known as business metadata, through information catalogs. The descriptive data, which is organized into metadata objects, helps you identify and locate information. You can search for specific objects in the information catalog and view any relationships an object participates in or an object's lineage. You can also create comments for objects. Some users can also define additional objects in the information catalog. For more information about


Information Catalog Center, refer to Information Catalog Center Administration Guide Version 8 Release 2, SC27-1125.

14.2.13 Data Warehouse CenterYou can use the Data Warehouse Center (DWC) to move data from operational databases to a warehouse database, which users can query for decision support. This process is also known as ETL, which stands for Extract, Transform, and Load. You can use the DWC to define the structure of the operational databases, called sources. You can then specify how the operational data is to be moved and transformed for the warehouse. You can model the structure of the tables in the warehouse database, called targets, or build the tables automatically as part of the process of defining the data movement operations and loading the data.

For example, you can use the Data Warehouse Center to define your sales source data to use in a data warehouse, define a star schema for the data warehouse, and clean and transform the data to fit the star schema format.

The Data Warehouse Center, shown in Figure 14-20, uses SQL, ODBC export, and DB2 load and export utilities to move and transform data. You can use replication to copy large quantities of data from warehouse sources into a warehouse target, and then capture any subsequent changes to the source data. These operations are supported on all of the DB2 UDB workstation operating environments, DB2 Universal Database for z Series, DB2 for i Series, and non-DB2 databases such as IDS, with Information Integrator. You can also use the Data Warehouse Center to move data into an online analytical processing (OLAP) database. An expanded functionality version of DB2 Warehouse Center is called DB2 Warehouse Manager and is available as an additional cost option.

Figure 14-20 Data Warehouse Center


For more information about the Data Warehouse Center, see Data Warehouse Center Administration Guide Version 8 Release 2, SC27-1123. For more information about DB2 Warehouse Manager, see:

http://www.ibm.com/software/data/db2/datawarehouse/about.html

14.2.14 Web administrationTwo Web-based tools are available for remote administration of DB2: the DB2 Web Command Center and DB2 Web Health Center. These tools run as Web applications on a Web application server to provide access to DB2 servers through Web browsers.

The DB2 Web Command Center is based on a three-tier architecture. The first tier is the Web client HTTP browser. The middle tier is an application server that hosts the business logic and set of applications. This middle tier provides the underlying mechanisms for the communication (HTTP/HTTPS) with the first tier (Web client browser) and also the third tier (database or transaction server).

The DB2 Web Command Center implements many of the already existing features of the DB2 Command Center; however, it does not contain SQL Assist or Visual Explain.

The DB2 Web Command Center is targeted for use with the HTTP clients (browsers) available on mobile laptops and notebooks, as well as Web-enabled PDAs and Palm devices. For more information about the Web tools, see IBM DB2 UDB Installation and Configuration Supplement, GC09-4837.

14.2.15 Wizards, advisors, and launchpadsThe wizards and advisors that are part of DB2 can greatly improve your productivity, especially as you make the transition from IDS to DB2. The DB2 advisors, wizards, and launchpads are integrated into the DB2 administration tools. They assist you in completing administrative tasks by stepping you through the tasks.

The example in Figure 14-21 on page 450 shows the assistant functions available from the Wizards window accessed from the Control Center by selecting Tools → Wizards from the menu.



Figure 14-21 Wizards menu in the Control Center

Some of the wizards and launchpads that are available from other parts of Control Center include:

� Configure Automatic Maintenance wizard � Create Cache Table wizard � Redistribute Data wizard � Storage Management Setup launchpad� Set Up Activity Monitor wizard � Set Up High Availability Disaster Recovery (HADR) Databases wizard� Configure Automatic Maintenance wizard � Storage Management Setup launchpad

14.3 Optional toolsThe tools discussed in this section add value to your DB2 environment by helping you to maximize your productivity. Each is an optional cost item. For more details, see:

http://www.ibm.com/software/data/db2imstools/



14.3.1 DB2 Performance ExpertDB2 Performance Expert offers a comprehensive view that consolidates, reports, analyzes, and recommends changes to DB2 performance-related information. The tool includes a Performance Warehouse that stores performance data and analysis tools and a Buffer Pool Analyzer that collects data and provides reports on related event activity. DB2 Performance Expert builds on IBM autonomic computing and on demand expertise, providing recommendations for system tuning to gain optimum throughput. The tool is available for DB2 Universal Database on the Linux, UNIX, and Windows platforms, as well as z/OS.

Figure 14-22 shows a DB2 Performance Expert overview window. For more information about DB2 Performance Expert, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2pe/index.html

Figure 14-22 DB2 Performance Expert

Consider DB2 Performance Expert if you need a comprehensive DB2 monitoring and reporting tool, monitor your DB2 systems across the enterprise, and want to use DBA skills for monitoring multiplatform DB2 databases z/OS databases concurrently, or if you need in-depth information for long-term planning.



14.3.2 DB2 Recovery ExpertIBM DB2 Recovery Expert provides targeted, flexible, and automated recovery of database assets. DB2 Recovery Expert helps expert and novice DBAs to recover database objects safely, precisely, and quickly without having to resort to full disaster recovery processes.

Building on IBM autonomic computing expertise, this tool provides intelligent analysis and diagnostics of altered, incorrect, or missing database assets including tables, indexes, or data. It also automates the process of rebuilding those assets to a correct “point-in-time,” often without taking the database offline. In addition, you can mine the database logs to create “undo” or “redo” SQL and to remove errant transactions without having to do a full table space or database recovery.

Figure 14-23 shows the results of a log analysis, where the table space userspace1 has been mined for all transactions. You can then select the transactions to undo.

Figure 14-23 DB2 Recovery Expert Log Analysis

Consider DB2 Recovery Expert if you need to reduce recovery time, want to avoid full disaster recovery scenarios, would like to improve DBA productivity, or want best practices for database maintenance.


For more information about DB2 Recovery Expert, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2re/

14.3.3 DB2 High Performance UnloadHigh Performance Unload (HPU) is the equivalent to the unload process of the Informix High-Performance Loader with additional functionality. High Performance Unload is a high-speed DB2 utility for unloading DB2 tables from either a database or from a backup. The tool is available for DB2 UDB on z/OS, as well as on the Linux, UNIX, and Windows platforms.

Using HPU, you can quickly unload your DB2 data with a variety of formats, such as flat files, tape, or named pipes. Additional features include:

� Fast SQL-like SELECT capabilities, such as filtering columns and rows using a WHERE clause

� Unloads a sampling of data (for example, every nth row)

� Unloads data from online databases or database backups

� Unloads all data or data from selected table spaces

Consider using High Performance Unload if you need to significantly reduce your unload times or batch processing windows, or if you are performing multiple unloads against the same table.

For more information about High Performance Unload, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2hpu/

14.3.4 DB2 Test Database GeneratorIBM DB2 Test Database Generator, shown in Figure 14-24 on page 454, rapidly populates application and testing environments and simplifies problem resolution. It can easily create test data from scratch or from existing data sources and maintains referential integrity while extracting data sets from source databases. It can create complete or scaled down copies of production databases while masking sensitive production data for use in a test environment.




Figure 14-24 DB2 Test Database Generator

Consider DB2 Test Database Generator when:

� Application developers and testers need to routinely generate test databases or regenerate copies of their original test databases.

� Sales people need realistic test data to use for product demonstrations.

� DBAs need relief from the time-consuming task of generating appropriate test data for applications.

� DBAs need test data to use when evaluating new software products.

For more information about DB2 Test Database Generator, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2tdbg/



14.3.5 DB2 Table EditorIBM DB2 Table Editor quickly and easily accesses, updates, and deletes data across multiple DB2 database platforms, including the Informix Dynamic Server 9.x. Key features include:

� Navigates IBM DB2 databases, tables and views; finds related data; and quickly updates, deletes, or creates data with full support for your existing security and logon IDs.

� Edits DB2 tables everywhere with your choice of end-user entry points: Java-enabled Web browsers, Java-based interfaces launched from the IBM DB2 Control Center, Microsoft Windows, or an ISPF interface.

� Provides drag-and-drop and wizards to rapidly create customized, task-specific Java-bases or Windows-based table editing forms containing built-in data validation and business rules.

Consider DB2 Table Editor when you need to edit DB2 tables, need easy-to-build forms capability for end users, or need access to IDS or DB2 data.

For more information about DB2 Table Editor, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2te/

14.3.6 DB2 Web Query ToolThe DB2 Web Query Tool connects all your users directly to multiple enterprise databases, securely and simultaneously, regardless of database size, hardware, operating system, or location. In addition, the Web Query Tool also supports IDS.

The key features of DB2 Web Query Tool are:

� Enables complex querying, data comparisons, and customized presentations.

� Provides rapid global access to business information over e-mail clients, including WAP-enabled devices such as PDAs, wireless phones, and text pagers.

� Supports standard browsers, giving administrators, developers, and end users the ability to build queries that support multiple DB2 platforms, share and run the queries, and convert the results to XML and other highly transportable file formats.

� Is a J2EE-compliant Web application, so it can be deployed on WebSphere and other application servers.

Consider DB2 Web Query Tool when you need comprehensive query and comparison capabilities without compromising DB2 security or data integrity,



require thin client access from many different devices on your network, or need access to IDS or DB2 databases across an enterprise.

For more information about the DB2 Web Query Tool, refer to:

http://www.ibm.com/software/data/db2imstools/db2tools/db2wqt/

14.4 UtilitiesDB2 has a complete set of utilities, available through the command line and graphical interface. For this discussion, we show the wizards for each and the command syntax that is generated through the tools.

Table 14-3 is a comparison chart showing the major DB2 utilities with their IDS equivalents. For more information, see IBM DB2 UDB Command Reference, SC09-4828.

Table 14-3 DB2 and IDS utilities comparison

Function DB2 IDS

Backup/restoreNote: This topic is covered in 5.4.2, “Backup and restore methods” on page 167.

backup, restore, recover onbar, ontape

Load/unload data. import (row at a time), load (bulk data), export, High Performance Unload (fast unload, a separately priced option), db2move (move database)

dbexport, dbimport, HPL

Check if database needs reorganization.

reorgchk oncheck; sysmaster

Reorganize. reorg index, reorg table unload/reload, alter fragment init, alter index to cluster

Maintain database statistics.

runstats (can also be automated)

update statistics

Analyze queriesNote: This topic is covered in 9.3.1, “Optimizer analyses” on page 310.

explain, db2exfmt, db2expln, Visual Explain

set EXPLAIN, xtool, I-Spy, onperf



14.4.1 Exporting and importing dataDB2 has several methods for importing and exporting data, each with multiple options. The main utilities for moving data are IMPORT and LOAD; EXPORT for inserting data; High Performance Unload for extraction; and the db2move command for migrating databases. We explain these in detail in this section. First, we discuss file formats.

Five operating system file formats are supported by the DB2 EXPORT, IMPORT, LOAD, and db2move utilities:

� DEL: Delimited ASCII, for data exchange among a wide variety of database managers and file managers. This common approach to storing data uses special character delimiters to separate column values, which you can define as required.

� ASC: Non-delimited ASCII, for importing or loading data from other applications that create flat text files with aligned column data.

� PC/IXF: PC version of the Integrated Exchange Format (IXF), the preferred method for data exchange within DB2. PC/IXF is a structured description of a database table that contains an external representation of the internal table. When using the PC/IXF data file format, the table does not need to exist before beginning the import operation. IXF files are functionally equivalent to the files generated by the IDS db2export utility in that they contain data and schema information.

� WSF: Work-sheet format, for data exchange with products such as Lotus® 1-2-3 and Symphony. The load utility does not support this file format.

DDL (schema) extraction. db2look dbschema

Check database integrity. db2dart, inspect/db2inspf

oncheck

Command line database monitoring (see 14.6, “Monitoring tools and advisors” on page 499).

db2pd (has many of the same commands as onstat)

onstat

Check backup. db2ckbkp archecker

Function DB2 IDS


� CURSOR: A cursor declared against an SQL query. This method provides excellent performance. When using the CURSOR file type, the table, including its column names and data types, must be defined before beginning the load operation. It is not necessary for the specified cursor to be open before starting the load operation. This file type is only supported by the load utility.

When using DEL, WSF, or ASC data file formats, you must define the table, including its column names and data types, before importing the file. The import utility accepts data with minor incompatibility issues, including character data imported with possible padding or truncation and numeric data imported into different types of numeric fields.

ExportThe export utility extracts data from a database to an operating system file, which can be in one of several external file formats. This operating system file can then be used to move the table data to a different server.

Other options you can specify include:

� New column names when exporting to IXF or WSF files. � Output file name.� Delimiter.� SQL statement for the export.� A message file name. During DB2 operations such as exporting, importing,

loading, binding, or restoring data, you can specify that message files be created to contain the error, warning, and informational messages associated with those operations. Specify the name of these files with the MESSAGES parameter. These message files are standard ASCII text files. Each message in a message file begins on a new line and contains information provided by the DB2 message retrieval facility. To print them, use the printing procedure for your operating system; to view them, use any ASCII editor.

Figure 14-25 on page 459 shows an EXPORT of the items table we migrated from the IDS stores_demo database to DB2 database ifmx2db2. We are exporting it to an IXF formatted file with the file directed to items.out and the messages to itemsmsgs.out. All columns are being exported, although as you can see, you can limit the columns or even issue your own SQL statement.


Figure 14-25 Export items table

ImportThe import utility inserts data from an input file into a table or updatable view, a row at a time. If the table or view receiving the imported data already contains data, you can either replace or append to the existing data.

You can import files that are delimited, fixed length, or files that have been exported using the DB2 EXPORT utility.

You can also specify:

� The method to use for importing the data: column location, column name, or relative column position.


� The number of rows to INSERT before committing the changes to the table. Requesting periodic COMMITs reduces the number of rows that are lost if a failure and a ROLLBACK occur during the import operation. It also prevents the DB2 logs from getting full when processing a large input file.

� The number of file records to skip before beginning the import operation. If an error occurs, you can restart the import operation immediately following the last row that was successfully imported and committed.

� The names of the columns within the table or view into which the data is to be inserted.

� A message file name.

The example in Figure 14-26 on page 461 shows an IMPORT of the items table we just exported from the ifmx2db2 database. We are importing it from an IXF formatted file with the file directed to items.out and the messages to itemsmsgs.in. The target database is micky. All columns are being imported. To import a table, right-click Tables and select Create from Import in the object view of the Control Center. You can also import into an existing table. Some of the other import options you can choose include allowing write access during import, the transaction commit frequency, number of warnings, and initial column and table defaults. In this example, we assign a new name for the table, items2, as shown in Figure 14-26 on page 461.


Figure 14-26 Import table example

LoadThe load utility efficiently moves large quantities of data into newly created tables, or into tables that already contain data. The utility can handle most data types, including large objects (LOBs) and user-defined types (UDTs). The load utility is faster than the import utility, because it writes formatted pages directly into the database, while the import utility performs SQL INSERTs. The load utility does not fire triggers and does not perform referential or table constraints checking other than validating the uniqueness of the indexes.


The load process consists of four distinct phases:

1. Load, during which the data is written to the table

During the load phase, data is loaded into the table, and index keys and table statistics are collected if necessary. Save points, or points of consistency, are established at intervals specified through the SAVECOUNT parameter in the LOAD command. Messages are generated, indicating how many input rows were successfully loaded at the time of the save point. If a failure occurs, you can restart the load operation. The RESTART option automatically restarts the load operation from the last successful consistency point. The TERMINATE option rolls back the failed load operation.

2. Build, during which indexes are produced

During the build phase, indexes are produced based on the index keys collected during the load phase. The index keys are sorted during the load phase, and index statistics are collected (if the STATISTICS YES with INDEXES option was specified). The statistics are similar to those collected through the runstats command. If a failure occurs during the build phase, the RESTART option automatically restarts the load operation at the appropriate point.

3. Delete, during which the rows that caused a unique key violation are removed from the table

Unique key violations are placed into the exception table if one was specified, and messages about rejected rows are written to the message file. Following the completion of the load process, review these messages, resolve any problems, and insert the corrected rows into the table. Do not attempt to delete or to modify any temporary files created by the load utility. Some temporary files are critical to the delete phase. If a failure occurs during the delete phase, the RESTART option automatically restarts the load operation at the appropriate point.

4. Index copy, during which the index data is copied from a system temporary table space to the original table space

This will only occur if a system temporary table space was specified for index creation during a load operation with the READ ACCESS option specified.

Other options you can specify on LOAD include:

� Loading data that resides on the client if the load utility is invoked from a remotely connected client.

� The method to use for loading the data: column location, column name, or relative column position, and column names.


� How often the utility is to establish consistency points. Use the SAVECOUNT parameter to specify this value. If this parameter is specified, a load restart operation will start at the last consistency point instead of at the beginning.

� Whether or not preexisting data in the table can be queried while the load operation is in progress.

� Whether the load operation should wait for other utilities or applications to finish using the table or force the other applications off before proceeding.

� An alternate system temporary table space in which to build the index.

� A message file name. You can only view the contents of a message file after the operation is finished.

� Whether the utility should modify the amount of free space available after a table is loaded. Additional free space permits INSERT and UPDATE growth to the table following the completion of a load operation. Reduced free space keeps related rows more closely together and can enhance table performance.

� Whether statistics are to be gathered during the load process. This option is only supported if the load operation is running in REPLACE mode. If data is appended to a table, statistics are not collected. To collect current statistics on an appended table, invoke the runstats utility following completion of the load process.

� Whether to keep a copy of the changes made. This is done to enable rollforward recovery of the database. Logging is required for fully recoverable databases. The load utility almost completely eliminates the logging associated with the loading of data. In place of logging, you have the option of making a copy of the loaded portion of the table.

� User access to the data that existed in the table prior to the load.

LOAD operates at the table level and does not require exclusive access to the table space. LOAD will place a lock only on the table objects associated with the load operation taking place. Concurrent access to other table objects in the same table spaces is permitted.

Figure 14-27 on page 464 shows a LOAD into the items2 table we previously created, replacing the existing rows. The file is located on a Windows client. The table we are loading into is located on an AIX server. Messages are being sent to C:\itemsload.out. The Load wizard also prompts you for additional options, such as column mapping and default behavior, statistics collection, performance parameters, and how you want to recover from failure.


Figure 14-27 Load wizard

Loading from a CURSORThrough the use of the new CURSOR file type, you can now load the results of an SQL query into a database without having to export them to a data file first. You can also use the Federated feature of DB2 to use IDS as the source table and DB2 as the target table. This is a fast and useful method for data movement.

Copy table function in the Control CenterYou can use the copy table function in the Control Center to simplify moving tables between databases and instances. The copy table function generates the export and import commands for you. To access this function, select the source table, right-click it, and select Copy. Figure 14-28 on page 465 shows an example of copying the orders table from database ifmx2db2 to micky. We also renamed it orders2.


Figure 14-28 Copy Table - ORDERS

db2moveThe db2move command facilitates the movement of large numbers of tables between DB2 databases. The tool queries the system catalog tables for a particular database and compiles a list of all user tables. It then exports these tables in PC/IXF format. The PC/IXF files can be imported or loaded to another local DB2 database on the same system, or can be transferred to another platform and imported or loaded to a DB2 database. The db2move tool is available only from the command line. When using this command, there are three options: export, import, or load. In Example 14-1 on page 466, we export the ifmx2db2 database. Next, we load this database into the database micky.


Example 14-1 db2move export and db2move import commands example

db2inst2:/home/db2inst2> db2move ifmx2db2 export

***** DB2MOVE *****

Action: EXPORT

Start time: Wed Aug 18 11:59:16 2004

Connecting to database IFMX2DB2 ... successful! Server: DB2 Common Server V8.2.0

Binding package automatically ...Bind file: /home/db2inst2/sqllib/bnd/db2move.bnd

Bind was successful!

EXPORT: 2046118 rows from table "DB2INST2"."T1"EXPORT: 5 rows from table "DB2INST2"."CALL_TYPE"EXPORT: 30 rows from table "DB2INST2"."CUSTOMER"EXPORT: 67 rows from table "DB2INST2"."ITEMS"EXPORT: 11 rows from table "DB2INST2"."MANUFACT"EXPORT: 23 rows from table "DB2INST2"."ORDERS"EXPORT: 7 rows from table "DB2INST2"."CUST_CALLS"EXPORT: 74 rows from table "DB2INST2"."STOCK".....

Disconnecting from database ... successful!

End time: Wed Aug 18 11:59:50 2004db2inst2:/home/db2inst2> db2move micky import

***** DB2MOVE *****

Action: IMPORT

Start time: Wed Aug 18 12:18:08 2004

Connecting to database MICKY ... successful! Server: DB2 Common Server V8.2.0

* IMPORT: table "DB2INST2"."T1" -Rows read: 2046118 -Inserted: 2046118 -Rejected: 0


-Committed: 2046118

* IMPORT: table "DB2INST2"."CALL_TYPE" -Rows read: 5 -Inserted: 5 -Rejected: 0 -Committed: 5

.....

* IMPORT: table "DB2INST2"."CUSTOMER" -Rows read: 30 -Inserted: 30 -Rejected: 0 -Committed: 30-Rejected: 0 -Committed: 2

* IMPORT: table "DB2INST2"."ITEMS" -Rows read: 67 -Inserted: 67 -Rejected: 0 -Committed: 67

* IMPORT: table "DB2INST2"."MANUFACT" -Rows read: 11 -Inserted: 11 -Rejected: 0 -Committed: 11

* IMPORT: table "DB2INST2"."ORDERS" -Rows read: 23 -Inserted: 23 -Rejected: 0 -Committed: 23

* IMPORT: table "DB2INST2"."CUST_CALLS" -Rows read: 7 -Inserted: 7 -Rejected: 0 -Committed: 7

* IMPORT: table "DB2INST2"."STOCK" -Rows read: 74 -Inserted: 74 -Rejected: 0 -Committed: 74


Disconnecting from database ... successful!

End time: Wed Aug 18 12:22:11 2004

When you move your database, it is also necessary to move all other objects associated with the tables, such as aliases, views, triggers, user-defined functions, and so on. There are additional options you can use with the db2move command, such as specifying specific tables and creators.

Example 14-2 shows the syntax diagram.

Example 14-2 db2move syntax

|>>-db2move--dbname--action----+-----------------------+-+------>< +--tc-- table-creators ---+ +--tn-- table-names ------+ +--sn-- schema-names -----+ +--ts-- tablespace-names -+ +--tf-- filename ---------+ +--io-- import-option ----+ +--lo-- load-option ------+ +--l-- lobpaths ----------+ +--u-- userid ------------+ +--p-- password ----------+ '--aw-------------------'Action is IMPORT, EXPORT, or LOAD

High Performance UnloadHigh Performance Unload is an extra charge option of DB2 that provides the capability to unload data by bypassing the database manager and reading directly from data blocks. The result is performance typically several times faster than the EXPORT utility. For more information, refer to 14.3.3, “DB2 High Performance Unload” on page 453.

14.4.2 Database reorganizationAfter many changes to table data, logically sequential data might be on non-sequential physical data pages so that the database manager must perform additional read operations to access data. Additional read operations are also required if a significant number of rows have been deleted. In such a case, you might consider reorganizing the table to match the index and to reclaim space. You can reorganize the system catalog tables and the database tables.


Consider the following factors, which might indicate that you should reorganize a table:

� A high volume of insert, update, and delete activity on tables accessed by queries.

� Significant changes in the performance of queries that use an index with a high cluster ratio.

� Executing runstats to refresh statistical information does not improve performance.

� The reorgchk command indicates a need to reorganize your table.

� The trade-off between the cost of increasing degradation of query performance and the cost of reorganizing your table, which includes the CPU time, the elapsed time, and the reduced concurrency resulting from the reorg utility locking the table until the reorganization is complete.

To reduce the need for reorganizing a table, perform these tasks after you create the table:

1. Alter table to add PCTFREE.

2. Create clustering index with PCTFREE on the index.

3. Sort the data.

4. Load the data.

After you have performed these tasks, the table with its clustering index and the setting of PCTFREE on the table helps preserve the original sorted order. If enough space is allowed in table pages, new data can be inserted on the correct pages to maintain the clustering characteristics of the index. As more data is inserted, and the pages of the table become full, records are appended to the end of the table so that the table gradually becomes unclustered.

Similarly, as tables are updated with deletes and inserts, index performance degrades in the following ways:

� Fragmentation of leaf pages increases I/O costs, because more leaf pages must be read to fetch table pages.

� The physical index page order no longer matches the sequence of keys on those pages, which is referred to as a badly clustered index.

� When leaf pages are badly clustered, sequential prefetching is inefficient and results in more I/O waits.

� The index develops more than its maximally efficient number of levels.

If you set the MINPCTUSED parameter when you create an index, the database server automatically merges index leaf pages if a key is deleted and the free


space is less than the specified percent. This process is called online index defragmentation. To restore index clustering, free space, and reduce leaf levels, you can use one of the following methods:

� Drop and recreate the index.

� Use the reorg indexes command to reorganize indexes online. You might choose this method in a production environment because it allows users to read from and write to the table while its indexes are being rebuilt.

� Use the reorg table command with options that allow you to reorganize both the table and its indexes offline.

Assessing the need for reorganizationThe reorgchk command returns statistical information about data organization and can advise you about whether particular tables need to be reorganized. Running specific queries against the catalog statistics tables at regular intervals or specific times can also provide a performance history that enables you to spot trends that might have wider implications for performance. The reorgchk command can also be used to update table and index statistics in the catalogs. Example 14-3 shows the output for a reorgchk on all tables (table all option). Note that the output has been truncated. Asterisks (*) in the output of the REORG column indicate that reorganization is needed, based on three separate formulas, which are labelled F1, F2, and F3. You will see in the example that SYSIBM SYSINDEXES has asterisks for F1 and F3, thus a reorganization is needed (highlighted in blue and bold typeface).

Example 14-3 Sample reorgchk output

db2inst2:/home/db2inst2> db2 reorgchk on table all

Doing RUNSTATS ....

Table statistics:

F1: 100 * OVERFLOW / CARD < 5F2: 100 * (Effective Space Utilization of Data Pages) > 70F3: 100 * (Required Pages / Total Pages) > 80

Tip: Creating multidimensional clustering (MDC) tables might reduce the need to reorganize tables. For MDC tables, clustering is maintained on the columns that you specify as arguments to the ORGANIZE BY DIMENSIONS clause of the CREATE TABLE statement. However, reorgchk might recommend reorganization of an MDC table if it considers that there are too many unused blocks or that blocks should be compacted. For more information about MDC tables, refer to 9.2.2, “Multidimensional cluster” on page 305.


SCHEMA NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG----------------------------------------------------------------------------------------ASN IBMQREP_APPLYENQ - - - - - - - - - --- ASN IBMQREP_APPLYMON - - - - - - - - - --- CINDYM HARRY 1 0 1 1 - 20 0 - 100 --- DB2INST2 STOCK 74 0 2 2 - 4218 0 100 100 --- DB2INST2 T1 2046118 0 8157 8157 - 28645652 0 87 100 --- SYSIBM SYSINDEXES 240 118 21 40 - 206640 49 100 52 *-* SYSIBM IBM24 3469 8 0 2 19 14 12 80 53 20 0 0 *---- Table: SYSIBM.SYSROUTINESSYSIBM IBM127 272 2 0 2 13 0 272 65 73 60 0 0 *---- SYSIBM IBM151 272 1 0 1 6 1 4 97 - - 0 0 ----- SYSIBM IBM189 272 3 0 2 26 2 201 76 60 48 0 0 *---- SYSIBM IBM25 272 4 0 2 24 2 272 68 54 40 0 0 *---- SYSIBM IBM26 272 4 0 2 32 0 272 70 68 32 0 0 *---- SYSIBM IBM27 272 3 0 2 26 2 201 70 60 48 0 0 *---- SYSIBM IBM28 272 1 0 1 6 1 2 99 - - 0 0 ----- SYSIBM IBM29 272 1 0 1 4 0 272 99 - - 0 0 ----- SYSIBM IBM30 272 14 0 2 59 129 272 75 32 19 32 0 **-*- SYSIBM IBM55 272 4 0 2 23 2 272 75 53 41 0 0 *---- Table: SYSIBM.SYSSCHEMAAUTHSYSIBM IBM57 9 1 0 1 33 0 9 100 - - 0 0 ----- SYSIBM IBM58 9 1 0 1 12 0 9 100 - - 0 0 ----- -------------------------------------------------------------------------------------------------

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.

Tables defined using the ORGANIZE BY clause and the corresponding dimension indexes have a '*' suffix to their names. The cardinality of a dimension index is equal to the Active blocks statistic of the table.

For more information, refer to IBM DB2 UDB Administration Guide: Performance, SC09-4821.

Table reorganizationThe reorg table command is used to reorganize a table. It can also reorganize an index at the same time.

Figure 14-29 on page 473 shows an example of reorganizing the state table in the ifmx2db2 database. We are doing this in online mode, meaning that users have access to the table while the utility is running. DB2 does this by reorganizing data in place, a block at a time. To access the reorg command, select the table to be reorganized in the Control Center, right-click, and select Reorganize Table. Note that we are also reorganizing an index.


Figure 14-29 Reorganize table example

You can also configure automatic maintenance of the database so that reorg will be performed automatically when appropriate. For more information, see 14.5.1, “Configuring automatic maintenance” on page 485.

Index reorganizationNew in DB2 Version 8 is the ability to read and update a table and its existing indexes during an index reorganization using the new reorg indexes command.

During an online index reorganization, the entire index object (that is, all indexes on the table) is rebuilt. A “shadow copy” of the index object is made, leaving the original indexes and the table available for read and write access. Any concurrent transactions that update the table are logged. After the logged table changes have been forward-fitted and the new index (the shadow copy) is ready, the new index is made available. While the new index is being made available, all access to the table is prohibited. The time required to swap files is quite small, typically


on the order of seconds. The default behavior of the reorg indexes command is ALLOW READ-ONLY ACCESS. But you can also specify ALLOW NO ACCESS, which specifies that no other users can access the table while the indexes are being reorganized, or ALLOW WRITE ACCESS, which specifies that other users can read from and write to the table while the indexes are being reorganized.

Figure 14-30 shows an example of reorganizing the indexes on the stock table, allowing write access and converting type 1 to type 2 indexes. For a discussion of index types, refer to 9.1.3, “Type I and type II indexes” on page 297.

Figure 14-30 Reorganize indexes command example

You can also enable automatic maintenance for maintaining indexes. For more information, see 14.5.1, “Configuring automatic maintenance” on page 485.

14.4.3 Database statisticsBoth the IDS and DB2 use a cost-based optimizer. That means statistical information, such as the number of rows of a table or structure of an index, is used by the optimizer to calculate the cost of a query plan. It is up to the database administrator to keep these statistics as current as possible and


necessary. Without the correct statistical information, the optimizer is not able to calculate a adequate query plan, which can result in degraded performance.

The DB2 version of update statistics is called runstats. Like the update statistics command known by IDS, you have to run this statement from time to time. The right time to execute a runstats depends on the dynamic nature of the data. If the content of a table is changing constantly, you will need to update the statistics more often. If a table content is static, a single runstats will be sufficient. This is almost the same manner as IDS behaves.

However, there is a difference between IDS and DB2 about what kind of statistics are collected. DB2 collects table, column, and index information. This is reflected in the runstats command. Example 14-4 shows the command syntax.

Example 14-4 runstats syntax

db2inst2:/home/db2inst2> db2 ? runstatsRUNSTATS ON TABLE table-name [USE PROFILE | statistics-options]

statistics-options:[table-object-options] [ALLOW {WRITE | READ} ACCESS][table-sampling-options] [profile-options] [UTIL_IMPACT_PRIORITY [priority]]

table-object-options:[{FOR index-clause | [column-stats-clause] [AND index-clause]}]

table-sampling-options:[TABLESAMPLE {BERNOULLI | SYSTEM} (numeric-literal)[REPEATABLE (integer-literal)]]

profile-options:[{SET PROFILE [NONE | ONLY] | UPDATE PROFILE [ONLY]}]

index-clause:[[SAMPLED] DETAILED] {INDEXES | INDEX} {ALL | index-name [{,index-name}...]}

columns-stats-clause:[ON {{ALL | KEY} COLUMNS [AND COLUMNS (column-option [{,column-option}...])] |COLUMNS (column-option [{,column-option}...])}] [distribution-clause]

column-option:{column-name [LIKE STATISTICS] | (column-name [{,column-name}...])}

distribution-clause:WITH DISTRIBUTION [ON {{ALL | KEY} COLUMNS [AND COLUMNS (dist-column[{,dist-column}...])] | COLUMNS (dist-column [{,dist-column}...]) }][DEFAULT [NUM_FREQVALUES number] [NUM_QUANTILES number]]

dist-column:


{column-name | (column-name [{,column-name}...])} [NUM_FREQVALUES number][NUM_QUANTILES number]

The online help of the runstats command demonstrates that there are a lot more options you can use compared to IDS update statistics. We do not cover all of these in this book. Instead, we discuss a few of the more important options here. Table 14-4 provides a basic comparison of update statistics and runstats commands.

Table 14-4 Basic update statistics and runstats commands comparison

If you prefer a graphical method to create your runstats, you can use DB2 Control Center. To do so, right-click the table and select Run Statistics. As shown in Figure 14-31 on page 477, you can adjust all the Run Statistics settings.

IDS DB2

UPDATE STATISTICS LOW RUNSTATS ON TABLE schema.tabname AND INDEXES ALL

UPDATE STATISTICS MEDIUM RUNSTATS ON TABLE schema.tabname WITH DISTRIBUTION ON ALL COLUMNS DEFAULT NUM_FREQVALUES n NUM_QUANTILES m AND SAMPLED DETAILED INDEXES ALL

UPDATE STATISTICS HIGH RUNSTATS ON TABLE schema.tabname WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL

Note: All examples in Table 14-4 run against all columns and indexes of the table. You can also select single columns and indexes.

The UPDATE STATISTICS MEDIUM equivalent for DB2 is not exactly the same as for IDS. The lower the parameters NUM_FREQVALUES and NUM_QUANTILES are, the smaller the samples taken are.


Figure 14-31 Performing a runstats with the Control Center

Example 14-5 demonstrates the impact of a runstats run.

Example 14-5 Query plans before and after a runstats run

SELECT c.customer_num, company, order_num, order_dateFROM customer c, orders oWHERE c.customer_num = o.customer_numORDER BY company;

The query plans (shown in Figure 14-32 on page 478) are taken before and after a runstats. The query plans are generated with the Visual Explain tool (see “Visual Explain” on page 311 for a detailed description). Notice in the following example how the total cost of the query decreased from 51.62 to 37.51 timerons after runstats updated the statistics.


Figure 14-32 Query plans before and after a runstats run

You can also automate statistics maintenance by using the automated database maintenance feature. For more information, see 14.5.1, “Configuring automatic maintenance” on page 485.

14.4.4 Schema extractionThe db2look utility is the equivalent to the IDS dbschema utility for extracting a database schema to an external file. You can use these DDL statements to reproduce the database objects of a production database on a test database. For example, you can replicate database statistics, database configuration parameters, database manager configuration parameters, and db2set statements to match those of the production database.

Using this tool makes it possible to create a test database where access plans are similar to those that would be used on the production system.

You can access the db2look utility from the Control Center at the database or the table level by right-clicking the database or table and selecting Generate DDL. The db2look example shown in Figure 14-33 on page 479 was used to extract


DDL from the micky database. In the Statement tab, we select all the options, such as database objects, table spaces, database statistics, and configuration. In the Object tab, we specify the user db2inst2 and schema db2inst2. In this tab, you can also select specific tables. Here, we select all tables by default.

Figure 14-33 The db2look utility example

Example 14-6 shows the DDL output (note that the output has been edited for brevity).

Example 14-6 DDL output for the db2look utility on the micky database

-- Specified SCHEMA is: DB2INST2-- Creating DDL for table(s)

-- Schema name is ignored for the Federated Section-- Running db2look in mimic mode


-- Omitting COMMIT in mimic file-- This CLP file was created using DB2LOOK Version 8.1-- Timestamp: Wed Aug 18 17:22:47 CDT 2004-- Database Name: MICKY -- Database Manager Version: DB2/6000 Version 8.2.0 -- Database Codepage: 819-- Database Collating Sequence is: UNIQUE-- COMMIT is omitted. Explicit commit is required after executing the script.

-- Binding package automatically ... -- Bind is successful-- Binding package automatically ... -- Bind is successful

-------------------------------------- DDL Statements for BUFFERPOOLS -------------------------------------- CREATE BUFFERPOOL "BP1" SIZE 4000 PAGESIZE 8192 NOT EXTENDED STORAGE;

CONNECT RESET;CONNECT TO MICKY;

-------------------------------------- DDL Statements for TABLESPACES --------------------------------------

CREATE REGULAR TABLESPACE SYSTOOLSPACE IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY SYSTEM

USING ('/usr/db2/db2inst2/NODE0000/SQL00001/SYSTOOLSPACE') EXTENTSIZE 32 PREFETCHSIZE AUTOMATIC BUFFERPOOL IBMDEFAULTBP OVERHEAD 12.670000 TRANSFERRATE 0.180000 DROPPED TABLE RECOVERY ON;

CREATE REGULAR TABLESPACE HARRY IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 8192 MANAGED BY DATABASE

USING (FILE '/usr/db2/harryts'256,FILE '/usr/db2/harryts2'256)

EXTENTSIZE 8 PREFETCHSIZE 8 BUFFERPOOL BP1 OVERHEAD 12.500000 TRANSFERRATE 0.130000 DROPPED TABLE RECOVERY ON;

................


-- Mimic tablespace

ALTER TABLESPACE SYSCATSPACE PREFETCHSIZE AUTOMATIC OVERHEAD 12.670000 TRANSFERRATE 0.180000;

ALTER TABLESPACE TEMPSPACE1 PREFETCHSIZE AUTOMATIC OVERHEAD 12.670000 TRANSFERRATE 0.180000;

ALTER TABLESPACE USERSPACE1 PREFETCHSIZE AUTOMATIC OVERHEAD 12.670000 TRANSFERRATE 0.180000;

----------------------------------- DDL Statements for distinct types and/or Abstract Data Types---------------------------------

CREATE DISTINCT TYPE "DB2INST2"."NEWTYPE" AS "SYSIBM ".BLOB(1024);

COMMENT ON TYPE "DB2INST2"."NEWTYPE" IS 'sample data type';

----------------------------------- DDL statements for User Defined Functions---------------------------------

CREATE FUNCTION DB2INST2.FUNCTION1( ) RETURNS INTEGER-------------------------------------------------------------------------- SQL UDF (Scalar)------------------------------------------------------------------------F1: BEGIN ATOMIC RETURN SELECT count(*) FROM SYSCAT.FUNCTIONS;--END;

-------------------------------------------------- DDL Statements for table "DB2INST2"."KAITLYN"------------------------------------------------


CREATE TABLE "DB2INST2"."KAITLYN" (

"ONE" INTEGER ) IN "SYSTOOLSPACE" ;

-------------------------------------------------- DDL Statements for table "DB2INST2"."T1"------------------------------------------------ CREATE TABLE "DB2INST2"."T1" (

"COL1" INTEGER NOT NULL ) IN "SYSTOOLSPACE" ;

14.4.5 Maintaining database integrityYou can check for database integrity using two options:

� The INSPECT command, new with DB2 Version 8, enables you to inspect table spaces and tables for their architectural integrity while your database remains online.The inspection validates table objects and table space structures.

� The DB2DART utility accomplishes the same result. However, no database access is allowed while the tool is running.

Both INSPECT and DB2DART are run from the command line. There are many options available, such as specifying a table space or table spaces, tables, and schema. Example 14-7 shows INSPECT for the database micky. The results keep is important, because the file will not be kept unless there are problems reported by the utility. After you run INSPECT, you must use the db2inspf facility to format the results. In Example 14-7, we direct the results to file inspmicky.fmt and then display the output.

Example 14-7 INSPECT output

db2inst2:/usr/db2/db2inst2> db2 inspect check database results keep inspmicky.bin DB20000I The INSPECT command completed successfully.

db2inst2:/usr/db2/db2inst2> db2inspf inspmicky.bin inspmicky.fmtA partial listing of file inspmicky.fmt is shown below.

DATABASE: MICKY VERSION : SQL08020 2004-08-19-16.24.33.965157


Action: CHECK DATABASEResult file name: inspmicky.bin Database phase start. Tablespace phase start. Tablespace ID: 0 Tablespace name: SYSCATSPACE Tablespace Type: SMS - System Managed Space; Extent size: 32; Page size: 4096; Number of containers: 1 Container name: /usr/db2/db2inst2/NODE0000/SQL00001/SQLT0000.0 Table phase start (ID Signed: 2, Unsigned: 2; Tablespace ID: 0) : Data phase start. Object: 2 Tablespace: 0 The index type is 2 for this table. DAT Object Summary: Total Pages 33 - Used Pages 33 - Free Space 5 % Data phase end. Index phase start. Object: 2 Tablespace: 0 INX Object Summary: Total Pages 18 - Used Pages 18 Index phase end. LOB phase start. Object: 2 Tablespace: 0 LOB Object Summary: Total Pages 576 - Used Pages 572 LBA Object Summary: Total Pages 2 - Used Pages 2 LOB phase end. Table phase end.......

For more information, refer to IBM DB2 UDB Command Reference, SC09-4828.

14.4.6 Throttling utilitiesDB2 maintenance utilities, such as BACKUP and REBALANCE, can be very resource intensive. Running them can impact the performance of your production system. Such utilities are typically scheduled to run in off-peak hours. However, today's business demand of constant uncompromised availability makes finding any off-peak time almost impossible. Deferring these utility tasks is not an option, because they are required to assure data integrity and maintain query performance. With the introduction of utility throttling, you can regulate the performance impact of maintenance utilities so that they can be run concurrently with production periods. You can develop a throttling policy that will run the utilities aggressively when the production workload is light, but will run them more conservatively as production demands increase.


The ability to throttle utilities enables you to:

� Execute maintenance tasks with total control over the performance impact to the production workload. This eliminates the need to identify off-peak hours or schedule downtime for utility tasks.

� Ensure that valuable system resources are fully used by utilities in periods of reduced demand.

� Eliminate performance impact as a consideration when monitoring a utility and configuring its parameters (for example, setting the PARALLELISM parameter for a backup invocation). After a throttling policy is established, it is the system's responsibility to ensure that the policy is obeyed (to the extent possible).

The SET UTIL_IMPACT_PRIORITY command changes the impact setting for a running utility. Using this command, you can throttle a utility that was invoked in unthrottled mode, unthrottle a throttled utility (disable throttling), or reprioritize a throttled utility. You can monitor utility progress using the Utility Monitor tool, which is accessible in the Control Center by right-clicking the database and selecting Manage Utilities. The command line equivalent to the Utility Monitor is LIST UTILITIES.

The general syntax for SET UTIL_IMPACT_PRIORITY is:

set util_impact_priority for <utility ID> to <percent resources>

You can obtain the utility ID through the LIST UTILITIES command (we did this earlier to obtain the number 13 in the following example). This command is also used to show the progress of a backup. Here, we set UTIL_IMPACT PRIORITY to 10% of the system resources. Example 14-8 shows how we are performing a backup on database ifmx2db2. We also see that the backup is 93% complete.

Example 14-8 Utility throttling

db2inst2:/db2fs/micky> db2 backup database ifmx2db2 onlineIn another session, issue: db2inst2:/home/db2inst2> db2 set util_impact_priority for 13 to 10DB20000I The SET UTIL_IMPACT_PRIORITY command completed successfully.Now LIST UTILITIES.... db2 => list utilities

ID = 13Type = BACKUPDatabase Name = IFMX2DB2Partition Number = 0Description = online dbStart Time = 08/18/2004 18:36:18.506409Throttling: Priority = 10Progress Monitoring: Estimated Percentage Complete = 93


14.4.7 Validating a backupThe db2ckbkp (check backup) utility 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.

In Example 14-9, we validated the backup taken on 20040818 at 18:22:47. Note that the command window truncated the full backup file name.

Example 14-9 The db2ckbkp utility

db2inst2:/db2fs/micky> ls IFMX*IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818182247.001IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818182617.001IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818183231.001IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818183414.001IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818183517.001IFMX2DB2.0.db2inst2.NODE0000.CATN0000.20040818183618.001db2inst2:/db2fs/micky> db2ckbkp IFMX2DB2.0.db2inst2.NODE0000.CATN0000.2004081>

[1] Buffers processed: #######

Image Verification Complete - successful.db2inst2:/db2fs/micky>

For more information, refer to IBM DB2 UDB Command Reference, SC09-4828.

14.5 Other administrative operationsOther administrative operations that you will perform can include configuring automatic maintenance and working with databases and tables. In this section, we provide some brief examples. We also discuss the command line processor (CLP) and how to use the CLP to run batch scripts.

14.5.1 Configuring automatic maintenanceDB2 provides automatic maintenance capabilities for performing database backups, keeping statistics current, and reorganizing tables and indexes. 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. You can also configure automatic maintenance using the Control Center.


Automatic database backupAutomatic database backup provides users with a solution to help ensure that their database is being backed up both properly and regularly, without having to worry about when to back up or having any knowledge of the backup command.

Automatic database backup determines the need to perform a backup operation based on one or more of the following criteria:

� You have never completed a full database backup.

� The time elapsed since the last full backup is more than a specified number of hours.

� The transaction log space consumed since the last backup is more than a specified number of 4 KB pages (in archive logging mode only).

The automatic database backup feature can be enabled or disabled by using the auto_db_backup and auto_maint database configuration parameters.

Through the Configure Automatic Maintenance wizard in the Control Center or Health Center, you can configure the requested time or number of log pages between backups, the backup media, and whether it will be an online or offline backup.

Automatic database statisticsAutomatic statistics collection attempts to improve the performance of the database by maintaining up-to-date table statistics. Automatic statistics profiling advises when and how to collect table statistics by detecting outdated, missing, and incorrectly specified statistics and by generating statistical profiles based on query feedback. Automatic statistics collection works by determining the minimum set of statistics that give the optimal performance improvement. The

Note: The first time you run the wizard, the Retrieving Policies phase might take some time as new tables are being created to store control information. If you do not want to wait, you can click Close, because the tables will then be created in the background. You can then continue with the wizard when the process is complete.

Important: If backup to disk is selected, the automatic backup feature will regularly delete backup images from the directory specified in the Configure Automatic Maintenance wizard. Only the most recent backup image is guaranteed to be available at any given time. We recommend that this directory be kept exclusively for the automatic backup feature and not be used to store other backup images.


decision to collect or update statistics is taken by observing and learning how often tables are modified and how much the table statistics have changed. The automatic statistics collection algorithm learns over time how fast the statistics change on a per table basis and internally schedules runstats execution accordingly.

Normal database maintenance activities, such as runstats, reorg, or altering or dropping a table, are not affected by the enablement of this feature. The automatic statistics collection feature can be enabled or disabled by using the auto_runstats, auto_tbl_maint, and auto_maintdatabase configuration parameters.

Tables considered for automatic statistics collection are configurable by you using the Automatic Maintenance wizard from the Control Center or Health Center.

Automatic reorganizationAutomatic reorganization manages offline table and index reorganization without users having to worry about when and how to reorganize their data. Automatic reorganization determines the need for reorganization on tables by using the reorgchk formulas. It periodically evaluates tables that have had their statistics updated to see if reorganization is required. If so, it internally schedules a classic reorganization (that is, offline) for the table. This requires that your applications function without write access to the tables being reorganized.

The automatic reorganization feature can be enabled or disabled by using the auto_reorg, auto_tbl_maint, and auto_maint database configuration parameters.

You can configure automatic reorganization using the Automatic Maintenance wizard from the Control Center or Health Center.

Automation exampleThe following example uses the Control Center wizard to configure automatic maintenance. You can use this wizard to enable and disable maintenance.

In the Control Center, right-click the database and select Configure Automatic Maintenance. Here, we enable maintenance. Select Change Automation Settings in the Select Automatic Maintenance Type window. This window also displays the current settings for maintenance, which are all turned off. Next, specify when maintenance activities can be run. You can specify both online and offline windows. We define an online window as 00-4 a.m., 7 days a week, and an offline window on the fifteenth of the month for one hour. In the next window, add names to the notification list for health messages. These are the messages that are generated when the utilities run.


Select a maintenance activity to configure. We chose backup, reorg, and runstats. You can specify filters, such as select tables on runstats and reorg, and backup options, such as backup location, online or offline, and criteria for backup. For example, we define the maximum time between backups and maximum log space used between backups by clicking the Customize button on the Backup Criteria window. In this example, we leave the defaults.

Finally, Figure 14-34 shows you all the options you have selected.

Figure 14-34 Configure maintenance example

Click Finish to complete the Configure Maintenance wizard and to turn on maintenance.

Automation maintenance windows The automatic maintenance features previously described consume resources on your system and can affect the performance of your database when they are run. Automatic reorganization and offline database backup also restrict access to the tables and database when these utilities are run. It is, therefore, necessary to provide appropriate periods of time when these maintenance activities can be internally scheduled for execution. These can be specified as offline and online maintenance time periods using the Automatic Maintenance wizard from the Control Center or Health Center.


Offline database backups and table and index reorganizations are run in the offline maintenance time period. These features run to completion even if they go beyond the time period specified. The internal scheduling mechanism learns over time and estimates job completion times. If the offline time period is too small for a particular database backup or reorganization activity, the scheduler will not start the job the next time and relies on the health monitor to provide notification of the need to increase the offline maintenance time period.

Automatic statistics collection and profiling, as well as online database backups, are run in the online maintenance time period. To minimize the impact on the system, they are throttled by the adaptive utility throttling mechanism. The internal scheduling mechanism uses the online maintenance time period to start the online jobs. These features run to completion even if they go beyond the time period specified.

Creating new databases with maintenance enabledYou can now enable various automatic maintenance features when creating a database from the Control Center and from First Steps. The automatic maintenance features can:

� Create a new database on the disk or directory of your choice � Assign disk space for the data � Configure the new database for performance � Turn on automatic maintenance � Configure notification by e-mail or pager if the database needs attention

Monitoring and notification The health monitor provides monitoring and notification functionality for the automatic database backup, statistics collection, and reorganization features. See 14.6.1, “Health check tools” on page 499 for more details about the health monitor.

14.5.2 Working with databasesIn this section, we discuss the basic tasks needed to set up a database. Prior to creating your database, you should spend sufficient time designing the contents, layout, potential growth, and use.

When you create a database, each of the following tasks are done for you:

� Setting up of all the system catalog tables that are needed by the database

� Allocation of the database recovery log

� Creation of the database configuration file with default values

� Binding of the database utilities to the database


� Granting of database privileges to PUBLIC: CREATETAB, BINDADD, CONNECT, IMPLICIT_SCHEMA, and SELECT on the system catalog views

To create a database using the Control Center:

1. Select the database object from the object tree, right-click, and select Create Database.

2. Select one of the three options: Standard, With Automatic Maintenance, or From Backup. We selected Automatic Maintenance. At this point the Create Database wizard opens.

3. We enter rowbanks as the name, and an alias of rowbanks. Click Next.

4. Select a maintenance strategy from one of two options:

– Yes I can specify an offline maintenance window of at least one hour when the database is inaccessible

– No I cannot specify an offline maintenance window

5. We select the No option, and click Next.

6. Now, select contact names for notification. We select db2inst2@greenland, and click Next.

7. Select the percentage of server memory you want the database to use by moving the slider bar as appropriate. We selected 24% or 7864mb. Click Next.

8. The Review the actions window, shown in Figure 14-35 on page 491, summarizes our actions. Click Finish.


Figure 14-35 Automatic Maintenance

Example 14-10 shows the syntax that was generated by the wizard. Note the AUTOCONFIGURE option in the CREATE DB statement and also the UPDATE DB CFG statements, which configure memory and set up automatic maintenance for backups, runstats, and reorgs.

Example 14-10 Create database rowbanks example

CREATE DB ROWBANKS ON / ALIAS ROWBANKS AUTOCONFIGURE USING MEM_PERCENT 24 APPLY DB ONLY;UPDATE DB CFG FOR ROWBANKS USING AUTO_MAINT ON;UPDATE DB CFG FOR ROWBANKS USING AUTO_DB_BACKUP ON;UPDATE DB CFG FOR ROWBANKS USING AUTO_TBL_MAINT ON;UPDATE DB CFG FOR ROWBANKS USING AUTO_RUNSTATS ON;UPDATE DB CFG FOR ROWBANKS USING AUTO_REORG ON;UPDATE ALERT CFG FOR DATABASE ON ROWBANKS USING db.db_backup_req SET THRESHOLDSCHECKED YES;UPDATE ALERT CFG FOR DATABASE ON ROWBANKS USING db.tb_reorg_req SET THRESHOLDSCHECKED YES;UPDATE ALERT CFG FOR DATABASE ON ROWBANKS USING db.tb_runstats_req SET THRESHOLDSCHECKED YES;


14.5.3 Working with tablesThe Control Center has extensive capabilities for working with tables. Using this tool, you can create and modify table structures, run queries, and even modify the data if you are authorized.

Creating a tableTo create a table:

1. In the Control Center, select Tables in the object tree, right-click, and select either Create or Create from Import. The Create Table wizard then opens to walk us through the process. In our example, we create a new table.

2. Next, we are prompted for the schema and table name and an optional comment. Figure 14-36 on page 493 shows this.

3. Now, add your columns. You will be prompted for the names, formats, lengths, and other options, such as default values, nullability, and any formulas. We added several columns: name_no, address, city, state, and zip. The windows in which to enter additional information open, but we do not shown them here.


Figure 14-36 Create Table wizard Add Column window

4. For example, in the next window, enter the table space you want to use. You can also leave it as the default or create a new one. If you are using DMS table spaces, you can specify a separate index and long table space. In this example, we leave the table space name as the default, which is userspace1.

5. In the next window, define your keys: primary, unique, foreign, or partitioning. Partitioning keys are only used if you have the DPF option for DB2 enabled. In this example, we add a foreign key on name_no (in the following Alter Table example, we show adding the primary key for the corresponding names table). We also define ON DELETE options.


At this point, you have the option to define data clustering, also known as multidimensional dimensional clustering (for more details, see 9.2.2, “Multidimensional cluster” on page 305). We skipped this option.

You can also define check constraints for your table. We skipped this option as well.

6. Finally, you are presented with a summary window. Click Show SQL to display the create table syntax. For the command line user, you can see that the syntax is quite similar to IDS. Click Finish to create the table. Figure 14-37 shows the summary window and generated SQL syntax.

Figure 14-37 Creating a table: Summary window and SQL syntax

Altering a tableUse the Alter Table function in the Control Center to make the following changes to your table:

� Add columns � Add predefined columns � Change an existing column (Version 8.2 or later) � Change a comment on an existing column (pre-Version 8.2)


� Change the length of an existing VARCHAR column (pre-Version 8.2) � Change a new column � Define or change the primary key � Add or change unique keys � Add or change foreign keys � Define or change partitioning keys (DPF option only)� Add or change check constraints � Change table properties

In our example, we use the Alter Table function to add a primary key to the names table.

To add a primary key:

1. Select the table in the object list within the Control Center, right-click, and select Alter Table. The wizard has four tabs where you can make changes: Columns, Keys, Check Constraints, and Table.

2. We are adding a primary key called name_no to the names table in the family database. Click the Keys tab.

3. Click Add Primary, and select the desired column or columns for the primary key.

Figure 14-38 on page 496 shows the Keys tab, showing the primary key, and the resulting SQL that was generated.


Figure 14-38 Alter Table window

14.5.4 Command line processorThe command line processor (CLP) is the interface for running interactive DB2 commands or for running scripts. To access the CLP, type DB2 from the UNIX prompt. For Windows, you can access the CLP by selecting Start → Programs → IBM DB2 → Command Line Tools → Command Line Processor. From this environment, you can run any DB2 command without having to prefix the command with “DB2”.

In Example 14-11 on page 497, we connect to the database family and issue a SELECT statement on the names table. Note how the output is sent to the screen. For this test, we initiated a CLP session from a Windows client with a connection to a database on a UNIX server.

Note: Some types of table changes will result in the unloading and reloading of your table. The wizard will generate appropriate syntax to do this.


Example 14-11 Command line processor

(c) Copyright IBM Corporation 1993,2002Command Line Processor for DB2 SDK 8.2.0

You can issue database manager commands and SQL statements from the commandprompt. For example: db2 => connect to sample db2 => bind sample.bnd

For general help, type: ?.For command help, type: ? command, where command can bethe first few keywords of a database manager command. For example: ? CATALOG DATABASE for help on the CATALOG DATABASE command ? CATALOG for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outsideinteractive mode, all commands must be prefixed with 'db2'.To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.

db2 => connect to family user db2prime using xxxxx

Database Connection Information

Database server = DB2/6000 8.2.0 SQL authorization ID = DB2PRIME Local database alias = FAMILY

db2 => select * from names

NAME_NO FNAME----------- --------------- 1 Rhoda 2 Murray 3 Andrue 4 Donna 5 Harry 6 Micky 7 Mike 8 Larry 9 Carol 10 Kaitlyn 11 David 12 Michael 13 Rebecca 14 Henry 15 Midge


16 Shelley 17 Megan 18 Rob 19 Mikayla 20 Fiona 21 Brendan 22 Shannon 23 Jeff 24 Moira 25 Fred 26 Zachary 27 Kirsi 28 Leslie 29 Kevin 30 Rutherford

30 record(s) selected.

You can also run batch scripts by invoking DB2 from the command line, as follows:

db2 -tvf <inputscriptfilename.sql>

In Example 14-12, we took the connect and SELECT statements and placed them into a script called names.sql. Typically, the output is sent to the screen, but you can also redirect it to a file, as we have done here.

Example 14-12 Batch command line processor example

First, run the program... C:\Program Files\IBM\SQLLIB\BIN>db2 -tvf names.sql > names.outHere is the batch file: connect to family user db2prime using xxxx;select * from names;The output from names.out shows the session output, including the connect and statements that were executed: connect to family user db2prime using

Database Connection Information

Database server = DB2/6000 8.2.0 SQL authorization ID = DB2PRIME Local database alias = FAMILY

select * from names

NAME_NO FNAME----------- ---------------


1 Rhoda 2 Murray 3 Andrue 4 Donna 5 Harry 6 Micky 7 Mike 8 Larry 9 Carol 10 Kaitlyn 11 David.......

14.6 Monitoring tools and advisorsDB2 offers a wide variety of monitoring tools and advisors, which we discuss in this section. These tools help make the DBA’s job easier by proactively monitoring conditions and advising a course of action. To facilitate monitoring, DB2 collects information from the database manager, its databases, and any connected applications. With this information, you can do the following and more:

� Forecast hardware requirements based on database usage patterns� Analyze the performance of individual applications or SQL queries� Track the usage of indexes and tables� Pinpoint the cause of poor system performance� Assess the impact of optimization activities (for example, altering database

manager configuration parameters, adding indexes, or modifying SQL queries)

In this section, we discuss the various tools and facilities for monitoring the database.

14.6.1 Health check toolsHere, we discuss the health check monitor, Health Center tool, and Recommendation Advisor. The health monitor is a server-side tool that adds a management-by-exception capability by constantly monitoring the health of an instance and active databases and table space and table space containers, without user interaction. The health monitor proactively detects issues that might lead to hardware failure, or to unacceptable system performance or capability. The proactive nature of the health monitor enables users to address an issue before it becomes a problem that affects system performance. This management-by-exception model frees up valuable DBA resources by


generating alerts to potential system health issues without requiring active monitoring.

If the health monitor finds that a defined threshold has been exceeded (for example, the available log space is not sufficient), or if it detects an abnormal state for an object (for example, an instance is down), the health monitor will raise an alert. When an alert is raised, two things can occur:

� Alert notifications can be sent by e-mail or to a pager address, enabling you to contact whoever is responsible for a system.

� Preconfigured actions can be taken. For example, a script or a task (implemented from the new Task Center) can be run.

A health indicator is a system characteristic that the health monitor checks against health-indicator thresholds when determining whether to issue an alert. The health monitor comes with a set of predefined thresholds for these health indicators. Using the Health Center, commands, or APIs, you can customize the threshold settings of the health indicators and define who should be notified and what script or task should be run if an alert is issued.

The health monitor can only evaluate health indicators on a database and its objects when the database is active. You can keep the database active either by starting it with the ACTIVATE DATABASE command or by maintaining a permanent connection to the database.

The Health Center provides the graphical interface to the health monitor. Use the Health Center to configure the health monitor and to see the alert state of your instances and database objects. With the health monitor drill-down capability, you can access details about current alerts and obtain a list of recommended actions that describe how to resolve the alert. You can follow one of the recommended actions to address the alert. If the recommended action is to make a database or database manager configuration change, a new value will be recommended. You can then implement the recommendation by clicking a button directly from within the tool. In other cases, the recommendation will be to investigate the problem further by launching a tool, such as the CLP or the Memory Visualizer.

The Health Center and Control Center are integrated through Health Beacons. Health Beacons provide notifications about new alerts in the Health Center. Beacons are implemented on all Control Center windows and notebooks. Click a

Note: The health monitor gathers information about the health of the system using interfaces that do not impose a performance penalty, such as data retrieved from database system monitor elements and the operating system. It does not turn on any snapshot monitor switches to collect information.


Health Beacon to access the Health Center. Figure 14-39 shows a Health Beacon in the bottom-right corner of the window, which is circled in blue. You will see there are three new Health Center alerts. Click the ! beacon to launch the Health Center.

Figure 14-39 Object View

There is also Web Health Center that can be used to access the health monitor information from a Web browser or PDA. For more information, see 14.2.14, “Web administration” on page 449.

The Recommendation Advisor helps you to resolve health alerts on DB2 objects. The Recommendation Advisor provides recommendations that can correct the issue causing a health alert. In addition, the Recommendation Advisor helps you to implement the recommendation that you select, whether this requires


launching a tool, running a script, or adjusting the configuration parameter settings on an instance or a database.

Health Center and Recommendation Advisor exampleAs previously mentioned, when an alert beacon is displayed in the Control Center, you can click it to launch Health Center and investigate the alert.

Figure 14-40 on page 503 shows an alert on instance DB2. There is color coding to signify the severity of the problem (red, yellow, and green). In this example, monitor heap utilization is 129%. To obtain more information about this alert, right-click the alert. The detail window provides you with a definition of the alert, current warning and alarm thresholds, and a description of the significance of the element. Click the Display History button to see details about the alert history. Here, we see the alert started at 135% and decreased to 129%.


Figure 14-40 Health Center alert for monitor heap utilization


Now that we have determined that a problem exists in the monitor heap size, we can use the Recommendation Advisor to help us diagnose the problem:

1. To use the advisor, right-click the Monitor Heap Utilization alarm, and select Recommendation Advisor.

2. First, the Recommendation Advisor will ask you a series of questions about your environment and objectives for resolving the problem. You can choose to do a full investigation, or to get an immediate solution to the problem. We chose to conduct a full investigation. Figure 14-41 displays the Recommendation Advisor recommendations. It suggests that we investigate memory usage and also increase the monitor heap size.

3. We decide to investigate memory usage and click the preferred recommendation. Click Next. This takes you to a window (not shown) suggesting that we launch the Memory Visualizer tool. We clicked the Launch button to start the tool, which we discuss in the next section.

Figure 14-41 Recommendation Advisor suggestions


14.6.2 Memory VisualizerThe Memory Visualizer is a DB2 tool that helps database administrators to monitor the memory-related performance of an instance and all of its databases. Using the tool, you can select, display, and graph memory usage for one or more memory components.

The Memory Visualizer window displays two views of data: a tree view and a historical view. A series of columns show percentage threshold values for upper and lower alarms and warnings. The columns also display real-time memory utilization. With the Memory Visualizer, you can:

� View data on the memory utilization of selected components for a DB2 instance and its databases.

� Change settings for individual memory components by updating configuration parameters.

� Load performance data from a file into a Memory Visualizer window.� Save the performance data for later analysis

Memory Visualizer exampleThe initial Memory Visualizer window displays a list of monitored objects, along with their percentage utilization and threshold values. In Figure 14-42 on page 506, we see that not only is the database monitor heap above the threshold, but so is the lock manager heap. We select both elements by selecting the check boxes for these elements under the Show Plot column. Selecting the memory elements enables you to plot memory usage, as shown in Figure 14-43 on page 517. We changed the default refresh to a one minute interval. Over the course of several minutes, we see that both element values are increasing. The lock manager increase is the result of an insert statement that occurred during this time period (in the background, we submitted an insert). We might still need to investigate the increase in the monitor heap and investigate whether we need all monitor switches turned on or not (we turned them on previously for the database snapshot capability). At this point, you might want to increase the heap size to provide additional capacity.


Figure 14-42 Memory Visualizer example

14.6.3 Storage ManagerThe Storage Manager, which is accessible from the Control Center, provides you with the ability to manage table spaces and containers and to monitor size over time and set warning indicators and thresholds. For more information, see “The Storage Management tool” on page 157.

14.6.4 Event monitorEvent monitors are used to collect information about the database and any connected applications when specified events occur. This is equivalent to running IDS onstat commands, except that unlike the onstat command, event


monitors must be enabled. Events represent transitions in database activity, for example, connections, deadlocks, statements, and transactions. You can define an event monitor by the type of event or events you want it to monitor. For example, a deadlock event monitor waits for a deadlock to occur; when one does, it collects information about the applications involved and the locks in contention. By default, all databases have an event monitor named DB2DETAILDEADLOCK defined, which keeps track of DEADLOCKS WITH DETAILS. The DB2DETAILDEADLOCK event monitor starts automatically when the database starts.

While the snapshot monitor is typically used for preventative maintenance and problem analysis, event monitors are used to alert administrators to immediate problems or to track impending ones. To create an event monitor, use the CREATE EVENT MONITOR SQL statement. Event monitors collect event data only when they are active. To activate or deactivate an event monitor, use the SET EVENT MONITOR STATE SQL statement. The status of an event monitor (whether it is active or inactive) can be determined by the SQL function EVENT_MON_STATE.

Event monitor output can be directed to SQL tables, a file, or a named pipe. For example, you can request that DB2 logs the occurrence of deadlocks between connections to a database. We illustrate this activity using the example database that is distributed with DB2, called sample. You can create this database by running the script db2sampl, much like you create the stores_demo database in IDS.

First, you must create and activate a DEADLOCK event monitor. Example 14-13 shows the process to do that.

Example 14-13 Create and activate deadlock event monitor

db2 CONNECT TO sampledb2 "CREATE EVENT MONITOR dl FOR DEADLOCKS WRITE TO FILE ‘/tmp/dl'"mkdir /tmp/dldb2 "SET EVENT MONITOR dl STATE 1"Now, two applications using the database enter a deadlock. That is, each one is holding a lock that the other one needs in order to continue processing. The deadlock is eventually detected and resolved by the DB2 deadlock detector component, which will rollback one of the transactions. This can be set up with the following scenario:Application 1:db2 CONNECT TO sampledb2 +c "INSERT INTO staff VALUES (1, 'Ofer', 1, 'Mgr', 0, 0, 0)"

DB20000I The SQL command completed successfully.The +c option turns autocommit off for CLP. Application 1 is now holding an exclusive lock on a row of the staff table.Application 2:


db2 CONNECT TO sampledb2 +c "INSERT INTO department VALUES (‘1', 'System Monitor', '1', 'A00', NULL)"DB20000I The SQL command completed successfully.Application 2 now has an exclusive lock on a row of the department table.Application 1:db2 +c SELECT deptname FROM departmentAssuming cursor stability, Application 1 needs a share lock on each row of the department table as the rows are fetched, but a lock on the last row cannot be obtained because Application 2 has an exclusive lock on it. Application 1 enters a LOCK WAIT state, while it waits for the lock to be released.Application 2:db2 +c SELECT name FROM staffApplication 2 also enters a LOCK WAIT state, while waiting for Application 1 to release its exclusive lock on the last row of the staff table.These applications are now in a deadlock. This waiting will never be resolved because each application is holding a resource that the other one needs to continue. Eventually, the deadlock detector checks for deadlocks (set by the DLCHKTIME database manager configuration parameter) and chooses a victim to rollback:Application 2:SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "2". SQLSTATE=40001At this point the event monitor logs a deadlock event to its target (in this case, file /tmp/dl). Application 1 can now continue. Because an event monitor buffers its output and this scenario did not generate enough event records to fill a buffer, the event monitor values must be flushed to the event monitor output writer:Monitor Session:db2 "FLUSH EVENT MONITOR dl BUFFER"DB20000I The SQL command completed successfully.The event trace is written as a binary file. It can now be formatted using the db2evmon tool:Monitor Session:

cindym:/home/cindym> db2evmon -path /tmp/dlFrom the output below, you will see that application id LOCAL.db2inst2.05CD70204424 holds an exclusive lock on STAFF, while application id LOCAL.db2inst2.0328D0205132 holds an exclusive lock on the DEPARTMENT table. (To see a list of application ids, issue the command db2 list applications). Here is the output that shows the applications connected, with the lock holders highlighted in blue:

Reading /tmp/dl/00000000.evt ...-------------------------------------------------------------------------- EVENT LOG HEADER Event Monitor name: DL


Server Product ID: SQL08020 Version of event monitor data: 7 Byte order: BIG ENDIAN Number of nodes in db2 instance: 1 Codepage of database: 819 Territory code of database: 1 Server instance name: db2inst2--------------------------------------------------------------------------

-------------------------------------------------------------------------- Database Name: SAMPLE Database Path: /home/db2inst2/db2inst2/NODE0000/SQL00012/ First connection timestamp: 08/30/2004 15:44:24.608529 Event Monitor Start time: 08/30/2004 15:48:19.134171--------------------------------------------------------------------------

3) Connection Header Event ... Appl Handle: 28 Appl Id: *LOCAL.db2inst2.05CD70204424 Appl Seq number: 0008 DRDA AS Correlation Token: *LOCAL.db2inst2.05CD70204424 Program Name : db2bp Authorization Id: DB2INST2 Execution Id : db2inst2 Codepage Id: 819 Territory code: 1 Client Process Id: 220374 Client Database Alias: SAMPLE Client Product Id: SQL08020 Client Platform: AIX Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2004 15:44:24.608529

4) Connection Header Event ... Appl Handle: 29 Appl Id: *LOCAL.db2inst2.06BA10204452 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.db2inst2.06BA10204452 Program Name : db2bp Authorization Id: CINDYM Execution Id : cindym Codepage Id: 819 Territory code: 0 Client Process Id: 224160 Client Database Alias: SAMPLE Client Product Id: SQL08020 Client Platform: AIX Client Communication Protocol: Local


Client Network Name: Connect timestamp: 08/30/2004 15:44:52.116007

5) Connection Header Event ... Appl Handle: 30 Appl Id: *LOCAL.db2inst2.0328D0205132 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.db2inst2.0328D0205132 Program Name : db2bp Authorization Id: DB2INST2 Execution Id : db2inst2 Codepage Id: 819 Territory code: 0 Client Process Id: 209548 Client Database Alias: SAMPLE Client Product Id: SQL08020 Client Platform: AIX Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2004 15:51:32.031193

6) Deadlock Event ... Deadlock ID: 1 Number of applications deadlocked: 2 Deadlock detection time: 08/30/2004 15:52:34.669479 Rolled back Appl participant no: 2 Rolled back Appl Id: *LOCAL.db2inst2.0328D0205132 Rolled back Appl seq number: : 0001

7) Deadlocked Connection ... Deadlock ID: 1 Participant no.: 2 Participant no. holding the lock: 1 Appl Id: *LOCAL.db2inst2.0328D0205132 Appl Seq number: 0001 Appl Id of connection holding the lock: *LOCAL.db2inst2.05CD70204424 Seq. no. of connection holding the lock: 0009 Lock wait start time: 08/30/2004 15:52:25.477427 Lock Name : 0x00020003000000270000000052 Lock Attributes : 0x00000000 Release Flags : 0x00000001 Lock Count : 1 Hold Count : 0 Current Mode : none Deadlock detection time: 08/30/2004 15:52:34.669479 Table of lock waited on : STAFF Schema of lock waited on : DB2INST2 Tablespace of lock waited on : USERSPACE1 Type of lock: Row


Mode of lock: X - Exclusive Mode application requested on lock: NS - Share (and Next Key Share) Node lock occured on: 0 Lock object name: 39 Application Handle: 30

8) Deadlocked Connection ... Deadlock ID: 1 Participant no.: 1 Participant no. holding the lock: 2 Appl Id: *LOCAL.db2inst2.05CD70204424 Appl Seq number: 0009 Appl Id of connection holding the lock: *LOCAL.db2inst2.0328D0205132 Seq. no. of connection holding the lock: 0001 Lock wait start time: 08/30/2004 15:52:13.358644 Lock Name : 0x000200040000000D0000000052 Lock Attributes : 0x00000000 Release Flags : 0x00000001 Lock Count : 1 Hold Count : 0 Current Mode : none Deadlock detection time: 08/30/2004 15:52:34.669479 Table of lock waited on : DEPARTMENT Schema of lock waited on : DB2INST2 Tablespace of lock waited on : USERSPACE1 Type of lock: Row Mode of lock: X - Exclusive Mode application requested on lock: NS - Share (and Next Key Share) Node lock occured on: 0 Lock object name: 13 Application Handle: 28

You can also use the optional DB2 Performance Expert tool to identify locks. For more information, see 14.3.1, “DB2 Performance Expert” on page 451.

14.6.5 SnapshotsSnapshots are useful for diagnosing both operational and application issues, especially for situations that occur over time, such as deadlocks. Prior to the new db2pd command, snapshots and event monitors were the methods to obtain point-in-time information from the instance and database.

Like event monitors, you have the option of storing monitor information in files or SQL tables, viewing it on screen (directing it to standard out), or processing it with a client application.


The snapshot monitor provides two categories of information for each level being monitored: state and counter. State includes information such as current status of the database or application, or both, information about the current or most recent unit of work, a list of locks being held, the current number of database connections, and the most recent SQL statement. Counters accumulate counts for activities from the time monitoring started until the time a snapshot is taken. Counters are kept for items such as the number of deadlocks, number of database transactions, and application lock wait time.

Unlike the onstat utility, snapshots must be enabled through database manager configuration parameters or through application snapshot switches. You can select the appropriate switches to enable, which include buffer pool, lock, sort, statement, table, and unit of work.

There are two ways to set monitor switches: at the database manager level, using the update dbm cfg command, and at the application level, using the update monitor switches command.

To set or deactivate a switch at the instance level, use the syntax:

db2 update dbm cfg using dft_mon_<switchname> <on/off>

Where <switchname> is DFT_MON_BUFPOOL, DFT_MON_LOCK, DFT_MON_SORT, DFT_MON_STMT, DFT_MON_TABLE, or DFT_MON_UOW.

For example:

root:/> db2 update dbm cfg using dft_mon_lock onDB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed successfully.

To set or deactivate a switch at the application level, use the syntax:

update monitor switches using <switchname> <on/off>

For example, to set the sort switch on, use:

root:/> db2 update monitor switches using lock onDB20000I The UPDATE MONITOR SWITCHES command completed successfully.

You can also set multiple switches by listing the parameters separated by spaces.

To display monitor switches for your instance, use the db2 get dbm cfg command as follows:

db2inst2:/> db2 get dbm cfg

Example 14-14 on page 513 shows a partial output of the dbm cfg command showing the monitor switch settings.


Example 14-14 Monitor switch settings

Buffer pool (DFT_MON_BUFPOOL) = ONLock (DFT_MON_LOCK) = ONSort (DFT_MON_SORT) = OFFStatement (DFT_MON_STMT) = OFFTable (DFT_MON_TABLE) = OFFTimestamp (DFT_MON_TIMESTAMP) = ONUnit of work (DFT_MON_UOW) = OFF

To display monitor switches for your application, issue the command shown in Example 14-15.

Example 14-15 Display monitor switches

db2inst2:/> db2 get dbm monitor switches

DBM System Monitor Information Collected

Switch list for db partition number 0Buffer Pool Activity Information (BUFFERPOOL) = ON 08/27/2004 12:04:32.268686Lock Information (LOCK) = ON 08/27/2004 18:41:54.704815Sorting Information (SORT) = OFFSQL Statement Information (STATEMENT) = OFFTable Activity Information (TABLE) = OFFTake Timestamp Information (TIMESTAMP) = ON 08/27/2004 12:04:32.268686Unit of Work Information (UOW) = OFF

You can see that buffer pool and lock switches are set to on.

Example 14-16 on page 514 shows how you can obtain a list of the locks held by applications connected to a database using a database lock snapshot.

First, we turned on the LOCK switch so that the time spent waiting for locks is collected.

Next, as shown in Example 14-16 on page 514, we connect to the database, start a transaction, and then take the snapshot.


Example 14-16 Snapshot

db2inst2:/home/db2inst2> db2 connect to ifmx2db2db2 Database Connection Information

Database server = DB2/6000 8.2.0 SQL authorization ID = DB2INST2 Local database alias = IFMX2DB2

db2inst2:/home/db2inst2> db2 +c list tables for all Table/View Schema Type Creation time------------------------------- --------------- ----- --------------------------ADVISE_INDEX DB2INST2 T 2004-07-19-19.37.49.363333ADVISE_INSTANCE DB2INST2 T 2004-07-19-19.37.48.876527CATALOG DB2INST2 T 2004-08-02-16.51.49.607423CUST_CALLS DB2INST2 T 2004-08-02-16.51.50.272099CUSTOMER DB2INST2 T 2004-08-02-16.51.50.637357....... (etc)db2inst2:/home/db2inst2> db2 get snapshot for locks on ifmx2db2

Database Lock Snapshot

Database name = IFMX2DB2Database path = /usr/db2/ifmx2db2/db2inst2/NODE0000/SQL00001/Input database alias = IFMX2DB2Locks held = 4Applications currently connected = 2Agents currently waiting on locks = 0Snapshot timestamp = 08/27/2004 19:29:23.032842

Application handle = 99Application ID = *LOCAL.db2inst2.034A18002636Sequence number = 0001Application name = db2bpCONNECT Authorization ID = DB2INST2Application status = UOW WaitingStatus change time = Not CollectedApplication code page = 819Locks held = 2Total wait time (ms) = 0


List Of Locks Lock Name = 0x53514C4332453033A95B579A41 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 1 Hold Count = 0 Lock Object Name = 0 Object Type = Internal Plan Lock Mode = S

Lock Name = 0x53514C4445464C540763DD2841 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 1 Hold Count = 0 Lock Object Name = 0 Object Type = Internal Plan Lock Mode = SApplication handle = 85Application ID = G9306ADD.F30B.040827234019Sequence number = 0003Application name = javaw.exeCONNECT Authorization ID = DB2INST2Application status = UOW ExecutingStatus change time = Not CollectedApplication code page = 1208Locks held = 2Total wait time (ms) = 0

List Of Locks Lock Name = 0x00000001000000010001610056 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 1 Hold Count = 0 Lock Object Name = 0 Object Type = Internal Variation Lock Mode = S

Lock Name = 0x535953534832303028EFECDC41 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 1 Hold Count = 0 Lock Object Name = 0Object Type = Internal Plan LockMode = S


From this snapshot, you can see that there is currently one application connected to the IFMX2DB2 database, and it is holding four locks. The following lines are highlighted in blue in Example 14-16 on page 514:

Locks held = 4Applications currently connected = 2

The lock snapshot also returns the total time spent waiting for locks (so far) by applications connected to this database:

Total wait time (ms) = 0

This is an example of an accumulating counter. An application taking snapshots can reset its view of the counters at any time by using the RESET MONITOR command.

14.6.6 Activity MonitorThe Activity Monitor is a tool that assists database administrators in improving the efficiency of database performance monitoring, problem determination, and resolution. The Activity Monitor focuses on monitoring application performance, application concurrency, resource consumption, and SQL statement usage. It will help DBAs to diagnose the cause of database performance problems, such as application locking situations, and to tune queries for optimal utilization of database resources.

The Activity Monitor provides easy access to relevant and well-organized monitor data through a set of predefined reports such as top CPU time-consuming applications and SQL statements with the largest total sort time. For each predefined report, appropriate actions might be recommended to help resolve resource utilization problems, to optimize performance, or to invoke another tool for further investigation. Lock monitor data is also supplied to illustrate the details of lock waiting situations. Application lock chains can be displayed to show lock waiting dependencies.

The Activity Monitor is accessible through a GUI interface, the command line processor, and in the form of stored procedures and user-defined functions.

To use the Activity Monitor:

1. In the Windows environment, you can access the Activity Monitor by selecting Start → Programs → IBM DB2 → Monitoring Tools → Activity Monitor. In this example, we monitor the DB2 sample database.

2. Select the database to be monitored. Click Next.


3. Select the type of task you want to monitor. A set of tasks has been predefined for you: resolve a general database system slowdown, resolve performance degradation, resolve application locking, or tune dynamic SQL statement cache. You can also define your own task to monitor. We select Resolving a general database system slowdown, and then click Next.

4. At this point, you can specify a filter for the applications you want to monitor. We monitor all applications, which is the default. Click Next. The summary window, shown in Figure 14-43, summarizes our selections.

The result will be to turn on the snapshot monitor switches (for more information about snapshots, see, 14.6.5, “Snapshots” on page 511).

Figure 14-43 DB2 Activity Monitor setup


5. Click Finish. Monitoring is now enabled.

6. The next step is to select from a list of reports. We selected Top CPU time-consuming applications. Our report is shown in Figure 14-44. There are several other reports you can run to help you diagnose a problem, such as applications with the largest sort time, lock wait time, largest number of rows read or written, and so forth. Here, we see that the user MUNNS has consumed the most total CPU time for a given application.

Figure 14-44 Activity Monitor CPU consumption report

14.6.7 DB2 Performance ExpertThis optional tool, discussed in 14.3.1, “DB2 Performance Expert” on page 451, provides additional monitoring capabilities, such as the ability to graph performance elements and to discover longer-term performance trends.

14.6.8 The db2pd utility, an onstat equivalentWith Version 8.2 of DB2, the new db2pd utility provides a command line interface for monitoring DB2 instances and databases. This feature was implemented specifically to address the needs of IDS DBAs, who have derived great productivity and functionality from the onstat feature.


The db2pd utility was created with a look, feel, and function similar the IDS onstat utility. Like the onstat utility, it runs from the command line with an optional interactive mode. This tool can provide a wide range of information useful for troubleshooting and problem determination, performance improvements, and application development design, including:

� Locks� Buffer pools� Table spaces� Containers� Dynamic SQL statements� Agents� Applications� Memory pools and sets� Transactions� Logs

The db2pd utility is similar to the onstat utility in that it does not acquire any locks or latches or use instance resources. However, because the DB2 architecture is different from that of IDS, especially with regard to having more memory areas, the db2pd output will be somewhat different. For example, you have the ability to limit the scope of output to either the instance, or the database, by using the -ins or -db databasename modifiers. Using the db2pd utility with either modifier, by default, will provide all information for the instance or database. At the instance level, the information will include the DB2 version, operating system information (type, level, machine name), CPU, memory for both server and database instance, agents, the database manager configuration, and utilities status. At the database level, in addition to the DB2 version, operating system, CPU, and memory previously mentioned, the output includes the applications connected, transactions, buffer pools, logs, locks, table spaces, containers, cache, dynamic SQL, packages, database configuration, table and index statistics, and database organization status.

One thing to note is the use of abbreviations in the syntax. Most db2pd options and suboptions have a three-character minimum requirement. A user can use the full option name or any number of characters with a minimum of three. For the purposes of these examples, we use the minimum.

Table 14-5 on page 520 compares several onstat functions to their db2pd equivalents.


Table 14-5 pnstat and db2pd equivalents

In the next several sections, we provide side-by-side comparisons of the db2pd and onstat utilities.

LocksThe -locks option is used to show transactions that are holding and waiting on locks. This is equivalent to onstat -k. The “Sts” column indicates the status of the lock. W means waiting, and G means holding. In Example 14-17 on

Function db2pd onstat

Elapsed time since the instance was started.

db2pd - onstat -

Version information. db2pd -V onstat -V

All information (note that eve is an abbreviation for everything).

db2pd -eve onstat -a

Repeat command. db2pd repeat num sec n count n

onstat command -r n

Display locks. db2pd -db <database> -locks

onstat -k

Display session and application information.

db2pd -db <database> -applications

onstat -u

Display threads and agents.

db2pd -agents onstat -g ath

Display storage information (db2spaces and table spaces).

db2pd -db <database> -tablespaces

onstat -d

Display logs information. db2pd -db <database> -logs

onstat -l

Display transactions. db2pd -db <database> -transactions

onstat -x

Display memory segments and sets.

db2pd [-db <database>] -memsets

onstat -g seg

Display memory pools. db2pd [-db <database] -mempools

onstat -g mem

Display configuration. db2pd -dbmcfg onstat -c


, we see that transaction handle 3 is waiting on the lock held by transaction handle 2.

Example 14-17 db2pd -locks example

Informix Locks (onstat -k): address wtlist owner lklist type tblsnum rowid key#/bsiza14d098 0 10532e40 0 HDR+S 100002 204 0 a14d1e8 0 10532e40 a14d098 HDR+IX 10006e 0 0 a14d290 0 10532e40 a14d3e0 HDR+X 10006e 300 0 a14d2e4 10533448 10532e40 a14d1e8 HDR+X 10006e 100 0 a14d3e0 0 10532e40 a14d2e4 HDR+X 10006e 200 0 aea6fe0 0 10533448 0 S 100002 204 0 aea7034 0 10533448 aea6fe0 IX 10006e 0 0 7 active, 500000 total, 65536 hash buckets, 0 lock table overflows

Userthread 10533448 is waiting on the lock held by user 10532e40.

DB2 Locks (db2pd -db <database> -locks): Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse0x402B6340 2 00020003000000000000000054 Table .IX G 2 1 0 0 0x400x402B7178 3 00020003000000000000000054 Table .IX G 3 1 0 0 0x400x402B6480 2 00020003000000040000000052 Row ..X G 2 1 0 0 0x400x402B71A0 3 00020003000000040000000052 Row ..X W 2 1 0 0 0x400x402B64D0 2 00020003000000050000000052 Row ..X G 2 1 0 0 0x400x402B6520 2 00020003000000060000000052 Row ..X G 2 1 0 0 0x40

Sessions and applicationsDB2 applications are equivalent to IDS sessions. To find out which applications are connected to your database, you can either issue a LIST APPLICATIONS command or use the db2pd command, db2pd -applications, as shown in Example 14-18 on page 522. This is equivalent to the IDS onstat -u command. You can use this db2pd command to find the process ID and application handle for purposes of problem determination and tuning.


Example 14-18 db2pd -applications example

Informix Sessions (onstat -u)

Userthreadsaddress flags sessid user tty wait tout locks nreads nwrites10531018 ---P--D 1 informix - 0 0 0 15 1510531620 ---P--F 0 informix - 0 0 0 0 878410531c28 ---P--F 0 informix - 0 0 0 0 819210532230 ---P--- 9 informix - 0 0 0 0 347510532838 ---P--B 10 informix - 0 0 0 0 010532e40 Y-BP--- 34 informix 3 10f3c9c8 0 5 0 010533448 L--PR-- 35 informix 2 a14d2e4 -1 2 0 010533a50 ---P--D 13 informix - 0 0 0 0 0 8 active, 128 total, 19 maximum concurrent

DB2 Applications (db2pd -db <database> -applications)

Applications:Address AppHandl [nod-index] NumAgents CoorPid Status Appid 0x300E1690 26 [000-00026] 1 1941610 Lock-wait *LOCAL.jmcmahon.040824143331 0x300E3D70 13 [000-00013] 1 3203114 UOW-Waiting *LOCAL.jmcmahon.040824141858

Threads and agentsDB2 agents are equivalent to IDS threads. Each DB2 application has one or more agents. The db2pd command db2pd -agents shows you which agents are working on behalf of an application, as shown in Example 14-19. You can also look at the number of rows written and read and watch the progress of an agent.

Example 14-19 db2pd -agents example

Informix Threads (onstat -g ath)

Threads: tid tcb rstcb prty status vp-class name 2 10cd2860 0 2 sleeping forever 8lio lio vp 0 3 10d7c148 0 2 sleeping forever 9pio pio vp 0 4 10d91148 0 2 sleeping forever 10aio aio vp 0 5 10da6148 0 2 sleeping forever 11msc msc vp 0 6 10dd3148 0 2 sleeping forever 12aio aio vp 1 7 10de82a8 10531018 4 sleeping secs: 1 1cpu main_loop() 8 10de8e58 0 2 running 1cpu sm_poll

DB2 Agents (db2pd -agents)


Agents:Current agents: 3Idle agents: 0Active agents: 2Coordinator agents: 2

Address AppHandl [nod-index] AgentPid Priority Type State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt DBName 0x300EA4D0 26 [000-00026] 1941610 0 Coord Active 2252998 jmcmahon db2bp 0 0 NotSet SAMPLE 0x300E9370 13 [000-00013] 3203114 0 Coord Active 2527308 jmcmahon db2bp 47 35 NotSet SAMPLE 0x300E9B90 0 [000-00000] 2539662 0 Coord Pooled n/a n/a n/a 0 0

Dbspaces and table spacesUse the db2pd -tab command to list table space and container information, as shown in Example 14-20. This is equivalent to the onstat -D command. With this command, you can determine space utilization and storage allocations.

Example 14-20 db2pd -tab example

Informix Dbspaces and chunks(onstat -d)

Dbspacesaddress number flags fchunk nchunks flags owner name102047d8 1 0x1 1 1 N informix rootdbs 1 active, 2047 maximum

Chunksaddress chk/dbs offset size free bpages flags pathname10204928 1 1 0 500000 219747 PO- /dev/rdsk/c0t3d0s6 1 active, 2047 maximum

DB2 Tablespaces (db2pd -db <database> -tablespaces)

Tablespaces:Address Id Type Content PageSize ExtentSize Auto Prefetch BufID BufIDDisk State TotPages UsablePgs UsedPgs PndFreePgs FreePgs HWM MinRecTime NQuiescers NumCntrs MaxStripe Name 0x4037D7F0 0 SMS Any 4096 32 Yes 32 1 1 0x00000000 0 0 0 0 0 0 0 0 1 0 SYSCATSPACE 0x40924850 1 SMS SysTmp 4096 32 Yes 32 1 1 0x00000000 0 0 0 0 0 0 0 0 1 0 TEMPSPACE1


0x402A6FE0 2 SMS Any 4096 32 Yes 32 1 1 0x00000000 0 0 0 0 0 0 0 0 1 0 USERSPACE1 0x40972ED0 3 SMS Any 4096 32 Yes 32 1 1 0x00000000 0 0 0 0 0 0 0 0 1 0 SYSTOOLSPACE

Containers:Address TspId ContainNum Type TotalPages UseablePgs StripeSet Container 0x4037DDF0 0 0 Path 0 0 0 /home/jmcmahon/jmcmahon/NODE0000/SQL00001/SQLT0000.00x40924E50 1 0 Path 0 0 0 /home/jmcmahon/jmcmahon/NODE0000/SQL00001/SQLT0001.00x402A3E70 2 0 Path 0 0 0 /home/jmcmahon/jmcmahon/NODE0000/SQL00001/SQLT0002.00x409734D0 3 0 Path 0 0 0 /home/jmcmahon/jmcmahon/NODE0000/SQL00001/SYSTOOL

LogsTo monitor logs, you use the same process for DB2 and IDS. In both cases, you monitor log usage for long transactions. The goal is to avoid running out of log spaces. The db2pd -logs command is the equivalent to the onstat -l command. Startlsn indicates the starting log sequence number or transaction. This is used to determine the oldest transaction being held in the log, as shown in Example 14-21.

Example 14-21 db2pd -logs example

Informix Logs (onstat -l)

Physical LoggingBuffer bufused bufsize numpages numwrits pages/io P-1 0 1024 1377 816 1.69 phybegin physize phypos phyused %used 100107 2500 1381 0 0.00

Logical LoggingBuffer bufused bufsize numrecs numpages numwrits recs/pages pages/io L-1 0 1600 53453 4714 2994 11.3 1.6 Subsystem numrecs Log Space used OLDRSAM 53453 5433284

address number flags uniqid begin size used %used10570720 1 U---C-L 1 100acb 5000 4716 94.3210570758 2 A------ 0 101e53 5000 0 0.0010570790 3 A------ 0 1031db 5000 0 0.00105707c8 4 A------ 0 104563 5000 0 0.00


DB2 Logs (db2pd -db <database> -logs)

Logs:Current Log Number: 0 Pages Written: 35

Address StartLSN State Size Pages Filename0x4022806C 0x000000BB8000 0x00000000 1000 1000 S0000000.LOG0x402280FC 0x000000FA0000 0x00000000 1000 1000 S0000001.LOG0x4022818C 0x000001388000 0x00000000 1000 1000 S0000002.LOG

TransactionsUse the db2pd -transactions command to identify the longest transaction and to ensure that you will not run out of log space. This option is equivalent to the onstat -x command. The firstlsn is the log sequence number that identifies the oldest transaction. Use the db2pd -logs command to identify the log number attached to that transaction. Example 14-22 shows the output.

Example 14-22 Log output

Informix Transactions (onstat -x)Transactionsaddress flags userthread locks beginlg curlog logposit isol retrys coord10562018 A---- 10531018 0 0 1 0x126b018 COMMIT 0 105621e4 A---- 10531620 0 0 0 0x0 COMMIT 0 105623b0 A---- 10531c28 0 0 0 0x0 COMMIT 0 1056257c A---- 10532230 0 0 0 0x0 COMMIT 0 10562748 A---- 10532838 0 0 0 0x0 COMMIT 0 10562914 A-B-- 10532e40 5 1 1 0x1269154 COMMIT 0 10562ae0 A---- 10533a50 0 0 0 0x0 COMMIT 0 10562cac A---- 10533448 2 0 0 0x0 COMMIT 0 8 active, 128 total, 10 maximum concurrent

DB2 Transactions (db2pd -db <database> -transactions)

Transactions:Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2 Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID 0x4024D580 13 [000-00013] 2 38 WRITE 0x00000000 0x00000000 0x000000BB800C 0x000000BB8518 1606 2936 0x0000000000B1 1 0 0x4024E000 26 [000-00026] 3 5 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0 0 0x0000000000D0 1 0

Memory segments and setsUse the db2pd -memsets option to see how much memory is being used by the instance or database, or both, as shown in Example 14-23 on page 526. This is the equivalent to using the onstat -g seg to view IDS shared memory segments.


Alternatively, you can use the Memory Visualizer to graphically view memory in DB2. For more information, see 14.6.2, “Memory Visualizer” on page 505.

Example 14-23 db2pd -memsets example

Informix Memory Segments (onstat -g seg)Segment Summary:id key addr size ovhd class blkused blkfree 3072 1385187329 a000000 101711872 218400 R 24663 169 3073 1385187330 10100000 51380224 2168 V 4111 8433 3074 1385187331 13200000 2097152 664 M 261 251 Total: - - 155189248 - - 29035 8853

DB2 Memory Sets (db2pd [-db <database>] -memsets)

Memory Sets:Name Address Id Size Key DBP Type Ov OvSize DBMS 0x30000000 224526406 14204928 0x26061E61 0 0 Y 2473984 SAMPLE 0x40000000 479723597 46071808 0x0 0 1 Y 8945664 FMP 0xA0000000 766115873 245284864 0x0 0 2 N 0 App26 0xB0000000 131596303 131072 0x0 0 3 N 0 App13 0xB0000000 180748362 131072 0x0 0 3 N 0 Trace 0xC0000000 4063279 140665792 0x26061E74 0 -1 N 0

Memory poolsMemory pools in IDS and DB2 are similar. With the db2pd -mempools command, you can monitor memory pools in detail. Not only can you see the sizes, this command will also display the physical and logical high-water marks, enabling you to plan memory utilization more effectively. This is shown in Example 14-24. The IDS equivalent command is onstat -g mem.

Example 14-24 db2pd -mempools example

Informix Memory Pools (onstat -g mem)Pool Summary:name class addr totalsize freesize #allocfrag #freefrag afpool V 10109020 4096 2176 3 1 tpcpool V 10cb8020 61440 576 59 1 pnlpool V 10cbb020 77824 488 75 1 sbtlist V 10174020 12288 5600 4 3 dstpool V 10cb7020 4096 1512 2 1 ampool V 10ccd020 4096 688 32 1

DB2 Memory Pools (db2pd [-db <database] -mempools )


Memory Pools:Address MemSet PoolName Id Overhead LogSz LogUpBnd LogHWM PhySz PhyUpBnd PhyHWM Bnd BlkCnt CfgParm 0x300006D8 DBMS monh 11 24352 140884 368640 141108 180224 376832 180224 Ovf 13 MON_HEAP_SZ0x3000063C DBMS resynch 62 12992 101692 1622016 101692 131072 1622016 131072 Ovf 2 n/a 0x300005A0 DBMS apmh 70 0 28774 884736 29038 32768 884736 32768 Ovf 23 n/a 0x30000504 DBMS kerh 52 112 31368 311296 31660 49152 311296 49152 Ovf 11 n/a 0x30000468 DBMS bsuh 71 0 20661 7602176 32089 32768 7602176 49152 Ovf 62 n/a 0x300003CC DBMS sqlch 50 0 762446 786432 762446 786432 786432 786432 Ovf 163 n/a 0x30000330 DBMS pmth 80 0 180 108000 252 16384 114688 16384 Ovf 5 n/a 0x30000294 DBMS krcbh 69 0 18980 32768 18980 32768 32768 32768 Ovf 3 n/a 0x300001F8 DBMS eduah 72 0 64024 64048 64024 65536 65536 65536 Ovf 1 n/a 0x40000810 SAMPLE utilh 5 0 472 20496384 688 16384 20496384 16384 Ovf 3 UTIL_HEAP_SZ0x400006D8 SAMPLE pckcacheh 7 16480 588960 Unlimited 590009 638976 Unlimited 638976 Ovf 482 PCKCACHESZ0x4000063C SAMPLE catcacheh 8 0 121948 Unlimited 121948 131072 Unlimited 131072 Ovf 47 CATALOGCACHE_SZ0x400005A0 SAMPLE bph 16 11072 4268352 Unlimited 4268352 4292608 Unlimited 4292608 Ovf 2 n/a

Configuration parametersYou can view the configuration parameters for your instance and database by using the db2pd -dbmcfg and db2pd -dbcfg commands, as shown in Example 14-25. This is similar to the IDS onstat -c command.

Example 14-25 db2pd configuration example

Informix onconfig (onstat -c): onconfig parameters

# Root Dbspace ConfigurationNETTYPE ipcshm,1,100,CPU ROOTNAME rootdbs # Root dbspace nameROOTPATH /dev/rdsk/c0t3d0s6 # Path for device containing root dbspaceROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)ROOTSIZE 1000000 # Size of root dbspace (Kbytes)


DB2 dbm (db2pd -dbmcfg): database manager configuration parameters (disk and memory)

Database Manager Configuration Settings:Description Memory Value Disk Value RELEASE 0xa00 0xa00 CPUSPEED 4.000000e-05 4.000000e-05 COMM_BANDWIDTH 0.000000e+00 0.000000e+00 NUMDB 8 8 DATALINKS NO NO FEDERATED NO NO

DB2 db (db2pd -db <database> -dbcfg): database configuration parameters (disk and memory)

Database Configuration Settings:Description Memory Value Disk Value DB configuration release level 0xa00 0xa00 Database release level 0xa00 0xa00 Database territory US US Database code page 819 819 Database code set ISO8859-1 ISO8859-1 Database country/region code 1 1

For further details about the db2pd command, refer to IBM DB2 UDB Command Reference, SC09-4828.

14.6.9 Diagnostic filesDB2 uses two sets of diagnostic files, while IDS uses one, online.log. Prior to DB2 Version 8.1, there was one log, which was known as db2diag.log. The db2diag.log file has now been split into two separate logs: the administration notification log (admin.nfy) and the db2diag.log. This was done to separate administration and user information (the admin log) from internal support information (db2diag.log). The logs are both located in the directory specified by the DIAGPATH database manager configuration parameter. DIAGPATH is equivalent to the IDS MSGPATH in the onconfig file.

On Windows systems, the DB2 administration notification log is in the event log and can be reviewed through the Windows Event Viewer. The Journal, which is accessible either directly or from the Control Center, is used to view the notification log. You can use the Journal for either local or remote systems. For more information about the Journal, refer to 14.2.8, “Journal” on page 443. On UNIX and Linux systems, the admin.nfy and db2diag.log files are located, by default, in the INSTHOME/sqllib/db2dump directory, where INSTHOME is the home directory of the instance owner.


The information that DB2 records in the administration logs is determined by the DIAGLEVEL and NOTIFYLEVEL settings.

Valid values for DIAGLEVEL are:

� 0 – No diagnostic data captured

� 1 – Severe errors only

� 2 – All errors

� 3 – All errors and warnings

The administration logs grow continuously. When they get too large, back them up and then erase the file. A new set of files is generated automatically the next time they are required by the system.

Valid values for NOTIFYLEVEL are:

� 0 – No administration notification messages captured. (This setting is not recommended.)

� 1– Fatal or unrecoverable errors. Only fatal and unrecoverable errors are logged. To recover from some of these conditions, you might need assistance from DB2 service.

� 2 – Immediate action required. Conditions are logged that require immediate attention from the system administrator or the database administrator. If the condition is not resolved, it could lead to a fatal error. Notification of very significant, non-error activities (for example, recovery) might also be logged at this level. This level will capture health monitor alarms.

� 3 – Important information, no immediate action required. Conditions are logged that are non-threatening and do not require immediate action, but might indicate a non-optimal system. This level will capture health monitor alarms, health monitor warnings, and health monitor attentions.

� 4 – Informational messages.

If you have the health monitor enabled, you can trigger certain messages to kick off event warnings and alarms so that you will proactively be made aware of potential problems with your system. Otherwise, we suggest that you periodically monitor both files to ensure that any error messages are investigated.

Diagnostic log analysis tool for db2diag.logA new tool for filtering and formatting db2diag.log files (db2diag) is available in DB2 Version 8.2. You can use this tool to filter diagnostic log files, which use a new message format for V8.2. Among other options, you can indicate which fields to display, use a grep- like filter to reduce the number of records, and have the empty fields omitted.


Command line options include:

db2diag -help Provides a short description of the options.

db2diag -h brief Provides descriptions for all options without examples.

db2diag -h notes Provides usage notes and restrictions.

db2diag -h examples Provides a small set of examples to get started.

db2diag -h tutorial Provides examples for all available options.

db2diag -h all Provides the most complete list of options.

In Example 14-26, the command db2diag -gi "level=severe" -H 3d shows all severe errors from the past three days.

Example 14-26 Diagnostic log filter example

cindym:/home/cindym> db2diag -gi "level=severe" -H 3d2004-07-19-17.34.13.969732-360 I243548C411 LEVEL: SeverePID : 88158 TID : 1 PROC : db2agent (instance) 0INSTANCE: db2inst2 NODE : 000APPHDL : 0-290 APPID: G9012663.F206.013789233224FUNCTION: DB2 UDB, base sys utilities, sqleattach_agent, probe:60RETCODE : ZRC=0x81360012=-2127167470=SQLZ_RC_CMERR, SQLT_SQLJC "External Comm error"

14.6.10 Error message and command helpUse of the ? (question mark) symbol within a DB2 command will provide online syntax examples, as shown in Example 14-27.

Example 14-27 DB2 command line help

cindym:/home/cindym> db2 ? create database

CREATE DATABASE database-name[AT DBPARTITIONNUM | [ON path] [ALIAS database-alias][USING CODESET codeset TERRITORY territory][COLLATE USING {SYSTEM | IDENTITY | IDENTITY_16BIT | COMPATIBILITY | NLSCHAR}][NUMSEGS numsegs] [DFT_EXTENT_SZ dft_extentsize][CATALOG TABLESPACE tblspace-defn] [USER TABLESPACE tblspace-defn][TEMPORARY TABLESPACE tblspace-defn] [WITH "comment-string"]][AUTOCONFIGURE [USING config-keyword value [{,config-keyword value}...]][APPLY {DB ONLY | DB AND DBM | NONE}]]tblspace-defn: MANAGED BY { SYSTEM USING ('string' [ {,'string'} ... ] ) | DATABASE USING ({FILE | DEVICE} 'string' number-of-pages [ {,{FILE | DEVICE} 'string' number-of-pages} ... ] ) } [EXTENTSIZE number-of-pages] [PREFETCHSIZE number-of-pages]


[OVERHEAD number-of-milliseconds] [TRANSFERRATE number-of-milliseconds] [NO FILE SYSTEM CACHING | FILE SYSTEM CACHING]

config-keyword: MEM_PERCENT, WORKLOAD_TYPE, NUM_STMTS, TPM, ADMIN_PRIORITY NUM_LOCAL_APPS, NUM_REMOTE_APPS, ISOLATION, BP_RESIZEABLE.

Similarly, you can obtain error message text by using the ? symbol with the error number, similar to using the IDS command finderr nnnn. In Example 14-28, we use ? to investigate an SQL error message from a SELECT statement.

Example 14-28 Error message help

cindym:/home/cindym> db2 connect to mickyd Database Connection Information

Database server = DB2/6000 8.2.0 SQL authorization ID = CINDYM Local database alias = MICKY

cindym:/home/cindym> db2 select coltwo from harrySQL0206N "COLTWO" is not valid in the context where it is used.SQLSTATE=42703cindym:/home/cindym> db2 ? sql0206

SQL0206N "<name>" is not valid in the context where it is used.Explanation:This error can occur in the following cases:

o For an INSERT or UPDATE statement, the specified column is not a column of the table, or view that was specified as the object of the insert or update.

o For a SELECT or DELETE statement, the specified column is not a column of any of the tables or views identified in a FROM clause in the statement.........

The statement cannot be processed.

User Response:

Verify that the names are specified correctly in the SQLstatement. For a SELECT statement, ensure that all the requiredtables are named in the FROM clause. For a subselect in an ORDERBY clause, ensure that there are no correlated column references.


If a correlation name is used for a table, verify that subsequentreferences use the correlation name and not the table name.

For a CREATE TRIGGER statement, ensure that only new transitionvariables are specified on the left hand side of assignments inthe SET transition-variable statement and that any reference tocolumns of the subject table have a correlation name specified.

sqlcode : -206

sqlstate : 42703


Appendix A. Configuration variables and parameters

In this appendix, we describe a number of system parameters that will be of value as you prepare for and execute your transition processes. This appendix includes:

� Table of general registry variables

� Table of system environment variables

� Example of DB2 database manager configuration parameters

A


General registry variablesTable A-1 provides a list of the general registry variables, their values, and a description of each.

Table A-1 General registry variables

Variable name Operating system

Values Description

DB2ACCOUNT All Default: null The accounting string that is sent to the remote host. Refer to the IBM DB2 Connect User's Guide, SC09-4835, for details.

DB2BIDI All Default: NO Values: YES or NO

This variable enables bidirectional support, and the DB2CODEPAGE variable is used to declare the code page to be used. Refer to the AIX 5L Version 5.3 National Language Support Guide and Reference, SC23-4902, for additional information about bidirectional support.

DB2CODEPAGE All Default: Derived from the language ID, as specified by the operating system

Specifies the code page of the data presented to DB2 for database client application.

DB2DBDFT All Default: null Specifies the database alias name of the database to be used for implicit connects. If an application has no database connection, but SQL statements are issued, an implicit connect will be made if the DB2DBDFT environment variable has been defined with a default database.

DB2DBMSADDR Windows 32-bit operating systems

Default: 0x20000000 for Windows NT Value: 0x20000000 to 0xB0000000 in increments of 0x10000

Specifies the default database manager shared memory address in hexadecimal format. If db2start fails due to a shared memory address collision, this registry variable can be modified to force the database manager instance to allocate its shared memory at a different address.

DB2_DISABLE_FLUSH_LOG

All Default: OFF Value: ON or OFF

Specifies whether to disable closing the active log file when the online backup completes.


DB2DISCOVERYTIME

Windows Default: 40 secondsMinimum: 20 seconds

Specifies the amount of time that SEARCH Discovery will search for DB2 systems.

DB2GRAPHICUNICODESERVER

All Default: OFF Values: ON or OFF

This registry variable is used to accommodate existing applications written to insert graphic data into a Unicode database. Its use is only needed for applications that specifically send sqldbchar (graphic) data in Unicode instead of the code page of the client. (sqldbchar is a supported SQL data type in C and C++ that can hold a single double-byte character.) When set to “ON”, you are telling the database that graphic data is coming in Unicode, and the application expects to receive graphic data in Unicode.

DB2INCLUDE All Default: current directory

Specifies a path to be used during the processing of the SQL INCLUDE text-file statement during DB2 PREP processing. It provides a list of directories where the INCLUDE file might be found. Refer to the IBM DB2 UDB Application Development Guide: Programming Client Applications, SC09-4826, for descriptions of how DB2INCLUDE is used in the different precompiled languages.


Values Description

Appendix A. Configuration variables and parameters 535

DB2_INDEX_TYPE2 All Default: ON Values: ON or OFF

This registry variable controls the type of indexes created on user tables. If it is not set, or set to ON, user indexes will be created as type 2. If it is set to OFF, user indexes will be created as type 1. (Note that this variable only affects index creations on tables that do not already have indexes. An index created on a table that already has indexes will have the same type as the existing indexes.) Type 2 indexes are new in Version 8 and have significant functional and concurrency advantages over type 1 indexes. The registry variable will be removed, and all indexes will be created as type 2 in a future release.

DB2INSTDEF Windows operating systems

Default: DB2 Sets the value to be used if DB2INSTANCE is not defined.

DB2INSTOWNER Windows NT

Default: null The registry variable created in the DB2 profile registry when the instance is first created. This variable is set to the name of the instance-owning machine.

DB2_LIC_STAT_SIZE All Default: null Range: 0 to 32 767

The registry variable determines the maximum size (in MBs) of the file containing the license statistics for the system. A value of zero turns the license statistic gathering off. If the variable is not recognized or not defined, the variable defaults to unlimited. The statistics are displayed using the License Center.

DB2LOCALE All Default: NO Values: YES or NO

Specifies whether the default “C” locale of a process is restored to the default “C” locale after calling DB2 and whether to restore the process locale back to the original “C” after calling a DB2 function. If the original locale was not “C”, this registry variable is ignored.


Values Description


DB2NBDISCOVERRCVBUFS

All Default: 16 buffersMinimum: 16 buffers

This variable is used for NetBIOS search discovery. The variable specifies the number of concurrent discovery responses that can be received by a client. If the client receives more concurrent responses than are specified by this variable, the excess responses are discarded by the NetBIOS layer. The default is 16 NetBIOS receive buffers. If a number less than the default value is chosen, the default is used.

DB2OPTIONS All except Windows 3.1 and Macintosh

Default: null Sets command line processor options.

DB2SLOGON Windows 3.x

Default: nullValues: YES or NO

Enables a secure logon in DB2 for Windows 3.x. If DB2SLOGON=YES, DB2 does not write user IDs and passwords to a file, but instead uses a segment of memory to maintain them. When DB2SLOGON is enabled, the user must log on each time Windows 3.x is started.

DB2TERRITORY All Default: Derived from the language ID, as specified by the operating system.

Specifies the region or territory code of the client application, which influences date and time formats.

DB2TIMEOUT Windows 3.x and Macintosh

Default: (not set) Used to control the timeout period for Windows 3.x and Macintosh clients during long SQL queries. After the timeout period has expired, a dialog box opens asking if the query should be interrupted or allowed to continue. The minimum value for this variable is 30 seconds. If DB2TIMEOUT is set to a value between 1 and 30, the default minimum value will be used. If DB2TIMEOUT is set to a value of 0, or a negative value, the timeout feature is disabled. This feature is disabled by default.


Values Description


DB2TRACENAME Windows 3.x and Macintosh

Default: DB2WIN.TRC (on Windows 3.x), DB2MAC.TRC (on Macintosh)

On Windows 3.x and Macintosh, specifies the name of the file where trace information is stored. The default for each system is saved in your current instance directory (for example, \sqllib\db2). It is strongly recommended that you specify the full path name when naming the trace file.

DB2TRACEON Windows 3.x and Macintosh

Default: NO Values: YES or NO

On Windows 3.x and Macintosh, turns trace on to provide information to IBM in case of a problem. (We do not recommend that you turn trace on unless you encounter a problem you cannot resolve.) Troubleshooting information includes information about using the trace facility with clients.

DB2TRCFLUSH Windows 3.x and Macintosh


On Windows 3.x and Macintosh, DB2TRACEFLUSH can be used in conjunction with DB2TRACEON=YES. Setting DB2TRACEFLUSH=YES will cause each trace record to be written immediately into the trace file. This will slow down your DB2 system considerably, so the default setting is DB2TRACEFLUSH=NO. This setting is useful in cases where an application hangs the system and requires the system to be rebooted. Setting this keyword guarantees that the trace file and trace entries are not lost by the reboot.

DB2TRCSYSERR Windows 3.x and Macintosh

Default: 1 Values: 1-32 767

Specifies the number of system errors to trace before the client turns off tracing. The default value traces one system error, after which, trace is turned off.


Values Description


System environment variablesTable A-2 contains a list of system environment variables, their values, and a description.

Table A-2 System environment variables

DB2YIELD Windows 3.x


Specifies the behavior of the Windows 3.x client while communicating with a remote server. When set to NO, the client will not yield the CPU to other Windows 3.x applications, and the Windows environment is halted while the client application is communicating with the remote server. You must wait for the communications operation to complete before you can resume any other tasks. When set to YES, your system functions as normal. We recommend that you try to run your application with DB2YIELD=YES. If your system crashes, you will need to set DB2YIELD=NO. For application development, ensure that your application is written to accept and handle Windows messages while waiting for a communications operation to complete.


Values Description


Values Description

DB2CONNECT_IN_APP_PROCESS

All Default: YES Values: YES or NO

When you set this variable to NO, local DB2 Connect clients on a DB2 Connect Enterprise Edition machine are forced to run within an agent. Some advantages of running within an agent are that local clients can be monitored and that they can use SYSPLEX support.


DB2DOMAINLIST Windows NT server only

Default: null Values: A list of Windows NT domain names separated by commas (“,”)

Defines one or more Windows NT domains. Only users belonging to these domains will have their connection or attachment requests accepted. This registry variable should only be used under a pure Windows NT domain environment with DB2 servers and clients running DB2 Universal Database Version 7.1 (or later).

DB2ENVLIST UNIX Default: null Lists specific variable names for either stored procedures or user-defined functions. By default, the db2start command filters out all user environment variables except those prefixed with DB2 or db2. If specific environment variables must be passed to either stored procedures or user-defined functions, you can list the variable names in the DB2ENVLIST environment variable. Separate each variable name by one or more spaces.

DB2INSTANCE All Default: DB2INSTDEF on Windows 32-bit operating systems

The environment variable used to specify the instance that is active by default. On UNIX, users must specify a value for DB2INSTANCE.

DB2INSTPROF Windows operating systems

Default: null The environment variable used to specify the location of the instance directory on Windows operating systems, if different than DB2PATH.

DB2LIBPATH UNIX Default: null DB2 constructs its own shared library path. If you want to add a PATH into the engine's library path (for example, on AIX, a user-defined function requires a specific entry in LIBPATH), you must set DB2LIBPATH. The actual value of DB2LIBPATH is appended to the end of the DB2-constructed shared library path.


Values Description


DB2NODE All Default: null Values: 1 to 999

Used to specify the target logical node of a DB2 Enterprise Server Edition database partition server that you want to attach to or connect to. If this variable is not set, the target logical node defaults to the logical node that is defined with port 0 on the machine.

DB2_PARALLEL_IO All Default: null Values: * (meaning every table space) or a comma-separated list of more than one defined table space

While reading or writing data from and to table space containers, DB2 might use parallel I/O for each table space value that you specify. The degree of parallelism is determined by the prefetch size and extent size for the containers in the table space. For example, if the prefetch size is four times the extent size, there are four extent-sized prefetch requests. The number of containers in the table space does not affect the number of prefetchers. To enable parallel I/O for all table spaces, use the wildcard character “*”. To enable parallel I/O for a subset of all table spaces, enter the list of table spaces. If there is more than one container, extent-size pieces of any full prefetch request are broken down into smaller requests executed in parallel based on the number of prefetchers. When this variable is not enabled, the number of prefetcher requests created is based on the number of containers in the table space.

DB2PATH Windows operating systems

Default: Varies by operating system

The environment variable used to specify the directory where the product is installed on Windows 32-bit operating systems.


Values Description


DB2PROCESSORS Windows operating systems

Default: null Values: 0-n-1 (where n = the number of processors)

Sets the process affinity mask for a particular db2syscs process. In environments running multiple logical nodes, this variable is used to associate a logical node to a processor or set of processors.When specified, DB2 issues the SetProcessAffinityMask() API. If unspecified, the db2syscs process is associated with all processors on the machine.

DB2_USE_PAGE_CONTAINER_TAG

All Default: null Values: ON, null

By default, DB2 stores a container tag in the first extent of each DMS container, whether it is a file or a device. The container tag is the metadata for the container. Before DB2 Version 8.1, the container tag was stored in a single page, and it thus required less space in the container. To continue to store the container tag in a single page, set DB2_USE_PAGE_CONTAINER_TAG to ON. However, if you set this registry variable to ON when you use RAID devices for containers, I/O performance might degrade. Because for RAID devices you create table spaces with an extent size equal to or a multiple of the RAID stripe size, setting the DB2_USE_PAGE_CONTAINER_TAG to ON causes the extents not to line up with the RAID stripes. As a result, an I/O request might need to access more physical disks than would be optimal. Users are strongly advised against enabling this registry variable.To activate changes to this registry variable, issue a DB2STOP command and then enter a DB2START command.


Values Description


Database manager configuration fileThis section provides information regarding database manager configuration parameters. The following examples are commands for accessing the configuration information.

db2 get database manager configuration

Or:db2 get dbm cfg

DB2_CLPHISTSIZE All Default: 20 Note: This registry variable is not set to the default value during installation. Instead, the code that makes use of this variable uses a default value of 20 if the registry variable is not set or if it is set to a value outside of the valid range. Values: 1-500 inclusive

This variable determines the number of commands stored in the command history during CLP interactive sessions. Because the command history is held in memory, a very high value for this variable might result in a performance impact depending on the number and length of commands run in a session.

DB2_CLP_EDITOR All Default: Windows platforms: NotepadUNIX: viNote: This registry variable is not set to the default value during installation. Instead, the code that makes use of this variable uses a default value if the registry variable is not set. Values: Any valid editor that is located in the operating system path

This variable determines the editor to be used when executing the EDIT command. From a CLP interactive session, the EDIT command launches an editor pre-loaded with a user-specified command that can then be edited and run.


Values Description


Example A-1 shows the configuration parameter information obtained from these types of commands.

Example: A-1 Database manager configuration parameters

Database Manager Configuration

Node type = Enterprise Server Edition with local and remote clients

Database manager configuration release level = 0x0a00CPU speed (millisec/instruction) (CPUSPEED) = 5.943666e-07 Communications bandwidth (MB/sec) (COMM_BANDWIDTH) = 1.000000e+02Max number of concurrently active databases (NUMDB) = 8 Data Links support (DATALINKS) = NO Federated Database System Support (FEDERATED) = YES Transaction processor monitor name (TP_MON_NAME) =

Default charge-back account (DFT_ACCOUNT_STR) =

Java Development Kit installation path (JDK_PATH) = /usr/java131

Diagnostic error capture level (DIAGLEVEL) = 3 Notify Level (NOTIFYLEVEL) = 3 Diagnostic data directory path (DIAGPATH) = /home/db2inst2/sqllib/db2dump

Default database monitor switches Buffer pool (DFT_MON_BUFPOOL) = ON Lock (DFT_MON_LOCK) = OFF Sort (DFT_MON_SORT) = OFF Statement (DFT_MON_STMT) = OFF Table (DFT_MON_TABLE) = OFF Timestamp (DFT_MON_TIMESTAMP) = ON Unit of work (DFT_MON_UOW) = OFF Monitor health of instance and databases (HEALTH_MON) = ON

SYSADM group name (SYSADM_GROUP) = DB2GRP1 SYSCTRL group name (SYSCTRL_GROUP) = DB2DBCRT SYSMAINT group name (SYSMAINT_GROUP) = SYSMON group name (SYSMON_GROUP) =

Client Userid-Password Plugin (CLNT_PW_PLUGIN) = Client Kerberos Plugin (CLNT_KRB_PLUGIN) = Group Plugin (GROUP_PLUGIN) = GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) = Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) = Server Userid-Password Plugin (SRVCON_PW_PLUGIN) = Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED


Database manager authentication (AUTHENTICATION) = SERVER

Cataloging allowed without authority (CATALOG_NOAUTH) = NO Trust all clients (TRUST_ALLCLNTS) = YES Trusted client authentication (TRUST_CLNTAUTH) = CLIENT Bypass federated authentication (FED_NOAUTH) = NO

Default database path (DFTDBPATH) = /home/db2inst2

Database monitor heap size (4KB) (MON_HEAP_SZ) = 90 Java Virtual Machine heap size (4KB) (JAVA_HEAP_SZ) = 2048 Audit buffer size (4KB) (AUDIT_BUF_SZ) = 0 Size of instance shared memory (4KB) (INSTANCE_MEMORY) = AUTOMATIC Backup buffer default size (4KB) (BACKBUFSZ) = 1024 Restore buffer default size (4KB) (RESTBUFSZ) = 1024

Sort heap threshold (4KB) (SHEAPTHRES) = 18186

Directory cache support (DIR_CACHE) = YES

Application support layer heap size (4KB) (ASLHEAPSZ) = 15 Max requester I/O block size (bytes) (RQRIOBLK) = 32767 Query heap size (4KB) (QUERY_HEAP_SZ) = 2048

Workload impact by throttled utilities(UTIL_IMPACT_LIM) = 5

Priority of agents (AGENTPRI) = SYSTEM Max number of existing agents (MAXAGENTS) = 400 Agent pool size (NUM_POOLAGENTS) = 400 Initial number of agents in pool (NUM_INITAGENTS) = 10 Max number of coordinating agents (MAX_COORDAGENTS) = 400 Max no. of concurrent coordinating agents (MAXCAGENTS) = MAX_COORDAGENTS Max number of client connections (MAX_CONNECTIONS) = MAX_COORDAGENTS

Keep fenced process (KEEPFENCED) = NO Number of pooled fenced processes (FENCED_POOL) = MAX_COORDAGENTS Initial number of fenced processes (NUM_INITFENCED) = 0

Index re-creation time and redo index build (INDEXREC) = RESTART

Transaction manager database name (TM_DATABASE) = 1ST_CONN Transaction resync interval (sec) (RESYNC_INTERVAL) = 180

SPM name (SPM_NAME) = greenla1 SPM log size (SPM_LOG_FILE_SZ) = 256 SPM resync agent limit (SPM_MAX_RESYNC) = 20 SPM log path (SPM_LOG_PATH) =


TCP/IP Service name (SVCENAME) = db2c_db2inst2 Discovery mode (DISCOVER) = SEARCH Discover server instance (DISCOVER_INST) = ENABLE

Maximum query degree of parallelism (MAX_QUERYDEGREE) = 1 Enable intra-partition parallelism (INTRA_PARALLEL) = NO

No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = 4096 Number of FCM request blocks (FCM_NUM_RQB) = AUTOMATIC Number of FCM connection entries (FCM_NUM_CONNECT) = AUTOMATIC Number of FCM message anchors (FCM_NUM_ANCHORS) = AUTOMATIC

Node connection elapse time (sec) (CONN_ELAPSE) = 10 Max number of node connection retries (MAX_CONNRETRIES) = 5 Max time difference between nodes (min) (MAX_TIME_DIFF) = 60

db2start/db2stop timeout (min) (START_STOP_TIME) = 10

The database configuration fileThe commands for database configuration parameters are:

GET DATABASE CONFIGURATION (or GET DB CFG) [ FOR database_name ]

For example:

DB2 GET DB CFG FOR ifmx2db2

Example A-2 shows the configuration parameter information obtained from these types of commands.

Example: A-2 Database configuration for ifmx2db2 database

Database Configuration for Database ifmx2db2

Database configuration release level = 0x0a00 Database release level = 0x0a00

Database territory = US Database code page = 1252 Database code set = IBM-1252 Database country/region code = 1 Database collating sequence = UNIQUE Alternate collating sequence (ALT_COLLATE) =

Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE

Discovery support for this database (DISCOVER_DB) = ENABLE


Default query optimization class (DFT_QUERYOPT) = 9 Degree of parallelism (DFT_DEGREE) = 1 Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO Default refresh age (DFT_REFRESH_AGE) = 0 Default maintained table types for opt (DFT_MTTB_TYPES) = SYSTEM Number of frequent values retained (NUM_FREQVALUES) = 10 Number of quantiles retained (NUM_QUANTILES) = 20

Backup pending = NO

Database is consistent = YES Rollforward pending = NO Restore pending = NO

Multi-page file allocation enabled = YES

Log retain for recovery status = NO User exit for logging status = NO

Data Links Token Expiry Interval (sec) (DL_EXPINT) = 60 Data Links Write Token Init Expiry Intvl(DL_WT_IEXPINT) = 60 Data Links Number of Copies (DL_NUM_COPIES) = 1 Data Links Time after Drop (days) (DL_TIME_DROP) = 1 Data Links Token in Uppercase (DL_UPPER) = NO Data Links Token Algorithm (DL_TOKEN) = MAC0

Database heap (4KB) (DBHEAP) = 1200 Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC Catalog cache size (4KB) (CATALOGCACHE_SZ) = 260 Log buffer size (4KB) (LOGBUFSZ) = 132 Utilities heap size (4KB) (UTIL_HEAP_SZ) = 55192 Buffer pool size (pages) (BUFFPAGE) = 1000 Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000 Number of extended storage segments (NUM_ESTORE_SEGS) = 0 Max storage for lock list (4KB) (LOCKLIST) = 100

Max size of appl. group mem set (4KB) (APPGROUP_MEM_SZ) = 12187 Percent of mem for appl. group heap (GROUPHEAP_RATIO) = 70 Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128

Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = (SHEAPTHRES) Sort list heap (4KB) (SORTHEAP) = 909 SQL statement heap (4KB) (STMTHEAP) = 2048 Default application heap (4KB) (APPLHEAPSZ) = 2048 Package cache size (4KB) (PCKCACHESZ) = 859 Statistics heap size (4KB) (STAT_HEAP_SZ) = 4384

Interval for checking deadlock (ms) (DLCHKTIME) = 10000


Percent. of lock lists per application (MAXLOCKS) = 60 Lock timeout (sec) (LOCKTIMEOUT) = -1

Changed pages threshold (CHNGPGS_THRESH) = 60 Number of asynchronous page cleaners (NUM_IOCLEANERS) = 1 Number of I/O servers (NUM_IOSERVERS) = 5 Index sort flag (INDEXSORT) = YES Sequential detect flag (SEQDETECT) = YES Default prefetch size (pages) (DFT_PREFETCH_SZ) = 32

Track modified pages (TRACKMOD) = OFF

Default number of containers = 1 Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32

Max number of active applications (MAXAPPLS) = 40 Average number of active applications (AVG_APPLS) = 1 Max DB files open per application (MAXFILOP) = 64

Log file size (4KB) (LOGFILSIZ) = 1024 Number of primary log files (LOGPRIMARY) = 3 Number of secondary log files (LOGSECOND) = 0 Changed path to log files (NEWLOGPATH) = Path to log files = /usr/db2/ifmx2db2/db2inst2/NODE0000/SQL00001/SQLOGDIR/

Overflow log path (OVERFLOWLOGPATH) = Mirror log path (MIRRORLOGPATH) = First active log file = Block log on disk full (BLK_LOG_DSK_FUL) = NO Percent of max active log space by transaction(MAX_LOG) = 0 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0

Group commit count (MINCOMMIT) = 1 Percent log file reclaimed before soft chckpt (SOFTMAX) = 120 Log retain for recovery enabled (LOGRETAIN) = OFF User exit for logging enabled (USEREXIT) = OFF

HADR database role = STANDARD HADR local host name (HADR_LOCAL_HOST) = HADR local service name (HADR_LOCAL_SVC) = HADR remote host name (HADR_REMOTE_HOST) = HADR remote service name (HADR_REMOTE_SVC) = HADR instance name of remote server (HADR_REMOTE_INST) = HADR timeout value (HADR_TIMEOUT) = 120 HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC

First log archive method (LOGARCHMETH1) = OFF Options for logarchmeth1 (LOGARCHOPT1) = Second log archive method (LOGARCHMETH2) = OFF


Options for logarchmeth2 (LOGARCHOPT2) = Failover log archive path (FAILARCHPATH) = Number of log archive retries on error (NUMARCHRETRY) = 5 Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20 Vendor options (VENDOROPT) =

Auto restart enabled (AUTORESTART) = ON Index re-creation time and redo index build (INDEXREC) = SYSTEM (RESTART) Log pages during index build (LOGINDEXBUILD) = OFF Default number of loadrec sessions (DFT_LOADREC_SES) = 1 Number of database backups to retain (NUM_DB_BACKUPS) = 12 Recovery history retention (days) (REC_HIS_RETENTN) = 366

TSM management class (TSM_MGMTCLASS) = TSM node name (TSM_NODENAME) = TSM owner (TSM_OWNER) = TSM password (TSM_PASSWORD) =

Automatic maintenance (AUTO_MAINT) = OFF Automatic database backup (AUTO_DB_BACKUP) = OFF Automatic table maintenance (AUTO_TBL_MAINT) = OFF Automatic runstats (AUTO_RUNSTATS) = OFF Automatic statistics profiling (AUTO_STATS_PROF) = OFF

Automatic profile updates (AUTO_PROF_UPD) = OFF

Automatic reorganization (AUTO_REORG) = OFF


Appendix B. Informix source and object definitions

This appendix provides a summary of the Informix source and object definitions used in the MTK tutorial in Chapter 8, “An MTK tutorial” on page 241. These will help you understand the MTK tutorial and enable you to duplicate it in your own environment.

The following list shows the files used in the MTK tutorial. These files are documented here for those who want to implement the data used in the tutorial. You can download the file data used in the tutorial from the Redbooks Web site. These listed files contain information to aid in your understanding of the MTK tutorial.

The following two files are the DDL, both the source and target:

� table.src: This file is the DDL for both the source and target. It has the IDS stores_demo tables and index DDL. It is on the download site for those users who do not have access to a stores_demo database and includes the itemslog table that was added to support the trigger.

� tables.db2: This file has the DB2 tables and index DDL MTK translations of the source IDS stores_demo database. It includes the itemslog table that was added to the stores_demo database.

B


The following files are routines and a trigger that were added to the stores_demo database for the purpose of the tutorial, because the stores_demo database is not delivered with any SPL routines or triggers:

� stockdel.sql: IDS SPL routine to delete stock entries

� get_order: IDS SPL routine to get an order

� upd_items-p2: IDS SPL routine to update items

� trigger.sql: IDS trigger

The itemslog.sql file supports the trigger that was added. This is the additional table added to the IDS stores_demo database to support the trigger. It is for users who already have a stores_demo database, but need to supplement to match the database in the tutorial (the trigger used in the database requires having this table created).

The following files are the MTK translation (for DB2) with manual additions to complete the translation:

� nsokolof_get_order.db2: MTK translation of the IDS SPL routine for DB2

� nsokolof_stockdel.db2: MTK translation of the IDS SPL routine for DB2

� nsokolof_upd_items-p2.db2: MTK translation of the IDS SPL routine for DB2

� nsokolof_trigger.sql: MTK translation of the IDS SPL routine for DB2


Appendix C. Additional resources

A typical transition or migration project encompasses many phases, from planning to tuning. As you move through each phase, you probably will have questions and require additional information. In Chapter 7, “DB2 Migration Toolkit for Informix” on page 213 and Chapter 8, “An MTK tutorial” on page 241, we discuss and demonstrate how the DB2 Migration Toolkit (MTK) is used to facilitate the implementation phase.

In this appendix, we present additional IBM resources that can be of help to you throughout your transition project.

C


Pre-transition planning and estimating The IBM Software Migration Project Office (SMPO) can provide guidance and assistance for planning your transition. The SMPO can offer assistance throughout the process, with particular emphasis placed on:

� Estimates for the transition effort in hours

� Database differences training for DBAs and application developers

� Sample SQL conversions, including stored procedures and triggers

� MTK demonstrations and training

� Tools and consulting services recommendations

� Facilitating solutions related to transition issues

SMPO assistance is available free of charge. You can contact the SMPO through your local IBM Sales Representative or visit their Web page at:

http://www.ibm.com/software/solutions/softwaremigration

General transition questionsIn addition to the SMPO, another way to contact IBM regarding transition questions, assistance, or services, during any phase of the process, is by sending an e-mail to:

� For the Americas:

mailto:[email protected]

� For Europe, Middle East, Africa:


� For Asia and Pacific:


Your questions are routed to the appropriate team and answered by e-mail.

Transition consulting servicesFee-based IBM consulting services for your transition project can be obtained from the Lab Services Migration Center.

The Lab Services Migration Center is a worldwide team of transition specialists, database specialists, architects, and project managers. The Lab Services


http://www.ibm.com/software/solutions/softwaremigration




Migration team can be engaged to perform your entire transition, provide consultants to supplement your internal transition team, or be contracted for consulting advice. You can learn more about the Lab Services Migration Center by contacting your local IBM Sales Representation or by sending a note to the appropriate e-mail address, as described in “General transition questions” on page 554.

DB2 UDB training and educationProviding the right training for your DBAs, application developers, and end users, is an important part of your transition plan. A special course has been designed for customers who currently have in-house relational database expertise, but require additional skills in DB2. This course is “Fast Path to DB2 UDB for Experienced Relational DBAs,” Course Code CF281.

For details about this course, and other training information, visit the IBM Learning Services Web page:


There are also a series of complementary self-study courses and tutorials about DB2 that you can download from:

http://www.ibm.com/software/data/education/selfstudy.html

DB2 UDB product certificationIBM Professional Certification is a way for skilled IT professionals to demonstrate their expertise to the world. It validates your skills and demonstrates your proficiency in the latest IBM technology and solutions. The mission of IBM Professional Certification is to:

� Provide a reliable, valid, and fair method of assessing skills and knowledge.

� Provide IBM with a method of building and validating the skills of individuals and organizations.

� Develop a loyal community of highly skilled certified professionals who recommend, sell, service, support, and/or use IBM products and solutions.

Several certification programs are available for DB2. For more information, see:

http://www.ibm.com/certify/certs/dm_index.shtml

Appendix C. Additional resources 555




Useful Web sites The following Web sites can provide you with assistance.

� DB2 Migrate Now!

If you are interested in transitioning from Oracle, Sybase, and SQL Server, visit the DB2 Migrate Now! Web site. This site offers porting guides and other general information related to transitioning.

http://www.ibm.com/software/data/db2/migration/

� DB2 UDB developerWorks

To learn more about DB2 application development and view coding examples, visit the DB2 UDB Version 8 developerWorks Web page at:


On developerWorks, you can search and find articles about porting, tuning, and specific programming techniques. For example:

– For tuning information, go to:

http://www.ibm.com/developerworks/db2/zones/porting/tuning.html

– For Java programming information, go to:

http://www.ibm.com/developerworks/java/

� Perl DBI

DBI is an open standard API that provides database access for client applications written in Perl. The latest DB2 UDB Perl driver and information about Perl is at the DB2 UDB Perl DBI support Web page:

http://www.ibm.com/software/data/db2/perl/

� Getting started with DB2

http://www.ibm.com/developerworks/db2/newto/

� DB2 UDB documentation on the Web

There are a number of documentation manuals available, including:

– DB2 Version 8 documentation is available at:

http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8pubs.d2w/en_main

– DB2 Information Center is an online searchable tool for viewing documentation. You can access at this Web site at:

http://publib.boulder.ibm.com/infocenter/db2v8luw/index.jsp



http://www.ibm.com/developerworks/db2/zones/porting/tuning.html

http://www.ibm.com/developerworks/java/



http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8pubs.d2w/en_main

http://publib.boulder.ibm.com/infocenter/db2v8luw/index.jsp


� DB2 Support

The DB2 Technical Support Web site is available at:

http://www.ibm.com/software/data/support/

At this site, you can search for information in order to solve a problem, download software, or learn about a topic.

Support can be accessed both online and by telephone, at 1-800-IBM-SERV (1-800-426-3738).

Table C-1 summarizes the support that is available to you.

Table C-1 Support summary

Type Description URL

IBM Product Support Web site

Basic search capability for closed APARs and software fixes. Information about how to purchase software maintenance and premium support. Marketing information, such as product overviews, newsletters, Redbooks, white papers, and announcement letters.Links to education and training information.Links to the IBM Software Support Guide.

http://www.ibm.com/software/support

IBM Registered User Support Site

Submit, view, and update customer problem records. View entitlement information and recent problem activity.Technical news containing proactive technical content.Access to knowledge base of FAQs, known problems, and so on.Download fix packs, drivers, code corrections, and so on. e-Customer Care 1-800-978-2246.Comprehensive advanced search capabilities.Ability to create a “My support” page, enabling users to view only information previously selected (see the link on the upper-right side of the page).


Appendix C. Additional resources 557






IBM RedbooksIf you are also considering a transition from Oracle to DB2, a good source of information is Oracle to DB2 UDB Conversion Guide, SG24-7048.

This IBM Redbook also discusses and demonstrates the MTK (for Oracle). This Redbook, and many others, can be ordered and downloaded from:

http://www.ibm.com/redbooks

IBM Press Books For a comprehensive discussion of the DB2 SQL procedure language and a variety of SQL PL coding examples, a good reference source is DB2 SQL Procedural Language for Linux, UNIX, and Windows by Paul Yip et al., ISBN 0131007726.

In addition, other books about DB2 UDB are available. A good list is available at the following Web site:

http://www.ibm.com/software/data/education/bookstore/learning.html

IBM Software Support Guide

Provides detailed information about all IBM software support, including:� STC's role and process to set up

authorized callers.� Authorized caller registration

process for electronic support.� Severity level examples.� Support delivery process.� What to do prior to calling.� How to invoke support.� How to escalate a problem.� How to purchase software

maintenance.� Worldwide list of support center

phone numbers.

http://techsupport.services.ibm.com/guides/handbook.html

IBM PMR System Quick reference for reporting PMRs, the equivalent to an Informix case number.

http://www-3.ibm.com/software/support/probsub.html

Authorized Program Analysis Report (APAR) Search

Knowledge base for APARS (product defects).

http://www-1.ibm.com/support/apar_search.html

Type Description URL









http://www.ibm.com/redbooks

Appendix D. Additional material

This redbook refers to additional material that can be downloaded from the Internet as described here.

Locating the Web materialThe Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:

ftp://www.redbooks.ibm.com/redbooks/SG246367

Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks

Select the Additional materials and open the directory that corresponds with the redbook form number, SG246367.

Using the Web materialThe additional Web material that accompanies this redbook includes the following file:

File name DescriptionMTK-Scripts.zip Zipped scripts for the example MTK tutorial

D


ftp://www.redbooks.ibm.com/redbooks/SG246367



System requirements for downloading the Web materialThe following system configuration is recommended:

Hard disk space: 10 MB minimumOperating system: Windows/LinuxProcessor: AT/AT® compatibleMemory: 500 MB

How to use the Web materialThese are the files used in the MTK tutorial in Chapter 8, “An MTK tutorial” on page 241. With them, you can duplicate the test environment used for the tutorial.

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.

The file names and descriptions are as follows:

� table.src: DDL for both the source and target. It has the Informix stores_demo tables and index DDL. It is on the download site for those users who do not have access to a stores_demo database and includes the itemslog table that was added to support the trigger.

� stockdel.sql: Informix SPL routine to get an order.

� get_order.sql: Informix SPL routine to get an order.

� upd_items-p2: Informix SPL routine to update items.

� trigger.sql: Informix trigger.

� itemslog.sql: The additional table added to the Informix stores_demo database to support the trigger. It is for users who already have a stores_demo database, but need to supplement to match the database in the tutorial (the trigger used in the database requires having this table created).

There is additional information about this material in Appendix B, “Informix source and object definitions” on page 551.


Glossary

Access control list (ACL). The list of principals that have explicit permission (to publish, to subscribe to, and to request persistent delivery of a publication message) against a topic in the topic tree. The ACLs define the implementation of topic-based security.

Aggregate. Pre-calculated and pre-stored summaries, kept in the data warehouse to improve query performance.

Aggregation. An attribute-level transformation that reduces the level of detail of available data, for example, having a Total Quantity by Category of Items rather than the individual quantity of each item in the category.

Application programming interface. An interface provided by a software product that enables programs to request services.

Asynchronous messaging. A method of communication between programs in which a program places a message on a message queue, and then proceeds with its own processing without waiting for a reply to its message.

Attribute. A field in a dimension table.

BLOB. Binary large object, a block of bytes of data (for example, the body of a message) that has no discernible meaning, but is treated as one solid entity that cannot be interpreted.

Commit. An operation that applies all the changes made during the current unit of recovery or unit of work. After the operation is complete, a new unit of recovery or unit of work begins.

Compensation. The ability of DB2 to process SQL that is not supported by a data source on the data from that data source.

© Copyright IBM Corp. 2004. All rights reserved.

Composite key. A key in a fact table that is the concatenation of the foreign keys in the dimension tables.

Computer. A device that accepts information (in the form of digitalized data) and manipulates it for some result based on a program or sequence of instructions about how the data is to be processed.

Configuration. The collection of brokers, their execution groups, the message flows and sets that are assigned to them, and the topics and associated access control specifications.

DDL (data definition language). An SQL statement that creates or modifies the structure of a table or database, for example, CREATE TABLE, DROP TABLE, ALTER TABLE, or CREATE DATABASE.

DML (data manipulation language). An INSERT, UPDATE, DELETE, or SELECT SQL statement.

Data append. A data loading technique where new data is added to the database leaving the existing data unaltered.

Data cleansing. A process of data manipulation and transformation to eliminate variations and inconsistencies in data content. This is typically to improve the quality, consistency, and usability of the data.

Data federation. The process of enabling data from multiple heterogeneous data sources to appear as though it is contained in a single relational database. Can also be referred to “distributed access.”

561

Data mart. An implementation of a data warehouse, typically with a smaller and more tightly restricted scope, such as for a department or workgroup. It can be independent, or derived from another data warehouse environment.

Data mining. A mode of data analysis that has a focus on the discovery of new information, such as unknown facts, data relationships, or data patterns.

Data partition. A segment of a database that can be accessed and operated on independently even though it is part of a larger data structure.

Data refresh. A data loading technique where all the data in a database is completely replaced with a new set of data.

Data warehouse. A specialized data environment developed, structured, and used specifically for decision support and informational applications. It is subject oriented rather than application oriented. Data is integrated, non-volatile, and time variant.

Database instance. A specific independent implementation of a DBMS in a specific environment. For example, there might be an independent DB2 DBMS implementation on a Linux server in Boston supporting the Eastern offices, and another separate and independent DB2 DBMS on the same Linux server supporting the Western offices. They would represent two instances of DB2.

Database partition. Part of a database that consists of its own data, indexes, configuration files, and transaction logs.

DataBlades. These are program modules that provide extended capabilities for Informix databases and are tightly integrated with the DBMS.

DB Connect. Enables connection to several relational database systems and the transfer of data from these database systems into the SAP Business Information Warehouse.

Debugger. A facility on the Message Flows view in the Control Center that enables message flows to be visually debugged.

Deploy. Make operational the configuration and topology of the broker domain.

Dimension. Data that further qualifies or describes a measure, or both, such as amounts or durations.

Distributed application In message queuing, a set of application programs that can each be connected to a different queue manager, but that collectively constitute a single application.

Drill-down. Iterative analysis, exploring facts at more detailed levels of the dimension hierarchies.

Dynamic SQL. SQL that is interpreted during execution of the statement.

Engine. A program that performs a core or essential function for other programs. A database engine performs database functions on behalf of the database user programs.

Enrichment. The creation of derived data. An attribute-level transformation performed by some type of algorithm to create one or more new (derived) attributes.

Extenders. These are program modules that provide extended capabilities for DB2 and are tightly integrated with DB2.

FACTS. A collection of measures, and the information to interpret those measures in a given context.

Federated server. Any DB2 server where the DB2 Information Integrator is installed.

Federation. Providing a unified interface to diverse data.

Gateway. A means to access a heterogeneous data source. It can use native access or ODBC technology.

Grain. The fundamental lowest level of data represented in a dimensional fact table.


Instance. A particular realization of a computer process. Relative to the database, the realization of a complete database environment.

Java Database Connectivity. An application programming interface that has the same characteristics as ODBC, but is specifically designed for use by Java database applications.

Java Development Kit. Software package used to write, compile, debug, and run Java applets and applications.

Java Message Service. An application programming interface that provides Java language functions for handling messages.

Java Runtime Environment. A subset of the Java Development Kit that enables you to run Java applets and applications.

Materialized query table. A table where the results of a query are stored for later reuse.

Measure. A data item that measures the performance or behavior of business processes.

Message domain. The value that determines how the message is interpreted (parsed).

Message flow. A directed graph that represents the set of activities performed on a message or event as it passes through a broker. A message flow consists of a set of message processing nodes and message processing connectors.

Message parser. A program that interprets the bit stream of an incoming message and creates an internal representation of the message in a tree structure. A parser is also responsible for generating a bit stream for an outgoing message from the internal representation.

Metadata. Typically called data (or information) about data. It describes or defines data elements.

MOLAP. Multidimensional OLAP. Can be called MD-OLAP. It is OLAP that uses a multidimensional database as the underlying data structure.

Multidimensional analysis. Analysis of data along several dimensions, for example, analyzing revenue by product, store, and date.

Multitasking. Operating system capability that allows multiple tasks to run concurrently, taking turns using the resources of the computer.

Multithreading. Operating system capability that enables multiple concurrent users to use the same program. This saves the overhead of initiating the program multiple times.

Nickname. An identifier that is used to reference the object located at the data source that you want to access.

Node group. Group of one or more database partitions.

Node. An instance of a database or database partition.

ODS. (1) Operational data store: A relational table for holding clean data to load into InfoCubes, and can support some query activity. (2) Online Dynamic Server, an older name for IDS.

OLAP. Online analytical processing. Multidimensional data analysis, performed in real time. Not dependent on an underlying data schema.

Open Database Connectivity. A standard application programming interface for accessing data in both relational and non-relational database management systems. Using this API, database applications can access data stored in database management systems on a variety of computers even if each database management system uses a different data storage format and programming interface. ODBC is based on the call-level interface (CLI) specification of the X/Open SQL Access Group.

Optimization. The capability to enable a process to execute and perform in such a way as to maximize performance, minimize resource utilization, and minimize the process execution response time delivered to the end user.

Glossary 563

Partition. Part of a database that consists of its own data, indexes, configuration files, and transaction logs.

Pass-through. The act of passing the SQL for an operation directly to the data source without being changed by the federation server.

Pivoting. Analysis operation where a user takes a different viewpoint of the results, for example, by changing the way the dimensions are arranged.

Primary key. Field in a table that is uniquely different for each record in the table.

Process. An instance of a program running in a computer.

Program. A specific set of ordered operations for a computer to perform.

Pushdown. The act of optimizing a data operation by pushing the SQL down to the lowest point in the federated architecture where that operation can be executed. More simply, a pushdown operation is one that is executed at a remote server.

ROLAP. Relational OLAP. Multidimensional analysis using a multidimensional view of relational data. A relational database is used as the underlying data structure.

Roll-up. Iterative analysis, exploring facts at a higher level of summarization.

Server. A computer program that provides services to other computer programs (and their users) in the same or other computers. However, the computer that a server program runs in is also frequently referred to as a server.

Shared nothing. A data management architecture where nothing is shared between processes. Each process has its own processor, memory, and disk space.

Static SQL. SQL that has been compiled prior to execution. Typically provides best performance.

Subject area. A logical grouping of data by categories, such as customers or items.

Synchronous messaging. A method of communication between programs in which a program places a message on a message queue and then waits for a reply before resuming its own processing.

Task. The basic unit of programming that an operating system controls. Also see Multitasking.

Thread. The placeholder information associated with a single use of a program that can handle multiple concurrent users. Also see Multithreading.

Type mapping. The mapping of a specific data source type to a DB2 UDB data type.

Unit of work. A recoverable sequence of operations performed by an application between two points of consistency.

User mapping. An association made between the federated server user ID and password and the data source (to be accessed) user ID and password.

Virtual database. A federation of multiple heterogeneous relational databases.

Warehouse catalog. A subsystem that stores and manages all the system metadata.

Wrapper. The means by which a data federation engine interacts with heterogeneous sources of data. Wrappers take the SQL that the federation engine uses and map it to the API of the data source to be accessed. For example, they take DB2 SQL and transform it to the language understood by the data source to be accessed.

xtree. A query-tree tool that enables you to monitor the query plan execution of individual queries in a graphical environment.


acronyms

ACS access control system

ADK Archive Development Kit

API application programming interface

AQR automatic query rewrite

AR access register

ARM automatic restart manager

ART access register translation

ASCII American Standard Code for Information Interchange

AST application summary table

BLOB binary large object

BW Business Information Warehouse (SAP)

CCMS Computing Center Management System

CFG Configuration

CLI call-level interface

CLOB character large object

CLP command line processor

CORBA Common Object Request Broker Architecture

CPU central processing unit

CS Cursor Stability

DAS DB2 Administration Server

DB database

DB2 II DB2 Information Integrator

DB2 UDB DB2 Universal Database

DBA database administrator

DBM database manager

DBMS database management system

DCE distributed computing environment

Abbreviations and


DCM Dynamic Coserver Management

DCOM Distributed Component Object Model

DDL data definition language

DES Data Encryption Standard

DIMID Dimension Identifier

DLL dynamic link library

DML data manipulation language

DMS database managed space

DPF data partitioning facility

DRDA Distributed Relational Database Architecture

DSA Dynamic Scalable Architecture

DSN data source name

DSS decision support system

EAI Enterprise Application Integration

EBCDIC Extended Binary Coded Decimal Interchange Code

EDA enterprise data architecture

EDU engine dispatchable unit

EGM Enterprise Gateway Manager

EJB Enterprise Java Beans

ER Enterprise Replication

ERP Enterprise Resource Planning

ESE Enterprise Server Edition

ETL Extract, Transform, and Load

FP fix pack

FTP File Transfer Protocol

Gb gigabits

GB gigabytes

565

GUI graphical user interface

HADR High Availability Disaster Recovery

HDR High Availability Data Replication

HPL High Performance Loader

I/O input/output

IBM International Business Machines Corporation

ID identifier

IDE Integrated Development Environment

IDS Informix Dynamic Server

II Information Integrator

IMG Integrated Implementation Guide (for SAP)

IMS™ Information Management System

ISAM Indexed Sequential Access Method

ISM Informix Storage Manager

ISV independent software vendor

IT information technology

ITR internal throughput rate

ITSO International Technical Support Organization

IX index

J2EE Java 2 Platform Enterprise Edition

JAR Java Archive

JDBC Java Database Connectivity

JDK Java Development Kit

JE Java Edition

JMS Java Message Service

JRE Java Runtime Environment

JVM Java Virtual Machine

KB kilobyte (1024 bytes)

LDAP Lightweight Directory Access Protocol

LPAR logical partition

LV logical volume

Mb megabits

MB megabytes

MDC multidimensional clustering

MPP massively parallel processing

MQI message queuing interface

MQT materialized query table

MRM message repository manager

MTK DB2 Migration Toolkit for Informix

NPI non-partitioning index

ODBC Open Database Connectivity

ODS operational data store

OLAP online analytical processing

OLE object linking and embedding

OLTP online transaction processing

ORDBMS Object Relational Database Management System

OS operating system

O/S operating system

PDS partitioned data set

PIB parallel index build

PSA persistent staging area

RBA relative byte address

RBW red brick warehouse

RDBMS Relational Database Management System

RID record identifier

RR repeatable read

RS read stability

SCB session control block

SDK Software Developers Kit

SID surrogate identifier


SMIT Systems Management Interface Tool

SMP symmetric multiprocessing

SMS System Managed Space

SOA service-oriented architecture

SOAP Simple Object Access Protocol

SPL Stored Procedure Language

SQL structured query

TCB thread control block

TMU table management utility

TS table space

UDB Universal Database

UDF user-defined function

UDR user-defined routine

URL Uniform Resource Locator

VG volume group (RAID disk terminology).

VLDB very large database

VP virtual processor

VSAM virtual sequential access method

VTI virtual table interface

WSDL Web Services Definition Language

WWW World Wide Web

XBSA X-Open Backup and Restore APIs

XML Extensible Markup Language

XPS Informix Extended Parallel Server

Abbreviations and acronyms 567

Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. In some cases material from these IBM publications may have been used, or referenced, in this redbook.

IBM RedbooksFor information about ordering these publications, see “How to get IBM Redbooks” on page 572. Note that some of the documents referenced here may be available in softcopy only.

� A Practical Guide to DB2 UDB Data Replication V8, SG24-6828

� DB2 UDB ESE V8 non-DPF Performance Guide for High Performance OLTP and BI, SG24-6432

� Oracle to DB2 UDB Conversion Guide, SG24-7048

Other publicationsThese publications are also relevant as further information sources:

� Data Warehouse Center Administration Guide Version 8 Release 2, SC27-1123

� DB2 Application Programming Guide for common server V2, S20H-4643

� IBM DB2 Connect User's Guide, SC09-4835

� IBM DB2 Information Integrator Developer's Guide Version 8, SC18-7359

� IBM DB2 Information Integrator Replication and Event Publishing Guide and Reference Version 8 Release 2, SC18-7568

� IBM DB2 UDB Administration Guide: Performance, SC09-4821

� IBM DB2 UDB Administration Guide: Planning, SC09-4822

� IBM DB2 UDB Application Development Guide: Programming Client Applications, SC09-4826

� IBM DB2 UDB Application Development Guide: Programming Server Applications, SC09-4827


� IBM DB2 UDB Command Reference, SC09-4828

� IBM DB2 UDB Data Movement Utilities Guide and Reference, SC09-4830

� IBM DB2 UDB Data Recovery and High Availability Guide and Reference, SC09-4831

� IBM DB2 UDB Installation and Configuration Supplement V8.2, GC09-4837

� IBM DB2 UDB Quick Beginnings for DB2 Servers, GC09-4836

� IBM DB2 UDB SQL Reference Volume 1, SC09-4844

� IBM DB2 UDB SQL Reference Volume 2, SC09-4845

� Information Catalog Center Administration Guide Version 8 Release 2, SC27-1125

� Baklarz, G., et al., DB2 Universal Database v7.1 for UNIX, Linux, Windows, and OS/2, Database Administration Certification Guide, Prentice Hall PTR, 2000, ISBN 0130913669

� Brown, P., Object-Relational Database Development: A Plumber's Guide, Prentice Hall PTR, 2000, ISBN 0130194603

� Roy, J., Informix Dynamic Server.2000: Server-Side Programming in C, Prentice Hall PTR, 1999, ISBN 013013709X

� Roy, J., et al., Open-Source Components for Informix Dynamic Server 9.x, Pearson Education, 2001, ISBN 0130428272

� Yip, P., et al., DB2 SQL Procedural Language for Linux, UNIX, and Windows, Prentice Hall PTR, 2002, ISBN 0131007726

Online resourcesThese Web sites and URLs are also relevant as further information sources:

� “Using the Node Data Type to Solve Problems with Hierarchies in DB2 Universal Database” by Jacques Roy, February 2003


� “Generating XML from IDS 9.x,” by Jacques Roy, February 25, 2003


� “Using GUIDs with IDS 9.x,” by Jacques Roy, January 29, 2004


� “DB2 Basics: Fun with Dates and Times,” Paul Yip, August 28, 2003







� “DB2 Basics: Table Spaces and Buffer Pools,” by D. Kline and G. Wieser, December 19, 2002


� “Which distributed edition of DB2 Version 8 is right for you?,” by Paul C. Zikopoulos, November 2002


� IBM Training “Fast Path to DB2 UDB for Experienced Relational DBAs,” Course Code CF281, and DB2 UDB Advanced Programming, Course Code CF114


� IBM Software Migration Project Office (SMPO)


� IBM Informix DataBlade API: Programmer’s Guide


� List of books about DB2 UDB


� IBM Learning Services Web page


� A series of complementary self-study courses and tutorials about DB2


� Certification programs for DB2


� DB2 Migrate Now!


� DB2 UDB developerWorks


� Perl DBI


� Getting started with DB2


� DB2 Support


Related publications 571















� DB2 Warehouse Manager


� Optional DB2 tools


� DB2 Performance Expert


� DB2 Recovery Expert


� High Performance Unload


� DB2 Test Database Generator


� DB2 Table Editor


� DB2 Web Query Tool


How to get IBM RedbooksYou can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:

ibm.com/redbooks

Help from IBMIBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services




http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/









Index

Symbols.NET 64

Aaccess methods 287ACID 361activate database 426ActiveX 64Activity Monitor 426, 516additional DB2 processes 34additional processes 33ADO 64agent pool 32Agent private memory 23AIX 217Alter Buffer Pool 145Alter option 145Alter Table function 494ALTER TABLESPACE 149–150alternative authentication 402ANTLR 220application group 24Application Group Shared Memory 22application migration 354Application Shared Memory 22architecture 11Archival Logging 46archive information 39Ascential DataStage 60aslheapsz 23Audit buffer size 22Authentication 402authorities 4autoconfigure 75, 77Automated backup 166Automated Summary Tables 299Automatic database backup 486Automatic database statistics 486automatic maintenance 485Automatic Maintenance wizard 166Automatic reorganization 487


Bbackup 3, 22backup and recovery 65, 164backup database 168backup image 169, 177, 187backup wizard 168bind file 356BIND syntax 359Binding 358BLOB 37, 390BLOB classes 354BLOB space 35, 37block-based buffer pools 24BLOCKSIZE 25Books 351Boolean data types 338buffer cache 18, 42Buffer Pool Analyzer 451buffer pool tuning 421buffer pools 17, 22, 24, 69, 141Built-in functions 215Business intelligence 8

CC 63C string 386C++ API 390C/C++ 376C/C++ functions 381cache 141calculate index sizes 290Catalog cache 22cataloging 70character types 329

NCHAR 330TEXT 331Truncation 329VARCHAR 331

chunk 37, 146circular logging 46, 160CLI 63CLI environment 389Client Configuration Assistant 425

573

client reroute host 180client/server encryption 414client-side message buffers 20CLOB 37clone 187clustered index 289COBOL 63Collection 347collections data types 338Command Editor 143, 427, 429, 438Command Line Processor 63, 496Committed Read 369Common Migration Considerations 258compressed database backup 168Configuration Advisor 6, 75, 425Configuration Assistant 442configuration changes 137configuration files 68configuration options 3configuration parameters 69, 137Configure Client Reroute 180Configuring a C++ Compiler 229Connection Concentrator 7connection string 388Constraints 241container 37, 146, 149context switch 25, 29

process-based 26Control Center 15, 63, 68, 138, 142, 172, 176, 234, 291, 425, 427, 447, 455, 485–486CONTROL privileges 238cooked files 38Copy table function 464cost-based optimization 46cost-based optimizer 474Crash recovery 165create a database 489create buffer pool 142Create DB2 instance 232Create Index Wizard 291Create Table Space Notebook 40Create Table Space Wizard 40create table spaces 146create UDF 383Creating DB2 database users 239Cursor Stability 369, 372Cursors 372

Close 374Declare 373

Fetching rows 373Free the cursor 374Insert Cursor 375Non-Scroll 374Open 373Scroll Cursors 374Update Cursor 374

DDAS 137Data Blade Development Kit 441data conversion 55–56Data Encryption 402Data Managed Space 56data migration methods 4data movement 59, 241Data transfer script creation 241data type support 7data types 4Data Warehouse Center 448database activation 134database administration 419Database administrative commands 216database backup 164database configuration 137, 159database configuration file 15database heap 22Database History 443database integrity 482database interfaces 62database manager 69database manager configuration parameters 543

aslheapsz 23intra_parallel 23max_connections 23max_coordagents 23

Database manager shared memory 22database objects 62database operations 133database population method 177database recovery 169database restore 172database shared memory 22Database System Monitor 22DataBlade modules 348DataBlades 4Date and time types 335DB2 Administration Server 16


DB2 agents 522coordinator 24subagents 24

DB2 applications 521DB2 architecture 3, 17DB2 CLI 8, 388DB2 Data Links Manager 7DB2 Database Modes 44DB2 Development Center 8, 397DB2 Enterprise Server Edition 9–10DB2 ESE

See DB2 Enterprise Server EditionDB2 Everyplace 7DB2 Express 10DB2 Extenders 4, 349DB2 Federated feature 464DB2 Information Integrator 60DB2 limits 341DB2 log files

Primary Log Files 45Secondary Log Files 45

DB2 maintenance utilities 483DB2 Migration Toolkit for Informix

See MTKDB2 Net Search Extender 7DB2 optimization 4DB2 packaging 8DB2 Performance Expert 451DB2 processes 33DB2 Query Optimization 47DB2 Recovery Expert 452DB2 Replication Center 445DB2 Spatial Extender 7DB2 Table Editor 455DB2 Test Database Generator 453DB2 Tools catalog 232DB2 UDB 1, 11, 213, 446DB2 UDB authorities 238DB2 UDB privileges 238DB2 Universal Database

See DB2 UDBDB2 Version 8.2 5DB2 Warehouse Manager 448DB2 Web Health Center 449DB2 Web Query Tool 455db2agent 32db2agntp 32DB2DART utility 482db2fmp 23

DBI 64DBMS 1dbspace 37–38DDL 39, 54, 58, 249, 267, 479DDL syntax 3deadlocks 368, 507DECIMAL data type 332

FLOAT 333default buffer pool 142Deletion of index entries 292Delimited ASCII 457delprioritychar file type modifier 331Deployment 218Design Advisor 425Development Center 349, 441device containers 146diagnostic files, 528directory containers 146disk 3disk allocation 39Disk considerations 329Disk mirroring 187Distinct type 347Distributed Partitioning Facility 5DML 39, 246DMS 40–41, 56, 289DMS table space 235dynamic logging 44dynamic SQL 48, 63, 216, 356–357

EEDU

See engine dispatchable unitengine dispatchable unit 31Enterprise Edition 10Enterprise Replication 48Enterprise Server Edition

See DB2 Enterprise Server EditionEntity-Relationship 58environment variables 136, 539Error handling 380ESE package 9ESQL/C 4, 356, 385ETL tools 60Event monitor 506Event Publishing 445export utility 458extended storage 142

Index 575

extensibility 4, 343check constraints 344stored procedures 344triggers 344

extent 37External procedures 348

Ffast recovery 165Federated Web Services 7federation 7, 60, 65FENCED clause 408fenced stored procedure 23fenced user screen 232file containers 146file formats 457FLOAT data type 340Foreign Key 296FORTRAN 63fragmentation 38Function signature 382Functional indexes 298

Ggeneral registry variables 534generate scripts 55Grant command syntax 239group authentication 402GUI 5, 40, 138, 217

HHADR 164

See High Availability Disaster RecoveryHDR 176

See High Availability Data ReplicationHealth Center 445, 486Health Center Tool 499Health Center/Monitor 6Health Check Monitor 499high availability 3, 48, 57, 65, 176, 186

mirroring 49High Availability Data Replication 3, 48High Availability Disaster Recovery 3, 7, 48, 164, 176High Performance Loader Express 20High Performance Unload 453host variables 386

assignments 387HP-UX 217HTML 64HTTP 64

IIBM Silicon Valley Lab 214IBM Watson Research Laboratory 214IDENTITY definition 334IDS 1, 11, 214IDS architecture 3, 14IDS built-in functions 222IDS data pages 18IDS Database Modes

ANSI database 44Logged database 44Non-logged database 44

IDS DataBlades 349IDS Enterprise Edition 9IDS Logging 42IDS MaxConnect 7IDS sessions 521IDS shared memory 18IDS threads 522IDS Version 9.40.FC3 5IDS Workgroup Edition 10Implicit privilege 238import utility 459Include option 293incremental backup 167incremental delta 167index comparison 288index expansions 293index leaf pages 290Index placement 288index rebuild 364index reorganization 297, 473index space estimates 290index tree 295index types 4indexes 215, 241indexes and constraints 296indexing capabilities 346indexing columns 288indexing schemas 288indexing strategies 288Individual privilege 238Informatica PowerMart 60


Information Catalog Center 447Information Integrator. 60Informix 2Informix 4GL 5, 377Informix Client/SDK 5Informix Dynamic Server

See IDSInformix XPS 5, 10instance 3, 12, 15, 56, 67, 133

attachment 135configuration 137configuration changes 133creation 133operation 133operation modes 134

integer variable 386Integrated Exchange Format 457Internal procedures 348INTERVAL data type 337intra-parallelism 23, 47intra-partition parallelism 24iSeries 5, 214Isolation Level - changing 370Isolation Levels 369ISV migrations 218

JJ2EE 64Java 8, 54, 62–63, 220, 376, 427Java/JDBC 387JDBC 4, 8, 63, 138, 219, 246, 354, 387Journal 443

LLarge Objects 348, 390LDAP 417leaf page 295Linux 5, 214, 217, 243, 451load 22load from a cursor 464LOB data types 338

BLOB 338BYTE 338CLOB 338TEXT 338

LOB host variable 390LOB locator host variable 391Lock escalation 368

Lock list 22LOCK TABLE 368lock-placement 365Locks 19, 364, 520log buffers 17, 19, 42log mirroring 185logging modes 160Logical Log File 43logical logs 68LOGPATH 159long object names 326Loops 379Lotus 457

MManaging logs 159Manuals 350Materialized Query Table

See MQTmax_connections 23MDC 8, 305, 425, 470

dimensions 305extent sizes 305syntax 307two-dimensional 306type of table 305

memory 3memory allocation 16, 18, 21memory heap 137memory pools 19, 526Memory Visualizer 6Memory Visualizer tool 504metadata 59Microsoft .NET Add-In 398Microsoft Visual Studio .NET 441migrate a core database 241migrate database application objects 241migration process 219Mirroring 49Mobility on demand 7model 58MONEY data type 333Monitor Buffer Pools 139Monitor heap 22monitoring and notification 489monitoring tools and advisors 499MQT 8, 299, 425

creation 300

Index 577

Dynamic SQL 301Optimization class 301query optimization 300Query rewriting 302Refresh deferred 300Refresh immediate 300REFRESH TABLE 300refreshing 304when to use 304

MTK 3, 61, 213, 241, 431additional features 262Advanced Options 250ASCII delimited 264ASCII positional 264best practices 273Changes Report 262Connect to Database 248Convert 244Convert step 257Convert tab 249Create a new project 243Create Scripts 265DB2 Data Loading Options 263DB2 Load/Import Mode 264DB2 Table Spaces 260Debugger 273Default Source Schema 250Deploy Tables and Indexes 266Deploy to DB2 245, 266Deployment Best Practice 269Deployment phase 261Extract grant statements 248File Format 264Generate Data Transfer Scripts 245, 263Global Type Mapping 251index DDL 260Making Manual Changes 257Message Help 256not null constraint 255procedures 271product installations 242Refine 244Refine tab 252source file 255Specify Source 244SQL Translator 271successful connection 247Translation Rate message 256Translator Information 253

Translator Warning 253triggers 271user interface 244Verification Report 268View button 248

MTK actionsConvert 220Deploy to DB2 222, 225Extract 219Functions and Procedures 223Generate Data Transfer Scripts 224Import 219Loading Data 229Manual transfer 225metadata 221Refine 220Specify Step 219Translator 220

MTK Configurations 217MTK tutorial 241MTK with Manual Deployment 231Multidimensional Cluster

See MDCMultidimensional data clustering

see MDCmultithreaded architecture 20, 25, 29

Nnamed pipes 59NCHAR data type 330Non-delimited ASCII 457Notification Log 445NULL values 340numerical data types 331numerical limits 331numerical types

DATE 335DATETIME 336DECIMAL 332INTERVAL 337MONEY 333SERIAL 333TIME 336TIMESTAMP 336

Oobject types 4object-oriented 344


object-relational 344ODBC 4, 8, 63–64, 219ODBC/CLI 388Offline mode 135OLAP 53OLE DB 8, 64ON-bar 39oncheck 290ONCONFIG 137, 159ONCONFIG file 47oninit process 26Online Analytical Processing 448

also see OLAPOnline load 7Online mode 134Online storage management 7onstat 139, 525Opaque 347optimizer 299, 308

Cartesian products 321classes 319composite inner tables 321cost based 309directives 216, 319Dynamic Programming 321Greedy join enumeration 321Merge Scan joins 320Non-uniform distribution statistics 321query plans 308, 310star-join strategy 321statistics 356table scans 320Visual Explain 311

Oracle 214Ownership privileges 238

PPackage cache 22Package concept 355Package versions 361page 36page cleaning 422Parallel Data Query 47parallelism 47partitioned databases 6partitioning strategies 425password encryption 402performance tuning 6, 11

buffer pools 421data organization 426database reorganization 426database statistics 426instance and database 420multiple buffer pools 422page cleaning processes 423processes 424Quick-start tips 425

Performance Warehouse 451Personal Developer’s Edition 10Personal Edition 10phantom rows 371Physical Log File 43planning the transition 3Pluggable Authentication Module 418prefetch

see sequential prefetchPrimary Key 296private buffers 19privileges 4Process allocation 16process context switch 25process model 31Process Tuning 424processes 3, 17, 25programming languages 385

QQuery Optimization 46query plan 355query plan analysis 315Queue replication 186, 445queues 19Quiescent mode 135

Rraw devices 38raw disk 146Read Stability 369, 371readiness assessment 53Real or Smallfloat data type 341REBIND syntax 359Recommendation Advisor 499RECOVER command 169recover database 175recoverable database 166recovery 3, 165

Index 579

recovery history file 165, 170recovery log files 165recovery logging 160Redbooks Web site 572

Contact us xixregistry profile 69REORG INDEXES 470, 473REORGCHK 470Repeatable Read 371replication 7, 65, 186Replication Center 445replication server 60Resource Tuning 427RESTART option 462restore 22RESTORE command 169rollback 363ROLLFORWARD command 169rollforward recovery 165root reserved pages 39round-robin 40Row type 347RSAM thread control block 29RUNSTATS 216, 271, 296, 359, 426, 462, 476

SSavepoints 363Sbspaces 38Scalar function 348schema extraction 478scope of the redbook 3security 4, 401

authentication methods 417client/server 414default privileges 405GRANT and REVOKE 405index privileges 408LDAP 417levels 405list of privileges 410package privileges 409permissions 404Pluggable Authentication Module 418privilege descriptions 407roles and groups 404schema privileges 410schema privileges list 411Secure Shell 415

table space privileges 414Table/View/Nickname privileges 412three-tier architecture 417tunneling 415two-tier architecture 416

Self Managing 427Sequence objects 339Sequences 215sequential prefetch 24, 142SERIAL data type 333server-side message buffers 20session control block 19, 29Session pools 19Set User Information 232shadow column 298shared library 382Shared memory

connections 18message portion 20portions 18resident portion 18sort 22virtual portion 19

shared nothing architecture 47SIMPLE BLOB 390SIMPLE LOB 347SMART BLOB 390SMART LOB 347SMPO 55SMS 40–41, 56, 289SMS table space 235snapshot 187, 511snapshot monitor 512SOAP 64soft checkpoints 423SPL commands 221SPL routines 215, 241split image 177Split Image Backups 50split mirror function 187split mirror image 187SQL 376SQL Assist 427, 438SQL Communication Area 392SQL Communications Access record 335SQL considerations 3SQL Descriptor Area 397SQL extenders 348SQL replication 186, 445


SQL Server 214SQL/PL 376SQL/PL expansions 378SQLCA

see SQL Communications AreaSQLCODE 216SQLDA

see SQL Descriptor AreaSQLJ 63SQLJ programming interfaces 8standby database 188standby instance 177Static SQL 355, 357statistical information 296Storage Management 157Storage Management tool 157Storage Manager 152, 506storage objects 157Stored Procedure 62, 64, 375

builder 348Language 377parameter handling 378

stores_demo database 4striping 40Structured type 348Structured type columns 348Sun Solaris 217Sybase 214symmetric multiprocessor 47Symphony 457Synonyms 215

TTable function 348Table reorganization 364, 472table space 15, 17, 37, 40, 146

creating 236temporary 15

table space categorieslarge 235regular 235temporary 235

table space change history file 165table space planning 235table space security

authority 238privilege 238

table space state 155–156

table space types 40tables 241Task Center 143, 433Task History 443Task schedules 433TERMINATE option 462terminology 347test environment 5TEXT data type 331thread 27, 29thread context switch 25thread control block 19, 29thread switching 25throttling utilities 484time plan 57Training 350Training costs 55transaction logging 158transaction logging mode 159transaction scope 361transition 2, 4–5, 11, 18, 35, 50, 213Transition consulting services 554transition plan 354transition planning 554Triggers 62, 215, 241, 468Truncation 329tutorial for MTK 242Type I and Type II indexes 297Typed tables 348Types of locks 365

Exclusive lock 365Shared lock 365Update (promotable) lock 365

UUDF

see user-defined functionUDR

See user-defined routinesUncommitted Read 372UNIX 214, 243, 451UNIX File System 38Update Statistics 271, 476user authentication 402user-defined functions 23, 164, 346, 348, 376, 441, 468

invocation 384user-defined functions and routines 348

Index 581

user-defined routines 31, 376user-defined types 345Utility heap 22

Vvalidating backup 485VARCHAR data type 330Version recovery 165video 64Views 215, 468virtual processors 20, 27Visual Explain 4, 439, 477VisualAge C++ 229

WWeb services 7WebSphere 8WebSphere MQ 186WebSphere Studio Application Developer 397WebSphere Studio Application Developer plug-in 397Windows 214, 217, 243, 451Wizards

Configure Automatic Maintenance 450Create Cache Table 450Redistribute Data 450Set Up Activity Monitor 450Set Up HADR 450Storage Management Setup launchpad 450

Workgroup Server Edition 10write-ahead logging 159

XXML 7XPS 214

Zz/OS 5, 451


(1.0” spine)0.875”<->

1.498”460 <->

788 pages

Database Transition: Informix Dynam

ic Server to DB2 Universal Database

®

SG24-6367-00 ISBN 0738490989

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

Database Transition:Informix Dynamic Serverto DB2 Universal Database

The transition process, planning, guidelines, and examples

DB2 Migration Toolkit for Informix makes it easier

Data and application considerations

This IBM Redbook focuses on the considerations and methodology for transitioning from IBM Informix Dynamic Server (IDS) Version 9.4 to IBM DB2 Universal Database Version 8.2.

We address the basic topic areas of data, applications, and administration. We also include an overview of the architecture of the two products to give you a better understanding of how they are structured. This book provides information about feature and functionality mapping and SQL implementation as guidelines to help you understand the specific capabilities, and similarities, in areas such as data types, DML, DDL, and stored procedures. To aid in the transition preparation, we discuss application conversion considerations. There is an overview of the capabilities of the DB2 Migration Toolkit for Informix to show how it can make the transition much easier. We also describe other transition approaches to provide you with alternatives to consider and to give you flexibility.

With this information, you can understand the requirements, plan your transition, and proceed with the transition in an orderly and cost effective manner.

Back cover




Database Transition: Informix Dynamic Server to DB2 Universal

Documents

Transcript of Database Transition: Informix Dynamic Server to DB2 Universal