Front cover. DB2 for Linux, UNIX, and Windows Performance Tuning and Monitoring Workshop. Student Exercises. IBM Certified Course Material V2.0.0.

Transcription

1 V cover Front cover DB2 for Linux, UNIX, and Windows Performance Tuning and Monitoring Workshop (Course Code CF41) Student Exercises ERC 9.0 IBM Certified Course Material

2 Student Exercises Trademarks IBM is a registered trademark of International Business Machines Corporation. The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both: AIX DB2 DB2 Universal Database DRDA Informix MVS MVS/ESA OS/2 OS/390 z/os Alerts is a registered trademark of Alphablox Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. December 2006 Edition The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Copyright International Business Machines Corporation 2001, All rights reserved. This document may not be reproduced in whole or in part without the prior Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

3 V1.2.2 Student Exercises TOC Contents Trademarks v Exercises Description vii Exercise 1. Database Performance and Monitoring Exercise 2. Tablespace and I/O Performance Exercise 3. DB2 Memory Management Exercise 4. DB2 Automated Memory Management Exercise 5. DB2 Explain Tools Exercise 6. DB2 Optimizer Exercise 7. Using Indexes for Performance Exercise 8. Complex SQL Performance Exercise 9. Using DB2 Utilities for Performance Exercise 10. Monitoring Database Health and Activity Exercise 11. Application Performance Exercise 12. Event Monitoring Appendix A. UNIX vi Editor Command Summary A-1 Copyright IBM Corp. 2001, 2006 Contents iii Course materials may not be reproduced in whole or in part without the prior

4 Student Exercises iv DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006 Course materials may not be reproduced in whole or in part without the prior

5 V2.0 Student Exercises TMK Trademarks The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies: IBM is a registered trademark of International Business Machines Corporation. The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both: AIX DB2 DB2 Universal Database DRDA Informix MVS MVS/ESA OS/2 OS/390 z/os Alerts is a registered trademark of Alphablox Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. Copyright IBM Corp. 2001, 2006 Trademarks v Course materials may not be reproduced in whole or in part without the prior

6 Student Exercises vi DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006 Course materials may not be reproduced in whole or in part without the prior

7 V2.0 Student Exercises pref Exercises Description Exercise 1: This exercise allows the student to begin analyzing the database performance characteristics for an application using SNAPSHOT monitoring. Exercise 2: This exercise allows the student to begin analyzing the database performance characteristics for an application. The impact of increased bufferpool size, using separate data and index DMS table spaces and implementing row compression will be measured. Exercise 3: This exercise allows the student to analyze the performance impact of implementing multiple database buffer pools. The database performance statistics will be collected to adjust the sortheap size to improve sort efficiency. Exercise 4: This exercise allows the student to configure a DB2 database to implement the Self Tuning Memory Management function to automatically adjust the database memory configuration. Exercise 5: This exercise allows the student to become familiar with the DB2 explain tools. These tools can be used to understand the processing required to execute SQL statements. Exercise 6: This exercise allows the student to use the DB2 Explain tools to better understand access plan selections of the DB2 Optimizer. Exercise 7: This exercise allows the student to analyze the performance impact of indexes to improve the efficiency of processing SQL statements. Exercise 8: This exercise allows the student to use the DB2 explain tools to better understand access strategies of the DB2 Optimizer, including use of indexes for joining tables. A Materialized Query Table (MQT), will be used to improve query performance. The use of partition elimination in access plans for range partitioned tables will be explored. Exercise 9: This exercise allows the student to use the DB2 UDB utilities to analyze and improve query performance. The DB2BATCH tool will be used to gather performance statistics. The REORG command will be used to change the sequence of rows in a table to improve query efficiency. The RUNSTATS command will be used update the DB2 Catalog statistics to provide accurate input to the DB2 Optimizer. The REORGCHK command will be used to report on index efficiency. Copyright IBM Corp. 2001, 2006 Exercises Description vii Course materials may not be reproduced in whole or in part without the prior

8 Student Exercises Exercise 10: This exercise allows the student to use the DB2 Health Center, and Activity Monitor tools to view the status of an active DB2 database. Exercise 11: This exercise allows the student to analyze the performance impact of using different application development techniques, including Static SQL and Dynamic SQL. Exercise 12: This exercise allows the student to use Event Monitors to collect performance statistics for transactions, SQL statements and application connections executing in the DB2 UDB database. The event monitoring will use files and database tables to store the monitor data. viii DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006 Course materials may not be reproduced in whole or in part without the prior

9 V Student Exercises EXempty Exercise 1. Database Performance and Monitoring What This Exercise Is About This exercise is an online lab which allows the student to begin analyzing the database performance characteristics for an application. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 GET SNAPSHOT command to collect statistics for performance analysis. Configure the DB2 Database Manager Configuration to collect detailed performance statistics. Use the DB2EXPLN utility to examine the explain information for an application that uses static SQL. Perform SQL queries using the SNAPSHOT table functions and Administrative views to collect selected database performance information. Use a db2pd command to view information about an active DB2 database. Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-1 Course materials may not be reproduced in whole or in part without the prior

10 Student Exercises Exercise Instructions Section 1 - New Application Performance Analysis Introduction: A new database TP1 was created to test a new OLTP application. The TP1 database is using the defaults for all configuration options. The application uses four tables: 1. ACCT - With information for accounts. 2. BRANCH - With information for 100 bank branches. 3. TELLER - With information for 1000 banks. 4. HISTORY - Empty table to hold transaction history data. An application MULTI was created to generate application transactions for performance testing. The tables were created in an SMS table space TP1SMS. The tables have been loaded with test data and the required indexes were created. 1. You will be using the DB2 GET SNAPSHOT command to collect performance statistics. Check the Database Manager configuration to determine if the snapshot monitor switches are on by default. Logon to your Linux workstation with a userid of inst411 and the password provided by the instructor (ibm2blue). From your Linux workstation, start a new terminal session. In the terminal session, issue the command: db2 get database manager monitor switches The output will look similar to: DBM System Monitor Information Collected 2. Switch list for db partition number 0 Buffer Pool Activity Information (BUFFERPOOL) = OFF Lock Information (LOCK) = OFF Sorting Information (SORT) = OFF SQL Statement Information (STATEMENT) = OFF Table Activity Information (TABLE) = OFF Take Timestamp Information (TIMESTAMP) = ON :04: Unit of Work Information (UOW) = OFF All of the SNAPSHOT monitor switches are off except for the TIMESTAMP option. Issue the DB2 command to have all of the snapshot monitor statistics available when the instance is started. In a terminal session, issue the commands: 1-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

11 V Student Exercises EXempty db2 update dbm cfg using DFT_MON_BUFPOOL ON DFT_MON_LOCK ON db2 update dbm cfg using DFT_MON_SORT ON DFT_MON_STMT ON db2 update dbm cfg using DFT_MON_TABLE ON DFT_MON_UOW ON db2 terminate db2stop db2start List the Database Manager monitor switches: db2 get database manager monitor switches DBM System Monitor Information Collected Switch list for db partition number 0 Buffer Pool Activity Information (BUFFERPOOL) = ON :18: Lock Information (LOCK) = ON :18: Sorting Information (SORT) = ON :18: SQL Statement Information (STATEMENT) = ON :18: Table Activity Information (TABLE) = ON :18: Take Timestamp Information (TIMESTAMP) = ON :04: Unit of Work Information (UOW) = ON :18: List the active monitor switches for the DB2 Command window session: db2 get monitor switches Monitor Recording Switches 3. Switch list for db partition number 0 Buffer Pool Activity Information (BUFFERPOOL) = ON :18: Lock Information (LOCK) = ON :18: Sorting Information (SORT) = ON :18: SQL Statement Information (STATEMENT) = ON :18: Table Activity Information (TABLE) = ON :18: Take Timestamp Information (TIMESTAMP) = ON :04: Unit of Work Information (UOW) = ON :18: Now all of the available SNAPSHOT monitor statistics are available for use in the performance analysis. Use the MULTI application to generate one minute of update transactions. The application SQLTP1ST will be used for the first test. This application updates one row in the ACCT, BRANCH, and TELLER tables and inserts one row into the HISTORY table. Use the ACTIVATE DATABASE command to make sure that the database statistics will be available for analysis. In the terminal session, issue the commands: cd $HOME/bin db2 activate database tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application and issue the following commands: Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-3

12 Student Exercises cd $HOME/bin multi tp1st.cfg To begin processing transactions, click the RUN button. Wait for 60 seconds of Elapsed Time to complete. What was the Total Count of transactions completed in 60 seconds? The system was probably only able to complete a few transactions. This is unacceptable performance for these simple transactions. The file checkapp.sql has the following query: select agent_id, rows_read, rows_written, rows_selected, rows_inserted from sysibmadm.snapappl Run the query using the following command: db2 -tvf checkapp.sql The query result should look similar to the following: AGENT_ID ROWS_READ ROWS_WRITTEN ROWS_SELECTED ROWS_INSERTED DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

13 V Student Exercises EXempty 7 record(s) selected. This shows a high number of rows read by each application, compared to the number of rows selected. This usually indicates that an index was not being used, at least for some of the SQL statements processed. Close the MULTI application now. 4. Use the DB2 GET SNAPSHOT command to collect the statistics for each table accessed since the database was activated. Save the report to a file and use the UNIX vi editor to review the data. In the terminal session, issue the commands: db2 get snapshot for tables on tp1 > sntab1.txt vi sntab1.txt Table Snapshot First database connect timestamp = 11/20/ :55: Last reset timestamp = Snapshot timestamp = 11/20/ :03: Database name = TP1 Database path = /database/inst411/node0000/sql00001/ Input database alias = TP1 Number of accessed tables = 18 Table List Table Schema = SYSIBM Table Name = SYSTABLES Table Type = Catalog Data Object Pages = 27 Index Object Pages = 16 LOB Object pages = 256 Rows Read = 31 Rows Written = 6 Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = ACCT Table Type = User Data Object Pages = Index Object Pages = 3631 Rows Read = Rows Written = 111 Overflows = 0 Page Reorgs = 0 Table Schema Table Name = SYSIBM = SYSINDEXES Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-5

14 Student Exercises Table Type = Catalog Data Object Pages = 16 Index Object Pages = 10 LOB Object pages = 1 Rows Read = 6 Rows Written = 6 Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = BRANCH Table Type = User Data Object Pages = 4 Index Object Pages = 3 Rows Read = Rows Written = 111 Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = TELLER Table Type = User Data Object Pages = 29 Index Object Pages = 7 Rows Read = Rows Written = 111 Overflows = 0 Page Reorgs = 0 Table Schema = SYSIBM Table Name = SYSINDEXCOLUSE Table Type = Catalog Data Object Pages = 7 Index Object Pages = 11 Rows Read = 3 Rows Written = 6 Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = HISTORY Table Type = User Data Object Pages = 130 Rows Read = 0 Rows Written = 111 Overflows = 0 Page Reorgs = 0 Record the number of rows read and written for each of the applications tables. Table Name Rows Read Rows Written HISTORY BRANCH 1-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

15 V Student Exercises EXempty Table Name Rows Read Rows Written TELLER ACCT The table statistics show large numbers of rows read and a small number of rows written to each table. It will be necessary to look at the application's SQL statements to understand this performance problem. The application SQLTP1ST was written using static SQL.The DB2BFD utility can be used to list the static SQL statements for the bind file SQLTP1ST.BND. Look for the SQL statements that access the ACCT table, which had a large count of rows read from the table statistics. Save the report to a file and examine the file using the UNIX vi editor. In the terminal session, issue the commands: db2bfd -s sqltp1st.bnd more The report will include the following: Line Sec Typ Var Len SQL statement text INCLUDE SQLCA BEGIN DECLARE SECTION END DECLARE SECTION DECLARE CURSOR1 CURSOR FOR SELECT BALANCE, ACC T_GRP FROM ACCT WHERE ACCT_ID = :H00001 FOR U PDATE OF BALANCE OPEN CURSOR ROLLBACK FETCH CURSOR1 INTO :H00006, :H ROLLBACK UPDATE ACCT SET BALANCE = BALANCE + :H00007 WHERE CURRENT OF CURSOR1 This shows that the SQL SELECT statement for the ACCT table is: SELECT BALANCE, ACCT_GRP FROM ACCT WHERE ACCT_ID = :H00001 FOR UPDATE OF BALANCE There is only one row for each ACCT_ID in the ACCT table. An index should be available to support this type of table access. Use the DB2 DESCRIBE command to check to see what indexes are available for the ACCT table. In the terminal session, issue the commands: db2 connect to tp1 db2 describe indexes for table acct show detail The output will be similar to the following: Index Index Unique Number of schema name rule columns Column names Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-7

16 Student Exercises INST411 ACCTINDX U 1 +ACCT_ID There is a unique index ACCTINDX on the ACCT_ID column of the account table, so the simple select should use this index. Since the application SQLTP1ST was written using static SQL, the DB2EXPLN utility can be used to list the explain information for each static SQL statement in the package. Review the db2expln report to see if the ACCTINDX index is being utilized for the SQLTP1ST application. Save the report to a file and examine the file using the UNIX vi editor. In the terminal session, issue the commands: db2expln -d tp1 -p sqltp1st -c TP1 -o exp1.txt vi exp1.txt Look for the SELECT statement that accesses the ACCT table. The db2expln output will include: Section = 1 SQL Statement: DECLARE CURSOR1 CURSOR FOR SELECT BALANCE, ACCT_GRP FROM ACCT WHERE ACCT_ID =:H00001 FOR UPDATE OF BALANCE Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.ACCT ID = 3,2 #Columns = 2 Relation Scan Prefetch: Eligible Lock Intents Table: Intent Exclusive Row : Update Sargable Predicate(s) #Predicates = 1 Return Data to Application #Columns = 2 End of section What is the Estimated Cost for running this SQL statement? Is the ACCTINDX index being used? 1-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

17 V Student Exercises EXempty 8. The table ACCT was accessed using a relational scan. This is the primary reason that the application performance is poor. The DBA that created the database and set up the application remembered that the indexes were created AFTER the BINDs were done for the applications, including SQLTP1ST. Rebind the applications now that the indexes have been created for the tables and check to see if the new package uses the existing indexes. A command file, TP1BIND contains all the necessary BIND commands. In the terminal session, issue the commands: db2 connect to tp1 First collect the current statistics: tp1stats db2 -tvf tp1bind The DB2EXPLN utility can be used to check the revised explain information for the SQLTP1ST package. Review the db2expln report to see if the ACCTINDX index is being utilized for the SQLTP1ST application. Save the report to a file and examine the file using the UNIX vi editor. Check the same SELECT statement from the ACCT table. In the terminal session, issue the commands: db2expln -d tp1 -p sqltp1st -c TP1 -o exp2.txt vi exp2.txt The db2expln output will include: Section = 1 SQL Statement: DECLARE CURSOR1 CURSOR FOR SELECT BALANCE, ACCT_GRP FROM ACCT WHERE ACCT_ID =:H00001 FOR UPDATE OF BALANCE Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.ACCT ID = 3,2 Index Scan: Name = INST411.ACCTINDX ID = 1 Regular Index (Not Clustered) Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-9

18 Student Exercises Index Columns: 1: ACCT_ID (Ascending) #Columns = 2 Single Record Fully Qualified Unique Key #Key Columns = 1 Start Key: Inclusive Value 1:? Stop Key: Inclusive Value 1:? Data Prefetch: None Index Prefetch: None Lock Intents Table: Intent Exclusive Row : Update Return Data to Application #Columns = 2 9. End of section What is the Estimated Cost for running this SQL statement? Is the ACCTINDX index being used? All of the accesses in the package SQLTP1ST are now using the available indexes. Now that the index usage problem has been resolved, another minute of MULTI transactions will be run. The database TP1 will be deactivated to clear all database statistics before the next performance test. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 Restart the MULTI application. multi tp1st.cfg To begin processing transactions, click the RUN button. Wait for 60 seconds of Elapsed Time to complete. What is the new Total Count of transactions now that the indexes can be used? Run the query checkapp.sql to get application statistics DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

19 V Student Exercises EXempty db2 connect to tp1 db2 -tvf checkapp.sql The output might look similar to the following: AGENT_ID ROWS_READ ROWS_WRITTEN ROWS_SELECTED ROWS_INSERTED record(s) selected. The number of rows read by each connection should have decreased significantly. Use the db2pd command to review agent statistics: db2pd -db tp1 -agent > db2pdagent1.txt vi db2pdagents1.txt 10. Use the DB2 GET SNAPSHOT command to collect the statistics for each table accessed since the database was activated. Save the report to a file and use the UNIX vi editor to review the data. In the terminal session, issue the commands: db2 get snapshot for tables on tp1 > sntab2.txt vi sntab2.txt Table List Table Schema = INST411 Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-11

20 Student Exercises Table Name = ACCT Table Type = User Data Object Pages = Index Object Pages = 3631 Rows Read = Rows Written = Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = BRANCH Table Type = User Data Object Pages = 4 Index Object Pages = 3 Rows Read = Rows Written = Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = TELLER Table Type = User Data Object Pages = 29 Index Object Pages = 7 Rows Read = Rows Written = Overflows = 0 Page Reorgs = 0 Table Schema = INST411 Table Name = HISTORY Table Type = User Data Object Pages = 325 Rows Read = 0 Rows Written = Overflows = 0 Page Reorgs = 0 Record the number of rows read and written for each of the applications tables. Table Name Rows Read Rows Written HISTORY BRANCH TELLER ACCT How do these statistics compare to the first MULTI results? The table statistics show much smaller numbers of rows read and a larger number of rows written to each table for the 60 seconds of testing DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

21 V Student Exercises EXempty 11. The SNAPSHOT statistics for tables can be retrieved with a SQL SELECT using the SNAPSHOT_TABLE function provided by DB2. Create a query to retrieve the table statistics from the TP1 database. The DESCRIBE statement can be used to get the column names so that the query can request specific performance elements. In the terminal session, issue the commands: db2 connect to tp1 db2 "describe select * from table(snap_get_tab_v91('tp1',-1)) as tab1" The output will look like: SQLDA Information sqldaid : SQLDA sqldabc: 896 sqln: 20 sqld: 17 Column Information sqltype sqllen sqlname.data sqlname.length TIMESTAMP 26 SNAPSHOT_TIMESTAMP VARCHAR 128 TABSCHEMA VARCHAR 128 TABNAME BIGINT 8 TAB_FILE_ID VARCHAR 14 TAB_TYPE BIGINT 8 DATA_OBJECT_PAGES BIGINT 8 INDEX_OBJECT_PAGES BIGINT 8 LOB_OBJECT_PAGES BIGINT 8 LONG_OBJECT_PAGES BIGINT 8 XDA_OBJECT_PAGES BIGINT 8 ROWS_READ BIGINT 8 ROWS_WRITTEN BIGINT 8 OVERFLOW_ACCESSES BIGINT 8 PAGE_REORGS SMALLINT 2 DBPARTITIONNUM BIGINT 8 TBSP_ID INTEGER 4 DATA_PARTITION_ID 17 Use a SQL statement to retrieve the table names, and the counts for rows read and written. db2 " select tabname, rows_read, rows_written from table(snap_get_tab_v91('tp1',-1)) as tab1 where tabschema = user " The output will look similar to this: TABNAME ROWS_READ ROWS_WRITTEN Copyright IBM Corp. 2001, 2006 Exercise 1. Database Performance and Monitoring 1-13

22 Student Exercises HISTORY BRANCH TELLER ACCT record(s) selected. 12. A new table, SNAPDATA, will be created to save database statistics throughout the lab exercises. DB2 command files are provided to create the table and insert database statistics into the table. The file crsnap.ddl contains the following: create table snapdata as ( SELECT * from sysibmadm.snapdb ) definition only in userspace1 ; The file savesnap.ddl contains the following: insert into snapdata ( SELECT * from sysibmadm.snapdb ) ; In the terminal session, issue the commands: db2 -tvf crsnap.ddl db2 -tvf savesnap.ddl Run the GET SNAPSHOT FOR DATABASE command and use the UNIX grep command to show statistics for row level access. db2 get snapshot for database on tp1 grep Rows The output will look similar to the following: Rows deleted = 0 Rows inserted = 947 Rows updated = 2841 Rows selected = 1894 Rows read = 7594 The count of Rows inserted should match the number of completed MULTI transactions. 13. Close all the applications and deactivate the TP1 database to clear all current statistics. Close the MULTI application. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE 1-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

23 V Student Exercises EXempty Exercise 2. Tablespace and I/O Performance What This Exercise Is About This exercise is an online lab which allows the student to begin analyzing the database performance characteristics for an application. The impact of increased bufferpool size, using separate data and index DMS tablespaces and implementing row compression will be measured. What You Should Be Able to Do At the end of the lab, you should be able to: Use DB2 GET SNAPSHOT commands and SQL queries to collect database statistics for analysis of database I/O performance. Implement multiple DMS table spaces to separate the data and index components. Plan and implement Row Compression to reduce I/O costs and improve buffer pool efficiency. Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-1

24 Student Exercises Database Performance Results Table DB2 Monitor Statistic Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio (Calculated) BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio (Calculated) Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available LSN Gap cleaner triggers Dirty page steal cleaner triggers Dirty page threshold cleaner triggers Rows inserted Rows updated Log Pages Written Small Buffer Pool Size Buffer Pool DMS Table Size 10,000 Spaces Compress Acct Table 2-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

25 V Student Exercises EXempty Exercise Instructions Introduction In this exercise, you will be making a series of changes to the database and tablespace configuration used by the application. The SNAPSHOT monitoring reports will be used to check the results of each change to the database configuration. In section 2 the buffer pool size will be increased to make more memory available for data and index pages from the table spaces. In section 3, the ACCT and HISTORY tables will be moved to DMS tablespaces. In the last section, Row Compression will be implemented for the ACCT table. Some of the key performance statistics that will be monitored will be: Buffer Pool Data and Index Logical Reads - These indicate the level of demand for data and index pages by the applications. Processing a larger number of transactions will increase the logical reads for index and data pages. Buffer Pool Data and Index Physical Reads - These indicate the number of disk I/Os for reading data and index pages. Increasing the buffer pool memory may reduce the number of I/Os required to process each transaction, but an increased transaction rate may also increase the total physical I/O counts. Buffer Pool Data and Index Writes and Page Cleaners - Most pages should be written asynchronously in parallel to SQL processing. The Dirty Page Steal Cleaners are synchronous writes which delay the applications. The increasing the buffer pool size should improve disk write efficiency and free the disk system to do more productive reads. Buffer Pool data and Index Hit Ratios - These hit ratios will be calculated to indicate the percentage of logical reads that were satisfied quickly from the buffer pool without a physical disk I/O. Rows Inserted and Updated - For the MULTI transactions, the best indication of improved performance will be an increase in the counts of rows inserted or updated, which is the output of the application process. Higher counts will indicate a higher transaction rate for the fixed measurement interval. Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-3

26 Student Exercises Section 1 - Buffer Pool Activity using a small buffer pool 1. You will be using the DB2 GET SNAPSHOT command to collect performance statistics. The TP1 database has been configured to minimize memory requirements using basic database and database manager configuration options. Check the size of the buffer pool, IBMDEFAULTBP. In the terminal session, issue the commands: db2 connect to tp1 db2 select bpname, npages, pagesize from syscat.bufferpools The output will look similar to: BPNAME NPAGES PAGESIZE IBMDEFAULTBP record(s) selected. The TP1 database has one buffer pool, IBMDEFAULTBP, with 250 4K pages to support the database. Run three minutes of MULTI transactions using the configuration file tp1st3.cfg and collect the database statistics using a GET SNAPSHOT for database report. Deactivate the database TP1 to clear all database statistics before the next performance test. In the terminal session, issue the commands: cd $HOME/bin db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application, and issue the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) of Elapsed Time to complete. What is the new Total Count of transactions with the small buffer pool size? 2-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

