Concepts Oracle

Oracle 8 à 10
Concepts et
structures de base
Rosaire Amore
Table des matières
I Les concepts
Architecture système.....................................................................4
Une instance Oracle.............................................................................................4
Structure des process...........................................................................................4
Variantes dans les configurations...........................................................................8
Structures de la base....................................................................10
Segments, Extents et Blocs.................................................................................10
Data blocks.......................................................................................................11
Extents.............................................................................................................14
Segments.........................................................................................................16
Tablespaces et Data files.....................................................................................22
Les objets d'un schéma.......................................................................................26
Intégrité des données.........................................................................................29
Dictionnaire de données......................................................................................31
Accès concurrents, verrous..........................................................35

Généralités.......................................................................................................35
Mécanismes de verrouillage.................................................................................36
Les commandes gérant les verrous.......................................................................39
Verrouillage explicite des données........................................................................39
Obtenir des verrouillages de tables explicites.........................................................40
Acquisition explicite de verrouillage par ligne........................................................41
La commande CREATE TABLE.......................................................45

STORAGE Clause...........................................................................48
CONSTRAINT clause.....................................................................52
Definir des contraintes d'intégrité.........................................................................55
Les contraintes PRIMARY KEY .............................................................................56
Contraintes d'intégrité référentielles.....................................................................58
La commande CREATE SEQUENCE................................................63
Préambule
Oracle - Concepts P .2 R. Amore

Ce support de cours est en fait directement tiré de la documentation constructeur. Il est
constitué des chapitres qui m'ont semblé sinon les plus importants, dumoins les plus
utiles par rapport au cours.
Les aspects non abordés dans ce support, le seront en s'appuyant sur des tirés à part
complémentaires, fournis au moment où le sujet sera abordé (par exemple, les stratégies
et procédures de sauvegarde, mise en œuvre de la gestion des divers types de segments,
optimisation de la base et de SQL, création d'une base, …).
La documentation Oracle utilisée ici a été le "Concepts". Il ne s'agit pour l'essentiel que
d'une simple traduction.

Architecture système
Une instance Oracle
Indépendamment du type d'ordinateur exécutant Oracle et des options particulières de
configuration de la mémoire, chaque base Oracle en fonctionnement est associée à
une instance Oracle. Chaque fois qu'une base est démarrée sur un serveur, une zone
mémoire appelée la System Global Area (SGA) est réservée et un ou plusieurs
processus sont lançés. La combinaison de la SGA et des process Oracle est appelée
une instance. La figure ci-dessous montre ce qu'est une instance Oracle.
Au démarrage d'une instance, la base de données est montée par l'instance. De

multiples instances peuvent s'exécuter concurremment sur les mêmes machines,
chacune d'elles accédant à sa propre base de données physique. Sur des systèmes
ayant des couplages peu importants, l'Oracle Parallel Server est utilisé quand une base
de données isolée est montée par plusieurs instances ; les instances partagent la
même base de données physique. D'autres configurations peuvent permettrent à une
seule instance de monter plusieurs databases.
Structure des process

Un process est "un canal de contrôle" ou un mécanisme dans un OS qui peut exécuter
une série de traitements. Quelques OS utilisent le terme job ou task. Un process a
normalement sa propre zone de mémoire privée dans laquelle il s'exécute.
La structure des process d'un système tel qu'Oracle est importante parce qu'elle définit
comment plusieurs activités peuvent se produire et comment elles sont accomplies.
L'architecture des process d'Oracle est conçue pour maximiser les performances.
Instance en Single Process (mono process)

C'est le type d'instance que l'on peut trouver sur des systèmes mono tâche (tel que
MS DOS).
Instance en Multi Process

Cette structure utilise plusieurs process pour exécuter différentes parties d'Oracle et
un process séparé pour chaque utilisateur connecté. De nombreux systèmes de base
de données sont multi-utilisateurs car l'un des premiers avantages d'une database est
de gérer les données dont ont besoin de multiples utilisateurs en même temps.
La figure ci-dessous illustre une instance Oracle en multi process.

Dans un système multi process on peut scinder en deux catégories les types de
process : les process utilisateurs et les process Oracle.
Process utilisateurs
Ce sont les process qui s'exécutent lorque un utilisateur se connecte au moyen d'outils
ou d'applications tels que SQL*DBA, SQL*PLUS, …
Dans ce cas un process est créé pour chaque application.
Les process Oracle

Dans les systèmes multi process, Oracle est contrôlé par deux types de process : les
server process et background process.
Les server process sont créés pour traiter les requêtes des user process connectés à
l'instance. Souvent lorsque l'application et Oracle s'exécutent sur la même machine
plutôt qu'au travers d'un réseau, le user process et son server process correspondant
sont combinés en un process unique pour réduire la surcharge du système. Toutefois
quand l'application et Oracle opèrent sur des machines différentes un user process
communique avec Oracle via un server process séparé.
Les server process créés pour chaque application utilisateur peuvent accomplir une ou
plusieurs des tâches suivantes :
Vérifier et exécuter les commandes SQL lancées depuis l'application
Lire les blocs nécessaires sur le disque et les placer dans les buffers database
partagés de la SGA, s'ils ne sont pas déjà présents dans celle-ci
Retourner des résultats de telle façon que l'application puisse traîter l'information
Pour optimiser les performances et servir de nombreux utilisateurs, Oracle utilise
quelques process additionnels appelés les background process. Sur de nombreux OS,
les background process sont créés automatiquement quand l'instance est démarrée.
Une instance Oracle peut avoir un grand nombre de process. La figure ci-dessous
permet de se faire une idée de l'architecture globale de ces process et de leur
interraction avec les différents composants d'Oracle.

Pour une description complète de ces process, il est conseillé de consulter la
documentation d'Oracle (Concepts Manual). Néanmoins, voici une description succinte
des principaux parmi les process mis en œuvre dans ce type d'architecture.
DBWR
Ecrit les blocs modifiés du buffer base de donnée dans la base. Cette écriture a lieu
aussi quand Oracle a besoin d'un buffer.
Il n'y a pas forcément écriture dans la base de donnée lors d'un commit. Cette
écriture, garantissant l'intégrité des données, se fait dans le redo log file en ligne.
LGWR
Ce process écrit les entrées redo log sur disque. Si un buffer doit être libéré, il peut y
avoir écriture sur disque dans le redo en ligne, sans que certaines transactions ne
soient committées, mais celles ci ne deviennent permanentes que lors de leur commit.
SMON
Son rôle est de procéder à la restauration "instance". Il est utilisé au startup pour
effectuer les restaurations automatiques au démarrage d'une instance, suite à un
incident CPU. SMON est également responsable du nettoyage des segments
temporaires inutilisés. Il finalise aussi les transactions avortées ou non finalisées à
cause d'un crash ou du non montage d'un tablespace. Ces transactions sont terminées
par SMON dès que le montage du tablespace ou du fichier est réalisé.
PMON
Procède aux "process recovery" quand un process utilisateur échoue (p.ex. un process
SQL*Plus client est perdu). PMON est responsable du nettoyage des caches et de la
libération des ressources utilisées par ce process échoué. Par exemple, il réinitialise le
statut de la table des transactions actives, débloque les verrous, supprime le PID de la
liste des process Oracle actifs.
PMON et SMON se comportent comme des daemons Unix.
ARCH
Le process d'archivage, écrit les redo log files online vers la bande, lorsqu'ils sont
pleins et qu'un switch log survient. ARCH n'est actif que lorsque Oracle est utilisé en
mode ARCHIVELOG.

Variantes dans les configurations
La figure ci-dessous illustre une configuration d'Oracle assez courante et qui
correspond assez bien à ce qui se passe lorsqu'il est mis en œuvre en client-serveur.
Par exemple le serveur fonctionnant sur un OS du type Unix, correspondra à cette
structure mémoire. Le client se trouve être sur une machine distante, reliée par
réseau.
Configuration en Dedicated Server Processes
Un autre type de configuration intéressante est celle où Oracle fonctionne en Multi-

Threaded Server Configuration et Shared Server Processes. Dans cette configuration,
les process suivants sont nécessaires:
Un "Network listener" qui connecte les process utilisateurs à un dispatcher et aux
dedicated server (Ce process fait partie de SQL*Net)
Un ou plusieurs dispatcher
Un ou plusieurs shared server processes
Le Network Listener attends les demandes de connection et détermine si chaque
process utilisateur peut ou non utiliser le shared server process. Si c'est le cas, le
listener donne au process utilisateur, l'adresse d'un dispatcher. Si le process utilisateur
nécessite un dedicated server, le listener crée un dedicated server process et connect
le process utilisateur (Il doit y avoir au moins un dispatcher qui doit être configuré et
démarré par protocole réseau que la database cliente utilisera).
En résumé, une telle architecture est intéressante dans la mesure où elle permet de
faire des économies substantielles sur le taux d'occupation de la mémoire lorsque
Oracle est utilisé par un nombre important de clients.
La configuration de la mémoire ressemble alors à ceci :

Structures de la base
Segments, Extents et Blocs
Oracle gère l'allocation d'espace pour toutes les données dans la database. Les unités
logiques d'allocation dans la database sont les blocs de données (data blocks), extents
et segments. La figure suivante illustre la relation entre ces structures de données.
Data blocks
Au niveau de granularité le plus fin, les données d'une base de données Oracle sont
stockées dans des data blocks (appelées aussi blocs logiques, Oracle blocks ou pages).
Un bloc correspond à un nombre spécifique d'octets. La taille d'un bloc est spécifié
pour chaque bloc de données lors de la création de la base. Cette taille est un multiple
de la taille d'un bloc de l'OS. Il est important de se souvenir qu'une base de données à
son plus fin de granularité, utilise et alloue de l'espace libre dans des blocs de données
(par opposition, toutes les données au niveau du système d'exploitation sont stockées
en octets).
Extents
Le niveau logique supérieur d'allocation d'espace dans une database est appelé un
extents. Un extent est un nombre spécifique de data blocks contigus qui est alloué
pour stocker un type spécifique d'informations.

Segments
Le niveau logique au dessus de l'extent est appelé un segment. Un segment est un
ensemble d'extents qui a été alloué pour un type spécifique de structures de données
et qui sont toutes stockées dans le même tablespace. Par exemple, toutes les données
d'une table sont stockées dans leur propre segment de données alors que toutes les
données d'un index sont stockées dans un segment d'index. Oracle alloue de l'espace
pour les segments dans les extents. Par conséquent, quand un extent d'un segment
est plein Oracle alloue un autre extent pour ce segment. Puisque les extents sont
alloués selon les besoins, les extents d'un segment peuvent être ou non contigus sur le
disque, et peuvent ou non être placés sur plusieurs fichiers (datafiles). Un extent ne
peut pas être à cheval sur plusieurs fichiers.
Data blocks
Format
Le format d'un bloc Oracle est le même que le bloc contienne des données de tables,
d'index ou de clusters. La figure ci-dessous illustre le format d'un bloc.
En-tête (header)
Contient des informations générales telles l'adresse du bloc, type de segment. Sa taille
varie de 84 à 107 octets
Table directory
Contient des informations sur la table dont les données se trouvent dans ce bloc.

