PoT IM 06 1 027 14-Workbook

IBM Software Information Management
An IBM Proof of Technology
IBM DB2 10.1 Administration for the Experienced Oracle DBA

Lab Exercises
An IBM Proof of Technology

PoT.IM.06.1.027.014
Version 7.0 December 7, 2012 Burt Vialpando & Vikram Khatri
Copyright IBM Corporation, 2006, 2012 US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
LAB 01. INSTANCE EXPLORATION ............................................................................................................................... 8 A. DB2 OPERATING SYSTEM DIRECTORIES AND FILES .............................................................................................. 8 B. START AND STOP A DB2 INSTANCE................................................................................................................... 12 C. CLP INTRODUCTION........................................................................................................................................ 13 D. CREATE A NEW DB2 INSTANCE ........................................................................................................................ 15 E. CATALOG A DB2 INSTANCE .............................................................................................................................. 19 F. EXTRA EXERCISES .......................................................................................................................................... 21 DATABASE CREATION AND EXPLORATION ............................................................................................... 22 A. GENERAL DB2 DATABASE COMMANDS ............................................................................................................. 22 B. THE DB2 SYSTEM AND LOCAL DATABASE DIRECTORIES ..................................................................................... 24 C. CREATING A DATABASE ................................................................................................................................... 26 D. EXPLORING VARIOUS DB2 DATABASE FUNCTIONALITY FEATURES ......................................................................... 29 E. ALTERING A TABLE .......................................................................................................................................... 30 DATA STUDIO.................................................................................................................................................. 31 A. LAUNCHING DATA STUDIO ................................................................................................................................ 31 B. CONNECTING TO AND MANAGING A DATABASE .................................................................................................... 32 CLPPLUS AND ORACLE COMPATIBILITY .................................................................................................... 54 A. LOGGING ON TO CLPPLUS............................................................................................................................... 54 B. INTERACTIVE CLPPLUS COMMANDS .................................................................................................................. 56 C. RUNNING A SCRIPT FILE IN CLPPLUS BATCH MODE ............................................................................................. 63 D. ORACLE COMPATIBILITY EXAMPLES................................................................................................................... 66 SECURITY ........................................................................................................................................................ 76 A. INSTANCE LEVEL SECURITY.............................................................................................................................. 76 B. DATABASE LEVEL SECURITY ............................................................................................................................ 79 B. DATABASE LEVEL SECURITY ............................................................................................................................ 79 C. OBJECT LEVEL SECURITY ................................................................................................................................ 83 D. USING THE SYSTEM CATALOG SECURITY VIEWS ................................................................................................ 85 E. USER AND GROUP OVERVIEW .......................................................................................................................... 88 G. VIEWING DATABASE AUTHORITIES ...................................................................................................................... 90 H. COLUMN AND ROW LEVEL SECURITY .................................................................................................................. 91 I. EXTRA EXERCISE: DB2AUDIT AND AUDIT POLICY ............................................................................................ 93 J. EXTRA EXERCISE: A QUICK LOOK INTO LABEL BASED ACCESS CONTROL ............................................................... 95 K. CLEANUP ....................................................................................................................................................... 95 AUTONOMIC COMPUTING ............................................................................................................................. 96 A. SELF TUNING MEMORY MANAGER (STMM)....................................................................................................... 96 B. AUTOMATIC STORAGE ................................................................................................................................... 100 C. AUTOCONFIGURE .......................................................................................................................................... 101 D. EXTRA EXERCISE: AUTOMATIC MAINTENANCE ................................................................................................. 102 E. EXTRA EXERCISE: STATISTIC PROFILING ......................................................................................................... 108 F. EXTRA EXCERCISE: SYSTOOLS SETUP ......................................................................................................... 109 G. CLEANUP ..................................................................................................................................................... 109 DEEP COMPRESSION .................................................................................................................................. 110 A. TABLE DEEP COMPRESSION ........................................................................................................................... 110 B. CLEAN UP..................................................................................................................................................... 116 EXPLAIN FACILITIES AND THE OPTIMIZER ............................................................................................... 117 A. CREATE EXPLAIN TABLES .............................................................................................................................. 117 B. UNION ALL VIEW EXAMPLE SETUP .................................................................................................................. 119 C. VISUAL EXPLAIN IN DATA STUDIO - AN OVERVIEW ............................................................................................. 122 D. VISUAL EXPLAIN TUNING A QUERY ............................................................................................................... 126 E. USING DB2EXFMT EXPLAIN MULTIPLE QUERIES AT ONCE.................................................................................. 132 F. EXTRA EXERCISE USING DB2EXPLN ............................................................................................................. 133 G. EXTRA EXERCISES: REBIND AND ROW MOVEMENT ................................................................................... 135 WORKLOAD MANAGEMENT (WLM) ............................................................................................................ 136 A. SETTING UP A CUSTOM WORKLOAD MANAGER ENVIRONMENT ............................................................................. 136 B. SETTING UP TO SIMULATE A WORKLOAD ........................................................................................................... 141 C. RUNNING A WORKLOAD AS USER DB2USER1 .................................................................................................... 143 D. RUNNING A SECOND WORKLOAD AS DB2COBRA ................................................................................................ 146 E. RUNNING A THIRD WORKLOAD AS USER DB2SEC ............................................................................................... 148 F. WORKING WITH WLM EVENT MONITORS .......................................................................................................... 150 G. EXTRA EXERCISE: MISCELLANEOUS WLM LESSONS ........................................................................................ 152
LAB 02.
LAB 03. LAB 04.
LAB 05.
LAB 06.
LAB 07. LAB 08.
LAB 09.
H. CLEAN UP .................................................................................................................................................... 152 MONITORING ................................................................................................................................................. 153 A. SNAPSHOT MONITORING ................................................................................................................................ 153 B. EVENT MONITORING ...................................................................................................................................... 154 C. DATA STUDIO STORED PROCEDURE PROFILING ............................................................................................... 157 D. LIGHT WEIGHT MONITORING SQL FUNCTIONS AND DB2PD ............................................................................. 159 E. CLEANUP ..................................................................................................................................................... 159 LAB 11. IBM DB2 PUREXML ....................................................................................................................................... 160 A. CREATE A SUPPORTING DATABASE AND AN XML READY TABLE ........................................................................ 160 B. INSERTING AND EXPLORING XML DATA ........................................................................................................... 161 C. IMPORTING AND EXPORTING XML DATA .......................................................................................................... 164 D. CREATING INDEXES ON XML DATA ................................................................................................................. 166 E. EXTRA EXERCISE: REGISTERING AN XSR ........................................................................................................ 167 F. EXTRA EXERCISE: VALIDATING WITH THE XSR ................................................................................................. 168 G. CLEANUP ..................................................................................................................................................... 168 LAB 12. MULTIDIMENSIONAL CLUSTERS (MDCS) .................................................................................................. 169 A. CARS TABLES EXAMPLE SETUP .................................................................................................................... 169 B. EXPLORE MDC SPACE USAGE ....................................................................................................................... 170 C. EXPLORE MDC TABLE ORGANIZATION ............................................................................................................ 172 D. USING THE DB2BATCH BENCHMARKING UTILITY ................................................................................................ 174 E. EXTRA EXERCISE - MDC PERFORMANCE TIMING TEST ..................................................................................... 175 F. CLEANUP...................................................................................................................................................... 179 LAB 13. DATA MOVEMENT UTILITIES....................................................................................................................... 180 A. DB2RELOCATEDB .......................................................................................................................................... 180 B. USING DB2MOVE AND DB2LOOK ...................................................................................................................... 183 C. SYSPROC.ADMIN_MOVE_TABLE ........................................................................................................... 186 D. DATA INGEST................................................................................................................................................ 187 E. CLEANUP ..................................................................................................................................................... 188 LAB 14. BACKUP, RESTORE & RECOVERY ............................................................................................................. 189 A. OFFLINE BACKUP .......................................................................................................................................... 189 B. OFFLINE RESTORE ........................................................................................................................................ 190 C. OFFLINE REDIRECTED RESTORE USING DATA STUDIO ...................................................................................... 192 D. CONFIGURE DATABASE LOGGING ................................................................................................................... 195 E. ONLINE DATABASE BACKUP ........................................................................................................................... 196 F. DATABASE RECOVER AND RESTORE / ROLL FORWARD TECHNIQUES .................................................................. 197 G. RECOVER A DROPPED TABLE......................................................................................................................... 198 H. RESTORE A HISTORY FILE ............................................................................................................................. 198 I. MOVING TABLE SPACE LOCATIONS WITH A SCRIPT (REDIRECTED RESTORE) ........................................................ 199 J. ONLINE TABLE SPACE BACKUP / RESTORE / RECOVERY .................................................................................... 201 K. INCREMENTAL BACKUP / RESTORE / RECOVERY ............................................................................................... 201 L. DELTA BACKUP / RESTORE / RECOVERY .......................................................................................................... 202 M. CLEANUP ..................................................................................................................................................... 202 LAB 15. ADDITIONAL MISC. TOPICS ......................................................................................................................... 203 A. TEMPORAL DATA MANAGEMENT & TIME TRAVEL QUERY ................................................................................... 203 B. FEDERATION SIMPLE DB2 TO DB2 EXAMPLE ................................................................................................. 207 C. CLEANUP ..................................................................................................................................................... 209 OPTIONAL TOPICS VOTING SHEET ........................................................................................................................................ 213 LAB 10.
[This page left intentionally blank]
IBM Software
DB2 10.1 Administration for the Experienced Oracle DBA
Lab Instructions
Setting up this Proof of Technology (PoT) if you are not using an IBM VMware approach
If you are not doing this lab in an IBM hosted Proof of Technology session on IBM prepared VM imaged computers, you can prepare for this PoT yourself by doing the following:

