📈 Oracle — Monitoring & Tuning (Outils production)

Panorama des outils natif Oracle, open-source, SaaS et commercial pour diagnostiquer, monitorer, alerter et tuner une base Oracle en prod. Objectif : “voir vite”, “comprendre”, “agir” (playbooks).

Règle DBA (prod) : un bon monitoring combine temps réel (incidents) + historique (tendances). Sur Oracle, le duo “pro” est souvent : AWR/ASH/ADDM (diagnostic) + OEM (supervision centralisée), complété par une couche observabilité (Grafana/Datadog/ELK) pour corréler DB ↔ OS ↔ app.

1.1

Oracle Enterprise Manager (OEM)

Supervision centralisée : alertes, métriques, jobs, dashboards, capacité, conformité.

OracleCentraliséAlerting

1.2

AWR (Workload Repository)

Historique perf : CPU/IO/waits, top SQL, load profile, snapshots comparables.

HistoriqueBaselineTop SQL

1.3

ADDM (Diagnostic auto)

Analyse automatique sur AWR : goulots, recommandations, priorisation, impact.

DiagnosticRecommandationsAWR

1.4

ASH / ASH Analytics

“Qui attend quoi” : sessions actives, waits, verrous, hot SQL, pannes intermittentes.

Temps réelWaitsSessions

1.5

Real-Time SQL Monitoring

Pour les requêtes lourdes : étapes du plan, progrès, IO, parallélisme, temps par opérateur.

SQLPlanLong-running

1.6

SQL Tuning Advisor

Conseils ciblés : stats, index, SQL Profile (si applicable), rewriting/structure.

AdvisorTuningSQL

2.1

Prometheus + Grafana

Métriques & dashboards sur mesure : DB + OS + app. Idéal “stack observability” self-host.

Open-sourceDashboardsAlerting

2.2

Oracle Exporter

Expose des métriques Oracle à Prometheus (sessions, waits, cache hit, tablespace, etc.).

ExporterPrometheusMetrics

2.3

ELK / OpenSearch logs

Centralisation & recherche : alert.log, listener, audit, traces, corrélation avec logs applicatifs.

LogsSearchCorrelation

3.1

Datadog / Dynatrace / New Relic

Observabilité full-stack : APM + DB insights + alerting, corrélation traces → SQL.

SaaSAPMSLO

3.2

SolarWinds DPA

Approche “wait-based” claire : historique, top waits, régressions, recommandations.

CommercialWait-basedHistorique

3.3

Quest / Redgate / Toad

Suites DBA : tuning SQL, diagnostics, comparaisons, dev-ops DB, tooling poste de travail.

DBA suiteTuningWorkflow

1.1 — Oracle Enterprise Manager (OEM / Cloud Control) — Supervision & Tuning en production

Pourquoi OEM est “le cockpit DBA” en production

OEM (Cloud Control) sert de tour de contrôle : surveillance multi-cibles, alerting, diagnostics, reporting, configuration & compliance. En environnement Oracle “sérieux”, OEM devient le point d’entrée : observer → comprendre → agir → prouver (reports).

Ce que OEM remplace (ou standardise)

Besoin	Sans OEM	Avec OEM
Vue multi-DB	scripts + bricolage	console centralisée
Alerting	cron/grep	seuils + actions + historique
Diagnostic	approche “à l’œil”	AWR/ASH/ADDM intégrés (si packs)
Capacity	Excel / estimations	tendances + forecast
Conformité	contrôles manuels	policies / drift / audit

Vision prod : OEM = “pilotage”. Les dashboards externes (Grafana/SaaS) = “observabilité full-stack”. Tu peux/DOIS garder les deux : Oracle deep + corrélation système/app.

Diagramme mental : OEM comme pipeline “signal → enquête → action”

[Cibles]      [Collecte]         [Analyse]                 [Action]
                            DB/ASM/RAC --> Agent OEM --> Metric Store + Baselines --> Alerts/Incidents
                            |              |                 |                         |
                            |              |                 |                         +--> Notifications (mail/webhook)
                            |              |                 +--> Perf (AWR/ASH/ADDM)   +--> Runbooks / opérateurs
                            |              +--> Config/Compliance                       +--> Jobs (maintenance)
                            +--> OS/Host (selon scope)                                  +--> Reporting (audit/capacity)