Row directory
Contient des informations sur les lignes effectivement stockées dans ce bloc (y
compris l'adresse des lignes dans la zone row data).
Row data
Contient les données de la table ou de l'index.
Espace libre
Est utilisé pour l'INSERTion de lignes ou pour les UPDATE qui requièrent de l'espace
supplémentaire. Bien que l'INSERTion de données dans un bloc soit fonction des
paramètres PCTFREE et PCTUSED.
Une introduction à PCTFREE et PCTUSED

Ces paramètres influencent le contrôle de l'usage de l'espace libre pour les INSERT et
les UPDATE des lignes dans le bloc de données. Ces deux paramètres peuvent être
spécifiés à la création et à la modification de la structure de la table ou cluster. Le
paramètre PCTFREE peut être spécifié également pour les segments d'index.
Le paramètre PCTFREE
Permet de spécifier le poucentage du bloc devant rester libre pour les éventuels
UPDATE de lignes se trouvant déjà stockées dans ce bloc. Par exemple, en supposant
que l'on a spécifié la valeur suivante pour ce paramètre à la création de la table :
PCTFREE 20
Cette clause spécifie que 20% de chaque bloc de données pour cette table sera gardé
libre pour de possibles mises à jour des lignes déjà stockées dans chaque bloc.
Il est à noter qu'avant que le PCTFREE ne soit atteint, l'espace est rempli par les
INSERTions et la croissance du header.

Le paramètre PCTUSED
Après que le bloc de données a été rempli, conformément au paramètre PCTFREE, le
bloc n'est plus considéré comme étant disponible pour de nouvelles INSERTions tant
que le pourcentage du bloc utilisé ne retombe au dessous de la valeur de PCTUSED.
Avant que cette valeur ne soit atteinte, le bloc n'est plus utilisable que pour
d'éventuels UPDATE. Par exemple, en supposant que l'on a spécifié la valeur suivante
pour ce paramètre à la création de la table : PCTUSED 40, Dans ce cas, un bloc de
données utilisé pour les données d'une table de ce segment n'est pas considéré
comme étant libre à l'INSERTion d'aucune ligne tant que l'espace utilisé dans le bloc
ne descend pas à 39% ou moins (en supposant que l'espace utilisé dans le bloc ait
auparavent atteint le PCTFREE). La figure ci-dessous illustre ce fait.
Interraction entre PCTFREE et PCTUSED

PCTFREE et PCTUSED sont utilisés de pair pour l'optimisation de l'espace occupé dans
les blocs d'un extent d'un segment donné. La figure ci-dessous illustre comment
PCTFREE et PCTUSED fonctionnent ensemble pour le contrôle de l'espace libre utilisé
dans un data block.
Comment Oracle utilise PCTFREE et PCTUSED

Dans un bloc nouvellement alloué, l'espace disponible pour les INSERTions est égal à
la taille du bloc moins la somme des tailles de l'en-tête et de PCTFREE. Les UPDATEs
de données existantes peuvent utiliser tout espace disponible dans le bloc. Par
conséquent, les UPDATE peuvent réduire l'espace disponible d'un bloc à une valeur
inférieure à PCTFREE, espace réservé aux UPDATE mais interdit aux INSERTions.
Pour chaque segment data et index, Oracle gère une ou plusieurs freelists. Une free
list est une liste de blocs ayant été alloués pour cet extent de ce segment qui ont un
espace libre supérieur à PCTFREE. Ces blocs peuvent être utilisés pour les INSERTions.
Lorsque Oracle doit réaliser une INSERTion, il vérifie dans le premier bloc disponible
que l'espace requis pour l'INSERTion est assez grand, sinon s'il est à un taux
d'occupation au moins égal à PCTUSED, le bloc est retiré de la free list.

Après un UPDATE ou un DELETE, Oracle vérifie que l'espace réellement utilisé dans le
bloc est ou non, inférieur à PCTUSED. Si c'est le cas, le bloc est réintégré dans la free
list et il devient le premier bloc disponible pour une INSERTion.
Disponibilité et Compression de l'espace libre

Deux types de commandes libèrent de la place dans les blocs: DELETE et UPDATE.
L'espace ainsi libéré devient disponible pour de nouvelles INSERTions aux conditions
suivantes :
Si la commande INSERT se trouve dans la même transaction et se trouve être
subsequent à la commande ayant libéré de la place dans le bloc.
Si la commande INSERT et la commande ayant libéré de la place se trouvent dans
des transactions différentes, la commande INSERT pourra utiliser l'espace libéré
seulement après que la seconde transaction aura été COMMITée et seulement si
l'espace libéré doit être utilisé.
L'espace libéré peut être ou non contigu avec la zone libre principale du bloc. L'espace
libre d'un bloc est recompacté uniquement quand un INSERT ou un UPDATE tente
d'utiliser un bloc qui contient assez d'espace libre mais que cet espace est trop
fragmenté pour permettre que les nouvelles données ne soient insérées de façon
continue. Cette compression est réalisée uniquement dans ces conditions parce
qu'alors, les performances de la base de données ne sont pas altérées par des
recompactages continus et inutiles réalisés à chaque UPDATE ou DELETE.

Extents
Un extent est une unité logique de stockage composée d'un certain nombre de blocs
contigus. Chaque type de segment est composé d'un ou plusieurs extent. Lorsque
l'espace existant dans un segment est complètement utilisé, Oracle alloue un nouvel
extent pour ce segment.
Quand se fait cette allocation?

Quel que soit son type, chaque segment d'une base de données est créé avec au
moins un extent destiné à contenir ses données. Cet extent est nommé le initial
extent.
Une exception à ceci: les Rollback Segment sont toujours créé avec au moins
! deux extents.
Par exemple, lorsqu'une table est créée, son segment de données contient un initial
extent composé d'un nombre de blocs de données pré-spécifié. Bien qu'il n'y ait eu
aucune INSERTion dans cette table, cet espace lui est d'ores et déjà réservé.
Lorsque les blocs d'un initial extent sont pleins, alors Oracle alloue automatiquement
un nouvel extent pour ce segment
A des fins de maintenance, chaque segment contient un bloc d'en-tête de segment qui
décrit les caractéristiques de ce segment ainsi qu'une liste (directory) des extent de ce
segment.
Comment sont alloués les extents

Pour les détails de cette opération se reporter à Administrator's Guide ou au Concept
Manual.
Désallocation
En général, les extents ne sont libérés que lorsque des commandes telles que DROP
TABLE sont exécutées. Mais il existe des exceptions où Oracle désalloue
automatiquement un extent, en particulier dans le cas des Rollback Segment.
Taille et limites d'un extent

Déterminée par les paramètres de la clause STORAGE, par exemple, de la commande
CREATE TABLE, dont voici la syntaxe complète (description complète de ces paramètres
en annexe).

Segments
Un segment est un ensemble d'extents qui contient toutes les données d'un type
spécifique d'une structure logique de stockage dans un tablespace.
Une base de données Oracle peut contenir quatre différents types de segments :
Data segments
Index segments
Rollback segments
Temporary segments
Data segments
Chaque table non clustérisée dans une base de données Oracle a un seul data
segment qui contient toutes ses données. Ce data segment pour la table est
indirectement créé via la commande CREATE TABLE.
Chaque cluster dans une base de données Oracle a aussi un seul data segment
contenant ses données.
Les paramètres de stockage contrôlent la façon dont les extents sont alloués.
Index segments
Chaque index dans une base de données Oracle a un segment d'index pour contenir
ses données. Le segment d'index pour l'index est indirectement créé via la commande
CREATE INDEX.
Rollback Segment
Chaque base de données contient un ou plusieurs Rollback Segment, un Rollback
Segment est une portion de la data base qui enregistre les actions d'une transaction
susceptible de subir un ROLLBACK dans certaines circonstances. Les Rollback Segment
sont utilisés pour fournir la cohérence en lecture, pour annuler des transactions
(ROLLBACK) et pour restaurer la data base.
Il est à noter qu'à partir de la version 9, sont apparus les undo tablespaces qui
gèrent le rollbacking de façon différente (voir le tiré à part sur ce point).

Contenu d'un Rollback Segment
Les informations dans un Rollback Segment sont constituées par des suites de rollback
entries (entrées). Entre autre information une entrée rollback inclut des informations
sur les blocs (nom de fichier, numéro de bloc correspondant aux données qui ont été
modifiées) et les données telles qu'elles existaient avant une opération dans la
transaction. Les entrées rollback pour la même transaction sont reliées ensemble de
sorte que les entrées peuvent être retrouvées facilement si nécessaire pour annuler la
transaction.
Les Rollback Segment sont modifiés exclusivement par Oracle.
Etant donné que les entrées rollback changent des blocs de données, elles sont aussi
enregistrées dans le redo log. Ce second enregistrement des informations de rollback
est très important pour la transaction active non encore committée au moment où se
produit un crash système. Si un crash système se produit l'information du Rollback
Segment, y compris les entrées rollback pour la transaction active est
automatiquement restaurée lors des restaurations d'instance ou de média. Le rollback
des transactions qui n'ont pas été committées ou rollbackées au moment de l'incident
pourra être réalisé après la fin de la restauration.

Informations requises pour un Rollback Segment
Oracle entretient une table des transactions pour chaque Rollback Segment contenu
dans la base. Chaque table est une liste de toutes les transactions qui utilisent le
Rollback Segment associé et l'entrée rollback pour chaque changement effectué par
ces transactions. Les entrées rollback dans un Rollback Segment sont utilisées pour
effectuer le ROLLBACK de transactions et pour obtenir des résultats cohérents en
lecture pour les requêtes. Les Rollback Segment enregistrent les données avant
changement, en prenant comme unité de base la transaction. Pour chaque transaction,
chaque nouveau changement est relié au précédent. Si l'on doit annuler la transaction,
les changements de la chaine sont appliqués aux blocs de données dans un ordre qui
restaure les données dans leur état précédent. De même lorsque Oracle doit fournir un
ensemble de résultats cohérent en lecture pour une requête, il peut utiliser
l'information se trouvant dans le Rollback Segment pour générer un ensemble
consistant de données, considéré à un instant donné.
Tous les types de rollbacks utilisent les mêmes procédures :
Rollback au niveau d'une commande (suite à une erreur d'exécution, à un deadlock)
Rollback to savepoint
Rollback d'une transaction à la demande de l'utilisateur
Rollback d'une transaction due à une fin anormale d'un processus
Rollback des transactions incomplètes durant la restauration
Transactions et Rollback Segment

Chaque fois qu'une transaction commence elle est automatiquement affectée à un
Rollback Segment.
Une transaction peut être automatiquement attribuée au premier Rollback Segment
disponible par Oracle.
Une transaction peut être explicitement affectée à un Rollback Segment spécifique
par l'application. Au début d'une transaction, un utilisateur ou un développeur
peut spécifier un Rollback Segment particulier qu'Oracle doit utiliser en
exécutant la transaction.
Pendant la durée d'une transaction, le process utilisateur associé écrit les entrées
rollback uniquement dans le Rollback Segment concerné. Quand une transaction se
termine par COMMIT, les informations de rollback libérées mais non détruites
immédiatement. Les informations demeurent dans le Rollback Segment pour créer des
vues cohérentes en lecture de données pertinentes pour les requêtes qui ont été
lancées avant que la transaction ne soit COMMITée. Pour garantir que les données de
rollback sont disponibles aussi longtemp que possible pour de telles vues, l'écriture
dans les extents des Rollback Segment est séquentielle. Quand le dernier extent d'un
Rollback Segment est plein, Oracle continue à écrire des données de rollback en
repartant du premier extent du segment (de façon circulaire). Une transaction très
longue peut requérir l'allocation d'un nouvel extent.
Chaque Rollback Segment peut manipuler un certain nombre de transactions d'une
instance.

Allocation d'extents et Rollback Segment
Quand un Rollback Segment est créé, des paramètres de stockage peuvent être
spécifiés pour contrôler l'allocation d'extent pour ce segment. Un minimum de deux
extents sont alloués pour chaque Rollback Segment.
Une transaction écrit séquentiellement dans un seul Rollback Segment. Chaque
transaction écrit à un seul extent du Rollback Segment quelque soit le moment. En
outre, plusieurs transactions actives peuvent écrire concurrement dans un seul
Rollback Segment, voire le même extent d'un Rollback Segment ; cependant, chaque
bloc d'un extent peut contenir seulement les informations d'une seule transaction.
Lorsqu'une transaction n'a plus de place dans l'extent courant et nécessite de
continuer ses écritures, Oracle doit trouver un extent disponible du même Rollback
Segment. Oracle a deux alternatives :
Il peut réutiliser un extent déjà alloué au Rollback Segment.
Il peut faire l'acquisition d'un nouvel extent pour le Rollback Segment.
La première transaction qui nécessite d'acquérir de l'espace vérifie le prochain extent
du Rollback Segment. Si le prochain extent du Rollback Segment ne contient pas
d'informations à "défaire" (par ROLLBACK) actives, Oracle en fait l'extent courant, et
toutes les transactions qui ont besoin de plus d'espace peuvent dès lors écrire leurs
entrées rollback dans le nouvel extent. La figure ci-dessous illustre deux transactions,
T1 et T2, qui continuent à écrire du troisième extent jusqu'au quatrième d'un Rollback
Segment.
Pendant que la transaction continue à écrire et à remplir l'extent courant, la
disponibilité du prochain extent alloué au Rollback Segment est vérifiée. Dans cette
figure E1 est cet extent. Cette figure montre la nature cyclique de l'utilisation des
extents dans les Rollback Segment.

Pour continuer à écrire les informations de rollback pour une transaction, Oracle essaie
toujours de réutiliser le prochain extent dans l'anneau en premier. Cependant, si le
prochain extent contient des données actives, alors Oracle doit allouer un nouvel
extent .
La figure qui suit illustre quand un nouvel extent doit être alloué. Les transactions
actives (pas de COMMIT ni de ROLLBACK) trainent en longueur. Les quatre extents
sont actifs. Toutefois, lorsque E4 est complètement plein, les transactions ne peuvent
pas continuer leurs opérations d'écriture dans le prochain extent déjà alloué pour le
Rollback Segment, E1, puisqu'il contient des entrées rollback actives. Par conséquent,
Oracle réserve un nouvel extent (E5), et les transactions peuvent continuer à écrire
dans ce nouvel extent.
Désallocation d'extents d'un Rollback Segment

Quand un Rollback Segment est créé ou modifié le paramètre de stockage OPTIMAL,
qui s'applique uniquement aux Rollback Segments, peut être utilisé pour spécifier la
taille optimale d'un Rollback Segment, en octets. Si une transaction doit continuer à
écrire des informations de rollback d'un extent à un autre dans lee Rollback Segment,
Oracle compare la taille actuelle du Rollback Segment à la taille optimale du segment.
Si le Rollback Segment à une taille supérieure à sa taille optimale et que les extents
qui suivent immédiatement l'extent qui vient d'être plein sont inactifs, Oracle
désalloue les extents consécutifs non actifs du Rollback Segment jusqu'à ce que la
taille du Rollback Segment se rapproche mais reste supérieure à la taille optimale du
Rollback Segment. Oracle libère toujours les plus anciens extents inactifs.
Le Rollback Segment SYSTEM

Un Rollback Segment nommé SYSTEM est créé quand une base de données est créée.
Ce segment initial est créé dans le tablespace SYSTEM, utilisant les paramètres de
stockage par défaut associé à ce tablespace. Le Rollback Segment SYSTEM ne peut
jamais faire l'objet d'une commande DROP. Une instance nécessite toujours la
présence de ce Rollback Segment en plus de tout autre Rollback Segment éventuel.
S'il y a plusieurs Rollback Segments, Oracle essaie d'utiliser le Rollback Segment
SYSTEM seulement pour les transactions spéciales du système et distribue les
transactions des utilisateurs entre les autres Rollback Segments. S'il y a trop de
transactions pour les Rollback Segments non-SYSTEM, Oracle utilise le segment
SYSTEM autant que nécessaire. En général, après la création de la database, au moins
un Rollback Segment additionnel devrait être créé dans le tablespace SYSTEM.
Etats d'un Rollback Segment

