Module 1 DBA 1 9i

Grer une instance
1Z0-031
Module n1
Auteur : Mathieu Musard

Grer une instance d septembre yyyy Nombre de pages : 38
Ecole Suprieure dInformatique de Paris 23. rue Chteau Landon 75010 PARIS
www.supinfo.com
Grer une instance
2 / 38
Table des matires

1.COMPOSANTS DE LARCHITECTURE ORACLE......................................................................................4 1.1. INTRODUCTION AU SERVEUR ORACLE........................................................................................................................ 4 1.1.1.Tches de ladministrateur de base de donnes...........................................................................................4 1.2. CONNEXION A UN SERVEUR ORACLE......................................................................................................................... 4 1.2.1.Processus utilisateur.....................................................................................................................................5 1.2.2.Processus serveur......................................................................................................................................... 5 1.3. INSTANCE ORACLE ET BASE DE DONNES.................................................................................................................. 6 1.3.1.System Global Area (SGA)........................................................................................................................... 6 1.3.2.SGA dynamique............................................................................................................................................ 7 1.3.3.Processus d'arrire plan...............................................................................................................................7 1.3.4.Fichiers de la base de donnes.....................................................................................................................8 1.3.5.Fichiers relatant la Base de donnes........................................................................................................ 8 1.4. TRAITEMENT DE REQUTES...................................................................................................................................... 9 1.4.1.Etapes lors du traitement d'une requte....................................................................................................... 9 1.4.2.Pool partag (Shared Pool)..........................................................................................................................9 1.4.3.Buffer de Cache de la base de donnes (Database Buffer Cache).............................................................10 1.4.4.Buffer de Redo Log.....................................................................................................................................10 1.4.5.Program Global Area (PGA)..................................................................................................................... 10 1.5. TRAITEMENT DE REQUTES DML.......................................................................................................................... 11 1.5.1.Phases d'excution d'un requte DML....................................................................................................... 11 1.5.2.Segments de Rollback................................................................................................................................. 12 1.5.3.Database Writer (DBWn)........................................................................................................................... 12 1.5.4.Log Writer (LGWR) ................................................................................................................................... 13 1.6. TRAITEMENT DUN COMMIT................................................................................................................................... 14 1.6.1.Numro de changement du systme (SCN).................................................................................................14 1.6.2.Traitement d'un COMMIT : Etapes............................................................................................................14 1.6.3.Traitement d'un COMMIT RAPIDE (Fast Commit) ..................................................................................15 2.OUTILS D'ADMINISTRATION......................................................................................................................16 2.1. UTILITAIRES ADMINISTRATIFS..................................................................................................................................16 2.1.1.Utilitaires d'administration de base de donnes........................................................................................ 16 2.1.2.Optimal Flexible Architecture (OFA).........................................................................................................17 2.2. ORACLE ENTREPRISE MANAGER (OEM)................................................................................................................17 2.2.1.Architecture d'OEM : Vue d'ensemble....................................................................................................... 17 2.2.2.Composants de la console OEM.................................................................................................................18 2.2.3.Services communs d'OEM.......................................................................................................................... 19 2.2.4.Configurer OEM.........................................................................................................................................19 2.3. PACKAGE D'ADMINISTRATION..................................................................................................................................19 2.3.1.Pack de management DBA......................................................................................................................... 19 2.3.2.Packs de management supplmentaires..................................................................................................... 20 3.GRER UNE INSTANCE ORACLE............................................................................................................... 22 3.1.AUTHENTIFICATION ET PRIVILGES........................................................................................................................... 22 3.1.1.Configurer lauthentification par le systme dexploitation...................................................................... 22 3.1.2.Configurer l'authentification par fichier de mots de passe........................................................................ 23 3.2.FICHIERS DE PARAMTRES.......................................................................................................................................23 3.2.1.Paramtres prsents dans le fichier de paramtre.....................................................................................23 3.2.2.Le PFILE (initSID.ora)...............................................................................................................................23 3.2.3.Le SPFILE (spfileSID.ora)......................................................................................................................... 24 3.2.4.Rgles pour les valeurs de paramtre........................................................................................................ 25 3.2.5.Paramtres essentiels................................................................................................................................. 25 3.2.6.Paramtres communment modifis...........................................................................................................26 3.3. DMARRAGE ET ARRT D'UNE INSTANCE.................................................................................................................. 26 3.3.1.Etapes de dmarrage dune instance......................................................................................................... 26 3.3.2.Dmarrer une instance............................................................................................................................... 27 3.3.3.Changer la disponibilit de la Base de donnes........................................................................................ 27 3.3.4.Etapes d'arrt d'une instance..................................................................................................................... 27
http://www.labo-oracle.com Ce document est la proprit de Supinfo et est soumis aux rgles de droits dauteurs
Grer une instance
3 / 38
3.3.5.Modes d'arrts............................................................................................................................................ 28 3.4. VUE DYNAMIQUE DES PERFORMANCES ..................................................................................................................... 28 3.4.1.Caractristiques des vues dynamiques de performance.............................................................................28 3.4.2.Descriptions des vues dynamiques de performance...................................................................................28 3.5. PARAMTRES DYNAMIQUES.................................................................................................................................... 29 3.5.1.Afficher les valeurs des paramtres courants.............................................................................................29 3.5.2.Paramtres d'initialisation dynamique.......................................................................................................29 3.6. GRER LES SESSIONS.............................................................................................................................................30 3.6.1.Activer les modes Restreint et Lecture seule.............................................................................................. 30 3.6.2.Terminaison de Session.............................................................................................................................. 30 3.7. CONFIGURATION DORACLE MANAGED FILES (OMF).............................................................................................. 31 3.8.FICHIER DE LOG ET D'ALERTES............................................................................................................................... 31 3.8.1.Fichiers de Log...........................................................................................................................................31 3.8.2.Fichiers d'Alerte......................................................................................................................................... 32 4.NATIONAL LANGUAGE SUPPORT (NLS)..................................................................................................33 4.1.JEU DE CARACTRES.............................................................................................................................................. 33 4.1.1.Caractristiques d'NLS...............................................................................................................................33 4.1.2.Plans d'encodage de caractres................................................................................................................. 33 4.1.3.Caractristiques du jeu de caractres........................................................................................................ 34 4.2.COMPORTEMENT DPENDANT DU LANGAGE................................................................................................................34 4.2.1.Paramtres NLS ct serveur..................................................................................................................... 34 4.2.2.Paramtres NLS drivs............................................................................................................................. 35 4.2.3.Contourner le comportement par dfaut NLS............................................................................................ 35 4.2.4.Comportement dpendant du langage pour une session............................................................................36 4.2.5.NLS et le tri.................................................................................................................................................36 4.2.6.Paramtres NLS dans les fonctions SQL....................................................................................................37 4.3.INFORMATION DU DICTIONNAIRE DE DONNES.............................................................................................................37 4.3.1.Obtenir des informations sur les jeux de caractres.................................................................................. 37 4.3.2.Obtenir des informations sur les configurations NLS................................................................................ 38
Grer une instance
4 / 38
1.Composants de larchitecture Oracle

1.1. Introduction au serveur Oracle
1.1.1.Tches de ladministrateur de base de donnes
L'administrateur de base de donnes (appel DBA) est responsable du contrle et de la configuration du systme et des utilisateurs. De nombreuses taches vont tre effectues par celui-ci : Installer le serveur Oracle et les outils applicatifs, crer les bases de donnes. Assurer la maintenance et la disponibilit de la base de donnes. Crer la structure logique de stockage, c'est dire les tablespaces, les tables, les vues et les indexes. Manager la structure physique de stockage, comprenant les fichiers de donnes, les fichiers de contrle et les fichiers de redo log. Allouer et prvoir l'espace disque systme de stockage ncessaire aux spcifications de la base de donnes. Maintenir, contrler et monitorer les accs des utilisateurs. Assurer la scurit du systme. Monitorer les performances de la base de donnes. Crer un plan de sauvegarde et de rcupration.
1.2. Connexion a un serveur Oracle

Pour travailler et consulter les donnes, les utilisateurs doivent tout d'abord se connecter un Serveur Oracle. Il existe trois types de connexions grce auxquelles un utilisateur peut accder un Serveur Oracle : Connexion locale : Selon cette mthode, un utilisateur est directement connect sur la machine faisant office de Serveur Oracle. Connexion Deux Tiers : Ce type de connexion est couramment nomm "Connexion Client Serveur", un utilisateur se connecte partir d'une machine directement connecte un Serveur Oracle. Par exemple, lorsque qu'un utilisateur lance un Oracle Forms (Front End pour consulter des base de donnes Oracle travers des formulaires.) sur un poste client sous Windows pour accder un Serveur Oracle rsident sur une machine Windows NT Serveur. Connexion Multi Tiers : Dans une architecture multi tiers, la machine de l'utilisateur se connecte un Serveur applicatif (Par exemple un Serveur Web) qui lui mme va se connecter au serveur Oracle pour rcuprer les donnes issues de la base de donnes. Lorsque qu'un utilisateur est connect une machine sur laquelle rside un Serveur Oracle, deux process sont invoqus : Le process utilisateur et le process serveur. Un process utilisateur est cr lorsque tout outil client allant communiquer avec le serveur Oracle est lanc (Un outil d'administration, une application, SQL*Plus, une application Oracle Forms). Un process utilisateur est un mcanisme qui va excuter le code d'une application ou d'un outil Oracle. Un process serveur est cr lorsque un utilisateur va se loguer sur le serveur en spcifiant un nom d'utilisateur, un mot de passe et un nom de base de donnes. Le process Serveur est cr sur le serveur Oracle. Le process serveur va permettre l'interaction entre le process utilisateur et le serveur Oracle en rcuprant les requtes et en les excutant sur les serveurs Oracle.
Grer une instance
5 / 38
Le lien entre le process utilisateur et le process serveur est appel une connexion. Si l'utilisateur se connecte localement sur le serveur, le chemin de communication est tabli via un mcanisme de communication inter process. Si l'utilisateur se connecte via une machine cliente, un logiciel rseau est utilis. Une connexion spcifique entre un utilisateur et un serveur Oracle est appel une Session. La session dmarre lorsque la connexion de l'utilisateur est valide par le serveur Oracle et se termine lorsqu'il se dconnecte ou lorsqu'une fin de connexion prmature se produit. De nombreuses sessions concurrentes d'un mme utilisateur ou de plusieurs peuvent s'excuter sur le serveur Oracle.
1.2.1.Processus utilisateur
Pour faire fonctionner un outil application tel que SQL*Plus ou des applicatifs Oracle Forms, Oracle cre un process utilisateur (Client). L'UPI (User Program Interface) est un mcanisme standardis utilis par un process utilisateur pour communiquer avec un process serveur. C'est l'UPI qui gnre l'appel au serveur Oracle.
1.2.2.Processus serveur
Le process serveur a les caractristiques suivantes : Il traite les requtes du process utilisateur et retourne le statut et le rsultat de cette requte. Le DBA la responsabilit de l'administration de ces process serveurs. Chaque process serveur utilise une zone de mmoire appele la PGA (Program Global Area). Cette zone est cre au dmarrage du process serveur. Le process serveur inclus l'OPI (Oracle Program Interface) qui est utilis pour communiquer avec la base de donnes Oracle.
Grer une instance
6 / 38
1.3. Instance Oracle et Base de donnes

