LP_Admin_base_données.ppt

Filière (LP) : Développement des Systèmes
d’Information et de Communications-S6
Année Universitaire : 2018/2019 au 2023/2024
Diaporamas du cours :
Administration des Bases de
Données (sous oracle)
Préparé par : Idriss CHANA
Enseignant chercheur au Département Génie Informatique, EST-UMI
Meknès Email : i.chana@umi.ac.ma
Au Profit des Etudiants de La LP DSIC inscrits en semestre S6

Module Administration de base de
données
• Pré requis:
Modèle relationnel (structure, contraintes, SQL)
• Objectifs
– Connaître les concepts et points clés de l'architecture Oracle
– Connaître les tâches d'un DBA
– Savoir effectuer les principales tâches sous Oracle
2
Pré requis et Objectif du module

1- Introduction Générale :
- Introduction à l'administration de Base de données
- Fonction de l'administrateur de Base de données
2- Architecture d'un serveur Oracle
- L'instance - les données ( base de données)
- les Processus
- les fichiers
3- Création de la structure d’une base de données
- Du besoin à l’application
- Rappels sur les indexes Principes choix et création : index btree , BitMap
- Syntaxe générale de création : - tablespaces, - tables,
- Alimentation d'une base de données le sqlloader
4- Gestion des utilisateurs
5- Sauvegarde et restauration.
-L’outil Rman
Plan de module

Cadre applicatif et administration BD
4

Évaluation
• Cours & TD 50%
- DS théorique
- Participation pendant des séances de TD et de cours
• TP 50%
- DS Pratique
- Participation active pendant des séances de TP .
- Rapports rendus à la fin des séances TP
5

7
Maître d’oeuvrage
Partie porteuse du besoin qui définit l’objet du projet, le calendrier et le
budget
Maître d’oeuvre
Partie en charge de la réalisation technique du projet
Acteurs de développement

9
Métiers autour des BD
• Administrateur
• Responsable de la sécurité
• Administrateur Réseaux
• Développeurs d’application
• Administrateurs d’application
• Utilisateurs : modifier les données, créer des rapports, etc.

10
Rôles du DBA
• Installer les logiciels les serveur, des applications clientes,
• En fonction de la configuration système disponible
• Si fonctionnement en réseau : Composants réseaux de l’SGBD
• Planifier, créer et configurer des bases de données
• Gérer l’espace et implanter les schémas des données
• Assurer la sécurité, l’intégrité et la pérennité des données
• Implémenter une stratégie de sauvegarde et de récupération.
• Déplacer des données entre des bases de données et des fichiers.
Remarque :
• Dans un environnement de petite taille, l’administrateur (DBA) peut jouer
quasiment tous les rôles

 Chapitre I Architecture d'une base de données Oracle
Architecture Interne d’Oracle : grandes lignes
La mémoire d’Oracle
- System Global Area (SGA) et ces composante
Les processus Oracle
- - Program Global Area (PGA)
- Les processus utilisateur
- Les processus serveur
- Les processus d’arrière plan (Background process)
- DataBase Writer (DBWR)
- Log Writer (LGWR) et ça gestion
- Process Monitor (PMON)
- System Monitor (SMON)
-CheckPoint (CKPT)
-Archiver (ARCn)
- Recover (RECO) et - Lock (LCKn)

1 - 12
A la fin de ce chapitre, vous pourrez :
 Enumérer les principaux composants de l'architecture
d'une base de données Oracle
 Décrire les structures mémoire
 Décrire les processus en arrière-plan
Administration des bases de données sous Oracle
Chapitre 1 : Architecture d'une base de données Oracle
Objectifs

1 - 13
 Le système de gestion de base de données relationnelle (SGBDR)
Oracle fournit une approche ouverte, complète et intégre de la gestion
des informations.
Géstion fiable d’une grande quantité d’information
Envirennement multiutilisateur avec performances élevées
Enpeche les accès non autorisés
reprise ( recupération) après incident
 Une base de données est un ensemble de données traitées comme
une seule et même unité. Elle sert principalement à stocker et à extraire
des informations connexes.
Introduction : Base de données et SGBD Oracle

1 - 14
Base de données (structures de stockage)
Processus
serveur
PGA
Processus
utilisateur
Instance
Structures mémoire
(mémoire SGA)
Structures de processus
Client
Serveur
Un serveur de bases de données Oracle est compose :
 d'une instance = plusieurs processus et une zone de mémoire
 d'une base de données : Ensemble de fichiers (sur disque) contenant les
données, les informations sur les données, le journal de modifications
 de plusieurs schémas: assimiles a des utilisateurs
Dans le cas de clusters de machines, Oracle peut associer plusieurs instances a
une même base de données.
Architecture: grandes lignes

1 - 15
 C’est l’ensemble de structures mémoire et de processus qui
assurent la gestion de la base de données.
 Le fichier de paramètres est utilisé pour configurer l’instance lors de
son démarrage.
 Une instance ne peut ouvrir qu’une seule base de données.
 Une instance emploie deux zones mémoire principales; la SGA
(System Global Area) et la PGA (Program Global Area).
L’instance (1/3)
Architecture:

1 - 16
Serveur de BD
SGA
PGA
PGA
PGA
Processus 1 Processus 3
Processus 2 Processus ...
L’instance (2/3)
Architecture:
SHOW PARAMETER INSTANCE_NAME;
// ou
SELECT INSTANCE_NAME FROM V$INSTANCE;

1 - 17
 C’est un espace mémoire partagé par tous les processus de l’instance. Elle est
allouée au démarrage de l’instance et libérée lors de son arrêt. Elle inclut 6 zones
mémoires (3+3).
 Plus la SGA est grande, plus le serveur est performant. Sa taille maximale est
définie via le paramètre SGA_MAX_SIZE
L’instance (3/3)
Architecture:
SGA : System global Area

1 - 18
Dictionary
Cache
Library
Cache
DB Buffer
Cache
Shared
Pool
Redo Log
Buffer
Java Pool
Streams
Pool
Large Pool
SGA
Architecture: Structure de la mémoire SGA
SGA : System global Area

1 - 19
 Elle est composée de deux structures; le library cache et le dictionary cache. Sa
taille est définie via le paramètre SHARED_POOL_SIZE.
 Le LC contient pour chaque requête récemment exécutée trois informations:
- Son texte
- Sa compilation
- Son plan d’exécution
 Lorsqu’une requête existe encore dans le LC, Oracle ne perd pas son temps à la
ré-exécuter.
 Le DC stocke toutes les informations nécessaires à l’analyse sémantique de la
requête (table? Colonnes? Droits d’accès?...)
NOTE : le dba peut nettoyer le buffer via la commande
Alter System Flush Shared Pool
Shared Pool

1 - 20
 Il stocke les blocs de données les plus récemment utilisés.
 Lorsqu’une requête est exécutée, Oracle vérifie d’abord si les blocs de
données à ramener ne soient pas déjà chargés dans le DB buffer.
 Si les blocs à renvoyer n’existent pas dans le DB buffer cache, Oracle les y
stocke (et libère d’autres blocs s’il le faut).
 La taille du DB Buffer Cache est définie via le paramètre DB_CACHE_SIZE
DB Buffer Cache

1 - 21
 Contient les informations sur les transactions exécutées.
 Le Redo Log Buffer est écrit de manière séquentielle.
 Chaque modification correspond à une entrée Redo. Cette dernière est
constituée de plusieurs vecteurs, chacun correspond à un bloc de données
modifié (ancienne + nouvelle valeur).
 Le contenu du Redo Log Buffer est écrit dans les fichiers journaux.
 La taille du Redo Log Buffer est définie via le paramètre LOG_BUFFER*
Pour consulté les fichier redo log  La vue v$logfile
Redo Log Buffer

1 - 22
 Le Large Pool : Stocke des données lors de l’exécution d’opérations volumineuses. (pas comme
Data Buffer cache qui alloue de petite zones mémoire)
- Allocation de grande zones mémoire ( Backup /Restaure par RMAN Calloc, malloc, copie,
utilisation de plusieurs processeur )
- Libération de la mémoire allouée on utilise des expression explicite au langage de
programmation (free)  Pas comme pour la Data Buffer cache : pas de concept de libération
de mémoire - Paramètre LARGE_POOL_SIZE.
Autres zones mémoire
 Le JAVA Pool ( à partir de Oracle 8.1.6) : Stocke les objets et applications Java les plus
récemment utilisés lorsque la machine virtuelle Java JVM optionnelle est utilisée. Paramètre
JAVA_POOL_SIZE.
 Le Streams Pool ( à partir de Oracle 10.R2) : C’est le cache des données relatives à la queue de
messages utilisées par Oracle lors de la Réplication par synchronisation. ( exp:cas de serveur
principale et serveur secondaire)  Paramètre STREAMS_POOL_SIZE.
 A noter que dans la SGA, il y a une petite zone mémoire appelée SGA fixe. Elle inclut des infos
sur l’état de la base, l’instance, les verrous…
 Les vues V$SGA et V$SGA_DYNAMIC_COMPONENTS.

1 - 23
SGA
PGA
PGA
PGA
Processus 1 Processus 3
Processus 2 Processus ...
Dictionary
Cache
Library
Cache
DB Buffer
Cache
Shared
Pool
Redo Log
Buffer
Java Pool
Streams
Pool
Large Pool
SGA
SERVEUR BD =
Instance
+
BD (fichiers)
Récapitulatif
INSTANCE =
Zones mémoires
+
Processus
ZONES MÉMOIRES
=
3 + 3

1 - 24
PMON
SMON
Autres
Instances (base de données à part)
RECO
ARCn
DBWn LGWR
CKPT
PGA
Processus en arrière-plan
Mémoire SGA (System Global Area)
Obligatoires :
ASMB RBAL
Facultatifs :
Processus
utilisateur
Processus
serveur
Processus
d'écoute
Architecture: Structure des processus
Introduction

1 - 25
 C’est une zone mémoire privée dédiée aux utilisateurs. Elle est créée pour
chaque processus serveur.
 Elle stocke des informations spécifiques aux utilisateurs, tel que les
variables hôtes, les variables de session, l’état des curseurs utilisés, des
informations de tri etc.
 La PGA totale allouée à tous les processus serveur est appelée PGA
agrégée.
 Le paramètre PGA_AGGREGATE_TARGET définit la taille de la PGA
agrégée, c’est Oracle qui se charge de la répartir entre les différentes
processus serveur.
La PGA

1 - 26
 Ils permettent une interaction entre les différentes composantes du
serveur ainsi qu’avec les utilisateurs.
 Il existe trois types de processus
1. Les processus utilisateur
2. Les processus serveur
3. Les processus d’arrière plan
Les processus

1 - 27
 Le processus utilisateur s’exécute au niveau client.
 Le processus serveur s’exécute au niveau serveur BD.
 L’interaction entre le serveur et les clients se fait en réalité grâce à
ces deux processus, chacun de son côté.
 Lorsque le client est lié au serveur, on parle d’une connexion.
 Lorsque l’utilisateur s’identifie, il ouvre une session.
 Plusieurs sessions peuvent être ouvertes en même temps. Elles ne
doivent pas dépasser la valeur du paramètre SESSIONS*.
Les processus utilisateur et serveur

1 - 28
 Le processus serveur (PS) reçoit les requêtes utilisateur, les exécute et renvoie
le résultat.
 Un serveur BD : soit en mode DÉDIÉ, soit en mode PARTAGÉ.
 En mode dédié, on dédie un PS à chaque utilisateur.
 En mode partagé, on partage un PS pour un ensemble d’utilisateurs.
 Le mode par défaut est le mode dédié. Pour activer le mode partagé, il faut
modifier la valeur de SHARED_SERVERS (par défaut =0).
 La valeur de SHARED_SERVERS indique le nombre de processus serveur
partagés.
 Rappelons qu’une zone de mémoire PGA est allouée à chaque PS.
Les processus utilisateur et serveur

1 - 29
 Assurent le bon fonctionnement du serveur.
 Maximisent la performance du serveur.
 Démarrent avec ou après (sur demande) le démarrage de
l’instance.
 Certains peuvent être exécutés en n exemplaires.
Les processus d’arrière plan

1 - 30
 écrit sur les fichiers de données les anciens blocs utilisés « dirty », et
fait appel au Pmon, pour « Nettoyer » le DB Buffer Cache et ce pour:
 Libérer de la place dans le cache pour y charger les nouveaux blocs
de données.
 Peuvent fonctionner en 20 exemplaires en cas de forte charge
transactionnelle (inutile en cas de serveurs monoprocesseurs).
 Le paramètre qui détermine ce nombre DB_WRITER_PROCESSES*.
 L’écriture des blocs modifiés est différée c’est a dire que le COMMIT ne
déclenche pas automatiquement une écriture par le DBWn dans le
disque (fichier de données) .
Le DB Writer (DBWn)

1 - 31
 Le DBWn se déclenche pour écrire les blocs dirty sur le disque: par ces
deux événements:
1. Le PS ne trouve pas de tampons « clean » après avoir scanné un
nombre seuil de tampons.
Seuil = 13
DB Buffer Cache
Le DB Writer (DBWn)

1 - 32
 Le DBWn se déclenche (en écrivant les blocs dirty les moins récemment
utilisées sur le disque) par ces deux événements:
2. Après une certaine période pour faire avancer le point de reprise.
DB Buffer Cache
Data Files LOG Files
1. Insert…;
2. Update…;
Le DBW est déclenché !
3. Update…;
commit;
4. Insert…;
5. Update…;
commit;
LOG Buffer
1 2 3 4
5
1
2
3
4
5
1 2 3
4 5
1 2
CRASH !!!
Le point de reprise est la position
dans les fichiers journaux à partir
de laquelle les données sont
récupérables = le plus ancien
tampon dirty du DB cache.
Le DB Writer (DBWn)

1 - 33
 Le DBWn ne se déclenche pas à la suite d’un COMMIT. Il faut donc
savoir qu’on peut se trouver dans l’une de ces deux situations:
1. Le DBWn écrit des modifications non-confirmés (non commités)
dans les fichiers de données. On dit qu’il anticipe.
2. Des modifications confirmées ne sont pas écrites sur les fichiers de
données, et restent en mémoire centrale (dans le DB Buffer
Cache).
Le DB Writer (DBWn)

1 - 34
 Le LGWR écrit le contenu du Redo Log Buffer sur les fichiers journaux pour libérer de
l’espace au PS.
 Le LGWR est déclenché par :
1. COMMIT  écriture des entrés redo relatives à la transaction confirmée.
2. Après un délai (3 secondes)
3. Quand le Redo Log Buffer est plein au tiers
Le LOG Writer (LGWR)

1 - 35
 La notion de fast COMMIT est liée à l’écriture différée des blocs dirty
confirmés sur les fichiers de données.
 Dans le cas où : Après un COMMIT seules les entrées Redo de la
transaction confirmée sont écrites sur les fichiers journaux (les blocs dirty
ne sont pas écrits sur les fichiers de données par le DBWn), cela s’appelle
Fast COMMIT.
 Le SCN (System Change Number) est un code affecté à toute transaction
confirmée par un COMMIT.
 Le SCN est inscrit sur les entrées redo de la transaction confirmée sur les
fichiers journaux.
 Ce système de codage est fondamental pour la restauration des données
en cas de crash du système.
Le fast COMMIT & le SCN

1 - 36
 Le CKPT est lancé lorsque le système a besoin de faire un check point (point de
vérification).
 Lorsqu’un point de vérification est déclenché, le CKPT envoie un message au
DBWn pour qu’il écrive tous les blocs dirty sur les fichiers de données.
 Une fois le DBWn termine sa tâche, le CKPT écrit le SCN de la dernière
transaction confirmée dans les entêtes des fichiers de données ainsi que dans le
fichier de contrôle.
 En cas de crash, les transactions récupérées à partir des fichiers journaux sont
celles dont le SCN est supérieur à celui écrit dans le fichier de contrôle.
Le Check Point (CKPT)

