1

Administration de Base de données Oracle

Chapitre 1 Installation et paramétrage d’Oracle
Section 1 Installation d’Oracle

 Oracle Universal Installer :

L’installateur Universel est un installateur Java utilisé pour installer Oracle, les outils Oracle et les
utilitaires. Il peut installer des logiciels à partir d’un CDROM ou d’Internet, détecter les dépendances
entre les différents composants. Il détecte le langage courant du système d’exploitation ou bien utilise
le langage par défaut. Il est possible de spécifier différents répertoires principaux (Le
ORACLE_HOME) pour permettre d’installer plusieurs versions d’un même produit. L’installation
peut être guidé par des assistants ou permet d’utiliser des packages standard nécessitant un minimum
de réponses. Il est également possible de le lancer en mode silencieux, dans ce cas, un fichier de
réponse est utilisé pour remplacer les réponses aux différentes questions lors de l’installation. Le
mode silencieux est utilisé lorsqu’il n’y a pas de terminal graphique ou lorsque l’on veut que
l’utilisateur n’ait rien à faire pour l’installation.
Un fichier de log est créé lors de l’installation et contient l’ensemble des étapes et les résultats.
Une liste des produits installés est maintenue en cas de désinstallation de l’un d’entre eux. Les
outils de post-installation sont également lancés si besoin est. Par exemple, après l’installation
d’OEM (Oracle Enterprise Manager), l’assistant de configuration de base de données est lancé.
Oracle Database Configuration Assistant :

 Optimal Flexible Architecture (OFA)

OFA est l’architecture standard qu’il est recommandé d’utiliser dans une base de données Oracle. Les
trois règles importantes pour respecter cette architecture sont :
• Etablir une structure de répertoires, où n’importe quel fichier de base de données peut être
enregistré sur n’importe quel espace disque.
• Séparer les objets avec un comportement différent sur différents tablespaces.
• Augmenter les performances de la base de données en séparant les composants de la base de
données sur des disques différents.

 Créer une base de données

Il est possible de créer une base de données à la main avec un script SQL qui utilise la commande
CREATE DATABASE ou tout simplement avec Oracle Database Configuration Assistant.
Assistant de configuration de base de données

Il existe deux méthodes pour créer une base de données. Soit en utilisant l’assistant de configuration
de la base de données, soit en utilisant le commande CREATE DATABASE.
Lors de la création d’une base de données avec l’assistant de configuration, il vous sera demandé de
choisir parmi l’un des quatre types de base de données suivant :
• Installation typique ou personnalisée : L’installation typique est pour une base de données
avec un faible trafic. Le mode personnalisé permet de choisir parmi l’un des environnements
suivant :
• OLTP (OnLine Transaction Processing) : Cet environnement est utilisé pour les grandes
bases de données devant gérer des milliers de transactions (lecture, écriture, suppression) par
2
 jour. Les performances pour ce type d’environnement sont définit en terme de disponibilité
des données.
• Data Warehousing : Cet environnement est utilisé avec des bases de données qui sont
souvent interrogées mais peut modifiées. Les performances de ce type d’environnement sont
définit en terme de temps de réponse.
• Mixed : Environnement supportant à la fois OLTP et Data Warehousing. Mode par défaut
pour l’installation d’une base de données.
 Créer une base de données en mode commande
La principale responsabilité d'un DBA est de créer et de gérer une ou plusieurs bases de données.
Dans ces bases de données peut être stocké un très grand nombre de données qui peuvent être
récupérées et analysées. Le script utilisé pour créer une base de données doit être écrit dans un fichier
texte. Le script est ensuite exécuté en utilisant SQL*Plus (par exemple).
Les conditions d'erreur lors de la création d'une base de données

Il existe plusieurs situations lors de la création d’une base de données avec la commande CREATE
DATABASE qui peuvent provoquer un échec. La connaissance de ces situations permet au DBA
d'identifier les erreurs faites lors de la création d'une base de données.
• Des erreurs de syntaxe dans le script SQL
• Les fichiers que la commande CREATE DATABASE doit créer existent déjà. Cette erreur
apparaît lorsque l’option REUSE n’a pas été spécifiée ou lorsque la taille des fichiers ne
correspond pas.
• Une erreur se produit au niveau du système, telles que des permissions de fichier et de
répertoire non valides.
• Il n’y a pas assez d’espace disque pour créer les fichiers spécifiés dans la commande
CREATE DATABASE.
Dans tous les cas d’échec, il faut arrêter l’instance. Il faut ensuite modifier la commande, redémarrer
l’instance en mode NOMOUNT et créer à nouveau la base de données.
Le contenu d'une base de données après sa création

Oracle crée automatiquement plusieurs fichiers, segments et tables dans une base de données. La
connaissance des éléments qui constituent une base de données permet au DBA d'identifier et de
gérer les objets des bases de données.
Lors de la création de la base de données, le tablespace SYSTEM est créé.
Le tablespace SYSTEM est un ensemble de fichiers de données spécifiés dans la commande
CREATE DATABASE. Il contient le dictionnaire de données.
Les tables du dictionnaire de données sont créées durant la création de la base de données. Les tables
du dictionnaire de données contiennent les informations sur la structure de la base de données, sur les
utilisateurs de la base de données et sur l’allocation de l'espace. Les vues du dictionnaire de données
ne sont pas créées automatiquement lors de la création de la base de données.
Les vues du dictionnaire de données sont des vues sur les tables du dictionnaire de données.
Les fichiers de contrôle et les fichiers redo log sont créés à la création de la base de données. Les
fichiers de contrôle contiennent le nom de la base de données et le chemin d'accès de tous les fichiers
de données et fichiers redo log. Lors de la création de la base de données, les fichiers redo log sont
vides ; ils enregistrent ensuite tous les modifications apportées aux données de la base de données.

3
Les deux utilisateurs par défaut SYS et SYSTEM sont créés à la création de la base de données. SYS
et SYSTEM ont respectivement les mots de passe par défaut « change_on_install » et « manager ».
Les utilisateurs SYS et SYSTEM possèdent tous les privilèges système sur la base de données.
Enfin, lorsque la base de données est créée, le segment de rollback SYSTEM est créé dans le
tablespace SYSTEM. Le segment de rollback SYSTEM est utilisé pour enregistrer les modifications
apportées dans le tablespace SYSTEM.
Section 2 Paramétrage d’Oracle
Authentification et privilèges
Les utilisateurs administrateurs de la base de données sont responsables de la gestion et de
l’administration du serveur Oracle. Des privilèges particuliers sont requis pour permettre de faire ces
taches.
Deux comptes utilisateur DBA sont créés automatiquement et ont le rôle DBA :
Le compte SYS : Créé lors de l’installation d’Oracle avec tous les privilèges systèmes.
Mot de passe par défaut : change_on_install, à changer après l’installation.
Le schéma de SYS stocke toutes les tables et les vues du dictionnaire de base de données.
Aucun utilisateur ne peut modifier ou créer de table dans ce schéma.
Le compte SYSTEM : Créé lors de l’installation d’Oracle avec tous les privilèges systèmes.
Mot de passe par défaut : manager à changer après l’installation.
Le schéma de SYSTEM stocke les tables et les vues administratives ainsi que des informations
administratives propres à certains produits Oracle supplémentaires.
Configurer l’authentification par le système d’exploitation

Des privilèges particuliers sont attribués aux utilisateurs DBA pour les tâches administratives. Pour
s’assurer que seul des utilisateurs valides puissent se connecter à la base de données avec les
privilèges adéquats, Oracle fournit deux méthodes d’authentification. Ces méthodes sont
l’authentification par l’OS ou bien par un fichier de mots de passe (Méthode d’authentification propre
à Oracle).
Configurer l'authentification par fichier de mots de passe

Lorsque la connexion à un serveur distant n’est pas sécurisée (Pas d’authentification par le système
d’exploitation), la solution la plus sécurisée consiste à utiliser l’authentification Oracle (Ou
authentification par fichier de mot de passe).
L’utilitaire ORAPWD.exe permet de créer un fichier de mot de passe.
C’est dans ce fichier que sont consignés les comptes et mots de passe des utilisateurs pour se
connecter au schéma SYS.
Avec cette méthode d’authentification, l’utilisateur SYS peut utiliser la commande GRANT pour
fournir des privilèges DBA à d’autres utilisateurs Oracle.
Fichiers de paramètres

Paramètres présents dans le fichier de paramètre

Une base de données Oracle devient accessible aux utilisateurs lorsque le DBA démarre l’instance et
ouvre la base de données. Pour démarrer une instance, Oracle lit le fichier d’initialisation. Ces fichiers
sont au nombre de deux: le PFILE et le SPFILE. Le PFILE fait communément référence au fichier
init<SID>.ora et le SPFILE (fichier binaire) fait référence au fichier spfile<SID>.ora où SID est le
nom de l’instance.

4
Le fichier de paramètre est un fichier texte contenant la liste des paramètres de démarrage de
l’instance.
Paramètres essentiels

La plupart des paramètres sont optionnels, cependant certains paramètres sont au contraire essentiels
pour l’instance Oracle.
La liste suivante les présente :
DB_NAME : Identifiant de la base de données.
DB_CACHE_SIZE : Ne peut être mis à 0. Gère la taille du buffer par défaut.
DB_KEEP_CACHE_SIZE : Gère la taille du keep buffer cache, utilisé pour stocker les blocks dans la
mémoire susceptible d’être réutilisés.
DB_RECYCLE_CACHE_SIZE : Gère le taille du recycle buffer cache, employé pour supprimer les
blocs de mémoire réutilisé qui ont subi peu de changement.
DB_BLOCK_SIZE : Taille d’un bloc de données spécifié lors de la création de la base de données.
Ne peut être changé après la création.
COMPATIBLE : Version du serveur avec laquelle l’instance pourra être compatible.
CONTROL_FILES : Spécifie le nom des fichiers de contrôle de la base de données.
SHARED_POOL_SIZE : Spécifie la taille du pool partagé en bytes.
BACKGROUND_DUMP_DEST : Spécifie le répertoire ou le process de fond de taches écrit les
fichiers de trace et les fichiers de log d’alertes.
USER_DUMP_DEST : Spécifie le lieu où les fichiers de trace utilisateurs sont créés.
Paramètres communément modifiés

Les paramètres le plus souvent modifiés par le DBA pour une instance donnée sont les suivants :
IFILE : Permet d’inclure un autre fichier de paramètres dans le fichier courant. Peut être utilisé
jusqu’à trois niveaux.
LOG_BUFFER : Spécifie le nombre de bytes qui sont alloués pour le buffer de redo log dans la SGA.
MAX_DUMP_FILE_SIZE : Spécifie la taille maximale en bloc des fichiers de trace.
PROCESSES : Définit le nombre maximum de process du système d’exploitation pouvant être
simultanément connecté à l’instance.
SQL_TRACE : Permet d’activer ou non l’utilitaire de trace SQL pour toutes les sessions utilisateurs.
TIMED_STATISTICS : Permet d’activer ou non la datation des événements dans les fichiers de trace
et les écrans de monitoring.

Chapitre 2 Oracle.Net, le Middleware Oracle

Section 1 Définition de Middleware et d’Oracle.Net
Oracle Net pourrait être défini comme un regroupement de logiciels (Oracle Net, pilotes ODBC,…) et
de matériels (type de réseau, câblage, cartes de communication,…) mis en œuvre entre l’application
cliente et le serveur de données.
Il assure un lien invisible entre les applications du poste client et la base de données sur le serveur.
Pour se connecter à Oracle, il faut trois paramètres :
 le nom de l’utilisateur (déclaré dans la base Oracle cible)
 le mot de passe (déclaré dans la base Oracle cible)
 un alias pour se connecter à la base cible

5
L’alias d’Oracle Net a pour but de regrouper, sous un label, un ensemble de caractéristiques
techniques qui sont :
 le protocole réseau utilisé pour accéder à la machine cible (TCP/IP)
 le nom ou l’adresse de la machine sur laquelle se situe la base
 la SID cible, car la machine distante peut héberger plusieurs bases
 d’autres paramètres qui dépendent du protocole utilisé

Section 2 Oracle.Net et Listener Oracle

Le fichier d’initialisation d’Oracle Net

Les fichiers tnsnames.ora et listener.ora sont les principaux fichiers de paramétrage d’Oracle Net.

Le fichier trace d’Oracle Net

Coté serveur, le listener enregistre tous les démarrages, arrêts, connexions réussies ou échouées dans
le fichier log.
Coté client il est possible de forcer la création d’un fichier trace pour enregistrer tout ce que votre
application confie à Oracle Net dans une communication client/serveur

Configuration d’Oracle Net

Si vous souhaitez accéder à la base de données en mode client-serveur, il est nécessaire de configurer
Oracle Net coté client pour ajouter un point d’entrée au fichier tnsnames.ora

Le listener (écouteur) Oracle

Les paramètres regroupés sous un alias significatif sont ceux qui sont envoyés à la machine cible.
Celle-ci doit être à l’écoute des demandes de connexions : c’est le rôle du listener oracle. Celui-ci doit
être paramétré et lancé
La configuration la plus simple pour un listener est d’en établir un par serveur, ce qui permet de se
connecter à toutes les bases hébergées sur le serveur. Une fois qu’il est démarré, le listener reconnait
automatiquement toutes les instances démarrées sur le serveur

Les assistants Oracle Net : Netca et Netmgr

Netca (Oracle Net Configuration Assistant) > $ORACLE_HOME\BIN\launch.exe
"$ORACLE_HOME\network\tools"…\network\tools \netca.cl
Netmgr (Oracle Net Manager) > $ORACLE_HOME\BIN\launch.exe
"$ORACLE_HOME\network\tools"…\network\tools \netmgr.cl.
Ces assistants vous aident dans toutes les taches de conception de fichiers de configuration d’Oracle
Net. Netca est le plus simple, l’utilisateur est guidé pas à pas pour enter les paramètres nécessaires à
une configuration. Par contre netmgr est beaucoup plus complet, il permet d’accéder à l’ensemble des
paramètres qui peuvent figurer dans les fichiers de configurations.

Chapitre 3 Programmer avec PL/SQL

Section 1 types de données PL/SQL
Les types de données PL/SQL

6
Utilisation et traitement des variables
Une variable est un espace de stockage temporaire de données.
variable_name [CONSTANT] datatype [NOT NULL] [ := | DEFAULT expr] ;

Une fois déclarées, les variables peuvent être utilisées de façon répétée dans une application
simplement en les référençant dans d'autres ordres même déclaratifs. Les valeurs stockées par la
variable peuvent être manipulées.

Utilisation et traitement des variables :

- Déclarer et initialiser les variables dans la section déclarative.
Les déclarations allouent l'espace de stockage nécessaire pour une valeur, spécifient les types de
données et nomment la localisation du stockage qui sert à le référencer. Affecter de nouvelles
valeurs aux variables dans la section exécutable.
- Nommer les identifiants selon les règles utilisées pour la dénomination des objets SQL.
- Affecter une valeur initiale à une variable déclarée comme NOT NULL et/ou CONSTANT.
- Initialiser une variable avec une expression, en utilisant l’opérateur d’affectation " := " ou le mot
réservé DEFAULT. Par défaut, la valeur NULL est affectée aux variables.
- Passer les variables à des sous-programmes à l'aide de paramètres.
PL/SQL prend en charge quatre types de données qui peuvent être utilisés pour la déclaration de
variables, de constantes, de pointeurs ou de localisateurs :

Scalaire Contient une valeur unique mais pas de composants internes.

Contient des composants internes qui peuvent être manipulés. Ce type de

données est réutilisable. Les variables de type composé sont des variables
Composé
temporaires auxquelles différentes valeurs peuvent être affectées au cours de
l’exécution. Ex : types RECORD, TABLE, NESTED TABLE et VARRAY.

Référenc Il s’agit d’un pointeur vers un autre type de données. Il contient des valeurs
e appelées pointeurs, désignant d’autres objets programme.

Il s'agit d'un "localisateur" qui spécifie la localisation de gros objet (des images,
LOB
des vidéos…) qui sont stockés "out offline".

Il existe trois types de variables non-PL/SQL :

- les variables de substitution (cf Module 2 § 4.1 Les variables de substitutions)
- les variables définies par l'utilisateur (cf Module 2 § 4.2 Les variables définies par l'utilsateur) -
les variables hôtes (appelées aussi "bind" variable)

