IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Migration avec attach bases


Sujet :

Administration SQL Server

  1. #1
    Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2009
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : février 2009
    Messages : 82
    Points : 56
    Points
    56
    Par défaut Migration avec attach bases
    Bonjour,

    J'aurais aimé une confirmation.

    J'ai récupéré l'administration d'une instance SQL Server 2000. Et oui on a encore du sql server 2000 pour une application qui n'est plus supportée mais qui va être remplacée... migration en cours.
    En attendant, nous devons maintenir et assurer la fiabilité du serveur SGBD SQL Server 2000 concerné.
    Pour ce faire, nous allons migrer la VM Azure concernée avec un OS Windows Server 2003 sur une VM Azure avec un OS Windows Server 2019.
    Ceci a été fait pour les environnements DEV et ACC. Après qq "réglages" par notre homme système sur Windows 2019, SQL Server 2000 fonctionne bien.

    Nous devons migrer maintenant les bases de PROD relativement volumineuses (application critique EAI).
    Notre contrainte : limiter au maximum la "fenêtre" de downtime.

    Ce qui est prévu :
    . arrêter la VM actuelle / SQL Server sera donc arrêté
    . snapshot des disques sur lesquels il y a les fichiers data et log des bases
    . connexion du snapshot sur la nouvelle VM et copie sur les disques de ce nouveau serveur
    . attach des bases à partir des fichiers data et log présents

    Backups des bases + copie des backups + restore des bases = durée très importante
    Arrêt VM + snapshot + lien et copie snapshot sur disques nouvelle VM + attach --> beaucoup moins de temps

    D'habitude, pour une migration je fais cela par backup/restore (ce qui a été fait pour DEV et ACC).


    Dans notre plan d'action,

    → est-ce que le fait de ne pas faire de detach des bases avant l'arrêt de SQL Server peut être préjudiciable sur l'attach à venir sur le nouveau serveur ?

    → est-ce que l'arrêt de SQL Server "suffit" pour assurer une cohérence des bases après l'attach à venir sur le nouveau serveur ?

    Pour résumer, est-ce que faire un arrêt de sql server et ensuite utiliser les fichiers data et log des bases utilisateurs pour faire des attach sur une autre instance fonctionne et est sans risque pour la cohérence des bases ?


    Après l'attach, je prévois de faire les opérations suivantes :
    → dbcc checkdb
    → DBCC UPDATEUSAGE (0)
    → EXEC sp_updatestats
    et eventuellement reconstruire les index les plus volumineux si la "fenêtre temps" le permet.
    Votre avis ?

    Par avance, merci pour vos réponses.

    Franck

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 726
    Points : 49 099
    Points
    49 099
    Billets dans le blog
    1
    Par défaut
    Le mieux serait de faire tout simplement un sp_detach_db côté 2000, copier les fichiers de données (pas les journaux) vers la destination puis réattacher de l'autre avec CREATE DATABASE ... FOR ATTACH WITH REBUILD LOG.

    Le problème est que la migration de 2000 vers 2019 n'est pas supportée. Il faut impérativement passer par une étape intermédiaire 2008/2008R2.

    Après DBCC UPDATEUSAGE (0) va mettre beaucoup de temps... et c'est inutile....
    Et EXEC sp_updatestats le fait par échantillon, ce qui peut être cata dans certains cas.
    et faite un dbcc checkdb au niveau physique cela suffit

    Si vous êtes en édition enterprise, je vous conseille un recalcul des stats en mode FULLSCAN

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    DECLARE @SQL NVARCHAR(max) = N'';
    SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + '].[' + o.name + '] ( [' + st.name   + ']) WITH FULLSCAN;' 
    FROM   sys.stats AS st
           JOIN sys.objects AS o ON st.object_id = o.object_id
    	   JOIN sys.schemas AS s ON o.schema_id = s.schema_id
    	   CROSS APPLY sys.dm_db_stats_properties(st.object_id, st.stats_id) AS sp
    WHERE  is_ms_shipped = 0;
    EXEC (@SQL);
    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2009
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : février 2009
    Messages : 82
    Points : 56
    Points
    56
    Par défaut
    Bonjour Frédéric,

    Quand je parlais de 2019 c'était pour Windows.
    On reste en SQL Server 2000 car l'application "plus supportée" ne permet pas de faire évoluer la version de SQL Server (à cause de l'utilisation notamment de tables system à l'ancien format).
    J'ai fait une étude complète pour faire évoluer SQL Server mais pas possible. Pas d'évolution possible sur l'application qui reste "figée" jusqu'au remplacement (en cours).
    Le fait de passer de Windows 2003 à Windows 2019 au niveau OS sur nos VM Azure va nous permettre de bénéficier de capacités dans Azure notamment pour les backups Azure des disques.

    Si je ne fais pas le detach des bases mais si l'instance SQL Server est arrêtée avant la copie des fichiers data, est-ce que c'est ok ?
    Normalement l'arrêt de SQL Server devrait permettre la cohérence des fichiers de chaque base et permettre un attach après sur l'autre instance.

    Vous allez me demander pourquoi je ne veux pas faire le detach sur l'ancien serveur ?
    Si pb lors de la migration, je conserve l'instance SQL Server actuelle à l'identique au cas où j'aurais besoin de faire marche arrière.
    Il me suffit de la rédémarrer et tout est comme avant. Pas besoin de refaire les attachs.

    Ok pour me limiter au dbcc checkdb après l'attach.
    C'est une édition Standard pour SQL Server donc moins pratique pour avoir des opérations moins pénalisantes.

    Merci pour votre retour

    Franck

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 726
    Points : 49 099
    Points
    49 099
    Billets dans le blog
    1
    Par défaut
    Il vaut mieux quand même faire le detach et conserver les fichiers sur l'ancien serveur afin d'éviter la dualité des bases.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 401
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : août 2005
    Messages : 5 401
    Points : 12 732
    Points
    12 732
    Par défaut
    Si tu veux un minimum de downtime, pourquoi ne pas passer par du log shipping entre tes 2 VM ? Sur SQL 2000 ca marche plutôt bien.

    ++

  6. #6
    Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    février 2009
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : février 2009
    Messages : 82
    Points : 56
    Points
    56
    Par défaut
    Bonjour,

    Merci Frédéric pour la précision.

    Merci Mikedavem pour l'idée du log shipping. L'instance actuelle est très critique et on va éviter de la "toucher". De plus, on a négocié un arrêt pendant un week-end nous permettant de faire l'opération "snapshot disques actuels / link des snapshots sur nouvelle VM / copie data et log files sur disques nouvelle VM / attach des bases / check des bases".
    Je suis en train de tester l'opération afin de voir le temps à prévoir.

    Merci à vous 2

    Franck

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 4
    Dernier message: 10/06/2014, 16h29
  2. Réponses: 4
    Dernier message: 31/10/2013, 14h18
  3. [11gR2] Migration avec même nom de serveur et nom base d données
    Par zidane2012 dans le forum Administration
    Réponses: 1
    Dernier message: 25/09/2013, 13h45
  4. [2005] Attach base avec script sqlcmd
    Par Mimie37 dans le forum Administration
    Réponses: 2
    Dernier message: 20/02/2013, 13h20
  5. migration 2007 -> 2010 attachement base de données
    Par James Dt dans le forum Installation
    Réponses: 1
    Dernier message: 27/02/2012, 17h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo