Qual è il tuo flusso di lavoro per pianificare una migrazione dei dati?

Tante volte sono stato coinvolto alla fine di uno sforzo di sviluppo software e mi è stato detto qualcosa del tipo "okay, abbiamo tutto questo nuovo codice e richiede che le tabelle cambino e che i dati vengano migrati".

Sembra che ogni volta si tratti di uno scenario unico, sparo alla moda e ipotesi migliore. Sento che questa è la mia abilità più debole impostata come DBA.

Mi piacerebbe entrare in alcuni schemi di approccio, gestione e test delle migrazioni dei dati .

Per favore, mi indizio su alcune migliori pratiche e / o dove posso ottenere materiale di apprendimento per aiutarmi a migliorare in questo settore.

Ogni volta che l'ho fatto, abbiamo fatto due passaggi ...

1. fare uno snapshot e, lavorando su un altro server, utilizzarlo per determinare cosa deve essere fatto per la migrazione e scriverlo.
2. una volta che hanno lo script in mano, lo snapshop viene ripristinato sul sistema di test ed è programmato per vedere se verrà eseguito entro il tempo richiesto o se sarà sintonizzato e modificato fino a quando non sarà possibile.
3. far firmare agli stakeholder che nulla sembra sbagliato con i dati sul sistema di test.

Quindi, per un fine settimana, hai un'interruzione programmata:

1. Venerdì sera, i sistemi che utilizzano il database vengono disattivati, viene eseguito un backup completo a freddo e gli script vengono eseguiti per migrare / modificare / qualunque cosa ai dati
2. I sistemi vengono ripristinati con un indirizzo privato o in qualche modo impostati in modo che non siano aperti a chiunque, ma agli stakeholder per i test di accettazione
3. Se le parti interessate approvano, il sistema viene messo online e reso pubblico; in caso contrario, il database viene ripristinato dal backup effettuato venerdì sera e si riavvia il processo.

Con il nostro programma, la gente del database di solito aveva dalle 18:00 alle 10:00 di sabato per eseguire gli script di backup e migrazione, quindi il nostro obiettivo era che funzionassero in meno di 8 ore (~ 6 di questi erano backup), quindi noi " avere del tempo per i nostri test e correzioni prima che vengano rilasciati agli stakeholder.

Le parti interessate hanno avuto la loro finestra temporale in anticipo, quindi sapevano di lasciare il weekend aperto per i test all'inizio della finestra. Avrebbero anche detto alla fine della loro finestra, in genere domenica pomeriggio, dove se tutti non avessero firmato, avremmo dovuto iniziare a tornare indietro.

Oh, e ovviamente ... se qualcuno ha avuto un cambiamento durante uno dei test di accettazione, e abbiamo fatto un cambiamento, ciò significava che tutte le sottoscrizioni degli stakeholder erano annullate e dovevano riprovare ... quindi proveremmo a dedicare loro un po 'di tempo a cercare i problemi ed eseguire le correzioni in blocco, anziché applicarle una alla volta.

Fortunatamente, le uniche volte in cui ho avuto una di quelle situazioni in cui non potevamo avere tempi di inattività significativi, i sistemi che stavo migrando erano alimentati da script, non da input dell'utente, quindi potevo solo avere due sistemi paralleli attivi e scambiarli quando le cose sono state firmate. (solo una volta c'è stato un problema, quando il mio capo ha insistito sul fatto che avessimo un backup completo, non capendo che l'intera cosa sarebbe stata ancora online a un IP diverso ... quindi cosa avrebbe dovuto essere un'interruzione di 5 minuti in un brutta giornata è diventata un'interruzione di 5 ore.)

