Dba 1

ORACLE
DATABASE
ADMINISTRATIO
I
N
2
ORACLE n.m. (lat. oraculum) ANTIQ. Réponse

d’une divinité au fidèle qui la consultait ; divinité qui
rendait cette réponse ; sanctuaire où cette réponse
était rendue. LITT. Décision jugée infaillible et
émanant d’une personne de grande autorité ;
personne considérée comme infaillible.
3
Les données sont omniprésentes autours de nous…
Manipuler
Gérer
Operations Manuellement
Langages (SQL…) SGBD
INFORMATIO
N
Les politiques de
protection des
données
Sauvegarde, Site de
secours, réplication,
Clouding…
Protéger
Chiffrement,
Chiffrement sécurisation, lutte
Sauvegarde contre Cybercriminalité
PLSI
SMSI
4
Concepts d’une base de données
Les Bases de Données occupent aujourd'hui une place de plus en plus

importante dans les systèmes informatiques.
Pourquoi les bases de données
 Environnement informatique traditionnel (gros systèmes d'exploitation)
 Mode de gestion de données : Système de gestion des fichiers.
 chaque équipe de l'entreprise dispose de ses propres fichiers de données où ne

figurent que les informations la concernant.
 Forme de stockage de l’information dépend de nombreux facteurs : matériel
disponible, bonne volonté, structure de stockage , etc
 l'organisation des fichiers (séquentiel, aléatoire…)
Approche fichier avec PCs

Direction des études Bibliothèque Service social
Appli Appli Appli

En Cobol en Java en C
Fichiers Elèves Fichiers Elèves Fichiers Elèves

et UVs et Livres et Chambres
5
Approche fichiers + SGF
Application bibliothèque
Programme 1
Description du fichier des Elèves
Edition du fichier Elèves
par ordre alpha
*2 Fichier Elèves
Programme 2
Description du fichier des Elèves
Mise à jour du fichier Elèves
via nom élève
SGF
6
7
Exemple de fichier de donnée

8
• Voici un exemple de ce à quoi ressemble un bout de programme COBOL en

environnement mainframe:
 IDENTIFICATION DIVISION : Cette section va contenir les informations générales du programme,

comme son nom par exemple.
 ENVIRONNEMENT DIVISION : Cette section va elle contenir des informations sur l’environnement
qui va exécuter le programme (Matériel, logiciel)
 DATA DIVISION : Cette zone va contenir toutes les déclarations de variable de travail, la
description des fichiers d’entrée, de sortie.
 PROCEDURE DIVISION : C’est ici que nous allons donner toutes les instructions, c’est en quelque
sorte, le « vrai » code !
9
Dans ce contexte, on constate l'apparition de nombreuses difficultés :
 Redondance des données :

 Problème de répétition de données dans différents endroit
 Problème lors de la Mise à Jour
 Difficulté d'accès aux données

L’Accès aux données nécessitant l'intervention d'un informaticien
 Emplacement de la machine,
 Structures utilisées pour stocker ces informations,
 Manipulation de données UNIQUEMENT via programmes
 les chemins d'accès disponibles…)Environnement informatique traditionnel (gros systèmes
d'exploitation)
 Aucune interactivité avec l’utilisateur final (non informaticien)
 Problèmes de partage des données

 Problème lors des MAJ de la même données du même fichier
 Complexité pour la MAJ de plusieurs occurrence de la même donnée
 Problèmes de sécurité
 En cas de panne ou interruption de programme, aucune reprise, ni annulation des transaction, d’où
problème d’incohérence
 Problème de confidentialité (plusieurs occurrence de données)
10
 Manque de portabilité des applications

 Application développées liées au capacité du système et son gestionnaire de fichier
 Problème lors de changement de plateforme ou de support de stockage (exemple codage de
l’emplacement en dur)
 Problèmes de maintenance
 Réécriture totale du code lors du changement de la structure de données
 Transposition des données depuis l’ancienne vers la nouvelle structure (fameux bug 2000)
Risque
Conclusion
• Organisation traditionnelle présentant plusieurs défauts

• Défaut de base : les programmes et les données non sont pas séparés
SOLUTION
Regroupement et unicité des Administration unique Indépendance des programmes
données centralisée et données
Système de Gestion de Bases de Données (DBMS)

Approche centralisée
PC Windows BD
Appli C
Elèves
Uvs
Appli Cobol Appli Java
Livres
Chambres
PC SGBD
NT
Description
BD
PC Linux
Terminaux
11
Approche client/serveur
PC Windows BD
Appli Cobol Elèves

Uvs
Livres
SGBD Chambres
PC
Appli Java
NT
Description
BD
Appli C
PC Linux
12
13
Un peu d’historique
4ème
génération
3ème (1990 -
génération 1999)
1969 • SGBD
2ème • SGBD Orienté
génération relationnel Objet
1965 – 1970 (DB2, Oracle,
Informix,
• (modèle
1ère MsAccess)
hiérarchique)
génération • SQL
• (modèle
1950 - 1965
• SGF(Systèmes de
réseau)
Gestion de Fichiers)
14
Définition d’une BD
Une BD est un ensemble volumineux, structuré et minimalement redondant de

données, reliées entre elles, stockées sur supports numériques centralisés ou
distribués, servant pour les besoins d'une ou plusieurs applications, interrogeables et
modifiables par un ou plusieurs utilisateurs travaillant potentiellement en parallèle
Centraliser • Ensemble unique de stockage

l’information • Non redondance de l’information
• Contraintes d’intégrité au sein de la BD

Centraliser les • Modifications aisées des règles de
contrôles gestion
Objectifs Rendre indépendant • Modification de la structure des données

les données et les sans toucher aux traitements
programmes
Faciliter l’accès aux

• Langage standard d’accès aux
données données : SQL
15
Concept du SGBD
SGBD : Systèmes de Gestion de Bases de Données
Ensemble de logiciels systèmes permettant aux utilisateurs de faire des

applications (insérer, modifier, et rechercher) efficacement des données spécifiques
dans une grande masse d'informations (pouvant atteindre plusieurs milliards
d'octets) partagée par de multiples utilisateurs
Les niveaux d’abstraction du SGBD
• Niveau physique : Ce niveau appelé aussi niveau interne, gère le stockage et

l'accès aux données. Il n'y a qu'un seul niveau physique par SGBD
• Niveau conceptuel : C'est à ce niveau, également appelé le niveau logique,
que l'on parle de modèle (conceptuel) de données. Ce modèle décrit
l'ensemble des données de l'entreprise. La description conceptuelle d'une base
de données - BD - est unique
• Niveau externe : Les schémas externes sont dédiées aux utilisateurs et

donnent des vues (partielles) des données de la base
16
Concept du SGBD
Exemples de SGBD
Les SGBD commerciaux les plus connus sont :Oracle, Sybase, Ingres, Informix et DB2
• Oracle est un SGBD relationnel (et relationnel-objet dans ses dernières versions) très
reconnu pour les applications professionnelles.
• PostgreSQL est un SGBD relationnel et relationnel-objet très puissant qui offre une
alternative open source aux solutions commerciales comme Oracle ou IBM.
• MySQL est un SGBD relationnel libre (licence GPL et commerciale), simple d'accès et très
utilisé pour la réalisation de sites Web dynamiques. Depuis la version 4 MySQL implémente
la plupart des fonctions attendues d'un SGBD relationnel.
• Access est un SGBD relationnel Microsoft, qui offre une interface graphique permettant de
concevoir rapidement des applications de petite envergure ou de réaliser des prototypes
Caractéristiques du
17
SGBD
• Indépendance physique : le niveau physique peut être modifié indépendamment du
niveau conceptuel. Cela signifie que tous les aspects matériels de la base de données
n'apparaissent pas pour l'utilisateur, il s'agit simplement d'une structure transparente de
représentation des informations
• Indépendance logique : le niveau conceptuel doit pouvoir être modifié sans remettre en
cause le niveau physique, c'est-à-dire que l'administrateur de la base doit pouvoir la faire
évoluer sans que cela gêne les utilisateurs
• Manipulabilité : des personnes ne connaissant pas la base de données doivent être
capables de décrire leur requête sans faire référence à des éléments techniques de la
base de données
• Rapidité des accès : le système doit pouvoir fournir les réponses aux requêtes le plus
rapidement possible, cela implique des algorithmes de recherche rapides
• Administration centralisée : le SGBD doit permettre à l'administrateur de pouvoir
manipuler les données, insérer des éléments, vérifier son intégrité de façon centralisée
• Limitation de la redondance : le SGBD doit pouvoir éviter dans la mesure du possible
des informations redondantes, afin d'éviter d'une part un gaspillage d'espace mémoire
mais aussi des erreurs
• Vérification de l'intégrité : les données doivent être cohérentes entre elles, de plus
lorsque des éléments font référence à d'autres, ces derniers doivent être présents
• Partageabilité des données : le SGBD doit permettre l'accès simultané à la base de
données par plusieurs utilisateurs
Caractéristiques du
18
SGBD
• Sécurité des données : le SGBD doit présenter des mécanismes permettant de gérer les
droits d'accès aux données selon les utilisateurs
• Disponibilité : Un SGBDR se doit d’offrir une bonne disponibilité des données. Une disponibilité
totale des données est possible (temps de reprise nul) il suffit de s’en donner les moyens logiciels et
matériels…
• Fiabilité: Des mécanismes de sauvegarde varies (physique, logique, offline, online, totale, partielle,
incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer
une information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel.
• Confidentialité : Tout n’est pas accessible a tout le monde! Se connecter a la base de données,
donne un certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un
administrateur. La granularité d’accès peut aller jusqu’a la vision unique d’un champ d’un
enregistrement d’une table particulière. Encore une fois on ne manipule plus des fichiers…
• Cohérence : Que les données soient reparties ou non –dans ce dernier cas les mécanismes mis en
jeux seront plus complexes– elles doivent être cohérentes. Cela sous entend, d’une part que les
accès concurrents d’utilisateurs, notamment lors de mises a jour, ne doivent pas compromettre
l’intégrité des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité du
modèle, mais aussi aux règles de gestion de l’entreprise.
• Traçabilité : On peut, notamment en cas de problème important ou en cas d’attaque du système,

recourir a l’analyse de traces ou de logs du SGBD. Le niveau de détail de ces traces est
paramétrable, et concerne soit les aspects système, soit réseau, soit l’accès aux données
élémentaires elles mêmes
19
Catégories de BD
les catégories de bases de donnes
La base de données, à l’instar d’un programme classique s’inscrit dans un cycle de vie, et
différentes occurrences de la base permettent de ‘coller’ aux différentes phases du projet.
On distingue principalement :
• la phase de conception, qui produira le modèle conceptuel et le modèle logique de la

base
• la phase de développement, qui verra la création et l’évolution de la base de

développement (Base n°1)
• les tests, avec une base de test ou de pré production (Base n°2) qui permettra outre de
tester les programmes de manière approfondie, de tester la montée en charge et les
performances en terme de volume de données, et de concurrence d’accès
• la phase de production / exploitation et de maintenance, avec une base de production

(Base n°3), initialisée avec des données réelles et dimensionnée de manière adéquate
20
les catégories de bases de donnes
Le DBA sera fréquemment amène a transférer des données d’une base a une autre :
• de la base de développement a la base de Test, pour effectuer les dits tests. Un ensemble de données
cohérentes (jeu d’essai) est alors nécessaire, ce qui n’est pas toujours facile a obtenir vu la complexité
croissante des applications et peut nécessiter des outils spécifiques d’extraction de données
• de la base de test a la base de production, pour la mise en exploitation réelle
• de la base de production vers la base de test ou de développement, pour être sur d’avoir des données
cohérentes et pertinentes (puisque réelles).
• Ce dernier transfert de données est VIVEMENT déconseillé, d’abord parce qu’il manipule des volumes
de données inutiles (la totalité des données réelles) et ensuite car il offre d’importantes failles de
sécurité, les systèmes de test et de développement étant par définition moins protégés que les
systèmes en production…
• le passage de la base de test a la base de production, nécessite de réinitialiser la base, avec les scripts
SQL originaux (création et chargement initial). Le passage au serveur réel peut s’avérer délicat et
contraignant (environnement matériel et logiciel diffèrent).
21
Les types d’architectures
Architectures locales et reparties
 Architecture locale
 Architecture client/serveur : client lourd. Le PC communique avec le serveur
de données sur un serveur distant, via le réseau, et la couche Oracle Net.
 Architecture 3 tiers : Pas de programme client. Un navigateur suffit sur le
poste de travail (dit alors ‘client léger’). Il dialogue avec le serveur de données
distant via http.
Comment
22
choisir ?
Comparaison Oracle, MySql, PostgreSql
rapidité petites Bases
100%
80%
60%
Sandard rapidité grandes Bases
40%
20%
Oracle
0% MySql
Postgresql
fonctionnalitées facilité de mise en œuvre
Sécurité
sécuritédes
desdonnées
données
Qu’est ce qu’est une base de
23
données
Définition générale
« Une base de données (son abréviation est BD, en anglais DB), est
une entité dans laquelle il est possible de stocker des données de façon
structurée et avec le moins de redondance possible. Ces données
doivent pouvoir être utilisées par des programmes, par des utilisateurs
différents »
Définition par oracle
« C’est un ensemble de programmes

qui manipulent les fichier de
données »
Scott martin
24
La nécessité de comprendre l’architecture
• De nombreux utilisateurs ne voient pas l’intérêt de

comprendre l’architecture interne de la base de
données
• Codage rapide (prototypage rapide)
• La base de données relationnelle et ses outils facilitent
le développement
Une bonne compréhension de la conception et

structure de la base de données s’avère très
utile pour résoudre les problèmes
25
Le DBA?
 D.B.A. = Data Base Administrator = Administrateur de bases de données. Il

est responsable du bon fonctionnement des bases de données de l‘entreprise
(bases de développement, test et production).
 Les taches du DBA :

 Installer le logiciel, faire les mises a jour (patchs, changement de version
du noyau mais aussi des autres produits),
 Créer les bases de données physiques et gérer l’espace physique,
 Gérer les utilisateurs et leurs droits d’accès,
 Valider les schémas de données (cohérence, non redondance,
optimisation)
 créer les objets du schéma : tables, index, vues, …
 Assurer la sécurité de la base (sauvegarde, restauration, confidentialité
d’accès),
 surveiller le système, gérer les ressources et optimiser les performances,
 Faire les transferts de données de et vers d’autres systèmes,
 contacter le support technique…ou Google
Logiciels 26
utiles
• Pour pouvoir faire les exercices, et pratiquer a minima l’administration Oracle,

il vous faudra installer le logiciel Oracle 10g, et créer une base par défaut.
• Il vous faudra suivant le cas 1GO sur disque et de 512MO a 1GO de
mémoire pour que le logiciel s’installe et fonctionne.
• Oracle Database 10g Express : Une version light ET GRATUITE d’Oracle
pour Linux et Windows. Totalement fonctionnelle et assez peu gourmande en
ressources. Données limitées à 4GO ! , S’installe facilement, Idéale pour
démarrer.
• Toutes les infos sur Oracle Database 10g Express et le logiciel a télécharger,
sont disponibles ici : http://
www.oracle.com/technology/products/database/xe/index.html
• Oracle SQL developper v 1.2.1 : Un outil de développement graphique,

gratuit. Il vous permet de faire du SQL, du PL/SQL, de naviguer dans la base
de données et de produire des rapports personnalises.
• Toutes les infos concernant ce produit, et le logiciel a télécharger, sont
disponibles ici : http://
www.oracle.com/technology/products/database/sql_developer/index.ht
ml
DBA 1
CHAPITRE 1
COMPOSANTS DE
L'ARCHITECTURE ORACLE
28
Principaux composants de l’architecture Oracle
29
L’architecture Oracle
L’architecture oracle est constituée d’une instance et d’une base de données
appelée database.
Une instance est constituée :
 D’une zone de mémoire partagée appelée System Global Area (SGA);
 D’un ensemble de processus d’arrière plan ayant chacun un rôle bien
précis;
 D’un ensemble de processus serveur chargés de traiter les requêtes
des utilisateurs
Une base de données est constituée de :
• Un fichier de contrôle, contenant les informations sur tous les autres
fichiers de la base (nom,emplacement, taille).
• Fichiers de Redo Log, contenant l’activité des sessions connectées à
la base. Ce sont des journaux de transactions de la base. Ils sont
organisés en groupe possédant le même nombre de membres.
• Et éventuellement, de fichiers de Redo Log archivés contenant les
archives d’anciens fichiers de Redo Log.
• D’un ou plusieurs fichiers de données qui contiennent les données des
tables de la base.
30
Le serveur Oracle
Un serveur Oracle :
• est un SGBD qui gère de façon
fiable (sécurité + cohérente +
récupération après incident) Serveur Oracle
dans un environnement multi

utilisateur une quantité importante
de données
• est constitué d'une instance et
d'une base de données Oracle.
31
Établir une connexion et créer une session Oracle
Se connecter à une instance Oracle :

• Établir une connexion utilisateur
• Créer une session
un “listener” SQL*Net est obligatoire, même si le client est situe sur la même
machine que le serveur. On sera alors en pseudo accès distant.
32
Configuration en serveur dédié
En architecture standard Oracle, un processus serveur (shadow process) est dédié a
chaque session cliente. En clair il y a autant de processus sur le serveur que de clients
connectes.
C’est donc le mode par défaut. Il est satisfaisant dans la plupart des cas, hormis
lorsque le nombre d’utilisateurs connectes simultanément (sessions) est très
important. Dans ce cas il sera peut être intéressant de passer en architecture partagée
pour diminuer le nombre de processus sur le serveur…
33
Configuration en serveur partagé
L’architecture clients / serveurs partages (shared servers), baptisée ‘Multithread’
dans les précédentes versions d’Oracle permet de ne pas dédier un processus
serveur à chaque demande d’ouverture de session d’un client. Un ou plusieurs
processus partagés pourront ainsi supporter un grand nombre de connexions
simultanées, sans augmenter linéairement le nombre de processus serveurs.
34
Configuration en serveur partagé (2)
Les processus en architecture serveur partagé
Il faut au minimum 3 processus pour que ca marche :
• un listener , (LISTENER) processus réseau qui attend les

demandes de connexion utilisateur, et connecte le processus
utilisateur à un serveur partage (ou à un serveur dédié en cas de
demande expresse).
• un dispatcher (ora_D00n) , qui place la requête dans une file
d’attente (request queue) ou le premier serveur partage disponible
se servira . le nombre initial de dispatchers est donné par le
paramètre DISPATCHERS de l’init.ora
• un serveur partagé (ora_S00n) , qui traite effectivement la
requête, accède au SGBD et met le résultat dans la file d’attente de
réponse (response queue) du dispatcher demandeur.
Il y a entre SHARED_SERVERS and MAX_SHARED_SERVERS

(paramètres de l’ini.ora) qui peuvent être créés.
L’INSTANCE
36
L’instance Oracle
Une instance Oracle :

• Permet d'accéder à une et une seule base de données
Oracle,
• Est constituée de structures de processus d'arrière-plan et
de structures mémoire.
37
L’instance Oracle
l’option RAC (Oracle Real Application Clusters)
• Utiliser Oracle sur des serveurs en cluster;
• une base de données peut être ouverte par plusieurs instances situées
sur des nœuds distincts d’un cluster de serveurs;
• Option est intéressante pour la haute disponibilité mais complexe à
mettre en œuvre
une répartition de la
charge ou d’introduire
de la redondance, pour
pallier a des
problèmes éventuels
de panne de CPU…
38
Configuration BD
39
La structure de mémoire
La structure mémoire d'Oracle est constituée des deux zones
de mémoire suivantes :
la mémoire SGA,
• Allouée au démarrage de l'instance et qui est une composante fondamentale
d'une instance Oracle;
• C’est le moyen de communication le plus rapide et le plus efficace pour les
processus;
• Partagée;
• structure est donc accessible par tous les processus utilisateurs et serveur.
la mémoire PGA
• Allouée au démarrage du processus serveur;
• Emplacement en mémoire dédié à un processus serveur
• Non partagée
• Contient les informations du processus pour lequel elle a été créé (variable de
session, tableau etc. etc .
40
La SGA
 Database Buffer Cache : cache des données

 Shared Pool
 Library Cache → cache des requêtes SQL
 Dictionnary Cache → cache du dictionnaire des données
 Result Cache → Résultats de requêtes.
 RedoLog Buffer : tampon pour les transactions sur la BD
 Large Pool : utilisé pour des processus optionnels ( RMAN,
configuration en serveur partage )
 Java Pool : a 0 si la machine virtuelle java de Oracle n'est pas utilisée
 Stream Pool : tampon pour échange via flux Stream ( fonctionnalité non
maintenue post 11g )
41
Database Buffer Cache
 Le Database Buffer Cache stocke les blocs de données
utilisés en dernier.
 C’est Zone mémoire dans laquelle oracle place les blocs de
données pour exploitation par les processus utilisateurs
 Les données de la base ne sont accessibles, en lecture ou en
mise à jour, qu’après avoir été chargées dans le Database
Buffer Cache.
 Dans la pratique, le Database Buffer Cache ayant une taille
finie, Oracle utilise un algorithme LRU (Least Recently Used)
pour gérer le cache : en cas de manque de place, Oracle
supprime du cache les données utilisées le moins
récemment.
 Lu par le processus DBW0 afin d‘écrire dans les fichiers de
données.
42
Database Buffer Cache
 Généralement, augmenter la taille du Database Buffer Cache

améliore les performances.
 La taille du bloc (DB_BLOCK_SIZE) étant fixée à la création

de la base, la taille du Database Buffer Cache est définie par
la valeur du paramètre DB_BLOCK_BUFFERS qui fixe le
nombre de buffers en mémoire, chaque buffer ayant une taille
égale à DB_BLOCK_SIZE.
 Dimensionné par le paramètre DB_CACHE_SIZE.
ALTER SYSTEM SET DB_CACHE_SIZE = 48M;

43
Shared Pool Area (SPA)
Composée de deux structures :
 Library Cache
Texte de l'ordre SQL
Sa version analysée
Son plan d‘exécution
 Dictionnary Cache
 Description des tables
 Droits des utilisateurs
 Sa taille est définie et dimensionnée par le

paramètre SHARED_POOL_SIZE.
ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
44
Library cache
 Le library cache est utilisé pour stocker les ordres SQL et les blocs
PL/SQL à partager entre utilisateurs, ce dernier est géré par un
algorithme LRU (Least Recently Used).
 Le library cache évite les nouvelles analyses d'ordre.
 Si un utilisateur effectue un ordre déjà mis en cache, le serveur

Oracle peut utiliser la version mise en cache sans avoir à l'analyser
de nouveau.
 Pour savoir si un ordre est déjà mis en cache, le serveur Oracle :

 réduit l'ordre à la valeur numérique du texte ASCII
 utilise une fonction hash de ce chiffre
45
Lors d’une requête identique, mais seulement la valeur qui diffère, une seule
Shared SQL Area est allouée. Les ordres SQL peuvent partager une zone SQL
partagée en utilisant du code générique et des bind variables plutôt que des
constantes. (nom de variable au lieu de sa valeur)
 Pour savoir si un ordre est déjà mis en cache, le serveur Oracle :
 réduit l'ordre à la valeur numérique du texte ASCII
 utilise une fonction hash de ce chiffre
47
L'UGA est la mémoire de session ,

qui est la mémoire allouée aux
variables de session, telles que les
informations de connexion et d'autres
informations requises par une session
de base de données. Essentiellement,
l'UGA stocke l'état de la session.
L'UGA doit être disponible pour une session de base de

données pendant toute la durée de la session. Pour
cette raison, l'UGA ne peut pas être stocké dans le PGA
lors de l'utilisation d'une connexion de
serveur partagé car le PGA est spécifique à un seul
processus. Par conséquent, l'UGA est stocké dans le
SGA lors de l'utilisation de connexions de serveur
partagé, permettant à tout processus de serveur
partagé d'y accéder. Lorsque vous utilisez
une connexion de serveur dédiée , l'UGA est stocké
dans le PGA.
48
Library Cache
Une requête SQL passe par 2 ou 3 phases :

 Analyse ( parsing )
 Syntaxiquement correcte
 Sémantiquement correcte : les données existent et l'utilisateur a le
droit de les utiliser.
 Déterminer le plan d'exécution ( se base sur des statistiques )
 Exécution ( exécute )
 Recherche ( fetch ), uniquement pour les select.
La phase d'analyse est longue et consommatrice de

ressources.
Le stockage en Library Cache permet en cas d'exécution

multiple de la requête de ne pas refaire la phase
d'analyse → requêtes identiques
49
Library Cache
Requêtes identiques
Oracle analyse le texte d'une requête au caractère près.

Les requêtes suivantes sont toutes différentes :
select * from client where id = 1;
select * FROM client Where id = 1;
select * from client where id = 2;
 Il importe dans une application de coder selon une norme

(majuscule/minuscule, espace... )
 Pour les valeurs variables il faut utiliser des variables bind
afin d'affecter un paramètre a la requête :
select * from client where id = :v;
L'amélioration des performances peut être spectaculaire.

50
Library Cache
51
Library cache : Optimisation
 Premier objectif d'optimisation : réduire les absences de données en

minimisant l'analyse
 si une application fait un appel d'analyse pour un ordre SQL alors que la
représentation analysée de l'ordre n'existe pas dans une zone SQL
partagée du library cache, le serveur Oracle analyse l'ordre et alloue une
zone SQL partagée. Les ordres SQL peuvent partager une zone SQL
partagée en utilisant du code générique et des bind variables plutôt que
des constantes.
 si une application fait un appel d'exécution pour un ordre SQL alors que la
zone SQL partagée concernant la représentation analysée de l'ordre a été
libérée du library cache pour faire place à un autre ordre, le serveur
Oracle analyse de nouveau l'ordre implicitement, lui alloue une nouvelle
zone SQL partagée et l'exécute. Il faut réduire les absences de données
dans le library cache lors d'un appel d'exécution en allouant plus de
mémoire au library cache.
 si l'objet d'un schéma est référencé dans un ordre SQL et qu'on le modifie
par la suite, la zone SQL partagée devient invalide.
52
Library cache : Optimisation
 Second objectif d'optimisation : éviter la fragmentation
 en assurant suffisamment d'espace contigu pour les besoins importants

en mémoire via l'allocation d'espace réservé dans la zone shared pool.
 en maintenant en mémoire les objets volumineux les plus fréquemment

demandés tels que les zones SQL et PL/SQL, au lieu de les exclure par le
mécanisme LRU habituel.
 en utilisant de petites fonctions PL/SQL au lieu de larges blocs PL/SQL

anonymes.
53
Dictionnary Cache
Tout Oracle est dans Oracle → dictionnaire des

données.
Le dictionnaire des données stocke l'ensemble des

informations de la base
 Structure des tables, colonnes, type...
 Droits des utilisateurs
 Stockage...
 Lors de la phase d'analyse, le dictionnaire des données

est sollicité pour valider sémantiquement la requête.
 La mise en mémoire cache des informations du
dictionnaire de données réduit le temps de réponse aux
interrogations et aux instructions LMD.
54
Result Cache
 La version 11g de Oracle introduit une zone

supplémentaire.
 Cette zone est située dans la Shared Pool
donc en SGA.
 Elle contient le résultat produit par une ou des
requêtes précédentes.
 Le Result Cache est davantage un concept
programmation qu'administration.
55
Redo Log Buffer
Tampon mémoire sur toute transaction

 insert
 update
 delete
 A chaque transaction une entrée de redo est écrite dans ce pool;
 Le processus LGWR écrit dans les fichiers de journalisation

(redolog ) selon certains évènements;
 Les select n'utilisent pas beaucoup voir pas du tout ce pool;
 Dimensionné par le paramètre log_buffer
 La chaine redolog buffer, LGWR et fichiers redolog est un goulot

d'étranglement au niveau de Oracle ( base OLTP) car l'ensemble
des transactions passe par elle.
 Son optimisation est complexe mais fondamentale.
56
Zone de mémoire LARGE POOL
 Zone facultative de la mémoire SGA

 Elle réduit la charge de la zone de mémoire
partagée.
 les processus serveur d'E/S
 les opérations de sauvegarde et de restauration ou RMAN
 les mémoires tampon des messages d'exécution en
parallèle
 PARALLEL_AUTOMATIC_TUNING = TRUE
 Elle n'utilise pas de liste LRU.
 Sa taille est définie par le paramètre
LARGE_POOL_SIZE.
57
Zone de mémoire JAVA
• La zone de mémoire Java répond aux besoins

d'analyse des commandes Java.
• Elle est nécessaire si Java est installé et utilisé.
• Sa taille est définie par le paramètre

JAVA_POOL_SIZE.
58
La mémoire PGA
Mémoire réservée à chaque processus utilisateur qui se connecte à une

base de données Oracle.
 Elle est allouée lorsqu'un processus est créé.
 Elle est libérée à la fin du processus.
 Elle n'est utilisée que par un processus.
Pour un processus serveur, la PGA contient :
• Une zone de tri (allouée dynamiquement lors d’un tri)
• Des informations sur la session
• Des informations sur le traitement des requêtes de la session
• Les variables de session
Dans une configuration multithread, une partie de la PGA est en fait
stockée dans la SGA (dans la Large Pool ou éventuellement dans la
Shared Pool).
A partir de la version 9i, la PGA devient dynamique et est configurée par le
paramètre PGA_AGGREGATE_TARGET.
LA BASE
DE
DONNEES
60
La base de données
La base de données est l’ensemble des fichiers qui permettent de gérer les
données stockées dans de la base de données.
Une base de données est constituée de :
 Un fichier de paramètres binaire SPFILE<SID>.ORA, contenant les paramètres
de démarrage de l’instance et d’autres valeurs qui déterminent l’environnement
dans lequel elle s’exécute -- Créé à partir d’un fichier de paramètres caractère
(INIT<SID>.ora)
 Un fichier de mots de passe, contenant le mot de passe du privilège SYSDBA.
 Un fichier de contrôle, contenant les informations sur tous les autres fichiers de la
base (nom, emplacement, taille).
 Fichiers de Redo Log, contenant l’activité des sessions connectées à la base. Ce

sont des journaux de transactions de la base. Ils sont organisés en groupe
possédant le même nombre de membres. Et éventuellement, de fichiers de Redo
Log archivés contenant les archives d’anciens fichiers de RedoLog.
61
La base de données
 D’un ou plusieurs fichiers de données qui contiennent les données

proprement dites, elle contient à la création de la base de données au
minimum :
 Tablespace SYSTEM, contenant le dictionnaire de données.
 Tablespace SYSAUX, c’est le tablespace auxiliaire du tablespace SYSTEM

contenant des fonctions Oracle ou des données utilisées par des outils tels que
le référentiel d’OEM (Oracle Enterprise Manager), placées avant dans un
tablespace OEM_REPOSITORY, situées aujourd’hui dans le tablespace
SYSAUX.
 Tablespace Temporaire TEMP, récupérant les segments temporaires utilisés

par les requêtes SQL de la base de données.
 Tablespace UNDO, récupérant la version précédente des données en cours de

modification par les transactions se déroulant sur la base.
 Tablespace USERS, tablespace de travail par défaut des utilisateurs.

62
Les fichiers de données
 Ils contiennent les données proprement dites de la base

 Dictionnaire des données ( system )
 Statistiques sur ressources ( sysaux )
 Données utilisateurs
 Index.
 L’espace occupé par un objet dans un tablespace est désigné par le
terme générique de segment.
 Ils sont logiquement regroupés en tablespaces.
 Un tablespace est une unité logique de stockage composée d’un ou
plusieurs fichiers physiques.
63
Les fichiers de données
Organisation de stockage
Les fichiers sont découpés en blocs Oracle
 Un bloc Oracle est un multiple du bloc système
 5 tailles de blocs possibles ( 2,4,8,16 et 32Ko )
 Depuis la 9i Oracle peut utiliser plusieurs tailles de blocs
 La taille du bloc standard est fixe par le paramètre DB_BLOCK_SIZE et
ne peut être modifie après création de la base.
 Le bloc est la plus petite unité d'entrée/sortie de Oracle.
 La notion de bloc est fondamentale et se retrouve partout dans Oracle.
Un ensemble de blocs contigus forme un extent
Un ensemble d'extent forme un segment
 4 types de segments
 table
 index
 annulation( undo ) → ordre ROLLBACK
 temporaire → tri, clause order by, group by...
Un segment appartient a un tablespace
64
Notions de tablespace
 La structure logique définit le mode d'utilisation de l'espace physique

d'une base de données.
 Les données Oracle sont stockées dans des fichiers physiques sur disque.
Toutefois Oracle utilise principalement la notion de tablespace et non de
fichier.
 Un tablespace est un ensemble logique contenant 1 ou x fichiers physiques.
 La manipulation des tablespaces est une des taches principales
d'administration Oracle.
65
Stockage des données
Lorsqu’un segment est créé dans un tablespace, Oracle lui alloue un premier
extent dans un des fichiers du tablespace. Lorsque ce premier extent est plein,
Oracle alloue un deuxième extent au segment et ainsi de suite.
66
Stockage des données
Lorsqu’un segment est créé dans un tablespace, Oracle lui alloue un premier extent dans
un des fichiers du tablespace. Lorsque ce premier extent est plein, Oracle alloue un
deuxième extent au segment, mais pas forcément côte à côte ni forcément dans le même
fichier. Lorsqu’un segment est supprimé, les extents qu’il occupe sont libérés et rendus
disponibles pour d’autres segments.
67
Le fichier de contrôle
Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier
de contrôle est le premier fichier ouvert, il permet ensuite à l’instance de
localiser et d’ouvrir les autres fichiers de la base de données. Si on perd le
fichier de control, la base de données reste à l’état NOMOUNT, et ne
pourra pas s’ouvrir.
 Il s'agit d'un petit fichier binaire.
 Il définit l'état actuel de la base de données physique.
 Il assure l'intégrité de la base de données.
 Il est requis :
 lors de l'étape MOUNT lors du démarrage de la base de
données,
 pour le fonctionnement de la base de données.
 Il est lié à une seule base de données.
La perte de ce fichier peut nécessiter la récupération de la base de

données.
Sa taille initiale est définie par la commande CREATE DATABASE.
68
Le fichier de contrôle
Le fichier de contrôle est automatiquement mis à jour par Oracle lors

de chaque modification de la structure de la base de données (ajout ou
déplacement de fichier, …).
• Un fichier de contrôle contient les informations suivantes :
• Le nom et l’identifiant de la base de données
• Le nom et l’emplacement des fichiers de données et des
fichiers Redo Log
• Le nom des tablespaces
• La date et l’heure de création de la base de données
• Le numéro de séquence du journal courant
• Des informations relatives au point de synchronisation
• L’historique du journal
• Les informations de sauvegarde de l’utilitaire Recovery
Manager
69
Multiplexer le fichier de contrôle
Pour vous préserver d'une panne en un point unique affectant le fichier de

contrôle, il est vivement recommandé de multiplexer ce fichier et de stocker
chaque copie sur un disque physique distinct. Ainsi, si vous perdez un fichier
de contrôle, vous pouvez utiliser une copie multiplexée de ce fichier pour
redémarrer l'instance sans procéder à une récupération de la base de
données.
Le multiplexage peut être mise en œuvre lors de la création de la base :
 Spécifier la liste des fichiers de contrôle souhaités dans le paramètre

CONTROL_FILES avant d’exécuter l’ordre SQL CREATE DATABASE
Mais il peut aussi être mise en œuvre ultérieurement :
1. Arrêter la base proprement (pas ABORT !)
2. Dupliquer un fichier de contrôle existant vers une nouvelle destination
3. Mentionner le nouveau fichier de contrôle dans le paramètre
CONTROL_FILES
4. Redémarrer la base de données
Protéger les fichiers de contrôle est une opération simple. En plus ce sont de
petits fichiers, donc on peut en avoir plusieurs copies sans problème.
70
Multiplexer le fichier de contrôle lorsqu'un fichier SPFILE est utilisé
1. Modifiez le SPFILE :
ALTER SYSTEM SET control_files =
'$HOME/ORADATA/u01/ctrl01.ctl',
'$HOME/ORADATA/u02/ctrl02.ctl' SCOPE=SPFILE;
2. Arrêtez la base de données
shutdown immediate
3. Créez des fichiers de contrôle supplémentaires :
copy $HOME/ORADATA/u01/ctrl01.ctl
$HOME/ORADATA/u02/ctrl02.ctl
4. Démarrez la base de données :
startup
71
Multiplexer le fichier de contrôle lorsqu'un fichier PFILE est utilisé
1. Modifiez le SPFILE :
ALTER SYSTEM SET control_files =
'$HOME/ORADATA/u01/ctrl01.ctl',
'$HOME/ORADATA/u02/ctrl02.ctl' SCOPE=SPFILE;
2. Arrêtez la base de données
shutdown immediate
3. Créez des fichiers de contrôle supplémentaires :
copy $HOME/ORADATA/u01/ctrl01.ctl
$HOME/ORADATA/u02/ctrl02.ctl
4. Démarrez la base de données :
startup
72
Les fichiers Redo log
REDOLOG ou aussi fichiers de journalisation :
 Enregistrent l'ensemble des modifications de la BD Ordres :DML.
 Utilisés suite à un arrêt anormal ou récupération suite à la perte d'un fichier de
données
 Organisés en groupe, composés de membres
 Minimum deux groupes de un membre
 Ecriture circulaire → informations périodiquement écrasées
 Conservation possible en activant le mode ARCHIVELOG de la BD ( optionnel ).
 Utilise une zone de la SGA ( redolog buffer ) et un processus dédié ( LGWR )
 Le passage d'un groupe a l'autre est appelé switch et peut être force par la
commande alter system switch logfile
73
Principe de l‘ARCHIVOLOG
Les entrées de journalisation sont écrites par le processus LGWR dans l'un
des groupes de fichiers de journalisation, appelé groupe de fichiers de
journalisation en cours, dans les cas suivants :
• lorsqu'une transaction est validée,
• lorsqu'un tiers du tampon de journalisation est occupé,
• lorsque le tampon de journalisation contient plus d'un mégaoctet
d'enregistrements modifiés,
• avant que le processus DBWn n'écrive les blocs modifiés du cache de
tampons (buffer cache) de la base de données dans les fichiers de données.
 Une copie du redolog est effectuée dès que celui-ci est rempli au moment du
passage vers un autre groupe.
 Inconvénient du mode archivelog est la génération d'un volume important sur les
disques.
74
Principe de restauration
PROCESSUS
D’ARRIERE
PLAN
76
Processus d’arrière plan
 Lancés au démarrage d’Oracle

 Il existe environ une trentaine de processus Oracle. Leur lancement
dépend de la configuration de oracle.
 Certains processus peuvent être lancés en plusieurs exemplaires,
notamment DBWn, ARCn et CJQn. Le n désigne le nombre (0 pour
le premier)
Le nom des processus est normalise sur 4 caractères ( plus pour les
processus en multi-lancement ). Les processus standards sont les
suivants :
• ● DBWn
• ● LGWR
• ● CKPT
• ● SMON
• ● PMON
• ● CJQn
• ● ARCn ( optionnel )
77
Processus database writer (DBWn)
 Chargé d'écrire les blocs modifiés du Database Buffer Cache dans les fichiers de
données.
 Sur les systèmes multiprocesseurs à forte activité => plusieurs en parallèle (maxi 20)
 L'écriture est déclenche par un des évènements suivants :
 point de reprise
 seuil des tampons "dirty" atteint
 aucune mémoire tampon disponible
 temps imparti dépassé
A un instant t, la situation suivante est possible :
 Un fichier ne contient pas les données commitées, Si le Database Buffer Cache est
trop petit et que le commit tarde, les données non validées peuvent être écrites dans
les fichiers.
En cas de plantage à cet instant ?
 Les transactions étant dans les fichiers de journalisation, l'instance au moment du

redémarrage remet les fichiers dans un état cohérent ( processus SMON ).
78
Processus LGWR (Log Writer)
 Ecrit le contenu du RedoLog Buffer dans le fichier de journalisation courant.

 L'écriture est déclenchée sur un des évènements suivants :
 Lorsqu'une transaction est validée (commit).
 Lorsqu'un tiers du tampon de journalisation est occupé.
 Lorsque le tampon de journalisation contient plus d'un mégaoctet de
modifications enregistrées.
 Avant que le processus DBWn n'écrive les blocs modifiés du cache de tampons
de la base de données vers les fichiers de données.
 Toutes les trois secondes.
 C'est l'unique action produite lors d'un commit.
 L'écriture est rapide, notion de fast-commit.

 Etant donné que la journalisation est nécessaire à la récupération des données,
le processus LGWR ne confirme la validation qu'une fois les données
journalisées enregistrées sur le disque.
79
Processus CKPT (Checkpoint)
 Ce processus est chargé :
 de signaler DBWn aux points de reprise, (Ecriture)
 de mettre à jour les en-têtes de fichiers de données avec les informations sur le
point de reprise, (Ecriture)
 de mettre à jour les fichiers de contrôle avec les informations sur le point de reprise
 Ce mécanisme définit un point de reprise dans les fichiers de journalisation(Ecriture)
 En cas d'arrêt anormal, ce point marque le début des données à utiliser pour récupérer
l'instance.
 Un point de reprise peut être force par la commande alter system checkpoint.
 Les points de reprise sont mis en œuvre pour les raisons suivantes :
 Pour garantir que les blocs de données modifiés qui se trouvent en mémoire sont
régulièrement écrits sur disque afin d'éviter une perte des données en cas de panne
du système ou de la base de données.
 Pour réduire le temps de récupération d'une instance. Seules les entrées de
journalisation postérieures au dernier point de reprise doivent être traitées.
 Pour garantir que toutes les données validées ont été écrites dans les fichiers de
données lors de l'arrêt.
80
Processus SMON (System Monitor)
 Il permet la restauration de l’instance après un arrêt anormal
 Etapes de Récupération de l'instance :

1) ré implémente des modifications dans les fichiers de journalisation,
2) ouvre la base de données pour permettre l'accès aux utilisateurs,
3) annule les transactions non validées.
 Le processus SMON exécute également des fonctions de gestion de

l'espace :
 Il combine ou fusionne les espaces libres adjacents dans les fichiers
de données.
 Il libère les segments temporaires et augmente ainsi l'espace
disponible dans les fichiers de données.
81
Processus PMON (Process Monitor)
 Process Monitor est chargé principalement du nettoyage lors d'un plantage

d'un processus utilisateur,
 il assure la récupération des processus utilisateur qui ont échoués,
 il nettoie les transactions défaillantes.
 PMON est capable de détecter des transactions orphelines dont le processus
utilisateur a disparu suite à une coupure réseau ou un dysfonctionnement de
l'application.
 lors d'un échec d'un processus utilisateur.
 annule la transaction (ROLL BACK)
 nettoie le cache de tampons de la base de données.
 libère les zones mémoire allouées, supprime les verrous posés par les transactions et annule
les ressources affectées aux threads de la transaction.
 lors d'un fonctionnement normal de la base de données.

 PMON vérifie le statut des processus Dispatcher et Serveur.
 PMON redémarre les processus Dispatcher et Serveur si ils sont arrêtés.
 PMON peut être appelé par d'autre Processus .
 Si le processus Process Monitor PMON s’arrête, l'instance Oracle doit être
redémarrée.
82
Processus ARCn (processus d'archivage)
 Archiver = C’est un processus optionnel

 Il permet l'archivage des fichiers de journalisation pleins avant leur effacement
 Fonctionne quand La base est en mode ARCHIVELOG
 Il est fortement recommandé d'activer ce mode de fonctionnement en

production. En cas de crash, si les archivelogs sont préservés, Oracle peut
reconstruire toute la base de données jusqu'au moment du crash.
 Inconvénient : Demande de l'espace disque important.

83
Récapitulatif de l’architecture interne d’ORACLE
84
Récapitulatif (transaction en mémoire)
Enchainement
1. Une instance Oracle est démarrée sur le serveur
2. Une application cliente établit une connexion et ouvre une session
3. Le serveur détecte la requête de connexion et crée un processus serveur
dédié
4. L'utilisateur lance une requête SQL et un commit
5. Le processus serveur recherche dans la shared pool
6. requête existe ?
1. OUI : elle sera utilisée pour répondre
2. NON : la nouvelle requête est insérée dans la shared pool, analysée et exécutée
7. Le processus serveur récupère les données dans les fichiers de données
(et les charge dans le cache)
8. Le processus serveur modifie éventuellement les données dans le cache
9. Puisqu'il y a validation, LGWR écrit la transaction dans le cahier de reprise
10. Les changements seront répertoriés dans les fichiers de données par DBWn
11. Le résultat, ou une confirmation, est envoyé au processus utilisateur
DBA 1
CHAPITRE 2
GÉRER UNE INSTANCE

ORACLE
86
Fichiers de paramètres d'initialisation
Pour démarrer une instance, le serveur Oracle doit lire le fichier de

paramètres d'initialisation.
FICHIERS DE
PARAMETRAGE
88
Le fichier de paramètres
Pour démarrer une instance, le serveur Oracle lit le fichier de paramètres

d'initialisation. Ce dernier peut être de deux types :
 Fichier de paramètres statique, PFILE, généralement nommé initSID.ora.
 Fichier de paramètres persistant, SPFILE, généralement nommé spfileSID.ora.
Il existe deux types de paramètre :

 Explicite – Le fichier contient une entrée.
 Implicite – Le fichier ne contient aucune entrée, mais prend en compte les
valeurs Oracle par défaut.
Le fichier de paramètres contient le mode de fonctionnement de l'instance et

des indicateurs pour la base de données :
 Liste de paramètres d'instance
 Nom de la base de données à laquelle l'instance est associée
 Affectations destinées aux structures mémoire de la mémoire SGA (System
Global Area)
 Utilisation des fichiers de journalisation en ligne (online) remplis
 Noms et emplacements des fichiers de contrôle
 Informations relatives aux segments d'annulation
89
Fichier PFILE initSID.ora
 Il s'agit d'un fichier texte
 Il peut être modifié à l'aide d'un éditeur du système d'exploitation
 Toute modification est apportée manuellement
 Les modifications sont effectives au démarrage suivant
 Il ne peut être ouvert que lors du démarrage de l'instance
 Son répertoire par défaut est $ORACLE_HOME/dbs
Créer un fichier PFILE

 Créez ce fichier à partir d'un exemple de fichier init.ora.
 Copiez l'exemple à l'aide de la commande appropriée du système
d'exploitation.
 Identifiez-le de façon unique à l'aide d'un SID de base de données.
 Modifiez le fichier initSID.ora.
 Editez les paramètres.
 Affectez des valeurs qui répondent aux besoins de la base de données.
90
Fichier PFILE initSID.ora
# Initialization Parameter File: initdba01.ora

db_name = dba01
instance_name = dba01
control_files = (
home/dba01/ORADATA/u01/control01dba01.ctl,
home/dba01/ORADATA/u02/control01dba02.ctl)
db_block_size = 4096
db_cache_size = 4M
shared_pool_size = 50000000
java_pool_size = 50000000
max_dump_file_size = 10240
background_dump_dest = /home/dba01/ADMIN/BDUMP
user_dump_dest = /home/dba01/ADMIN/UDUMP
core_dump_dest = /home/dba01/ADMIN/CDUMP
undo_management = AUTO
undo_tablespace = UNDOTBS
. . .
91
Fichier SPFILE spfileSID.ora

 Il s'agit d'un fichier binaire.
 Sa mise à jour est effectuée par le serveur Oracle.
 Il réside toujours côté serveur.
 Il permet de rendre les modifications persistantes après l'arrêt et le
redémarrage.
 Il peut régler les valeurs des paramètres.
Créer un fichier SPFILE

 Créez ce type de fichier à partir d'un fichier PFILE.
CREATE SPFILE = ‘$ORACLE_HOME/dbs/spfileDBA01.ora’

FROM PFILE = ‘$ORACLE_HOME/dbs/initDBA01.ora’;
• Il peut être exécuté avant ou après le démarrage de l'instance.
92
Modification des paramètres SPFILE
 Tous les paramètres ne sont pas modifiables à chaud. Pour certains seule la clause
spfile de scope est possible (Exemple : SGA_MAX_SIZE)
 Les paramètres sont modifies au niveau global par la commande alter system set
 Ils peuvent être modifiés pour une session, par la commande alter session set , dans
ce cas la clause scope n'est pas précisé et seuls les paramètres modifiables a chaud
peuvent être utilises.
ALTER SYSTEM SET paramètre = valeur […] [ COMMENT = ‘texte’ ]

[ DEFERRED ] [ SCOPE = MEMORY | SPFILE | BOTH ]
Dans la vue v$system_parameter :
 La colonne issys_modifiable, niveau système, peut prendre 3 valeurs :
• IMMEDIATE → modifiable en mémoire, donc dans spfile via le scope=both
• DEFERRED → la valeur est valide en mémoire pour les futures sessions
• FALSE → modifiable uniquement dans scope=spfile
 La colonne isses_modifiable, niveau session, peut prendre 2 valeurs :
• TRUE → modifiable au niveau session
• FALSE → non modifiable au niveau session
93
Fonctionnement de la commande STARTUP
 Ordre des priorités :
 spfileSID.ora
 SPFILE par défaut
 initSID.ora
 PFILE par défaut
 Vous pouvez modifier ces priorités si vous indiquez un PFILE :
STARTUP PFILE = $ORACLE_HOME/dbs/initDBA1.ora

 Un PFILE peut indiquer qu'un SPFILE doit être utilisé.
SPFILE = /database/startup/spfileDBA1.ora
 Si vous indiquez un fichier PFILE, le fichier SPFILE par défaut n'est pas
utilisé pour démarrer l'instance.
 Un fichier PFILE peut éventuellement contenir une définition précisant
qu'un SPFILE doit être utilisé.
 Exemple : SPFILE=$HOME/ADMIN/PFILE/$ORACLE_SID.ora.
94
Exemple de modification des paramètres à chaud
La base doit avoir été démarrée avec un spfile.

Il faut être connecté avec sysdba
Dans l'exemple nous allons modifier le paramètre open_cursors
La commande show parameter permet de visualiser la valeur actuelle.
1. SQL> show parameter open_cursors → 50
2. Passer la valeur à 300
3. SQL> alter system set open_cursors=300 scope=both;
4. SQL> show parameter open_cursors → 300
 memory → la modification est valide jusqu'au redémarrage de l'instance

 spfile → la modification sera prise en compte au redémarrage de l'instance
 both → la modification est valide et le sera après redémarrage.
En complément il est possible de spécifier l'option DEFFERED, seules les prochaines

sessions qui se connecterons auront la nouvelle valeur. Cette option n'a pas de sens
avec un scope à spfile et ne concerne pas tous les paramètres.
DEMARRAGE
D’UNE
INSTANCE
96
Démarrage de l'instance (NOMOUNT)
Démarrer une base de données en mode NOMOUNT

97
Démarrage de l'instance (NOMOUNT)
• Le démarrage d'une instance en mode NOMOUNT ne s'effectue qu'à la
création d'une base de données ou à la recréation de fichiers de contrôle.
• Le démarrage d'une instance comprend les tâches suivantes :
 La lecture du fichier d'initialisation dans le répertoire

$ORACLE_HOME/dbs dans l'ordre suivant :
• fichier spfileSID.ora,
• s'il n'est pas détecté, fichier spfile.ora,
• s'il n'est pas détecté, fichier initSID.ora.
La déclaration du paramètre PFILE avec STARTUP remplace les valeurs

par défaut.
 L'affectation de la mémoire SGA.
 Le démarrage des processus d'arrière-plan.
 L'ouverture du fichier alertSID.log et des fichiers trace.
• Nommez la base de données à l'aide du paramètre DB_NAME dans le fichier
de paramètres d'initialisation ou dans la commande STARTUP.
98
Démarrage de l'instance (MOUNT)
Démarrer une base de données en mode MOUNT

99
Démarrage de l'instance (MOUNT)
• Pour effectuer des opérations de maintenance, vous démarrez une

instance et montez une base de données sans l'ouvrir.
• C'est le cas, par exemple, pour les tâches suivantes :
• renommer des fichiers de données,
• activer ou désactiver des options d'archivage de fichiers de journalisation,
• effectuer une récupération complète de la base de données.
• Le montage d'une base de données comprend les tâches
suivantes :
• Association d'une base de données à une instance démarrée
• Localisation et ouverture des fichiers de contrôle indiqués dans le fichier
de paramètres
• Lecture des fichiers de contrôle pour extraire le nom et le statut des
fichiers de données et des fichiers de journalisation. Toutefois, l'existence
des fichiers de données et des fichiers de journalisation en ligne n'est pas
vérifiée à ce stade.
10
Démarrage de l'instance (OPEN) 0
Démarrer une base de données en mode OPEN

10
Démarrage de l'instance (OPEN) 1
• les utilisateurs autorisés peuvent se connecter à la base et effectuer

des opérations standard sur les données.
• L'ouverture de la base de données comprend les tâches suivantes :

• Ouverture des fichiers de données en ligne
• Ouverture des fichiers de journalisation en ligne
• Si un fichier de données ou de journalisation en ligne est absent

lorsque vous tentez d'ouvrir la base de données, le serveur Oracle
renvoie une erreur.
• Au cours de cette dernière étape, le serveur Oracle vérifie que tous

les fichiers de données et de journalisation en ligne peuvent être
ouverts et contrôle la cohérence de la base de données. Si
nécessaire, le processus d'arrière-plan SMON (System Monitor)
déclenche la récupération de l'instance.
10
Commande STARTUP 2
Démarrez l'instance et ouvrez la base de données :

STARTUP
STARTUP [FORCE] [RESTRICT]

[PFILE=filename]
[OPEN [RECOVER][database]
|MOUNT
|NOMOUNT]
OPEN permet aux utilisateurs d'accéder à la base de données,
MOUNT monte la base de données pour certaines tâches d'administration, mais ne permet
pas aux utilisateurs d'y accéder,
NOMOUNT crée la mémoire SGA et lance les processus d'arrière-plan, mais ne permet pas
d'accéder à la base de données,
PFILE=parfile permet de configurer l'instance à partir d'un fichier contenant des
paramètres qui ne sont pas des paramètres par défaut.
FORCE interrompt l'instance en cours, puis exécute un démarrage normal
RESTRICT n'autorise l'accès à la base de données qu'aux utilisateurs disposant du
privilège RESTRICTED SESSION
RECOVER lance la procédure de restauration physique au démarrage de la base de
données
10
Commande ALTER DATABASE 3
• Remplacez le statut NOMOUNT de la base de données par le statut

MOUNT :
ALTER DATABASE db01 MOUNT;
• Ouvrez la base de données en lecture seule :
ALTER DATABASE db01 OPEN READ ONLY;
Pour faire passer la base de données du statut NOMOUNT à MOUNT ou du statut MOUNT à
OPEN, exécutez la commande ALTER DATABASE :
ALTER DATABASE { MOUNT | OPEN }
Vous pouvez ouvrir la base de données en mode lecture seule pour éviter que des
transactions utilisateur ne modifient des données.
ALTER DATABASE OPEN [READ WRITE| READ ONLY]
READ WRITE : ouvre la base de données en lecture-écriture pour permettre

aux utilisateurs de générer des fichiers de journalisation
READ ONLY : limite l'accès aux transactions en lecture seule et ne permet pas
de générer des informations de journalisation
10
Ouverture en mode d’accès restreint 4
Utilisez la commande STARTUP pour restreindre l'accès à une

base de données :
STARTUP RESTRICT
Une session en mode restreint s'avère utile, par exemple, lors de la mise à jour
des structures ou de l'import/export d'une base de données. la base de
données est démarrée en mode restreint pour qu'elle ne soit accessible qu'aux
utilisateurs disposant du privilège RESTRICTED SESSION.
On peut utiliser la commande ALTER SYSTEM pour placer une instance en
mode d'accès restreint :
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ENABLE RESTRICTED SESSION accepte uniquement les connexions

ultérieures des utilisateurs disposant du privilège RESTRICTED
SESSION,
DISABLE RESTRICTED SESSION désactive le privilège RESTRICTED
SESSION pour que les utilisateurs qui ne le possèdent pas puissent se
connecter.
10
Mettre fin à des sessions 5
Après avoir placé une instance en mode d'accès restreint, il faut fermer
toutes les sessions utilisateur actives avant d'effectuer des tâches
administratives :
ALTER SYSTEM KILL SESSION 'integer1,integer2'

integer1 correspond à la valeur de la colonne SID de la vue V$SESSION
integer2 correspond à la valeur de la colonne SERIAL# de la vue
V$SESSION
Remarque : L'ID de session et le numéro de série permettent d'identifier une session

de façon unique. Cette unicité garantit que la commande ALTER SYSTEM KILL
SESSION est appliquée à la session appropriée, même si l'utilisateur se déconnecte et
qu'une nouvelle session est ouverte sous le même ID de session.
Conséquences de la fin d'une session
A l'exécution de la commande ALTER SYSTEM KILL SESSION, le processus

d'arrière-plan PMON effectue les tâches suivantes :
 Annulation de la transaction en cours de l'utilisateur
 Libération de tous les verrous de table ou de ligne
 Libération de toutes les ressources réservées par l'utilisateur
10
Arrêt de la base de données 6
• Mode d'arrêt :
• A = ABORT
• I = IMMEDIATE
• T = TRANSACTIONAL
• N = NORMAL
la base de données doit être arrêtée pour effectuer la sauvegarde hors ligne de
toutes les structures physiques via le système d'exploitation et pour que les
modifications appliquées aux paramètres d'initialisation statiques soient effectives
au redémarrage.
Pour arrêter une instance, se connecter en tant que SYSOPER ou SYSDBA et

utiliser la commande suivante :
SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT ]

10
Modes d’arrêt de la base de données 7
Base de données cohérente (base "propre")
 Arrêt en mode Normal :

Le mode Normal est le mode d'arrêt par défaut :
 Aucune nouvelle connexion ne peut être établie.
 Le serveur Oracle attend la déconnexion préalable de tous les utilisateurs.
 Les tampons de journalisation et de la base de données sont écrits sur disque.
 Les processus d'arrière-plan prennent fin et la zone SGA est supprimée de la mémoire.
 Oracle ferme et démonte la base de données avant d'arrêter l'instance.
 La récupération de l'instance n'est pas nécessaire lors du redémarrage.
 Arrêt en mode Transactionnel

L'arrêt en mode Transactionnel évite aux clients de perdre leurs travaux en cours
 Aucun client ne peut lancer de nouvelle transaction pour l'instance indiquée.
 Le client est déconnecté lorsqu'il termine la transaction en cours.
 La fin de toutes les transactions entraîne l'arrêt immédiat de la base de données.
 Arrêt en mode Immédiate

L'arrêt en mode Immediate s'effectue dans les conditions suivantes :
 Les instructions SQL en cours de traitement par Oracle ne sont pas terminées.
 Le serveur Oracle n'attend pas la déconnexion des utilisateurs de la base de données.
 Oracle annule les transactions actives et déconnecte tous les utilisateurs.
 Oracle ferme et démonte la base de données avant d'arrêter l'instance.
