Mange moderne applikationer bruger DB2 på z/OS som database server via DRDA. Disse applikationer bruger typisk også dynamisk SQL, hvilket umuliggør brug af SET statementet, som kun kan bruges i statisk SQL. Her kommer SYSDUMMY1 tabellen ind i billedet, da den kan bruges som erstatning. Et typisk eksempel er at få fat i CURRENT TIMESTAMP:
I statisk SQL skriver man i stedet SET :hostvar = CURRENT TIMESTAMP. Den store forskel er den tid og det CPU forbrug, der knytter sig til de to statements. SET kommandoen tager hverken særlig lang tid eller koster ret meget. Helt anderledes forholder det sig med SELECT udgaven. Rent faktisk foretager DB2 for z/OS en læsning af tabellens ene række, og det koster ret meget CPU i forhold til SET og tager også længere tid.
Heldigvis indførte DB2 i version 8 muligheden for at kortslutte læsningen af tabellerne i et SELECT statement. En kortslutning sker, hvis WHERE-clausen med sikkerhed ikke returnerer nogen rækker, som for eksempel en WHERE 0=1. Det kalder DB2 at PRUNE. Dette trick kan benyttes til at optimere ovenstående SELECT:
Men hov, det giver jo ikke mening, for nu får vi jo ikke returneret nogen værdi. Det er rigtigt, men vi kan snyde med en kolonne-funktion, som MAX eller MIN, som vil tvinge DB2 til at returnere en NULL værdi, når der ikke er noget resultat. Og så kan vi bruge VALUE til at konvertere NULL til en brugbar værdi:
Denne SELECT returnerer også CURRENT TIMESTAMP, men uden at læse SYSDUMMY1 tabellen. Mine målinger viser, at dette statement har et CPU forbrug, der er 1/3 til 1/4 af det oprindelige. Med andre ord kan det optimerede statement udføres tre til fire gange før det har brugt lige som meget CPU som det oprindelige. Det er da værd at tage med, især hvis det oprindelige statement udføres rigtig tit.
Læg mærke til, at tricket kan bruges på alle mulige udgaver af SELECT expression FROM SYSIBM.SYSDUMMY1, hvor expression omkranses af en MIN eller MAX og expression gentages i en VALUE. Det er i øvrigt med fuldt overlæg, at jeg har skrevet DB2 på z/OS, da DB2 for LUW virker anderledes med hensyn til brugen af SYSDUMMY1 tabellen.