Guide - DP-300 Microsoft Azure Database Administrator Associate

Une base de données SQL critique nécessite un SLA de 99,995 %, une HA redondante inter-zones et des capacités de scale-out en lecture.

Déployer Azure SQL Database en utilisant le niveau de service Business Critical avec la redondance de zone activée.

Pourquoi: Business Critical offre le SLA le plus élevé, utilise des SSD locaux pour une faible latence, et inclut des répliques secondaires lisibles intégrées sans coût supplémentaire. General Purpose a un SLA inférieur et aucune réplique en lecture intégrée.

Référence

Une base de données présente des schémas d'utilisation intermittents et imprévisibles avec de longues périodes d'inactivité. L'optimisation des coûts est critique.

Déployer Azure SQL Database en utilisant le niveau General Purpose avec le modèle de calcul Serverless.

Pourquoi: Serverless adapte automatiquement le calcul en fonction de la demande et peut se mettre en pause automatiquement pendant l'inactivité, ne facturant que le stockage. C'est plus rentable que le calcul Provisioned pour les charges de travail non continues.

Référence

Migration d'un SQL Server sur site qui repose fortement sur des fonctionnalités telles que SQL Server Agent, les requêtes inter-bases de données et Service Broker.

Migrer vers Azure SQL Managed Instance.

Pourquoi: Managed Instance offre une compatibilité proche de 100 % avec SQL Server sur site, préservant les fonctionnalités au niveau de l'instance non disponibles dans Azure SQL Database.

Référence

Une application nécessite un accès au niveau du système d'exploitation, un accès au système de fichiers (par exemple, pour Filestream) ou des fonctionnalités non prises en charge par les offres PaaS comme CLR avec EXTERNAL_ACCESS.

Déployer SQL Server sur une machine virtuelle Azure (IaaS).

Pourquoi: IaaS offre un contrôle total sur le système d'exploitation et l'instance SQL Server, offrant une compatibilité maximale avec les configurations sur site au prix d'une surcharge de gestion accrue.

Une base de données devrait dépasser 4 To, jusqu'à 100 To, et nécessite une mise à l'échelle rapide du stockage et des restaurations rapides.

Déployer Azure SQL Database en utilisant le niveau de service Hyperscale.

Pourquoi: Hyperscale est conçu pour les bases de données très volumineuses (VLDBs), offrant jusqu'à 100 To de stockage qui s'adapte automatiquement. Il utilise une architecture unique avec des serveurs de pages pour des restaurations de base de données rapides et à temps constant, quelle que soit la taille.

Référence

Une application SaaS héberge de nombreuses petites bases de données avec des schémas d'utilisation variés et imprévisibles. Il faut optimiser les coûts tout en fournissant des ressources partagées.

Regrouper les bases de données dans un pool élastique Azure SQL Database.

Pourquoi: Les pools élastiques permettent à plusieurs bases de données de partager un ensemble de ressources (eDTUs ou vCores) à un prix fixe, ce qui est plus rentable que de provisionner des bases de données individuelles lorsque l'utilisation n'est pas constante pour tous les tenants.

Déploiement d'une Azure SQL Managed Instance dans un réseau virtuel.

Créer un sous-réseau dédié avec une taille minimale de /27 (32 adresses) et le déléguer à Microsoft.Sql/managedInstances.

Pourquoi: Managed Instance nécessite un sous-réseau dédié et vide avec suffisamment d'adresses IP pour ses composants internes et sa mise à l'échelle future. Un /27 est la taille minimale prise en charge.

Migration d'une grande base de données SQL Server sur site critique vers Azure avec un temps d'arrêt minimal.

Utiliser le service Azure Database Migration Service (DMS) en mode de migration en ligne.

Pourquoi: La migration en ligne de DMS effectue un chargement initial puis utilise la synchronisation continue des données (log shipping) pour maintenir la cible synchronisée, permettant une fenêtre de basculement très courte.

Configuration du stockage pour un SQL Server sur une VM Azure hébergeant une charge de travail d'entrepôt de données avec de grandes lectures séquentielles.

Utiliser des SSD Premium. Configurer la mise en cache de l'hôte en lecture seule pour les fichiers de données et Aucune pour les fichiers journaux.

Pourquoi: La mise en cache en lecture seule est optimale pour les grandes lectures séquentielles courantes dans les entrepôts de données. La mise en cache doit être désactivée pour les fichiers journaux afin d'assurer la durabilité des écritures et de prévenir la perte de données.