10
Modes d’arrêt de la base de données 8
Base de données incohérente (base non "propre")
 Si les arrêts en modes Normal et Immediate échouent, on peut abandonner

l'instance de base de données en cours. Cette opération s'effectue dans les
conditions suivantes :
 Les instructions SQL en cours de traitement par le serveur Oracle sont

immédiatement interrompues.
 Oracle n'attend pas la déconnexion des utilisateurs de la base de données.
 Les tampons de journalisation et de la base de données ne sont pas écrits sur
disque.
 Les transactions non validées ne sont pas annulées.
 L'instance est interrompue sans fermeture des fichiers.
 La base de données n'est pas fermée, ni démontée.
 Une récupération est nécessaire au redémarrage ; elle s'effectue
automatiquement.
 Remarque : Il n'est pas conseillé de sauvegarder une base de données

incohérente..
10
Surveillance de la base de données 9
Surveiller une instance à l'aide de fichiers de diagnostic

 Les fichiers de diagnostic permettent de capturer des informations relatives aux
activités de la base de données. Ils s'avèrent également utiles pour la gestion
des instances. Leur type varie en fonction de l'incident qui se produit ou des
informations qui doivent être délivrées.
 Fichier alertSID.log : Informations destinées au fonctionnement

quotidien de la base de données
 Fichiers trace de processus en arrière-plan (background process) :

Informations essentielles en cas d'échec des processus d'arrière-plan
(SMON, PMON, DBWn, etc.)
 Fichiers trace utilisateur : Informations essentielles en cas d'erreurs

utilisateur fatales ou de fichiers d'une trace forcée par l'utilisateur.
11
Les fichiers d’alerte 0
 Chaque instance Oracle possède un fichier d'alertes. Au besoin, il est créé au

démarrage de l'instance. Sa taille augmente lors de l'utilisation de la base de
données.
 le fichier d'alertes sert à diagnostiquer des opérations quotidiennes ou des

erreurs. Ce fichier contient également des pointeurs sur des fichiers trace qui
délivrent des informations plus détaillées.
 Le fichier d'alertes conserve un enregistrement des informations suivantes :

 Date/heure d'arrêt ou de démarrage de la base de données
 Liste de tous les paramètres d'initialisation qui ne sont pas des paramètres par
défaut
 Démarrage des processus d'arrière-plan
 Thread utilisé par l'instance
 Numéro de séquence du journal utilisé par le processus LGWR (Log Writer)
 Informations relatives à un changement de fichier de journalisation
 Création de tablespaces et de segments d'annulation
 Instructions ALTER émises
11
Recap sur l’ouverture de la base 1
11
Recap sur l’ouverture de la base 2 2
11
Exercice 3
1 a Arrêtez la base de données, puis ouvrez-la en mode lecture seule.

b Connectez-vous en tant qu'utilisateur HR avec le mot de passe HR, puis insérez
une
ligne dans la table REGIONS en utilisant la syntaxe suivante :
INSERT INTO regions VALUES (8, ‘AFRIQUE’);
Que se passe-t-il ?
c Réaffectez à la base de données le mode lecture-écriture.
2 a Connectez-vous en tant qu'utilisateur HR avec le mot de passe HR, puis insérez la
ligne suivante dans la table REGIONS. Ne validez pas et ne quittez pas la

session.
INSERT INTO regions VALUES ( 8, ‘AFRIQUE’ );
b Démarrez SQL*Plus dans une nouvelle session. Connectez-vous en tant
qu'utilisateur SYS AS SYSDBA, puis procédez à un arrêt en mode Transactional.
c Annulez l'insertion dans la session de HR, puis quittez. Que se passe-t-il dans la
session de HR ? Que se passe-t-il dans celle de SYS ?
3 a Connectez-vous en tant qu'utilisateur SYS, puis démarrez la base de données.

