Devo installare l’ultima Cumulative Update (CU) di SQL Server ? Un nuovo servizio informativo dal gruppo “Italian Premier Center for SQL Server” solo per i clienti italiani…

L’argomento è delicato in quanto il lecito desiderio di ogni DBA di evitare certi problemi a priori, si scontra con quelle che sono le “best practices” Microsoft in termini di installazione degli aggiornamenti per SQL Server (e non solo), in particolare per le “Cumulative Update” (CU).

Il meccanismo delle “Cumulative Update” (CU), in uso da alcuni anni da SQL Server 2005 in poi (e su altri prodotti Microsoft) ha dato ottimi risultati in termini di modularità dei rilasci (più hotfix in bundle), regolarità degli aggiornamenti (periodicità bimestrale) e qualità dei test svolti da Microsoft (regression test). E’ bene sottolineare che una “Cumulative Update” (CU) non è equivalente ad una “Service Pack” (SP) ma ci va molto vicino, inoltre permette di ridurre anche l’impatto delle modifiche da testare, dato che si tratta di un numero decisamente inferiori di modifiche al codice sorgente.

Dopo questa doverosa premessa, ecco la domanda che spesso mi viene rivolta dai Clienti: “Devo installare l’ultima CU rilasciata per SQL Server ? ”.

Fatemi prima rispondere come “engineer” Microsoft, mostrandoVi un tipico estratto da uno degli articoli relativi al rilascio delle varie (CU), nello specifico la CU4 per SQL Server 2008 SP2:

A supported cumulative update package is now available from Microsoft. However, it is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems . This cumulative update package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 service pack that contains the hotfixes in this cumulative update package.

Sembra abbastanza chiaro, Microsoft raccomanda di applicare la specifica (CU) solo se contiene la fix relativa ad un problema specifico che Voi avete riscontrato, altrimenti è meglio aspettare la prossima (SP).

C’è un primo problema non trascurabile nel seguire quella che è una policy assolutamente basata sul buon senso, e che condivido in pieno, cerco di illustrarvelo citando uno dei problemi “fissati” nella medesima CU4 per SQL Server 2008 SP2:

FIX: Database corruption if data compression enabled on a partitioned table in SQL Server 2008 http://support.microsoft.com/kb/2548593/en-us

Impressionante, vero ?

Immaginate di ricadere nella situazione specifica: Vi ritrovate con un database corrotto e sebbene Voi abbiate sicuramente una robusta e collaudata politica di backup (vero ? :-)), comunque il Vostro ambiente di produzione avrà un non trascurabile impatto dovuto alle necessarie operazioni di troubleshooting per capire cosa è successo e alle seguenti ed inevitabili operazioni di restore.  

Forse sarebbe meglio evitare, Voi cosa dite ?

 

Altro problema che potreste avere seguendo alla lettera la suddetta policy negli aggiornamenti, ecco un altro bug/articolo di esempio:

 FIX:A query that has a CONTAINS predicate in a WHERE clause takes a long time to compile in SQL Server 2008 or SQL Server 2008 R2 http://support.microsoft.com/kb/2491510/en-us

Già, I problemi di performance: talvolta I DBA non se ne accorgono subito, magari la dotazione hardware dei server è tale da mitigare/nascondere tali problemi, ma non sarebbe meglio evitare a priori ?

In base a quanto detto finora in questo post, appare chiaro (spero !) che comunque la policy di Microsoft, nello specifico per SQL Server per quanto riguarda l’applicazione delle (CU) rimane assolutamente valida, io ci aggiungerei una piccola postilla:

 

Il DBA dovrebbe periodicamente controllare le CU rilasciate e verificarne la lista dei problemi fissati, quindi valutarne l’impatto, qualora esista, sul proprio ambiente di produzione, infine considerare il rischio inerente alla mancata applicazione del suddetto aggiornamento.

Come spesso accade, quello che crea problemi ai DBA è la mancanza di tempo, rivedere tutte le CU periodicamente non è proprio un’attività trascurabile, in ogni modo se volete farlo ecco due utilissimi articoli per tenere traccia delle ultime CU disponibili per SQL Server 2008 e SQL Server 2008 R2:

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released http://support.microsoft.com/kb/2402659/en-us

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released http://support.microsoft.com/kb/981356/en-us

IMPORTANTE: Attenzione che ogni (CU) è specifica per una certa (SP), i suddetti articoli quindi cambieranno al rilascio di una nuova (SP).

 

Chiedo scusa agli utilizzatori di SQL Server 2005 ma oramai il prodotto è entrato in “Extended Support” e non ha quindi più molto senso seguirne le relative CU che a breve termineranno.

 

Per finire, ecco cosa il nostro gruppo vorrebbe fare per Voi: mettere in evidenza, quindi pubblicare periodicamente su questo blog, le hotfix contenute nelle (CU), che da ora in poi verranno rilasciate da Microsoft per SQL Server 2008 e SQL Server 2008 R2, e che rivestono particolare importanza per la stabilità e le performance di SQL Server.

E’ un impegno non trascurabile, ma credo che sia un servizio utile per i Clienti che ci onorerano della loro attenzione, devo però includere due importanti “disclaimer”:

1) La lista delle hotfixes che verranno segnalate nel presente blog non ha la pretesa di essere esaustiva: verranno scelte solo quelle di grande e generale impatto. Per una lista completa delle hotfixes contenute in ogni CU rilasciata è necessario fare riferimento ai seguenti articoli:

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released http://support.microsoft.com/kb/2402659/en-us

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released http://support.microsoft.com/kb/981356/en-us

2) Le informazioni contenute non costituiscono alcuna modifica alle policy ufficiali Microsoft, e sono da considerarsi solo un mezzo informativo a disposizione dei DBA;

3) Le segnalazioni non costituiscono alcuna garanzia di compatibilità e/o funzionalità per gli aggiornamenti riportati, le canoniche policy di “change management” proprie di ogni Cliente devono essere comunque ottemperate;

Spero che questa iniziativa incontri il Vostro favore, ogni commento o critica sarà bene accetto.

Buon lavoro ed appuntamento al prossimo post !

 

- Igor Pagliai -