Chapitre 5 — Structure logique et physique

Support de cours Oracle 11g

← Accueil ← Ch. 4

Ce chapitre explore la dualité fondamentale d'Oracle : la séparation entre l'organisation logique (invisible à l'OS) et l'organisation physique (fichiers concrets sur disque).

📖 Sommaire du Chapitre

🔍 Comprendre l'Architecture

L'une des grandes forces d'Oracle est la séparation totale entre la manière dont les données sont organisées pour l'administrateur (vision logique) et la manière dont elles sont stockées sur le disque (vision physique). Cette abstraction permet une flexibilité incomparable : on peut déplacer des fichiers physiques d'un disque à un autre sans modifier une seule ligne de code SQL.

Pourquoi cette architecture à plusieurs niveaux ?

✅ Avantages pour l'Admin

Contrôle granulaire de l'espace, isolation des défaillances, optimisation I/O

✅ Performances

Gestion d'espace efficace, réduction des fragmentations, cache optimisé

🏗️ La Hiérarchie Logique

La structure logique est une hiérarchie pyramidale qui permet à Oracle de gérer l'espace avec précision. Voici comment les données sont imbriquées, du plus grand au plus petit composant :

1️⃣

Tablespace

Le conteneur logique de plus haut niveau qui regroupe les objets.

2️⃣

Segment

L'ensemble des données d'un objet spécifique (table, index...).

3️⃣

Extent

Une unité d'allocation d'espace contigu sur le disque.

4️⃣

Bloc Oracle

La plus petite unité d'échange de la base de données.

La règle d'or de cette structure : Un objet logique (comme un Tablespace) peut s'étendre sur plusieurs fichiers physiques (Datafiles), mais un fichier physique ne peut appartenir qu'à un seul Tablespace.

📦 Les Tablespaces : Le Sommet de la Hiérarchie Logique

Le Tablespace est l’unité de stockage logique de plus haut niveau dans Oracle 11g. Il fait office de pont entre la base de données et les fichiers stockés sur le disque. C’est à ce niveau que l’administrateur organise les données par type, par utilisateur ou par application.

1️⃣ Définition et Rôle Stratégique

Un tablespace est un conteneur qui regroupe des objets logiques (tables, index, vues matérialisées). Son rôle dépasse le simple stockage ; il est l'outil principal de gestion administrative :

  • Contrôle Granulaire de l'Espace : On peut définir des quotas par utilisateur sur un tablespace, limiter sa taille maximale (MAXSIZE) ou activer l'auto-extension (AUTOEXTEND) pour éviter les interruptions de service.
  • Gestion de la Disponibilité : Contrairement à d'autres systèmes, Oracle permet de mettre un tablespace spécifique OFFLINE (pour maintenance ou restauration) sans impacter l'accès aux autres tablespaces de la base.
  • Optimisation des Performances (I/O) : En séparant les tablespaces sur différents disques physiques (ex: placer le tablespace des Index sur un SSD et celui des archives sur un disque classique), on réduit les contentions d'entrée/sortie.
  • Sécurité et Lecture Seule : Un tablespace peut être passé en mode READ ONLY. Cela garantit qu'aucune donnée ne sera modifiée et permet de l'exclure des cycles de sauvegarde réguliers.
💡 Conseil pour l'Admin : Créez au minimum 4 tablespaces distincts : SYSTEM (critique, ne pas toucher), DATA (tables), INDEXES (index), et TEMP (opérations de tri). Cela facilite la maintenance et améliore les performances.

2️⃣ La Dualité Logique / Physique

Il est crucial de comprendre la relation stricte entre la structure logique et les fichiers du Système d'Exploitation (OS) :

  • Un Tablespace peut être composé de plusieurs Datafiles (permettant ainsi à un seul tablespace de dépasser la taille maximale autorisée par le système de fichiers pour un seul fichier).
  • À l'inverse, un Datafile appartient exclusivement à un seul et unique Tablespace.

3️⃣ Anatomie d'une base : Les Tablespaces Natifs

Lors de la création d'une base Oracle 11g, ces tablespaces sont automatiquement générés :

Tablespace Rôle Critique
SYSTEM Le cœur. Contient le dictionnaire de données et les définitions de tous les objets. Si ce tablespace est corrompu, la base ne démarre plus.
SYSAUX Le bras droit du SYSTEM. Allège le SYSTEM en stockant les métadonnées des options (Statistiques, AWR, EM).
UNDOTBS La gestion du passé. Stocke les anciennes valeurs des données modifiées pour permettre le ROLLBACK et assurer la cohérence des lectures (Read Consistency).
TEMP L'espace de travail. Sert de zone de tri sur disque lorsque la mémoire RAM (PGA) est insuffisante pour un ORDER BY ou un GROUP BY.
USERS Le bac à sable. Stocke par défaut les objets créés par les utilisateurs non-administrateurs.

4️⃣ Bonnes pratiques de segmentation

En tant que formateur, soulignez que la multiplication des tablespaces est une stratégie de "diviser pour régner" :

  • Séparation DATA / INDEX : Accélère les recherches en permettant des lectures simultanées sur des disques différents.
  • Isolation Applicative : Évite qu'une saturation d'espace dans le module "Ventes" ne paralyse le module "RH".
  • Stratégie de Sauvegarde : Permet de sauvegarder uniquement les tablespaces dont les données ont changé, optimisant ainsi le temps de backup.

📌 Illustration Conceptuelle

Le schéma suivant résume la manière dont Oracle encapsule les objets logiques dans des conteneurs physiques :

tablespaces

Note pour les apprenants : Imaginez le Tablespace comme une "étagère" (Logique) et les Datafiles comme les "caisses" (Physique) posées sur cette étagère. Vous pouvez ajouter des caisses pour ranger plus de livres, mais une caisse ne peut pas être sur deux étagères en même temps.

🧩 Les Segments : L'unité de stockage des objets

Le Segment est la structure logique située juste en dessous du Tablespace. Il représente l'ensemble de l'espace alloué pour un objet spécifique de la base de données au sein d'un Tablespace. Il est crucial de comprendre qu'Oracle ne stocke pas une table de manière diffuse : chaque objet qui nécessite du stockage physique possède son propre segment dédié.

1️⃣ Définition et Caractéristiques

  • Relation Objet-Segment : En règle générale, il existe une relation de 1 pour 1. Si vous créez une table nommée EMPLOYEES, Oracle crée un segment de type TABLE nommé EMPLOYEES.
  • Frontières : Un segment réside dans un seul Tablespace, mais il a la particularité de pouvoir s'étendre à travers plusieurs Datafiles si le Tablespace en comporte plusieurs.
  • Allocation Dynamique : Un segment ne consomme pas tout l'espace du Tablespace dès sa création. Il grandit par "morceaux" appelés Extents (Extensions) au fur et à mesure que les données sont insérées.
⚠️ Attention : La suppression de lignes (DELETE) ne libère pas l'espace au segment. Utilisez TRUNCATE ou SHRINK SPACE pour récupérer de la mémoire. DELETE laisse de "l'espace mort" utilisable uniquement pour de futures insertions.

2️⃣ Les différents types de Segments

Il est erroné de penser que seules les tables occupent de l'espace. Oracle gère plusieurs types de segments pour assurer le fonctionnement du moteur :

  • Data Segments (Segments de données) : Stockent les données des tables non partitionnées et des clusters.
  • Index Segments : Stockent les structures d'index. Séparer les segments d'index des segments de table (souvent dans des Tablespaces différents) est une règle d'or pour la performance.
  • Undo Segments : Stockent les "images avant" des données modifiées. Ils permettent d'annuler une transaction (ROLLBACK) ou de fournir une image cohérente des données à une autre session pendant qu'une modification est en cours.
  • Temporary Segments : Créés dynamiquement par Oracle lorsque les opérations de tri (SORT), de jointure (HASH JOIN) ou de création d'index dépassent la capacité de la mémoire vive (PGA). Ils sont supprimés automatiquement une fois l'opération terminée.
  • LOB Segments : Utilisés pour stocker les objets volumineux (Large Objects) comme les images, les vidéos ou les documents PDF (clob, blob).

3️⃣ Cas particuliers : Partitionnement et Objets sans Segment

  • Partitionnement : Si une table est partitionnée, elle ne possède pas "un" segment, mais un segment par partition. Chaque partition peut même résider dans un Tablespace différent.
  • Objets sans segment : Certains objets logiques comme les Vues (Views), les Synonymes ou les Triggers ne possèdent pas de segment car ils ne stockent pas de données propres ; ils ne sont que des définitions stockées dans le dictionnaire de données (Tablespace SYSTEM).

4️⃣ Gestion de l'espace au sein du Segment

Oracle 11g utilise principalement le ASSM (Automatic Segment Space Management). Dans ce mode, Oracle utilise des bitmaps à l'intérieur du segment pour suivre l'espace libre dans les blocs, remplaçant l'ancienne gestion manuelle complexe (Freelists). Cela réduit considérablement les contentions lors des insertions massives par plusieurs utilisateurs simultanés.

✓ Conseil d'expert : En interrogeant la vue DBA_SEGMENTS, un administrateur peut identifier immédiatement quels objets consomment le plus d'espace disque et sur quel fichier physique ils se situent réellement.

📏 Les Extents (Extensions) : L'unité d'allocation

L'Extent est le troisième niveau de la structure logique d'Oracle. Alors que le segment définit quoi stocker (une table, un index), l'extent définit combien d'espace est réservé physiquement sur le disque à un instant donné. C'est l'unité de croissance d'un segment.

1️⃣ Définition et Mécanisme d'Allocation

Un Extent est un ensemble contigu de blocs Oracle. Lorsqu'un segment est créé, il se voit allouer un premier extent (l'extent initial). Dès que cet espace est saturé par l'insertion de nouvelles lignes, Oracle ne va pas chercher un seul bloc supplémentaire sur le disque, mais il alloue un nouvel Extent complet.

  • Contiguïté physique : Les blocs à l'intérieur d'un seul extent sont physiquement adjacents sur le disque, ce qui optimise les performances de lecture séquentielle (Multi-Block Reads).
  • Fragmentation : Un segment est composé d'un ou plusieurs extents. Ces extents ne sont pas nécessairement contigus entre eux sur le disque ; ils peuvent être éparpillés dans différents fichiers de données appartenant au même tablespace.

