Architecture Oracle

Un serveur de données Oracle = instance + base physique !!!!

L'instance Oracle et son paramétrage

La base physique : Les fichiers Oracle

relations instance & fichiers

Zoom sur les fichiers de données (data files)

Zoom sur les fichiers journaux ( (redo) log files )

L'instance

Une instance est caractérisée par son identificateur : SID, généralement une variable ORACLE_SID
positionnée dans l'environnement.
Une instance active, en mémoire ce sont :
- des programmes de fond (services ou processus) qui assurent la maintenance du serveur de
données et les entrées / sorties fichiers
- des process server (dédiés ou non à un utilisateur)
- et une zone globale partagée : la SGA, qui contient essentiellement du cache de buffers

Pour un serveur 8.1.5 (Oracle 8i) sous NT on aura par exemple les principaux services suivants :
- Oracle_nom_home_oracle_TNSListener : qui indique un serveur SQLNet présent (et actif ici) sur la
machine
- OracleServicenom_de_la_base : qui indique qu'un serveur Oracle est présent (et actif ici) sur la
machine

Voir le panneau de configuration NT / services pour info :

ici la base s'appelle b8i1 et le oracle home 'Ora81'

Sur Unix un certain nombre de 'Background processes' tournent sur la machine, le proprétaire est
généralement l'utilisateur Oracle (ce qui permet de les identifier). Les noms de process sont
également suffixés par le nom de l'instance auquels ils sont attachés

Nous sommes ici sur une machine Unix, avec Oracle 8.0.5 d'installé. On a filtré les process actifs sur
le mot oracle. On remarque ici que 2 bases sont actives : l'une s'appelle TESUN et l'autre DEVUN. On
reconnait les process de fond DBWR, LGWR, PMON, SMON, RECO notamment et deux process
utilisateur distants connectés à TESUN...

La base physique : les fichiers Oracle

Une base de données complète est constitué d'un certain nombre de fichiers :

 des fichiers de données (datafiles ou databasefiles)

 des fichiers journaux (logfiles ou redologfiles)
 des fichiers de controle (control files)
  un fichier d'initialisation ou de paramétrage (init file)

et optionnellement

 un fichier de mot de passe (password file)

 et des fichiers d'archivage des journaux

Les fichiers de données initiaux, les fichiers journaux et le control file sont créés par l'ordre SQL
'CREATE DATABASE' :

exemple
ici on crée un seul fichier de données et 2 group de logfiles (mirroir) sur 2 disques différents pour des
raisons de sécurité.

CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE 10M

LOGFILE GROUP 1 ('d:\dataora2\test_log1a', 'd:\dataora2\test_log1b') SIZE 500K,
GROUP 2 ('d:\dataora3\test_log2a', 'd:\dataora3\test_log2b') SIZE 500K;

Généralement ces fichiers ont un nom assez explicite et ont le type '.ora' sur NT ou '.dbf' sur Unix.

Voici un exemple des fichiers installés lors de la création par défaut d'une 8.05 sur NT...

relations entre instance & fichier

Les relations entre process et fichiers de la base physique apparaissent ci-après :

Les fichiers de données (data files)

Les fichiers de données contiennent ... les données proprement dites (essentiellement les tables et
leurs lignes),
mais aussi les autres objets Oracle connexes aux tables : index, vues, synonymes, database links,
procédures stockées, etc.).

Il aurait été plus judicieux de les appeler autrement, mais je traduis le terme Oracle
'data file'...

Ce qui n'est pas vraiment des données...dans les fichiers de données :

 Les Vues , synonymes, database links peuvent être considérés comme des données puisque
"pointent" sur des données dans des tables.
 Les indexes et les clusters n'en sont évidemment pas, mais plutôt des "accélérateurs" de
traitement
 Les procédures stockées (et fonctions et packages) non plus, mais des morceaux de
programmes ([Link]) stockés dans la base.

et pire encore :

 les Images avant ou "rollback segments" qui sont des zones temporaires qui permettent de
"revenir en arrière" sur des mises à jour, ou en d'autres termes d'annuler des transactions

Pourtant tout ce petit monde est stocké dans les data files !

Les fichiers journaux (redo log files)

Les fichiers journaux servent à mémoriser toutes les modifications (validées ou non) faites sur la base,
à des fins de reprise en cas de perte de données physiques.

