Deep understanding of DB2 and Snapshots monitoring and Administrative view Sharad D. Pawar ACI Payment system

2 Agenda 1.How to capture DB2 Snapshots 2.Database snapshot interpretations 3.Snapshot Analysis 4.DB2 Administrative views

3 How to Capture DB2 snapshots Get the snapshots for scenario from productions Verify monitor switches turn on db2 “get monitor switches” db2 "get dbm cfg "| grep -i "DFT_MON« db2 "get monitor switches" Some time database server bounce will be required.

4 How to Capture DB2 snapshots DB Configuration for Monitor Switches are as follows :  Buffer pool (DFT_MON_BUFPOOL) = ON  Lock (DFT_MON_LOCK) = ON  Sort (DFT_MON_SORT) = ON  Statement (DFT_MON_STMT) = ON  Table (DFT_MON_TABLE) = ON  Timestamp (DFT_MON_TIMESTAMP) = ON  Unit of work (DFT_MON_UOW) = ON

5 How to Capture DB2 snapshots  db2 “get snapshot for all on ” > outfile.txt  Basic command to get the snapshots. GET SNAPSHOT FOR {DATABASE MANAGER | ALL [DCS] DATABASES | ALL [DCS] APPLICATIONS | ALL BUFFERPOOLS | [DCS] APPLICATION {APPLID appl-id | AGENTID appl-handle} | FCM FOR ALL DBPARTITIONNUMS | LOCKS FOR APPLICATION {APPLID appl-id | AGENTID appl-handle} | {ALL | [DCS] DATABASE | [DCS] APPLICATIONS | TABLES | TABLESPACES | LOCKS | BUFFERPOOLS | DYNAMIC SQL [write to file]} ON database-alias} [AT DBPARTITIONNUM db-partition-number | GLOBAL]

6 How to Capture DB2 snapshots Snapshot can be collected for following monitoring switches : Database Tables Tablespaces Locks Bufferpools Application Dynamic SQL

7 Database Snapshot Interpretations Snapshot can be interpreted in following ways :  General health of database can be determined from the Database Snapshots  Even based on these counters we can determine application counter.

8 Snapshot Analysis Following are the matrices for measuring the performance database  ARSS ( Average Result Set Size )  IRE ( Index Read Efficiency )  Synchronous Read Percentage (SRP)  Number of Transactions Completed (TXCNT)  Number of Selects per Transaction (SELTX)  DML per Transaction (DMLTX)  Sorts per Transaction (SRTTX)  Sort Overflows per Transaction  Rows Read per Transaction (DB-RRTX)  Rows Fetched per Transaction (DB-FETTX)  Bufferpool Logical Reads per Transaction (BPLRTX)  Bufferpool Logical INDEX Reads per Transaction (BPLITX)

9 Snapshot Analysis  ARSS ( Average Result Set Size ) Rule of Thumb : If ARSS is less than or equal to 10, then the database is behaving like an OLTP database. If the ARSS is greater than 10, then your database is behaving like a Data Warehouse database. If the ARSS is just a little bit greater than 10, then you may have an OLTP database with some concurrent decision support (DW) queries running. How to Calculate ARSS : ARSS = ROWS_SELECTED / SELECT_SQL_STMTS

10 Snapshot Analysis  IRE (Index Read Efficiency) Rule of Thumb : If IRE is less than or equal to 10, This is desirable for OLTP database. If you have an OLTP database, an Index Read Efficiency ratio of ten or higher is cause for concern. This would indicate that indexes providing sufficient filtration quality are not available. DB2 may be performing scans or using inefficient indexes as a poor substitute. The IREF for this database was 180 meaning that DB2 picks up and evaluates 180 rows to return just one row on average. This is indicative of scans, and scans in an OLTP database are bad. How to Calculate IRF : IRE : Rows Read / Rows Selected

11 Snapshot Analysis  SRP (Synchronous Read Percentage ) SRP Guidelines for OLTP databases: Rule of Thumb : * SRP should be greater than 90 to make good use of of high quality synchronous I/O to retrieve the required result sets. * If the SRP is in the range of 80-90%, this is good, but may have tuning opportunities for improvement. * If the SRP is in the range of 50-80%, the database's performance may be marginal at best. There are definitely physical design opportunities for improvement. If your SRP is in this range * SRP is being less than 50%, this is highly undesirable. DBA will have lot of opportunity to improve the performance.

12 Snapshot Analysis  SRP (Synchronous Read Percentage) How to Calculate SRP : SRP : (((Asynchronous pool data page reads + Asynchronous pool index page reads) * 100) / (Buffer pool data physical reads + Buffer pool index physical reads)).

