Share via


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!

    /Hood

  • Anonymous
    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

    /Hood

  • Anonymous
    September 13, 2006
    The comment has been removed

  • Anonymous
    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 removed

  • Anonymous
    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.

    tikam

  • Anonymous
    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

    Tikam

  • Anonymous
    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


    Tikam

  • Anonymous
    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.