2.1.2 Les types de données scalaires

Un type de données scalaires est utilisé pour stocker une valeur unique. En PL/SQL, le type de
données scalaire est divisé en quatre catégories : nombre, caractères, date et booléen.
Les types scalaires les plus utilisés et leurs sous-types :

NUMBER INTEGER Entier.

7
 POSITIVE Entier positif

Entiers entre -2 147 483 647

BINARY_INTEGER
et 2 147 483 947.

NUMBER Nombre flottant

[(précision,degré)]

Entiers signés entre -2 147 483 647

PLS_INTEGER
et 2 147 483 947.

Chaîne de caractères variable (jusqu’à 32 760

LONG
octets).

VARCHAR2 Chaîne de caractères variable (jusqu’à 32 767

CHAR octets, pas de valeur par défaut)

Chaîne de caractère fixe (jusqu’à 32767 octets,

CHAR
si maximum_lenght n'est pas spécifié, alors sa
[(maximum_length)].
taille est 1).

Date et heure. La tranche des dates est de 4712

DATE
B.C. à 9999 A.D.

Type de données pouvant stocker trois valeurs

BOOLEAN possibles utilisées pour les calculs logiques :
TRUE, FALSE ou NULL.

Type de données stockant des données

RAW (maximum_size) binaires. Sa taille maximale est de 2 000 octets.
Ce type n'est pas interprété par le PL/SQL.
RAW Type de données stockant des données
LONG RAW binaires. Sa taille maximale est de 32 760
(maximum_size) octets. Ce type n'est pas interprété par le
PL/SQL.

Les valeurs PLS_INTEGER requiert moins d'espace de stockage et sont plus rapide que les valeurs
NUMBER et BINARY_INTEGER.

Les types de données composés

Les types de données composés (appelées aussi collections) sont :

Type de données permettant de déclarer un identifiant pouvant stocker

RECORD une ligne constituée de plusieurs colonnes possédant chacune son
propre nom et son propre type de données.

Type de données permettant de déclarer un identifiant pouvant stocker

TABLE au plusieurs valeurs toutes du même type de données. Une TABLE n'a
pas de taille fixe et possède une colonne PRIMARY KEY.
8
 Type de données permettant de déclarer un identifiant pouvant stocker
au plusieurs valeurs toutes du même type de données. Un tableau
VARRAY
(VARRAY) a une taille minimale fixée à 1 et une taille maximale fixée
lors de sa déclaration.

Les types de données LOB

Les types de données LOB (Large Object) d'Oracle8i, des blocs de données non structurées (tels que
du texte, des images, des fichiers vidéo et fichiers audio…) permettent de stocker des objets jusqu'à
4 gigaoctets dans la base de données.

Il existe quatre types de données LOB :

CLOB CLOB est utilisé pour stocker des gros blocs

de texte (caractères sur 8 bits).
(Character Large Object Binary)

BLOB BLOB est utilisé pour stocker de larges objets

binaires.
(Binary Large Object)

BFILE BFILE est utilisé pour stocker de larges objets

binaires tels que des fichiers OS.
(Binary File)

NCLOB NCLOB est utilisé pour stocker de gros blocs

de données, unité en octet ou multi-octets de
(National Language Character Large
taille fixe.
Object)

Les variables scalaires

Déclaration de variables scalaires
Une variable doit être déclarée avant d'être référencée dans une instruction.
variable_name [CONSTANT] scalair [NOT NULL] [ := | DEFAULT expr] ;
Deux objets (dont les variables) peuvent avoir le même nom à condition qu'ils soient définis dans
des blocs différents.
Les identifiants ont une longueur maximale de 30 caractères. Le premier caractère doit être une
lettre, les caractères suivants peuvent être des lettres, des nombres ou des caractères spéciaux.
Assigner des valeurs aux variables
Pour assigner une valeur à une variable, il faut écrire un ordre PL/SQL d'assignement. La variable
doit être explicitement nommée pour qu'elle reçoive la nouvelle valeur. Cette valeur est placé à
gauche de l'opérateur d'assignement " := ".
Identifiant := expr ;
Il existe une autre façon d'assigner une valeur à une variable : de sélectionner (SELECT) ou de
ramener (FETCH) des valeurs dans la base de données.
Déclarer des variables scalaires à l’aide de %TYPE
Lorsqu'une application doit mettre à jour les valeurs des colonnes d’une table, l'intégrité des
données doit être respectée et les erreurs d'exécution évitées. Les variables PL/SQL qui contiendront
9
 les valeurs des colonnes doivent être déclarées du même type de données que les colonnes à mettre à
jour.
Plutôt que d’écrire explicitement le type de données et la précision, une variable peut être déclarée
en fonction d’une colonne de base de données grâce à l’attribut %TYPE.

variable_name table_name.column_name%TYPE [NOT NULL][ := | DEFAULT expr];

%TYPE est très utile dans la mesure où la déclaration de la variable ne nécessite pas de connaître le
type exacte des données de la colonne de la base de données dont elle va accueillir les valeurs.
PL/SQL détermine le type de données et la précision de la variable de la variable lors de la
compilation du bloc.
De plus, si le type de données de la colonne change dans la base de données, le type de données de
la variable déclarée à l’aide du type %TYPE sera modifié par une recompilation automatique.
Si une variable est déclarée avec %TYPE et référence une colonne définie comme NOT NULL, la
valeur de cette variable peut être quand même être NULL. En effet, la contrainte NOT NULL sur la
colonne ne s'applique pas automatiquement sur la variable. La contrainte NOT NULL doit être
appliquée à la variable pour interdire les valeurs nulles.

L’attribut %TYPE peut aussi être utilisé pour déclarer une variable présentant le même type de
données qu’une autre variable déclarée précédemment.

variable2 variable1%TYPE [NOT NULL] [ := | DEFAULT expr] ;

Les variables composées (les collections)

Les collections TABLE et VARRAY
Définir une collection TABLE
Une table PL/SQL est un tableau à une dimension (une seule colonne utilisable) dynamique,
inconsistant constitué d'éléments homogènes (données du même type) et indexé par des nombres
entiers.
Elle est donc composée de deux colonnes :
- La première colonne est la clé primaire qui sert à indexer la table PL/SQL. Le type de
données de cette colonne est BINARY_INTEGER. ( de -2 147 483 647 à 2 147 483 647).
L'index n'est pas obligé de commencer à 1 et peut être négatif.
- La seconde colonne est du type de données scalaire ou RECORD, elle stocke les éléments de
la table PL/SQL.
La taille d’une table PL/SQL peut augmenter de façon dynamique.
Avant d'utiliser une table PL/SQL, il faut d'abord déclarer un type de données TABLE car il n'existe
pas de types de données TABLE prédéfinies, et ensuite déclarer une variable PL/SQL de ce type.
Déclaration d’un type TABLE PL/SQL :

TYPE type_name IS TABLE OF { column_type | variable%TYPE |

table.column%TYPE | table%ROWTYPE }
[NOT NULL]
[INDEX BY BINARY_INTEGER] ;
10
 La clause INDEX BY est obligatoire en PL/SQL version 2 et optionnelle en
PL/SQL version 8
Définir une collection VARRAY
La collection VARRAY permet d'associer un identifiant unique à une collection entière (un
tableau). Cette association permet de manipuler la collection dans son ensemble et de référencer
facilement chaque élément.
Une collection VARRAY possède une taille maximale qui doit être spécifiée dans sa définition. Son
index a une limite inférieure fixée à 1 et une limite supérieure fixée lors de la déclaration du type.
Syntaxe :

TYPE type_name IS {VARRAY | VARYING ARRAY} {size_limit} OF

{column_type | variable%TYPE | table.column%TYPE | table
%ROWTYPE }
[NOT NULL];
type_name est un type spécifique utilise plus tard pour déclarer une variable VARRAY.
size_limit est un entier positif littéral déterminant le nombre de poste dans la
collection (VARRAY). element_type correspond au type de données PL/SQL des
éléments de la collection. Si le type de données est du type RECORD, tus les
champs du RECORD doivent être du type scalaire ou objet.
Le type des éléments peut être également défini avec %ROWTYPE ou %TYPE.
Déclarer et Initialiser une collection TABLE ou VARRAY
Après avoir créé le type de la collection, il faut déclarer une variable de ce type :
Identifiant type_name ;
Tant qu'elle n'est pas initialisée, une collection est NULL (ce ne sont pas ses éléments qui sont
NULL mais la collection elle-même). Pour initialiser une collection, il faut utiliser un constructeur.
Un constructeur est une fonction définie par le système ayant le même nom que le type de la
collection. Cette fonction "construit" la collection en lui passant des valeurs.
Interroger les collections TABLE et VARRAY
Les méthodes d'interrogation des collections TABLE et VARRAY ont des procédures ou des
fonctions qui opèrent sur des tables et qui permettent d'obtenir diverses informations sur des tables.
Référencer une collection TABLE ou VARRAY
Pour référencer un élément d'une table PL/SQL, il faut utiliser la syntaxe suivante :
collection_name(index)
index doit être est un entier (qui peut être issue d'une expression). Cet entier doit être compris entre
-2**31 et 2**31 en ce qui concerne les tables PL/SQL, et entre 1 et la limite supérieur définie dans
le type en ce qui concerne les tableaux.
Pour pouvoir être affectée le contenu d'une collection à une autre, les deux collections doivent être
du même type.
Deux collections ne peuvent pas être comparées dans une égalité ou dans une inégalité.
Des collections ne peuvent pas apparaître dans une liste DISTINCT, GROUP BY ou ORDER BY.

11
La collection RECORD
Déclarer et définir une collection RECORD
Le type PL/SQL RECORD permet de déclarer un enregistrement PL/SQL pouvant stocker une ligne
constituée de colonnes possédant chacune son propre nom et son propre type de données. Ces
colonnes sont appelées des champs. Ces champs sont créés lors de la déclaration de l’enregistrement
PL/SQL.
Avant d'utiliser un enregistrement PL/SQL, il faut d'abord déclarer un type de données RECORD
car il n'existe pas de types de données RECORD prédéfinis pour les enregistrements PL/SQL, et
ensuite déclarer une variable PL/SQL de ce type.

Déclaration d’un type RECORD :

TYPE type_record_name IS RECORD

( field_name1 { field_type | variable%TYPE | table.column%TYPE
table%ROWTYPE } [NOT NULL { := | DEFAULT} expr],
field_name2 { field_type | variable%TYPE | table.column%TYPE } table
%ROWTYPE } [NOT NULL { := | DEFAULT} expr],
...) ;
L’attribut %TYPE peut être utilisé pour définir le type de données des champs. %TYPE peut
référencer le type de données d'une variable précédemment déclarée ou le type de données d'une
colonne d'une table de base de données. field_type est un type de données PL/SQL (sauf le type
REF CURSOR).
Un enregistrement peut posséder autant de champs (field_name) que nécessaire.
Déclaration d’un enregistrement du type RECORD :
Identifiant type_record_name ;
Les champs ne contenant aucune valeur sont initialisés automatiquement à NULL.
Les types RECORD et les enregistrements peuvent être définis et déclarés dans la section
déclarative d'un bloc, d'un sous-programme ou d'un package.
Un type RECORD peut être le composant d’un autre type RECORD, c’est à dire être imbriqué dans
un autre type RECORD.
La structure d’un enregistrement PL/SQL est semblable à celle d’un enregistrement défini dans un
langage de troisième génération (L3G). Par contre, sa structure est différente de celle d’une ligne
d’une table de base de données.
Un type RECORD peut contenir un ou plusieurs champs de type RECORD. Les types RECORD
peuvent donc être imbriqués.
Déclarer une collection RECORD à l’aide de %ROWTYPE
%ROWTYPE est un attribut utilisé pour déclarer un enregistrement PL/SQL pouvant stocker une
ligne entière de données sélectionnée dans une table ou une vue.
dentifiant table_name%ROWTYPE ;
La structure de l’enregistrement déclaré sera identique à la structure de la table de base de données
spécifiée : l'enregistrement possèdera le même nombre de champs avec les mêmes noms et les
mêmes types de données que les colonnes de la table.
Un enregistrement peut également adopter la structure d'une ligne de données extraites d'un curseur.
Grâce à l'attribut %ROWTYPE :

12
 - Il n’est pas nécessaire de connaître le nombre de colonnes et le type de données des colonnes
sous-jacentes.
- Le type de données des champs de l’enregistrement sera modifié en conséquence lors de
l’exécution et sera automatiquement modifier si le type d'une colonne change.
Cet attribut est utile lors de l’extraction d’une ou plusieurs lignes à l’aide de l’instruction SELECT
ou à l’aide d’un curseur explicite.
Référencer et initialiser une collection RECORD
Pour référencer et/ou initialiser un champ dans un enregistrement, il faut utiliser la syntaxe
suivante : record_name.field_name
Les instructions SELECT..INTO et FETCH permettent d'affecter, en une seule instruction, une
valeur à chaque colonne d'un enregistrement. Les noms des colonnes doivent apparaître dans le
même ordre que les champs de l'enregistrement.
Un champ d'un enregistrement peut être assigné à un champ d'un autre enregistrement à condition
qu'ils aient le même type de données.
Un enregistrement défini par l'utilisateur et un enregistrement défini avec l'attribut %ROWTYPE
n'aura jamais le même type de données.
Des collections imbriquées
Une table d'enregistrements permet de stocker de façon dynamique des enregistrements dans une
table. Une table d'enregistrements est constituée de deux colonnes : une colonne clé primaire et une
colonne de type RECORD.
Pour référencer un champ dans une table PL/SQL :
table(index).field
De la même façon, une collection RECORD peut être imbriquée dans une collection VARRAY
Section 2 Structures de contrôles
LE CONTROLE DES FLUX DANS LES BLOCS PL/SQL
Le contrôle conditionnel

Les actions à effectuer de façon sélective

Le flux logique des ordres peut être changé en utilisant un ordre conditionnel IF et des structures de
contrôle de boucle.
Des instructions peuvent être exécutées de façon sélective en fonction d’une condition, à l’aide de
l’instruction IF.
IF condition THEN
statements ;
[ELSIF condition THEN
statements ; ]
[ELSE
statements ; ]
END IF ;
condition est une variable booléenne ou une expression booléenne associée à une séquence d'ordres
qui sont exécutés seulement si le résultat de l'expression ou la variable est vrai.
THEN est une clause qui associe la condition qui la précède avec la séquence d'ordres qui la
suit. statements : les instructions peuvent être des ordres SQL et PL/SQL.
ELSIF est une clause suivie d'une condition. La clause ELSIF est utilisée si la condition précédente
est fausse.
13
 ESLE est une clause suivie d'une séquence d'ordres. La clause est utilisée si toutes les
conditions qui la précèdent sont fausses.
Il existe trois formes d'ordre IF :
- IF-THEN-END IF
- IF-THEN-ELSE-END IF
- IF-THEN-ELSIF-END IF
La boucle IF-THEN-END IF
IF-THEN-END IF est l'ordre IF simple qui permet d'effectuer des actions sous certaines conditions.

IF condition THEN instructions ;

Si la condition booléenne est vraie, la séquence d'ordres associée est exécutée. Si la condition
booléenne est fausse ou nulle, la séquence d'ordre associée n'est pas exécutée.
La boucle IF peut contenir d'autres boucles IF, par exemple :
IF condition1 THEN
IF condition2 THEN
IF condition3 THEN
...
END IF; END IF; END IF;
...
...
La boucle IF-THEN-ELSE-END IF
Cette boucle possède une clause ELSE qui permet d'exécuter une séquence d'ordres spécifique si la
condition de la boucle est fausse ou nulle.
IF condition THEN
statements1 ;
ELSE END IF ;
Statements2 ;
Il ne peut y avoir qu'une seule clause ELSE
Si la condition booléenne est vrai, la séquence d'ordres associée au IF est exécutée. Si la condition
booléenne est fausse ou nulle, la séquence d'ordre associée à la clause ELSE est exécutée.
Tout comme les ordres associés à la clause IF, les ordres associés à la clause ELSE peuvent contenir
des ordres IF imbriqués
La boucle IF-THEN-ELSIF-END IF
Cette boucle possède une clause ELSIF qui est utilisée pour faciliter l'écriture, en effet une clause
ELSIF et équivalente à un ordre IF imbriquée.
Une instruction IF peut contenir plusieurs clauses ELSIF mais qu'une seule clause ELSE.
La syntaxe de l’instruction IF est dictée par deux règles :
- le mot clé ELSIF représente un seul mot et le mot clé END IF est composé de deux
mots,
- l’instruction IF peut comporter plusieurs clauses ELSIF mais uniquement une seule
clause ELSE.
Remarque : l'ordre GOTO p19-3
Les conditions booléennes
Les conditions booléennes peuvent être simples ou complexes.

