🧠 Oracle DBA – Prépa Entretien Technique (IDEO-Lab)

Cheat-Sheet “DBA Oracle” (à relire avant l’entretien)

Les 12 “must say” (senior vibe)

Instance vs Database (SGA/PGA + datafiles/controlfiles/redo).
UNDO vs REDO : cohérence lecture/rollback vs durabilité (LGWR).
RMAN + Archivelog + tests restore (sinon backup = théorie).
AWR / ASH / ADDM : méthodo de diagnostic, pas d’impro.
Wait events : CPU vs I/O vs locks (pas “la DB est lente”).
Plan réel : DBMS_XPLAN.DISPLAY_CURSOR (+ stats, cardinalité).
Row-by-row = anti-pattern ; bulk collect / forall ; SQL set-based.
RAC : services, “skew”, interconnect, Cache Fusion.
ASM : diskgroups + rebalance + REDUNDANCY.
Runbook incident + communication (impact, ETA, décision).
Sécurité : least privilege, audit, secrets, rotation.
Patching : GI/RDBMS, fenêtre, rollback plan, conformité.

Punchlines

“Je ne redémarre jamais ‘pour voir’. Je diagnostique d’abord, je mesure l’impact, puis j’agis.”
“Un backup non restauré n’est pas un backup : je teste PITR au moins trimestriellement.”
“En perf, je cherche d’abord où part le temps : CPU, I/O, locks, réseau, puis seulement je tune.”

Mini-check

Avant entretien :
- connaître DBWR/LGWR/CKPT/SMON/PMON/ARCn
- savoir expliquer ‘log file sync’ / ‘TX row lock’ / ‘db file sequential read’
- 3 exemples d’incidents prod résolus (méthodo + résultat)

Walkthrough : “La base est lente” (méthodo d’intervention)

0) Cadrage (5 min)

Question	Pourquoi	Exemple de réponse attendue
Depuis quand ?	corrélation release / batch / infra	“Depuis 10h12 après un batch”
Impact ?	priorité (prod critique vs reporting)	“front KO, SLA client”
Périmètre ?	1 base, 1 service, RAC entier ?	“Instance 2 saturée”

1) Vue globale

- CPU / Load / IO wait (OS + DB)
- Sessions actives & waiting
- AWR/ASH (si dispo) sur la fenêtre exacte
- Top wait events (catégories)

Signals

CPU 100% + top SQL → requête runaway, stats, plan.
I/O waits → stockage, full scans, hot segments.
log file sync → commits trop fréquents / latency storage redo.
RAC GC waits → interconnect / skew / services.

Ce que l’intervieweur veut

Une “méthode”. Pas une liste d’outils.
D’abord localiser le temps perdu (waits), ensuite seulement optimiser.

2) SQL / Sessions

- Top SQL (CPU/elapsed/gets/reads)
- Vérifier plan RÉEL (DISPLAY_CURSOR)
- SQL Monitor pour long running
- Vérifier stats, bind peeking, cardinalité

Expliquer :
- “estimated vs actual rows”
- “full scan” peut être correct si DW
- index = pas toujours solution (write overhead)

3) Locks / Contention

- blocking_session / blocked sessions
- enq: TX row lock contention
- deadlocks (trace + application fix)
- latch/mutex (shared pool / parse storm)

“Je cherche d’abord QUI bloque QUI, puis la transaction racine,
puis je décide : kill session ? escalade app ? fenêtre ?”

4) Actions sûres (prod)

Action	Quand	Risque
Kill session runaway	SQL unique qui tue tout	rollback long si grosse txn
Switch service RAC	skew sur un node	impact sessions courantes
Plan bascule / DG	storage KO / corruption	RTO/RPO selon mode
Restart	dernier recours (fuite mémoire avérée)	downtime + recovery

SQL Pack – commandes “interview” (V$ / diagnostics)

Sessions actives / attente

-- Sessions actives (simple)
SELECT sid, serial#, username, status, event, wait_class, seconds_in_wait
FROM v$session
WHERE type='USER'
ORDER BY status DESC, seconds_in_wait DESC;

-- Top events (instance)
SELECT event, total_waits, time_waited/100 time_waited_s
FROM v$system_event
ORDER BY time_waited DESC;

Blocking sessions / verrous

-- Qui bloque qui
SELECT sid, serial#, blocking_session, event, seconds_in_wait
FROM v$session
WHERE blocking_session IS NOT NULL
ORDER BY seconds_in_wait DESC;

-- Détails verrous (TX/TM)
SELECT l.sid, l.type, l.id1, l.id2, l.lmode, l.request, l.block
FROM v$lock l
WHERE l.block = 1 OR l.request > 0
ORDER BY l.block DESC, l.request DESC;

Top SQL (gets/reads/elapsed)

