IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Notes pour OCP 9i DBA1

Date de publication : 01/09/2004 , Date de mise a jour : 01/09/2004




7. Segments et structures de stockage
7.1. Les blocs
7.2. Les extensions
7.3. Les segments
7.4. Les segments d'annulation (UNDO)


7. Segments et structures de stockage


7.1. Les blocs

La taille d'un bloc de base de données se définit par le paramètre d'initialisation DB_BLOCK_SIZE.

Structure d'un bloc

  • en-tête : il contient le type de bloc (données, index ou annulation). La partie fixe de l'en-tête fait 24 octets, et la partie variable fait 24*INITRANS, sachant qu'INITRANS vaut 1 pour un bloc de données, et 2 pour un bloc d'index.
  • Répertoire des tables : liste des tables qui ont des données dans ce bloc
  • Répertoires des enregistrements : liste des enregistrements présents dans le bloc
  • Données
  • Espace libre
En moyenne, l'espace occupé pour la gestion interne du bloc est d'environ 100 octets. Il augmente notablement selon la valeur de INITRANS.

Chaque segment possède au moins une liste des blocs disponibles. Le nombre de listes se définit par la clause de stockage FREELISTS.

Lorsqu'un enregistrement est dès sa création trop grand pour tenir en un bloc, il est réparti sur autant de blocs que nécessaire. On appelle cela le chaînage d'enregistrements. Il faut éviter cette situation autant que possible, en prévoyant une taille de bloc suffisante.

Lorqu'un enregistrement existant est modifié, et devient trop grand pour tenir dans le bloc où il se trouve (car il y a d'autres enregistrements dans ce même bloc), mais qu'il peut tenir dans un bloc entier, Oracle transfère l'enregistrement complet dans un nouveau bloc, en laissant un pointeur dans l'ancien bloc. On appelle cela la migration d'enregistrements. Cette opération est coûteuse et doit être évitée.

Les paramètres PCTFREE et PCTUSED permettent de limiter la migration.
PCTFREE spécifie le pourcentage d'espace qui doit rester libre dans un bloc pour de futures mises à jour qui agrandiraient les enregistrements. Par exemple, si PCTFREE vaut 35, on ne peut faire des INSERT dans le bloc qu'à concurrence de 65% de l'espace. Les 35% restants sont réservés pour les UPDATE.
Quand un bloc est plein au sens de PCTFREE, il est retiré de la liste des blocs disponibles (FREELIST).
PCTFREE doit avoir une valeur élevée quand des mises à jour qui agrandissent largement les enregistrements sont attendues.

PCTUSED spécifie le pourcentage d'espace occupé en dessous duquel un bloc qui a préalablement atteint le seuil PCTFREE est réintroduit dans la FREELIST.
Si PCTUSED=40, cela signifie que le bloc redevient disponible dès qu'il est occupé à moins de 40% . C'est à dire qu'il doit y avoir au moins 60% d'espace libre dans le bloc pour qu'on puisse y refaire des INSERT.
Cela permet d'attendre qu'un espace suffisamment grand soit disponible dans le bloc avant d'y refaire des insertions. Si le bloc était déclaré réutilisable dès qu'il retombe juste en dessous de l'occupation définie par PCTFREE, on aurait des va et vient incessants du bloc vers la FREELIST.
PCTUSED peut être défini pour une table, mais pas pour un index.

La somme PCTFREE + PCTUSED doit être inférieure à 100.
PCTFREE vaut 10 par défaut, et PCTUSED 40.

Dans un tablespace géré localement en mode AUTO, PCTUSED est ignoré, alors que PCTFREE est pris en compte.

INITRANS spécifie combien d'entrées doivent être réservées dans l'en-tête de bloc pour les transactions simultanées. Chaque entrée occupe 24 octets, il faut donc ne pas surestimer INITRANS. INITRANS vaut par défaut 1 pour un segment de données, et 2 pour un segment d'index.
MAXTRANS spécifie combien de transactions simultanées peuvent avoir lieu dans le bloc. Si INITRANS est dépassé, l'espace de gestion est pris dans la zone de données du bloc. Cet espace supplémentaire n'est ensuite jamais libéré pour stocker des données; il est adjoint à l'en-tête du bloc.
La valeur maximale de MAXTRANS est de 255; la valeur par défaut dépend de l'OS.

Gestion automatique de l'espace libre (ASM)
Dans les tablespaces gérés localement (EXTENT MANAGEMENT LOCAL), l'espace libre peut être géré automatiquement.
Pour cela, il faut spécifier SEGMENT SPACE MANAGEMENT AUTO. Ce paramètre est valable pour tout le tablespace, et ne peut pas être spécifié individuellement pour chaque objet qui y est stocké.
Le mode AUTO s'occupe de manière transparente de la réutilisation des espaces libres, sans qu'on doive spécifier le paramètre PCTUSED. Dans le mode AUTO, la notion de FREELIST disparaît, car les espaces libres sont gérés par des champs de bits.