Dans une phrase

“OEM te dit : ce qui casse, depuis quand, sur quelles DB/instances, avec quel impact, et te donne un chemin d’investigation standard.”

Architecture OEM (Cloud Control) — cibles, agents, OMS, dépôt

Schéma (simplifié, mais fidèle au concept)

 +---------------------------+              +---------------------------+
                            |         Console UI         |              |    Notifications/ITSM      |
                            |  Dashboards / Reports      |  -----       |  Email / Webhook / Ticket  |
                            +---------------------------+      |       +---------------------------+
                            ^                  Alerts
                            |                   |
                            |                   v
                            +---------------------------+   +---------------------------+
                            |      OMS (Management      |   |  Policies / Baselines     |
                            |       Service)            |---|  Rules / Incidents        |
                            +---------------------------+   +---------------------------+
                            |
                            | writes/reads
                            v
                            +---------------------------+
                            |  OEM Repository (DB)      |
                            |  Metrics / history / conf |
                            +---------------------------+
                            ^
                            | agent upload
                            +--------------+--------------+------------------------------+
                            |        Agents OEM sur les hôtes / cibles                   |
                            |  - DB targets (instance/CDB/PDB), listeners, ASM, host     |
                            +--------------+--------------+------------------------------+
                            |                              |
                            v                              v
                            +------------------+             +------------------+
                            | Oracle DB target |             | Host/OS target   |
                            +------------------+             +------------------+

Point clé : la qualité OEM dépend de 3 choses : (1) métriques pertinentes, (2) seuils calibrés par baseline, (3) runbooks/actions (sinon alert fatigue).

Checklist déploiement (vue DBA)

Étape	But	À valider
Définir périmètre cibles	DB/ASM/RAC/Host	inventaire + criticité
Installer agents	collecte	latence réseau, firewall
Configurer repository	historique	capacité / maintenance
Importer templates	standardisation	mêmes règles partout
Baselines	seuils intelligents	période “saine”
Canaux d’alerte	réaction	mail/webhook/ITSM
Runbooks	MTTR bas	action immédiate

Erreurs classiques (à éviter)

Trop d’alertes → personne ne lit. Résultat : incident non détecté.
Seuils statiques “au pif” → faux positifs / faux négatifs.
Pas de runbook → OEM sonne… mais personne ne sait quoi faire.
Repo OEM sous-dimensionné → console lente, historique inutilisable.

Métriques & Dashboards (prod) — ce qui est réellement utile

Dashboard “SRE/Prod” (signaux rapides)

Signal	Ce que tu veux voir	Lecture
CPU	DB CPU vs Host CPU	CPU bound vs OS saturation
DB Time	DB Time, AAS	charge réelle côté DB
Waits	Top wait events	où se perd le temps
Sessions	active/blocked/new logons	pics / runaway / locks
Errors	ORA- rate / listener errors	bug / attaque / config
Storage	tablespace / FRA / ASM	risque incident imminent

Pattern : 1 dashboard “SLO” (latence/erreurs), 1 dashboard “DB internals” (waits/SQL), 1 dashboard “capacity” (disque/FRA/archives).

Dashboard “DBA” (investigation)

Bloc	Tu cherches	Action
Top SQL	régression / nouvelle requête	SQL Monitor + plan
Concurrency	locks, enqueues, latches	ASH + blockers
IO profile	hot objects / latence	segments + storage
Parsing	hard parse / library cache	binds / pool
Redo	commit latency / log sync	app commits / I/O redo

Diagramme : “DB Time se décompose en…”

DB TIME = DB CPU + Wait Time
                            Wait Time ≈ IO waits + Concurrency waits + Commit/Redo waits + Others

                            Si DB CPU >> waits  → CPU bound (SQL/parse)
                            Si waits dominent   → chercher l’événement principal (IO/locks/log sync…)

Alerting “pro” — éviter l’alert fatigue (et détecter avant la panne)

Stratégie de seuils (baseline-first)

Définir une période saine (baseline) : jours ouvrés / batch / pics.
Seuils = écart à la baseline + seuils absolus (ex: FRA 90%).
Différencier warning vs critical + délai (persistant X minutes).
Chaque alerte doit avoir : owner, runbook, action.

