Les fichiers d'une base de données peuvent-ils être copiés alors qu'une base de données est en ligne?


9

Je travaille sur la configuration d'une copie de développement d'une base de données de production sur SQL Server 2008 R2 SP1. La base de données en direct est actuellement légèrement utilisée par deux développeurs pour les requêtes en lecture seule, mais la nouvelle base de données aura également des mises à jour.

Étant donné que la base de données est de 2,1 To et a pris au total 3 jours pour restaurer et mettre à jour la dernière version dont nous avons besoin pour les tests, mon plan initial était de créer un nouvel ensemble de fichiers de sauvegarde, puis de restaurer à partir de ces fichiers. Cela me permettrait de créer la copie de développement de la base de données sur la même instance SQL et la même machine, sans avoir à mettre la base de données actuelle hors ligne.

Cependant, afin d'économiser quelques jours, je pensais que ce pourrait être une bonne idée de simplement copier les fichiers de la base de données physique et de joindre la nouvelle copie de la base de données. Malheureusement, lorsque j'essaie de copier, j'obtiens une erreur faisant référence au verrou que SQL Server place sur ces fichiers.

Étant donné que je ne peux pas mettre la base de données hors ligne pour autre chose que le transfert des fichiers journaux (je peux terminer cela avant que les gens n'entrent le matin), existe-t-il un moyen de copier les fichiers de base de données en direct sans mettre la base de données dans un état hors ligne? Ou devrais-je attendre que les gens rentrent chez eux pour le faire?

Réponses:


11

Pourquoi faut-il 3 jours pour sauvegarder / restaurer une base de données de 2,1 To? S'il s'agit de déplacer la sauvegarde, je soupçonne que la copie des fichiers MDF / LDF serait en fait plus lente car au moins la sauvegarde pourrait être compressée. Et s'il s'agit simplement de restaurer, l'écriture des copies du fichier ne devrait pas être plus rapide que le processus de restauration lui-même - assurez-vous que l' initialisation instantanée du fichier est activée . Ou obtenez des E / S plus rapides sur le système secondaire.

Quoi qu'il en soit, non, vous ne pouvez pas copier les fichiers MDF / LDF pendant que la base de données est en ligne, vous devez la mettre hors ligne pour le faire. Et c'est le moyen le MOINS sûr et absolu de copier une base de données. Si quelque chose arrive aux fichiers alors qu'ils sont détachés / hors ligne, vous n'avez maintenant aucune copie de votre base de données.

Je suggérerais de chercher des moyens d'accélérer la sauvegarde / restauration - que ce soit en vous assurant de compresser vos sauvegardes et de transférer les fichiers de la meilleure façon possible, en utilisant le meilleur sous-système d'E / S disponible, en améliorant les E / S, en faisant assurez-vous que l'IFI est activé, etc.

Une autre option à envisager est l'envoi de journaux à tour de rôle - en supposant que la production est en pleine récupération et que vous effectuez des sauvegardes de journaux régulières, vous pouvez effectuer l'envoi de journaux vers une base de données pendant que les développeurs travaillent sur une autre, et lorsque vous arrivez à un point stable, restaurez avec la récupération et faire basculer les développeurs en emportant avec eux leurs récents changements. Réinitialisez maintenant l'envoi des journaux sur la copie sur laquelle ils viennent de cesser de fonctionner, et il sera prêt pour eux au prochain basculement "stable", sans attente.


La sauvegarde prendrait un nombre d'heures inconnu (je n'ai pas créé la sauvegarde d'origine). La restauration prend 10 heures, puis l'exécution des mises à jour pour l'adapter à notre build de développement prend encore 8 heures. Donc, vraiment, si nous parlons d'une journée de 24 heures, cela ne prend que 18 heures. Parler d'environ 8 heures par jour, c'est essentiellement 3 jours (en ajoutant du temps pour copier les fichiers). Il y a ABSOLUMENT des façons de régler le processus de sauvegarde / restauration lui-même, et c'est ce que je vais faire maintenant que je sais que c'est la voie que je veux suivre.
Sean Long

0

Non, vous devrez le mettre hors ligne pour copier les fichiers. Si votre base de données est divisée en fichiers / groupes de fichiers plus petits, cela pourrait aider à accélérer la restauration de la sauvegarde après l'avoir effectuée une fois (selon les données qui changent et les données nécessaires pour la copie de développement).


0

J'ai vu les autres réponses et elles sont parfaitement logiques. Cependant, juste pour répondre à votre question, vous pouvez certainement copier des fichiers de base de données sans mettre la base de données hors ligne. Vous devrez utiliser la programmation SMO à cet effet. Vérifiez ceci: http://technet.microsoft.com/en-us/library/ms162175(v=sql.100).aspx

Veuillez noter que le lien fourni concerne les objets de programmation SMO généraux et non une réponse spécifique à cette question. Je ne l'ai pas encore fait, mais je vais bientôt essayer cela et je ferai savoir à tout le monde (si je me souviens bien) ce que je découvre.


-1

Les fichiers d'une base de données peuvent-ils être copiés alors qu'une base de données est en ligne?

Oui.

Tout ce que vous avez à faire est de mettre la base de données en lecture seule:

  1. Courir:

    USE [master]
    GO
    ALTER DATABASE [Database] SET READ_ONLY WITH NO_WAIT
    GO
  2. Copiez les fichiers de base de données - MDF, LDF, etc. vers leur nouvelle destination

  3. Une fois la copie effectuée, vous pouvez détacher et rattacher le nouvel emplacement. Assurez-vous simplement de réinitialiser l'option en lecture seule et que vous utilisez le même compte d'utilisateur lors de la manipulation de ces fichiers. En outre, vous souhaiterez peut-être supprimer les anciens fichiers après le déplacement.

Une autre méthode

Une fois les fichiers copiés avec succès (étape 2 ci-dessus):

Vous pouvez définir la base de données sur: Single_Usermode puis:

  1. Courir:

    USE [master]
    GO
    ALTER DATABASE [Database] SET  Single_USER WITH NO_WAIT
    GO
  2. D:\ être le nouvel emplacement

    ALTER DATABASE Database MODIFY FILE
    (NAME = DATABASE, FILENAME = 'D:\DATABASE.mdf')
    GO
    ALTER DATABASE OHDSI MODIFY FILE
    (NAME = DATABASE_LOG, FILENAME = 'D:\DATABASE_LOG.ldf')
    GO
  3. Assurez-vous que les fichiers de données dans le nouvel emplacement ( D:\) ont un accès complet au compte de service qui exécute SQL Server.

  4. Redémarrez les services SQL

  5. Courir:

    USE [master]
    GO
    ALTER DATABASE [Database] SET  Multi_USER WITH NO_WAIT
    GO

Terminé!


Notez tout d'abord que le fait de mettre la base de données en mode lecture seule provoque une panne effective si une utilisation normale nécessite l'écriture dans la base de données. Deuxièmement, je m'attendrais à ce que SQL Server verrouille toujours les fichiers à utiliser s'ils sont lus; si votre expérience personnelle ou votre documentation MS indique le contraire, veuillez le modifier dans votre réponse. Troisièmement, le conseil que j'ai généralement vu pour modifier l'emplacement d'un fichier est de mettre la base de données hors ligne , pas seulement en mode mono-utilisateur. Encore une fois, si vous avez une expérience personnelle ou des documents MS suggérant le contraire, veuillez modifier en réponse. Merci!
RDFozz

C'est correct! La lecture seule empêchera les utilisateurs d'écrire, mais ils pourront lire. Dans votre deuxième point - oui, vous pouvez mettre la base de données hors ligne - mais la question est en ligne. Le processus que j'ai décrit ci-dessus fonctionne avec un temps d'arrêt minimal. Merci.
RAVicioso

@RAVicioso la base de données en lecture seule est également une panne. Si vous ne pouvez pas écrire de nouvelles données (c'est-à-dire prendre des commandes), votre système est effectivement en panne. Cela semble être une mauvaise idée, non?
Erik Darling

@sp_BlitzErik - La solution fonctionne, mais vous ne pourrez pas écrire pendant ce type de maintenance. Dans votre exemple: «prenez les commandes», ce ne sera pas le cas.
RAVicioso
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.