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 (21)

  1. Hood says:

    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

  2. erol says:

    merci EROL MVP SPS il faudra que je vois ce que cela va donner avec SPS 2003, tu l’as testé ?

  3. 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.

  4. Hood says:

    Ah merci …

    Je me disais que sinon, il y allait avoir des émeutes un peu partout dans le monde 😀

    /Hood

  5. faire des transferts de base via internet d’un server sql server 2000 vers un sql server 2005 pose des problêmes lorsque les noms de colonnes ont des caractères accentués comme par exemple "Référence"

    je suis le seul a avoir connu ce problême ?

    p.s : les deux serveurs ont la même collation , l’install sql 2005 a été fait en mode compatible sql server 2000

  6. C'est des conneries says:

    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é.

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

  8. tikam says:

    Bonjour,

    j’ai suivi exactement la même procédure mais j’ai un message d’erreur quand je veux accéder au schéma de base de données (diagramme en sqlserver 2000):

    Les objets de prise en charge du schéma de base de données ne peuvent pas être

    installés car la base de données n’a pas de propriétaire valide. pour continuer,

    définissez le propriétaire de la base de données à un nom de connexion valide

    dans la page fichiers de la boîte de dialogue propriétés de la base de données,

    puis ajoutez les objets de prise en charge du schéma de base de données"

    les autres développeurs disent qu’ils faut créer la base par un script et importer les données, je trouve ça contradictoire vu que la restauration marche bien , qu’est ce qui coince dans tout ça ?

    merci de me donner votre avis

  9. 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.

  10. Tikam says:

    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

  11. Tikam says:

    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

  12. Cool ! tiens moi au courant de la réaction du pro 🙂

  13. Tikam says:

    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

  14. Laurens says:

    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 ?

  15. Pascal Belaud says:

    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 !

  16. Pierre-Yves says:

    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).

  17. Steve Renaud says:

    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.