Nouveau DBA dans le cloud : Gestion de Azure SQL Database après 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

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 cinq minutes afin de garantir l’efficacité de la reprise après sinistre et le minimum de la perte de données. La première sauvegarde complète se produit dès que vous créez une base de données. Vous pouvez accéder à ces sauvegardes pendant une certaine période appelée période de rétention, qui varie selon le niveau de service que vous choisissez. Vous pouvez restaurer à n’importe quel moment de cette période de conservation en utilisant la récupération à un moment donné (PITR).

De plus, la fonction de sauvegardes de rétention à long terme vous permet de conserver vos fichiers de sauvegarde jusqu’à 10 ans et de restaurer les données de ces sauvegardes à tout moment durant cette période. Azure conserve les sauvegardes de bases de données dans un stockage géorépliqué afin d’assurer une résilience face aux catastrophes régionales. Vous pouvez également restaurer ces sauvegardes dans n’importe quelle région Azure à tout moment pendant 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 ?

Stockez vos sauvegardes de base de données dans un stockage géo-répliqué pour vous assurer que, lors d’une catastrophe régionale, vous puissiez restaurer la sauvegarde dans une autre région Azure. Cette fonctionnalité s’appelle la restauration géographique. 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éo-réplication active, les groupes de basculement vous aident à gérer la réplication et le basculement d’un groupe de bases de données. Vous pouvez créer un groupe de basculement contenant plusieurs bases de données situées dans une même région ou dans des régions différentes. Vous pouvez ensuite initier 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 afin de détecter toute catastrophe et déclenchez un basculement vers le 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éo-répliques secondaires actives pour un accès en lecture seule, ce qui aide à réduire la latence dans un scénario d’application géo-distribuée.

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

Vous pouvez configurer votre stratégie de reprise d’activité après sinistre en seulement quelques étapes dans Azure SQL Database 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é

Azure SQL Database assure la sécurité à la fois au niveau de la base de données et au niveau de la plateforme. Vous pouvez contrôler et fournir une sécurité optimale à votre application en utilisant les fonctionnalités suivantes :

• Identité et authentification (authentification SQL et authentification avec Microsoft Entra ID).
• 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 ligne et masquage dynamique des données).

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 méthodes d’authentification utilisateur SQL Database propose-t-il ?

SQL Database propose deux méthodes d’authentification :

• Authentification Microsoft Entra
• Authentification SQL

L’authentification Windows n’est pas 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 identifiants sont partagés entre les services Azure pour faciliter l’authentification.

Microsoft Entra ID prend en charge l’authentification multifactorielle et peut facilement être intégré à Microsoft Entra Connect Sync. Cette intégration permet également à Azure SQL Database d’offrir une authentification multifacteur et des comptes utilisateurs invités au sein d’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é.

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

Pour organiser la connectivité de votre application, utilisez les techniques suivantes :

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

Pare-feu

Par défaut, le serveur SQL logique interdit toutes les connexions aux bases de données, sauf (optionnellement) les connexions provenant d’autres services Azure. En utilisant une règle de pare-feu, vous pouvez n’ouvrir l’accès à votre serveur qu’aux entités (par exemple, une machine développeur) que vous approuvez en autorisant l’adresse IP de cet ordinateur à passer par le pare-feu. Vous pouvez également spécifier une plage d’IP pour permettre l’accès au serveur. Par exemple, vous pouvez ajouter les adresses IP des machines développeurs dans votre organisation en même temps 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. Vous pouvez créer des règles de pare-feu IP au niveau serveur en utilisant le portail Azure ou en utilisant 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 permettre aux services et ressources Azure d’accéder à ce serveur, ce qui signifie que toute machine virtuelle dans Azure pourrait 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. En utilisant des points de terminaison de service, les paquets circulent directement de votre réseau virtuel vers le service sur le réseau Azure backbone.

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 attribuant des adresses IP réservées, vous n’avez pas besoin de mettre à jour les règles du pare-feu en changeant d’adresses IP.

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

Azure SQL Database communique par le biais du port 1433. Pour vous connecter depuis un réseau d’entreprise, vous devez ajouter une règle sortante 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 de base de données SQL

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 souhaitez obtenir des informations sur les potentielles violations de sécurité et de politiques, maintenir la conformité réglementaire, et plus encore. Il fournit des rapports préconfigurés et un tableau de bord pour vous donner un aperçu des événements survenant dans votre base de données. Vous pouvez définir et configurer les catégories d’événements qui nécessitent un audit.

Vous pouvez appliquer ces politiques d’audit au niveau de la base de données ou au niveau serveur. Pour plus d’informations, voir Activer l’audit de base de données SQL.

Détection de menaces

En utilisant la détection de menaces, vous pouvez agir sur des violations de sécurité ou de politique découvertes par 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 dispose également de certaines fonctionnalités intégrées comme la détection par injection SQL, qui est une méthode courante 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 journaux et de données
• 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, depuis les clients non autorisés jusqu’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.

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