2️⃣ Gestion de l'espace : Local vs Manual

Dans Oracle 11g, la gestion des extents se fait presque exclusivement de manière Locale (Locally Managed Tablespaces) :

  • Locally Managed (Recommandé) : Le tablespace gère lui-même ses extents via un Bitmap stocké dans l'en-tête de ses fichiers de données. Chaque bit correspond à un bloc ou un groupe de blocs. Cela élimine les contentions sur le dictionnaire de données et évite la fragmentation récursive.
  • Uniform vs Autoallocate :
    • UNIFORM : Tous les extents du tablespace ont exactement la même taille (ex: 1 Mo). Idéal pour prédire l'espace.
    • AUTOALLOCATE : Oracle décide de la taille des extents (64 Ko, puis 1 Mo, puis 64 Mo...). C'est la méthode la plus souple pour les tables de tailles variables.

3️⃣ Cycle de vie d'un Extent

  • Allocation : Se produit lors de la création de l'objet ou lorsqu'un objet existant dépasse sa capacité actuelle.
  • Utilisation : Les blocs de l'extent sont remplis progressivement.
  • Libération : Un extent n'est normalement libéré que si l'objet est supprimé (DROP) ou tronqué (TRUNCATE). Une simple suppression de lignes (DELETE) ne libère pas l'extent ; l'espace reste réservé au segment pour de futures insertions (ce que l'on appelle le "High Water Mark").

⚛️ Le Bloc Oracle : L'Atome de la Base de Données

Le Bloc Oracle est la plus petite unité logique de stockage et la plus petite unité d'entrée/sortie (I/O) utilisée par le moteur. C’est à ce niveau que résident physiquement vos données (lignes de tables, entrées d'index).

