Chapitre - 2 - ArchitectureOracle BD

Introduction
Vue d’ensemble
Connexion à une base de données
Base de données et instance
Architecture générale d’Oracle
Chapitre 2: Architecture d’un serveur ORACLE
Naourez MEJRI
naourez.mejri@gmail.com
ISIKef
19 octobre 2020
Naourez Mejri Chapitre 2 1 / 50

Introduction
Vue d’ensemble
Plan de l’exposé
1 Introduction
2 Vue d’ensemble
3 Connexion à une base de données
4 Base de données et instance
5 Architecture générale d’Oracle

Introduction
Vue d’ensemble
Dans ce chapitre, nous allons examiner les composants d’une

base de données Oracle et les concepts d’implémentation qui
régissent leur utilisation.
Pour pouvoir administrer une base Oracle, il est nécessaire
de
comprendre comment ces différents composants interagissent,
connaître leur rôle
et de savoir comment personnaliser au mieux le système afin
de répondre à des besoins spécifiques.

Introduction
Vue d’ensemble
Un serveur de bases de données est composé de :

une instance = plusieurs processus et une zone de mémoire
une base de données
plusieurs schémas, assimilés à des utilisateurs
Dans le cas de clusters de machines, Oracle peut associer
plusieurs instances à une même base de données.

Introduction Connexion client-serveur
Vue d’ensemble Processus utilisateur
Connexion à une base de données Processus serveur
Base de données et instance Processus d’écoute
L’utilisateur qui désire accéder aux données gérées par un

serveur Oracle doit tout d’abord établir une connexion.
Une connexion va être créée avec l’instance Oracle
L’utilisateur va ouvrir une session.

Programme qui demande une interaction avec le serveur Oracle

Géré en entier par l’outil ou l’application cliente et n’entre
pas directement en interaction avec le serveur Oracle.
S’exécute sur la machine client : il est démarré lorsque l’outil
démarre et se termine lorsque l’utilisateur quitte ou est obligé
d’interrompre la session en cours.

Programme qui entre directement en interaction avec le ser-

veur Oracle.
Répond aux appels générés et renvoie les résultats.
Sert principalement à charger en mémoire les données du
disque pour permettre à l’utilisateur de les traiter.
Analyse et exécute les requêtes et retourner les données.
Il existe deux types de processus serveurs :
Les serveurs dédiés
Les serveurs partagés

Serveurs dédiés
A chaque fois qu’un uti-
lisateur se connecte, il est
pris en charge par un pro-
cessus serveur.
Si 10 utilisateurs se
connectent, 10 proces-
sus serveurs sont ainsi
créés, et chacun prend
en charge spécialement
les commandes du seul et
même processus utilisa-
teur tout le temps de sa
session.
Serveurs partagés
Un petit groupe de pro-
cessus serveurs s’occupe
d’un grand nombre de
processus utilisateurs.
Besoin d’un processus ré-
seau - le DISPATCHER-
qui met les requêtes des
utilisateurs dans une file
d’attente, et le(s) proces-
sus serveur(s) partagé(s)
exécute(nt) toutes les re-
quêtes, une par une.

Le processus LISTENER écoute les requêtes entrantes sur

un port de réseau.
Lorsqu’il reçoit une requête, il la transmet à un gestionnaire
de service, c’est-à-dire à un processus serveur qui s’exécute
sur le même système que le serveur Oracle. Il peut s’agir
d’un processus serveur dédié ou d’un dispatcher, ce dernier
collaborant avec des processus serveur partagés.

Introduction
Vue d’ensemble
Deux concepts essentiels :
Base de données (BD) Instance

se compose d’un en- se compose d’une struc-
semble de fichiers phy- ture de mémoire partagée
siques qui contiennent et d’un ensemble de pro-
notamment les données. cessus.
Deux éléments étroitement liés mais différents.
Analogie
L’instance représente une application (Exp. Microsoft Word) et
la base de données le document (Exp. Un document Microsoft
Word).
Pour accéder à la BD, il faut l’ouvrir avec une instance Oracle.

Introduction Bases de données Oracle
Vue d’ensemble Structure logique
Connexion à une base de données Instance
Base de données et instance Contenu d’un schéma

Désignée par le nom de la base de données avec le paramètre

DB_NAME qui est attribué à la création de la base de
données.
Constituée de
un ou plusieurs fichiers de données qui contiennent les don-
nées proprement dites.
au moins un fichier de contrôle des informations de contrôle
sur la BD.
au moins deux groupes de fichiers de journalisation qui enre-
gistrent toutes les modifications apportées à la Base.


Fichiers de données-DataFiles
servent au stockage physique des données contenues dans une
base Oracle.
contiennent toutes les informations de la base dans un format spé-
cifique à Oracle.
contiennent l’ensemble des données de la base (les tables, les vues,
les procédures, synonymes, index,etc.).
leur dimension dépend de la quantité d’information à stocker.
logiquement regroupés sous forme de tablespaces.
Une BD Oracle inclut au moins

2 tablespaces, SYSTEM et
SYSAUX.

Fichiers de journalisation - Redo log files)

Oracle maintient un journal de toutes les transactions qui ont eu
lieu dans la BD, appelé journal de reprise (redo log).
Ces transactions sont sauvegardées dans des fichiers du journali-
sation (redo log) en ligne.
Utilisés en cas de défaillance de la base, ou d’altération des fichiers
de données pour rétablir les transactions dans l’ordre correct.
Les informations redo sont stockées séparément des fichiers des
données.

Fichiers de journalisation - Redo

log files)
Une base de données Oracle dis-
pose au minimum de trois fichiers
redo log.
Ecriture cyclique : lorsque le pre-
mier fichier est plein, écriture dans
le suivant et ainsi de suite jusqu’à
remplissage de tous les fichiers.
Ensuite reprise depuis le premier,
en remplaçant son contenu par
des nouvelles données transaction-
nelles.

Quant tous les groupes sont remplis, les données du premier

groupe sont écrasées pour écrire les nouvelles données.
Problème
Que faire si on aura besoin de ces données plus tard ?
Solution
Archiver les fichiers journaux avant de les écraser → Fichiers
de journalisation archivés

Fichiers de journalisation archivés- Archived Redo log files

Dans le mode ARCHIVELOG, Oracle réalise une copie de chaque
fichier redo log dans des fichiers redo log archivés avant de le réuti-
liser (c’est une sauvegarde des fichiers journaux) .
Ces fichiers archivés peuvent ensuite servir à récupérer n’importe
quelle partie de la base de données jusqu’à un point précis dans le
temps.
Ces fichiers peuvent être stockés sur des disques (serveurs) dis-
tants, ce qui optimisera la sécurité de la BD.
Une base de données n’est pas forcément en

mode ARCHIVELOG, si elle ne l’est pas, les
fichiers journaux ne sont pas archivés.

Fichiers de contrôle - control files

Contiennent des informations de contrôle sur la base :
Nom de la base ;
Date et heure de création de la base ;
Noms et localisation des fichiers de données et redo log ;
Numéro de séquence du fichier redo log courant ;
Des informations de synchronisation.
Au moins deux fichiers de contrôle sont utilisés.

Fichiers de paramètres - parameter files

Ce fichier contient les paramètres de démarrage de la base et
d’autres valeurs qui déterminent l’environnement dans lequel elle
s’exécute.
Lorsque la base est démarrée, le fichier de paramètres est lu et plu-
sieurs structures mémoire sont allouées en fonction de son contenu.
Ce fichier est optionnel.

Fichiers de paramètres - parameter files

Il existe deux types de fichiers de paramètres :
PFILE SPFILE
(parameter file) (server parameter file)
Fichier texte Fichier binaire
Modifiable via un éditeur texte Modifiable via SQL
Disponible sur la machine Centralisé
de démarrage (sur le serveur uniquement)
Nommé init%.ora Nommé spfile%.ora

Fichier de mot de passe - password file

Le fichier de mot de passe est utilisé pour établir l’authenti-
cité des utilisateurs privilégiés de la base de données

Tablespace
Une base de données est divisée en unités de stockage logiques
appelés tablespaces. Chaque base de données est divisée de
manière logique en un ou plusieurs tablespaces.
Les tablespaces SYSTEM et SYSAUX sont obligatoires. Ils
sont créés en même temps que la base de données et doivent
être en ligne.

Des concepts pour gérer finement la mémoire

Le block de données est l’unité logique la plus fine, 8ko par
défaut.
L’extent est un ensemble contigü de blocks, alloués en une
seule fois.
Le segment est un ensemble d’extents dédiés à un même objet
(table, index, ...)
Le tablespace : regroupe un ensemble d’objets (=segments)
pour faciliter leur administration. Peut atteindre 8 exabytes !
Un tablespace = un ou plusieurs fichiers de données


Une instance Oracle :

permet d’accèder à une base de données Oracle
n’ouvre qu’une seule base de données
Les paramètres qui déterminent la taille et la composition
d’une instance sont stockés soit dans un fichier d’initialisa-
tion au format texte appelé init.ora, ou bien dans la base
de données dans un fichier de paramètres serveur (SPFILE,
server parameter file) au format binaire appelé spfile.ora.
Le fichier de paramètres d’initialisation est lu au démarrage
de l’instance et peut être modifié par le DBA.

Définition
Ensemble des processus (serveur et d’arrière-plan) et des zones
mémoire qui sont alloués pour permettre l’exploitation de la
base de données.
Elle est constituée de :
une zone de mémoire partagée appelée System Global Area
(SGA) ;
une zone mémoire associée aux processus serveurs appelée
Program Global Area (PGA)
un ensemble de processus d’arrière-plan (Background
process) ayant chacun un rôle bien précis ;
un ensemble de processus serveur (Server process) char-
gés de traiter les requêtes des utilisateurs ;

Zones mémoires :
La SGA - System Global Area
Zone partagée par tous les utilisateurs de la base de données
Allouée au démarrage de l’instance en mémoire principale :
doit-être la plus grosse possible.
Son but est d’économiser les E/S. Elle contient :
le cache de données (database buffer cache)
le cache de reprise (redo log buffer) : log des changements
récents
le cache d’exécution partagé (shared pool) pour les requêtes
SQL et PL/SQl. Contient le dictionnaire de données en cache.
La PGA - Program Global Area

Zone d’exécution des processus du serveur
Allouée au lancement de chaque processus
Zones mémoire-SGA
Le paramètre définissant la taille globale du SGA est SGA_MAX_S

Zones mémoire-SGA
Zone de mémoire partagée

Contient
le cache bibliothèque ou cache « library » (library cache) qui
maintient des informations sur les instructions exécutées dans
la base de données pour autoriser le partage d’instructions
SQL souvent utilisées.
le cache du dictionnaire de données (dictionnary cache)

Zones mémoire-SGA
Zone de mémoire partagée
Cache « library »
Cache du dictionnaire de données
Contient le texte de la re-
Contient les définitions des
quête SQL, son plan d’exécu-
objets de la base de données
tion et sa représentation ana-
qui ont été utilisé récemment
lysée (parse tree) après son
(les méta données).
exécution (la version compilée
de la requête SQL). Permet au serveur Oracle de
ne pas avoir à aller chercher
Est utilisée lorsqu’une requête
ces informations sur le disque
identique sera émise (par
à chaque exécution d’une re-
n’importe quel utilisateur)→
quête SQL.
pour accélérer son exécution.

Zones mémoire-SGA
Cache de tampons de la base de données

C’est la zone de chargement et de mise à jour en mémoire
des blocs de données (blocs les plus récemment utilisés).
Ces blocs proviennent des fichiers de données.
c.à.d lorsque vous allez lancer une première fois une requête
Oracle, cette dernière va se charger de ramener les données à
partir du disque dur.
Lors des exécutions suivantes, les blocs de données seront
récupérés à partir de cette zone mémoire, entraînant ainsi
un gain de temps.

Zones mémoire-SGA
Tampon de journalisation
Les entrées redo (redo entries) décrivent les modifications
apportées à la base de données.
Elles sont écrites, périodiquement, dans les fichiers de jour-
nalisation (redo log) en ligne.
Avant d’être enregistrées dans ces fichiers, les transactions
sont d’abord placées dans une portion de la zone SGA, appelé
tampon de journalisation ou tampon journaux de reprise.
La taille du ce tampon est déterminée par le paramètre
LOG_BUFFER.

Zones mémoire-SGA
Zone de mémoire Java

La zone de mémoire java stocke les commandes java analy-
sées.
Elle permet d’exécuter le code java stocké dans le noyau
Oracle.
Sa taille est définie au moyen du paramètre
JAVA_POOL_SIZE.

Zones mémoire-SGA
Zone de mémoire Large pool

C’est une structure mémoire optionnelle.
Le DBA peut configurer cette zone pour soulager le buffer de
données ou la zone SQL partagée pour certaines opérations
gourmandes en mémoire.
Sa taille est définie au moyen du paramètre
LARGE_POOL_SIZE.

Zones mémoire-SGA
Zone mémoire des flux

Dans une seule base de données, vous pouvez spécifier que
la mémoire de Streams soit allouée à partir d’une zone de
la mémoire SGA appelée zone mémoire des flux ou streams
pool.

Zones mémoire - PGA
PGA-Program Global Area

C’est la mémoire privée des différents processus.
Pour un processus serveur, le PGA contient :
Une zone de travail SQL (SQL Work area) allouée dynami-
quement pour certaines opérations ;
Des informations sur la session ;
Des informations sur le traitement des requêtes de la session ;
Les variables de session.
Elle est allouée lors du démarrage du processus et libérée lors
de l’arrêt du processus.
La PGA totale, allouée à tous les processus serveurs, est ap-
pelée PGA agrégée (Aggregated PGA)

Processus d’arrière-plan
La relation entre les structures physiques et les structures mémoire
d’une base de données est maintenue et mise en œuvre au moyen
de processus d’arrière-plan (background process).
Ils assurent la gestion d’une base de données et peuvent varier en
nombre selon la configuration de celle-ci.
La plupart des processus d’arrière-plan sont lancés au démarrage
de l’instance et arrêtés lors de l’arrêt de l’instance.
Le processus « serveur » prend en charge les requêtes de processus
utilisateurs
Les principaux processus d’arrière-plan pour une instance stan-
dard sont les suivants :

SMON - System Monitor

Le processus de surveillance SMON entreprend une récupé-
ration après crash (panne, accident) lors du redémarrage en
utilisant les fichiers redo log en ligne.
Libère aussi les segments temporaires, éliminant les objets
transactionnels qui ne sont plus employés.
Sert à défragmenter les fichiers des données, tablespaces etc.
Au cours de la récupération de l’instance, SMON effectue
deux opérations :
Un Roll Forward pour appliquer aux fichiers de données les
modifications non enregistrées des transactions validées.
Puis un Roll Back pour enlever des fichiers de données les
modifications enregistrées des transactions non validées.

PMON - Process Monitor

Le processus de surveillance PMON est principalement
chargé du nettoyage lors du plantage d’un processus utili-
sateur :
Annulation (ROLLBACK) de la transaction ;
Libération des verrous posés sur les données modifiées à cause
de la transaction en cours.
Capable de détecter si un processus utilisateur qui a ouvert
une session sur le serveur n’est plus "Présent" et n’a pas
fermé la session.
La cause de la non "présence" du processus utilisateur est
variable : Fin anormale de l’application sur le poste de l’uti-
lisateur, coupure réseau, etc.

DBWn - Database Writer

C’est un processus obligatoire.
Il est dédié à l’écriture du « Database Buffer Cache » dans
les fichiers de données de la base de données.
Permet de vérifier en permanence le nombre de blocs libres
dans le « Database Buffer Cache » afin de laisser assez de la
place disponible pour l’écriture des données dans le buffer.
Plusieurs processus DBWn (numérotés DBW0, DBW1, etc)
peuvent s’exécuter simultanément ce qui limite les risques de
contention (désaccord) lors d’importantes opérations portant
sur plusieurs fichiers de données.

DBWn - Database Writer

Fréquence d’écriture du DBWn
Toutes les trois secondes
Dès que la Dirty List (liste des blocs modifiés dépasse un seuil
prédéfini
Chaque fois qu’un processus consulte la liste LRU et ne
trouve pas un emplacement libre après un nombre prédéter-
miné de recherche de bloc
Lors de chaque Checkpoint (CKPT)
Chaque fois qu’une base est arrêtée normalement
Chaque fois qu’un tablespace est mis en mode OFFLINE ou
READ ONLY ou s’il fait partie d’une sauvegarde en ligne

LGWr - Log Writer

Le processus d’écriture dans les fichiers de journalisation en
ligne.
Il écrit y séquentiellement.
L’écriture est déclenchée par un des événements suivants :
Une transaction est validée (COMMIT) ;
Le 1/3 de « Redo Log Buffer » est plein ;
DataBase Writer s’apprête à écrire des blocs modifiés de tran-
sactions non validées dans les fichiers de données.
Un délai est dépassé.

LGWr - Log Writer

En cas d’arrêt anormal de l’instance, on peut se retrouver
dans l’un des cas suivants :
Un fichier de données peut ne pas contenir les données mo-
difiées de transactions validées,
Un fichier de données peut contenir des données modifiées de
transactions non validées.
Grâce au LGWr, les fichiers de journalisation contiennent
forcément les informations nécessaires pour :
Refaire les transactions validées (mettre dans les fichiers de
données les données modifiées des transactions validées),
Ou défaire les modifications non validées (remettre dans les
fichiers de données les anciennes données pour les modifica-
tions non validées).

CKPT - Checkpoint
Le processus de contrôle CKPT provoque l’exécution de
DBWn, qui écrit tous les blocs de données qui ont été mo-
difiés depuis le dernier point de contrôle dans les fichiers de
données,
Puis met à jour les en-têtes de ces fichiers ainsi que le fichier
de contrôle afin de signaler le point de contrôle le plus récent.
Ce processus s’exécute automatiquement lorsqu’un fichier
redo log en ligne est plein.
Le CKPT s’exécute automatiquement lors du déclenchement
des événements suivants :
Immédiatement et à la demande de l’administrateur ;
A chaque changement du groupe ou fichier REDO LOG ;
Si le TIMEOUT à été atteint (paramètre
LOG_CHECKPOINT_TIMEOUT
Naourez Mejri Chapitre 2 : intervalle 46
de/ 50
temps) ;
ARCn - Archiver
Le processus LGWR écrit dans chacun des fichiers redo log
en ligne à tour de rôle.
Lorsque le premier fichier est plein, il écrit dans le suivant et
ainsi de suite.
Une fois le dernier fichier rempli, il écrase le contenu du pre-
mier.

RECO - Recoverer
Le processus de récupération RECO résout les défaillances
dans des configurations de base de données distribuées, en
tentant d’accéder aux bases impliquées dans des transactions
distribuées interrompues brutalement.

Autres processus
Il existe d’autres processus d’importance secondaire tels que :
Dnnn(Dispatcher),
Pnnn(Parallel query),
LMSn (Lock Manager Server),
etc.

Correspond à un utilisateur : les deux portent le même nom

Ensemble d’objets de l’utilisateur manipulables en SQL
Exemple : tables, index, clusters, triggers, vues, dimensions,
fonctions, etc.
Un objet correspond à :
plusieurs extents
un segment
un tablespace
un ou plusieurs fichiers du tablespace
Pas de correspondance schema/tablespace

Chapitre - 2 - ArchitectureOracle BD

Transféré par

Informations du document

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

Chapitre - 2 - ArchitectureOracle BD

Transféré par

Droits d'auteur :

Formats disponibles

Introduction

Chapitre 2: Architecture d’un serveur ORACLE

Naourez Mejri Chapitre 2 1 / 50

3 Connexion à une base de données

4 Base de données et instance

5 Architecture générale d’Oracle

Naourez Mejri Chapitre 2 2 / 50

Dans ce chapitre, nous allons examiner les composants d’une

Naourez Mejri Chapitre 2 3 / 50

Un serveur de bases de données est composé de :

Naourez Mejri Chapitre 2 4 / 50

L’utilisateur qui désire accéder aux données gérées par un

Naourez Mejri Chapitre 2 5 / 50

Programme qui demande une interaction avec le serveur Oracle

Naourez Mejri Chapitre 2 6 / 50

Programme qui entre directement en interaction avec le ser-

Naourez Mejri Chapitre 2 7 / 50

Naourez Mejri Chapitre 2 9 / 50

Le processus LISTENER écoute les requêtes entrantes sur

Naourez Mejri Chapitre 2 10 / 50

Deux concepts essentiels :

Base de données (BD) Instance

Deux éléments étroitement liés mais différents.

Pour accéder à la BD, il faut l’ouvrir avec une instance Oracle.

Architecture générale d’Oracle

Naourez Mejri Chapitre 2 12 / 50

Désignée par le nom de la base de données avec le paramètre

Naourez Mejri Chapitre 2 13 / 50

Naourez Mejri Chapitre 2 14 / 50

Une BD Oracle inclut au moins

Naourez Mejri Chapitre 2 15 / 50

Fichiers de journalisation - Redo log files)

Naourez Mejri Chapitre 2 16 / 50

Fichiers de journalisation - Redo

Naourez Mejri Chapitre 2 17 / 50

Quant tous les groupes sont remplis, les données du premier

Naourez Mejri Chapitre 2 18 / 50

Fichiers de journalisation archivés- Archived Redo log files

Une base de données n’est pas forcément en

Naourez Mejri Chapitre 2 19 / 50

Fichiers de contrôle - control files

Naourez Mejri Chapitre 2 20 / 50

Fichiers de paramètres - parameter files

Naourez Mejri Chapitre 2 21 / 50

Fichiers de paramètres - parameter files

Naourez Mejri Chapitre 2 22 / 50

Fichier de mot de passe - password file

Naourez Mejri Chapitre 2 23 / 50

Naourez Mejri Chapitre 2 24 / 50

Des concepts pour gérer finement la mémoire

Naourez Mejri Chapitre 2 25 / 50

Naourez Mejri Chapitre 2 26 / 50

Une instance Oracle :

Naourez Mejri Chapitre 2 27 / 50

Naourez Mejri Chapitre 2 28 / 50

La PGA - Program Global Area

Naourez Mejri Chapitre 2 30 / 50

Zone de mémoire partagée

Naourez Mejri Chapitre 2 31 / 50

Zone de mémoire partagée

Naourez Mejri Chapitre 2 32 / 50

Cache de tampons de la base de données

Naourez Mejri Chapitre 2 33 / 50