Ci sono state alcune controversie in corso nella comunità di SQL Server circa l'opportunità di installare Service Pack (SP) e Aggiornamenti cumulativi (CU) per SQL Server. Esistono diverse posizioni di base che le organizzazioni in genere tendono ad assumere su questo argomento, come elencato di seguito:
- L'organizzazione installa regolarmente Service Pack e Aggiornamenti cumulativi
- L'organizzazione installa i Service Pack, ma non installa gli aggiornamenti cumulativi
- L'organizzazione non installa Service Pack o Aggiornamenti cumulativi
Il primo caso è un'organizzazione che cercherà di rimanere ragionevolmente aggiornata con i Service Pack di SQL Server e gli aggiornamenti cumulativi di SQL Server utilizzando una procedura di test e implementazione completa. Questa è la migliore politica secondo me. La mia posizione è che la tua organizzazione sia molto più servita rimanendo aggiornata sia con i Service Pack che con gli aggiornamenti cumulativi (a patto che tu disponga delle procedure di test e implementazione e dell'infrastruttura richiesta per supportare tale politica).
Il secondo caso è un'organizzazione che (forse dopo un certo ritardo) installerà i Service Pack di SQL Server, ma non installerà gli aggiornamenti cumulativi di SQL Server per nessun motivo. Questo non è buono come il primo caso, ma è molto meglio del terzo caso.
Nel terzo caso, alcune organizzazioni non installano mai Service Pack di SQL Server o Aggiornamenti cumulativi di SQL Server, per nessun motivo. In alcuni casi, rimangono effettivamente nella build RTM (release to manufacturing) originale della versione principale di SQL Server in esecuzione, per tutta la vita dell'istanza. Questa è la politica meno desiderabile, per una serie di motivi.
Microsoft ha un criterio per il ritiro di rami di codice (il ramo RTM o un ramo del Service Pack successivo) per una particolare versione di SQL Server quando sono due rami precedenti. Ad esempio, quando è stato rilasciato SQL Server 2008 R2 Service Pack 2, il ramo RTM originale (indipendentemente dal livello CU) è stato ritirato ed è diventato un "service pack non supportato". Ciò significa che non ci saranno più hotfix o aggiornamenti cumulativi per quel ramo e che riceverai solo un supporto limitato per la risoluzione dei problemi da Microsoft CSS durante una richiesta di supporto finché non installerai un service pack supportato sulla tua istanza.
Motivi per cui la manutenzione di SQL Server è posticipata
In alcuni casi, un'organizzazione potrebbe non essere a conoscenza del modo in cui SQL Server viene normalmente servito con una combinazione di Service Pack, aggiornamenti cumulativi e hotfix. Molte organizzazioni dispongono di criteri rigidi e dall'alto verso il basso sulla modalità di manutenzione e assistenza di prodotti come SQL Server, che precludono l'installazione regolare di SP e/o CU da parte degli amministratori di database. Potrebbero anche essere limitati dalla manutenzione delle proprie istanze di SQL Server dal fatto che utilizzano database di terze parti supportati solo dal fornitore con determinate versioni specificate dal fornitore e livelli di Service Pack di SQL Server.
Molte organizzazioni hanno anche il comprensibile timore di "rompere" un'istanza di SQL Server o un'applicazione che dipende da tale istanza. Potrebbero inoltre non avere il tempo e le risorse per eseguire un livello appropriato di test dell'applicazione e del sistema dopo l'installazione di una build aggiornata di SQL Server su un'istanza in un ambiente di test. In alcuni casi, potrebbero non avere un ambiente di test dedicato (che è un problema importante separato).
Alcune organizzazioni potrebbero non disporre di una soluzione di alta disponibilità funzionante (come il tradizionale clustering di failover, il mirroring del database o i gruppi di disponibilità) nel proprio ambiente di produzione, quindi sono molto più riluttanti a eseguire qualsiasi tipo di manutenzione che potrebbe causare un riavvio del server di database e causare un'interruzione relativamente lunga. Potrebbero effettivamente disporre di una soluzione ad alta disponibilità, ma raramente la testano con un failover di produzione e potrebbero avere meno fiducia nel suo funzionamento e affidabilità.
Motivi per mantenere regolarmente SQL Server
Dopo aver elencato alcuni dei motivi comuni per cui le organizzazioni possono scegliere di non eseguire regolarmente il servizio SQL Server, è il momento di affrontare alcuni di questi argomenti. Innanzitutto, l'ignoranza su come SQL Server è normalmente servito da Microsoft non è più una scusa valida. Microsoft ha un blog sui servizi di rilascio di SQL, in cui annunciano sia Service Pack che aggiornamenti cumulativi per SQL Server. Matthias Bernt ha spiegato la strategia di manutenzione generale per SQL Server nel suo post:Un approccio modificato ai Service Pack, con maggiori dettagli sull'approccio del modello di manutenzione incrementale di SQL Server disponibile in questo articolo della Knowledge Base di Microsoft.
La versione ridotta del modello di manutenzione prevede che i singoli problemi di SQL Server vengano corretti con aggiornamenti rapidi. È necessario contattare Microsoft CSS e aprire una richiesta di supporto per ottenere l'accesso a un singolo hotfix (a meno che non si tratti di un hotfix relativo alla sicurezza, che viene eliminato da Microsoft Update). A seconda del livello di supporto a pagamento con Microsoft, questo può essere un processo relativamente noioso e dispendioso in termini di tempo. Esiste anche il problema che è molto improbabile che la maggior parte dei clienti di SQL Server sia a conoscenza degli aggiornamenti rapidi esistenti che non sono stati rilasciati come parte di un aggiornamento cumulativo di SQL Server. Ciò significa che è improbabile che la maggior parte dei clienti ottenga e distribuisca i singoli hotfix su base regolare.
Gli aggiornamenti cumulativi sono rollup di un numero di aggiornamenti rapidi (in genere da circa 10 a 50 aggiornamenti rapidi) che vengono rilasciati ogni otto settimane. Questi aggiornamenti cumulativi sono in realtà cumulativi (come suggerisce il nome), quindi otterrai tutti gli aggiornamenti rapidi rilasciati in precedenza per la tua versione e ramo (RTM, SP1, SP2 e così via) del codice quando installi un aggiornamento cumulativo. Ciò significa che l'affermazione comune sulle organizzazioni che "applicano aggiornamenti cumulativi solo per correggere problemi specifici che stanno riscontrando" in realtà non è particolarmente valida nella vita reale.
Ad esempio, se stavi eseguendo la build RTM di SQL Server 2012 Service Pack 1 (11.0.3000) e hai deciso di installare SQL Server 2012 Service Pack 1 aggiornamento cumulativo 3 (11.0.3349) perché includeva un hotfix per uno specifico problema che stavi effettivamente riscontrando, otterresti effettivamente tutti gli hotfix per SP1 CU1, SP1 CU2 e SP1 CU3, che ammonterebbero a oltre 100 hotfix.
Come afferma Microsoft sugli aggiornamenti cumulativi:"Poiché le build sono cumulative, ogni nuova versione di correzione contiene tutti gli hotfix e tutte le correzioni di sicurezza incluse con la precedente versione di correzione di SQL Server 2012 SP 1. Ti consigliamo di prendere in considerazione l'applicazione della versione di correzione più recente che contiene questo hotfix. Fondamentalmente ciò significa che se si individua un problema particolare e rilevante che è stato risolto in una CU precedente, è necessario procedere e distribuire l'ultima CU pertinente sul sistema (che includerà anche quell'hotfix).
Un argomento che sento spesso sul motivo per cui le organizzazioni non distribuiscono gli aggiornamenti cumulativi è che "non sono completamente testati di regressione come lo sono i Service Pack, quindi non li distribuiamo". C'è una certa validità in questo punto di vista, ma c'è anche un malinteso comune sul fatto che gli aggiornamenti cumulativi siano semplicemente unit test, senza alcun test di regressione. Non è così.
La documentazione Microsoft sugli aggiornamenti cumulativi indica che poiché "applicano test di regressione incrementali durante tutto il ciclo di sviluppo seguiti da 2 settimane di test mirati entro la finestra di rilascio di 8 settimane, i processi di garanzia della qualità associati alle CU superano quelli dei singoli hotfix". Ciò significa che stai effettivamente correndo meno rischi implementando una CU che è stata testata in modo incrementale e ha avuto anche due settimane di test mirati rispetto a quando distribuisci un singolo hotfix che è stato solo unit test.
Negli ultimi sei o sette anni, ho distribuito personalmente molti, moltissimi aggiornamenti cumulativi e Service Pack su un gran numero di sistemi che eseguono SQL Server 2005 tramite SQL Server 2012 e non ho ancora riscontrato problemi importanti. Inoltre, non ho sentito di problemi diffusi che fanno questo tipo di lavoro segnalati nei blog, su Twitter, ecc. Potrebbe essere che io (e tutti quelli che conosco) siamo stati solo fortunati, o forse Aggiornamenti cumulativi e Service Pack non sono del tutto rischioso come credono alcune persone (a patto che vengano testati e implementati correttamente).
L'importanza di un piano di test e attuazione
A meno che tu non preveda mai di eseguire alcun tipo di manutenzione del server o aggiornamento delle applicazioni per tutta la vita del tuo sistema (che sembra una proposta improbabile), devi davvero sviluppare una sorta di procedura di test e implementazione e un piano che dovresti seguire come parte di apportare qualsiasi tipo di modifica al server.
Questo piano può iniziare in modo relativamente semplice, ma diventerà più complesso e completo man mano che acquisirai maggiore esperienza con la manutenzione regolare delle istanze di SQL Server e applicherai le lezioni apprese con ogni distribuzione. Idealmente, dovresti seguire questo piano ogni volta che apporti una modifica al sistema, ma ciò potrebbe non essere possibile in ogni singolo caso.
Ecco alcuni passaggi iniziali e test che dovrebbero essere inclusi in questo tipo di piano.
- Installa la CU su una macchina virtuale di prova
- La CU si installa senza problemi o errori?
- L'installazione della CU richiede un riavvio del sistema?
- Tutti i servizi SQL Server rilevanti vengono riavviati dopo l'installazione?
- Sembra che SQL Server funzioni correttamente dopo l'installazione?
- Installa la CU su diversi sistemi di sviluppo
- La CU si installa senza problemi o errori?
- Sembra che SQL Server funzioni correttamente durante il normale utilizzo quotidiano?
- Le tue applicazioni sembrano funzionare correttamente durante gli unit test?
- Installa la CU in un QA condiviso o in un ambiente di integrazione
- Hai seguito un piano di implementazione e una checklist specifici per l'installazione?
- Tutte le applicazioni che utilizzano SQL Server superano il test del fumo?
- Tutte le applicazioni superano i test automatici che hai a disposizione?
- Tutte le applicazioni superano test funzionali manuali più dettagliati?
- Installa la CU nel tuo ambiente di produzione
- Utilizza una strategia di aggiornamento continuo, ove possibile
- Utilizzare un elenco di controllo dettagliato e dettagliato durante l'implementazione
- Aggiorna la tua lista di controllo con gli oggetti persi e le lezioni apprese
Conclusione
Quello che spero di ottenere qui è convincere più professionisti del database a iniziare a muoversi verso una mentalità in cui desiderano effettivamente mantenere regolarmente le loro istanze di SQL Server, piuttosto che essere titubanti o aver paura di farlo. Ciò può comportare una notevole quantità di lavoro extra all'inizio, poiché potresti dover convincere altre persone nella tua organizzazione a partecipare ai tuoi piani. Potrebbe essere necessario spingere altre parti dell'organizzazione a sviluppare piani di test migliori e sarà necessario creare una checklist di implementazione. Dovrai anche ottenere dall'azienda l'autorizzazione per le finestre di manutenzione (che dovrebbero essere relativamente brevi con gli aggiornamenti in sequenza), in modo da poter effettivamente ottenere aggiornamenti distribuiti sui tuoi sistemi di produzione su base regolare.
In cambio di questo lavoro extra, avrai un sistema meglio mantenuto che ha meno probabilità di incorrere in problemi in futuro. Sarai in una configurazione completamente supportata da Microsoft e avrai più fiducia nelle tue tecnologie ad alta disponibilità, poiché le eserciterai effettivamente su base regolare. Acquisirai anche una preziosa esperienza durante la pianificazione e l'implementazione di tutto ciò che migliorerà le tue capacità di risoluzione dei problemi in futuro.
