DBA- Partie I

FACULTE DES SCIENCES ET TECHNIQUES-SETTAT

Administration Oracle

11g

Partie I

Noreddine GHERABI

F I L I E R E D E S I N G E N I E U R S - G I

Noreddine GHERABI

2

I- PRESENTATION

La version oracle database 11g release 2 est disponible depuis septembre 2010. La version 11.2 pour Windows est disponible depuis avril 2010. Cette nouvelle release contient l’outil de développement rapide APEX (Oracle Application Expresse). Un serveur http est également intégré dans la base de données. Il utilise la technologie WebDAV et est implémenté sous le nom de XML DB. Il est nommé par Oracle « Embedded PL/SQL Gateway ». Oracle Database 11g représente la nouvelle génération de la gestion des informations en entreprise, qui permet de faire face aux exigences qu’imposent la croissance rapide des volumes de données, l’évolution constante de l’environnement et la nécessité de fournir une qualité de service maximale tout en réduisant et en contrôlant les coûts informatiques. Oracle 11g offre une performance améliorée du stockage sur fichiers, des fonctionnalités renforcées pour la sécurité, d’importantes améliorations de performances pour Oracle XML DB, et des fonctions nouvelles pour l’OLAP et le datawarehouse. Oracle Database 11g reste centré sur le grid computing : il permet de constituer des matrices de serveurs et de systèmes de stockage économiques, capables de traiter les données de façon rapide, fiable et évolutive, en supportant les environnements les plus exigeants, qu’il s’agisse de datawarehouse, de transactionnel ou de gestion de contenus.

II- SERVEUR ORACLE

Un serveur Oracle, système de gestion de base de données, se compose d'une instance Oracle et d'une base de données Oracle .

L'instance et la base de données constituent ensemble un serveur Oracle.

L'architecture d'Oracle Server peut être décrite en quatre phases:

1. Connexion utilisateur à la base de données 2. Structures mémoire qui font partie de l’instance Oracle 3. Processus d’arrière plan qui font partie de l’instance Oracle 4. Structures physiques de fichiers formant la base de données Oracle

Connexion utilisateur à la base de données

Dans une configuration de serveur dédié, le Listener lance pour chaque client un nouveau processus serveur et lui cède le contrôle de la session du client. Chaque connexion client est servie par son propre processus serveur.

Noreddine GHERABI

3

Le schéma ci-dessus correspond à une configuration serveur dédié et pour une application client/serveur.

Le processus de connexion passe par les étapes suivantes :

1. Le client contacte le listener Oracle en choisissant l’instance à laquelle il souhaite se connecter (demande d’un nom de service).

2. Le listener démarre un processus dédié appelé processus serveur 3. Le listener envoie un accusé de réception au client avec l'adresse du processus

serveur dédié 4. Le client établit une connexion avec le processus serveur dédié 5. Le processus serveur se connecte à l'instance Oracle pour le compte du

processus utilisateur (création d’une session utilisateur)

C’est le processus serveur qui se connecte à l'instance Oracle pour servir le processus utilisateur durant toute la session du client.

Le processus utilisateur n'entre pas directement en interaction avec le serveur Oracle. C'est plutôt, le processus serveur qui interagit avec le serveur Oracle, répond aux demandes de l’utilisateur et lui renvoie les résultats.

III- 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

Noreddine GHERABI

4

La base de données est l’ensemble des fichiers qui permettent de gérer les données de la base. 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.

Le schéma suivant présente les principaux composants d’un serveur Oracle :

1- Instance Une instance est l’ensemble des processus d’arrière-plan (background process) et de zones mémoire qui sont allouées au démarrage de la base de données, pour permettre l’exploitation des données. Une instance Oracle est composée d’une zone mémoire appelée System Global Area (SGA), associée à cela un certain nombre des processus qui interagissent entre le SGA et les fichiers de la base de données qui se trouvent sur disque. Elle est identifiée par

Noreddine GHERABI

un identifiant appelé SID. Généralement, le SID porte le même nom que la base et l’instance. Une instance ne peut ouvrir qu’une seule base de données à la fois et dans la grande majorité des cas, une base de données est ouverte par une seule instance.En dehors des processus de l’instance, il existe des processus utilisateurs correspondant à l’application utilisée par l’utilisateur pour se connecter à la base de données (SQL*Plus, un progiciel, un logiciel spécifique, …).Dans une architecture client/serveur, ceposte de l’utilisateur et communiquent avec le serveur à travers le réseau grâce à la couche Oracle Net. Le PGA

Afin d’optimiser ses performances, le serveur Oracle dispose de plusieurs zones mémoires différentes ayant chacune une tâche claire dans le fonctionnement du serveur. Comme on a pu le voir précédemment, le processus utilisateur est un processus qui établie une connexion, ouvre une session avec une base de données Oracle. Par exemple, un utilisateur quiainsi une session pendant laquelle il pourra envoyer au moteur d’Oracle des commandes SQL. La session durera jusqu’à la fin de la connexion. Bref, La zone mémoire allouée pour le fonctionnement de chdu serveur s’appelle la zone mémoire du programme (PGA, Program Global Area).

1.1 La SGA (System Global Area)

La mémoire SGA (System Global Area) est une mémoire partagée par tous les serveur et les processus en arrière

La SGA est composée de trois composants obligatoires et trois éléments facultatifs.

Les composants obligatoires :