1️⃣ Taille du Bloc (Block Size)

La taille d'un bloc est fixée lors de la création de la base de données via le paramètre DB_BLOCK_SIZE.

  • Standard : La valeur la plus courante est 8 Ko.
  • Lien avec l'OS : Un bloc Oracle est toujours un multiple de la taille du bloc du système d'exploitation (souvent 512 octets ou 4 Ko). Cela permet d'optimiser les lectures/écritures en minimisant le nombre d'opérations physiques.
  • Flexibilité : Bien qu'il y ait une taille par défaut, Oracle 11g permet de créer des tablespaces avec des tailles de blocs non standards (2 Ko, 4 Ko, 16 Ko, 32 Ko) pour des besoins spécifiques (ex: très grosses lignes LOB).
✓ Bonne pratique : Pour 90% des bases de production, 8 Ko reste la taille idéale. Changez de taille uniquement si vous avez des LOBs importants ou des besoins de cache très spécifiques.

2️⃣ Anatomie d'un Bloc Oracle

Chaque bloc possède une structure interne organisée pour maximiser la performance et garantir l'intégrité :

  • En-tête du bloc (Block Header) : Contient des métadonnées (adresse du bloc, type de segment, informations sur les transactions actives). Il croît du haut vers le bas.
  • Répertoire des lignes (Row Directory) : Un index interne qui contient l'adresse précise de chaque ligne stockée dans le bloc.
  • Espace Libre (Free Space) : Situé au milieu du bloc, il permet l'insertion de nouvelles lignes ou l'extension de lignes existantes suite à une mise à jour.
  • Données des lignes (Row Data) : C'est ici que sont stockées les valeurs réelles. Cette zone croît du bas vers le haut.

