Chapitre 4 — Mémoire et processus Oracle

Support de cours Oracle 11g

← Accueil ← Ch. 3 Ch. 5 →

Découvrez l'architecture interne : la gestion de la mémoire (SGA, PGA) et les processus qui animent Oracle.

📖 Sommaire du Chapitre

🏗️ Architecture Mémoire Oracle

L'architecture interne d'Oracle 11g est conçue pour une efficacité maximale. Son but principal est de limiter les entrées/sorties (I/O) physiques sur le disque, qui sont des milliers de fois plus lentes que les opérations en mémoire vive.

Le fonctionnement d'Oracle repose sur deux structures de mémoire distinctes :

🧠 La SGA

(System Global Area)

Mémoire partagée, commune à tous

💼 La PGA

(Program Global Area)

Mémoire privée, dédiée à chaque utilisateur

Ces structures de mémoire sont animées par des processus (serveurs et de fond) qui assurent le mouvement des données entre la RAM et les fichiers disques.

💾 La SGA (System Global Area)

La SGA est une zone de mémoire vive (RAM) partagée et unique pour chaque instance Oracle. Elle est allouée dynamiquement lors du démarrage de l'instance (étape NOMOUNT).

Elle est dite "partagée" car tous les processus utilisateurs et tous les processus de fond d'une même instance peuvent y accéder. Son rôle est central : elle sert de zone tampon pour les données, de cache pour les instructions SQL et de zone de transit pour les journaux de modifications.

1️⃣ Caractéristiques principales

🔗 Partage

Elle permet à plusieurs utilisateurs d'accéder aux mêmes données sans avoir à les relire sur le disque.

⚡ Performance

En gardant les données fréquemment utilisées en mémoire, elle réduit considérablement les temps de réponse.

⚙️ Configuration

Dans Oracle 11g, sa taille est gérée soit manuellement via plusieurs paramètres, soit automatiquement via le paramètre SGA_TARGET (Automatic Shared Memory Management).

2️⃣ Composition de la SGA

Elle se décompose en plusieurs sous-zones spécialisées (pools), dont les plus importantes sont :

📦 Le Database Buffer Cache

Stockage des blocs de données.

📚 Le Shared Pool

Stockage du code SQL et du dictionnaire.

📝 Le Redo Log Buffer

Stockage des modifications.

🎯 Le Large Pool (Optionnel)

Pour les opérations lourdes comme les sauvegardes RMAN.

☕ Le Java Pool (Optionnel)

Pour l'exécution des procédures stockées en Java.

💡 Note de conception : La taille de la SGA est l'un des leviers les plus puissants pour l'optimisation (tuning) d'une base Oracle. Une SGA trop petite provoque des lectures disques excessives, tandis qu'une SGA trop grande peut saturer la RAM du serveur.

📚 Le Shared Pool

Le Shared Pool (zone globale partagée) est l'un des composants les plus critiques de la SGA. Son rôle est de mettre en cache les informations relatives à l'exécution des ordres SQL et les métadonnées de la base de données afin de minimiser le coût processeur (CPU) lié à l'analyse des requêtes.

Il se divise principalement en deux zones majeures :

1️⃣ Library Cache (Cache de bibliothèque)

C'est ici qu'Oracle stocke le code exécutable. Lorsqu'un utilisateur envoie une requête SQL (ex: SELECT * FROM clients), Oracle vérifie si cette requête existe déjà dans le Library Cache.

✓ Soft Parse

Si elle existe : Oracle réutilise le plan d'exécution déjà calculé. C'est extrêmement rapide.

✗ Hard Parse

Si elle n'existe pas : Oracle doit analyser la syntaxe, vérifier les droits d'accès et calculer le meilleur chemin. Cette opération est coûteuse en ressources.

📦 Contenu

Code SQL, plans d'exécution et procédures stockées PL/SQL.

2️⃣ Data Dictionary Cache (Cache du dictionnaire de données)

Aussi appelé Row Cache, il contient des informations sur la structure de la base de données.

  • Rôle : Pour exécuter une requête, Oracle doit savoir si la table existe, si les colonnes sont correctes et quels sont les privilèges de l'utilisateur.
  • Contenu : Définitions des tables, colonnes, index, utilisateurs et droits. En gardant ces informations en mémoire, Oracle évite de lire les fichiers de données système à chaque requête.

🎯 Pourquoi est-ce important ?

Un Shared Pool bien dimensionné permet :

  • De réduire l'utilisation du CPU en évitant les analyses répétitives.
  • D'améliorer la concurrence (plusieurs utilisateurs peuvent partager le même plan d'exécution).
  • D'accélérer la validation des objets grâce au dictionnaire en mémoire.

💡 Astuce de DBA :

En Oracle 11g, l'utilisation de variables de liaison (bind variables) dans le code applicatif est essentielle pour maximiser l'efficacité du Shared Pool et éviter de saturer le Library Cache avec des requêtes presque identiques.

📦 Le Database Buffer Cache

Le Database Buffer Cache est la zone de la SGA la plus importante en termes de volume. C'est le "garde-manger" des données : il contient des copies des blocs de données lus depuis les fichiers de données (Datafiles).

1️⃣ Rôle et Fonctionnement

Lorsqu'un utilisateur souhaite consulter ou modifier des données, Oracle ne travaille jamais directement sur le disque. Le processus suit ces étapes :

  1. 1. Recherche : Oracle vérifie si le bloc de données requis est déjà présent dans le Buffer Cache.
  2. 2. Lecture (si absent) : Si le bloc n'y est pas (on parle de Cache Miss), il est lu sur le disque et copié dans le cache.
  3. 3. Traitement : L'utilisateur accède à la donnée directement en mémoire.

2️⃣ Gestion par l'algorithme LRU (Least Recently Used)

