Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026

DBA Oracle — Ideo-Lab

Oracle Tuning — 20 Scripts Best-Of (Waits, I/O, SQL, Locks, Memory, Redo)

Objectif : fournir un pack de scripts “terrain” (SQL/SQL*Plus) pour diagnostiquer rapidement : latence I/O, commit/redo, verrous, SQL coĂ»teuses, pression mĂ©moire et concurrence.

SQL / SQL*Plus 11g → 21c Single / RAC (GV$) Tuning “Terrain”

Vue d’ensemble

Philosophie : un tuning efficace commence par distinguer “symptĂŽme” et “cause”. Ces scripts sont conçus pour ĂȘtre utilisĂ©s dans cet ordre :
  • 1) OĂč ça attend ? (wait classes / events / sessions)
  • 2) Quel SQL ? (top elapsed / gets / reads / plan rĂ©el)
  • 3) Quelle ressource ? (I/O fichiers/segments, TEMP, REDO, mĂ©moire)
  • 4) Quelle contention ? (locks TX, ITL waits, hot blocks)
  • 5) Fix pragmatique : index/statistiques/SQL/paramĂštres/infra

Ce que tu obtiens

  • 20 scripts prĂȘts Ă  l’emploi (v$ / gv$ / dba_*)
  • Une lecture “DBA terrain” : quoi regarder & comment conclure
  • Des variantes : instance vs RAC (GV$)
  • Des piĂšges classiques : stats fausses, hard parse, TEMP, redo

3 signaux “d’alarme”

Les 3 patterns les plus fréquents en prod :

db file sequential read log file sync enq: TX - row lock contention

Ils pointent respectivement vers : I/O random (index), commit/redo latency, contention applicative/verrous.

Pré-requis

  • AccĂšs vues dynamiques : v$* (ou rĂŽle adaptĂ©)
  • AccĂšs dictionnaire : dba_* (sinon utiliser all_*)
  • Optionnel : SQL*Plus pour spool et formatage
Note licence : les scripts de ce guide n’exigent pas AWR/ASH, mais si tu ajoutes des sections AWR/ADDM, pense Ă  la conformitĂ© de licence.

Mini “checklist” de lecture

IndicateurCe que ça suggÚreAction DBA typique
Buffer gets / exec trĂšs hautPlan inefficace, scans logiques massifsIndex, rewrite SQL, stats, hints (rare)
Disk reads / exec trÚs hautI/O physique, cache insuffisant ou accÚs non sélectifIndex, partitioning, cache sizing, storage
log file sync dominantCommits fréquents / latence redoBatch commit, redo/logs, fsync, LGWR, storage
TX locks, blockersContention applicative, sĂ©quences de transactionsCorriger l’app, rĂ©duire durĂ©e txn, indexing FK

MĂ©thode DBA (rapide, efficace, “prĂ©sentable CTO”)

Étape 1 — “OĂč part le temps ?”

Avant de parler SQL : on mesure le profil d’attente (wait classes / events). C’est le moyen le plus direct de distinguer CPU vs I/O vs verrous vs commit.

Wait classes
Non-Idle events
Top sessions

Étape 2 — “Quel SQL fait mal ?”

Ensuite on remonte Ă  l’identitĂ© du problĂšme : SQL_ID, plan, exĂ©cution rĂ©elle, binds, cardinalitĂ©s (E-Rows vs A-Rows).

Top elapsed
Top gets
DBMS_XPLAN

Étape 3 — “Quelle ressource est saturĂ©e ?”

On corrÚle avec le systÚme : redo, TEMP, datafiles, segments chauds, pressure mémoire (PGA/sorts, library cache).

Redo
TEMP
Hot segments
Rùgle d’or : ne jamais “tuner à l’aveugle”. Toujours lier : symptîme → mesure → cause probable → test correctif → validation.

Format SQL*Plus recommandé (lisibilité)

Copier
-- Exemple SQL*Plus
set lines 220 pages 200 trimspool on long 2000000 longchunksize 2000000
col event format a46
col wait_class format a18
col sql_id format a13
col username format a18
col machine format a26
col program format a34
Conseil terrain : en prod, privilĂ©gie des scripts “read-only”, rapides, et un spool horodatĂ© (preuve + traçabilitĂ©).

Scripts (Pack) — utilisation “simple”

Tu peux utiliser ce guide en mode copier/coller, ou livrer un “pack” (un fichier SQL) qui regroupe tout + un menu. Dans Ideo-Lab, tu peux mĂȘme proposer un bouton download.

Télécharger le pack (oracle_tuning_scripts_pack_2026.sql)

/static/toolbox/oracle_tuning_scripts_pack_2026.sql (à déposer cÎté serveur)

Astuce : le pack peut gĂ©nĂ©rer un dossier de logs : spool tuning_&&_DATE._&&_TIME..log pour conserver un “snapshot” exploitable (audit + reporting CTO).

Structure conseillée (menu)

