Partager via


Optimiser les performances en mettant à niveau un pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics

Mettez à niveau votre pool SQL dédié (anciennement SQL DW) vers la dernière génération de l’architecture matérielle et de stockage Azure.

Pourquoi procéder à une mise à niveau ?

Vous pouvez maintenant effectuer une mise à niveau de manière fluide vers le niveau Gen2 optimisé pour le calcul du pool SQL dédié (anciennement SQL DW) dans le portail Azure pour les régions prises en charge. Si votre région ne prend pas en charge la mise à niveau automatique, vous pouvez passer à une région prise en charge ou attendre que la mise à niveau automatique soit disponible dans votre région. Effectuez la mise à niveau dès maintenant pour bénéficier de la dernière génération de matériel et de l’architecture de stockage améliorée d’Azure, y compris de performances plus rapides, d’une plus grande évolutivité et d’un stockage en colonnes illimité.

Important

Cette mise à niveau s’applique aux pools SQL dédiés de niveau Gen1 optimisés pour le calcul (anciennement SQL DW) dans les régions prises en charge.

Avant de commencer

  1. Vérifiez si votre région est prise en charge pour la migration GEN1 vers GEN2. Prenez note des dates de migration automatique. Pour éviter tout conflit avec le processus automatisé, planifiez votre migration manuelle avant la date de début du processus automatisé.

  2. Si vous vous trouvez dans une région qui n’est pas encore prise en charge, continuez à vérifier si votre région doit être ajoutée ou effectuer la mise à niveau en utilisant la restauration dans une région prise en charge.

  3. Si votre région est prise en charge, effectuez la mise à niveau via le portail Azure.

  4. Sélectionnez le niveau de performance suggéré pour un pool SQL dédié (anciennement SQL DW) en fonction de votre niveau de performance actuel sur le niveau Gen1 optimisé pour le calcul en utilisant le mappage ci-dessous :

    Niveau Gen1 optimisé pour le calcul Niveau Gen2 optimisé pour le calcul
    DW100 DW100c
    DW200 DW200c
    DW300 DW300c
    DW400 DW400c
    DW500 DW500c
    DW600 DW500c
    DW1000 DW1000c
    DW1200 DW1000c
    DW1500 DW1500c
    DW2000 DW2000c
    DW3000 DW3000c
    DW6000 DW6000c

Notes

Les niveaux de performance suggérés ne constituent pas une conversion directe. Par exemple, nous recommandons de passer du DW600 au DW500c.

Mise à niveau dans une région prise en charge à l’aide du Portail Azure

  • La migration de Gen1 vers Gen2 via le portail Azure est définitive. Il est impossible de revenir à Gen1.
  • Le pool SQL dédié (anciennement SQL DW) doit être en cours d’exécution pour migrer vers Gen2.

Avant de commencer

Notes

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

  • Connectez-vous au portail Azure.
  • Vérifiez que le pool SQL dédié (anciennement SQL DW) est en cours d’exécution, ce qui est obligatoire pour migrer vers Gen2.

Commandes de mise à niveau PowerShell

  1. Si le pool SQL dédié (anciennement SQL DW) de niveau Gen1 optimisé pour le calcul à mettre à niveau est suspendu, reprenez l’exécution du pool SQL dédié (anciennement SQL DW).

  2. Attendez-vous à quelques minutes de temps d’arrêt.

  3. Identifiez les références de code à des niveaux de performances Gen1 optimisé pour le calcul et modifiez-les à leur niveau de performances Gen2 optimisé pour le calcul équivalent. Les deux exemples ci-dessous illustrent où vous devez mettre à jour les références de code avant la mise à niveau :

    Commande PowerShell Gen1 d’origine :

    Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -DatabaseName "mySampleDataWarehouse" -ServerName "mynewserver-20171113" -RequestedServiceObjectiveName "DW300"
    

    Remplacée par :

    Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -DatabaseName "mySampleDataWarehouse" -ServerName "mynewserver-20171113" -RequestedServiceObjectiveName "DW300c"
    

    Notes

    -RequestedServiceObjectiveName "DW300" est remplacé par - RequestedServiceObjectiveName "DW300c"

    Commande T-SQL Gen1 d’origine :

    ALTER DATABASE mySampleDataWarehouse MODIFY (SERVICE_OBJECTIVE = 'DW300') ;
    

    Remplacée par :

    ALTER DATABASE mySampleDataWarehouse MODIFY (SERVICE_OBJECTIVE = 'DW300c') ;
    

    Notes

    SERVICE_OBJECTIVE = 'DW300' est remplacé par SERVICE_OBJECTIVE = 'DW300c'