27 V Student Exercises EXempty 3. Close the MULTI application. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database with a default configuration. Save the statistics to a file and to the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb20.txt vi sndb20.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled 'Small Buffer Pool size'. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available LSN Gap cleaner triggers Dirty page steal cleaner triggers Dirty page threshold cleaner triggers Rows inserted Rows updated Log Pages Written The Hit Ratios could be calculated from the database snapshot report using these formulas: Buffer Pool Data Hit Ratio = ( 1 - (Buffer Pool Data Physical Reads / Buffer Pool Data Logical Reads ) * 100 Buffer Pool Index Hit Ratio = ( 1 - (Buffer Pool Index Physical Reads / Buffer Pool Index Logical Reads ) * 100 You could use the Windows Calculator a calculator to compute the hit ratio percentages, but a DB2 Administrative view, SYSIBMADM.BP_HITRATIO can be used to retrieve buffer pool hit ratios. The DB2 command file, snaphits.sql, contains a SELECT from the SYSIBMADM.BP_HITRATIO view to retrieve the I/O statistics for data and index pages including the logical reads, physical reads and hit ratios. In the terminal session, issue the commands: db2 connect to tp1 Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-5

28 Student Exercises cat snaphits.sql The output will look similar to: SELECT data_physical_reads, index_physical_reads, total_physical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' SELECT data_logical_reads, index_logical_reads, total_logical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' SELECT data_hit_ratio_percent, index_hit_ratio_percent, total_hit_ratio_percent, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' Run the DB2 command file, snaphits.sql, and record the results in the table at the beginning of this exercise. db2 -tf snaphits.sql The output will have the following format: DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP 4. DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT BP_NAME IBMDEFAULTBP Record the data and index hit ratios in the Database performance results table. The Administrative views SYSIBMADM.BP_READ_IO and SYSIBMADM.BP_WRITE_IO provide additional buffer pool I/O performance statistics. The command file bpioperformance.sql uses these views to show key I/O performance statistics. The SQL text is the following: select substr(bp_name,1,15) as bp_name, total_physical_reads, average_read_time_ms from sysibmadm.bp_read_io where bp_name not like 'IBMSYSTEM%' select substr(bp_name,1,15) as bp_name, total_writes, average_write_time_ms from sysibmadm.bp_write_io 2-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

29 V Student Exercises EXempty where bp_name not like 'IBMSYSTEM%' In the terminal session, issue the commands: db2 -tvf bpioperformance.sql > ioperf20.txt vi ioperf20.txt The output will look similar to the following: BP_NAME TOTAL_PHYSICAL_READS AVERAGE_READ_TIME_MS IBMDEFAULTBP BP_NAME TOTAL_WRITES AVERAGE_WRITE_TIME_MS IBMDEFAULTBP This shows the counts for buffer pool reads and writes and average read and write performance in milliseconds. Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-7

30 Student Exercises Section 2 - Buffer Pool Activity with a 10,000 Page Buffer Pool Increase the size of the buffer pool IBMDEFAULTBP to 10,000 pages. Run three minutes of MULTI transactions and collect the database statistics using GET SNAPSHOT for database. Deactivate the database TP1 to clear all database statistics before the next performance test. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 db2 alter bufferpool ibmdefaultbp size db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start the MULTI application in a second terminal session using the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) of Elapsed Time to complete. Close MULTI now. Use the GET SNAPSHOT FOR DATABASE command to collect a second set of database statistics for the TP1 database with a 10,000 page buffer pool. Save the statistics to a file and the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb21.txt vi sndb21.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled Buffer Pool Size 10,000. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio 2-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

31 V Student Exercises EXempty Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available LSN Gap cleaner triggers Dirty page steal cleaner triggers Dirty page threshold cleaner triggers Rows inserted Rows updated Log Pages Written Run the DB2 command file snaphits.sql and write the results in the table at the beginning of this exercise. In the terminal session, issue the commands: db2 connect to tp1 db2 -tf snaphits.sql The output will have the following format: DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP 3. DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT Compare the statistics for the two performance tests of the SQLTP1ST application. What were the results of increasing the buffer pool size to 10,000 pages? Was there an increase in the number of rows updated and inserted during the 180 seconds of transaction processing? Did the number of Logical Reads for Index and Data pages increase? This is an indication of the application demand for data. Did the number of Physical Reads for Index and Data pages increase? Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-9

32 Student Exercises Did the number of Data Writes increase or decrease with a larger buffer pool? What is triggering the page cleaners write activity with the 10,000 page buffer pool? Use the command file bpioperformance.sql to show key I/O performance statistics. In the terminal session, issue the commands: db2 -tvf bpioperformance.sql > ioperf21.txt vi ioperf21.txt 2-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

33 V Student Exercises EXempty Section 3 - Implement DMS Table Spaces for Larger Application Tables 1. The ACCT table with 1 million rows is the largest application table. The HISTORY table will continue to grow over time and become large. These two tables will be moved to new DMS table spaces. The ACCT table will have two DMS table spaces, one for index and one for data. The HISTORY table will be moved to an Automatic Storage table space, which has the basic characteristics of DMS a table space, but the containers will be assigned and managed automatically. This table space will be defined with a 16 KB page size, which will require a new 16 KB page size buffer pool. In order to check the prefetching that is being used for the current SMS tablespace, a simple query will scan the ACCT table in the TP1SMS table space and the database I/O statistics will be checked. From your Linux workstation, start a terminal session. In the terminal session, issue the commands: db2 connect to tp1 db2 alter bufferpool ibmdefaultbp numblockpages 1024 blocksize 8 db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 db2 select name from acct where name = 'xyz' Wait for the query to complete. There should be no rows selected but every ACCT table was scanned to process the query. The DB2 command file, snprefetch.sql, contains a SELECT from the SNAPSHOT_DATABASE table function to retrieve selected I/O statistics and calculate the number of pages per prefetch. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 cat snprefetch.sql The output will look similar to: Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-11

34 Student Exercises SELECT pool_data_p_reads as Total_Data_Reads, POOL_ASYNC_DATA_READS as Asynch_Data_Reads, POOL_ASYNC_READ_TIME from sysibmadm.snapbp where bp_name = 'IBMDEFAULTBP' ; SELECT POOL_ASYNC_DATA_READ_REQS as Data_Prefetch_Requests, decimal(pool_async_data_reads) / decimal(pool_async_data_read_reqs) AS Data_Pages_Per_Prefetch, pages_from_block_ios from sysibmadm.snapbp where bp_name = 'IBMDEFAULTBP' ; Run the command file and record the results. db2 -tf snprefetch.sql The output will look similar to the following: TOTAL_DATA_READS ASYNCH_DATA_READS POOL_ASYNC_READ_TIME record(s) selected. DATA_PREFETCH_REQUESTS DATA_PAGES_PER_PREFETCH PAGES_FROM_BLOCK_IOS ASYNCH_DATA_READS = DATA_PREFETCH_REQUESTS = DATA_PAGES_PER_PREFETCH = Check the extent size, prefetch size and automatic prefetch option for the TP1SMS table space that contains the ACCT table. In the terminal session, issue the command: db2 get snapshot for tablespaces on tp1 more The output will contain information similar to: Tablespace name = TP1SMS Tablespace ID = 3 Tablespace Type = System managed space Tablespace Content Type = All permanent data. Regular table space. Tablespace Page size (bytes) = 4096 Tablespace Extent size (pages) = 8 Automatic Prefetch size enabled = Yes Buffer pool ID currently in use = 1 Buffer pool ID next startup = 1 Using automatic storage = No 2-12 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

35 V Student Exercises EXempty File system caching = Yes Tablespace State = 0x' ' Detailed explanation: Normal Tablespace Prefetch size (pages) = 8 Total number of pages = Number of usable pages = Number of used pages = Minimum Recovery Time = Number of quiescers = 0 Number of containers = 1 2. The number of data pages read per prefetch request should match the extent size of the TP1SMS table space, which is 8 pages. Automatic Prefetch setting is enabled for this table space. The database configuration options NUM_IOSERVERS and NUM_IOCLEANERS is set to AUTOMATIC. Check the current setting for these options/ In the terminal session, issue the command: db2 get db cfg show detail grep NUM_IO Both NUM_IOSERVERS and NUM_IOCLEANERS are set to AUTOMATIC. What are the current system selected values for each of these? NUM_IOSERVERS : NUM_IOCLEANERS : Create the new table spaces and a new buffer for the table space that will contain the HISTORY table. The DB2 command file, tp1tblspace, can be used to create the new buffer pool TP1H16K, and the table spaces TP1DMSH for the HISTORY table and TP1DMSAD and TP1DMSAI for the ACCT table. In the terminal session, issue the command: db2 -tvf tp1tblspace The output will look similar to the following: CREATE Bufferpool TP1H16K IMMEDIATE SIZE 1000 PAGESIZE 16 K DB20000I The SQL command completed successfully. CREATE REGULAR TABLESPACE TP1DMSH PAGESIZE 16 K MANAGED BY AUTOMATIC STORAGE INITIALSIZE 40 M EXTENTSIZE 8 PREFETCHSIZE AUTOMATIC BUFFERPOOL TP1H16K DB20000I The SQL command completed successfully. CREATE REGULAR TABLESPACE TP1dmsad PAGESIZE 4 K MANAGED BY DATABASE USING (FILE 'tp1dms/dmsad1' 10000, FILE 'tp1dms/dmsad2' 10000, FILE 'tp1dms/dmsad3' 10000, FILE 'tp1dms/dmsad4' ) EXTENTSIZE 64 PREFETCHSIZE AUTOMATIC AUTORESIZE YES DB20000I The SQL command completed successfully. Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-13

36 Student Exercises CREATE REGULAR TABLESPACE TP1dmsai PAGESIZE 4 K MANAGED BY DATABASE USING (FILE 'tp1dms/dmsai' 20000) EXTENTSIZE 32 PREFETCHSIZE AUTOMATIC AUTORESIZE YES DB20000I The SQL command completed successfully. 3. Use the DB2 EXPORT command to save the ACCT and HISTORY table data to files. In the terminal session, issue the commands: db2 export to acct.del of del select * from acct db2 export to history.del of del select * from history The output will look similar to the following: SQL3104N The Export utility is beginning to export data to file "acct.del". SQL3105N The Export utility has finished exporting " " rows. Number of rows exported: SQL3104N The Export utility is beginning to export data to file "history.del". 4. SQL3105N The Export utility has finished exporting "23113" rows. Number of rows exported: Use the DB2 command file, tp1tabdms, to drop the existing ACCT and HISTORY tables and recreate the two tables and the index for the ACCT table in the new DMS table spaces. In the terminal session, issue the command: db2 -tvf tp1tabdms The output will look similar to the following: drop table acct DB20000I The SQL command completed successfully. drop table history DB20000I The SQL command completed successfully. CREATE TABLE ACCT (ACCT_ID INT NOT NULL, NAME CHAR(20) NOT NULL, ACCT_GRP SMALLINT NOT NULL, BALANCE DECIMAL(15,2) NOT NULL, ADDRESS CHAR(30) NOT NULL, TEMP CHAR(40) NOT NULL) IN TP1DMSAD INDEX IN TP1DMSAI 2-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

37 V Student Exercises EXempty DB20000I The SQL command completed successfully. CREATE UNIQUE INDEX ACCTINDX ON ACCT(ACCT_ID) DB20000I The SQL command completed successfully. CREATE TABLE HISTORY (ACCT_ID INTEGER NOT NULL, TELLER_ID SMALLINT NOT NULL, BRANCH_ID SMALLINT NOT NULL, BALANCE DECIMAL(15,2) NOT NULL, DELTA INTEGER NOT NULL, PI INTEGER NOT NULL, TSTMP TIMESTAMP NOT NULL WITH DEFAULT, ACCTNAME CHAR(20) NOT NULL, TEMP CHAR (6) NOT NULL) IN TP1DMSH DB20000I The SQL command completed successfully Use the DB2 LOAD command to reload the ACCT and HISTORY tables data from the export files. In the terminal session, issue the commands: db2 " load from acct.del of del messages loadacct.msg replace into acct " db2 " load from history.del of del messages loadhist.msg replace into history " The output will look similar to the following: Number of rows read = Number of rows skipped = 0 Number of rows loaded = Number of rows rejected = 0 Number of rows deleted = 0 Number of rows committed = Number of rows read = Number of rows skipped = 0 Number of rows loaded = Number of rows rejected = 0 Number of rows deleted = 0 Number of rows committed = Use the DB2 command file, tp1stats, to invoke the RUNSTATS utility for each of the four tables. Use the command file, tp1bind, to rebind the application programs that use these tables. In the terminal session, issue the command: tp1stats The output will look similar to the following: RUNSTATS ON TABLE INST411.ACCT AND INDEXES ALL Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-15

38 Student Exercises DB20000I The RUNSTATS command completed successfully. RUNSTATS ON TABLE INST411.BRANCH AND INDEXES ALL DB20000I The RUNSTATS command completed successfully. RUNSTATS ON TABLE INST411.TELLER AND INDEXES ALL DB20000I The RUNSTATS command completed successfully. RUNSTATS ON TABLE INST411.HISTORY DB20000I The RUNSTATS command completed successfully. db2 -tf tp1bind The output will look similar to the following: LINE MESSAGES FOR SQLTP1ST.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. LINE MESSAGES FOR SQLTP1DY.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. LINE MESSAGES FOR SQLTP1CP.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. LINE MESSAGES FOR SQLTP1RI.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. LINE MESSAGES FOR SQLTP1DL.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. LINE MESSAGES FOR SQLTP1DS.BND SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. DB20000I The SQL command completed successfully DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

39 V Student Exercises EXempty DB20000I The TERMINATE command completed successfully. Check the configuration options NUM_IOSERVERS and NUM_IOCLEANERS. The new tablespace, TP1DMSAD, was defined with four containers. The number of database prefetchers should have been automatically increased. In the terminal session, issue the command: db2 force application all db2 deactivate db tp1 db2 connect to tp1 db2 get db cfg show detail grep NUM_IO Run the query that scans the ACCT table and collect the database statistics using GET SNAPSHOT for database. Deactivate the database TP1 to clear all database statistics before the next performance test. In the terminal session, issue the commands: db2 alter bufferpool ibmdefaultbp numblockpages 1024 blocksize 64 db2 terminate db2 force application all db2 activate db tp1 db2 connect to tp1 db2 select name from acct where name = 'xyz' Wait for the query to complete processing. Run the command file and record the results. db2 -tvf snprefetch.sql The output will look similar to the following: TOTAL_DATA_READS ASYNCH_DATA_READS POOL_ASYNC_READ_TIME DATA_PREFETCH_REQUESTS DATA_PAGES_PER_PREFETCH PAGES_FROM_BLOCK_IOS ASYNCH_DATA_READS = DATA_PREFETCH_REQUESTS = DATA_PAGES_PER_PREFETCH = Check the extent size, prefetch size and automatic prefetch option for the TP1DMSAD table space that contains the ACCT table. In the terminal session, issue the command: Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-17

40 Student Exercises db2 get snapshot for tablespaces on tp1 more Tablespace name = TP1DMSAD Tablespace ID = 5 Tablespace Type = Database managed space Tablespace Content Type = All permanent data. Regular table space. Tablespace Page size (bytes) = 4096 Tablespace Extent size (pages) = 64 Automatic Prefetch size enabled = Yes Buffer pool ID currently in use = 1 Buffer pool ID next startup = 1 Using automatic storage = No Auto-resize enabled = Yes File system caching = Yes Tablespace State = 0x' ' Detailed explanation: Normal Tablespace Prefetch size (pages) = 256 Total number of pages = Number of usable pages = Number of used pages = Number of pending free pages = 0 Number of free pages = High water mark (pages) = Current tablespace size (bytes) = Rebalancer Mode = No Rebalancing Minimum Recovery Time = Number of quiescers = 0 Number of containers = 4 Compare these results to the statistics before the table space change. The number of data pages read from disk should be about the same, but the number of prefetch requests should have been reduced, while the average number of data pages per read prefetch request increase in extent size to 64 pages. The Automatic Prefetch size is enabled, so the prefetch size is currently 256, because there are four containers. ( 4 Containers ) * ( 64 Page extent size) = 256 Page prefetch 2-18 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

41 V Student Exercises EXempty Section 4 Run a performance test with DMS Tablespaces Now that the application's tables have be split into multiple table spaces, run three minutes of MULTI transactions and collect the database statistics using GET SNAPSHOT for database. Deactivate the database TP1 to clear all database statistics before the next performance test. In the terminal session, issue the commands: cd $HOME/bin db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application and issue the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) of Elapsed Time to complete. What is the new Total Count of transactions with the new table spaces? Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database with multiple table spaces. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb22.txt vi sndb22.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled DMS Table Spaces. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-19

42 Student Exercises Buffer Pool Index Hit Ratio Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available LSN Gap cleaner triggers Dirty page steal cleaner triggers Dirty page threshold cleaner triggers Rows inserted Log Pages Written Run the DB2 command file snaphits.sql and write the results in the table at the beginning of this exercise. In the terminal session, issue the commands: db2 connect to tp1 db2 -tf snaphits.sql The output will look similar to the following: DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP TP1H16K DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP TP1H16K DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT BP_NAME IBMDEFAULTBP TP1H16K 3. Use the command file bpioperformance.sql to show key I/O performance statistics. In the terminal session, issue the commands: db2 -tvf bpioperformance.sql > ioperf22.txt vi ioperf22.txt The TP1 database currently has two buffer pools, The buffer pool TP1H16K, was created to support the HISTORY table which has 16 KB page size. All other table spaces are supported by the buffer pool IBMDEFAULTBP which was increased to pages to improve database performance. Run the DB2 command file, snaptbsio.sql, to look at the data and index I/O counts for each table space. In the terminal session, issue the command: 2-20 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

43 V Student Exercises EXempty db2 -tvf snaptbsio.sql The output will look similar to the following: SELECT POOL_DATA_P_READS as DATA_Reads, POOL_INDEX_P_READS as INDEX_Reads, POOL_DATA_WRITES, substr(tbsp_name,1,16) as Table_space from sysibmadm.snaptbs DATA_READS INDEX_READS POOL_DATA_WRITES TABLE_SPACE SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI SYSTOOLSPACE SYSTOOLSTMPSPACE 9 record(s) selected. Most of the buffer pool reads and writes are associated with the ACCT table. Implementing row compression may reduce the I/O demand for ACCT table pages and improve buffer pool efficiency. Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-21

44 Student Exercises Section 5 Implement Row Compression for the ACCT table 1. The ACCT table is currently the largest table used by the MULTI application. Implementing Row Compression may be able to reduce the number of pages that will need to be read and written during processing and also reduce the number of buffer pool pages needed to hold the rows processed. There will be CPU overhead for compressing and uncompressing rows, but there may be adequate CPU resource available. The INSPECT command can be used to estimate the row compression results for an existing table. First, use a query to find the current table size for the ACCT table. In the terminal session, issue the commands: db2 connect to tp1 db2 select npages, fpages from syscat.tables where tabname = ACCT' and tabschema = INST411' How many pages currently have data in the ACCT table (npages)?: db2 inspect rowcompestimate table name acct schema inst411 results keep inspect1.dat db2inspf $HOME/sqllib/db2dump/inspect1.dat inspect1.txt vi inspect1.txt The output will look similar to the following: DATABASE: TP1 VERSION : SQL Action: ROWCOMPESTIMATE TABLE Schema name: INST411 Table name: ACCT Tablespace ID: 5 Object ID: 4 Result file name: inspect1.dat Table phase start (ID Signed: 4, Unsigned: 4; Tablespace ID: 5) : INST411.ACCT Data phase start. Object: 4 Tablespace: 5 Row compression estimate results: Percentage of pages saved from compression: 78 Percentage of bytes saved from compression: 78 Percentage of rows ineligible for compression due to small row size: 0 Compression dictionary size: bytes. Expansion dictionary size: bytes. Data phase end DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

45 V Student Exercises EXempty 2. Table phase end. Processing has completed This sample report shows an estimated 78% compression would be expected for the ACCT table if the COMPRESS option was set to YES. The Administrative View, SYSIBMADM.TBSP_UTILIZATION can be used to check the current disk space utilization for each tablespace. Before the ACCT table gets compressed, check the utilization for the tablespaces TP1DMSAD and TP1DMSAI. The file tablespaceutil.sql can be used to run the query. The query text is: select substr(tbsp_name,1,20) as tbsp_name, tbsp_total_size_kb as total_kb, tbsp_used_size_kb as used_kb, tbsp_free_size_kb as free_kb, tbsp_utilization_percent as percent_utilized from sysibmadm.tbsp_utilization In the terminal session, issue the commands: db2 tvf tablespaceutil.sql more The output will look similar to the following: TBSP_NAME TOTAL_KB USED_KB FREE_KB PERCENT_UTILIZED SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI record(s) selected. Note the USED_KB for the two tablespaces, TP1DMSAD : TP1DMSAI : Alter the ACCT table to set the COMPRESS option to YES. Use the REORG utility to build the compression dictionary and compress the data rows. The RUNSTATS utility needs to be used to collect new catalog statistics after the table is reorganized. In the terminal session, issue the commands: db2 alter table acct compress yes db2 reorg table inst41.acct index inst411.acctindx use tempspace1 resetdictionary db2 runstats on table inst411.acct and indexes all Run the tablespace utilization query now that the ACCTY table has been compressed. db2 tvf tablespaceutil.sql more Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-23

46 Student Exercises The output will look similar to the following: TBSP_NAME TOTAL_KB USED_KB FREE_KB PERCENT_UTILIZED SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI record(s) selected. Note the USED_KB for the two tablespaces, TP1DMSAD : TP1DMSAI : The space required for the data in TP1DMSAD should have decreased significantly. The space required for the index on the ACCT table, in the TP1DMSAI tablespace has not decreased. Row compression does not affect the size of the indexes for a table. The tablespace TP1DMSAD can now be reduced in size. In the terminal session, issue the commands: db2 alter tablespace TP1DMSAD RESIZE (all containers 3000) Run the query checkcomp.sql to show the catalog statistics for the ACCT table that provide information about compressed tables. db2 tvf checkcomp.sql The output will look similar to the following: select avgrowsize, pctpagessaved, pctrowscompressed, avgrowcompressionratio, tabname from syscat.tables where tabname = 'ACCT' AVGROWSIZE PCTPAGESSAVED PCTROWSCOMPRESSED AVGROWCOMPRESSIONRATIO TABNAME E E+000 ACCT record(s) selected. Rebind the applications following the changes for the ACCT table, using the tp1bind command file. In the terminal session, issue the commands: db2 tf tp1bind Now that Row Compression has been implemented for the ACCT table, run three minutes of MULTI transactions and collect the database statistics using GET SNAPSHOT for database. Deactivate the database TP1 to clear all database statistics before the next performance test. In the terminal session, issue the commands: cd $HOME/bin 2-24 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

47 V Student Exercises EXempty db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application and issue the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) of Elapsed Time to complete. What is the new Total Count of transactions with the new table spaces? Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database with multiple table spaces. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb23.txt vi sndb23.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled Compress ACCT table. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available LSN Gap cleaner triggers Dirty page steal cleaner triggers Dirty page threshold cleaner triggers Rows inserted Log Pages Written Copyright IBM Corp. 2001, 2006 Exercise 2. Tablespace and I/O Performance 2-25

48 Student Exercises 6. Run the DB2 command file snaphits.sql and write the results in the table at the beginning of this exercise. In the terminal session, issue the commands: db2 connect to tp1 db2 -tf snaphits.sql Use the command file bpioperformance.sql to show key I/O performance statistics. In the terminal session, issue the commands: db2 -tvf bpioperformance.sql > ioperf23.txt vi ioperf23.txt Compare the statistics for the last performance test to the previous results: Was there an increase in the number of rows updated and inserted during the 180 seconds of transaction processing? Did the number of Logical Reads for Index and Data pages increase? This is an indication of the application demand for data. Did the buffer pool hit ratios increase or decrease? (If row compression was effective the buffer pool hit ratio for data should have increased. Close all the applications and deactivate the TP1 database to clear all current statistics. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE 2-26 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

49 V Student Exercises EXempty Exercise 3. DB2 Memory Management What This Exercise Is About This exercise is an online lab which allows the student to analyze the performance impact of implementing multiple database buffer pools. The database performance statistics will be collected to adjust the sortheap size to improve sort efficiency. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 command db2mtrk to collect information about the current status of database memory heaps. Configure multiple buffer pools to improve database performance. Use db2pd command options to retrieve statistics about database memory usage. Review database and database manager snapshot statistics and use explain output adjust database sortheap size to improve sort efficiency. Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-1

50 Student Exercises Database Performance Results Table DB2 Monitor Statistic Multiple Buffer Pools Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written 3-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

51 V Student Exercises EXempty Exercise Instructions Introduction In this exercise, you will be implementing two new buffer pools. The new buffer pools will be created to separate the data and index portions of the large ACCT table. A query that performs a large sort will be analyzed to adjust the size of the sortheap for the database to avoid a sort overflow during query processing. The db2mtrk and db2pd commands will be used to collect statistics about buffer pool and database memory heap sizes. Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-3

52 Student Exercises Section 1 Examine DB2 Database Memory allocations 1. The Database shared memory heaps are allocated when the database becomes active. Activate the TP1 database and use the command db2mtrk to list the size of the database buffer pools and other memory allocations. From your Linux workstation, start a terminal session. In the terminal session, issue the commands: db2 terminate db2stop force db2start db2 activate db tp1 db2 connect to tp1 db2mtrk -d -v The output will look similar to: Tracking Memory on: 2006/11/02 at 16:53:39 Memory for database: TP1 Backup/Restore/Util Heap is of size bytes Package Cache is of size bytes Catalog Cache Heap is of size bytes Buffer Pool Heap (2) is of size bytes Buffer Pool Heap (1) is of size bytes Buffer Pool Heap (System 32k buffer pool) is of size bytes Buffer Pool Heap (System 16k buffer pool) is of size bytes Buffer Pool Heap (System 8k buffer pool) is of size bytes Buffer Pool Heap (System 4k buffer pool) is of size bytes Shared Sort Heap is of size 0 bytes Lock Manager Heap is of size bytes Database Heap is of size bytes Other Memory is of size bytes Total: bytes What does the db2mtrk report show for the size of these areas? Backup/Restore/Util Heap : (65,536) Buffer Pool Heap (1) : (42,401,792) Buffer Pool Heap (2) : (16,646,144) Shared Sort Heap : (0) Lock Manager Heap : (393,216) 3-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

53 V Student Exercises EXempty Use the query in the file ckdbcfg.sql to list the database configuration options for the utility heap size, shared sort memory and locklist size. These are retrieved from the administrative view SYSIBMADM.DBCFG. It will also show the number of pages assigned to each buffer pool, using the administrative view SYSIBMADM.SNAPBP_PART. In the terminal session, issue the command: db2 tvf ckdbcfg1.sql The output will look similar to: select substr(name,1,20) as DB_CFG_Option, substr(value,1,40) as current_value from sysibmadm.dbcfg where name in ('util_heap_sz', 'sheapthres_shr', 'locklist' ) DB_CFG_OPTION CURRENT_VALUE locklist 50 sheapthres_shr util_heap_sz record(s) selected. select substr(bp_name,1,25) as BP_name, BP_CUR_BUFFSZ as BP_Pages from sysibmadm.snapbp_part BP_NAME BP_PAGES IBMDEFAULTBP TP1H16K 1000 IBMSYSTEMBP4K 16 IBMSYSTEMBP8K 16 IBMSYSTEMBP16K 16 IBMSYSTEMBP32K 16 6 record(s) selected. What does the query result show for the size of these areas? Util_heap_sz : (9332) IBMDEFAULTPB : (10,000) TP1H16K : (1,000) Sheapthres_shr : (10,000) Lock Manager Heap : (50) The configuration options are in units of The buffer pools are the number of pages. The buffer pool IBMDEFAULTBP uses a 4K page size, while TP1H16K uses a 16K page size. Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-5

54 Student Exercises 2. Notice that both the db2mtrk report and the query show four extra buffer pools, which DB2 allocates for handling of some special cases. These are sometimes referred to as the hidden' buffer pools. The standard db2mtrk report shows the current memory usage for each memory heap. For buffer pools and the lock list, DB2 has allocated the full defined size when the database was activated. The utility heap and shared sort memory heap do not allocate much memory until it is needed for processing. Use the db2pd command to show memory usage for the active TP1 database. In the terminal session, issue the command: db2pd db tp1 mempools > mempool1.txt Look at the portion of the report that shows PhySz' and PhyUpBnd' for each memory heap. The PhySZ' is the current physical size, that is similar to the number in the db2mtrk report. The PhyUpBnd' shows the upper bound for each area based on the configured limits. The output will include information similar to the following: Memory Pools: Address MemSet PoolName Id PhySz PhyUpBnd PhyHWM 0x134B0B14 TP1 utilh x134B09B4 TP1 pckcacheh Unlimited x134B0904 TP1 xmlcacheh x134B0854 TP1 catcacheh Unlimited x134B07A4 TP1 bph Unlimited x134B06F4 TP1 bph Unlimited x134B0644 TP1 bph Unlimited x134B0594 TP1 bph Unlimited x134B04E4 TP1 bph Unlimited x134B0434 TP1 bph Unlimited x134B0384 TP1 shsorth x134B02D4 TP1 lockh x134B0224 TP1 dbh The database configuration option DATABASE_MEMORY can be used to set the overall size of database shared memory. Use the command, GET DB CFG SHOW DETAIL to display the current setting for DATABASE_MEMORY. In the terminal session, issue the commands: db2 connect to tp1 db2 get db cfg show detail grep MEMORY The output will look similar to the following: 3-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

55 V Student Exercises EXempty Size of database shared memory (4KB) (DATABASE_MEMORY) = COMPUTED(33408) This shows that the size of the overall size of database shared memory has been computed as 33,408 pages, based on the size of the other database shared memory heaps when the database was activated. Your value might be somewhat different based on the current database configuration. The database overflow area will be about 20% of the total size of database shared memory when DATABASE_MEMORY is set to COMPUTED. Use the db2pd command to look the current memory sets for the TP1 database. In the terminal session, issue the commands: db2pd db tp1 memsets The output will include information similar to the following: Memory Sets: Name Address Id Size(Kb) Key DBP Type Unrsv(Kb) Used(Kb) TP1 0x134B x App10 0x x App9 0x x App8 0x x This report shows that the TP1 database has allocated about 200MB of memory and is using about 65MB currently. The Unrsv size of 39,296KB, about 40MB is the current size of the database overflow buffer in database shared memory. Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-7

56 Student Exercises Section 2 - Implement Multiple Buffer Pools for DMS Table Spaces The application's tables were split into multiple table spaces. The small tables BRANCH and TELLER are in the table space TP1SMS. The ACCT table is using two tablespaces TP1DMSAD, for data and TP1DMSAI, for the index. The HISTORY table is using TP1DMSH, which uses its own buffer pool with 16K pages. Allocate two new buffer pools, one for the ACCT table data pages and one for the ACCT table index pages. The small tables can stay in the default buffer pool. In the terminal session, issue the commands: db2 CONNECT TO TP1 db2 ALTER BUFFERPOOL IBMDEFAULTBP NUMBLOCKPAGES 0 db2 ALTER BUFFERPOOL IBMDEFAULTBP IMMEDIATE SIZE 2000 db2 CREATE Bufferpool TP1ADATA SIZE 6000 PAGESIZE 4 K db2 CREATE Bufferpool TP1AINDX SIZE 4000 PAGESIZE 4 K db2 ALTER TABLESPACE TP1DMSAD BUFFERPOOL TP1ADATA db2 ALTER TABLESPACE TP1DMSAI BUFFERPOOL TP1AINDX The database will need to be stopped and reactivated to reset database statistics and get the new buffer pools allocated. Run three minute of MULTI transactions and collect the database statistics using a GET SNAPSHOT for database command and SQL queries. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Use db2mtrk to display database shared memory allocation with the 2 new buffer pools. In the terminal session, issue the commands: db2mtrk d -v The output will include information similar to the following: Tracking Memory on: 2006/11/20 at 10:43:17 Memory for database: TP1 Backup/Restore/Util Heap is of size bytes 3-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

57 V Student Exercises EXempty 3. Package Cache is of size bytes Catalog Cache Heap is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (2) is of size bytes Buffer Pool Heap (1) is of size bytes Buffer Pool Heap (System 32k buffer pool) is of size bytes Buffer Pool Heap (System 16k buffer pool) is of size bytes Buffer Pool Heap (System 8k buffer pool) is of size bytes Buffer Pool Heap (System 4k buffer pool) is of size bytes Shared Sort Heap is of size bytes Lock Manager Heap is of size bytes Database Heap is of size bytes Other Memory is of size bytes Total: bytes Start the MULTI application in a second terminal session using the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) seconds of Elapsed Time to complete. Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database with multiple buffer pools. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb31.txt vi sndb31.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled Multiple Buffer Pools. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-9

58 Student Exercises Log Pages Written Run the DB2 command file snaphits.sql to list the buffer pool activity for each buffer pool including the hit ratios. In the terminal session, issue the commands: db2 connect to tp1 db2 -tvf snaphits.sql The output will look similar to the following: SELECT data_physical_reads, index_physical_reads, total_physical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_logical_reads, index_logical_reads, total_logical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_hit_ratio_percent, index_hit_ratio_percent, total_hit_ratio_percent, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. Your results will likely be somewhat different from those above. In general it would be expected that the hit ratio for the small tables in the default buffer pool, IBMDEFAULTBP would be higher that the hit ratio for the buffer pools with the larger tables and indexes DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

59 V Student Exercises EXempty Run the DB2 command file bpioperformance.sql to check the I/O performance statistics for each buffer pool. In the terminal session, issue the commands: db2 connect to tp1 db2 -tvf bpioperformace.sql The output will include information similar to the following: select substr(bp_name,1,15) as bp_name, total_physical_reads, average_read_time_ms from sysibmadm.bp_read_io where bp_name not like 'IBMSYSTEM%' BP_NAME TOTAL_PHYSICAL_READS AVERAGE_READ_TIME_MS IBMDEFAULTBP TP1H16K 14 4 TP1ADATA TP1AINDX record(s) selected. select substr(bp_name,1,15) as bp_name, total_writes, average_write_time_ms from sysibmadm.bp_write_io where bp_name not like 'IBMSYSTEM%' BP_NAME TOTAL_WRITES AVERAGE_WRITE_TIME_MS IBMDEFAULTBP TP1H16K 99 4 TP1ADATA TP1AINDX 0-4 record(s) selected. Your results will likely be somewhat different from those above. These show that almost all of the disk reads are associated with the buffer pools TP1ADATA and TP1AINDX that support the ACCT table. Notice that since the ACCT table is being updated but no new rows are inserted or deleted, the indexes are only being read. The index buffer pool in the above report shows no write activity at all. New rows are being inserted into the HISTORY table, but the buffer pool is large enough to hold the changes without the need to do many writes. Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-11