Create userid dbapot with password password. Log on as this user to complete these steps and run the PoT session with. Install IBM DB2 10.1 FP2 Enterprise Server Edition on a SLES 11 2 machine (Note: install DB2 as root and not as dbapot.) Use all the defaults while installing DB2 (create the DAS and fenced users in any way you like, these are not used in the PoT) Create a default instance db2inst1 password password when doing the DB2 install
Now create instance dbapot (see script examples Setup48.sh if you don't know how to do this.) Copy the PoT scripts to your computer in the directory /home/dbapot. (If you did not get these scripts, ask for them from your IBM representative). These scripts will all be under directory /home/dbapot/pot_db2. Run the setup script in /00setup/Setup01.sh (this creates the databases you will need for the PoT) Run the setup script in /00setup/Setup02.sh (this creates all the users you will need for the PoT.) Install the free Data Studio product, using the defaults. http://www.ibm.com/developerworks/downloads/im/data/
Helpful icons you can create for your desktop:

You might want to create the following desktop icons to make your PoT experience easier: Data Studio 3.1.1 Full client DB2 instance dbapot console dbapot's Home File Browser
Properties Command: /opt/IBM/DS3.1.1/eclipse -product com.ibm.datastudio.consolidated.product.ide
Properties Command: gnome-terminal --workingdirectory=/home/db2inst1 -window-with-profile=db2inst1
Properties Command: Default when you log in as dbapot
Page 6
Lab Instructions
IBM Software
The script directories and files:

/home/dbapot/pot_db2/ 00setup 01instance 02database 03datastudio 04clpplus 05security 06autonom 07compress 08explain 09wlm 10monitor 11purexml 12mdc 13data 14backup 15misc 99instructor Script to set up the labs Instance creation and exploration and the CLP Database creation and exploration Data Studio CLPPlus and Oracle compatibility Security concepts and usage Autonomic computing DB2 Deep compression Explain facilities and the Optimizer DB2 Workload Manager Core monitoring capbilities IBMs XML concepts Multidimensional Clusters Data Movement utilities Backup and restore and logging Temporal data mgmt, Multi-temp Storage, Federation, DB2 Cloud Other supporting documents for this PoT
Script file names use this convention: TTTTNN.EXT TTTTT = Topic lesson (like Instance) NN = Number of script within that lab section EXT = File extension that best describes the contents: SH, DB2, SQL, DML, DCL, etc. CMD files are the scripts that you will run that use the others scripts in the lab directories.
*** End of Lab Instructions ***
Lab Instructions
Page 7
IBM Software
Lab 01. Instance Exploration

A. DB2 Operating System Directories and Files
Let us explore how installed DB2 looks on your SUSE Linux operating system: ___1. This icon opens the File Browser and is set to the home directory for user dbapot. Double click on it to explore the files for this instance:
___2.
This icon opens a Linux Console, positioned at the instance dbapot home directory, but under the subdirectory pot_db2 where all the lab scripts are located. Double click on it:
___3.
Try to keep only one Console open at the start of each lab topic, so even if you open more than one during the lab itself, close them all except for one.
Page 8
Lab 01 Instance Exploration
IBM Software
___4.
In the Console find out key environment variables for your DB2 instance by running this command: env | grep DB2
___5.
Use the File Browser to look through the DB2 home directory for this instance, especially the bin and lib subdirectories, to get familiar with them. This is where most of the instance dbapot will get its DB2 functionality from. When an instance is created, its DB2 home directory gets its source from the main install library that were created during the DB2 install itself. Use the File Browser to click on the "Places" called "File System". Then navigate to the main DB2 install directory /opt/ibm/db2/V10.1. Explore through these files to get familiar with them.
___6.
___7.
To review your DB2 registry variables, do this command: db2set all
Page 9
IBM Software
These are the kinds of DB2 registry variables, which are parsed by DB2 in this order: Environment variables Node level registry Instance level registry Global level registry - denoted by [e] - denoted by [n] - denoted by [i] - denoted by [g]
Instance and database metadata ___8. To review key metadata about your instance, review these files in the File Browser:
___9.
To review key metadata about the databases in your instance, review these files in the File Browser:
SQL00001 is the directory for the metadata for the SAMPLE database. This is different than the SAMPLE directory which is where the automatic storage containers are kept for the SAMPLE database.
Page 10
IBM Software
___10. Find the table space directories for the SAMPLE database:
___11. Find the local database directory called sqldbdir. This is on the same level as SQL00001 and SQL00002. We will be learning later what this does.
Page 11
IBM Software
B. Start and Stop a DB2 Instance

___12. To make sure you know which instance you are currently set to, return to the Console and type: db2 get instance ___13. To start this instance, type: db2start
Don't do this now, but to stop the instance, you can use: db2stop force Or, the alternate DB2 command: db2 stop dbm force We will do this later in the lab... ___14. To verify that DB2 is running, you can execute this command: (note - you might want to make your Console window larger to see everything properly) db2pd -edus
Page 12
IBM Software
C. CLP Introduction
___15. From the Console, type the following commands to learn more about your instance: db2 get dbm cfg Notice the use of dbm (data base manager = instance) These are the instance configuration parameters (scroll up to see them all.)
___16. To see what is in the instance memory, hit your up arrow key, then finish typing this: db2 get dbm cfg show detail You will get an error stating you are not attached to the instance, so you cannot get detailed information from it. The detail will show temporary changes to the cfg settings (if any) so you need to be attached to the instance to find this information The cfg it is referencing is simply information in a binary file and saved changes are persistent.
___17. To attach to a DB2 instance, type: db2 attach to dbapot ___18. Try the previous command again (hint: hit your up arrow key): db2 get dbm cfg show detail ___19. To see the DB2 Administration Server (DAS) settings, type: db2 get admin cfg DAS is a special process that helps administrate communication between instances and databases, locally and remotely which has its own configuration settings For UNIX systems, a special DAS user needs to be created, normally called dasusr1
___20. Try the DB2 CLP in the interactive mode, type: db2
Page 13
IBM Software
___21. To verify your instance location, type: get instance Notice this time we did not need to preface the command with db2
___22. To run a Linux command, preface it with a !, for example: !ls -al ___23. Type the following to see that no databases are yet active: list active databases ___24. To understand connections and applications type: connect to gsdb ___25. Now, type: list active databases This database was activated by default because we connected to it
___26. Type: list applications Notice that GSDB has a db2bp application name (this is the CLP background process itself)
___27. Type: list applications show detail This demonstrates there are other applications to the database started on our behalf when the database was activated
___28. Type: terminate This command does the following: resets the connection to GSDB, refreshes the directory cache, stops the background process and leaves the CLP interactive session
___29. We are no longer in the interactive mode, but we can still run DB2 commands. Try listing the active databases. Notice that the GSDB database is no longer active because the terminate command ended the connection to it, so it deactivated by default.
You can use command activate database [database name] in order to activate it proactively. In that way, connecting to the database or disconnecting from the database does not affect its activation.
Page 14
IBM Software
D. Create a New DB2 Instance

DB2 instance creation on Windows: 1. 2. 3. 4. Requires administration authority to run Creates a Windows Service (with DB2 [instance_name node_name] convention) Creates an Instance directory (e.g. Documents and settings/DB2copy1/inst_name) Creates a Registry Key (regedit, HKEY_LOCAL)
DB2 Instance creation on UNIX: 1. Sets environment variables DB2INSTANCE and PATH Creates /sqllib subdirectory in $HOME of the instance owner (e.g. /home/[instancename] /sqllib) Configures communication based on servers available protocol
2. Creates files db2profile for main environment variable settings (bourne, bash, ksh) userprofile for upgrade and additional environment variable settings
3. Requires user id to: Run with root authority this is because it needs to access the db2icrt command in the DB2 install directory /opt/IBM/db2/[version]/instance/db2icrt on most UNIX platforms /opt/ibm/db2/[version]/instance/db2icrt on Linux Specifies an instance name that is tied to a particular user id which has its own home file system and home directory; this user id should also have the SYSADM authority
Create a DB2 instance and then verify it ___30. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/01instance You can use cd commands or simply type an alias provided for you that will make this simple: lab01
Page 15
IBM Software
___31. Use the File Browser to review a script in this directory called db2icrt. Notice that the heart of this script executes the DB2 utility also called: db2icrt. This script will also create a user for this new instance (before the instance creation) and then start the instance using another utility called db2gcf after the instance creation.
___32. Instance creation is done by root, so we will execute this using sudo like this: sudo ./db2icrt db2inst2
The instance is created and started. For details on the db2icrt command see file: Instance_DB2ICRT_Command.txt
Page 16
IBM Software
___33. After the script completes, switch users to the new instance owner called db2inst2 using su: (password is password)
___34. Now do some DB2 commands to explore this instance: db2 get instance db2 stop dbm db2 start dbm db2 get dbm cfg
___35. Type the following to return to the user dbapot and to make sure you are there: exit whoami
Explore the instance environment ___36. List instances on this server: db2ilist
Page 17
IBM Software
___37. While you can always switch to an instance by simply switching users to the instance owner, review file db2iswitch to see how this can be done with any user:
___38. The key to switching instances in DB2 is to source that instance db2profile and then to issue a db2 terminate command. The script provided above does that for us. Let's run this script to switch instances. We'll stay as user dbapot and run it this way: source db2iswitch db2inst1 ___39. Once you are switched, prove that you remained as user dbapot but are positioned to instance db2inst1: whoami db2 get instance db2 get dbm cfg | grep SVCE
___40. Switch back to your instance dbapot: source db2iswitch dbapot ___41. To drop an instance, explore script db2idrop. Notice the heart of this script is to run the db2idrop command. However, this script makes sure to stop the instance first and then it deletes the instance owner userid as well.
___42. Run this script this way to drop instance db2inst2 (NOTE: TAKE CARE TO NOT DROP INSTANCE db2inst1!) sudo ./db2idrop db2inst2 db2ilist
Page 18
IBM Software
E. Catalog a DB2 Instance

To catalog a instance means to create a local alias for an instance that resides on the same machine. A local node should be cataloged when there is more than one instance on the same workstation to be accessed from the user's client. Inter-process Communications (IPC) is used to access the local node. ___43. With the File Browser, review: Instance01.sh
___44. Execute it: ./Instance01.sh ___45. Notice the script will also run a list node directory command after the catalog is done in order to see instance dbapot catalog entry for instance db2inst1
___46. This now means that instance dbapot now knows about, or has cataloged, the db2inst1 instance. This means they can now communicate with each other and that any GUI tools launched using instance dbapot's catalog can "see" instance db2inst1.
You can use the utilities db2cfexp and db2cfimp to export and import all of your clients configuration settings including your catalog entries. This allows you to easily share all of the catalog information without doing individual catalog commands. These commands also allow you to exchange protocol, registry, dbm cfg and other settings. Usage of this tool is demonstrated in the extra exercises of this lab.
Page 19
IBM Software
Other important communication services ___47. Let's set up the communication for instance db2inst1 to make sure it is available for use by any TCP/IP client. First, switch to the user to perform these things (password is password) su db2inst1 ___48. Next, make sure the DB2 Communication Protocol (DB2COMM) is set: db2 get instance db2start db2set -all
OPTIONAL: If DB2COMM is not set as shown, you can do so with: db2set db2comm=tcpip ___49. Next, make sure the instance Service Name (the TCPIP listening port) is set correctly: tail -15 /etc/services
db2 get dbm cfg | grep SVCENAME
OPTIONAL: If this is not set as shown above, you can do so with these commands: db2 update dbm cfg using svcename 60000 db2stop db2start db2 get dbm cfg | grep SVCENAME ___50. Type exit to leave the su session for db2inst1 and return to user dbapot
Page 20
IBM Software
F. Extra Exercises
___51. db2support utility Review and execute script: Instance02.sh Note: Right click on file Instance02.sh.out.zip, then choose "Open with File Roller" Then find file db2support.html and open it with Firefox.
___52. dbmcfg, dbcfg and reg_variables Administration views usage example Review and execute script: Instance03.sh which executes Instance04.sql ___53. db2diag (diagnostic log tool) usage example Review and execute script: Instance05.sh ___54. inspect and db2inspf usage example Review and execute script: Instance06.sh ___55. db2pd (Problem Determination) usage example Review and execute script: Instance07.sh ___56. db2gcf (Generic Control Facility) usage example Review and execute script: Instance08.sh Note: this must be run as root, this way: sudo ./Instance08.sh db2inst1
___57. db2cfexp (Connectivity Configuration Export Tool) usage example Review and execute script: Instance09.sh ___58. Close all by one Console. Close all editor sessions.
*** End of Instance Exploration Lab - by Burt Vialpando ***
Page 21
IBM Software
Lab 02. Database Creation and Exploration

A. General DB2 Database Commands
Lets explore the database called SAMPLE in the instance called dbapot. ___1. Open a Console if you dont already have one open.
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/02database You can use cd commands or simply type an alias provided for you that will make this simple: lab02
___3.
To make sure the instance is in an Oracle compatibility mode, do the following: db2set db2_compatibility_vector=ORA db2set all db2stop force db2start (sets the compatibility) (make sure the setting was done correctly) (stops the instance) (starts the instance)
___4.
To enter the DB2 CLP in interactive mode, type: db2
Page 22
Lab 02 Database Creation and Exploration
IBM Software
___5.
To see the database configuration parameters, type: get db cfg for sample
___6.
Connect to the SAMPLE database: connect to sample This PoT often uses a "pass through" connection whereby the userid of the OS is used to connect to the database without having to re-authenticate with a password. If you want to use the complete syntax for the CONNECT command, it would be: connect to sample user dbapot using password
___7.
To explore further, type these: get db cfg get connection state list tables for schema dbapot The default schema for a userid is usually the userid itself. Well explore in more detail later in the Security lab the differences between a user and a schema in DB2. describe table department describe indexes for table department select * from employee describe output select * from employee values user select user from dual values current date select sysdate from dual runstats on table dbapot.employee reorgchk update statistics on schema dbapot quit The above commands that used DUAL will only work when the registry variable is set to make our instance Oracle compatible. Well learn more about Oracle compatibility in a later lab.
Page 23
IBM Software
B. The DB2 System and Local Database Directories

___8. In order to learn about DB2 database directories, from the Console type: db2 list database directory This is a system database directory, which means a directory of all databases both remote and local that are cataloged for the current instance with the CATALOG command.
db2 list database directory on /home/dbapot This gives you a local database directory, which means all databases created on the drive path. This is only updated during a CREATE DATABASE or DROP DATABASE command.
___9.
To understand these better, first connect to the GSDB database to prove that you can access it: db2 connect to gsdb
___10. Connect back to the SAMPLE database using the same background process: db2 connect to sample ___11. Uncatalog the GSDB database in the current instance: db2 uncatalog database gsdb ___12. Refresh the directory cache (and terminate the background process as well): db2 terminate ___13. List the system database directory again. Notice GSDB is not there: db2 list database directory
___14. List the local database directory (and notice GSDB is still there): db2 list database directory on /home/dbapot ___15. Try to connect to the GSDB directory (and notice you cannot): db2 connect to gsdb
Page 24
IBM Software
___16. Recatalog database GSDB to make it available again: db2 catalog db gsdb db2 terminate ___17. Try to connect to the GSDB directory (notice now you can!): db2 connect to gsdb
It is very important that you catalog the GSDB database so that you can connect to it again! You will be using this database again in the PoT, so make sure this works. So, the catalog and terminate commands shown above MUST be done correctly and you must be able to connect to GSDB.
Page 25
IBM Software
C. Creating a Database
Creating a database managed by the instance DB2 ___18. To create a database in the instance DB2, try these commands: db2 get instance db2 terminate db2 create database sample2 This will take a few minutes to completewhile this command is executing, see the explanation in the box below for what the CREATE DATABASE command is doing. Also, review the file Database_CREATE_DATABASE_Command.txt (the instance the database will be created in)
The DB2 CREATE DATABASE command does the following: 1. 2. 3. 4. 5. 6. 7. Creates a subdirectory to hold the database metadata information Creates SYCATSPACE, TEMPSPACE1 and USERSPACE1 table spaces Creates system catalog tables in the SYSCATSPACE table space Creates SQLJ, SYSCAT, SYSFUN, SYSIBM, SYSIBMADM, SYSIBMINTERNAL, SYSIBMTS, SYSPROC, SYSPUBLIC and SYSSTAT schemas Grants SECADM, DBADM, DATAACCESS and ACCESSCTRL authorities to the database creator Grants selected database privileges to PUBLIC (unless specified as restricted) Defaults many things for you, but you can control these if you wish: Partition number Install path Database alias name Collating characteristics Codeset and territory Table space characteristics (types, sizes, containers, etc.) Database configuration parameters (using feature called autoconfigure which well go through later) Set up Automatic Storage and Automatic Resize defaults Many other things (see: Database CREATE_DATABASE_Command.txt)
___19. When the CREATE DATABASE command finishes, run these commands: db2 list db directory db2 connect to sample2 db2 list tablespaces db2 terminate
Page 26
IBM Software
Creating a database managed by the instance db2inst1 ___20. Now lets create a database called BACKDB in a different instance: db2inst1 ___21. Switch users to db2inst1 and run script Database01.db2: su db2inst1 db2 -vf Database01.db2
Remember, it takes a few minutes to finish a CREATE DATABASE command... while this is running, review the script Database01.db2 and then see the box below for differences between Oracle and DB2 regarding a create database command.
___22. When the CREATE DATABASE command completes, check out your results: db2 list db directory db2 connect to backdb db2 terminate exit In DB2, the following Oracle concepts are handled differently: 1. Oracle PFILE DB2 - DB config parameters are in file sqldbcon, but this is a binary file Change this with: update db cfg DB2 - uses a similar method to the new SPFILE concept introduced in Oracle 9i Oracle requires a PFILE to create a database DB2 - autoconfigure feature calculates and displays initial values for the buffer pool size, database configuration and database manager configuration parameters, with the option of applying these recommended values DB2 - if you create a database from a backup, you can get the exact db configuration parameter settings from the backup since backups keep db config information 2. Oracle Control File DB2 - file db2rhist.asc history file contains history information about backups, restores, loading of tables, reorganization of tables, altering of a table space, and other changes to a database (has a backup copy) DB2 - file sqlspcs.1 provides table space information (has a backup copy) DB2 - file sqlbp.1 provide buffer pool information (has a backup copy) DB2 - db2tschng.his file contains a history of table space changes at a log-file level. For each log file, db2tschg.his contains information that helps to identify which table spaces are affected by the log file. Table space recovery uses information from this file to determine which log files to process during table space recovery. The above are all automatically created and backup up for you during create database.
Page 27
IBM Software
___23. When back to user dbapot, type: db2 list db directory ___24. Notice database BACKDB is not in the directory for our instance dbapot. This is because we have not yet cataloged it to instance dbapot. (It is however cataloged to the instance db2inst1 which manages and owns it.) ___25. Lets catalog database BACKDB to instance dbapot: db2 "catalog db backdb at node db2inst1 with 'my 1st node db catalog'" db2 terminate
___26. Review if it is in the system catalog of our instance DB2: db2 list db directory
___27. Try connecting to it now db2 connect to backdb
db2 terminate
Page 28
IBM Software
D. Exploring various DB2 database functionality features

Run the following exercises in a Console: ___28. To learn about administrative views and functions: Review and run script: Database03.sh Review file: Database03.sh.out
___29. To learn about db2mtrk Memory Tracking: Review and run script: Database04.sh Review files: Database04.sh.out & Database_DB2MTRK_Commant.txt
___30. To learn about Event Monitoring: Review and run script: Database05.CMD Review files: Database05.sh.out & Database_DB2EVMON_Commant.txt
Page 29
IBM Software
E. Altering a Table
DB2 allows you to alter a table in many different ways. Here is an example of how DB2 can alter a table: ___31. Review scripts Database15.sh which executes Database15a.ddl. Notice what this last script is doing: 1) renaming a column, 2) changing a column data type from SMALLINT to CHAR, 3) dropping a column:
Run script Database15.sh which executes Database15a.ddl Review file: Database15.sh.out
DB2 ALTER TABLE actually has much more power than this. For example, you can alter a column from CHAR to BIGINT for example, provided your data can be cast that way. So, if your CHAR column had 1,2,3 data in it, DB2 would scan your column to make sure your CHAR data can be cast into and BIGINT column, and if it can do that, it will! DB2 can alter a table to change any column data type to any other, provided the data can be cast that way. For an extra exercise, try these commands: db2 connect to gsdb db2 describe table alter_table_tb db2 alter table alter_table_tb alter column dept set data type bigint db2 describe table alter_table_tb db2 terminate
*** End of Database Creation and Exploration Lab by Burt Vialpando ***
Page 30
Lab 03 Data Studio
IBM Software
Lab 03. Data Studio

A. Launching Data Studio
___1. Open the Data Studio 3.1.1 Full client by double clicking on this icon:
ORYou can open Data Studio by clicking the Computer icon and choosing it from there. ___2. At the Workspace Launcher window, make sure your workspace is pointed to the following folder: /home/dbapot/pot_db2/03datastudio/workspace
___3. ___4.
Check the box: Use this as the default and do not ask again After the perspective opens, close the Task Launcher view
___5.
The top right portion of your screen shows that you are now in the Database Administration perspective.
Lab 03 Data Studio
Page 31
IBM Software
B. Connecting to and managing a database

We will connect to the GSDB database using the Administration Explorer view. You will find this view in the top left corner of your Database Administration perspective. (A perspective is made up of a number of views.) ___6. ___7. Expand the view Administration Explorer a little more by clicking on its edge and dragging it over. Then expand the view to see all the databases. Right click on the connection property GSDB Connect
___8.
You are now in a Properties for GSDB screen. Fill in the following (case sensitive!) User name: dbapot Password: password Save password: [check]
___9.
Try [Test Connection]. You should get: Ping succeeded!
Note: if you don't get a successful ping, make sure to fill in the connection properties exactly as shown above
Page 32
Lab 03 Data Studio
IBM Software
___10. In this same Properties for GSDB screen, click on the Common setting ___11. Check box: Connect every time the workbench is started [OK]
___12. You are now connected to the GSDB database. After you leave Data Studio, upon returning, you will automatically reconnect to this database. Notice you see GSDB database in the Administration Explorer below the instance DB2.
Instance management
___13. Maximize your Data Studio screen in order to best take advantage of the entire Database Administration perspective. ___14. Right click on the instance dbapot. Notice the functionality that is available to you for the instance that manages GSDB. We wont be using any of these yet so dont choose any of them. (Note: Configure means changing the DBM CFG parameters; we will explore this in a later exercise.)
Lab 03 Data Studio
Page 33
IBM Software
Database management
___15. Right click on the GSDB database connection to see what database management activities you can perform with the UI. ___16. Choose: Set Up and Configure Configure. This will allow you to change database (DB) configuration parameters.
___17. An Editor view opens up in the middle pane of your perspective. Double click on the view name to expand it to full screen. Dont change any parameters just now, but notice how you could if you wanted to by reviewing the parameters in this task assistant screen. Close this screen when done by clicking on the X in the view tab after double clicking on it (which shrinks it again.)
___18. Expand GSDB database and notice you can click on database level objects like buffer pools or table spaces to manage these as well. Click on table spaces and right click on one of the table spaces to see what you can do with it.
___19. Close all Editor views (which are the top middle screens in your Database Administrative perspective) when done reviewing.
Page 34
Lab 03 Data Studio
IBM Software
Editing and Running SQL

___20. Open a new perspective called the Data perspective. To do this, click on the following: Window Open Perspective Data
___21. You are now in this new perspective called "Data". Expand the Data Source Explorer GSDB database connection as shown below. Notice the first GSDB entry is the connection property, the second is the database itself
___22. Right click on the GSDB database and choose: New SQL Script
___23. Choose the appropriate instance and database connection that this script will run in if it is not shown like this below:
The Editor view will be open with a blank SQL editor session.
Lab 03 Data Studio
Page 35
IBM Software
___24. Using the File Browser, find the script as shown below and copy and paste it into the editor : /home/dbapot/db2_pot/03datastudio/DataStudio01.sql (Hint: use Ctrl-C, then Ctrl-V)
(Alternately, you can use a technique with these commands: File Open File...) ___25. The first SQL statement will use a proprietary Oracle syntax (reference to DUAL) and the second a proprietary DB2 syntax (reference to FETCH) select sysdate from dual; select * from gosales.product fetch first 5 rows only; ___26. Highlight both statements, right click, then choose: Format SQL
___27. Highlight the first SQL statement and hit [F5] SQL statement and then choose: Run SQL)
(You can also right click on the highlighted
___28. Find the output in the bottom right pane of your Data perspective in the SQL Results view. (You may have to expand it a bit to see the results better.)
___29. Highlight the second SQL statement and do the same.
Page 36
Lab 03 Data Studio
IBM Software
Notice that Data studio will use whatever Oracle compatibility features you have enabled for your database. (We enabled this earlier in the Database lab.) ___30. Look at the SQL Results section closely. Notice you can now click on either query you have run before. Both result sets are available to you.
You can right click in the SQL Results pane and remove or save any of these results. ___31. Highlight the first query, then right click on it, then choose: Toggle Comment (or [Ctrl] /)
___32. Remove the keyword ONLY from the second query. Notice you get a syntax warning with the red X mark on the line and a red underline near the syntax problem. (Note: you can turn these off if you don't want to see them.)
___33. Put the keyword "ONLY" back into the SQL statement to fix the syntax error. ___34. Right click in the editor window anywhere, choose: Validate Database Object References
___35. Now change your query to reference a fake column name (like XXX) that does not exist in your table in the query (as shown below) and notice you get an error warning.
___36. Change the editor settings back to how it was in the beginning of this Editor lesson
Lab 03 Data Studio
Page 37
IBM Software
___37. Close this Editor view and dont save the script.
Page 38
Lab 03 Data Studio
IBM Software
C. Exploring Tables
Overview diagrams
___38. Expand the top and side of your Data Source Explorer to see more of it ___39. Expand the objects in this view by clicking on the arrow (twistie) signs next to: 1) GSDB database, 2) Schemas & 3) GOSALES under schemas.
___40. Notice each database object type is represented for you to manipulate with the UI. Data Studio is powerful as you can right click on any object or any level of object and it will show you what things you can do. ___41. Expand the Tables under schema GOSALES. ___42. Select table PRODUCT Hold [SHIFT] Click PRODUCT_TYPE Right Click Add to Overview Diagram
Lab 03 Data Studio
Page 39
IBM Software
___43. At the Overview Diagram Selection screen, check the Infer implicit relationships box. This is a powerful Data Studio capability that can go beyond defined foreign keys on tables. It will match up column names and data types to make relationships in the diagram. Click: [OK]
___44. Data Studio will take a couple of seconds to calculate the inferred relationships and return a diagram of these tables in the Editor view. ___45. Double click on the diagram views tab. This will maximize this view in your Data perspective.
___46. Review the diagram. Move the tables and lines around to get a sense for how this can be redrawn if you dont like the default diagram.
Page 40
Lab 03 Data Studio
IBM Software
___47. Double click the diagram view tab again to shrink it. Select the Properties view and notice you can manipulate the diagram using this view if you want to by selecting anything on the diagram.
This is just a basic functionality of Data Studio. If you want the full power of a data modeling tool, please ask about IBM InfoSphere Optim Data Architect which integrates fully with other Eclipse based tools. ___48. Close the diagram view when you are done with this review.
Lab 03 Data Studio
Page 41
IBM Software
Editing and viewing table data

___49. Find table PRODUCT_SIZE_LOOKUP. Right click on it then Data Edit
___50. In the editing screen find the last row <new row>. Right click on it Insert Row ___51. Add values 900 and Huge to the row. Update another row by changing a value in it like shown below. Click Save or [CTRL]+S
___52. Notice the SQL Results view message that reflects what you just did.
___53. Close the Edit view. Save your work as you exit. ___54. Right click on the table PRODUCT_SIZE_LOOKUP again. This time try: Data Return all rows ___55. Look in the SQL Results view, your changes should be there.
Page 42
Lab 03 Data Studio
IBM Software
Generating DDL
___56. Select all tables in schema: GOSALES (hint: hold [Shift]). ___57. Right click then choose: Generate DDL
___58. Choose all the defaults [Next] then [Next]. ___59. In the Save and Run DDL screen, check the box: Edit and run DDL in the SQL Editor.
___60. Then [Next] then [Finish].
Notice you have generated DDL for all these tables.
___61. Close the script Editor view when done reviewing the DDL.
You have a great amount of flexibility in generating DDL like creating DROP statements, fully qualifying object names, including DDL for related objects, etc., but we just chose defaults for this example to keep it simple.
Lab 03 Data Studio
Page 43
IBM Software
Table maintenance exercices: runstats, reorg

