Risques liés à la mise à niveau vers SQL Server 2008 R2

Nous avons un certain nombre de serveurs SQL qui doivent être mis à niveau de la version 2005 à 2008 R2. Les travaux sont prévus avant le milieu de l'année, car Microsoft met fin à sa prise en charge.

Les serveurs SQL 2005 sont tous SP3 et SP4, fonctionnant sur Windows Server 2003 (dont la prise en charge est déjà terminée, mais nous avons une exception d'extension pour un an de plus), mais si nécessaire, nous pouvons également procéder à une mise à niveau du système d'exploitation du serveur.

Ces serveurs incluent la réplication (transactionnelle), l'envoi de journaux, les services de génération de rapports et un serveur d'intégration exécutant des packages SSIS.

Ma question ici n'est pas comment, je voudrais plutôt connaître les risques impliqués ou les pré-vérifications qui peuvent être faites avant de planifier cette mise à niveau?

En outre, une mise à niveau sur place sera-t-elle un meilleur plan que côte à côte pour cette migration / mise à niveau?

C'est une très grande question, alors décomposons-la un peu.

Que puis-je faire à l'avance?

Commencez par quelques lectures obligatoires .

• 2008 R2 rétrocompatibilité
• Compatibilité descendante 2008

Ces liens contiennent des liens vers des informations supplémentaires telles que

• Fonctionnalités SQL Server obsolètes
• Fonctionnalités SQL Server abandonnées
• Changements de rupture
• Modifications du comportement des fonctionnalités de SQL Server

Lisez chacun d'eux pour voir ce qui change le plus. Portez une attention particulière aux fonctionnalités que vous utilisez.

De plus, vous devez utiliser le Conseiller de mise à niveau . Il vérifie les composants installés et identifie ceux que vous devrez réparer avant ou après l'installation.

Beaucoup de pour et de contre ici des deux côtés.

En place

Avantages

• Beaucoup plus facile. Toutes vos configurations restent les mêmes par exemple. De plus, les chaînes de connexion de vos applications n'auront probablement pas besoin d'être modifiées.
• Moins cher. Aucun deuxième ensemble de matériel requis.

Les inconvénients

• Le retrait est difficile, voire impossible. Si quelque chose ne va pas, vous devrez passer et terminer car la sauvegarde implique la création d'un tout nouveau serveur et la réinstallation de SQL, puis la restauration des sauvegardes de vos tables.

Cote à cote

Fondamentalement, les avantages et les inconvénients sont à l'opposé de En place.

Avantages

• Plus sûr - En cas de problème, vous tuez la nouvelle version et continuez avec l'ancienne. Vous pourrez ensuite réessayer plus tard.

Les inconvénients

• C'est plus cher car vous devez créer un nouvel ensemble d'instances probablement sur de nouveaux serveurs.
• C'est plus difficile car vous devez changer les chaînes de connexion, assurez-vous que toutes vos configurations sont identiques, etc.

Vous pouvez désormais atténuer les coûts liés à la création côte à côte en créant une nouvelle instance sur le même serveur, en déplaçant tout sur celui-ci, puis en désinstallant l'ancienne instance. Cela fonctionne et selon votre situation peut être la meilleure idée.

Honnêtement, le passage de 2005 à 2008 R2 n'est pas si mal. Ce n'est rien comparé à 2000 - 2005 ou 2008 R2 - 2012 (principalement des changements SSIS). Je dirais qu'avec une planification et une lecture minutieuses, vous devriez être en bonne forme.

Donc, ma question ici n'est pas comment, plutôt aimerais-je savoir le risque encouru ou les pré-vérifications qui peuvent être faites avant de planifier cette mise à niveau?

Vous devez exécuter le conseiller de mise à niveau et résoudre les problèmes signalés par celui-ci avant la migration.

Reportez-vous à ma réponse pour une liste complète des étapes avant et après la mise à niveau .

Serveur SQL qui doit être mis à niveau de la version 2005 à 2008R2

Vous choisissez un chemin où vous serez de retour à la case 1 (puisque dans 3 ans, vous devrez à nouveau mettre à niveau). Voir le tableau ci-dessous

la mise à niveau Inplace sera-t-elle un meilleur plan ou côte à côte pour cette migration / mise à niveau?

Sur la base de mon expérience, je vous suggère de faire une migration côte à côte puisque vous obtenez une nouvelle version du système d'exploitation et de SQL. Il s'agit d'une approche beaucoup plus propre, car vous aurez toujours vos anciens serveurs, juste au cas où vous souhaiteriez effectuer une restauration. Reportez-vous à: Les mises à niveau sur place de SQL Server sont-elles aussi mal conseillées qu'auparavant? . Ne vous méprenez pas lorsque je suggère une migration côte à côte, c'est juste un côté plus sûr en matière de restauration.

Si vous allez faire l'effort de migrer, vous devriez aller jusqu'en 2014 même si vous l'exécutez en mode de compatibilité 10.0.

Vous allez quand même payer la licence. L'effort de test de régression et la courbe d'apprentissage développeur / DBA seront également importants dans les deux cas. Si vous vous arrêtez maintenant à 2008R2, il vous suffira de répéter l'exercice dans quelques années. 2008R2 a déjà vu son dernier Service Pack et dans quelques mois (semaines) il y aura 3 versions complètes derrière la version actuelle.

Je recommande que mon organisation passe directement de 2008R2 à 2016 pour les mêmes raisons. Je m'attends à ce que nous commencions un effort de test dès que 2016 atteindra RTM.

BTW, je conviens qu'une mise à niveau côte à côte est préférée. La dernière fois que j'ai fait cet exercice, nous avons exécuté la version "Pre-Production" dans un environnement Dev pendant environ un mois.