SQL Server 2008 Backup automatico

Question

Vogliamo avere i nostri server di test database aggiornati dai nostri database server di produzione su base giornaliera per assicurare che stiamo sviluppando sui dati più recenti. Noi, però, vogliamo assicurare che ogni fn, sp, ecc che stiamo attualmente lavorando nell'ambiente di sviluppo non viene sovrascritto dal processo di backup. Quello che stavamo pensando di fare stava avendo un programma PreBackup che salva gli oggetti selezionati dai nostri sviluppatori e un programma PostBackup per aggiungere di nuovo dopo il processo di backup è completo.

Mi chiedevo che cosa gli altri sviluppatori hanno fatto in una situazione come questa. Esiste uno strumento esistente per fare questo per noi che può essere eseguito automaticamente su base giornaliera e ci permettono di impostare gli oggetti non sovrascrivere (senza richiedere l'attenzione di un amministratore di sistema per eseguire tutti i giorni).

Answer 1

Tutti gli oggetti nei nostri database sono mantenute nel codice - tabelle, vista, trigger, stored procedure, tutto - se ci aspettiamo di trovare nel database allora dovrebbe essere in DDL nel codice che siamo in grado di eseguire. modifiche dello schema effettivi sono di versione -. quindi non c'è una tabella nel database che dice che questa è la versione dello schema "n", e se questa non è la versione attuale (in base al codice di aggiornamento) poi apportare le modifiche necessarie

Cerchiamo di separare trigger e viste - non lo fanno, anche se probabilmente dovrebbe, fare molto con SP e FN - con goccia e ricreare il codice che è valida per la versione dello schema corrente. Di conseguenza dovrebbe essere "sicuro" per eliminare e ricreare tutto ciò che non è una tabella, anche se ci saranno problemi di sequenza sia con la goccia e il creare se ci sono le dipendenze tra gli oggetti. La cosa bella di questo genere è che possiamo tranquillamente portare uno schema da nuova alla corrente e avere fiducia che qualsiasi istanza dello schema è coerente.

L'espansione al vostro caso, se avete la possibilità di eseguire il codice aggiornamento dello schema compreso il codice per ricreare tutti gli oggetti di database in base alle attuali definizioni allora il vostro problema dovrebbe sostanzialmente andare via ... backup, ripristino, eseguire lo schema maint logica. Ciò avrebbe l'ulteriore vantaggio che è possibile introdurre modifiche dello schema (tabella) nei server dev e ancora mantenere la stessa logica di aggiornamento.

So che questa non è una soluzione del tutto generico. E la sua pena di notare che probabilmente funziona meglio con il database per sviluppatore (Sono un vecchio programmatore di stile, quindi non vedo tutti i problemi quello di avere soluzioni in codice (- :) ma come approccio generale penso che abbia notevole pregio perché dà un meccanismo coerente per affrontare una serie di problemi.