1. Zone de mémoire partagée (Shared Pool) 2. Cache de tampons de la base de données (database buffer cache)3. Tampon de journalisation

entifiant appelé SID. Généralement, le SID porte le même nom que la base et

Une instance ne peut ouvrir qu’une seule base de données à la fois et dans la grande une base de données est ouverte par une seule instance.

des processus de l’instance, il existe des processus utilisateurs correspondant à l’application utilisée par l’utilisateur pour se connecter à la base de données (SQL*Plus, un progiciel, un logiciel spécifique, …). Dans une architecture client/serveur, ces processus utilisateurs sont situés sur le poste de l’utilisateur et communiquent avec le serveur à travers le réseau grâce à la

Afin d’optimiser ses performances, le serveur Oracle dispose de plusieurs zones s ayant chacune une tâche claire dans le fonctionnement du

Comme on a pu le voir précédemment, le processus utilisateur est un processus qui établie une connexion, ouvre une session avec une base de données Oracle. Par exemple, un utilisateur qui se connecte à l’instance de la base de données et ouvre ainsi une session pendant laquelle il pourra envoyer au moteur d’Oracle des commandes SQL. La session durera jusqu’à la fin de la connexion. Bref, La zone mémoire allouée pour le fonctionnement de chaque processus utilisateur au niveau du serveur s’appelle la zone mémoire du programme (PGA, Program Global Area).

La SGA (System Global Area)

La mémoire SGA (System Global Area) est une mémoire partagée par tous les rrière-plan.


Les composants obligatoires :

Zone de mémoire partagée (Shared Pool) Cache de tampons de la base de données (database buffer cache) Tampon de journalisation (redo log buffer)

5

entifiant appelé SID. Généralement, le SID porte le même nom que la base et

Une instance ne peut ouvrir qu’une seule base de données à la fois et dans la grande une base de données est ouverte par une seule instance.

des processus de l’instance, il existe des processus utilisateurs correspondant à l’application utilisée par l’utilisateur pour se connecter à la base de

s processus utilisateurs sont situés sur le poste de l’utilisateur et communiquent avec le serveur à travers le réseau grâce à la

Afin d’optimiser ses performances, le serveur Oracle dispose de plusieurs zones s ayant chacune une tâche claire dans le fonctionnement du

Comme on a pu le voir précédemment, le processus utilisateur est un processus qui établie une connexion, ouvre une session avec une base de données Oracle. Par

se connecte à l’instance de la base de données et ouvre ainsi une session pendant laquelle il pourra envoyer au moteur d’Oracle des commandes SQL. La session durera jusqu’à la fin de la connexion. Bref, La zone

aque processus utilisateur au niveau du serveur s’appelle la zone mémoire du programme (PGA, Program Global Area).

La mémoire SGA (System Global Area) est une mémoire partagée par tous les processus


Noreddine GHERABI

6

Les éléments facultatifs :

1. Zone de mémoire LARGE POOL 2. Zone de mémoire Java (Java Pool ) 3. Zone de mémoire streams (streams pool)

La SGA doit représenter au moins 2% de la taille totale de la base données (physique). Elle est répartie comme suit :

• 50% Cache de données (database buffer cache) • 40% Shared Pool • 10% Redo log Buffers + le reste

Paramétrer la taille SGA avec SGA_TARGET et SGA_MAX_SIZE.

Comment modifier la taille de la SGA Oracle ?.

La SGA ou System Global Area représente une zone mémoire d’une instance, c’est elle qui assure le partage des données entre les utilisateurs. Les données lues ou modifiées transitent par la SGA.

En 11G, nous avons la possibilité d'activer une fonctionnalité de réglage automatique de la mémoire partagée, c'est l'ASSM ou Automatic Shared Memory Management. Pour activer l'ASSM, il suffit d'affecter au paramètre SGA_TARGET une valeur supérieur à 0. Si SGA_TARGET = 0 alors les paramètres ci-dessous doivent être affectés. Si l'ASSM ( SGA_TARGET > 0 ) est activée, alors les valeurs suivantes seront dynamiquement gérées par Oracle.

• Database Buffer Cache - DB_CACHE_SIZE.

• Large Pool - LARGE_POOL_SIZE .

• Shared Pool - SHARED_POOL_SIZE.

• Java Pool - JAVA_POOL_SIZE .

Si vous attribuez une valeur aux paramètres gérées dynamiquement par Oracle, alors cette valeur sera la valeur minimale.

La valeur du paramètre SGA_MAX_SIZE contient la taille maximale de la SGA. La valeur du paramètre SGA_TARGET contient la taille souhaitée de la SGA. SGA_MAX_SIZE >= SGA_TARGET .

1.1.1 Zone de mémoire partagée (Shared Pool)

Noreddine GHERABI

7

La zone de mémoire partagée (Shared Pool) est constituée de deux structures mémoire liées aux performances :

1. Cache du dictionnaire de données (row cache) examiné ci-après. 2. Cache "library" examiné dans le second.

a) Cache du dictionnaire de données (row cache).