___62. Right click on any table (PRODUCT table shown below) and choose: Update Statistics. Review the SQL Results to see how it did the runstats.
___63. Change to the Database Administration perspective
___64. Find table PRODUCT under the tables view in the Administration Explorer. Right click and choose: Manage Reorg Table
___65. In the Reorg editor choose the options shown below then: Preview Command.
Close this window and any other edit windows when done.
Page 44 DB2 10.1 Administration for the Experienced Oracle DBA
Lab 03 Data Studio
IBM Software
D. Extra Exercise: Debug a stored procedure

Creating a project To debug a stored procedure, it is best to first create a project to put our work into. This allows us to create, alter, and save our scripts in a folder under our workspace. ___66. Return to the Data perspective.
___67. At the top of your Data Studio menu choose: File New Data Development Project
___68. Give the project a name: MyFirstProject. Click [Next].
___69. Make sure you associate the GSDB database connection property with this project. Click [Next].
___70. Change the Default schema to be GOSALESCT which happens to be where the stored procedure is we want to debug.
___71. Click [Finish].
Your project will be created with the properties you just chose.
Lab 03 Data Studio
Page 45
IBM Software
___72. Answer [Yes] to the prompt about opening a new perspective.
___73. In the top left view in your SQL and Routine Development perspective, find and expand your project MyFirstProject in the Data Project Explorer. Notice the types of projects we can do in this view. We will be working on a Stored Procedures project in this view.
___74. Now go to the Data Source Explorer, and find and expand Schemas to find schema GOSALESCT. Find Stored Procedures. Click on GET_CUSTOMER_NAME then drag and drop it into the Stored Procedures section of the project MyFirstProject as shown below.
Page 46
Lab 03 Data Studio
IBM Software
___75. Choose the stored procedure code for GOSALES.GET_CUSTOMER_NAME, right click on it then: Open
___76. Notice the Editor view has the stored procedure code loaded and ready to being work.
Debugging the stored procedure ___77. Right click on the stored procedure, then choose: Deploy
___78. Keep defaults, then: [Next]
Lab 03 Data Studio
Page 47
IBM Software
___79. On the Routine Options screen, make sure to click: Enable debugging Then: [Finish]
___80. The routine should be deployed to the database like this:
___81. Now right click on the stored procedure, then choose: Debug
___82. In the Parameter Values tab, set CUSTOMERID to 101. Then click: [Debug]
Page 48
Lab 03 Data Studio
IBM Software
___83. Data Studio will now warn you that it is about to change perspectives on you. Check the Remember my decision box and then: [Yes]
___84. Look in the upper right hand corner of the screen and notice you now have both a Debug perspective opened. You can switch between any of the open perspectives if you want to, but stay in the Debug perspective for now.
___85. In this Debug Perspective, set breakpoints anywhere in your code by double clicking in the shaded area next to the code. Set breakpoints on all the SELECT statements as shown below.
Lab 03 Data Studio
Page 49
IBM Software
___86. Now either press [F5] to go from line to line or use the icon shown below to Step Into the code. Learn to use [F6] and [F7] for Step Return and Step Over.
___87. As you step through this simple stored procedure, notice the output parameters (variables) change. The code we are using here is purposefully simple to demonstrate how strategically placed breakpoints will help you find what your code is doing and what it is returning.
Page 50
Lab 03 Data Studio
IBM Software
___88. If you run all the way through the code and the session is terminated, then just right click on the terminated session itself and choose: Relaunch. This will let you start your debugging all over again.
___89. Close the Debug perspective when you are done by right clicking on it and then: Close.
___90. Back in the Data perspective, close all the editor views.
Lab 03 Data Studio
Page 51
IBM Software
E. Extra Exercise: Stored procedure performance information (profiling)

You can use Data Studio to "profile" a stored procedure, which means to run it and gather performance information on it, line by line, in order to find out which lines of code are executed, how many times and for how long. Profiling can tell you total sort times, rows read and many other things. ___91. In your Data Project Explorer, find the stored procedure GET_CUSTOMER_NAME again. Right click on it then choose: Run
___92. In the Run screen, click on the Run and Performance Options tab
___93. Check the Performance data box that says: Gather performance information from the database Then: [Run]
Page 52
Lab 03 Data Studio
IBM Software
___94. Double click the SQL Results view to enlarge it, then find the Profiling Data tab. Review all the performance information and imagine a large complex procedure with lots of loops and branches. This information can tell you where the code is going and what it is doing line by line. Right click on any line of code to switch to the InfoSphere Optim Query Workload Tuner to begin a tuning session. (Note: this product has not been installed for this lab and is outside the scope of this topic. Ask about our other PoTs on various IBM tooling for more details.)
___95. In the SQL Results view, right click and choose: Remove All
___96. Close your editors and exit from the Data Studio by using the tool bar: File Exit
*** End of Data Studio Lab by Burt Vialpando ***
Lab 03 Data Studio
Page 53
IBM Software
Lab 04. CLPPlus and Oracle Compatibility

A. Logging on to CLPPlus
We will learn how to use CLPPlus in the interactive and batch modes here. To get started: ___1. Open a Console if you dont already have one open.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/04clpplus You can use cd commands or simply type an alias provided for you that will make this simple:
lab04
___2. ___3.
For our CLPPlus session, we will be using the following parameters: User: Password: Host: Port: Database: dbapot password localhost 50000 sample
(Note: we can also use actual hostname "potserver")
There are several ways to start up CLPPlus. The first method we will use is to connect directly to the database upon start up. In the console, type in the following command:
clpplus dbapot/password@localhost:50000/sample
Page 54
Lab 04 CLPPlus and Oracle Compatibility
IBM Software
___4.
You are now in an interactive CLPPlus window with a default prompt SQL>
Note: There is a -nw option that keeps us in the same console we used to start CLPPlus. This is demonstrated below. For purposes of these lab exercises however, we will not use this option but will use the distinct black background CLPPlus window as shown above. This should help make it easier to know when you are in the CLPPlus session vs. just doing other DB2 commands in the Console.
Page 55
IBM Software
B. Interactive CLPPlus commands

___5. Use the DESCRIBE command to look at the details of the table EMPLOYEE. The columns and their details are listed.
DESCRIBE employee
CLPPlus commands are not case sensitive. In this lab workbook, CLPPlus commands are shown capitalized in order to distinguish the command itself from other keywords, but you don't have to type them in that way if you don't want to. You can use lowercase as well. ___6. Use the HOST command to run any operating system command. For example, try this:
HOST ls -al
___7. Using the File Browser to review script file: clpplus01.sql (which is in the 04clpplus directory)
Page 56
IBM Software
___8.
To execute this script in CLPPlus, use the command (NOTE: The file name is case-sensitive)
START clpplus01.sql
___9. Any DB2 commands in the script will be loaded to the SQL buffer and then executed.
Note: The GET command will load the script into the SQL buffer without executing it.
___10. Use the LIST command to display the SQL buffer:
LIST
Page 57
IBM Software
Use CLPPlus SQL buffer line commands to manipulate a query ___11. We would like to sort the entries by salary in ascending order instead of descending. To do this, we can use the CHANGE command that will do a pattern matching and replace the old token with the new one. Be aware that the pattern string you provide is case-sensitive.
CHANGE /salary DESC/salary ASC

___12. We want to double check that the SQL commands in the buffer have been changed by typing in the command LIST. We can see that line 3 has been changed successfully to ORDER BY job, salary ASC. Note that CHANGE only alters the SQL buffer. The original script file which we loaded remains unchanged.
LIST
___13. Use the RUN command to execute the query contained in the SQL Buffer. You can also use / as an alias to the RUN command. Note how the output will now be ordered in salary ascending order.
RUN
Page 58
IBM Software
Using the editor ___14. Use the EDIT command to invoke the default editor to make changes to the SQL buffer.
EDIT
___15. In the vi editor, change the NOT LIKE value from E% to A% and save this change.
Note: if you have never used the vi editor before, here are some hints on using it: Position the cursor to the letter E in E% and type rA. (This will replace the letter E with A.) Use <esc> : w Use <esc> : q (to write or save the file) (to quit the edit session)
___16. Your buffer has changed and lists the code again for you automatically. Use the / key to run this new change (alternately you can use the RUN command)
Page 59
IBM Software
Writing results to a file (SPOOL) ___17. Use the SPOOL command to save the results of our SQL output to a file in order to make a report. SPOOL requires an output file name and optionally a complete path. Type in the command:
SPOOL employee_report.out
___18. Now execute the following commands to create your report file:
RUN SPOOL OFF

___19. In the File Browser, find your report file and open it (double click):
___20. Use the SHOW command to check the value of a particular CLPPlus setting. Try this to see if your spool is on or not:
SHOW spool
Page 60
IBM Software
___21. Try this to see all of your command control settings:
SHOW
___22. Notice your timing command control setting is off. To see timing of your executed SQL try this:
SET timing on RUN
Page 61
IBM Software
Save and clear the SQL buffer content ___23. Use the SAVE command to save the contents of the SQL buffer to a file:
SAVE employee_changed_report.sql
___24. Now find and review this file using the File Browser
With SAVE, you could hard code a complete path where you want the saved file to go, otherwise CLPPlus will put the file in the path where you invoked SAVE from.
___25. Use the CLEAR command to empty your SQL buffer in order to start fresh.
CLEAR BUFFER LIST
___26. Use the QUIT command to exit CLPPlus.
QUIT
Page 62
IBM Software
C. Running a script file in CLPPlus batch mode

Starting out using CLPPlus batch mode ___27. Using the File Browser find and open the file clpplus02.sh in the directory 04clpplus.
___28. Notice in this script we invoke the CLPPlus with a SQL script file all in one command line:
___29. Using the File Browser, find the SQL script file clpplus03.sql. Open it and review it. Take time to review the control setting commands like SET and COLUMN. ___30. Run the command file to see how it creates a report automatically for you using all of these techniques weve seen so far:
./clpplus02.sh
___31. This script may be a bit slow because we will also reset the compatibility vector to make sure we are in Oracle compatible mode (in case you didn't do that in a previous lab exercise.) ___32. Notice the output report is spooled to a file clpplus02_report.out. Use the File Browser to open this report to see the formatting.
Page 63
IBM Software
Using substitution variables ___33. Lets explore using substitution variables in a script. Use the File Browser to open file clppluus04.sql. ___34. Notice this script has two ACCEPT commands. The first is for the OWNER_NAME_STRING variable which is accepted, defined and used later in the query.
___35. Run this SQL script the way shown below. (This is typed all in one line and there is a space after the database name and before the @SQL script file name. Note: you can use the up arrow key to bring back your previous execution of CLPPlus to make this easier.)
clpplus dbapot/dbapot123@localhost:50000/sample @clpplus04.sql

___36. When prompted for the Schema Owner String, answer the value '%POT%' When prompted for the Table String, answer the value '%EMP%' Make sure to include the single quotes and case as shown below!
These answers are strings that our query uses to find any owner with POT in the name and any table with EMP in its name because the query uses a LIKE syntax in the WHERE clause.
Page 64
IBM Software
___37. Review output report clpplus04_report.out. Notice our query has used the substitution variables to customize the report. (Owner only has POT in the name and the table_name only has ones with EMP in the name. Try running this script again, but this time use different values for the variables, or, just hit [ENTER] when prompted for the variable and let it default and see what happens. (Hint: use the up arrow key to bring back your old command in the Console.)
Substitution variables can be used in your SQL in any way you can dream up in any part of the SQL statement, not just in the WHERE clause. These make a single query more flexible. ___38. Close all your File Browser windows.
Page 65
IBM Software
D. Oracle Compatibility examples

Now lets see some more native Oracle functionality using the CLPPlus. This functionality works in the DB2 CLP too by the way, or in any programming interface for that matter. We will be mixing CLP with CLPPlus command examples in this lab exercise, so do the following: Checking your Oracle compatibility environment ___39. First, lets look at our registry variables to see if we are in an Oracle compatible mode. Type the following in the console window:
db2set -all
Notice the registry variable DB2_COMPATIBILITY_VECTOR. Setting this to ORA turns on all Oracle compatibility features. (It is possible to set this to choose only some compatibility features, but we have set it for all Oracle related features.) To activate this registry variable for your instance, you would start and stop the instance with two commands: db2stop then db2start. (We did these things already in the first command script in this lab.) Once this registry variable is set for your instance, you would next create your database. Creating a database with the compatibility vector set will enable it to use Oracle native data types and also creates an Oracle data dictionary compatible set of views in the DB2 system catalog. (We have already done that for the SAMPLE database in our setup script for this PoT.) Using Oracle proprietary syntax in a DB2 database with CLPPlus ___40. Review and run script clpplus05.sh and clpplus06.sql to see SQL using Oracle proprietary syntax used in a DB2 database. Notice now you will be able to run these kinds of commands in DB2 because you are in a compatibility mode. You can run these in the CLP, in CLPPlus, in a Java program, in any way that you may want.
./clpplus05.sh
___41. Review the output file clpplus05_report.out to see how DB2 can use: DECODE, SYSDATE, DUAL, ROWNUM and NVL. ___42. To see the Oracle dictionary views in the DB2 database, review and run script clpplus07.sh:
./clpplus07.sh
___43. Review clpplus07_sh.out. Seeing these views and the compatibility vector as above tells us we are ready to use all Oracle native PL/SQL syntax.
Page 66
IBM Software
Using Oracle proprietary syntax in a DB2 database with the CLP ___44. We can run Oracle syntax in the DB2 CLP too. However, the CLP does not by default recognize the / as a delimiter in scripts the way CLPPlus does. So, in order to get the CLP to use this / delimiter we use a SET SQLCOMPAT command. ___45. Review script clpplus08.sh
___46. Review the script it calls: clpplus09.sql. Notice this is just regular Oracle PL/SQL syntax and Oracle delimiter that creates a procedure.
___47. Run clpplus08.sh to see how this works:
./clpplus08.sh
___48. Notice that the creation of the procedure is successful and the call to that procedure works. Review file clpplus08.sh.out for details.
Page 67
IBM Software
Automatic Revalidation ___49. There is a database parameter called AUTO_REVAL. This parameter controls how revalidation of objects is enforced in DB2. The most powerful option of this parameter is called deferred_force. Lets see how this works: ___50. From the console, type the following: db2 "connect to sample" db2 "update db cfg using auto_reval deferred_force" ___51. To make sure this has taken affect, type this next (this is case sensitive): db2 "get db cfg" | grep AUTO_REVAL ___52. You should see this if your commands worked properly:
___53. Review script clpplus11.ddl (which is called by clpplus10.sh):
First, notice DB2 will perform the CREATE OR REPLACE functionality on the view. This capability means that we can avoid using DROP in order to recreate a view which preserves grants to the view. Second, notice that the view references a function not yet created, and then the function references a table not yet created. Wont this DDL fail if it is attempted to be run in this order? Normally, yes, but with AUTO_REVAL to deferred_force set as we did earlier, it will work just fine. We will see this in action soon. Third, the table is created and data inserted into it. Finally, the view is used in a SELECT. Results are displayed because the view and function will automatically revalidate upon reference. Since everything is there for them to validate, the view works just fine!
Page 68
IBM Software
___54. Run clpplus10.sh to see how this works:
./clpplus10.sh
___55. Review the output and notice that the view and function are created, but are marked as invalid and an error code is produced
___56. Notice though that at the end of the script, the SELECT from the view works just fine! This is because the view and functions are automatically revalidated upon access.
DB2 has another online schema change ability called soft invalidation. This allows for you to drop or alter an object, even while transactions are using that object. For example, you could have a long running query going against a view. DB2 allows you to alter or drop the view without killing the transaction. The running transaction simply uses the copy of the view until it completes. This is the default setting for DB2. If you want to turn this off, do the following registry variable change: db2set DB2_DDL_SOFT_INVAL=OFF
Page 69
IBM Software
Migrating a schema from Oracle to DB2 ___57. We have taken some DDL from an Oracle database, and separated it by object type as shown below. Lets see if we can create these objects in DB2. ___58. Using your File Browser, review this source DDL in the 04clpplus directory. Pay special attention to the PL/SQL types of objects like packages, procedures, functions and triggers. Notice all of these files use the proprietary Oracle syntax. This would represent all the source code from your source Oracle database that you wish to migrate to DB2.
___59. Review script clpplus20.sh. Note the following things about the script:

It connects as user db2user1
(so, the target objects will end up in that schema) (so, we can create objects in any order) (so, the source DDL can have / delimiters)
It uses auto_reval deferred_force It uses SQLCOMPAT PLSQL
Page 70
IBM Software
___60. It then calls each .sql file using the DB2 CLP Batch Command Processor
___61. Run script clpplus20.sh to create all these objects in DB2
./clpplus20.sh
___62. You can review file clpplus20.sh.out to see the details on the creation of each of these. ___63. Run script clpplus21.sh to see a report of all the objects in the DB2 database under schema db2user1. Review clpplus21.sh.out for that report.
./clpplus21.sh
Page 71
IBM Software
Currently Committed ___64. We can easily see how the Currently Committed behavior works in DB2. ___65. Review and run clpplus30.sh to set up a session that is updating a table
clpplus30.sh
___66. This script does the following:

CONNECT as user dbapot Display CUR_COMMIT database configuration parameter setting SELECT all records from table INVENTORY Begins an UPDATE of the first record in the INVENTORY table, but does not commit it
___67. Scroll up in your console to notice how the table looks before an update is attempted:
___68. Again, please note: user dbapot is in the middle of a non-committed update to this table. ___69. Now, this is important: OPEN A SECOND console, DON'T touch the first one you are paused in. ___70. In this second console, simulate another DB2 application by typing:
db2 "connect to sample user db2user1 using password"
Page 72
IBM Software
___71. Next, select from the INVENTORY table like this, qualifying the schema:
db2 "select * from dbapot.inventory"

___72. User db2user1 is using Currently Committed, so the writer (the update being done by user dbapot) does not block the reader (the select being done by user db2user1). The SQL returns what is currently committed for that first record without a wait or a lock of any kind.
___73. If you want to see what the data looks like that hasnt been committed, you can use a dirty read of the data in memory using isolation level UR (Uncommitted Read). Try this:
db2 "select * from dbapot.inventory with ur"

___74. Notice DB2 reads the dirty data from memory, again, without a lock and without a wait.
Page 73
IBM Software
___75. If you want to use the classic behavior of isolation level CS that does not use Currently Committed, try this:
db2 "select * from dbapot.inventory wait for outcome"
___76. Notice the screen stays in a locked mode. The query is waiting for the other transaction to commit or rollback ___77. Return to the FIRST console and hit any key, this will abort the update and roll back the transaction: ___78. Notice now that both transactions in both consoles complete.
___79. Close the second console and any File Browser sessions.
Page 74
IBM Software
Extra Exercise: Anonymous Block and DBMS package use ___80. To see an example of anonymous block PL/SQL in DB2 as well as support of DBMS_OUTPUT review file clpplus35.sql first. ___81. In a Console, logon into the SAMPLE database using CLPPlus like this:
clpplus dbapot/password@localhost:50000/sample @clpplus35.sql
___82. Quit from CLPPlus
*** End of CLPPlus and Oracle Compatibility lab by Burt Vialpando ***
Page 75
IBM Software
Lab 05. Security

A. Instance Level Security
This lab assumes you have already completed the Data Studio Lab 03 exercises. If you have not, then you should complete sections A and B of Lab 03 to learn how to launch Data Studio and connect to a database. We will first check the instance configuration parameters using Data Studio. ___1. Launch Data Studio make sure you are open to the Database Administration perspective.
___2. ___3.
In the Administration Explorer, connect to the SAMPLE database. (Hint: right click on the database). Use dbapot, password as the User name and Password to connect with as shown below
___4.
Right click on the instance dbapot, then choose: Configure
Page 76
Lab 05 Security
IBM Software
___5.
Choose SAMPLE as the Connection Profile.
___6.
Review the Administration section of DBM cfg parameters in the UI This section of DBM cfg parameters controls security at the instance level A section of DBM cfg parameters is a UI concept only as this arrangement is to help you find similar parameters within the Data Studio UI interface.
___7.
Double click on parameter: AUTHENTICATION. Then click in the Pending Value box to find a drop down option. You can now set the DBM cfg value in the UI
Hover on the question mark symbol
to see help on this parameter
Lab 05 Security
Page 77
IBM Software
___8.
Review parameters: TRUST_ALLCLNTS and TRUST_CLNTAUTH These work with client authentication only.
___9.
Review parameter: SYSADM_GROUP This grant gives the highest authority for the this instance to users in this group. If this is not set, then the default group of the instance owner is assumed.
Notice the other instance level authorities that are granted through a DBM CFG parameter to a group: SYSADM_GROUP, SYSCTRL_GROUP, SYSMAINT_GROUP, and SYSMON_GROUP. Right now they are not set however.
___10. Review parameters: SVRCON_PW_PLUGIN and CLNT_PW_PLUGIN Remember, a plug-in is a DB2 method of controlling database authentication. The default plug-in that uses the OS to authenticate comes with DB2, all others are optional purchases from vendors or they can be custom built by your IT shop. You can pretend to put a plug-in name here called myplugin to see how to set this. Do not save this parameter setting however.
___11. Close the Configure Parameters editor without executing any changes.
___12. Disconnect from the SAMPLE database (right click on it, then: Disconnect)
Page 78
Lab 05 Security
IBM Software
B. Database Level Security

We will be connecting to DB2 from the CLP to do these next security exercises. Please keep your Data Studio session open. We will be returning to it later. Note that when you connect to a DB2 database on a remote server, you need to specify your user credentials. In our labs we connect to DB2 from the same server so our connect string can be simple. ___13. Open a Console if you dont already have one open.
___14. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/05security You can use cd commands or simply type an alias provided for you that will make this simple: lab05
___15. Type the following one at a time in the Console: db2 terminate db2 connect to sample user dbapot using password db2 get connection state db2 connect to sample in exclusive mode If you get an error here, in Data Studio right click on database SAMPLE then choose: disconnect. You cannot get exclusive lock on the database while it is in use. Try the above connect in exclusive mode again. db2 get connection state (You should now show exclusive connection mode.) Exclusive mode connections lock out everybody else. If you were to open another Console and try to connect as a different user (like user db2user1 password password) you would not connect and receive a message shown below:
db2 terminate
(this is important!)
Lab 05 Security
Page 79
IBM Software
___16. Return to Data Studio and connect to SAMPLE again. ___17. Right click the database SAMPLE Manage Privileges
___18. After accepting the message prompt, review the Properties section of this perspective. Notice that you can use the icons shown below to grant to new or existing users, groups or roles any database level authority. We will do this on the next step.
___19. Click on the yellow diamond to make database level grants to a new user.
___20. Fill in the Grantee as GUEST. Check off CONNECT and CREATETAB grant boxes, then: [OK]
Page 80
Lab 05 Security
IBM Software
You did NOT just create a user GUEST. You simply are performing a grant to a user called GUEST so that, if properly authenticated, that user is allowed to connect to the SAMPLE database and then create a table in it. You dont care at this point how GUEST authenticates, you have just made sure that if they do authenticate, they will have these database authorities. ___21. Try this again, but this time use Group and name the new group NEWGROUP.
DB2 does not have the concept of creating nor maintaining users as does some other databases like Oracle. Only the grants to users, groups and roles are maintained in DB2. We will show how this looks in the system catalog later in this lab. ___22. You will now harden these changes to the database by performing the following: ___23. Make sure to click on the database SAMPLE in the Administration Explorer. This will make sure the delta changes we are performing will show up in the editor view.
___24. Find the Review and Deploy Changes icon in the top right corner of the editor view which looks like the one below. Hover on it first to make sure it is the correct one, then click on it.
Lab 05 Security
Page 81
IBM Software
___25. The very first time this is done in a Data Studio session, it can take a few seconds to complete, so please be patient while it sets up your change DDL in a change plan... ___26. Review the changes then click [Run].
___27. The SQL Results view will tell you if you did this properly.
Page 82
Lab 05 Security
IBM Software
C. Object Level Security

___28. In Data Studio click on the Tables for the SAMPLE database. Scroll to find table DBAPOT.ACT.
___29. Right click on the table ACT, then Manage Privileges
___30. Notice the Properties view for the table becomes available. Click on all the privileges for the user DB2COBRA so it looks like the image below:
___31. Notice that an icon symbolizing a delta change now shows next to this table. That means this object is being altered in some way in Data Studio.
___32. Find the icon on this editor view at the top right that symbolizes Review and deploy changes shown below. Hover on it first to see what it is, then click on it when you are sure you have found it.
___33. Note: If you get a warning, you can inspect the [Details] to see that it is telling you a related view might need changes as well as the table. Go ahead with the changes anyway for now.
Lab 05 Security
Page 83
IBM Software
___34. Review the changes. Notice that your earlier double clicking of a grant box adds the WITH GRANT OPTION to the grant. Click [Run].
___35. Security for most other database objects works similarly, take a look at a couple of different object types as the exact kind of privileges vary from object type to object type, for example: Table spaces have only one privilege: USE. Indexes only have one: CONTROL
Other objects, like triggers and buffer pools, dont have any specific privileges associated with them directly at all. Review these kind of objects too.
___36. Close any editors you may have open. Don't worry about saving changes.
Page 84
Lab 05 Security
IBM Software
D. Using the System Catalog Security Views

Determine what privileges and authorities we have in the database by reviewing the system catalog: ___37. In the Data Studio Administration Explorer, right click on Views Database Catalog Filter
___38. In the Conditions screen fill in the Value as %AUTH, then [Finish]
___39. Notice you are now only showing views with names that end in AUTH
___40. Right click on the SYSCAT.DBAUTH view Browse Data
Lab 05 Security
Page 85
IBM Software
___41. You will see all the database authority grants in this database. Notice the last entries were the ones we made earlier in this lab to user NEWGROUP and group GUEST.
___42. Close this view. ___43. Find view SYSCAT.TABAUTH. Right click on it then Browse Data
___44. Find and click on the filter icon on the top right of this editor (browse) session
___45. First click the [Add All] button to select all columns to display in the filter.
Page 86
Lab 05 Security
IBM Software
___46. Next, in the Row Selection Condition section, fill in the column, operator and value as shown below with TABNAME, =, ACT. ACT doesnt have to be entered with quotes, Data Studio will add the quotes. This will filter all data in the browse session to only see grants on table ACT.
___47. Click [OK] to see the results of this filter for the data in this view. You will notice we can see the grants we made earlier in this lab for table ACT for user DB2COBRA.
___48. Right click on the filtered Views in the Administration Explorer again Database Catalog Filter
___49. Blank out the filter and click [Finish]
___50. The views should no longer have a filter on them.
Lab 05 Security
Page 87
IBM Software
E. User and Group Overview

Use the Data Studio special view for users and groups ___51. In the Data Studio Administration Explorer, expand Users and Groups. Click on Users.
___52. Find user GUEST and right click on it Manage Privileges
___53. Notice in the Properties view you can manage all database and object privileges for this single user here in one editor session!
___54. Review group NEWGROUP the same way. So, you can see that these Data Studio views allow you to change all the privileges for a user, group or role in one editor session.
Page 88
Lab 05 Security
IBM Software
F. Schemas This exercise will show you how schemas work. Return to your Console and make sure you are positioned in directory: /home/dbapot/pot_db2/05security ___55. Review & run script Security01.sh. Review output file Security01.sh.out. ___56. The script sets up the example by creating a schema called TSCHEM. Then it creates a table fully qualified with the schema name. It is called TSCHEM.TSCHEM_TABLE
___57. The script next does a simple select from this table, but the first time it fully qualifies the table name with the schema:
___58. The second time it does a select from this table, but uses a SET SCHEMA method:
Notice the results work fine this way too. ___59. Extra exercise: You can explore the schema and table we just created in Data Studio.
IMPLICITSCHEMA is a database authority that lets users create a schema on the fly if it doesnt exist. So, if you issued a CREATE TABLE schema1.table1 command and schema1 did not yet exist and the user had IMPLICITSCHEMA authority, then that schema would be created along with the table.
Lab 05 Security
Page 89
IBM Software
G. Viewing database authorities

We will show you how to view your database authorities using one table function: SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ___60. Review and run: Security02.sh. After running above script, review file: Security02.sh.out The output from this function shows both direct and indirect grants to an authority through various means. The first columns are for direct grants to a user, group or through a public grant The last columns are for role grants, first direct, then indirect Asterisks (*) mean this is not applicable. For example, you cannot grant instance level authorities like SYSADM through a user grant, only through a group assignment (please recall our first exercise in this lab...) Authorities without a "Y" somewhere means the user does not have this authority
Page 90
Lab 05 Security
IBM Software
H. Column and Row level security

Row Column Access Control (RCAC) is also called Fine Grained Security in the database industry. Here's how DB2 does it: ___61. Review and run: Security03.sh. After running above script, review file: Security03.sh.out Notice that at first user DBAPOT can see all 42 records of the table EMPLOYEE, as well as the data in the SALARY column
___62. After Row and Column Access Control is implemented by the security administrator (user DB2SECADM) and rerunning the exact same query produces a limited result set for rows and columns:
Lab 05 Security
Page 91
IBM Software
___63. Use Data Studio to Return All Rows from this table connected as user dbapot.
___64. Notice that any access method obeys these RCAC rules, even the Data Studio UI. They cannot be overridden by any access method. They can only be changed by the security administrator.
___65. Review the properties for this table to see how RCAC is enabled. (Note: we could have added RCAC to our table with Data Studio if we wanted to.)
Page 92
Lab 05 Security
IBM Software
I. Extra Exercise: DB2Audit and AUDIT POLICY

Please disconnect from the SAMPLE database in Data Studio before doing this exercise.
DB2 passive auditing is controlled in following 2 ways: SYSADM is in control of instance level security through the use of the db2audit tool. SECADM is in control of database level security through the use of AUDIT POLICY and AUDIT commands.
___66. A user with SYSADM grants SECADM authority to user secpot which creates 2 audit policies. Review and run script Security04.sh. Explore output file Security04.sh.out; Notice that secpot with SECADM creates 2 audit policies: CHECK_POLICY to determine what DBAs are doing SENSITIVE_DATA_POLICY to determine who is accessing a given table.
___67. The audit facility controlled by SYSADM is demonstrated by the script Security05.sh. Review and run scripts: Security05.sh that executes Security07.sql and Security08.sql Explore output file Security05.sh.out. The last part of the output shows the output of SQL reports run against AUDIT tables. This shows that user dbapot using SYSADM: Did see instance level auditing information, in this case, connection audits Did not see database level audit results from SAMPLE database at all
Hint: You can also use Data Studio to browse table AUDIT.VALIDATE
Lab 05 Security
Page 93
IBM Software
___68. The script Security06.sh shows the audit capabilities exercised by SECADM at the database level. Review and run scripts Security06.sh that executes Security07.sql and Security08.sql Explore output file Security06.sh.out. The last part of the output shows the output of SQL reports run against AUDIT tables. This shows that user secpot using SECADM: Did see database level auditing information, in this case, who was creating or accessing tables Did not see instance level audit results from instance DB2 at all
Page 94
Lab 05 Security
IBM Software
J. Extra Exercise: A quick look into Label Based Access Control

This lab exercise gives you a quick look into the DB2 Label Based Access Control (LBAC). This exercise just shows a very small portion of the LBAC security capability by showing an example of a SALES table having restricted access. ___69. This is the scenario used in this exercise: User db2cobra: User db2user1: User db2user2: User dbapot: full read access to the SALES table will only see sales data from WEST region. will only see sales data from EAST region will see sales data from CENTRAL_NORTH/CENTRAL_SOUTH regions.
___70. Review and run exercise Security09.sh. Review the output file Security09.sh.out. All users issue the identical query: SELECT SALES_DATE, SALES_PERSON, REGION, SALES FROM ACCOUNT.SALES (This query does not have a WHERE clause, so it runs against every row in the table) Notice that the user db2cobra sees all 4 rows of the table:
___71. Other users only see data of their region:
K. Cleanup
After you are done with the above exercises, you can run the following command to clean up the resources: Security50.sh *** End of Security Lab - by Burt Vialpando and Vikram Khatri ***
Lab 05 Security
Page 95
IBM Software
Lab 06. Autonomic Computing

This lab assumes you have already completed the Data Studio Lab 03 exercises. If you have not, then you should complete sections A and B of Lab 03 to learn how to launch Data Studio and connect to a database.
A. Self Tuning Memory Manager (STMM)

___1. Open a Console if you dont already have one open.
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/06autonom You can use cd commands or simply type an alias provided for you that will make this simple: lab06
___3.
Execute Autonom01.sh which executes Atonom01a.db2 and Autonom01b.db2. This will set up our lab. Notice that these scripts create a database AUTONMDB, a buffer pool, a table space and a table for our lab exercises. The script takes about 2 to 3 minutes to complete. Wait for the script to finish before going on to the next step, but during this time you can review the scripts you are running to see what they are doing. After the script is finished, if you are not in Data Studio, re-launch it. If you are in Data Studio already then restart it by choosing: File Restart
___4. ___5.
Page 96
Lab 06 Autonomic Computing
IBM Software
___6.
The restart should have automatically added a new database connection attribute for AUTONMDB in Data Studio. Connect to this database now if it is there. (User: dbapot Password: password)
___7.
OPTIONAL: If this connection property is not there, you can add a new connection manually by right clicking on the Database Connections folder in the Data Source Explorer view and choosing: New
Then fill out the connection attributes as shown below. Test the connection before finishing. You will now be ready to work with your new database AUTONMDB in Data Studio.
___8. ___9.
Next run Autonom04.sh which creates output files Autonom04.sh-bufferpools.out and Autonom04.sh-parameters.out. This file shows all the STMM related database configuration parameters for AUTONMDB:
Page 97
IBM Software
___10. This file shows the buffer pools that are STMM configurable for our database:
___11. Now run Autonom05.sh which executes Autonom06a, Autonom06b, Autonom06c, Autonom06d multiple times. Youll see a window for each session of this running script simulating many users doing work against the STMM_TABLE table in our database. ___12. Let all the sessions run for a couple of minutes or so... ___13. While they are running, watch the Diagnostics Log file as it changes and note that STMM will begin to make changes automatically to the database. Look for entries like the ones shown below:
___14. After this completes you can close the Diagnostic Log tail window when you are done reviewing it. ___15. Execute this script: Autonom07.sh which creates output files Autonom07.shbufferpools.out and Autonom07.sh-parameters.out. .
Page 98
IBM Software
___16. Review and compare files Autonom04.sh-parmeters.out with Autonom07.sh-parmeters.out to see that STMM changed the DATABASE_MEMORY automatically:
___17. Review and compare files Autonom04.sh-bufferpools.out with Autonom07.shbufferpools.out to see that STMM changed two buffer pool sizes automatically:
Note: If the buffer pools or memory configurations did not change by very much for you, then run the script Autonom05.sh again. Your own DB2 session may vary on how STMM engages with the pretend workload submitted in this lab exercise than what is shown here, but it should still make changes none the less.
Page 99
IBM Software
B. Automatic Storage
Note when this lab was first set up, we created the database with the AUTOMATIC STORAGE YES" parameter. This is all you need to do in order to get DB2 to handle automatic storage for you from now on in this database.
If you did not create the database with automatic storage, you can always add this later with: CREATE STORAGE GROUP [NAME] ON PATH [PATH] ___18. Review and execute the command Autonom08.sh that executes Autonom08a.ddl (which contains our ready-made table space DDL) and Autonom08b.sql (which uses administration views to show us information about all the table spaces in this database) ___19. Notice how the container paths look different for automatic and non-automatic storage table spaces. All automatic storage table spaces are under directory /home/dbapot/dbapot/NODE0000/AUTONMDB
Extra Exercise: Convert table space TEST_NONAUTO_STG to use automatic storage

___20. Perform the following commands in your Console, in this sequence: db2 connect to autonmdb db2 "alter tablespace test_nonauto_stg managed by automatic storage" db2 vf autonom08b.SQL db2 "alter tablespace test_nonauto_stg rebalance" db2 vf autonom08b.SQL db2 terminate
Page 100
IBM Software
C. Autoconfigure
___21. Review and execute the command Autonom20.sh to run autoconfigure command contained in Autonom20a.db2.
___22. Review the output in Autonom20.sh.out file ___23. You can modify the Autonom20a.db2 to change APPLY NONE parameter to APPLY DB AND DBM to apply changes in database manager and database configuration parameters.
Page 101
IBM Software
D. Extra Exercise: Automatic Maintenance

Automatic Maintenance RUNSTATS Exercise Setup
In order to test out the DB2 auto maintenance utility, we will build 4 quarterly tables so we can use DB2 autonomics to do RUNSTATS for us on these tables: ___24. Review and run script Autonom30.sh which executes Autonom30a.ddl and Autonom30b.ddl Review output file: Autonom30.sh.out In Data Studio find database AUTONMDB (Use the Data Source Explorer) In Data Studio find the tables AUTOMAINT%
___25. To see what statistics look like for these tables, review and run these scripts: Autonom33.sh which executes Autonom33a.sql Review output file: Autonom33.sh.out
Page 102
IBM Software
___26. Run script Autonom35.sh which executes Autonom35a.ddl. statistics for the table cardinality and NPAGES.
This script will reset the
___27. Autonom33.sh which executes Autonom33a.sql (yes, run this again) Now review this file again: Autonom33.sh.out
So, now you know what these tables look like with and without statistics We will set up the automatic maintenance facility to update these statistics for us from now on.
Page 103
IBM Software
Automatic Maintenance RUNSTATS UI Settings

The first automatic maintenance feature we will explore it the RUNSTATS feature. As of DB2 9.1, the RUNSTATS feature in automatic maintenance is already on by default. Still, we will learn how to use it and customize it in this lab so we can get a handle on how the rest of the automatic maintenance features work. ___28. In Data Studio get to the Database Administration perspective, and find the Administration Explorer ___29. Right click on database AUTONMDB Set Up and Configure Configure Automatic Maintenance
___30. Options screen: Review defaults and leave as-is, click: Online Maintenance Window
___31. Online Maintenance Window screen: Maintenance Window ___32. Offline Maintenance Window screen: Policy
Review defaults and leave as-is, click Offline
Review defaults and leave as-is, click Runstats
Page 104
IBM Software
___33. Runstats Policy screen: Check off: Create or update the runstats policy. Click on: Selected tables Fill in simple condition as shown below which will only run statistics on tables with names that start AUTOMAINT%
___34. Click on Preview Command
___35. Review the commands that will perform the automatic maintenance set up tasks in your database, then click: [Run]
___36. Wait for the command to finish and make sure it is successful. Close the task assistant editor.
Page 105
IBM Software
Checking the UI usage ___37. Now lets see what weve done in the database when setting the automatic maintenance ON for RUNSTATS on all tables. ___38. In your Data Studio view, right click on database AUTONMDB: Set Up and Configure Configure ___39. Find section called Maintenance and find the keyword parameters called AUTO_MAINT, AUTO_TBL_MAINT and AUTO_RUNSTATS.
If these three are set to ON, then DB2 will automatically run statistics in your database. Close this editor window after reviewing. ___40. Find the table called SYSTOOLS.POLICY in Data Studio and browse the data. This is the table that keeps all the automatic maintenance settings you gave it during the UI usage as well as any it determines for itself. Close the editor window when done.
You are now all set up for automatic table maintenance, RUNSTATS on all tables, during your specified maintenance window. DB2 will automatically detect that statistics are required in those AUTOMAINT% tables and run statistics on them. This happens at the discretion of DB2.
Page 106
IBM Software
Automatic Maintenance RUNSTATS Exercise Finalization

___41. To complete this exercise, run script Autonom37.sh which executes Autonom37a.dml This script will simulate activity against the AUTOMAINT% tables by doing selects, updates and deletes to them. ___42. DB2 will now wake up every 2 hours to see if it is within its maintenance windows. If it is, then it will update the statistics for the selected tables sometime within that window. You can go back to this later to check the results of the automatic RUNSTATS you have configured. To check how DB2 is doing, you can run this script again and again until you see the DB2 engine automatically do the work for you: Autonom33.sh Review Autonom33.sh.out
Remember, the desired final outcome is for the automatic maintenance feature to produce statistics for your tables without you having to do so manually. The final outcome should look like this:
Page 107
IBM Software
E. Extra Exercise: Statistic Profiling

DB2 RUNSTATS has the concept of profiling, which is just a way of saving the last way you ran RUNSTATS in your catalog and using that saved command instead of the having to run the entire command all over again. ___43. To see a simple way of how this works, execute these commands: db2 "connect to autonmdb" db2 "runstats on table dbapot.automaint_tab4 on all columns set profile" db2 "runstats on table dbapot.automaint_tab3 with distribution tablesample bernoulli(30) repeatable(4196) set profile" ___44. Now execute and review the output from this script again: Autonom33.sh In output file Automaint33.sh, pay special attention to column PROFILE
___45. To use a previously set profile, run this command: db2 "runstats on table dbapot.automaint_tab4 use profile"
Page 108
IBM Software
F. Extra Excercise: SYSTOOLS setup

Automatic maintenance is controlled with policies that are saved by the GUI into tables in a schema called SYSTOOLS. Lets make these tables and review them: ___46. Review and run these scripts: This script will reset your Policy table and effectively undo the previous exercises in this lab. Do not do this exercise until you are satisfied with the other exercises in this lab and have seen the automatic maintenance work for you at least once! Autonom39.sh which executes Autonom39a.db2 ___47. From Data Studio, find all tables in the SYSTOOLS schema ___48. Review contents of table POLICY There are 5 records in this table Review columns NAME and UPDATE_TIME to get an idea
DB2 normally creates this table for you when you first invoke the Automatic Maintenance UI in Data Studio, but we went ahead and did this manually to see what is involved for purposes of understanding it better in this lab, or this could be done if you every want to start from scratch in your database.
G. Cleanup
After you are done with the above exercises, you can run the following command to clean up the resources: Autonom50.sh *** End of Autonomic Computing Lab by Burt Vialpando ***
Page 109
IBM Software
Lab 07. Deep Compression

A. Table Deep Compression

Setting up the database compression exercise using SAMPLE database
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/07compress You can use cd commands or simply type an alias provided for you that will make this simple: lab07
___3.
Run script Compress01.sh While it is running review the script to notice that it creates 3 tables that are set up this way: Table COMPRESS1_TB COMPRESS2_TB COMPRESS3_TB Initial row count 500,000 0 0 Compression ON? NO NO YES Have any indexes? NO NO YES (3 indexes)
Review details in Compress01.sh.out
Page 110
Lab 07 Deep Compression
IBM Software
___4.
In Data Studio, go to the Data perspective and find and connect to the SAMPLE database. Find and review the table DBAPOT.COMPRESS1_TB. Notice in its properties that it starts out as not using row compression.
___5. ___6.
Open the SQL Script Editor by right clicking on database SAMPLE New SQL Script Run the following SQL in the SQL Script Editor to check the cardinality of this table: SELECT COUNT(*) FROM DBAPOT.COMPRESS1_TB
Page 111
IBM Software
Estimating Compression
___7. Review and run script Compress02.sh This script runs a DB2 table function called SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO that will give an estimate of the compression and percentage of saving in the data pages if compression were to be enabled for any given table. Review the output file Compress02.sh.out.
Remember, this table function command estimates compression on the table before you actually do it. In this way you can determine whether or not you think it is worthwhile to do compression before actually doing it.
Page 112
IBM Software
___8.
In the SQL Script Editor, run the SQL statement in script Compress01c.sql
___9.
So, reviewing the view SYSSTAT.TABLES, this table uses 2,908 pages (of 8192 bytes each because that is the table space page size). This means the table usage is 23,822,336 bytes (a little over 22.7 MB) uncompressed. According to the table function estimator, we should expect a 68% compression savings out of that or 15.4 MB of savings for this table.
Compressing a table Complete REORG

___10. Review and run script Compress03.sh (then review Compress03.sh.out) This script will first ALTER the DBAPOT.COMPRESS1_TB table to turn compression ON and then it will perform a REORG on that table which will build the dictionary used to compress the data during the REORG. This is the most complete way to compress a table because it builds a table-level compression dictionary based on all of the data in the table. ___11. The script does a RUNSTATS on the table to collect the latest statistics for us so we can view it again in Data Studio. ___12. Run the SQL from script Compress01c.sql in the SQL Editor for a second time. ___13. Notice it had a compression ratio of the same amount as the table function estimated.
Page 113
IBM Software
Compressing a table Partial sampling REORG with secondary INSERT of varying data
___14. Review and run script Compress04.sh (then review Compress04.sh.out) This script INSERTS 100,000 records from COMPRESS1_TB into COMPRESS2_TB It then reorgs COMPRESS2_TB to get a compression dictionary on that data, results below:
The script then lNSERTS 400,000 more records into COMPRESS2_TB, but uses a different stored procedure to generate that data. This data is significantly different from the first. NO REORG is done after that 400,000 row INSERT of varying data, rather, Adaptive Compression takes over and still provides excellent compression
___15. Run the SQL from script Compress01c.sql in the SQL Editor for a third time. To see just how different the data is between the first and second INSERTs, review the code in stored procedures COMPRESS_DATA_INSERT1 and COMPRESS_DATA_INSERT2. (Hint: use Data Studio, right click on them and choose ALTER)
Page 114
IBM Software
Compressing a table Complete REORG of all varying data

___16. Review and run script Compress05.sh (then review Compress05.sh.out) This script simply REORGs table COMPRES2_TB Remember though, that it contains varying kinds of data different from COMPRESS1_TB Compress05.sh.out shows the different data values for one of the columns to demonstrate that the two table vary in their data. Run the SQL from script Compress01c.sql in the SQL Editor for a fourth time.
Compressing indexes automatically when compression for the table is ON

___17. Review and run script Compress06.sh. (then review Compress06.sh.out) ___18. This script inserts 500,000 rows into table COMPRESS3_TB from COMPRESS2_TB ___19. COMPRESS3_TB already has compression on, so it will use automatic dictionary compression to on the table when enough data is inserted into it, a static dictionary will be built. After that, any other data will be compressed using dynamic compression ___20. The 3 indexes on this table will also be automatically compressed ___21. Run the SQL from script Compress01c.sql in the SQL Editor for a fifth time.
___22. Automatic dictionary compression kicks in ONLY after about a 3MB sample of data is detected. The static dictionary is then built from that data and the data is compressed using it first, then after that, adaptive compression will kick in for data that is different from that initial sample. This is the easiest way to initiate compression for data because no reorg is done at all, but of course its compression savings isn't quite as good either. Notice here it's 64% vs. 68% when a reorg is done. ___23. Review the end of the output file Compress06.sh.out to see how the index compression worked.
Page 115
IBM Software
___24. First, notice output from a simple query on the catalog table syscat.indexes. This tells us what indexes are on the table and whether or not compression is turned on for them. By default, when you turn on compression for data in a table, the indexes created after that have compression on for them as well. You can however turn off compression for individual indexes if you needed to.
___25. Next notice the output from table function sysproc.admin_get_index_compress_info. This tell us how efffective the compression is for that index.
___26. For extra credit, explore the tables and indexes in Data Studio to see the compression settings.
B. Clean up
In Data Studio, close your editors. Run Compress50.sh to clean up resources after above lab exercises. *** End of Deep Compression Lab - by Burt Vialpando ***
Page 116
Lab 08 Explain Facilities and the Optimizer
IBM Software
Lab 08. Explain Facilities and the Optimizer

A. Create Explain Tables

All DB2 explain facility tools use the explain tables, so lets create them now. We will use the DB2 supplied script found in the DB2 install library under folder misc/EXPLAIN.DDL. ___1. Open a Console if you dont already have one open.
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/08explain You can use cd commands or simply type an alias provided for you that will make this simple: lab08
___3. ___4.
Review and run the following script to create the explain tables in database GSDB: Explain01.sh Launch Data Studio (if not open) and open the Data perspective:
Page 117
IBM Software
___5.
Connect to the GSDB database. Verify that the explain tables were created in schema DBAPOT. These tables are named: EXPLAIN_%
The script also created the ADVISE_% tables. The presentation material mentioned how these tables can be used, but we will not be working with these tables in this lab.
Page 118
IBM Software
B. Union All View Example Setup

To demonstrate the explain facilities in DB2, we will use an example of a DB2 union all view: ___6. ___7. To set up this example, review and run these scripts: Explain02.sh which executes Explain03.ddl and Explain04.ddl The end of the output for these scripts should show a check results section with a Monthly and Quarterly Tax summary. If data is returned from this script and looks like below, then your setup was successful.
___8.
In Data Studio, right click on Tables and choose: Refresh
___9.
Expand Tables again, and find the 4 individual tables named Q?_2012. Sample the contents of one of them to make sure it has data and to see what the data looks like.
Page 119
IBM Software
___10. Expand table Q1_2012 and review its Constraints.
___11. Find the view called YEAR_2012 and right click on it. Sample contents from it too.
___12. Right click on view YEAR_2012 again and choose Generate DDL.
___13. Choose the defaults using [Next] until you see the Preview DDL screen. Use this to double check your union all view DDL. You can open the DDL for editing here by checking the appropriate box. Then [Finish].
Page 120
IBM Software
___14. Review the DDL in the editor. You can reformat it here if you want to be able to better understand what it is doing.
___15. Close this editor view and dont bother to save this edited script. ___16. Clean out your SQL Results cache too. (Right click, Remove All)
We are now ready to run SQL against this union all view (YEAR_2012) to see how the DB2 explain facility works.
Page 121
IBM Software
C. Visual Explain in Data Studio - an overview

___17. In the Data Studio Data Source Explorer, right click on database (not the connection) GSDB New SQL Script
___18. Using the File Browser, navigate and find directory /home/dbapot/pot_db2/08explain and open click: Explain05.sql
___19. Copy and paste the contents of this file into your editor view in Data Studio (Hint: use Ctrl-C, then Ctrl-V)
Notice this script will count all records from the view YEAR_2012 that have a month of value 3 (March). ___20. Highlight and run this script with [F5] to see the results. Your results may vary from the one shown here, but the key thing is that throughout this exercise, your results should not change if we do things to tune this query using explain. Note your query results here: _______
___21. To see this query explained visually in Data Studio, right click anywhere in the query windows (or you can highlight the query itself) and choose: Open Visual Explain
Page 122
IBM Software
___22. Choose defaults by using [Next] and [Finish].
If we had not already built the explain tables through the script we previously ran, the Data Studio UI would build them for us anyway at this time. ___23. Drag open and double click on the Access Plan Diagram that was generated to expand it to fill the perspective. (Note: It may be a hidden a bit on the left most part of your perspective.)
___24. Click on the Scale to Fit icon shown below to make your visual explain fill your screen.
___25. Right click on one of the table icons on the bottom of the diagram and choose: Show Description.
Page 123
IBM Software
___26. Notice you have details on this explain node regarding the details of the table, its statistics creation time, number of rows, and so on. You even can drill down into its table space, columns, frequent values, and so on.
___27. Close this after reviewing it. ___28. Find the section on the left side of the Access Plan Diagram called Canvas. Click on it to expand it or to contract it. The click on the tab called Description of Selected Node
___29. Click on the top node called RETURN in your Visual Explain diagram. Notice this node is described in the canvas. Find and expand Environment to see things like the overall parallelism, CPU speed, buffer pool size, etc. used in this query.
Page 124
IBM Software
___30. Now, notice the total timeron cost from this query shown in the node: RETURN. (To see this, hover over the top RETURN node.) Make note of this result here: __________________
___31. In the Access Plan Diagram, notice that the query is using table scans and these are pretty costly. Review the table scan predicate detail to see which column this is occurring on. Can we reduce the cost of this query somehow to avoid these table scans? (Answer: Yes and we will do this later.)
___32. In the Canvas, find the tab called Overview Diagram. Click on the icons shown below to see what they do.
___33. Close this Access Plan Diagram when you are finished.
Page 125
IBM Software
D. Visual Explain Tuning a query

Design change example
The answer to the previous question about being able to avoid table scans was yes, we can create indexes on the tables for the TX_DATE column to reduce the timeron cost of this query. ___34. Choose: File Open
___35. Navigate to this lab's working directory and double click on file: Explain06.ddl
___36. You will have a new editor session opened with the DDL from that script in it. ___37. Click on the "No Connection" link:
___38. Choose GSDB and then [Finish]
Page 126
IBM Software
___39. Now highlight all the statements in the script and then [F5] to run the DDL together. (Note: alternatively, if you don't highlight anything in the script, Data Studio runs all SQL together by default as one script. So, highlight everything or nothing, and then [F5])
___40. Review the SQL Results view to see if these were created. Make sure all 4 indexes were created.
___41. If the DDL ran successfully, close the editor for this DDL script. You are done with it.
___42. Find table Q1_2012 in the Data Source Explorer and verify it has an index by expanding as shown below: (Note: you may have to refresh the view to see it.)
Page 127
IBM Software
___43. Highlight the original query in your editor (you should not have closed it) right click on it and choose: Open Visual Explain again. Choose the same defaults again and [Finish]. Review the Access Plan Diagram now that we have made a design change to the database by adding indexes. Notice the reduced timeron count especially since all the table scans have become index scans.
___44. Notice that even though we were performing a function in the query on the indexed column, DB2 was able to use the index. In other databases, like Oracle for example, this would require a functional index. The DB2 optimizer is aware of many of its built-in functions and does not require functional indexes for this kind of situation.
___45. Close the access plan diagram now
Query change example

There is room to improve this query and reduce the timeron count. For example, the query looks through all four tables in the union all view and not just one table. We can get DB2 to just look at the one table the March data is actually in:
Page 128
IBM Software
___46. Use your File Browser to find and review script. Explain07.sql. Either of these queries will solve our problem and we will work with them one at a time. Note, the second query uses functions and will not require a functional index to do so.
___47. Replace the single query in our editor session with the contents of this script with a COPY / PASTE. Then highlight the first query and right click on it, then Open Visual Explain
Why does the SQL work? Because we also provided the YEAR and not the just MONTH in the query. Our union all view was based on the table constraints for each table and those constraints contained both YEAR and MONTH. Just providing a month alone in the query was not enough for the optimizer to prune the other tables out. This is true for partitioned tables in Oracle, DB2, etc. You must provide the entire partition key in the WHERE predicate for partition pruning to work. ___48. Run this query to make sure the final answer is not changed from our original answer. (Tuning a query should NEVER change its results!)
___49. Highlight the second query solution (the one using functions) and run it with [F5]. The answer should be the same as when we first ran it at the beginning of this lab. So, adding indexes should not change the result of the query, and writing our query more efficiently should not change the result answer either.
Page 129
IBM Software
___50. Do a visual explain on the second query too. Notice it also gives an efficient plan.
___51. But, what about the query rewrite that DB2 does. What does that mean? ___52. In the Access Plan Diagram, find and click on the Canvas section on the left edge as shown here, then make sure you are on the tab Overview of Diagram
___53. On View the SQL Statements (to the left of the diagram) click on the second tab: Compare the Original tab with the Optimized tab
Page 130
IBM Software
___54. This second tab contains the query rewritten by DB2 and is shown the way the DB2 optimizer sees the query. Notice the function calls have been replaced with <= clauses. Notice that DB2 has rewritten this query to not use functions. ___55. As a final comparison, find the original "bad" query we ran at the very beginning in file Explain05.sql. Run a visual explain on it and this time look at the Original vs. Optimized SQL Statements
___56. Close all editor sessions and Access Plan Diagrams. Dont bother saving any scripts.
Page 131
IBM Software
E. Using db2exfmt explain multiple queries at once

___57. To demonstrate how db2exfmt works, review these scripts Explain08.sh which executes Explain09.dml ___58. From the Console, run Explain08.sh ___59. Explore output file Explain08.sh_plan.out. Notice that explain plans for 3 different queries are included in this output. You can find the beginning of each query by searching on the following text: EXPLAIN INSTANCE
___60. Review the data in the explain tables EXPLAIN_INSTANCE and EXPLAIN_PREDICATE. Notice what the EXPLAIN ALL FOR command produces in these tables.
___61. Review Explain_DB2EXFMT_Command.txt for full command syntax ___62. Use Data Studio to explore the data in EXPLAIN_INSTANCE and EXPLAIN_STATEMENT tables.
Page 132
IBM Software
F. Extra Exercise Using db2expln

Static SQL method
Earlier in script Explain04.ddl, we created a stored procedure called: UNION_DATA. Lets find the DB2 package that contains the static SQL in that stored procedure so we can explain that package: ___63. Review and run this script in the SQL script editor: Explain10.sql Find the package name for the stored procedure in your own database and note it here: _____________
___64. To demonstrate how the db2expln utility works in its static mode, review and run this script: Explain11.sh [package_name] Dont forget to use the package_name parameter when executing this script!
___65. Explore output file Explain11.sh_plan.out Notice packages are broken into sections. Each section is for each SQL statement in the package. So, each SQL statement in any DB2 package can be explained this way.
___66. Close any editor session you may have open in Data Studio. Dont bother to save the scripts.
Page 133
IBM Software
Dynamic SQL Method

___67. To demonstrate how the db2expln utility works in its dynamic mode, review and run these scripts: Explain12.sh which executes Explain13.sql
___68. Explore output file Explain12.sh_plan.out Check the explain tables
___69. Review Explain_DB2EXPLN_Command.txt for full command syntax
Page 134
IBM Software
G. Extra Exercises: REBIND and ROW MOVEMENT

Rebind ___70. Rebind package for the UNION_DATA stored procedure using: Explain14.db2
Question: Why would you think you would ever need to do this? Answer: For stored procedures, the package is bound when it is created. Statistics and the data model can change over time and affect the access path. A rebind will make sure this path is up-to-date.
Row movement ___71. Single out the first record in table Q1_2012 and note the TX_NUMBER here ________
Through the union all view YEAR_2012 update that record with the date: 2012-12-30. Use script Explain15.db2 which has the solution and looks something like this: UPDATE YEAR_2012 SET TX_DATE=DATE('2012-12-30') WHERE TX_NUMBER=5; COMMIT;
Question: What happens to the record in the individual tables and why? Can you find it in table Q1_2012? Answer: The data moves from table Q1_2012 to Q4_2012. Note that this is NOT the DB2 default behavior. When this view was created, the syntax used to make this happen was: WITH ROW MOVEMENT. Find the moved record: SELECT * FROM Q4_2012 WHERE TX_NUMBER=1;
In lieu of the above query, you can also right click on the Q4_2012 table and choose: Return all rows. Then, in the SQL Results, scroll down to the last record. Notice this moved record is there. Try the same in table Q1_2012. You'll see the record is gone.
___72. Close all editors and exit from Data Studio. *** End of Explain Facilities and the Optimizer Lab by Burt Vialpando***
Page 135
IBM Software
Lab 09. Workload Management (WLM)

A. Setting up a custom workload manager environment

___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/09wlm You can use cd commands or simply type an alias provided for you that will make this simple: lab09
___3.
Review and run WLM01.sh. This script will execute SQL against the system catalog of the SAMPLE database showing how the WLM environment looks. This first run of this script shows the default workloads and no defined service classes, which is the way a DB2 database looks just after creation. Review WLM01.sh.out to see how a default WLM database environment looks.
Page 136
Lab 09 Workload Management (WLM)
IBM Software
___4.
Review scripts WLM03.sh and WLM04.db2. This will customize the WLM environment. Notice it creates workloads, services classes, thresholds, work class sets, work action sets, etc. This script does these things in a particular order since the WLM objects are hierarchically dependant upon one another.
___5.
When reviewing the script, there are two workload / service class configurations you should pay attention to: WORKLOAD #1: Name: Identify by: Service Class: (higher resource usage) CLP_Workload_Admin Client userid db2cobra CLP_Serv_Admin
10,000 SOFT CPU shares. High prefetch & buffer pool priority
Service subclass1: CLP_Serv_Admin_HI

6,000 SOFT CPU shares. High prefetch & buffer pool priority
Service subclass2: CLP_Serv_Admin_MED

4,000 HARD CPU shares. Medium prefetch & buffer pool priority
Work Act. Set:
Admin_Actions
Map WRITE work to the high sub service class Map READ work to the medium sub service class
WORKLOAD #2: Name: Identify by: Service Class:
(Lower resource usage) CLP_Workload_User1 Client userid db2user* CLP_Serv_User

50 HARD CPU shares. Low prefetch & buffer pool priority
___6.
Run script WLM03.sh to create these WLM customizations.
Lab 09 Workload Manager (WLM)
Page 137
IBM Software
___7.
Run script WLM01.sh again and review WLM01.sh.out again to see how the WLM environment has changed. Study this for all WLM objects created.
___8.
From this output, note the following things:

The service superclass called CLP_Serv_User does not have a defined service subclass, but it still uses one: SYSDEFAULTSUBCLASS. Workload IPADDR does not have any defined service classes, so it will use a default. Notice the thresholds and event monitors the script created too.
Setting up Priority Aging ___9. Review script WLM05.sh. Notice it calls a script wlmtiersdefault.db2 which is supplied in the DB2 sample scripts directory in the DB2 install path. Review script wlmtiersdefault.db2. This script is useful for instructing you how to set up a WLM priority aging environment, where service subclasses can remap activities to other service subclasses, while those activities are running. The key to how this works is shown below in excerpts from this script: Define the super and subclasses:
Page 138
IBM Software
Create the thresholds that will perform the remapping (AKA priority aging)
Alter the workload to use this
___10. Run script WLM05.sh. Then run WLM01.sh a third time. Review WLM01.sh.out a third time to see your WLM environment now set up with priority aging. Notice the script altered the SYSDEFAULTUSERWORKLOAD to map to the WLM_TIERS service superclass.
Page 139
IBM Software
___11. Notice too that in our earlier script we created some event monitors that write to a DB2 table. We will be using these later.
___12. Review and run WLM10.sh to see this WLM using the db2pd utility. WLM10.sh.out contains the db2pd report. This report has zeros in the activity counts because we havent started running an active workload on the database yet.
Page 140
IBM Software
B. Setting up to simulate a workload

___13. Review and run WLM20.sh which runs WLM21.ddl. These scripts will create a table and inserts 200,000 records into it. This table is used in a simulated workload later.
___14. This script takes a minutes or so to run, so while it is running go on to the next steps to save time in this lab. ___15. Launch Data Studio if it is not already running. In Data Studio, get into the Data perspective so we can connect to the SAMPLE database as user db2cobra, password password. To do this, right click on SAMPLE then: Properties ___16. In the Driver Properties screen, fill in the new credentials as below, then [OK]. Answer "yes" to reconnect.
Note: if you don't connect at this time, just right click and connect as usual. ___17. Start the Data Studio SQL Script Editor for the SAMPLE database.
Page 141
IBM Software
___18. Copy and paste into the editor the entire contents of script file: WLM30.sql Hint: it is located at: /home/dbapot/pot_db2/09wlm ___19. You should now have a SQL edit session that looks like this:
___20. Scroll down to find the very first SQL SELECT statement in the script. It is labeled #1 Workload -> service class occurrences. Highlight it and run it. (note: you can also use [F5] to run it.)
___21. The db2jcc_applicat application name is for the Data Studio connection.
If you see an application name called db2bp, that is the background process of our CLP session that we used to create the WLM environment in. If it is still connected, return to the Console and type : db2 terminate
Page 142
IBM Software
C. Running a workload as user db2user1

We are now ready to start a workload in order to monitor it through built-in WLM monitoring capabilities. ___22. Review WLM22.sh. Notice this script runs script WLM22a 500 times.
___23. Review script WLM22a and notice it connects as user db2user1 and it sets the client information to set our client_userid as db2user1. (This stored procedure is necessary to use since we are submitting this work through the CLP and we want the CLIENT_USER to be db2user1 (not just the SESSION_USER or SYSTEM_USER) The workload is a collection of SELECT, INSERT, UPDATE, DELETE and other commands.
Page 143
IBM Software
___24. Execute WLM22.sh to see it begins its 500 cycles of workload as user db2user1
___25. Return to the SQL Script Editor and run script #1 again. You will now see a new db2bp application running user db2user1. This user is NOT using the default workload. It is using workload CLP_Workload_User1 which in turn uses the service superclass CLP_Serv_User.
___26. db2user1 mapped to this workload because of this statement we used when we created it:
Page 144
IBM Software
___27. In the SQL Script Editor, find, highlight and run query #2 Service class activity counts. Youll see the service class CLP_Serv_User has been busy completing many activities.
Please keep this console open and running the WLM22.sh script for the remainder of this lab. Do not close it! If the loop should complete, simply start the script again in the console to simulate a non-stop workload on your database by client user db2user1.
Page 145
IBM Software
D. Running a second workload as db2cobra

___28. Open a SECOND Console.
___29. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/09wlm (You can use cd commands or alias lab09) ___30. Review and run WLM23.sh. Notice this script connects as user db2cobra and it sets the client information to set our client_userid as db2cobra. ___31. This script will run the same workload 500 times just as the previous script did, but it will use a different client userid. ___32. After submitting WLM23.sh, notice that since your script WLM22.sh was started first it is further ahead in the loop cycles of workload than script WLM23.sh. So, user db2user1 is many workloads further ahead of user db2cobra. (your results will vary from the example below.)
___33. Return to the SQL Script Editor and run script #1 again. ___34. Notice that now db2cobra is running under a different workload CLP_Workload_Admin and this uses a different service superclass CLP_Serv_Admin.
If you recall, this service class runs with much higher resource allocation than the one db2user1 is using. We should expect to see it finishing more activities faster.
Page 146
IBM Software
___35. Run script #2 again to see the activities it has done so far. The total number of activities is behind the other service class right now. But, we should expect it to catch up at some point and pass the number of activities in the lesser service class.
___36. Compare the status of each of the loops of these two scripts. Notice that your user db2cobra has closed the gap or even overtaken the user db2user1 even though the workloads the two users are running are identical. Why has this happened? Because you've given more CPU and other resources to the service class db2cobra runs under!
Please keep this second Console open and running the WLM23.sh script for the remainder of this lab. Do not close it!
Page 147
IBM Software
E. Running a third workload as user db2sec

___37. Open a third Console and change to the same WLM working directory Review and run WLM24.sh. Notice this script connects as user db2sec and it sets the client information to set our client_userid as db2sec. ___38. Run script #1 and #2 again in the SQL Script Editor.
___39. Run script #3 Work Action Set Activity Count. Remember, script wlmtiersdefault.db2 used work action sets to do initial mapping into the service subclasses depending upon what type of activity it was.
We can also use work action sets to map to subclasses based on data tags in table spaces or storage groups. We don't show that in this exercise, but it works in the same way.
Page 148
IBM Software
___40. Run script #4 Long query to test activity remapping. This script will run longer than the subclass threshold allows and will remap the query activity to another subclass. (Important: Dont forget to select and run the FLUSH PACKAGE CACHE DYNAMIC statement along with the query!) ___41. When it finishes, run script #2 again and look at the ACTIVITIES_REMAPPED_IN and ACTIVITIES_REMAPPED_OUT columns. (You may have more than one remap shown.) Notice the subclasses these remaps belong to. WLM_SHORT will remap to WLM_MEDIUM. WLM_MEDIUM will remap to WLM_LONG This is an example of priority aging.
We can also use thresholds to remap based on data tags in table spaces or storage groups. We don't show that in this exercise, but it works in the same way.
Page 149
IBM Software
F. Working with WLM event monitors

___42. Run the CALL WLM_COLLECT_STATS() stored procedure in the script
___43. Immediately run script #2 again.
___44. Notice the in-memory statistics have been set back to zero. But, fortunately, they have been collected in our event monitors. Since our event monitors were created as tables, we can easily select from them. ___45. Run scripts #5, #6, #7 and #8. These seem familiar as they are like the in-memory statistics queries we were using earlier, only now we are using our event monitor tables. These persist after a database is deactivated, in-memory statistics dont. ___46. Now, lets look at a very special event monitor called Threshold Violations. This contains information we cannot get from in-memory statistics. Run script #9. Threshold violations event monitor summary table select
Notice we show two threshold violated, one resulting in a Continue and another in Remap we discussed earlier. This remap occurred when we ran that long query earlier and showe the priority aging capability of WLM.
Page 150
IBM Software
___47. Run script "#10 MON_SAMPLE_SERVICE_CLASS_METRICS". This will run for 60 seconds and take a sample of CPU utilization for each service class.
___48. If you are not doing the extra exercises in the next section, you can close all of your open Consoles now. ___49. Close Data Studio as well.
Page 151
IBM Software
G. Extra Exercise: Miscellaneous WLM lessons

Using the entire in-memory functions: ___50. Review and run each in-memory function that is provided in the script. These are the same functions that we were using earlier in the labs. The earlier exercises only used some of the columns, so these will give you every column, not just the ones we wanted to show you earlier.
Revisiting db2pd: ___51. In a Console, run WLM10.sh while at least one workload is running in another Console. This is the db2pd script. This time you will have in-memory statistics from running workloads to review this utility with. ___52. Close all Consoles and Data Studio now.
H. Clean up
___53. Run WLM50.sh to clean up resources after above lab exercises.
*** End of Workload Manager (WLM) Lab by Burt Vialpando ***
Page 152
Lab 10 Monitoring
IBM Software
Lab 10. Monitoring

A. Snapshot Monitoring
The snapshot monitoring requires turning on switches either at an instance level or at a session level. The following lab exercise shows how to turn on and off monitoring switches. ___1. Open a Console if you dont already have one open.
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/10monitor You can use cd commands or simply type an alias provided for you that will make this simple: lab10
___3.
Review and run Monitor01.sh. Review output in file Monitor01.sh.out to see the monitor switches set at the instance and session levels. Notice that the global monitoring switches are set using UPDATE DBM command at the DB2 Instance level and session specific monitoring switches is set using UPDATE MONITOR command.
The snapshot monitor is a classic monitoring approach accomplished by the use of the GET SNAPSHOT CLP command. ___4. Review and run the script: Monitor02.sh to see the output from the GET SNAPSHOT command. Review output in file Monitor02.sh.out The snapshot monitoring is the technology of yesteryear. While it is going to stay around, the current preference is to use light weigh monitoring functions and the db2pd command line tool which we will demonstrate later in this lab.
Lab 10 Monitoring
Page 153
IBM Software
B. Event Monitoring
An event monitor differs from other monitor types due to the fact that information is collected at the time when that event is detected or completes. The following lab exercise is an example of event monitoring where we will capture elapsed time used by the SQL statements inside a stored procedure. ___5. Review and run the command: Monitor03.sh which runs Monitor03a.sql that has DDL to create a table MONITOR_TAB and a stored procedure MONITOR_SP to insert and update data in that table. Review Monitor03.sh.out to see the results of running the stored procedure.
___6.
Review and run the command: Monitor05.sh which runs Monitor05a.sql that creates an event monitor POT_EVEMON and a stored procedure MONITOR_RS which we will use to see the elapsed time for each SQL statements used inside MONITOR_SP procedure. The db2evtbl command line tool can help you generate event monitor command scripts to store data in target DB2 tables. In the DB2 install path, under the folder MISC, there is an example script for building DB2 Workload Manager event monitors called: wlmevmon.ddl Notice that this script turns on the statement event monitor POT_EVEMON and then runs the procedure MONITOR_SP. The statement event monitor captures the data from this procedure and populates three event monitor tables: POT_EVEMON_HEAD, POT_EVEMON_STMT and POT_EVEMON_CTRL
Now we will run the MONITOR_RS procedure in Data Studio to see the elapsed time for each SQL statement that was inside the procedure MONITOR_SP. ___7. Open Data Studio and connect to SAMPLE database using the Database Administration perspective. Note: If you did the previous WLM lab, you should change the user you connect with to be dbapot, not db2cobra that was used in that lab. Set this via the connection properties option. ___8. Navigate to schema DBAPOT and expand node Stored Procedures.
Page 154
Lab 10 Monitoring
IBM Software
___9.
You should see MONITOR_SP and MONITOR_RS stored procedures. (If not, refresh this view so they will appear.) We will run MONITOR_RS procedure to pull information from event monitor tables in which we captured data from the MONITOR_SP procedure.
___10. Right click on stored procedure MONITOR_RS and open click on Run.
___11. In the dialog box, specify DBAPOT and MONITOR_SP as the arguments to the procedure so that it will pull the information from event tables for each SQL statement. Click Run to continue
Lab 10 Monitoring
Page 155
IBM Software
___12. You will see results from the stored procedure in SQL Results window as shown below. Double click on SQL Results to maximize the screen.
___13.
Click Result1 tab. Expand the TEXT column width to see the statements text and review results:
Page 156
Lab 10 Monitoring
IBM Software
C. Data Studio Stored Procedure Profiling

Data Studio can also be used to gather performance data for a stored procedure. ___14. From the Data Studio, right click on the MONITOR_SP stored procedure. Choose: Run.
___15. Check Gather performance information from the database. Click Run.
___16. When the run is completed, double click SQL Results tab.
Lab 10 Monitoring
Page 157
IBM Software
___17. Click tab Profile Data. Adjust the width of the SQL column. Double click User CPU Time to sort in the descending order.
This view shows the Stored Procedure body and you have options to sort in different fashion to arrive at the SQL which are expensive and needs attention.
Page 158
Lab 10 Monitoring
IBM Software
D. Light Weight Monitoring SQL functions and db2pd

There are two kinds of light weight monitoring in DB2 that is free from latch contention and does not require use of the monitoring switches. The first type of monitoring like this is accomplished using SQL based table functions. The second is using the tool: db2pd ___18. Return to your Console. ___19. Review and run script Monitor07.sh, which calls Monitor07a.sql ___20. Notice that the script loops and does three things in each loop: Runs two SQL table function queries Runs db2pd with the -LOGS switch Runs the stored procedure MONITOR_SP to do work in the database so the results will change on the next loop The use of these SQL table functions shown in this exercise are only 2 of 48 currently available to you in DB2.
___21. Review the output in Monitor07.sh.out file. Notice that we did monitoring of MONITOR_TAB table by running a work load and monitoring the table, table space containers and logs using these lightweight monitoring techniques.
db2pd additional functionality

Unlike the other monitoring tools, db2pd can also be used when the database is not available. This tools peeks inside the instance and database memory to give you unprecedented power and flexibility. ___22. To see more on this tool, in your Console type the following:: db2pd osinfo db2pd -interactive edus -mempools -quit db2pd h file=help.out gedit help.out
E. Cleanup
Please run the following script to clean up objects that we created in this lab: Monitor50.sh *** End of Monitoring Lab by Vikram Khatri and Burt Vialpando ***
Lab 10 Monitoring
Page 159
IBM Software
Lab 11. IBM DB2 pureXML

A. Create a Supporting Database and an XML Ready Table

First, in order to start working with IBM DB2 pureXML, well create a database for it. ___1. Close Data Studio and open a Console if you dont already have one open.
___2.
In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/11purexml You can use cd commands or simply type an alias provided for you that will make this simple: lab11
___3.
Run script: purexml01.sh which executes purexml02.db2 Review these scripts while they are running. Wait for the scripts to complete.
___4. ___5. ___6. ___7.
Launch Data Studio again only when the scripts are finished. Go to the Data perspective and find database XMLDB that was just created and right click on it. Connect with the user name dbapot and password password Review and run scripts: purexml03.sh which executes purexml04.db2 (Note: this will create a table that supports XML) In Data Studio find new table DBAPOT.XML_BOOKS. Click on it and then review the columns in its properties view. Notice the XML column called BOOK_DOC.
Page 160
Lab 11 pureXML
IBM Software
B. Inserting and Exploring XML Data

___8. Review and run scripts: purexml05.sh which executes purexml06.db2 Right click on XML_BOOKS and choose: Data Edit
Notice three new records in the table. Review the XML documents by clicking on the BOOK_DOC fields in any row. Ellipses will appear. Click on the ellipses.
In the XML Cell Editor, find the XML Tree tab. Expand the tree and review.
Explore other XML documents and see if you can tell how they are different from each other. Notice how they have different element structures. For example, the XML document for the record BOOK_ID=34567 has an element called extras that the other XML documents do not have. This shows the flexibility of XML. Notice you can edit this data if you wanted to. We won't be doing that for this lab . Click [Cancel] when done reviewing.
Lab 11 pureXML
Page 161
IBM Software
Exploring XQuery using the SQL Script Editor ___9. Next we will use the SQL Script Editor to execute XML based Queries. Right click on the database XMLDB, choose: New SQL Script
___10. In your File Browser, find and open the file: purexml07.sql ___11. Copy and paste all the queries in this file into the SQL Script Editor window
___12. Run the first query only by highlighting it and then: [F5] Note: alternately, you can use the RUN icon to run the query:
Page 162
Lab 11 pureXML
IBM Software
___13. Do this for each query and explore the result sets from these queries to learn more about exploiting the power of XML in your DB2 hybrid pure native XML database! Notice below one that uses a complex xQuery FLWOR expression:
___14. Close the SQL Script Editor when finished. ___15. Close all editor view sessions. ___16. Clean out your SQL Results view too.
Lab 11 pureXML
Page 163
IBM Software
C. Importing and Exporting XML Data

Importing XML data Using a script
___17. Review and run scripts: purexml08.sh which executes purexml09.db2 ___18. As the presentation already covered, the key to the import utility working for the XML data is the XML FROM keywords which point to subdirectory the XML documents are stored in.
___19. The data file itself has pointers to the exact file, and offset within that file, where the XML data is located for each row of data.
___20. Use Data Studio to view the newly imported data. (Hint: use Edit)
Page 164
Lab 11 pureXML
IBM Software
Extracting XML data using a UI

___21. In Data Studio and right click the table XML_BOOKS Data Extract
___22. Fill in the output file name, like below. Leave the delimiters as-is, then [Finish]
___23. Find and open the file in the File Browser
Lab 11 pureXML
Page 165
IBM Software
D. Creating Indexes on XML Data

___24. From Data Studio, click on the table XML_BOOKS and view its indexes. Review each of the generated indexes Properties to see how XML columns automatically generate indexes to support them.
___25. Review and run script: purexml11.sh which executes purexml12.ddl
Note: there are MANY ways to create supporting indexes on a DB2 XML column. You must find out from your application developers how they are using their XML data to best create these. The Data Studio task assistant UI can help you do this.
___26. Refresh your index listing. Notice the new indexes you have just created. Click on each and explore them in the Properties view.
Page 166
Lab 11 pureXML
IBM Software
E. Extra Exercise: Registering an XSR

___27. Review and run script: purexml13.sh which executes purexml14.ddl Notice the XSR is created by registering the XSD file that is in purexml15_book.xsd ___28. Find and Refresh the Schemas in your XMLDB database
___29. Find schema BOOKS, then XML Schemas SCHEMA1
___30. Alter the XML Schema Repository to explore it some more
Lab 11 pureXML
Page 167
IBM Software
F. Extra Exercise: Validating with the XSR

___31. Copy script purexml16.dml into the SQL Script Editor and run it. (Hint: New SQL Script) What SQL error code do you get and why? (Answer: Element nonxsdelement isnt allowed by our XSD validation check.)
___32. Edit your INSERT statement and take out the element called <nonxsdelement> that is not registered in your XSR and rerun the INSERT statement. Your INSERT statement should now validate against your XSR and succeed.
___33. Close all views and editors in Data Studio and then close Data Studio.
G. Cleanup
After you are done with the above exercises, you can run the following command to clean up the resources: purexml50.sh *** End of pureXML Lab by Burt Vialpando ***
Page 168
Lab 12 Multidimensional Clusters (MDCs)
IBM Software
Lab 12. Multidimensional Clusters (MDCs)

A. CARS Tables Example Setup

To show MDCs in action, we need to create two otherwise identical tables in their own table spaces, but one is MDC and one is traditionally index clustered with indexes on all the key columns. The data well put into these tables is identical for each table. ___1. Close Data Studio and open a Console if you dont already have one open. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/12mdc You can use cd commands or simply type an alias provided for you that will make this simple: lab12
___2.
To set up this lab, run these scripts right away without reviewing them:
MDC01.sh which executes these 3 scripts: MDC02.db2 & MDC03.db2 & MDC04.sh
This can take 5 to 10 minutes to complete. While these scripts run, take this time review what the scripts are doing. Here is an overview of what these scripts do: Overview of what the setup scripts create in database GSDB:
Table: CARS Table: CARS_MDC Table: CARS_TIMING_CHECK Table space: CARS_DATA Table space: CARS_INDEX Table space: CARS_MDC_DATA Table space: CARS_MDC_INDEX Buffer pool: CARS_BP_DATA Buffer pool: CARS_BP_INDEX Buffer pool: CARS_MDC_BP_DATA Buffer pool: CARS_MDC_BP_INDEX Procedure: CARS_INSERT_ALL Procedure: CARS_FETCH_CHK Procedure: CARS_INSERT_CHK Procedure: CARS_UPDATE_CHK Procedure: CARS_DELETE_CHK Regular table w/clustered index and regular indexes MDC table, with dimensions CARNAME, COLOR & YEAR Repository table used to collect timing statistics Each table and indexes for each table has its own table space which has its own buffer pool. (the timing table is put in the userspace1 table space)
Buffer pool for non-MDC data Buffer pool for non-MDC indexes Buffer pool for MDC data Buffer pool for MDC indexes Used to populate CARS & CARS_MDC with generated data Used to perform fetches on both tables and time the results Used to perform inserts on both tables and time the results Used to perform updates on both tables and time the results Used to perform deletes on both tables and time the results
Page 169
IBM Software
B. Explore MDC Space Usage

The table spaces First, lets explore how the space allocation is used with our table spaces by using the system catalog information. ___3. ___4. Launch Data Studio and connect to database GSDB in the Data perspective Open a SQL Script Editor window and cut and paste the SQL from file MDC10.sql.
___5.
Run the SQL and review the output from the system catalog on table space usage
___6.
Since the data and indexes are in their own table space for the CARS and CARS_MDC tables, we can easily see the usage in pages of each of these solutions. Note: the total for CARS_DATA + CARS_INDEX table spaces take up over 4,000 pages. Note: the total for CARS_MDC_DATA + CARS_MDC_INDEX table spaces take up less than 3,000 pages. Note: the CARS_MDC_DATA alone however, is greater than the CARS_DATA Note: it is the savings in index space that makes the CARS MDC solution smaller overall
Note: IBM does not claim to save space with MDCs in every scenario. But the very small index size required to support MDCs is helpful in offsetting the space used up by the data.
Page 170
IBM Software
The tables Now let's explore this at the table level from the system catalog. ___7. ___8. ___9. In the SQL Script Editor window and cut and paste the SQL from file MDC11.sql. Run the script. Notice that in fact the MDC table uses up more data pages, even though it has the exact same data and number of rows. Why? Because some extents are allocated, but not used up. (Remember the presentation?)
The indexes Now let's explore the indexes from the system catalog. ___10. In the SQL Script Editor window and cut and paste the SQL from file MDC12.sql. ___11. Run the script. ___12. Notice the indexes for the MDC tables are significantly smaller and less complex ___13. Notice the indexes for the MDC tables are generated names, created during table creation time
Page 171
IBM Software
C. Explore MDC Table Organization

Lets look at how these two tables differ in the way the data is added to the tables themselves: ___14. From Data Studio browse the data in the DBAPOT.CARS table first (hint: find this in schema DBAPOT and use Return all rows)
___15. Notice what the first 10 rows looks like unfiltered and unsorted (your solution may vary as the data is randomly generated)
___16. Now browse the CARS_MDC table next (again Return all rows) ___17. Notice what the first 10 rows of this table looks like unfiltered and unsorted (your solution may vary)
___18. Notice that the CARS data look randomly put into the table. Actually, it is randomly put into the table. (Only sorting or indexing on it will give it order.)
Page 172
IBM Software
___19. Notice the CARS_MDC data is grouped together however. This is because it is not randomly put into the table. It is organized by the CAR, COLOR and YEAR blocks. ___20. Scroll down in the CARS_MDC table until you see the CARNAME change. This is the very next block of data. From this example, we can conclude we were able to fit 169 records into one MDC block. That is GREAT record co-location!
___21. Is the data really identical in the data groupings between the two tables? Let's check this out by running the SQL from file MDC13.sql. You'll notice that the results for both tables are identical meaning there are the same numbers of each car dimension. You can change the query to see the color or year dimensions too if you want to and see these too are identical.
Page 173
IBM Software
D. Using the db2batch Benchmarking Utility

Use db2batch to test the fetch timing from both the CARS and the CARS_MDC tables. DB2BATCH is a benchmark testing utility and well demonstrate how it works here as well as show how fetching with MDCs is faster: ___22. Disconnect from GSDB in Data Studio since it might be creating locks on the data in these tables and could affect this test.
___23. Run MDC20.sh which executes MDC21.db2 and MDC22.db2 ___24. Review output in the two MDC20.sh_*.out files
A final note: this is a very small table compared to a typical data warehousing fact table. You can expect even much better performance from MDCs in most real-world situations.
Page 174
IBM Software
E. Extra Exercise - MDC Performance Timing Test

There are four stored procedures we will be using to test the timing of fetch, insert, update and delete actions against both tables. You can review the code for these stored procedures in the file MDC03.db2 you executed earlier to satisfy yourself that they perform the exact same actions against both tables in the exact same way. The procedures further place the output of this test in the CARS_TIMING_CHECK table so you can review total time spent (in microseconds) on each action.
Before you do this exercise, make sure you are no longer browsing any of the cars tables in Data Studio or any other way!! If you are doing so, the results will be skewed by the fact that the data is in the buffer pools already. Disclaimer: The purpose of this test is not to try to prove anything specific about performance with MDCs, but is rather to get you to think about how performance will work with MDCs in your environment going through various DML types. We realize this test is neither complete enough nor large enough to be considered comprehensive. The DB2 Toronto Labs have done much more extensive testing and proving of MDC performance than what will be shown in these exercises. Contact your local IBM DB2 representative if you want more details on actual MDC performance test results.
For reference, here are the different colors used in our CARS tables: RED, BLUE, GREEN, YELLOW, BROWN, BLACK, PURPLE, SILVER, GREY, ORANGE, PINK, WHITE, CLEAR
Fetch timing test

___25. From a Console connect to the GSDB database and type in the following: db2 connect to gsdb db2 "call cars_fetch_chk('xxxx')" Substituting xxxx with the color of your choice. (The case of the color is not important, you can use red or RED for example). This stored procedure will fetch all records from each table that has the color you indicated Use three or four different colors to get more than one result for a fetch from both tables Also, use a made up color you know that does not exist like FFFF
Page 175
IBM Software
___26. From Data Studio browse the table: CARS_TIMING_CHECK. This is the table the stored procedure puts the results in. Review the TOTAL_MICROSCNDS column for time spent on each fetch activity; which seems to run faster fetches, MDC or non-MDC? Answer: MDCs are faster at fetching data when using any dimensional column Note: values not found (like our example below "FFFF") is equally fast for both tables
Use the Data Studio SQL Script Editor to run script MDC30.sql to get summary totals from the CARS_TIMING_CHECK table:
Generally speaking, MDC tables can be very efficient for fetching data. Though both tables are highly indexed, MDC indexes are smaller and thus more efficient. Further, you have automatic prefetching advantages for MDC tables due to collocation of like rows. The non MDC clustered table may degrade over time. Run a test of more colors to see the numbers begin to really add up and imagine warehouses with tables with millions of rows and thousands of queries.
Page 176
IBM Software
Insert timing test

___27. From a Console db2 "call cars_insert_chk('xxxx')" TIP: Use different colors in this test than you used in the previous test Try an insert on a made up color you know does not exist, like use: IIII Repeat as above: browse the results table again and rerun the summary script MDC30.sql again to get a new running total
Inserting into MDC tables has a different free space search algorithm than for non MDC tables so random inserts into MDC tables can take a bit more time. Sometimes it does and sometimes it doesn't. You can improve on inserts by sorting them first. INSERT into MDCs utilizes partially filled blocks before creating new ones. The LOAD utility has been enhanced to work with MDCs at a block level so it is more efficient than INSERT. Presorting data for a LOAD helps improve performance and space usage, but it is not necessary. LOAD does not use partially filled blocks though.
Page 177
IBM Software
Delete timing test

___28. From a Console db2 "call cars_delete_chk('xxxx')" Repeat as above; make sure you take into account some colors have changed Try a made up color that does not exist, like using DDDD Browse the timing table again
DELETE from an MDC table can also be quite fast. If you delete on a dimension column, MDCs know already all the blocks that qualify and can delete a block at a time. Also, it has less bid indexing to maintain. Non MDC tables must both find each record, wherever they are, and then delete them and update the rid indexes each time, thus being slower. Your test should have shown an advantage here over the non MDC table. ___29. Run script MDC30.sql to get final totals from the CARS_TIMING_CHECK table How did your MDC table do? Your run might look like this below. Notice that MDC tables are faster on bulk fetches and deletes.
Page 178
IBM Software
Update timing test

___30. From a Console db2 "call cars_update_chk('xxxx')" Repeat as above and try to use colors you have not yet used. Make sure to pick colors that are still in the database, so don't use the ones you deleted in the delete test. Note: this procedure updates the color you choose and adds an X to the front of the data.
UPDATE of MDC tables can be faster or slower depending upon what is being updated. In this exercise, we updated on one of the dimension columns which can make the MDC UPDATE fast because it changes every record in the block quickly as it reads all records together and writes it back in bulk. If our test were to only update one record on a dimension column however, it would have to relocate the data to a new or different block making it slower. How did your test do?
F. Cleanup
After you are done with the above exercises, you can run the following command to clean up the resources: MDC50.sh *** End of MDC Lab by Burt Vialpando ***
Page 179
IBM Software
Lab 13. Data Movement Utilities

A. db2relocatedb
The db2relocatedb tool is for a copy or move of an entire or partial DB2 database at the operating system level. It can also rename or relocate files that a DB2 database uses. To demonstrate this feature do the following steps: ___1. Close Data Studio and open a Console if you dont already have one open. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/13data You can use cd commands or simply type an alias provided for you that will make this simple: lab13
___2.
Review and run script Data01.sh to set up the database called: DATA Data01.sh creates the following: Source database: DATA Source data table space: DATA Source index table space: IDX Source table: RELO_TB (with 1000 rows)
___3. ___4. ___5.
After the script completes, open Data Studio and open the Database Administration perspective. Connect to the DATA database. (Hint: user dbapot, using password password.) Expand Data Table Spaces. Verify that it has two DMS user table spaces.
Page 180
DB2 10.1 Administration for the Experienced Oracle DBAs
Lab 13 Data Movement Utilities
IBM Software
___6.
Select Data table space. Click Containers from the Properties view and check for the container name. Do the same with table space IDX.
___7.
Select Tables. Verify that the database has RELO_TB table as well as the table spaces used by this table.
___8.
Right click on the RELO_TB table and select Browse Data to make sure there is data there.
___9.
Using the File Browser, check on the OS for the table space data files that we created in the script. We will be renaming these files for purposes of this exercise.
Page 181
IBM Software
___10.
Review and run command Data02.sh and Data02a.cfg which will do three steps: 1) take the database offline (alternatively, we could just have taken the table space offline for this example) 2) move OS files and 3) harden those changes to your database.
___11. Review in the File Browser the file name changes done by the script.
___12. Restart Data Studio, (Hint: File Restart) Check the table RELO_TB, its table spaces, containers and data as you did before to see that it all worked.
db2relocatedb can also move an entire database from one location to another, even from instance to instance.
Page 182
IBM Software
B. Using db2move and db2look

In this lab exercise, we will move database DATA to a new database called DATA2 using: db2move db2look to export / import database to generate the necessary DDL files to reproduce the database
___13. Step #1. Review and run Data10.sh. This script exports the DATA database using the db2move command. It puts the data in a directory called DUMP under your current lab directory:
___14. Review Data10.sh.out (in the dump directory) to see how it worked.
Page 183
IBM Software
___15. Step #2. Review and run Data11.sh. This generates a DDL script using the db2look command. The breakdown of this command is as follows: db2look -d data -e -o db2look_dump.ddl -l -x -f The -d option indicates the database name to be reengineered The -e option extracts all objects (entire database) The -o option indicates the output file name for the generated DDL script The -l option generates DDL for user defined table spaces, partition groups & buffer pools The -x option generates authorization DDL The -f option generates an update command for database configuration parameters The -m option generates statistics statements.
___16. This creates a DDL dump file db2look_dump.ddl. Review it to see the entire database. (note: it is located in the DUMP directory) Note: Make sure to change the two CONNECT commands in this file to database DATA2 as shown below. (We will be creating a different database called DATA2.)
___17. Step #3. Review and run Data12.sh. This creates a new target database DATA2. This database could actually be on any platform in any codepage as this technique can relocate a database from any platform to any platform as long as the endianness is the same.

It then recreates the database structures using the db2look_dump.ddl file. It then imports all the data using the db2move data2 load command. db2move accepts two loading options, IMPORT and LOAD. If we use the IMPORT option, the table definition can be recreated from IXF files. But in case of the LOAD option, the table must be present in target database. The db2look utility should be used to generate other objects like triggers, UDFs event monitors, any DB2 object, in the target database.
Page 184
IBM Software
___18. Check results in database DATA2 in Data Studio. (Hint: you can either add a new connection for this database manually or restart Data Studio again with: File Restart)
Page 185
IBM Software
C. SYSPROC.ADMIN_MOVE_TABLE
___19. Review and run Data20.sh. This will move a table from one table space to another. This only begins to show the many options of this powerful stored procedure. ___20. Review terminal output message (shown below) as well as file Data20.sh.out
Page 186
IBM Software
D. Data Ingest
The INGEST utility can be run continuously to pump data into DB2 tables using SQL array inserts, updates, and deletes until data sources are exhausted. Ingest command is restartable from the last commit point. Ingest utility also works for DB2 DPF (Warehouse) and DB2 pureScale (OLTP) environments.
This exercise demonstrates the use of the INGEST utility. ___21. IMPORTANT: Close Data Studio for this exercise. The INGEST utility may need the memory used by Data Studio in your VMWare image, so to avoid a memory problem, close it now. ___22. Review and run Data30.sh. This script creates an INGEST_SAMPLE table with 10 rows.
___23. Review data file Data32b.txt. This file has 7 rows of data having 3 new rows, updated information for 3 existing rows and indication to delete one row. Action New Update Delete Description HULU, FACEBOOK, LINKEDIN WAL MART, JC PENNY, IBM KODAK
Page 187
IBM Software
___24. Review script Data32a.SQL which has the INGEST command to merge the data.
___25. Review and run script Data32.sh. This script will run the INGEST command (Data32a.sql) against data file Data32b.txt and merge the data in INGEST_SAMPLE table.
Note: 3 new rows are inserted, 3 rows are updated and 1 row is deleted. We have only shown one capability of the INGEST utility and there are others like continuous data ingestion, reading from pipe etc.
E. Cleanup
Run the following command to clean up DATA database: Data50.sh *** End of Data Movement Utilities Lab by Vikram Khatri and Burt Vialpando ***
Page 188
Lab 14 Backup, Restore & Recovery
IBM Software
Lab 14. Backup, Restore & Recovery

A. Offline Backup
We will create a database called BKPTEST to demonstrate DB2 core backup, restore and recovery features. ___1. Close Data Studio and open a Console if you dont already have one open. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/14backup You can use cd commands or simply type an alias provided for you that will make this simple: lab14
___2. ___3.
Review and execute script Backup01.sh. This script creates a database BKPTEST and adds some tables to it so it will have data to work with for this lab. The next thing the script does is quiesce and deactivates that database, which is a key way to taking an offline backup. It then performs the backup as shown below. The output of all commands is stored in Backup01.sh.out file; review this file now.
___4.
Find the backup in the directory db2backup. Notice the file name of that backup incorporates the timestamp taken from the backup. This is how DB2 names all its backups so it is impossible to accidentally write over a DB2 backup in the operating system.
Page 189
IBM Software
B. Offline Restore
___5. We need the timestamp of the BKPTEST database backup in order to restore it. There are three methods to locate the timestamp of the last backup. The first is to manually write it down from the backup script output. The second is to find the backup file itself and get the timestamp from that. The third way is to review the history file. To do this last way, we use the command: db2 list history backup all for bkptest ___6. This command lists all the timestamps of all the previous backups taken on BKPTEST database. Review and execute: Backup02.sh
___7.
Here is what the history file output looks like:
Page 190
IBM Software
___8.
You can also use following SQL command to find most recent timestamp from history file for full backup using the view SYSIBMADM.DB_HISTORY db2 connect to bkptest db2 x "SELECT max(START_TIME) FROM SYSIBMADM.DB_HISTORY where operation = 'B' and operationtype = 'F'"
The value of operation and operation type can be looked from following table:
Operation B Description Backup Operation Type F Offline backup N Online Backup I Incremental offline O Incremental online D Delta offline E Delta online None E End of logs P Point in time F Offline I Incremental offline N Online O Incremental online R Rebuild
D F R
Dropped table Roll forward Restore
___9.
Review and run script Backup03.sh to restore the BKPTEST database from a backup.
Error message SQL2540W, warning 2539 is normal for restoring over an already existing database, which is what we did in this exercise.
Page 191
IBM Software
C. Offline Redirected Restore using Data Studio

This lab assumes you have already completed the Data Studio Lab 03 exercises. If you have not, then you should complete sections A and B of Lab 03 to learn how to launch Data Studio and connect to a database. This is a GUI lab exercise to demonstrate redirected restore in DB2. In this lab exercise, we will change the locations of the two table space containers and modify their sizes. Please follow these steps: ___10. Open Data Studio and open the Database Administration perspective ___11. In Administration Explorer, connect to database BKPTEST. (Hint: user dbapot password password) ___12. Right click BKPTEST, select Back Up and Restore Restore
___13. The Restore Database view will open. Select Restore Objects and click to select the backup image.
Page 192
IBM Software
___14. Select Restore Containers. Click the drop down of Table space with containers to be redirected and select HDATA16.
___15. Click Add. Enter container path /home/dbapot/pot_db2/14backup/db2newloc/BackupData1601.dat and size as 10000 pages.
___16. Select HIDX16 from the drop down. Click Add. Specify container path /home/dbapot/pot_db2/14backup/db2newloc/BackupIndex1601.dat and size as 5000 pages.
___17. Click Preview Command
Page 193
IBM Software
___18. Review the generated RESTORE DATABASE command. Click Run.
___19. The redirected restore commands run and you will be able to see the output.
___20. When this finishes, use the File Browser to review the contents of the db2newloc folder.
___21. Verify this by looking at the table space containers in the database BKPTEST in Data Studio as well:
Page 194
IBM Software
D. Configure Database Logging

To enable archive logging in DB2, we only have to set one database configuration parameter called logarchmeth1. After this parameter is set for the first time, DB2 will make sure we have a full database backup as a base line to work with. So, we will take that backup of the database to make sure we have this base line in order to do future restores to a point-in-time. ___22. IMPORTANT! IN DATA STUDIO DISCONNECT FROM THE BKPTEST DATABASE NOW! ___23. Review and run: Backup04.sh. Review the output in file Backup04.sh.out.
___24. We built this lab's logging script that updates the db cfg parameters using the Configure Database Logging task assistant in Data Studio. We will not be using this task assistant in the lab, but you should know it is available and that it simplifies the first-time logging setup for your databases. To use it, right click on database then Set Up and Configure Configure Database Logging. (We are not going to finish using this GUI here in this lab, but you should know about it.)
___25. Review output file Backup04.sh.out carefully to make sure a backup was taken. It should look something like this:
Page 195
IBM Software
E. Online Database Backup

After turning archive logging on, it is now possible to take online backups of the database as well as take individual table space backups. This next script takes an online backup of database BKPTEST that will include all of the table spaces. ___26. Review command Backup05.sh before running it. This lab script will kick off a secondary script that inserts data into table BACKUPTEST and then loads records into table BKPLOAD before doing the on-line backup. The purpose of this is to demonstrate the online backup being done while work (eg. the INSERTs and the LOAD) is being done on the database. It also shows how recoverable load operations are handled. ___27. Once the above lab exercise is done, please go to the Windows Explorer (refresh if necessary) and review the contents of db2loaddata and db2primarylogarch folders. During the load operation, DB2 keeps a copy of the data in db2loaddata folder so that the subsequent RESTORE operation can use the same data to load the table during recovery process. This is important to note as the LOAD utility does not generate DB2 LOG records but it is possible to use a recoverable load as shown in this lab exercise.
___28. Run: Backup05.sh. Notice that two different consoles are doing work. One is doing the online backup while the other (smaller console) is doing INSERT and LOAD operations.
___29. When completed, notice how LOAD data is kept in the db2loaddata directory and explore the db2primarylogarch directory as well.
Page 196
IBM Software
F. Database Recover and Restore / Roll Forward Techniques

___30. First, the database RECOVER command is demonstrated. (This is for ease of use.) Review and run: Backup06.sh
___31. Next, the RESTORE database and ROLLFORWARD commands are demonstrated. (This is for greater control.) Next, review and run: Backup07.sh
Check the count in BACKUPTEST and BKPLOAD tables and it should be 50,000 rows. The BACKUPTEST table gets 25,000 rows from the LOGS whereas table BKPLOAD gets its data using the RECOVERABLE load operation from db2loaddata location.
Page 197
IBM Software
Extra Exercises G. Recover a Dropped Table

___32. To recover a dropped table, it is necessary that we have an offline/online database/table space level backup taken previously and that the database is in RECOVER mode. These are the 7 steps used to simulate a recovery of a dropped table: 1. Take an online backup of the database to level-set this exercise 2. Create a table after the full database backup and then drop it to simulate an accidental loss 3. Pick up the dropped table ID from the history of the dropped table 4. Restore the table space (containing the table) from the previous backup image 5. Unload the dropped table's data 6. Recreate the table using the DDL from the history command 7. Load the data into the table ___33. Review and run the following command to execute all above steps: Backup08.sh
H. Restore a History File

Sometimes we may need to restore a history file from a backup. The script Backup09.sh restores the history file from most recent online backup. The heart of this script is show below: ___34. Review and run: Backup09.sh
Page 198
IBM Software
I. Moving Table Space Locations with a script (Redirected Restore)

___35. You have already seen an exercise using a GUI to perform a redirected restore to move the table space container locations. The heart of the redirected restore is the RESTORE command followed by SET TABLESPACE command. Then it continues the RESTORE operation. ___36. You can also perform a redirected restore using an automatically generated script through RESTORE command. Review and run: Backup10.sh (the heart of this script is as follows):
___37. When you run the above script, the RESTORE command generates the redirected restore script to a file called redirect.clp. Find this file and edit it:
Page 199
IBM Software
___38. Find and modify the table space container names for HDATA16 and HIDX16 as shown below. (Note: there are TWO changes you need to make!)
___39. After modifying the generated script to change container names, save the changes and run this script this way: db2 tvf redirect.clp (Please disconnect the Data Studio connection if it is connected. You may get Database is in use error if applications are connected with it. The redirected restore can be performed only in offline mode with the above command.) ___40. If you get a warning, that is OK, say "Yes" to accept it. ___41. The output from above script is kept is BKPTEST_NODE0000.out. Please verify this file and if it was executed correctly, you will see the new table space container names. Use the File Browser and check the new table space containers locations. ___42. After running above script, you cannot connect to the database as it is in roll forward pending mode. Run the roll forward command as shown below. db2 rollforward db bkptest to end of logs and complete
Page 200
IBM Software
J. Online Table Space Backup / Restore / Recovery

___43. To demonstrate online backup/restore and recovery of table spaces, we will follow these steps. 1. Insert 1000 rows in already created BACKUPTEST table. 2. Take online backup of these two table spaces. 3. Insert another 1000 rows in the BACKUPTEST table. 4. Assume that we need to recover these two table spaces due to disk failure. Do an Online Restore of these two table spaces. After the online restore, you will get an SQL0290N error if you try to access the table space. 5. Roll forward the transactions to apply changes from logs. 6. Check the count of rows and it should be 2000 rows in BACKUPTEST table. ___44. Run the following command to perform the online backup and restore of the above two table spaces. Run: Backup11.sh
K. Incremental Backup / Restore / Recovery

___45. We will use the following steps to demonstrate incremental backup and restore: 1. Update TRACKMOD database parameter to enable incremental backup 2. Insert 1000 rows in the BACKUPTEST table. 3. Perform online backup of BKPTEST database. 4. Insert another 1000 rows in the table 5. Perform 1st incremental backup on BKPTEST database. 6. Insert another 1000 rows in the table 7. Perform 2nd incremental backup on BKPTEST database 8. Insert another 1000 rows in the table 9. Assume that the disk containing HDATA16 and HIDX16 has failed. Restore backup of BKPTEST database 10. Apply incremental backups 11. Roll forward the transactions 12. We should see 4000 rows in the table after recovery ___46. Run the following command to demonstrate online incremental backup and restore: Backup12.sh
Page 201
IBM Software
L. Delta Backup / Restore / Recovery

___47. We will use the following steps to demonstrate delta backup and restore: 1. Update TRACKMOD database parameter to enable incremental backup 2. Insert 1000 rows in the BACKUPTEST table. 3. Perform online backup of BKPTEST database. 4. Insert another 1000 rows in the table 5. Perform 1st delta backup on BKPTEST database. 6. Insert another 1000 rows in the table 7. Perform 2nd delta backup on BKPTEST database 8. Insert another 1000 rows in the table 9. Assume that the disk containing HDATA16 and HIDX16 has failed. Restore backup of BKPTEST database 10. Apply delta backups 11. Roll forward the transactions. 12. We should see 4000 rows in the table after recovery ___48. Run the following command to demonstrate online incremental backup/restore and recovery. Run: Backup13.sh ___49. Close Data Studio.
M. Cleanup
After you are done with the above exercises, you can run the following command to clean up resources. Run: Backup60.sh
*** End of Backup, Restore and Recovery Lab by Vikram Khatri and Burt Vialpando ***
Page 202
Lab 15 Additional Misc. Topics
IBM Software
Lab 15. Additional Misc. Topics

A. Temporal Data Management & Time Travel Query

Temporal Data Management ___1. Open a Console if you dont already have one open. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/15misc You can use cd commands or simply type an alias provided for you that will make this simple: lab15
___2.
Review and run script Temporal01.sh. This will set up the POLICY_INFO and POLICY_INFO_HIST tables that will support temporal data management. Review Temporal01.sh.out to see the two tables created for this lab exercise.
Page 203
IBM Software
___3.
Launch Data Studio if it not already open, then connect to the GSDB database and use the Data perspective to review the tables to see the versioning information. Hint: schema is DBAPOT. (Note: we could have built our temporal tables in Data Studio without this script.)
___4.
Run script Temporal03.sh to see the data in the tables. At first, the tables are empty.
___5. ___6.
Find the script file Temporal04.dml and bring it into a SQL Script Editor session in Data Studio. (Hint: New SQL Script) Highlight and run each DML statement one at a time.
Page 204
IBM Software
___7.
After each DML execution in the SQL Script Editor, run script Temporal03.sh to see what the tables look like:
___8.
After you finish the INSERTS, find script Temporal05.dml and do the same, running the three UPDATES, one at a time and reviewing the output. Notice on the UPDATE, a new history record is generated.
Page 205
IBM Software
___9.
Finally, run the last DELETE DML operation and review the output, which should look like this:
___10. Study how the start and end times relate to each other. For example, the last history record for POLICY_ID 'A001' ends when the current record for it starts. Time Travel Query ___11. Copy and paste script file Temporal06.sql into the SQL Script Editor. ___12. Review your own output from the Temporal03.sh file in your Console (shown above) to notice the timestamps of your data. Your examples will be run with later and different timestamps than the examples shown here in this lab document, so you have to adjust your timestamps in the query in order to get them to work.
___13. Examples of how this output looks when run with appropriate dates is shown below:
Page 206
IBM Software
B. Federation simple DB2 to DB2 example

___14. Open a Console if you dont already have one open. In the Console, change directories to the first lab working directory called: /home/dbapot/pot_db2/15misc You can use cd commands or simply type an alias provided for you that will make this simple: lab15
___15. If you have NOT done so already, create a SAMPLE2 database by using the following CLP command: db2 create database sample2 (we will need this database to federate from) ___16. Review script Fed01.sh to see it has 5 steps: 1) Enable federation, 2) create a wrapper, 3) create a server, 4) create a mapping and 5) create a nickname. ___17. Run script Fed01.sh
___18. At end of the script, notice it runs a query using the nickname EMP_NICK which is in the SAMPLE2 database federated from the table EMP in the SAMPLE database
Page 207
IBM Software
Federation is enabled ___19. In Data Studio connect to database SAMPLE2. (userid dbapot password password) ___20. In the Database Administration perspective, right click on Instance dbapot and choose: Configure
If Data Studio asks you for a Connection Profile, choose SAMPLE2
___21. Find the section called Environment, then the parameter FEDERATED and notice the script has changed this to YES. This allows for federation to be done in any database in this instance.
___22. Close this parameter edit session when done reviewing.
Review federated objects ___23. From Data Studio, go to the Data perspective.
Page 208
IBM Software
___24. In the Data Source Explorer, find and expand the entire tree for Federated Objects under SAMPLE2 database
___25. First notice the Wrappers and the one called DRDA This wrapper library is found in the lib subdirectory of the instance sqllib directory, so on this Linux system by default this should be in /home/dbapot/sqllib/lib/libdb2drda.so'. If we had other wrapper DLL for Oracle or SQL Server, this is where we would put them to create a wrapper. ___26. Next notice the Defined Remote Servers. We have defined one called SAMPLE for the SAMPLE database ___27. Next notice the User Mappings. We have defined one called DBAPOT for server SAMPLE. ___28. Finally, expand EMP_NICK under Nicknames and explore all the attributes of this object.
C. Cleanup
After you are done with the above exercises, you can run the following command to clean up the resources: Misc50.sh *** End of Misc Additional Topics Lab by Burt Vialpando ***
Page 209
IBM Software
Appendix A. Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106-0032, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.
Page 210
IBM Software
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
Appendix
Page 211
IBM Software
Appendix B. Trademarks and copyrights

