INTRODUCTION

ORACLE a été édité par la société Oracle Corporation, implantée aux USA à RedWood Shores en Californie.
Premier prototype 1977. Oracle version1 en 1979 premier SGBDR au monde.
Depuis, les produits ORACLE n’ont cessé d’évoluer avec l’évolution des technologies de l’information et de la
communication. Aujourd’hui ORACLE est un SGBD réparti, qui s’est tourné vers le Web.
Oracle est le leader des SGBD sur le marché mondial.
Objectif généraux :
Ce cours a pour but de vous apprendre à installer oracle, administrer une base de données, sa création, la
création des objets (Tables, séquences, indexes, …), la mise en place de la sécurité (gestion des utilisateurs),
la sauvegarde, restauration des données et la configuration de base de données pour une application.
.Chpt 1 : INSTALLATION D’ORACLE ET LES PRODUITS ORACLE

I. Produits et Editions Oracle

I.1 Produits

• Base de données Oracle

• Oracle Application Server
• Oracle Applications
• Oracle Collaboration Suite
• Oracle Development Suite
• Oracle Services
• ORACLE Server, gestionnaire de la base de données : il contrôle toutes les actions au niveau de la
BD comme l’accès utilisateur et la sécurité, stockage et intégrité des données.
• Le langage SQL et l’extension PL/SQL (langage comprenant des commandes procédurales
supportant la gestion des erreurs et déclaration de variables)
• ORACLE Designer est un ensemble de produits intégrés dans un référentiel unique d’entreprise pour
la conception des applications.
• ORACLE Developer : outils de développement d’applications client/serveur ou Internet.
• ORACLE Discoverer : outil d’interrogation pour des utilisateurs qui ont besoin d’accéder par eux-
mêmes aux données, Datawarehouse, Datamart.
I.2 Les Editions Oracle

 Enterprise Edition : inclut toutes les fonctionnalités d’Oracle Database, en standard ou en option, et
gère des données extrêmement volumineuses.
 Standard Edition : inclut les fonctionnalités de base, mais ne permet pas d’exploiter certaines options
avancées. Cette édition est d’ailleurs destinée pour des serveurs avec une capacité maximale de
quatre processeurs.
 Standard Edition One : pratiquement identique à l’édition standard mais limité à des serveurs
biprocesseurs.
 Personal Edition : disponible uniquement sur Windows, destinée aux développeurs pour une
utilisation mono-utilisateur.

1
  Express Edition : complètement gratuite, destinée pour des machines monoprocesseurs et
spécialement pour les petites entreprises, voire les institutions à but académique.
 Lite Edition : inclut les fonctionnalités requises pour le développement et le déploiement
d’applications et de base de données mobiles.

II. Configuration système requise

Matériel :
• 512 Mo de mémoire physique (RAM)
• 1 Go d'espace de swap (ou deux fois la quantité de RAM)
• 400 Mo d'espace disque dans le répertoire temporaire (/tmp ou \Temp)
• 1,5 Go d'espace disque pour le logiciel Oracle
• 1,5 Go d'espace disque pour la base de données préconfigurée Système d'exploitation : voir
documentation
Objectifs
A la fin de ce chapitre, vous pourrez :
• décrire l'architecture de la base de données Oracle
• comprendre l'architecture d'une instance
• utiliser la structure de gestion
• utiliser l'assistant DBCA pour
– créer une base de données
– configurer une base de données
– supprimer une base de données
– gérer des modèles

III. Installation oracle 10g

 Comment obtenir Oracle 10g :

Vous pouvez télécharger la base de données d'Oracle 10g de www.oracle.com. Vous devez
enregistrer et créer un compte avant que vous puissiez télécharger le logiciel.

 Installation proprement dite

Sous UNIX, l'installation d'Oracle Database ne peut se faire que par un utilisateur du groupe système
DBA. L'administrateur système "root" ne peut pas faire l'installation. Créez alors un groupe "DBA" et
un compte séparé appartenant à ce groupe "DBA" pour faire l'installation.
Sous Windows, l'installation doit se faire par un utilisateur du groupe administrateurs système. Ce
compte sera ajouté à un groupe système ORA_DBA créé automatiquement durant l'installation
d'Oracle Database.
Etape 1:
Décompresser le logiciel d'installation que vous avez téléchargé : "10201_database_win32.zip " dans
un dossier que vous choisissez ("c:\soft\oracle10g" par exemple)
Etape 2:
Lancer "C:\soft\oracle10g\database\setup.exe" pour démarrer "Oracle Universal Installer"
Dans l'écran qui suit :

2
Choisissez l'option "Installation de base" et laissez les valeurs choisies par défaut. Choisissez un mot de
passe de l'administrateur oracle (comptes System et Sys).

Cliquez, ensuite, sur "Suivant"

L'installateur procède à la vérification des prérequis :

Si toutes les vérifications affichent le status "Succès", cliquez sur "Suivant".

3
Etape 3

A ce niveau, un écran résumant les paramètres d'installation est affiché :

Cliquez sur "Installer".

Si vous recevez une alerte de sécurité liée au Par-feu Windows, cliquez sur "Débloquer" pour autoriser les
composants java à s'exécuter.

Etape 4:

A ce niveau l'installation proprement dite est démarrée :

4
Laissez l'installateur progresser dans la configuration Oracle Net, base de données et iSQLPlus

A la fin de la création de la base de données et démarrage de l'instance oracle associée, l'écran suivant est
affiché:

Cliquez sur "OK" si vous ne souhaitez pas déverrouillez les comptes par défaut. Vous pouvez gérer plus tard
les comptes oracle via la console d'administration.

Sauvegarder le contenu de l’écran Assistant Configuration de Base de données pour d’éventuelle utilisation,
ou vous pouvez trouver ces informations dans le dossier oracle_home\install\readme.txt.

Une fois terminé :

5
Cliquez sur suivant : et puis sur "Quitter" dans l'écran "Fin de l'Installation".

Ainsi, vos fichiers de configuration de base de données sont installés dans oracle_home exemple
"C:\oracle\product\10.2.0\db_n" (n entier).

IV. Les principales variables d’environnement sont

1) ORACLE_HOME = définie l’emplacement du noyau Oracle (l’endroit où tous les outils
sont installés) exemple : C:\oracle\product\10.2.0\db_1
2) ORACLE_BASE = définie l’emplacement des bases oracle C:\oracle\product
3) ORACLE_SID = désigne le nom de l’instance sur laquelle on veut se positionner
4) NLS_LANG = langage du système d’exploitation exemple :
FRENCH_FRANCE.WE8MSWIN1252

V. Tâches d'un administrateur de base de données Oracle

Approche générale pour la conception, l'implémentation et la maintenance d'une base de
données Oracle :
1. Evaluer le matériel pour le serveur de base de données
2. Installer le logiciel Oracle
3. Planifier la base de données
4. Créer et ouvrir la base de données
5. Sauvegarder la base de données
6. Inscrire les utilisateurs du système
7. Implémenter la conception de la base de données
8. Récupérer la base de données suite à une panne
9. Surveiller les performances de la base de données

Chp II : GESTION DES INSTANCES ORACLE

I. Les structures mémoire de base associées à une instance Oracle:

6
 • Mémoire SGA : partagée par tous les processus serveur et processus en arrière-plan.
• Mémoire PGA (Program Global Area) : propre à chaque serveur et processus en arrière-plan ; il
existe une mémoire PGA pour chaque processus.
La mémoire SGA est une zone de mémoire partagée contenant les données et les informations de contrôle de
l'instance.

La mémoire SGA contient les structures de données suivantes :

• Cache de tampons (Database buffer cache) de la base de données : met en mémoire cache les
blocs de données récemment extraits de la base.
Généralement, augmenter la taille du Database Buffer Cache améliore les performances.
La taille du bloc (DB_BLOCK_SIZE) étant fixée à la création de la base, la taille du Database
Buffer Cache est définie par la valeur du paramètre DB_BLOCK_BUFFERS qui fixe le nombre de
buffers en mémoire, chaque buffer ayant une taille égale à DB_BLOCK_SIZE. Le paramètre
DB_BLOCK_BUFFERS est typiquement compris entre un millier (pour une petite base de test) et
plusieurs dizaines/centaines de milliers d’octets. Dimensionné par le paramètre
DB_CACHE_SIZE.
• Tampon de journalisation (Redo Log Buffer) : met en mémoire cache les informations de
journalisation (utilisées pour la récupération d'instance) jusqu'à ce qu'elles puissent être écrites
dans les fichiers de journalisation physiques stockés sur le disque. Dimensionné par le paramètre
LOG_BUFFER.
• Zone de mémoire partagée (Shared Pool Area) : met en mémoire cache diverses structures
pouvant être partagées par les utilisateurs (des ordres SQL récentes (Library Cache) et des
données du dictionnaire de données (Dictionary Cache). Elle est utilisée pour mémoriser,
analyser et traiter les ordres SQL soumis par les utilisateurs, elle peut réutiliser les ordres SQL
déjà exécutés. Elle est Dimensionnée par le paramètre SHARED_POOL_SIZE.
• Zone de mémoire LARGE POOL : zone facultative utilisée pour la mise en mémoire tampon des
demandes d'E/S volumineuses. Dimensionnée par le paramètre LARGE_POOL_SIZE.
• Zone de mémoire Java (Java Pool) : utilisée pour l'ensemble du code Java et des données
propres à la session, dans la JVM (Java Virtual Machine). Dimensionné par le paramètre
JAVA_POOL_SIZE.
• Zone de mémoire Streams (Stream Pool): utilisée par Oracle Streams. Dimensionné par le
paramètre STREAMS_POOL_SIZE.

Lorsque vous démarrez l'instance via Enterprise Manager ou SQL*Plus, la mémoire allouée pour la mémoire
SGA s'affiche.

Les Vues nécessaires :

II. Les Processus

Les processus Oracle permettent les différentes composantes du serveur d’interagir et d’échanger entre elles
ainsi qu’avec l’utilisateur. Il existe des processus utilisateurs du côté des clients, un ou plusieurs processus
serveurs du côté du serveur assurant la communication avec le client et plusieurs processus d’arrière plan qui
assurent le bon fonctionnement de l’instance.

a. Les processus-utilisateur et le processus-serveur

 La connexion

Le lien entre le processus utilisateur et le processus serveur est appelé une connexion.

7
Une connexion spécifique entre un utilisateur et un serveur Oracle est appelé une Session.
La session démarre lorsque la connexion de l'utilisateur est validée par le serveur Oracle et se termine
lorsqu'il se déconnecte ou lorsqu'une fin de connexion prématurée se produit.
De nombreuses sessions concurrentes d'un même utilisateur ou de plusieurs peuvent s'exécuter sur le
serveur Oracle.

L’interaction entre les clients et le serveur de base de données est assurée par le processus utilisateur du
côté client et par le processus serveur du côté du serveur. En effet, lorsqu’un utilisateur démarre une
application (SQL*Plus, Oracle Enterprise Manager, une application Developer Forms etc.), Oracle démarre un
processus utilisateur que ce soit sur sa machine distante s’il s’agit d’une architecture client-serveur ou sur un
serveur middle-tiers sur une architecture multi-tiers. Par la suite, une connexion entre le processus utilisateur
et l’instance est initiée et maintenue. Une fois la connexion établie, l’utilisateur ouvre une session en
s’identifiant (saisie de son nom d’utilisateur et de son mot de passe). Il est à noter que plusieurs sessions
peuvent être ouvertes en même temps, ces sessions peuvent être ouvertes par le même utilisateur ou
d’autres. Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est
SESSIONS.
Après l’ouverture d’une session, Oracle démarre un processus serveur sur le serveur base de données, c’est
ce processus qui se chargera d’exécuter les requêtes de l’utilisateur et de maintenir une interaction entre le
client et le serveur.
Un serveur base de données est soit configuré en mode dédié, soit en mode partagé. Lorsque le serveur est
configuré en mode dédié, Oracle crée sur le serveur pour chaque utilisateur (et donc pour chaque processus
utilisateur) un processus serveur. En mode partagé, plusieurs processus utilisateurs peuvent partager un seul
et unique processus serveur. Le mode par défaut est le mode dédié, pour activer le mode partagé, il suffit de
modifier le paramètre SHARED_SERVERS dont la valeur par défaut est 0. La nouvelle valeur indiquerait le
nombre de processus serveurs partagés démarrés lorsque l’instance est lancée.
Rappelons qu’une zone de mémoire PGA est créée pour chaque processus serveur, elle inclut entre autres
les variables hôtes et les variables de session utilisées dans les requêtes/programmes
 Syntaxe de la connexion classique
La connexion d’un utilisateur quelconque à une base de données oracle se fait en suivant la syntaxe :

SQLPLUS /nolog

8
SQL> Connect user_name/monpass@ service_OracleNet ( à la place de @service_OracleNet vous
pouvez positionner d’abord la variable d’environnement oracle_sid)
Exemple : set oracle_sid=nom_sid avant de taper SQLPLUS /nolog

Exemple : connexion de l’utilisateur System avec mot de passe Manager et Service Oracle Net « Orcl »
SQL> Connect SYSTEM/manager@Orcl

 Syntaxe pour la connexion spéciale SYSDBA ou SYSOPER

Avec une identification par le système d’exploitation
CONNECT / AS {SYSDBA | SYSOPER}
Set ORACLE_SID=Orcl
sqlplus /nolog
SQL> Connect /as sysdba
Les connexions SYSDBA et SYSOPER
SYSDBA : permet toutes les opérations « lourdes » d’administration (création, arrêt, démarrage, restauration,
…).
SYSOPER : même droits que SYSDBA, à l’exception de la création de la base et des restaurations partielles.

b. Processus d’arrière plan

Dans une instance, les processus en arrière plan effectuent les fonctions courantes nécessaires aux
traitements simultanés de plusieurs requêtes utilisateurs, sans compromettre l’intégrité et la performance de
l’ensemble du système. Selon la configuration, chaque instance peut utiliser plusieurs processus en arrière
plan, mais chacune d’elle comprend par défaut les cinq processus en arrière plan suivants :
o Le process PMON (Process Monitor)
 Nettoie les connexions terminées de façon anormale
 Défait les transactions non validées
 Libère les verrous qui ont été posés par un processus client terminé en erreur
 Libère les ressources SGA allouées par le processus client en erreur
 Redémarre les serveurs partagés et le processus Dispatcher en erreur.
Le processus PMON est orienté vers la gestion des ressources demandées par les processus clients.
o Le process SMON (System Monitor)
 Réalise la restauration automatique d'une instance (au démarrage de celle-ci)
 Récupère l'espace occupé par les segments temporaires (tris) qui ne sont plus utilisés
 Fusionne les zones contiguës d'espace libre dans les fichiers de données
SMON est orienté vers le maintien de la cohérence globale de la base de données.
o Le process LGWR (Log Writer)
LGWR écrit les entrées dans les fichiers Redo Log à partir du Buffer Redo Log lorsque :
 Le délai d'attente par défaut est dépassé (3 secondes)
 Le Buffer Redo Log est rempli au tiers
 Avant que DBWR n'écrive dans les fichiers de données de la base.
 Lorsqu'une transaction est validée (commit)
LGWR est orienté vers le maintien de la cohérence logique de la base de données.

o Le process DBWR (Database Writer)

DBWR écrit dans les fichiers de données de la base de données les blocs Oracle du Buffer Cache (SGA) qui
ont subit une modification. DBWR réalise des copies de bloc Oracle depuis la mémoire vers leur emplacement
d'origine dans les fichiers de données de la base.
LGWR est orienté vers le maintien de la cohérence physique de la base de données.
9
 o Le Processus Checkpoint
Il met à jour les informations sur l’état de la base de données à chaque enregistrement définitif dans la base
de données suite à des modifications effectuées dans le buffer cahe.
Les autres processus sont optionnels. Si l'un de ces cinq processus échoue, le démarrage de l'instance ne se
fera pas, celle-ci sera détruite et devra être redémarrée.

o Les Process optionel dû aux parametrages :

RECO, LCKn, Pnn et SNPn, ARCn :
 RECO résout les erreurs concernant une transaction distribuée (cas de plusieurs serveurs)
 LCKN REALISE LE VERROUILLAGE INTER-INSTANCES DANS UN SYSTEME PARALLEL SERVER
 Pnnn permet le parallélisme des requêtes, de la création d'index, du chargement de données, et de la
commande CREATE TABLE AS SELECT
 SNPn réalise les rafraîchissements automatiques des snapshots (tables répliquées en lecture seule). Il
est également responsable des files d'attente de job du serveur et des files d'attente de réplication.
 ARCn (Archiver) : copie les fichiers de journalisation dans l'emplacement de stockage d'archivage lorsque
les fichiers journaux sont pleins ou en cas de changement de fichier de journalisation.

III. Les vues Statiques et Dynamiques

a. Les vues statiques

Les vues statiques sont basées sur de vraies tables stockées dans le tablespace SYSTEM, et sont
accessibles uniquement quand la base est ouverte.
Les vues statiques sont caractérisées par leur préfixe :
USER_* : Informations sur les objets qui appartiennent à l’utilisateur (exp User_tables)
ALL_* : Information sur les objets auxquels l’utilisateur a accès (les siens et ceux sur lesquels il a reçu des
droits) expl : ALL_Tables
DBA_* : Information sur tous les objets de la base (expl : DBA_Tables)
Derrière le préfixe, le reste du nom de la vue est représentatif de l’information accessible, au pluriel. Exemple
b. vues dynamiques de performance
Ces tables sont basées sur des informations en mémoire ou extraites du fichier de contrôle.
Elles donnent des informations sur le fonctionnement de la base de données, notamment sur les
performances. Elles sont remises à zéro si on arrête la base de données.
Elles sont accessibles même lorsque la base n’est pas complètement ouverte (MOUNT).
Les vues dynamiques de performance sont : Préfixées par « V$ ».
Derrière le préfixe, le reste du nom de la vue est représentatif de l’information accessible exemple :
V$INSTANCE, V$DATABASE, V$SGA, V$DATABASE, V$PARAMETER
Les vues DICTIONARY et DICT_COLUMNS donnent la description de toutes les tables et vues du
dictionnaire (statiques et dynamiques).
- la liste complète des vues statiques Commen9ant par DBA est obtenue par la requête :
SELECT view_name FROM ALL_VIEWS WHERE ALL_VIEWS like ‘DBA%’ ;

IV. Création d’une Instance Oracle

IV.1 Syntaxe de création d’instance

set ORACLE_SID=Nom_SID
Oracle_Home\bin\oradim -new -sid Nom_SID -startmode AUTO -pfile
"Emplacement_fichier_init\initsid.ora"

10
 IV.2 Syntaxe de Modification d’une Instance
Set ORACLE_SID=Nom_SID
Oracle_Home\bin\oradim -Edit -sid Nom_SID -startmode AUTO -pfile
"Emplacement_fichier_init\initsid.ora"

V. Arrêt et Démarrage de la base de données

11
Commande de démarrage de l’instance

$ >Sqlplus/nolog
Connect sys/motpasse@chaine_de_connexion
Startup open

12
Commande d’Arrêt de l’instance

$ >Sqlplus/nolog

Connect sys/motpasse@chaine_de_connexion

Shutdown immediate

13
Chp 2 : GESTION DE LA BASE DE DONNEES

I. Architecture de la base de données

I.1 Architecture Physique : les fichiers

Une base de données Oracle est un ensemble cohérent de fichiers OS; ceux-ci appartiennent à trois groupes
distincts :
a) Les fichiers de contrôle (trois au moins !), ils contiennent une cartographique de la structure physique
de la base de données : Ils sont lus au démarrage de l'instance et mis à jour après chaque modifications de
la structure physique de la base de données.
Création d’un fichier de contrôle
SQL>alter database backup controlfile to trace;
Cette commande génére un fichier traces dans le répertoire des traces utilisateurs indiqué par le paramètre
"user_dump_dest". Le fichier ressemble alors à ceci : La partie qui nous intéresse est la suivante :

STARTUP NOMOUNT
CREATE CONTROLFILE Reuse DATABASE "oratest" NoRESETLOGS NoARCHIVELOG
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 908
LOGFILE
GROUP 1 'D:\ORACLE\ORADATA\oratest\REDO01.LOG' SIZE 10M,
GROUP 1 'D:\ORACLE\ORADATA\oratest\REDO02.LOG' SIZE 10M,
GROUP 2 'D:\ORACLE\ORADATA\oratest\REDO03.LOG' SIZE 10M,
GROUP 2 'D:\ORACLE\ORADATA\oratest\REDO04.LOG' SIZE 10M
DATAFILE
'D:\ORACLE\ORADATA\oratest\SYSTEM01.DBF',
'D:\ORACLE\ORADATA\oratest\CWMLITE01.DBF',
'D:\ORACLE\ORADATA\oratest\DRSYS01.DBF',
'D:\ORACLE\ORADATA\oratest\INDEX\INDDEM.DBF',
'D:\ORACLE\ORADATA\oratest\INDEX\INDDIS.DBF',
CHARACTER SET WE8MSWIN1252
14
;
RECOVER DATABASE;
ALTER DATABASE OPEN;

b) Les fichiers Redo Log ou fichiers de journale des transactions, qui contiennent les enregistrements de
toutes les modifications effectuées sur le contenu de la base de données lors des transactions utilisateurs.
c) Les fichiers de données ou datafiles, ces derniers contiennent toutes les données de la base : les
structures logiques, telles que les tables, indexes, séquences, synonymes, vues et clusters qui sont
physiquement stockés dans les fichiers de données. Referez vous à la partie des tablespaces pour la
création de ces fichiers de données car ils sont liés aux tablespaces.
o Les Fichiers Redo Log
Les fichiers Redo Log contiennent les Redo Entries : structures d'information contenant la trace de toutes les
modifications du contenu de la base; ils sont utilisés pour la restauration des données. Les fichiers Redo Log
DOIVENT être multiplexés sur deux disques distincts afin de procurer une sécurité maximum en cas de
pannes disque. Les fichiers redo log sont remplis selon un mode circulaire. Il doit y avoir au moins deux
groupes de fichiers redo log pour qu'une instance accepte de démarrer. Dans la pratique on peut avoir
raisonnablement une quinzaine de groupe.
o Les fichiers Redo Log Multiplexés
Oracle recommande d'avoir au moins deux membres de redo log par groupe, chaque membre devant résider
sur un disque différents (si possible les disques devant être sur des contrôleurs SCSI différents).
Le multiplexage des redo log permet au DBA de survivre professionnellement à la perte d'un fichier Redo Log.
Tous les membres d'un groupe de fichiers Redo Log contiennent la même information et SONT de même
taille.
Les membres d'un même groupe sont mis à jours simultanément par LGWR.
Chaque groupe devrait contenir le même nombre de membres que les autres groupes.
LGWR écrit dans les fichiers Redo Log de manière séquentielle : lorsque le groupe courant est rempli, LGWR
écrit dans le groupe suivant. Lorsque le dernier groupe est rempli, LGWR recommence à écrire dans le
premier groupe et ainsi de suite... Chaque changement de groupe est appelle "SWITCH de Redo Log". Le
DBA a moyen de forcer un switch de Redo Log à l'aide de la commande suivante:

ALTER SYSTEM SWITCH LOGFILE ;

o Mise à jour des fichiers Redo Log online
Généralités
Les fichiers Redo Log sont mis à jour par le serveur Oracle afin de minimiser au maximum les pertes de
données. Ils sont utilisés lors de la restauration d'une instance. Oracle y écrit TOUS les changements qui se
produisent sur les données de la base de données. Avant d'écrire physiquement dans les fichiers Redo Log,
les modifications sont conservées dans le Buffer Redo Log de l'instance. Les fichiers Redo Log sont LE
mécanisme de sécurité d'Oracle.
 Groupes et membres de fichiers Redo Log
Le DBA peut (et doit) configurer la base de données de telle façon que des copies de fichiers Redo Log soient
maintenues afin d'éviter les pertes de données qui pourraient advenir lors d’une panne (panne disque par
exemple).
Les premiers groupes et membres de fichiers Redo Log sont crées lors de la création de la base de données.
Il est ensuite possible d'ajouter ou retirer des groupes ou des membres. Certains paramètres influent sur le
nombre de groupes ou de membres possibles.
- MAXLOGFILES : nombre maximum de groupe de Redo Log (le maximum est 255).
- MAXLOGMEMBERS : nombre maximum de membre par groupe.
- LOG_FILES : nombre maximum de groupes de redo logs qui peuvent être ouverts en même temps pour
la base de données.
15
 LGWR, Switchs de fichiers et points de synchronisation
Tous les changements apportés à la base de données sont stockés dans le Buffer Redo Log. C'est le process
background LGWR (LoG WRiter) qui écrit le contenu du Buffer redo Log dans le groupe de Redo Log courant
lorsque :
- Un COMMIT est exécuté.
- Lorsque le Buffer Redo Log est rempli au Tiers.
- Le délai d'attente par défaut de LGWR (3 secondes) est dépassé.
- Avant que DBWR (DataBase WRiter) n'écrive les blocs modifiés du Buffer Cache dans les fichiers de
données.
- Le process backgrounp CKPT (ChecKPoinT) met à jour les entêtes de TOUS les fichiers de données ainsi
que le fichier de contrôle.
Un point de synchronisation est déclenché lorsque :
- Un switch de Redo Log (que celui-ci se passe "naturellement" ou qu'il soit forcé par le DBA)
- Lorsqu'une instance est arrêtée "proprement" (avec les options NORMAL, IMMEDIATE ou
TRANSACTIONAL)
- La structure physique de la base de données est modifiée : ajout de tablespace, mise offline d'un
tablespace ou encore lorsque le DBA passe la base en lecture seule)
Les switchs de Redo Log sont mentionnés dans le fichier alert<SID>.log
 Archivage de fichiers Redo Log
Une base de données peut fonctionner dans deux modes : ARCHIVELOG et NOARCHIVELOG (mode par
défaut). Une base de production ne doit JAMAIS fonctionner en mode NOARCHIVELOG.
En mode NOARCHIVELOG, les fichiers Redo Log écrasés par LGWR ne sont pas archivés (copiés). Les
données de ces fichiers sont donc perdues définitivement. En mode ARCHIVELOG, les fichiers Redo Log sont
archivés avant que LGWR ne les écrasent. Ce mode permet des restaurations très précises lors d'un gros
plantage. Ces deux modes de la base de données seront discutés dans le chapitre "Sauvegarde et
Restauration" plus loin dans ce cours.
 Informations sur le mode de fonctionnement de la base de données

La commande suivante, lancée sous Server Manager (svrmgrl) permet de savoir si la base fonctionne en
mode ARCHIVELOG ou NOARCHIVELOG.
Svrmgrl> ARCHIVE LOG LIST
Un peu de pratique
 Ajout de groupe de Redo Log :
Il peut être intéressant dans certains cas d'ajouter des groupes de Redo Log (en fonction de l'évolution d'une
base de production par exemple).
ALTER DATABASE ADD LOGFILE
('Unite\disk5\log31.rdo', 'unite\disk6\log32.rdo') SIZE 10M;
Remarquez que dans cet exemple, les deux membres du groupe sont sur des disques différents.
 Ajout de membre de fichier Redo Log :
Dans le cas où une base de données n'aurait pas ses redo log multiplexés, il est impératif de rajouter au
moins un membre à chaque groupe pour garantir la sécurité de celle-ci par la commande suivante :
ALTER DATABASE ADD LOGFILE MEMBER
'disk6\log12.rdo' TO GROUP 1, '\disk6\log22.rdo' TO GROUP 2;
L'exemple ci-dessus ajoute un membre aux groupes 1 et 2; ceux-ci sont donc désormais multipléxés.
 Déplacer des fichiers Redo Log :
Le déplacement de fichiers Redo Log se fait en plusieurs étapes :
1. Arrêter la base de données (shutdown immediate)
2. Déplacer (par des commandes OS) les fichiers au nouvel emplacement (cp, mv)
3. Monter la base de données (startup mount)

16
 4. Exécuter la commande
ALTER DATABASE RENAME FILE '\disk6\log12.rdo' TO '\disk7\log12.rdo';
5. Ouvrez la base de données (alter database open)
 Suppression de groupes de fichiers Redo Log
Pour augmenter (ou diminuer) la taille des membres d'un groupe, il faut créer un nouveau groupe dont les
membres sont plus volumineux puis supprimer un ancien groupe devenu trop petit.
ALTER DATABASE DROP LOGFILE GROUP 5 ;
Dans certains cas, il est impossible de supprimer un groupe de Redo Log :
- Il faut impérativement à Oracle au moins 2 groupes de Redo Log
- On ne peut pas supprimer le groupe de Redo Log courant
- Dans le cas d'une base en mode ARCHIVELOG, il est impossible de supprimer un groupe qui n'a pas été
archivé
 Suppression de membres
Il est possible de supprimer un membre d'un groupe de fichiers Redo Log par la commande :
ALTER DATABASE DROP LOGFILE MEMBER '\disk6\log12.rdo' ;
Tout comme pour la suppression des groupes de Redo Log, il existe certains cas dans lesquels il est
impossible de supprimer un membre d'un groupe.
- Il est impossible de supprimer le dernier membre valide d'un groupe.
- Il est impossible de supprimer un membre du groupe courant; il faudra attendre ou forcer un switch de
Redo Log.
- Dans le cas d'une base en mode ARCHIVELOG, il est impossible de supprimer un membre d'un groupe
non archivé.

 Outres les trois principaux fichiers, il en existe d’autres qui sont :

Le fichier de paramètre, fichier de Mot de passe, les fichiers traces, Alerte et les fichiers Archives.
o Le Fichier Init.ora
Pour démarrer une instance, Oracle doit lire un fichier de paramètres init<SID>.ora. Le fichier paramètre est
un fichier texte contenant une liste de paramètres de configuration d'instance. Entre autre chose, le fichier
paramètre renseigne Oracle sur les points suivants :
- La quantité de mémoire à utiliser pour les structures internes de la SGA.
- Que faire avec les fichiers rod log actifs et pleins.
- Les noms et emplacements des fichiers de contrôle de la base de données.
Quelques paramètres du fichier init.ora
SHARED_POOL_SIZE taille en octets de l'espace assigné pour le partage des ordres SQL et PL/SQL
DB_BLOCK_SIZE taille en octet d'un bloc Oracle (mémoire et disque)
DB_BLOCK_BUFFER taille du buffer cache en nombre de blocs
LOG_BUFFER taille en octet du redo buffer
o Le Fichier Spfile.ora ( dans les versions postérieures à la 8i)
Il renferme les mêmes informations que le fichier pfile.
o Les Fichiers Traces et le fichier alert.log
Si une erreur se produit durant l'utilisation de votre instance Oracle, les messages sont écrits dans le fichier
alert.log. Si l'erreur est détectée par un processus serveur ou un processus détaché (PMON,SMON
LGWR,DBWR) l'information est vidée dans un fichier trace
 Le fichier alert.log
Le fichier alert.log d'une base de données est un journal chronologique de messages et d'erreurs qui comprend :
- Toutes les erreurs internes (ORA-600), erreur de corruption de blocs (ORA-1578) et les erreurs
d'interblocage (ORA-60).
17
 - Toutes les opérations d'administration, et les commandes de server Manager (SVRMGRL) sont
logées dans ces fichiers.
- Les valeurs de tous les paramètres d'initialisation qui n'ont pas une valeur par défaut au moment
du démarrage de l'instance.
Oracle utilise le fichier alert.log en tant qu'alternative à l'affichage de telles informations sur la console de
l'opérateur. Le fichier alert.log se trouve dans l'emplacement spécifié par le paramètre
BACKGROUND_DUMP_DEST.
Il est fondamental de vérifier quotidiennement le contenu du fichier alert.log, afin de détecter les problèmes
éventuels avant qu'ils ne deviennent sérieux et pendant que vous avez encore une sauvegarde valide, selon
la nature du problème.
 Les fichiers traces
Quand une erreur interne est détectée par un processus serveur ou par un processus détaché, l'information
sur le dysfonctionnement est vidée dans un fichier trace en relation avec le processus. Les fichiers traces sont
localisés à l'emplacement spécifié par le paramètre BACKGROUND_DUMP_DEST, si l'information est écrite
par un processus détaché, sinon elle est écrite dans la destination spécifiée par USER_DUMP_DEST , c'est le
cas des processus serveur.
o Les Fichiers Redo Log archivés
Les Fichiers Redo Log archivés : ils copient offline les fichiers redo log pouvant être nécessaires à la
restauration des données suite à une panne d’un disque.
o Le fichier mot de passe
Le fichier mot de passe est utilisé pour établir l’authenticité des utilisateurs privilégiés de bases de données.
 Création du fichier Mot de passe

Autrefois créé avec l’utilitaire ORAPWD, il est aujourd’hui créé automatiquement lors de la création de la base
de données avec l’outil dbca. Mais pour des raisons de sécurité ou de corruption du fichier vous pouvez
toujours utiliser l’utilitaire ORAPWD pour le créer.
Ce fichier protège le compte SYS associé au privilège SYSDBA permettant une administration lourde
(création, démarrage, arrêt, restaurations).
orapwd file=<fichier> password=<mot de passe> [entries=<valeur>]
C: \orapwd file=$ORACLE_HOME/Database/pwd<SID>.ora password=dba entries=5
Pour octroyer le privilege SYSDBA à un utilisateur faite :
Grant SYSDBA to mon_user;

I.2 Explorer la Structure Avec OEM

18
I. 3 Architecture Logique :

I.3.1 Composition Logique

19
I.3.2 Gestion des Structures de Stockage

20
  Actions sur les tablespaces
Le menu Actions vous permet d'effectuer différentes opérations sur les tablespaces. Sélectionnez un
tablespace, puis l'action que vous souhaitez effectuer :
• Add Datafile : ajoute un fichier de données au tablespace, ce qui a pour effet
d'augmenter la taille de ce dernier.
• Create Like : crée un tablespace en utilisant un autre tablespace comme
modèle.
• Generate DDL : génère l'instruction LDD qui crée le tablespace. Cette
instruction peut ensuite être copiée et collée dans un fichier texte afin d'être
utilisée en tant que script ou à des fins de documentation.