Lorsqu’un utilisateur soumet une requête SQL , le processus serveur extrait au cours de l’analyse de la requête, des informations stockées dans les tables du dictionnaire (données du compte utilisateur, noms des fichiers de données, noms des segments de tables et index, emplacements d'extents, descriptions des tables et privilèges utilisateur …).

Ces informations sont placées dans le cache du dictionnaire pour des besoins de réutilisation. Au cours des prochaines analyses parse, le processus serveur recherche les informations dans le cache du dictionnaire pour résoudre les noms d'objet et valider l'accès.

Noreddine GHERABI

La mise en mémoire cache des informations du dictionnatemps de réponse aux instructions LMD (SELECT, INSERT, UPDATE, DELETE). Une taille suffisante de ce cache contribue considérablement à l’amélioration des performances.

Si le cache du dictionnaire est de taille limitée, des appels rinterrogations effectuées directement dans le cache, seront opérés par le processus serveur sur le dictionnaire de la base de données (accès disque).

� Optimisation du cache du dictionnaire

SELECT sum(gets) "DC Gets",

sum(getmisses) "DC get Misses",

sum(getmisses) / (sum(gets)+sum(getmisses))*100 "R"

FROM v$rowcache ;

R doit être <= 10% ou 15% sinon accroitrerequête suivante :

alter system set SHARED_POOL_SIZE

b) Cache "library" (library cache)

La mise en mémoire cache des informations du dictionnaire de données réduit le temps de réponse aux instructions LMD (SELECT, INSERT, UPDATE, DELETE). Une taille suffisante de ce cache contribue considérablement à l’amélioration des

Si le cache du dictionnaire est de taille limitée, des appels récursifs plus lents que les interrogations effectuées directement dans le cache, seront opérés par le processus serveur sur le dictionnaire de la base de données (accès disque).

Optimisation du cache du dictionnaire

SELECT sum(gets) "DC Gets",

sum(getmisses) "DC get Misses",

sum(getmisses) / (sum(gets)+sum(getmisses))*100 "R"

R doit être <= 10% ou 15% sinon accroitre SHARED_POOL_SIZE

alter system set SHARED_POOL_SIZE=<taille M>;

"library" (library cache)

8

ire de données réduit le temps de réponse aux instructions LMD (SELECT, INSERT, UPDATE, DELETE). Une taille suffisante de ce cache contribue considérablement à l’amélioration des

écursifs plus lents que les interrogations effectuées directement dans le cache, seront opérés par le processus

SHARED_POOL_SIZE en utilisant la

Noreddine GHERABI

9

Le cache "library" conserve, à des fin de partage, des informations sur les commandes SQL et le code PL/SQL les plus récemment utilisées qui ont été soumis par des utilisateurs de la base de données.

Le chargement d'une instruction SQL consomme beaucoup de ressources, c’est pourquoi le cache « library » partagé est utilisé pour optimiser et ne charger une instruction SQL qu'une seule fois pour de multiples exécutions.

C'est le processus serveur associé à la session utilisateur qui exécute l'ordre SQL transmis par le processus utilisateur.

Pour le traitement de l’ordre SQL, un curseur est créé. Il pointe vers une zone mémoire SQL privée allouée dans la mémoire PGA

� Optimisation du cache de la librairie

SELECT sum(pins) "Executions",

sum(reloads) "Défaut de cache",

sum(reloads) / (sum(pins) + sum(reloads))*100 "R"

FROM v$librarycache ;

reloads : défaut de lecture dans le cache de librairie d'exécutions

pins : nombre d'exécutions sans défaut de cache

si R >= 1% alors augmenter SHARED_POOL_SIZE en utilisant la requête suivante :

alter system set SHARED_POOL_SIZE=<taille M>;

Noreddine GHERABI

1.1.2 Le database buffer cache

Il contient les blocs de données les plus récemment utilisés (blocs de tables, bloc d’index, bloc de segments d’annulation) avant de les inscrire dans la base de données. Ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently Used) pour gérer ce cache.

Les caractéristiques de database buffer sont

• Zone de chargement et de mise à jour en mémoire des

• blocs de données (blocs les plus récemment utilisés)des fichiers de données

En cas de manque de place, Oracle supprirécemment. Généralement, l’augmentation de sa taille améliore les performances du système. La taille du Database Buffer Cache est définie par la valeur du paramètre DB_BLOCK_BUFFERS.

Les performances sont bonnes

R= 1

Le database buffer cache

Il contient les blocs de données les plus récemment utilisés (blocs de tables, bloc d’index, bloc de segments d’annulation) avant de les inscrire dans la base de données. Ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently

database buffer sont :

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.

En cas de manque de place, Oracle supprime du cache les données utilisées le moins récemment. Généralement, l’augmentation de sa taille améliore les performances du système. La taille du Database Buffer Cache est définie par la valeur du paramètre

es performances sont bonnes si le ratio R est >= 60 ou 70%

Physical read = 1 - -------------------------------------

db block gets + consistent gets

10

Il contient les blocs de données les plus récemment utilisés (blocs de tables, bloc d’index, bloc de segments d’annulation) avant de les inscrire dans la base de données. Ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently

Ces blocs proviennent

me du cache les données utilisées le moins récemment. Généralement, l’augmentation de sa taille améliore les performances du système. La taille du Database Buffer Cache est définie par la valeur du paramètre

db block gets + consistent gets

Noreddine GHERABI

– Physical read : nombre de lecture sur disque

– db block gets + consistent gets : nombre total de

La table v$sysstat contient les statistiques utiles :

SELECT name, value

FROM v$sysstat

WHERE name IN ('db block gets', 'consistent gets', 'physical reads');

1.1.3 Le Buffer REDO LOG