The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:
IBM Lotus IBM logo pureXML 1-2-3 Sametime AIX DB2 IMS
Microsoft, Windows, Windows NT, and the Windows logo 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 and service names may be trademarks or service marks of others.
Page 212
IBM Software
OPTIONAL TOPICS VOTING SHEET

Indicate which topics you prefer to cover with the optional time in the PoT session
Name: (optional)
_____________________________________________________________
Rules and guidelines for voting: You can talk with others on your team about how they want to vote, so you can vote similarly You can only vote once for yourself You can refrain from voting if you want to TOPIC or LAB DB2 Compression DB2 Compression LAB Explain Facilities Explain Facilities LAB DB2 Workload Manager (WLM) DB2 Workload Manager (WLM) LAB DB2 pureXML DB2 pureXML LAB DB2 Multidimensional Clusters DB2 Multidimensional Clusters LAB DB2 Data Movement DB2 Data Movement LAB DB2 Backup, Restore & Recovery DB2 Backup, Restore & Recovery LAB DB2 Monitoring DB2 Monitoring LAB Misc Additional Topics & LABs
* Ranking
Time to complete 20 minutes 20 minutes 60 minutes 45 minutes 60 minutes 40 minutes 30 minutes 30 minutes 30 minutes 30 minutes 60 minutes 30 minutes 45 minutes 75 minutes 30 minutes 30 minutes 40+ minutes
Ranking *
Give 10 to your highest, 9 to your next highest and so on down to your lowest with a ranking of 1 If you want to do a lab for a topic, rank the lab for a topic the same as the topic The time to complete is listed to remind you of how much time each topic usually takes We will tally up the rankings of each, and the ones with the highest go first, and so on, until we run out of time for our PoT session
Optional Topics Voting Sheet
NOTES
NOTES
Copyright IBM Corporation 2012. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBMs sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml.

