Database-patch van Oracle lost beheerprobleem niet op

Die teller is door de bouwers van de database fors gedimensioneerd. Er zijn 48 bits voor gereserveerd, waardoor er ruim 281 biljoen nummers beschikbaar zijn. Daarnaast hebben de bouwers een check ingevoerd om te controleren of de database niet op hol is geslagen. Voor iedere seconde sinds de aanvang van het jaar 1988 mag het SCN met meer dan 16.384 nummers opgehoogd zijn. De limiet staat dus op dit moment in de buurt van de 12 biljoen.

Grote configuraties kwetsbaar

Bij normale operatie is dat een grens waar beheerders zich het hoofd niet over hoeven te pijnigen. Maar in grote configuraties van onderling verknoopte Oracle databases ligt dat anders. Om de dataconsistentie te bewaren, moeten de databases in zo'n geval het SCN synchroniseren. En omdat dat nummer niet verlaagd kan worden, vindt synchronisatie plaats naar het hoogste getal.

Die noodzakelijkheid kon tot problemen leiden door een bug in de faciliteit om een live backup te maken van een Oracle-database, meldt de redactie van InfoWorld op basis van eigen onderzoek. Die mogelijkheid bleek namelijk een snelle stijging van het SCN-nummer uit te lokken, met miljoenen tot zelfs wel honderden miljoenen tegelijk. Dat is op zich ook nog geen probleem, maar als bij tientallen onderling verbonden Oracle-databases van deze functie gebruik wordt gemaakt, die allemaal moeten synchroniseren naar het hoogst aangetroffen SCN, kan de grens opeens snel in zicht komen.

Kwaadwillende kan probleem uitlokken

Nog ernstiger was de constatering dat het SCN relatief simpel te verhogen zou zijn door een kwaadwillende die zich toegang weet te verschaffen tot een database in de keten die bijvoorbeeld alleen voor rapportagedoeleinden wordt gebruikt. Ondanks het feit dat dat een database met weinig privileges zal zijn, volstaan die om snelle verhoging van het SCN uit te lokken. Ook een aanval op een applicatie die kwetsbaar is voor SQL-injectie zou dat effect kunnen bewerkstelligen, aldus InfoWorld.

Het bereiken van de limiet qua ophoging van het aantal SCN's heeft bijzonder vervelende consequenties. Simpelste oplossing is het stilleggen van alle onderling verknoopte databases. Dan loopt de limiet per seconde 16. 384 cijfers bij je vandaan. Dat is een weinig aanlokkelijke keuze. Maar dat geldt nog minder voor het alternatief: het dumpen van de gegevens uit de bestaande databases en het importeren van die gegevens in volledig nieuwe databases.

Patch roept vraagtekens op

Oracle heeft in zijn jongste patchronde een patch uitgebracht om het probleem te tackelen. Die schijnt verbindingen met databases met een ongewoon hoog SCN te weigeren. Daarnaast biedt Oracle klanten de mogelijkheid de limiet in de check op een op hol geslagen database te verdubbelen of zelfs verder te verhogen naar een zelf gekozen waarde.

InfoWorld heeft die patches nog niet kunnen testen, maar zet op voorhand wel wat vraagtekens. De belangrijkste is dat de patches niet beschikbaar zijn voor oudere databases. Men moet daarvoor minimaal Oracle 11g 11.1.0.7 of Oracle 109 10.1.0.5 hebben. In configuraties waarin nog oudere versies draaien is de enige mogelijkheid om het probleem uit te bannen waarschijnlijk het upgraden van die oude versies.

Het is ook de vraag hoe een gedistribueerde database functioneert als je niet alle onderdelen gelijktijdig patcht. Zeker als men ook besluit om de limiet van het aantal uitgegeven nummers per seconde te verdubbelen, zouden er communicatieproblemen kunnen ontstaan met Oracle-databases waarop dat nog niet is gebeurd, aldus InfoWorld.