Quali sono le pratiche che segui per evitare aggiornamenti errati dei dati in grandi database?

Un consiglio tipico prima di qualsiasi distribuzione di produzione è il backup del DB per primo. In questo modo, se il nuovo aggiornamento ha qualche problema che può portare a una potenziale perdita di dati o al danneggiamento logico dei dati, allora hai ancora un backup per confrontare e correggere i vecchi record.

Tuttavia, questo può funzionare bene fino a quando la dimensione del DB è in pochi GB. Quando le dimensioni del database sono enormi, i backup richiedono molto tempo. Quali sono alcune best practice da seguire in tali situazioni, in modo da evitare la corruzione dei dati logici a causa di problemi logici in una distribuzione di codice?

Come persona che si è occupata regolarmente dell'aggiornamento del database di produzione per i clienti per i nostri aggiornamenti del software, vi dico che il modo migliore per ridurre al minimo gli errori è effettuare gli aggiornamenti nel modo più semplice possibile.

Se è possibile eseguire una modifica a tutti i record piuttosto che a record specifici, è preferibile.

In altre parole, se ti viene fornito un elenco di ID di record che richiedono il loro stato modificato, dovresti chiederti perché l'aggiornamento viene eseguito nel contesto del programma. Potrebbe essere quello dei 10 record che devi aggiornare, la tabella ha solo 10 elementi. Pertanto dovresti chiederti se concettualmente tutto quello che stai facendo è aggiornare lo stato di tutti i record.

Se è possibile inserire, è preferibile.

L'atto di aggiungere un record è autonomo. Con questo intendo dire che c'è solo un effetto collaterale dell'aggiunta di un record, e cioè l'esistenza di un record che non esisteva prima. Pertanto, a meno che non si stia aggiungendo un record che non dovrebbe essere presente, non dovrebbero esserci problemi.

Se è possibile evitare la cancellazione, è preferibile.

Se si esegue una cancellazione, si rimuovono i dati che altrimenti sarebbero irrecuperabili senza un backup. Se possibile, prova a organizzare i dati in modo tale da poter disabilitare i record modificandone lo stato anziché eliminarli fisicamente. L'eccesso di dati può essere inserito in una partizione o può essere rimosso completamente in un secondo momento, una volta che si è sicuri che non ci siano problemi.

Avere una politica di aggiornamento coerente.

Se è necessario aggiornare un record, può succedere una delle seguenti cose:

1. Il tuo record non esiste.
2. Il tuo record esiste ma è già stato modificato.
3. Il tuo record esiste e richiede la modifica.

È necessario disporre di una politica per determinare il corso dell'azione qualora qualcosa non dovesse andare come previsto. Per semplicità, dovresti essere coerente su tutta la linea e applicare questa politica in qualsiasi situazione di questo tipo, non solo per tabelle specifiche. Ciò semplifica il recupero dei dati in un secondo momento. In generale, la mia politica è quella di scrivere lo script in modo da poterlo rieseguire in un secondo momento. Se lo script dovesse fallire, è bello sapere che è possibile apportare le opportune modifiche e rieseguire, tuttavia si è liberi di scegliere la propria politica più adatta a voi.

I backup

Questo non ti scusa affatto dall'eseguire un backup prima di eseguire qualsiasi aggiornamento in un ambiente di produzione! Sebbene anche con un backup, ritengo che non sia necessario utilizzare il backup. Perdita di dati non possono essere una possibilità, anche nel caso peggiore scenario.

Conclusione

Non sarai sempre in grado di farlo a modo tuo. Lo schema della tabella non sarà probabilmente determinato da te, pertanto significa che i tipi di aggiornamenti che puoi aspettarti di eseguire saranno sia complicati che rischiosi. Tuttavia, se hai qualcosa da dire in merito, aiuta a tenere a mente questi punti mentre eseguono gli aggiornamenti in modo semplice e senza rischi significativi.

In bocca al lupo!

A quel punto, dovresti usare un sistema DB di livello commerciale che supporti le istantanee (Oracles lo chiama Flashback ) - è esattamente il tipo di cosa per cui sono.

Tieni presente che hai comunque bisogno di un concetto di backup: avere più dati non significa eliminare i backup perché diventano difficili, al contrario. È necessario un tipo di backup continuo, ad esempio basato sulla replica con failover automatico.

Questa è un'area enorme - quindi aspettatevi che questa domanda sia chiusa in un ordine abbastanza breve ma, al di sopra della mia testa (come un ex DBA su enormi database):

Mart / Repository

È possibile mitigare alcuni rischi se si dispone di un database separato per gli aggiornamenti e di un database separato utilizzato da tutti. Quindi si tratta solo di copiare i dati da un DB all'altro dopo aver effettuato vari controlli. Mart / repository è come viene talvolta descritto ma potresti avere primario / secondario, master / slave ecc.

Codice sorgente

Per tutto ciò che può cambiare, disporre di un codice sorgente correlato al modo in cui i dati sono stati aggiornati. Quanti di questi hai variano da DB a DB ma potresti averne uno per ogni utente, ruolo, feed di dati, modulo di codice ecc.

Data di creazione / aggiornamento

Qualcosa che può essere di grande aiuto nel tracciare dove sono andate male le cose è avere una creazione e aggiornare i dati per ogni riga. Quindi puoi vedere a colpo d'occhio quali righe sono state aggiornate.

ETL

Se l'aggiornamento del database fa parte di una factory di dati, potresti essere in grado di ripristinare una vendemmia precedente da file flat.

di riserva

I backup completi occupano ovviamente molto spazio, ma il solito scenario è che un backup completo avvenga a intervalli regolari (ad esempio settimanali) e parziali su una base più frequente (giornaliera ecc.).

Ripristino puntuale

A seconda di quale RDBMS stai usando, alcuni punti di supporto nel recupero del tempo. Ciò consente di tornare indietro nel tempo in cui era noto un buono stato. Ciò richiede tuttavia una grande quantità di spazio di archiviazione che aumenta per quanto si desidera tornare indietro.

revisione

Avere tabelle di controllo ti dirà chi (o cosa) ha effettuato un aggiornamento di una riga. Questo può darti un buon punto di partenza per le indagini.

Storia

Per alcune tabelle critiche, una copia della riga pertinente viene acquisita al momento dell'aggiornamento in modo che i dati possano essere ripristinati, se necessario.

Convalida dei dati

Accertarsi che vengano eseguiti controlli di convalida di base sui dati prima che vengano archiviati, oltre ai controlli del tipo di dati di base.

Integrità referenziale

L'integrità referenziale non è un proiettile d'argento ma può aiutare a garantire che i dati siano ben strutturati.

Molte volte se stiamo eseguendo un aggiornamento "one shot" eseguiamo un backup della produzione e lo ripristiniamo su un server di prova. Quindi creiamo una serie di test ed eseguiamo il colpo singolo. Verifichiamo che i dati sono cambiati tramite i test e ci sentiamo a nostro agio che l'aggiornamento avrà esito positivo e modificiamo i dati nel modo che ci aspettiamo. Questo si chiama run a secco o di prova. Consiglio di farlo.

Questo dà a tutti un buon senso che il colpo singolo avrà successo. Non possiamo garantire il 100% perché i dati verranno aggiornati dalla data dell'esecuzione della prova, ma aumentiamo la fiducia e i fattori di successo. Questo dà anche un'idea reale di eventuali problemi che si verificano poiché stiamo usando una copia della produzione. Ora, se per qualche motivo l'aggiornamento non riesce, possiamo sempre tornare alla back run prima di ripristinare, se necessario, ma avremmo dovuto trovare e correggere eventuali problemi con la dry run.

Se non riesci a prendere l'intero database (se veramente grande) prova ad esportare una dimensione del campione più piccola ed esegui l'aggiornamento (piccola esecuzione a secco) rispetto ai dati effettivi. Preferirei l'intero set di dati, se possibile, per garantire che il test sia il più completo possibile.