13 Snapshot Analysis  SRP (Synchronous Read Percentage) SRP Calculation for DW Database : Rule of Thumb : * If your SRP is greater than 50%, database is performing very good as Data Warehouse queries tend to do a significant amount of data scanning for queries that return larger result sets. * If the SRP is in the range of 25-50%, this is good, but it may have tuning opportunities. * If the SRP is anywhere less than 20%, it means database has lot of opportunities for tuning.

14 Snapshot Analysis  TXCNT (Number of Transactions Completed) It’s summation of the number of committed statement and rollback statements. How to Calculate TXCNT : TXCNT = Commit statements attempted + Rollback statements attempted

15 Snapshot Analysis  SELTX (Number of Selects per transaction) Rule of Thumb : For OLTP database, the range is SELTX indicates how much data retrieval work is being done for each transaction. A value less than 10 is common and desirable. How to Calculate SELTX : SELTX = "Select SQL statements executed" / TXCNT

16 Snapshot Analysis  DMLTX (DML per Transaction) Rule of Thumb : General consideration is within the worldwide normal range of.5 to Select statements are being accompanied by 1-2 Insert/Update/Delete statements, on average. This is good because the units of work are small. DMLTX indicates how much data change activity is being performed for each transaction. A value less than 4 is common and desirable. As DMLTX increases, this will influence the need to increase the DB CFG parameter LOGBUFSZ. The risk of lock contention also increases along with increases in DMLTX How to calculate DMLTX : DMLTX = "Update/Insert/Delete statements executed" / TXCNT

17 Snapshot Analysis  SRTX (Sorts per Transaction) Rule of Thumb : Removing Sorts from your transactions will measurably improve transaction response times AND lower CPU consumption. How to Calculate SRTX : SRTX= Total sorts / TXCNT

18 Snapshot Analysis  SOPT (Sort Overflows per Transaction) Rule of Thumb : SORT consumes CPU cycle and it should be lower for each transaction. Ideally, this should be less than 1 or 2. How to calculate SOPT : SOPT = (Sort overflows * 100) / Total sorts

19 Snapshot Analysis  RRTX (Rows Read per Transaction) Rule of Thumb : Rows Read per Database Transaction should be less than 10%. Making higher rows read per transaction will cause high CPU consumption on the database server.  How to Calculate RRTX : RRTX = Rows Read / TXCNT

20 Snapshot Analysis  FETTX (Rows Fetched per Transaction) Rule of Thumb : Rows Read per Database Transaction should be less than 10%. Making higher rows read per transaction will cause high CPU consumption on the database server.  How to Calculate FETTX : FETTX = Rows Selected / TXCNT (Commit statements attempted + Rollback statements attempted)

21 Snapshot Analysis  BPLRTX (Bufferpool Logical Reads per Transaction) This is cost metric and one of the best cost measurements Bufferpool Read I/O ms per Transaction or verifying your tuning success. Bufferpool logical page reads equate in direct proportion to CPU time consumed. This value Should be low. Just remember: Logical Reads = CPU Consumption When DB2 wants to access data (either index pages or data pages), a Logical Read is performed against the bufferpool. If the data requested is not present in the bufferpool per the logical read request, then a Physical Read must be performed to disk to retrieve the page that was logically requested. If the logically requested data is already in the bufferpool, then the physical disk read is avoided. So, you will note that a request for data typically begins with a Logical request which may, or may not, result in a physical request.

22 Snapshot Analysis  BPLRTX (Bufferpool Logical Reads per Transaction) Formula for calculation : BPLRTX = cast((((Buffer pool data logical reads)+(Buffer pool index logical reads))/((Commit statements attempted)+(Rollback statements attempted)))

23 Snapshot Analysis Overall Read Time (ms) (ORMS) ORMS tells us the average time for DB2 to complete a physical read. It should be computed for the database and for each tablespace. DBA should compare the ORMS for the database against the ORMS for each tablespace. If any tablespaces have read times significantly higher than the average for the database, then it is important to determine why and attempt to improve the performance of the slowest tablespaces. In our example it is 0

24 Snapshot Analysis Overall Write Time (ms) (OWMS) The average time to perform a physical write for this database was 1.84ms. This is good % of writes are being performed asynchronously. This is also good. OWMS at the database level tells us the average time for the database to perform a write (any write, whether synchronous or asynchronous). OWMS at the tablespace level tells us the average write time for each tablespace. If the OWMS for a tablespace is significantly higher than the OWMS for the database, then you have likely uncovered a "performance opportunity for improvement". This situation needs to be investigated. For the tablespaces with the slowest write times, carefully examine their definitions, containers, and placement of containers, and consider these best practices:

25 Snapshot Analysis Bufferpool Write I/O ms per Transaction (BPWIOTX) Bufferpool write time is just one important component of understanding where transaction time goes. we'll also need to look direct I/O times, lock times, sort times, and CPU times. Once we know where time is spent inside the database, then we can focus on the resource that is the greatest bottleneck to optimized performance. We'll also look at determining average transaction times, and how much time, and what percent of time, is spent inside the database and out. BPWIOTX = cast(TOTBPWRITETM as decimal(18,0))/ cast((COMMITSTMTATTMPTD + ROLLBCKSTMTATTMPTD) as decimal(18,0)))