Cette zone mémoire sert exclusivement à enregistrer toutes les modifications apportées sur les données de la base.

L’écriture dans le Redo Log Buffer est séquentielle (les modifications de plusieurs transactions se mélangent) et circulaire (quand le buff… après avoir été écrit sur disque dans les fichiers de Redo Log).

� Optimisation du buffer Redo log

la table des performances v$sysstat

– SELECT name, value FROM v$sysstat

WHERE name = 'redo log space requests' ;

name : nom de la statistique

value : valeur de la statistique

– interprétation :

Si value est très proche de 0 alors OK

Physical read : nombre de lecture sur disque

db block gets + consistent gets : nombre total de lecture sur disque ou en mémoire.

La table v$sysstat contient les statistiques utiles :

WHERE name IN ('db block gets', 'consistent gets', 'physical reads');

Le Buffer REDO LOG

Cette zone mémoire sert exclusivement à enregistrer toutes les modifications apportées sur les données de la base.

L’écriture dans le Redo Log Buffer est séquentielle (les modifications de plusieurs transactions se mélangent) et circulaire (quand le buffer est plein, il repart au début … après avoir été écrit sur disque dans les fichiers de Redo Log).

Optimisation du buffer Redo log

v$sysstat contient les information utiles

SELECT name, value FROM v$sysstat

'redo log space requests' ;

name : nom de la statistique

value : valeur de la statistique

Si value est très proche de 0 alors OK

11

lecture sur disque ou en mémoire.

Cette zone mémoire sert exclusivement à enregistrer toutes les modifications

L’écriture dans le Redo Log Buffer est séquentielle (les modifications de plusieurs er est plein, il repart au début

Noreddine GHERABI

Si value croit souvent alors il y a attente : augmenter

1.1.4 Large Pool

Le DBA peut configurer une zone de la SGA appeléBuffer de données ou la gourmandes en mémoire

• Que peut fournir la Large pool ? :

– L’ espace mémoire nécessaire pour les sessions gérés

– L’ espace mémoire pour les transactions XA (moniteur

– L’ espace mémoire pour effectuer les Backup et

– L’ espace mémoire pour le traitement des requêtes

• Dimensionnement de la Large POOL

>Alter system set Large_pool_size=<valeurM>

1.1.5 Java POOL

Zone de mémoire nécessaire pour la machine virtuelle

• Cette zone permet d’ exécuter le code Java stocké dans

• Dimensionnement de la Java POOL

>Alter system set java_pool_size

1.1.6 Reserved Area

C’est zone réservée, destinée à l’enregistrement d’objets SQL de grande taille.

Dimensionnée par le paramètre SHARED_POOL_RESERVED_SIZE

Pour dimensionner la taille de cette zone nous utilisons l’instruction

> sho parameter reserved

> alter system set shared_pool_reserved_size=10m scope=spfile;

Si value croit souvent alors il y a attente : augmenter LOG_BUFFER par palier de 5%

configurer une zone de la SGA appelé Large Pool pour soulager le Zone des requêtes partagés pour certaines opérations

• Que peut fournir la Large pool ? :

L’ espace mémoire nécessaire pour les sessions gérés par les serveurs partagés

L’ espace mémoire pour les transactions XA (moniteur transactionnel)

L’ espace mémoire pour effectuer les Backup et Restauration

L’ espace mémoire pour le traitement des requêtes parallèles

• Dimensionnement de la Large POOL

Large_pool_size=<valeurM> ;

Zone de mémoire nécessaire pour la machine virtuelle Java intégré dans Oracle

• Cette zone permet d’ exécuter le code Java stocké dans le noyau Oracle

• Dimensionnement de la Java POOL

java_pool_size =<valeurM> ;



Pour dimensionner la taille de cette zone nous utilisons l’instruction

alter system set shared_pool_reserved_size=10m scope=spfile;

12

LOG_BUFFER par palier de 5%

Large Pool pour soulager le Zone des requêtes partagés pour certaines opérations

les serveurs partagés

transactionnel)

Java intégré dans Oracle

le noyau Oracle



Pour dimensionner la taille de cette zone nous utilisons l’instruction alter system :

Noreddine GHERABI

13

> Startup force

1.1.7 Streams Pool

Cette zone est réservée notamment lors de la réplication de données entre bases de données distantes.

Cette zone est dimensionnée par le paramètre STREAMS_POOL_SIZE.

alter system set STREAMS_POOL_SIZE =<tialleM>;

1.2 La PGA (Program Global Area)

En dehors de la SGA, chaque processus serveur possède une zone de mémoire privée appelée PGA (Program Global Area).

La zone mémoire allouée pour le fonctionnement de chaque processus utilisateur au niveau du serveur

Lorsque le processus utilisateur se déconnecte (fin de session), le processus serveur associé prend fin et la mémoire PGA est libérée. Pour un processus serveur, la PGA contient :

� Des informations sur la session � Des informations sur le traitement des requêtes de la session � Les variables de session

Les tables v$sesstat, v$statname, permettent de déterminer la taille de la PGA pour une session

Select ss.sid, ss.value, sn.name FROM v$sesstat ss, v$statname sn, v$session se

WHERE ss.statistic#=sn.statistic# and sn.name in ('session pga memory')

and se.sid=ss.sid and type != 'BACKGROUND';

� Paramétrage de PGA

PGA devient dynamique et est configurée par le paramètre

PGA_AGGREGATE_TARGET.

� Affichage de paramètres PGA

Noreddine GHERABI

14

Select PARAMETER,OPER_TYPE,INITIAL_SIZE,TARGET_SIZE,FINAL_SIZE,STATUS

from V$MEMORY_RESIZE_OPS;

ou

Select COMPONENT,CURRENT_SIZE from V$MEMORY_DYNAMIC_COMPONENTS;

ou

Show parameter pga

� Configuration de PGA

alter system set pga_aggregate_target=100M;

1.3 Les processus autour d’Oracle

Deux classes de processus autour d’Oracle • Les processus utilisateurs (liés à l'exécution d'un outil, d'un programme d'application, ...) • Les processus Oracle • Les processus d’arrière plan (SMON, PMON, LGWR, DBWR, CKPT, ARCH, RECO, ...) • Les processus serveurs

• Autres processus

1.3.1 Les processus d’arrière plan

- SMON Le processus SMON (ou System Monitor) est un processus qui va servir à corriger les

plantages de l'instance et à vérifier la synchronisation des données. Si l'instance

plante, c'est SMON qui va se charger de rejouer le contenu des REDO LOG FILE afin

de pouvoir rejouer les transactions et de resynchroniser les données dans les fichiers

de données.

Voici les étapes de cette récupération :

• Etape 1 : SMON va automatiquement rejouer les transactions qui ont été enregistrées dans les fichiers REDO LOG FILE mais pas sur le disque dur. Le

Noreddine GHERABI

fait de rejouer les transactions contenues dans les fichiers REDO LOG FILE va permettre de valider les transactions qui avaient été validées mais qui n'avaient pas pu être enregistrée sur le disque.

• Etape 2 : SMON va ouvrir la binformations qui ne sont pas utilisées dans l'étape 1 et qui ont été validées sont alors disponibles immédiatement. Les autres restent verrouillées pour l'étape 3.

• Etape 3 : SMON se charge alors d'annuler topas été validés. Ce qui permettra d'avoir un état valide de la base de données.

SMON sert aussi à nettoyer les segments temporaires après leur utilisation. Il sert

aussi à défragmenter les fichiers de données, tables

En Oracle 8i, SMON afin de rejouer les transactions lisait de manière séquentielle les

fichiers REDO LOG FILE et rejouait toutes les transactions. Cette méthode était

fortement pénalisante lors du redémarrage après le crash.

En Oracle 9i (et plus), SMON va effectuer 2 lectures successive des fichiers REDO

LOG FILE. La première lecture va servir à identifier les blocs qui vont nécessiter une

restauration. La deuxième lecture servira à ne rejouer que les blocs identifiés. Cette

méthode est évidement moins coûteuse car le temps de lecture des fichiers REDO

LOG FILE est négligeable comparée à la répétition de toutes les transactions.

- PMON Le processus PMON (ou Process Monitor) va être surtout dédié aux processus des

utilisateurs. Il va servir à annuler les transactions d'une session (lors d'un plantage de

la session par exemple), mais aussi servir à relâcher tous les verrous posés par la

