Vous êtes sur la page 1sur 25

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

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

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

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

3
3

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 :

La base de données est l’ensemble des fichiers qui permettent de gérer les données de la

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

4
4

un identifiant appelé SID.

Généralement, le SID porte le même n om que la base et

l’instance. Une instance ne peut ouvri r qu’une seule base de données à la fois et dans la grande majorité des cas, une base d e données est ouverte par une seule inst ance. En dehors des processu s de l’instance, il existe des proce ssus utilisateurs correspondant à l’applicati on utilisée par l’utilisateur pour se conn ecter à la base de données (SQL*Plus, un pro giciel, un logiciel spécifique, …).

Dans une architecture clie nt/serveur, ces processus utilisateurs

sont situés sur le

poste de l’utilisateur et co mmuniquent avec le serveur à travers le réseau grâce à la couche Oracle Net.

Le PGA

Afin d’optimiser ses perfo rmances, le serveur Oracle dispose de

plusieurs zones

mémoires différentes ayan t chacune une tâche claire dans le fo nctionnement du

serveur. Comme on a pu le voir pr écédemment, le processus utilisateur est un processus qui établie une connexion, ou vre une session avec une base de don nées Oracle. Par

exemple, un utilisateur qu i se connecte à l’instance de la base de

données et ouvre

ainsi une session pendan t laquelle il pourra envoyer au mot eur d’Oracle des commandes SQL. La sessi on durera jusqu’à la fin de la connexi on. Bref, La zone mémoire allouée pour le f onctionnement de chaque processus util isateur au niveau du serveur s’appelle la zon e mémoire du programme (PGA, Progra m Global Area).

  • 1.1 La SGA (System Gl obal Area)

La mémoire SGA (System Gl obal Area) est une mémoire partagée par tous les processus serveur et les processus en arr ière-plan.

un identifiant appelé SID. Généralement, le SID porte le même n om que la base et

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

Les composants obligatoires :

  • 1. Zone de mémoire part agée (Shared Pool)

  • 2. Cache de tampons de l a base de données (database buffer cache)

  • 3. Tampon de journalisat ion (redo log buffer)

Noreddine GHERABI

5
5

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

6
6

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.

La zone de mémoire partagée (Shared Pool) est constituée de deux structures mémoire liées aux performances
  • 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

7
7
La mise en mémoire cach e des informations du dictionnaire de données réduit le temps de
La mise en mémoire cach e des informations du dictionnaire de données réduit le temps de

La mise en mémoire cach e des informations du dictionnaire de

données réduit le

temps de réponse aux instr uctions LMD (SELECT, INSERT, UPDAT E, DELETE). Une taille suffisante de ce c ache contribue considérablement à l’ amélioration des performances.

Si le cache du dictionnaire est de taille limitée, des appels récursifs plus lents que les

interrogations effectuées d irectement dans le cache, seront opérés

serveur sur le dictionnaire

de la base de données (accès disque).

par le processus

Optimisation du c ache du dictionnaire

SELECT sum(gets) "DC Ge ts",

sum(getmisses) "DC get Mi sses",

sum(getmisses) / (sum(get s)+sum(getmisses))*100 "R"

FROM v$rowcache ;

R doit être <= 10% ou 15 % sinon accroitre SHARED_POOL_SIZ E en utilisant la requête suivante :

alter system set SHARED_ POOL_SIZE=<taille M>;

  • b) Cache "li brary" (library cache)

Noreddine GHERABI

8
8

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

9
9
1.1.2 Le database buf fer cache Il contient les blocs de do nnées les plus récemment
1.1.2 Le database buf fer cache Il contient les blocs de do nnées les plus récemment
  • 1.1.2 Le database buf fer cache

Il contient les blocs de do nnées les plus récemment utilisés (blo cs de tables, bloc

d’index, bloc de segment s d’annulation) avant de les inscrire

dans la base de

données. Ayant une taille Used) pour gérer ce cache.

