Méthodes d'allocations des segments avec Oracle 9i. Liste des blocs libres (freelists) vs ASSM (Automatic Storage Space Management)

Introduction

L'allocation des blocs dans une instance Oracle pour un objet (table, index...) peut être réalisée selon 2 méthodes depuis Oracle 9i:

  • Liste des blocs libres (free lists).
  • Gestion automatique de l'espace dans les segments (ASSM - Automatic Storage Space Management).

Ces deux méthodes sont disponibles pour les tablespaces "gérés localement" (locally managed tablespaces).

Le schéma ci-dessous rappelle le stockage des données sous Oracle : un segment (table, index...) dans un tablespace est constitué d'extents. Les extents stockent les blocs Oracle dont la taille est définie par le paramètre db_block_size. Chaque bloc contenant les lignes du segment est également constitué d'une en-tête (header) stockant des meta données.

structure du stockage des segments Oracle

Quelles sont les différences entre les deux méthodes ? Quels sont les avantages et inconvénients avant d'envisager la migration d'un mode de stockage à l'autre ?

La méthode d'allocation des blocs (liste des blocs libres ou ASSM) est définie à la création d'un tablespace en mode "locally managed" avec la clause segment space management dans la syntaxe CREATE TABLESPACE :

create tablespace USERS
datafile '/sop/oracle/SOP1ORA/USER_01.dbf' size 2000M
extent management local
segment space management manual|auto
online;
  • manual : méthode de la liste des blocs libres (freelists). Mode par défaut.
  • auto : méthode ASSM (Automatic Storage Space Management).

Pour retrouver la méthode de gestion de l'espace pour un tablespace (MANUAL ou AUTO), interroger la vue dba_tablespaces

select tablespace_name, segment_space_management from dba_tablespaces;
TABLESPACE_NAME     SEGMENT_SPACE_MANAGEMENT
------------------- ------------------------
USERS               AUTO
HISTO               AUTO

Liste des blocs libres (freelists)

ll s'agit de la méthode d'allocation par défaut lors de la création d'un tablespace en mode "locally managed".

Dans la méthode des blocs libres :

  • Le bloc d'en-tête de chaque segment contient une liste de blocs libres.
  • Les blocs sont ajoutés ou retirés aux listes de blocs libres au fur et à mesure des mises à jour.
  • La liste des blocs libres est analysée pour rechercher des blocs disponibles.
structure du stockage PCTFREE/PCTUSED

Les paramètres PCTUSED et PCTFREE à la création d'un segment contrôlent l'espace utilisé dans un bloc :

create table RISK.TITRES ( ... )
PCTFREE 10 PCTUSED 40;

Pour les tables :

  • PCTFREE est le pourcentage minimal d'espace dans un bloc réservé aux mises à jour de lignes existantes. Lorsque le taux d'espace libre devient inférieur au paramètre PCTFREE, le bloc n'est plus disponible pour des insertions.
  • PCTUSED est la limite inférieure pour le taux d'utilisation d'un bloc. En dessous de cette limite PCTUSED, le bloc est disponible pour des insertions.

Pour les indexes :

  • PCTFREE est l'espace réservé dans un bloc pour les nouvelles entrées d'un index après sa création.
  • PCTUSED n'est pas appliquable aux indexes (0).

PCTFREE et PCTUSED sont les paramètres pour chaque segment qui vont gouverner la liste des blocs libres disponibles lors des opérations de mise à jour.

Dans cette méthode, les blocs d'en-tête d'un segment sont régulièrement mise à jour et balayés lors de la recherche de blocs libres, ce qui génère potentiellement de la contention lors d'opérations de mise à jour intensives (INSERT/UPDATE/DELETE).

contention freelist

Cette contention se manifeste par des évènements "buffer busy waits" liés aux blocs d'en-tête.

Event                       Waits   Timeouts   Time (s)   (ms)     /txn
-------------------- ------------ ---------- ---------- ------ --------
buffer busy waits         154,553          0        942      6      9.4

Dans l'exemple de rapport Statspack ci-dessus, un fort taux d'évènement d'attente "Buffer busy waits" par transaction est observé (9.4 par transaction), alors que l'instance n'est pas en manque de cache. Durant ce rapport Statspack, des insertions massives sont réalisées (28 433) :