Une politique de sécurité exige que toutes les connexions à la base de données soient chiffrées et que le certificat du serveur soit validé.

Définir la version minimale de TLS à 1.2 sur le serveur. Dans les chaînes de connexion client, utiliser `Encrypt=Strict`.

Pourquoi: La définition du TLS minimal sur le serveur empêche la négociation de protocole non sécurisée. `Encrypt=Strict` (TDS 8.0+) impose le chiffrement et la validation complète du certificat, prévenant les attaques de l'homme du milieu.

Les données sensibles dans des colonnes spécifiques (par exemple, SSN) doivent être chiffrées, mais l'application doit effectuer des recherches d'égalité et des jointures sur les données chiffrées.

Utiliser Always Encrypted avec un chiffrement déterministe pour les colonnes recherchables.

Pourquoi: Le chiffrement déterministe génère le même texte chiffré pour une valeur de texte en clair donnée, permettant des comparaisons d'égalité. Le chiffrement aléatoire offre une protection plus forte mais ne permet pas ces opérations.

Le chiffrement des données au repos est requis, mais l'organisation doit conserver un contrôle total sur les clés de chiffrement.

Activer le chiffrement transparent des données (TDE) avec des clés gérées par le client (BYOK) stockées dans Azure Key Vault.

Pourquoi: Cette configuration permet à l'organisation de gérer le cycle de vie des clés (rotation, révocation) dans son propre Key Vault, offrant un contrôle et répondant aux exigences de conformité en matière de propriété des clés.

Une Azure SQL Database ne doit être accessible qu'à partir d'un réseau virtuel Azure spécifique, avec un accès Internet public complètement bloqué.

Configurer un Private Endpoint pour le serveur SQL et définir "Deny public network access" sur Yes.

Pourquoi: Un Private Endpoint donne à la base de données SQL une IP privée au sein de votre VNet. La désactivation de l'accès public garantit que c'est le seul moyen de se connecter, offrant une isolation réseau complète.

Une application multi-tenant doit s'assurer que les utilisateurs ne peuvent voir que leurs propres données dans une table partagée.

Implémenter la sécurité au niveau des lignes (RLS) en créant un prédicat de sécurité (fonction à valeur de table inline) et une politique de sécurité qui l'applique à la table.

Pourquoi: RLS filtre les lignes de manière transparente en fonction du contexte de l'utilisateur (par exemple, USER_NAME() ou SESSION_CONTEXT), imposant l'isolation des données au niveau du moteur de base de données sans modifications de l'application.

Les administrateurs de base de données doivent gérer la base de données mais ne doivent pas pouvoir voir les données sensibles dans certaines colonnes.

Implémenter le masquage dynamique des données (DDM) sur les colonnes sensibles. Ne pas accorder la permission UNMASK aux DBA.

Pourquoi: DDM masque les données dans les résultats de requête pour les utilisateurs non privilégiés sans modifier les données stockées. Cela permet aux DBA d'effectuer leurs tâches tout en les empêchant de voir les informations sensibles réelles.

Une politique de sécurité exige la désactivation de l'authentification SQL pour imposer une gestion centralisée des identités et la MFA pour une base de données Azure SQL ou Managed Instance.

Définir un administrateur Azure AD pour le serveur et activer la propriété "Azure AD-only authentication".

Pourquoi: Ce paramètre désactive complètement le point de terminaison d'authentification SQL, forçant toutes les connexions à utiliser Azure AD. Il s'agit d'une étape critique pour appliquer les politiques d'authentification modernes.

Il est nécessaire de détecter et de recevoir des alertes pour les activités de base de données anormales, y compris les injections SQL potentielles, les schémas d'accès inhabituels et les attaques par force brute.

Activer Microsoft Defender pour SQL (anciennement Advanced Threat Protection).

Pourquoi: Defender pour SQL analyse les journaux de base de données pour les activités suspectes et génère des alertes de sécurité, fournissant une couche cruciale de détection des menaces au-delà des contrôles d'accès de base.

Les journaux d'audit pour une Azure SQL Database doivent être conservés pendant plusieurs années et être consultables pour les enquêtes de conformité et de sécurité.

Configurer l'audit Azure SQL pour envoyer les journaux à un espace de travail Log Analytics avec la rétention de données requise configurée.

