Du développeur à l'entreprise, tout ira bien, assurez-vous simplement que si vous utilisez des licences de processeur, vous disposez de licences sur le serveur cible pour couvrir tous les processeurs. Et il ne suffit pas de les cacher de SQL, s'ils sont physiquement connectés à la machine, vous en êtes responsable.
De plus, lorsque vous passez d'une version inférieure à une version supérieure, la version de votre base de données augmente. Il existe quelques scénarios où cela peut être problématique - par exemple, si vous utilisez la prise en charge de 15 000 partitions sur une version spécifique de 2008, cela ne fonctionnera pas lorsque vous effectuez une mise à niveau vers une version spécifique de 2008 R2. Vous pouvez également compter sur des optimisations (et des solutions de contournement en place) qui sont en fait des bogues dans une ancienne version mais qui sont corrigées dans la nouvelle version, ce qui peut entraîner une baisse des performances. Il est également essentiel d'examiner tous les indicateurs de trace utilisés à la source et de déterminer s'ils doivent également être activés à la destination. Peu importe les emplois, les connexions, etc.
Bien sûr, vous ne pouvez pas reculer. Je n'ai jamais essayé un downgrade mineur comme 10.0.5512 -> 10.0.5500 mais il n'est certainement pas possible de descendre dans le service pack ou la version. Donc, si vous avez une base de données 2012 sur votre instance Developer Edition et que vous souhaitez la mettre sur votre instance 2008 en production, vous aurez du travail à faire pour vous (voir ici et ici ) - surtout si vous avez utilisé les fonctionnalités 2012 .
Mais pour couvrir d'autres cas qui pourraient amener les gens à cette question (par exemple, quelqu'un veut passer de Developer -> Standard ou Enterprise -> Express ou ce que vous avez) ...
Il existe d'autres éditions -> mises à niveau d'édition qui ne fonctionneront pas aussi bien, par exemple de Developer -> Express si vous avez utilisé des fonctionnalités qui ne sont pas prises en charge dans Express (et il en va de même pour toute édition autre que Enterprise vraiment). Quelques exemples de fonctionnalités que vous ne pourrez pas utiliser sur les éditions de bas niveau (auquel cas la restauration mourra au moment où elle tentera de mettre la base de données en ligne):
- Partitionnement
- Modifier la capture de données
- Compression des données
- Cryptage transparent des données
Je ne sais pas s'il existe un moyen de le dire directement à partir du fichier .BAK (je suis sûr qu'il y a de la magie qui peut être extraite quelque part des en-têtes de page, ou si vous avez un week-end à graver avec un éditeur hexadécimal) , mais bien que la base de données soit toujours intacte sur l'instance source, vous pouvez toujours procéder comme suit pour voir si vous utilisez des fonctionnalités disponibles en raison de la référence que vous utilisez:
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
Je ne sais pas si SQL Server Audit devrait figurer sur cette liste - l'exclusivité d'édition de cette fonctionnalité a changé, donc cela dépend probablement de ce que vous en faites. Il y a d'autres choses que vous utilisez peut-être mais qui n'apparaîtront pas dans le DMV (certaines parce qu'elles sont dans votre code, que le DMV n'analyse pas, et d'autres parce que votre base de données s'appuie sur des choses externes telles que l'Agent SQL Server , Service Broker, etc.):
- mise en miroir
- certaines formes de réplication
- expédition de journaux
- instantanés de base de données
- indexation en ligne
- vues partitionnées distribuées pouvant être mises à jour
- compression de sauvegarde
- gestion basée sur des politiques
- guides de plan
- messagerie de base de données
- plans de maintenance
- recherche en texte intégral
Il existe également des cas où vous ne pourrez pas passer du développeur à Express en raison des limitations de taille de fichier (les bases de données Express sont limitées à 10 Go de taille totale du fichier de données).
Bien sûr, il peut y avoir d'autres problèmes dont vous ne serez pas averti - ils n'empêcheront pas la migration, mais ils peuvent conduire à des performances très différentes sur la cible. Exemples:
- Différentes limitations de mémoire / CPU sur l'édition cible (ou même le système d'exploitation sous-jacent sur la cible). Beaucoup de gens sont passés de 2008 R2 Enterprise à 2012 Enterprise (CAL), où le service est artificiellement limité aux 20 premiers cœurs). Cela peut entraîner des différences de performances simples (pas assez de mémoire pour satisfaire une requête, par exemple, ou des performances de requête parallèle beaucoup plus lentes); les plus subtils incluent les choix de plans qui sont faits en raison des différents matériels sous-jacents.
- La dépendance à des fonctionnalités telles que la correspondance de vues indexées sur la source ne sera pas automatiquement respectée sur la cible sans changer le code source à utiliser
NOEXPAND. Et vous ne savez peut-être même pas que cette capacité est la raison pour laquelle vos requêtes ralentissent soudainement.
- Il en va de même pour les opérations d'index parallèles et probablement une foule d'autres optimisations qui ne me viennent pas à l'esprit en ce moment (heureusement, je travaille presque exclusivement dans l'espace Enterprise, donc je n'ai pas à me soucier des limitations des éditions inférieures dans la plupart des cas ).
MISE À JOUR basée sur ce double :
Il peut y avoir des cas où vous essayez de restaurer une base de données d'une certaine édition vers une édition moindre (même sur la même version), et vous obtenez des erreurs qui ne sont pas utiles :
RESTORE a échoué pour le serveur 'serveur \ instance'.
RESTORE n'a pas pu démarrer la base de données 'nom de la base de données'.
Ce n'est pas très intuitif. Cependant, si vous regardez plus en profondeur dans les journaux d'événements de SQL Server, vous verrez des erreurs plus utiles (un seul exemple):
La base de données «nom de la base de données» ne peut pas être démarrée car certaines fonctionnalités de la base de données ne sont pas disponibles dans l'édition actuelle de SQL Server.
La base de données «nom de base de données» ne peut pas être démarrée dans cette édition de SQL Server car elle contient une fonction de partition «_dta_pf__9987». Seule l'édition Enterprise de SQL Server prend en charge les fonctions de partition.
Maintenant, ce n'est pas tout à fait vrai - vous pouvez également restaurer vers Edition d'évaluation ou Developer Edition, mais ce n'est pas la question. Afin de restaurer cette base de données, vous avez essentiellement deux options:
- Restaurez vers une édition appropriée de SQL Server - ce qui signifie localiser ou installer une nouvelle instance.
- Restaurez la sauvegarde sur le serveur source en tant que nouvelle base de données avec un nom différent, supprimez toutes les fonctionnalités Enterprise, puis sauvegardez à nouveau la base de données et restaurez-la sur la moindre édition. (Dans ce cas spécifique, j'ai laissé le nom de la fonction de partition dans le message d'erreur, car cela semble de toute façon être une chose à ignorer - il a été créé par le Conseiller de réglage du moteur de base de données et peut avoir été fait par quelqu'un qui n'a pas tout à fait savoir ce qu'ils faisaient. Ce n'est pas toujours le cas.)
Une variante de (2) serait de simplement supprimer le partitionnement et les autres fonctionnalités de la base de données source et d'effectuer une autre sauvegarde. Mais si ce n'est pas cassé ...