finie, Oracle utilise un algorithme LR U (Least Recently

Les caractéristiques de data

base buffer sont :

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

blocs de données (b locs les plus récemment utilisés), Ces des fichiers de donn ées.

blocs proviennent

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 Data base Buffer Cache est définie par la val eur du paramètre DB_BLOCK_BUFFERS.

Les performances sont bon nes si le ratio R est >= 60 ou 70%

R= 1 -

Physical read -------------------------------------

db block gets + consistent get s

Noreddine GHERABI

10
10

– 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 l es statistiques utiles :

SELECT name, value

FROM v$sysstat

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

  • 1.1.3 Le Buffer RED O LOG

Cette zone mémoire sert

exclusivement

à

enregistrer

toutes

apportées sur les données d e la base.

les

modifications

L’écriture dans le Redo L og Buffer est séquentielle (les modificat ions de plusieurs

transactions se mélangent) … après avoir été écrit sur

et circulaire (quand le buffer est plein, disque dans les fichiers de Redo Log).

il repart au début

– Physical read : nombre de lecture sur disque – db block gets + consistent gets

Optimisation du b uffer Redo log

la table des performances v $sysstat contient les information utiles

– SELECT name, value FRO M v$sysstat

WHERE name = 'redo log s pace requests' ;

name : nom de la statistiqu e

value : valeur de la statistiq ue

– interprétation :

Si value est très proche de 0

alors OK

Noreddine GHERABI

11
11

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

  • 1.1.4 Large Pool

Le DBA peut configurer u ne zone de la SGA appelé Large Pool

pour soulager le

Buffer de données ou la gourmandes en mémoire

Zone des requêtes partagés pour cer taines opérations

• Que peut fournir la Large

pool ? :

– L’ espace mémoire nécess aire pour les sessions gérés par les serve urs partagés

– L’ espace mémoire pour l es transactions XA (moniteur transaction nel)

– L’ espace mémoire pour e ffectuer les Backup et Restauration

– L’ espace mémoire pour l e traitement des requêtes parallèles

• Dimensionnement de la L arge POOL

>Alter system set Large_ pool_size=<valeurM> ;

  • 1.1.5 Java POOL

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

• Cette zone permet d’ exéc uter le code Java stocké dans le noyau O racle

• Dimensionnement de la J ava POOL

>Alter system set java_p ool_size =<valeurM> ;

  • 1.1.6 Reserved Area

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

Dimensionnée par le para mètre SHARED_POOL_RESERVED_SI ZE

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

Pour dimensionner la tail le de cette zone nous utilisons l’instructi on alter system :

> sho parameter reserved

> alter system set shared_p ool_reserved_size=10m scope=spfile;

Noreddine GHERABI

12
12
> Startup force
> 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

13
13

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

14
14

fait de rejouer les tra nsactions contenues dans les fichiers RE DO 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 o uvrir la base de données pour les utilisa teurs. Toutes les

informations qui ne sont pas utilisées dans l'étape 1 et qui on t été validées sont alors disponibles im médiatement. Les autres restent verrouil lées pour l'étape

3.

Etape 3 : SMON se c harge alors d'annuler toutes les transacti ons qui n'avaient

pas été validés. Ce q ui permettra d'avoir un état valide de la

base de données.

fait de rejouer les tra nsactions contenues dans les fichiers RE DO LOG FILE va permettre

SMON sert aussi à nettoy er les segments temporaires après leur

utilisation. Il sert

aussi à défragmenter

les

fichiers

de

données,

tablesp aces

et

autres.

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

fichiers REDO LOG FILE fortement pénalisante

et rejouait toutes les transactions. Ce tte méthode était

lors

du

redémarrage

aprè s

le

crash.

En Oracle 9i (et plus), SM ON va effectuer 2 lectures successive d es fichiers REDO LOG FILE. La première lec ture va servir à identifier les blocs qui v ont nécessiter une restauration. La deuxième lecture servira à ne rejouer que les bloc s identifiés. Cette méthode est évidement m oins coûteuse car le temps de lecture d es fichiers REDO LOG FILE est négligeable c omparée à la répétition de toutes les tran sactions.

-

PMON

Le processus PMON (ou P rocess Monitor) va être surtout dédié a ux processus des

utilisateurs. Il va servir à an nuler les transactions d'une session (lors

d'un plantage de

la session par exemple), m ais aussi servir à relâcher tous les ver rous posés par la

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

Noreddine GHERABI

15
15

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

16
16

Quand une transacti on est terminée avec un COMMIT

Quand une transacti on est terminée avec un COMMIT

Quand le REDO LO G Buffer est au 1/3 plein (peut dépendre de vos propres

paramètres) Quand il y a plus de 1Mo d'informations de log contenues da ns le buffer

Avant que DBWn n' écrive le contenu du Database Buffer Cac he dans les

fichiers du disque d ur

-

CKPT