21
 • Make Locally Managed : si le tablespace est actuellement géré au moyen du
dictionnaire de données, cette opération le convertit en tablespace géré
localement.
• Make Readonly : arrête toutes les écritures dans le tablespace. Les
transactions en cours peuvent se terminer, mais aucune nouvelle instruction
LMD ou autre activité d'écriture n'est autorisée à démarrer sur le tablespace.
• Make Writable : permet le lancement d'instructions LMD et d'autres activités
d'écriture sur les objets du tablespace.
Afficher les informations relatives aux tablespaces
Cliquez sur View pour afficher les informations relatives au tablespace sélectionné. Dans la page View
Tablespace, vous pouvez également cliquer sur Edit afin de modifier le tablespace.
Les informations relatives aux tablespaces et aux fichiers de données peuvent également être
obtenues via l'interrogation des vues suivantes :
• Informations relatives aux tablespaces :
- DBA_TABLESPACES
- V$TABLESPACE
• Informations relatives aux fichiers de données :
- DBA_DATA_FILES
- V$DATAFILE
• Informations relatives aux fichiers temporaires :
- DBA_TEMP_FILES
- V$TEMPFILE
 Création du TableSpace Permanent

CREATE TABLESAPCE tablespace_name

DATAFILE filespec size [autoextend_claused]
[, filespec size [autoextend_claused]]…
[MINIMUM EXTENT [K|M]]
[ONLINE|OFFLINE]
Storage_clause:==
STORAGE ([INITIAL [K|M]]
[NEXT [K|M]]
[MINEXTENTS integer ]
[MAXEXTENTS { integer | UNLIMITED} ]
[PCTINCREASE integer ])

DEFAULT STORAGE : paramètres de stockage par défaut qui sera appliqué à tous les objets crées dans ce
tablespace

22
MINIMUM EXTENT : permet de s’assurer que chaque taille d’extent utilisée dans le tablespace est un multiple
de l’entier. Cette option est uniquement disponible à partir de la version 8
D'autres options peuvent être ajoutées à cette commande :
ONLINE : spécifie la mise online (disponible aux utilisateurs) du tablespace. C'est la valeur par défaut.
OFFLINE : spécifie la mise offline (non disponible aux utilisateurs) du tablespace
PERMANENT : Indique que le tablespace sera utilisé pour contenir des objets permanents (données, index).
C'est la valeur par défaut.
TEMPORARY : Indique que le tablespace ne contiendra que des objets temporaires. Cette option est utilisée
lorsque l'on crée un tablespace qui contiendra les segments de tri.
√ Paramètres de stockage
Les paramètres de stockage servent à contrôler l'allocation d'espace pour un segment. Ces paramètres sont
initialisés à la création du segment. Si aucun paramètre de stockage n'est indiqué lors de la création d'un
segment (dans les commandes CREATE TABLE, CREATE INDEX...), ce sont les paramètres de stockage par
défaut de la tablespace qui sont appliqués à ce segment.
Les paramètres de stockage sont les suivants :
- INITIAL : taille du premier extent. La taille minimum de l'initial est de 2*DB_BLOCK_SIZE (taille de 2 blocs
Oracle); la valeur par défaut est 5 blocs Oracle.
- NEXT : taille de l'extent qui suit l'initial.
- MINEXTENTS : nombre d'extents pré-alloués lors de la création du segment. La valeur minimum est de 1;
en effet, un segment contient au moins un extent : l'INITIAL.
- PCTINCREASE : pourcentage d'augmentation de la taille d'un extent en fonction de l'extent précédent.
ex : si un extent fait 100K et que le PCTINCREASE est 50%, la taille de l'extent suivant sera 150K
- MAXEXTENTS : nombre maximum d'extent d'un segment. Il est possible de spécifier UNLIMITED qui
permet de ne pas fixer de limite au nombre d'extents d'un segment.

Exemple :

CREATE TABLESPACE DATA_01

DATAFILE '/disk4/data_01.dbf' SIZE 500M,
'/disk5/data_02.dbf' SIZE 500M
MINIMUM EXTENT 100K
DEFAULT STORAGE (INITIAL 64K NEXT 64K MAXEXTENTS 500 PCTINCREASE 50) ;

 Création de Temporary TableSpace

CREATE TEMPORARY TABLESAPCE tablespace_name
TEMPFILE ‘filespec’ size [autoextend_claused]
[, ‘filespec’ size [autoextend_claused]]…
√ Ajout de Datafile(s) à un Tablespace
Devant la croissance d'une base de données de production, il est parfois indispensable de rajouter un (ou
plusieurs) datafiles dans un tablespace afin de pouvoir continuer à stocker les données de production. La
commande suivante s'en charge :
ALTER TABLESPACE DATA_01
ADD DATAFILE '/disk7/data_03.dbf' SIZE 1000M ;
√ Modification de la taille d'un Datafile
Il y a deux façons de modifier la taille d'un fichier de données :
1. En spécifiant la clause AUTOEXTEND
ALTER DATABASE DATAFILE '/disk7/data_03.dbf'
AUTOEXTEND ON MAXSIZE 1500M;
23
2. En modifiant manuellement la taille du fichier de données ou en ajoutant un fichier de données
ALTER DATABASE DATAFILE '/disk7/data_03.dbf' RESIZE 1500M ;
√ Modification des paramètres de stockage
C'est la commande ALTER TABLESPACE qui permet de modifier les paramètres de stockage.
ALTER TABLESPACE DATA_01 DEFAULT STORAGE (MAXEXTENTS 123);
ALTER TABLESPACE DATA_01 DEFAULT STORAGE (INITIAL 10M NEXT 25M);
√ Les différents statuts des Tablespaces
Un tablespace peut avoir plusieurs statuts :
ONLINE : tous les utilisateurs peuvent accéder aux données contenues dans les datafiles de ce tablespace.
ALTER TABLESPACE DATA_01 ONLINE ;
OFFLINE : aucun utilisateur ne peut accéder au tablespace. Lorsque l'on met un tablespace OFFLINE. Un
point de synchronisation est effectué. Si une base est arrêtée avec un tablespace OFFLINE. La présence de
celui-ci ne sera pas vérifiée lors du redémarrage suivant. La mise offline d'un tablespace supporte trois options
supplémentaires : NORMAL (par défaut), TEMPORARY et IMMEDIATE.
ALTER TABLESPACE DATA_01 OFFLINE ;
READ ONLY : les données des fichiers de données du tablespace sont accessibles en lecture seule. Aucun
utilisateur ne pourra faire de mise à jour sur celles-ci. Ce statut est intéressant pour un tablespace qui
contiendrait des tables de paramètres par exemple.
ALTER TABLESPACE DATA_01 READ ONLY;
READ WRITE : ce statut est le statut qui permet aux utilisateurs d'accéder en modifications aux données.
ALTER TABLESPACE DATA_01 READ WRITE;
√ Déplacement de fichiers de données
Il existe deux méthodes pour déplacer un fichier de données :
A l'aide de la commande ALTER TABLESPACE:
Cette commande ne s'applique qu'aux fichiers de données qui appartiennent à une tablespace non SYSTEM
la procédure est la suivante :
1. Mettre la tablespace OFFLINE
ALTER TABLESPACE DATA_01 OFFLINE ;
2. Déplacer par une commande OS le fichier de données :
$ mv \disk5\data_01.dbf \disk6\data_01.dbf
3. Exécuter la commande :
ALTER TABLESPACE RENAME DATAFILE
'\disk5\data_01.dbf' TO '\disk6\data_01.dbf' ;
4. Remettez le tablespace ONLINE
ALTER TABLESPACE DATA_01 ONLINE ;
A l'aide de la commande ALTER DATABASE:
Cette commande permet de déplacer n'importe quel fichier de données, qu'il soit dans un tablespace
SYSTEM ou non SYSTEM. La procédure est la suivante :
1. Fermez la base de données
SHUTDOWN IMMEDIATE ;
2. Utilisez une commande OS pour déplacer physiquement le fichier de données en question à un
nouvel emplacement
$ mv \disk1\system01.dbf \disk2\system01.dbf
3. Montez la base de données
STARTUP MOUNT ;
4. Exécuter la commande ALTER DATABASE
ALTER DATABASE RENAME FILE
24
'\disk1\system01.dbf' TO '\disk2\system01.dbf’;
5. Ouvrez la base de données
ALTER DATABASE OPEN ;
√ Suppression des Tablespaces
La commande DROP TABLESPACE permet de supprimer un tablespace :
DROP TABLESPACE DATA_01 ;
Il faut utiliser l'option INCLUDING CONTENTS pour supprimer un tablespace qui contient encore des
données.
L'option CASCADE CONSTRAINTS permet de supprimer les contraintes d'intégrité référentielles sur les
tables qui se situent en dehors du tablespace en question.

 Données d'annulation

Les données d'annulation sont également utilisées pour la récupération suite à l'échec de
transactions. Une transaction échoue lorsqu'une session utilisateur se termine de façon anormale (par
exemple suite à des erreurs réseau ou à la défaillance de l'ordinateur client), avant que l'utilisateur
n'ait décidé de valider (commit) ou d'annuler la transaction. Les transactions peuvent également
échouer suite à une défaillance de l'instance. En cas d'échec d'une transaction, le comportement le
plus sûr est choisi et Oracle annule toutes les modifications apportées par un utilisateur, en
rétablissant les données d'origine.

Des informations d'annulation sont conservées pour toutes les transactions, au moins jusqu'à la fin de
la transaction, qui a lieu lorsque l'un des événements suivants se produit :

• L'utilisateur change d'avis (annulation).

• L'utilisateur termine la transaction (validation).

• La session utilisateur se termine de façon anormale (annulation).

• La session utilisateur se termine de façon normale parce que l'utilisateur quitte

la session (validation).

Les informations d'annulation peuvent être conservées plus longtemps, selon l'activité et la
configuration de la base de données.

o Administrer les informations d'annulation

Oracle Database 10g recommande l'utilisation de la gestion automatique des annulations, via l'affectation de
la valeur AUTO au paramètre d'initialisation UNDO_MANAGEMENT. La gestion manuelle des annulations est
prise en charge pour des raisons de compatibilité descendante avec Oracle8i et les versions antérieures, mais
nécessite beaucoup plus d'interventions
du DBA.

Avec la gestion automatique des annulations, le DBA gère les informations d'annulation au niveau tablespace,
en contrôlant via le paramètre d'initialisation UNDO_TABLESPACE le tablespace d'annulation utilisé par une
instance. Après la sélection du tablespace d'annulation, l'administrateur doit simplement faire en sorte que
l'espace soit suffisant et qu'une période de conservation des informations d'annulation soit configurée.
25
Avec la gestion manuelle, le DBA doit également :

• Dimensionner les segments, notamment le nombre maximum d'extents et la taille

des extents

• Identifier et éliminer les transactions provoquant un blocage

• Créer suffisamment de segments d'annulation pour gérer les transactions (en mode manuel, les
segments d'annulation sont également appelés "rollback segments")

• Choisir un tablespace pour le stockage des segments d'annulation (les tablespaces d'annulation
ne sont utilisés qu'avec la gestion automatique des annulations)

Undo_management=auto

Undo_tablespace=undotbs1

o Création d’undo Tablespace

Create undo tablespace Nom_tablespace

Datafile ‘chelmin\fichier’ size nK/M autoextend on

Retention Guarenttee

o Activé un undo tablespace

Alter system set undo_tablespace= Nom_tablespace ;

Les vues : V$transaction, dba_undo_extends

La période de conservation des informations d'annulation peut être configurée via le paramètre d'initialisation
UNDO_RETENTION. Ce paramètre définit la période au-delà de laquelle les informations d'annulation
expirent et peuvent être remplacées si nécessaire.

26
Avec la gestion automatique, les informations d'annulation sont si possible conservées jusqu'à leur expiration,
mais si une transaction active a besoin d'espace dans le tablespace d'annulation, les informations validées
(non expirées) sont remplacées, quelle que soit la période de conservation définie, afin d'éviter l'échec de la
transaction.

Une période de conservation de 0 active le réglage (tuning) automatique de la période de conservation des
informations d'annulation. Dans ce mode, l'instance conserve autant d'informations d'annulation que
nécessaire pour satisfaire l'interrogation la plus longue.

o Garantir la période de conservation

Le comportement par défaut consiste à remplacer les informations d'annulation des transactions validées et
qui n'ont pas encore expiré, dès lors qu'il s'agit d'éviter l'échec d'une transaction en raison d'un manque
d'espace.

Ce comportement peut toutefois être modifié via la garantie de la période de conservation. Lorsque la période
de conservation des informations d'annulation est garantie, les paramètres de conservation sont appliqués
même si cela entraîne l'échec d'une transaction.

RETENTION GUARANTEE est un attribut de tablespace et non un paramètre d'initialisation. Cet attribut peut
être modifié uniquement avec des instructions SQL de ligne de commande. La syntaxe permettant de modifier
un tablespace d'annulation afin de garantir la période de conservation des informations d'annulation est
illustrée dans la diapositive ci-dessus. Pour rétablir le comportement par défaut, utilisez la commande
suivante :

SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;

La garantie de la période de conservation des informations d'annulation s'applique uniquement aux

tablespaces d'annulation. Toute tentative de l'appliquer à un autre tablespace provoque l'erreur suivante :

SQL> ALTER TABLESPACE example RETENTION GUARANTEE;

ERROR at line 1:

ORA-30044: 'Retention' can only specified for undo tablespace

II. Création de la base de données

