Nedetid for Oracle-database FS04PRD
Dato: 2021-10-20
Skrevet av: jonvenb
Oracle-database FS04PRD var nede fra kl 11:13 (i praksis trolig fra kl 10:56) til kl 12:00 onsdag 20.10.2021 pga problemer i forbindelse med utvidelse av loggfiler. Institusjoner som bruker FS04PRD er DMMH, KRUS, MIL, NHH, PHS, SOOP og HINN.
Beskrivelse av avviket og feilrettingsprosess
Bakgrunnen for det som skjedde var at iholm skulle øke størrelsen på alle redo log-filer til 6 GB. Størrelsene var fra før dels 4 GB, dels 5 GB. Det var 4 logfile groups (nr 1, 2, 3 og 4) med 2 identiske filer i hver. Det var hyppige logg-svitsjer, ca hvert 1,5 minutt.
- 10:46:33: legger til midlertidig gruppe #8
- 10:50:23: legger til midlertidig gruppe #9
- 10:53:27: Gruppe #9 blir Current
- 10:54:29: gjør "drop logfile group 1" (som går bra)
- 10:55:01: Gruppe #4 blir Current
- 10:55:41: gjør "drop logfile group 2" (som går bra), "drop logfile group 3" (som går bra) og "drop logfile group 4" som feiler med feilmelding ORA-1623, "log is current log - cannot drop".
- 10:56:10: Gruppe #8 blir Current
- 10:56:10: Oracle skriver i alert-logg at det ikke går å åpne de 2 filene i gruppe 4, fordi de ikke finnes
- 11:11: varsler i DBD-chat at FS04PRD må tas ned pga feil. Det er veldig mange feilmeldinger i alert-logg om de manglende filene. Eksisterende vinduer henger og det går ikke å åpne nye sesjoner mot maskinen
- 11:13: må gjøre shutdown på serveren for å få kontroll på databasen igjen
- 11:31: ber om bistand i DBD-chat. Databasen er i status nomount (nede).
- 11:37: møtes på Zoom
- 11:42: gjør "CLEAR UNARCHIVED LOGFILE GROUP 4" og deretter "drop logfile group 4" som går bra.
- 11:43: sender e-post til UNIT om at FS04PRD er nede og at vi arbeider med saken.
- 11:51: ringer til UNIT for å varsle
- 11:59: starter database og listener
- 12:00: Databasen er oppe
- 12:03: sender e-post til UNIT om at FS04PRD er oppe igjen
Konsekvenser
Vi tror at FS04PRD var utilgjengelig fra kl 10:56 og i hvert fall fra kl 11:13. Den var tilgjengelig igjen kl 12:00.
Institusjoner som bruker FS04PRD er DMMH, KRUS, MIL, NHH, PHS, SOOP og HINN.
Det kom ingen feilmeldinger inn til DBD i RT.
Feilkategori: A/B, vi heller mot B siden feilen ikke gjaldt alle institusjoner og det skjedde rundt lunsj og det ikke kom noen klager.
Hva skulle vi gjort for at situasjonen ikke oppsto?
Problemet var at de 2 filene i logfile group #4 forsvant. Vi har ikke klart å bringe på det rene om de ble slettet ved en feiltakelse av oss rett etter drop-kommandoen som feilet, eller om Oracle gjorde det.
Vi kunne ha unngått å droppe en logfile group som var Current. Det var litt vanskelig med FS04PRD pga svært hyppige loggskifter samt at svitsje-rekkefølgen ser ut til å ha vært (logfile group nr) 1-4-2-8-3-9-1 osv.
Hva kunne USIT gjort bedre?
Vi bør utvise forsiktighet med OS-kommandoer mot filer som er styrt av databaser.
Som følge av rutineendringer etter erfaring fra tidligere hendelser fungerte varsling internt og ut til kunde (UNIT) godt. Intern varsling og bruk av Zoom til operasjonssenterplattform gjorde koordinering av arbeidet og samling av faglig kompetanse til feilretting rask og effektiv.
Tiltak
Vi bør utvise forsiktighet med OS-kommandoer mot filer som er styrt av databaser. Vi bør gjennomgå hendelsen med alle som jobber med Oracle i DBD.