DBA Teradata, les questions sur l'index primaire, le skew et TASM

Teradata reste en place dans des banques, des assureurs, des opérateurs télécoms et des distributeurs, souvent depuis vingt ans. Le DBA y gère l'espace (perm, spool, temp), les droits, les sauvegardes, les montées de version et le partage de la machine entre rapports, chargements de nuit et utilisateurs avancés. Il conseille les développeurs sur le choix de l'index primaire et sur les statistiques. Les offres françaises citent BTEQ et TPT, le capacity planning, le tuning, et souvent une migration vers le cloud, BigQuery par exemple.

Beaucoup de CV mélangent développeur Teradata et DBA. Le développeur écrit du SQL et des scripts BTEQ. Le DBA sait pourquoi une requête épuise le spool d'un seul AMP, ce qu'une statistique périmée fait au plan, et comment un throttle protège les requêtes tactiques. Faites décrire un incident vécu : une table déséquilibrée, une erreur « no more spool space », une file TASM saturée un matin de clôture.

Si le poste prépare une migration vers le cloud, demandez au candidat ce qu'il a déjà inventorié avant une bascule : volumes, macros, scripts BTEQ, dépendances des rapports. Les profils seniors citent les traitements que personne ne voulait migrer. Dans le PDF, le cas porte sur un entrepôt bancaire dont les rapports du matin sortent en retard.

Les briques de Teradata qu'un DBA administre

Architecture MPP : PE, AMP, BYNET

Teradata répartit les lignes de chaque table entre des AMP qui travaillent en parallèle, chacun sur sa part. Les Parsing Engines optimisent les requêtes, le BYNET relie l'ensemble. Une table mal répartie fait attendre tout le système sur l'AMP le plus chargé.

Index primaire et hachage

L'index primaire décide sur quel AMP va chaque ligne. Bien choisi, il équilibre la répartition et rend les jointures locales. Mal choisi, il crée du skew et des erreurs de spool. C'est la première décision de conception que le DBA vérifie.

COLLECT STATISTICS

L'optimiseur s'appuie sur les statistiques collectées pour estimer les volumes. Périmées ou absentes, elles produisent des plans faux, visibles dans l'EXPLAIN par un niveau de confiance faible. Le DBA décide quoi collecter et à quel rythme.

EXPLAIN et DBQL

L'EXPLAIN décrit le plan prévu, étape par étape. DBQL journalise ce qui s'est réellement passé : CPU, I/O, spool, skew par requête et par étape. Les deux ensemble servent à l'optimisation et au capacity planning, avec PDCR pour l'historique.

TASM et Viewpoint

TASM répartit les ressources entre workloads : priorités, throttles, filtres, exceptions, réglages différents le jour et la nuit. Viewpoint est la console web de supervision et de configuration, avec Query Monitor et Workload Designer.

BTEQ et TPT

BTEQ exécute des scripts SQL avec gestion des erreurs. Teradata Parallel Transporter regroupe les anciens utilitaires (FastLoad, MultiLoad, TPump, FastExport) sous forme d'opérateurs Load, Update, Stream et Export. Les offres demandent les deux.

DSA et FALLBACK

DSA (Data Stream Architecture) gère les sauvegardes et restaurations. FALLBACK garde une seconde copie des lignes sur un autre AMP pour survivre à une panne. Le candidat doit savoir que l'un ne remplace pas l'autre.

Migration vers le cloud

Beaucoup d'entreprises préparent une sortie de Teradata vers BigQuery, Snowflake ou Databricks, ou un passage aux offres cloud de Teradata. Le DBA fournit l'inventaire d'usage, connaît les différences de comportement du SQL et organise le transfert des données.

Le poste existe surtout dans les grands comptes : banque, assurance, télécoms, distribution. Chez un client final, le DBA Teradata vit avec un entrepôt ancien et critique, alimenté chaque nuit, et arbitre entre les équipes qui se le partagent. En ESN, les missions sont longues (souvent plusieurs années) et mêlent run, tuning et projets de migration. Les offres demandent administration, tuning, capacity planning, gestion des chargements et montées de version, avec des outils voisins comme Control-M, DataStage ou Informatica. Les projets de sortie de Teradata changent le profil recherché : on attend du DBA qu'il connaisse aussi la plateforme cible et qu'il sache faire tourner les deux en parallèle pendant le double run. Peu de profils juniors arrivent sur ce marché, et les candidats viennent souvent du développement Teradata ou d'un autre SGBD.

Six compétences pour juger un DBA Teradata

• Index primaire, répartition et skew
• Statistiques et lecture de l'EXPLAIN
• Workload management avec TASM
• Espace, chargements et verrous
• Sauvegarde, sécurité et montées de version
• Migration de Teradata vers le cloud