Lancer la mise à niveau

  1. Accédez à votre pool SQL dédié (anciennement SQL DW) Gen1 optimisé pour le calcul dans le portail Azure. Si le pool SQL dédié (anciennement SQL DW) de niveau Gen1 optimisé pour le calcul à mettre à niveau est suspendu, reprenez l’exécution du pool SQL dédié.

  2. Sous l’onglet Tâches, sélectionnez Mettre à niveau vers Gen2 :

    Remarque

    Si vous ne voyez pas la carte Mettre à niveau vers la 2e génération sous l’onglet Tâches, votre type d’abonnement est limité dans la région actuelle. Envoyez un ticket de support pour faire en sorte que votre abonnement soit approuvé.

  3. Vérifiez que l’exécution de votre charge de travail est terminée et arrêtée avant de mettre à niveau. Vous avez un temps d’arrêt de quelques minutes avant que votre pool SQL dédié (anciennement SQL DW) soit remis en ligne comme pool SQL dédié (anciennement SQL DW) de niveau Gen2 optimisé pour le calcul.

  4. Sélectionnez Mettre à niveau.

  5. Surveillez votre mise à niveau en vérifiant l’état dans le portail Azure. Vous verrez probablement une bannière de message qui indique « Cet entrepôt de données est mis à niveau vers Gen2 ».

    La première étape du processus de mise à niveau passe par l’opération de mise à l’échelle (« Mise à niveau - Hors connexion ») pendant laquelle toutes les sessions seront supprimées et les connexions fermées.

    La deuxième étape du processus de mise à niveau est la migration des données (« Mise à niveau - En ligne »). La migration des données est un processus en arrière-plan progressif en ligne. Ce processus déplace lentement les données en colonnes de l’ancienne architecture de stockage vers la nouvelle architecture de stockage, en utilisant un cache de disque SSD local. Pendant ce temps, votre pool SQL dédié (anciennement SQL DW) sera en ligne à des fins d’interrogation et de chargement. Vos données pourront être interrogées, qu’elles aient été migrées ou non. La migration des données se produit à des taux variables selon la taille de vos données, de votre niveau de performance et du nombre de vos segments de columnstore.

  6. Recommandation facultative : Une fois l’opération de mise à l’échelle est terminée, vous pouvez accélérer le processus de migration en arrière-plan. Vous pouvez forcer le déplacement des données en exécutant ALTER INDEX ... REBUILD sur toutes les tables columnstore primaires que vous interrogez sur une plus large classe de SLO et de ressources. Cette opération est en mode hors connexion. Elle dégrade ou bloque les autres requêtes, mais se termine plus vite par rapport au processus en arrière-plan progressif, dont l’exécution peut prendre plusieurs heures en fonction du nombre et de la taille de vos tables. Toutefois, la migration des données sera beaucoup plus rapide et vous pourrez tirer pleinement parti de la nouvelle architecture de stockage améliorée avec des groupes de lignes de haute qualité.

Notes

Alter Index Rebuild est une opération hors connexion et les tables ne seront pas disponibles tant que la reconstruction ne sera pas terminée.

La requête suivante génère les commandes ALTER INDEX ... REBUILD requises pour accélérer la migration des données :

SELECT 'ALTER INDEX [' + idx.NAME + '] ON ['
       + Schema_name(tbl.schema_id) + '].['
       + Object_name(idx.object_id) + '] REBUILD ' + ( CASE
                                                         WHEN (
                                                     (SELECT Count(*)
                                                      FROM   sys.partitions
                                                             part2
                                                      WHERE  part2.index_id
                                                             = idx.index_id
                                                             AND
                                                     idx.object_id =
                                                     part2.object_id)
                                                     > 1 ) THEN
              ' PARTITION = '
              + Cast(part.partition_number AS NVARCHAR(256))
              ELSE ''
                                                       END ) + '; SELECT ''[' +
              idx.NAME + '] ON [' + Schema_name(tbl.schema_id) + '].[' +
              Object_name(idx.object_id) + '] ' + (
              CASE
                WHEN ( (SELECT Count(*)
                        FROM   sys.partitions
                               part2
                        WHERE
                     part2.index_id =
                     idx.index_id
                     AND idx.object_id
                         = part2.object_id) > 1 ) THEN
              ' PARTITION = '
              + Cast(part.partition_number AS NVARCHAR(256))
              + ' completed'';'
              ELSE ' completed'';'
                                                    END )
