Jeg skrev sidste år et tip om REBIND med APREUSE(WARN) og nu har jeg fået lidt praktisk erfaring med netop denne option. Vi har på min installation besluttet, at alle DB2 packages, der sidst er lavet BIND af på version 10 eller tidligere, og som bruger en vis mængde CPU skal REBINDes på version 11. Til dette formål er option APREUSE(WARN) helt perfekt.
REBIND kvitterer pænt med noget ekstra output omkring brugen af denne option. Du får lige et eksempel:
REBIND PACKAGE(MYCOLL.MYDB2PGM.()) APREUSE(WARN)
DSNT286I -DB2A: DSNTBBP2 REBIND FOR PACKAGE =
DB2A.MYCOLL.MYDB2PGM,
USE OF APREUSE RESULTS IN:
3 STATEMENTS WHERE APREUSE IS SUCCESSFUL
1 STATEMENTS WHERE APREUSE IS EITHER NOT SUCCESSFUL
OR PARTIALLY SUCCESSFUL
0 STATEMENTS WHERE APREUSE COULD NOT BE PERFORMED
0 STATEMENTS WHERE APREUSE WAS SUPPRESSED BY OTHER HINTS.
Og så er der alt det andet sædvanlige output fra REBINDen. Jeg har endnu ikke set andet end 0 i de to sidste muligheder. Det spændende er, hvad der så lige fik DB2 til at mene, at et statement ikke var en 100 procent succes. Hvis din DB2 package var bind'et med EXPLAIN(YES), så kan du faktisk blive klogere ved at kigge i PLAN_TABLE. Jeg har lavet et kondenseret udtræk herfra for ovenstående REBIND. Det er specielt kolonnerne HINT_USED og REMARKS, der er interessante:
PROGNAME STMT HINT_USED REMARKS --------+-----+----------+------------------------------------------------------------------ MYDB2PGM 1183 MYDB2PGM 1183 APREUSE FAILURE (REASON: 40) APCOMPARE FAILURE (COLUMN: MIXOPSEQ) MYDB2PGM 1641 APREUSE MYDB2PGM 1684 APREUSE MYDB2PGM 1730 APREUSE
Her kan jeg så konstatere, at det er det første SQL statement i programmet, som DB2 11 ikke kan lave 100 procent reuse af. Og så er grunden tilsyneladende en fejl 40. Men hvor slår du lige den op. Jo den er beskrevet under SQLCODE +395. her kan jeg så læse, at indexet, der forsøges benyttet, ikke kan bruges længere, og derfor har DB2 valgt en anden accessvej. Og så skal du selvfølgelig være på vagt. Er den nye accessvej bedre eller dårligere end den gamle, men det ved du sikkert alt om allerede. Læg i øvrigt mærke til, at kolonnen HINT_USED er udfyldt med APREUSE for alle de statements, hvor den gamle accessvej er blevet benyttet. Det er altså en ekstremt dårlig ide at benytte værdien APREUSE som OPTHINT. Bemærk i øvrigt parentesen, hvor det er beskrevet, hvilken kolonne der volder REBINDen problemer.
En sidste detalje, jeg blev ramt af, er, at jeg ikke har angivet nogen værdi for alle de andre BIND options, for så får jeg jo dem fra den tidligere BIND eller REBIND. Det passer så desværre ikke helt. Option APPLCOMPAT benytter ikke den gamle værdi, men den i den nye APPLCOMPAT DSNZPARM værdi. Her blev jeg ramt af, at APPLCOMPAT(V11R1) er mere restriktiv end APPLCOMPAT(V10R1), når det kommer til formatet på timestamps. Så den berømte IBM bagudkompabilitet holder desværre ikke altid.