La journalisation (assurée par le process LGWR) est un mécanisme permanent et obligatoire d'Oracle,
pour assurer un minimum de sécurité des données.
Les fichiers journaux appartiennent à des groupe, et sont remplis de manièrer séquentielle et circulaire
(quand on a fini de remplir le log du groupe courant, on attaque le log du groupe suivant suivant.
Quand on arrive au dernier, on recommence à écrire dans le premier...).

C'est pour ca qu'il faut au minimum 2 (groupes de) redo log.

lorsqu'on boucle un cycle, on perd les premières journalisations qui ont été faites et l'on
ne saura pas toujours restaurer la totalité des données en cas de problème. C'est pour ca
qu'on peut "archiver" tout l'historique des redo logs, en utilisant l'archivage optionnel.

Par sécurité on peut multiplexer ou mirrorer l'écriture dans plusieurs redo log en même temps (sur des
disques différents bien sur).

Dans ce cas on a plusieurs fichiers par groupe, et LGWR écrit tous les fichiers du groupe courant en
même temps.

Voir dans le chapitre sauvegarde, l'utilisation de groupes de log files

Oracle - DBA - Sauvegarde et restauration

 Présentation
 les vues du dictionnaire utiles
 Les cas de récupération automatique
 Rappel des structures physiques utiles
 L'archivage
 Principes d'organisation
o séparation des fichiers de données et des fichiers redologs
o multiplexage des fichiers de controle
o multiplexage des journaux
o multiplexage des logs ARCHIVES

 Sauvegarde complète base fermée (à froid)

 Restauration complète (à froid)

 Sauvegarde partielle base ouverte (tablespace offline)

 Sauvegarde partielle base ouverte (tablespaces on line)
 Restauration partielle base ouverte (tablespace offline)

 restauration du (des) control file(s) perdus

 Sauvegarde / restauration logique par Export / Import

 :-) Bonus track :-) :-) :-) :-) :-) :-) :-)
o scénario complet de sauvegarde, perte de fichier et de reprise avec REDO LOGs
o script SQL de sauvegarde complète base ouverte (HOT Backup) et son script de
nettoyage SQLPlus
o Présentation de Recovery Manager (par Fred. Brunet, 3O)

Présentation
Sauvegarde et restauration, permettent de se prémunir plus ou moins parfaitement de la perte
accidentelle de données physique, fichier de données ou autre.
Principaux cas de figure : corruption de fichier, perte de fichier , perte de disque.
Obéissent à une stratégie :
- Quoi sauvegarder : totalité, tablespace, uniquement les données sensibles, etc.
- Quand : fréquence pluri quotidienne, quotidienne, hebdomadaire, etc.
- Comment : à froid, à chaud, physiquement, logiquement
Répondent à des contraintes :
- disponibité des données : haute, moyenne, basse
- importance relative de certaines données
- temps de reprise
- volume maximum de perte supporté
- économie (par exemple la très haute disponibilité coute cher...)

infos utiles du dictionnaire sur la base et ses fichiers

Nom de la vue infos

v$database description générale de la base
DBA_TABLESPACES description des tablespaces et fichiers
DBA_DATA_FILES description des fichiers de données
v$logfile description des redologsz
v$log_history info sur l'historique de tous les redos issus du control
file
v$log infos sur les groupes et les membres
v$parameter TOUS les parametres d'init de l'instance, y compris
CONTROL_FILES...
v$controlfile nom des control files

Les cas de récupération automatique

Certains problèmes ne relèvent pas de la perte de données physique, mais plutôt de la perte
d'information en mémoire centrale : interruption d'une transaction par exemple. Ces problèmes sont
automatiquement résolus par Oracle :
- echec d'un ordre SQL : provoque une erreur d'execution documentée
- echec de process client (interruption du client, pb réseau, arrêt du shadow process) : provoque un
Rollback de la transaction
- echec de l'instance (arrêt d'un process de fond du serveur, arrêt CPU serveur) : provoqhe un
Rollback immédiat ou différé (au redémarrage de la base...)remarque : certains dispositifs matériel :
disques mirroir, CPUs redondants, machines à très haute disponibilité, etc. peuvent prendre en charge
de manière automatique et transparente les pertes de données physiques, sans passer par un
processus de sauvegarde / restauration.

Rappel des structures physiques utiles

 La base physique
- des fichiers de données (datafiles ou databasefiles)
- des fichiers journaux (logfiles ou redologfiles)
- des fichiers de controle (control files)

+ un fichier d'initialisation ou de paramétrage (init file) et optionnellement un fichier de mot de passe

(password file) et des fichiers
d'archivage des journaux
 >> pour + de détails, voir les fichiers physiques d'Oracle du chapitre DBA / Architecture

