SQL Server en SaaS — difficultés et pièges

Un incident sans changement identifiable est presque toujours dû à la croissance des données (volumétrie qui franchit un seuil : mémoire, limite de taille, plan différent) ou à une expiration (jeton, mot de passe, certificat, secret d'application).

· Symptôme : les visuels DirectQuery se figent pendant quelques minutes la nuit. Cause : TRUNCATE/DROP/ALTER ou SWITCH prend un verrou Sch-M, que toutes les requêtes en lecture attendent. Remède : charger en table de préparation puis SWITCH ou renommage atomique court ; fenêtre de maintenance ; ou couper DirectQuery pendant la consolidation (modèle en Import, ou réplica en lecture).

· Symptôme : CPU à 100 % à 9 h, retombe vers 10 h. Cause : tous les utilisateurs ouvrent la même page DirectQuery ; aucun cache. Remède : agrégations en Import, réduction des visuels par page, option « réduire le nombre de requêtes » (segments appliqués via bouton), cache de requêtes de la capacité Premium/Fabric.

· Symptôme : « le jeu de résultats dépasse la limite de lignes » (de l'ordre de 1 million de lignes sur capacité partagée ; réglable en Premium selon les paramètres). Cause : visuel table/matrice non agrégé. Remède : agréger, filtrer en amont, pagination par visuel de table à détail limité.

· Symptôme : consolidation lente alors que CPU à 30 %. Cause : le débit d'écriture du journal de transactions est plafonné par le niveau de service (attente LOG_RATE_GOVERNOR). Remède : réduire le volume journalisé (chargements par lots, columnstore, INSERT ... SELECT vers une table neuve), réduire les index à maintenir, ou monter temporairement de niveau.

⚠️ Piège 5 — Un seul gros UPDATE · Symptôme : transaction géante, journal plein, annulations très longues. Cause : mise à jour de dizaines de millions de lignes en une fois. Remède : traiter par lots (50 000 à 500 000 lignes) avec points de reprise ; privilégier INSERT dans une table neuve + SWITCH.

· Symptôme : performances irrégulières sans changement de code. Cause : une autre base du pool consomme le budget. Remède : limites min/max par base, séparer les bases critiques, ou sortir la base du pool.

· Symptôme : « l'optimisation a gagné 40 % » puis disparaît en recette. Cause : variabilité d'environnement, cache chaud. Remède : protocole ci-dessus ; critère de réussite exprimé en CPU et en lectures.

· Symptôme : la première actualisation du matin échoue ou dure plus longtemps. Cause : reprise de la base (de l'ordre de la minute) ; délai de connexion dépassé. Remède : désactiver la pause pour la production (ou délai de pause long), « réveiller » la base par une requête légère avant l'actualisation, tolérance de nouvelle tentative dans le pipeline.

· Symptôme : coupures de connexion de quelques secondes. Cause : un changement de niveau de service bascule les connexions en fin d'opération. Remède : hors heures de pointe ; stratégie de reconnexion avec nouvelle tentative dans les pipelines ; éviter de changer pendant une actualisation.

· Symptôme : Desktop OK, service KO (« client avec l'adresse IP … non autorisé »). Cause : l'IP de l'utilisateur est autorisée, pas le service. Remède : autoriser « services Azure » (large) ou plages ciblées, ou endpoint privé + passerelle de réseau virtuel ; vérifier la balise de service PowerBI.

· Symptôme : le nom du serveur se résout en IP publique depuis le réseau d'entreprise, qui est refusée. Cause : zone DNS privée privatelink.database.windows.net non liée au réseau. Remède : lier la zone au VNet, ou redirecteurs conditionnels ; tester avec nslookup depuis la machine de la passerelle.

· Symptôme : toutes les actualisations d'un domaine échouent en même temps. Cause : passerelle sur VM unique arrêtée, mise à jour, certificat. Remède : cluster de passerelles (≥ 2 nœuds), supervision, mises à jour planifiées ; ou passerelle de réseau virtuel gérée.

· Symptôme : Timeout expired à la connexion ou à l'exécution. Cause : base en pause, saturation de workers, requête trop longue. Remède : augmenter le délai de commande dans la source si légitime, mais surtout corriger la cause ; distinguer délai de connexion (réseau/pause) de délai de commande (requête).

· Symptôme : passerelle installée mais « hors ligne ». Cause : ports sortants (HTTPS, Service Bus) bloqués par le pare-feu d'entreprise. Remède : ouvrir les destinations documentées (liste en vigueur à consulter dans la documentation officielle de la passerelle).

· Symptôme : l'actualisation échoue du jour au lendemain (« informations d'identification non valides »). Cause : mot de passe SQL renouvelé, compte de service désactivé, secret d'application Entra expiré. Remède : compte de service sans expiration surprise ou, mieux, principal de service/identité managée avec rotation planifiée et alerte à J-30.

· Symptôme : Login failed for user '<token-identified principal>'. Cause : la base n'a pas créé l'utilisateur externe (CREATE USER [x] FROM EXTERNAL PROVIDER), ou l'administrateur Entra n'est pas défini sur le serveur, ou le jeton n'a pas la bonne audience. Remède : définir l'admin Entra ; créer l'utilisateur dans chaque base ; accorder les rôles ; vérifier le locataire.

· Symptôme : tous les utilisateurs voient les mêmes données, la RLS SQL ne s'applique pas. Cause : la source du modèle utilise l'identité du propriétaire et non « Single Sign-On Entra ID pour les requêtes DirectQuery ». Remède : activer l'option dans les paramètres de la source ; tester avec deux comptes aux droits différents.

· Symptôme : les appels d'API (actualisation, déploiement) répondent 401/403. Cause : les principaux de service n'ont pas été autorisés au niveau du locataire (paramètre d'administration) ou n'ont pas de rôle sur l'espace de travail. Remède : groupe de sécurité dédié autorisé dans le portail d'administration, rôle Membre/Contributeur sur l'espace.

· Symptôme : l'actualisation échoue après activation de l'authentification multifacteur. Cause : un compte utilisateur « technique » est devenu soumis à l'accès conditionnel. Remède : plus de comptes utilisateurs pour des automates ; identités de service avec stratégies d'accès conditionnel adaptées.

· Symptôme : un kit d'installation du datamart « réussit » mais n'a pas créé certains objets. Cause : droits insuffisants (non propriétaire de base) ou erreurs masquées par un outil qui renvoie 0. Remède : donner db_owner au compte de déploiement sur les bases cibles, exécuter le kit avec arrêt à la première erreur et vérifier les journaux, pas seulement le code retour.

· Symptôme : actualisations en attente puis échec, mémoire insuffisante. Cause : N modèles planifiés à la même heure sur une capacité. Remède : décaler, limiter la parallélisation, actualiser par partitions ; surveiller l'application de métriques de capacité.

· Symptôme : les utilisateurs veulent « du temps réel » alors que 8 actualisations/jour sont le maximum. Cause : exigence mal posée. Remède : clarifier la fraîcheur vraiment utile ; table hybride, ou DirectQuery ciblé, ou Direct Lake via mirroring.

· Symptôme : durée identique à une actualisation complète. Cause : étape Power Query qui casse le query folding (fonctions non traduisibles, ordre des étapes), ou parametres RangeStart/RangeEnd mal appliqués. Remède : vérifier la requête native ; faire le filtrage de date en première étape ; passer par une vue SQL.

· Symptôme : chiffres historiques incorrects malgré une correction en base. Cause : la politique incrémentielle n'actualise pas les périodes anciennes. Remède : actualisation ciblée de la partition (XMLA/API améliorée) ou « détection de changements » sur une colonne de dernière modification ; procédure de reprise d'historique documentée.

· Symptôme : erreur de mémoire pendant l'actualisation, alors que le modèle « tient » en lecture. Cause : doublement transitoire de la mémoire. Remède : incrémentiel, retrait de colonnes à haute cardinalité (identifiants, horodatages à la seconde), division date/heure, agrégations, ou capacité supérieure.

· Symptôme : des collègues ne voient pas le rapport. Cause : sans capacité dédiée (ou selon la licence Fabric/Premium), le lecteur doit avoir une licence Pro/Premium par utilisateur ; avec une capacité suffisante, les lecteurs peuvent être « gratuits » (selon la référence). Remède : cartographier lecteurs/auteurs et choisir le modèle de licence ; voir coût, licences et capacité.

· Symptôme : une vue appelant une UDF scalaire est nettement plus lente en DirectQuery (parfois d'un ordre de grandeur). Cause : niveau de compatibilité 130 : pas d'inlining, exécution ligne à ligne et plan sans parallélisme. Remède : relever le niveau (après test de régression, Query Store comme filet), ou déplier la fonction dans la requête (jointures ou CASE), ou la convertir en fonction table en ligne.

· Symptôme : certaines requêtes régressent après passage à un niveau supérieur. Cause : nouvel estimateur de cardinalité. Remède : activer Query Store en mode lecture/écriture avant ; passer au niveau cible ; comparer ; forcer le plan précédent pour les rares régressions ; réglage automatique FORCE_LAST_GOOD_PLAN.

· Symptôme : le rapport charge toute la table avant de filtrer. Cause : fonctions M sans équivalent SQL (Text.Proper, certaines conversions) cassent le folding. Remède : transformer en SQL (vue), ou conserver les transformations non pliables après les étapes pliables.

Dans un environnement de déploiement par kits, gardez une version du niveau de compatibilité par environnement dans le code (ALTER DATABASE ... SET COMPATIBILITY_LEVEL) et testez en bas avant le haut.

· Symptôme : « Opération » à la place de « Opération ». Cause : un fichier UTF-8 lu comme cp1252 (ou inversement) à l'installation ou à l'import. Remède : normaliser l'encodage des scripts (UTF-8 avec BOM), spécifier l'encodage explicitement dans les outils, tester avec un libellé « sentinelle » accentué dans la recette.

· Symptôme : « Café » et « Cafe » regroupés, ou clés en doublon refusées. Cause : collation AI. Remède : collation sensible aux accents pour les libellés métier ; différencier le comportement par colonne (COLLATE) plutôt que par base.

· Symptôme : l'ordre des libellés diffère entre une requête SQL et le visuel. Cause : le tri du modèle suit sa propre culture/collation, indépendante de celle de la base. Remède : colonne de tri explicite (numéro d'ordre) pour les libellés qui comptent (mois, statuts), plutôt que de compter sur l'ordre alphabétique.

· Symptôme : les visites de 23 h apparaissent le lendemain, ou « aujourd'hui » est vide jusqu'à 2 h. Cause : UTC vs heure locale ; TODAY() en UTC. Remède : stocker UTC et heure locale (datetimeoffset ou deux colonnes) ; dimension de dates/heures locale calculée dans le datamart ; AT TIME ZONE 'Romance Standard Time' pour convertir (gère l'heure d'été) ; paramètre de décalage dans le modèle pour les mesures « du jour ».

· Symptôme : « nombre de produits distincts » vaut 120 pour un directeur et 45 pour un commercial, alors que le catalogue est identique. Cause : la RLS filtre une dimension ; le filtre se propage vers les faits puis, via un filtre bidirectionnel ou securityFilteringBehavior, remonte vers une autre dimension. Remède : limiter la propagation (sens unique), calculer la mesure sur la dimension sans passer par les faits, ou documenter que la mesure est conditionnelle au périmètre ; tester chaque rôle.

Une base de test conservée en General Purpose 8 vCore alors qu'elle sert deux jours par mois : passer en serverless (min 0,5 vCore, pause) ramène le coût de calcul à une fraction (ordre de grandeur : de 90 % de réduction possible, selon les durées d'activité), au prix d'un temps de reprise.

· Symptôme : « La colonne X de la table Y est introuvable » à l'actualisation. Cause : renommage côté datamart sans adapter le modèle. Remède : vues d'exposition à contrat stable ; pour toute rupture, ajouter la nouvelle colonne, migrer le modèle, retirer l'ancienne ensuite.

· Symptôme : des rapports clients perdent leurs visuels. Cause : l'identifiant interne (lineageTag) de la mesure a changé. Remède : modifier en place ; si suppression indispensable, publier une note de rupture.

· Symptôme : tout va bien en test, pas en production. Cause : volumétrie, droits, réseau ou niveau de service différents. Remède : environnement de recette à volumétrie proche, données anonymisées ; documenter les différences ; voir recette et validation métier.

· Symptôme : des données client réelles en développement. Cause : copie de production sans anonymisation. Remède : masquage dynamique, jeux anonymisés, accès restreints ; voir sécurité, confidentialité, conformité.

· Symptôme : une erreur humaine détruit une table, personne ne sait comment restaurer. Cause : confiance dans « le cloud sauvegarde tout ». Remède : restauration à un instant dans le temps (PITR) testée une fois par trimestre, rétention documentée, procédure écrite ; rappel : la sauvegarde ne remplace pas la discipline de déploiement.

L'IA excelle à expliquer un message d'erreur et à proposer une liste de causes ; elle est moins fiable pour hiérarchiser la cause réelle dans votre contexte, et peut inventer des limites chiffrées. Garde-fou : toute valeur de limite ou de tarif se vérifie dans la documentation officielle. Voir 08-sqlserver-saas-ia.md.