3️⃣ Gestion de l'espace : Le paramètre PCTFREE

Le paramètre PCTFREE est crucial pour éviter la dégradation des performances.

  • Rôle : Il définit le pourcentage du bloc qui doit rester vide pour les futures mises à jour (UPDATE) des lignes déjà présentes.
  • Exemple : Avec un PCTFREE de 10, Oracle cesse d'insérer de nouvelles lignes dès que le bloc est rempli à 90%.
  • Risque (Row Migration) : Si PCTFREE est trop bas et qu'une ligne est mise à jour avec une donnée plus longue, le bloc déborde. Oracle doit alors déplacer la ligne dans un autre bloc, créant un "pointeur". Cela double le temps de lecture de cette ligne.

4️⃣ Le cycle de vie d'un bloc en mémoire

Lorsqu'un bloc est lu sur le disque, il est copié tel quel dans le Database Buffer Cache (SGA).

  • Si une ligne est modifiée, le bloc est marqué comme "Dirty" (sale).
  • Le processus DBWR se chargera de réécrire ce bloc entier sur le disque plus tard.
  • Oracle ne lit ou n'écrit jamais une "ligne" isolée sur le disque, il déplace toujours des blocs entiers.

💾 Les Datafiles (Fichiers de données)

Le Datafile est le composant physique principal de la base de données Oracle. C'est là que sont réellement enregistrées toutes les structures logiques (tables, index, dictionnaires) que nous avons étudiées précédemment.

1️⃣ Relation avec la structure logique

La liaison entre le physique et le logique est rigoureuse :

  • Appartenance : Un datafile appartient à un seul et unique Tablespace.
  • Multiplicité : Un Tablespace peut être composé de plusieurs Datafiles pour répartir la charge sur différents disques ou pour dépasser les limites de taille imposées par le système d'exploitation.
  • Contenu : Physiquement, le datafile est une suite de blocs Oracle.

