IBM Class Author main book file - Department of...

V5.1

cover

Front cover

AI Certification Preparation for Exam 730 (Course code CE500)

Instructor GuideERC 1.0

Instructor Guide

Trademarks

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:

Windows and Windows NT are trademarks 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.

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

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

AIX AT Database 2DB2 Distributed Relational

Database ArchitectureDRDA

Informix iSeries MVSOS/390 OS/400 Rationalz/OS

February 2008 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 2008. All rights reserved.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.

Instructor GuideV5.1

TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Instructor course overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiThe ease of working with a relational database . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvData in a DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiDB2 is a Relational Database Management System . . . . . . . . . . . . . . . . . . . . . . . .xixTable creation – English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxiThe language of Relational Database Management Systems . . . . . . . . . . . . . . . . xxiiiCreating tables in DB2 – We must provide ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvFrom an Editor that talks to DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviiA BIG picture look at running an application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxixHow DB2 handles an SQL Change request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxxiFinish the Change request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

Part 1. DB2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5DB2 Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7DB2 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9CLP Command Line Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11CLP syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13Using the CLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Roadmap to the GUI tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20Command Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25Configuration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27Visual Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29Developer Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31Memory Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33Storage Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35IBM Data Warehouse Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39

Part 2. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Basic client-server-host configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7DB2 authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Authentication within the DBM configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

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

© Copyright IBM Corp. 2008 Contents iii

Instructor Guide

DB2 authentication types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13DB2 Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15DB2 Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18Explicit authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23LBAC (Label Based Access Control) query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-25Example implementation of LBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-27Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30