Un Rollback Segment est toujours dans l'un parmi plusieurs états possibles. L'état d'un
Rollback Segment va déterminer s'il pourra être utilisé par les transactions, de même
que s'il peut être utilisé par le DBA pour procéder à toute tâche d'administration sur le
segment.
Les différents états d'un Rollback Segment sont les suivants :
OFFLINE Il n'est utilisé par aucune instance.
ONLINE Il est utilisé par une instance. Il est susceptible de
contenir des donnéesde transactions actives.
NEEDS RECOVERY (réparation/restauration nécessaire). Contient des
données d'une transaction non COMMITée, à laquelle on
ne peut appliquer de ROLLBACK (Les datafiles impliquées
sont inaccessibles), ou est corrompu.
PARTLY AVAILABLE Contient des données d'une transaction in-doubt
(transactions distribuées non résolues).
INVALID a été supprimé (l'espace déjà alloué à ce Rollback
Segment sera utilisé plus tard à la création d'un nouveau
Rollback Segment).
La figure ci-dessous montre de quelle façon un Rollback Segment passe d'un état à un
autre.

Segments temporaires
Pour traiter des requêtes, Oracle utilise souvent des espaces de travail temporaires
pour les étapes intermédiaires du traitement des commandes SQL. Cet espace disque
appelé un segment temporaire est automatiquement réservé par Oracle. Typiquement
un segment temporaire est requis comme aire de travail pour les opérations de tris. Un
segment n'est pas créé si l'opération de tri peut être réalisé en mémoire, ou si Oracle
trouve une autre façon de réaliser l'opération en utilisant des index.
Opérations utilisant les segments temporaires

Les commandes SQL comportant les commandes suivantes peuvent demander l'usage
de segments temporaires :
CREATE INDEX
SELECT … ORDER BY
SELECT DISTINCT …
SELECT … GROUP BY
SELECT … UNION
SELECT … INTERSECT
SELECT … MINUS
Jointures non indexées
Certaines sous-requêtes corrélées

Allocation
Les segments temporaires sont alloués au fur et à mesure des besoins durant une
session utilisateur. Par exemple, un utilisateur peut exécuter une requête qui requiert
trois segments temporaires. Les segments temporaires sont supprimés quand la
commande se termine. Les caractéristiques de stockage pour les extents des segments
temporaires sont déterminés par les valeurs par défaut des tablespaces dans lesquels
ils sont créés.
Dans la mesure où l'allocation et la désallocation de segments temporaires survient
fréquemment, il est raisonnable de créer un tablespace spécial pour les segments
temporaires. En opérant de la sorte on peut distribuer les entrées/sorties sur des
périphériques disques et éviter la fragmentation des tablespaces SYSTEM et les autres
qui autrement contiendraient des segments temporaires.
Les segments temporaires sont créés dans le tablespace temporaire de l'utilisateur tel
que spécifié pour l'utilisateur via les commandes CREATE USER ou ALTER USER avec
l'option TEMPORARY TABLESPACE. Le tablespace SYSTEM est le tablespace temporaire
par défaut si l'on a pas spécifié explicitement le tablespace temporaire pour un
utilisateur.

Tablespaces et Data files
Introduction
Les données utilisables d'une base de données Oracle sont stockées logiquement dans
les tablespaces et physiquement dans les data files associés au tablespace
correspondant. La figure ci-dessous illustre cet relation.
Bien que les databases, tablespaces, datafiles, et segments sont intimement liés, ils
comportent d'importantes différences :
Databases et Une database Oracle est constituée de une ou plusieurs unités
tablespaces logiques de stockage appelées tablespace. Les données de la
database est globalement stockées dans les tablespaces de la
database.
Tablespaces et Chaque tablespace dans une base de données Oracle est
datafiles composée de un ou plusieurs fichiers sytème appelés datafiles. Un
datafile d'un tablespace contient physiquement les données
associées de la database sur disque.
Databases et Les données d'une database sont collectivement stockées dans les
datafiles datafiles qui constituent chaque tablespace de la database. Par
exemple, la database Oracle la plus simple aurait un tablespace
avec un datafiles, une database plus complexe pourrait avoir trois
tablespaces, chacune étant composée de deux datafiles (pour un
total de six datafiles).
Schema objects, Quand un objet d'un schéma tel qu'une table ou un index est
segments et créé, son segment est créé dans un tablespace donné de la
tablespaces database. Par exemple, supposons qu'une table soit créée dans
un tablespace spécifique en utilisant la commande CREATE TABLE
avec l'option TABLESPACE. L'espace pour le segment de données
de cette table est alloué dans un ou plusieurs des datafiles qui
constituent le tablespace spécifié. Un segment d'un objet réserve
de la place dans seulement un tablespace d'une database.

Tablespaces
Une database est divisée en une ou plusieurs unités logiques de stockage appelées
tablespaces. Un administrateur de base de données peut utiliser les tablespaces pour :
Contrôler l'allocation d'espace disque pour les données de la database.
Assigner des quotas spécifiques pour les utilisateurs de la database.
Contrôler la disponibilité des données en plaçant des tablespaces online ou offline.
Réaliser des opérations de backup ou de restauration partielle de la base de
données.
Distribuer le stockage des données sur plusieurs périphériques disque pour
améliorer les performances.
Un administrateur de bases de données peut créer de nouveaux tablespaces, ajouter
ou supprimer des datafiles de ces tablespaces, fixer et modifier des réglages de
stockage par défaut pour les segments créés dans un tablespace, et supprimer des
tablespaces.
Le tablespace SYSTEM
Chaque base de données Oracle contient un tablespace nommé SYSTEM qui est
automatiquement créé lors de la création de la base de données. Le tablespace
SYSTEM contient toujours les tables du dictionnaire de données pour la base de
données entière.
Une petite base de données pourrait ne nécessiter que le tablespace SYSTEM.
Cependant il est recommandé qu'au moins un tablespace supplémentaire soit créé
pour stocker les données utilisateur séparément des informations du dictionnaire de
données, ce qui vous donne plus de flexibilité dans de nombreuses opérations
d'administration de la database, et qui peut réduire les "embouteillages" entre les
objets du dictionnaire et les objets des schémas dans le même datafile.
Le tablespace SYSTEM doit toujours être maintenu online (il ne peut pas être mis
offline).
Toutes les données stockées pour les unités de programmes PL/SQL stockées
(procédures, fonctions, packages et triggers) le sont dans le tablespace SYSTEM. Si le
nombre de ces objets PL/SQL est important l'administrateur de la base de données
doit tenir compte avec attention de l'espace qu'ils occupent.
Agrandissement d'une database

Pour agrandir une base de
données des datafiles
supplémentaires peuvent
être ajoutés à l'un des
tablespaces existants,
augmentant par là l'espace
disque disponible pour ce
tablespace. Cette façon
d'accroitre l'espace est
illustrée dans la figure ci-
contre.

Autrement, un DBA peut créer un nouveau tablespace (définit par un datafiles
additionnel) pour augmenter la taille de la base de données. Ce qui est illustré par la
figure ci-dessous.
La taille d'un tablespace est la taille du datafile ou la taille cumulée des multiples
datafiles qui constituent le tablespace, et la taille de la base de données est la taille
collective des tablespaces qui constituent la base de données.
A noter que dans les versions récentes d'Oracle il est possible de gérer la
!
croissance d'une base de données de façon plus automatisée en particulier par

l'utilisation d'options nouvelles à incorporer dans les commandes de création ou de
modification de la database (en particulier l'option AUTOEXTEND).

Tablespaces Online et Offline
L'administrateur d'une base de données a la possibilité de placer online ou offline tout
tablespace même lorsque la base de données est ouverte. La seule exception est le
tablespace SYSTEM qui doit toujours rester online puisque le dictionnaire de
données doit toujours être accessible.
Un tablespace est normalement online de telle sorte que les données qu'il contient
sont disponibles pour les utilisateurs de la base. Toutefois l'administrateur de la base
peut souhaiter mettre offline un tablespace pour l'une parmi les raisons suivantes :
Pour rendre indisponible une portion de la base tout en gardant accessible le reste
de celle-ci.
Pour effectuer des backups offline de tablespaces (bien qu'un tablespace puisse
subir un backup alors qu'il est online et utilisé).
Pour rendre une application et son groupe de table temporairement indisponible
pendant sa mise à jour ou sa maintenance.
Quand un tablespace est offline, Oracle ne permet à aucune commande SQL de faire
référence aux objets qu'il contient. Les transactions actives composées de commandes
faisant référence à des données appartenant à un tablespace qui a été placé offline, ne
sont pas affectées au niveau de la transaction. Néanmoins, les entrées de rollback
correspondant à ces commandes sont sauvegardées dans un Rollback Segment différé
(dans le tablespace SYSTEM) et appliquées au tablespace, si nécessaire, lorsque le
tablespace est ramené online.
Un tablespace ne peut pas être mis offline s'il contient un Rollback Segment actif.
Si un tablespace est offline lorsque la database est arrêtée, au redémarrage il sera
toujours dans ce même état. Un tablespace peut être mis online uniquement par la
database qui l'a mis offline (à cause des informations enregistrées dans le dictionnaire
de données). Ainsi un tablespace ne peut pas être transféré d'une database à une
autre.
Datafiles
Un tablespace dans une base de données Oracle est composé d'un ou plusieurs
datafiles. Un datafile peut être associé à un tablespace et un seul et seulement une
database.
Contenu d'un datafile

Juste après la création d'un datafile, l'espace disque alloué ne contient aucune donnée.
Cependant, l'espace est réservé en vue de contenir seulement les données pour les
futurs segments du tablespace associé (il ne peut y avoir de stockage de quelque autre
donnée que ce soit). Dès qu'un segment est créé et croit dans le tablespace, Oracle
utilise l'espace libre du datafile associé pour réserver de l'espace aux extents des
segments.
Les données dans les segments objets (données, index, Rollback Segments, …) sont
physiquement stockées dans un ou plusieurs des datafiles qui constituent le
tablespace. Les extents d'un segment donné peuvent être alloués dans un ou plusieurs
datafiles d'un tablespace, ainsi donc un objet peut être stocké "à cheval" sur un ou
plusieurs datafiles. L'administrateur et l'utilisateur final ne peuvent pas contrôler dans
quel datafile sera stocké un objet.
Datafiles Offline
Les tablespaces peuvent être mis offline ou ramenés online à tout moment. De même
un datafile individuel peut aussi être mis offline. Cependant cela n'est fait que durant
certaines procédures de restauration de la base de données.

Les objets d'un schéma
Schéma
Associé avec chaque utilisateur de la base de données, il existe un schéma. Un schéma
est une collection d'objets. Des exemples d'objets constituants un schéma sont : les
tables, les vues, les séquences, les synonymes, les index, les clusters, les databases
links, les procédures et les packages. Un schéma est une structure logique de stockage
de données. Chaque schéma n'a pas de fichier physique correspondant sur disque qui
stocke ses infomations. Néanmoins, un schéma est stocké logiquement dans un
tablespace de la database. La figure suivante illustre la relation entre objets,
tablespaces et datafiles.
Il n'y a pas de relation entre schéma et tablespace : un tablespace peut contenir des
objets de différents schémas et les objets d'un schéma peuvent être contenus dans
différents tablespace.
Tables
Les tables sont l'unité basique de stockage des données dans une base de données
Oracle. Les données sont stockées en lignes et colonnes.
Voir cours SQL.
Voir annexe sur la commande CREATE TABLE et les commentaires qui suivent.
Vues
Voir cours SQL.
Séquences
Voir annexe sur la commande CREATE SEQUENCE et les commentaires qui suivent.
Index
Voir support Administration.
Clusters
Généralités
Les clusters sont une méthode optionnelle de stockage des données des tables. Un
cluster est un groupe de tables qui partagent les mêmes blocs de données parce qu'ils
partagent des colonnes communes et sont souvent utilisées ensemble.Par exemple, les
tables EMP et DEPT partagent la colonne deptno. Si elles sont clusterisées, toutes les
lignes de chaque département des deux tables sont stockées physiquement dans les
mêmes blocs de données. Il en découle deux bénéfices principaux :
Les E/S disque sont réduites, améliorant ainsi les temps d'accès
Il peut y avoir une économie au niveau de l'espace requis pour le stockage des
données
Règles guidant les choix opportuns

Les tables sont en priorité l'objet de requêtes (peu de INSERT et de UPDATE)
Les tables sont souvent utilisées en jointure ou l'objet de SELECT basés sur la colonne
clustérisée
Les critères de choix pour les colonnes sont approximativement les mêmes que pour
les index.
Si plusieurs colonnes sont utilisées dans les requêtes qui joignent les tables faites de
la Cluster Key une clé composite.
Un bon cluster a suffisamment de valeurs uniques pour que chacune d'entre elles (les
lignes qui les concernent) remplisse un bloc de données.
Trop de valeurs par clé entraînent un temp de recherche des lignes plus important.
Une mauvaise clé pourrait être une clé du type sexe (Male/femelle)
Effet produit par les clusters

Soient les lignes des tables EMP et DEPT suivantes :
....7782 CLARK MANAGER 7839.... 10 etc
....7839 KING PRESIDENT...10 etc
....7934 MILLER CLERK...10 1300 etc
....ACCOUNTING 10
Ces lignes sont stockées de façon totalement non contrôlée lorsque l’on n’utilise pas
les clusters. L’utilisation d’un cluster sur ces deux tables va provoquer un rangement
des données sur disque qui pourra ressembler à ce qui suit :
...10 7782 CLARK MANAGER 7839 09-JUN-89 2450 7839 KING PRESID
ENT 17-NOV-81 7934 MILLER CLERK 7782 etc
Il faut noter que l’utilisation d’un cluster affecte la façon dont les données sont
stockées physiquement sur disque.
Conditions d’utilisation des clusters:

