Les ralentissements Teradata sont rarement causés par un seul composant. Ils apparaissent à l’intersection du SQL, de la distribution des données, des statistiques, de la concurrence, des fenêtres batch, des règles de priorité et des pratiques d’exploitation.
À retenir
- Mesurer la variabilité et pas seulement la moyenne.
- Traiter les workloads et les requêtes dans le même diagnostic.
- Prioriser les actions réversibles et mesurées.
- Relier la capacité à la croissance et aux engagements métier.
1. Construire une baseline utile
La première étape consiste à établir un état de référence : temps de réponse par catégorie, consommation CPU, I/O, spool, concurrence, volumes, échecs, rejets et respect des fenêtres. Une moyenne globale masque les pointes et les workloads qui se dégradent.
2. Réaligner le workload management sur les priorités métier
Les règles historiques ne reflètent pas toujours les usages actuels. Les files, exceptions, throttles et priorités doivent être relus avec les propriétaires métier. L’objectif est d’éviter qu’un usage non critique dégrade un traitement réglementaire ou une activité opérationnelle.
3. Cibler le SQL à fort impact
Optimiser les requêtes les plus longues n’est pas toujours le meilleur choix. Une requête moyenne exécutée des milliers de fois peut consommer davantage. Il faut combiner fréquence, consommation, variabilité, criticité et possibilité d’action.
4. Gouverner les statistiques
Des statistiques absentes, obsolètes ou collectées sans stratégie influencent fortement les plans. La collecte doit être priorisée selon les colonnes, les jointures, les filtres, la volatilité et le coût de maintenance.
5. Identifier le skew et les distributions fragiles
Une mauvaise distribution augmente le temps de traitement, la consommation et le risque de spool. L’analyse doit distinguer skew structurel, valeurs dominantes, évolution des données et choix d’index.
6. Traiter les usages de spool comme un signal d’architecture
Les incidents de spool peuvent révéler un produit cartésien, une redistribution massive, une granularité incohérente ou une estimation erronée. Augmenter la limite sans traiter la cause reporte souvent le problème.
7. Revoir les choix physiques au regard des usages actuels
Index, partitionnement, compression et organisation des tables doivent être évalués sur les requêtes réellement exécutées. Les choix initiaux peuvent devenir inadaptés lorsque la volumétrie ou les accès évoluent.
8. Décomposer et ordonnancer les fenêtres batch
Un batch est un portefeuille de dépendances. L’analyse du chemin critique, des attentes, des traitements parallèles et des reprises permet souvent de gagner du temps sans modifier chaque étape.
9. Piloter la capacité avec des scénarios
La capacité se pilote avec la croissance, les nouveaux usages, les pics, les contraintes de reprise et la marge opérationnelle. Une projection simple et partagée vaut mieux qu’un chiffre isolé de saturation.
10. Rendre le monitoring actionnable
Une alerte doit indiquer le service affecté, le niveau de priorité, le contexte et l’action attendue. Trop d’alertes sans propriétaire créent une fausse visibilité.
11. Industrialiser le diagnostic et la reprise
Runbooks, collecte standard, historique des incidents, scripts contrôlés et critères d’escalade réduisent le temps de résolution et la dépendance à quelques experts.
12. Installer une gouvernance de performance
Un rituel mensuel peut suivre les workloads critiques, les principales consommations, les tendances, les actions et les décisions de capacité. La performance devient alors un processus, pas une succession de crises.
Plan d’action sur 90 jours
- Deux semaines : baseline et top causes.
- Un mois : quick wins testés et règles de priorité clarifiées.
- Deux mois : chantiers SQL/physiques et monitoring.
- Trois mois : gouvernance, capacity plan et transfert de compétences.