Je configure un nouveau serveur de développement et souhaite installer la dernière version de SQL Server 2008 Express.Une raison d'avoir SQL Server 2005 et 2008 installé sur la même machine?
Est-ce que nos bases de données sql2005 existantes fonctionneront avec 2008 sans modification? Si oui, y a-t-il une raison pour installer les deux versions sur le même serveur?
Je n'ai pas vraiment essayé de migrer une base de données 2005 vers 2008, mais généralement SQL gère cela proprement et sans difficulté. La méthode la plus simple consiste à effectuer une sauvegarde de votre base de données à partir de SQL 2005 et à restaurer cette sauvegarde avec SQL 2008.
Si vous souhaitez conserver la copie SQL 2005 en ligne et jusqu'à ce que vous sachiez que la copie de 2008 fonctionne, vous devrez peut-être déplacer les fichiers de données/journaux pour votre base de données lors de la restauration de 2008, car les anciens fichiers de données seront utilisés en 2005. Vous pouvez le faire en utilisant l'option with move de restore database, par exemple:
RESTORE DATABASE mydb FROM disk = 'c:\backupfile.bak'
WITH MOVE 'maindatafile' to 'c:\newdatalocation.mdf',
MOVE 'mainlogfile' to 'c:\newloglocation.ldf'
Quant à la fois avoir installé en même temps, l'une des raisons que vous pouvez décider de le faire serait de simplifier le travail de te Sting code contre les deux versions, si vous aviez l'intention d'avoir votre support logiciel pour parler aux deux versions.
Vous pouvez détacher une base de données 2005 et l'attacher à un serveur 2008. Je recommande de ne pas installer les deux sur la même machine sauf si vous devez (par exemple, vous écrivez du code pour un tiers et ils n'utilisent que 2005).
Ce que je recommande vivement est en utilisant le serveur Windows 2008 Hyper-V pour créer 2 machines virtuelles avec l'environnement 2005, l'autre avec 2008. machines virtuelles Hyper-V sont incroyablement plus rapide que serveur virtuel 2007.
Les bases de données doivent (devrait!) fonctionner sans être modifiées. Toutefois, pour le développement, il est préférable que vous ayez sql2005 pour tester vos scripts, sauf si vous supposez que tous vos clients passeront à 2008, car 2008 a des fonctionnalités qui n'existent pas dans SQL Server 2005.
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 en raison du fait que plusieurs pools de mémoire tampon se battent et détruisent vos performances.
Pour moi, l'important est que vous ayez des instances prod qui sont des bases de données 2005? Devrez-vous prendre en charge les rapports de services de rapports qui se trouvent sur un serveur prod qui ne dispose que de la version 2005 des services de reporting, etc?
Si c'est le cas, vous devriez avoir les versions 2005 et 2008 sur vos machines de développement. J'ai vu beaucoup de code qui a dû être jeté parce que les développeurs ont travaillé sur 2008 quand prod était 2005. Toujours se développer contre la version du logiciel que vous aurez en prod. Si vous convertissez en 2008 mais pas encore en production, vous avez besoin des deux, une pour les changements de maintenance et une pour les futures.
Personnellement, j'ai un serveur SQL 2000, 2005 et 2008 sur ma machine car nous n'avons pas encore tout converti et j'ai des choses qui ne peuvent être faites que sur l'ancienne version. Nous avons trouvé que la clé pour maintenir plusieurs versions est de les installer dans l'ordre correct. Cela semble aller mal si vous mettez 2008 en premier, puis les anciennes versions.
Parfois, vous devez être en mesure de tester sur plusieurs versions, ou vous pouvez avoir besoin de 2005 pour une chose et 2008 pour une autre. Parfois, vous avez plusieurs applications différentes, dont certaines sont sur un et d'autres sur l'autre, et vous n'avez pas encore tout mis à jour. Parfois, vous effectuez une mise à niveau et 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 d'autres 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.