Oracle – 0) Philosophie du Tuning

0.1 · Pourquoi le tuning Oracle est différent

Oracle = “système complet”

Optimizer (CBO) très puissant → stats/plans deviennent critiques.
Caches (SGA/Shared Pool/Buffer Cache) → parse vs I/O.
Concurrence (enqueues, latches, mutex) → contention invisible si mal outillé.
Redo/Undo : durabilité et read-consistency ont un coût mesurable.
Tooling enterprise (AWR/ASH/ADDM) → diagnostic guidé (quand bien utilisé).

Idée clé : Oracle ne se “tune” pas en devinant. On lit les wait events et on remonte la chaîne des causes.

Ce qui piège souvent en entreprise

Legacy : SQL anciens, schémas figés, contraintes d’ERP.
Workloads mixtes : OLTP + batch + reporting sur la même instance.
Paramètres historiques copiés de serveur en serveur (“ça marche”).
Conflits de priorités : perf vs coûts vs risques vs SLA.

                        Oracle tuning = diagnostic + gouvernance :
                        - observer (AWR/ASH)
                        - comprendre (architecture)
                        - agir (changement ciblé)
                        - vérifier (baseline / regression)
                        - documenter (runbook)

0.2 · Mythe du “paramètre magique”

Pourquoi c’est un mythe

Un paramètre modifie un compromis (CPU vs I/O, latence vs throughput, mémoire vs stabilité).
Les “tweaks” déplacent souvent la charge au lieu de la réduire.
Oracle a déjà beaucoup d’auto-tuning : on complète, on ne remplace pas l’observation.

Anti-patterns fréquents

Erreur	Pourquoi c’est mauvais	Alternative saine
Augmenter la mémoire “par réflexe”	Masque un mauvais plan / stats	Lire AWR/ASH + plan d’exécution
Changer 10 paramètres d’un coup	Impossible d’attribuer l’effet	1 hypothèse → 1 changement → mesure
Forcer des hints partout	Fige le plan, casse la maintenabilité	Corriger stats/index/SQL
Chasser le “cache hit ratio”	Indicateur trompeur	Se baser sur waits & latence

Règle d’or : si tu ne peux pas expliquer quel wait event tu cibles, tu ne dois pas changer un paramètre en prod.

0.3 · Performance = système global (SQL + Oracle + OS/I-O + App)

Les 4 couches

Couche	Exemples	Ce qu’on mesure
SQL	Plans, joins, cardinalités	elapsed, gets, reads, rows
Moteur Oracle	SGA/PGA, parse, redo/undo	wait events, ASH, latch/mutex
OS/Stockage	latence disque, CPU steal, FS	iostat, vmstat, perf, latency
Application	pool connexions, timeouts	APM, traces, p95/p99

Diagramme simple (copiable)

                        [APP / APM]  -> latence p95/p99, timeouts
                        |
                        v
                        [ORACLE SQL] -> plans, gets, reads, rows
                        |
                        v
                        [ORACLE ENGINE] -> waits, locks, redo/undo, caches
                        |
                        v
                        [OS / STORAGE] -> CPU, I/O latency, filesystem, network

Le piège : optimiser SQL sans voir un disque lent, ou changer I/O alors que c’est un lock (contention).

0.4 · Quand ne pas tuner (ou quand s’arrêter)

Cas typiques “tuning inutile”

Pas de SLA/SLO : impossible de dire si “c’est mieux”.
Bug applicatif : boucle, N+1, retry agressif, transaction trop longue.
Infra saturée : disque à 30ms, CPU steal, réseau instable → corriger l’infra d’abord.
Volumétrie non cadrée : 10x de données sans partitionnement/archivage.
Risque prod trop élevé : pas de fenêtre, pas de rollback, pas de monitoring.

Principe ROI : si l’action coûte plus cher (risque/temps) que le gain attendu, on change la stratégie (archi, scaling, refacto SQL).

0.5 · Méthodologie “observe → mesure → agir”

Cycle court (reproductible)

Observer : AWR/ASH + métriques app (p95/p99) + OS
Mesurer : baseline (avant), top SQL, top waits
Hypothèse : “la cause principale est X” (1 cause)
Agir : 1 changement (SQL/index/param) + plan de rollback
Vérifier : comparer baseline, valider la non-régression
Documenter : runbook + décision + contexte

Template d’hypothèse (copiable)

                        Symptôme:
                        - p95 API = 900ms (objectif 250ms)
                        - pic 10h–11h

                        Mesures:
                        - AWR: top wait = "log file sync"
                        - top SQL stable

                        Hypothèse:
                        - latence commit liée au redo/storage

                        Action:
                        - ajuster redo logs / storage / commit rate
                        - rollback défini

                        Validation:
                        - p95 passe 900ms -> 280ms
                        - wait "log file sync" divisé par 3

Important : on ne “tune” jamais pour le plaisir. On tune pour atteindre un objectif mesurable (SLA).

A · Cadre de travail (SLA → mesures → priorités)

Transformer “c’est lent” en plan d’action

Question	Exemple	Impact sur le tuning
SLO/SLA ?	p95 < 250ms, erreurs < 0.1%	Mesure objective (avant/après)
Workload ?	OLTP + batch nuit + reporting	Conflits de ressources
Fenêtre de changement ?	samedi 2h	Stratégie (param vs SQL)
Risques ?	prod critique, data loss interdit	Rollback + validation renforcés

Priorisation : d’abord le plus gros facteur (top wait / top SQL), ensuite le reste. Pas l’inverse.

B · Mythes & anti-patterns (à afficher au DBA junior)

“On augmente la RAM” → si c’est un mauvais plan ou un lock, ça ne change rien.
“On force des hints” → tu figes l’optimizer et tu crées une dette technique.
“On vise 99% cache hit” → souvent un faux objectif (workload dépendant).
“AWR donne la vérité absolue” → il faut interpréter, recouper avec l’app et l’OS.
“Un paramètre = une solution” → c’est un compromis, pas une potion magique.

Phrase clé : “Le tuning c’est de la méthode + de la mesure + de la prudence.”

C · Diagramme “système global” (copiable)

Vue “du symptôme à la cause”

                [Utilisateur] -> (latence p95/p99) -> [APP/APM]
                |
                v
                [SQL + Plans]
                |
                v
                [Oracle Engine]
                waits: CPU | I/O | locks | latches | commit(redo)
                |
                v
                [OS / Storage / Network]

Astuce : toujours commencer par un “top 3” : top waits, top SQL, top périodes (heures).

🟥 0) Introduction — Philosophie du Tuning Oracle

Pourquoi Oracle “tuning” est différent

Mythe du “paramètre magique”

Performance = système global

Quand ne pas tuner

Méthodologie “observe → mesure → agir”

Cadre de travail (SLA → actions)

Mythes & anti-patterns

Diagramme “système global”