Migrazione Oracle con fermi ridotti al minimo: perché si parte dal cutover
Un database Oracle critico si sposta con fermi brevi se il lavoro pesante si fa prima, a sistema acceso. Tecniche, licenze, prove e piano di rientro, partendo dal momento del passaggio.
Un database Oracle critico si può migrare con un fermo di pochi minuti se il lavoro pesante si fa prima, mentre il sistema lavora: si prepara il nuovo database, lo si tiene allineato con una replica continua e si fissa in anticipo il cutover, cioè il momento in cui le applicazioni smettono di scrivere sul vecchio sistema e passano al nuovo. Il cutover va progettato per primo, perché da quanto può durare dipendono la tecnica, gli strumenti, le licenze e il calendario. Un fermo del tutto nullo, invece, non si può promettere: si riduce e si pianifica.
Scenario tipico. Un’azienda che vende online in più Paesi deve spostare il database degli ordini su una nuova piattaforma. Il primo piano prevede sei ore di fermo, di sabato notte, con un’esportazione completa e un nuovo caricamento. Ma i clienti ordinano a tutte le ore, da fusi orari diversi, e nessuno sa dire se sei ore basteranno. Il problema non è lavorare più in fretta. È cambiare l’ordine delle operazioni.
Che cos’è il cutover e perché si progetta per primo?
Il cutover è il passaggio finale di una migrazione: si fermano le scritture sul sistema di partenza, si verifica che la destinazione abbia tutti i dati, si collegano le applicazioni al nuovo database e si riapre il servizio. È la parte che si vede, ed è l’unica in cui chi usa il gestionale o il sito si accorge di qualcosa.
Per questo la prima domanda non è «quale strumento usiamo?», ma «quanto fermo può sopportare l’azienda, e in quale momento?». La risposta la danno le persone che usano il sistema, non solo l’IT: vendite, logistica, amministrazione. Se il fermo accettabile è di qualche ora di notte, una copia tradizionale può bastare. Se è di pochi minuti, serve una replica continua, con tutto ciò che comporta.
Due parametri aiutano a mettere la decisione per iscritto:
- RTO (Recovery Time Objective): il tempo massimo per cui il servizio può restare fermo;
- RPO (Recovery Point Objective): quanti dati, misurati in tempo, si possono perdere se qualcosa va storto durante il passaggio.
Quali tecniche riducono il fermo, e con quali licenze?
Le tecniche principali sono cinque. Differiscono per durata del fermo, per vincoli tecnici e per costo delle licenze.
| Tecnica | Come funziona | Fermo | Licenze e vincoli |
|---|---|---|---|
| Esportazione e importazione (Data Pump) | si estraggono i dati e si caricano nel nuovo database | per tutta la durata della copia | inclusa nel database |
| Copia e ripristino (RMAN) | si ripristina una copia sulla destinazione e la si porta avanti con i log | per l’ultimo allineamento | incluso; di norma stessa piattaforma |
| Database di riserva (Data Guard) | la destinazione riceve di continuo le modifiche; al momento giusto i ruoli si invertono | breve, il tempo del cambio di ruolo | incluso nella Enterprise Edition, non disponibile nella Standard Edition 2 |
| Replica logica (GoldenGate) | le modifiche vengono riapplicate sulla destinazione, anche tra versioni e piattaforme diverse | breve | prodotto con licenza propria; per alcune migrazioni verso il cloud di Oracle valgono condizioni specifiche |
| ZDM, lo strumento di migrazione di Oracle | automatizza i flussi fisici e logici qui sopra verso Oracle Cloud, Exadata e altre destinazioni indicate da Oracle | nullo o minimo, secondo la documentazione | usa gli strumenti e le licenze indicati per ciascun flusso |
La scelta dipende da edizione, versione di partenza e di arrivo, piattaforma e volumi. Un esempio: con la Standard Edition 2 Data Guard non è disponibile, e le strade per ridurre il fermo cambiano. Un altro: la replica logica permette di cambiare versione e sistema operativo nello stesso passaggio, ma richiede più preparazione e una licenza da mettere a budget.
Se la migrazione coincide con un aggiornamento di versione, vale anche quanto scritto su versioni e scadenze di Oracle: si parte dalla certificazione del gestionale.
Che cosa va verificato prima di partire?
Prima di toccare una configurazione serve una fotografia tecnica, fatta con metodo. Le voci che più spesso fanno slittare una migrazione sono queste:
- dipendenze nascoste: elaborazioni pianificate, collegamenti tra database, applicazioni che scrivono direttamente nelle tabelle, integrazioni con fornitori e clienti;
- carichi di lavoro: picchi di scrittura, elaborazioni notturne, chiusure di fine mese che non devono sovrapporsi alla sincronizzazione;
- compatibilità: la versione di arrivo deve essere certificata per il gestionale; alcune funzioni cambiano tra una versione e l’altra, o tra un server in azienda e un servizio cloud;
- licenze: in cloud cambia il modo in cui si contano; opzioni e strumenti usati durante la migrazione devono essere coperti;
- prestazioni: le interrogazioni più importanti vanno misurate prima e dopo, sulla destinazione, con dati reali;
- rete e sicurezza: banda disponibile per la replica, cifratura dei dati in transito, utenze dedicate alla migrazione e chiuse alla fine.
Saltare questa fase fa risparmiare qualche giorno all’inizio e spesso ne fa perdere di più alla fine, quando i problemi emergono a passaggio già fatto.
Come si prova il passaggio prima del giorno stabilito?
Un cutover riesce meglio se è già stato provato. La prova generale si fa su una copia, con il cronometro in mano, e produce tre documenti.
- La scaletta del passaggio: ogni operazione, chi la esegue, in che ordine, quanto dura.
- Le verifiche di validazione: conteggi delle righe sulle tabelle principali, controlli applicativi fatti dagli utenti chiave, tempi delle interrogazioni critiche.
- I criteri per decidere: che cosa deve risultare vero per proseguire, e che cosa fa scattare il ritorno indietro. Si scrivono prima, non durante.
Il giorno stabilito, la scaletta si segue come è stata provata. Chi decide se proseguire è una persona indicata in anticipo, che ha davanti le verifiche e i criteri, non un’impressione.
Perché il rientro fa parte del piano?
Un piano di migrazione senza ritorno indietro è una scommessa. Il sistema di partenza resta integro e disponibile per un periodo concordato dopo il cutover. Dove la tecnica lo consente, resta anche allineato: con Data Guard il vecchio database può diventare a sua volta la copia di riserva del nuovo; con la replica logica si può attivare la replica in senso inverso.
Così, se nelle prime ore o nei primi giorni emerge un problema, si torna al sistema di partenza senza perdere i dati scritti nel frattempo. Il vecchio ambiente si dismette solo quando il nuovo ha dimostrato di reggere: prestazioni, coerenza dei dati, tempi di risposta delle funzioni critiche, prime chiusure.
Quando basta il team interno e quando serve un aiuto esterno?
Un team interno può gestire la migrazione se ha già usato in produzione le tecniche scelte e se può dedicare una persona esperta al progetto per tutto il tempo necessario, senza lasciare scoperta la gestione ordinaria. Quando questa esperienza manca, il rischio più insidioso non è il passaggio che fallisce in modo evidente. È il problema silenzioso: dati disallineati che emergono settimane dopo, interrogazioni che rallentano senza una causa apparente, copie di sicurezza mai provate sul nuovo ambiente.
Spesso la formula più efficace è mista: il team interno porta la conoscenza delle applicazioni, un gruppo esterno porta l’esperienza sulle tecniche di migrazione e sulle prove.
In sintesi
- Il fermo di una migrazione Oracle si riduce e si pianifica; un fermo nullo non si promette.
- Si parte dal cutover: quanto fermo è accettabile e in quale momento lo decide chi usa il sistema.
- Data Guard è incluso nella Enterprise Edition; GoldenGate ha una licenza propria; ZDM automatizza i flussi verso le destinazioni indicate da Oracle.
- Dipendenze, compatibilità, licenze e prestazioni si verificano prima di cominciare.
- Il passaggio si prova su una copia, con scaletta, verifiche e criteri scritti.
- Il sistema di partenza resta disponibile, e dove possibile allineato, finché il nuovo non ha dimostrato di reggere.
Domande frequenti
Una migrazione Oracle può avvenire senza alcun fermo?
Di norma no. Con una replica continua il fermo si riduce al cutover, che può durare pochi minuti, ma un momento in cui le scritture si fermano e le applicazioni cambiano destinazione resta. Quanto dura dipende da edizione, piattaforma, volumi e applicazioni, e si misura nella prova generale.
GoldenGate è compreso nella licenza del database?
No. Oracle GoldenGate è un prodotto con licenza propria. Per alcune migrazioni verso il cloud di Oracle la documentazione di ZDM indica un modo specifico per usarlo: le condizioni si verificano prima di mettere la migrazione a budget.
Data Guard funziona con la Standard Edition 2?
No. Secondo le informazioni di licenza di Oracle, il database di riserva con Data Guard è compreso nella Enterprise Edition e non è disponibile nella Standard Edition 2. Chi usa quest’ultima deve scegliere altre tecniche per ridurre il fermo.
Quanto tempo serve per preparare una migrazione?
Dipende dal numero di database, dalle applicazioni collegate e dalla tecnica scelta. La fotografia tecnica iniziale serve anche a questo: dire quante prove servono e quando il cutover può essere fissato con ragionevole sicurezza.
Migrazioni e aggiornamenti con fermi pianificati sono una parte centrale del lavoro della nostra divisione Oracle & Database Engineering: valutazione tecnica, scelta della tecnica e delle licenze, prova generale, passaggio nella finestra concordata e rientro previsto.
Fonti
ApprofondisciOracle & Database EngineeringAmministrazione di database Oracle in outsourcing o accanto al team interno: prestazioni, copie provate, aggiornamenti di versione e migrazioni.
