Path Check gives your DB2 developers and DBAs the ability to identify potential access path changes before they occur. A major problem in nearly all DB2 environments is the need to respond to performance degradation stemming from unexpected access path changes.

Using Path Check, developers can preview access path changes that may occur due to development, migration or system activity, and decide on a course of action before the change impacts the production DB2 environment. It also helps DBA's verify changes to access paths, eliminating the risks of "Access Path Roulette".

Path Check tests the access paths for a program (DBRM) without requiring a bind. It examines each SQL statement in a DBRM and issues an EXPLAIN request for access path information. It then compares the EXPLAIN to the original access path from the backup PLAN_TABLE. Path Check does not invoke BIND processing, so there is no impact on the existing production environment. It reports both the old and new access paths in the PLAN_TABLE. It can report on all access paths or just those that have changed.

The user can compare the access path from PLAN_TABLE after the bind process to the backup PLAN_TABLE. It then produces a concise report of the existing access path from PLAN_TABLE. Path Check works with any valid DB2 PLAN_TABLE and will compare available data even if two PLAN_TABLEs do not contain the same number of columns. It can be used to safely test changes to catalog statistics, changes from RUNSTATS and migrations to different environments (DB2 or CPU changes).

Path Check eliminates the surprise of unexpected access path changes as programs are migrated or rebound. Resources can be devoted to more critical issues with savings in time and cost of operations. Both application development and DBA activities are enhanced.