1 - 37
 Les événements qui déclenchent un point de vérification (CKPT):
1. Lorsque le LGWR bascule d’un groupe à un autre. En fait le LGWR ne
prend pas le risque d’écraser des entrées Redo sans écrire les blocs
qui leurs correspondent dans les fichiers de données.
2. A la fermeture de la base de données.
3. Lors de la mise en offline d’un tablespace.
Le Check Point (CKPT)

1 - 38
 Récupération des données au démarrage après un crash.
 Optimisation de l’espace disque (libération des segments temporaires,
compactage des extensions libres et contiguës)
IL a un rôle de libération des ressources utilisées inutilement par le système.
Il surveille les espaces libres des fichiers de la base de données et les
réorganise si nécessaire afin de les défragmenter
Si erreur d’arrêt de la base  analyse le rollback segment pour éviter les
deadlocks
 Le SMON effectue ou bien un ROLLBACK, ou bien un ROLLFORWARD
 ROLLBACK : annulation des modifications non-confirmées qui étaient
enregistrées sur disque par anticipation du DBWn.
 ROLLFORWARD : enregistrement des modifications confirmées sur les
fichiers de données à partir des fichiers journaux.
Le System Monitor (SMON)

1 - 39
• Il assure la recuperation des processus utilisateur qui ont échoué.
– Nettoyage du cache de tampons de la base de données
– Enlever les plans d’execution qui ne sont plus choisis par l’optimizer
– Libére des ressources utilisées par le processus utilisateur en échec
• Il surveille les sessions pour détecter tout dépassement
du délai d'inactivité, ou plantage d’une sesion  kill session .
• Il enregistre dynamiquement les services de base de données dans
les processus d'écoute.
Processus PMON
Cache de tampons de
la base de données
Processus utilisateur en échec
Utilisateur
PMON
Processus
serveur
tnslsnr
Le Process Monitor (PMON)

1 - 40
 Détection du plantage des processus utilisateurs.
 Imaginez ce scénario :
1. Un PU qui a déjà lancé une requête UPDATE
2. Les données modifiées sont naturellement verrouillées
3. Le PU se bloque suite à une raison
 Les données seront verrouillées indéfiniment !
 C’est là où le PMON entre en action, il détecte le PU bloqué,
annule la transaction en cours et libère les verrous
Le Process Monitor (PMON)

1 - 41
 Écriture du contenu des fichiers journaux dans les fichiers journaux
archivés.
 Déclenché par le basculement dans les fichiers journaux d’un groupe à
un autre.
 Activé si le serveur fonctionne en mode ARCHIVELOG.
 Le paramètre LOG_ARCHIVE_MAX_PROCESSES* spécifie le nombre
d’exemplaires d’ARCn, même si le LGWR peut spécifier ce nombre de
manière automatique (si pas d’intervention de l’administrateur).
ARCHIVE (ARCn)

1 - 42
 Il existe d’autres processus d’arrière plan, nous nous arrêterons sur
l’ARCn.
 Le paramètre d’initialisation PROCESSES* définit le nombre max de
processus connectés en même temps à l’instance.
 La vue V$PROCESS inclut les informations de tous les processus en
cours d’exécution dans l’instance.
Les processus d’arrière plan

1 - 43
Introduction
La structure physique
- Les Fichiers de données (DataFiles)
- Les Fichiers de reprise (Redo Log Files)
- Les Fichiers de contrôle (Control Files)
La structure Logique
- Les Tablespaces
-Segments
- Extensions (Extent)
- Blocs
L architecture Oracle:
- Client /serveur
- Multitier
Chapitre 2 :Structure de stockage d’une Base de Données Oracle
Plan

1 - 44
Fichiers de
journalisation en ligne
Fichier de mots
de passe
Fichier de
paramètres
Fichiers de
journalisation
archivés
Fichiers de
contrôle
Fichiers de
données
Fichiers trace et fichier
d'alertes
Fichiers de
sauvegarde
Structure Physique
Introduction

1 - 45
Fichier de contrôle
 Fichier de contrôle (Control File)
- Contient des informations de contrôle sur la base:
Nom de la base, noms et chemins des fichiers de données et de
journalisation, informations de restaurations etc …
- Premier fichier lu par l’instance lors du démarrage.
- La vue V$CONTROLFILE nous renseigne sur le contenu du
fichier de contrôle.
-Il sont consultés et gérer en état mount de la base de données
SHOW PARAMETER CONTROL_FILES;
Fichier de contrôle
Structure Physique

1 - 46
•Le nom de la base de données qui est pris avec le paramètre
•Le SID de l’instance lié à la base de données créée.
•Le timestamp de la création de la base de données.
•Les noms et localisations des fichiers de données et des fichiers de redo log sont mis
à jour dans un fichier de contrôle lorsqu’un fichier de données ou un fichier de redo
log est ajouté ou supprimé.
•Les informations sur les tablespaces sont mises à jour lorsqu’un tablespace est
supprimé ou ajouté.
•L’historique des switches de redo log.
•Les localisations et statuts des logs archivés sont enregistrés lorsque l’archivage est
activé.
•Les localisations et statuts des backups sont enregistrés par l’utilitaire Recovery
Manager.
•Le numéro de séquence de log courant est enregistré lorsque des switchs de log se
Contenu des fichiers de contrôle
Fichiers de contrôle
Structure Physique

1 - 47
 Fichier de données (Data Files)
- Stockent les données sous un format spécial à Oracle.
- Physiquement, un fichier de données est un ensemble de blocs SE. Un
bloc SE constitue l’unité d’E/S(écriture/lecture) des fichiers.
- Les fichiers de données sont logiquement regroupés sous forme de
tablespaces.
- Une BD Oracle 10g et 11g incluent au moins deux tablespaces, SYSTEM
et SYSAUX.
Fichiers de données
Fichier de données
Structure Physique

1 - 48
INSERT INTO
UPDATE…
DELETE...
INSERT INTO
UPDATE…
DELETE...
DELETE
UPDATE
INSERT INTO
UPDATE
UPDATE…
INSERT INTO
DELETE
UPDATE
INSERT INTO
UPDATE
UPDATE…
INSERT INTO
Membre 1 Membre 2
Membre 1 Membre 2
Groupe 1
Groupe 2
Dans une BD Oracle toute les transaction sans enregistré dans des fichiers
 Ces fichier sont dits fichiers de journalisation
Lorsque les fichier de groupe 1 sont pleins l’écriture est basculée
vers les fichiers de groupe 2 et cela d’une manière cycliques
Au minimum 2
groupes
Le processus LGW
Statut des groupes (la vue v$log)
Actif : les données ne sont pas encore
synconisés avec le datafils
Current: LGW est entrain d y écrire
Inactif : les données synconisés avec le
datafils ( #Actif)
Unused : jamais utilisé
Fichiers de journalisation
Structure Physique

1 - 49
 Les fichiers de journalisation contiennent toutes les modifications
effectuées sur les données depuis une certaine durée.
 En cas de crash du système, ou d’altération des fichiers de données, on
peut reconstituer les données à partir des fichiers journaux.
 L’écriture sur les fichiers journaux est multiplexée et cyclique.
 L’ensemble des fichiers multiplexés (qui contiennent donc les mêmes
informations) sont appelés membres et forment un groupe.
 L’écriture est multiplexée à l’intérieur d’un groupe, et cyclique entre les
groupes.
 Les vue DBA_LOG_FILES et v$log et v$logfile(pour les member)
contiennent les informations des fichiers journaux.
Pour ajouter un fichier log  alter database add logfile
Example :alter database add logfile group 4 ('d:men') size 4M ;
alter system switch logfile
alter database add logfile member 'd:men4_2‘ to group 4 size 4M ;
Structure Physique

1 - 50
 L’écriture des fichiers journaux est cyclique, ce qui fait qu’à un certain
moment, certaines transactions seront écrasées.
 La solution, c’est d’archiver les fichiers journaux avant de les écraser.
 Les fichiers journaux archivés peuvent être stockés sur des disques
(serveurs) distants, ce qui optimisera la sécurité de la BD.
 Une base de données n’est pas forcément en mode ARCHIVELOG, si elle
ne l’est pas, les fichiers journaux ne sont pas archivés.
Structure Physique

1 - 51
1- Pour ajouter un fichier log  alter database add logfile
Exemple :alter database add logfile group 4 ('d:men') size 4M ;
2- Pour basculer alter system switch logfile
3- Pour ajouter un membre alter database add logfile
Exemple: alter database add logfile member 'd:men4_32.log‘ to
group 4;
4- Pour supprimer un membre : alter database drop logfile
Example : alter database drop logfile member 'd:men4_2‘
( groupe ne soit pas current on lance un switch dans ce cas )
5-Pour supprimer un groupe : alter database drop logfile group Num_group;
Example : alter database drop logfile group 4;
6- Le redimensionnement des REDO consiste à les supprimer et les recréer à la bonne taille.
Pour les supprimer, il faut qu'ils soient INACTIFS (qu'ils ne contiennent plus de transactions non
Gestion Fichiers de journalisation Ajout/suppression
Structure Physique

1 - 52
Structure Physique
Gestion Fichiers de journalisation : déplacer / renommer des membres
Par soucis de performance il est parfois nécessaire de devoir déplacer ou renommer
les membres Redolog d'une instance de base de données.
Voici une des solutions, simple et efficace avec ALTER DATABASE RENAME FILE.
Etape 1 - On constate l'emplacement physique actuel des membres redolog :
SQL> SELECT member FROM v$logfile;.
Etape 2 - On stop la base de données (SHUTDOWN) et on deplace le
membre redolog (HOST MOVE)
SQL> shutdown immediate;
SQL> host move encien_fichier.LOG nouveau_fichier.LOG
1 fichier(s) déplacé(s).
- Ou bien vous le déplacer et renommer par les commande du SE ( ou coper/coller)
- Vous pouvez aussi utiliser HOST COPY mais il faudra supprimer l'ancien Redolog à la main ).
Etape 3 - démarrer la base en mode MOUNT, puis spécifier à Oracle le nouvel
emplacement du Redolog
SQL> startup mount
SQL>ALTER DATABASE RENAME FILE encien_fichier .LOG to nouveau_fichier.LOG
Etape 4 - ALTER DATABASE OPEN et on vérifie la prise en compte par Oracle

1 - 53
 Un fichier de paramètres inclut l’ensemble des paramètres de
configuration du serveur BD.
 L’instance lit ce fichier et fonctionne selon les valeurs des paramètres qui
y sont spécifiés.
 Il existe deux types de fichiers de paramètres:
C:product11.2.0dbhome_1database
PFILE (parameter file) SPFILE (server parameter file)
Fichier texte Fichier binaire
Modifiable via un éditeur texte Modifiable via SQL
Disponible sur la machine de démarrage Centralisé (sur le serveur uniquement)
Nommé init%.ora Nommé spfile%.ora
Modification à froid Modification à chaud
Le fichier de paramètres ( PFILE et SPFINE init%.ora)
Structure physique

1 - 54
Introduction
Base de données
Tablespace
Fichier de
données
Segment
Extent
Bloc de
données Oracle
Système de stockage
• SAN
• NAS
• Exadata
• Système de fichiers
• NFS
• ASM
• RAW
Structures logiques Structures physiques
Structure Logique

1 - 55
Segments, extents et blocs
• Les segments existent dans un tablespace.
• Les segments sont des ensembles d'extents.
• Les extents sont des ensembles de blocs de données contigus.
• Les blocs de données sont mis en correspondance avec des
blocs du disque.
Segment Extents
Blocs de
données
Blocs du disque
(stockage dans
le système de
fichiers)
Structure Logique

1 - 56
Tablespaces et fichiers de données
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko 8 Ko
8 Ko
8 Ko
8 Ko
8 Ko
Tablespace 1
Fichier de
données 1
Fichier de
données 2
Extent
64 Ko
Extent
96 Ko
Segment
160 Ko
Tablespace 2 (Bigfile)
Fichier de
données 3
Un seul fichier de
données autorisé
<= 128 To
Structure Logique

1 - 57
Les tablespaces
 Les tablespaces
- Un tablespace est une unité logique qui correspond physiquement à un
ou plusieurs fichiers de données.
- L’administrateur (DBA) agit sur les tablespaces et non sur les fichiers de
données.
- Une BD est organisée sous forme de plusieurs tablespaces, chacun
correspondant à un contexte (thème).
- EX: On peut créer plusieurs tablespaces dans une BD d’une Ese
commerciale qui gère la FACTURATION, la GRH, et le PARC INFO.
Structure Logique

1 - 58
- Le tablespace FACTURATION  fact01.dbf et fact02.dbf
- Les tables FACTURE, LIGNE_FACTURE, PRODUIT, CLIENT, REGLEMENT.
- Le tablespace GRH  grh01.dbf
- Les tables PERSONNEL, PAIE, SANCTION etc.
- Le tablespace PARC  parc01.dbf
- Les tables EQUIPEMENT, CATEGORIE, REPARATION, MAINTENANCE etc.
- Avantage: On peut administrer par tablespace, et donc par partie (par rapport à la
BD). Par exemple, pour maintenir certaines tables relatives à la facturation, on peut
mettre uniquement le tablespace FACTURATION en offline, au lieu de rendre toute
la base indisponible ce qui touchera des centaines d’utilisateurs qui ont besoin de
manipuler les données de la GRH, PARC INFO etc.
Les tablespaces
Structure Logique

1 - 59
 Les tablespace
- Les vues DBA_TABLESPACES et DBA_DATA_FILES incluent toutes les
informations relatives aux tablespaces et aux fichiers de données de la
base.
- Pour afficher les noms des fichiers de données ainsi que les
tablespaces auxquelles ils correspondent:
SELECT tablespace_name, file_name
FROM DBA_DATA_FILES
ORDER BY tablespace_name;
L’occupation d’un tablespace voir la table DBA_EXTENTS*
Les tablespaces
Structure Logique

1 - 60
Structure de stockage
Database
Tablespace
Segment
Extension
Bloc de données
Fichier de
données
Bloc SE
Structure Logique Structure Physique
Segment
- C’est l’espace occupé par un objet base
de données (Table ou Index)
- Il existe 4 types de segments:
1. Segment table: espace occupé par une table
2. Segment index: espace occupé par un index
3. Segment d’annulation: espace qui inclut les
informations d’annulation
4. Segment temporaire: espace annexe à la
MC pour les opérations volumineuses.
Structure Logique

1 - 61
 Le segment d’annulation sert à stocker les données
nécessaires:
1. A l’annulation
Mémoire centrale
Disque
Le segment d’annulation
Update table1
set col1=A
Where col1=B;
Structure Logique

1 - 62
nécessaires:
1. A l’annulation
Disque
Mémoire centrale
Update table1
Set col1=A
Where col1=B;
En effet, la MAJ peut être effectuée sur
disque sans attendre un COMMIT.
Segment
table
Segment
d’annulation
Nouvelle
image (A)
La nouvelle image est enregistrée dans un segment table, l’ancienne dans un segment
d’annulation. Au cas où un ROLLBACK est effectué, c’est cette image qu’on utilisera pour
rétablir les données.
Ancienne
image (B)
Structure Logique

1 - 63
nécessaires:
1. A l’annulation
2. A la lecture cohérente (ou dite aussi consistante).
11:58
Update table1
set col1=A
Where col2=C;
12:01
Select col1 From table1
Where col2=C;
Nouvelle valeur ou
ancienne?
Ancienne valeur
Structure Logique

1 - 64
nécessaires:
1. A l’annulation
2. A la lecture cohérente (ou dite aussi consistante avant
validation/commit).
a. Si pas d’anticipation d’enregistrement des MAJ, Alors la lecture
se fait directement à partir du segment table.
b. Si anticipation d’enregistrement des MAJ, Alors la lecture se fait
à partir du segment d’annulation.
Structure Logique

1 - 65
 Le segment temporaire sert à stocker les données relatives à des
opérations volumineuses si la mémoire centrale ne suffit pas à les
exécuter.
Exemple d’opérations volumineuses:
- Certains tris.
- Certaines jointures.
- Création d’index.
- Etc.
Le segment temporaire
Structure Logique

1 - 66
Database
Tablespace
Segment
Extension
Bloc de données
Fichier de
données
Bloc SE
 Un segment est à son tour composé d’extensions
 Une extension est un ensemble de
blocs contigus appartenant à un même
fichier de données
 Par contre un segment peut s’étaler sur
plusieurs fichiers à travers ses
extensions.
 La taille d’un bloc de données est
définie par le paramètre
DB_BLOCK_SIZE
Extension
Structure Logique

1 - 67
Fact01.dbf Fact02.dbf
Segment A (Extent 1) Segment A (Extent 2)
Segment B (Extent 1)
Segment B (Extent 2)
Segment C (Extent 1)
Structure du tablespace FACTURATION
Database
Tablespace
Segment
Extension
Bloc de données
Fichier de
données
Bloc SE
Extension : Exemple
Structure Logique

1 - 68
Architecture d'une base de données Oracle

1 - 69

1 - 70

1 - 71

1 - 72

1 - 73

1 - 74

1 - 75

1 - 76

1 - 77

1 - 78

1 - 79

1 - 80

1 - 81

1 - 82

1 - 83

1 - 84

1 - 85

1 - 86
Deux architectures possibles:
client/serveur : des applications clientes envoient les requêtes SQL et
PL/SQL a un serveur. ( Voir TP)
architectures possibles:
Multitier : des serveurs d'application allègent la charge du
serveur en réalisant certains accès pour les clients.

1 - 87
pour se connecter au serveur oracle
il faut deux choses
Configuration Paramètre locale fichier
tnsnames.ora
Coté client
Coté serveur
Configuration Paramètre réseau fichier
listner.ora
SID_Alis =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.4)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)
LISTENER = (DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521 )) ) )
Configuration de Paramètres de nommage locaux (tnsnames.ora) et
réseau (Lisner.ora)