26 Snapshot Analysis Bufferpool Matrix Database Bufferpool Index Hit Ratio (DB-BPIHR) Database Bufferpool Overall Hit Ratio (DB-BPOHR) The bufferpool index hit ratio was 98.58% and the overall bufferpool hit ratio was 86.52%. While these hit ratios look good, remember that bufferpool hit ratios can be very misleading (give you a false sense of security and tuning success) when scans are occurring in the bufferpools. To improve hit ratios, DBAs will commonly throw more and more memory at the bufferpool sizes until they can't get the bufferpool hit ratios to go any higher.

27 Snapshot Analysis Various Bufferpool Matrix  Buffer pool hit ratio per bufferpool  Should be around 95% and above.  Buffer pool data read (logical + physical)  Buffer pool index read (logical + physical)  Buffer pool total read time  Buffer pool total write time  No of victim buffers Available  Direct read/write  Time spend on direct read/write

28 Snapshot Analysis Lock related matrix LCKMS - The Average Lock Wait Time Not every lock times out. Some locks just experience temporary delays while they wait for required resources to become available. The LCKMS formula will tell you the average lock wait time. LCKMS should not be greater than LOCKTIMEOUT, but it could be equal to LOCKTIMEOUT if ALL of your locks time out. Remember, too, that LOCKTIMEOUT is configured in seconds and this formula computes milliseconds - another one of the wonderful consistencies within DB2 LCKTX - The Average Lock Wait Time per Transaction LCKTX = Time database waited on locks (ms) / TX Count

29 What are different Lock matrix indicate What are different lock matric indicate :  Number Lock held.  Total Lock wait time.  Snapshot timestamp  Application Id  Application status  Status Change time  Look for “Application status =“ basically lock waiting.

30 Snapshot Analysis Problem Analysis for the Query  Number Rows read per execution.  Execution time per execution.  System CPU time per execution.  Rows returned per execution.  Look for Buffer pool Data read (logical + physical)  Look for Buffer pool index read (logical + physical)  Look for temporary xml read (logical + physical)  Look for Sort time/ Number of sort/Sort overflow

31 Snapshot Analysis Catalog Cache Analysis : The Catalog Cache Hit Ratio (CATHR) CATHR = ( Catalog cache inserts * 100 / Catalog cache lookups ) The Catalog Cache Hit Ratio should generally be at least 95%, and most shops are able to achieve this rather easily. If you find that your CATHR is less than 95%, then you will want to increase DB CFG parameter CATALOGCACHE_SZ in gradual 5% increments, or 16 4K pages, whichever is greater, until such time as you successfully achieve the 95% goal.

32 Snapshot Analysis What are different application matrix indicate :  Application status  Status change time  Application idle time = 2 minutes 22 seconds (example)  Look for Lock section in the transaction  Locks held by application  Lock waits since connect  Time application waited on locks (ms)  Deadlocks detected  Lock escalations  Exclusive lock escalations  Number of Lock Timeouts since connected  Total time UOW waited on locks (ms)  Sort related counter (Total sort/Total sort time/overflow)  Rows deleted/ inserted/updated  Rows selected (If this value is higher then application is reading too much data)  Rows written

33 DB2 Administrative View  The system-defined routines and views provide a primary, easy-to-use programmatic interface to administer and use DB2® through SQL. They encompass a collection of built- in views, table functions, procedures, and scalar functions for performing a variety of DB2 tasks.  Refer db2.luw.sql.rtn.doc/doc/c html db2.luw.sql.rtn.doc/doc/c html  SysIBMAdm (Administrative view) and Sysproc (Table Functions)

34 DB2 Administrative View  Db2 “list tables for schema sysibmadm” | grep –i “mon_”

35 DB2 Administrative View  MON_DB_SUMMARY  MON_GET_APPL_LOCKWAIT  MON_GET_BUFFERPOOL  MON_GET_INDEX  MON_GET_LOCKS  MON_GET_TABLE  MON_GET_TABLESPACE  MON_GET_PKG_CACHE_STMT

How to use the database level matrix to overall performance of system How to relate the same into the Administrative view Summary

Questions