Une raison quelconque d'avoir SQL Server 2005 et 2008 installé sur le même ordinateur?

Question

Je configure un nouveau serveur de développement et souhaite installer la dernière version de SQL Server 2008 Express.

Nos bases de données SQL2005 existantes fonctionneront-elles avec 2008 sans modification?   Si oui, y a-t-il une raison d'installer les deux versions sur le même serveur?

Answer 1

Je n'ai pas encore essayé de migrer une base de données 2005 vers 2008, mais SQL le gère généralement proprement et sans difficulté. Le moyen le plus simple consiste à effectuer une sauvegarde de votre base de données à partir de SQL 2005, puis à restaurer cette sauvegarde avec SQL 2008.

Si vous souhaitez conserver la copie SQL 2005 et en ligne jusqu'à ce que vous sachiez que la copie 2008 fonctionne, vous devrez peut-être déplacer les fichiers de données / journaux de votre base de données lors de la restauration de la sauvegarde sur 2008, car les anciens fichiers de données sera utilisé d’ici 2005. Vous pouvez le faire en utilisant l’option avec déplacer de restaurer la base de données , par exemple:

RESTORE DATABASE mydb FROM disk = 'c: \ backupfile.bak'
 WITH MOVE 'maindatafile' vers 'c: \ newdatalocation.mdf',
 DÉPLACER 'fichier principal' vers 'c: \ newloglocation.ldf'

Pour ce qui est d’avoir les deux installés en même temps, vous pourriez peut-être décider de le faire en simplifiant le test du code par rapport aux deux versions, si vous aviez l’intention de faire dialoguer votre support logiciel avec les deux versions.

Answer 2

Vous pouvez détacher une base de données 2005 et l’attacher à un serveur 2008. Je déconseille d'installer les deux sur le même ordinateur, sauf si vous devez (par exemple, vous écrivez du code pour un tiers et ils n'utilisent que 2005).

Ce que je recommande fortement est d'utiliser Windows Server 2008 hyper-v pour créer 2 machines virtuelles, l'une avec l'environnement 2005 et l'autre avec 2008. Les machines virtuelles Hyper-v sont incroyablement plus rapides que le serveur virtuel 2007.

Answer 3

Les bases de données devraient ( devraient! ) fonctionner sans modification. Toutefois, pour le développement, il est préférable de disposer de sql2005 pour tester vos scripts, sauf si vous supposez que tous vos clients effectueront également une mise à niveau vers 2008, car 2008 ne comporte pas de fonctionnalités qui n'existaient pas dans SQL Server 2005.

Answer 4

Dans les environnements de développement et de test, l'installation de plusieurs serveurs de base de données n'est pas un problème et peut réduire le nombre de serveurs de test requis.

En production, je ne le recommanderais pas car plusieurs pools de mémoire tampon combattent et nuisent à vos performances.

Answer 5

Pour moi, l’important est de savoir si vous avez des instances de prod qui sont des bases de données 2005. Devrez-vous prendre en charge les rapports des services de génération de rapports sur un serveur de production disposant uniquement de la version 2005 des services de génération de rapports, etc.?

Si tel est le cas, vous devriez avoir les versions 2005 et 2008 sur vos machines de développement. J'ai vu beaucoup de code qui devait être jeté car les développeurs avaient travaillé sur 2008 alors que prod était 2005. Cependant, développez-le par rapport à la version du logiciel que vous aurez dans prod. Si vous effectuez une conversion en 2008 mais que vous n’êtes pas encore inscrit dans prod, vous avez besoin des deux, un pour les modifications de maintenance et un pour les tâches futures.

Personnellement, j’ai SQL Server 2000, 2005 et 2008 sur ma machine car nous n’avons pas encore tout converti et j’ai des tâches qui ne peuvent être effectuées que sur l’ancienne version. Nous avons découvert que la clé pour gérer plusieurs versions consiste à les installer dans le bon ordre. Cela semble aller mal si vous mettez 2008 en premier, puis les anciennes versions.

Answer 6

Parfois, vous devez être capable de tester plusieurs versions ou vous pouvez avoir besoin de 2005 pour une chose et de 2008 pour une autre.

Parfois, vous gérez plusieurs applications différentes, certaines sur l’une et l’autre sur l’autre, et vous n’avez pas encore tout mis à jour. Parfois, vous effectuez une mise à niveau et vous devez tester les deux versions au cours de la mise à niveau. Parfois, vous prenez en charge plusieurs clients différents, certains sur une version et certains sur une autre. Parfois, vous souhaitez mettre à niveau vos applications internes, mais vous utilisez un progiciel certifié uniquement sur une version antérieure.

Il y a beaucoup de raisons.