Tablespaces et fichiers de données

1. Vue d’ensemble

Un tablespace est une unité logique de stockage composée d’un ou plusieurs fichiers physiques (fichiers de données).

La majorité des opérations d’administration relatives au stockage s’effectue au niveau du tablespace, et non au niveau des fichiers de données.

À l’intérieur d’un tablespace, le stockage est organisé en segments, composés d’une ou de plusieurs extensions (extent). Ces extensions peuvent être gérées "par le dictionnaire" ou "localement". Dans le premier cas (tablespace géré par le dictionnaire), les informations sur les extensions libres et allouées sont stockées dans des tables du dictionnaire de données ; dans le second cas (tablespace géré localement), les informations sur les extensions libres et allouées sont stockées dans l’en-tête des fichiers de données du tablespace.

En version 10, Oracle a introduit la notion de tablespace BIGFILE : un tablespace BIGFILE est un tablespace composé d’un seul fichier de données qui peut être particulièrement volumineux (jusqu’à 2^32 - 3 blocs Oracle soit plus de 4 milliards de blocs). A contrario, un tablespace traditionnel, dorénavant appelé tablespace SMALLFILE, peut contenir plusieurs fichiers de données (jusqu’à 1 022 fichiers), mais de taille plus limitée ("seulement" 2^22 - 2 blocs Oracle, soit tout de même plus de 4 millions de blocs).

Lorsqu’un tablespace SMALLFILE contient plusieurs fichiers de données...

1. Création d’un tablespace permanent

L’ordre SQL CREATE TABLESPACE permet de créer un tablespace permanent.

Syntaxe simplifiée

CREATE [ BIGFILE | SMALLFILE ] TABLESPACE nom 
DATAFILE spécification_fichier [,...] 
[ clause_gestion_extension ] 
[ clause_gestion_segment ] 
[ BLOCKSIZE valeur [K] ] 
[ LOGGING | NOLOGGING ] 
[ FORCE LOGGING ] 
[ FLASHBACK { ON | OFF } ] 
[ ONLINE | OFFLINE ] ; 
       - spécification_fichier 
'nom_fichier' [ SIZE valeur [K|M|G|T] ] [REUSE] 
[ clause_auto_extension ] 
       - clause_auto_extension 
AUTOEXTEND OFF 
| AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ] 
               [ MAXSIZE UNLIMITED | valeur [K|M|G|T] ] 
       - clause_gestion_extent 
EXTENT MANAGEMENT DICTIONARY 
| EXTENT MANAGEMENT LOCAL 
           { AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M|G|T] ] } 
       - clause_gestion_segment 
SEGMENT SPACE MANAGEMENT { MANUAL | AUTO } 

Exemple

Tablespace pour les tables, avec une gestion locale uniforme des extensions :

CREATE TABLESPACE data 
DATAFILE 'e:\app\oracle\oradata\hermes\data01.dbf' SIZE 500M 
       AUTOEXTEND ON NEXT 100M MAXSIZE 800M 
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M 
SEGMENT SPACE MANAGEMENT AUTO; 

Tablespace pour les index, avec une gestion locale automatique des extensions :

CREATE TABLESPACE indx 
DATAFILE 'e:\app\oracle\oradata\hermes\indx01.dbf' SIZE 500M 
       AUTOEXTEND ON NEXT 100M MAXSIZE 800M 
EXTENT MANAGEMENT LOCAL AUTOALLOCATE 
SEGMENT SPACE MANAGEMENT AUTO; 

Les options de l’ordre SQL CREATE TABLESPACE sont :

BIGFILE | SMALLFILE

Cette clause indique si le tablespace est un tablespace BIGFILE ou SMALLFILE. Si cette clause est omise, Oracle utilise le type par défaut défini au niveau de la base...

1. Principes

L’organisation du stockage à l’intérieur d’un tablespace peut être résumée par le schéma ci-après.

À l’intérieur d’un tablespace, le stockage est organisé en segments contenant une ou plusieurs extensions (extents), une extension étant un ensemble de blocs Oracle contigus.

Lorsqu’un segment est créé dans un tablespace, Oracle lui alloue une ou plusieurs extensions dans un des fichiers de données du tablespace. Lorsque l’espace initialement alloué est plein (suite à l’insertion de données par exemple), Oracle alloue une nouvelle extension au segment, et ainsi de suite. Toutes les extensions allouées à un segment sont dans le tablespace de création du segment, mais pas obligatoirement côte à côte, ni forcément dans le même fichier de données (si le tablespace est composé de plusieurs fichiers de données). Lorsqu’un segment est supprimé, les extensions qu’il occupe sont libérées et rendues disponibles pour d’autres segments. Des créations/suppressions fréquentes de segments dans un tablespace peuvent donc conduire à une fragmentation de l’espace disponible dans ce tablespace.

Pour mémoire, il existe quatre types principaux de segments :

La première extension d’un segment contient au minimum deux blocs, le premier étant réservé à l’en-tête du segment (ne contient pas de données utiles mais la carte des extensions allouées au segment). Il en est de même pour chaque fichier de données du tablespace ; le premier bloc est un bloc d’en-tête (nous verrons bientôt que l’en-tête du fichier peut contenir davantage de blocs).

Nous verrons au chapitre Gestion...

1. Rôle du tablespace temporaire

Lorsqu’une requête nécessite un tri (clause ORDER BY par exemple), Oracle tente de faire le tri en mémoire, dans la PGA du processus serveur qui exécute la requête.