Pourquoi: Log Analytics offre une rétention à long terme et de puissantes capacités de requête basées sur KQL, ce qui le rend supérieur au Stockage Blob pour les données d'audit consultables à long terme.

Fournir un accès temporaire, limité dans le temps et soumis à approbation à une base de données pour une équipe DevOps à des fins de dépannage.

Utiliser Azure AD Privileged Identity Management (PIM) pour gérer l'éligibilité à un groupe Azure AD ayant accès à la base de données.

Pourquoi: PIM fournit un accès juste-à-temps (JIT) qui est auditable, nécessite une justification et expire automatiquement, adhérant au principe du moindre privilège.

Un système nécessite un historique vérifiable et infalsifiable de toutes les modifications de données pour respecter une conformité réglementaire stricte.

Utiliser la fonctionnalité de registre (ledger) d'Azure SQL Database.

Pourquoi: Les tables de registre utilisent les concepts de blockchain pour lier cryptographiquement les modifications de données, créant un historique immuable qui peut être vérifié indépendamment. C'est plus fort que les tables temporelles, qui ne sont pas infalsifiables.

Une base de données subit une dégradation des performances. Il est nécessaire d'identifier les requêtes les plus gourmandes en ressources, de suivre les changements de plan et de trouver les régressions de performance.

Activer et utiliser Query Store.

Pourquoi: Query Store est l'enregistreur de données de vol intégré pour les performances des requêtes. Il capture automatiquement l'historique des requêtes, les plans et les statistiques d'attente, ce qui en fait l'outil principal pour diagnostiquer les problèmes de performance au fil du temps.

Référence

Une requête fonctionne bien parfois mais mal à d'autres moments en raison de problèmes de "parameter sniffing", où un plan d'exécution est optimisé pour une valeur de paramètre non représentative.

Utiliser Query Store pour identifier les différents plans et forcer le plan d'exécution qui fonctionne constamment bien.

Pourquoi: Le forçage de plan dans Query Store offre un moyen rapide et efficace de stabiliser les performances des requêtes problématiques sans modifier le code. Il remplace le choix de l'optimiseur par un plan connu et performant.

Améliorer les performances des requêtes sans modification du code en tirant parti de fonctionnalités telles que le mode batch sur rowstore, le retour d'informations sur l'octroi de mémoire et la compilation différée des variables de table.

Définir le niveau de compatibilité de la base de données à 150 (pour les fonctionnalités de SQL 2019) ou plus.

Pourquoi: L'ensemble de fonctionnalités Intelligent Query Processing (IQP) est activé par le niveau de compatibilité de la base de données. Le niveau 150+ active un large éventail d'améliorations de performance "sans modification de code" dans le processeur de requêtes.

L'équipe des opérations doit être avertie lorsque des indicateurs de performance clés, tels que le pourcentage d'utilisation du CPU ou les interblocages, dépassent un seuil défini.

Utiliser Azure Monitor pour créer des alertes de métriques (pour le CPU) et des alertes de journaux (pour les interblocages) qui déclenchent un groupe d'actions.

Pourquoi: Azure Monitor est la plateforme centralisée pour la surveillance et l'alerte sur les ressources Azure. Les groupes d'actions offrent des canaux de notification flexibles (e-mail, SMS, webhook, etc.).

Améliorer les performances d'écriture en identifiant et en supprimant les index qui ne sont utilisés par aucune requête de lecture.

Interroger la DMV `sys.dm_db_index_usage_stats`.

Pourquoi: Cette DMV suit l'utilisation de l'index (recherches, analyses, consultations) par rapport aux mises à jour. Les index avec des mises à jour élevées mais une utilisation nulle ou très faible sont les principaux candidats à la suppression, réduisant la charge de maintenance.

Il est nécessaire de capturer des informations détaillées sur les problèmes de blocage intermittents, y compris les instructions et les sessions impliquées dans la chaîne de blocage.

Configurer une session Extended Events qui capture l'événement `blocked_process_report`.

Pourquoi: Cet événement fournit un rapport XML détaillé des chaînes de blocage lorsque le `blocked process threshold` est dépassé, offrant des informations de diagnostic approfondies non disponibles dans les DMV.

Une base de données doit adapter automatiquement sa stratégie d'indexation aux changements de schémas de charge de travail sans intervention manuelle.

