Den 3. april 2003

Pressemeddelelse
Mandag den 10. marts udførte IBM’s tekniske afdeling en rutinemæssig udskiftning af en defekt strømforsyningsenhed i et disksystem fra IBM af typen RVA (Disksystem, der anvendes til lagring af data i DB2 databasesoftware) i DMdata’s driftsinstallation i Ejby. I forbindelse med reparationen skete et strømudfald i disksystemet, og konsekvensen var, at driften standsede kl. 16.08 i det ene af bankens to driftscentre (Ejby).

Udskiftningen, der tog sin begyndelse som en rutinemæssig operation, udviklede sig på grund af et sammenfald af omstændigheder til at blive ganske omfattende. Dette sammenfald udløste flere hidtil uidentificerede fejl i IBMs DB2 databasesoftware, som efterfølgende førte til en kritisk driftssituation.

Konsekvenserne har været mærkbare for Danske Bank-koncernens kunder, specielt inden for betalingsformidling samt handel med og afvikling af valuta og værdipapirer. Realkredit Danmark og Danica Pension var kun berørt i meget begrænset omfang.

Teknisk problembeskrivelse
RVA-Disken og de forretningsdata, der var lagret på den, var efter fejlen ikke længere tilgængelig for koncernens systemer. Det medførte, at den del af systemerne, der kører på driftscentret i Ejby (valuta-, fondshandel- og udlandssystemer samt betalingsformidling), standsede. Driften kunne fortsætte for de systemer, der kører på driftscentret i Brabrand (pengeautomater og selvbetjeningssystemer).

Da den fejlramte RVA-diskenhed blev klarmeldt mandag den 10. marts kl. 22:00, blev bankens systemer i Ejby genstartet som normalt efter en driftsforstyrrelse. Afviklingen af koncernens batchkørsler ( Behandling af store mængder opsamlede data fra produktsystemerne til bl.a. bogføring, print, clearing og datawarehouse) blev tirsdag kl. 01:00 startet med 6 timers forsinkelse. I løbet af tirsdag den 11. marts om morgenen kunne det konstateres, at afviklingen af koncernens batchkørsler ikke foregik korrekt.

Selvom genstarten af DB2 databasesoftwaren forløb helt normalt, var der en kombination af forhold, som medførte inkonsistens i dataene. Denne første softwarefejl i DB2 databasesoftwaren har eksisteret i samtlige installationer af DB2 databasesoftware siden 1997, uden at IBM har haft kendskab til den.

I det efterfølgende arbejde med datagenskabelsen, der varede fra tirsdag den 11. marts om morgenen til fredag morgen den 14. marts, blev der konstateret yderligere tre fejl i IBM’s DB2 databasesoftware – følgefejl som blev udløst af den oprindelige usædvanlige hændelse ved genstart af DB2 databasesoftwaren.

Den anden softwarefejl betød, at recovery processen på en række DB2 tabeller ikke kunne startes, hvilket resulterede i tidstab under retableringen.

Den tredje softwarefejl resulterede i, at recovery jobs ikke kunne gennemføres i et parallelt forløb, hvilket medførte yderligere tidstab i forbindelse med retableringen.

Den fjerde softwarefejl indebar, at recovery jobs ikke genskabte alle data på tabellerne. Denne sidste fejl, som opstod torsdag den 13. marts, resulterede i nye tilfælde af inkonsistente data, der måtte genskabes på anden vis, hvilket medførte, at processen kompliceredes yderligere og trak ud. For at undgå længere forsinkelse blev det besluttet ikke at afvente IT-leverandørens korrektion af software. I stedet blev en proces, som banken udviklede sammen med DMdata, byggende på bankens egne replicerede data fra driftscentret i Brabrand, taget i anvendelse.

Driften af systemerne i bankens driftscenter i Brabrand var principielt set upåvirket, men en række systemers funktioner var påvirket af den manglende adgang til data i driftscenter Ejby.

Torsdag den 13. marts om eftermiddagen blev en række online systemer genstartet, herunder valuta- og fondshandelssystemerne samt koncernens udlandssystemer. Natten til fredag den 14. marts blev data endelig gendannet.

Fredag den 14. marts om morgenen blev alle online systemer startet med succes, og afviklingen af batchkørsler fra mandag den 10. marts blev begyndt. Der var indlagt en række ekstraordinære kontroller i dette forløb til sikring af, at alle data var korrekt gendannet.