1 - 88
Synthèse
Ce chapitre vous a permis d'apprendre à :
• énumérer les principaux composants de l'architecture d'une
base de données Oracle
• décrire les structures mémoire
• décrire les processus en arrière-plan
• définir la relation entre les structures de stockage logiques
et physiques

1 - 89
TD N°1
1) Citer le cycle de vie d’une base de données
2) Quel est la différence entre Un serveur BD en mode DÉDIÉ, et en mode
PARTAGÉ.
3) A Quoi servent les deux fichier (tnsnames.ora) et Lisner.ora)
4) Quel est le nom du paramètre ou est définit La taille d’un bloc de données
5) Que contient Les deux vues DBA_TABLESPACES et DBA_DATA_FILES
6) Donner la commande qui permet d’ajouter un fichier log
7) Quelle est la relation entre les fichiers de données (datafiles) et les tablespaces
8) Citer quelques taches qu’effectue les processus DB Writer (DBWn), SMON , et
PMON
9) Quel est le nom de la zone de mémoire contenant des données et des
informations de contrôle pour un processus serveur ou un processus en
arrière-plan ?
10)Représenter dans un schéma de l’architecture de l’SGDB oracle

1 - 90
1) Le cycle de vie d’une base de données
Conception , Implémentation , Utilisation (exploitation ), maintenance et
administration
9) Le nom de la zone de mémoire contenant des données et des
informations de contrôle pour un processus serveur ou un processus
en arrière-plan
PGA
10) un schéma synaptique de l’architecture de l’SGDB oracle
Note: La correction complète est faites en classe

Chapitre 3 :
Création de la structure d’une base de données
 Phase de réflexion
 Création de la base de données: Graphiquement DBCA et
manuellement
 Création et Gestion des tablespaces et des tables et
tablespace Undo
 Rappels sur les indexes Principes choix et création : index
btree , BitMap
 Alimentation d'une base de données: le sqlloader

Avant création, et pour faire les bons choix:
Réfléchir aux tables et indexes à venir, estimer leur taille
Planifier la distribution de ses fichiers, l’espace libre dans les
blocks
Décider entre une gestion classique ou automatique des fichiers
Déterminer la taille des blocs de données
Choisir le mode de gestion de l’annulation, Tablespace dédié
Segments d’annulation
Déterminer la stratégie de sauvegarder et reprise après panne
-reprendre l’etat de sauvgarde
- Dérouler le fichier de journalisation
-réplication
Chapitre 3: Créer une base de données
Création de la base : Phase de réflexion

Deux possibilités:
Utiliser l’assistant Oracle : graphique : DBCA
Créer manuellement à l’aide de scripts
En cas de mise à jour d’Oracle ou de migration ,
une procédure particulière existe Compatibilité
ascendante, on ne recrée pas les bases de données.
Pré requis :
Oracle doit-être installé
Vous devez être administrateur du SE et de l’instance
La mémoire principale et mémoire disque doit être
suffisante
Chapitre 3 : Créer une base de données
Création de la base : Généralités

■ Une Base de données comporte les états suivants
Création de la base : États de la l’instance ( base)

Les Privilèges utiles
Les Privilèges nécessaires pour créer, démarrer ou arrêter une base
 SYSDBA (arrêt, démarrage, modification, création d’ une base, …)
 SYSOPER(arrêt démarrage d’une base, modification)
Chapitre 3 : Créer une base de données
Création de la base : États de la base

1. Démarrer l’assistant
 Soit par start->programme->OracleHome->Configuration and
Migration Tools-> Database Configuration Assistant
 Ou bien on tape DBCA dans l’invite DOS ( ou dans un terninal en
cas Linux et Unix)
2. Choisir créer une base
3. Choisir un template (modèle) de base
4. Donner le nom global de la base (exemple DBTEST) ainsi que le SID
(DBTEST)
5. Sélectionner le mode de déploiement de la base (mode dédié) ou
(mode serveurs multithreads)
6. Fixer la taille de la SGA(buffer cache, shared pool, large pool, java
pool)
7. sélectionner le mode d’archivage de la base (Archivelog ou
noarchivelog).Localiser les fichiers d’archive
8. Fixer la taille maximale de la zone de tri ainsi que les caractères sets
9. Localiser les fichiers de contrôles, de données et redo log
10. Modifier à tout moment les paramètres d’itialisation supplémentaires
et démarrer la création de la base
Création de la base : Étapes à suivre pour créer une
base avec le Database Configuration Assistant: DBCA

Création de la base : Étapes pour créer une base Manuellement
Spécifier le nom de l'instance SID : ( ici DB1 )
positionner les variable : oracle_home=D:apphpproduct11.2.0dbhome_1
oracle_base=D:apphp et oracle_sid= DB1
Créer le fichier de paramètres PFILE (partir de l'exemple Oracle init%.ora)
(D:apphpadminorclpfileinit.ora)
Nom de la base, emplacement des fichiers de contrôle ….
Créer le fichier de mot de passe - orapwd file=orapwDB1 password=Test01;
Pour windows executer : oradim -new -sid DB1
Se connecter a l'instance inactive
SQLPLUS nolog puis CONNECT AS SYSDBA
STARTUP PFILE='D:apphpadminDB1pfileinit.ora' nomount
Créer un fichier de paramètre serveur SPFILE (D:apphpproduct11.2.0dbhome_1database)
(a partir du fichier manuel)  Create SPFILE from PFILE
SQL> create SPFILE='D:APPHPPRODUCT11.2.0DBHOME_1DATABASESPFILEDB1.ora' from
PFILE='D:apphpadminDB1pfileinit.ora'; ;
Mon noyau oracle (ORACLE_BASE )est installé sous D:apphp
À l’aide la commade MKDIR on crée les répertoires suivant :
D:apphpadmin , D:apphporadata , D:apphpadminDB1,
D:apphporadataDB1 , D:apphpadminDB1bdump , D:apphpadminDB1cdump
D:apphpadminDB1pfile et D:apphpadminDB1udump,
D:apphpflash_recovery_areaDB1

CREATE DATABASE DB1
USER SYS IDENTIFIED BY pz6r58
USER SYSTEM IDENTIFIED BY y1tz5p
LOGFILE GROUP 1 ('D:apphporadataDB1redo01.log') SIZE 100M,
GROUP 2 ('D:apphporadataDB1redo02.log') SIZE 10M,
GROUP 3 ('D:apphporadataDB1redo03.log') SIZE 10M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE 'D:apphporadataDB1system01.dbf' SIZE 320M REUSE
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE 'D:apphporadataDB1sysaux01.dbf' SIZE 320M REUSE
DEFAULT TABLESPACE tbs_1
DATAFILE 'D:apphporadataDB1users01.dbf' SIZE 50M REUSE AUTOEXTEND ON
MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE 'D:apphporadataDB1temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undotbs1
DATAFILE 'D:apphporadataDB1undotbs01.dbf'
SIZE 20M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

création des vues et synonymes publics (CATALOG.SQL)
• Installation de l'option procédurale(CATPROC.SQL)
• création des synonymes publics pour les tables virtuelles (UTLMONTR.SQL)
• Création des Synonymes sur les vues dba_* du dictionnaire (CATDBSYN.SQL) pour
le DBA
 Le chemin de ces scriptes .sql est :
{ORACLE_HOME}RDBMSADMIN
Sur Mon PC : D:apphpproduct11.2.0dbhome_1RDBMSADMIN
Créer de nouveaux tablespace, par exemple :
- Un USERS pour les utilisateurs
- un INDX pour les index
Lancer les scripts de création du dictionnaire (catalog.sql,catproc.sql) et
éventuellement d'autres scripts optionnels
(suite)

Précisions sur les paramètres de l'instance (pfile)
le nom de la base ne comporte que 8 caractères
créer au moins deux fichiers de controles
Sur des disques diferents si possible
Laisser Oracle choisir la taille des blocs
On peut contrôler la SGA
En lui fixant une taille maximale
en fixant la taille de différents composants
On peut changer la taille plus tard, de façon dynamique
On peut fixer le nombre de processus autorisés
On doit choisir un mode de gestion des annulations
Comment on gère les données d'annulation ? (Avant Commit)
Automatique : gérées dans un tablespace
Manuel : gérées dans les segments d'annulation (Undo)
(suite)

Remarques complémentaires:
Si la création échoue, visualiser le chier d'alertes (show parameter user_dump)
Arrêter l'instance
Supprimer les fichiers crées pendant la tentative
Pour supprimer une base : ( commande drop database)
La base doit être montée et fermée
sql> shutdown immediate;
sql> startup mount exclusive restrict
sql> Drop database ;
Conserve les fichiers d'archivage et les copies
Pour modifier des paramètres
Les commandes ALTER SYSTEM pour les paramètres d'instance (modifie le SPFILE,
pas le PFILE !)
La commandesALTER DATABASE pour revenir sur les choix du CREATE DATABASE
Pour voir les informations sur la base
Show parameters, vues 'database_properties' et V$DATABASE
(suite)