60 Student Exercises Section 3 - Sort Activity and Sortheap Configuration The application SQLTP1ST does not require any sorting for its SQL processing. The TP1 database was configured with a small value for sortheap, 256 pages. A query will be run that produces a large sorted result set. Deactivate the database TP1 to clear all database statistics before the next performance test. The DBM instance will be stopped to clear its sort related statistics. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 db2stop db2start db2 connect to tp1 Run the following query using the file sortquery.sql that contains the following sql statement: select name, address from acct where acct_grp < 50 order by name Note: The large result output will be piped to the UNIX grep command to avoid saving or viewing the result. db2 tf sortquery.sql grep selected The query will run for some time. Wait for the command to end normally. Use the GET SNAPSHOT command to collect sort related statistics from the TP1 database and the DBM instance. In the terminal session, issue the commands: db2 get snapshot for database on tp1 grep -i sort The output will look similar to this: Total Private Sort heap allocated = 0 Total Shared Sort heap allocated = 0 Shared Sort heap high water mark = 256 Post threshold sorts (shared memory = 0 Total sorts = 1 Total sort time (ms) = 203 Sort overflows = 1 Active sorts = 0 db2 get snapshot for dbm grep -i sort The output will look similar to this: Private Sort heap allocated = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

61 V Student Exercises EXempty Private Sort heap high water mark = 0 Post threshold sorts = 0 Piped sorts requested = 1 Piped sorts accepted = 1 Sorting Information (SORT) = ON :54: Record the following statistics from your output: Total Sorts = Sort Overflows = Total sort time (ms) = Shared Sort heap high water mark = Piped sorts requested = Piped sorts accepted = This large result overflowed the allocated sort heap space. This overflow of sort heap will use space in the temporary table space TEMPSPACE1. Use the GET SNAPSHOT command to examine the activity in the TEMPSPACE1 table space, caused by the sorting or the result. Use Notepad In the terminal session, issue the commands: db2 get snapshot for tablespaces on tp1 > sntssort1.txt vi sntssort1.txt The report will contain a section for TEMPSPACE1 similar to this: Tablespace name = TEMPSPACE1 Tablespace name = TEMPSPACE1 Tablespace ID = 1 Tablespace Type = System managed space Tablespace Content Type = System Temporary data Tablespace Page size (bytes) = 4096 Tablespace Extent size (pages) = 32 Automatic Prefetch size enabled = Yes Buffer pool ID currently in use = 1 Buffer pool ID next startup = 1 File system caching = Yes Tablespace State = 0x' ' Detailed explanation: Normal Tablespace Prefetch size (pages) = 32 Total number of pages = 33 Number of usable pages = 33 Number of used pages = 33 Minimum Recovery Time = Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-13

62 Student Exercises Number of quiescers = 0 Number of containers = 1 Container Name = /database/db2inst1/node0000/sql00001/sqlt Container ID = 0 Container Type = Path Total Pages in Container = 33 Usable Pages in Container = 33 Stripe Set = 0 Container is accessible = Yes Buffer pool data logical reads = 0 Buffer pool data physical reads = 0 Buffer pool temporary data logical reads = 1514 Buffer pool temporary data physical reads = 38 Asynchronous pool data page reads = 0 Buffer pool data writes = 38 Asynchronous pool data page writes = 7 Buffer pool index logical reads = 0 Buffer pool index physical reads = 0 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Asynchronous pool index page reads = 0 Buffer pool index writes = 0 Asynchronous pool index page writes = 0 Total buffer pool read time (ms) = 0 Total buffer pool write time (ms) = 0 Total elapsed asynchronous read time = 0 Total elapsed asynchronous write time = 0 Asynchronous data read requests = 4 Asynchronous index read requests = 0 No victim buffers available = 586 Direct reads = 0 Direct writes = 0 Direct read requests = 0 Direct write requests = 0 Direct reads elapsed time (ms) = 0 Direct write elapsed time (ms) = 0 Number of files closed = 0 Data pages copied to extended storage = 0 Index pages copied to extended storage = 0 Data pages copied from extended storage = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

63 V Student Exercises EXempty Index pages copied from extended storage = 0 4. Record the statistics for the following: Buffer pool temporary data logical reads = Buffer pool temporary data physical reads = Asynchronous pool data page reads = Buffer pool data writes = Asynchronous pool data page writes = Note: The increased buffer pool for the TP1 database should have been able to process the sort function without any physical reads or writes to disk. Use the explain tool db2expln to estimate the size of the sort heap needed for the SQL statement in the file sortheap.sql. In the terminate session, issue the command db2expln d tp1 f sortquery.sql g z \; -o expsort.txt vi expsort.txt The output will look similar to this: Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.ACCT ID = 5,4 #Columns = 2 Compressed Table Relation Scan Prefetch: Eligible Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 1 Insert Into Sorted Temp Table ID = t1 #Columns = 2 #Sort Key Columns = 1 Key 1: NAME (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 56 Piped Sorted Temp Table Completion ID = t1 Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-15

64 Student Exercises Access Temp Table ID = t1 #Columns = 2 Relation Scan Prefetch: Eligible Sargable Predicate(s) Return Data to Application #Columns = 2 Return Data Completion The explain report shows that an estimated 49,958 rows will be sorted, each with 56 bytes of data. The current sortheap is defined as 256 pages A larger sortheap should be able to sort this amount of information without an overflow to a temporary table. Increase the database configuration option sortheap to 2,500 or 10 MB. Run the same query and collect the performance statistics again. Deactivate the TP1 database to clear all database statistics before the next performance test. The DBM instance will be stopped to clear its sort related statistics. In the terminal session, issue the commands: db2 update db cfg for tp1 using sortheap 2500 db2 terminate db2 force application all db2stop db2start db2 connect to tp1 Run the query in the file sortquery.sql Note: The large result output will be piped to the UNIX grep command to avoid saving or viewing the result. db2 tf sortquery.sql grep selected The query will run for some time. Wait for the command to end normally. Use the GET SNAPSHOT command to collect sort related statistics from the TP1 database and the DBM instance. In the terminal session, issue the commands: db2 get snapshot for database on tp1 grep -i sort The output will look similar to this: The output will look similar to this: Total Private Sort heap allocated = 0 Total Shared Sort heap allocated = 0 Shared Sort heap high water mark = 2247 Post threshold sorts (shared memory = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

65 V Student Exercises EXempty Total sorts = 1 Total sort time (ms) = 137 Sort overflows = 0 Active sorts = 0 db2 get snapshot for dbm find -i sort The output will look similar to this: Private Sort heap allocated = 0 Private Sort heap high water mark = 0 Post threshold sorts = 0 Piped sorts requested = 1 Piped sorts accepted = 1 Sorting Information (SORT) = ON :54: Record the following statistics from your output: Total Sorts = Sort Overflows = Total sort time (ms) = Shared Sort heap high water mark = Piped sorts requested = Piped sorts accepted = The increased sort heap should have been able to perform the sort without overflowing to temporary table space. Use the DB2 Administrative view, SYSIBMADM.SNAPDB_MEMORY to show database shared memory statistics. The file, dbmemory.sql can be used to produce the necessary report. In the terminal session, issue the commands: db2 -tvf dbmemory.sql The output will look similar to this: select pool_id, pool_secondary_id, pool_cur_size as curent_size, pool_watermark as high_watermark from sysibmadm.snapdb_memory_pool where pool_secondary_id not like 'System%' or pool_secondary_id is null order by pool_id,pool_secondary_id POOL_ID POOL_SECONDARY_ID CURENT_SIZE HIGH_WATERMARK BP BP BP BP CAT_CACHE DATABASE Copyright IBM Corp. 2001, 2006 Exercise 3. DB2 Memory Management 3-17

66 Student Exercises LOCK_MGR OTHER PACKAGE_CACHE SHARED_SORT UTILITY record(s) selected. 7. Close the connection now. In the terminal session, issue the commands: db2 terminate END OF EXERCISE 3-18 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

67 V Student Exercises EXempty Exercise 4. DB2 Automated Memory Management What This Exercise Is About This exercise is an online lab which allows the student to configure a DB2 database to implement the Self Tuning Memory Management function to automatically adjust the database memory configuration. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 command db2mtrk to collect information about the current status of database memory heaps that are being managed by STMM. Configure a database for Self Tuning Memory. Use db2pd command options to retrieve statistics about database memory usage. Review the changes made by STMM from messages in the db2diag.log file. Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-1

68 Student Exercises Database Performance Results Table DB2 Monitor Statistic Buffer Pool Data Logical Reads System Tuned Memory Pools Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written 4-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

69 V Student Exercises EXempty Exercise Instructions Introduction In this exercise, you will be configuring the TP1 database for self tuning memory. The MULTI applications will run for 30 minutes, to allow the STMM function to adjust the database buffer pools and memory heaps for the applications. Note: The first section of the lab should be run immediately following the previous exercise.this allows the 30 minutes of automated processing to overlap with the lecture time for the automatic memory management unit. A new set of performance tests will be run to check the transaction performance after the memory has been tuned by STMM. The db2mtrk and db2pd commands will be used to collect statistics about buffer pool and database memory heap sizes. Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-3

70 Student Exercises Section 1 Examine DB2 Database Memory allocations 1. Configure the TP1 database with minimal memory allocations for the buffer pools and activate self tuning memory management. Use db2mtrk to save the initial memory usage statistics. The overall size of database shared memory, DATABASE_MEMORY, will be set to pages. This will allow STMM sufficient memory to try various memory configurations during the tests. These configuration changes will be made before STMM is activated: Utility Heap util_heap_sz : 2000 Shared Sort Memory sheapthres_shr : 8000 AUTOMATIC Sort Heap sortheap : 2000 AUTOMATIC Log File Size logfilsiz : 2000 Secondary Logs logsecond : 30 Database Shared Memory database_memory : From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME/bin db2 terminate db2stop force db2start db2 connect to tp1 db2 alter bufferpool ibmdefaulbp size 1000 automatic db2 alter bufferpool tp1adata size 1000 automatic db2 alter bufferpool tp1aindx size 1000 automatic db2 update db cfg using util_heap_sz 2000 db2 update db cfg using logsecond 30 logfilsiz 2000 db2 update db cfg using sheapthres_shr 8000 automatic db2 update db cfg using sortheap 2000 automatic db2 update db cfg using database_memory db2 terminate db2 connect to tp1 Check the current memory configuration using db2mtrk. db2mtrk d v tee lab4mtrk1.txt The output will look similar to: 4-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

71 V Student Exercises EXempty Tracking Memory on: 2006/11/02 at 16:53:39 Tracking Memory on: 2006/11/21 at 07:28:47 Memory for database: TP1 Backup/Restore/Util Heap is of size bytes Package Cache is of size bytes Catalog Cache Heap is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (2) is of size bytes Buffer Pool Heap (1) is of size bytes Buffer Pool Heap (System 32k buffer pool) is of size bytes Buffer Pool Heap (System 16k buffer pool) is of size bytes Buffer Pool Heap (System 8k buffer pool) is of size bytes Buffer Pool Heap (System 4k buffer pool) is of size bytes Shared Sort Heap is of size bytes Lock Manager Heap is of size bytes Database Heap is of size bytes Other Memory is of size bytes Total: bytes Use db2pd to examine the memory sets. db2pd db tp1 memsets tee lab4mset1.txt The output will look similar to: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:04:11 Memory Sets: Name Address Id Size(Kb) Key DBP Type Unrsv(Kb) Used(Kb) TP1 0x134B x App23 0x x App22 0x x App21 0x x App20 0xB74BE x The total size of database memory for the TP1 database is 240,128 KB. The current configuration is using 36,928 KB. STMM will be activated and allowed to reconfigure the memory heaps and buffer pools to run the applications more efficiently. In the terminal session, issue the command: db2 update db cfg using self_tuning_mem on Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-5

72 Student Exercises 2. Now activate the TP1 database to allow self tuning memory to begin making memory adjustments for an application workload. In the terminal session, issue the command: db2 terminate db2 activate db tp1 db2 connect to tp1 Run the db2mtrk command with the options to collect database memory statistics every 3 minutes for the next 36 minutes. db2mtrk d v r > lab4mtrk2.txt Start the MULTI application in a second terminal session using a configuration, tp1stmm.cfg, that will run a mixture of applications for a 30 minute test. Enter the following commands: In the terminal session, issue the command: cd $HOME/bin multi tp1stmm.cfg To begin processing transactions, click the RUN button. This will run for 30 minutes, while you are learning about STMM in a lecture. Relax, STMM will take care of the database memory. 4-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

73 V Student Exercises EXempty Section 2 Review the memory changes implemented by STMM for the MULTI applications The db2mtrk command issued in the previous step saved the database memory statistics every 3 minutes while the STMM function was tuning the database memory. Review the information in the file lab4mtrk2.txt. In the terminal session, issue the commands: To check for changes in the buffer pool TP1ADATA, look for the size of Buffer Pool Heap (3)'. Use grep to look for changes to this buffer pool. cat lab4mtrk2.txt grep Pool Heap (3)' The output will look similar to: Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Buffer Pool Heap (3) is of size bytes Now check for changes in the buffer pool TP1AINDX, look for the size of Buffer Pool Heap (4)'. Use grep to look for changes to this buffer pool. cat lab4mtrk2.txt grep Pool Heap (4)' The output will look similar to: Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Buffer Pool Heap (4) is of size bytes Use the db2pd command to check the memory sets for the TP1 database. Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-7

74 Student Exercises In the terminal session, issue the commands: db2pd db tp1 memsets tee lab4mset2.txt The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 01:31:21 Memory Sets: Name Address Id Size(Kb) Key DBP Type Unrsv(Kb) Used(Kb) TP1 0x134B x App41 0x x App40 0x x App39 0x x In the example shown, STMM has increased the Used memory for the TP1 database to 122,752K over the 30 minutes of testing. Use a query, in the file dbmemory.sql to show current memory heap sizes. In the terminal session, issue the commands: db2 tvf dbmemory.sql > lab4dbmem2.txt The output will include information similar to the following: select pool_id, pool_secondary_id, pool_cur_size as curent_size, pool_watermark as high_watermark from sysibmadm.snapdb_memory_pool where pool_secondary_id not like 'System%' or pool_secondary_id is null order by pool_id,pool_secondary_id POOL_ID POOL_SECONDARY_ID CURENT_SIZE HIGH_WATERMARK BP BP BP BP CAT_CACHE DATABASE LOCK_MGR OTHER PACKAGE_CACHE SHARED_SORT UTILITY record(s) selected. Use the vi editor to examine the list of db2mtrk reports in the file lab4mtrk2.txt. Record the memory size of each are from the first and last reports. In the terminal session, issue the commands: vi lab4mtrk2.txt 4-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

75 V Student Exercises EXempty Memory Heap Description Backup/Restore/Util Heap Package Cache Catalog Cache Heap Buffer Pool Heap (4) Buffer Pool Heap (3) Buffer Pool Heap (2) Buffer Pool Heap (1) Shared Sort Heap Lock Manager Heap 4. Use the db2diag command to locate the informational messages in the db2diag.log file that were generated by the memory changes made by STMM. In the terminal session, issue the commands: db2diag -gi message:=automatic Size in First db2mtrk report The output will include information similar to the following: Size in Last db2mtrk Report I1803G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "1000" <automatic> To: "1512" <automatic> I2259G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "1512" <automatic> To: "2280" <automatic> I3159G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "2280" <automatic> To: "3432" <automatic> I4059G455 LEVEL: Info Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-9

76 Student Exercises PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "3432" <automatic> To: "4872" <automatic> I4959G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "4872" <automatic> To: "5938" <automatic> I5859G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "5938" <automatic> To: "6780" <automatic> I6759G455 LEVEL: Info PID : 3687 TID : PROC : db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "6780" <automatic> To: "7516" <automatic> I7659G455 LEVEL: Info PID : 3687 TID : PROC :b db2stmm (TP1) 0 INSTANCE: inst411 NODE : 000 DB : TP1 APPHDL : 0-8 APPID: *LOCAL.inst AUTHID : INST411 FUNCTION: DB2 UDB, buffer pool services, sqlbalterbufferpoolact, probe:90 MESSAGE : Altering bufferpool "TP1ADATA" From: "7516" <automatic> To: "8092" <automatic> 4-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

77 V Student Exercises EXempty Section 3 Collect performance statistics with the new memory Configuration The database will need to be stopped and reactivated to reset database statistics. Run three minute of MULTI transactions and collect the database statistics using a GET SNAPSHOT for database command and SQL queries. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start the MULTI application in a second terminal session using the following commands: cd $HOME/bin multi tp1st3.cfg To begin processing transactions, click the RUN button. Wait for 3 minutes (180 seconds) seconds of Elapsed Time to complete. Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database with multiple buffer pools. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndb41.txt vi sndb41.txt Record the following statistics in the table at the beginning of this lab exercise in the column labeled System Tuned Memory Pools. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-11

78 Student Exercises Run the DB2 command file snaphits.sql to list the buffer pool activity for each buffer pool including the hit ratios. In the terminal session, issue the commands: db2 connect to tp1 db2 -tvf snaphits.sql The output will look similar to the following: SELECT data_physical_reads, index_physical_reads, total_physical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_logical_reads, index_logical_reads, total_logical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_hit_ratio_percent, index_hit_ratio_percent, total_hit_ratio_percent, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. Your results will likely be somewhat different from those above. Run the DB2 command file bpioperformance.sql to check the I/O performance statistics for each buffer pool. In the terminal session, issue the commands: db2 connect to tp DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

79 V Student Exercises EXempty db2 -tvf bpioperformace.sql The output will include information similar to the following: select substr(bp_name,1,15) as bp_name, total_physical_reads, average_read_time_ms from sysibmadm.bp_read_io where bp_name not like 'IBMSYSTEM%' BP_NAME TOTAL_PHYSICAL_READS AVERAGE_READ_TIME_MS IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX record(s) selected. select substr(bp_name,1,15) as bp_name, total_writes, average_write_time_ms from sysibmadm.bp_write_io where bp_name not like 'IBMSYSTEM%' BP_NAME TOTAL_WRITES AVERAGE_WRITE_TIME_MS IBMDEFAULTBP 33 3 TP1H16K 65 7 TP1ADATA TP1AINDX 0-4 record(s) selected. 3. Your results will likely be somewhat different from those above. These show that the HISTORY, TELLER and BRANCH tables are processed mostly in the buffer pools. Once the ACCT table data and index pages are brought into the buffer pool, most reads are handled from the buffer pool. Some writes are being done for the data pages of the ACCT table. Compare the last performance results with the statistics from the performance tests from lab 3. Was there an increase in the number of rows inserted during the 180 seconds of transaction processing? Did the number of Logical Reads for Index and Data pages increase? This is an indication of the application demand for data. Did the number of Physical Reads for Index and Data pages increase? Did the number of Data Writes increase or decrease? Copyright IBM Corp. 2001, 2006 Exercise 4. DB2 Automated Memory Management 4-13

80 Student Exercises 4. Turn off the Self Tuning Memory and deactivate the TP1 database. In the terminal session, issue the commands: db2 update db cfg using self_tuning_mem off db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE 4-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

81 V Student Exercises EXempty Exercise 5. DB2 Explain Tools What This Exercise Is About This exercise is an online lab which allows the student to become familiar with the DB2 explain tools. These tools can be used to understand the processing required to execute SQL statements. What You Should Be Able to Do At the end of the lab, you should be able to: Use the Visual Explain tool from within the DB2 Control Center. Invoke the Visual Explain tool to analyze a dynamic SQL statement using the Command Editor. Utilize the db2exfmt tool to create a report containing the information stored in the explain tables during a bind for static SQL. Use db2exfmt to create a report for a dynamic SQL statement using the command line processor. Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-1

82 Student Exercises Exercise Instructions Introduction In this exercise, you will be using DB2 Explain tools to review the detailed information used by the DB2 Optimizer to determine the least costly method for running SQL statements. First, the db2exfmt tool will be used to analyze the simple SELECT from the ACCT table contained in the SQLTP1ST application. The db2exfmt tool will next be used to show the explain information for a SELECT that performs a full table scan and requires a sort to be performed. The Control Center will then be used to invoke the graphical Visual Explain tool to look at the same table scan query. Next the Command Editor will be used to see the Visual Explain information for a query that joins two tables and uses indexes to access the tables. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown. 5-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

83 V Student Exercises EXempty Section 1 - Use db2exfmt to Format Explain Table Data from Static SQL 1. To prepare the TP1 database for beginning to explain SQL statements some setup steps will be performed. The command file lab5config.ddl will be used to set the database and tablespace configuration options. The file explain.ddl will be run to create the explain tables that are needed to use Visual Explain and the db2exfmt explain tool. A saved copy of the HISTORY table, with 200,000 rows will be loaded. New table and index statistics need to be collected. From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 db2 tvf lab5config.ddl The output will look similar to the following: update db cfg using self_tuning_mem off DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. alter bufferpool ibmdefaultbp size 2000 DB20000I The SQL command completed successfully. alter bufferpool tp1adata size 7000 DB20000I The SQL command completed successfully. alter bufferpool tp1aindx size 6000 DB20000I The SQL command completed successfully. update db cfg using sheapthres_shr 7500 sortheap 2500 DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. update db cfg using database_memory DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. SQL1363W One or more of the parameters submitted for immediate modification were not changed dynamically. For these configuration parameters, all applications must disconnect from this database before the changes become effective. update db cfg using logsecond 30 logfilsiz 2000 softmax 100 DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-3

84 Student Exercises SQL1363W One or more of the parameters submitted for immediate modification were not changed dynamically. For these configuration parameters, all applications must disconnect from this database before the changes become effective. alter tablespace tp1dmsad overhead transferrate.18 DB20000I The SQL command completed successfully. alter tablespace tp1dmsai overhead transferrate.18 DB20000I The SQL command completed successfully. alter tablespace tp1dmsh overhead transferrate.18 DB20000I The SQL command completed successfully. 2. alter tablespace tp1sms overhead transferrate.18 DB20000I The SQL command completed successfully. db2 tvf explain.ddl db2 load from hist200k.ixf of ixf replace into history A new index will be added to the HISTORY table on the branch_id column using the file crhistix.ddl. db2 tvf crhistix.ddl tp1stats The application SQLTP1ST was written using static SQL. The explain information for applications that use static SQL can be generated as part of the BIND command processing. Bind the application SQLTP1ST with the EXPLAIN and EXPLSNAP options to save the explain data for analysis. Use the utility db2exfmt to format the explain data for the first SQL statement in the SQLTP1ST application and save the output to a file. In the terminal session, issue the commands: db2 connect to tp1 db2 bind sqltp1st.bnd explain yes explsnap yes db2exfmt -1 -d tp1 -n SQLTP1ST -# 1 -o exptp1.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DATABASE 2 Explain Table Format Tool Connecting to the Database. Connect to Database Successful. Output is in exptp1.txt. 5-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

85 V Student Exercises EXempty 3. Executing Connect Reset -- Connect Reset was Successful. Use the UNIX vi editor to review the explain data saved in the file exptp1.txt. vi exptp1.txt Locate the Database Context section. The output will look similar to: Database Context: Parallelism: None e-07 CPU Speed: Comm Speed: 100 Buffer Pool size: Sort Heap size: 2500 Database Heap size: 2392 Lock List size: 50 Maximum Lock List: 60 Average Applications: 1 Locks Available: 2550 The Database Context section has information about the configuration of the TP1 database at the time the explain data was saved. For example, the Buffer Pool size is 16000, the total number of pages in all four buffer pools. This also shows that there is space available for 2550 locks without exceeding the maximum number of locks configured per connection. Locate the Original Statement section which shows the SQL SELECT statement from the ACCT table. The output will look similar to: Original Statement: DECLARE CURSOR1 CURSOR FOR SELECT BALANCE, ACCT_GRP FROM ACCT WHERE ACCT_ID = :H00001 FOR UPDATE OF BALANCE Locate the Access Plan section which shows a graph of the processing for the SQL SELECT statement from the ACCT table. The output will look similar to: Access Plan: Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-5

86 Student Exercises Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O 1 FETCH ( 2) / \ 1 1e+06 IXSCAN TABLE: INST411 ( 3) ACCT e+06 INDEX: INST411 ACCTINDX The Access Plan section graph contains three processing steps including: Step 1) RETURN - Returns the result to the application. Step 2) FETCH - Is the access for the ACCT table. Step 3) IXSCAN - Is the access to the ACCTINDX index. In this format, Step 1 is the final result, not the first processing step. The input to Step 1 is produced by Step 2, the FETCH operation. The input to Step 2 is produced by Step 3, the Index Scan operation. The estimated Total Cost of running this SQL statement is shown above as timerons. The cost in your report may vary due to differences in the system being used for the labs. Locate the detailed information about Step 1, returning the result. The output will look similar to: 1) RETURN: (Return Result) Cumulative Total Cost: Cumulative CPU Cost: Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

87 V Student Exercises EXempty Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Arguments: BLDLEVEL: (Build level) DB2 v : s STMTHEAP: (Statement heap size) 2048 Input Streams: ) From Operator #2 Estimated number of rows: 1 Number of columns: 4 Subquery predicate ID: Not Applicable Column Names: Q2.$C2+Q2.$C3+Q2.ACCT_GRP+Q2.BALANCE The RETURN operation section shows estimates for the work required to complete the SQL statement. Look at the following information: Cumulative CPU Cost: Cumulative I/O Cost: Estimated Bufferpool Buffers: Estimated number of rows: 1 This shows the estimated total CPU and I/O cost to produce the one row of output. The Estimated Bufferpool Buffers in the example is , meaning the processing might use 4 or 5 buffer pool pages for Index and Data pages. The Cumulative I/O Cost of in the example shows that the expected number of I/Os is one less than the number of buffers. The optimizer is expecting one of the pages to be accessed without a disk I/O. The numbers in your report will likely show a slightly different estimate. Locate the detailed information about Step 2, the FETCH operation. The output will look similar to: 2)FETCH : (Fetch) Cumulative Total Cost: Cumulative CPU Cost: Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-7

88 Student Exercises Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Arguments: MAXPAGES: (Maximum pages for prefetch) 1 PREFETCH: (Type of Prefetch) NONE ROWLOCK : (Row Lock intent) UPDATE TABLOCK : (Table Lock intent) INTENT EXCLUSIVE TBISOLVL: (Table access Isolation Level) CURSOR STABILITY Input Streams: ) From Operator #3 Estimated number of rows: 1 Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q1.$RID$ 3) From Object INST411.ACCT Estimated number of rows: 1e+06 Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q1.ACCT_GRP+Q1.BALANCE Output Streams: 5-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

89 V Student Exercises EXempty ) To Operator #1 Estimated number of rows: 1 Number of columns: 4 Subquery predicate ID: Not Applicable Column Names: Q2.$C2+Q2.$C3+Q2.ACCT_GRP+Q2.BALANCE Look at the Input Streams for the FETCH operation. This states that one row of input is expected from Step 3 - IXSCAN, which is the RID, the row pointer stored in the Index. The ACCT table is the second input to the FETCH operation. The type of locking that will be performed is also shown here. The PREFETCH indicates NONE, which means the pages will be read with synchronous I/O rather than being prefetched asynchronously by DB2's I/O servers. The cumulative I/O costs are the same as the total, so all of the I/O activity will be completed during the FETCH operation. Locate the detailed information about Step 3, the IXSCAN operation. The output will look similar to: 3) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: Cumulative I/O Cost: 2 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: 3 Arguments: MAXPAGES: (Maximum pages for prefetch) 1 PREFETCH: (Type of Prefetch) NONE ROWLOCK : (Row Lock intent) UPDATE SCANDIR : (Scan Direction) FORWARD TABLOCK : (Table Lock intent) INTENT EXCLUSIVE Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-9

90 Student Exercises Predicates: ) Start Key Predicate Comparison Operator: Equal (=) Subquery Input Required: No Filter Factor: 1e-06 Predicate Text: (Q1.ACCT_ID = :H00001) 2) Stop Key Predicate Comparison Operator: Equal (=) Subquery Input Required: No Filter Factor: 1e-06 Predicate Text: (Q1.ACCT_ID = :H00001) Input Streams: ) From Object INST411.ACCTINDX Estimated number of rows: 1e+06 Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q1.$RID$+Q1.ACCT_ID Output Streams: ) To Operator #2 Estimated number of rows: 1 Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q1.$RID$ 5-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

91 V Student Exercises EXempty Look at the Input Streams for the IXSCAN operation. This states that the ACCTINDX index will be accessed. The Predicates show that the start and stop key predicates are the same and will be equal to the host variable H00001 from the application. The PREFETCH indicates NONE which means the pages will be read with synchronous I/O rather than being prefetched asynchronously by DB2's I/O servers. The cumulative I/O cost is two Disk I/Os for three buffers. Since these counts are cumulative, the I/O counts for each operation can be calculated by subtracting the counts from the previous step. Step # Operation Cumulative I/O Cost Estimated Buffer Pool Buffers I/O Cost for This Step Buffer Pool Buffers for this Step 3 IXSCAN FETCH RETURN This shows that the query processing is estimated to perform two physical disk reads for three index pages. The average I/O cost for the FETCH is in the example, which indicates that either one or two data pages will be read. Why would the optimizer expect the access for one data row involve one or two data pages? The answer can be found in the statistics for the objects. Locate the section Objects Used in Access Plan to see detailed information about the ACCT table and the ACCTINDX. These are the statistics from the DB2 Catalog tables at the time that the explain was performed. The output will look similar to: Objects Used in Access Plan: Schema: INST411 Name: ACCTINDX Type: Index Time of creation: Last statistics update: Number of columns: 1 Number of rows: Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-11

92 Student Exercises Width of rows: -1 Number of buffer pool pages: 9479 Distinct row values: Yes Tablespace name: TP1DMSAI Tablespace overhead: Tablespace transfer rate: Source for statistics: Single Node Prefetch page count: 32 Container extent page count: 32 Index clustering statistic: Index leaf pages: 3611 Index tree levels: 3 Index full key cardinality: Index first key cardinality: Index first 2 keys cardinality: -1 Index first 3 keys cardinality: -1 Index first 4 keys cardinality: -1 Index sequential pages: 3610 Index page density: 99 Index avg sequential pages: 3610 Index avg gap between sequences:0 Index avg random pages: 0 Fetch avg sequential pages: -1 Fetch avg gap between sequences:-1 Fetch avg random pages: -1 Index RID count: Index deleted RID count: 0 Index empty leaf pages: 0 Base Table Schema: INST411 Base Table Name: ACCT Columns in index: ACCT_ID Schema: INST411 Name: ACCT Type: Table Time of creation: Last statistics update: Number of columns: 6 Number of rows: Width of rows: 30 Number of buffer pool pages: 9479 Number of data partitions: 1 Distinct row values: No 5-12 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

93 V Student Exercises EXempty Tablespace name: TP1DMSAD Tablespace overhead: Tablespace transfer rate: Source for statistics: Single Node Prefetch page count: 256 Container extent page count: 64 Table overflow record count: Table Active Blocks: -1 Average Row Compression Ratio: Percentage Rows Compressed: 100 Average Compressed Row Size: 33 The information about the objects accessed can be used to better understand the costs of the query processing. Note the following information: From the ACCTINDX index object: Tablespace overhead: ( ) Tablespace transfer rate: ( ) Index leaf pages: (3611) Index tree levels: (3) From the ACCT table object: Number of rows: ( ) Number of buffer pool pages: (9479) (*) Tablespace overhead: ( ) Tablespace transfer rate: ( ) Table Overflow Record count (281899) (*) (*) Your values will likely be different for these. To calculate the cost of performing one physical Disk I/O for a 4 KB page, add the Table space overhead to the Tablespace transfer rate. In the example above, this would be = The Cumulative I/O cost, in this example would account for the majority of the Cumulative Total Cost for the query. The Index tree levels of 3, accounts for the three Buffer Pool buffers required for the IXSCAN operation. The DB2 optimizer estimated that the page containing the highest level of index would already be in the buffer pool, so only two disk I/Os were included in the I/O cost of the index scan. The optimizer used the table statistics to estimate the I/O cost for the ACCT table. One very important catalog statistic was the Total Overflow Record Count', 281,899 in the example. Since Row Compression was implemented for the ACCT table, the updates performed by the MULTI transactions are causing rows to be recompressed. Since no free space is defined for this table, PCTFREE, changes in row length are causing many rows to be moved to new pages, leaving overflow Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-13

94 Student Exercises 4. record pointers in the original page. That is why the optimizer is expecting some percentage of the data rows to require two pages to be read from disk. This accounts for the I/O cost for the FETCH being What should be done to improve the efficiency of the updates to the compressed rows in the ACCT table? The ACCT table should be altered to implement some free space on each data page using the PCTFREE option. This would allow the updates to expand rows when needed without creating overflow records. A table reorganization will be needed to rebuild the table with page free space. A new compression dictionary should also be created to reflect the current data. Alter the ACCT table to add 15% free space per page. Use the REORG utility to implement the free space and also to rebuild the compression dictionary. Update the statistics for the ACCT table using the RUNSTATS utility. In the terminal session, issue the commands: db2 connect to tp1 db2 alter table acct pctfree 15 db2 reorg table acct index acctindx use tempspace1 resetdictionary db2 runstats on table inst411.acct and indexes all db2 terminate 5-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

95 V Student Exercises EXempty Section 2 - Use db2exfmt to Format Explain Table Data from Dynamic SQL 1. Use the SET CURRENT EXPLAIN statement to generate the explain table information from a dynamic SQL statement without actually running the query and producing a result. The DB2 utility db2exfmt will be used to format the explain data into a report. The SQL query used will be the following: ' select name, address from acct where acct_grp < 50 order by name' This will require a table scan and a sort operation to produce the result set. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 db2 set current explain mode explain db2 set current explain snapshot explain Run the query. db2 ' select name, address from acct where acct_grp < 50 order by name' The following message will be displayed: SQL0217W The statement was not executed as only Explain information requests are being processed. SQLSTATE=01604 Format the explain table data for the last statement into a report. db2exfmt -1 -d tp1 -o exptp2.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DATABASE 2 Explain Table Format Tool Connecting to the Database. Connect to Database Successful. Output is in exptp2.txt. the UNIX vi editor to view the explain report. vi exptp2.txt Locate the Database Context section. The output will look similar to: Database Context: Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-15

96 Student Exercises Parallelism: None CPU Speed: e-007 Comm Speed: 100 Buffer Pool size: Sort Heap size: 2500 Database Heap size: 2392 Lock List size: 50 Maximum Lock List: 60 Average Applications: 1 Locks Available: 2550 This shows that the TP1 database is configured with a Sort Heap size of 2500, which is 10 MB. Locate the Access Plan section which shows a graph of the processing for the SQL SELECT statement from the ACCT table. The output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) SORT ( 3) TBSCAN ( 4) DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

97 V Student Exercises EXempty e+06 TABLE: INST411 ACCT The section Access Plan graph contains four processing steps including: Step 1) RETURN - returns the result to the application. Step 2) TBSCAN - is the scan of the sorted result set. Step 3) SORT - is the sorting of the result set. Step 4) TBSCAN - is the scan of the ACCT table to retrieve the result set. Each step in the graph shows the row count, the cumulative total cost and I/O counts. What is the Total Cost for this query from the access plan? (14440) What is the Cost shown for Step 4, the TBSCAN? (14403) This shows that the DB2 optimizer estimates almost all of the cost of running this query to be associated with the first step, scanning the ACCT table. The SORT operation is not adding much additional cost for the query. Locate the section for Step 3, the SORT operation. The output will look similar to: 3) SORT : (Sort) Cumulative Total Cost: Cumulative CPU Cost: e+09 Cumulative I/O Cost: 7620 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: 2.167e+09 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: 7620 Arguments: DUPLWARN: (Duplicates Warning flag) FALSE NUMROWS : (Estimated number of rows) ROWWIDTH: (Estimated width of rows) 56 SORTKEY : (Sort Key column) 1: Q1.NAME(A) TEMPSIZE: (Temporary Table Page Size) 4096 UNIQUE : (Uniqueness required flag) Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-17