Principes d'organisation et de répartition : - multiplexages des fichiers de contrôle

séparation des fichiers de données et des fichiers redologs sur des disques différents -

CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE 10M

LOGFILE GROUP 1 ('e:\dataora\test_log1a') SIZE 500K,
GROUP 2 ('e:\dataora\test_log2a') SIZE 500K;

create tablespace TB1 datafile 'd:\dataora\[Link]' size 100M';

ici on crée un nouveau Tablespace (et donc un fichier de données) sur le même disque
que le fichier du tablespace 'SYSTEM' qui contient le dictionnaire. Ce n'est peut être pas une
bonne idée en terme de performances...

multiplexage des fichiers de controle

pour ce faire il suffit de déclarer plusieurs fichiers de controle, sur des disques différents. Les mises à
jour éventuelles par le noyau Oracle seront faites simultanément dans tous les fichiers. En cas de
perte il suffira de recopier un des autres control file et de le renommer avec le nom du fichier perdu,
puis de redémarrer la base.
la liste des fichiers de contrôle est spécifié dans le fichier de démarrage de la base : [Link]
ex :

INIT_test.ora

DB_NAME = TEST
CONTROL_FILES = (/disk1/test_ctl1.ora, /disk2/test_ctl2.ora)

multiplexage des journaux (redo log files)

On a vu que l'écriture dans les redo logs files est circulaire.

Au minimum une base doit contenir 2 groupes de un fichier.

Pour permettre l'écriture simultanée de plusieurs redo logs et ainsi les sécuriser, on crée 2 fichiers ou
plus par groupe.
exemple : le minimum, 2 groupes contenant chacun un fichier (pas de multiplexage donc...)

CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE 10M

LOGFILE GROUP 1 ('d:\dataora\test_log1a') SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a') SIZE 500K;

un peu mieux, LGWR va ecrire simultanément dans les 2 fichiers du groupe courant

CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE 10M

LOGFILE GROUP 1 ('d:\dataora\test_log1a', 'e:\dataora\test_log1b') SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a', 'e:\dataora\test_log2b') SIZE 500K;

protection max : ceinture ET bretelles (on écrit dans 3 fichiers en même temps)

CREATE DATABASE test DATAFILE 'd:\dataora\test_system' SIZE 10M

LOGFILE GROUP 1 ('d:\dataora\test_log1a', 'e:\dataora\test_log1b' , 'f:\dataora\
test_log1b') SIZE 500K,
GROUP 2 ('d:\dataora\test_log2a', 'e:\dataora\test_log2b' , 'f:\dataora\test_log1b')
SIZE 500K;

si on veut augmenter le temps de rebouclage du cycle d'écriture, ou en d'autres termes

augmenter le délai avant écrasement éventuel du contenu du 1er journal, on peut rajouter des
groupes supplémentaires...

Multiplexage des logs ARCHIVES

on utilise le pramètre LOG_ARCHIVE_DEST_n (où n est un entier de 1 à 5)

LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc/'
LOG_ARCHIVE_DEST_2 = 'LOCATION=/disk2/arc/'
LOG_ARCHIVE_DEST_3 = 'LOCATION=/disk3/arc/'

avec le format suivant

LOG_ARCHIVE_FORMAT = arch%t_%[Link]

on aura le résultat suivant (thread 1; log sequence de 100 à 102)

/disk1/arc/arch1_100.arc, /disk1/arc/arch1_101.arc, /disk1/arc/arch1_102.arc,

/disk2/arc/arch1_100.arc, /disk2/arc/arch1_101.arc, /disk2/arc/arch1_102.arc,
/disk3/arc/arch1_100.arc, /disk3/arc/arch1_101.arc, /disk3/arc/arch1_102.arc

l'archivage des redologs files

Ce processus (process ARCH ou "ARCHIVER") est optionnel et permet de faire des restaurations les
plus à jour possible.
En l'absence d'archivage, on ne pourra récupérer les données que de la dernière sauvegarde. Avec
l'archivage on récupérera ces mêmes données + les modifications qui ont été faites entre la
sauvegarde et le crash. (seules les transactions en cours au moment du crash sont
perdues).L'archivage permet de garder tout l'historique des fichiers redologs, qui sont recopier sur le
répertoire d'archivage dès qu'ils sont pleins (Switch).
Si on n'archive pas les redologs sont écrasés cycliquement, puisque rappelons le, ils sont utilisés de
manière séquentielle et circulaire !
mise en place de l'archivage