session, et à relâcher toutes les ressources détenues par la session.

fait de rejouer les transactions contenues dans les fichiers REDO LOG FILE va permettre de valider les transactions qui avaient été validées mais qui n'avaient pas pu être enregistrée sur le disque.

SMON va ouvrir la base de données pour les utilisateurs. Toutes les informations qui ne sont pas utilisées dans l'étape 1 et qui ont été validées sont alors disponibles immédiatement. Les autres restent verrouillées pour l'étape

SMON se charge alors d'annuler toutes les transactions qui n'avaient pas été validés. Ce qui permettra d'avoir un état valide de la base de données.


aussi à défragmenter les fichiers de données, tablespaces et autres.




, SMON va effectuer 2 lectures successive des fichiers REDO



t évidement moins coûteuse car le temps de lecture des fichiers REDO


Le processus PMON (ou Process Monitor) va être surtout dédié aux processus des

ir à annuler les transactions d'une session (lors d'un plantage de


session, et à relâcher toutes les ressources détenues par la session.

15

fait de rejouer les transactions contenues dans les fichiers REDO LOG FILE va permettre de valider les transactions qui avaient été validées mais qui

ase de données pour les utilisateurs. Toutes les informations qui ne sont pas utilisées dans l'étape 1 et qui ont été validées sont alors disponibles immédiatement. Les autres restent verrouillées pour l'étape

utes les transactions qui n'avaient pas été validés. Ce qui permettra d'avoir un état valide de la base de données.


paces et autres.




, SMON va effectuer 2 lectures successive des fichiers REDO



t évidement moins coûteuse car le temps de lecture des fichiers REDO


Le processus PMON (ou Process Monitor) va être surtout dédié aux processus des

ir à annuler les transactions d'une session (lors d'un plantage de


Noreddine GHERABI

16

Le processus Process Monitor PMON en action lors d'un échec d'un processus utilisateur.

• PMON annule la transaction (ROLL BACK) • PMON nettoie le cache de tampons de la base de données. • PMON 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.

Le processus Process Monitor PMON en action lors d'un fonctionnement normal de la base de données.

• PMON scrute et détecte les processus utilisateurs. • 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 etre appelé par d'autre Processus.

- DBWn Le processus DBWn (ou Database Writer) va être dédié à l'écriture du Database

Buffer Cache dans les fichiers de données de la base de données.

