Comprendre les niveaux de compatibilité dans SQL Server

Qu’est-ce que le niveau de compatibilité ?

Supposons que vous avez SQL Server 2012 installé sur l’un de vos nouveaux serveurs. Cette instance de SQL Server 2012 contient une ou plusieurs bases de données dont vous devez faire la maintenance de temps en temps. Mais ce n’est pas parce que SQL Server 2012 est en cours d’exécution sur ce serveur que cela ne signifie que toutes les bases de données dans cette instance sont toutes des bases SQL Server 2012.

Si vous aviez précédemment une vieille base de données SQL Server 2008 et que l’avez restaurée sur cette nouvelle instance SQL Server 2012, cela signifie-t-il qu’elle a été convertie en base SQL Server 2012 ? La réponse est non. Bien sûr, la base peut très bien tourner sur cette nouvelle instance, mais avez-vous réellement mis à jour quelque chose ? La réponse se trouve si le niveau de compatibilité a changé au cours du processus de restauration. Pour savoir si vous avez vraiment converti quoi que ce soit, vous devez regarder le niveau de compatibilité de la base elle-même. Un niveau de compatibilité est associé à chaque base de données. Il permet au comportement de la base de données d’être compatible avec la version spécifique de SQL Server sur laquelle la base est installée.

Pour voir le niveau de compatibilité de chaque base de données, faites un clic-droit sur la base de données dans SQL Server Management Studio et sélectionnez Propriétés, puis cliquez sur l’onglet Options. Voyez le champ surligné :

Dans le cas ci-dessus, je fais fonctionner une base SQL Server 2008, qui a un niveau de compatibilité égal à 100, sur une machine qui fait tourner une instance de SQL Server Express 2014 (dans la colonne de gauche, dans la section Connection, vous voyez mon instance appelée SQLEXPRESS2014).

Un autre moyen de voir les niveaux de compatibilité des bases de votre serveur est de faire une requête sur la colonne compatibility_level de la table sys.databases :

USE YourDatabaseName;
GO
SELECT compatibility_level
FROM sys.databases WHERE name = 'YourDatabaseName';
GO

La principale raison pour avoir des niveaux de compatibilité est de permettre la compatibilité descendante. Chaque niveau de compatibilité a son propre ensemble de fonctionnalités et vous devez programmer avec ces caractéristiques lors de l’élaboration d’une application qui utilise la base de données. Si vous voulez migrer votre base de données vers une nouvelle instance de SQL Server, mais en même temps avoir une compatibilité descendante, vous devez vous assurer que le niveau de compatibilité demeure le même. Mais attention, parfois, vous pouvez ne pas avoir le choix et le niveau doit être changé parce que la nouvelle instance de SQL Server |’exige.

Connaître votre instance

Pour comprendre les niveaux de compatibilité, vous devez d’abord comprendre ce qu’est une instance. Une instance SQL Server est liée à la version de SQL Server que vous avez installé sur votre serveur. Par exemple, si vous avez installé SQL Server 2008, vous disposez d’une instance de SQL Server 2008. Si vous avez installé SQL Server Express 2014, vous disposez d’une instance de SQL Server Express 2014. N’est-ce pas simple ? Pendant l’installation, vous avez la possibilité de nommer votre instance. Il est fortement recommandé de la nommer de telle façon que vous savez de quelle version de SQL il s’agit, surtout si vous avez l’intention d’avoir différentes versions sur la même machine. Je recommande d’inclure la version dans votre nom d’instance, par exemple SQLEXPRESS2008 ou SQL2012. Vous savez ainsi immédiatement quels niveaux de compatibilité elle supporte juste en regardant son nom.

Donc, quelles relations ?

Il y a un nombre limité de niveaux de compatibilité que chaque version de SQL Server peut supporter. Par exemple, les bases de données qui ont un niveau 80 de compatibilité ne peuvent être installées que sur des instances allant de SQL Server 2000 jusqu’à SQL Server 2008. Voici un résumé de ce que chaque instance peut prendre en charge :

Le tableau ci-dessus nous dit immédiatement, par exemple, que si vous avez une ancienne base SQL Server 2000 et que vous souhaitez la migrer vers SQL Server 2012, vous ne pouvez pas ! Le niveau de compatibilité minimum supporté par SQL Server 2012 est de 90, qui correspond à une base SQL Server de 2005. Vous obtiendrez une erreur ressemblant à :

The database was backed up on a server running version 8.00.0760. That version is incompatible with this server, which is running version 11.00.3128. Either restore the database on a server that supports the backup, or use a backup that is compatible with this server.

N’attendez pas trop longtemps pour migrer

Alors que faire dans un tel cas ? Certaines personnes enchaînent deux étapes : ils migrent d’abord la base de données SQL Server 2000 à, disons SQL Server 2005, puis migrent vers SQL Server 2012. Ceci est une bonne raison de ne pas attendre trop longtemps pour migrer une base de données SQL Server vers une nouvelle version. Tôt ou tard, votre niveau de compatibilité devra changer et cela aura un impact sur vos applications. En le faisant plus tôt, vous pouvez alléger la quantité de travail que vous aurez à faire plus tard.

La façon rapide