Table d’alertes recommandées (production)

Famille	Signal	Warn	Crit	Runbook (1ère action)
Storage	Tablespace usage	80%	90%	identifier segments + plan extend/purge
Storage	FRA usage	80%	90%	archivelogs, backups, rétention
Perf	DB Time / AAS	+X% baseline	+Y% baseline	Top waits + top SQL (AWR/ASH)
Concurrency	Blocked sessions	> 0 persistant	> N	trouver blocker + SQL_ID + app owner
Stability	ORA- rate	burst	burst + persistant	corréler release/logs + rollback
IO	Read latency	p95 hausse	p99 hausse	storage path + hot objects

Diagramme : pipeline d’alerte “OEM → action”

Metric breach
                            |
                            v
                            Incident (OEM)  ---> auto-ticket (option)
                            |
                            +--> Notification (mail/webhook) --> on-call
                            |
                            +--> Runbook (lien) : "quoi regarder / quoi faire"
                            |
                            v
                            Investigation : AWR/ASH/SQL Monitor + logs
                            |
                            v
                            Fix (SQL / config / storage / app) + validation baseline

Tip : pour chaque alerte critique, ajoute un champ “Definition of Done” : “comment on prouve que c’est résolu ?” (retour baseline, p95 normal, plus de blocage, etc.)

Anti-patterns (les pires)

- Alerte sur ratios "magiques" sans contexte - Alerte sans runbook - Seuils identiques sur toutes les DB (sans baseline) - Critique immédiat sans délai (bruit) - 200 alerts/day => plus personne ne regarde

Tuning via OEM — quand tu bascules dans AWR/ASH/ADDM / SQL Monitor

Workflow “incident perf” (OEM-guided)

1) Symptôme : DB Time↑ / latence app↑ / sessions bloquées
                            2) OEM : ouvrir la cible DB → Performance home
                            3) Identifier :
                            - Top wait events (dominant)
                            - Top SQL (elapsed / CPU / IO)
                            - AAS & sessions actives
                            4) Basculer :
                            - ASH (qui attend quoi, SQL_ID, blocker)
                            - SQL Monitor (requête lourde)
                            - AWR report (période incident vs baseline)
                            5) Action :
                            - SQL tuning (plan/stats/index/rewrite)
                            - Concurrency (locks/app)
                            - Storage/IO (hot objects / path)
                            6) Validation : retour baseline + fermeture incident + postmortem

Table “symptôme → outil”

Symptôme	Outil	Tu veux obtenir
pannes intermittentes	ASH	sessions actives / waits
dégradation sur 2h	AWR	diff baseline / top SQL
requête batch lente	SQL Monitor	où le plan consomme
diagnostic global	ADDM	findings + priorité

Diagramme : “Top wait” → hypothèses

Top Wait Event                    Hypothèses typiques
                            --------------------------------------------------------------
                            db file sequential read           index reads / IO latency
                            db file scattered read            full scans / stats/plan
                            log file sync                     commits fréquents / redo IO
                            enq: TX - row lock contention     locks applicatifs / transactions
                            library cache lock/pin            parsing / invalidations / shared pool
                            gc* (RAC)                         interconnect / hot blocks / skew

Important : OEM t’aide à “naviguer” vite. Mais la qualité du fix dépend de la discipline : mesure → hypothèse → test → validation.

Check “SQL régression” (ultra utile)

- La requête existait avant ? (release) - Plan a changé ? (stats, binds, cardinalité) - Nouveau predicate/Join ? - Stats stale / histogram manquant ? - Cardinalité estimée vs réelle (SQL Monitor) - Solution : stats, rewrite, index, baseline/plan control (prudence)

Jobs & Automation — OEM comme orchestrateur DBA

Ce que tu automatises classiquement

Job	But	Fréquence	Risques
Health checks	détection early	5–15 min	bruit si mal calibré
Stats collection	plans stables	daily/weekly	charge (fenêtre)
Tablespace audit	éviter saturation	hourly/daily	aucun si read-only
Backup verification	restores fiables	daily	temps/IO
Compliance scans	drift / sécurité	weekly	aucun

Règle : tout job doit être “safe-by-default” + logs + rollback (si action).