98 Student Exercises FALSE Input Streams: ) From Operator #4 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q1.ADDRESS+Q1.NAME Output Streams: ) To Operator #2 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q1.NAME(A)+Q1.ADDRESS Record the NUMROWS and ROWWIDTH values from the arguments section of this operation. NUMROWS (Estimated number of rows): (49958) ROWWIDTH (Estimated width of rows): (56) The size of the result set is estimated to * 56 = This is smaller than the available sort heap size which means this can be a 'piped' sort and reduces the estimated cost of the sort operation. No I/Os for temporary table space pages are expected to be necessary. Locate the detailed information about Step 4, a TBSCAN operation. The output will look similar to: 4) TBSCAN: (Table Scan) Cumulative Total Cost: Cumulative CPU Cost: e+09 Cumulative I/O Cost: 7620 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: 2.167e+09 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

99 V Student Exercises EXempty Arguments: MAXPAGES: (Maximum pages for prefetch) ALL PREFETCH: (Type of Prefetch) SEQUENTIAL ROWLOCK : (Row Lock intent) NEXT KEY SHARE SCANDIR : (Scan Direction) FORWARD TABLOCK : (Table Lock intent) INTENT SHARE TBISOLVL: (Table access Isolation Level) CURSOR STABILITY Predicates: ) Sargable Predicate Comparison Operator: Less Than (<) Subquery Input Required: No Filter Factor: Predicate Text: (Q1.ACCT_GRP < 50) Input Streams: ) From Object INST411.ACCT Estimated number of rows: 1e+06 Number of columns: 4 Subquery predicate ID: Not Applicable Column Names: Q1.$RID$+Q1.ADDRESS+Q1.NAME+Q1.ACCT_GRP Output Streams: ) To Operator #3 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-19

100 Student Exercises +Q1.ADDRESS+Q1.NAME The Cumulative I/O Cost of this table scan is 7620 in the above example, which is the number of pages in the ACCT table based on DB2 Catalog statistics. This can be verified in the Objects Used in Access Plan portion at the end of this report. Record the MAXPAGES and PREFETCH values from the arguments section of this operation. MAXPAGES (Maximum pages for prefetch): (ALL) PREFETCH: (Type of Prefetch) (SEQUENTIAL) This shows that the Optimizer plans to perform asynchronous data page reads using the I/O servers. Record the Filter Factor from the Arguments section. This is used to estimate the number of rows that will be in the result set when the WHERE clause of (Q1.ACCT_GRP < 50) is checked. Filter Factor: ( ) This Filter factor is multiplied by the Estimated number of rows: 1e+0 06 (1 million) in the Input Streams to determine the get the Estimated number of rows: that appears in the Output Streams DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

101 V Student Exercises EXempty Section 3 - Using Visual Explain Tool from the Control Center to View Explain Information 1. Use the DB2 Control Center to invoke the Visual Explain tool. The data that was formatted into a report by db2exfmt in Section 2 can be displayed with Visual Explain. In the terminal session, issue the command: db2cc Expand the left panel of the Control Center to access the TP1 database. Right-click the TP1 database and select Show Explained Statements History. The display contains a column SQL text. Scroll through the list of previously explained SQL statements to find the following SQL text: select name, address from acct where acct_grp < 50 order by name Once the entry for this statement is located, select Statement from the menu line, then select Show Access Plan. Look the Visual Explain tool representation of the query processing. This is very similar to the Access Plan section of the db2exfmt report. It shows the same four steps, the numbering may be different: Step 1) Return Step 3) TBSCAN Step 5) SORT Step 7) TBSCAN Visual Explain also shows a rectangle with the name of the ACCT table. The Visual Explain tool uses these objects to show where tables are accessed. Double-click the ACCT table rectangle or use the right mouse button to select Show Statistics. There are two columns of information, Explained are the catalog statistics that were saved when the explain data was created. The Current column shows the catalog statistics for this table now. If the statistics have changed significantly, the DB2 optimizer might produce a different access plan. Select Statement from the menu line, then select Show Optimization Parameters. Similar to the table statistics, there are two columns of information, Explained are the database configuration and bind command options that were saved when the explain data was created. The Current column shows the database configuration options now. If the database configuration has changed significantly, like increasing Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-21

102 Student Exercises the size of the buffer pools or sort heap, the DB2 optimizer might produce a different access plan. The cumulative cost is shown for each step, so for this query Step 4, the ACCT table scan, accounts for almost all of the query cost. Double-click the TBSCAN at the bottom or use the right mouse button to select Show Detail. Scroll through the Input Arguments section to find the Sargable Predicates and locate the Selectivity. This is shown as 0.05 meaning that approximately 5% of the rows will be selected. Browse through the other steps and sections to locate the information that was contained in the db2exfmt report from the previous lab step. Close the Visual Explain application window and exit from the Control Center. Section 4 - Use Visual Explain Tool from Command Editor to View Explain Information for Dynamic SQL 1. Use the DB2 Command Editor to invoke the Visual Explain tool. In the terminal session, issue the command: db2ce Using the Command Editor, enter the following statement: connect to TP1 Select the menu item Selected, then select Execute to run start processing the statement. Enter the following SQL Select statement: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID = 25 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC ; This query joins the HISTORY and TELLER tables. The HISTORY transactions for a single Branch are being selected. To invoke the Visual Explain tool for this query without running the query, select the menu item Selected, then select Access Plan. This query produces a more complex, but very interesting sequence of operations. First find the method that the optimizer selected for joining the two tables. The HSJOIN shown is a hash join operation. This join will bring the TELLER table column data into the sort heap to be joined with the selected data from the HISTORY table DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

103 V Student Exercises EXempty Two indexes will be used for this query, HISTIX1 for the HISTORY table and TELLINDX for the TELLER table. Select each Index shown and look at the statistics for each index. Record the following: Statistics HISTIX1 TELLINDX NLEAF Number of Leaf Pages NLEVEL Number of Index Levels CLUSTERRATIO% Clustered Statistics HISTIX1 TELLINDX NLEAF Number of Leaf Pages 84 4 NLEVEL Number of Index Levels 2 2 CLUSTERRATIO% Clustered Look at the IXSCAN operations for each index and find the predicates listed in the input Arguments panel. The IXSCAN for the HISTIX index is being used to find the transactions for one branch. The IXSCAN for the TELLINDX does not have any predicates, so this will scan the entire index. Using the TELLINDX index is considered efficient because it is small and highly clustered, even though it is not being used to limit the number of TELLER table pages retrieved. Notice that two operations, a SORT and RIDSCN follow the IXSCAN for the HISTIX index, before the FETCH operation is performed. These two operations sort the row pointers or RIDs from the index into page number sequence to improve the I/O efficiency of accessing the HISTORY table. This is based on the low cluster ratio of the HISTIX1 index. The transactions are not physically ordered by branch number and scanning directly using this index could generate more disk I/O requests. The following is the db2exfmt Access Plan for this same query. Access Plan: Total Cost: Query Degree: 1 Rows RETURN ( 1) Cost I/O Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-23

104 Student Exercises TBSCAN ( 2) 434, SORT ( 3) HSJOIN ( 4) / \ FETCH FETCH ( 5) ( 9) / \ / \ RIDSCN TABLE: ADMIN IXSCAN TABLE: ADMIN ( 6) HISTORY ( 10) TELLER SORT INDEX: ADMIN ( 7) TELLINDX IXSCAN ( 8) INDEX: ADMIN HISTIX DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

105 V Student Exercises EXempty Close all the applications, Visual Explain, the Command Editor and Control Center now and deactivate the TP1 database. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 5. DB2 Explain Tools 5-25

106 Student Exercises 5-26 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

107 V Student Exercises EXempty Exercise 6. DB2 Optimizer What This Exercise Is About This exercise is an online lab which allows the student to use the DB2 UDB Explain tools to better understand access plan selections of the DB2 Optimizer. What You Should Be Able to Do At the end of the lab, you should be able to: Configure the DB2 Query Optimization Level to generate different access plans for an SQL query. Utilize the RUNSTATS utility to collect distribution statistics to improve cardinality estimates for SQL query. Use the DB2 explain tools to evaluate the access plan for a query using a table with no catalog statistics and a table that is set to VOLATILE. Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-1

108 Student Exercises Exercise Instructions Introduction In this exercise, you will be using the DB2 Explain tool DB2EXPLN to review the DB2 Optimizer access strategies for running an SQL query with different query optimization levels. The query used, joins two tables and uses indexes to access the tables. A new table, HIST2, will be created with data from the current HISTORY table. A query will be analyzed that references the new HIST2 table that has no catalog statistics. The HIST2 table will be altered to have the VOLATILE option to determine the effect of this option on the optimizer access plan. A set of transaction will be loaded in the HIST2 that have a non-uniform distribution for the branch_id column. The db2exfmt explain tool will be used to show difference between optimizer cardinality estimates with basic table statistics and more detailed distribution statistics for the branch_id column. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown. If a different level of DB2 UDB product is used for this exercise, some of the processing operations selected by the optimizer could also be changed. 6-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

109 V Student Exercises EXempty Section 1 - Use db2expln to Explain a Query That Joins Two Tables with Various Optimization Levels The db2expln tool can be used to produce a simple report that shows the DB2 optimizer's access plan for dynamic SQL statements. A query will be explained with different levels of optimization to see the differences in access plans and estimated query costs. The following query will be used: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID = 25 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC This query joins the HISTORY and TELLER tables. The HISTORY transactions for a single Branch are being selected. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 Check the current database configuration option for DFT_QUERYOPT. db2 get db cfg grep QUERYOPT The output will look similar to the following: Default query optimization class (DFT_QUERYOPT) = 5 This shows that the TP1 database has the default level of query optimization, which is 5. Run the db2expln tool and save the report to a file, lab61.txt. The SQL statement is contained in a file lab60.sql. db2expln -d tp1 -f lab60.sql -z \; -g -o lab61.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL Explain Tool Output is available in 'lab61.txt'. Use the UNIX vi editor to review the explain data saved in the file lab61.txt. In the terminal session, issue the command: vi lab61.txt Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-3

110 Student Exercises The output will look similar to: DB2 Universal Database Version 9.1, (c) Copyright IBM Corp. 1991, 2006 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = No SQL Path "SYSIBMADM", = "SYSIBM", "SYSFUN", "SYSPROC", "INST411" Statement: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID =TELLER.TELLER_ID AND HISTORY.BRANCH_ID =25 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.TELLER ID = 3,4 Index Scan: Name = INST411.TELLINDX ID = 1 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) #Columns = 2 #Key Columns = 0 Start Key: Beginning of Index Stop Key: End of Index 6-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

111 V Student Exercises EXempty Data Prefetch: Eligible 0 Index Prefetch: None Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) Process Build Table for Hash Join Hash Join Early Out: Single Match Per Outer Row Estimated Build Size: Estimated Probe Size: Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Inclusive Value 1: 25 Stop Key: Inclusive Value 1: 25 Index-Only Access Index Prefetch: None Isolation Level: (null) Lock Intents Table: Intent None Row : None Sargable Index Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 1 #Sort Key Columns = 1 Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 16 Piped Duplicate Elimination Sorted Temp Table Completion ID = t1 List Prefetch Preparation Access Table Name = INST411.HISTORY ID = 4,4 #Columns = 5 Fetch Using Prefetched List Prefetch: 330 Pages Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-5

112 Student Exercises Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 1 Process Probe Table for Hash Join Insert Into Sorted Temp Table ID = t2 #Columns = 5 #Sort Key Columns = 1 Key 1: ACCT_ID (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 60 Piped Access Temp Table ID = t2 #Columns = 5 Relation Scan Prefetch: Eligible Sargable Predicate(s) Return Data to Application #Columns = 5 Return Data Completion End of section Optimizer Plan: RETURN ( 1) TBSCAN ( 2) SORT ( 3) HSJOIN ( 4) /-/ \-\ FETCH FETCH (----) ( 9) / \ / \ RIDSCN Table: IXSCAN Table: 6-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

113 V Student Exercises EXempty ( 6) INST411 ( 9) INST411 HISTORY TELLER SORT Index: ( 7) INST411 TELLINDX IXSCAN ( 8) / \ Index: Table: INST411 INST411 HISTIX1 HISTORY 3. Locate the following in the db2expln report: Estimated Cost: ( ) Estimated Cardinality (2000) JOIN Method selected by the Optimizer (HASH JOIN) Access Method for TELLER table: In the example above, the TELLINDX index is sequentially scanned and the row IDs are used to scan the TELLER table. Access Method for HISTORY table: In the example above, the HISTIX1 index is searched for the row IDs with Branch_ID = 25. The row IDs are sorted and LIST PREFETCH is used to efficiently access the HISTORY table rows. How many sort operations are planned? (2 piped sorts) Use db2expln to create another explain report for the same query with the query optimization level set to 1. In the terminal session, issue the command: Change the default query optimization level to 1. db2 update db cfg using DFT_QUERYOPT 1 This database configuration option can be changed with the database active. db2expln -d tp1 -f lab60.sql -z \; -g -o lab62.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL Explain Tool Output is available in 'lab62.txt'. Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-7

114 Student Exercises 4. Use the UNIX vi editor to review the explain data saved in the file lab62.txt. In the terminal session, issue the command: vi lab62.txt The output will look similar to: DB2 Universal Database Version 9.1, (c) Copyright IBM Corp. 1991, 2006 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 1 Partition Parallel = No Intra-Partition Parallel = No SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", "INST411" Statement: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID =TELLER.TELLER_ID AND HISTORY.BRANCH_ID =25 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.TELLER ID = 3,4 Index Scan: Name = INST411.TELLINDX ID = 1 Regular Index (Not Clustered) Index Columns: 6-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

115 V Student Exercises EXempty 1: TELLER_ID (Ascending) #Columns = 2 #Key Columns = 0 Start Key: Beginning of Index Stop Key: End of Index Data Prefetch: Eligible 0 Index Prefetch: None Lock Intents Table: Intent Share Row : Next Key Share Merge Join Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 5 #Key Columns = 1 Start Key: Inclusive Value 1: 25 Stop Key: Inclusive Value 1: 25 Data Prefetch: Eligible 330 Index Prefetch: Eligible 330 Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 5 #Sort Key Columns = 1 Key 1: TELLER_ID (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 40 Piped Sorted Temp Table Completion ID = t1 Access Temp Table ID = t1 #Columns = 5 Relation Scan Prefetch: Eligible Insert Into Sorted Temp Table ID = t2 #Columns = 5 #Sort Key Columns = 1 Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-9

116 Student Exercises Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 60 Piped Access Temp Table ID = t2 #Columns = 5 Relation Scan Prefetch: Eligible Sargable Predicate(s) Return Data to Application #Columns = 5 Return Data Completion End of section Optimizer Plan: RETURN ( 1) TBSCAN ( 2) SORT ( 3) MSJOIN ( 4) / \--\ FETCH * ( 5) * / \ IXSCAN Table: TBSCAN ( 5) INST411 ( 8) TELLER Index: SORT INST411 ( 9) TELLINDX FETCH ( 10) / \ IXSCAN Table: 6-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

117 V Student Exercises EXempty ( 10) INST411 HISTORY Index: INST411 HISTIX1 5. Locate the following in the db2expln report: Estimated Cost: ( ) This is slightly higher than the estimated cost with optimization level set to 5. JOIN Method selected by the Optimizer (MERGE JOIN) Access Method for TELLER table: In the example above, the TELLINDX index is sequentially scanned and the row IDs are used to scan the TELLER table. Access Method for HISTORY table: In the example above, the index HISTIX1 is used to access the HISTORY table. An Index Scan is used to retrieve the transactions with Branch_ID = 25. The rows are then sorted by TELLER_ID for the join. How many sort operations are planned? (2 piped sorts) Use db2expln to create another explain report for the same query with the query optimization level set to 0. In the terminal session, issue the commands: Change the default query optimization level to 0. db2 update db cfg using DFT_QUERYOPT 0 db2expln -d tp1 -f lab60.sql -z \; -g -o lab63.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL Explain Tool 6. Output is available in 'lab53.txt'. Use the UNIX vi editor application to review the explain data saved in the file Lab63.txt. In the terminal session, issue the following command: vi lab63.txt Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-11

118 Student Exercises The output will look similar to: DB2 Universal Database Version 9.1, (c) Copyright IBM Corp. 1991, 2006 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 0 Partition Parallel = No Intra-Partition Parallel = No SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", "INST411" Statement: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID =TELLER.TELLER_ID AND HISTORY.BRANCH_ID =25 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 5 #Key Columns = 1 Start Key: Inclusive Value 6-12 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

119 V Student Exercises EXempty 1: 25 Stop Key: Inclusive Value 1: 25 Data Prefetch: Eligible 330 Index Prefetch: Eligible 330 Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 5 #Sort Key Columns = 1 Key 1: ACCT_ID (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 40 Piped Sorted Temp Table Completion ID = t1 Access Temp Table ID = t1 #Columns = 5 Relation Scan Prefetch: Eligible Nested Loop Join Access Table Name = INST411.TELLER ID = 3,4 Index Scan: Name = INST411.TELLINDX ID = 1 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) #Columns = 1 Single Record Fully Qualified Unique Key #Key Columns = 1 Start Key: Inclusive Value 1:? Stop Key: Inclusive Value 1:? Data Prefetch: None Index Prefetch: None Lock Intents Table: Intent Share Row : Next Key Share Return Data to Application #Columns = 5 Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-13

120 Student Exercises End of section Optimizer Plan: RETURN ( 1) NLJOIN ( 2) /-/ \-\ TBSCAN FETCH ( 3) ( 2) / \ SORT IXSCAN Table: ( 4) ( 2) INST411 TELLER FETCH Index: ( 5) INST411 / \ TELLINDX IXSCAN Table: ( 5) INST411 HISTORY Index: INST411 HISTIX1 Locate the following in the db2expln report: Estimated Cost: ( ) This is higher than the estimated cost of the other access plans selected at levels 1 and 5. JOIN Method selected by the Optimizer (Nested Loop Join) Access Method for HISTORY table: In the example above, the HISTIX1 index will be scanned to retrieve the HISTORY rows for branch_id =25. This is the outer table for the nested loop join. Access Method for TELLER table: In the example above, the TELLINDX index is used to locate the teller information as the inner table for the nested loop join. The index scan will be done once for each row from the HISTORY table. How many sort operations are planned? (1 piped sorts) 6-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

121 V Student Exercises EXempty For this query, the DB2 optimization level of 5 selected a lower cost access plan when compared to levels 1 and Change the default query optimization level for the TP1 database back to 5. In the terminal session, issue the command: db2 update db cfg using DFT_QUERYOPT 5 Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-15

122 Student Exercises Section 2 - Query Optimization using Default Statistics and VOLATILE Tables 1. The TELLER and HISTORY tables and the indexes have DB2 catalog statistics available because the RUNSTATS utility was used to capture those statistics. A new table HIST2 will be created with the same column definitions as the HISTORY table and a similar index will be created. The data in the HISTORY table will be inserted into the new table HIST2. This new table will not have any catalog statistics, so the DB2 optimizer will use default values. The two table join query will be explained using the new HIST2 table in place of the HISTORY table. The file HIST2TAB.DDL has the SQL needed to create the HIST2 table and insert the data. In the terminal session, issue the commands: cd $HOME/bin db2 -tvf hist2tab.ddl The output will look similar to the following: CREATE TABLE HIST2 (ACCT_ID INTEGER NOT NULL, TELLER_ID SMALLINT NOT NULL, BRANCH_ID SMALLINT NOT NULL, BALANCE DECIMAL(15,2) NOT NULL, DELTA INTEGER NOT NULL, PID INTEGER NOT NULL, TSTMP TIMESTAMP NOT NULL WITH DEFAULT, ACCTNAME CHAR(20) NOT NULL, TEMP CHAR(6) NOT NULL) IN TP1DMSH DB20000I The SQL command completed successfully. CREATE INDEX HIST2IX1 ON HIST2 ("BRANCH_ID" DESC, "TELLER_ID" DESC) ALLOW REVERSE SCANS DB20000I The SQL command completed successfully. INSERT INTO HIST2 ( SELECT * FROM HISTORY ) DB20000I The SQL command completed successfully. SELECT COUNT(*) FROM HIST record(s) selected. The SQL to perform the join between the HIST2 and TELLER tables is in the file lab61.sql. The SQL Text is the following: SELECT HIST2.BRANCH_ID, TELLER.TELLER_NAME, HIST2.ACCTNAME, HIST2.ACCT_ID, HIST2.BALANCE FROM HIST2 AS HIST2, TELLER AS TELLER 6-16 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

123 V Student Exercises EXempty WHERE HIST2.TELLER_ID =TELLER.TELLER_ID AND HIST2.BRANCH_ID between 10 and 70 and hist2.teller_id < 200 ORDER BY HIST2.BRANCH_ID ASC, HIST2.ACCT_ID ASC Use db2exfmt to create an explain report for the query in lab61.sql. db2 set current explain mode explain db2 tvf lab61.sql db2exfmt -1 d tp1 o lab64.txt The output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL Explain Tool 2. Output is available in 'lab64.txt'. Use the UNIX vi editor to review the explain data saved in the file lab64.txt. In the terminal session, issue the command: vi lab64.txt The access plan in the explain output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) SORT ( 3) Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-17

124 Student Exercises HSJOIN ( 4) / \ FETCH FETCH ( 5) ( 9) / \ / \ RIDSCN TABLE: INST411 RIDSCN TABLE: INST411 ( 6) HIST2 ( 10) TELLER SORT SORT ( 7) ( 11) IXSCAN IXSCAN ( 8) ( 12) INDEX: INST411 INDEX: INST411 HIST2IX1 TELLINDX Locate the following in the db2expln report: Estimated Cost: ( ) Estimated Cardinality: ( ) JOIN Method selected by the Optimizer (HASH JOIN) Look at the index scan, IXSCAN(12) for the Index TELLINDX. The output will look similar to the following: 6-18 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

125 V Student Exercises EXempty 12) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: Cumulative I/O Cost: 1 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: 2 Arguments: MAXPAGES: (Maximum pages for prefetch) 1 PREFETCH: (Type of Prefetch) NONE ROWLOCK : (Row Lock intent) NONE SCANDIR : (Scan Direction) FORWARD TABLOCK : (Table Lock intent) INTENT NONE Predicates: ) Stop Key Predicate Comparison Operator: Less Than (<) Subquery Input Required: No Filter Factor: Predicate Text: (Q1.TELLER_ID < 200) Input Streams: ) From Object INST411.TELLINDX Estimated number of rows: 1000 Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-19

126 Student Exercises Q1.TELLER_ID(A)+Q1.$RID$ Output Streams: ) To Operator #11 Estimated number of rows: 199 Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q1.TELLER_ID(A) How is the Index being used to access the TELLER table?: In the example above, the TELLINDX index is used to handle the predicate, Q1.TELLER_ID < 200', so the index is scanned until the teller_id of 200 is reached. Look at the index scan, IXSCAN(8) for the Index HIST2IX1. The output will look similar to the following: 8) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: e+07 Cumulative I/O Cost: 21.9 Cumulative Re-Total Cost: Cumulative Re-CPU Cost: e+07 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: 22.9 Arguments: MAXPAGES: (Maximum pages for prefetch) 21 PREFETCH: (Type of Prefetch) SEQUENTIAL ROWLOCK : (Row Lock intent) NONE SCANDIR : (Scan Direction) FORWARD 6-20 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

127 V Student Exercises EXempty TABLOCK : (Table Lock intent) INTENT NONE Predicates: ) Start Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (Q2.BRANCH_ID <= 70) 5) Stop Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (10 <= Q2.BRANCH_ID) Input Streams: ) From Object INST411.HIST2IX1 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q2.BRANCH_ID(D)+Q2.$RID$ Output Streams: ) To Operator #7 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-21

128 Student Exercises Column Names: Q2.BRANCH_ID(D) The Input Streams shows an estimated number of rows at , which is very close to the actual row count of The index scan is being used to retrieve the rows with a branch_id between 10 and 70. The start predicate is (Q2.BRANCH_ID <= 70) and the stop predicate is (10 <= Q2.BRANCH_ID). This is done because the index was created with the branch_id in a descending sequence. How many rows are expected to result from the index scan of the HIST2 table? The example shows rows of output are expected. Next look at the FETCH (5) operation for the HIST2 table. The output will look similar to the following: 5) FETCH : (Fetch) Cumulative Total Cost: Cumulative CPU Cost: e+08 Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: e+07 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Arguments: JN INPUT: (Join input leg) OUTER MAX RIDS: (Maximum RIDs per list prefetch request) 1024 PREFETCH: (Type of Prefetch) LIST ROWLOCK : (Row Lock intent) NEXT KEY SHARE TABLOCK : (Table Lock intent) INTENT SHARE TBISOLVL: (Table access Isolation Level) CURSOR STABILITY Predicates: ) Sargable Predicate Comparison Operator: Less Than (<) 6-22 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

129 V Student Exercises EXempty Subquery Input Required: No Filter Factor: Predicate Text: (Q2.TELLER_ID < 200) 4) Sargable Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (Q2.BRANCH_ID <= 70) 5) Sargable Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (10 <= Q2.BRANCH_ID) Input Streams: ) From Operator #6 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q2.$RID$(A) 5) From Object INST411.HIST2 Estimated number of rows: Number of columns: 5 Subquery predicate ID: Not Applicable Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-23

130 Student Exercises Column Names: Q2.BALANCE+Q2.ACCT_ID+Q2.ACCTNAME +Q2.BRANCH_ID+Q2.TELLER_ID Output Streams: ) To Operator #4 Estimated number of rows: Number of columns: 5 Subquery predicate ID: Not Applicable Column Names: Q2.BALANCE+Q2.ACCT_ID+Q2.ACCTNAME +Q2.BRANCH_ID+Q2.TELLER_ID The Output Streams shows an estimated number of rows at This is also the estimated number of rows that will be returned. Notice that the explain output contains some diagnostic messages: 3. Extended Diagnostic Information: Diagnostic Identifier: 1 Diagnostic Details: EXP0022W Index has no statistics. The index 'INST411 '.'HIST2IX1' has not had runstats run on it. This can lead to poor cardinality and predicate filtering estimates. Diagnostic Identifier: 2 Diagnostic Details: EXP0020W Table has no statistics. The table 'INST411 '.'HIST2' has not had runstats run on it. This may result in a sub-optimal access plan and poor performance. These are warnings that the table HIST2 and its index do not have valid statistics. The HIST2 table could be altered to add the VOLATILE attribute to warn the DB2 Optimizer that the size of the table can fluctuate and the catalog statistics may be inaccurate. Alter the HIST2 table to add the VOLATILE option and use db2expln to generate another explain report for the same query. In the terminal session, issue the commands: 6-24 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

131 V Student Exercises EXempty db2 alter table HIST2 VOLATILE db2 terminate db2 connect to TP1 Use db2exfmt to create an explain report for the query in lab61.sql. db2 set current explain mode explain db2 tvf lab61.sql db2exfmt -1 d tp1 o lab65.txt The access plan in the output will look similar to the following: DB2 Universal Database Version 8.1, (c) Copyright IBM Corp. 1991, 2002 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL Explain Tool 4. Output is available in 'lab65.txt'. Use the UNIX vi editor to review the explain data saved in the file lab65.txt. In the terminal session, issue the following command: vi lab65.txt The output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) SORT ( 3) Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-25

132 Student Exercises HSJOIN ( 4) / \ FETCH FETCH ( 5) ( 7) / \ / \ IXSCAN TABLE: INST411 RIDSCN TABLE: INST411 ( 6) HIST2 ( 8) TELLER INDEX: INST411 SORT HIST2IX1 ( 9) IXSCAN ( 10) INDEX: INST411 TELLINDX Locate the following in the db2expln report: Estimated Cost: ( ) Estimated Cardinality: ( ) What are the differences between these two access plans? The one using default catalog statistics for the HIST2 table and the one with the HIST2 table altered to be volatile? 6-26 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

133 V Student Exercises EXempty The estimated cost for access to the volatile table has been reduced and the number of estimated rows is much less. The 2nd access plan is not using a list prefetch to retrieve the HIST2 rows once the index is accessed. One big difference is that the estimated number of rows resulting from the Hash Join of the two tables is now only Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-27

134 Student Exercises Section 3 - Using Distribution Statistics to improve cardinality estimates Use the LOAD utility to load a new set of transactions into the HIST2 table. Run the RUNSTATS utility to collect the basic statistics. In the terminal session, issue the command: cd $HOME/bin db2 connect to tp1 db2 load from histdist.ixf of ixf messages h2load.txt replace into hist2 db2 runstats on table inst411.hist2 and indexes all Run the query in the file lab62.sql and generate the explain information in the explain tables. The query text is the following: In the terminal session, issue the commands: db2 set current explain mode yes db2 tvf lab62.sql grep selected db2 set current explain mode no The query result was rows. Use db2exfmt to generate the explain report for this query. db2exfmt -1 d tp1 -o lab66.txt vi lab66.txt The access plan in the report will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

135 V Student Exercises EXempty SORT ( 3) HSJOIN ( 4) / \ FETCH FETCH ( 5) ( 7) / \ / \ IXSCAN TABLE: INST411 RIDSCN TABLE: INST411 ( 6) HIST2 ( 8) TELLER INDEX: INST411 SORT HIST2IX1 ( 9) IXSCAN ( 10) INDEX: INST411 TELLINDX What is the estimated number of rows returned? ( ) This is less than the actual query result, 71,962 rows. Look at the IXSCAN (6) operation for the HIST2 table. Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-29

136 Student Exercises The output will look similar to: 6) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: e+08 Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: e+08 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Arguments: MAXPAGES: (Maximum pages for prefetch) 45 PREFETCH: (Type of Prefetch) SEQUENTIAL ROWLOCK : (Row Lock intent) NEXT KEY SHARE SCANDIR : (Scan Direction) FORWARD TABLOCK : (Table Lock intent) INTENT SHARE VOLATILE: (Volatile type) CARDINALITY Predicates: ) Start Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: 0.3 Predicate Text: (Q2.BRANCH_ID <= 30) 5) Stop Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: 0.91 Predicate Text: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

137 V Student Exercises EXempty (10 <= Q2.BRANCH_ID) Input Streams: ) From Object INST411.HIST2IX1 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q2.BRANCH_ID(D)+Q2.$RID$ 3. Output Streams: ) To Operator #5 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q2.BRANCH_ID(D) The Input Streams are the table HIST2, which has rows. The predicate section shows that the predicate, Branch_id between 10 and 30' is expected to match about 20% of the rows, so the output stream has an estimated count of 107,851 rows. There are 100 unique values for branch_id, with a range of 1 to 100, so basic statistics indicate that about 20% would be between the values of 10 and 30. The problem is that the HIST2 data has a non-uniform distribution for the branch_id column. Collect distribution statistics for the table HIST2 using the RUNSTATS utility. Run the query lab62.sql and generate a new explain report. In the terminal session, issue the commands: db2 runstats on table inst411.hist2 on all columns with distribution on columns ( branch_id num_freqvalues 20 num_quantiles 50) and detailed indexes all db2 set current explain mode yes db2 tvf lab62.sql grep selected db2 set current explain mode no Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-31