II.1. Par ligne de commande
/* Creation de L’instance

set ORACLE_SID=BASE
Oracle_home\bin\oradim.exe -new -sid BASE -startmode manual -spfile
Oracle_home\db_1\bin\oradim.exe -edit -sid BASE -startmode auto -srvcstart system

Création de la base
Oracle_home\bin\sqlplus/nolog
Connect sys/mot_pas as sysdba
Startup nomount

Set Echo On
27
 Spool 'c:\oracle\the_path\the_echo\echo_create.txt'
CREATE DATABASE Base
USER SYS IDENTIFIED BY password
USER SYSTEM IDENTIFIED BY y1tz5p
LOGFILE GROUP 1 ('/u01/oracle/oradata/mynewdb/redo01.log') SIZE 100M,
GROUP 2 ('/u01/oracle/oradata/mynewdb/redo02.log') SIZE 100M,
GROUP 3 ('/u01/oracle/oradata/mynewdb/redo03.log') SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE '/u01/oracle/oradata/mynewdb/system01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/u01/oracle/oradata/mynewdb/sysaux01.dbf' SIZE 325M REUSE
DEFAULT TABLESPACE tbs_1
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/u01/oracle/oradata/mynewdb/temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE '/u01/oracle/oradata/mynewdb/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

28
 Chp 3 : Présentation des Outils de Gestion

Cet utilitaire permet de créer, de modifier et de supprimer une base de données.

Il se lance à partir Démarrer\programmes\Oracle-OraDb10g_home1\Outils de Configuration et de

Migration\Assistant Configuration de base de données

 OEM : Oracle Entreprise Manager

Il permet de gérer la base de données : Exécution des tâches administratives, gestion de manière
graphique des objets

29
30
31
Cet outil permet d’exécuter des requêtes SQL et PLSQL

32
  Assistant Configuration Oracle net :

Cet outil permet de créer un nom de service Réseau et un processus d’écoute

 Comment créer un listener :

Choisir configuration d’un processus d’écoute et faire suivant jusqu’à la fin.
 Comment créer un nom de service réseau :
Choisir Configurer nom de service réseau local, faire suivant, ajouter, Entrer le nom de la
Base de Données, choisir le protocole TCP, entrer le nom d’hôte, tester la connexion,
Entrer le nom de service Réseau et cliquer sur terminer.
Toute fois vous pouvez ouvrir le fichier du répertoire Oracle_home\network\admin pour
configurer le nom de service réseau sans passer par l’option graphique en ajoutant les
lignes et modifiant les mots en gras :
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = TEST)
)
)

Il se lance à partir Démarrer\programmes\Oracle-OraDb10g_home1\Outils de Configuration et de Migration\

 Oracle Net Manager

33
Cet outil permet de créer le processus d’écoute( Listener) ,un nom de service Réseau (dans le tnsname),
d’inscrire la base dans le listener.

 Comment créer un listener :

Dérouler l’arborescence Local jusqu’à se mettre sur le processus d’écoute et cliquer sur
le bouton + pour créer un listener.
 Gérer le listener :
Démarrer avec la commande :
LSNRCTL >Start
Arrêter avec la commande :
LSNRCTL >Stop
Vérifier le statut
LSNRCTL >Status

 Comment créer un nom de service réseau :

Dérouler l’arborescence Local jusqu’à se mettre sur résolution de noms de service et
cliquer sur le bouton +
Sur la fenêtre suivante entrer le nom de service réseau, faire suivant, choisir le
TCP/IP(Protocole internet), Entrer le nom d’hôte, entrer le nom de la Base de Données,
cliquer sur terminer.
 Comment inscrire une base de données dans le listener :

Dérouler l’arborescence Local jusqu’à se mettre sur le listener et dans le menu à droit
emplacements d’écoute, choisir Services de Base de Données et cliquer sur le bouton

34
 ajouter une base de données qui est en bas, dans nom global entrer le nom de la base,
entrer le répertoire d’origine d Oracle Home et enfin introduit le nom d’instance.

Toute fois Pour inscrire une nouvelle base de données sans option graphique
Ouvrer le Listener dans le répertoire : Oracle_home\network\admin, en ajoutant les lignes :
(SID_DESC =
(GLOBAL_DBNAME = ESSAI)
(SID_NAME = ESSAI)
)

Il se lance à partir Démarrer\programmes\Oracle-OraDb10g_home1\Outils de Configuration et de Migration\

 Assistant Mise à Niveau de Base de données :

Permet la Mise à niveau de la base

Chp4 : Administrer les utilisateurs et leurs profiles

35
 I. Gérer les utilisateurs graphiquement

Profils et utilisateurs

Les profils imposent un ensemble nommé de limites concernant l'utilisation de la base de données et les
ressources des instances. Les profils imposent également des limitations concernant les mots de passe des
36
utilisateurs (longueur, période d'expiration, etc.). Chaque utilisateur est affecté à un profil et ne peut appartenir
qu'à un seul profil à la fois.

Le profil par défaut sert de base pour tous les autres profils. Comme vous pouvez le voir dans la diapositive ci-
dessus, les limitations concernant un profil peuvent être définies implicitement (CPU/Session), être illimitées
(CPU/Call) ou faire référence à des paramètres du profil par défaut (Connect Time).

Les profils ne peuvent imposer des limitations de ressources aux utilisateurs que si la valeur TRUE est
affectée au paramètre RESOURCE_LIMIT. Avec la valeur par défaut (FALSE) de RESOURCE_LIMIT, les
limitations des profils sont ignorées.

Les profils permettent à l'administrateur de contrôler les ressources système suivantes :

• CPU. Les ressources CPU peuvent être limitées par session ou par appel. Une limite
CPU/Session de 1000 signifie que si une session individuelle qui utilise ce profil
consomme plus de 10 secondes de temps CPU (les limitations du temps CPU étant
exprimées en centièmes de seconde), cette session reçoit une erreur et est
déconnectée :

ORA-02392: exceeded session limit on CPU usage, you are being logged off

Authentification des utilisateurs

L'authentification consiste à vérifier l'identité d'une entité (utilisateur, périphérique ou autre) qui souhaite
utiliser les données, les ressources ou les applications. La validation de cette identité établit une relation de
confiance pour les interactions ultérieures. L'authentification permet également la responsabilisation, car il est
possible de lier l'accès et les actions à des identités spécifiques. Après l'authentification, le processus
d'autorisation peut autoriser l'accès et les actions par cette entité, ou les limiter.

Lorsque vous créez un utilisateur, vous devez décider de la technique d'authentification à utiliser, laquelle
pourra être modifiée ultérieurement.

37
Password : ce mode, également appelé authentification par la base de données Oracle, crée chaque
utilisateur avec un mot de passe associé qui doit être fourni lorsque l'utilisateur tente d'établir une connexion.
Lorsque vous définissez un mot de passe, vous pouvez le configurer afin qu'il expire immédiatement, ce qui
oblige l'utilisateur à le changer lors de la première connexion. Dans ce cas, assurez-vous que les utilisateurs
ont la possibilité de changer le mot de passe. Certaines applications n'offrent pas cette possibilité.

Privilèges

Un privilège est le droit d'exécuter un type particulier d'instruction SQL ou d'accéder à un objet d'un autre
utilisateur. Oracle autorise le contrôle très fin de ce que les utilisateurs peuvent ou ne peuvent pas faire dans
la base de données. Les privilèges sont répartis en deux catégories :

• Privilèges système. Chaque privilège système autorise un utilisateur à effectuer une

opération particulière ou une classe d'opérations particulières sur la base de
données ; par exemple, le privilège de créer des tablespaces est un privilège
système. Les privilèges système peuvent être accordés par l'administrateur ou par
quelqu'un à qui la permission d'administrer le privilège a été accordée explicitement.
Il existe plus de 100 privilèges système distincts.

• Privilèges objet. Les privilèges objet permettent à un utilisateur d'effectuer une action
particulière sur un objet spécifique, tel qu'une table, une vue, une séquence, une
procédure, une fonction ou un package. Sans permission spécifique, les utilisateurs
ne peuvent accéder qu'à leurs propres objets. Les privilèges objet peuvent être
38
 accordés par le propriétaire d'un objet, par l'administrateur ou par quelqu'un à qui la
permission d'accorder des privilèges sur l'objet a été accordée explicitement.

39
Rôles

Dans la plupart des systèmes, il est trop fastidieux d'accorder de manière individuelle les privilèges
nécessaires à chaque utilisateur et le risque d'erreur est trop important. Oracle permet la gestion facile et
contrôlée des privilèges par l'intermédiaire de rôles. Les rôles sont des groupes nommés de privilèges liés qui
sont accordés aux utilisateurs ou à d'autres rôles. Ils sont conçus pour faciliter l'administration des privilèges
dans la base de données, et donc améliorer la sécurité.

Caractéristiques des rôles

• Les privilèges sont accordés aux rôles (et révoqués) comme si le rôle était un
utilisateur.

• Les rôles peuvent être accordés aux utilisateurs ou à d'autres rôles (et révoqués)
comme s'il s'agissait de privilèges système.
40
 • Un rôle peut être constitué de privilèges système et objet.

• Un rôle peut être activé ou désactivé pour chaque utilisateur auquel le rôle est
accordé.

• L'activation d'un rôle peut nécessiter un mot de passe.

• Les rôles n'appartiennent à personne et ne résident dans aucun schéma.

Qu'est-ce qu'un schéma ?

Un schéma est un ensemble d'objets de base de données appartenant à un utilisateur particulier. Un schéma
porte le même nom que l'utilisateur auquel il appartient. Les objets de schéma sont les structures logiques qui
font directement référence aux données de la base. Les objets de schéma incluent des structures telles que
des tables, des vues et des index.

Remarque : Il n'existe pas de relation entre un tablespace et un schéma. Les objets du même schéma
peuvent résider dans différents tablespaces et un tablespace peut contenir des objets de différents schémas.

Vous pouvez créer et manipuler les objets de schéma à l'aide de code SQL ou de l'application Enterprise
Manager. Lorsque vous utilisez Enterprise Manager, le code SQL sous-jacent est généré pour vous.

II. Gestion des Utilisateurs en ligne de commande

41
  Syntaxe complète de l'ordre CREATE USER

Voici une explication de tous les mots clé.

Utilisateur : Login du futur utilisateur (voir paragraphe 1.2)
IDENTIFIED BY mot de passe : Active l'authentification par la base de données avec le mot de passe
spécifié.
IDENTIFIED EXTERNALLY : Active l'authentification par le système d'exploitation
IDENTIFIED GLOBALLY AS 'nom externe' : Active l'authentification par un LDAP externe.
DEFAULT TABLESPACE nom du tablespace : Permet d'attribuer un TABLESPACE de données par défaut
à l'utilisateur.
TEMPORATY TABLESPACE nom du tablespace : Permet d'attribuer un TABLESPACE temporaire par
défaut à l'utilisateur.
QUOTA options ON nom du tablespace : Permet de définir le quota d'espace attribué à l'utilisateur sur un
TABLESPACE précis.
PROFILE nom du profil : Permet d'attribuer un profil limitant les ressources système de l'utilisateur.
PASSWORD EXPIRE :
Permet de faire expirer le mot de passe de l'utilisateur pour que celui-ci le change lors de la première
connexion.
ACCOUNT LOCK / UNLOCK : Permet d'activer ou de désactiver un compte utilisateur.
Exemple
CREATE USER Helyos
IDENTIFIED BY mypass1
DEFAULT TABLESPACE tbs_users
QUOTA 10M ON tbs_users
TEMPORARY TABLESPACE tmp_users
QUOTA 5M ON tmp_users
QUOTA 5M ON tools
PROFILE app_user
PASSWORD EXPIRE;

42
  Modifier un Utilisateur
Il est possible de modifier un utilisateur à l'aide de la commande ALTER USER :
ALTER USER bob IDENTIFIED BY bob123;
Change le mot de passe de l'utilisateur bob.
La même commande permet d'expirer le mot de passe d'un utilisateur :
ALTER USER bob PASSWORD EXPIRE ;
On peut de la même façon modifier les quotas des utilisateurs :
ALTER USER bob QUOTA 0 ON DATA_02 ;
La valeur 0 (zéro) supprime tous les droits de l'utilisateur sur le tablespace spécifié derrière le mot-clé "ON".
Toutes les options disponibles dans la commande CREATE USER sont modifiables par la commande ALTER
USER.
 Supprimer un Utilisateur
Voici la structure complète d'un ordre DROP USER :

Voici une explication de tous les mots clé.

Utilisateur : Login de l'utilisateur à supprimer.

CASCADE : Permet de supprimer le contenu du schéma de l'utilisateur qui sera supprimé.

Consulter les vues suivantes pour les Informations sur les utilisateurs
DBA_USERS, DBA_TS_QUOTAS
1. Gestion des profiles
Un profil est un ensemble de restrictions associé à un utilisateur. Ces limitations rentrent pleinement dans le
cadre de l'administration de la base car une bonne gestion des utilisateurs est nécessaire pour un bon
fonctionnement global de la base. Ces restrictions peuvent être de plusieurs types :
- Allocation d'un temps limite processeur
- Limitation du temps d'inactivité d'un utilisateur
- Limitation de l'espace mémoire
- Limitation du temps de connexion et du nombre de connexion simultanée
- Limitation d'opération d'Entrée/Sortie
- Restrictions quant aux mots de passe (durée, vérification de la complexité, ...)
- Verrouillage d'un compte utilisateur
Oracle crée un profil par défaut lors de l'installation. Ce profile DEFAULT ne limite aucune ressource. Par
défaut, lors de la création d'un utilisateur, c'est le profil DEFAULT qui est assigné à un utilisateur. Par défaut,
tous les utilisateurs ne sont en aucune façon limités.
 Les options de création d'un Profile

Limitation mot de passe :

Option Description
Ce paramètre permet de définir le nombre maximal de tentatives de connexion. Si
le nombre de connexion donné par le paramètre FAILED_LOGIN_ATTEMPTS est
FAILED_LOGIN_ATTEMPTS
atteint le compte sera alors verrouillé pendant une période donnée par le
paramètre PASSWORD_LOCK_TIME
Ce paramètre permet de définir la durée d'utilisation du même mot de passe. Ce
PASSWORD_LIFE_TIME
paramètre devra être défini en jours. Une fois la date limite d'utilisation, Oracle
43

PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME
PASSWORD_VERIFY_FUNCTION
Les limitations des ressources système
Option
SESSIONS_PER_USER
CPU_PER_SESSION
CPU_PER_CALL
CONNECT_TIME
44
demandera alors automatiquement à l'utilisateur de bien vouloir changer son mot
de passe.
Ce paramètre défini en nombre de jours, permet de définir le délai entre deux
utilisations du même mot de passe. Par exemple si celui ci vaut 30 et que votre
mot de passe actuel est toto. Il vous faudra attendre 30 jours à compter de la date
de votre changement de mot de passe avant de pouvoir à nouveau utiliser toto
comme mot de passe.
Si vous donner une valeur numérique au paramètre PASSWORD_REUSE_TIME
vous devrez alors donner la valeur UNLIMITED au paramètre
PASSWORD_REUSE_MAX.
Ce paramètre permet de définir le nombre de réutilisation du même mot de passe
(consécutive ou non).
Si vous donner une valeur numérique au paramètre PASSWORD_REUSE_MAX
vous devrez alors donner la valeur UNLIMITED au paramètre
PASSWORD_REUSE_TIME.
Ce paramètre permettra de définir la durée de verrouillage du compte utilisateur
après avoir bloqué le compte avec le paramètre FAILED_LOGIN_ATTEMPTS. Le
compte sera alors automatiquement déverrouillé lorsque le temps défini par ce
paramètre sera atteint. Ce paramètre sera défini en jours (Vous pouvez aussi
spécifier un nombre de minutes ou heure, par exemple 30 minutes donnera
30/1440) ou pourra avoir la valeur UNLIMITED (pour un verrouillage définitif et
donc une action d'un administrateur pour débloquer le compte)
Ce paramètre permet de définir en jours le temps de grace qui vous sera alloué
pour changer votre mot de passe. Par exemple vous avez défini le paramètre
PASSWORD_LIFE_TIME à 30 ce qui signifie que l'utilisateur devra changer son
mot de passe tout les 30 jours. Cependant si celui-ci décide pour une raison ou
une autre de ne pas changer son mot de passe à la fin de cette période Oracle
bloquera son compte automatiquement au bout de 3 demandes.
L'intérêt de ce paramètre est d'ajouter une période de grâce pendant laquelle
l'utilisateur sera en mesure de ne pas changer son mot de passe. Cela revient à
donner un délai supplémentaire à l'utilisateur pour changer son mot de passe.
Ce paramètre devra contenir le nom d'une fonction PL/SQL qui servira à vérifier
les mots de passe saisi. Vous pouvez utiliser celle fournie par Oracle (script
utlpwdmg.sql). La fonction fournie en argument devra avoir cette définition :
<nom de la fonction> (username varchar2, password varchar2, old_password
varchar2) RETURN boolean
Si vous ne souhaitez pas utiliser de fonction de vérification utiliser la valeur NULL.
Description
permet de définir le nombre de session maximum qu'un utilisateur pourra ouvrir.
permet de définir le temps de processeur maximum en centièmes de secondes
qu'une session pourra utiliser.
permet de définir le temps de processeur maximum en centièmes de secondes
qu'un "appel serveur" (requête) pourra utiliser.
permet de définir le temps en minutes pour la durée de connexion maximale
d'une session. A la fin du temps imparti la session sera automatiquement
 déconnectée.
permet de définir le temps en minutes pour la durée d'inactivité maximale d'une
IDLE_TIME session. A la fin du temps imparti la session sera automatiquement
déconnectée.
LOGICAL_READS_PER_SESSION permet de définir le nombre maximal de bloc lus durant une session.
LOGICAL_READS_PER_CALL permet de définir le nombre maximal de bloc lus durant un "appel serveur".
Permet de définir le coût total des limitations autorisées pour une session.
Oracle calcule le coût total de toutes les ressources à partir du poids attribué
COMPOSITE _LIMIT
aux paramètres CPU_PER_SESSION, CONNECT_TIME,
LOGICAL_READS_PER_SESSION, et PRIVATE_SGA.
PRIVATE_SGA permet de définir la taille en Kbytes ou MBytes que pourra utiliser une session.

NB : La valeur DEFAULT est une valeur particulière, lorsque vous assignerez la valeur DEFAULT à une limitation alors
Oracle ira récupérer la valeur de la limitation dans le profil DEFAULT.

1.2. Création d'un profil

La syntaxe de création d'un profil est très simple. Voici un exemple :

CREATE PROFILE app_user

LIMIT
SESSIONS_PER_USER UNLIMITED
CPU_PER_SESSION UNLIMITED
CPU_PER_CALL 3000
CONNECT_TIME 45
IDLE_TIME 10
LOGICAL_READS_PER_SESSION DEFAULT
LOGICAL_READS_PER_CALL 1000
PRIVATE_SGA 15K
COMPOSITE_LIMIT Default
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LOCK_TIME 1;

 Assigner un Profil à un Utilisateur

Une fois que l'on a crée un profil, la commande suivante permet d'associer ce profil à un utilisateur :
ALTER USER bob PROFILE user ;
Un profil peut aussi être assigné à un utilisateur à sa création :
CREATE USER bob
IDENTIFIED BY bob123
TEMPORARY TABLESPACE TEMP
DEFAULT TABLESPACE USER
PROFILE user ;
 Activer la Limitation de Ressources
Il y a deux méthodes pour activer la limitation de ressources :
- Changer dans le fichier init<SID>.ora la valeur du paramètre RESOURCE_LIMIT à TRUE (ce paramètre
est à FALSE par défaut)
- Exécuter la commande ALTER SYSTEM RESOURCE_LIMIT = TRUE ; Dans ce cas, le paramètre
RESOURCE_LIMIT est mis à TRUE jusqu'à l'arrêt de la base ou une nouvelle mise à jour de sa valeur.
 Modification d'un Profil
Il est possible de modifier un profil par la commande :

45
 ALTER PROFILE user LIMIT
SESSIONS_PER_USER 10
IDLE_TIME 15;
Toutes les options de la commande CREATE PROFILE sont modifiables par la commande ALTER PROFILE.
 Suppression d'un Profil
Syntaxe :

Profile : nom du profil à supprimer.

CASCADE : Cette option vous permettra de supprimer le profil à tous les utilisateurs qui disposaient de ce
profil et demandera au serveur de leur assigner le profil DEFAULT.
DROP PROFILE user cascade ;
NB : le profil DEFAULT ne peut pas être supprimé.
Informations sur les Profils : consulter les : DBA_USERS, DBA_PROFILES
2. Gestion des privilèges et Rôles
 Assigner des privilèges système à un utilisateur
Lorsqu'un utilisateur est créé avec l'instruction CREATE USER, il ne dispose encore d'aucun droit car aucun
privilège ne lui a encore été assigné.
Il ne peut même pas se connecter à la base.
Il faut donc lui assigner les privilèges nécessaires.
Il doit pouvoir se connecter, créer des tables, des vues, des séquences.
Pour lui assigner ces privilèges de niveau système il faut utiliser l'instruction GRANT dont voici la syntaxe :

- Systeme_privilege représente un privilège système (liste en annexe 1) ;

- Role représente un rôle préalablement créé ;
- ALL PRIVILEGES représente tous les privilèges système (à l'exception de SELECT ANY DICTIONARY) ;
- user représente le nom de l'utilisateur qui doit bénéficier du privilège
- PUBLIC assigne le privilège à tous les utilisateurs
- WITH ADMIN OPTION assigne à l'utilisateur le droit d'assigner, de retirer, de modifier et de supprimer à
son tour les privilèges du rôle reçus.

Attention avec l'option ALL PRIVILEGES. Celle-ci accorde des droits quasi illimités à l'utilisateur qui en hérite,
avec les risques de sécurité que cela implique.
Pour que l'utilisateur puisse simplement se connecter à la base, il doit bénéficier du privilège système
CREATE SESSION
GRANT CREATE SESSION TO nom_utilisateur ;
Ensuite il faut lui assigner des droits de création de table
GRANT CREATE TABLE TO nom_utilisateur ;
46
Puis les droits de création de vues
GRANT CREATE VIEW TO nom_utilisateur ;
Et il en va de même pour tous les autres privilèges qui lui sont assignés.
L'ensemble de ces privilèges peuvent être assignés au sein d'une même commande

GRANT
CREATE SESSION
,CREATE TABLE
,CREATE VIEW
TO nom_utilisateur ;

 Assigner des privilèges objet à un utilisateur

Syntaxe :

object_privilege représente un privilège objet (liste en annexe 2)

role représente un rôle préalablement créé,
ALL PRIVILEGES représente tous les privilèges assignés à l'exécuteur de l'instruction,
column représente le nom de colonne d'une table,
Schema représente le nom d'un schéma,
Object représente le nom d'un objet du schéma,
directory_name représente le nom d'une directory
JAVA SOURCE représente le nom d'une source Java
JAVA RESOURCE représente le nom d'une ressource Java
WITH GRANT OPTION assigne à l'utilisateur de droit d'assigner à son tour le privilège reçu à un autre
utilisateur
(WITH GRANT OPTION s'applique à un utilisateur ou à PUBLIC, mais pas à un rôle)
WITH HIERARCHY OPTION assigne les privilèges aux sous-objets.
Pour assigner à l'utilisateur le droit de sélectionner, insérer, modifier et supprimer des lignes dans la table
EMP de l'utilisateur SCOTT

47
GRANT
SELECT
,INSERT
,UPDATE
,DELETE
ON SCOTT.EMP
TO nom_utilisateur ;
Une liste de colonnes peut être indiquée dans l'instruction afin de restreindre davantage les droits sur une
table
GRANT
UPDATE (JOB, MGR)
ON SCOTT.EMP
TO nom_utilisateur ;
L'utilisateur peut modifier la table SCOTT.EMP mais uniquement les colonnes JOB et MGR

Pour pouvoir mettre à jour ou supprimer des lignes d'une table, les privilèges UPDATE ET DELETE ne
suffisent pas. Le privilège SELECT est nécessaire.
Un utilisateur munis des droits DBA ne pourra pas accorder de privilèges sur un objet qui ne lui appartient pas

Principes généraux appliqués aux privilèges

 Un utilisateur possède automatiquement tous les privilèges sur un objet qui lui appartient
 Un utilisateur ne peut pas donner plus de privilèges qu'il n'en a reçu
 s'il n'a pas reçu le privilège avec l'option WITH GRANT OPTION, un utilisateur ne peut pas assigner à
son tour ce même privilège
 Créer des rôles et leur assigner des privilèges
Cet ensemble s'appelle un rôle et se créé avec l'instruction CREATE ROLE dont la syntaxe est :

ROLE représente le nom du rôle

NOT IDENTIFIED (défaut) indique qu'aucun mot de passe n'est nécessaire pour activer le rôle
IDENTIFIED BY password indique qu'un mot de passe est nécessaire pour activer le rôle
IDENTIFIED USING package indique qu'un package va être utilisé pour fixer les droits de l'utilisateur
IDENTIFIED EXTERNALLY indique que l'autorisation provient d'une source externe (S.E.)
IDENTIFIED GLOBALLY pour un user GLOBAL géré par exemple par Enterprise Directory Service

Lorsque le rôle est créé, il ne contient rien et il faut l'alimenter à l'aide d'instructions GRANT

CREATE ROLE comptabilite;

GRANT SELECT, INSERT, UPDATE, DELETE ON CPT.FACTURE TO comptabilite ;
GRANT SELECT, INSERT, UPDATE, DELETE ON CPT.LIG_FAC TO comptabilite ;
48
GRANT SELECT, INSERT, UPDATE, DELETE ON CPT.JOURNAL TO comptabilite ;
Une fois le rôle créé, il peut être assigné à un utilisateur ou à un autre rôle

GRANT comptabilite TO nom_utilisateur ;

Trois principales rôles en standard
 CONNECT
 RESOURCE
 DBA
Les privilèges système assignés au rôle CONNECT voir le resultat de cette requête :
SQL> select * from DBA_SYS_PRIVS where grantee='CONNECT' ;
Les privilèges système assignés au rôle RESOURCE voir le resultat de cette requête :
SQL> select * from DBA_SYS_PRIVS where grantee='RESOURCE' ;
Les privilèges système assignés au rôle DBA voir le resultat de cette requête :
SQL> select * from DBA_SYS_PRIVS where grantee='DBA' order by PRIVILEGE
D'une façon générale, il est fortement déconseillé d'utiliser ces rôles standards car ils accordent trop de droits
aux utilisateurs.
La liste des rôles définis est visible depuis la vue DBA_ROLES.
La liste des privilèges système assignés à un rôle s'obtient en interrogeant les vues DBA_SYS_PRIVS et
USER_SYS_PRIVS.
La liste des rôles assignés à un utilisateur s'obtient via les vues DBA_ROLE_PRIVS et USER_ROLE_PRIVS.
La liste des privilèges objet assignés à un utilisateur s'obtient en interrogeant les vues
DBA_TAB_PRIVS, ALL_TAB_PRIVS et USER_TAB_PRIVS.
La liste des privilèges objet sur les colonnes de tables assignés à un utilisateur s'obtient en interrogeant les
vues
DBA_COL_PRIVS, ALL_COL_PRIVS et USER_COL_PRIVS
 Modifier des rôles
Un mot de passe peut être ajouté à un rôle par l'instruction ALTER ROLE

IDENTIFIED permet de définir le système d'identification

NOT IDENTIFIED supprime le système d'identification
Cela permet de se prémunir de l'attribution du rôle par un utilisateur non autorisé qui tenterait de se l'attribuer
via l'instruction SET ROLE .
 Suppression d'un rôle
Un rôle peut être supprimé en utilisant l'instruction DROP ROLE

DROP ROLE nom_role ;

Le rôle spécifié ainsi que tous les privilèges qui lui sont associés sont supprimés de la base et également
retiré à tous les utilisateurs qui en bénéficiaient

49
  Retirer des privilèges système
Les privilèges système qui ont été assignés à des utilisateurs ou à des rôles peuvent être retirés avec
l'instruction REVOKE :
Syntaxe

Les arguments sont identiques à ceux décrits pour l'instruction GRANT

Pour pouvoir supprimer un privilège, il faut en avoir reçu l'autorisation avec l'option ADMIN OPTION.
L'utilisteur disposant du rôle DBA peut révoquer les privilèges CONNECT, RESOURCE, DBA ou tout autre
privilège système ou rôle.
Retirer des privilèges à un utilisateur ne supprime pas son schéma ni les objets qu'il contient
 Retirer des privilèges objet
Les privilèges objet qui ont été assignés à des utilisateurs ou à des rôles peuvent être retirés avec l'instruction
REVOKE

Chp4 : Gestion des Objets du Dictionnaire de Données

50
 I. Un schéma :

Un schéma est un ensemble d'objets de base de données appartenant à un utilisateur particulier. Un schéma
porte le même nom que l'utilisateur auquel il appartient. Les objets de schéma sont les structures logiques qui
font directement référence aux données de la base. Les objets de schéma incluent des structures telles que
des tables, des vues et des index.

Remarque : Il n'existe pas de relation entre un tablespace et un schéma. Les objets du même schéma
peuvent résider dans différents tablespaces et un tablespace peut contenir des objets de différents schémas.

Vous pouvez créer et manipuler les objets de schéma à l'aide de code SQL ou de l'application Enterprise
Manager. Lorsque vous utilisez Enterprise Manager, le code SQL sous-jacent est généré pour vous.

 Accéder aux objets de schéma

Vous pouvez accéder rapidement à de nombreux types d'objet de schéma à partir de la région Schéma de la
page Database Administration.

II. Les Tables

 Les types de données

Définir des types de données pour les tables

Lorsque vous créez une table, vous devez indiquer un type de données pour chacune de ses colonnes.
Lorsque vous créez une procédure ou une fonction, vous devez indiquer un type de données pour chacun de
ses arguments. Ces types de données définissent le domaine des valeurs que chaque colonne peut contenir
ou que chaque argument peut comporter.

Voici quelques-uns des types de données intégrés d'Oracle Database :

• CHAR(size) : chaîne de caractères de longueur fixe, dont la longueur est de size

octets. La taille maximale est de 2 000 octets. La taille par défaut et minimale est de
1 octet.
51
 • VARCHAR2(size) : chaîne de caractères de longueur variable, dont la longueur
maximale est de size octets. La taille maximale est de 4 000 octets. Vous devez
impérativement indiquer la taille pour le type de données VARCHAR2.

• DATE : plage de dates valide, comprise entre le 1er janvier 4712 avant J.-C. et le
31 décembre 9999 après J.-C. ; ce type de données contient également l'heure, avec
une précision d'une seconde.

• NUMBER : nombre dont la précision est p et l'échelle s. La précision peut être

comprise entre 1 et 38. L'échelle peut être comprise entre -84 et 127.

Reportez-vous au manuel Oracle Database SQL Reference pour la liste complète des types de données
intégrés et des types de données définis par l'utilisateur.

 Creation d’une table

La forme simple de création de table est:

CREATE TABLE nom

(Col1 Type [lg] [NOT NULL] [Col_contrainte],
Col2 Type [lg] [NOT NULL] [Col_contrainte],
…
Coln Type [lg] [NOT NULL] [Col_contrainte],
[table_contrainte]);

Une table peut comporter jusqu'à 254 colonnes et une seule de type LONG.
Le nombre de tables qu'il est possible de définir dans une base est de 65535.
Syntaxe.
CREATE TABLE nom_table (
nom_colonne1 type_donées [NOT NULL],
…
nom_colonneN type_donnes [ NOT NULL],
[Constraint nom_contratinte]
[Primary key (nom_colonneA, nom_colonneB,.., nom_colonneX)],
[Constraint nom_contratinte_FK Foreign key (nom_colonneF1, …, nom_colonneFN)
references table_reference (nom_colonneP1,…, colonnePN])
[TABLESPACE nom_tbs]
[ STORAGE ([INITIAL taille K | M] [NEXT taille K | M] [MINEXTENTS taille K | M] [MAXEXTENTS taille K | M]
[PCTINCREASE pct ] )] ;
EXEMPLE

CREATE TABLE emp1 (

empno NUMBER(5) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
job VARCHAR2(10),
mgr NUMBER(5),
hiredate DATE DEFAULT (sysdate),
sal NUMBER(7,2),

52
 comm NUMBER(7,2),
deptno NUMBER(3) NOT NULL
CONSTRAINT dept_fkey REFERENCES dept)
PCTFREE 10
PCTUSED 40
TABLESPACE users
STORAGE ( INITIAL 50K
NEXT 50K
MAXEXTENTS 10
PCTINCREASE 25 );

Contraintes d'intégrités sur les colonnes.

colonne [NULL] | [NOT NULL [CONSTRAINT nom]]
[UNIQUE|PRIMARY KEY [CONSTRAINT nom]]
[REFERENCE table [(colonne)] [CONSTRAINT nom]]
[CHECK (condition) [CONSTRAINT nom]]

Différences entre clé primaire et colonne unique.

PRIMARY KEY UNIQUE
Toutes les valeurs sont distinctes OUI OUI
La colonne est définie en NOT NULL OUI OUI
Défini l'identifiant OUI
précisé une seule fois par table OUI
fait lien avec REFERENCE OUI
 Création simple.
On peut créer une table par la commande CREATE TABLE en spécifiant le nom et le type de chaque
colonne.
A la création, la table sera vide. Cependant un certain espace lui sera alloué.

Exemple: CREATE TABLE salarie

53
 ( empno NUMBER(6) NOT NULL, ename VARCHAR2(10),
job VARCHAR2(9), mgr NUMBER(6),
hiredate DATE,sal NUMBER(10,2) ,
comm NUMBER(9,0) , deptno NUMBER(2));

Remarques : L'option NOT NULL assure qu'Oracle interdira lors d'un INSERT ou d'UPDATE que cette
colonne contienne la valeur NULL qui est la valeur par défaut.
 Création avec insertion de données.

On peut insérer des données dans la table lors de sa création, en utilisant la syntaxe suivante:

CREATE TABLE table

(col1 [NOT NULL],
col2 [NOT NULL],
...,
coln [NOT NULL])
AS SELECT table2.col1,
table2.col2,
...,
table2.coln
FROM table2;
On peut ainsi par un seul ordre SQL créer une table et la remplir à partir de données provenant d'un
SELECT. On ne spécifie pas le type des colonnes, les types de données seront ceux provenant du
SELECT ainsi que l'option NOT NULL.
Par compte, on peut nommer les colonnes, par défaut le nom des colonnes est le nom des colonnes
ramenées par le SELECT (si le SELECT ramène une expression, elle devra être nommée).
Le nombre de colonnes citées dans le CREATE et le SELECT doivent être égal.
Le SELECT peut contenir des fonctions de groupe ou un GROUP BY mais pas de clause ORDER BY.
 Modification d'objet de type table.
Oracle offre la possibilité de modifier dynamiquement la définition d'une table pour:

Ajouter une colonne.

Ajouter une contrainte d'intégrité.
Redéfinir une colonne (type de donnée, taille, valeur par défaut..).
 Modifier les caractéristiques de stockage.
 Ajout de colonnes et contraintes.
ALTER TABLE nom_table
ADD (Col1 type [contrainte],
......
Coln type [contrainte]);

Exemple:> ALTER TABLE MANAGER

ADD (sexe CHAR(1) default 'M' not null);
 Modification de colonnes.
ALTER TABLE nom_table
MODIFY (Col1 type,
......
54
 Coln type);
Exemple: ALTER TABLE MANAGER
Modify (sal number (8,2), ename not null);
 suppression de contraintes
ALTER TABLE nom_table
DROP CONSTRAINT nom;
 Suppression d'objet de type table.
Une commande SQL permet de supprimer une table. Les lignes de la table ainsi que la définition elle-
même de la table sont détruites, l'espace occupé par la table est libéré.
Syntaxe.

Exemple: drop table manager;

 RENOMMER un objet de type table.

Une commande SQL permet de donner un nouveau nom à un objet de type table, vue ou synonyme. Si
une table a été renommée, les vues qui étaient créées à partir de l'ancien nom ne pourront plus
s'exécuter.
Syntaxe.

Exemple: rename EMP to salarie;

III. Les index :

Les index sont des structures facultatives associées aux tables. Elles peuvent être créées afin d'améliorer les
performances de l'extraction des données. Un index Oracle fournit un chemin d'accès direct vers les données
des tables.

Les index peuvent être créés sur une ou plusieurs colonnes d'une table. Une fois un index créé, il est
automatiquement géré et utilisé par le serveur Oracle. Les mises à jour des données d'une table, telles que
l'ajout, la mise à jour ou la suppression de lignes, sont automatiquement propagées vers tous les index
appropriés, de manière totalement transparente pour l'utilisateur qui apporte la modification.

Vous pouvez cliquer sur le lien Indexes sous l'en-tête Schema de la page Administration afin d'afficher la page
Indexes. Vous pouvez afficher les attributs des index ou utiliser le menu Actions pour afficher les
dépendances (View Dependencies) d'un index.

Les index peuvent être créés explicitement, ou implicitement par l'intermédiaire de Contraintes placées sur
une table.

 Création d'index.

55
Syntaxe.

Un index peut être créé sur une table contenant déjà des lignes. Il sera ensuite tenu à jour
automatiquement lors des modifications de tables.
Il est préférable de créer la table, de la renseigner puis de créer les index plutôt que de créer la table,
les index et de renseigner la table. Les index seront mieux équilibrés.
Exemples: create index ideptno on emp (deptno);
CREATE INDEX article_idx ON article
PCTFREE 10
STORAGE (INITIAL 64K NEXT 64K PCTINCREASE 50 MAXEXTENTS 500)
TABLESPACE IDX ;
 Suppression d'un index.
Syntaxe.

 Modification d’indexe
o Modifications des paramètres de stockage d'index
ALTER INDEX article_idx STORAGE (NEXT 200K MAXEXTENTS 200) ;
Il est aussi possible de modifier les paramètres de concurrence des index INITRANS et MAXTRANS.
o Allocation - Désallocation d'Extents
Avant une insertion importante de données, il peut être intéressant, comme pour les tables, de préallouer des
extents par la commande :
ALTER INDEX article_idx ALLOCATE EXTENT (SIZE 500K DATAFILE '/disk5/index_01.dbf') ;
On peut aussi désallouer les extents vides :
ALTER INDEX article_idx DEALLOCATE UNUSED;
o Reconstruction d'index
Il est possible de reconstruire des index avec la commande :
ALTER INDEX article_idx REBUILD TABLESPACE IDX_02 ;
Cette commande est utilisée lorsque :
- Un index doit être déplacé vers un autre tablespace
- Un index contient beaucoup d'entrées supprimées. Ce qui est le cas après certaines purges par
exemple.
56
 - Un index B-tree peut être transformé en un index inversé et vice versa.
Une reconstruction d'index exécute les tâches suivantes :
- Lorsque l'on reconstruit un index, les utilisateurs peuvent continuer à l'utiliser car le nouvel index est
crée à part à partir du précédent index et celui-ci remplace le nouvel index une fois crée.
- Elle supprime physiquement les entrées d'index ce qui permet d'avoir des index bien plus efficaces.
Comme la reconstruction d'index se base sur un index déjà existant, il n'y a pas besoin de faire des tris.
 Utilisation des index.
Les index peuvent être utilisé si:
 La colonne indexée est référencée dans un prédicat.
 Une fonction ou une expression n'altère pas cette colonne dans le prédicat.
Les index sont mis à jour automatiquement par Oracle lors des ordres LMD (INSERT, UPDATE et
DELETE).
Il faut indexer :
 Les colonnes servant d'identifiant (index) unique (clé primaire).
 Les colonnes de jointure avec une autre table (clé étrangère).
 Les colonnes servant souvent de clé d'accès dans les prédicats.

Il ne faut pas indexer :

 Les colonnes souvent modifiées.
IV. Les vues

Les vues sont des représentations personnalisées des données d'une ou plusieurs tables ou autres vues. Il
s'agit en quelque sorte d'interrogations stockées. Les vues ne contiennent pas de données à proprement
parler ; leurs données sont issues des tables sur lesquelles elles sont basées. Ces tables sont appelées tables
de base de la vue.

 Données et contraintes.
Les données sont de type identique aux données des tables.
La clause WITH CHECK OPTION permet d'assurer la cohérence des informations modifiées.
 Création de vues.
Syntaxe.

La spécification des noms de colonnes de la vue est facultative. Par défaut, les colonnes de la vue ont
pour nom, les noms des colonnes issus du SELECT.
Le SELECT servant à créer la vue ne peut pas contenir les clauses ORDER BY et CONNECT BY.
L'ordre SQL de création de la vue sera exécuté à chaque appel de la vue.

Exemple: create view dept_10

57
 as select empno, ename,job
from emp
where deptno = 10;
 Interrogation à travers une vue.
Une vue peut être référencée dans un SELECT au même titre qu'une table.

Tout se passe comme si la table, virtuelle, existait réellement bien que reconstituée à chaque appel de
la vue.
Exemple:> select * from dept_10;
 Mise à jour à travers une vue.
Il est possible d'effectuer des mises à jour au travers de vues, sous certaines conditions.

Type de vue crée DELETE UPDATE INSERT

Avec jointure. NON NON NON
Avec GROUP BY ou DISTINCT. NON NON NON
Avec référence à ROWNUM. NON NON NON
Avec une colonne issue d'une expression. OUI OUI  OUI 
Avec au moins une des colonnes NOT NULL absente OUI OUI NON

Ne pas oublier la clause WITH CHECK OPTION qui contrôle l'intégrité en interdisant par exemple
d'insérer des lignes ou de modifier des lignes qui ne feraient pas ou plus partie de la vue.
Exemple: SQLWKS> update dept_10
Set JOB = 'ANALYST'
Where job is null;

 Modification d'une vue.

Il n'est pas possible d'appliquer la commande ALTER vue pour modifier les caractéristiques
de la vue. Il est nécessaire de la commande create or replace view pour modifer une vue.
 Suppression d'une vue.
Une vue peut être détruite par l'utilisation de la commande DROP.
Syntaxe.

 Renommer une vue.

Une vue peut être renommée par l'utilisation de la commande RENAME.
Syntaxe.

V. Les Séquences

Qu'est-ce qu'une séquence ?


OUI sur les autres colonnes.

OUI sur les autres colonnes.
58
Une séquence est un objet de base de données à partir duquel différents utilisateurs peuvent générer des
entiers uniques. Les séquences sont généralement utilisées pour générer des valeurs de clé primaire.

• Name : utilisez les règles d'appellation étudiées précédemment pour nommer

une séquence.

• Schema : propriétaire de la séquence.

• Type : une séquence peut être croissante ou décroissante.

• Maximum Value : indiquez la valeur maximale que la séquence peut générer. Cette valeur
entière peut comporter 28 chiffres ou moins. Elle doit être supérieure aux valeurs Minimum
Value et Initial. L'option Unlimited indique une valeur maximale de 1027 pour une séquence
croissante et de -1 pour une séquence décroissante. La valeur par défaut est Unlimited.

• Minimum Value : indiquez la valeur minimale de la séquence. Cette valeur entière peut
comporter 28 chiffres ou moins. Elle doit être inférieure ou égale à Initial, et inférieure à
Maximum Value. L'option Unlimited indique une valeur minimale de 1 pour une séquence
croissante et de -1026 pour une séquence décroissante. La valeur par défaut
est Unlimited.

Lorsque vous cliquez sur l'un des liens, la page Results s'affiche. Dans la région Search de la page, vous
pouvez entrer un nom de schéma et un nom d'objet afin de rechercher un objet spécifique. En outre, vous
pouvez rechercher d'autres types d'objet via la région Search, en sélectionnant le type d'objet dans le menu
déroulant. Le menu déroulant inclut des types d'objet qui ne sont pas présentés sous forme de liens dans la
page Database Administration.

 Création de séquences.
Les séquences sont des données de type numérique.
Syntaxe.

Pseudo-colonnes utilisables.
Deux variables peuvent être utilisées pour obtenir les valeurs de la séquence.
 CURRVAL numéro de séquence en cours.
 NEXTVAL prochaine valeur
Exemples: CREATE SEQUENCE eseq

59
 INCREMENT BY 10
START with 5000;
 Modification de séquences.
Le but est de modifier les paramètres d'une séquence existante.
Syntaxe.

Exemples: alter SEQUENCE eseq

INCREMENT BY 5;

 Utilisation de séquences
Insert into emp (empno,ename,deptno) values (eseq.nextval,'ALTER1 SEQ',40);
 Suppression de séquences.
Syntaxe.

VI. Les Synonymes

 Définition.
Il s'agit de référencer un objet différemment en lui donnant un autre nom.
Il est possible d'affecter un synonyme à un objet de type:
 Table.
 Vue.
 Séquence.
 Synonyme.
 Création de synonyme.
Syntaxe.

Examples
Creation du synonyme public Employees pour la table employees du schéma Hr de la base de donnés Sales
CREATE PUBLIC SYNONYM employees
FOR hr.employees@sales;

60
  Suppression de synonyme.
Syntaxe.

I.1.1.1.1.1.1 Database links

Il permet au sein d'une même session SQL d'accéder à différents objets de bases réparties sur le réseau. On
peut par exemple définir un database link compta_bordeaux qui référence le schéma compta qui se trouve sur
la base distante localisée sur le serveur de bordeaux. Ensuite on pourra accéder à une table ou vue distante
via ce database link. Une description des database links se trouve dans la vue USER_DB_LINKS du
dictionnaire.
CREATE [SHARED] [PUBLIC] DATABASE LINK dblink
[ CONNECT TO { CURRENT_USER | user IDENTIFIED BY password [authenticated_clause] }
| authenticated_clause
]
[USING 'connect_string'];
 Example avec Utilisateur Courant
CREATE DATABASE LINK sales.hq.acme.com
CONNECT TO CURRENT_USER
USING 'sales';
 Example avec un utilisateur fixé
CREATE DATABASE LINK sales.hq.acme.com
CONNECT TO hr IDENTIFIED BY hr
USING 'sales';
 Manipulation du lien de base de données

SELECT * FROM employees@sales.hq.acme.com;

INSERT INTO orders@sales.hq.acme.com

(customer_id, order_id, order_total)
VALUES (5001, 1235, 2000);

UPDATE orders@sales.hq.acme.com
SET order_total = order_total + 500;

DELETE FROM order_id@sales.hq.acme.com

WHERE order_id = 2443;

Chp 5 : Sauvegarde et Restauration

 Différents Modes d’archive de bases de données

a. Mode no Archive
Par défaut, une base Oracle est créée en mode NOARCHIVELOG. Ce mode n'archive pas les Redo Logs une
fois rempli ce qui fait que les fichiers Redo Log écrasés sont perdus. Il est donc impossible de restaurer les
données alors écrasées.
b. Mode Archive
61
Le mode Archivelog permet d'archiver les fichiers Redo Logs "pleins" afin de pouvoir rejouer toutes les
transactions effectuées sur la base dans une période donnée. Une fois qu'un Redo Log est rempli, le
processus ARCH archive dans un (ou plusieurs) répertoire(s) ces fichiers Redo Log.
o Configuration pour Archivage
Plusieurs paramètres sont nécessaires pour le fonctionnement du mode Archivelog :
- LOG_ARCHIVELOG_DEST : spécifie le répertoire dans lequel seront archivés les fichiers Redo Log
remplis
- LOG_ARCHIVE_FORMAT : format du nom des archives.
- L'option %s ou %S indique le numéro de séquence de fichier Redo Log
- LOG_ARCHIVE_START = TRUE : lance la paramètre ARCH qui est le processus background qui archive
les fichiers Redo Log remplis.
Depuis la version 8, il est possible d'archiver les fichiers Redo Logs remplis dans deux répertoires différents
grâce au paramètre LOG_ARCHIVE_DUPLEX_DEST. En version 8i, il est possible d'archiver dans 5
répertoires différents (et notamment en traversant des réseaux et notamment Internet); il est possible de
lancer en parallèle jusqu'à 10 processus ARCH.
o Passage en Mode Archivelog
Plusieurs conditions doivent être réunies pour passer une base en mode Archivelog : le processus
background ARCH doit être lancé et la base doit passer en MODE Archivelog. La procédure est la suivante:
1. Insérer la ligne LOG_ARCHIVE_START = TRUE dans le fichier init<SID>.ora
2. Connecter à l’instance avec INTERNAL : Connect Internal/mot_passe
3. Mountez la base de données
STARTUP MOUNT pfile=$ORACLE_HOME/dbs/init.ora
4. Modifier le mode de la base (sous Server Manager)
ALTER DATABASE ARCHIVELOG
ALTER DATABASE Open
5. Fermez la base en mode NORMAL et IMMEDIATE
SHUTDOWN IMMEDIATE
5. Effectuez une sauvegarde complète de la base
Il est aussi possible de démarrer manuellement le process ARCH avec la commande
ALTER SYSTEM ARCHIVE LOG START TO '/disk02/sauve/arch' ;
Cette façon de procéder obligera le DBA à démarrer le process ARCH manuellement à chaque redémarrage
de la base.
La commande ALTER SYSTEM ARCHIVE LOG STOP désactivera le process ARCH manuellement.
o Informations sur le Mode de Fonctionnement de la Base de Données
- La commande ARCHIVELOG LIST lancée sous Server Manager permet d'avoir toutes les informations
sur le mode de focntionnement de la base de données.
- V$ARCHIVED_LOG : informations de log archivés
- V$ARCHIVE_DEST : répertoire(s) pour les Redo Logs archivés
- V$LOG_HISTORY : informations sur les Redo Logs
- V$DATABASE : statut de l'archivage
II. Sauvegardes Physiques
II.1 Sauvegarde complète base à FROID
Par définition une sauvegarde à froid se fait base fermée...
Les étapes de sauvegarde :
1 - liste de tous les fichiers physiques utiles :
fichiers de données, redologs, control files et init.ora), à l'aide des descriptions de fichiers dans le dictionnaire.
Les répertoires et noms de fichiers EXACTS seront utiles pour la restauration...
Infos utiles du dictionnaire sur la base et ses fichiers
62
Nom de la vue infos
v$database description générale de la base
DBA_TABLESPACES description des tablespaces et fichiers
DBA_DATA_FILES description des fichiers de données
v$logfile description des redologsz
info sur l'historique de tous les redos issus du control
v$log_history
file
v$log infos sur les groupes et les membres
TOUS les parametres d'init de l'instance, y compris
v$parameter
CONTROL_FILES...
v$controlfile nom des control files
2 - Arrêt de la base
on utilise le 'server manager' : ORACLE_HOME/bin/svrmgrXX (XX dépend des versions...) et les commandes
CONNECT INTERNAL
SHUTDOWN IMMEDIATE
3 - copie des fichiers sur un support externe
(bande, disque ou CD)
II.2 Sauvegardes des fichiers d'un tablespace fermé (offline), base ouverte
1) lister les fichiers appartenant au tablespace à sauvegarder (voir la vue DBA_DATA_FILES du dictionnaire).
2) mettre le tablespace offline :
SQL> ALTER TABLESPACE tbs_toto OFFLINE normal;
Vous devez pour ce faire etre DBA ou avoir le privilège système 'MANAGE TABLESPACE' .
3) sauvegarder les fichiers du tablespace listés précédemment :
SQL> HOST cp /data/fic1.dbf /sauv/fic1.dbs
SQL> HOST cp /data/fic2.dbf /sauv/fic2.dbs
SQL> HOST cp /data/fic3.dbf /sauv/fic3.dbs
4) remettre le tablespace online :
SQL> ALTER TABLESPACE tbs_toto ONLINE ;
II.3 Sauvegardes des fichiers d'un tablespace ouvert (on line), base ouverte
1) D'abord vérifier dans le dictionnaire, les spécifications de fichiers complètes composant le tablespace
concerné :
SELECT tablespace_name, file_name
FROM sys.dba_data_files
WHERE tablespace_name = 'USERS';

TABLESPACE_NAME FILE_NAME
------------------------------- --------------------
USERS /oracle/dbs/tbs_21.f
USERS /oracle/dbs/tbs_22.f
2) Marquer le début de la sauvegarde des fichiers à chaud :
ALTER TABLESPACE users BEGIN BACKUP;
3) sauvegarder les fichiers
Utiliser des commandes OS pour copier les fichiers sur une autre destination :

63
% cp /oracle/dbs/tbs_21.f /oracle/backup/tbs_21.backup
% cp /oracle/dbs/tbs_22.f /oracle/backup/tbs_22.backup
4) marquer la fin de la sauvegarde à chaud
ALTER TABLESPACE users END BACKUP;
III. Sauvegardes et Restaurations logique

Introduction
Avant tout il faut préciser que cette méthode est une méthode logique de sauvegarde (Export) et de
restauration des données (Import). Elle va nous permettre de sauvegarder le contenu logique d'une base de
données dans un fichier de transfert Oracle au format binaire, ou fichier dump. Ce fichier pourra donc être relu
pour recréer des objets qu'il contient. Ce transfert peut s'accomplir sur une même base ou même sur deux
bases Oracle, et cela même si leurs configurations matérielles et logicielles diffèrent. Cela signifie que l'on
peut tout à fait exporter une base sous Windows pour l'importer sous Linux ou Unix (sauf pour les tablespaces
transportables).
Ces deux utilitaires qui peuvent être alors employés comme des techniques de sauvegarde peuvent être
exécutés à partir de n'importe quel client NET*8 (le fichier DUMP est traité, dans ce cas, de manière locale par
rapport au client : lors d'un import ou d'un export à partir d'un client NET*8, il faut faire attention car cette
opération peut augmenter le trafic du réseau et affecter ce dernier de manière importante. Autre précision de
taille : la version de l'utilitaire Import ne peut être antérieure à celle de l'utilitaire Export, plus précisément on
ne saurait exporter une base de données Oracle 9i pour l'importer sur une base de données 8i avec leur
utilitaire d'origine. Et enfin dernier détail mais non des moindres, ne compressez jamais un fichier dump avec
un outil de compression système Winzip (Windows) ou GZIP (Linux - Unix), vous risqueriez d'avoir de
mauvaises surprises lors de sa décompression.
III 1 :Les différents modes d'export et d'import
1. Niveau base de données complète
C'est le mode le plus complet, lors de ce type d'exportation tous les objets de la base sont exportés à
l'exception de certains utilisateurs : SYS, ORDSYS, CTXSYS, MDSYS et ORDPLUGINS. Par contre les
informations relatives aux structures de base de données, telles que les définitions de tablespaces et de
segments de rollback, sont incluses. Lors de L'insertion des données tout ces objets sont importés et créés
dans la base de destination : le paramètre FULL permet de spécifier ce mode pour l'exportation et
l'importation.
2. Niveau utilisateur
Dans ce cas là, ce sont tous les objets appartenant à un utilisateur qui sont exportés: tables, fonctions,
synonymes, déclencheurs, liens de bases de données… Le paramètre OWNER permet de désigner les
utilisateurs que l'on désire exporter et le paramètre FROMUSER désigne quel est l'utilisateur à importer du
fichier Dump (le paramètre TOUSER nous indique quand à lui le schéma destinataire).
3. Niveau table
Lors de l'exportation de tables individuelles tous leurs objets associés (index, contraintes, déclencheurs,
privilèges …) sont écrits dans le fichier DUMP. Lors de l'importation tout comme l'exportation les tables
doivent être nommées grâce au paramètre TABLES.
4. Niveau tablespace
Lors de l'exportation, des métas donnés concernant les tablespaces spécifiés et les objets qu'ils contiennent
sont écrites dans un fichier DUMP.
5. Privilèges pré-requis
Actions Privilège ou rôle nécessaire
Exporter son propre schéma CREATE SESSION
Exporter d'autres schémas SYSDBA, EXP_FULL_DATABASE et DBA
Exporter la base entière ou tablespaces EXP_FULL_DATABASE

64
 Importer un objet du fichier DUMP IMP_FULL_DATABASE

III 2 : Les principaux paramètres de contrôle

Paramètres d'export
Valeur par
Paramètre Description
défaut
Userid chaîne de connexion à la base de données
Buffer Taille du buffer de transfert 4096
Compress Compression des extents en un seul Y
Contraints Export des contraintes Y
File Nom du fichier DUMP expdat.dmp
Nom du fichier de sortie du compte-rendu, pour
Log
voir les erreurs en particulier
Full Export de toute la base N
Grants Export des privilèges Y
Affiche la liste des paramètres supportés, aucun
Help N
DUMP généré.
Indexes Export des index Y
Owner Utilisateur(s) à exporter userid
Parfile Fichier contenant les paramètres d'export
Indique que l'export doit stocker les informations
Record Y
sur les exports et les objets exportés
Export incrémental (COMPLETE, CUMULATIVE,
Inctype
INCREMENTAL)
Rows Export des lignes
Tables Table(s) à exporter
Positionne sa session en " READ ONLY " le
Consistent temps de l'export. Cela permet donc de préserver N
la cohérence des données exportées.
Direct Chargement direct par tableau N
Statistics Analyse des objets exportés ESTIMATE
Point_in_time_Recover Indique si on autorise l'export des tablespaces N
Recover_Tablespaces Liste des tablespaces à sauvegarder

Paramètres d'import

65
 Valeur par
Paramètre Description
défaut
Userid chaîne de connexion à la base de données
Buffer Taille du buffer de transfert 10240
Commit Ecriture régulière des blocs de données N
File Nom du fichier DUMP expdat.dmp
Nom du fichier de sortie du compte-rendu, pour
Log
voir les erreurs en particulier
Fromuser Utilisateur à exporter vers TOUSER
Full Import de tout le contenu du DUMP N
Grants Export des privilèges Y
Affiche la liste des paramètres supportés, aucun
Help N
DUMP généré.
Ignore Ignore les erreurs et continue l'import N
Indexes Import des index Y
Parfile Fichier contenant les paramètres d'import
Rows Import des données Y
Détruit les objets s'ils existent avant de les
Destroy N
importer
Liste le contenu du fichier d'export, aucune
Show N
opération n'est effectuée dans la base.
Tables Table(s) à importer
Touser Utilisateur destinataire
Code alphabet du pays de référence s'il est
Charset NLS_LANG
différent de celui de la création de base
Point_in_time_recover Indique si on autorise l'import des tablespaces N
Permet de repousser la reconstruction de l'index
Skip_unusable_indexes N
après l'insertion des données dont ils dépendent
Exécute la commande ANALYZE dans le fichier
Analyze Y
dump

III.3 : Deux façons d'exporter et d'importer

III 3.1 : En ligne de commande
Export FULL des objets
C:\> exp userid=system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log full=y rows=n
Ici, on se connecte à la base en tant que SYSTEM (userid=system/manager) et on exporte toute la base
(full=y) sans les données (rows=n). On sauvegarde la sortie dans le fichier de log
(log=c:\control\export_full.log).
66
Voici quelques exemples suplémentaires :

Export du schéma SCOTT

C:\> exp system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log owner=scott
Export de la table ACCOUNT de l'utilisateur SCOTT
C:\> exp system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log tables=scott.account
Export du tablespace USER
C:\> exp system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log tablespaces=users
L'export de tablespace est implémenté depuis la version 8i d'Oracle et est connu sous la
dénomination de tablespace transportable.
Les exemples suivants permettent d'importer les fichiers générés dans les exemples précédents.

Import du schéma SCOTT

C:\> imp scott/tiger file=c:\backup\export_full.dump
log=c:\control\export_full.log
Import du schéma SCOTT dans le schéma TEST
C:\> imp system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log fromuser=scott touser=test
l'utilisateur de connexion (indiqué dans userid) doit naturellement être autorisé à créer les objets
dans le shéma TEST.
Import de la table ACCOUNT de l'utilisateur SCOTT dans TEST
C:\> imp system/manager file=c:\backup\export_full.dump
log=c:\control\export_full.log fromuser=scott touser=test tables=scott.account
Import de tous les schémas inclus dans le DUMP
C:\> imp system/manager file=c:\backup\export_full.dump full=y
log=c:\control\export_full.log
III 3.2 : En utilisant un fichier de paramètres
Nous avons pu voir dans les exemples précédents que la ligne de commande peut devenir très fastidieuse à
écrire. Afin de faciliter la maintenance des scripts, les utilitaires d'export et import permettent d'indiquer un
fichier de paramètres via l'option parfile.
Ainsi ce fichier est simplement l'énumération des paramètres à appliquer. Avec le fichier
c:\backup\parfile.prm suivant :
userid=system/manager
file=c:\exp_scott.dmp
log=c:\exp_scott_log.txt
owner=scott
rows=n
Les commandes suivantes sont équivalentes :
exp system/manager file=c:\exp_scott.dmp log=c:\exp_scott_log.txt
owner=scott rows=n

- OU -

67
exp parfile=c:\backup\parfile.prm
imp system/manager file=c:\exp_scott.dmp log=c:\exp_scott_log.txt
owner=scott rows=n
- OU -
imp parfile=c:\backup\parfile.prm ;

III.4 : SQL*Loader
SQL*Loader est, comme son nom l'indique un utilitaire de chargement spécifique pour les bases Oracle. Il
permet d'initialiser une base de données, ou plus précisément une ou plusieurs tables avec des données
issues d'un fichier texte.
Ainsi si l'on souhaite migrer des données d'un fichier Mainframe vers Oracle, on pourra extraire les données
du fichier d'origine pour produire un fichier texte et ensuite utiliser SQL*loader pour effectuer le chargement
automatique de la (ou des) table(s).

La (ou les) table(s) destination sont créées dans le schéma cible.

On précise le format des entrées et des sorties dans un fichier de paramétrage, appelé fichier de contrôle,
créé avec un éditeur de texte. Un fichier log donnant les résultats du chargement est généré. En cas d'erreur,
les enregistrements rejetés sont stockés dans un fichier '.bad', pour être éventuellement retraités.

Commande minimale :
sqlldr nom_user/mot_de_passe@base control=nom_fic.ctl

La structure de la table cible doit être créée avant le chargement, SQL*Loader à la différence d'autres
outils ne crée pas la table.

III.4.1 : Principales caractéristiques

- charge des fichiers texte externes dans Oracle
- format des fichiers d'entrée fixe ou variable (avec séparateur)
- utilisation de fonctions SQL
68
 - génération de clés uniques
- mode "direct" optimisé
- gestion des logs, des erreurs et possibilité de reprise
III.4 2 : Principe général
La (ou les) table(s) destination sont créées dans le schéma cible.
On précise le format des entrées et des sorties dans un fichier de paramétrage, appelé fichier de controle,
créé avec un éditeur de texte. Un fichier log donnant les résultats du chargement est généré. En cas d'erreur,
les enregistrements rejetés sont stockés dans un fichier '.bad', pour être éventuellment retraités.
Commande minimale :
sqlldr nom_user/mot_de_passe@base control=nom_fic.ctl

La structure de la table cible doit être créée avant le chargement, SQL*Loader à la différence d'autres outils ne
crée pas la table.
 Options de la ligne de commandes
option description Defaut
userid username et mot de passe
control nom du fichier de controle du loader
data nom du fichier de données d'entrée
log nom du fichier de trace
bad nom du fichier des enregistrements rejetés
parfile nom du fichier contenant les parametres de la commande...
skip n nombre d’enregistrements logiques à sauter 0
load n nombre à charger all
errors n nombre max d'erreurs autorisées 50
rows n nb de lignes du tableau utilisé pour les entrées 64
bindsize taille du tableau précédent en bytes OSdep
silent n'affiche plus les messages pendant l'execution
direct utilise l'accès direct (direct path) false
parrallel chargement en mode parrallelisé false
file fichier d'allocation pour les chargements parralleles
fichier des enregistrements non chargés intentionnellement (saut
discard
conditionnel)
discardmax nombre maximums de ces enregistrements non chargés all
 Le contenu du fichier de controle, par étapes
1. Spécification des entrées
load data infile nom_fic | *
nom du fichier d'entrée ou * si les datas sont à la suite :
69
Exemples
1) load data infile c:\temp\entrees.dat
2) load data *
...
begindata
1000;Martin;Essonne
2000;Dupont;Marne
...
 Mode de chargement
insert insère les datas dans une table vide,
append insère les datas à la suite des données existantes,

replace insère les datas en remplaçant les données existantes,

truncate insère les datas après un TRUNCATE.
 Table cible
into nom_table (TRAILING NULLCOLS) spécifie la ou les tables (si plusieurs INTO) à charger.
Description générale des champs
fields spécifie les délimiteurs.
Exemple : field terminated by ';' optionally enclosed by ' " '
 Specifier les colonnes
col par défaut de type CHAR,
Col [POSITION debut:fin | *] type_col [longueur] [format] [NULLIF col = BLANKS]
Exemple
nom CHAR
no INTEGER EXTERNAL
Les types numériques (INTEGER, DECIMAL, FLOAT, ...) sans EXTERNAl sont des types binaires ! La plupart
du temps les numérqiues en entrée sont des caractères !
Remarque : le type de colonne peut être un type spécial
- RECNUM : no de ligne du fichier d'entrée
- SYSDATE : la date du jour
- CONSTANT valeur : une constante
- SEQUENCE (debut, increment) : un compteur automatique
 Clauses spéciales
Continueif this permet de fusionner plusieurs enregistrement physique en cas d'incomplétude
exemple : continueif this (1) = '*' concatene la ligne" suivante si la ligne courante a '*' en colonne 1
WHEN condition specif colonne
 Fichier de contrôle avec entrées au format variable

-- param.ctl
LOAD DATA INFILE 'monfic' --fichier à charger (.dat)
REPLACE --ecrase la table
INTO TABLE matable
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"' --car. de séparation
( NUMERO, NOM, PRENOM , DATE_NAISSANCE date "DDMMYY", SEXE)
 Fichier de contrôle avec entrées au format fixe
LOAD DATA INFILE 'monfic.fix'

70
REPLACE
INTO TABLE matable ( NUMERO position(1-5) char,
position de début et de fin du champ
NOM position(6-35) char, PRENOM position (36-50) char,
DATE_NAISSANCE position (*) date "DDMMYY",
--indique la position suivante
SEXE position(*) char
--longueur iimplicite pour char : 1 )
 Chargement de 2 tables à partir d’un fichier
Un fichier (3 champs) éclaté dans 2 tables (chacune 2 colonnes) une pour les employes, l'autre pour les
projets avec une colonne de jointure sur le no d'employe...
fichier d'entree :
1000-deleglise-------10
2000-martin----------20
3000-dupont----------10
...
fichier de contrôle
...
into table employes
(no_emp position(1:4) integer external,
nom position (6:20) char)
into table projet
(no_emp position (1:4) integer external,
no_projet position (22:25) integer external)
...

IV. Duplication d’une Base de Données

Il existe différents moyens de dupliquer une base donnée, soit en passant par une sauvegarde logique de la
base de données qu'on importe sur la base clone (Utilitaires EXPORT /IMPORT) soint en utilisant RMAN
(Recovery Manager) ou une par une sauvegarde complète physique et une restauration complète sur la base
clone.
Nous étudierons le cas de duplication d’une base de données par les utilitaire import et Export et celui de la
sauvegarde physique complète et restauration.

a. Procédure de la duplication par les utilitaires export et import :

1. Faites l’export full de la basede donné sur un fichier :

Exemple C:\ exp system/manager@mabase full=y file=d:\backup\mabase.dmp
2. créer une base de données clone du même nom et de mêmes paramètres que la base source (voir le
cours sur la création de base de données).
3. Importer le fichier export (mabase.dmp) précédenment sauvegardé, dans la base clone. Exemple :
C:\ Imp system/manager full=y ignor=y

b. Procédure de la duplication par la sauvegarde et la restauration physiques :

4. Arrêter la base et faites la sauvegarde physique de celle-ci.

5. Mettez les fichiers sauvegardés de la base au nouvel emplacement choisi

71
 6. Créer l’Instance qui pointe sur le fichier pfile du même nom que l’instance source (voir le cours sur la
gestion d’instance à la page 16).
7. Demarrer la base clone en ouverture

c. Importation des objets d’un schéma (utilisateur) d’une base de données à une autre

Exemple d’un utilisateur Scott

1. Faites l’export des objets de l’utilisateur Sott :
C:\ exp system/manager@mabase owner=SOCTT file f=d:\backup\mabase.dmp
2. Créer l’utilisateur Scott et mot de passe tiger dans la base destination
Create user scott indentified by tiger
3. Importer le fichier export (mabase.dmp) précédemment sauvegardé, dans la nouvelle base.
Exemple :
C:\ imp system/manager file=c:\backup\exportl.dmp fromuser=scott touser=test tables=scott.account

Chp 5 : Problèmes typiques Oracle et leurs solutions

II. problèmes de connexion
ORA-1034 Oracle not Available
Base Oracle non disponible se connecter directement au serveur (telnet ou prise de main a distance);
Positionner si nécessaire la variable d'environnement ORACLE_SID avec le nom de la base (export
ORACLE_SID=ma_base), puis vérifier que la base cible est démarrée.
(ps -ef|grep DBW sur Unix ou service Oracle actif sur NT). Redémarrer la base en utilisant le server manager
ou sqlplus.
$> export ORACLE_SID=MA_BASE
$> Sqlplus
Sqlplus > CONNECT INTERNAL
Sqlplus > SHUTDOWN ABORT (pour être sur...)
Sqlplus > STARTUP PFILE=le_fichier_init.ora (de MA_BASE)
Ou avec une version + récente :
$sqlplus 'system as sysdba/motdepasse' (si vous avez les privilèges qui vont bien, bien sûr...)
ORA- 12154 TNS could not resolve service name | Le service n'a pu etre résolu
III. problèmes de résolution de nom d'ALIAS SQL*Net
Problème de résolution de nom d'ALIAS SQL*Net
la traduction de l'alias sqlnet a échoué. Vérifier quelle est la méthode de résolution de nom (Oracle Names,
fichier local ou autre).
Et suivant la méthode utilisée vérifier que chaque élément est correct au niveau du serveur de nom, du fichier
TNSNAMES.ORA, etc. : nom du serveur cible dans la DNS, port d'écoute de SQL*Net (en général 1521) , SID
de la base sur le serveur).
.
IV. problèmes de saturation de l’espace de stockage
ORA-01653: unable to extend table proprietaire.ma_table by N in tablespace mon_TBS
- saturation d'un tablespace fixe (contenant un ou des fichiers de taille fixe)
 solution 1 : passer le fichier du tablespace en mode d'allocation dynamique d'espace supplémentaire
SQL> ALTER DATAFILE
 solution ajouter un fichier supplémentaire au tablespace
SQL> ALTER TABLESPACE TOTO ADD DATAFILE toto2.dbs SIZE 10M
- saturation d'un tablespace dynamique (contenant un ou des fichiers en mode AUTO EXTEND)
Le disque est alors 'saturé'
72
  Solution 1 : Allouer (ou libérer) de la place supplémentaire sur le volume contenant le fichier
$> rm fichier_superflus
 Solution 2 : Ajouter un fichier au tablespace TOTO sur un autre disque
SQL> ALTER TABLESPACE TOTO ADD DATAFILE disque2:\toto2.dbs SIZE 10M
ORA-01652: unable to extend temp segment by NNN in tablespace TEMP
Saturation d'un segement temporaire dans un tablespace temporaire (TEMP ou autre de type TEMPORARY) :
le segment temporaire, stocké dans le tablespace TEMPORARY, utilisé pour les tris et fusion de données
hors de la mémoire centrale est trop petit
 solution 1 : augmenter la zone de tri en mémoire pour diminuer l'utilisation du segment (espace
physique) temporaire
On augmente sensiblement le paramètre SORT_AREA_SIZE du fichier de démarrage init.ora et on redémarre
la base
 solution 2 : (beaucoup moins bien sauf si on n'a plus de RAM dispo) : augmenter la taille du
tablespace, en ajoutant un fichier ou en le passant en AUTOEXTEND (CF paragraphe précédent)
ORA-01562: failed to extend rollback segment number NNN
ORA-01650: unable to extend rollback segment RBS_A_DD by NNN in tablespace MON_TBS
Saturation d'un tablespace de Rollback Segment (ou par raccourci "d'un rollback segment")
 solution 1 : réduire l'utilisation des rollbacks segments (qui mémorise toutes les valeurs avant
modification). EN d'autre termes réduire la taille des transactions : FAIRE DES COMMITS plus
souvent (éventueellement a chaque modif)
 solution 2 : affecter un gros rollback segment à la transaction :
SQL> set transaction use rollback segment rbsdd;
En cas de pb à l' IMPORT : mettre le paramètre COMMIT=Y , pour forcer de petites transactions
Ce qui suit est encore en construction et sera mis à jout très prochainement ;-(
(mais j'ai mis la page en ligne quand même parce que ca peut servir...) ;-)

V. problèmes de droit d’accès

ORA-00942: table or view does not exist
exemple :
SQL> connect scott/tiger
SQL> select * from TOTO;
ERREUR à la ligne 1 :
ORA-00942: table or view does not exist
Attention !! ici trois cas de figure :
- 1) SOIT la table n'existe effectivement pas,
- 2) SOIT la table existe, vous avez les droits mais elle ne vous appartient pas ,
- 3) SOIT vous n'avez pas les droits d'accès
 solution 1 (la table n'existe effectivement pas) vérifié que la table existe :
SQL> SELECT table_name from USER_TABLES
(scanne la liste de mes tables)
sinon
SQL> CREATE TABLE TOTO (...); !!
 solution 2 (la table existe, vous avez les droits, mais elle ne vous appartient pas) préfixer le nom de la
table par le nom du propriétaire de la table (sinon Oracle suppose que la table vous appartient et la
cherche dans votre compte courant (votre schéma) :
SQL> select * from nom_propriétaire.nom_table;

73
 ou plus simplement créez un synonyme pour ce nom de table, qui vous évite de préfixer à chaque fois :
SQL> CREATE SYNONYM nom_table FOR nom_propriétaire.nom_table;
 solution 3 (vous n'avez pas les droits d'accès) demander au DBA de vous donner les droits !
ou si vous connaisser le mot de passe du propriétaire, donnez vous les droits :
SQL> connect propriétaire / mot_de_passe
SQL> GRANT SELECT ON nom_table TO mon_nom_a_moi;
ORA-01031: insufficient privileges
Tentative de donner des droits à quelqu'un sur une table qui ne nous appartient pas
exemple :
SQL> grant select on scott.emp to autre_user
ERREUR à la ligne 1 :
ORA-01031: insufficient privileges
Attention !! Même le DBA peut rencontrer ce genre d'erreur (c'est un comble !), bien qu'il ait les
droits de lecture sur la table
 solution
Pour contourner ce problème le propriétaire de la table doit donner le droit de lecture ET le droit de
donner des droits !
SQL> connect propriétaire / mot_de_passe
SQL> GRANT SELECT on la_table TO le_gras_qui_veut_la_lire_et_la_faire_lire WITH GRANT OPTION;
...c'est le 'WITH GRANT OPTION' qui fait tout.

Chp 6 : La sécurité des bases de données

II. Evolution des architectures

On trouvera ci-après un résumé succinct des principales étapes de l'évolution des architectures matérielles et
logicielles qui se sont profondément modifiées lors des deux dernières décennies.
Type
Type logiciels
Type serveur connexion / logiciels serveur
client clients
architecture
OS + Applicatif + fichiers de
terminal Mainframe directe -
données
PC
Départemental réseau émulateur OS + Applicatif + SGBD
terminal
PC client / applicatif
Départemental OS + Applicatif + SGBD
lourd serveur nav + applet
Srv d'application : OS (+web) +
PC Départemental /
n-tier navigateur appli
léger Central
Srv de données : OS + SGBD
la plupart de ces architectures peuvent sembler désuètes, voire anachroniques, mais il suffit de se
pencher sur l'écran d'un ordinateur dans une grande surface ou un aéroport pour constater que l'émulation de
terminal (même enjolivée) est toujours très utilisée en 2004.
Quoi qu'aie pu en penser SUN il y a quelques années :" the Network is NOT YET the computer"
On constate cependant à l'évidence une tendance à la complexité :
 multiplication des matériels (plusieurs clients fixes ou mobiles, plusieurs serveurs, réseau
hétérogènes)
74
  multiplication des couches logicielles (OS client, application client, client reseau, OS serveur, serveur
reseau, serveur applicatif, SGBD)
 multiplication (voire ubiquité) des réseaux ( intranet, internet et surtout en ce qui concerne la sécurité
des données EXTRAnet)
 généralisation du partage de données : entre particuliers, mais aussi employés, entreprises, clients,
fournisseurs, partenaires
qui fait de la sécurité des données un enjeu majeur.
Pour info, ci après les statistiques du CERT sur les enregistrements d'incidents des dernières années :
Année 1990 1991 1992 1993 1994 1995 1996
Incidents
252 406 773 1334 2340 2412 2573
rapportés

Année 1997 1998 1999 2000 2001 2002 2003

Incidents
2134 3734 9859 21756 52658 82094 +150000
rapportés

2. Les piliers de la sécurité des systèmes en général et des SGBDs en particulier

On envisage souvent la sécurité sous un angle fermé, essentiellement celui de la confidentialité. Mais bien
d'autres concepts sous tendent la sécurité. Ils sont pratiquement tous applicables aux OS ET aux SGBDs, tant
il est vrai que ces deux domaines sont extrêmement recouvrant.
 confidentialité
Tout n’est pas accessible à tout le monde! Se connecter à l'OS ou à la base de données, donne un
certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un
administrateur. La granularité d’accès peut aller jusqu’à la vision unique d’un champ d’un
enregistrement d’une table particulière.
 disponibilité
Faculté de délivrer correctement un service en terme de délai et de qualité à l'utilisateur. Se mesure
en pourcentage du temps de fonctionnement total. Une disponibilité de 100% est possible (temps de
reprise nul) il suffit de s’en donner les moyens logiciels et matériels...
 fiabilité
Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle,
incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une
information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel.
 intégrité
Que les données soient réparties ou non –dans ce dernier cas les mécanismes mis en jeux seront
plus complexes– elles doivent être cohérentes. Cela sous entend, d’une part que les accès
concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent pas compromettre la
cohérence des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité du
modèle, et / ou aux règles de gestion de l’entreprise.
 traçabilité
en cas de problème important ou d’attaque du système, on peut recourir à l’analyse de traces ou de
logs. Le niveau de détail de ces traces est paramétrable, et concerne soit les aspects système, soit
réseau, soit l’accès aux données élémentaires elles-mêmes.
 maintenabilité
aptitude à la réparation, évolution, maintenance du système. Mesuré en temps de reprise après
panne (Mean Time To Recover)
3. Les mécanismes mis en oeuvre pour la sécurité
Les sgbds (dignes de ce nom) se doivent de fournir un certain n ombre de mécanismes internes ou de
fonctionnalités assurant un niveau satisfaisant de sécurité.
75
  L'authentification, est le processus qui permet de vérifier qu'un utilisateur réclamant un accès est
bien celui qu'il prétend être, ou plus simplement le processus qui contrôle l'identité de l'utilisateur.
Cette action (login) se fait en général via la fourniture du couple nom d'utilisateur / mot de passe.
Dans certains cas l'authentification peut être implicite et héritée d'une authentification précédente, ou
reconnue automatiquement (@IP du user sur le réseau par exemple), bien que simplifiant les accès
ce choix peut évidemment s'avérer dangereux.
la multiplication des couches logicielles sus évoquée, et l'inflation d'applications sur les postes
utilisateur fait que ce dernier est fréquemment amené à s'authentifier des dizaines de fois par jour. La
signature unique (Single Sign On ou SSO) est un objectif très louable mais rarement atteint !
 Les droits et privilèges : une fois correctement identifié l'utilisateur doit pouvoir accéder aux
informations et ressources auxquelles il a droit (et uniquement à celle là!) Ce problème est résolu le +
simplement avec la gestion de droits élémentaires accordé à un individu, ou plus efficacement avec
des rôles et / ou profils affectés à des groupes d'invidus...ou à des rôles ou profils.

mécanisme mis en exemple d'implémentation exempled'implémentation

Aspect sécurité
oeuvre au niveau SGBD au niveau OS
 référentiel user /
password :
DBA_USERS
 tables de user
applicatifs
 identification  SSO LDAP
 authentification
externe :  identification externe
 indépendance CREATE USER  architecture client
logique / physique ...IDENTIFIED serveur
EXTERNALLY
 tables / tbs / fichiers
 vues (1)
confidentialité
 virtual private
database
 droits d'accès aux
données
GRANT SELECT
ON toto
 droits du LDD ou
 droits et privilèges Systeme  user OS DBA ou root
GRANT CREATE
TABLE TO...
GRANT CREATE
SESSION TO...
 roles
 logs apache
 tables d'audit
traçabilité  logs et traces  logs OS
 log Oracle Net
 logs réseau

fiabilité,  tolérance de  stand by DB  H.A.C.M.P

disponibilité, panne  cluster logiciels :  techno RAID
76
maintenabilité architecture R.A.C  machines
redondantes
 physique :
sauvegarde +
journalisation +
 sauvegarde et restauration  copie physique totale
restauration
 logique : export /
import
 génération de SQL
 Two Phase Commit
 transaction (2PC)
atomique
intégrité  contraintes
 contraintes 'reference'
d'intégrité
 read consistancy

 Les LOGs ou traces : permet d'enregistrer tout ou partie des informations concernant les accès
(réussis ou échoués). Cette trace pourra être plus ou moins verbeuse et son volume étroitement
surveillée. De ce fait on l'utilisera de manière cibllée sur des périodes de temps spécifiques
 tolérance aux pannes : permet par du matériel ou du logiciel redondant (CPUs, disques, IOs) de
supporter de manière partiellemnt ou complètement transparentes différents types de pannes, tant au
niveau du client, que du réseau, que du serveur. Une tolérancec totale a bien sur un cout certain.
 sauvegarde et restauration
Sauvegarder les données sur des supports externes (disques, bandes, etc.) et pouvoir les restituer, les
plus à jour possible. le but est de ne pas perdre de données suite à un pb matériel (panne disque) ,
logiciel (bug) ou une fausse manipulation d'un utilisateur.
 mécanismes transactionnels
L’atomicité des transactions, par définition assure la cohérence des données, même dans des
environnements distribués. L'image avant modification, stockée de manière redondante dans ou hors de
la BD, permet de faire d'éventuels retours arrière pour retrouver le dernier état cohérent, ou de s'assurer
qu'il n'y aps pas eu d'opérations partielles ou incomplète (transaction bancaires par exemple)
(1) la vue est pratiquement le seul contrôle d'accès offrant un niveau de granularité ligne ou colonne ! et
qui plus est de manière contextuelle, en les paramétrant (tranches horaires, @ IP, etc.)
4. Les principales menaces
Au dela des attaques accidentelles ou les défaillances du système, les attaques 'malveillantes' nous
intéresserons + particulièrement.
Les menaces les plus connues du grand public, visent à paralyser, ou détruire tout ou partie du système
d'information. Elles ne ciblent pas vraiment les SGBDs mais nous les citerons néanmoins parce
qu'incontournables. Jetons un oeil aux définitions données par le grand glossaire de la sécurité de
ECHU.ORG :
 Virus : Au sens large du terme, on qualifie généralement de virus tout programme capable de se
reproduire (techniquement, se recopier) lui-même et d'endommager des données informatiques. On
les classe en plusieurs catégories, principalement: parasite, compagnon, amorce, multiformes,
résident mémoire ou non, furtifs, polymorphes, réseau et flibustier. Pour plus de détails reportez-vous
aux définitions correspondantes.
 Ver (ou Worm) : programme qui peut s'auto-reproduire et se déplacer à travers un réseau en utilisant
les mécanismes réseau, sans avoir réellement besoin d'un support physique ou logique (disque dur,
programme hôte, fichier ...) pour se propager; un ver est donc un virus réseau.

77
  Cheval de Troie : (en anglais trojan horse) un programme informatique effectuant des opérations
malicieuses à l'insu de l'utilisateur : vol des mots de passe, copie de données sensibles, exécution
d'action nuisible ...
Une intro très accessible de ces notions est dispo sur : http://www.commentcamarche.net/ et d'autres
infos encore sur : http://assiste.com
Un peu moins connus mais plus probables dans le domaine des SGBDs :
 Back doors : ("Portes dérobées") : Programmes usurpateurs qui détournent des fonctionnalités
systèmes dans le but d'ouvrir des accès utiles aux pirates pour contrôler à distance les machines
ciblées (modification des programmes de login avec user/passwd en dur, ouverture de ports
particuliers, etc.). Ces programmes sont la plupart du temps installés par le biais d'un "cheval de
Troie". Parmi les plus (tristement) célèbres, on peut citer BackOrifice (BO) ou encore NetBus.
Les accès illicites via ces backdoors pouvant être facilement détectés par des commandes système
standards (liste des process connectés, des ports ouverts) ils sont parfois utilisés conjointement avec
des rootkits, ensemble de commandes standards modifiées pour masquer les intrusions.
certaines back doors peuvent être inclsues dans le code d'applications standards, sans intention
forcément malveillante mais pour réserver au développeur du programme, un accès 'privé' à toutes
les machines hébergeant son code. L'accès à la source d'un logiciel libre peut nous prémunir contre
ce genre d'indélicatesse.
 altération du SQL, Buffer Overflow
5. Les principales failles de sécurité...ou de comportement
 'portes' ouvertes : (pas seulement les 'back doors' !)
porte de la salle machine ouverte, poste ou serveur sans mot de passe ou mot de passe faible, poste
sans veille, post it (!) ; recommandation : fermez les portes !! mettez en oeuvre la gestion de mots de
passe !!
 Installation par défaut :
- les valeurs de paramètres sont connues (port 80 / 1525, mot de passe SYS et SYSTEM,
- des services superflus sont accessibles (srv ftp, srv samba, snmp, serveur d'admin, etc
- les communications ne sont pas chiffrées (ftp, telnet, pop) ; recommandation : lisez la doc !! auditez vos
serveurs !!
 Mauvaise politique de gestion des droits (top, au lieu de bottom-up) :
- installation confortable : tous les logiciels sont installés sous root, tous les utilisateurs de l'applicatif
sont DBAs
- allow all implicite...deny N / deny all.. allow n
- utilisation abusive de l'héritage ; recommandation : maitrisez la gestions des droits de vos OS /
logiciels serveurs / bases de données
 bugs (qui peuvent provoquer un simple déni de service voire l'arrêt du système) ;-) faites de la veilles,
patchez régulièrement
 Mauvais codage (parametres en clair dans les URLs, connexion non chiffrées, etc.)
;-) documentez vous (best practices, faites tester vos programmes)
 Controle d'accès au niveau applicatif, qui peut facilement être court circuité
;-) (re) centralisez (ET FACTORISEZ!) les controles au niveau données : contraintes d'intégrité
Comme chacun sait (depuis certaines émissions de télé) c'est le maillon le plus faible de la chaîne qui cassera
imanquablement. On peut mettre en place le plus beau (et le + cher) des firewalls, il sera bien inutile si un
adminitrateur est resté 'loggé' root sur son poste (Statistiquement la majorité des attaques provient de
l'intérieur des entreprises !)
Cependant, on n'oubliera pas de rester pragmatique : tous les PMEs ne sont pas le pentagone et n'intéressent
pas tous les hackers de la planète. Les besoins et les objectifs doivent être clairement définis au départ et
l'adéquation de la solution vérifiée. Un certains nombres d'utilitaires libres sont disponibles sur internet pour
vérifier la fiabilité de votre système d'information. Voir parmi la liste des liens utiles.
Il faudra de + trouver un équilibre entre niveau de sécurité satisfaisant et confort (voire simple possibilité) de
travail des autres acteurs.

78
79