14
 Une condition booléenne simple est la combinaison d'expressions avec un opérateur de
comparaison.
Une condition booléenne complexe est la combinaison de plusieurs conditions simples avec des
opérateurs logiques tels que AND, OR et NOT.

AND TRUE FALSE NULL

TRUE TRUE FALSE NULL

FALSE FALSE FALSE FALSE

NULL NULL FALSE NULL

v_result := (v_tag1 OR v_tag2)

OR TRUE FALSE NULL

TRUE TRUE TRUE TRUE

FALSE TRUE FALSE NULL

NULL TRUE NULL NULL

v_result := (NOT v_tag1) L’opérateur NOT opère sur une condition unique

NOT

TRUE FALSE

FALSE TRUE

NULL NOT
NULL
Les structures des boucles : le contrôle itératif

La boucle élémentaire LOOP

Les instructions de contrôle itératif sont utilisées pour exécuter plusieurs fois une instruction ou une
séquence d’instructions.
La boucle élémentaire est constituée d’un ensemble d’instructions incluses entre les délimiteurs
LOOP et END LOOP. Ces instructions sont exécutées de façon répétée.
LOOP
statement1 ;
statement2 ;
…
statementN ;
END LOOP ;

15
 A chaque fois que le flux de l’exécution rencontre l’instruction END LOOP, le contrôle est renvoyé
à la première instruction de la boucle. Sous cette forme, la boucle élémentaire est infinie.
L’instruction EXIT permet de sortir de la boucle. L'instruction EXIT peut être utilisée en tant
qu’action dans une instruction IF, ou comme instruction autonome dans la boucle.
EXIT en tant qu'action dans la boucle EXIT en tant qu'instruction autonome
dans une instruction IF
LOOP LOOP
statement1 ; statement1 ;
statement2 ;
statement2 ; …
… statementN ;
statementN ; EXIT [WHEN condition] ;
IF condition THEN EXIT ; END LOOP ;
END LOOP ;

Dans le cas où l'instruction EXIT est utilisée comme une instruction autonome, la condition de la
clause WHEN doit être une variable booléenne ou une expression retournant une valeur booléenne.
Une boucle LOOP peut contenir plusieurs conditions de sortie.
La boucle FOR..LOOP
La boucle FOR est un mécanisme permettant d’exécuter un ensemble d’instructions un certain
nombre de fois dans une boucle.
La boucle FOR..LOOP a la même structure générale que la boucle basique LOOP. FOR..LOOP
possède, en plus, un ordre de contrôle placé avant le mot clé LOOP qui détermine le nombre
d'itération que PL/SQL doit effectuer.
FOR index IN [REVERSE] lower_limit..higher_limit
LOOP
statements ;
END LOOP ;
REVERSE déclenche une décrémentation (au lieu d'une incrémentation) du compteur (index) de 1
à chaque itération de la boucle jusqu'à ce que la limite inférieure soit atteinte.
Le compteur (index) est déclaré, initialisé et incrémenté (ou décrémenté) implicitement. Lorsque le
contrôle entre dans la boucle, les limites inférieures (lower_limit) et supérieure (lower_limit) sont
utilisées pour déterminer le nombre d’exécutions de la boucle.
Si la valeur de la limite supérieure est inférieure à la valeur de la limite inférieure, la boucle ne
s’exécute pas.
Les règles à respecter concernant l’utilisation de la boucle FOR :
- Ne faire référence à l’index qu’à l’intérieur de la boucle, car il n’est pas défini en dehors de
celle-ci.
- Les références à la valeur existante d’un index doivent être effectuées dans une expression.
La valeur précédente d’un index ne peut pas être référencée.
16
 - La référence à l’index ne peut pas être une cible d’affectation.
index := value ;  code non valide

La boucle WHILE..LOOP
La boucle WHILE exécute des instructions tant que sa condition est vraie.
WHILE condition

LOOP
statement1 ; statement2 ;
…
statementN ;
END LOOP ;
La condition est évaluée au démarrage de chaque itération.
La boucle se termine lorsque la condition est fausse. Si la condition est fausse au démarrage de la
première itération, aucune itération n’a lieu et le contrôle sort de la boucle.
Si la condition est nulle, la séquence d'instructions de la boucle n'est pas exécutée et le contrôle
passe à l'ordre suivant : l'instruction END LOOP.
La boucle WHILE peut posséder un compteur (un index) explicite.
La condition de la boucle WHILE peut être altérée par les instructions de la boucle.
Les boucles imbriquées
Une boucle imbriquée est une boucle intégrée dans une autre. La boucle contenant une autre boucle
est appelée boucle externe. La boucle imbriquée est appelée boucle interne.
Les boucles peuvent être imbriquées à plusieurs niveaux. Les boucles FOR peuvent être imbriquées
dans des boucles WHILE et inversement.
La fin d’une boucle imbriquée ne provoque pas l’arrêt de la boucle externe, sauf si une exception
est levée. Les étiquettes permettent de sortir d’une boucle externe en fonction de la valeur d’une
boucle interne.
Une étiquette est un identifiant déclaré qui désigne de façon facultative une instruction ou un bloc
vers lequel le contrôle doit être transféré.
<<outer>>
LOOP
…
LOOP
…
EXIT outer WHEN …
END LOOP ;
…
END LOOP outer ;
L'instruction EXIT provoque la sortie de la boucle outer, donc des deux boucles à la fois.
La précision d'un label dans la clause END LOOP est facultative et est utilisée pour clarifier le
code.
Section 3 Interaction avec la base de données
Extraction de données

17
Extraire des données avec l'ordre SELECT…INTO
Pour traiter les données stockées dans une table de la base de données, les données doivent d'abord
être extraites de la table et ensuite placées dans des variables PL/SQL. Cette opération peut être
effectuée facilement à l’aide de l’instruction SELECT..INTO. Cette instruction place les valeurs
issues de l'ordre SELECT dans des variables.
SELECT select_list
INTO { variable_name [variable_name,...] | record_name }
FROM table_list
[WHERE condition] ;
select_list spécifie la liste des colonnes à extraire d’une table de base de données. Elle peut contenir
des expressions SQL, des fonctions de ligne ou des fonctions de groupes. variable_name est une
variable scalaire destine à stocker une valeur récupérée par la requête. Les variables booléennes ne
sont pas admises. record_name est un enregistrement destiné à stocker toutes les valeurs récupérées
par la requête. table_list spécifie la liste des tables intervenant dans la requête. condition est la ou
les conditions de la requête qui peuvent être composées de noms de colonnes, d'expressions, de
constantes, d'opérateurs de comparaison, des variables et constantes PL/SQL.
La requête ne doit retourner qu'une seule ligne. Si elle ne retourne aucune ligne ou plus d'une ligne,
alors une erreur est générée.
En PL/SQL, la clause INTO est obligatoire dans l’instruction SELECT. La clause INTO est requise
pour le stockage des valeurs extraites dans des variables scalaires (variable_name) ou dans un
enregistrement PL/SQL (record_name).
En plus de son usage habituel, la clause WHERE peut être aussi utilisée pour spécifier des variables
d’entrée, des constantes, des valeurs littérales ou des expressions PL/SQL.
Afin d’éviter des erreurs de syntaxe et les ambiguïtés, certaines règles doivent être respectées lors de
l’utilisation de l'ordre SELECT..INTO :
- Les colonnes de la base de données et les identifiants, tels que les variables, doivent avoir des
noms différents.
- Le nombre de variable dans la clause INTO doit être identique au nombre de colonnes
sélectionnées dans la clause SELECT. Leurs positions doivent correspondre.
- Le type de données des identifiants doit correspondre à celui des colonnes. Dans ce cas, l'attribut
%TYPE peut être utile pour assurer la compatibilité des types de données.
Pour extraire toutes les colonnes d’une ligne appartenant à une table, il faut utiliser un
enregistrement PL/SQL dans la clause INTO.
Exceptions engendrées par des instructions SELECT..INTO
Les erreurs d’exécution dues à des erreurs de codage interrompent le traitement normal. Une erreur
provoquant l’arrêt d’un bloc PL/SQL est appelée une exception.
Une exception peut également être produite lors de l’extraction de données d’une table de base de
données à l’aide de l’instruction SELECT..INTO. L’instruction SELECT ne doit extraire qu'une
seule ligne, sinon une exception se produit.
Les deux exceptions SELECT pouvant être produites sont :

TOO_MANY_ROW Cette exception se produit lorsque l’instruction SELECT retourne

S plus d’une ligne. Le serveur Oracle attribue le numéro d’erreur 1422

18
 à cette exception.

Cette exception se produit lorsque l’instruction SELECT ne retourne

NO_DATA_FOUND aucune ligne. Le serveur Oracle attribue le numéro d’erreur +1403 à
cette exception.

Les exceptions produites peuvent être traitées à l’aide de routines de traitements d’exceptions.
Manipulation des données

Insertion de données
L’instruction INSERT est une commande du langage de manipulation des données. Elle est utilisée
pour ajouter de nouvelles lignes dans une table.

INSERT INTO table_name [(column1, column2, ...)]

VALUES (variable1, variable2, ...);

L'instruction INSERT a le même fonctionnement qu’en SQL.

Lors de l’insertion de données dans toutes les colonnes de la ligne, il n’est pas nécessaire de
préciser le nom des colonnes.
L'instruction INSERT peut utiliser des fonctions SQL, peut générer des valeurs de clé primaire en
utilisant des séquences dans la base de données, utiliser des variables définies dans le bloc PL/SQL,
ajouter des valeurs de colonne par défaut
Mise à jour des données
L’instruction UPDATE modifie les données existantes de la table. Il s’agit d’une instruction du
langage de manipulation des données (DML).

UPDATE table_name
SET colonne = variable [, colonne2 = variable2…]
[WHERE condition] ;
Suppression de données
L’instruction DELETE supprime des lignes dans une table.
DELETE FROM table_name
[WHERE condition] ;
Si la clause WHERE est omise, toutes les lignes de la table sont supprimées.

Section 4 Transaction
Gestion Des Transactions

Validation des transactions en cours

Toutes les modifications ou transactions en cours apportées aux enregistrements de bases de
données sont temporaires, et ne sont pas écrites immédiatement dans la base de données. Ces
modifications sont stockées dans une zone de mémoire appelée database buffer cache.

19
 La commande SQL COMMIT sert valider les modifications en cours apportées aux données de la
base. La commande SQLCOMMIT confirme la transaction en cours en la rendant permanente dans
la base de données.
COMMIT [WORK] ;
Des commandes explicites de verrouillage, telles LOCK TABLE et SELECT..FOR UPDATE
(cf…), peuvent être utilisées dans un bloc. Dans ce cas, le verrouillage prend effet jusqu'à la fin de
la transaction. (Attention, un bloc PL/SQL n'implique pas nécessairement une transaction)
Annulation des modifications en attente
La commande ROLLBACK permet d’annuler les modifications en attente d'être validées. Grâce à
cette commande, les modifications stockées dans la zone de mémoire database buffer cache sont
annulées avant la mise à jour de la table.
ROLLBACK [WORK] ;
Contrôle des points de transaction
La commande SAVEPOINT associée à la commande ROLLBACK permet d’annuler les
modifications en attente à partir d’un point donné.
Elle est utilisée pour créer un marqueur dans la transaction afin d’enregistrer les modifications
jusqu’à un point donné. La commande ROLLBACK est utilisée ultérieurement pour faire référence
au marqueur afin d’annuler une partie de la transaction.
SAVEPOINT marqueur ;
ROLLBACK TO SAVEPOINT marqueur ;
Section 5 Codage d’un sous-programme PL/SQL
Structure d’un bloc PL/SQL anonyme

Un bloc anonyme est un bloc ne possédant pas de noms. Ces blocs sont déclarés à l’endroit où ils vont
être exécutés dans une application. Ils sont passés au moteur PL/SQL lors de l’exécution du
programme.
[DECLARE]
[<section déclarative optionnelle>]
BEGIN
<section exécutable obligatoire>
[EXCEPTION]
<section de traitement des exceptions optionnelle>]
END;
Les mots clés DECLARE, BEGIN et EXCEPTION ne sont pas suivis d’un point virgule, seul END et
les autres ordres PL/SQL nécessitent un point virgule.
Structure d’un sous-programme PL/SQL

Un sous programme PL/SQL est un block nommé qui peut prendre des paramètres et être invoqué
dans d’autres blocs. Il existe deux types de sous programmes : les procédures et les fonctions.
Header
IS|AS
[<section déclarative optionnelle>]
BEGIN
<section exécutable obligatoire>
[EXCEPTION]

20
 <section de traitement des exceptions optionnelle>]
END;
La section Header détermine la manière dont le sous-programme va être appelé ou invoquée. Cette
section détermine également le type du sous-programme (procédure ou fonction), la liste des
paramètres si il y en a, la clause RETURN qui s’applique uniquement aux fonctions.
Le mot clé IS est obligatoire. Il ne faut pas utiliser le mot clé DECLARE car la section déclarative se
situe entre le IS et le BEGIN.
Pour le reste du code, il se comporte de la même manière que pour les blocs PL/SQL anonymes.
Avantages des sous-programmes

Les procédures et fonctions stockées ont des avantages en plus du développement modulaire des
applications. Les sous programmes permettent d’améliorer :
• la maintenance
• l’intégrité et la sécurité des données
• les performances
Les environnements de développement
SQL*Plus et Procedure Builder

Le PL/SQL n’est pas à proprement parlé un produit Oracle. C’est une technologie utilisée par le
serveur Oracle et par certains outils de développement Oracle, les blocs de PL/SQL sont passés et
traités par un moteur PL/SQL. Ce moteur peut être inclus dans l’outil de développement ou dans le
serveur Oracle.
Les deux principaux outils de développement sont SQL*Plus et Procedure Builder.
SQL*Plus utilise le moteur PL/SQL du serveur Oracle alors que Procedure Builder utilise le moteur
PL/SQL de l’outil client ou le moteur du serveur Oracle.
Développer des fonctions et procédures avec SQL*Plus

Il y a deux moyens pour écrire des blocs PL/SQL dans SQL*Plus. On peut les stocker dans le buffer
SQL*Plus et ensuite l’exécuter à partir de SQL*Plus ou bien les stocker dans un script SQL*Plus et
ensuite exécuter le fichier grâce à la commande EXECUTE.
Développer en utilisant Oracle Procedure Builder

Procedure Builder est un outil que l’on peut utiliser pour créer, exécuter et débugger des programmes
PL/SQL utilisés dans vos applications ou sur le serveur Oracle par le biais de son interface graphique.
L’environnement de développement Procedure Builder possède un éditeur intégré avec lequel il est
possible de créer et d’éditer des sous programmes. Il est possible compiler, tester et débugger son
code grâce à cet outil.
Appel de fonctions et de procédures
Les procédures et fonctions stockées peuvent être appelées depuis plusieurs environnements :
SQL*Plus : Oracle Developer, Oracle Discoverer, WebDB , une autre procédure stockée et de
nombreux outils Oracle et applications de précompilation.
Pour lancer une procédure ou fonction depuis SQL*Plus il faut utiliser la commande EXECUTE
suivie du nom du fichier dans lequel elle est stockée. Avec Oracle discoverer et Oracle Developer il
suffit de spécifier le nom du fichier script.
Pour exécuter une procédure à l’intérieur d’une autre il faut simplement donner le nom de la
procédure au moment voulu.

21
Les sous programmes
Déclarer des sous-programmes

Un sous programme peut être déclaré dans n’importe quel bloc PL/SQL. C’est une alternative à la
création de procédures à usage unique pour les appeler depuis d’autres procédures.
Le sous programme doit être déclaré dans la section déclarative du bloc et doit être le dernier élément
de cette section, après tous les autres éléments du programme. Si une variable est déclarée après la fin
du sous programme cela créera une erreur de compilation.
Invoquer une procédure depuis un bloc anonyme

Les procédures peuvent être appelées depuis n’importe quel outil ou langage prenant en compte le
PL/SQL. Pour appeler une procédure depuis un bloc anonyme il faut indiquer son nom, en passant les
paramètres éventuels entre parenthèses, suivi d’un point virgule.
Les procédures peuvent être également appelées à partir de procédures stockées. Pour ce faire, il faut
utiliser le nom de la procédure comme pour l’appel à partir de blocs anonymes.
CREATION DE FONCTIONS
Les fonctions
Aperçu des fonctions stockées

Une fonction stockée est un bloc PL/SQL nommé pouvant accepter des paramètres et être appelée de
la même façon que les procédures. Généralement, on utilise une fonction pour calculer une valeur.
Les procédures et les fonctions possèdent une structure semblable sauf qu’une fonction doit retourner
une valeur à l’environnement appelant.
Comme les procédures, les fonctions sont composées de quatre parties : un en-tête, une section
déclarative, une partie exécutable et une partie optionnelle de gestion d’erreur. Une fonction doit avoir
une clause RETURN dans l’en-tête et au moins un RETURN dans la partie exécutable.
Les fonctions facilitent la réutilisation et la maintenance. Une fois validée, les fonctions sont
stockées dans la base de données en tant qu’objet de base de données et peuvent ainsi être réutilisées
dans de nombreuses applications.
Syntaxe pour la création de fonctions

Pour créer une fonction, on utilise la commande CREATE FUNCTION, dans laquelle on peut
spécifier une liste de paramètres. Dans cette commande on doit définir la valeur qui sera retournée à
l’environnement appelant et définir les actions effectuées par le bloc PL/SQL standard.
CREATE [OR REPLACE] FUNCTION function_name ( parameter1 [ mode1] datatype1,
parameter2 [ mode2] datatype2,
. . .)
RETURN datatype
IS|AS
PL/SQL Block;

Datatype Type de donnée du paramètre RETURN Type de donnée de la valeur RETURN qui doit
être renvoyée par la datatype fonction
PL/SQL Corps de la procédure définissant les actions effectuées par la
Block fonction

22
L’option REPLACE indique que si la fonction existe déjà, elle sera remplacée par la nouvelle version
crée par la requête.
Le type de donnée du RETURN ne doit avoir de taille spécifiée.
Le bloc PL/SQL commence soit par un BEGIN soit par une section de déclaration de variables locales
et se tremine par END ou END function_name. Il doit obligatoirement y avoir au moins une
expression RETURN (variable). Il est impossible de faire référence à des variables hôtes ou à des
variables de substitution dans le bloc PL/SQL d’une fonction stockée.
Les fonctions dans SQL*Plus
Création de fonctions stockées

Pour créer une fonction stockée à partir de SQL*Plus on tape l’expression CREATE FUNCTION
dans un éditeur de texte, puis on sauvegarde ce fichier en tant que fichier script (*.sql). Ce fichier
script doit ensuite être exécuté dans SQL*Plus afin de le compiler en p-code. Si la compilation
produit des erreurs, on utilise la commande SHOW ERRORS pour les corriger. Une fois la
compilation effectuée sans erreurs, on appelle la fonction depuis un environnement Oracle Server.
L’exécution de la commande CREATE FUNCTION stocke le code source dans le dictionnaire de
données même si la fonction contient des erreurs de compilation. Il faut donc supprimer la fonction
(DROP) ou bien utiliser la syntaxe OR REPLACE si l’on veut effectuer des changements dans une
fonction.
Exécuter des fonctions
Les fonctions sont appelées à l’intérieur d’expression PL/SQL. Pour que la fonction s’exécute
convenablement il faut créer une variable hôte pour y stocker la valeur retournée. Lors de l’exécution,
la variable hôte est initialisée avec la valeur renvoyée par le RETURN.
Une fonction peut accepter plusieurs paramètres IN mais elle ne doit retourner qu’une seule valeur.
Emplacements d’où appeler les fonctions
Les fonctions PL/SQL définies par l’utilisateur peuvent être appelées depuis toute expression SQL
dans laquelle on peut utiliser une fonction prédéfinie.
C'est-à-dire que l’on peut utiliser une fonciton PL/SQL dans la liste d’un ordre SELECT, dans les
conditions des clauses WHERE et HAVING, dans les clauses CONNECT BY, START WITH,
ORDER BY et GROUP BY, dans la clause VALUES d’un ordre INSERT et dans la clause SET d’un
ordre UPDATE.
Supprimer des fonctions
Supprimer des fonctions serveurs

Lorsqu’une fonction stockée n’est plus utilisée, on peut la supprimer en utilisant un ordre SQL dans
SQL*Plus ou en utilisant le panneau de l’interpréteur Procedure Builder pour faire un DROP.
Pour supprimer une fonction côté serveur sous SQL*Plus on utilise la commande DROP FUNCTION.
DROP FUNCTION function_name
Pour supprimer une fonction stockée avec Procedure Builder il faut tout d’abord se connecter à la
base de données. On développe ensuite le nœud Database Objects, puis le schéma du propriétaire de
la fonction. On sélectionne la fonction que l’on souhaite supprimer puis on clique sur Drop dans
l’explorateur d’objet. On doit ensuite confirmer la suppression dans la fenêtre d’avertissement qui
apparaît.
Supprimer des fonctions clientes

23
Pour supprimer une fonction côté client on utilise Procedure Builder. Pour cela on développe le nœud
Program Units puis on sélectionne la fonction que l’on veut supprimer. On clique ensuite sur Delete
dans l’explorateur d’objets en confirmant la suppression dans la boîte de dialogue qui apparaît.
Si le code source de la fonction a été exporté dans un fichier texte et que l’on veut l’effacer du client il
faut utiliser les fonctionnalités du système d’exploitation.
Récapitulatif
Les procédures sont créées pour stocker une série d’actions à exécuter ultérieurement. Une procédure
peut accepter ou non des paramètres, qui ne sont pas limités en nombre et peuvent être transférés du et
vers l’environnement appelant. Une procédure ne retourne pas nécessairement une valeur.
Les fonctions sont créées pour calculer une valeur, elles doivent retourner une valeur à
l’environnement appelant. Une fonction peut accepter ou non des paramètres qui sont transmis de
l’environnement. Une fonction ne peut retourner qu’une seule valeur et ne peut pas accepter de
paramètre OUT ou IN OUT.
Cependant si l’on en déclare il ne se produira pas d’erreurs de compilation mais il est conseillé de ne
jamais en utiliser.
Comparaison entre procédures et fonctions

Procédure Fonction
S’exécute comme une requête PL/SQL Est appelé dans une expression
Pas de type de donnée RETURN Doit avoir un type de donnée RETURN
Peut retourner une, aucune ou plusieurs Ne retourne qu’une seule valeur
valeurs
Une procédure contenant un seul paramètre OUT peut être réécrite en tant que fonction en utilisant le
paramètre OUT pour la valeur retournée.
CREATION DE PACKAGES
Les packages
Aperçu des packages

Les packages sont des groupes comprenant des types, des éléments et des sous-programmes PL/SQL
logiquement associés. Par exemple un package Ressources Humaines pourrait contenir les procédures
embauche et licenciement, les fonctions commission et bonus et les variables d’exemption de taxe.
Généralement un package est constitué de deux parties stockées séparément dans la base de données :
la spécification et le corps.
La spécification est l’interface pour les applications. Elle déclare les types, les variables, les
constantes, les exceptions, les curseurs et les sous-programmes que l’on peut utiliser dans le
package. Le corps définit les curseurs et les sous-programmes et ce qui a été définit dans la
spécification.
Le package lui-même ne peut pas être appelé, recevoir de paramètre ou être imbriqué. Cependant un
package a le même format qu’un sous-programme. Une fois écrit et compilé, le contenu peut être
partagé par plusieurs applications.
Quand on appelle un élément de package pour la première fois, tout le package est chargé en
mémoire. Par conséquent les appels suivant à l’élément en question ne requièrent pas d’écriture ou de
lecture sur le disque.

24
Les composantes d’un packages

Sur le schéma on distingue les zones de déclarations : pour les variables publiques (1), les procédures
publiques (2), les procédures privées (3), les variables privées spécifiques au package (4) et les
variables locales spécifiques à la procédure (5).
Le package se crée en deux parties : on définit d’abord la spécification et ensuite on crée le corps du
package. Les éléments publics d’un package sont ceux que l’on déclare dans la spécification et qui
sont définit dans le corps. Les éléments privés d’un package sont ceux qui sont définis uniquement
dans le corps.
Le Serveur Oracle stocke la spécification et le corps du package séparément dans la base de données,
ce qui permet de changer la définition d’un élément du corps du package sans que Oracle ait à
désactiver d’autres objets du schéma qui font appel ou font référence à cet élément.
Référencer les objets d’un package

Les variables définies dans le package n’ont pas toutes la même visibilité c'est-à-dire que selon
l’endroit où l’on se trouve on ne pourra pas utiliser certaines variables.
Les éléments d’un package peuvent avoir une visibilité locale ou globale.
Créer des packages
Développement d’un package

Pour développer un package on choisit tout d’abord un environnement de développement : SQL*Plus

ou Procedure Builder.
On tape ensuite la syntaxe. Sous Procedure Builder on utilise l’éditeur d’unités de programmes et sous
SQL*Plus on utilise un éditeur de texte puis on enregistre le code en tant que fichier script.
Enfin on compile le code du package. Le code source est compilé en p-code. Pour compiler le
package sous Procedure Builder il suffit de cliquer sur Save, sous SQL*Plus on lance le fichier script
créé. Une fois le code source compilé, il est stocké dans le dictionnaire de données.
Pour faciliter le développement ultérieur, il est conseillé de sauvegarder dans des fichiers textes
séparés le code du CREATE PACKAGE : un fichier pour la spécification et un pour le corps.
Une spécification de package peut exister sans qu’elle soit associée à un corps, mais le contraire n’est
pas possible. Le corps d’un package doit toujours être associé à une spécification.
Si l’on a incorporé dans le package le code d’une procédure existante, il est conseillé de supprimer la
procédure indépendante à l’aide de la commande DROP.
Création des spécifications du package

25
Pour créer la spécification d’un package on utilise la commande CREATE PACKAGE. Il faut
spécifier toutes les structures publiques dans la spécification du package. On peut spécifier l’option
REPLACE si la spécification du package existe déjà. Si nécessaire on initialise les variables avec une
constante ou une formule dans la spécification, sinon la variable est initialisée implicitement à NULL.

CREATE [OR REPLACE] PACKAGE package_name

IS|AS
public type and item declarations
subprogram specifications
END package_name;

Paramètre Description
Package_name Nom du package
Public type and item Déclare les variables, les constantes, les
declarations curseurs, les exceptions
Subprogram Déclare les sous-programmes PL/SQL
specifications

Déclaration d’éléments publics

Dans la spécification du package on déclare les variables publiques, les procédures publiques et les
fonctions publiques. Les fonctions et les procédures publiques sont des routines qui peuvent être
appelées à plusieurs reprises par d’autres éléments du même package, ou d’en dehors du package.
Pour déclarer les éléments publics on spécifie le type de l’élément suivi de son nom, dans la section
de spécification.

CREATE [OR REPLACE] PACKAGE package_name

IS|AS
TYPE name [parameter] END package_name;

Création du corps du package

Pour créer le corps du package on utilise la commande CREATE PACKAGE BODY. Dans le corps
du package on définit tous les éléments publics et privés du package. On peut spécifier l’option
REPLACE pour supprimer et remplacer une version existant déjà.

CREATE [OR REPLACE] PACKAGE BODY package_name

IS|AS
private type and item declarations
subprogram bodies
END package_name;

Paramètre Description

26
 Package_name Nom du package
Private type and item Déclaration des variables, constantes,
declarations curseurs, exceptions ou types
Subprogram bodies Définition des sous-programmes PL/SQL
publics et privés
L’ordre dans lequel les sous-programmes sont définis est très important. Il faut déclarer les
variables avant qu’une autre variable ou un sous-programme y fasse référence. Il faut déclarer ou
définir les sous-programmes privés avant de les appelés depuis d’autres sous-programmes. Le
plus souvent, toutes les variables et sous-programmes privés sont déclarés en premier dans le
corps du package et ensuite on définit les sous-programmes publics.
Directives pour développer des packages
Il faut essayer de faire des packages aussi généraux que possible afin de pouvoir les réutiliser dans des
applications futures. Il faut aussi éviter de créer des packages qui dupliquent des fonctions fournies
par Oracle. La spécification du package définit la structure de l’application, donc il faut toujours
définir la spécification, puis le corps du package.
La spécification du package ne doit contenir que les éléments devant être visible par les autres
utilisateurs du package. Ainsi les autres développeurs ne pourront pas faire mauvaise utilisation en
basant leur code sur des éléments non appropriés.
Pour réduire la nécessité de recompilation quand le code est changé il faut placér le plus petit nombre
possible d’éléments dans la spécification du package. Les changements dans le corps du package ne
nécessitent pas la recompilation des éléments dépendants, alors que les changements dans la
spécification du package nécessitent la recompilation de tous les sous-programmes stockés faisant
référence au package.
Manipuler les packages
Exécuter une procédure publique d’un package

Une procédure publique est déclarée dans la spécification du package et est définie dans le corps du
package. Par conséquent il est possible de l’appeler directement depuis l’environnement SQL*Plus.
Pour cela on utilise la commande EXECUTE en précisant le nom du package, de la procédure et les
arguments, s’il y a lieu d’en fournir.
SQL> EXECUTE package_name. procedure_name( parameters)
Invoquer des éléments de packages
Une fois le package stocké dans la base de données, il est possible de faire appel à un élément de
package depuis le package même ou bien en dehors du package. Cette caractéristique dépend du type
de l’élément : s’il est privé seul le premier cas est possible, s’il est public les deux cas sont possibles.
Lorsque l’on appelle une procédure ou une fonction à l’intérieur du même package, il n’est pas
nécessaire de préciser le nom du package.
Lorsque l’on appelle une procédure ou une fonction depuis l’extérieur d’un package il faut spécifier
le nom du sous-programme ainsi que le nom du package. Si le package se trouve dans un autre
schéma, il faut préciser le nom du schéma avant le nom du package. On peut également appeler un
package se trouvant sur une autre base de donnée. Pour cela on ajoute un arobase suivi du nom de la
base de données.
27
 Référencer une variable publique à partir d’une procédure autonome
Les variables publiques (globales) sont visibles hors du package, donc il est possible d’y faire
référence dans des procédures indépendantes. Pour cela on spécifie son nom ainsi que le nom du
package dont elle est issue.
Les procédures indépendantes peuvent faire appel à tous les types de donnés pouvant être déclarés
dans la spécification d’un package (variables, curseurs, constantes ou exceptions). A chaque fois il
faut préciser le nom du package en plus du nom de l’élément.
Supprimer des packages

Quand un package n’est plus utilisé on peut le supprimer en utilisant un ordre SQL dans SQL*Plus ou
dans Procedure Builder. Dans SQL*Plus on utilise la commande DROP PACKAGE BODY et DROP
PACKAGE.
DROP PACKAGE BODY package_name
DROP PACKAGE package_name
Dans Procedure Builder on clique sur DROP lorsque la procédure est sélectionnée dans l’explorateur
d’objets. Comme un package est composé de deux parties distinctes on peut choisir de supprimer tous
le package ou bien de supprimer seulement le corps et de garder la spécification du package. Il est
impossible de supprimer uniquement la spécification puisque on ne peut pas avoir de corps de
package non lié à une spécification.
Avantages des packages
L’utilisation de packages est une alternative à la création de fonctions et procédures indépendantes et
offre de nombreux avantages.
Cela apporte une grande modularité car on encapsule des structures de programmes logiquement
reliés dans un module nommé. Chaque package est facile à comprendre et la liaison entre les
packages est simple, claire et bien définie.
Les packages permettent de cacher des informations aux autres utilisateurs. On peut en effet décider si
un élément sera public (visible et accessible par tous) ou privé (caché et inaccessible hors du
package).

