IBM DB2 Universal Database

Administration Guide:
Design and Implementation
V
ersion 6

SC09-2839-00
IBM DB2 Universal Database

Administration Guide:
Design and Implementation
V
ersion 6

SC09-2839-00
Before using this information and the product it supports, be sure to read the general information under “Appendix P.
Noti...
Contents
.
.
.

.
.
.

.
.
.

.
.
.

. xiii
. xiv
. xiv

Part 1. Database Concepts . . . .
Chapter 1. Introduction to Conc...
Introductory Concepts for Database
Implementation . . . . . . . . . .
Starting and Stopping DB2 . . . . .
Starting DB2 UDB...
The Control Center . . . . . . . . .
Main Elements of the Control Center
Using a Customized Control Center in
DB2 for OS/3...
Table and View Privileges . . . . .
Nickname Privileges . . . . . .
Server Privileges . . . . . . . .
Package Privileges ....
Setting up an ADSTAR Distributed
Storage Manager Client for UNIX-Based
Platforms . . . . . . . . . . . 452
Setting up an A...
Chapter 14. High Availability in the
Windows NT Environment . . . . . .
Failover Configurations . . . . . . .
Hot Standby C...
Accessing Information with
Information Center . . .
Setting Up a Document Server
Searching Online Information
Printing the...
Overview for UNIX-Based Operating
Systems . . . . . . . . . . . . .
Invoking a User Exit Program . . . . .
Sample User Exi...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
...
xii

Administration Guide Design and Implementation
About This Book
The Administration Guide in its two volumes provides information necessary
to use and administer the year ...
process ID and the thread ID are used to identify the operating system that
generated the log. Combined with the Control C...
v Chapter 3. Designing Your Physical Database, discusses the guidelines for
designing a physical database, including consi...
v Appendix A. How the DB2 Library Is Structured, provides information
about the structure of the DB2 library, including Sm...
The specific chapters and appendixes in that volume are briefly described
here:
Introduction to Performance
v Elements of Pe...
v Explain Tables and Definitions, provides information about the tables used
by the DB2 Explain facility and how to create ...
Part 1. Database Concepts

© Copyright IBM Corp. 1993, 1999

1
2

Administration Guide Design and Implementation
Chapter 1. Introduction to Concepts Within DB2 Universal
Database
This chapter provides an introduction to DB2 Universal D...
stored. See “Nodegroups and Data Partitioning” on page 6 for more
information about nodegroups. See “Overview of DB2 Paral...
System

Instance(s)

Database(s)

Nodegroup(s)

Table space
tables

index(es)

long data

Figure 1. Relationship Among Som...
A single-partition database is a database having only one database partition. All
data in the database is stored in that p...
Database

Nodegroup 2

Database
Partition

Nodegroup 1
Database
Partition
Database
Partition
Database
Partition

Nodegroup...
DB2 supports the following types of parallelism:
v I/O
v Query
v Utility

I/O Parallelism
For situations in which multiple...
SELECT... FROM...

A query is divided
into parts, each being
executed in parallel.

Data
Database Partition

Figure 3. Int...
SELECT... FROM...

A query is divided
into parts, each being
executed in parallel.

Data

Data

Data

Data

Database Parti...
SELECT... FROM...

SELECT... FROM...

SELECT... FROM...

A query is divided
into parts, each being
executed in parallel.

...
CREATE INDEX command is issued, during restart (if an index is marked
invalid), and during the reorganization of data.
Bac...
Uniprocessor machine

CPU

Memory
Database Partition

Disks

Figure 6. Single Partition On a Single Processor

The databas...
Single Partition with Multiple Processors
This environment is typically made up of several equally powerful processors
wit...
Capacity and Scalability
In this environment you can add more processors. However, since it is
possible for the different ...
Communications Facility

Uniprocessor machine

Uniprocessor machine

Uniprocessor machine

Uniprocessor machine

CPU

CPU
...
Partitions with Multiple Processors
As an alternative to a configuration in which each partition has a single
processor is ...
Logical Database Partitions
A logical database partition differs from a physical partition in that it is not
given control...
Figure 11 illustrates the fact that you can multiply the configuration shown in
Figure 10 on page 18 to increase processing...
Table 1. Types of Parallelism Possible for Each Hardware
Environment
Hardware Environment

Single Partition,
Single Proces...
CURRENT DEGREE
Special register for dynamic SQL. Refer to the SQL Reference for more
information.
For more information on ...
v The INTRA_PARALLEL database manager configuration parameter must be
ON
v The table must be large enough to benefit from pa...
– At least as large as the largest (extentsize * number of containers)
product of the table spaces being restored.
– The s...
Figure 12. A Federated Database System

DB2 federated database catalog entries contain information about data source
objec...
Wrappers
Identify the modules (dll, library, etc.) used to access a particular class
or category of data source.
Servers
D...
Federated systems tolerate parallel environments. Performance gains are
delimited by the extent to which a federated datab...
Part 2. Database Design and Implementation

© Copyright IBM Corp. 1993, 1999

27
28

Administration Guide Design and Implementation
Chapter 2. Designing Your Logical Database
This section describes the following steps in database design:
v “Decide What D...
In the sample employee table, the entity “employee” has attributes, or
properties, such as employee number, name, work dep...
Sally manages department C01.
Before you design your tables, you must understand entities and their
relationships. “Employ...
v Group all the relationships for which the “many” side of the relationship is
the same entity.
v Define a single table for...
can have more than one employee. The questions “What does Dolores
Quintana work on?” and “Who works on project IF1000?” bo...
The DEPARTMENT table:
DEPTNO

MGRNO

A00

000010

B01

000020

D11

000060

Figure 15. Assigning One-to-One Facts to a Tab...
A user-defined type (UDT), is a type that is derived from an existing type.
You may need to define types that are derived fr...
v A sourced function, which will be used to invoke other UDFs
For example, two numeric data types are European Shoe Size a...
allows the database manager to enforce the uniqueness of the primary key. At
other times the database manager may use othe...
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Db2
Upcoming SlideShare
Loading in...5
×

Db2

451

Published on

