Er du irriteret over nogen gange at få dit SQL kald afsluttet med SQLCODE -905, så kan dette tip måske hjælpe dig. En SQLCODE -905 betyder, at DB2 Governor er aktiv på den DB2, som du udsteder SQL kaldet fra, og at dit SQL kald har forbrudt sig mod en af de regler, der er defineret i DB2 Governor. DB2 Governor stander et SQL kald, der har forbrugt for meget CPU i henhold til reglerne. Når du får en -905 er det altså fordi dit SQL-kald har brugt for meget CPU. DB2 Governor kaldes i øvrigt også for Resource Limit Facility (RLF).

Hvis du støder på ovennævnte problem, og du absolut skal have udført dit SQL, så er der mange måder at omgå problemet på. Her er en liste med de fleste af mulighederne:

• Få en anden til at udføre dit SQL kald. Eksempelvis har OPC useren typisk lov til at bruge al den CPU, der skal til.
• Lav dit SQL kald om til statisk SQL ved at udføre det i et program. -905 kan du kun få i dynamisk SQL.
• Find ud af hvem, der vedligeholder reglerne i DB2 governor og få overtalt vedkommende til at give dig mere CPU, så dit SQL kald ikke bliver slået ned.
• Undersøg selv reglerne i DB2 Governor og find ud af, om du kan udføre dit SQL kald vha. et andet program, som får mere CPU. Måske får SQL udført af SAS lov til at bruge mere CPU end SQL udført af SPUFI eller QMF.
• Omskriv dit SQL kald, så det bruger mindre CPU.

Jeg vil nu beskrive de to sidste muligheder lidt nærmere. For det første er det vigtigt at forstå, at CPU begrænsningen gælder pr. SQL kald. Et SELECT statement udføres jo som en OPEN efterfulgt af et antal FETCH. Hvis din SELECT for eksempel er udstyret med en ORDER BY, som ikke kan anvende et index, så vil al CPU blive forbrugt i OPEN kaldet. Ved at fjerne ORDER BY vil CPU forbruget blive fordelt ud på hver enkelt FETCH, som hver især sandsynligvis bruger langt mindre CPU end den grænse, du støder på. Så kommer dit SQL kald igennem, men nu usorteret. Hvis du kan sende resultatet igennem DFSORT bagefter, så er du jo en glad mand. Eller også kan du sagtens undvære et sorteret resultat.

Om et SQL kald bruger al tiden i OPEN eller ej kan være svært at afgøre. Her er du nødt til at kigge på en EXPLAIN og se om der er nogen METHOD 3 rækker. Hvis der er, så sker al CPU forbruget under OPEN. Et andet problem kan være, at dit SQL kald laver tablespace scan på en meget stor tabel og det kun er få af rækkerne, der opfylder reglerne i dit SQL kald. I dette tilfælde kan en FETCH gå hen og blive så dyr, at CPU grænsen i DB2 Governor rammes, fordi DB2 skal scanne en masse rækker inden den finder en række at returnere. Du kan i disse tilfælde overveje at benytte DB2 UNLOAD utilitien, FAST UNLOAD fra CA eller tilsvarende produkt i stedet. Disse utilities kører udenom DB2 SQL processoren og dermed også udenom DB2 Governor.

Du kan også sætte dig ind i de DB2 Governor regler, som er sat op på den DB2, som giver dig problemer. DB2 Governor reglerne er gemt i en enkelt DB2 tabel, der som tabelnavn hedder noget med DSNRLST efterfulgt af to valgfrie alfanumeriske tegn. Creator'en for tabellen er også valgfri. Det eksakte navn på DSNRLST tabellen står i den SQLCA, der returneres på en -905. Herefter kan du lave en SELECT mod denne tabel for at finde ud af hvilken regel, du forbrød dig imod. Efterfølgende kan du finde ud af, om du kan komme til at falde ind under en knap så restriktiv regel.

Du kan læse alt om reglerne i DB2 Administration Guide. Bemærk, at dette link er til DB2 version 7 manualen, men der er ikke de store ændringer i forhold til version 8. Der er i hvert fald ingen ændringer i selve angivelsen og fortolkningen af reglerne.