Migrering fra Firebird til MariaDB: Fremgangsmåde, faldgruber og driftssikkerhed i hverdagen

Den, der ønsker at migrere Firebird til MariaDB, har som regel et klart mål: en langsigtet driftbar dataplatform, der passer ind i eksisterende infrastruktur, backup-strategier, overvågning og IT-teamets know-how. I praksis er det dog sjældent blot en ren datakopi. Firebird og MariaDB adskiller sig i SQL-dialekt, transaktionsadfærd, datatyper, tegnsætningsregler (collations) samt i måden, logik implementeres i databasen (triggere, stored procedures, sekvenser/generatorer).

Dette indlæg beskriver en fremgangsmåde, der fungerer i virksomheder: med pålidelig analyse, en kontrolleret migrationssti, efterprøvbar testbarhed og et cutover, der ikke unødigt sætter driften på spil. Fokus er bevidst på drift, administration, datakvalitet og integrationer – mindre på framework-detaljer.

Hvorfor virksomheder afløser Firebird – og hvorfor MariaDB ofte vælges

Firebird er attraktiv for mange etablerede forretningsapplikationer: slankt, hurtigt klar til brug, ofte driftssikkert over lang tid. Samtidig opstår der, afhængigt af organisationen, typiske drivere for en udskiftning:

• Driftsstandardisering: MariaDB (MySQL-kompatibel) drives i mange miljøer allerede som standarddatabase, inklusive automatisering, patch-processer og overvågning.
• Platform- og tool-økosystem: Mange ETL-værktøjer, BI-tilkoblinger og driftværktøjer er særligt godt forberedt til MySQL/MariaDB.
• Skalerings- og højtilgængelighedskoncepter: Replikation, proxy-opsætninger, cluster-muligheder og container-drift er organisatorisk ofte nemmere at integrere.
• Personale og ansvar: Know-how og vagtberedskab kan ofte dækkes nemmere, når databasen passer til RESTen af landskabet.

Vigtigt er: En migration er kun umagen værd, hvis den ikke blot „på en eller anden måde“ fungerer, men bliver driftbar. Det omfatter klare driftsparametre, backup/RESTore-tider, overvågning, efterprøvbar dataintegritet og en planbar rollback.

Firebird vs. MariaDB: Tekniske forskelle, der virkelig tæller i projekter

Før det egentlige migrationsdesign er det værd at se nærmere på de forskelle, der senere afgør tid og risiko:

SQL-dialekt og funktioner

Firebird har egne syntaksvarianter og funktionsnavne. MariaDB er MySQL-kompatibel, men har også særheder. Typiske konflikter er dato-/tidsfunktioner, strengfunktioner, casting-regler og måden, forespørgsler optimeres på. I migrationen er det ikke akademisk: Hver omskrevne forespørgsel kan forårsage regressioner, hvis den ikke testes systematisk.

Transaktioner, isolation og samtidighed

Firebird arbejder med Multiversion Concurrency Control (MVCC): læsere blokerer typisk ikke skrivere på samme måde som i klassiske låsemodeller. MariaDB bruger også MVCC (via InnoDB), men den konkrete adfærd afhænger i høj grad af isolation level, indeksering og forespørgselsform. I praksis betyder det: Efter migrationen kan låseadfærd, forekomst af deadlocks og „Long Running Transactions“ påvirkes anderledes.

Tegnsæt, collation og sortering

En hyppig projektrisiko er kombinationen af tegnsæt (f.eks. UTF-8) og Collation (sorterings- og sammenligningsregler). Firebird-projekter indeholder ofte blandede tilstande: gamle data i legacy-encodings, senere omstillet, samt applikationskode med egne konverteringer. I MariaDB kan Collations konfigureres per database, tabel eller kolonne. Forkerte indstillinger fører til forkerte sammenligninger, “duplikerede” nøgler ved case-insensitiv sortering eller overraskende søgeresultater.

Datatyper og præcision