Diagramme : OEM jobs → preuves (audit)

[Job OEM] --> [Exécution] --> [Résultat] --> [Evidence/Report]
                            |             |             |               |
                            |             |             +--> OK/FAIL     +--> PDF/HTML export / historique
                            |             +--> logs
                            +--> schedule + notifications

Conseil très prod

Sépare "détection" (read-only) et "remédiation" (write). La remédiation doit être explicite, tracée, et validée.

Capacité & Reporting — prouver, prévoir, planifier

Capacity planning : ce que tu veux anticiper

Objet	Métrique	But	Décision
Data growth	GB/day, tablespaces	prévenir saturation	extend/move/partition
FRA	rétention archivelogs	éviter blocage	policy / storage
CPU	AAS trend	prévoir scale	optimiser vs ajouter CPU
IO	latence + throughput	éviter “IO wall”	storage tier / tuning SQL

En entreprise : les reports OEM servent à convaincre (budget / change management).

Rapports utiles (et lisibles)

Weekly health report : incidents, top alerts, top SQL, capacity delta.
Monthly capacity : croissance, FRA, storage, tendances CPU/IO.
Post-incident : timeline, métriques, root cause, action, prévention.

Diagramme : “reporting = preuve”

Mesure (avant) ---> Changement ---> Mesure (après) ---> Conclusion (ROI/risque)

Sécurité & RBAC — OEM doit être “safe”

Principes

Comptes OEM : RBAC strict (DBA, viewer, auditor, ops).
Agents : accès réseau minimal, segmentation.
Audit : actions OEM tracées (qui a fait quoi, quand).
Principe du moindre privilège sur les cibles DB (collecte vs action).

Modèle RBAC (exemple)

Rôle	Peut voir	Peut faire	Interdit
Viewer	dashboards	aucune action	jobs, config
Ops	alerts/incidents	runbooks, ack	tuning actions
DBA	perf + config	jobs maintenance	actions non validées
Auditor	reports	export	toute modification

Diagramme : zones de confiance

[Admin Users] ---RBAC---> [OEM UI/OMS] ---agents---> [DB targets]
                            |                         |
                            |                         +--> Repository (metrics/history)
                            |
                            +--> Audit trail (who/when/what)

Bon réflexe : OEM = surface d’administration majeure → traite-le comme un composant “Tier-0”.

Packs / Licensing — la réalité en production

OEM “de base” couvre déjà la supervision. Mais les diagnostics/tuning avancés s’appuient souvent sur des packs (ex: fonctionnalités AWR/ASH/ADDM/SQL Monitoring selon contexte). Dans un environnement entreprise, la question “qu’est-ce qui est autorisé/licencié ?” fait partie du métier DBA.

Fonction	Valeur	Remarque
Monitoring centralisé	visibilité multi-DB	socle OEM
Diagnostics historiques	forensic + trends	souvent lié à AWR/ASH/ADDM
SQL deep analysis	plans/progrès	SQL Monitoring / tuning
Compliance	policies / drift	selon modules/options

Pratique : en entretien DBA, on attend que tu saches distinguer : “outil dispo” ≠ “option licencée” ≠ “autorisé en prod”.

Playbooks incidents — “quoi regarder” en 5 minutes

Incident	Symptômes	Dans OEM	Ensuite	Fix typique
CPU 100%	latence globale	DB Time vs DB CPU, Top SQL	SQL Monitor + plan	rewrite/stats/index/binds
Locks	blocked sessions	Blocking sessions, ASH	identifier blocker	corriger logique app / commits
IO bound	read latency high	Top waits IO, segments	AWR compare baseline	hot objects / storage / plan
FRA plein	archivelogs bloquent	FRA usage + alert	logs backup	rétention / purge / capacity
ORA- burst	erreurs soudaines	error metrics / incidents	corréler release	rollback / fix app / patch

Mini runbook (template) — à coller dans tes tickets

1) Symptôme / impact / start time
                            2) OEM target : DB + instance + host
                            3) Graphs : DB Time, AAS, CPU, top waits
                            4) Top SQL : SQL_ID, module, user, plan changes
                            5) Hypothèse : (CPU/IO/locks/redo)
                            6) Action : (SQL fix / config / storage / app)
                            7) Validation : retour baseline + métrique OK
                            8) Postmortem : cause + prévention + seuils ajustés