Il est indiqué d’utiliser des clusters dès que l’on a affaire à des tables importantes
entre lesquelles doivent être effectuées fréquemment des jointures sur certaines
colonnes. Ce sont ces colonnes là qu’il y aura intérêt à clusteriser. Un effet annexe et
interressant des clusters est une meilleure utilisation de l’espace disque.
La mise en oeuvre d’un cluster se fait en suivant les étapes suivantes :
création du cluster :
CREATE CLUSTER NomCluster (Colonne Type, Colonne Type, ...);
création de l'index du cluster :
CREATE INDEX NomIndex ON CLUSTER NomCluster;
Création de la table clustérisée :
CREATE TABLE NomTable (Colonne Type, Colonne Type,...)
CLUSTER NomCluster (ColonneCluster, ColonneCluster, ...)
[; ou AS Requête;]
Modifications d’un cluster.

Si la table existe déjà,
Il faut la recréer sous un autre nom au moyen d’une requête, par exemple, en
spécifiant que la nouvelle table utilise le cluster. puis faire un DROP sur la table
d’origine et rebaptiser la nouvelle table
Suppression d’une table appartenant à un cluster :
on réalise l’opération inverse. A savoir, créer une table non clustérisée à partir de
la table clustérisée, faire un DROP sur la table clustérisée, renommer la nouvelle
table.
Suppression d’un cluster
D’abord, supprimer les tables contenues dans le cluster (vérifier au moyen du
dictionnaire de données). Faire le DROP sur le cluster.
Hash Clusters
Le hashing est une option de stockage de données améliorant les performances sur
l'accès aux données. Pour l'utiliser il faut créer un hash cluster et charger ensuite les
tables dans ce cluster. Les lignes d'une table dans un hash cluster sont physiquement

stockées et retrouvées selon le résultat d'une fonction de hachage. Une fonction de
hashage est utilisée pour générer une distribution de valeurs numériques, appelées
valeurs de hash (hash values), qui sont basées sur une clé particulière. Cette clé peut
être une colonne seule ou composée. Pour trouver ou stocker une ligne dans un hash
cluster, Oracle applique la fonction de hashage à la valeur de la clé de la ligne; la
valeur résultant du calcul par la fonction de hashage correspond à un bloc de données
dans le cluster.
Un hash cluster est une alternative qui peut être intéressante dans la mesure où
l'accès aux données se fera sans lecture annexe dans l'index du cluster mais
directement dans le bloc dont l'adresse est le résultat d'un calcul basé sur la valeur de
la clé. Le résultat est que l'accès à une ligne se fera par un minimum d'une seule
opération d'E/S.
La figure ci-dessus met en évidence les différences de méthodes d'accès à des

données en utilisant les clusters avec index et les hash clusters.
De nombreux critères doivent être pris en compte pour mettre en place les hash
clusters. On peut citer les valeurs des paramètres SIZE, HASHKEYS, INITIAL, … On
trouvera la discussion sur ce sujet et tous les paramètres à prendre en compte pour
effectuer des choix opportuns sur ce sujet dans le Administrator's Guide (Managing
Scheme Objects).
Intégrité des données

Qu'est-ce que l'intégrité des données ? Il est important (poilaudents) que les données
adhèrent à un ensemble de règles prédéfinies, telles que déterminées par
l'administrateur de la base de données ou le développeur d'applications. Comme
exemple d'intégrité de données, considérons les tables EMP et DEPT et les règles
appliquées à ces tables, telles qu'illustrées dans la figure ci-dessous.

A chacune de ces règles peut correspondre une définition de contrainte qu'il est
possible d'appliquer par le biais des commandes du LDD d'Oracle.
Types de règles d'intégrité des données

On distingue les principales règles suivantes :
Null Autorise ou non la présence de valeurs indéterminées dans la colonne à
laquelle on applique cette contrainte
Valeurs Une règle qui interdira toute redondance dans la colonne concernée.
uniques
Clé primaire Une règle définie sur une colonne de telle façon que chaque ligne de la
table sera identifiée de façon unique et interdisant les valeurs
indéterminées (null).
Intégrité Une règle définie sur une ou un ensemble de colonnes qui permet
référentielle l'insertion ou la mise à jour d'une ligne seulement si la valeur de la
colonne ou l'ensemble de colonnes égale une valeur présente dans une
colonne d'une autre table (la valeur référencée).
L'intégrité référencielle inclut aussi les règles qui dictent quels types de
manipulations de données sont autorisées sur les données référencées et
quelles actions doivent être réalisées sur les données qui en dépendent, en
résultat de toutes actions menées sur les données de référence. Les règles
associées à l'intégrité référencielle sont :
Restrict Une règle qui interdit la mise à jour ou l'effacement des
données référencées.
Set to Null Quand les données référencées sont mises à jour ou
effacées, toutes les données dépendantes prennent la
valeur null
Set to Default Quand les données référencées sont mises à jour ou
effacées, toutes les données dépendantes associées
prennent une valeur par défaut.
Cascade Lorsque les valeurs référencées sont mises à jour, toutes
les données associées dépendantes sont mises à jour de
façon à maintenir une correspondance ; quand les lignes
référencées sont effacées, toutes les lignes associées
dépendantes sont supprimées.
Vérification Il s'agit de règles définies par l'utilisateur pour une colonne ou un
d'intégrité ensemble de colonnes, relatives au contenu de la colonne, qui autorise ou
complexe interdit les inserts, updates ou delete d'une ligne en se basant sur la
valeur qu'elle contient pour cette colonne.
Comment Oracle applique l'intégrité des données

Oracle permet de définir et d'appliquer chaque type de règles d'intégrité définies ci-
dessus. La plupart de ces règles sont définies facilement en utilisant les contraintes
d'intégrité. Une contrainte d'intégrité est une méthode déclarative pour définir une
règle sur une colonne d'une table. Les contraintes d'intégrité supportées par Oracle
sont décrites en détail dans la section "CONSTRAINT clause" de l'annexe sur les
commandes.
Oracle permet d'appliquer des règles d'intégrité en utilisant une approche non
déclarative (non prévue dans le LDD) basée sur l'utilisation des triggers base de
données (des procédures stockées dans la database invoquées automatiquement lors
des commandes INSERT, UPDATE, DELETE). Voir le support PL/SQL, section Triggers.
Dictionnaire de données
Introduction
L'une des plus importantes parties d'une base Oracle est son dictionnaire de données.
Ce dictionnaire est un ensemble de tables à utiliser comme une référence en read-
only, qui fournit des informations sur la database associée, par exemple, le
dictionnaire de données peut fournir les informations suivantes :
Les noms des utilisateurs Oracle
Les privilèges et les rôles de chaque utilisateur
Les noms des objets d'un schéma (table, vue, index, etc)
Les informations sur les contraintes d'intégrité
Les valeurs par défaut des colonnes
Combien d'espace a été attribué, ou est actuellement utilisé par les objets de la
base de données
Procéder à des audits, tels qui a eu accès ou mis à jour divers objets
D'autres informations générales sur la database
Le dictionnaire de données est structuré en tables et en vues, comme toutes les
données de la base. Pour accèder au dictionnaire de données, on utilise SQL. Etant
donné que le dictionnaire de données est en lecture seule, les utilisateurs peuvent
seulement exécuter des requêtes (commande SELECT).
La structure du dictionnaire de données

Le dictionnaire de données est composé de :
Tables de base La base du dictionnaire de données est composée d'un
ensemble de tables sous-jacentes où sont stockées les
informations de la database associée. Ces tables sont
écrites et lues uniquement par Oracle. On y accède
rarement directement en tant que utilisateur parce qu'elles
sont normalisées et de nombreuses données sont stockées
sous forme cryptée.

Vues accessibles Le dictionnaire de données contient des vues accessibles
aux utilisateurs aux utilisateurs qui synthétisent et affichent de façon
intelligible les informations des tables de base et du
dictionnaire. La plupart des utilisateurs ont accès aux vues
plutôt qu'aux tables de base.
SYS, le proriétaire du dictionnaire de données

Toutes les tables de base et les vues accessibles aux utilisateurs du dictionnaire de
données sont la propriété de l'utilisateur SYS. En conséquence de quoi aucun
utilisateur Oracle ne devrait jamais modifier un objet contenu dans le schéma SYS, et
l'administrateur de la sécurité du système devrait garder un contrôle très stricte sur ce
compte central.
Comment le dictionnaire est utilisé

Le dictionnaire de données a deux usages primordiaux :
Oracle accède au dictionnaire de données chaque fois qu'une commande du LDD est
exécutée.
Tout utilisateur peut utiliser le dictionnaire comme une référence en lecture seule
pour obtenir des informations sur la base de données.
L'accès aux vues du dictionnaire se fait via le langage SQL. Certaines vues sont
accessibles à tous les utilisateurs Oracle, alors que d'autres sont réservées aux tâches
d'administration.
Le dictionnaire de données est toujours accessible lorsque la base est ouverte. Il réside
sur le tablespace SYSTEM, qui est toujours online quand la base est ouverte.
Le dictionnaire de données consiste en plusieurs ensembles de vues. Dans de
nombreux cas un ensemble est constitué de trois vues contenant des informations
similaires et distinguées les unes des autres par leur préfixe.
Préfixe Champ d'application

USER Les vues des utilisateurs
ALL Vues des utilisateurs étendues
DBA Les vues de l'administrateur de la database
L'ensemble des colonnes est identique au travers des vues à ces exceptions près :
Les vues préfixées de USER excluent en général la colonne OWNER. Cette colonne
est implicitement utilisée par les vues USER comme ayant pour valeur le nom de
l'utilisateur rédigeant la requête.
Quelques vues DBA ont des colonnes additionnelles contenant des informations
utiles à l'administrateur.
Vues ayant comme préfixe USER

Ce sont les vues typiquement utiliées par l'utilisateur courant. Ces vues :
Font référence à l'environnement privé de l'utilisateur, lui fournissant des
informations sur les objets qu'il a créés, les droits qu'il a donnés aux autres
utilisateurs, etc.
Affichent uniquement les lignes pertinentes pour l'utilisateur.
Ont les mêmes colonnes que les autres vues (ALL) excepté la colonne OWNER qui
est implicite.
Retournent un sous ensemble des informations contenues dans les vues ALL.

Peuvent avoir des synonymes PUBLIC par commodité.
Par exemple, la requête suivante retourne la liste de tous les objets contenus dans
votre schéma :
SELECT object_name, object_type
FROM user_objects;
Les vues préfixées de ALL

Les vues avec le préfixe ALL font référence à l'ensemble des objets de tous les
utilisateurs de la base.
Par exemple, la requête suivante donne des informations sur tous les objets auxquels
vous avez accès :
SELECT owner, object_name, object_type
FROM all_objects;
Les vues préfixées de DBA

Les vues préfixées par DBA montrent une vue globale de la base de données entière ;
elles sont donc supposées être utilisées uniquement par l'administrateur de la
database. Tout utilisateur possédant le privilège système SELECT ANY TABLE peut
effectuer des requêtes sur les vues ayant le préfixe DBA. Il n'y a pas de synonyme créé
pour ces vues puisqu'elles sont censées être l'objet de requêtes uniquement par les
administrateurs, par conséquent pour faire une requête sur les vues DBA, les
administrateurs doivent préfixer le nom de la vue par son propriétaire, SYS comme
dans :
SELECT owner, object_name, object_type
FROM sys.dba_objects;
Les administrateurs peuvent exécuter le scripte DBA_SYNONYMS.SQL pour créer des
synonymes privés leur appartenant.
La table DUAL
La table nommée DUAL est une petite table référencée par Oracle et les programmes
écrits par les utilisateurs pour garantir un résultat connu. Cette table a une colonne et
une ligne. Elle permet par exemple, de prendre connaissance de la valeur des pseudos
colonnes :
SELECT sysdate
FROM dual;
Les tables de performances dynamiques

Tout au long de ses opérations, Oracle maintient à jour un ensemble de tables
"virtuelles" qui enregistrent l'activité de la base. Ces tables sont appelées dynamic
performance tables.
Dans la mesure où ces tables ne sont pas de vraies tables, elles ne devraient pas être
utilisées par beaucoup d'utilisateurs. Toutefois, les administrateurs de la base peuvent
effectuer des requêtes sur ces tables et peuvent créer des vues auxquelles les autres
utilisateurs auront accès.
Les tables de performances dynamiques sont possédées par SYS et leurs noms
commencent tous par V_$. Des vues sont créées sur ces tables, et ensuite des
synonymes sont créés sur ces vues. Les noms des synonymes commencent par V$.

Accès concurrents, verrous
Généralités
En général, les bases de données multi-utilisateurs utilisent une forme quelconque de
verrouillage de données pour résoudre les problèmes associés à l'accès concurrent aux
données, à leur intégrité et à leur cohérence. Les verrouillages sont des mécanismes
utilisés pour prévenir des intéractions destructives entre des utilisateurs accèdant aux
mêmes ressources, tels que des verrouillages d'une table entière ou des lignes
spécifiques d'une table. On entend par intéractions destructives toute intéraction qui
met à jour incorrectement des données ou qui modifie la structure d'une table, d'une
colonne … La perte de données et des opérations du LDD destructives en sont de bons
exemples.
Les ressources concernées incluent en général deux types généraux d'objets :
Les objets utilisateurs (tables, lignes - structures et données ).
Les objets systèmes invisibles aux utilisateurs (structures mémoire, dictionnaire de
données …).
En général, deux niveaux de verrouillage peuvent être utilisés dans une base de
données multi-utilisateurs :
Les verrous exclusifs (exclusive locks) : un verrou exclusif interdit le partage des
ressources associées. La première transaction à verrouiller une ressource est la
seule qui puisse la modifier jusqu'à son déverrouillage.
Les verrous partagés (share locks) : un verrou partagé permet à la ressource
associée d'être partagée selon les opérations engagées sur celle-ci. Par exemple,
plusieurs utilisateurs peuvent lire les mêmes données au même moment.
Plusieurs transactions peuvent obtenir un share lock sur la même ressource.
Les verrous partagés autorisent une plus grande finesse au niveau du contrôle des
accès concurrents aux données que les verrous exclusifs.
Modèle de cohérence multi-version

Oracle assure la cohérence de lecture à deux niveaux différents : cohérence de lecture
au niveau commande et au niveau transaction.
Cohérence de lecture au niveau commande

Oracle impose toujours la cohérence de lecture au niveau commande, qui garantit que
les données retournées par une
réquête sont cohérentes en
regard du moment où la requête
a commencé à s'exécuter. Donc,
une requête ne voit jamais les
changements réalisés sur les
tables concernées, par des
transactions qui se terminent
(COMMIT) durant l'exécution de
la requête. Pour produire cette
cohérence Oracle se base sur le
SCN (System Change Number)
quand une requête entre dans sa
phase d'exécution. Voir figure ci-
contre.

Cohérence de lecture au niveau transaction
Oracle donne aussi la possibilité d'imposer une cohérence de lecture au niveau
transactionnel. Il peut garantir que les données vues par toutes les requêtes d'une
même transaction sont cohérentes par rapport à un moment donné. Donc, la
cohérence de lecture au niveau transactionnel produit des lectures reproductibles.
Oracle permet cette cohérence de lecture en utilisant différentes méthodes :
Transactions en READ-ONLY : ces transactions peuvent contenir uniquement des
requêtes. Pour fournir des lectures reproductibles dans ce type de transaction
Oracle observe le début de celle-ci. Pendant la durée de la transaction seules les
données validées (COMMIT) avant son début sont disponibles.
Verrous exclusifs sur tables et lignes : si des lectures reproductibles sont requises
dans une transaction qui contient des commandes du LMD, une transaction peut
explicitement acquérir des verrous partagés (share locks) sur les tables ou des
verrous exclusifs (exclusive locks) sur des lignes qui doivent retourner des
lectures reproductibles. Cette solution fournit une bonne cohérence de lecture
dans la transaction bien qu'elle limite les possibilités d'accès concurrents.
Mécanismes de verrouillage
Oracle utilise automatiquement différents types de verrous pour contrôler l'accès
concurrent aux données et prévenir des intéractions destructives entre utilisateurs.
Oracle verrouille automatiquement une ressource en faveur d'une transaction pour
empêcher d'autres transactions de faire quelque chose qui nécessiterait un accès
exclusif à la même ressource. Le verrou est automatiquement levé quand certains
évènements se produisent et que la transaction n'utilise plus la ressource.
Il faut bien garder présent à l'esprit que les verrouillages posés par Oracle le sont de
façon totalement automatique et ne demandent aucune intervention. Des verrous
implicites se produisent pour toutes les commandes SQL, de sorte que les utilisateurs
n'ont jamais besoin de verrouiller explicitement une ressource. Tout ce qui suit
suppose que deux paramètres d'initialisation ont leurs valeurs par défaut :
SERIALIZABLE = FALSE
ROW_LOCKING = ALWAYS
Différents types de verrous

Les différents types de verrous à différents niveaux que peut poser Oracle selon la
ressource à verrouiller et les commandes à exécuter tombent dans l'une de ces
catégories :
Verrouillage de données (LMD Locks) : concerne les verrouillages de tables (leurs
données) ou de lignes.
Verrouillage du dictionnaire (LDD Locks) : concerne la protection des structures des
objets (définition des tables, des vues, …).
Verrous internes : concernent la structure interne de la base de données
(entièrement automatique).
Verrous distribués : concernent les architectures réparties.
Verrouillage des données

L'objectif du verrouillage de données (LMD locks) est de protéger les données des
tables et de garantir l'intégrité des données lorsque ces données sont manipulées
concurremment par plusieurs utilisateurs. Par exemple, les verrous sur les données
garantissent qu'une ligne spécifique d'une table peut-être mise à jour par seulement
une transaction à n'importe quel moment et que la table ne peut être supprimée
(DROP) si une transaction non terminée contient une commande insert into.

Les commandes du LMD peuvent obtenir des verrouillages sur les données à deux
différents niveaux : pour des lignes spécifiques ou pour la table entière.
Verrouillage de ligne (Row Locks)

Un verrouillage de données exclusif est obtenu pour une ligne dans une transaction
quand la ligne est modifiée par l'une des commandes suivantes : INSERT, UPDATE,
DELETE et SELECT suivit de l'option FOR UPDATE.
Une ligne est toujours verrouillée en mode exclusif de sorte que d'autres utilisateurs
ne puissent la modifier tant que la transaction détenant le verrouillage n'est pas
"committée" ou "rollbackée". Les verrouillages de lignes sont toujours posés
automatiquement par Oracle comme conséquence des commandes listées ci-dessus.
Verrouillage de lignes et verrouillage de tables. Si une transaction obtient un
verrou sur une ligne la transaction obtient aussi un verrou sur la table. Un verrou sur
la table doit aussi être obtenu pour éviter les opérations du LDD conflictuelles qui
pourraient empiéter sur les modifications de données dans une transaction en cours.
Verrouillage de tables (Table Locks)

Une transaction obtient un verrou sur une table lorsque la table est modifiée par les
commandes suivantes du LMD : INSERT, UPDATE, DELETE, SELECT avec l'option FOR
UPDATE, et LOCK TABLE. Ces commandes LMD nécessitent des verrous sur la table
pour deux raisons :
Pour se réserver un certain niveau d'accès LMD sur les tables pour le compte de la
transaction
Et pour éviter les conflits avec les opérations du LDD qui gèneraient les
modifications de données dans une transaction en cours.
Tout verrou sur une table protège de l'acquisition d'un verrou LDD exclusif sur la
même table, restreignant ainsi les opérations du LDD qui requièrent un verrouillage
LDD exclusif sur la table. Par exemple, une table ne doit pas être modifiée (ALTER) ou
supprimée si une transaction en cours détient un verrou pour cette table.
Un verrouillage des tables peut-être obtenu dans l'un des modes suivants : row share,
row exclusive, share lock, share row exclusive et exclusive. Le degré de restriction du
mode de verrouillage d'une table détermine les modes dans lesquels les autres
verrouillages de tables sur la même table pourront être obtenus et gardés.
Durée des verrous sur les données

Du moment qu’un verrou a été posé sur une donnée, il reste actif jusqu’à ce qu’un
COMMIT ou un ROLLBACK soit effectué.
Verrouillage des objets (DDL Locks - dictionary locks)

Un verrou LDD protège la définition d'un objet (p.ex. une table) pendant que cet objet
est engagé dans une opération LDD en cours (se souvenir qu'une commande LDD
commit implicitement une transaction). Par exemple, supposons qu'un utilisateur crée
une procédure. En plus de l'exécution de la commande, Oracle pose automatiquement
des verrous LDD pour tous les objets référencés dans la définition de la procédure. Ce
qui évite que les objets référencés dans la procédure ne soient modifiés ou supprimés
avant que la compilation de la procédure ne se termine.
Un verrou LDD est posé automatiquement par Oracle en arrière plan de toutes
transactions LDD qui le demande. Les utilisateurs ne peuvent pas requérir
explicitement un verrou LDD. Seuls des objets individuels qui sont modifiés ou
référencés sont verrouillés durant les opérations LDD. Les verrous LDD tombent dans
deux catégories principales : les exclusive DDL locks, share DDL locks.

Verrous DDL Exclusifs (Exclusive Locks)
Par exemple, une commande DROP TABLE ne peut pas s'exécuter tant qu'une
commande ALTER TABLE est en train d'ajouter une colonne à la table et vice versa.
En plus des DDL lock, les opérations LDD obtiennent aussi des DML locks (verrouillage
des données) sur les objets modifiés. La plupart des opérations LDD obtiennent des
verrous exclusifs sur les objets à modifier. Les exceptions sont vues ci-après.
Verrous DDL Partagés (Share DDL Locks)

Certaines opérations LDD requièrent des verrous LDD partagés (share DDL locks) pour
une ressource afin de se prémunir contre les interférences destructives avec des
opérations LDD en conflit, mais autorisent l'accès concurrent aux données pour des
opérations LDD similaires. Par exemple, quand une commande CREATE PROCEDURE
est exécutée, la transaction qui la contient obtient un share DDL lock pour toutes les
tables référencées. Les autres transactions peuvent concurremment créer des
procédures qui font référence à la même table et donc, acquérir des share DDL locks
concurrents sur les mêmes tables, mais aucune transaction ne peut obtenir un
exclusive DDL lock sur aucune des tables référencées. Aucune transaction ne peut
modifier ou supprimer une table référencée. Le résultat obtenu est que la transaction
qui détient un share DDL lock est assurée que la définition de l'objet référencé
demeurera constante pendant la durée de la transaction.
Durée des verrous sur les Objets

La durée des DDL locks varie selon le type de verrou. Les verrous LDD exclusive et
share durent toute la durée de l'exécution de la commande et le commit implicite de la
transaction qui s'ensuit.

Les commandes gérant les verrous
Verrouillage de tables
LOCK TABLE NomTable IN Mode MODE [NOWAIT]
où Mode peut être : ROW SHARE
ROW EXCLUSIVE
SHARE
SHARE ROW EXCLUSIVE
EXCLUSIVE
ex : LOCK TABLE emp IN SHARE ROW EXCLUSIVE MODE NOWAIT;
Cette commande permet de verrouiller manuellement la totalité d’une table
Verrouillage de lignes
SELECT ... FOR UPDATE OF Colonne;
Autres verrouillages
Généralement, il faut savoir que les tables sont totalement vérrouillées par toutes les
commandes modifiant le contenu des tables (y compris les commandes du L.M.D).
Verrouillage explicite des données

Oracle met toujours en place les verrouillages nécessaires pour garantir l'accès
concurrent aux données, les règles d'intégrité et la cohérence des lectures au niveau
des commandes. Toutefois, des options sont disponibles pour ignorer les mécanismes
de verrouillages par défaut. Les situations où il devrait être avantageux d'ignorer les
verrouillages par défaut d'Oracle sont les suivantes :
les applications demandent une cohérence de lecture au niveau transactionnel ou
des lectures répétées (les transactions doivent demander un ensemble cohérent
de données pendant la durée de la transaction, sachant que les données n'ont
pas été modifiées par quelques autres transactions du système). La cohérence en
lecture au niveau de la transaction peut être obtenue uniquement en utilisant
des verrouillages explicites, des transactions en lecture seule, ou en ignorant les
verrouillages par défaut pour le système.
Les applications nécessitent qu'une transaction ait un accès exclusif à une
ressource. Pour exécuter ces commandes, la transaction avec accès exclusif à la
ressource n'a pas à attendre la fin d'autres transactions.
Les mécanismes de verrouillage automatique peuvent être suplantés à deux niveaux
(de deux façons) différents :
au niveau de la transaction : les transactions qui contiennent les commandes SQL
suivantes ignorent les verrouillages par défaut d'Oracle : la commande LOCK
TABLE, la commande SELECT avec l'option FOR UPDATE et la commande SET
TRANSACTION avec l'option READ ONLY. Les verrouillages obtenus par ces
commandes sont libérés lorsque la transaction se termine.
Au niveau système : une instance peut être lancée avec des verrouillages
personnalisés en ajustant les paramètres d'initialisation SERIALIZABLE et ROW
LOCKING.
Les sections suivantes décrivent chaque option disponible pour suplanter les
verrouillages par défaut d'Oracle (attention à la valeur du paramètre DML_LOCKS).
Si vous remplacez les verouillages automatiques d'Oracle par des verrous explicites,
! assurez vous du bon fonctionnement des procédures mises en place. En particulier,
veiller à éviter les situations de Deadlocks!

Obtenir des verrouillages de tables explicites
Une transaction obtient le verrouillage spécifié sur une table quand la commande
LOCK TABLE est exécutée. Cette commande remplace les verrouillages par défaut. Si
elle est exécutée sur une vue, les tables sous-jacentes sont verrouillées. La commande
suivante fait l'acquisition d'un verrouillage exclusif des tables EMP et DEPT en faveur
de la transaction qui la contient :
LOCK TABLE emp, dept
IN EXCLUSIVE MODE NOWAIT;
L'option NOWAIT permet d'obtenir le verrouillage seulement s'il est immédiatement
disponible. Sinon une erreur est renvoyée. Dans ce cas on peut refaire une tentative
ultérieurement. Si NOWAIT est omis la transaction ne se fait pas jusqu'à ce que le
verrouillage demandé est obtenu. Si le temps d'attente pour un verrouillage de table
est excéssif vous pourriez désirer annuler la demande et réessayer plus tard ; vous
pourriez dans ce cas là, préférer coder cette logique dans vos applications. Les
paragraphes suivants fournissent des indications sur les situations où il peut être
intéressant d'acquérir chaque type de verrouillage de table utilisant la commande
LOCK TABLE.
ROW SHARE et ROW EXCLUSIVE