138 Student Exercises db2exfmt -1 d tp1 -o lab67.txt vi lab67.txt The access plan in the report will look similar to: The access plan in the report will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) SORT ( 3) HSJOIN ( 4) / \ FETCH FETCH ( 5) ( 7) / \ / \ IXSCAN TABLE: INST411 RIDSCN TABLE: INST411 ( 6) HIST2 ( 8) TELLER DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

139 V Student Exercises EXempty INDEX: INST411 SORT HIST2IX1 ( 9) IXSCAN ( 10) INDEX: INST411 TELLINDX What is the estimated number of rows returned? ( ) This is much closer to the actual query result, 71,962 rows. Look at the details for the IXSCAN (6) operation for the HIST2 table. The output will look similar to: 6) IXSCAN: (Index Scan) Cumulative Total Cost: Cumulative CPU Cost: e+08 Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: e+08 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Arguments: MAXPAGES: (Maximum pages for prefetch) 143 PREFETCH: (Type of Prefetch) SEQUENTIAL ROWLOCK : (Row Lock intent) NEXT KEY SHARE SCANDIR : (Scan Direction) FORWARD TABLOCK : (Table Lock intent) INTENT SHARE Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-33

140 Student Exercises VOLATILE: (Volatile type) CARDINALITY Predicates: ) Start Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (Q2.BRANCH_ID <= 30) 5) Stop Key Predicate Comparison Operator: Less Than or Equal (<=) Subquery Input Required: No Filter Factor: Predicate Text: (10 <= Q2.BRANCH_ID) Input Streams: ) From Object INST411.HIST2IX1 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q2.BRANCH_ID(D)+Q2.$RID$ Output Streams: ) To Operator #5 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable 6-34 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

141 V Student Exercises EXempty 4. Column Names: Q2.BRANCH_ID(D) The Input Streams are the table HIST2, which has rows, and the result of the index scan, which is expected to have row pointers. With distribution statistics on the branch_id column, the optimizer now estimates that about 66% of the HIST2 rows will be returned by the index scan. In this example the generated access plans had the same operations for both sets of statistics. In many cases the access plan would be different when the cardinality changes significantly. For example, if the index on the HIST2 table had a lower cluster ratio, the optimizer might have selected a table scan for a larger expected result. Close all the applications now and deactivate the TP1 database. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 6. DB2 Optimizer 6-35

142 Student Exercises 6-36 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

143 V Student Exercises EXempty Exercise 7. Using Indexes for Performance What This Exercise Is About This exercise is an online lab which allows the student to analyze the performance impact of indexes to improve the efficiency of processing SQL statements. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 design advisor command, db2advis to recommend new indexes for a defined SQL workload. Implement new indexes to reduce query processing costs. Use the explain tools db2exfmt and db2expln to review access plans that contain dynamic bitmap index anding operations. Examine a db2expln report for a query that uses multiple indexes for an OR clause. Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-1

144 Student Exercises Exercise Instructions Introduction In this exercise, you will be using the DB2 design Advisor, in command mode, to evaluate new indexes to reduce processing costs for a set of SQL queries. A new index will be implemented for the HISTORY table, based on the TELLER_ID column. Two SQL queries will be explained. One contains predicates for the BRANCH_ID and TELLER_ID with an AND condition. The other SQL query contains an OR condition for two predicates. The explain tools will be used to examine access plans that combine multiple indexes on a single table to reduce query processing costs. 7-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

145 V Student Exercises EXempty Section 1 Use the DB2 Design Advisor to recommend Indexes for an application workload. 1. A new application is being developed that will require efficient access to selected HISTORY table transactions. The HISTORY table will grow much larger over time, so indexes need to be created to avoid scanning the entire table for these applications. Examples of the SQL queries are in a file named advisesql.txt. Use the UNIX vi editor to look at the SQL text. In the terminal session, issue the command: vi advisesql.txt -- SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE BRANCH_ID = 50 ORDER BY TELLER_ID ASC ; -- SELECT * FROM HISTORY WHERE BRANCH_ID = 50 ORDER BY TELLER_ID ASC ; -- SELECT * FROM HISTORY WHERE BRANCH_ID = 10 and teller_id = 200 ; 2. SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE TELLER_ID BETWEEN 100 AND 300 ORDER BY TELLER_ID ASC ; SELECT BRANCH_ID, TELLER_ID, ACCT_ID, BALANCE, ACCTNAME FROM HISTORY WHERE BRANCH_ID < 20 AND TELLER_ID BETWEEN 700 AND 800 ; The SQL statements are selecting data from the HISTORY table for specific BRANCH_ID and TELLER_ID values and ranges. Use the DB2ADVIS command to analyze the SQL statements in the file advisesql.txt. In the terminal session, issue the commands: db2 connect to tp1 Run the db2advis application and save the output to a file. db2advis -d tp1 -i advisesql.txt -o newindex.ddl > adviseout.txt vi adviseout.txt Review the Index Advisor output. The output will look similar to the following: execution started at timestamp found [5] SQL statements from the input file Recommending indexes... Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-3

146 Student Exercises total disk space needed for initial set [ ] MB total disk space constrained to [ ] MB Trying variations of the solution set. Optimization finished. 4 indexes in current solution [ ] timerons (without recommendations) [ ] timerons (with current solution) [38.39%] improvement LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], 2.688MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("BRANCH_ID" ASC, "TELLER_ID" ASC, "ACCTNAME" ASC, "BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; -- index[2], 4.314MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("BRANCH_ID" ASC, "TELLER_ID" ASC, "TEMP" ASC, "ACCTNAME" ASC, "TSTMP" ASC, "PID" ASC, "DELTA" ASC, "BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; -- index[3], 4.314MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("TELLER_ID" ASC, "BRANCH_ID" ASC, "TEMP" ASC, "ACCTNAME" ASC, "TSTMP" ASC, "PID" ASC, "DELTA" ASC, "BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; -- index[4], 2.688MB 7-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

147 V Student Exercises EXempty CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("TELLER_ID" ASC, "BRANCH_ID" ASC, "ACCTNAME" ASC, "BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; RECOMMENDED EXISTING INDEXES -- ============================ -- RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."HISTIX1" ; -- COMMIT WORK ; UNUSED EXISTING INDEXES -- ============================ -- =========================== solutions were evaluated by the advisor DB2 Workload Performance Advisor tool is finished. How many Indexes were suggested by the Index Advisor? What was the estimated cost, in timerons, for running the queries without the new indexes? What was the estimated cost, in timerons, for running the queries with new indexes? What was the percentage improvement in estimated cost? What is the estimated total disk space for the new indexes? Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-5

148 Student Exercises 3. The Design Advisor may have recommended several new indexes, tailored to optimize each of the SQL SELECTS in the file. In the example above, the suggested indexes all have multiple columns and in some cases every column from the HISTORY table included in the new index. That is because some of the queries use 'SELECT * FROM...'. Having all columns in the index would allow 'index only access' avoiding the I/O for the related data pages. Although this might provide some improved performance for the queries, the additional disk space for the indexes and the maintenance overhead may not be justified. Run the db2advis command again, and add the option to limit the disk space of any new indexes to 4 MB. In the terminal session, issue the commands: db2advis -d tp1 -i advisesql.txt -disklimit 4 -o newindex.ddl > adviseout2.txt vi adviseout2.txt The output will look similar to the following: execution started at timestamp found [5] SQL statements from the input file Recommending indexes... total disk space needed for initial set [ 5.377] MB total disk space constrained to [ 4.000] MB Trying variations of the solution set. Optimization finished. 1 indexes in current solution [ ] timerons (without recommendations) [ ] timerons (with current solution) [22.27%] improvement LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], 2.688MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("BRANCH_ID" ASC, "TELLER_ID" ASC, "ACCTNAME" ASC, "BALANCE" ASC, "ACCT_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

149 V Student Exercises EXempty RECOMMENDED EXISTING INDEXES -- ============================ -- RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."HISTIX1" ; -- COMMIT WORK ; UNUSED EXISTING INDEXES -- ============================ -- =========================== solutions were evaluated by the advisor DB2 Workload Performance Advisor tool is finished. How many Indexes were suggested by the Index Advisor? What was the estimated cost, in timerons, for running the queries without indexes additional indexes? What was the estimated cost, in timerons, for running the queries with new indexes? What was the percentage improvement in estimated cost? What is the estimated total disk space for the new index? The new index suggested this time would have the columns Branch_ID and Teller_ID and some additional columns. Four of the five queries include predicates based on the Branch_ID column. There is already a single column index on the Branch_ID column. To add a new index with the smallest amount of overhead to processing the inserts into the HISTORY table, a new index with the TELLER_ID column will be added. Run the DB2 command file, crhistix2.ddl, to create the new index. The index statistics will be collected during index creation to avoid the need to run a RUNSTATS command. Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-7

150 Student Exercises In the terminal session, issue the commands: db2 connect to tp1 db2 -tvf crhistix2.ddl The output will look similar to the following: CREATE INDEX HISTIX2 ON HISTORY (teller_id ASC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS DB20000I The SQL command completed successfully. 7-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

151 V Student Exercises EXempty Section 2 Using Multiple Indexes for improving query processing 1. Now there are two single column indexes on the HISTORY table, one on the BRANCH_ID column and one on the TELLER_ID column. The DB2 optimizer can combine both indexes to reduce SQL processing costs. First we will look at a query that uses the two columns with an AND condition. The sample SQL text used is the following: select * from history where BRANCH_ID between 10 and 20 AND TELLER_ID > 800 First generate a detailed explain report using db2exfmt for this query. The sql text is in a file indexand.sql. In the terminal session, issue the commands: cd $HOME/bin db2 connect to tp1 db2 set current explain mode explain db2 tvf indexand.sql db2 set current explain mode no db2exfmt -1 d tp1 > indexand.txt vi indexand.txt The access plan in the db2exfmt report will look similar to the following: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O FETCH ( 2) / \ RIDSCN TABLE: INST411 ( 3) HISTORY Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-9

152 Student Exercises SORT ( 4) IXAND ( 5) / \ IXSCAN IXSCAN ( 6) ( 7) INDEX: INST411 INDEX: INST411 HISTIX1 HISTIX2 The access plan above includes an Index ANDING operation, IXAND (5). Look at the details for this operation in the db2exfmt report. The output will look similar to the following: 5) IXAND : (Index ANDing) Cumulative Total Cost: Cumulative CPU Cost: e+08 Cumulative I/O Cost: Cumulative Re-Total Cost: Cumulative Re-CPU Cost: e+08 Cumulative Re-I/O Cost: 0 Cumulative First Row Cost: Estimated Bufferpool Buffers: Input Streams: ) From Operator #6 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable 7-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

153 V Student Exercises EXempty Column Names: Q1.BRANCH_ID(A) 4) From Operator #7 Estimated number of rows: Number of columns: 1 Subquery predicate ID: Not Applicable Column Names: Q1.TELLER_ID(A) Output Streams: ) To Operator #4 Estimated number of rows: Number of columns: 2 Subquery predicate ID: Not Applicable Column Names: Q1.TELLER_ID(A)+Q1.$RID$ The Input Streams, shows that the two index scans are being used as input to the index anding operation. This is the Dynamic Bitmap Index Anding' operation that uses sortheap memory to compare lists of RIDs from multiple index scans. In this example the index scan from the index on TELLER_ID is estimated to generate rows. The index scan from the BRANCH_ID index is estimated to generate rows. So either index alone would require access to a large portion of the HISTORY table. The Output Streams section for this operation shows that an estimated rows would be expected to match both index lists. That should reduce the number of pages in the HISTORY table that need to be accessed. A list prefetch operation will be used to efficiently retrieve the list of pages that contain the rows resulting from the index anding function. 2. Next we will look at the information about this same SQL statement in the shorter report generated by the db2expln tool. Use the db2expln tool to generate a simple access plan report for the same query, in the file indexand.sql. In the terminal session, issue the command: db2expln d tp1 f indexand.sql g I z \; -o indexand2.txt The output will look similar to the following: Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-11

154 Student Exercises Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = No SQL Path "SYSIBMADM", = "SYSIBM", "SYSFUN", "SYSPROC", "INST411" Statement: select * from history where branch_id between 10 and 20 and teller_id > 800 Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Index ANDing Optimizer Estimate of Set Size: 4400 Index ANDing Bitmap Build Using Row IDs Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Inclusive Value 1: 10 Stop Key: Inclusive Value 1: 20 Index-Only Access Index Prefetch: None Isolation Level: (null) Lock Intents Table: Intent None Row : None 7-12 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

155 V Student Exercises EXempty Index ANDing Bitmap Probe Using Row IDs Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX2 ID = 2 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Exclusive Value 1: 800 Stop Key: End of Index Index-Only Access Index Prefetch: Eligible 16 Isolation Level: (null) Lock Intents Table: Intent None Row : None Insert Into Sorted Temp Table ID = t1 #Columns = 1 #Sort Key Columns = 1 Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 16 Piped Duplicate Elimination List Prefetch Preparation Access Table Name = INST411.HISTORY ID = 4,4 #Columns = 9 Fetch Using Prefetched List Prefetch: 385 Pages Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 3 Return Data to Application #Columns = 9 Return Data Completion End of section Optimizer Plan: Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-13

156 Student Exercises RETURN ( 1) FETCH (----) / \ RIDSCN Table: ( 3) INST411 HISTORY SORT ( 4) IXAND ( 5) /-/ \-\ IXSCAN IXSCAN ( 6) ( 7) / \ / \ Index: Table: Index: Table: INST411 INST411 INST411 INST411 HISTIX1 HISTORY HISTIX2 HISTORY The less detailed report from db2expln does show that the access plan includes and index anding function. The report also provides some useful details for the index anding operation. The sample report includes the following text: Index ANDing Optimizer Estimate of Set Size: 4400 Index ANDing Bitmap Build Using Row IDs Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Inclusive Value 1: 10 Stop Key: Inclusive Value 1: 20 Index-Only Access 7-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

157 V Student Exercises EXempty 3. This shows that the index INST411.HISTIX1 will be used to build' the initial bitmap. It also shows that 4400 rows are estimated to result from the index anding operation. It does not show the estimates for each index scan. The other index access is shown as follows: Index ANDing Bitmap Probe Using Row IDs Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX2 ID = 2 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Exclusive Value 1: 800 Stop Key: End of Index This shows that the second index, INST411.HISTIX2 will be used to probe' the bitmap and generate the subset of row ids that match both index lists. Next we will look at a query that uses an OR clause instead of the AND clause for selecting rows from the HISTORY table. The sample SQL text is the following: select * from history where BRANCH_ID between 10 and 12 OR TELLER_ID =800 Generate a simple explain report using db2expln for this query. The sql text is in a file indexor.sql. db2expln d tp1 f indexor.sql g I z \; -o indexor.txt vi indexor.txt The output will look similar to the following: DB2 Universal Database Version 9.1, (c) Copyright IBM Corp. 1991, 2006 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = No SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-15

158 Student Exercises "INST411" Statement: select * from history where branch_id between 10 and 12 or teller_id =800 Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Inclusive Value 1: 10 Stop Key: Inclusive Value 1: 12 Index-Only Access Index Prefetch: None Isolation Level: (null) Lock Intents Table: Intent None Row : None Sargable Index Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 1 #Sort Key Columns = 1 Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 16 Piped Duplicate Elimination Sorted Temp Table Completion ID = t1 Access Table Name = INST411.HISTORY ID = 4,4 Index Scan: Name = INST411.HISTIX2 ID = 2 Regular Index (Not Clustered) 7-16 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

159 V Student Exercises EXempty Index Columns: 1: TELLER_ID (Ascending) #Columns = 0 #Key Columns = 1 Start Key: Inclusive Value 1: 800 Stop Key: Inclusive Value 1: 800 Index-Only Access Index Prefetch: None Isolation Level: (null) Lock Intents Table: Intent None Row : None Sargable Index Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 1 Sorted Temp Table Completion ID = t1 Index ORing Preparation Prefetch: Enabled Access Table Name = INST411.HISTORY ID = 4,4 #Columns = 9 Fetch Using Prefetched List Prefetch: 415 Pages Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 3 Return Data to Application #Columns = 9 Return Data Completion End of section Optimizer Plan: RETURN ( 1) FETCH (----) /-/ \ RIDSCN Table: ( 3) INST411 Copyright IBM Corp. 2001, 2006 Exercise 7. Using Indexes for Performance 7-17

160 Student Exercises /-/ \-\ HISTORY SORT SORT ( 4) ( 6) IXSCAN IXSCAN ( 5) ( 7) / \ / \ Index: Table: Index: Table: INST411 INST411 INST411 INST411 HISTIX1 HISTORY HISTIX2 HISTORY The access plan in the explain report does not show a special operation for performing ORing of multiple indexes. The report does include the following text: Index ORing Preparation Prefetch: Enabled Access Table Name = INST411.HISTORY ID = 4,4 #Columns = 9 Fetch Using Prefetched List Prefetch: 415 Pages This shows that the sorted RID lists from the two index scans will be used in a list prefetch operation to access the HISTORY table. END OF EXERCISE 7-18 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

161 V Student Exercises EXempty Exercise 8. Complex SQL Performance What This Exercise Is About This exercise is an online lab which allows the student to use the DB2 explain tools to better understand access strategies of the DB2 Optimizer, including using indexes to join tables. A range partitioned table will be created to better understand the use of partition elimination for processing queries. A Materialized Query Table (MQT), will be used to improve query performance. What You Should Be Able to Do At the end of the lab, you should be able to: Use the explain tools to analyze SQL statements that access a range partitioned table and determine if partition elimination is being utilized in the access plan. Create a Materialized Query Table to reduce the cost of running a SQL query that summarizes information from a large table. Create new indexes with INCLUDE columns to improve the performance of a multiple table join query. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-1

162 Student Exercises Exercise Instructions Introduction In this exercise, you will be using the DB2 Explain tools and SNAPSHOT statistics to analyze SQL queries. A Materialized Query Table or MQT will be created to provide efficient access to summarized information from the ACCT table without scanning the large ACCT table. A three table join SQL statement will be analyzed to decide what new indexes could be created to improve the performance of this query. The indexes will be created and the performance will be measured to see if the expected benefits are realized. A range partitioned table will be created using the branch_id column to separate data into multiple data partitions. Several example queries will be analyzed to understand how the DB2 optimizer can use partition elimination to reduce processing costs for rage partitioned tables. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown. If a different level of DB2 UDB product is used for this exercise, some of the processing operations selected by the optimizer could also be changed. 8-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

163 V Student Exercises EXempty Section 1 - Using Indexes to Improve Table Join Query Performance 1. The ACCT table is the largest table for the TP1 database. A new application is being created to list all the HISTORY table transactions for a single account. The application reports some detailed information in the ACCT and TELLER tables. The explain tool db2exfmt will be used to get optimizer access plan information. The GET SNAPSHOT for database re port will provide the performance statistics. The SQL query used will be the following: SELECT ACCT.ACCT_ID, ACCT.NAME, TELLER.TELLER_ID, TELLER.TELLER_NAME, HISTORY.BRANCH_ID, HISTORY.BALANCE, HISTORY.PID FROM ACCT AS ACCT, TELLER AS TELLER, HISTORY AS HISTORY WHERE ACCT.ACCT_ID = HISTORY.ACCT_ID AND ACCT.ACCT_ID = 2000 AND HISTORY.TELLER_ID = TELLER.TELLER_ID ORDER BY HISTORY.PID ASC In the terminal session, issue the commands: db2 connect to tp1 db2 reset monitor all db2 set current explain mode YES db2 set current explain snapshot YES Run the query now. db2 -tvf lab81.sql Get the current database read statistics. db2 get snapshot for database on tp1 grep -i read The output will look similar to: Buffer pool data logical reads = 1465 Buffer pool data physical reads = 931 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Asynchronous pool data page reads = 858 Buffer pool index logical reads = 261 Buffer pool index physical reads = 43 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Asynchronous pool index page reads = 0 Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-3

164 Student Exercises 2. Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Asynchronous pool xda page reads = 0 Total buffer pool read time (milliseconds) = 4042 Total elapsed asynchronous read time = 3763 Asynchronous data read requests = 108 Asynchronous index read requests = 0 Asynchronous xda read requests = 0 Unread prefetch pages = 0 Direct reads = 130 Direct read requests = 14 Direct reads elapsed time (ms) = 68 Rows read = Log pages read = 0 Log read time (sec.ns) = Number read log IOs = 0 The snapshot shows relatively small counts for logical and physical reads. The number of rows read is high due to the scanning of the HISTORY table to locate the transactions for this one ACCT_ID. Format the explain table data for the last statement into a report. db2exfmt -1 -d tp1 -o lab8join1.txt Use the vi editor to view the explain report. vi lab8join1.txt Locate the Access Plan section. The output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O TBSCAN ( 2) 8-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

165 V Student Exercises EXempty SORT ( 3) NLJOIN ( 4) / \ FETCH NLJOIN ( 5) ( 8) / \ / \ 1 1e IXSCAN TABLE: INST411 TBSCAN FETCH ( 6) ACCT ( 9) ( 10) / \ 1e INDEX: INST411 TABLE: INST411 IXSCAN TABLE: INST411 ACCTINDX HISTORY ( 11) TELLER INDEX: INST411 TELLINDX Locate the following from the Access Plan section: Estimated Total Cost: ( ) What is the Estimated Cost to access the ACCT table? ( ) What is the Estimated Cost to access the TELLER table? ( ) What is the Estimated Cost to access the HISTORY table? ( ) Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-5

166 Student Exercises 3. The HISTORY table access, using a table scan, is the most costly operation of the query. As the HISTORY table will become very large over time, this cost will increase. The DB2 optimizer plan shows that a nested loop join will be used to join the HISTORY rows retrieved to the TELLER table using the index on TELLER_ID. The ACCT table is also being accessed using the index on the ACCT_ID column. Use the DB2 Index Advisor to recommend new indexes to improve the efficiency of the SQL query. Save the Index Advisor report to a file and use the UNIX vi editor to view the file. In the terminal session, issue the commands: db2advis -d tp1 -i lab81.sql -disklimit 70 > lab8advise1.txt vi lab8advise1.txt The output will look similar to the following: execution started at timestamp found [1] SQL statements from the input file Recommending indexes... total disk space needed for initial set [ 5.800] MB total disk space constrained to [ ] MB Trying variations of the solution set. Optimization finished. 3 indexes in current solution [ ] timerons (without recommendations) [ ] timerons (with current solution) [96.41%] improvement LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], 5.485MB CREATE UNIQUE INDEX "INST411 "."IDX " ON "INST411 "."ACCT" ("ACCT_ID" ASC) INCLUDE ("NAME") ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."ACCT" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; -- index[2], 0.274MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."HISTORY" ("ACCT_ID" ASC, "TELLER_ID" ASC, "PID" ASC, "BALANCE" 8-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

167 V Student Exercises EXempty ASC, "BRANCH_ID" ASC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."HISTORY" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; -- index[3], 0.040MB CREATE UNIQUE INDEX "INST411 "."IDX " ON "INST411 "."TELLER" ("TELLER_ID" ASC) INCLUDE ("TELLER_NAME") ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."TELLER" FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; RECOMMENDED EXISTING INDEXES -- ============================ -- RUNSTATS ON TABLE "INST411 "."ACCT" FOR INDEX "INST411 "."ACCTINDX" ; -- COMMIT WORK ; -- RUNSTATS ON TABLE "INST411 "."TELLER" FOR INDEX "INST411 "."TELLINDX" ; -- COMMIT WORK ; UNUSED EXISTING INDEXES -- ============================ -- DROP INDEX "INST411 "."HISTIX1"; -- DROP INDEX "INST411 "."HISTIX2"; -- =========================== solutions were evaluated by the advisor DB2 Workload Performance Advisor tool is finished. The DB2ADVIS tool recommended three new indexes. One for each table. The ACCT and TELLER table indexes are unique indexes with additional INCLUDE columns. These indexes could be used to replace the current unique indexes on these tables. The new index for the HISTORY table includes a number of extra columns. A new index for the HISTORY table will be created, but only the ACCT_ID will be included to limit the size of this new index as the table grows larger. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-7

168 Student Exercises The DB2 Command file, lab82.ddl, contains the following SQL statements to create the new indexes and generate index statistics. -- ACCT Index DROP INDEX ACCTINDX ; CREATE UNIQUE INDEX ACCTINDX ON ACCT (ACCT_ID ASC) INCLUDE (NAME) ALLOW REVERSE SCANS ; RUNSTATS ON TABLE DB2INST1.ACCT FOR INDEXES ALL ; COMMIT WORK ; -- HISTORY INDEX CREATE INDEX HISTIX3 ON HISTORY (ACCT_ID ASC ) ALLOW REVERSE SCANS ; -- RUNSTATS ON TABLE DB2INST1.HISTORY FOR INDEXES ALL ; COMMIT WORK ; -- TELLER INDEX DROP INDEX TELLINDX ; CREATE UNIQUE INDEX TELLINDX ON TELLER (TELLER_ID ASC) INCLUDE (TELLER_NAME) ALLOW REVERSE SCANS ; 5. RUNSTATS ON TABLE DB2INST1.TELLER FOR INDEXES ALL ; In the terminal session, issue the commands: db2 terminate db2 connect to tp1 db2 -tvf lab82.ddl Now that new indexes are available, run the query again and collect the same information. In the terminal session, issue the commands: db2 reset monitor all db2 set current explain mode YES db2 set current explain snapshot YES db2 -tvf lab81.sql Get the current database read statistics. db2 get snapshot for database on tp1 grep -i read The output will look similar to: Buffer pool data logical reads = 403 Buffer pool data physical reads = 41 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Asynchronous pool data page reads = 0 Buffer pool index logical reads = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

169 V Student Exercises EXempty Buffer pool index physical reads = 23 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Asynchronous pool index page reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Asynchronous pool xda page reads = 0 Total buffer pool read time (milliseconds) = 424 Total elapsed asynchronous read time = 0 Asynchronous data read requests = 0 Asynchronous index read requests = 0 Asynchronous xda read requests = 0 Unread prefetch pages = 0 Direct reads = 98 Direct read requests = 12 Direct reads elapsed time (ms) = 34 Rows read = 52 Log pages read = 0 Log read time (sec.ns) = Number read log IOs = 0 6. These statistics show a much smaller count for Rows Read. The new index on the HISTORY table is able to avoid the scanning of every row in the HISTORY table. Format the explain table data for the last statement into a report. db2exfmt -1 -d tp1 -o lab8join2.txt Use the vi editor to view the explain report. vi lab8join2.txt Locate the Access Plan section. The output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-9

170 Student Exercises NLJOIN ( 2) / \ TBSCAN IXSCAN ( 3) ( 9) SORT INDEX: INST411 ( 4) TELLINDX NLJOIN ( 5) / \ IXSCAN FETCH ( 6) ( 7) / \ 1e INDEX: INST411 IXSCAN TABLE: INST411 ACCTINDX ( 8) HISTORY INDEX: INST411 HISTIX3 Locate the following from the Visual Explain shown: Estimated Total Cost: (86.757) What is the Estimated Cost to access the ACCT table? ( ) What is the Estimated Cost to access the TELLER table? (12.871) 8-10 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

171 V Student Exercises EXempty What is the Estimated Cost to access the HISTORY table? ( ) The new indexes allow Index Only access for the TELLER and ACCT tables. The index for the HISTORY table eliminates the need for a table scan. As the HISTORY table will become very large over time, this Access Plan should continue to provide efficient access at a much lower cost. These indexes will increase the processing costs for the MULTI transactions that insert rows into the HISTORY table. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-11

172 Student Exercises Section 2 - Use a Materialized Query Table to Improve Performance of a Query 1. The ACCT table is the largest table for the TP1 database. Some reporting applications will need summary information based on the ACCT_GRP value of groups of accounts rather than detailed information from a single account. Use the SET CURRENT EXPLAIN statement to generate the explain table information from a dynamic SQL statement. The query will be executed so that SNAPSHOT performance statistics can be collected. The DB2 utility db2exfmt will be used to format the explain data into a report. The SQL query used will be the following: SELECT ACCT_GRP, SUM(BALANCE) FROM ACCT WHERE ACCT_GRP BETWEEN 100 AND 150 GROUP BY ACCT_GRP This will require a table scan and a sort operation to produce the result set. In the terminal session, issue the commands: cd $HOME/bin db2 terminate db2 connect to tp1 db2 reset monitor all db2 set current explain mode YES db2 set current explain snapshot YES Run the query using the file lab8sum.sql. db2 -tvf lab8sum.sql The output will look similar to the following: ACCT_GRP DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

173 V Student Exercises EXempty record(s) selected. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-13

174 Student Exercises Collect the database statistics with a GET SNAPSHOT command to and use the UNIX grep command to get the counters for reads. db2 get snapshot for database on tp1 grep -i read The output will look similar to: Buffer pool data logical reads = 8053 Buffer pool data physical reads = 7665 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Asynchronous pool data page reads = 7366 Buffer pool index logical reads = 158 Buffer pool index physical reads = 35 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Asynchronous pool index page reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Asynchronous pool xda page reads = 0 Total buffer pool read time (milliseconds) = 6983 Total elapsed asynchronous read time = 6418 Asynchronous data read requests = 118 Asynchronous index read requests = 0 Asynchronous xda read requests = 0 Unread prefetch pages = 0 Direct reads = 116 Direct read requests = 12 Direct reads elapsed time (ms) = 48 Rows read = Log pages read = 0 Log read time (sec.ns) = Number read log IOs = 0 There were a large number of logical and physical reads for data. This was caused by the table scan for the ACCT table. All one million rows of the ACCT table were read, but only the summarized information was selected. Format the explain table data for the last statement into a report. db2exfmt -1 -d tp1 -o lab8mqt1.txt Examine the file using the UNIX vi editor. vi lab8mqt1.txt 8-14 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

175 V Student Exercises EXempty Locate the Access Plan section. The output will look similar to: Access Plan: Total Cost: Query Degree:1 Rows RETURN ( 1) Cost I/O GRPBY ( 2) TBSCAN ( 3) SORT ( 4) TBSCAN ( 5) e+06 TABLE: INST411 ACCT The Access Plan shows that almost all of the query cost comes from the TBSCAN, with a relatively small cost from the SORT operation. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-15

176 Student Exercises 4. It is possible that an index on the ACCT_GRP column might allow subsets of the ACCT table to be accessed directly and avoid the table scan. A Materialized Query Table might also provide an efficient method to query the ACCT table summarized by ACCT_GRP values. The DB2 Design Advisor can be invoked using the db2advis command to evaluate both alternatives and suggest the use of either indexes, MQTs or a combination of the two, in order to reduce query cost. In a terminal session, issue the commands: cd $HOME/bin db2advis -d tp1 -file lab8sum.sql -type IM > lab8advise2.txt Review the Design Advisor output using UNIX vi editor. vi lab8advise2.txt execution started at timestamp Using the default table space name USERSPACE1 found [1] SQL statements from the input file Recommending indexes... Recommending MQTs... Found 1 user defined views in the catalog table Found [2] candidate MQTs Getting cost of workload with MQTs total disk space needed for initial set [ 5.573] MB total disk space constrained to [ ] MB Trying variations of the solution set. Optimization finished. 1 indexes in current solution 1 MQTs in current solution [ ] timerons (without recommendations) [ ] timerons (with current solution) [99.91%] improvement LIST OF RECOMMENDED MQTs -- =========================== -- MQT MQT can be created as a refresh immediate MQT -- mqt[1], 0.032MB CREATE SUMMARY TABLE "INST411 "."MQT " AS (SELECT Q3.C0 AS "C0", Q3.C1 AS "C1", Q3.C2 AS "C2" FROM TABLE(SELECT Q2.C0 AS "C0", SUM(Q2.C1) AS "C1", COUNT(* ) AS "C2" FROM TABLE(SELECT Q1.ACCT_GRP AS "C0", Q1.BALANCE AS "C1" FROM INST411.ACCT AS Q1) AS Q2 GROUP BY Q2.C0) AS Q3) DATA INITIALLY DEFERRED 8-16 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

177 V Student Exercises EXempty REFRESH IMMEDIATE IN TP1DMSAD ; COMMIT WORK ; REFRESH TABLE "INST411 "."MQT " ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."MQT " ; COMMIT WORK ; RECOMMENDED EXISTING MQTs -- =========================== UNUSED EXISTING MQTs -- ============================ LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], 0.036MB CREATE INDEX "INST411 "."IDX " ON "INST411 "."MQT " ("C0" ASC, "C1" DESC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE "INST411 "."MQT " FOR INDEX "INST411 "."IDX " ; COMMIT WORK ; RECOMMENDED EXISTING INDEXES -- ============================ UNUSED EXISTING INDEXES -- ============================ Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-17

178 Student Exercises -- DROP INDEX "INST411 "."ACCTINDX"; -- =========================== solutions were evaluated by the advisor DB2 Workload Performance Advisor tool is finished. In the above example, the design advisor has recommended creating a MQT that will contain the summed balance for each ACCT_GRP and a index for the new MQT that would contain ACCT_GRP and SUM(Balance) columns. It is estimated that with the new MQT and Index that the query cost would be reduced 99.91% from timerons to 13 timerons. The file mqt1.sql contains the DDL to create the recommended MQT and Index, modified to use meaningful names and the use the TP1SMS table space for the new MTQ. The contents are as follows: -- LIST OF RECOMMENDED MQTs -- =========================== -- MQT MQT1 can be created as a refresh deferred MQT -- mqt[1], 0.032MB CREATE SUMMARY TABLE MQT1 AS (SELECT Q3.C0 AS "C0", Q3.C1 AS "C1", Q3.C2 AS "C2" FROM TABLE(SELECT Q2.C0 AS "C0", SUM(Q2.C1) AS "C1", COUNT(* ) AS "C2" FROM TABLE(SELECT Q1.ACCT_GRP AS "C0", Q1.BALANCE AS "C1" FROM DB2INST1.ACCT AS Q1) AS Q2 GROUP BY Q2.C0) AS Q3) DATA INITIALLY DEFERRED REFRESH DEFERRED IN TP1SMS ; COMMIT WORK ; REFRESH TABLE MQT1 ; COMMIT WORK ; LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], 0.044MB CREATE INDEX MQTIX1 ON MQT1 ("C0" ASC, "C1" DESC) ALLOW REVERSE SCANS ; COMMIT WORK ; RUNSTATS ON TABLE DB2INST1.MQT1 and INDEXES ALL ; COMMIT WORK ; In the terminal session, issue the command: db2 -tvf mqt1.sql 8-18 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

179 V Student Exercises EXempty 5. Run the ACCT table summary query again now that the Materialized Query Table, TP1SUM has been created. The SET CURRENT REFRESH AGE SQL statement must be used to inform the optimizer that this query can tolerate noncurrent data. This is necessary because the Materialized Query Table, MQT1, was created with the REFRESH DEFERRED option and the contents could be old data. Check the read statistics when the query completes. In the terminal session, issue the commands: db2 terminate db2 connect to tp1 db2 reset monitor all db2 set current REFRESH AGE ANY db2 set current explain mode YES db2 set current explain snapshot YES Run the query using the file lab8sum.sql. db2 -tvf lab8sum.sql Collect the database statistics with a GET SNAPSHOT command to and use the UNIX grep command to get the counters for reads. db2 get snapshot for database on tp1 grep -i read The output will look similar to: Buffer pool data logical reads = 276 Buffer pool data physical reads = 74 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Asynchronous pool data page reads = 0 Buffer pool index logical reads = 150 Buffer pool index physical reads = 47 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Asynchronous pool index page reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Asynchronous pool xda page reads = 0 Total buffer pool read time (milliseconds) = 612 Total elapsed asynchronous read time = 0 Asynchronous data read requests = 0 Asynchronous index read requests = 0 Asynchronous xda read requests = 0 Unread prefetch pages = 0 Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-19

180 Student Exercises 6. Direct reads = 122 Direct read requests = 14 Direct reads elapsed time (ms) = 152 Rows read = 57 Log pages read = 0 Log read time (sec.ns) = Number read log IOs = 0 The query should have completed much faster than before. The snapshot reports show much smaller counts for logical and physical reads for data and index. Only a few rows needed to be read to produce the result. The query is now using the index on the MQT to return the result. Format the explain table data for the last statement into a report. db2exfmt -1 -d tp1 -o lab8mqt2.txt Use the UNIX vi editor to view the explain report. vi lab8mqt2.txt Locate the Access Plan section. The output will look similar to: Access Plan: Total Cost: Query Degree: 1 Rows RETURN ( 1) Cost I/O 51 IXSCAN ( 2) INDEX: INST411 MQTIX1 The Explain report shows that the query will now access the index MQTIX1 using an index scan rather than performing a table scan and sort of the large ACCT table, resulting in a very low estimated cost DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

181 V Student Exercises EXempty Locate the Extended Diagnostic Information section of the explain report. The output will look similar to: Extended Diagnostic Information: Diagnostic Identifier: 1 Diagnostic Details: EXP0148W The following MQT or statistical view was considered in query matching: "INST411 "."MQT1". Diagnostic Identifier: 2 Diagnostic Details: EXP0149W The following MQT was used (from those considered) in query matching: "INST411 "."MQT1". These messages show that the MQT, INST411.MQT1, was considered and selected used to generate the current access plan. If the MQT was not used, there would be a message explaining why it was not selected. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-21

182 Student Exercises Section 3 - Using a Range Partitioned Table to reduce query costs for large tables 1. The HISTORY table with transactions could grow very large over time. A range partitioned table is designed to hold large amounts of data, spread over multiple tablespaces. It would also offer the function to attach and detach data partitions to roll in transactions or roll out transactions. A range partitioned table will be created to divide the 100 bank branches into 5 different data partitions, each with 20 banks. Each data partition will be assigned to a different table space. The indexes will be assigned to another tablespace. Use the command file tstablepart.ddl to create the necessary tablespace. Automatic Storage will be used to manage these tablespaces. The command file crhistpart.ddl to create the new table. In the terminal session, issue the commands: db2 connect to tp1 db2 tvf tstablepart.ddl The output will look similar to the following: create tablespace tshistp1 managed by automatic storage initialsize 10 M DB20000I The SQL command completed successfully. create tablespace tshistp2 managed by automatic storage initialsize 10 M DB20000I The SQL command completed successfully. create tablespace tshistp3 managed by automatic storage initialsize 10 M DB20000I The SQL command completed successfully. create tablespace tshistp4 managed by automatic storage initialsize 10 M DB20000I The SQL command completed successfully. create tablespace tshistp5 managed by automatic storage initialsize 10 M DB20000I The SQL command completed successfully. create tablespace tshistix managed by automatic storage initialsize 20 M DB20000I The SQL command completed successfully. db2 tvf crhistpart.ddl The output will look similar to the following: CREATE TABLE INST411.HISTORYPART ( ACCT_ID INTEGER NOT NULL, TELLER_ID SMALLINT NOT NULL, BRANCH_ID SMALLINT NOT NULL, BALANCE DECIMAL(15,2) NOT NULL, DELTA INTEGER NOT NULL, PID INTEGER NOT NULL, TSTMP TIMESTAMP NOT NULL WITH DEFAULT, ACCTNAME CHAR(20) NOT NULL, TEMP CHAR(6) NOT NULL ) IN TSHISTP1, TSHISTP2, TSHISTP3, TSHISTP4, TSHISTP5 INDEX IN TSHISTIX PARTITION BY RANGE (BRANCH_ID) (STARTING FROM (1) ENDING (100) EVERY (20) ) 8-22 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

183 V Student Exercises EXempty DB20000I The SQL command completed successfully. CREATE INDEX INST411.HISTPIX1 ON INST411.HISTORYPART (TELLER_ID) DB20000I The SQL command completed successfully. CREATE INDEX INST411.HISTPIX2 ON INST411.HISTORYPART (BRANCH_ID) DB20000I The SQL command completed successfully. Now load data into the new table using the load utility. In the terminal session, issue the commands: db2 load from histdist.ixf of ixf replace into historypart Use the command file partstat.cmd to collect the catalog statistics db2 tvf partstat.cmd Use the describe command to show the data partitions for the table inst411.historypart. db2 describe data partitions for table historypart show detail The output will look similar to the following: PartitionId Inclusive (y/n) Inclusive (y/n) Low Value High Value Y 1 N 21 1 Y 21 N 41 2 Y 41 N 61 3 Y 61 N 81 4 Y 81 Y record(s) selected. PartitionId PartitionName TableSpId PartObjId LongTblSpId AccessMode Status PART F 1 PART F 2 PART F 3 PART F 4 PART F 2. 5 record(s) selected. This provides a summary of the data ranges for this table and shows which tablespace ID is assigned to each data partition. Run the first query, in the file tpart1.sql. Use the command file snaptbsio.sql to show the I/O counts for each tablespace. Use db2expln to produce a simple access plan for this query. The SQL text is the following: select * from historypart where branch_id between 11 and 60 Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-23

184 Student Exercises In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 db2 connect to tp1 db2 -tvf tpart1.sql grep selected There should have been rows selected. db2 -tvf snaptbsio.sql The output will look similar to the following: SELECT POOL_DATA_P_READS as DATA_Reads, POOL_INDEX_P_READS as INDEX_Reads, POOL_DATA_WRITES, substr(tbsp_name,1,16) as Table_space from sysibmadm.snaptbsp DATA_READS INDEX_READS POOL_DATA_WRITES TABLE_SPACE SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI SYSTOOLSPACE SYSTOOLSTMPSPACE TSHISTP TSHISTP TSHISTP TSHISTP TSHISTP TSHISTIX 15 record(s) selected. This shows that the first three tablespaces, TSHISTP1, TSHISTP2 and TSHISTP3 had significant reads. There are some I/Os for other tablespaces, but these were reads performed data database startup time. Now run db2expln to generate an explain report for the query. db2expln d tp1 f tpart1.sql g I z \; -o lab8part1.txt The output will look similar to: Statement: select * from historypart where branch_id between 11 and DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

185 V Student Exercises EXempty Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.HISTORYPART ID = -6, #Columns = 9 Data-Partitioned Table Data Partition Elimination Info: Range 1: #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 60 Active Data Partitions: 0-2 Relation Scan Prefetch: Eligible Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 2 Return Data to Application #Columns = 9 Return Data Completion End of section Optimizer Plan: RETURN ( 1) TBSCAN ( 2) Table: INST411 HISTORYPART The explain report shows that a table scan will be used to produce the query result. The report contains the following information relative to data partition elimination. Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-25

186 Student Exercises 3. Data-Partitioned Table Data Partition Elimination Info: Range 1: #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 60 Active Data Partitions: 0-2 Relation Scan This shows that the first three data partitions will be accessed (0-2), which matches the query predicate branch_id between 11 and 60'. The last two data partitions will not be accessed. That matches the tablespace I/O statistics reported. Run the next query, in the file tpart2.sql Use the command file snaptbsio.sql to show the I/O counts for each tablespace. Use db2expln to produce a simple access plan for this query. The SQL text is the following: select * from historypart where branch_id between 11 and 60 and teller_id between 800 and 810 This query adds another predicate to the previous query to only return rows with a teller_id value between 800 and 810. In the terminal session, issue the commands: db2 terminate db2 connect to tp1 db2 -tvf tpart2.sql grep selected There should have been 2202 rows selected. db2 -tvf snaptbsio.sql The output will look similar to the following: SELECT POOL_DATA_P_READS as DATA_Reads, POOL_INDEX_P_READS as INDEX_Reads, POOL_DATA_WRITES, substr(tbsp_name,1,16) as Table_space from sysibmadm.snaptbsp DATA_READS INDEX_READS POOL_DATA_WRITES TABLE_SPACE SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI SYSTOOLSPACE SYSTOOLSTMPSPACE 8-26 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

187 V Student Exercises TSHISTP1 EXempty TSHISTP TSHISTP TSHISTP TSHISTP TSHISTIX 15 record(s) selected. This shows again that the first three tablespaces, TSHISTP1, TSHISTP2 and TSHISTP3 had significant read counts, but fewer reads than before. This would indicate that a table scan is not being performed. Now run db2expln to generate an explain report for the query. db2expln d tp1 f tpart2.sql g I z \; -o lab8part2.txt The output will look similar to: Statement: select * from historypart where branch_id between 11 and 60 and teller_id between 800 and 810 Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Access Table Name = INST411.HISTORYPART ID = -6, Index Scan: Name = INST411.HISTPIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) #Columns = 0 Data-Partitioned Table Data Partition Elimination Info: Range 1: #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 60 Active Data Partitions: 0-2 #Key Columns = 1 Start Key: Inclusive Value 1: 800 Stop Key: Inclusive Value Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-27

188 Student Exercises 1: 810 Index-Only Access Index Prefetch: Eligible 16 Isolation Level: (null) Lock Intents Table: Intent None Row : None Sargable Index Predicate(s) Insert Into Sorted Temp Table ID = t1 #Columns = 1 #Sort Key Columns = 1 Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 16 Piped Duplicate Elimination Sorted Temp Table Completion ID = t1 List Prefetch Preparation Access Table Name = INST411.HISTORYPART ID = -6, #Columns = 9 Data-Partitioned Table All data partitions will be accessed Fetch Using Prefetched List Prefetch: 2455 Pages Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 4 Return Data to Application #Columns = 9 Return Data Completion End of section Optimizer Plan: RETURN ( 1) FETCH (----) 8-28 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

189 V Student Exercises EXempty / \ RIDSCN Table: ( 3) INST411 HISTORYPART SORT ( 4) IXSCAN ( 5) / \ Index: Table: INST411 INST411 HISTPIX1 HISTORYPART 4. The explain report shows that an index scan will be used. The index INST411.HISTPIX1 is on the teller_id column, so an index scan is used to find the rows that match the predicate teller_id between 800 and 810'. This index has pointers to all data partitions, but the optimizer put in the access plan the following information: Active Data Partitions: 0-2 This means that each index entry will check the two byte partition ID of the row, so that only rows on data partitions 0, 1 and 2 will be accessed. This is done because of the predicate branch_id between 11 and 60'. The last two data partitions will not be accessed. That matches the tablespace I/O statistics reported. Run the next query, in the file tpart3.sql Use the command file snaptbsio.sql to show the I/O counts for each tablespace. Use db2expln to produce a simple access plan for this query. The SQL text is the following: select * from historypart where branch_id between 11 and 20 and teller_id > 800 This query selects a smaller range of branch_id values than the previous query, but includes a larger range of teller_id values, those with a teller_id greater then 800, which would be about 20% of all 1000 tellers. In the terminal session, issue the commands: db2 terminate db2 connect to tp1 db2 -tvf tpart3.sql grep selected There should have been 66,888 rows selected. db2 -tvf snaptbsio.sql Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-29

190 Student Exercises The output will look similar to the following: DATA_READS INDEX_READS POOL_DATA_WRITES TABLE_SPACE SYSCATSPACE TEMPSPACE USERSPACE TP1SMS TP1DMSH TP1DMSAD TP1DMSAI SYSTOOLSPACE SYSTOOLSTMPSPACE TSHISTP TSHISTP TSHISTP TSHISTP TSHISTP TSHISTIX 15 record(s) selected. This report shows that only the first data tablespace, TSHISTP1 had a large number of reads. The index tablespace, TSHISTIX shows a larger number of index pages read. Now run db2expln to generate an explain report for the query. db2expln d tp1 f tpart3.sql g I z \; -o lab8part3.txt The output will look similar to: Statement: select * from historypart where branch_id between 11 and 20 and teller_id > 800 Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Index ANDing Optimizer Estimate of Set Size: Index ANDing Bitmap Build Using Row IDs Access Table Name = INST411.HISTORYPART ID = -6, Index Scan: Name = INST411.HISTPIX1 ID = 1 Regular Index (Not Clustered) Index Columns: 1: TELLER_ID (Ascending) 8-30 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

191 V Student Exercises EXempty #Columns = 0 Data-Partitioned Table Data Partition Elimination Info: Range 1: #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 20 Active Data Partitions: 0 #Key Columns = 1 Start Key: Exclusive Value 1: 800 Stop Key: End of Index Index-Only Access Index Prefetch: Eligible 297 Isolation Level: (null) Lock Intents Table: Intent None Row : None Index ANDing Bitmap Probe Using Row IDs Access Table Name = INST411.HISTORYPART ID = -6, Index Scan: Name = INST411.HISTPIX2 ID = 2 Regular Index (Not Clustered) Index Columns: 1: BRANCH_ID (Ascending) #Columns = 0 Data-Partitioned Table Data Partition Elimination Info: Range 1: #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 20 Active Data Partitions: 0 #Key Columns = 1 Start Key: Inclusive Value 1: 11 Stop Key: Inclusive Value 1: 20 Index-Only Access Index Prefetch: Eligible 892 Isolation Level: (null) Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-31

192 Student Exercises Lock Intents Table: Intent None Row : None Insert Into Sorted Temp Table ID = t1 #Columns = 1 #Sort Key Columns = 1 Key 1: (Ascending) Sortheap Allocation Parameters: #Rows = Row Width = 16 Piped Duplicate Elimination List Prefetch Preparation Access Table Name = INST411.HISTORYPART ID = -6, #Columns = 9 Data-Partitioned Table All data partitions will be accessed Fetch Using Prefetched List Prefetch: 1954 Pages Lock Intents Table: Intent Share Row : Next Key Share Sargable Predicate(s) #Predicates = 3 Return Data to Application #Columns = 9 Return Data Completion End of section Optimizer Plan: RETURN ( 1) FETCH (----) / \ RIDSCN Table: ( 3) INST411 HISTORYPART SORT ( 4) 8-32 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

193 V Student Exercises EXempty IXAND ( 5) /----/ \---\ IXSCAN IXSCAN ( 6) ( 7) / \ / \ Index: Table: Index: Table: INST411 INST411 INST411 INST411 HISTPIX1 HISTORYPART HISTPIX2 HISTORYPART 5. The explain report shows that two index scans will be used. The index anding operation, IXAND (5) will be used to narrow the number of rows that will be retrieved from the data pages during the Fetch operation. The optimizer's row estimate of 61,702 is relatively close to the actual query result, which was 66,888. Each index scan shows the following characteristic: Active Data Partitions: 0 Both index scans will therefore bypass the rows from data partitions 1-4. This is done because of the predicate branch_id between 11 and 20'. That matches the tablespace I/O statistics reported. Drop the tablespaces for the range partitioned table using the command file lab8droppart.ddl. Close all the applications now and deactivate the TP1 database. In the terminal session, issue the commands: db2 connect to tp1 db2 tvf lab8droppart.ddl db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 8. Complex SQL Performance 8-33

194 Student Exercises 8-34 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

195 V Student Exercises EXempty Exercise 9. Using DB2 Utilities for Performance What This Exercise Is About This exercise is an online lab which allows the student to use the DB2 utilities to analyze and improve query performance. The DB2BATCH tool will be used to gather performance statistics. The REORG command will be used to change the sequence of rows in a table to improve query efficiency. The RUNSTATS command will be used update the DB2 Catalog statistics to provide accurate input to the DB2 Optimizer. The REORGCHK command will be used to report on index efficiency. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2BATCH tool to run a set of SQL queries and collect statistics for performance analysis. Use the REORG utility to reorganize a table in a different clustered sequence based on an index. Update the DB2 catalog statistics using the RUNSTATS command to reflect changes in tables or indexes. Use sampled statistics options of RUNSTATS to collect catalog statistics with reduced system resources. Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-1

196 Student Exercises Exercise Instructions Introduction In this exercise, you will be using DB2 utilities to collect performance statistics and improve the performance characteristics for a set of SQL statements. The DB2BATCH utility will be run to collect the initial performance data and then rerun after each change to measure the effects of the change. In addition to collecting SNAPSHOT statistics for each SQL statement executed, DB2BATCH will report the elapsed times and CPU utilization. A new index will be created for the ACCT to allow accounts to retrieved based on the ACCT_GRP value without a table scan. The REORG utility will be used to reorganize the ACCT using the new index and the RUNSTATS command will be used to update the DB2 catalog statistics. It is common to focus on elapsed time as a measure of good or poor performance and in some cases the elapsed time is critical to achieve a performance objective, like processing an application according to an operations schedule. In this exercise elapsed times of several queries may be reported as very different when the amount of work each requires is very similar. This shows that it is sometimes necessary to look various performance statistics to see the whole picture. The RUNSTATS utility will be used to collect sampled statistics for a table to improve the accuracy of information used during query optimization at a reduced system resource cost. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown. If a different level of DB2 UDB product is used for this exercise, some of the processing operations selected by the optimizer could also be changed. 9-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

197 V Student Exercises EXempty Section 1 - Use db2batch to Run a Sequence of SQL Queries to Collect Performance Statistics 1. The db2batch utility provides a simple method for gathering performance data for one or more queries. The file batch1.sql contains a set of five SQL queries that will be run as follows: Query 1: Joins TELLER and HISTORY tables for a range of BRANCH_IDs. SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID BETWEEN 20 AND 29 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC ; Query 2: Lists HISTORY transactions for a range of TELLER-IDs. SELECT ACCT_ID, ACCTNAME, TELLER_ID, BRANCH_ID, BALANCE FROM HISTORY WHERE TELLER_ID BETWEEN 100 AND 199; Query 3: ACCT Summary Report for selected ACCT_GRPs. SELECT ACCT_GRP, SUM(BALANCE) FROM ACCT WHERE ACCT_GRP BETWEEN 100 AND 150 GROUP BY ACCT_GRP; Query 4: Join ACCT,TELLER,HISTORY information for Groups of Accounts. SELECT ACCT.ACCT_ID, ACCT.NAME, TELLER.TELLER_ID, TELLER.TELLER_NAME, HISTORY.BRANCH_ID, HISTORY.BALANCE, HISTORY.PID FROM ACCT AS ACCT, TELLER AS TELLER, HISTORY AS HISTORY WHERE ACCT.ACCT_ID = HISTORY.ACCT_ID AND ACCT.ACCT_GRP BETWEEN 400 AND 500 AND HISTORY.TELLER_ID = TELLER.TELLER_ID ORDER BY HISTORY.PID ASC ; Query 5: Partial NAME,ADDRESS List from ACCT. SELECT NAME, ADDRESS FROM ACCT WHERE ACCT_GRP < 50 ORDER BY NAME ; The file also contains several DB2BATCH options as follows: --#SET ROWS_OUT 5 This tells DB2BATCH to fetch all of the result rows, but only list the first 5. --#SET PERF_DETAIL 2 This tells DB2BATCH to produce a set of basic performance statistics for each query. From your Linux workstation, start a terminal session. Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-3

198 Student Exercises In the terminal session, issue the commands: cd $HOME/bin db2 activate db tp1 db2 connect to tp1 Invoke db2batch to run the SQL statements in the file batch1.sql. Use an optimization level of 5 and generate explain data for each query. Save the output to a file, batch1.out. db2batch -d tp1 -f batch1.sql -i complete -o o 5 e 2 > batch1.out Use db2exfmt to format a report for the last query executed by db2batch, Query 5. db2exfmt -1 -d tp1 -o expbat1.txt Use the UNIX vi editor to view the db2batch report. vi batch1.out The db2batch output has a summary report at the bottom that will look similar to the following: Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Statement Statement Statement Statement Statement Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Look at the report sections for Query 3 and Query 5 record the following information: Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads Buffer pool index physical reads 9-4 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

199 V Student Exercises EXempty Example Output Report Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads Buffer pool index physical reads Both of these queries have large numbers for data logical and physical reads. In the examples above, the elapsed times were relatively short for the large number of physical reads, because the database had enough memory to keep most of the file pages in the buffer pools and some may have been read from the operating system's file cache. Your results for elapsed times may have been significantly different depending on your system. The SQL statements for Query 3, Query 4, and Query 5 all required table scans of the large ACCT table to produce the query results. All three queries were reporting on specific ACCT_GRP ranges in the ACCT table. Create a new index of the ACCT table on the ACCT_GRP column to allow quicker access to these subsets of the account information. The file cracctix.ddl has the SQL statement to create the new index. Use the RUNSTATS utility to collect statistics on the new index. In the terminal session, issue the commands: db2 -tvf cracctix.ddl db2 runstats on table inst411.acct for index inst411.acctgrp Use db2batch to collect new performance statistics for the same SQL statements in the file batch1.sql. Use an optimization level of 5 and generate explain data for each query. Save the output to a file batch2.out. In the terminal session, issue the command: db2batch -d tp1 -f batch1.sql -i complete -o o 5 e 2 > batch2.out Use db2exfmt to format a report for the last query executed by db2batch, Query 5. db2exfmt -1 -d tp1 -o expbat2.txt Use the UNIX vi editor to view the db2batch report. vi batch2.out The db2batch output has a summary report at the bottom that will look similar to the following: * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Statement Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-5

200 Student Exercises Statement Statement Statement Statement Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Look at the report sections for Query 3 and Query 5 record the following information: Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads Buffer pool index physical reads Example Output Report Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads Buffer pool index physical reads The addition of the index may have reduced elapsed times. Note that there was an increased count for index logical reads so the new index has changes by the access plan for the query. Use REORGCHK to compare the statistics for the two indexes on the ACCT table. Use the REORGCHK command to create a report for the acct table. In the terminal session, issue the commands: db2 reorgchk current statistics on table inst411.acct > stats1.txt vi stats1.txt The reorgchk output for the indexes will contain information similar to the following: SCHEMA.NAME INDCARD LEAF ELEAF LVLS NDEL KEYS...F4 F5 F6 F7 F8 REORG Table: INST411.ACCT 9-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

201 V Student Exercises EXempty 5. Index: INST411.ACCTGRP *---- Index: INST411.ACCTINDX In this report, the F4 calculated value shows the cluster ratio for each index. The ACCT table is very clustered when accessed by the ACCTINDX index, but very unclustered when accessed using the ACCTGRP index. The reporting queries access groups of rows by ACCT_GRP value. The transaction applications look for a single row by ACCT_ID. Reorganizing the ACCT table using the ACCTGRP index should allow both types of applications efficient access to the ACCT data. Use the REORG utility to reorganize the ACCT table using the ACCTGRP index. The REORG utility will use the temporary table space TEMPSPACE1. Increase the size of the IBMDEFAULT buffer pool to improve REORG performance. In the terminal session, issue the commands: db2 alter bufferpool ibmdefaultbp immediate size 5000 db2 reorg table acct index acctgrp use tempspace1 resetdictionary Wait for the reorg to complete. Collect new statistics for the ACCT table and both indexes. db2 runstats on table inst411.acct and indexes all Use the REORGCHK command to create a new report for the acct table. db2 reorgchk current statistics on table inst411.acct > stats2.txt vi stats2.txt The reorgchk output for the indexes will look similar to the following: 6. SCHEMA.NAME INDCARD LEAF ELEAF LVLS NDEL KEYS...F4 F5 F6 F7 F8 REORG Table: INST411.ACCT Index: INST411.ACCTGRP *---- Index: INST411.ACCTINDX Now the ACCT table is very clustered when accessed using the ACCTGRP index. In this example the ACCTINDX index is not clustered, but in most cases the clustering for non-clustered indexes is unpredictable. Use db2batch to collect new performance statistics for the same SQL statements in the file batch1.sql. Use an optimization level of 5 and generate explain data for each query. Save the output to a file batch3.out. In the terminal session, issue the command: db2batch -d tp1 -f batch1.sql -i complete -o o 5 e 2 > batch3.out Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-7

202 Student Exercises Use db2exfmt to format a report for the last query executed by db2batch, Query 5. db2exfmt -1 -d tp1 -o expbat3.txt Use the UNIX vi editor to view the db2batch report. vi batch3.out The db2batch output has a summary report at the bottom that will look similar to the following: * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Statement Statement Statement Statement Statement Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Look at the report sections for Query 3 and Query 5 record the following information: Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads Buffer pool index physical reads Example Output Report Report Statistic Query 3 Query 5 Elapsed Time Buffer pool data logical reads Buffer pool data physical reads Buffer pool index logical reads DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

203 V Student Exercises EXempty Buffer pool index physical reads Both of these queries now have much smaller numbers for data logical and physical reads. The statistics show that the queries can now retrieve the same groups of accounts with far fewer page references after the table reorganization. Each time db2batch was run, the option '-o e 2' was used to store explain information for each query in the explain tables. Running db2exfmt with the default options after each db2batch test generated an explain report for the last query, Query 5. Look at the three saved explain reports to see how the optimizer costs changed during the performance tests. The reports are in the files expbat1.txt. expbat2.txt and expbat3.txt. Record the information from the RETURN operation in each file into the following table: Description No ACCT_GRP Index Unclustered ACCT_GRP Index Clustered ACCT_GRP Index Explain File expbat1.txt expbat2.txt expbat3.txt Cumulative Total Cost Cumulative I/O Cost Description No ACCT_GRP Index Unclustered ACCT_GRP Index Clustered ACCT_GRP Index Explain File expbat1.txt expbat2.txt expbat3.txt Cumulative Total Cost Cumulative I/O Cost For Query 5, using the new ACCTGRP index on was only slightly less costly than the table scan until the table was reorganized. In the example above, the clustered ACCT_GRP index reduced the query cost by 91%. Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-9

204 Student Exercises Section 2 - Using the TABLESAMPLE Option In this exercise, we're going to use the TABLESAMPLE option of the RUNSTATS utility to collect table statistics using less system resources The lack of accurate statistics can cause DB2 optimizer to inaccurately estimate query cardinalities and can lead to inefficient access plans. The gathering of table statistics on large tables can consume large amounts of processing and I/O capacity. In some cases, the use of sampling options of the RUNSTATS utility may provide sufficient statistical input to the optimizer at a reduced cost. Drop and recreate the table HIST2, to hold the HISTORY table transactions. The new table will not have any catalog statistics. In the terminal session, issue the commands: db2 terminate db2 deactivate db tp1 db2 CONNECT TO TP1 db2 drop table hist2 db2 -tvf hist2tab.ddl Use db2expln to get estimated cardinality of a query that joins the HIST2 table to the teller table. The query is in the file lab61.sql and contains the following: SELECT HIST2.BRANCH_ID, TELLER.TELLER_NAME, HIST2.ACCTNAME, HIST2.ACCT_ID, HIST2.BALANCE FROM HIST2 AS HIST2, TELLER AS TELLER WHERE HIST2.TELLER_ID =TELLER.TELLER_ID AND HIST2.BRANCH_ID between 10 and 70 and hist2.teller_id < 200 ORDER BY HIST2.BRANCH_ID ASC, HIST2.ACCT_ID ASC ; In the terminal session, issue the commands: db2expln -d tp1 -f lab61.sql -z \; -g -o lab91.txt vi lab91.txt Find the following: Estimated Cost = ( ) Estimated Cardinality = ( ) 3. Use the RUNSTATS utility with a TABLESAMPLE option to collect statistics on 20% of the pages in the table HIST2. When the RUNSTATS is completed, use db2expln to get updated estimates for query cost and cardinality. In the terminal session, issue the commands: db2 CONNECT TO TP DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