2️⃣ Caractéristiques et État

  • Identifiant physique : Chaque fichier possède un nom et un chemin d'accès absolu sur le serveur (ex: /u01/app/oracle/oradata/DB11G/users01.dbf).
  • État (Online/Offline) : Un administrateur peut mettre un datafile individuel hors ligne (OFFLINE). Dans ce cas, les données qu'il contient deviennent inaccessibles, mais le reste de la base continue de fonctionner (si ce n'est pas un fichier du tablespace SYSTEM).
  • En-tête (Header) : Le premier bloc du fichier est crucial. Il contient le Checkpoint SCN (System Change Number). Au démarrage, Oracle compare ce numéro avec celui du Control File. S'ils sont différents, une récupération est nécessaire.

3️⃣ Gestion de la croissance : AUTOEXTEND

Oracle permet d'automatiser la gestion de l'espace disque pour éviter les erreurs "Out of space" :

  • Taille initiale : Définie lors de la création (ex: 500 Mo).
  • Auto-extension : Si le fichier est plein, il peut grandir automatiquement d'un incrément défini (ex: NEXT 50M) jusqu'à une taille maximale (MAXSIZE).

4️⃣ Le concept de Bigfile Tablespace

Introduit pour simplifier la gestion des très grosses bases de données (VLDB) :

  • Smallfile Tablespace (Standard) : Peut contenir jusqu'à 1022 fichiers de données.
  • Bigfile Tablespace : Contient un seul fichier géant (pouvant atteindre 128 To selon la taille du bloc). Cela réduit considérablement le nombre de fichiers à gérer pour le DBA.
🔒 Note de sécurité : Lorsqu'Oracle écrit dans un datafile (via le processus DBWR), il s'assure que l'écriture est sécurisée. Si un datafile est supprimé accidentellement au niveau de l'OS alors que la base est ouverte, Oracle s'en apercevra immédiatement et passera le fichier en état "Recover" ou arrêtera l'instance selon la criticité du fichier.

🎯 Les Control Files (Fichiers de contrôle)

Le Control File est sans doute le fichier le plus vital de toute l'architecture Oracle. Bien qu'il soit de petite taille (quelques Mo), il contient l' "empreinte digitale" de la base de données. C'est lui qui permet à l'instance de savoir quels fichiers physiques constituent la base et quel est leur état de cohérence.

1️⃣ Rôle et Importance

C'est le fichier de liaison. Sans lui, l'instance ne peut pas passer de l'état NOMOUNT à l'état MOUNT. Il sert principalement à :

  • Maintenir l'inventaire : Il contient la liste exhaustive des fichiers de données (Datafiles) et des fichiers de journalisation (Redo Log Files).
  • Synchroniser la base : Il stocke les numéros de séquence système (SCN - System Change Number) qui garantissent que tous les fichiers sont au même niveau de mise à jour.
  • Gérer les sauvegardes : Il contient les informations de l'outil de sauvegarde RMAN (métadonnées des backups).

2️⃣ Contenu détaillé

Un fichier de contrôle contient les métadonnées suivantes :

  • Le nom de la base de données (DB_NAME).
  • L'horodatage de la création de la base.
  • L'emplacement et le nom de chaque fichier de données et de chaque Redo Log.
  • Le numéro de séquence actuel des Redo Logs.
  • Les informations sur les points de contrôle (Checkpoints).

3️⃣ Sécurité : Le Multiplexage

Puisque la perte de ce fichier empêche tout démarrage de la base (même si les données sont intactes), Oracle impose une stratégie de survie appelée Multiplexage :

  • Le DBA doit configurer Oracle pour maintenir au moins deux ou trois copies identiques du fichier de contrôle.
  • Ces copies doivent être stockées sur des disques physiques différents.
  • Lors d'une modification (ex: ajout d'un datafile), Oracle met à jour toutes les copies simultanément. Si l'une des copies manque ou est corrompue, l'instance refuse de démarrer par sécurité.

4️⃣ Cycle de vie et mise à jour

Le fichier de contrôle est mis à jour en continu par les processus de fond, notamment lors :

  • De l'ajout, du renommage ou de la suppression d'un fichier de données.
  • D'un changement de structure (ajout d'un Redo Log).
  • D'un Checkpoint (le processus CKPT y inscrit le nouveau SCN).

