Rischi connessi all'aggiornamento a SQL Server 2008 R2

Abbiamo parecchi server SQL che devono essere aggiornati dalla versione 2005 a 2008 R2. Il lavoro è pianificato prima della metà dell'anno poiché Microsoft sta terminando il suo supporto per lo stesso.

I server SQL 2005 sono tutti SP3 e SP4, in esecuzione su Windows Server 2003 (il cui supporto è già terminato, ma abbiamo un'eccezione di estensione per un altro anno), ma dove richiesto potremmo anche andare con un aggiornamento del sistema operativo del server.

Questi server includono replica (transazionale), log shipping, servizi di reportistica e un server di integrazione che esegue pacchetti SSIS.

La mia domanda qui non è come, piuttosto vorrei conoscere i rischi connessi o eventuali controlli preliminari che possono essere fatti prima di pianificare questo aggiornamento?

Inoltre, un aggiornamento sul posto sarà un piano migliore rispetto al side-by-side per questa migrazione / aggiornamento?

Questa è una domanda davvero grande, quindi spezziamola un po '.

Cosa posso fare in anticipo?

Inizia con alcune letture richieste .

• 2008 R2 Compatibilità con le versioni precedenti
• Compatibilità con le versioni precedenti del 2008

Questi collegamenti hanno collegamenti ad ulteriori informazioni come

• Funzionalità di SQL Server obsolete
• Funzionalità di SQL Server fuori produzione
• Ultime modifiche
• Modifiche al comportamento delle funzionalità di SQL Server

Leggi ognuno di essi per vedere quali cose importanti stanno cambiando. Presta particolare attenzione alle funzionalità che stai utilizzando.

Inoltre, è necessario utilizzare Upgrade Advisor . Verifica la presenza di componenti installati e identifica quelli che dovrai riparare prima o dopo l'installazione.

Molti pro e contro sono qui su entrambi i lati.

A posto

Professionisti

• Molto più facile. Tutte le tue configurazioni rimangono le stesse per esempio. Anche le stringhe di connessione per le tue applicazioni probabilmente non dovranno essere modificate.
• Più economico. Nessun secondo set di hardware richiesto.

Contro

• Il backout è difficile o impossibile. Se qualcosa va storto dovrai accenderlo e finirlo perché il backout implica la creazione di un server completamente nuovo e la reinstallazione di SQL, quindi il ripristino dei backup delle tabelle.

Side-by-side

Fondamentalmente i pro e contro sono l'opposto di In place.

Professionisti

• Più sicuro - Se qualcosa va storto, uccidi la nuova versione e prosegui con quella precedente. Quindi puoi riprovare più tardi.

Contro

• È più costoso perché devi creare un nuovo set di istanze probabilmente su nuovi server.
• È più difficile perché devi cambiare le stringhe di connessione, assicurarti che tutte le tue configurazioni siano uguali, ecc.

Ora puoi mitigare le spese affiancate creando una nuova istanza sullo stesso server, spostando tutto su di essa e disinstallando la vecchia istanza. Funziona e in base alla situazione potrebbe essere la migliore idea.

Onestamente il passaggio dal 2005 al 2008 R2 non è poi così male. Non è nulla rispetto al 2000-2005 o 2008 R2-2012 (principalmente modifiche SSIS). Direi che con un'attenta pianificazione e lettura dovresti essere in buona forma.

Quindi la mia domanda qui non è come, piuttosto vorresti conoscere il rischio coinvolto o eventuali controlli preliminari che possono essere fatti prima di pianificare questo aggiornamento?

È necessario eseguire il consulente per l'aggiornamento e risolvere i problemi segnalati prima di eseguire la migrazione.

Fare riferimento alla mia risposta per un ampio elenco di passaggi pre e post aggiornamento .

Server SQL che deve essere aggiornato dalla versione 2005 a 2008R2

Stai scegliendo il percorso in cui tornerai al punto 1 (dal momento che entro 3 anni dovrai aggiornare di nuovo). Vedi la tabella sotto

l'aggiornamento inplace sarà un piano migliore o fianco a fianco per questa migrazione / aggiornamento?

In base alla mia esperienza, ti suggerirei di eseguire una migrazione side-by-side poiché stai ottenendo un nuovo sistema operativo e una versione SQL. Questo è un approccio molto più pulito poiché i tuoi vecchi server saranno ancora in giro, nel caso in cui si desideri eseguire il failback. Fare riferimento a: Gli aggiornamenti sul posto di SQL Server sono sconsiderati come in passato? . Non fraintendetemi quando suggerisco una migrazione side-by-side, è solo un lato più sicuro quando si tratta di rollback.

IMO se hai intenzione di eseguire la migrazione, dovresti andare fino al 2014 anche se lo esegui in modalità di compatibilità 10.0.

Pagherai comunque la licenza. Anche lo sforzo di test di regressione e la curva di apprendimento sviluppatore / DBA saranno significativi in ​​entrambi i casi. Se ti fermi a 2008R2 ora dovrai ripetere nuovamente l'esercizio tra un paio d'anni. 2008R2 ha già visto il suo ultimo Service Pack e in pochi mesi (settimane) saranno 3 versioni complete dietro la versione corrente.

Raccomando la mia organizzazione dal 2008R2 direttamente al 2016 per gli stessi motivi. Mi aspetto che inizieremo uno sforzo di test non appena il 2016 raggiungerà RTM.

A proposito, sono d'accordo che è preferito un aggiornamento side-by-side. L'ultima volta che ho fatto questo esercizio abbiamo eseguito la versione "Pre-Production" in un ambiente Dev per circa un mese.