LOCK TABLE table IN ROW SHARE MODE;
LOCK TABLE table IN ROW EXCLUSIVE MODE;
Les verrouillages de table en mode ROW SHARE et ROW EXCLUSIVE offrent le degré
de contrôle le plus fin de l'accès concurrent. Les raisons qui peuvent justifier
l'acquisition explicite d'un verrouillage de table en mode ROW SHARE ou ROW
EXCLUSIVE sont :
votre transaction doit empécher une autre transaction d'obtenir un "partage
interférant" (un share Row ou un verrouillage exclusif) pour une table avant que
celle-ci puisse être mise à jour dans votre transaction. Si une autre transaction
obtient un "partage interférant", un share Row ou un verrouillage exclusif pour
une table, aucune autre transaction ne peut mettre à jour la table jusqu'à ce que
la transaction qui verrouille se termine.
Votre transaction doit empêcher une table d'être modifiée ou supprimée avant que
la table puisse être modifiée plus tard dans votre transaction.
SHARE
LOCK TABLE table IN SHARE MODE;
Les verrouillages de table en mode SHARE sont des verrouillages de données plutôt
restrictifs. Les conditions qui peuvent justifier l'acquisition explicite d'un verrouillage
de table en mode SHARE sont :
votre transaction fait seulement des requêtes sur la table et requiert un ensemble
cohérent des données de la table pour toute la durée de la transaction.
On peut accepter, si d'autres transactions tentent de mettre à jour la table
verrouillée concurremment, qu'elles aient à attendre que toutes les transactions
avec le verrouillage en mode SHARE se terminent.
Il est acceptable d'autoriser d'autres transactions à acquérir des verrouillages
concurrents en mode SHARE sur la même table leur permettant ainsi la
possibilité d'une cohérence de lecture au niveau de leur transaction.
Votre transaction peut ou non mettre à jour la table plus tard dans la même
! transaction. Toutefois, si plusieurs transactions détiennent concurremment un
verrouillage de type SHARE sur la même table aucune d'entre elles ne peut
mettre à jour la table. Donc, si ces types de verrouillages concurrents sur la
même table sont fréquents les mises à jour ne peuvent se faire et les

"deadlocks" seront fréquents (utilisez SHARE ROW EXCLUSIVE ou EXCLUSIVE à
la place).
Par exemple, supposons que 2 tables EMP et BUDGET demandent un ensemble de
données cohérent à une troisième table DEPT. C'est-à-dire pour un numéro de
département donné on veut mettre à jour les informations dans les deux tables et
s'assurer qu'il n'y ait pas d'ajouts de nouveaux membres du département entre ces
deux transactions.
Bien que ce scénario soit assez rare il peut être géré en verrouillant la table DEPT en
SHARE MODE comme décrit ci-dessous :
LOCK TABLE dept IN SHARE MODE;
UPDATE EMP
SET sal = sal * 1.1
WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS');
UPDATE budget
SET totsal = totsal * 1.1
WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS');
COMMIT;
SHARE ROW EXCLUSIVE

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;
Les conditions qui justifient l'acquisition d'un verrouillage en SHARE ROW EXCLUSIVE
sont :
votre transaction requiert à la fois une cohérence de lecture au niveau de la
transaction pour la table spécifiée et la possibilité de mettre à jour la table
verrouillée.
Vous n'êtes pas concerné par des verrouillages explicites au niveau ligne obtenus
(c'est-à-dire, via SELECT …FOR UPDATE) par d'autres transactions qui peuvent
ou non faire que les commandes UPDATE et INSERT dans la transaction
bloquante attendent pour mettre à jour la table.
Vous voulez que juste une seule transaction ait les propriétés ci-dessus.
EXCLUSIVE
LOCK TABLE table IN EXCLUSIVE MODE;
Les conditions qui justifient l'acquisition explicite d'un verrouillage exclusif d'une table
sont :
votre transaction demande un accès en mise à jour immédiat à la table verrouillée.
Donc si votre transaction détient un verrouillage exclusif de la table, les autres
transactions ne peuvent bloquer des lignes spécifiques.
Votre transaction respecte aussi la cohérence de lecture au niveau de la transaction
pour la table verrouillée jusqu'à ce qu'il y ait COMMIT ou ROLLBACK.
Acquisition explicite de verrouillage par ligne

SELECT ... FOR UPDATE OF Colonne;
SELECT * FROM emp
WHERE deptno=30
FOR UPDATE OF sal, comm;
Permet de placer un verrou exclusif sur une ou plusieurs lignes d’une table (et non sur
des colonnes). Après un SELECT ... FOR UPDATE, on effectue normalement la
commande Update. Celle-ci verrouille toute la table. Pour minimiser les inconvénients
liés à ce verrouillage automatique de la table :

Utiliser la commande SELECT ... FOR UPDATE
Dès que la commande Update est lancée, penser à effectuer immédiatement un
COMMIT ou un ROLLBACK pour déverrouiller la table

Annexe
Quelques commandes

La commande CREATE TABLE
Syntaxe
Mots clés et Paramètres
schema
est le nom du schéma qui contient la table. Si non spécifié, la table est créé dans le
schéma courant
table
Nom de la table à créer
column
Nom d'une colonne de la table (max.: 254 colonnes).
Peut être omis si la clause AS est utilisée.
datatype
est le type de données de la colonne
Peut être omis si la commande désigne aussi la colonne comme faisant partie d'une clé
étrangère (foreign key) d'une contrainte d'intégrité référentielle. Dans ce cas elle
prend automatiquement le type de la clé étrangère référencée.

DEFAULT
Spécifie une valeur par défaut à affecter à la colonne si elle n'est pas spécifiée dans un
INSERT.
Peut être toute expression respectant le type de données prévu pour la colonne.
Ne peut pas être une référence à une autre colonne, aux pseudo colonne (CURRVAL,
NEXTVAL, LEVEL, ROWNUM, ou des constantes dates incomplètement spécifiées).
column_constraint
Définit une contrainte d'intégrité. Voir la description de la syntaxe dans la partie
décrivant la CONSTRAINT CLAUSE
table_constraint
idem, pour la table
PCTFREE
Spécifie le pourcentage d'espace devant être laissé libre dans chaque bloc contenant
des données de cette table réservé pour de futurs UPDATE).
Doit être compris entre 0 et 99.
Valeur par défaut: 10.
PCTUSED
Spécifie le pourcentage minimum d'espace utilisé dans les blocs de cette table, en
deçà duquel, le bloc redeviendra candidat lors de prochaines INSERTions.
Valeur par défaut: 40.
La somme de PCTFREE et PCTUSED doit être inférieure à 100.
Pour la détermination optimal des deux valeurs conjointement se reporter au Oracle7
Server Tuning.
INITRANS
Ce paramètre garantit qu'un nombre minimum de transactions pourront s'effectuer
concuremment sur cette table. Il ne devrait pas être modifié de sa valeur par défaut,
mais il agit surtout sur la réservation de place dans l'en-tête du bloc réservé à la
gestion des transactions.
MAXTRANS
Mêmes remarques que pour INITRANS.
TABLESPACE
Spécifie le nom du Tablespace dans lequel devra être gérée la table. Sinon, Oracle crée
la table dans le tablespace par défaut pour l'utilisateur.
STORAGE
Spécifie les caractéristiques de stockage des données de la table.
Voir la clause STORAGE
RECOVERABLE

Spécifie que la création de la table sera répertoriée dans les fichiers redo (ainsi que
toutes les informations relatives aux définitions de contraintes).
C'est l'option par défaut.
UNRECOVERABLE
Même rôle (inversé) que l'option précédente. Dans ce cas une restauration ne recréera
pas la table, mais par contre la création de la table sera plus rapide (bof!).
CLUSTER
Spécifie que la table sera stockée dans un cluster, avec comme noms de colonnes, les
colonnes servant de clés dans le cluster.
Les noms de colonnes doivent être spécifiées dans le même ordre que lors de la
déclaration des clés pour le cluster.
Si cette option est utilisée, ne pas utiliser les paramètres PCTFREE, PCTUSED,
INITRANS, ou MAXTRANS , l'option TABLESPACE, STORAGE, car le stockage dans les
clusters se fait de façon indépendante de ces paramètres.
PARALLEL
Option réservée au fonctionnement de la database en mode Parallel Server.
ENABLE
Active une contrainte d'intégrité
DISABLE
Désactive une contrainte d'intégrité
Si non précisé, c'est l'option enable qui est utilisée par défaut lors de la définition
d'une contrainte à la création d'une table.
AS subquery
Permet de créer une table au moyen d'une sous requête qui la définit et la remplit en
une seule opération.
Une commande CREATE TABLE ne peut contenir à la fois une clause AS et une
déinition de contrainte d'intégrité référentielle.
CACHE
Spécifie que les blocs lus pour cette table sont placés à la plus récente extrémité de la
liste LRU dans le buffer cache. Permet un séjour plus long de la table en SGA.
Intéressant pour des petites tables utilisées en consultation fréquemment.
NOCACHE
Idem, inversé. C'est la valeur par défaut.

STORAGE Clause
But
Spécifier les caractéristiques de stockage des tables, index, clusters et Rollback

Segments et les caractéristiques par défaut des Tablespace.
Prerequis
Cette clause peut apparaître dans les commandes de création ou de modification de

l'un quelconque des objets suivants :
clusters
indexes
rollback segments
snapshots
snapshot logs
tables
tablespaces
Syntaxe
Mots clés et paramètres
INITIAL
Spécifie la taile en octets du premier extent de l'objet. On peut spécifier la taille en K
ou M, la taille par défaut étant 5 blocs.
NEXT
Spécifie la taille en octets du prochain extent alloué pour cet objet.

PCTINCREASE
Spécifie le pourcentage par lequel chaque extent après le second grossira par rapport
au précédent. La valeur par défaut est 50 (%). La valeur minimale est 0, signifiant que
tous les extents après le premier auront tous la même taille.
Pour les Rollback Segment, ce paramètre vaut toujours 0.
MINEXTENTS
Spécifie le nombre total d'extents alloués à la création du segment. Ce paramètre
permet d'allouer un large espace lorsque l'on crée un objet, même si l'espace
disponible n'est pas contigu. La valeur minima et par défaut est 1, ce qui signifie
qu'Oracle n'alloue que le initial extent, sauf pour les Rollback Segment (2 extents).
Si la valeur de MINEXTENT est supérieure à 1, alors Oracle calcule les tailles des
extents subséquents, en se basant sur les valeurs de INITIAL, NEXT et PCTINCREASE.
MAXEXTENTS
Spécifie le nombre total d'extents, le premier compris.
FREELIST GROUPS
Pour les objets autres que les tablespace, spécifie le nombre de groupes de freelist
pour une table, un cluster ou index.
N'utiliser ce paramètre que pour le fonctionnement en Parallel Server.
FREELISTS
Pour les objets autres que les tablespace, spécifie le nombre de free list pour chaque
groupe de free list pour la table, cluster ou index
La valeur par défaut est 1, ce qui signifie que chaque groupe de free list contient une
free list.
On peut spécifier ce paramètre uniquement dans les commandes CREATE TABLE,
CREATE CLUSTER, et CREATE INDEX.
Notes d'utilisation
Le paramètre STORAGE affecte à la fois les temps d'accès aux données stockées dans
la base et l'efficacité avec laquelle l'espace dans la base de données est utilisé. Pour
une discussion plus approfondie sur les effets de ces paramètres, voir la section
"Tuning I/O" de la documentation Oracle7 Server Tuning.
Lorsque l'on crée un Tablespace, on peut spécifier cette clause de STORAGE. Elle
s'appliquera aux segments alloués dans le Tablespace. Lorsque l'on créera un objet
sujet à ce paramètre, Oracle lui appliquera automatiquement ces paramètres de
stockage; sauf si l'on spécifie pour l'objet des valeurs autres qui prévaudront sur les
valeurs par défaut appliquées à tout le Tablespace. Quelques exemples tirés de la
documentation d'Oracle :

Exemple I
La commande suivante crée une table et fournit des valeurs aux paramètres de la
clause STORAGE :
CREATE TABLE dept
(deptno NUMBER(2),
dname VARCHAR2(14),
loc VARCHAR2(13) )
STORAGE (INITIAL 100K NEXT 50K
MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 5 )
Oracle alloue de l'espace à la table selon les paramètres des paramètres de la clause
STORAGE selon les règles suivantes :
Puisque la valeur de MINEXTENTS est 1, Oracle7 alloue 1 extent pour la table à la
création.
Puisque la valeur de INITIAL est 100K, la taille du premier extent est 100 kilobytes.
Si la quantité de données dans la table croît jusqu'à excéder la taille du premier
extent, Oracle7 alloue un deuxième extent. Puisque la valeur du paramètre NEXT est
50K, la taille du prochain extent est 50 kilobytes.
Si la table continue à croitre de façon telle que le second extent se révèle insuffisant,
Oracle7 alloue a troisième extent.
Puisque la valeur de PCTINCREASE est 5, la taille calculée pour le troisième extent
sera de 5% supérieure à la taille du second, à savoir 50K + 5%, donc 52.5K. Si la
taille du bloc est de 2K, Oracle7 arrondira cette valeur à 52 kilobytes.
Et ainsi de suite…
Puisque la valeur de MAXEXTENTS est de 50, Oracle7 peut allouer jusqu'à 50 extents
pour la table.
Exemple II
La commande suivante crée un rollback segment et fournit des valeurs pour le
paramètre STORAGE
CREATE ROLLBACK SEGMENT rsone
STORAGE ( INITIAL 10K NEXT 10K
MINEXTENTS 2 MAXEXTENTS 25
OPTIMAL 50K )
Oracle7 alloue de l'espace pour le rollback segment en se basant sur les valeurs des
paramètres STORAGE :
La valeur de MINEXTENTS est à 2, Oracle7 alloue 2 extents pour le rollback segment à
la création.
Dans la mesureoù la valeur de INITIAL est 10K, la taille du premier extent est 10
kilobytes.
La valeur de NEXT est 10K, donc la valeur du second extent est de 10 kilobytes.
Si les données du rollback segment excèdent les deux premiers extents, Oracle7 alloue
un troisième extent.
Puisque la valeur de PCTINCREASE pour les rollback segments est toujours 0, le
troisième extent a la même taille que le second extent, 10 kilobytes.
Si les données dans le rollback segment continuent à croitre, Oracle7 alloue des
extents suppléméntaires, tous de la même taille que le précédent, 10 kilobytes.
La valeur de MAXEXTENTS étant à 25, Oracle7 peut allouer 25 extents pour le rollback
segment.