Activer l'option CREATE_INDEX dans le réglage automatique d'Azure SQL Database.

Pourquoi: Cette fonctionnalité permet à Azure d'analyser la charge de travail, d'identifier les index manquants à fort impact, de les créer et de valider leur bénéfice en termes de performances, automatisant ainsi une tâche clé du DBA.

Décharger les charges de travail de reporting gourmandes en lecture de la base de données OLTP primaire dans un niveau Business Critical ou Premium.

Modifier les chaînes de connexion en lecture seule de l'application pour inclure `ApplicationIntent=ReadOnly`.

Pourquoi: Ces niveaux incluent une réplique secondaire lisible intégrée et gratuite. La propriété `ApplicationIntent` dans la chaîne de connexion redirige automatiquement les connexions en lecture seule vers cette réplique, isolant les charges de travail de lecture.

Une grande table de faits dans un entrepôt de données est fréquemment utilisée pour des requêtes d'agrégation (SUM, COUNT, AVG) qui sont lentes.

Créer un index columnstore clusterisé sur la table de faits.

Pourquoi: Les index columnstore stockent les données dans un format colonnaire, offrant une très haute compression des données et permettant l'exécution en mode batch, ce qui accélère considérablement les requêtes analytiques gourmandes en agrégation et en analyse.

Une base de données subit une contention de blocage significative entre les requêtes de lecture (rapports) et les requêtes d'écriture (transactions).

Activer Read Committed Snapshot Isolation (RCSI) sur la base de données.

Pourquoi: RCSI utilise le versionnement des lignes, permettant aux lecteurs de voir la dernière version validée des données sans prendre de verrous partagés, éliminant ainsi les blocages des écrivains. Les écrivains ne bloquent pas les lecteurs.

Une application utilisant une base de données Serverless subit des temps de connexion initiaux lents après une période d'inactivité.

Diminuer le délai de pause automatique ou configurer une valeur minimale de vCore supérieure à zéro.

Pourquoi: Le délai est dû à la reprise de la base de données après un état de pause (démarrage à froid). La définition d'une valeur minimale de vCore empêche la base de données de se mettre complètement en pause, éliminant la latence de reprise au prix d'une certaine facturation continue du calcul.

Implémenter un pipeline CI/CD pour des déploiements de schémas de base de données automatisés, versionnés et reproductibles.

Utiliser un projet de base de données SQL (par exemple, dans Visual Studio) pour générer un fichier DACPAC. Utiliser les pipelines Azure DevOps pour déployer le DACPAC.

Pourquoi: C'est le modèle Infrastructure as Code (IaC) standard pour les schémas SQL. Le DACPAC est un modèle déclaratif du schéma, et les outils de déploiement gèrent la génération du script différentiel, assurant la cohérence.

Une Azure SQL Database doit être mise à l'échelle automatiquement en fonction d'un calendrier ou de seuils de métriques (par exemple, CPU élevé).

Utiliser un runbook Azure Automation (PowerShell) déclenché par un calendrier ou une alerte Azure Monitor.

Pourquoi: Azure SQL Database (niveau Provisioned) n'a pas d'autoscaling intégré. Azure Automation est l'outil standard pour orchestrer ce type de tâche opérationnelle à l'aide de scripts et de plannings.

