Oracle – 10) Runbook tuning en prod

10.1 Cadre & responsabilités (RACI) : qui fait quoi en prod

RACI minimal (exemple)

Activité	R	A	C	I
Diagnostic perf	DBA	DBA Lead	App/Infra	Ops
Change SQL	App	App Lead	DBA	Ops
Paramétrage DB	DBA	DBA Lead	Security	App
Index/Partition	DBA	DBA Lead	App	Ops
Rollback décision	DBA+Ops	Incident commander	App	Stakeholders

Risque majeur : “tout le monde peut changer en prod” → personne n’est responsable.

On-call & incident commander

Incident commander : 1 personne décide (stop/go/rollback).
DBA on-call : diagnostic Oracle + exécution changements DB.
App on-call : validation SLA applicatif, tests fonctionnels rapides.
Infra : stockage, réseau, VM, OS (latence/queueing).

Règle : pendant un change, le “commander” ne tape pas de commandes : il pilote.

Règles d’or

Un seul changement à la fois (sinon causalité impossible).
Critères d’arrêt définis avant (p95/p99, errors, CPU, TEMP…).
Rollback prêt, testé (sinon = pas de change).
Traçabilité : qui / quoi / quand / pourquoi / résultat.

Anti-patterns

Changer plusieurs paramètres “pour gagner du temps”.
Pas de baseline → pas de preuve → “on pense que…”.
Faire un change en pleine charge sans fenêtre ni garde-fou.
Pas de rollback : “on verra bien”.

10.2 Pré-checks (avant tout) : checklist “no surprises”

Fenêtre de change

Charge attendue (pic vs normal)
Jobs batch prévus (PQ/ETL)
Gel applicatif (déploiements ?)
Stakeholders disponibles (DBA/App/Infra)

Bon signe : fenêtre dédiée + monitoring live + rollback prêt.

Analyse de risque

Change	Risque	Mitigation
Stats	plan regression	baselines / rollback stats
Paramètre mémoire	OS cache / swap	petits pas + monitoring OS
Index	lock/space	online si possible + fenêtre
PQ/DOP	TEMP meltdown	caps + test contrôlé

Capacité (headroom)

CPU : run queue acceptable ? marge ?
I/O : latence stable ? pas de queueing ?
TEMP/UNDO : headroom suffisant ?
Redo : log file sync/parallel write stables ?

Si une ressource est déjà “tendue”, on ne fait pas un change agressif.

Backout plan (obligatoire)

Qui décide rollback ?
Comment revert (scripts prêts) ?
Quels signaux déclenchent rollback ?
Temps max accepté avant rollback ?

Stop rules (ex) :
- p99 > +30% pendant 5 min
- erreurs/timeouts > seuil
- TEMP > 90% et croissance continue
- CPU run queue > X stable

10.3 Baseline (mesures “avant”) : capturer la preuve

Baseline = “photo” complète du système

DB : DB Time, DB CPU, top waits, top SQL (SQL_ID), plans, stats.
App : p95/p99, throughput, erreurs, timeouts, endpoints critiques.
Infra : CPU load, run queue, mémoire, swap, latence I/O, réseau.

Astuce : prendre 2 baselines : “normal” et “pic”, sinon on optimise le mauvais scénario.

Captures DB

Snapshot AWR avant/après (fenêtre comparable).
ASH sur la fenêtre du problème.
Top SQL : SQL_ID + plans + A-Rows si possible.

À conserver dans le ticket :
- AWR snapshot ids (begin/end)
- Top 10 SQL_ID (avant)
- Top waits (avant)
- DB Time / DB CPU (avant)

Captures applicatives

Signal	Exemples	Pourquoi
Latence	p95/p99 par endpoint	SLA réel
Erreurs	5xx, timeouts	stabilité
Throughput	TPS / req/s / jobs/h	capacité
Concurrence	sessions actives	pression

Captures OS/Storage

CPU : load, run queue, steal (VM).
Disk : read/write latency, queue depth, saturation.
Memory : free, cache, swap.

Attention : une “amélioration DB” qui dégrade l’OS (swap) = dette technique immédiate.

10.4 Change plan : hypothèse → action → validation (1 changement à la fois)

Plan minimal (qui marche)

Problème (symptôme, population, fenêtre)
Preuve (AWR/ASH : top waits, SQL_ID)
Hypothèse (#1 cause racine)
Changement (unique, petit)
Validation (critères + fenêtre)
Rollback (script + seuils)

Exemples d’hypothèses solides

“Le DB Time est dominé par db file sequential read sur SQL_ID X (index lookup) → manque index ou mauvais plan.”
“Les spills TEMP montent pendant PQ sur SQL_ID Y → workareas insuffisantes / cardinalité fausse.”
“Hard parse et mutex waits dominent → manque binds / curseurs.”

Une bonne hypothèse cite : symptôme + preuve + cause + action testable.

Stop rules (non négociable)

SLA : p99 +X% pendant Y minutes.
Errors : timeouts / ORA-xxxxx au-delà d’un seuil.
Ressources : TEMP > 90% + croissance ; CPU run queue > Z ; I/O latence > seuil.
Signal humain : “on ne comprend plus ce qui se passe” → stop & rollback.

Exemple de plan (copiable)

Hypothèse:
- SQL_ID abc123 fait un hash join qui spill en TEMP en PQ (DOP 16)
Preuve:
- ASH: direct path write temp dominant sur SQL_ID abc123
Action:
- Réduire DOP à 8 + corriger stats sur table T (stale)
Validation:
- TEMP peak -50%, durée -20%, p99 OLTP inchangé
Rollback:
- Revenir au DOP initial + restore stats si régression plan
Stop rules:
- TEMP > 90% et croissance 5 min
- p99 OLTP +30% pendant 5 min

10.5 Changements contrôlés : SQL, stats, paramètres, index, partition (sans casser prod)

Changer SQL “en prod” (approche safe)

Préférer un changement ciblé (1 SQL_ID) plutôt qu’un “tuning global”.
Mettre sous contrôle : plan stable, validation sur fenêtre, rollback prêt.
Éviter les hints sauvages “à vie” : documenter l’intention et re-valider régulièrement.

Les pires incidents viennent de : “on a mis un hint, ça a marché… puis la data a changé”.

Stats : le changement le plus “à double tranchant”

Stats peuvent améliorer… ou provoquer une regression de plan.
Ne pas recollecter au hasard : prouver “stale stats” + impact cardinalité.
Prévoir rollback des stats (export/import) ou plan baselines.

Paramètres : attention aux effets secondaires

Type	Risque	Règle
SGA/PGA	OS cache / swap	petits pas + monitoring
PQ/DOP	TEMP meltdown	caps + fenêtre
Optimizer	plans instables	jamais sans preuve

Index / partition : risques opérationnels

Space : croissance / quotas / ASM.
Locks : privilégier online si possible, sinon fenêtre.
Impact DML : plus d’index = plus de redo/undo.

10.6 Validation en live : go/no-go + garde-fous (pendant le change)

Must-not-break (à surveiller en continu)

p95/p99 endpoints critiques
errors/timeouts
sessions actives & waits dominants
TEMP/UNDO/redo
CPU run queue / I/O latency

Si un must-not-break passe au rouge → rollback (pas de débat).

Checks rapides (DB)

- top sessions actives (SQL_ID)
- top waits (non-idle)
- TEMP top consumers
- log file sync / temp waits

L’idée : confirmer que l’hypothèse bouge dans le bon sens, sans créer de nouvelle fuite.

Décision go/no-go

État	Condition	Action
GO	SLA stable + cause dominante ↓	continuer / confirmer
HOLD	gain incertain / bruit	attendre / mesurer plus
NO-GO	SLA dégradé / nouveau risque	rollback immédiat

Journal de change (obligatoire)

T+00:00 Baseline confirmée
T+00:05 Change appliqué (ref: script X)
T+00:10 Checks: p99 stable, TEMP stable, wait class shift OK
T+00:20 Validation: DB Time -15% sur fenêtre comparable
T+00:25 Decision: keep / rollback

10.7 Rollback : Plan B prêt (SQL, params, stats, index) + seuils

Rollback = capacité opérationnelle, pas une idée

Scripts prêts, testés, versionnés.
Temps de rollback connu (et acceptable).
Décision rollback non-politique : basée sur stop rules.

Rollback par type de change

Change	Rollback	Note
Paramètre	revert valeur	attention effets secondaires
Stats	restore export	prévoir avant
Index	drop index	peut être long / lock
SQL change	revert code	coordination app

Rollback drill (exercice)

Simuler un rollback en staging (même scripts).
Mesurer le temps réel.
Valider que les métriques reviennent au baseline.
Documenter : “how-to rollback” en 5 lignes.

Seuils (exemples)

Rollback si :
- p99 +30% sur 5 minutes
- erreurs/timeouts > seuil
- TEMP > 90% et croissance
- CPU run queue > X stable
- nouveaux waits dominants inconnus

10.8 Post-mortem & capitalisation : mesurer, documenter, durcir le runbook

Post-mortem (format court)

Contexte :
- Fenêtre / workload :
- Problème initial :
Preuve :
- AWR/ASH (top waits, SQL_ID) :
Changement :
- quoi / pourquoi / qui / quand :
Résultat :
- delta DB Time / p95/p99 / errors :
Incidents :
- impacts / durée :
Rollback :
- utilisé ? temps ?
Apprentissages :
- ce qu'on change dans le runbook :

Mesurer “après” proprement

Fenêtre comparable (mêmes heures, charge similaire).
Comparer AWR avant/après (DB Time, waits, top SQL).
Comparer SLA app (p95/p99, timeouts).
Comparer infra (CPU/I/O/TEMP/UNDO).

Capitalisation

Créer une fiche “pattern” : cause → action → validation → pièges.
Mettre à jour les checklists (pré-checks + stop rules).
Stocker scripts et sorties AWR/ASH dans le ticket (ou repo).

Actions follow-up

Automatiser les captures baseline.
Définir caps PQ / policies de change.
Réduire surface de risque (privileges, audit).
Planifier un “rollback drill” périodique.

10.9 Sécurité & conformité : tuning sans affaiblir la prod

Principes

Least privilege : accès DBA minimisés, rôles distincts.
Traçabilité : chaque change est attribuable.
Durcissement : pas de “quick fix” qui ouvre des droits.

Un tuning “efficace” mais qui baisse la sécurité = dette + risque majeur.

Accès

Comptes nominaux (pas de comptes partagés).
Élévation temporaire (JIT) si possible.
Accès prod limité en temps + en scope.

Audit

Log des changements : paramètres, DDL, stats, jobs.
Conserver les preuves : AWR/ASH IDs, scripts, outputs.
Process d’approbation (au minimum 2 paires d’yeux).

Secrets & hygiene

Jamais de mots de passe dans scripts/tickets.
Vault/secret manager.
Rotation + contrôle des accès “anciens”.

A · Templates (Ticket, Change plan, Post-mortem)

Template ticket (copier-coller)

[TICKET] Tuning Oracle (Prod)

1) Problème
- Service / schéma / PDB :
- Période (date/heure) :
- Population touchée :
- Symptômes (latence/erreurs/timeouts) :

2) SLA / cible
- p95 :
- p99 :
- TPS / débit batch :
- erreurs max :

3) Preuve
- AWR snapshot (begin/end) :
- Top waits :
- Top SQL (SQL_ID) :
- Hypothèse cause racine :

4) Plan de change
- Change #1 :
- Validation :
- Rollback :
- Stop rules :

5) Communication
- Stakeholders :
- On-call :
- Go/No-go decision maker :

Template change plan

[CHANGE PLAN] Oracle tuning prod

Pré-checks:
- fenêtre OK / stakeholders OK
- backups OK
- headroom CPU/I/O/TEMP/UNDO OK

Baseline (avant):
- DB Time / DB CPU
- top waits
- top SQL_ID + plans
- p95/p99 app + erreurs
- storage latency

Hypothèse:
- ...

Action (unique):
- ...

Validation (pendant):
- must-not-break:
  - p99 ...
  - errors ...
  - TEMP ...
  - CPU ...
  - I/O ...
- timebox: ...

Rollback:
- script:
- seuils:

Conclusion:
- keep / rollback

Template post-mortem

[POST-MORTEM] Oracle tuning prod

Contexte:
- date/heure, fenêtre, workload
Incident / besoin:
- ...
Preuve:
- AWR/ASH (IDs), top waits, SQL_ID
Changement:
- ...
Résultat:
- delta DB Time
- delta p95/p99
- erreurs/timeouts
Effets secondaires:
- ...
Rollback:
- utilisé ? temps ?
Lessons learned:
- ...
Actions:
- update runbook / caps / monitoring

B · Commandes & vues (runbook) : avant / pendant / après

Avant (baseline)

-- Sessions actives
SELECT sid, serial#, username, sql_id, program, module, status,
       event, wait_class, seconds_in_wait
FROM v$session
WHERE status='ACTIVE'
ORDER BY seconds_in_wait DESC;

-- Top events (non-idle)
SELECT event, total_waits, time_waited/100 time_s
FROM v$system_event
WHERE wait_class <> 'Idle'
ORDER BY time_waited DESC FETCH FIRST 25 ROWS ONLY;

-- TEMP top consumers
SELECT s.sid, s.serial#, s.username, s.sql_id,
       tu.tablespace, tu.segtype, tu.blocks
FROM v$tempseg_usage tu
JOIN v$session s ON s.saddr = tu.session_addr
ORDER BY tu.blocks DESC;

Pendant (garde-fous)

- p95/p99 app + erreurs
- top sessions actives (SQL_ID)
- waits dominants (temp / redo / IO / concurrency)
- TEMP/UNDO headroom
- CPU run queue + storage latency

Pendant : on cherche “le changement bouge la cause ?” et “aucun must-not-break ne part en vrille ?”.

Après (validation)

- Comparer AWR avant/après (fenêtre comparable)
- Vérifier top SQL changé (DB time, buffer gets, reads)
- Vérifier SLA app stable (p95/p99, erreurs)
- Vérifier infra stable (CPU/I/O/TEMP/UNDO)

Minimal set (ultra-compact)

1) AWR/ASH (snapshot ids)
2) top waits (non-idle)
3) top SQL_ID (avant/après)
4) TEMP top consumers
5) UNDO (v$undostat) + redo waits (log file sync)
6) SLA app (p95/p99 + erreurs)

🚀 10) Runbook tuning en prod

Cadre & responsabilités (RACI)

Pré-checks (avant tout)

Baseline (mesures “avant”)

Change plan (hypothèse → action)

Changements contrôlés

Validation en live (go/no-go)

Rollback (Plan B prêt)

Post-mortem & capitalisation

Sécurité & conformité

Templates (Ticket, Change plan, PM)

Commandes & vues (runbook)