1. IBM DB2 Universal DatabaseAdministration Guide: Design and Implementation V ersion 6SC09-2839-00

2. IBM DB2 Universal DatabaseAdministration Guide: Design and Implementation V ersion 6SC09-2839-00 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. Contents . . .. . .. . .. . .. xiii . xiv . xivPart 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 Congurations . . . 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 26Part 2. Database Design and Implementation. . . . . . . . . 27 Chapter 2. Designing Your Logical Database . . . . . . . . . . . . Decide What Data to Record in the Database . . . . . . . . . . . . Dene Tables for Each Type of Relationship Copyright IBM Corp. 1993, 199929 29 31One-to-Many and Many-to-One Relationships . . . . . . . . . . Many-to-Many Relationships . . . . . One-to-One Relationships . . . . . . Provide Column Denitions 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 51Chapter 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 Considerations55 55 56 58 59 59 61 62 63 65 66 67 67 68 75 78 82 84 85 97Chapter 4. Implementing Your DesignAbout This Book . . . . Who Should Use This book . How This Book is Structured.9931 32 33 34 36 38iii 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 Prole Registry . . . . . . . . . DB2 Administration Server (DAS) . . . Create a Node Conguration File . . . Creation of the Database Conguration File . . . . . . . . . . . . . Replicating Conguration Information Using Response Files . . . . . . . Enable FCM Communications . . . . Creating a Database . . . . . . . . . Denition of Initial Nodegroups . . . Denition of Initial Table Spaces . . . Denition of System Catalog Tables . . Denition of Database Directories . . . DCE Directory Services . . . . . . Lightweight Directory Access Protocol (LDAP) Directory Services . . . . . Creating Nodegroups . . . . . . . Denition 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-Dened Function (UDF) Creating a User-Dened 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 Specication . . . . . . . . . .iv100 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 200Administration Guide Design and ImplementationBefore Altering a Database . . . . . . Changing Logical and Physical Design Characteristics. . . . . . . . . . Changing the License Information . . . Changing Instances . . . . . . . . Changing Environment Variables and the Prole Registry Variables . . . . . . Changing the Node Conguration File Changing the Database Conguration 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-Dened Structured Type Deleting and Updating Rows of a Typed Table . . . . . . . . . . . . . Renaming an Existing Table . . . . . Dropping a Table. . . . . . . . . Dropping a Trigger . . . . . . . . Dropping a User-Dened Function (UDF), Function Template, or Function Mapping . . . . . . . . . . . Dropping a User-Dened 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 Specication . . . . . . . . . . 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 . . . . . Dening a Filter to Retrieve a Specic Set of Data . . . . . . . . . . Help . . . . . . . . . . . .. . . . . . . . .206 206 206 207 212 212 212 213 214 214 214 216 216 223 223 223 224 225226 227 227 228 229 230 230 232 233235 236 238 239 239 240 241 241 242. 242 . 242 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 Conguration Assistant . . . . . Searching for Databases . . . . . . Performance Monitor . . . . . . . . Event Monitor. . . . . . . . . . Using the Monitor Tools . . . . . . Monitoring Performance at a Point in Time . . . . . . . . . . . . . Predened 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 274Checking 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 . 312Contentsv 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 . 331Chapter 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 ... 363Chapter 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. . . .. . . .vi333 335 337 341 342 356 358373 373 375 376Administration Guide Design and ImplementationFrequency 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 444445 445 446 449 450 452 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 . . . . . 454Part 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 Conguration 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 Congured 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 . . . . Conguration Considerations . . XA Function Supported . . . .465 466 467 467 469 474477 478 481 482 484 485 485 486.. 489.. 490.. 490 491 . 491 . 494 . 495 . 496. . . .XA Interface Problem Determination Conguring XA Transaction Managers to Use DB2 UDB . . . . . . . . . . . Conguring IBM TXSeries CICS. . . . Conguring IBM TXSeries Encina . . . Conguring BEA Tuxedo . . . . . . Conguring Microsoft Transaction ServerPart 4. Ensuring the High Availability of Your System499 500 501 501 504 505. . . 513Chapter 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 Conguration . . . . . . . . Conguration of a DB2 Database Partition. . . . . . . . . . . . Example of a Mutual Takeover Conguration . . . . . . . . . . Example of a Hot Standby Takeover Conguration . . . . . . . . . . Conguration of a NFS Server Node Example of a NFS Server Takeover Conguration . . . . . . . . . . Considerations When Conguring the SP Switch . . . . . . . . . . . . DB2 HACMP Conguration Examples DB2 HACMP Startup Recommendations HACMP ES Event Monitoring and User-Dened 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. . . .Contents515 516 516 519 520 522523 524 529 530 530 531 532 532 534 543 544 547 550 552 552 554 554 556 557vii 9. Chapter 14. High Availability in the Windows NT Environment . . . . . . Failover Congurations . . . . . . . Hot Standby Conguration . . . . . Mutual Takeover Conguration . . . . Using the DB2MSCS Utility . . . . . . Specifying the DB2MSCS.CFG File . . . Setting up Failover for a Single-Partition Database System . . . . . . . . . Setting up a Mutual Takeover Conguration 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 Congurations 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 573574 574 576 577577 579 580 580 581582 583 584 585 586 586 586 587 591 591 592 593593 595. 597 . 597Administration Guide Design and ImplementationFailover Congurations . . . . . . Hot Standby Conguration . . . . Mutual Takeover Conguration . . . Setting up Failover Support for a Database System . . . . . . . . . . . . Choosing a Failover Conguration . . 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 Congurations . . . . . . . Hot Standby Conguration . . . . . Mutual Takeover Conguration . . . . Setting Up Failover Support for a Database System . . . . . . . . . . . . . Choosing a Failover Conguration . . . 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 Conguration Setting Up a Mutual Takeover Conguration . . . . . . . . . . Starting and Stopping DB2 . . . . . Running Scripts During a Failover . . . Considerations for Table Spaces . . . . . Client Application Considerations . . . .604 605 605 605 606 606607 607 609 610 611 613 614 615 615 616 616 617 618 618 619 619 619 620 620 621Part 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. 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 639Appendix 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 643Appendix 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 . . . . Conguration Parameters . . . . . . DB2 Universal Database Version 5 Incompatibilities . . . . . . . . . . System Catalog Views . . . . . . . Application Programming . . . . . . SQL . . . . . . . . . . . . . Database Security and Tuning . . . . Utilities and Tools . . . . . . . . Connectivity and Coexistence . . . . Conguration Parameters . . . . . . Appendix D. Naming Rules . . . Database Names . . . . . . . Database and Database Alias Names User IDs and Passwords . . . .. . . .. . . .. . . .647 648 648648649 649 650 657 663 665 666 667 667 668 668 670 679 685 685 686 686 691 691 691 692Schema Names . . . . . . . Group and User Names . . . . Object Names . . . . . . . . Federated Database Object Names . How Case-Sensitive Values Are Preserved in a Federated System. . . .. . . .. . . .... 696Appendix 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 . . . . . . Conguration 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 695699 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 . 733Contents727 727 729 730ix 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 Identiers . . . . . 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) . . . Prex Sequences . . . . . . . . . . Specifying the List of Machines . . . . .x734 734 735 735 736 737 737 738 739 741 742745 745 746 746 747 761 761 763 770 770 771 772 773 773 777 784791 791 792 793 794 794 795 796 799Administration Guide Design and ImplementationEliminating Duplicate Entries from the List of Machines . . . . . . . . Controlling the rah Command . . . . $RAHDOTFILES on UNIX-Based Platforms . . . . . . . . . . Setting the Default Environment Prole 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 . 814Appendix L. Conguring 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. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .835 835 836 836Appendix P. Notices . . . . Trademarks . . . . . . . Trademarks of Other Companies. . .. . .. . .. 861 . 862 . 862837Index.......... 865837Contacting IBM .......... 883Install 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 . . . . . . . . . . . . Congure 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 835Performance 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 859838. 845Contentsxi 13. xiiAdministration Guide Design and Implementation 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 conguring 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 conguring 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 le 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 le can be viewed and updated using an ASCII le editor. The log le records the error message type, a time stamp, a process identier (PID), a thread identier (TID), and an SQL error message. The Copyright IBM Corp. 1993, 1999xiii 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 le can be edited by an ASCII le 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.xivAdministration Guide Design and Implementation 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 databases 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 Bookxv 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 les 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. Conguring Multiple Logical Nodes, describes how to congure 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 denitions, and adding new action denitions. 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 applications, and the DB2 Universal Database product, performance.xviAdministration Guide Design and Implementation 18. The specic chapters and appendixes in that volume are briey 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 Conguring 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 Conguration, 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 Conguring DB2, discusses the database manager and database conguration les and the values for the conguration parameters. Appendixes v DB2 Registry and Environment Variables, presents prole 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 Bookxvii 19. v Explain Tables and Denitions, 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.xviiiAdministration Guide Design and Implementation 20. Part 1. Database Concepts Copyright IBM Corp. 1993, 19991 21. 2Administration Guide Design and Implementation 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 exibility for you to run a wide range of hardware congurations. It allows you to choose how to best match your hardware and application requirements with a specic DB2 product conguration. 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 specic 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 specic environment. In some cases, entire sections or chapters are appropriate for only a specic 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 dened 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 rst 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, 19993 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 denition of a database partition. A database is organized into parts called table spaces. A table spaces denition 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 le 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 dened 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 dening 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 FROM 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.4Administration Guide Design and Implementation 24. SystemInstance(s)Database(s)Nodegroup(s)Table space tablesindex(es)long dataFigure 1. Relationship Among Some Database ObjectsOverview 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, conguration les, 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 Database5 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 databases 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 dene named subsets of one or more database partitions in a database. Each subset you dene 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 dened with database partitions that belong to the same instance. Figure 2 on page 7 shows an example of a database with ve partitions in which: v v v vA 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.6Administration Guide Design and Implementation 26. DatabaseNodegroup 2Database PartitionNodegroup 1 Database Partition Database Partition Database PartitionNodegroup 3Database PartitionFigure 2. Nodegroups in a DatabaseYou 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 conguration, and the hardware environment determine how DB2 will perform a task in parallel. These considerations are interrelated. You should consider them together when rst 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 Database7 27. DB2 supports the following types of parallelism: v I/O v Query v UtilityI/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 signicant 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.8Administration Guide Design and Implementation 28. SELECT... FROM...A query is divided into parts, each being executed in parallel.Data Database PartitionFigure 3. Intra-Partition ParallelismFigure 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 congure 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 Database9 29. SELECT... FROM...A query is divided into parts, each being executed in parallel.DataDataDataDataDatabase PartitionDatabase PartitionDatabase PartitionDatabase PartitionFigure 4. Inter-Partition ParallelismFigure 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 dene 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.10Administration Guide Design and Implementation 30. SELECT... FROM...SELECT... FROM...SELECT... FROM...A query is divided into parts, each being executed in parallel.DataDataDatabase PartitionDatabase PartitionFigure 5. Both Inter-Partition and Intra-Partition ParallelismUtility Parallelism DB2s 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 Database11 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 congurations 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.12Administration Guide Design and Implementation 32. Uniprocessor machineCPUMemory Database PartitionDisksFigure 6. Single Partition On a Single ProcessorThe 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 conguration. 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 conguration is described in the next section.Chapter 1. Introduction to Concepts Within DB2 Universal Database13 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 signicantly 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 machineCPUCPUCPUCPUMemoryDatabase PartitionDisksFigure 7. Single Partition Database Symmetric Multiprocessor SystemTable 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware conguration.14Administration Guide Design and Implementation 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 specically 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 congurations are described in the next section.Multiple Partition Congurations 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 congurations: 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 conguration. The latter name accurately reects 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 Database15 35. Communications FacilityUniprocessor machineUniprocessor machineUniprocessor machineUniprocessor machineCPUCPUCPUCPUMemoryMemoryMemoryMemoryDatabase PartitionDatabase PartitionDatabase PartitionDatabase PartitionDisksDisksDisksDisksFigure 8. Massively Parallel Processing SystemA 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 conguration. Capacity and Scalability: In this environment you can add more database partitions (nodes) to your conguration. 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 conguration is described in the next section.16Administration Guide Design and Implementation 36. Partitions with Multiple Processors As an alternative to a conguration in which each partition has a single processor is a conguration in which a partition has multiple processors. This is known as an SMP cluster. This conguration 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 FacilitySMP machineCPUCPUCPUSMP machineCPUCPUCPUCPUMemoryMemoryDatabase PartitionDatabase PartitionDisksCPUDisksFigure 9. Cluster of SMPsTable 1 on page 20 lists the types of parallelism best suited to take advantage of this hardware conguration. 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 Database17 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 FacilityCPUCPUCPUCPUMemoryMemoryDatabase Partition 1Database Partition 2DisksDisksFigure 10. Partitioned Database, Symmetric Multiprocessor System18Administration Guide Design and Implementation 38. Figure 11 illustrates the fact that you can multiply the conguration shown in Figure 10 on page 18 to increase processing power. Communications FacilityBig SMP machineBig SMP machineCommunications FacilityCommunications FacilityCPU CPUCPU CPUCPU CPUCPU CPUMemoryMemoryMemoryMemoryDatabase Partition 1Database Partition 2Database Partition 3Database Partition 4DisksDisksDisksDisksFigure 11. Partitioned Database, Symmetric Multiprocessor Systems Clustered TogetherNote also that the ability to have two or more partitions coexist on the same machine (regardless of the number of processors) allows greater exibility in designing high availability congurations 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 Database19 39. Table 1. Types of Parallelism Possible for Each Hardware Environment Hardware EnvironmentSingle Partition, Single ProcessorI/O ParallelismYesIntra-Query Parallelism Intra-Partition Inter-Partition Parallelism Parallelism No(1)NoSingle Partition, Yes Multiple Processors (SMP)YesNoMultiple Partitions, One Processor (MPP)YesNo(1)YesMultiple Partitions, Multiple Processors (cluster of SMPs)YesYesYesLogical Database Partitions YesYesYesNote: (1) There may be an advantage to setting the degree of parallelism (using one of the conguration 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 conguration parameters and database manager conguration parameters. INTRA_PARALLEL Database manager conguration parameter. Refer to Administration Guide, Performance for more information on this parameter. DFT_DEGREE Database conguration 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.20Administration Guide Design and Implementation 40. CURRENT DEGREE Special register for dynamic SQL. Refer to the SQL Reference for more information. For more information on the conguration parameter settings, and how to enable applications to process in parallel, refer to Conguring 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 specication in the autoloader.cfg le. Refer to Administration Guide, Performance for more information on this LOAD specication and the conguration le.Create Index To enable parallelism when creating an index:Chapter 1. Introduction to Concepts Within DB2 Universal Database21 41. v The INTRA_PARALLEL database manager conguration parameter must be ON v The table must be large enough to benet 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 Congure 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 Congure 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.22Administration Guide Design and Implementation 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 Database23 43. Figure 12. A Federated Database SystemDB2 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:24Administration Guide Design and Implementation 44. Wrappers Identify the modules (dll, library, etc.) used to access a particular class or category of data source. Servers Dene data sources. Server data includes the wrapper name, server name, server type, server version, authorization information, and server options. Nicknames Identiers stored in the federated database that reference specic data source objects (tables, aliases, views). Applications reference nicknames in queries just like they reference tables and views. Depending on your specic 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 specications, 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 Database25 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 conguration 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)26Administration Guide Design and Implementation 46. Part 2. Database Design and Implementation Copyright IBM Corp. 1993, 199927 47. 28Administration Guide Design and Implementation 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 Dene Tables for Each Type of Relationship on page 31 v Provide Column Denitions 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 rst 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 dened 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, 199929 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 rst row describe an employee named Haas. Table 2. Occurrences of Employee Entities and their Attributes EMPNOFIRSTNMELASTNAMEWORKDEPTJOB000010ChristineHaasA00President000020MichaelThompsonB01Manager000120SeanOConnellA00Clerk000130DoloresQuintanaC01Analyst000030SallyKwanC01Manager000140HeatherNichollsC01Analyst000170MasatoshiYoshimuraD11DesignerThere 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 departments30Administration Guide Design and Implementation 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 OConnell is a clerk in Department A00. The information contained within a table depends on the relationships to be expressed, the amount of exibility 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.Dene 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 specic environment. If employees of a company belong to several departments, the relationship between employees and departments is many-to-many. You will want to dene 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 33One-to-Many and Many-to-One Relationships To dene tables for each one-to-many and many-to-one relationship: Chapter 2. Designing Your Logical Database31 51. v Group all the relationships for which the many side of the relationship is the same entity. v Dene a single table for all the relationships in a group. In the following example, the many side of the rst and second relationships is employees so we dene an employee table, EMPLOYEE. Table 3. Many-to-One Relationships EntityRelationshipEntityEmployeesare assigned todepartmentsEmployeeswork atjobsDepartmentsreport to(administrative) departmentsIn the third relationship, departments is the many side, so we dene a department table, DEPARTMENT. The following tables illustrate how these examples are represented: The EMPLOYEE table: EMPNOWORKDEPTJOB000010A00President000020B01Manager000120A00Clerk000130C01Analyst000030C01Manager000140C01Analyst000170D11DesignerThe DEPARTMENT table: DEPTNOADMRDEPTC01A00D01A00D11D01Figure 13. Assigning Many-to-One Facts to TablesMany-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 project32Administration Guide Design and Implementation 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: EMPNOPROJNO000030IF1000000030IF2000000130IF1000000140IF2000000250AD3112Figure 14. Assigning Many-to-Many Facts to TablesOne-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 Database33 53. The DEPARTMENT table: DEPTNOMGRNOA00000010B01000020D11000060Figure 15. Assigning One-to-One Facts to a TableProvide Column Denitions for All Tables To dene 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-dened types. For information about the data types provided by DB2 and about user-dened 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 followi