b Démarrez une autre session en tant qu'utilisateur HR.
Remarque : Conservez les sessions SQL*Plus de SYS et de HR ouvertes.
c Sous l'ID utilisateur SYS, activez la session en mode restreint.
d Sous l'ID utilisateur HR, effectuez une sélection (SELECT) dans la table REGIONS.
L'opération aboutit-elle ? Quittez la session, puis reconnectez-vous sous l'ID

utilisateur HR. Que se passe-t-il ?
DBA 1
CHAPITRE 3
GÉRER LES UTILISATEURS

11
Gérer les utilisateurs 5
Notion de schéma
Objets de schéma
• Un schéma est un ensemble Tables
nommé d'objets. Déclencheurs
• Lorsqu'un utilisateur est créé, Contraintes
un schéma correspondant est Index
également créé. Vues
• Un utilisateur ne peut être Séquences
associé qu'à un seul schéma. Programmes stockés
• Le nom utilisateur et le nom de Synonymes
schéma sont souvent utilisés Types de données définis par
l'utilisateur
indifféremment
Liens de base de données
11
Liste de contrôle pour la création d'utilisateurs

 Identifiez les tablespaces dans lesquels l'utilisateur a besoin de
stocker des objets.
 Déterminez les quotas applicables pour chaque tablespace.
 Affectez un tablespace par défaut et un tablespace temporaire.
 Créez un utilisateur.
 Accordez des privilèges et des rôles à l'utilisateur.
Mécanisme d'authentification
 Trois méthodes permettent d'authentifier un utilisateur qui souhaite
accéder à la base de données :
 Par le dictionnaire de données
 Par le système d'exploitation
 Par le réseau
11
Créer un utilisateur : authentification par la base de données
CREATE USER MICDA

IDENTIFIED BY 123jhgjhgjhA
DEFAULT TABLESPACE data
TEMPORARY TABLESPACE temp
QUOTA 15M ON data
PASSWORD EXPIRE;
BY password indique que l'utilisateur est authentifié par la base de données et qu'il doit
fournir un mot de passe pour se connecter.
EXTERNALLY indique que l'utilisateur est authentifié par le système d'exploitation.
GLOBALLY AS indique que l'utilisateur est authentifié de façon globale.
DEFAULT TABLESPACE ou TEMPORARY TABLESPACE désigne le tablespace par défaut
ou le tablespace temporaire de l'utilisateur.
QUOTA définit l'espace maximum alloué aux objets détenus par l'utilisateur dans le
tablespace (le quota peut être défini par un entier représentant des octets ou des kilo-
octets et des mégaoctets
11
Créer un utilisateur : authentification par la base de données
Le mot-clé UNLIMITED permet d'indiquer que les objets détenus par l'utilisateur peuvent
utiliser l'ensemble de l'espace disponible du tablespace. Par défaut, aucun quota de
tablespace n'est affecté aux utilisateurs).
PASSWORD EXPIRE force l'utilisateur à réinitialiser le mot de passe lorsqu'il se connecte
à la base de données à l'aide de SQL*Plus (cette option n'est valide que si l'utilisateur est
authentifié par la base de données).
ACCOUNT LOCK/UNLOCK permet de verrouiller ou de déverrouiller explicitement le
compte de l'utilisateur (la valeur par défaut est UNLOCK).
PROFILE permet de contrôler l'utilisation des ressources et de définir le mécanisme de
contrôle par mot de passe à appliquer à l'utilisateur.
11
Créer un utilisateur : authentification par système d’exploitation

 Le paramètre d'initialisation OS_AUTHENT_PREFIX indique le format
des noms utilisateur.
 Sa valeur par défaut est OPS$.
CREATE USER ''OPS$ PC_CLASSE \MICDA''

IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE temp
QUOTA 15m ON data
PASSWORD EXPIRE;
 Sous Windows, le nom de la machine fait partie du login utilisateur

Ainsi un utilisateur MICDA au niveau Windows sur une machine PC_classe aura
pour login de connexion dans oracle : OPS$ PC_CLASSE \MICDA
 MICDA doit être membre du groupe ORA_DBA.
 Il est impératif de saisir la chaine OPS$ PC_CLASSE \MICDA entre guillemet et
en majuscules.
 Pour déclarer un utilisateur dans Oracle identifie par l'OS :
SQL> create user ''OPS$ PC_CLASSE \MICDA'' identified externally;
SQL> grant connect to ''OPS$ PC_CLASSE \MICDA'';
12
Supprimer un utilisateur
• La clause CASCADE permet de supprimer tous les objets

d'un schéma.
DROP USER MICDA;

• Vous ne pouvez pas supprimer les utilisateurs qui sont
connectés au serveur Oracle.
DROP USER MICDA CASCADE;

12
Droits des utilisateurs 1
 Créer un utilisateur ne suffit pas, il faut lui donner des privilèges.
 Le privilège minimum pour se connecter a Oracle est create session.
 Historiquement ce privilège est inclus dans le rôle connect.
 Les rôles permettent de regrouper un ensemble de privilèges sous un nom

unique.
 Oracle propose 3 rôles prédéfinis :

 connect → permet juste la connexion a la base.
 resource → permet la création d'objets tables et index.
 dba → tous les droits,.
GESTION DES
PRIVILEGES ET
DES ROLES
12
Gestion des privilèges et des rôles 3
 L'objectif est de sécuriser l'accès aux données de la base.
 Le principe est d'accorder ( Grant ) ou de retirer ( revoke ) des privilèges a

un utilisateur.
 Pour faciliter la gestion il est possible de regrouper un ensemble de

privilèges dans un rôle.
 Il existe deux types de privilèges utilisateur Oracle :
 Système : permet aux utilisateurs de réaliser certaines actions dans la

base de données
 Objet : permet aux utilisateurs d'accéder à un objet donné et de le
manipuler
12
Privilèges système : exemples

12
Accorder des privilèges système
• Utilisez la commande GRANT pour accorder des privilèges

système.
• Le bénéficiaire peut accorder le privilège système à
d'autres utilisateurs grâce à l'option ADMIN.
GRANT CREATE TABLE TO MICDA1;
GRANT CREATE TABLE TO MICDA1 WITH ADMIN OPTION;

12
Révoquer des privilèges système
• Utilisez la commande REVOKE pour révoquer un privilège système

accordé à un utilisateur.
• Les utilisateurs qui disposent d'un privilège système avec l'option

ADMIN OPTION peuvent révoquer des privilèges système.
• Seuls les privilèges accordés via la commande GRANT peuvent être

révoqués.
REVOKE CREATE TABLE FROM MICDA1;

12
Privilèges objets : exemples

12
Accorder des privilèges objets
• Utilisez la commande GRANT pour accorder des privilèges

objet.
• L'objet doit se trouver dans votre schéma ou vous devez
avoir reçu le privilège avec l'option GRANT OPTION.
GRANT EXECUTE ON dbms_output TO MICDA1;
GRANT UPDATE ON EMPLOYEES TO MICDA1 WITH GRANT

OPTION;
12
Révoquer des privilèges objets
• Utilisez la commande REVOKE pour révoquer des privilèges objet.

• Seul l'utilisateur qui a accordé un privilège objet peut le révoquer.
REVOKE SELECT ON EMPLOYEES FROM MICDA1;

13
Les rôles
 Un rôle (role) est un ensemble nommé de privilèges (système ou objets).
 Un rôle est accordé à un ou plusieurs utilisateurs, voire à tous (utilisation de
PUBLIC). Ce mécanisme facilite la gestion des privilèges.
 Un rôle peut être aussi attribué à un autre rôle pour transmettre davantage
de droits.
La chronologie des actions à entreprendre pour travailler avec des rôles est la
suivante :
 créer le rôle (CREATE ROLE) ;
 l’alimenter de privilèges système ou objets par GRANT ;
 l’attribuer par GRANT à des utilisateurs (voire à tous avec PUBLIC), ou à
d’autres rôles ;
 lui ajouter éventuellement de nouveaux privilèges système ou objets par
GRANT
13
Exemple de suppression en cascade
Créer un utilisateur MICDA1 avec comme rôle : connect et

resource.
Lui donner un mot de passe quelconque.
Se connecter MICDA1 et créer la table classe
SQL> create table classe( id char(2), nom char(15));
Insérer une ligne
SQL>insert into classe values(‘01',‘Mohamed');
SQL>commit;
=> Supprimer l’utilisateur MICDA1

13
Création d’un rôle
CREATE ROLE nomRôle

[ NOT IDENTIFIED | IDENTIFIED
{ BY motdePasse | USING [schéma.]paquetage | EXTERNALLY |
GLOBALLY } ] ;
• NOT IDENTIFIED indique que l’utilisation de ce rôle est autorisée sans mot
de passe.
• IDENTIFIED signale que l’utilisateur doit être autorisé par une méthode
(locale par un mot de passe, externe à Oracle et globale par un service
d’annuaire)
13
1 - Création de rôles
2 - Alimentation des rôles par des
CREATE ROLE consult privilèges
NOT IDENTIFIED; GRANT SELECT
CREATE ROLE modif ON HR.employees
NOT IDENTIFIED; TO consult;
CREATE ROLE tout_faire GRANT SELECT
NOT IDENTIFIED; ON MICDA1.classe
TO consult;
GRANT UPDATE (id,nom)
ON MICDA1.classe
3 - Affectation des rôles à des TO modif;
utilisateurs
GRANT consult, modif
GRANT consult
TO tout_faire ;
TO MICDA1;
GRANT tout_faire
TO HR;
13
Exemples de rôles prédéfinis

13
Révocation d’un rôle

• Pour pouvoir annuler un rôle, vous devez détenir au préalable ce rôle avec l’option
ADMIN OPTION ou avoir reçu le privilège système GRANT ANY ROLE.
REVOKE nomRôle [, nomRôle…]

FROM {utilisateur | nomRôle | PUBLIC} [,{utilisateur | nomRôle |
PUBLIC}]… ;
REVOKE SELECT
ON HR.employees Révocation d’un privilège d’un rôle
FROM consult;
REVOKE consult
From MICDA1; Révocation d’un rôle d’un utilisateur
REVOKE modif
FROM tout_faire; Révocation d’un rôle d’un rôle
13
Activation d’un rôle

• Les rôles, une fois créés et alimentés, sont donc actifs par défaut. les rôles peuvent
être désactivés puis réactivés par la commande SET ROLE.
SET ROLE
{ nomRôle [IDENTIFIED BY motdePasse] [,nomRôle [IDENTIFIED BY
motdePasse]]…
| ALL [EXCEPT nomRôle [,nomRôle]…]
| NONE } ;
• ALL active tous les rôles accordés à l’utilisateur qui exécute la commande.
• NONE désactive tous les rôles dans la session courante
Suppression d’un rôle
• DROP ROLE nomRôle;

LES OBJETS
D’UN
SCHEMA
13
Les objets d’un schéma 8
Données et index
Les tables
 Les tables sont des segments physiques.

 Elles contiennent les données utilisateur.
 Elles sont composées de colonnes typées.
 Elles présentent des contraintes d’intégrité (unique, clé primaire, clé étrangère,
‘check’).
 Elles sont Décrites dans le dictionnaire dans USER_TABLES, ALL_TABLES et
DBA_TABLES.
exemple
SQL> CREATE TABLE salaires
( no_emp NUMBER , salaire NUMBER)
TABLESPACE USERS
STORAGE (INITIAL 50K NEXT 50K MINEXTENTS 1 MAXEXTENTS 25
PCTINCREASE 0)
13
Les clusters
 Les clusters sont des segments spéciaux qui contiennent plusieurs tables
fusionnées, suivant en général une colonne de jointure.
 On peut les voir comme des jointures physiques.
(un certain nombre de tables du dictionnaire sont organisées en cluster.)
Les index
 Ce sont des accélérateurs, externes aux tables.

 Peuvent être créés / détruits a tout moment.
 Se remplissent dynamiquement au fur et à mesure des mises a jour de la table
indexée.
Remarque
un index n’est efficace que si la colonne indexée est utilisée dans la clause
WHERE d’un SELECT !!
un index peut ne pas être unique. Une clé primaire dans une table est
représentée sous forme d’index unique par Oracle.
14
Vues , synonymes, liens et séquences

Aucun de ces objet n’est un ’segment’. C’est a dire qu’ils ne consomment pas de
blocs dans les fichiers de la base. Ils sont simplement définis dans le dictionnaire
de données.
La vue
 Une vue est une fenêtre sur une table.
 Elle ne contient pas de données.
 Stockée dans le DD sous forme de ’select nommé’.
 La mise à jour d’une vue est en fait la mise a jour de la table ‘A TRAVERS’ la
vue. Il n’y a pas de duplication de données.
 Une vue peut porter sur plusieurs tables, éventuellement distantes !
