Noget der kan give enhver DB2 DBA sved på panden er, når der er blevet kørt RUNSTATS på centrale tabeller. Nu skal man til at beslutte sig for at køre REBIND af de packages, der access'er disse tabeller. Hvis access vejen ændrer sig, så kan det få stor betydning for performance i den efterfølgende tid. Derfor er det ikke altid, at der bliver foretaget REBIND efter RUNSTATS kørsler.

Det vil være rart at vide, hvad den nye access vej bliver inden man foretager en REBIND. Desværre findes der ikke en REBIND EXPLAIN(ONLY) option til REBIND kommandoen, men på den nyligt afholdte IDUG konference i Berlin foreslog IBM, at man i stedet laver en BIND COPY til en dummy collection. Det synes jeg er en kanon god ide, som hermed er bragt videre til dig.

BIND COPY laver en en nøjagtig kopi af den package, man kopierer fra, i en anden collection. Under kopieringen gennemgår den nye package samme proces som foretages under REBIND og resultatet er, at kopien af den oprindelige package får de access veje, som den oprindelige package vil få efter en REBIND. Nu er der sådan set ikke andet tilbage end at sammenligne access vejen for den nye package med den oprindelige. Hvis de er ens, så behøver man ikke REBIND'e. Hvis de er forskellige, så må man vurdere om den nye access vej er bedre eller dårligere end den gamle og ud fra denne vurdering beslutte om man vil REBIND'e eller ej.