cv 8317 stud

Enterprise Computing Solutions

Business Intelligence

Data Centre Cloud Mobility

Comunidad de Madrid

Dirección General de Formación

CONSEJERÍA DE EMPLEO,TURISMO Y CULTURA

UNIÓN EUROPEAFONDO SOCIAL EUROPEO

El Fondo Social Europeo invierte en tu futuro

EDUCATIONS E R V I C E S

Student Manual

V5.4.0.3

cover

Exclus

ivo fo

r

proy

ecto

Front cover

DB2 10 for z/OS Database Administration Workshop Part 1 (Course code CV831)

Student NotebookERC 7.0

IBM certified course material

mación

C.F.T.I.C.

Student Notebook

.

Trademarks

The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies:

IBM® is a registered trademark of International Business Machines Corporation.

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

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

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

Windows is a trademark of Microsoft Corporation in the United States, other countries, or both.

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

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®DRDA® IMS™ Lotus®Notes® OS/390® Parallel Sysplex®QMF™ RACF® RETAIN®z/OS® zSeries® 1-2-3®

xclus

ivo fo

rmac

ión

yecto

C.F.T.I.C

October 2011 edition

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

© Copyright International Business Machines Corporation 1993, 2011.This document may not be reproduced in whole or in part without the prior written permission of IBM.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

E pr

o

Student NotebookV5.4.0.3

TOC

E

Contents

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Unit 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2What is DB2 for z/OS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3The user’s view (dynamic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5Another kind of user (static) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6A program's responsibility - a logical unit of work . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8The system’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11DB2’s responsibilities - SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12Data integrity and concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13DB2 system log data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15COPY/RECOVER utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16DB2’s responsibilities - PERFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17DB2’s responsibilities - METADATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18DB2 for z/OS data sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Roles and interfaces in DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Unit 2. Setting up a DB2 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.1. Overview of setting up a DB2 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Objects used by DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Defining DB2 objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Owner concept - example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Owner’s privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8DB2 naming rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

2.2. Storage groups, databases, and table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11DB2 Storage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12DB2 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15DB2 buffer pools (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17DB2 buffer pools (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18EBCDIC, ASCII, and Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Administration at the database level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22DB2 table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23Types of table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24Simple table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Segmented table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27Single and multiple-table table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.

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

© Copyright IBM Corp. 1993, 2011 Contents iii

Student Notebook

.

Segmented table space - sample definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30Segmented table space - maximum size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31Classic partitioned table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32Create a classic partitioned table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-33Advantages of partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-34Classic partitioned table space - Maximum size for NUMPARTS < 255 . . . . . . . .2-35Classic partitioned table space - Maximum number of partitions . . . . . . . . . . . . . .2-36Classic partitioned table space - Maximum size for NUMPARTS > 254 . . . . . . . .2-37Partition-by-range universal table space (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . .2-38Partition-by-growth universal table space (PBG) . . . . . . . . . . . . . . . . . . . . . . . . . .2-40Partition-by-growth UTS - pros and cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41Create a partition-by-growth universal table space . . . . . . . . . . . . . . . . . . . . . . . .2-42Default type of a table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-44SYSTABLESPACE catalog information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-45Space allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-47Space map page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50Data page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-52Free space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-53

2.3. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-55CREATE TABLE - column attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-56Row format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-59Basic row format and reordered row format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-61DEFAULT attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-64Table check constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-66SYSTABLES and SYSCOLUMNS catalog information . . . . . . . . . . . . . . . . . . . . .2-69Check constraints catalog information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-70Enable table-controlled partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-71ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-72Examples for adding / removing check constraints . . . . . . . . . . . . . . . . . . . . . . . .2-73Adding able check constraints - considerations . . . . . . . . . . . . . . . . . . . . . . . . . . .2-74The -DISPLAY DATABASE command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-75

2.4. Data compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-77Data compression - overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-78Data compression - data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-79Data compression - building the dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-80Compress on INSERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-84How Compress on INSERT works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-85Location of compression dictionary pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-87Miscellaneous on Compress on Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-89

2.5. Views and Materialized Query Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-91DB2 views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-92CREATE VIEW - examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-94Views on views on tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-96DELETE from a view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-98SELECT, UPDATE, INSERT, DELETE with VIEWS . . . . . . . . . . . . . . . . . . . . . . .2-99The disappearing row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-101WITH CHECK OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-102Effect of cascaded CHECK OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-104

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C

iv DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011



TOC

E

Views - catalog information (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-106Views - catalog information (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-107Materialized query tables (MQTs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-108Populating and refreshing MQTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111Special registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-112

2.6. Synonyms and Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-113SYNONYM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-114SYNONYM - catalog information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-115ALIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-116ALIAS - catalog information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-118Object name translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-119

2.7. Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-123What is an index? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-124Why have indexes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-125Creating unique and non-unique indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-127Index on expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-131Index and index space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-133Index and index space attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-134DB2 index tree structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-139Catalog tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140DB2 addressing scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-143DB2 addressing scheme - overflow pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-144Leaf page - index entry format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-146Non-leaf pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-147Index page management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-148Index-controlled partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-150Table-controlled partitioning - partitioning index(partitioned and non-partitioned) 2-153Table-controlled partitioning - non-partitioning non-partitioned secondary index (NPSI) 2-155Table-controlled partitioning - non-partitioning partitioned secondary index (DPSI) . . .2-156Table-controlled partitioning - partition one way and cluster another way . . . . . 2-158Table-controlled partitioning - catalog entries . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-160

2.8. Index compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-163Index compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-164DDL, catalog and utility changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-167Comparison: Index and data compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-169

2.9. Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-171Automatic creation of objects (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-172Automatic creation of objects (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-174Automatic creation of objects (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-176DB2 naming conventions for data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-177Object dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-178Checkpoint quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-180Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.

© Copyright IBM Corp. 1993, 2011 Contents v


Student Notebook

.

Unit 3. Implementing unique and referential requirements . . . . . . . . . . . . . . . . . . . .3-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

3.1. Referential integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5Primary key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6Unique key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Foreign key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9Foreign key - column considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11Referential integrity - DB2 implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Creating a referential constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14Creating the primary key and primary index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15Creating unique keys and foreign keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16Creating informational referential constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18Adding primary key constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20Adding unique and foreign key constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21Dropping constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22Restrictions on dropping indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23Catalog information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24Referential structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26Additional considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28TABLESPACESET concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29REPORT TABLESPACESET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-30CHECK PENDING restrictive state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31

3.2. Generating unique values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33Identity columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-34Identity column considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-37DB2 sequence object (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-39DB2 sequence object (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-41Identity columns versus sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-45Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-47

Unit 4. Getting data into and out of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

4.1. Introduction to DB2 utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Generating utility JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4DB2 utility panel (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5DB2 utility panel (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6DSNUxxx.CNTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7DSNUPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9SYSIBM.SYSUTILX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10DB2 utility commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11DB2 utility flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12

4.2. The LOAD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13Loading data into one table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14Data type conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16Data conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17Loading NULL values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18Loading multiple tables in a table space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20LOAD RESUME, REPLACE, and REUSE at TS level . . . . . . . . . . . . . . . . . . . . . .4-22

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C

vi DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011



TOC

E

LOAD RESUME, REPLACE, and REUSE at partition level . . . . . . . . . . . . . . . . . 4-24Other LOAD options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25LOAD phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27DISCARD file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Unique index violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29LOAD considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30DB2 family cross-loader function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31LOAD - delimited input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

4.3. Ensuring referential and check constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33Check pending (CHKP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34Using the CHECK DATA utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36CHECK DATA - exception tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38CHECK DATA - phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40CHECK DATA - example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41

4.4. The UNLOAD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43DB2 UNLOAD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44Table space input specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46Example of the unloaded records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48Output field specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49UNLOAD - delimited output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-50Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52Checkpoint quiz (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53Checkpoint quiz (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54Checkpoint quiz (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56

Unit 5. Keeping your DB2 data in good shape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.1. RUNSTATS and real-time statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4RUNSTATS versus real-time statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Enabling real-time statistics (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Enabling real-time statistics (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7When are space-related statistics still needed? . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8Important RUNSTATS options (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Important RUNSTATS options (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Inline statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12Recommended RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13

5.2. REORG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15Reasons for reorganizing table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Reasons for reorganizing indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18REORG TABLESPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19REORG INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21REORG examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22REORG TABLESPACE ... DISCARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23Determining the need for REORG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.

© Copyright IBM Corp. 1993, 2011 Contents vii


Student Notebook

.

Unit 6. Application data recovery basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2Application data recovery - overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3DB2 logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4SYSIBM.SYSLGRNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6Backing up table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7Backing up partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9Copy data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11COPY - examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13COPYTOCOPY utility - establishing copies of image copies . . . . . . . . . . . . . . . . .6-14Table space recovery concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16Recovery - examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-18Preparing for a recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19Combining image copies for table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20REBUILD INDEX utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-21REBUILD INDEX examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22REBUILD INDEX considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-23Recovery / rebuild pending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-24MODIFY RECOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28

Unit 7. Program preparation / bind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Program preparation flow for DB2 precompiler . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3Program preparation flow for multiple modules . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5Let BIND determine object to be accessed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8

Unit 8. Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2DB2 authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3Who is the user? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4Establishing authorization IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6USER and CURRENT SQLID special registers . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7What can be authorized? (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9What can be authorized? (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10What do authorities contain? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11Install SYSADM and install SYSOPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12Separation of duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14Where is authorization information kept? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16Which ID is checked? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17How do you acquire authority? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18Granting privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19Privileges example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-20How do you control it? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21Revoking privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22CREATE privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23Example - ownership of a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C

viii DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011



TOC

E

Establishing ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25Ownership examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27Checking authorization to execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28Controlling access for dynamic DML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30Controlling access for static SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31Authorizations for BIND (overview) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32DB2 authorization summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-34

Unit 9. Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2Why does DB2 have serialization mechanisms? . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3DB2 serialization mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5What gets locked? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7Main characteristics of transaction locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9Size of transaction locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10Concurrency versus CPU overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12Two locking strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13Page or row locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14Lock mode compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16Table, table space and partition locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17More about table, table space and partition locks . . . . . . . . . . . . . . . . . . . . . . . . . 9-18Lock mode compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20Isolation levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21SKIP LOCKED DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24Duration of page and row locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26Duration of table, table space and partition locks . . . . . . . . . . . . . . . . . . . . . . . . . 9-27Lock avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28Lock escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29Lock escalation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31COMMIT interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33Deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-34Some factors which affect locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37

Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.

© Copyright IBM Corp. 1993, 2011 Contents ix


Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


x DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


TMK

E

Trademarks

The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies:

IBM® is a registered trademark of International Business Machines Corporation.

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

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

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

Windows is a trademark of Microsoft Corporation in the United States, other countries, or both.

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

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®DRDA® IMS™ Lotus®Notes® OS/390® Parallel Sysplex®QMF™ RACF® RETAIN®z/OS® zSeries® 1-2-3®

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Trademarks xi

Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xii DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


pref

E

Course description

DB2 10 for z/OS Database Administration Workshop Part 1

Duration: 5 days

Purpose

This course provides you with instruction on how to physically implement a logical database design in DB2. The course includes instruction on DB2 data management, DB2 catalog tables, the bind process, database utilities such as LOAD and REORG, and security considerations.

Note: This course material is at the DB2 10 for z/OS level.

Audience

Future DB2 for z/OS database administrators who need to acquire the basic skills required to administer a DB2 database.

Prerequisites

Before taking this course, you should be able to: • Design a relational table • Describe the SQL data manipulation statements to access and

change the contents of DB2 tables

You should also take DB2 Family Fundamentals (CE03) and SQL Workshop (CE12), or have equivalent experience.

Objectives

After completing this course, you should be able to:

• Implement a DB2 database design • Use database utilities to load and reorganize data • Define and implement a DB2 database recovery strategy • Control access to database using DB2 authorization facilities

Contents

This course covers the following major topics:

• Setting up a DB2 database

• Referential integrity

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Course description xiii

Student Notebook

.

• Getting data into and out of DB2

• Keeping your DB2 data in good shape

• Application data recovery basics

• Program preparation and Bind

• Security

• Serialization

The course includes extensive machine exercises.

Curriculum relationship

CV841 DB2 9 for z/OS Database Administration Workshop Part 2

CV851 DB2 10 for z/OS System Administration

CV870 DB2 9 for z/OS Utilities for Database Administrators

CV891 DB2 9 for z/OS Application Data Recovery

CV940 DB2 9 for z/OS Index Modeling and Design

CV950 DB2 9 for z/OS System Performance Analysis and Tuning

CV960 DB2 9 for z/OS Application Performance for Tuning

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xiv DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


pref

E

DB2 9 for z/OS Database Administration Workshop Part 2 (CV841 - 3 days)

This course is a continuation of CV83 and is designed to teach you how to perform additional database administration tasks. The main topics covered by the course are as follows:

• Program Preparation and use of Packages • Online Schema Changes • Clone Tables • Partition Management • UDTs and UDFs • Stored Procedures • Triggers • Large Objects


DB2 10 for z/OS System Administration (CV851 - 5 days)

Administrators of DB2 10 for z/OS can acquire a view of the architecture and fundamental processes required to manage a DB2 10 for z/OS subsystem. Engage in lectures and hands-on labs to gain experience to:

• Relate the z/OS IPL process to a DB2 subsystem

• Explain effects of stopping and starting DB2

• Explain how DB2 sets and use Integrated Catalog Facility (ICF) catalog names

• The use of DSN command processor running in batch and foreground

• See how the catalog (through grant activity) controls access to data

• Search the catalog for problem situations

• Use the catalog and DB2 utilities to determine data recovery requirements

• Describe Internal Resource Lock Manager (IRLM) in a DB2 environment

• Implement DB2 and Resource Access Control Facility (RACF) security

• Describe DB2 program flow for all environments

• Display normal and problem threads and database status

• See how the SQL Processor Using File Input (SPUFI) AUTOCOMMIT option defers the COMMIT/ROLLBACK decision

• Identify and cancel particular threads

• Describe available DB2 utilities to manage system and user page sets

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Course description xv

Student Notebook

.

DB2 9 for z/OS Utilities for Database Administrators (CV870 - 3 days)

This course is designed to teach you advanced topics about DB2 for z/OS utilities. It is assumed that you attended course CV831 so that you already have basic skills about the main utilities. Recovery-oriented topics are not part of this course, so such utility functions are not presented. The main topics covered by this course are as follows:

• CV831 utilities review

• More on utilities and their functions (RUNSTATS, DSN1COPY, REPAIR, DIAGNOSE)

• LOAD and REBUILD INDEX performance and availability

• Online CHECK DATA

• REORG performance and availability

• UNLOAD performance and availability

• Generic utility jobs (LISTDEF and TEMPLATE)


DB2 9 for z/OS Application Data Recovery (CV891 - 3 days)

This course is designed to teach you how data and index recovery is supported by DB2 9 for z/OS in order to develop the knowledge and skills you need to design and implement backup and recovery procedures for your installations. Practice using the utility functions and techniques included in the lecture material during extensive interactive machine exercises on a z/OS system. The main topics covered by the course are as follows:

• Backup and recovery basics • Normal backup of table and index spaces • Normal recovery of table and index spaces • Point-in-time recovery • Generic utility jobs • Using nonstandard copies • Special recovery situations • Application recovery

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xvi DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


pref

E

DB2 9 for z/OS Index Modeling and Design (CV940 - 3 days)

This course is designed to teach the students how to design the right indexes for improving query performance, both for single table access and for multiple table access.

All of the index utilization possibilities are illustrated as well as the desired column sequence of a multiple column index. Pros and cons of DPSI and NPSI indexes are explained together with the lesser known concepts like index look-aside, implicit uniqueness, sparse indexes, and combination of index screening with list prefetch. The course also clarifies the meaning of many DB2 catalog columns pertaining to the indexes and shows how to correctly use the different RUNSTATS options related to indexes. The main topics covered by this course are as follows:

• Generalities

• Different index formats and distinct reasons for using indexes

• Indexing enhancements in DB2 V9

• Indexes for join

• Index versioning

• Less-known index features

• Operational utilities for indexes

• Index cost

• Indexes for Star Schema

DB2 9 for z/OS System Performance Analysis and Tuning (CV950 - 4 days)

This classroom course explains how to monitor and tune DB2 9 for z/OS from a system point of view. The main topics covered by this course are as follows:

• DB2 system performance analysis and tuning introduction

• The DB2 trace

• Operating system and hardware

• Service time, queuing time and transaction analysis

• The DB2 attachments

• In-depth application of the DB2 system

• Disk subsystems and I/Os

• Capacity analysis and massive Batch

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Course description xvii

Student Notebook

.

DB2 9 for z/OS Application Performance and Tuning (CV960 - 5 days)

This course is designed to teach you how to prevent application performance problems and how to improve the performance of existing applications. The main topics covered by the course are as follows:

• Index design • Table implementation considerations related to performance (denormalization,...) • SQL writing • Optimizer pitfalls • Avoiding long lock waits • Detecting and analyzing performance problems with accounting traces

The course includes paper and machine exercises.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xviii DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


pref

E

Figure 1. Course objectives CV8317.0

Notes:

© Copyright IBM Corporation 2011


• Implement a DB2 database design

• Use database utilities to load and reorganize data

• Define and implement a DB2 database recovery strategy

• Control access to database using DB2 authorization facilities


• Implement a DB2 database design

• Use database utilities to load and reorganize data

• Define and implement a DB2 database recovery strategy

• Control access to database using DB2 authorization facilities

Course objectives

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Course description xix

Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xx DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


pref

E

Agenda

Day 1

WelcomeIntroductionUnit 2 (topic 1) - Overview of setting up a DB2 databaseUnit 2 (topic 2) - Storage groups, databases, table spaces Exercise 1 and reviewUnit 2 (topic 3) - Tables Exercise 2 and reviewUnit 2 (topic 4) - Data compression

Day 2

Unit 2 (topic 5) - Views, synonyms, and aliases Exercise 3 and reviewUnit 2 (topic 6) - Materialized Query Tables Unit 2 (topic 7) - Indexes Exercise 4 and reviewUnit 2 (topic 8) - Index compressionUnit 2 (topic 9) - Additional information

Day 3

Unit 3 (topic 1) - Referential integrity Exercise 5 and reviewUnit 3 (topic 2) - Identity columns and sequences Unit 4 - Getting data into and out of DB2 Exercise 6 and review

Day 4

Unit 5 - Keeping your DB2 data in good shape Exercise 7 and reviewUnit 6 - Application data recovery basics Exercise 8 and review

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Agenda xxi

Student Notebook

.

Day 5

Unit 7 - Program preparation Unit 8 - Security Exercise 9 and reviewUnit 9 - Serialization Exercise 10 and review

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


xxii DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


Uempty

E

Unit 1. Introduction

What this unit is about

This unit is an introduction to the different components of a DB2 environment. Starting with a high-level overview of DB2 for z/OS, the user, the responsibilities of the application programs and of the DB2 system itself will be discussed, as well as the major roles people will play in a DB2 shop.

What you should be able to do

After completing this unit, you should be able to:

• Describe the main components of a DB2 environment and the roles they play:

- Users

- Data

- SQL statements (static, dynamic)

- System

How you will check your progress

Accountability:

• Classroom discussion

References

Student Notebook

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 1. Introduction 1-1

Student Notebook

.

Figure 1-1. Unit objectives CV8317.0

Notes:




– Users

– Data

– SQL statements (static, dynamic)

– System



– Users

– Data


– System

Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


1-2 DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


Uempty

E

Figure 1-2. What is DB2 for z/OS? CV8317.0

Notes:

This is the view of DB2 for z/OS from 37,000 feet. A high-level view in one visual before we get into any detail.

DB2 for z/OS is a Relational Database Management System (RDBMS).

Data is presented as a set of tables, that is, rows and columns.

The Structured Query Language (SQL) provides you with capabilities to access, define and control access to these tables. The main language statements fall broadly into 3 categories.

• Data Manipulation Language (DML) comprises SELECT, INSERT, UPDATE, DELETE, and MERGE statements.

• Data Definition Language (DDL) comprises CREATE, ALTER, and DROP statements

• Data Control Language (DCL) comprises GRANT and REVOKE statements

There are many other statements in the language.


What is DB2 for z/OS?

• Relational Data Base Management System (RDBMS)– Data base consists of tables

• Simple concepts• Dynamic relationships

– Structured query language (SQL)• High level

– Data Manipulation Language (DML)– Data Definition Language (DDL)– Data Control Language (DCL)

• User specifies WHAT not HOW – RDBMS facilities

• Integrity• Dynamic definition of DB2 objects• Active catalog• Recovery / restart• Continuous operations• Security• Interactive tools

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

You tell DB2 WHAT columns, rows and sorting sequence you want and DB2 will decide HOW to satisfy your request with the best performance.

As we shall see in this course, DB2 has facilities to maintain the integrity of your data and to allow your definitions to take effect immediately. You can query DB2’s catalog to find out what tables have been defined and who owns them etc. There are extensive recovery and restart facilities and many enhancements in recent years to help provide 24X7 operations. DB2 has its own security mechanism. DB2 provides interactive tools for you to carry out your database administration tasks.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-3. The user’s view (dynamic) CV8317.0

Notes:

Most of you have attended a SQL DML course. During the machine labs, you were asked to code SQL statements and to execute them. You learned the syntax of the Data Manipulation Language (DML) part of the SQL language. While you were practicing, you were DB2 users.

How does a DB2 user "see" the world around them? They see tables and issue SQL DML statements against those tables. They do not see other programs; they do not have to worry about data integrity and so on.

The interactive user communicates with a dynamic program. Such programs don't have complete built-in SQL statements, but ask for the SQL statements (or parts of SQL statements, such as a WHERE clause) at execution time. Once the complete statement is known, it will be passed on to DB2 for access path selection and then executed.

The access path could not be determined at program preparation time, since some fundamental part of the statement, or the entire statement, was unknown until execution of the program.


000010 Chris I Haas A00 3978 1965-01-01000020 Mike L Thomson B01 3476 1973-10-10000030 Sally A Kwain C01 4738 1975-04-05000060 Irving F Stern D11 6423 1973-09-14

...000050 John B Geyer E01 6542 1972-02-02

A00 Spiffy Computer Ser. Div. 000010 ...B01 Planning 000020C01 Information Center 000030D11 Manufacturing System 000060...

D01 Development Center ?

QMF / SPUFI

SELECT LASTNAMEFROM EMPWHERE EMPNO = ‘000050’

Result Data: Geyer

The user’s view (dynamic)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-4. Another kind of user (static) CV8317.0

Notes:

Besides interactive (or dynamic) users who enter SQL statements at their terminals, DB2 also supports static users. The static users communicate with static programs. These users use specific programs (transactions) to perform specific actions on DB2 data, such as getting information about a customer, making a flight reservation, modifying product data, and so on.

These users need not know SQL, and might not even be aware that they access data stored in DB2. The programs with which they work do not expect SQL statements to be entered from a terminal. Such programs contain built-in or embedded SQL statements that were written into the program when it was written. The access path is determined at program preparation time. At execution time, those SQL statements will be executed by loading the needed access paths in storage and completing the missing variables with input from a data set or terminal.

Typically, static programs will be used in transactional or batch environments where the same data access logic has to be executed over and over again. The only information to be


000010 Chris I Haas A00 3978 1965-01-01

000020 Mike L Thomson B01 3476 1973-10-10

000030 Sally A Kwain C01 4738 1975-04-05

000060 Irving F Stern D11 6423 1973-09-14

...000050 John B Geyer E01 6542 1972-02-02

A00 Spiffy Computer Ser. Div. 000010 ...

B01 Planning 000020C01 Information Center 000030D11 Manufacturing System 000060...

D01 Development Center ?

EMP NR ? EMP NR ?

000050

LASTNAME :

Geyer

GET ...MOVE ...

SELECT LASTNAMEFROM EMPWHERE EMPNO = :EMPNO

Another kind of user (static)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

provided at execution time will be the actual employee number or a specific product number, but the access logic will always be the same.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-5. A program's responsibility - a logical unit of work CV8317.0

Notes:

A major responsibility of any program is to group its statements in Logical Units of Work (LUW).

A program must tell the system when a LUW starts and ends. This is part of the business logic. The typical banking transaction (debit/credit) doesn't make sense unless it moves money from one account to another, thereby updating both accounts. It must tell DB2 by COMMITing that a LUW has successfully ended, or by ROLLBACKing that the entire LUW should be backed out.

The actual statement used to COMMIT depends on the execution environment of the program: EXEC SQL COMMIT under TSO or batch; EXEC CICS SYNCPOINT under CICS; GU IOPCB or CHKP calls under IMS.

DB2 uses the term Unit of Recovery for LUW.


UPDATE B

Logical Unit of WorkUPDATE A

COMMIT

A 2000 1000 1000 1000B 3000 3000 4000 4000

UPDATE BUPDATE A

ROLLBACK

A 2000 1000 1000 2000B 3000 3000 4000 3000

A program transfers $1000 from account A to account B

A program's responsibility - a logical unit of work

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-6. The system’s view CV8317.0

Notes:

There are many different ways that DB2 data can be accessed concurrently such as:

• User-written applications

• SQL statements that users key in dynamically

• DB2 utilities

The visual shows the allied (or user application) address spaces where application programs run. The dashed lines between the allied address spaces and DB2 are connections or threads. Think of them as pipelines through which any kind of DB2 request must flow; that is true for SQL, commands, DSN subcommands, utilities, and so forth. To communicate with DB2, allied address spaces must have an authorized connection.

A DB2 subsystem is composed of the following address spaces:

• System Services or MSTR (mandatory)

• Database Services or DBM1 (mandatory)

• Internal Resource Lock Manager (IRLM) (mandatory)


• DB2 receives MANY requests from MANY user programs to access potentially the SAME data

• Besides USER PROGRAMS, DB2 also receives requests from UTILITIES

Utility

Trx2

Prog2

TSO

Trx1

CICS

TrxbTrxa

IMS-TM(aka IMS-DC)

DB2

Utility

BATCH

Prog1

WebSphereApplication

Server

Appl2

Appl1

• Distributed Applications

The system’s view

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• Distributed Data Facility (DDF) or DIST (optional)

This address space is required in a distributed environment.

• One or more WLM-established Stored Procedure address spaces (optional), also used to execute User Defined Functions (UDF).

WLM = Workload Manager (component of z/OS)

A distributed environment enables applications to access data on different DB2 systems located at, say, different sites in a network.

Distributed data is data that resides on a DB2 system other than your local DB2 system. Your local DB2 system is the one on which you bind (see later). All other DB2 systems are remote.

When you request services from a remote DB2 system, the remote DB2 system is a server and your local DB2 system is a requester or client. A remote server can be many miles away or it can run under the same operating system as the local client. The remote server can be another DB2 for z/OS system or another member of the DB2 Family.

Although only DB2 systems are mentioned above, you should note that any kind of relational DRDA system is able to connect to a DB2 for z/OS system.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-7. Utilities CV8317.0

Notes:

Utilities are "special" programs that can be run by submitting JCL (or calling the DSNUTILS or DSNUTILU stored procedure). They run in batch and get their control information via control statements (not SQL).

Utilities are used, for example, to take backups of tables (COPY utility), to reorganize table data (REORG), or to load them with data from sequential data sets (LOAD utility).


COPY

LOADREORG

• Work at the data set level

• Run in BATCH

• Compete with user programs for resources

• Specify your requirements using CONTROL STATEMENTS mostly

SEQUENTIALDATA SET

IMAGE COPY

Utilities

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-8. DB2’s responsibilities - SECURITY CV8317.0

Notes:

Every SQL call, every utility execution, and every command execution must be authorized, otherwise access will be denied. Security definitions are made using the GRANT and REVOKE SQL statements.

The resulting security definitions are stored in the DB2 catalog (set of tables containing DB2's own control information).


DB2 must verify whether a request is LEGITIMATE

GRANT SELECTON TABLE T1TO JAN, PIERRE ;

GRANT UPDATE ON TABLE T1 TO JAN ; Table User Select Update

T1 Jan Y YT1 Pierre Y N

DB2 CATALOG

DB2UPDATET1 SET ...

SELECT ...FROM T1 Jan

PierreSTOP

OK

DB2’s responsibilities - SECURITY

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-9. Data integrity and concurrency CV8317.0

Notes:

Step 1

Program 1 is updating an employee row.

While this data is being modified within a logical unit of work (LUW) it is potentially inconsistent and must therefore be hidden from all other processes until program 1’s update completes with a COMMIT or ROLLBACK.

To protect the modified data from all other processes DB2 automatically uses a locking mechanism. DB2’s locking mechanism is covered in detail in a later unit. For now, here is a brief introduction.

Before allowing a program to access a piece of data, DB2 may ask for a shared lock (if the program only reads the data), or an exclusive lock (if it also modifies the data) on behalf of that program.

If no one is using the data, a lock will be granted. If another program already has a shared lock on the data, only other shared locks will be granted. If another program already has an exclusive lock on the data, no other locks will be granted.


Prog1 Prog2

. . .

UPDATE

COMMIT

SELECTOK

Row

RELEASELOCK

SHAREDLOCK

... WAIT ...

EXCLUSIVE LOCK

DB2 must maintain data integrity and also provide maximum concurrency

STOP

1

2

3

4

EMPLOYEE Table

Data integrity and concurrency

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Programs that are denied locks will have to wait.

Step 2

Program 2 attempts to read the employee record that is currently being updated by program 1.

Program 2 is made to wait until the LUW finishes.

Step 3

Program 1 completes the update and issues a COMMIT.

DB2 releases the exclusive lock and the committed update is now visible to other programs.

Step 4

DB2 "wakes up" program 2, acquires a shared lock on the data and allows program 2 to read the committed update. Other programs will be able to read the same data concurrently.

SELECT.........WITH UR

Some types of request don't really worry about integrity of the data.

An example is the business analyst who wants to know how much of product “Y” was already sold. He just needs a ballpark figure. He can specify the request using uncommitted read (UR) isolation, and is fully aware that he can potentially receive uncommitted data. If he were to run the query with the standard integrity, he could have problems running concurrently with transactions that add new sales to the table. In this case, the waiting would be inappropriate as the analyst just needs an approximate number.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-10. DB2 system log data set CV8317.0

Notes:

When a program modifies DB2 data, this actually happens in storage, in the data buffers. Writing those changes to disk can happen at any time, before or after the changes are COMMITted or ROLLBACKed. The only synchronous process is the I/O to the log data set at COMMIT/ROLLBACK time.

The log data set is the master copy of the data, and enables DB2 to recover from whatever might happen in the system.


LOGDATA SETX X X

Program

UPDATE

INSERT

COMMIT

DB2

Data Buffer

XASYNC

XDATA

XXXLog Buffer

before after

SYNC

DB2 system log data set

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-11. COPY/RECOVER utilities CV8317.0

Notes:

The basic principle is very straightforward; every once in a while, an image copy will be taken of the data (when somebody submits a COPY job). In the meantime, DB2 continues recording all changes on the log data set. If, for some reason, data was destroyed by a non-DB2 disaster (disk crash, for example), the DB2 RECOVER utility will be able to reconstruct the data by restoring the image copy and then applying all log records that were created since the copy was taken.

For DB2 to be able to recover data, changes to data must be copied to an image copy data set (using the COPY utility), or be logged (always happens with SQL; some utilities can bypass), or both.


Log Time

UPDATE UPDATE DELETE

IMAGE COPY

RECOVER

DISKCRASH

COPY

COPY/RECOVER utilities

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-12. DB2’s responsibilities - PERFORMANCE CV8317.0

Notes:

The program formulates WHAT it wants by coding an SQL request.

The system will have to find out HOW to get to the data the most efficient way.

The traditional program compilation process will have to perform some additional work if SQL statements are included in the program. The most important one is called the BIND, during which DB2 will do access path selection.

BIND will create an executable access path that will be stored in DB2's control data sets. Later, at execution time, DB2 will simply "load" that access path into storage and execute it.


Program DB2

WHAT

LoadModule

AccessPathEXECUTION Catalog

Statistics

BIND

HOW

Optimizer

DB2 must translate a user’s or program’sSQL request into ACCESS STRATEGIES

DB2’s responsibilities - PERFORMANCE

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-13. DB2’s responsibilities - METADATA CV8317.0

Notes:

Another responsibility of the DBMS is to manage its objects, programs, program-to-object dependencies, security, and so on.

It therefore stores all metadata concerning objects and programs, in its catalog and directory.

The Catalog

This is a set of DB2 tables at the heart of the DB2 system used by both the DB2 system and authorized SQL users

• Data definitions of tables, views, columns, indexes etc. These definitions are used, for example, by DB2 when processing SQL

• Security definitions of privileges / authorizations granted to users. By querying the catalog with SQL you can find out who can access what

• Recovery data has, for example, details of backups taken and this information is used for recovery


DB2

CATALOG

DataDefinitions

SecurityDefinitions

RecoveryInformation

SystemAdministrator

DatabaseAdministrator

ApplicationProgrammer

S Q L

DB2 uses a centralized CATALOG and DIRECTORY

DB2’s responsibilities - METADATA

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• Statistical data such as the number of rows in tables, key ranges etc. These statistics are updated by the RUNSTATS utility and they are used by the DBA to decide, for example, whether to REORG and they are used by DB2, for example, to choose the best access path to data.

You can query the catalog tables with SQL

The DB2 catalog is in database DSNDB06.

The Directory

The directory contains further metadata used mostly by DB2.

You can access parts of the directory using commands. For example, you can monitor the status of a utility as it runs.

The DB2 directory is placed in database DSNDB01.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 1-14. DB2 for z/OS data sharing CV8317.0

Notes:

The data sharing function of DB2 for z/OS enables applications that run on more than one DB2 for z/OS system to read from and write to the same set of data concurrently.

DB2 for z/OS systems that share data must belong to a DB2 data sharing group which runs on a Parallel Sysplex. A Parallel Sysplex is a cluster of z/OS systems that communicate and co-operate with each other.

Each DB2 for z/OS system that belongs to a particular data sharing group is a member of that group. All members use the same shared catalog.

You don’t need to change the SQL in your applications to use data sharing.

The primary advantage of data sharing is improved availability. If one system goes down temporarily then you can continue to access the same DB2 data via the other members.


• Improved availability• Huge queries feasible• SYSPLEX hardware required• Single shared catalog

• Incremental processing growth• Configuration flexibility• Dynamic workload balancing

z/OS

DB2 DB2 DB2

DB2 SHAREDDASD

DB2

DB2 DB2 DB2

z/OS z/OS

z/OS z/OS

z/OS z/OSz/OS

DB2 for z/OS data sharing

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 1-15. Roles and interfaces in DB2 CV8317.0

Notes:

This course is targeted to an audience of DB2 database administrators and system administrators. Database administrators will:

• In development:

- Support the application/development population in the more technical domains - Be involved in the database design - Create DB2 objects - Participate in application design reviews - Provide information to the SYSADM regarding DASD requirements, number of

users, types of transactions, logging requirements, data loading, and archiving requirements

- Design the methods to create test data - Be responsible for adhering to the system authorization procedures and guidelines

established by the SYSADM


FunctionalDesigner

Programmer

TechnicalDesigner

DatabaseAdministrator

SystemAdministration

SecurityAdministrator

DataAdministrator

CapacityPlanner

z/OSSysprog

CICS/IMSSysprog

TPSpecialist

Operations

Roles and interfaces in DB2

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

1-22 D

E

• In production:

- Support the applications as they are put into production - Manage the data resources and programs (compilations) - Tune the database objects using the DB2 utilities such as REORG and RUNSTATS - Cooperate with the development DBAs to define recovery and security procedures - Be responsible for loading data into the production tables - Be responsible for adhering to the security procedures established with the

development DBA and the SYSADM - Ensure that all system problems are correctly reported, and that fixes do not impact

the production environment.

System administrators:

• Are responsible for monitoring and controlling the DB2 subsystem operation and resources

• Provide information to capacity planners • Define and adjust system parameters • Tune DB2 at the system level • Define acceptable performance criteria • Are responsible for directing the DB2 operator and system programming activities • Are responsible for directing DB2 Recovery, data integrity, and data security • Are responsible for the backup and maintenance of the DB2 catalog • Define naming standards for programs, data objects, and so on. • Install, update, and migrate DB2 subsystems • Generally serve as the help desk, as a last resort.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


B2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


Uempty

E

Figure 1-16. Unit summary CV8317.0

Notes:


Having completed this unit, you should be able to:


– Users

– Data


– System

Having completed this unit, you should be able to:


– Users

– Data


– System

Unit summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 2. Setting up a DB2 database


This unit describes how to implement a DB2 database.



• Describe the DB2 objects that make up a DB2 database • Select parameters for these DB2 database objects so that they are

implemented with the most appropriate attributes • Create storage groups, databases, table spaces, tables, views,

synonyms, aliases, materialized query tables, and indexes • Alter the attributes of DB2 database objects as requirements

change over time • Describe how data is stored in a DB2 database


Accountability:

• Machine exercises

References

GC19-2985 DB2 10 for z/OS What’s New?

SC19-2968 DB2 10 for z/OS Administration Guide

SC19-2983 DB2 10 for z/OS SQL Reference

GC18-9856 DB2 Version 9.1 for z/OS What’s New?

SC18-9840 DB2 Version 9.1 for z/OS Administration Guide

SC18-9854 DB2 Version 9.1 for z/OS SQL Reference

GC18-7428 DB2 UDB for z/OS Version 8 What’s New?

SC18-7413 DB2 UDB for z/OS Version 8 Administration Guide

SC18-7426 DB2 UDB for z/OS Version 8 SQL Reference

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 2. Setting up a DB2 database 2-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe the DB2 objects that make up a DB2 database• Select parameters for these objects so that they are

implemented with the most appropriate attributes• Create storage groups, databases, table spaces, tables,

views, synonyms, aliases, materialized query tables, and indexes

• Alter the attributes of DB2 database objects as requirements change over time

• Describe how data is stored in a DB2 database

After completing this unit, you should be able to:• Describe the DB2 objects that make up a DB2 database• Select parameters for these objects so that they are

implemented with the most appropriate attributes• Create storage groups, databases, table spaces, tables,

views, synonyms, aliases, materialized query tables, and indexes



Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.1. Overview of setting up a DB2 database

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-2. Objects used by DB2 CV8317.0

Notes:

This is an introduction to storage groups, databases, table spaces, tables, indexes (in index spaces), views, synonyms, aliases, and materialized query tables (MQT).

• Database

- A collection of table spaces and index spaces grouped together to facilitate operations and security

• Table space

- An area of external storage used to store the records of one or more tables

• Index space

- An area of external storage used to store the entries of one index

• Index

- An ordered set of key values and pointers to the rows containing those keys


TableTable

Table

Viewsand

MQTs

Synonyms and Aliases

TableV_LONG_TABLE_NAME

SELECT * FROM T1

Hi-levelqualifier

Hi-levelqualifier

DB2 Storage Group

DatabaseTable Space

Table

IndexSpace

Index

...

Objects used by DB2

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• Storage group

- A set of volumes from which DB2 can assign space for table spaces and index spaces

• View

- A virtual table defined by a select statement that identifies some or all of the rows / columns of one or more tables

• Synonym

- A private nickname for a local table, local view, or local materialized query table

• Alias

- A system-wide nickname for a table, view, or materialized query table. Can be used for local or remote objects

• Materialized query table

- A materialized query table is a table that contains pre-computed data from other tables / views

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-3. Defining DB2 objects CV8317.0

Notes:

You use the SQL language to create, alter, and drop DB2 objects such as storage groups, databases, table spaces, tables, indexes, views, materialized query tables, aliases, and synonyms.

DB2 automatically records information about the DB2 objects you set up or change in one or more of the DB2 catalog tables. In some cases, information is also recorded in the VSAM catalog. When you drop a DB2 object, the information is automatically removed.

Some of the catalog tables are shown in the visual. All of the DB2 catalog table names are prefixed with SYSIBM.

For a complete description of the DB2 catalog tables and their contents, you should refer to the SQL Reference manual.

These objects can be set up using SPUFI, QMF, DSNTEP2, DSNTEP4, etc.


• Create Stogroup

• Create Database

• Create Table

• CreateIndex

• CreateView

• CreateAlias

• CreateSynonym

• SYSSTOGROUP

• SYSDATABASE

• SYSTABLESPACE• SYSTABLEPART

• SYSTABLES• SYSCOLUMNS

• SYSINDEXES• SYSINDEXPART

• SYSVIEWS• SYSSYNONYMS• SYSTABLES

DB2 CATALOGDSNDB06

DB2 Storage Group

Database Table Space

Table

IndexSpace

Index

VSAMCATALOG

• Create Tablespace

Hi-levelqualifier

Hi-levelqualifier

…

Defining DB2 objects

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-4. Owner concept - example CV8317.0

Notes:

A DB2 object has an owner.

For example, a DB2 table has an owner and is recorded in the OWNER column of the DB2 catalog table SYSIBM.SYSTABLES.

The complete table name has three qualifiers: first the location, second the schema name, and last the table name. When the table is at your local DB2 subsystem, you do not have to specify the location.

In this course we consider local objects.


CREATE TABLE EMP(EMPNO CHAR(6) NOT NULL,FIRSTNME VARCHAR(12),. . .

IN DBX.TSX

BART.EMP

COMPLETE TABLE NAME:OWNER_name.TABLE_name

BART

Owner concept – example

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-5. Owner’s privileges CV8317.0

Notes:

An owner is a concept that relates to DB2 security. The owner of an object has the right of life and death over that object. The owner can use, modify, or destroy the object which they own. The owner can also decide who else should be able to work with the object.

The visual illustrates this by showing how table owner (Bart) grants the SELECT privilege on his table to another person (Lisa).


SELECT…FROM EMP ;GRANT SELECTON EMPTO LISA

BART LISA

SELECT ...FROM BART.EMP

BART.EMP

Owner’s privileges

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-6. DB2 naming rules CV8317.0

Notes:

The DATABASE name and STORAGE GROUP name must be unique within the DB2 system. For other objects indicated above, the qualified name must be unique.

SCHEMA qualifies the object and by default is the same as the object owner (authorization ID). The relevant columns In the DB2 catalog are CREATOR and OWNER. Some catalog tables have only CREATOR column and some have both CREATOR and OWNER columns.

Begin all object names with an alphabetic character (A-Z, #, $, @) followed by any alphanumeric characters (A-Z, #, $, 0-9, @, _)

The name for a database and table space can be up to a maximum of 8 characters. The name of other objects on the visual can be up to a maximum of 128 characters. Index space name is generated by DB2 when the index is created.


COLUMN

Qualifies

QualifiesQualifies

DB2 naming rules

STORAGE GROUP and DATABASE no Qualifier

DATABASE TABLESPACE

SCHEMA TABLE

VIEW

SYNONYM

ALIAS

INDEX

INDEXSPACEQualifies

DATABASE

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.2. Storage groups, databases, and table spaces

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-7. DB2 Storage Group CV8317.0

Notes:

A DB2 storage group is a named set of disk volumes, in which DB2:

• Allocates storage for table spaces and indexes

• Defines, extends, alters and deletes the necessary VSAM data sets

The volumes are associated with an ICF catalog or VCAT. The ICF catalog stores entries for all data sets that DB2 creates on behalf of a storage group.

VCAT

The VCAT parameter is used to specify the ICF high-level qualifier of the catalog name or alias.

SYSDEFLT

SYSDEFLT is the default DB2 storage group and is created when DB2 is installed. It is used whenever a storage group is not explicitly specified in CREATE DATABASE,CREATE TABLESPACE, or CREATE INDEX.


DB2 Storage Group

Default: SYSDEFLT

Tablespace

Table

VSAM data set:‘hlq1 . xxxxxxxxxx‘

CREATE STOGROUP SG2 VOLUMES(VOL001,VOL002...) VCAT hlq1;

ALTER STOGROUP SG2ADD VOLUMES (VOL007, VOL008)REMOVE VOLUMES(VOL001);

VOL001 VOL002 ...SG2: DB2-managed datasets

CREATE STOGROUP SG1 VOLUMES(‘*‘) VCAT hlq1;

-- also possible:CREATE STOGROUP SG1 VOLUMES(‘*‘) VCAT hlq1DATACLAS(dc1) MGMTCLAS(mc1) STORCLAS(sc1); ...

SG1: SMS-managed datasets

Purpose:Simplify VSAM data set creationby specifying:

• high-level qualifier• list of volumes

- if SMS not used

Syntax:

non-SMS

SMS

DB2storagegroup:hlq1

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The two main options for managing DB2 data sets in DB2 storage groups are:

1. SMS-managed DB2 data sets

When defining DB2 storage groups, use the VOLUMES(’*’) attribute on the CREATE STOGROUP statement to let SMS (a z/OS component) control the selection of volumes during allocation.

CREATE STOGROUP SG2 VOLUMES('*') VCAT VCATID;

If your installation uses SMS the following applies:

• If your SMS setup (more precisely the SMS ACS routines written by your SMS administrator) is such that DB2 data is SMS-managed, the volumes in the DB2 storage groups may be overridden by SMS at allocation time. If this is the case, it is strongly recommended to define your storage groups with VOLUMES(‘*’) to avoid having volumes in catalog table SYSIBM.SYSVOLUMES that do not correspond to the volumes that are really used to store DB2 data sets.

• SMS ACS routines could be written in the following way:

- If VOLUMES(‘*’) is used, SMS assigns a volume.

- If VOLUMES(volser,...) is used, SMS tries to allocate the DB2 data set on the specified volumes.

Note

The data class, management class and storage class for these SMS managed data sets are specified in SMS ACS routines. You can also specify these classes in the CREATE STOGROUP statement. There are three keywords in the syntax. You can specify just one, two or all three of them in the CREATE STOGROUP statement:

• DATACLAS dc-name

SMS data classes influence characteristics such as the data set control block (DCB), striping, extended format usage, extended addressability usage and so on.

• MGMTCLAS mc-name

Management classes define the data sets frequency of volume backups, migration requirement and things like that.

• STORCLAS sc-name

Among other things, storage classes can for example define guaranteed space requirements.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

2. DB2-managed DB2 data sets

CREATE STOGROUP SG1 VOLUMES(VOL001,VOL002,....) VCAT VCATID;

VOLUMES

A volume assigned to a storage group is not dedicated to it. Non-DB2 data sets can be allocated on the volume and a volume can be assigned to more than one storage group.

The maximum number of volumes that can be managed for a storage group is 133. The volumes must be of the same device type. The maximum number of volumes that can be allocated per data set is 59.

Typically, the systems administrator creates storage groups.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-8. DB2 database CV8317.0

Notes:

A database is a collection of table spaces and index spaces grouped together for organizational purposes and operational convenience.

It is recommended that you organize databases by application or by, say, QMF user.

CREATE DATABASE DB1 STOGROUP SG1 BUFFERPOOL BP1 INDEXBP BP2 CCSID EBCDIC;

The STOGROUP, BUFFERPOOL, and INDEXBP parameters establish default storage groups and buffer pools for objects created in the database.

CCSID specifies the default encoding scheme for data stored in the database.

The defaults for the database may be overridden for the individual objects defined in the database. But note that an index always has the same encoding scheme as its associated table and that all tables in a table space always have the same encoding scheme.


DatabaseTable Space

Table

Table Space

Table

IndexSpace

Index

Table Space

TableIndexSpace

IndexIndexSpace

Index

IndexSpace

Index

VSAMLDS

VSAMLDS

Default Storage Group

BP1

BP2

ASCII,EBCDIC,Unicode

Default BUFFERPOOL

Default INDEXBP

DefaultEncoding Scheme

DB2 database

CREATE DATABASE USDB1 BUFFERPOOL BP1 INDEXBP BP2

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

The STOGROUP, BUFFERPOOL, INDEXBP, and CCSID parameters can be altered using ALTER DATABASE.

ALTER DATABASE DB1 STOGROUP SG3 BUFFERPOOL BP4 INDEXBP BP6;

The database name can be a maximum of 8 alphanumeric characters. It must be unique within the DB2 subsystem. It has no prefix.

DSNDB04

DSNDB04 is used when you issue a CREATE TABLESPACE without IN clause or a CREATE TABLE ... IN table-space-name.

It is recommended you always explicitly specify a database name.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-9. DB2 buffer pools (1 of 2) CV8317.0

Notes:

DB2 buffer pools

Buffer pools are areas of virtual storage that temporarily store pages of:

• Table spaces and / or

• Indexes.

When an application program accesses a row of a table, DB2 places the data page that contains that row in a buffer. If the requested data is already in a buffer, the application program does not have to wait for it to be retrieved from disk. Avoiding the need to retrieve data from disk results in faster performance.

The data remains in the buffer until DB2 decides to use the space for another page. Until that time, the data can be read or changed without a disk I/O operation.

If the row is changed, the data in the buffer must be written back to disk eventually. But that write operation might be delayed until, for example, a time determined by DB2.


Program

BP2 BP8K2

DB2 DBM1 Address Space

Long Row

Short Row

SELECT...

SELECT...

...

CREATE TABLESPACE TS1IN DB1USING STOGROUP SG1

BUFFERPOOL BP2

CREATE TABLESPACE TS2IN DB1USING STOGROUP SG2

BUFFERPOOL BP8K2

CI_1

CI_2

CI_3

CI_4

CI_5

CI_6

TS2CI_5 CI_9

CI_ACI_BCI_C

CI_1

CI_2 CI_3

CI_5

CI_4

CI_6CI_7CI_8

TS1

VSAM Data Set 1 VSAM Data Set 2

DB2 buffer pools (1 of 2)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-10. DB2 buffer pools (2 of 2) CV8317.0

Notes:

Numbers and sizes of DB2 buffer pools

DB2 allows you to use:

• Up to 50 buffer pools called BP0, BP1, BP2,........, BP49 which contain 4 KB buffers and

• Up to 10 buffer pools called BP8K0, ..... , BP8K9 which contain 8 KB buffers and

• Up to 10 buffer pools called BP16K0, ...... , BP16K9 which contain 16 KB buffers and

• Up to 10 buffer pools called BP32K, BP32K1, .......... , BP32K9 which contain 32 KB buffers.

Note

Do not confuse BP32 which contains 4 KB pages with BP32K which contains 32 KB pages.


DB2 buffer pools (2 of 2)

• Numbers and sizes of DB2 Buffer Pools– BP0, BP1, BP2,........, BP49 which contain 4 KB buffers– BP8K0, ..... , BP8K9 which contain 8 KB buffers– BP16K0, ...... , BP16K9 which contain 16 KB buffers– BP32K, BP32K1, .......... , BP32K9 which contain 32 KB buffers

• Do not confuse BP32 with BP32K

• Catalog uses BP0, BP8K0, BP16K0, and BP32K• Size of a TS data page and index page determined by

buffer pool• VSAM CI sizes of 4 KB, 8 KB, 16 KB, or 32 KB

– Only for table spaces– Can improve query performance

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

You can set the size of each of these buffer pools (and many other buffer pool parameters) separately using the -ALTER BUFFERPOOL command.

DB2 stores buffer pool attributes in a DB2 data set called the DB2 bootstrap data set (BSDS).

You may choose a single 4 KB buffer pool, say, for a test DB2 system or you may choose more than one buffer pool, say, to isolate indexes from data.

Whether you choose to set up one or many 4 KB buffer pools, DB2 also requires you to define BP32K because some SQL operations, such as joins, can create a result row that does not fit into a 4 KB page. You must also have BP0, BP8K0 and BP16K0 defined for the catalog.

Assigning a table space or index to a buffer pool

You assign a table space or an index to a particular buffer pool with:

• CREATE / ALTER TABLESPACE BUFFERPOOL BPn

• CREATE / ALTER INDEX BUFFERPOOL BPn

• CREATE / ALTER DATABASE BUFFERPOOL BPn

- Can specify the default buffer pool to be used for table spaces and indexes created in the database.

A default buffer pool for user data and one for user indexes can also be specified at install time.

The buffer pool is actually allocated the first time a table space or index assigned to it is opened.

DB2 catalog uses buffer pools BP0, BP8K0, BP16K0, and BP32K.

Choosing a buffer pool for user data and indexes other than those used by the Catalog is a good idea. It is much more difficult to monitor and tune if user data and indexes share the same buffer pools.

Data page or index page size

The size of a data page or an index page is determined by the buffer pool to which you assign the table space or index. For example:

• A table space has 4 KB data pages when it is defined in a 4 KB buffer pool and 8 KB data pages when it is defined in an 8 KB buffer pool.

Table spaces and indexes can be in 4 KB, 8 KB, 16 KB, or 32 KB buffer pool.

A good starting point is to use 4 KB page sizes when access to the data is random and only a few rows per page are needed. If row sizes are very small, using the 4 KB page size is recommended.

As a row cannot be split over two or more pages, the page size must be able to contain at least one row.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

VSAM control intervals

A VSAM control interval (CI) is an area on disk in which VSAM stores records. It is the unit of I/O between the disk subsystem and the DB2 buffer pool.

DB2 can define data sets with VSAM CI sizes of 4 KB, 8 KB, 16 KB or 32 KB.

This is controlled with a DSNZPARM parameter DSVCI. With the default, a DB2–managed data set is created with a VSAM control interval that corresponds to the size of the buffer pool that is used for the table space. Otherwise, you can specify that a DB2–managed data set is always created with a fixed VSAM CI of 4 KB, regardless of the size of the buffer pool used for the table space.

For example, a table space with pages 16 KB in size can have a VSAM CI of 4 KB or 16 KB.

Control interval sizing has no impact on indexes. VSAM data sets for indexes have always a CI size of 4 KB.

One of the biggest benefits of this change is an improvement in query processing performance.

ALTER BUFFERPOOL command

Authorized users can change the sizes and other characteristics of a buffer pool at any time while DB2 is running, by using the ALTER BUFFERPOOL command.

DISPLAY BUFFERPOOL command

Authorized users can display the current status of one or more buffer pools by using the DISPLAY BUFFERPOOL command.

TS Page Size Default CI Size Compatible CI Sizes4 KB 4 KB 4 KB8 KB 8 KB 4 KB, 8 KB16 KB 16 KB 4 KB, 16 KB32 KB 32 KB 4 KB, 32 KB

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-11. EBCDIC, ASCII, and Unicode CV8317.0

Notes:

Unicode is an encoding scheme that supports all:

• Countries, languages, platforms, technical characters, punctuation marks, all accessible by people anywhere

Unicode meets the needs of:

• Multinational corporations

• e-commerce

Goal is to provide:

• Single, unique definition (code point) for every character in the world

The Unicode standard is published by the Unicode Consortium, http://www.unicode.org


EBCDIC, ASCII, and Unicode• EBCDIC

– Mainframe data sets in most cases

• ASCII– PCs and workstations store

data using ASCII

• UNICODE – All countries, languages, platforms,

technical characters, punctuation marks, and so forth

– Single, unique definition (code point) • For every character in the world

– Specify at table space level

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-12. Administration at the database level CV8317.0

Notes:

Database administration (DBADM) authority can be granted at the database level.

If you have DBADM authority, you can create, alter, and drop objects in the database, use utilities on the objects, and execute commands on the objects such as DISPLAY, STOP, and START.


Tablespace

Table

Database Table Space

TableTable Space

Table

Table Space

Table

IndexSpace

IndexIndexSpace

IndexIndexSpace

Index

IndexSpace

Index

• GRANTs at the database level

• Commands at the database level– DISPLAY DATABASE(...........)

SPACENAM(..........)– STOP DATABASE(...........)

SPACENAM(..............)– START DATABASE(...........)

SPACENAM(..............)

Administration at the database level

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-13. DB2 table spaces CV8317.0

Notes:

DB2 tables are stored in z/OS data sets. A table space serves as a means to specify within DB2 how this logical structure of a table should be mapped to the physical structure of a data set. Therefore, a table is related to (resides in) a table space which in turn controls (resides in) a data set. To be precise, many tables can be stored in a table space, or a table space can be stored in many data sets.

Typically, you do not define these data sets by yourself. Instead, when you create a table space in DB2, you define, for example, how many data sets DB2 should define for a given table, perhaps where these data sets should reside, how much data should be transferred by a single I/O operation, and other parameters (like locking, freespace) on how DB2 should process the data.

DB2 only uses VSAM LDS (Virtual Storage Access Method – Linear Data Set) data sets for your table spaces.

Table spaces are divided into pages, and you can specify a page size of 4, 8, 16, or 32 K. For the table spaces we discuss in this course, a table row must completely fit into one page. Thus, only large table rows require page sizes of more than 4 K.


DB2 table spaces

What is a table space?

• DB2 storage structure

• Contains the data rows for one or more tables

• Resides in a page set of one or more VSAM linear data sets– Page size is 4 (usually), 8, 16, or 32 K

• Created in a database using SQL

Table space

Table

VSAM linear data set

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-14. Types of table spaces CV8317.0

Notes:

You need to decide which type of table space is best for each of your tables. When you have made a decision, there are then many parameters to select so that your table spaces are managed by DB2 in the best way.

It is always best to explicitly specify parameters when you create a table space, otherwise defaults apply (including which type of table space is used), and these may not always be the best for your table spaces.

Simple table space

Since V9, this type of table space cannot be created any more. But because existing simple table spaces can still be used and as its internal structure is used in classic partitioned table spaces, this type is described here. A simple table space can hold one or more tables. A page can contain rows from different tables.


Types of table spaces

• Simple table space

• Segmented table space

• Partitioned table space (“classic“ partitioned table space)

• Universal table space (UTS) – partition-by-growth (PBG)

• Universal table space (UTS) – partition-by-range (PBR)

• LOB table space

• XML table spaceSee other courses}

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Segmented table space

This can hold one or more tables. The table space is divided into SEGMENTS of from 4 to 64 pages. Each segment is dedicated to a single table, but a table can occupy many segments. This internal structure offers processing advantages over a simple table space.

Classic partitioned table space

This can hold only one table. The table space is divided into parts (partitions). Each partition is stored in a separate VSAM linear data set.

Advantages:

1. A classic partitioned table space can hold more data

2. Individual partitions can be processed

3. Partitions can be processed in parallel.

Universal table space – partition-by-growth (UTS PBG)

Enhanced version of a segmented table space in that it can hold more data and offers many advantages due to partitioning (similar to classic partitioned table space or UTS PBR). Can only hold one table.

Universal table space – partition-by-range (UTS PBR)

Enhanced version of a classic partitioned table space. Each partition has the internal structure of a segmented table space (whereas each partition of a classic partitioned table space has the structure of a simple table space).

LOB table space, XML table space

You can store large movies, pictures, text documents (so called large objects, LOBs) or XML documents in specialized table columns with a data type of LOB or XML. Because the values in those columns do not fit into one page, such objects are stored in separate, either LOB or XML table spaces. Depending on its size, a LOB can now reside completely in the base table space along with other non-LOB columns. They are explained in other courses.xc

lusivo

form

ación

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-15. Simple table space CV8317.0

Notes:

Rows from multiple tables can be interleaved on each data page. For example, a row from the DEPT table can be followed by multiple rows from the EMPLOYEE table. This would result in more efficient processing if you wanted to select, say, rows from each department table together with the corresponding rows from the employee table.

The interleaving of rows is something you would need to set up and manage. DB2 does not maintain the interleaving for you during SQL INSERT.

For a simple table space with multiple tables:

• A table space scan scans rows of all tables, even if you are interested in the rows of only one table.

• There is no lock at the table level.

• REORG is needed to reclaim space after DROP TABLE.

If your installation has been using DB2 for many years, you may find some simple table spaces still in use.


Simple Table SpaceDept Table

Employee Table

• One or more tables– No limit

• Rows from multiple tables can beinterleaved

=DEPT Row

=EMPLOYEE Row

Header

Space Map

Data Page

Simple table space

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-16. Segmented table space CV8317.0

Notes:

A segmented table space is divided into SEGMENTS. A segment can consist of 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, or 64 pages. You specify the segment size with the SEGSIZE parameter. Your choice of SEGSIZE should be determined by the table size. The SEGSIZE applies to all tables in the table space. Each segment is dedicated to a table.

A table space scan scans only the segments of the table being processed.

You can specify a lock size of TABLE (see later).

A REORG is not necessary to reclaim space occupied by a dropped table. However, a REORG is necessary to reclaim space from a mass delete.

The space map is used to avoid scanning empty segments and segments containing only deleted rows.

When you take a full image copy, the COPY utility does not copy empty pages due to a dropped table or mass delete.


Segment 3

Header

Space Map

Data Page

Segment 1

Segment 2

• One or more tables– No limit

• Divided into segments– Each segment

dedicated to a table– A table can occupy

multiple segments– SEGSIZE must be a

multiple of 4 between 4 and 64 (inclusive)

=DEPT Row

=EMPLOYEE Row

Segmented Table Space

Dept Table

Employee Table


xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Detailed information is available in the space map to locate free space for variable length rows and to maintain the clustering sequence (see later).

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-17. Single and multiple-table table spaces CV8317.0

Notes:

With single-table table spaces you can give each table its own attributes.

Utilities, such as REORG, RUNSTATS, COPY, and RECOVER, operate at the table space or partition level. With single-table table spaces, you can run these utilities for individual tables.

With multiple-table table spaces, you need to set up and run fewer utilities, and it can be easier to keep related tables in step.


Single and multiple-table table spaces

• Single– Each table can have different attributes

• Space allocations• Buffer pool assignments

– Can schedule utilities at table level– Pending states (see later) limit availability of only one table

• Multiple– Need to run fewer utilities– Easier to keep related tables in step

• Especially backup and recovery– Good for small reference tables

• Avoids header / space map for each table

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-18. Segmented table space - sample definition CV8317.0

Notes:

The IN clause of the CREATE TABLESPACE statement specifies the database.

The USING STOGROUP clause specifies the storage group that is used for space allocation of the table space.

Most parameters you specify on CREATE TABLESPACE can be changed with ALTER TABLESPACE. But there are exceptions.

Note

You can execute the CREATE TABLESPACE statement without specifying the SEGSIZE clause successfully. However, what is created is not a simple table space, but a segmented table space with SEGIZE 4.

If you execute the CREATE TABLESPACE statement without specifying the IN clause, the table space is created in the default database DSNDB04.


Segmented table space – sample definition

CREATE TABLESPACE USTS2IN USDB1USING STOGROUP USCV831S

SEGSIZE 64BUFFERPOOL BP2FREEPAGE 4 PCTFREE 20MAXROWS 255LOCKSIZE ANYCCSID EBCDIC;

PRIQTY 14400SECQTY 720ERASE NO

CREATE TABLESPACE USTS1IN USDB1 ;

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-19. Segmented table space - maximum size CV8317.0

Notes:

The data set of a segmented table space can grow up to 2 GB.

If more data is added to its tables, DB2 automatically creates a continuation data set, if PRIQTY and SECQTY are big enough.

But DB2 does not allocate more than 32 data sets for a segmented table space, thus the maximum size of a segmented table space is 64 GB.


Segmented table space – maximum size

Segmented table space (single data set max. 2 GB):

max. 32 data sets....................................

2 GB 2 GB 2 GB 2 GB 64 GB

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-20. Classic partitioned table space CV8317.0

Notes:

A classic partitioned table space contains one table only. It is divided into parts (partitions). Each partition is stored in a separate VSAM linear data set. CREATE TABLE specifies the partitioning key and the partition boundary values.


Space Map

Data Page

4th Data Partition(Data set)

• Header

Space Map

• Header

Data Page

2nd Data Partition(Data set)

1st Data Partition(Data set)

Space Map

Data Page

• Header

• One table only• Divided into parts (partitions)• Each partition is a VSAM data set• CREATE TABLE specifies:

–The partitioning key and–The partition boundary values

Table-Controlled Partitioning

Data Partition 1

EMPLOYEE Table (Partitioned by EMPNO)

Partitioned Table Space

Max EMPNO 099

Data Partition 2

Data Partition 3

Data Partition 4

Max EMPNO 199

Max EMPNO 299

Max EMPNO 999

Classic partitioned table space

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-21. Create a classic partitioned table space CV8317.0

Notes:

The CREATE TABLESPACE statement in the visual creates a classic partitioned table space with four partitions. This is shown by the NUMPARTS parameter.

The storage group, space allocation, and free space required for all partitions are also specified.

However, partitions 1 and 2 have been named separately. Different storage group, space allocation, free space, and compression parameters have been specified explicitly for these two partitions.

In DB2 10, if SEGSIZE is not specified, the value of DSNZPARM DPSEGSZ applies. If it is set to 0, a classic partitioned table space is created. If the DPSEGSZ value is greater than 0, a partition-by-range universal table space is created.

In DB2 9, SEGSIZE 0 is invalid and creating a partitioned table space without specifying SEGSIZE clause results in a classic partitioned table space.

The definition of the table space is incomplete until the partitioning key and partition boundaries are specified in the CREATE TABLE statement.


CREATE TABLESPACE USTS3 IN USDB1 USING STOGROUP USCV831S PRIQTY 14400 SECQTY 720 ERASE NO PCTFREE 20 FREEPAGE 4 SEGSIZE 0NUMPARTS 4

(PARTITION 1 USING STOGROUP USCV832S PRIQTY 7200 SECQTY 720 ERASE YES PCTFREE 15 FREEPAGE 8 COMPRESS YES,

PARTITION 2 USING STOGROUP USCV833SPRIQTY 7200 SECQTY 720 ERASE YES PCTFREE 25 FREEPAGE 2 COMPRESS YES)

BUFFERPOOL BP2;

Create a classic partitioned table space

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-22. Advantages of partitioning CV8317.0T

Notes:

There are many reasons why you would choose a partitioned table space to implement your data, and they are listed in the visual.


Advantages of partitioning

• Good for large volumes of data• As a rule-of-thumb, at least 10,000,000 rows or 0.5GB data

– Table space is in smaller, more manageable pieces– Can run utilities, commands or SQL independently at partition level

• Individual partitions can have different space allocations• Parallelism• Partition scan

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-23. Classic partitioned table space - Maximum size for NUMPARTS < 255 CV8317.0

Notes:

You may specify the maximum data set size per partition (DSSIZE option in the CREATE TABLESPACE statement). If you specify (or DB2 chooses) a DSSIZE value greater than 4G, the data sets for the table space must be associated with a DFSMS data class that has been specified with extended format and extended addressability.

For a classic partitioned table space, if DSSIZE is omitted, the default for the maximum size for each partition depends on the value of NUMPARTS. For example, if NUMPARTS is 65 to 254, the default partition size is 4 GB.

If you specify NUMPARTS 254 and DSSIZE 64G, the classic partitioned table space can grow up to almost 16 TB.


Classic partitioned table space –Maximum size for NUMPARTS < 255

Partitioned TS, without specifying DSSIZE:

almost 1 TB (1016 GB)4 GB65-254

64 GB1 GB33-64

64 GB2 GB17-32

64 GB4 GB1-16

Maximum size of table space

Maximum size per partition

NUMPARTS

If you specify DSSIZE nG [n=1,2,4,8,16,32, or 64],

then the maxiumum size is almost 16 TB.

(for NUMPARTS < 255)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-24. Classic partitioned table space - Maximum number of partitions CV8317.0

Notes:

If you specify NUMPARTS > 254, but do not specify DSSIZE, DB2 chooses DSSIZE according to the rule: DSSIZE = n GB if page size = n KB (for n = 4, 8, 16, or 32).

According to the above table, if you rely on the default DSSIZE, you can specify up to 4096 partitions for any page size.


Classic partitioned table space –Maximum number of partitions

If you specify NUMPARTS > 254 and do not specify DSSIZE,DB2 chooses a default DSSIZE (governed by page size) .

Depending on page size and DSSIZE, NUMPARTS can be up to:

2048102451225664 GB

40962048102451232 GB

409640962048102416 GB

40964096409620488 GB

40964096409640961-4 GB

32 K16 K8 K4 K

Page sizeDSSIZE

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-25. Classic partitioned table space - Maximum size for NUMPARTS > 254 CV8317.0

Notes:

Previously, we saw the maximum size of a classic partitioned table space with up to 254 partitions. This table lists the maximum size of a classic partitioned table space with more than 254 partitions. This maximum size depends on the page size, the DSSIZE and the number of partitions (remember, the maximum number of partitions itself depend on page size and DSSIZE).

For example, reaching a table space size of 128 TB with the maximum DSSIZE of 64 GB is possible only with 32 K page and 2048 partitions.


Classic partitioned table space –Maximum size for NUMPARTS > 254

Maximal table space size depends on page size and DSSIZE:

128 TB204864 GB32 KB128 TB409632 GB32 KB64 TB204832 GB16 KB64 TB409616 GB16 KB32 TB204816 GB8 KB32 TB40968 GB8 KB

4 TB40961 GB8 KB16 TB25664 GB4 KB16 TB51232 GB4 KB16 TB102416 GB4 KB16 TB20488 GB4 KB16 TB40964 GB4 KB

4 TB40961 GB4 KBMax TS sizeMax # of partitionsDSSIZEPage size

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-26. Partition-by-range universal table space (PBR) CV8317.0

Notes:

In contrast to a classic partitioned table space, each partition of a partition-by-range universal table space has the structure of a segmented table space. You easily create this type of table space when you specify both keywords, NUMPARTS and SEGSIZE in the CREATE TABLESPACE statement. Once you have created a partition-by-range universal table space, you can take any action that is allowed on classic partitioned or segmented table spaces. However, as for classic partitioned table spaces, only one table is allowed.

Some benefits of partition-by-range universal table spaces are:

• Better space management in conjunction with varying-length rows. This is because a segmented space map page has more information on free space than a classic partitioned space map page.

• Improved mass delete performance. Mass delete in a segmented table space organization tends to be faster than in other types of table space organizations such as classic partitioned table spaces.


Partition-by-range universal table space (PBR)

• Perfect mixture of classic partitioned and segmented table spaces

• To create, specify both, NUMPARTS and SEGSIZE on CREATE TABLESPACE

• One table per table space

• Better space management when using varying-length rows

• Better performance in mass delete operations

• Example:

CREATE TABLESPACE USTS5 IN USDB1USING STOGROUP USCV831SNUMPARTS 10 SEGSIZE 64 ;

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The example on the visual creates a partition-by-range universal table space, USTS5, in database USDB1 using storage group USCV831S. The table space has 64 pages per segment and has 10 partitions.

In DB2 10, if SEGSIZE is not specified, the value of DSNZPARM DPSEGSZ applies. If it is set to 0, a classic partitioned table space is created. If the DPSEGSZ value is greater than 0, a partition-by-range universal table space is created.

In DB2 9, SEGSIZE 0 is invalid and creating a partitioned table space without specifying SEGSIZE clause results in a classic partitioned table space.

Note

With a partition-by-range universal table space, you can also control the partition size, choose from a wide array of indexing options, and take advantage of partition-level operations and parallelism capabilities. You can immediately reuse all or most of the segments of a table after a mass delete has been performed.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-27. Partition-by-growth universal table space (PBG) CV8317.0

Notes:

The maximum size of a segmented table space is 64 GB.

If you want to have a segmented table space that can hold more than 64 GB, you must use a Universal Table Space (UTS) of type Partition-by-Growth (PBG).

Using ALTER TABLESPACE, you can increase, but not decrease the MAXPARTITIONS value.


Partition-by-growth universal table space (PBG)

2048102451225664 GB

40962048102451232 GB

409640962048102416 GB

40964096409620488 GB

40964096409640961 – 4 GB32 KB Page16 KB Page8 KB Page4 KB PageDSSIZE

What is it?• Similar to segmented table space, but allows for additional partitions• Starts as 1-partition table space, gets more partitions if data is added• Each partition can be up to a maximum of SEGSIZE• Created using MAXPARTITIONS clause on CREATE TABLESPACE• Maximum accepted number determined by page size and DSSIZE:

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-28. Partition-by-growth UTS - pros and cons CV8317.0

Notes:

The data structure of a partition-by-growth universal table space is that of a segmented table space. This structure is preferable over a simple table space or a classic partitioned table space because segmented table spaces have better space management and mass delete capabilities.

Begins small – as a one-partition table space. Grows only if needed. You do not have to allocate too much space at the beginning.

Additional partitions may become empty, but are not purged after a ROLLBACK or REORG or LOAD REPLACE.

Indexes on PBG UTS cannot be partitioned. The explanation of a “partitioned index” follows later.


Partition-by-growth UTS – pros and cons Useful for table spaces that:

• Do not have a suitable partitioning key (*)• Are expected to exceed the 64 GB limit

Can grow up to 128 TBAdvantageous data structure of a segmented table spaceBegins its life as single-partition table spaceAdditional partitions automatically created when more data is addedYou can increase MAXPARTITIONSYou can limit the number of partitions to prevent run-away applicationsMany capabilities of partition-level operations (*)

Once created partitions cannot be deleted if not needed anymore (*)You cannot decrease MAXPARTITIONSMust be storage-group controlledOnly NPIs allowed (*)

(*) see subsequent units

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-29. Create a partition-by-growth universal table space CV8317.0

Notes:

The first example on the visual creates a partition-by-growth universal table space that has a maximum size of 4 GB for each partition, 64 pages per segment with a maximum of 24 partitions for the table space.

Important

It is not possible to use ALTER TABLESPACE to reduce MAXPARTITIONS after the table space has been created.

Implicit creation: The default type of an implicitly create table space is partition-by-growth. If you want to influence the DSSIZE of your implicitly created table space, you can do so, as shown in the second example on the visual, by using the PARTITION BY SIZE clause in your CREATE TABLE statement. The syntax is PARTITION BY SIZE EVERY integer G. If you omit the EVERY integer G part of the syntax, the implicit table space defaults to


Create a partition-by-growth universal table space

• Create explicitly

CREATE TABLESPACE USTS4 IN USDB1 USING STOGROUP USCV831SDSSIZE 4G MAXPARTITIONS 24 SEGSIZE 64;

• Create implicitly

CREATE TABLE TB2(C1 SMALLINT, C2 DECIMAL(9,2))

PARTITION BY SIZE EVERY 1GIN DATABASE USDB1;

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

SEGSIZE 4, Maximum size of each partition 4 GB, and Maximum number of partitions set to 256.

If the limit of maximum 256 partitions is inadequate, you can increase it using ALTER TABLESPACE statement. Note as stated earlier, you cannot decrease the value.

Note

You have the option to partition according to data growth, which enables segmented tables to be partitioned as they grow, without the need for key ranges. As a result, segmented tables benefit from increased table space limits and SQL and utility parallelism that were formerly available only to partitioned tables, and you can avoid needing to reorganize a table space to change the limit keys.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-30. Default type of a table space CV8317.0

Notes:

The default type of a table space is segmented when issuing CREATE TABLESPACE (assuming you have specified neither NUMPARTS, nor MAXPARTITIONS, nor LOB).

Some applications may issue CREATE TABLE without specifying a table space. In this case, a table space is automatically created and it is not a segmented, but a partition-by-growth universal table space with MAXPARTITIONS 256. Note that this value cannot be decreased, only increased using ALTER TABLESPACE. Therefore, even if you want a PBG UTS, consider first to create the table space explicitly with a smaller MAXPARTITIONS value and then specify this table space in your CREATE TABLE statement in order to prevent run-away applications.

The default DSSIZE of 4 GB can be overridden by “PARTITION BY SIZE EVERY integerG” in the CREATE TABLE statement.


Default for implicitly created TS via CREATE TABLE:PBG table space with:

• SEGSIZE = 4

• DSSIZE = 4 GB

• MAXPARTITIONS = 256

Default type of a table space

Segmented table space with SEGSIZE 4

Not specifiedNot specified

PBG table space with SEGSIZE set by DSNZPARM DPSEGSZ

Explicitly specifiedNot specified

Segmented table spaceNot specifiedExplicitly specified

PBG table spaceExplicitly specifiedExplicitly specified

Type of table spaceMAXPARTITIONSclause

SEGSIZE clause

can be overridden by: PARTITION BY SIZE EVERY integer

Default for explicitly created TS via CREATE TABLESPACE:

can only be increased

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-31. SYSTABLESPACE catalog information CV8317.0

Notes:

Looking at the entries in the SYSIBM.SYSTABLESPACE catalog table, how do you determine whether a table space is simple, segmented, classic partitioned, universal (either partition-by growth or partition-by-range)?. You have to look at columns PARTITIONS, MAXPARTITIONS, SEGSIZE, and TYPE.

In this example, we have information about these table spaces as follows:

• USTS1 and USTS2 are segmented table spaces, because columns PARTITIONS and MAXPARTITIONS contain zero values, SEGSIZE contains a non-zero value, and TYPE is blank.

• USTS3 is a classic partitioned table space, because column PARTITIONS contains a non-zero value, and MAXPARTITIONS and SEGSIZE contain zero values, and TYPE is blank.

• USTS4 and TB2 are partition-by growth universal table spaces, because column TYPE shows ‘G’. For a partition-by growth universal table space, PARTITIONS shows the current number of partitions and MAXPARTITIONS shows the maximum number of


---------+---------+---------+---------+---------+------SEGSIZE PGSIZE TYPE STATUS IMPLICIT NTABLES DSSIZE

---------+---------+---------+---------+---------+------4 4 T N 0 0 64 4 T N 0 0 0 4 T N 0 064 4 G T N 0 4194304 4 4 G A Y 1 104857664 4 R T N 0 4194304

SELECT NAME, DBNAME,CREATOR,BPOOL,PARTITIONS,MAXPARTITIONS,SEGSIZE,PGSIZE,TYPE,STATUS,IMPLICIT,NTABLES,DSSIZEFROM SYSIBM.SYSTABLESPACEWHERE DBNAME = ‘USDB1’---------+---------+---------+---------+---------+---------+NAME DBNAME CREATOR BPOOL PARTITIONS MAXPARTITIONS ---------+---------+---------+---------+---------+---------+USTS1 USDB1 TSOUD01 BP1 0 0 USTS2 USDB1 TSOUD01 BP2 0 0 USTS3 USDB1 TSOUD01 BP1 4 0 USTS4 USDB1 TSOUD01 BP1 1 24 TB2 USDB1 TSOUD01 BP0 1 256 USTS5 USDB1 TSOUD01 BP1 10 0

SYSTABLESPACE catalog information• SYSIBM.SYSTABLESPACE

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

partitions to which it can grow. SEGSIZE shows the segment size and never contains zero value. For table space TB2, column IMPLCIT shows ‘Y’ indicating it was created implicitly.

• USTS5 is a partition-by-range universal table space, because column TYPE shows ‘R’. For a partition-by-range universal table space, PARTITIONS and SEGSIZE always contain non-zero values and MAXPARTITIONS always contains zero value.

Notice the value in the STATUS column.

• For segmented table spaces USTS1 and USTS2, and classic partitioned table space UTS3, initially the value is ‘T’ and later changed to ‘A’ when tables are created in these table spaces.

• For table space USTS4, initially the value is ‘T’, indicating that the definition is incomplete because no table has been created in this table space. The value changes from ‘T’ to ‘A’ when the table is created.

• For table space TB2, the value is ‘A’ indicating for the implicitly created partition-by-growth universal table space, the table space is available since the table is already created. Notice for the implicitly created partition-by-growth universal table space, SEGSIZE is 4 and MAXPARTITIONS is 256.

• For table space USTS5, initially the value is ‘T’ and later changed to ‘A’ when a table-controlled partitioned table is created in the table space.

Notice the value in DSSIZE shows the maximum size of a data set in kilobytes. A zero value indicates that the table space is not greater than 64 GB.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-32. Space allocation CV8317.0

Notes:

The components of the USING STOGROUP clause are discussed below, first for nonpartitioned table spaces and then for partitioned table spaces. This is applicable to classic partitioned table spaces and universal table spaces (PBG and PBR).

USING STOGROUP clause for nonpartitioned table spaces:

For nonpartitioned table spaces, USING STOGROUP indicates the data set for the table space is defined by DB2. This clause also gives space allocation parameters.

PRIQTY

PRIQTY integer specifies the minimum primary space allocation for a DB2-managed data set.

1. If you specify PRIQTY with a value other than -1, the primary space allocation is at least n kilobytes, where n is the value of integer with the following exceptions:

- For 4KB page sizes, if integer is less than 12, n is 12.


CREATE TABLESPACE INVS0001IN INVDB11USING STOGROUP INVDG112

PRIQTY p (in kilo bytes)SECQTY s (in kilo bytes)

BUFFERPOOL ...

p p p

s

sINSERT, LOAD

Space allocation

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.




- For any page size, if integer is greater than 67108864, n is 67108864.

2. If you specify PRIQTY -1 or do not specify PRIQTY, actual primary quantity is determined as follows:

- If the TSQTY subsystem parameter value is specified and is greater than 0, actual primary quantity is at least the value of TSQTY.

- If the TSQTY subsystem parameter is not specified or is 0, actual primary quantity is one cylinder.

SECQTY

SECQTY integer specifies the minimum secondary space allocation for a DB2-managed data set.

1. If you do not specify SECQTY, the following formulas determine actual secondary quantity:

- If the maximum size of a data set in the table space is < 32 GB, the formula is:

actual secondary quantity in cylinders = MAX(0.1 * actual primary quantity in cylinders, MIN(calculated extent in cylinders,127))

- If the maximum size of a data set in the table space is >= 32 GB, the formula is:

actual secondary quantity in cylinders = MAX(0.1 * actual primary quantity in cylinders, MIN(calculated extent in cylinders,559))

The calculated extent in cylinders is arrived at by DB2 using a sliding scale. A sliding scale means that the first secondary extent allocations are smaller than later secondary allocations. For example, for the sliding scale of secondary extent allocations that DB2 uses for a 64-GB data set, the size of each secondary extent is larger for each secondary extent that is allocated up to the 127th extent. For the 127th secondary extent and any subsequent extents, the secondary size allocation is 559 cylinders.

2. If you specify SECQTY 0, the actual secondary quantity is 0.

3. If you specify SECQTY and the value is not 0 or -1, the following applies;

This is the only rule that depends on the value of subsystem parameter MGEXTSZ (field OPTIMIZE EXTENT on installation panel DSNTIP7).

If MGEXTSZ is YES:

- If SECQTY is specified and specified secondary quantity is not equal to -1 or 0, the following formulas determine actual secondary quantity:

• If the maximum size of a data set in the table space < 32 GB, the formula is:

actual secondary quantity in cylinders = MAX(MIN(calculated extent in cylinders,127),specified secondary quantity in cylinders)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• If the maximum size of a data set in the table space is >= 32 GB, the formula is:

actual secondary quantity in cylinders = MAX(MIN(calculated extent in cylinders,559),specified secondary quantity in cylinders)

If MGEXTSZ is NO:

- For a table space, if SECQTY is n, the secondary space allocation is at least n kilobytes, with the following exceptions:

• If SECQTY is greater than 4194304, n is 4194304 kilobytes.

Note

Executing the CREATE TABLESPACE statement causes only one data set to be created. However, you might have more data than this one data set can hold. DB2 automatically defines more data sets when they are needed. Regardless of the value in PRIQTY, when a data set reaches its maximum size, DB2 creates a new one. To enable a data set to reach its maximum size without running out of extents, it is recommended that you allow DB2 to automatically choose the value of the secondary space allocations for extents.

USING STOGROUP clause for partitioned table spaces:

If the table space is partitioned, there is a USING clause for each partition; either one you give explicitly or one provided by default. Except as explained below, the meaning of the clause and the rules that apply to it are the same as for a nonpartitioned table space.

The USING clause for a particular partition is the first of these choices that can be found:

• A USING clause in the PARTITION clause for the partition

• A USING clause that is not in any PARTITION clause

• An implicit USING STOGROUP clause that identifies the default storage group of the database and accepts the defaults for PRIQTY and SECQTY.

If you omit USING STOGROUP, DB2 defines the data sets using the default storage group of the database and the defaults for PRIQTY and SECQTY.

Preformatting

Two cylinders or tracks are preformatted at a time for table spaces when they are created. Preformatting means writing X'00' on the pages. Further preformatting can occur when an application is issuing, for example, SQL INSERTs, and this can be resource-intensive. You can minimize this by having the LOAD or REORG utilities preformat allocated space by specifying the PREFORMAT parameter.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-33. Space map page CV8317.0

Notes:

All pages of a table space have the same size, determined by the buffer pool.

After the header page (page 0) comes the space map page (page 1).

The space map pages tell DB2 where to find free space on the data pages that follow.

Space map for simple and classic partitioned table spaces

DB2 uses two bits to indicate whether space is available on a particular page for the largest, average, or smallest row, or whether the page is full.

The space map pages also tell the COPY utility which pages have been changed since the last copy. This information is used to determine which pages should be copied when making an incremental copy.

Each space map covers 10,760 4K pages. Space map pages may recur throughout the table space.


Space Map

DataPage

• Header

DataPage

DataPage DataPage

DataPage

xx space for :00 > max row size01 < max & >= avg row size10 < avg & >= min row size11 < min row size

xx .. .. ..

Page Header 26 bytes

One 2-bit entry

for each page

Free Space Status

x :0 not modified1 modified

x . . . One 1-bit entry

for each page

Page Status


One 7-byte entryfor each segment

Free Space Status

1-byte trailer

Seg 1 P1 Pn....

Seg 2 P1 Pn....And 4-bit entryfor each pagein the segment

x :0 not modified1 modified

x . . . One 1-bit entryfor each page

Page Status

1-byte trailer

• Simple and Classic Partitioned Table Space

Space map page

• Segmented and Universal Table Space

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Space map for segmented and universal table spaces

DB2 uses four bits to determine if there is space available on a particular page to insert or update a row.

The meaning of the bits is as follows:

0 - Page is empty and unformatted 1 - Page is emptied by mass delete 2 - Page is empty and formatted 3 - Page has space for longest row 4-10 Values used for placing variable length rows 11-14 For future use 15 - Page is full

The space map page is also used to identify the segments in a segmented table space.

The improved space map gives segmented table spaces an advantage over nonsegmented ones.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-34. Data page CV8317.0

Notes:

The first data page has page number 2 in the absence of other pages (for example, dictionary pages, see later).

Data pages have the same layout in all types of table space.

A table row consists of all the columns in the row plus a 6-byte prefix.

The row prefix has a 1-byte row type, a record length of 2 bytes, a 2-byte OBID, and a 1-byte map ID for the directory entry at the bottom of the page.

The page directory contains up to 255 map IDs, each of which is 2 bytes in length. This maximum number of directory entries corresponds to the maximum number of rows you can specify for a page with the MAXROWS parameter.

The last 2 bytes on the page contain the ID of the first free ID map entry (1 byte) and a check byte (1 byte).



2-byte trailer

Header ... Row Data

6 bytes

ID Map2 bytes/rowmax 255

X

FlagsLengthand so forth

Space Map

Data Page

• Header

Data Page

Data Page Data Page

Data Page

Data page

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-35. Free space CV8317.0

Notes:

Free space

The right amount of free space in data pages has a favorable influence on, for example, keeping rows in clustering sequence (see later) and managing variable length rows during SQL INSERT and UPDATE processing. This can improve performance.

On the other hand, over-allocation of free space can mean, for example, more pages to scan and less information transferred per I/O.

How do I specify my free space requirements?

You can use the PCTFREE and FREEPAGE clauses of the CREATE TABLESPACE statement to improve the performance of INSERT and UPDATE operations.

You can change the values of PCTFREE and FREEPAGE for existing table spaces using the ALTER TABLESPACE statement but the change has no effect until you load or reorganize the table space.

The space made available by deleted rows is eligible for reuse. Deleted rows are chained together, and the chain is anchored from the 20-byte page header.


NextLargehole

f LL Space

f

ts

Smallhole

Header

Total Free Space

Free Space

ID Map

Largehole

Free space

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

PCTFREE

This specifies what percentage of each page in a table space is left free when loading or reorganizing the data.

The first record on each page is loaded without restriction. When additional records are loaded at least the PCTFREE percentage of free space is left on each page.

The percentage can range from 0 to 99. The default for a table space is 5.

FREEPAGE

This clause specifies how often DB2 leaves a full page of free space when loading data or when reorganizing data. For example, if you specify 30 for FREEPAGE, DB2 leaves a free page for every 30 pages populated with data.

The default is 0. The maximum value you can specify for FREEPAGE is 255. However, in a segmented table space, the maximum value is 1 less than the number of pages specified for SEGSIZE.

Leaving and Using free space

The LOAD (except LOAD RESUME YES SHRLEVEL CHANGE) and REORG utilities leave free space, whereas INSERT and UPDATE use the free space in order to maintain the clustering sequence of the data.

Insufficient free space

When there is insufficient free space for SQL INSERTs and UPDATEs, DB2 may have to hold some of your data on a page other than the best page. This can cause performance problems. For example:

• An SQL INSERT causes DB2 to search for the best page to hold the row so that it can maintain the rows in clustering sequence (see later). If there is insufficient free space on the best page then DB2 has to choose a less favorable page.

• An SQL UPDATE can increase the length of a variable length row and if there is insufficient free space on the page to hold the expanded row then DB2 may have to place it on a neighboring, less favorable page.

Occurrences of records that have been inserted into or overflowed to pages other than their best pages are reported by real time statistics tables (see later) in REORGLEAFFAR and REORGNUMLEVELS in SYSIBM.SYSINDEXSPACESTATS, and REORGUNCLUSTINS and REORGFARINDREF in SYSIBM.SYSTABLESPACESTATS.

Free space is not necessary if, for example, the table space is read-only, inserts are in ascending order, and updates are only on fixed-length columns with non-compressed data.Exc

lusivo

form

ación

proy

ecto

C.F.T.I.C




Uempty

E

2.3. Tables

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-36. CREATE TABLE - column attributes CV8317.0

Notes:DATATYPE DESCRIPTION LENGTH/RANGE STORED AS -------- ----------- ------------- ---------- Numbers SMALLINT WHOLE NUMBERS (See note below) BINARY INTEGER WHOLE NUMBERS (See note below) BINARY BIGINT WHOLE NUMBERS (See note below) BINARY DECFLOAT DECIMAL (See note below) DECIMAL(x,y) PRECISION/SCALE 1 TO 31 DIGITS PACKED DECIMALREAL SINGLE PRECISION (See note below) 32 BITS DOUBLE DOUBLE PRECISION (See note below) 64 BITS Strings CHARACTER(x) FIXED LENGTH 1 TO 255 BYTES EBCDIC, ASCII or UNICODEVARCHAR(x) VARYING LENGTH 0 TO PAGE SIZE EBCDIC, ASCII or UNICODEBINARY(x) FIXED LENGTH 1 TO 255 BYTES NOT ASSOCIATED WITH ANY CCSIDVARBINARY(x) VARYING LENGTH 1 TO 32704 BYTES NOT ASSOCIATED WITH ANY CCSIDGRAPHIC(x) FIXED LENGTH 1 TO 127 CHARS DBCS VARGRAPHIC(x) VARYING LENGTH 0 TO PAGE SIZE DBCS DateTime values DATE ISO,USA,EUR,JIS 4 BYTES YYYYMMDD TIME ISO,USA,EUR,JIS 3 BYTES HHMMSS TIMESTAMP ISO,USA,EUR,JIS 10 BYTES YYYYMMDDHHMMSSNNNNNN TIMESTAMP may be defined with a user-defined number of positions after the seconds.


CREATE TABLE EMP(EMPNO CHAR(6) NOT NULL ,FIRSTNME VARCHAR(30) NOT NULL ,MIDINIT CHAR(1) ,LASTNAME VARCHAR(30) NOT NULL ,WORKDEPT CHAR(3) ,PHONENO CHAR(4) ,HIREDATE DATE ,JOB CHAR(8) WITH DEFAULT ‘NEW HIRE’ ,EDLEVEL SMALLINT ,SEX CHAR(1) NOT NULL ,BIRTHDATE DATE NOT NULL ,SALARY DECIMAL(9,2) ,RESUME CLOB(10M) ,INFO XML) ;

[ or IN DBX.TSX ;][ or IN DATABASE DBX ;][ or IN TSX ;]

Datatype Null Attribute Default Attribute

CREATE TABLE – column attributes

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Note

Numbers

A small integer (SMALLINT) is a binary integer with a precision of 15 bits. The range of small integers is -32768 to +32767

A large integer (INTEGER) is a binary integer with a precision of 31 bits. The range of large integers is -2147483648 to +2147483647.

A big integer (BIGINT) is a binary integer with a precision of 63 bits. The range of big integers is -9223372036854775808 to +9223372036854775807.

DECFLOAT is similar to both packed decimal and floating point. For precision of 16 decimal digits use DECFLOAT(16) and for precision of 32 decimal digits use DECFLOAT(32). DECFLOAT processing deals with exact numbers.

REAL is a single precision floating point number. DOUBLE (or FLOAT) is a double precision floating point number. Number of significant digits is 1 - 21 for REAL and 22 - 53 for DOUBLE, and the range is -7.2E75 to +7.2E75 for both REAL and DOUBLE.

Strings

Character strings are represented by CHAR, VARCHAR, and CLOB. CLOB (character large object) is discussed in CV841.

Binary strings are represented by BINARY, VARBINARY and BLOB. BLOB (binary large object) is discussed in CV841.

Graphic strings are represented by GRAPHIC, VARGRAPHIC, and DBCLOB. DBCLOB (double-byte character large object) is discussed in CV841.

ROWID

The data type ROWID is supported. The ROWID allows you to uniquely identify a row in a table. A ROWID column enables queries to be written that navigate directly to a row in the table because the column implicitly contains the location of the row. ROWID data type is discussed in CV841.

XML

The data type XML is supported. The XML data type allows you to store XML data in your table. XML data type is discussed in CV120 or CV260.

NULL

NULL indicates the absence of a value. NULL is not considered for column function evaluation (AVG...), except COUNT. Multiple NULLs are not considered equal, except for UNION, INTERSECT, EXCEPT, GROUP BY, ORDER BY, and unique indexes. The next visual discusses how nulls are handled in DB2.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

If the CREATE TABLE statement specifies IN DBX.TSX, the table EMP is created in the table space DBX.TSX.

If the CREATE TABLE statement specifies IN DATABASE DBX, the table EMP is created in an implicitly created table space and associated with the database DBX.

If the CREATE TABLE statement does not specify the IN clause, the table EMP is created in an implicitly created table space and associated with an implicitly created database.

The implicitly created table space is PBG UTS if the CREATE TABLE statement does not specify PARTITION BY clause, or a PBR UTS if the CREATE TABLE statement specifies PARTITION BY clause.

More information on implicitly created database is provided at the end of this unit.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-37. Row format CV8317.0

Notes:

Nullable fields

Nulls are used when actual values are unknown.

The use of nulls requires a 1-byte flag to be added to each nullable column. Another 1-byte flag is added to each value in an index created from a nullable column.

The null prefix is HEX '00' if the value is present, and HEX 'FF' if it is not.

Application programs that select data from nullable columns should be coded with null indicators.

The extra bytes for null flags and the additional processing for null indicators can represent an overhead.


fld1 00 fld2 FF fld3

fld1 00 fld2 03 00 fld3

1

2

Fixed Length Row (no VL fields)

Variable Length Row (VL fields)

fld3 is nullfld2 is presentfld1 cannot be null

Length of fld3 (VL)Fixed length fields

• ALTER TABLE ... ADD columnname does not update the existing records -> Updated when values are inserted for the new column or at REORG time

Row format• Nullable fields have a flag to indicate whether the field is present (X'00') or null (X'FF')

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Variable length fields

The VARCHAR data type can provide disk space savings. Space is allocated according to the actual length of each data item, and trailing blanks are not included.

Although VARCHAR can use space efficiently, remember that a VARCHAR entry carries a 2-byte length prefix. The benefits of space savings should outweigh the overhead of the length prefixes.

If a VARCHAR column permits nulls, then there is the 1-byte null flag overhead as well as the 2-byte length overhead.

The use of VARCHAR columns means the row is variable in length.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-38. Basic row format and reordered row format CV8317.0

Notes:

Prior to V9, each variable length column in a data row is stored with its length preceding it. If you need to access a column that is preceded by a variable length column, DB2 has to traverse through all the columns that precede it, starting with the first variable length column until it reaches the column you want to process. If you updated a variable length column, DB2 logs the changed column and everything to the end of the row. For these reasons, we recommend that all variable length columns be placed at the end of the row and the most frequently changed ones at the very end of the row. In today’s world of ERP, CRM and many other canned applications, it is impossible to control the placement of columns. V9 introduces a new format for data rows called reordered row format that helps reduce the impact and overhead of processing of variable length columns.

In V9 NFM and later versions, you do not have to worry about the order of columns within the row. You can specify the order however you wish, and DB2 automatically reorders the columns within the row and places all of the variable length columns at the end of the physical row within the data page. Instead of storing the columns with their length, DB2 stores all of the offsets for the variable length columns in an area following the last fixed length column and prior to the first variable length column. DB2 can now directly access


Basic row format and reordered row format

• The offset is a hexadecimal value, indicating the offset for thecolumn from the start of the data in the row.

• Note: More log volume may occur for rows stored in RRF..

C1 C2 C3 C48000000A 0006 WILSON ANDREW 0008 SAN JOSE

Basic Row Format

Reordered Row Format

2-byte length

C1 C3 O2 O4 C2 C48000000A ANDREW 12 18 WILSON SAN JOSE

offset to C2 offset to C4

CREATE TABLE TB1 (C1 INTEGER NOT NULL,C2 VARCHAR(10) NOT NULL,C3 CHAR(10) NOT NULL,C4 VARCHAR(20)

)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

each variable length column and know its length by doing simple calculations with the offsets. This is a much more efficient way to process individual varying length columns. This enhancement may also help reduce the amount of logging performed for canned applications since all the variable length columns are physically located at the end of the row no matter how the applications define the order of the columns.

Let us take a look at an example of how this is done. We use the statement shown in the visual to create a table with four columns, two variable length character columns, and two fixed length character columns. In our example, the variable length columns are in the middle and end of the row.

DB2 internally rearranges the columns in such a manner that all the fixed length columns go to the front of the row. All the length fields from VARiable columns get turned into offsets. All the data parts from VARiable columns get stored at the end of the row. Net result is 2-byte offset replaces 2-byte length field for VARCHAR meaning row length remains unchanged.

C2 offset: 4 bytes (for two x two-byte offset fields) + 4 bytes for an integer column + 10 bytes for the char field = 18 bytes = x’12’ bytes.

C4 offset: 18 bytes for C2 offset + 6 bytes for VARCHAR column C2 = 24 bytes = x’18’ bytes.

Note

Even though the physical order of the columns within the row has changed, if you do a SELECT * to retrieve all the columns, DB2 still returns them in the order specified in your CREATE TABLE statement.

In Basic Row Format, for a varying length field, DB2 logs from the first changed byte to the end of the row. In Reordered Row Format, the first changed byte may be the offset field for the first varying length field following the one being updated.

Information

The value of the DSNZPARM parameter RRF (field REORDERED ROW FORMAT on Install panel DSNTIP7, Install DB2 - Sizes Panel 2) specifies whether most newly created table spaces are to store data in reordered row format (RRF) or basic row format (BRF) by default. Acceptable values are ENABLE and DISABLE. The default is ENABLE. In DB2 9 this parameter is not on the installation panel.

ENABLE - Newly created table spaces or newly added partitions that are created by ALTER ADD PARTITION statements on partition-by-growth table spaces are created in RRF. Existing BRF table spaces are converted to RRF by running LOAD REPLACE or REORG TABLESPACE.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

DISABLE - Newly created table spaces, including universal table spaces, and newly added partitions that are created by ALTER ADD PARTITION statements on partition-by-growth table spaces are created in BRF. Existing BRF table spaces are not converted to RRF by LOAD REPLACE or REORG TABLESPACE.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-39. DEFAULT attributes CV8317.0

Notes:

It is possible to provide your own default value. It is used by DB2 if you fail to supply a value in the INSERT statement. The current timestamp, time, and date are supported through the traditional system default. There are no additional keywords required.

DATA TYPE DEFAULT VALUE -------------------------------------- NUMERIC 0 CHARACTER Blanks VARCHAR ZERO LENGTH GRAPHIC Blanks BINARY X’00’ DATE CURRENT DATE TIME CURRENT TIME TIMESTAMP CURRENT TIMESTAMP Note [VAR]CHAR is padded with spaces (X’40’ for EBCDIC, and X’20’ for ASCII and Unicode. BINARY is padded with X’00’. VARBINARY is not padded even during comparisons,


WITH DEFAULT ‘MY OWN VALUE’WITH DEFAULT USERWITH DEFAULT CURRENT SQLIDWITH DEFAULT NULLWITH DEFAULT

DEFAULT attributes

• Default can be either:– A constant– USER (special register)– CURRENT SQLID (special register)– NULL– System defaults

• Examples:

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The USER special register always contains the primary authorization ID of the process.

WITH DEFAULT NULL specifies that the default is the null value. NOT NULL and DEFAULT NULL cannot both be specified. If NOT NULL is omitted and DEFAULT is omitted, the effect is equivalent to an implicit specification of DEFAULT NULL.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-40. Table check constraints CV8317.0

Notes:

Table check constraints enhance your ability to control the integrity of your data.

A table check constraint designates the values that specific columns of a base table can contain. It is checked whenever the content of the data is changed.

The constraints are included in the table DDL. The presence of the constraint impacts the behavior of DB2 for that table. DB2 automatically enforces the constraint at all times.

The following is the complete list of check constraint restrictions as documented in SQL Reference:

• It can refer only to columns of this table; however, the columns cannot be LOB, ROWID, or security label columns (including distinct types that are based on LOB and ROWID data types).

• It can be up to 3800 bytes long, not including redundant blanks.

• It must not contain any of the following:

- Subselects


CREATE TABLE EMPLOYEE(EMPNO INTEGER NOT NULL,NAME CHAR(10) NOT NULL,DEPT INTEGER CHECK (DEPT BETWEEN 1 AND 100),JOB CHAR(10),YEARS INTEGER,SALARY DECIMAL(10,2),INVESTP INTEGER NOT NULL WITH DEFAULT,MAXINVEST INTEGER NOT NULL WITH DEFAULT,CHECK (JOB IN ('MANAGER','SALES','TECHNICAL')),CONSTRAINT NOINVEST CHECK ((YEARS < 5 AND INVESTP = 0)

OR (YEARS >= 5)),CHECK (INVESTP <= MAXINVEST))

WITH RESTRICT ON DROPIN USDB1.USTS2;

Table check constraints

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

- Built-in or user-defined functions

- Cast functions other than those created when the distinct type was created

- Host variables

- Parameter markers

- Special registers

- Columns that include a field procedure

- CASE expressions

- Row expressions

- DISTINCT predicates

- GX literals (hexadecimal graphic string constants)

• If a check condition refers to a LOB column (including a distinct type that is based on a LOB), the reference must occur within a LIKE predicate.

• The AND and OR logical operators can be used between predicates. The NOT logical operator cannot be used.

• The first operand of every predicate must be the column name of a column in the table.

• The second operand in the check condition must be either a constant or a column name of a column in the table.

- If the second operand of a predicate is a constant, and if the constant is:

• A floating-point number, then the column data type must be floating point.

• A decimal number, then the column data type must be either floating point or decimal.

• An integer number, then the column data type must not be a small integer.

• A small integer number, then the column data type must be small integer.

• A decimal constant, then its precision must not be larger than the precision of the column.

- If the second operand of a predicate is a column, then both columns of the predicate must have:

• The same data type.

• Identical descriptions, with the exception that the specification of the NOT NULL and DEFAULT clauses for the columns can be different, and that string columns with the same data type can have different length attributes.

Using CONSTRAINT to name a CHECK is optional. If you do not provide a name, then DB2 generates one for you.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Note

WITH RESTRICT ON DROP:

• Cannot drop table. Also the database or table space that contains the table cannot be dropped.

• Restrict status is recorded in CLUSTERTYPE column of SYSIBM.SYSTABLES.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-41. SYSTABLES and SYSCOLUMNS catalog information CV8317.0

Notes:

All DB2 tables, including the catalog tables, are described in the DB2 catalog table SYSIBM.SYSTABLES.

All DB2 table columns are described in SYSIBM.SYSCOLUMNS.


SYSIBM.SYSTABLESSELECT NAME,OWNER,TYPE,DBNAME,TSNAME,DBID,OBID,COLCOUNT,CHECKS,CLUSTERTYPEFROM SYSIBM.SYSTABLESWHERE NAME = 'EMPLOYEE' AND

CREATOR = 'TSOUD01'---------+---------+---------+---------+---------+---------+---------+------+NAME OWNER TYPE DBNAME TSNAME DBID OBID COLCOUNT CHECKS CLUSTERTYPE---------+---------+---------+---------+---------+---------+---------+------+EMPLOYEE TSOUD01 T USDB1 USTS2 264 8 8 4 Y

SYSTABLES and SYSCOLUMNS catalog information

SYSIBM.SYSCOLUMNSSELECT NAME,TBNAME,COLNO,COLTYPE,LENGTH,SCALE,NULLS,DEFAULTFROM SYSIBM.SYSCOLUMNSWHERE TBNAME = 'EMPLOYEE' AND

TBCREATOR = ‘TSOUD01'---------+---------+---------+---------+---------+---------+---------+--NAME TBNAME COLNO COLTYPE LENGTH SCALE NULLS DEFAULT---------+---------+---------+---------+---------+---------+---------+--EMPNO EMPLOYEE 1 INTEGER 4 0 N NNAME EMPLOYEE 2 CHAR 10 0 N NDEPT EMPLOYEE 3 INTEGER 4 0 Y YJOB EMPLOYEE 4 CHAR 10 0 Y YYEARS EMPLOYEE 5 INTEGER 4 0 Y YSALARY EMPLOYEE 6 DECIMAL 10 2 Y YINVESTP EMPLOYEE 7 INTEGER 4 0 N YMAXINVEST EMPLOYEE 8 INTEGER 4 0 N Y

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-42. Check constraints catalog information CV8317.0

Notes:

SYSIBM.SYSCHECKS describes the check constraints.

SYSIBM.SYSCHECKDEP has a cross-reference of the constraints and the columns they refer to.


SYSIBM.SYSCHECKS---------+---------+---------+---------+---------+---------+---------+--SELECT TBNAME,OBID,TBOWNER,CHECKNAME, CHECKCONDITIONFROM SYSIBM.SYSCHECKSWHERE TBOWNER = ‘TSOUD01' AND

TBNAME = 'EMPLOYEE'---------+---------+---------+---------+---------+---------+---------+--------TBNAME OBID TBOWNER CHECKNAME CHECKCONDITION---------+---------+---------+---------+---------+---------+---------+--------EMPLOYEE 9 TSOUD01 DEPT DEPT BETWEEN 1 AND 100EMPLOYEE 12 TSOUD01 INVESTP INVESTP <= MAXINVESTEMPLOYEE 10 TSOUD01 JOB JOB IN ('MANAGER','SALES','TECHNICAL')EMPLOYEE 11 TSOUD01 NOINVEST (YEARS < 5 AND INVESTP = 0) OR (YEARS >= 5)

Check constraints catalog information

SYSIBM.SYSCHECKDEP---------+---------+---------+---------+---------+-SELECT TBOWNER,TBNAME,CHECKNAME,COLNAME FROM SYSIBM.SYSCHECKDEPWHERE TBOWNER = 'TSOUD01' AND

TBNAME = 'EMPLOYEE'---------+---------+---------+---------+---------+-TBOWNER TBNAME CHECKNAME COLNAME---------+---------+---------+---------+---------+-TSOUD01 EMPLOYEE DEPT DEPTTSOUD01 EMPLOYEE INVESTP INVESTPTSOUD01 EMPLOYEE INVESTP MAXINVESTTSOUD01 EMPLOYEE JOB JOBTSOUD01 EMPLOYEE NOINVEST INVESTPTSOUD01 EMPLOYEE NOINVEST YEARS

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-43. Enable table-controlled partitioning CV8317.0

Notes:

The table-controlled partitioning is initiated by specifying the PARTITION BY clause in the CREATE TABLE statement. The PARTITION BY clause identifies the columns and values used to define the partition boundaries. When the CREATE TABLE statement executes successfully, the definition of the partitioned table space (either classic or partition-by-range) is complete, and data can be inserted into the table. PARTITION n (where n is the partition number) and ENDING AT keywords are used to specify the partition boundaries.

The example shows the table is created in the classic partitioned table space USDB1.USTS3. If you specify IN USDB1.USTS5, the table is created in the partition-by-range universal table space USDB1.USTS5.


CREATE TABLE EMPLOYEE1(EMPNO INTEGER NOT NULL,NAME CHAR(10) NOT NULL,DEPT INTEGER,JOB CHAR(10),YEARS INTEGER,SALARY DECIMAL(10,2),INVESTP INTEGER NOT NULL WITH DEFAULT,MAXINVEST INTEGER NOT NULL WITH DEFAULT)

PARTITION BY (EMPNO ASC)(PARTITION 1 ENDING AT (099),PARTITION 2 ENDING AT (199),PARTITION 3 ENDING AT (299),PARTITION 4 ENDING AT (999))

IN USDB1.USTS3;

Enable table-controlled partitioning

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-44. ALTER TABLE CV8317.0

Notes:

When a column is added via ALTER, it becomes the rightmost, and contains NULL values or the default value for existing rows.

ALTER TABLE PROJ ADD PROJCOST DECIMAL (7,0) NOT NULL WITH DEFAULT

If the table is not created by specifying WITH RESTRICT ON DROP, the table definition can be altered using ALTER TABLE specifying ADD RESTRICT ON DROP.

If there is a need to drop the table, the table definition can be altered using ALTER TABLE specifying DROP RESTRICT ON DROP.

You can use the RENAME COLUMN clause to rename columns. Numerous restrictions apply. Details are discussed in CV841.


ALTER TABLE

• You can:– Add / remove Table check / Referential integrity constraints– Add extra column or partitioning key– Change a column name– Specify ADD RESTRICT ON DROP– Specify DROP RESTRICT ON DROP– Increase data type length (old values must fit in) such as:

• CHAR(30) to CHAR(50)• VARCHAR(30) to VARCHAR(50)• SMALLINT to BIGINT• DECIMAL (9,2) to DECIMAL(15,4)

– But not DECIMAL(5,2) to DECIMAL (5,0)– Switch between fixed and variable types of same length such as:

• CHAR(30) to VARCHAR(30) and vice versa• GRAPHIC(30) to VARGRAPHIC(30) and vice versa

• You cannot: – Remove or Rearrange columns – Change NULL or default attribute

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-45. Examples for adding / removing check constraints CV8317.0

Notes:


ALTER TABLE EMPLOYEEADD CONSTRAINT SALCHECKCHECK(SALARY > 0);

--ALTER TABLE EMPLOYEE

DROP CONSTRAINT SALCHECK;

--

ALTER TABLE EMPLOYEEADD CONSTRAINT SALCHECKCHECK(SALARY > 10000);

--ALTER TABLE EMPLOYEE

DROP CHECK SALCHECK;

Examples for adding / removing check constraints

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-46. Adding able check constraints - considerations CV8317.0

Notes:

The CURRENT RULES special register is set initially to the value specified by the BIND SQLRULES option. The special register can be changed dynamically by using the SET CURRENT RULES SQL statement.

Check integrity exists when each row of a table conforms to the check constraints defined on that table. Check Pending (CHKP) is set when check integrity cannot be guaranteed.

A table in Check Pending status cannot be accessed through DML.


Adding table check constraints - considerations

• If table is empty, the check constraint is added

• If table is populated, the action depends on:– CURRENT RULES special register (STD|DB2)

• For STD– If no violating rows, then constraint is added– If violating rows, then ALTER fails

• For DB2– Check Pending (CHKP) is set

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-47. The -DISPLAY DATABASE command CV8317.0

Notes:

The -DISPLAY DATABASE command can be used to show the status of all objects in your database. As you can see, the status is set at the table space (not table) and index level. We see some other restrictive states later in the course.


DSNT360I # *********************************************************DSNT361I # * DISPLAY DATABASE SUMMARY

* GLOBALDSNT360I # *********************************************************DSNT362I # DATABASE = INVDB11 STATUS = RW

DBD LENGTH = 4028DSNT397I #NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE...... .... ..... .......... ....... ....... ....... .....INVSINV TS RWINVSINL TS RW,CHKPINVXINV0 IX RWINVXINLO IX RW*******DISPLAY OF DATABASE INVDB11 ENDED *************************DSN9022I # DSNTDDIS ‘DISPLAY DATABASE’ NORMAL COMPLETION***

-DIS DB (INVDB11)

The -DISPLAY DATABASE command

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.4. Data compression

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-48. Data compression - overview CV8317.0

Notes:

Data compression means table space compression.

The decision whether to use data compression for a specific table space is a tradeoff between resource savings (disk space, I/O, and buffer pool requirements) and the incurred CPU overhead of the compression or decompression.

This discussion is applicable to all types of table spaces discussed earlier.


Buffer pool

Program

I/O

Buffer pool

Program

I/O

ENCODEDECODE

Withoutdata compression

Withdata compression

Data compression – overview

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-49. Data compression - data management CV8317.0

Notes:

When a row is read for compression, the algorithm evaluates the compression space savings before actually doing the compression. A bit in the row header indicates whether a row has been compressed or not.

Data compression uses a dictionary that is stored with the data and is anchored in the table space's header page. The dictionary is a structure which defines the rules used to encode and decode strings of characters. The dictionary has at most 4096 entries and a maximum size of 64 KB. Depending the page size of the table space, it can therefore be stored, for example, in 16 4K pages or two 32K pages.

Compression may be specified at the partition level.


Space Map

Dictionary

Header Page

Data Page

RowHeader

RowData

CREATE/ALTER TABLESPACECOMPRESS YES

Dictionary Anchor

Data compression – data management

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-50. Data compression - building the dictionary CV8317.0

Notes:

A compression dictionary can be built by the LOAD and REORG utilities.

Since different data can have different characteristics; the best compression requires customization to the specific data.

This customization of encoding and decoding to the data is the purpose of the compression dictionary. Each table space (or partition of a partitioned table space) in DB2 has a dictionary that is custom-built to the characteristics of the data within it to maximize the compression of that data.

LOAD COPYDICTIONARY option:

The LOAD COPYDICTIONARY option allows compression dictionaries to be copied from one partition to another in a classic partitioned or partition-by-range universal table space.

The LOAD keyword, COPYDICTIONARY integer, at the table space level enables LOAD PART REPLACE to copy an existing compression dictionary from the partition specified to all partitions being PART REPLACEd.


Data compression – building the dictionary

For table space or partition with COMPRESS YES• REORG TABLESPACE

1. Builds the dictionary during UNLOAD2. When full, improves dictionary by sampling remaining data3. Compress at RELOAD

• LOAD REPLACE or LOAD RESUME NO1. Inserts rows (uncompressed) until dictionary full2. Starts compressing

• LOAD utility COPYDICTIONARY and KEEPDICTIONARY options

• REORG TABLESPACE utility KEEPDICTIONARY option• DSN1COMP stand-alone utility

– Estimates space savings

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

1+1= 2 Example

How to copy a compression dictionary from physical partition 1 to partitions 3 and 5.

LOAD RESUME NO COPYDICTIONARY 1INTO TABLE PART 3 REPLACEINTO TABLE PART 5 REPLACE

Allows the LOAD utility to copy an existing compression dictionary from the specified partition to other partitions on a partitioned table space. LOAD copies the current compression dictionary from the specified partition and uses it for compressing the input data for the partitions being replaced.

This option provides a method to copy a compression dictionary to an empty partition that normally would not have a compression dictionary built.

The COPYDICTIONARY keyword is only compatible on classic partitioned and partition-by-range universal table spaces using the RESUME NO option at the table space level with PART integer REPLACE statements, where the partition being copied is not the same as the partitions being replaced.

LOAD PART integer RESUME is not supported with the COPYDICTIONARY keyword. Neither is LOAD RESUME YES COPYDICTIONARY.

The COPYDICTIONARY keyword is incompatible with the KEEPDICTIONARY keyword at the table space or partition level and with the REPLACE keyword at the table space level.

This keyword only copies the compression dictionary to partitions being replaced that have the COMPRESS YES attribute. A valid dictionary must exist for the partition specified with the COPYDICTIONARY keyword.

You can specify any valid partition number that is not being replaced for the partitioned table space. The default value is 1.

LOAD KEEPDICTIONARY option:

Prevents the LOAD utility from building a new compression dictionary. LOAD retains the current compression dictionary and uses it for compressing the input data. This option eliminates the cost that is associated with building a new dictionary.

DB2 ignores the KEEPDICTIONARY option if the REORG utility changes the table space from basic row format to reordered row format.

If the table space or partition is empty, DB2 performs one of these actions:

• DB2 builds a dictionary if a compression dictionary does not exist.

• DB2 keeps the dictionary if a compression dictionary exists.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

If RESUME NO and REPLACE are specified when the table space or partition is not empty, DB2 performs the same actions as it does when the table space or partition is empty.

If the table space or partition is not empty and RESUME YES is specified, DB2 performs one of these actions:

• DB2 does not build a dictionary if a compression dictionary does not exist.

• DB2 keeps the dictionary if a compression dictionary exists

You must use KEEPDICTIONARY to ensure that the compression dictionary is maintained.

REORG TABLESPACE KEEPDICTIONARY option:

Prevents REORG TABLESPACE from building a new compression dictionary when unloading the rows. The efficiency of REORG increases with the KEEPDICTIONARY option for the following reasons:

• The processing cost of building the compression dictionary is eliminated.

• Existing compressed rows do not need to be compressed again.

• Existing compressed rows do not need to be expanded, unless indexes require it or SORTDATA is used.

Possible reasons for not specifying KEEPDICTIONARY are:

• If the data has changed significantly since the last dictionary was built, rebuilding the dictionary might save a significant amount of space.

• If the current dictionary was built either by the LOAD utility or automatically by DB2 based on records that have been inserted over time, rebuilding the dictionary by using REORG might produce a better compression dictionary.

• If the data is being converted from basic row format to reordered row format, REORG builds a new dictionary for the new format. DB2 ignores the KEEPDICTIONARY option if the REORG utility changes the table space from basic row format to reordered row format.

You must use KEEPDICTIONARY to ensure that the compression dictionary is maintained.

Note

The first time you REORG a compressed table space, DB2 automatically rebuilds a new compression dictionary even if you specify the KEEPDICTIONARY keyword in your REORG/LOAD control statement.Exc

lusivo

form

ación

proy

ecto

C.F.T.I.C




Uempty

E

DSN1COMP Stand-alone utility:

The DSN1COMP stand-alone utility provides a close approximation to DB2 compression results without altering the data. Input to the utility can be VSAM data sets containing DB2 table space or partition data, DB2 full image copy data sets, or sequential data sets containing DB2 table space or partition data (for example, DSN1COPY output).

DSN1COMP does not require DB2 authorization checking (data sets maybe RACF protected) therefore, can run when DB2 is up or down.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-51. Compress on INSERT CV8317.0

Notes:

Prior to DB2 10, if you turn on compression for a table space using the ALTER TABLESPACE command, DB2 needs to build the compression dictionary. Compression dictionaries are built as part of REORG TABLESPACE or LOAD utility runs. You might not be able to run LOAD or REORG when you decide to turn on compression for a given table space.

With DB2 10 NFM, you can turn on compression with ALTER any time, and the compression dictionary is built when you execute the following statements:

• INSERT statements • MERGE statements • LOAD SHRLEVEL CHANGE


Compress on INSERT

• Data compression occurs when a dictionary exists

• Prior to DB2 10 – Dictionary not built on a table space with COMPRESS YES attribute

until:• REORG or• LOAD utility was executed

– For some customers, REORG or LOAD are not executed frequently

• DB2 10 NFM allows for build of compression dictionary on: – INSERT– MERGE– LOAD SHRLEVEL CHANGE

• No REORG or LOAD needed to get compressed data

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-52. How Compress on INSERT works CV8317.0

Notes:

The threshold is about 1.2 MB, which is determined by reading the RTS statistics in memory. When the threshold is reached, DB2 builds the dictionary asynchronously and issues the message shown below:

DSNU241I -DB0B DSNUZLCR - DICTIONARY WITH 4096 755ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 598 ROWS FOR TABLE SPACESABI6.TS6, PARTITION 1

The DSNU241I message is issued in this case because the table space is partitioned. DSNU231I is written out in case of a non-partitioned table space. These messages are issued on the console only by compress on insert. The LOAD and REORG utilities have the same messages, but these messages are written in the utility output, not on the console.

After the dictionary is built, DB2 inserts the data in compressed format. At least 1.2 MB of data in the table space is not compressed. The additional data is compressed.


How Compress on INSERT works

• INSERT, MERGE and LOAD SHRLEVEL CHANGE trigger the creation of a compression directory if:– The table space or partition is defined with COMPRESS YES– The table space or partition has no compression dictionary built– Inserted data reaches a threshold that allows the build of the

compression dictionary• Threshold is 1.2 MB (checked through RTS data)

• If threshold is reached, dictionary build is done asynchronously:– Data continues to be inserted uncompressed until dictionary is ready– Rows read with UR in order to build the dictionary

• No way to turn off Auto Compress – Use COMPRESS NO if unwanted

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Data rows that you insert while the dictionary is still under construction are inserted uncompressed. When building the dictionary asynchronously, DB2 reads the existing data with isolation level uncommitted read.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-53. Location of compression dictionary pages CV8317.0

Notes:

If the compression dictionary is built using LOAD REPLACE or REORG TABLESPACE, the dictionary pages follow the system pages (header and space map), which is not the case when the compression dictionary is built on-the-fly. Because there must be at least 1.2 MB worth of data in the table space before the new compression functionality kicks in, the compression dictionary gets any page numbers. Furthermore, the dictionary pages might not be contiguous, as illustrated in above visual.

The left side in the above visual shows the dictionary pages (DI) in the table space. When the table space is image copied with option SYSTEMPAGES YES the dictionary pages are replicated after the header and space map pages.

If you use image copies as input for the UNLOAD utility and if you plan on using this automatic compression without REORG or LOAD, you must run the COPY utilities with option SYSTEMPAGES YES. This option requests the collection of all SYSTEMPAGES during utility execution and places a copy of those directly behind the first space map page. The original dictionary pages remain at their original location. So, the SYSTEMPAGES YES option on COPY TABLESPACE produces duplicates of those system pages.


Location of compression dictionary pages

UNLOAD DATA.... FROMCOPY

DSNU1232I -COMPRESSED

ROWIS IGNORED

BECAUSE THEDICTIONARY

IS NOT AVAILABLE FOR TABLE table-name

H SM D D ..

D D DI D

D DI D DI

COPY TS... SYSTEMPAGES NO

.

.H SM D D .

.D D DI D

D DI D DI

.

.

COPY TS... SYSTEMPAGES YES(option makes DB2 copy the dictionary pages after space map page)

H SM DI DI ..

DI D D D

DI D D DI

.

.Dictionary pages not necessarily after space map pagenor contiguous D DI

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

If you specify SYSTEMPAGES NO, DB2 copies only the table space as is. When you attempt to unload from this image copy, the UNLOAD utility recognizes that the rows in the table space are compressed but cannot uncompress the rows because it looks only for dictionary pages at the beginning of the table space prior to first data page.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-54. Miscellaneous on Compress on Insert CV8317.0

Notes:

If you run REORG later, depending on your choice regarding the KEEPDICTIONARY utility control keyword, REORG either moves the dictionary pages behind the space map page and before the first data page or creates a new dictionary, which is then located at this point.

Generally, you can use the DSN1COMP utility to estimate the space savings that can be achieved by DB2 data compression in table spaces and indexes.

If you run the DSN1COMP utility without any special option, the utility calculates the estimated space savings based on the algorithms that are used for building compression during LOAD. If you use the LOAD utility to build a new compression dictionary, the compression ratio is likely to be a bit less effective than during REORG. If you specify the REORG keyword on the compression utility, DB2 calculates the compression ratio based on what is accomplished by the REORG utility. There is no specific keyword for the COMPRESS on INSERT method. Compress on INSERT reaches similar compression ratios as the LOAD utility for table spaces, considerably larger than 1.2 MB. As a


Miscellaneous on Compress on Insert

• DSN1COMP can be used to estimate space savings

• If REORG keyword is not specified: – Space saving calculated based on what LOAD would achieve– Compression ratio likely to be a little less effective

• If COMPRESS YES:– Check for message DSNU241I or DSNU231I– Check, for example, RTS so see if data volume is large enough

(> 1.2 MB) – Remember that RTS only updated past the minutes you specified for

DSNZPARM STATSINT

• If DATASIZE > 1,310,720 bytes, but compression not activated:– Can happen if dictionary cannot be built due to nature of data– No error message

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

consequence, if you do not specify REORG for your estimate, the calculated savings is about the same as COMPRESS ON INSERT.

Let us assume that you have turned on compression for your table space and now you want to know whether COMPRESS on INSERT actually worked and if the data is now compressed.

The easiest way to verify whether the table space is compressed is to check the SYSLOG for the following message:

DSNU241I -DB0B DSNUZLCR - DICTIONARY WITH 4096 755ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 598 ROWS FOR TABLE SPACESABI6.TS6, PARTITION 1

If you can find this message, you know that the dictionary was built for a given partition of a table space. For a non-partitioned table space, the message is DSNU231I.

If you cannot find this message in the SYSLOG, check whether the data volume is large enough so that the threshold of 1.2 MB of data is passed and compression can theoretically begin. You can for example use the following SQL query to check the RTS tables:

SELECT DATASIZEFROM SYSIBM.SYSTABLESPACESTATSWHERE DBNAME='yourdb'AND NAME='yourts';

Remember that column DATASIZE contains the amount of data stored in your table space in bytes, that is you need at least 1,310,720 bytes. However, the time that the current value is reflected in the catalog depends on the interval specified for externalizing RTS statistics (STATSINT DSNZPARM default is 30 minutes).

In some cases, it might appear that you turn on compression and that the data volume is larger than 1.2 MB but that COMPRESS on INSERT did not take place. This situation can occur if DB2 cannot build a usable compression dictionary because of the data contents. If this is the case, you do not get an error message. An error message, such as DSNU235I or DSNU245I, displays on the console if there are issues, such as out of space conditions or similar.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.5. Views and Materialized Query Tables

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-55. DB2 views CV8317.0

Notes:

What are views?

Views are virtual tables made up of columns and rows from real tables and other views. They provide alternative ways of looking at data in one or more tables.

DB2 does not store any data for the view itself because the data already exists in the real (base) table or tables.

You define a view in terms of a SELECT. For example, you can define a view as:

• A subset of columns of a real table

• A subset of rows of a real table

• A JOIN of two or more real tables

The definition is recorded in the DB2 catalog and resolved into base table references when SQL using the view is bound.

Users see views as if they were real tables.


View V1 (Subset of columns)

View V3 (Join of 2 tables)

DB2 views

EMP Table

DPT# DPTNME MGR

F01 ACCT 087

B11 ADMIN 177

F02 SALES 358

DEPT Table DPT# EMP# LAST MI FIRST JOB

F01 020 DAVIS A CHARLES 52

F01 090 QUINTO F DOLORES 55

F01 087 EAST E MORIS 99

F01 333 WILSON Y MARY 52

F02 358 MALLET F MIKE 99

B11 130 PARKER R JUDITH 62

B11 200 SMITH G BETTY 40

B11 298 KANDOS R PHILLIP 47

B11 177 SECOND X MARC 99

DEPT Table EMPLOYEE Table

EMP Table

EMP Table

View V2 (Subset of rows)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Ease of use

A single view can provide easy access to several underlying base tables.

Your installation naming standards may mean that some table and column names are long or difficult to remember. You can create a view that uses alternative names that are much easier to remember.

You can create views for users which execute complex SQL and which perform well, rather than expect users to code complex SQL.

Note

Do not be concerned if you cannot easily read the data within the table cells shown on this visual. The details are not important at this stage. The purpose of the diagram is to highlight what is visible through the view as opposed to what is actually in the table.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-56. CREATE VIEW - examples CV8317.0

Notes:

The visual has further examples of views.

Virtual columns such as AVG(SALARY), SUM(SALARY) and MIN(BIRTHDATE) can be given names on the CREATE VIEW as shown or on the SELECT using the AS clause as shown.

Cost of views

In most cases a view costs only a few microseconds of CPU time when the SQL referencing the view is bound. For static SQL this is a one-time cost and for dynamic SQL this cost is incurred each time the view is used.

View materialization

In some cases the qualifying rows from a view definition must be written to a work fIle. For example, if the SELECT in the view definition has a GROUP BY with a column function.


CREATE VIEW MYTABLESASSELECT *FROM SYSIBM.SYSTABLESWHERE CREATOR = USER

CREATE VIEW VFUTPROJASSELECT MGRNO,

DEPTNAME,PROJNO,RESPEMP

FROM PROJ,DEPTWHERE PROJ.DEPTNO = DEPT.DEPTNOAND PRENDATE < CURRENT DATE - 1 YEAR

CREATE VIEW VSALSTAT(AVGSAL,SUMSAL,MINBIRTH)

ASSELECT AVG(SALARY),

SUM(SALARY),MIN(BIRTHDATE)

FROM EMPWHERE BIRTHDATE < ‘1980-01-01’

CREATE VIEW VSALSTATASSELECT AVG(SALARY) AS AVGSAL,

SUM(SALARY)AS SUMSAL,MIN(BIRTHDATE)AS MINBIRTH

FROM EMPWHERE BIRTHDATE < ‘1980-01-01’

OR

CREATE VIEW – examples

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Read-only views

In some cases, a view is read-only. For example, when a view is defined on the JOIN of two or more tables (and no INSTEAD OF TRIGGER is defined).

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-57. Views on views on tables CV8317.0

Notes:

You can create a view on views as long as the view references no more than 15 base tables directly or indirectly.

In the visual, VIEW1 is defined on some rows and columns of TABLE1 and VIEW2. Also, VIEW2 is defined on some rows and columns of TABLE3 and TABLE4.

Higher level views depend on those at lower levels. If a lower level view or table is dropped then higher level views depending on it are also dropped automatically. For example, if TABLE4 is dropped, then VIEW2 and VIEW1 are dropped.

REVOKE SELECT ON base-table FROM view-creator drops the view. This is driven by the DSNZPARM REVOKE_DEP_PRIVILEGES setting.

Security

Views provide security for your data. Rather than allow users to access all rows and columns in a base table, you can grant them access to data via views that define a subset of columns and rows.


SQL1 SQL2 SQL3 SQL4 SQL5

TABLE1

VIEW1 VIEW2

TABLE4TABLE3TABLE2

Views on views on tables

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Data independence

If you ALTER an underlying base table and add a column, users selecting columns through an existing view do not see the new column even when using SELECT *. This way, programs using views can run unchanged.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-58. DELETE from a view CV8317.0

Notes:


CREATE VIEW EMPE11ASSELECT EMPNO, NAME, ROOM, TELEPHONEFROM EMPLOYEE WHERE DEPT = 'E11';

EMPLOYEE

EMPE11

DELETE FROM EMPE11WHERE NAME = 'SCHMIDT';

EMPNO NAME DEPT ROOM TELEPHONE SALARY110 SCHMIDT A10 1018 4388 7500220 ABELE E10 1003 4407 4900290 OBERHAUS E11 1012 4112 5500300 SCHMIDT E11 1034 4234 4300310 MUELLER E11 1022 4419 4100

EMPNO NAME ROOM TELEPHONE290 OBERHAUS 1012 4112300 SCHMIDT 1034 4234310 MUELLER 1022 4419

• Two rows with name SCHMIDT in the table. What is the effect of DELETE?

DELETE from a view

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-59. SELECT, UPDATE, INSERT, DELETE with VIEWS CV8317.0

Notes:

UPDATE: The change of values in the view changes the values in the corresponding columns the base table. However, base table columns which are not part of the view are not changed.

INSERT: Inserting a row into a view is only possible, if all columns of the base table, which are not part of the view, are nullable or have defaults.

DELETE: The deletion of a row from the view deletes the entire row from the base table, even if some columns are not part of the view. However, the rows that are not part of the view cannot be deleted.

There are some restrictions on updating views:

1. You cannot delete, update or insert into:

- Views that join tables (and no INSTEAD OF TRIGGER is defined).

- Views that use functions

- Views that use DISTINCT

© Copyright IBM Corporation 2011© Copyright IBM Corporation 2007

? ? ?

VIEW A B C D E FB C E

BASE TABLE

SELECTand

UPDATE

INSERT

DELETE

SELECT, UPDATE, INSERT, DELETE with VIEWS

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

- Views that use GROUP BY

2. You cannot insert into:

- Views that contain derived data using arithmetic expressions

- Views that contain constants

- Views that eliminate columns without a default value

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-60. The disappearing row CV8317.0

Notes:

In the first example, view SALARIES_1 is created. An update that raised the yearly salary to 40000 or more, which is beyond the scope of the view, would succeed. After the update, the changed row is no longer visible through the view, but still exists in the base table. We call this effect ‘the disappearing row’.

In the second example, view SALARIES_2 is created. It has the same definition as SALARIES_1, except that WITH CHECK OPTION is specified. This time, an update that tried to raise the yearly salary to 40000 or higher would fail. WITH CHECK OPTION ensures that the update is not permitted if it would remove the changed row from the scope of the view.

The CHECK OPTION also constraints INSERT through the view, not just UPDATE as in the example in the visual.


WORKS!

UPDATE SALARIES_1SET SALARY = 42000WHERE EMPNO = '000030'

CREATE VIEW SALARIES_1AS SELECT EMPNO, LASTNAME, SALARY

FROM EMPLOYEEWHERE SALARY < 40000

EMPLOYEE Table

EMPNO LASTNAME WORKDEPT SALARY

000010000030000120000130000140

HAASKWANO'CONNELLQUINTANANICHOLLS

A00C01A00C01C01

52750.0038250.0029250.0023800.0028420.00

FAILS!

UPDATE SALARIES_2SET SALARY = 42000WHERE EMPNO = '000030'

CREATE VIEW SALARIES_2AS SELECT EMPNO, LASTNAME, SALARY

FROM EMPLOYEEWHERE SALARY < 40000WITH CHECK OPTION

The disappearing row

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-61. WITH CHECK OPTION CV8317.0

Notes:

WITH CHECK OPTION has two forms: CASCADED and LOCAL.

The difference between these two forms is meaningful only when a view is defined on top of another view. If a view called V2 is defined by a query on another view called V1, we refer to V1 as the underlying view.

When V2 is defined using WITH LOCAL CHECK OPTION, operations on V2 must satisfy the definitions of V2 and of all underlying views that also have WITH CHECK OPTION; however, they need not satisfy the definitions of underlying views that do not have WITH CHECK OPTION.

On the other hand, when V2 is defined using WITH CASCADED CHECK OPTION, all operations on V2 must satisfy the definitions of V2 and of all underlying views, whether they have WITH CHECK OPTION or not.

If a CREATE VIEW statement simply specifies WITH CHECK OPTION, the default is WITH CASCADED CHECK OPTION.


WITH CHECK OPTION

• WITH CHECK OPTION– Either LOCAL or CASCADED

• WITH LOCAL CHECK OPTION– Verify only your own WHERE clause and any underlying views

that also have the WITH CHECK OPTION– Ignore definitions of underlying views that do not have the

WITH CHECK OPTION • WITH CASCADED CHECK OPTION

– Enforce your WHERE clause and– Enforce WHERE clauses of underlying views

• Regardless of definitions of those views

V2 with WHERE condition 2!

V1 with WHERE condition 1!

TB

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

If the CHECK OPTION for view V2 is LOCAL, only WHERE condition 2 is checked during UPDATE and INSERT.

If the CHECK OPTION for view V2 is CASCADED, both WHERE condition 2 and WHERE condition 1 are checked during UPDATE and INSERT.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-62. Effect of cascaded CHECK OPTION CV8317.0

Notes:

In this example, view V1 is created on table EMPLOYEE using WITH CHECK OPTION. Notice the WHERE clause that allows only rows where SALARY < 5000 to be retrieved through this view. Updating the table through view V1 by increasing the SALARY by 200 would fail because SALARY for EMPNO 220 would go over 5000.

View V2 is created on view V1 without the use of WITH CHECK OPTION. Notice the WHERE clause that allows only rows where SALARY > 4200 to be retrieved. Thus, out of three rows visible through view V1, only two rows can be retrieved through view V2, because the SALARY for EMPNO 310 is < 4200.

Updating the table through view V2 by increasing the SALARY by 200 would fail because SALARY for EMPNO 220 would go over 5000. Although WITH CHECK OPTION is not used when creating view V2, since view V1 is created using WITH CHECK OPTION, the search condition of view V1 is inherited by view V2.


CREATE VIEW V1ASSELECT EMPNO, NAME, SALARYFROM EMPLOYEEWHERE SALARY < 5000WITH CHECK OPTION;

EMPLOYEE

V1

UPDATE V1 SET SALARY = SALARY + 200;

EMPNO NAME DEPT ROOM TELEPHONE SALARY110 LIEBHERR A10 1018 4388 7500220 ABELE E10 1003 4407 4900290 OBERHAUS E11 1012 4112 5500300 SCHMIDT E11 1034 4234 4300310 MUELLER E11 1022 4419 4100

EMPNO NAME SALARY220 ABELE 4900300 SCHMIDT 4300310 MUELLER 4100

CREATE VIEW V2ASSELECT EMPNO, NAME, SALARYFROM V1WHERE SALARY > 4200;

EMPNO NAME SALARY220 ABELE 4900300 SCHMIDT 4300

V2

UPDATE V2 SET SALARY = SALARY + 200;

1.

2.

3.

4.

FAILS! FAILS!

Effect of cascaded CHECK OPTION

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The rules for the two WITH CHECK OPTIONS can be summarized as follows:

• CASCADED

When a row is inserted or updated using a view defined WITH CASCADED CHECK OPTION, then the search condition for the view is checked along with any search conditions defined for underlying views.

This is regardless of whether or not the WITH CHECK OPTION was specified in the definition of the underlying views.

• LOCAL

When a row is inserted or updated using a view defined WITH LOCAL CHECK OPTION, then the search condition for the view is checked along with any search conditions for underlying views defined with the WITH CHECK OPTION clause.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-63. Views - catalog information (1 of 2) CV8317.0

Notes:

Since views are "virtual" tables, DB2 stores information about them as if they were tables.

In SYSIBM.SYSTABLES a row is inserted with TYPE ‘V’ indicating this row is for the view EMPLOYEEV shown under column NAME.

In SYSIBM.SYSCOLUMNS, a row is inserted for each column in the view definition. In this example, the column names in the table are used for the view column names by default. The view name is shown under column TBNAME.


CREATE VIEW EMPLOYEEV AS SELECT EMPNO,DEPT,YEARS FROM EMPLOYEE;

---------+---------+---------+---------+------SELECT NAME,OWNER,TYPE,COLCOUNTFROM SYSIBM.SYSTABLESWHERE TYPE = 'V' AND

CREATOR = ' TSOUD01';---------+-----+---------+---------+------NAME OWNER TYPE COLCOUNT---------+-----+---------+---------+------EMPLOYEEV TSOUD01 V 3

SELECT NAME,TBNAME,COLNO,COLTYPE,LENGTH,NULLSFROM SYSIBM.SYSCOLUMNSWHERE TBNAME = 'EMPLOYEEV';---------+---------+---------+---------+---------+---------+---------+--NAME TBNAME COLNO COLTYPE LENGTH NULLS ---------+---------+---------+---------+---------+---------+---------+--EMPNO EMPLOYEEV 1 INTEGER 4 N DEPT EMPLOYEEV 2 INTEGER 4 Y YEARS EMPLOYEEV 3 INTEGER 4 Y

• SYSIBM.SYSTABLES

• SYSIBM.SYSCOLUMNS

Views – catalog information (1 of 2)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-64. Views - catalog information (2 of 2) CV8317.0

Notes:

In addition, the view definition is stored as well as "dependency" information.

The view definition is stored in SYSIBM.SYSVIEWS catalog table in one or more rows. Column TEXT defined as VARCHAR(1500) NOT NULL contains text or portion of the text of the statement that was used to create the view. Column SEQNO contains the sequence number of this row; the first portion of the view is on row one and successive rows have increasing values of SEQNO.

SYSIBM.SYSVIEWDEP.table records the dependencies of views on tables, functions, and other views. In this example, one row is inserted in this table to indicate the view EMPLOYEEV is dependent on table EMPLOYEE.


CREATE VIEW EMPLOYEEV AS SELECT EMPNO,DEPT,YEARS FROM EMPLOYEE;

SELECT NAME,TYPE,SEQNO,TEXTFROM SYSIBM.SYSVIEWSWHERE NAME = 'EMPLOYEEV';---------+---------+---------+---------+---------+---------+---------+---------+----NAME TYPE SEQNO TEXT ---------+---------+---------+---------+---------+---------+---------+---------+----EMPLOYEEV V 1 CREATE VIEW EMPLOYEEV AS SELECT EMPNO,DEPT,YEARS FROM EMPLOYEE

SELECT DNAME,DTYPE,BNAME,BTYPEFROM SYSIBM.SYSVIEWDEPWHERE DNAME = 'EMPLOYEEV';---------+---------+---------+---------+---------+--DNAME DTYPE BNAME BTYPE---------+---------+---------+---------+---------+--EMPLOYEEV V EMPLOYEE T

• SYSIBM.SYSVIEWS

• SYSIBM.SYSVIEWDEP

Views – catalog information (2 of 2)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-65. Materialized query tables (MQTs) CV8317.0

Notes:

The numbered steps above are as follows:

1. CREATE your MQT in terms of a Subselect

2. Populate the MQT with pre-computed result data (for example, using REFRESH)

3. Users then run ‘heavyweight’ decision support queries targeting massive operational tables.

4. The optimizer automatically rewrites the queries to access the MQT to satisfy the queries much more cheaply and with better performance.

Decision support queries

Decision support queries typically:

• Operate over huge amounts of data

• Perform multiple joins and complex aggregation operations.

The problem


MQT1DEPARTMENTEMPLOYEE

Subselect

CREATE TABLE MQT1 AS(SELECT D.DEPTNO, D.DEPTNAME,SUM(E.SALARY) AS TOTAL_SALARY,SUM(E.BONUS) AS TOTAL_BONUS,SUM(E.COMMISSION) AS TOTAL_COMMISSION

FROM EMPLOYEE E, DEPARTMENT D WHERE E.DEPTNO = D.DEPTNOGROUP BY D.DEPTNO, D.DEPTNAMEORDER BY D.DEPTNO)

MAINTAINED BY SYSTEMENABLE QUERY OPTIMIZATIONIN DBX.TSX;

User query

2.

3.

1.

Materialized query tables (MQTs)

• MQTs are pre-computed result tables

SELECT …FROM EMPLOYEE E, DEPARTMENT DWHERE E.DEPTNO = D.DEPTNO

AND ….GROUP BY D.DEPTNO, D.DEPTNAME

4.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The demand on response times has reached a very high level and traditional optimization techniques often fail to meet these new requirements.

The solution

• Precompute the whole or parts of each query beforehand and materialize the results into an MQT.

• Use these materialized results to provide a timely answer when queries are submitted.

Materialized Query Tables (MQTs)

These precomputed results are known as materialized query tables (MQTs).

The precomputed data is the result of a query that is a subselect associated with the table, specified as part of the CREATE/ALTER TABLE statement.

The source for a materialized query table can be base tables and views.

Automatic Query Rewrite (AQR)

MQTs can either be accessed:

• Directly using SQL or

• Can be chosen by the optimizer through automatic query rewrite

MQTs versus views

A view is only a logical definition while a materialized query table actually contains materialized data.

Creating MQTs

You can create an MQT from scratch using the CREATE TABLE statement

CREATE TABLE MQT1 AS(SELECT D.DEPTNO, D.DEPTNAME,SUM(E.SALARY) AS TOTAL_SALARY,SUM(E.BONUS) AS TOTAL_BONUS,SUM(E.COMMISSION) AS TOTAL_COMMISSIONFROM EMPLOYEE E, DEPARTMENT DWHERE E.DEPTNO = D.DEPTNOGROUP BY D.DEPTNO, D.DEPTNAMEORDER BY D.DEPTNO)MAINTAINED BY SYSTEMENABLE QUERY OPTIMIZATIONIN DBX.TSX;

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• DATA INITIALLY DEFERRED

This means the data is not inserted into the materialized query table when it is created. Use the REFRESH TABLE statement to populate the materialized query table, or use INSERT, LOAD, or other means to insert data into a user-maintained materialized query table.

• REFRESH DEFERRED

This means the data in the table is not refreshed on update of the base table (except by use of triggers), but can be refreshed at any time using the REFRESH TABLE statement. The data in the table only reflects the result of the query as a snapshot at the time when the REFRESH TABLE statement is processed or when it was last updated for a user-maintained materialized query table.

• MAINTAINED BY SYSTEM

This means the materialized query table is maintained by the system. Only the REFRESH TABLE SQL statement is allowed on the table. This is the default.

• MAINTAINED BY USER

This means the materialized query table is maintained by the user, who can use the LOAD utility, an SQL data change statement, a SELECT from data change statement, or REFRESH TABLE SQL statements on the table.

• ENABLE QUERY OPTIMIZATION

This means the materialized query table can be used for query optimization. If the Subselect specified does not satisfy the restrictions for query optimization, an error occurs. This is the default.

• DISABLE QUERY OPTIMIZATION

This means the materialized query table cannot be used for query optimization. The table can still be queried directly.

MQTs are registered in the DB2 catalog table SYSIBM.SYSTABLES. The identifier in column TYPE is ‘M’ for MQTs.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-66. Populating and refreshing MQTs CV8317.0

Notes:

REFRESH TABLE SQL statement

You can use the REFRESH TABLE SQL statement to populate a system-maintained or a user-maintained MQT.

Whenever you issue the REFRESH TABLE statement, the following actions are performed:

1. All rows are deleted from the MQT. As for regular tables, deletes are much faster if the data is stored in a segmented table space or universal table spaces.

2. The MQTs Subselect is executed to recalculate the data from the tables which are specified in this fullselect. Access to the MQT itself is blocked during the execution of the REFRESH TABLE statement.

3. The calculated data is then inserted into the MQT.

4. The catalog is updated.

The four steps described above are all done within a single commit scope.


Populating and refreshing MQTs

• REFRESH TABLE SQL stmt – Can populate:

• System-maintained MQT• User-maintained MQT

• Performs 4 actions in a single commit scope– All MQT rows deleted

• Logging• Mass delete if segmented table space

– Subselect executed• Uses MQT isolation level• No other access to MQT

– Data INSERTed into MQT• Logging

– Catalog updated• Refresh timestamp• MQT cardinality

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-67. Special registers CV8317.0

Notes:

Special registers

In addition to specifying ENABLE QUERY OPTIMIZATION there are two special registers that govern the selection of the MQT by automatic query rewrite at run time. They are:

1. CURRENT REFRESH AGE

2. CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION


CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION

CURRENTREFRESH

AGE

ANY

0

SYSTEM USER ALL NONE

All system-maintained query optimizationenabled MQTs

All user-maintained query optimizationenabled MQTs

All query optimizationenabled MQTs

None

None None None None

Special registers

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.6. Synonyms and Aliases

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-68. SYNONYM CV8317.0

Notes:

Synonym

An alternative name for a local table or local view.

For example, you can create a synonym to refer to:

• One of your own tables or views perhaps using a more meaningful name

• Someone else’s table or view so that you can then refer to that table or view without specifying the first qualifier.

Points to remember about synonyms

1. A synonym can only be defined on a local table or view.2. The table or view must exist.3. No authorization is required to define a synonym.4. Dropping a table or view also drops its synonyms.5. A synonym is unqualified and can only be used by the authid that created it.6. A synonym can only be used on the local system.


LISA

LISA

LISABART

CREATE TABLE EMP

CREATE SYNONYMSEMP FOR BART.EMP

SELECT *FROM SEMP

BART

GRANT SELECTON EMPTO LISA,BETH

BETH

SELECT *FROM LISA.SEMP

SELECT *FROM SEMP

12

3

4

5

6

SYNONYM

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-69. SYNONYM - catalog information CV8317.0

Notes:

A synonym can be considered as a "private" pointer to a table. It can only be referenced by its owner. No qualifier can be used. This also explains why synonym definitions are not stored in the SYSIBM.SYSTABLES catalog table as is the case for views.


CREATE SYNONYM SEMP1 FOR TSOUD01.EMPLOYEE;

CREATE SYNONYM SEMP2 FOR TSOUD01.EMPLOYEEV;

SELECT NAME,CREATOR,TBNAME,TBCREATORFROM SYSIBM.SYSSYNONYMSWHERE CREATOR = 'TSOUD01';---------+---------+---------+---------+---------+---------+---NAME CREATOR TBNAME TBCREATOR---------+---------+---------+---------+---------+---------+---SEMP1 TSOUD01 EMPLOYEE TSOUD01SEMP2 TSOUD01 EMPLOYEEV TSOUD01

• SYSIBM.SYSSYNONYMS

SYNONYM – catalog information

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-70. ALIAS CV8317.0

Notes:

Alias

An alternative name that can be used in SQL statements to refer to a table or view in the local or remote DB2 subsystem.

Points to remember about aliases

1. An alias can be defined on a local or remote table or view.2. The table or view need not exist when the alias is defined.3. Dropping a table or view has no effect on its aliases.4. Need CREATEALIAS privilege, SYSADM or SYSCTRL authority, DBADM or DBCTRL

authority on the database that contains the table, or System DBADM authority to define an alias.

5. An alias is a qualified name that can be used by any authid.6. An alias defined at one DB2 subsystem can be used at another DB2 subsystem.7. A fully qualified alias name (a three-part name) can refer to a remote alias.


LISA

LISA

LISABART

CREATE TABLE EMP

CREATE ALIASAEMP FORBART.EMP

SELECT *FROM AEMP

BART

GRANT SELECTON EMPTO LISA,BETH

BETH

SELECT *FROM LISA.AEMP

SELECT *FROM AEMP

12

3

4

5

6

ALIAS

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

In the visual, for Lisa to create the Alias successfully, she requires the CREATEALIAS privilege, unless either she is a DBADM or DBCTRL (see later) on the database that contains the table BART.EMP, or she is a SYSADM or SYSCTRL (see later), or she has System DBADM authority (see later).

Note

ALIAS is used for remote table or view and then the three part name becomes relevant. We do not discuss this here.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-71. ALIAS - catalog information CV8317.0

Notes:

Its definition in the catalog is analogous to tables and views.


CREATE ALIAS AEMP1 FOR TSOUD01.EMPLOYEE;

SELECT NAME,OWNER,TYPE,TBNAME,TBCREATOR,LOCATIONFROM SYSIBM.SYSTABLESWHERE TYPE = 'A' AND

CREATOR = 'TSOUD01';---------+---------+---------+---------+---------+---------+---NAME OWNER TYPE TBNAME TBCREATOR LOCATION---------+---------+---------+---------+---------+---------+---AEMP1 TSOUD01 A EMPLOYEE TSOUD01


ALIAS – catalog information

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-72. Object name translation CV8317.0

Notes:

At BIND time, DB2 resolves your 1-, 2-, or 3-part table name.

The logic followed is outlined below:

1. The SQL statement specifies a 1-part name, for example SELECT ... FROM X.

X can be a synonym, table, view, or alias. First it adds the prefix (CURRENT SQLID for dynamic SQL, BIND QUALFIER for static SQL) and looks up the catalog table SYSIBM.SYSSYNONYMS. The relevant columns in this table are:

- NAME, synonym for the table or view

- CREATOR, authorization ID of the owner of the synonym

- TBNAME, name of the table or view referred to by the synonym

- TBCREATOR, authorization ID of the owner of the table or view

a. If a row is present for the matching values in NAME and CREATOR columns, then it is a synonym.


‘Table’ Name used in SQL statement

1 part name 2 part name 3 part name

add prefix (authid)

SYSSYNONYMSlocal name remote name

table/view alias

local name remote name

SYSTABLES

process locally send to remote location

Object name translation

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Using the values in TBNAME and TBCREATOR columns, it looks up the SYSIBM.SYSTABLES catalog table for a matching row on columns NAME and CREATOR. The relevant columns in this table are:

• NAME, name of the table, view

• OWNER, authorization ID of the owner of the table or view

• TYPE, Indicates if it is a table (‘T’) or view (‘V’)

Be aware that, if an alias is used to denote the table or view, the name of that table or view, not the alias, is recorded in the catalog as the definition of the synonym. That severs the connection between the synonym and alias, and even if the alias is dropped and redefined, the synonym is still in effect and names the original table or view.

If the matching row has ‘T’ in column TYPE, the synonym is defined for a table and the resolution is complete. It uses the values in columns NAME and CREATOR to retrieve the data.

If the matching row has ‘V’ in column TYPE, the synonym is defined for a view. Using the values in columns NAME and CREATOR, it looks up for a matching row in SYSIBM.SYSVIEWDEP on columns DNAME and DCREATOR. In addition to SYSVIEWDEP, an internal table SYSIBM.SYSVTREE may also be looked into.

The relevant columns in SYSIBM.SYSVIEWDEP table are:

• BNAME, the name of the table or view on which the view is dependent

• BCREATOR, authorization ID of the owner of BNAME

• BTYPE, type of object (‘T’ is table and ‘V’ is view)

• DNAME, name of the view

• DOWNER, authorization ID of the owner of the view

If BTYPE = ‘T’, the resolution is complete. It uses the values in columns BNAME and BCREATOR to retrieve the data.

If BTYPE = ‘V’, the resolution is still not complete because the view is based on another view. The cycle is repeated until the table can be reached!

b. If a row is not present for the matching values in the NAME and CREATOR columns, then it is not a synonym. It is a table, a view, or an alias, and looks up the SYSIBM.SYSTABLES catalog table. The relevant columns in this table are:

• NAME, name of the table, view, or alias

• OWNER, authorization ID of the owner of the table, view, or alias

• TYPE, indicates if it is a table (‘T’), view (‘V’), or alias (‘A’)

• TBNAME, Name of the table or view referred to, if TYPE is ‘A”, else blank

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• TBCREATOR, authorization ID of the owner of the referred to table or view, if TYPE is ‘A’, else blank

• LOCATION, location name of the object of an alias. Blank for a table, a view, or an alias that was not defined with a three-part object name.

If the row has ‘T’ in column TYPE, the resolution is complete. It uses the values in columns NAME and CREATOR to retrieve the data.

If the row has ‘V’ in column TYPE, using the values in columns NAME and CREATOR, it looks up for a matching row in SYSIBM.SYSVIEWDEP on columns DNAME and DCREATOR. In addition to SYSVIEWDEP, an internal table SYSIBM.SYSVTREE may also be looked into.

The relevant columns in the SYSIBM.SYSVIEWDEP table are:








If the row has ‘A’ in column TYPE, using the values in columns TBNAME and TBCREATOR, it looks up for a matching row in SYSIBM.SYSTABLES on columns NAME and OWNER. The following possibilities exist:

• A row is not present. That is, the table or view on which the alias is defined does not exist. This results in SQLCODE -204 (undefined name).

• A row is present and column LOCATION is blank. This is treated as a local request, and it proceeds as follows:

- The row has ’T’ in column TYPE. That is, the alias is defined on a table. The resolution is complete. It uses the values in columns NAME and OWNER to retrieve the data.

- The row has ‘V’ in column TYPE. That is, the alias is defined on a view. Using the values in columns TBNAME and TBCREATOR, it looks up for a matching row in SYSIBM.SYSVIEWDEP on columns DNAME and DOWNER. The relevant columns in this table are:




xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.





• A row is present and column LOCATION is not blank. That is, the alias is defined with a three-part object name, and the request is sent to the location named in the column LOCATION.

2. The SQL statement specifies a 2-part name, for example SELECT ... FROM RAVI.X.

A qualified name is never interpreted as a synonym. Therefore, it directly looks up the SYSIBM.SYSTABLES catalog table, using the values RAVI for column CREATOR and X for column NAME, and follows the same logic as explained above.

3. The SQL statement specifies a 3-part name, for example SELECT ... FROM SANJOSE.BART.X.

The assumption is that the communication database is properly set up at the local location, and there is an entry for location SANJOSE. The request is simply sent to the remote location for processing.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.7. Indexes

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-73. What is an index? CV8317.0

Notes:

If you have no indexes on a table then every row would have to be read even when you are looking for only 1 or 2 rows amongst, say, many thousands of rows.

Also the order of rows in a table would not be maintained as rows are inserted, updated, and deleted.

An index is a DB2 object that can be used efficiently to locate a row or rows that meet particular search conditions. It is an ordered list of values with one or more pointers called RIDs that point to where these values can be found within the table. Conceptually, a RID is comprised of a page number and a “row locator” within the page.


EMPLOYEE table

IX2EMPL Index

I need to call Larry Jones... what is the best way for DB2 to find his phone number among

10,000 entries in the EMPLOYEE table?

I can create an index of course. It gives DB2 direct access to the

table rows I want.

What is an index?

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-74. Why have indexes? CV8317.0

Notes:

Performance improvement

There are several ways indexes can benefit your SQL transactions. These are discussed below. Also, in some cases, indexes can improve DB2 utility run times, for example, CHECK DATA.

Access paths

DB2 may choose to use an index in one of several different ways - matching, non-matching or screening. DB2 can process an index either forwards or backwards. In some cases DB2 may not even need to access the table.

Index-only access

If DB2 finds it can meet the requirements of an SQL query by processing only the index then it does so because avoiding access to the table reduces I/O and CPU costs. You can increase the likelihood of index-only access by creating a composite or ‘fat’ index by including up to 64 columns per key.


Why have indexes?

• Performance improvement– Access paths– Index only access– Avoid sorts

• Order by / Group by / Distinct– Cluster data– Foreign keys

• Integrity– Uniqueness

• Primary keys / Unique keys But:• Performance impact

– Delete – Insert– Update (Delete / Insert)

• Disk space• Utility run times

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Avoid sorts

A sort in an access path forces DB2 to materialize the whole result set, perhaps thousands of rows, at OPEN CURSOR time. DB2 then knows which row to deliver to the program first and in the right sequence. But this could mean a lot of unnecessary DB2 processing especially if the program subsequently decides to FETCH, say, only the first 20 rows in the result set, build only one screen of output and then terminate.

An ORDER BY, for example, does not cause a sort if DB2 uses an index in which the matching index rows are in the requested order. In this case, DB2 materializes the result set FETCH by FETCH and not at OPEN CURSOR.

All sorts should be investigated in every EXPLAIN review. You should check whether DB2 really needs to do the sort.

Cluster data

A clustering index indicates that data rows should be clustered on pages in the table space (or partition) in the same sequence as the sequence of the index. DB2 maintains that clustering sequence as much as possible during SQL INSERT activity and during a REORG. An application that could benefit from a clustering index, for example, is one that frequently SELECTs rows over a range of values using BETWEEN, <, > or LIKE.

Foreign keys

These are covered in the next unit when we shall see that it is strongly recommended that you build an index on each foreign key for performance.

Uniqueness

The UNIQUE option prevents the table from containing two or more rows with the same value of the index key. The constraint is enforced when rows of the table are updated or new rows are inserted or loaded.

Primary keys and unique keys

These are covered in the next unit when we shall see that primary keys and unique keys must have an index built on them.

Performance impact

Every time a row is DELETEd from or INSERTed into a table then each of the indexes needs to be maintained. The number of indexes you build on a table are probably limited by the required performance of INSERTs and DELETEs. You must also consider the cost of UPDATEs to the columns in affected indexes.

Indexes occupy disk space and disk space costs money. However, if you drop a column from a composite index to save disk space then it could mean response times go up due to, for example, the loss of index-only access. This may not always be a good tradeoff.

Some utilities, for example, REORG TABLESPACE may run longer with more indexes.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-75. Creating unique and non-unique indexes CV8317.0

Notes:

A unique index allows only one pointer (RID) per index value. For example, a unique index on LAST_NAME, FIRST_NAME would prevent a row from being added to the table if its LAST_NAME, FIRST_NAME values matched those of an existing row. On the other hand, a non-unique index allows duplicate values.

The key of an index is the ordered set of columns (or expressions) on which the index is defined, in the example on the visual LAST_NAME,FIRST_NAME. The individual combination of values in these columns are called ‘key values’ or just ‘keys’.

ASC (default) or DESC

DB2 has the capability for backward index scans, and it is not necessary to create an ascending and descending index on the same table columns.

UNIQUE

This specifies a unique index. DB2 does not allow you to insert or update a value that would lead to a duplicate key. One null entry is allowed.

UNIQUE WHERE NOT NULL


EMPNO FIRST_NAME LAST_NAME DEPTNO E_MAIL_ADDR

000010 CHRISTINE HAAS A00 [email protected] MICHAEL THOMPSON B01 -000030 SALLY KWAN C01 [email protected] JOHN GEYER E01 [email protected] IRVING STERN D11 -000070 EVA PULASKI D21 -000090 EILEEN HENDERSON E11 -000100 THEODORE SPENSER E21 [email protected] VINCENZO LUCCHESI A00 -000120 SEAN O'CONNELL A00 -000130 DOLORES QUINTANA C01 -000140 HEATHER NICHOLLS C01 -000150 BRUCE ADAMSON D11 -000160 ELIZABETH PIANKA D11 -000170 MASATOSHI YOSHIMURA D11 [email protected]

EMPLOYEE table

Creating unique and non-unique indexesCREATE UNIQUE INDEX IX1EMPL

ON EMPLOYEE(EMPNO)CLUSTER;

CREATE INDEX IX2EMPLON EMPLOYEE(LAST_NAME,FIRST_NAME);

CREATE UNIQUE WHERE NOT NULL INDEX IX3EMPLON EMPLOYEE(E_MAIL_ADDR);

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

This is like UNIQUE except that DB2 allows any number of null entries.

If the value of any column of the key is null, then the value of the whole key is considered to be null and DB2 allows multiple occurrences of such cases.

Note

If you do not specify UNIQUE or UNIQUE WHERE NOT NULL then you have no control over duplicates.

The sum of the length attributes of the columns must not be greater than the following limits, where n is the number of columns that can contain null values, and m is the number of varying-length columns in the key:

- 2000 - n for a padded, nonpartitioning index - 2000 - n - 2m for a non-padded, nonpartitioning index - 255 - n for a partitioning index (padded or non-padded)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

"

Figure 2-76. Index on expression CV8317.0

Notes:

You normally build an index on column values.

You can also build an index on expression. For this, your SQL must reference an expression equivalent to the one used in the index key.

DB2 stores the results of the expression in the index.

Any uniqueness constraint is enforced against the values that are stored in the index and not against the original values of the columns.

Restrictions:

Note the following restrictions:

• Maximum number of expressions in an index key is 64.

• An index on an expression cannot be a clustering index.

• DESC / RANDOM cannot be specified for indexes on expressions.


Index on expression

• ExampleCREATE TABLE EMPLOYEE (

ID INTEGER NOT NULL,LASTNAME VARCHAR(20) NOT NULL,FIRSTNAME VARCHAR(20) NOT NULL,SALARY DEC(15,2) NOT NULL,BONUS FLOAT );

CREATE INDEX INDEX1ON EMPLOYEE (SALARY + BONUS);SELECT SALARY + BONUS, LASTNAME, FIRSTNAMEFROM EMPLOYEEWHERE SALARY + BONUS < 51000;

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• You cannot use ALTER to add columns to an index on an expression.

• Primary key and foreign keys with expressions are not supported.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-77. Clustering CV8317.0

Notes:

We mentioned earlier that a clustering index indicates that data rows should be clustered on pages in the table space (or partition) in the same sequence as the sequence of the index.

The clustering index itself is essentially no different from any other index, except that it affects the physical order of rows in the table.

DB2 maintains that clustering sequence as much as possible during SQL INSERT activity and during a REORG.

SQL INSERT

When a row is inserted into the table, DB2 tries to place the new row in the home page defined by the clustering index. If there is not enough room, then DB2 tries the pages close to the home page.

CREATE TABLE has an APPEND. The default value for APPEND is NO and SQL INSERT observes the clustering index.


ClusteringIndex

IX1EMPL(EMPNO)

Non-ClusteringIndex

IX2EMPL(LAST_NAME,FIRST_NAME)

EMPLOYEEtable

• DB2 tries to keep the data rows in the sequence of the clustering index

Clustering

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

If the value for APPEND is YES, SQL INSERT disregards the clustering index and append the row at the end of the table (or appropriate partition)

For a Universal table space (partition-by-range), the partition is determined by the key. For a Universal table space (partition-by-growth), any partition with space at the end is used.

This option applies to all user tables (except global temp tables) and is independent of table space type.

This can be useful when queries are probes rather than range scans.

REORG

When you REORG a table space, DB2 restores the rows in the sequence defined by the clustering index.

An application that could benefit from a clustering index, for example, is one that frequently SELECTs rows over a range of values using BETWEEN, <, > or LIKE.

On the CREATE INDEX you can specify CLUSTER and this designates the index as the clustering index.

You can have only one clustering index per table.

You should define a clustering index for each table. If there is no explicitly created clustering index, DB2 uses the first index created in the chronological order as the implicit clustering index. If there is no index on the table, DB2 uses the physical sequence.

REORG is not influenced by the APPEND option.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-78. Index and index space CV8317.0

Notes:

What is an index space?

An index space is the set of VSAM Linear Data Sets that hold the index data. It belongs to the same database as the table and its table space. It can only be used for storing one index.

The CREATE INDEX creates the index, index space and VSAM data set.

There is no explicit CREATE INDEXSPACE statement.

If the index is defined with the DEFINE NO clause then this defers the physical creation of the data set until data is first inserted into the index.

There is also an option that allows you to create the VSAM data set yourself separately.

creator.IX1EMPL and dbname.IX1EMPL must be unique.

Index name has a maximum of 128 alphanumeric characters and index space name has a maximum of 8 alphanumeric characters.


CI_1CI_2CI_3

CI_5

CI_4

CI_6CI_7CI_8

CI_9CI_ACI_BCI_C

Indexspace 13 45 86

4 8 1319 33 45

62 75 86

. . . 4 . . . 8 . . 13 . . 19 . . 33 . . 45 . . 62 . . 75 . . 86

Index VSAM Data Set

Index and index space

• CREATE INDEX IX1EMPL ON EMPLOYEE......

– Creates:• An index called creator.IX1EMPL and• An index space called dbname.IX1EMPL and• One or more VSAM data sets catname.DSNDBx.dbname.IX1EMPL.p0001.Innn

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

"

Figure 2-79. Index and index space attributes CV8317.0

Notes:

The components of the USING STOGROUP clause are discussed below, first for nonpartitioned indexes and then for partitioned indexes. If you omit USING STOGROUP, DB2 defines the data sets using the default storage group of the database and the defaults for PRIQTY and SECQTY.

USING STOGROUP clause for nonpartitioned indexes:

For nonpartitioned indexes, USING STOGROUP indicates the data set for the index is defined by DB2. This clause also gives space allocation parameters.

PRIQTY

PRIQTY integer specifies the minimum primary space allocation for a DB2-managed data set.

1. If you specify PRIQTY with a value other than -1, the primary space allocation is at least n kilobytes, where n is the value of integer with the following exceptions:



CREATE INDEX IX4EMPLON EMPLOYEE(LAST_NAME ASC,DEPTNO DESC)

USING STOGROUP USCV831SPRIQTY 7200 SECQTY 7200PADDEDFREEPAGE 5PCTFREE 20BUFFERPOOL BP2

ALTER INDEX IX4EMPLPRIQTY 14400 SECQTY 1440BUFFERPOOL BP3FREEPAGE 15PCTFREE 25NOT PADDED

RENAME INDEX

Index and index space attributes

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E




- For any page size, if integer is greater than 4194304, n is 4194304.

If the DB2 subsystem is under DFP 1.5, the maximum value allowed for PRIQTY is 64GB (67108864 kilobytes). Otherwise, the maximum value of 4GB (4194304 kilobytes) applies.

2. If you specify PRIQTY -1 or do not specify PRIQTY, actual primary quantity is determined as follows:

- if the IXQTY subsystem parameter value is specified and is greater than 0, actual primary quantity is at least the value of IXQTY.

- If the IXQTY subsystem parameter is not specified or is 0, actual primary quantity is one cylinder.

SECQTY

SECQTY integer specifies the minimum secondary space allocation for a DB2-managed data set.

1. If you do not specify SECQTY, the following formulas determine actual secondary quantity:

- If the maximum size of a data set in the index is < 32 GB, the formula is:

actual secondary quantity in cylinders=MAX(0.1 * actual primary quantity in cylinders, MIN(calculated extent in cylinders,127))

- If the maximum size of a data set in the index is >= 32 GB, the formula is:

actual secondary quantity in cylinders=MAX(0.1 * actual primary quantity in cylinders, MIN(calculated extent in cylinders,559))

The calculated extent in cylinders is arrived at by DB2 using a sliding scale. A sliding scale means that the first secondary extent allocations are smaller than later secondary allocations. For example, for the sliding scale of secondary extent allocations that DB2 uses for a 64-GB data set, the size of each secondary extent is larger for each secondary extent that is allocated up to the 127th extent. For the 127th secondary extent and any subsequent extents, the secondary size allocation is 559 cylinders.

2. If you specify SECQTY 0, the actual secondary quantity is 0.

3. If you specify SECQTY and the value is not 0 or -1, the following applies;

This is the only rule that depends on the value of subsystem parameter MGEXTSZ (field OPTIMIZE EXTENT on installation panel DSNTIP7).

If MGEXTSZ is YES:

- If SECQTY is specified and specified secondary quantity is not equal to -1 or 0, the following formulas determine actual secondary quantity:

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• If the maximum size of a data set in the index < 32 GB, the formula is:

actual secondary quantity in cylinders=MAX(MIN(calculated extent in cylinders,127),specified secondary quantity in cylinders)

• If the maximum size of a data set in the index is >= 32 GB, the formula is:

actual secondary quantity in cylinders=MAX(MIN(calculated extent in cylinders,559),specified secondary quantity in cylinders)

If MGEXTSZ is NO:

- if SECQTY is n, the secondary space allocation is at least n kilobytes, where n is:

• 12 if n is less than 12 (for 4 KB page sizes)

• n if n is between 12 and 4,194,304

• 4,194,304 if n is greater than 4,194,304

Note

Executing the CREATE INDEX statement causes only one data set to be created. However, you might have more data than this one data set can hold. DB2 automatically defines more data sets when they are needed. Regardless of the value in PRIQTY, when a data set reaches its maximum size, DB2 creates a new one. To enable a data set to reach its maximum size without running out of extents, it is recommended that you allow DB2 to automatically choose the value of the secondary space allocations for extents.

USING STOGROUP clause for partitioned indexes:

If the index is partitioned, there is a PARTITION clause for each partition. Within a PARTITION clause, a USING clause is optional. If a USING clause is present, it applies to that partition in the same way that a USING clause for a secondary index applies to the entire index.

When a USING specification is absent from a PARTITION clause, the USING clause parameters for the partition depend on whether a USING clause is specified before the PARTITION clauses.

• If the USING clause is specified, it applies to every PARTITION clause that does not include a USING clause.

• If the USING clause is not specified, the following defaults apply to the partition:

- Data sets are managed by DB2

- The default storage group for the database is used

- A value of 12 is used for PRIQTY and SECQTY

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Preformatting

Two cylinders or tracks are preformatted at a time for indexes when they are created. Preformatting means writing X'00' on the pages. Further preformatting can occur when an application is issuing, for example, SQL INSERTs, and this can be resource-intensive. You can minimize this by having the LOAD or REORG utilities preformat allocated space by specifying the PREFORMAT parameter.

PADDED

This specifies that varying-length string columns within the index are always padded with the default pad character to their maximum length. When the index contains at least one varying-length column, the default depends on an install option.

Only NOT PADDED indexes support index-only access.

BUFFERPOOL

This identifies the buffer pool to be used for the index.

FREEPAGE

A FREEPAGE value of, say, 15 means that a free page is left for every 15 pages populated with data and this is good with sequential prefetch.

FREEPAGE is useful if you cannot prevent leaf page splits: the other half of the leaf page does not go to the end of the index. It is generally better, however, to minimize the number of leaf page splits by distributing all the free space you can afford to the leaf pages. PCTFREE 20% may be reasonable if you cannot reorganize your indexes frequently.

Values of 0 are best for PCTFREE and FREEPAGE in cases where there is no insert or update processing, or where you are inserting ever-ascending keys.

PCTFREE

PCTFREE is the percentage of free space left at the bottom of each index page by utilities that build indexes such as LOAD, REORG, and REBUILD INDEX.

The default is 10 percent. You should consider a higher value if the index key is longer than 80 bytes. To minimize leaf page splits with random inserts, at least four or five should fit in the free space per leaf page.

The value you specify should be sufficient to accommodate any additional index entries between one REORG and the next. REORG reestablishes free space.

Because of random variation, you should plan an index reorganization when half of the PCTFREE is used, assuming random inserts and deletes. Thus, with 10% PCTFREE, an index reorganization is probably needed when the index has grown by 5%. Hot spots cause leaf page splits much before this point.

Changing PCTFREE and FREEPAGE requires the index to be rebuilt in order for the new values to take effect.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

RENAME INDEX

You can use the extended RENAME statement to rename existing indexes. As for any other object, an index is unambiguously identified within a database by its OBID. Renaming the index does not change this number. Plans and packages identify indexes used in their access paths by those IDs. As a result, your plans and packages are not invalidated when you rename an index.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-80. DB2 index tree structure CV8317.0

Notes:

When an index is built, DB2 scans the table and collect the key value and address (RID or record ID) from each table row. Each key value and its appended RID become an index entry.

DB2 then sorts the keys and RIDs into key sequence, and builds a set of LEAF PAGES containing the index entries in key sequence.

Depending on your CREATE INDEX specification, DB2 may leave a certain percentage of free space in each leaf page, and every nth leaf page may be left completely empty.

The index page size can be 4K, 8K, 16K, or 32K.

The size of index pages is usually 4K, so typically 100 to 200 index entries fit on one page. For, say, a 1,000,000 row table, the number of leaf pages might be approximately 5000.

When the leaf pages are complete, DB2 creates nonleaf pages, which enable it to find the first index entry with a given key value very quickly, even when the table may have billions of rows. Each nonleaf page points to a set of pages, typically 100 to 300 on the next lower level. The nonleaf page at the top of the index tree structure is called the root page.


13 45 86

4 8 1319 33 45

62 75 86

. . . 4 . . . 8 . . 13 . . 19 . . 33 . . 45 . . 62 . . 75 . . 86

TABLE

Data Page Data Page Data Page Data Page

Row

Non-LeafPages

LeafPages

........WHERE EMPNO = 15 15Root

DB2 index tree structure

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-81. Catalog tables CV8317.0

Notes:

SYSIBM.SYSINDEXES

One row is inserted into the SYSIBM.SYSINDEXES catalog table when a CREATE INDEX statement is executed.

CLUSTERING

This indicates if the index is a clustering index or not

CLUSTERRATIOF

When multiplied by 100, the value of the column is the percentage of rows that are in clustering order. For example, a value of +0.1000000000000000E+01 indicates 100%.

NLEAF

Number of active leaf pages in the index. The value is -1 if statistics have not been gathered.


• SYSIBM.SYSINDEXPART

---------+---------+---------+---------+---------+---------+---------+-----NAME INDEXSPACE TBNAME CLUSTERING CLUSTERRATIOF ---------+---------+---------+---------+---------+---------+---------+-----IX1EMPL IX1EMPL EMPLOYEE Y +0.1000000000000000E+01 IX2EMPL IX2EMPL EMPLOYEE N +0.7777777777777777E+00 IX3EMPL IX3EMPL EMPLOYEE N +0.7777777777777777E+00 IX4EMPL IX4EMPL EMPLOYEE N +0.7777777777777777E+00

---------+---------+---------+---------+---------NLEAF NLEVELS UNIQUERULE PADDED AVGKEYLEN

---------+---------+---------+---------+---------1 2 U 6 1 2 D N 28 1 2 N 51 1 2 D N 12

+--------+------PGSIZE BPOOL

+--------+------4096 BP2 4096 BP2 4096 BP2 4096 BP3

---------+---------+---------+---------+---------+IXNAME PQTY SQTY PCTFREE FREEPAGE ---------+---------+---------+---------+---------+IX1EMPL -1 -1 10 0 IX2EMPL -1 -1 10 0 IX3EMPL -1 -1 10 0 IX4EMPL 3600 360 25 15

---------+---------+---------+---------+--IXNAME COLNAME COLSEQ ORDERING ---------+---------+---------+---------+--IX1EMPL EMPNO 1 A IX2EMPL LAST_NAME 1 A IX2EMPL FIRST_NAME 2 A IX3EMPL E_MAIL_ADDR 1 A IX4EMPL LAST_NAME 1 A IX4EMPL DEPTNO 2 D

• SYSIBM.SYSKEYS

---------+---------+-----SPACEF

---------+---------+-----+0.7200000000000000E+03 +0.7200000000000000E+03 +0.7200000000000000E+03 +0.1440000000000000E+05

Catalog tables• SYSIBM.SYSINDEXES

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

NLEVELS

Number of levels in the index tree. The value is -1 if statistics have not been gathered.

UNIQUERULE

This indicates whether the index is unique:

AVGKEYLEN

Average length of keys within the index. The value is -1 if statistics have not been gathered.

SYSIBM.SYSINDEXPART

Contains one row for each nonpartitioned secondary index (NPSI) and one row for each partition of a partitioning index or a data-partitioned secondary index (DPSI).

PQTY

The value is the primary space allocation in units of 4 KB storage blocks or -1.

For user-specified values of PRIQTY other than -1, the value is set to the primary space allocation only if RUNSTATS INDEX with UPDATE(ALL) or UPDATE(SPACE) is executed; otherwise, the value is zero.

PQTY is based on a value of PRIQTY in the appropriate CREATE or ALTER INDEX statement. Unlike PQTY, however, PRIQTY asks for space in 1KB units.

A value of -1 indicates that either of the following cases is true:

• PRIQTY was not specified for a CREATE INDEX statement or for any subsequent ALTER INDEX statements.

• -1 was the most recently specified value for PRIQTY, either on the CREATE INDEX statement or a subsequent ALTER INDEX statement.

SQTY

The value is the secondary space allocation in units of 4 KB storage blocks or -1.

For user-specified values of SECQTY other than -1, the value is set to the secondary space allocation only if RUNSTATS INDEX with UPDATE(ALL) or UPDATE(SPACE) is executed; otherwise, the value is zero.

SQTY is based on a value of SECQTY in the appropriate CREATE or ALTER INDEX statement. Unlike SQTY, however, SECQTY asks for space in 1KB units.

A value of -1 indicates that either of the following cases is true:

• SECQTY was not specified for a CREATE INDEX statement or for any subsequent ALTER INDEX statements.

• -1 was the most recently specified value for SECQTY, either on the CREATE INDEX statement or a subsequent ALTER INDEX statement.

If the value does not fit into the column, the value of the column is 0.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

SPACEF

Number of kilobytes of DASD storage allocated

SYSIBM.SYSKEYS

Contains one row for each column of an index key.

SYSIBM.SYSKEYTARGETS

For indexes on expression, catalog table SYSKEYTARGETS is used instead of SYSKEYS.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-82. DB2 addressing scheme CV8317.0

Notes:

An index entry on a leaf page contains a key value and a RID. A RID is 4 bytes in length for non-large partitioned and nonpartitioned table spaces.

The first 3 bytes of a RID refer to a data page, and the fourth byte of the RID points to a slot in the ID map array that contains the offset of the row on the page.

In the case of a large partitioned table space, the RIDs in indexes on the table are 5 bytes. The first 4 bytes of the RID refer to a data page, and the fifth byte of the RID points to a slot in the ID map array.


Page 8

Free Space

IDMap

5

RID

8 5Page-ID Slot

0

Data Page

Index Leaf Page

Key Field(s)

ROW

Index Entry

DB2 addressing scheme

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-83. DB2 addressing scheme - overflow pointer CV8317.0

Notes:

Variable length rows may occur for:

1. Rows with VARCHAR columns2. Tables which have had columns added or column lengths increased with the ALTER

statement3. Compressed rows (see later)

An SQL UPDATE may increase the length of a variable length row.

If necessary, DB2 compacts available free space in an attempt to keep the row on its original page.

If there is insufficient free space, DB2 may have to move the expanded row to a new page with sufficient free space leaving behind a ‘mail forwarding address’, that is, a pointer (a RID) in the original location pointing to the new location.

If the row is increased in length again with insufficient free space on the page, DB2 moves the row again, and the original pointer is updated to point to the new location. This avoids the build-up over time of a chain of pointers that must be followed to locate a moved row.


RID

8 5Page-ID Slot

Index Leaf Page

Key Field(s) Index Entry

Page 100

Free Space

ID Map

5 0

Data PageOverflow record

Page 8

Free Space

ID Map5 0

Data Page

100 5

RIDOverflow pointer

• After a row has overflowed, all indexes continue to point to the original position

A "Mail forwarding address"

DB2 addressing scheme – overflow pointer

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The use of the ‘mail forwarding address’ avoids having to update each index referencing the table to point to the new location of the row. Instead, each index continues to point to the original location of the row.

I/O wait time can be adversely affected by moved rows. If there is a ‘mail forwarding address’ to a moved row outside the range of prefetched pages, a synchronous I/O is issued to locate the moved row.

It is therefore important to know about these ‘mail forwarding addresses’. Their occurrences can be reported by the RUNSTATS utility (see later) and updated in SYSIBM.SYSTABLEPART in columns NEARINDREF and FARINDREF.

REORG TABLESPACE (see later) eliminates these ‘mail forwarding addresses’ and reestablishes free space.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-84. Leaf page - index entry format CV8317.0

Notes:

If an index is on a column with unique values, then each index key value has one RID appended to it. If an index is on a column with duplicate values, then each index key has one or more RIDs appended to it. The RIDs on a RID chain are maintained in data page number sequence to assist delete processing performance. The flag byte contains a pseudo-delete bit which indicates whether the entry is deleted or not.

Variable length keys can be padded with blanks (to maximum length) to create fixed-length keys. The decision to pad with blanks or not is determined by an installation option or the PADDED / NOT PADDED option on CREATE INDEX statement

If the fields can be null, a one-byte null indicator is stored with the key. This null indicator is before the column value so all null and all not-null values are grouped together.

NOT NULL WITH DEFAULT keys are stored as NOT NULL keys, for example, no null indicator bytes.

UNIQUE WHERE NOT NULL indexes are stored like non-unique indexes.


Unique Keys

f RID

f RID f RIDNon-Unique Keys

Key

Key

Flagbyte 4 or 5

bytes

Flagbytes

Numberof

RIDs(2 bytes)

f RID

Leaf page – index entry format

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-85. Non-leaf pages CV8317.0

Notes:

A leaf page has a high-key value. This high-key value is, in fact, the first key on the next leaf page. All keys on a leaf page are less than its high-key value. For example, the high-key for leaf page 9 is “Lioness”.

Nonleaf pages also contain the high-key values. But in the nonleaf pages unique high-key values are truncated. This is to save space and allow more keys to be stored per page.

Only the low order positions are dropped. The remaining fragment is just enough to allow DB2 to determine the range of keys for a given leaf page.

For nonunique keys with many duplicates, the index entry has a long RID chain. This may span several leaf pages. The nonleaf page contains the high RID as well as the key. By using the RID as well as the key, DB2 can more quickly find the correct leaf page.


Antelope 201Bear 202Cod 203

Cow 204Dog 205Eel 206

Elephant 207Frog 208Gazelle 209

Giraffe 301Horse 302Iguana 303

Jaguar 304Leopard 305Lion 306

Lioness 307Marmot 308Osprey 309

5 Cow6 El7

8 J9 Lione10

3 Gi4

Nonleaf Page 3 Nonleaf Page 4

Root Page 2

Leaf Page 8 Leaf Page 9 Leaf Page 10Leaf Page 6 Leaf Page 7Leaf Page 5

Non-leaf pages

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

"

Figure 2-86. Index page management CV8317.0

Notes:

Index page management - INSERT

When you INSERT a row and the free space on an index leaf page is used up, a page split occurs.

a. if a random insert pattern is detected on the index DB2 splits the index entries 50/50. Half the entries remain on the original page, and half of them are placed on a new page.

DB2 updates the nonleaf page above the split page to point to the new lower-level leaf page. This process can continue up to the root page.

If there is no free space in the root page to account for a new nonleaf page, the root page is split and a new root page is created. This results in an extra level being added to the index structure.

b. If an ever-ascending sequential insert pattern is detected for an index, DB2 splits index pages asymmetrically so that most existing keys stay on the original index


Index page management

• INSERT– Random insert pattern

• 50 / 50 page split – Ever-ascending or Ever-descending sequential insert pattern

• Asymmetric page split– REORG to reestablish free space

• UPDATE– Really DELETE then INSERT– Updating low-order field in composite index

• Entry less likely to move to another page

• DELETE– Pseudo delete – Physical delete

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

page, thereby leaving more space on the new index page for future inserts and preventing pages that are 50% empty from being left in the index.

When the last leaf page becomes full, DB2 simply adds a new leaf page rather than splitting the full one.

c. If an ever-descending sequential insert pattern is detected in an index, DB2 splits index pages asymmetrically so that most existing keys are moved to the new index page thereby making room on the original index page for future inserts.

When the last leaf page becomes full, DB2 simply adds a new leaf page rather than splitting the full one.

You should consider reorganizing an index when leaf page splits start to appear, because leaf page splits make sequential processing slower. This is significant for SELECTs which process a significant slice of the index, say, thousands of index entries. However, leaf page splits may be unavoidable if many inserts go to a hot spot which is not the end of the index.

Index page management - UPDATE

Update in the index consists of deletion of the entry on one page followed by insertion of a new entry on the same page or a different page.

Updating a column that is a low-order field in a composite index is less likely to cause the entry to move to another page than updating a high-order field in a composite index.

Index page management - DELETE

For page or row level locking (see later), DB2 simply switches on the pseudo-delete bit in the one-byte flag preceding each RID to indicate that the RID has been deleted or updated. This process is a logical delete.

A logical delete is a much faster process than the physical removal of the index entry.

It might increase the required DASD space, as both the old and new values exist for an index update.

The space is eligible for reuse after a commit.

Physical delete is performed at “garbage collection” time.

Garbage collection is triggered by either an SQL INSERT when the page is a certain percentage full, or an SQL FETCH when a threshold number of pseudo-deleted RIDs is reached.

For a task running with Uncommitted Read (UR) (see later), a RID with the pseudo-delete bit turned on is considered as not being present even if the delete is not committed. Other tasks attempting to access a RID with the pseudo-delete bit turned on are suspended until the delete is committed.

If the table or table space is X-locked (see later), physical delete is always used.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-87. Index-controlled partitioning CV8317.0

Notes:

Index-controlled partitioning

Index-controlled partitioning is one of the two types of partitioning in DB2 for z/OS. The other one is table-controlled partitioning. Table-controlled partitioning is the preferred type as it provides more capabilities.

Note

Index-controlled partitioning is possible only with a classic partitioned table space. Notice SEGSIZE 0 in the CREATE TABLESPACE statement. In DB2 10 this ensures a classic partitioned table space is created.


Table Space DefinitionCREATE TABLESPACE USTS7IN USDB1NUMPARTS 4SEGSIZE 0;Table DefinitionCREATE TABLE CUSTOMER ( ACCOUNT_NUM INTEGER

NOT NULL, CUST_LAST_NAME CHAR(30), LAST_ACTIVITY_DATE DATE, STATE CHAR(2) ) IN USDB1.USTS7; Index DefinitionCREATE INDEX PART_IXON CUSTOMER(ACCOUNT_NUM ASC)CLUSTER(PARTITION 1 ENDING AT (199),

PARTITION 2 ENDING AT (299), PARTITION 3 ENDING AT (399), PARTITION 4 ENDING AT (499))

Index DefinitionCREATE INDEX SI_0ON CUSTOMER

(STATE ASC)

Partitioning IndexPART_IX

(ACCOUNT_NUM ASC)

Clustering Sequence

101102103104105106

201202203204205206

301302303304305306

401402403404405406

101102103104105106

201202203204205206

301302303304305306

401402403404405406

Nonpartitioning index (NPI) SI_0

(STATE)

AL

CT

DE

FL

IA

IL

IN

KY

LA

MA

MD

MI

MN

MO

MS

NC

NH

NJ

NY

199

299

399

999

Index-controlled partitioning

Index-controlled partitioning• Partitioning index has high-key definitions and has to be the clustering index

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Creating an index-controlled partitioned table space is a 3-step process.

This example shows an outline of the syntax. DB2 also accepts the syntax PART n VALUES (value) in place of PARTITION n ENDING AT (value).

Partitioning index

You have to create a partitioning index to designate which rows go into which partitions. The partitioning index is also partitioned into the same number of VSAM data sets as is used for the table space partitions.

You have to specify a high key value for the columns in the partitioning index. Each high key value is the maximum value that can be placed in a partition. The high key values are used by DB2 to determine into which partition to insert a row.

The highest key for the last partition depends on how you define the table space.

1. For table spaces you create without LARGE or DSSIZE, the constant you specify after ENDING AT is not enforced.

2. For table spaces you create with LARGE or DSSIZE, the constant you specify after ENDING AT is enforced.

You can ALTER the high key values for one or more partitions as requirements change over time. The altered partitions then have to be reorganized.

The partitioning index has to be the clustering index.

Non-partitioning index (NPI)

Any index that does not specify the PART n VALUES keywords and is defined on a classic partitioned table, is a non-partitioning index (NPI) and cannot be physically partitioned; that is, it cannot have multiple physical partitions. However, pieces of an NPI can be allocated across multiple volumes to reduce I/O contention.

Step 1: Create the partitioned table space

CREATE TABLESPACE USTS7IN USDB1NUMPARTS 4SEGSIZE 0

Step 2: Create the table

CREATE TABLE CUSTOMER ( ACCOUNT_NUM INTEGER, CUST_LAST_NAME CHAR(30), LAST_ACTIVITY_DATE DATE, STATE CHAR(2) ) IN USDB1.USTS7;

Step 3: Create the partitioning index

CREATE INDEX PART_IXON CUSTOMER (ACCOUNT_NUM ASC)CLUSTER( PARTITION 1 ENDING AT (199), PARTITION 2 ENDING AT (299), PARTITION 3 ENDING AT (399), PARTITION 4 ENDING AT (499) )

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Logical partitions

In a non-partitioning index (NPI), the index entries that point to one particular data partition constitute an index logical partition. Some utilities, for example, REBUILD INDEX can run at the logical partition level. But NPIs can cause, for example, contention problems.

Converting index-controlled partitioning to table-controlled partitioning

There are several ways to convert from index-controlled partitioning to table-controlled partitioning.

A non-disruptive method is to run ALTER INDEX ixname NOT CLUSTER on the partitioning index and this converts the table to table-controlled partitioning. The index remains clustering until another index is explicitly defined with CLUSTER. If you wish, you could then run ALTER INDEX ixname CLUSTER on the same partitioning index. The partitioning remains as table-controlled partitioning.

Note

With table-controlled partitioning, the term partitioning index has a different meaning as we shall see in a later visual.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-88. Table-controlled partitioning - partitioning index(partitioned and non-partitioned) CV8317.0

Notes:

Table-controlled partitioning is possible either with a classic partitioned table space or with a UTS PBR.

Partitioning index

An index is regarded as a partitioning index if the columns in the index are the same as (that is, are in the same order and have the same collating sequence), or start with the same columns as, those specified in the PARTITION BY clause of the CREATE TABLE statement for table-controlled partitioned tables.

A partitioning index can have a superset of the partitioning columns, that is, it can contain all the partitioning columns plus additional columns.

A partitioning index can be either partitioned or non-partitioned.

Index PART_IX1

This is a partitioning index, because its key has the same left-most columns, in the same order, and using the same collating sequence as the columns (in this case only one column, ACCOUNT_NUM ASC) which partitions the table.


Table-controlled partitioning

101102103104105106

201202203204205206

301302303304305306

401402403404405406

101102103104105106

201202203204205206

301302303304305306

401402403404405406

101 DE 102 MO103 MI104 IL105 CT 106 KY

201 NJ202 FL203 IA204 MD205 AL206 NC

301 LA 302 MD303 MN304 MS305 CT306 NH

401 NY 402 IA 403 FL404 IN405 MA406 NH

Partitioning IndexPART_IX1

(ACCOUNT_NUM ASC)

Partitioning Index PART_IX2

(ACCOUNT_NUM ASC,STATE ASC)Table DefinitionCREATE TABLE CUSTOMER ( ACCOUNT_NUM INTEGER NOT NULL, CUST_LAST_NAME CHAR(30), LAST_ACTIVITY_DATE DATE, STATE CHAR(2) )

PARTITION BY (ACCOUNT_NUM ASC)(PARTITION 1 ENDING AT (199), PARTITION 2 ENDING AT (299), PARTITION 3 ENDING AT (399), PARTITION 4 ENDING AT (499))

IN USDB1.USTS8; Index DefinitionCREATE INDEX PART_IX1ON CUSTOMER(ACCOUNT_NUM ASC)

PARTITIONEDIndex DefinitionCREATE INDEX PART_IX2ON CUSTOMER (ACCOUNT_NUM ASC,STATE ASC)

Partitioning Column

Partitioning Column

Table-controlled partitioning – partitioning index(partitioned and non-partitioned)

• Has same leftmost columns as columns which partition table

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

The partitioning index PART_IX1 is also partitioned because the keyword PARTITIONED is specified in the CREATE INDEX statement.

Index PART_IX2

This is also a partitioning index, because its key also has the same left-most columns, in the same order, and using the same collating sequence as the columns (in this case only one column, ACCOUNT_NUM ASC) which partition the table. In fact, it has a superset of the partitioning columns, because column STATE is included.

The partitioning index PART_IX2 is not partitioned because the keyword PARTITIONED is not specified in the CREATE INDEX statement.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-89. Table-controlled partitioning - non-partitioning non-partitioned secondary index (NPSI) CV8317.0

Notes:

A non-partitioning (or secondary) index is any index where the columns do not coincide with the partitioning columns of the table. That is, a non-partitioning (or secondary) index is any index which is not a partitioning index.

There are two types of non-partitioning (or secondary) index:

• Non-partitioned secondary index and

• Partitioned secondary index

Non-partitioned secondary index (NPSI)

Index SI_1 is a secondary index, because its key (LAST_ACTIVITY_DATE ASC) does not have the same left-most columns as those which partition the table (in this case, ACCOUNT_NUM ASC).

Also index SI_1 lacks the option PARTITIONED so the index is non-partitioned. It is made up of a single data set.

Such an index is called a Non-Partitioned Secondary Index (NPSI).


105 APR CT101 FEB DE104 NOV IL106 JAN KY103 DEC MI102 MAR MO

205 JAN AL202 AUG FL203 OCT IA206 FEB NC201 JUL NJ204 DEC MD

305 SEP CT301 NOV LA302 JUL MD306 JUN NH303 MAY MN304 APR MS

403 MAR FL402 NOV IA404 FEB IN405 JUN MA406 OCT NH401 SEP NY

JAN

FEB

MAR

APR

MAY

JUN

JUL

AUG

SEP

OCT

NOV

DEC

Table DefinitionCREATE TABLE CUSTOMER ( ACCOUNT_NUM INTEGER NOT NULL, CUST_LAST_NAME CHAR(30), LAST_ACTIVITY_DATE DATE, STATE CHAR(2) ) PARTITION BY (ACCOUNT_NUM ASC)(PARTITION 1 ENDING AT (199), PARTITION 2 ENDING AT (299), PARTITION 3 ENDING AT (399), PARTITION 4 ENDING AT (499))

IN USDB1.USTS8; Index Definition (NPSI)CREATE INDEX SI_1 ON CUSTOMER (LAST_ACTIVITY_DATE ASC);


Non-partitioned Secondary Index

(NPSI) SI_1LAST_ACTIVITY_DATE

Table-controlled partitioning – non-partitioning non-partitioned secondary index (NPSI)

• The index columns do not coincide with the partitioning columns.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-90. Table-controlled partitioning - non-partitioning partitioned secondary index (DPSI) CV8317.0

Notes:

Data partitioned secondary index (DPSI)

The partitioned secondary index SI_2 is generally referred to as a Data Partitioned Secondary Index (DPSI):

1. Partitioned because of the attribute PARTITIONED

2. Secondary (or nonpartitioning) because the index contains a column (LAST_ACTIVITY_DATE) different from the partitioning column (ACCOUNT_NUM). In some cases, the index columns might be the same as the partitioning columns but specified in a different order or collating sequence).

The DPSI SI_2 is made up of multiple physical index partitions. The number of these index partitions equals the number of table space partitions. All RIDs of any one index partition point to the data rows of the corresponding table space partition.

Each partition of the DPSI SI_2 potentially has values for all dates JAN, .....DEC.

If the keyword UNIQUE is used when creating a DPSI, the uniqueness is enforced within each partition, not across partitions.


105 APR CT101 FEB DE104 NOV IL106 JAN KY103 DEC MI102 MAR MO

205 JAN AL202 AUG FL203 OCT IA206 FEB NC201 JUL NJ204 DEC MD

305 SEP CT301 NOV LA302 JUL MD306 JUN NH303 MAY MN304 APR MS

403 MAR FL402 NOV IA404 FEB IN405 JUN MA406 OCT NH401 SEP NY


JAN FEBMAR APR NOVDEC

JAN FEBJULAUG OCTDEC

APR MAY JUN JULSEP NOV

FEBMARJUN SEP OCTNOV

Data Partitioned Secondary Index

(DPSI) SI_2 LAST_ACTIVITY_DATE


IN USDB1.USTS8; Index Definition (DPSI)CREATE INDEX SI_2 ON CUSTOMER (LAST_ACTIVITY_DATE ASC) PARTITIONED;

Table-controlled partitioning – non-partitioning partitioned secondary index (DPSI)• The index columns do not coincide with the partitioning columns.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

DPSIs and utilities

DPSIs can promote efficient utility processing.

For example, if you run multiple LOAD jobs concurrently to load the partitions of a partitioned table space and if all indexes on the table are partitioned then index page contention is eliminated because there are no shared pages between the partitions on which contention can occur.

Another example is that online REORG of individual partitions can benefit from DPSIs.

DPSIs and query performance

Queries with predicates that solely reference columns of the DPSI are likely to experience performance degradation due to the need to probe each partition of the index for values that satisfy the predicate.

Queries with predicates that reference the DPSI and which also reference columns of the partitioning index can be restricted to specific partitions and therefore can benefit from the DPSI organization.

The DB2 optimizer is aware of the nature of DPSIs and takes this into account when determining the best access path.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-91. Table-controlled partitioning - partition one way and cluster another way CV8317.0

Notes:

Only one index can be defined as the clustering index on a table.

With table-controlled partitioning the clustering index can be any one of the indexes on the table whether partitioning, nonpartitioning, partitioned or non-partitioned.

No explicit CLUSTER index

If the clustering index is not defined, then the oldest index created on the table is used as the clustering index.

No index at all

If there are no indexes defined on the partitioned table, then clustering is done using the partitioning columns specified in the PARTITION BY clause.



106 JAN KY101 FEB DE102 MAR MO105 APR CT104 NOV IL103 DEC MI

205 JAN AL206 FEB NC201 JUL NJ202 AUG FL203 OCT IA204 DEC MD

304 APR MS303 MAY MN306 JUN NH302 JUL MD305 SEP CT301 NOV LA

404 FEB IN403 MAR FL405 JUN MA401 SEP NY406 OCT NH402 NOV IA

JAN FEBMAR APR NOVDEC

JAN FEBJULAUG OCTDEC

APR MAY JUN JULSEP NOV

FEBMARJUN SEP OCTNOV

101102103104105106

201202203204205206

301302303304305306

401402403404405406

Partitioning, Partitioned but Non-Clustering Index PART_IX1

Non-Partitioning, Partitioned and

Clustering Index IX2


IN USDB1.USTS8; Index DefinitionCREATE INDEX PART_IX1ON CUSTOMER(ACCOUNT_NUM ASC)PARTITIONEDIndex DefinitionCREATE INDEX IX2ON CUSTOMER (LAST_ACTIVITY_DATE ASC)PARTITIONEDCLUSTER

ClusteringSequence

Table-controlled partitioning –partition one way and cluster another way

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Index PART_IX1

This has the following attributes:

• Partitioning, because its key has the same left-most columns, in the same order, and using the same collating sequence as the columns (in this case, only one column, ACCOUNT_NUM ASC) which partitions the table.

• Partitioned, because the keyword PARTITIONED is specified on the CREATE INDEX statement.

Partitioning columns determine which partition row goes in.

Clustering Index determines location within partition.

Index PART_IX2

This has the following attributes:

• Non-partitioning, because its key is different from the column (ACCOUNT_NUM ASC) which partitions the table.

• Partitioned, because the keyword PARTITIONED is specified on the CREATE INDEX statement.

• Clustering, because the keyword CLUSTER is specified.

Note

With table-controlled partitioning, the partitioning columns determine which partition the rows go in and the clustering index controls the location within the partition. This example illustrates that partitioning and clustering can be done different ways.

Changing the clustering index

You also have the capability to change the clustering index with the ALTER INDEX statement. Since only one index can be explicitly defined as a clustering index, you must follow these steps to change the clustering:

1. ALTER INDEX <index name> NOT CLUSTER on the current clustering index. Clustering continues to be done according to this index until a new clustering index is explicitly defined.

2. ALTER INDEX <index name> CLUSTER on any index that should become the clustering index. Rows added to the table after these two ALTERs are clustered according to the new clustering index, but the existing rows remain in their current location.

REORG the table space to rearrange the rows in the new clustering index order. All existing rows are rearranged in the new clustering sequence. Any new rows are inserted in the new clustering sequence. "

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-92. Table-controlled partitioning - catalog entries CV8317.0

Notes:

Catalog entries for table-controlled partitioning

SYSIBM.SYSINDEXES

INDEXTYPE

D Data-partitioned secondary index

P Partitioning index on a table that uses table-controlled partitioning

SYSIBM.SYSCOLUMNS

PARTKEY_COLSEQ

The column’s numeric position within the table’s partitioning key.

The value is 0 if it is not part of the partitioning key.


• SYSIBM.SYSCOLUMNS

• SYSIBM.SYSTABLEPART

---------+---------+---------+------NAME CLUSTERING INDEXTYPE ---------+---------+---------+------TAB3_IX1 N P TAB3_IX2 N D TAB3_IX3 N D TAB3_IX4 N P TAB3_IX5 Y D

---------+---------+---------+---------+-------NAME PARTKEY_COLSEQ PARTKEY_ORDERING ---------+---------+---------+---------+-------EMPNO 1 A FIRST_NAME 0 E_MAIL_ADDR 0 LAST_NAME 0

---------+---------+---------NAME PARTKEYCOLNUM ---------+---------+---------EMPLOYEE 1


-----+---------+---------+---------+---------+------LIMITKEY LIMITKEY_INTERNAL HEX_LIMITKEY_INTERNAL -----+---------+---------+---------+---------+------20000 Ø.+..... 80004E20 30000 Ø.Í..... 80007530 40000 Ø.æ .... 80009C40

Table-controlled partitioning – catalog entries

• SYSIBM.SYSINDEXES

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

PARTKEY_ORDERING

Order of the column in the partitioning key:

A Ascending

D Descending

blank Column is not used as part of a partitioning key

SYSIBM.SYSTABLEPART

LIMITKEY

The high value of the partition in external format

LIMITKEY_INTERNAL

The highest value of the limit key of the partition in an internal format. Note that HEX_LIMITKEY_INTERNAL shows the value in hex. This is not a column in the catalog table.

SYSIBM.SYSTABLES

PARTKEYCOLNUM

The number of columns in the partitioning key.

Catalog entries for index-controlled partitioning

LIMITKEY in external format is held in SYSIBM.SYSTABLEPART but LIMITKEY in internal format is held in SYSIBM.SYSINDEXPART.

PARTKEYCOLNUM in SYSIBM.SYSTABLES and PARTKEY_SYSCOLSEQ and PARTKEY_ORDERING in SYSIBM.SYSCOLUMNS are all blank for index-controlled partitioning.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.8. Index compression

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-93. Index compression CV8317.0

Notes:

In data warehouse type applications, it is common to have many very large indexes defined on large tables. It is also possible to have index spaces that are much larger than the tables they are based upon. In order to lower the cost of ownership and to improve scalability (more index entries in a single physical index data set), in DB2 10, you can choose to compress your indexes and also define indexes with page sizes larger than 4 KB.

Unlike table compression, the compression mechanism implemented for index compression does not require a compression dictionary. Because DB2 performs dictionary-less compression, newly created indexes might begin compressing their contents immediately. The implementation of index compression only compresses the data in the leaf pages. The goal is to reduce the cost of ownership, hence index pages are stored on disk in their compressed format (physical 4 KB index page on disk) and are expanded when read from disk into 8 KB, 16 KB or 32 KB pages. In order to turn on compression for an index, it must be defined in an 8 KB, 16 KB or 32 KB buffer pool.


Index compression • Software compression is done on a block of data • No dictionary for the compression is required, but a compression

algorithm is used:• Not compressed in buffer pool, logs, and image copies• Prefix compression and RID compression

– See details in the notes taken from Redpaper (redp4345)• An index page on disk contains both compressed (leaf pages) and

non-compressed data (non-leaf pages)• The physical 4 KB page on disk is expanded to an

8 KB, 16 KB, or 32 KB page to reside in the buffer pool:– After a page is read from disk, a decompress routine is used to expand the

page from 4 KB to either 8 KB, 16KB, or 32 KB– Prior to writing a page to disk, a compress routine is used to shrink an 8 KB,

16 KB, or 32 KB page to a 4 KB page

• Index pages are only updated and logged while in uncompressed format

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

DB2 only compresses leaf pages, which represent the vast majority of the index space. However, even the non-leaf pages are read into the I/O work area and then copied (instead of being expanded, since they are not compressed) into the buffer pool.

Unlike data compression, log records for index keys are not compressed and image copies for indexes are not compressed. However, BSAM compression can be used to compress index image copies on DASD, and tape controllers are capable of compressing all data sets on tape.

Index compression does not use Ziv-Lempel and does not use a compression dictionary. Rather index compression takes advantage of the fact that indexes contain sorted keys. Some access methods such as VSAM in z/OS have long employed the concept of prefix compression for indexes. That is what DB2 is now doing for indexes.

DB2 compresses the index keys as well as RID (record identifier) Lists. At the end of each page is a key map which consists of two bytes for each distinct key value. This key map is not written to disk for a compressed index since the key map can be reconstructed when a compressed page is read from disk. Normally the key map does not constitute a large percentage of the space, but an exception would be a unique index with small keys, in which case DB2 can fit a lot of distinct key values on one page. For example, if there are 400 distinct key values on a page, then the key map consumes 800 bytes. As the non-uniqueness increases, the space for the key map decreases and the space consumed by RID Lists increases. When a RID List is compressed, we can expect to save one byte for every three bytes in the RID list.

The chief technique used by DB2 to compress the indexes is called prefix compression. Prefix compression is made possible by the fact that the keys on each index page are stored in sorted order from the left byte to right, either in ascending or descending order. The left-most bytes that are common from one key to the next constitute the prefix. Of course, the prefix length varies throughout the index, but generally the longer the prefix is, the better the compression is. Table 2-1 illustrates the concept of prefixes.

This sample index contains three CHAR(20) columns, the last name followed by a birth date, followed by the first name. Since the last name is defined as CHAR(20), we can expect to see some common prefixes of at least 20 bytes. In this case, since the first three characters of the second column tend to be repeated, they would be included in the prefix. Therefore the prefix for the 5 instances of Smith would be 23 bytes, and DB2 saves 4 of the occurrences of this prefix (minus the cost of control information). For Smithers and Smithson, 5 bytes are saved for the first 5 characters that are common to the previous key.

Table 2-1: sample indexLASTNAME CHAR(20) BIRTHDATE DATE FIRSTNAME CHAR(20)Smith 1980-02-05 John Smith 1980-04-22 AndreaSmith 1982-10-11 BillSmith 1984-05-31 Tommie

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.
As this example illustrates, the length of the prefix is very often equal to the length of the first column (if the first column is non-unique), but the prefix may be less than the first column or it may extend into the second column.
Smith 1985-07-09 SusanSmithers 1980-08-15 FredSmithson 1981-12-13 EricStewart 1982-07-05 George

Table 2-1: sample indexLASTNAME CHAR(20) BIRTHDATE DATE FIRSTNAME CHAR(20)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-94. DDL, catalog and utility changes CV8317.0

Notes:

The CREATE INDEX and ALTER INDEX have the keyword COMPRESS YES/NO. If you ALTER INDEX COMPRESS YES/NO, the index is placed in Rebuild Pending. Compression takes place for the whole index, cannot be activated at the partition level.

Note

IMAGE COPY of a compressed index creates an uncompressed format output file. This likely causes the size of the space required to store the image copy data set to exceed the size of the source index.

Utility DSN1PRNT is changed to print the contents of compressed VSAM index data sets. If you specify PARM='PRINT', unformatted compressed 4 KB pages are printed. If you specify PARM='PRINT,EXPAND', unformatted uncompressed 8 KB, 16 KB or 32 KB pages are printed. If you specify PARM='PRINT,FORMAT,EXPAND', formatted uncompressed 8 KB, 16 KB or 32 KB pages are printed. If you specify PARM='PRINT,FORMAT', formatted


DDL, catalog and utility changes

• CREATE INDEX COMPRESS YES|NO:– This matches the keyword used for CREATE TABLESPACE– The default is COMPRESS NO

• ALTER INDEX COMPRESS YES– Marks the index as REBUILD Pending

• New column COMPRESS in SYSIBM.SYSINDEXES:– CHAR(1) NOT NULL WITH DEFAULT ‘N'– Indicates whether or not index compression is active

• DSN1PRNT, DSN1COPY– Print the uncompressed contents of an index page

• DSN1COMP– Estimates space savings for indexes and recommends a page size of

8 KB, 16 KB, or 32 KB

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

header portions of pages are printed. DSN1COPY can copy an 8 KB, 16 KB or 32 KB IMAGE copy data set to a compressed 4 KB physical VSAM file.

As with table compression, you can use DSN1COMP to estimate the effectiveness of compressing an index. This helps you decide which indexes benefit from compression. Only one parameter is required for index estimates, PARM='LEAFLIM(x)', where 'x' is the number of leaf pages to be scanned. If you wish to scan all index pages, do not specify the LEAFLIM parameter. The estimate provides you with an evaluation of compression using different index page sizes. It is very important that you do not choose a larger index page size than what is recommended. You can end up wasting valuable buffer pool space if you do. A good rule of thumb is to stop below 50% unused space when choosing the compressed index page size.

Note

Index compression always compresses down, whatever index page size you choose, to a 4 KB page on disk. As inserts and deletes are processed, DB2 keeps track of the available space remaining for compressed data (keys/RIDs) as it would fit on disk (4 KB). Once DB2 determines there is no more available space in the compressed version of the page, it does not allow additional inserts against the non-compressed index page. This can cause you to waste space in the uncompressed index page and your buffer pool pages. It is best to choose a buffer/page size that reduces unused buffer space. One size does not fit all!

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-95. Comparison: Index and data compression CV8317.0

Notes:

Use DSN1COMP utility to simulate compression ratio without real index compression.

1. No compression or decompression in each insert or fetch. Instead at I/O time CPU overhead is critically sensitive to index buffer pool hit ratio. Bigger index buffer pool is strongly recommended for index compression.

2. LOAD or REORG is not required for compression.

3. Higher for relatively unique indexes with long keys.


25 to 75% (3)10 to 90%Typical compression ratio

No (2)YesCompression dictionary

NoYesCompression in buffer pool and log

YesYesCompression in DASD

Accounting and/or DBM1 SRB

AccountingCPU overhead

Page (1)RowLevel of compression

IndexData

Comparison: Index and data compression

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

2.9. Additional information

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-96. Automatic creation of objects (1 of 3) CV8317.0

Notes:

If you do not specify the IN clause in CREATE TABLE statement, DB2 creates an implicit database. The table space that is implicitly created is a partition-by-growth universal table space if the CREATE TABLE statement does not specify PARTITION BY clause, or a partition-by range universal table space if the CREATE TABLE statement specifies PARTITION BY clause. An implicit database can have multiple such table spaces, one for each of the tables stored in that database.

The name of the database is DSNnnnnn where nnnnn ranges from 00001 to 10000 and creator is SYSIBM. You cannot explicitly create a database with the same naming convention used for the implicit databases, nor can you specify the name of the implicit database in the IN clause of CREATE TABLE or CREATE TABLESPACE statement.

The characteristics of the implicit database depend on the DSNZPARM settings. You can use the ALTER DATABASE statement to change the characteristics.

The implicit partition-by-growth universal table space is created with DSSIZE 4G, SEGSIZE 32, MAXPARTITIONS 256, LOCKSIZE ROW, and LOCKMAX SYSTEM.


Automatic creation of objects (1 of 3)

• CREATE TABLE without IN clause– Database DSNnnnnn (where n is numeric) implicitly created – PBG UTS implicitly created if CREATE TABLE without PARTITION BY

is specified– PBR UTS implicitly created if CREATE TABLE with PARTITION BY

is specified

• System required objects created automatically (for example, index to enforce primary or unique key)– Only if the table space is created implicitly– For CREATE TABLE without IN or with IN DATABASE clause

• CREATE TABLESPACE without IN clause– Database used is DSNDB04– Here there is no automatic creation of objects

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The partition-by-range universal table space is implicitly created with DSSIZE 4G, SEGSIZE 32, MAXPARTITIONS 0, LOCKSIZE ROW, and LOCKMAX SYSTEM.

System required objects, for example, indexes to enforce primary or unique keys are automatically created for both implicit database and DSNDB04 if the table space is implicit.

Note

You can simplify your database implementation by letting DB2 implicitly create certain objects for you. On a CREATE TABLE statement, if you do not specify a database name, DB2 uses an existing implicitly created database. If an implicitly created database does not exist, DB2 creates one using the naming convention of DSNxxxxx (from DSN00001 to DSNnnnnn, where nnnnn is the maximum value of the sequence SYSIBM.DSNSEQ_IMPLICITDB, with a default of 10000).

If you wish to lower the 10000 limit, the maximum value for the sequence SYSIBM.DSNSEQ_IMPLICITDB can be altered with the installation SYSADM authority using the ALTER SEQUENCE statement with the MAXVALUE option. For example, to lower the limit to 500, you would use the following statement:

ALTER SEQUENCE SYSIBM.DSNSEQ_IMPLICITDB MAXVALUE 500;

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:

The visual shows you exactly how DB2 reuses those implicit databases. In V8, you were allowed to use ’DSN’ followed by a 5-digit number as the database name. Due to that, it is possible that after migration to V9, you already have databases defined in your subsystem that use names that are now reserved for implicit databases.

We assume that databases DSN00004 and DSN00005 are explicit databases that have been migrated from V8 to V9.

1. Create table TB1 without using the IN clause on the CREATE TABLE statement. As a result, DB2 creates database DSN00001 implicitly for this table.

2. Create table TB2 without using the IN clause on the CREATE TABLE statement. DSN00001 is not used to store a second table now. Instead, the database name is incremented by 1 and DB2 implicitly creates database DSN00002.

3. Again and for all following CREATE TABLE statements, the IN clause is not used. The database name is incremented by 1 again and database DSN00003 is implicitly generated.



CREATE TABLE TB1 LIKETBA DSN00001 implicitly createdCREATE TABLE TB2 LIKE TBA DSN00002 implicitly createdCREATE TABLE TB3 LIKE TBA DSN00003 implicitly createdCREATE TABLE TB4 LIKE TBA DSN00006 implicitly createdDROP TABLE TB2 DSN00002 stays as empty databaseCREATE TABLE TB5 LIKE TBA DSN00007 implicitly createdCREATE TABLE TB6 LIKE TBA DSN00008 implicitly created

OO

OO

CREATE TABLE TB9998 LIKE TBA DSN10000 implicitly createdCREATE TABLE TB9999 LIKE TBA DSN00001 reused. Now has 2 tablesCREATE TABLE TB10000 LIKE TBA DSN00002 reused. Now has 1 table

• CREATE TABLE TBx LIKE TBA– We assume databases DSN00004 and DSN00005 were explicitly

created in V8 and migrated to DB2 9

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

4. Starting with the creation of table TB4, the numbering of the table and the database diverges. Since DSN00004 already exists, DB2 continues to check whether DSN00005 is available for being created. Since this one also exists, DB2 must increment the number one more time, and finally implicitly creates database DSN00006.

5. You drop table TB2 now. Database DSN00002 that hosted this table is not implicitly dropped and continues to exist as an empty database.

6. If you create a new table TB5 subsequently, DB2 does not reuse database DSN00002, which has just become empty. Instead, it continues incrementing the database names by 1 and creates the next database in row, which is DSN00007.

7. If you continuously create new tables without using the IN clause, DB2 also continuously creates new implicit databases until it finally reaches DSN10000. Once this number is reached, DB2 starts wrapping around.

8. The next CREATE TABLE statement, which could be, for example, for table TB10001, again starts using the implicit databases with the counter reset to 1. Following this, DB2 creates table TB10001 in DSN00001, which has been used in the past for hosting TB1. DSN00001 now contains two tables.

The whole process continues over and over again, incrementing the number or database that is to be used by 1 after every CREATE TABLE without an IN clause in it.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:


CREATE TABLE TT(C1 INTEGER NOT NULL UNIQUEC2 INTEGER NOT NULL UNIQUE);

SELECT NAME,DBNAME,TSNAME,OWNERFROM SYSIBM.SYSTABLESWHERE NAME = ‘TT' AND

CREATOR = USER;---------+-----+---------+---------+-----NAME DBNAME TSNAME OWNER---------+-----+---------+---------+-----TT DSN00050 TT TSOUD01

SELECT NAME,OWNER,TBNAME,TBCREATORFROM SYSIBM.SYSINDEXESWHERE TBNAME = ‘TT';---------+---------+---------+---------+---------+-----NAME OWNER TBNAME TBCREATOR ---------+---------+---------+---------+---------+-----TTABCDEF_#_Y6P TSOUD01 TT TSOUD01TTABCDEF_#_VZP TSOUD01 TT TSOUD01


• SYSIBM.SYSINDEXES


Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 2-99. DB2 naming conventions for data sets CV8317.0

Notes:

A naming convention is used for the names of the VSAM data sets associated with table spaces and index spaces.

VSAM data sets for table spaces are named like this example:

VCAT.DSNDBD.DB1.TS1.I0001.A001

VSAM data sets for index spaces are named like this example:

VCAT.DSNDBD.DB1.IX1.I0001.A001

The naming convention is of the form a.b.c.d.e000n.f where:

• a = ICF catalog name or alias • b = DSNDBD for VSAM data and DSNDBC for VSAM cluster • c = Database name • d = Table space name or index space name • e = I or J, followed by a 4 digit number 000n and the last digit n can be 1 or 2 • f = The data set number


DB2 uses the following naming convention for table space and index space

vcat High Level Qualifier (STOGROUP VCAT)

x C if a cluster, D if a data object

db Database name (8 characters)

ps Table space name (8 characters) or first 8 characters ofindex space name (the result of scrambling the index name to ensure uniqueness within the database)

m Normally I, can also be J if online REORG is used

y Normally 1, can also be 2 if clone tables are used

Lnnn For segmented table space A001-A032For partitioned data sets (table space or index), the following:A001-A999 for partitions 1 to 999B000-B999 for partitions 1000 to 1999C000-C999 for partitions 2000 to 2999D000-D999 for partitions 3000 to 3999E000-E096 for partitions 4000 to 4096

DB2 naming conventions for data sets

vcat.DSNDBx.db.ps.m000y.Lnnn

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-100. Object dependencies CV8317.0

Notes:

Implications of dropping a table

As a result of, say, DROP TABLE PROJECT:

• Any dependent objects are dropped such as indexes, views, synonyms, and triggers (see CV841)

• Any referential constraints are dropped • Entries for PROJECT are removed from SYSTABLES and SYSCOLUMNS • Security privileges for PROJECT are removed from SYSTABAUTH • Any dependent application plans or packages are invalidated • Cached dynamic SQL statements that use PROJECT are removed • Access path statistics and space statistics for the table are deleted • DB2 reclaims the space if PROJECT is in a segmented table space


DATABASE

CONSTRAINT INDEX SYNONYM

SYNONYM

TABLESPACE

TABLE

VIEW

Object dependencies

• If you DROP a table:– Dependent objects, referential constraints, catalog definitions, statistics and cached

dynamic SQL are lost – Dependent plans / packages invalidated– DB2 reclaims space if table is in a segmented table space

• Check for table dependencies in SYSVIEWDEP, SYSPLANDEP, SYSPACKDEP, SYSINDEXES and SYSTABAUTH

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Checking for dependencies

SYSVIEWDEP, SYSPLANDEP and SYSPACKDEP indicate what views, application plans and packages are dependent on different DB2 objects. Also, SYSINDEXES tells you what indexes currently exist on a table and SYSTABAUTH tells you which users are authorized to use the table.

RESTRICT ON DROP

You must alter tables that have been created with RESTRICT ON DROP to remove the restriction before you can drop them.

Database hierarchy

DB2 maintains control information in the DB2 Directory (DSNDB01) which describes this hierarchy for each database. This control information is called a Database Descriptor - DBD.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 2-101. Checkpoint quiz CV8317.0

Notes:

This quiz helps to recap which table space, database and storage group would be used when you create a table.

Determine the:

1. Table space

2. Database and

3. Storage group

that would be used in each of the examples in the visual and complete the grid.

Can you also infer the type of table space, SEGSIZE, and MAXPARTITIONS in each case?

Each example should be treated independently of the others.


TABLE TS DB SG

1. TEMPL

2. MYEMP

3. YREMP

4. TDEPT

Checkpoint quiz1 CREATE TABLE TEMPL (C INTEGER) PARTITION BY (C) (PARTITION 1 ENDING AT(100),PARTITION 2 ENDING AT(200))

2 CREATE DATABASE DSN8D2APSTOGROUP DSN8G200BUFFERPOOL BP1

CREATE TABLE MYEMP (C INTEGER)IN DATABASE DSN8D2AP

3 CREATE DATABASE DSN8D2APSTOGROUP DSN8G200BUFFERPOOL BP1

CREATE TABLESPACE DSN8SEMPIN DSN8D2APUSING STOGROUP DSN8G200

CREATE TABLE YREMP (C INTEGER)IN DSN8SEMP

4 CREATE DATABASE DSN8D2AP

CREATE TABLESPACE DSN8SDEP IN DSN8D2AP

CREATE TABLE TDEPT (C INTEGER)IN DSN8D2AP.DSN8SDEP

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:


Having completed this unit, you should be able to:• Describe the DB2 objects that make up a DB2 database• Select the most appropriate parameters for these objects so

that they are implemented with the most appropriate attributes

• Create storage groups, databases, table spaces, tables, views, synonyms, aliases, materialized query tables, and indexes



Having completed this unit, you should be able to:• Describe the DB2 objects that make up a DB2 database• Select the most appropriate parameters for these objects so

that they are implemented with the most appropriate attributes

• Create storage groups, databases, table spaces, tables, views, synonyms, aliases, materialized query tables, and indexes



Unit summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 3. Implementing unique and referential requirements


This unit describes referential integrity. Following this, there is a discussion about identity columns and sequence objects.



• Describe the concepts of: - PRIMARY KEY - UNIQUE KEY and - FOREIGN KEY

• Implement these keys in DB2 • Describe the concepts of:

- REFERENTIAL CONSTRAINT and - REFERENTIAL INTEGRITY

• Implement REFERENTIAL CONSTRAINTS on • New tables • Existing tables

- With the appropriate DELETE rules • Drop REFERENTIAL CONSTRAINTS and their enforcing indexes • Query the appropriate catalog tables for RI details • Describe the relationships that require special handling • Describe what informational constraints are and their use • Discuss identity columns and sequence objects


Accountability:

• Machine exercises to implement referential constraints in the CV831 case study.

References


SC19-2972 DB2 10 for z/OS Command Reference


xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 3. Implementing unique and referential requirements 3-1

Student Notebook

.


SC18-9844 DB2 Version 9.1 for z/OS Command Reference



SC18-7416 DB2 UDB for z/OS Version 8 Command Reference


Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:


After completing this unit, you should be able to:• Describe the concepts of:

– PRIMARY KEY – UNIQUE KEY and – FOREIGN KEY


– REFERENTIAL CONSTRAINT and – REFERENTIAL INTEGRITY


– With the appropriate DELETE rules • Drop REFERENTIAL CONSTRAINTS and their enforcing indexes• Query the appropriate catalog tables for RI details• Describe the relationships that require special handling• Describe what informational constraints are and their use • Discuss identity columns and sequence objects

After completing this unit, you should be able to:• Describe the concepts of:





– With the appropriate DELETE rules • Drop REFERENTIAL CONSTRAINTS and their enforcing indexes• Query the appropriate catalog tables for RI details • Describe the relationships that require special handling• Describe what informational constraints are and their use • Discuss identity columns and sequence objects

Unit objectives

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

3.1. Referential integrity

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-2. Primary key CV8317.0

Notes:

Primary key

A primary key is a column (or set of columns) that identifies a row and distinguishes it from every other occurrence of a row.

A table can have only ONE primary key.

A primary key must be UNIQUE. You can have more columns than are necessary to achieve uniqueness, although this is generally not recommended.

A primary key cannot be NULL.

NOT NULL WITH DEFAULT is generally not recommended for primary key columns unless they have, say, the TIMESTAMP attribute.

Entity integrity

Entity integrity exists when the uniqueness of each occurrence of a row is guaranteed.


E01 Support ServicesE11 OperationsE21 Software Support

DEPTNODEPT

PrimaryKey

EMPNOEMP 000050 John B GEYER US01234 E01

000280 Ethel R SCHNEIDER US05678 E11

NI_NUMBER WORKDEPT

Primary key

• Primary Key– Column (or set of columns) – Identifies a row – Distinguishes it from every other occurrence of a row

• Must be UNIQUE• Cannot be NULL• Only ONE per table

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Primary index

A unique index known as the primary index must be defined on the columns of the primary key. The sequence of the columns in this index must be the same as that of the primary key definition.

Choose a primary key that is not updateable. It is good practice to have unique identifiers that remain the same.

As we shall see later, the columns of a primary key can be referenced by a foreign key.

You can still define a primary key even if no other table references the primary key table. The definition of a primary key will force the creation of a primary index, and once a primary index has been created, DB2 won't allow it to be inadvertently dropped. You will need to take into account any possible index maintenance overhead in this case.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-3. Unique key CV8317.0

Notes:

Unique keys

You can also define any number of unique keys to ensure that no two values are equal. DB2 enforces the unique constraints whenever you add or modify data.

A unique key may be composed of one or more columns. Each column must be defined as NOT NULL.

You can define a unique key by using the UNIQUE clause of the CREATE TABLE or ALTER TABLE statement.

DB2 forces you to create a unique index on the columns that constitute a unique key.

As we shall see later, the columns of a unique key can be referenced by a foreign key.



DEPTNODEPT

UniqueKey



NI_NUMBER WORKDEPT

Unique key

• You can also define any number of unique keys – Ensure no two values are equal

• DB2 forces you to create a unique index on the columns that constitute each unique key

• DB2 enforces the unique constraints whenever you add or modify data• DB2 does not allow you to drop an enforcing index

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-4. Foreign key CV8317.0

Notes:

Foreign key

A foreign key is a column (or set of columns) associated with a primary or unique key.

A foreign key value can be NULL. A multi-column foreign key is considered NULL if at least one of the columns is NULL.

You can define any number of foreign keys.

You can define a foreign key in a CREATE TABLE or ALTER TABLE statement.

Referential constraint

This association is called a REFERENTIAL CONSTRAINT.

A primary key or unique key of a REFERENTIAL CONSTRAINT is also known as a parent key.



DEPTNODEPT

(Parent table)

Foreign Key

EMPNOEMP

(Dependent table)

000050 John B GEYER US01234 E01000280 Ethel R SCHNEIDER US05678 E11

NI_NUMBER WORKDEPT

REFERENTIAL CONSTRAINT

Foreign key

• Foreign Key– Column (or set of columns) – Associated with a primary or unique key

• That is, a parent key • Association is called a REFERENTIAL CONSTRAINT• DB2 guarantees that non-null foreign key values always refer to

parent key values

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

A parent table is a table containing a parent key that is referenced by one or more foreign keys.

A dependent table is a table containing a foreign key. It can contain foreign keys referencing one or more parent tables. A dependent table can also be a parent table.

Once a REFERENTIAL CONSTRAINT is defined, then DB2 guarantees that non-null foreign key values always refer to parent key values.

Referential integrity

REFERENTIAL INTEGRITY is the automatic enforcement of all REFERENTIAL CONSTRAINTS.

Foreign key index

If you define an index on the foreign key columns, the index columns may be ASC or DESC, which may be different to the ASC or DESC attribute of the corresponding parent key index.

A foreign key index is optional but strongly recommended.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-5. Foreign key - column considerations CV8317.0

Notes:

More than one column

Parent Table Dependent Table ------------ --------------- Col1 ... ... ... Col3 ... ... ... ... Col5 ... ... ... ... ... Col8 Parent Key: (Col1,Col3) Foreign Key: (Col8,Col5)

Col5 and Col8 need not be adjacent, and Col8 may precede Col5 in the foreign key.

Col8 must have the same data type and size as Col1, and Col5 must have the same data type and size as Col3.



DEPTNODEPT

Foreign Key



NI_NUMBER WORKDEPT


ParentKey

Foreign key - column considerations

• A foreign key referencing a parent key consisting of more than one column must be created with the same:– Number and – Sequence of columns

• Each corresponding column must have the same:– Data type and – Size

• Column names, default values, and null attributes may be different

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-6. Referential integrity - DB2 implementation CV8317.0

Notes:

Referential constraints affect:

• INSERTs • UPDATEs • DELETEs

They do not affect SELECTs.

Certain rules define the referential constraints to be met between parent tables and dependent tables.

These rules are defined for each FK relationship.

In most cases, the rule is implicit. In one case (the DELETE rule for PKs), you choose the rule explicitly.


PARENT KEY FOREIGN KEY

INSERT

•You can add a row to a parent table provided the value of its PK is UNIQUE and NOT NULL. That is, the PK obeys the entity integrity rule.

•You can add a row to a dependent table if the value of its FK is NULL (if permitted) or equal to a value of its PK.

UPDATE

•You can update the PK value of a row in a parent table provided that there are no dependent rows.

•The new value must obey the entity integrity rule.

•Updating PKs is not recommended.

•You can update the FK of a row in a dependent table to a value that is NULL (if permitted) or to a value of its PK.

DELETE

•You specify an explicit DELETE rule:•RESTRICT•CASCADE•SET NULL•NO ACTION

•OK

Referential integrity - DB2 implementation

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

DELETE rules

The DELETE rule for PKs states the requirements to be met when you delete a row in a parent table. The options are:

1. RESTRICT - A row in a parent table cannot be deleted if there are rows in the dependent tables

with FK values equal to the PK value of this row. - Default if CURRENT RULES = DB2

2. CASCADE - If a row in a parent table is deleted using SQL DELETE, then all rows in the

dependent tables with FK values equal to the PK value of this row will also be deleted.

3. SET NULL - If a row in a parent table is deleted using SQL DELETE, then the FK of all rows in

the dependent tables with FK values equal to the PK value of this row will be changed to NULL.

4. NO ACTION - Same as for RESTRICT except for self-referencing tables. - Default if CURRENT RULES = STD

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-7. Creating a referential constraint CV8317.0

Notes:

If there is no unique index on the specified primary key or unique key, then DB2 considers the table definition to be incomplete.

The STATUS column in SYSIBM.SYSTABLES equals 'I', and the TABLESTATUS column gives the reason for the table being incomplete.

DB2 will not allow SQL DML access or utility access to an incomplete table.

An incomplete table can be altered or dropped, or an index can be created.


Creating a referential constraint

On new tables• For the parent table

– Use CREATE TABLE to define the:• Primary Key constraint and / or• Unique Key constraints

– Create a unique index on the columns that will be the:

• Primary Key and / or • Unique Keys

• For the dependent table– Use CREATE TABLE to define the:

• Foreign Key constraint and• Delete Rule

• Optional but recommended– Create an index on the columns that

will be the:• Foreign key

On existing tables• For the parent table

– Create a unique index on thecolumns that will be the:

• Primary Key and / or• Unique Keys

– Use ALTER TABLE to define the:• Primary Key constraint and / or• Unique Key constraints

• For the dependent table– Use ALTER TABLE to define the:

• Foreign Key constraint and• Delete rule

• Optional but recommended– Create an index on the columns that

will be the:• Foreign key

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-8. Creating the primary key and primary index CV8317.0

Notes:

PRIMARY KEY

The first step in setting up a new table's RI is to specify the PRIMARY KEY in the CREATE TABLE statement.

The CONSTRAINT clause for defining a PRIMARY KEY provides consistency with the way other DB2 constraints can be defined.

You can give a PRIMARY KEY constraint a NAME of up to 128 characters. This name must be unique for all constraints defined for a given table. If you omit a constraint name, then DB2 will provide one for you by using the name of the first column referred to in the constraint definition.


CREATE TABLE DEPT(DEPTNO CHAR(3) NOT NULL,DEPTNAME VARCHAR(36) NOT NULL,MGRNO CHAR(96),ADMRDEPT CHAR(3) NOT NULL,LOCATION CHAR(16),CONSTRAINT PKDEPT PRIMARY KEY (DEPTNO))IN EDUD001C.CV831DEV;

--

CREATE UNIQUE INDEX XDEPT ON DEPT (DEPTNO);

Creating the primary key and primary index

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-9. Creating unique keys and foreign keys CV8317.0

Notes:

UNIQUE KEYs

You specify a new table's UNIQUE keys in the CREATE TABLE statement.

The CONSTRAINT clause for defining a UNIQUE key provides consistency with the way other DB2 constraints can be defined.

You can give a UNIQUE key constraint a NAME of up to128 characters. This name must be unique for all constraints defined for a given table. If you omit a constraint name, then DB2 will provide one for you by using the name of the first column referred to in the constraint definition.

FOREIGN KEYs

You specify a new table's FOREIGN KEYs in the CREATE TABLE statement.

A FOREIGN KEY can reference a PRIMARY KEY or a UNIQUE key.


CREATE TABLE EMP(EMPNO CHAR(6) NOT NULL,FIRSTNME VARCHAR(12) NOT NULL,MIDINIT CHAR(1) NOT NULL WITH DEFAULT,LASTNAME VARCHAR(15) NOT NULL,NI_NUMBER CHAR(6) NOT NULL,WORKDEPT CHAR(3), PHONENO CHAR(6), HIREDATE DATE, JOB CHAR(8), EDLEVEL SMALLINT, SEX CHAR(1), BIRTHDATE DATE, SALARY DECIMAL(9,2), BONUS DECIMAL(9,2), COMM DECIMAL(9,2), CONSTRAINT RED FOREIGN KEY (WORKDEPT)REFERENCES DEPT ON DELETE SET NULL, CONSTRAINT UKNI_NUMBER UNIQUE (NI_NUMBER))IN EDUD001C.CV831DEV;

--

CREATE INDEX XWORKDEPT ON EMP (WORKDEPT);

--

CREATE UNIQUE INDEX XNI_NUMBER ON EMP (NI_NUMBER);

Creating unique keys and foreign keys

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The CONSTRAINT clause for defining a FOREIGN KEY provides consistency with the way other DB2 constraints can be defined.

You can give a FOREIGN KEY constraint a NAME. DB2 uses this name in error messages and also returns it in the SQLCA to identify a violated constraint.

This name must be unique for all constraints defined for a given table.

If you omit a constraint name, then DB2 will provide one for you by using the name of the first column referred to in the constraint definition.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-10. Creating informational referential constraint CV8317.0

Notes:

An informational referential constraint is a referential constraint that DB2 does not enforce during normal operations. Use these constraints only when referential integrity can be enforced by another means, such as when retrieving data from other sources. These constraints might improve performance by enabling the query to qualify for automatic query rewrite.

DB2 ignores informational referential constraints during insert, update, and delete operations. Some utilities ignore these constraints; other utilities recognize them.

For example, CHECK DATA and LOAD ignore these constraints. QUIESCE TABLESPACESET recognizes these constraints by quiescing all table spaces related to the specified table space.

You should use this type of referential constraint only when an application process verifies the data in a referential integrity relationship. For example, when inserting a row in a dependent table, the application should verify that a foreign key exists as a primary or unique key in the parent table. To define an informational referential constraint, use the


CREATE TABLE EMP(EMPNO CHAR(6) NOT NULL,FIRSTNME VARCHAR(12) NOT NULL,MIDINIT CHAR(1) NOT NULL WITH DEFAULT,LASTNAME VARCHAR(15) NOT NULL,NI_NUMBER CHAR(6) NOT NULL,WORKDEPT CHAR(3), PHONENO CHAR(6), HIREDATE DATE, JOB CHAR(8), EDLEVEL SMALLINT, SEX CHAR(1), BIRTHDATE DATE, SALARY DECIMAL(9,2), BONUS DECIMAL(9,2), COMM DECIMAL(9,2), CONSTRAINT RED FOREIGN KEY (WORKDEPT)REFERENCES DEPT NOT ENFORCED;

Creating informational referential constraint

• Informational RI is not enforced by database manager and is ignored by most utilities

• Informational RI is always used by the optimizer in query rewrite

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

NOT ENFORCED option of the referential constraint definition in a CREATE TABLE or ALTER TABLE statement.

Informational referential constraints are often useful, especially in a data warehouse environment, for several reasons:

• To avoid the overhead of enforcement by DB2.

Typically, data in a data warehouse has been extracted and cleansed from other sources. Referential integrity might already be guaranteed. In this situation, enforcement by DB2 is unnecessary.

• To allow more queries to qualify for automatic query rewrite.

Automatic query rewrite is a process that examines a submitted query that references source tables and, if appropriate, rewrites the query so that it executes against a materialized query table that has been derived from those source tables. This process uses informational referential constraints to determine whether the query can use a materialized query table. Automatic query rewrite results in a significant reduction in query run time, especially for decision-support queries that operate over huge amounts of data.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-11. Adding primary key constraints CV8317.0

Notes:


CREATE TABLE DEPT (DEPTNO CHAR(3) NOT NULL,DEPTNAME VARCHAR(36) NOT NULL,MGRNO CHAR(96), ADMRDEPT CHAR(3) NOT NULL, LOCATION CHAR(16)) IN EDUD001C.CV831DEV;

--

CREATE UNIQUE INDEX XDEPT ON DEPT (DEPTNO);

--

ALTER TABLE DEPT ADD CONSTRAINT PKDEPT PRIMARY KEY (DEPTNO);

Example

Adding primary key constraints

• Use ALTER TABLE– A unique index must exist on the specified columns before a

Primary Key constraint can be added

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-12. Adding unique and foreign key constraints CV8317.0

Notes:


CREATE TABLE EMP(EMPNO CHAR(6) NOT NULL,FIRSTNME VARCHAR(12) NOT NULL,MIDINIT CHAR(1) NOT NULL WITH DEFAULT,LASTNAME VARCHAR(15) NOT NULL,NI_NUMBER CHAR(6) NOT NULL,WORKDEPT CHAR(3), PHONENO CHAR(6), HIREDATE DATE, JOB CHAR(8), EDLEVEL SMALLINT, SEX CHAR(1), BIRTHDATE DATE, SALARY DECIMAL(9,2), BONUS DECIMAL(9,2), COMM DECIMAL(9,2)) IN EDUD001C.CV831DEV;

--

CREATE UNIQUE INDEX XNI_NUMBER ON EMP (NI_NUMBER);CREATE INDEX XWORKDEPT ON EMP (WORKDEPT);

--

ALTER TABLE EMPADD CONSTRAINT UKNI_NUMBER UNIQUE(NI_NUMBER);

ALTER TABLE EMPADD CONSTRAINT RED FOREIGN KEY(WORKDEPT)REFERENCES DEPTON DELETE SET NULL;

Example

Adding unique and foreign key constraints• Use ALTER TABLE

– A unique index must exist on the specified columns before aUnique Key constraint can be added

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-13. Dropping constraints CV8317.0

Notes:

The visual shows how the DROP CONSTRAINT clause of the ALTER TABLE statement can be used to drop:

• Primary key constraints • Unique key constraints • Referential constraints

Additionally, a unique key constraint can be dropped as follows:

ALTER TABLE.... DROP UNIQUE UKNI_NUMBER;


• Dropping a Unique Key Constraint

Example

ALTER TABLE EMPDROP CONSTRAINT RED;

Example

ALTER TABLE EMPDROP CONSTRAINT UKNI_NUMBER;

• Dropping a Foreign Key Constraint

Example

ALTER TABLE DEPTDROP CONSTRAINT PKDEPT;

Dropping constraints

• Dropping a Primary Key Constraint

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-14. Restrictions on dropping indexes CV8317.0

Notes:

Once an index has been defined to enforce a primary key constraint or unique key constraint, it cannot be dropped until the constraint itself is removed. Any attempt to remove such an index will result in an error.

This protects you from inadvertently dropping an index which is fundamental to the enforcement of data integrity.

To remove an index that supports a primary key or unique key constraint, you must first remove the constraint itself, using the ALTER TABLE statement. Any foreign key constraints that refer to the primary key or unique key constraints will be dropped automatically.


Primary Index

XDEPT


DEPT

Foreign Key



NI_NUMBER WORKDEPT


Primary Key

Constraint Name

PKDEPT

DEPTNO

DROP INDEX XDEPT;

---------+---------+---------+---------+---------+---------+---------+---DSNT408I SQLCODE = -669, ERROR: THE OBJECT CANNOT BE EXPLICITLY DROPPED.

REASON 0002 DSNT418I SQLSTATE = 42917 SQLSTATE RETURN CODE DSNT415I SQLERRP = DSNXIDIX SQL PROCEDURE DETECTING ERROR DSNT416I SQLERRD = 500 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION DSNT416I SQLERRD = X'000001F4' X'00000000' X'00000000' X'FFFFFFFF'

X'00000000' X'00000000' SQL DIAGNOSTIC INFORMATION ---------+---------+---------+---------+---------+---------+---------+---

Example

• To remove an index that supports a constraint, the constraint itself must first be dropped

ALTER TABLE DEPT DROP CONSTRAINT PKDEPT;

---------+---------+---------+---------+---------+---------+-------DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 0 ---------+---------+---------+---------+---------+---------+-------

DROP INDEX XDEPT; ---------+---------+---------+---------+---------+---------+-------DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 0 ---------+---------+---------+---------+---------+---------+-------

Example

Restrictions on dropping indexes• Indexes which enforce either a Primary Key or a Unique Key cannot be dropped

until the constraint is dropped

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-15. Catalog information CV8317.0

Notes.

The visual shows where details of DB2 constraints are recorded.

Primary key and unique key constraints

SYSIBM.SYSTABCONST contains one row for each primary key or unique key constraint.

SYSIBM.SYSKEYCOLUSE contains one row for every column in a primary key or unique key constraint from the SYSIBM.SYSTABCONST table.

Foreign key constraints

SYSIBM.SYSRELS contains one row for every foreign key constraint.


• Other details of RI definitions are recorded in:– SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS and SYSIBM.SYSINDEXES

• Foreign Key constraints are recorded in two catalog tables:1 SYSIBM.SYSRELS

2 SYSIBM.SYSFOREIGNKEYS---------+---------+---------+---------+---------+---------+--TBNAME CREATOR RELNAME COLNAME COLNO COLSEQ ---------+---------+---------+---------+---------+---------+--EMP KIDDJA RED WORKDEPT 6 1

---------+---------+---------+---------+---------+---------+------TBNAME CREATOR RELNAME REFTBNAME COLCOUNT DELETERULE---------+---------+---------+---------+---------+---------+------EMP KIDDJA RED DEPT 1 N

---------+---------+---------+---------+---------+---------+----CONSTNAME TBCREATOR TBNAME COLNAME COLNO COLSEQ ---------+---------+---------+---------+---------+---------+----PKDEPT KIDDJA DEPT DEPTNO 1 1 UKNI_NUMBER KIDDJA EMP NI_NUMBER 5 1

---------+---------+---------+---------+---------+---------+--------CONSTNAME TBCREATOR TBNAME TYPE IXNAME COLCOUNT---------+---------+---------+---------+---------+---------+--------PKDEPT KIDDJA DEPT P XDEPT 1UKNI_NUMBER KIDDJA EMP U XNI_NUMBER 1

Catalog information

• Primary Key and Unique Key constraints are recorded in two catalog tables:1 SYSIBM.SYSTABCONST

2 SYSIBM.SYSKEYCOLUSE

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Other information recorded about RI definitions

SYSIBM.SYSTABLES contains:

• STATUS

Set to X when the table has a unique constraint (primary key or unique key) and the table definition is complete.

Set to I when the table definition is incomplete.

• TABLESTATUS

Set to P if the definition is incomplete because the table lacks a primary index.

Set to U if the definition is incomplete because the table lacks a required index on a unique key.

Set to PU if the definition is incomplete because the table lacks a primary index AND a required index on a unique key.

SYSIBM.SYSCOLUMNS contains:

• KEYSEQ

The column's numeric position within the table's primary key.

SYSIBM.SYSINDEXES contains:

• UNIQUERULE

P means that the index is a primary index.

C means that the index is used to enforce a unique constraint.

SYSIBM.SYSFOREIGNKEYS contains:

• A row for every column of every foreign key. It includes the name of the constraint for which the column is part of the foreign key.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-16. Referential structures CV8317.0

Notes:

In order to meet the design objectives of the DB2 implementation of RI a number of DDL restrictions apply to ensure access path independence requirements. Any violations are detected at DDL time.

Cycles

A table within a cycle cannot be delete-connected to itself. This means in a cycle involving more than two tables, two or more delete rules must not be CASCADE.

On the next page is an example of the anomaly that might occur if this restriction were not enforced.

Self-referencing cycle

The DELETE rule must be CASCADE.

Multipath

In the visual, ORDER correctly has identical delete rules of RESTRICT on its relationships. Identical delete rules are a requirement and they must not be SET NULL.


HIERARCHY

Customer

Order

Orderline

CYCLES

Employee

Department

SELF-REFERENCINGCYCLE

Employee

MULTIPATH

EMPLOYEE

CUSTOMER

ORDER

• Terminology:– Dependent is immediately below Parent– Descendent is somewhere below a Parent

T1

T2 T3

CASCADE

RESTRICT

RESTRICTCASCADE

Referential structures• Tables linked by Referential Constraints• Types of Referential Structure:

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Example: Potential problem with a table if it were allowed to be delete-connected to itself:

Table T1 _______________ | PKT1 | FKT3 | |______|______| | T1A | ---- | <------<---- | T1B | T3A | <-----<------ | | T1C | T3B | | CASCADE | T1D | T3C | CASCADE | | | | | V | Table T2 Table T3 _______________ _______________ | PKT2 | FKT1 | | PKT3 | FKT2 | |______|______| |_______|_____| | T2A | T1A | | T3A | --- | | T2B | T1B | | T3B | T2B | | T2C | T1C | | T3C | T2C | | T2D | T1D | | T3D | T2D | | | | | | | | | V SET NULL | ---------------->------------------>----------------->

Issue the following SQL:

DELETE FROM T3 WHERE FKT2 IS NULL;

The result depends on the sequence in which DB2 accesses table T3

• If DB2 accesses table T3 in the sequence of rows T3D, T3C, T3B and T3A, only row T3A would qualify for the delete.

• If DB2 accesses table T3 in the sequence of rows T3A, T3B, T3C and T3D, all four rows T3A, T3B, T3C and T3D would qualify for the delete.xc

lusivo

form

ación

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-17. Additional considerations CV8317.0

Notes:

If you write your own code to implement special requirements, it is safe to put this code into a dedicated module that takes care of the required processing. Due to the operational impact, DB2 makes sure your data is consistent. Thus, it is better that your RI structures be of acceptable size. Avoid connecting applications through code tables. DB2 doesn't know the nature of these tables, and therefore requires a coordinated backup and recovery procedure. If a table has an RI problem, the entire table space is put into problem state (CHECK PENDING ... see later), even the tables that are not part of the RI structure. So, once again, one table per table space are the words of wisdom. At least one NULLable foreign key in a cycle allows you to insert data after the definition of the constraints.


Additional considerations

• What if DB2 does not support your requirements?– Write user code to provide it

• How big should an RI structure be?– Limit it to the size of the business meaning– Do not connect applications via code tables– Do not mix structures in one table space

• Create an Index on the Foreign Key• Allow at least one nullable Foreign Key in a cycle

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-18. TABLESPACESET concept CV8317.0

Notes:

A table space set is the set of table spaces containing a set of RI-connected tables so that no RI constraint “leaves” or “enters” the table space set.

The table space set is a DB2 concept and not a DB2 object. It is not explicitly created.

The visual serves as an illustration of the definitions rather than a recommendation of the way to implement referential structures.


Dependent Table TAB2

Table space TS1 Table space TS2 Table space TS3

•One Table space set•Two Referential Structures

Parent Table TAB1 Dependent Table TAB3

Dependent Table TAB5 Parent Table TAB4

Dependent Table TAB6

TABLESPACESET concept

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-19. REPORT TABLESPACESET CV8317.0

Notes:

The REPORT TABLESPACESET utility allows you to see the table spaces that make up a table space set. This utility will be primarily used for setting up backup and recovery procedures for RI-related tables.


1DSNU000I DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = USCV831ODSNU1044I DSNUGTIS - PROCESSING SYSIN AS EBCDIC0DSNU050I DSNUGUTC - REPORT TABLESPACESET USV831OD.TSLOCNDSNU587I -DBP8 DSNUPSET - REPORT TABLESPACE SET WITH TABLESPACE USV831OD.TSLOCN

TABLESPACE SET REPORT:

TABLESPACE : USV831OD.TSDEPT

TABLE : USCV831O.DEPARTMENTINDEXSPACE : USV831OD.IXDEPT1

INDEX : USCV831O.IXDEPT1INDEXSPACE : USV831OD.IXDEPT2

INDEX : USCV831O.IXDEPT2INDEXSPACE : USV831OD.IXDEPT3

INDEX : USCV831O.IXDEPT3DEP TABLE : USCV831O.DEPARTMENT

USCV831O.EMPLOYEEUSCV831O.PROJECT

TABLESPACE : USV831OD.TSEMPL

TABLE : USCV831O.EMPLOYEEINDEXSPACE : USV831OD.IXEMPL1

INDEX : USCV831O.IXEMPL1INDEXSPACE : USV831OD.IXEMPL2

INDEX : USCV831O.IXEMPL2INDEXSPACE : USV831OD.IXEMPL3

INDEX : USCV831O.IXEMPL3DEP TABLE : USCV831O.DEPARTMENT

USCV831O.ON_PROJECTUSCV831O.PROJECT .

.

.

DSNU580I DSNUPORT - REPORT UTILITY COMPLETE - ELAPSED TIME=00:00:00DSNU010I DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

REPORT TABLESPACESET

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-20. CHECK PENDING restrictive state CV8317.0

Notes:

When a table space is put in the CHECK PENDING state, it means that DB2 isn't sure that no RI or table check integrity violations exist in all the tables in the table space. In that case, since DB2 only allows access to data when it is 100% consistent, no access will be allowed to the data, except for certain utilities.

A typical example is the case where a table with data is altered to add a constraint. DB2 will not do inflight RI verifications, but will force the user to run the CHECK DATA utility to make sure that no RI violations exist, and if they do exist, to do the necessary cleanup.


CHECK PENDING restrictive state

When DB2 suspects an RI violation, it puts the table space in the

CHECK PENDING state.

• No SQL DML access allowed– (57011/-904 + reason code 00C900A3)

• The CHECK DATA utility can:– Verify RI and reset CHECK PENDING state if no RI violation– Verify RI, delete violating rows and reset CHECK PENDING state

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

3.2. Generating unique values

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 3-21. Identity columns CV8317.0

Notes:

An identity column is defined using the AS IDENTITY clause of the CREATE TABLE statement.

A table can have only one identity column.

CREATE TABLE ... ... colname datatype ... GENERATED ALWAYS / BY DEFAULT AS IDENTITY (START WITH n, INCREMENT BY n, CACHE n / NO CACHE, CYCLE / NO CYCLE, MINVALUE n / NO MINVALUE, MAXVALUE n / NO MAXVALUE, ORDER / NO ORDER)

GENERATED specifies that DB2 generates values for the column. GENERATED must be specified for an identity column.


Identity columns• A way for DB2 to automatically generate unique, sequential, and

recoverable valuesCREATE TABLE EMPLOYEE

(EMPNO INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 1,

INCREMENT BY 1,CACHE 20),

NAME CHAR(30),SALARY DECIMAL(8,2),DEPTNO SMALLINT);

INSERT INTO EMPLOYEE (NAME, SALARY, DEPTNO)

VALUES (‘Kate’, 100000.00, 50);

VALUES IDENTITY_VAL_LOCAL()INTO :IVAR;

• Can avoid concurrency andperformance problems

• Useful for generatingunique primary key values

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

GENERATED ALWAYS specifies that DB2 always generates values for the column when a row is inserted into the table. DB2 guarantees that all column values are unique. If an INSERT or UPDATE statement is issued in an attempt to provide an explicit value, DB2 returns an error and the statement fails.

GENERATED BY DEFAULT specifies that DB2 generates a value for the column when a row is inserted into the table except when a value is provided on the INSERT statement. Values can be changed using an UPDATE statement. DB2 does not guarantee the uniqueness of a generated value among all the column values, but only among the set of values it previously generated. GENERATED BY DEFAULT is intended to be used only for data propagation, where the intent is to copy the identity column values from one table to another.

AS IDENTITY is an attribute of the GENERATED keyword on the CREATE TABLE SQL statement.

START WITH, if used, specifies the first, or starting, value for the identity column. This value has a numeric data type, and can be any positive or negative value with a zero scale. If not specified, this keyword defaults to 1.

INCREMENT BY defines the interval between subsequent sequentially generated values. This keyword allows any positive or negative numeric value with a zero scale within the range of a large integer. If not specified, this keyword defaults to 1.

You have two options when dealing with caching. The first turns caching on by specifying CACHE followed by the number of values that should be cached. Any value greater than 2 within the range of an integer can be used, and if not specified, the default is 20. The other option is to turn caching completely off with NO CACHE. Caching sequence values in memory is a performance and tuning option that promotes faster access to the sequence values when the application can handle the behavior. NO CACHE turns off the caching mechanism.

CYCLE allows an identity to wrap around to a new beginning when the minimum or maximum value is reached. Cycling through values a second time can create duplicate values. NO CYCLE causes the identity value to stop being generated when the minimum or maximum is reached. NO CYCLE is the default.

MAXVALUE specifies the maximum value that can be generated for this identity column.

MINVALUE specifies the minimum value that can be generated for this identity column.

NO MINVALUE and NO MAXVALUE are the defaults if either MINVALUE or MAXVALUE is not specified.

NO MINVALUE specifies that no minimum end point of the range has been set. The minimum value for an ascending sequence becomes the START WITH value, or 1 if a START WITH value is not specified. For a descending sequence, the default is the lowest value, the largest negative value, for the data type of the column to which the identity is assigned.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

NO MAXVALUE specifies that no maximum end point of the range has been set. The maximum value for an ascending sequence is the greatest value allowed by the data type for that column. For a descending sequence, it is the START WITH value if specified, or –1 if no START WITH was specified.

For MINVALUE and MAXVALUE, any negative or positive value including zero can be specified. In addition, MINVALUE can be equal to MAXVALUE.

INCREMENT BY can be set to zero.

ORDER and NO ORDER specify whether or not the identity values must be generated in the order of the request. The default is NO ORDER. NO ORDER specifies that the values do not need to be generated in order of request, while ORDER specifies that the values are generated in order of request.

IDENTITY_VAL_LOCAL

The built-in scalar function, IDENTITY_VAL_LOCAL, returns a value with a data type of DECIMAL(31,0) regardless of the actual data type of the identity column to which the returned value corresponds.

The value returned by the function is the value that was assigned to the identity column of the table identified in the most recent single row INSERT statement with a VALUES clause for a table containing an identity column, where the INSERT statement was issued.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-22. Identity column considerations CV8317.0

Notes:

Identity column considerations

• When a table is being created like another table that contains an identity column, the new table inherits only the data type of the identity column and none of the other column attributes. If INCLUDING IDENTITY COLUMN ATTRIBUTES is specified, the new table inherits all of the identity column attributes. If the identified object of LIKE is a view, INCLUDING IDENTITY COLUMN ATTRIBUTES cannot be specified.

• If the table is not defined with an identity column, you can use the ALTER TABLE ... ADD COLUMN ... statement to add a new column as an identity column. An existing column cannot be altered to an identity column.

• Assume that tables T1 and T2 have the same definition but different identity column attributes. How can you copy the contents of T1 to T2 using an INSERT statement, but ask DB2 to generate new identity column values for T2?

- Ensure that the identity column for T2 is defined as GENERATED ALWAYS

- Execute the INSERT statement shown in the visual


Identity column considerations

• New LIKE clause option for CREATE TABLE– CREATE TABLE T2 LIKE T1 INCLUDING IDENTITY COLUMN

ATTRIBUTES

• Adding an identity column to a table– ALTER TABLE T ADD <column> GENERATED ... AS IDENTITY

• Overriding identity column values when using INSERT with subselect– INSERT INTO T2

OVERRIDING USER VALUESELECT * FROM T1

• Altering the characteristics of identity columns– ALTER TABLE <table> ALTER COLUMN <column>

• Unload and reload a table which has identity column

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• You can alter the characteristics of an identity column by using the ALTER TABLE ... ALTER COLUMN ... statement.

If you specify GENERATED ALWAYS and later have a requirement to unload or reload your tables, you can:

• ALTER TABLE ... ALTER COLUMN ... SET GENERATED BY DEFAULT

• Unload the table

• Reload the table

• ALTER TABLE ... ALTER COLUMN ... SET GENERATED ALWAYS

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-23. DB2 sequence object (1 of 2) CV8317.0

Notes:

There are six SQL statements and two expressions in support of sequence objects.

CREATE SEQUENCE

The CREATE SEQUENCE SQL statement creates a sequence object at the application server. The sequence object is a user-defined object that generates sequential numeric values. The CREATE is also used to describe the sequence value’s specifications.

The example in the visual shows the CREATE SEQUENCE statement with all of the keywords specified. In this example, we have specified INTEGER, even though it is the default. The sequence starts at 1, and increments by 1 to a maximum value of 5. When the maximum is reached, the sequence cycles back to the minimum value of 0 (zero). Five values are kept in the cache to assist with performance. On the first pass, that would be all five values generated. However, on subsequent cycles, six values will be generated.

ALTER SEQUENCE

The ALTER SEQUENCE SQL statement changes the attributes of the sequence object, such as INCREMENT BY, MINVALUE, MAXVALUE, CACHE, CYCLE, ORDER, and the


• CREATE SEQUENCE SEQTEST1AS INTEGER START WITH 1 INCREMENT BY 1 MINVALUE 0 MAXVALUE 5 CYCLE CACHE 5 NO ORDER;

• ALTER SEQUENCE SEQTEST1 RESTART WITH 100 INCREMENT BY 100 MAXVALUE 1000000;

• DROP SEQUENCE• COMMENT ON SEQUENCE• GRANT / REVOKE ON SEQUENCE• NEXT VALUE FOR and PREVIOUS VALUE FOR

DB2 sequence object (1 of 2)• A stored user-defined object that generates next ASC / DESC value

– Values generated can be:• SMALLINT, INTEGER, DECIMAL

(With 0 scale)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

point at which the sequence should be restarted. Only future values are affected, and then only after the ALTER has been committed. Whenever a sequence is ALTERed, there is always the risk of creating duplicate values, so care should be taken. If uniqueness is critical to the application, an unique index can be defined for the column using the sequence value.

Example

In the ALTER SEQUENCE in the visual, the sequence just created will be modified. It was decided that the original maximum was a little low, so it is being increased to 1,000,000. The sequence will also no longer be incremented by 1, but rather by 100. When the sequence is restarted, it will restart at 100 rather than the minimum. The minimum, cache size, and cycle values will all remain the same as the values with which the sequence was created.

The ALTER does not take affect until it has been committed.

DROP SEQUENCE

The DROP SEQUENCE statement drops the sequence object and removes a sequence object description from the DB2 catalog.

COMMENT ON SEQUENCE

Allows a user to supply a comment or description for a sequence in the REMARKS column of the DB2 catalog table SYSIBM.SYSSEQUENCES.

GRANT/REVOKE

Grant or revoke the ALTER or USAGE privilege for a user-defined sequence or list of user-defined sequences from an authorization identifier (auth ID, or list of auth IDs, or from PUBLIC).

NEXT VALUE FOR and PREVIOUS VALUE FOR

NEXT and PREVIOUS VALUE FOR are used to reference the sequence values by specifying the named sequence.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-24. DB2 sequence object (2 of 2) CV8317.0

Notes:

Example 1

The sequence is simply being incremented by 1.

Each subsequent VALUES statement generates the next available sequence.

The COMMIT has no effect on the sequence generation.

The last VALUES, performing a PREVIOUS VALUE FOR, still returns the last value generated by the previous VALUES.

Example 2

This uses the sequence number generated as part of the SET clause of an UPDATE. This is valid for both searched and positioned updates.

Example 3

In this example, we use the syntax for a select from insert. This syntax allows us to examine the sequence value generated without having to perform a separate SELECT.


DB2 sequence object (2 of 2)• CREATE SEQUENCE MYSEQ START WITH 1 INCREMENT BY 1• Examples

– Example 1VALUES NEXT VALUE FOR MYSEQ INTO :HV .. Generates value of 1VALUES NEXT VALUE FOR MYSEQ INTO :HV .. Generates value of 2 COMMIT;VALUES PREVIOUS VALUE FOR MYSEQ INTO :HV .. Returns most recently generated

value of 2– Example 2

UPDATE T SET C1 = (SELECT PREVIOUS VALUE FOR MYSEQ FROM T);UPDATE T SET C1 = NEXT VALUE FOR MYSEQ;

– Example 3SELECT * FROM FINAL TABLE

(INSERT INTO TESTTAB (KEYVALUE, TESTSEQ)VALUES ( NEXT VALUE FOR MYSEQ,

NEXT VALUE FOR MYSEQ2 ))• Ranges and cycles• Generating constants• Duplicate sequences• Caching• Gaps• Catalog

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• Ranges and cycles

A sequence can be optionally defined to CYCLE after reaching its maximum value (or minimum if descending).

- The sequence will wrap around to the other end of the range and start a new cycle of values.

- The default is NOCYCLE.

The first cycle always starts with the START WITH value, but all subsequent cycles start with MINVALUE (ascending sequence) or MAXVALUE (descending sequence).

If NO CYCLE is in effect, sequence value generation will stop when the sequence reaches the end of a logical range of values.

• Generating constants example

CREATE SEQUENCE consequence AS INTEGER START WITH 1 INCREMENT BY 0 MINVALUE 0 MAXVALUE 5 CYCLE CACHE 5 NO ORDER;

A constant, non-changing sequence can be generated by specifying an INCREMENT BY keyword set to 0 (zero). Every sequence generated would be the same as the START WITH value, the first sequence generated. The MAXVALUE or high value of the data type could never be reached, and a cycle would never be performed for this sequence if the CYCLE keyword were specified. The START WITH value would have to be within the MINVALUE and MAXVALUE keyword values.

If START WITH were equal to MINVALUE and MINVALUE were equal to MAXVALUE, and CYCLE were specified, the START WITH value would be generated repeatedly. However, if NO CYCLE were specified, one sequence value would be generated equal to the START WITH value, and a subsequent attempt to generated a sequence would receive an error. This is true even if INCREMENT BY is a non-zero value.

• Duplicate sequences

DB2 will make every attempt to ensure that all sequences generated are unique. However, this is not always possible. If CYCLE is specified for the sequence, the sequence is restarted and the same sequence values are generated. If the previous set of values are still in use, the new set will be duplicates of the previous set.

The same can be true if the RESTART WITH keyword is specified and the sequence is restarted with a value that is already in use, or the direction the sequence is generated is reversed by altering the INCREMENT BY keyword from positive to negative or negative to positive. Duplicate values can be avoided if a unique index is created on the

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

column that will contain the sequence value. Prevention is accomplished by generating a error and having the insert process fail for that sequence value.

• Caching

- CACHE option allows DB2 to cache preallocated values in memory for fast access

• Reduces synchronous I/O to the catalog table SYSIBM.SYSSEQUENCES

• I/O to table only required when cached values are exhausted

- Recommended value is 20

• Assigning a higher value gives no benefit and increases the size of gap should a failure occur

- Use NOCACHE if values must be assigned in strict numeric order

• Each assignment of sequence value results in update of catalog

• Gaps

A gap is any unintentional break in a sequence. Unintentional here means that the gap was not the result of using the INCREMENT BY keyword of the CREATE or ALTER SQL statement. If INCREMENT BY specifies a value greater than 1 or less than -1, the generated sequences, although sequential, will not be without gaps. The gaps that are of concern to us are the unintentional gaps caused by anything other than the INCREMENT BY keyword. There are a number of ways in which gaps might be caused in a sequence. If a transaction is rolled back after the sequence has been generated, that generated sequence is lost and a gap will exist. The SQL statement using the sequence is all that is rolled back; the sequence itself continues to increment forward. Similarly, if an SQL statement fails after the sequence for that SQL statement has already been generated, the generated sequence is once again lost and a gap will exist. Generated sequences can also be lost if something happens to the cache. If the cache is lost, all sequences not used in the cache are also lost, causing a gap. The cache can be lost by stopping SYSIBM.SYSSEQ table space, if the DB2 subsystem is stopped, or if the DB2 subsystem crashes. DDL can also negatively affect a sequence. If the SEQUENCE is DROPped or ALTERed and the DROP or ALTER is rolled back, gaps could be left in the sequence.

Unintentional gaps could also result if multiple transactions are processing using the same sequence name.

• Catalog information

- SYSIBM.SYSSEQUENCES (in SYSIBM.SYSSEQ table space)

• Records all data about SEQUENCE attributes

• MAXASSIGNEDVAL column: last possible assigned value

• Columns:

- PRECISION: Precision of sequence object's decimal or other numeric data type

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

- RESTARTWITH: Restart with numeric constant value specified during ALTER of the sequence or NULL

- SYSIBM.SYSSEQUENCESDEP (in SYSIBM.SYSSEQ2 table space)

• Columns:

- DTYPE / DSCHEMA

- BSCHEMA / BNAME

- SYSIBM.SYSSEQUENCEAUTH (in SYSIBM.SYSSEQ2 table space)

• Columns:

- GRANTOR / GRANTEE

- SCHEMA / NAME

Spreading inserted rows across multiple partitions

Sequences can also be used to spread inserted rows across multiple partitions if used to supply the partitioning value.

By manipulating the INCREMENT BY and RESTART WITH values and specifying CYCLE, a sequence could be generated that would force each new inserted row to go to a different partition of a partition table space.

As an alternative, and because a sequence is independent and not associated to any particular column, all or part of the generated sequence value could be used as part of the partition key in a attempt to spread the rows evenly across multiple partitions of a partitioned table space.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 3-25. Identity columns versus sequences CV8317.0

Notes:

Sequence objects build on the concepts introduced with the identity columns, with some significant enhancements. Sequences are standalone objects that generate sequence values when requested by an application. These values can be used by that application for whatever purpose the application chooses. However, identity columns are associated with a specific column in a specific table, and can be used only to supply a value for that column.

What is similar and what is different?

A sequence has nothing to do with a specific table. There is not a one-to-one relationship between a sequence object and any table. A sequence object simply gives the application the ability to get the next unique sequential value. The application can then do with that value anything it chooses. In fact, a single sequence value could be used multiple times in the same SQL statement to supply a value for multiple columns, or multiple sequence objects could be used. Sequences use the SQL expressions NEXT VALUE FOR and PREVIOUS VALUE FOR to retrieve the next generated or previously generated values from the sequence. These expressions are not allowed against identity columns.


Identity Columns Sequences•Associated with one specific column in one specific table

•Stand-alone object

•One to one relationship between identity column and table

•Multiple sequences can be used in one table

•One sequence can be used in many tables

•One sequence can be used multiple times in one SQL stmt to supply values for multiple columns in one table

•SELECT... IDENTITY_VAL_LOCAL •Within agents scope only

•SELECT....NEXT VALUE FOR / PREVIOUS VALUE FOR

•SELECT....(INSERT.......)•ALTER TABLE....ALTER COLUMN •ALTER SEQUENCE

•Can only be used to supply a value for that column

•Values can be used by application for whatever purpose it chooses

Identity columns versus sequences

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

As discussed earlier, to retrieve a value supplied by an identity, that column should be SELECTed or retrieved with the IDENTITY_VAL_LOCAL function. The sequence object used can also be displayed as it is used in an INSERT SQL statement using a SELECT... FROM FINAL TABLE(INSERT …).

The ALTER SEQUENCE statement is used to modify the sequence attributes, whereas the identity column characteristics can be altered using the ALTER TABLE ... ALTER COLUMN statement.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:


Having completed this unit, you should be able to:• Describe the concepts of:





– With the appropriate DELETE rules • Drop REFERENTIAL CONSTRAINTS and their enforcing indexes • Query the appropriate catalog tables for RI details • Describe the relationships that require special handling • Describe what informational constraints are and their use • Discuss identity columns and sequence objects

Having completed this unit, you should be able to:• Describe the concepts of:





– With the appropriate DELETE rules • Drop REFERENTIAL CONSTRAINTS and their enforcing indexes • Query the appropriate catalog tables for RI details • Describe the relationships that require special handling • Describe what informational constraints are and their use • Discuss identity columns and sequence objects

Unit summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 4. Getting data into and out of DB2


This unit describes how to get your data into and out of DB2.



• Describe how DB2 utilities may be executed, monitored, terminated, and restarted

• Run the DB2 LOAD utility and make full use of its many features • Run the CHECK DATA utility to check DB2 table space data for any

violations of referential integrity constraints or table check constraints

• Run the DB2 UNLOAD utility, and make full use of its many features


Accountability: • Machine exercises

References


SC19-2984 DB2 10 for z/OS Utility Guide and Reference



SC18-9855 DB2 Version 9.1 for z/OS Utility Guide and Reference



SC18-7427 DB2 UDB for z/OS Version 8 Utility Guide and Reference


xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 4. Getting data into and out of DB2 4-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe how DB2 utilities may be executed, monitored,

terminated, and restarted• Run the DB2 LOAD utility, and make full use of its many

features• Run the CHECK DATA utility to check DB2 table space data

for any violations of referential integrity constraints or tablecheck constraints


After completing this unit, you should be able to:• Describe how DB2 utilities may be executed, monitored,





Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

4.1. Introduction to DB2 utilities

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-2. Generating utility JCL CV8317.0

Notes:

Generating Utility JCL using DB2I is done in two steps:

• Step 1: Create a sequential data set (or PDS member) with control statements.

• Step 2: Create the Utility JCL in DB2I.

Utility control statements define the function that the utility job performs.

Create the utility statements with the ISPF/PDF edit function.

After the utility control statements are created, save them in a sequential or partitioned data set.

DB2 typically reads utility control statements from the SYSIN data set.


EDIT userid.UTIL.SYSIN(LOAD)Command ===> _________________

****** ***********************000001 LOAD DATA....000002 ...000003000004000005000006000007000008

DB2I PRIMARY OPTION MENU

1 SPUFI2 DCLGEN3 PROGRAM PREPARATION4 PRECOMPILE5 BIND/REBIND/FREE6 RUN7 DB2 COMMANDS8 UTILITIESD DB2I DEFAULTSX EXIT

LOAD DATA... // EXEC DSNUPROC//SYSIN DD *

Control Statements Utility JCL

Generating utility JCL

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-3. DB2 utility panel (1 of 2) CV8317.0

Notes:

When choosing option 8 in DB2I, this is what you will see.

In STATEMENT DATA SET, you must enter the name of the data set (or PDS member) which contains the control statements for the utility.


DB2 UTILITIES SSID: DSN1

===>

Select from the following:

1 FUNCTION ===> EDITJCL (SUBMIT job, EDITJCL, DISPLAY, TERMINATE)

2 JOB ID ===> TSOUD01 (A unique job identifier string)

3 UTILITY ===> LOAD (CHECK DATA, CHECK INDEX, CHECK LOB,

COPY, DIAGNOSE, LOAD, MERGE, MODIFY,

QUIESCE, REBUILD, RECOVER, REORG INDEX,

REORG LOB, REORG TABLESPACE, REPORT,

REPAIR, RUNSTATS, STOSPACE, UNLOAD)

4 STATEMENT DATA SET ===> UTIL.SYSIN(LOAD)

5 RESTART ===> NO (NO, CURRENT, PHASE or PREVIEW)

6 LISTDEF? (YES|NO) ===> NO TEMPLATE? (YES|NO) ===> NO

7 lib == > (BLANK or DB2 Library name).

* The data set names panel will be displayed when required by a utility.

F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE

F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE

DB2 utility panel (1 of 2)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-4. DB2 utility panel (2 of 2) CV8317.0

Notes:

Some utilities require you to fill this panel.


DATA SET NAMES SSID:

===>

Enter data set name for LOAD, REORG TABLESPACE, or UNLOAD:

1 RECDSN ===> TSDEPT.DATA

Enter data set name for LOAD or REORG TABLESPACE:

2 DISCDSN ===> DISCARD

Enter output data sets for local/current site for COPY, MERGECOPY,

LOAD, or REORG TABLESPACE:

3 COPYDSN ===> COPY1

4 COPYDSN2 ===> COPY2

Enter output data sets for recovery site for COPY, LOAD, or REORG

TABLESPACE:

5 RCPYDSN1 ===> COPY3

6 RCPYDSN2 ===> COPY4

Enter output data sets for REORG or UNLOAD

7 PUNCHDSN ===>

F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE

F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE

DB2 utility panel (2 of 2)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-5. DSNUxxx.CNTL CV8317.0

Notes:

This is an example of the JCL DB2I will generate for the LOAD utility.

The procedure invoked is DSNUPROC (see next visual). Note the SYSIN DD card with the control statements from the edited member.

The generated JCL is saved in a data set with the name DSNUxxx.CNTL where xxx depends on the utility being invoked. Table 4-2 lists the data set name for each utility:

Table 4-2: Data set name containing the generated JCL for the utilityUtility name Data set name with generated JCLCHECK INDEX DSNUCHI.CNTLCHECK DATA DSNUCHD.CNTLCOPY DSNUCOP.CNTLLOAD DSNULOA.CNTLMERGECOPY DSNUMER.CNTLMODIFY DSNUMOD.CNTL


//UTIL EXEC DSNUPROC,SYSTEM=DSN1,UID='TSOUD01',UTPROC=''//*//**********************************************//*//* GENERATING JCL FOR THE LOAD UTILITY//* DATE: 08/15/11 TIME: 14:03:50//*//**********************************************//*//DSNUPROC.SORTWK01 DD DSN=TSOUD01.SORTWK01,// DISP=(MOD,DELETE,CATLG),// SPACE=(16384,(20,20),,,ROUND),// UNIT=SYSDA

**

//DSNUPROC.SYSIN DD *LOAD DATA INDDN SYSREC LOG NO RESUME YESEBCDIC CCSID(00000,00000,00000)INTO TABLE "TSOUD01 "."DEPARTMENT "WHEN(00004:00005 = X'000A')( "DEPTNO " POSITION(00007:00009) CHAR(003), "SUPERIOR_DEPTNO " POSITION(00011:00013) CHAR(003)

NULLIF(00010)=X'FF', "MGRNO " POSITION(00015 :00020)CHAR(006)

NULLIF(00014)=X'FF', "NAME " POSITION(00021) VARCHAR)//

DSNUxxx.CNTL

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

QUIESCE DSNUQIE.CNTLREBUILD INDEX DSNUREB.CNTLRECOVER DSNUREC.CNTLREORG INDEX DSNURGI.CNTLREORG TABLESPACE DSNURGT.CNTLREPORT DSNURPT.CNTLRUNSTATS DSNURUN.CNTLSTOSPACE DSNUSTO.CNTLUNLOAD DSNUUNL.CNTL

Table 4-2: Data set name containing the generated JCL for the utilityUtility name Data set name with generated JCL

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-6. DSNUPROC CV8317.0

Notes:

This is the DSNUPROC cataloged procedure.

The DB2I generated job stream will invoke this procedure.

You can see that the program is DSNUTILB. It will read the control statements via the SYSIN DD card. DSNUTILB is called the batch utility driver.

All online utilities will be invoked through this common program.


//DSNUPROC PROC LIB='DSN1010.SDSNLOAD', // SYSTEM=DSN1, // SIZE=0K,UID='',UTPROC='' //* //*******************************************************************************//* *//* PROCEDURE-NAME: DSNUPROC *//* *//* DESCRIPTIVE-NAME: UTILITY PROCEDURE *//* *//* FUNCTION: THIS PROCEDURE INVOKES THE ADMF UTILITIES IN THE *//* BATCH ENVIRONMENT * //*//*******************************************************************************//* //DSNUPROC EXEC PGM=DSNUTILB,REGION=&SIZE, // PARM='&SYSTEM,&UID,&UTPROC' //STEPLIB DD DSN=&LIB,DISP=SHR //* //**********************************************************************//* *//* THE FOLLOWING DEFINE THE UTILITIES' PRINT DATA SETS *//* *//**********************************************************************//* //SYSPRINT DD SYSOUT=* //UTPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //*DSNUPROC PEND REMOVE * FOR USE AS INSTREAM PROCEDURE *

DSNUPROC

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-7. SYSIBM.SYSUTILX CV8317.0

Notes:

SYSIBM.SYSUTILX contains status information about your utility, and this information is updated as the utility progresses.

You can monitor the progress of your utility with the DB2 -DISPLAY UTILITY command.


JOB UTILITY CHECKPOINTUTILID NAME NAME INFORMATION...

Unique Identifier

SYSIBM.SYSUTILX

• A DB2 directory table

• Row inserted at Utility Start• Row updated at Utility Checkpoint

– Utility commit and – Utility Stop

• Row deleted at Utility Termination

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-8. DB2 utility commands CV8317.0

Notes:

When working with utilities, it is handy to be able to find out whether your utility is running ("active") or has encountered some kind of a problem ("stopped").

A utility is identified by a UID (Utility ID).

A utility that is in a stopped state will remain "known" to DB2 as long as it is not "terminated" by a DB2 -TERM command or restarted.

Terminating an active utility may leave restrictive states on the accessed objects.

Warning

Be careful with the -TERM UTIL command.


DSNU105I # DSNUGDIS - USERID = BEDB2MUTILID = CF8CHKDPROCESSING UTILITY STATEMENT 1UTILINIT = CHECKDATPHASE = UTILITY COUNT 0STATUS = ACTIVE

DSN9022I # DSNUGCCC '-DIS UTIL' NORMAL COMPLETION

DSNU166I # DSNUGTER - CHECK DATA UTILITYUTILID = CF8CHKD NOT EXECUTING,CLEANUP COMPLETE

DSN9022I # DSNUGCCC '-TERM UTIL' NORMAL COMPLETION

-DIS UTIL(CF8CHKD)

-TERM UTIL(CF8CHKD)

• “STATUS” can be:– ACTIVE– STOPPED– TERMINATING

• All resources are released

DB2 utility commands

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-9. DB2 utility flow CV8317.0

Notes:

The vertical line on the left of the visual represents a utility — z/OS JOB (1) — which starts and runs to completion in one execution.

The vertical lines on the right represent a utility which starts and for some reason does not complete. The utility is restarted and then completes. This represents one utility, but requires two z/OS jobs.

When a utility is restarted, the utility control cards must be the same as in the original job (that is, DO NOT change the utility control cards before restarting a utility).


Utility #1 Utility #2

z/OSJOB(1)

z/OSJOB(2.1)

z/OSJOB(2.2)

Utility started* Row added to SYSUTILX

(key = utilid)

Utility stopped(REORG UNLOAD PAUSE, errorcondition, operator cancel, and so on)

Utility restarted(key = utilid)

Utility terminated* Row deleted fromSYSUTILX

DB2 utility flow

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

4.2. The LOAD utility

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-10. Loading data into one table CV8317.0

Notes:

The LOAD utility provides a great deal of flexibility in loading data into a table space from a sequential data set. Some of its features are:

• You can selectively load some fields from records in the input data set and ignore others.

• You can specify conditions on the LOAD control statement such that only records meeting certain conditions are loaded into the table space.

• Records that do not meet your conditions or are in error can be written to a discard data set.

• Multiple tables in a table space can be loaded from a single input data set.

• Selected partitions of a partitioned table space can be loaded.

• LOAD can convert many data types and field lengths to match the data types and lengths of the table columns.


LOAD DATAINTO TABLE DEPT(DEPTNO POSITION(7) CHAR(3),DEPTNAME POSITION(10) CHAR(26),MGRNO POSITION(36) CHAR(6), ADMRDEPT POSITION(42) CHAR(3))

CHAR(6)

DEPTNO DEPTNAME MGRNO ADMRDEPTE21 SOFTWARE SUPPORT 031435 E01

TABLEDEPT

0 . . . . 1 . . . . 2 . . . . 3 . . . . 4 . . .

E21 SOFTWARE SUPPORT 031435 E01

POSITION(36)

input field type and lengthinput field location

target column name

Loading data into one table

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• EBCDIC, ASCII, or Unicode data can be loaded into a table space. The LOAD utility can convert as necessary.

• LOAD can replace existing data or add to existing data.

• LOAD can validate data to ensure no RI or table check constraint violations.

The visual shows a simple, first example of the LOAD utility's control statements needed to load data into a single table.

TRUNCATE and STRIP

You can load certain fields that are longer than the length of target column by truncating the data. DB2 truncates the data only when you explicitly specify the TRUNCATE option. You can specify TRUNCATE with the CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY, and VARBINARY data type options. LOAD first applies any CCSID conversion, and then truncates the data. The TRUNCATE option of the LOAD utility truncates string data, and it has a different purpose than the SQL TRUNCATE scalar function.

You can also remove a specified character from the beginning, end, or both ends of the data by specifying the STRIP option. This option is valid only with the CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY, and VARBINARY data type options. If you specify both the TRUNCATE and STRIP options, LOAD performs the strip operation first.

Note

The workshop DB2 for z/OS: How to Deal with Unicode and Multiple CCSID Statements (CV280) provide you in-depth knowledge about how DB2 for z/OS supports the usage of Unicode data.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-11. Data type conversion CV8317.0

Notes:

In some cases, the data types of the input record field and the target column do not match.

In the example, the INTEGER EXTERNAL keyword tells DB2 that the record field contains numeric data formatted as characters.

The LOAD utility will perform the necessary data conversion.


LOAD DATAINTO TABLE DEPT(DEPTNO POSITION(7) CHAR(3),DEPTNAME POSITION(10) CHAR(26),MGRNO POSITION(36) INTEGER EXTERNAL(6),ADMRDEPT POSITION(42) CHAR(3))

Character format

DEPTNO DEPTNAME MGRNO ADMRDEPTE21 SOFTWARE SUPPORT 031435 E01

Defined as INTEGER whenCREATE TABLE was performed

TABLE DEPT

0 . . . . 1 . . . . 2 . . . . 3 . . . . 4 . . .

E21 SOFTWARE SUPPORT 031435 E01

Data type conversion• Suppose that:

– MGRNO was defined as INTEGER in the DEPT table– The input data set is identical to the one in the previous example

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-12. Data conversion CV8317.0

Notes:

LOAD supports data type conversion between numeric data types and between character data types.

If a column is defined as DATE, TIME, or TIMESTAMP, then the data on the sequential input data sets must be in character format with punctuation. For example, with ISO (International Standards Organization) format:

• 2002-02-06 is a valid date • 19.15.30 is a valid time • 2002-02-06-19.15.30.123456 is a valid timestamp

The input fields must be defined to the LOAD utility as DATE EXTERNAL, TIME EXTERNAL, and TIMESTAMP EXTERNAL.

If NOT NULL WITH DEFAULT is specified, and the date or time is not provided in the input data set, then the date or time at the start of the LOAD utility is used for all rows loaded without a date or time. This may or may not be what you want. If it is not, then the input data set must have a valid date or time.


Data conversion

DYYYYYDECFLOATYDYYYYFLOATYYDYYYDECIMALYYYDYYBIGINTYYYYDYINTEGERYYYYYDSMALLINT

DECFLOATFLOATDECIMALBIGINTINTEGERSMALLINT

DYNNNNVARBINARYYDNNNNBINARYNNDYY*Y*VARGRAPHICNNYDY*Y*GRAPHICYYY*Y*DYVARCHARYYY*Y*YDCHAR

VARBINARYBINARYVARGRAPHICGRAPHICVARCHARCHAR

DYYTIMESTAMPEXTERNAL

NDNTIME EXTERNALNNDDATE EXTERNAL

TIMESTAMPTIMEDATE

• Character Data Conversion

• Time Data Conversion

• Numeric Data Conversion

InputData

Types

InputData

Types

InputData

Types

Output Data Types

Output Data Types

Output Data Types

*=Conversionapplies when

either the inputdata or the targettable is Unicode

D=Defaults usedwhen you do notspecify the input

data type in afield spec of the

INTO TABLEstatement

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-13. Loading NULL values CV8317.0

Notes:

Column allows NULLs

In the visual, '??????' in the input data is used to indicate that a value is unknown. The NULLIF (36:41) = '??????' parameter of the MGRNO column causes X'FF' to be loaded in the one-byte null flag prefixing the MGRNO column. This indicates in DB2 that the value is unknown.

NOT NULL WITH DEFAULT

With this table definition...

CREATE TABLE TAB1 (COL1 INTEGER NOT NULL WITH DEFAULT, ............ ............


LOAD DATAINTO TABLE DEPT(DEPTNO POSITION(7:9) CHAR,DEPTNAME POSITION(10:35) CHAR,MGRNO POSITION(36:41) CHAR

NULLIF (36:41) = '??????',ADMRDEPT POSITION(42:44) CHAR)

DEPTNO DEPTNAME MGRNO ADMRDEPTE21 SOFTWARE SUPPORT ------ E01

The MGRNO columnallows NULLs

TABLE DEPT

0 . . . . 1 . . . . 2 . . . . 3 . . . . 4 . . .

E21 SOFTWARE SUPPORT ?????? E01

Loading NULL values

• Setting columns to NULLs

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

the DEFAULTIF parameter can be used with the LOAD statement as shown below:

LOAD DATA INTO TABLE TAB1 (COL1 POSITION (1:4) INTEGER DEFAULTIF (1:4) = -1, ................................ ................................

The LOAD utility will load zero in COL1 if positions 1-4 in the input data set contain -1 in binary.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-14. Loading multiple tables in a table space CV8317.0

Notes:

Multiple INTO TABLE specs and WHEN clauses

The WHEN clause tells the utility which records in the input data set are to be loaded. Input records that satisfy the WHEN condition for a particular table are loaded into that table.

Input records that do not satisfy any WHEN clause of any INTO TABLE statement are written to the discard data set, if one exists.

Loading VARCHAR columns

Column SHTITLE is defined in the table COURSE as VARCHAR(60).

In the visual, the input data for SHTITLE begins in position 7 of the input record. It contains a 2-byte length field containing X'0037', and this is immediately followed by 55 input characters for SHTITLE.

SHTITLE Is loaded with no trailing blanks.


LOAD DATA INDDN SYSREC

RESUME NO

DISCARDDN SYSDISC

CONTINUEIF(80)='X'

INTO TABLE COURSE

WHEN(1)='C'

(COURSENO POSITION(2) CHAR(5),

SHTITLE POSITION(7) VARCHAR,

DESCRIPT POSITION(*) VARCHAR,

DURATION POSITION(*) DECIMAL EXTERNAL,

PREREQ1 POSITION(*) CHAR(4) NULLIF(PREREQ1=' '),

PREREQ2 POSITION(*) CHAR(4) NULLIF(PREREQ2=' '),

PREREQ3 POSITION(*) CHAR(4) NULLIF(PREREQ3=' '))

INTO TABLE OFFERING

WHEN(1)='O'

(COURSENO POSITION(2) CHAR(5),

WEEKNO POSITION(7) DECIMAL EXTERNAL(2),

DATESUFF POSITION(9) CHAR(1),

STRTDATE POSITION(10) DATE EXTERNAL(10),

ENDDATE POSITION(20) DATE EXTERNAL(10),

ROOMNO POSITION(30) DECIMAL EXTERNAL(3))

CCV831 DB2 10 FOR Z/OS DATABASE ADMINISTRATION WORKSHOP PART 1 THIS CO

CCEFFF03CCF4FF4CDD4E6DE4CCECCCEC4CCDCDCEEDCECDD4EDDDECDD4DCDE4F04ECCE4CD

335831074220100669091620413121250144959239139650669228670719301013892036

URSE PRX

EDEC4DDE

49250797

OCV83104018.10.201122.10.2011201

DCEFFFFFFFF4FF4FFFFFF4FF4FFFFFFF

63583104018B10B201122B10B2011201

OVIDES BASIC SKILLS FOR DB2 DATABASE ADMINISTRATION5.0CE030CE120

DECCCE4CCECC4EDCDDE4CDD4CCF4CCECCCEC4CCDCDCEEDCECDDF4FCCFFFCCFFF4

6594520212930229332066904220413121250144959239139655B035030351200

• Two Input Records to be Concatenated for COURSE

• Input Record for OFFERING

Loading multiple tables in a table space• LOAD Utility Control Statement

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The LOAD control statement uses RELATIVE POSITIONING (indicated by POSITION(*)) rather than ABSOLUTE POSITIONING to describe the locations of input fields that come after the first VARCHAR input.

Loading BINARY and VARBINARY columns

BINARY fields are assumed to be of fixed maximum length. VARBINARY fields must contain a valid 2-byte binary length field preceding the data.

NULLIF

PREREQ3 will be set to NULL.

CONTINUEIF

Allows you to treat each input record as a portion of a table row.

In the visual, two input records are concatenated into one row for COURSE.

RESUME NO

See the next visual.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-15. LOAD RESUME, REPLACE, and REUSE at TS level CV8317.0

Notes:

When you specify RESUME or REPLACE as part of the LOAD spec as shown in the visual, LOAD will serialize at the table space level.

RESUME NO

This causes the LOAD utility to write into an empty table space.

This is the default.

If any data is present in the table space, the utility does not load any rows.

RESUME YES

This causes the LOAD utility to add new rows at the end of the table space.

This is a good choice for adding rows compared to using SQL INSERT. In general, the LOAD utility has performance advantages.


• Initial load:– Empty table space

• This is the default

• Additional load:– Non-empty table space

• To load another table in the same table space

• To add rows to a non-empty table

LOAD DATAREPLACEINTO TABLE EMP

RESUME NO RESUME YES REPLACE

LOAD DATARESUME NOINTO TABLE EMP

LOAD DATARESUME YESINTO TABLE EMP

• Replace old data:– Resets a table space

and related indexes to empty before loading

– Easy way to refresh data

Start of LOAD

Start of LOAD

Start of LOADTable space Table space Table space

Existing Data

Existing Data

LOADRESUME NO

RESUME YES

REPLACEINTO-TABLE spec

REUSE

LOAD RESUME, REPLACE, and REUSE at TS level

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

REPLACE

DB2 will reset to empty the table space and all its indexes.

For DB2-managed data sets, the data sets are deleted and redefined.

The data in all tables is lost when you LOAD REPLACE a single table in a multi-tabletable space.

LOAD REPLACE of a parent table sets dependent tables in CHKP.

Note

The first time you run a LOAD REPLACE, DB2 automatically converts the table space from the old basic format to the new reordered format. With reordered row format, DB2 no longer stores the length of varying length columns, and the data can look significantly different within the row/page.

REPLACE with REUSE

LOAD will reset and reuse all existing DB2-managed data sets. That is, the data sets are not deleted and redefined.

RESUME YES with SHRLEVEL CHANGE

It causes the LOAD utility to add new rows using processing similar to SQL INSERT.

It inserts rows according to the clustering index, provided that sufficient free space is available.

LOG YES is required.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-16. LOAD RESUME, REPLACE, and REUSE at partition level CV8317.0

Notes:

RESUME, REPLACE and REUSE can be used when loading individual partitions. In this case, these specifications must come after the INTO TABLE clause

LOAD will serialize at the partition level. That is, other partitions can be processed concurrently.

REPLACE with REUSE resets and reuses existing DB2-managed data sets for the partitions. That is, no delete / redefine occurs.

© Copyright IBM Corporation 2011© Copyright IBM Corporation 2007

• RESUME, REPLACE and REUSE– Can be used when loading

individual partitions– Must come after the INTO TABLE

• REPLACE with REUSE– Resets and reuses existing DB2-

managed data sets for the partitions

• That is, no delete / redefine

• LOAD will serialize at the partition level– Other partitions can be processed

concurrently

INTO-TABLE table-nameRESUME NO

RESUME YES

REPLACEPART integer

REUSE

ExampleLOAD DATA CONTINUEIF(72:72)='X'

INTO TABLE DSN8810.EMP PART 1 REPLACE WHEN(1)='0'

(EMPNO POSITION(1:6) CHAR(6),FIRSTNME POSITION(7:18) CHAR(12),

.

.

. ) INTO TABLE DSN8810.EMP PART 2RESUME YES WHEN(1)='1'

(EMPNO POSITION(1:6) CHAR(6),FIRSTNME POSITION(7:18) CHAR(12),..

)

LOAD RESUME, REPLACE, and REUSE at partition level

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-17. Other LOAD options CV8317.0

Notes:

ENFORCE CONSTRAINTS

The LOAD utility enforces RI and table check constraints.


ENFORCE NO

The use of ENFORCE NO always causes CHKP to be set on, because the LOAD utility does not check for any constraint violations, and some may exist.

It is necessary to clear CHKP in order to SELECT or UPDATE rows. One way to do this is with the CHECK DATA utility covered in the next topic.

ENFORCE NO is one solution to the problem of loading tables in a referential cycle. You can load all the tables in the referential structure with ENFORCE NO. This will result in all the table spaces being put into CHKP, which you can clear with CHECK DATA...DELETE YES.


Other LOAD options

• LOG NO LOADs faster but impact on RECOVERY

• Allow or suppress enforcement of the table check orreferential constraints while LOADing. ENFORCE NO sets the CHECK PENDING state

• LOAD stops after 25 errors

LOAD DATAENFORCE CONSTRAINTS/NO

LOAD DATALOG YES/NO

LOAD DATADISCARDS 25

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

LOG YES


LOG NO

This reduces the number of bytes that must be logged.

The time and resources required to follow the LOAD with an image copy are almost always less than the cost of logging the data as it is loaded.

Copy pending (COPY) is set for the table space or partition when a table space is loaded with LOG NO. SQL INSERTS, UPDATES, and DELETES cannot be executed, and the table space cannot be recovered. SQL SELECTs are still permitted.

You can remove the copy pending restrictive state in one of these ways:

• Following the LOAD take a full image copy with SHRLEVEL REFERENCE.

• REPAIR....NOCOPYPEND

• -START DB(........) SPACENAM(........) ACCESS(FORCE)

When adding rows to a table space, use LOAD....RESUME YES...LOG NO, and follow it with a full image copy SHRLEVEL REFERENCE.

When replacing rows in a table space, use LOAD....REPLACE...LOG NO, and take an inline image copy.

DISCARDS n

Records that cannot be loaded are written to the discard data set.

The DISCARDS parameter sets a limit for the number of records to be discarded.

Use the DISCARDS parameter to avoid writing all input records to the discard data set because of, say, a typing error on the LOAD statement.

Discarding all records can take several times longer than loading the data.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-18. LOAD phases CV8317.0

Notes:

LOAD RESUME NO

• Message DSNU345I reports keys which duplicate another previously loaded, showing the input record number and RID of both.

• All rows with the duplicating key values are removed from the target table.

• A summary report shows the input records rejected, their error type, and their position in the input data set.

LOAD RESUME YES

• DSNU344I reports rows with a key duplicating an existing key of a row in the table. The invalid input row is then deleted with a message, but NOT THE ROW ALREADY EXISTING IN THE TABLE.

• These deleted rows can optionally be placed in a discard data set.


SORT

UTILINIT

ENFORCE

ErrorSummary

REPORT

Table Space

Sortout

Index

Sysdisc

SequentialData Set

DISCARD

Sysin

INDEXVALViolations Deleted

Discarded Rows

Sysut1

Syserr Sysmap

BUILD Unique IXErrors

RELOAD

LoadErrors Row

Map

LOAD phases

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-19. DISCARD file CV8317.0

Notes:

A number of conditions can cause records to be discarded.

• During RELOAD phase

- WHEN condition not satisfied

- Conversion errors

- Table check constraint violations

• During INDEXVAL phase

- Duplicate key in unique index

• During ENFORCE phase

- RI constraint violation


Referentialconstraint violation

WHEN conditionnot satisfied

Duplicate keyin unique index

Conversionerror

Table checkconstraint violation

DISCARDFILE

DISCARD file

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-20. Unique index violations CV8317.0

Notes:


INPUTKEYS

TABLE ROWSLOADED

INDEXENTRIES

BA

CDB

A

CD

A

CD

B

B

OPTIONAL DISCARD

Unique index violations

• RESULTS OF LOAD RESUME NO– Table and Index both loaded– Duplicate key rows not loaded

• Error message indicates record number of input record

• USER CORRECTION– Correct and reload unique index violation records by either:

• SQL INSERT – For correct positioning of the records, or:

• LOAD RESUME YES – Which appends to the end of the table space

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-21. LOAD considerations CV8317.0

Notes:

The LOAD utility will LOAD data coming from a sequential data set into one or more tables in the same table space. Since the data is coming from a non-DB2 source, all integrity checks have to be performed:

• Entity integrity • Referential integrity • Check integrity

Check integrity is accomplished during the initial load of the data; other integrity checks are done after the data is loaded.

By the time LOAD gets to the ENFORCE phase, all the data has been loaded (and the indexes built).

In case LOAD is interrupted, the data and indexes will be left in "restrictive states", such as Check Pending and Recover Pending (see later).

LOAD errors include conversion errors and table check constraint errors. If LOAD errors occur, the utility abends unless a DISCARD data set is provided.


LOAD considerations

• Pre-process input to remove errors– Duplicate keys – Check constraint violations – Referential constraint violations

• Sort input data into clustering sequence by table – Load does not sort data

• Avoid data conversions• Create all your indexes before loading your data• For LOAD REPLACE use:

– LOG NO to avoid excessive log I/O, and– Take an inline image copy

• Otherwise, use LOG NO and then take a full image copy• Load parent tables before dependent tables• Specify ENFORCE CONSTRAINTS (or let default)

– Unless you have self-referencing tables and you do not load the whole data at once, or you have cycles with non-null foreign keys

• Run RUNSTATS utility afterwards or use inline statistics• Rebind affected plans/packages

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-22. DB2 family cross-loader function CV8317.0

Notes:

You can load the output of any SQL SELECT statement directly into a DB2 for z/OS table using the LOAD utility.

Since the SELECT can access any DRDA server, the data source can be any member of the DB2 family, Information Integrator, or any other vendor that supports DRDA server capabilities.

This function of the LOAD utility is referred to as the DB2 Family Cross Loader Function.

EXEC SQL DECLARE C1 CURSOR FOR SELECT * FROM HONOLULU.SCHEMA1.EMP WHERE SALARY > 10000 ENDEXEC LOAD DATA INCURSOR C1 REPLACE INTO TABLE MYEMP


DB2 familyOracleSybaseInformixIMSVSAMSQL ServerNCR Teradata

SELECTLOADutility

Dataconversion

Local DB2,DRDA, or

InformationIntegrator

DB2 for z/OS

DB2 family cross-loader function

EXEC SQL DECLARE C1 CURSOR FOR SELECT * FROM HONOLULU.SCHEMA1.EMP WHERE SALARY > 10000

ENDEXECLOAD DATA INCURSOR C1 REPLACEINTO TABLE MYEMP

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-23. LOAD - delimited input CV8317.0

Notes:

The control statement specifies that data in delimited format is to be loaded into the specified columns (FILENO, DATE1, and TIME1) in table DELT. The FORMAT DELIMITED option indicates that the data is in delimited format.

The COLDEL option indicates that the column delimiter is a comma (,). The CHARDEL option indicates that the character string delimiter is a double quotation mark ("). The DECPT option indicates that the decimal point character is a period (.). You are not required to explicitly specify these particular characters, because they are all defaults.

Note

All numeric fields are in EXTERNAL format for LOAD. Field specifications of INTEGER or SMALLINT are treated as if they are INTEGER EXTERNAL; specifications of DECIMAL, DECIMAL PACKED, or DECIMAL ZONED are treated as DECIMAL EXTERNAL; and specifications of FLOAT, REAL, or DOUBLE are treated as FLOAT EXTERNAL.


LOAD - delimited inputCREATE DATABASE DELDB;CREATE TABLESPACE DELTS IN DELDB;CREATE TABLE DELT( FILENO CHAR(3),

NAME VARCHAR(30),DATE1 DATE EXTERNAL,TIME1 TIME EXTERNAL)

IN DELDB.DELTS;LOAD DATAFORMAT DELIMITED COLDEL ’,’ CHARDEL ’"’ DECPT ’.’INTO TABLE DELT(FILENO CHAR,NAME VARCHAR,DATE1 DATE EXTERNAL,TIME1 TIME EXTERNAL)"001", “KUMAR”,2000-02-16, 00.00.00"002", “KASCHTA”,2001-04-17, 06.30.00"003", “HUTH”,2002-06-18, 12.30.59"004", “WHITLARK”,1991-08-19, 18.59.30"005", “BAUMGARTNER”,2000-12-20

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

4.3. Ensuring referential and check constraints

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-24. Check pending (CHKP) CV8317.0

Notes:

What is check pending (CHKP)?

CHECK PENDING is a DB2 restrictive state that is set on if there is a potential violation of a constraint.

What is the purpose of check pending?

The purpose is to ensure the integrity of DB2 data.

What does it apply to?

Check Pending applies to:

• Dependent table spaces of an RI structure • Table check constraints


Check pending (CHKP)

• What is Check Pending (CHKP)?

• What is the purpose of Check Pending?

• What does it apply to?

• What is permitted or not permitted?

• What causes Check Pending?

• How can Check Pending be reset?

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

What is permitted/not permitted?

• No SELECT, INSERT, UPDATE, or DELETE - But DROP and ALTER allowed

• No update of PK when FK table is in CHKP • No COPY or REORG

- But CHECK DATA, LOAD REPLACE, and RECOVER allowed

What causes check pending?

CHKP set on by:

• LOAD of dependent table with ENFORCE NO • LOAD REPLACE of parent table in its own table space

- Applies to dependents, not descendents • Adding FK or table check constraint to populated table • Running CHECK DATA...DELETE NO and violations are detected

How can check pending be reset?

Some of the ways Check Pending can be reset are:

• CHECK DATA...DELETE YES. • CHECK DATA...DELETE NO and no violating rows are found. • -START DB(...) SPACENAM(...) ACCESS FORCE

- This resets all restrictive states on the table space. • REPAIR.....NOCHECKPEND

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-25. Using the CHECK DATA utility CV8317.0

Notes:

1. CHECK DATA TABLESPACE DB1.TS1

- Always produces a report with details of each violation:

• RID of invalid row. This cross-references to RID in exception table.

• Name of table

• Constraint name


FOR EXCEPTION IN UID1.TBL1 USE UID1.E_TBL1 IN UID1.TBL2 USE UID1.E_TBL2DELETE NO

- Invalid rows can optionally be copied to a user-specified exception table.

- Option is invoked by specifying FOR EXCEPTION.

- All dependent (not descendent) tables must be specified with the IN keyword.


Using the CHECK DATA utility1. CHECK DATA TABLESPACE DB1.TS1

2. CHECK DATA TABLESPACE DB1.TS1FOR EXCEPTION IN UID1.TBL1 USE UID1.E_TBL1

IN UID1.TBL2 USE UID1.E_TBL2DELETE NO

3. CHECK DATA TABLESPACE DB1.TS1FOR EXCEPTION IN UID1.TBL1 USE UID1.E_TBL1

IN UID1.TBL2 USE UID1.E_TBL2IN UID1.TBL3 USE UID1.E_TBL3IN UID1.TBL4 USE UID1.E_TBL4

DELETE YES

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

- All dependent (not descendent) tables must be specified with the USE keyword.

Note

If CHECK DATA specifies DELETE NO and SHRLEVEL REFERENCE, and constraint violations are detected, what is done by the utility depends on the DB2 version you use.

Prior to DB2 10:

CHECK DATA utility places the table space in the CHECK-pending status.

DB2 10:

DSNZPARM CHECK_SETCHKP setting determines the utility action as follows:

• If CHECK_SETCHKP is set to NO (which is the default), then CHECK DATA utility does not place the table space in check-pending status.

• If CHECK_SETCHKP is set to YES, then CHECK DATA utility places the table space in check-pending status.


FOR EXCEPTION IN UID1.TBL1 USE UID1.E_TBL1 IN UID1.TBL2 USE UID1.E_TBL2 IN UID1.TBL3 USE UID1.E_TBL3 IN UID1.TBL4 USE UID1.E_TBL4DELETE YES

- Invalid rows can optionally be deleted from the dependent table after they have been copied to the exception table.

- Option is invoked by DELETE YES.

- FOR EXCEPTION must include all dependent and descendent tables.

- All dependents and descendants of deleted row copied to respective exception tables and deleted.

- CHECK PENDING is set off.

SCOPE ALL causes all rows to be checked.

SCOPE PENDING causes only rows in dependent table spaces added by the LOAD utility since the last invocation of CHECK DATA to be checked. This is the default.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-26. CHECK DATA - exception tables CV8317.0

Notes:

An exception table is a user-created table that mimics the definition of a table being checked.

• The first n columns of the exception table must have exactly the same name and description as the corresponding column of the table being checked.

• The nth + 1 column is optional. If you define it, CHECK DATA provides the RIDs of the invalid rows of the table being checked. You can use the RIDs to match the utility output with rows in the exception table. The RID column must be defined as CHAR(5) for LARGE table spaces, but may be either CHAR(4) or (5) for other table spaces,

• The nth + 2 column is optional. If it exists it must be defined as a TIMESTAMP, and the starting time of the CHECK utility will be placed in it. It can be used to identify different invocations of the CHECK utility.

Some considerations regarding exception tables are:

• The exception table cannot have more than 750 columns.

• The names of the CHAR(5) and TIMESTAMP columns do not matter.


CHECK DATA - exception tables

• Exception table requires same column names and descriptions as table being checked

1. Create an exception table with same columnsCREATE TABLE XCPTA LIKE DATATABA

IN DATABASE PERSDB2. Add column for RID of row (optional)

ALTER TABLE XCPTAADD ANYNM1 CHAR(5)

3. Add column for utility start time (optional)ALTER TABLE XCPTA

ADD ANYNM2 TIMESTAMP

• If DELETE YES is specified, exception tables are required for the tables being checked, the dependent tables, and the descendent tables

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• Any other columns of the exception table that are not in the dependent table will be ignored, but must be nullable or NOT NULL WITH DEFAULT.

• An exception table can reside in any table space, but should not have a unique index or any other constraint that could cause errors at insert.

• An exception table can be easily defined using the CREATE TABLE statement with the LIKE operand.

• The ALTER TABLE ADD statement can be used to add the additional columns.

• The CHECK utility will NOT ensure that the exception tables are empty at the beginning of the processing.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-27. CHECK DATA - phases CV8317.0

Notes:

The CHECK DATA utility checks table spaces for referential integrity or table check constraint violations.

When a table space is in the CHECK PENDING restrictive state, the CHECK DATA utility should be run to reset the status and do the necessary cleanup.

An Index on the foreign key will speed up this utility.


DB2

DescendentTABLES

REPORTCK

SCANTAB

UTILINITJCL

SYSIN

DB2

DependentFK IX

SORTOUT

DB2

EXCEPTIONTABLES

SYSERR

DB2

ParentPK

IX

DB2

TABLE

Repeat foreach table SORT

ORCHECKDAT

SummaryReport

SYSUT1

CHECK DATA - phases

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-28. CHECK DATA - example CV8317.0

Notes:

CHECK DATA uses index-only access when an index is available and no sort is required.

However, if there is no index available on a FK, or the index contains additional columns that are not part of the FK, the FK key values are extracted and sorted before checking the constraints.

• Was an index defined on the foreign key?

• Was DELETE YES specified for this run?


CHECK DATA - example

CHECK DATA TABLESPACE INVDB11.INVSINL

- OUTPUT START FOR UTILITY, UTILID = CF8CHKD- CHECK DATA TABLESPACE INVDB11.INVSINL- TABLESPACE ‘INVDB11.INVSINL’ HAS NO CHECK PENDING FOR SCOPE- CHECKING TABLE INVDB111.T_INVOICE_LINE- SORT PHASE STATISTICS -NUMBER OF RECORDS=4ELAPSED TIME=00:00:02

- SORT PHASE STATISTICS -NUMBER OF RECORDS=1ELAPSED TIME=00:00:02

- ROW (RID=X’00000202’) HAS NO PARENT FOR INVDB111.T_INVOICE_LINE.INVRINL3- CHECK TABLE INVDB111.T_INVOICE_LINE COMPLETE, ELAPSED TIME=00:00:03- TABLESPACE INVDB11.INVSINL IS IN CHECK PENDING- CHECK DATA COMPLETE, ELAPSED TIME=00:00:06- UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4SORT TECHNIQUE SELECTED

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

4.4. The UNLOAD utility

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-29. DB2 UNLOAD utility CV8317.0

Notes:

You can unload data from:

1. An entire table space 2. A list of table spaces 3. Multiple table spaces with one run of UNLOAD 4. Specific partitions using parallelism 5. Certain tables only 6. Certain rows only 7. Certain columns only

Data is unloaded into BSAM sequential data sets in external format.

UNLOAD has a sampling capability so that you can reduce the number of rows to be unloaded to fill, say, a test table. You can also limit the number of rows to be unloaded.

UNLOAD has a number of conversion options so that you can convert character data:

• One CCSID to another. • EBCDIC, ASCII, Unicode


PartitionedTable space

DB2 UNLOAD

Data Conversion Row Sampling

LOAD Utility Statement

Table space Full

Image Copy IncrementalImage Copy

UNLOAD Data

DB2 UNLOAD utility

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

You can:

• Reorder columns compared to the order in the table • Specify the position of columns in the unload data set

You can unload from copies created by:

• COPY - Full image copy - Incremental image copy - Copy of a partition - Copy of a data set of a nonpartitioned table space.

• COPYTOCOPY • MERGECOPY • Inline full image copies from LOAD or REORG • DSN1COPY

UNLOAD can unload data in delimited format.

UNLOAD can also generate LOAD utility control statements.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-30. Table space input specification CV8317.0

Notes:

An example of the UNLOAD utility control statement is shown on the visual.

The table spaces from which the data is to be unloaded can be selected by specifying a table space name for the TABLESPACE keyword.

If you specify the name of a partitioned table space, then you can also specify an individual partition or a range of partitions.

For a selected table space, rows from the entire table space, selected partitions, or selected tables within the table space can be unloaded. Specific columns can also be selected.

Specific tables can be selected for unloading using one or more FROM TABLE specification:

If no FROM TABLE specification is given, the rows from all the tables in the table space will be unloaded.

If one or more FROM TABLE specification is given, only the rows belonging to the specified tables are unloaded.


UNLOAD TABLESPACE DBDAVID.TS1 ASCII NOPAD

FROM TABLE DAVID.EMP

HEADER CONST 'EMP'

SAMPLE 50

LIMIT 4000

(EMPNO, LASTNAME, SALARY DECIMAL EXTERNAL)

WHEN (WORKDEPT = 'D11' AND SALARY > 25000)

The column order specifiesthe field order in the output records

Maximum number of rows which will be unloaded from table EMP

Variable length data will not be padded in the output records

Header field which will prefix the output records

Data will be unloaded in ASCII

Table space input specification

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Within a FROM TABLE specification, you can also specify which columns and rows should be unloaded. When a column (field specification) list is given, only the listed columns are unloaded, and the columns are unloaded in the listed order. If the column list is omitted, all the columns in the row are unloaded, and the columns are unloaded in the order in which the columns are defined in the table. The rows to be unloaded from a table can be qualified using the WHEN clause. The format of the WHEN clause is similar to the format of the WHERE clause in an SQL statement.

In addition to row selection using the WHEN clause, the UNLOAD utility also provides a row sampling capability. The following sampling criteria can be specified:

The percentage of rows to be unloaded from a table (the SAMPLE option). The sampling is applied to the rows that qualify the WHEN conditions, if specified.

The maximum number of rows to be unloaded from a table (the LIMIT option). If a limit is specified, then as soon as this limit is reached, the UNLOAD utility stops unloading any further rows from the table.

SAMPLE and LIMIT are independent options. If both options are specified, the limit is applied to the sampled rows. For example, let's say you specify SAMPLE 50 LIMIT 4000. If there are approximately 10,000 rows in the table, and approximately 5,000 rows qualify the WHEN conditions specified, then the UNLOAD utility unloads approximately 2,500 rows from the table, but no more than 4,000 rows.

The HEADER option is used to specify a header field at the beginning of the output records for a table. This field can then be used to associate an output record with the table from which it was unloaded. By default, the UNLOAD utility prefixes each output record with a 2-byte binary field which contains the table OBID. HEADER NONE specifies that a header field should not be created.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-31. Example of the unloaded records CV8317.0

Notes:

The visual shows an example of the output records unloaded by the UNLOAD utility control statement shown on the previous visual.


EMP000060@@SHEARER# 32250.00

EMP000150@@BECKHAM# 25280.00

EMP000200@@SCHOLES# 27740.00

EMP000220@@OWEN# 29840.00

EMP200220@@HALL# 29840.00

2-byte length field for varchar column LASTNAME

NULL indicator byte for nullable column SALARY

record header character string

Example of the unloaded records

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-32. Output field specification CV8317.0

Notes:

For each selected column you can use the POSITION option to specify where the column's output field should start in the output record. Of course, if explicit (byte) start positions are specified for certain columns, then the values specified must be in ascending order as they appear in the column selection list.

An output field can have a different data type from the one defined for the column as long as the data types are compatible. For example, if the column data type is CHAR, then the output field data type can be CHAR, VARCHAR, or CLOB. The output field data type is reflected in the generated LOAD statement.


Note: You can also specify "field-name CONSTANT 'string' " for a table to request creation of a fixed-length output field which contains the specified string. In this case, "field-name" cannot be the same as one of the table's column names.

Output field specification

• For each column selected, you can optionally specify the following attributes for the column's corresponding output field:– Start position– Data type (for example, DECIMAL EXTERNAL)– Length– TRUNCATE - used to truncate column values when they

are longer than the output field length specified– STRIP - used to remove leading and/or trailing blanks

(or the specified character) from column values

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-33. UNLOAD - delimited output CV8317.0

Notes:

UNLOAD utility can produce a delimited file when unloading the data and simplifies the process of moving or migrating data out of DB2 for z/OS.

When delimited is specified for UNLOAD, the NOPAD option is in effect for variable length column output, even if NOPAD is not specified. Therefore, trailing padded blanks are not used for variable length columns. For example, if a VARCHAR (100) field contains the data ABC in it, UNLOAD DELIMITED unloads it as "ABC".

For fixed length columns, the normal padding rules applies. For example, a CHAR(100) column containing ABC, UNLOAD DELIMITED unloads as "ABC <97 blanks>" (with 97 blanks actually following ABC).

The UNLOAD utility generates the delimited LOAD utility control statement in the data set specified in PUNCHDDN.


Optional keywords

POSITION(*) keywords andchar field lengthsoptional

No trailing blanks for VARCHAR

Note that field lists are optional for LOAD / UNLOAD, and are primarily used for selecting a subset of columns or selecting columns in a different order

UNLOAD - delimited output

UNLOAD TABLESPACE DELDB.DELTSDELIMITED CHARDEL '#' COLDEL ';' DECPT '.'PUNCHDDN SYSPUNCHUNLDDN SYSREC EBCDICFROM TABLE DELT (FILENO POSITION(*) CHAR(3), NAME POSITION(*) VARCHAR(30),DATE1 POSITION(*) DATE EXTERNAL,TIME1 POSITION(*) TIME EXTERNAL)

Unloaded data looks like:

#001#;#KUMAR#;02/16/2000;00:00 AM #002#;#KASCHTA#;04/17/2001;06:30 AM #003#;#HUTH#;06/18/2002;12:30 PM #004#;#WHITLARK#;08/19/1991;06:59 PM #005#;#BAUMGARTNER#;12/20/2000;12:00 AM

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-34. Error handling CV8317.0

Notes:

The MAXERR keyword specifies the number of records in error at which the unloading process should terminate. When the error count reaches the specified number, the UNLOAD utility issues message DSNU1219 and terminates with return code 8.

The default is MAXERR 1, which means that the UNLOAD utility terminates when it encounters the first error. If zero or a negative number is specified, then the check on the error count will not be performed (utility execution continues regardless of the number of records in error).

If multiple table spaces are being processed, the number of records in error is counted separately for each table space.

If the input data contains rows belonging to dropped tables, then these rows will be ignored by the UNLOAD utility and the error count will not be incremented.

If less than MAXERR errors are encountered, then the final return code will be 4.


UNLOAD ... MAXERR n ...

Error handling

• Some of the reasons why a row cannot be unloaded:

– The output field is too small for a column value and the TRUNCATE option was not specified (or was not available)

– The row is compressed but no dictionary exists in the input image copy data sets

• UNLOAD terminates (RC=8) when "n" records are found to be in error

• The default is MAXERR 1– UNLOAD terminates when it encounters the first record in error

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 4-35. Considerations CV8317.0

Notes:

The UNLOAD utility does not support unloading data from index spaces or concurrent image copy data sets.

The UNLOAD utility does not support the specification of a view name in the FROM TABLE clause. To overcome this restriction, you can use the sample program DSNTIAUL. This is an SQL program. You might choose to use it, for example, when you want to unload data with the use of some SQL functions or when you want to unload only a few rows specified with a WHERE condition and where the access path is supported by an index.


Considerations

• The UNLOAD utility does not support:

– Index spaces– Views– Concurrent image copies– FlashCopy image copies– Directory table spaces

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 4-36. Checkpoint quiz (1 of 3) CV8317.0

Notes:

This is an optional quiz. Use the student notes and the Utility Guide to research your answers. Write your answers here:

1.

2.

3.

4.


Checkpoint quiz (1 of 3)

1. What would happen if the LOAD utility encountered duplicate keys for a table on which a unique index had been created?

2. What types of error would cause input records to be written to a discard data set?

3. Incorrect specification of input field position / length could cause the LOAD utility to do a lot of work to no avail. How could you prevent this?

4. If the LOAD failed before completion, what could you do after correcting the cause of the failure?

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:

Write down your answers here:

5.

6.

7.



5. It may sometimes be necessary to LOAD new data and overwrite all the original data. How would you do this at the:

– TS level– Partition level

6. What effect does a clustering index have on the way in which the data is loaded?

7. What recommendations would you suggest with regard to logging during the LOAD? Would this have any effect on the LOAD utility restart capabilities?

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:

Write down your answers here:

8.


T1 T2 T3

Tables T1, T2, T3 contain data

How would you...

• Replace the data in table T2 by the contents of the sequential data set?

____________________________________

• Add data to table T2 from a sequential data set?

____________________________________


8.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:


Having completed this unit, you should be able to:• Describe how DB2 utilities may be executed, monitored,





Having completed this unit, you should be able to:• Describe how DB2 utilities may be executed, monitored,





Unit summary

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 5. Keeping your DB2 data in good shape


This unit describes how to keep your data in good shape.



• Describe and interpret the statistics collected by RUNSTATS and real-time statistics

• Run RUNSTATS with an appropriately chosen set of options • Describe how DB2 collects statistics in real time • Describe why it is necessary to periodically REORG your

table spaces and indexes • Run REORG with an appropriately chosen set of options


Accountability:


References


SC19-2978 DB2 10 for z/OS Managing Performance




SC18-9851 DB2 Version 9.1 for z/OS Performance Monitoring and Tuning Guide






xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 5. Keeping your DB2 data in good shape 5-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe and interpret the statistics collected by RUNSTATS

and real-time statistics • Run RUNSTATS with an appropriately chosen set of options• Describe how DB2 collects statistics in real time• Describe why it is necessary to periodically REORG your

table spaces and index spaces• Run REORG with an appropriately chosen set of options

After completing this unit, you should be able to:• Describe and interpret the statistics collected by RUNSTATS



Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

5.1. RUNSTATS and real-time statistics

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-2. RUNSTATS CV8317.0

Notes:

The DB2 RUNSTATS utility collects statistics used by:

• The optimizer, to choose a good access path (access path selection statistics).

• The DBA, for space management, to determine the frequency of reorganizations and for current documentation (space-related statistics).

RUNSTATS is also used to invalidate all cached dynamic statements using the objects referred to by RUNSTATS. If you want only to invalidate cached dynamic statements without collecting statistics, use UPDATE NONE REPORT NO.

UPDATE ALL is the default.

REPORT indicates if the collected statistics should be written to SYSPRINT.

The Optimizer is called by BIND, REBIND, and PREPARE.

Refer to DB2 catalog tables section in the Appendix of DB2 10 for z/OS SQL Reference or Chapter 11 in Part 2 of DB2 10 for z/OS Managing Performance for a complete list of the columns updated by RUNSTATS.


Table Space

Data

Index

Accesspath

selectionstatistics

Space-relatedstatistics

• Number of rows in a table?• Clustering OK?• Index levels?• Number of distinct values in column?• ...

RUNSTATSReport

• DBA

• Reorganize?• ...

REPORT YES SYSPRINT

Catalog

OPTIMIZER

RUNSTATS

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-3. RUNSTATS versus real-time statistics CV8317.0

Notes:

For the space-related statistics, there is an alternative, called real-time statistics, which collects the same information as RUNSTATS and some other statistics, such as the number of rows inserted, updated, or deleted since the last execution of REORG, LOAD REPLACE, REBUILD INDEX, RUNSTATS, or the number of changed pages since the last execution of COPY.

The collection of real-time statistics is almost real time. DB2 writes or updates these statistics to the mentioned catalog tables every n minutes, n being a system parameter (DSNZPARM STATSINT).


Catalog Catalog

Space-relatedstatistics

Space-relatedstatisticsand more

RUNSTATS ... Almost real-time

RUNSTATS versus real-time statistics

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-4. Enabling real-time statistics (1 of 2) CV8317.0

Notes:

The default value for STATSINT is 30 minutes.

Refer to DB2 catalog tables section in the Appendix of DB2 10 for z/OS SQL Reference for a complete list of columns for real-time statistics contained in the catalog tables SYSIBM.SYSTABLESPACESTATS and SYSIBM.SYSINDEXSPACESTATS.


Enabling real-time statistics (1 of 2)

• DSNZPARM STATSINT controls for how long DB2 waits before attempting to write out page set statistics to the real-time statistics tables in the catalog

– SYSIBM.SYSTABLESPACESTATS• Contains information about table spaces and table space partitions

– SYSIBM.SYSINDEXSPACESTATS• Contains information about indexes and index partitions

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-5. Enabling real-time statistics (2 of 2) CV8317.0

Notes:


Enabling real-time statistics (2 of 2)

• All non-utility related numbers, such as #rows and #pages, are initialized with CREATE and therefore do not need a starting point.

• REORG-related numbers are also initialized with CREATE and column REORGLASTTIME is set to the creation time.

• Only for RUNSTATS and COPY the utility must be run once to activate the counters.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-6. When are space-related statistics still needed? CV8317.0

Notes:

OFFPOSLIMIT integer

You may recall from unit 2 that an SQL INSERT causes DB2 to search for the best page to hold the row so that it can maintain the rows in clustering sequence. If there is insufficient free space on the best page then DB2 has to choose a less favorable page.

Occurrences of records that have been inserted into pages other than their best pages are reported by the RUNSTATS utility in NEAROFFPOSF and FAROFFPOSF in SYSIBM.SYSINDEXPART

When you run the REORG utility you can specify OFFPOSLIMIT integer. This means that DB2 does a calculation involving NEAROFFPOSF and FAROFFPOSF and compare the result with your OFFPPOSLIMIT integer. If this integer is exceeded then REORG is performed or recommended.


When are space-related statistics still needed?

• Space-related RUNSTATS statistics are still needed if one of the following applies: – Use of REORG keywords

• OFFPOSLIMIT• INDREFLIMIT• LEAFDISTLIMIT

– Tools using space-related RUNSTATS statistics from the catalog

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

INDREFLIMIT integer

You may recall from unit 2 that an SQL UPDATE can increase the length of a variable length row and if there is insufficient free space on the page to hold the expanded row then DB2 may have to place it on a neighboring, less favorable page.

Occurrences of records that have overflowed to pages other than their best pages are reported by the RUNSTATS utility in NEARINDREF and FARINDREF in SYSIBM.SYSTABLEPART.

When you run the REORG utility you can specify INDREFLIMIT integer. This means that DB2 does a calculation involving NEARINDREF and FARINDREF and compare the result with your INDREFLIMIT integer. If this integer is exceeded then REORG is performed or recommended.

LEAFDISTLIMIT integer

You may recall from unit 2 that when you SQL INSERT a row and the free space on an index leaf page has been used up, a page split occurs. Occurrences of page splits are reflected by the LEAFDIST value in SYSINDEXPART.

You should consider reorganizing an index when leaf page splits start to appear, because leaf page splits make sequential processing slower.

When you run the REORG INDEX utility you can specify LEAFDISTLIMIT integer. This means DB2 compares the LEAFDIST value in SYSINDEXPART for your index with your LEAFDISTLIMIT integer. If this integer is exceeded then REORG INDEX is performed or recommended.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-7. Important RUNSTATS options (1 of 2) CV8317.0

Notes:


Important RUNSTATS options (1 of 2)

Index statistics will be collected for the specified indexes (ALL for all indexes, this is the default)

INDEX (...)

Column statistics will be collected for the specified columns (ALL for all columns) in the specified tables

TABLE (...)COLUMN (...)

Column statistics (cardinality, second lowest and highest value) will be collected for all columns in all tables in the specified table space(s)

TABLEorTABLE (ALL)

Only table space and table statistics, like the number of rows and the number of pages, will be collected

TABLE, COLUMN, INDEXnot specified

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-8. Important RUNSTATS options (2 of 2) CV8317.0

Notes:

History statistics are for your own documentation. They are not used by DB2.

Partition statistics (collected using the PART keyword) are not used by the optimizer for access path selection. The optimizer uses only statistics at the table space / index level. For this reason, the RUNSTATS utility also updates statistics at the table space / index level, even when the PART keyword is used, if one or both of the following applies:

• Statistics already exist for ALL other partitions in the table space / index.

• The option FORCEROLLUP YES is used in the RUNSTATS utility. If statistics are missing for one or more partitions, DB2 extrapolates the statistics from the partitions having statistics. The DSNZPARM STATROLL sets the default for FORCEROLLUP.

Other options (KEYCARD, FREQVAL, ...) are related to access path selection statistics and are covered in detail in course CV96.


Important RUNSTATS options (2 of 2)

For partitioned table spaces and indexes, allows the collection of statistics for the specified partition only

PART

Allows old statistics to be kept in separate catalog tables called SYSIBM.SYS..._HIST

HISTORY

Indicates if, during RUNSTATS, only readers are allowed to access the objects (SHRLEVEL REFERENCE) or if writers are also allowed (SHRLEVEL CHANGE, the default)

SHRLEVEL

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-9. Inline statistics CV8317.0

Notes:


Inline statistics

• The inline statistics function is supported by: – LOAD REPLACE and LOAD RESUME NO– REORG TABLESPACE and REORG INDEX – REBUILD INDEX

• Reduces the overall elapsed time required to: – Run the utility and – Collect statistics

• Inline statistics enabled by using the STATISTICS keyword– Table space statistics are collected during the RELOAD phase

• Discarded records might be counted– Index statistics are collected during the BUILD phase– All RUNSTATS options except COLGROUP can be specified

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-10. Recommended RUNSTATS CV8317.0

Notes:

TABLESPACE DB.TS specifies the table space (and the database to which it belongs) on which table space and table statistics are to be gathered.

SHRLEVEL CHANGE allows other programs to change the table space or index. With SHRLEVEL CHANGE, RUNSTATS might collect statistics on uncommitted data.

TABLE (ALL) specifies that column statistics are to be gathered on all columns of all tables in the table space.

INDEX (ALL) specifies that column statistics are to be gathered for all indexes that are defined on tables that are contained in the table space.

KEYCARD collects all of the distinct values in all of the 1 to n intermediate key column combinations for the specified indexes. n is the number of columns in the index. For example, suppose that you have an index defined on three columns: A, B, and C. If you specify KEYCARD, RUNSTATS collects cardinality statistics for the intermediate column set A and B.


Recommended RUNSTATS

RUNSTATS TABLESPACE DB.TSSHRLEVEL CHANGE TABLE (ALL) INDEX (ALL) KEYCARD HISTOGRAM

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

In DB2 10, the KEYCARD option is deprecated in the RUNSTATS TABLESPACE (and RUNSTATS INDEX) control statement and no longer needs to be specified to collect statistics on the values in the key columns of an index if INDEX is specified.

The RUNSTATS utility automatically collects all of the distinct values in all of the 1 to n intermediate key column combinations for the specified indexes, where n is the number of columns in the index. For example, suppose that you have an index defined on three columns: A, B, and C. RUNSTATS collects cardinality statistics for column A, column set A and B, and column set A, B, and C. With the deprecation of KEYCARD, this functionality cannot be disabled.

The RUNSTATS utility tolerates the specification of the KEYCARD option. The utility does not issue any messages if the control statement includes or excludes the KEYCARD option when INDEX is specified.

Histogram statistics

This is a way of summarizing data distribution. This technique divides up the range of possible values into intervals (quantiles), such that each interval contains approximately the same percentage of the rows. A set of statistics is collected for each interval. This gives the optimizer the potential to select a better access path.

The number of intervals is specified by the value of NUMQUANTILES when you use the HISTOGRAM option of RUNSTATS. For example:

RUNSTATS TABLESPACE DB.TS HISTOGRAM NUMCOLS 2 NUMQUANTILES 10

RUNSTATS will produce an equal-depth histogram, that is, each interval (range) will have about the same number of rows. As a general recommendation, specify NUMQUANTILES 100 or, for example, if the query ranges are always done on boundaries like 0-10%, 10-20%, 20-30%... then NUMQUANTILES 10 might be a better choice.

The better filter factor derived from histogram statistics will benefit RANGE, LIKE and BETWEEN predicates. Furthermore, the optimizer will evaluate the predicate filter factor more accurately if the searching range matches the boundary of any one quantile or any group of consecutive quantiles.

In the example on the visual, NUMCOLS 1 and NUMQUANTILES 100 are used by default.

Important

Running RUNSTATS in this way will ensure that all important statistics are collected. The overhead of collecting lots of statistics is by far outweighed by the better access path chosen by the optimizer due to the availability of complete statistics. One way to reduce RUNSTATS costs is to run RUNSTATS only if needed, meaning that 20% of the data has changed since the last RUNSTATS.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

5.2. REORG

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-11. Reasons for reorganizing table spaces CV8317.0

Notes:

For non-partitioned table spaces, all indexes related to all tables in the table space are "reorganized" when the table space is reorganized, since they are rebuilt as part of the process.

For partitioned table spaces, if the whole table space is reorganized, all indexes related to the table in the table space are "reorganized" when the table space is reorganized, since they are rebuilt as part of the process.

For partitioned table spaces, if one or more partitions are reorganized, the corresponding partitions of all partitioned indexes related to the table in the table space are "reorganized", since they are rebuilt as part of the process. The nonpartitioned indexes are not rebuilt, and therefore are not reorganized. The RIDs of the corresponding logical partitions in the nonpartitioned indexes are corrected in place.


Reasons for reorganizing table spaces

• Recluster the data– SYSTABLESPACESTATS column REORGUNCLUSTINS– SYSINDEXPART columns NEAROFFPOSF AND FAROFFPOSF

• Eliminate overflow records– SYSTABLEPART columns NEARINDREF and FARINDREF– SYSTABLESPACESTATS column REORGFARINDREF

• Restore free space• Modify PRIQTY, SECQTY

– Eliminate extents– Eliminate overallocations

• Realign segments in segmented table spaces

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Note

One more reason to reorganize table spaces is to reset the REORP, AREO*, and AREOR states.

The REORG-pending (REORP) restrictive status indicates that a table space partition definition has changed and the affected partitions must be reorganized before the data is accessible.

The REORG-pending (AREO*) advisory status indicates that a table space, or partition needs to be reorganized for optimal performance.

The advisory REORG-pending (AREOR) status indicates that a table space needs to be reorganized for optimal performance and to apply pending definition changes. This state is applicable only in DB2 10.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-12. Reasons for reorganizing indexes CV8317.0

Notes:

Note

One more reason to reorganize indexes is to reset the AREO* and AREOR states.

The REORG-pending (AREO*) advisory status indicates that an index, or partition needs to be reorganized for optimal performance.

The advisory REORG-pending (AREOR) status indicates that an index needs to be reorganized for optimal performance and to apply pending definition changes. This state is applicable only in DB2 10.


Reasons for reorganizing indexes

• Restore physical ordering of leaf pages– SYSINDEXSPACESTATS column REORGLEAFFAR– SYSINDEXPART column LEAFDIST

• Restore free space• Reduce number of levels

– SYSINDEXSPACESTATS column REORGNUMLEVELS • Modify PRIQTY, SECQTY

– Eliminate extents– Eliminate overallocations

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-13. REORG TABLESPACE CV8317.0

Notes:

The SHRLEVEL parameter determines the accessibility of the data during reorganization and the destination of the reloaded data.

SHRLEVEL NONE


The phases shown on the visual apply to SHRLEVEL NONE.

Data can be read only during the unload of the data, and no SELECT, INSERT, UPDATE or DELETE statements are allowed while the data is being reloaded.

LOG specifies whether records are logged during the RELOAD phase of REORG. If the records are not logged, the table space is recoverable only if an image copy has been taken before REORG. For SHRLEVEL NONE, the default is LOG YES.

SHRLEVEL NONE always reloads data back in the original data sets. The REUSE parameter avoids to DELETE/DEFINE these data sets.


TABLESPACE

UTILINITPHASE

UNLOADPHASE

RELOADPHASE

SORTPHASE

BUILD PHASE

TABLE SPACE

SYSIBM.SYSCOPY

INDEXSPACE(S)

INLINE FULL IMAGE COPY IFCOPYDDN and/orRECOVERYDDN

Correct Nonpartitioned Indexes ifREORG TABLESPACE PART

•SHRLEVEL NONE / REFERENCE / CHANGE•LOG YES / NO•REUSE•STATISTICS

REORG TABLESPACE

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

SHRLEVEL REFERENCE

The data can only be read during most of the reorganization processing. The data is reloaded into shadow (new) data sets.

REORG SHRLEVEL REFERENCE is outside the scope of this course and is covered in detail in course CV870.

SHRLEVEL CHANGE

SELECT, INSERT, UPDATE, and DELETE processing can be executed on the original data during most of the reorganization processing. The data is reloaded into shadow (new) data sets.

REORG SHRLEVEL CHANGE is outside the scope of this course and is covered in detail in course CV870.

STATISTICS

Inline statistics have been discussed in the previous topic.

Note

The first time you run a REORG, DB2 automatically converts the table space from the old basic format to the new reordered format. With reordered row format, DB2 no longer stores the length of varying length columns, and the data can look significantly different within the row/page.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-14. REORG INDEX CV8317.0

Notes:

The options for REORG INDEX are a subset of those for REORG TABLESPACE.

Refer to the previous page for an explanation of these options.


SYSUT1

INDEX

INDEX

UTILINITPHASE

UNLOADPHASE

BUILDPHASE

•SHRLEVEL NONE / REFERENCE / CHANGE•REUSE•STATISTICS

REORG INDEX

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-15. REORG examples CV8317.0

Notes:

In the second example above, PART 3 says reorganize PART 3 of the table space, PART 3 of all partitioned indexes, and update the index entries for PART 3 in all nonpartitioned indexes.

In the third example above, PART 3:6 says reorganize PART 3 through PART 6 of the table space, PART 3 through PART 6 of all partitioned indexes, and update the index entries for PART 3 through PART 6 in all nonpartitioned indexes.

Note

Reorganizing partitions of a table space having NPIs results in the reorganization of the whole NPI.

SHRLEVEL NONE — See the earlier description.

REUSE — See the earlier description.


REORG TABLESPACE PERSDB.PERSTSP1

REORG TABLESPACE PERSDB.PERSTSP2PART 3

REORG INDEX DBA01.DEPTNO_INDEX

REORG TABLESPACE PERSDB.PERSTSP2PART 3:6SHRLEVEL NONE

REORG INDEX DBA01.DEPTNO_INDEXPART 3REUSE

REORG examples

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 5-16. REORG TABLESPACE ... DISCARD CV8317.0

Notes:


REORG TABLESPACE HR.PERSDISCARDFROM TABLE COMPANY.EMPLOYEEWHEN(EMPDEPT=’1CA’

OR EMPDEPT='1CF')

REORG TABLESPACE ... DISCARD

• DISCARD keyword– Mutually exclusive with UNLOAD EXTERNAL– Discarded rows

• Written to SYSDISC data set or• Data set specified with DISCARDDN keyword or• Not written (for example, lost)

– LOAD statements generated as with UNLOAD EXTERNAL• FROM TABLE ... WHEN clause

– Rows meeting the conditions will be discarded (not reloaded)

– Discarded records are in external format

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 5-17. Determining the need for REORG CV8317.0

Notes:

This is a way to automate decision-making to REORG.

The criteria for REORG are specified through parameters.

REPORTONLY checks the limits, set the return code, and produce a report.

Return codes are set to indicate the action taken or not taken.


REORG TABLESPACE DB.TSINDREFLIMIT 15==> REORG performed only if morethan 15% of the rows in the tablespace (cardinality) have overflowrecords.

Determining the need for REORG• REORG TABLESPACE

– OFFPOSLIMIT (percentage of rows no longer in clustering order)– INDREFLIMIT (percentage of overflow records)

• REORG INDEX– LEAFDISTLIMIT (value of column LEAFDIST in SYSIBM.SYSINDEXPART)

• REPORTONLY keyword– Checks limits and sets return code without reorganizing the data

• Return codes– (1) No limit met

• REORG not performed or recommended– (2) Some limit was met

• REORG performed or recommended• Relies on space-related RUNSTATS statistics

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:

The visual summarizes what we have covered in this unit.


Having completed this unit, you should be able to:• Describe and interpret the statistics collected by RUNSTATS



Having completed this unit, you should be able to:• Describe and interpret the statistics collected by RUNSTATS



Unit summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 6. Application data recovery basics


This unit describes what you need to do to make DB2 user data available again following media failures.



• Make DB2 user data available again following media failures.


Accountability:


References













xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 6. Application data recovery basics 6-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Make DB2 user data available again following media failures

After completing this unit, you should be able to:• Make DB2 user data available again following media failures

Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-2. Application data recovery - overview CV8317.0

Notes:

Before we discuss the individual details, the overall big picture for application data recovery is presented in this visual.


Log

Create TS TS1

RESTORE

C ED

IICTS1

MediaFailure

F

SYSIBM.SYSCOPY

Recover Tablespace TS1

(to current)

Archlog

LOG APPLY

Directory of ARCHIVE LOG / ACTIVE LOG

SYSIBM.SYSLGRNX

Application data recovery - overview

IICTS1FIC of TS1

Timeupdates updates updates updates

ICTYPE TSNAME START_RBAC TS1 AF TS1 BI TS1 CI TS1 D

+ + +

Active L.

BSDS

TS1 A1 – A8TS1 B1 – B7TS1 C1 – C7TS1 D1 – D7

BA

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-3. DB2 logging CV8317.0

Notes:

As you make changes to your tables, DB2 writes appropriate records to the DB2 log, allowing DB2 to back out the changes if a unit of recovery fails, or to reapply these changes during a recovery.

The DB2 log is mapped onto data sets. Each DB2 system has a predefined fixed set of active log data sets on disk. Log records are first written by DB2 into a log buffer. They are subsequently written from there onto the active log data sets. As an active log data set fills up, DB2 moves onto the next active log data set.

When all active log data sets have been filled, DB2 wraps around to the first active log data set and uses it again. In order not to lose log records that may be required for a backout or recovery, the active log data sets are automatically offloaded as they fill up.

They are offloaded by DB2 to archive log data sets, which may be on disk but which frequently reside on tapes. In contrast to the limited set of active log data sets, there is effectively an endless set of archive log data sets. Only those archive logs that are still needed for backout or recovery operations need to be kept.


Offloading

Log data sets recorded in

Bootstrap Data Set (BSDS)

ChangesWritten to

DB2 Log

Active Log Data Set 1




Wrap-around

ArchiveLog Data

Set n

ArchiveLog Data Set n+1

ArchiveLog Data Set n+2

DB2 logging

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

The individual log data sets, both active and archive, are recorded in the Bootstrap Data Set (BSDS).

Note

In general, DB2 logs undo and redo records. The following are the exceptions:

• CHECK DATA LOG NO

Use the LOG NO option with caution because its use limits your ability to recover data by using the log. For example, if you issue the CHECK DATA DELETE YES LOG NO utility control statement at particular log RBA, you can recover data that exists on the log before that point in time or after the point on the log at which the utility execution completes.

• LOAD and REORG LOG NO

You should establish image copies after the successful completion of LOAD and REORG, or take inline image copies as part of LOAD and REORG execution.

Nothing is logged for a LOB table space defined with LOG YES or LOG NO. Control information is logged for a LOB table space defined with LOG NO even if LOG YES is specified with the LOAD or REORG utility.

Nothing is logged for a XML table space defined with LOG YES or LOG NO. Nothing is logged for a XML table space defined with LOG NO even if LOG YES is specified with the LOAD or REORG utility.

• CREATE/ALTER TABLESPACE …… NOT LOGGED

Specifies that changes made to data in this table space are not to be recorded on the log. The NOT LOGGED attribute suppresses the logging of undo and redo information.

You should use the NOT LOGGED attribute only for situations where the data is in effect being duplicated. If the data is corrupted, you can recreate it from its original source, rather than from an image copy and the log.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-4. SYSIBM.SYSLGRNX CV8317.0

Notes:

To be able to determine log records for a specific table space more easily, DB2 uses table SYSIBM.SYSLGRNX of the DB2 Directory to record periods during which this table space was updated.

Each row for a table space identifies a time interval during which there was update activity for the table space.

The information in SYSIBM.SYSLGRNX allows DB2 to determine the log data sets or even the parts of the log data sets that DB2 needs to process for a recovery of the table space.


SYSIBM.SYSLGRNX

DB2 Directory

SYSIBM.SYSLGRNX

TableSpace 1

TableSpace 2

DB2 Log

1st update after open

Last update before close

DBID OBIDStart RBA

Start LRSNEnd RBA

End LRSN



DBID OBIDStart RBAStart LRSN

End RBAEnd LRSN



DBID OBIDStart RBAStart LRSN

End RBAEnd LRSN

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-5. Backing up table spaces CV8317.0

Notes:

The DB2 recovery concept is based on the assumption that you regularly back up your table spaces by creating image copies using the COPY utility. By means of the COPY utility you can create FULL IMAGE COPIES (FICs) or INCREMENTAL IMAGE COPIES (IICs).

Full image copy

A full image copy consists of all pages of the table space, whether changed or not.

You specify FULL YES on the COPY utility control statement.

FULL YES is the default.

Incremental image copy

An incremental image copy just contains the pages changed since the previous full or incremental image copy.

Incremental image copies require that a previous full copy exists for the table space.


C = Changed

SYSIBM.SYSCOPY

DB2 Catalog

C

C C

C

Table Space

COPY TABLESPACE FULL YES

COPY TABLESPACE FULL NO

Full Image CopyC

C C

C

Incremental Image Copy

C C C C

Backing up table spaces

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

You specify FULL NO on the COPY utility control statement.

SYSIBM.SYSCOPY

Image copies are sequential data sets. The fact that an image copy exists is recorded in the table SYSIBM.SYSCOPY in the DB2 Catalog.

Each image copy has a row in this table. Column ICTYPE specifies the type of image copy taken:

• A full image copy has an ICTYPE of F. • An incremental image copy has an ICTYPE of I.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-6. Backing up partitions CV8317.0

Notes:

You can create image copies for units smaller than the entire table space.

Partitioned table spaces

You can create image copies for individual partitions by specifying the partition number via the DSNUM keyword of the COPY utility control statement.

DSNUM integer identifies the partition within the partitioned table space to be copied.

Non-partitioned table spaces

You can create image copies for individual data sets by specifying the data set number via the DSNUM keyword of the COPY utility control statement.

DSNUM integer identifies the data set number within the non-partitioned table space to be copied.


PART1

PART3

Partitioned Table Space or Partitioned Index

PART2

Image Copy

COPY . . . DSNUM 2

PART2

Backing up partitions

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Since image copies are physical copies, you cannot establish image copies for logical partitions of non-partitioned indexes. You also cannot take image copies of the physical data sets of non-partitioned indexes.

The DSNUM column of SYSIBM.SYSCOPY row for an image copy identifies the partition or data set copied.

If you establish the image copies for partitions or data sets, then you cannot recover the table space as a unit in this case. You must recover the table space partition by partition, or data set by data set.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-7. Copy data sets CV8317.0

Notes:

DB2 gives you the capability to take multiple copies.

If an image copy is not available because it has been destroyed, then DB2 uses the second copy. DB2 can also fall back and use earlier image copies. This avoids lengthy recoveries from the log.

By means of the COPYDDN parameter of the COPY utility control statement, you can specify the DD names for two copies, the regular image copy, referred to as the PRIMARY copy, and a second copy, referred to as the BACKUP copy.

For each copy produced, SYSIBM.SYSCOPY contains a row. Column DSNAME specifies the data set name for the copy, and column ICBACKUP specifies whether it is a PRIMARY copy, or a BACKUP copy. Most of the other columns are identical, even the TIMESTAMP column containing the date and time when the row was inserted.

For the copies, you should:

• Consider using generation data groups (GDGs) to prevent duplicate data set names.

• Specify DISP=(MOD,CATLG) if you want to allow for the restart of the COPY utility.


Table Space or Index Space

COPY . . . COPYDDN ( local-primary, [ local-backup ])

Local Primary Local Backup

optional

Copy data sets

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• Specify a large block size for performance.

Note

For tape data sets the large block interface is supported (greater than 32760 bytes). This can significantly improve COPY and the restore phase of RECOVER.

Large format data sets are automatically supported when they are input data sets to utilities. Large format data sets are greater than 65,535 tracks per disk volume. They are supported as output for utilities if the DD card specifies table spaces that are created with DSNTYPE=LARGE.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-8. COPY - examples CV8317.0

Notes:

Example 1 shows the COPY utility control statements to take a PRIMARY and a BACKUP full image copy of each of six table spaces.

Example 2 shows an alternative way of taking the same copies using LISTDEF and TEMPLATE statements.

LISTDEF and TEMPLATE statements can be used with most utilities. They ease the management of utilities, because they minimize the need to change utility control statements, as a result of:

• Adding a table space to a database • Space allocation changes due to growing table spaces

LISTDEF and TEMPLATE are discussed in course CV870.


Example 1//UTIL EXEC DSNUPROC,SYSTEM=DBV8,UID='COPY',UTPROC=''

//DSNUPROC.TSDEPTP DD DSN=WWCF83DB.TSDEPT.P2001056,...

//DSNUPROC.TSDEPTB DD DSN=WWCF83DB.TSDEPT.B2001056,...

//DSNUPROC.TSEMPLP DD DSN=WWCF83DB.TSEMPL.P2001056,...

//DSNUPROC.TSEMPLB DD DSN=WWCF83DB.TSEMPL.B2001056,...

//DSNUPROC.TSLOCNP DD DSN=WWCF83DB.TSLOCN.P2001056,...

//DSNUPROC.TSLOCNB DD DSN=WWCF83DB.TSLOCN.B2001056,...

//DSNUPROC.TSPROJP DD DSN=WWCF83DB.TSPROJ.P2001056,...

//DSNUPROC.TSPROJB DD DSN=WWCF83DB.TSPROJ.B2001056,...

//DSNUPROC.TSRSMEP DD DSN=WWCF83DB.TSRSME.P2001056,...

//DSNUPROC.TSRSMEB DD DSN=WWCF83DB.TSRSME.B2001056,...

//DSNUPROC.SYSIN DD *

COPY TABLESPACE WWCF83DB.TSDEPT COPYDDN(TSDEPTP,TSDEPTB) FULL YES

TABLESPACE WWCF83DB.TSEMPL COPYDDN(TSEMPLP,TSEMPLB) FULL YES

TABLESPACE WWCF83DB.TSLOCN COPYDDN(TSLOCNP,TSLOCNB) FULL YES

TABLESPACE WWCF83DB.TSPROJ COPYDDN(TSPROJP,TSPROJB) FULL YES

TABLESPACE WWCF83DB.TSRSME COPYDDN(TSRSMEP,TSRSMEB) FULL YES

//UTIL EXEC DSNUPROC,SYSTEM=DBV8,UID='COPY',UTPROC=''

//DSNUPROC.SYSIN DD *

LISTDEF RECSET INCLUDE TABLESPACES

TABLESPACE WWCF83DB.TSEMPL RI ALL

TEMPLATE RECTMP DSN &DB..&SN..&PB.&DATE.

COPY LIST RECSET COPYDDN(RECTMP,RECTMP) FULL YES

Example 2

COPY - examples

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-9. COPYTOCOPY utility - establishing copies of image copies CV8915.0

Notes:

Using COPY utility you can establish a primary copy and a backup copy. Of course, if you establish both primary and backup copies, the longer the COPY, REORG TABLESPACE, or LOAD utility takes and the longer the object is unavailable.

You can establish only the primary copy during the utility execution and create the missing backup copy later by means of the COPYTOCOPY utility. From an existing image copy for a table space, an index space, a table space partition, or an index partition, the COPYTOCOPY utility establishes the backup copies and records them in SYSIBM.SYSCOPY.

The copies established are the corresponding backup, and must not exist yet. You specify via the COPYDDN parameter.

The SYSIBM.SYSCOPY rows for the copies established by COPYTOCOPY receive the same TIMESTAMP, ICDATE, ICTIME, and START_RBA values as the input copy. Of course, the data set names (DSNAME column) must be different.


COPYTOCOPY TABLESPACE table-space-name

COPYDDN (, backup)FROMLASTINCRCOPY

SYSIBM.SYSCOPY

DB2 Catalog

Backup

Primary

• COPYTOCOPY allows to establish missing copies from existing copy• Established copies recorded in SYSIBM.SYSCOPY

– Same TIMESTAMP, ICDATE, ICTIME, and START_RBA as input copy• FROMLASTCOPY, FROMLASTFULLCOPY, FROMLASTINCRCOPY or FROMCOPY,

that is, from specified copy data set

COPYTOCOPY utility –establishing copies of image copies

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

You have multiple options for selecting the input copy, that is, the copy data set to be copied. You can select a specific copy data set (FROMCOPY parameter) by specifying its data set name (and volume serial number and file sequence number if the data set is not cataloged). For generation data sets, you must provide the fully qualified data set names, including absolute generation and version numbers.

You can also select the input copy data set in a more generic manner:

• If you specify FROMLASTCOPY, the most recent image copy for the object is copied independent of the type of image copy (full image copy or incremental image copy).

• If you specify FROMLASTFULLCOPY, the most recent full image copy for the object is copied.

• If you specify FROMLASTINCRCOPY, the most recent incremental image copy for the object is copied.

If you specify the input copy generically, you do not specify the type of input copy data set (primary copy, or backup copy) either. From the existing copy data sets, the COPYTOCOPY utility determines the one it is going to copy.

There are also rules for the order in which missing copies can be established by different COPYTOCOPY utility jobs: A missing primary copy must be established before a missing backup copy. If the primary copy does not exist when a backup copy is to be established, message DSNU1401I is issued and the COPYTOCOPY utility fails.

The example on the visual establishes a backup copy which must not exist yet. Since the backup copy is established, the primary copy must already exist.

An advantage of the COPYTOCOPY utility over the COPY utility is that it does not restrict the access to the table space, index space, or partition. It need not restrict the access since it copies a copy and not the "real" object. It only needs to restrict the access to SYSIBM.SYSCOPY. Therefore, it might be your strategy to create only the primary copy by means of the COPY utility and to establish the backup copy data set using COPYTOCOPY.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-10. Table space recovery concept CV8317.0

Notes:

Table spaces are recovered by means of the RECOVER utility. When recovering a table space, the RECOVER utility performs two major phases, the RESTORE phase and the LOGAPPLY phase.

By means of the rows in SYSIBM.SYSCOPY, the RECOVER utility determines the full image copy it needs as a basis for the requested recovery.

RESTORE phase

During the RESTORE phase, it merges the full image copy with its incremental image copies to form the basis for the restored table space. Pages in an incremental image copy replace the appropriate pages in the full image copy or in earlier incremental image copies.

The “restored” version of the table space is far from complete, because there were most likely changes to the table space after the latest image copy was taken. These changes are recorded only on the DB2 log.


SYSIBM.SYSCOPY

DB2 Catalog

Incremental Image Copy 1

3 10 11 24


4 5 11

Full Image Copy

1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

17 18 19 20

21 22 23 24

25 26 27 28

29 30 31 32

Table Space1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

17 18 19 20

21 22 23 24

25 26 27 28

29 30 31 32

20

125

10

BSDS

Log Data Sets

DB2 Log

DB2 Directory

SYSIBM.SYSLGRNX

5 10 12 20RESTORE LOGAPPLY

Table space recovery concept

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

LOGAPPLY phase

During the LOGAPPLY phase, the appropriate log records are read from the DB2 log and applied to the restored table space.

This is where SYSIBM.SYSLGRNX comes in handy, because it identifies the ranges on the DB2 log pertaining to the table space being recovered. DB2 needs to read only these log ranges.

Point-in-time recovery

Point-in-time recovery, also known as partial recovery, is the process of resetting part or all of your data to an earlier point in time. The reasons for point-in-time recoveries can be manifold. In contrast to a recovery to current which is generally used to correct physical problems, point-in-time recoveries are mostly used to undo logical errors such as the execution of an erroneous program as illustrated above:

Imagine that, after having stopped the online service and having taken image copies of your table spaces and COPY enabled index spaces, you run a program overnight. When returning to the office the next morning, you discover that the program did not work as expected and has corrupted your data. As a consequence, you may not have another chance than resetting the data to a point in time before you started the erroneous program, most likely to the point in time when the image copies were taken.

DB2 supports point-in-time recovery. However, it does not allow you to back out erroneous programs or transactions as such. It only allows you to reset your data consistently to a prior point in time.

Point-in-time recoveries must be handled with extreme care. In many cases, you cannot really perform point-in-time recoveries. Unless you have a detailed transaction log allowing you to reapply the transactions correctly, you cannot reset your data if there were updating online transactions in the meantime. Many transactions involve human interactions that are not automatically undone by resetting the data. For example, money may have been paid to a customer who has left in the meantime. The customer does not come back just because you are resetting your data. Similarly, customers who have deposited money in bank accounts would not be very happy finding out that their money has disappeared.

Nevertheless, point-in-time recoveries might be unavoidable and possible in cases as the one described above.

Point-in-time recovery is not covered in this course.xc

lusivo

form

ación

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-11. Recovery - examples CV8317.0

Notes:

You can use the RECOVER utility to recover an entire table space, a list of table spaces, individual partitions, or data sets.

If you make image copies by table space, you can recover the entire table space or a data set or partition from the table space.

If you make image copies separately by partition or data set, you must recover the partitions or data sets by separate RECOVER steps.


RECOVER TABLESPACE DB01.TS01TABLESPACE DB01.TS02

Example 2

RECOVER TABLESPACE DB01.TS01 DSNUM 3TABLESPACE DB01.TS02 DSNUM 3

Example 1

RECOVER TABLESPACE DB01.TS01 DSNUM ALL

Example 4

Example 3RECOVER TABLESPACE DB01.TS01 DSNUM 1

TABLESPACE DB01.TS01 DSNUM 2 TABLESPACE DB01.TS01 DSNUM 3 TABLESPACE DB01.TS01 DSNUM 4

RECOVER TABLESPACE DB01.TS01

Example 5

Recovery - examples

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-12. Preparing for a recovery CV8317.0

Notes:

With the REPORT RECOVERY utility, you can determine which image copies and archive log data sets (if any) you need for the recovery of a table space.

Image copy information is contained in SYSIBM.SYSCOPY, and the REPORT utility displays the information of the corresponding rows.

Log range information is extracted from SYSIBM.SYSLGRNX.

Archive log data set information is extracted from the BSDS.

By specifying CURRENT, you can restrict the information to entries since the most recent “recovery base”. This is the point at which the most recent full image copy was taken, or when LOAD REPLACE LOG YES or REORG LOG YES was last run.

By specifying SUMMARY, you can limit the information to the volume serial numbers for the image copies and for the archive log data sets.


DB2 Directory

SYSIBM.SYSLGRNX

BSDS

Log Data Sets

Preparing for a recovery

• Use the REPORT RECOVERY utility to determine:– Image copies, which must be restored

– Log ranges that need to be applied

– Archive log data sets containing the log records

• You can obtain the information for:– A specific table space– A partition of a partitioned table space– A data set for a nonpartitioned table space

• Limit the information you receive: • CURRENT – only what is needed for the last recoverable point• SUMMARY – only volume serial numbers for the image copy data

sets and the archive log data sets

DB2 catalog

SYSIBM.SYSCOPY

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-13. Combining image copies for table spaces CV8317.0

Notes:

The MERGECOPY utility allows you to merge image copies of a table space in advance to reduce the time required when a recovery is necessary.

The MERGECOPY utility gives you two possibilities:

• You can merge the latest full image copy and the incremental image copies based on it to form a new full image copy (NEWCOPY YES).

• You can merge the incremental image copies of the latest full image copy to form a new single incremental image copy (NEWCOPY NO).

In both cases, the new image copy is recorded in SYSIBM.SYSCOPY.


Combining image copies for table spaces

MERGECOPY . . . NEWCOPY YES


3 10 11 24


4 5 11

1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

17 18 19 20

21 22 23 24

25 26 27 28

29 30 31 32

Full Image Copy1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

17 18 19 20

21 22 23 24

25 26 27 28

29 30 31 32

Full Image Copy1 2 3 4

5 6 7 8

9 10 11 12

13 14 15 16

17 18 19 20

21 22 23 24

25 26 27 28

29 30 31 32

Incremental Image Copy3 4 5 10 11 24

MERGECOPY . . . NEWCOPY NO


3 10 11 24


4 5 11

Full Image Copy

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-14. REBUILD INDEX utility CV8317.0

Notes:

The REBUILD INDEX utility allows you to rebuild an index from scratch using the data in the table on which the index is based.

If the table space is defective as well, then you must recover the table space before you can rebuild the index.

You can rebuild the entire index, a partition of a partitioned index, or a logical partition of a nonpartitioned index. A logical partition always corresponds to a physical partition of the associated partitioned table space. It contains all index entries whose target rows are contained in that physical partition.

With a single REBUILD INDEX statement you can rebuild multiple indexes, index partitions or logical partitions. All indexes or index partitions rebuilt must be for tables of the same table space.

REBUILD INDEX allows you to rebuild all indexes for all tables of a table space by specifying the table space.


Index 2Index 1

TableSpace

Key/RID pairs for all rows

and indexes

UNLOAD

SORTBLDSORTBUILD

REBUILD INDEX utility• Allows you to rebuild an index from scratch

– Uses data in the table

• You can rebuild:– An entire index– A partition – A logical partition – Multiple indexes or partitions

• For tables of same table space • With single REBUILD INDEX

– All indexes for all tables of a table space• By specifying the table space

• REBUILD INDEX (creator.ixname,....)• REBUILD INDEXSPACE

(dbname.isname,..)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-15. REBUILD INDEX examples CV8317.0

Notes:

The visual shows some examples of REBUILD INDEX and REBUILD INDEXSPACE.


REBUILD INDEX (DSN8710.XDEPT1)

Example 2: Rebuild all partitions of a partitioning index

Example 1: Rebuild a single index

Example 4: Rebuild all indexes on a partitioned table space

Example 3: Rebuild multiple partitions of a partitioning index

REBUILD INDEX (ALL) TABLESPACE DB01.PTS01

REBUILD INDEX (DSN8710.XEMP1 PART 2, DSN8710.XEMP1 PART 3)

REBUILD INDEX (DSN8710.XEMP1)

Example 5: Rebuild one index partition specifying index space nameREBUILD INDEXSPACE (DB1.IS1 PART 9)

REBUILD INDEX examples

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 6-16. REBUILD INDEX considerations CV8317.0

Notes:


REBUILD INDEX considerations

• REUSE option avoids deletion and redefinition of data sets

• If you are rebuilding an index because of media failure:– Do not use the REUSE option– Remove defective volume from storage group before

rebuilding the index

• You can gather index statistics during REBUILD INDEX– DB2 Catalog updated and/or statistics printed– Rebind required to make statistics effective

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-17. Recovery / rebuild pending CV8317.0

Notes:

RECP

RECOVER Pending status

A table space or table space partition is broken and must be recovered by running the RECOVER utility on the affected object.

RBDP

REBUILD Pending status

Set, for example, by RECOVER, LOAD, or REORG abend

Can be set for:

• Index

• Physical Index Partition


Partitioned Index

Non-Partitioned IndexData Partitions

Logical Partition

Logical Partition

Logical Partition

Logical Partition

CUSTNOIndex

CUSTNAMEIndex

PSR

BD

RB

DP

RB

DP*

REC

P

Recovery / rebuild pending

RB

DP REC

P

RB

DP

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• Logical Index Partition of NPI

- Can still access other logical index partitions via SQL and utilities

- Reset by REBUILDing only the logical partition

RBDP*

REBUILD pending status

Set, for example, by RECOVER TORBA / TOCOPY of data partitions

Can be set for:

• Logical Index Partition of NPI only

- Entire index is inaccessible to SQL applications

- Reset by REBUILDing only the logical partition

PSRBD

Page set REBUILD pending status

Set, for example, by LOADing data partition and abending in BUILD phase for the NPI

Can be set for:

• Entire NPI only

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 6-18. MODIFY RECOVERY CV8317.0

Notes:

Since SYSIBM.SYSLGRNX can become very large, run the MODIFY RECOVERY utility regularly to delete obsolete SYSIBM.SYSCOPY and related rows (log ranges) from SYSIBM.SYSLGRNX.

If you specify the AGE parameter, the rows older than the specified number of days are deleted. In particular, AGE(0) means that the rows older than zero days are deleted, that is, the rows created yesterday or before. If you specify the DATE parameter, the rows created before the specified date are removed. For AGE(*) or DATE(*), all rows for the specified object are deleted regardless of their age or the date on which they were created.

You can specify an entire table space or, by means of the DSNUM parameter, a specific partition or data set. As usual, an entire table space is specified by not providing the DSNUM parameter or specifying DSNUM ALL.

If you specify an entire table space, those SYSIBM.SYSCOPY rows for the entire table space and for its partitions or data sets are deleted that meet the specified age or date criterion. In addition, all SYSIBM.SYSLGRNX rows for the table space or its partitions are removed meeting the age or date criterion.


MODIFY RECOVERY

• Specify Retention Criteria

• Works on dates not timestamps

• SYSLGRNX records deleted even if no SYSCOPY records deleted

• Example:MODIFY RECOVERY TABLESPACE DBKQBL01.TPKQBL01 RETAIN GDGLIMIT

DELETE AGE integer

DATE(*)

integer

RETAIN LAST

(*)

(integer)LOGLIMIT

GDGLIMITGDGLIMIT LAST (integer)GDGLIMIT LOGLIMIT

Queries SYSCOPYQueries BSDSQueries GDG

For mixed lists

DELETE AGE integer

DATE(*)

integer

RETAIN LAST

(*)

(integer)LOGLIMIT

GDGLIMITGDGLIMIT LAST (integer)GDGLIMIT LOGLIMIT

Queries SYSCOPYQueries BSDSQueries GDG

For mixed lists

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

If you specify a specific partition or data set, SYSIBM.SYSCOPY rows for the specified partition or data set, meeting the specified age or date criterion, are deleted. However, SYSIBM.SYSCOPY rows having a START_RBA greater than that of the most recent recoverable point for the entire table space are not deleted and message DSNU577I is issued. The most recent recoverable point may have been established by a full image copy, an inline copy, a LOAD LOG YES, or a REORG TABLESPACE LOG YES.

If a partition copy is deleted, the SYSIBM.SYSLGRNX rows for the partition copy, meeting the age or date criterion, are deleted as well.

When performing a MODIFY RECOVERY for a table space, the SYSIBM.SYSCOPY and SYSIBM.SYSLGRNX rows for related COPY enabled indexes, meeting the age and date criterion, are automatically deleted. You cannot specify an index or index space for the MODIFY RECOVERY utility.

Alternatively, in DB2 V9 you can use the keyword RETAIN to indicate that records are to be retained and older records are to be deleted.

The RETAIN keyword has five possible settings. Note for all these settings DB2 establishes a date before which entries can be deleted. To satisfy the retention criteria, RETAIN works internally with a date, not a complete timestamp. As a result, more copies might be kept than are specified by RETAIN. For example, if the most recent five copies have been taken on the same day, and RETAIN LAST (2) is specified, then all five copies remain in SYSCOPY. When the criteria is related to the number of copies, then DB2 only considers primary full copies (ICTYPE=’F’ and ICBACKUP=blank, in SYSCOPY).

• LAST (integer) specifies the number of recent records to retain in SYSIBM.SYSCOPY if the most recent record in SYSIBM.SYSCOPY refers to a non-GDS.

• LOGLIMIT queries the BSDS to determine the oldest archive log timestamp and deletes records older than this timestamp, if the most recent record in SYSIBM.SYSCOPY refers to a non-GDS.

• GDGLIMIT retrieves the GDG limit if the most recent record in SYSIBM.SYSCOPY refers to a GDS (Generation data set). As many recent records (referring to the same GDG) as specified in the GDG limit is retained.

• GDGLIMIT LAST (integer) is a combination of the GDGLIMIT and LAST options. DB2 uses the GDG base limit, if the last primary copy is a GDG, if not it uses the integer specified. This is useful when both GDGs and non-GDGs are used and when using LISTDEF.

Use the AGE or DATE options when you want to delete SYSLGRNX rows and there are no SYSCOPY rows that meet the deletion criteria. The SYSLGRNX rows are deleted based on the AGE or DATE specified.

The example control statement specifies that MODIFY RECOVERY is to retain as much recent records in SYSIBM.SYSCOPY as defined in the GDG limit.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:

The visual summarizes what we have covered in this unit.


Having completed this unit, you should be able to:• Make DB2 user data available again following media failures

Having completed this unit, you should be able to:• Make DB2 user data available again following media failures

Unit summary

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 7. Program preparation / bind


This unit covers the main steps needed to prepare a program with embedded static SQL to access DB2.



• Describe the main steps needed to prepare a program with embedded static SQL to access DB2.


Accountability:

• Discussion

References


SC19-2969 DB2 10 for z/OS Application Programming & SQL Guide



SC18-9841 DB2 Version 9.1 for z/OS Application Programming & SQL Guide



SC18-7415 DB2 UDB for z/OS Version 8 Application Programming and SQL Guide


xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 7. Program preparation / bind 7-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe the main steps needed to prepare a program with

embedded static SQL to access DB2

After completing this unit, you should be able to:• Describe the main steps needed to prepare a program with


Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 7-2. Program preparation flow for DB2 precompiler CV8317.0

Notes:

Embedded static SQL

Traditionally, source programs that access DB2 contain ordinary SQL statements; such statements are called "embedded SQL statements".

If these SQL statements are (almost) complete, they are called "embedded static SQL statements". If these SQL statements are provided by the user at run time, they are called "embedded dynamic SQL statements".

In this section, we deal with embedded static SQL statements.

Why precompile?

In the source code, these SQL statements are delimited by:

• PLI: "EXEC SQL" and ";"

• COBOL: "EXEC SQL" and "END-EXEC", and so on.


Program preparation flow for DB2 precompiler

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Therefore, a precompiler must eliminate or modify such statements which the language compiler cannot process.

DB2 precompiler

The DB2 precompiler processes the program source code and comments out all of the SQL statements and replaces them with calls to the language interface (CALL DSNHLI). It creates two outputs, the first output being the modified source code that is input to the program compiler. The second output is the DBRM that is the input into the BIND process.

You process the SQL statements in your source program by using the DB2 precompiler. The output is a load module, possibly one or more packages, and an application plan. Creating a load module involves compiling the modified source code that is produced by the precompiler into an object program, and link-editing the object program to create a load module. Creating a package or an application plan involves binding one or more DBRMs, which are created by the DB2 precompiler, using the BIND PACKAGE or BIND PLAN commands.The BIND PLAN can be done asynchronously with an n:m relationship implemented only via the package list.

You must include the correct interface module (DSNELI, DSNCLI, DSNRLI, DSNALI) during the link-edit step with options that support the precompiler.

What the BIND PACKAGE process does

• It takes a single DBRM as input

• It determines access path to the data for each SQL statement. For example, whether to access the data directly or via an index.

• It stores the access paths and the executable form of the statements in a package in a collection in DB2.

What the BIND PLAN process does

BIND PLAN builds an application plan from the specified collections containing packages. All local DB2 programs require an application plan to allocate DB2 resources and support SQL requests made at run time.

What happens at runtime?

The load module must be associated with the corresponding plan. For example, in a TSO environment, via the DSN subcommand RUN.

When a CALL DSNHLI statement in the load module is executed, the appropriate access path in the package is retrieved and executed.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 7-3. Program preparation flow for multiple modules CV8317.0

Notes:

Modularization using packages

When dealing with a more complex application, for example one consisting of a MAIN program and two external sub programs SUB1 and SUB2, modularization in DB2 is achieved with packages.

Each external program is subject to a precompiler run of its own, so we get three DBRMs and three modified sources.

You bind each DBRM separately into a package which is a DB2 object. Then, you associate these three packages with an application plan.

The advantage of using packages is that, if you change one source program module, you have to precompile only that one, and bind the corresponding package.

The access paths are determined at BIND PACKAGE and stored with each package.

Packages are qualified with a collection, hence the statement has two parameters:


Compile

Link/Edit

Main Sub1 Sub2

Mod.Source

Main Sub1 Sub2

DB2

Main Sub1 Sub2

Source

RUNPROGRAM (Main)PLAN (Plan1)

BIND PLAN (Plan1)PKLIST (Col1.*,Col2.Sub2)

BIND PACKAGE(Col1)MEMBER(Main)

Main Sub1Col1

Sub2Col2

Main Sub1 Sub2

DBRM

Main Sub1 Sub2

Object

Main Sub1 Sub2

LoadRun Time:

BIND PACKAGE

BIND PLAN

Precompile

Program preparation flow for multiple modules

Plan1

BIND PACKAGE(Col1)MEMBER(Sub1)

BIND PACKAGE(Col2)MEMBER(Sub2)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

• BIND PACKAGE(collection ID) MEMBER(dbrm-member).

The name of the resulting package is the name of DBRM member.

When associating the three packages with the application plan PLAN1, you use the PKLIST option of BIND PLAN.

The plan PLAN1 merely consists of pointers to the three packages.

At execution time the MAIN load module works with PLAN1.

With packages the CALL DSNHLI specifies the dbrm-member as one parameter, and hence DB2 knows which package to search for the corresponding access path.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 7-4. Let BIND determine object to be accessed CV8317.0

Notes:

Assume that your test and production environments run on the same DB2 subsystem. When you want to promote your application from the tables with the TEST qualifier to tables with PROD qualifier, you must ensure that your programs access the right tables.

As you do not want to change all your source programs, you can omit the table qualifiers in your source programs and specify these qualifiers at package bind time.

When promoting from TEST to PROD, you have to bind only your DBRMs again.

When you specify neither the package owner (OWNER option) nor the table qualifier (QUALIFIER option), then the binder userid (USER1) becomes the qualifier of all non-qualified tables names in your program.

When you specify the package owner, but do not use the QUALIFIER option, the package owner is also used as qualifier for all non-qualified table names.

When you specify the table qualifier (QUALIFIER option), this parameter becomes the qualifier for all unqualified table names in your program.


Precompile

DB2

PROG1

DBRM

PROG1 Load

EXEC SQL SELECT ... FROM V1;

Source

USER1 issues:

USER1.V1 TEST.V1 ADMIN.V1

BIND PACKAGE(C)MEMBER(PROG1)OWNER(PROD)QUALIFIER(ADMIN) BIND PLAN PLAN2PKLIST(C.PROG1)

BIND PACKAGE(C)MEMBER(PROG1)OWNER(TEST) BIND PLAN PLAN2PKLIST(C.PROG1)

BIND PACKAGE(C)MEMBER(PROG1)BIND PLAN PLAN2PKLIST(C.PROG1)

Comp & Link

PROG1

Let BIND determine object to be accessed

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:


Having completed this unit, you should be able to:• Describe the main steps needed to prepare a program with


Having completed this unit, you should be able to:• Describe the main steps needed to prepare a program with


Unit summary

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C



Student NotebookV5.4

Uempty

E

Unit 8. Security


This unit describes the DB2 security mechanisms.



• Describe DB2 global security • Describe the various DB2 authids and how they are established • Understand how DB2 security controls access to data • Describe and implement DB2 privileges and authorities

appropriately • Describe how ownership is established in DB2 • Describe DB2 authorization checking • Describe and implement security for plans and packages


Accountability:


References






SC18-7426 DB2 UDB for z/OS Version 8 SQL Referencexclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 8. Security 8-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe DB2 global security • Describe the various DB2 authids and how they are

established• Understand how DB2 security controls access to data • Describe and implement DB2 privileges and authorities

appropriately• Describe how ownership is established in DB2 • Describe DB2 authorization checking • Describe and implement security for plans and packages

Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-2. DB2 authorization CV8317.0

Notes:

RACF security can be used to authenticate address spaces, such as IMS, CICS, TSO, and DB2 address spaces, when they are initialized.

RACF security can be used to control which address spaces can connect to DB2.

When a user signs on to, say, CICS or IMS, then they provide an ID and password which have to be checked.

RACF security can control which user can use a transaction in CICS or IMS.

The ENABLE / DISABLE BIND options define which environments are valid or invalid for particular plans or packages. For example, you could BIND a package for execution only in MPP regions of a specific IMS system.

The Id issuing an SQL statement, a DB2 command, or executing a DB2 utility can be checked from the information stored in DB2 catalog tables to verify the ID is authorized.

RACF can protect DB2 data sets, including the times when these data sets are not allocated to DB2.


CICS

IMS

BATCH

TSO

DB2AUTHORIZATION

SQLCOMMANDSUTILITIES

DB2

DB2

CATALOG

DB2 authorization

Distributed

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-3. Who is the user? CV8317.0

Notes:

Authorization IDs

Every process that connects to or signs on to DB2 is represented by a set of one or more DB2 identifiers called authorization IDs.

Authorization IDs can be assigned to a process by default procedures or user-written exit routines. Methods of assigning these IDs are covered in the next visual.

Primary authorization ID

Every process is assigned one mandatory ID called the primary authorization ID.

It represents the user:

• TSO logon userid • CICS / IMS signon userid

It holds personal privileges and is used by accounting and performance traces.


Userid

composite list

PRIMARYAUTHID

CURRENTSQLID

SET CURRENT SQLID

SECONDARY

AUTHID

LIST

(0 - 1012)

USER

AUTHORIZATION

EXIT

ROUTINE

Who is the user?

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Secondary authorization IDs

You can have up to 1,012 additional, optional authids called secondary authorization IDs.

Typically, these may be project, function, team, or group-related.

They can mean additional privileges for the user and allow an object to be created by one ID and owned by another ID.

By separating personal IDs from functional IDs means granted privileges will be more stable and the need for granting and revoking them will be reduced.

DB2 learns what a primary authorization ID’s secondary list is going to be from an authorization exit. The exit learns it from RACF, though exit program could build it (not recommended).

• User exits provide secondary authorization ID values:

- Exit DSN3@ATH - for TSO, Batch, and Distributed

- Exit DSN3@SGN - for IMS and CICS

• To succeed with SET CURRENT SQLID:

- SQLID must match primary or secondary authorization IDs

- Except that SYSADM can set CURRENT SQLID to any value (with SEPARATE_SECURITY set to NO -this DSNZPARM is introduced later in this unit)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-4. Establishing authorization IDs CV8317.0

Notes:

How authorization IDs are established depends on the environment of the requesting process.

Requests from, for example, TSO go through CONNECTION PROCESSING, which drives a CONNECTION EXIT ROUTINE. This routine establishes the PRIMARY AUTHID, the initial value of the CURRENT SQLID, and can provide up to 1012 SECONDARY AUTHIDs.

Similarly, requests from CICS or IMS transactions go through SIGNON PROCESSING, which drives a SIGNON EXIT ROUTINE.

The visual shows how the exit routine fetches information from RACF to assign the authorization IDs. By default, it obtains the RACF GROUPS you are connected to via the RACF CONNECT command, and assigns these RACF GROUP names as SECONDARY AUTHIDs.

The sample exit routine provided by DB2 can be tailored to suit your particular requirements.

This mechanism works with other security products as well as RACF.


RACFData Set

TSO / CICS / IMS DB2

ExitLOGON/SIGNON

ID

Initial Primary Authid Primary Authid

PAYROLL

ACCNTG

MANUF

Secondary Authids

LOGON/SIGNON

LOGON/SIGNON

ID

PAYROLL

RACFControlBlock

LOGONID

Establishing authorization IDs

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-5. USER and CURRENT SQLID special registers CV8317.0

Notes:

USER special register

Always refers to your PRIMARY AUTHID.

Cannot be changed.

CURRENT SQLID special register

This is set to either your primary authid or one of your secondary authids. (Except for SYSADM / SYSCTRL - see later)

For dynamic SQL, your CURRENT SQLID special register has 3 purposes:

1. Provides implicit qualifier for unqualified objects: - SELECT * FROM T1

2. Used for authorization checking of: - CREATE, GRANT, REVOKE

3. Becomes the owner of a table, table space, database, storage group or synonym: - CREATE TABLE T1........


USER and CURRENT SQLID special registers

• USER– Always refers to your PRIMARY AUTHID– Cannot be changed

• CURRENT SQLID– Use SET CURRENT SQLID SQL statement to set to:

– Your primary authid or– One of your secondary authids

– For dynamic SQL, has 3 purposes: • Provides implicit qualifier for unqualified objects:

> SELECT * FROM T1• Used for authorization checking of:

> CREATE, GRANT, REVOKE• Becomes owner of a table, .....

> CREATE TABLE T1........

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Querying the values of special registers

You can use this query to show the values of USER and CURRENT SQLID.

SELECT 'PRIMARY AUTHID = '||USER, 'CURRENT SQLID = '||CURRENT SQLID FROM SYSIBM.SYSDUMMY1

This will result in:

PRIMARY AUTHID = primary authid CURRENT SQLID = current sqlid

There is no standard way within DB2 for you to retrieve a list of all your SECONDARY AUTHIDs.

Setting CURRENT SQLID

You can change the value with the SET CURRENT SQLID SQL statement.

The default CURRENT SQLID is the PRIMARY AUTHORIZATION ID. It is set initially by the exit routine invoked at connection to DB2.

The CURRENT SQLID can be set to your PRIMARY AUTHID or to any SECONDARY AUTHID provided by the exit routine.

If an invalid ID is specified for SET CURRENT SQLID, a -553 return code results and the SQLSTATE is set to 42503.

With SYSADM authority it can be set to any value.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-6. What can be authorized? (1 of 2) CV8317.0

Notes:

In DB2 for z/OS we talk about privileges and Authorities. Refer to the security section of the DB2 10 for z/OS Administration Guide for a complete description of these privileges and administrative authorities. An administrative authority is simply a collection of individual privileges.


• Privileges– Explicit

• Collection (CREATEIN)• Database (CREATETAB, CREATETS, LOAD, DROP, STARTDB, …)• Package (BIND, COPY, …)• Plan (BIND, EXECUTE)• Routine (EXECUTE on function, EXECUTE on procedure)• Schema (CREATEIN, ALTERIN, DROPIN)• System (ARCHIVE, BINDADD, BSDS, CREATEALIAS,

CREATEDBA, …)• Table and view (SELECT, INSERT, UPDATE, DELETE, INDEX, …)• Usage (USAGE ON SEQUENCE, USAGE ON JAR, …)• Use (USE OF BUFFERPOOL, USE OF TABLESPACE,

USE OF STOGROUP, …) – Implicit through object ownership

What can be authorized? (1 of 2)

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-7. What can be authorized? (2 of 2) CV8317.0

Notes:

This falls into two categories. One category is installation authorities controlled by DSNZPARM settings. Another category is Grantable authorities controlled by use of GRANT and REVOKE statements.


• Authorities– Installation authorities

• Install SYSADM• Install SYSOPR• SECADM

– Grantable authorities• SYSADM• SYSCTRL• SYSOPR• DBADM• DBCTRL• DBMAINT• PACKADM• System DBADM• ACCESSCTRL• DATAACCESS• SQLADM

What can be authorized? (2 of 2)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-8. What do authorities contain? CV8317.0

Notes:

This is only valid if the DSNZPARM SEPARATE_SECURITY is set to NO. This DSNZPARM is presented later in this unit.


Install SYSOPR

What do authorities contain?

SYSOPR

DATAACCESS

PACKADM

ACCESSCTRL

DBMAINTDBCTRL

SYSCTRL

DBADM

SECADM

System DBADM SQLADM

SYSADM

Install SYSADM

Included in SYSCTRL authority

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-9. Install SYSADM and install SYSOPR CV8317.0

Notes:

The key point here is that you want to avoid GRANTing SYSADM. Get that authority from a secondary ID. Otherwise, if a GRANTed SYSADM user leaves your company, you are apt to find them owning many DB2 objects. There is no way to modify ownership except by means of DROP/CREATE which can be extraordinarily painful.

SYSADM System administrator, which includes SYSCTRL, plus access to all data.

SYSADM can:

• Use all the privileges of DBADM over any database

• Use EXECUTE and BIND on any plan or package, COPY on any package

• Use privileges over views that are owned by others

• Set the current SQL ID to any valid value, whether it is currently a primary or secondary authorization ID

• Create and drop synonyms and views for others on any table

• Use any valid value for OWNER in BIND or REBIND


• Can start DSNDB01, DSNDB06 after stopped or in restrictedstatus

• Can run CATMAINT

• SYSADM - Primary authid of main SYSADM• SYSADM2 - Secondary authid for other SYSADMs• Avoid GRANTing SYSADM!

Install SYSADMs and Install SYSOPRs can

• Run with ACCESS(MAINT)• Run all allowable utilities against DSNDB01 or DSNDB06

Install SYSADMs

Suggestion:

Install SYSADM and install SYSOPR

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

• Drop database DSNDB07

• Grant any of the privileges listed above to others

• Holders of SYSADM authority can also drop or alter any DB2 object, except system databases, issue a COMMENT ON or LABEL ON statement for any table or view, and terminate any utility job, but SYSADM cannot specifically grant those privileges.

Install SYSADM One or two IDs are assigned this authority when DB2 is installed. They have all the privileges of SYSADM, plus:

• Authority is not recorded in the DB2 catalog. The catalog need not be available to check installation SYSADM authority. (The authority outside the catalog is crucial: If the catalog table space SYSDBAUT is stopped, for example, DB2 cannot check the authority to start it again. Only an installation SYSADM can start it.)

• No ID can revoke this authority; it can be removed only by changing the module that contains the subsystem initialization parameters (typically DSNZPARM). Those IDs can also:

- Access DB2 when the subsystem is started with ACCESS(MAINT)

- Start databases DSNDB01 and DSNDB06 when those are stopped or in restricted status

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-10. Separation of duties CV8317.0

Notes:

DSNZPARM SEPARATE_SECURITY, can be used to separate the security authority from system and database administration authority. This DSNZPARM can be set to YES or NO. The default value is NO.

If SEPARATE_SECURITY is NO (the default), the install SYSADM and SYSADM authorities implicitly have the SECADM authority and can continue to manage all security objects and grant and revoke privileges granted by others. Additionally, the SYSADM authority manages security objects, including the row-level and column-level access control.

Users with SYSCTRL authority implicitly have ACCESSCTRL authority and can continue to perform security-related tasks with no authority to access user data. Additionally, SYSCTRL can manage roles and can set the BIND OWNER to any value, provided the specified owner qualifies for the data access privilege that is required by the SQL DML statements contained in the package.

In the above visual on the left hand side, SECADM and ACCESSCTRL are not separated from SYSADM, including those of the DBADM and DATAACCESS authorities.


Separation of duties

DSNZPARM SEPARATE_SECURITY

SYSCTRL

SYSADM

System DBADM

DATAACCESS

SECADM

ACCESSCTRL

NO

SYSCTRLSYSADM

System DBADM

DATAACCESS

YES

SECADM

ACCESSCTRL

Authority implicitly held

NOTE: Install SYSADM always includes SECADMindependently of the setting ofSEPARATE_SECURITY

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

After the SEPARATE_SECURITY system parameter is set to YES, the SYSADM authority cannot manage security objects, or grant and revoke privileges. The SYSCTRL authority does not have the ability to manage roles either. From this point, the SECADM authorization grants and revokes privileges and manages these objects instead. SYSADM or SYSCTRL cannot perform grants to revoke privileges granted by others. Existing privileges granted by SYSADM and SYSCTRL are left intact. A user with ACCESSCTRL or SECADM authority is required to revoke any of these privileges.

In the above visual on the right hand side, SECADM and ACCESSCTRL separated from SYSADM, illustrates the separation of security administrative duties from the SYSADM authorities when DB2 is configured with DSNZPARM SEPARATE_SECURITY set to YES. In this scenario, the security administration authority SECADM is separated from SYSADM. The SYSADM authority loses the power to execute the privileges held by the SECADM and ACCESSCTRL authorities.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-11. Where is authorization information kept? CV8317.0

Notes:

We recommend that you become thoroughly familiar with these catalog tables. Refer to the catalog appendix in the SQL Reference. Not all of the columns are listed in the visual above. This is just an abbreviation of the authorization information kept in the DB2 catalog.

It is important to minimize the use of the WITH GRANT OPTION on GRANT statements. Evidence for its use is easily found in the catalog by looking for "G" in the appropriate columns.

All DB2 security information is maintained in the catalog, with the major exception of the Install SYSADM, SECADM, and Install SYSOPR IDs (which reside in DSNZPARM).


Many additional columns

indicate command privileges

and create privileges

Tablename inDB2 Catalog

SYSUSERAUTHSystem privileges

ColumnnameSYSADMAUTHSYSCTRLAUTHSYSOPERAUTHBINDADDAUTHBINDAGENTAUTH

Remarks

SYSDBAUTHDatabase privileges

SYSRESAUTHResource privileges

SYSTABAUTHTable privileges

SYSCOLAUTH

SYSPLANAUTHPlan privileges

SYSPACKAUTHPackage privileges

DBADMAUTHDBCTRLAUTHDBMAINTAUTH

OBTYPE

DELETEAUTHINSERTAUTHSELECTAUTHUPDATEAUTH

COLNAME

BINDAUTHEXECUTEAUTH

BINDAUTHEXECUTEAUTHCOPYAUTH

Additional columns indicatecreate TS, create Table,Utility and command privileges

B - buffer pool; S - stogroup;R - table space; C - collectionD - distinct type

Additional columns indicateother table and viewprivileges

For column update

SYSSCHEMAAUTHSchema privileges

CREATEINAUTHALTERINAUTHDROPINAUTH

SYSROUTINEAUTHRoutine privileges

ROUTINETYPEEXECUTEAUTH

EXECUTE authority on UDFs,functions and stored procedures

xxxAUTH cols contain:• Y if privilege held• G if GRANTable

Where is authorization information kept?

SYSSEQUENCEAUTHSequence privileges

USEAUTH

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-12. Which ID is checked? CV8317.0

Notes:

Sometimes we use the primary ID to verify authorization, sometimes one (or more) IDs in the composite set, and sometimes the current SQLID. The ID we use depends on the operation we were doing.


?• Primary authid:

– Accounting and Audit Records– Default Owner for BIND

• Composite list (any ID used):– Utility Execution – Plan Execution – Dynamic DML – Commands

• Current SQLID (not used for static SQL):– Default owner for created objects (DDL) – Default qualifier for table or view name (DML) – The GRANTOR authid for GRANT and REVOKE

Which ID is checked?

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-13. How do you acquire authority? CV8317.0

Notes:

In DB2, you cannot do anything without authorization, and that authorization has to come from somewhere. Initially, it all comes from Install SYSADMs and Install SYSOPRs. A SYSADM might GRANT authorization to a very few secondary IDs that will be used to spread other authorization. Other secondary IDs will be production secondaries that actually do the work.


• GRANT by authid (could be secondary ID)holding privilege on the object

– CURRENT SQLID (using dynamic SQL)– PLAN OWNER (using static SQL)

Minimize use of WITH GRANT OPTION

• Owning an object– Can GRANT to PUBLIC

• Initially, by Install SYSADM or SECADM

How do you acquire authority?

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-14. Granting privileges CV8317.0

Notes:

A DB2 GRANT statement gives a specific privilege to an authorization ID. A process which is connected to DB2 and has several authorization IDs will be able to use the privileges granted to each one of those.

Depending on the type of activity, DB2 will look at either:

1. All composite privileges in the list, or

2. Only at the privileges granted to your CURRENT SQLID.


PAYROLL

ACCNTG

MANUF

TSOUDxx GRANT SELECT ON TABLE TABLE1TO TSOUDxx

GRANT BIND ON PACKAGE COLL1.PKG1 TO PAYROLL

GRANT SELECTON TABLE ACCNTG1TO ACCNTG

GRANT CREATETAB, LOADON DATABASE DBMANUFTO MANUF WITH GRANT OPTION

Primary Authorization ID

Secondary Authorization IDs

Granting privileges

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-15. Privileges example CV8317.0

Notes:

The visual shows privileges required to create a table.


GRANT CREATETABON DATABASE DB11 TO TSOUDxx

GRANT USE OF TABLESPACEDB11.TS0001TO TSOUDxx

CREATE TABLE T_ORDER(...)IN DB11.TS0001

DB11

TS0001T_ORDER

Database Privileges

Resource Privileges

SYSIBM.SYSDBAUTH

GRANTOR GRANTEE NAME OBTYPE QUALIFIER ...

DBADM1 TSOUDxx TS0001 R DB11

SYSIBM.SYSRESAUTH

DBADM1 Issues:

TSOUDxx Issues:

Privileges example

GRANTOR GRANTEE NAME CREATETABAUTH ...

DBADM1 TSOUDxx DB11 Y

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-16. How do you control it? CV8317.0

Notes:

With secondary IDs, individuals have no GRANTs done to their primary authorization ID, which is exactly what we recommend. The user can be disconnected from the group when that particular authorization is no longer required.

If you GRANT something, then you can also take it away.

SYSADMs and SYSCTRLs can REVOKE anything that can be revoked.

If an object is DROPped, then all GRANTs associated with it go away.

Be careful of this one: If you omit RETAIN on BIND PLAN ... REPLACE then all GRANTs to the plan go away. That is the default.


Losing Authority

• SYSADM, SECADM, SYSCTRL, or ACCESSCTRL revokes

• Object is DROPped or FREEd

• RETAIN is omitted on BIND PLAN ... REPLACE

• Grantor REVOKEs

• Disconnected from RACF Group

How do you control it?

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-17. Revoking privileges CV8317.0

Notes:

When revoking privileges, beware of the cascade effect, especially if the ID involved has granted a lot of privileges with the WITH GRANT OPTION.

Avoid using the WITH GRANT OPTION whenever possible.

In DB2 10, cascading revokes may be disabled by DSNZPARM parameter REVOKE_DEP_PRIVILEGES and SQL clause NOT INCLUDING DEPENDENT PRIVILEGES in the REVOKE statement.


SYSADM / SYSCTRL /SECADM / ACCESSCTRL only

GRANT SELECT TO BWITH GRANT OPTION

GRANT SELECT TO CWITH GRANT OPTION SELECT

A B C

REVOKE SELECTFROM B SELECT SELECT

A B C

Revoking privileges

• REVOKE privileges ON resource FROM authid (BY authid)– REVOKE must be issued with GRANTOR’s CURRENT SQLID– REVOKE SELECT can DROP VIEWS– Timestamp-based cascading effect

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-18. CREATE privileges CV8317.0

Notes:

Some authorities apply to objects that already exist, others to objects that do not exist. If the authority applies to an existing object, and the object is DROPped, then the authority is lost.

• CREATEDBA – Grants the privilege to issue the CREATE DATABASE statement and acquire DBADM authority over those databases.

• CREATEDBC – Grants the privilege to issue the CREATE DATABASE statement and acquire DBCTRL authority over those databases.

• CREATESG – Grants the privilege to create new storage groups.

• BINDADD – Grants the privilege to create plans and packages.


CREATEDBACREATEDBCCREATESGCREATETS

CREATETABBINDADD

Versus

DBADMDBCTRLDBMAINT

and other privileges

• Create privileges are grantedbefore the object exists

• When the object is created:– The CURRENT SQLID

becomes the owner *– Privileges of ownership

cannot be revoked– Owner automatically has

GRANT authority

• Granted on existing objects

• The authority or privilege remains until revoked or untilthe object no longer exists

• Can GRANT authority and privilege only if authority orprivilege is heldWITH GRANT OPTION

CREATE privileges

* The authorization ID using CREATE DATABASE onlyreceives DBCTRL if the original authority was CREATEDBC.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-19. Example - ownership of a table CV8317.0

Notes:

You create DB2 objects, except for plans and packages, by issuing SQL CREATE statements in which you name the object. When you create the object, you establish its ownership and the owner implicitly holds certain privileges over it.

The visual lists, by way of example, the privileges held implicitly by the owner of a table.


Example - ownership of a table

• Implicit privileges:– Alter / drop:

• Table or any of its indexes – Lock the table, comment on it, or label it– Create an index or view – SELECT, UPDATE, DELETE, or INSERT – Use the LOAD utility – Define referential constraints – Define a trigger

• Privileges implicit in ownership cannot be revoked• Ownership cannot be changed• Owner can GRANT explicit privileges

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-20. Establishing ownership CV8317.0

Notes:

UNQUALIFIED

If you issue a CREATE statement dynamically, and if the name of the table, view, index, alias, or synonym you are creating is unqualified, then the owner of the created object is your CURRENT SQLID. This CURRENT SQLID must have the privileges needed to create the object. CURRENT SCHEMA content is used to qualify unqualified object references (it has the schema name).

QUALIFIED

If you issue a CREATE statement dynamically, and if the name of the table, view, index, or alias you are creating is qualified, then the owner of the created object is the qualifier you specify.

If you have no administrative authority, this qualifier must be your primary authid or one of your secondary authids.

If you have no administrative authority, this qualifier must have the CREATETAB privilege implicitly or explicitly for the database specified by the IN clause.


Establishing ownership

• CREATE TABLE– DYNAMIC SQL

• TABLE with unqualified name– CURRENT SQLID:

> Becomes OWNER> Must have privileges needed to create table> Recorded in OWNER column in SYSTABLES> CREATOR column in SYSTABLES has the SCHEMA of the table > SCHEMA is same as CURRENT SQLID, unless SET SCHEMA is issued

specifying a different value – Primary Authid:

> Recorded in CREATEDBY column in SYSTABLES• TABLE with qualified name

– QUALIFIER:> Must have privileges needed to create table > Becomes OWNER> Must be your primary authid or one of your sec authids> Can use any qualifier if current SQLID has at least DBCTRL

– Primary Authid:> Recorded in CREATEDBY column in SYSTABLES

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

If your CURRENT SQLID has at least DBCTRL authority, you can use any qualifier for a table or an index.

To specify any qualifier when creating a view or a MQT, you need SYSADM or DBADM, depending on the setting of DSNZPARM DBACRVW.

To specify any qualifier when creating an alias, you need SYSCTRL or DBCTRL, depending on the setting of DSNZPARM DBACRVW.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-21. Ownership examples CV8317.0

Notes:

The visual shows some examples of establishing ownership in DB2.

In catalog table SYSDATABASE, column CREATOR contains the authorization ID of the owner of the database and column CREATEDBY contains the primary authorization ID of the user who created the database. Column OWNER is not present in this table.

In catalog table SYSTABLESPACE, column CREATOR contains the authorization ID of the owner of the table space and column CREATEDBY contains the primary authorization ID of the user who created the table space. Column OWNER is not present in this table.

In catalog table SYSTABLES, column CREATOR contains the schema of the table, column CREATEDBY contains the primary authorization ID of the user who created the table, and column OWNER contains the authorization ID of the owner of the table.


1. LOGON(USER01)...(CENSUS)

PRIMARY ID SECONDARY ID 2. SET CURRENT SQLID=’CENSUS’;--has CREATEDBA3. SET CURRENT SCHEMA=’RAVI’4. CREATE DATABASE DB01;5. CREATE TABLESPACE TBSP01 IN DB01;6. CREATE TABLE TAB01 IN DB01.TBSP01;7. CREATE TABLE USER03.TABLEX IN DB01.TBSP01;

--Note different qualifier –

RESULTS IN CATALOG TABLE ENTRIES:

Auth IDsestablished by

EXIT ROUTINE

SYSDATABASESYSTABLESPACESYSTABLES

SYSDBAUTHSYSTABAUTH

4,5

7

Ownership examples

USER03USER01USER03CENSUSUSER01RAVIN/AUSER01CENSUS

OWNERCREATEDBYCREATOR

USER03USER03

CENSUSCENSUS

CENSUSCENSUS

GRANTEEGRANTOR

6

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-22. Checking authorization to execute CV8317.0

Notes:

GRANT and REVOKE

For a GRANT issued dynamically, the CURRENT SQLID is checked for:

• The privilege with the grant option, or

• An authority that includes the privilege with the grant option, or

• Ownership that implicitly includes the privilege.

For a REVOKE issued dynamically, the CURRENT SQLID:

• Must have granted the privilege that is being revoked, or

• Hold SYSCTRL or SYSADM authority


PAYROLL

ACCNTG

MANUF

TSOUDxxGRANT SELECTON TABLEA.TABLE1 TO TSOUDxx

GRANT ALLON TABLEA.TABLE2 TO PAYROLL

SELECT * FROMA.TABLE1,A.TABLE2

SELECT * FROMA.TABLE1,PAYROLL.TABLE3

Both SELECTs are valid In dynamicSQL in, say, SPUFI bound withDYNAMICRULES (RUN)

Primary Authorization ID

SecondaryAuthorization IDs

Checking authorization to execute• DYNAMIC SQL

– GRANT / REVOKE• Current SQLID is checked for required privileges

– CREATE• Current SQLID is checked for required privileges

– Other SQL• Composite Privileges checked for required privileges

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Composite privileges

An SQL statement can name more than one object. For example, a SELECT can join two or more tables. An INSERT can use a subquery. These operations require privileges on all the tables.

With DYNAMICRULES (RUN), you can issue such a statement dynamically, even if one of your authids alone does not have all the required privileges.

The statement is validated if your primary authid and all your secondary authids have all the necessary privileges among them.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-23. Controlling access for dynamic DML CV8317.0

Notes:

We have already seen some of the considerations for controlling dynamic DDL, now we examine DML (SELECT, INSERT, UPDATE, DELETE). As always, SYSADMs can do anything that can be done. Ownership has privileges. And then again, specific table privileges are GRANTable.

Ordinarily, current SQLID is used to check authorization and to act as the qualifier on table names for DDL and as GRANTEE on GRANT and REVOKE.

DYNAMICRULES (BIND) is a BIND option that causes DB2 to check the authorization of the PLAN OWNER, rather than the user for dynamic SQL. That is, dynamic SQL authorization checking behaves like that for static SQL. With this option, dynamic DDL and GRANT/REVOKE are not allowed. Nor is SET CURRENT SQLID.


Dynamic DML requires an ID in the compositelist to have one of the following:

DYNAMICRULES Option on BIND

• SYSADM, DBADM, or DATAACCESS authority or• Ownership of Table or View or• Specific table privileges:

SELECTINSERTUPDATEDELETE

• RUN: Use composite privileges• BIND: Use OWNER for authid checking:

Dynamic DDL, GRANT, REVOKE not allowedSET CURRENT SQLID not allowed

Controlling access for dynamic DML

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-24. Controlling access for static SQL CV8317.0

Notes:

RACF can prevent execution of a load module, which is similar to not GRANTing EXECUTE authority to a plan.

Many shops GRANT access to a plan to PUBLIC and then handle the real security checking from a transaction manager. But do not leave the back door open and allow such a transaction to run (illicitly) in, perhaps, batch: BIND with the ENABLE or DISABLE keyword.


CICS and IMS

TSO and BATCH

BIND keywords can control the execution environment:

• Usually requires (non-public) DB2 Authorization List• Could control access to program library with RACF

• Transaction manager controls use of transaction code• Could GRANT EXECUTE ON PLAN...TO PUBLIC• CICS AUTHTYPE parm controls SIGNON and DB2 accounting

• ENABLE / DISABLE controls connections:– Connection-ID (IMS,IMSBATCH,BATCH,DB2CALL,REMOTE ...)– By subsystem (specific imsids or CICS applids ...)

Controlling access for static SQL

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 8-25. Authorizations for BIND (overview) CV8317.0

Notes:

Causing a BIND to succeed is not a trivial thing. Many authorizations are required. The distinction between BIND and BINDADD is important. BINDADD lets you do anything BIND permits, but it also lets you add new plans and packages.

Note that there is an install parameter set on panel DSNTIPP called BIND NEW PACKAGE that controls whether BIND or BINDADD authority is required to BIND a new version of an existing package. The default, BINDADD, only allows users with BINDADD to create a new package. BIND allows users with only BIND authority to create new versions of packages. This also affects users with PACKADM authority.

With BINDAGENT and PACKADM you can separate owners of plans (say production control) from owners of packages (perhaps programmers).

PACKADM grants package administration authority for the designated collections.

BINDAGENT grants the privilege to BIND, FREE PACKAGE, REBIND, and DROP PACKAGE.

At thread creation time, the plan is allocated if all security checks are in place.


BIND PACKAGE loc.collection-id ACTION( )

Package Owner has- CREATE IN Collection-id

and- BINDADD if (ADD) or- BIND if (REPLACE) or- PACKADM or BINDAGENT

BIND PLAN ACTION()

Plan Owner has- BIND if (REPLACE)- BINDADD if (ADD)- BINDAGENT

PACKAGE

PLAN

PKLIST (...)

Plan OwnerhasEXECUTE onlocal/remotePackages

COPY coll.pkg-id

Package Owner has- COPY on Package

andAuthorization for allstatic SQL

- OR -

MEMBER(dbrm)

Package Owner hasauthorization forall static SQL

DBRMLIB

PGMC ...

Authorizations for BIND (overview)

CREATE THREAD/SIGNON

Some Authid of Userhas EXECUTE on PlanAnd Connection andConnection-id Enabledfor Plan and Package

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 8-26. DB2 authorization summary CV8317.0

Notes:

CREATE VIEW ... WITH CHECK OPTION and table check constraints are another type of security, or more properly, ways of guaranteeing data integrity by forcing data to stay within certain bounds.

Then again, by only allowing people to see some of the data because of a limiting view, you prevent them from seeing sensitive fields.


Security implementation requires planning

• Establish DB2 authorization guidelines:– Who will own your objects? – Functional or individual authids? – RACF supplies group names or hard-coded in exits?

• Establish DB2 authorization procedures:– Grant (WITH GRANT OPTION) / revoke – Use of other DB2 options:

• View (With Check Option)• Table check constraints • CREATE TABLE ... WITH RESTRICT ON DROP• Encoding via Editproc/Fieldproc• Erase Yes option on table space

• Use AUDIT TRACE to monitor GRANTs and REVOKEs

DB2 authorization summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.


Notes:


Having completed this unit, you should be able to:• Describe DB2 global security • Describe the various DB2 authids and how they are

established• Understand how DB2 security controls access to data • Describe and implement DB2 privileges and authorities

appropriately• Describe how ownership is established in DB2 • Describe DB2 authorization checking • Describe and implement security for plans and packages

Unit summary

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Unit 9. Serialization


This unit is about basic serialization mechanisms and their objectives.



• Describe concurrency • Explain the aspects of transaction locks • Tell when locks are acquired and released • Describe S and X locks • Explain isolation levels • Explain LOCKSIZE


Accountability:


References

SC19-2978 DB2 10 for z/OS Managing Performance

SC18-9851 DB2 Version 9.1 for z/OS Performance Monitoring and Tuning Guide


xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Unit 9. Serialization 9-1

Student Notebook

.


Notes:


After completing this unit, you should be able to:• Describe concurrency• Explain the aspects of transaction locks • Tell when locks are acquired and released • Describe S and X locks • Explain isolation levels • Explain LOCKSIZE

After completing this unit, you should be able to:• Describe concurrency• Explain the aspects of transaction locks • Tell when locks are acquired and released • Describe S and X locks • Explain isolation levels • Explain LOCKSIZE

Unit objectives

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-2. Why does DB2 have serialization mechanisms? CV8317.0

Notes:

Why does DB2 have serialization mechanisms?

Without these serialization mechanisms, data integrity would be lost as illustrated by these examples.

Lost updates

Two applications, Prog-1 and Prog-2, might both read the same row from a table and both calculate new values for one of its columns based on the data these applications read. If Prog-1 updates the row with its new value and Prog-2 then also updates the row, the update performed by Prog-1 is lost.

Access to uncommitted data

Prog-1 might update a value in a table and Prog-2 might read that value before it is committed. Then, if the value of Prog-1 is rolled back the calculations performed by Prog-2 are based on uncommitted and, presumably, invalid data.


Lost Updates

Prog-1 Acct Prog-2

Read Acct

Acct = Acct + 10

Change Acct

Read Acct

Acct =Acct + 20

Change Acct

100

110120

Read Uncommitted Data

Read Acct

Acct = Acct + 300

Change Acct

Rollback

Read Acct

IF Acct > 0Then ....

-100

200

-100

Prog-1 Acct Prog-2

DB2 providesWrite Integrity

DB2 providesRead Integrity

Why does DB2 have serialization mechanisms?• What might happen without serialization mechanisms?

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

There are other possible problems (not illustrated) that could occur without serialization mechanisms.

Non-repeatable reads

Application A reads a row from a table and then goes on to process other SQL. In the meantime, application B either modifies or deletes the same row and commits its change. If application A then attempts to read the original row again it will see the modified row or discover that the original row has been deleted.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-3. DB2 serialization mechanisms CV8317.0

Notes:

DB2 serialization mechanisms

DB2 has a number of different serialization mechanisms which can be used to:

• Prevent loss of data integrity and

• Maximize concurrency and

• Minimize cost in CPU, I/O and storage resources.

They are:

1. Transaction locking

In this topic we shall be looking primarily at transaction locking.

2. Restricted states

For example, STOP, START UT, CHKP, UTUT, UTRO, UTRW...

Restricted states can be set on DB2 objects by a DB2 utility or a DB2 command.


DB2 serialization mechanisms

• DB2 has several serialization mechanisms:– Transaction locking

• Applies to all SQL statements, wherever they are(batch, distributed applications, etc.)

– Restricted states• STOP, START UT, CHKP, UTUT, UTRO, UTRW...

– Claims and drains– Latching

• These mechanisms should be used to:– Protect data integrity– Maximize concurrency and– Minimize costs

• CPU, I/O and storage• In this topic we shall be looking at

transaction locking.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

3. Claims and drains

Claims and drains enable DB2 utilities and commands to take over access to some objects independently of any transaction locks held on the objects.

4. Latching

The structure of a page may be inconsistent while changes (inserts, updates) are being made. During this time a page latch is used to prevent access to the page.

Concurrency

Concurrency refers to the sharing of resources by multiple users or application programs at essentially the same time.

This access is controlled by DB2’s serialization mechanisms which prevent the undesirable effects discussed above.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-4. What gets locked? CV8317.0

Notes:

What gets locked?

User data

The data you target with SQL gets locked (although there are exceptions). You have the most control over these locks.

Additionally, the data in related tables may get locked. For example, if you delete a row from a parent table DB2 might delete rows from a dependent table as well. In this case, DB2 locks data in the dependent table as well as in the parent table.

Note

Indexes on user tables are not locked by transaction locks.


What gets locked?

• User data – The data you target with SQL

• Some exceptions• You have the most control here

– The data in tables related by RI• Catalog / directory

– Subject to update activity• CREATE, ALTER, DROP, GRANT, REVOKE• BIND, REBIND and FREE

– Designed to minimize contention• Note:

– Indexes on user tables are not locked by transaction locks

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

DB2 subsystem objects

The DB2 Catalog and directory are subject to update activity that must be serialized.

Although the catalog and directory are designed to minimize contention among application processes, you need to be aware of some of the user activities that cause locking in these objects.

• CREATE, ALTER, DROP, GRANT, and REVOKE

• BIND, REBIND, and FREE

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-5. Main characteristics of transaction locking CV8317.0

Notes:

The main characteristics of transaction locking are:

• Size of the lock

• Mode of the lock

• Duration of the lock

Knowing the characteristics helps you understand why a process suspends or times out or why two processes deadlock.

We shall be considering each of these in the following pages.


Main characteristics of transaction locking

• Size – How much data is locked?

• Mode– Does the lock allow others to read and/or update the locked object?

• Duration– How long is the lock held?

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-6. Size of transaction locks CV8317.0

Notes:

Size of transaction locks

The same piece of data can be controlled by locks of different sizes. A table space lock (the largest size) controls the most data, all the data in an entire table space. A page or row lock controls only the data in a single page or row.

CREATE TABLESPACE and ALTER TABLESPACE have the LOCKSIZE option. The choices are ANY (default), ROW, PAGE, TABLE, or TABLESPACE.

ANY

ANY permits DB2 to make the final choice and DB2 favours page locking as a good compromise between high concurrency and high CPU consumption.

DB2 has the option to use table or table-space level or even row locking as an alternative depending on the SQL.



Table space lock

Table lock

Row lock Page lock

Partitioned and Universal table space

Partition lock

Row lock Page lock

Size of transaction locks

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

LOCK TABLE

The explicit SQL statement LOCK TABLE is another option.

The SHARE and EXCLUSIVE options make the table read-only or give exclusive ownership of the table to a single process respectively.

Lock hierarchy

In a segmented table space, for example, if DB2 decides to lock a data row, then according to the locking hierarchy, DB2 locks the table space and the table before locking the row.

In a simple table space, if DB2 decides to lock a data row, then according to the locking hierarchy, DB2 locks the table space before locking the row.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-7. Concurrency versus CPU overhead CV8317.0

Notes:

Concurrency versus CPU overhead

Your choice of lock size represents a trade-off between concurrency and CPU overhead.

For example, row locking may increase the use of available CPU resources. No I/O operations are done, but each lock request requires two-way communication between DB2 and the internal resource lock manager (IRLM).


Contention problemsCPU consumption

High

LowTable space Table Page Row

Locksize

Concurrency versus CPU overhead

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-8. Two locking strategies CV8317.0

Notes:

Strategy 1

DB2 locks only the table.

In this case, all rows in the table will be affected to the same degree.

Strategy 2

DB2 locks the table and the underlying pages or rows.

Note

Only for segmented table spaces does table locking occur. For simple table spaces, locks are taken at the table space level and possibly pages / rows. For partitioned and universal table spaces, locks are taken at the partition level and possibly pages / rows.


OR

Table Table

Table Space

Page(s)or

Row(s)

Two locking strategies

• Segmented table space example

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-9. Page or row locks CV8317.0

Notes:

Page or row lock mode

Share (S)

The lock owner and any concurrent process can read, but not change, the locked page or row.

Concurrent processes may acquire S- or U-lock on a page or row, or might read the data without acquiring a page or row lock.

Update (U)

The lock owner can read, but not change, the locked page or row. However, the owner can promote the U-lock to an X-lock and then change the page or row. Promotion to X-lock may cause a suspension if concurrent processes hold S-locks.

U-locks reduce the chance of deadlocks when the lock owner is reading data to determine whether to change it.


Page or row locks

• Page / row lock modes of S, U and X– Share (S)

• Lock owner and others can read but not update– Update (U)

• Lock owner can read but not update • Others may hold S• Owner can promote U to X

– May cause a suspension if others hold S• Reduces deadlocks

– Exclusive (X)• Only lock owner can read or update• Others can read with UR (see later)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Exclusive (X)

Only the lock owner can read or change the locked page or row. A concurrent process can access the data only if the process runs with uncommitted read isolation.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-10. Lock mode compatibility CV8317.0

Notes:

The visual shows whether page locks of any two modes, or row locks of any two modes are compatible.

For example, USERA is holding an S lock on a page and USERB requests an X lock on the same page. The lock mode of USERA does not permit the request from USERB because the two lock modes S and X are not compatible.

Note

Within a table space you cannot use both page and row locks at the same time.


S U X

S Yes Yes No

U Yes No No

X No No No

Requested LockHeldLock

Lock mode compatibility

• Page or row locks

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-11. Table, table space and partition locks CV8317.0

Notes:

At the table, table space or partition level, you can expect to see IS, IX, SIX, S, U or X locks. We shall discuss each one of these in a moment.

For now, we shall observe that these locks fall into two categories:

1. IS, IX or SIX, sometimes known as intent lock mode2. S, U or X, sometimes known as gross lock mode

IS, IX or SIX (Intent lock mode)

In the visual, User 1 has an IS intent lock at the table level and additionally S locks at the page or row level.

The intent lock is like a warning light that shows other concurrent transactions what type of access the underlying pages or rows are undergoing.

The Intent lock also regulates the type of locks taken on the underlying pages or rows.

S, U or X (Gross lock mode)

In the visual, User 2 attempts to take an X gross lock at the table level.


User 1 uses strategy 2 lockingExample: SELECT . . .

Assume LOCKSIZE PAGE or ROW

Pageor

row

Pageor

row

Pageor

row

Pageor

row

Pageor

row

Table / table space / partition

SSSS

IS

User 2 uses strategy 1 lockingExample:LOCK TABLE . . . IN EXCLUSIVE MODE X

Table, table space and partition locks

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-12. More about table, table space and partition locks CV8317.0

Notes:

1. IS, IX or SIX (Intent lock mode)

Intent share (IS)

The lock owner can read data in the table, table space or partition but not change it.

The lock owner acquires S-locks on pages or rows accessed.

Concurrent processes may both read and change data.

Intent exclusive (IX)

The lock owner and concurrent processes can read and change data in the table, table space or partition.

The lock owner acquires X locks on pages or rows changed. The lock owner is also eligible to read pages or rows and acquires S locks on pages or rows read. The lock owner is also eligible to read pages or rows with update intent and acquires U locks on these pages or rows. When a page or row is changed then the U lock is promoted to an X lock.


More about table, table space and partition locks

• IS, IX or SIX (Intent lock mode)– Intent share (IS)– Intent exclusive (IX)– Share with intent exclusive (SIX)

• S, U or X (Gross lock mode)– Share (S)– Update (U)– Exclusive (X)

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Share with intent exclusive (SIX)

SIX is actually a hybrid state. From a read perspective it is a gross lock and from a write perspective it is an intent lock.

The lock owner can read and change data in the table, table space or partition.

Concurrent processes can read data in the table, table space or partition but not change it.

Only when the lock owner changes data, is the X lock acquired on a page or row.

2. S, U or X (Gross lock mode)

Share (S)

The lock owner and concurrent processes can read, but not change, data in the table or table space.

There is no need for S-lock on a page or row.

Update (U)

The lock owner can read, but not change, the locked data. However, the owner can promote the U-lock to an X-lock and then change the data.

Processes concurrent with the U-lock can acquire S-locks and read the data, but no concurrent process can acquire a U-lock.

The lock owner does not need page or row locks.

U-locks reduce the chance of deadlocks when the lock owner is reading data to determine whether to change it.

Exclusive (X)

The lock owner may read and change data in the table space or table.

Only the concurrent processes using uncommitted read isolation (see later) may access the table space or table.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-13. Lock mode compatibility CV8317.0

Notes:

The visual shows whether or not table / table space / partition locks of any two modes are compatible.


IS IX S U SIX X

IS Yes Yes Yes Yes Yes No

IX Yes Yes No No No No

S Yes No Yes Yes No No

U Yes No Yes No No No

SIX Yes No No No No No

X No No No No No No

Requested LockHeldLock

Lock mode compatibility

• Table, table space and partition locks

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-14. Isolation levels CV8317.0

Notes:

You have control over the extent to which your SELECT is isolated from the possible effects of other concurrent processes.

You do this by specifying an ISOLATION LEVEL for your SELECT. This is coded on the individual SELECT statement or specified as a BIND option for the entire package.

You have a choice of 4 options: Cursor Stability (CS), Repeatable Read (RR), Read Stability (RS) or Uncommitted Read (UR).


I don't want EMPLOYEE to change during processing the inner and outer query

SELECT * FROM EMPLOYEEWHERE SALARY >(SELECT AVG (SALARY) FROM EMPLOYEE)WITH RR

• Use ISOLATION RR

I just need an approximate

average salary as quickly as possible

SELECT AVG (SALARY) FROM EMPLOYEEWITH UR

• Use ISOLATION UR

I want only committed data, possibly avoiding locking overheads and with minimal impact on

other users

• Use ISOLATION CS

User 1

User 2 User 3

Isolation levels

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Cursor Stability (CS)

DECLARE C1 CURSOR FORSELECT COLA,COLB,....FROM TABLEXWITH CS

OPEN C1

FETCH C1 INTO :HVCOLA,....FETCH C1 INTO :HVCOLA,.........CLOSE C1

User 1 does not want to read uncommitted data.

As user 1 issues each FETCH, If the row or page he wants is already X locked by someone else then DB2 will wait to take an S lock. This S lock is subsequently released as soon as subsequent FETCHes cause DB2 to move off this page or row onto another one.

As user 1 issues each FETCH, If the row or page wanted is not already X locked by someone else then DB2 will avoid taking an S lock. This avoids some locking overhead and reduces the impact user 1 might have had on follow-on updaters. But if user 1 attempts to re-read data in the same unit of work he may find he does not get the same result set.

If the above DECLARE had specified FOR UPDATE OF then DB2 would have taken U locks instead of S locks. U locks are also released as soon as subsequent FETCHes cause DB2 to move off the page or row onto another one.

Note

DB2 never practises lock avoidance with U locks.

Repeatable Read (RR)

A row or page S lock is held for all accessed rows, qualifying or not, at least until the next commit point.

For the non-correlated subquery shown, the inner query executes first and the result feeds into the outer query.

User 2 does not want EMPLOYEE to change between processing the inner query and the outer query. This can be achieved with repeatable read.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Note

DB2 never practises lock avoidance with repeatable read.

Read Stability (RS)

A row or page lock is held only for qualifying rows or pages that are returned to an application at least until the next commit point.

RS can offer more concurrency than RR because, although other applications cannot change any of the qualifying rows returned to the original application, they can insert new rows or update rows that did not satisfy the original application’s search criteria.

For example, suppose your application reads a set of rows. Then another application inserts some additional rows that satisfy your application’s query and commits. Your application then repeats the original query within the same unit of work and the additional rows are returned as part of the result set.

Uncommitted Read (UR)

User 3 acquires no page or row locks.

Advantages:

• Less overhead

• Any updaters in the system do not cause lock waits to user 3.

• User 3 does not cause lock waits to any updaters.

Considerations:

• User 3 is at risk from reading uncommitted data.

• A moving row may be counted twice or not at all.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-15. SKIP LOCKED DATA CV8317.0

Notes:

DB2 transaction locking:

• DB2 locking allows inter-process concurrency and avoids data integrity problems

• A transaction is suspended when it requests a lock that is already held by another transaction and that lock cannot be shared

• The locking mechanism worsens application performance where the user only wants to see available and committed data

SKIP LOCKED DATA is designed to allow a transaction to silently skip rows locked by other transactions. When processing a SELECT, UPDATE or DELETE request, if a row is incompatibly locked by another transaction, then the attempt to lock that row is given up and the row is skipped. No error is returned. Instead, the transaction is resumed so that it can retrieve the next row. With this capability, application’s performance can improve significantly. Unlike isolation UR, application can only see unlocked committed rows.


SKIP LOCKED DATA

• SKIP LOCKED DATA option allows a transaction to skip rows or pages that are incompatibly locked by other transactions

• Can be specified in SELECT, SELECT INTO, Searched UPDATE, Searched DELETE, and PREPARE statements and in UNLOAD utility

• Isolation levels (CS and RS) and lock sizes (Row and Page)

• Lock mode compatibility (same as before)• Example of inconsistent or incomplete resultTable T(C1 INTEGER

C2 CHAR(4))C1 C21 AAAA2 BBBB3 CCCC4 DDDD

Transaction A: UPDATE T SET C1=99 WHERE C1<3Transaction B: SELECT COUNT(*) FROM T

WHERE C2>=‘AAAA’ SKIP LOCKED DATA Assuming no index on C2, returns a value 2

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

To use the SKIP LOCKED DATA option, specify the clause in a SELECT, SELECT INTO, PREPARE, searched UPDATE, or searched DELETE statement. You can also use the SKIP LOCKED DATA option with the UNLOAD utility.

You can use the SKIP LOCKED DATA option with cursor stability (CS) isolation and read stability (RS) isolation. However, you cannot use SKIP LOCKED DATA with uncommitted read (UR) or repeatable read (RR) isolation levels. For UR and RR, DB2 ignores the SKIP LOCKED DATA clause.

The SKIP LOCKED DATA option works only with row locks and page locks. If you specify SKIP LOCKED DATA for a transaction with row level locking, incompatibly locked rows are skipped. If you specify SKIP LOCKED DATA for a transaction with page level locking, all rows on pages with incompatible locks are skipped.

In general, the SKIP LOCKED DATA clause does not apply to table, partition, or table space locks. When LOCKSIZE TABLE or LOCKSIZE TABLESPACE is specified for a table space or when a lock is escalated to a gross table, partition, or table space lock, DB2 ignores the SKIP LOCKED DATA clause.

Lock mode compatibility for transactions that use the SKIP LOCKED DATA option is the same as lock mode compatibility for other page- and row-level locks. However, when incompatible locks are held, a transaction that uses the SKIP LOCKED DATA option does not wait for the locks to be released and skips the locked data instead.

Example: Suppose that transaction A holds an s lock on a row that transaction B also wants to access. The query in transaction B specifies SKIP LOCKED DATA. The outcome of transaction B depends on the mode of lock that it acquires. If transaction B requires a compatible s or u lock, transaction B can access the row on which transaction A holds an s lock. If transaction B requires an incompatible x lock, transaction B cannot access the locked row. Because the SKIP LOCKED DATA option is specified, that row is skipped and the results of transaction B are returned without that row.

With some queries that use the SKIP LOCKED DATA clause, you can receive unexpected or inconsistent results as shown in the example in the above visual.

Example: Suppose that a table T exists in a table space with row-level locking, or in a table space with page-level locking and the rows of the table are distributed across several pages. Assume transaction A issues the update statement.

If transaction B issues the SELECT statement before transaction A commits., and if you do not have an index defined on C2, DB2 returns a count of 2 because DB2 skips the two rows that are locked by the uncommitted UPDATE statement. xc

lusivo

form

ación

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-16. Duration of page and row locks CV8317.0

Notes:

The lock duration shown in the visual above is for page locks. If the LOCKSIZE=ROW, then the duration will be for row locks.

Scenario 1 shows that with CURSOR STABILITY (CS), a page S lock, such as page 1, 2, and 4, is held only long enough to allow the cursor to move to another page. The same is true for U locks. Any X locks caused by an update, such as page 3, are always held until commit. In this situation, any page read can disappear and a new page can appear upon re-read. The user will not get uncommitted data and the user’s changed data will not be seen by others (non UR) until the change is committed. This satisfies the CS requirement.

Scenario 2 shows that with REPEATABLE READ (RR) as well as READ STABILITY (RS) index access, a page S lock is held for all accessed rows, qualifying or not, such as page 1, 2, and 4, until the next commit point. Any X locks, such as page 3, caused by an update, are always held until commit. The index access protects against any new rows to appear and the duration of the S lock (until commit time) protects against a read row from disappearing on re-read. If no index is used to access the data, a gross lock would have to be required to satisfy the semantics of RR.

© Copyright IBM Corporation 2011• Note: With CS, S locks may be avoided as shown by brackets (S)

Program startPlan allocation

Scenario 1Cursor Stability

Scenario 2Repeatable Read and Read Stability

Pg1

(S)

Pg2

(S)

Pg3

X

Pg4

(S)

Pg1

S

Pg2

S

Pg3

X

Pg4

S

FETCH Page 1

FETCH Page 2

UPDATE Page 3

FETCH Page 4

COMMIT

Isolation level:

Duration of page and row locks• Influenced by choice of isolation level

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-17. Duration of table, table space and partition locks CV8317.0

Notes:

BIND options ACQUIRE(USE) and RELEASE(DEALLOCATE / COMMIT) control the point at which the table, table space or partition locks are acquired and released.

ACQUIRE(USE) option

Since ACQUIRE(ALLOCATE) is no longer supported, this option causes the DB2 locks on table, table space or partition to be acquired only when that DB2 object is first accessed.

This option does not affect page or row locks.

RELEASE(DEALLOCATE / COMMIT) option

Generally, these options release the lock when the application ends or at the next commit.

The partition locks on any locked partitions of a partitioned table space are all held for the same duration. That is to say, if one package has been bound with RELEASE(COMMIT) and another package has been bound with RELEASE(DEALLOCATE) then the locks on the locked partitions will be released according to RELEASE(DEALLOCATE).


Use/DeallocateTSA

S

TSB

S

X

TSC

S

Use/Commit

TSA

S

TSB

S

X

TSC

S

Program startPlan allocationSELECT TSA

LOCK TBL TSB

UPDATE TSB

COMMIT

SELECT TSC

COMMIT

Plan deallocation

Acquire:Release:

Duration of table, table space and partition locks

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-18. Lock avoidance CV8317.0

Notes:

Lock avoidance is used for read-only cursors (no FOR UPDATE) defined with isolation level CS if the plan or package containing the cursor is bound with CURRENTDATA(NO).

Lock avoidance applies also to singleton selects (with isolation level CS and CURRENTDATA(NO)).

Lock avoidance does not mean 100% lock avoidance. If the timestamp of the last update from the page header is not older than the start time of all units of recovery updating the table space containing the page, lock avoidance fails and DB2 asks for an S lock as it would have done without lock avoidance.

Lock avoidance failures are normally less than 1% on average under normal conditions.


DB2 knows the row is committed- without acquiring an S lock

TABLEPAGE X

'timestamp' of last update

If 'timestamp' of last update older than start time of any open unit of recovery updating the table space containing page X, all rows on the page are committed.

Applies only to S locksApplies only to isolation level CSNeeds BIND ... CURRENTDATA(NO)

page header

Lock avoidance

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-19. Lock escalation CV8317.0

Notes:

DB2 provides the application developer with the option to dynamically switch from low level locking to high level locking based on the number of low level locks held by the application process. This option is called lock escalation and is controlled by the parameter LOCKMAX of CREATE TABLESPACE and ALTER TABLESPACE. The purpose of lock escalation is to reduce the impact of low level locks, both in terms of CPU and storage, at the possible expense of concurrency. When the number of low level locks exceeds a specified threshold, DB2 attempts to promote the high level intent locks, either IS or IX, to S or X, respectively. If this succeeds, then the low level locks are all released and no more low level locks are requested. The lock promotion request may itself fail if other processes hold incompatible locks, either low or high level, for longer than the timeout period. If the higher level lock cannot be acquired before the timeout value has been reached, then the process times out, all updates are rolled back, and all locks are released.

The flow chart in the above visual describes the lock escalation scenario and how DB2 uses NUMLKTS and LOCKMAX values. By the same token, you can develop an application specific mechanism to control lock escalation by using the NUMLKTS parameter at the system level and LOCKMAX parameter at the table space level.



Table space lock

Table lock

Row lock Page lock

Partitioned and Universal table space

Partition lock

Row lock Page lock

Lock escalation

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

LOCKMAX

The LOCKMAX parameter specifies the maximum number of locks that can be taken on this table space by a single process before lock escalation occurs. LOCKMAX SYSTEM means that the value specified in the NUMLKTS DSNZPARM should dictate the maximum number of locks before escalation occurs for this table space. LOCKMAX 0 specifies that lock escalation should not occur for this table space.

When lock escalation occurs, DB2 requests a single lock at the next higher level in the lock hierarchy of the table space. The lock requested is equal to the most restrictive lock held by the process on the table space. If this lock is acquired, then all of the lower level locks that were held by the process are released. If the higher level lock cannot be acquired before the timeout value has been reached, then the process times out, all updates are rolled back and all locks are released.

There is no locking hierarchy at the table space level for a partitioned table space. The highest level of locking is at the partition level. Therefore, when the LOCKMAX threshold is reached, all partitions on which your process currently holds locks are escalated to a gross lock. Any unlocked partitions that are subsequently accessed will also be locked with a gross partition level lock.

NUMLKTS

the DSNZPARM NUMLKTS corresponds to the field LOCKS PER TABLE (SPACE) on the DB2 installation panel INSTALL DB2 - IRLM PANEL 2 (DSNTIPJ). The acceptable values are 0 to 104857600 and the default is 2000. The value that you specify for this field must be less than the value specified for LOCKS PER USER (NUMLKUS), except when LOCKS PER USER is set to 0. This value becomes the default value (SYSTEM) for the LOCKMAX clause of the SQL statements CREATE TABLESPACE and ALTER TABLESPACE. A value of 0 indicates that there is no limit to the number of page and row locks that a program can acquire.

NUMLKUS

The DSNZPARM NUMLKUS corresponds to field LOCKS PER USER on the DB2 installation panel INSTALL DB2 - IRLM PANEL 2 (DSNTIPJ). It specifies the maximum number of page or row locks that a single application process can hold concurrently on all table spaces. Once that limit is reached, the program that accumulated these locks will terminate with SQLCODE -904.

The maximum includes locks on data pages or rows that the process acquires when it accesses table spaces. The limit applies to all table spaces defined with the LOCKSIZE PAGE, LOCKSIZE ROW, or LOCKSIZE ANY options. The acceptable values are 0 to 104857600 with a default value of 10,000.

A value of 0 means that there is no limit to the number of page and row locks a program can acquire.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-20. Lock escalation example CV8317.0

Notes:

See the above visual for an illustration of the consequences of lock escalation for a partitioned table space. Partitions 1, 4, and 7 contain low level locks acquired by USER 1. Lock escalation is then triggered by USER 1. Note that escalation is tracked at the table space level, and not the partition level, so if the total number of locks on the entire table space exceeds the LOCKMAX value, lock escalation is triggered for all partitions that have been accessed by User 1. After the lock escalation, USER 1 now holds gross S locks on partitions 1, 4, and 7. The low level locks previously held by USER 1 are released.


– Before Escalation

– After Escalation

IS,IS IS IS IS,IS

USER 1USER 2

USER 1 USER 2 USER 1USER 2

S,IS S IS S,IS

USER 1USER 2

USER 1 USER 2 USER 1USER 2

S SS

S

S

SS

SS

SS

S

S

SS

S

SS

Lock escalation example• Partitioned table space with 7 partitions

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-21. COMMIT interval CV8317.0

Notes:

An application process is suspended when it requests a lock that is already held by another application process and cannot be shared. The suspended process temporarily stops running.

The suspended process resumes running when all processes that hold the conflicting lock release it, ideally within 5 seconds.


Table

UPDATEEXCLUSIVE

LOCKSTOP

User 1 User 2

COMMIT interval

SELECT( No UR andNo SKIP LOCKED DATA ).

WAIT.

WAIT.

WAIT.COMMIT Share lock can now be granted

Maxim

um 5 seconds

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Figure 9-22. Timeouts CV8317.0

Notes:

An application process is suspended when it requests a lock that is already held by another application process and cannot be shared. The suspended process temporarily stops running.

The suspended process resumes running when:

• All processes that hold the conflicting lock release it or

• The requesting process times out after a preset interval and the process resumes to deal with an error condition. DB2 issues two messages to the console and returns SQLCODE -911 or -913 to the process.

The DSNZPARM IRLMRWT corresponds to RESOURCE TIMEOUT field on the DB2 installation panel INSTALL DB2 - IRLM PANEL 1 (DSNTIPI). It specifies the number of seconds IRLM waits before detecting a timeout. Acceptable values are 1 to 3600 seconds. The default is 30 seconds.


Table

UPDATEEXCLUSIVE

LOCKSTOP

112

2

3

4567

8

9

1011

TIMEOUT

User 1 User 2

-911 / -913

Timeouts

SELECT( No UR andNo SKIP LOCKED DATA ).

WAIT.

WAIT.

WAIT.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-23. Deadlocks CV8317.0

Notes:

1. User 1 updates table M, and acquires an exclusive lock for page A, which contains record 000100.

2. User 2 updates table N, and acquires an exclusive lock for page B, which contains record 000030.

3. User 1 then attempts to SELECT from page B of table N, while still holding the lock on page A of table M. The job is suspended, because user 2 is holding an exclusive lock on page B.

4. User 2 then attempts to SELECT from page A of table, M while still holding the lock on page B of table N. The job is suspended, because user 1 is holding an exclusive lock on page A.

The situation is a deadlock. After a preset time interval, DB2 can roll back the current unit of work for one of the processes or request a process to terminate. That frees the locks and allows the remaining processes to continue.


User 1

User 2 Table M

Page A

000100

Table N

Page B

000300

1. UPDATE

2. UPDATE

3.. SELECT

4.. SELECT

OK

OK

SUSPENDED

SUSPENDED

Deadlocks

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E

Reducing deadlocks

One way to reduce the likelihood of deadlocks is to access data in a consistent order.

In the above example, both users should access the tables in the same order if possible, that is, table M followed by table N. The first user to access table M might delay the second user but the two users cannot deadlock.

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Figure 9-24. Some factors which affect locking CV8317.0

Notes:

Here is a summary of the main ‘tuning knobs’ for locking.


Some factors which affect locking1. DML

– SQL statements2. DDL

– LOCKSIZE• Specification for each table space accessed

– LOCKMAX– MAXROWS

3. BIND– Release time for table space, partition and table locks

• (RELEASE - DEALLOCATE / COMMIT)– Duration of page/row locks

• (ISOLATION - CS / RS / RR)– Lock avoidance

• (Possibly with ISOLATION - CS)• (Always with ISOLATION - UR)

4. Programming– Design and coding– COMMIT frequency– LOCK TABLE IN S/X MODE

5. DSNZPARM thresholds – NUMLKTS and NUMLKUS

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




Uempty

E


Notes:


Having completed this unit, you should be able to:• Describe concurrency• Explain the aspects of transaction locks • Tell when locks are acquired and released • Describe S and X locks • Explain isolation levels • Explain LOCKSIZE

Having completed this unit, you should be able to:• Describe concurrency• Explain the aspects of transaction locks • Tell when locks are acquired and released • Describe S and X locks • Explain isolation levels • Explain LOCKSIZE

Unit summary

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.



Student Notebook

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C




bibl

E

Bibliography

DB2 10 for z/OS system reference library

SC19-2968 Administration Guide

SC19-2969 Application Programming & SQL Guide

SC19-2970 Application Programming Guide and Reference for Java

GC19-2971 Codes

SC19-2972 Command Reference

SC19-2973 Data Sharing: Planning and Administration

GC19-2974 Installation and Migration Guide

SC19-2975 Internationalization Guide

SC19-2976 Introduction to DB2 for z/OS

GC19-2977 Licensed Program Specifications

SC19-2978 Managing Performance

GC19-2979 Messages

SC19-2980 ODBC Guide and Reference

SC19-2981 pureXML Guide

SC19-2982 RACF Access Control Module Guide

SC19-2983 SQL Reference

SC19-2984 Utility Guide and Reference

GC19-2985 What’s New?

GC19-2986 IBM Spatial Support for DB2 10 for z/OS

GC19-2987 IBM OmniFind Text Search Server for DB2 for z/OS

GC19-2666 IRLM Messages and Codes for IMS and DB2 for z/OS

LY37-3220 Diagnosis Guide and Reference

GI10-8829 DB2 10 for z/OS Program Directory

GI10-8830 z/OS Application Connectivity to DB2 for z/OS

GI10-8840 DB2 Utilities Suite for z/OS, V10, Program Directory

GI10-8842 DB2 Accessories Suite for z/OS Program Directory

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Bibliography X-1

Student Notebook

.

DB2 Version 9.1 for z/OS system reference library


SC18-9841 Application Programming & SQL Guide


GC18-9843 Codes




LY37-3219 Diagnostic Quick Reference

GC18-9846 Installation Guide

SC19-1161 Internationalization Guide

SC18-9847 Introduction to DB2

GC18-9848 Licensed Program Specifications

GC18-9849 Messages


SC18-9851 Performance Monitoring and Tuning Guide

GI10-8737 Program Directory


SC18-9853 Reference for Remote DRDA Requesters and Servers

SX26-3854 Reference Summary



GC18-9856 What’s New?

SC18- 9857 XML Extender Administration and Programming

SC18-9858 XML Guide

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C


X-2 DB2 10 for z/OS DB Admin Workshop Part 1 © Copyright IBM Corp. 1993, 2011


bibl

E

DB2 UDB for z/OS Version 8 system reference library


SC18-7415 Application Programming and SQL Guide


GC18-9603 Codes




GC18-9602 Installation Guide

GC18-7422 Messages



SC18-7424 Reference for Remote DRDA Requesters and Servers

SX26-3853 Reference Summary

SC18-7425 Release Planning Guide



GC18-7428 What's New?

SC18-7431 XML Extender Administration and Programming

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.


© Copyright IBM Corp. 1993, 2011 Bibliography X-3

V5.4.0.3

backpg

E

Back page

xclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C.

.

Exclus

ivo fo

rmac

ión

proy

ecto

C.F.T.I.C

CONTACTO

Teléfono91 761 21 78Póngase en contacto con nuestro equipo y le informaremos de cualquier duda o cuestión que pueda surgirle.

[email protected]ándenos un email y le atenderemos enseguida.

Online@Arrow_Edu_ESO bien puede contactarnos a través de nuestro perfil en Twitter.

VisítenosArrow ECS Education ServicesAvenida de Europa 21, Parque Empresarial La Moraleja28108 Alcobendas, Madrid

EDUCATIONS E R V I C E S

cv 8317 stud

Documents