Part 3. Accessing DB2 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4What makes up a DB2 database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6DB2 object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8Default table space containers with Automatic Storage . . . . . . . . . . . . . . . . . . . . .3-10Creating your first database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14Create Database Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16CREATE DATABASE syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20CREATE DATABASE examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25CREATE TABLESPACE syntax (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27CREATE TABLESPACE syntax (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31Cataloging your DB2 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33Configuration Assistant (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-35Configuration Assistant (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-37Manipulating DB2 objects with the Control Center . . . . . . . . . . . . . . . . . . . . . . . . .3-39Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-41

Part 4. Working with DB2 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4The parts of speech of SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6Types of SQL statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8Data Manipulation Language (DML) – SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10Data Manipulation Language (DML) – WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12Data Manipulation Language (DML) – ORDER BY . . . . . . . . . . . . . . . . . . . . . . . .4-15Data Manipulation Language (DML) – Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17Data Manipulation Language (DML) – Set operators . . . . . . . . . . . . . . . . . . . . . . .4-19Data Manipulation Language (DML) – GROUP BY . . . . . . . . . . . . . . . . . . . . . . . .4-21Data Manipulation Language (DML) – INSERT . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23Data Manipulation Language (DML) – UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . .4-25Data Manipulation Language (DML) – DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . .4-27Data Manipulation Language (DML) – MERGE . . . . . . . . . . . . . . . . . . . . . . . . . . .4-29Data Manipulation Language (DML) – Reference . . . . . . . . . . . . . . . . . . . . . . . . .4-31Units of work and savepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-33Creating and calling an SQL procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-35Creating and using SQL user-defined functions . . . . . . . . . . . . . . . . . . . . . . . . . . .4-38User-defined table function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-40


iv AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


TOC
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
Part 5. Working with DB2 objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Numeric data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8String data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Datetime data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12XML data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14User-defined data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Create Trigger statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18Create Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20Set current schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22DB2 Extenders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Tables – CREATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26Tables – ALTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28Tables – DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30Tables – NOT NULL, DEFAULT, and GENERATED . . . . . . . . . . . . . . . . . . . . . . 5-32Constraints – Unique constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34Constraints – Referential integrity constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36Constraints – Table check constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42Creating indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44Clustering indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46Using included columns in indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50

Part 6. Data concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Simple workload consisting of three transactions . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Comparing successful and unsuccessful transactions . . . . . . . . . . . . . . . . . . . . . . 6-8Lock mode compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10Concurrency and isolation levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12Repeatable read isolation level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14Read stability isolation level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16Cursor stability isolation level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Uncommitted read isolation level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20Lock attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Table lock modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Row lock modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27Lock conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29Lock escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Lock wait and timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33Deadlock causes and detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37


© Copyright IBM Corp. 2008 Contents v

Instructor Guide

Part 7. Introducing XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Certification Exam (730) objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4Sample XML document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6XQuery navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8Sample data for the clients table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10Simple XML data retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12Specifying a single filtering predicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-14Converting XML to HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16Conditional logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18Hybrid queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22

Unit 8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1Review of units covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Part 1: DB2 planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4Part 2: Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6Part 3: Accessing DB2 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8Part 4: Working with DB2 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10Part 5: Working with DB2 objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12Part 6: Data concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14Part 7: Introducing XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16


vi AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


TMK
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:

Windows and Windows NT are trademarks 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.

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

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

AIX® AT® Database 2™DB2® Distributed Relational

Database Architecture™DRDA®

Informix® iSeries® MVS™OS/390® OS/400® Rational®z/OS®


© Copyright IBM Corp. 2008 Trademarks vii

Instructor Guide


viii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


pref
Instructor course overview
Course strategy

RECOMMENDED INSTRUCTION APPROACH:

The following is one recommended approach for using this education material, but feel free to adjust according to your available time.

1. Download lecture material from IBM Academic Initiative:

DB2 9 Fundamentals Classroom Resources

See: www-304.ibm.com/jct09002c/us/en/university/scholars/ courseware/

2. Instruct students to download pre-class preparation tutorials from:

DB2 9 Fundamentals Tutorial Series: ibm.com/developerworks/offers/lp/db2cert/db2-cert730.html

3. Conduct weekly lectures and assign pre-class tutorials according to schedule below. We recommend that students read the pre-class tutorials prior to attending the classroom session.

Week 1: Topic: PlanningPre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 1 Classroom Resources: DB2 9 Fundamentals Classroom Resources Part 1

Week 2: Topic: Security Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Classroom Resources DB2 9 Fundamentals Classroom Resources Part 2

Week 3: Topic: Accessing DB2 Data Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 3 Classroom Resources: DB2 9 Fundamentals Classroom Resources Part 3

Week 4: Topic: Working with DB2 Data using SQL Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 4Classroom Resources: DB2 9 Fundamentals Classroom Resources Part 4

Week 5: Topic: Working with DB2 objects Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 5 Classroom Resources: DB2 9 Fundamentals Classroom Resources Classroom Resources Part 5

Week 6: Topic: Data Concurrency Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 6 Classroom Resources: DB2 9 Fundamentals Classroom Resources Part 6

Week 7: Topic: Introducing XQuery Pre-Class Resources: DB2 9 Fundamentals (Exam 730) Tutorial Part 7 Classroom Resources: DB2 9 Fundamentals Classroom Resources Part 7


© Copyright IBM Corp. 2008 Instructor course overview ix

Instructor Guide

Week 8: Topic: Overview of all material Pre-Class Resources: N/A Classroom Resources: DB2 9 Fundamentals Resources Summary

4. Encourage students to use these additional self-study materials:

SQL and XQuery Tutorial: ibm.com/developerworks/db2/library/lp/sqlxquerytutorials.html

DB2 Express-C online book: ibm.com/developerworks/wikis/display/DB2/FREE+Book-+Getting+Started+with+DB2+Express-C

Hello World: Learn the basic features and concepts of DB2 for Linux, UNIX, and Windows:

Part 1: ibm.com/developerworks/edu/dm-dw-db2-hellodb2a.html

Part 2: ibm.com/developerworks/edu/dm-dw-db2-hellodb2b.html

Course materials

• Student Notebook • Instructor Guide • PowerPoint visuals in PDF form to be displayed


x AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


pref
Course description
AI Certification Preparation for Exam 730

Duration: 1 day

Purpose

This series of eight lectures are used in combination with the DB2 9 Fundamentals self-study tutorials. (See: http://www.ibm.com/developerworks/offers/lp/db2cert/db2-cert730. html)

Both the self-study tutorials and lectures will help students prepare for DB2 Family Fundamentals Exam 730.

This education series provides a solid base for each section of the exam.

Audience

Individuals who want to prepare for the DB2 9 Fundamentals Exam 730 or individuals needing an introductory knowledge of DB2.

Prerequisites

Before this course begins, the student should review the DB2 9 Fundamentals exam 730 prep tutorials listed here:

http://www.ibm.com/developerworks/offers/lp/db2cert/db2-cert730. html

• Part 1: DB2 planning • Part 2: Security • Part 3: Accessing DB2 data • Part 4: Working with DB2 data • Part 5: Working with DB2 objects • Part 6: Data concurrency • Part 7: Introducing XQuery

During the course, the instructor will present slides coinciding with each Tutorial unit.

These are short tutorials, averaging about 1 hour.


© Copyright IBM Corp. 2008 Course description xi

Instructor Guide

Objectives

After completing this course, students should be able to:

• Write the DB2 Family Fundamentals, Exam 730

- Section 1 — Planning (14%) - Section 2 — Security (11%) - Section 3 — Working with Databases and Database Objects

(17%) - Section 4 — Working with DB2 Data using SQL (23.5%) - Section 5 — Working with DB2 Tables, Views and Indexes

(23.5%) - Section 6 — Data Concurrency (11%)

(See: http://www-03.ibm.com/certify/certs/08003503.shtml)

EXAM INFORMATION:

The exam is made up of 64 questions. The breakdown of questions associated with each topic area is identified below. Each student is given 90 minutes to write the exam. Each student must achieve a score of 59% to pass the test.

• Section 1 — Planning (14%) • Section 2 — Security (11%) • Section 3 — Working with Databases and Database Objects (17%) • Section 4 — Working with DB2 Data using SQL (23.5%) • Section 5 — Working with DB2 Tables, Views and Indexes (23.5%) • Section 6 — Data Concurrency (11%)

(See: http://www-03.ibm.com/certify/certs/08003503.shtml)


xii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


pref
Agenda
Day 1

(00:50) Welcome (00:50) Part 1: DB2 planning (00:35) Part 2: Security (00:50) Part 3: Accessing DB2 data (01:00) Part 4: Working with DB2 data (01:15) Part 5: Working with DB2 objects (00:50) Part 6: Data concurrency (00:30) Part 7: Introducing XQuery (00:20) Summary


© Copyright IBM Corp. 2008 Agenda xiii

Instructor Guide


xiv AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 1. The ease of working with a relational database CE5001.0

Notes:

© Copyright IBM Corporation 2008

The ease of working with a relational database

I need to call Larry Jones in thecompany directory... now, where is his

phone number?

Phone book

COMPANYDIRECTORY


© Copyright IBM Corp. 2008 -xv

Instructor Guide

Instructor notes:

Purpose —

Details — We work with tables of data every day. A phone book is a table of data. Each page has the same columns (name, address, and phone number), just different rows.

Unlike tables of data in a relational database manager, phone books are in alphabetical sequence.

Additional information —

Transition statement —


-xvi AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 2. Data in a DBMS CE5001.0

Notes:


DB2Tables - R - Us

Optimizer

LockManager Security

Logging

ContinuousOperation

Integrity andRecovery

Phone book

COMPANYDIRECTORY

DBA

DB2, managethe company phone

directory

Data in a DBMS


© Copyright IBM Corp. 2008 -xvii

Instructor Guide

Instructor notes:

Purpose —

Details — Database managers provide many services. These are but a few:

• Logging • Security • Optimization • Locking • Recovery • Data integrity

Database theory demands that all changes to data follow the ACID model.

ATOMICITY refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are. A transfer of funds can be completed or it can fail for a multitude of reasons, but atomicity guarantees that one account won't be debited if the other is not credited as well.

CONSISTENCY refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction can't break the rules, or integrity constraints, of the database. If an integrity constraint states that no salaries can exceed 50,000, then any transaction violating this rule will be aborted.

ISOLATION refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; a bank manager can see the transferred funds on one account or the other, but never on both — even if they ran their query while the transfer was still being processed.

DURABILITY refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. This means it will survive system failure, and that the database system has checked the integrity constraints and won't need to abort the transaction. Typically, all transactions are written into a log that can be played back to recreate the system to its state right before the failure. A transaction can only be deemed committed after it is safely in the log.




-xviii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 3. DB2 is a Relational Database Management System CE5001.0

Notes:


DB2 is a Relational Database Management System

COL1 COL2 COL3

ABC 7 1987-11-14DEF 4 1963-01-01GHI 6 1946-07-12JKL 7 1951-12-30MNO 0 1992-08-12

OWNER1.TABLE_A

PROD QTY SUPPLIER

BOLT 7 ABC CORPNUT 4 THE NUT COSCREW 6 FASTEN INCBOARD 7 ECM CORPWIRE 0 BINDINGS

PROD.PARTS

"RELATION" = TABLE(Data stored in

columns and rows)

"Relational Database"is a "Table Database"


© Copyright IBM Corp. 2008 -xix

Instructor Guide

Instructor notes:

Purpose —

Details — The database management system we are working with in class is DB2. DB2 is a relational database management system (RDBMS). The word relation is a synonym for the word table. A relational database management system is a database manager that manages data perceived to be stored in a table format, that is, columns and rows. IBM Informix is another example of a Relational Database Management System.




-xx AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 4. Table creation – English CE5001.0

Notes:


–Tables - R - UsDB2, build me a table. Here are the rules to enforce on the table. Name the table COMPANY.DIRECTORY.

Name the first column LASTNAME.Ensure that only character data be

allowed in that column. Also, ensure that every phone listing has a value in the LASTNAME column.

Now, for the second column...

Table creation – English

DB2

DBA


© Copyright IBM Corp. 2008 -xxi

Instructor Guide

Instructor notes:

Purpose —

Details — Talking to DB2 in English, French, or German, and so forth, would be too cumbersome. A more concise language is needed.




-xxii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 5. The language of Relational Database Management Systems CE5001.0

Notes:


The language of Relational Database Management Systems

WHAT to do, NOT how to

do it

SQ

LTRUCTURED

UERY

ANGUAGEFlexible


© Copyright IBM Corp. 2008 -xxiii

Instructor Guide

Instructor notes:

Purpose —

Details — SQL is a non-navigational language. With SQL, we tell DB2 what to do, not how to do it.




-xxiv AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 6. Creating tables in DB2 – We must provide ... CE5001.0

Notes:


Describe the columns (give each column 3 attributes)

COLUMN NAMEDATATYPE / LENGTH

NULL CHARACTERISTIC

Table name

DBA

Creating tables in DB2 – We must provide ...

DBA


© Copyright IBM Corp. 2008 -xxv

Instructor Guide

Instructor notes:

Purpose —

Details — Every table must be given a name. Each of the table's columns must be assigned three attributes:

• Name

• Data type / length

• Null characteristic




-xxvi AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 7. From an Editor that talks to DB2 CE5001.0

Notes:


CREATE TABLE COMPANY.DIRECTORY

( ID INTEGER NOT NULL ,

LASTNAME CHAR(15) NOT NULL ,

FIRSTNAME CHAR(15) ,

ADDRESS VARCHAR(45) NOT NULL

WITH DEFAULT,

~ ~ ~ )

Columndescription

area

From an Editor that talks to DB2


© Copyright IBM Corp. 2008 -xxvii

Instructor Guide

Instructor notes:

Purpose —

Details — This CREATE statement tells DB2 that:

• The schema/qualifier of the table is to be COMPANY.

• The simple name of the table is to be DIRECTORY.

• The name of the first column will be ID.

• Only numeric data is to be allowed in the first column.

• The name of the second column will be LASTNAME.

• Only character data is to be allowed in the second column.

• All values in the second column will be stored with 15 characters.

• The second column must always have a value.

• The name of the third column will be FIRSTNAME.

• Only character data is to be allowed in the third column.

• If a first name is not available for a row, DB2 is to mark it null (unknown).

• The name of the fourth column will be ADDRESS.

• Only character data is to be allowed in the fourth column.




-xxviii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 8. A BIG picture look at running an application CE5001.0

Notes:


Application

Application

Application

Application

Application

Application

ApplicationPrograms

ApplicationManager

DataTables

Logging

ContinuousOperation

Security

Optimizer

Integrity&

Recovery

LockManager

DB2Tables - R - Us

A BIG picture look at running an application


© Copyright IBM Corp. 2008 -xxix

Instructor Guide

Instructor notes:

Purpose —

Details —

• The user must be authorized to log on to the system.

• The application manager may have its own security.

• The application manager loads the program into memory, and so forth.

• The application manager passes the authid to DB2.

• DB2 verifies that the authid is authorized to do what it is trying to do.

• DB2 returns messages (and perhaps data) to the application.




-xxx AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 9. How DB2 handles an SQL Change request CE5001.0

Notes:


Catalog

Data

LockManager

Lock

Logging

ContinuousOperation

Security

Optimizer

Integrity&

Recovery

LockManager

DB2Tables - R - Us

User wants to change a SALARY

User's applicationconnects to DB2

Passes user's IDto DB2

Is user permittedto update salary?

Readinto DB2buffer

How DB2 handles an SQL Change request


© Copyright IBM Corp. 2008 -xxxi

Instructor Guide

Instructor notes:

Purpose —

Details —

• The user logs on.

• The user's ID is passed to DB2.

• The user's request is passed to DB2.

• DB2 verifies that user is permitted to update the salary column.

• DB2 locks the data that will be changed.

• DB2 reads the data that will be changed into its buffers.




-xxxii AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 10. Finish the Change request CE5001.0

Notes:


DataLogging

ContinuousOperation

Security

Optimizer

Integrity&

Recovery

LockManager

DB2Tables - R - Us

After the update

Release the lock

Write

Write/Commit

Logging

LOG

Finish the Change request


© Copyright IBM Corp. 2008 -xxxiii

Instructor Guide

Instructor notes:

Purpose —

Details —

• DB2 writes a before update copy of the data to the log.

• DB2 updates the row.

• DB2 writes an after update copy of the data to the log.

• DB2 writes a commit to the log.

• DB2 writes the data to the table (writes may be batched and may not actually occur at this time).

• DB2 releases the lock on the data.

• DB2 returns a message to the user/application as to the success or failure of the SQL statement.




-xxxiv AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty
Part 1. DB2 Planning
Estimated time

01:00

What this unit is about

This unit describes:

• The different versions of DB2, and the various DB2 products

• The tools that are included with DB2

• How to use the Control Center to manage systems, DB2 instances, databases, database objects, and more

• How the Configuration Assistant lets you maintain a list of databases to which your applications can connect, manage, and administer.

• All of the standalone tools in the Control Center and the Configuration Assistant

• What data warehousing is, and the DB2 products available to assist with data warehousing

What you should be able to do

After completing this unit, you should be able to:

• Identify the different versions of DB2, and the various DB2 products.

• List the tools that are included with DB2.

• Use the Control Center to manage systems, DB2 instances, databases, database objects, and more.

• Identify how the Configuration Assistant lets you maintain a list of databases to which your applications can connect, manage, and administer.

• Use all of the standalone tools in the Control Center and the Configuration Assistant.

• Identify what data warehousing is, and the DB2 products available to assist with data warehousing.


© Copyright IBM Corp. 2008 Part 1. DB2 Planning 1-1

Instructor Guide

Also note that throughout this tutorial, you will see commands and syntax that are generally used on either a Linux, Windows, or UNIX platform.


1-2 AI Cert Prep for Exam 730 © Copyright IBM Corp. 2008


Uempty

Figure 1-1. Unit objectives CE5001.0

Notes:


Unit objectives

After completing this unit, you should understand:• Identify the different versions of DB2, and the various DB2

products.• List the tools that are included with DB2.• Use the Control Center to manage systems, DB2 instances,

databases, database objects, and more.• Identify how the Configuration Assistant lets you maintain a

list of databases to which your applications can connect, manage, and administer.





Instructor Guide

Instructor notes:

Purpose —

Details — This lists the unit objectives.






Uempty

Figure 1-2. Certification Exam (730) objectives CE5001.0

Notes:


Certification Exam (730) objectives

• Knowledge of the features or functions available in DB2 tools (just tools that come with product, that is, Control Center, Configuration Advisor, Configuration Assistant, Command Line Processor)

• Knowledge of database workloads (OLTP versus warehousing)



Instructor Guide

Instructor notes:

Purpose —

Details — Sample questions:






Uempty

Figure 1-3. DB2 Editions CE5001.0

Notes:


DB2 Editions

Enterprise Server Edition with Data Partitioning Feature

Massively Parallel Processor (MPP)

Enterprise Server Edition

Workgroup Server Edition

ClusterDB2

Express Edition



Instructor Guide

Instructor notes:

Purpose —

Details — DB2 Express Edition (EE) is the ideal entry level data server. Suitable for transaction processing or complex query workloads on servers with up to two processors. Your workload may be smaller, but your business data is as critical to you as to the largest enterprise. DB2 Express 9 provides many of Enterprise capabilities as value add features to allow you to control costs by purchasing only the capability you need. EE includes all core DB2 capabilities, packaged in two media packs - the Core CD and the ECF (electronic certification file), being for either Authorized User or CPU.

DB2 Workgroup Server Edition (WSE) provides full DB2 database server capacity for your departmental LANs running Windows NT, Windows 2000, Windows XP, Windows.NET, AIX, HP-UX, Linux, and Solaris operating environments. It is the database server designed for deployment in a departmental or small business environment that involves a small number of internal users. Workgroup Server Edition uses a licensing model designed to provide an attractive price point for smaller installations while still providing a full function database server. Workgroup Server Edition can be deployed in Linux, UNIX, and Windows server environments on systems with up to four CPUs. WSE is packaged in two media packs, which includes the Core CD and the ECF, being for either Authorized User or CPU.

DB2 Enterprise Server Edition (ESE) meets the database server needs of midsize to large businesses. It can be deployed in Linux, UNIX, and Windows server environments on any size server. Enterprise Server Edition is the ideal foundation for building data warehouses, transaction processing, or Web-based solutions as well as a backend for packaged solutions like Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM). Additionally, Enterprise Server Edition offers connectivity and integration for other enterprise DB2 and Informix data sources. Platforms supported include Windows NT, Windows 2000, Windows.NET, Linux, Linux/390, AIX, HP-UX, and Solaris. ESE is packaged in two media packs,. including the Core CD and the ECF (being for either Authorized User or CPU).

DB2 Database Partitioning Feature (DPF) allows ESE customers to partition a database within a single system or across a cluster of system. The DPF capability provides the customer with multiple benefits, including scalability to support very large databases or complex workloads and increased parallelism for administration tasks. The DPF feature is only available in the CPU Option, contained in a separate ECF.

The ECFs for each of the Features contain the entitlements for both the Authorized User and CPU Option, with the exception of DPF and Homogeneous Federation Feature, which are only available in the CPU Option.






Uempty

Figure 1-4. DB2 components CE5001.0

Notes:


DB2 components

DRDAApplicationRequester

DataServer Client

Data Server Runtime Client

DB2 DB2 Connect

DRDA Application Server

Communication Support



Instructor Guide

Instructor notes:

Purpose —

Details — DB2 provides a full-function, robust, relational database management system (RDBMS) along with a set of related products designed for the DB2 platforms. DB2 brings to these platforms the support of the IBM SQL technology that is available on all members of the DB2 family.

A Communication Support product must be installed on the server to enable remote client access.

Distributed Relational Database Architecture (DRDA) Application Requesters represent DRDA requests coming from, for example, z/OS, VM, and OS/400. No special product or enablement, other than support of remote clients, is required on the DB2 Server to support DRDA Application Requesters.

The DB2 Application Development Client and DB2 Administration Client have been combined and renamed to DB2 Client.

The DB2 Client provides the ability for workstations from a variety of platforms to access and administer DB2 databases. The DB2 Client has all the features of the DB2 Runtime Client and also includes all the DB2 administration tools and support for Thin Clients. The DB2 Client is a collection of graphical and non-graphical tools and components for developing character-based, multimedia, and object-oriented applications. Special features include a plug-in to the Developer Workbench (was Development Center) and sample applications for all supported programming languages.

The DB2 Runtime Client (RTCL) is a lightweight client that provides the functionality required for an application to access DB2 servers and DB2 Connect servers. Functionality includes communication protocol support and support for application interfaces such as JDBC, SQLJ, ODBC, CLI, and OLE DB. Compared to previous versions, due to the removal of most of the previous Run-Time Client GUI facilities, the current Runtime Client has diminished disk requirements.

DB2 Connect provides DRDA application requester (AR) function. With Communications Support, DB2 Connect enables applications running on DB2 for Linux, UNIX, and Windows platforms to access and update data on DB2 for OS/390, DB2 for z/OS, DB2 for VM and VSE, DB2 for iSeries, and other database management systems that are DRDA-compliant. The DB2 Connect product incorporates the following utilities and functions of DB2:

• Command Line Processor (CLP), which allows you to issue SQL statements to access host platforms

• Database system monitor utility, which is an aid in the problem determination area • The bind command, which allows you to bind packages to the host platforms • The IMPORT and EXPORT utilities, which allow you to move data between host

platforms and the DB2 Connect workstations • The ability to catalog databases for the host platform





Uempty

Figure 1-5. CLP Command Line Processor CE5001.0

Notes:


CLP Command Line Processor



Instructor Guide

Instructor notes:

Purpose —

Details — Through the Command Line Processor you can issue:

• SQL statements

• XQuery statements (with the prefix XQUERY)

• DB2 commands

• OS system commands

In an Windows environment, the CLP can be found under the Command Line Processor as well as the Command Window and in an Linux/UNIX environment, it would be activated with the db2profile, so a normal terminal could be used.






Uempty

Figure 1-6. CLP syntax CE5001.0

Notes:


CLP syntax

phrase

message

sql-state

class-code

db2

option-flag db2-command

sql-statement

?



Instructor Guide

Instructor notes:

Purpose —

Details — The options may be entered after the db2 and before the command or statement. If the command or statement will not fit on one line, either:

Continue typing and allow your typing to wrap and continue on the next line, or

Use the \ (backslash) character for continuation.

The class-code option in the above syntax diagram means that you can request help for a message specified by a valid class-code.






Uempty

Figure 1-7. Using the CLP CE5001.0

Notes:


Using the CLP

db2=> CONNECT TO musicdbdb2=> SELECT * FROM syscat.tables

(double quotes may be required)

db2 CONNECT TO musicdb

db2 “SELECT * FROM syscat.tables“ | more

Interactive mode

db2

Non-interactive mode



Instructor Guide

Instructor notes:

Purpose —

Details — The Online Command Reference contains the syntax and explanations of all DB2 commands that may be executed through CLP. The Online Command Reference is invoked by:

db2? - List of all DB2 commands

db2? command - Information about specific commands

db2? SQLnnnn - Information about a specific SQLCODE generated by database manager. SQLCODE must be four or five digits in length.

db2? nnnnn - Information about a specific SQLSTATE generated by database manager. SQLSTATE must be five digits in length.

A set of reference manuals are also available online. For information on installation and setting up online reference manuals, consult your Installing and Configuring DB2 Clients manual.

Prefix all CLP commands or requests with db2, or use CLP in interactive mode by typing db2 and then pressing Enter. In the interactive mode, the user can type CLP commands without prefixing them by db2.

When using CLP without being in interactive mode on a Linux/UNIX or Windows platform, remember to put quotes around the statement or command if special characters (system characters) are included.

To issue XQuery statements in CLP, prefix the statements with the XQUERY keyword.

Interactive mode does not allow you to do piping or other operating system functions at the interactive CLP command level. To execute operating system commands without quitting interactive mode, issue!<operating-system-command>.

In the interactive mode, the history of commands is displayed by entering history (or shortened form h). Two variations are allowed:

reverse (r) list in reverse order, in other words most recent first

num (such as 5) limits the list to the last num history entries

Examples, assuming that you first entered db2start, then a “list active databases” command, and then you entered? sql11111:

db2 => h

1 db2start 2 list active databases 3 --> sql11111 4 h




Uempty
db2 => h r
5 h r 4 h 3 --> sql11111 2 list active databases 1 db2start

db2 => h r 3

6 h r 3 5 h r 4 h

There is also an edit (e) command which enables editing of a previous command. You can edit the command using the number in the history list, for example e 2. If no number is entered, the last command would be edited.

After having edited the command and closed the editor, the edited command is displayed in the CLP window, and you will be asked:

Do you want to execute the above command --> (y/n)

If you enter y, the command as edited is executed.

With runcmd (r) you can re-run a previously executed command. You can do this using the number from the history list, for example r 3. If no number is entered, the last command is re-executed.

If a command that you are entering exceeds the limit allowed at the command prompt, use a \ (backslash) as the line continuation character. If you want a blank space between the last character on the current line and the first character on the next line, don't forget to code a blank space before the backslash. You may wish to use the CLP flag -t instead of the \ (backslash). It says that the CLP statement terminates with a; (semicolon).

In its output, CLP represents a SQL NULL value as a hyphen (-). If the column is numeric, the hyphen is placed at the right of the column. If the column is not numeric, the hyphen is at the left.





Instructor Guide

Figure 1-8. Roadmap to the GUI tools CE5001.0

Notes:


Roadmap to the GUI tools

Information

IBM DB2

Information Center(db2ic)

CommandLine Tools

GeneralAdministration

Tools

MonitoringTools

SetupTools

CommandEditor

(db2ce)

CommandWindow(db2cw)

CommandLine

Processor(db2)

ControlCenter(db2cc)

Journal(db2journal)

ReplicationCenter(dbrc)

EventAnalyzer(db2eva)

HealthCenter(db2hc)

InDoubtTransaction

Manager(db2indbt)

MemoryVisualizer

(db2memvis)

ConfigurationAssistant(db2ca)

First Steps(db2fs)

Register VisualStudio Add-ins(db2vsregister)

SatelliteSynchronizer

ActivityMonitor(db2am)

Task Center(db2tc)

LicenseCenter




Uempty
Instructor notes:
Purpose —

Details — The graphic shows an overall view, or roadmap, for accessing the graphical tools.

There are some tools that can be started from a command prompt, in addition to starting them from the GUI interface. These are shown on the graphic, if they exist, in italics and red color. For example, by entering the command db2cmd from a command prompt, you can start the DB2 Command Line Processor. The Configuration Assistant (CA) can be started using the command db2ca, as well as from the DB2 Desktop folder.

You can access many of the other graphical tools from within the Control Center. Most of the graphical tools have a menu bar option, Tools, and an icon bar, that will allow you to easily access any of the other graphical tools.





Instructor Guide

Figure 1-9. Control Center CE5001.0

Notes:


Control Center

ObjectTreePane

ContentsPane

ObjectDetailPane




Uempty
Instructor notes:
Purpose —

Details — The Control Center is the central point of administration for DB2. There are three views that you can chose from:

Basic View: Is a simplified view of DB2 core functionality, and omits features that are generally used by the DB2 system administrator but not by the DBA. This includes essential objects such as databases, tables, views, triggers, and stored procedures.

Advanced View: Is the default and lists the standard set of objects.

Custom View: Here you can select those features which you wish to see.

The Control Center is divided into three areas which have contents depending on your chosen view:

Object tree Pane

Contents Pane, showing the contents of the selected object.

Object Detail Pane, which provides context-sensitive access to the main features of the object focused and selected in the other panes, like, for example, the Backup Database tool, the Storage Management tool, or Automatic Maintenance.

Use the Control Center to manage systems (different OSs), DB2 instances, DB2 for OS/390 and z/OS subsystems, databases, and database objects such as tables and views.

In general: The most often used parameters and options are included in UIF panels. If a special parameter or option needs to be used, use the command line interface instead.

In the Control Center, you can administer all of your systems, databases, and database objects. From the Control Center, you can also open other centers and tools to help you optimize queries, jobs, and scripts; perform data warehousing tasks; create stored procedures or UDFs; and work with DB2 commands.

The following are some of the key tasks that you can perform with the Control Center:

• Add DB2 systems, federated systems, DB2 for z/OS and OS/390 systems, instances, databases, and database objects to the object tree.

• Manage database objects. You can create, alter, and drop databases, table spaces, tables, views, indexes, triggers, and schemas. You can also manage users.

• Manage data. You can load, import, export, and reorganize data. You can also gather statistics.

• Perform preventive maintenance by backing up and restoring databases or table spaces.

• Monitor performance and troubleshoot problems. • Configure and tune instances and databases. • Manage database connections, such as DB2 Connect servers and subsystems. • Manage applications. • Analyze queries using Visual Explain to look at access plans. • Launch other tools such as the Command Editor and the Health Center.



Instructor Guide

• Automatic maintenance of your databases.

In many cases, wizards and launch pads are available to help you perform these tasks more quickly and easily. In many cases, the wizard will launch automatically when you select a task to be performed on an object; for example, the Create action on the Tables object will launch the Create Table wizard.

Other components of the Control Center are the following:

• Menu Bar - It is used to access Control Center functions and online help using menus.

• Tool Bar - These icons are used to access all the other administration tools.

• Hover Help - Provides a short description for each icon on the toolbars.

The Systems object represents machines. You can see all of the systems that your system has catalogued by looking at the list in the Control Center. The local workstation is represented by a System icon labeled with the machine name of the local workstation; other remote systems defined are labeled as they are cataloged.

To display the instances on each system, expand the object tree by clicking the plus sign (+) on the local or remote system name.






Uempty

Figure 1-10. Command Editor CE5001.0

Notes:


Command Editor

SQL Assist



Instructor Guide

Instructor notes:

Purpose —

Details — Use the Command Editor to execute DB2 commands and SQL/XQUERY statements; to execute MVS, OS/390, or z/OS commands; to work with command scripts; and to view a graphical representation of the access plan for explained SQL statements.

On the command page, you can perform the following actions:

• Execute an SQL statement or DB2 CLP command. You do not need to precede the command by DB2.

• Run an existing script, by clicking the Execute icon (at the left of the tool bar). • Execute the commands in sequence. • Create and save a script. You can optionally store a saved script in the Task Center,

where you can schedule the script to run at a specific time. • Run and/or modify an existing script.

On the Query Results page, you can see the results of the queries. You can also save the results or edit the contents of the table.

On the Access Plan page, you can see the access plan for any explainable statement that you specified on the Interactive page or the Script page. DB2 generates the access plan when it compiles the SQL or XQUERY statement. You can use this information to tune your queries for better performance.

To invoke the SQL Assist tool, click the SQL Assist button on the Interactive page. To invoke the Visual Explain tool, execute an explainable statement on the Interactive page or the Script page.

The Web version of the Command Editor includes most of these features but it does not currently include Visual Explain or SQL Assist.

Both the GUI and traditional CLP are installed and shown as icons in the DB2 folder. For Windows, there is also a Command Window to enable users to execute SQL statements and DB2 commands from an MS-DOS command prompt.

The example commands shown in the Command Editor assume that a semi-colon (;) has been set in the Tools (can be specified at the bottom of the command editor window) as the statement termination character.






Uempty

Figure 1-11. Journal CE5001.0

Notes:


Journal



Instructor Guide

Instructor notes:

Purpose —

Details — The Journal displays historical information about tasks, database actions and operations, Control Center actions, messages, and alerts.

To see the most recent information, click the Refresh button.

The Task History page shows the results of tasks that were previously executed. You can use this information to estimate how long future tasks will run.

The Task History page contains one row for each execution of a task. The Task Center contains only one row for each task no matter how many times the task is executed. Each row in the Task Center could be directly related to multiple rows in the Task History page of the Journal.

For each completed execution of a task, you can perform the following actions:

• View the execution results • View the task that was executed • Edit the task that was executed • View the task execution statistics • Remove the task execution object from the Journal

To perform one of these actions, right-click a completed task execution and select the corresponding action from the pop-up menu that appears.

The Database History page shows information from the recovery history file. This file is updated when various operations are performed, including:

• Backup • Restore • Roll forward • Load • Reorg

This information could be useful if you need to restore a database or table space.

The Messages page shows messages that were previously issued from the Control Center and other GUI tools.

The Notification Log page shows information from the administration notification log. You can filter the list, for example to show only alerts from the health monitor.

Several customizable saved views are available via the pull-up menu at the bottom of the Journal.






Uempty

Figure 1-12. Configuration Assistant CE5001.0

Notes:


Configuration Assistant



Instructor Guide

Instructor notes:

Purpose —

Details — The Configuration Assistant (CA) is the GUI tool that is used to configure access to remote databases. It can be invoked from the Control Center, DB2 Desktop folder, or from the command line with the db2ca command.

Use the Configuration Assistant to configure your clients. You can also use it as a lightweight alternative to the Control Center, in situations where you do not want to install the complete set of GUI tools.

CA can also be used to change DB2 registry parameters and DB2 instance parameters but, not all available parameters are shown in the lists.

You must configure your DB2 clients so that they can work with the available objects, as follows:

• To access an instance or database on another server or system, DB2 must catalog that system in the node directory of the client.

• To access a database, DB2 needs information about the node where the database resides.

• Each database that will be accessed must be configured at the DB2 client.

From the Configuration Assistant, you can work with existing database objects, add new ones, bind applications, set database manager configuration parameters, and import and export configuration information. The graphical interface makes these complex tasks easier through:

• Wizards that help you perform certain tasks • Dynamic fields that are activated based on your input choices • Hints that help you make configuration decisions • Discovery that can retrieve information about selected database objects

The Configuration Assistant displays a list of the databases to which your applications can connect. Each database is identified by its database alias. You can use the Add Database wizard to add databases to the list. You can use the Change Database wizard to alter the information that is associated with databases in the list.

From the View menu, you can select an advanced view, which uses a notebook to organize connection information by object: Systems, Instance Nodes, Databases, Database Connection Services (DCS), and Data Sources.

You can use the notebook pages to perform object-specific actions.






Uempty

Figure 1-13. Visual Explain CE5001.0

Notes:


Visual Explain



Instructor Guide

Instructor notes:

Purpose —

Details — Visual Explain lets you view the access plan for an explained SQL statement as a graph. You can use the information available from the graph to tune your SQL query for better performance. Visual Explain also lets you dynamically explain an SQL statement and view the resulting access plan graph. Visual Explain is available as a stand alone tool from the Control Center, or through interfaces associated with the Command Editor and the Developer Workbench.






Uempty

Figure 1-14. Developer Workbench CE5001.0

Notes:


Developer Workbench



Instructor Guide

Instructor notes:

Purpose —

Details — DB2 9 has an integrated development environment (IDE) called the DB2 Developer Workbench (DB2 DWB), specifically designed for power DBAs and developers who are required to build business logic for their databases. The DB2 9 DWB replaces the DB2 8 Development Center (DB2 DC), which was a successor to the DB2 7 Stored Procedure Builder (DB2 SPB). The DB2 DWB is a completely different tool that's built on the Eclipse foundation, so the interface is identical to other DB2 products that use this architecture, such as DB2 SQL Warehousing Tool, Rational Application Developer, Rational Data Architect, and more.

The DB2 DWB is a rapid iterative development environment that can be used for building stored procedures (SPs), user-defined functions (UDFs), and structured data types. It is also useful for creating XQuery statements, registering XML schemas, annotating XML Schema documents for shredding, SQLJ development, and much more.

In DB2 9.5, the DB2 Developer Workbench has been replaced with the IBM Data Studio, which is also Eclipse-based.






Uempty

Figure 1-15. Memory Visualizer CE5001.0

Notes:


Memory Visualizer



Instructor Guide

Instructor notes:

Purpose —

Details — The Memory Visualizer helps DBAs understand their systems' memory allocations on a per-instance basis. You can start this tool by right-clicking the instance you want to work with in the Control Center and selecting View Memory Usage. You can also select the tool directly from the Start menu in a Windows environment. The figure shows the Memory Visualizer monitoring an instance called DB2.






Uempty

Figure 1-16. Storage Management CE5001.0

Notes:


Storage Management



Instructor Guide

Instructor notes:

Purpose —

Details — DB2 has a Storage Management tool that helps DBAs understand their storage requirements and potential considerations. DB2 9 includes automated storage management where DB2 can automatically grow containers that require more space, and even manage the table spaces (this feature is available with DMS FILE-based table spaces only). If you're using the automated storage management capabilities in DB2 9, the Storage Management tool may not be as useful if you choose a manual-based storage mechanism for your data server.

You can use the Storage Management tool to schedule or immediately capture a snapshot of currently allocated storage resources. Start the Storage Management tool by selecting a database in the Control Center, right-clicking, and selecting View Storage.






Uempty

Figure 1-17. IBM Data Warehouse Edition CE5001.0

Notes:


IBM Data Warehouse Edition

An integrated data warehouse for greater business insight

Identify opportunities to pursue - before the competition does

Identify risks to be minimized or eliminated - before they become public



Instructor Guide

Instructor notes:

Purpose —

Details — OLTP (On-Line Transaction Processing)

An OLTP system is typical of a Web ordering system, where you perform transactions over the Web (such as ordering a product). These applications are characterized by granular single-row look-ups with logic that likely updates a small number of records.

Systems that contain operational data -- the data that runs the daily transactions of a business -- are OLTP systems.

BI (Business Intelligence)

DB2 is built for business intelligence. Not only is DB2 the world's most scalable database, it also has a robust set of business intelligence functions. DB2 has two Data Warehouse Editions (DB2 DWE) that provide steep discounts on a complete set of data warehousing tools. Some of these tools are available for purchase outside of the DB2 DWE packages, and some are not. DB2 DWE comes in the Base and Enterprise Editions.

The DB2 DWE builds on and extends the powerful DB2 Enterprise 9 product to provide improved performance and usability of data warehousing, and analytics features, for real-time insight and decision making to achieve information on demand. DB2 DWE features include tools for warehouse management, analytic application development, OLAP, data mining, and very large database (VLDB) query and resource management.

This has been renamed to DB2 Warehouse for DB2 9.5 in the 9.5 version of the product.






Uempty

Figure 1-18. Unit summary CE5001.0

Notes:


Unit summary

Having completed this unit, you should understand:• Identify the different versions of DB2, and the various DB2

products.• List the tools that are included with DB2.• Use the Control Center to manage systems, DB2 instances,

databases, database objects, and more.• Identify how the Configuration Assistant lets you maintain a

list of databases to which your applications can connect, manage, and administer.





Instructor Guide

Instructor notes:

Purpose —

Details — This lists objectives covered in this unit.






Uempty
Part 2. Security
Estimated time

01:00



• The structure of the entire DB2 environment, which includes client, servers, gateways, and hosts

• Authentication, authorization, and privileges

• How to use the db2 catalog database command on the gateway and client

• The basics of the SYSADM, SYSCTRL, SYSMAINT, and SYSMON authorities, which are set in the DBM CFG file

• The basics of the DBADM, LOAD, and SECADM authorities, which are set using the GRANT command and revoked using the REVOKE command

• What command each authority is allowed to run

• The different types of privileges and what they allow a user to do

• How a privilege is obtained/revoked explicitly, implicitly, or (for packages only) indirectly

• Basics of Label-Based Access Control, and how to define different types of policies based on this new security concept



• Identify the structure of the entire DB2 environment, which includes client, servers, gateways, and hosts

• Work with authentication, authorization, and privileges.

• Use the db2 catalog database command on the gateway and client

• List the basics of the SYSADM, SYSCTRL, SYSMAINT, and SYSMON authorities, which are set in the DBM CFG file


© Copyright IBM Corp. 2008 Part 2. Security 2-1

Instructor Guide

• List the basics of the DBADM, LOAD, and SECADM authorities, which are set using the GRANT command and revoked using the REVOKE command

• Identify what command each authority is allowed to run

• Identify the different types of privileges and what they allow a user to do

• Identify how a privilege is obtained/revoked explicitly, implicitly, or (for packages only) indirectly

• Identify the basics of Label-Based Access Control, and how to define different types of policies based on this new security concept




Uempty


Notes:


Unit objectivesAfter completing this unit, you should be able to:• Identify the structure of the entire DB2 environment, which includes

client, servers, gateways, and hosts. • Use the db2 catalog command on the gateway and client.• Use the basics of the SYSADM, SYSCTRL, SYSMAINT, and

SYSMON authorities, which are set in the DBM CFG file.• List the basics of the DBADM, LOAD, and SECADM authorities, which

are set using the GRANT command and revoked using the REVOKE command.

• Identify what command each authority is allowed to run.• Identify the different types of privileges and what they allow a user to

do.• Identify how a privilege is obtained/revoked explicitly, implicitly, or (for

packages only) indirectly. • Identify the basics of Label-Based Access Control, and how to define

different types of policies based on this new security concept.



Instructor Guide

Instructor notes:

Purpose —







Uempty


Notes:



• Knowledge of restricting data access

• Ability to identify and connect to DB2 servers and databases

• Knowledge of DB2 products (client, server, etc.)

• Knowledge of different privileges and authorities

• Knowledge of encryption options (data and network)

• Given a DDL SQL statement, knowledge to identify results (grant/revoke/connect statements)



Instructor Guide

Instructor notes:

Purpose —

Details — Sample questions.






Uempty

Figure 2-3. Basic client-server-host configuration CE5001.0

Notes:


Basic client-server-host configuration

DB2 server orDB2 Connect Server

(Gateway)

Windows

AIX

Linux

DB2 on the host

DB2 clients



Instructor Guide

Instructor notes:

Purpose —

Details — The database server is the machine (or machines in a partitioned database system) on which the database physically resides. The DB2 database clients are machines that are configured to run queries against the database on the server. These clients can be local (reside on the same physical machine as the database server) or they can be remote (reside on separate machines).






Uempty

Figure 2-4. DB2 authentication CE5001.0

Notes:


DB2 authentication

• Implicit security checking:ATTACH TO DB2

• Explicit security checking:CONNECT TO sample USER test1 USING <password>

Database Connection Information

Database server = DB2/NT 9.1.0SQL authorization ID = TEST1Local database alias = SAMPLE



Instructor Guide

Instructor notes:

Purpose —

Details — Authentication can be done implicitly, using the logged-on user ID and password, or explicitly by specifying the user ID and password during an ATTACH or CONNECT activity.






Uempty

Figure 2-5. Authentication within the DBM configuration CE5001.0

Notes:


Authentication within the DBM configurationGET DBM CFG

Server Connection Authentication (SRVCON_AUTH) = KERBEROS……Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT



Instructor Guide

Instructor notes:

Purpose —

Details — The Database Manager controls the method of authentication by using the SRVCON_AUTH and/or AUTHENTICATION DBM configuration parameters, for all databases within that instance.






Uempty

Figure 2-6. DB2 authentication types CE5001.0

Notes:


DB2 authentication types

GSS_SERVER_ENCRYPTGSSPLUGIN

DATA_ENCRYPT_CMPDATA_ENCRYPT

*KRB_SERVER_ENCRYPT*KERBEROS

CLIENTSERVER_ENCRYPTSERVER



Instructor Guide

Instructor notes:

Purpose —

Details —

• SERVER Authentication takes place on the server.

• SERVER_ENCRYPT Authentication takes place on the server. Passwords are encrypted at the client machine before being sent to the server.

• CLIENT Authentication takes place on the client machine.

• *KERBEROS Authentication is performed by the Kerberos security software.

• *KRB_SERVER_ENCRYPT Authentication is performed by Kerberos security software if the client setting is KERBEROS. Otherwise, SERVER_ENCRYPT is used.

• DATA_ENCRYPT Authentication takes place on the server. The server accepts encrypted userids and passwords, and will encrypt the data. This operates the same way as SERVER_ENCRYPT, except the data is encrypted as well.

• DATA_ENCRYPT_CMP Authentication is the same as for DATA_ENCRYPT, except that this scheme allows older clients that don't support the DATA_ENCRYPT scheme to connect using SERVER_ENCRYPT authentication. The data in this case will not be encrypted. if the client connecting supports DATA_ENCRYPT, it is forced to encrypt the data, and can not downgrade to SERVER_ENCRYPT authentication. This authentication type is only valid in the server's database manager configuration file and is not valid when used on the CATALOG DATABASE command on a client or gateway instance.

• GSSPLUGIN Authentication is controlled by an external GSS-API plug-in.

• GSS_SERVER_ENCRYPT Authentication is controlled by an external GSS-API plug-in. In the case where the client doesn't support one of the server's GSS-API plug-ins, SERVER_ENCRYPT authentication is used.






Uempty

Figure 2-7. DB2 Authorities CE5001.0

Notes:


DB2 Authorities

MIGRATE DATABASEUPDATE DBM CFGGRANT/REVOKE DBADMUPDATE db/node/dcs directoriesFORCE USERS OFF SYSTEMCREATE/DROP DATABASECREATE/DROP/ALTER TABLE SPACERESTORE TO NEW DATABASEUPDATE DB CFGBACKUP DATABASE or TABLE SPACERESTORE TO EXISTING DATABASEPERFORM ROLLFORWARD RECOVERYSTART/STOP DATABASE INSTANCERESTORE TABLE SPACERUN TRACETAKE DBM or DB SNAPSHOTSQUERY TABLE SPACE STATEUPDATE LOG HISTORY FILESQUIESCE TABLE SPACEREORG TABLERUN RUNSTATS UTILITYREAD LOG FILESCREATE/ACTIVATE/DROP EVENT MONITORS

YESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYES

YESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYES

YESYESYESYESYESYESYESYESYESYESYESYESYES

YESYESYESYESYESYESYES

Function SYSADM SYSCTRL SYSMAINT DBADM LOAD

YES

YES

YES



Instructor Guide

Instructor notes:

Purpose —

Details — System Administrator Authority - SYSADM authority is the highest level of administrative authority.

Users with SYSADM authority can run utilities, issue database and database manager commands, and access the data in any table in any database within the database manager instance. It provides the ability to control all database objects in the instance, including databases, tables, views, indexes, and packages.

System Control Authority - SYSCTRL authority is the highest level of system control authority.

This authority provides the ability to perform maintenance and utility operations against the database manager instance and its databases. These operations can affect system resources, but they do not allow direct access to data in the databases. System control authority is designed for users administering a database manager instance containing sensitive data. A user with SYSCTRL authority has the implicit privilege to connect to a database.

System Maintenance Authority - SYSMAINT authority is the second level of system control authority.

This authority provides the ability to perform maintenance and utility operations against the database manager instance and its databases. These operations can affect system resources, but they do not allow direct access to data in the databases. System maintenance authority is designed for users maintaining databases within a database manager instance that contains sensitive data. A user with SYSMAINT authority has the implicit privilege to connect to a database.

System Monitor Authority - SYSMON gives the ability to take database system monitor snapshots of a database manager instance or its databases.

This includes the following commands: GET DBM MONITOR SWITCHES, GET MONITOR SWITCHES, GET SNAPSHOT, LIST ACTIVE DATABASES, LIST APPLICATIONS, LIST DCS APPLICATIONS, RESET MONITOR, UPDATE MONITOR SWITCHES.

Security administration authority - SECADM authority can only be granted by the SYSADM and can be granted to a user but not to a group.

It gives these and only these abilities: Create and drop security label components, Create and drop security policies, Create and drop security labels, Grant and revoke security labels, Grant and revoke LBAC rule exemptions, Grant and revoke SETSESSIONUSER privileges, Execute the SQL statement TRANSFER OWNERSHIP on objects that you do not own. No other authority gives these abilities, not even SYSADM.

Database Administration Authority - DBADM authority is the second highest level of administrative authority.




Uempty
It applies only to a specific database, and allows the user to run utilities, issue database commands, and access the data in any table in the database. When DBADM authority is granted, BINDADD, CONNECT, CREATETAB, and CREATE NOT FENCED privileges are granted as well. Only a user with SYSADM can grant/revoke DBADM. Users with DBADM can grant privileges on the database to others and can revoke any privilege from any user regardless of who granted it.
A user may hold DBADM authority on more than one database, but a DBADM can only perform functions on the databases for which DBADM authority is held.

Load Authority - Users having LOAD authority at the database level, as well as INSERT privilege on a table, can use the LOAD command to load data into a table.

Users having LOAD authority at the database level, as well as INSERT privilege on a table, can LOAD RESTART or LOAD TERMINATE if the previous operation was a load to insert data. If the previous load operation was a load replace, the DELETE privilege must also have been granted to that user before the user can LOAD RESTART or LOAD TERMINATE. If the exception tables are used as part of a load operation, the user must have INSERT privilege on the exception tables. The user with this authority can perform QUIESCE TABLESPACES FOR TABLE, RUNSTATS, and LIST TABLESPACES commands.

The database manager configuration parameter CATALOG_NOAUTH specifies whether users are able to catalog and uncatalog databases and nodes, or DCS and ODBC directories, without SYSADM authority. Default value is NO which means that SYSADM or SYSCTL authority is needed. If set to YES, the DB2 system administrator can allow users to maintain their own cataloging.





Instructor Guide

Figure 2-8. DB2 Privileges CE5001.0

Notes:


DB2 Privileges

SYSCTRL

SYSMAINT

ALLALTER

DELETEINDEX

INSERTREFERENCES

SELECTUPDATE

CONTROL(Tables)

SYSADM

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Authorities

Privileges

ALLDELETEINSERTSELECTUPDATE

CONTROL(Views)

BINDEXECUTE

CONTROL(Packages)

SchemaOwner

CREATEINALTERINDROPIN

CONTROL(Indexes)

Table spaceOwner

USE

BINDADDCONNECT

CREATETABCREATE_EXTERNAL_ROUTINE

CREATE_NOT_FENCED_ROUTINEIMPLICIT_SCHEMA

LOADQUIESCE_CONNECT

(Database)

EXECUTE(Routines)

LOADSYSMON

SECADM DBADM




Uempty
Instructor notes:
Purpose —

Details — Both DB2 authorities and privileges on objects are hierarchical in nature.

A privilege is the right of a particular user or group to create or access a resource.

Resources can be protected from unauthorized access by:

• Database privileges controlling both access and creation of databases.

• Table privileges controlling both access and creation of tables.

• View privileges controlling access and creation of views. Views can be used to control access to a table. By granting access to a view instead of the underlying tables, access is restricted to the rows and columns selected by the view definition.

• Index privileges controlling the creation of indexes.

• Package privileges controlling the creation, modification, and execution of packages.

Users with SYSADM authority automatically possess the privileges associated with DBADM authority for each database in the instance.

DATABASE PRIVILEGES

The creator of a database automatically receives DBADM authority.

DBADM authority allows any SQL access to the database.

DBADM authority is required to GRANT the following privileges:

• BINDADD - Create new packages in the database.

• CONNECT - Connect to the database.

• CREATETAB - Create new tables in the database.

• CREATE_EXTERNAL_ROUTINE - Allows a user to create a procedure for use by applications and other users of the database.

• CREATE_NOT_FENCED_ROUTINE - Create a user-defined function or procedure that is not fenced. UDFs or procedures that are not fenced must be extremely well tested because the database manager does not protect its storage or control blocks from these UDFs. An unfenced UDF runs on the same side of the firewall as the database engine code.

• IMPLICIT_SCHEMA - Create a schema implicitly by creating an object using a CREATE statement with a schema name that does not already exist. SYSIBM becomes the owner of the implicitly created schema, and PUBLIC is given the privilege to create objects in this schema.

• LOAD - Load data into a table. LOAD is considered an authority since it implies other functions (quiesce table spaces, query table spaces, RUNSTATS), but it also gives the LOAD privilege at the database level.



Instructor Guide

• QUIESCE_CONNECT - Allows a user to access the database while it is quiesced.

Only users with SYSADM or DBADM authority can grant and revoke these privileges to and from other users.

TABLE SPACE PRIVILEGES

The owner of the table space, typically the creator who has SYSADM or SYSCTRL authority, has USE privilege and the ability to grant this privilege to others.

USE privilege allows the user to create tables within the table space.

By default, at database creation time the USE privilege for table space USERSPACE1 is granted to PUBLIC, though this privilege can be revoked.

The USE privilege cannot be used with SYSCATSPACE or any system temporary table spaces.

SCHEMA PRIVILEGES

The owner of the schema has all of the schema privileges and the ability to grant them to others.

Being owner of a schema allows GRANTing of:

• ALTERIN - Alter objects in the schema.

• CREATEIN - Create objects within the schema.

• DROPIN - Drop objects within the schema.

Objects that are manipulated within the schema object include: tables, views, indexes, packages, data types, functions, triggers, procedures, and aliases.

TABLE PRIVILEGES

The creator of a table automatically receives CONTROL privilege. To grant CONTROL privilege on a table or view, the user must have SYSADM or DBADM authority.

CONTROL privilege allows GRANTing of:

• ALTER - Add columns to a table, add or change comments on a table and its columns, add a primary key or unique constraint, and create or drop a table check constraint. The user can also create triggers on the table, though additional authority on all objects referenced in the trigger, including SELECT on the table if the trigger references any columns of the table) is required. A user with ALTER on all the descendent table can drop a primary key; a user with ALTER privilege on the table and REFERENCES privilege on the parent table, or REFERENCES privilege on the appropriate columns, can create or drop a foreign key.

• DELETE - Delete rows from the table/view.

• INDEX - Create indexes on the table. The creator of the index has CONTROL privilege on index and can drop the index.

• INSERT - Insert rows into the table. Run IMPORT utility against the table.




Uempty
• REFERENCES - Create referential constraints on a table, specifying the table as the parent in a relationship. The user might have this privilege only on specific columns.
• SELECT - Retrieve rows from a table or view. Create a view on the table. Run the EXPORT utility against the table or view.

• UPDATE - Change entries in the table or view or for one or more specific columns in a table or view. The user may have this privilege only on specific columns.

CONTROL privilege is required to DROP the table, REORGANIZE the table, or refresh its statistics with RUNSTATS utility, and grant or revoke individual table privileges. When a user is granted CONTROL privilege on a table, all other privileges on that table are automatically granted WITH GRANT OPTION.

The privilege to grant these privileges to others may also be granted using the WITH GRANT OPTION on the GRANT statement.

VIEW PRIVILEGES

To create a view, SELECT or CONTROL privilege on every table or view referenced is required.

CONTROL privilege is ONLY granted if the creator has CONTROL privilege on all tables and views referenced, or if they have SYSADM or DBADM authority.

CONTROL privilege is required to grant DELETE, INSERT, SELECT, and UPDATE privileges; SELECT is the only option for read-only views.

View privileges allow an authorized user to perform actions against base tables that they are not allowed to perform directly.

INDEX PRIVILEGES

The creator of an index automatically receives CONTROL privileges.

CONTROL privilege allows users to drop the index.

No privilege is required to use an index.

The table level INDEX privilege allows a user to create an index on that table.

PACKAGE PRIVILEGES

The creator of a package automatically receives CONTROL privilege.

CONTROL privilege allows granting of:

• BIND - Bind or rebind the package and to add new package versions of the same package name and creator.

• EXECUTE - Execute or run the package.

CONTROL privilege implies that you can drop a package.

The binder must have privileges or authority required to execute every embedded static SQL statement in the package granted to their userid or to PUBLIC.



Instructor Guide

Any user with EXECUTE privilege may execute the statements within the scope of executing the package. They may not execute the statements in a dynamic environment (such as CLP) unless they have been granted authority to do so.

Package privileges provide a powerful way to extend partial privileges to users through executing a package that contains embedded SQL.

Database privilege BINDADD allows users to create new packages or rebind an existing package in the database.

ROUTINE PRIVILEGES

Execute privileges involve actions on all types of routines such as functions, procedures, and methods within a database. Once having execute privilege, a user can then invoke that routine, create a function that is sourced from that routine (applies to functions only), and to reference the routine in any DDL statement such as CREATE VIEW, CREATE TRIGGER; or, when defining a constraint.

The one who defines the externally stored procedure, function, or method receives EXECUTE WITH GRANT privilege.

SYSADM has implicit connect on all databases. DBADM has implicit connect on a specific database. When a database is created, the following privileges are automatically granted to PUBLIC. To remove these privileges, a DBADM or SYSADM must explicitly revoke the database privileges from PUBLIC.

• CREATETAB

• BINDADD

• CONNECT

SELECT privilege on system catalog views.






Uempty

Figure 2-9. Explicit authorization CE5001.0

Notes:

Privileges and DBADM authority may be explicitly GRANTed to users or PUBLIC by someone who holds a higher authority or privilege (SYSADM, DBADM, or CONTROL). When granting database privileges, the name of the database is not specified, because you must be CONNECTed (using) a specific database in order to execute SQL statements. Therefore, DB2 knows to which database you are connected.


Explicit authorization

GRANT/REVOKE

*

Databaseprivileges

CONTROL

ONDATABASE

useridgroupidPUBLIC

* must be SYSADM, DBADM, or have CONTROL on object

USE

Table/viewprivileges

OF TABLESPACEtablespacename

ON TABLEtable/view_name

ON INDEXindex_name

TO/FROM

USER/GROUP

Schemaprivileges

ON SCHEMAschema_name

Packageprivileges

ON PACKAGEpackage_name



Instructor Guide

Instructor notes:

Purpose —

Details —






Uempty

Figure 2-10. LBAC (Label Based Access Control) query CE5001.0

Notes:


LBAC (Label Based Access Control) query

SALARYIDLBACNo LBAC

450001057800020083000904600025333000755400010082000102560002503000060450005070000505000010060000255

SELECT * FROM EMPWHERE SALARY >= 50000

User Level = 100

Users with user level 100 can view the rows with ID <= 100 and salary >= 50000 (indicated in green)

With no LBAC user level imposed, users can view rows that meet the salary >= 50000 qualifier (shown in red)



Instructor Guide

Instructor notes:

Purpose —

Details — In the chart shown in the visual, we assume that the current User Level (LBAC) is 100. When that user executes the select statement shown, the result set of that query is depicted in the table.

With LBAC:

Note that for LBAC secured data, only those rows listed with the color green will be returned for that user, because they meet both the LBAC security requirement and the predicate clause requirement.

User ID 100 will not retrieve rows from a higher security level, but can retrieve rows from lower security levels.

Without LBAC:

If there is no LBAC security imposed on the EMP table, only those rows shown in red will be returned, because they meet the predicate requirement.






Uempty

Figure 2-11. Example implementation of LBAC CE5001.0

Notes:


Example implementation of LBAC

• Steps overview:

1. Define the security policies and labels a. Define the security label component b. Define the security policy c. Define the security labels

2. Create the protected SALES table by including a column that holds the security label and attaching the security policy to the table.

3. Grant the appropriate security labels to users.

• Requires SECADM authority to execute commands for creating security policies and labels.



Instructor Guide

Instructor notes:

Purpose —

Details — In this example, we need to design the security labels that will control access to the data rows in the SALES table.

In designing security labels, you need to consider the following:

• Row security labels that protect the rows. • User security labels that grant users the appropriate access. • Security label components that create the security labels.

Row security labels

From your analysis, you determine that each region requires a security label to control access to its data. And so four security labels are needed, one for each sales region. The security label components for building these security labels can be constructed using the sales regions as the elements. Since all regions appear to be of equal importance you might consider using a SET for this security label component.

User security labels for the regional managers

The appropriate security labels used to tag the rows will be granted to the regional managers so that they can access the data for their region. Their access is to this data is READ/WRITE.

User security label for general manager

The General manager of the Central region can read data for the Central-North and Central-South regions, so this security label should rank above the security labels used to protect the rows of those sub-regions. Because now there is a hierarchy, you might consider using an ARRAY or a TREE for another security label component.

Since the general manager is not allowed to write to the SALES table, some restriction should be imposed at the table level by revoking the INSERT, UPDATE, and DELETE privileges from this user. These types of restrictions will not be part of a security label component or security label, but will be imposed when you GRANT security labels to users.

User security labels for executives

The executives can read all the sales data. One way to accomplish this is by granting all security labels to the executives, but this might not be the most efficient method. An alternative might be to use a hierarchical structure, where the security label granted to the executives is higher than the security labels used to protect the rows. This hierarchy should match the organizational structure of the company and so is too complex for an ARRAY and you should consider using a TREE.

Like the general manager, the executives cannot write to the SALES table and so similar WRITE restrictions should be imposed.




Uempty
Security label components
Since data access is based on Global Life Financial's geographic regions, the security label component can be constructed with a TREE structure with regions as the elements.





Instructor Guide


Notes:


Unit summaryHaving completed this unit, you should be able to:• Identify the structure of the entire DB2 environment, which includes

client, servers, gateways, and hosts. • Use the db2 catalog command on the gateway and client.• Use the basics of the SYSADM, SYSCTRL, SYSMAINT, and

SYSMON authorities, which are set in the DBM CFG file.• List the basics of the DBADM, LOAD, and SECADM authorities, which

are set using the GRANT command and revoked using the REVOKE command.

• Identify what command each authority is allowed to run.• Identify the different types of privileges and what they allow a user to

do.• Identify how a privilege is obtained/revoked explicitly, implicitly, or (for

packages only) indirectly. • Identify the basics of Label-Based Access Control, and how to define

different types of policies based on this new security concept.




Uempty
Instructor notes:
Purpose —






Instructor Guide




Uempty
Part 3. Accessing DB2 data
Estimated time

01:00



• Creating a DB2 database on your own

• Cataloging it for use by other users

• Examining and manipulating the objects within that database


After completing this unit, you should understand how to:

• Create a DB2 database on your own

• Catalog it for use by other users

• Examine and manipulate the objects within that database.


© Copyright IBM Corp. 2008 Part 3. Accessing DB2 data 3-1

Instructor Guide


Notes:


Unit objectives

After completing this unit, you should understand how to:



• Examine and manipulate the objects within that database




Uempty
Instructor notes:
Purpose —






Instructor Guide


Notes:



• Ability to identify DB2 objects

• Knowledge of basic characteristics and properties of DB2 objects

• Given a DDL SQL statement, knowledge to identify results (ability to create objects)




Uempty
Instructor notes:
Purpose —






Instructor Guide

Figure 3-3. What makes up a DB2 database? CE5001.0

Notes:


What makes up a DB2 database?

• A DB2 database is made up of a collection of objects

• The database contains many of the following physical and logical objects:– Tables, views, indexes, schemas– Locks, triggers, stored procedures, packages– Buffer pools, log files, table spaces




Uempty
Instructor notes:
Purpose —

Details — A DB2 database is actually made up of a collection of objects. From the user's perspective, a database is a collection of tables that are usually related in some way.

From the perspective of a database administrator (DBA -- that's you), it's a little more complicated than that. The actual database contains many of the following physical and logical objects:

• Tables, views, indexes, schemas

• Locks, triggers, stored procedures, packages

• Buffer pools, log files, table spaces





Instructor Guide

Figure 3-4. DB2 object hierarchy CE5001.0

Notes:


DB2 object hierarchy

Database 1

Instance 1

Log

DB configuration file

Index1

Index2BLOBs

Table1

Index1

Catalog

View1

View2

Table2 Table3

TSDMSREG2

SYSCATSPACE

TSDMSLRG3

dbm configuration file

Database 2Log

DB configuration file

Catalog

View1

Table2

SYSCATSPACE

USERSPACE1TSSMS1 TSDMSLRG1




Uempty
Instructor notes:
Purpose —

Details — Each DB2 instance has its own database manager configuration file. Its global parameters affect the system resources allocated to DB2 for an individual instance. Its parameters may be changed from the system default values to improve performance or increase capacity, depending on the workstation configuration.

Each instance may have multiple databases. A relational database presents data as a collection of tables. A table consists of a defined number of columns and any number of rows. Each database includes a set of system catalog tables, which describe the logical and physical structure of the data (like a table or view), or contain statistics of the data distribution; a configuration file containing the parameter values allocated for the database; and a recovery log with ongoing transactions and archiveable transactions.

Each table may have multiple indexes. Indexes may provide a faster way to access table data. Each table may have multiple views.

Views may be associated with more than one base table.

The physical objects in a database are assigned to table spaces. When creating a table, you can decide to have certain objects such as indexes and large object (LOB) data kept separately from the rest of the table data. By default, all objects referencing a table reside in the same table space where the table itself resides. A table space can also be spread over one or more physical storage devices.

In the visual, two databases are shown.

For Database 1:

The system catalog tables are in table space SYSCATSPACE.

Table 1 and its one Index are in a SMS table space named TSSMS1.

Tables 2 and Table 3 are both assigned to the Large DMS table space TSDMSLRG1.

Two Indexes for Table 3 are assigned to the Regular table space TSDMSREG2.

The Large Object data columns from Table 3 are assigned to the Large table space TSDMSLRG3.

For Database 2:

The system catalog tables are in table space SYSCATSPACE.

Table 2 is assigned to the table space USERSPACE1. By default, USERSPACE1 would be an Automatic Storage managed table space.





Instructor Guide

Figure 3-5. Default table space containers with Automatic Storage CE5001.0

Notes:


Defaulttable space containers with Automatic Storage

inst20

C0000000.CAT

DSS

dbauto

NODEnnnn

CREATE DATABASE DSS ON /dbauto DBPATH ON /database

DB2INSTANCE=inst20

T0000000

T0000001

T0000002C0000000.LRG

C0000000.TMP

USERSPACE1

SYSCATSPACE (Catalog Partition Only)

TEMPSPACE1




Uempty
Instructor notes:
Purpose —

Details — If automatic storage is enabled when a new database is created, DB2 will use automatic storage management for the three system default table spaces. The number of containers and the names will depend on the number of and names of the automatic storage paths defined.

The example assumes that the database named DSS is created in the instance named inst20 with a single automatic storage path defined, named /dbauto. The table space SYSCATSPACE will only have containers on the catalog partition. The other two table spaces. USERSPACE1 and TEMPSPACE1 will have containers defined, but will not contain any data.





Instructor Guide

Figure 3-6. Creating your first database CE5001.0

Notes:


Creating your first database




Uempty
Instructor notes:
Purpose —

Details — As part of the DB2 installation process, the First Steps panel is displayed allowing the user to generate a number of a sample databases to work with.

Selecting the Database Creation option will display an additional menu to allow you to create the SAMPLE database.

Most users will want to create the SAMPLE database and use that to explore the features of DB2. This panel can be invoked by selecting First Steps from within the Setup Tools folder in the DB2 Program group (in Windows environments). In addition, issuing the command db2sampl from a command-line prompt will also generate the SAMPLE database. Once the SAMPLE button has been selected, an additional panel is displayed to determine where the SAMPLE database will be created.





Instructor Guide

Figure 3-7. Control Center CE5001.0

Notes:


Control Center




Uempty
Instructor notes:
Purpose —

Details — The Control Center can be used to create and manage your databases.





Instructor Guide

Figure 3-8. Create Database Wizard CE5001.0

Notes:


Create Database Wizard




Uempty
Instructor notes:
Purpose —

Details — Part of the syntax of the CREATE DATABASE statement relation to the table space definitions is explained here, referencing the syntax diagram in the visual.

MANAGED BY SYSTEM

Specifies that the table space is to be an SMS table space. When the type of table space is not specified, the default behavior is to create a regular table space.

DATABASE

Specifies that the table space is to be a DMS table space. When the type of table space is not specified, the default behavior is to create a large table space.

AUTOMATIC STORAGE

Specifies that the table space is to be an automatic storage table space. If automatic storage is not defined for the database, an error is returned (SQLSTATE 55060).

An automatic storage table space is created as either a system managed space (SMS) table space or a database managed space (DMS) table space. When DMS is chosen and the type of table space is not specified, the default behavior is to create a large table space. With an automatic storage table space, the database manager determines which containers are to be assigned to the table space, based upon the storage paths that are associated with the database.

EXTENTSIZE

Specifies the number of PAGESIZE pages that will be written to a container before skipping to the next container. The extent size value can also be specified as an integer value followed by K (for kilobytes) or M (for megabytes). If specified in this way, the floor of the number of bytes divided by the page size is used to determine the value for the extent size. The database manager cycles repeatedly through the containers as data is stored.

The default value is provided by the DFT_EXTENT_SZ database configuration parameter, which has a valid range of 2-256 pages.

PREFETCHSIZE

Specifies to read in data needed by a query prior to it being referenced by the query, so that the query need not wait for I/O to be performed.

The default value is provided by the DFT_PREFETCH_SZ database configuration parameter.

OVERHEAD

Specifies the I/O controller overhead and disk seek and latency time. This value is used to determine the cost of I/O during query optimization. The value of number-of-milliseconds is any numeric literal (integer, decimal, or floating point). If this value is not the same for all



Instructor Guide

containers, the number should be the average for all containers that belong to the table space.

For a database that was created in Version 9 or later, the default I/O controller overhead and disk seek and latency time is 7.5 milliseconds. For a database that was migrated from a previous version of DB2 to Version 9 or later, the default is 12.67 milliseconds.

TRANSFERRATE

Specifies the time to read one page into memory. This value is used to determine the cost of I/O during query optimization. The value of number-of-milliseconds is any numeric literal (integer, decimal, or floating point). If this value is not the same for all containers, the number should be the average for all containers that belong to the table space.

For a database that was created in Version 9 or later, the default time to read one page into memory is 0.06 milliseconds. For a database that was migrated from a previous version of DB2 to Version 9 or later, the default is 0.18 milliseconds.

AUTORESIZE

Specifies whether or not the auto-resize capability of a DMS table space or an automatic storage table space is to be enabled. Auto-resizeable table spaces automatically increase in size when they become full. The default is NO for DMS table spaces and YES for automatic storage table spaces.

INITIALSIZE

Specifies the initial size, per database partition, of an automatic storage table space. This option is only valid for automatic storage table spaces. The integer value must be followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). Note that the actual value used might be slightly smaller than what was specified, because the database manager strives to maintain a consistent size across containers in the table space. Moreover, if the table space is auto-resizeable and the initial size is not large enough to contain meta-data that must be added to the new table space, DB2 will continue to extend the table space by INCREASESIZE until there is enough space. If the table space is auto-resizeable, but the INITIALSIZE clause is not specified, the database manager determines an appropriate value.

INCREASESIZE

Specifies the amount, per database partition, by which a table space that is enabled for auto-resize will automatically be increased when the table space is full, and a request for space has been made. The integer value must be followed by:

• PERCENT to specify the amount as a percentage of the table space size at the time that a request for space is made. When PERCENT is specified, the integer value must be between 0 and 100 (SQLSTATE 42615).

• K (for kilobytes), M (for megabytes), or G (for gigabytes) to specify the amount in bytes.

Note that the actual value used might be slightly smaller or larger than what was specified, because the database manager strives to maintain consistent growth across containers in




Uempty
the table space. If the table space is auto-resizeable, but the INCREASESIZE clause is not specified, the database manager determines an appropriate value.
MAXSIZE

Specifies the maximum size to which a table space that is enabled for auto-resize can automatically be increased. If the table space is auto-resizeable, but the MAXSIZE clause is not specified, the default is NONE.





Instructor Guide

Figure 3-9. CREATE DATABASE syntax CE5001.0

Notes:


CREATE DATABASE syntaxCREATE DATABASE

DBdatabase-name

AT DBPARTIONNUM|Create Database Options|

USING CODESET TERRITORYcodeset territory

CATALOG TABLESPACE |tblspace-defn|

USER TABLESPACE |tblspace-defn|

Create Database options:

ON pathdrive

ALIAS db-alias

DFT_EXTENT_SZ dft-extentsizeCOLLATE USING SYSTEMIDENTITY

tblspace-defn: ,

EXTENTSIZE PREFETCHSIZEnum-pages num-pages

WITH

TEMPORARY TABLESPACE |tblspace-defn|

"comment-string"

TRANSFERRATEOVERHEAD number-of-milliseconds number-of-milliseconds

| MANAGED BY SYSTEM USING

DATABASE USING FILEDEVICE

'container-string'

'container-string' num-pages

(

(

)

),

|autoconfigure-settings|

PAGESIZE 4096K

AUTOMATIC STORAGE YESNO

DBPATHON

pathdrive

,

n

RESTRICTIVE




Uempty
Instructor notes:
Purpose —

Details — The CREATE DATABASE command initializes a new database with an optional user-defined collating sequence (through API only), creates the three initial table spaces, creates the system catalog tables, and allocates the recovery log.

Only a SYSADM or SYSCTRL may create databases. The CREATE DATABASE command may be executed using CLP, or the Control Center, or through an application program invoking an API.

Command Parameters

database-name - Unique name to be assigned to the new database. 1-8 characters long.

• Must begin with alphabetic character, @, #, or $ • May contain a-z, A-Z, 0-9, @, #, $, or _ (underscore)

AT DBPARTITIONNUM - Specifies that the database is to be created only on the database partition that issues the command. You do not specify this option when you create a new database. You can use it to recreate a database partition that you dropped because it was damaged. After you use the CREATE DATABASE command with the AT DBPARITIONNUM option, the database at this database partition is in the restore-pending state. You must immediately restore the database on this node. This parameter is not intended for general use.

AUTOMATIC STORAGE - Specifies that automatic storage is being explicitly disabled or enabled for the database. The default value is YES. If the AUTOMATIC STORAGE clause is not specified, automatic storage is implicitly enabled by default. NO = Automatic storage is not being enabled for the database.

ON path/drive - On Linux/UNIX platforms, the path on which to create the database can be specified. By default, the DFTDBPATH parameter specified in the database manager configuration file is used. On Windows platforms, the letter of the drive on which to create the database can be specified.

DBPATH ON path/drive - If automatic storage is enabled, the DBPATH ON option specifies the path on which to create the database. If automatic storage is enabled and the DBPATH ON option is not specified, the database is created on the first path listed with the ON option. The maximum length of a database path is 215 characters and the maximum length of a storage path is 175 characters.

database-alias - An alias for the database. Defaults to the database name. The alias name is used by applications to connect to the database.

USING codeset/territory - Specifies the codeset and territory to be used for data entered into this database.

COLLATE USING - Identifies the type of collating sequence to be used for this database. SYSTEM indicates that the collating sequence is based on the current territory. IDENTITY



Instructor Guide

indicates that the collating sequence is the identity sequence, where strings are compared byte by byte.

PAGESIZE integer - Specifies the page size of the default buffer pool along with the initial table spaces (SYSCATSPACE, TEMPSPACE1, USERSPACE1) when the database is created. This also represents the default page size for all future CREATE BUFFERPOOL and CREATE TABLESPACE statements. The valid values for integer without the suffix K are 4096, 8192, 16384, or 32768. The valid values for integer with the suffix K are 4, 8, 16, or 32. At least one space is required between the integer and the suffix K. The default is a page size of 4096 bytes (4 K).

dft-extentsize - Specifies the default extent size of table spaces in the database.

RESTRICTIVE - If the RESTRICTIVE option is present it causes the RESTRICT_ACCESS database configuration parameter to be set to YES and no privileges are automatically granted to PUBLIC. If the RESTRICTIVE option is not present then the RESTRICT_ACCESS database configuration parameter is set to NO and a variety of privileges are automatically granted to PUBLIC.

tblspace-defn - Specifies the definition of the table space which will be used to hold the catalog tables (CATALOG TABLESPACE - SYSCATSPACE), initial user table space (USER TABLESPACE - USERSPACE1), and initial temporary table space (TEMPORARY TABLESPACE - TEMPSPACE1).

“comment string” - Up to 30-character comment describing the database.

autoconfigure-settings - Based on user input, calculates the recommended settings for buffer pool size, database configuration, and database manager configuration and optionally applies them.






Uempty

Figure 3-10. CREATE DATABASE examples CE5001.0

Notes:


CREATE DATABASE examplesCREATE DATABASE sales1 ON /dbsales1– Database Path: /dbsales1– Automatic Storage Path: /dbsales1

CREATE DATABASE sales2 AUTOMATIC STORAGE no ON/dbsales2– Database Path: /dbsales2– Automatic Storage not enabled

CREATE DATABASE sales3 ON /dbauto3 DBPATH ON /dbsales3– Database Path: /dbsales3– Automatic Storage Path: /dbauto3

CREATE DATABASE sales4 AUTOMATIC STORAGE yesON /dbauto41,/dbauto42,/dbauto43DBPATH ON /dbsales4– Database Path: /dbsales4– Automatic Storage Paths: /dbauto41, /dbauto42 and /dbauto43



Instructor Guide

Instructor notes:

Purpose —

Details — The visual shows several examples of the CREATE DATABASE statement.

The first example:

create database sales1 on /dbsales1

The Database Path for this database would be /dbsales1. The database would have automatic storage enabled with one automatic storage path, /dbsales1 being the same as the database path.

The second example:

create database sales2 automatic storage no on /dbsales2

The Database Path for this database would be /dbsales2. The database would have automatic storage disabled. SMS table space management would be used for the three system table spaces and the containers would use the database path.

The next example:

create database sales3 on /dbauto3 dbpath on /dbsales3

The Database Path for this database would be /dbsales3. The database would have automatic storage enabled with one automatic storage path, /dbauto3.

The next example:

create database sales4 automatic storage yes on /dbauto41,/dbauto42,/dbauto43 dbpath on /dbsales4

The Database Path for this database would be /dbsales4. The database would have automatic storage enabled with three automatic storage paths, /dbauto41, /dbauto42 and /dbauto43.






Uempty

Figure 3-11. Database Configuration CE5001.0

Notes:


Database Configuration



Instructor Guide

Instructor notes:

Purpose —

Details — Use the Database Configuration window to view or change the database configuration parameter values. The database configuration parameters (Keyword) and their values for this database are displayed. You can use the options available from View to rearrange the display.

The database configuration file is created when a DB2 database is created. The parameters it contains affect resources at the database level. Values for many of these parameters can be changed from the default values to improve performance.

CLP or the Control Center may be used to get a listing of the database configuration file. The GET DB CFG command will list the parameters contained in the database configuration file.

The updatable parameters in the database configuration file can be changed using the UPDATE DB CFG command, or via the database configuration GUI.

The database territory, code set, country code, and code page are recorded in the database configuration file. However, these parameters cannot be changed.






Uempty

Figure 3-12. CREATE TABLESPACE syntax (1 of 2) CE5001.0

Notes:


CREATE TABLESPACE syntax (1 of 2)REGULAR

CREATE

LARGE

tablespace-nameTABLESPACE

DATABASE PARTITION GROUP

IN db-partition-group-name

PAGESIZE 4096

PAGESIZE integerK

OVERHEAD7.5number-of-milliseconds

TRANSFERRATE0.06number-of-milliseconds

MANAGED BY | system-containers ||database-containers | num-pagesEXTENTSIZE

integer KMG

BUFFERPOOL bufferpool-nameAUTOMATICnum-pages

PREFETCHSIZE

integer KMG

SYSTEM

USERTEMPORARY

SYSTEMDATABASE

AUTOMATIC STORAGE | size-attributes |

FILE SYSTEM CACHINGNO FILE SYSTEM CACHING

DROPPED TABLE RECOVERY ONOFF



Instructor Guide

Instructor notes:

Purpose —

Details — The CREATE TABLESPACE statement creates a new table space within the database, assigns containers to the table space, and records the table space definition and attributes in the catalog. Only users with SYSADM or SYSCTRL authority can create table spaces.

REGULAR - Stores all kinds of permanent data. This type applies to both DMS and SMS table spaces. Only type allowed for SMS table spaces, and also the default type for SMS table spaces when no type is specified.

LARGE - Stores all kinds of permanent data. This type is only allowed on database managed space (DMS) table spaces. It is also the default type for DMS table spaces when no type is specified. When a table is placed in a large table space: the table can be larger than a table in a regular table space; the table can support more than 255 rows per data page, which can improve space utilization on data pages; indexes that are defined on the table will require an additional 2 bytes per row entry, compared to indexes defined on a table that resides in a regular table space.

SYSTEM TEMPORARY Stores system temporary tables. These are work areas used by the database manager to perform operations such as sorts or joins. The keyword SYSTEM is optional. A database must always have at least one SYSTEM TEMPORARY table space, as system temporary tables can only be stored in such a table space. A SYSTEM TEMPORARY table space is always created when a database is created. A database can have more than one temporary table space. Temporary objects are allocated between the temporary table spaces in a round-robin fashion.

Recommendation: Create as few system temporary table spaces as possible. It is better to put all of the containers into a single table space rather than dividing them up among multiple table spaces. Any given activity that uses a system temporary table space (for example, a sort) will use only one system temporary table space. If the system temporary table space it uses is too small, the activity will fail.

USER TEMPORARY - Stored declared global temporary tables. No USER TEMPORARY table spaces exist when a database is created. At least one user temporary table space should be created with appropriate USE privileges to allow definition of declared temporary tables.

tablespace-name - Names the table space. This is a one-part name.

IN DATABASE PARTITION GROUP db-partition-group-name - Specifies the database partition group for the table space in a partitioned database. The database partition group must exist. The only database partition group that can be specified when creating a SYSTEM TEMPORARY table space is IBMTEMPGROUP. The DATABASE PARTITION GROUP keyword is optional. If the database partition group is not specified, the default database partition group, IBMDEFAULTGROUP, is used for REGULAR, LONG, and USER TEMPORARY table spaces. For SYSTEM TEMPORARY table spaces, the default database partition group is IBMTEMPGROUP.




Uempty
PAGESIZE integer K - Defines the size of pages used for the table space. The valid page sizes are 4 KB, 8 KB, 16 KB, or 32 KB. The default is 4096 or 4 KB pages, unless overridden on CREATE DATABASE statement.
MANAGED BY AUTOMATIC STORAGE - Specifies that the table space is to be an automatic storage table space. If automatic storage is not defined for the database, an error is returned. Automatic storage table space is created as either a system managed space (SMS) table space or a database managed space (DMS) table space. When DMS is chosen and the type of table space is not specified, the default behavior is to create a large table space. With an automatic storage table space, the database manager determines which containers are to be assigned to the table space, based upon the storage paths that are associated with the database.

EXTENTSIZE num-pages - Specifies the number of PAGESIZE pages that will be written to a container before skipping to the next container. The extent size value can also be specified as an integer value followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). The number of pages for the extent size will then be calculated by DB2 by considering the page size and the extent size indicated. The database manager cycles repeatedly through the containers as data is stored.

The default value is provided by the DFT_EXTENT_SZ configuration parameter.

size-attributes - Specify the size attributes for an automatic storage table space or a DMS table space that is not an automatic storage table space. SMS table spaces are not auto-resizeable.

AUTORESIZE - Specifies whether or not the auto-resize capability of a DMS table space or an automatic storage table space is to be enabled. Auto-resizeable table spaces automatically increase in size when they become full. The default is NO for DMS table spaces and YES for automatic storage table spaces.

INITIALSIZE - Specifies the initial size, per database partition, of an automatic storage table space. This option is only valid for automatic storage table spaces. The integer value must be followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). The actual value used might be slightly smaller than what was specified, because the database manager strives to maintain a consistent size across containers in the table space. Moreover, if the table space is auto-resizeable and the initial size is not large enough to contain meta-data that must be added to the new table space, DB2 will continue to extend the table space by INCREASESIZE until there is enough space. If the table space is auto-resizeable, but the INITIALSIZE clause is not specified, the database manager determines an appropriate value.

INCREASESIZE - Specifies the amount, per database partition, by which a table space that is enabled for auto-resize will automatically be increased when the table space is full, and a request for space has been made. The integer value must be followed by: PERCENT to specify the amount as a percentage of the table space size at the time that a request for space is made. When PERCENT is specified, the integer value must be between 0 and 100; or integer K (for kilobytes), M (for megabytes), or G (for gigabytes) to specify the amount in bytes.



Instructor Guide

MAXSIZE - Specifies the maximum size to which a table space that is enabled for auto-resize can automatically be increased. If the table space is auto-resizeable, but the MAXSIZE clause is not specified, the default is NONE. An integer value specifies a hard limit on the size, per database partition, to which a DMS table space or an automatic storage table space can automatically be increased.

PREFETCHSIZE number-of-pages - Specifies the number of PAGESIZE pages that will be read from the table space when data prefetching is being performed. Prefetching reads in data needed by a query prior to it being referenced by the query, so the query need not wait for I/O to be performed. The prefetch size value can also be specified as an integer value followed by K (for kilobytes), M (for megabytes), or G (for gigabytes). The number of pages for the prefetch size will then be calculated by DB2 by considering the page size and the prefetch size indicated. The default value is provided by the DFT_PREFETCH_SZ database configuration parameter.

• For performance reasons, the PREFETCHSIZE should be a multiple of the EXTENTSIZE. PREFETCHSIZE should be equal to the number of containers multiplied by the extentsize.

• Because prefetching is a means to improve query performance, setting the correct prefetch size is an important step in performance tuning. This parameter is now AUTOMATIC by default, allowing DB2 to calculate an appropriate prefetch size for a table space based on the extent size, the number of containers, and the number of physical spindles per container. This frees the user from having to determine the appropriate value for the table space prefetch size and from having to remember to reset this value when any containers are added or removed from a table space.

BUFFERPOOL bufferpool-name - The name of the buffer pool used for tables in this table space. The buffer pool must exist. If not specified, the default buffer pool, IBMDEFAULTBP, is used.

OVERHEAD number-of-milliseconds - Any numeric literal that specifies the I/O controller overhead and disk seek and latency time, in milliseconds. The number should be an average for all containers that belong to the table space, if not the same for all containers.

TRANSFERRATE number-of-milliseconds - Any numeric literal that specifies the time to read one page into memory, in milliseconds. The number should be an average for all containers that belong to the table space, if not the same for all containers.

In a partitioned database where more than one partition resides on the same physical node, the same device or specific path cannot be specified for the database partitions on the same physical node. For this environment, either specify a unique container-string for each partition or use a relative path name.

The limit in the number of table spaces in a database is 32768 (32K). Allows administrators to create many more table spaces in a large installation. This value is generally transparent to applications and does not adversely affect applications or database performance and has the potential to improve memory utilization.





Uempty

Figure 3-13. CREATE TABLESPACE syntax (2 of 2) CE5001.0

Notes:


CREATE TABLESPACE syntax (2 of 2)

on-db-partitions-clause:

TO

db-partition-number1

db-partition-number2

( )

,ON DBPARTITIONNUM

DBPARTITIONNUMS

system-containers:

,

USING

| on-db-partitions-clause |

'container-string'( )

database-containers:

USING

| on-db-partitions-clause |

| container-clause |

container-clause:

FILE

DEVICE

'container-string' num-pagesinteger

( )

,

KMG

AUTORESIZE YESNO

INITIALSIZE int KMG

MAXSIZE int KMG

NONE

INCREASESIZE int

KMG

perc

size-attributes:



Instructor Guide

Instructor notes:

Purpose —

Details — MANAGED BY SYSTEM - Specifies that the table space is to be a SMS table space.

USING (‘container-string') - Identifies one or more containers that will belong to the table space and into which the table space's data will be stored. Each container string can be an absolute or relative directory name.

MANAGED BY DATABASE - Specifies that the table space is to be a DMS table space.

USING (FILE | DEVICE ‘container-string' number-of-pages - Identifies one or more containers that will belong to the table space and into which the table space's data will be stored. The type of the container (either FILE or DEVICE) and its size (in PAGESIZE pages) are specified.

• For a FILE container, the string must be an absolute or relative file name.

• For a DEVICE container, the string must be a device name. The device must already exist.

All containers must be unique across all databases on a single physical node; a container can belong to only one table space. The size of the containers can differ, however optimal performance is achieved when all containers are the same size.

on-partitions-clause - Specifies the partition or partitions on which the containers are created in a partitioned database environment. If this clause or any other on-partitions-clause of this statement is not specified, then the containers are created on all partitions currently in the database partition group. For a SYSTEM TEMPORARY table space defined on database partition group IBMTEMPGROUP, when the clause is not specified, the containers will also be created on all new partitions added to the database. The partitions specified by the partition number and every number in a range of partitions must exist in the database partition group on which the table space is defined. A partition-number may only appear explicitly or within a range in exactly one on-partitions-clause for the statement.






Uempty

Figure 3-14. Cataloging your DB2 database CE5001.0

Notes:


Cataloging your DB2 database

CATALOG

DB

database-nameDATABASE

AS -- alias

AT NODE -- nodename

ON path

drive

CLIENTSERVER_ENCRYPT

KERBEROS TARGET PRINCIPAL--principalnameDATA_ENCRYPT

GSSPLUGIN

SERVERAUTHENTICATION

WITH -- "comment-string"



Instructor Guide

Instructor notes:

Purpose —

Details — DB2 automatically catalogs databases when they are created. It catalogs an entry for the database in the local database directory and another entry in the system database directory. If the database is created from a remote client (or for a client that is executing from a different instance on the same machine), an entry is also made in the system database directory at the client instance.

So, why does a database have to be cataloged? Without this information, an application can't connect to a database! DB2 has multiple directories that are used to access databases. These directories allow DB2 to find databases known to it whether they are on the local system or a remote system. The system database directory contains a list and pointer indication where each of the known databases can be found. The node directory contains information relating to how and where remote systems or instances can be found. To put an entry into any of these directories, a CATALOG command is used. To remove an entry, the UNCATALOG command is used.






Uempty

Figure 3-15. Configuration Assistant (1 of 2) CE5001.0

Notes:


Configuration Assistant (1 of 2)



Instructor Guide

Instructor notes:

Purpose —

Details — Use the Configuration Assistant to configure and maintain the database objects that you or your applications will be using. Each database that will be accessed must be configured at your DB2 client before you can work with it. You must configure your DB2 clients so they can work with the available objects. From the Configuration Assistant, you can work with existing database objects, add new ones, bind applications, set database manager configuration parameters, and import and export configuration information. The Configuration Assistant's graphical interface makes these complex tasks easier through:

• Wizards that help you perform certain tasks.

• Dynamic fields that are activated based on your input choices.

• Hints that help you make configuration decisions.

• Discovery that can retrieve information that is known about selected database objects.






Uempty

Figure 3-16. Configuration Assistant (2 of 2) CE5001.0

Notes:


Configuration Assistant (2 of 2)



Instructor Guide

Instructor notes:

Purpose —

Details — The Configuration Assistant displays a list of the databases to which your applications can connect and access data. Each database is identified by its database alias. You can use the Add Database Wizard to add databases to the list. You can use the Change Database Wizard to alter the information associated with databases in the list.

The Configuration Assistant also has an Advanced view which uses a notebook to organize connection information by object: Systems, Instance Nodes, Databases, Database Connection Services (DCS), and Data Sources. You can use the notebook pages to perform object specific actions.






Uempty

Figure 3-17. Manipulating DB2 objects with the Control Center CE5001.0

Notes:


Manipulating DB2 objects with the Control Center

Menu barControl bar

Objectspane

Contentspane

Contents paneTool bar

Details



Instructor Guide

Instructor notes:

Purpose —

Details — The Control Center is the central point of administration for DB2. The Control Center provides the user with the tools necessary to perform typical database administration tasks. It allows easy access to other server administration tools, gives a clear overview of the entire system, enables remote database management, and provides step-by-step assistance for complex tasks.

So why did we go through all that pain of learning how to create databases from the command line? Although the Control Center makes your life easier, there are times when you want to create scripts that automatically create objects or invoke database maintenance. The Control Center can help you generate, manage, and schedule these scripts, but they are all run as DB2 commands. And in some cases, the Control Center may not be available on the operating system you are using, so you'll have no alternative but to use DB2 commands.

While the Control Center is certainly useful for creating databases, it has a lot of additional functionality you can use to create, modify, or delete almost any database object.

New objects are created by right-clicking the object name in the Objects pane. If you need to modify or delete an object, you need to display it in the Contents pane on the right side of the Control Center.

There are a number of actions that can be performed against table objects. For example, you can view the sample contents of the table, alter the table, or reorganize it.

The Control Center also contains the Details pane which gives more details about an item that was selected in the Object pane. This feature is particularly useful since it gives you a quick view of the table definition. For instance, when a table is selected, the Details pane will display the table schema (the column definition) along with options to display the table contents, query the table, or show related objects.






Uempty


Notes:


Unit summary

Having completed this unit, you should understand how to:



• Examine and manipulate the objects within that database



Instructor Guide

Instructor notes:

Purpose —







Uempty
Part 4. Working with DB2 data
Estimated time

01:00



• Understanding the fundamentals of SQL, with a focus on SQL language elements

• Using DML to select, insert, update, or delete data

• Using COMMIT and ROLLBACK statements to manage transactions, and know what constitutes a transaction boundary

• Creating and call SQL procedures or invoke user-defined functions from the command line



• Identify the fundamentals of SQL, with a focus on SQL language elements

• Use DML to select, insert, update, or delete data

• Use COMMIT and ROLLBACK statements to manage transactions, and know what constitutes a transaction boundary

• Create and call SQL procedures or invoke user-defined functions from the command line


© Copyright IBM Corp. 2008 Part 4. Working with DB2 data 4-1

Instructor Guide


Notes:


Unit objectives









Uempty
Instructor notes:
Purpose —






Instructor Guide


Notes:



• Given a DML SQL statement, knowledge to identify results

• Ability to use SQL to SELECT data from tables

• Ability to use SQL to SORT or GROUP data

• Ability to use SQL to UPDATE, DELETE, or INSERT data

• Knowledge of transactions (that is, commit/rollback and transaction boundaries)

• Ability to call a procedure or invoke a user-defined function




Uempty
Instructor notes:
Purpose —






Instructor Guide

Figure 4-3. The parts of speech of SQL CE5001.0

Notes:


The parts of speech of SQL

• SQL is a language that is used to define and manipulate database objects.

• There are several types of SQL:– DDL: Data Definition Language– DML: Data Manipulation Language– DCL: Data Control Language

– Use SQL to:• Define a database table (DDL)• Insert data into the table (DML)• Change the data in the table (DML)• Retrieve data from the table (DML)• Change security on database objects (DCL)

• In this unit, we will concentrate on DML.




Uempty
Instructor notes:
Purpose —

Details — Like all languages, SQL has a defined syntax and a set of language elements.





Instructor Guide

Figure 4-4. Types of SQL statements CE5001.0

Notes:


Types of SQL statements

• Most SQL statements contain one or more of the following language elements:– Single-byte characters can be a letter, a digit (0-9), or a special character.– A token is a sequence of one or more characters. – An SQL identifier is a token that is used to form a name.– The data type of a value determines how DB2 interprets that value. – A constant specifies a value. – A special register is a storage area that is defined for an application process by

the database manager and is used to store information that can be referenced in SQL statements.

– A routine can be a function, a method, or a procedure.• A function is a relationship between one or more input data values and one or more

result values. • A method is also a relationship between a set of input data values and a set of result

values. However, database methods are defined, either implicitly or explicitly, as part of the definition of a user-defined structured type.

• A procedure is an application program that can be started by executing a CALL statement.

– An expression specifies a value.– A predicate specifies a condition that is true, false, or unknown about a given

row or group.




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 4-5. Data Manipulation Language (DML) – SELECT CE5001.0

Notes:


Data Manipulation Language (DML) – SELECT

• The SELECT statement is used to retrieve table or view data. In its simplest form, the SELECT statement can be used to retrieve all the data in a table.

"SELECT * FROM staff";SELECT * FROM staff FETCH FIRST 10 ROWS ONLY;SELECT name, salary FROM staff;SELECT DISTINCT dept, job FROM staff;SELECT name, salary + comm AS pay FROM staff;




Uempty
Instructor notes:
Purpose —

Details — For example, to retrieve all the STAFF data from the SAMPLE database, issue the following command:

SELECT * FROM staff

To restrict the number of rows in a result set, use the FETCH FIRST clause. For example:

SELECT * FROM staff FETCH FIRST 10 ROWS ONLY

Retrieve specific columns from a table by specifying a select list of column names separated by commas. For example:

SELECT name, salary FROM staff

Use the DISTINCT clause to eliminate duplicate rows in a result set. For example:

SELECT DISTINCT dept, job FROM staff

Use the AS clause to assign a meaningful name to an expression or an item in the SELECT list. For example:

SELECT name, salary + comm AS pay FROM staff





Instructor Guide

Figure 4-6. Data Manipulation Language (DML) – WHERE CE5001.0

Notes:


Data Manipulation Language (DML) – WHERE

• Use the WHERE clause to select specific rows from a table or view by specifying one or more selection criteria, or search conditions."SELECT name, salary FROM staff

WHERE salary > 20000";

"SELECT name, job, salary FROM staffWHERE job <> 'Mgr‘AND name LIKE 'S%'AND salary > 20000";

• Subquery"SELECT lastname FROM employee

WHERE lastname IN(SELECT sales_person FROM sales

WHERE sales_date < '01/01/1996')";

"SELECT e.salary FROM employee eWHERE e.salary <(SELECT AVG(s.salary) FROM staff s)";




Uempty
Instructor notes:
Purpose —

Details — Use the WHERE clause to select specific rows from a table or view by specifying one or more selection criteria, or search conditions. A search condition consists of one or more predicates. A predicate specifies something about a row that is either true or false.

When building search conditions, be sure to:

• Apply arithmetic operations only to numeric data types • Make comparisons only among compatible data types • Enclose character values within single quotation marks • Specify character values exactly as they appear in the database

Find the names of staff members whose salaries are greater than $20,000:

"SELECT name, salary FROM staff WHERE salary > 20000";

Enclosing the statement within double quotation marks keeps your operating system from misinterpreting special characters, such as * or >; the greater-than symbol could be interpreted as an output redirection request.

List the name, job title, and salary of staff members who are not managers and whose salary is greater than $20,000:

"SELECT name, job, salary FROM staff WHERE job <> 'Mgr' AND salary > 20000";

Find all names that start with the letter S:

SELECT name FROM staff WHERE name LIKE 'S%';

In this example, the percent sign (%) is a wild card character that represents a string of zero or more characters.

A subquery is a SELECT statement that appears within the WHERE clause of a main query and feeds its result set to that WHERE clause. For example:

"SELECT lastname FROM employee WHERE lastname IN (SELECT sales_person FROM sales WHERE sales_date < '01/01/1996')";

A correlation name is defined in the FROM clause of a query and can serve as a convenient short name for a table. Correlation names also eliminate ambiguous references to identical column names from different tables. For example:



Instructor Guide

"SELECT e.salary FROM employee e WHERE e.salary < (SELECT AVG(s.salary) FROM staff s)";






Uempty

Figure 4-7. Data Manipulation Language (DML) – ORDER BY CE5001.0

Notes:


Data Manipulation Language (DML) – ORDER BY

• Use the ORDER BY clause to sort the result set by values in one or more columns.

"SELECT name, salary FROM staffWHERE salary > 20000ORDER BY salary";



Instructor Guide

Instructor notes:

Purpose —

Details — Use the ORDER BY clause to sort the result set by values in one or more columns.

The column names that are specified in the ORDER BY clause do not have to be specified in the select list. For example:

"SELECT name, salary FROM staff WHERE salary > 20000 ORDER BY salary";

Sort the result set in descending order by specifying DESC in the ORDER BY clause:

ORDER BY salary DESC






Uempty

Figure 4-8. Data Manipulation Language (DML) – Joins CE5001.0

Notes:


Data Manipulation Language (DML) – Joins

• A join is a query that combines data from two or more tables.SELECT deptnumb, deptname, manager, id, name, dept, job

FROM org, staff;

SELECT deptnumb, deptname, id AS manager_id, name ASmanager

FROM org, staff WHERE manager = id ORDER BY deptnumb;

– Inner joins return only rows from the cross product that meet the join condition.

– Outer joins return rows that are generated by an inner join operation, plus rows that would not be returned by the inner join operation.• Left outer join• Right outer join• Full outer join



Instructor Guide

Instructor notes:

Purpose —

Details — A join adds columns to the result set. For example, a full join of two three-column tables produces a result set with six columns.

The simplest join is one in which there are no specified conditions. For example:

SELECT deptnumb, deptname, manager, id, name, dept, job FROM org, staff;

This statement returns all combinations of rows from the ORG table and the STAFF table. The first three columns come from the ORG tables, and the last four columns come from the STAFF table. Such a result set (the cross product of the two tables) is not very useful. What is needed is a join condition to refine the result set. For example, here is a query that is designed to identify staff members who are managers:

SELECT deptnumb, deptname, id AS manager_id, name AS manager FROM org, staff WHERE manager = id ORDER BY deptnumb;

To explicitly specify an inner join, rewrite the previous query with an INNER JOIN operator in the FROM clause:

... FROM org INNER JOIN staff ON manager = id ...;

There are three types of outer joins:

• A left outer join includes the inner join plus the rows from the left table that are not returned by the inner join. This type of join uses the LEFT OUTER JOIN (or LEFT JOIN) operator in the FROM clause.

• A right outer join includes the inner join plus the rows from the right table that are not returned by the inner join. This type of join uses the RIGHT OUTER JOIN (or RIGHT JOIN) operator in the FROM clause.

• A full outer join includes the inner join plus the rows from both the left table and the right table that are not returned by the inner join. This type of join uses the FULL OUTER JOIN (or FULL JOIN) operator in the FROM clause.

Construct more complex queries to answer more difficult questions.






Uempty

Figure 4-9. Data Manipulation Language (DML) – Set operators CE5001.0

Notes:


Data Manipulation Language (DML) – Set operators

• Use set operators to combine two or more queries into a single query– The UNION set operator generates a result table by combining two

or more other result tables.– The EXCEPT set operator generates a result table by including all

rows that are returned by the first query, but not by the second or any subsequent queries.

– The INTERSECT set operator generates a result table by includingonly rows that are returned by all the queries.

"SELECT sales_person FROM salesWHERE region = 'Ontario-South'

UNIONSELECT sales_person FROM sales

WHERE sales > 3";



Instructor Guide

Instructor notes:

Purpose —

Details — Combine two or more queries into a single query by using the UNION, EXCEPT, or INTERSECT set operators. Set operators process the results of the queries, eliminate duplicates, and return the final result set.

Following is an example of a query that makes use of the UNION set operator. The same query could use the EXCEPT or the INTERSECT set operator by substituting the appropriate keyword for UNION.

"SELECT sales_person FROM sales WHERE region = 'Ontario-South' UNION SELECT sales_person FROM sales WHERE sales > 3";






Uempty

Figure 4-10. Data Manipulation Language (DML) – GROUP BY CE5001.0

Notes:


Data Manipulation Language (DML) – GROUP BY

• Use the GROUP BY clause to organize rows in a result set.SELECT sales_date, MAX(sales) AS max_sales

FROM salesGROUP BY sales_date;

• Grouping sets can be used to analyze data at different levels of aggregation in a single pass (not available in DB2 z/OS).SELECT YEAR(sales_date) AS year, region, SUM(sales)AS tot_sales

FROM salesGROUP BY GROUPING SETS (YEAR(sales_date),

region, () );

• The HAVING clause is often used with a GROUP BY clause to retrieve results for groups that satisfy only a specific condition.SELECT sales_person, SUM(sales) AS total_sales

FROM salesGROUP BY sales_personHAVING SUM(sales) > 25;



Instructor Guide

Instructor notes:

Purpose —

Details — Use the GROUP BY clause to summarize results.

Use the GROUP BY clause to organize rows in a result set. Each group is represented by a single row in the result set. For example:

SELECT sales_date, MAX(sales) AS max_sales FROM sales GROUP BY sales_date;

This statement returns a list of sales dates from the SALES table. The GROUP BY clause groups the data by sales date, and the MAX function in this example returns the maximum number of sales recorded for each sales date.

A different flavor of the GROUP BY clause includes the specification of the GROUPING SETS clause. Grouping sets can be used to analyze data at different levels of aggregation in a single pass. For example:

SELECT YEAR(sales_date) AS year, region, SUM(sales) AS tot_sales FROM sales GROUP BY GROUPING SETS (YEAR(sales_date), region, () );

Here, the YEAR function is used to return the year portion of date values, and the SUM function is used to return the total in each set of grouped sales figures. The grouping sets list specifies how the data is to be grouped, or aggregated. A pair of empty parentheses is added to the grouping sets list to get a grand total in the result set.

A statement that is almost identical to the previous one, but that specifies the ROLLUP clause, or the CUBE clause instead of the GROUPING SETS clause, returns a result set that provides a more detailed perspective on the data. It might provide summaries by location or time.

The HAVING clause is often used with a GROUP BY clause to retrieve results for groups that satisfy only a specific condition. A HAVING clause can contain one or more predicates that compare some property of the group with another property of the group or a constant. For example:

"SELECT sales_person, SUM(sales) AS total_sales FROM sales GROUP BY sales_person HAVING SUM(sales) > 25";

This statement returns a list of salespeople whose sales totals exceed 25.






Uempty

Figure 4-11. Data Manipulation Language (DML) – INSERT CE5001.0

Notes:


Data Manipulation Language (DML) – INSERT

• The INSERT statement is used to add new rows to a table or a view.INSERT INTO staff VALUES

(1212,'Cerny',20,'Sales',3,90000.00,30000.00);INSERT INTO staff VALUES

(1213,'Wolfrum',20,'Sales',2,90000.00,10000.00);– Equivalent (not available on DB2 z/OS):INSERT INTO staff (id, name, dept, job, years, salary, comm) VALUES

(1212,'Cerny',20,'Sales',3,90000.00,30000.00),(1213,'Wolfrum',20,'Sales',2,90000.00,10000.00);

• A fullselect is a statement that generates a result table.CREATE TABLE pers LIKE staff;

INSERT INTO persSELECT id, name, dept, job, years, salary, comm

FROM staffWHERE dept = 38;



Instructor Guide

Instructor notes:

Purpose —

Details — The INSERT statement is used to add new rows to a table or a view. Inserting a row\ into a view also inserts the row into the table on which the view is based.

Note the two statements shown above are equivalent.

Specify a fullselect to identify data that is to be copied from other tables or views. A fullselect is a statement that generates a result table. An example is shown in these two statements:

CREATE TABLE pers LIKE staff; INSERT INTO pers SELECT id, name, dept, job, years, salary, comm FROM staff WHERE dept = 38;






Uempty

Figure 4-12. Data Manipulation Language (DML) – UPDATE CE5001.0

Notes:


Data Manipulation Language (DML) – UPDATE

• The UPDATE statement is used to change the data in a table or a view.UPDATE staff

SET dept = 51, salary = 70000WHERE id = 750;

• Equivalent (not available on DB2 z/OS):UPDATE staff

SET (dept, salary) = (51, 70000)WHERE id = 750;

• If you don't specify a WHERE clause, DB2 updates each row in the table or view!



Instructor Guide

Instructor notes:

Purpose —

Details — Change the value of one or more columns for each row that satisfies the conditions specified by a WHERE clause. For example:

UPDATE staff SET dept = 51, salary = 70000 WHERE id = 750;

Note the two statements shown above are equivalent.






Uempty

Figure 4-13. Data Manipulation Language (DML) – DELETE CE5001.0

Notes:


Data Manipulation Language (DML) – DELETE

• The DELETE statement is used to delete entire rows of data from a table.

DELETE FROM staffWHERE id IN (1212, 1213);

• If you don't specify a WHERE clause, DB2 deletes all the rows in the table or view!



Instructor Guide

Instructor notes:

Purpose —

Details — Delete each row that satisfies the conditions specified by a WHERE clause. For example:

DELETE FROM staff WHERE id IN (1212, 1213);






Uempty

Figure 4-14. Data Manipulation Language (DML) – MERGE CE5001.0

Notes:


Data Manipulation Language (DML) – MERGE• Use the MERGE statement to combine conditional update, insert, or delete

operationsMERGE INTO employee AS e

USING (SELECTempno, firstnme, midinit, lastname, workdept,phoneno, hiredate, job, edlevel, sex, birthdate,salaryFROM my_emp) AS m

ON e.empno = m.empnoWHEN MATCHED THEN

UPDATE SET (salary) = (m.salary)WHEN NOT MATCHED THEN

INSERT (empno, firstnme, midinit, lastname, workdept, phoneno, hiredate, job, edlevel, sex, birthdate, salary) VALUES

(m.empno, m.firstnme, m.midinit, m.lastname,m.workdept, m.phoneno, m.hiredate, m.job,m.edlevel, m.sex, m.birthdate, m.salary);

• Correlation names have been assigned to both the source and the target table to avoid ambiguous table references in the search condition.



Instructor Guide

Instructor notes:

Purpose —

Details — The MERGE statement updates a target table or updatable view using data from a source table. During a single operation, rows in the target that match the source can be updated or deleted, and rows that do not exist in the target can be inserted.

In the above statement:

Correlation names have been assigned to both the source and the target table to avoid ambiguous table references in the search condition. The statement identifies the columns in the MY_EMP table that are to be considered. The statement also specifies the actions that are to be taken when a row in the MY_EMP table is found to have a match in the EMPLOYEE table, or when a row does not have a match.






Uempty

Figure 4-15. Data Manipulation Language (DML) – Reference CE5001.0

Notes:


Data Manipulation Language (DML) – Reference

• Use the data-change-table-reference clause to retrieve intermediate result sets in the same unit of workSELECT salary FROM OLD TABLE (

UPDATE employee SET salary = salary * 1.07WHERE empno = '000220');

SALARY-----------

29840.00

1 record(s) selected.



Instructor Guide

Instructor notes:

Purpose —

Details — Suppose you want to give employee 000220 a 7% raise and retrieve her old salary, both in the same unit of work (UOW). You could accomplish this by using a data-change-table-reference clause, which is part of the FROM clause in an SQL statement.

In the example above:

Columns in the target of the data-change operation (insert, update, or delete) become the columns of the intermediate result table, and can be referenced by name (in this case, Salary) in the select list of the query. The keywords OLD TABLE specify that the intermediate result table is to contain values that precede the data-change operation. The keywords NEW TABLE specify that the intermediate result table is to contain values that immediately follow the data-change operation (before referential integrity evaluation and the firing of after triggers has taken place).

The keywords FINAL TABLE specify that the intermediate result table is to contain values that follow the data-change operation, referential integrity evaluation, and the firing of after triggers.

Suppose you have a CUSTOMERS table that is defined as follows:

CREATE TABLE customers ( cust_id INTEGER GENERATED ALWAYS AS IDENTITY ( START WITH 10001 ), cust_name VARCHAR(12), PRIMARY KEY (cust_id) );

The primary key for this table, Cust_ID, is an automatically generated identity column. You can use a data-change-table-reference clause to retrieve the generated identity column value that is being used as a customer number.

SELECT * FROM FINAL TABLE (INSERT INTO customers (cust_name) VALUES ('Lamarr')); CUST_ID CUST_NAME ----------- ------------ 10001 Lamarr 1 record(s) selected.






Uempty

Figure 4-16. Units of work and savepoints CE5001.0

Notes:


Units of work and savepoints

• A unit of work (UOW), also known as a transaction:– Is a recoverable sequence of operations within an application

process.– Starts implicitly when the first SQL statement within an application

process is issued against the database. • All subsequent reads and writes by the same application process are

considered part of the same UOW.

• The application ends the UOW by issuing either a COMMIT or a ROLLBACK statement

• A savepoint lets you selectively roll back a subset of actions that make up a UOW without losing the entire transaction.– You can nest savepoints and have several savepoint levels active at

the same time; this allows your application to roll back to a specific savepoint, as necessary.



Instructor Guide

Instructor notes:

Purpose —

Details — The classic example of a UOW is a simple bank transaction to transfer funds from one account to another. There is an inconsistency -- immediately after the application subtracts an amount of money from one account -- that is resolved after an equal amount of money is added to the second account. When these changes have been committed, they become available to other applications.

The COMMIT statement makes all changes made within the UOW permanent, whereas the ROLLBACK statement reverses those changes. If the application ends normally without an explicit COMMIT or ROLLBACK statement, the UOW is automatically committed. If the application ends abnormally before the end of a UOW, that unit of work is automatically rolled back.






Uempty

Figure 4-17. Creating and calling an SQL procedure CE5001.0

Notes:


Creating and calling an SQL procedure

• An SQL procedure is:– A stored procedure whose body is written in SQL. The body contains

the logic of the SQL procedure.– Created when you successfully invoke a CREATE PROCEDURE

(SQL) statement

CREATE PROCEDURE sales_status(IN quota INTEGER, OUT sql_state CHAR(5))

DYNAMIC RESULT SETS 1LANGUAGE SQL

BEGINDECLARE SQLSTATE CHAR(5);DECLARE rs CURSOR WITH RETURN FORSELECT sales_person, SUM(sales) AS total_sales

FROM salesGROUP BY sales_personHAVING SUM(sales) > quota;

OPEN rs;SET sql_state = SQLSTATE;END @



Instructor Guide

Instructor notes:

Purpose —

Details — An SQL procedure is a stored procedure whose body is written in SQL. The body contains the logic of the SQL procedure. It can include variable declarations, condition handling, flow-of-control statements, and DML. Multiple SQL statements can be specified within a compound statement, which groups several statements together into an executable block.

SQL procedures are a handy way to define more complex queries or tasks that can be called whenever they are needed.

In the example above:

• This procedure, called SALES_STATUS, accepts an input parameter called quota and returns an output parameter called sql_state. The procedure body consists of a single SELECT statement that returns the name and the total sales figures for each salesperson whose total sales exceed the specified quota.

• The parameter list for an SQL procedure can specify zero or more parameters, each of which can be one of three possible types:

- IN parameters pass an input value to an SQL procedure; this value cannot be modified within the body of the procedure.

- OUT parameters return an output value from an SQL procedure.

- INOUT parameters pass an input value to an SQL procedure and return an output value from the procedure.

SQL procedures can return zero or more result sets.

In our example, the SALES_STATUS procedure returns one result set. This has been done by:

1. Declaring the number of result sets that the SQL procedure returns in the DYNAMIC RESULT SETS clause.

2. Declaring a cursor in the procedure body (using the WITH RETURN FOR clause) for each result set that is returned. A cursor is a named control structure that is used by an application program to point to a specific row within an ordered set of rows. A cursor is used to retrieve rows from a set.

3. Opening the cursor for each result set that is returned.

4. Leaving the cursor(s) open when the SQL procedure returns.

Variables must be declared at the beginning of the SQL procedure body. To declare a variable, assign a unique identifier to and specify an SQL data type for the variable and, optionally, assign an initial value to the variable.

To call the SQL procedure SALES_STATUS, perform the following steps:

1. Connect to the SAMPLE database.




Uempty
2. Issue the following statement:
db2 "CALL sales_status (25, ?)";

In this example, a value of 25 for the input parameter quota is passed to the SQL procedure, as well as a question mark (?) place-holder for the output parameter sql_state. The procedure returns the name and the total sales figures for each salesperson whose total sales exceed the specified quota (25).





Instructor Guide

Figure 4-18. Creating and using SQL user-defined functions CE5001.0

Notes:


Creating and using SQL user-defined functions

• Create user-defined functions to extend the set of built-in DB2 functions.– Suppose that you needed a function that returns the area of a circle when the

radius of that circle is specified as an argument to the function.CREATE FUNCTION ca (r DOUBLE)

RETURNS DOUBLELANGUAGE SQLCONTAINS SQLNO EXTERNAL ACTIONDETERMINISTIC

RETURN 3.14159 * (r * r);

• Example output:db2 SELECT ca(96.8) AS area FROM sysibm.sysdummy1

AREA------------------------+2.94374522816000E+004

1 record(s) selected.




Uempty
Instructor notes:
Purpose —

Details — For example, create functions that evaluate complex mathematical expressions or manipulate strings, and then reference these functions in SQL statements like you would any existing built-in function.

The NO EXTERNAL ACTION clause specifies that the function does not take any action that changes the state of an object that the database manager does not manage. The DETERMINISTIC keyword specifies that the function always returns the same result for a given argument value. This information is used during query optimization.

A convenient way to execute the function is to reference it in a query, as shown above.





Instructor Guide

Figure 4-19. User-defined table function CE5001.0

Notes:


User-defined table function

• You can also create a user-defined table function, which takes zero or more input arguments and returns data as a table.– A table function can only be used in the FROM clause of an SQL

statement.• A function that returns the names and employee numbers of all

employees that hold a specific job:CREATE FUNCTION jobemployees (job VARCHAR(8))

RETURNS TABLE (empno CHAR(6),firstname VARCHAR(12),lastname VARCHAR(15))

LANGUAGE SQLREADS SQL DATANO EXTERNAL ACTIONDETERMINISTIC

RETURNSELECT empno, firstnme, lastname

FROM employeeWHERE employee.job = jobemployees.job;




Uempty
Instructor notes:
Purpose —

Details — The following query references the new table function in the FROM clause and passes the job title 'CLERK' as the argument to the function. A correlation name, introduced by the keyword AS, is required by the syntax:

db2 SELECT * FROM TABLE(jobemployees('CLERK')) AS clerk; EMPNO FIRSTNAME LASTNAME ------ ------------ --------------- 000120 SEAN O'CONNELL 000230 JAMES JEFFERSON 000240 SALVATORE MARINO 000250 DANIEL SMITH 000260 SYBIL JOHNSON 000270 MARIA PEREZ 6 record(s) selected.





Instructor Guide


Notes:


Unit summary

Having completed this unit, you should be able to:








Uempty
Instructor notes:
Purpose —






Instructor Guide




Uempty
Part 5. Working with DB2 objects
Estimated time

01:00



• Understanding data types and advanced data types

• Creating tables, views, and indexes in a DB2 database

• Understanding the features and use of unique constraints, referential integrity constraints, and table check constraints

• Using views to restrict access to data

• Understanding the features of indexes



• List data types and advanced data types

• Create tables, views, and indexes in a DB2 database

• Identify the features and use of unique constraints, referential integrity constraints, and table check constraints

• Use views to restrict access to data

• List the features of indexes


© Copyright IBM Corp. 2008 Part 5. Working with DB2 objects 5-1

Instructor Guide


Notes:


Unit objectives




• Identify the features and use of unique constraints, referentialintegrity constraints, and table check constraints






Uempty
Instructor notes:
Purpose —






Instructor Guide


Notes:



• Ability to demonstrate usage of DB2 data types

• Given a situation, ability to create table

• Knowledge to identify when referential integrity should be used

• Knowledge to identify methods of data constraint

• Knowledge to identify characteristics of a table, view or index

• Knowledge to identify when triggers should be used

• Knowledge of schemata

• Knowledge of data type options for storing XML data

• Knowledge of non-relational data concepts (extenders)




Uempty
Instructor notes:
Purpose —






Instructor Guide

Figure 5-3. Data types CE5001.0

Notes:


Data types

• DB2 comes with basic data types such as INTEGER, CHAR, and DATE:– It also includes facilities to create user-defined data types (UDTs)

• There are four categories of built-in data types: – Numeric, string, datetime, and XML

• The user-defined data types are categorized as: – Distinct, structured, and reference




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 5-4. Numeric data types CE5001.0

Notes:


Numeric data types

• Three categories of numeric data:– Integer: Used to store integer numbers.

• SMALLINT — Store integers from -32,768 to 32,767 in 2 bytes. • INTEGER — Store integers from -2,147,483,648 to 2,147,483,647 in 4

bytes.• BIGINT — Store integers from -9,223,372,036,854,775,808 to

9,223,372,036,854,775,807 in 8 bytes.

– Decimal: Store numbers with fractional parts• DECIMAL

– Floating point: Store approximations of numbers• REAL — Defined with a length between 1 and 24 digits and requires 4

bytes of storage.• DOUBLE — Defined with a length of between 25 and 53 digits and

requires 8 bytes of storage.




Uempty
Instructor notes:
Purpose —

Details — FLOAT can be used as a synonym for REAL or DOUBLE.





Instructor Guide

Figure 5-5. String data types CE5001.0

Notes:


String data types• DB2 provides several data types for storing character data or strings

• Single-byte character strings:– CHAR or CHARACTER — Store fixed-length character strings up to 254

bytes.– VARCHAR — Store variable-length character strings.

• The maximum length of a VARCHAR column is 32,672 bytes

• Double-byte character strings:– GRAPHIC — Store fixed-length double-byte character strings.

• The maximum length of a GRAPHIC column is 127 characters– VARGRAPHIC — Store variable-length double-byte character strings.

• The maximum length of a VARGRAPHIC column is 16,336 characters

• Long data types can be defined up to 2 GB in length– LONG VARCHAR– CLOB (character large object)– LONG VARGRAPHIC– DBCLOB (double-byte character large object)– BLOB (binary large object)




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 5-6. Datetime data types CE5001.0

Notes:


Datetime data types

• DB2 provides three data types to store dates and times:– DATE

– TIME• Several formats available: ISO, USA, EUR, and JIS.

– TIMESTAMP• Single format: yyyy-mm-dd-hh.mm.ss.nnnnnn.

– Applications can manipulate them as strings.

– Enclose the value in quotation marks when updating these data types.




Uempty
Instructor notes:
Purpose —

Details — For example, if your database is using the USA format, the format of date values would be mm/dd/yyyy.





Instructor Guide

Figure 5-7. XML data type CE5001.0

Notes:


XML data type

• Used to store well-formed XML documents:– Stored in an internal representation different from string data types.– To store XML data in an XML data type column, transform the data

using the XMLPARSE function. – An XML data type value can be transformed into a serialized string

value representation of the XML document using the XMLSERIALIZE function.

• DB2 provides many other built-in functions to manipulate XML data types.




Uempty
Instructor notes:
Purpose —

Details — Values in XML columns are stored in an internal representation different from string data types. To store XML data in an XML data type column, transform the data using the XMLPARSE function. An XML data type value can be transformed into a serialized string value representing of the XML document using the XMLSERIALIZE function. DB2 provides many other built-in functions to manipulate XML data types.





Instructor Guide

Figure 5-8. User-defined data types CE5001.0

Notes:


User-defined data types

• There are three user-defined data types:– User-defined distinct:

• Define a new data type based on a built-in type:– Has the same features of the built-in type– Can use it to ensure that only values of the same type are compared

– User-defined structured: • Create a type that consists of several columns of built-in types

– Use this structured type when creating a table

– User-defined reference: • When using structured types, you can define references to rows in

another table using reference types:– These references appear similar to referential constraints; however, they

do not enforce relationships between the tables– References in tables let you specify queries in a different way




Uempty
Instructor notes:
Purpose —

Details — DB2 allows you to define data types that suit your application. There are three user-defined data types:

User-defined distinct:

For example, you can define a Canadian dollar type (CANDOL) and a US dollar type (USADOL) both based on DECIMAL(10,2). Both types are based on the same built-in type, but you won't be able to compare them unless a conversion function is applied.

CREATE DISTINCT TYPE CANDOL AS DECIMAL(10,2) WITH COMPARISONS CREATE DISTINCT TYPE USADOL AS DECIMAL(10,2) WITH COMPARISONS

User-defined structured:

For example, you can create a structured type named ADDRESS that contains data for street number, street name, city, and so forth. Then you can use this type when defining other tables, such as employees or suppliers, because the same data is required for both.

Also, structured types can have subtypes in a hierarchical structure. This lets you store objects that belong to a hierarchy in the database.

User-defined reference:

When using structured types, you can define references to rows in another table using reference types. These references appear similar to referential constraints; however, they do not enforce relationships between tables. References in tables let you specify queries in a different way.





Instructor Guide

Figure 5-9. Create Trigger statement CE5001.0

Notes:


Create Trigger statement

CREATE TRIGGER reorderAFTER UPDATEOF qty ON stockREFERENCING NEW AS nFOR EACH ROW MODE DB2SQLWHEN (n.qty <=5)

INSERT INTO reorder VALUES(n.itemno, current timestamp);




Uempty
Instructor notes:
Purpose —

Details — Triggers can be defined to DB2 so that the database manager automatically enforces business rules that should follow an INSERT, UPDATE, or DELETE operation against the specified table. The benefits of DB2 enforcement of such rules include eliminating the need for redundant coding, global enforcement of the defined rules, and ease of maintenance if the business rules change.

Business rules that may be supported by triggers include:

• Validation of input

• Automatic generation of a value for an inserted row

• Reading from other tables for cross-referencing purposes

• Writing to other tables for audit-trail purposes

• Maintaining business rules

• Providing support for user alerts





Instructor Guide

Figure 5-10. Create Schema CE5001.0

Notes:


Create Schema

CREATE SCHEMA payroll AUTHORIZATION db2admin;COMMENT ON SCHEMA payroll IS 'schema for payroll application';




Uempty
Instructor notes:
Purpose —

Details — While organizing your data into tables, it may also be beneficial to group tables (and other related objects) together. This is done by defining a schema. Information about the schema is kept in the system catalog tables of the database to which you are connected. As other objects are created, they can be placed within this schema.

When the schema is explicitly created with the CREATE SCHEMA statement, the schema owner is granted CREATEIN, DROPIN, ALTERIN, GRANTIN privileges on the schema with ability to grant to other users.





Instructor Guide

Figure 5-11. Set current schema CE5001.0

Notes:


Set current schema

CONNECT TO musicdb USER Keith;"SELECT * FROM employee";• Will select from KEITH.EMPLOYEE

SET CURRENT SCHEMA = 'PAYROLL';SELECT * FROM employee;• Will select from PAYROLL.EMPLOYEE




Uempty
Instructor notes:
Purpose —

Details — When accessing data within DB2, unqualified references will be implicitly qualified with the authorization ID that was used to connect to the database. You can override this by setting the CURRENT SCHEMA. The initial value of the CURRENT SCHEMA special register is equivalent to USER. The example on the graphic shows that a user KEITH is connecting to the database. If Keith issues a select against the EMPLOYEE table, the table that will be accessed will be KEITH.EMPLOYEE. If he sets his current schema to PAYROLL, then a select against the EMPLOYEE table will be directed against the PAYROLL.EMPLOYEE table.

Alternative syntax includes:

SET CURRENT SCHEMA = 'PAYROLL' SET SCHEMA 'PAYROLL' SET CURRENT SQLID 'PAYROLL'

Note that the use of the = is optional in all of these statements.

The value of the CURRENT SCHEMA special register is used as the schema name in all dynamic SQL statements where an unqualified reference to a database object exists.





Instructor Guide

Figure 5-12. DB2 Extenders CE5001.0

Notes:


DB2 Extenders

• DB2 Extenders provide support for complex, nontraditional data types. – Packaged separately from the DB2 server code and installed on

the server and into each database that uses the data type.

• DB2 Extenders are implemented using the features of user-defined types and user-defined functions (UDFs). – Each extender comes with one or more UDTs, UDFs for operating

on the UDT, specific application programming interfaces (APIs), and perhaps other tools.

• For example, the DB2 Image Extender includes:– The DB2IMAGE UDT– UDFs to insert and retrieve from a DB2IMAGE column– APIs to search based on characteristics of images

• Before using these data types, install the extender support intothe database.




Uempty
Instructor notes:
Purpose —

Details — For example, use the DB2 Image Extender to store an image of a book cover and the DB2 Text Extender to store the text of a book.

The DB2 Spatial Extender could be used for storing and analyzing spatial data and the XML Extender for managing XML documents (instead of using the new XML data type in DB2 9).





Instructor Guide

Figure 5-13. Tables – CREATE CE5001.0

Notes:


Tables – CREATE

• All data is stored in tables in the database. • A table consists of one or more columns of various data types. • The data is stored in rows or records.

CREATE TABLE artists(artno smallint NOT NULL,name VARCHAR(50) WITH DEFAULT 'abc',classification CHAR(1) NOT NULL,bio CLOB(100K) LOGGED,picture BLOB( 10M) NOT LOGGED COMPACT)

IN dms01;




Uempty
Instructor notes:
Purpose —

Details — Besides user tables, a DB2 database also has a set of tables, called the system catalog tables, which hold information about all the objects in the database.

You can also use the CREATE TABLE SQL statement to create a table that is like another table or view in the database:

CREATE TABLE MYBOOKS LIKE BOOKS





Instructor Guide

Figure 5-14. Tables – ALTER CE5001.0

Notes:


Tables – ALTER

• Use the ALTER TABLE SQL statement to change characteristics of a table. – For instance, you can add or drop:

• A column• A primary key• One or more unique or referential constraints• One or more check constraints

• The following statement adds a column called BOOKTYPE to the BOOKS table:ALTER TABLE books ADD booktype CHAR(1);




Uempty
Instructor notes:
Purpose —

Details — You can also change characteristics of specific columns in a table:

• The identity attributes of a column • The length of a string column • The datatype of a column • The nullability of a column • The constraint of a column

There are restrictions on altering columns:

• When altering the length of a string column, you can only increase the length.

• When altering the datatype of a column, the new datatype must be compatible with the existing data type. For example, you can convert CHAR columns to VARCHAR columns, but cannot convert them to GRAPHIC or numeric columns. Numeric columns can be converted to any other numeric data type as long as the new datatype is large enough to hold the values. For example, convert an INTEGER column to BIGINT, but, a DECIMAL(10,2) column cannot be converted to SMALLINT.

• Fixed length strings can be converted to variable length string and variable length strings can be converted to fixed length. For example, a CHAR(100) can be converted to VARCHAR(150). Similar restrictions exist for variable length graphic strings.





Instructor Guide

Figure 5-15. Tables – DROP CE5001.0

Notes:


Tables – DROP

• The DROP TABLE statement: – Removes a table from the database

• Deleting the data and the table definition• Indexes or constraints defined on the table are dropped as well

• The following DROP TABLE statement deletes the BOOKS table from the database:DROP TABLE books;




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 5-16. Tables – NOT NULL, DEFAULT, and GENERATED CE5001.0

Notes:


Tables – NOT NULL, DEFAULT, and GENERATED

• NOT NULL:– If you do not want to allow null values, specify the NOT NULL clause

for the column.• DEFAULT:

– Specify a default value using the WITH DEFAULT clause and a default value.CREATE TABLE books (

bookid INTEGER NOT NULL,bookname VARCHAR(100) WITH DEFAULT 'TBD',isbn CHAR(10)

);

• GENERATED:– Use the GENERATED ALWAYS option to have DB2 calculate the

value of a column automatically.CREATE TABLE books (

bookid INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY(START WITH 1, INCREMENT BY 1),

bookname VARCHAR(100) WITH DEFAULT 'TBD',isbn CHAR(10)

);




Uempty
Instructor notes:
Purpose —

Details — The columns of a table are specified in the CREATE TABLE statement by a column name and data type. The columns can have additional clauses specified that restrict the data in the column.

By default, a column allows null values.





Instructor Guide

Figure 5-17. Constraints – Unique constraints CE5001.0

Notes:


Constraints – Unique constraints

• Unique constraints– Used to ensure that values in a column are unique– Can be defined over one or more columns

• Each column included in the unique constraint must be defined as NOT NULL

– Can be defined either as the PRIMARY KEY or UNIQUE constraint

CREATE TABLE books (

bookid INTEGER NOT NULL PRIMARY KEY,

bookname VARCHAR(100),

isbn CHAR(10) NOT NULL CONSTRAINT booksisbn UNIQUE

);

• The CONSTRAINT keyword lets you specify a name for the constraint.




Uempty
Instructor notes:
Purpose —

Details — DB2 provides several ways to control what data can be stored in a column. These features are called constraints or rules that the database manager enforces on a data column or set of columns.

DB2 provides three types of constraints: unique, referential integrity, and table check.

A unique key is a key (set of columns) that is constraint so that no two values are equal.

The columns of a unique key cannot contain null values.

• A primary key is a special case of a unique key. It is normally used to refer to the rows of the appropriate table.

• A table can have multiple unique keys, but cannot have more than one primary key. A key can either be defined as a unique key or as a primary key, but not both. Primary keys and unique keys can be defined using CREATE TABLE or ALTER TABLE.

• By definition, the values of a foreign key always match the values of a primary key or unique key.





Instructor Guide

Figure 5-18. Constraints – Referential integrity constraints CE5001.0

Notes:


Constraints – Referential integrity constraints

• Referential integrity constraints are used to define relationships between tables and ensure that these relationships remain valid.– A PRIMARY KEY value must be UNIQUE and cannot be NULL– By definition, a FOREIGN KEY matches a PRIMARY KEY of a UNIQUE KEY or

can be null– DB2 enforcement of referential constraints occurs during insert/update/load of

FOREIGN KEY– DB2 ensures that a PRIMARY KEY/UNIQUE KEY is updated only if no FOREIGN

KEY matches the original value of the primary/unique key

CREATE TABLE authors (authorid INTEGER NOT NULL PRIMARY KEY,lname VARCHAR(100),fname VARCHAR(100));

CREATE TABLE books (bookid INTEGER NOT NULL PRIMARY KEY,bookname VARCHAR(100),isbn CHAR(10),authorid INTEGER REFERENCES authors);




Uempty
Instructor notes:
Purpose —

Details —

• A referential constraint is a rule, enforced by the database manager, that controls the relationship between a primary key/unique key and a foreign key. Referential constraints are defined to DB2 when the foreign key is defined. They are enforced when rows containing a foreign-key value are inserted, updated, or loaded.

• DB2 prevents the updating of primary key/unique key values if there are matching foreign key values. The new values are not propagated to the appropriate rows of the dependent table. In other words, a primary key/unique key value can only be updated if no foreign key value matches the original value of the primary/unique key.





Instructor Guide

Figure 5-19. Constraints – Table check constraints CE5001.0

Notes:


Constraints – Table check constraints

• Table check constraints are used to verify that column data does not violate rules defined for the column and to restrict the values in a certain column of a table. – DB2 ensures that the constraint is not violated during inserts and

updates.

• Example:ALTER TABLE books

ADD booktype CHAR(1)

CHECK (booktype IN ('F','N') );

– You can define check constraints when you create the table or add them later using the ALTER TABLE SQL statement.

– You can modify check constraints by dropping and then recreatingthem using the ALTER TABLE SQL statement.




Uempty
Instructor notes:
Purpose —

Details —

• Many data rules are specific to the column values in a single table. Check constraints can be used to define such rules to the DB2 database manager. The database manager will then enforce these rules.

• Constraints will be checked during INSERT and UPDATE operations.

• Installations requiring such data checking should consider using constraints rather than enforcing data content via applications. Constraints are defined once, directly within DB2, and are applied globally, eliminating the need for applications to do this work.





Instructor Guide

Figure 5-20. Views CE5001.0

Notes:


Views• Views allow different users or applications to look at the same data in

different ways.– To the user, a view just looks like a table. – Except for the view definition, a view does not take up space in the

database; the data presented in a view is derived from another table. – You can create a view on an existing table (or tables), on another view, or

some combination of the two. – A view defined on another view is called a nested view.– To define column names in the view that are different from those in the base

table, you can specify them in the CREATE VIEW statement.CREATE VIEW mybookview (title,type) AS

SELECT bookname,booktype FROM books;– If you do not want to allow a user to insert rows that are outside the scope of

the view, you can define the view with the check option. – The following statement defines a view using WITH CHECK OPTION:

"CREATE VIEW nonfictionbooks ASSELECT * FROM books

WHERE booktype = 'N'WITH CHECK OPTION";




Uempty
Instructor notes:
Purpose —

Details — Nested views with check option.

When defining nested views, the check option can be used to restrict operations.

However, there are other clauses you can specify to define how the restrictions are inherited. The check option can be defined either as CASCADED or LOCAL.

CASCADED is the default if the keyword is not specified. Several possible scenarios explain the differences between the behavior of CASCADED and LOCAL.

When a view is created WITH CASCADED CHECK OPTION, all statements executed against the view must satisfy the conditions of the view and all underlying views -- even if those views were not defined with the check option. Suppose that the view NONFICTIONBOOKS is created without the check option, and you also create a view NONFICTIONBOOKS1 based on the view NONFICTIONBOOKS using the CASCADED keyword:

CREATE VIEW NONFICTIONBOOKS AS SELECT * FROM BOOKS WHERE BOOKTYPE = 'N' CREATE VIEW NONFICTIONBOOKS1 ASSELECT * FROM NONFICTIONBOOKS WHERE BOOKID > 100 WITH CASCADED CHECK OPTION

The following INSERT statements would not be allowed because they do not satisfy the conditions of at least one of the views:

INSERT INTO NONFICTIONBOOKS1 VALUES( 10,..,'N') INSERT INTO NONFICTIONBOOKS1 VALUES(120,..,'F') INSERT INTO NONFICTIONBOOKS1 VALUES( 10,..,'F')





Instructor Guide

Figure 5-21. Indexes CE5001.0

Notes:


Indexes

• An index is an ordered list of the key values of a column or columns of a table. – There are two reasons why you might create an index:

• To ensure uniqueness of values in a column or columns.• To improve performance of queries against the table.

– Indexes can be defined as unique or nonunique. – Indexes are created using the CREATE INDEX SQL statement.

• Indexes are also created implicitly in support of a PRIMARY KEY or UNIQUE constraint.

– Indexes are created as ascending, descending, or bidirectional.• Bidirectional is recommended




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 5-22. Creating indexes CE5001.0

Notes:


Creating indexes

CREATE UNIQUE INDEX dba1.empnoON dba1.employee (empno ASC)PCTFREE 10 MINPCTUSED 10 ALLOW REVERSE SCANS PAGE SPLIT SYMMETRIC COLLECT SAMPLED DETAILED STATISTICS;

CRETE UNIQUE INDEX itemno ON albums (itemno);

CREATE INDEX item ON stock (itemno) CLUSTER;

CREATE UNIQUE INDEX empidxON employee (empno)INCLUDE (lastname, firstname);




Uempty
Instructor notes:
Purpose —

Details — By default, an index is created in ascending order, but you can also create indexes that are descending. You can even specify different orders for the columns in the index.

When an index is created in a database, the keys are stored in the specified order. The index helps improve the performance of queries requiring the data in the specified order.

A bidirectional index eliminates the need to create an index in the reverse order, and it eliminates the need for the optimizer to sort the data in the reverse order.

To create a bidirectional index, specify the ALLOW REVERSE SCANS option on the CREATE INDEX statement (default).

The PCTFREE can be used to control the amount of free space left on an index page when an index is created. The default is 10% and the valid range of values is 0-90. By setting the value to a higher number, index page splits can be minimized. By setting the value to a lower number, fewer pages could be required to store the index for a read-only table.

MINPCTUSED indicates whether indexes are defragmented online and the threshold for the minimum percent of space used on an index leaf page. If, after a key is deleted from an index leaf page, the percentage of space used on the page is at or below the percentage specified for MINPCTUSED, an attempt is made to merge the remaining keys on this page with those of a neighboring page.

PAGE SPLIT specifies an index split behavior. The default is SYMMETRIC, which specifies that pages are to be split roughly in the middle.





Instructor Guide

Figure 5-23. Clustering indexes CE5001.0

Notes:


Clustering indexes

• You can create one index on each table as the clustering index:– A clustering index is useful when the table data is often referenced

in a particular order. – The clustering index defines the order in which data is stored in the

database.

• To create an index as the clustering index, specify the CLUSTER clause on the CREATE INDEX statement:CREATE INDEX iauthbkname

ON books (authorid, bookname) CLUSTER;




Uempty
Instructor notes:
Purpose —

Details — The above statement creates an index on the AUTHORID and BOOKNAME columns as the clustering index. This index would improve the performance of queries written to list authors and all the books that they have written.





Instructor Guide

Figure 5-24. Using included columns in indexes CE5001.0

Notes:


Using included columns in indexes

• When creating an index, you have the option to include extra column data that is stored with the key, but is not actually part of the key itself and is not sorted. – The main reason for including additional columns in an index is to

improve the performance of certain queries: with this data already available in the index page, DB2 does not need to access the data page to fetch it.

• Included columns can only be defined for unique indexes.

• Cons:– Requires more physical space in the database because the table

data would essentially be duplicated in the index. – All the copies of the data would need to be updated whenever the

data value is updated.




Uempty
Instructor notes:
Purpose —

Details —

INCLUDE

This keyword introduces a clause that specifies additional columns to be appended to the set of index key columns. Any columns included with this clause are not used to enforce uniqueness. These included columns might improve the performance of some queries through index only access. The columns must be distinct from the columns used to enforce uniqueness.

Note

The include columns are not used as part of the key ( not considered in the index sorting mechanism).

Suppose that you often need to get a list of book names ordered by BOOKID. The query would look like this:

SELECT BOOKID, BOOKNAME FROM BOOK ORDER BY BOOKID

Create an index that might improve performance:

CREATE UNIQUE INDEX IBOOKID ON BOOKS (BOOKID) INCLUDE(BOOKNAME)

As a result, all the data required for the query result is present in the index and no data pages need to be retrieved.





Instructor Guide


Notes:


Unit summary




• Identify the features and use of unique constraints, referentialintegrity constraints, and table check constraints






Uempty
Instructor notes:
Purpose —






Instructor Guide




Uempty
Part 6. Data concurrency
Estimated time

01:00



• Identifying factors that influence locking

• Listing objects on which locks can be obtained

• Identifying characteristics of DB2 locks

• Identifying the isolation level that should be used for a given situation



• Identify factors that influence locking

• List objects on which locks can be obtained

• Identify characteristics of DB2 locks

• Identify the isolation level that should be used for a given situation


© Copyright IBM Corp. 2008 Part 6. Data concurrency 6-1

Instructor Guide




Notes:


Unit objectives






Instructor Guide



V4.1

Uempty Instructor notes:

Purpose —




Instructor Guide




Notes:



• Knowledge to identify factors that influence locking

• Ability to list objects on which locks can be obtained

• Knowledge to identify characteristics of DB2 locks

• Given a situation, knowledge to identify the isolation levels that should be used

Instructor Guide



V4.1


Purpose —




Instructor Guide



Figure 6-3. Simple workload consisting of three transactions CE5001.0

Notes:


Simple workload consisting of three transactions

CONNECT TO my_db

CREATE TABLE department (dept_id INTEGER NOT NULL, dept_name VARCHAR(20))

INSERT INTO department VALUES(100, 'PAYROLL')INSERT INTO department VALUES(200, 'ACCOUNTING')COMMIT;

INSERT INTO department VALUES(300, 'SALES')ROLLBACK;

INSERT INTO department VALUES(500, 'MARKETING')COMMIT;

Instructor Guide



V4.1


Purpose —

Details — A transaction (also known as a unit of work) is a recoverable sequence of one or more SQL operations, grouped together as a single unit, usually within an application process. The initiation and termination of a transaction defines points of database consistency; either the effects of all SQL operations performed within a transaction are applied to the database (committed), or the effects of all SQL operations performed are completely undone and thrown away (rolled back).



Instructor Guide



Figure 6-4. Comparing successful and unsuccessful transactions CE5001.0

Notes:


Comparing successful and unsuccessful transactions

Instructor Guide



V4.1


Purpose —

Details — What happens if a system failure occurs before a transaction can be completed? In this case, the DB2 database manager will back out all uncommitted changes in order to restore the database consistency that it assumes existed when the transaction was initiated.



Instructor Guide



Figure 6-5. Lock mode compatibility CE5001.0

Notes:


Lock mode compatibility

U

YES

NO

NO

NO

YES

NO

NS

YES

YES

NO

NO

YES

YES

W

NO

NO

NO

NO

NO

YES

MODE OF LOCK BMODE OFLOCK A

IN

IS

S

IX

SIX

U

X

Z

Table Locks

MODE OF LOCK BLOCKA

MODE

S

U

X

W

NS

NW

Row Locks

IS

YES

YES

YES

YES

YES

YES

NO

NO

S

YES

YES

YES

NO

NO

YES

NO

NO

IX

YES

YES

NO

YES

NO

NO

NO

NO

IN

YES

YES

YES

YES

YES

YES

YES

NO

X

NO

NO

NO

NO

NO

NO

S

YES

YES

NO

NO

YES

NO

NW

NO

NO

NO

YES

YES

NO

SIX

YES

YES

NO

NO

NO

NO

NO

NO

U

YES

YES

YES

NO

NO

NO

NO

NO

X

YES

NO

NO

NO

NO

NO

NO

NO

Z

NO

NO

NO

NO

NO

NO

NO

NO

Instructor Guide



V4.1


Purpose —

Details — If the state of one lock placed on a data resource enables another lock to be placed on the same resource, the two locks (or states) are said to be compatible. Whenever one transaction holds a lock on a data resource and a second transaction requests a lock on the same resource, the DB2 database manager examines the two lock states to determine whether or not they are compatible.

If the locks are compatible, the lock is granted to the second transaction (provided no other transaction is waiting for the data resource).

If however, the locks are incompatible, the second transaction must wait until the first transaction releases its lock before it can gain access to the resource and continue processing. (If there is more than one incompatible lock in place, the second transaction must wait until all locks are released.)



Instructor Guide



Figure 6-6. Concurrency and isolation levels CE5001.0

Notes:


Concurrency and isolation levels

• Repeatable read (RR)

• Read stability (RS)

• Cursor stability (CS)

• Uncommitted read (UR or dirty read)

Instructor Guide



V4.1


Purpose —

Details — Maintaining database consistency and data integrity, while allowing more than one application to access the same data at the same time, is known as concurrency.

One of the ways DB2 attempts to enforce concurrency is through the use of isolation levels, which determine how data used in one transaction is locked or isolated from other transactions while the first transaction works with it.



Instructor Guide



Figure 6-7. Repeatable read isolation level CE5001.0

Notes:


Repeatable read isolation level

Instructor Guide



V4.1


Purpose —

Details — The repeatable read isolation level is the most restrictive isolation level available.

When it's used, the effects of one transaction are completely isolated from the effects of other concurrent transactions: dirty reads, non-repeatable reads, and phantoms can't occur. With repeatable read, every row that's referenced in any manner by the owning transaction is locked for the duration of that transaction.



Instructor Guide



Figure 6-8. Read stability isolation level CE5001.0

Notes:


Read stability isolation level

Instructor Guide



V4.1


Purpose —

Details — The read stability isolation level isn't quite as restrictive as the repeatable read level; therefore, it doesn't completely isolate one transaction from the effects of other, concurrent transactions. The read stability isolation level prevents dirty reads and non-repeatable reads; however, phantoms can occur. When this isolation level is used, only the rows that are actually retrieved or modified by the owning transaction are locked.



Instructor Guide



Figure 6-9. Cursor stability isolation level CE5001.0

Notes:


Cursor stability isolation level

Instructor Guide



V4.1


Purpose —

Details — The cursor stability isolation level is very relaxed in the way it isolates the effects of one transaction from the effects of other concurrent transactions. It prevents dirty reads; however, non-repeatable reads and phantoms can and may occur. That's because in most cases, the cursor stability isolation level only locks the row that is currently referenced by a cursor that was declared and opened by the owning transaction.

As with the repeatable read and read stability isolation levels, transactions using the cursor stability isolation level (which is the default isolation level used) won't see changes made to other rows by other transactions until those changes have been committed.



Instructor Guide



Figure 6-10. Uncommitted read isolation level CE5001.0

Notes:


Uncommitted read isolation level

Instructor Guide



V4.1


Purpose —

Details — The uncommitted read isolation level is the least restrictive isolation level available. In fact, when this isolation level is used, rows retrieved by a transaction are only locked if another transaction attempts to drop or alter the table the rows were retrieved from. Because rows usually remain unlocked when this isolation level is used, dirty reads, non-repeatable reads, and phantoms can occur.



Instructor Guide



Figure 6-11. Lock attributes CE5001.0

Notes:


Lock attributes

• All locks have the following basic attributes:– Object: The object attribute identifies the data resource that is being

locked.– Size: The size attribute specifies the physical size of the portion of the

data resource that is being locked. – Duration: The duration attribute specifies the length of time for which

a lock is held. – Mode: The mode attribute specifies the type of access allowed for the

lock owner as well as the type of access permitted for concurrent users of the locked data resource. This attribute is commonly referred to as the lock state.

Instructor Guide



V4.1


Purpose —

Details — A lock is a mechanism that is used to associate a data resource with a single transaction, with the purpose of controlling how other transactions interact with that resource while it is associated with the owning transaction. (The transaction that a locked resource is associated with is said to hold or own the lock.)

If one transaction attempts to access a data resource in a way that is incompatible with the lock being held by another transaction (we'll look at lock compatibility shortly), that transaction must wait until the owning transaction has ended.



Instructor Guide



Figure 6-12. Table lock modes CE5001.0

Notes:


Table lock modes

IX Intention eXclusive

X eXclusive

Z superexclusive

IS Intention Share

IN Intent None

Row Locking also used Strict Table Locking

(See next page)

SIX Share with Intention eXclusive

S Share

U Update

Instructor Guide



V4.1


Purpose —

Details —

Intent None (IN)

The lock owner can read data in the locked table, including uncommitted data, but cannot change this data. In this mode, the lock owner does not acquire row-level locks; therefore, other concurrent applications can read and change data in the table.

Intent Share (IS)

The lock owner can read data in the locked table, but cannot change this data. Again, because the lock owner does not acquire row-level locks, other concurrent applications can both read and change data in the table. (When a transaction owns an Intent Share lock on a table, it acquires a Share lock on each row it reads.) This lock is acquired when a transaction does not convey the intent to update rows in the table. (The SELECT FOR UPDATE, UPDATE ... WHERE, and INSERT statements convey the intent to update.)

Intent Exclusive (IX)

The lock owner and any other concurrent applications can read and change data in the locked table. When the lock owner reads data from the table, it acquires a Share lock on each row it reads, and it acquires both an Update and an Exclusive lock on each row it updates. Other concurrent applications can both read and update the locked table. This lock is acquired when a transaction conveys the intent to update rows in the table.

Share with Intent Exclusive (SIX)

The lock owner can both read and change data in the locked table. The lock owner acquires Exclusive locks on the rows it updates but does not acquire locks on rows that it reads; therefore, other concurrent applications can read but cannot update the data in the locked table.

Share (S)

The lock owner and any other concurrent transactions can read, but cannot change, data in the locked table or row. As long as a table is not Share locked, individual rows in that table can be Share locked. If, however, a table is Share locked, row-level Share locks in that table cannot be acquired by the lock owner. If either a table or a row is Share locked, other concurrent transactions can read the data, but they cannot change it.

Update (U)

The lock owner can update data in the locked table and the lock owner automatically acquires Exclusive locks on any rows it updates. Other concurrent applications can read but cannot update the data in the locked table.

Exclusive (X)

The lock owner can both read and change data in the locked table or row. If an Exclusive lock is acquired, only applications using the Uncommitted Read isolation level are allowed

Instructor Guide



to access the locked table or row(s). Exclusive locks are acquired for data resources that are going to be manipulated with the INSERT, UPDATE, and/or DELETE statements.

Super Exclusive (Z)

The lock owner can alter a table, drop a table, create an index, or drop an index. This lock is automatically acquired on a table whenever a transaction attempts to perform any one of these operations. No other concurrent transactions are allowed to read or update the table until this lock is removed.



Instructor Guide



V4.1

Uempty

Figure 6-13. Row lock modes CE5001.0

Notes:


Row lock modes

S

U

X

W

NS

NW

Row Lock

Row locks

S, U, X, or Z

Minimum* SupportingTable Lock

An application does not acquire

if it is using Table Locks of

IS

IX

IX

IX

IS

IX

Share

Update

eXclusive

Weak exclusive

Next key Share

Next key Weak exclusive

Instructor Guide



Instructor notes:

Purpose —

Details —

Weak Exclusive (W)

The lock owner can read and change the locked row. This lock is acquired on a row when it is inserted into a non-catalog table.

Next Key Share (NS)

The lock owner and all concurrent transactions can read, but cannot change, data in the locked row. This lock is acquired in place of a Share lock on data that is read using the Read Stability or Cursor Stability transaction isolation level.

Next Key Weak Exclusive (NW)

The lock owner can read but cannot change the locked row. This lock is acquired on the next row in a table when a row is inserted into the index of a non-catalog table.



Instructor Guide



V4.1

Uempty

Figure 6-14. Lock conversion CE5001.0

Notes:


Lock conversion

• Changing of locks when application accesses data object (row, table, or block) on which it already holds a lock and requires amore restrictive lock– More restrictive lock may or may not be granted

• Example 1:– Application selects row from a table using FOR UPDATE clause

• FOR UPDATE causes U-lock on row– Application then updates row using WHERE CURRENT of cursor

• Causes lock conversion of U-lock to X-lock

• Example 2:– Application performs RS select which identifies a row

• Row is read using index, IS lock on table, S lock on row– Application then performs update against row

• Table lock conversion from IS to IX, row lock from S to X

Instructor Guide



Instructor notes:

Purpose —

Details — A lock conversion occurs when an application accesses a data object (row, table, or block) on which it already holds a lock, and the mode of access requires a more restrictive lock than the one already held. A process can hold only one lock on a data object at any time. The operation of changing the mode of the lock already held is called a lock conversion. During the lock conversion process, the more restrictive lock may or may not be granted.

For example, an application selects a row from a table using the FOR UPDATE clause. The FOR UPDATE clause will cause a U-lock to be placed on the row. The application then updates the row using a WHERE CURRENT of cursor which causes a lock conversion of the U-lock to an X-lock.

Another example is if an application performs a query to update a row. The row is read using an index, an IS lock is placed on the table, and an S lock is placed on the row. Next the row is accessed for update, so the table lock is converted from IS to IX and the row lock from S to X.



Instructor Guide



V4.1

Uempty

Figure 6-15. Lock escalation CE5001.0

Notes:


Lock escalation

locklist

locklist. . . . . . . . . . . .

. . . . . . . . . .

XX

XIX

XXIX

. . . . . . . . .

X

X . . . . . . . . . . . .

maxlocks

maxlocks

exceeded

locklist

full

ESCALATING APPLICATION OTHER APPLICATIONS

. . . . . . . . . .

Instructor Guide



Instructor notes:

Purpose —

Details — A lock escalation occurs when the number of locks held on rows and tables in the database equals the percentage of the lock list specified by the maxlocks database configuration parameter. Lock escalation might not affect the table that acquires the lock triggering the escalation. To reduce the number of locks to about half the number held when the lock escalation began, the database manager begins converting many small row locks to table locks for all active tables, beginning with any locks on large object (LOB) or long VARCHAR elements. An exclusive lock escalation is a lock escalation in which the table lock acquired is an exclusive lock.



Instructor Guide



V4.1

Uempty

Figure 6-16. Lock wait and timeout CE5001.0

Notes:


Lock wait and timeout

LOCKHOG

xx x x

xxxxx

xx x

x x

xW A I T !

I just wantthat one!

locktimeout 30

-1

12

9

6

3

If the application hogging the locksdoesn’t COMMIT or ROLLBACK

other applications wait until lock isavailable or timeout exceeded

Instructor Guide



Instructor notes:

Purpose —

Details — Lock timeout detection is a database manager feature that prevents applications from waiting indefinitely for a lock to be released in an abnormal situation. For example, a transaction might be waiting for a lock held by another user's application, but the other user has left the workstation without allowing the application to commit the transaction that would release the lock. To avoid stalling an application in such a case, set the locktimeout configuration parameter to the maximum time that any application should wait to obtain a lock.

Setting this parameter helps avoid global deadlocks, especially in distributed unit of work (DUOW) applications. If the time that the lock request is pending is greater than the locktimeout value, the requesting application receives an error and its transaction is rolled back. For example, if program1 tries to acquire a lock which is already held by program2, program1 returns SQLCODE -911 (SQLSTATE 40001) with reason code 68 if the timeout period expires. The default value for locktimeout is -1, which turns off lock timeout detection.



Instructor Guide



V4.1

Uempty

Figure 6-17. Deadlock causes and detection CE5001.0

Notes:


Deadlock causes and detection

MILK

UNIT OF WORK —

DELETE SOME CEREAL AND MILK

RAISINBRAN

APPLICATION A

dlchktime 10000 milliseconds

APPLICATION B

Instructor Guide



Instructor notes:

Purpose —

Details — Suppose Transaction A acquires an Exclusive (X) lock on Table RAISIN_BRAN and Transaction B acquires an Exclusive (X) lock on Table MILK. Now, suppose Transaction A attempts to acquire an Exclusive (X) lock on Table MILK and Transaction B attempts to acquire an Exclusive (X) lock on Table RAISIN_BRAN.

Processing by both transactions will be suspended until their second lock request is granted. However, because neither lock request can be granted until one of the transactions releases the lock it currently holds (by performing a commit or rollback operation), and because neither transaction can release the lock it currently holds (because both are suspended and waiting on locks), the transactions are stuck in a deadlock cycle.

The sole responsibility of the deadlock detector is to locate and resolve any deadlocks found in the locking subsystem. Each database has its own deadlock detector, which is activated as part of the database initialization process.

If the deadlock detector discovers that a deadlock cycle exists, it randomly selects one of the transactions (the victim) in the cycle to terminate and roll back. The transaction chosen receives an SQL error code and all locks it had acquired are released; the remaining transaction(s) can then proceed because the deadlock cycle has been broken.



Instructor Guide



V4.1

Uempty


Notes:


Unit summary






Instructor Guide



Instructor notes:

Purpose —





Uempty
Part 7. Introducing XQuery
Estimated time

01:00



• Understanding fundamental XQuery concepts

• Writing simple XQueries using several common expressions



• List fundamental XQuery concepts

• Write simple XQueries using several common expressions


© Copyright IBM Corp. 2008 Part 7. Introducing XQuery 7-1

Instructor Guide


Notes:


Unit objectives







Uempty
Instructor notes:
Purpose —






Instructor Guide


Notes:



• Knowledge of XML data implications (non-shredding)

• Given an XQuery statement, knowledge to identify results




Uempty
Instructor notes:
Purpose —






Instructor Guide

Figure 7-3. Sample XML document CE5001.0

Notes:


Sample XML document




Uempty
Instructor notes:
Purpose —

Details — This is an XML document containing eight element nodes, one attribute node, and six text nodes. The element nodes are represented by element tags. Client, Address, street, city, state, zip, and both email elements are all element nodes in this document. If you look closely at the Client element, you'll see that it contains an attribute node for the client's id. Some of the document's element nodes have text nodes associated with them. For example, the text node for the city element is San Jose.

<Client id="123"> <Address> <street>9999 Elm St.</street> <city>San Jose</city> <state>CA</state> <zip>95141</zip> </Address> <email>[email protected]</email> <email>[email protected]</email> </Client>





Instructor Guide

Figure 7-4. XQuery navigation CE5001.0

Notes:


XQuery navigation

• Navigate to the city element/Client/Address/city

• More path expressions://*

//email

/Client/email[1]/text()

/Client/Address/*

/Client/data(@id)

/Client/Address[state="CA"]/../email




Uempty
Instructor notes:
Purpose —

Details — XPath expressions look very much like the expressions you use when working with a traditional computer file system. Consider how you navigate through Unix or Windows directories, and you'll get an idea of how you can navigate through an XML document using XPath.

A path expression in XQuery consists of a series of "steps" separated by slash characters. In its simplest form, each step navigates downward in an XML hierarchy to find the children of the elements returned by the previous step. Each step in a path expression may also contain a predicate that filters the elements that are returned by that step, retaining only elements that satisfy some condition.





Instructor Guide

Figure 7-5. Sample data for the clients table CE5001.0

Notes:


Sample data for the clients table

INSERT INTO clients VALUES (3227, 'Ella Kimpton', 'Gold','<Client>

<Address><street>5401 Julio Ave.</street><city>San Jose</city><state>CA</state><zip>95116</zip>

</Address><phone>

<work>4084630000</work><home>4081111111</home><cell>4082222222</cell>

</phone><fax>4087776666</fax><email>[email protected]</email>

</Client>');




Uempty
Instructor notes:
Purpose —

Details — The SQL statement above inserts a row into the clients table. Each row contains an XML document, and the structure of each XML document varies somewhat. For example, email addresses are available for some customers but not others.





Instructor Guide

Figure 7-6. Simple XML data retrieval CE5001.0

Notes:


Simple XML data retrieval• Simple XQuery to return customer contact data

XQUERY db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')

• Output from the query:<?xml version="1.0" encoding="windows-1252" ?><Client>

<Address><street>

5401 Julio Ave.</street><city>

San Jose</city><state>

CA</state><zip>

95116</zip>

</Address><phone>

<work>4084630000

</work><home>

4081111111</home><cell>

4082222222</cell>

</phone><fax>

4087776666</fax><email>

[email protected]</email>

</Client>




Uempty
Instructor notes:
Purpose —

Details — When running as a top-level language, XQuery needs to have a source of input data. In DB2, one way that you can specify this source of input data is by calling a function named db2-fn:xmlcolumn. This function takes an input parameter that identifies the DB2 table and XML column name of interest.





Instructor Guide

Figure 7-7. Specifying a single filtering predicate CE5001.0

Notes:


Specifying a single filtering predicate

• FLWOR expression with a new WHERE clauseXQUERY

FOR $y IN

db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')

/Client/Address

WHERE $y/zip="95116"

RETURN $y

• Output from the query:<Address>

<street>5401 Julio Ave.</street>

<city>San Jose</city>

<state>CA</state>

<zip>95116</zip>

</Address>




Uempty
Instructor notes:
Purpose —

Details — You can incorporate a where clause into your XQuery to filter results based on the value of the zip element in the sample XML documents stored in DB2.





Instructor Guide

Figure 7-8. Converting XML to HTML CE5001.0

Notes:


Converting XML to HTML• Querying DB2 XML data and returning results as HTML:XQUERY<ul> {

FOR $y INdb2-fn:xmlcolumn('CLIENTS.CONTACTINFO')/Client/Address

ORDER BY $y/zipRETURN <li>{$y}</li>} </ul>

• HTML output of the query:<ul>

<li><Address>

<street>9407 Los Gatos Blvd.</street><city>Los Gatos</city><state>CA</state><zip>95032</zip>

</Address></li><li>

<Address><street>4209 El Camino Real</street><city>Mountain View</city><state>CA</state><zip>95033</zip>

</Address></li>

. . .</ul>




Uempty
Instructor notes:
Purpose —

Details — In Web-based applications, it is common to convert all or part of XML documents into HTML for easy display. With XQuery, this process is straightforward.





Instructor Guide

Figure 7-9. Conditional logic CE5001.0

Notes:


Conditional logic• XQuery with a three-part conditional expression

FOR $y IN db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')/ClientRETURN (

IF ($y/email) THEN $y/email[1]ELSE IF ($y/phone/home) THEN

<homePhone>{$y/phone/home/text()}</homePhone>ELSE $y/Address)

• Query output:<email>

[email protected]</email><Address>

<street>1204 Meridian Ave.

</street><apt>

4A</apt><city>


CA</state><zip>

95124</zip>

</Address><homePhone>

4083332222</homePhone>

. . .




Uempty
Instructor notes:
Purpose —

Details — Imagine that you'd like to contact each of your clients. You'd prefer to contact them by email, but if you don't have an email address, then you want to phone them at home. If you don't have a home phone number either, you want to send them a letter by postal mail.





Instructor Guide

Figure 7-10. Hybrid queries CE5001.0

Notes:


Hybrid queries• Embedding SQL within an XQueryXQUERY

FOR $y INdb2-fn:sqlquery

('SELECT contactinfo FROM clients WHERE status=''Gold'' ')/Client

WHERE $y/Address/city="San Jose"RETURN (IF ($y/email) THEN <emailList>{$y/email}</emailList>ELSE $y/Address

)

• Query output<emailList>

<email>[email protected]

</email><Address>

<street>1204 Meridian Ave.

</street><apt> 4A</apt><city>


CA</state><zip>

95124</zip>

</Address>




Uempty
Instructor notes:
Purpose —

Details — To embed SQL in an XQuery, you use the db2-fn:sqlquery function in place of the db2-fn:xmlcolumn function. The db2-fn:sqlquery function executes an SQL query and returns only the selected data. The SQL query passed to db2-fn:sqlquery must only return XML data; this enables XQuery to further process the result of the SQL query.





Instructor Guide


Notes:


Unit summary







Uempty
Instructor notes:
Purpose —






Instructor Guide



Instructor Guide

Figure 8-1. Review of units covered CE5001.0

Notes:


Review of units covered

• Units covered:– DB2 9 Fundamentals exam 730 prep, Part 1: DB2 planning– DB2 9 Fundamentals exam 730 prep, Part 2: Security– DB2 9 Fundamentals exam 730 prep, Part 3: Accessing DB2 data– DB2 9 Fundamentals exam 730 prep, Part 4: Working with DB2 data– DB2 9 Fundamentals exam 730 prep, Part 5: Working with DB2

objects– DB2 9 Fundamentals exam 730 prep, Part 6: Data concurrency– DB2 9 Fundamentals exam 730 prep, Part 7: Introducing XQuery




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-2. Part 1: DB2 planning CE5001.0

Notes:


Part 1: DB2 planning

• DB2 Editions• DB2 components• Roadmap to the GUI tools• CLP Command Line Processor and CLP syntax• Online reference• Using the CLP• Control Center• Command Editor• Journal• Replication Center• Configuration Assistant• Visual Explain• Developer Workbench• Memory Visualizer• Storage Management• IBM Data Warehouse Edition




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-3. Part 2: Security CE5001.0

Notes:


Part 2: Security

• Basic client-server-host configuration

• DB2 authentication

• Authentication within the DBM configuration

• DB2 authentication types

• DB2 Authorities

• DB2 Privileges

• LBAC (Label Based Access Control) query

• Example implementation of LBAC




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-4. Part 3: Accessing DB2 data CE5001.0

Notes:


Part 3: Accessing DB2 data

• What makes up a DB2 database?• DB2 object hierarchy• Default table space containers with Automatic Storage• Creating your first database• Control Center• Database Configuration• CREATE TABLESPACE syntax • CREATE DATABASE syntax• CREATE DATABASE examples• Cataloging your DB2 database• Configuration Assistant • Manipulating DB2 objects with the Control Center• Create Database Wizard• Creating and accessing basic DB2 objects




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-5. Part 4: Working with DB2 data CE5001.0

Notes:


Part 4: Working with DB2 data

• The parts of speech of SQL• Types of SQL statements• Data Manipulation Language (DML) – SELECT• Data Manipulation Language (DML) – WHERE• Data Manipulation Language (DML) – ORDER BY• Data Manipulation Language (DML) – Joins• Data Manipulation Language (DML) – Set operators• Data Manipulation Language (DML) – GROUP BY• Data Manipulation Language (DML) – INSERT• Data Manipulation Language (DML) – UPDATE• Data Manipulation Language (DML) – DELETE• Data Manipulation Language (DML) – MERGE• Data Manipulation Language (DML) – Reference• Units of work and savepoints• Creating and calling an SQL procedure• Creating and using SQL user-defined functions• User-defined table function




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-6. Part 5: Working with DB2 objects CE5001.0

Notes:


Part 5: Working with DB2 objects

• Data types• Numeric data types• String data types• Datetime data types• XML data type• User-defined data types• DB2 Extenders• Tables – CREATE, ALTER, DROP, NOT NULL, DEFAULT,

and GENERATED• Constraints – Unique constraints, Referential integrity

constraints, Table check constraints• Views• Creating indexes• Clustering indexes• Using included columns in indexes




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-7. Part 6: Data concurrency CE5001.0

Notes:


Part 6: Data concurrency

• Simple workload consisting of three transactions• Comparing successful and unsuccessful transactions• Concurrency and isolation levels• Repeatable read, Read stability, Cursor stability, Uncommitted

read isolation levels• Lock attributes• Table lock modes• Row lock modes• Lock mode compatibility• Lock conversion• Lock escalation• Lock wait and timeout• Deadlock causes and detection




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide

Figure 8-8. Part 7: Introducing XQuery CE5001.0

Notes:


Part 7: Introducing XQuery

• Sample XML document

• XQuery navigation

• Sample data for the clients table

• Simple XML data retrieval

• Specifying a single filtering predicate

• Converting XML to HTML

• Conditional logic

• Hybrid queries




Uempty
Instructor notes:
Purpose —

Details —





Instructor Guide



V5.1

backpg
Back page

IBM Class Author main book file - Department of...

Documents

Transcript of IBM Class Author main book file - Department of...