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
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é.
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.
Si votre région est prise en charge, effectuez la mise à niveau via le portail Azure.
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
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).
Attendez-vous à quelques minutes de temps d’arrêt.
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
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é.
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é.
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.
Sélectionnez Mettre à niveau.
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.
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
- Connectez-vous au portail Azure.
- Accédez au pool SQL dédié (anciennement SQL DW) pour lequel vous voulez créer un point de restauration.
- Dans la barre d’outils de la page Vue d’ensemble, sélectionnez + Nouveau point de restauration.
- Spécifiez un nom pour votre point de restauration.
Restaurer une base de données active ou interrompue à l’aide du portail Azure
Connectez-vous au portail Azure.
Accédez au pool SQL dédié (anciennement SQL DW) à partir duquel vous voulez effectuer la restauration.
Dans la barre d’outils de la section Vue d’ensemble, sélectionnez Restaurer.
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.
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.
- Ouvrez Windows PowerShell.
- Connectez-vous à votre compte Azure et répertoriez tous les abonnements associés à votre compte.
- Sélectionnez l’abonnement contenant la base de données à restaurer.
- Obtenez la base de données à récupérer.
- Créez la demande de récupération de la base de données, en indiquant un ServiceObjectiveName Gen2.
- 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.