Un script de maintenance (par exemple, la reconstruction d'index) doit être exécuté sur des centaines de bases de données Azure SQL.

Utiliser des Elastic Jobs.

Pourquoi: Elastic Jobs est un service PaaS conçu spécifiquement pour exécuter des travaux T-SQL sur un groupe cible de bases de données, gérant les informations d'identification, la planification et la journalisation de manière centralisée.

S'assurer que tous les nouveaux serveurs Azure SQL créés dans un abonnement ont une fonctionnalité spécifique, comme TDE ou l'audit, activée par défaut.

Créer une Azure Policy avec un effet `DeployIfNotExists` ou `Modify`.

Pourquoi: Azure Policy assure la gouvernance à grande échelle. L'effet `DeployIfNotExists` configure automatiquement le paramètre manquant lors de la création de la ressource, assurant la conformité sans intervention manuelle.

Planifier un script T-SQL récurrent ou une tâche de maintenance sur une Azure SQL Managed Instance.

Utiliser le SQL Server Agent intégré.

Pourquoi: Managed Instance inclut le SQL Server Agent complet, offrant les mêmes capacités de planification de tâches familières que SQL Server sur site sans avoir besoin d'un service d'automatisation externe.

Contrôler le moment où Azure effectue la maintenance planifiée sur une Azure SQL Database ou Managed Instance pour minimiser l'impact sur les opérations commerciales.

Configurer une fenêtre de maintenance pour la ressource.

Pourquoi: Cette fonctionnalité vous permet de sélectionner un créneau horaire prédéfini (par exemple, les week-ends) pour qu'Azure applique les mises à jour, vous offrant une prévisibilité sur la maintenance ayant un impact sur le service.

Une application nécessite un basculement automatique vers une région secondaire pour la reprise après sinistre, sans nécessiter de modifications des chaînes de connexion.

Configurer un groupe de basculement automatique entre les bases de données/instances primaires et secondaires.

Pourquoi: Les groupes de basculement fournissent des points de terminaison d'écouteur en lecture-écriture et en lecture seule. Ces points de terminaison redirigent automatiquement le trafic vers le serveur primaire/secondaire actuel après un basculement, rendant le processus transparent pour l'application.

Les sauvegardes de base de données doivent être conservées pendant de nombreuses années (par exemple, 7 à 10 ans) pour satisfaire aux exigences de conformité légales ou réglementaires.

Configurer une politique de rétention de sauvegarde à long terme (LTR).

Pourquoi: Les sauvegardes standard de restauration à un instant T (PITR) sont conservées pendant un maximum de 35 jours. LTR stocke les sauvegardes complètes dans un stockage Blob Azure distinct pendant jusqu'à 10 ans, spécifiquement pour les besoins de conformité.

Une base de données doit rester disponible pendant une défaillance de centre de données (zone de disponibilité) au sein d'une même région Azure.

Activer la configuration redondante inter-zones pour une base de données de niveau Business Critical ou Premium.

Pourquoi: La redondance de zone déploie des répliques secondaires synchrones dans différents centres de données physiques au sein de la même région, offrant un basculement automatique avec un RPO proche de zéro pour les pannes au niveau de la zone.

Une Azure SQL Managed Instance nécessite une solution de reprise après sinistre dans une région Azure jumelée avec une capacité de basculement automatique.

Configurer un groupe de basculement automatique pour l'Instance Gérée.

Pourquoi: C'est le modèle DR canonique pour Managed Instance, offrant une réplication asynchrone, des points de terminaison d'écouteur pour un basculement d'application transparent et une option de basculement automatisé.

Il est nécessaire de pouvoir restaurer une base de données à n'importe quelle seconde spécifique du mois dernier.

Configurer la période de rétention de sauvegarde à court terme (PITR) à 30-35 jours.

Pourquoi: Azure SQL effectue automatiquement des sauvegardes complètes, différentielles et fréquentes des journaux de transactions. Le paramètre de rétention PITR (1 à 35 jours) détermine la durée de conservation de ces sauvegardes, définissant la fenêtre pour les restaurations à un instant T.

Configuration d'un cluster de basculement Windows Server pour un groupe de disponibilité SQL Server Always On sur des machines virtuelles Azure.

Utiliser un témoin Cloud (Cloud Witness) comme témoin de quorum.

Pourquoi: Un témoin Cloud utilise Azure Blob Storage et est l'option recommandée et la plus résiliente pour les clusters dans Azure. Il évite la nécessité d'une troisième VM pour un témoin de partage de fichiers ou de configurations complexes de disques partagés.

Implémentation d'une instance de cluster de basculement SQL Server (FCI) sur des machines virtuelles Azure qui nécessite un stockage partagé.

Utiliser des disques partagés Azure (attacher un disque géré à plusieurs machines virtuelles).

Pourquoi: Les disques partagés Azure sont la solution native Azure pour fournir un stockage en bloc accessible par plusieurs machines virtuelles, ce qui est une condition préalable pour un FCI traditionnel.

Le processus de reprise après sinistre pour un groupe de basculement doit être testé sans impacter la base de données primaire de production.

Initier un basculement planifié (manuel) pendant une fenêtre de maintenance à faible impact, valider la connectivité de l'application, puis revenir au basculement initial.

Pourquoi: Un basculement planifié garantit l'absence de perte de données et constitue le moyen le plus approfondi de valider l'ensemble du processus de reprise après sinistre, y compris la propagation DNS et la reconnexion de l'application. C'est un événement de production bref et contrôlé.