Les questions à poser sur la répartition, les stats et les workloads

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Une table de faits de 3 milliards de lignes a un skew de 60 % et ses requêtes finissent en « no more spool space ». Que regardez-vous et que proposez-vous ?

   Une bonne réponseLe déséquilibre vient d'un index primaire peu sélectif ou d'une valeur très fréquente (valeur par défaut, NULL, code inconnu) : un AMP reçoit beaucoup plus de lignes que les autres. Le spool étant réparti par AMP, la requête échoue sur l'AMP le plus chargé alors qu'il reste de la place ailleurs. Le candidat mesure la répartition avec HASHAMP(HASHBUCKET(HASHROW(colonne))) et DBC.TableSizeV par AMP, puis choisit un index primaire plus sélectif et utilisé dans les jointures, composite si besoin. Il sait que changer l'index primaire impose de recréer la table (CREATE TABLE AS, copie, renommage) et vérifie l'effet sur les jointures existantes.

   Signal d'alerteDemander plus de spool pour l'utilisateur, ou choisir une colonne unique sans regarder les jointures.

2. Question 2 · confirmé

   Après un gros chargement, un rapport qui tournait en 2 minutes prend 40 minutes et l'EXPLAIN annonce « no confidence » sur une jointure. Que faites-vous ?

   Une bonne réponse« no confidence » signifie que l'optimiseur n'a pas de statistiques utilisables sur les colonnes de jointure ou de filtre, ou qu'elles sont périmées après le chargement. Il compare les estimations de l'EXPLAIN aux lignes réelles (DBQL avec STEPINFO), vérifie la date des statistiques avec HELP STATISTICS, puis recollecte sur l'index primaire, les colonnes de jointure, les colonnes de partition et la colonne PARTITION. En session de test, DIAGNOSTIC HELPSTATS ON FOR SESSION fait apparaître dans l'EXPLAIN les statistiques recommandées. Il ajoute la collecte à la chaîne de chargement, avec des seuils (USING THRESHOLD) pour ne pas tout recollecter.

   Signal d'alerteRecollecter toutes les statistiques de toutes les tables chaque nuit, ou ignorer le niveau de confiance de l'EXPLAIN.

3. Question 3 · senior

   À 9 heures, les tableaux de bord de la direction attendent derrière des requêtes ad hoc de data scientists. Comment réglez-vous TASM ?

   Une bonne réponseIl classe les requêtes en workloads selon le compte, l'application, le query band ou le coût estimé. Les requêtes des tableaux de bord vont au niveau tactique ou à un niveau à objectif de service, les requêtes ad hoc en timeshare avec une priorité plus basse. Des throttles limitent le nombre de requêtes ad hoc simultanées, des filtres refusent les requêtes manifestement démesurées, des exceptions rétrogradent une requête qui dépasse un seuil de CPU ou de skew. Des planned environments donnent un réglage différent la nuit, pendant les chargements. Il suit l'effet dans Viewpoint (Workload Monitor, Query Monitor) et dans DBQL.

   Signal d'alerteTuer à la main les requêtes des data scientists chaque matin, ou mettre tout le monde en priorité haute.

4. Question 4 · confirmé

   Un MultiLoad tombe à mi-parcours et la table cible reste verrouillée. Comment la débloquez-vous ?

   Une bonne réponseMultiLoad pose un verrou utilitaire et s'appuie sur des tables de travail, d'erreur et de log. Le candidat regarde d'abord si le job peut repartir de son point de reprise. Sinon il libère la table avec RELEASE MLOAD, ou RELEASE MLOAD IN APPLY si la phase d'application avait commencé, puis supprime les tables de travail et d'erreur. Il sait qu'après un échec en phase d'application, la table peut être incohérente et devoir être restaurée ou rechargée. Sur un nouveau traitement, il passerait par TPT avec l'opérateur Update.

   Signal d'alerteSupprimer et recréer la table sans essayer de relancer le job ni regarder la phase atteinte.

5. Question 5 · confirmé

   Vous migrez un entrepôt Teradata vers BigQuery ou Snowflake. Quelles différences de comportement cassent les traitements si personne ne les voit ?

   Une bonne réponseLes tables SET, qui écartent les lignes en double sans erreur lors d'un INSERT SELECT, alors que les cibles gardent les doublons. Les comparaisons de chaînes insensibles à la casse par défaut en mode Teradata (NOT CASESPECIFIC) et les espaces de fin ignorés, absents ailleurs. Les formats de date, la syntaxe propre (SEL, MERGE, macros, procédures), les scripts BTEQ et leurs .IF ERRORCODE, les tables volatiles. L'index primaire n'a pas d'équivalent : il faut repenser partitionnement et clustering. Il prévoit une comparaison des résultats sur données réelles, table par table.

   Signal d'alertePenser qu'un outil de conversion du SQL suffit, ou ignorer la différence entre tables SET et MULTISET.

Recrutement d'un DBA Teradata : réponses courtes

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.