Le processus Database Writer (DBWn) a un rôle important dans le bon

fonctionnement d'une Instance, laquelle a principalement un processus Database

Writer nommé DBW0 (possibilité d'avoir plusieurs processus DBWn sur des

systèmes à forte activité et Multi-processeurs)

Ce processus est aussi là pour vérifier en permanence le nombre de blocs libres dans

le Database Buffer Cache afin de laisser assez de place de disponible pour l'écriture

des données dans le buffer.

DBWn se déclenchera lors des événements suivants :

• Lorsque le nombre de bloc dirty atteint une certaine limite • Lorsqu'un processus sera à la recherche de blocs libres dans le Database Buffer

Cache, et qu'il ne sera pas en mesure d'en trouver. • Lors de timeouts (environ toutes les 3 secondes par défaut) • Lors d'un checkpoint

- LGWR

Le processus LGWR (ou Log Writer) est le processus qui va écrire les informations

contenues dans le REDO LOG Buffer dans les fichiers REDOLOG FILE lors des

évenements suivant :

Noreddine GHERABI

• Quand une transaction est terminée avec un COMMIT• Quand le REDO LOG Buffer es

paramètres) • Quand il y a plus de 1Mo d'informations de log contenues dans le buffer• Avant que DBWn n'écrive le contenu du Database Buffer Cache dans les

fichiers du disque dur

- CKPT Ce processus va servir à met

jour les fichiers CONTROL FILE afin de spécifier que l'action de CHECKPOINT s'est

