One important cost metric for measuring tuning efficiency and effectiveness is "Hash Joins per 1,000 Transactions." DB2 may perform a hash join when there is an equal predicate between two columns of the same data type, and one or more of the columns does not have an index defined. Thus, the presense of hash joins suggests that one or more potential indexes are undefined.
The formula is:
HJ/1000TX = (TOTAL_HASH_JOINS * 1000) / ( COMMIT_SQL_STMTS + ROLLBACK_SQL_STMTS)
After implementing a new index or other physical design change, monitor "Hash Joins/1000 TX" to verify that average hash join cost is indeed going down. If the cost metric goes up, it may be appropriate to back out a recent physical design change.
The trick, of course, is knowing which missing indexes need to be created. To find out, use the SQL Equalization and Cost Aggregation technique to aggregate statements according to highest CPU costs (DBI recommends using pureFeat for DB2 LUW to automate this analysis (per US Patent #6,772,411)). Explain the statements having the highest CPU costs and look for the presence of the Hash Join method. Alternatively, review the statement text WHERE clauses and query the Catalog to determine missing indexes.