MainframeSupports
tip uge 4/2000:

For os, der har sloges med DB2-optimizeren i mange år, så er der altid et nyt slagsmål i enhver ny version af DB2. Her i MainframeSupport har vi "hygget" os med, at optimizeren under visse omstændigheder i DB2 version 5 giver forskellige access-veje afhængig af hvilken rækkefølge, man angiver sine host-variable og konstanter i en IN-liste.

Følgende eksempel illustrerer problemstillingen:

SELECT * FROM MYTABLE
WHERE FIRSTINDEXCOL IN(:hostvariable, 'SOME-VALUE')

Kolonnen FIRSTINDEXCOL er den første kolonne i et index og har en skæv fordeling af værdier, som vel at mærke er registreret af DB2 i SYSIBM.SYSCOLDIST, fordi der er kørt RUNSTATS på MYTABLE. Lidt afhængig af, hvor skæv fordelingen er, så vil optimizeren vælge en anden access-vej, hvis man i stedet skriver IN ('SOME-VALUE', :hostvariable).

Nu er det sådan set op til dig at beslutte, hvilken access-vej, du synes bedst om, at optimizeren skal vælge. Hvis dit SQL-kald lige nu er FIRSTINDEXCOL = :hostvariable, så kan du prøve med IN (<CONSTANT>, :hostvariable), hvor du er sikker på, at <CONSTANT> ikke kommer til at findes som værdi i FIRSTINDEXCOL.

En helt anden mulighed er at overveje, at lave BIND med REOPT(VARS), som vil basere access-vejen på det konkrete indhold af din host-variabel. Men først og fremmest er det vigtigt at prøve sig frem. Nogle gange er optimizerens valg faktisk ikke så tåbelige, som vi gerne vil gøre dem til.

Sidste uges tip        Tip oversigten