Migration de SQL Server 7.0/2000 vers SQL Server 2005
Lorsque l'on voit ce que Microsoft SQL Server 2005, nom de code Yukon, peut amener aux développeurs, on est tenté de s'y mettre le plus vite possible.
Cependant quand on a un existant SQL Server 2000 ou SQL Server 7.0, il est également légitime de se poser la question : "Que faire ? "
Plusieurs approches sont possibles :
Installation de nouvelles instances SQL Server 2005 en "side by side" avec des instances 7.0 ou 2000. Ce scénario est totalement supporté. Un extrait de la documentation :
Migration d'une instance 7.0 ou 2000 directement vers la version 2005. Voici les chemins de migration supportés :
Si vous souhaitez tester ce que donnerait une base de données au format SQL Server 2000 directement sous SQL Server 2005, il est possible d'effectuer une sauvegarde de votre base de données depuis une instance SQL Server 2000 et de la restaurer directement dans une instance SQL Server 2005.
Préambule :
Si vous essayer de vous connecter depuis l'outil SQL Enterprise Manager 2000 vers une instance SQL Server 2005, vous obtiendrez le message d'erreur suivant :
Par contre, depuis le tout nouveau SQL Server Management Studio 2005, il est tout à fait possible de se connecter à une instance SQL Server 2000 :
Ceci étant dit, pour effectuer les tests nécessaires, nous allons donc d'abord réaliser une sauvegarde de la base de données :
Nous allons maintenant opérer la restauration de ce fichier de sauvegarde depuis une instance SQL Server 2005 :
Nous avons désormais accès à la base de données au format SQL Server 2005 :
[Initialement posté le 15/03/2005 à 18:03 ici]
Comments
Anonymous
September 13, 2006
Ai je bien lu : pas d'upgrade d'un SQLSERVER2000 Entreprise vers une version de Yukon ....
Heu, cest prévu dans un avenir proche, car sinon yen a qui vont avoir des mauvaises surprises!
/HoodAnonymous
September 13, 2006
merci EROL MVP SPS il faudra que je vois ce que cela va donner avec SPS 2003, tu l'as testé ?Anonymous
September 13, 2006
Salut Hood,
Non, non, ne t'inquiète pas :-), c'est seulement le statut pour la build intermédiaire dont j'ai extrait la documentation.Anonymous
September 13, 2006
Ah merci ...
Je me disais que sinon, il y allait avoir des émeutes un peu partout dans le monde :D
/HoodAnonymous
September 13, 2006
The comment has been removedAnonymous
September 13, 2006
CE QUE TU EXPLIQUE NE MARCHE ABSOLUMENT PAS !!
Les indexations sont complètement différentes entre SQL 2000 et 2005. Tu perds tout lors de la restauration et REBUILD ou DBCC n'est plus supporté.Anonymous
September 13, 2006
Que c'est joliment et surtout poliment dit tout ça. Je ne parle même pas du post courageux que tu fais, anonymement...
Ceci étant dit, je te confirme que tout ce qui est dit dans ce post est correct et que les indexations sont les mêmes entre SQL Server 2000 et SQL Server 2005.
DBCC DBREINDEX est toujours supporté mais il est juste précisé que, dans une prochaine version, cette commande pourrait être supprimée et remplacée par ALTER INDEX ... REBUILD
Enfin et pour ta gouverne, il n'y a jamais eu de commande REBUILD en SQL Server 2000.
Maintenant, si la base était corrompue lors de la restauration, cela expliquerait la recréation des index ou alors il se peut que l'optimiseur de SQL Server 2005 ait besoin d'autres indexes que ceux de SQL Server 2000 mais ce cas est extrêmement rare et si tu es tombé dessus, tu n'as pas eu de chances, mais de toute façon, ça ne te donnerait pas pour autant le droit d'être impoli.
A bon entendeur.Anonymous
September 13, 2006
The comment has been removedAnonymous
September 13, 2006
Salut Tikam,
Pas de panique !
Il suffit, comme le dit le message, de réaffecter un utilisateur valide à cette base. Tout est clairement expliqué dans ce lien :
http://msdn2.microsoft.com/en-us/library/ms186345.aspx
Cela va consister globalement à exécuter une requête T-SQL de 1 ligne à peu près !
ALTER AUTHORIZATION ON DATABASE::TaBase TO TonLogin
Donc tu pourras dire "aux autres développeurs" qu'il y'a une solution bien plus simple que ce qu'ils te proposent :-)
A ta disposition pour plus d'infos.Anonymous
September 13, 2006
re-bonjour,
Ma base a pour propriétaire l'administrateur local sur la machine, et en tentant de lui affecter un autre utilisateur (puisque celui là n'est pas valide à priori) cad l'utilisateur dbo qui est l'administrateur sur le domaine, j'obtiens le message suivant:
Msg 15110, Niveau 16, État 1, Ligne 1
Le nouveau propriétaire proposé pour la base de données en est déjà un utilisateur ou en possède un alias.
d'autre part si je prends le problème à l'envers et que je créé le propriétaire de ma base comme utilisateur de la base, ça ne résoud pas mon problème d'accès au schéma.
je pense que je n'ai pas tout compris ;-), pouvez vous m'aider ?, je vous remercie.
tikamAnonymous
September 13, 2006
Merci pascal,
Je vous remercie beaucoup,
grâce au lien que vous m'avez donné et que j'ai relu plus attentivement, j'ai exécuté l'instruction
ALTER AUTHORIZATION ON DATABASE::database_name TO valid_login.
et j'accède enfin à mes schémas.
du coup je vais le dire avec joie au fameux développeur qui se la joue "super pro SQL"
Encore merci
TikamAnonymous
September 13, 2006
Cool ! tiens moi au courant de la réaction du pro :-)Anonymous
September 13, 2006
Bonjour,
en fait c'est la requête:
EXEC sp_dbcmptlevel 'database_name', '90';
qui a résolu mon problème, j'avais fait une erreur de copier coller sur le message précédent dsl ;-)
quand à la réaction du pro elle fut brève ! "il intègre la solution dans la FAQ de développez.net... LOL
voici le lien vers la discussion en question:
http://www.developpez.net/forums/showthread.php?t=160405
TikamAnonymous
February 19, 2007
PingBack from http://chaespot.com/mssql/2007/02/20/whats-new-in-microsoft-sql-server-2000-find/Anonymous
March 13, 2007
Salut, Je viens d'avoir la surprise d'une requête qui en SQL2005 SP2 (bonne version) se met à lire 75 millions de lignes contre 1500 en SQL2000 SP4 ! Evidemment le temps d'execution est une cata. Cette requête est pourtant une simple procédure stockée qui utilise du SQL dynamique... Une idée ?Anonymous
March 13, 2007
Salut Laurens, Bien-sûr ! Compte-tenu de la direction du vent et de l'âge du capitaine, je dirais que c'est normal... :-) Plus sérieusement, si tu veux que je t'aide, il faudrait peut-être me donner un minimum de détails techniques sur ta base, tes tables, tes indexes et la requête qui fait défaut, tu ne crois pas :-) ? A bientôt !Anonymous
April 10, 2007
Salut, j'ai executer la commande EXEC sp_dbcmptlevel 'nom_de ma base', '90'; et SQL 2005 me dit que la valeur 90 n'est pas un bonne valeur seul les valeur 60, 65, 70, 80 sont des valeur correct. Alors comment faire pour passer en compatibilité 2005 ? PS: j'ai besoin d'utiliser la compatibilité 2005 pour définir un varchar(max).Anonymous
June 11, 2007
PingBack from http://chaespot.com/mssql/2007/06/12/learn-how-to-migrate-an-access-database-to/Anonymous
June 22, 2007
PingBack from http://chaespot.com/mssql/2007/06/23/microsoft-certified-windows-2000-server-experts-offer-computer/Anonymous
April 27, 2009
Bonjour, Eh oui je vais faire une migration depuis SQL 2000 vers SQL 2005 en 2009 (l'année) ! Votre article est très intéressant, mais je voulais juste savoir si je pouvais désinstaller ensuite SQL 2000 du serveur après la migration sans altérer la nouvelle version... Par ailleurs j'ai une version standard du 2000, est-ce que la migration fonctionne vers un SQL 2005 Enterprise ? Merci d'éclairer ma lanterne quelque peu rouillée.