Copier
-- Pseudo-menu SQL*Plus
prompt 1) Top non-idle events
prompt 2) Wait classes
prompt 3) Top waiting sessions
prompt 4) Blocking sessions
prompt 5) Top SQL elapsed
...
accept choice prompt 'Choix (1-20) : '
-- then @script_01.sql ...
RAC : si environnement RAC, remplace beaucoup de v$ par gv$ + ajoute inst_id dans les selects (sinon tu perds la dimension “noeud”).

Dashboard — 20 scripts (ouvrir en modal)

Clique sur une carte : tu obtiens le script, une lecture rapide, et des pistes d’actions. (Copy/Print disponibles dans la modal.)

1

Top non-idle events

OĂč part le temps (waits), sans le bruit “Idle”.

WaitsMust-have
2

Wait classes

Vue macro : I/O vs Commit vs Concurrency vs CPU.

WaitsMacro
3

Top waiting sessions (live)

Qui attend maintenant, sur quoi, et depuis combien de temps.

LiveSessions
4

Blocking sessions

Détecter bloqueur/bloqué (contention immédiate).

LocksUrgence
5

Locks + objet (table/index)

Relier la contention Ă  l’objet (segment) impactĂ©.

LocksObjet
6

Top SQL — elapsed time

Les SQL qui coûtent le plus en temps cumulé.

SQLMust-have
7

Top SQL — buffer gets

Consommation CPU logique / cache (gets par exec).

SQLCPU
8

Top SQL — disk reads

RequĂȘtes qui tapent le disque (reads par exec).

SQLI/O
9

SQL text (SQL_ID)

RĂ©cupĂ©rer rapidement le texte de la requĂȘte.

SQLInvestig
10

Plan réel (DBMS_XPLAN)

Plan + ALLSTATS LAST (E-Rows vs A-Rows).

PlanProof
11

Commit/Redo waits

log file sync vs parallel write (latence commit).

RedoCritique
12

Redo volume & commits

Pression redo + fréquence commit (sysstat).

RedoDML
13

Hot datafiles I/O

Quels fichiers prennent le plus d’I/O.

I/OStorage
14

Hot segments (v$segment_statistics)

Objets chauds : logical/physical reads, ITL waits.

SegmentsMust-have
15

Buffer cache polluters (v$bh)

Segments “envahisseurs” du buffer cache.

MemoryCache
16

PGA / sorts / workarea

Overflows TEMP : onepass/multipass, sorts disk.

PGATEMP
17

TEMP consumers (live)

Qui consomme TEMP maintenant (v$tempseg_usage).

TEMPUrgence
18

Hard parse indicators

Parse hard, cursor cache hits : symptĂŽmes shared pool.

ParseShared Pool
19

Sessions actives + SQL_ID

Qui exĂ©cute quoi (actives) + temps d’attente.

LiveSQL
20

Index monitoring (pistes)

Index lourds vs usage monitoré (avec prudence).

IndexesPrudence

Exploitation & bonnes pratiques

Routine “DBA Prod” (10 minutes)

  1. Scripts 1–2 : wait profile
  2. Script 3–4 : sessions / blocages
  3. Scripts 6–8 : top SQL (elapsed/gets/reads)
  4. Script 10 : plan réel du SQL_ID coupable
  5. Scripts 11–12 : commit/redo si besoin

Spool & preuve

En incident, un “snapshot” horodatĂ© est prĂ©cieux.

Copier
-- SQL*Plus
define TS = &&_DATE._&&_TIME
spool tuning_snapshot_&TS..log
-- exécute scripts...
spool off

RAC : réflexe

  • Utiliser GV$ + inst_id
  • Comparer les nƓuds : un seul nƓud saturĂ© = hotspot
  • VĂ©rifier Ă©vĂ©nements “gc 
” (Global Cache) cĂŽtĂ© RAC
Attention “faux remĂšdes” : augmenter un paramĂštre mĂ©moire ou ajouter un index sans preuve peut dĂ©placer le problĂšme (ou en crĂ©er un autre). Toujours valider par mĂ©triques avant/aprĂšs.

Dépannage & piÚges classiques

1) “Tout est lent” mais pas de waits

  • CPU saturĂ© (OS) : la DB “attend” peu → check OS / runqueue / steal time
  • Plans changĂ©s suite stats : vĂ©rifier plans (script 10), stats/histograms

2) “E-Rows” trĂšs diffĂ©rent de “A-Rows”

  • Stats obsolĂštes / biaisĂ©es → gather stats ciblĂ©
  • Binds “atypiques” → peeked binds, bind sensitivity
  • Skew de donnĂ©es → histogrammes / partitioning

3) log file sync explose

  • Commits trop frĂ©quents → batch, regroupement
  • Storage redo lent → vĂ©rifier latence disque / fsync / configuration redo logs
  • RAC : interconnect / GC / log shipping

4) TEMP full / sorts disk

  • Hash join/sort qui dĂ©borde → PGA, SQL rewrite, indexes, rĂ©duction cardinalitĂ©s
  • Workarea multipass Ă©levĂ© → script 16
Tip : garde toujours un “script de baseline” (avant incident) pour comparer. Le tuning, c’est aussi une affaire de rĂ©fĂ©rence.