Exporter (0) Imprimer
Développer tout

Copie de bases de données dans Base de données SQL Azure

Mis à jour: juin 2014

L'opération de copie de base de données copie une Base de données SQL Microsoft Azure dans une nouvelle base de données. La copie peut être créée sur le même serveur logique ou sur un serveur logique différent. Une fois le processus de copie terminé, la nouvelle base de données est une base de données entièrement opérationnelle et indépendante de la base de données source. La nouvelle base de données est transactionnellement cohérente avec la base de données source à ce moment-là. La couche de service, la taille et le niveau de performance de la base de données de la copie sont identiques à la base de données source.

La nouvelle base de données offre les mêmes couches de service et niveaux de performance que la base de données. Chaque copie ajoute le nombre de bases de données total et est facturée au même tarif que la base de données source. Pour plus d'informations, consultez la page Détails de la tarification - Base de données SQL.

Dans cette rubrique :

Présentation

Les scénarios suivants exigent de créer une copie de votre base de données source dans une nouvelle base de données. Les méthodes utilisées dans ces scénarios dépendent du fait que les bases de données source et de destination résident dans le même serveur ou dans des serveurs différents, la même région ou des régions différentes, le même abonnement ou des abonnements différents. Ces méthodes sont décrites en détail dans la section Autres méthodes pour la copie d'une base de données située plus loin dans cette rubrique.

  • Développement et test d'application : copiez la base de données de production dans une nouvelle base de données pouvant être utilisée à des fins de développement et de test.

  • Mise à niveau de l'application : avant d'effectuer des mises à jour d'application majeures, copiez la base de données d'application vers une base de données de sauvegarde avec un nom différent. En cas d'échec ou d'erreur pendant la mise à niveau, récupérez la version antérieure à la mise à niveau de la base de données en renommant la base de données de sauvegarde avec le nom de la base de données d'application.

  • Migration d'application : il peut être nécessaire de migrer votre application, ce qui implique de déplacer également votre base de données.

noteRemarque
Les bases de données créées par la fonctionnalité de copie sont comptabilisées dans le cadre de la limite Base de données SQL Azure de 150 bases de données pour chaque serveur Base de données SQL Azure. Pour connaître l'impact en matière de coût et de facturation, consultez la rubrique Comptes et facturation de la Base de données SQL Azure.

Icône de flèche utilisée avec le lien Retour en haut [Top]

Utilisation d'une copie de base de données

Lors de l'utilisation de la fonctionnalité de copie de base de données, celles-ci étant copiées de façon asynchrone, aucune connexion au serveur Base de données SQL Azure n'est nécessaire pendant toute la durée du processus. Vous pouvez copier une base de données en vous connectant à la base de données master du serveur de destination et en exécutant l'instruction Transact-SQL CREATE DATABASE avec la clause AS COPY OF. Vous pouvez ensuite contrôler le processus de copie à l'aide des vues sys.dm_database_copies et sys.databases sur le serveur de destination.

Vous pouvez copier une base de données sur le même serveur Base de données SQL Azure avec un nom différent, ou sur un serveur Base de données SQL Azure différent. Cette section prend en compte ces deux alternatives.

Copie sur le même serveur

Lorsque vous copiez une base de données pour créer une nouvelle base de données sur le même serveur Base de données SQL Azure, les mêmes connexions peuvent être utilisées sur les deux bases de données. Le principal de sécurité que vous utilisez pour copier la base de données devient le propriétaire de la nouvelle base de données lorsqu'elle est créée. L'illustration suivante montre la copie sur le même serveur :

Copier une base de données sur le même serveur de base de données SQL

Sur cette illustration, Database1A est copié vers une nouvelle base de données, Database1B, sur le même serveur Base de données SQL Azure, Server1. La connexion qui a copié la base de données devient le propriétaire de la base de données Database1B. Tous les utilisateurs de la base de données, leurs autorisations et leurs identificateurs de sécurité (SID) de Database1A sont copiés vers Database1B. Les identificateurs SID des utilisateurs étant identiques sur les deux bases de données, les connexions à partir de Server1 conservent les mêmes autorisations sur les deux bases de données.

