I løbet af de sidste mange år er mængden af dynamisk SQL, der håndteres af DB2 på mainframen, eksploderet. Dynamisk SQL kræver for hvert SQL-kald, at DB2 evaluerer accessvejen. Det kan som bekendt klares een gang for alle ved BIND af statisk SQL. For at optimere på dynamisk SQL indførte IBM for mange år siden en såkaldt dynamisk statement cache i DB2. I denne cache gemmes teksten for et dynamisk SQL-kald sammen med accessvejen. Teksten i hvert eneste dynamiske SQL-kald sammenlignes med teksterne i den dynamiske statement cache. Hvis teksten stemmer overens med et cached SQL-kald, så benyttes accessvejen fra det tidligere udførte SQL-kald, og evalueringen af accessvejen spares.
Før DB2 version 8 kunne du som udvikler ikke rigtig bruge denne statement cache til noget. Den var ene og alene et værktøj, som DBA'er og systemprogrammører kunne bruge til at optimere DB2 performance med. Men i DB2 version 8 skete der noget. EXPLAIN statementet blev udvidet, så det nu er muligt at se de dynamiske SQL-kald, der ligger i statement cachen. Du kan også se, hvilken accessvej, de er blevet udført med. Endnu bedre er, at du faktisk er i stand til at se, hvor mange ressourcer, der er blevet brugt på at udføre de forskellige SQL-kald i statement cachen. Det er faktisk en ren guldgrube for dig, hvis du interesserer dig lidt for SQL-performance.
Du kan udføre de følgende SQL-kald for at trække indholdet af statement cachen ud:
Det centrale SQL-kald er EXPLAIN STMTCACHE ALL, som udskriver indholdet af statement cachen til DB2-tabellen DSN_STATEMENT_CACHE_TABLE. Det SQLID, der udfører oventående SQL-kald skal altså have oprettet en DB2-tabel kaldet DSN_STATEMENT_CACHE_TABLE før ovenstående SQL-kald udføres. Når EXPLAIN STMTCACHE ALL udføres, kigger DB2 på, hvilke autorisationer det pågældende SQLID er i besiddelse af. Hvis SQLID har SYSADM autorisation, så udskrives alt indholdet af statement cachen. Hvis ikke, så udskrives kun de statements, som er udført af SQLID. I praksis betyder dette, at du kun får udskrevet de SQL-kald, du selv har udført, med mindre du har SYSADM-autorisation.
Jeg har lavet en DELETE FROM DSN_STATEMENT_CACHE_TABLE før EXPLAIN STMTCACHE ALL, fordi EXPLAIN STMTCACHE ALL kun inserter rækker i DSN_STATEMENT_CACHE_TABLE. Hvis du ikke sletter rækkerne får du altså indblik i historikken i statement cachen. Prøv det, så vil du helt sikkert lære mere om, hvordan statement cachen virker.
Det er selvfølgelig ret centralt for at ovenstående virker, at du har fået oprettet en DSN_STATEMENT_CACHE_TABLE. Du kan bruge den CREATE TABLE, der findes i SQL Reference. Der kan du også læse, hvad de forskellige kolonner indeholder. I DB2 version 9 vil DB2 automatisk oprette de tilhørende LOB-objekter. Det sker desværre ikke i DB2 version 8. Hvis du stadig bruger DB2 version 8, så skal du ud over den beskrevne CREATE TABLE også udføre følgende SQL-kald:
Husk at erstatte userid med dit eget userid eller noget andet entydigt. Nogen installationer fjerner i øvrigt udvikleres autorisationer til at kunne oprette tabeller i DSNDB04. Her må du søge hjælp hos dine DBA'er for at komme videre, hvis du har problemer med at oprette objekter i DSNDB04.
Når du endelig har fået EXPLAIN STMTCACHE ALL til at virke, så kan det være, at kolonnerne med de rigtig spændende informationer (alle STAT_-kolonnerne) står til 0. Det er fordi, at DB2 systemprogrammørerne eller DBA'erne enten har glemt eller har fravalgt at starte den DB2 TRACE, der opsamler disse tal. Du kan bede dem om at udføre en -START TRACE(MON) IFCID(318), så vil det virke. Jeg vil i øvrigt vende tilbage med flere tip om statement cachen, da dette tip kun lige kradser i overfladen.