Aggiornamenti cumulativi di MS SQL Server - Best practice

Sto cercando di farmi un'idea delle migliori pratiche consigliate per gli aggiornamenti cumulativi di SQL Server .

Attualmente, abbiamo l'idea di "non fare nulla a meno che un problema risolto dalla CU sia quello che sperimentiamo". Funziona con un approccio "se non è rotto, non aggiustarlo", ma mi chiedo se sia davvero una buona idea dato che molte CU hanno miglioramenti delle prestazioni. Stiamo forse cercando di aggiungere la CU alle patch applicate durante i nostri cicli di manutenzione periodica un mese o due dopo il rilascio della CU.

Cosa fanno gli altri e perché?

Come aggiornamento alla domanda che riguarda le risposte di seguito, il 24 marzo 2016 il team di SQL Server di Microsoft ha annunciato che stava aggiornando il proprio modello di manutenzione . Microsoft consiglia a tutti gli utenti di installare tutte le CU rilasciate dopo gennaio 2016:

A partire dalle versioni CU di gennaio, questi messaggi di avvertenza sono stati aggiornati, ora raccomandiamo l'installazione continua e proattiva delle CU quando saranno disponibili. È necessario pianificare l'installazione di una CU con lo stesso livello di sicurezza previsto per l'installazione degli SP (Service Pack) rilasciati. Questo perché le CU sono certificate e testate al livello di SP. Inoltre, i dati CSS Microsoft indicano che una percentuale significativa di problemi dei clienti viene spesso risolta in precedenza in una CU rilasciata, ma non applicata in modo proattivo. Inoltre, le CU contengono un valore aggiunto oltre agli hotfix. Questi possono anche contenere aggiornamenti di supportobilità, registrazione e affidabilità che migliorano l'esperienza complessiva.

Oltre agli aggiornamenti di messaggistica e guida, abbiamo apportato aggiornamenti al modello di acquisizione CU.

Modifiche all'acquisizione:

• Le CU, naturalmente, sono state tradizionalmente rese disponibili sul server "Hotfix" (accompagnato dal "linguaggio cautelativo" associato a un "QFE" o "Hotfix"). L'incongruenza qui è che le CU non sono più semplici hotfix rapidi. Gli aggiornamenti racchiusi sono testati bene sia a livello individuale che a livello di integrazione completa del sistema oggi.
• Pertanto, ora stiamo posizionando l'ultima baseline di CU per mainstream supportata (2012 SP2 / SP3 e 2014 RTM / SP1 oggi) su microsoft.com/downloads, proprio come avviene oggi per i Service Pack
• Inoltre, rilasceremo e manterremo presto tutte le CU nel catalogo di Windows Update per facilitare l'acquisizione e la distribuzione
• Solo le correzioni temporanee "su richiesta" della CU verranno posizionate sul server di aggiornamento rapido andando avanti
• Per ridurre l'attrito, il download di CU da microsoft.com/downloads non richiede la fornitura / ricezione di e-mail e URL
• Stiamo anche valutando l'offerta dell'ultima CU come aggiornamento facoltativo su Microsoft Update, proprio come i Service Pack di oggi

Sono un grande sostenitore di tenersi aggiornato con l'aggiornamento cumulativo più recente, ma solo se il ciclo di test / QA può garantire test di regressione completi e adeguati contro di esso. Glenn Berry di SQLskills è anche un sostenitore di questo approccio .

La raccomandazione di Microsoft è quella di applicare solo CU che risolvono problemi che ti riguardano, anche se recentemente hanno allentato tale posizione . Il problema è che potresti essere interessato da uno o più di questi problemi e non saperlo, oppure potresti essere interessato domani anche se non ti ha ancora colpito. Stai andando a provare e provare a riprodurre il problema dietro ogni singola correzione in ogni singola CU per il tuo ramo? Lo farai continuamente per assicurarti di non essere ancora interessato?

Sarò abbastanza onesto: non ho mai avuto problemi ad applicare una CU ai miei casi. E in effetti il ​​loro processo di rilascio della CU è stato molto più affidabile del ciclo di rilascio del service pack e in molti casi (incluso l' ultimo con SQL Server 2012 Service Pack 2 ), non si desidera applicare il service pack fino al primo La CU per quella filiale è stata comunque rilasciata. In questo caso esiste un aggiornamento rapido temporaneo per risolvere il problema che non è stato risolto in tempo per rendere il codice del Service Pack, ma ciò non è sempre vero.

Ci tenevamo al passo con le CU. Circa 1 mese dopo il rilascio li applicheremmo se riscontrassimo un problema corretto o meno.

Tuttavia, dopo esserci imbattuti in un grosso problema, abbiamo interrotto questa pratica. Nel nostro caso un service pack che avevamo installato ha risolto un problema con l'indicizzazione full-text che stavamo riscontrando. Pochi mesi dopo, una delle unità di controllo ha ripristinato quella correzione specifica. Ciò ha causato per noi ogni sorta di problemi che hanno richiesto parecchie ricerche per capire cosa è successo. Abbiamo finito per codificare un lavoro che è stato poi rovinato quando una nuova CU ha rotto qualcos'altro ... Risultato netto: il server è stato installato da zero fino a un determinato livello SP / CU e bloccato.

Le prestazioni delle nostre applicazioni sono tali che non ci occupiamo di eventuali nuovi miglioramenti delle prestazioni SQL che potrebbero emergere, quindi non è un problema. Inoltre, i report e altre query stanno costantemente recuperando risultati validi, quindi non sono necessarie nuove modifiche. Ciò significa che deve essere un problema di sicurezza prima di prendere in considerazione l'applicazione di una CU in questo momento.

Sono completamente d'accordo con Aaron: fallo solo se il tuo ciclo di test / QA può testarlo correttamente Altrimenti direi di stare attento a meno che non risolva un problema che stai effettivamente affrontando. E anche allora, prova ogni piccolo aspetto di esso con dati reali per assicurarti che non abbiano rotto qualcosa da cui potresti dipendere.