IBM: DB2-problem er kun set hos CSC

Ifølge IBM er der ikke set andre eksempler på problemer med DB2-databaser i forbindelse med den opdatering, som lukkede Skats it-system.

Den dårlige nyhed er, at fejlen, der fik CSC til at lukke Skats it-system ned fredag, endnu ikke er afklaret. Den gode nyhed er, at fejlen ser ud til at være begrænset til systemerne hos CSC.

IBM oplyser til Version2.dk, at selskabet ikke har hørt om problemer med opdateringen hos andre kunder.

»Vi har været rundt i systemet, og der er tale om et problem, som er relateret til CSC Danmark og deres kunder. Vi har ikke umiddelbart kunne identificere samme problem hos andre kunder i eller uden for Danmark,« siger pressechef Carsten Grønning til Version2.

Hos CSC's amerikanske afdeling har man heller ikke hørt om problemer med DB2, som derfor ser ud til at være begrænset til de danske systemer.

»Det er første gang, jeg hører om problemet,« siger kommunikationschef Mike Dickerson fra CSC i USA til Version2.

De præcise omstændigheder bag nedbruddet var fredag endnu ikke klarlagt, men problemerne opstod angiveligt, efter CSC installerede en rutinemæssig opdatering til IBM's DB2 database.

Det fik it-systemer, som CSC står for driften af, tilhørende politiet og Skat til at køre ustabilt. CSC valgte derfor at foretage en kontrolleret lukning af Skats system.

CSC og IBM arbejder hen over weekenden på at få løst problemet og blandt andet få klarlagt, om der er gået data tabt på grund af fejlen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Krogh

En RDBMS er et komplekst stykke software, jeg læste engang
en påstand om at det nok konkurrerede med OS'et om at være
de 2 mest komplexe stykker software vi bruger i dag. Derfor
er det jo også endnu mere vigtigt at have sine emergency
procedurer på plads.

DET UNDRER MIG AT DE IKKE HAR KUNNET STØVE SØNDAGENS BACKUP
FREM OG FÅ DEN TIL AT KØRE I LØBET AF TIRSDAGEN.

Sandsynligheden for problemer med disse meget komplekse
stykker software bliver større hvis man:

  • Benytter et stykke software der er eksklusivt (Ikke
    bliver brugt af mange). (DB2 er i denne kategori, DB2 på
    mainframe er endnu mere(jeg ved ikke om det er en
    mainframe))
  • Benytter features i softwaren der ikke bliver brugt af
    mange af softwares brugere ellers. (Costum-build software
    som SKAT må antages at være i denne kategori)

Disse 2 kombinationer gør at man godt kan havne i en situation, hvor man ufrivilligt bliver eneste eksisterende bruger af en specifik "code-path" i softwaren og dermed også udsat for problemer som kun en selv har.

Hvad kan man gøre for at modstå:
* Benytte softwaren i kombinationer som er brugt andre
steder
* Benytte software der er brugt bredere.

Er det ikke muligt, så må man teste "at det virker", også
teste sine backup-procedurer, så man kan bringe systemet
tilbage i drift ved ukendte problemer.

Jeg ved godt at DB2 er en af "the big 3" databaser, men det er altså i komplexitet de er store og ikke i udbredelse. Jeg er sikker på at den store udbredelse af Open Source databaserne gør det mindre muligt at ramme en unik bug i dem. Den anden fordel ved Open Source databaserne er at der er mange flere øjne på koden end dem hos leverandøren.

Slutteligt.. jeg ville ikke bruge koden til noget, hvis jeg havde løbet i dette problem med en Open Source database.. Jeg ville have spolet backuppen ind (tilbage til sidste kendte gode tilstand). Og derefter kunne man give sig til at undersøge hvad årsagen til problemet var.

Min hovedpointe er stadig. Hvorfor har deres backup procedurer ikke reddet dem, så de var "back in business" allerede tirsdag (eller senest onsdag).

Der mangler forøvrigt også nogle muligheder for at begrænse
omfanget af forstyrrelser af andre systemer ved lukning af
det pågældende system.

Jesper

  • 0
  • 0
Jarnis Bertelsen

At lave et roll-back kræver bl.a.:

a) At man er opmærksom på at fejlen findes
b) At man ved hvornår den er opstået
c) At man er klar til at miste (eller kan genskabe) de data der er tilføjet siden.

Jeg synes ikke det fremgår af artiklen hvornår CSC opdagede/lokaliserede fejlen. Man har tilsyneladende heller ikke på skrivende tidspunkt et klart billede over fejlens omfang og hvor meget data der evt er gået tabt.

Jeg mener derfor ikke, at man som udenforstående kan konkludere, at de bare skulle have vendt tilbage til weekendens backup.

Jarnis

  • 0
  • 0
Chris Kjær

Jeg mener derfor ikke, at man som udenforstående kan konkludere, at de bare skulle have vendt tilbage til weekendens backup.

Enig, det er absolut sidste udvej, som man kun vælger hvis databasens log er defekt (hvilket den kun er, hvis driftsfolkene er dybt inkompetente). I en situation, hvor man skal genskabe data, tager man udgangspunkt i sin seneste fulde backup og supplerer med opdateringer fra loggen. Dette kan let tage et stykke tid, da loggen af en lille uges opdateringer sagtens kan fylde mange hundrede gigabytes (på tape) i et travlt DB2-system, og det er nok det, som IBM og CSC har brugt de sidste par dage på.

  • 0
  • 0
Log ind eller Opret konto for at kommentere