COMPATIBILITY_LEVEL : Votre avis

Bonjour,

Voilà on prévois une migration de 2008R2 à 2016.
Sur le principe il n'y a rien a signaler, mais une des bases est critique et je souhaiterais la garder en 2008R2 (dans un premier temps en tout cas)

Du coup je me dis super, je la migre en 2016 et je set le COMPATIBILITY_LEVEL sur 100 et l'existant n'y verra que du feux.

Mais en cherchant j'ai trouvé cet article deprecated database engine features in sql server 2016
Qui dit que ça ne fonctionne que pour les deux dernière versions. 2008R2, 2012, 2014, 2016, ça fait une de trop :(

Ensuite je clique sur le liens "for more information etc.." et je tombe sur ça alter database transact sql compatibility level
Qui dit que pour sql 2016 support le mode de compatibilité 100, 110, 120 et 130 :?

Ca semble contradictoire...
Du coup, elle est ou la vérité vrai de la vrai vie?

A+

Sans répondre à votre question j'ai plusieurs fois migré de grosses applications de 2008 (tout court) à 2016 sans soucis.

Citation:

---

Envoyé par iberserk

Sans répondre à votre question j'ai plusieurs fois migré de grosses applications de 2008 (tout court) à 2016 sans soucis.

---

Oui sur la plus part des db j'ai pas peur.
Mais une en particulier est un truc créer en 2005 (ou peut être 2000) avec des package SSIS très vieux.

Sur 2016, tu as la possibilité de mettre ta DB en compatibility level à 100, donc pour moi c'est bon. En tout cas, j'ai créé une DB vide, CL sur 2016, et je l'ai passée en 2008 sans problème.

Mais pourquoi tu ne fais pas un test pendant une fenêtre de maintenance si c'est possible? Tu prends un backup de ta DB, tu la mets sur 2016, tu changes ton application pour qu'elle pointe dessus et tu vois si c'est bon?

Ou je suppose que tu as un environnement de test?

Oui bien-sure

Mais un test complet me prendra bien deux ou trois jours, ce qui veux dire demande coordinations etc..

La rétro compatibilité est assurée depuis la version 2005 jusqu'à toute nouvelle version à ce jour (2016).
Pour les versions antérieures à 2005 la rétro compatibilité n'est assurée que pour un saut de 2 version majeure. Donc jusqu'à 2008R2 inclus.

Pour une base 2008 ou 2008R2 passer à 2016 ne présente aucun problème logique.

Sur le plan des performances il faut dans un premier temps et juste après le rattachement de la base, effectuer une mise à jours des statistiques d'optimisation en mode "FULLSCAN".

Enfin, depuis la version 2014 l'estimateur de cardinalité ayant été largement modifié, certaines requêtes peuvent devenir moins rapide car les index 2008 peuvent être inadapdaté à l'optimiseur 2014... Dans ce cas, il est possible :

• de laisser la base en mode de rétro compatibilité et éventuellement de forcer le nouvel estimateur pour certaines requêtes

ou inversement :

• de mettre la base en version 2016 et de forcer l'ancien estimateur pour certaines requêtes

Pour cela vous pouvez :

• soit ajouter la clause OPTION à vos requêtes
• soit utiliser un "plan guide"

Pour ce faire : traceflag 2312 et 9481 (voire 4199)


A +

Bonjour,

Au passage des bases de données de production de SQL Server 2008 vers SQL Server 2014 (qui embarque aussi le nouvel optimiseur que sous SQL Server 2016), j'ai eu de (trop) nombreux problèmes de performances.
Ceux-ci sont principalement dus à une modélisation qui n'est pas faite dans les règles de l'art, et à des défaut d'estimation de cardinalité en sortie de jointure par Hash.
Donc toutes les bases de production qui sont hébergées par une instance SQL Server 2014 sont en mode de compatibilité 110.
Pour certaines requêtes, nous avons forcé le nouvel optimiseur (OPTION (QUERYTRACEON 2312)).

@++ ;)

J'ai eu le meme souci en migrant des BDD de 2008 R2 a 2016, j'ai du activer le traceflag 9481 sur le moteur SQL, pour revenir a de bonnes performances de mon coté :mrgreen: