Embed Size (px)
DESCRIPTION
Architecture fonctionnelle d'Oracle
Citation preview
Administration des bases de données
Chapitre :
Architecture fonctionnelle d’Oracle
Description des structures qu’implique la
connexion d’un user à un serveur Oracle
Description des étapes du traitement d’une
requête
Description des étapes du traitement d’un
ordre de LMD
Description des étapes du traitement des
opérations COMMIT
Objectifs
La gestion de la BD se fait grâce à un système
appelé SGBD ou DBMS.
Le SGBD est un logiciel de haut niveau qui offre les
possibilités suivantes :
Permettre l'accès aux données de façon simple et
transparente
Consulter et manipuler les datas présentes dans la BD
Définir des contraintes d’intégrité sur les datas
Définir des protections d'accès (password, privilèges,
rôles ...)
Gérer les problèmes liés aux accès multiples aux
informations par différents users
Introduction aux SGBDs (1)
Le SGBD est un logiciel de haut niveau qui offre les
possibilités suivantes :
Prévoir des procédures de reprise en cas d'incident
(sauvegardes, journaux,...)
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
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 une non
cohérence de l’information
Introduction aux SGBDs (2)
Avantages de l’utilisation
d’un SGBD
Avantage Conséquence
Centralisation des données Intégrité des données
Contrôle centralisé de
l'accès aux données
Sécurité accrue
Instructions de traitement
très puissantes
Grande rapidité de
développement
Indépendance vis-à-vis de
la structure physique et
logique des données
Maintenance facilitée
1ère version du SGBDR ORACLE a été commercialisée
en 1979
Une version PC voit le jour en 1984. Les versions Unix
se succèdent
Actuellement Oracle est un véritable environnement de
travail avec des outils pouvant être classés en:
Outils d'administration (SQL*loader, Oracle Entreprise
Manager, Oracle Manager(SQL*DBA), Import/Export)
Outils de développement (Oracle Developer, SQL*Plus)
Outils de communication (SQL*Net…)
Outils de génie logiciel (Designer,…)
Outils d'aide à la décision ( Discover…)
SGBD Oracle
Le SO est un SGBD relationnelles-objets qui
permet d’assurer:
La définition et la manipulation des données
La cohérence des données
La confidentialité des données
L'intégrité des données (non violation des
contraintes d’intégrités)
La sauvegarde et la restauration des données
La gestion des accès concurrents
Serveur Oracle 9i (SO)
Un user de BD peut se connecter au SO de l’une des manières suivantes:
Connexion directe à l’hôte
Connexion à deux tiers (client-serveur) : la machine de l’user est directement connectée à la machine qui exécute le SO
User démarre une application Developer et accède à une BD située sur un serveur NT
Connexion à trois tiers : établissement de la communication par le biais d’une application ou un serveur réseau
Application sur un serveur NT et BD sur un hôte UNIX
Méthodes d’accès au (SO)
Une connexion est une voie d’accès de communication entre user process et SO:
Connexion directe à l’hôte : la voie est établie à l’aide de mécanismes de communication inter-processus
Connexion 2 tiers ou 3 tiers : la voie est établie à l’aide de logiciel réseau
En établissant une connexion, une session est ouverte
Tant de session que de connexion
Mais c’est quoi une connexion?
Pour établir une connexion avec BD, il faut réaliser les
étapes :
User démarre SQL*Plus ou application, démarrage donc d’un
user process
Lors de l’identification de l’user (login, password et chaîne
hôte), un processus se crée sur la machine qui exécute le SO :
Server process
Connexion à une BD C/S
Client SO
User process
Server process
Fonctionne sur la machine du client
Démarre lors de l’appel d’un outil (SQL*Plus,
SQL*Loader, Developer..) ou d’une application
L’UPI (interface du programme utilisateur) est
incluse dans le UP
À chaque requête, UP appelle le SO par le biais
de l’UPI
User Process (UP)
Fonctionne sur la machine serveur (hôte)
Créé lors de la connexion de l’user et se termine lors de sa déconnexion
Utilise l’OPI (Oracle Program Interface) pour communiquer avec le SO suite à une demande de l’UP
Envoie les résultats à l’UP
Utilise une zone mémoire nommée PGA (zone mémoire du programme) qui stocke des informations concernant les variables utilisées, la session utilisateur et l’état des transactions en cours
Server Process (SP)
Chaque SP prend en charge 1 seul UP (configuration la plus simplifiée : serveur dédié).
Dans le cas où on a plusieurs utilisateurs qui accèdent à la base ceci impliquera une multiplication des UP et des SP(par conséquent des PGAs) qui conduira à une surcharge du système
Solution (à partir de 100 à 150 utilisateurs simultanés): Utilisation de l’option MTS (Multi-Threaded Server) peut économiser des ressources en transférant une partie des opérations effectuées dans la PGA vers la SGA
Server Process (SP)
Le SO se compose:
D’une instance Oracle
Zone mémoire globaledu système (System Global Area (SGA) )
Processus en arrière-plan
(background processes)
D’une BD Oracle
Structure logique représente les
composantes qu’on crée dans une
BD (table, index, etc)
Structure physique représente la
méthode de stockage des datas
utilisée par Oracle (physical files)
Indépendance entre la structure
logique et physique
Composants du SO
Une instance Oracle (SGA + background processes)
Est un moyen d’accéder à une BD Oracle
Ouvre toujours une seule et unique BD
Est identifiée en définissant ORACLE_SID au niveau de l’OS
Instance Oracle
Allouée dans la mémoire virtuelle de l’ordinateur où réside le SO
Représente la zone mémoire déterminante d’une instance, tant par sa taille que par son rôle
Assure le partage des datas entre les users (les datas lues et modifiées transitent par le SGA)
Instance Oracle-SGA
Comprend 5 structures de mémoireShared pool : stocke des informations comme les opérations SQL récentes et les informations du dictionnaire de datas les plus récemment utilisées
Database buffer cache : utilisé pour stocker les datas les plus récemment utilisées
Redo log buffer cache : utilisé pour enregistrer les modifications apportées à la BD
Instance Oracle-SGA-structure
Large Pool (new Oracle 9i) : zone mémoire optionnelle que le DBA configure afin de fournir une mémoire pour les opérations de BD comme les opérations de backup ou de restauration
JAVA Pool (new Oracle 9i) : zone mémoire optionnelle que le DBA configure afin de fournir une mémoire pour les opérations Java
Instance Oracle-SGA-structure
Sa taille est définie par le paramètre d’initialisation
SHARED_POOL_SIZE qui se trouve dans le fichier des
paramètres
Composée de :
Library cache : Formé de 3 zones:
shared SQL area (SSA) : contient le texte de l’ordre, le
code analysé et le plan d’exécution qui définit les étapes à
suivre lors de l’exécution de l’ordre (comme déterminé par
l’optimiseur)
shared PL/SQL area (SPA) : idem que le SSA. Quand une
procédure est exécutée alors le corps de cette dernière
transitera dans le SPA
Locks and others structures : des structures de contrôle
comme les verrous
Data dictionnary cache (Row cache) : stocke les
informations du dictionnaire de datas les plus récemment
utilisées (définitions de tables et de colonnes, les users
names, les passwords et les privilèges)
SGA-Shared Pool
Taille de chacun des buffers dans le cache = Taille d’un
bloc de data. Définie par le paramètre DB_BLOCK_SIZE
Pour augmenter la taille du Database buffer cache, il faut
modifier DB_CACHE_SIZE (new Oracle 9i)
La valeur affectée est adaptée pour être multiple de
DB_BLOCK_SIZE
Algorithme Least Recently Used LRU (buffers les moins
récemment accédés) afin d’exclure ces derniers et de
permettre l’hébergement de nouveaux blocs dans le
buffer cache
Partagé entre tous les utilisateurs connectés à la BD
SGA-Database buffer cache
C’est le SP qui enregistre les modifications (suite à l’exécution
d’un ordre INSERT, UPDATE, DELETE, CREATE, ALTER ou
DROP) apportées à la BD dans le redo log buffer cache
Ses caractéristiques sont :
Taille en octets définie par le paramètre LOG_BUFFER
(paramètre dynamique)
Stocke des enregistrements redo qui conservent la trace des
modifications ( bloc modifié, emplacement de la modification et la nouvelle valeur)
Il est circulaire c’est à dire une fois qu’ il est rempli, les anciennes entrées redo sont enregistrées dans les fichiers
redo log et les nouvelles entrées redo prennent leurs places
Écriture séquentiel
SGA-Redo log buffer cache
Les background processes
effectuent les fonctions
courantes nécessaires au
traitement simultané de plusieurs
requêtes users, tout en
préservant
L’intégrité
La performance du système
Selon la configuration, chaque
instance peut utiliser plusieurs
background processes, mais elle
contient par défaut 5 processus
principaux
SGA-Background processes
Les 5 background processes sont :
DBWR (DataBase Writer ) chargé d'écrire les datas modifiées dans la
BD ( plus spécifiquement dans les datas files)
LGWR (Log Writer) : sauvegarde les modifications enregistrées au
niveau du buffer redo log dans la BD ( plus spécifiquement dans les
Redo Log files)
PMON (Process Monitor) chargé de nettoyer les ressources et les
verrous
SMON (System Monitor) chargé de vérifier la cohérence de la BD et éventuellement sa restauration lors du démarrage si besoin
CKPT (CheckPoint) met à jour les informations concernant l’état de la BD à chaque enregistrement définitif des modifications effectuées
dans le database buffer cache
SGA-Background processes
Par défaut, Oracle démarre un DBWR (DBW0) au
moment de démarrage de l’ instance
Lorsqu’on a plusieurs utilisateurs ou lorsque le
système est chargé, Oracle peut démarrer 9 autres
DBWR (DBW1 jusqu’à DBW9) pour améliorer la
performance
Le paramètre DB_WRITER_PROCESSES détermine le
nombre de processus additionnels que nous pouvons
démarrer
SGA-DBWR
Lorsque LGWR écrit les redo log buffers sur le
disque, SP peut alors écrire de nouvelles entrées dans
le redo log buffer
LGWR écrit les buffers sur le disque dans les cas
suivants :
Suite à un COMMIT
Quand le redo log buffer est rempli au 1/3
Chaque 3 secondes
SGA-LGWR
Il existe également d'autres processus d'importance
secondaire :
RECO (Recoverer) : processus optionnel permettant de
résoudre les transactions interrompues brutalement dans un
système de BD distribuées
ARCH (Archiver) : processus optionnel. Il permet de dupliquer
les fichiers Redo-Log dans un espace d'archivage.
Dnnnn (Dispatcher, nnnn représente une suite de nombre
entiers) : processus optionnel
n'est présent que dans les configurations MTS
Il permet de router les requêtes vers d’autres serveurs
SGA-Background processes
Il existe également d'autres processus d'importance
secondaire :
Snnnn (Server, nnnn représente une suite de nombre entiers):
Ce processus n'est également présent que dans les
configurations MTS
Il permet de recevoir les demandes de connexions
distantes envoyées par le processus Dnnnn d'un serveur
distant
LCKn(Lock) est un processus de verrouillage utilisé lorsque
Oracle Parallel Server est installé
SGA-Background processes
Désigné par son nom (DB_NAME)
Oracle conseille d’utiliser le même nom pour la BD et l’instance
Les files composants une BD contiennent les datas utilisateur et les informations nécessaires au fonctionnement correct des opérations liées à la BD
Les fichiers physiques d'une base Oracle permettent de stocker de manière persistante les datas manipulées par Oracle
Les fichiers d'une BD Oracle sont :
Data files
Redo Log files
Control files
BD Oracle-Structure physique
Les datas files stockent :
Le dictionnaire de données (les tables, les vues, les
procédures stockées, ...)
Les objets utilisateurs
Les « images avant » de données modifiées par les
transactions en cours
L'extension est .dbf dans le cas de serveur Unix
Est associé à une et une seule BD
BD Oracle-Data files
Écriture est assurée par le processus DBWR
Lorsque le fichier est plein, il peut augmenter
automatiquement de taille
Le DBA doit préciser un incrément et fixer une
dimension maximale
évite la saturation du système
évite la création de fichiers de taille supérieur à celle
posée par Linux (2GO)
BD Oracle-Data files
L'extension est .rdo ou .log dans le cas de serveur Unix
Ces files contiennent l'historique des modifications
effectuées (image avant et après) sur la BD pour
garantir la restauration de la base en cas de panne et
donc garantir un état cohérent de la base
Une BD requiert au moins 2 fichiers redo log
Les Redo-log files sont dans un format propriétaire
Oracle et l'écriture dans ces fichiers est assurée par le
processus LGWR
BD Oracle-Redo log file
L’analyse des Redo-log files se fait grâce à l’éditeur
Log Miner
Oracle propose également un mode archivage (copie
offline) permettant la sauvegarde du fichier Redo-log
avant sa réutilisation pour restaurer la base (Cache
redo-log ou fichiers redo log archivés) en cas de panne
d’un disque
BD Oracle-Redo log file
L'extension est .ctl dans le cas de serveur Unix
Ces fichiers contiennent l’information nécessaire à la mise à jour et à la vérification de l’intégrité des BDs. Ces informations sont:
Nom de la BD, Date et heure de création de la base, L'emplacement des Redo-Log files, etc
Une BD requiert au moins un control file
Ils sont créés lors de la création de la base
Ils sont repérés par le fichier des paramètres (nommé aussi fichier d'initialisation)
Indispensable au démarrage de la base
BD Oracle-Control file
Outre les files de BD, un SO utilise d’autres files :
Les logiciels Oracle
Des fichiers dont l’installation est nécessaire au bon fonctionnement d’une base
Leur nombre est impressionnant
L’ajout d’un nouveau logiciel ou la modification d’un composant Oracle nous oblige à intervenir sur ces fichiers
En jargon Oracle, l’ensemble de ces fichiers s’appelle distribution
BD Oracle-Autres structures
physiques
Init File ou fichier de paramètre
Définit les caractéristiques d’une instance Oracle
Format texte contenant l'ensemble des paramètres de démarrage de la base nommé initSID.ora (PFILE)
, où SID représente le nom donné à l'instance
Ou format d’initialisation persistant et le fichier sera nommée spfileSID.ora (SPFILE), où SID représente le nom donné à l'instance (new Oracle 9i)
Créé par défaut lors de la création d'une base
BD Oracle-Autres structures
physiques
Fichiers redo log archivés
copie offline des redo-log files pouvant être
nécessaire à la restauration des datas suite à une
panne d’un disque
Password File ou fichier mot de passe
Utilisé pour établir l’authenticité des utilisateurs de BD
Alert File
En cas de problèmes, Oracle enregistre des messages explicites
Si le fichier n’existe pas lors du démarrage de la BD, Oracle crée un automatiquement
BD Oracle-Autres structures
physiques
1. L’analyse
a) UP envoie la query au SP pour l’analyser et la compiler
b) SP vérifie la validité de la commande et utilise la zone shared pool pour compiler l’ordre (Library cache) , vérifier les privilèges d’accès et résoudre les noms d’objets spécifiés dans l’ordre SQL (Row cache)
c) SP renvoie l’état au UP (réussite ou échec de l’analyse)
2. L’exécution
SP se prépare à extraire les datas
3. La récupération
SP renvoie à user les lignes extraites par la query. Selon la mémoire de transfert, une ou plusieurs récupérations sont requises pour transférer les résultats de la query
Traitement d’une requête
SP
UP
Select *
From emp
Order by ename;
1.a
1.c
2
3
PGA
1.b
Traitement d’un ordre LMD
Update emp
Set sal=sal*1.1
Where empno=15
1
2
3
4
5
SP
Requiert juste 2 phases
L’analyse
Similaire à celle du traitement d’une requête
L’exécution
1. SP lit les blocs de datas à partir des files datas si ces derniers ne sont pas dans le database buffer cache
2. Les copies des blocs lus sont placées dans le database buffer cache
3. SP met les verrous sur les datas
Traitement d’un ordre LMD
Update emp
Set sal=sal*1.1
Where empno=15
1
2
3
4
5
SP
4. SP enregistre les modifications à apporter au bloc rollback « image
avant » et aux blocs de datas (new value) dans le buffer redo log
5. Dans le database buffer cache, SP enregistre l’image avant dans le bloc rollback et met à jour le bloc de datas
Le traitement de l’ordre DELETE et INSERT est similaire
à celui de l’UPDATE à une exception près :
L’image avant d’une suppression contient les valeurs de colonnes de la ligne supprimée
Alors que les insertions requièrent seulement les informations sur l’emplacement de la ligne pour être stockées dans le rollback
Traitement d’un ordre LMD
1. SP place un enregistrement de validation dans le buffer redo log
2. LGWR effectue une écriture contiguë de toutes les entrées du buffer redo log dans les redo log files
3. SP informe UP de l’achèvement du COMMIT
4. SP enregistre les informations indiquant que la transaction est complète et que les verrous mis sur les ressources peuvent être supprimés
Traitement du COMMIT
3
UP
SP
1
2
4
1
Après ce cours, vous devez être capable :
D’expliquer les fichiers de BD : data files, control files, online redo logs
D’expliquer la structure de la mémoire SGA : DB buffer cache, shared SQL pool, Java Pool, Large Pool and redo log buffer
D’expliquer l’utilité des background processes : DBWR, LGWR, CKPT, PMON, SMON et ARC
D’expliquer les différentes étapes d’exécutions des ordres SQL : parse, execute, fetch
Résumé
Questions ?
1. Quels sont les différents composants d’un serveur
Oracle ?
Pour chaque composant énuméré, donnez son rôle.
2. Quels sont les trois architectures de connexion à un
serveur Oracle ?
Pour chaque architecture, précisez ses avantages et
ses inconvénients.
3. Lorsqu’un utilisateur exécute un « commit », dans
quel fichier sont enregistrées les modifications, avant
que le serveur Oracle ne renvoie le message
« validation complète » à l’utilisateur ?
Questions :