Cote serveur
Un processus d‘écoute utilisant un protocole réseau :
listenerSID
Un serveur BD Oracle = instance + base
Les configurations (services d‘écoute) sont enregistrées dans
listener.ora
Éditable a la main, ou via outils graphiques
Côte client
Configurations (services d'acces) enregistrées dans tnsname.ora
Permet au client de se connecter de façon transparente
Éditable a la main, ou via outils graphiques
Configuration du reseau
(suite)

 Positionner les variables d'environnement ORACLE_SID et ORACLE_HOME
Démarrage de la base possible par paliers (startup nomount, startup mount,
et startup open)
Posséder les privilèges appropriés (SYSDBA, SYSOPER, OSDBA ou OSOPER, ...)
 Indiquer si nécessaire le fichier des paramètres
■ Syntaxe de la commande
 STARTUP [FORCE] [RESTRICT] [PFILE=fich_param] [OPEN | MOUNT |
NOMOUNT]
ALTER DATABASE [nom_base] MOUNT | OPEN
Création de la base : Démarrage d'une base :Procédure
Générale

■ Description des mots et paramètres
FORCE Si instance ouverte, Fermeture puis démarrage
RESTRICT sert à des tâches de maintenance. Il faut avoir
le privilège Restricted Session
PFILE Indique le fichier des paramètres
OPEN démarrer et ouvrir les fichiers de la base
MOUNT Instance démarrée fichier(s) de contrôle ouvert(s)
NOMOUNT Seule l'instance est démarrée
ALTER DATABASE : permet le démarre par paliers après un
startup NOMOUNT ou MOUNT
Création de la base : Démarrage d'une base

■ Exemple
• Variables d’environnement
Unix $export ORACLE_SID = COURS
 $ export ORACLE_HOME=useroracle
Windows  Set ORACLE_SID = COURS
 set ORACLE_HOME=D:apphpproduct11.2.0dbhome_1
Lancer SQLPLUS $sqlplus username : sys as sysdba
démarrer et ouvrir les fichiers de la base
SQL >startup ; oubien $ SQL>startup OPEN
pfile=D:apphpproduct11.2.0dbhome_1dbsinitCOURS.ora;
 démarrer la base par paliers
-Instance démarrée, fichiers de contrôles ouverts SQL >startup mount ;
- En plus les fichiers de données sont ouverts SQL > alter database open ;
Création de la base : Démarrage d'une base

Posséder les privilèges OS (osdba, osoper)
positionner les variables d'environnement (ORACLE_SID et ORACLE_HOME)
Lancer l'outil SQLPLUS
■ Syntaxe de la commande:
SHUTDOWN [NORMAL | IMMEDIATE | ABORT | TRANSACTIONAL]
– NORMAL attend la déconnexion de l'ensemble des utilisateurs
– IMMEDIATE Invalide les transactions en cours et déconnecte les users
– ABORT Arrêt violent de l'instance (recouvrement utile : SMON)
- TRANSACTIONAL Contrairement à IMMEDIATE, laisse finir les transactions en cours
Création de la base : Arrêt d'une base:■ Procédure Générale

• Positionner les variables d'environnement (UNIX)
$export ( set dans Windouws) ORACLE_SID=COURS
$export ( set dans Windouws) ORACLE_HOME=usersoraclev9
• Lancer SQL $SQL sys as sysdba
1- arrêt normal avec attente de déconnexion : SQL>shutdown
2- Ou Arrêt immédiat : Annulation des transactions en cours et déconnexion
: SQL>shutdown immediate ;
Les utilisateurs ont le message suivant :
ORA-03113 : end-of-file on communication channel
3- ou Arrêt brutal (pas d’attente de déconnexion, pas d'invalidation de
transactions en cours) : SQL >shutdown abort;
Création de la base : Arrêt d'une base
■ Exemple

Création et Gestion des tablespaces et tables: tablespaces
Rappel

Espace de stockage logique des objets
Un tablespace = plusieurs fichiers de donnees
Un seul dans le cas des tablespace a gros chier (bigfile)
Il est necessaire d'utiliser plusieurs tablespace :
Separer les donnees des utilisteurs du dictionnaire
Separer les donnees d'applications différentes, pour alléger les accès et
réduire les risques de panne des applications
Tablespaces optimisés pour certaines tâches : lecture seule ou mises a jour
fréquentes, espace temporaire
Sauvegarde individuelle des tablespace
Stocker un tablespace par disque, pour réduire les
concurrences ES
Pour chaque utilisateur il faut assigner un quota
Création et Gestion des tablespaces et tables : tablespaces
Rappel : grande lignes

Tablespaces Ordinnaire Stockets les données
Liés aux tables.
Tablespace d'annulation, pour les opérations non valides
Tablespaces temporaires : pour la gestion des tris
Une instance + un tablespace = un segment de tri
Affectés à chaque utilisateurs
Forcement à gestion locale depuis 10g
ne génère pas d‘écriture dans les fichiers de reprise
* Pour vérifier le statut de nos tablespace voilà une requête :
 SELECT tablespace_name, status, contents, extent_management FROM dba_tablespaces;
Différents types de tablespaces

Bigfilele tablespaces (jusqu'a 128 tera)
Lorsqu'on a besoin de plus de capacite (64 000 fichiers de données au maximum)
Simplifie la gestion du tablespace (un seul fichier)
Uniquement pour les tablespace a gestion locale et automatique de l'espace
Différents types de tablespaces (suite)

Tablespace créé par défaut lors de la création de la base
contient le dictionnaire de données
contient un Rollback segment créé par défaut SYSTEM
il est déconseillé d'y stocker des données autres que celles du dictionnaire
Le tablespace SYSTEM

CREATE TABLESPACE <tablespacename>
DATAFILE <filename> SIZE <nn> AUTOEXTEND ON|OFF
TEMPORARY|PERMANENT
EXTENT MANAGEMENT LOCAL|DICTIONARY
LOGGING|NOLOGGING
ONLINE|OFFLINE
SEGMENT SPACE MANAGEMENT MANUAL|AUTO
113
Ajout possible d’autre fichier, separé par la virgule
Clause obligatoire pour la gestion des fichier par manuellement
Clause optionnelle pour la gestion des fichier par oracle(OMF)
On peut specifier la taille dans les deux cas
Note: il y a d’autre clauses optionnels
Syntaxe Création de tablespace

TEMPORARY|PERMANENT
LOGGING|NOLOGGING
ONLINE|OFFLINE
114
TEMPORARY: est utilisé dans le cas des tablespaces
temporaire gérer par le dictionnaire oracle
PERMANENT: Option par Default; stocker les objects
(tables et indexes) d’une façon permanente

TEMPORARY|PERMANENT
LOGGING|NOLOGGING
ONLINE|OFFLINE
115
LOCAL: option par défault; gere les extents libres free
par un index bitmap dans la tablespace
DICTIONARY: le tablespace gere les extents libre par le
dictionnaire
Note: D’autres option peuvent etre ajouté ( voir la suite)

TEMPORARY|PERMANENT
LOGGING|NOLOGGING
ONLINE|OFFLINE
116
LOGGING: Par Default; tout les DML, DDL, et les insertion
INSERT en masse sont enregistrés dans le redo log
NOLOGGING: Sauf les commandes DML sont enregistrés
dans le redo log

TEMPORARY|PERMANENT
LOGGING|NOLOGGING
ONLINE|OFFLINE
117
ONLINE: Par Default; le tablespace est prét à utilisé
OFFLINE: le tablespace n’est encore prét à utilisé

TEMPORARY|PERMANENT
LOGGING|NOLOGGING
ONLINE|OFFLINE
118
AUTO: gere les espace libre des segment dans un bitmap
dans la tablespace
MANUAL: gere les espace libre des segment dans le
dictionnaire de données oracle

CREATE TABLESPACE APPLI_PERSONNEL
DATAFILE 'homeFichier1_app_pers.dbf‘ SIZE 100M,
'homeFichier2_app_pers.dbf‘ SIZE 10M
DEFAULT STORAGE ( INITIAL 100K NEXT 50K MINEXTENTS 4
MAXEXTENTS 100 PCTINCREASE 25 )
EXTENT MANAGEMENT DICTIONARY;
Exemple
PCTINCREASE 25 veut dire :
Taille de L’extent suivant = taille de l’extent précédent +25%
storage (initial 100K next 50K minextents 1 maxextents 30 pctincrease 5);
-max 30 extents, le premier à une taille de 100K, le suivant de 50K, puis 5% de plus :
(si un bloc = 4K, ) Le 3eme extent est de : 50K+5%=52.5K=13 blocs

Création des tablespaces gérés dans le dictionnaire ( gestion manuelle)
 Généralités
– Les informations sur les extensions des segments sont gérées dans le
dictionnaire
– C’ est l’ approche historique de création de tablespaces sous Oracle jusqu’ à la
version 8i
 Les extensions des segments peuvent avoir des tailles différentes
 Les extensions sont définies par le DBA en s’ appuyant sur les clauses
DEFAULT STORAGE du tablespace ou STORAGE d’ un segment
 Ce type de tablespace à partir de la version 9i ne peut être crée que si le
tablespace System est lui même géré dans le dictionnaire
Tablespaces gérés par le Dictionnaire

 Exemple1
SQL> CREATE TABLESPACE APPLI_COMPTA
DATAFILE 'homeFichier1_app_cpt.dbf‘ SIZE 10M AUTOEXTEND ON NEXT 10M
MAXSIZE UNLIMITED EXTENT MANAGEMENT DICTIONARY;
 Exemple2
SQL> CREATE TABLESPACE APPLI_PERSONNEL
DATAFILE 'homeFichier1_app_pers.dbf'SIZE 100M, 'homeFichier2_app_pers.dbf‘
SIZE 10M DEFAULT STORAGE ( INITIAL 100K NEXT 50K MINEXTENTS 4
MAXEXTENTS 100 PCTINCREASE 25 )
EXTENT MANAGEMENT DICTIONARY;
Création des Tablespaces gérés par le Dictionnaire

– Un tablespace géré localement prend en charge la gestion de ses extent
– une Bitmap est créé dans l'entête de chaque fichier pour identifier les Blocs ou les
Extents
– c’est l’Option par défaut d’ Oracle
La taille d’une extension ici peut être calculée automatiquement (AUTOALLOCATE) on
peut la fixe (UNIFORM SIZE…)
Si l'on utilise la clause AUTOALLOCATE Oracle détermine la taille optimale des
extensions de chaque segment avec un minimum de 64K. Vous pouvez préciser la taille
de l’extension INITIALE lors de la création du segment. Oracle s’ en sert pour calculer
la taille des extensions du segment
Si l'on utilise la clause UNIFORM SIZE toutes les extensions de tous les segments
auront la même taille : celle spécifiée lors de la création du tablespace ou celle part
défaut qui est de 1Mo
Tablespaces gérés localemnt

Avantages par rapport a ceux gérés via le Dictionnaire :
– défragmentation automatique du Tablespace
NOTES :
– Les paramètres de stockage NEXT, PCTINCREASE, MINEXTENTS,
MAXEXTENTS, DEFAULT STORAGE sont ignorés pour les Tablespaces
gérés localement
– Avec la clause UNIFORM SIZE INITIAL n’est pas non plus pris en
compte
Création de Tablespaces gérés localemnt
BLOCKSIZE. Taille du bloc utilisée par le Tablespace. (2k, 4K, 8K, 16K, 32K,64k)
Sql> SHOW PARAMETER DB_BLOCK_SIZE

Exemple 3 :
Création d'un tablespace Local avec la clause AUTOALLOCATE (option par défaut)
Sql> CREATE TABLESPACE TSLOCAL DATAFILE ‘D:ts_local1m.dbf' SIZE 10M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
Sql>
CREATE TABLE TestLocal(c1 char(4))
storage(initial 1m next 500K minextents 2 maxextents 6) tablespace tslocal
Sql>
select SEGMENT_NAME , EXTENT_ID, BYTES, BLOCKS
from dba_extents where SEGMENT_NAME like ‘TESTLOCAL’;
SEGMENT_NAME EXTENT_ID BYTES BLOCKS
TESTLOCAL 0 10485760 128 ---
TESTLOCAL 1 10485760 128
On voit bien que dans autoallocate le paramètre initial de stockage détermine le nombre
de blocs le reste des paramètres est ignoré (RQ: le bloc oracle =8ko)
Création de Tablespaces gérés localemnt
taille de segment
en bloc oracle
128x8ko=1M

Exemple 4 : Création d'un tablespace Local avec la clause UNIFORM SIZE
Sql> CREATE TABLESPACE tslocaluniform DATAFILE
'F:oracleoradatadbtestsTSLOCALts_local_unif1.dbf' SIZE 10M EXTENT
MANAGEMENT LOCAL UNIFORM SIZE 200K;
Sql> CREATE TABLE Testuniform1(c1 char(4)) tablespace tslocaluniform storage(initial
100k next 50K minextents 1 maxextents 2);
Sql> select SEGMENT_NAME , EXTENT_ID, BYTES, BLOCKS
from dba_extents where SEGMENT_NAME ='TESTUNIFORM1';
SEGMENT_NAME EXTENT_ID BYTES BLOCKS
TESTUNIFORM1 0 204800 25
Création de Tablespaces gérés localement
SEGMENT_NAME nom de segment associé à l'extent
TABLESPACE_NAME nom de tablespace qui contient l'extent
EXTENT_ID numero de lExtent dans le segment
BYTES Taille de l'extent en bytes
BLOCKS Taille de segment en bloc oracle
25x8ko=200K

1) Tablespaces à gestion locale des extents (par défaut !)
 Gère la mémoire locallement avec des bitmaps
 Améliore les performances
 Allège les accès au dictionnaire
 Permet le choix automatique de l’unité d’extention
 Autorise la gestion automatique de l’espace dans les segments peut s’appliquer à tous les tablespaces
2) Tablespaces gérer par le dictionnaires
 Gestion plus précise
 Nécessite une fusion périodique des extents libres ( défragmentation manuelle)
Gestion des tablespaces : Locale VS Dictionnaire

Les tablespaces temporaires
Lorsqu'une requête nécessite un tri qui ne peut pas s'exécuter en mémoire (dans la PGA),
Oracle peut utiliser soit:
•un segment temporaire créé dans n'importe quel tablespace permanent. À éviter, puisqu’à
chaque tri, le segment temporaire sera alloué et libéré. Mauvais pour la performance et pour
la fragmentation.
•Ou un segment temporaire créé dans un tablespace temporaire. Dans ce cas, un segment
de tri est créé par le 1er tri ( 1ere requête) et réutilisable par les tris suivants.
Ce segment est libéré uniquement lors de l’arrêt de l’instance.
- Ces tries peuvent provenir des ordres SQL contenant :
ORDER BY, GROUP BY, DISTINCT, UNION, INTERSECTION, MINUS, CREATE INDEX, SORT,
MERGE …
Création et Gestion des tablespaces et tables :
Tablespaces temporaire

Exemple de création :
CREATE TEMPORARY TABLESPACE lmtemp
TEMPFILE '/u02/oracle/data/lmtemp01.dbf' SIZE 20M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;
Un tablespace temporaire à un fonctionnement particulier :
- Les modifications ne sont pas enregistrées dans les fichiers de journalisation/redo-log.
- ll ne peut pas être renommé ou déplacé (doit le détruire et le recréer)
Tablespaces temporaire (suite)

Toutes les données d’annulation sont stockées dans un tablespace spécial appelé « UNDO ».
Lorsque vous créez un tablespace « UNDO », Oracle gère le stockage, la rétention et l’emploi de
l’espace pour les données de rollback par l’intermédiaire de la fonction SMU (System-Managed
Undo). Aucun objet permanent n’est placé dans le tablespace undo. Pour pouvoir créer un
tablespace undo à la création de la base de données, il faut prendre soin d’initialiser le paramètre
UNDO_MANAGEMENT=AUTO
Tablespaces UNDO

Rappelez-vous, la syntaxe SQL de création de la base de données comporte
d’abord la création d’un tablespace « SYSTEM » et d’un tablespace « SYSAUX »,
ainsi que la création de tablespaces « TEMP » et « UNDO ».
Attention ! À la création de la base de données, si vous ne précisez pas de
tablespace undo, Oracle crée un tablespace undo appelé « SYS_UNDOTS ».
Le paramètre « UNDO_TABLESPACE » doit avoir la valeur «
SYS_UNDOTS », sinon la base de données ne pourra pas être créée.
Tablespaces UNDO (suite)