Tutto dipende dal volume di dati rispetto alla potenza dell'hardware che supporta il database e dagli accordi sulla disponibilità del sistema. Ti capita di avere dei tempi di inattività o dovrebbe essere fatto tutto online? Inizia a pulire i dati, cancellando il più possibile le righe obsolete. Questo è un progetto su se stesso. Se i dati sono puliti e di valore, chiedi all'utente di decidere i tempi di fermo. Se i tempi di inattività sono disponibili, è abbastanza semplice, se si tratta di una trasformazione nota che dovrebbe essere applicata ai dati esistenti per formare la raccolta aggiornata. Se non ci sono - o molto poco - tempi di inattività consentiti, la sfida ha inizio. Oracle lo supporta in diversi modi, come la ridefinizione dei tavoli online e la nuova ridefinizione basata sull'edizione 11g. Con la ridefinizione dei tavoli online puoi preparare i tavoli in modo che assumano la loro nuova forma. Questo può essere fatto mentre l'applicazione è in esecuzione sul vecchio formato della tabella [s]. Se sono tutti pronti, puoi passare alla nuova forma della tabella [s]. Questo sarà anche il momento di introdurre il nuovo codice dell'applicazione e allo stesso tempo segna l'inizio dei tempi di inattività richiesti per mettere in atto la nuova applicazione. I dati storici meno recenti possono essere preparati prima della migrazione dei dati attivi e mantenuti sincronizzati utilizzando strumenti come Oracle Golden Gate. In tale scenario, si crea effettivamente un nuovo database che assume il ruolo del vecchio database. La ridefinizione basata sull'edizione è più adatta se non sono necessarie modifiche alla tabella. Ci sono tonnellate di opzioni da considerare e penso che sia difficile dare una buona regola che funzioni sempre. Questo sarà anche il momento di introdurre il nuovo codice dell'applicazione e allo stesso tempo segna l'inizio del tempo di inattività richiesto per mettere in atto la nuova applicazione. I dati storici meno recenti possono essere preparati prima della migrazione dei dati attivi e mantenuti sincronizzati utilizzando strumenti come Oracle Golden Gate. In tale scenario, si crea effettivamente un nuovo database che assume il ruolo del vecchio database. La ridefinizione basata sull'edizione è più adatta se non sono necessarie modifiche alla tabella. Ci sono tonnellate di opzioni da considerare e penso che sia difficile dare una buona regola che funzioni sempre. Questo sarà anche il momento di introdurre il nuovo codice dell'applicazione e allo stesso tempo segna l'inizio del tempo di inattività richiesto per mettere in atto la nuova applicazione. I dati storici meno recenti possono essere preparati prima della migrazione dei dati attivi e mantenuti sincronizzati utilizzando strumenti come Oracle Golden Gate. In tale scenario, si crea effettivamente un nuovo database che assume il ruolo del vecchio database. La ridefinizione basata sull'edizione è più adatta se non sono necessarie modifiche alla tabella. Ci sono tonnellate di opzioni da considerare e penso che sia difficile dare una buona regola che funzioni sempre. I dati storici meno recenti possono essere preparati prima della migrazione dei dati attivi e mantenuti sincronizzati utilizzando strumenti come Oracle Golden Gate. In tale scenario, si crea effettivamente un nuovo database che assume il ruolo del vecchio database. La ridefinizione basata sull'edizione è più adatta se non sono necessarie modifiche alla tabella. Ci sono tonnellate di opzioni da considerare e penso che sia difficile dare una buona regola che funzioni sempre. I dati storici meno recenti possono essere preparati prima della migrazione dei dati attivi e mantenuti sincronizzati utilizzando strumenti come Oracle Golden Gate. In tale scenario, si crea effettivamente un nuovo database che assume il ruolo del vecchio database. La ridefinizione basata sull'edizione è più adatta se non sono necessarie modifiche alla tabella. Ci sono tonnellate di opzioni da considerare e penso che sia difficile dare una buona regola che funzioni sempre.

È un argomento interessante, Ronald.

Buone risposte finora. Aggiungerò un altro paio di punti in considerazione.

Innanzitutto, quando puoi eseguire le migrazioni con un semplice DML SQL, puoi fare affidamento in gran parte sul tuo motore SQL per assicurarti che tutte le righe vengano elaborate correttamente. Sono stato coinvolto in migrazioni, tuttavia, dove parte della migrazione era un po 'più complicata: ci sono state effettive trasformazioni di dati quando i dati sono stati spostati in una nuova struttura. In questi casi, è importante disporre di un processo in grado di gestire i seguenti elementi:

• Conta i record in vs. record elaborati.
• Rileva gli errori durante la trasformazione e gestiscili in un modo che consenta alla trasformazione di continuare e permetta di rielaborare i record "errati" dopo aver identificato una correzione.
• I conteggi dei record dovrebbero includere record "errati", ad esempio records-in = records-out-good + bad-records
• Se la trasformazione cambia il conteggio dei record (un record di input diventa più di un record di output, ad esempio), ha un modo per prevedere il numero di record di output con cui finirai e quindi testare i risultati rispetto a quel conteggio.

L'altro punto che aggiungerei è che è importante avere un piano per quello che farai se / quando le cose non vanno come previsto. Questa è davvero una funzione della distribuzione nel suo insieme, ma è una che sembra essere abbastanza frequentemente cancellata che ho pensato che valesse la pena menzionarla.

Una panoramica di come farlo

Iniziare con

• Hai il database "after" in test / UAT / qualunque "DB di lavoro"
• Hai il database "prima" in produzione. Quindi usalo per creare una copia della produzione da qualche parte = "DB di riferimento". E un altro come "DB test script"
• Spero anche che tu abbia un sacco di script di sviluppo con i tuoi ALTER ecc. In tal caso, un'altra copia della produzione con lo script di sviluppo applicata, in modo pulito e in ordine è utile = "cambia DB"

Quindi, scarica Red Gate Confronta strumenti o qualcosa come Embarcadero SQL Change manager . Non puoi migrare facilmente senza di essa. Il costo è banale per la quantità di tempo risparmiata. E, soprattutto, gli script generati apportano modifiche in un'unica transazione, il che significa una distribuzione pulita

Adesso,

• generare script di modifica e rollback utilizzando gli strumenti confrontando tra "riferimento" e "modifica"
• applicare lo script di modifica a "test di script" e confrontarlo con "DB di lavoro"
• applica lo script di rollback a "test script" e confronta nuovamente con "e confronta nuovamente con" DB funzionante "

Ora, hai script di modifica e rollback sicuri + testati da applicare ogni volta.

E ovviamente esegui il backup del database prima di qualsiasi modifica perché statisticamente alla fine succederà sempre merda.

Gli strumenti di Red Gate possono anche essere confrontati con una cartella che è sotto il controllo del codice sorgente. Quindi catturiamo gli ALTER ecc. Nel nostro controllo del codice sorgente separatamente negli script di modifica effettivi.