Filter optimization and usage
Log Master
supports very complex filters. To avoid poor performance, optimize your filters in the same way that database users optimize their SQL SELECT statements. Use the tips in this section to help you create more efficient filters, which can result in improved performance. Improvement depends on many factors in your environment, including the size of the filters that you define.
- When you request a range of Db2 objects, use IN or LIKE instead of GREATER THAN or LESS THAN to gain more efficient results. Similarly, when you request a set of similar objects, use IN or LIKE to define the set, rather than joining a list of objects together with the OR operator.
If you select objects in the Db2 catalog, specify only the most distinct object. For example, to select a given table, you do not need to specify the table space or database. From most distinct to least distinct, the order is
- Column name
- Table name (or DBID.OBID)
- Table space name (or DBID.PSID)
- Database name (or DBID )
This suggestion becomes especially important when the value of either the USELGRNG keyword or the USELGRNG installation option is YES. If you include unneeded qualifiers in your filter, you can cause Log Master to read extra log files, negating the time savings that USELGRNG provides.
If you select more than one occurrence of the same type of database object, do not use the logical OR operator to join them together. Instead, use the IN or NOT IN operators to more efficiently specify a set of objects.
Add URID-level predicates (like authorization ID or plan name) in your filter when possible, to enable pre-filtering. Doing so enables Log Master to filter out unneeded records at an earlier point in processing, and improve overall performance.
To determine the amount of pre-filtering that occurs, use the statistics displayed starting in messages BMC097583 and BMC097586.
- If the Db2 catalog in your environment contains large numbers of objects (for example, some enterprise resource planning applications generate tens of thousands of objects), avoid using the NOT operator or LIKE syntax. These types of filters cause Log Master to scan the Db2 catalog. Also consider using dynamic filtering in this environment. For more information, see the FILTER METHOD keyword in the section about FILTER METHOD.
To generate DDL statements, you might need to include some additional Db2 objects to obtain the dependent effects that you need. For example, to generate MIGRATE DDL for an entire table space, you might use a filter such as the following:
TABLESPACE NAME = DTBS01.TBLSPC01Using this filter, Log Master generates DDL statements to create the table space and the tables within it, but does not generate statements to create the indexes on the various tables. To create the table space, the tables, and the indexes, use a filter such as the following (where the names of all tables in the table space begin with the characters SPC01):
TABLESPACE NAME = DTBS01.TBLSPC01
OR
TABLE NAME LIKE OWNER01.SPC01TB*
Related topic