Correzione sicura dei dati del database di produzione

Si verificano errori e talvolta i dati devono essere corretti in produzione. Qual è il modo più sicuro di procedere dal punto di vista di una grande azienda? Ci sono strumenti che possono aiutare? Ecco alcune considerazioni alla base di questo requisito ...

1. Dobbiamo registrare chi ha eseguito la query e ciò che ha eseguito
2. Idealmente, dobbiamo consentire alla persona di accedere alle query solo sulle tabelle di interesse e solo per un breve periodo
3. Qualunque cosa stia eseguendo, le query devono avere alcune informazioni utili per non consentire l'esecuzione a lungo termine e il blocco di SQL senza autorizzazione esplicita
4. Questo processo deve essere indipendente dal DB o almeno comprendere DB2, Oracle e SQL Server.

Stiamo provando a ridurre il rischio di interrogazioni di correzione ad hoc prod prodotte dal fare la "cosa sbagliata" e allo stesso tempo aggiungere un po 'di sicurezza / audtis al processo. Pensieri o Idee?

Mai e poi mai aggiornare manualmente i database di produzione.

Scrivi script.

Controlla tre volte e chiedi a più persone di farlo, non una sola persona che lo fa tre volte.

Includi query di convalida post-modifica in tali script.

Ogni volta che la situazione lo consente, testare l'intera modifica all'interno di una transazione che viene ripristinata alla fine, dopo l'esecuzione della convalida post-modifica. Se sei sicuro dei risultati, modifica il rollback in un commit.

Metti alla prova quegli script e nauseam contro un database di test.

Effettuare un backup prima di eseguire lo script sul database di produzione.

Esegui gli script.

Controlla, convalida e controlla tre volte i dati modificati usando gli script post-change-validation.

Fai comunque un controllo visivo.

Se qualcosa sembra spento, tornare indietro e ripristinare il backup.

Non procedere con i dati modificati come dati di produzione fino a quando non si è assolutamente sicuri che tutto sia a posto e non si sia disconnesso dai manager (aziendali) coinvolti.

La risposta di Marjan Venema è tecnicamente valida e dovrebbe essere seguita quando possibile. Ahimè, Marjan risponde dal punto di vista di un teorico o di un amministratore di database purista a cui piace fare le cose in modo pulito. In pratica, a volte i vincoli aziendali rendono impossibile fare le cose in modo pulito.

Immagina il seguente caso:

1. C'è un bug nel prodotto software che lo fa smettere di funzionare quando rileva ciò che ritiene essere un'incoerenza dei dati nel database,

2. Tutti gli sviluppatori che potrebbero potenzialmente correggere il bug nell'applicazione non sono raggiungibili,

3. La società sta attualmente perdendo migliaia di dollari l'ora (diciamo $ 6.000, che significa $ 100 al minuto),

4. Il bug riguarda diverse tabelle, una delle quali è enorme e riguarda solo i dati stessi, non lo schema,

5. Al fine di aggirare il bug, dovresti sperimentare un po 'con i dati, che comporta sia la rimozione che la modifica,

6. Il database è di grandi dimensioni e occorrerebbero tre ore per eseguire o ripristinare il backup,

7. L'ultimo backup completo è stato eseguito tre settimane fa; ci sono anche backup incrementali giornalieri e l'ultimo backup incrementale giornaliero è stato eseguito 14 ore fa,

8. I backup del database sono considerati affidabili; sono stati severamente testati, anche di recente,

9. Perdere 14 ore di dati non è accettabile, ma la perdita di una o due ore di dati è,

10. L'ambiente di gestione temporanea è stato infine utilizzato sei mesi fa; sembra che non sia aggiornato e potrebbero essere necessarie ore per configurarlo,

11. Il database è Microsoft SQL Server 2008 Enterprise.

Il modo pulito per fare le cose è:

1. Ripristina il backup in un ambiente di gestione temporanea,

2. Sperimenta lì,

