Esistono best practice per il controllo degli errori nella business logic per gli aggiornamenti del DB? [chiuso]

7

Lavoro per un'azienda con database di grandi dimensioni che si aggiornano tutti durante la notte, pronti per essere interrogati dagli utenti al mattino. Questi carichi durante la notte essenzialmente troncano tutte le tabelle, e ricaricano di nuovo usando una logica aziendale piuttosto complicata.

Questo è tutto a posto, ma a volte, piuttosto che seguire le giuste rotte, è necessaria una correzione rapida nella logica aziendale e le modifiche verranno apportate sul server "Live" alla logica di business senza troppi test .

Questo, come sono sicuro che puoi immaginare, ha portato a errori sottili ma significativi. Fondamentalmente voglio ora scrivere in modo indipendente la logica (probabilmente in T-SQL) che cercherà di individuare eventuali modifiche anomale, quindi almeno sono davanti al gioco e posso segnalarlo prima.

La mia domanda è, ovviamente, qualcuno ha qualche consiglio su questo? Esiste una teoria o una buona pratica generale che potrei incorporare per limitare, auspicabilmente, l'impatto dei futuri cambiamenti "veloci e sporchi" alla logica aziendale?

Proprio per quello che sai, utilizziamo il controllo del codice sorgente e utilizziamo gli ambienti di server Live, UAT e Dev, ma è giusto che a volte le modifiche vengano apportate immediatamente, piuttosto che passare attraverso i canali più rigidi.

    
posta CatchingMonkey 20.10.2011 - 21:13
fonte

3 risposte

3

L'uso delle transazioni dovrebbe pagare qui. Se si verificano problemi, non eseguire il commit delle modifiche apportate, è sufficiente riportarlo all'inizio o in un altro momento nel tempo (suddividendolo in più transazioni con le tabelle per ogni passaggio). Se si utilizzano tabelle aggiuntive per ogni fase del processo, è possibile esaminare le modifiche apportate ai dati in ciascun punto e individuare dove si è verificato l'errore.

In base al feedback che mi hai fornito per la mia risposta originale. Sappiamo alcune cose sul tuo ambiente:

(1) È un ambiente aziendale in cui c'è poca comunicazione tra i team. Ciò è evidenziato dal fatto che sembra difficile per te ottenere i file di registro dal team DBA.

(2) È un mostro di un sistema.

Prima di poter risolvere un problema, devi capirlo. Nel tuo caso, ottenere i file di registro e tenere un diario / diario degli errori e dei tipi di errori che otterrai ti darà una migliore idea di cosa sta succedendo. Stai ricevendo errori di immissione dei dati? Mancano i dati? L'integrità referenziale viene violata ovunque? Se riesci a correggere gli errori, avrai una migliore comprensione di cosa sta andando storto. Se ottenere i registri è problematico come dici tu, parla con il tuo manager del problema e chiedigli se può ottenere i log per te. In un ambiente aziendale, le persone tendono ad essere molto territoriali riguardo al proprio lavoro e non rispondono a tutti in quanto sono probabilmente sotto stress con una larghezza di banda minima per affrontare altri problemi. Se la richiesta proviene da qualcuno più in alto, potresti ricevere una risposta più positiva.

Dopo aver ottenuto i file di log e gestito il tema dei problemi, dovresti avere una seconda discussione con il tuo manager. Dagli un feedback su ciò che hai trovato e suggerisci due o tre soluzioni per risolverlo. Descrivi i benefici a breve e a lungo termine di ciascuno, fornendo una stima approssimativa di quanto a lungo pensi che sarebbe necessario implementare. La chiave qui è la comunicazione. Le tue risposte alla mia risposta iniziale indicano che c'è una completa mancanza di esso, quindi è necessario fare un grande sforzo per promuoverlo. Avere il tuo manager che ti supporta ti fornirà un mezzo aggiuntivo per comunicare con il team DBA in quanto può parlare con il proprio manager se non risponde.

Se tutto questo fallisce e non sei soddisfatto della situazione, il mio unico altro consiglio è che cerchi un altro posto dove lavorare. Ho riscontrato che questa situazione si verifica in molte aziende e in diversi gradi e può ridursi a un caso di quanto è possibile tollerare. Dopo che mi è successo un paio di volte, sono giunto alla conclusione che semplicemente non era la mia azienda e che i problemi emersi riguardavano la gestione. Se mi rendesse la vita difficile, passerei semplicemente ad altre cose. La vita è troppo breve.

Ovviamente, puoi utilizzare i file di registro standard che vengono forniti con il tuo DBMS, ma se la tua azienda opera sotto un "affrettato mantra" per quanto riguarda l'ottenimento di cose fuori dalla porta e sta causando molto di ritardi, dovresti sforzarti di discutere questi problemi con il management. Mostra loro ciò che la loro ignoranza dei test sta costando loro.

    
risposta data 20.10.2011 - 23:03
fonte
1

Suppongo che la corsa notturna stia chiamando le stored procedure. Se non riesci a scrivere un log di testo e amp; ottenere l'accesso a combattere per questo. A volte i DBA possono essere un po 'possessivi dei log perché non gli piacciono gli sviluppatori che li leggono e fanno domande difficili;).

Supponendo di perdere il combattimento, crea una semplice tabella di registrazione e una libreria di log (se il tuo RDBMS non ne ha uno). Quindi durante la corsa scrivere le voci sulla tabella. Volete queste voci al di fuori della transazione principale in modo da ottenere "tipo di errore rilevato XYZ nel record ABC che ripristina" le voci di tipo nel registro invece di avere il registro degli errori anche rollback.

Quindi, la prima cosa che fai al mattino è la scansione delle voci del registro dei giorni & cercare problemi.

Nel tempo potresti riscontrare problemi di dati che non vengono registrati. Se si verifica un problema non registrato, scrivere il codice per identificare e registrare il problema prima di correggere il codice (un po 'come TDD). In questo modo, come i test di unità, le ipotesi relative ai dati verranno documentate e testate e le eccezioni registrate in modo da poterle correggere.

    
risposta data 21.10.2011 - 08:10
fonte
0

Se hai molte di queste modifiche, allora la tua organizzazione deve affrontare il fatto che il software installato non corrisponde ai requisiti aziendali. Di conseguenza, l'organizzazione dovrebbe avviare un progetto per determinare il divario e correggere il software esistente e infine pubblicare una nuova versione o versione.

Se la tua organizzazione desidera qualità, non c'è alcun sostituto per seguire adeguate procedure di sviluppo, test e promozione che richiedono tempo e impegno.

    
risposta data 21.10.2011 - 07:49
fonte

Leggi altre domande sui tag