Concepts Oracle

64
Oracle 8 à 10 Concepts et structures de base Rosaire Amore

Transcript of Concepts Oracle

Page 1: Concepts Oracle

Oracle 8 à 10

Concepts et structures de base

Rosaire Amore

Page 2: Concepts Oracle

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

Page 3: Concepts Oracle

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.

Oracle - Concepts P .3 R. Amore

Page 4: Concepts Oracle

A r c h i t e c t u r e s y s t è m e

Une instance OracleIndé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 processUn 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.

Oracle - Concepts P .4 R. Amore

Page 5: Concepts Oracle

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.

Oracle - Concepts P .5 R. Amore

Page 6: Concepts 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

Oracle - Concepts P .6 R. Amore

Page 7: Concepts Oracle

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.

Oracle - Concepts P .7 R. Amore

Page 8: Concepts Oracle

Variantes dans les configurationsLa 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 :

Oracle - Concepts P .8 R. Amore

Page 9: Concepts Oracle

Oracle - Concepts P .9 R. Amore

Page 10: Concepts Oracle

S t r u c t u r e s d e l a b a s e

Segments, Extents et BlocsOracle 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.

Oracle - Concepts P .10 R. Amore

Page 11: Concepts Oracle

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 blocksFormat

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.

Oracle - Concepts P .11 R. Amore

Page 12: Concepts Oracle

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.

Oracle - Concepts P .12 R. Amore

Page 13: Concepts Oracle

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.

Oracle - Concepts P .13 R. Amore

Page 14: Concepts Oracle

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.

Oracle - Concepts P .14 R. Amore

Page 15: Concepts Oracle

!

ExtentsUn 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).

Oracle - Concepts P .15 R. Amore

Page 16: Concepts Oracle

SegmentsUn 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).

Oracle - Concepts P .16 R. Amore

Page 17: Concepts Oracle

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.

Oracle - Concepts P .17 R. Amore

Page 18: Concepts Oracle

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.

Oracle - Concepts P .18 R. Amore

Page 19: Concepts Oracle

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.

Oracle - Concepts P .19 R. Amore

Page 20: Concepts Oracle

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

Oracle - Concepts P .20 R. Amore

Page 21: Concepts Oracle

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.

Oracle - Concepts P .21 R. Amore

Page 22: Concepts Oracle

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

Oracle - Concepts P .22 R. Amore

Page 23: Concepts Oracle

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.

Oracle - Concepts P .23 R. Amore

Page 24: Concepts Oracle

Tablespaces et Data filesIntroduction

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 tablespaces

Une database Oracle est constituée de une ou plusieurs unités logiques de stockage appelées tablespace. Les données de la database est globalement stockées dans les tablespaces de la database.

Tablespaces et datafiles

Chaque tablespace dans une base de données Oracle est 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 datafiles

Les données d'une database sont collectivement stockées dans les 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, segments et tablespaces

Quand un objet d'un schéma tel qu'une table ou un index est créé, son segment est créé dans un tablespace donné de la 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.

Oracle - Concepts P .24 R. Amore

Page 25: Concepts Oracle

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.

Oracle - Concepts P .25 R. Amore

Page 26: Concepts Oracle

!

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

Oracle - Concepts P .26 R. Amore

Page 27: Concepts Oracle

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.

Oracle - Concepts P .27 R. Amore

Page 28: Concepts Oracle

Les objets d'un schémaSché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

Oracle - Concepts P .28 R. Amore

Page 29: Concepts Oracle

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.

Oracle - Concepts P .29 R. Amore

Page 30: Concepts Oracle

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 PRESIDENT 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 clusterD’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

Oracle - Concepts P .30 R. Amore

Page 31: Concepts Oracle

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éesQu'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.

Oracle - Concepts P .31 R. Amore

Page 32: Concepts Oracle

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 uniques

Une règle qui interdira toute redondance dans la colonne concernée.

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é référentielle

Une règle définie sur une ou un ensemble de colonnes qui permet 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

Oracle - Concepts P .32 R. Amore

Page 33: Concepts Oracle

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 d'intégrité complexe

Il s'agit de règles définies par l'utilisateur pour une colonne ou un ensemble de colonnes, relatives au contenu de la colonne, qui autorise ou 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éesIntroduction

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.

Oracle - Concepts P .33 R. Amore

Page 34: Concepts Oracle

Vues accessibles aux utilisateurs

Le dictionnaire de données contient des vues accessibles 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.

Oracle - Concepts P .34 R. Amore