Db2

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
451
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Db2

  1. 1. IBM DB2 Universal Database Administration Guide: Design and Implementation V ersion 6 SC09-2839-00
  2. 2. IBM DB2 Universal Database Administration Guide: Design and Implementation V ersion 6 SC09-2839-00
  3. 3. Before using this information and the product it supports, be sure to read the general information under “Appendix P. Notices” on page 861. This document contains proprietary information of IBM. It is provided under a license agreement and is protected by copyright law. The information contained in this publication does not include any product warranties, and any statements provided in this manual should not be interpreted as such. Order publications through your IBM representative or the IBM branch office serving your locality or by calling 1-800-879-2755 in the United States or 1-800-IBM-4YOU in Canada. When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. © Copyright International Business Machines Corporation 1993, 1999. All rights reserved. US Government Users Restricted Rights – Use duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
  4. 4. Contents . . . . . . . . . . . . . xiii . xiv . xiv Part 1. Database Concepts . . . . Chapter 1. Introduction to Concepts Within DB2 Universal Database . . . . Overview of DB2 Concepts . . . . . . Overview of DB2 Parallelism Concepts . . Nodegroups and Data Partitioning . . . Types of Parallelism . . . . . . . . . I/O Parallelism . . . . . . . . . Query Parallelism . . . . . . . . Utility Parallelism . . . . . . . . Hardware Environments . . . . . . . Single Partition on a Single Processor Single Partition with Multiple Processors Multiple Partition Configurations . . . Summary of Parallelism Best Suited To Each Hardware Environment. . . . . Enabling Parallelism for Queries . . . . Enabling Intra-Partition Query Parallelism . . . . . . . . . . . Enabling Inter-Partition Query Parallelism . . . . . . . . . . . Enabling Utility Parallelism . . . . . . Load . . . . . . . . . . . . . AutoLoader . . . . . . . . . . Create Index . . . . . . . . . . Backup Database / Table Space . . . . Restore Database / Table Space . . . . Federated Database System Concepts . . . Enabling a Federated System . . . . . . 1 3 3 5 6 7 8 8 11 12 12 14 15 19 20 20 21 21 21 21 21 22 22 23 26 Part 2. Database Design and Implementation. . . . . . . . . 27 Chapter 2. Designing Your Logical Database . . . . . . . . . . . . Decide What Data to Record in the Database . . . . . . . . . . . . Define Tables for Each Type of Relationship © Copyright IBM Corp. 1993, 1999 29 29 31 One-to-Many and Many-to-One Relationships . . . . . . . . . . Many-to-Many Relationships . . . . . One-to-One Relationships . . . . . . Provide Column Definitions for All Tables Identify One or More Columns as a Primary Key . . . . . . . . . . . . . . Identifying Candidate Key Columns Be Sure Equal Values Represent the Same Entity . . . . . . . . . . . . . Consider Normalizing Your Tables . . . . First Normal Form . . . . . . . . Second Normal Form . . . . . . . Third Normal Form . . . . . . . . Fourth Normal Form . . . . . . . Planning for Constraint Enforcement . . . Unique Constraints . . . . . . . . Referential Integrity . . . . . . . . Table Check Constraints . . . . . . Triggers . . . . . . . . . . . . Other Database Design Considerations . . 38 39 40 40 42 43 44 45 45 50 51 51 Chapter 3. Designing Your Physical Database . . . . . . . . . . . . Database Physical Directories . . . . . Database Physical Files. . . . . . . Estimating Space Requirements for Tables System Catalog Tables . . . . . . . User Table Data . . . . . . . . . Long Field Data . . . . . . . . . Large Object (LOB) Data . . . . . . Index Space . . . . . . . . . . Additional Space Requirements . . . . . Log File Space . . . . . . . . . Temporary Work Space. . . . . . . Designing Nodegroups. . . . . . . . Nodegroup Design Considerations . . . Designing and Choosing Table Spaces. . . System Managed Space Table Space . . Database Managed Space Table Space Adding Containers to DMS Table Spaces Table Space Design Considerations . . . Federated Database Design Considerations 55 55 56 58 59 59 61 62 63 65 66 67 67 68 75 78 82 84 85 97 Chapter 4. Implementing Your Design About This Book . . . . Who Should Use This book . How This Book is Structured. 99 31 32 33 34 36 38 iii
  5. 5. Introductory Concepts for Database Implementation . . . . . . . . . . Starting and Stopping DB2 . . . . . Starting DB2 UDB on Windows NT . . Using Multiple Instances of the Database Manager . . . . . . . . . . . Organizing and Grouping Objects by Schema . . . . . . . . . . . . Enabling Intra-Partition Parallelism . . Enabling Data Partitioning . . . . . Before Creating a Database . . . . . . Design Logical and Physical Database Characteristics. . . . . . . . . . Create an Instance . . . . . . . . License Management . . . . . . . Establish Environment Variables and the Profile Registry . . . . . . . . . DB2 Administration Server (DAS) . . . Create a Node Configuration File . . . Creation of the Database Configuration File . . . . . . . . . . . . . Replicating Configuration Information Using Response Files . . . . . . . Enable FCM Communications . . . . Creating a Database . . . . . . . . . Definition of Initial Nodegroups . . . Definition of Initial Table Spaces . . . Definition of System Catalog Tables . . Definition of Database Directories . . . DCE Directory Services . . . . . . Lightweight Directory Access Protocol (LDAP) Directory Services . . . . . Creating Nodegroups . . . . . . . Definition of Database Recovery Log Binding Utilities to the Database . . . Cataloging a Database . . . . . . . Creating a Table Space . . . . . . . Creating a Schema . . . . . . . . Creating and Populating a Table . . . Creating a Trigger . . . . . . . . Creating a User-Defined Function (UDF) Creating a User-Defined Type (UDT) Creating a View . . . . . . . . . Creating a Summary Table . . . . . Creating an Alias. . . . . . . . . Creating a Wrapper . . . . . . . . Creating a Server. . . . . . . . . Creating a Nickname . . . . . . . Creating an Index or an Index Specification . . . . . . . . . . iv 100 100 101 102 103 104 104 105 106 106 114 114 124 140 142 143 144 145 146 147 148 148 150 150 151 151 152 152 153 157 158 174 176 179 182 187 189 190 191 198 200 Administration Guide Design and Implementation Before Altering a Database . . . . . . Changing Logical and Physical Design Characteristics. . . . . . . . . . Changing the License Information . . . Changing Instances . . . . . . . . Changing Environment Variables and the Profile Registry Variables . . . . . . Changing the Node Configuration File Changing the Database Configuration Altering a Database . . . . . . . . . Dropping a Database . . . . . . . Altering a Nodegroup . . . . . . . Altering a Table Space . . . . . . . Dropping a Schema . . . . . . . . Modifying a Table in Both Structure and Content . . . . . . . . . . . . Altering a User-Defined Structured Type Deleting and Updating Rows of a Typed Table . . . . . . . . . . . . . Renaming an Existing Table . . . . . Dropping a Table. . . . . . . . . Dropping a Trigger . . . . . . . . Dropping a User-Defined Function (UDF), Function Template, or Function Mapping . . . . . . . . . . . Dropping a User-Defined Type (UDT) or Type Mapping . . . . . . . . . Altering or Dropping a View . . . . . Dropping a Summary Table . . . . . Dropping a Wrapper . . . . . . . Altering or Dropping a Server . . . . Altering or Dropping a Nickname . . . Dropping an Index or an Index Specification . . . . . . . . . . Statement Dependencies When Changing Objects . . . . . . . . . . . . Chapter 5. Administering DB2 Using GUI Tools . . . . . . . . . . . . Administration Tools . . . . . . . Common Tool Features. . . . . . . Show SQL and Show Command . . Show Related . . . . . . . . . Generate DDL. . . . . . . . . Filter . . . . . . . . . . . . Filtering the Display . . . . . . Filtering Retrieved Data . . . . . Defining a Filter to Retrieve a Specific Set of Data . . . . . . . . . . Help . . . . . . . . . . . . . . . . . . . . . 206 206 206 207 212 212 212 213 214 214 214 216 216 223 223 223 224 225 226 227 227 228 229 230 230 232 233 235 236 238 239 239 240 241 241 242 . 242 . 242
  6. 6. The Control Center . . . . . . . . . Main Elements of the Control Center Using a Customized Control Center in DB2 for OS/390 . . . . . . . . . Systems That Can Be Administered . . Objects that can be Administered . . . Displaying Systems in the Control Center Managing DB2 for OS/390 Objects . . . Adding DB2 for OS/390 Subsystems Managing Gateway Connections . . . Functions You Can Perform from the Control Center . . . . . . . . . Creating New Objects . . . . . . . Working with Existing Objects . . . . Locating objects (DB2 for OS/390 only) The Satellite Administration Center . . . The Command Center . . . . . . . . The Script Center . . . . . . . . . Using an Existing Script with the Script Center . . . . . . . . . . . . Scheduling a Saved Command Script to Run . . . . . . . . . . . . . The Journal . . . . . . . . . . . Working with Jobs . . . . . . . . The License Center . . . . . . . . . The Alert Center . . . . . . . . . . Client Configuration Assistant . . . . . Searching for Databases . . . . . . Performance Monitor . . . . . . . . Event Monitor. . . . . . . . . . Using the Monitor Tools . . . . . . Monitoring Performance at a Point in Time . . . . . . . . . . . . . Predefined Monitors . . . . . . . Action Required When an Object Appears in the Alert Center . . . . . Analyzing an Event for a Period of Time Event Analyzer . . . . . . . . . Analyzing SQL Statements . . . . . . Improving Performance of a Query . . Analyzing a Simple Dynamic SQL Statement . . . . . . . . . . . Managing Remote Databases . . . . . . Managing Users . . . . . . . . . . Granting and Revoking Authorities and Privileges . . . . . . . . . . . Moving Data . . . . . . . . . . . Managing Storage . . . . . . . . . Estimating Table and Index Size. . . . 243 244 244 245 245 247 247 247 248 248 249 250 250 251 252 252 253 253 254 254 255 255 255 256 257 258 258 261 262 264 264 265 267 268 268 269 271 271 272 274 274 Checking Space Available in a Table Space . . . . . . . . . . . Adding More Space to a Table Space Troubleshooting . . . . . . . . . Replicating Data . . . . . . . . . Using Lightweight Directory Access Protocol . . . . . . . . . . . . Using a Java Control Center . . . . . Running the Control Center as a Java Applet . . . . . . . . . . . Using Your Java-based Tools for Administration . . . . . . . . . Chapter 6. Controlling Database Access An Overview of DB2 Security . . . . Authentication . . . . . . . . Authorization . . . . . . . . . Federated Database Authentication and Authorization Overview . . . . . Selecting User IDs and Groups for Your Installation . . . . . . . . . . . Selecting an Authentication Method for Your Server . . . . . . . . . . Authentication Considerations for Remote Clients . . . . . . . . . . . . Partitioned Database Considerations . . Using DCE Security Services to Authenticate Users . . . . . . . . How to Setup a DB2 User for DCE. . How to Setup a DB2 Server to Use DCE How to Setup a DB2 Client Instance to Use DCE . . . . . . . . . . DB2 Restrictions Using DCE Security Federated Database Authentication Processing . . . . . . . . . . . Authentication Settings. . . . . . Passing IDs and Passwords to Data Sources . . . . . . . . . . . Federated Database Authentication Example . . . . . . . . . . Privileges, Authorities, and Authorization System Administration Authority (SYSADM) . . . . . . . . . . System Control Authority (SYSCTRL) System Maintenance Authority (SYSMAINT) . . . . . . . . . Database Administration Authority (DBADM) . . . . . . . . . . Database Privileges . . . . . . . Schema Privileges . . . . . . . . 275 276 . 276 . 277 . 278 . 279 . 279 . 280 281 . 282 . 282 . 283 . 284 . 285 . 287 . 292 . 293 . 293 . 294 295 . 297 298 . 299 . 299 . 300 . 303 305 . 307 308 . 309 . 310 . 310 . 312 Contents v
  7. 7. Table and View Privileges . . . . . Nickname Privileges . . . . . . Server Privileges . . . . . . . . Package Privileges . . . . . . . Index Privileges . . . . . . . . Controlling Access to Database Objects . Granting Privileges . . . . . . . Revoking Privileges . . . . . . . Managing Implicit Authorizations by Creating and Dropping Objects . . . Establishing Ownership of a Plan or a Package . . . . . . . . . . . Allowing Indirect Privileges through a Package . . . . . . . . . . . Allowing Indirect Privileges through a Package Containing Nicknames . . . Controlling Access to Data with Views Monitoring Access to Data Using the Audit Facility . . . . . . . . . Tasks and Required Authorizations. . . Using the System Catalog . . . . . . Retrieving Authorization Names with Granted Privileges . . . . . . . Retrieving All Names with DBADM Authority . . . . . . . . . . Retrieving Names Authorized to Access a Table . . . . . . . . . . . Retrieving All Privileges Granted to Users. . . . . . . . . . . . Securing the System Catalog Views . . . . . . . . . 314 316 317 317 318 318 319 320 . 321 . 322 . 322 . 323 324 . 327 . 327 . 328 . 329 . 330 . 330 . 330 . 331 Chapter 7. Auditing DB2 Activities . . Audit Facility Behavior. . . . . . . Audit Facility Usage Scenarios . . . . Audit Facility Messages . . . . . . Audit Facility Record Layouts . . . . Audit Facility Tips and Techniques . . . Controlling DB2 Audit Facility Activities . . . . . . Chapter 8. Utilities for Moving Data . . . 363 Chapter 9. Recovering a Database . Overview of Recovery . . . . . . Factors Affecting Recovery . . . . Recoverable and Non-Recoverable Databases . . . . . . . . . Database Logs. . . . . . . . Reducing Logging on Work Tables . Point of Recovery . . . . . . . . . . 365 . 366 . 371 . . . . . . . . vi 333 335 337 341 342 356 358 373 373 375 376 Administration Guide Design and Implementation Frequency of Backups and Time Required . . . . . . . . . . . Recovery Time Required . . . . . . Storage Considerations . . . . . . . Keeping Related Data Together . . . . Restrictions on Using Different Operating Systems . . . . . . . . . . . . Damaged Table Space Recovery . . . . Recovery Performance Considerations Disaster Recovery Considerations . . . . Reducing the Impact of Media Failure. . . Protecting Against Disk Failure . . . . Reducing the Impact of Transaction Failure System Clock Synchronization in a Partitioned Database System . . . . . . Crash Recovery . . . . . . . . . . Getting to a Consistent Database . . . Transaction Failure Recovery in a Partitioned Database Environment . . . Identifying the Failed Database Partition Server . . . . . . . . . . . . Recovery Method: Version Recovery . . . Backing Up a Database. . . . . . . Restoring a Database . . . . . . . Recovery Method: Roll-Forward Recovery Backup Considerations . . . . . . . Restore Considerations . . . . . . . Rolling Forward Changes in a Database Recovery History File Information . . . . Garbage Collection . . . . . . . . . DB2 Data Links Manager Considerations Crash Recovery Considerations . . . . Backup Utility Considerations . . . . Restore and Rollforward Utility Considerations . . . . . . . . . Restoring Databases from an offline Backup without Rolling Forward . . . Restoring Databases and Table Spaces and Rolling Forward to the End of the Logs . . . . . . . . . . . . . Restoring Databases and Table Spaces and Rolling Forward to a Point in Time DB2 Data Links Manager and Recovery Interactions . . . . . . . . . . Removing a Table from the Datalink_Reconcile_Not_Possible State Reconciling Data Links . . . . . . . ADSTAR Distributed Storage Manager . . 376 378 378 379 380 380 382 384 384 385 387 387 389 389 390 393 394 394 400 406 407 410 413 435 436 440 440 442 442 444 445 445 446 449 450 452
  8. 8. Setting up an ADSTAR Distributed Storage Manager Client for UNIX-Based Platforms . . . . . . . . . . . 452 Setting up an ADSTAR Distributed Storage Manager Client for Other Platforms . . . . . . . . . . . 453 Considerations for Using ADSTAR Distributed Storage Manager . . . . . 454 Part 3. Distributed Transaction Processing . . . . . . . . . . 463 Chapter 10. Distributed Databases . . . Using a Single Database in a Transaction Using Multiple Databases in a Single Transaction. . . . . . . . . . . . Updating a Single Database . . . . . Updating Multiple Databases . . . . Other Configuration Considerations in Any Environment . . . . . . . . . . . Host or AS/400 Applications Which Access a DB2 Universal Database Server in a Multisite Update . . . . . . . Understanding the Two-Phase Commit Process . . . . . . . . . . . . . Recovering from Problems During Two-Phase Commit . . . . . . . . . Manual Recovery of Indoubt Transactions . . . . . . . . . . Resynchronizing Indoubt Transactions if AUTORESTART=OFF . . . . . . . Recovery of Indoubt Transactions on the Host . . . . . . . . . . . . . . Recovery when DB2 Connect Has the DB2 Syncpoint Manager Configured Recovery when DB2 Connect Does Not Use the DB2 Syncpoint Manager . . . Chapter 11. Using DB2 with an XA-Compliant Transaction Manager . Setting Up a Database as a Resource Manager . . . . . . . . . . Updating Host or AS/400 Database Servers . . . . . . . . . . Database Connection Considerations Making a Heuristic Decision . . . Security Considerations . . . . Configuration Considerations . . XA Function Supported . . . . 465 466 467 467 469 474 477 478 481 482 484 485 485 486 . . 489 . . 490 . . 490 491 . 491 . 494 . 495 . 496 . . . . XA Interface Problem Determination Configuring XA Transaction Managers to Use DB2 UDB . . . . . . . . . . . Configuring IBM TXSeries CICS. . . . Configuring IBM TXSeries Encina . . . Configuring BEA Tuxedo . . . . . . Configuring Microsoft Transaction Server Part 4. Ensuring the High Availability of Your System 499 500 501 501 504 505 . . . 513 Chapter 12. High Availability Cluster Multi-Processing (HACMP) on AIX . Hot Standby . . . . . . . . . Examples . . . . . . . . . Mutual Takeover . . . . . . . . Examples . . . . . . . . . Additional HACMP Resources . . . . . . . . . . . . . . . Chapter 13. High Availability Cluster Multi-Processing, Enhanced Scalability (HACMP ES) for AIX . . . . . . . . Cluster Configuration . . . . . . . . Configuration of a DB2 Database Partition. . . . . . . . . . . . Example of a Mutual Takeover Configuration . . . . . . . . . . Example of a Hot Standby Takeover Configuration . . . . . . . . . . Configuration of a NFS Server Node Example of a NFS Server Takeover Configuration . . . . . . . . . . Considerations When Configuring the SP Switch . . . . . . . . . . . . DB2 HACMP Configuration Examples DB2 HACMP Startup Recommendations HACMP ES Event Monitoring and User-Defined Events . . . . . . . . HACMP ES Script Files . . . . . . DB2 Recovery Scripts Operations with HACMP ES . . . . . . . . . . Other Script Utilities . . . . . . . Monitoring HACMP Clusters . . . . . DB2 SP HACMP ES Installation . . . . . DB2 SP HACMP ES New Installation DB2 SP HACMP ES Migration . . . . DB2 SP HACMP ES Worksheets. . . . Contents 515 516 516 519 520 522 523 524 529 530 530 531 532 532 534 543 544 547 550 552 552 554 554 556 557 vii
  9. 9. Chapter 14. High Availability in the Windows NT Environment . . . . . . Failover Configurations . . . . . . . Hot Standby Configuration . . . . . Mutual Takeover Configuration . . . . Using the DB2MSCS Utility . . . . . . Specifying the DB2MSCS.CFG File . . . Setting up Failover for a Single-Partition Database System . . . . . . . . . Setting up a Mutual Takeover Configuration for Two Single-Partition Database Systems . . . . . . . . Setting up Multiple MSCS Clusters for a Partitioned Database System . . . . . Maintaining the MSCS System . . . . . Fallback Considerations . . . . . . . Registering Database Drive Mapping for Mutual Takeover Configurations in a Partitioned Database Environment . . . . Reconciling Database Drive Mapping Example - Setting up Two Single-Partition Instances for Mutual Takeover . . . . . Preliminary Tasks . . . . . . . . Run the DB2MSCS Utility . . . . . . Example - Setting up a Four-Node Partitioned Database System for Mutual Takeover . . . . . . . . . . . . Preliminary Tasks . . . . . . . . Run the DB2MSCS Utility . . . . . . Register the Database Drive Mapping for ClusterA . . . . . . . . . . . Register the Database Drive Mapping for ClusterB. . . . . . . . . . . . Administering DB2 in an MSCS Environment . . . . . . . . . . . Starting and Stopping DB2 Resources Running Scripts . . . . . . . . . Database Considerations . . . . . . User and Group Support . . . . . . Communications Considerations . . . System Time Considerations . . . . . Administration Server and Control Center Considerations in a Partitioned Database Environment . . . . . . . Limitations and Restrictions . . . . . Chapter 15. High Availability in the Solaris Operating Environment, Single-Partition Database . . . . Cluster Components . . . . . . viii . . 565 566 566 567 568 569 573 574 574 576 577 577 579 580 580 581 582 583 584 585 586 586 586 587 591 591 592 593 593 595 . 597 . 597 Administration Guide Design and Implementation Failover Configurations . . . . . . Hot Standby Configuration . . . . Mutual Takeover Configuration . . . Setting up Failover Support for a Database System . . . . . . . . . . . . Choosing a Failover Configuration . . Creating a DB2 Instance . . . . . Registering the DB2 Resource with Sun Cluster . . . . . . . . . . . Enable Failover for an Instance . . . Starting and Stopping DB2 . . . . Running Scripts During a Failover . . Unregistering DB2 for Failover . . . Client Application Considerations . . . . 600 . 600 . 600 . 601 . 601 . 602 . . . . . . Chapter 16. High Availability in the Solaris Operating Environment, Partitioned Database . . . . . . . . Cluster Components . . . . . . . . Failover Configurations . . . . . . . Hot Standby Configuration . . . . . Mutual Takeover Configuration . . . . Setting Up Failover Support for a Database System . . . . . . . . . . . . . Choosing a Failover Configuration . . . Preliminary Requirements . . . . . . Scripts and Programs . . . . . . . Creating a DB2 Instance . . . . . . Registering the DB2 Resource with Sun Cluster 2.1 . . . . . . . . . . . Enabling Failover for an Instance . . . Binding Database Partition Servers to a Logical Host . . . . . . . . . . How Failover Processing Works . . . . Setting Up a Hot Standby Configuration Setting Up a Mutual Takeover Configuration . . . . . . . . . . Starting and Stopping DB2 . . . . . Running Scripts During a Failover . . . Considerations for Table Spaces . . . . . Client Application Considerations . . . . 604 605 605 605 606 606 607 607 609 610 611 613 614 615 615 616 616 617 618 618 619 619 619 620 620 621 Part 5. Appendixes . . . . . . . 623 Appendix A. How the DB2 Library Is Structured . . . . . . . . . . . Completing Tasks with SmartGuides . . Accessing Online Help . . . . . . . DB2 Information – Hardcopy and Online Viewing Online Information . . . . . . 625 . 625 . 626 628 . 635
  10. 10. Accessing Information with Information Center . . . Setting Up a Document Server Searching Online Information Printing the PostScript Books. Ordering the Printed Books . the . . . . . . . . . . . . . . . . . . . . . . . . . 636 637 638 638 639 Appendix B. Planning Database Migration Migration Considerations . . . . . . . Migration Restrictions . . . . . . . Security and Authorization . . . . . Storage Requirements . . . . . . . Release-to-Release Incompatibilities . . Migrating a Database . . . . . . . 641 642 642 642 643 643 643 Appendix C. Incompatibilities Between Releases . . . . . . . . . . . . DB2 Universal Database Planned Incompatibilities . . . . . . . . . . Read-only Views in a Future Version of DB2 Universal Database . . . . . . PK_COLNAMES and FK_COLNAMES in a Future Version of DB2 Universal Database . . . . . . . . . . . COLNAMES No Longer Available in a Future Version of DB2 Universal Database . . . . . . . . . . . DB2 Universal Database Version 6 Incompatibilities . . . . . . . . . . System Catalog Views . . . . . . . Application Programming . . . . . . SQL . . . . . . . . . . . . . Database Security and Tuning . . . . Utilities and Tools . . . . . . . . Connectivity and Coexistence . . . . Configuration Parameters . . . . . . DB2 Universal Database Version 5 Incompatibilities . . . . . . . . . . System Catalog Views . . . . . . . Application Programming . . . . . . SQL . . . . . . . . . . . . . Database Security and Tuning . . . . Utilities and Tools . . . . . . . . Connectivity and Coexistence . . . . Configuration Parameters . . . . . . Appendix D. Naming Rules . . . Database Names . . . . . . . Database and Database Alias Names User IDs and Passwords . . . . . . . . . . . . . . . . 647 648 648 648 649 649 650 657 663 665 666 667 667 668 668 670 679 685 685 686 686 691 691 691 692 Schema Names . . . . . . . Group and User Names . . . . Object Names . . . . . . . . Federated Database Object Names . How Case-Sensitive Values Are Preserved in a Federated System . . . . . . . . . . . . . . . 696 Appendix E. Using Distributed Computing Environment (DCE) Directory Services Creating Directory Objects . . . . . . Database Objects . . . . . . . . . Database Locator Objects . . . . . . Routing Information Objects . . . . . Attributes of Each Object Class . . . . . Details About Each Attribute . . . . . Directory Services Security . . . . . . Configuration Parameters and Registry Variables . . . . . . . . . . . . CATALOG and ATTACH Commands, and the CONNECT Statement . . . . . . . CATALOG GLOBAL DATABASE Command . . . . . . . . . . . CONNECT Statement . . . . . . . ATTACH Command . . . . . . . How a Client Connects to a Database . . . Connecting to Databases in the Same Cell . . . . . . . . . . . . . Connecting to a Database in a Different Cell . . . . . . . . . . . . . How Directories are Searched . . . . . ATTACH Command . . . . . . . CONNECT Statement . . . . . . . Temporarily Overriding DCE Directory Information . . . . . . . . . . . Directory Services Tasks . . . . . . . DCE Administrator Tasks . . . . . . Database Administrator Tasks . . . . Database User Tasks . . . . . . . Directory Services Restrictions . . . . . Appendix F. X/Open Distributed Transaction Processing Model Application Program (AP). . . Transaction Manager (TM) . . Resource Managers (RM) . . . . . . . 693 693 694 695 699 699 700 701 703 704 705 709 711 713 713 713 713 714 716 717 718 718 719 720 721 721 722 723 724 . . . . . . . . . . . . Appendix G. User Exit for Database Recovery . . . . . . . . . . Overview for OS/2 . . . . . . . . . . 733 . 733 Contents 727 727 729 730 ix
  11. 11. Overview for UNIX-Based Operating Systems . . . . . . . . . . . . . Invoking a User Exit Program . . . . . Sample User Exit Programs . . . . . . Sample User Exit Programs for OS/2 Sample User Exit Programs for UNIX-Based Operating Systems . . . . Calling Format . . . . . . . . . . Calling Format for OS/2 . . . . . . Calling Format for UNIX-Based or Windows NT Operating Systems . . . Archive and Retrieve Considerations . . . Backup and Restore Considerations (DB2 for OS/2 only) . . . . . . . . . Error Handling . . . . . . . . . . Appendix H. National Language Support (NLS) . . . . . . . . . . . . . Deriving Code Page Values . . . . . . Deriving Locales in Application Programs How DB2 Derives Locales. . . . . . Country Code and Code Page Support . . Unicode/UCS-2 and UTF-8 Support in DB2 UDB . . . . . . . . . . . . . . Introduction . . . . . . . . . . UCS-2/UTF-8 Implementation in DB2 UDB . . . . . . . . . . . . . Character Sets . . . . . . . . . . . DBCS Character Sets . . . . . . . Extended UNIX Code (EUC) Character Sets . . . . . . . . . . . . . Character Set for Identifiers . . . . . Coding of SQL Statements . . . . . Bidirectional CCSID Support . . . . . Collating Sequences . . . . . . . . Datetime Values . . . . . . . . . Appendix I. Issuing Commands to Multiple Database Partition Servers . . . Commands. . . . . . . . . . . . Command Descriptions . . . . . . Specifying the Command to Run . . . Running Commands in Parallel on UNIX-Based Platforms . . . . . . . Monitoring rah Processes on UNIX-Based Platforms . . . . . . . . . . . Additional Rah (Run All Hosts) Information (Solaris and AIX only) . . . Prefix Sequences . . . . . . . . . . Specifying the List of Machines . . . . . x 734 734 735 735 736 737 737 738 739 741 742 745 745 746 746 747 761 761 763 770 770 771 772 773 773 777 784 791 791 792 793 794 794 795 796 799 Administration Guide Design and Implementation Eliminating Duplicate Entries from the List of Machines . . . . . . . . Controlling the rah Command . . . . $RAHDOTFILES on UNIX-Based Platforms . . . . . . . . . . Setting the Default Environment Profile on Windows NT . . . . . . . . Determining Problems with rah on UNIX-Based Platforms . . . . . . . Appendix J. How DB2 for Windows NT Works with Windows NT Security . . A Sample Scenario with Server Authentication: . . . . . . . . . A Sample Scenario with Client Authentication and a Windows NT Client Machine: . . . . . . . . . . . A Sample Scenario with Client Authentication and a Windows 95 Client Machine: . . . . . . . . . . . Using a Backup Domain Controller with DB2 . . . . . . . . . . . . . Appendix K. Using the Windows NT Performance Monitor . . . . . . . Registering DB2 with the Windows NT Performance Monitor . . . . . . . Enable Remote Access to DB2 Performance Information . . . . . . . . . . Displaying DB2 and DB2 Connect Performance Values . . . . . . . . Accessing Remote DB2 Performance Information . . . . . . . . . . Resetting DB2 Performance Values . . . . 800 . 800 . 802 . 803 . 803 . 807 . 808 . 808 . 809 . 810 . 811 . 811 . 812 . 813 . 814 . 814 Appendix L. Configuring Multiple Logical Nodes . . . . . . . . . . . . . 817 Appendix M. Using Virtual Interface (VI) Architecture . . . . . . . . . . . Overview of DB2 UDB Extended Enterprise Edition . . . . . . . . . . . . . Running DB2 UDB for Windows NT with GigaNet Interconnect . . . . . . . . Setup Procedure for GigaNet Interconnect . . . . . . . . . . Running DB2 UDB for Windows NT with ServerNet Interconnect . . . . . . . . Setup Procedure for ServerNet Interconnect . . . . . . . . . . 819 820 821 821 823 823
  12. 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 835 836 836 Appendix P. Notices . . . . Trademarks . . . . . . . Trademarks of Other Companies . . . . . . . . . . 861 . 862 . 862 837 Index . . . . . . . . . . 865 837 Contacting IBM . . . . . . . . . . 883 Install DB2 Universal Database Version 5.2 or Later (EEE) . . . . . . . . . . . 826 Implement DB2 to Run Using VI . . . 828 Appendix N. Lightweight Directory Access Protocol (LDAP) Directory Services . . . . . . . . . . . . Registration of DB2 Servers After Installation . . . . . . . . . . . . Update the Protocol Information for the DB2 Server . . . . . . . . . . . . Catalog a Node Alias for ATTACH . . . . Deregistering the DB2 Server. . . . . . Registration of Databases . . . . . . . Attaching to a Remote Server . . . . . Deregistering the Database . . . . . . Refreshing LDAP Entries in Local Database and Node Directories . . . . . . . . Searching . . . . . . . . . . . . Configure Host Database . . . . . . . Setting DB2 Registry Variables at the User Level . . . . . . . . . . . . . . Enable LDAP Support After Installation is Complete . . . . . . . . . . . . Disable LDAP Support . . . . . . . . Security Considerations . . . . . . . Managing Multiple User Accounts . . . . Extending the Directory Schema with DB2 Object Classes and Attributes . . . . . Extending the Directory Schema for IBM eNetwork Directory Version 2.1 . . . . Object Classes and Attributes Used by DB2 . . . . . . . . . . . . . Appendix O. Extending the Control Center . . . . . . . . . . . . 829 829 831 831 831 832 832 833 833 834 834 835 Performance Considerations Packaging Considerations . Interface Descriptions . . CCExtension . . . . CCObject . . . . . CCMenuAction . . . CCToolBarAction. . . Usage Scenario . . . . MyExtension.java . . MySample.java . . . MyDatabaseActions.java MyInstance.java . . . MyDB2.java . . . . MyDatabases.java . . MySYSPLAN.java . . MyTable.java . . . . MyDBUser.java . . . MyToolbarAction.java . MyAlterAction.java . . MyAction.java. . . . MyDropAction.java . . MyCascadeAction.java . MyCreateAction.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 845 845 845 846 847 850 850 851 852 852 853 854 854 855 856 856 857 858 858 858 859 859 859 838 . 845 Contents xi
  13. 13. xii Administration Guide Design and Implementation
  14. 14. About This Book The Administration Guide in its two volumes provides information necessary to use and administer the year 2000 ready, DB2* relational database management system (RDBMS) products, including: v Information required for designing, implementing and managing databases (found in Administration Guide, Design and Implementation) v Information regarding the configuring and tuning of your database environment to improve performance (found in Administration Guide, Performance). Many of the tasks described in this book can be performed using different interfaces: v The Command Processor, which allows you to access and manipulate databases from a graphical interface. From this interface, you can also execute SQL statements and DB2 utility functions. Most examples in this book illustrate the use of this interface. For more information about using the command processor, see the Command Reference manual. v The application programming interface, which allows you to execute DB2 utility functions within an application program. For more information about using the application programming interface, see the Administrative API Reference manual. v The Control Center, which allows you to graphically perform administrative tasks such as configuring the system, managing directories, backing up and recovering the system, scheduling jobs, and managing media. The Control Center also contains Replication Administration to graphically setup the replication of data between systems. execute DB2 utility functions through a graphical user interface. To invoke the Control Center, use the db2cc command, or (for OS/2) select the Control Center icon from the DB2 folder. For introductory help, select Getting started from the Help pull-down of the Control Center window. The Visual Explain and Performance Monitor tools are invoked from the Control Center. Error conditions when using the Control Center are recorded in the Control Center Administration Engine Log (db2cc.log). This log records information about the errors generated while using the Control Center. The log is always active while the Control Center is active. The log file is kept in the home directory of the executable that invokes the Control Center. That is, in the bin subdirectory of the sqllib subdirectory. The file can be viewed and updated using an ASCII file editor. The log file records the error message type, a time stamp, a process identifier (PID), a thread identifier (TID), and an SQL error message. The © Copyright IBM Corp. 1993, 1999 xiii
  15. 15. process ID and the thread ID are used to identify the operating system that generated the log. Combined with the Control Center trace information, DB2 Service and Support personnel are able to determine which Control Center task caused the error. The information is only of use to the DB2 Service and Support personnel. The log file can be edited by an ASCII file editor to remove log records that are no longer needed. There are other tools available that you can use to perform administration tasks. They include: v The Script Center to store small applications called scripts. These scripts may contain DB2 commands as well as operating system commands. v The Alert Center to monitor the messages that result from other DB2 operations. v The Tool Settings to change the settings for the Control Center, Alert Center, and Replication. v The Journal to schedule jobs to run unattended. Who Should Use This book This book is intended primarily for database administrators, system administrators, security administrators and system operators who need to design, implement and maintain a database to be accessed by local or remote clients. It can also be used by programmers and other users who require an understanding of the administration and operation of the DB2 relational database management system. How This Book is Structured The Administration Guide, Design and Implementation contains information about the following major topics: Database Concepts v Chapter 1. Introduction to Concepts Within DB2 Universal Database, presents an overview of DB2 Universal Database including: Using the Control Center, the types of parallelism provided by DB2, and federated systems use. Database Design and Implementation v Chapter 2. Designing Your Logical Database, discusses the concepts and guidelines for designing a logical database. xiv Administration Guide Design and Implementation
  16. 16. v Chapter 3. Designing Your Physical Database, discusses the guidelines for designing a physical database, including considerations related to physical data storage. v Chapter 4. Implementing Your Design, discusses the concepts and guidelines for creating a database and the objects within a database. v Chapter 5. Administering DB2 Using GUI Tools, introduces the Graphical User Interface (GUI) tools used to administer the database. v Chapter 6. Controlling Database Access, describes how you can control access to your database’s resources. v Chapter 7. Auditing DB2 Activities, describes how you can detect and monitor unwanted or unanticipated access to data. v Chapter 8. Utilities for Moving Data, discusses the LOAD, AutoLoader, IMPORT and EXPORT utilities. db2move and replication are also discussed. v Chapter 9. Recovering a Database, discusses factors to consider when choosing database and table space recovery methods, including backing up and restoring a database or table space, and using the roll-forward recovery method. Distributed Transaction Processing v Chapter 10. Distributed Databases, discusses how you can access multiple databases in a single transaction. v Chapter 11. Using DB2 with an XA-Compliant Transaction Manager, discusses how you can use your databases in a distributed transaction processing environment such as CICS. High Availability Systems v Chapter 12. High Availability Cluster Multi-Processing (HACMP) on AIX, discusses the support of IBM High Availability Cluster Multi-Processing (HACMP) for AIX by DB2. v Chapter 13. High Availability Cluster Multi-Processing, Enhanced Scalability (HACMP ES) for AIX, discusses the support of IBM High Availability Cluster Multi-Processing, Enhanced Scalability (HACMP ES) for AIX by DB2. v Chapter 14. High Availability in the Windows NT Environment, discusses the support of Microsoft Cluster Server for Windows NT by DB2. v Chapter 15. High Availability in the Solaris Operating Environment, Single-Partition Database, discusses the support of Sun Cluster 2.1 for the Sun Solaris Operating System by DB2. v Chapter 16. High Availability in the Solaris Operating Environment, Partitioned Database, discusses the support of Sun Cluster 2.1 for the Sun Solaris Operating System by DB2 Enterprise - Extended Edition. Appendixes About This Book xv
  17. 17. v Appendix A. How the DB2 Library Is Structured, provides information about the structure of the DB2 library, including SmartGuides, online help, messages, and books. v Appendix B. Planning Database Migration, provides information about migrating databases to Version 5. v Appendix C. Incompatibilities Between Releases, presents the incompatibilities introduced with Version 5. v Appendix D. Naming Rules, provides the rules to follow when naming databases and objects. v Appendix E. Using Distributed Computing Environment (DCE) Directory Services, provides information about how you can use DCE Directory Services. v Appendix F. X/Open Distributed Transaction Processing Model, provides an overview of the X/Open Distributed Transaction Processing model and the DB2 database support provided. v Appendix G. User Exit for Database Recovery, discusses how user exit programs can be used with database log files and describes some sample user exit programs. v Appendix H. National Language Support (NLS), introduces DB2 National Language Support (NLS) including information about countries, languages, and code pages. v Appendix I. Issuing Commands to Multiple Database Partition Servers, discusses the use of the db2_all and rah shell scripts to send commands to all partitions in a partitioned database environment. v Appendix J. How DB2 for Windows NT Works with Windows NT Security, describes how DB2 works with Windows NT security. v Appendix L. Configuring Multiple Logical Nodes, describes how to configure multiple logical nodes in a partitioned database environment. v Appendix M. Using Virtual Interface (VI) Architecture, describes how to enable Virtual Interface Architecture for use with DB2 Enterprise - Extended Edition in the Windows NT environment. v Appendix N. Lightweight Directory Access Protocol (LDAP) Directory Services, provides information about how you can use Lightweight Directory Access Protocol (LDAP) Directory Services. v Appendix O. Extending the Control Center, provides information about how you can extend the Control Center by adding new tool bar buttons including new actions, adding new object definitions, and adding new action definitions. The other volume of the Administration Guide (Administration Guide, Performance) is concerned with performance issues. That is, those topics and issues concerned with establishing, testing, and improving all aspects of your application’s, and the DB2 Universal Database product, performance. xvi Administration Guide Design and Implementation
  18. 18. The specific chapters and appendixes in that volume are briefly described here: Introduction to Performance v Elements of Performance, introduces concepts and considerations for managing and improving DB2 UDB performance. Tuning Application Performance v Application Considerations, describes some techniques for improving database performance when designing your applications. v Environmental Considerations, describes some techniques for improving database performance when setting up your database environment. v System Catalog Statistics, describes how statistics about your data can be collected and used to ensure optimal performance. v Understanding the SQL Compiler, describes what happens to an SQL statement when it is compiled using the SQL compiler. v SQL Explain Facility, describes the Explain facility, which allows you to examine the choices the SQL compiler has made to access your data. Tuning and Configuring Your System v Operational Performance, provides an overview of how the database manager uses memory and other considerations that affect run-time performance. v Using the Governor, provides an introduction to the use of a governor to control some aspects of database management. v Scaling Your Configuration, introduces some considerations and tasks associated with increasing the size of your database systems. v Redistributing Data Across Database Partitions, discusses the tasks required in a partitioned database environment to redistribute data across partitions. v Benchmark Testing, provides an overview of benchmark testing and how to perform benchmark testing. v Configuring DB2, discusses the database manager and database configuration files and the values for the configuration parameters. Appendixes v DB2 Registry and Environment Variables, presents profile registry values and environment variables. v Sample Tables, contains a description of the sample tables provided with the database manager. v Catalog Views, contains a description of each system catalog view, including column names and data types. About This Book xvii
  19. 19. v Explain Tables and Definitions, provides information about the tables used by the DB2 Explain facility and how to create those tables. v SQL Explain Tools, provides information on using the DB2 explain tools: db2expln and dynexpln. v db2exfmt — Explain Table Format Tool, provides information on using the DB2 explain tool to format the explain table data. xviii Administration Guide Design and Implementation
  20. 20. Part 1. Database Concepts © Copyright IBM Corp. 1993, 1999 1
  21. 21. 2 Administration Guide Design and Implementation
  22. 22. Chapter 1. Introduction to Concepts Within DB2 Universal Database This chapter provides an introduction to DB2 Universal Database and to the types of parallelism provided by DB2. This chapter describes the following: v Overview of basic DB2 concepts and DB2 parallelism concepts v Types of parallelism v Hardware environments v Summary of parallelism possible for each hardware environment v Enabling parallelism v Overview of federated database system concepts v Enabling federated database systems DB2 provides the flexibility for you to run a wide range of hardware configurations. It allows you to choose how to best match your hardware and application requirements with a specific DB2 product configuration. The remaining chapters in this book assist you in the design and implementation of your database. With the different levels of complexity in database environments that DB2 supports, there are considerations and tasks specific to one or more of these environments. These considerations and tasks are presented toward the end of each section or chapter and introduced as being for a specific environment. In some cases, entire sections or chapters are appropriate for only a specific environment. After reading this chapter, you should be able to discern which chapters are appropriate for your business needs and your environment. Overview of DB2 Concepts A database manager (sometimes called an instance) is DB2 code that manages data. It controls what can be done to the data, and manages system resources assigned to it. Each instance is a complete environment. It contains all the database partitions defined for a given parallel database system. An instance has its own databases (which other instances cannot access), and all its database partitions share the same system directories. It also has separate security from other instances on the same machine. A nodegroup is a set of one or more database partitions. When you want to create tables for the database, you first create the nodegroup where the table spaces will be stored, then you create the table space where the tables will be © Copyright IBM Corp. 1993, 1999 3
  23. 23. stored. See “Nodegroups and Data Partitioning” on page 6 for more information about nodegroups. See “Overview of DB2 Parallelism Concepts” on page 5 for the definition of a database partition. A database is organized into parts called table spaces. A table space’s definition and attributes are recorded in the database system catalog. Once a table space is created, you can then create tables within this table space. A container is assigned to a table space. A container is an allocation of physical storage (such as a file or device). Table spaces reside in nodegroups. A table consists of data logically arranged in columns and rows. The data in the table is logically related, and relationships can be defined between tables. Data can be viewed and manipulated based on mathematical principles and operations called relations. Table data is accessed via SQL, a standardized language for defining and manipulating data in a relational database. All database and table data is assigned to table spaces. A query is used in applications or by users to retrieve data from a database. The query uses Structured Query Language (SQL) to create a statement in the form of SELECT <data_name> FROM <table_name> In this chapter we use the term “query” to identify a retrieval request (a SELECT statement) from a database. Figure 1 on page 5 illustrates the relationship among the objects just described. It also illustrates that tables, indexes, and long data are stored in table spaces. 4 Administration Guide Design and Implementation
  24. 24. System Instance(s) Database(s) Nodegroup(s) Table space tables index(es) long data Figure 1. Relationship Among Some Database Objects Overview of DB2 Parallelism Concepts DB2 extends the database manager to the parallel, multi-node environment. A database partition is a part of a database that consists of its own data, indexes, configuration files, and transaction logs. A database partition is sometimes called a node or database node. (Node was the term used in the DB2 Parallel Edition for AIX Version 1 product.) Chapter 1. Introduction to Concepts Within DB2 Universal Database 5
  25. 25. A single-partition database is a database having only one database partition. All data in the database is stored in that partition. In this case nodegroups, while present, provide no additional capability. A partitioned database is a database with two or more database partitions. Tables can be located in one or more database partitions. When a table is in a nodegroup consisting of multiple partitions, some of its rows are stored in one partition and others are stored in other partitions. Usually, a single database partition exists on each physical node and the processors on each system are used by the database manager at each database partition to manage its part of the database’s total data. Because data is divided across database partitions, you can use the power of multiple processors on multiple physical nodes to satisfy requests for information. Data retrieval and update requests are decomposed automatically into sub-requests and executed in parallel among the applicable database partitions. The fact that databases are split across database partitions is transparent to users of SQL statements. User interaction is through one database partition. It is known as the coordinator node for that user. The coordinator runs on the same database partition as the application, or in the case of a remote application, the database partition to which that application is connected. Any database partition can be used as a coordinator node. Nodegroups and Data Partitioning You can define named subsets of one or more database partitions in a database. Each subset you define is known as a nodegroup. Each subset that contains more than one database partition is known as a multi-partition nodegroup. Multi-partition nodegroups can only be defined with database partitions that belong to the same instance. Figure 2 on page 7 shows an example of a database with five partitions in which: v v v v A nodegroup spans all but one of the database partitions (Nodegroup 1). A nodegroup contains one database partition (Nodegroup 2). A nodegroup contains two database partitions. The database partition within Nodegroup 2 is shared (and overlaps) with Nodegroup 1. v There is a single database partition within Nodegroup 3 that is shared (and overlaps) with Nodegroup 1. 6 Administration Guide Design and Implementation
  26. 26. Database Nodegroup 2 Database Partition Nodegroup 1 Database Partition Database Partition Database Partition Nodegroup 3 Database Partition Figure 2. Nodegroups in a Database You create a new nodegroup using the CREATE NODEGROUP statement. Refer to the SQL Reference for more information. Data is divided across all the partitions in a nodegroup. If you are using a multi-partition nodegroup, you must look at several nodegroup design considerations. For more information in both of these areas, see “Designing Nodegroups” on page 67. Types of Parallelism Parts of a database-related task (such as a database query) can be executed in parallel in order to speed up the task, often dramatically so. There are different ways a task is performed in parallel. The nature of the task, the database configuration, and the hardware environment determine how DB2 will perform a task in parallel. These considerations are interrelated. You should consider them together when first deciding on the physical and logical design of a database. This section describes the types of parallelism. Chapter 1. Introduction to Concepts Within DB2 Universal Database 7
  27. 27. DB2 supports the following types of parallelism: v I/O v Query v Utility I/O Parallelism For situations in which multiple containers exist for a table space, the database manager can initiate parallel I/O. Parallel I/O refers to the process of reading from or writing to two or more I/O devices at the same time to reduce elapsed time. Performing I/O in parallel can result in significant improvements to I/O throughput. I/O parallelism is a component of each hardware environment described in “Hardware Environments” on page 12. Table 1 on page 20 lists the hardware environments best suited for I/O parallelism. Query Parallelism There are two types of query parallelism: inter-query parallelism and intra-query parallelism. Inter-query parallelism refers to the ability of multiple applications to query a database at the same time. Each query will execute independently of the others, but DB2 will execute all of them at the same time. DB2 has always supported this type of parallelism. Intra-query parallelism refers to the processing of parts of a single query at the same time using either intra-partition parallelism or inter-partition parallelism or both. The term query parallelism is used throughout this book. Intra-Partition Parallelism Intra-partition parallelism refers to the ability to break up a query into multiple parts. (Some of the utilities also perform this type of parallelism. See “Utility Parallelism” on page 11.) Intra-partition parallelism subdivides what is usually considered a single database operation such as index creation, database load, or SQL queries into multiple parts, many or all of which can be executed in parallel within a single database partition. 8 Administration Guide Design and Implementation
  28. 28. SELECT... FROM... A query is divided into parts, each being executed in parallel. Data Database Partition Figure 3. Intra-Partition Parallelism Figure 3 shows a query that is broken into four pieces that can be executed in parallel, with the results returned more quickly than if the query was run in a serial fashion. The pieces are copies of each other. To utilize intra-partition parallelism, you need to configure the database appropriately. You can choose the degree of parallelism or let the system do it for you. The degree of parallelism is the number of pieces of a query that execute in parallel. Table 1 on page 20 lists the hardware environments best suited for intra-partition parallelism. Inter-Partition Parallelism Inter-partition parallelism refers to the ability to break up a query into multiple parts across multiple partitions of a partitioned database, on one machine or multiple machines. The query is performed in parallel. (Some of the utilities also perform this type of parallelism. See “Utility Parallelism” on page 11.) Inter-partition parallelism subdivides what is usually considered a single database operation such as index creation, database load, or SQL queries into multiple parts, many or all of which can be executed in parallel across multiple partitions of a partitioned database in one machine or multiple machines. Chapter 1. Introduction to Concepts Within DB2 Universal Database 9
  29. 29. SELECT... FROM... A query is divided into parts, each being executed in parallel. Data Data Data Data Database Partition Database Partition Database Partition Database Partition Figure 4. Inter-Partition Parallelism Figure 4 shows a query that is broken into four pieces that can be executed in parallel, with the results returned more quickly than if the query was run in a serial fashion in a single partition. The degree of parallelism is largely determined by the number of partitions you create and how you define your nodegroups. Table 1 on page 20 lists the hardware environments best suited for inter-partition parallelism. Using Both Intra-Partition and Inter-Partition Parallelism You can use intra-partition parallelism and inter-partition parallelism at the same time. This combination provides, in effect, two dimensions of parallelism. This results in an even more dramatic increase in the speed at which queries are processed. Figure 5 on page 11 illustrates this. 10 Administration Guide Design and Implementation
  30. 30. SELECT... FROM... SELECT... FROM... SELECT... FROM... A query is divided into parts, each being executed in parallel. Data Data Database Partition Database Partition Figure 5. Both Inter-Partition and Intra-Partition Parallelism Utility Parallelism DB2’s utilities can take advantage of intra-partition parallelism. They can also take advantage of inter-partition parallelism; where multiple database partitions exist, the utilities execute in each of the partitions in parallel. The following paragraphs describe how some utilities take advantage of parallelism. The LOAD utility can take advantage of intra-partition parallelism and I/O parallelism. Loading data is a heavily CPU-intensive task. The LOAD utility takes advantage of multiple processors for tasks such as parsing and formatting data. Also, the LOAD utility can use parallel I/O servers to write the data to the containers in parallel. Refer to the Data Movement Utilities Guide and Reference or the LOAD command in the Command Reference for information on how to enable parallelism for the LOAD utility. In a partitioned database environment, the AutoLoader utility takes advantage of intra-partition, inter-partition, and I/O parallelism by parallel invocations of load at each database partition where the table resides. Refer to Data Movement Utilities Guide and Reference for more information about the AutoLoader utility. During index creation, the scanning and subsequent sorting of the data occurs in parallel. DB2 exploits both I/O parallelism and intra-partition parallelism when creating an index. This helps to speed up index creation when a Chapter 1. Introduction to Concepts Within DB2 Universal Database 11
  31. 31. CREATE INDEX command is issued, during restart (if an index is marked invalid), and during the reorganization of data. Backing up and restoring data are heavily I/O bound tasks. DB2 exploits both I/O parallelism and intra-partition parallelism when performing backups and restores. Backup exploits I/O parallelism by reading from multiple table space containers in parallel, and asynchronously writing to multiple backup media in parallel. Refer to the BACKUP DATABASE command and the RESTORE DATABASE command in the Command Reference for information on how to enable parallelism for these two commands. Hardware Environments This section provides an overview of the following hardware environments: v Single partition on a single processor (uniprocessor) v Single partition with multiple processors (SMP) v Multiple partition configurations – Partitions with one processor (MPP) – Partitions with multiple processors (cluster of SMPs) – Logical database partitions (also known as Multiple Logical Nodes (MLN) in DB2 Parallel Edition for AIX Version 1) In each hardware environment section, considerations for capacity and scalability are described. Capacity refers to the number of users and applications able to access the database in large part determined by memory, agents, locks, I/O, and storage management. Scalability refers to the ability for a database to grow and continue to exhibit the same operating characteristics and response times. Single Partition on a Single Processor This environment is made up of memory and disk, but contains only a single CPU. This environment has been given many names such as: standalone database, client/server database, serial database, uniprocessor system, and single node/non-parallel environment. Figure 6 on page 13 illustrates this environment. 12 Administration Guide Design and Implementation
  32. 32. Uniprocessor machine CPU Memory Database Partition Disks Figure 6. Single Partition On a Single Processor The database in this environment serves the needs of a department or small office where the data and system resources (including only a single processor or CPU) are managed by a single database manager. Table 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware configuration. Capacity and Scalability In this environment you can add more disks. Having one or more I/O servers for each disk allows for more than one I/O operation to be taking place at the same time. You can also add more hard disk space to this environment. A single-processor system is restricted by the amount of disk space the processor can handle. However, as workload increases a single CPU may become insufficient in processing user requests any faster, regardless of other additional components, such as memory or disk, that you may add. If you have reached maximum capacity or scalability, you can consider moving to a single partition system with multiple processors. This configuration is described in the next section. Chapter 1. Introduction to Concepts Within DB2 Universal Database 13
  33. 33. Single Partition with Multiple Processors This environment is typically made up of several equally powerful processors within the same machine and is called a symmetric multi-processor (SMP) system. Resources such as disk space and memory are shared. More disks and memory are found in this machine compared to the single-partition database, single processor environment. This environment is easy to manage since physically everything is together in one machine and the sharing of memory and disks is expected. With multiple processors available, different database operations can be completed significantly more quickly than with databases assigned to only a single processor. DB2 can also divide the work of a single query among available processors to improve processing speed. Other database operations such as the LOAD utility, the backup and restore of table spaces, and index creation on existing data can take advantage of the multiple processors. Figure 7 illustrates this environment. SMP machine CPU CPU CPU CPU Memory Database Partition Disks Figure 7. Single Partition Database Symmetric Multiprocessor System Table 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware configuration. 14 Administration Guide Design and Implementation
  34. 34. Capacity and Scalability In this environment you can add more processors. However, since it is possible for the different processors to attempt to access the same data, limitations with this environment can appear as your business operations grow. With shared memory and shared disks, you are effectively sharing all of the database data. One application on one processor may be accessing the same data as another application on another processor, possibly causing the second application to wait for access to the data. You can increase the I/O capacity of the database partition associated with your processor, such as the number of disks. You can establish I/O servers to specifically deal with I/O requests. Having one or more I/O servers for each disk allows for more than one I/O operation to take place at the same time. If you have reached maximum capacity or scalablity, you can consider moving to a system with multiple partitions. These configurations are described in the next section. Multiple Partition Configurations You can divide a database into multiple partitions, each on its own machine. Multiple machines with multiple database partitions can be grouped together. This section describes the following partition configurations: v Partitions on systems each with one processor v Partitions on systems each with multiple processors v Logical database partitions Partitions with One Processor In this environment there are many database partitions with each partition on its own machine and having its own processor, memory, and disks. Figure 8 on page 16 illustrates this. A machine consists of a CPU, memory, and disk with all machines connected by a communications facility. Other names that have been given to this environment include: a cluster, a cluster of uniprocessors, a massively parallel processing (MPP) environment, or a shared-nothing configuration. The latter name accurately reflects the arrangement of resources in this environment. Unlike an SMP environment, an MPP environment has no shared memory or disks. The MPP environment removes the limitations introduced through the sharing of memory and disks. Chapter 1. Introduction to Concepts Within DB2 Universal Database 15
  35. 35. Communications Facility Uniprocessor machine Uniprocessor machine Uniprocessor machine Uniprocessor machine CPU CPU CPU CPU Memory Memory Memory Memory Database Partition Database Partition Database Partition Database Partition Disks Disks Disks Disks Figure 8. Massively Parallel Processing System A partitioned database environment allows a database to remain a logical whole while being physically divided across more than one partition. To applications or users, the database can be used as a whole and the fact that data is partitioned remains transparent to most users. The work to be done with the data can be divided out to each of the database managers. Each database manager in each partition works against its own part of the database. Table 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware configuration. Capacity and Scalability: In this environment you can add more database partitions (nodes) to your configuration. On some platforms, for example the RS/6000 SP, the maximum is 512 nodes. However, there may be practical limits for managing a high number of machines and instances. If you have reached maximum capacity or scalability, you can consider moving to a system where each partition has multiple processors. This configuration is described in the next section. 16 Administration Guide Design and Implementation
  36. 36. Partitions with Multiple Processors As an alternative to a configuration in which each partition has a single processor is a configuration in which a partition has multiple processors. This is known as an SMP cluster. This configuration combines the advantages of SMP and MPP parallelism. This means a query can be performed in a single partition across multiple processors. It also means that a query can be performed in parallel across multiple partitions. Communications Facility SMP machine CPU CPU CPU SMP machine CPU CPU CPU CPU Memory Memory Database Partition Database Partition Disks CPU Disks Figure 9. Cluster of SMPs Table 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware configuration. Capacity and Scalability: In this environment you can add more database partitions, as in the previous section. You can also add more processors to existing database partitions. Chapter 1. Introduction to Concepts Within DB2 Universal Database 17
  37. 37. Logical Database Partitions A logical database partition differs from a physical partition in that it is not given control of an entire machine. Although the machine has shared resources, the database partitions do not share the resources. Processors are shared but disk and memory are not. One reason for using logical database partitions is to provide scalability. Multiple database managers running in multiple logical partitions may be able to make fuller use of available resources than a single database manager could. This will become more true as machines with even more processors are manufactured. Figure 10 illustrates the fact that you may gain more scalability on an SMP machine by adding more partitions, particularly for machines with many processors. By partitioning the database, you can administer and recover each partition separately. Big SMP machine Communications Facility CPU CPU CPU CPU Memory Memory Database Partition 1 Database Partition 2 Disks Disks Figure 10. Partitioned Database, Symmetric Multiprocessor System 18 Administration Guide Design and Implementation
  38. 38. Figure 11 illustrates the fact that you can multiply the configuration shown in Figure 10 on page 18 to increase processing power. Communications Facility Big SMP machine Big SMP machine Communications Facility Communications Facility CPU CPU CPU CPU CPU CPU CPU CPU Memory Memory Memory Memory Database Partition 1 Database Partition 2 Database Partition 3 Database Partition 4 Disks Disks Disks Disks Figure 11. Partitioned Database, Symmetric Multiprocessor Systems Clustered Together Note also that the ability to have two or more partitions coexist on the same machine (regardless of the number of processors) allows greater flexibility in designing high availability configurations and failover strategies. See “Chapter 12. High Availability Cluster Multi-Processing (HACMP) on AIX” on page 515 for a description of how, upon machine failure, a database partition can be automatically moved and restarted on another machine already containing another partition of the same database. Table 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware environment. Summary of Parallelism Best Suited To Each Hardware Environment The following table summarizes the types of parallelism best suited to the various hardware environments. Chapter 1. Introduction to Concepts Within DB2 Universal Database 19
  39. 39. Table 1. Types of Parallelism Possible for Each Hardware Environment Hardware Environment Single Partition, Single Processor I/O Parallelism Yes Intra-Query Parallelism Intra-Partition Inter-Partition Parallelism Parallelism No(1) No Single Partition, Yes Multiple Processors (SMP) Yes No Multiple Partitions, One Processor (MPP) Yes No(1) Yes Multiple Partitions, Multiple Processors (cluster of SMPs) Yes Yes Yes Logical Database Partitions Yes Yes Yes Note: (1) There may be an advantage to setting the degree of parallelism (using one of the configuration parameters) to greater than one even on a single CPU system, especially if the queries you execute are not fully utilizing the CPU (for example if they are I/O bound). Enabling Parallelism for Queries There are two types of query parallelism: intra-partition parallelism and inter-partition parallelism. Either type, or both types, can be used depending on whether the environment is a single-partition or multi-partition environment. Enabling Intra-Partition Query Parallelism In order for intra-partition query parallelism to occur, you must modify database configuration parameters and database manager configuration parameters. INTRA_PARALLEL Database manager configuration parameter. Refer to Administration Guide, Performance for more information on this parameter. DFT_DEGREE Database configuration parameter. Provides the default for the DEGREE bind option and the CURRENT DEGREE special register. Refer to Administration Guide, Performance for more information on this parameter. DEGREE Precompile or bind option for static SQL. Refer to the Command Reference for more information. 20 Administration Guide Design and Implementation
  40. 40. CURRENT DEGREE Special register for dynamic SQL. Refer to the SQL Reference for more information. For more information on the configuration parameter settings, and how to enable applications to process in parallel, refer to ″Configuring DB2″ in the Administration Guide, Performance. Enabling Inter-Partition Query Parallelism Inter-partition parallelism occurs automatically based on the number of database partitions and the distribution of data across these partitions. Enabling Utility Parallelism This section provides an overview of how to enable intra-partition parallelism for the following utilities: v Load v Create index v Backup database / table space v Restore database / table space Inter-partition parallelism for utilities occurs automatically based on the number of database partitions. Load The Load utility automatically makes use of parallelism, or you can use the following parameters on the LOAD command: v CPU_PARALLELISM v DISK_PARALLELISM Refer to the Data Movement Utilities Guide and Reference for information on the LOAD command. AutoLoader You can enable multiple split processes for the AutoLoader by specifying the MODIFIED BY ANYORDER parameter for the LOAD specification in the autoloader.cfg file. Refer to Administration Guide, Performance for more information on this LOAD specification and the configuration file. Create Index To enable parallelism when creating an index: Chapter 1. Introduction to Concepts Within DB2 Universal Database 21
  41. 41. v The INTRA_PARALLEL database manager configuration parameter must be ON v The table must be large enough to benefit from parallelism v Multiple processors must be enabled on an SMP machine. Refer to the SQL Reference for information on the CREATE INDEX statement. Backup Database / Table Space To enable I/O parallelism when backing up a database or table space: v Use more than one target media. v Configure table spaces for parallel I/O. v Use the PARALLELISM parameter on the BACKUP command to specify the degree of parallelism. v Use the WITH num-buffers BUFFERS parameter on the BACKUP command to ensure enough buffers are available to accommodate the degree of parallelism. The number of buffers should equal the number of target media you have plus the degree of parallelism selected plus a few extra. Also, use a backup buffer size that is: – As large as feasible. 4 MB or 8 MB (1024 or 2048 pages) is a good rule of thumb. – At least as large as the largest (extentsize * number of containers) product of the table spaces being backed up. Refer to the Command Reference for information on the BACKUP DATABASE command. Restore Database / Table Space To enable I/O parallelism when restoring a database or table space: v Use more than one source media. v Configure table spaces for parallel I/O. v Use the PARALLELISM parameter on the RESTORE command to specify the degree of parallelism. v Use the WITH num-buffers BUFFERS parameter on the RESTORE command to ensure enough buffers are available to accommodate the degree of parallelism. The number of buffers should equal the number of target media you have plus the degree of parallelism selected plus a few extra. Also, use a restore buffer size that is: – As large as feasible. 4 MB or 8 MB (1024 or 2048 pages) is a good rule of thumb. 22 Administration Guide Design and Implementation
  42. 42. – At least as large as the largest (extentsize * number of containers) product of the table spaces being restored. – The same as, or an even multiple of, the backup buffer size. Refer to the Command Reference for information on the RESTORE DATABASE command. Federated Database System Concepts A federated database system or federated system is a database management system (DBMS) that supports applications and users submitting SQL statements referencing two or more DBMSs or databases in a single statement. An example is a join between tables in two different DB2 databases. This type of statement is called a distributed request. A DB2 UDB Version 6 federated system provides support for distributed requests across databases and DBMSs. You can, for example, perform a UNION operation between a DB2 table and an Oracle view. Supported DBMSs include DB2, members of the DB2 Family (such as DB2 for OS/390 and DB2 for AS/400), and Oracle. A DB2 federated system provides location transparency for database objects. If information (tables and views) is moved, references to that information (called nicknames) can be updated without any changes to applications that request the information. A DB2 federated system also provides compensation for DBMSs that do not support all of the DB2 SQL dialect or certain optimization capabilities. Operations that cannot be performed at a DBMS, such as recursive SQL, are run at DB2. A DB2 federated system functions in a semi-autonomous manner: DB2 queries containing references to Oracle objects can be submitted while Oracle applications are accessing the same server. A DB2 federated system does not monopolize or restrict access to Oracle or other DBMS objects (beyond integrity/locking constraints). A DB2 federated system consists of a DB2 UDB Version 6 instance, a database that will serve as the federated database, and one or more data sources. The federated database contains catalog entries identifying data sources and their characteristics. A data source consists of a DBMS and data. Applications connect to the federated database just like any other DB2 database. See Figure 12 on page 24 for a visual representation of a federated database environment. Chapter 1. Introduction to Concepts Within DB2 Universal Database 23
  43. 43. Figure 12. A Federated Database System DB2 federated database catalog entries contain information about data source objects: what they are called, information they contain, and conditions under which they can be used. Because this DB2 catalog stores information about objects in many DBMSs, it is called a global catalog. Object attributes are stored in the catalog. The actual DBMSs being referenced, modules used to communicate with the data source, and DBMS data objects (such as tables) that will be accessed are outside the database. (One exception: the federated database can be a data source for the federated system.) You can create federated objects using the Control Center or SQL DDL statements. Required federated database objects are: 24 Administration Guide Design and Implementation
  44. 44. Wrappers Identify the modules (dll, library, etc.) used to access a particular class or category of data source. Servers Define data sources. Server data includes the wrapper name, server name, server type, server version, authorization information, and server options. Nicknames Identifiers stored in the federated database that reference specific data source objects (tables, aliases, views). Applications reference nicknames in queries just like they reference tables and views. Depending on your specific needs, you can create additional objects: v User mappings, to address authentication issues v Data type mappings, to customize the relationship between a data source type and an DB2 type v Function mappings, to map a local function to a data source function v Index specifications, to speed performance After a federated system is set up, the information in data sources can be accessed as if it was in one big database. Users and applications send queries to one federated database, which then retrieves data from DB2 Family and Oracle systems as needed. User and applications specify nicknames in queries; these nicknames provide references to tables and views located at data sources. From an end-user perspective, nicknames are similar to aliases. There are many factors affecting federated system performance. The most critical step is to ensure that accurate and up-to-date information about data sources and their objects is stored in the federated database global catalog. This information is used by the DB2 optimizer and can affect decisions to push down operations for evaluation at data sources. See the Administration Guide, Performance for additional information on federated system performance. A DB2 federated system operates under some restrictions. Distributed requests are limited to read-only operations. In addition, you cannot execute utility operations (LOAD, REORG, REORGCHK, IMPORT, RUNSTATS, and so on) against nicknames. You can, however, use a pass-through facility to submit DDL and DML statements directly to database managers using the SQL dialect associated with that data source. Chapter 1. Introduction to Concepts Within DB2 Universal Database 25
  45. 45. Federated systems tolerate parallel environments. Performance gains are delimited by the extent to which a federated database query can be semantically broken down into local object (table, view) references and nickname references. Requests for nickname data are processed sequentially; local objects can be processed in parallel. For example, given the query SELECT * FROM A, B, C, D where A and B are local tables and C and D are nicknames referencing tables at Oracle data sources, one possible plan would join tables A and B with a parallel join. The results are then joined sequentially with nicknames C and D. Enabling a Federated System DB2 Extended Edition and DB2 Enterprise Extended Edition can support federated databases. To enable a federated system: 1. Select the distributed join installation option of DB2 EE or EEE during installation 2. Set the database manager configuration parameter federated to “YES” 3. Create wrappers, servers, and nicknames (see “Creating a Database” on page 145 for more information) 4. Create additional objects or set options as required (see “Chapter 4. Implementing Your Design” on page 99 for more information) 26 Administration Guide Design and Implementation
  46. 46. Part 2. Database Design and Implementation © Copyright IBM Corp. 1993, 1999 27
  47. 47. 28 Administration Guide Design and Implementation
  48. 48. Chapter 2. Designing Your Logical Database This section describes the following steps in database design: v “Decide What Data to Record in the Database” v “Define Tables for Each Type of Relationship” on page 31 v “Provide Column Definitions for All Tables” on page 34 v “Identify One or More Columns as a Primary Key” on page 36 v “Be Sure Equal Values Represent the Same Entity” on page 38 v “Consider Normalizing Your Tables” on page 39 v “Planning for Constraint Enforcement” on page 44 v “Other Database Design Considerations” on page 51. Your goal in designing a database is to produce a representation of your environment that is easy to understand and will serve as a basis for expansion. In addition, you want a database design that will help you maintain consistency and integrity in your data. You can do this by producing a design that will reduce redundancy and eliminate anomalies that can occur during the updating of your database. These steps are part of logical database design. Database design is not a linear process; you will probably have to redo steps as you work out the design. The physical implementation of the database design is described in “Chapter 3. Designing Your Physical Database” on page 55 and “Chapter 4. Implementing Your Design” on page 99. Decide What Data to Record in the Database The first step in developing a database design is to identify the types of data to be stored in database tables. A database includes information about the entities in an organization or business and their relationships to each other. In a relational database, entities are defined as tables. An entity is a person, object, or concept about which you wish to store information. Some of the entities described in the sample tables are employees, departments, and projects. (Refer to the “Sample Tables” in the Administration Guide, Performance, for a description of the sample database.) © Copyright IBM Corp. 1993, 1999 29
  49. 49. In the sample employee table, the entity “employee” has attributes, or properties, such as employee number, name, work department, and salary amount. Those properties appear as the columns EMPNO, FIRSTNME, LASTNAME, WORKDEPT, and SALARY. An occurrence of the entity “employee” consists of the values in all of the columns for one employee. Each employee has a unique employee number (EMPNO) that can be used to identify an occurrence of the entity “employee”. Each row in a table represents an occurrence of an entity or relationship. For example, in the following table the values in the first row describe an employee named Haas. Table 2. Occurrences of Employee Entities and their Attributes EMPNO FIRSTNME LASTNAME WORKDEPT JOB 000010 Christine Haas A00 President 000020 Michael Thompson B01 Manager 000120 Sean O’Connell A00 Clerk 000130 Dolores Quintana C01 Analyst 000030 Sally Kwan C01 Manager 000140 Heather Nicholls C01 Analyst 000170 Masatoshi Yoshimura D11 Designer There is a growing need to support non-traditional database applications such as multimedia. Within your design, you may want to consider attributes to support multimedia objects such as documents, video or mixed media, image, and voice. In a table, each column of a row is related in some way to all the other columns of that row. Some of the relationships expressed in the sample tables are: v Employees are assigned to departments Dolores Quintana is assigned to Department C01 v Employees perform a job Dolores works as an Analyst v Departments report to other departments Department C01 reports to Department A00 Department B01 reports to Department A00 v Employees work on projects Dolores and Heather both work on project IF1000 v Employees manage departments 30 Administration Guide Design and Implementation
  50. 50. Sally manages department C01. Before you design your tables, you must understand entities and their relationships. “Employee” and “department” are entities; Sally Kwan is part of an occurrence of “employee,” and C01 is part of an occurrence of “department”. The same relationship applies to the same columns in every row of a table. For example, one row of a table expresses the relationship that Sally Kwan manages Department C01; another, the relationship that Sean O’Connell is a clerk in Department A00. The information contained within a table depends on the relationships to be expressed, the amount of flexibility needed, and the data retrieval speed desired. In addition to identifying data within your design, you should also identify other types of information such as the business rules which apply to that data. Define Tables for Each Type of Relationship In a database, you can express several types of relationships. Consider the possible relationships between employees and departments. An employee can work in only one department; this relationship is single-valued for employees. On the other hand, one department can have many employees; the relationship is multi-valued for departments. The relationship between employees (single-valued) and departments (multi-valued) is a one-to-many relationship. Relationships can be one-to-many, many-to-one, one-to-one, or many-to-many. The type of a given relationship can vary, depending on the specific environment. If employees of a company belong to several departments, the relationship between employees and departments is many-to-many. You will want to define separate tables for different types of relationships. The following topics are discussed within this section: v “One-to-Many and Many-to-One Relationships” v “Many-to-Many Relationships” on page 32 v “One-to-One Relationships” on page 33 One-to-Many and Many-to-One Relationships To define tables for each one-to-many and many-to-one relationship: Chapter 2. Designing Your Logical Database 31
  51. 51. v Group all the relationships for which the “many” side of the relationship is the same entity. v Define a single table for all the relationships in a group. In the following example, the “many” side of the first and second relationships is “employees” so we define an employee table, EMPLOYEE. Table 3. Many-to-One Relationships Entity Relationship Entity Employees are assigned to departments Employees work at jobs Departments report to (administrative) departments In the third relationship, “departments” is the “many” side, so we define a department table, DEPARTMENT. The following tables illustrate how these examples are represented: The EMPLOYEE table: EMPNO WORKDEPT JOB 000010 A00 President 000020 B01 Manager 000120 A00 Clerk 000130 C01 Analyst 000030 C01 Manager 000140 C01 Analyst 000170 D11 Designer The DEPARTMENT table: DEPTNO ADMRDEPT C01 A00 D01 A00 D11 D01 Figure 13. Assigning Many-to-One Facts to Tables Many-to-Many Relationships A relationship that is multi-valued in both directions is a many-to-many relationship. An employee can work on more than one project, and a project 32 Administration Guide Design and Implementation
  52. 52. can have more than one employee. The questions “What does Dolores Quintana work on?” and “Who works on project IF1000?” both yield multiple answers. A many-to-many relationship can be expressed in a table with a column for each entity (“employees” and “projects”), as shown in the following example. The following table illustrates how a many-to-many relationship (an employee can work on many projects and a project can have many employees working on it) can be represented: The employee activity (EMP_ACT) table: EMPNO PROJNO 000030 IF1000 000030 IF2000 000130 IF1000 000140 IF2000 000250 AD3112 Figure 14. Assigning Many-to-Many Facts to Tables One-to-One Relationships One-to-one relationships are single-valued in both directions. A manager manages one department; a department has only one manager. The questions, “Who is the manager of Department C01?” and “What department does Sally Kwan manage?” both have single answers. The relationship can be assigned to either the DEPARTMENT table or the EMPLOYEE table. Because all departments have managers, but not all employees are managers, it is most logical to add the manager to the DEPARTMENT table as shown in the following example. The following tables illustrates how a one-to-one relationship can be represented: Chapter 2. Designing Your Logical Database 33
  53. 53. The DEPARTMENT table: DEPTNO MGRNO A00 000010 B01 000020 D11 000060 Figure 15. Assigning One-to-One Facts to a Table Provide Column Definitions for All Tables To define a column in a relational table: 1. Choose a name for the column Each column in a table must have a name that is unique within the table. Selecting column names is described in detail in “Appendix D. Naming Rules” on page 691. 2. State what kind of data is valid for the column The data type and length specify maximum length and the type of data that is valid for the column. Data types may be chosen from those provided by the database manager or you may choose to create your own user-defined types. For information about the data types provided by DB2 and about user-defined types, refer to the SQL Reference manual. Examples of data type categories are: numeric, character string, double-byte (or graphic) character string, date-time, and binary string. Large object (LOB) data types support multi-media objects such as documents, video, image and voice. These large objects are implemented using the following data types: v A binary large object (BLOB) string. Examples of BLOBs are photographs of employees, voice, and video. v A character large object (CLOB) string, where the sequence of characters can be either single- or multi-byte characters, or a combination of both. An example of a CLOB is a resume of an employee. v A double-byte character for large object (DBCLOB) string, where the sequence of characters are double-byte characters. An example of a DBCLOB is a Japanese resume. For a better understanding of large object support, refer to the SQL Reference manual. 34 Administration Guide Design and Implementation
  54. 54. A user-defined type (UDT), is a type that is derived from an existing type. You may need to define types that are derived from existing types that share similar characteristics, but are considered to be separate and incompatible types. A structured type is a user-defined type that has a structure that is defined in the database. It contains a sequence of named attributes, each of which has a data type. A structured type may be defined as a subtype of another structured type, called its supertype. A subtype inherits all the attributes of its supertype and may have additional attributes defined. The set of structured types that are related to a common supertype is called a type hierarchy and the supertype that does not have any supertype is called the root type of the type hierarchy. A structured type may be used as the type of a table or a view. The names and data types of the attributes of the structured types, together with the object identifier, become the names and data types of the columns of this typed table or typed view. Rows of the typed table or typed view can be thought of as a representation of instances of the structured type. A structured type cannot be used as the data type of a column of a table or a view. There is also no support for retrieving a whole structured type instance into a host variable in an application program. A reference type is a companion type to the structured type. Similar to a distinct type, a reference type is a scalar type that shares a common representation with one of the built-in data types. This same representation is shared for all types in the type hierarchy. The reference type representation is defined when the root type of a type hierarchy is created. When using a reference type, a structured type is specified as a parameter of the type. This parameter is called the target type of the reference. The target of a reference is always a row in a typed table or view. When a reference type is used, it may have a scope defined. The scope identifies a table (called the target table) or view (called the target view) that contains the target row of a reference value. The target table or view must have the same type as the target type of the reference type. An instance of a scoped reference type uniquely identifies a row in a typed table or typed view, called its target row. A User-defined function (UDF) may be used for a number of reasons, including invoking routines that allow comparison or conversion between user-defined types. UDFs extend and add to the support provided by built-in functions of SQL and can be used wherever a built-in function can be used. There are two types of UDFs: v An external function, which is written in a programming language Chapter 2. Designing Your Logical Database 35
  55. 55. v A sourced function, which will be used to invoke other UDFs For example, two numeric data types are European Shoe Size and American Shoe Size. Both types share the same representations of shoe size, but they are incompatible because the measurement base is different and cannot be compared. When this occurs, a user-defined function can be invoked to convert from one shoe size to another. During your design, you may have to consider functions for your UDTs. For a better understanding of user-defined types, structured types, reference types, and user-defined functions, refer to the SQL Reference manual. 3. State which columns might need default values Some columns cannot have meaningful values in all rows because: v A value of the column is not applicable to the row. For example, a column containing an employee’s middle initial is not applicable to an employee who has no middle initial. v A value is applicable, but the value is not known at this time. As an example, the MGRNO column might not contain a valid manager number because the previous manager of the department has been transferred and a new manager has not been appointed yet. In both situations, you can choose between allowing a null value (a special value indicating that the column value is unknown or inapplicable) or allowing a non-null default value to be assigned by the database manager or by the application. Null values and default values are described in detail in the SQL Reference manual. Identify One or More Columns as a Primary Key The unique key of a table is a column or an ordered collection of columns for which each value identifies (functionally determines) a unique row. For example, an employee number column can be defined as a unique key, because each value in the column identifies only one employee. No two employees can have the same employee number. The primary key of a table is one of the unique keys defined on a table but is selected to be the key of first importance on the table. There can only be one primary key on a table. A primary index is automatically created for the primary key. The primary index is used by the database manager for efficient access to table rows and 36 Administration Guide Design and Implementation
  56. 56. allows the database manager to enforce the uniqueness of the primary key. At other times the database manager may use other columns with indexes defined, and not only the primary key and index, to access data when processing queries. Several columns could qualify as a candidate to be the primary key for a table. Each of the candidate columns could be considered unique. You could have all of the columns as part of the primary key but this would create an overly complex primary key. You should consider having just one of the columns as the primary key and then creating unique constraints or unique indexes on one or more of the other columns. In some cases, using a timestamp as part of the key can be helpful, for example when a table does not have a “natural” unique key or if arrival sequence is the method used to distinguish unique rows. Primary keys for some of the sample tables are: Table Key Column Employee table EMPNO Department table DEPTNO Project table PROJNO The following example shows part of the project table with the primary key column indicated. Table 4. A Primary Key on the PROJECT Table PROJNO (Primary Key) PROJNAME DEPTNO MA2100 Weld Line Automation D01 MA2110 Weld Line Programming D11 If every column in a table contains duplicate values, you cannot define a primary key with only one column. In this case, you can list two or more columns for the primary key. A key with more than one column is a composite key. The combination of column values should define a unique entity. If a composite key cannot be easily assigned, you may consider defining a new column that has unique values. The following example shows a primary key containing more than one column; it is a composite key. Chapter 2. Designing Your Logical Database 37

×