Overbelastet database årsag til nedbrud i banksystem

Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 7. januar 2005.


Ugens nedbrud hos SDC skyldtes en fejl i en DB2-database. Årsagen var et markant stort pres på 79 bankers filialsystemer og netbank-løsninger.

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.
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. 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.
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.
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.

Billedtekst:
Ekstraordinært mange bankkunder valgte at tjekke deres konti i efter nytår. De mange forespørgsler tvang en DB2-database hos SDC Udvikling i knæ.
Foto: Torben Klint

Boks:
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.
Det er vigtigt at holde styr på størrelsen af EDM-poolen. Hvis der ikke er mere plads i EDM-poolen, vil vigtige applikationer ikke få lov til at køre.
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.




Brancheguiden
Brancheguide logo
Opdateres dagligt:
Den største og
mest komplette
oversigt
over danske
it-virksomheder
Hvad kan de? Hvor store er de? Hvor bor de?
Jobindex Media A/S
Salg af telemarketing og research for it-branchen, it-kurser og konferencer

Nøgletal og mere info om virksomheden
Skal din virksomhed med i Guiden? Klik her

Kommende events
Compliance og strategisk it-sikkerhed efter DORA

Finansielle koncerner har i snit 85 sikkerhedsløsninger i drift – men er i snit op til 100 dage om at opdage et igangværende cyberangreb. Ydermere viser øvelser, at det typisk tager 4-6 uger at rense og genetablere sikker drift af centrale systemer efter et stort angreb. Fokus for dagen vil derfor være på henholdsvis governance samt om, hvordan du som it-leder i den finansielle sektor skal kunne håndtere fremtidens cybertrusler og arbejde effektivt med sikkerhed på et strategisk niveau.

04. april 2024 | Læs mere


EA Excellence Day

Hvad er det, der gør it-arkitektens rolle så vigtig? Og hvad er det for udfordringer inden for områder som cloud, netværk og datacentre, som fylder hos nogle af landets bedste it-arkitekter lige nu? Det kan du her høre mere om og blive inspireret af på denne konference, hvor du også får lejlighed til at drøfte dette med ligesindede.

16. april 2024 | Læs mere


IAM - din genvej til højere sikkerhed uden uautoriseret adgang og datatab

På denne dag udforsker vi de nyeste strategier, værktøjer og bedste praksis inden for IAM, med det formål at styrke virksomheders sikkerhedsposition og effektiviteten af deres adgangsstyringssystemer og dermed minimere risikoen for uautoriseret adgang og datatab. Og hvordan man kommer fra at overbevise ledelsen til rent faktisk at implementere IAM?

18. april 2024 | Læs mere