Modifiche allo schema di SQL Server 2014 in ambiente multiutente 24/7

SQL Server 2014 Enterprise è installato per eseguire un database che dovrebbe essere disponibile 24/7. Il nostro database è abbastanza grande (200 GB +). Inoltre abbiamo un sacco di servizi che arrivano al nostro database ogni minuto per leggere, aggiornare o inserire nuovi dati. Vogliamo fornire una funzionalità di riassegnazione "a caldo" per i nostri clienti e rendere trasparenti i nostri aggiornamenti giornalieri (.net e gli schemi). Abbiamo trovato una soluzione basata su cluster con bilanciamento del carico per aggiornare i file binari della nostra app, ma abbiamo ancora qualche equivoco sul processo di distribuzione degli aggiornamenti del database e quali sono le migliori pratiche per risolvere questo problema.

Per le modifiche allo schema, disattiva un server, applica le modifiche allo schema, ripristinalo e quindi applica le stesse modifiche alla seconda istanza. Può essere realizzato con gli strumenti di SQL Server ed è un approccio comune? Come sincronizzare i dati dopo il backup del server? O sto pensando completamente nella direzione sbagliata e ci sono soluzioni migliori?

Modifiche allo schema comuni: aggiungi / elimina colonna, aggiungi / elimina stored procedure

Di seguito richiederà un po 'più di pianificazione e test.

Concetto blu-verde:

L'essenza di Blue-Green Concept è quella di dividere la produzione in 2 ambienti e sono sempre identici (sincronizzazione dei dati) in cui

1. Blue (Current) avrà la versione corrente dello schema / build o del prodotto e sarà il tuo ambiente "LIVE".

2. Allo stesso tempo, Green sarà il tuo ambiente di gestione temporanea / test in cui aggiornerai il tuo schema / build o prodotto alla versione NEXT, eseguirai un test di regressione completo e riceverai l'approvazione dai tuoi utenti aziendali. Una volta felice, durante un periodo di interruzione, promuoverai il Green in modo che diventi il ​​tuo ambiente "LIVE" e declassi il Blue in modo che diventi una pre-produzione / messa in scena o test per la prossima versione.

In questo modo, si ha un tempo di inattività molto inferiore e il rischio di errori di distribuzione su un sistema live (che si trova nella finestra di manutenzione, poiché si sta eseguendo l'aggiornamento) sarà ridotto al minimo. Inoltre, seguendo l'approccio Blu-Verde, oscillerai tra la versione LIVE e PREVIOUS che andrà in scena per la prossima versione.

Ancora una volta, ciò richiederà più hardware / licenze, nonché pianificazione e test.

La maggior parte dei passaggi può essere automatizzata tramite DACPAC e PowerShell. Inoltre, se si installano più istanze su un server, assicurarsi di riequilibrare le impostazioni della memoria quando si passa da blu a verde. L'ambiente LIVE riceve più memoria rispetto all'ambiente passivo.

Nel mio ambiente attuale, abbiamo implementato il modello blu / verde per la distribuzione di codice Agile che ci consente di promuovere il codice ogni 2 settimane con un ampio periodo di tempo per i test e la firma commerciale. Inoltre, è un gioco da ragazzi tornare indietro nel caso qualcosa vada terribilmente storto. Abbiamo automatizzato la maggior parte delle cose di distribuzione usando Dacpacs e PowerShell.

(Fonte immagine)

Consultare anche l'articolo di Grant Fritchey sulla risoluzione dei problemi di ripristino e ripristino; Sfide e strategie

Se il database non viene replicato, quindi, aggiungere e rilasciare le colonne verrà eseguito molto velocemente. Perché aggiungi colonna è solo una posizione vuota creata da SQL. La colonna di rilascio cancellerà semplicemente il riferimento.

Altrimenti, se c'è qualche vincolo o indice su di esso, fai attenzione.

ADD/DELETEle procedure avranno effetto sull'esecuzione stessa. La raccomandazione è prima di qualsiasi modifica su di essa eseguire la ricompilazione

sp_recompile 'myproc'