Ce processus va servir à me ttre à jour les en-têtes des fichiers de do nnées, et mettre à jour les fichiers CONTROL FILE afin de spécifier que l'action de CH ECKPOINT s'est bien déroulée (par exemple lors d'un changement de groupe de RED O LOG FILES).

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 d e la base de données (c'est à dire sans l'op tion ABORT)

D'une demande expl icite de l'administrateur

D'une limite définie par les paramètres d'initialisation

LOG_CHECKPOIN T_INTERVAL, LOG_CHECKPOINT_TIM FAST_START_IO_T ARGET

EOUT, et

Checkpoint inscrit les info rmations de point de reprise dans les fic hiers de Controles

et dans l'entête de chaque

fichier de données. C'est ce point de r eprise (SCN) qui

permet de rendre cohére nt les fichiers de controles et les fich iers de données,

indispensable pour un proc essus de récupération. Les numéros SCN enre gistrés dans les fichiers garantissent

que

toutes

les

modifications apportées au x blocs de base de données avant un nu méro SCN ont été écrites sur le disque. L'évènement CHECKPOIN T va ensuite déclencher l'écriture d'un c ertain nombre de

blocs du Database Buffer

Cache dans les fichiers de données par

DBWn après que

LGWR ait fini de vider le R EDO LOG Buffer. Le nombre de blocs éc ris par DBWn est

défini avec le paramètre FA ST_START_IO_TARGET si celui-ci a été défini.

Noreddine GHERABI

17
17
1.4 Comment arrêter e t démarrer l'instance Que ce soit sous Window s ou Linux/Unix la
  • 1.4 Comment arrêter e t démarrer l'instance

Que ce soit sous Window s ou Linux/Unix la méthode est identi que. La première

étape sera de définir la vari able d'environnement ORACLE_SID. Ensuite il va falloir se conn ecter à sqlplus en mode SYSDBA afin d' être en mesure de lancer et démarrer l'instanc e. sqlplus /nolog connect / AS sysdba Une fois connecté il ne r estera plus qu'à démarrer l'instance av ec la commande startup.

Le démarrage d'une base

de données complète se déroulera en

telles que NOMOUNT, MO UNT, OPEN. Ces trois étapes sont o bligatoires et devront être executées

plusieurs étapes

dans cet ordre.

Cependant la commande actions.

STARTUP permettra d'effectuer autom atiquement ces 3

NOUMOUNT : Cet te étape va consister à lire le fichier ini t.ora, à démarrer l'instance, allouer la mémoire, et démarrer les processus d'arr ière plan.

MOUNT : Cette éta pe va consister à ouvrir le ou les fichiers CONTROLEFILE

afin de mettre en

mémoire

les

informations

contenues

par les fichiers

CONTROLEFILE. D urant cette étape les fichiers de don nées ne sont pas accessible car ils n'o nt pas encore été ouverts. OPEN : Cette étap e va consister à ouvrir tous les fich iers de données

enregistrés dans les

fichiers CONTROLEFILE. Puis une foi s tous les fichiers

ouverts et disponi ble, à ouvrir complètement la base utilisateurs.

de données aux

Voici des exemples d'utilisa tion :

-- Démarrage de l'instan ce STARTUP NOMOUNT PFILE="< emplacement du init.ora>"

-- Lecture des controles files ALTER DATABASE MOUNT;

-- Ouverture de la base de données ALTER DATABASE OPEN;

Noreddine GHERABI

18
18

-- NOMOUNT et MOUNT automatique ALTER DATABASE MOUNT PFILE="<emplacement du init.ora>"

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

19
19

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

format propriétaire. Ainsi pour modifier les informations contenues dans la base de données il est impossible

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

20
20

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

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

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

ALTER DATABASE [database ]

| ADD LOGFILE MEMBER

'filename' [ REUSE ]

TO { GROUP integer

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

...

)

Noreddine GHERABI

21
21

Exemples

• ALTER DATABASE Fst

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

size 500K;

• ALTER DATABASE Fst

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

TO GROUP 4;

• ALTER DATABASE Fst

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.

ALTER DATABASE [database ]

DROP LOGFILE

{ GROUP integer

| ('filename'[,'filename']

...

)

| 'filename'}

Noreddine GHERABI

22
22

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 d’instance.

__

RECOVERY

: informations sur les temps estimés de restauration

Noreddine GHERABI

23
23
Noreddine GHERABI 24
Noreddine GHERABI 24

Noreddine GHERABI

24
24
  • 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.

Noreddine GHERABI

25
25