Il modo migliore per creare uno script di rollback di SQL Server?

Question

Sto lavorando ad alcune modifiche dello schema di un database esistente.

Ho eseguito il backup del database per ottenere una copia di sviluppo e ho apportato le mie modifiche. Creerò uno script a rotolo singolo per migrare le modifiche sulla macchina di produzione in un'unica transazione.

Esiste una procedura consigliata per la creazione di uno script di rollback in cui si presenta un problema di distribuzione? Prima ho scritto a mano usando il seguente schema:

• Elimina nuovi vincoli e indici
• Modifica le tabelle per rimuovere nuove colonne
• Elimina tabelle aggiunte
• Commetti transazione

Esiste un approccio migliore?

Answer 1

È praticamente tutto, non credo che ci sia molto da aggiungere, a parte il tuo approccio. Questo è il modo in cui lo facciamo nella nostra azienda, noi sviluppatori siamo responsabili della creazione dello script e dello script di rollback e siamo responsabili di lasciare il DB nello stesso stato in cui era prima dell'applicazione delle modifiche iniziali. Quindi i DBA lo eseguono in produzione, in caso di problemi eseguiranno lo script di rollback e tutto tornerà alla normalità. Tieni a mente le dipendenze e l'ordine in cui modifichi i tuoi oggetti e quindi crei lo script di rollback al contrario.

Answer 2

Ti manca il quinto passaggio

• Elimina nuovi vincoli e indici
• Modifica le tabelle per rimuovere nuove colonne
• Elimina tabelle aggiunte
• Commetti transazione
• Prova l'inferno fuori dallo script prima di eseguirlo in produzione

Un approccio più efficiente è quello di registrare le modifiche mentre si verificano come RoR < a href = "http://wiki.rubyonrails.org/rails/pages/UsingMigrations" rel = "nofollow noreferrer"> migrations do . Per ogni modifica del DB, crei uno script che applicherà la modifica e lo ripristinerà (a tua scelta, ovviamente). Puoi quindi avere quegli script sotto il controllo della versione proprio come il tuo codice.

Inoltre, se si mantiene un numero di versione nel database, è possibile automatizzarlo un po 'di più, identificando ogni script con un numero di versione e facendolo aumentare o diminuire il numero di versione nel database in base all'azione eseguita.

Answer 3

Se si tratta di un database relativamente piccolo, eseguire un backup prima di applicare l'aggiornamento. Se tutto va in tilt fai un ripristino.

Una volta che diventano attivi e vengono inseriti nuovi dati, non è possibile ripristinarli comunque. Devi solo risolvere i problemi.

Answer 4

Se si utilizza uno strumento come SQL Compare di Redgate, è possibile eseguire il confronto tra i due database in entrambi i modi e utilizzare entrambi per creare gli script necessari. lo script dev to prod avrebbe le modifiche che stai apportando e lo script prd to dev tornerebbe allo stato originale del database di produzione. Questo ti assicura di non dimenticare nulla in nessuno dei due script.

Answer 5

Con SQL Server 2005 o versioni successive è anche possibile creare uno snapshot del database, che consente di tornare a quello stato in qualsiasi momento. Vedi questa pagina per maggiori informazioni:

http://msdn.microsoft.com/en-us/library /ms175158.aspx