Si le tri ne tient pas en mémoire, Oracle le découpe en morceaux et trie chaque morceau individuellement en stockant des résultats intermédiaires sur disque dans des segments temporaires.

Un segment temporaire peut être créé dans n’importe quel tablespace mais ce n’est pas souhaitable pour les performances.

Oracle recommande donc de créer un tablespace dédié, de type TEMPORARY, pour stocker les segments temporaires, et de préférence un tablespace temporaire géré localement. Il est possible de créer un tablespace temporaire géré par le dictionnaire mais les performances sont alors limitées et ce choix est déprécié par Oracle ; c’est pourquoi nous ne l’évoquerons pas davantage.

Les requêtes qui peuvent demander un tri sont les suivantes :

Utiliser un tablespace permanent comme tablespace temporaire est possible (c’est ce qui passe par défaut avec le tablespace SYSTEM) mais ce n’est pas conseillé, notamment du point de vue des performances. En effet, dans un tablespace permanent, les segments temporaires sont alloués et libérés à chaque tri ; c’est mauvais pour les performances et cela risque de fragmenter l’espace disponible du tablespace. Dans le cas de l’utilisation d’un tablespace temporaire, un seul segment de tri est créé par le premier tri et réutilisé par les tris suivants.

Le segment temporaire peut être partagé par plusieurs tris (mais pas les extensions) et il est libéré uniquement lors de l’arrêt de l’instance ; de cette manière, il y a moins d’allocation dynamique d’extensions et les performances s’en trouvent optimisées.

1. Principes

Oracle peut prendre complètement en charge la gestion physique des fichiers en déterminant un nom et un emplacement lors de la création des fichiers et en supprimant physiquement les fichiers lorsque la structure logique associée est supprimée. Cette fonctionnalité est appelée Oracle Managed Files (OMF).

Cette gestion peut concerner les fichiers de données des tablespaces, les fichiers de journalisation, les fichiers de contrôle, mais aussi les fichiers de journalisation archivés et les sauvegardes RMAN.

La seule chose que l’administrateur doit faire, c’est définir l’emplacement des fichiers à l’aide de paramètres.

Cette fonctionnalité est particulièrement intéressante pour les bases de données de test ou les petites bases de données, pour lesquelles le stockage n’est pas critique. Cette fonctionnalité est aussi intéressante dans le cas de l’utilisation d’un gestionnaire de volumes logiques où il n’y a pas de contrôle sur l’emplacement physique réel des fichiers. En complément, l’utilisation conjointe de tablespaces BIGFILE peut être intéressante ; il n’y a jamais aucune manipulation à faire sur les fichiers de données, qui deviennent « invisibles ».

Par ailleurs, OMF permet d’avoir des scripts d’administration qui fonctionnent sur toutes les plates-formes sans adaptation, puisqu’il n’y a plus besoin de spécifier de chemins ni de noms dans ces scripts.

2. Mise en œuvre

Pour qu’Oracle puisse gérer les fichiers, il faut définir les paramètres DB_CREATE_ FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n (n compris entre 1 et 5) et DB_RECOVERY_FILE_DEST.

Le paramètre DB_CREATE_FILE_DEST définit l’emplacement des fichiers de données et des fichiers « temporaires » (les TEMPFILE des tablespaces temporaires gérés localement)....

1. Avantages des tablespaces gérés localement

Les tablespaces gérés localement présentent de nombreux avantages :

Un des objectifs des tablespaces gérés localement est de rationaliser l’utilisation de l’espace dans les tablespaces et d’éviter le phénomène de fragmentation de l’espace disponible. Cette fragmentation de l’espace disponible peut survenir suite à une forte activité d’allocation/libération d’extensions : il peut y avoir beaucoup d’espace disponible dans le tablespace mais sous la forme d’une multitude de petites extensions non adjacentes. Le risque de fragmentation disparaît complètement dans un tablespace géré localement avec une gestion uniforme des extensions : toutes les extensions allouées dans le tablespace ont forcément la même taille et une extension libérée pourra obligatoirement être réutilisée....

1. Tablespaces et fichiers de données

Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les tablespaces et les fichiers de données :

Les colonnes intéressantes des différentes vues sont présentées ci-après.

DBA_TABLESPACES

Exemple

SQL> SELECT tablespace_name,contents,extent_management, 
  2         allocation_type,bigfile,block_size,status 
  3  FROM dba_tablespaces; 
TABLESPACE_NAME CONTENTS  EXTENT_MAN ALLOCATIO BIG BLOCK_SIZE STATUS 
--------------- --------- ---------- --------- --- ----------...

1. Tablespaces

Dans SQL Developer, ouvrez le dossier Stockage du panneau DBA puis le sous-dossier Tablespace pour accéder à l’écran de gestion des tablespaces :

Sélectionnez un tablespace dans le panneau de gauche pour avoir des détails sur ce dernier :

À partir de cet écran, vous pouvez effectuer diverses actions sur les tablespaces :

Lors de la création d’un tablespace, les caractéristiques principales (nom, type, fichier de données) peuvent être définies sur le premier onglet :

Sur les autres onglets, les valeurs par défaut sont satisfaisantes dans la plupart des cas.

2. Fichiers de données

Dans SQL Developer, ouvrez le dossier Stockage du panneau DBA puis le sous-dossier Fichiers de données pour accéder à l’écran de gestion des fichiers de données :

Sélectionnez un fichier de données...