bien déroulée (par exemple lors d'un changement de groupe de REDO LOG FILES).

Le CHECKPOINT est un évènement qu

• D'un changement de groupe de REDO LOG FILE.• D'un arrêt normal de la base de données (c'est à dire sans l'option ABORT)• D'une demande explicite de l'administrateur• D'une limite définie par les paramètres d'initialisation

LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, et FAST_START_IO_TARGET

Checkpoint inscrit les informations de point de reprise dans les fichiers de Controles

et dans l'entête de chaque fichier de données. C'est ce point de reprise (

permet de rendre cohérent

indispensable pour un processus de récupération.

Les numéros SCN enregistrés dans les fichiers garantissent que toutes les

modifications apportées aux blocs de base de données avant un numéro

écrites sur le disque.

L'évènement CHECKPOINT va ensuite déclencher l'écriture d'un certain nombre de

blocs du Database Buffer Cache dans les fichiers de données par DBWn après que

LGWR ait fini de vider le REDO LOG Buffer. Le nombre de blocs écris par DBWn est

défini avec le paramètre FAST_START_IO_TARGET si celui

Quand une transaction est terminée avec un COMMIT Quand le REDO LOG Buffer est au 1/3 plein (peut dépendre de vos propres

Quand il y a plus de 1Mo d'informations de log contenues dans le bufferAvant que DBWn n'écrive le contenu du Database Buffer Cache dans les fichiers du disque dur

Ce processus va servir à mettre à jour les en-têtes des fichiers de données, et mettre à



Le CHECKPOINT est un évènement qui se déclencher lors :

D'un changement de groupe de REDO LOG FILE. D'un arrêt normal de la base de données (c'est à dire sans l'option ABORT)D'une demande explicite de l'administrateur D'une limite définie par les paramètres d'initialisation

NT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, et FAST_START_IO_TARGET

inscrit les informations de point de reprise dans les fichiers de Controles

et dans l'entête de chaque fichier de données. C'est ce point de reprise (

permet de rendre cohérent les fichiers de controles et les fichiers de données,

indispensable pour un processus de récupération.


modifications apportées aux blocs de base de données avant un numéro




ramètre FAST_START_IO_TARGET si celui-ci a été défini.

17

t au 1/3 plein (peut dépendre de vos propres

Quand il y a plus de 1Mo d'informations de log contenues dans le buffer Avant que DBWn n'écrive le contenu du Database Buffer Cache dans les

têtes des fichiers de données, et mettre à



D'un arrêt normal de la base de données (c'est à dire sans l'option ABORT)

NT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, et

inscrit les informations de point de reprise dans les fichiers de Controles

et dans l'entête de chaque fichier de données. C'est ce point de reprise (SCN) qui

les fichiers de controles et les fichiers de données,


modifications apportées aux blocs de base de données avant un numéro SCN ont été




ci a été défini.

Noreddine GHERABI

1.4 Comment arrêter et démarrer l'instance

Que ce soit sous Windows ou Linux/Unix la méthode est identique. La première

étape sera de définir la variable d'environnement ORACLE_SID.

Ensuite il va falloir se connecter à sqlplus en mode SYSDBA afin d'être en mesure de

lancer et démarrer l'instance.

sqlplus /nolog

connect / AS sysdba

Une fois connecté il ne restera plus qu'à démarrer l'instance avec la commande

startup.

Le démarrage d'une base de données complète se déroulera en plusieurs étapes

telles que NOMOUNT, MOUNT, OPEN.

Ces trois étapes sont obligatoires et devront être executées dans cet ordre.

Cependant la commande STARTUP permettra d'effectuer automatiquement ces 3

actions.

• NOUMOUNT : Cette étape va consister à lire le fichier init.ora, à démarrer l'instance, allouer la mémoire, et démarrer les processus d'arrière plan.

• MOUNT : Cette étape va consister à ouvrir le ou les fichiers CONTROLEFILE afin de mettre en mémoire lesCONTROLEFILE. Durant cette étape les fichiers de données ne sont pas accessible car ils n'ont pas encore été ouverts.

• OPEN : Cette étape va consister à ouvrir tous les fichiers de données enregistrés dans les fichiouverts et disponible, à ouvrir complètement la base de données aux utilisateurs.

Voici des exemples d'utilisation :

-- Démarrage de l'instanceSTARTUP NOMOUNT PFILE="<emplacement du init.ora>" -- Lecture des controles filesALTER DATABASE MOUNT; -- Ouverture de la base de donnéesALTER DATABASE OPEN;

Comment arrêter et démarrer l'instance


étape sera de définir la variable d'environnement ORACLE_SID.


lancer et démarrer l'instance.


'une base de données complète se déroulera en plusieurs étapes

telles que NOMOUNT, MOUNT, OPEN.



Cette étape va consister à lire le fichier init.ora, à démarrer l'instance, allouer la mémoire, et démarrer les processus d'arrière plan.

Cette étape va consister à ouvrir le ou les fichiers CONTROLEFILE afin de mettre en mémoire les informations contenues par les fichiers CONTROLEFILE. Durant cette étape les fichiers de données ne sont pas accessible car ils n'ont pas encore été ouverts.

Cette étape va consister à ouvrir tous les fichiers de données enregistrés dans les fichiers CONTROLEFILE. Puis une fois tous les fichiers ouverts et disponible, à ouvrir complètement la base de données aux

Voici des exemples d'utilisation :

Démarrage de l'instance "<emplacement du init.ora>"

des controles files

Ouverture de la base de données

18




'une base de données complète se déroulera en plusieurs étapes



Cette étape va consister à lire le fichier init.ora, à démarrer l'instance, allouer la mémoire, et démarrer les processus d'arrière plan.

Cette étape va consister à ouvrir le ou les fichiers CONTROLEFILE informations contenues par les fichiers

CONTROLEFILE. Durant cette étape les fichiers de données ne sont pas

Cette étape va consister à ouvrir tous les fichiers de données ers CONTROLEFILE. Puis une fois tous les fichiers

ouverts et disponible, à ouvrir complètement la base de données aux

Noreddine GHERABI

19

-- NOMOUNT et MOUNT automatique ALTER DATABASE MOUNT PFILE="<emplacement du init.or a>" -- Ouverture de la base de données ALTER DATABASE OPEN; -- -- -- Ouverture directe de la base de données sans spé cifier les 3 étapes STARTUP PFILE="<emplacement du init.ora>"

2- Base de données

2.1 Structure d’une Base de Données Oracle

2.1.1 Structure physiques d'une base Oracle

Les fichiers physiques d'une base Oracle permettent de stocker de manière persistante les données manipulées par Oracle, tandis que la mémoire sert à optimiser la vitesse de fonctionnement de la base de données.

On distingue généralement deux types de fichiers :

• Les fichiers servant à stocker les informations de la base. Tous ces fichiers sont des fichiers binaires, ce qui signifie qu'ils sont inexploitables avec un éditeur de texte.

• Les fichiers destinés à la configuration et au fonctionnement de la base Oracle

Oracle a défini une architecture permettant de définir une méthode d'organisation standard des fichiers de la base Oracle. Cette architecture est nommée OFA (Optimal Flexible Architecture).

Les fichiers d'une base de données Oracle sont les suivants :

• Les fichiers de données (dont l'extension est .dbf). Ces fichiers contiennent l'ensemble des données de la base (les tables, les vues, les procédures stockées, ...).

• Les fichiers Redo Log (dont l'extension est .rdo ou .log). Ces fichiers contiennent l'historique des modifications effectuées sur la base de données

• Les fichiers de contrôle (dont l'extension est .ctl). Ces fichiers permettent de stocker les informations sur l'état de la base de données (emplacement des fichiers, dates de création, ...)

Une base de données Oracle nécessite au minimum un fichier de données, deux fichiers redo

Log et un fichier de contrôle.

a) Les fichiers de données

Les fichiers de données sont les fichiers occupant la majeure partie de la base de données, leur taille peut osciller entre quelques Mégaoctets et plusieurs gigaoctets. Ceux-ci contiennent en effet toutes les données relatives à la base Oracle dans un

Noreddine GHERABI

20

format propriétaire. Ainsi pour modifier les informations contenues dans la base de données il est impossible d'intervenir directement sur ces fichiers; la bonne procédure à adopter consiste à modifier le contenu de la base de données par l'intermédiaire d'ordres SQL.

Les fichiers de données contiennent des informations de deux types :

• Le dictionnaire de données et de travail • Les données des utilisateurs

La lecture de ces fichiers de données est faite à l'aide des processus utilisateurs tandis que

l'écriture est assuré par le processus DBWR (Database Writer)

b) Les fichiers Redo-log

Les fichiers Redo-log contiennent l'historique des modifications apportées à la base de données Oracle. Ces fichiers de journalisation enregistrent les modifications successives de la base de données afin de pouvoir restaurer la base de données en cas de défaillance d'un disque dur. Ainsi le cas échéant, la base de données Oracle est à même de simuler l'ensemble des commandes n'ayant pas été sauvegardées pour rétablir le contenu de la base de données.

Au même titre que les fichiers de données, les fichiers Redo-log sont dans un format propriétaire Oracle et l'écriture dans ces fichiers est assurée par le processus LGWR (Log Writer).

Oracle propose également un mode archivage permettant la sauvegarde du fichier Redo-log avant sa réutilisation pour restaurer la base. Si ce mode n'a pas été activé, le contenu du fichier Redo Log est supprimé après utilisation.

Enfin ces fichiers peuvent être multiplexés (comprenez dupliqués dans des répertoires de groupe) afin de fournir un maximum de sécurité.

Configuration minimale

Utilisation en mode multiplexés (au moins deux groupes)

• Un groupe à au moins 2 fichiers qui sont identiques et mis à jour simultanément

Noreddine GHERABI

21

• il est conseillé de stocker chaque fichier d'un même groupe sur des disques différents

• il est conseillé d'avoir un même nombre de membres par groupe

� Ajout de fichiers REDO

� Ajout d'un groupe de fichiers

ALTER DATABASE [database ]

ADD LOGFILE

[ 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 ]

TO { GROUP integer

| ( 'filename'[REUSE] [,'filename']... )

Noreddine GHERABI

22

� Exemples

• ALTER DATABASE Fst

ADD LOGFILE GROUP 4 (' ‘/oracle/oradata/fst/disk1/log4adbcours.dbf')

size 500K;


ADD LOGFILE MEMBER ‘/oracle/oradata/fst/disk2/log4bdbcours.dbf'

TO GROUP 4;


ADD LOGFILE MEMBER

‘/oracle/oradata/fst/disk1/log4adbcours.dbf'

TO

‘/oracle/oradata/fst/disk3/log4cdbcours.dbf'

� Suppression de fichiers REDO

Le groupe concerné doit avoir au moins 2 membres pour pouvoir en supprimer un (il doit en rester au moins un). Un membre du groupe courant (celui dans lequel LGWR est en train d’écrire) ne peut pas être supprimé. En mode ARCHIVELOG, un membre d’un groupe pas encore archivé ne peut pas être supprimé. Les fichiers concernés ne sont pas physiquement supprimés par Oracle.

Pour supprimer tous les membres d’un groupe il faut supprimer le groupe.


DROP LOGFILE

{ GROUP integer

| ('filename'[,'filename']...)

| 'filename'}

Noreddine GHERABI

23

DROP LOGFILE MEMBER

'filename'[,'filename']...

� Forcer le basculement du groupe courant

Le basculement d’un groupe courant peut être utilisé lorsque l’on a besoin d’effectuer une suppression de groupe ou lorsque l’on veut générer une archive avant d’effectuer une sauvegarde (la base de données doit alors être en ARCHIVELOG). Utiliser l’ordre SQL ALTER SYSTEM :

ALTER SYSTEM SWITCH LOGFILE ;

Si les SWITCH sont trop fréquents, ce n’est pas bon pour les performances. La vue V$LOG_HISTORY peut être utilisée pour analyser la fréquence de SWITCH des fichiers de Redo Log (colonne FIRST_TIME). Le basculement manuel provoque les mêmes évènements qu’un basculement automatique

- Checkpoint : point de reprise

- Archivage (si l’archivage est activé)

� Trouver des informations sur les fichiers Redo Log

Plusieurs vues du dictionnaire permettent d’obtenir des informations sur les fichiers de redo log : _ V$LOG : informations sur les groupes _ V$LOGFILE : informations sur les membres _ V$LOG_HISTORY : informations sur l’historique des fichiers de redo log _ V$INSTANCE__RECOVERY : informations sur les temps estimés de restauration d’instance.

Noreddine GHERABI

24

Noreddine GHERABI

25

c) Les fichiers de contrôle

Les fichiers de contrôle permettent de stocker l'état de la base de données. Ils sont créés lors de la création de la base.

Ces fichiers permettent, lors de l'initialisation de la base, de savoir si la base de données a été arrêtée correctement, ainsi que de connaître l'emplacement des fichiers de données et des fichiers Redo Log. Les fichiers de contrôle sont eux-même repérés par le fichier d'initialisation.

Le fichier de contrôle contient les informations suivantes :

• Nom de la base de données • Date et heure de création de la base • L'emplacement des fichiers journaux (Redo-Log) • Des informations de synchronisation

Ajout de copies supplémentaires de fichiers de contrôles

1. Arrêter la base et sortir du logiciel d'Administration (Sqlplus) 2. Dupliquer sous l'OS le fichier de contrôle 3. Relancer le logiciel d'administration et redémarrer la base.

Backup d'un fichier de contrôle Sauvegarde en dupliquant un fichier de contrôle

ALTER DATABASE BACKUP CONTROLFILE TO ‘chemin/ file.dbf’;

Sauvegarde sous forme de requête SQL dans le fichier de trace (ora_xxx.trc)

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

d) Le fichier d'initialisation

Ce fichier est un fichier au format texte contenant l'ensemble des paramètres de démarrage de la base (il est généralement nommé initSID.ora, où SID représente le nom donné à l'instance). Son existence n'est toutefois pas majeure car il peut être facilement reconstruit.

Un fichier d'initialisation par défaut est créé lors de la création d'une base. Celui-ci est largement documenté et des exemples de valeurs sont donnés pour chaque paramètre. Toutefois parmi ces paramètres, seul un nombre limité d'entre-eux est réellement utile.

DBA- Partie I

Documents

Transcript of DBA- Partie I