FROM   sys.indexes idx
       INNER JOIN sys.tables tbl
               ON idx.object_id = tbl.object_id
       LEFT OUTER JOIN sys.partitions part
                    ON idx.index_id = part.index_id
                       AND idx.object_id = part.object_id
WHERE  idx.type_desc = 'CLUSTERED COLUMNSTORE';

Mettre à niveau à partir d’une région géographique Azure en utilisant la restauration via le portail Azure

Créer un point de restauration défini par l’utilisateur à l’aide du portail Azure

  1. Connectez-vous au portail Azure.
  2. Accédez au pool SQL dédié (anciennement SQL DW) pour lequel vous voulez créer un point de restauration.
  3. Dans la barre d’outils de la page Vue d’ensemble, sélectionnez + Nouveau point de restauration.
  4. Spécifiez un nom pour votre point de restauration.

Restaurer une base de données active ou interrompue à l’aide du portail Azure

  1. Connectez-vous au portail Azure.

  2. Accédez au pool SQL dédié (anciennement SQL DW) à partir duquel vous voulez effectuer la restauration.

  3. Dans la barre d’outils de la section Vue d’ensemble, sélectionnez Restaurer.

  4. Sélectionnez Points de restauration automatiques ou Points de restauration définis par l’utilisateur. Pour l’option Points de restauration définis par l’utilisateur, sélectionnez un point de restauration défini par l’utilisateur ou créez un point de restauration défini par l’utilisateur. Pour le serveur, sélectionnez Créer et choisissez un serveur dans une région géographique prise en charge par Gen2.

    Capture d’écran du portail Azure montrant les points de restauration à choisir.

Restaurer à partir d’une région géographique Azure à l’aide de PowerShell

Notes

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Pour récupérer une base de données, utilisez la cmdlet Restore-AzSqlDatabase.

Notes

Vous pouvez effectuer une géorestauration vers Gen2 ! Pour ce faire, spécifiez une valeur ServiceObjectiveName Gen2 (par exemple, DW1000c) comme paramètre facultatif.

  1. Ouvrez Windows PowerShell.
  2. Connectez-vous à votre compte Azure et répertoriez tous les abonnements associés à votre compte.
  3. Sélectionnez l’abonnement contenant la base de données à restaurer.
  4. Obtenez la base de données à récupérer.
  5. Créez la demande de récupération de la base de données, en indiquant un ServiceObjectiveName Gen2.
  6. Vérifiez l’état de la base de données affectée par la géo-restauration.
Connect-AzAccount
Get-AzSubscription
Select-AzSubscription -SubscriptionName "<Subscription_name>"

# Get the database you want to recover
$GeoBackup = Get-AzSqlDatabaseGeoBackup -ResourceGroupName "<YourResourceGroupName>" -ServerName "<YourServerName>" -DatabaseName "<YourDatabaseName>"

# Recover database
$GeoRestoredDatabase = Restore-AzSqlDatabase –FromGeoBackup -ResourceGroupName "<YourResourceGroupName>" -ServerName "<YourTargetServer>" -TargetDatabaseName "<NewDatabaseName>" –ResourceId $GeoBackup.ResourceID -ServiceObjectiveName "<YourTargetServiceLevel>" -RequestedServiceObjectiveName "DW300c"

# Verify that the geo-restored database is online
$GeoRestoredDatabase.status

Notes

Pour configurer votre base de données une fois la restauration terminée, consultez la page Configurer votre base de données après récupération.

La base de données récupérée sera compatible avec le chiffrement transparent des données si la base de données source l’est aussi.

Si vous rencontrez des problèmes avec votre pool SQL dédié, créez une demande de support et indiquez « Mise à niveau vers Gen2 » comme cause possible.

Votre pool SQL dédié (anciennement SQL DW) mis à niveau est en ligne. Pour tirer parti de l’architecture améliorée, découvrez les classes de ressources.

Étape suivante