Firebird og MariaDB adskiller sig på numeriske typer, tids-typer, Boolean, BLOBs samt i håndteringen af default-værdier. Særligt kritisk er præcision for pengebeløb (Decimal) og tidsstempler. En migration skal planlægge type-mapping, så der ikke opstår stille afrundinger eller trunkeringer.

Generatorer/Sequencer, Auto-Increment og Trigger

Firebird bruger “Generatorer” (sekvenser) ofte i kombination med triggers til tildeling af primærnøgler. MariaDB arbejder typisk med AUTO_INCREMENT eller SEQUENCE (afhængig af version/setup). Hvis applikationen hidtil eksplicit har læst generatorværdier eller triggerlogik er baseret på generatorer, skal det reproduceres korrekt eller bevidst ændres – inklusive korrekte startværdier og konfliktfrihed.

Forberedelse: Opgørelse i stedet for mavefornemmelse

En holdbar migration begynder med en opgørelse, der ikke blot tæller tabeller, men kortlægger anvendelsen. Målet er at undgå overraskelser i omstillingsugen.

1) Objekt- og logikinventar

• Tabeller, Views, Indekser, Constraints
• Triggers (især til audit, valideringer, primærnøgle)
• Stored Procedures og UDFs (User Defined Functions)
• Generatorer/Sequencer og deres brugsmønstre
• Roller/privilegier, evt. applikationsbrugere

Vigtigt er spørgsmålet: Hvad er ren dataopbevaring – og hvad er forretningslogik, der ligger i databasen? Jo mere logik der ligger i Firebird, desto mere migrationsarbejde kræver overførsel eller bevidst flytning til services/applikation.

2) Dataprofilering og datakvalitet

Før kopiering bør det være klart, om data er konsistente. Typiske gamle problemer er ugyldige datoer, “0” i stedet for NULL, afklippede strenge, ikke-entydige nøgler eller historisk tolererede overtrædelser af constraints. MariaDB er på nogle punkter strengere, på andre mere tolerant – begge dele kan skabe problemtilfælde. Dataprofilering identificerer felter med outliers, uventede encodings og markante andele af NULL-værdier.

3) Belastnings- og adgangsmønstre

For drift og ydeevne tæller ikke kun datamængde, men adgang: Hvilke tabeller er hotspots? Hvilke rapporter kører om natten? Hvilke transaktioner er lange? Hvilke forespørgsler kører uden indeks? Firebird kan tilgive visse mønstre; MariaDB kan reagere med locking eller høj IO-belastning. Denne analyse bestemmer senere indeksdesign, forespørgselsjusteringer og parametre.

Arkitekturvalg: 1:1-portering eller kontrolleret modernisering?

Ved migration findes to yderpunkter: “1:1 overtage” eller “alt nyt”. I praksis er en kontrolleret mellemvej ofte mindst risikofyldt:

• 1:1 for datastrukturer der, hvor applikationen er stærkt koblet, og ændringer ville være dyre.
• Målrettede oprydninger ved gamle beslutninger, som i MariaDB vil føre til permanent driftsrisiko (f.eks. for lange VarChars, manglende indekser, uklare Collations).
• Afkobling ved grænseflader, hvor eksterne systemer er involveret (BI, DWH, ERP/DMS/CRM). Her er et stabilt contract-lag (Views, API, exporttabeller) ofte fornuftigt.

For voksede Delphi– eller Windows-client-server-applikationer spiller dataadgangslaget en central rolle. Hvis I bruger BDE-afløsning med native binding (et udbredt Delphi-dataadgangsbibliotek), er den tekniske tilslutning til MariaDB grundlæggende godt gennemførlig. Afgørende er mindre driveren end semantikken: transaktioner, parametertyper, fejlkoder, BLOB-håndtering og de forespørgselsvarianter, der indtil nu „har fungeret“.

Typiske faldgruber ved skridtet „migrere fra Firebird til MariaDB“

NULL, standardværdier og tomme strenge

