🟥 1) Comprendre l’Architecture Oracle (pré-requis)

Définitions (à connaître par cœur)

Pourquoi c’est critique

• Une “lenteur” peut venir de mémoire (parse/cache) sans I/O disque.
• Un “commit lent” peut venir de redo (LGWR) même si le SQL est parfait.
• Un “DBWR en retard” = symptômes I/O et checkpoints, pas forcément SQL.

Mini-diagramme

[CLIENTS] -> (Sessions) -> [INSTANCE]
                     |      - SGA (shared)
                     |      - PGA (per session)
                     |      - Background processes
                     v
                  [DATABASE FILES]
                   - Datafiles
                   - Controlfiles
                   - Online Redo Logs
                   - (Archived Redo Logs)
                   - UNDO / TEMP
                    

Réflexe DBA : toujours dire “problème instance” vs “problème fichiers/I/O”.

Les 3 zones à retenir

Règle d’or

• Le tuning SGA n’est pas “augmenter tout” : il faut savoir où on perd du temps.
• Les wait events dictent la décision (AWR/ASH au chapitre 6).

Schéma “mémoire → symptômes”

[Shared Pool]
  - SQL parse/optimize
  - Cursor caching
  => si sous pression: hard parse, contention (mutex/latch)

[Buffer Cache]
  - blocs chauds
  => si cache insuffisant: I/O reads + "buffer busy waits"

[Redo Buffer] -> [LGWR] -> [Redo Logs] -> (ARCH)
  => si redo saturé: "log buffer space"
  => si commit lent: "log file sync"
                    

À compléter ensuite avec les vues V$SGAINFO / V$SGASTAT / V$BH (si nécessaire).

Ce que la PGA finance

• Work areas : sort, hash join, bitmap merge
• Session state, private SQL area
• Large workloads (OLAP) → risque de spill sur TEMP

Symptômes typiques

• Consommation mémoire OS qui grimpe avec le nombre de sessions
• TEMP qui explose (sort/hash spills)
• Temps de requêtes irréguliers “par vagues”

Mini-check “PGA vs TEMP”

Si work areas insuffisantes:
- opérations sort/hash basculent sur TEMP
- I/O TEMP augmente
- latence OLAP augmente fortement
                    

On détaillera le tuning mémoire/TEMP au chapitre 8 (Mémoire & I/O).

Les incontournables

Flux writes simplifié

DML -> Buffer Cache (dirty buffers)
    -> Redo Buffer (change vectors)
COMMIT -> LGWR flush redo -> "log file sync" wait
DBWR flush data -> datafiles (asynchrone)
CKPT coordonne checkpoints (périodique / pression)
                    

C’est la base pour comprendre “commit slow” vs “I/O slow”.

Étapes

1. Parse : recherche cursor, validation, dictionary cache
2. Optimize : CBO estime cardinalités, choisit plan
3. Execute : accès blocs (cache/I/O), verrous, CPU
4. Fetch : renvoi lignes (tri, hash, PGA)

Symptômes

• Hard parse élevé → shared pool / bind variables / app “chatty”
• Execute lent → I/O, contention, plan mauvais
• Fetch lent → tri/hash (PGA/TEMP), volumétrie

Mini-diagramme

SQL -> PARSE (Shared Pool)
    -> OPTIMIZE (Stats + CBO)
    -> EXECUTE
        - Buffer Cache hits
        - Disk reads
        - Locks / latches
    -> FETCH
        - Sort/Hash (PGA)
        - TEMP spills
                    

On branchera ensuite ce flux sur AWR/ASH (chapitre 6).

SQL*Plus / vues rapides

-- Instance / DB
SELECT * FROM v$instance;
SELECT name, open_mode, database_role FROM v$database;

-- SGA / composants
SELECT * FROM v$sgainfo;
SELECT pool, name, bytes FROM v$sgastat WHERE bytes>0 ORDER BY bytes DESC;

-- Sessions
SELECT status, COUNT(*) FROM v$session GROUP BY status;

-- Top waits (global)
SELECT event, total_waits, time_waited
FROM v$system_event
ORDER BY time_waited DESC FETCH FIRST 15 ROWS ONLY;
                    

Process & fichiers

-- Processus
SELECT pname, COUNT(*) FROM v$process GROUP BY pname ORDER BY 2 DESC;

-- Redo logs
SELECT group#, bytes/1024/1024 AS mb, status, archived
FROM v$log
ORDER BY group#;

-- Datafiles
SELECT file#, name, bytes/1024/1024 AS mb
FROM v$datafile
ORDER BY file#;

-- Controlfiles
SELECT name FROM v$controlfile;
                    

On raffinera au chapitre 6 (AWR/ASH/ADDM) et 8 (mémoire & I/O).