📝 Les Redo Log Files (Fichiers de journalisation)

Les Redo Log Files constituent la "boîte noire" de votre base de données Oracle. Leur rôle est unique : enregistrer chronologiquement toutes les modifications apportées aux données afin de pouvoir les réappliquer en cas de défaillance matérielle ou logicielle.

1️⃣ Le principe de fonctionnement : Write-Ahead Logging

Oracle utilise un mécanisme de sécurité appelé "Journalisation avant écriture". Avant qu'une modification (un bloc "sale") ne soit écrite définitivement dans les Datafiles par le DBWR, la trace de cette modification est obligatoirement sécurisée dans les Redo Logs par le processus LGWR.

  • Objectif : Garantir qu'aucune transaction validée (COMMIT) ne soit perdue, même si le serveur s'éteint brutalement avant que les données n'aient atteint le disque dur.

2️⃣ Organisation en Groupes et Membres

Pour assurer la continuité de service et la sécurité, les Redo Logs sont organisés de manière circulaire et multiplexée :

  • Groupes : Une base Oracle nécessite au minimum deux groupes de Redo Logs. Oracle écrit dans le Groupe 1 ; lorsqu'il est plein, il bascule vers le Groupe 2 (c'est le Log Switch), et ainsi de suite.
  • Membres : À l'intérieur d'un groupe, on peut avoir plusieurs fichiers identiques appelés Membres.
  • Multiplexage : Comme pour les fichiers de contrôle, il est vital de placer les membres d'un même groupe sur des disques physiques différents. Si un disque tombe, Oracle continue d'écrire sur le membre survivant sans interruption.

3️⃣ Le cycle de vie : Archive Log vs NoArchiveLog

Le comportement des Redo Logs dépend du mode de la base :

  • Mode NOARCHIVELOG : Lorsqu'Oracle a fait le tour de tous les groupes, il écrase les données du premier groupe pour continuer à écrire. En cas de perte d'un disque de données, vous ne pouvez restaurer la base que jusqu'à la date de la dernière sauvegarde complète.
  • Mode ARCHIVELOG : Avant d'écraser un groupe plein, le processus ARCn en fait une copie vers une destination sécurisée (les Archive Logs). Cela permet de restaurer la base à n'importe quel instant T (Point-in-time recovery).

4️⃣ Contenu d'un Redo Log

Un enregistrement de reprise (Redo Entry) contient :

  • Le type de modification (INSERT, UPDATE, DELETE).
  • L'adresse du bloc modifié.
  • Le numéro SCN de la transaction.
  • Les anciennes et les nouvelles valeurs (nécessaires pour la récupération).
⚡ Note de performance : La taille des Redo Logs influence la fréquence des Checkpoints. Si les fichiers sont trop petits, Oracle passera trop de temps à basculer de l'un à l'autre, ce qui peut ralentir les performances globales de la base.

🧪 TP : Exploration du dictionnaire de données

Le dictionnaire de données est le "cerveau" d'Oracle. Il s'agit d'un ensemble de tables et de vues stockées dans le tablespace SYSTEM, appartenant à l'utilisateur SYS, et maintenues automatiquement par le noyau. Pour un administrateur, c'est l'unique source de vérité pour comprendre comment l'espace est réellement distribué entre les structures logiques et physiques.

Dans ce TP, nous allons utiliser les vues de type DBA_ (vue globale de la base) pour auditer l'architecture que nous venons d'étudier.

Exercice 1 : Analyse des Tablespaces et de leurs fichiers physiques

Cet exercice permet de vérifier la correspondance entre les noms logiques et les chemins d'accès sur le disque.

SQL COLUMN tablespace_name FORMAT A15 COLUMN file_name FORMAT A50 SELECT tablespace_name, file_name, bytes / 1024 / 1024 AS "Taille (Mo)", autoextensible AS "Auto" FROM dba_data_files ORDER BY tablespace_name;

Objectif : Identifier quels fichiers composent chaque tablespace et vérifier si l'auto-extension est activée.

