Quali sono le pratiche che segui per evitare errori di aggiornamento dei dati nei grandi database?

Come qualcuno che si occupava regolarmente dell'aggiornamento del database di produzione per i clienti per i nostri aggiornamenti software, ti dico che il modo migliore per ridurre gli errori è rendere gli aggiornamenti il più semplici possibile.

Se è possibile eseguire una modifica su tutti i record anziché su record specifici, è preferibile.

In altre parole, se ti viene fornita una lista di id di record che hanno bisogno del 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 solo ha 10 elementi. Quindi dovresti chiederti se concettualmente tutto ciò che stai facendo è aggiornare lo stato di tutti i record.

Se è possibile inserire, è preferibile.

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

Se puoi evitare la cancellazione, è preferibile.

Se stai eseguendo una cancellazione, stai rimuovendo i dati che altrimenti sarebbero irrecuperabili senza un backup. Se possibile, cerca di organizzare i dati in modo tale da poter disabilitare i record modificandone lo stato anziché eliminando fisicamente il record. L'eccesso di dati può essere inserito in una partizione o può essere rimosso completamente in un secondo momento una volta che sei sicuro che non ci siano problemi.

Avere una politica di aggiornamento coerente.

Se devi aggiornare un record, può accadere 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 se qualcosa non va come previsto. Per ragioni di semplicità, dovresti essere coerente su tutta la linea e applicare questo criterio in situazioni qualsiasi di questo tipo, non solo per tabelle specifiche. Ciò rende più facile essere in grado di recuperare i dati in seguito. In generale, la mia politica è di scrivere lo script in modo tale da poterlo ri-eseguire in un secondo momento. Se lo script fallisce, è bello sapere che puoi apportare le regolazioni e rieseguire correttamente, tuttavia sei libero di scegliere la tua politica che ti si addice di più.

Backup

Questo non significa assolutamente che tu esegua un backup prima di eseguire qualsiasi aggiornamento in un ambiente di produzione! Anche se con un backup, considero un fallimento dover utilizzare il backup. La perdita di dati non può essere una possibilità anche nello scenario worst-case .

Conclusione

Non sarai sempre in grado di farlo a modo tuo. Lo schema della tabella non sarà probabilmente determinato da te, e come tale significa che i tipi di aggiornamenti che puoi aspettarti di eseguire saranno sia complicati che rischiosi. Anche se si ha un dubbio in materia, è utile tenere a mente questi punti poiché rendono gli aggiornamenti semplici e senza rischi significativi.

Buona fortuna!

A questo punto, dovresti utilizzare un sistema DB di livello commerciale che supporta snapshot (Oracles lo chiama Flashback ) - Questo è esattamente il tipo di cosa per cui sono.

Ricorda che hai comunque bisogno di un concetto di backup: avere più dati non significa abbandonare i backup perché diventano difficili, al contrario. Hai bisogno di una sorta di backup continuo, ad es. basato sulla replica con failover automatico.

Questa è un'area enorme - quindi aspettati che questa domanda sia chiusa in un ordine abbastanza breve ma, in cima alla mia testa (come un ex DBA su yuge database):

Mart / Repository

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

Codice sorgente

Per tutto ciò che può cambiare, avere un codice sorgente che si riferisce a come i dati sono stati aggiornati. Quanti di questi hai varia da DB a DB ma potresti averne uno per ogni utente, ruolo, feed di dati, modulo di codice ecc.

Crea / aggiorna la data

Qualcosa che può essere di grande aiuto quando si traccia dove le cose sono andate storte è 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 prende parte come parte di un data factory, potresti essere in grado di ripristinare una vendemmia precedente da file flat.

Backup

Naturalmente i backup completi richiedono molto spazio, ma il solito scenario è che un backup completo avvenga a intervalli regolari (per esempio settimanali) e parziali su base più frequente (ogni giorno ecc.).

Ripristino puntuale

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

Audit

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

Storia

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

Convalida dei dati

Verifica che i controlli di convalida di base vengano eseguiti sui dati prima che vengano archiviati, al di sopra dei controlli di tipo di dati di base.

Integrità referenziale

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

Molte volte, se eseguiamo un aggiornamento "one shot", eseguiamo un backup della produzione e lo ripristiniamo su un server di prova. Quindi creiamo un completo di test e eseguiamo l'unico colpo. Verifichiamo che i dati sono cambiati tramite i test e ci rendiamo conto che l'aggiornamento avrà successo e modificherà i dati in un modo che ci aspettiamo. Questo è chiamato un processo a secco o di prova. Consiglio di farlo.

Ciò dà a tutti la sensazione che l'uno abbia successo. Non possiamo garantire il 100% perché i dati verranno aggiornati dalla data della prova, ma aumentiamo la fiducia e i fattori di successo. Questo dà anche una vera idea di eventuali problemi che si verificano poiché stiamo usando una copia della produzione. Ora se per qualche motivo l'aggiornamento fallisce, possiamo sempre andare alla back run prima del ripristino, se necessario, ma dovremmo aver trovato e risolto eventuali problemi con il dry run.

Se non è possibile prendere l'intero database (se molto grande), provare ad esportare una dimensione campione più piccola ed eseguire l'aggiornamento (piccola corsa a secco) rispetto ai dati effettivi. Preferirei l'intero set di dati, se possibile, per garantire che il test sia il più completo possibile.