Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks

For efficient join performance, it is important that an index exists to support the
join predicates, regardless of the table size (small or large). For anything other
than very small dimensions/master data tables (a few data pages), you must
ensure that these tables have indexes that support the join and local filtering
predicates. This will ensure efficient nested loop join performance for all tables.
Local predicates are preferred as the leading index columns because they
support this table accessed as the leading table accessed or non-leading of a
table join sequence. Additionally, they allow frequency statistics to be collected
on the local predicate column with default RUNSTATS. Both the local and join
predicates should be included in the index because both columns provide
filtering as part of the join — that is, unless the dimension/master data table is
very small, in which case an index on the join predicate alone may be sufficient
for join performance.
Aside from data access and join performance, statistics collection on the
dimension and master data tables becomes very important. An incorrect
estimation of filtering from dimension/snowflake will propagate to the large
facttable. Thus a 10% error in estimation on a 100-row dimension is only 10
rows, but when joined to the facttable (10 million), the error factor becomes 1
million rows.
Single column indexes that support the local predicates on the dimension and
master data tables allow frequency statistics to be collected by default. For
dimensions/master data tables that have multiple filtering predicates, indexes
that contain all filtering columns allow default collection of correlation information
on these tables. This information is crucial for correct access path selection (and
table join sequence).
Dimensions and master data tables (large or small) can support many more
indexes than can multi-million row facttables. This should be encouraged for the
purpose of efficient data access/join performance, and also for effective statistics
collection.
Chapter 10. Tips for SQL efficiency 225