Section 6 Exceptions
GESTION DES EXCEPTIONS
Une exception est un identificateur en PL/SQL qui est levée durant l'exception.
Lorsqu'une exception survient dans la section des commandes exécutables, le contrôle de l'exécution
quitte immédiatement cette section et recherche dans la section de gestion des exceptions une
exception correspondant à l'erreur rencontrée.
Lever et traiter les exceptions
Il existe deux façons de lever une exception :
- Une erreur Oracle survient et l'exception associée est automatiquement levée. Par exemple,
si aucune ligne n'est retournée dans un ordre SELECT, l'erreur ORA-01403 survient, alors le
langage PL/SQL lève l'exception NO_DATA_FOUND.
- Le programmeur lève une exception explicitement en utilisant l'ordre RAISE dans un bloc.
L'exception levée doit être une exception définie par le développeur ou une exception
prédéfinie.
Il existe deux façons de traiter une exception :
- L'attraper (la capturer) avec un traitement ("handler").

28
 - La propager dans l'environnement.
Les types d'exception
Il existe trois types d'exception :
- Les erreurs du serveur Oracle prédéfinies
- Les erreurs du serveur Oracle non prédéfinies
- Les erreurs définies par le développeur
Note : Des applications avec des clients PL/SQL, tel que Oracle Developer Forms, possèdent leurs
propres exceptions.
Capturer les exceptions

Le développeur peut capturer n'importe quel erreur en incluant une routine correspondante dans la
section de gestion des exceptions d'un bloc PL/SQL. Chaque section de traitement (appelé
"handler") est constitué d'une clause WHEN qui spécifie une exception, suivie d'une séquence
d'ordres exécutée lorsque l'exception est levée.

Syntaxe :

EXCEPTION
WHEN exception1 [OR exception2...] THEN
statement1; statement2;
...
[WHEN exception3 [OR exception4...] THEN
statement1; statement2;
...]
[WHEN OTHERS THEN
statement1; statement2;
...]

Capturer des erreurs prédéfinies du serveur Oracle

Pour capturer une erreur prédéfinie par le serveur Oracle, son nom doit être référencé dans la routine
de traitement des exceptions.
Capturer des exceptions non prédéfinies du serveur Oracle
Pour capturer une exception non prédéfinie du serveur Oracle, il existe deux méthodes. La première
consiste à utiliser la clause OTHERS dans la section de gestion des exceptions. La deuxième permet
un traitement personnalisé de l'exception :
1. Déclarer l'exception dans la section déclarative.(L'exception déclarée est implicitement levée)
Syntaxe :
exception EXCEPTION;
exception est le nom de l'exception donné par le développeur.
Associer le nom de l'exception à un numéro d'erreur Oracle à l'aide du pragma (appelé aussi
pseudo-instruction) EXCEPTION_INIT dans la section déclarative. Ce pragma permet de référencer
n'importe quelle exception interne par un nom et d'y rattacher un traitement spécifique dans la
section de gestion des exceptions.

Syntaxe :

29
PRAGMA EXCEPTION_INIT(exception, error_number);

exception correspond à l'exception déclarée précédemment.

error-number est un numéro d'erreur standard du serveur Oracle.

Un pragma est une directive de compilateur, un pragma peut être vu comme une remarque entre
parenthèses faite au compilateur. Un pragma est traité au moment de la compilation et non de
l'exécution.
Le pragma EXCEPTION_INIT peut être déclaré dans la section déclarative d'un bloc PL/SQL
ou dans un package.
La déclaration du pragma doit apparaître quelque part après la déclaration de l'exception dans la
même section déclarative.

3. Référencer l'exception dans une routine de la section de gestion des exceptions. Syntaxe :

WHEN exception THEN

statement1; statement2;
...

exception correspond à l'exception déclarée et associée à un numéro d'erreur

précédemment.
statement correspondent aux ordres PL/SQL traitant l'exception.

Les fonctions pour capturer les exceptions

Lorsqu'une exception se produit, le code de l'erreur associé à l'exception et le message d'erreur peut
être récupéré avec deux fonctions :
SQLCODE retourne le numéro d'erreur Oracle d'une exception interne. La valeur retournée
peut être assignée à une variable de type NUMBER.
- SQLERRM retourne le message associé au numéro de l'erreur. La valeur retournée peut être
assignée à une variable de type chaîne de caractères.
En générale, SQLCODE retourne un nombre négatif.
Quelques valeurs particulières retournées par SQLCODE :
- Si SQLCODE retourne 0, cela signifie qu'aucune exception n'a été levée ("encountered").
- Si SQLCODE retourne 1, cela signifie que l'exception levée a été définie par l'utilisateur.
- Si SQLCODE retourne +100, cela signifie que l'exception levée est l'exception prédéfinie
NO_DATA_FOUND.
Le langage PL/SQL permet à l'utilisateur de définir ces propres exceptions. Les exceptions définies
par l'utilisateur doivent être :
1. déclarées dans la section déclarative d'un bloc PL/SQL.
Syntaxe :
exception EXCEPTION;

exception est le nom de l'exception donné par le développeur.

30
2. levées explicitement dans la section exécutable avec l'ordre RAISE. Syntaxe
:
RAISE exception;
exception est le nom de l'exception déclarée par le développeur.
référencées avec dans une routine de la section de gestion des exceptions. Syntaxe :
WHEN exception THEN statements; exception est le nom de l'exception déclarée et levée
explicitement précédemment.
La procédure RAISE_APPLICATION_ERROR
La procédure AISE_APPLICATION_ERROR permet de publier des messages d'erreur définis par
l'utilisateur depuis un bloc PL/SQL. Ainsi, il est possible d'annoncer des erreurs à une application et
d'éviter de retourner des exceptions non définies.
Syntaxe :
RAISE_APPLICATION_ERROR (error_number, message [,{TRUE|FALSE}]);
error_number est le numéro d'exception spécifié par le développeur qui doit se trouver
entre -20000 et -20999.
message est le message d'erreur associée à l'exception et spécifié par le
développeur. Il s'agit d'une chaîne de caractères avec une taille maximale
de 2048 octets.
TRUE | FALSE correspond à un paramètre booléen optionnel. (Si la valeur est
TRUE, l'erreur est placée sur la pile des erreurs précédentes. Si la
valeur est FALSE (valeur par défaut), l'erreur est remplace toutes
les erreurs précédentes).
La procédure RAISE_APPLICATION_ERROR peut être utilisée à deux emplacements différents :
- Dans la section exécutable Exemple :
...
BEGIN
...
DELETE FROM emp
WHERE mgr =
v_mgr; ...
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE_APPLICATION_ERROR (-20201, 'This is not a valid
manager');
END;
- Dans la section de gestion des exceptions
Une application ne peut appeler la procédure RAISE_APPLICATION_ERROR que depuis un bloc
PL/SQL (nommé ou non) exécutable. Quand elle est appelée, la procédure termine le bloc (ou
sousprogramme) et retourne un numéro d'erreur et un message définis par l'utilisateur à
31
 l'application. Ce numéro et ce message peuvent être attrapés comme une erreur du serveur Oracle.
L'application obtient une exception PL/SQL qui peut être traitée en utilisant les fonctions
SQLCODE et SQLERRM dans une routine OTHERS. L'application peut aussi utiliser le pragma
EXCEPTION_INIT pour récupérer les numéros d'erreur retournés par la procédure
RAISE_APPLICATION_ERRORS.
Note : La procédure RAISE_APPLICATION_ERROR appartient au package
DBMS_STANDARD livré par Oracle. Ce package fournit des "language facilities" pour aider une
application à interagir avec Oracle. Le package DBMS_STANDARD est une extension du package
STANDARD, donc il n'est pas nécessaire de référencer leurs procédures.
La propagation des exceptions

Quand un sous-bloc traite une exception, le sous-bloc se termine normalement, et le programme

reprend donc dans le bloc "père" immédiatement après l'ordre END du sous-bloc.
Cependant, si le moteur PL/SQL lève une exception qui ne possède pas de routine dans la section de
gestion des exceptions du bloc courant, alors l'exception est propagée successivement dans les blocs
"pères" jusqu'à trouver une routine. Si aucun des blocs ne capture l'exception, une exception non
traitée aboutit dans l'environnement hôte et le programme échoue.
Un des avantages de la propagation est que des ordres qui requièrent leurs propres traitements
d'exceptions peuvent être inclus dans des sous-blocs en laissant les traitements d'exception plus
généraux dans les blocs "pères".
Une exception déclarée dans un bloc est considérée comme local pour ce bloc et global pour tous les
sous-blocs.
Une exception ne peut pas être déclarée deux fois dans un même bloc, mais elle peut être déclarée
deux fois dans deux blocs différents. C'est l'exception locale qui prévaut sur l'exception globale.
Pour référencer l'exception globale, il faut utiliser des blocs labellisés :
block_label.exception ;

Section 7 Déclencheur
Les triggers de base de données
Il s’agit d’un bloc PL/SQL associé à une table de la base de données. Il est exécuté
automatiquement lors de la manipulation du contenu de la table à laquelle il est attaché. Le trigger
de base de données est disponible sur le serveur Oracle.
TRIGGER nom { BEFORE | AFTER } [FOR EACH ROW] [WHEN <condition>] BEGIN
<instructions>
[EXCEPTION]
<traitement des exceptions>
END ;
Les triggers d'application
Il s’agit d’un bloc PL/SQL associé à un événement d’application et exécuté automatiquement
lorsqu’un événement spécifié se produit. Le trigger d'application n'est disponible que dans les
composants de Oracle Developper.

32
Chapitre 4 Gestion de l’espace disque et des fichiers
Section 1 Apport d’Oracle entreprise manager
Oracle Enterprise Manager : C’est un outil important permettant, via une interface graphique,
d’administrer, de contrôler et de tuner une ou plusieurs bases de données localisées sur un ou
plusieurs serveurs.
Architecture d'OEM : Vue d'ensemble

Oracle Entreprise Manager fournit un outil graphique de configuration système pour administrer une
ou plusieurs bases de données.
OEM se présente sous la forme d’une architecture trois tiers, elle comprend :
• La console est un outil graphique, utilisés par les DBA pour administrer une ou plusieurs
bases de données à partir d’une même console.
• Les composants OMS forment le second tiers, les données de ces composants sont en effet
stockées dans le repository OEM. Le repository OEM est un jeu de tables dans la base de
données contenant les données système, les données applicatives et l’état des nœuds
administrés sur l’environnement Oracle.
• Les Noeuds constituent la troisième couche de l’architecture qu’un utilisateur va chercher à
administrer. Ces nœuds sont contrôlés par les « intelligent agents ». Un « intelligent agent »
est un process qui s’exécute sur le nœud distant du réseau et qui permet de l’administrer à
distance.
Services communs d'OEM

OEM comporte un ensemble de services permettant au DBA d’administrer les serveurs Oracle et leurs
bases de données.
Les principaux services fournis par les OMS sont les suivants :
Le service de taches panifiées (Job Service) ;
Le service de gestion des évènements (Event Service) ;
Le service de découverte (Discovery Service) ;
Le service de sécurité (Security Service) .
Configurer OEM

Lors de son installation, installateur universel lance l’assistant de configuration d’OEM, mais il est
également possible de le lancer à nouveau lors de la création d’un repository supplémentaire. Les
étapes se découpent comme suit :Création du repository OEM, Lancement du service OMS,
Lancement de la console OEM, Configuration de la sécurité, Travail sur une base de données.

Section 2 Gestion de l’espace

Hiérarchie de stockage d’une base de données
La base de données, premier composant dans la hiérarchie de stockage, est divisé logiquement en
tablespaces.
Le tablespace est le deuxième composant dans la hiérarchie de stockage. Il permet de regrouper des
structures logiques liées. Par exemple, les tablespaces peuvent regrouper tous les objets d’une
application pour simplifier certaines tâches d’administration.Chaque tablespace contient un ou
plusieurs fichiers de données.
Les fichiers de données sont les structures physiques qui stockent les données.

33
La somme des tailles des fichiers de données d’un tablespace correspond à la capacité de stockage de
tous les tablespaces. La somme des capacités de stockage de tous les tablespace d’une base de
données donne la capacité de stockage totale de cette base de données.
Un tablespace peut contenir un ou plusieurs segments.
Un segment correspond à l’espace utilisé par une structure logique, par exemple une table ou un
index. Lors de sa création, un segment contient au moins un extent.
Le quatrième composant de la hiérarchie de stockage est l’extent. Il s’agit d’un ensemble de blocs
contigus permettant de stocker un certain type d’information. Des extents sont ajoutés lorsqu’un
segment nécessite davantage d’espace.
Le dernier composant de la hiérarchie de stockage est le bloc Oracle. Il s’agit de la plus petite unité
d’entrée/sortie. Lorsque des données doivent être extraites du disque, le serveur Oracle utilise un ou
plusieurs blocs Oracle. La taille d’un bloc Oracle doit être un multiple de la taille d’un bloc du
système d’exploitation.
Un bloc de données correspond à un nombre spécifique d’octets d’espace de base de données
physique sur le disque. Lors de la création de chaque base de données Oracle, une taille de bloc de
données est définie.
Des segments sont créés dans la base de données pour stocker, extraire et gérer des données.
Un segment est un objet occupant de l’espace dans la base de données. Il est constitué d’un ou
plusieurs extents. Les différents types de segments sont les suivants :Table, Partition de table, Cluster,
Index, Table organisée en index ,Partition d'index, Segment undo, Segment temporaire, Segment
LOB, Table imbriquée et Segment de démarrage
Informations sur la structure de stockage
Interroger les vues du dictionnaire de données
Les relations entre les tablespaces, les fichiers de données, les segments et les extents utilisés et libres
peuvent être vus avec les dictionnaires de données.
Quand un tablespace est créé avec plus d’un fichier, une ligne est ajoutée à DBA_TABLESPACES.

Pour chaque fichier dans une base de donnée, une ligne est ajoutée dans DBA_DATA_FILES.

A ce stade, l’espace de chaque fichier de données, excluant leur entête, se montre comme un extent libre
dans DBA_FREE_SPACE.

Quand un segment est créé, une ligne apparaît dans DBA_SEGMENTS. L’espace alloué aux extents dans un
segment peu être vu de DBA_EXTENTS, tandis que DBA_FREE_SPACE montre les espaces libres dans un fichier
où les extents ont été créés pour le segment.

Tout les espaces de fichier (incluant les entêtes) doivent se retrouver dans DBA_FREE_SPACE ou dans
DBA_EXTENTS.

Recherche d’informations sur les segments

Le nombre courant d’extents et de blocs alloués à un segment peut être obtenu à l’aide de la vue de
dictionnaire de données DBA_SEGMENTS.

La vue DBA_SEGMENTS utilise un certain nombre de colonnes.

Elles peuvent être réparties en trois catégories :

les colonnes qui affichent des informations générales,

les colonnes qui affichent la taille,

34
les colonnes qui affichent les paramètres de stockage.

Les catégories et noms des colonnes sont les suivantes :

Colonnes de la vue DBA_SEGMENTS

Informations Taille Paramètres de stockage

OWNER INTIAL_EXTENT
NEXT_EXTENT MIN_EXTENT
SEGMENT_NAME EXTENTS BLOCKS MAX_EXTENT PCT_INCREASE
SEGMENT_TYPE
TABLESPACE_NAME

Affichage des informations sur les extents utilisés

La vue DBA_EXTENTS permet de vérifier l’espace alloué aux extents dans un segment donné.

La vue DBA_EXTENTS contient un certain nombre de colonnes. Celles-ci peuvent être réparties en deux
catégories :

les colonnes utilisées à des fins d’identification.

les colonnes affichant l’emplacement et la taille des extents.

Les catégories et noms des colonnes sont décrits ci-dessous :

Colonnes de la vue DBA_EXTENTS

Informations Taille

TABLESPACE_NAME

RELATIVE_FNO
OWNER
FILE_ID
SEGMENT_NAME
EXTENT_ID BLOCK_ID

BLOCKS

Recherche d’informations sur les extents libres

Pour pouvoir stocker les données, l'administrateur doit connaître la quantité d’espace libre dont il dispose
dans les tablespaces.

La vue DBA_FREE_SPACE permet de connaître la quantité d’espace libre dans chaque tablespace de la base de
données.

La vue DBA_FREE_SPACE utilise un certain nombre de colonnes pour indiquer l’emplacement des blocs libres
dans un tablespace :

TABLESPACE_NAME

RELATIVE_FNO

FILE_ID

35
BLOCK_ID

BLOCKS

Vérifier le nombre d’extents et de blocs libres dans chaque tablespace à l’aide de la vue DBA_FREE_SPACE.
Extraire les données des colonnes TABLESPACE_NAME,

COUNT(*) et SUM(BLOCKS). Classer ensuite l’affichage en fonction de la colonne TABLESPACE_NAME.

SQL> SELECT tablespace_name, count(*), SUM(blocks)

FROM dba_free_space

GROUP BY tablespace_name;

TABLESPACE_NAME EXTENTS BLOCKS

----------------------- ----------- -----------

ROLLBACK_DATA 7 2719

SYSTEM 12 2536 TEMPORARY_DATA 1 1023

USER_DATA 4 rows selected. 1 640

Cette requête a extrait les informations relatives aux blocs libres pour tous les tablespaces disponibles. Le
tablespace ROLLBACK_DATA contient 7 extents libres avec un total de 2719 blocs.

Section 3 Gestion des tablespaces

Caractéristiques d'un tablespace

La structure de stockage logique la plus importante d'une base de données est le tablespace.
• Un tablespace ne peut appartenir qu'à une seule base de données
• Un tablespace est constitué d'un ou plusieurs fichiers du système d'exploitation.
• Les tablespace peuvent être mis offline lorsque la base de données fonctionne. Cette
fonctionnalité permet à l'administrateur de contrôler les données sans arrêter la base de
données.
• Tous les tablespaces, à l'exception du tablespace SYSTEM ou d'un tablespace avec un
undo segment actif, peuvent être mis offline. Dans ce cas, la base de données continue de
fonctionner. L'administrateur peut ainsi assurer la gestion des données sans que la base de
données ne soit indisponible.
• L'état d'un tablespace peut être basculé entre lecture écriture et lecture seule. Cette
fonctionnalité permet d'empêcher les utilisateurs de modifier des données stockées et
inversement.

Utilisations d'un tablespace

Le tablespace présente plusieurs utilisations possibles permettant la gestion efficace de l'espace
disque.
• Aider les serveurs Oracle pour le contrôle de l'allocation de l'espace et l'attribution de
quotas d'espace aux utilisateurs.
• Contrôler la disponibilité des données. Ce contrôle est effectué par la mise online ou
offline des tablespaces individuels.

36
 • Améliorer les performances E/S et réduire les contentions E/S grâce à la répartition du
stockage des données sur plusieurs périphériques.
• Utiliser lors des opérations de sauvegardes et de restaurations partielles.
• Utiliser pour stocker de grandes quantités de données statiques sur des périphériques en
lecture seule.

Créer des Tablespaces

Types de tablespaces

Lorsque l'administrateur crée une base de données, un tablespace appelé SYSTEM est créé par défaut.
Tous les autres tablespaces, appelés tablespaces non-SYSTEM, sont créés par l'administrateur de la
base de données.
L'administrateur créé un tablespace non-SYSTEM pour gérer facilement la base de données et
permettre aux utilisateurs de l'utiliser de façon efficace.
Le tablespace SYSTEM est indispensable pour le bon fonctionnement de toute base de données. Le
tablespace non-SYSTEM n'est pas obligatoire.
Le tablespace SYSTEM contient les informations du dictionnaire de données, les définitions des
procédures stockées, des packages et des triggers base de données, les undo segments SYSTEM.
D'autre part, les tablespaces non-SYSTEM peuvent contenir les segments de données, les segments
d'index, les segments temporaires et les undo segments. Ils séparent aussi les données dynamiques et
statiques
Le tablespace SYSTEM contient le rollback segment SYSTEM, tandis qu'un tablespace nonSYSTEM
peut contenir tout autre rollback segment.
Il n'est pas souhaitable de stocker les données utilisateur dans le tablespace SYSTEM. Si le tablespace
SYSTEM contient des données utilisateur, vous ne pouvez pas procéder à des sauvegardes offline des
données sans arrêter la base de données.

Création d’un tablespace

L'administrateur est responsable de la gestion des données des bases de données. Un moyen efficace
de gestion des données consiste à créer des tablespaces pour différents groupes d'utilisateurs, en
créant, par exemple, un tablespace marketing pour le personnel du service marketing.
Syntaxe de création d'un tablespace :
CREATE TABLESPACE tablespace [DATAFILE clause]
[MINIMUM EXTENT integer[K|M]]
[BLOCKSIZE integer [K]]
[LOGGING|NOLOGGING]
[DEFAULT storage_clause ]
[ONLINE|OFFLINE]
[PERMANENT|TEMPORARY]
• DATAFILE spécifie le ou les fichiers de données liés au tablespace. M spécifie la taille en Mo
ou Kbits.
• LOGGING option par défaut qui spécifie que toutes les tables, indexes et partitions dans le
tablespace génèrent des infos de redo log.
• DEFAULT définit les paramètres de stockage par défaut pour tous les objets créés dans le
tablespace.

37
 • OFFLINE rend le tablespace indisponible immédiatement après la création.
• PERMANENT spécifie que le tablespace peut être utilisé pour contenir des objets permanents.
• TEMPORARY cette clause est utilisée pour les objets temporaires.
storage_clause := (
[INITIAL integer [K|M]]
[NEXT integer [K|M]]
[MINEXTENTS integer ]
[MAXENTENTS {integer | UNLIMITED}]
[PCTINCREASE integer ])
Lors de la création de tablespaces, le nombre maximal de tablespaces pouvant être affectés à chaque
base de données est de 64 000 et le nombre maximal de fichiers de données pouvant être affectés à
chaque tablespace est de 1 023.
Gestion de l’espace dans les tablespaces

Les tablespaces peuvent être gérés avec les tables du dictionnaire de données ou des tables binaires
d’allocations (bitmaps). L’une de ces méthodes doit être choisie lorsque l’on crée un tablespace et ne
pourra être changée par la suite. Locally Managed Tablespaces
Un tablespace qui gère ses propres extents garde un bitmap dans chaque fichier de données pour
garder une trace des blocs libres ou utilisés dans ces fichiers de données. Chaque bitmap correspond à
un bloc ou un groupe de blocs. Lorsqu’un extent est alloué ou prêt à être réutilisé, le serveur Oracle
change la valeur du bitmap pour mettre à jour le nouveau statut des blocs.
Locally Managed tablespaces

L’option LOCAL de la clause EXTENT MANAGEMENT spécifie qu’un tablespace est géré
localement. Cette option est par défaut.
extent_management_clause :==
[ EXTENT MANAGEMENT
[ DICTIONARY | LOCAL
[ AUTOALLOCATE | UNIFORM [SIZE integer[K|M]] ] ] ]
• DICTIONARY signifie que le tablespace est géré grâce aux tables du dictionnaire.
• LOCAL signifie que le tablespace est géré localement avec un bitmap. Si c’est clause est
utilisé, on ne peut utiliser DEFAULT storage_clause, MINIMUM EXTENT, ou
TEMPORARY.
• AUTOALLOCATE est l’option par défaut. Les utilisateurs ne peuvent spécifier une taille
d’extent.
• UNIFORM signifie que le tablespace est géré avec des extents de tailles uniformes de SIZE
bytes.
CREATE TABLESPACE userdata
DATAFILE ‘u01/oradate/userdata01.dbf’ SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256k;
Les avantages des tablespaces gérés localement sont les suivants :
• Pas de contention en mise a jour au niveau du dictionnaire.
• Par conséquence pas d'utilisation de Rollback segment pour ces transactions.
• Pas de soucis de gestion de l'espace (calcul d'un espace de stockage adéquat).