Certains développeurs ou administrateurs prennent un raccourci lors de la migration d’une ancienne base de données vers une nouvelle version de SQL Server. Ils sauvegardent l’ancienne base de données et font une restauration sur une instance plus récente, qui prend en charge le niveau de compatibilité de l’ancienne base de données. Mais, après la restauration, ils gardent l’ancien niveau de compatibilité et continuent d’utiliser la base de données avec les mêmes applications. Enfin, ils annoncent à leurs utilisateurs que la migration est « complète ».

Dans certains cas, ça peut être le meilleur choix si l’application est complexe, surtout si le but est simplement d’éliminer d’anciennes instances de SQL Server, et que vous n’avez pas le temps de faire des changements à l’application. Pour certains administrateurs de bases de données, cette façon de faire n’est pas vraiment une migration ou une mise à niveau. Pour eux, vous avez tout simplement déplacé la base de données. De plus, et c’est plus important, vous ne serez pas en mesure d’utiliser aucune des nouvelles fonctionnalités offertes dans la nouvelle version.

Si vous optez pour la migration facile, sachez que ce que vous faites est en réalité juste de botter en touche, d’esquiver le problème pour un temps. Tôt ou tard, Microsoft sortira une version de SQL Server qui ne supportera pas le niveau de compatibilité de votre vieille base de données. Vous n’aurez alors pas d’autre choix que de migrer et de passer à un niveau de compatibilité plus élevé. Vous devrez également le faire si vous voulez profiter des nouvelles fonctionnalités de SQL Server.

Impacts du changement de niveau de compatibilité

Le fait de changer le niveau de compatibilité indique à la base de données de changer son jeu de fonctions. Autrement dit, certaines fonctionnalités seront ajoutées, mais en même temps, d’autres seront supprimées. Par exemple, au niveau de compatibilité 100, la clause FOR BROWSE n’est pas autorisée dans INSERT et SELECT INTO, mais est autorisée bien qu’ignorée au niveau 90. Si votre application utilise cette clause, le changement peut introduire des résultats inattendus.

Pour une liste des changements et une version mise à jour du tableau ci-dessus, trouvez la page appropriée de la bibliothèque MSDN basée sur votre version de SQL Server. Les liens ci-dessous sont quelques exemples :

• https://msdn.microsoft.com/en-us/library/bb510680.aspx
• https://msdn.microsoft.com/en-us/library/bb510680(v=sql.105).aspx
• https://msdn.microsoft.com/en-us/library/bb510680(v=sql.110).aspx

Avant de changer le niveau compatibilité

Ne jamais changer le niveau de compatibilité alors que des utilisateurs sont connectés. Il est préférable de suivre ces étapes pour faire le travail proprement :

1. Changer la base de données en mode mono-utilisateur.
2. Modifier le niveau de compatibilité.
3. Remettez la base de données en mode multi-utilisateur.

Pour l’essentiel, élever le niveau de compatibilité implique un réel travail et est considéré comme étant une véritable mise à niveau. Faire cela vous oblige à revoir et tester votre application, de balayer toutes les fonctions SQL utilisées et les mettre à jour si nécessaire. Essayez de trouver un utilisateur chevronné de l’application pour qu’il réalise un test complet, de A à Z, en même temps que vous, en tant que développeur, regardez le code pour voir quels problèmes pourraient avoir été introduits par la mise à niveau.

Attention à la mise à jour silencieuse

À terme, un niveau de compatibilité devient obsolète. Quand une nouvelle version de SQL Server ne prend plus en charge un vieux niveau de compatibilité, les bases de données ayant ce vieux niveau qui sont restaurées peuvent être silencieusement mises à niveau vers le niveau de compatibilité le plus bas possible sur le serveur. Par exemple, si vous restaurez une base de données SQL Server 2005 (avec le niveau de compatibilité 90) sur une instance SQL Server 2014, la base sera silencieusement mise à niveau 100. C’est parce que 100 est le plus bas niveau supporté par SQL Server 2014. Si vous regardez la table ci-dessus, 80 et 90 ne sont pas supportés par SQL Server 2014.

Testez votre application !

Même si vous ne modifiez pas le niveau de compatibilité, vous devez toujours tester votre application.

En effet, les chances sont élevées que cela vous donne des résultats inattendus lors de l’exécution de votre application et vous devrez corriger avant de déclarer la migration réussie. Tout dépend des fonctions de traitement de données utilisées par l’application. Utilisez les liens ci-dessus pour vous préparer.

Le niveau de compatibilité est aussi utilisé lorsque des procédures stockées (Stored Procedures) sont exécutées. En fait, toutes les procédures sont recompilées au changement de niveau. Donc, testez toutes les procédures stockées que votre application exécute.

Conclusion

Ne jamais supposer que la sauvegarde et la restauration d’une base de données sur une instance plus récente sont tout ce qu’il faut pour migrer une base de données. Ceci est la cause de bien des erreurs cachées et inattendues. Si votre application donne des erreurs après une restauration de la base de données, regardez son niveau de compatibilité. S’il a changé, vous savez maintenant pourquoi vous avez des erreurs. À mon avis, le niveau de compatibilité est plus important que la version de SQL Server elle-même.