SELECT *
FROM (
  SELECT sql_id, executions, elapsed_time/1e6 elapsed_s, cpu_time/1e6 cpu_s,
         buffer_gets, disk_reads, rows_processed
  FROM v$sql
  ORDER BY elapsed_time DESC
)
WHERE ROWNUM <= 15;

Plan réel (DBMS_XPLAN)

-- Plan réel (avec stats)
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +PEEKED_BINDS'));

-- “Estimated vs Actual rows” est LA discussion senior.

RAC / ASM

-- RAC : instances + services (selon contexte)
SELECT inst_id, instance_name, host_name, status
FROM gv$instance
ORDER BY inst_id;

-- ASM : diskgroups
SELECT name, state, type, total_mb, free_mb
FROM v$asm_diskgroup;

-- Rebalance en cours (si ASM)
SELECT * FROM v$asm_operation;

1) Architecture Oracle (réponses attendues)

Le pitch en 45 secondes

Oracle = (Instance) + (Database)
Instance = SGA (shared memory) + background processes
Database = datafiles + controlfiles + online redo logs (+ archivelogs)

Process clés (à connaître)

Process	Rôle	Phrase simple
DBWR	écrit buffers → datafiles	“flush du cache vers disque”
LGWR	écrit redo → redo logs	“durabilité commits”
CKPT	checkpoint	“cohérence + accélère recovery”
SMON/PMON	recovery / nettoyage	“hygiène et restart propre”
ARCn	archive redo	“permet recovery avancé”

UNDO vs REDO (question classique)

REDO : “ce que j’ai fait” (durabilité) → utilisé par recovery
UNDO : “comment revenir en arrière” (rollback + read consistency)
Les deux sont nécessaires, et ne se remplacent pas.

Relances typiques

- Pourquoi “log file sync” existe ?
- Que fait un checkpoint ?
- À quoi sert le controlfile ?
- Différence plan estimé vs réel ?

2) RMAN / Recovery (prod-ready)

Concepts à maîtriser

ARCHIVELOG indispensable pour recovery avancé (PITR).
Full + Incremental + backup controlfile/spfile.
RPO/RTO : objectifs business, pas seulement “tech”.
Catalog (optionnel) : centraliser historiques & métadonnées.

Punchline :
“Je fais des backups RMAN, mais surtout je PRATIQUE des restores.
Sinon je n’ai aucune preuve que le plan fonctionne.”

Cas pratique : datafile perdu

1) Identifier le datafile / tablespace impacté
2) OFFLINE tablespace (si possible) ou datafile
3) RMAN RESTORE DATAFILE n
4) RMAN RECOVER DATAFILE n
5) ONLINE + validation applicative

Risk note :
Si grosse transaction, le recover peut être long (archivelogs).

PITR (Point-In-Time Recovery)

Cas : suppression logique, corruption logique, “DROP TABLE”…
Principe : restaurer à T0 (avant l’erreur) puis réouvrir/extraire.

On attend de toi :
- savoir expliquer la fenêtre temporelle
- savoir expliquer la perte potentielle (RPO)
- savoir isoler l’environnement de restore

Tests restore (ce qui fait senior)

Test	Fréquence	Objectif
Restore controlfile/spfile	trimestriel	valider basiques
Restore datafile + recover	trimestriel	valider RTO réaliste
PITR (scénario)	semestre	valider plan “erreur logique”
DG switchover/failover (si DG)	semestre	DR “vrai”

3) Performance & Tuning (AWR/ASH/Waits)

Tri “où part le temps”

Symptôme	Lecture	Action initiale
CPU	top SQL CPU, parse storm	plan réel, stats, bind
I/O	sequential/scattered read	segments hot, scans
Commit	log file sync	latence redo + commit pattern
Locks	TX row lock	blocking session + root txn
RAC GC	gc cr request	services + skew + interconnect

Ce que tu dois citer

AWR : incidents “passés”
ASH : pics courts / sessions actives
ADDM : recommandations auto (si pack)
SQL Monitor : exécution live
DBMS_XPLAN : plan réel (ALLSTATS)

Anti-patterns (pièges)

- Ajouter des index “au hasard”
- “Flush shared pool” en prod sans justification
- Tuner sans connaître la charge (OLTP vs DW)
- Confondre “full scan” = mauvais (pas toujours)
- Optimiser SQL alors que le vrai souci est lock/commit/storage

Question piège : “Que fais-tu d’abord ?”

Réponse attendue :
“Je mesure. Je regarde les waits / top SQL / ASH sur la fenêtre.
Je ne touche rien avant d’avoir identifié la cause dominante.”

4) RAC / ASM (ce qu’on te demande vraiment)

RAC

