🟨 2) Collecte d’entrées & cadrage (Methodology)

Checklist (questions à poser au métier / app)

• Transaction exacte (écran, endpoint, job, module) ?
• Fenêtre (heure/jour/période de fin de mois) ?
• Population touchée (% utilisateurs) ?
• Symptômes : latence, timeout, erreurs, blocages, files d’attente ?
• Changements récents : release app, patch DB, infra, statistiques, index ?
• Définition du “lent” : p95/p99, SLA, throughput, batch ?

Avec ces réponses, tu peux isoler : service / top SQL / top waits sur la fenêtre.

Red flags (cadrage “toxique”)

• “Toute la base est lente” (trop large)
• “Ça dépend” sans fenêtre / sans transaction
• “On a changé 10 choses” (impossible d’isoler)
• “Le CPU est haut donc on ajoute de la RAM” (non sequitur)

Plan de secours

Si le métier ne sait pas quoi :
1) Prendre la fenêtre de douleur (heure)
2) Extraire Top SQL (elapsed time)
3) Extraire Top waits
4) Mapper SQL_ID -> service/module -> écran/API
          

Template “problème” (copie/colle)

Symptôme :
- Transaction / écran / job :
- Service / PDB :
- Fenêtre (date/heure) :
- Population touchée :
- p95 / p99 actuel :
- Erreurs / timeouts :
- Changements récents (app/db/infra) :

Hypothèse initiale :
- CPU / I/O / contention / commit ?
          

Ce bloc doit tenir dans un ticket. Si tu ne peux pas le remplir, tu n’es pas prêt à tuner.

Exemples “propres”

Pourquoi percentiles

• La moyenne masque les pics (et c’est précisément les pics qui font mal).
• Le tuning vise souvent à réduire la variance (stabilité p95/p99).

Métrique ↔ source de vérité

Pièges courants

• Optimiser “Oracle” alors que le problème est réseau / app / cache applicatif.
• Suivre uniquement CPU% sans DB time / waits.
• Mesurer “après” sur une autre période (charge différente) → conclusions fausses.

Toujours aligner :
- même fenêtre
- même workload
- mêmes métriques
          

Questions indispensables

• Sessions actives en pic ? par service ?
• Top 20 SQL (elapsed time) sur la fenêtre ?
• Read/Write ratio ? commits/sec ?
• Pics quotidiens ou incidents exceptionnels ?

Signaux utiles

• OLTP : commits/sec + log file sync + contention
• OLAP : TEMP + db file scattered read + PGA
• Mixte : “qui écrase qui” (priorités/service)

Carte mentale (copiable)

Workload = {
  Services/modules,
  Sessions actives,
  TPS & commits,
  Mix read/write,
  Top SQL (elapsed/cpu/reads),
  Fenêtres de pics,
  Concurrence (locks/latches),
  Jobs batch,
  Variabilité (p95/p99)
}
          

Signaux typiques

• Plan qui dérive car stats obsolètes
• Contention sur “hot blocks” (index très écrits)
• Spill TEMP sur hash join / sort

Leviers possibles

- Index ciblés (pas à l’aveugle)
- Partitioning (gros volumes, historisation)
- Purge / archivage
- Stats (granularité, histograms)
- Réduction des scans
          

Contraintes métier & organisation

• CAB / change management
• Rollback obligatoire
• Règles sécurité / audit

Action ↔ risque ↔ rollback

Métriques minimales

• DB Time, Top wait events
• Top SQL (elapsed/cpu/reads/executions)
• CPU, run queue
• I/O latency (datafiles / temp / redo)
• Commits/sec + log file sync (OLTP)

Cadre avant/après (copie/colle)

Fenêtre baseline :
- Date/heure :
- Durée :
- Charge comparable ? (O/N)

Avant :
- DB Time :
- Top waits :
- CPU :
- I/O latency :
- Top 10 SQL :

Changement :
- Hypothèse :
- Action :
- Risques :
- Rollback :

Après :
- mêmes métriques
- delta (%)
          

Triangle des causes

flowchart LR
  CPU[CPU] --- IO[I/O]
  IO --- CONC[Contention]
  CONC --- CPU
          

OS : CPU / run queue / I/O latency

top
vmstat 1 10
sar -u 1 5

iostat -x 1 5
pidstat -d 1 5

sar -n DEV 1 5
          

Baseline / comparaison

4) Baseline (avant)
- DB Time :
- Top waits :
- CPU :
- I/O latency :
- AWR/ASH ref :

5) Plan
- Hypothèse 1 :
- Action 1 :
- Mesure après :
- Rollback :