PoT IM 06 1 027 14-Workbook

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PoT IM 06 1 027 14-Workbook

Caricato da

Copyright:

Formati disponibili

IBM Software Information Management

An IBM Proof of Technology

IBM DB2 10.1 Administration for the Experienced Oracle DBA

An IBM Proof of Technology

Version 7.0 December 7, 2012 Burt Vialpando & Vikram Khatri

LAB 03. LAB 04.

LAB 07. LAB 08.

[This page left intentionally blank]

DB2 10.1 Administration for the Experienced Oracle DBA

Helpful icons you can create for your desktop:

Properties Command: /opt/IBM/DS3.1.1/eclipse -product com.ibm.datastudio.consolidated.product.ide

Properties Command: gnome-terminal --workingdirectory=/home/db2inst1 -window-with-profile=db2inst1

Properties Command: Default when you log in as dbapot

DB2 10.1 Administration for the Experienced Oracle DBA

The script directories and files:

*** End of Lab Instructions ***

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01. Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

To review your DB2 registry variables, do this command: db2set all

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

B. Start and Stop a DB2 Instance

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

D. Create a New DB2 Instance

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

E. Catalog a DB2 Instance

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

db2 get dbm cfg | grep SVCENAME

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 01 Instance Exploration

*** End of Instance Exploration Lab - by Burt Vialpando ***

Lab 01 Instance Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 02. Database Creation and Exploration

To enter the DB2 CLP in interactive mode, type: db2

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 02 Database Creation and Exploration

Lab 02 Database Creation and Exploration

DB2 10.1 Administration for the Experienced Oracle DBA

B. The DB2 System and Local Database Directories

DB2 10.1 Administration for the Experienced Oracle DBA

Lab 02 Database Creation and Exploration

Lab 02 Database Creation and Exploration

* End of Lab Instructions *

* End of Instance Exploration Lab - by Burt Vialpando *