En af vore kollegaer, har fået et nyt job og starter 1. april. Derfor var vi DBA'ere samlet her forleden, til at overtage hendes databaser - og det betyder lidt mere arbejde til os andre, indtil der kommer en og udfylder "hullet". I samme forbindelse, sad jeg og gennemgik mine nye setups, og dertil hørende logs her til morgen. En af databaserne (produktion), syntes at rapportere den samme fejl hvert 5 minut.

Jeg ringede op til system ejeren, for dels at sige hej, da det nu er mit drift område, og dels høre lidt om fejlen eller om de havde set den før. Han kunne fortælle der aldrig havde været fejl på systemet, så det kom derfor helt bag på ham at jeg ringende og sagde der var fejl - det kunne ikke passe.

Jeg kunne fortælle system ejeren, at den alert.log fil jeg sad med gik tilbage til 28 mar 2007 (opkaldet til ham foretog jeg den 19 apr 2007), og det kom selfølgelig bag på ham. Det eneste der var sket fysisk, som han husker det, var en database opgradering fra 9 til 10G i september 2006. Jeg vil næsten tro han har haft fejlen siden, men det er min påstand.

Jeg kastede mig efterfølgende over metalink, google og andre steder, men der er meget lidt derude på dette her. Nedenfor det jeg startede, med at finde i alert.log filen.

ORA-12899 encountered when generating server alert SMG-4120
ORA-12899 encountered when generating server alert SMG-4121

ORA-12899 betyder at værdien der forsøges indsat eller opdateret, er for stor til hvad der er afsat plads til. Det er en fejl man sagtens kan se optræde hyppigt i diverse applikationer, og løsningen er typisk at gennemgå sin kode og SQL. Jeg syntes dog at fejen syntes at se lidt anderledes ud end hvad jeg havde forventet; ORA-12899 encountered when generating server alert SMG-4120. Ved at søge på metalink  er der godt nok bug 5172797 der har at gøre med noget karaktersæt noget, og det er ikke rigtig vores situation. Udover denne bug var der 2 gange 600 fejl, der heller ikke havde noget med os at gøre - og thats it. Det vil sige på google er der en kinesisk hjemmeside, på kinesisk - så der var heller ikke meget hjælp.

Tilbage med problemet alene; Ok i alert.log filen, kan jeg se dette sker hvert 5 minut. Der er sikkert et cronjob der ligger og kører eller et DBMS_JOB. Lad os kigge på cronnen da vi her i huset ikke bruger DBMS_JOB, og sørme om der ikke kører noget, der til og med stemmer med tidsstemplerne i alert'en.

03,08,13,18,23,28,33,38,43,48,53,58

Når jeg gennemgår scriptet, kan jeg se det er 3 SQL scripts. 1 der skriver til en log tabel via en procedure, og fortæller jobbet er startet. 1 der udfører 3 updates, samt det sidste der igen skriver til log tabelen og siger jeg er færdig. Det script der skriver til log tabelen hedder write_syslog.

write_syslog lagde jeg mærke til bliver kaldt fra alle cronjobs, på samme måde; før og efter - så hvis den skulle forudsage fejlen, ville der nok være en hel del flere entries i alert.log filen. Vi koncentrer os altså om de 3 updates. 

System ejeren og undertegnede gennemgik herefter koden, vi fandt dog ikke noget der var af kritisk karakter eller relateret til ORA-12899.

Tilgengæld kan man jo være lidt heldig en gang imellem, og samtidigt med ovenstående sad jeg og undersøgte omkring en ORA-13917. Se i næste skriv hvordan disse 2 måske er relaterede - det er ihvertfald mit bedste bud - husk på dette er en 10G, på Solaris 10. 10G udemærker sig bl.a. med alt det her automatiske håntering af statestikker, memory m.fl.