Chaque application contient des données sensibles dans la base de données que vous devez protéger contre la visibilité de tous. Certains membres du personnel de l’organisation doivent consulter ces données, mais d’autres ne devraient pas. Dans de tels cas, vous devez soit masquer vos données sensibles, soit ne pas les exposer du tout. SQL Database propose deux approches pour empêcher les utilisateurs non autorisés de consulter des données sensibles :

• Le masquage dynamique des données est une fonctionnalité de masquage que vous pouvez utiliser pour limiter l’exposition de données sensibles en les masquant aux utilisateurs non privilégiés. Vous définissez une règle de masquage qui crée un motif de masquage. Par exemple, vous ne pouvez afficher que les quatre derniers chiffres d’un numéro XXX-XX-0000 d’identification nationale et masquer le reste avec le X caractère. Avec le masquage dynamique des données, vous identifiez quels utilisateurs sont exclus de la règle de masquage et pouvez voir les données non masquées. Le masquage se fait en temps réel et diverses fonctions de masquage sont disponibles pour différentes catégories de données.

• La sécurité au niveau des lignes vous permet de contrôler l’accès au niveau des lignes. Cette fonctionnalité masque certaines lignes dans une table de base de données selon l’exécution de la requête par l’utilisateur (appartenance au groupe ou contexte d’exécution). La restriction d’accès se fait dans la base de données plutôt que dans une couche d’application, ce qui simplifie la logique de votre application. Vous commencez par créer un prédicat qui filtre les lignes non exposées. Ensuite, vous créez la politique de sécurité qui définit qui a accès à ces lignes. Enfin, l’utilisateur final lance sa requête et, selon le privilège de l’utilisateur, il voit soit ces lignes restreintes, soit ne peut pas les voir du tout.

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

Le chiffrement Always Encrypted (chiffrement côté client) et le chiffrement transparent des données (chiffrement au repos) offrent des options de clés gérées par le client . Faites pivoter régulièrement les clés de chiffrement. Choisissez une fréquence de rotation conforme aux réglementations internes et aux exigences de conformité de votre organisation.

Transparent Data Encryption (TDE)

TDE utilise une hiérarchie à deux clés. Les données de chaque base de données utilisateur sont chiffrées par une clé de chiffrement de base de données (DEK) symétrique AES-256, qui est chiffrée par une clé maîtresse RSA 2048 asymétrique unique 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, Azure SQL Database gère la clé maîtresse TDE. Si votre organisation souhaite contrôler la clé maîtresse, utilisez Azure Key Vault comme stockage 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. Pour les organisations séparant les rôles entre sécurité et gestion des données, un administrateur de la sécurité peut provisionner le matériel de clé pour la clé maîtresse TDE dans Azure Key Vault et fournir un identifiant de clé Azure Key Vault à l’administrateur de base de données pour l’utiliser 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é

Always Encrypted utilise également une hiérarchie à deux clés. Une colonne de données sensibles est chiffrée par une clé de chiffrement AES à 256 colonnes (CEK), qui est chiffrée par une clé maîtresse 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 CEK est stockée dans la base de données, et la CMK est stockée dans un magasin de clés de confiance, tel que le magasin de certificats Windows, Azure Key Vault ou un module matériel de sécurité.

• Faites tourner à la fois le CEK et le CMK.

• La rotation de la CEK est une opération dont la durée dépend du volume de données et peut prendre beaucoup de temps selon la taille des tables contenant les colonnes chiffrées. Planifiez les rotations CEK en conséquence.

• La rotation des CMK n’interfère pas avec la performance de la base de données, et peut se faire avec des rôles séparés.

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 la base de données SQL est généralement acheminé via le réseau public. Cependant, vous pouvez optimiser ce chemin et le rendre plus sécurisé en utilisant Azure ExpressRoute. ExpressRoute étend votre réseau d’entreprise vers la plateforme Azure via une connexion privée, contournant ainsi 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 prévoyez de transférer une part importante de données entre votre organisation et Azure, utiliser ExpressRoute peut vous apporter des avantages coûteux. Vous avez trois modèles de connectivité différents à votre disposition pour la connexion entre votre organisation et Azure :

• Colocation Cloud Exchange
• Connexion universelle
• 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 la connectivité inter-régions en utilisant ExpressRoute. Pour obtenir la liste des fournisseurs de connectivité ExpressRoute, consultez les partenaires ExpressRoute et les emplacements de peering. Les articles suivants décrivent ExpressRoute plus en détail :

• 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 ?

Azure SQL Database est conforme à un large éventail d’exigences réglementaires. Pour consulter le dernier ensemble de conformités que SQL Database respecte, rendez-vous dans le Microsoft Trust Center et examinez les conformités 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

Après avoir migré votre base de données vers SQL Database, surveillez votre base de données (par exemple, vérifiez l’utilisation des ressources ou vérifiez les DBCC) et effectuez 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

