Lige siden DB2 version 4 kom på gaden har det været muligt at lave såkaldte dirty reads i DB2. Faktisk er det så snedigt implementeret, at man pr. SQL-kald kan bestemme om man vil lave dirty reads eller ej. Nu vil der nok være en del af jer, der straks vil sige, at det her er jo gamle nyheder, men jeg har konstateret, at der er rigtig mange, der ikke kender til muligheden for at lave dirty reads.
Dirty reads er, når man læser rækker, der er insert'et eller update't af en anden samtidig kørende proces, men endnu ikke er blevet commit'ted. Og det er rent data-integritetsmæssigt noget forfældeligt snavs, deraf ordet dirty read. Derfor er muligheden for dirty reads da også noget, man skal benytte med stor varsomhed. Dirty reads er blevet indført i DB2, fordi det har man kunnet længe i Oracle og ikke mindst fordi, at man slipper for låse-problematikken med en del bedre performance som følgevirkning.
Den letteste måde at bruge dirty reads på er ved at benytte option WITH UR allersidst i sit SQL SELECT-kald. UR står for Uncommitted Read. Problemet er bare, at WITH UR kun må benyttes på SELECT-kald, der returnerer såkaldt READ ONLY resultater. Heldigvis kan man tvinge sit SELECT-kald til altid at levere et READ ONLY resultat ved at benytte option FOR FETCH ONLY. Hvis man vil lave et SELECT-kald, der laver dirty reads, er det allermest hensigstmæssige altså at tilføje FOR FETCH ONLY WITH UR allersidst i SELECT-kaldet.
Jeg kan kun anbefale at benytte dirty reads i dynamiske SQL-kald som for eksempel fra QMF eller SPUFI eller lignende. Og kun når man ikke har behov for et 100% korrekt resultat. Når det så er sagt, så kan jeg konstatere, at 95% af alle de dynamiske SQL-kald, jeg laver, ikke kræver 100% korrekte resultater. Jeg skal bare lige kigge lidt på data-indholdet af en eller anden tabel. Eller måske skal jeg lave lidt statistik. Bare tænk på runstats informationerne i DB2. De er langt fra korrekte. Og fidusen er, at jeg sparer DB2 for en masse energi og får resultatet lidt hurtigere, hver gang jeg benytter FOR FETCH ONLY WITH UR.
En anden fidus ved dirty reads i DB2 er, at man aldrig risikerer at få eller skabe hverken timeout eller deadlock. De af os, der ind imellem har behov for at kigge på produktionsdata, vil sætte stor pris på ikke at spænde ben for brugerne eller produktionsbatch'en. Den eneste påvirkning dirty reads har i et produktionsmiljø, er den CPU-tid og I/O-tid, der skal til for at gennemføre SELECT-kaldet.