205 V Student Exercises EXempty db2 ' runstats on table inst411.hist2 tablesample system(20) ' db2expln -d tp1 -f lab61.sql -z \; -g -o lab92.txt vi lab92.txt Find the following: Estimated Cost = ( ) Estimated Cardinality = ( ) Use the db2batch to get the actual count of rows that would result from running the query lab51.sql. In the terminal session, issue the command: db2batch -d tp1 -f lab61.sql -o r 0 The output should include information similar to the following: * SQL Statement Number 1: SELECT HIST2.BRANCH_ID, TELLER.TELLER_NAME, HIST2.ACCTNAME, HIST2.ACCT_ID, HIST2.BALANCE FROM HIST2 AS HIST2, TELLER AS TELLER WHERE HIST2.TELLER_ID =TELLER.TELLER_ID AND HIST2.BRANCH_ID between 10 and 70 and hist2.teller_id < 200 ORDER BY HIST2.BRANCH_ID ASC, HIST2.ACCT_ID ASC ; BRANCH_ID TELLER_NAME ACCTNAME ACCT_ID BALANCE * row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds Find the following: Number of rows retrieved = (22945) In the example above the actual count of 22,945 is about 5% less than the optimizer's estimate with the sampled statistics, but 344% larger than the estimate without statistics. Close all the applications now and deactivate the TP1 database. In the terminal session, issue the commands: db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 9. Using DB2 Utilities for Performance 9-11

206 Student Exercises 9-12 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

207 V Student Exercises EXempty Exercise 10. Monitoring Database Health and Activity What This Exercise Is About This exercise is an online lab which allows the student to use the DB2 Health Center and Activity Monitor tools to view the status of an active DB2 database. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 Health Center to check an active DB2 database for alert status indicators and get recommendations for actions to take if an alert condition occurs. Use the DB2 GET HEALTH SNAPSHOT command to view various health indicators for DB2 databases and table spaces. Use the Activity Monitor to report on the statistics for the Dynamic SQL statement cache and for current SQL activity. Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-1

208 Student Exercises Exercise Instructions Introduction In this exercise, you will be using the Health Center, Activity Monitor tools to view the status of an active DB2 database. First, the DB2BATCH utility will be used to run several queries that perform large sort operations. The large sorts will cause overflows of the sortheap. The Health Center will be used to check the status of the TP1 database and show the high percentage of sort heap overflows. The GET HEALTH SNAPSHOT command will be used to check the health indicators for the TP1 database and for the table spaces in the TP1 database. The Activity Monitor will be used to examine the dynamic SQL statements in the database package cache after db2batch is used to run a series of queries. Note: The examples are shown to help you locate the information, the statistics and other contents in your reports and may vary from the values shown DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

209 V Student Exercises EXempty Section 1 - Use Health Center/Health Monitor to View Status of Active Database 1. Use a DB2 Command window to stop and restart the DB2 Instance. Activate the TP1 database and use DB2BATCH to start a long running query that performs a large sort operation. The Alert configuration will be updated to make sure sort overflow checking is activated. From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME/bin db2 update alert cfg for database on tp1 using db.spilled_sorts set alarm 50, warning 30, thresholdschecked yes db2 terminate db2 force application all db2stop db2start db2 activate db TP1 db2 connect to tp1 Use DB2BATCH to execute the queries in the command file batchover.sql. When the query processing completes, start the Health Center to view the status of the database TP1. db2batch -d tp1 -f batchover.sql The first query will take some time to complete, wait for the following messages to appear. * Timestamp: Sun Nov :18:56 EST #SET ROWS_OUT #SET PERF_DETAIL * Comment: " NAME,ADDRESS List from ACCT" * SQL Statement Number 1: SELECT * FROM ACCT ORDER BY NAME ; Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-3

210 Student Exercises ACCT_ID NAME ACCT_GRP BALANCE ADDRESS TEMP <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 3127 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 4112 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 7480 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 8681 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > * row(s) fetched, 5 row(s) output. * Elapsed Time is: seconds * SQL Statement Number 2: SELECT * FROM ACCT ORDER BY NAME desc ; ACCT_ID NAME ACCT_GRP BALANCE ADDRESS TEMP <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 3127 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 4112 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 7480 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > 8681 <--20 BYTE STRING--> < BYTE STRING > < BYTE STRING > * row(s) fetched, 5 row(s) output. * Elapsed Time is: seconds * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Statement Statement * Total Entries: 2 * Total Time: seconds * Minimum Time: seconds * Maximum Time: seconds * Arithmetic Mean Time: seconds * Geometric Mean Time: seconds DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

211 V Student Exercises EXempty 2. * Timestamp: Sun Nov :19:15 EST Start the DB2 Health Center to show the status of the TP1 database. Start a second terminal session for running the DB2 Health Center by issuing the following command: db2hc Expand the Instance inst411 to show the TP1 Database. Set the Refresh time in the upper right hand corner to 1 Minute. Wait for the Health Center to detect the sort overflow status for the TP1 database. When the sort overflow indicator is detected by the Health Center, it will be shown similar to the following example. 3. Since the DB2BATCH processing was the only application that has executed since the TP1 database became active, the status for Percentage of Sorts That Overflowed is high, and an alarm is indicated. Use the GET SNAPSHOT FOR HEALTH command to retrieve the status of all of the DB2 Health indicators for the TP1 database. Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-5

212 Student Exercises In the terminal session, issue the commands: To get a more detailed report, use the SHOW DETAIL option and save the result to a file for review. In the terminal session, issue the commands: db2 get health snapshot for database on tp1 show detail > healthtp1.txt vi healthtp1.txt The report will contain information similar to the following: Database Health Snapshot Snapshot timestamp = 11/26/ :39: Database name = TP1 Database path = /database/inst411/node0000/sql00001/ Input database alias = TP1 Operating system running at database server= LINUX Location of the database = Local Database highest severity alert state = Alarm Health Indicators: Indicator Name = db.db_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Formula = 0 History Entry "1": Value = 0 Evaluation timestamp = 11/26/ :29: Alert state = Normal Formula = 0 History Entry "2": Value = 0 Evaluation timestamp = 11/26/ :24: Alert state = Normal Formula = 0 History Entry "3": Value = 0 Evaluation timestamp = 11/26/ :19: Alert state = Normal Formula = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

213 V Student Exercises EXempty Indicator Name = db.spilled_sorts Value = 67 Unit = % Evaluation timestamp = 11/26/ :38: Alert state = Alarm Formula = (((2-0) / ((2-0) + 1)) * 100) Additional information = The sort heap (sortheap) database configuration parameter is set to "2500". The high watermark for private sort memory is "2500". The high watermark for shared sort memory is "0" History Entry "1": Value = 67 Unit = % Evaluation timestamp = 11/26/ :32: Alert state = Alarm Formula = (((2-0) / ((2-0) + 1)) * 100) Additional information = The sort heap (sortheap) database configuration parameter is set to "2500". The high watermark for private sort memory is "2500". The high watermark for shared sort memory is "0" History Entry "2": Value = 67 Unit = % Evaluation timestamp = 11/26/ :26: Alert state = Alarm Formula = (((2-0) / ((2-0) + 1)) * 100) Additional information = The sort heap (sortheap) database configuration parameter is set to "2500". The high watermark for private sort memory is "2500". The high watermark for shared sort memory is "0" History Entry "3": Value = 67 Unit = % Evaluation timestamp = 11/26/ :20: Alert state = Alarm Formula = (((2-0) / ((2-0) + 1)) * 100) Additional information = The sort heap (sortheap) database configuration parameter is set to "2500". The high watermark for private sort memory is "2500". The high watermark for shared sort memory is "0" Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-7

214 Student Exercises Indicator Name = db.log_util Value = 0 Unit = % Evaluation timestamp = 11/26/ :34: Alert state = Normal Formula = ((0 / ( )) * 100) Additional information = The following are the related database configuration parameter settings: logprimary is "13", logsecond is "30", and logfilsiz is "2000". The application with the oldest transaction is "15". History Entry "1": Value = 0 Unit = % Evaluation timestamp = 11/26/ :24: Alert state = Normal Formula = ((0 / ( )) * 100) Additional information = The following are the related database configuration parameter settings: logprimary is "13", logsecond is "30", and logfilsiz is "2000". The application with the oldest transaction is "15". Indicator Name = db.db_heap_util Value = 31 Unit = % Evaluation timestamp = 11/26/ :34: Alert state = Normal Formula = (( / ) * 100) History Entry "1": Value = 31 Unit = % Evaluation timestamp = 11/26/ :29: Alert state = Normal Formula = (( / ) * 100) History Entry "2": Value = 31 Unit = % Evaluation timestamp = 11/26/ :24: Alert state = Normal Formula = (( / ) * 100) History Entry "3": Value = 31 Unit = % Evaluation timestamp = 11/26/ :19: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

215 V Student Exercises EXempty Alert state = Normal Formula = (( / ) * 100) Indicator Name = db.auto_storage_util Value = 13 Unit = % Evaluation timestamp = 11/26/ :34: Alert state = Normal Formula = (( / ) * 100) Additional information = The short term growth rate at which space is filling up on the database storage path filesystems from "11/26/ :34: " to "11/26/ :34: " is "N/A" bytes per second and the long term growth rate from "11/25/ :34: " to "11/26/ :34: " is "N/A" bytes per second. Time to fullness is projected to be "N/A" and "N/A" respectively. History Entry "1": Value = 13 Unit = % Evaluation timestamp = 11/26/ :24: Alert state = Normal Formula = (( / ) * 100) Additional information = The short term growth rate at which space is filling up on the database storage path filesystems from "11/26/ :24: " to "11/26/ :24: " is "N/A" bytes per second and the long term growth rate from "11/25/ :24: " to "11/26/ :24: " is "N/A" bytes per second. Time to fullness is projected to be "N/A" and "N/A" respectively. 4. Use the Health Center to view the recommended actions for the sort overflow condition. Select the health indicator Percentage of Sorts that Overflowed. Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-9

216 Student Exercises Use the menu options Selected with Show Details. 5. Close the Health Center now. Use the GET SNAPSHOT FOR HEALTH command to retrieve the Health status of all of the table spaces the TP1 database. In the terminal session, issue the command: db2 get health snapshot for tablespaces on tp1 more The output will look similar to the following: Tablespace Health Snapshot Snapshot timestamp = 11/26/ :41: Database name = TP1 Database path = /database/inst411/node0000/sql00001/ Input database alias = TP1 Number of accessed tablespaces = 9 Tablespace name Tablespace highest severity alert state = SYSCATSPACE = Normal DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

217 V Student Exercises EXempty Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c cat Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c cat Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = SYSTOOLSPACE = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-11

218 Student Exercises Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c lrg Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c lrg Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = SYSTOOLSTMPSPACE = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c utm Health Indicators: Indicator Name = tsc.tscont_op_status Value = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

219 V Student Exercises EXempty Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c utm Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = TEMPSPACE1 = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c tmp Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c tmp Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-13

220 Student Exercises Tablespace name Tablespace highest severity alert state = TP1DMSAD = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 4 Container Name = /database/inst411/node0000/sql00001/tp1dms/dmsad1 Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /database/inst411/node0000/sql00001/tp1dms/dmsad2 Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /database/inst411/node0000/sql00001/tp1dms/dmsad3 Health Indicators: Indicator Name = tsc.tscont_op_status DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

221 V Student Exercises EXempty Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /database/inst411/node0000/sql00001/tp1dms/dmsad4 Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = TP1DMSAI = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 1 Container Name = /database/inst411/node0000/sql00001/tp1dms/dmsai Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = TP1DMSH = Normal Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-15

222 Student Exercises Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c usr Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c usr Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = TP1SMS = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

223 V Student Exercises EXempty Container Name Health Indicators: = /database/tp1/tp1sms Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = tsc.tscont_util Value = 13 Unit = % Evaluation timestamp = 11/26/ :34: Alert state = Normal Tablespace name Tablespace highest severity alert state = USERSPACE1 = Normal Health Indicators: Indicator Name = ts.ts_op_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Indicator Name = ts.ts_auto_resize_status Value = 0 Evaluation timestamp = 11/26/ :34: Alert state = Normal Number of containers = 2 Container Name = /dbauto/path1/inst411/node0000/tp1/t /c lrg Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal Container Name = /dbauto/path2/inst411/node0000/tp1/t /c lrg Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-17

224 Student Exercises Health Indicators: Indicator Name = tsc.tscont_op_status Value = 1 Evaluation timestamp = 11/26/ :34: Alert state = Normal DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

225 V Student Exercises EXempty Section 3 - Using the Activity Monitor In this exercise, we will use the Activity Monitor to review the performance statistics for an active database. 1. Use the DB2 Command line processor window to stop and restart the Instance db2inst1. Activate the TP1 database and use DB2BATCH to run a set of long running queries. From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME/bin db2 force application all db2 terminate db2stop db2start db2 activate db TP1 Use DB2BATCH to execute the queries in the command file batchmon.sql. When the query processing completes, start the Activity Monitor to view the status of the database TP1. db2batch -d tp1 -f batchmon.sql -o r 0 The queries may take some time to complete, wait for the following messages to appear. * Timestamp: Sun Nov :45:04 EST * Comment: " JOIN TELLER,HISTORY for BRANCH Range" * Comment: " QUERY 1" * SQL Statement Number 1: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID > 60 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC ; BRANCH_ID TELLER_NAME ACCTNAME ACCT_ID BALANCE Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-19

226 Student Exercises * row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds * Comment: " QUERY 2" * Comment: " List HISTORY from Teller Range" * SQL Statement Number 2: SELECT ACCT_ID, ACCTNAME, TELLER_ID, BRANCH_ID, BALANCE FROM HISTORY WHERE TELLER_ID BETWEEN 100 AND 800 order by balance desc ; ACCT_ID ACCTNAME TELLER_ID BRANCH_ID BALANCE * row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds * Comment: " QUERY 3" * Comment: " ACCT Summary Report by ACCT_GRP" * SQL Statement Number 3: SELECT ACCT_GRP, SUM(BALANCE) FROM ACCT WHERE ACCT_GRP BETWEEN 300 and 700 GROUP BY ACCT_GRP; ACCT_GRP * 401 row(s) fetched, 0 row(s) output DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

227 V Student Exercises EXempty * Elapsed Time is: seconds * Comment: " QUERY 4" * Comment: " Join ACCT,TELLER,HISTORY" * SQL Statement Number 4: SELECT ACCT.ACCT_ID, ACCT.NAME, TELLER.TELLER_ID, TELLER.TELLER_NAME, HISTORY.BRANCH_ID, HISTORY.BALANCE, HISTORY.PID FROM ACCT AS ACCT, TELLER AS TELLER, HISTORY AS HISTORY WHERE ACCT.ACCT_ID = HISTORY.ACCT_ID AND ACCT.ACCT_GRP < 400 AND HISTORY.TELLER_ID = TELLER.TELLER_ID ORDER BY HISTORY.PID ASC ; ACCT_ID NAME TELLER_ID TELLER_NAME BRANCH_ID BALANCE PID * row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds * Comment: " QUERY 5" * Comment: " Partial NAME,ADDRESS List from ACCT" * SQL Statement Number 5: SELECT NAME, ADDRESS FROM ACCT WHERE ACCT_GRP < 50 ORDER BY NAME ; NAME ADDRESS * row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-21

228 Student Exercises * SQL Statement Number 6: SELECT COUNT(*) FROM HISTORY ; * 1 row(s) fetched, 0 row(s) output. * Elapsed Time is: seconds * Summary Table: Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output Statement Statement Statement Statement Statement Statement * Total Entries: 6 * Total Time: seconds * Minimum Time: seconds * Maximum Time: seconds * Arithmetic Mean Time: seconds * Geometric Mean Time: seconds * Timestamp: Sun Nov :45:10 EST Start the DB2 Activity Monitor to show the status of the TP1 database. From your Linux workstation, start a terminal session. In a the terminal session, issue the command: db2cc When the Control Center starts, locate and select the TP1 database under All Databases. In the panel on the bottom right portion of the Control Center, click Activity Monitor. Select the TP1 Database in the Instance inst411 for monitoring DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

229 V Student Exercises EXempty Expand the Instance inst411 to show the TP1 Database. Select Next to proceed to selecting a Monitoring Task. Select the monitoring task 'Tuning the dynamic SQL statement cache'. Copyright IBM Corp. 2001, 2006 Exercise 10. Monitoring Database Health and Activity 10-23

230 Student Exercises 3. Select Finish. Select the report 'Dynamic SQL statements in the cache with the largest number of rows read'. Select the SQL statement at the top of the list and choose the menu option Selected and Explain Query to show the access plan using Visual Explain. Exit the Activity Monitor and Close the Control Center application. In the terminal session, deactivate the TP1 database now. In the terminal session, issue the commands: db2 force application all db2 terminate db2 deactivate db TP1 END OF EXERCISE DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

231 V Student Exercises EXempty Exercise 11. Application Performance What This Exercise Is About This exercise is an online lab which allows the student to analyze the performance impact of using different application development techniques, including Static SQL and Dynamic SQL. What You Should Be Able to Do At the end of the lab, you should be able to: Use the DB2 GET SNAPSHOT command to collect database statistics for applications using Static and Dynamic SQL. Analyze the DB2 database statistics to look for package cache and catalog cache utilization. Use the GET SNAPSHOT FOR DYNAMIC SQL report to see the information available about previously executed dynamic SQL statements in the package cache. Use the db2pd command to get information about the static and dynamic SQL usage of the package cache and current application locks. Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-1

232 Student Exercises Database Performance Results Table DB2 Monitor Statistic Static SQL Dynamic SQL Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads Buffer Pool Data Hit Ratio (Calculated) BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio (Calculated) Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written 11-2 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

233 V Student Exercises EXempty Exercise Instructions Introduction In this exercise, you will be monitoring three different application programs that were designed to access the same application tables. The static SQL application SQLTP1ST, will be compared to an application SQLTP1DY that uses all dynamic SQL statements. A third application SQLTP1DS will be run concurrently with the update transactions to perform some read only queries. Next, the application SQLTP1RI that uses a stored procedure, SQLTP1DL, will be measured with the stored procedure running in 'fenced' mode. The stored procedure application will also be measured running 'not fenced' mode. The application tables are currently using row locking, so the ACCT and HISTORY tables will be altered to use table level locking to introduce lock contention for this heavy update application environment so that the effect of lock contention on transaction performance can be measured. Some of the key performance statistics that will be monitored will be: Package cache lookups - The number of times that an application looked for a section or package in the package cache. If this number is large relative to the number of Package Cache inserts, then the static or dynamic SQL can be processed efficiently. Package cache inserts - The total number of times that a requested section was not available for use and had to be loaded into the package cache. Time database waited on locks - This is the total amount of elapsed time that all applications were waiting for a lock within this database. Lock Waits - This monitoring statistic shows the total number of times that applications or connections waited for locks. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown. Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-3

234 Student Exercises Section 1 - Compare Static SQL and Dynamic SQL Versions of an Update Transaction Application 1. The SQLTP1ST application that has been used for the previous MULTI transaction processing was written using static SQL. Another program SQLTP1DY performs the same application function but uses dynamic SQL statements. Run three minute of transactions with each application and record the performance statistics in the results table. The application SQLTP1DS will be used by two of the four MULTI connections, to introduce some read only processing into the transaction processing. The new indexes implemented to improve query performance in the previous labs may impact the transaction rate for the update transactions. The application SQLTP1DS includes the following SQL statement: DECLARE C1 CURSOR FOR SELECT A.ACCT_GRP, SUM(A.BALANCE ) AS ASUM, COUNT(*) AS ACOUNTS FROM ACCT A WHERE ACCT_ID BETWEEN :H00002 AND :H00003 AND ACCT_GRP BETWEEN :H00005 AND :H00006 GROUP BY A.ACCT_GRP FOR READ ONLY From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME/bin db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 db2 -tf tp1bind db2 connect to tp1 Start a second terminal session for running the MULTI application using the configuration file tp1stmix3.cfg, and issue the following commands: cd $HOME/bin multi tp1stmix3.cfg To begin processing transactions, click the RUN button. While the transactions are being processed, check for lock contention using the following db2pd command: db2pd db tp1 locks The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:03: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

235 V Student Exercises EXempty Locks: Address TranHdl Lockname Type Mode Sts Owner 0x D001B Row..X G 6 0x A Row..X G 6 0x C C4BE7A241 Internal P..S G 6 0x13851E C C4BE7A241 Internal P..S G 8 0x138509C Row..X G 8 0x C AFBE9E841 Internal P..S G 9 0x138515D C AFBE9E841 Internal P..S G 7 0x D00A Row..X G 8 0x F Row..X G 6 0x138511B F Row.NS W 0 0x C00A Row..X G 6 0x138507B BA Row..X G 8 0x13851C Row..X G 8 0x13851B Table.IX G 6 0x Table.IX G 8 0x Table.IS G 9 0x Table.IX G 6 0x Table.IX G 8 0x138512A Table.IS G 7 0x Table.IX G 6 0x13850B Table.IX G 8 0x Table.IX G 6 0x13851E Table.IX G 8 You may catch some lock waits, but there should not be much contention at the row level between these applications. A lock wait would be indicated by a W' in the Sts column. The applications are using IX and IS table locks and getting row locks based on the SQL statement processing. Allow the MULTI transactions to complete 3 minutes of processing. What is the Total Count of transactions for the application mixture using the static SQL application? Use the db2pd command to examine the information about the static application packages in the package cache for the database. db2pd db tp1 static > pdstatic.txt The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:04:14 Static Cache: Current Memory Used Total Heap Size Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-5

236 Student Exercises 2. Cache Overflow Flag 0 Number of References Number of Package Inserts 4 Number of Section Inserts 7 Packages: Address Schema PkgName Version UniqueID NumSec UseCount NumRef Iso QOpt Blk Lockname 0x1947EBF0 INST411 SQLTP1ST JArHRBLV CS 5 B 53514C C4BE7A241 0x194878B0 INST411 SQLC2F0A AAAAAHLV CS 5 B 53514C F12CF8E241 0x1947EE30 INST411 SQLTP1DS ebyhrblv CS 5 B 53514C AFBE9E841 0x1947E4E0 NULLID SQLDEFLT Default Package 1 CONTOKN UR 5 U 53514C C5428DD Sections: Address Schema PkgName UniqueID SecNo NumRef UseCount StmtType Cursor W-Hld 0x1947F070 INST411 SQLTP1ST JArHRBLV CURSOR1 NO 0x1947F1B4 INST411 SQLTP1ST JArHRBLV NO 0x1947F2F8 INST411 SQLTP1ST JArHRBLV CURSOR2 NO 0x1947F43C INST411 SQLTP1ST JArHRBLV NO 0x1947F580 INST411 SQLTP1ST JArHRBLV NO 0x1947F6C4 INST411 SQLTP1ST JArHRBLV NO 0x196260C0 INST411 SQLC2F0A AAAAAHLV SQLCUR1 NO 0x INST411 SQLC2F0A AAAAAHLV SQLCUR2 NO 0x INST411 SQLC2F0A AAAAAHLV SQLCUR3 NO 0x C INST411 SQLC2F0A AAAAAHLV SQLCUR4 NO 0x196265D0 INST411 SQLC2F0A AAAAAHLV SQLCUR5 NO This report includes the counts of references to each status package and section. Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndbap1.txt 11-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

237 V Student Exercises EXempty vi sndbap1.txt Locate the section of the database snapshot report that contains Package Cache and Catalog Cache statistics. It will look similar to the following: Package cache lookups = Package cache inserts = 11 Package cache overflows = 0 Package cache high water mark (Bytes) = Application section lookups = Application section inserts = 18 Catalog cache lookups = 93 Catalog cache inserts = 10 Catalog cache overflows = 0 Catalog cache high water mark = Record the following from your report. Package cache lookups: Package cache inserts: Package cache high water mark (Bytes): Catalog cache lookups: Catalog cache inserts: These statistics show that running the transactions using a single application with static SQL caused a few new static SQL sections to be inserted into the package cache from the DB2 Catalog tables. As the transactions ran, those sections were found in package cache and did not need to be read again from the DB2 Catalogs. The static SQL application did not require SQL compilation, so there was light usage of the Catalog Cache. Record the following statistics in the table at the beginning of this lab exercise in the column labeled Static SQL. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-7

238 Student Exercises Run the DB2 command file snaphits.sql and write the results in the table at the beginning of this exercise. In the terminal session, issue the commands: db2 connect to tp1 db2 -tf snaphits.sql The output will look similar to the following: SELECT data_physical_reads, index_physical_reads, total_physical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_PHYSICAL_READS INDEX_PHYSICAL_READS TOTAL_PHYSICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_logical_reads, index_logical_reads, total_logical_reads, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_LOGICAL_READS INDEX_LOGICAL_READS TOTAL_LOGICAL_READS BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 4 record(s) selected. SELECT data_hit_ratio_percent, index_hit_ratio_percent, total_hit_ratio_percent, bp_name from sysibmadm.bp_hitratio where bp_name not like 'IBMSYSTEM%' DATA_HIT_RATIO_PERCENT INDEX_HIT_RATIO_PERCENT TOTAL_HIT_RATIO_PERCENT BP_NAME IBMDEFAULTBP TP1H16K TP1ADATA TP1AINDX 3. 4 record(s) selected. The SQLTP1DY application contains the same application function but it was written using Dynamic SQL rather than Static SQL. Run three minutes of transactions for this application using the configuration file tp1dymix3.cfg. In the terminal session, issue the commands: db2 terminate db2 force application all 11-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

239 V Student Exercises EXempty db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application using the configuration file tp1dymix3.cfg, and issue the following commands: cd $HOME/bin multi tp1dymix3.cfg To begin processing transactions, click the RUN button. While the transactions are being processed, check for lock contention using the following db2pd command: db2pd db tp1 locks The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:06:55 Locks: Address TranHdl Lockname Type Mode Sts Owner 0x Internal V..S G 7 0x13851AE Internal V..S G 6 0x13851E APM Seq..S G 6 0x APM Seq..S G 7 0x13851E C C28B Internal P..S G 6 0x138519F C C28B Internal P..S G 7 0x13851F Row..X G 6 0x BE0056 Internal V..S G 7 0x13852A BE0056 Internal V..S G 6 0x13852A Row..X G 7 0x138504E D Row..X G 7 0x138527B F00C Row..X G 6 0x C AFBE9E841 Internal P..S G 9 0x C AFBE9E841 Internal P..S G 8 0x13851B F21F Row..X G 6 0x13852B E00C Row..X G 7 0x138528D Row..X G 6 0x DD0056 Internal V..S G 7 0x DD0056 Internal V..S G 6 0x138522D Internal V..S G 6 0x Internal V..S G 7 0x13851C B0056 Internal V..S G 7 0x B0056 Internal V..S G 6 0x138505D B Row..X G 7 0x138507E Table.IX G 7 0x13851A20 6 Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-9

240 Student Exercises Table.IX G 6 0x Table.IS G 9 0x138511E Table.IS G 8 0x13851EA Table.IX G 7 0x Table.IX G 6 0x138507B Table.IX G 7 0x13851B Table.IX G 6 0x13852A Table.IX G 7 0x13851A Table.IX G 6 You may catch some lock waits, but there should not be much contention at the row level between these applications. Allow the MULTI transactions to complete 3 minutes of processing. What is the Total Count of transactions for the mixture with the dynamic SQL application? Use the db2pd command to examine the information about the dynamic sql statements in the package cache for the database. db2pd db tp1 dynamic > pddynamic.txt The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:09:40 Dynamic Cache: Current Memory Used Total Heap Size Cache Overflow Flag 0 Number of References Number of Statement Inserts 57 Number of Statement Deletes 17 Number of Variation Inserts 42 Number of Statements 40 Dynamic SQL Statements: Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text 0x196CF CALL REORGCHK_TB_STATS ('T', '"INST411 "."HIST2"') 0x1948E2A select agent_id, agent_id_holding_lk, appl_id_holding_lk from sysibmadm.lockwaits order by agent_id 0x196D29A SELECT TYPE FROM SYSIBM.SYSTABLES WHERE TYPE='L' AND SYSIBM.SYSTABLES.CREATOR='INST411 ' AND SYSIBM.SYSTABLES.NAME='HIST2' 0x196DD SELECT indschema, indname from SYSCAT.INDEXES where tabschema =? AND tabname =? AND (INDEXTYPE = 'CLUS' OR UNIQUERULE IN ('P','U')) ORDER BY INDEXTYPE, UNIQUERULE with ur DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

241 V Student Exercises EXempty 0x1947FE SELECT BALANCE, ACCT_GRP FROM ACCT WHERE ACCT_ID =? FOR UPDATE OF BALANCE 0x1967F SELECT CREATE_TIME FROM SYSTOOLS.HMON_ATM_INFO WHERE SCHEMA =? AND NAME =? FOR UPDATE 0x1967BF CALL SYSINSTALLOBJECTS( 'DB2AC', 'V', NULL, NULL ) 0x1948A COMMIT 0x196DFDC SELECT COUNT(*) FROM SYSTOOLS.HMON_ATM_INFO WHERE REORG_FLAG = 'Y' AND REORG_NOTIFY = 'Y' 0x1967CDF SELECT TABNAME FROM SYSCAT.TABLES WHERE TABNAME='HMON_ATM_INFO' AND TABSCHEMA='SYSTOOLS' 0x1967F SELECT CREATOR, NAME, CTIME FROM SYSIBM.SYSTABLES WHERE TYPE='T' OR TYPE='S' 0x194868C UPDATE TELLER SET BALANCE = BALANCE +? WHERE TELLER_ID =? 0x196D WITH JTAB(JSCHEMA,JNAME) AS (VALUES(TABLE_SCHEMA('HIST2','INST411 '), TABLE_NAME ('HIST2','INST411 '))) SELECT AVGROWSIZE FROM SYSIBM.SYSTABLES, JTAB WHERE (CREATOR = JTAB.JSCHEMA) AND (NAME = JTAB.JNAME) 0x196DF7A SELECT COUNT(*) FROM SYSTOOLS.HMON_ATM_INFO WHERE REORG_FLAG = 'Y' AND ((REORG_STATE = 2) OR (REORG_STATE = 6)) 0x196D5C WITH JTAB(JSCHEMA,JNAME) AS (VALUES(TABLE_SCHEMA('HIST2','INST411 '), TABLE_NAME('HIST2','INST411 '))) SELECT CREATOR, NAME, CARD, OVERFLOW, NPAGES, FPAGES, ACTIVE_BLOCKS, CLUSTERED, AVGCOMPRESSEDROWSIZE, PCTFREE FROM SYSIBM.SYSTABLES, JTAB WHERE ((TYPE='T') OR (TYPE = 'S') OR (TYPE = 'U')) AND (CREATOR=JTAB.JSCHEMA) AND (NAME=JTAB.JNAME) ORDER BY CREATOR,NAME 0x196DAD WITH JTAB(JSCHEMA,JNAME) AS (VALUES(TABLE_SCHEMA('HIST2','INST411 '), TABLE_NAME('HIST2','INST411 '))) SELECT COUNT(*) FROM SYSIBM.SYSDATAPARTITIONS, JTAB WHERE (TABSCHEMA = JTAB.JSCHEMA) AND (TABNAME = JTAB.JNAME) AND LENGTH(STATUS)=0 0x196D8A WITH JTAB(JSCHEMA,JNAME) AS (VALUES(TABLE_SCHEMA('HIST2','INST411 '), TABLE_NAME ('HIST2','INST411 '))) SELECT SYSIBM.SYSTABLESPACES.PAGESIZE, SYSIBM.SYSTABLESPACES.EXTENTSIZE, SYSIBM.SYSTABLESPACES.DATATYPE FROM SYSIBM.SYSTABLESPACES, SYSIBM.SYSTABLES, JTAB, SYSIBM.SYSDATAPARTITIONS WHERE (SYSIBM.SYSTABLES.CREATOR = JTAB.JSCHEMA) AND (SYSIBM.SYSTABLES.NAME = JTAB.JNAME) AND (SYSIBM.SYSTABLES.NAME = SYSIBM.SYSDATAPARTITIONS.TABNAME) AND (SYSIBM.SYSTABLES.CREATOR = SYSIBM.SYSDATAPARTITIONS.TABSCHEMA) AND (SYSIBM.SYSDATAPARTITIONS.SEQNO=0) AND (SYSIBM.SYSDATAPARTITIONS.TBSPACEID = SYSIBM.SYSTABLESPACES.TBSPACEID) Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-11