En utilisant 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 à fonctionner à 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. En utilisant SQL Database Advisor, vous pouvez automatiquement implémenter des recommandations d’index en fonction de votre charge de travail. Cette fonctionnalité s’appelle l’Auto-Tuning. 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é exploitables pour vous aider à sécuriser vos données. Il offre également une détection des menaces pour identifier et enquêter sur les activités suspectes de la base de données pouvant représenter une menace potentielle pour la base de données. L’évaluation des vulnérabilités est un service de numérisation et de reporting de bases de données que vous pouvez utiliser pour surveiller à grande échelle l’état de sécurité de vos bases de données et identifier les risques et les dérivations par rapport à une base de sécurité que vous définissez. Après chaque scan, il fournit une liste personnalisée d’étapes concrètes et de scripts de remédiation, ainsi qu’un rapport d’évaluation qui peut vous aider à respecter les exigences de conformité.

En utilisant Microsoft Defender for Cloud, vous pouvez identifier des recommandations de sécurité dans tous les domaines et les appliquer rapidement.

Optimisation des coûts

La plateforme Azure SQL analyse l’historique d’utilisation à travers les bases de données d’un serveur afin d’évaluer et de 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 en utilisant les 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 du watcher de base de données (version préliminaire)
• Analyser les données de surveillance de Database Watcher (aperçu)
• FAQ au sujet de l’observateur de base de données

Portail Azure

Le portail Azure affiche l'utilisation d'une base de données lorsque vous sélectionnez la base de données et sélectionnez le graphique dans le panneau Aperçu. 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épondre aux conditions des ressources par un e-mail, d’écrire sur un point de terminaison HTTPS/HTTP ou d’effectuer une action. Pour plus d’informations, voir Créer des alertes pour Azure SQL Database via le portail Azure.

vues de gestion dynamiques

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.

Aperçu 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 ?

La plupart des techniques de dépannage que vous utilisez pour diagnostiquer les problèmes de requête et de performance de base de données sont les mêmes que sur site avec SQL Server. Azure SQL Database utilise le même SQL Moteur de base de données. Cependant, les fonctionnalités d’Azure vous aident à dépanner et diagnostiquer les problèmes de performance 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 automatiquement.

Votre approche pour résoudre les problèmes de performance peut bénéficier significativement de l’utilisation de fonctionnalités intelligentes telles que Query Performance Insight (QPI) et Database Advisor. La différence de méthodologie est que vous n’avez plus besoin de faire le travail manuel de détailler les détails essentiels qui pourraient vous aider à résoudre le problème en question. La plateforme fait le travail difficile à votre place. Un exemple de ce travail est QPI. En utilisant QPI, vous pouvez aller jusqu’au niveau de la requête et examiner les tendances historiques pour déterminer quand exactement la requête a régressé. Le Conseiller en Base de Données vous propose des recommandations sur des éléments qui pourraient vous aider à améliorer vos performances globales en général, comme l’absence d’index, la suppression d’index, la paramétrisation de vos requêtes, et plus encore.

En dépannage des performances, il est important d’identifier si c’est uniquement l’application ou la base de données qui affecte la performance 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 car de nombreuses requêtes courtes circulent (« bavardes ») entre l’application et le serveur. 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 sys.dm_db_resource_stats et sys.resource_stats gestion dynamique pour comprendre la consommation CPU, E/S et 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 un ensemble complet de recommandations pour régler les problèmes de performance, voir Tune your database.

Comment puis-je m’assurer d’utiliser 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 constatez que vos bases de données fonctionnent régulièrement à forte utilisation, envisagez de passer à une taille de calcul plus élevée. De même, si vous n’utilisez pas autant les ressources pendant les heures de pointe, envisagez de réduire la taille de calcul actuelle. Vous pouvez envisager d’utiliser Azure Automation pour faire évoluer vos bases de données SQL selon un calendrier.

Si vous avez un modèle d’application SaaS ou un scénario de consolidation de base de données, envisagez d’utiliser un pool élastique pour l’optimisation des coûts. Un pool élastique est un excellent moyen d’assurer la consolidation des bases de données et l’optimisation des coûts. Pour plus d’informations sur la gestion de plusieurs bases de données en utilisant un pool élastique, voir Gérer les pools et 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. Le service utilise ces techniques intégrées lorsque le besoin se fait sentir. S’il y a des problèmes, SQL Database les traite de manière proactive. Comme couche de protection supplémentaire, vous pouvez choisir de tester la restauration des sauvegardes et de faire des vérifications d’intégrité. Pour plus d’informations, consultez Data Integrity in Azure SQL Database.

La réparation automatique des pages est utilisée pour corriger des pages corrompues ou présentant des problèmes d’intégrité des données. Le CHECKSUM paramètre vérifie toujours l’intégrité des pages de la base de données. Pour plus d’informations, consultez Intégrité des données dans SQL Database.

Mouvement des données après la migration

Comment puis-je exporter et importer des données sous forme de fichiers BACPAC depuis une base de données SQL en utilisant le 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 sous forme de fichier BACPAC dans votre base de données dans Azure SQL Database en utilisant le portail Azure :

  

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

Pour plus d’informations sur les alternatives à la synchronisation des données, voir Migrer vers des solutions alternatives.

Contenu connexe

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