Il existe des vues paramétrées qui peuvent rendre de grands services pour restreindre
certains type d’accès.
Si on veut restreindre l’accès a certaines périodes horaires par exemple :
CREATE VIEW emp_ouvrable
AS SELECT * FROM EMPLOYEES
WHERE TO_CHAR(SYSDATE,’HH’) BETWEEN ‘08′ AND ‘17′
en dehors de la période 8H $ 17H le prédicat est faux et la vue ne renvoie aucune données
!
14
synonymes
Un synonyme est un nom logique (un alias) référençant un objet d’un schéma.
Un synonyme peut être privé (visible seulement dans le schéma du propriétaire) ou public
(visibles par tous).
CREATE SYNONYM S_countries FOR hr.countries;
Les database links

Les database links sont des références à des comptes utilisateurs distants.
Ceci permet au sein d’une même session SQL d’accéder à différents objets de bases
reparties sur le réseau. On peut par exemple définir un database link Miage_settat qui
référence le schéma miage qui se trouve sur la base distante localisée sur le serveur de
SETTAT. Ensuite on pourra accéder à une table ou vue distante via ce database link.
CREATE DATABASE LINK nom_lien CONNECT TO « HR" identified by « HR" using ‘XE';
Séquence
Une séquence est un compteur programmable stocké en mémoire par Oracle et utilisable
de manière partagé.
Il est en général utilisé pour fournir des numéro de clé d’enregistrements.
CREATE SEQUENCE seq_table START WITH 1 INCREMENT BY 1;

INSERT INTO table1 (code, nom, age) VALUE (seq_table.nextval, ‘samir', 30);
DBA 1
CHAPITRE 4
GÉRER LES FICHIERS DE

JOURNALISATION
14
Les Fichiers de Reprise (Redo-Log) 3
• Fichiers de reprise ou redo log files ou journaux

• Idée de base
• enregistrer toutes les modifications apportées aux données pour
minimiser les problèmes liés aux pannes
Ces fichiers contiennent la trace de l’activité en terme de mise à jour sur la base
• Deux groupes au moins avec chacun au moins un fichier sont
obligatoires
• Ils doivent être multiplexés pour plus de sécurité
• Ne sont utiles qu’en cas de perte des fichiers de données, d'arrêt
anormal de la base ou d'échec d'une instance;
• pour restaurer des données validées non écrites dans les fichiers de données
• Fonctionnent de façon cyclique
• Le serveur Oracle met à jour les fichiers de reprise
• buffer de reprise
• processus LGWR
14
Groupes et membres de fichiers de reprise

 Groupe de fichiers de reprise est un ensemble de copies identiques
de fichiers de reprise online
 Un membre est un élément d'un groupe,
 LGWR écrit simultanément sur chaque membre du groupe

 tous les membres d'un groupe possèdent un numéro de séquence log
 sert d'identifiant
 le numéro courant est stocké dans le fichier de contrôle
 Configuration minimale
 au moins 2 groupes avec au moins un fichier chacun
 sans multiplexage
 En cas de Log Switch => changement de groupe

14
Rappel
 Serveur Oracle enregistre séquentiellement toutes les
modifications dans le buffer de reprise circulaire de la SGA
 Transfert du buffer vers le groupe courant de reprise par
LGWR
 quand un commit est exécuté
 quand le buffer est rempli au 1/3
 lors d'un délai d'attente du LGWR (3s)
 avant que DBWR n'écrive les blocs modifiés du buffer cache de données
dans les fichiers de données
 LGWR écrit séquentiellement dans les fichiers de reprise
 organisation circulaire des groupes
 quand un groupe est plein, on passe au suivant
14
Utilisation en mode multiplexés (au moins deux groupes)

• Un groupe à au moins 2 fichiers qui sont identiques et mis à jour
simultanément
• Il est conseillé de stocker chaque membre (fichier) d'un même
groupe sur des disques différents
• Il est conseillé d'avoir un même nombre de membres (de fichiers)
par groupe
Disque 1 Disque 2
14
 Initialisation des fichiers de reprise
 Générés lors de la création de la base de données
 Paramètres dans le script de création de la base

 MAXLOGFILES : nombre max de groupe dans une base de données
(<255)
 MAXLOGMEMBERS : nombre max de membre par groupe
 Paramètres dans le fichier d’initialisation init<sid>.ora

 LOG_FILES : nombre max de fichiers de reprise à ouvrir :
 doit être inférieur à MAXLOGFILES * MAXLOGMEMBERS
14
Modification de fichiers REDO LOG

• Ajout d'un groupe de fichiers
ALTER DATABASE [database ]

ADD LOGFILE [THREAD integer ]
[ GROUP integer ] filespec
[, [ GROUP integer ] filespec...
• Ajout d'un membre dans un groupe connaissant son Numéro ou le nom d'un
fichier

| ADD LOGFILE MEMBER
'filename' [ REUSE ]
[,'filename' [REUSE]]...
TO { GROUP integer
| ( 'filename'[REUSE] [,'filename']... )
| 'filename' [REUSE]}
[TO { GROUP integer
| ( 'filename'['filename']...)
| 'filename'} ]...
14
Modification de fichiers REDO LOG : Exemples

ALTER DATABASE ADD LOGFILE
('D:\data\DISK3\log3a.rdo',
'D:\data\DISK4\log3b.rdo') size 150 K;
-------------------------------------------------
ALTER DATABASE DBCOURS
ADD LOGFILE GROUP 4
(' ‘/oracle/oradata/DBCOURS/disk1/log4adbcours.dbf')
size 500K;
-------------------------------------------------
ADD LOGFILE MEMBER
‘/oracle/oradata/DBCOURS/disk2/log4bdbcours.dbf' TO
GROUP 4;
-------------------------------------------------
ADD LOGFILE MEMBER
‘/oracle/oradata/DBCOURS/disk1/log4adbcours.dbf' TO
‘/oracle/oradata/DBCOURS/disk3/log4cdbcours.dbf';
15
Déplacement des fichiers de reprise
1. Arrêter la base de données

2. Copier les fichiers de reprise au nouvel emplacement
3. Monter la base de données
4. Exécuter un ordre
ALTER DATABASE [databaseb] RENAME FILE
['file' [, 'file'] … TO ['file' [, 'file'] …
5. Ouvrir la base de données
6. Supprimer l’ancien fichier
15
Suppression de fichiers REDO LOG

• Suppression d'un groupe de fichiers

DROP LOGFILE
{ GROUP integer
| ('filename'[,'filename']...)
| 'filename'}
[, { GROUP integer
| ('filename'[,'filename']...)
| 'filename'}]...
• Suppression d’un membre

DROP LOGFILE MEMBER
'filename'[,'filename']...
• Le groupe doit être inactif
• un autre membre du groupe doit exister
• Si mode ARCHIVELOG et que le groupe du membre n'a pas été archivé, opération non
permise.
•
15
Suppression de fichiers REDO LOG

.
• Suppression des contenus des fichiers

CLEAR LOGFILE
'filename'[,'filename']...
• Exemples
ALTER DATABASE DROP LOGFILE

GROUP 3
ALTER DATABASE DROP LOGFILE

MEMBER 'D:\data\DISK3\log2b.rdo'
ALTER DATABASE CLEAR LOGFILE

'D:\data\DISK3\log2a.rdo'
15
Point de synchronisation ou checkpoint

• Un point de synchronisation se produit:
• quand LGWR change de groupe courant
• quand une instance s'arrête (un shutdown N,T ou I)
• Lors d’un TIMEOUT ou un intervalle en taille atteinte utilisation des
paramètres d'initialisation :
LOG_CHECKPOINT_INTERVAL et LOG_CHECKPOINT_TIMEOUT
• Sauvegarde d'un tablespace activé ou quand un tablespace est
désactivé
• Actions faites :
• tous les blocs modifiés du cache de données qui sont aussi traités
par le cache de reprise sont écrits par DBWR
• le processus en arrière plan CKPT met à jour les fichiers de
contrôle pour signaler son aboutissement
15
Déclencher ou forcer un checkpoint

• Pour rendre le groupe courant inactif en cas de problème
• Pour des besoins de maintenance
• Pour provoquer un archivage immédiat si le REDO LOG est trop grand
• Commande de l’administrateur à exécuter (privilège requis : ALTER
SYSTEM)
ALTER SYSTEM SWITCH LOGFILE ;
Forcer un Checkpoint sans Switch
• LGWR continue d'écrire dans le REDO LOG courant

• La commande de l’administrateur à exécuter est :
ALTER SYSTEM CHECKPOINT ;
• plus rapide, n'implique pas de switch logfile
15
Informations sur les REDO LOG
Utilisation des Vues :
 v$logfile : table contenant les noms des fichiers Redo Log et leur état.
 v$log : Vue contenant les informations issues du fichier de contrôle sur

les fichiers Redo Log.
 v$log_history :Vue contenant les informations sur l’historique des

fichiers Log
 V$THREAD: vue contenant des informations issues du fichier de contrôle

sur les Log Thread.
EXERCICES
15
Composants de l'architecture Oracle 7
Exercice 1
1. Parmi les affirmations suivantes, déterminez laquelle est vraie.
a) Un serveur Oracle est un ensemble de données composé de trois types de fichier.
b) Pour établir une connexion avec la base de données, l'utilisateur doit démarrer une instance
Oracle.
c) Une connexion est un chemin de communication entre le serveur Oracle et l'instance Oracle.
d) Une session démarre une fois que le serveur Oracle a authentifié l'utilisateur.
2. Parmi les zones mémoire suivantes, laquelle ne fait pas partie de la mémoire SGA ?
a) le cache de tampons de la base de données,
b) la mémoire PGA,
c) le tampon de journalisation,
d) la zone de mémoire partagée.
3. Identifiez les deux affirmations correctes se rapportant à la zone de mémoire

partagée.
a) La zone de mémoire partagée est composée du cache "library", du cache du dictionnaire de
données, de la zone SQL partagée, de la zone de mémoire Java et de la zone de mémoire
LARGE POOL.
b) La zone de mémoire partagée permet de stocker les dernières instructions SQL exécutées.
c) La zone de mémoire partagée est utilisée pour un objet pouvant être partagé globalement.
d) Le cache "library" est composé des zones SQL et PL/SQL partagées.
15
4. Parmi les zones mémoire suivantes, laquelle permet de mettre en mémoire cache
les
informations du dictionnaire de données ?
a) le cache de tampons de la base de données,
b) la mémoire PGA,
c) le tampon de journalisation,
d) la zone de mémoire partagée.
5. La tâche principale du tampon de journalisation consiste à enregistrer toutes les
modifications apportées aux blocs de données de la base.
a) Vrai
b) Faux
6. La mémoire PGA est une région de la mémoire qui contient les données et les
informations de contrôle de plusieurs processus serveur ou de plusieurs
processus
d'arrière-plan.
a) Vrai
b) Faux
7. Parmi les processus suivants, lequel ou lesquels sont disponibles au démarrage
d'une instance Oracle ?
a) le processus utilisateur,
b) le processus serveur,
c) les processus d'arrière-plan.
15
8. Affectez à chaque processus la tâche correspondante.

a) Database Writer permet l'écriture dans les en-têtes des fichiers de
données.
b) Log Writer se charge de la récupération de l'instance.
c) System Monitor exécute des opérations de nettoyage suite à l'échec
de
processus.
d) Process Monitor enregistre les modifications de la base de données
pour permettre la
récupération.
e) Checkpoint écrit les tampons "dirty" dans les fichiers de
données.
9. La structure physique d'une base Oracle est composée de fichiers de contrôle, de
fichiers de données et de fichiers de journalisation.
a) Vrai
b) Faux
10. Rétablissez la hiérarchie des structures suivantes, en commençant par la base de
données.
a) Tablespaces
b) Extent
c) Segment
d) Base de donnée
e) Bloc
16
Gérer l’instance d’oracle 0
Exercice
1. Connectez-vous à la base de données en tant qu' utilisateur SYS, puis arrêtez la base.
2. Une fois la base de données arrêtée, créez un fichier SPFILE à partir d'un fichier
PFILE.
Placez le fichier SPFILE dans le répertoire $HOME/ADMIN/PFILE en lui
affectant un nom au format spfileSID.ora (où SID correspond au nom de votre
instance).
Créez le fichier SPFILE à partir du fichier PFILE qui se trouve dans le répertoire
$HOME/ADMIN/PFILE.
3. Affichez le fichier SPFILE depuis le système d'exploitation
4. Connectez-vous en tant qu'utilisateur SYS, puis démarrez la base de données à l'aide
du fichier SPFILE.
5. a Arrêtez la base de données, puis ouvrez-la en mode lecture seule.
b Connectez-vous en tant qu'utilisateur HR avec le mot de passe HR, puis
insérez une ligne dans la table REGIONS en utilisant la syntaxe
suivante :
INSERT INTO regions VALUES (5, ‘Mars’);
Que se passe-t-il ?
c Réaffectez à la base de données le mode lecture-écriture.
16
Gérer l’instance d’oracle 1
6. a Connectez-vous en tant qu'utilisateur HR avec le mot de passe HR, puis

