Een databasewissel roept vragen op

Op dat moment ontstaat vaak twijfel. De database bevat tenslotte het hart van je systeem. Alle informatie die heb je dagelijks nodig hebt zit erin. In het geval van IBM Maximo: werkorders, asset informatie, storingshistorie en rapportages. De stap naar een andere database voelt al snel als een risico.

Niet zo vreemd dus dat er meteen zorgen op tafel komen zodra een databasemigratie wordt besproken. Wat zijn de grootste angsten en hoe ondervang je ze?

1. Is mijn database niet te groot voor een migratie?

Voor databasemigraties zijn standaard IBM-tools beschikbaar. Die zetten een database eerst om naar een tekstbestand waarin het databaseschema en de data worden vastgelegd. Van daaruit wordt de database weer op het nieuwe platform opgebouwd. Bij kleinere databases werkt dat meestal rechtstreeks.

Bij grote databases werkt een opgesplitste aanpak beter. Het databaseschema, het geraamte van de database, en een deel van de kleinere tabellen gaan via de IBM-tool over. Daarmee staat de basis van de database al op het nieuwe platform.

Grotere tabellen krijgen vervolgens een aparte behandeling, met speciaal ontwikkelde tools die tabellen met veel records in batches overzetten. Tabellen met grote BLOB- en CLOB-velden krijgen extra aandacht. Door deze tabellen apart en gecontroleerd te verwerken, blijft zelfs een grote database goed migreerbaar.

2. Krijg ik al mijn data wel een-op-een over?

Een bekend voorbeeld is case sensitivity. In veel Oracle-omgevingen zijn databases hoofdlettergevoelig, terwijl SQL Server dat vaak niet is. Waarden als ABC123 en abc123 kunnen daardoor in de ene database naast elkaar bestaan, terwijl ze in een andere database als duplicaat worden gezien. Dat soort situaties moeten vóór de migratie worden opgespoord.

Ook bij datatypes en velddefinities kunnen verschillen optreden. Denk aan tekstvelden met een andere maximale lengte, numerieke velden met een andere precisie of datumtypes die net anders worden opgeslagen. Tijdens de migratie converteert de tool de data naar het juiste format.

Na de migratie volgt een controle van de data zelf. Recordaantallen worden vergeleken en bij kritische tabellen wordt ook de inhoud van velden gecontroleerd. Zo blijkt of de data in de nieuwe database overeenkomen met de oorspronkelijke situatie.

3. Wordt de database-syntax wel goed vertaald?

Bij een overstap naar een ander databaseplatform moet die platform-specifieke syntax worden vertaald. SQL lijkt bijvoorbeeld overal hetzelfde, maar functies en constructies verschillen per databasetype (Oracle, MS SQL, DB2). Een functie of datatype dat in Oracle voorkomt, heeft in SQL Server of DB2 vaak net een ander equivalent.

Daarom start een migratie met een inventarisatie van de databaseobjecten en query-opbouw in velden in de bestaande database. Standaardconstructies kunnen meestal automatisch worden omgezet. Bij database-specifieke functies of maatwerkobjecten is vaak een aanpassing nodig om dezelfde logica op het nieuwe platform te behouden.

Zo blijft de werking van de database intact, ook als die straks op een ander platform draait.

4. Blijft de performance van mijn database wel hetzelfde?

Om die reden begint een databasemigratie met een analyse van de omgeving waarin de database straks draait. Welke machines zijn beschikbaar? Hoeveel processorkracht en geheugen zijn nodig? En hoeveel capaciteit heb je nodig als de database de komende jaren verder groeit? Op basis daarvan ontstaat een beeld van de infrastructuur die nodig is voor het nieuwe databaseplatform.

Daarna volgt een analyse van het gebruik van de database zelf. Queries bepalen voor een groot deel hoe snel een systeem reageert. Daarbij spelen bijvoorbeeld de gebruikte where clauses een belangrijke rol. Hoe efficiënter een query is, hoe sneller het resultaat beschikbaar is zonder het systeem zwaar te belasten.

Door zowel de infrastructuur als het querygebruik mee te nemen, blijft de database na de migratie niet alleen functioneel hetzelfde werken, maar sluit ook de performance aan op het daadwerkelijke gebruik van het systeem.

5. Ligt mijn systeem er straks niet te lang uit?

Daarom vindt de migratie eerst volledig plaats in een testomgeving. Alle stappen komen daar al een keer voorbij: het overzetten van de database, het opstarten van de nieuwe omgeving en de controles op de data. Zo wordt duidelijk hoeveel tijd elke stap kost en waar mogelijke knelpunten zitten. Op basis daarvan ontstaat een gedetailleerd migratieplan. Omdat de volledige migratie al is uitgevoerd, is vooraf duidelijk waar de risico’s zitten en hoe lang de overgang duurt.

De daadwerkelijke migratie vindt vervolgens plaats op een moment waarop je organisatie er zo min mogelijk last van heeft, bijvoorbeeld in een onderhoudsvenster of buiten piekuren. Omdat de stappen bekend zijn en de timing vooraf is getest, verloopt de overgang gecontroleerd en voorspelbaar.

Databasemigratie vraagt om ervaring

Bij Gemba hebben we ruime ervaring met het overzetten van databases onder bedrijfssystemen zoals IBM Maximo en andere platforms. Op basis van die ervaring hebben we een aanpak en toolset ontwikkeld waarmee zelfs grote en complexe databases gecontroleerd en voorspelbaar kunnen worden gemigreerd. Zo ondervangen we stap voor stap de belangrijkste zorgen bij een databasemigratie.

Eens sparren over de migratie van jouw database? Neem contact op met Wouter Schouten via +31 (0)6 52 68 37 43 of w.schouten@gemba.nl.