Unieke Oracle bug gevonden

Tijdens het testen blijkt opeens dat er essentiële jobs crashten in C-ARM. Na wat uitzoekwerk bleek dat de EDSN Oracle configuratie de enige in de wereld was waar dit probleem optrad. Werk aan de winkel. Bart Cremers en Folkert Alberts van onze partner CGI vertellen hoe het ging.


Wat was de aanleiding?

Binnen C-ARM is er een performance testomgeving aanwezig met een 100% gepseudonimiseerde productie-afslag.  Hier wordt elke twee weken een driedaagse performance-volume-regressietest uitgevoerd, waarbij gedurende deze drie dagen de productie gesimuleerd wordt qua aantallen berichten en uurlijkse spreiding over de hele dag.

De doelen van deze test wisselen al naar gelang het belang van de business en operatie, maar meestal wordt een aankomende productie-release getest op stabiliteit en performance.

Ook nieuwe functionele changes vanuit de DevOps teams (zoals voor Allocatie2.0), opgeloste defects of bijvoorbeeld schalingstesten (zoals de wellicht bekende iSMA opschalingstest naar 850k aansluitingen) worden hier getest tegen volume en performance.  

Vanuit de beheerorganisatie worden aankomende platformwijzigingen (bv windows-upgrade, database-patching of hardware vervanging) ook altijd eerst aan deze volume-regressie test onderworpen.

Tijdens de laatste stap van het traject om de database van Oracle 12 naar 19 te brengen, eind februari, is hierbij de zogenaamde compatibiliteits-mode uitgezet, waardoor alle voordelen van de reeds draaidende Oracle 19c versie benut zouden kunnen gaan worden.

Op 1 maart startte de driedaagse test waarbij bij het verhogen van het volume vreemd gedrag optrad: essentiële jobs crashten, veroorzaakt door niet eerder geziene interne Oracle ‘ORA-00600’ foutmeldingen. Deze fout was nergens anders in de Ontwikkeld, Test en Acceptatie (OTA) omgevingen opgetreden en dus daar dus ook niet ontdekt.


Wat hebben jullie toen gedaan?
Nog tijdens deze lopende run is conform proces de technisch-beheer organisatie van CGI gemobiliseerd. En vrijwel direct ook is CGI GTO (Global Technology Operations) bijgeschakeld, waar het technisch databasebeheer is belegd. Vanuit incidentanalyse is Oracle bijgeschakeld.

Al snel bleek dat reguliere beschikbare oplossingen niet afdoende waren. Potentiële oplossingen konden daarbij direct getest worden door het opnieuw opvoeren van ‘load’.  Hiermee kwamen we in de vreemde, maar ook interessante positie, waarbij onze Oracle configuratie bij EDSN de enige in de hele wereld bleek waar dit probleem optrad. In een dagelijkse escalatie-call met CGI-beheer, Oracle en EDSN is samen gezocht naar een oplossing.


Wat deed de leverancier Oracle met jullie vraag?

Oracle heeft, vanuit onze prio-1 en partnerschap, op 24-uurs inzet (dus wereldwijd) binnen hun development teams gezocht naar een oplossing en uiteindelijk een dedicated fix voorbereid, die succesvol op onze performancetestomgeving getest kon worden. Na goedkeuring aan onze kant is deze fix opgenomen binnen de reguliere DB-patches welke overigens in juli op EDSN Productie wordt gereleased.


Hoe lang duurde dit hele proces?
Op 23 mei is het sein ‘brand meester’ gegeven na succesvolle drie-daagse volumetesten inclusief de fix. Het incident-proces heeft daarmee een dikke anderhalve maand geduurd. Hierbij waren er overigens maatregelen getroffen om de performance testen in de tussentijd ondanks deze hindernis toch doorgang te kunnen laten vinden.

Wat heeft het opgeleverd voor EDSN en de netbeheerders?
Uiteraard heeft dit issue het, door EDSN onderkende nut weer bewezen van een dergelijke productie-like omgeving met productie-like performance-volume-regressietesten.

Waren jullie zelf blij met het vinden van dit probleem?
Elke fout is er natuurlijk één teveel, maar het is fijn en goed dat dit issue voor productie-livegang getackeld kon worden. En ook mooi dat het incident-oplossingsproces werkt zoals bedacht, met, vanaf dag 1 goede samenwerking op dagbasis met DevOps teams, EnablerTestteam, CGI-beheer, GTO en Oracle. En op persoonlijke titel: Het was een interessante exercitie, want als tester is het ook maar saai als alle testen alleen maar succesvol resultaat geven😉

Vragen hierover? Mail naar folkert.alberts@edsn.nl of jesse.lantinga@edsn.nl.

 

_____________________________________________

Bekijk ook andere berichten uit de nieuwsbrief: