TP11 - Administration/Tuning

MIAGE #3 - 2006/2007
January 9, 2007

1 Architecture physique d’une base Oracle

1.1 La structure physique
Une base de données Oracle est composé de fichiers (au sens du système
d’exploitation de la machine sur laquelle est installée la base). On distingue
- les fichiers de données qui contiennent les objets de la base de données:
le dictionnaire, les structures de données utilisateurs, les objets “procedu-
raux”: triggers, procedure stockées.
- les redo log files (fichiers historiques, journaux) qui conserve une trace
de l’activité transactionnelle, essentiellement dans la perspective d’une
restauration de toute ou partie de la base après un incident.
- les control files contiennent des informations sur la base de données: date
de création, noms des fichiers de données, des fichiers journaux, leurs
numéros de séquence (pour gérer leur utilisation cyclique) . . .
Dès que la base de données est modifiée (fichier de données supplemen-
taires, changement de support de certains fichiers) ces informations sont
consignées dans le control file. Ces informations sont particulierement
utiles au démarrage (startup) et à l’arrêt de la base (shutdown)
Les fichiers de données alloués à la base constitue l’espace mémoire dans lequel
le SGBDR Oracle installera ses propres structures d’information. Oracle se
comporte vis à vis de l’espace disque qu’il lui est alloué comme un système
d’exploitation.

1.2 L’organisation interne d’une base Oracle

Pour le SGBDR, la base de données se compose de tablespaces. Un tablespace
est constitué de plusieurs fichiers physiques (situés éventuellement sur des dis-
ques differents).
Tout objet d’une base de données occupe une partie de l’espace de stockage d’un
des tablespaces).

1
La taille d’un objet de la base peut évoluer à l’interieur du tablespace (il pour-
rait résider physiquement sur plusieurs fichiers et pourquoi pas sur plusieurs
disques).
Les tablespaces peuvent être activés (online) ou désactivés (offline) individuelle-
ment pour d’éventuelles opérations de maintenance. Les objets d’un tablespace
offline ne sont plus accessibles, sans que cela ne perturbe l’accès aux objets des
autres tablespaces.
L’interêt d’une telle structuration:
- amélioration de la tolérance aux pannes disque: affecter les fichiers de données
d’un même disque (ou d’un même contrôleur de disque) à une même tablespace
permet de réduire l’impact d’une panne à un seul tablespace.
- Amélioration des performances- diminution des contentions disques- par exem-
ple en placant tables et index dans différents tablespaces (corespondant à differ-
ents disques). Un placement judicieux des tables et index dans les tablespaces
en fonction de leurs utilisations peut influer sur les performances globales du
système.
Les tablespaces peuvent être étendus par allocation de nouveaux fichiers auprès
du système d’exploitation de la machine serveur.
Le tablespace SYSTEM est nécessaire au fonctionnement d’une BD Oracle, il
contient notamment le dictionnaire de la base.
create tablespace <nom>
datafile <chemin/nom> size XXXM
default storage(....)
[online|offline]

1.3 Structure des TableSpaces

Les tablespaces se décomposent en segments (1 segment ≡ 1 objet): data seg-
ments (tables), index segments, rollback segments, temporary segments. Les
segments temporaires ne sont pas crées directement par les users, mais sont
générés par le système lorsque celui-ci a besoin d’espace de stockage pour réaliser
certaines opérations telles que tri ou création d’index.
Lorsq’un objet est crée, le tablespace auquel il est affecté résulte de plusieurs
facteurs;
- à quels tablespaces, l’utilsateur a-t-il accès
- quels privilg̀es système ont été accordés à cet utilisateur
- quelles options a-t-on précisées au moment de la création de l’objet
Illustration
create user x identified by <password> create table A( create table B(
default tablespace TA no number(8), ... id number(8) ...)
temporary tablespace TA text varchar2(220)); tablespace TB;
quota unlimited on TA
quota 10MB on TB;

2
1.4 Structure des segments
Dans le souci d’éviter ou au moins de minimiser la fragmentation des segments,
le système permet (au DBA) de contrôler l’allocation et l’utilisation de l’espace
mémoire par l’ajustement de ce qu’on appelle les paramètres de stockage.
Une segment est constitué de un ou plusieurs extends qui correspondent aux
zones mémoire allouées aux segments. L’initial extend est alloué lors de la
création du segment (i.e de l’objet). Les next extends sont générés par le système
dès que l’espace n’est plus suffisant pour prendre en compte les changements
apportés au niveau de l’objet. Il est également possible de définir la taille des
extends (initial, et first next) ainsi que le facteur de croissance d’un extend par
rapport au dernier alloué. Chaque extend est constitué de blocs contigus (1 bloc
∼
= 8Ko).

A Chaque ligne d’une table est assignée un ROWID qui correspond à l’adresse
physique de la ligne: block.row.file en représentation hexadécimale 1 : Le numéro
du bloc dans le fichier, le numéro de la ligne dans le bloc, le numero du fichier.
Les rowid sont utilisés dans la constitution des index (pointeur de la ligne). Le
rowid est le mode d’accès le plus direct à une ligne - accès direct.
En terme d’efficacité on ne peut faire mieux que select * from T where rowid
= ’OOOOOOFFFBBBBBBRRR’2

Question 1 Faı̂tes le constat que toutes vos tables sont situés dans le même
tablespace.
Faı̂tes le constat que la plupart de vos tables sont toute entière contenues dans
un même bloc de données.

Question 2 Créer la table test11(filler char(1000)).

Quel est à votre avis l’espace occupé par 1 ligne de cette table ?
En observant les adresses, relever le nombre de blocs occupés par les lignes de
cette table après
• l’insertion de 7 lignes
• l’insertion de 7 lignes supplémentaires
1 Représentation sous forme de chaı̂ne Base64 à partir d’Oracle 9i
2 An extended rowid has a four-piece format, OOOOOOFFFBBBBBBRRR:
• OOOOOO: The data object number that identifies the database segment (AAAAao in
the example). Schema objects in the same segment, such as a cluster of tables, have
the same data object number.
• FFF: The tablespace-relative datafile number of the datafile that contains the row (file
AAT in the example).
• BBBBBB: The data block that contains the row (block AAABrX in the example).
Block numbers are relative to their datafile, not tablespace. Therefore, two rows with
identical block numbers could reside in two different datafiles of the same tablespace.
• RRR: The row in the block.

3
 • l’insertion de 7 lignes supplémentaires

1.5 Paramétres de Stockage

Valeur des valeurs des différents paramètres évoqués çi-dessus pour un objet, ou,
au niveau d’un tablespace, pour les object qui y seront créés sans spécification
de paramètres de stockage.
Exemple: storage( initial 20MB, next 10MB, minextends 3, maxextends
3, pctincrease 15, freelists 33 ).
Les paramétres de stockage definis au niveau du tablespace sont adoptés comme
paramétres par défaut pour tous les objets crées à l’intérieur du tablespace. Il
est également possible de mentionner explicitement les paramétres de stockage
d’un objet lors de sa création.

Question 3 Les paramètres de stockage des tables peuvent être consultés par
le biais de la vue du dictionnaire USER TABLES.
Constater par le biais d’une requête sur USER TABLES, que toutes vos tables ont
les mêmes paramètres de stockage. Les quels ?

1.6 La structure des Blocs Oracle

La petite unité mémoire composant un segment n’est pas l’extend mais le bloc.
Les blocs correspondent aux unités d’échanges de données entre mémoire cen-
trale et mémoire de masse. Quand on crée un objet de la database, on peut
au delà des caracteristiques des extends, influer sur la gestion interne les blocs
eux-mêmes au travers des paramétres: PCTFREE, PCTUSED.
• PCTFREE est utilisé pour indiquer le pourcentage du bloc qui ne peut pas
être rempli par des insertions dans la table (ce qui veut dire cette partie
est reservé pour des mise-à-jour des enregistrements présents dans le bloc.
• PCTUSED définit le pourcentage d’espace qui doit être occupé par des en-
registrements avant qu’un bloc vierge soit utilisé.
Un bloc est divisé en deux parties: l’entête de bloc et la partie donnée.
L’entête contient des informations générales comme:
- row directory - répertoire de lignes de la table contenues dans le bloc
-transaction directory - répertoire des transactions en cours modifiant le contenu
du bloc.
La partie données est subdivisée en deux parties: insert area partie destiné à
recevoir de nouvelles lignes.
free area partie du bloc reversé à l’augmentation de taille des articles exis-
tants. Cette partie est particulierement importante dans le cas où les blocs
stockent des données de type VARCHAR (chaine de careactr̀es de longueur vari-
able) ou VARCHAR2. Pour ces types de données, le système alloué juste la place
3 ce dernier paramétre prend toute son importance lorsque de nombreuses insertions sont

réalisés en parallèle dans une table. Dans ce cas ce paramétre peut être supérieur à 1

4
néceéssaire au stockage de la valeur courante; des mise-à-jour ultérieurse peu-
vent donc augmenter de façon très significative la taille des enregistrements. De
telles variations de taille peuvent également intervenir lors de mises-à-jour de
valeurs NULL. La free area est là pour assurer autant que faire se peut que la
taille d’un enregistrement puisse augmenter tout en restant dans le même bloc.
Si la free area n’est pas suffisamment grande pour qu’on puisse pratiquer l’opération
de mise-à-jour, alors la totalité de l’enregistrement est déplacé dans un autre
bloc. Cet enregistrement reste lié (chaı̂né) à son bloc d’origine. Cela n’entraine
donc aucune mise-à-jour des index correspondants.

Le second paramètre important est PCTUSED, il assure que les blocs seront
occupés de la façon la plus égalitaire que possible. En effet, les nouveaux en-
registrements seront inscrits dans des blocs - qui n’ont pas encore atteint le
niveau d’occupation PCTUSED- ou qui par suite d’opérations de mise-à-jour
sont tombés sous ce niveau d’occupation. Tous les blocs qui rentrent dans cette
catégorie sont intégrés à la liste des blocs “libres”, c’est-à-dire disponible pour
des opérations d’insertion. Néanmoins un bloc ne sera choisi que s’il dispose de
suffisammment de place. Dès que la limite PCTUSED est de nouveau atteinte,
le bloc est retiré de la liste des blocs libres.
Les blocs de données peuvent donc être dans l’une des trois situations suivantes;
-bloc utilisé sous le niveau PCTUSED
-bloc utilisé au dessus du niveau PCTUSED
-bloc alloué à l’extend et non utilisé
L’espace libéré par une suppression ou une mise-à-jour ne devient disponible
qu’une fois la transaction achevée. Cela signifie que, pour respecter l’exécution
d’une transaction, la liste des blocs libres doit être regardée sous deux angles:
la liste des blocs libres du segment, et en complément une liste additionnelle des
blocs descendus sous le PCTUSED durant la transaction. Si dans le courant
de la même transaction, un ordre d’insertion est exécuté , le SGBDR Oracle
ira d’abord rechercher un bloc libre dans cette liste interne à la transaction.
Si l’espace réclamé excéde celui disponible au travers de la free list interne à
la transaction , le système a alors recours à la free list du segment, s’il s’avère
que l’opération n’est toujours pas possible , alors on va puiser dans les blocs
inutilisés du segment (qui rentrent alors dans la free list). Si cela n’est pas
possible non plus, alors le système générera un nouvel extend de taille next +
(next*pctincrease/100.
Les opérations d’insertion font un usage intensif du mécanisme de free list, de
sorte qu’il peut apparaitre comme une bonne idée , lorsque les tables font l’objet
de nombreuses insert parallèles, de créer plusieurs free lists.

Utilisation de Enterprise Manager Console

Connectez-vous sous l’outil d’Administration:

Question 4 A partir de l’item stockage du navigateur, relever les tailles, pour-

centages d’utilisation, paramètres de stockage des tablespaces System, MIAGE

5
 S Table Index
Y
Filex
S
T Segments
FileY
E
M

Extends
Initial Next

Header : Row Directory Blocs de

TableSpaces 2 Ko
Free Area

Bloc:
Row --
Row --
Row --

Question 5 A partir de l’item sécurité/utilisateur, relever les rôles, privilèges

système vous concernant en tant que user oracle.
Question 6 Que permet le rôle connect

1.7 La commande ANALYZE

La commande ANALYZE déclenche l’évaluation d’indicateurs calculés sur une ta-
ble; cette évaluation peut être effectuée sur l’ensemble de la table (COMPUTE
STATISTICS) ou sur une échantillon de lignes (ESTIMATE STATISTICS). Les
valeurs de ces indicateurs sont mémorisés dans le dictionnaire de la base. On
peut y accéder soit par le biais de programme spécificiques, soit en consultant
la vue USER TABLES.
ANALYZE TABLE <TABLE_NAME> COMPUTE STATISTICS ;
Créer la table suivante : test(no char(3), filler char(97)). Attention: les valeurs
de l’attribut no devront correspondre à des nombres entiers compris entre 0 et
999. Poser sur cette table, au moment de sa création, la contrainte déclarative
correspondante.
Question 7 Est-ce que la longueur des tuples de cette table est variable ?
Quelle serait la valeur la plus appropriée pour le paramètre PCTFREE.
Parmi les indicateurs de volumétrie qu’Oracle peut déterminer sur une table
figurent :

6
 1. NUM ROWS : nombre de lignes
2. BLOCKS : nombre de blocs utilisés
3. EMPTY BLOCKS : nombre de blocs alloués, mais non utilisés
4. AVG SPACE : espace libre moyen dans les blocs utilisés
5. AVG ROW LEN : longueur moyenne des lignes
Ces informations sont (ré)évaluées par la commande analyze table nom table
compute statistics. Elles sont accessibles notamment dans la vue USER TABLES.
On pourra aussi les consulter par le biais de DBA-Studio en se positionnant sur
la table (item schéma/user/table du navigateur).

Question 8 Relever l’évolution des ces indices:

1. après la création de la table
2. après insertion de 50 lignes
3. après insertion de 50 lignes supplementaires
4. après insertion de 100 lignes supplementaires
Comparer à chaque fois l’espace réellement occupé par la table et l’espace
théoriquement nécessaire à sa mémorisation . Comment expliquer cette différence
?

Question 9 Faites ”grossir” la table jusqu’à ce que vous constatiez l’allocation

d’un nouvel extend à la table. Cela correspond-il aux paramètres de stockage
de la table.

Question 10 Supprimer les 1/3 des lignes de cette table (ceux dont le no est
divisible par 3).
Réévaluer les statistiques sur cette table à l’issue de cette opération.
En déduire quelques éléments sur la stratégie d’allocation des blocs à une table
par le SGBDR Oracle.

Question 11 Supprimer l’intégralité des lignes, commiter et regénerez les statis-

tiques. Que constatez-vous ?
Effectuez un truncate table test et regénérez les statistiques. Que constatez-
vous ?