Nouvel administrateur de base de données dans le cloud - Gérer Azure SQL Database après la migration

S’applique à :Azure SQL Database

La migration d’un environnement auto-managé vers une instance PaaS telle qu’Azure SQL Database peut être complexe. Cet article met en évidence les principales fonctionnalités d’Azure SQL Database pour les bases de données uniques et mises en pool, ce qui vous aide à maintenir les applications disponibles, performantes, sécurisées et résilientes.

Les principales caractéristiques d’Azure SQL Database sont les suivantes :

• Supervision de base de données avec le portail Azure
• Continuité d’activité et récupération d’urgence (BCDR)
• Sécurité et conformité
• Surveillance et maintenance de bases de données intelligentes
• Déplacement des données

Remarque

Microsoft Entra ID s'appelait Azure Active Directory (Azure AD) jusqu'à une date récente.

Analyser des bases de données au moyen du portail Azure

Pour obtenir les métriques Azure Monitor, y compris un ensemble de règles d’alerte recommandées, consultez Surveiller Azure SQL Database avec des métriques et des alertes. Pour plus d’informations sur les niveaux de service, consultez vue d’ensemble du modèle d’achat DTU et modèle d’achat vCore.

Vous pouvez configurer des alertes sur les mesures de performances. Sélectionnez le bouton Ajouter une alerte situé dans la fenêtre Métrique. Suivez l'assistant pour configurer votre alerte. Vous pouvez alerter si les métriques dépassent un certain seuil ou si la métrique tombe en dessous d’un certain seuil.

Par exemple, si vous pensez que la charge de travail dans votre base de données va augmenter, vous pouvez choisir de configurer une alerte par courrier électronique chaque fois que votre base de données atteint 80 % de n'importe quelle mesure de performances. Vous pouvez l’utiliser comme un avertissement anticipé pour déterminer le moment auquel vous devez passer à la taille de calcul supérieure.

Les métriques de performances peuvent également vous aider à déterminer si vous pouvez passer à une taille de calcul inférieure. Toutefois, prenez en considération les éventuels pics ou baisses de charges de travail avant de passer à une taille de calcul inférieure.

Continuité d’activité et récupération d’urgence (BCDR)

Les capacités de continuité d’activité et de récupération d’urgence vous permettent de poursuivre votre activité en cas de sinistre. Un sinistre peut correspondre à un événement au niveau de la base de données (par exemple, une personne supprime par erreur une table essentielle) ou à un événement au niveau du centre de données (catastrophe naturelle dans la région, un tsunami par exemple).

Comment créer et gérer des sauvegardes sur SQL Database ?

Azure SQL Database sauvegarde automatiquement les bases de données pour vous. La plateforme effectue une sauvegarde complète chaque semaine, une sauvegarde différentielle toutes les quelques heures et une sauvegarde de journal toutes les 5 minutes pour garantir l’efficacité de la récupération d’urgence et la perte de données est minimale. La première sauvegarde complète se produit dès que vous créez une base de données. Ces sauvegardes sont disponibles pour une certaine période appelée période de rétention, qui varie en fonction du niveau de service que vous choisissez. Vous pouvez effectuer une restauration à n’importe quel moment dans le temps au cours de cette période de rétention en utilisant la Récupération à un point précis dans le temps (PITR).

En outre, la fonctionnalité de sauvegardes de rétention à long terme vous permet de conserver vos fichiers de sauvegarde pendant jusqu’à 10 ans et de restaurer des données à partir de ces sauvegardes à tout moment au cours de cette période. Les sauvegardes de base de données sont conservées dans le stockage géorépliqué pour assurer la résilience de la catastrophe régionale. Vous pouvez également restaurer ces sauvegardes dans n’importe quelle région Azure à tout point dans le temps compris dans la période de rétention. Pour plus d’informations, consultez Continuité des activités dans Azure SQL Database.

Comment assurer la continuité de l’activité en cas de sinistre au niveau du centre de données ou d’une catastrophe régionale ?

Vos bases de données sont stockées dans un stockage géorépliqué, lors d’une catastrophe régionale, vous pouvez restaurer la sauvegarde dans une autre région Azure. Cette fonctionnalité s’appelle la géorestauration. Pour en savoir plus et connaître le calendrier des géorestaurations, consultez Géorestauration pour Azure SQL Database.

Pour les bases de données stratégiques, la base de données Azure SQL offre une géoréplication active, qui crée une copie secondaire géorépliquée de votre base de données d’origine dans une autre région. Par exemple, si votre base de données est initialement hébergée dans la région Azure USA Ouest et que vous souhaitez une résilience régionale en cas de catastrophe, créez une réplique géographique active de la base de données dans USA Ouest vers USA Est. Quand la catastrophe frappe la région USA Ouest, vous pouvez basculer vers la région USA Est.