38
 • "coalesce" automatique (fusion des espaces libres contigus pour optimiser l'espace libre).

Paramètres de stockage
L'efficacité d'un tablespace dépend de la quantité d'espace utilisée par un segment. Ainsi, il est
important de connaître les paramètres qui influent sur la quantité d'espace utilisée par un segment.
Cinq paramètres déterminent et contrôlent la quantité d'espace utilisée par un segment. Il s'agit des
paramètres INITIAL, NEXT, MAXEXTENTS, MINEXTENTS et PCTINCREASE.
La taille du premier extent de tout segment est définie par le paramètre INITIAL. La taille minimale
du premier extent est de deux blocs ou de 2*DB_BLOCK_SIZE. La taille par défaut est de cinq blocs
ou de 5*DB_BLOCK_SIZE.
Le paramètre NEXT fait référence à la taille du deuxième extent. La taille minimale de l'extent
suivant est d'un bloc et la taille par défaut est de cinq blocs ou de 5*DB_BLOCK_SIZE.
La valeur du paramètre MINEXTENTS détermine le nombre d'extent alloués lors de la création du
segment. Par défaut, la valeur minimale est de un.
Le PCTINCREASE est le pourcentage d'augmentation de la taille de NEXT.
Par exemple, NEXT est défini sur 200 Ko et PCTINCREASE est défini sur 50%. Dans une telle
situation, le deuxième extent présente une taille de 200 Ko, le troisième extent une taille de 300 Ko et
le quatrième extent une taille de 450 Ko.
La valeur minimale du paramètre PCTINCREASE est de zéro et sa valeur par défaut est de 50. La
valeur calculée est arrondie à la valeur immédiatement supérieure de 5*DB_BLOCK_SIZE.
Le paramètre MAXEXTENTS détermine le nombre maximum d'extents qu'un segment peut contenir.
La valeur minimale est de un. La valeur maximale par défaut dépend de la taille des blocs de données.
La taille maximale peut également être spécifiée par le mot clé UNLIMITED, équivalent à une valeur
de 2 147 483 645.
Il est important de garder à l'esprit que les valeurs de ces paramètres doivent représenter un objet
typique qui sera créé dans le tablespace. Cependant, ces paramètres de stockage peuvent être rejetés
de la création de segments individuels.
Il est possible d’utiliser la commande ALTER TABLESPACE pour modifier les paramètres par
défaut

Tablespace temporaire
Ces tablespaces sont apparus avec la 9i et remplacent les segments temporaires qui étaient placés dans
les tablespaces standard. Il est nécessaire de créer une tablespace temporaire par défaut autre que
SYSTEM, où seront stockées uniquement les données temporaires (création d’index, jointures, tris,
etc...). Un segment temporaire permet d’avoir un gain de performance lorsque, par exemple, plusieurs
tris occupent trop de place pour la mémoire et doivent être stockés sur le disque dur temporairement.
Ainsi la taille du segment de tris va augmenter en allouant des extents jusqu’à ce que la taille du
segment soit suffisante pour stocker toutes les données que calculent les opérations de tris de
l’instance.
La commande pour créer un tablespace temporaire est la suivante :
CREATE TEMPORARY TABLESPACE temp
TEMPFILE ‘u01/oradate/temp01.dbf’ SIZE 500m
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;

39
Les tablespaces temporaires gérés localement ont des fichiers de données temporaires (tempfiles) qui
sont identiques aux fichiers de données ordinaires. Mais certaines différences existent. Tout d’abord,
les tempfiles sont toujours en mode NOLOGGING, ils ne peuvent être en lecture seule ou renommés.
On ne peut créer de tempfile avec la commande ALTER DATABASE.

Tablespace en lecture seul

Pour répondre aux exigences en matière d'organisation, il se peut que l'administrateur dispose de
tablespaces destinés à contenir des données de nature statique. Afin d'éviter d'avoir à procéder à des
opérations de sauvegarde et de restauration de telles données statiques, l'administrateur peut mettre
ces tablespaces en lecture seule. Ceci permet également de garantir qu'aucune opération d'écriture ne
sera effectuée sur les données.
Les fichiers de données peuvent être stockés sur des supports en lecture seule, tels que des CD-ROM
ou des disques WORM, car le serveur Oracle ne met jamais à jour les fichiers d'un tablespace en
lecture seule.
La commande SQL permettant de mettre un tablespace en mode lecture seule est la suivante :
ALTER TABLESPACE tablespace READ { ONLY | WRITE } ;
Outre la commande SQL, Oracle offre une interface graphique nommée Oracle Storage Manager
permettant de mettre un tablespace en mode lecture seule.
Il est possible de supprimer des objets comme des index ou des tables dans un tablespace en lecture
seul. En effet, la commande DROP met à jour seulement le dictionnaire de données mais pas les
fichiers physiques qui constituent le tablespace.
Cependant, plusieurs conditions doivent être remplies pour pouvoir mettre un tablespace en mode
lecture seule :
• le tablespace doit être online,
• aucune transaction active ne doit être en cours d'exécution sur ce tablespace
• le tablespace ne doit contenir aucun rollback segment actif et ne doit pas être actuellement
impliqué dans une sauvegarde online.
Le moyen recommandé de se conformer à ces restrictions consiste à démarrer l'instance en mode
restreint.
En outre, la mise en lecture seule des tablespaces provoque un point de synchronisation sur les
fichiers de données.
Supprimer un Tablespace

En raison d'une modification des besoins des utilisateurs, il se peut que certains tablespaces ne soient
plus nécessaires. La présence de ces tablespaces constitue un gaspillage d'espace disque. Pour
résoudre ce problème, Oracle permet de supprimer de tels tablespaces.
La commande SQL permettant de supprimer de tels tablespaces est la suivante :
DROP TABLESPACE tablespace
[INCLUDING CONTENTS [CASCADE CONSTRAINTS] ];
CASCADE CONSTRAINTS supprime les contraintes d'intégrité référentielle des
tables se trouvant en dehors du tablespace. Il s'agit des contraintes qui font référence
aux clés primaires et uniques des tables du tablespace supprimé.
Outre la commande SQL, Oracle offre une interface graphique, Oracle Storage Manager, permettant
de supprimer un tablespace.
Il est important de suivre un certain nombre de règles lors de la suppression d'un tablespace.

40
 • Il faut s'assurer que les transactions n'accèdent à aucun des segments du tablespace. Le
meilleur moyen de garantir cela consiste à mettre d'abord le tablespace offline.
• Si le tablespace est supprimé avec la commande SQL, il est important de se souvenir qu'un
tablespace contenant encore des données ne peut pas être supprimé sans l'option
INCLUDING CONTENTS.
Lorsque le tablespace contient de nombreux objets, l'utilisation de l'option INCLUDING
CONTENTS peut générer un grand nombre de rollback. Une alternative consiste à utiliser un
script pour supprimer un par un les objets du tablespace, puis à supprimer le tablespace.
Conséquences de la suppression de tablespaces

Pour économiser de l'espace disque, l'administrateur supprime les tablespaces qui ne sont plus
nécessaires.
Voici les conséquences de la suppression d'un tablespace :
• Les données du tablespace supprimé ne sont plus disponibles, elles ne peuvent donc plus
être interrogées.
• Lors de la suppression d'un tablespace, seuls les pointeurs de fichiers dans le fichier de
contrôle de la base de données associée sont supprimés. Pour récupérer l'espace disque
utilisé par le tablespace, il faut supprimer explicitement les fichiers de données au niveau
du système d'exploitation.
• Si un tablespace en lecture seule est supprimé, les segments qu'il contient sont également
supprimés. Dans ce cas, seuls le dictionnaire de données et les fichiers de données doivent
être mis à jour.

Autres options sur les Tablespaces

Configurer OMF pour la création de Tablespace

Lorsque l’on configure OMF pour créer un tablespace, un paramètre d’initialisation est spécifié :
DB_CREATE_FILE_DEST. Ce paramètre stocke le chemin par défaut des fichiers de données.
Il existe deux moyens de le configurer, soit directement dans le fichier d’initialisation soit avec la
commande suivante :
ALTER SYSTEM SET db_create_file_dest =
‘u01/oradate/db01’;
Créer des Tablespaces avec OMF

Lorsque l’on crée un tablespace avec OMF, la clause DATAFILE n’est pas obligatoire. Par défaut
les fichiers ont une taille de 100M, paramétrés à autoextend et de taille maximale illimitée.
CREATE TABLESPACE apps2_data DATAFILE SIZE 20M;
Récupérer des informations sur les Tablespaces
L'organisation des données dans le tablespaces présente plusieurs avantages.
Avantages liés à l'utilisation de plusieurs tablespaces :
• L'utilisation de plusieurs tablespaces garantit que les données utilisateur et les données du
dictionnaire de données peuvent être conservées séparément. Ceci permet une souplesse
des opérations sur la base de données.
• Les données des différentes applications peuvent être stockées dans des tablespaces
distincts. Ceci permet de garantir une bonne disponibilité des données.

41
 • La réduction des contentions constitue un autre avantage de l'utilisation de plusieurs
tablespaces. Les contentions E/S sont réduites grâce au stockage des fichiers de données de
différents tablespaces sur des disques durs distincts.
• L'utilisation de plusieurs tablespaces constitue une protection contre la perte définitive de
données. Cette protection est assurée par la séparation des rollback segments et des
segments de données.
• L'utilisation de plusieurs tablespaces offre un degré élevé de flexibilité dans
l'administration des données, car les tablespaces individuels peuvent être mis offline. Ceci
permet également de garantir une bonne disponibilité des données.
• L'utilisation de plusieurs tablespaces permet également la sauvegarde des tablespaces
individuels.
• L'utilisation de plusieurs tablespaces permet de réserver des tablespaces pour un type
particulier d'activité sur la base de données, tel que des activités de mise à jour, des
opérations en lecture seule et le stockage temporaire de segments. Ceci permet d'améliorer
l'efficacité de la base de données.
L'administrateur a besoin d'informations sur les tablespaces afin d'assurer une gestion efficace de la
base de données.
Oracle offre des vues du dictionnaire de données et des vues dynamiques sur les performances, qui
vous permettent de rassembler des informations sur les tablespaces. Les noms des vues dynamiques
sur les performances et des vues du dictionnaire de données sont les suivantes :
• DBA_TABLESPACES
Cette vue contient des informations sur les noms, les paramètres de stockage par défaut, les
types et la disponibilité de tous les tablespaces.
Section 4 Gestion des fichiers
Fichiers de données
Caractéristiques d'un fichier de données

Un tablespace est la structure de stockage logique la plus importante d'une base de données. Les
données du tablespace sont stockées dans les structures de stockage physiques appelées fichiers de
données.
Chaque tablespace d'une base de données Oracle est constitué d'un ou plusieurs fichiers de données.
Les fichiers de données sont les structures physiques conformes au système d'exploitation sur lequel
le serveur Oracle est installé.
Caractéristiques d'un fichier de données :
• Un fichier de données ne peut appartenir qu'à un seul tablespace. Ceci permet à un
administrateur de base de données de procéder à une sauvegarde du fichier de données
sans affecter la disponibilité de tout autre tablespace.
• Un fichier de données est créé par le serveur Oracle. Cependant, la quantité disque à
occuper par le fichier de données est spécifiée par l'administrateur de la base de données.
Le serveur Oracle crée le fichier de données avec la quantité spécifiée d'espace disque plus
un léger dépassement.
• Un fichier de données peut être modifié par l'administrateur de la base de données après sa
création. L'administrateur peut également spécifier que la taille d'un fichier de données doit
augmenter de façon dynamique, tout comme le nombre d'objets du tablespace. Cette
caractéristique permet à l'administrateur de la base de données de contourner la limitation
42
 du paramètre MAXDATAFILES et permet à la base de données d'être constituée de moins
de fichiers de données pour chaque tablespace.
Fichiers de manipulation des données
Mettre en place l’extension automatique des fichiers de données

La clause AUTOEXTEND permet d’autoriser ou non l’extension automatique des fichiers de

données. Les commandes suivantes peuvent être utilisées pour spécifier l’extension automatique.
• CREATE DATABASE
• CREATE TABLESPACE … DATAFILE
• ALTER TABLESPACE … ADD DATAFILE
Ajouter un fichier de données à un Tablespace

Lorsque les tables sont remplies avec des objets pendant une période donnée, l'espace disponible dans
les fichiers de données s'épuise. Pour faire face à cette situation, Oracle vous permet d'ajouter des
fichiers de données aux tablespaces. Cette opération alloue davantage d'espace disque aux objets de la
base de données.
La commande SQL permettant d'ajouter un fichier de données à un tablespace est affichée à l'écran.
ALTER TABLESPACE tablespace
ADD DATAFILE 'filespec' [auto_extend_clause];
Outre la commande SQL, Oracle offre une interface graphique appelée Oracle Storage Manager afin
de permettre d'ajouter un fichier de données à un tablespace.
Déplacer un fichier de données : ALTER TABLESPACE

Fichier de données non-SYSTEM :

Avec l'augmentation du nombre d'enregistrements de la base de données, la taille du fichier de
données augmente également. Par conséquent, il peut arriver que le support de stockage du fichier de
données ne dispose plus de suffisamment d'espace. Pour faire face à ce problème, Oracle permet de
déplacer les fichiers de données vers un nouvel emplacement.
ALTER TABLESPACE tablespace RENAME DATAFILE
'filename' [,'filename']...
TO 'filename' [,'filename']... ;
Le tablespace SYSTEM est nécessaire pour que la base de données fonctionne correctement.
Cependant, dans certaines situations, telles que le remplacement du disque dur sur lequel les fichiers
de données du tablespace SYSTEM sont actuellement stockés, l'administrateur doit déplacer les
fichiers de données du tablespace SYSTEM vers un nouvel emplacement.
Oracle permet de déplacer un fichier de données du tablespace SYSTEM vers un nouvel
emplacement. Voici les étapes à suivre :
• Arrêter la base de données
• Utiliser une commande du système d'exploitation pour déplacer les fichiers de données
vers le nouvel emplacement.
• Monter la base de données
• Déplacer le fichier de données du tablespace SYSTEM
• Ouvrir la base de données
Il faut toujours fournir les noms complets des fichiers accompagnés de leur chemin d'accès pour
identifier les anciens et les nouveaux fichiers de données.
Exemple :

43
 Déplacez le fichier de données SYS1ORCL.ORA du répertoire c:\ora92\database appartenant
au tablespace SYSTEM vers le répertoire d:\orclbackup.
 Montez la base de données
 Copiez le fichier dans le répertoire d:\orclbackup avec les commandes du système
d'exploitation
 Déplacer les fichiers de données dans la base de données :
SQL> ALTER DATABASE RENAME FILE 'c:\ora92\database\sys1orcl.ora'
2 TO 'd:\orclbackup\sys1orcl.ora';
 Ouvrir la base de données

Fichier de contrôle
Le fichier de contrôle est un petit fichier binaire, nécessaire pour démarrer et maintenir une base de
données. Le fichier de contrôle doit être disponible chaque fois que la base de données est montée ou
ouverte.
Lorsqu'une instance monte la base de données, elle lit le fichier de contrôle pour localiser les fichiers
de données et les fichiers redo log online.
Une des fonctions du fichier de contrôle est de fournir les informations les plus récentes sur la base de
données à l’instance Oracle mise à jour en permanence pendant l'utilisation de la base de données. Le
fichier de contrôle fournit également des informations sur la cohérence de la base de données. Ces
informations sont utilisées lors de la restauration de la base de données.
Si le fichier de contrôle utilisé par la base de données devient indisponible, la base de données ne peut
pas fonctionner proprement. Le fichier de contrôle peut devenir indisponible pour un grand nombre de
raisons telles que la défaillance du disque ou la corruption du fichier.
Certains mots-clés utilisés pendant la création d’une base de données, affectent la taille du fichier de
contrôle. Ceci est surtout visible quand les paramètres ont de très grandes valeurs. Les paramètres
suivants affectent la taille du fichier de contrôle :
• MAXLOGFILES
• MAXLOGMEMBERS
• MAXLOGHISTORY
• MAXDATAFILES
• MAXINSTANCES
Contenu des fichiers de contrôle

Le fichier de contrôle stocke des informations permettant à la base de données de fonctionner

correctement.
Le fichier de contrôle stocke :
• Le nom et l’identifiant de la base de données
• Les noms et les emplacements des fichiers de données et des fichiers redo log en ligne.
Ces informations permettent au serveur Oracle de localiser les fichiers de la base de
données sur le disque.
• Le nom des tablespaces
• La date et l'heure de création de la base de données.
• Le numéro de séquence de log actuel. Cette information permet de synchroniser tous les
fichiers appartenant à la base de données.

44
 • Les informations sur les points de synchronisation. Cette information est utilisée par le
serveur Oracle lors de la restauration de l’instance.
• L’historique des fichiers log
• Les informations de sauvegarde de l’utilitaire Recovery Manager.
• Le début et à la fin des segments de undo.
Le fichier de contrôle se divise en deux parties :
• Réutilisable, qui stocke les informations du Recovery Manager, comme les fichiers de
sauvegarde de redo log et les fichiers de sauvegarde de données. Ces fichiers ne sont
réutilisables que par le Recovery Manager.  Non réutilisable.

Gérer les fichiers de contrôle avec OMF

Les fichiers de contrôles sont reconnus comme OMF pendant la création de la base de données si le
paramètre CONTROL_FILES n’est pas spécifié dans le fichier d’initialisation. Si on utilise un fichier
init.ora, le paramètre CONTROL_FILES doit être défini au nom généré par OMF, qui peut être trouvé
en interrogant la vue V$CONTROLFILE ou le fichier alert<SID>.log. Si l’on utilise un SPFILE, le
paramètre CONTROL_FILES est automatiquement définit et généré à la création de la base de
données. Le fichier de contrôle généré s’appelle ora_cmr7t30p.ctl et contenu dans le fichier
alert<SID>.log.
Il est toujours possible de créer un nouveau fichier de contrôle en utilisant la commande CREATE
CONTROLFILE. Les noms des OMF doivent être utilisés dans les clauses DATAFILE et LOGFILE.
Récupérer les informations des fichiers de contrôle

Pour récupérer l’emplacement et les noms des fichiers de contrôles, il est nécessaire d’interroger la
vue dynamique V$CONTROFILE.
SELECT name FROM V$CONTROLFILE ;
NAME
-------------------------------
D:\ORACLE\ORADATA\IASDB\CONTROL01.CTL
D:\ORACLE\ORADATA\IASDB\CONTROL02.CTL
D:\ORACLE\ORADATA\IASDB\CONTROL03.CTL
2 rows selected.
D’autres vues peuvent être utilisées comme V$PARAMETER qui contient toutes les informations sur
tous les paramètres, V$CONTROLFILE_RECORD_SECTION qui contient les informations sur les
sections d’enregistrement des fichiers de contrôles, et la commande SHOW PARAMETERS
CONTROL_FILES qui liste le nom, l’état et l’emplacement des fichiers de contrôles.
Les fichiers de redo log
Utiliser les fichiers de redo log

Comme il a été vu dans le module précédent, les fichiers de redo log permettent d’enregistrer tous les
changements effectués par des transactions sur les données et fournissent un mécanisme de
récupération des données en cas de dysfonctionnement du système ou d’un disque. Les fichiers redo
log stockent toutes les modifications apportées aux données du buffer cache. L’organisation des

45
fichiers de redo log s’effectue en groupe (au minimum 2) contenant un ou plusieurs fichiers de redo
log. Chaque fichier de redo log appartenant à un groupe est appelé un membre.
Tous les membres redo log online présentent tous des numéros de séquence log identiques. Le numéro
de séquence log est affecté chaque fois que le serveur Oracle commence à écrire dans un groupe de
fichiers redo log online. Ces numéros sont utilisés pour identifier de façon unique chaque membre
redo log online.
Le numéro de séquence log courant est stocké dans le fichier de contrôle ainsi que dans l'entête de
tous les fichiers de données. Ce numéro est utilisé lors de la récupération de la base de données.
Les membres redo log online ont tous la même taille.
Un groupe de redo log en ligne sert également à restaurer des données validées qui n'ont pas été
écrites dans les fichiers de données. Une telle situation peut se produire après l'échec d'une instance.
Structure des fichiers de redo log

La charge de maintenir et gérer plusieurs fichiers de redo log appartient au DBA, pour éviter qu’un
seul dysfonctionnement d’un fichier fasse perdre des informations à la base de données. Les
mêmes informations sur les modifications apportées aux données sont enregistrées dans tous
fichiers redo log online d'un groupe de redo log online. Donc tous les fichiers redo log d'un groupe
redo log en ligne possèdent exactement les mêmes informations. Ce travail est effectué pas le
processus d'arrière plan LGWR.

Paramètres des fichiers de redo log

Les performances d'une base de données sont affectées par le nombre et la taille des fichiers et des
groupes redo log online.
Le numéro initial et la taille des fichiers redo log en ligne et des groupes sont déterminés pas des
paramètres d'initialisation :
• MAXLOGFILES spécifie le nombre maximal de groupes de fichiers redo log online. La
limite de MAXLOGFILES est de 255.
• MAXLOGMEMBERS détermine le nombre maximal de membres redo log online pour
chaque groupe de redo log online. Le nombre total de membres redo log online est un multiple
du nombre de fichiers redo log.
• LOG_FILES spécifie le nombre maximal actuel de groupes de fichiers redo log online pour la
durée de vie de l'instance courante. Par défaut, la valeur de LOG_FILES est plus petite ou
égale au nombre total de membres redo log en ligne (MAXLOGMEMBERS *
MAXLOGFILES).
Les fichiers redo log en ligne sont créés durant la création de la base de données.
Le serveur Oracle enregistre séquentiellement tous les changements fait sur la base de données dans le
buffer de redo log. Ensuite, les données contenues dans le redo buffer sont écrites grâce au process
LGWR dans le fichier de redo log online. LGWR déclenche le processus d’écriture lors d’un des
évènements suivants :
• Une transaction est comité.
• Quand le buffer de redo log est plein au tiers.
• Quand le buffer de redo log contient plus de 1Mo d’enregistrements changés.
• Avant que le process DBWn écrivent les blocs modifiés du database buffer cache dans les
fichiers de données.

46
Chapitre 5 Sauvegarde d’une base de données Oracle
Section 1 Principes de sauvegarde
Sauvegarde et restauration, permettent de se prémunir plus ou moins parfaitement de la perte
accidentelle de données physique, fichier de données ou autre.
Principaux cas de figure : corruption de fichier, perte de fichier, perte de disque. Obéissent à
une stratégie :
 Quoi sauvegarder : totalité, tablespace, uniquement les données sensibles, etc.
 Quand : fréquence pluri quotidienne, quotidienne, hebdomadaire, etc.
 Comment : à froid, à chaud, physiquement, logiquement
Rependent à des contraintes :
 Disponibité des données : haute, moyenne, basse
 Importance relative de certaines données
 Temps de reprise
 Volume maximum de perte supporté
 Economie (par exemple très haute disponibilité, coute cher,…
Section 2 Sauvegarde
Sauvegarde manuelle du fichier de données
Sauvegarde à froid (base arrêtée)
Sauvegarde à chaud (online): si et seulement si en mode archivelog
procédure de backup à froid
--fichier de contrôle
select name from v$contolfile;
---fichier de données
select name
from v$datafile;
---les journaux
select member
from v$logfile
--NB: copier les fichiers de la BD vers le répertoire de sauvegarde
---backup Manuel à chaud
1. alter datebase begin backup;
ou
alter tablespace nom_tablespace begin backup;
2. copie physique des fichiers vers la destination de backup
3. alter database end backup;
backup avec recovery manager (RMAN)
lancer RMAN EN LIGNE DE COMMANDE
RMAN target /
au préalable il faut se mettre au niveau du repertoire BIN
cd E:\oracle\oracle_serveur\product\11.2.0\dbhome\BIN
--affiche les parametres de RMAN
show all;
on copie CONFFIGURE CONTROLFILE AUTOBACKUP OFF;
47
on le colle en modifiant OFF en ON;
backup database;
NB: RMAN n'est possible qu'en mode archivage

---arret de la base
--startup
restore database;
recover database;
alter database open;
--indiquer l'emplacement des fichiers de sauvegarde
configure channel device type disk format 'E:\oracle\backup\OCADBA_%U';
----perte d'un fichier de controle
1. cas
modifier le fichier de parametre
controle_files
2. cas
remplacer le fichier invalide par le fichier valide
"E:\oracle\oracle_flashback\OCADBA\control02.ctl"
-- perte de tous les fichiers de controle

alter database backup controlfile to trace as 'E:\oracle\backup

-----------------
run{
allocate channel c1 type disk;
buckup
incremental level=0
format 'E:\oracle\backup\rman\df_%d_%s_%p.bak';
database;
}

Sauvegarde logique basee sur la technomogie de oracle datapump

avec les utilitaires EXPDP(export datapump)
et impdp(import datapump)
-----------executer en ligne de commande
E:\oracle\oracle_serveur\product\11.2.0\dbhome

expdp system/oracle123@ocadba

les fichiers sont generés dans le repertoire oracle_base\admin\sid\dpdump

--- creer un repertoire pour les dmp

48
 create directory repdp
as 'E:\oracle\backup';

expdp system/oracle123@ocadba directory =repdp dumpfile = scott_091213.dmp schemas

=scott

Chapitre 6 Restauration d’une base de données Oracle

Section 1 Principes

Conditions nécessaires pour remettre la base en l’état du dernier backup (Full Backup ou
Archivelog backup) † Disposer des données du repository catalog; † Disposer des fichiers de
backups RMAN; † Restaurer préalablement les filesystems / et /U01; † Recréer préalablement
l’arborescence de /U02 à /U06.
Pour restaurer jusqu’à la dernière transaction il faut disposer des éléments nécessaires à la
restauration partielle ainsi que: † de tous les archivelogs non encore sauvegardés † des
redologs † du dernier controlfile (si possible) Pour cette raison, dans l’architecture proposée,
tous ces fichiers sont écrits simultanément sur plusieurs filesystem qui devraient
obligatoirement correspondre à des disques différents

Section 2 Restauration
restore database;
recover database;
alter database open;
--indiquer l'emplacement des fichiers de sauvegarde
configure channel device type disk format 'E:\oracle\backup\OCADBA_%U';
----perte d'un fichier de controle
1. cas
modifier le fichier de parametre
controle_files
2. cas
remplacer le fichier invalide par le fichier valide
"E:\oracle\oracle_flashback\OCADBA\control02.ctl"
-- perte de tous les fichiers de controle
alter database backup controlfile to trace as 'E:\oracle\backup
----------------
run{
allocate channel c1 type disk;
buckup
incremental level=0
format 'E:\oracle\backup\rman\df_%d_%s_%p.bak';
database;
}

49
 Chapitre 7 Configuration des disques Oracle
Section 1 Différents systèmes de fichiers
Fichiers de la base de données
Une base de données Oracle a une structure logique et physique. Entendons par structure physique
que les fichiers contenu dans la base de données ont une réelle existence (ex : fichiers de données).
Pour sa part, la base de données Oracle est constituée de trois types de fichiers :
Les fichiers de données contenant les données des blocs de données qui sont modifiées par les
transactions courantes, le dictionnaire de données, les objets utilisateurs.
Les fichiers de redo log contenant un enregistrement des changements qui ont été fait sur la base de
données, pour avoir la possibilité de revenir en arrière en cas de dysfonctionnement. Une base Oracle
contient au moins deux groupes de redo log chacun contenant au moins un fichier de redo log. Pour
renforcer leur tolérance à une panne de disque dur, Oracle supporte les fichiers de redo log
multiplexés. On peut ainsi maintenir une ou plusieurs copies de fichiers de redo log sur différents
disques (On parle de fichiers mirrorés).
Les fichiers de contrôle contenant les informations nécessaires pour maintenir et vérifier l’intégrité
des données de la base. Une base de données Oracle nécessite au moins un fichier de contrôle, il est
toutefois possible de les mirrorer sur plusieurs disques dur.
Fichiers relatant à la Base de données
Ce sont les fichiers qui ne font pas partie de la base de données mais qui sont utilisés par le serveur
Oracle pour des opérations telles que le démarrage d'une instance ou l'authentification des utilisateurs.
Il existe trois types de fichiers :
Les fichiers de paramètre (Parameter File) :
Il va définir les caractéristiques de l'instance. Lors du démarrage d'une instance, le serveur Oracle va
lire les paramètres d'initialisation du fichier de paramètres.
On retrouve des informations telles que le nom de la base de données, la taille de la mémoire à
allouer, le nom des fichiers de contrôle ainsi que les autres paramètres système.
Le fichier de mots de passe (Password File) :
Il est utilisé pour authentifier les utilisateurs privilégiés.
Les fichiers de redo log archivés (Archived Redo Log Files) :
Ils contiennent des copies off line des fichiers de redo log. Ils sont utilisés lors d'une récupération
suite à une défaillance d'un média. Les fichiers de redo log sont sauvés lorsqu'ils sont pleins, cette
fonctionnalité n'est utilisée que lorsque la base de données est en mode "ARCHIVELOG".

Section 2 Technologie RAID

Un ensemble RAID est composé de deux disques durs physiques ou plus, combinés en une seule unité
de stockage logique. Un RAID apporte des fonctionnalités supplémentaires par rapport à une
configuration JBOD (Just a Bunch Of Disks). On retrouve trois grands concepts:
o « miroitage » (mirroring en anglais)
o volumes agrégés par bandes (stripping en anglais)
o correction d’erreurs
Un miroir consiste en l’écriture de données identiques sur plus d’un disque. L’exemple de base de
mise en miroir est une matrice RAID 1 formée de deux disques. Les deux disques ont le même
contenu en tout temps. Si le premier disque tombe en panne, les opérations de lecture et d’écriture
peuvent être effectuées directement sur le second disque. Les opérations de lecture sur les matrices en
50
 miroir sont plus rapides que sur un seul disque, car le système peut récupérer les données sur plusieurs
disques en même temps
L’agrégation par bandes de volumes est le partage des données sur plusieurs disques. Par exemple, le
RAID 0 constitué de deux disques sépare les données sur les deux disques. Cette technique ne fournit
aucune tolérance en cas de panne, seulement un gain de performance. Les opérations de lecture et
d’écriture sont plus rapides car les deux opérations sont réparties entre tous les disques disponibles.
La correction d’erreurs nécessite l’enregistrement des données de parité afin de permettre la détection
et éventuellement la correction des problèmes. Le RAID 5 est un bon exemple du mécanisme de
correction d’erreurs. Par exemple, une matrice RAID 5 composée de trois disques distribue les
données sur les deux premiers disques et enregistre la parité sur le troisième pour assurer la tolérance
aux pannes. Le mécanisme de correction d’erreurs ralentit les performances, en particulier au niveau
des opérations d’écriture puisque tant les données que les informations de parité doivent être
enregistrées. En outre, la reconstruction d’une matrice défectueuse à partir de l’information de parité
implique une dégradation accrue des performances parce que les données doivent être récupérées à
partir de tous les lecteurs du RAID afin de reconstruire l’information sur le nouveau disque.
La conception de tout système RAID est un compromis entre la protection des données et la
performance. La compréhension de vos besoins en matière de stockage est primordiale afin de
sélectionner la configuration RAID appropriée.
RAID matériel vs logiciel
Il existe deux types de gestionnaires de RAID:
o Matériels
o Logiciels

Chapitre 8 Optimisation et performance

Section 1 optimisation de Windows
L’optimisation ou « Tuning » consiste à établir le meilleur niveau de performance d’un système en
tenant compte de contraintes souvent contradictoires.
En général, les applications sont testées sur de petites configurations, avec peu de données. Elles sont
ensuite déployées et le volume de données n’a plus rien en commun avec ce qu’il était initialement.
Des problèmes jusqu’à là masqués, apparaissent alors. Cette raison est la première cause nécessitant
des actions de tuning.
Vous pouvez améliorer de façon spectaculaire les performances en corrigeant des erreurs courantes
provenant de l’application ou du paramétrage. Pour cela il faut utiliser un tuning
Section 2 Etapes du tuning
Etape 1 Installer et configurer Oracle proprement
Etape 2 Choix de design de l’application
Etape 3 Optimisation des traitements et ordre Sql
Etape 4 Tuning de la mémoire
Etape 5 Tuning des entrées/sorties disques
Etape 6 Tuning de l’utilisation CPU
Etape 7 Tuning des différentes contentions

51
Chapitre 9 Interface JDBC
Section 1 Généralités

La version .0 de l'API JDBC a été intégrée au JDK 1.2. Cette nouvelle version apporte plusieurs
fonctionnalités très intéressantes dont les principales sont :

 support du parcours dans les deux sens des résultats

 support de la mise à jour des résultats
 possibilité de faire des mises à jour de masse (Batch Updates)
 prise en compte des champs définis par SQL-3 dont BLOB et CLOB

L'API JDBC est séparée en deux parties :

 la partie principale (core API) contient les classes et interfaces nécessaires à l'utilisation de
bases de données : elles sont regroupées dans le package java.sql
 la seconde partie est une extension utilisée dans J2EE qui permet de gérer les transactions
distribuées, les pools de connexions, la connexion avec un objet DataSource ... Les classes et
interfaces sont regroupées dans le package javax.sql
A partir de JDBC version 3.0 fournie avec Java 1.4, l'interface javax.sql.DataSource propose de
fournir une meilleure alternative à la classe DriverManager pour assurer la création d'instance de
connexions à une base de données.
Une implémentation de l'interface DataSource est une fabrique pour créer des connexions vers une
source de données. Il existe plusieurs types d'implémentation de l'interface DataSource :

 implémentation basique (basic implementation) : créer des instances de type Connection

 implémentation utilisant un pool de connections (connection pooling implementation) : obtenir
des instances préalable créées et stockées dans un pool
 implémentation pour transactions distribuées (distributed transaction implementation) : obtenir
des instances pouvant participer à une transaction distribuées

Les fournisseurs de pilotes doivent proposer au moins une implémentation de l'interface DataSource.

Une fois créé, un objet de type DataSource peut être enregistré dans un service de nommage. Il suffit
alors d'utiliser JNDI pour obtenir une instance de classe DataSource.

JDBC n'est qu'une spécification : l'implémentation réalisée au travers des pilotes peut proposer tout ou
uniquement une partie de ces fonctionnalités.

Un pool de connexions permet de maintenir et réutiliser un ensemble de connexions établies vers une
base de données. L'établissement d'une connexion est très coûteux en ressources. L'intérêt du pool de
connexions est de limiter le nombre de ces créations et ainsi d'améliorer les performances surtout si le
nombre de connexions est important.

52
Section 2 Connexion à une base de données
La connexion à une base de données requiert au préalable le chargement du pilote JDBC qui sera
utilisé pour communiquer avec la base de données. Une fabrique permet alors de créer une instance de
type Connection qui va encapsuler la connexion à la base de données.
Pour se connecter à une base de données via ODBC, il faut tout d'abord charger le pilote JDBC-
ODBC qui fait le lien entre les deux.
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Pour se connecter à une base en utilisant un driver spécifique, la documentation du driver fournit le
nom de la classe à utiliser. Par exemple, si le nom de la classe est jdbc.DriverXXX, le chargement du
driver se fera avec le code suivant :
Il n'est pas nécessaire de créer une instance de cette classe et de l'enregistrer avec le DriverManager
car l'appel à Class.forName le fait automatiquement : ce traitement charge le pilote et crée une
instance de cette classe.
La méthode static forName() de la classe Class peut lever l'exception
java.lang.ClassNotFoundException.
Pour se connecter à une base de données, il faut instancier un objet de la classe Connection en lui
précisant sous forme d'URL la base à accéder.
La syntaxe URL peut varier d'un type de base de données à l'autre mais elle est toujours de la forme :
protocole:sous_protocole:nom
"jbdc" désigne le protocole et vaut toujours "jdbc". "odbc" désigne le sous protocole qui définit le
mécanisme de connexion pour un type de base de données.
Le nom de la base de données doit être celui saisi dans le nom de la source sous ODBC.
La méthode getConnection() peut lever une exception de la classe java.sql.SQLException.

Bibliographie :
Jacky, A. (2011). Conception des Bases de Données Relationnelles en pratique, Vuibert
Christ J., D. (2004). Introduction aux bases de données, Vuibert
Jérôme, G. (2015). Théorie et pratique Oracle 12C : Programmer avec SQL et PL/SQL, ENI
Georges, G. (1988). Bases de Données : Les systèmes et leurs langages, Eyrolles
Georges, G. (2005).Bases de Données, Eyrolles
Eric, G. (2011). SAL les fondamentaux du langage, ENI
Christian, S. (2011). SQL pour Oracle, Eyrolles

53
Table des matières
Chapitre 1 Installation et paramétrage d’Oracle.................................................................................................1
Section 1 Installation d’Oracle.........................................................................................................................1
 Oracle Universal Installer :..................................................................................................................1
 Optimal Flexible Architecture (OFA)....................................................................................................1
 Créer une base de données.................................................................................................................1
 Authentification et privilèges..............................................................................................................3
 Fichiers de paramètres........................................................................................................................3
 Paramètres présents dans le fichier de paramètre.............................................................................3
Chapitre 2 Oracle.Net, le Middleware Oracle.....................................................................................................4
Section 1 Définition de Middleware et d’Oracle.Net........................................................................................4
Section 2 Oracle.Net et Listener Oracle...........................................................................................................5
 Le fichier d’initialisation d’Oracle Net................................................................................................5
 Le fichier trace d’Oracle Net................................................................................................................5
 Configuration d’Oracle Net.................................................................................................................5
 Le listener (écouteur) Oracle...............................................................................................................5
 Les assistants Oracle Net : Netca et Netmgr.......................................................................................5
Chapitre 3 Programmer avec PL/SQL..................................................................................................................5
Section 1 types de données PL/SQL.................................................................................................................5
 Utilisation et traitement des variables................................................................................................5
 Utilisation et traitement des variables :..............................................................................................5
 Les types de données scalaires............................................................................................................6
 Les types de données composés.........................................................................................................7
 Les variables scalaires.........................................................................................................................8
 Les variables composées (les collections)...........................................................................................9
Section 2 LE CONTROLE DES FLUX DANS LES BLOCS PL/SQL..........................................................................12
Section 3 Transaction.....................................................................................................................................18
 Les environnements de développement...........................................................................................19
 Appel de fonctions et de procédures................................................................................................20
 Les sous programmes........................................................................................................................20
Section 4 CREATION DE FONCTIONS...............................................................................................................20
 Les fonctions.....................................................................................................................................20
 Supprimer des fonctions...................................................................................................................22
 Récapitulatif......................................................................................................................................22
Section 5 CREATION DE PACKAGES.................................................................................................................23

54
  Les packages......................................................................................................................................23
 Créer des packages............................................................................................................................24
 Manipuler les packages.....................................................................................................................26
Section 6 EXCEPTIONS....................................................................................................................................27
Section 7 Déclencheur....................................................................................................................................31
Chapitre 4 Gestion de l’espace disque et des fichiers.......................................................................................31
Section 1 Apport d’Oracle entreprise manager..............................................................................................31
Section 2 Gestion de l’espace.........................................................................................................................32
 Recherche d’informations sur les segments......................................................................................33
 Affichage des informations sur les extents utilisés............................................................................33
 Recherche d’informations sur les extents libres................................................................................34
Section 3 Gestion des tablespaces.................................................................................................................35
 Caractéristiques d'un tablespace......................................................................................................35
 Utilisations d'un tablespace..............................................................................................................35
 Créer des Tablespaces.......................................................................................................................35
 Création d’un tablespace..................................................................................................................36
 Paramètres de stockage....................................................................................................................37
 Tablespace temporaire......................................................................................................................38
 Tablespace en lecture seul................................................................................................................38
 Autres options sur les Tablespaces...................................................................................................39
 Fichiers de manipulation des données..............................................................................................41
 Fichier de contrôle............................................................................................................................42
 Gérer les fichiers de contrôle avec OMF...........................................................................................43
 Les fichiers de redo log......................................................................................................................44
 Paramètres des fichiers de redo log.................................................................................................44
Chapitre 5 Sauvegarde d’une base de données Oracle.....................................................................................45
Section 1 Principes de sauvegarde.................................................................................................................45
Chapitre 6 Restauration d’une base de données Oracle....................................................................................47
Section 1 Principes.........................................................................................................................................47
Section 2 Restauration...................................................................................................................................47
Chapitre 7 Configuration des disques Oracle....................................................................................................48
Section 1 Différents systèmes de fichiers.......................................................................................................48
Section 2 Technologie RAID...........................................................................................................................48
Chapitre 8 Optimisation et performance..........................................................................................................49
Section 1 Optimisation de Windows..............................................................................................................49
Chapitre 9 Interface JDBC..................................................................................................................................50
55
Section 1 Généralités.....................................................................................................................................50
Section 2 Connexion à une base de données.................................................................................................51
Bibliographie :................................................................................................................................................51

56