1.3.1.System Global Area (SGA)
Un serveur Oracle est constitu d'une instance Oracle et d'une base de donnes Oracle. L'instance Oracle comprend une rgion de la mmoire appele La SGA (System Global Area), ainsi que les processus darrire plan utilis pour grer la base de donnes. La SGA contient des donnes et des informations de contrle sur le serveur Oracle. La mmoire est alloue la SGA lors du dmarrage d'une instance et ds alloue lors de son arrt. Cette zone mmoire est partage et rside dans la mmoire vive qui n'est pas swappe ni pagine pour des raisons de performances. La SGA se compose de plusieurs structures de groupe de mmoire, les trois principales tant : Le pool partag (Shared Pool) : Contient les requtes SQL le plus rcemment excut et l'information du dictionnaire de donnes la plus rcemment utilise. Le buffer de cache de la base de donnes (Database Buffer Cache) : Cette structure stocke les donnes utilisatrices les plus rcentes tires des tables. Le buffer de redo Log (Redo Log Buffer) : Ce buffer est utilis pour enregistrer les modifications effectues sur la base de donnes. Une nouvelle unit dallocation : Le granule. Cest une unit dallocation mmoire contigu dpendant de la taille de la SGA. Si la SGA_MAX_SIZE est infrieur 128 Mo, alors la taille du granule sera de 4 Mo. Si la taille est suprieure ou gal 128 Mo alors la taille du granule sera de 16 Mo. On exprime donc la taille de sa SGA en granule qui en contient au minimum 3 (Fixed SGA (dont redo log buffer), buffer cache, shared pool). Lallocation des granules est montre par la vue V$BUFFER_POOL. On trouve aussi dans la SGA : Le pool large (Large Pool) : Le large pool est une zone mmoire optionnel de la SGA configure uniquement dans un environnement serveur partag. Quand un utilisateur se connecte un serveur partag, Oracle a besoin dallouer de lespace supplmentaire dans les shared pool pour stocker les informations de connexions entre les diffrents process. Le pool large permet donc dallger certaines zones mmoires de la SGA. En effet, il na pas besoin de diminuer la mmoire alloue aux arbres de parcours au profit des informations de sessions, dentres/sortie, de sauvegarde et des processus de rcuprations. Le gain de performance vient de la rduction de la charge occasionne par l'augmentation ou la rduction de la mmoire cache partage. Recover Manager (RMAN), utilise le large pool pour restaurer les donnes en cas de dfaillance. Le pool Java (Java Pool) : Sa taille par dfaut est de 24Mo et doit tre utilis en cas dutilisation du langage Java.
Grer une instance
7 / 38
1.3.2.SGA dynamique
Une SGA dynamique implmente une infrastructure qui permet de modifier la taille dynamiquement de la SGA sans teindre linstance. La taille de la SGA va augmente par lintermdiaire du data buffer cache, du shared pool, et du pool large sans jamais dpasser le SGA_MAX_SIZE. Les paramtres qui affectent la taille de la SGA sont : DB_CACHE_SIZE : La taille de cache des blocs standard. LOG_BUFFER : Le nombre de bit pour le redo log buffer cache. SHARED_POOL_SIZE : La taille en bit du shared pool. LARGE_POOL_SIZE : La taille du large pool, par dfaut 0.
1.3.3.Processus d'arrire plan

Une instance Oracle comprend, en plus de la SGA, un ensemble de process d'arrire plan qui sont au niveau du systme d'exploitation. Oracle 9i comprend cinq process d'arrire plan obligatoire pour une instance : Database Writer (DBWn) : Il crit les donnes changes du buffer de cache de base de donnes vers les fichiers de donnes. Log Writer (LGWR) : Il enregistre les changements qui sont instancis dans le buffer de redo log ver les fichiers de redo log. (Ces changements sont rfrencs comme les donnes du redo log) System Monitor (SMON) : Il excute une rcupration de l'instance lors de son dmarrage, il nettoie les segments temporaires qui ne sont plus utiliss et annule les transaction qui n'avaient pas t valides lors d'un plantage du systme. Il dfragmente l'espace disponible dans les fichiers de donnes. Process Monitor (PMON) : Il rcupre les process lorsque qu'un process utilisateur choue. Il est responsable du nettoyage du cache et de dverrouiller les ressources systme bloques par un process utilisateur.
Grer une instance
8 / 38
Check point (CKPT) : il met jour les statuts d'information sur la base de donnes tels que les enttes des fichiers de base de donnes. Ceci est fait lors d'un vnement de check point tel qu'une rotation des logs. Les changements dans le buffer de cache de la base de donnes sont alors crits de manire permanente dans les fichiers de donnes. En plus de ces process obligatoires, on trouve un ensemble de process optionnels : Recoverer (RECO) Archiver (ARCn) Lock (LCKn) Dispatcher (Dnnn) Shared Server (Snnn) Parallel Query Slaves (Pnnn)
1.3.4.Fichiers de la base de donnes

Une base de donnes Oracle a une structure logique et physique. Entendons par structure physique que les fichiers contenu dans la base de donnes ont une relle existence (ex : fichiers de donnes). Pour sa part, la base de donnes Oracle est constitue de trois types de fichiers : Les fichiers de donnes contenant les donnes des blocs de donnes qui sont modifies par les transactions courantes, le dictionnaire de donnes, les objets utilisateurs. Les fichiers de redo log contenant un enregistrement des changements qui ont t fait sur la base de donnes, pour avoir la possibilit de revenir en arrire en cas de dysfonctionnement. Une base Oracle contient au moins deux groupes de redo log chacun contenant au moins un fichier de redo log. Pour renforcer leur tolrance une panne de disque dur, Oracle supporte les fichiers de redo log multiplexs. On peut ainsi maintenir une ou plusieurs copies de fichiers de redo log sur diffrents disques (On parle de fichiers mirrors). Les fichiers de contrles contenant les informations ncessaires pour maintenir et vrifier lintgrit des donnes de la base. Une base de donnes Oracle ncessite au moins un fichier de contrle, il est toutefois possible de les mirrorer sur plusieurs disques dur.
1.3.5.Fichiers relatant la Base de donnes

Ce sont les fichiers qui ne font pas partie de la base de donnes mais qui sont utiliss par le serveur Oracle pour des oprations telles que le dmarrage d'une instance ou l'authentification des utilisateurs. Il existe trois types de fichiers :
Grer une instance
9 / 38
Les fichiers de paramtre (Parameter File) : Il va dfinir les caractristiques de l'instance. Lors du dmarrage d'une instance, le serveur Oracle va lire les paramtres d'initialisation du fichier de paramtres. On retrouve des informations telles que le nom de la base de donnes, la taille de la mmoire allouer, le nom des fichiers de contrle ainsi que les autres paramtres systme. Le fichier de mots de passe (Password File) : Il est utilis pour authentifier les utilisateurs privilgis. Les fichiers de redo log archivs (Archived Redo Log Files) : Ils contiennent des copies off line des fichiers de redo log. Ils sont utiliss lors d'une rcupration suite une dfaillance d'un mdia. Les fichiers de redo log sont sauvs lorsqu'ils sont pleins, cette fonctionnalit n'est utilise que lorsque la base de donnes est en mode "ARCHIVELOG".
1.4. Traitement de requtes

1.4.1.Etapes lors du traitement d'une requte
Lorsqu'un utilisateur lance une dclaration ou une requte SQL, le process utilisateur l'envoie au process serveur qui la traite. Ce traitement est dcoup en trois tapes : Parcours (Parse) : Le process serveur reoit la requte, analyse la syntaxe et vrifie les privilges de l'utilisateur pour les objets rfrencs accder. La section de mmoire du pool partag de la SGA est utilise pour compiler la requte et crer un arbre de parcours. Le statut de russite ou non de l'analyse est renvoy au process utilisateur. Excution (Excution) : Prparation de la rcupration des donnes. Si l'ordre SQL est un UPDATE ou un DELETE, les lignes affectes sont verrouilles par le process serveur pour tre rendues non accessibles aux autres utilisateurs. Rcupration des donnes (Fetch) : Les donnes sont rcupres et envoyes au process utilisateur. Selon la quantit de mmoire disponible, un ou plusieurs fetch peuvent tre ncessaires.
1.4.2.Pool partag (Shared Pool)

Le pool partag est une zone mmoire faisant parti de la SGA et dont la taille doit tre dfinie par le DBA. Le Shared Pool peut tre retaille dynamiquement avec la commande :
ALTER SYSTEM SET SHARED_POOL_SIZE = 128M;
Nous allons ici voir les diffrentes composantes de cette zone utilise par le process serveur pour traiter les requtes. On trouve dans le pool partag : Le cache de librairie (Library Cache) : Contient les informations sur les requtes SQL et/ou PL/SQL rcemment utilises. Le plan dexcution de ces requtes est galement stock ainsi que larbre de parcours et le texte des requtes. Les verrous et les handles sur le cache de librairie sont galement consigns. Le cache de librairie est compos de deux structures : la zone partage SQL et la zone partage PL/SQL Le cache du dictionnaire de donnes (Data Dictionary Cache) :
Grer une instance
10 / 38
Contient des informations les plus rcemment utilises sur le dictionnaire de donnes, les objets de la base de donnes, sa structure et la dfinition des colonnes. On trouve galement les utilisateurs valides, leur mot de passe et leurs privilges. Les informations du dictionnaire de donnes sont mises en cache lorsque elles sont demandes par la base de donnes. Ceci permet daugmenter la rapidit daccs aux donnes.
1.4.3.Buffer de Cache de la base de donnes (Database Buffer Cache)

Lorsquune requte est excute, le process serveur consulte le database buffer cache (Compris dans la SGA) pour les blocs de donnes requis par la requte. Le DBA doit configurer la taille de cette zone mmoire. Le buffer de cache est compos de trois caches indpendants : DB_CACHE_SIZE : Ne peut tre mis 0. Gre la taille du buffer par dfaut DB_KEEP_CACHE_SIZE : Gre la taille du keep buffer cache, utilis pour stocker les blocs dans la mmoire susceptible dtre rutiliss. DB_RECYCLE_CACHE_SIZE : Gre le taille du recycle buffer cache, employ pour supprimer les blocs de mmoire rutilis qui ont subit peu de changement. DB_CACHE_ADVICE (ON, OFF, READY) : Permet dactiver les statistiques qui prdisent le comportement de la base lorsquon modifie la taille du cache. Les rsultats sont consultables laide de la vue V$DB_CACHE_ADVISE.
Le database buffer cache contient des blocs de donnes lus dans les fichiers de donnes. Cela permet au process serveur daccder plus rapidement aux donnes, cette zone comporte les caractristiques suivantes : Le database buffer cache contient les donnes les plus rcemment et frquemment utilises. Il contient des blocs de donnes modifies et non modifies dats selon un algorithme Oracle (LRU) pour mettre jour le buffer. La taille de chaque buffer du buffer cache est gale la taille dun bloc Oracle et spcifi par le paramtre DB_BLOCK_SIZE.
1.4.4.Buffer de Redo Log

Le buffer de redo log enregistre les changements faits lors dune requte DML. Ces caractristiques sont les suivantes : Il fait parti de la SGA. Sa taille est dfinie par le paramtre LOG_BUFFER et doit tre dfinie par le DBA. Il se compose dentres qui contiennent les blocs changs, la position du changement et la nouvelle valeur. Il nidentifie pas le bloc o les changements sont faits, c'est--dire quil traite de manire similaire les blocs de donnes, dindex ou de segments de ROLLBACK. Son utilisation est squentielle et circulaire. Il est renouvel lorsquil est plein et que les entres ont t enregistres dans les fichiers de redo log on-line.
1.4.5.Program Global Area (PGA)

Lorsque quun process serveur est cr, ou un process darrire plan, la base de donnes Oracle alloue une zone globale de programme (PGA Program Global Area ou bien Process Global Area) dans la mmoire. Cest un buffer mmoire qui contient les donnes et les informations de contrle pour ce process serveur. Elle contient pour un serveur ddi :
Grer une instance
11 / 38
Une zone de tri (Sort area) : Utilis pour stocker, si ncessaire, les rsultats intermdiaires lors du tri. Des informations de session : Contient les privilges utilisateurs pour la session en cours. Un tat de curseur (Cursor State) : Etat de ltape dans lexcution des ventuels curseurs de la session. Un curseur est un pointeur sur la mmoire associ une requte SQL donne. Cest une zone de travail utilis pour stocker le rsultat de la requte. Un espace de pile (Stack Space) : Contient les variables de session et les arrays. Dans la version 9i, de nouveaux paramtres dynamiques de gestion de la PGA sont apparus. Par exemple, PGA_AGGREGATE_TARGET dfinit la taille maximale que peut atteindre la PGA totale alloue toute une instance. La taille total de la PGA est infrieur au PGA_AGGREGATE_TARGET en mode auto de WORKAREA_SIZE_POLICY.
1.5. Traitement de requtes DML

1.5.1.Phases d'excution d'un requte DML
Les requtes de manipulations de donnes (DML), tel que les UPDATE, DELETE ou INSERT, sont utilises pour manipuler les donnes. Comprendre leur excution permet de crer le data buffer cache et les segments de ROLLBACK appropris. Le traitement dune requte DML se compose de deux phases : Parcours (Parse) : Contrle des erreurs et placement dans une mmoire partage SQL. Excution : Si la phase de parcours sest effectue avec succs, lexcution se fait en plusieurs tapes. Lecture des blocs de donnes et de ROLLBACK dans le database buffer cache. Mise en place de verrous sur les donnes qui vont tre changes. Ecriture de limage-avant dans les segments de roll back et enregistrement des changements du buffer cache dans le redo log buffer pour protger limage-avant en cas de dfaillance. Finalement, les donnes sont enregistres dans le buffer cache et les changements sont galement enregistrs dans le redo log buffer protgeant ainsi limage-aprs. Les blocs de donnes altres dans le buffer cache sont marqus comme " sales (Dirty) ", c'est--dire quils ne correspondent plus aux blocs dans les fichiers de donnes.
Grer une instance
12 / 38
1.5.2.Segments de Rollback
Les segments de Rollback sont utiliss pour sauver les donnes lors dune requte DML afin de les restaurer en cas d'annulation de la transaction ainsi que pour empcher dautres transactions de voir les donnes en cours de modification. Ces segments ne sont pas visibles par un utilisateur. Une base de donnes contient un ou plusieurs segments de Rollback. Le serveur Oracle assigne un segment de Rollback chaque transaction. Les segments de Rollback peuvent permettre de rcuprer des donnes non commites lors dune transaction. Ils permettent galement de rcuprer un tat consistant de la base de donnes en cas de dfaillance systme. Les segments de Rollback sont contenus dans les fichiers de donnes et sont lus dans le database buffer cache si ncessaire.
1.5.3.Database Writer (DBWn)

Ce process darrire plan crit les donnes du database buffer cache vers les fichiers de donnes sur le disque. Ces blocs de donnes sont crits lorsque certains vnements se produisent tel que : Lcriture a lieu lorsque le nombre de buffers sales atteint un seuil, cela permet de librer des buffers dans le database buffer cache. Lcriture se produit lorsque quun process serveur ne trouve plus de buffer libre aprs avoir recherch un certain nombre de buffers. Lcriture seffectue lors dun timeout, par exemple lorsque le DBWn reste inactif plus de trois secondes. Le DBWn recherche alors des buffers sales selon lalgorithme LRU ou bien crit la totalit si la base de donnes est inactive.
Grer une instance

13 / 38
Le DBWn se dclenche lorsquun check point est atteint, cela se produit par exemple lors de larrt de la base de donnes. Lorsquun tablespace temporaire ou normal est mis offline. Lorsquun tablespace est mis en lecture seule. Lorsquune table est tronque ou supprime. Lors dun timeout.
1.5.4.Log Writer (LGWR)

Le Log Writer crit squentiellement des entres du redo log buffer vers les fichiers de redo log. Le process LGWR crit lorsque lun des quatre vnements suivants se produit : Lorsque le buffer de redo log est plein un tiers de sa capacit. Lorsquun timeout se produit, par exemple lors dune inactivit de plus de trois secondes. Avant que le process DBWn crive les donnes du database buffer cache vers les fichiers de donnes. Lorsquune transaction utilisateur est commite. Toutes les 3secondes. LGWR peut demander DBWn dcrire dans les fichiers de donnes.
Grer une instance
14 / 38
1.6. Traitement dun commit

1.6.1.Numro de changement du systme (SCN)
La base de donnes Oracle assigne un SCN (System Change Number) chaque transaction qui est commite dans le but de lidentifier de manire unique. Ce numro unique est enregistr dans les segments de Rollback ainsi que dans les fichiers de redo log. Il est galement utilis comme une marque temporelle (Timestamp) pour permettre la base de donnes de synchroniser les donnes. Les vnements sont organiss dans un ordre temporel au sein dune instance et entre instances. Il permet au serveur Oracle de lire les donnes de manire consistante en faisant abstraction de la date systme du systme dexploitation lors de la restauration de la base de donnes.
1.6.2.Traitement d'un COMMIT : Etapes

Une transaction doit tre crite de manire permanente aprs le traitement de celle-ci. Pour cela un COMMIT est ralis. Nous allons voir les tapes qui constitue cette action de commit : Un process serveur enregistre une ligne COMMIT accompagne de son SCN dans le buffer de redo log. Le process LGWR crit les entres du buffer de redo log dans les fichiers de redo log en commenant par la ligne de COMMIT (LGWR confirme la russite du commit seulement aprs que les buffer de redo log soit crit sur le disque.). Le process serveur enregistre les informations indiquant que la transaction est termine. Les ressources verrouilles dans les tables et les enregistrements sont alors libres. Le process serveur informe le process utilisateur de la fin du COMMIT. Un commit ralisant ces tapes est appel un commit rapide (Fast Commit), on remarquera que seul le buffer de redo log est crit sur le disque. Les buffers sales sont crits dans le fichier de donnes de manire indpendante par le process DBWn.
Grer une instance
15 / 38
Une seule criture sur le disque est donc ncessaire pour raliser un COMMIT. Si plusieurs process utilisateurs ralisent un commit simultanment, le serveur Oracle rassemble les commits et ncrit quune seule fois.
1.6.3.Traitement d'un COMMIT RAPIDE (Fast Commit)

Un serveur Oracle utilise un mcanisme de COMMIT rapide. Cela lui permet de restaurer les donnes en cas de dfaillance du systme dexploitation. Une criture squentielle est ralise dans les fichiers de redo log ce qui est un gain de temps considrable compar une criture des donnes dans diffrents blocs des fichiers de donnes. Seul les informations ncessaires pour enregistrer les changements sont crites dans les fichiers de redo log, ce qui est plus conomique en temps car crire les donnes dans les fichiers de donnes demande dcrire les blocs entiers et non les seuls changements. Plusieurs transactions peuvent tres commites en une seule fois et laide dune seule criture. Le FAST COMMIT ne require quune seule criture synchronise par transaction, mis part si le buffer de redo log est plein, la taille dune transaction naffecte donc pas la rapidit dun commit.
Grer une instance
16 / 38
2.Outils d'administration
2.1. Utilitaires administratifs
2.1.1.Utilitaires d'administration de base de donnes
Oracle Universal Installer : Linstallateur Universel est un installateur Java utilis pour installer Oracle9i, les outils Oracle et les utilitaires. Il peut installer des logiciels partir dun CDROM ou dInternet, dtecter les dpendances entre les diffrents composants. Il dtecte le langage courant du systme dexploitation ou bien utilise le langage par dfaut. Il est possible de spcifier diffrents rpertoires principaux (Le ORACLE_HOME) pour permettre dinstaller plusieurs versions dun mme produit. Linstallation peut tre guid par des assistants ou permet dutiliser des packages standard ncessitant un minimum de rponses. Il est galement possible de le lancer en mode silencieux, dans ce cas, un fichier de rponse est utilis pour remplacer les rponses aux diffrentes questions lors de linstallation. Le mode silencieux est utilis lorsquil ny a pas de terminal graphique ou lorsque lon veut que lutilisateur na rien faire pour linstallation. La syntaxe de lancement de la commande varie en fonction du systme dexploitation :
Unix : $ ./runInstaller Unix (Installation silencieuse en utilisant rpones) : ./runInstaller responsefile myrespfile silent les fichiers de
Un fichier de log est cr lors de linstallation et contient lensemble des tapes et les rsultats. Une liste des produits installs est maintenue en cas de dsinstallation de lun dentre eux. Les outils de post-installation sont galement lancs si besoin est. Par exemple, aprs linstallation dOEM (Oracle Enterprise Manager), lassistant de configuration de base de donnes est lanc. Oracle Database Configuration Assistant : Cet assistant permet de crer une base de donnes, configurer les options de la base de donnes, supprimer une base de donnes, grer les templates. Outils pour la cration des fichiers de mots de passe : La commande orapwd permet de crer un fichier de mot de passe :
$orapwd file=$ORACLE_HOME/dbs/orapwu15 Password=admin entries=5
Ensuite, il suffit de mettre REMOTE_LOGIN_PASSWORDFILE EXLUSIVE dans le fichier de paramtre. Puis, ajouter les utilisateurs au fichier de mot de passe et de leur attribuer des privilges. SQL* Plus : SQL* Plus est un outils Oracle qui permet de manipuler et interagir avec la base de donnes. Une prsentation plus complte de SQL* Plus est disponible dans le module SQLP.
Grer une instance
17 / 38
Oracle Enterprise Manager : Cest un outil important permettant, via une interface graphique, dadministrer, de contrler et de tuner une ou plusieurs bases de donnes localises sur un ou plusieurs serveurs.
2.1.2.Optimal Flexible Architecture (OFA)

OFA est larchitecture standard quil est recommand dutiliser dans une base de donnes Oracle. Les trois rgles importantes pour respecter cette architecture sont : Etablir une structure de rpertoires, o nimporte quel fichier de base de donnes peut tre enregistr sur nimporte quel espace disque. Sparer les objets avec un comportement diffrent sur diffrents tablespaces. Augmenter les performances de la base de donnes en sparant les composants de la base de donnes sur des disques diffrents. OFA organise donc la base de donnes en fonctiondes types de fichiers et de leurs utilisations. Les fichiers binaires, de contrles, de logs et administratifs peuvent tre spars sur des disques diffrents. Ladministration en sera simplifi et les performances grandement amliores.
Larborescence ci-dessus montre une structure de stockage selon le modle OFA.
2.2. Oracle Entreprise Manager (OEM)

2.2.1.Architecture d'OEM : Vue d'ensemble
Oracle Entreprise Manager fournit un outil graphique de configuration systme pour administrer une ou plusieurs bases de donnes. OEM se prsente sous la forme dune architecture trois tiers, elle comprend : La console est un outil graphique, utiliss par les DBA pour administrer une ou plusieurs bases de donnes partir dune mme console. La console OEM comporte des menus, des barres doutils et elle peut intgrer des outils provenant dautres fabricants. Elle permet daccder un ensemble doutils tel que la planification de taches, la gestion des vnements, la recherche de services sur le rseau et la scurit.
Grer une instance
18 / 38
Les composants OMS forment le second tiers, les donnes de ces composants sont en effet stockes dans le repository OEM. Le repository OEM est un jeu de tables dans la base de donnes contenant les donnes systme, les donnes applicatives et ltat des nuds administrs sur lenvironnement Oracle. La base de donnes stockant le repository OEM doit tre accessible la console OEM. Un repository est associ des utilisateurs et non une machine, ainsi, il devient indpendant de sa localit et peut tre accd de partout. Un repository OEM distinct peut tre associ chaque utilisateur. OMS peut donc effectuer toutes les taches administratives, et ce de manire distribue, de plus, plusieurs OMS peuvent tre mis en place et agir en load balancing, ce qui augmente la tolrance de panne.
Les Noeuds constituent la troisime couche de larchitecture quun utilisateur va chercher administrer. Ces nuds sont contrls par les intelligent agents . Un intelligent agent est un process qui sexcute sur le nud distant du rseau et qui permet de ladministrer distance.
2.2.2.Composants de la console OEM

La console OEM est linterface graphique utilisateur de lapplication OEM, elle contient un ensemble de composants qui permettent un ensemble de DBA dadministrer une ou plusieurs base de donnes dans un environnement Oracle. Elle se compose de menus permettant de lancer des applications dadministrations, des outils daccs et de services et laccs lensemble des fonctionnalits de la console OEM. Elle contient un ensemble dicnes prsentant sous forme de palettes les diffrents outils, et donnant un accs similaire aux lments des menus de manire plus rapide. Une fentre de navigation apporte une vue hirarchique des diffrents nuds du rseau, elle permet de visualiser lensemble des services Oracle travers le rseau ainsi que les objets quils contiennent. Les objets rseaux sont galement reprsents sur une carte graphique qui permet de les situer gographiquement. La console OEM comprend galement la gestion des taches planifies (Job) qui permettent de lancer distance des taches concernant les listeners , les bases de donnes ou bien les htes. Un historique et un suivi de ltat des jobs sont galement disponibles. On peut galement consulter les vnements systmes sur les diffrents nuds et selon les critres que lon souhaite. Le DBA peut alors tre contact par email ou autres. Certains vnements peuvent faire lobjet de jobs correctifs qui seront lancs au dclanchement de celui-ci.
Grer une instance

2.2.3.Services communs d'OEM
19 / 38
OEM comporte un ensemble de services permettant au DBA dadministrer les serveurs Oracle et leurs bases de donnes. Les principaux services fournis par les OMS sont les suivants : Le service de taches panifies (Job Service) : Il gre les jobs programms et permet donc dautomatiser des taches rptitives. Le service de gestion des vnements (Event Service) : Il permet de contrler les vnements systmes survenant sur lensemble des serveurs Oracle du rseau, il permet de contrler des limites applicatives et systmes tel que lespace occup par les fichiers de donnes, la charge CPU ou bien des pertes de disponibilit dun service. Il peut, lors dun vnement donn, dclencher des jobs de rcupration ou autres. Le service de dcouverte (Discovery Service) : Cest un assistant permettant de dcouvrir sur le rseau les diffrents services tel que les bases de donnes, les serveurs Web, les listeners, les machines, les parallel Servers et les serveurs de vido. Le service de scurit (Security Service) : Il permet de contrler laccs aux services Oracle ainsi quaux nuds du rseau. Un super administrateur peut galement grer les diffrents administrateurs et leurs privilges. Les authentifications sont encodes dans le repository OEM et les utilisateurs doivent spcifier leur identit pour accder chaque ressource travers la console OEM.
2.2.4.Configurer OEM
Cette section prsente la configuration dOEM, lors de son installation, installateur universel lance lassistant de configuration dOEM, mais il est galement possible de le lancer nouveau lors de la cration dun repository supplmentaire. Les tapes se dcoupent comme suit : Cration du repository OEM : Lassistant de configuration demande lhte, le port, et le SID du lieu ou va tre install le repository. Lancement du service OMS : La seconde tape consiste lancer le service OMS, il dmarre automatiquement au dmarrage de Windows ou bien il peut tre dmarr manuellement. Lancement de la console OEM : La console OEM peut tre lanc via le menu Dmarrer . Il est alors possible de se connecter au repository OEM et de dcouvrir automatiquement (Ceux ou lintelligent agent est lanc) ou manuellement les diffrents nuds et services prsents sur le rseau. Configuration de la scurit : La scurit approprie doit tre mise en place pour contrler laccs aux diffrents nuds et services du rseau. Lauthentification pour un utilisateur doit tre configure pour chaque objet accder. Travail sur une base de donnes : La dernire tape consiste choisir une base de donnes via lexplorateur et sauthentifier pour pouvoir ladministrer.
2.3. Package d'administration

2.3.1.Pack de management DBA
Le pack de management DBA est un ensemble doutils utiliss pour ladministration des bases de donnes. Il se compose de cinq applications et de deux jeux dutilitaires et dassistants :
Grer une instance

20 / 38
Instance Manager : Cet outil permet de monter, fermer et surveiller une base de donne Security Manager : Il permet de contrler laccs aux services Oracle ainsi quaux nuds du rseau. Un super administrateur peut galement grer les diffrents administrateurs et leurs privilges. Storage Manager : Permet de surveiller les tablespaces, fichiers de donnes, segments de rollback. Schema Manager : Il permet de crer et maintenir des objets comme les tables, indexes et vues. SQL* Plus Worksheet : Cest une application en ligne de commandes permettant de lancer des requtes SQL, du code PL/SQL ou encore des commandes SQL*Plus.
Les outils et les assistants de sauvegarde Oracle : Ils permettent de sauvegarder, restaurer ou bien recouvrer une base de donnes. On peut galement grer les fichiers de redo log grce ces outils. On lance ces outils partir de la console ou du Gestionnaire de Schma. Les outils et assistants de gestion des donnes : Ils aident au chargement et lorganisation des donnes dans les bases de donnes. Ils permettent galement le transfert des donnes partir et vers une base de donnes Oracle. On lance ces outils partir de la console ou du Gestionnaire de Stockage.
2.3.2.Packs de management supplmentaires

OEM peut intgrer dans sa console trois outils administratifs supplmentaires : Le Pack de Diagnostic : Il fournit des utilitaires daudit et de monitoring des bases de donnes, il devient possible de collecter et dinspecter des performances spcifiques selon des statistiques aidant au paramtrage fin dune base de donnes. Le Gestionnaire de Performances Oracle permet de raliser cela en temps rel et fournit des vues graphiques sur la performance de la base de donnes et du systme. Oracle TopSessions permet de lister lensemble des sessions connectes au serveur Oracle. On peut galement voir les dtails dune session et y mettre fin. Le planificateur de capacit permet de collecter des donnes et de stocker un historique des informations sur la base de donnes pour parer laugmentation de la capacit requise. Le Visualisateur de donnes de trace Oracle permet de suivre et de programmer les informations de traages de la base de donnes et de Net8. Le Pack de Tuning : Il se compose dun ensemble doutils visant amliorer les performances dune base de donnes. Lanalyseur SQL permet danalyser et dditer des requtes SQL pour augmenter leurs performances. Le Gestionnaire de Tablespace permet de monitorer et contrler lespace de stockage. Il fournit un ensemble dinformations sur les tablespaces et leurs segments. On peut dfragmenter lespace occup et rorganiser les donnes. Oracle Expert permet de tuner et doptimiser le systme de manire trs fine. Le Pack de Gestion du Changement : Il se compose dutilitaires utiliss pour contrler le changement de la dfinition des objets de la base de donnes. Lapplication de Capture permet de capturer limage dun objet un instant donn. Lapplication de Diffrentiel permet de comparer les diffrences entre la dfinition dobjet pour deux base de donnes ou selon un modle. Les Objet de Changement rapide et de modification permettent de propager des changements aux objets dune ou plusieurs bases de donnes. Lapplication de Gestion des Plans permet de centraliser laccs tous ces outils.
Grer une instance
21 / 38
Grer une instance
22 / 38
3.Grer une Instance Oracle

3.1.Authentification et privilges
Les utilisateurs administrateurs de la base de donnes sont responsables de la gestion et de ladministration du serveur Oracle. Des privilges particuliers sont requis pour permettre de faire ces taches. Deux comptes utilisateur DBA son crs automatiquement et ont le rle DBA : Le compte SYS : Cr lors de linstallation dOracle avec tous les privilges systmes. Mot de passe par dfaut : change_on_install, changer aprs linstallation. Le schma de SYS stocke toutes les tables et les vues du dictionnaire de base de donnes. Aucun utilisateur ne peut modifier ou crer de table dans ce schma. Le compte SYSTEM : Cr lors de linstallation dOracle avec tous les privilges systmes. Mot de passe par dfaut : manager changer aprs linstallation. Le schma de SYSTEM stocke les tables et les vues administratives ainsi que des informations administratives propres certains produits Oracle supplmentaires.
3.1.1.Configurer lauthentification par le systme dexploitation

Des privilges particuliers sont attribus aux utilisateurs DBA pour les tches administratives. Pour sassurer que seul des utilisateurs valides puissent se connecter la base de donnes avec les privilges adquats, Oracle fournit deux mthodes dauthentification. Ces mthodes sont lauthentification par lOS ou bien par un fichier de mots de passe (Mthode dauthentification propre Oracle). Lors dune administration locale, les deux mthodes peuvent tre utilises au mme titre. Il en va de mme lors dune administration distante si vous avez une connexion scurise la base de donnes. Par contre, si la connexion nest pas scurise, il est ncessaire dutiliser lauthentification par fichier de mots de passe. Dans le cas de lauthentification par le systme dexploitation, le nom dutilisateur systme du DB fait partie dun groupe spcial ayant les privilges dadministration. Si lon place un compte utilisateur dans ce groupe, il hrite des droits DBA. Configuration : Sous Windows NT, il est possible de crer un groupe spcifique chaque instance ou pour toutes les instances. Pour cela, il faut utiliser User Manager. Groupes spcifiques chaque instance : ORA_<SID>_DBA et ORA_<SYD>_OPER (Le <SID> tant le nom de linstance). Groupes non spcifiques une instance : ORA_DBA et ORA_OPER. Il est ensuite ncessaire dditer le fichier de paramtres pour prciser que lauthentification par fichier de mots de passe nest pas ncessaire. Il suffit daffecter la valeur NONE la variable REMOTE_LOGIN_PASSWORDFILE. Il est ensuite possible de se connecter avec les privilges SYSDBA en tapant dans SQL*Plus Worksheet : Connect / AS SYSDBA.
Grer une instance

3.1.2.Configurer l'authentification par fichier de mots de passe
23 / 38
Lorsque la connexion un serveur distant nest pas scurise (Pas dauthentification par le systme dexploitation), la solution la plus scurise consiste utiliser lauthentification Oracle (Ou authentification par fichier de mot de passe). Lutilitaire ORAPWD.exe permet de crer un fichier de mot de passe. Cest dans ce fichier que sont consigns les comptes et mots de passe des utilisateurs pour se connecter au schma SYS. Avec cette mthode dauthentification, lutilisateur SYS peut utiliser la commande GRANT pour fournir des privilges DBA dautres utilisateurs Oracle. Le contenu du fichier de mot de passe est stock dans un format crypt et non lisible par des utilisateurs Oracle dune autre base de donnes. Ce fichier est un fichier cach se trouvant sous Windows NT dans le rpertoire %ORACLE_HOME%\DATABASE. Sous UNIX, cest dans le rpertoire $ORACLE_HOME/dbs que lon peut le trouver. La commande suivante doit tre utilise pour configurer ce mode dauthentification :
ORAPWD FILE=<fname> PASSWORD=<password> ENTRIES=<entries>
Ou : <fname> est le nom et le chemin complet du fichier de mot de passe. <password> est le mot de passe pour les comptes SYS et INTERNAL. <entries> est le nombre maximum dutilisateurs qui peuvent se connecter en tant que SYSDBA et SYSOPER. Le paramtre REMOTE_LOGIN_PASSWORDFILE peut tre positionn avec la valeur EXCLUSIVE ou SHARED. En mode EXCLUSIVE, une seule instance peut utiliser le fichier de mot de passe et il peut contenir dautres noms dutilisateurs que SYS et SYSTEM. En mode SHARED, plusieurs instances peuvent se partager le fichier de mots de passe. Par contre, seul lutilisateur SYS est reconnu.
3.2.Fichiers de paramtres
3.2.1.Paramtres prsents dans le fichier de paramtre
Une base de donnes Oracle devient accessible aux utilisateurs lorsque le DBA dmarre linstance et ouvre la base de donnes. Pour dmarrer une instance, Oracle lit le fichier dinitialisation. Ces fichiers sont au nombre de deux (le dernier est une nouveaut de la 9i) : le PFILE et le SPFILE. Le PFILE fait communment rfrence au fichier init<SID>.ora et le SPFILE (fichier binaire) fait rfrence au fichier spfile<SID>.ora o SID est le nom de linstance. Le fichier de paramtre est un fichier texte contenant la liste des paramtres de dmarrage de linstance.
3.2.2.Le PFILE (initSID.ora)

Sous Windows NT, ce fichier se trouve par dfaut dans le rpertoire %ORACLE_HOME%\database et contient un paramtre IFILE qui fait rfrence un fichier plus complexe situ dans le rpertoire % ORACLE_HOME%\admin\<SID>\pfile. Sous UNIX, on peut le trouver dans le rpertoire $ORACLE_HOME/dbs. Ce fichier est lu lors du dmarrage de linstance, on peut lditer avec nimporte quel diteur de texte et le redmarrage de linstance est ncessaire pour que les changements prennent effet. Il est prfrable de faire une copie de ce fichier sur lordinateur o se trouve OEM sil en existe un. Parmi les paramtres du fichier de paramtre, on trouve le nom de la base de donnes pour laquelle linstance est dmarre.
Grer une instance
24 / 38
Les paramtres contrlent les performances de la base de donnes ainsi que la quantit de mmoire utilise par les diffrentes composantes de la SGA. On peut galement dfinir certains attributs physiques de la base de donnes au moment de sa cration telle que la taille des blocs de donnes. On trouve galement dans ce fichier le nom et le chemin des fichiers de contrle, des fichiers de log archivs et des fichiers de trace de la base de donnes.
3.2.3.Le SPFILE (spfileSID.ora)

Le spfile est un fichier binaire de paramtres dynamiques qui est gr par le serveur Oracle. Il se situe dans le mme rpertoire que le initSID.ora et contient aussi les mmes donnes. Si le fichier spfileSID.ora existe, il est prioritaire par rapport au PFile. En effet, au dmarrage de linstance le serveur essayera de lire le spfile plutt que le pfile, le pfile sera lu seulement en cas dchec de la lecture du spfile. Il est possible de crer le spfile partir du pfile avec la commande suivante :
CREATE SPFILE = s_params.ora FROM PFILE = $ORACLE_HOME/work/t_init1.ora
Comme pour le pfile il est possible de modifier les paramtres dinitialisation avec la commande :
ALTER SYSTEM SET paramtre = valeur [COMMENT = moncommentaire] [SCOPE = MEMORY | SPFILE |BOTH] [DEFERRED]
Grer une instance
25 / 38
O MEMORY : en mmoire uniquement (par dfaut comme la 8i). SPFILE : uniquement dans le SPFILE. BOTH : en mmoire et dans le SPFILE. DEFERRED : pour les paramtres dynamiques, les active pour les sessions futures (pas celles en cours). COMMENT : commentaire associer au paramtre de longueur maximale de 255 caractres. Remarque : Le contenu du spfile est visible dans la vu dynamique V$SPPARAMETER et non pas V$PARAMETER qui est utilis par le pfile.
3.2.4.Rgles pour les valeurs de paramtre

Un ensemble de rgles rgissent les paramtres compris dans le fichier de paramtre : La plupart des paramtres sont optionnels. Leur ordre nest pas important. Le format pour dfinir un paramtre est de la forme nom_de_paramtre=valeur et scrit sur une ligne. La plupart des paramtres ont une valeur par dfaut. Si un paramtre comprend des espaces ou des tabulations, il doit tre mis entre doubles quotes. Certain paramtres tel que CONTROL_FILE peuvent prendre plusieurs valeurs, elles doivent tre mises entre parenthses et spares par des virgules. Des lignes de commentaires peuvent tre incluses dans le fichier et doivent commencer par le symbole #. Le mot cl IFILE est utilis pour inclure dautres fichiers un fichier de paramtre. Si le systme dexploitation est sensible la casse, le fichier de paramtre le devient galement.
3.2.5.Paramtres essentiels
La plupart des paramtres sont optionnels, cependant certains paramtres sont au contraire essentiels pour linstance Oracle. La liste suivante les prsente : DB_NAME : Identifiant de la base de donnes. DB_CACHE_SIZE : Ne peut tre mis 0. Gre la taille du buffer par dfaut. DB_KEEP_CACHE_SIZE : Gre la taille du keep buffer cache, utilis pour stocker les blocks dans la mmoire susceptible dtre rutiliss. DB_RECYCLE_CACHE_SIZE : Gre le taille du recycle buffer cache, employ pour supprimer les blocs de mmoire rutilis qui ont subit peu de changement. DB_BLOCK_SIZE : Taille dun bloc de donnes spcifi lors de la cration de la base de donnes. Ne peut tre chang aprs la cration. COMPATIBLE : Version du serveur avec laquelle linstance pourra tre compatible. CONTROL_FILES : Spcifie le nom des fichiers de contrle de la base de donnes. SHARED_POOL_SIZE : Spcifie la taille du pool partag en bytes.
Grer une instance
26 / 38
BACKGROUND_DUMP_DEST : Spcifie le rpertoire ou le process de fond de taches crit les fichiers de trace et les fichiers de log dalertes. USER_DUMP_DEST : Spcifie le lieu o les fichiers de trace utilisateurs sont cres.
3.2.6.Paramtres communment modifis

Les paramtres le plus souvent modifis par le DBA pour une instance donne sont les suivants : IFILE : Permet dinclure un autre fichier de paramtres dans le fichier courant. Peut tre utilis jusqu trois niveaux. LOG_BUFFER : Spcifie le nombre de bytes qui sont allous pour le buffer de redo log dans la SGA. MAX_DUMP_FILE_SIZE : Spcifie la taille maximale en bloc des fichiers de trace. PROCESSES : Dfinit le nombre maximum de process du systme dexploitation pouvant tre simultanment connect linstance. SQL_TRACE : Permet dactiver ou non lutilitaire de trace SQL pour toutes les sessions utilisateurs. TIMED_STATISTICS : Permet dactiver ou non la datation des vnements dans les fichiers de trace et les crans de monitoring.
3.3. Dmarrage et arrt d'une instance

3.3.1.Etapes de dmarrage dune instance
Le dmarrage dune instance se fait en plusieurs tapes. Elles sont au nombre de trois et se prsentent tel que suit : le dmarrage de linstance, le montage de la base de donnes et louverture de la base de donnes. Le dmarrage de linstance est la premire tape, on parle de mode NOMOUNT. On dmarre ce mode lors de la cration de la base de donnes ou la rgnration des fichiers de contrle. Cest ce moment que le serveur va essayer de lire les fichiers de paramtres dans lordre suivant : le spfileSID.ora. Si il nest pas trouv alors, le spfile.ora (fichier de paramtres cre automatiquement avec une base de donnes). Sinon, le initSID.ora
La SGA est alloue et les process dmarrs. Les fichiers de trace et dalertes sont galement ouverts. La seconde tape consiste monter la base de donnes. Cest le mode MOUNT. La base de donnes nest pas encore ouverte et donc non accessible. Ce mode est utilis pour certaines taches de maintenance de la base de donnes. A ce moment, la base de donnes est associe une instance dmarre, le serveur Oracle localise les fichiers de contrle et les ouvres. Ces fichiers sont alors lus pour obtenir le nom et le statut des fichiers de donnes et de redo log. La troisime tape de dmarrage est louverture de la base de donnes. On lappelle galement le mode OPEN ou mode normal de la base de donnes. A ce moment, un utilisateur valide de la base de donnes peut se connecter et accder aux donnes.
Grer une instance
27 / 38
Lors de cette tape finale, le serveur Oracle vrifie que les fichiers de donnes et de redo log puissent tre ouverts. Si louverture de lun dentre eux choue, une erreur est renvoye et la base de donnes nest pas ouverte. La consistance de la base de donnes est galement vrifie pour sassurer que les fichiers de donnes soient bien synchroniss. Si ncessaire, le process darrire plan SMON lance la restauration dinstance. Les derniers checkpoints sont identifis, les fichiers de Rollback et les donnes utilisateurs sont mises jour, les transactions non commites font lobjet dun rollback
3.3.2.Dmarrer une instance

Nous allons voir comment dmarrer de manire pratique une instance. Il est possible au DBA de dmarrer une instance soit par la commande startup soit par le Manager dInstance Oracle.
STARTUP [FORCE] [RESTRICT] [PFILE=Filename] [EXCLUSIVE | PARALLEL | SHARED] [OPEN [RECOVER [database] | MOUNT | NOMOUNT]
Via le Manager dInstance Oracle, il faut se connecter avec les privilges DBA. Il devient alors possible de dmarrer lInstance avec les trois modes NOMOUNT, MOUNT ou OPEN. Il est possible de prciser le fichier de paramtre ou encore douvrir la base de donnes en mode restreint. Sous Windows NT, une instance Oracle est assimile un service. Le service dmarre automatiquement et permet de dmarrer linstance.
3.3.3.Changer la disponibilit de la Base de donnes

Un DBA peut dmarrer une instance Oracle dans lun des trois modes NOMOUNT, MOUNT et OPEN. Ce mode peut tre chang de lun lautre lorsque linstance t lance (de NOMOUT vers MOUNT puis VERS OPEN). Il est possible de le changer soit grce la commande ALTER DATABASE ou grce au Manager dInstance Oracle. En ligne de commande et en mode NOMOUT, il est possible de taper ceci :
ALTER DATABASE {MOUNT | OPEN}
Il est possible dagir sur le mode de la base de donnes laide du Manager dInstance Oracle. On peut par exemple changer ltat de la base de donnes de NOMOUNT MOUNT. Cela se fait laide du menu Base de donnes.
3.3.4.Etapes d'arrt d'une instance

Il y a trois tapes dans le process darrt dune instance et de la base de donnes : La base de donnes est dabord ferme : Lors de cette tape, le serveur Oracle crit tous les changements des buffers caches dans les fichiers de donnes. Tous les buffers de redo log sont crits dans les fichiers de redo log en ligne. Ces mmes fichiers sont ensuite ferms. La base de donnes devient indisponible aux utilisateurs mais les fichiers de contrle restent ouverts. Elle est ensuite dmonte : La base de donnes est ensuite dmonte de son instance Les fichiers de contrle sont ferms leur tour. Linstance est finalement arrte : Les fichiers de traage et dalerte sont ferms. La SGA est dsalloue de la mmoire et les process de tche de fond sont termins.
Grer une instance

3.3.5.Modes d'arrts
28 / 38
Un DBA peut fermer une base de donnes dans lun des quatre diffrents mode disponibles. Ces modes sont : normal, transactionnel, immdiat et abandon. Le mode normal est le mode par dfaut, les connexions la base de donnes deviennent impossibles, toutefois, le serveur Oracle attend que les utilisateurs connects se dconnectent de la base de donnes. Une fois tous les utilisateurs dconnects, le serveur Oracle dmonte et ferme la base de donnes puis linstance. Dans ce mode de fermeture, une restauration de linstance ne sera pas ncessaire au redmarrage. Dans le mode transactionnel, les clients ne peuvent perdre leur travail. Lors de lutilisation de ce mode, aucun utilisateur ne peut lancer une nouvelle transaction. Les clients sont dconnects lorsque leurs transactions en cours se terminent. La base de donnes est ensuite immdiatement ferme. La restauration dinstance ne sera pas ncessaire dans ce mode galement. Le mode darrt immdiat entrane larrt immdiat des requtes SQL en cours, les utilisateurs sont dconnects sans attente. Le serveur Oracle rollback annule les transactions actives. Une restauration de linstance ne sera pas ncessaire. Le mode abandon (ABORT) est utilis seulement lorsque les autres modes ne peuvent fonctionner. (Ce mode est excut lorsque la commande STARTUP FORCE est utilise). Les requtes SQL sont termines et les utilisateurs dconnects, les transactions non commites ne font pas lobjet dun rollback. Le prochain dmarrage de linstance ncessitera une restauration de linstance par SMON. En mode abandon, les fichiers ne sont pas ferms.
SHUTDOWN [NORMAL | TANSACTIONAL | IMMEDIATE | ABORT]
3.4. Vue dynamique des performances

3.4.1.Caractristiques des vues dynamiques de performance
Le serveur Oracle maintient un jeu de tables virtuelles qui enregistre lactivit courante de la base de donnes. Ces tables sont appeles les tables de performances dynamiques. Elles sont visibles pour les utilisateurs via les vues dynamiques de performances. Ces tables appartiennent au DBA et ne sont pas accessibles la plupart des utilisateurs. Les vues sont galement accessibles au DBA qui peut donner le droit daccs dautres utilisateurs. Ces vues sont identifies avec le prfixe V_$ mais le serveur Oracle cr un synonyme public avec le prfixe V$. Les tables sous-jacentes ces vues sont constamment mises jour lorsque la base de donnes est en cours dutilisation. Les informations les plus jours deviennent alors disponibles travers ces vues. Ces vues sont utilises pour fournir des donnes relatives aux performances telles que des informations sur les fichiers de donnes et les structures de la mmoire. Lorsquune instance est dmarre en mode NOMOUNT, seul les vues lisant des donnes de la mmoire sont accessibles. Lorsque la base de donnes est en mode MOUNT, les vues lisant les donnes des fichiers de contrle sont alors accessibles. La vue V$FIXED_TABLE montre les vues dynamiques de performance.
3.4.2.Descriptions des vues dynamiques de performance

Les principales vues accessibles en mode NOMOUNT lisent des donnes de la mmoire et sont les suivantes : V$PARAMETER: Liste les informations sur les paramtres dinitialisation avec leur nom, leur nombre, leur valeur et leur type. V$SPPARAMETER : Liste les informations sur les paramtres dinitialisation du serveur avec leur nom, leur nombre, leur valeur et leur type. V$SGA : Donne des informations rcapitulatives sur la SGA.
Grer une instance

V$OPTION : Liste les options installes avec le serveur Oracle. V$PROCESS : Contient des informations sur les process actifs. V$SESSION : Donne les informations sur la session courante. V$VERSION : Liste le numro de version et les composants du serveur Oracle.
29 / 38
V$INSTANCE : Donne ltat de linstance courante. Les vues lisant les donnes des fichiers de contrle sont accessibles seulement lorsque la base de donnes est monte. Les principales vues sont les suivantes : V$THREAD : Prsente les informations sur les threads des fichiers de contrle tel que les informations sur les groupes de redo log. V$CONTROLFILE : Fournit les noms des fichiers de contrle. V$DATABASE : Contient des informations sur la base de donnes tel que le nom ou la date de cration. V$DATAFILE : Donne les informations sur les fichiers de donnes tel que leur nom, leur statut et dautres dtails. V$DATAFILE_HEADER : Donne des informations sur les en-ttes des fichiers de contrle. V$LOGFILE : Contient des informations sur les fichiers de redo log en ligne
3.5. Paramtres dynamiques

3.5.1.Afficher les valeurs des paramtres courants
Les paramtres dinitialisation contrlent la configuration de linstance et de la base de donnes, il est possible dafficher ces paramtres grce la commande SHOW PARAMETER ou bien via la vue V$PARAMETER. La commande SHOW PARAMETER affiche les informations sur les paramtres de la base de donnes lance. Ils sont prsents par ordre alphabtique avec leur valeur. La commande peut galement afficher un paramtre donn en spcifiant son nom, par exemple :
SHOW PARAMETER control
Il est possible dinterroger la vue V$PARAMETER grce une requte SQL tel que :
SELECT name, value FROM V$PARAMETER WHERE name LIKE %control%;
Il est par ailleurs possible de consulter la valeur des paramtres via le noeud des paramtres dinitialisation dans le Manager dInstance Oracle. Note : Il est ncessaire de redmarrer linstance Oracle pour que les changements apports aux paramtres du fichier init.ora soient effectifs.
3.5.2.Paramtres d'initialisation dynamique

Ces paramtres peuvent tre modifis par : Les commandes SQL:
ALTER SESSION SET <param>=<value> ;
Grer une instance

ALTER SYSTEM SET <param>=<value> [DEFERRED] ;
30 / 38
Soit lon utilise la commande ALTER SESSION pour modifier les paramtres de la session courante, soit lon utilise le ALTER SYSTEM pour toutes les sessions. La valeur devient effective immdiatement et jusqu larrt de linstance. Loption DEFERRED permet de modifier la valeur dun paramtre uniquement pour les sessions venir. On peut vrifier la valeur dun paramtre soit par la vue V$PARAMETER (Pour les paramtres de session) ou V$SYSTEM_PARAMETER (Pour les paramtres systme). Les champs ISSES_MODIFIABLE, ISSYS_MODIFIABLE, ISMODIFIED et ISADJUSTED sont les champs de ces vues concernant le statut de ces paramtres. Le Manager dInstance Oracle : En lanant la console, il faut cliquer sur le nud des paramtres dinitialisation. Les paramtres sont affichs sur la droite et leurs valeur peuvent tre dites.
3.6. Grer les sessions

3.6.1.Activer les modes Restreint et Lecture seule
Lors de la ralisation de tches administratives, la base de donnes peut tre place en mode restreint. Cela peut tre fait au dmarrage et permet de laisser laccs la base de donnes seulement aux utilisateurs ayant le privilge RESTRICTED SESSION. La base de donnes peut tre change en mode restreint via la commande ALTER SYSTEM ou le Manager dInstance Oracle. La commande est la suivante :
{ENABLE | DISABLE} RESTRICTED SESSION
Les sessions en cours ne sont pas dconnectes, le mode restreint ninterviendra que pour les futures connexions. Il est possible de voir les informations sur le mode restreint, en utilisant la vue V$INSTANCE. Dans le Manager dInstance Oracle, il faut utiliser le menu Session et slectionner loption Restrict. Il faudra choisir loption Allow All pour revenir en mode normal. Il est galement possible douvrir la base de donnes en mode Lecture seule. Les utilisateurs peuvent alors accder aux donnes, mais ne peuvent les modifier. Pour cela, on peut utiliser la commande SQL suivante :
ALTER DATABASE OPEN READ ONLY
3.6.2.Terminaison de Session
Lors de certaines tches administratives, le DBA doit parfois dconnecter les utilisateurs en cours. En effet, les modes restreints vus prcdemment ne dconnectent pas les sessions en cours. La commande SQL suivante dconnectera les utilisateurs ayants des sessions en cours :
ALTER SYSTEM KILL SESSION 'SID, SERIAL#' [POST_TRANSACTION]
Les paramtres sont le SID et le numro de srie ils permettent eux deux didentifier une session de manire unique. On peut les retrouver en consultant la vue V$SESSION. Il est galement possible de mettre fin une session via le Manager dInstance Oracle. Le noeud concern est le noeud Sessions, il est possible de mettre fin lune delle en cliquant dessus pour la slectionner, puis en slectionnant dans le menu Session, le sous-menu Disconnect et soit Immediate, soit Post Transaction. Lorsquune session est termine, le process de tche de fond PMON rollback annule la transaction courante. Toutes les tables et les enregistrements verrouills sont librs. Le message ORA-00028 est
Grer une instance

envoy lutilisateur pour linformer de la fin de la session. La colonne STATUS de la vue V$SESSION est marque comme killed.
31 / 38
3.7. Configuration dOracle Managed Files (OMF)

OMF est gr par le SGBD et permet de simplifier ladministration en liminant le besoin de grer directement les fichiers dans la base de donnes, notamment ceux de contrle, de donnes, et de redo logs. OMF cre un nom unique pour chaque fichier et se charge de les supprimer automatiquement en cas de suppression logique. Ainsi, les rpertoires physiques sont grs par 2 paramtres dynamiques : DB_CREATE_FILE_DEST : utilis pour les fichiers de donnes Db_CREATE_ONLINE_LOG_DEST_N (1<=n<=5) : utilis pour les fichiers de contrle et les redo logs. La commande suivante peut tre lanc pour dfinir le premier paramtre :
ALTER SYSTEM SET db_create_file_dest =/oracle/dbs/files;
Si seul le premier paramtre est initialis, alors tous les fichiers (contrle, donnes et redo) seront localiss dans le mme rpertoire Crer une base de donnes o les fichiers de donnes, de contrles et les redo log sont crs dans des rpertoires spars : La premire tape consiste crer larborescence pour les fichiers de paramtres :
DB_CREATE_FILE_DEST = /u01/oradata DB_CREATE_ONLINE_LOG_DEST_1 = /u02/oradata/ DB_CREATE_ONLINE_LOG_DESt_2 = /u03/oradata/
Le paramtre DB_CREATE_FILE_DEST initialise le rpertoire par dfaut pour les fichiers de donnes. Les paramtres DB_CREATE_ONLINE_LOG_DEST_1 et DB_CREATE_LOG_DEST_2 initialise les rpertoires pour les fichiers de redo log et les fichiers de contrles. La dernire tape consiste crer la base de donnes en elle-mme.
3.8.Fichier de Log et d'Alertes

3.8.1.Fichiers de Log
Les fichiers de Log et dAlerte permettent au DBA de maintenir et daugmenter les performances du serveur Oracle. Les fichiers de trace sont utiliss pour consigner les erreurs internes. Elles contiennent galement des informations pour tuner les applications et les instances. Ce sont les process de fond qui inscrivent les erreurs dtectes dans ces fichiers. Les process serveur peuvent tre galement tracs si le traage SQL est activ. On peut activer le traage SQL selon les deux mthodes suivantes :_ Placer la valeur du paramtre dinitialisation SQL_TRACE TRUE en utilisant la commande SQL :
ALTER SESSION SET sql_trace=TRUE;
Le paramtre dinitialisation BACKGROUND_DUMP_DEST spcifie le chemin des fichiers de trace gnr par le process darrire plan.
Grer une instance
32 / 38
Le paramtre dinitialisation USER_DUMP_DEST spcifie le chemin des fichiers de trace gnrs par les process serveur. La taille des fichiers de trace est spcifie par le paramtre MAX_DUMP_FILE_SIZE.
3.8.2.Fichiers d'Alerte
Les fichiers dalerte de la base de donnes sont un archivage chronologique des messages et des erreurs. Sous Windows NT, le fichier est nomm <SID>ALRT.LOG et alert_<SID>.log sous UNIX. Ces fichiers sont crs lors du dmarrage de la base de donnes sils nexistent pas. Ces fichiers permettent de contrler si une instance fonctionne normalement, les erreurs se produisant lors de son fonctionnement sont crites dans ces fichiers. Le chemin de ces fichiers est spcifi par le paramtre BACKGROUND_DUMP_DEST. Par dfaut, le chemin sous Windows NT est %ORACLE_HOME%\RDBMS\TRACE et $ORACLE_HOME/rdbms/log sous UNIX. Leur maintenance doit tre faite la main. Ainsi, leur sauvegarde et leur suppression sont la charge du DBA. Ils peuvent tre supprims mme lorsquune instance est lance. Les informations contenues dans ces fichiers contiennent toutes les informations sur les erreurs internes, les blocs corrompus, et les erreurs de deadlock (verrous morts). Les oprations Oracle affectant les structures et les paramtres, de la base de donnes, sont galement consignes. On retrouve galement les actions telles que le lancement ou larrt dune instance ou encore les paramtres dinitialisation dont la valeur n'est pas la valeur par dfaut.
Grer une instance
33 / 38
4.National Language SuppOrt (NLS)

4.1.Jeu de caractres
4.1.1.Caractristiques d'NLS
Le support national de langage permet aux utilisateurs dinteragir avec une base de donnes dans leur langue dorigine et de lancer des applications dans des environnements comportant diffrents langages. NLS permet aux utilisateurs dinteragir, de stocker, dinterroger et de manipuler des donnes dans leur langue dorigine. Il est inclus le support de langues tel que celles dEurope de lOuest, de lEurope de lEst, de lEurope Centrale ou de lAsie. Les jeux de caractres sont galement propres diffrents pays ou rgions. Des jeux de caractres sur un bit, plusieurs bits variant ou plusieurs bits fixes sont supports par NLS. Des squences de tri correctes sont galement disponibles pour les diffrentes langues. La traduction des messages derreurs et des interfaces des utilitaires est galement assure dans plus de 40 langues. Les formats de date et dheure sont galement permis en accord avec les standards ISO. Les calendriers tel que le calendrier Grgorien, Japonais, Imprial, et Thai Budda sont galement supports. Les valeurs numriques sont galement reprsentes dans le format local appropri. Les symboles montaires, les crdits et les dbits sont galement supports selon les normes ISO selon les pays. Cependant, les mots cls sont uniquement spcifis en anglais. De mme, le jeu de caractres de la base de donnes ne peut tre de longueur fixe sur plusieurs caractres. Note : Les jeux de caractres de longueur variable stockent les donnes de manire plus efficace que les jeux de caractres de longueur fixe.
4.1.2.Plans d'encodage de caractres

Laffichage dun caractre sur une station de travail dpend des conventions de reprsentation qui sont supportes par celle-ci. Le code numrique spcifi pour un caractre dfini le plan dencodage de caractres. Plusieurs types dencodage de caractres sont disponibles : Bit simple : Chaque caractre occupe un bit (Utilis pour lEurope et les langues du moyen Orient). Ils sont cods sur 7 ou 8 octets. Sur 7 octets, il est possible de coder jusqu 128 caractres, ce qui permet de coder lalphabet. Sur 8 octets, jusqu 256 caractres sont utiliss, cela permet de coder plusieurs langues telles que celles de lEurope de lOuest. Bit multiple longueur variable : Un caractre est cette fois-i cod sur un ou plusieurs bits tel que pour les langues asiatiques. Longueur fixe bits multiples : Les informations stockes sont similaires au prcdent type de codage, il est seulement toujours utilis le mme nombre de bits pour lencodage. Unicode : Cest un codage qui reprsente la totalit des caractres informatiques possible, ainsi que les caractres de symboles techniques et de publication. 38 885 caractres sont reprsents. Les deux principaux formats sont lUCS2 (Deux bits fixes) et lUTF8 (Longueur variable).
Grer une instance

4.1.3.Caractristiques du jeu de caractres
34 / 38
Lors de la cration dune base de donnes, vous devez slectionner des jeux de caractres adapts votre base de donnes. Il est tout dabord prfrable de slectionner un jeu de caractres correspondant au plan dencodage de caractres supports par le systme dexploitation. Il peut toutefois tre diffrent de celui-ci. Une base de donnes Oracle utilise un jeu de caractres de la base de donnes et un jeu de caractres National. Ces deux jeux de caractres sont configurs lors de la cration de la base de donnes et ne peuvent tre changs ensuite. Ils ont les caractristiques suivantes : Jeu de caractres de la base de donnes Dfini la cration de la base de donnes. Jeu de caractres National Dfini la cration de la base de donnes.
Donnes des colonnes stockes pour les types CHAR, VARCHAR2, CLOB et LONG.
Donnes des colonnes stockes pour les types NCHAR, NVARCHAR2 et NCLOB (Le type LONG nest pas support). Stocke les jeux de caractres encods sur plusieurs bits en taille variable. Stocke les jeux de caractres encods sur plusieurs bits de taille fixe.
Stocke les jeux de caractres encods sur plusieurs bits en taille variable.
Les considrations suivantes sont prendre en compte pour choisir les jeux de caractres : Slectionner un jeu de caractres proche pour celui de la base de donnes et le National. Evaluer les performances pour les oprations sur les chanes de caractres. Les recherches et comparaisons sur les chanes de caractres sont plus rapides si lencodage du jeu de caractres est fixe pour le jeu de caractres national. Ne pas oublier que les jeux de caractres encods sur une taille variable sont plus conomes en place.
4.2.Comportement dpendant du langage

4.2.1.Paramtres NLS ct serveur
Les paramtres NLS permettent de spcifier la langue, les noms de mois et des jours, le symbole de la monnaie locale, et dautres attributs. Il est possible de configurer ces paramtres selon trois mthodes : Via les paramtres dinitialisation : Il est possible de configurer via les paramtres dinitialisation un comportement par dfaut dpendant du langage pour le serveur. Cette configuration naura pas dimpact sur les clients. Via les variables denvironnement : En configurant un langage via les variables denvironnement, il est possible de configurer le comportement dune session cliente et de prendre le pas sur la configuration du serveur. Via la commande ALTER SESSION : Elle permet de configurer le langage soit pour la session, soit pour le serveur. Les paramtres dinitialisation sont :
Grer une instance
35 / 38
NLS_LANGUAGE : pour les messages derreur serveur. Les messages sont stocks dans des fichiers binaires et sont nomms selon la convention <Nom de produit><ID de langage>.MSB (Par exemple ORAF.MSB pour un Oracle Franais). Ce paramtre agit sur : La langue des mois et jours dans une date. Les symboles pour les heures et les sicles. Le tri alphabtique du jeu de caractres. NLS_TERRITORY : Il dfinit les caractristiques pour : Les caractristiques du formatage des dates et des nombres. Les symboles montaires et ISO. Les caractres dcimaux, les sparateurs de groupes, de listes, le jour de dbut de la semaine, le symbole des crdits et dbits, et le calcul ISO des numros de jour. Ils peuvent tre configurs via le fichier de paramtres dinitialisation ou bien par la commande ALTER SESSION.
4.2.2.Paramtres NLS drivs

Les paramtres NLS drivs permettre doutrepasser la configuration par dfaut des paramtres tels que NLS_LANGUAGE et NLS_TERRITORY. Les paramtres drivs de NLS_LANGUAGE sont : NLS_DATE_LANGUAGE pour laffichage des jours et des mois. NLS_SORT pour le tri des caractres. Les paramtres drivs de NLS_TERRITORY sont : NLS_CURRENCY pour le symbole montaire local renvoyer pour le masque L. NLS_ISO_CURRENCY pour le symbole montaire local ISO renvoyer pour le masque C. Par exemple, le symbole montaire ISO pour le dollar amricain est USD ou AUD pour le dollar australien. NLS_DATE_FORMAT pour le format du masque de date utilis avec les fonctions TO_CHAR et TO_DATE, il doit tre mis entre double guillemets. NLS_NUMERIC_CHARACTERS dfinit le caractre dcimal (Qui spare la partie entire de la partie dcimale dun nombre) et le sparateur de groupes (Qui spare les groupes dentier pour les milliers, les millions, etc. Ces deux caractres doivent tre diffrents et les oprateurs arithmtiques ainsi que les nombres ne sont pas autoriss. Ces paramtres sont modifiables via les paramtres dinitialisation, les variables denvironnement ou la commande ALTER SESSION et permettent de contourner les valeurs par dfaut.
4.2.3.Contourner le comportement par dfaut NLS

Le serveur Oracle supporte un environnement htrogne dans le cas o les clients et le serveur nutilisent pas les mmes jeux de caractres. Le jeu de caractres utiliser par un client pour une session peut tre configur via le paramtre NLS_LANG. La valeur de cette variable contourne les valeurs par dfaut des paramtres dinitialisation. Le paramtre NLS_LANG se compose de trois composants : Le langage, le territoire et le jeu de caractres. Sa syntaxe est la suivante :
NLS_LANG = <langue>_<Territoire>.<Jeu de caractres>
Ce paramtre fixe les conventions pour les messages serveur et laffichage des jours et des mois.
Grer une instance
36 / 38
Langue : Chaque nom de langue dans Oracle se nomenclature avec leur nom anglais, par exemple : American, French ou German. La valeur par dfaut est langlais amricain. Il contourne le paramtre NLS_LANGUAGE. Territoire : Il spcifie des valeurs pour le format par dfaut de date ou numrique et passe outre le paramtre NLS_TERRITORY. Les valeurs sont par exemple America, France ou Canada et la valeur par dfaut est lamrique. Jeu de caractres : Il spcifie le jeu de caractres pour le client sur son poste de travail. Cest un acronyme de la forme US7ASCII ou WE8ISO8859P1. Il est possible de modifier la valeur de cette variable denvironnement sous Windows NT via longlet des paramtres denvironnement dans les Proprits Systmes . Dautres variables denvironnement peuvent tre spcifies pour une station cliente : NLS_LANG NLS_CREDIT NLS_DEBIT NLS_DISPLAY NLS_LIST_SEPARATOR NLS_MONETARY NLS_NCHAR
4.2.4.Comportement dpendant du langage pour une session

Il est possible de contrler la valeur par dfaut du langage et du territoire en utilisant la commande ALTER SESSION. Une commande ALTER SESSION implicite est ralise lors du dmarrage dune session. Ces appels implicites positionnent les variables NLS_LANGUAGE et NLS_TERRITORY avec les valeurs des variables stockes dans NLS_LANG. De plus, il est possible de changer ces variables en utilisant la commande ALTER SESSION comme suit :
ALTER SESSION <territoire> ; SET NLS_LANGUAGE = <langue> NLS_TERRITORY =
4.2.5.NLS et le tri
Pour raliser un rsultat tri selon la convention de langage supporte par la station de travail, le serveur Oracle propose un mcanisme de tri linguistique. Le mcanisme de tri conventionnel est le tri binaire. Dans ce cas, le tri est ralis selon la valeur binaire des caractres qui est dfini par le plan dencodage des caractres propre la station de travail. Cependant, lordre alphabtique des caractres peut varier dun langage lautre. Lordre des caractres aprs un tri binaire peut donc parfois ne pas correspondre lordre alphabtique de la langue. Pour parer ce problme, Oracle dispose dun mcanisme de tri linguistique. Ce tri linguistique est li au paramtre NLS_SORT qui peut passer outre la variable NLS_LANGUAGE. Par exemple, lallemand a son propre ordre de tri nomm GERMAN . Le tri linguistique nest pas support pour les caractres encods sur des longueurs de bit variables. La commande suivante permet de positionner la variable avec la valeur souhaite :
ALTER SESSION SET nls_sort = <langue>
Le paramtre dinitialisation NLS_COMP permet de contrler le comportement des oprateurs de comparaison face lordonnancement des langues. La valeur par dfaut est binaire, mais elle peut tre passe ANSI pour utiliser le tri linguistique.
Grer une instance

4.2.6.Paramtres NLS dans les fonctions SQL
Il est parfois ncessaire de raliser des requtes SQL indpendantes du langage. Les fonctions SQL suivantes peuvent utiliser avec leurs paramtres NLS correspondants : Fonctions SQL TO_DATE TO_NUMBER TO_CHAR Paramtre NLS NLS_DATE_LANGUAGE NLS_CALENDAR NLS_NUMERIC NLS_CURRENCY NLS_ISO_CURRENCY NLS_DATE_LANGUAGE NLS_NUMERIC NLS_CURRENCY NLS_ISO_CURRENCY NLS_CALENDAR NLS_SORT
37 / 38
NLS_UPPER, NLS_LOWER, NLS_INITCAP, NLSSORT Exemple :
SELECT TO_CHAR(hiredate, dd.mm.yyyy, NLS_DATE_LANGUAGE=GERMAN) FROM emp; SELECT ename, TO_CHAR(99G999D99, NLS_NUMERIC_CHARACTERS=:,);
Note : Les paramtres suivants ne sont pas pris en compte dans les fonctions SQL : NLS_LANGUAGE, NLS_TERRITORY, NLS_DATE_FORMAT.
4.3.Information du dictionnaire de donnes

4.3.1.Obtenir des informations sur les jeux de caractres
Il est possible dutiliser la vue NLS_DATABASE_PARAMETERS pour consulter les informations sur les jeux de caractres courants de la base de donnes.
Grer une instance
38 / 38
Figure 4-3-1 Les paramtres considrer sont NLS_CHARACTERSET et NLS_NCHAR_CHARACTERSET. La requte SQL suivante permettra dafficher les informations sur ces variables :
SELECT parameter, value FROM nls_database_parameters WHERE parameter LIKE %CHARACTERSET%;
4.3.2.Obtenir des informations sur les configurations NLS

Les vues suivantes permettent de rcolter des informations sur la configuration NLS courante : NLS_INSTANCE_PARAMETERS : Cest une vue du dictionnaire affichant les paramtres NLS explicitement initialiss dans le fichier de paramtres. NLS_SESSION_PARAMETERS : Cest une vue du dictionnaire affichant les paramtres de session NLS. V$NLS_VALID_VALUES : Cette vue permet de rcuprer les paramtres NLS valides tel que LANGUAGE, SORT, TERRITORY et CHARACTERSET. V$NLS_PARAMETERS : Cette vue permet dafficher les valeurs courantes des paramtres NLS.

Module 1 DBA 1 9i

Transféré par

Informations du document

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

Module 1 DBA 1 9i

Transféré par

Droits d'auteur :

Formats disponibles

Grer une instance

Auteur : Mathieu Musard

Grer une instance

Table des matires

Grer une instance

Grer une instance

1.Composants de larchitecture Oracle

1.2. Connexion a un serveur Oracle

Grer une instance

Grer une instance

1.3. Instance Oracle et Base de donnes

Grer une instance

1.3.3.Processus d'arrire plan

Grer une instance

1.3.4.Fichiers de la base de donnes

1.3.5.Fichiers relatant la Base de donnes

Grer une instance

1.4. Traitement de requtes

1.4.2.Pool partag (Shared Pool)

Grer une instance

1.4.3.Buffer de Cache de la base de donnes (Database Buffer Cache)

1.4.4.Buffer de Redo Log

1.4.5.Program Global Area (PGA)

Grer une instance

1.5. Traitement de requtes DML

Grer une instance

1.5.3.Database Writer (DBWn)

Grer une instance

1.5.4.Log Writer (LGWR)

Grer une instance

1.6. Traitement dun commit

1.6.2.Traitement d'un COMMIT : Etapes

Grer une instance

1.6.3.Traitement d'un COMMIT RAPIDE (Fast Commit)

Grer une instance

Grer une instance

2.1.2.Optimal Flexible Architecture (OFA)

Larborescence ci-dessus montre une structure de stockage selon le modle OFA.

2.2. Oracle Entreprise Manager (OEM)

Grer une instance

2.2.2.Composants de la console OEM

Grer une instance

2.3. Package d'administration

Grer une instance

2.3.2.Packs de management supplmentaires

Grer une instance

Grer une instance

3.Grer une Instance Oracle

3.1.1.Configurer lauthentification par le systme dexploitation

Grer une instance

3.2.2.Le PFILE (initSID.ora)

Grer une instance

3.2.3.Le SPFILE (spfileSID.ora)

Grer une instance

3.2.4.Rgles pour les valeurs de paramtre

Grer une instance

3.2.6.Paramtres communment modifis

3.3. Dmarrage et arrt d'une instance

Grer une instance

3.3.2.Dmarrer une instance

3.3.3.Changer la disponibilit de la Base de donnes

3.3.4.Etapes d'arrt d'une instance

Grer une instance

3.4. Vue dynamique des performances