242 Student Exercises 0x196D WITH VTYPED (NAME, SCHEMA) AS (VALUES(TABLE_NAME ('HIST2', 'INST411 '), TABLE_SCHEMA('HIST2', 'INST411 '))) SELECT TYPE FROM SYSIBM.SYSTABLES, VTYPED WHERE TYPE = 'U' AND SYSIBM.SYSTABLES.NAME = VTYPED.NAME AND SYSIBM.SYSTABLES.CREATOR = VTYPED.SCHEMA 0x196E SELECT MAX(REORG_AVG_RUNTIME) FROM SYSTOOLS.HMON_ATM_INFO 0x1947EB SET CURRENT LOCALE LC_CTYPE = 'en_us' 0x196C89A UPDATE SYSTOOLS.HMON_ATM_INFO AS ATM SET ATM.REORG_FLAG = 'N' 4. Close the MULTI application now. Use the GET SNAPSHOT FOR DATABASE command to collect a set of database statistics for the TP1 database. Save the statistics to a file and in the table SNAPDATA. In the terminal session, issue the commands: db2 -tvf savesnap.ddl db2 get snapshot for database on tp1 > sndbap2.txt vi sndbap2.txt Locate the section of the database snapshot report that contains Package Cache and Catalog Cache statistics. It will look similar to the following: Package cache lookups = Package cache inserts = 46 Package cache overflows = 0 Package cache high water mark (Bytes) = Application section lookups = Application section inserts = 70 Catalog cache lookups = 181 Catalog cache inserts = 34 Catalog cache overflows = 0 Catalog cache high water mark = Record the following from your report. Package cache lookups: Package cache inserts: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

243 V Student Exercises EXempty 5. Package cache high water mark (Bytes): Catalog cache lookups: Catalog cache inserts: These statistics show that running the transactions using a single application with dynamic SQL caused some dynamic SQL sections to be compiled by the DB2 optimizer and inserted into the package cache. As the following transactions ran, those sections were found in package cache and the SQL statements did not need to be compiled again. This dynamic SQL application did not access many different tables or indexes so the usage of the Catalog Cache was not high. Record the following statistics in the table at the beginning of this lab exercise in the column labeled Dynamic SQL. Buffer Pool Data Logical Reads Buffer Pool Data Physical Reads BP Data Writes Buffer Pool Index Logical Reads Buffer Pool Index Physical Reads Buffer Pool Index Hit Ratio Total buffer pool read time (ms) Total buffer pool write time (ms) No victim buffers available Rows inserted Log Pages Written Run the DB2 command file snaphits.sql and write the results in the table at the beginning of this exercise. In the terminal session, issue the commands: db2 connect to tp1 db2 -tf snaphits.sql The dynamic SQL statements used by SQLTP1DY are in the package cache. Use the GET SNAPSHOT command to list the contents of the TP1 database to get statistics for each statement. db2 get snapshot for dynamic sql on tp1 > sndyn2.txt vi sndyn2.txt The dynamic SQL report will include information similar to the following: Number of executions = 4296 Number of compilations = 1 Worst preparation time (ms) = 1944 Best preparation time (ms) = 1944 Internal rows deleted = 0 Internal rows inserted = 0 Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-13

244 Student Exercises Rows read = 4296 Internal rows updated = 0 Rows written = 4296 Statement sorts = 0 Statement sort overflows = 0 Total sort time = 0 Buffer pool data logical reads = 8592 Buffer pool data physical reads = 3 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Buffer pool index logical reads = 4322 Buffer pool index physical reads = 0 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Total execution time (sec.ms) = Total user cpu time (sec.ms) = Total system cpu time (sec.ms) = Statement text = UPDATE BRANCH SET BALANCE = BALANCE +? WHERE BRANCH_ID =? Number of executions = 4296 Number of compilations = 1 Worst preparation time (ms) = 848 Best preparation time (ms) = 848 Internal rows deleted = 0 Internal rows inserted = 0 Rows read = 0 Internal rows updated = 0 Rows written = 4296 Statement sorts = 0 Statement sort overflows = 0 Total sort time = 0 Buffer pool data logical reads = 4402 Buffer pool data physical reads = 2 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Buffer pool index logical reads = Buffer pool index physical reads = DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

245 V Student Exercises EXempty Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Total execution time (sec.ms) = Total user cpu time (sec.ms) = Total system cpu time (sec.ms) = Statement text = INSERT INTO HISTORY(ACCT_ID, TELLER_ID, BRANCH_ID, BALANCE, DELTA, PID, ACCTNAME, TEMP) VALUES(?,?,?,?,?,?,?,?) Number of executions = 4296 Number of compilations = 1 Worst preparation time (ms) = 3 Best preparation time (ms) = 3 Internal rows deleted = 0 Internal rows inserted = 0 Rows read = 4296 Internal rows updated = 0 Rows written = 4296 Statement sorts = 0 Statement sort overflows = 0 Total sort time = 0 Buffer pool data logical reads = 8592 Buffer pool data physical reads = 0 Buffer pool temporary data logical reads = 0 Buffer pool temporary data physical reads = 0 Buffer pool index logical reads = 0 Buffer pool index physical reads = 0 Buffer pool temporary index logical reads = 0 Buffer pool temporary index physical reads = 0 Buffer pool xda logical reads = 0 Buffer pool xda physical reads = 0 Buffer pool temporary xda logical reads = 0 Buffer pool temporary xda physical reads = 0 Total execution time (sec.ms) = Total user cpu time (sec.ms) = Total system cpu time (sec.ms) = Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-15

246 Student Exercises Statement text SET BALANCE = BALANCE +? CURSOR1 = UPDATE ACCT WHERE CURRENT OF 6. The SQL statements show large numbers for executions and only one compilation. The SQL statement text used by the SQLTP1DY application contain '?' instead of specific key data. This allows the reuse of these statements from package cache. Use the query in the file dblockinfo.sql to retrieve information about locking at the database level. The query uses the Administrative view SYSIBMADM.SNAPDB. Look at the database statistics for locking. In the terminal session, issue the commands: db2 tvf dblockinfo.sql The output should be similar to the following information: select lock_waits, lock_wait_time, lock_list_in_use, deadlocks, lock_escals, lock_wait_time / lock_waits as avg_lock_wait_ms from sysibmadm.snapdb LOCK_WAITS LOCK_WAIT_TIME LOCK_LIST_IN_USE DEADLOCKS LOCK_ESCALS AVG_LOCK_WAIT_MS record(s) selected. Record the following statistics: Lock Waits: Lock Wait Time : The application tables are large enough and the applications access a few rows using the indexes, so lock contention is not a problem for this application DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

247 V Student Exercises EXempty Section 2 - Alter the ACCT and HISTORY Tables for Table Locking Rather Than Row Locking and Measure the Effects on Performance 1. The transaction applications that have been tested access a few rows using unique indexes. DB2 is using row level locking to enable the four applications to share access to the tables with row level locks used to prevent access to uncommitted changes. The applications could have included LOCK TABLE statements to get exclusive access to the tables for the updates. Alter the ACCT and HISTORY tables to use table locking rather than row locking and collect database performance statistics for 3 minutes of transaction processing. In the terminal session, issue the commands: db2 connect to tp1 db2 alter table history locksize table db2 alter table acct locksize table Altering the locksize of these tables will invalid the packages for the applications with static SQL. cd $HOME/bin db2 -tf tp1bind db2 terminate db2 force application all db2 deactivate db tp1 db2 activate db tp1 db2 connect to tp1 Start a second terminal session for running the MULTI application using the configuration file tp1dy3.cfg, and issue the following commands: cd $HOME/bin multi tp1dy3.cfg To begin processing transactions, click the RUN button. While the transactions are being processed, check for lock contention using the following db2pd command: While the transactions are being processed, check for lock contention using the following db2pd command: db2pd db tp1 locks The output will include information similar to the following: Database Partition 0 -- Database TP1 -- Active -- Up 0 days 00:01:38 Locks: Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-17

248 Student Exercises Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg 0x Internal V..S G 0x138515D C C28B Internal P..S G 0x138519F C C28B Internal P..S G 0x C C28B Internal P..S G 0x13851E C C28B Internal P..S G 0x138522D BE0056 Internal V..S G 0x138525A Row..X G 0x138516F C Row..X G 0x138505D Internal V..S G 0x Internal V..S G 0x138516C Internal V..S G 0x DD0056 Internal V..S G 0x B0056 Internal V..S G 0x Table.IX G 0x138517B Table..X G 0x138523C Table..X W 0x Table..X W 0x Table..X W 0x Table..X G 0x Table.IX G 2. The use of table level locking for the ACCT and HISTORY tables is likely to cause lock waits in the applications. The example above shows that three of the four applications are currently in a lock wait. Allow the MULTI transactions to complete 3 minutes of processing. Close the MULTI application now. Use the query in the file dblockinfo.sql to retrieve information about locking at the database level. The query uses the Administrative view SYSIBMADM.SNAPDB. Look at the database statistics for locking. In the terminal session, issue the commands: db2 tvf dblockinfo.sql The output should be similar to the following information: select lock_waits, lock_wait_time, lock_list_in_use, deadlocks, lock_escals, lock_wait_time / lock_waits as avg_lock_wait_ms from sysibmadm.snapdb LOCK_WAITS LOCK_WAIT_TIME LOCK_LIST_IN_USE DEADLOCKS LOCK_ESCALS AVG_LOCK_WAIT_MS DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

249 V Student Exercises EXempty record(s) selected. Record the following statistics: Lock Waits : Lock Wait time : 3. The use of table locking has greatly increased the number of lock waits and the amount of time the applications were in lock waits. Change the ACCT and HISTORY tables back to row locking. Close all the applications and deactivate the TP1 database to clear all current statistics. In the terminal session, issue the commands: db2 alter table history locksize row db2 alter table acct locksize row db2 -tf tp1bind db2 terminate db2 force application all db2 deactivate db tp1 END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 11. Application Performance 11-19

250 Student Exercises DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

251 V Student Exercises EXempty Exercise 12. Event Monitoring What This Exercise Is About This exercise is an online lab which allows the student to use Event Monitors to collect performance statistics for transactions, SQL statements and application connections executing in the DB2 database. The event monitoring will use files and database tables to store the monitor data. What You Should Be Able to Do At the end of the lab, you should be able to: Create a file Event Monitor to collect SQL statement performance statistics for later analysis. Create a table Event Monitor to collect transaction performance statistics and use SQL queries to retrieve the information. Use the DB2EVMON utility to format the file Event Monitor data into a report. Use the Event Analyzer application to review table Event Monitor statistics. Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-1

252 Student Exercises Exercise Instructions Introduction In this exercise, you will be using the Event Monitoring facility of DB2 to collect performance statistics of several database applications. First, a File Event Monitor will be created to collect Statement and Connection Event data. DB2BATCH will be used to execute a set of five queries, and the DB2EVMON tool will be used to format a report from the collected statistics. Next a Table Event Monitor will be created to collect Transaction Events directly to a set of DB2 tables. The MULTI application will be used to generate a mixture of application transactions. The Table Event Monitor data will be reviewed using an SQL Query from the DB2 Tables. The DB2 Event Analyzer will be used to get another view of the transaction events. Note: The examples are shown to help you locate the information, the costs and other statistics in your reports may vary from the values shown DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

253 V Student Exercises EXempty Section 1 - Creating File Event Monitor and Using DB2EVMON Command In this exercise, we will create a File Event Monitor to collect SQL statement and Connection Event Monitor statistics. We will also use DB2EVMON command to format results into a report Create a File Event Monitor, STMTFILE to collect SQL statement and connection event statistics. The event monitor should be have the following options: NONBLOCKED BUFFERSIZE 8 MAXFILES 3 MAXFILESIZE 1024 FILE /home/inst411/stmt From your Linux workstation, start a terminal session. In the terminal session, issue the commands: cd $HOME mkdir stmt db2 activate db tp1 db2 connect to tp1 db2 CREATE EVENT MONITOR STMTFILE FOR STATEMENTS,CONNECTIONS WRITE TO FILE '/home/inst411/stmt' BUFFERSIZE 8 NONBLOCKED MAXFILES 3 MAXFILESIZE 1024 Activate the new STMTFILE Event Monitor and run a DB2BATCH command to generate performance statistics for a group of SQL queries. In the terminal session, issue the commands: Check to see if the STMTFILE Event Monitor is active. db2 ' select substr(evmonname,1,18) as event_monitor, event_mon_state(evmonname) as mon_state from syscat.eventmonitors ' The output will look similar to the following: EVENT_MONITOR MON_STATE DB2DETAILDEADLOCK 1 STMTFILE 0 This shows that the new Event Monitor is not active, start the Event Monitor. db2 set event monitor STMTFILE state 1 Use db2batch to run a set of SQL queries to generate Event Monitor data. cd $HOME/bin Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-3

254 Student Exercises 3. db2batch -d tp1 -f batch1.sql -i complete > batchmon1.out Stop the Event Monitor from collecting new monitor data. db2 set event monitor STMTFILE state 0 The DB2EVMON command can be used to format the collected Event Monitor statistics into a report. Run db2evmon and save the report to a file, eventstmt.txt. In the terminal session, issue the commands: db2evmon -db tp1 -evm stmtfile > eventstmt.txt vi eventstmt.txt Locate the first statement event for the following SQL text: Text : SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY... The output will look similar to the following: 10) Statement Event... Appl Handle: 182 Appl Id: *LOCAL.INST Appl Seq number: 0001 Record is the result of a flush: FALSE Type : Dynamic Operation: Prepare Section : 1 Creator : NULLID Package : TOOL1E00 Consistency Token : AAAAAaHS Package Version ID : Cursor : DYNCUR Cursor was blocking: FALSE Text : SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID BETWEEN 20 AND 29 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Start Time: 11/20/ :17: Stop Time: 11/20/ :17: Exec Time: seconds Number of Agents created: 1 User CPU: seconds System CPU: seconds Fetch Count: DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

255 V Student Exercises EXempty Sorts: 0 Total sort time: 0 Sort overflows: 0 Rows read: 4 Rows written: 0 Internal rows deleted: 0 Internal rows updated: 0 Internal rows inserted: 0 Bufferpool data logical reads: 14 Bufferpool data physical reads: 5 Bufferpool temporary data logical reads: 0 Bufferpool temporary data physical reads: 0 Bufferpool index logical reads: 6 Bufferpool index physical reads: 2 Bufferpool temporary index logical reads: 0 Bufferpool temporary index physical reads: 0 SQLCA: sqlcode: 0 sqlstate: ) Statement Event... Appl Handle: 182 Appl Id: *LOCAL.INST Appl Seq number: 0001 Record is the result of a flush: FALSE Type : Dynamic Operation: Open Section : 1 Creator : NULLID Package : TOOL1E00 Consistency Token : AAAAAaHS Package Version ID : Cursor : DYNCUR Cursor was blocking: TRUE Text : SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID BETWEEN 20 AND 29 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Start Time: 11/20/ :17: Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-5

256 Student Exercises Stop Time: 11/20/ :17: Exec Time: seconds Number of Agents created: 1 User CPU: seconds System CPU: seconds Fetch Count: 0 Sorts: 0 Total sort time: 0 Sort overflows: 0 Rows read: 0 Rows written: 0 Internal rows deleted: 0 Internal rows updated: 0 Internal rows inserted: 0 Bufferpool data logical reads: 0 Bufferpool data physical reads: 0 Bufferpool temporary data logical reads: 0 Bufferpool temporary data physical reads: 0 Bufferpool index logical reads: 0 Bufferpool index physical reads: 0 Bufferpool temporary index logical reads: 0 Bufferpool temporary index physical reads: 0 SQLCA: sqlcode: 0 sqlstate: ) Statement Event... Appl Handle: 182 Appl Id: *LOCAL.INST Appl Seq number: 0001 Record is the result of a flush: FALSE Type : Dynamic Operation: Close Section : 1 Creator : NULLID Package : TOOL1E00 Consistency Token : AAAAAaHS Package Version ID : Cursor : DYNCUR Cursor was blocking: TRUE 12-6 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

257 V Student Exercises EXempty Text : SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY.ACCTNAME, HISTORY.ACCT_ID, HISTORY.BALANCE FROM HISTORY AS HISTORY, TELLER AS TELLER WHERE HISTORY.TELLER_ID = TELLER.TELLER_ID AND HISTORY.BRANCH_ID BETWEEN 20 AND 29 ORDER BY HISTORY.BRANCH_ID ASC, HISTORY.ACCT_ID ASC Start Time: 11/20/ :17: Stop Time: 11/20/ :17: Exec Time: seconds Number of Agents created: 1 User CPU: seconds System CPU: seconds Fetch Count: Sorts: 2 Total sort time: 72 Sort overflows: 0 Rows read: Rows written: 0 Internal rows deleted: 0 Internal rows updated: 0 Internal rows inserted: 0 Bufferpool data logical reads: 710 Bufferpool data physical reads: 144 Bufferpool temporary data logical reads: 0 Bufferpool temporary data physical reads: 0 Bufferpool index logical reads: 29 Bufferpool index physical reads: 23 Bufferpool temporary index logical reads: 0 Bufferpool temporary index physical reads: 0 SQLCA: sqlcode: 0 sqlstate: Notice that there are three Event Monitor records for this one SQL statement. The operations are PREPARE, OPEN, and CLOSE. The complete statistics for the SQL statement execution are stored in the CLOSE operation. The db2batch execution command file batch1.sql contained 5 queries: Query 1: SELECT HISTORY.BRANCH_ID, TELLER.TELLER_NAME, HISTORY... Query 2: SELECT ACCT_ID, ACCTNAME, TELLER_ID, BRANCH_ID, BALANCE FROM... Query 3: SELECT ACCT_GRP, SUM(BALANCE) FROM ACCT WHERE ACCT_GRP... Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-7

258 Student Exercises Query 4: SELECT ACCT.ACCT_ID, ACCT.NAME, TELLER.TELLER_ID, TELLER... Query 5: SELECT NAME, ADDRESS FROM ACCT WHERE ACCT_GRP < Locate the CLOSE event record for each SQL statement and the record the following statistics. Monitor Statistic Query 1 Query 2 Query 3 Query 4 Query 5 Fetch Count Sorts Total sort time Sort overflows Rows read 12-8 DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

259 V Student Exercises EXempty Section 2 - Creating a Table Event Monitor In this exercise, we will create a Table Event Monitor to collect SQL Transaction Event Monitor statistics. We will also use SQL Query to retrieve the results Event Monitor records can be stored directly into database tables. In order to limit the size of the generated event records, a new DMS table space will be created for the DB2 tables used by the Event Monitor. In the terminal session, issue the command: db2 connect to tp1 The DB2 command file, montspace.ddl, contains the following statement to create a new table space. CREATE REGULAR TABLESPACE TP1EVENT PAGESIZE 4 K INITIALSIZE 10 M EXTENTSIZE 8 PREFETCHSIZE 16 Create the table space using the command file. cd $HOME/bin db2 -tvf montspace.ddl The db2evtbl command can be used to generate a file that contains a CREATE EVENT MONITOR SQL statement that can be tailored to specific monitoring requirements. Use the db2evtbl to generate a sample CREATE EVENT MONITOR statement. In the terminal session, issue the commands: db2evtbl -evm tp1samp connections,transactions,statements > evtsample.ddl vi evtsample.ddl The generated statement will look similar to the following: CREATE EVENT MONITOR tp1samp FOR CONNECTIONS, TRANSACTIONS, STATEMENTS WRITE TO TABLE CONNHEADER (TABLE CONNHEADER_tp1samp, INCLUDES (AGENT_ID, APPL_ID, APPL_NAME, AUTH_ID, CLIENT_DB_ALIAS, CLIENT_NNAME, CLIENT_PID, CLIENT_PLATFORM, CLIENT_PRDID, CLIENT_PROTOCOL, CODEPAGE_ID, CONN_TIME, Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-9

260 Student Exercises CORR_TOKEN, EXECUTION_ID, SEQUENCE_NO, TERRITORY_CODE )), STMT (TABLE STMT_tp1samp, INCLUDES (AGENT_ID, AGENTS_TOP, APPL_ID, BLOCKING_CURSOR, CONSISTENCY_TOKEN, CREATOR, CURSOR_NAME, EVMON_FLUSHES, FETCH_COUNT, INT_ROWS_DELETED, INT_ROWS_INSERTED, INT_ROWS_UPDATED, PACKAGE_NAME, PACKAGE_VERSION_ID, PARTIAL_RECORD, POOL_DATA_L_READS, POOL_DATA_P_READS, POOL_INDEX_L_READS, POOL_INDEX_P_READS, POOL_TEMP_DATA_L_READS, POOL_TEMP_DATA_P_READS, POOL_TEMP_INDEX_L_READS, POOL_TEMP_INDEX_P_READS, POOL_TEMP_XDA_L_READS, POOL_TEMP_XDA_P_READS, POOL_XDA_L_READS, POOL_XDA_P_READS, ROWS_READ, ROWS_WRITTEN, SECTION_NUMBER, SEQUENCE_NO, SORT_OVERFLOWS, SQL_REQ_ID, SQLCABC, SQLCAID, SQLCODE, SQLERRD1, SQLERRD2, SQLERRD3, SQLERRD4, SQLERRD5, SQLERRD6, DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

261 V Student Exercises EXempty SQLERRM, SQLERRP, SQLSTATE, SQLWARN, START_TIME, STMT_OPERATION, STMT_TEXT, STMT_TYPE, STOP_TIME, SYSTEM_CPU_TIME, TOTAL_SORT_TIME, TOTAL_SORTS, USER_CPU_TIME )), XACT (TABLE XACT_tp1samp, INCLUDES (AGENT_ID, APPL_ID, EVMON_FLUSHES, LOCK_ESCALS, LOCK_WAIT_TIME, LOCKS_HELD_TOP, PARTIAL_RECORD, PREV_UOW_STOP_TIME, ROWS_READ, ROWS_WRITTEN, SEQUENCE_NO, STOP_TIME, SYSTEM_CPU_TIME, UOW_LOG_SPACE_USED, UOW_START_TIME, UOW_STATUS, USER_CPU_TIME, X_LOCK_ESCALS )), CONN (TABLE CONN_tp1samp, INCLUDES (ACC_CURS_BLK, AGENT_ID, APPL_ID, APPL_PRIORITY, APPL_PRIORITY_TYPE, APPL_SECTION_INSERTS, APPL_SECTION_LOOKUPS, APPL_STATUS, AUTHORITY_LVL, BINDS_PRECOMPILES, CAT_CACHE_HEAP_FULL, CAT_CACHE_INSERTS, CAT_CACHE_LOOKUPS, CAT_CACHE_OVERFLOWS, Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-11

262 Student Exercises CAT_CACHE_SIZE_TOP, COMMIT_SQL_STMTS, COORD_NODE, DDL_SQL_STMTS, DEADLOCKS, DIRECT_READ_REQS, DIRECT_READ_TIME, DIRECT_READS, DIRECT_WRITE_REQS, DIRECT_WRITE_TIME, DIRECT_WRITES, DISCONN_TIME, DYNAMIC_SQL_STMTS, ELAPSED_EXEC_TIME, EVMON_FLUSHES, FAILED_SQL_STMTS, HASH_JOIN_OVERFLOWS, HASH_JOIN_SMALL_OVERFLOWS, INT_AUTO_REBINDS, INT_COMMITS, INT_DEADLOCK_ROLLBACKS, INT_ROLLBACKS, INT_ROWS_DELETED, INT_ROWS_INSERTED, INT_ROWS_UPDATED, LOCK_ESCALS, LOCK_TIMEOUTS, LOCK_WAIT_TIME, LOCK_WAITS, PARTIAL_RECORD, PKG_CACHE_INSERTS, PKG_CACHE_LOOKUPS, POOL_DATA_FROM_ESTORE, POOL_DATA_L_READS, POOL_DATA_P_READS, POOL_DATA_TO_ESTORE, POOL_DATA_WRITES, POOL_INDEX_FROM_ESTORE, POOL_INDEX_L_READS, POOL_INDEX_P_READS, POOL_INDEX_TO_ESTORE, POOL_INDEX_WRITES, POOL_READ_TIME, POOL_TEMP_DATA_L_READS, POOL_TEMP_DATA_P_READS, POOL_TEMP_INDEX_L_READS, POOL_TEMP_INDEX_P_READS, POOL_TEMP_XDA_L_READS, DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

263 V Student Exercises EXempty POOL_TEMP_XDA_P_READS, POOL_WRITE_TIME, POOL_XDA_L_READS, POOL_XDA_P_READS, POOL_XDA_WRITES, PREFETCH_WAIT_TIME, PRIV_WORKSPACE_NUM_OVERFLOWS, PRIV_WORKSPACE_SECTION_INSERTS, PRIV_WORKSPACE_SECTION_LOOKUPS, PRIV_WORKSPACE_SIZE_TOP, REJ_CURS_BLK, ROLLBACK_SQL_STMTS, ROWS_DELETED, ROWS_INSERTED, ROWS_READ, ROWS_SELECTED, ROWS_UPDATED, ROWS_WRITTEN, SELECT_SQL_STMTS, SEQUENCE_NO, SHR_WORKSPACE_NUM_OVERFLOWS, SHR_WORKSPACE_SECTION_INSERTS, SHR_WORKSPACE_SECTION_LOOKUPS, SHR_WORKSPACE_SIZE_TOP, SORT_OVERFLOWS, STATIC_SQL_STMTS, SYSTEM_CPU_TIME, TOTAL_HASH_JOINS, TOTAL_HASH_LOOPS, TOTAL_SORT_TIME, TOTAL_SORTS, UID_SQL_STMTS, UNREAD_PREFETCH_PAGES, USER_CPU_TIME, X_LOCK_ESCALS, XQUERY_STMTS )), CONTROL (TABLE CONTROL_tp1samp, INCLUDES (EVENT_MONITOR_NAME, MESSAGE, MESSAGE_TIME )); 3. Notice that a table is created to store each type of Event Monitor record. The monitoring elements can be tailored to be selectively included or excluded to reduce the amount of collected data. Create a Table Event Monitor, TP1TRAN, to collect transaction event statistics using the DB2 command file, tp1tran.ddl, which contains the following SQL statement: CREATE EVENT MONITOR tp1tran Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-13

264 Student Exercises FOR TRANSACTIONS WRITE TO TABLE CONNHEADER (TABLE CONNHEADER_tp1tran, in tp1event, INCLUDES (AGENT_ID, APPL_ID, APPL_NAME, AUTH_ID, CLIENT_DB_ALIAS, CLIENT_NNAME, CLIENT_PID, CLIENT_PLATFORM, CLIENT_PRDID, CLIENT_PROTOCOL, CODEPAGE_ID, CONN_TIME, CORR_TOKEN, EXECUTION_ID, SEQUENCE_NO, TERRITORY_CODE )), XACT (TABLE XACT_tp1tran, in tp1event, INCLUDES (AGENT_ID, APPL_ID, EVMON_FLUSHES, LOCK_ESCALS, LOCK_WAIT_TIME, LOCKS_HELD_TOP, PARTIAL_RECORD, PREV_UOW_STOP_TIME, ROWS_READ, ROWS_WRITTEN, SEQUENCE_NO, STOP_TIME, SYSTEM_CPU_TIME, UOW_LOG_SPACE_USED, UOW_START_TIME, UOW_STATUS, USER_CPU_TIME, X_LOCK_ESCALS )), CONTROL (TABLE CONTROL_tp1tran, in tp1event, INCLUDES (EVENT_MONITOR_NAME, MESSAGE, MESSAGE_TIME )) MANUALSTART ; In the terminal session, issue the command: db2 -tvf tp1tran.ddl DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

265 V Student Exercises EXempty 4. Start the new Table Event Monitor, TP1TRAN, to collect transaction event statistics. Use the MULTI application with a configuration of TP1MIX.CFG to run a mixture of application transactions. 5. In the terminal session, issue the command: db2 set event monitor TP1TRAN state 1 Start a second terminal session for running the MULTI application and issue the following commands: cd $HOME/bin multi tp1mix.cfg To begin processing transactions, click the RUN button. Wait for 60 seconds of Elapsed Time to complete. Close the MULTI application now. Stop the Event Monitor TP1TRAN from collecting new monitor data. db2 set event monitor TP1TRAN state 0 Use a SQL query to select some of the collected transaction statistics from the XACT_TP1TRAN table. The following query is in the DB2 command file evtquery1.sql: SELECT AGENT_ID, STOP_TIME - UOW_START_TIME AS DURATION, ROWS_READ, ROWS_WRITTEN, UOW_LOG_SPACE_USED, LOCK_WAIT_TIME FROM XACT_TP1TRAN WHERE ROWS_READ > 30 ORDER BY ROWS_READ DESC ; In the terminal session, issue the commands: db2 -tvf evtquery1.sql > evtreport1.txt vi evtreport1.txt The output will look similar to the following: SELECT AGENT_ID, STOP_TIME - UOW_START_TIME AS DURATION, ROWS_READ, ROWS_WRITTEN, UOW_LOG_SPACE_USED, LOCK_WAIT_TIME FROM XACT_TP1TRAN WHERE ROWS_READ > 30 ORDER BY ROWS_READ DESC AGENT_ID DURATION ROWS_READ ROWS_WRITTEN UOW_LOG_SPACE_USED LOCK_WAIT_TIME Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-15

266 Student Exercises record(s) selected DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

267 V Student Exercises EXempty Section 3 - Using the Event Analyzer Tool In this exercise, we will use the Event Analyzer Tool to view the Table Event Monitor for Transaction Event Monitor statistics collected by the TP1TRAN Event Monitor. 1. Start a new terminal session for running the Event Analyzer application and issue the following command: db2eva For Database Name, select TP1 from the list. For Event Monitor Name, select TP1TRAN. Select OK. Point to the entry that shows the Connection time and Start Time for the monitoring session. Click the Selected menu item and choose Drill Down To and Transactions. You can scroll down to see the list of transactions. Scroll to the right to view all the monitoring elements for each transaction. The detailed information for a single transaction event can also viewed by clicking the transaction. Choose one transaction from the Event Analyzer list. Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-17

268 Student Exercises Click the Selected menu item and choose Drill Down To and Data Elements DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

269 V Student Exercises EXempty Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-19

270 Student Exercises DB2 for Linux, UNIX, and Windows Copyright IBM Corp. 2001, 2006

271 V Student Exercises EXempty Close the Event Analyzer application now. END OF EXERCISE Copyright IBM Corp. 2001, 2006 Exercise 12. Event Monitoring 12-21