Etant donné que la valeur du paramètre OPTIMAL est de 50K, Oracle7 libère
(désalloue) les extents si le rollback segment excède 50 kilobytes. Il est à noter que
Oracle7 libère uniquement les extents qui contiennent des données de transactions qui
ne sont plus actives.
Voir aussi
Les commandes CREATE CLUSTER, CREATE INDEX, CREATE ROLLBACK SEGMENT,
CREATE TABLE, CREATE TABLESPACE

CONSTRAINT clause
But
Définir une contrainte d'intégrité. Une contrainte d'intégrité est une règle qui restreint
les valeurs que peuvent prendre une ou plusieurs colonnes d'une table.
Pré requis
La clause CONSTRAINT peut apparaître aussi bien dans la commande CREATE TABLE
que dans la commande ALTER TABLE
Syntaxe
Cette clause supporte deux syntaxes :
Contrainte posée sur la table : nécessaire uniquement si la contrainte concerne
plusieurs colonne (p.ex., définir une clé primaire sur deux colonnes).
Contrainte sur une colonne : utilisée pour poser une contrainte sur une colonne
particulière.
Syntaxe Table_constraint

Syntaxe Colonne_constraint
Mots clés et paramètres
CONSTRAINT
Permet d'identifier la contrainte par un nom, faute de quoi, Oracle7 enregistre la
contrainte sous un nom de la forme :
SYS_Cn
Où n est un entier attribué par Oracle assurant l'unicité du nom de la contrainte dans
la base.
NULL
Spécifie que la colonne peut contenir une valeur NULLe. C'est la valeur par défaut.
NOT NULL
Spécifie que la colonne ne peut pas contenir une valeur NULLe.
UNIQUE
Désigne une ou plusieurs colonnes comme clé unique.
PRIMARY KEY
Désigne une ou plusieurs colonnes comme étant la clé primaire de la table.
FOREIGN KEY
Désigne une colonne ou plusieurs colonnes comme étant la clé étrangère dans une
contrainte d'intégrité référentielle.
REFERENCES

Identifie la clé primaire ou unique référencée par une clé étrangère dans une
contrainte d'intégrité référentielle.
identifies the primary or unique key that is referenced by a foreign key in a referential
integrity constraint.
ON DELETE CASCADE
Spécifie que Oracle7 maintiendra l'intégrité référentielle en supprimant
automatiquement les valeurs de clés étrangères dépendantes si l'on supprime une
valeur de clé primaire ou unique référencée.
CHECK
Spécifie une condition que chaque ligne de la table doit remplir.
USING INDEX
Permet de spécifier des caractéristiques particulières pour l'index qui sera créé
automatiquement par Oracle pour mettre en application les contraintes UNIQUE ou
PRIMARY KEY. Le nom de l'ndex est le même que celui de la contrainte. On peut choisir
les valeurs des paramètres : INITRANS, MAXTRANS, TABLESPACE, STORAGE,
PCTFREE, RECOVERABLE, et UNRECOVERABLE
NOSORT
Indique que les lignes sont stockées en ordre ascendant et donc qu'Oracle n'aura pas à
les trier lors de la création de l'index.
DISABLE
Désactive la contrainte. Par défaut, une contrainte est activée dès sa définition.
On activer/désactiver une contrainte en utilisant les clauses ENABLE et DISABLE des
commandes CREATE TABLE et ALTER TABLE.

Definir des contraintes d'intégrité
Pour définir des contraintes d'intégrité, on peut utiliser l'une des deux formes pré-
citées: contraintes définies au niveau de la table ou au niveau des colonnes. Pour
préciser l'utilisation possible de ces formes ainsi que l'utilisation appropriée des
paramètres On s'appuiera sur les exemples qui suivent.
Exemple I (définir une contrainte NOT NULL)

La commande suivante modifie la structure de la table emp et définit en l'activant la
contrainte NOT NULL sur la colonne SAL.
ALTER TABLE emp
MODIFY (sal NUMBER CONSTRAINT nn_sal NOT NULL)
NN_SAL assure qu'il n'y a pas d'employés dans la table ayant des valeurs nulles pour
la colonne salaires (sal)
Exemple II (définir une contrainte UNIQUE)

La commande suivante crée la table DEPT et définit et active une clé unique sur la
colonne DNAME.
CREATE TABLE dept
(deptno NUMBER(2),
dname VARCHAR2(9) CONSTRAINT unq_dname UNIQUE,
loc VARCHAR2(10) ) ;
La contrainte UNQ_DNAME identifie la colonne DNAME comme étant une clé unique.
On peut définir la même contrainte en utilisant la syntaxe table_constraint :
CREATE TABLE dept
(deptno NUMBER(2),
dname VARCHAR2(9),
loc VARCHAR2(10),
CONSTRAINT unq_dname UNIQUE (dname)
USING INDEX
PCTFREE 20 TABLESPACE user_x STORAGE (INITIAL 8K NEXT 6K) )
On en profite pour découvrir l'usage de l'option USING INDEX
Exemple III (définir une clé UNIQUE composite)

La commande suivante définit et active une telle contrainte sur la combinaison des
deux colonnes CITY et STATE de la table CENSUS :
ALTER TABLE census
ADD CONSTRAINT unq_city_state UNIQUE (city, state)
USING INDEX
PCTFREE 5 TABLESPACE user_y
EXCEPTIONS INTO bad_keys_in_ship_cont ;
La contrainte UNQ_CITY_STATE garantit que la même combinaison de valeurs pour les
colonnes CITY et STATE, n'apparaîtront pas plus d'un fois dans la table
La clause CONSTRAINT spécifie aussi d'autres propriétés :
L'option USING INDEX option spécifie des caractéristiques de stockage pour l'index.
L'option EXCEPTIONS amène Oracle7 à écrire des informations dans la table
BAD_KEYS_IN_SHIP_CONT sur toute ligne se trouvant actuellement dans la table
SHIP_CONT et qui viole la contrainte

Les contraintes PRIMARY KEY
Une contrainte PRIMARY KEY désigne une colonne ou combinaison de colonnes,
comme étant la clé primaire d'une table.. Pour satisfaire à cette contrainte, les
conditions suivantes doivent être respectées :
UNIQUE
NOT NULL
Une seule clé primaire par table
On ne peut pas utiliser les types LONG ou LONG RAW dans une clé primaire.
On peut désigner une colonne (ou combinaison) comme étant à la fois primary key et
une foreign key.
Exemple IV (Definir une Primary Key)

La commande suivante crée la table DEPT et définit et active une primary key sur la
colonne DEPTNO :
CREATE TABLE dept
(deptno NUMBER(2) CONSTRAINT pk_dept PRIMARY KEY,
dname VARCHAR2(9),
loc VARCHAR2(10) ) ;
La contrainte PK_DEPT identifie la colonne DEPTNO comme étant la primary key de la
table DEPTNO. Ceci garantit qu'il n'y aura pas deux départements qui auront la même
valeur et qu'il n'y aura pas de valeur nulle dans cette colonne.
Autrement, on peut définir et activer cette même contrainte en utilisant la syntaxe
table_constraint :
CREATE TABLE dept
(deptno NUMBER(2),
dname VARCHAR2(9),
loc VARCHAR2(10),
CONSTRAINT pk_dept PRIMARY KEY (deptno) ) ;

Exemple V (Definir une Primary Key composite)
Etant donné qu'à la mise en place d'une contrainte primary key, Oracle construit un
index sur les colonnes la composant, on retrouvera les mêmes limites que sur ceux-ci,
à savoir limitation à 16 colonnes. Pour définir une contrainte primary key sur plusieurs
colonnes on est obligé d'utiliser la syntaxe table_constraint.
La commande suivante définit sans l'activer une primary key composite sur les
colonnes SHIP_NO et CONTAINER_NO de la table SHIP_CONT :
ALTER TABLE ship_cont
ADD PRIMARY KEY (ship_no, container_no)
DISABLE
La clause CONSTRAINT spécifie également les propriétés suivantes pour la contrainte :
Puisque le nom de la contrainte n'est pas précisé, Oracle la nomme
automatiquement
L'option DISABLE oblige Oracle à définir la contrainte sans l'activer

Contraintes d'intégrité référentielles
Une contrainte d'intégrité référentielle désigne une colonne (ou une combinaison)
comme étant une clé étrangère (foreign key) et établit une relation entre cette foreign
key et une primary key ou unique spécifiée, appelée la clé référencée (referenced
key).
Dans cette relation, la table contenant la foreign key est appelée la table fille (child
table) et la table contenant la référence est appelée la table parent (parent table).
A noter les points suivants :
Les tables fille et parent doivent se trouver sur la même base de données et non sur
différents nœuds d'une base de données distribuée. Dans ce cas là, la seule
façon d'assurer un contrôle de l'intégrité référentielle sera l'utilisation de
triggers.
La foreign key et la clé référencée peuvent se trouver sur la même table. Dans ce
cas les tables fille et parents sont la même table.
Pour satisfaire une contrainte d'intégrité référentielle, chaque ligne de la table fille doit
remplir l'une de ces conditions :
La valeur de la foreign key doit apparaître dans l'une des lignes de la table parent.
On dit de la ligne de la table fille qu'elle dépend de la clé référencée dans la table
parent.
La valeur de l'une des colonnes qui constituent la foreign key doit (peut) être null.
Une contrainte d'intégrité référentielle est définie dans la table fille. La définition d'une
contrainte d'intégrité référentielle peut contenir l'un des mots clés suivants :
FOREIGN KEY
Identifie la colonne (ou combinaison) dans la table fille qui constitue la foreign key. On
n'utilise ce mot clé que lorsque l'on utilise la syntaxe table_constraint.
REFERENCES
Identifie La table parent et la colonne (ou combinaison) qui constituent la clé
référencée.
Il doit y avoir correspondance de taille et de type entre les colonnes foreign key et la
colonne référencée
ON DELETE CASCADE
Autorise la suppression de valeurs dans la table parent qui ont des lignes dépendantes
dans la table fille en entraînant la suppression par Oracle, des lignes dépendantes
dans la table fille
Si cette option est omise, les suppressions sont interdites dans la table parent pour les
lignes qui ont des lignes dépendantes dans la table file.
Avant de définir une contrainte d'intégrité référentielle dans la table fille, la contrainte
unique ou primary key doit avoir été déjà définie dans la table parent.
On ne peut pas définir une contrainte d'intégrité référentielle dans une commande
CREATE TABLE qui contient une clause AS. Dans ce cas on définira la contrainte
d'intégrité référentielle au moyen d'une commande ALTER TABLE.
On peut définir plusieurs foreign keydans une seule table, de même qu'une colonne
peut faire partie de plus d'une foreign key

Exemple VI (Définir une contrainte foreign key)
La commande qui suit crée la table EMP et definit et active une foreign key sur la
colonne DEPTNO qui fait référence à la clé primaire sur la colonne DEPTNO de la table
DEPT :
CREATE TABLE emp
(empno NUMBER(4),
ename VARCHAR2(10),
job VARCHAR2(9),
mgr NUMBER(4),
hiredate DATE,
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno CONSTRAINT fk_deptno REFERENCES dept(deptno) )
La contrainte FK_DEPTNO garantit que tous les departments donnés pour le employés
de la table EMP sont présents dans la table DEPT. Cependant, les employés peuvent
avoir des numéros de département null, ce qui veut dire qu'ils peuvent n'être affectés
à aucun département. Si l'on souhaite éviter cette dernier fait, on peut créer une
contrainte NOT NULL sur la colonne deptno de la table EMP, en plus de la contrainte
REFERENCES.
Avant de définir et activer cette contrainte, il faut avoir défini la contrainte qui désigne
la colonne DEPTNO de la table DEPT comme une primary ou unique key (voir
exemple IV)
Exemple VI Bis (Définir une contrainte foreign key) .

Noter que la définition de la contrainte d'intégrité référentielle n'utilise pas le mot clé
FOREIGN KEY pour identifier les colonnes qui constituent la foreign key. Etant donné
que la contrainte est définie au niveau de la colonne DEPTNO (column_constraint
syntax), la foreign key est automatiquement sur la colonne DEPTNO.
Noter que la définition de la contrainte identifie à la fois la table parent et la colonne
de la clé référencée. Comme la clé référencée est la clé primaire de la table parent, les
noms des colonnes référencées est superflu.
Noter également que la définition de la colonne DEPTNO omet de préciser son type;
dans la mesure où elle est une foreign key Oracle lui alloue automatiquement le type
de la colonne référencée.
On a l'alternative de définir la même contrainte d'intégrité référentielle en utilisant la
syntaxe table_constraint :
CREATE TABLE emp
(empno NUMBER(4),
ename VARCHAR2(10),
job VARCHAR2(9),
mgr NUMBER(4),
hiredate DATE,
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno,
CONSTRAINT fk_deptno FOREIGN KEY (deptno) REFERENCES dept(deptno) )
On peut aussi noter que dans ces deux commandes, l'option ON DELETE CASCADE est
omise, amenant ainsi Oracle7 à interdire l'effacement d'un département s'il existe au
moins un employé qui y travaille.
Exemple VII (Utiliser ON DELETE CASCADE)