Diagramme “MTTR” (ce qui fait gagner du temps)

MTTR ↓ = Alert (bon signal) + Runbook + Outil (AWR/ASH/SQL Mon) + Owner clair
                            MTTR ↑ = Bruit + Seuils au hasard + Pas de baseline + Pas d'ownership

Conseil : OEM doit être configuré pour produire des alertes actionnables, sinon il devient une “machine à bruit”.

1.2 — AWR : rapports, baselines, lecture “pro”

À quoi sert AWR

AWR capture des snapshots périodiques pour analyser une période (incident) ou comparer à une baseline. C’est l’outil “forensic” numéro 1 quand tu veux répondre à : “qu’est-ce qui a changé ?”

Section	Ce que tu cherches	Signal
Load Profile	DB Time, calls, parses	augmentation brutale
Top Wait Events	attentes dominantes	IO/locks/log sync
SQL ordered by …	top SQL	requête régressée
Instance Efficiency	ratios (indicatifs)	tendance anormale

Générer un rapport AWR (script standard)

-- SQL*Plus (selon licences/options)
                        -- @?/rdbms/admin/awrrpt.sql

                        -- Mode “DBA pro” :
                        1) repérer les SNAP_ID (avant/après incident)
                        2) générer HTML / TEXT
                        3) comparer à une période saine (baseline)

Lecture rapide (méthode 5 minutes)

1) DB Time vs DB CPU (CPU bound ?) 2) Top Wait Events (où on attend ?) 3) Top SQL (une requête = 80% du problème ?) 4) I/O profile + segments / objects chauds 5) Concurrency (locks / latches / enqueues)

Tip : AWR te dit “quoi / où”. Ensuite tu passes à ASH/SQL Monitor pour le “qui / comment”.

1.3 — ADDM : diagnostic automatique & recommandations

ADDM : “Assistant de diagnostic”

ADDM parcourt les données AWR et sort des findings hiérarchisées avec un impact estimé. C’est utile pour accélérer l’analyse quand on débute un incident ou un audit perf.

Sortie	Exemples	Valeur
Findings	CPU bottleneck, IO bottleneck, Concurrency	priorisation
Recommendations	stats/index, memory, config	plan d’action
Rationale	preuves + corrélations	convaincre / documenter

Comment le lire sans se faire piéger

ADDM est un conseiller, pas une vérité : toujours recouper (AWR/ASH/SQL plan).
Ne pas appliquer en prod des changements “paramètres” sans test et rollback plan.
Prendre les recommandations “SQL / stats / index / locks” en premier (souvent les plus sûres).

Actions typiques suite à ADDM

Symptôme	Action	Outils
Top SQL	plan, stats, rewriting	AWR + SQL Monitor + DBMS_XPLAN
IO waits	hot segments, storage	AWR + OS metrics + ASM
Locks	bloqueur, app logic	ASH + v$ views + app logs

1.5 — Real-Time SQL Monitoring : anatomie d’une requête lourde

Quand l’utiliser

SQL long-running / batch qui dérape.
Plan complexe avec parallélisme / gros IO.
Tu veux savoir “où ça passe le temps” dans le plan.

Ce que tu lis dans un SQL Monitor

Élément	Lecture	Signal
Plan steps	opérateur par opérateur	un step “explose”
Rows / buffers	cardinalité réelle	mismatch → stats
PX	répartition/ skew	parallélisme inefficace

Actions typiques

Comparer cardinalité estimée vs réelle → stats, histograms, rewriting.
Isoler l’opérateur “hot” → index, join order, filtre plus tôt.
Valider le plan via DBMS_XPLAN / hints (avec prudence).

Le but n’est pas “tuner au feeling”, mais de justifier une action par une mesure.

2.1 — Prometheus + Grafana : dashboards & alerting (open-source)

Pourquoi c’est très “IDEO-Lab friendly”

Tu peux fabriquer des dashboards très expressifs (spikes, amplitude, autoscale), et corréler Oracle + OS + Nginx + Django, exactement comme tu le fais déjà sur tes dashboards infra.

Composant	Rôle	Résultat
Prometheus	collecte + TSDB	métriques historisées
Grafana	dashboards	visual “ops”
Alertmanager	alerting	notif (mail/webhook)

KPIs typiques à exporter

Sessions (active/blocked), logons/s
Waits (top events), DB time
Buffer cache / library cache (tendance)
Tablespace/FRA usage
Redo / archive log rate

Pro tip : garder un dashboard “SLO” (latence & erreurs) + un dashboard “DB internals”.

2.3 — ELK / OpenSearch : logs Oracle + corrélation applicative

Pourquoi les logs sont indispensables

Tu captures le “contexte” : ORA-errors, listener, authent, audit.
Tu corrèles DB ↔ app (ex: erreur HTTP + ORA-error même minute).
Tu peux faire du “search forensic” après incident.

Idéal si tu as déjà une culture “LogDoctor / pipelines logs” dans IDEO-Lab.

Sources de logs (exemples)

Source	Contenu	Usage
alert.log	événements DB	diagnostic
listener log	connexions	sécurité / perf
audit	qui fait quoi	compliance
traces	détails	deep dive

3.1 — Datadog / Dynatrace / New Relic : observabilité full-stack

Ce que ces outils apportent

Force	Impact	Exemple
Traces APM	corrélation request → SQL	latence API = requête lente
Dashboards prêts	gain de temps	DB + OS + app
Alerting/SLO	pilotage produit	latence p95, erreurs

Quand choisir SaaS : besoin “time-to-value” rapide, multi-stacks, corrélation forte, équipe réduite.
Quand éviter : contraintes coûts/compliance, besoin 100% on-prem.

3.3 — Quest / Redgate / Toad : suites DBA (poste de travail + ops)

À quoi ça sert (concret)

Famille	Exemples	Valeur
Monitoring avancé	Foglight (Quest)	diagnostic, historiques, alerting
DevOps DB	Oracle Monitor (Redgate)	surveillance + workflows
Tuning SQL/IDE	Toad for Oracle	analyse SQL, plans, productivité

Bon pattern : OEM/Grafana pour le cockpit global + une suite “DBA” pour l’investigation SQL et le workflow.

KPIs Oracle (production) — ce qu’un DBA surveille réellement

Performance

KPI	Pourquoi	Signal
DB Time / DB CPU	CPU bound vs wait bound	écart important
Top wait events	où on perd le temps	locks/IO/log sync
Top SQL (elapsed/CPU/IO)	1 requête peut tout casser	régression

Concurrence / Verrous

KPI	Pourquoi	Signal
Blocked sessions	MTTR incident	persistant
Enqueue waits	contention logique	hausse brutale
Log file sync	commit latency	app “write heavy”

Storage

KPI	Pourquoi	Signal
Tablespaces	prévenir saturation	80/90%
FRA usage	archivelogs bloquent	pics
ASM diskgroup	capacité/IO	déséquilibre

Stabilité

KPI	Pourquoi	Signal
ORA errors rate	bug/régression	burst
Parse rate / hard parse	CPU waste	hausse
Stats freshness	plans instables	stale

Playbooks DBA — incidents fréquents (quoi regarder, quels outils)

Incident	Symptôme	Outils	Premières actions
CPU 100%	latence globale	AWR + ASH + SQL Monitor	Top SQL, hard parse, plan regression
IO bound	db file read high	AWR + OS metrics + ASM	hot segments, index, storage latency
Locks	blocked sessions	ASH + v$session	identifier bloqueur, corriger logique app
Tablespace/FRA plein	échecs / arrêt	OEM + alerting + scripts	purge/extend, revoir rétention archivelogs

Best practice : documenter pour chaque incident : “signal → enquête → action → validation → postmortem”.

Stacks recommandées — selon ton contexte (Oracle “pur” vs observability full-stack)

Contexte	Stack	Pourquoi
Oracle centric	OEM + AWR/ASH/ADDM + SQL Monitor	diagnostic guidé + cockpit DBA
Self-host observability	Prometheus + Exporter + Grafana + (ELK logs)	dashboards très expressifs, corrélation OS/app
Entreprise multi-stack	Datadog/Dynatrace/New Relic + OEM	traces APM + DB insights + SLO

Pattern efficace : OEM pour la profondeur Oracle + une couche observabilité (Grafana/SaaS) pour le “système global”.