7.2. Les extensions

La taille et le nombre des extensions d'un segment se paramètrent par la clause STORAGE, qui comporte uniquement les options INITIAL, NEXT, PCTINCREASE, MINEXTENTS et MAXTENTS.
Les paramètres sur la gestion de l'espace libre et des transactions simultanées (INITRANS, MAXTRANS, PCTUSED, PCTFREE et FREELISTS) se spécifient hors de la clause STORAGE.

Dans un tablespace géré localement, les paramètres PCTUSED, FREELISTS et FREELIST GROUPS sont ignorés.

Lors d'un DELETE, les extensions libérées ne sont pas supprimées.
Pour les supprimer manuellement, il faut exécuter ALTER TABLE nom_table DEALLOCATE UNUSED.

A l'inverse, TRUNCATE supprime les extensions libérées, sauf celles allouées à concurrence du MINEXTENTS.
Si l'option REUSE STORAGE est spécifiée, les extensions libérées sont maintenues.

Dans un tablespace géré par le dictionnaire, l'allocation d'une nouvelle extension se fait comme suit :
Si plus de 5 blocs sont demandés, 1 de plus est demandé. Sinon le nombre exact est demandé.
Si une extension libre fait exactement la taille requise, elle est utilisée. Sinon une extension libre plus grande est utilisée, l'espace requis est alloué est le reliquat est répertorié dans la liste des extensions disponibles.
En dernier recours, le fichier est agrandi s'il est en mode AUTOEXTEND ON.

La vue DBA_EXTENTS liste les extensions allouées, alors que la vue DBA_FREE_SPACE liste les extensions libres.


7.3. Les segments

Chaque, table, index, cluster ou vue matérialisée constitue un segment. Pour les objets partitionnés, chaque partition est matérialisée par un segment distinct.
Une colonne de type LOB n'est pas stockée dans le segment de base de la table.

Il existe plus d'une dizaine de types de segment :

  • table
  • table partitionnée
  • index
  • index partitionné
  • IOT
  • Temporaire
  • Table imbriquée
  • LOB
  • Annulation
Les vues DBA_SEGMENTS et V$SORT_SEGMENT fournissent respectivement des informations sur les segments ordinaires et sur les segments temporaires. V$SORT_SEGMENT peut être vide si aucune opération nécessitant un segment temporaire n'est en cours.

Depuis Oracle 9.2, la vue V$SEGMENT_STATISTICS (avec un S !) fournit des statistiques sur les segments.


7.4. Les segments d'annulation (UNDO)

Le tablespace SYSTEM comporte automatiquement son propre segment d'annulation, qui est utilisé pour les transactions qui concernent le dictionnaire de données.
Par ailleurs, il faut créer un tablespace d'annulation supplémentaire, pour les opérations applicatives.

Chaque transaction utilise un segment d'annulation distinct.
Un seul tablespace d'annulation peut être actif à un moment donné; il en existe donc généralement un seul, qui doit être suffisant pour supporter toutes les transactions simultanées.

Depuis Oracle 9i, la gestion des segments d'annulation peut être automatisée; la gestion manuelle, toujours possible, est considérée comme dépassée.

Le mode de gestion de l'annulation est défini par le paramètre d'initialisation UNDO_MANAGEMENT=AUTO/MANUAL.
Le tablespace d'annulation courant se spécifie par le paramètre d'initialisation UNDO_TABLESPACE=nom_undo_tbs
Le paramètre d'initialisation UNDO_RETENTION spécifie pendant combien de temps, en secondes, les entrées d'annulation sont maintenues après validation de la transaction. Sa valeur par défaut est de 900 secondes, soit 15 minutes.

Le tablespace d'annulation se crée généralement lors du CREATE DATABASE, par la clause UNDO TABLESPACE nom_tbs DATAFILE
A défaut de création explicite, Oracle crée un tablespace d'annulation appelé SYS_UNDOTBS, et placé dans %ORACLE_HOME%\database.

Divers vues fournissent des informations sur les éléments d'annulation :

  • DBA_ROLLBACK_SEGS liste les segments d'annulation, actifs ou non
  • V$ROLLNAME ne liste que les segments d'annulation actifs
  • V$ROLLSTAT fournit des informations détaillées sur l'activité des segments d'annulation
  • V$UNDOSTAT maintient des statistiques par tranches de 10 minutes sur l'activité des segments d'annulation