La syntaxe de création d’un tablespace UNDO est :
CREATE {BIGFILE|SMALLFILE} UNDO TABLESPACE nom_tablespace
[ DATAFILE ['nom_fichier'] [ SIZE integer {K|M|G|T} ]
[ AUTOEXTEND {OFF | ON [ NEXT integer {K|M|G|T}] [ MAXSIZE {UNLIMITED | integer
{K|M|G|T}]} ] [,...] ] [{ONLINE | OFFLINE}] ;
____________________________________________________________
UNDO : Indique que le tablespace est de type undo.
Attention!
Le tablespace « UNDO » par défaut est celui qui est précisé dans le paramètre « UNDO_TABLESPACE
Sql> show parameter undo_tablespace
NAME TYPE VALUE
------------------------------------ ----------- --------
undo_tablespace string UNDOTBS1

Sql> create undo tablespace undobis datafile ‘D:fich1.dbf’
size 512m autoextend on next 512m;
Sql> alter system set undo_tablespace =undobis; ( pour activer undobis comme undo)
Système modifié.
Sql> show parameter undo_tablespace
NAME TYPE VALUE
------------------------------------ ----------- -------
undo_tablespace string UNDOBIS
Les information sur l’UNDO sont dans les paramètres suivants : ( show parameter …)
undo_management : Paramètre précisant la méthode de gestion des UNDO (AUTO ou
MANUAL).
undo_tablespace : Tablespace dans lequel seront stockées les informations d'annulation
undo_retention : Durée de rétention des UNDO qu'Oracle va tenter de respecter s'il n'a pas
besoin d'espace supplémentaire

Consulter les table et vues de dictionnaire
DBA_TABLESPACES
V$TABLESPACE
 DBA_DATA_FILES
 V$DATAFILE
DATABASE_PROPERTIES
Vérification de statut des tablespace:
select status,contents, tablespace_name from dba_tablespaces
Information sur les tablespaces et les fichiers de données

La vue DBA_DATA_FILES va nous permettre de déterminer la taile d'un tablespace,
La vue DBA_EXTENTS permet de connaitre la taille de tous les segments dans les
différents datafiles,
La vue DBA_FREE_SPACE qui indique les espaces libres dans les database files.
Information sur les tablespaces et les fichiers de données (suite)
SELECT A.tablespace_Name, A.Alloue, B.Occupe, C.Libre FROM
(SELECT tablespace_name, sum(bytes)/1024/1024 AS ALLOUE FROM dba_data_files GROUP BY
tablespace_name) A,
(SELECT tablespace_name, Sum(bytes)/1024/1024 AS OCCUPE FROM dba_segments
GROUP BY tablespace_name) B,
(SELECT tablespace_name, Sum(bytes)/1024/1024 AS LIBREFROM dba_free_space GROUP BY
tablespace_name) C
WHERE B.tablespace_Name = A.tablespace_Name AND C.Tablespace_Name =
B.Tablespace_Name;
La requête suivante vous permet de récupérer toutes ces informations

Modification des tablespaces
Renommer un tablespace
ALTER TABLESPACE ancien RENAME TO nouveau;
Ajouter ou supprimer un fichier de données
ALTER TABLESPACE nomTablespace ADD DATAFILE emplacementnomFic SIZE 100M;
ALTER TABLESPACE nomTablespace DROP DATAFILE emplacementnomFic ;
Modifier la taille d’un fichier de données
ALTER database datafile emplacementnomFic RESIZE 55M
Placer un tablespace hors ligne
ALTER TABLESPACE nomTablespace OFFLINE [ NORMAL ];
Placer un tablespace en mode lecture seule
ALTER TABLESPACE nomTablespace READ ONLY (au lieu de READ WRITE);
Supprimer un tablespace
DROP TABLESPACE nomTablespace INCLUDING CONTENTS AND DATAFILES;
- Attention : Ce n’est pas une opération où il y un ROLLBACK possible. À utiliser avec précaution ! Il
est également conseillé de mettre le tablespace OFFLINE avant de le supprimer.

• Pour créer une table il faut l’associer à un tablespace si non elle est associer
au tablespace par défaut ( SYSAUX)
• On peut aussi spécifier le type de stockage
Syntaxe :
CREATE TABLE NOM_Table (………) [tablespace nom_tablespace ]
[Storage (initial N1 [k,M,G] next N2 [K,M,G]
minextents N3 maxextents N4 ) ] ;
(N1,N2,N3,N4 sont des nombre entiers )
Exemples :
1- SQL> CREATE TABLE TestLocal(c1 char(4) ) tablespace tslocal
storage(initial 500k next 500K minextents 4 maxextents 10);
2- CREATE TABLE Testuniform1(c1 char(4)) tablespace tslocaluniform
storage(initial 100k next 50K minextents 1 maxextents 2);
Création Les tables

Rappels sur les indexes : Principes choix et
création : index btree , BitMap
Les indexes

L’index est utile pour accélérer l’exécution d’une requête SQL qui lit des données et ainsi
améliorer les performances d’une application utilisant une base de données
Les 2 types d’index les plus utilisé dans Oracle :
Arbres équilibrés (B-arbre) : toutes les branches de l’arbre ont la même longueur
Il est efficace lorsque les données indexés ne sont pas répétés ( Clé primaire , données uniques)
 Bitmap : Si peu de valeurs sont possibles pour les données répétées, une chaine de bits pour chaque
valeur
Un index est un objet complémentaire (mais non indispensable) à la base de données permettant d'"indexer"
certaines colonnes dans le but d'améliorer l'accès aux données par le SGBDR, au même titre qu'un index dans un livre
ne vous est pas indispensable mais vous permet souvent d'économiser du temps lorsque vous recherchez une partie
spécifique
Qu'est-ce qu'un index?
Les indexes (suite)

De manière générale, un index est créé automatiquement lors de la création de la clé
primaire d'une table ;
de la même manière, il est d'usage d'un créer un pour chaque clé étrangère afin d'améliorer
la vitesse lors des jointures.
Un index peut être :
 Simplement le stockage des données d'une colonne de table qui sera souvent
sollicitée (surtout au niveau des recherches)
 L'ensemble de plusieurs colonnes qui feront l'objet de requête pour les recherches.
Création de l’index
Les indexes (suite)

• Quand créer un index
-----------------------------
 Attributs utilisées dans des jointures,
 Attributs servant souvent pour les sélections,
 Table de gros volume dont la majorité des
interrogations sélectionne moins de 15% des
lignes,
• Quand ne pas créer un index
-------------------------------
 Attributs souvent modifiés (index à
recréer...),
 Table de petit volume,
 si requêtes sur NULL car les NULL, non
stockés dans l’index. (ex : WHERE ... IS
NULL).
Bitmap : attribut à peu de valeurs distinctes,
B-arbre : attribut à beaucoup de valeurs distinctes.
Création de l’index
Les indexes (suite)

La création d'index en SQL se fait grâce à la clause INDEX précédée
de la clause CREATE. Elle permet de définir un index désigné par son nom, portant
sur certains champs d'une table.
La syntaxe est la suivante :
CREATE [UNIQUE] [BITMAP]INDEX Nom_de_l_index ON Nom_de_la_table
(Nom_de_champ [ASCDESC], ...)
Tablespace nom_tablespace_des_index ;
•L'option UNIQUE permet de définir la présence ou non de doublons pour les
valeurs de la colonne
•L'option BITMAP Index de type bitmap
•Les options ASCDESC permettent de définir un ordre de classement des valeurs présentes
dans la colonne
•Supprimer l’INDEX  DROP INDEX Nom_Index
Les indexes (suite)

0-100
-------------
101-200
-------------
-----
………….
-------------
----
301-400-
Branches
( Branch Blocks)
0-33
-----------
34-67
----------
68-100
101-134
-----------
135-167
----------
167-300
0 Rowid
-----------
1 Rowid
----------
…
-------
33 Rowid
34 Rowid
-----------
35 Rowid
----------
…
-------
67 Rowid
68 Rowid
-----------
69 Rowid
----------
…
-------
100Rowid
101 Rowid
-----------
102Rowid
----------
…
-------
134Rowid
135Rowid
-----------
136Rowid
----------
…
-------
167Rowid
168Rowid
-----------
169Rowid
----------
…
-------
300Rowid
Nœud racine
( Root Node)
Feuilles
( Leaf Blocks)
Le segment de la table
Table segment

22
-3
8
5
6
7
2
35
30
20
-5
25
12
10
6
22
-3
8
5
20
7
2
35
30
6

Les valeurs inférieures sont à gauche
Les valeurs Supérieures sont à droit
Comment ça marche L’index B-Tree ( L’arbre Binnaire)

La Recherche
20
10
8
6
5

L’Insertion
20
10
11
5 11

Suppression
20
10
5 7
8
6
7

Suppression
2
5
2

Suppression
20
20
30
25
22
22

15
0
L’index Bitmap Select nom, prenom, job_id from employees
ID NOM Prenom Job_id-
---------------------------------------------------------------------------
101 Neena Kochhar AD_VP
102 Lex De Haan AD_VP
103 Alexander Hunold IT_PROG
104 Bruce Ernst IT_PROG
107 Diana Lorentz IT_PROG
108 Nancy Greenberg FI_MGR
109 Daniel Faviet FI_ACCOUNT
110 John Chen FI_ACCOUNT
111 Ismael Sciarra FI_ACCOUNT
112 Jose Manuel Urman FI_ACCOUNT
113 Luis Popp FI_ACCOUNT
115 Alexander Khoo PU_CLERK
116 Shelli Baida PU_CLERK
117 Sigal Tobias PU_CLERK
118 Guy Himuro PU_CLERK
119 Karen Colmenares PU_CLERK
120 Matthew Weiss ST_MAN
121 Adam Fripp ST_MAN
122 Payam Kaufling ST_MAN
123 Shanta Vollman ST_MAN
124 Kevin Mourgos ST_MAN
125 Julia Nayer ST_CLERK
126 Irene Mikkilineni ST_CLERK
127 James Landry ST_CLERK
128 Steven Markle ST_CLERK
105 David Austin IT_PROG
106 VallPataballa IT_PROG
1 2 3 4 5 6 7 8 …
ST_CLERK 0 0 0 0 0 0 0 0 ..
ST_MAN 0 0 0 0 0 0 0 0 ..
FI_ACCOUNT 0 0 0 0 0 0 1 1 ..
PU_CLERK 0 0 0 0 0 0 0 0 ..
IT_PROG 0 0 1 1 1 0 0 0 ..
AD_VP 1 1 0 0 0 0 0 0 ..
Select * from employees where job_id like
‘FI_ACCOUNT’
L’index Bitmap n’est pas utilisé (exploité) quand
la clause est ( not like , not in , different <>, null)

Exemple de création d’index
Créer l’index :
CREATE UNIQUE INDEX idx_clients ON clients(no_client) tablespace index1
CREATE BITMAP INDEX idx_empl ON departments (department_name)
tablespace indextbs
Supprimer l’index  DROP index idx_empl
Les indexes (suite)

Chapitre V:
Administration des
et gestion de comptes d’une base
de données Oracle
 Dictionnaire de Données Oracle
 Gestion des utilisateurs
 Privilère , Roles et Profiles utilisateurs

Dictionnaire de Données Oracle
 Définition: C’est un certain nombre de tables et vues
qui contient un ensemble d’information liée à l’activité et
au fonctionnement de la base de donnée
 Et ce pour:
Récupérer les information nécessaire à l’exploitation et à
l’administration de la base de donnée Oracle

 Caractéristiques
 Appartient à l’utilisateur SYS
 Stocke les informations sur:
 La base de données (structure logique et physique)
 Le nom et les définitions des différents objets crées
 Les contraintes sur les objets
 Les users de connexions et leur caractéristiques (ex:
privilèges)

Toutes les informations contenues dans les tables système du
dictionnaire des données et accessibles au travers de vues sont codées
en MAJUSCULES.
Exp: selecte * from all_tables where table_name like ‘JOBS’;
Le dictionnaire des données est mis automatiquement à jour après
chaque instruction SQL du LMD (INSERT, UPDATE, DELETE, …).
Majuscule

Les vues du dictionnaire de données sont :
DBA_* : informations sur les objets de tous les schémas
USER_* : informations sur les objets appartenant au compte connecté
ALL_* : informations des vues USER_* et des informations sur les objets
pour lesquels des privilèges ont été octroyés au groupe PUBLIC ou à
l’utilisateur courant
Liste des vues du dictionnaire
• DICTIONARY ou DICT

Démarche à suivre
La démarche à suivre afin d’interroger correctement le dictionnaire des données à
propos d’un objet est la suivante :
Étape 1 : trouver le nom de la vue en consultant DICTIONARY
Étape 2 : choisir les colonnes de la vue à sélectionner (utiliser DESC) ;
Étape 3 : interroger la vue en exécutant une requête SELECT contenant les colonnes
intéressantes.
NB : Étape 1 peut être omise si on connaît déjà le nom de la vue (ce sera le cas pour
les vues usuelles que vous aurez déjà utilisées à plusieurs reprises).

Recherche du nom d’une vue
L’extraction du nom des vues qui concernent un objet est rendue possible
par l’interrogation de la vue DICTIONARY (de synonyme DICT)
SQL>DESC DICTIONARY
SELECT * FROM DICTIONARY
WHERE table_name LIKE '%SEQUENCE%';
Nom NULL Type
---------- ---- --------------
TABLE_NAME VARCHAR2(30)
COMMENTS VARCHAR2(4000)
TABLE_NAME COMMENTS
---------------- -------------------------
ALL_ SEQUENCES Description of SEQUENCEs accessible to the user
DBA_ SEQUENCES Description of all SEQUENCEs in the database
USER_ SEQUENCES Description of the user's own SEQUENCEs
TABLE
INDEX
IRIGGER
VIEW
CONSTRAINT

Interroger la vue
L’interrogation de la vue sur la base des colonnes choisies est l’étape finale de
la recherche de données dans le dictionnaire
 Interrogeons le dictionnaire des données à travers les quatre premières
colonnes de la vue USER_SEQUENCES pour retrouver les
caractéristiques de ces deux séquences.
 La valeur courante de la séquence n’est pas stockée dans cette vue, elle
est, en revanche, accessible via la fonction CURRVAL.
SQL>
SELECT SEQUENCE_NAME,
MIN_VALUE, MAX_VALUE,
INCREMENT_BY
FROM USER_SEQUENCES ;
SEQUENCE_NAM MIN_VAL, MAX_VAL, INCREMENT_BY
DEPARTMENTS_SEQ 1 9990 10
EMPLOYEES_SEQ 1 9999999999 1
LOCATIONS_SEQ 1 9900 100
MA_SEQUENCE 1 999999999 1
MA_SEQUENCE2 1 9999999999 2
SQ_ID_TRANSACTION 1 10000 1

Le code source PL/SQL des packages, procedure, triggers,
fonction est maintenu est peut être consulté par les tables de
dictionnaire de données USER_SOURCE et ALL_SOURCE.
Pour consulter le code source de Specification :
SELECT text FROM user_source
WHERE name = 'COMM_PKG' AND type = 'PACKAGE';
Pour consulter le code source de body :
SELECT text FROM user_source
WHERE name = 'COMM_PKG' AND type = 'PACKAGE BODY';
Recherche d’un code source ou
d’une contrainte
Pour consulter les contraintes :
SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE,
TABLE_NAME from DBA_CONSTRAINTS;

Principales vues du dictionnaire des données
Nature de l’objet Vues
----------------------- ------ -------------------------------
Objets (au sens général) USER_OBJECTS : objets appartenant à l’utilisateur (synonyme OBJ).
USER_ERRORS : erreurs après compilation des objets PL/SQL stockés
(procédures, fonctions, paquetages, déclencheurs).
USER_STORED_SETTINGS : paramètres des objets PL/SQL stockés.
USER_SOURCE : source des objets PL/SQL stockés.
Tables USER_TABLES : description des tables relationnelles de l’utilisateur
(synonyme TABS).
USER_ALL_TABLES : description des tables relationnelles et objets de
l’utilisateur.
Colonnes USER_TAB_COLUMNS : colonnes des tables et vues (synonyme COLS).
USER_UNUSED_COL_TABS : colonnes éliminées des tables.
Index USER_INDEXES : description des index (synonyme IND).
USER_IND_EXPRESSIONS : expressions fonctionnelles des index.
USER_IND_COLUMNS : colonnes qui composent les index.
Contraintes USER_CONSTRAINTS : définition des contraintes de tables.
USER_CONS_COLUMNS : composition des contraintes (colonnes).

 Nature de l’objet Vues
----------------------- ------ -------------------------------
Vues USER_VIEWS : description des vues de l’utilisateur
Synonymes USER_SYNONYMS : description des synonymes privés d’un utilisateur
DBA_SYNONYMS et ALL_SYNONYMS : description de tous les
synonymes (privés et publics).
Séquences Déjà étudié en début de section.
Commentaires USER_TAB_COMMENTS : commentaires à propos des tables ou vues.
USER_COL_COMMENTS : commentaires à propos des colonnes des
tables et vues.
Utilisateurs USER_USERS : caractéristiques de l’utilisateur courant.
DBA_USERS et ALL_USERS : caractéristiques de tous les utilisateurs.
.

Privilèges USER_TAB_GRANTS : liste des autorisations sur les tables et les vues pour
lesquelles l’utilisateur est le propriétaire, ou ayant donné ou reçu l’autorisation.
USER_TAB_GRANTS_MADE : liste des autorisations sur les objets appartenant à l’utilisateur.
USER_COL_GRANTS : colonnes autorisées à l’accès
USER_COL_GRANTS_MADE : liste des autorisations sur les colonnes des tables ou des vues
appartenant à l’utilisateur.
USER_COL_PRIVS_MADE : informations sur les colonnes pour lesquelles l’utilisateur est
propriétaire ou bénéficiaire.
USER_TAB_GRANTS_RECD : liste des objets pour lesquels l’utilisateur a reçu une autorisation.
USER_COL_PRIVS_RECD : informations sur les colonnes pour lesquelles l’utilisateur a reçu
une autorisation.
Rôles DBA_ROLES : tous les rôles existants.
DBA_ROLE_PRIVS : rôles donnés aux utilisateurs et aux autres rôles.
USER_ROLE_PRIVS : rôles donnés à l’utilisateur.
ROLE_ROLE_PRIVS : rôles donnés aux autres rôles.
ROLE_SYS_PRIVS : privilèges système donnés aux rôles.
ROLE_TAB_PRIVS : privilèges sur les tables donnés aux rôles.
SESSION_ROLES : rôles actifs à un instant t

Sécurité de la base de Données
Introduction
Qu’est ce que une base de données pour les
organismes ( société , établissement, ministère …) ?
C’est un ensemble des informations et données centralisées qui
sont intègres, confidentielles, disponibles, tracées et dont
l’exploitation et utilisation sont conformes aux règles.
C’est les 5 principes de la sécurité de l’information

 Pour appliquer ces principe : il faut
 Authentification
 Autorisation
comment appliquer ces Principes

Chaque BD Oracle possède une liste de noms d’utilisateurs, et un mot de
passe associé.
Vérifier quand un utilisateur veut utiliser des données, des ressources, des applications,
par le système d’exploitation, le réseau, la base Oracle.
Authentification dans Oracle : cryptage du mot de passe, verrouillage des comptes,
expiration du mot de passe, vérification de la complexité du mot de passe.
A la création d’un nouvel utilisateur, on définit
Un profil délimitant l’accès aux ressources
Mot de passe
Autres paramètres …..
Authentification

Les autorisations reposent sur ce qui suit :
 Tous les éléments SQL ont un propriétaire. Un propriétaire d’un objet
possède tous les droits (privilèges) sur cet objet.
 On peut donner des droits à d’autres utilisateurs pour accéder aux données,
pour les modifier, pour obtenir des ressources, …
 Les droits sont accordés (ou refusés) à différents niveaux (objets, schémas,
tables, tuples, CPU, …).
 On peut accorder des droits individuellement, ou par groupes.
Autorisation

 Utilisateurs
 Profiles
 Droits et privilèges
 Rôles
Pour assurer L’authentification et l’autorisation, il
faut être en mesure de bien gerer les :
On est bien dans l’administration et la gestion des
Utilisateurs de la bases de données
Administration de base de données

Gestion des utilisateurs
classification
Les types d’utilisateurs, leurs fonctions et leur nombre peuvent varier d’une base à une autre.
Néanmoins, on peut les classifier de la manière suivante :
 Le DBA (DataBase Administrator). Il en existe au moins un. Une petite base peut n’avoir
qu’un seul administrateur. Une base importante peut en regrouper plusieurs qui se
partagent les tâches suivantes :
 installation et mises à jour de la base et des outils éventuels ;
 Gestion de l’espace disque et des espaces pour les données (tablespaces) ;
 Gestion des utilisateurs et de leurs objets (s’ils ne les gèrent pas eux-mêmes) ;
 Optimisation des performances ;
 Sauvegardes, restaurations et archivages ;
 Contact avec le support technique d’Oracle.

 L’administrateur réseaux (qui peut être le DBA) se charge de la configuration
de l’intergiciel (middleware) Oracle Net au niveau des postes clients.
 Les développeurs qui conçoivent et mettent à jour la base. Ils peuvent aussi
agir sur leurs objets (création et modification des tables, index, séquences, etc.).
Ils transmettent au DBA leurs demandes spécifiques (stockage, optimisation,
sécurité).
 Les administrateurs d’applications qui gèrent les données manipulées par
l’application ou les applications. Pour les petites et les moyennes bases, le DBA
joue ce rôle.
 Les utilisateurs qui se connectent et interagissent avec la base à travers les
applications ou à l’aide d’outils (interrogations pour la génération de rapports,
ajouts, modifications ou suppressions d’enregistrements).
classification

 Simple Syntaxe
Une simple syntaxe SQL de création d’un utilisateur est la suivante :
CREATE USER utilisateur IDENTIFIED { BY motdePasse
[PROFILE nomProfil ]
[PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK } ] ;
Syntaxe Simple très réduite :
CREATE USER utilisateur IDENTIFIED BY motdePasse
création

 IDENTIFIED BY motdePasse permet d’affecter un mot de passe à un utilisateur
local (cas le plus courant et le plus simple).
● PROFILE nom Profil affecte un profil (caractéristiques système relatives au CPU et aux
connexions) à l’utilisateur
- En l’absence de profil, le profil DEFAULT est affecté à l’utilisateur..
● PASSWORD EXPIRE pour obliger l’utilisateur à changer son mot de passe à la première
connexion (par défaut il est libre). Le DBA peut aussi changer ce mot de passe.
● ACCOUNT pour verrouiller ou libérer l’accès à la base (par défaut UNLOCK).
création (suite)

Instruction SQL Resultat
CREATE USER Paul
IDENTIFIED BY Pokemon
DEFAULT TABLESPACE USERS
QUOTA 10M ON USERS
TEMPORARY TABLESPACE TEMP
QUOTA 5M ON TEMP
PASSWORD EXPIRE;
Paul est déclaré « utilisateur », ses
objets (pas plus de 10 MO) seront
stockés dans USERS,
certaines de ses opérations
nécessiteront de ranger des données
dans TEMP (pas plus de 5 MO). Il
devra changer son mot de passe à la
première connexion.
CREATE USER Paul2
IDENTIFIED BY Pokemon
ACCOUNT LOCK;
Paul2 est déclaré « utilisateur », ses
objets seront stockés dans USERS,
son espace temporaire est SYSTEM.
Le compte est pour l’instant bloqué
Par défaut, les utilisateurs, une fois créés n’ont aucun droit sur la base de données
sur laquelle ils sont connectés. La section « Privilèges » étudie ces droits.
création (exemple )

 Pour Modifier le mot de passe de l’utilisateur (tache la plus utilisé) on utilise la
commande suivante:
ALTER USER Nom_user IDENTIFIED BY nouveau_mot_pass
 Pour pouvoir modifier les caractéristiques d’un utilisateur (autres que celle du mot
de passe) voila la Syntaxe. Elle contient instruction qui reprend les options
étudiées lors de la création d’un utilisateur.
Modification d’un Utilisateur

ALTER USER utilisateur
[ IDENTIFIED { BY password [ REPLACE old_password ] |
[ PROFILE nomProfil ]
[ PASSWORD EXPIRE ] [ ACCOUNT { LOCK | UNLOCK } ] ;
(Suite)
 PASSWORD EXPIRE oblige l’utilisateur à changer son mot de passe à la
prochaine connexion.
 autres changements seront opérationnels aux prochaines sessions de l’utilisateur
mais pas à la session courante (cas de l’utilisateur qui déclare un espace de travail
alors qu’il est actuellement connecté à un autre).

Instruction SQL Résultat
ALTER USER Paul
IDENTIFIED BY X_Men
TEMPORARY TABLESPACE TEMP
QUOTA UNLIMITED ON TEMP;
Paul a changé de mot de passe, son espace
temporaire est illimité dans TEMP. Il ne devra
plus changer son mot de passe à la première
connexion.
ALTER USER Paul2
QUOTA 10M ON USERS
ACCOUNT UNLOCK;
L’espace de travail de Paul2 est limité à 10
mégaoctets dans USERS. Le compte est
débloqué.
Exemples
Le tableau suivant décrit des modifications des utilisateurs créés auparavant :
(Exemples)

Syntaxe
La syntaxe SQL pour supprimer un utilisateur est la suivante :
DROP USER utilisateur [CASCADE];
Oracle ne supprime pas par défaut un utilisateur s’il possède des objets (tables, séquences,
index, déclencheurs, etc.).
L’option CASCADE force la suppression et détruit tous les objets du schéma de l’utilisateur.
Conséquences
Les contraintes d’intégrité d’autres schémas qui référençaient des tables du schéma à
détruire sont aussi supprimées.
Les vues, synonymes, procédures ou fonctions cataloguées définis à partir du schéma détruit
mais présents dans d’autres schémas ne sont pas supprimés mais invalidés.
Les rôles définis par l’utilisateur à supprimer ne sont pas détruits par l’instruction DROP
USER.
Suppression d’un utilisateur (DROP USER)

 Un profil regroupe des caractéristiques système (ressources) qu’il est possible d’affecter
à un ou plusieurs utilisateurs.
 Un profil est identifié par son nom.
 Un profil est créé par CREATE PROFILE, modifié par ALTER PROFILE et supprimé par
DROP PROFILE. Il est affecté à un utilisateur lors de sa création par CREATE USER ou
après que l’utilisateur est créé par ALTER USER. Le profil DEFAULT est affecté par
défaut à chaque utilisateur si aucun profil défini n’est précisé.
 Création d’un profil (CREATE PROFILE)
Pour pouvoir créer un profil vous devez posséder le privilège CREATE PROFILE. La
syntaxe SQL est la suivante
Les Profiles
Introduction

:
CREATE PROFILE nomProfil LIMIT
{ ParamètreRessource | ParamètreMotdePasse }
[ ParamètreRessource | ParamètreMotdePasse ]…;
ParamètreRessource :
{ { SESSIONS_PER_USER | CPU_PER_SESSION | CPU_PER_CALL
| CONNECT_TIME | IDLE_TIME | LOGICAL_READS_PER_SESSION
| LOGICAL_READS_PER_CALL | COMPOSITE_LIMIT } { entier | UNLIMITED
| DEFAULT }
| PRIVATE_SGA {entier[K|M] | UNLIMITED | DEFAULT}}
ParamètreMotdePasse :
{ FAILED_LOGIN_ATTEMPTS | PASSWORD_LIFE_TIME |PASSWORD_REUSE_TIME
| PASSWORD_REUSE_MAX | PASSWORD_LOCK_TIME | PASSWORD_GRACE_TIME } {
expression | UNLIMITED | DEFAULT } }
Les Profiles
Création -Syntaxe

Les options principales sont les suivantes :
● SESSIONS_PER_USER : nombre de sessions concurrentes autorisées.
● CPU_PER_SESSION : temps CPU maximal pour une session en centièmes de secondes.
● CPU_PER_CALL : temps CPU autorisé pour un appel noyau en centièmes de secondes.
● CONNECT_TIME : temps total autorisé pour une session en minutes (pratique pour les
examens de TP minutés).
● IDLE_TIME : temps d’inactivité autorisé, en minutes, au sein d’une même session (pour
les étudiants qui ne clôturent jamais leurs sessions).
● PRIVATE_SGA : espace mémoire privé alloué dans la SGA (System Global Area).
● FAILED_LOGIN_ATTEMPTS : nombre de tentatives de connexion avant de bloquer l’utilisateur
(pour un code PIN, c’est trois).
● PASSWORD_LIFE_TIME : nombre de jours de validité du mot de passe (il expire s’il n’est
pas changé au cours de cette période).
● PASSWORD_REUSE_TIME : nombre de jours avant que le mot de passe puisse être utilisé à
nouveau. Si ce paramètre est initialisé à un entier, le paramètre PASSWORD_REUSE_MAX
doit être passé à UNLIMITED.
Les Profiles
Création – Options et paramètres

 PASSWORD_REUSE_MAX : nombre de modifications de mot de passe avant de
pouvoir réutiliser le mot de passe courant. Si ce paramètre est initialisé à un entier, le
paramètre PASSWORD_REUSE_TIME doit être passé à UNLIMITED.
 PASSWORD_LOCK_TIME : nombre de jours d’interdiction d’accès à un compte
après que le nombre de tentatives de connexions a été atteint (pour la carte bleue, ça
dépend de plein de choses, de toute façon vous en recevrez une autre toute neuve
mais toute chère…).
 PASSWORD_GRACE_TIME : nombre de jours d’une période de grâce qui prolonge
l’utilisation du mot de passe avant son changement (un message d’avertissement
s’affiche lors des connexions). Après cette période le mot de passe expire.
 Les limites des ressources qui ne sont pas spécifiées sont initialisées avec les
valeurs du profil DEFAULT. Par défaut toutes les limites du profil DEFAULT sont à
UNLIMITED et on peut les changer . Il est possible de visualiser chaque paramètre
de tout profil en interrogeant certaines vues du dictionnaire des données (voir le
Les Profiles
Création – Options et paramètres (suite)

Instructions SQL Explication
CREATE PROFILE profil_Etudiants LIMIT
SESSIONS_PER_USER 3
CPU_PER_CALL 3000
CONNECT_TIME 45
LOGICAL_READS_PER_CALL 1000
PRIVATE_SGA 15K
IDLE_TIME 40
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LIFE_TIME 70
PASSWORD_REUSE_TIME 60
PASSWORD_REUSE_MAX UNLIMITED
PASSWORD_LOCK_TIME 1
PASSWORD_GRACE_TIME 10;
• 3 sessions simultanées autorisées.
• Un appel système ne peut pas consommer plus
de 30 secondes de CPU.
• Chaque session ne peut excéder 45 minutes.
• Un appel système ne peut lire plus de 1 000 blocs
de données en mémoire et sur le disque.
• Chaque session ne peut allouer plus de 15 ko de
mémoire en SGA.
• Pour chaque session, 40 minutes d'inactivité maximum
sont autorisées.
• 5 tentatives de connexion avant blocage du compte.
• Le mot de passe est valable pendant 70 jours et il
faudra attendre 60 jours avant qu’il puisse être utilisé à
nouveau.
• 1 seul jour d’interdiction d’accès après que les
5 tentatives de connexion ont été atteintes.
• La période de grâce qui prolonge l’utilisation du
mot de passe avant son changement est de 10 jours.
Exemple Le tableau suivant décrit la création d’un profil et l’explication de ses options :
Les Profiles
Création – Options et paramètres (suite)

 L’affectation de ce profil à l’utilisateur Paul est réalisée via l’instruction ALTER
USER suivante :
ALTER USER Paul PROFILE profil_Etudiants;
 Modification d’un profil (ALTER PROFILE)
 Pour pouvoir modifier un profil, vous devez posséder le privilège ALTER PROFILE.
La syntaxe SQL est la suivante, elle utilise les options étudiées lors de la création
d’un profil :
 ALTER PROFILE nomProfil LIMIT
{ ParamètreRessource | ParamètreMotdePasse }
[ ParamètreRessource | ParamètreMotdePasse ]…;
 Il est plus prudent de restreindre certaines valeurs du profil DEFAULT à l’aide de
cette commande (ALTER PROFILE DEFAULT LIMIT…).
Les Profiles
Modification d’un profil (ALTER PROFILE)

Pour pouvoir supprimer un profil, vous devez posséder le privilège DROP PROFILE.
NB: Le profil DEFAULT ne peut pas être supprimé.
La syntaxe ,SQL de suppression est la suivante :
DROP PROFILE nomProfil [CASCADE] ;
 CASCADE permet de supprimer le profil même si des utilisateurs en sont pourvus
(optiono bligatoire dans ce cas) et affecte le profil DEFAULT à ces derniers.
Les Profiles
Suppression d’un profil (DROP PROFILE)

Privilèges
Introduction (type de privilèges)
 Depuis le début du ce cours nous avons parlé de privilèges, il est temps à présent de
préciser ce que recouvre ce terme. Un privilège) (sous-entendu utilisateur est un droit
d’exécuter une certaine instruction SQL , ou un droit d’accéder à un certain objet d’un
autre schéma Les privilèges système diffèrent sensiblement d’un SGBD à un autre. En
revanche, les privilèges objets sont les mêmes et sont tous pris en charge via les
instructions GRANT et REVOKE.
Il y a deux type de privilèges :
 Privilège système : Est un droit d’exécuter une certaine instruction SQL Create
Alter , DROP , Etc …
 Privilège objet): Droit d’accéder à un certain objet d’un autre schéma SELECT,
DELETE, INSERT etc…

 Attribution de privilèges système (GRANT)
 La commande GRANT permet d’attribuer un ou plusieurs privilèges à un ou
plusieurs bénéficiaires.
 Nous étudierons les rôles dans la section suivante. L’utilisateur qui exécute cette
commande doit avoir reçu lui-même le droit de transmettre ces privilèges. Dans le cas
des utilisateurs SYS et SYSTEM, la question ne se pose pas car ils ont tous les droits.
GRANT { privilègeSystème | nomRôle | ALL PRIVILEGES }
TO { utilisateur | nomRôle | PUBLIC
[ WITH ADMIN OPTION ] ;
Privilèges Système
Attribution de privilèges système (GRANT)

 privilègeSystème : description du privilège système (exemple CREATE TABLE,
CREATE SESSION, etc.).
 ALL PRIVILEGES : tous les privilèges système.
 PUBLIC : pour attribuer le(s) privilège(s) à tous les utilisateurs.
 WITH ADMIN OPTION : permet d’attribuer aux bénéficiaires le droit de
retransmettre le(s) privilège(s) reçu(s) à une tierce personne (utilisateur(s) ou
rôle(s)).
Grant create trigger to ORA_ESTM
Grant create procedur e to TOTO
Grant create session to HR
Grant create vi ew to ORA_ESTM
grant unlimited tablespace to HR
Attribution de privilèges système (suite)

 Le tableau suivant décrit l’affectation de quelques privilèges système en donnant
les explications associées :
Administrateur Explication
GRANT CREATE SESSION,
CREATE SEQUENCE TO Paul;
Paul peut se connecter à la base sous
SQL*Plus par un outil (la console par
exemple), par programme. Il peut
créer des séquences.
GRANT CREATE TABLE TO
Paul with ADMIN OPTION
Paul peut créer des tables dans son
schéma et peut transmettre ce
privilège à un tiers.
GRANT CREATE SESSION,
CREATE ANY TABLE,
DROP ANY TABLE TO Paul2;
Paul2 peut se connecter à la base,
créer et détruire des tables dans tout
schéma.
Attribution de privilèges système (Exemple)

 Révocation de privilèges système (REVOKE)
La révocation d’un ou de plusieurs privilèges est réalisée par l’instruction REVOKE. Cette
commande permet d’annuler un privilège système ou un rôle d’un utilisateur ou d’un
rôle. Pour pouvoir révoquer un privilège ou un rôle, vous devez détenir au préalable
ce privilège avec l’option WITH ADMIN OPTION.
REVOKE
{ privilègeSystème | nomRôle | ALL PRIVILEGES }
FROM { utilisateur | nomRôle | PUBLIC } [,{ utilisateur | nomRôle } ]… ;
Les options sont les mêmes que pour la commande GRANT.
● ALL PRIVILEGES (valable si l’utilisateur ou le rôle ont tous les privilèges système).
 PUBLIC pour annuler les privilège à tout les utilisateur
Retirer de privilèges système (REVOKE)

 Le tableau suivant décrit la révocation de certains privilèges acquis
des utilisateurs de notre exemple
Administrateur Explication
REVOKE
CREATE SESSION
FROM PUAL1,
PAUL2;
Paul et Paul2 ne peuvent plus se connecter à la
base. Ils conservent néanmoins leurs autres
privilèges. Un tiers peut ainsi créer par exemple
des tables dans leur schéma (ils ont tous deux le
privilège CREATE TABLE).
REVOKE ALL
PRIVILEGES
FROM Paul2;
Commande incorrecte car Paul2 n’a pas reçu tous
les privilèges système.
Retirer de privilèges système (Exemple de
revoke)

 Privilèges objets
Les privilèges objets sont relatifs aux données de la base et aux actions sur les
objets (table,vue, séquence, procédure). Chaque type d’objet a différents privilèges
associés comme l’indique le tableau suivant. Nous ne montrons ici que quelques-unes
des possibilités de privilèges objets.
Privilèges Objets
Introduction

 GRANT { privilègeObjet | nomRôle | ALL PRIVILEGES }
[(colonne1 [,colonne2]…)]
[, { privilègeObjet | nomRôle | ALL PRIVILEGES }] [(colonne1 [,colonne2]…)]…
ON { [schéma.]nomObjet TO { utilisateur | nomRôle | PUBLIC } [WITH GRANT
OPTION] ;
Privilèges Objets
Syntaxe d’affectation de privilkège (Grant)
Syntaxe générale
Syntaxe la plus utilisée
Grant { privilègeObjet | nomRôle | ALL PRIVILEGES } on {objets} to Utilisateur

 PrivilègeObjet : description du privilège objet (ex : SELECT, DELETE, etc.).
colonne précise la ou les colonnes sur lesquelles se porte le privilège INSERT,ou
UPDATE (exemple : UPDATE(typeAvion) pour n’autoriser que la modification de la
colonne typeAvion).
 ALL PRIVILEGES donne tous les privilèges avec l’option GRANT OPTION) l’objet
en question.
 PUBLIC : pour attribuer le(s) privilège(s) à tous les utilisateurs.
 WITH GRANT OPTION : permet de donner aux bénéficiaires le droit de
retransmettre les privilèges reçus à une tierce personne (utilisateur(s) ou rôle(s)).
Privilèges Objets
Syntaxe d’affectation de privilkège (Grant -suite)

 Révocation de privilèges objets
 Pour pouvoir révoquer un privilège objet, vous devez détenir au préalable cette
permission ou avoir reçu le privilège système ANY OBJECT PRIVILEGE. Il n’est
pas possible d’annuler un privilège objet qui a été accordé avec l’option WITH
GRANT OPTION.
REVOKE { privilègeObjet | ALL PRIVILEGES } [(colonne1 [,colonne2]…)]
ON { [schéma.]nomObjet |
FROM { utilisateur | nomRôle | PUBLIC
[CASCADE CONSTRAINTS] ;
Privilèges Objets
Retirer les privilèges (REVOKE )

 Certaines options sont similaires à celles de la commande GRANT. Les autres
sont expliquées ci-après :
 CASCADE CONSTRAINTS concerne les privilèges REFERENCES ou ALL
PRIVILEGES. Cette option permet de supprimer la contrainte référentielle entre
deux tables de schémas distincts.
Privilèges Objets
Retirer les privilèges (REVOKE - suite )

Exemple
REVOKE UPDATE, SELECT
ON Pilote FROM christian_soutou;
christian_soutou ne peut plus
modifier ni lire la
table Pilote de olivier_teste.
REVOKE REFERENCES
ON Pilote FROM christian_soutou;
Commande incorrecte car l’option
CASCADE CONSTRAINT
doit être utilisée.
REVOKE REFERENCES
ON Pilote FROM christian_soutou
CASCADE CONSTRAINTS;
christian_soutou ne peut plus
bénéficier de la table
Pilote pour programmer une
contrainte référentielle via une clé
étrangère.
Privilèges Objets
Retirer les privilèges (REVOKE - suite )

Rôles
Introduction
Les rôles sont des groupes nommés de privilèges, qu’on accorde, en groupe,
à des utilisateurs ou à d’autres rôles.
 Permet de gérer les privilèges
– pour une application (ex: ensemble de privilèges nécessaires pour
exécuter l’application Paye)
– Pour un groupe d’utilisateurs (privilèges des directeurs de département,
des responsables de la paye, etc.)

 Définition du role ‘manager’ :
sql>CREATE ROLE manager;
sql>GRANT CREATE VIEW, CREATE PROCEDURE TO manager;
sql>GRANT SELECT, INSERT, UPDATE(SAL) ON emp TO manager;
sql>GRANT SELECT, INSERT, UPDATE ON dept TO manager;
GRANT manager TO user1, user2, user3;
 Pour annuler :
sql>REVOKE manager FROM user1;
sql>REVOKE INSERT ON emp FROM manager;
Pour annuler un role, il faut avoir le privilège GRANT ANY ROLE, ou avoir les
privilèges WITH ADMIN OPTION.
Rôles
Exemple

Oracle a des rôles prédéfinis :
 CONNECT : INSERT, UPDATE, DELETE, SELECT sur les relations dont
on a les privilèges. Permet de créer des vues.
 RESOURCE : crée les tables, les vues, les triggers, les procédures.
 DBA : tous les privilèges système avec ADMIN OPTION
 EXP_FULL_DATABASE : tous les privilèges pour exporter les données
de la base
 IMP_FULL_DATABASE : tous les privilèges pour importer des données.
Rôles
Rôles prédéfinis

Chapitre V:
Sauvegardes et Restaurations d’une Base de
données oracle
 Stratégie de Sauvegardes et Restaurations
 Les modes NOARCHIVELOG et ARCHIVELOG
 mode ARCHIVELOG
 Mode NOARCHIVLOG
 Rman (Recovery Manager )
 Présentation
 Les fonctions de RMAN .
 Les différents types de sauvegardes RMAN
 Sauvegarder une base de données avec RMAN
 Restauration une base de données avec RMAN

Sauvegardes et Restaurations d’une Base de données oracle
Stratégie de Sauvegardes et Restaurations
La principale responsabilité du DBA est de prendre les mesures nécessaires pour
assurer la sécurité et la disponibilité des données.:
 Il doit restituer les données en cas d’incident matériel ou d’erreur de
manipulation.
Cette sécurité est assurée par :
La mise en œuvre d’une protection des fichiers sensibles de la base
- Fichiers de contrôle
- Fichiers de Redo Log
La mise en place d’une stratégie de sauvegarde/restauration
-Adaptée aux contraintes de l’entreprise
- Et qui aura été complètement testée et documentée

Le DBA doit faire des sauvegardes régulières de la base de
données.
 Sauvegardes Physiques ET
 Sauvegardes logiques
Les questions à se poser pour définir la stratégie sont les suivantes :
 Est-il acceptable de perdre des données ?
 si oui sur quelle période ?
Est-il possible d’arrêter périodiquement la base ?
si oui quand et pour combien de temps ?
Est-il possible de faire une sauvegarde complète de la base pendant l’arrêt de
celle-ci ?

S’il n’est pas possible d’arrêter la base ou de faire une sauvegarde complète, il
sera toujours possible de faire des sauvegardes partielles.
La sauvegarde diffère en fonction de la nature de la base de données
Base de petits volumes,
Base contenant des données stratégiques
Base de volumes importants.
Par exemple, pour certaines bases de données, il sera préférable de recharger
certaines tables plutôt que de les restaurer (gain de temps pour de gros
volumes).
Ne pas oublier que le tablespace est l’unité de sauvegarde. Il faudra penser au
stockage des tables dans des tablespaces dédiés (les grosses tables ou les tables
stratégiques) ou mutualisés (les petites tables de référence)

La restauration du fichier de données consiste à prendre la dernière sauvegarde du
fichier de données, de remplacer par cette sauvegarde le fichier manquant ou
endommagé et à appliquer sur cette sauvegarde les fichiers de Redo Log archivés.
Ceci afin de ramener le fichier de données dans l’état où il se trouvait juste avant
l’incident.

 En fonction des possibilités d’arrêt et des pertes de données (acceptables),
on choisira de mettre la base de données en mode ARCHIVELOG ou non.
 En cas de passage en mode ARCHIVELOG, il faut étudier :
 Où mettre les archives (sur disque ou sur bande) ?
 Combien de jeux de sauvegarde conserve-t’on (nettoyage des
sauvegardes et des archives) ?
Les modes NOARCHIVELOG et ARCHIVELOG
Affichage du mode courant : Select log_mode from v$database ;

 Le mode NOARCHIVELOG
C’est le mode par défaut de Oracle
Dans ce mode:
 Un fichier de Redo Log peut être réutilisé immédiatement après qu’un
point de synchronisation (checkpoint) ait eu lieu.
 Une fois le contenu d’un fichier de RedoLog ait été écrasé par une
nouvelle écriture  les données à restaurer sont perdues.
Dans ce mode on ne peut pas faire une sauvegarde à chaud

Le mode NONARCHIVELOG est le mode par défaut de oracle, Et si la base était dans le
mode archivelog et on veut passer au mode NONARCHIVELOG on suit les étapes suivantes:
SQL> shutdown
SQL> startup mount
SQL> alter database noarchivelog;
SQL> alter database open;
passer la base en mode NONARCHIVELOG

Le mode ARCHIVELOG
La synchronisation des fichiers de données est basée sur le numéro de séquence
du fichier de Redo Log
En cas de restauration, Oracle a besoin de tous les fichiers de Redo Log à
partir de celui portant le numéro de séquence inscrit dans le fichier de données
au moment de la sauvegarde. Autrement la restauration ne sera pas possible.
Si un fichier d’archive est perdu, Oracle ne pourra pas restaurer
la base de données.

Le mode ARCHIVELOG :
 Ce mode permet de garantir qu’un groupe de fichiers de Redo Log non
archivés ne sera pas écrasé par LGWR.
 En version 9i, mettre la base en ARCHIVELOG ne démarrait pas
automatiquement le processus ARCH. Il fallait le faire en positionnant le
paramètre LOG_ARCHIVE_START à TRUE.
alter system set log_archive_start=TRUE scope=spfile;
 En cas d’oublie de positionnement de ce paramètre, cela provoquera un
crash de l’instance.
Les modes NOARCHIVELOG et ARCHIVELOG :

 Avant de passer la base en mode ARCHIVELOG, arrêtez celle-ci et
effectuez une sauvegarde à froid. Ne pas oublier de sauvegarder le
fichier SPFILE.
MODE OPERATOIRE :
Arrêter la base de données : SHUTDOWN IMMEDIATE
Monter la base : STARTUP MOUNT
Passer la base en ARCHIVELOG : ALTER DATABASE ARCHIVELOG ;
Ouvrir la base : ALTER DATABASE OPEN
Après avoir passé la base en mode ARCHIVELOG, vérifiez que les archives sont
générées correctement et apparaissent à l’emplacement demandé, puis arrêtez la
base de données et faites une première sauvegarde.
Passer la base en mode ARCHIVELOG

passer la base en mode ARCHIVELOG
-Create pfile from spfile ;
-alter system set LOG_ARCHIVE_DEST_1 = ‘location=f:oracleoradataBORAarch’
scope=SPFILE ;
-alter system set LOG_ARCHIVE_FORMAT=’arch%S_%R%T.arc’ scope=SPFILE ;
-Shutdown immediate;
- Startup mount;
-Alter database archivelog;
-Alter database open;
Passer la base en mode ARCHIVELOG
% S : numéro de la séquence de fichiers journaux,
% T: Thread id: Le numéro de l’instance dans le cas d’un environnement
Oracle RAC, sinon « 1 ».
% d : L’identifiant de la base de données ; il est utile si vous
stockez dans le même répertoire les fichiers de journaux
archivés de plusieurs bases de données.
% R : ID de journaux de réinitialisation qui garantit l’unicité des
noms pour les fichiers journaux archivés sur plusieurs versions
de la base de données
 ORA-19905: log_archive_format must contain %s, %t and %r

En règle générale, il est conseillé d’avoir des basculements de fichiers de Redo Log
(et donc des archivages en mode ARCHIVELOG) toutes les 20 à 30 minutes.
Plus l’activité est importante, plus il y a de basculement et génération d’archivages !
Pour garantir une périodicité stable, il est possible de spécifier une valeur dans le
paramètre ARCHIVE_LAG_TARGET :
 Indique en secondes la durée maximale qui doit séparer deux archivages
 Une valeur nulle désactive la fonctionnalité (valeur par défaut)
 Valeurs autorisées : entre 60 (une minute) et 7200 (2 heures)
Forcer l’archivage de façon périodique

Avantages /Inconvénients
Mode Avantages
ARCHIVELOG Vous pouvez effectuer des sauvegardes en cours d'exécution (quand
la base de données est en ligne).
Les journaux archivés et la dernière sauvegarde complète (hors
ligne ou en ligne) ou une sauvegarde antérieure permettent de
récupérer entièrement la base de données sans perte de données,
car le fichier journal enregistre toutes les modifications apportées à
la base de données.
NOARCHIVELOG Aucun espace disque supplémentaire n'est requis pour le stockage
des fichiers journaux archivés.

Mode Inconvénients
ARCHIVELOG Un espace disque supplémentaire est requis pour le stockage des fichiers journaux
archivés.
L'agent permet cependant de purger les journaux sauvegardés,
ce qui libère de l'espace disque si vous en avez besoin.
NOARCHIVELOG Si vous devez récupérer une base de données, vous pouvez restaurer uniquement la
dernière sauvegarde hors ligne complète. De ce fait, toutes les modifications apportées à
la base de données après cette sauvegarde sont perdues.
La durée des temps d'arrêt de la base de données est importante car la sauvegarde en
ligne de la base de données est impossible. Cette limitation pose un très sérieux
problème pour des bases de données volumineuses.
Avantages /Inconvénients

Livré en standard depuis la version 8 d'Oracle
RMAN (Recovery MANager) est un utilitaire standard de la base de données Oracle. Il
permet aux DBA de gérer les opérations de sauvegarde/restauration de manière souple
et optimisée. RMAN est le successeur de EBU (Enterprise Backup Utility). Il est codé
en Pro*C.
Rman (Recovery Manager )
Présentation et fonctions de RMAN
 Il ne nécessite pas d'installation particulière .Il offre les possibilités et les
fonctionnalités suivantes :
Réaliser des sauvegardes globales de la base, d'espaces disque logiques (tablespace), de
fichiers de données (datafiles), de fichiers de contrôle (controlfiles) et de fichiers d'archive
(archivelog).
Réaliser des sauvegardes incrémentielles (différentielles ou cumulatives) au niveau bloc
de données Oracle.

Eviter de sauvegarder les blocs Oracle vides, ce qui permet un gain significatif de volume de
sauvegarde.
S'interfacer avec un outil de sauvegarde externe (gestionnaire de médias).
Garder la trace des sauvegardes soit dans un catalogue de récupération (recovery catalog),
soit dans les fichiers de contrôle
 Effectuer des restaurations globales ou partielles.
De paralléliser les opérations de sauvegarde/restauration afin d'accroître les performances.
De gérer les périodes de conservation des sauvegardes.
De placer les opérations de sauvegarde/restauration courantes dans le catalogue sous forme
de scripts (à la condition d'utiliser le catalogue RMAN).
Les fonctions de RMAN (suite)

De mutualiser les scripts de sauvegardes, ils ne sont pas dépendants du système
d'exploitation. RMAN dispose de son propre langage de script.
D'éditer des rapports.
De sauvegarder ou dupliquer les bases de données. Les copies n'ont qu'un intérêt limité
par rapport aux copies OS.
De vérifier les sauvegardes effectuées en termes de corruption et ne corrompt pas les
bases qu'il sauvegarde (contrairement à la copie de fichiers de données sans positionner
les tablespaces en mode backup) ce qui est un avantage non négligeable.
Les fonctions de RMAN (Suite)

RMAN garantie donc les types de sauvegardes suivants :
 de type COMPLET (ou FULL) : on sauvegarde tous les blocs
 de type DIFFERENTIEL : on sauvegarde uniquement les blocs modifiés depuis la
précédente sauvegarde de niveau n ou inférieur ( selon le niveau voir les 2 slides
qui suivent) )
 de type CUMULATIF : on sauvegarde uniquement les blocs modifiés depuis la
précédente sauvegarde de niveau n-1
Les différents Type de sauvegarde de RMAN

Les sauvegardes différentielles et cumulatives sont dites incrémentielles en opposition aux
sauvegardes complètes.
RMAN gère 3 niveaux de sauvegardes incrémentielles ( ou différentielles) :
• Niveau 0 : Base de tous les autres niveaux (Sauvegarde de l'ensemble des blocs contenant des
données)
• Niveau 1 : Sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde
incrémentielle de niveau 0
• Niveau 2 : sauvegarde tous les blocs qui ont changé depuis la plus récente sauvegarde
incrémentielle de niveau 0, 1 ou 2.

Lancement de programme de RMAN (Connexions)
La connexion à un catalogue se fait comme suit :
$ rman catalog rman_user/xxxx[@DB]
ou
RMAN> connect catalog rman_user/xxxx[DB];
La connexion à une base cible se fait comme suit :
$ rman target sys/mdp@baseCible
ou à partir des commande se Systeme d’expointion ( Dos pour windows, invite de commande pour
Unix, linux..)
Set oracle_sid=baseCible
rman target /
Ou bien
RMAN> connect target sys/mdp@baseCible

 Gestion des sauvegardes
 Lister les sauvegardes disponibles Sauvegardes de la base complète :
RMAN> list backup;
 Lister les sauvegardes d'un fichier particulier :
RMAN> list backup of datafile 'chemin_datafile';
 Lister les Sauvegardes d'un tablespace particulier :
RMAN> list backup of tablespace TBS_NAME;
Commandes courantes de RMAN

Gérer les sauvegardes
 Lister les fichiers pour lesquels il manque des sauvegardes si on veut répondre à
la politique de sauvegarde définie (durée de rétention, nombre de sauvegardes...)
RMAN> report need backup;
 Lister les sauvegardes obsolètes (en dehors de la fenêtre de sauvegarde définie)
RMAN> report obsolete;
 Vérifier les sauvegardes effectuées par RMAN et encore physiquement présentes
dans la zone de sauvegarde :
RMAN> crosscheck backup;
Supprimer les sauvegardes obsolètes :
RMAN> delete obsolete;
Commandes courantes de RMAN (suite)

Sauvegarder la totalité d’une base
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Cette commande sauvegarde la base de données ainsi que les fichiers d’archive (REDOLOG
journalisés).
Si le mode CONTROLFILE AUTOBACKUP est réglé sur ON, une copie du fichier de contrôle
ainsi que du spfile sera effectuée aprés la sauvegarde.
Sauvegarder des tablespaces
RMAN> BACKUP TABLESPACE system, users, tools, undotbs;
Cette commande va sauvegarder les tablespaces SYSTEM, USERS, TOOLS et UNDOTBS
La sauvegarde

Sauvegarder un fichier de données
RMAN> BACKUP DATAFILE '?/oradata/trgt/users01.dbf', ?/oradata/trgt/tools01.dbf';
Cette commande va sauvegarder les fichiers de données $ORACLE_HOME/oradata/trgt/users01.dbf et
$ORACLE_HOME/oradata/trgt/tools01.dbf.
On peut également stipulé le numéro d’id du datafile à sauvegarder. Cette information peut
s’obtenir avec la requête suivante : SQL> select file_id,file_name from dba_data_files ;
FILE_ID FILE_NAME
-------- -------------------------------------------------
3 /u02/oradata/mgmt/users01.dbf
2 /u02/oradata/mgmt/undotbs01.dbf
1 /u02/oradata/mgmt/system01.dbf
4 /u02/oradata/mgmt/example01.dbf
La commande suivante sauvegardera donc le fichier "/u02/oradata/mgmt/example01.dbf" :
RMAN> BACKUP DATAFILE 4;
La sauvegarde

Sauvegarder le fichier de contrôle
Cette commande va sauvegarder le fichier de contrôle courant
RMAN> BACKUP CURRENT CONTROLFILE ;
. Cependant, si on est en mode autobackup ON, une copie du fichier sera effectuée à
chaque fin de sauvegarde.
La sauvegarde

Sauvegarder les journaux de transactions (redo-log)
Attention : on ne sauvegarde JAMAIS les REDO-LOG courant avec RMAN
Cependant, l’utilisation de RMAN nécessite que la base cible archive ses redo-log (mode
ARCHIVELOG). On peut donc aisément sauvegardé tout ou partie des redo-log archivés.
La commande suivante va sauvegarder l’ensemble des journaux de transactions archivés.
RMAN> BACKUP ARCHIVELOG ALL;
•La commande ci-dessous va sauvegarder les journaux de transactions archivés du mois écoulé.
RMAN> BACKUPARCHIVELOG TIME BETWEEN 'SYSDATE-31' AND 'SYSDATE';
La sauvegarde

Paramètre Exemple Explication du fonctionnement
FORMAT FORMAT ‘/tmp/%U’
Spécifie une localisation et un nom unique (%U)
pour les pièces de sauvegardes
FILESPERSET FILESPERSET 20
Limite le nombre de fichiers de données ou de
log archivés par jeu de sauvegarde
MAXSETSIZE MAXSETSIZE 5G
Spécifie la taille maximum d’un jeu de
sauvegarde
COPIES COPIES 2
Spécifie le nombre de copies de chaque jeu de
sauvegarde
TAG TAG ‘backup_du_lundi’
Spécifie une étiquette pour la sauvegarde. Par
défaut RMAN, génère cette étiquette
Autres paramètres de la sauvegarde
La sauvegarde

Exemple:
RMAN> BACKUP TABLESPACE tools, indx, undotbs FORMAT '?/oradata/%U';
? = Repertoire
La sauvegarde

Sauvegarde incrémentale
Lors d’un backup incrémental, on doit toujours spécifier le niveau 0 qui correspond à une
sauvegarde complète de la base.
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
Ensuite, on peut créer des sauvegardes à un niveau plus élevé.
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
Dans notre exemple, seuls les blocs ayant été modifiés depuis la sauvegarde de niveau 0
seront sauvegardés.
La sauvegarde

Valider ses sauvegardes
On peut tester le fonctionnement d’une sauvegarde sans générer de sortie avec l’option
VALIDATE.
Par exemple :
RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
RMAN> BACKUP VALIDATE TABLESPACE tools;
Cette approche va tester que la sauvegarde se fera sans problème.
Cependant, une fois une sauvegarde effectuée on peut tester que la restauration se fera
sans encombre.
La commande à exécuter est donc la suivante :
RMAN> RESTORE DATABASE VALIDATE;
Rman (Recovery Manager ) La sauvegarde

Copie d’un fichier
L’outil RMAN permet également de réaliser des copies de fichiers. Ces copies sont
équivalentes à des copies de fichiers OS. Cela peut s’avérer nécessaire lorsque
l’on désire réaliser des restaurations « user-managed ».( Restauration par des
commndes OS Sans avoir recours à Rman )
RMAN> COPY CURRENT CONTROLFILE TO '/save/mgmt_rman/cf_testcopie.ctl';
RMAN> COPY DATAFILE 1 TO '/save/mgmt_rman/dbf1_bkp.dbf'
Rman (Recovery Manager ) La sauvegarde

Restauration complète
La restauration complète d’une base de données s’effectue de la manière suivante :
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RETORE CONTROLFILE from ‘ fichier_de_controle_sauvgardé’
RMAN> ALTER DATABASE MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN [RESETLOGS];
Notons que pour effectuer cette opération la base doit être en mode MOUNT (montée).
NB : l’option FORCE va réaliser la combinaison SHUTDOWN ABORT / STARTUP..
Rman (Recovery Manager ) La Resstauration

Restauration incomplète:
Généralement, ce type de restauration s’effectue dans les cas suivants :
 Un ou tous les redo-log en lignes ont été détruits.
Une perte de données : un utilisateur qui a réalisé un DROP TABLE (par exemple) et on ne dispose pas d’un
export assez récent.
Impossibilité d’effectuer une restauration complète par absence d’un ou de plusieurs fichier de logs archivés.
.
La restauration incomplète se fera en mode point-in-time. Dans ce cas, on doit savoir exactement à quelle date
était le dernier état stable de la base et savoir également que toute sauvegarde de ce type entraînera une perte
de données :
Pour se faire, il faut exécuter les commandes suivantes :
RMAN> RUN {
2> SET UNTIL TIME = ‘2022-12-09 11:00:00';
3> RESTORE DATABASE;
4> RECOVER DATABASE;
5> ALTER DATABASE OPEN RESETLOGS;
}
Notons que le format de date doit correspondre aux variables d’environnement systèmes NLS_LANG et surtout
NLS_DATE_FORMAT.

Réstaurer Un tablespace
La restauration d’un tablespace peut se faire en ligne, avec les commandes suivantes :
RMAN> RUN {
2> SQL 'ALTER TABLESPACE users OFFLINE';
3> RECOVER TABLESPACE users;
4> SQL 'ALTER TABLESPACE users ONLINE';
}
Dans un tel cas, les fichiers seront restaurés au même endroit que le précédent. Si on veut
modifier cet endroit, il suffit d’exécuter les commandes suivantes (répéter la ligne 2 en
fonction du nombre de fichiers contenus par le tablespace) :
RMAN> SQL 'ALTER TABLESPACE users OFFLINE';
RMAN> SET NEWNAME FOR DATAFILE 8 TO '/nouveau_rep/mon_nouveau_nomDeFichier.dbf';
RMAN> RESTORE TABLESPACE users;
RMAN> SWITCH DATAFILE ALL;
RMAN> RECOVER TABLESPACE users;
RMAN> SQL 'ALTER TABLESPACE users ONLINE';
La Resstauration

SQL> SELECT tablespace_name,file_id,file_name FROM dba_data_files;
TABLESPACE_NAME FILE_ID FILE_NAME
--------------- ------- ------------------------
SYSTEM 1 /u02/mgmt/system01.dbf
UNDOTBS1 2 /u02/mgmt/undotbs01.dbf
CWMLITE 3 /u02/mgmt/cwmlite01.dbf
DRSYS 4 /u02/mgmt/drsys01.dbf
EXAMPLE 5 /u02/mgmt/example01.dbf
INDX 6 /u02/mgmt/indx01.dbf
ODM 7 /u02/mgmt/odm01.dbf
TOOLS 8 /u02/mgmt/tools01.dbf
USERS 9 /u02/mgmt/users01.dbf
XDB 10 /u02/mgmt/xdb01.dbf
RMAN_TS 11 /u02/mgmt/rman_ts01.dbf
11 ligne(s) sélectionnée(s).
La Resstauration
Restaurer Un fichier de données:
RMAN offre la possibilité de restaurer un fichier de données. Cette opération est similaire à la
restauration d’un tablespace. L’obtention de l’identifiant du fichier se fait par la requête SQL
suivante :

La restauration du fichier 9 à l’endroit indiqué par cette requête se fera par les commandes:
RMAN> SQL 'ALTER DATABASE DATAFILE 9 OFFLINE';
RMAN> RESTORE DATAFILE 9;
RMAN> RECOVER DATAFILE 9;
RMAN> SQL 'ALTER DATABASE DATAFILE 9 ONLINE';
Si on avait voulu restaurer le fichier à l’endroit suivant /u03/restore, nous aurions du exécuter
les commandes suivantes :
RMAN> SQL 'ALTER DATABASE DATAFILE 9 OFFLINE';
RMAN> SET NEWNAME FOR DATAFILE 9 TO '/u03/restore/users01.dbf';
RMAN> SWITCH DATAFILE ALL;
NB : Attention a la validité du fichier (si l’entête du fichier de contrôle courant correspond
aux fichiers à restaurer, alors aucune restauration ne sera effectuée).

 Vues du dictionnaire de données
 Plusieurs vues du dictionnaire permettent d’obtenir des informations sur l’archivage
:
V$DATABASE : mode de fonctionnement de la base (colonne LOG_MODE)
V$INSTANCE : statut du processus ARCH (colonne ARCHIVER)
V$LOG : statut des groupes vis à vis de l’archivage (colonne ARCHIVED)
V$ARCHIVED_LOG : informations sur les fichiers de Redo Log archivés
V$ARCHIVED_DEST : informations sur les destinations d’archivage
La Resstauration

 V$ARCHIVED_LOG
RECID Identifiant de l’enregistrement
NAME Chemin complet de l’archive
SEQUENCE# Numéro de séquence du fichier de Redo Log correspondant
FIRST_CHANGE# Plus petit numéro de SCN (numéro de transaction) écrit dans l’archive
FIRST_TIME Date et heure du plus petit numéro de SCN
NEXT_CHANGE# Plus grand numéro SCN écrit dans l’archive
NEXT_TIME Date et heure du plus grand numéro de SCN
COMPLETION_TIME Date et heure de l’archivage
 V$ARCHIVED_DEST
DEST_NAME Nom de la destination
DESTINATION Chemin complet de la destination
STATUS Statut de la destination (VALID, ERROR, …)
ERROR Message d’erreur (en cas d’erreur)
La Resstauration

 Exemple1 : tablespace endommagé ( Cas de TBS users)
1- mettre la tablespace users offline :
alter tablespace users offline;
2- faire un backup de tablespace users :
BACKUP TABLESPACE users;
2- Modifier le nom de fichier DBF correspondant ( pour simuler l’endommage du
fichier)
3- mettre tablespace users online (impossible)
RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;
4- SQL >ALTER TABLESPACE users ONLINE;
5- Verifier le nom de fichier DBF correspondant : est ce qu il est bien rétablie
Exemples de Backup, restauration
backup archivelog all delete input;
delete obsolete;

 Exemple2 : datafile endommagé
1- Consulter les vues dba_extents, dba_data_files, pour choisir un fichier de donné et la
table correspondant pour faire le test
Supposons que la table est SYSTEM.TESTLOCAL et le ficher est ‘D:GG1.DBF’
2-si la base n’est en mode archivelog redemarer là en mode mount
3- BACKUP DATAFILE ‘D:GG1.DBF’
4- Modifier ou déplacer le fichier ‘D:GG1.DBF’ ( pour simuler la perte de données)
5- SQL>alter database datafile 11 OFFLINE [drop]; (11 num de datafile)
6- RMAN>alter database open et faite un select sur la table SYSTEM.TESTLOCAL
Vous aurez une erreur : ORA-00376: fichier 11 ne peut être lu à cette heure
ORA-01110: fichier de donnÚes 11 : 'D:GG1.DBF'
7- Essayons de restaurer le fichier
8- faite un select sur la table et verifier aussi l’existance du fichier 'D:GG1.DBF'
Exemples de Backup, restauration (suite)

Si tous les fichiers de contrôle ont été perdus : s'assurer que l'instance est bien arrêtée
(SHUTDOWN ABORT si ce n'est pas le cas, car un IMMEDIATE ne marchera pas). Puis,
procéder comme suit :
RMAN> startup force mount;
RMAN> restore controlfile from autobackup;
RMAN> alter database open;
Rq : cette manipulation suppose que les fichiers de contrôle étaient en mode AUTOBACKUP
dans RMAN.
Si ce n'est pas le cas, faire appel à tout les DBA  il y a un grand travail à faire
Exemple3 : perte de tout les fichier de contrôle
Exemples de Backup, restauration (suite)

LP_Admin_base_données.ppt

Contenu connexe

Tendances

Similaire à LP_Admin_base_données.ppt

Dernier

LP_Admin_base_données.ppt