autorisation de l'archivage automatique dans [Link] (reg : ORA_TEST_PFILE)

log_archive_start = true
log_archive_dest_1 = "location=C:\Oracle\oradata\TEST\archive"
log_archive_format = %%ORACLE_SID%%T%TS%[Link]

puis arrêt / redémarrage de la base.

Il est possible d'autoriser l'archivage automatique de manière dynamique (sans arrêter

la base :

SQL> ALTER SYSTEM ARCHIVE LOG START;

declenchement du mode archivage

SQL> CONNECT INTERNAL

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG
SQL> ALTER DATABASE OPEN

verification de l'archivage (remplissage ou forcage des logs switchs)

SQL> ALTER SYSTEM SWITCH LOGFILE
voir log_archive_dest_1 et log_archive_format pour voir où les fichiers d'archive créés sur le disque

on peut également vérifier le statut de l'archivage avec la commande :

SQL> ARCHIVELOG LIST

Attention à la prolifération des LOGS archivés, notamment en cas de grosse procédure batch de
mise à jour, il est conseillé de désactiver l'archivage !
Il est conseillé également de purger les archives après chaque nouvelle sauvegarde réussie !

Il est possible comme on l'a vu plus haut de multiplexer les logs archivés pour (encore et toujours)
plus de sécurité

restauration du control file perdu

en cas de perte d'un control file il suffira

 d'arreter la base,
 de vérifier les spécifications des fichiers de controle dans l' [Link],
 et de recopier le fichier manquant à partir d'un de ses jumals dans le répertoire de destination
 de rouvrir la base
Tablespaces et segments d'une Base de données Oracle

les tablespaces

Tablespaces standards (ou PERMANENTs)

Une base peut être décomposée en tablespaces : partitions logiques contenant un ou plusieurs
fichiers.
Un fichier appartient à 1 et 1 seul tablespace.
Un tablespace peut s'étendre soit par ajout (on-line) d'un fichier, soit par auto-extension DU fichier du
tablespace.
Par défaut il existe toujours un tablespace baptisé SYSTEM qui contient le dictionnaire de données et
le rollback segment SYSTEM (dans le cas ou il n'existe pas d'UNDO tablespace).

On peut également stocker les datas et les index dans ce même tablespace, et obtenir ainsi une base
minimale peu structurée, peu perforformante et peu sécurisée :

Au contraire on peut répartir les données, les index, mais aussi les images avant (rollback segments)
sur un nombre maximum de disques. On y gagnera en performance, en souplesse, et en sécurité :

ordres SQL associés aux tablespaces :

SQL> CREATE TABLESPACE ...

SQL> DROP TABLESPACE...
SQL> ALTER TABLESPACE...
 par défaut un tablespace à la création est ON LINE (et donc accessible), il peut être mis
OFFLINE (et les fichiers qu'il continet par conséquent) pour en interdire l'accès ou pour certaines
opérations de maintenance

Description des tablespaces de la base courante dans les vues Dba_tablespaces et Dba_data_files
du dictionnaire.

Les fichiers du tablespace

Un tablespace contient AU MOINS un fichier. Celui ci est créé lors de la création du tablespace, de
manière automatique par Oracle, en fonction des paramètres données par la commande CREATE ou
ALTER tablespace (emplacement du fichier, nom et taille).

lors de la suppression du tablespace (DROP TABLESPACE...) les fichiers

correspondant ne sont PAS SUPPRIMES par Oracle !! il faut le faire manuellement au
niveau Unix ou Windows (rm, del...) !

quelques exemples SQL pour les tablespoaces et les fichiers

rem creation d'un tablespace nommé RBS contenant un fic de 10MO et des EXTENTS de
1MO
CREATE TABLESPACE RBS DATAFILE 'E:\orant\database\TEST\[Link]' SIZE 10M
DEFAULT STORAGE ( INITIAL 1024K NEXT 1024K PCTINCREASE 0);

ALTER TABLESPACE toto OFFLINE;

rem changement des parametres d'un tablespace existant

ALTER TABLESPACE SYSTEM
DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 300 PCTINCREASE 1);

rem Ajout ajout d'un ficheir auto exyensible jusqu'a 100 MO

ALTER TABLESPACE toto ADD DATAFILE 'E:\orant\database\TEST\[Link]' SIZE 10M
AUTOEXTEND ON NEXT 5M MAXSIZE 100M;

rem passage en AUTO extension d'un fichier de tablespace existant

ALTER DATABASE DATAFILE 'E:\orant\database\TEST\[Link]' AUTOEXTEND ON;

extension du tablespace

La taille d'un tablespace est la taille de son (ses) fichier(s) d'origine.

Pour augmenter la taille d'un tablespace, il y a 2 solutions :

 Ajouter un fichier au tablespace, qui sera chainé au premier (ALTER TABLESPACE toto ADD
DATAFILE...)
 mettre le fichier du tablespace en AUTO extension (ALTER DATABASE DATAFILE [Link]
AUTOEXTEND ON)

Une table (et tout segment en général) , peut "s'étaler" sur plusieurs fichiers. Ainsi le fait qu'une
table sature un tablespace n'est pas bloquant il suffit d'augmenter la taille du tablespace.

ATTENTION : la clause AUTOEXTEND specifie la taille d'extension du fichier d'un tablespace.

La clause STORAGE INITIAL, NEXT, MINEXTENTS ... spécifie la taille d'extension d'UN SEGMENT
du tablespace par exemple une table. Ces 2 paramètres sont totalement indépendants. La preuve en
est qu'une table (un segment de données) est forcément en allocation dynamique alors qu'un fichier
peut avoir une taille fixe (AUTOEXTEND OFF)

Les différents types de tablespaces spéciaux

Tablespaces en lecture seule (READ ONLY tablespaces)

Ces tablespaces sont utilisés (on s'en serait douté) en lecture seule. Ils permettent de stocker des
données statiques (ou variant très peu souvent, éventuellement sur des CDROMS, et ne rentrent pas
en ligne de compte dans les sauvegardes / restaurations.
Pour modifier les données d'un Tablespace READ ONLY il est évidemment obligatoire de modifier
préalablement son statut.

SQL> ALTER TABLESPACE toto READ ONLY;

SQL> ALTER TABLESPACE toto READ WRITE;

Tablespaces temporaires (temporary tablespaces)

Ces tablespaces apparus avec la 9i remplacent les segments temporaires placés précédemment dans
des tablespaces standards.
On peut (et doit) créer un tablespace temporarire par défaut autre que SYSTEM, où seront stockées
toutes les données temporaires (utilisées lors des tris, création d'index, jointures, etc). Ils sont définis
lors de la création de la base :

SQL> CREATE DATABASE ma_base...

DEFAULT TEMPORARY TABLESPACE mon_temp;

ou a posteriori :

SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE tempts2;

En plus de ce tablespace temporaire par défaut, chaque utilisateur peut se voir assigner un
tablespace temporaire particulier

SQL> CREATE TEMPORARY TABLESPACE mon_temp TEMPFILE '/oracle/data/[Link]'

SIZE 20M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M

SQL> CREATE USER toto

IDENTIFIED BY tutu
DEFAULT TABLESPACE data
QUOTA 100M ON data
TEMPORARY TABLESPACE temp_ts

Voir les vues dynamiques V$TEMP_EXTENT_MAP et V$TEMP_SPACE_HEADER pour des infos

précises sur l'utilisation en temps réel de ces tablespaces.

Tablespace d'annulation (undo tablespaces)

Les UNDO tablespaces sont exclusivement réservés au stockage de segments d'images avant
modification des données pour des annulations éventuelles (ROLLBACK).

Dans les versions précédentes d'Oracle, ces structures n'existaient pas et on utilisait des
ROLLBACK SEGMENTS implantables dans n'importe quel tablespace. Oracle peut désormais
fonctionner avec des UNDO tablespaces (gestion Automatique, préconisée) ou avec des rollback
segfments (gestion manuelle)
Paramètres de l'[Link] associés

paramètres valeurs but

AUTO |
UNDO MANAGEMENT utiliser les UNDO tbs ou les rollback segments
MANUAL
nom
UNDO TABLESPACE
tablespace précise le tablespace d'UNDO a utiliser par la base
evite les erreurs lorsue l'on tente d'utiliser explicitement les
TRUE | Rollback Segments (ALTER ROLLBACK..., SET
UNDO_SUPPRESS_ERRORS
FALSE TRANSACTION USE ROLLBACK...) alors que la base utilise
des UNDO tbs

SQL spécifice associé

CREATE UNDO TABLESPACE undo_1

DATAFILE '/tmp/[Link]' SIZE 10M AUTOEXTEND ON

ou dès la creation de la base

CREATE DATABASE test...

UNDO TABLESPACE undo_1
DATAFILE '/tmp/[Link]' SIZE 10M AUTOEXTEND ON

Tablespace gérés localement (Locally managed tablespaces)

A la différence des tablespaces standards géré au niveau du dictionnaire de données, la gestion de

l'espace physique (allocation / libération de blocs) se fait dans l'entête du fichier(s) du tablespace. Une
table binaire d'allocation (bitmap) y est maintenue.

Avantages :

 pas de contention en mise a jour au niveau du dictionnaire

 et conséquemment pas d'utilisation de Rollback segment pour ces transactions
 pas de soucis de gestion de l'espace (calcul d'un storage adéquat)
 "coalesce" automatique (fusion des espaces libres contigus pour optimmiser l'espace libre)

Evidemment la clause "DEFAULT STORAGE" est invalide pour les tablespaces gérés
localement.

les segments

un segment est composé d'extents. Un extent est composé de blocs contigus dont la taille dépend de
l'OS. Le segment s'étend dynamiquement au sein du tablespace (éventuellemnt sur plusieurs fichiers
donc...).
Il existe plusieurs types de segments :
- segment de données = table
- segment d'index = index
- segment d'annulation = rollback segment, qui stocke l'image avant modification des données
- segment temporaire , utilisé en interne par Oracle, si la zone mémoire de tri est insuffisante

remarque : seuls les objets 'physiques' peuvent être des segments. Ainsi une vue ou un synonyme
n'est pas un segment...

On peut forcer les segments de données et d'index à s'implanter dans un tablespace particulier :
- explicitement à la création du segment
- implicitement en affectant un tablespace par défaut à l'uttilisateur qui va créer le segment.

SQL> create table credit (n number, ...)

tablespace TBS_COMPTA;
ou bien
SQL> create user Appli_comptable default tablespace COMPTA;
SQL> create table credit (n number, ...);

Description dans la vue dba_segments du dictionnaire.

principe d'allocation des tables spaces

Allocation des Tablespaces standards

L'allocation obéit à des règles définies par une clause STORAGE. Oracle applique d'abord la clause
STORAGE du segment (définie explicitement dans un create table par exemple), sinon il utilise la
clause du tablespace (définie explicitement lors du create tablespace), sinon il utilise les valeurs par
défaut (implicites) du tablespace.

Au départ, lors de la création du segment (table, index ou autre) Oracle alloue MINEXTENTS extents
de taille INITIAL. Ensuite, lorsque le segment se remplit, quand le(s) premier(s) extent(s) est (sont)
plein(s), il alloue un extent de taille NEXT. Ensuite il augmente la taille des extents d'un pourcentage
fixé par PCTINCREASE. La limite est définie par MAXEXTENTS.

SQL> create table credit (n number,...)

storage ( initial 10K next 10K pctincrease 50 maxextents 100) ;
voici ce que donne le segment après création, puis 2 allocations supplémentaires :

Voir dba_extents dans le dictionnaire.

Alloication des Tablespaces gérés localement

Il y a deux types d'allocation pour ces tablespaces :

 "SYSTEM" : le DBA précise la taille de l'extent INITIAL puis Oracle détermine au mieux la
taille des extents suivants (minimum 64K)
 "UNIFORM" : tous les extents auront la même taille, précisée par le DBA, ou la taille par
défaut : 1MO

La gestion de l'espace libre

Lorsqu'un tablespace est créé (et le fichier minimum associé) Il est pratiquement vide hormis l'entete
du fichier. L'espace libre (FREE SPACE) diminue au fur et a mesure de la creation ou de
l'augmentation des segments dans ce tablespace et se fragmente lors de la libération de blocs
(DELETE, TRUNCATE, etc).
Une "carte des trous" est donnée dans DBA_FREE_SPACE. Cette table possède une ligne par trou et
la colonne BYTES donne la taille de chaque trou en octets.
Pour avoir l'espace libre total d'un tablespace il faudra donc sommer tous les espaces libres de tous
les fichier du tablespace.

SELECT SUM(BYTES)/1024 "Taille en KO" FROM DBA_FREE_SPACE

WHERE TABLESPACE_NAME= 'TBS_TOTO

Pour récupérer l'espace libre d'un segment, on peut utiliser

TRUNCATE table_toto DROP STORAGE
ou
ALTER TABLE table_toto DEALLOCATE UNUSED

L'espace libre est défragmenté de temps en temps par Oracle. En clair les espaces libres contigus
sont fusionnés (COALESCED).

voir DBA_FREE_SPACE_COALESCED dans le dictionnaire.