Outre la géoréplication active, les groupes de basculement vous permettent de gérer la réplication et le basculement d’un groupe de bases de données. Vous pouvez créer un groupe de basculement qui contient plusieurs bases de données dans les mêmes régions ou différentes. Vous pouvez ensuite lancer un basculement de toutes les bases de données du groupe de basculement vers la région secondaire. Pour plus d’informations, consultez la vue d’ensemble des groupes de basculement et les meilleures pratiques (Azure SQL Database).

Pour obtenir une résilience pour les défaillances de centre de données ou de zone de disponibilité, assurez-vous que la redondance de zone est activée pour la base de données ou le pool élastique.

Surveillez activement votre application en cas de catastrophe et lancez un basculement vers la base de données secondaire. Vous pouvez créer jusqu’à quatre géoréplicas actifs de ce type dans les différentes régions Azure. Vous obtenez ainsi des résultats encore meilleurs. Vous pouvez également accéder à ces géoréplicas actifs secondaires en lecture seule. Cela permet de réduire la latence d’un scénario d’application géodistribué.

À quoi ressemble la récupération d’urgence avec SQL Database ?

La configuration et la gestion de la récupération d’urgence peuvent être effectuées en quelques étapes seulement dans la base de données Azure SQL lorsque vous utilisez la géoréplication active ou des groupes de basculement. Vous devez toujours surveiller l’application et sa base de données pour toute catastrophe régionale et basculer vers la région secondaire pour restaurer la continuité d’activité.

Pour plus d’informations, consultez La récupération d’urgence d’Azure SQL Database 101.

Sécurité et conformité

La sécurité au sein de SQL Database est disponible au niveau de la base de données et au niveau de la plateforme. Vous pouvez contrôler et fournir une sécurité optimale pour votre application comme suit :

