REBIND

REBIND refreshes an existing package or plan without a fresh BIND. It reuses the bind options already stored in the catalog.

What REBIND does

• It re-binds an existing package or plan using the SQL and bind options already saved in the DB2 catalog.
• You do not supply the DBRM again. DB2 reuses the stored SQL statements.
• The optimizer re-chooses access paths based on current statistics and indexes.
• It is faster and safer than a full BIND because all your original bind options are preserved.

REBIND PACKAGE vs REBIND PLAN

• REBIND PACKAGE (collection.package) - refreshes one program's access paths. This is the common case.
• REBIND PLAN (planname) - refreshes the plan itself, needed after PKLIST-affecting changes or plan-level invalidation.
• Rebinding a package does not rebind the plan, and rebinding the plan does not rebind its packages. They are separate steps.

When to rebind

• After RUNSTATS on tables your SQL touches, so the optimizer sees fresh statistics.
• After creating or dropping indexes that affect the access path.
• After DB2 version upgrades or maintenance that changes optimizer behavior.
• To fix -805 or -818 inconsistencies after restores or load-module copies.
• After DDL changes (like ALTER TABLE) that marked the package invalid.

Example: REBIND control cards

• Refresh one package, then refresh the plan that references it:
  
  DSN SYSTEM(DB2A) REBIND PACKAGE (MYCOLL.PROG1) REBIND PLAN (MYPLAN) END