Services : orienter charge (OLTP vs batch) + équilibrage.
Skew : “un nœud hot” (appli colle à un node).
Cache Fusion : latence interconnect → waits GC.
Diagnostiquer : gv$ views + waits GC + latence réseau.

Question typique :
“Si un nœud RAC est à 95% CPU et l’autre à 10% ?”
Réponse :
“Je vérifie la distribution par service, les sessions par instance,
et je corrige via services / connection strings / load balancing.”

ASM

Diskgroups : NORMAL/HIGH redundancy.
Rebalance : impact perf, planifier fenêtre.
Surveillance : espace, opérations ASM, disques en erreur.

Mots-clés :
“ASM = abstraction + mirroring + striping”.
“Je surveille v$asm_operation pour éviter un rebalance en pleine prod.”

5) Sécurité & Gouvernance (DBA moderne)

Ce qu’ils veulent entendre

Thème	Attendu	Phrase utile
Privilèges	least privilege, rôles, séparation	“Je n’utilise pas SYS au quotidien.”
Audit	qui fait quoi, traces incident	“Audit utile = exploitable.”
Secrets	rotation, coffre, pas dans scripts	“Les mots de passe ne vivent pas dans bash.”
Chiffrement	TLS, at-rest selon besoins	“J’aligne avec la conformité.”

Piège :
“On veut aller vite, mets tout en DBA.”
Réponse senior :
“Je peux dépanner, mais je régularise ensuite : rôles, traceabilité, rotation.”

6) PL/SQL – ce qu’un DBA doit savoir

Points incontournables

Packages : API stable + perf (cache) + organisation.
Exceptions : gestion propre, pas de “WHEN OTHERS” silencieux.
Perf : BULK COLLECT / FORALL si besoin (sinon SQL set-based).
Instrumentation : logs, DBMS_APPLICATION_INFO, trace.
Scheduler : DBMS_SCHEDULER + runbooks + retry.

Template “industriel” (package)

CREATE OR REPLACE PACKAGE pkg_ops AS
  PROCEDURE p_housekeeping(p_days NUMBER);
END pkg_ops;
/

CREATE OR REPLACE PACKAGE BODY pkg_ops AS
  PROCEDURE p_housekeeping(p_days NUMBER) IS
  BEGIN
    -- TODO: purge, archive, stats refresh
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN
      -- TODO: log + rethrow
      RAISE;
  END;
END pkg_ops;
/

7) Incidents Prod (questions pièges)

Incident	Cause typique	Réaction attendue
Archive log full	FS plein / archiver bloqué	stop hémorragie, backup archivelogs, purge RMAN contrôlée
Tablespace plein	croissance / manque autoextend	ajout datafile, resize, contrôle objets qui explosent
Redo log switch	redo trop petits / commits	analyser fréquence, ajuster size/nb groups
Deadlock	ordre verrous applicatif	trace + correction côté app (pas “tuning DB”)
Runaway SQL	plan, stats, param	isoler SQL, plan réel, mesures, action safe

Ce qui impressionne :
“Je suis capable d’expliquer l’incident en langage métier + un plan d’action.”
“Je documente : timeline, cause racine, prévention (RCA).”

8) Comportemental (DBA de prod)

Questions fréquentes

“Tu fais quoi à 2h du matin ?”
“Tu redémarres la DB ?”
“Comment tu annonces un ETA ?”
“Comment tu gères un conflit app vs DB ?”

Réponses attendues (structure)

1) J’accuse réception + j’évalue l’impact
2) Je stabilise (stop la dégradation)
3) Je diagnostique (waits / top SQL / locks)
4) J’applique une action sûre + je communique
5) RCA + prévention (runbook / monitoring / capacity)

9) Banque de questions (interview-style)

Question	Ce qu’ils testent	Réponse courte attendue
Instance vs Database ?	fondations	SGA+process vs fichiers (data/control/redo)
UNDO vs REDO ?	cohérence/durabilité	rollback/consistency vs recovery/commit
Base lente, tu fais quoi ?	méthodo prod	waits → SQL/sessions → locks → actions sûres
AWR/ASH servent à quoi ?	outillage	historique vs pics courts / sessions actives
Plan estimé vs réel ?	tuning	DISPLAY_CURSOR + ALLSTATS LAST
RAC : un nœud hot ?	exploitation	services, skew, interconnect, gv$
Archive log full ?	incident	stop + backup + purge RMAN contrôlée
PITR : quand ?	recovery	erreur logique / restore à T0
Pourquoi pas “restart” ?	maturité	risque + perte diag + downtime

🧠 Oracle DBA – Préparation Entretien Technique

Architecture Oracle

RMAN / Backup & Recovery

Perf & Tuning (AWR/ASH)

RAC / ASM

Sécurité & Gouvernance

PL/SQL (indispensable)

Incidents Prod (pièges)

Entretien “comportemental”

Banque de questions