I ældre applikationer er tomme strenge og NULL ofte ikke klart adskilt. I rapporter, filtre eller entydige nøgler kan det efter migrationen føre til andre resultater. Her hjælper en klar beslutning per kolonne: Er NULL tilladt? Standardværdi? Skrives og læses der konsekvent sådan i UI/service?

Boolean- og statusfelter

Firebird bruger ofte Smallint(0/1) eller char(‚T’/’F‘)-mønstre. MariaDB har BOOLEAN som alias (typisk TINYINT(1)). For grænseflader er det vigtigt: Hvordan serialiseres værdierne (f.eks. i REST-services)? Uklar konvertering fører ellers til „true/false“-fejl, som først opdages i processen.

BLOBs: dokumenter, billeder, e-mails

BLOB-felter er sjældent „bare store“. De påvirker backup, restore, replikation og performance. For MariaDB skal det afklares, om BLOBs skal forblive i databasen, eller om et objektbaseret lager (filsystem, S3-kompatibelt) på mellemlangt sigt er mere hensigtsmæssigt. For selve migrationen gælder: Undersøg om BLOBs er binære eller tekstuelle, hvilke kodninger der gælder, og hvordan applikationen fortolker indholdet.

Identiteter og nøglegenerering

Hvis Firebird sætter primærnøgler via trigger + generator, må målmiljøet entydigt fastlægge, hvem der udsteder ID: databasen (AUTO_INCREMENT/SEQUENCE) eller applikationen. Blandingsformer er risikable. Derudover skal startværdier sættes korrekt efter import, ellers truer nøglekollisioner ved den første nye oprettelse efter cutover.

Trigger-logik for audits og validering

Mange systemer har triggers, som vedligeholder ændringstidspunkt, bruger-id eller audit-rækker. MariaDB understøtter triggers, men detaljerne (syntax, timing, adgang til OLD/NEW, fejlhåndtering) adskiller sig. Især audit-triggers er driftmæssigt relevante: Hvis de efter migrationen tavst udebliver, opstår et compliance- og sporbarhedsproblem.

Tegnsætskonflikter og „usynlige“ datafejl

En klassiker: Data ser korrekte ud i applikationen, men er forkert sorteret i målssystemet eller findes ikke ved LIKE-søgninger. Årsagen er kollationsforskelle eller blandede kodninger. Derfor: Test ikke kun „visning“, men også søgelogik, duplikattjek, import/export og integrationer (f.eks. CSV/EDI).

Migrationsstrategi: offline, online eller hybrid?

Valget af strategi bestemmer projektplanen. Typisk er der tre varianter:

Offline-migration (klassisk Cutover)

Applikationen stoppes, data eksporteres/importeres, og der skiftes så over. Fordele: enkelt, entydig datatilstand. Ulemper: nedetid kan afhængigt af datamængde og validering være lang.

Online-migration (parallelkørsel)

Firebird forbliver i produktion, MariaDB fyldes løbende (f.eks. via replikations- eller Change-Data-Capture-mekanismer). Cutover er kort. Til gengæld er kompleksiteten væsentligt højere: konflikter, rækkefølge, transaktioner, fejlbehandling.

Hybrid (indledende + endelig delta-import)

I mange virksomheder praktisk: Et initialt bulk-import gennemføres forud, derefter overføres kun ændringer (deltas), indtil det endelige Cutover finder sted. Tricket er en ren delta-definition: tidsstempler, sekvenser eller ændringsprotokoller skal være pålidelige.

ETL og dataoverførsel: Hvordan I gør importstier robuste

Ved overtagelsen betaler det sig med en klar proces i stedet for „et script og håbe“. Robust betyder her: gentagelig, logget, verificerbar.

Staging-tilgang frem for direkte import

Et afprøvet mønster er en staging-database (eller et schema), hvor data først importeres rå. Der kan I:

• normalisere tegnkodninger
• kontrollere og konvertere datatyper
• kontrollere referentiel integritet
• gøre duplikatkonflikter synlige

Først derefter føres dataene over i målschemat. Det reducerer risiko, fordi fejl bliver synlige tidligt, og importen forbliver gentagelig.