INSERT INTO SIEBEL."EIM_ADDR_PER" (ROW_ID,CREATED,CREATED_BY,LAS
T_UPD,LAST_UPD_BY,MODIFICATION_NUM,CONFLICT_ID,AP_ADDR_NAME,IF_R
OW_BATCH_NUM,IF_ROW_STAT,IF_ROW_STAT_NUM,ADPR_ADDRVERIF_FLG,AP_A
CTIVE_FLG,AP_CON_PRIV_FLG,AP_DISACLEANSE_FLG,AP_END_DT,AP_INFO_R
ECORD_DT,AP_LATITUDE,AP_LONGITUDE,AP_NAME_LOCK_FLG,AP_PREMISE_FL

Cet évènement d'attente "buffer busy waits" lors d'insertions et de mises à jour est généralement causé par de la contention sur l'entête du segment (segment header) pour rechercher les blocs libres dans la liste des blocs libres (freelists).

La table StatsPack stats$waitstat permet d'aller plus loin et rechercher plus spécifiquement le pourcentage des évènements d'attente liés à la contention sur les entêtes de segments, et donc la liste des blocs libres. La recherche est réalisée sur la colonne class de la table stats$waitstat pour la valeur "segment header".

Pour réduire la contention sur cette liste de blocs libres, il est possible de tuner finement pour chaque segment les paramètres ci-dessous :

  • FREELISTS : nombre de listes de blocs libres pour un segment, augmentation pouvant générer des surconsommations d'espace et un marqueur de cru (HWM - High Water Mark) très élevé pour le segment.
  • FREELIST GROUPS : plus particulièrement réservé à Oracle RAC (Real Application Clusters) et Oracle Parallel Query (OPQ).
  • PCTUSED, PCTFREE pour chaque segment sous réserve de bien mesurer et connaître le comportement de l'application sur les segments.

Ce type de tuning requiert beaucoup de temps et d'études techniques.

La gestion automatique de l'espace dans les segments (ASSM : Automatic Storage Space Management

Dans la méthode ASSM :

  • L'espace est géré avec des blocs bitmaps (BMB : Bitmap Blocks)
  • Les processus concurrents recherchent sur des blocs BMB différents.
  • La disponibilité d'un bloc est indiqué par un bit spécifique.
  • Les taux de remplissage (25, 50, 75 et 100%) sont spécifiés dans les bits.
stockage ASSM

Avec la gestion automatique de l'espace dans les segments, la liste des blocs libres n'est plus nécessaire. Les contentions liées à la recherche de blocs libres est drastiquement réduite. Cette méthode est particulièrement utile avec Oracle Real Applications Clusters (RAC), les processus concurrents recherchant des blocs libres dans des BMB distincts par un mécanisme de hachage de l'id de l'instance et de l'id du processus.

Avec la méthode ASSM, seul le paramètre PCTFREE est important. Les paramètres PCTUSED, FREELIST et FREELIST GROUPS sont ignorés et obsolètes avec la méthode d'allocation ASSM.

Lorsqu'une table est créée avec un paramètre PCTFREE défini à 20% : le bloc est marqué comme saturé et le bit de saturation prend la valeur 1 lorsque le taux d'occupation du bloc dépasse 80%. Le bloc n'est alors plus disponible pour les insertions.

Après des commandes de suppression ou de mise à jour (UPDATE/DELETE), le serveur vérifie à nouveau le taux d'occupation par seuils : 25%, 50%, 75% et 100%. Si l'espace utilisé est inférieur à un seuil lui même inférieur à PCTFREE, le bloc est à nouveau disponible pour les insertions. Dans l'exemple avec PCTFREE défini à 20, le seuil doit redescendre à 75% pour que le bloc redevienne à nouveau disponible pour des insertions.

Conclusions

La méthode d'allocation ASSM est incontestablement la plus souple. Toutes les conditions sont réunies pour démarrer les migrations vers le mode de stockage ASSM : réduction, voire élimination, des contentions sur la recherche des blocs libres, administration et tuning très réduits hormis le paramètre PCTFREE.