Come posso mantenere uno schema DB coerente su 18 database (server SQL)?

Question

Abbiamo 18 database che dovrebbero avere schemi identici, ma non lo fanno.In alcuni scenari, una tabella veniva aggiunta a una, ma non al resto.Oppure, alcune procedure memorizzate erano necessarie in alcuni database, ma non in altri.Oppure il nostro DBA ha dimenticato di eseguire uno script per aggiungere visualizzazioni su tutti i database.

Qual è il modo migliore per mantenere sincronizzati gli schemi dei database?

Answer 1

Per le correzioni/pulizia legacy, ci sono strumenti, come SQLCompare, che può generare script per sincronizzare i database.

Per i negozi .NET che eseguono SQL Server, è disponibile anche il file .NET Edizione del database di Visual Studio, che può creare script di modifica per le modifiche dello schema che possono essere archiviate nel controllo del codice sorgente e create automaticamente utilizzando il processo CI/build.

Answer 2

Confronto SQL di Red Gate è un ottimo strumento per questo.

Answer 3

SQLCompare è lo strumento migliore che ho utilizzato per trovare differenze tra i database e sincronizzarli.

Per mantenere sincronizzati i database, è necessario disporre di diverse cose:

1) Sono necessarie politiche su chi può apportare modifiche alla produzione.In genere dovrebbe trattarsi solo del DBA (team DBA per le organizzazioni più grandi) e 1 o 2 backap.I backup dovrebbero apportare modifiche solo quando il DBA è assente o in caso di emergenza.I backup NON dovrebbero essere distribuiti su base regolare.Imposta i diritti del database in base a questa politica.

2) Un processo e strumenti per gestire le richieste di distribuzione.Idealmente avrai un ambiente di sviluppo, un ambiente di test e un ambiente di produzione.Gli sviluppatori dovrebbero eseguire lo sviluppo iniziale nell'ambiente di sviluppo e inviare le modifiche al test e alla produzione, a seconda dei casi.Avrai bisogno di un modo per far sapere al DBA quando inviare le modifiche.NON consiglierei un processo in cui gridi al cubo successivo.Le organizzazioni di grandi dimensioni possono avere un comitato di controllo delle modifiche e le modifiche vengono apportate solo una volta al mese.Le aziende più piccole possono semplicemente chiedere allo sviluppatore di richiedere il test e, dopo il test, viene inoltrata una richiesta di distribuzione alla produzione.Un'azienda più piccola per cui lavoravo veniva usata Tracker dei problemi per queste richieste.

Usa tutto ciò che funziona nella tua situazione e nel tuo budget, basta avere un processo e disporre di strumenti che funzionino per quel processo.

3) Hai detto che a volte gli oggetti devono andare solo in una manciata di database.Con solo 18 database, probabilmente su un server, consiglierei di fare in modo che ogni Databse corrisponda esattamente agli oggetti.Solo 5 DB necessitano di usp_DoSomething?E allora?Inseriscilo in ogni database.Questo sarà molto più facile da gestire.Lo abbiamo fatto in questo modo su un sistema a 6 server con circa 250-300 DB.C'erano delle eccezioni, ma erano raggruppate.I database sul server C hanno ottenuto questo set aggiuntivo di oggetti.I database sul Server L hanno ottenuto quest'altro set.

4) Hai detto che a volte il DBA dimentica di distribuire gli script di modifica a tutti i DB.Questo mi dice che ha bisogno di strumenti per implementare i cambiamenti.Probabilmente sta prendendo uno script SQL, aprendolo in Query Analyser o Manegement Studio (o qualunque cosa tu usi) e andando manualmente in ciascun database ed eseguendo l'SQL.Questa non è una buona soluzione a lungo termine (o a breve termine). Porta Rossa (i creatori di SQLCompare sopra) hanno molti ottimi strumenti. Multiscrittura sembra che possa funzionare per scopi di distribuzione.Ho lavorato con un DBA che ha scritto il proprio strumento in SQL Server 2000 utilizzando O-SQl.Prenderebbe un file SQL e lo eseguirebbe su ciascun database sul server.Doveva eseguirlo su ciascun server, ma era migliore dell'esecuzione su ciascun DB.Ho anche aiutato a scrivere uno strumento VB.net che avrebbe fatto la stessa cosa, tranne che avrebbe anche esaminato un elenco di server, quindi doveva essere eseguito solo una volta.

5) Controllo del codice sorgente.Il mio team attuale non utilizza il controllo del codice sorgente e non ho abbastanza tempo per dirti quanti problemi ciò causa.Se non disponi di un qualche tipo di sistema di controllo del codice sorgente, procuratene uno.

Answer 4

Non ho abbastanza reputazione per commentare la risposta sopra, ma la versione pro di SQL Compare ha un'API programmabile.Dato che devi replicare elementi su tutti questi database, potresti usarlo per creare un lavoro automatizzato per generare gli script di modifica o per verificare che i database siano tutti sincronizzati.Inoltre non è molto più costoso della versione standard.

Answer 5

Oltre a utilizzare gli strumenti di confronto dei database, con 18 database dovresti avere un DBA, quindi applica una politica secondo cui solo il DBA può modificare le tabelle a livello di database limitando l'accesso a CREATE e ALTER solo al DBA.Sia sui database di test che su quelli live.Il database degli sviluppatori non dovrebbe averlo, ovviamente!Fai in modo che gli sviluppatori che hanno creato o modificato gli schemi, volenti o nolenti, passino attraverso il DBA.

Answer 6

Crea un singolo script DDL/SQL controllato dal codice sorgente per ogni versione e soltanto usarlo per aggiornare i database.Gli strumenti diff possono essere utili, ma soprattutto per verificare di non aver commesso un errore e per uscire dai guai quando le politiche falliscono.Combina gli script DDL, SQL e le procedure memorizzate in un unico script in modo che non sia facile "dimenticare" di eseguire uno degli script.

Answer 7

Abbiamo uno strumento chiamato DB Schema Difftective in grado di confrontare e sincronizzare gli schemi di database.Con il nostro altro strumento, DB MultiRun, puoi distribuire facilmente gli script generati (sincronizzazione) su più server DB (basati su progetti).

Answer 8

Mi rendo conto che questo post è vecchio, ma TurnKey ha ragione.Se sei uno sviluppatore che lavora in un ambiente di squadra, il modo migliore per mantenere uno schema di database per un'applicazione di grandi dimensioni è aggiornare uno schema principale in qualunque fonte sicura utilizzi.Scrivi semplicemente la tua lezione di Scripting e il tuo database sarà perfetto ogni volta.