Exercice 2 : Audit de la hiérarchie Segments / Extents

Nous allons isoler une table spécifique (par exemple EMPLOYEES) pour voir comment elle consomme l'espace.

A. Voir le segment (Global) :

SQL SELECT segment_name, segment_type, tablespace_name, extents, bytes / 1024 AS "Taille (Ko)" FROM dba_segments WHERE segment_name = 'EMPLOYEES';

B. Voir le détail des extents (Allocation) :

SQL SELECT extent_id, file_id, block_id, bytes / 1024 AS "Taille (Ko)" FROM dba_extents WHERE segment_name = 'EMPLOYEES' ORDER BY extent_id;

Analyse : Notez que block_id indique le début physique de l'allocation dans le fichier de données.

Exercice 3 : Santé des fichiers de contrôle et des Redo Logs

Il est crucial de vérifier que le multiplexage est bien en place.

A. Vérifier les Control Files :

SQL SELECT name, status FROM v$controlfile;

B. Vérifier les groupes et membres de Redo Logs :

SQL SELECT l.group#, f.member, l.bytes / 1024 / 1024 AS "Mo", l.status FROM v$log l JOIN v$logfile f ON l.group# = f.group#;

Interprétation : Si tous les membres d'un groupe sont sur le même disque, votre base n'est pas sécurisée contre une panne matérielle.

Exercice 4 : Statistiques sur les blocs et l'espace libre

Pour savoir s'il est temps d'agrandir un disque ou de réorganiser une table.

SQL SELECT tablespace_name, SUM(bytes) / 1024 / 1024 AS "Libre (Mo)" FROM dba_free_space GROUP BY tablespace_name;

Synthèse visuelle des vues du dictionnaire

Préfixe de vue Portée
DBA_ Tous les objets de la base de données (nécessite les droits admin).
ALL_ Tous les objets auxquels l'utilisateur courant a accès.
USER_ Uniquement les objets appartenant à l'utilisateur connecté.
V$ Vues dynamiques de performance (mémoire vive, statistiques temps réel).

Synthèse du Chapitre

L'architecture de stockage d'Oracle 11g repose sur une imbrication de composants qui permettent de passer de la donnée utilisateur (la ligne) au bit stocké sur le disque dur.

1️⃣ La Pyramide Logique (L'organisation de l'administrateur)

C'est la vision abstraite gérée par Oracle pour organiser les données indépendamment du matériel.

  • Tablespace : Le conteneur principal (ex: USERS).
  • Segment : L'espace total alloué à un objet (ex: la table EMP).
  • Extent : Un morceau d'espace contigu (ex: 1 Mo de blocs).
  • Bloc : La plus petite unité (ex: 8 Ko), là où logent les lignes.

2️⃣ La Couche Physique (L'organisation du Système d'Exploitation)

C'est ce que l'on voit réellement dans l'explorateur de fichiers du serveur.

  • Datafiles : Ils stockent les données des tablespaces.
  • Control Files : Ils maintiennent la structure et la cohérence (le cerveau).
  • Redo Log Files : Ils sécurisent chaque modification (la boîte noire).

🌉 3. Le Pont : Correspondance Logique vs Physique

Le point de contact entre ces deux mondes est la relation Tablespace ↔ Datafile.

Structure LOGIQUE ↔ Structure PHYSIQUE
Base de Données ↔ Ensemble de tous les fichiers
Tablespace ↔ Un ou plusieurs Datafiles
Bloc Oracle ↔ Un ou plusieurs Blocs OS

4️⃣ Aide-mémoire pour le DBA (TP)

Pour naviguer dans cette architecture, le dictionnaire de données propose des vues spécifiques :

  • DBA_TABLESPACES : Liste des conteneurs logiques.
  • DBA_DATA_FILES : Liste des fichiers physiques et leur taille.
  • DBA_SEGMENTS : Liste des objets (tables/index) consommant de l'espace.
  • DBA_FREE_SPACE : Espace encore disponible dans les tablespaces.