{"id":34625,"date":"2018-04-05T09:30:51","date_gmt":"2018-04-05T16:30:51","guid":{"rendered":"https:\/\/virtual-dba.com\/?p=34625"},"modified":"2021-02-10T18:20:00","modified_gmt":"2021-02-11T01:20:00","slug":"index-read-efficiency-db2","status":"publish","type":"post","link":"https:\/\/virtual-dba.com\/blog\/index-read-efficiency-db2\/","title":{"rendered":"Index Read Efficiency – A Key Performance Indicator for Db2"},"content":{"rendered":"

My top metric for analyzing database performance is index read efficiency. This metric essentially shows how well indexed a database is for the workload that runs against it. Index read efficiency is calculated by taking the rows read and dividing them by the rows returned. The value tells us, on average, how many rows Db2 had to read in order to return one row – essentially how well indexed this database is for the workload that runs against it. A poor index read efficiency is the number two predictor, after current runstats, of a database that is likely to have performance problems.<\/p>\n

Calculating Index Read Efficiency<\/h2>\n

The values are available in a number of different places to allow you to calculate it at a number of different levels:<\/p>\n

\"value<\/p>\n

The general calculation at any of these levels is:<\/p>\n

\"index<\/p>\n

Sometimes “Rows Returned” is referred to as “Rows Selected”, depending on the location.<\/p>\n

My favorite level to calculate it at is at the database level. Here is a query to calculate index read efficiency at the database level, since the last database activation:<\/p>\n

select  case when rows_returned > 0\n                then decimal(float(rows_read)\/float(rows_returned),10,5)\n                else -1\n        end as read_eff\nfrom table(mon_get_database(-2))\nwith ur;\nREAD_EFF\n------------------\n          65.79791\n  1 record(s) selected.\n<\/code><\/pre>\n
For OLTP or other transaction processing databases, we aim for an index read efficiency of 10 or less. Here is the general spectrum of values:<\/p>\n
\"spectrum<\/p>\n
Improving Index Read Efficiency<\/h2>\n
The options to improve index read efficiency are much more complicated that calculating the value.Often a DBA will identify problematic SQL<\/a>. This is a good query against MON_GET_PKG_CACHE_STMT to use:<\/p>\n
WITH SUM_TAB (SUM_RR, SUM_CPU, SUM_EXEC, SUM_SORT, SUM_NUM_EXEC) AS (\n        SELECT  FLOAT(SUM(ROWS_READ)),\n                FLOAT(SUM(TOTAL_CPU_TIME)),\n                FLOAT(SUM(STMT_EXEC_TIME)),\n                FLOAT(SUM(TOTAL_SECTION_SORT_TIME)),\n                FLOAT(SUM(NUM_EXECUTIONS))\n            FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T\n        )\nSELECT\n        SUBSTR(STMT_TEXT,1,10) as STATEMENT,\n        ROWS_READ,\n        DECIMAL(100*(FLOAT(ROWS_READ)\/SUM_TAB.SUM_RR),5,2) AS PCT_TOT_RR,\n        TOTAL_CPU_TIME,\n        DECIMAL(100*(FLOAT(TOTAL_CPU_TIME)\/SUM_TAB.SUM_CPU),5,2) AS PCT_TOT_CPU,\n        STMT_EXEC_TIME,\n        DECIMAL(100*(FLOAT(STMT_EXEC_TIME)\/SUM_TAB.SUM_EXEC),5,2) AS PCT_TOT_EXEC,\n        TOTAL_SECTION_SORT_TIME,\n        DECIMAL(100*(FLOAT(TOTAL_SECTION_SORT_TIME)\/SUM_TAB.SUM_SORT),5,2) AS PCT_TOT_SRT,\n        NUM_EXECUTIONS,\n        DECIMAL(100*(FLOAT(NUM_EXECUTIONS)\/SUM_TAB.SUM_NUM_EXEC),5,2) AS PCT_TOT_EXEC,\n        DECIMAL(FLOAT(STMT_EXEC_TIME)\/FLOAT(NUM_EXECUTIONS),10,2) AS AVG_EXEC_TIME\n    FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T, SUM_TAB\n    WHERE DECIMAL(100*(FLOAT(ROWS_READ)\/SUM_TAB.SUM_RR),5,2) > 10\n        OR DECIMAL(100*(FLOAT(TOTAL_CPU_TIME)\/SUM_TAB.SUM_CPU),5,2) >10\n        OR DECIMAL(100*(FLOAT(STMT_EXEC_TIME)\/SUM_TAB.SUM_EXEC),5,2) >10\n        OR DECIMAL(100*(FLOAT(TOTAL_SECTION_SORT_TIME)\/SUM_TAB.SUM_SORT),5,2) >10\n        OR DECIMAL(100*(FLOAT(NUM_EXECUTIONS)\/SUM_TAB.SUM_NUM_EXEC),5,2) >10\n    ORDER BY ROWS_READ DESC FETCH FIRST 20 ROWS ONLY WITH UR;\n<\/code><\/pre>\n
Sample output:<\/p>\n
STATEMENT  ROWS_READ            PCT_TOT_RR TOTAL_CPU_TIME       PCT_TOT_CPU STMT_EXEC_TIME       PCT_TOT_EXEC TOTAL_SECTION_SORT_TIME PCT_TOT_SRT NUM_EXECUTIONS       PCT_TOT_EXEC AVG_EXEC_TIME\n---------- -------------------- ---------- -------------------- ----------- -------------------- ------------ ----------------------- ----------- -------------------- ------------ -------------\nSELECT ACA              5671140      81.71               657030        1.13                 1422         0.76                       0        0.00                 1860         6.92          0.76\nWITH SYSIB               865658      12.47              1813570        3.12                 2903         1.56                       4        4.04                  214         0.79         13.56\nselect sna                62808       0.90                17975        0.03                   29         0.01                      13       13.13                   16         0.05          1.81\nCALL SYSIB                 9418       0.13             17493719       30.18                45506        24.50                       0        0.00                 2121         7.89         21.45\nSELECT T.t                 6600       0.09               383749        0.66                  617         0.33                      62       62.62                 2200         8.18          0.28\nselect str                 4353       0.06                52841        0.09                24344        13.10                       2        2.02                    3         0.01       8114.66\nCALL SYSIB                   41       0.00             34754421       59.97                61356        33.03                       0        0.00                 2949        10.97         20.80\n\n  7 record(s) selected.\n<\/code><\/pre>\n
Though complicated, this query helps to identify queries that are a problem in terms of key database resources and reports their impact as a percentage of that resource used by all other queries in the package cache<\/a>. The queries in this result set with a high percentage of rows read are most likely to be negatively impacting the index read efficiency for the database.<\/p>\n
After identifying the problematic queries, these are the most common actions to take to improve query performance and index read efficiency:<\/p>\n