Page 35: Concepts Oracle

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_typeFROM 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_typeFROM 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 sysdateFROM 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$.

Oracle - Concepts P .35 R. Amore

Page 36: Concepts Oracle

A c c è s c o n c u r r e n t s , v e r r o u s

GénéralitésEn 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.

Oracle - Concepts P .36 R. Amore

Page 37: Concepts Oracle

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 verrouillageOracle 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 = FALSEROW_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.

Oracle - Concepts P .37 R. Amore

Page 38: Concepts Oracle

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.

Oracle - Concepts P .38 R. Amore

Page 39: Concepts Oracle

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.

Oracle - Concepts P .39 R. Amore

Page 40: Concepts Oracle

Les commandes gérant les verrousVerrouillage de tables

LOCK TABLE NomTable IN Mode MODE [NOWAIT]

où Mode peut être : ROW SHARE ROW EXCLUSIVESHARESHARE ROW EXCLUSIVEEXCLUSIVE

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éesOracle 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!

Oracle - Concepts P .40 R. Amore

!

Page 41: Concepts Oracle

Obtenir des verrouillages de tables explicitesUne 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, deptIN 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 EXCLUSIVELOCK 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.

SHARELOCK 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

Oracle - Concepts P .41 R. Amore

!

Page 42: Concepts Oracle

"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 EMPSET sal = sal * 1.1WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS');

UPDATE budgetSET totsal = totsal * 1.1WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS');

COMMIT;

SHARE ROW EXCLUSIVELOCK 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.

EXCLUSIVELOCK 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 ligneSELECT ... FOR UPDATE OF Colonne;

SELECT * FROM empWHERE deptno=30FOR 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 :

Oracle - Concepts P .42 R. Amore

Page 43: Concepts Oracle

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

Oracle - Concepts P .43 R. Amore

Page 44: Concepts Oracle

Annexe

Quelques commandes

Oracle - Concepts P .44 R. Amore

Page 45: Concepts Oracle

L a c o m m a n d e C R E A T E T A B L E

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.

Oracle - Concepts P .45 R. Amore

Page 46: Concepts Oracle

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

Oracle - Concepts P .46 R. Amore

Page 47: Concepts Oracle

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.

Oracle - Concepts P .47 R. Amore

Page 48: Concepts Oracle

S T O R A G E C l a u s e

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.

Oracle - Concepts P .48 R. Amore

Page 49: Concepts Oracle

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 :

Oracle - Concepts P .49 R. Amore

Page 50: Concepts 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.

Oracle - Concepts P .50 R. Amore

Page 51: Concepts Oracle

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

Oracle - Concepts P .51 R. Amore

Page 52: Concepts Oracle

C O N S T R A I N T c l a u s e

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

Oracle - Concepts P .52 R. Amore

Page 53: Concepts Oracle

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

Oracle - Concepts P .53 R. Amore

Page 54: Concepts Oracle

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.

Oracle - Concepts P .54 R. Amore

Page 55: Concepts Oracle

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 censusADD CONSTRAINT unq_city_state UNIQUE (city, state)USING INDEX PCTFREE 5 TABLESPACE user_yEXCEPTIONS 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

Oracle - Concepts P .55 R. Amore

Page 56: Concepts Oracle

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) ) ;

Oracle - Concepts P .56 R. Amore

Page 57: Concepts Oracle

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_contADD 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

Oracle - Concepts P .57 R. Amore

Page 58: Concepts Oracle

Contraintes d'intégrité référentiellesUne 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

Oracle - Concepts P .58 R. Amore

Page 59: Concepts Oracle

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)

Oracle - Concepts P .59 R. Amore

Page 60: Concepts Oracle

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

Oracle - Concepts P .60 R. Amore

Page 61: Concepts Oracle

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.

Oracle - Concepts P .61 R. Amore

Page 62: Concepts Oracle

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_PNOidentifie 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_QTYInterdit la présence de nulls dans la colonne QUANTITY.

CHECK_QTYgarantit que les valeurs de la colonne QUANTITY sont toujours supérieures à 0.

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

Oracle - Concepts P .62 R. Amore

Page 63: Concepts Oracle

L a c o m m a n d e C R E A T E S E Q U E N C E

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.

Oracle - Concepts P .63 R. Amore

Page 64: Concepts Oracle

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 varFROM dual ;

On peut faire référence à la séquence également directement dans une commande telle que insert : INSERT INTO table

VALUES (eseq.nextval, …..);

Oracle - Concepts P .64 R. Amore