Le service Import/Export d’Azure SQL Database et de SQL Managed Instance prend beaucoup de temps pour importer ou exporter une base de données

S’applique à :Azure SQL DatabaseAzure SQL Managed Instance

Parfois, lorsque vous utilisez le service Import/Export, il arrive que le processus dure plus longtemps que prévu. Cet article décrit les causes probables d’un tel ralentissement et présente des méthodes permettant de contourner ce problème.

Service Import/Export d’Azure SQL Database

Le service Import/Export d’Azure SQL Database est un service web basé sur REST qui s’exécute dans chaque centre de données Azure. Ce service est appelé quand vous utilisez l’option Importer ou exporter une base de données pour déplacer votre base de données dans le portail Azure. Grâce à lui, vous pouvez placer des requêtes en file d’attente ou effectuer des calculs. Cela permet d’effectuer des importations et des exportations entre Azure SQL Database et Stockage Blob Azure.

Les opérations d’importation et d’exportation ne sont pas une sauvegarde de base de données physique traditionnelle, mais une sauvegarde logique de la base de données qui utilise un format BACPAC spécial. Le format BACPAC vous permet d’éviter d’avoir à utiliser un format physique qui peut varier entre les versions de Microsoft SQL Server, Azure SQL Database et Azure SQL Managed Instance.

Quelles peuvent être les causes d’un ralentissement du processus ?

Le service Import/Export d’Azure SQL Database fournit un nombre limité de machines virtuelles de calcul par région pour traiter les opérations d’importation et d’exportation. Les machines virtuelles de calcul sont hébergées par région afin d’éviter pour l’importation ou l’exportation tout délai et frais de bande passante entre les régions. Ainsi, si un trop grand nombre de requêtes sont effectuées simultanément dans la même région, le traitement des opérations risque d’être ralenti de façon notable. Le temps nécessaire pour exécuter les requêtes peut varier de quelques secondes à plusieurs heures.

En outre, lorsque le service d’importation/exportation effectue une sauvegarde logique de la base de données, le temps d’exécution dépend davantage du nombre d’objets de la base de données qu’une sauvegarde de base de données physique traditionnelle.

Notes

Une fois que les ressources sont attribuées et qu’une demande commence à être traitée, le service annule automatiquement la demande au bout de deux jours.

Solutions recommandées

Si vos exportations de base de données sont uniquement utilisées pour la récupération après une suppression accidentelle des données, toutes les éditions d’Azure SQL Database fournissent une fonctionnalité de restauration libre-service à partir des sauvegardes générées par le système. Toutefois, si vous avez besoin de ces exportations pour d’autres raisons et si vous avez besoin de performances d’importation/exportation beaucoup plus rapides ou plus ou moins prévisibles, nous vous recommandons les options suivantes :

• Procédez à une exportation vers un fichier BACPAC à l’aide de l’utilitaire SQLPackage.
• Exporter vers un fichier BACPAC à l’aide d’Azure Data Studio.
• Procédez à une exportation vers un fichier BACPAC à l’aide de SQL Server Management Studio (SSMS).
• Exécutez l’importation ou l’exportation BACPAC directement dans votre code à l’aide de l’API Microsoft SQL Server Data-Tier Application Framework (DacFx). Si vous souhaitez en savoir plus, veuillez consulter :
  • Exporter une application de la couche Données
  • Espace de noms Microsoft.SqlServer.Dac

Éléments à prendre en compte lorsque vous exportez ou importez une base de données

• Toutes les méthodes décrites dans cet article consomment des Unités de transaction de base de données (DTU) ou du quota UC, ce qui entraîne une limitation par le service Azure SQL Database. Vous pouvez afficher les statistiques DTU pour la base de données dans le portail Azure. Si la base de données atteint ses limites de ressources, mettez à niveau le niveau de service pour ajouter d’autres ressources.
• Dans l’idéal, vous devez exécuter des applications clientes (telles que l’utilitaire SqlPackage ou votre application DAC personnalisée) à partir d’une machine virtuelle dans la même région que votre base de données. Dans le cas contraire, vous risquez de rencontrer des problèmes de performances liés à la latence du réseau.
• L’exportation de tables volumineuses sans index cluster peut être très lente, voire entraîner un échec. Ce comportement se produit parce que la table ne peut pas être fractionnée et exportée en parallèle. Au lieu de cela, elle doit être exportée dans une transaction unique, ce qui entraîne un ralentissement des performances et une défaillance potentielle pendant l’exportation, en particulier pour les tables volumineuses.

Documents associés

Éléments à prendre en compte lors de l’exportation d’une base de données