3. Controlla lo script finale due volte,

4. Esegui lo script sul server di produzione.

Solo il primo passo costerà $ 18.000 per la tua azienda. Il rischio è piuttosto basso se si esegue il terzo passo in modo impeccabile, ma poiché si lavora sotto una pressione estrema, il rischio sarebbe molto più elevato. Potresti finire con uno script che ha funzionato perfettamente nella gestione temporanea, quindi ha rovinato il database di produzione.

Invece, avresti potuto fare così:

1. Crea uno snapshot (Microsoft SQL Server lo supporta e ci vogliono pochi secondi per ripristinare (e nulla per creare) uno snapshot di un database che impiega un'ora per il backup; immagino che anche altri prodotti di database supportino gli snapshot),

2. Sperimenta direttamente sul database di produzione, ripristinando l'istantanea se qualcosa va storto.

Mentre un purista sistemerebbe il database in modo pulito e rischierebbe di rovinare le cose data la pressione del tempo sprecando più di $ 20.000 della sua azienda, un amministratore del database che tiene conto dei vincoli aziendali risolverà il database in un modo che minimizzerà i rischi (grazie alle istantanee) mentre lo fa rapidamente.

Conclusione

Anch'io sono un purista e odio fare le cose in modo non pulito. Come sviluppatore, refactoring il codice che modifico, commento le parti difficili che non possono essere refactored, collaudo unitamente la base di codice e faccio revisioni del codice. Ma prendo anche in considerazione le circostanze in cui o fai le cose in modo pulito e il giorno dopo sei licenziato, o riduci al minimo sia i rischi che l'impatto finanziario facendo un trucco rapido che funziona.

Se un ragazzo IT vuole fare le cose in modo pulito solo per motivi di pulizia mentre causa migliaia di dollari di perdita per l'azienda, questo ragazzo IT ha un profondo fraintendimento del suo lavoro.

Correzione sicura dei dati del database di produzione. Qual è il modo più sicuro di procedere dal punto di vista di una grande azienda? Ci sono strumenti che possono aiutare?

È una cattiva pratica e una porta di invito per ulteriori problemi e problemi relativi ai dati. C'è anche una frase che descrive questo approccio come " Veloce e Sporco ".

Continuare le correzioni / gli aggiornamenti direttamente su un server di produzione è molto pericoloso , poiché costerà a te / alla tua azienda una fortuna ( cause legali, dati errati / sporchi, aziende perse, ecc. )

Tuttavia, i bug saranno presenti e dovranno essere corretti. Lo standard industriale di fatto è applicare patch / (script di distribuzione) su uno Staging (ambiente di pre-produzione con l'ultima copia del database prod) e consentire all'analista dei dati / al QA di verificare la correzione. Lo stesso script dovrebbe essere controllato in base alla versione e applicato all'ambiente Prod per evitare problemi.

Esistono numerose buone pratiche menzionate in questo documento relativo alle buone pratiche relative al database post- stadiazione

Un buon insieme di riferimenti da guardare sono:

• Quanto velocemente è possibile ottenere un bug risolto in produzione?
• Costi di sviluppo software Pyramid
• Quanto tempo dovrebbe essere assegnato per i test e la correzione di errori

Nella maggior parte delle organizzazioni ho lavorato aggiornando i dati nell'ambiente live sempre con un piccolo gruppo di persone con i diritti di accesso, in genere con un titolo professionale come DBA. Poiché gli aggiornamenti possono essere eseguiti solo da un numero limitato di persone, esiste almeno la possibilità che acquisiscano familiarità con i dati e quindi riduca (ma non elimini) il rischio di problemi.

La persona che scrive lo script di aggiornamento lo farebbe nei test (come da altre risposte) e riceverebbe una grave disconnessione dai non tecnici (coloro che conoscono il sistema, più qualcuno con un'autorità senior) che le funzionalità sembrano essere "di nuovo corrette" in oltre ai propri test paranoici. Gli script e i dati sarebbero stati verificati in modo indipendente da un altro tecnico (spesso il ruolo DBA che ho citato) durante il test prima di essere lanciato in produzione. I risultati verrebbero confrontati con i valori previsti (unici per ogni scenario, ma spesso cose come i conteggi delle righe ecc.)

In una società per cui ho lavorato, fare i backup non era un'opzione realistica, ma tutte le righe da aggiornare sono state cancellate in un file di testo come riferimento PRIMA dell'aggiornamento, e poi di nuovo DOPO l'aggiornamento, nel caso in cui qualcuno dovesse mai fare riferimento ad esso. Gli script e questi dati sono conservati in un registro delle modifiche dei dati organizzato correttamente.

Ogni azienda è unica e i rischi relativi all'aggiornamento di alcuni dati sono chiaramente maggiori rispetto ad altri.

Avendo un processo che fa sì che le persone debbano saltare attraverso i cerchi per fare questi aggiornamenti, si spera che tu promuova una cultura che induca le persone a considerare questo come ultima risorsa e crei un sano atteggiamento di "doppio controllo, triplo controllo" attorno a queste cose.

Ci sono momenti in cui è necessario correggere dati su Prod che non esistono su altri server. Questo non è solo dovuto a bug ma potrebbe derivare da un'importazione di dati da un file inviato da un client errato o da un problema causato da qualcuno che ha hackerato il tuo sistema. O da un problema causato da una cattiva immissione dei dati. Se il tuo database è di grandi dimensioni o critico nel tempo, potresti non avere il tempo di ripristinare l'ultimo backup e correggere su dev.

La tua prima difesa (e qualcosa che nessun database aziendale può permettersi di essere senza!) Sono le tabelle di controllo. Puoi usarli per annullare modifiche errate ai dati. Inoltre, è possibile scrivere script per riportare i dati allo stato precedente e testarli su altri server molto prima che sia necessario ripristinare i dati controllati. Quindi l'unico rischio è che siano stati identificati i record corretti da ripristinare.

Successivamente tutti gli script per modificare i dati sulla produzione dovrebbero includere quanto segue:

Dovrebbero essere in transazioni esplicite e avere un blocco TRY Catch.

Dovrebbero avere una modalità di test che è possibile utilizzare per ripristinare le modifiche dopo aver visto quali sarebbero state. È necessario disporre di una dichiarazione selezionata prima di apportare la modifica e una corsa dopo la modifica per assicurarsi che la modifica sia corretta. Lo script dovrebbe assicurarsi che sia mostrato il numero di righe elaborate. Abbiamo alcune di queste pre-impostate in un modello che assicura che i pezzi vengano eseguiti. Modelli per le modifiche, aiutano a risparmiare tempo nella scrittura della correzione.

Se è presente una grande quantità di dati da modificare o aggiornare, prendere in considerazione la possibilità di scrivere lo script da eseguire in batch con commit per ciascun batch. Non si desidera bloccare l'intero sistema mentre si correggono un milione di record. Se hai grandi quantità di dati da correggere, assicurati che un dba o qualcuno che è abituato a ottimizzare le prestazioni riesamini lo script prima di essere eseguito ed eseguito durante le ore di chiusura, se possibile.

Successivamente tutti gli script per modificare qualsiasi cosa sulla produzione vengono revisionati e messi nel controllo del codice sorgente. Tutti loro - senza eccezioni.

Infine, gli sviluppatori non dovrebbero eseguire questi script. Dovrebbero essere gestiti da dbas o da un gruppo di gestione della configurazione. Se non si dispone di nessuno di questi, solo le persone che sono leader tecnologici o superiori dovrebbero avere il diritto di gestire le cose su prod. Meno persone gestiscono cose su prod, più facile è rintracciare un problema. Gli script devono essere scritti in modo che vengano semplicemente eseguiti, senza evidenziare parti ed eseguendo un passaggio alla volta. Sono le cose in evidenza che spesso mettono le persone nei guai quando si sono dimenticate di evidenziare la clausola where.

Ho aggiornato più volte i dati durante l'esecuzione dei database di produzione. Concordo con la risposta sopra, che questa non sarebbe mai una procedura operativa standard.

Sarebbe anche costoso (guarderemmo alle spalle di ognuno e discuteremo 2 o 3 forse)

E la regola d'oro: fai sempre un'istruzione select per mostrare cosa verrebbe fatto prima di fare un'istruzione update / delete / insert

La regola d'oro che viene applicata dalle altre due persone nella squadra!

re: la risposta di MainMa ...

C'è un bug nel prodotto software che lo fa smettere di funzionare quando rileva ciò che ritiene essere un'incoerenza dei dati nel database,

• Come fai a sapere che è un "bug"? I dati non sono coerenti in base alle regole stabilite dallo sviluppatore del prodotto software.

Tutti gli sviluppatori che potrebbero potenzialmente correggere il bug nell'applicazione non sono raggiungibili,

La società sta attualmente perdendo migliaia di dollari l'ora (diciamo $ 6.000, che significa $ 100 al minuto),

• Apparentemente una perdita di $ 100 / minuto non è abbastanza importante per la gestione dell'azienda per poter individuare e assicurare che gli sviluppatori competenti tornino per correggere l'errore e aiutarti a ripristinare il database.

Il bug riguarda diverse tabelle, una delle quali è enorme e riguarda solo i dati stessi, non lo schema,

• Tutti i problemi del database "riguardano" lo schema. Come viene progettato lo schema è ciò che determinerà come risolvere questo problema.

Al fine di aggirare il bug, dovresti sperimentare un po 'con i dati, che comporta sia la rimozione che la modifica,

• Ecco a cosa serve il tuo database di gestione temporanea. Potrebbe essere necessario ripopolarlo con i dati "danneggiati" dal database di produzione subito dopo aver eseguito un backup online completo della produzione.

Il database è di grandi dimensioni e occorrerebbero tre ore per eseguire o ripristinare il backup,

• Quindi è meglio iniziare subito in modo che possa funzionare mentre analizzi il problema, sviluppando gli script di correzione, testandoli e perfezionandoli insieme agli sviluppatori e agli altri DBA che ti aiutano.

L'ultimo backup completo è stato eseguito tre settimane fa; ci sono anche backup incrementali giornalieri e l'ultimo backup incrementale giornaliero è stato eseguito 14 ore fa,

• Non hai almeno backup online completi giornalieri? Sei fregato. Ma probabilmente ci sei abituato. Meno male che è in esecuzione il backup completo che hai avviato sopra. Assicurati che la gestione tratti ogni minuto dei costi che avrebbero potuto essere evitati con i backup online giornalieri.

I backup del database sono considerati affidabili; sono stati severamente testati, anche di recente,

• Eccellente! Quindi potrebbe non essere necessario ripristinare il database più di una volta.

Perdere 14 ore di dati non è accettabile, ma la perdita di una o due ore di dati è,

• Nello scenario che hai descritto, tutte le scommesse sono disattivate. Questa è una situazione di "gestione delle catastrofi informative". Una buona cosa da fare per il management è documentare i costi che potrebbero essere evitati in futuro con backup e procedure e risorse di ripristino più efficienti.

L'ambiente di gestione temporanea è stato infine utilizzato sei mesi fa; sembra che non sia aggiornato e potrebbero essere necessarie ore per configurarlo,

• Se il sistema di backup supporta i backup online (ovvero il database è pienamente operativo durante il backup), è possibile eseguire l'estrazione per ripopolare il database di gestione temporanea contemporaneamente se si dispone di risorse hardware sufficienti per evitare di rallentare il backup.

Il database è Microsoft SQL Server 2008 Enterprise.

• Più difficile da fare tutto questo, ma non impossibile. In bocca al lupo!