Une fois la copie terminée, Database1B devient une base de données totalement opérationnelle et indépendante. Les connexions, utilisateurs et autorisations de Database1B peuvent être gérés indépendamment de Database1A.

Copie d'un serveur à un autre

Vous pouvez également créer une copie de base de données sur deux serveurs Base de données SQL Azure distincts qui se trouvent dans la même région. Étant donné que la nouvelle base de données est créée sur un autre serveur Base de données SQL Azure, elle est associée à une autre base de données master. Tous les utilisateurs dans la nouvelle base de données conservent les autorisations qu'ils détenaient dans la base de données source. Le principal de sécurité que vous utilisez pour copier la base de données devient le propriétaire de la nouvelle base de données lorsqu'elle est créée et un nouvel identificateur de sécurité (SID) lui est assigné. L'illustration suivante montre la copie d'un serveur à un autre :

Copier une base de données vers un autre serveur de Base de données SQL

Sur cette illustration, Database1A est copié à partir de Server1 vers une nouvelle base de données, Database2A, sur un serveur Base de données SQL Azure différent, Server2. La connexion qui a copié la base de données devient le propriétaire de la base de données Database2A. Tous les utilisateurs de la base de données et leurs autorisations (mais pas leurs SID) de Database1A sont copiés vers Database2A. Les connexions provenant de Server1 ne peuvent pas être utilisées avec la nouvelle base de données, car elles sont associées à un serveur Base de données SQL Azure différent et car les SID utilisateur de Database2A sont différents des SID utilisateur de Database1A.

ImportantImportant
Une région de Base de données SQL Azure peut comprendre plusieurs clusters physiques. Actuellement, vous ne pouvez pas copier une base de données entre deux clusters différents. Par ailleurs, vous ne pouvez pas copier une base de données entre deux abonnements différents. Pour plus d'informations sur les restrictions, consultez Restrictions.

Une fois le processus de copie entre serveurs terminé, les connexions, les utilisateurs et les autorisations de Database2A peuvent être gérés indépendamment de Database1A. Utilisez la connexion du propriétaire de base de données et l'instruction Transact-SQL ALTER USER pour mapper les utilisateurs dans la nouvelle base de données aux connexions sur le nouveau serveur Base de données SQL Azure. Par exemple : ALTER USER userName WITH LOGIN='loginName'. Pour plus d'informations, consultez la rubrique ALTER USER.

Icône de flèche utilisée avec le lien Retour en haut [Top]

Autres méthodes pour la copie d'une base de données

Même si la méthode la plus simple pour copier une base de données consiste à utiliser la fonctionnalité de copie de base de données, ses restrictions décrites plus haut pourraient dans certains cas vous inciter à choisir l'une des autres méthodes disponibles. .

Quelques remarques à propos des options prises en charge :

Une restauration dans le temps vous permet de créer une copie d'une version précédente de la base de données. Par exemple, si vous devez créer une copie de la version de la base de données antérieure à la dernière mise à niveau. La restauration dans le temps est disponible uniquement dans la nouvelle couche de service. Pour plus d'informations sur la restauration dans le temps, consultez Sauvegarde et restauration de base de données SQL Azure.

La géo-réplication active est disponible uniquement sur les bases de données utilisant la couche de service Premium. Elle vous permet de contrôler la chronologie de l'opération de copie. Il est recommandé de l'utiliser lorsqu'une coordination précise est nécessaire entre la fin de la copie et d'autres actions de votre flux de travail. Pour plus d'informations, consultez Géo-réplication active pour la base de données SQL Azure.