Comme la mémoire est limitée par rapport à la taille de la base sur disque, Oracle doit faire de la place pour les nouveaux blocs via une liste LRU :

Les blocs les plus consultés sont gardés à une extrémité de la liste.

Les blocs les moins utilisés sont poussés vers l'autre extrémité pour être écrasés par de nouvelles données.

3️⃣ Blocs "propres" vs Blocs "sales" (Dirty Buffers)

✅ Clean Buffers

Blocs lus mais non modifiés, ou blocs modifiés déjà écrits sur disque. Ils peuvent être supprimés sans risque.

⚠️ Dirty Buffers

Blocs modifiés en mémoire (via UPDATE) mais pas encore enregistrés sur disque. Le processus DBWR devra les synchroniser.

📝 Le Redo Log Buffer

Le Redo Log Buffer est une zone de mémoire circulaire et de petite taille au sein de la SGA. Son rôle est vital pour la sécurité et la récupération (recovery) des données.

1️⃣ Rôle : La "boîte noire" des transactions

Chaque modification (INSERT, UPDATE...) génère une "entrée de reprise" (Redo Entry). Elle est stockée ici avant d'être écrite sur disque.

2️⃣ Fonctionnement Circulaire

Les nouvelles informations écrasent les plus anciennes une fois transférées sur disque par le processus LGWR.

3️⃣ Pourquoi ne pas écrire directement sur le disque ?

L'écriture sur disque est lente. En stockant d'abord en mémoire, Oracle permet aux transactions de continuer sans attendre. Le transfert vers les fichiers physiques est asynchrone.

4️⃣ Quand est-il vidé ?

  • Lorsqu'un utilisateur valide une transaction (COMMIT).
  • Toutes les 3 secondes.
  • Lorsque le buffer est rempli au 1/3.
  • Juste avant que le processus DBWR n'écrive des blocs modifiés sur le disque.

💼 La PGA (Program Global Area)

Contrairement à la SGA partagée, la PGA est une zone de mémoire privée et exclusive à chaque processus serveur Oracle. Elle est allouée dans la RAM du serveur dès qu'une session utilisateur se connecte.

1️⃣ Composants principaux de la PGA

🔐 Zone SQL privée (Private SQL Area)

Stocke les infos spécifiques à l'exécution d'une requête

  • Variables de liaison (bind variables)
  • État de l'exécution (curseurs)

🧮 Zone de travail (SQL Work Areas)

Critique pour les requêtes complexes

  • Le Tri (Sort Area) : pour ORDER BY
  • Les Jointures (Hash Area) : pour les jointures Hash

2️⃣ Comparaison SGA vs PGA

Caractéristique SGA (System Global Area) PGA (Program Global Area)
Accessibilité Partagée par tous les processus Privée à une seule session
Contenu Données (blocs), Code SQL partagé Variables, Tris, Jointures
Allocation Au démarrage de l'instance À la connexion de l'utilisateur
Objectif Réduire les lectures disques (I/O) Faciliter le traitement local

⚙️ Les Processus Serveur (Server Processes)

Le Processus Serveur agit comme l'intermédiaire indispensable entre l'utilisateur (le client) et l'instance. Lorsqu'une application lance une commande SQL, c'est ce processus dédié qui s'exécute sur le serveur de base de données.

1️⃣ Flux de travail simplifié d'une requête SELECT

  1. 1. Le Processus Utilisateur envoie SELECT name FROM clients.
  2. 2. Le Processus Serveur reçoit la demande et l'analyse dans le Shared Pool.
  3. 3. Il cherche les blocs de la table clients dans le Buffer Cache.
  4. 4. Si absent, il lit le Datafile sur disque et place le bloc en mémoire.
  5. 5. Il filtre les données et renvoie le nom au client.

⚠️ Note importante : Le processus serveur a le droit de lire sur le disque (Datafiles), mais dans un fonctionnement normal, il n'a jamais le droit d'y écrire. L'écriture est réservée aux processus de fond.

🔧 Les Processus de Fond (Background Processes)

Ce sont les ouvriers invisibles qui assurent la maintenance, la sécurité et l'intégrité de l'instance Oracle. Sans eux, le système serait paralysé.

1️⃣ Processus Obligatoires

DBWR Database Writer

Responsable de l'écriture des blocs de données modifiés (Dirty Buffers) vers les Datafiles. Écrit de manière asynchrone pour ne pas ralentir le système.

LGWR Log Writer

Gère le transfert du Redo Log Buffer vers les fichiers Redo Log sur disque. Déclenché à chaque COMMIT pour garantir la récupération.

CKPT Checkpoint

Coordinateur. Met à jour l'en-tête des fichiers de données et de contrôle pour signaler que la mémoire et le disque sont synchronisés.

SMON System Monitor

Assure la maintenance système. Effectue la récupération automatique après un crash (Instance Recovery) et nettoie les espaces temporaires.

PMON Process Monitor

Surveille les processus utilisateurs. Nettoie les sessions en cas de plantage client et libère les verrous.

ARCn Archiver

OPTIONNEL — Copie les Redo Logs pleins vers une destination d'archivage. Indispensable pour la restauration de données historiques.

2️⃣ Schéma de synthèse : Architecture Mémoire et Processus

Ce récapitulatif illustre le flux vital de la donnée dans Oracle.

📥 Flux de Lecture :

Utilisateur → Processus Serveur (Shared Pool) → Buffer Cache → Lecture Datafile (si absent)

✍️ Flux d'Écriture (Données) :

Modification utilisateur → Bloc "sale" (Buffer Cache) → DBWR écrit dans Datafile (Asynchrone)

🔐 Flux de Sécurité :

Modification → Redo Log Buffer → LGWR écrit dans Redo Log Files (Immédiat au COMMIT)