Validering: Kontroller, der reelt hjælper i drift

Opsæt valideringer således, at de senere tjener som accept- og driftssikkerhed. Typiske kontrolkategorier:

• Rækketællinger pr. tabel (ikke som eneste bevis, men som basissignal)
• Sum-/hash-kontroller over kritiske kolonner (f.eks. beløb, status, tidsstempler)
• Referencer (forældreløse fremmednøgler, også hvis historisk uden constraint)
• Stikprøver fra fagligt kritiske processer (ordrer, bilag, historik)

Særligt vigtigt for beslutningstagere: Validering er ikke „nice to have“, men det greb, der minimerer risikoen for en snigende datafejl.

Performance og drift: Hvad afgør det efter importen

Efter den vellykkede dataovertagelse begynder fasen, der præger hverdagen: svartider, stabilitet, vedligeholdelsesvinduer og transparens i driften.

Indeksdesign og forespørgselsprofiler

Indekser kan ikke overføres 1:1, fordi optimeringsmotoren arbejder anderledes. En fornuftig tilgang:

• start med et solidt dækket basisset (primær-/fremmednøgler, hyppige filterkolonner)
• belastningstest med realistiske arbejdsgange (ikke kun syntetiske SELECTs)
• målrettede indeks-tilføjelser baseret på slow-query-logs og overvågning

Vigtigt: For mange indekser forringer skriveydelsen og øger hukommelse/IO. Målet er et operationelt kompromis, ikke et „indeks for hver forespørgsel“.

Transaktionsstørrelse og batchbehandling

Mange legacy-processer arbejder med store transaktioner (f.eks. natlige bogføringskørsler). I MariaDB kan det føre til undo/redo-belastning, locking eller lange recovery-tider. Her hjælper klare batch-grænser, idempotent behandling (gentagelig uden dobbeltposteringer) og korrekt placerede commit-punkter.

Backup/RESTore, RPO/RTO og test af gendannelse

For IT-ledelsen handler det i sidste ende om: Hvor hurtigt kan jeg gendanne, og hvor stort er datatabet i værste fald? Det er RTO (Recovery Time Objective) og RPO (Recovery Point Objective). Planlæg:

• Regelmæssige backups (logiske/fysiske afhængig af koncept)
• Opbevaring og kryptering
• Gendannelsestests i et separat miljø

En migration betragtes først som driftsstabil, når gendannelsesprocesser ikke blot er dokumenteret, men også er afprøvet i praksis.

Overvågning, alarmer og kapacitetsplanlægning

MariaDB er let at overvåge, men kun hvis du vælger de rigtige signaler: antal forbindelser, replikationsstatus (hvis anvendt), buffer-pool, disk I/O, lock waits, slow queries, tablespace-vækst. Sæt alarmgrænser, så de ikke overbelaster beredskabet med „støj“, men opdager reelle problemer tidligt.

Sikkerhed og rettigheder: Fra Firebird-tankegang til MariaDB-drift

Ved databasemigrationer bliver sikkerhed ofte behandlet sent. Koncepterne ændrer sig: brugerstyring, roller, host-baserede rettigheder, TLS-forbindelser, adgangskodepolitikker.

Praktiske punkter ved overgangen:

• Adskil servicekonti: applikation, reporting, admin, vedligehold – separate brugere, minimale rettigheder.
• Netværkssegmentering: Åbn ikke MariaDB „for alle“; adgang via definerede net og porte.
• Kryptering under overførsel: TLS mellem applikation og database, især ved distribuerede lokationer.
• Logning: Afhængig af compliance-krav skal adgang og admin-aktioner være eftersporelige.

Især når integrationer (fx portaler eller REST-Services) kobles til databasen, bør databasen ikke blive et „fælles bus“, men tilgås via definerede grænseflader. Det reducerer laterale bevægelser i en sikkerhedshændelse.

Cutover-planlægning: Sådan bliver et projekt til en kontrolleret overgang