Cet exemple crée la table EMP table, definit et active la contrainte d'intégrité
référentielle FK_DEPTNO, et utilise l'option ON DELETE CASCADE :
CREATE TABLE emp
(empno NUMBER(4),
ename VARCHAR2(10),
job VARCHAR2(9),
mgr NUMBER(4),
hiredate DATE,
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno NUMBER(2) CONSTRAINT fk_deptno REFERENCES dept(deptno)
ON DELETE CASCADE )
L'effacement de la ligne du département 20 est effacée dans la table DEPT, entraînera
la suppression automatique par Oracle des ligne comportant la même valeur dans la
table EMP.
Exemple VIII (Intégrité référentielle et clés multiples)

Pour satisfaire une contrainte d'intégrité référentielle impliquant des clés composées,
chaque ligne de la table fille, doit satisfaire aux conditions suivantes :
Les valeurs des colonnes de la foreign key doivent correspondre aux valeurs de la
clé référencée dans une ligne de la table parent
Les valeurs d'au moins une des colonnes de la foreign key doivent être nulles.
La commande suivante définit et active une foreign key sur la combinaison des
colonnes AREACO et PHONENO de la table PHONE_CALLS :
ALTER TABLE phone_calls
ADD CONSTRAINT fk_areaco_phoneno
FOREIGN KEY (areaco, phoneno)
REFERENCES customers(areaco, phoneno)
EXCEPTIONS INTO wrong_numbers
La contrainte FK_AREACO_PHONENO garantit que tous les appels dans la table
PHONE_CALLS sont des numéros qui sont présents dans la table CUSTOMERS. Avant
de définir cette contrainte, il faut avoir défini, dans la table CUSTOMERS une
contrainte sur la combinaison des colonnes AREACO and PHONENO en faisant une clé
primaire ou unique composite
L'option EXCEPTIONS oblige Oracle7 à écrire des informations dans la table
WRONG_NUMBERS sur toute ligne de la table PHONE_CALLS qui viole la contrainte.
Les contraintes CHECK

La contrainte CHECK définit explicitement une condition. Pour satisfaire à la
contrainte, chaque ligne de la table doit donner un résultat TRUE ou inconnu (valeur
NULL. La condition de la contrainte CHECK peut se référer à toute colonne dans la
table, mais ne peut faire référence à une colonne d'autres tables. Les conditions d'une
contrainte CHECK ne peuvent pas contenir les constructions suivantes :
Les requêtes se référant aux valeurs d'autres lignes
Appels aux fonctions SYSDATE, UID, USER, or USERENV
Les pseudo colonnes CURRVAL, NEXTVAL, LEVEL, or ROWNUM
Les constantes date qui ne sont pas complètement définies.
Chaque fois qu'Oracle7 evalue la condition d'une contrainte CHECK pour une ligne
particulière, tout nom de colonne dans la condition fait référence à la valeur de cette
colonne dans cette ligne.
Si l'on crée plusieurs contraintes CHECK pour une colonne, définissez les avec soin afin
d'éviter qu'elles ne donnent des résultat s'excluant mutuellement.

Oracle7 ne vérifie pas que des conditions CHECK ne sont pas mutuellement exclusives.
Exemple IX (contraintes CHECK)

La commande suivante crée la table DEPT et définit une contrainte CHECK sur chaque
colonne de la table :
CREATE TABLE dept
(deptno NUMBER CONSTRAINT check_deptno CHECK (deptno BETWEEN 10 AND 99)
DISABLE,
dname VARCHAR2(9) CONSTRAINT check_dname CHECK (dname = UPPER(dname))
DISABLE,
loc VARCHAR2(10) CONSTRAINT check_loc CHECK (loc IN ('DALLAS','BOSTON')) DISABLE)
;
Chaque contrainte restreint les valeurs que peut prendre la colonne sur laquelle elle
est définie.
Contrairement aux autres types de contraintes, une contrainte CHECK définie en
utilisant la syntaxe column_constraint peut imposer des règles sur n'importe quelle
colonne de la table, plutôt qu'uniquement sur la colonne sur laquelle elle est définie.
Exemple X (contraintes CHECK)

La commande suivante crée la table EMP et utilise la syntaxe table_constraint pour
définir et activer une contrainte CHECK :
CREATE TABLE emp
(empno NUMBER(4),
ename VARCHAR2(10),
job VARCHAR2(9),
mgr NUMBER(4),
hiredate DATE,
sal NUMBER(7,2),
comm NUMBER(7,2),
deptno NUMBER(2),
CHECK (sal + comm <= 5000) )
Cette contrainte utilise une inégalité pour limiter la somme de la rémunération totale
d'un employé à $5000:
Si un employé a un salaire ou une commission nulle, le résultat de la condition sera
indéterminé et donc, la condition sera automatiquement satisfaite
Etant donné que la contrainte n'est pas nommée, Oracle génèrera automatiquement
un nom pour celle-ci.

Exemple XI (contraintes CHECK)
La commande suivante crée la table order_detail, définit et active une contrainte
PRIMARY KEY, deux contrainte d'intégrité référentielle, une contrainte NOT NULL, et
deux contraintes CHECK :
CREATE TABLE order_detail
(CONSTRAINT pk_od PRIMARY KEY (order_id, part_no),
order_id NUMBER CONSTRAINT fk_oid REFERENCES scott.order (order_id),
part_no NUMBER CONSTRAINT fk_pno REFERENCES scott.part (part_no),
quantity NUMBER CONSTRAINT nn_qty NOT NULL CONSTRAINT check_qty_low
CHECK (quantity > 0),
cost NUMBER CONSTRAINT check_cost CHECK (cost > 0) )
Les contraintes établissents les règles suivantes sur les données de la table
PK_OD
identifie la combinaison des colonnes ORDER_ID et PART_NO comme étant la primary
key de la table. Pour satisfaire cette contrainte, les conditions suivantes doivent être
vraies :
Il ne doit pas y avoir deux lignes dans la table qui peuvent contenir la même
combinaison de valeurs dans les colonnes ORDER_ID et PART_NO.
Il ne doit pas y avoir de lignes dans la table qui peuvent contenir des valeurs NULL
dans les colonnes ORDER_ID ou PART_NO.
FK_OID
identifie la colonne ORDER_ID comme une foreign key qui fait référence à la colonne
ORDER_ID dans la table ORDER se trouvant dans le schéma de SCOTT. Toutes les
nouvelles valeurs ajoutées à la colonne ORDER_DETAIL.ORDER_ID doivent déjà
apparaître dans la colonne SCOTT.ORDER.ORDER_ID.
FK_PNO
identifie la colonne PART_NO comme étant une foreign key faisant référence à la
colonne PART_NO dans la table PART, appartenant à SCOTT. Toutes les nouvelles
valeurs ajoutées à la colonne ORDER_DETAIL.PART_NO doivent déjà apparaître dans la
colonne SCOTT.PART.PART_NO.
NN_QTY
Interdit la présence de nulls dans la colonne QUANTITY.
CHECK_QTY
garantit que les valeurs de la colonne QUANTITY sont toujours supérieures à 0.
CHECK_COST
garantit que les valeurs de la colonne COST sont toujours supérieures à 0.
Cet exemple illustre également les points suivants sur les clauses des contraintes et
les définitions de colonnes :
La syntaxe Table_constraint et la définition de colonnes peuvent apparaître dans
n'importe quel ordre. Dans cet exemple, la définition de la contrainte PK_OD
précède la définition des colonnes; Ce qui n'était pas le cas dans l'exemple IV
Une définition de colonne peut utiliser une syntaxe column_constraint plusieurs
fois. Dans cet exemple, la définition de la colonne QUANTITY contient à la fois les
définitions des contraintes de NN_QTY et de CHECK_QTY.
Une table peut avoir plusieurs contraintes. Plusieurs contraintes CHECK, chacune
avec une condition simple est une meilleure solution que la définition d'une seule
contrainte CHECK avec une condition complexe mettant en application de
multiples règles à respecter. Quand une contrainte est violée, Oracle7 retourne
un message d'erreur identifiant la contrainte. Un tel message d'erreur identifie
plus précisément la règle qui a été violée si la contrainte identifiée comme étant
à l'origine du message d'erreur, correspond à une seule règle.

La commande CREATE
SEQUENCE
Voici les principales options. La liste complète des options et leur effet se trouvera
dans documentation Oracle, "SQL Langage Reference".
But
Créer une séquence. Une sequence est un objet de la database à partir duquel de
multiples utilisateurs peuvent generer un unique nombre entier.
On peut utiliser une séquence pour générer automatiquement des valeurs de clé
primaires.
Pre requis
Pour céer une séquence dans votre propre schéma, vous devez avoir le privilège
CREATE SEQUENCE.
Dans une autre schéma, vous devez avoir le privilège CREATE ANY SEQUENCE.
Syntaxe
Mots clés et Paramètres
schema
est le schéma contenant la séquence.
séquence
est le nom de la séquence à créer.
INCREMENT BY
Spécifies l'intervalle de croissance des nombres de la séquence. Cet entier peut avoir
n'importe quelle valeur positive ou negative. Cette valeur peut avoir 28 chiffre ou
moins. La valeur par défaut est 1.

START WITH
spécifie la valeur du premier nombre généré.
CYCLE
spécifie que la séquence continue à générer des valeur après qu'elle ait atteint son
maximum. Après qu'une séquence ait atteint son maximum, une séquence génèrera
sa valeur minimale.
NOCYCLE
spécifies que la séquence ne peut générer de valeur après avoir atteint sa valeur
maximum ou minimum (si décroissante).
CACHE
spécifie combien de valeurs de la séquence Oracle7 pré-alloue et garde en mémoire
pour un accès plus rapide. Le minimum est 2. La valeur par défaut est 20.
Utilisation des Séquences

A partir des exemples qui suivent, on pourra se faire une idée de leur utilisation.
Dès qu'une séquence est créée, on pourra accéder à ses valeurs par les pseudo
colonne suivantes :
CURRVAL
retourne la valeur courante de la séquence.
NEXTVAL
incrémente la séquence et retourne une nouvelle valeur.
Exemple 1
La commande suivante crée la séquence ESEQ:
CREATE SEQUENCE eseq
INCREMENT BY 10
La première référence à ESEQ.NEXTVAL retourne 1. La seconde 11…
Exemple 2
La commande suivante utilise dans une procédure PL/SQL la séquence ESEQ:
SELECT esep.nextval INTO var
FROM dual ;
On peut faire référence à la séquence également directement dans une commande
telle que insert : INSERT INTO table
VALUES (eseq.nextval, …..);

Concepts Oracle

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Concepts Oracle

Transféré par

Droits d'auteur :

Formats disponibles

Oracle 8 à 10

Accès concurrents, verrous..........................................................35

La commande CREATE TABLE.......................................................45

La commande CREATE SEQUENCE................................................63

Oracle - Concepts P .2 R. Amore

Oracle - Concepts P .3 R. Amore

Au démarrage d'une instance, la base de données est montée par l'instance. De

Structure des process

Instance en Single Process (mono process)

Instance en Multi Process

Oracle - Concepts P .4 R. Amore

Les process Oracle

Oracle - Concepts P .5 R. Amore

Oracle - Concepts P .7 R. Amore

Un autre type de configuration intéressante est celle où Oracle fonctionne en Multi-

Oracle - Concepts P .8 R. Amore

Oracle - Concepts P .10 R. Amore

Oracle - Concepts P .11 R. Amore

Une introduction à PCTFREE et PCTUSED

Oracle - Concepts P .12 R. Amore

Interraction entre PCTFREE et PCTUSED

Comment Oracle utilise PCTFREE et PCTUSED

Oracle - Concepts P .13 R. Amore

Disponibilité et Compression de l'espace libre

Oracle - Concepts P .14 R. Amore

Quand se fait cette allocation?

Comment sont alloués les extents

Taille et limites d'un extent

Oracle - Concepts P .15 R. Amore

Oracle - Concepts P .16 R. Amore

Oracle - Concepts P .17 R. Amore

Transactions et Rollback Segment

Oracle - Concepts P .18 R. Amore

Oracle - Concepts P .19 R. Amore

Désallocation d'extents d'un Rollback Segment

Le Rollback Segment SYSTEM

Etats d'un Rollback Segment

Oracle - Concepts P .21 R. Amore

Opérations utilisant les segments temporaires

Oracle - Concepts P .22 R. Amore

Oracle - Concepts P .23 R. Amore

Oracle - Concepts P .24 R. Amore

Agrandissement d'une database

Oracle - Concepts P .25 R. Amore

croissance d'une base de données de façon plus automatisée en particulier par

Oracle - Concepts P .26 R. Amore

Contenu d'un datafile

Oracle - Concepts P .27 R. Amore

Règles guidant les choix opportuns

Effet produit par les clusters

Conditions d’utilisation des clusters:

Modifications d’un cluster.

Oracle - Concepts P .30 R. Amore

La figure ci-dessus met en évidence les différences de méthodes d'accès à des

Intégrité des données

Oracle - Concepts P .31 R. Amore

Types de règles d'intégrité des données

Comment Oracle applique l'intégrité des données

La structure du dictionnaire de données

Oracle - Concepts P .33 R. Amore

SYS, le proriétaire du dictionnaire de données

Comment le dictionnaire est utilisé

Préfixe Champ d'application

Vues ayant comme préfixe USER