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:
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.

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;
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
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 :
|
|
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 :
Pour les indexes :
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).

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 :
Ce type de tuning requiert beaucoup de temps et d'études techniques.
Dans la méthode 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.
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.
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 01/2011 | Version initiale |
Oracle 9i R2 BOL : Specifying Segment Space Management in Locally Managed Tablespaces