insérez la
ligne suivante dans la table REGIONS. Ne validez pas et ne quittez pas
la session. INSERT INTO regions VALUES ( 5, ‘Mars’ );
b Démarrez SQL*Plus dans une nouvelle session. Connectez-vous en tant
qu'utilisateur SYS AS SYSDBA, puis procédez à un arrêt en mode
Transactional.
c Annulez l'insertion dans la session de HR, puis quittez. Que se passe-t-il
dans la
session de HR ? Que se passe-t-il dans celle de SYS ?
7. a Connectez-vous en tant qu'utilisateur SYS, puis démarrez la base de données.

b Démarrez une autre session en tant qu'utilisateur HR.
Remarque : Conservez les sessions SQL*Plus de SYS et de HR ouvertes.
c Sous l'ID utilisateur SYS, activez la session en mode restreint.
d Sous l'ID utilisateur HR, effectuez une sélection (SELECT) dans la table
REGIONS.
L'opération aboutit-elle ? Quittez la session, puis reconnectez-vous sous l'ID
utilisateur HR. Que se passe-t-il ?
e Sous l'ID utilisateur SYS, désactivez la session en mode restreint.
16
Gérer les redo logs 2
Exercice
1. Répertoriez le nombre et l'emplacement des fichiers journaux existants et affichez le
nombre de groupes de fichiers de journalisation et de membres que contient votre base
de données.
• Interrogez la vue dynamique V$LOGFILE.
• Utilisez la vue dynamique V$LOG.
2. Dans quel mode la base de données est-elle configurée ? L'archivage est-il activé ?
• Interrogez la vue dynamique des performances V$DATABASE.
• Interrogez la vue dynamique des performances V$INSTANCE.
3. En respectant les conventions d'appellation suivantes, ajoutez un membre à chaque
groupe de fichiers de journalisation de la base de données stockée sur u04 :
Ajoutez un membre au groupe 1 : log01b.rdo
Ajoutez un membre au groupe 2 : log02b.rdo
Vérifiez le résultat obtenu.
• Exécutez la commande ALTER DATABASE ADD LOGFILE MEMBER pour
ajouter un membre à chaque groupe de fichiers de journalisation.
• Interrogez la vue dynamique des performances V$LOGFILE pour vérifier le
résultat.
16
4. En respectant les conventions d'appellation suivantes, ajoutez un groupe de fichiers de

journalisation à votre base de données et placez deux membres sur u03 et u04.
Ajoutez le groupe 3 : log03a.rdo et log03b.rdo
Vérifiez le résultat obtenu.
• Exécutez la commande ALTER DATABASE ADD LOGFILE pour créer un groupe.
• Interrogez la vue dynamique des performances V$LOGFILE pour afficher le nom
des nouveaux membres du nouveau groupe.
• Interrogez la vue dynamique des performances V$LOG pour afficher le nombre
de groupes de fichiers de journalisation et de membres.
5. Supprimez le groupe de fichiers de journalisation créé à l'étape 4.

• Exécutez la commande ALTER DATABASE DROP LOGFILE GROUP pour
supprimer le groupe de fichiers de journalisation.
• Interrogez la vue dynamique V$LOG pour vérifier le résultat.
• Supprimez du groupe les fichiers du système d'exploitation.
16
6. Redimensionnez tous les fichiers de journalisation en ligne en leur attribuant la taille

1024 Ko. (Les fichiers journaux ne pouvant pas être redimensionnés, vous devez
ajouter de nouveaux journaux et supprimer les anciens.)
• Exécutez la commande ALTER DATABASE ADD LOGFILE GROUP pour

ajouter deux nouveaux groupes d'une taille de 1024 Ko.
• Interrogez la vue dynamique V$LOG pour vérifier le groupe actif.
• Exécutez la commande ALTER SYSTEM SWITCH LOGFILE pour forcer les
changements de fichier de journalisation et attribuer au groupe le statut
inactif.
• Le nombre de changements de fichier requis varie.
• Exécutez la commande ALTER DATABASE DROP LOGFILE pour supprimer
les groupes inactifs.
• Interrogez la vue dynamique V$LOG pour vérifier le résultat.
16
Gérer les tablespaces et datafile 5
Exercice
1. Créez des tablespaces permanents associés aux noms et aux paramètres de
stockage suivants :
a DATA01, géré localement
b DATA02, géré localement avec des extents de taille uniforme
c INDX01, géré localement avec des extents d'une taille uniforme de 4 Ko
(activez l'extension automatique de 500 Ko).
d RONLY
e Affichez les informations à partir du dictionnaire de données.
Indice : Pour obtenir des informations sur les tablespaces, utilisez l'une des
interrogations suivantes :
- DBA_TABLESPACES
- V$TABLESPACE
- V$DATAFILE.
2. Allouez 500 Ko d'espace disque supplémentaire au tablespace DATA02 et vérifiez

le résultat.
16
Gérer les tablespaces et datafile 6
3. Déplacez le tablespace INDEX01 vers le sous-répertoire c:\u06. Vérifie l'emplacement

et le statut de INDEX01.
- Mettez le tablespace INDEX01 hors ligne.
- Utilisez V$DATAFILE pour vérifier le statut.
- Utilisez la commande appropriée du système d'exploitation pou
déplacer le tablespace vers c:\u06.
- Utilisez la commande ALTER TABLESPACE pour redéplacer le
tablespace.
- Mettez le tablespace INDEX01 en ligne.
- Utilisez V$DATAFILE pour vérifier le statut.
4. a Créez une table dans le tablespace RONLY. Mettez le tablespace RONLY en

lecture seule et vérifiez-le en exécutant une interrogation
appropriée.
b Essayez de créer une autre table TABLE2. Supprimez la première table
créée, TABLE1. Que se passe-t-il ?
5. Supprimez le tablespace RONLY et le fichier de données associé, puis vérifiez le

résultat.
16
Gérer les fichiers de contrôle 7
1. Exercice
1. Où se trouve le fichier de contrôle existant et quel est son nom ?

Interrogez la vue dynamique des performances V$CONTROLFILE.
Remarque : Vous pouvez également utiliser la vue V$PARAMETER ou
exécuter la commande SHOW PARAMETER pour afficher le nom et
l'emplacement du fichier de contrôle.
2. Tentez de démarrer la base de données sans fichier de contrôle. Pour simuler cette
opération, modifiez le nom du fichier de contrôle dans le fichier de paramètres
ou
renommez le fichier de contrôle. Que se passe-t-il ?
16
Gérer les fichiers de contrôle 8
3. Multiplexez le fichier de contrôle existant en utilisant le répertoire u02, puis nommez
le nouveau fichier ctrl02.ctl. Assurez-vous que le serveur Oracle a accès en écriture

à ce nouveau fichier.
- Avant d'arrêter la base de données, modifiez le fichier SPFILE
(SCOPE=SPILE) pour ajouter le nouveau fichier de contrôle au
fichier
d'initialisation.
- Arrêtez la base de données, puis copiez le fichier de contrôle
existant dans un nouveau fichier nommé ctrl02.ctl que vous
placerez dans le répertoire u02. Normalement, les droits sur le
fichier restent inchangés ; cette situation n'est présentée que pour les
besoins du cours.
- Démarrez la base de données.
- Interrogez la vue dynamique des performances V$CONTROLFILE
ou V$PARAMETER, ou utilisez la commande SHOW
PARAMETER pour confirmer que les deux
fichiers de contrôle sont utilisés.
4. Quelle est la taille initiale de la section relative aux fichiers de données dans le fichier
de contrôle ?
- Interrogez la vue dynamique des performances
16
Gérer les users et privilèges 9
Exercice
1. Créez l'utilisateur Bob associé au mot de passe CRUSADER. Assurez-vous que les
objets et les segments temporaires créés par Bob ne sont pas ajoutés au
tablespace SYSTEM. Assurez-vous également que Bob peut se connecter et
créer dans les tablespaces USERS et INDX des objets dont la taille peut
atteindre un mégaoctet. Utilisez le script lab15_01.sql pour accorder à Bob le
droit de créer des sessions.
Affectez à Bob le tablespace par défaut USERS et le tablespace temporaire
TEMP.
2. Créez l'utilisateur Emi associé au mot de passe MARY. Assurez-vous que les objets et
les segments de tri créés par Emi ne sont pas ajoutés au tablespace SYSTEM.
3. Affichez les informations sur Bob et Emi à partir du dictionnaire de données.

Vous pouvez interroger la vue DBA_USERS.
4. A partir du dictionnaire de données, affichez les informations sur la quantité d'espace

que Bob peut utiliser dans les tablespaces.
Indice : Vous pouvez interroger la vue DBA_TS_QUOTAS.
17
Gérer les users et privilèges 0
5. a Sous l'ID utilisateur Bob, modifiez le tablespace temporaire de Bob.

Que se passe-t-il ?
b Sous l'ID utilisateur Bob, remplacez le mot de passe de Bob par SAM.
6. Sous l'ID utilisateur SYSTEM, supprimez le quota de Bob sur son tablespace par
défaut.
7. Supprimez le compte d'Emi de la base de données.
8. Bob a oublié son mot de passe. Affectez-lui le mot de passe OLINK en vous
assurant
qu'il recevra une demande de modification de ce mot de passe lors de sa
prochaine
connexion.
MERC
I

Dba 1

Transféré par

Droits d'auteur :

Formats disponibles

Dba 1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dba 1

Transféré par

Droits d'auteur :

Formats disponibles

ORACLE

ORACLE n.m. (lat. oraculum) ANTIQ. Réponse

Les données sont omniprésentes autours de nous…

Les Bases de Données occupent aujourd'hui une place de plus en plus

Pourquoi les bases de données

 Environnement informatique traditionnel (gros systèmes d'exploitation)

 Mode de gestion de données : Système de gestion des fichiers.

 chaque équipe de l'entreprise dispose de ses propres fichiers de données où ne

Approche fichier avec PCs

Appli Appli Appli

Fichiers Elèves Fichiers Elèves Fichiers Elèves

Approche fichiers + SGF

Exemple de fichier de donnée

• Voici un exemple de ce à quoi ressemble un bout de programme COBOL en

 IDENTIFICATION DIVISION : Cette section va contenir les informations générales du programme,

 Redondance des données :

 Difficulté d'accès aux données

 Problèmes de partage des données

 Manque de portabilité des applications

• Organisation traditionnelle présentant plusieurs défauts

Système de Gestion de Bases de Données (DBMS)

Appli Cobol Elèves

Une BD est un ensemble volumineux, structuré et minimalement redondant de

Centraliser • Ensemble unique de stockage

• Contraintes d’intégrité au sein de la BD

Objectifs Rendre indépendant • Modification de la structure des données

Faciliter l’accès aux

Ensemble de logiciels systèmes permettant aux utilisateurs de faire des

Les niveaux d’abstraction du SGBD

• Niveau physique : Ce niveau appelé aussi niveau interne, gère le stockage et

• Niveau externe : Les schémas externes sont dédiées aux utilisateurs et

• Traçabilité : On peut, notamment en cas de problème important ou en cas d’attaque du système,

• la phase de conception, qui produira le modèle conceptuel et le modèle logique de la

• la phase de développement, qui verra la création et l’évolution de la base de

• la phase de production / exploitation et de maintenance, avec une base de production

les catégories de bases de donnes

• de la base de test a la base de production, pour la mise en exploitation réelle

fonctionnalitées facilité de mise en œuvre

Définition par oracle

« C’est un ensemble de programmes

• De nombreux utilisateurs ne voient pas l’intérêt de

Une bonne compréhension de la conception et

 D.B.A. = Data Base Administrator = Administrateur de bases de données. Il

 Les taches du DBA :

• Pour pouvoir faire les exercices, et pratiquer a minima l’administration Oracle,

• Oracle SQL developper v 1.2.1 : Un outil de développement graphique,

dans un environnement multi

Se connecter à une instance Oracle :

• un listener , (LISTENER) processus réseau qui attend les

Il y a entre SHARED_SERVERS and MAX_SHARED_SERVERS

Une instance Oracle :

 Database Buffer Cache : cache des données

 Généralement, augmenter la taille du Database Buffer Cache

 La taille du bloc (DB_BLOCK_SIZE) étant fixée à la création

 Dimensionné par le paramètre DB_CACHE_SIZE.

ALTER SYSTEM SET DB_CACHE_SIZE = 48M;

Composée de deux structures :

 Sa taille est définie et dimensionnée par le