• Identité et authentification (authentification et authentification SQL avec l'identité Microsoft Entra).
• Activité de surveillance (audit et détection des menaces).
• Protection des données réelles (chiffrement transparent des données [TDE] et Always Encrypted).
• Contrôle de l’accès aux données sensibles et privilégiées (sécurité au niveau des lignes et masquage des données dynamiques).

Microsoft Defender pour le cloud offre une gestion centralisée de la sécurité pour les charges de travail qui s’exécutent dans Azure, localement et dans d’autres clouds. Vous pouvez voir si une protection SQL Database essentielle, telle que l’audit et le chiffrement transparent des données [TDE] sont configurés sur toutes les ressources et créez des stratégies en fonction de vos propres besoins.

Quelles sont les méthodes d’authentification utilisateur proposées dans SQL Database ?

SQL Database propose deux méthodes d’authentification :

• Authentification Microsoft Entra
• Authentification SQL

L’authentification Windows est prise en charge. Microsoft Entra ID est un service centralisé de gestion des identités et des accès. Microsoft Entra ID fournit l’accès à l’authentification unique (SSO) au personnel de votre organisation. Cela signifie que les informations d’identification sont partagées entre les services Azure pour faciliter l’authentification.

Microsoft Entra ID prend en charge l’Authentification multifacteur et peut être facilement intégré avec Windows Server Active Directory. Cela permet également à SQL Database et Azure Synapse Analytics d'offrir une authentification multifacteur et des comptes d'utilisateurs invités dans un domaine Microsoft Entra. Si vous disposez déjà d’Active Directory localement, vous pouvez fédérer l’annuaire avec Microsoft Entra ID pour étendre votre annuaire à Azure.

L’authentification SQL prend uniquement en charge le nom d’utilisateur et le mot de passe pour authentifier les utilisateurs sur n’importe quelle base de données sur un serveur donné.

Si vous...	SQL Database / Azure Synapse Analytics
Avez utilisé AD avec SQL Server localement	Fédérer AD avec l’ID Microsoft Entra et utiliser l’authentification Microsoft Entra. La fédération vous permet d’utiliser l’authentification unique.
Besoin d’appliquer l’authentification multifacteur	Exiger l’authentification multifacteur en tant que stratégie via l’accès conditionnel et utiliser l’authentification multifacteur Microsoft Entra.
Sont connectés à Windows à l’aide de vos informations d’identification Microsoft Entra à partir d’un domaine fédéré	Utilisez l’authentification Microsoft Entra.
Sont connectés à Windows à l’aide d’informations d’identification d’un domaine non fédéré avec Azure	Utilisez l’authentification intégrée Microsoft Entra.
Avoir des services de niveau intermédiaire qui doivent se connecter à SQL Database ou Azure Synapse Analytics	Utilisez l’authentification intégrée Microsoft Entra.
Disposer d’une exigence technique pour utiliser l’authentification SQL	Utilisez l’authentification SQL

Comment limiter ou contrôler l’accès à la connectivité à ma base de données ?

Il existe plusieurs techniques à votre disposition pour garantir une organisation de connectivité optimale à votre application.

• Règles de pare-feu
• Points de terminaison de service de réseau virtuel
• IP réservées

Pare-feu

Par défaut, toutes les connexions aux bases de données à l’intérieur du serveur ne sont pas autorisées, sauf (éventuellement) les connexions entrantes à partir d’autres services Azure. Avec une règle de pare-feu, vous pouvez ouvrir l’accès à votre serveur uniquement aux entités (par exemple, un ordinateur développeur) que vous approuvez, en autorisant l’adresse IP de cet ordinateur via le pare-feu. Une règle vous permet également de spécifier une plage d'adresses IP auxquelles vous autorisez l'accès au serveur. Par exemple, vous pouvez rapidement ajouter toutes les adresses IP des ordinateurs de développeur de votre organisation en spécifiant une plage dans la page des paramètres du pare-feu.

Vous pouvez créer des règles de pare-feu au niveau du serveur ou de la base de données. Des règles de pare-feu IP de niveau serveur peuvent être créées à l’aide du portail Azure ou avec SSMS. Pour plus d’informations sur la définition d’une règle de pare-feu au niveau du serveur et au niveau de la base de données, consultez Créer des règles de pare-feu IP dans SQL Database.

Points de terminaison de service

Par défaut, votre base de données est configurée pour autoriser les services et ressources Azure à accéder à ce serveur, ce qui signifie que toute machine virtuelle dans Azure peut tenter de se connecter à votre base de données. Ces tentatives doivent quand même faire l’objet d’une authentification. Si vous ne souhaitez pas que votre base de données soit accessible par n'importe quelle adresse IP Azure, vous pouvez désactiver Autoriser les services et ressources Azure à accéder à ce serveur. En outre, vous pouvez configurer des points de terminaison de service de réseau virtuel.

Les points de terminaison de service vous permettent d’exposer vos ressources Azure critiques uniquement à votre propre réseau virtuel privé dans Azure. Cette option élimine l’accès public à vos ressources. Le trafic entre votre réseau virtuel et Azure reste sur le réseau principal Azure. Sans points de terminaison de service, vous obtenez un routage de paquets par mise en tunnel forcée. Votre réseau virtuel force le trafic Internet vers votre organisation et le trafic du service Azure à emprunter le même itinéraire. Avec les points de terminaison de service, vous pouvez l’optimiser, car les paquets circulent directement de votre réseau virtuel vers le service sur le réseau principal Azure.

IP réservées

Vous pouvez également provisionner des adresses IP réservées pour vos machines virtuelles, et ajouter ces adresses IP de machines virtuelles spécifiques dans les paramètres de pare-feu du serveur. En affectant des adresses IP réservées, vous évitez de devoir mettre à jour les règles du pare-feu en cas de changement des adresses IP.

Sur quel port dois-je me connecter à SQL Database ?

SQL Database communique sur le port 1433. Pour vous connecter à partir d’un réseau d’entreprise, vous devez ajouter une règle de trafic sortant dans les paramètres du pare-feu de votre organisation. En règle générale, évitez d’exposer le port 1433 hors de la limite Azure.

Comment surveiller et réglementer l’activité sur mon serveur et ma base de données dans SQL Database ?

Audit SQL Database

L’audit Azure SQL Database enregistre les événements de base de données et les écrit dans un fichier journal d’audit dans votre compte de stockage Azure. L’audit est particulièrement utile si vous envisagez d’obtenir un aperçu des violations potentielles de la sécurité et des stratégies, de maintenir la conformité réglementaire, etc. Il vous permet de définir et de configurer certaines catégories d’événements dont vous pensez avoir besoin d’audit et en fonction de ce que vous pouvez obtenir des rapports préconfigurés et un tableau de bord pour obtenir une vue d’ensemble des événements qui se produisent sur votre base de données.

Vous pouvez appliquer ces stratégies d’audit au niveau de la base de données ou au niveau du serveur. Pour plus d’informations, activez l’audit SQL Database.

Détection de menaces

Avec la détection des menaces, vous pouvez agir sur les violations de sécurité ou de stratégie découvertes par l’audit. Nul besoin d’être un expert en matière de sécurité pour traiter les menaces ou violations potentielles dans votre système. La détection des menaces a également des fonctionnalités intégrées telles que la détection d’injection SQL, qui est un moyen assez courant d’attaquer une application de base de données. La détection des menaces exécute plusieurs ensembles d’algorithmes qui détectent des vulnérabilités potentielles et des attaques par injection SQL, ainsi que des modèles d’accès anormal à la base de données (tels que l’accès à partir d’un emplacement inhabituel ou par un principal inconnu).

Les responsables sécurité ou les administrateurs désignés reçoivent une notification par e-mail si une menace est détectée sur la base de données. Chaque notification fournit des détails sur l’activité suspecte, ainsi que des recommandations sur l’analyse et l’atténuation de la menace. Pour savoir comment activer la détection des menaces, consultez Activer la détection des menaces.

Comment protéger mes données en général sur SQL Database ?

Le chiffrement constitue un puissant mécanisme de protection et de sécurisation de vos données sensibles contre les intrus. Vos données chiffrées ne sont d’aucune utilité à l’intrus s’il n’a pas la clé de déchiffrement. Par conséquent, le chiffrement ajoute une couche supplémentaire de protection aux couches de sécurité existantes intégrées à SQL Database. La protection de vos données dans SQL Database porte sur deux catégories de données :

• Vos données au repos dans les fichiers de données et de journaux
• Vos données en transit

Dans SQL Database, par défaut, vos données au repos dans les fichiers de données et de journaux sur le sous-système de stockage sont entièrement et toujours chiffrées via Chiffrement Transparent des Données (TDE). Vos sauvegardes sont également chiffrées. Avec TDE, il n’y a aucune modification requise côté application qui accède à ces données. Le chiffrement et le déchiffrement se produisent de manière transparente, d’où le nom.

Pour protéger vos données sensibles en cours et au repos, SQL Database fournit une fonctionnalité appelée Always Encrypted. Always Encrypted est une forme de chiffrement côté client qui chiffre les colonnes sensibles dans votre base de données (elles sont donc en texte chiffré aux administrateurs de base de données et aux utilisateurs non autorisés). Au départ, le serveur reçoit les données chiffrées.

La clé de chiffrement Always Encrypted est également stockée côté client, pour permettre uniquement aux clients autorisés de déchiffrer les colonnes sensibles. Les administrateurs du serveur et des données ne peuvent pas voir les données sensibles, car les clés de chiffrement sont stockées sur le client. Always Encrypted chiffre les colonnes sensibles de la table de bout en bout, de clients non autorisés au disque physique.

Always Encrypted prend en charge les comparaisons d’égalité, afin que les administrateurs de base de données puissent continuer à interroger des colonnes chiffrées dans le cadre de leurs commandes SQL. Vous pouvez utiliser Always Encrypted avec diverses options de magasin de clés, par exemple Azure Key Vault, le magasin de certificats Windows et les modules de sécurité matériels locaux.

Caractéristiques	Toujours Chiffré	Chiffrement transparent des données
Étendue de chiffrement	Bout en bout	Données au repos
Le serveur peut accéder aux données sensibles	Non	Oui, étant donné que le chiffrement concerne les données au repos
Opérations T-SQL autorisées	Comparaison d’égalité	Toute la surface d’exposition T-SQL est disponible
Modifications de l’application exigées pour utiliser la fonctionnalité	Minimales	Minimales
Granularité de chiffrement	Au niveau des colonnes	Au niveau de la base de données

Comment puis-je limiter l’accès aux données sensibles dans ma base de données ?

Chaque application a des données sensibles dans la base de données qui doivent être protégées pour qu'elles ne soient pas visibles par tout le monde. Certains employés de l’organisation ont besoin de consulter ces données, tandis que d’autres ne doivent pas être en mesure de les afficher. Dans ce cas, vos données sensibles doivent être masquées ou ne doivent pas être exposées du tout. SQL Database propose deux approches permettant d’empêcher les utilisateurs non autorisés d’afficher des données sensibles :

• Le masquage dynamique des données est une fonctionnalité de masquage des données qui vous permet de limiter l’exposition des données sensibles en la masquant aux utilisateurs non privilégiés sur la couche application. Vous définissez une règle de masquage qui peut créer un modèle de masquage (par exemple, pour afficher uniquement les quatre derniers chiffres d’un SSN d’ID national : XXX-XX-0000 et masquer la plupart d’entre elles avec le X caractère) et identifier les utilisateurs à exclure de la règle de masquage. Le masquage se produit à la volée et il existe diverses fonctions de masquage disponibles pour diverses catégories de données. Le masquage dynamique des données vous permet de détecter automatiquement les données sensibles dans votre base de données et de leur appliquer des masques.

• La sécurité au niveau des lignes vous permet de contrôler l’accès au niveau des lignes. Cela signifie que certaines lignes d’une table de base de données sont masquées en fonction de l’utilisateur qui exécute la requête (par exemple, en fonction de son appartenance à un groupe ou d’un contexte d’exécution). La restriction d’accès s’effectue sur la couche Base de données au lieu de la couche Application, ce qui simplifie votre logique d’application. Vous commencez par créer un prédicat de filtre, lequel permet de filtrer les lignes à ne pas exposer, puis vous créez la stratégie de sécurité pour définir qui a accès à ces lignes. Enfin, l’utilisateur final exécute sa requête et, en fonction de ses privilèges, il peut afficher ces lignes à accès restreint ou il ne les voit pas du tout.

Comment gérer les clés de chiffrement dans le cloud ?

Il existe des options de gestion des clés pour Always Encrypted (chiffrement côté client) et transparent des données (chiffrement au repos). Il est recommandé de faire tourner régulièrement les clés de chiffrement. La fréquence de rotation doit respecter à la fois la réglementation et les exigences de conformité de votre organisation interne.

Chiffrement transparent des données (TDE)

il existe une hiérarchie à deux clés dans TDE. Les données de chaque base de données utilisateur sont chiffrées par une clé de chiffrement de base de données AES-256 (DEK) symétrique spécifique à la base de données, qui est à son tour chiffrée par une clé principale RSA 2048 asymétrique spécifique au serveur. La clé principale peut être gérée de plusieurs façons :

• Automatiquement par Azure SQL Database
• Ou en utilisant Azure Key Vault comme magasin de clés

Par défaut, la clé principale pour TDE est gérée par Azure SQL Database. Si votre organisation souhaite contrôler la clé principale, vous pouvez utiliser Azure Key Vault comme magasin de clés. Avec Azure Key Vault, votre organisation contrôle le provisionnement, la rotation et les autorisations spécifiques aux clés. La rotation ou le changement de type d’une clé principale TDE demande peu de temps, car il suffit de rechiffrer la clé de chiffrement de base de données. Dans les organisations qui appliquent une séparation des rôles entre la gestion de la sécurité et celle des données, l’administrateur de la sécurité peut provisionner le matériel de clé pour la clé principale TDE dans Azure Key Vault, et fournir à l’administrateur de base de données un identificateur de clé Azure Key Vault pour le chiffrement au repos sur un serveur. Key Vault a été conçu de façon que Microsoft ne puisse pas voir ni extraire des clés de chiffrement. Vous bénéficiez également d’une gestion centralisée des clés pour votre organisation.

Toujours Chiffré

Il existe aussi une hiérarchie à deux clés dans Always Encrypted : une colonne de données sensibles est chiffrée par une clé de chiffrement de colonne AES 256 (CEK), qui est à son tour chiffrée par une clé principale de colonne (CMK). Les pilotes clients fournis pour Always Encrypted n’ont pas de limites concernant la longueur des clés principales de colonne. La valeur chiffrée de la clé de chiffrement de colonne est stockée dans la base de données, et la clé principale de colonne est stockée dans un magasin de clés approuvé, par exemple le magasin de certificats Windows, Azure Key Vault ou un module de sécurité matériel.

• Vous pouvez changer la clé de chiffrement de colonne et la clé principale de colonne.

• La rotation de la clé de chiffrement de colonne est une opération qui dépend de la taille des données ; elle peut prendre beaucoup de temps selon la taille des tables qui contiennent les colonnes chiffrées. Ainsi, il est préférable de planifier les rotations de clés de chiffrement de colonne en conséquence.

• La rotation des clés principales de colonne, quant à elle, n’interfère pas avec les performances des bases de données. Vous pouvez l’effectuer avec des rôles distincts.

Le diagramme suivant montre les options de stockage de clés pour les clés maîtresses de colonne dans Always Encrypted :

Comment puis-je optimiser et sécuriser le trafic entre mon organisation et SQL Database ?

Le trafic réseau entre votre organisation et SQL Database est généralement routé sur le réseau public. Toutefois, vous pouvez optimiser ce chemin et le rendre plus sécurisé avec Azure ExpressRoute. ExpressRoute étend votre réseau d’entreprise à la plateforme Azure via une connexion privée. Ainsi, vous ne passez pas par l’Internet public. Vous bénéficiez également d’une sécurité, d’une fiabilité et d’une optimisation du routage plus élevées qui se traduisent par des latences réseau inférieures et des vitesses plus rapides que celles que vous rencontrez normalement sur l’Internet public. Si vous envisagez de transférer un bloc important de données entre votre organisation et Azure, l’utilisation d’ExpressRoute peut permettre de réduire vos coûts. Vous avez trois modèles de connectivité différents à votre disposition pour la connexion entre votre organisation et Azure :

• Colocation Cloud Exchange
• Connexion universelle
• Connexion point à point

ExpressRoute vous permet également d'augmenter jusqu'à 2 fois la limite de bande passante que vous achetez, et ce, sans frais supplémentaires. Vous pouvez également configurer une connectivité interrégion à l’aide d’ExpressRoute. Pour obtenir la liste des fournisseurs de connectivité ExpressRoute, consultez les partenaires ExpressRoute et les emplacements de peering. Les articles suivants décrivent Express Route de façon plus approfondie :

• Présentation d’ExpressRoute
• Composants requis
• Flux de travail

SQL Database est-il conforme aux exigences réglementaires et comment cela aide-t-il à la conformité de mon organisation ?

SQL Database est conforme à un certain nombre d’exigences réglementaires. Pour afficher le dernier ensemble de compliancies rencontrées par SQL Database, visitez le Centre de gestion de la confidentialité Microsoft et passez en revue les compliancies importantes pour votre organisation afin de voir si SQL Database est inclus dans les services Azure conformes. Bien que SQL Database soit certifié en tant que service conforme, il contribue à la conformité du service de votre organisation, mais ne le garantit pas automatiquement.

Surveillance et maintenance de bases de données intelligentes après la migration

Une fois que vous avez migré votre base de données vers SQL Database, vous devez surveiller votre base de données (par exemple, vérifier l’utilisation des ressources ou les vérifications DBCC) et effectuer une maintenance régulière (par exemple, reconstruire ou réorganiser des index, des statistiques, etc.). SQL Database utilise les tendances historiques et les métriques et statistiques enregistrées pour vous aider de manière proactive à surveiller et à gérer votre base de données, afin que votre application s’exécute de manière optimale toujours. Dans certains cas, Azure SQL Database peut effectuer automatiquement des tâches de maintenance en fonction de vos paramètres de configuration. La surveillance de votre base de données revêt trois facettes dans SQL Database :

• Supervision et optimisation des performances
• Optimisation de la sécurité
• Optimisation des coûts

Supervision et optimisation des performances

Avec Query Performance Insights, vous pouvez obtenir des recommandations personnalisées pour votre charge de travail de base de données afin que vos applications puissent continuer à s’exécuter à un niveau optimal. Vous pouvez également le configurer de sorte que ces recommandations s’appliquent automatiquement et que vous n’ayez pas à vous soucier d’effectuer d’autres tâches de maintenance. Avec SQL Database Advisor, vous pouvez implémenter automatiquement des recommandations d’index en fonction de votre charge de travail. C’est ce qu’on appelle le réglage automatique. Les recommandations évoluent au même rythme que la charge de travail de votre application pour fournir des suggestions pertinentes. Vous avez également la possibilité de passer manuellement en revue ces recommandations et de les appliquer à votre convenance.

Optimisation de la sécurité

SQL Database fournit des recommandations de sécurité pratiques pour vous aider à sécuriser vos données. De plus, la détection des menaces vous permet d'identifier et d'analyser les activités de base de données suspectes qui constituent une menace potentielle pour la base de données. L'évaluation des vulnérabilités est un service d'analyse et de rapport de base de données qui vous permet de surveiller l'état de sécurité de vos bases de données à grande échelle, et d'identifier les risques de sécurité et les dérives par rapport à la base de référence que vous avez définie pour la sécurité. Après chaque analyse, une liste personnalisée d’étapes actionnables et de scripts de correction est fournie et un rapport d’évaluation qui peut être utilisé pour répondre aux exigences de conformité.

Avec Microsoft Defender pour le cloud, vous identifiez les recommandations en matière de sécurité dans le tableau de bord, et les appliquez rapidement.

Optimisation des coûts

la plateforme Azure SQL analyse l’historique d’utilisation de toutes les bases de données d’un serveur pour évaluer et vous recommander des options d’optimisation des coûts. Cette analyse prend généralement quelques semaines d’activité pour générer des recommandations actionnables.

Vous pouvez recevoir des notifications par bannière pour des recommandations de coût dans votre serveur Azure SQL. Pour plus d’informations, consultez Les pools élastiques vous aident à gérer et mettre à l’échelle plusieurs bases de données dans Azure SQL Database et planifier et gérer les coûts pour Azure SQL Database.

Comment surveiller les performances et l’utilisation des ressources dans SQL Database ?

Vous pouvez surveiller les performances et l’utilisation des ressources dans SQL Database à l’aide des méthodes suivantes :

Observateur de base de données

L’observateur de base de données collecte des données de surveillance de charge de travail détaillées pour vous donner une vue détaillée des performances, de la configuration et de l’intégrité de la base de données. Les tableaux de bord dans le Portail Azure fournissent une vue à volet unique de votre patrimoine Azure SQL et une vue détaillée de chaque ressource surveillée. Les données sont collectées dans un magasin de données central au sein de votre abonnement Azure. Vous pouvez interroger, analyser, exporter, visualiser des données collectées et les intégrer à des systèmes en aval.

Si vous souhaitez en savoir plus sur l’observateur de base de données, consultez les articles suivants :

• Surveiller les charges de travail Azure SQL avec l’observateur de base de données (aperçu)
• Démarrage rapide : Créer un observateur pour surveiller Azure SQL (préversion)
• Créer et configurer un surveillant (aperçu)
• Collection de données et jeux de données de l’observateur de base de données (aperçu)
• Analyser les données de surveillance de l’observateur de base de données (aperçu)
• FAQ au sujet de l’observateur de base de données

Portail Azure

Le portail Azure montre l’utilisation d’une base de données lorsque vous la sélectionnez et que vous sélectionnez le graphique du volet Vue d’ensemble. Vous pouvez modifier le graphique pour afficher plusieurs métriques, notamment le pourcentage d’UC, le pourcentage de DTU, le pourcentage d’E/S de données, le pourcentage de sessions et le pourcentage de taille de base de données.

À partir de ce graphique, vous pouvez également configurer des alertes par ressource. Ces alertes vous permettent de réagir à certaines situations spécifiques aux ressources par l’envoi d’un e-mail, d’écrire sur un point de terminaison HTTPS/HTTP ou d’effectuer une action. Pour plus d’informations, consultez Créer des alertes pour Azure SQL Database et Azure Synapse Analytics à l’aide du portail Azure.

Vues de gestion dynamique (DMV)

vous pouvez interroger la vue de gestion dynamique sys.dm_db_resource_stats pour retourner l’historique des statistiques de consommation des ressources de la dernière heure, et la vue de catalogue système sys.resource_stats pour retourner l’historique des 14 derniers jours.

Analyse des performances des requêtes

Query Performance Insight vous permet de voir l’historique des requêtes les plus consommatrices de ressources et des requêtes les plus longues pour une base de données spécifique. Vous pouvez rapidement identifier les TOP requêtes en fonction de l’utilisation des ressources, de la durée et de la fréquence d’exécution. Vous pouvez effectuer le suivi des requêtes et détecter une régression. Cette fonctionnalité nécessite l’activation du Magasin des requêtes pour la base de données.

Je remarque des problèmes de performances : Comment ma méthodologie de résolution des problèmes sql Database diffère-t-elle de SQL Server ?

Une partie majeure des techniques de résolution des problèmes que vous utiliseriez pour diagnostiquer les problèmes de performances des requêtes et des bases de données restent les mêmes : le même moteur de base de données alimente le cloud. Azure SQL Database peut vous aider à résoudre et diagnostiquer les problèmes de performances encore plus facilement. Il peut également effectuer certaines de ces actions correctives en votre nom et, dans certains cas, les corriger de manière proactive automatique.

Votre approche pour résoudre les problèmes de performances peut considérablement bénéficier en utilisant des fonctionnalités intelligentes telles que Query Performance Insight (QPI) et Database Advisor conjointement, et ainsi la différence de méthodologie diffère de ce point de vue - vous n’avez plus besoin de faire le travail manuel de broyer les détails essentiels qui peuvent vous aider à résoudre le problème à portée de main. La plateforme fait le travail difficile à votre place. La fonctionnalité QPI en est l’exemple. En effet, elle vous permet d’explorer jusqu’au niveau de la requête et d’examiner les tendances historiques pour déterminer à quel moment précis la requête a régressé. L’Assistant Base de données vous fournit des recommandations sur les éléments qui peuvent vous aider à améliorer vos performances globales en général, telles que les index manquants, la suppression d’index, la paramétrage de vos requêtes, etc.

Avec la résolution des problèmes de performance, il est important de déterminer si c’est uniquement l’application ou aussi la base de données qui l’accompagne, qui affectent les performances de votre application. Le problème de performance se trouve souvent dans la couche Application. Il peut être lié à l’architecture ou au modèle d’accès aux données. Par exemple, considérez que vous disposez d’une application chatteuse sensible à la latence réseau. Dans ce cas, votre application souffre parce qu’il y aurait beaucoup de courtes requêtes qui s'échangent abondamment entre l'application et le serveur, et sur un réseau congestionné, ces allers-retours s'accumulent rapidement. Pour améliorer les performances dans ce cas, vous pouvez utiliser des requêtes Batch, ce qui permet de réduire la latence des allers-retours et d’améliorer les performances de votre application.

De plus, si vous constatez une dégradation des performances globales de votre base de données, vous pouvez surveiller les vues de gestion dynamique sys.dm_db_resource_stats et sys.resource_stats pour comprendre comment sont consommées l’UC, les E/S et la mémoire. Vos performances peuvent être affectées si votre base de données est dépourvue de ressources. Vous devrez peut-être modifier la taille de calcul et/ou le niveau de service en fonction des demandes croissantes et de réduction des charges de travail.

Pour obtenir un ensemble complet de recommandations pour le réglage des problèmes de performances, consultez Régler votre base de données.

Comment m’assurer que j’utilise le niveau de service et la taille de calcul appropriés ?

SQL Database propose deux modèles d’achat différents : l’ancien modèle DTU et le modèle d’achat vCore, plus adaptable. Pour plus d’informations, consultez Comparer les modèles d’achat vCore et DTU d’Azure SQL Database.

Vous pouvez surveiller votre consommation de ressources de requête et de base de données dans l’un ou l’autre modèle d’achat. Pour plus d’informations, consultez Surveiller et régler les performances. Si vous trouvez que vos requêtes ou vos bases de données s’approchent constamment des limites, passez à une taille de calcul supérieure. De même, si vous ne semblez pas utiliser les ressources autant pendant les heures de pointe, envisagez de réduire la taille de calcul actuelle. Vous pouvez envisager d’utiliser Azure Automation pour mettre à l’échelle vos bases de données SQL en suivant une planification.

Si vous utilisez un modèle d’application SaaS ou un scénario de consolidation de bases de données, vous pouvez utiliser un pool élastique pour optimiser les coûts. Un pool élastique est un excellent moyen pour consolider des bases de données et optimiser les coûts. Pour plus d’informations sur la gestion de plusieurs bases de données à l’aide d’un pool élastique, consultez Gérer les pools et les bases de données.

À quelle fréquence dois-je exécuter des vérifications d’intégrité de la base de données pour ma base de données ?

SQL Database peut gérer automatiquement certaines classes d’altération des données et sans perte de données. Ces techniques intégrées sont utilisées par le service lorsque le besoin se produit. Vos sauvegardes de base de données sur le service sont régulièrement testées en les restaurant et en exécutant DBCC CHECKDB dessus. SQL Database traite les problèmes de façon proactive le cas échéant.

La réparation automatique des pages est utilisée pour résoudre les pages endommagées ou ayant des problèmes d’intégrité des données. Les pages de base de données sont toujours vérifiées avec le paramètre par défaut CHECKSUM qui vérifie l’intégrité de la page. SQL Database surveille et examine de manière proactive l’intégrité des données de votre base de données et résout les problèmes lors de leur apparition. Vous pouvez éventuellement exécuter vos propres vérifications d’intégrité en fonction des besoins. Pour plus d’informations, consultez Intégrité des données dans SQL Database.

Mouvement des données après la migration

Comment exporter et importer des données en tant que fichiers BACPAC à partir de SQL Database à l’aide du portail Azure ?

• Exportation : vous pouvez exporter votre base de données dans Azure SQL Database en tant que fichier BACPAC à partir du portail Azure :

  

• Importation : vous pouvez également importer des données en tant que fichier BACPAC dans votre base de données dans Azure SQL Database à l’aide du portail Azure :

  

Comment synchroniser des données entre SQL Database et SQL Server ?

Il existe plusieurs méthodes :

• Synchronisation des données : cette fonctionnalité vous permet de synchroniser les données bidirectionnellement entre plusieurs bases de données SQL Server et SQL Database. Pour synchroniser des bases de données SQL Server, vous devez installer et configurer l'agent de synchronisation sur un ordinateur local ou une machine virtuelle, et ouvrir le port TCP sortant 1433.

• Réplication des transactions : avec la réplication des transactions, vous pouvez synchroniser vos données d’une base de données SQL Server vers Azure SQL Database avec l’instance SQL Server en tant qu’éditeur et Azure SQL Database en tant qu’abonné. Pour l’instant, seule cette configuration est prise en charge. Pour plus d’informations sur la migration de vos données d’une base de données SQL Server vers Azure SQL avec un temps d’arrêt minimal, consultez Utiliser la réplication des transactions

Contenu connexe

• Surveillance et réglage des performances dans Azure SQL Database et Azure SQL Managed Instance