Vous devez envisager de recourir au service d'importation/exportation lorsqu'aucune autre option n'est disponible dans votre scénario particulier. Pour plus d'informations sur l'importation/exportation, consultez Procédure : importer et exporter une base de données (Base de données SQL Azure).

Le tableau ci-dessous répertorie les options disponibles pour différents cas d'utilisation :

 

Cas Abonnement Région Serveur Options prises en charge

Cas A

Identique

Identique

Identique

  • Copie de base de données (T-SQL, REST ou PowerShell)

  • Restauration dans le temps

Cas B

Identique

Identique

Différent

  • Copie de base de données (T-SQL)

  • Copie de base de données (T-SQL, REST ou PowerShell) vers le même serveur + Exportation/importation

  • Restauration dans le temps vers le même serveur + Exportation/Importation

  • Géo-réplication active

Cas B

Identique

Différent

Différent

  • Copie de base de données (T-SQL, REST ou PowerShell) vers le même serveur + Exportation/Importation

  • Restauration dans le temps vers le même serveur + Exportation/Importation

  • Géo-réplication active

Cas C

Différent

Identique

Différent

  • Copie de base de données (T-SQL, REST ou PowerShell) vers le même serveur + Exportation/Importation

  • Restauration dans le temps vers le même serveur + Exportation/Importation

Cas C

Différent

Différent

Différent

  • Copie de base de données (T-SQL, REST ou PowerShell) vers le même serveur + Exportation/Importation

  • Restauration dans le temps vers le même serveur + Exportation/Importation

Cas d'utilisation A
Lorsque la source et la destination se trouvent sur le même serveur, la méthode la plus simple consiste à utiliser la copie de base de données ou la restauration dans le temps. Comme décrit plus haut, la restauration dans le temps vous permet de créer une copie de la base de données telle qu'elle était à un moment donné dans le passé, tandis que la copie de base de données copie la base de données telle qu'elle est à ce moment-là.

Cas d'utilisation B
Lorsque la source et la destination se trouvent dans des abonnements identiques mais sur différents serveurs, la copie de base de données avec T-SQL peut être utilisée pour copier sur un serveur logique différent. Cependant, si le serveur logique se trouve sur un cluster physique différent, la copie échoue. Afin de déterminer si les serveurs logiques se trouvent dans le même cluster, utilisez la commande « Ping » sur les deux serveurs pour voir s'ils ont la même adresse IP. Si le serveur de destination se trouve sur un cluster différent, procédez de la manière suivante :

  1. Créez une copie intermédiaire de la base de données dans le même serveur en tant que source. Vous pouvez utiliser la copie de base de données ou la restauration dans le temps.

  2. Exportez la copie vers un fichier BACPAC dans le stockage d'objets blob Azure.

  3. Importez le fichier BACPAC créé à l'étape 2 dans une base de données de l'abonnement/de la région/du serveur souhaité.

  4. Supprimez la base de données intermédiaire créée à l'étape 1.

Pour les bases de données Premium : vous pouvez également utiliser la Géo-réplication active pour créer une base de données secondaire comme copie de la base de données source. Les étapes suivantes sont obligatoires pour créer une copie de base de données :

  1. Créer une base de données secondaire sur le serveur cible.

  2. Arrêter la base de données secondaire lorsque l'état du processus de réplication est catch-up.

  3. La nouvelle copie devient une base de données indépendante disponible pour les opérations de lecture et d'écriture.

  4. Si le nom de la copie doit être différent de celui de la base de données source, renommez la copie.

Cas d'utilisation C
Lorsque la source et la destination se trouvent dans des abonnements différents, indépendamment du fait que les régions soient identiques ou différentes, vous pouvez utiliser le processus décrit pour le Cas d'utilisation B, à l'exception de la Géo-réplication active. La Géo-réplication active ne fonctionne pas entre différents abonnements.

Les sections suivantes décrivent le fonctionnement de la fonctionnalité de copie de base de données lors de la copie sur un serveur logique identique ou différent.

Tâches associées

Voir aussi

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft