ORACLE






  


ORACLE


Introduction :

 

Oracle est devenu actuellement l’un des serveurs de bases de données les plus populaires, il est utilisé de plus en plus par les organismes (grands comptes) qui veulent gérer efficacement un très grand volume de données (Oracle peut gérer des téra-octes de données). La liste des référence Oracle est très riche dans ce sens, même au maroc.

Après l’apparition de la version NT, et la redéfinition des prix, les PME/PMI ont eux aussi commencé à s’intéressé à Oracle.

 

Le serveur de données Oracle, s’il est bien administré, garantie la cohérence, l’intégrité, la sécurité et la disponibilité des données. Il donne aussi une grande souplesse pour l’administrateur pour améliorer les performances et garantir un bon temps de réponse pour les applications qui sont développé autour d’oracle.

 

Je peut dire aussi que la force d’oracle vient principalement de :

1-     Oracle est très bien paramétré, le DBA expérimenté peut agir sur tout les aspects d’oracle ( mémoire, temps cpu, accès disque, ….) pour avoir les meilleurs temps de réponse.

2-     Sa disponibilité et portabilité sur une centaines de plate-forme.

3-     Le serveur Oracle dispose d’un très grand nombre d’outils qui tournent autour de lui :

a.      Développement : oracle Developper, Oracle objects for OLE, …

b.      Atelier de génie logiciel : oracle designe.

c.      Outils de datawarehouse : oracle express, oracle discoverer, …

d.      Outils d’administration : oracle entreprise manager, …

e.      Erp : Oracle application

f.        ……….

Mais Oracle, malheureusement, a aussi ses inconvénients. Le principale c’est le manque de documentation. De plus il faut vraiment beaucoup de temps d’apprentissage pour pouvoir maîtriser tous les aspects d’oracle.

 

Je ne suis pas entrain de faire de la pub pour oracle J, mais j’essaie seulement de vous mettre en bain.

 

En ce qui concerne ma présentation du DBA d’oracle, et puisque c’est un thème très riche, j’essaierai de faire ça sous forme de chroniques  comme l’a proposé notre grand amine.

 

Dans chaque chronique, j’essaierai d’aborder un thème bien précis.

 

Je ne prétend pas être exhaustif, mais a la fin de ces chroniques, j’aurai présenté l’essentiel de ce que un DBA peut faire.



 

Plan

 

Dans ce premier document, j’essaierai de présenter ce que un DBA doit faire. J’essaierai ensuite de présenter l’architecture général d’oracle.

 

Travail d’un DBA

 

Un DBA, comme a était définit par Oracle est la (ou les) personne qui doit :

 

1-     Installer le serveur Oracle ainsi que les applications qui tourne autour, que se soit au poste serveur ou au postes clients.

2-     Créer les structures de stockage, ainsi que les objets primaires indispensable pour q’une base de donnée (ou instance dans le dictionnaire d’oracle) puisse tourner.

3-     Allouer l’espace de stockage requis par le système et planifier les futurs besoins en terme d’espace de stockage.

4-     Gérer les structures de la BD

5-     Créer et gérer les utilisateurs

6-     Contrôler et surveiller l’accès de ces utilisateurs au ressources de la base

7-     assurer la sauvegarde-restauration de la base

8-     maintenir la sécurité du système

9-     surveiller et optimiser les performances de la base.

 

Architecture générale d’Oracle

 

 

processes

 

 

 

 

 

 

 

 

Structures mémoire

Snnn

SMON

PMON

CKPT

ARCH

Dnnn

Pnnn

RECO

LCKLM

SNPn

LGWR

DBWR

Fichiers

 Fichiers de

Contrôle

 Fichiers de

Données

 Fichiers

Redo Log

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 


Comme vous venez de le voir dans la figure, un instance oracle comprend trois composants :

 


 

1-     les structures mémoire : elle est appelé SGA  ou Shared Global Area. Cette zone mémoire est allouée par oracle lorsque le serveur est démarré. Cette zone comprend un ensemble de structures de mémoire partagées par tous les utilisateurs. Elle comprend les données des utilisateurs ainsi que les informations de contrôle utilisées par le système.

2-     Les processes : c’est un ensemble de processes système qui veille au bon déroulement du système. Il sont appelées background processes , quatre parmi eux sont indispensables (ceux qui sont en rouge), si un d’eux échoue, l’instance échoue aussi. Les autres sont optionnels. Chaque un de ces processes a une fonction bien déterminée dans le système.

3-     Les fichiers : ils sont de trois types :

a.       Fichiers de contrôle : ils englobent tous les informations sur le système. Ils sont nécessaire pour le démarrage de l’instance. Tous ces fichiers sont identiques et contient les même informations. Il sont dupliqués pour des raisons de sécurité, si un fichier est perdu, les autres sont utilisés.

b.      Fichiers de données : ces eux qui contient les données des utilisateurs, ainsi que le dictionnaire de données.

c.       Fichiers redo log : Ils contient les informations pour pouvoir restaurer le système en car de crash ou d’erreur fatale.

 

Maintenant , on va voir de façon détaillée les deux premiers composants d’une instance (SGA et Process).

 

1-      la SGA

 

Database Buffer

Cache

Shared Pool

SSA

Redo Log Buffer

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Elle est composée de 3 parties :

1-     la Shared pool :

cette dernière est, elle même, composée de 2 parties :

 

a-      la Shared Sql Area (SSA) : c’est le cache des requêtes SQL et PL/SQL exécutées par les utilisateurs connectés. Chaque entrée dans cette cache contient le texte d’une requête, sa forme analysée et son plan d’exécution.

Cette zone est partagée par tous les utilisateurs, si deux utilisateurs X et Y exécutent la même requête, alors ils vont partager le même plan d’exécution, de même, si un utilisateur lance une requête et que cette requête existe déjà dans le cache, alors, oracle utilise le plan d’exécution trouvé dans le cache.

Une question, comment oracle fait pour savoir que deux requêtes sont identiques ou qu’une requête existe dans le cache ?

Réponse : Pour pouvoir placer une requête dans cette zone partagée, oracle utilise un algorithme de hashing spécial. Ainsi, oracle garantis que seules les requêtes identiques sont placés dans la même entrée.

Deux requêtes sont considérées comme identiques si et seulement si :

-         ils ont le même texte : les deux textes de ces requête doivent être TOTALEMENT identiques, si on remplace un blanc par 2 blancs ou un caractère minuscule par un majuscule, les deux textes deviennent non identiques.

-         Ils ont les mêmes objets référencés.

-         Les nom et les types des variables sont identiques.

 

Pour tirer profit de cette cache, Il vaut mieux utiliser les requêtes paramétrés lors du développement d’applications avec SQL, PL/SQL. Cela permet de gagner le temps de génération du plan d’exécution.

       

b-     la Data Dictionnary Cache : c’est le cache du dictionnaire de données, il contient les informations sur tous les données contenu dans la base. ( tables, indexes, vues, privilèges …).

2-     le Database Buffer Cache : ou le cache des données, il contient les copies des bloques de données enregistrés dans le disque. Chaque fois qu’une requête a besoin de données, et que ces derniers ne sont pas chargés, alors oracle les charge dans la mémoire pour pouvoir les utiliser.

Il faut noter que les données du disque ne peuvent pas être chargées tous dans la mémoire, pour gérer ça, Oracle utilise un algorithme de Least Recently Used ( les blocs les moins utilisés ), Lorsque oracle ne trouve pas de blocks libre dans la mémoire.

( cet algorithme sera détaillé lorsqu’on parlera du processus d’exécution des requête au niveau d’oracle).

3-     le RedoLog Buffer : c’est un tampon circulaire qui garde trace des changements qui ont était opérés sur la base, ainsi, lorsqu’un incident se produit, la restauration de l’état de la base avant l’incident va être possible. En fait, lorsqu’un utilisateur effectue un changement sur la base ( update, insert, …), les informations nécessaires ( l’image des données originale, et l’image après changement, …) sont gardés dans ce buffer.

Lorsqu’un utilisateur valide sa transaction (commit), ce buffer est enregistré sur disque.

 

On a ainsi donné une idée sur cette fameuse SGA d’oracle. Il faut signalé que la taille de cette zone mémoire est paramétrable.

Pour se faire, il suffit de modifier les trois paramètres SHARED_POOL_SIZE, DB_BLOCK_BUFFERS, DB_BLOCK_SIZE et LOG_BUFFER dans le fichier d’initialisation de l’instance initSID.ORA ( SID étant l’identificateur unique de l’instance, si votre instance s’appelle ORCL, le fichier d’initialisation de cette dernière sera initORCL.ora).

 

Voici une ptite description  de ces paramètres :

 

DB_BLOCK_SIZE : c’est la taille du block oracle qui est un multiple des bloques de l’OS, si par exemple la taille du block OS est 1K, et que DB_BLOCK_SIZE = 3, alors la taille du block oracle sera 3K.

DB_BLOCK_BUFFERS : c’est la taille de la Database Buffers en blocks oracle, ainsi, si DB_BLOCK_BUFFERS = 1000, alors la Database Buffers contiendra 1000 blocks oracle.

LOG_BUFFER : c’est la taille de la RedoLog Buffer en blocks oracle.

 

Pour redimensionner la SGA, il faut ouvrir le fichier d’initialisation de l’instance, donner les valeurs désirés a ces paramètres, arrêter l’instance, puis la redémarrer. Si vous n’arrêtez pas l’instance et la redémarrer, ces paramètres ne seront pas pris en compte.

 

Le paramètre DB_BLOCK_SIZE est pris en compte, SEULEMENT, lors de la création de l’instance. Si vous le changer, il ne sera pas pris en compte ultérieurement, il faut donc supprimer l’instance et la recréer pour le prendre en considération ( eh oui ).

 

2- Les processes

 

Maintenant il est temps pour parler un ptit peut des processes détachés, voici la liste de ces processes avec une bref description :

 

-         PMON :  c’est le process monitor, c’est lu qui surveille les connexions des utilisateurs, si une connections est terminée avec erreur alors il libère les ressources détenus par cette connexion, il annule les transactions qui sont terminés d’une manière anormale ( sont être commités ou rollbackés), … .

-         SMON : c’est system monitor, il fait la restauration automatique de l’instance lors du démarrage, il libère l’espace alloué pour les segments temporaires, il fusionne l’espace disque dans les fichiers de données, … .

-         DBWR : c’est le database writer, sont travaille est d’écrire périodiquement sur disque, les blocks qui ont était modifiés dans le database buffers.

-         LGWR : c’est le redolog writer, son rôle est d‘écrire périodiquement sur disque le tampon des redolog buffer.

-         CKPT : c’est un process qui est activé lors d’un checkpoint ou point de synchronisation (si le paramètre CHECKPOINT_PROCESS est mis a TRUE dans le fichier d’initialisation). cet évènement sera discuté lorsqu’on va parler de la gestion de concurrence chez oracle, mais brièvement, lorsqu’un checkpoint est sollicité, le redolog buffers et le database buffer sont écrits sur disque, il faut noter que lorsqu’un utilisateur valide une transaction (commit), seul le redolog buffer est écrit sur disque, l’écriture du db buffer sur disque est différée pour optimiser les E/S sur disque.

-         ARCH : c’est le process ARCHIVER, il archive les fichiers redolog. Ainsi, si on perd l’instance, on peut la récupérer son état lorsqu’elle est perdu depuis une sauvegarde antérieur, il suffit de restaurer cette sauvegarde, puis appliquer les fichiers de redolog archivés sur cette sauvegarde.

Il y a d’autres process mais qui ne sont pas très importants et qui sont en option comme. Le RECO, qui permet de résoudre les erreurs lors des transactions distribués (dans le cas des BD distribués), le LCKn ( qui permettent de gérer le verrouillage lorsqu’on  a l’option parallele server, c’est a dire avoir plusieurs instances qui tourne sur la même base), le SNPn ( qui permettent de rafraîchir les snapshots ou clichés, un snapshot en fait c’est comme une vue mais qui a une existence physique, les snapshots sont rafraîchit périodiquement), Pnnn ( qui permettent le parallélisme des requêtes) …. .

 

Bon jusqu'à maintenant on a parlé des process systèmes qui veille au bon déroulement de l’instance. Maintenant, il est temps de parler sur les process utilisateurs et les processes serveurs.

 

Lorsque vous lancé un programme qui accède à la base de donnée ( sqlplus, oracle forms, …), un process utilisateur est démarré. En contrepartie, un process serveur dédié a ce dernier est lancé dans le serveur de base de données, il ya autant de process serveurs dans la base que de process utilisateurs connecté. Le process utilisateur transmet le texte des requêtes SQL et PL/SQL sollicités par le client a son process serveur dédié et reçoit le résultat de l’exécution.

 

Le process serveur lorsqu’il reçoit la requête, il utilise les ressources systèmes ( SGA, processes systèmes) pour l’exécuter, c’est lui qui analyse et exécute les requêtes, lit les blocks depuis le disque vers la mémoire, et renvoie les résultats a l’utilisateur.

 

Chaque process serveur a sa propre mémoire qui s’appelle PGA (et qui n’est pas partagée), cette dernière est composée de deux partie :

-         Le stack space : ou il stocke les variables, les tableaux, … .

-         Les données de session : c’est les données relative a la session utilisateur (numéro de session, host du client, programme détenteur du process utilisateur, ….) .

 

Voilà,  c’était un ptit résumé de l’architecture d’oracle.