Migration de SQL server 2005 vers SQL server 2008

Bonjour,

je souhaite migrer une application vers sql server 2008 depuis la version 2005. J'aimerai d'abord connaitre les impacts sur l'appli ? changement de code ?! requête obselete ?!
aprés, j'aimerai avoir les méthode pou y parvenir.

Merci.

Pour commencer, il est nécessaire de passer l'upgrade advisor 2008 pour connaitre les transformations à apporter à la base, en général, peu de transformation pour une base 2005.

http://msdn.microsoft.com/en-us/library/ms144256.aspx

http://www.microsoft.com/downloads/d...displaylang=fr

concernant la méthode de migration, elle n'a pas du changer, un simple flag à basculer.

Merci pour cette réponse. Mais un y a un point que je veut savoir. Es que la migration de SQL server 2005 à 2008 va impliquer des changement au niveau de l'application (au niveau du code par exemple). Il suffit juste de passer à 2008, il va pas pas falloir changer tout les fichier de qui contiennent la références à la base ?

Changement au niveau du code :

si votre application a été écrite en prenant certaines précautions, comme de placer l'ensemble du code SQL dans des procédures stockées. C'est mieux!

Le SQL écrit pour 2005 doit fonctionner sur 2008 donc le code SQL embarqué dans le code a des chances quand même d'être bon mais le tuning advisor ne pourra pas vous le dire ceci dit, vous le verrez malheureusement par un bug éventuel après la migration. Quoique peu probable...

Concernant la chaine de connexion à la base de données, cela fait des décennies que l'on doit l'embarquer dans un web.config, un global.asa où autre fichier de paramétrage windows, donc là aussi, je doute que la migration entraine un changement spectaculaire. Sauf, si bien sûr, le programmeur n'a pas fait son job convenablement.

A vous de nous le dire ?

je viens de noter que le rapport générer par l'upgrade Advisor peut contenir des flag du type « autres problèmes de mise à niveau » (other upgrade issues). Cet élément mène à une liste de problèmes qui ne sont pas détectés par l’upgrade Advisor, mais qui peuvent exister sur l'applications. ça peut être du à quoi ces problèmes non détectables ?

Je vous renvoie à la documentation microsoft concernant les migrations mais c'est un sujet vaste et complexe, l'an passé, en discutant avec un prospect, il me demandait comment migrer une réplication, la solution à ce problème se trouve non sur l'assistant mais dans la documentation 2005.

http://www.microsoft.com/downloads/d...DisplayLang=en

SQL Serveur Central pose le dilemne: est il utile de migrer une base 2005 sur 2008 vu la grande ressemblance entre ces deux serveurs.

http://www.sqlservercentral.com/arti...er+2008/64421/

Merci, mais je vois que cette question se pose lorsqu'on passe d'une version SQL server 2005 standard à la version standard 2008
mais pas du moement qu'on passe à la version Entreprise qui inclue toutes les nouvelle fonctionnalités
à ce niveau la c'est du commercial et ça ne m'étonne pas de la part de Microsoft.
Je pense personnelement que si on passe sur une version entreprise ça vaut le cout, je sais pas ce que t'en pense ?

ouaie, c'est une super chance d'avoir une version enterprise, vu le tarif de la licence. Evidemment, je suppose que vous en avez le besoin.

Sur la version enterprise, je vois l'intérêt lorsque la fenêtre de maintenance est trés étroite, là, on peux indexer online.

Il y a aussi les vues indexées qui offrent un vrai service aux développeur en panne de performance.

Il y a la capacité à monter en processeurs, en mémoire...

Sans doute qu'il y a d'autre point...

Juste une petite note de passage, on ne migre pas une application d'une version de SQL Server à une autre directement en live sur la production !
Installez un environment de dev en 2008, passer votre DB dessus, testez votre application exhaustivement, notez tous les nouveaux bugs et actions necessaires pour les résoudre, ensuite, passez en integration/UAT (les end users font des fois des choses bizarres auquelles on aurait jamais penser... lol ) et lorsque vous êtes sur de votre coup, que vous avez un timing précis et une liste de chose à changer (si necessaire) (scriptez tout !), pensez à bouger en production.