Gik kontoen i overtræk på grund af for dyrt indkøbte julegaver? Hvor meget kostede den flaske champagne egentlig, som jeg i et anfald af løssluppen nytårsfeststemning købte sent nytårsnat?
Den slags spørgsmål var der tilsyneladende mange af kunderne i 79 lokalbanker og sparekasser, der stillede sig selv i starten af denne uge.
Kunderne følte sig nødsaget til at tjekke deres konti for at få svar på spørgsmålene. Via internettet og filialsystemerne blev usædvanligt mange forespørgsler sendt til systemerne Portalbank og Kernesystem, som er udviklet af SDC.
Mandag klokken 10 om formiddagen opstod de første problemer.
IBM-database fejlede
Ifølge Erik Jakobsen, direktør for SDC Udvikling, fik de mange forespørgsler systemernes underliggende DB2-database til at fejle.
? Der havde været mange brugerforespørgsler. Fra home-banking kom der mange transaktioner og kombineret med mange forespørgsler fra filialerne, fik det databasen til at fejle, siger Erik Jacobsen.
Han understreger, at der ikke var problemer med Kernesystem, men at det var DB2, der fejlede.
Ifølge SDC Udvikling blev DB2's EDM-pool (se forklaring om pools) fyldt op som følge af presset på systemet.
| DB2 og pools En pool ? eller pulje ? er et område af memory, der er reserveret til at indeholde data til specifikke formål. IBM-databasen DB2 bruger fire typer pools ? bufferpools, EDM pool, RID pool og sort pool ? til at cache information i memory. Jo mere information, der kan caches i memory, jo bedre ydelse vil det give DB2, da der ikke hele tiden skal læses fra diske. Der kan dog også indlæses for meget information i cachen som denne uges nedbrud i SDC?s Portalbank og Kernesystem viste. Buffer pools anvendes af DB2 til at gemme data, der er læst fra disken. Der er 80 forskellige bufferpools. Når en applikation beder om data, tjekker DB2 om data allerede findes i bufferpools. Derved kan en I/O-operation spares, hvilket forbedrer performance. EDM-poolen anvendes af DB2 til at kontrollere applikationernes adgang til databasen. Her lagres blandt andet information om adgangsvejen til data (access paths) for de kørende programmers SQL-statements. Hvis applikationerne anvender dynamisk SQL, anvendes EDM-poolen også til at cache den statiske del af SQL'en (dynamisk SQL prepare information). Endelig indeholder EDM-poolen information om databaserne, som de kørende programmer anvender. Tilsyneladende var al pladsen i EDM-poolen blevet brugt i SDC tilfældet. RID pool anvendes af DB2 til at sortere Record Identifiers i forbindelse med list prefetch, multiple index access og hybrid join access paths. Sort pool anvendes af DB2 til at lave intern sortering af data i memory. |
EDM-poolen kunne adressere op til 1,5 gigabyte i memory, men det var ikke nok. De mange transaktioner betød, at EDM-poolen brugte al den afsatte plads, hvorefter DB2 tilsyneladende lukkede databaserne ned på en uhensigtsmæssig måde.
? Presset på systemerne betød, at DB2 smækkede nogle af databaserne hårdt ned. Ved genstart af systemerne kunne DB2 ikke som normalt automatisk allokere mere plads til tabellerne, beretter Erik Jakobsen.
Ikke helt i sort
På trods af problemerne var systemerne dog ikke gået helt i sort.
? Vi fik en million transaktioner på Kernesystem og cirka 600.000 homebanking-transaktioner igennem mandag og tirsdag. På nogle tidspunkter var der dog helt lukket af for systemet, så vi kunne ordne problemet, oplyser Erik Jakobsen.
Ifølge Erik Jakobsen har SDC Udvikling omgået fejlen ved at ændre en række af DB2's parametre. Ved at begrænse antallet af samtidige transaktioner undgår man at EDM-poolen forbruger alle 1,5 gigabyte.
I løbet af ugen forlød det, at fejlen var opstået i forbindelse med et serverskift, men den historie maner Erik Jakobsen i jorden.
? Vi rører ikke vores produktionssystem fra medio december til medio januar, oplyser Erik Jakobsen og gentager, at nedbruddet skyldtes en fejl i DB2.
? Hvis databasen er ved at bruge det maksimale antal ressourcer, skal den ikke fejle. Den skal lukke pænt ned i stedet for at smække ting ned om ørerne på os, siger Erik Jakobsen.
Fix til DB2
Onsdag formiddag var der, ifølge Erik Jakobsen, ved at blive lagt en fix på DB2, der skulle løse problemet.
Hos IBM Danmark lægger kommunikationschef Anders Lund Rendtorff vægt på, at IBM i samarbejde med SDC Udvikling i løbet af tirsdagen fik identificeret problemet.
? Vi er meget glade for at vi arbejdede sammen med kunden, og at vi fik koblet den rette kompetence på, så vi i fællesskab kunne få løst problemet, siger Anders Lund Rendtorff og fortsætter:
? I den fase hvor vi analyserede, hvad problemet var, koblede vi DB2-laboratorierne i Frankrig og USA på sagen.
Ifølge Anders Lund Rendtorff er DB2-fix'et til SDC rettet specielt mod SDC's driftsmiljø og der vil ikke blive udsendt en generel DB2-patch som følge af SDC-nedbruddet.
Anders Lund Rendtorff understreger også, at der ikke er nogen paralleller til Danske Bank-sagen fra 2003, hvor Danske Banks systemer som følge af fire forskellige fejl var nede i fem dage.