Cutover’en er ikke tidspunktet, hvor der „endelig skiftes“, men øjeblikket hvor god forberedelse bliver synlig. En praksisegnet Cutover-plan indeholder:

• Freeze-tidspunkt (fra hvornår der ikke længere sker dataændringer i Firebird)
• Endelig Delta-Import inklusive logging og tidstagning
• Verifikation med klare kriterier (ikke „ser godt ud“)
• Omskiftning af applikationer (Connection Strings, DNS/Proxy, Secrets)
• Smoke Tests af de vigtigste forretningsprocesser
• Rollback-beslutningsvindue (indtil hvornår er retur mulig og hvordan)

Et ordentligt rollback betyder ikke nødvendigvis „kopiere tilbage“. Ofte er den mest praktiske rollback at skifte tilbage til Firebird og midlertidigt stoppe MariaDB, såfremt der i Cutover-vinduet ikke er udløst irreversible efterprocesser. Det skal være koordineret organisatorisk (fx bilagsnumre, Schnittstellenexports).

Integration og applikationer: Hvad ændrer sig omkring databasen

Databasen er sjældent isoleret. Typiske afhængigheder er:

• Reporting (direkte SQL-forespørgsler, Views, ekstrakter)
• Grænseflader til ERP/DMS/CRM (fil- eller API-baseret)
• Batch-Jobs, Windows-Services eller Linux-Services, der behandler data
• Portaler og eksterne adgangspunkter (fx kundeportal)

Især for voksede systemer er det værd at benytte lejligheden til at afkoble dataadgang: centrale Views/Exports, klare REST-endepunkter eller servicelag. Det er ikke et mål i sig selv, men forbedrer vedligeholdelse og reducerer direkte SQL-afhængigheder, som ved næste migration igen bliver dyre.

Hvis din eksisterende applikation er implementeret i Delphi, er det også et godt tidspunkt til at konsolidere dataadgangen (f.eks. konfigurere BDE-Ablosung mit nativer Anbindung korrekt, sikre konsistente transaktionsrammer, ensartet fejlbehandling). Det bidrager direkte til driftssikkerhed og fejlsøgning.

Teststrategi: Accept uden illusioner

En databasemigration fejler sjældent fordi „SELECT ikke virker“, men fordi kanttilfælde i processen opfører sig anderledes. En robust teststrategi kombinerer:

• Tekniske tests: forbindelsesopbygning, transaktioner, låseadfærd, ydeevne under belastning.
• Faglige end-to-end-tests: typiske proceskæder fra registrering til evaluering.
• Regressionstests for rapporter: sammenligning af summer, grupper og filterlogik.
• Driftstests: Backup/RESTore, Monitoring/Alarme, genstartadfærd efter vedligeholdelse.

Vigtigt er definitionen af acceptkriterierne: Hvilke nøgletal skal være identiske? Hvilke afvigelser er forklarlige (f.eks. sorteringsrækkefølge ved samme Collation)? Hvem træffer beslutning ved tvivl? Uden denne Governance opstår unødvendige sløjfer kort før go-live.

Konklusion: Tænk migration som et driftsprojekt – ikke som et rent databastema

At migrere fra Firebird til MariaDB er fuldt gennemførligt, hvis det planlægges som et drift- og integrationsprojekt. De kritiske punkter er sjældent selve eksporten, men datatyper, Collations, triggerlogik, nøglegenerering, transaktionsadfærd og den sikre Cutover-Choreografie. Den, der tager inventar, validering og gendannelsestests alvorligt, reducerer projektrisici markant og skaber et datagrundlag, der er vedligeholdelsesvenligt på lang sigt.

Hvis I ønsker at forberede migrationen struktureret – fra analyse over testkoncept til Cutover-Plan og driftsoverdragelse – kan I kontakte os målrettet til det:

I det faglige miljø spiller også Firebird Migration og Mariadb Migration en vigtig rolle, når integrationer, dataflows og videreudvikling skal fungere sømløst sammen.

Drøft projekt eller moderniseringsforløb med Net-Base.