Batchkørslerne fra mandag den 10. marts til fredag den 14. marts blev gennemført i løbet af weekenden og tidligt mandag morgen den 17. marts var alle data fra den fejlramte diskenhed overført til andre systemer og den fejlramte diskenhed taget ud af drift.

Danske Bank havde således mandag den 17. marts afviklet de ophobede transaktioner med omverdenen og fungerede i øvrigt igen normalt.

Ingen af de fatale fejl i DB2 var kendt af IBM, og derfor forelå der ikke rettelser til disse. Rettelser til fejlene er nu tilgængelige for alle brugere af DB2 databasesoftware, herunder Danske Bank og DMdata. Danske Bank og DMdata har nu lagt disse rettelser på bankens systemer.

Danske Bank har undervejs i forløbet ikke på noget tidspunkt haft risiko for datatab, idet alle data kunne genskabes fra driftscentret i Brabrand eller fra DB2 databasesoftwarens logs, der opbevares på alternative disksystemer. Det store problem bestod i, at gendannelsesprocessen blev ved med at trække ud på grund af fremkomsten af softwarefejlene. Hvis der var opstået flere fejl i DB2 ud over de fire nævnte, havde konsekvensen alene været, at gendannelsen af data havde taget yderligere tid.

Fremadrettede tiltag
Danske Bank og DMdata har gennemgået hele hændelsesforløbet og drøfter i den forbindelse med IBM, hvad der skal iværksættes for at forbedre IBMs DB2-system og sikre et højere og bedre beredskab, hvis sådanne kritiske hændelser skulle indtræffe.

Det er ikke usædvanligt, at fejl i software hele tiden identificeres, og rettelser modtages fra leverandøren. DB2 er således under konstant udvikling, og nye versioner modtages løbende. Denne problemstilling er ikke specifik for Danske Bank, men for alle brugere af DB2 databasesoftware, som er det mest udbredte databasesoftware til mainframe systemer.

Danske Bank-koncernen har siden 1991 anvendt to-center drift, der i et vist omfang benytter dublering af data og afvikling af visse systemer i begge centre. Det var blandt andet på grund af denne dublering, at banken kunne genskabe data.

Som et supplement til det nuværende to-center driftssystem begyndte Danske Bank-koncernen i efteråret 2002 at implementere det såkaldte GDPS katastrofe sikkerhedssystem (Geographically Dispersed Parallel Sysplex) med spejlede diske, som skal supplere det eksisterende to-center drift setup.

Med GDPS-systemet vil koncernens centrale systemer få et mere sikkert katastrofeberedskab ved hardwarefejl, fordi den daglige drift afvikles på to ens maskinkomplekser, hvor data spejles. I tilfælde af hardwarefejl standses spejlingen umiddelbart, og det andet kompleks overtager driften. Dermed vil genetableringstiden blive kortere, og effekten af nedbrud vil kunne reduceres. Det er fremgået af dagspressen, at installation af spejlede diske ville have betydet, at Danske Bank havde undgået den aktuelle situation. Spejlede diske, med eller uden GDPS, ville i den nuværende version imidlertid ikke have forhindret Danske Banks seneste nedbrud. Det vurderes, at næste version af GDPS, der forventes frigivet til maj 2003, ville have forhindret driftskonsekvenserne af hardwarefejlen.

For at sikre mod komplekse softwarefejl vil Danske Bank endvidere vurdere en investering i yderligere udbygning af to-center drift for flere af koncernens vitale systemer.

Omverdenen har i forbindelse med Danske Banks driftsproblemer efterlyst en mere åben kommunikation, hvilket banken naturligvis vil søge at efterkomme. Det er nu indarbejdet i koncernens planer for katastrofeberedskab, herunder væsentlige driftsnedbrud.

Som det fremgår af hændelsesforløbet, udviklede situationen sig imidlertid uforudsigeligt med nye softwarefejl i dagene fra tirsdag morgen den 11. marts til fredag den 14. marts. I forløbet havde Danske Bank flere gange en forventning om, at driftssituationen var normaliseret, hvilket beklageligvis viste sig ikke at være tilfældet på grund af nye uventede softwarefejl.

Kontaktperson:
Vicedirektør Peter Schleidt, telefon 43 27 85 00.
​