Un DBA DB2 z/OS travaille dans un environnement très particulier, et l'entretien doit s'y tenir. Le DBA écrit et lit du JCL, travaille sous TSO, ISPF et SDSF, lance REORG, RUNSTATS, COPY et RECOVER, gère les BIND des programmes COBOL et suit les performances avec Omegamon. Les offres viennent surtout de la banque, de l'assurance et des caisses de retraite, via des ESN, pour des missions longues où la chaîne de nuit et l'ouverture du service à l'heure comptent plus que tout.
Les profils sont souvent seniors et les CV se ressemblent. La différence se fait entre le DBA études, proche des développeurs et des chemins d'accès, et le DBA système, qui installe Db2, applique la maintenance et gère le data sharing. Certains ont surtout suivi des procédures écrites par d'autres. D'autres ont déjà mené une reprise après incident ou la migration de Db2 12 vers Db2 13. Demandez un cas réel, avec les commandes utilisées.
Faites préciser au client s'il veut un DBA études ou un DBA système, car beaucoup d'annonces mélangent les deux. Avec un senior, faites chiffrer une reprise : durée du RECOVER, copies utilisées, heure de retour du service.
L'environnement mainframe d'un DBA DB2 z/OS
Db2 13 for z/OS
La version actuelle de la base relationnelle d'IBM sur mainframe, sortie en 2022. Depuis Db2 12, les nouveautés arrivent par niveaux de fonction plutôt que par grandes versions. Le support standard de Db2 12 s'est arrêté fin 2025 : les sites qui y sont encore préparent ou terminent leur migration, ce qui fait un bon sujet d'entretien.
Utilitaires IBM
REORG réorganise les données, RUNSTATS collecte les statistiques, COPY prend les image copies, RECOVER restaure, LOAD et UNLOAD chargent et extraient, CHECK DATA contrôle l'intégrité. Ils tournent en batch et laissent parfois les objets dans des états restrictifs (COPY-pending, CHECK-pending) qu'il faut savoir lever proprement.
JCL et ordonnanceur
Le JCL décrit les jobs batch qui lancent les utilitaires et les programmes. L'ordonnanceur, souvent IBM Workload Scheduler (TWS) ou Control-M, enchaîne les chaînes de nuit. Le DBA lit les sorties de job et intervient quand un utilitaire échoue au milieu de la nuit.
TSO, ISPF et SDSF
L'interface de travail du mainframe. On édite les fichiers sous ISPF, on lance des commandes Db2 et on consulte les sorties de jobs et les journaux système dans SDSF. Un candidat qui ne cite jamais ces outils a peu travaillé sur z/OS.
BIND, packages et EXPLAIN
Les programmes COBOL embarquent du SQL statique. Le BIND crée un package avec un chemin d'accès figé, que la PLAN_TABLE décrit après un EXPLAIN. Un REBIND mal préparé peut ralentir un batch de plusieurs heures, d'où l'intérêt de la gestion des plans.
Omegamon for Db2
L'outil de supervision et d'analyse de performance d'IBM, cité dans beaucoup d'offres. Il montre les threads, les attentes de verrous et les consommations CPU, à partir des traces SMF. Les sites équipés de BMC utilisent ses outils équivalents.
Data sharing et Parallel Sysplex
Plusieurs membres Db2 partagent les mêmes données sur plusieurs partitions logiques du mainframe, grâce à la coupling facility. C'est la base de la continuité de service dans les grandes banques. Le dimensionnement et la contention entre membres sont des sujets de DBA système.
RACF et sécurité
RACF est le gestionnaire de sécurité de z/OS. Selon les sites, il contrôle aussi les droits Db2, ou bien Db2 garde ses propres autorisations. Le DBA doit savoir lequel des deux modèles est en place et qui détient les droits d'administration.
REXX
Le langage de script du mainframe. Les DBA s'en servent pour générer du JCL, faire des contrôles quotidiens ou automatiser des tâches répétitives. Zowe permet aussi de piloter le mainframe depuis des scripts modernes.
Les postes de DBA DB2 z/OS se trouvent surtout dans la banque, l'assurance et les caisses de retraite, chez le client final ou via une ESN, souvent pour des missions longues. Les offres demandent Db2, JCL, TSO, ISPF, SDSF, les utilitaires, parfois REXX, VSAM et l'ordonnanceur TWS, et certaines réclament plus de dix ans d'expérience. Le métier se partage entre DBA études, qui accompagne les développeurs sur le SQL et les BIND, et DBA système, qui installe, applique la maintenance et gère le data sharing. Les profils expérimentés sont rares, et des DBA venus d'Oracle ou de Db2 LUW se forment au mainframe. L'entretien doit vérifier la pratique réelle des utilitaires et des reprises, pas seulement la connaissance des termes.
Points de contrôle pour un DBA DB2 mainframe
- Utilitaires REORG, RUNSTATS, COPY et LOAD
- Image copies, journaux et RECOVER
- BIND, PLAN_TABLE et chemins d'accès
- Verrous et chaînes batch de nuit
- JCL, TSO/ISPF et RACF
- Data sharing et niveaux de fonction
Cinq questions d'entretien pour un DBA DB2 z/OS
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.
Question 1 · confirmé
Un LOAD a laissé un tablespace en COPY-pending et les jobs suivants tombent en -904. Que faites-vous ?
Une bonne réponseVérifier l'état avec -DISPLAY DATABASE(...) SPACENAM(...) RESTRICT, puis lancer une image copy avec COPY. C'est la bonne sortie : sans copie après un LOAD LOG NO, l'objet n'est pas récupérable. Pour la suite, la personne propose un LOAD avec copie en ligne (COPYDDN) qui évite l'état. Elle sait que -904 signale une ressource indisponible et lit le code raison. REPAIR NOCOPYPEND ou un START ACCESS(FORCE) ne s'envisagent qu'en mesurant la perte de récupérabilité, et avec l'accord de l'équipe.
Signal d'alerte« Je fais un -START DATABASE ACCESS(FORCE) » par habitude, sans dire que l'objet devient impossible à restaurer.
Question 2 · junior à confirmé
Comment décidez-vous qu'un tablespace a besoin d'un REORG ?
Une bonne réponsePar les statistiques en temps réel de SYSIBM.SYSTABLESPACESTATS (insertions et suppressions depuis le dernier REORG, lignes déplacées, insertions hors ordre de cluster), souvent exploitées par la procédure DSNACCOX, et par les états d'information AREO* ou AREOR après un ALTER. La personne lance le REORG en SHRLEVEL CHANGE pour garder les données accessibles, avec statistiques en ligne, et prévoit un REBIND si les chemins d'accès doivent en profiter.
Signal d'alerteUn REORG de tous les objets chaque week-end, sans critère, ou un REORG SHRLEVEL NONE en pleine journée.
Question 3 · senior
Une chaîne batch a corrompu des données à 3 h. Comment remettez-vous le tablespace et ses index dans l'état de 2 h 55 ?
Une bonne réponseRECOVER TOLOGPOINT sur l'ensemble cohérent des objets, tablespaces liés par intégrité référentielle et index compris, en partant d'une image copy et des journaux. Idéalement, un QUIESCE posé avant la chaîne fournit un point de cohérence propre. La personne vérifie SYSIBM.SYSCOPY, construit la liste avec LISTDEF, lance CHECK DATA si des objets passent en CHECK-pending, puis prend une nouvelle image copy. Elle peut citer RECOVER BACKOUT YES pour défaire un intervalle récent sans repartir d'une copie.
Signal d'alerteUn RECOVER sur un seul tablespace, en oubliant les index et les tables liées.
Question 4 · confirmé
Après un REBIND, un programme batch passe de 20 minutes à 3 heures. Comment revenez-vous en arrière, et comment l'évitez-vous la prochaine fois ?
Une bonne réponseLa gestion des plans (PLANMGMT EXTENDED, le défaut) garde les copies précédentes du package : REBIND PACKAGE ... SWITCH(PREVIOUS) restaure l'ancien chemin d'accès. On compare ensuite les deux EXPLAIN dans la PLAN_TABLE et on cherche la cause, souvent des RUNSTATS récents qui ont changé les estimations. Pour la suite : REBIND avec APREUSE et APCOMPARE, et un EXPLAIN contrôlé avant tout REBIND en production.
Signal d'alerte« Je relance RUNSTATS et j'attends la nuit suivante. » Aucune notion de copie précédente du package.
Question 5 · confirmé
Dans la nuit, un batch reçoit des -911 et un autre des -913. Quelle différence, et comment réduisez-vous ces erreurs ?
Une bonne réponseLes deux signalent un deadlock ou un timeout. Avec -911, Db2 a annulé l'unité de travail ; avec -913, il ne l'a pas fait et c'est au programme de décider. On lit les messages DSNT375I (deadlock) et DSNT376I (timeout) dans le journal du MSTR, ou Omegamon, pour savoir qui tient le verrou. Causes courantes : commits trop rares, escalade de verrous, ordre d'accès différent, batch qui chevauche le transactionnel. Corrections : commits plus fréquents, LOCKSIZE et LOCKMAX adaptés, ISOLATION(CS) avec CURRENTDATA(NO), ordonnancement revu.
Signal d'alerteAugmenter le délai d'attente des verrous partout, ou ne pas savoir lequel des deux codes fait le rollback.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
DBA DB2 z/OS : réponses aux recruteurs
Quelle différence entre un DBA études et un DBA système sur DB2 z/OS ?
Le DBA études travaille avec les développeurs : modèle de données, revue du SQL, BIND et REBIND des packages, analyse des chemins d'accès et des batchs lents. Le DBA système installe Db2, applique la maintenance, active les niveaux de fonction, gère les journaux, le BSDS, le data sharing et la reprise sur le site de secours. Beaucoup d'offres mélangent les deux. Précisez dans l'annonce quelle part domine, les questions d'entretien ne seront pas les mêmes.
Un DBA Db2 LUW ou Oracle peut-il passer sur DB2 z/OS ?
Oui, avec un temps d'adaptation réel. Le SQL et les principes (index, statistiques, verrous, sauvegarde) se retrouvent. L'environnement change tout le reste : JCL, TSO, ISPF, utilitaires batch, image copies, data sharing, RACF. Pour une mission où la personne doit être autonome vite, cherchez quelqu'un qui a déjà travaillé sur z/OS. Pour un poste interne avec un binôme expérimenté, un DBA d'un autre moteur peut convenir.
Quel test technique proposer à un DBA mainframe ?
Une sortie de job réelle, anonymisée, d'un utilitaire en échec, ou une PLAN_TABLE avant et après un REBIND. Demandez à la personne d'expliquer ce qu'elle lit et ce qu'elle ferait, dans l'ordre. Dix à quinze minutes suffisent pour voir si elle connaît les commandes et les états des objets. Un accès à un vrai sous-système est rarement possible en entretien, et ce n'est pas nécessaire.
Pourquoi ces profils sont-ils difficiles à trouver ?
Peu d'écoles forment au mainframe, et les DBA DB2 expérimentés sont souvent déjà engagés sur des missions longues. Les applications bancaires et d'assurance qui tournent sur Db2 z/OS restent pourtant critiques. Les entreprises misent sur des missions longues, la formation interne de DBA venus d'autres moteurs et le binôme avec un senior. Un entretien bien construit aide à repérer qui peut monter en compétence vite sur le reste.
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.
