INSIA – SIGL Bases de données
ARCHITECTURE ORACLE
http://st-curriculum.oracle.com/tutorial/DBXETutorial/index.htm http://st-curriculum.oracle.com/
Bertrand LIAUDET
ARCHITECTURE ORACLE 3
Méthodes de connexion 3
La connexion 3
Les fichiers oracle 4
Structure des fichiers de la BD 4
Problème conceptuel : la notion de base de données, BD 5
Architecture de l’instance 5
Les processus d’arrière-plan et le processus serveur 6
La mémoire : SGA et PGA 6
Le shared pool (pool partagé) 7
Le buffer cache 7
Principe 7
Notion de bloc oracle 7
Bloc oracle et buffer cache 8
L’exécution d’un requête 8
Principe 8
Le buffer redo log : tampon des journaux de reprise 10
Le java pool 10
Les processus d’arrière plan 10
DBWn : DataBase Write 10
LGWR 10
ARCn 10 CKPT 11
SMON 11
PMON 11
Gestion des processus : vue v$session – v$process 11
Les fichiers d’alerte (alert.log) et de trace (.trc) 12
Principe 12
Localisation 12
Ménage des fichiers de trace ! 12
Remarque sur les erreurs 12
Le LISTENER 13
Le contrôleur du Listener : LSNRCTL 13
INSTANCE ET BD 14
Gestion d’une instance 14
Notion d’instance 14
Utilisateur SYS et SYSTEM 14
Le fichier de paramètres : PFILE 16
Le fichier de paramètres serveur : SPFILE 17
Création d’une instance : utilitaire ORADIM 18
Démarrage et arrêt d’une instance et d’une BD 19
Les vues dynamiques 20
Gestion d’une BD 22
Notion de BD 22
Les fichiers de la BD 22
Création manuelle d’une BD : CREATE DATABASE 22
Création du dictionnaire 23
Changer d’instance pour une BD 23
Sauvegarder : lister tous les fichiers de la BD 24
DICTIONNAIRE 25
Dictionnaire et dictionnaire des données 25
Présentation 25
La vue « dictionnary » ou le synonyme « dict » 25
Dictionnaire des données 26
Premiers usages du dictionnaire des données 26
Les vues du dictionnaires des données 27
Les 3 catalogues 27
Les différents objets 27
Accès aux statistiques 27
Les utilisateurs et leurs privilèges 27
CONTROLE, JOURNAUX ET UNDO 29
Les fichiers de contrôle 29
Les fichiers de journaux 29
Présentation 29
Gestion de base 29
Le segment UNDO 31
TABLESPACE 32
LES ASSISTANTS ORACLE 32
Oracle Net 32
OEM : Oracle Entreprise Manager 32
L’assistant DBCA 32
TP 33
Installation d’une instance 33
ARCHITECTURE ORACLE
Méthodes de connexion
1) client-serveur mono-machine.
2) client-serveur multi-machines. Le lien entre le client et le serveur est assuré par le middleware comprenant Oracle Net et le protocole de communication, généralement TCP/IP.
3) Architecture double serveurs : client – serveur d’application – serveur de BD.
Le protocole de communication client-serveur d’application est indépendant du protocole serveur d’application-serveur de BD.
4) Architecture triple serveurs : client – serveur web – serveur d’application – serveur de BD.
Le client exécute un navigateur qui communique avec le serveur web via le protocole HTTP.
Ce dernier demande l’exécution des commandes du client au serveur d’applications. Ce dernier est client de la BD et formate les résultats en HTML avant de les retourner au client.
5) Architecture multi serveurs de BD : client – serveur de BD – serveur de BD. Les BD se situent sur des serveurs séparés et se partagent les données.
La connexion
Le client est un processus utilisateur (SQL*Plus, une application, etc.) Pour se connecter, il faut un nom et un mot de passe.
C :> sqlplus nomUtilisateur / password SQL > show user
User est : “NomUtilisateur”
C :> sqlplus / nolog SQL > show user User est : “”
Il existe deux sortes de processus serveurs (oracle.exe) :
• les serveurs dédiés
• les serveurs partagés
Le principe du serveur dédié est que chaque utilisateur est pris en charge par un serveur dédié.
Le principe du serveur partagé est que plusieurs utilisateurs partagent le même serveur. Un processus DISPATCHER gère l’ordonnancement des requêtes des utilisateurs. Par défaut, les serveurs sont partagés.
Les fichiers oracle
Les fichiers oracle sont les suivants :
• Les fichiers de la BD :
1. Les fichier de données : les plus volumineux. Fichiers binaires.
2. Les fichiers de contrôle : fichier binaires qui décrivent tous les fichiers oracle.
3. Les fichier journaux (redo-log) : ces fichiers conservent les modifications successives de la BD. Ce sont des journaux de transactions de la base. Ils servent pour une restauration de la BD.
• Le fichier de paramètres : paramètres de démarrage qui déterminent l’environnement.
• Le fichier de mot de passe : pour établir l’authenticité des utilisateurs privilégiés..
• Les fichiers journaux archivés : les fichier journaux fonctionnent de façon circulaire. Les fichiers journaux archivés sont des copies des fichiers journaux avant leur réutilisation par circularité.
Structure des fichiers de la BD
STRUCTURE LOGIQUE
STRUCTURE PHYSIQUE
* 1
* 1
* 1
* 1
*
1
* *
T ABLES, INDEX, CLUST ERS, T ABLESPACES BASES DE DONNEES
FICHIERS SCHEMAS
Niveau logique :
Les objets de la BD (tables, indexs, etc.) appartiennent à un schéma et à un tablespace.
Schéma et tablespace appartiennent à une BD.
Le schéma peut être réparti dans plusieurs tablespace. Un tablespace peut contenir plusieurs schémas.
Niveau physique :
Un fichier correspond à un tablespace, mais un tablespace peut être réparti sur plusieurs fichiers.
Rappel sur les objets logiques de la BD :
• Tables, vues, procédures, fonctions, déclencheurs (triggers), packages (regroupements de procédures et de fonctions)
• Tables temporaires : créée le temps d’une session ou d’une transaction.
• Clusters : Un cluster est constitué par plusieurs tables stockées physiquement ensemble.
L’objectif est d’optimiser les temps de traitement en lecture-écriture.
• Index : table triée pour accéder aux données. Il existe des index de table, de clusters et bitmap (pour les attributs avec peu de valeurs distinctes).
• Tables organisées en index : toute la table est indexée à partir de sa clé primaire.
• Séquences : pour gérer les auto-incréments
• Vues matérialisées : pour synthétiser, répliquer ou distribuer des données.
• Synonymes : pointeur vers n’importe quel objet
• Liens de BD : pointeur vers n’importe quelle BD.
Problème conceptuel : la notion de base de données, BD Le terme BD est polysémique : il peut se rapporter à :
1. L’instance (mémoire vive) et les fichiers physiques de la base (au SGBD et à la BD), c’est-à- dire la totalité de la mémoire (vive et fichiers) utilisée par la BD.
2. La structure logique des données.
3. Les fichiers de données de la BD.
L’usage le plus courant est le premier.
Architecture de l’instance
Une instance est l’ensemble des :
• processus d’arrière-plan
• zones mémoires allouées
qui permettent l’exploitation d’une base de données.
Show parameter INSTANCE_NAME
Généralement, le nom de l’instance (SGBD) et de la BD (de la structure logiques) sont identiques.
Les processus d’arrière-plan et le processus serveur
Ce sont les processus qu’Oracle utilise, en plus du serveur, pour gérer la BD.
Le processus serveur prend en charge les requêtes des processus utilisateurs (SQL-Plus, applications, etc.)
Les processus d’arrière-plan ont chacun une tâche déterminée pour la gestion des données : écriture sur disques, calcul, gestion mémoire, etc.
La mémoire : SGA et PGA le SGA
Quand on interroge une BD, les données des fichiers sont chargées en mémoire. Oracle gère la mémoire pour améliorer les performances.
Le SGA (System Global Area) est la principale zone mémoire employée.
Le SGA contient particulièrement :
• Un shared pool (pool partagé)
• Un buffer cache
• Un buffer redo-log
• Un java pool
La taille maximum du SGA peuvent être paramétrée dans le fichier de paramètres. Elle n’est pas modifiable dynamiquement.
Show parameter SGA_MAX_SIZE
La taille de chaque composant mémoire peuvent être paramétrée dynamiquement.
Show parameter SHARED_POOL_SIZE Show parameter DB_CACHE_SIZE Show parameter LOG_BUFFER
Alter system set SHARED_POOL_SIZE = 10M
L’augmentation de la taille des composants mémoire permet une amélioration des performances.
le PGA
Le PGA (Program Global Area) est la zone mémoire allouée pour le fonctionnement de chaque processus utilisateur.
Le PGA contient :
• Un buffer pour la gestion des tris
• Un buffer pour les informations de la session
• Un buffer pour les curseurs
• Un buffer pour les variables utilisées par la session
A noter que les buffers de tri et de session sont dans le PGA si le serveur est dédié et dans le shared pool si le serveur est partagé.
Le shared pool (pool partagé)
Le shared pool est une zone mémoire du SGA est constitué de :
• Le cache du dictionnaire des données
• Le cache de bibliothèque
• Le cache de tri et de session (UGA : user global area).
Le cache du dictionnaire des données permet de stocker les données du dictionnaire des données (comptes utilisateur, fichiers de données, tables, privilèges). Ce cache se remplit au fur et à mesure de l’utilisation de la BD. Quand il est plein, l’algorithme de gestion retire les données dont l’utilisation est la plus ancienne : algorithme LRU (Least Recently Used) de gestion de file (on cherche dans la file l’élément cherché. S’il n’y ait pas, on le récupère dans les fichiers. Dans tous les cas, on le sort de la file pour le ré-enfiler. Si la file est pleine, on défile un élément).
Le cache de bibliothèque permet de stocker les plans d’exécution des requêtes les plus courantes. Il est géré par un algorithme LRU.
Le cache de tri est de session permet de gérer les ordres de tri et les informations de session dans le cas d’un serveur partagé. Si le serveur est dédié, le shared pool ne contient plus cette mémoire qui se retrouve dans la PGA.
Le buffer cache
Principe
Le buffer cache est une zone mémoire du SGA qui permet de stocker les données des requêtes de consultation et de modification ( Select et DML ). Le buffer cache permet donc de limiter les accès disque.
Notion de bloc oracle Présentation
Un bloc oracle est une structure logique de données qui contient des enregistrements d’une table. La taille d’un bloc oracle est un multiple du bloc physique manipulé par l’OS.
Le bloc oracle permet de faciliter les échanges entre les fichiers, la mémoire et les processus.
*
1
STRUCTURE LOGIQUE
STRUCTURE PHYSIQUE
* 1
* 1
* 1
* 1
* 1
* 1
*
1
* *
BLOCS ORACLE TABLES, INDEX, CLUST ERS,
TABLESPACES BASES DE DONNEES
FICHIERS
BLOCS OS SCHEMAS
Taille du bloc oracle
Une fois la BD créée, la valeur du DB_BLOCK_SIZE ne peut plus être modifiée (en KO).
Pour visualiser le DB_BLOCK_SIZE :
Show parameter DB_BLOCK_SIZE
L’augmentation de la valeur du BD_BLOCK_SIZE limite les accès disques.
Bloc oracle et buffer cache
Le buffer cache contient les blocs oracle où sont stockés les données des requêtes SQL (Select et DML).
Il est géré par un algorithme LRU (Least Recently Used, gestion de file).
La taille du buffer cache est un paramètre important de l’optimisation.
Généralement, ce cache représente 1 à 2% de la taille de la BD.
L’exécution d’un requête
Principe
L’exécution d’une requête se fait en trois temps
• L’analyse (« parse »)
• L’exécution
• La récupération des résultats (« fetch ») L’analyse : « parse »
L’analyse consiste d’abord à vérifier la syntaxe et les contrôles de sécurité (droits d’accès aux données).
L’analyse consiste ensuite à chercher si l’instruction, son arbre d’exécution et son plan d’exécution sont déjà dans le cache de librairie. Si ce n’est pas le cas, l’analyse va produire l’arbre et le plan d’exécution et les mettre dans le cache de librairie.
Ensuite le processus serveur valide l’existence des objets et de la requête (tables, vues, etc.) et de leurs composants (attributs, etc.), les droits de l’utilisateur à partir des informations du cache du dictionnaire des données si possible ou à partir des fichiers de données sinon.
L’exécution
L’exécution consiste à appliquer le plan d’exécution. Le processus détermine les blocs qui doivent être chargés à partir des fichiers, en accès direct par indexation ou en accès séquentiel.
Les blocs qui ne sont pas déjà dans le cache sont chargés et mis dans le buffer cache. Le calcul (filtre des lignes et des colonnes) est effectués à partir des données des blocs du buffer cache.
La récupération des résultats : « fetch »
Le processus serveur renvoie les lignes sélectionnées et mise en forme.
Le buffer redo log : tampon des journaux de reprise
Le tampon des journaux de reprise permet d’assurer la cohérence du système même en cas d’échec.
En cas de modifications des structures ou des données (DDL ou DML), le processus de traitement écrit dans le tampon des journaux de reprise l’image des lignes avant la modifications.
Ce tampon est de petite taille et utilisé de manière circulaire.
Le java pool
L’initialisation du moteur Java dans la base de données Oracle est facultative.
Si le moteur Java est installé, le Java pool est obligatoire et stocke les commandes java pré- analysées.
Les processus d’arrière plan
Les processus d’arrière plan gère les relations entre les buffers et les fichiers ainsi que les processus eux-mêmes.
DBWn : DataBase Write
Processus d’écriture par lots des blocs de données modifiées du buffer cache dans les fichiers de la BD.
Buffer Cache ---> DBWn ---> Fichier de données ---> LGWR
L’écriture se fait par lots : donc certains événements déclenche cette écriture : toutes les 3 secondes, au delà d’un certain nombre de blocs modifiés, à chaque checkpoint (processus CKPT), etc.
Le processus DBWn lance d’abord un processus LGWR
LGWR
Processus d’écriture séquentielle par lots des entrées du buffer redo log dans les fichiers journaux.
Buffer Redo Log ---> LGWR ---> Fichier journaux
C’est le processus LGWR qui maintient l’état le plus à jour de la BD (et pas le processus DBWn). L’écriture du buffer redo log doit donc être terminée pour valider une transaction.
L’écriture se fait par lots : toutes les 3 secondes, à chaque COMMIT, au delà d’un certain taux de remplissage du buffer redo log, , à chaque chedkpoint, par le processus DBWn.
ARCn
Le processus ARCn s’occupe de copier un fichier journal plein dans un fichier journal archivé.
Ce n’est pas un processus obligatoire.
CKPT
Le processus checkpoint gère les points de synchronisation dans la BD qui faciliteront sa récupération en cas de défaillance.
Il signale l’échéance de déclenchement au processus DBWn (toutes les 3 secondes) et commence par mettre à jours l’en-tête des fichiers de données.
CKPT ---> Fichier de données ---> DBWn
SMON
Le processus SMON assure le monitoring (la surveillance) du système.
Il se charge particulièrement des redémarrage après un arrêt brutal.
Il se charge aussi de faire le ménage dans la mémoire : mémoire des tris, regroupement des espaces libres des fichiers de données.
PMON
Le processus PMON assure le monitoring des processus utilisateur défaillant.
Gestion des processus : vue v$session – v$process consultation
SQL> column sid format 9999 SQL> column username format a12 SQL> column machine format a18 SQL> column program format a20
SQL> select sid, serial#, username, machine, program from v$session;
SID SERIAL# USERNAME MACHINE PROGRAM
--- --- --- --- --- 25 1 LIAUDET ORACLE.EXE (q000) 29 5 BERTRAND MSHOME\LIAUDET sqlplus.exe
31 23 SYS MSHOME\LIAUDET sqlplus.exe
33 1 LIAUDET ORACLE.EXE (QMNC) 36 3 LIAUDET ORACLE.EXE (MMON) 37 5 LIAUDET ORACLE.EXE (q001) 39 1 LIAUDET ORACLE.EXE (MMNL) 41 1 LIAUDET ORACLE.EXE (CJQ0) 42 1 LIAUDET ORACLE.EXE (RECO) 43 1 LIAUDET ORACLE.EXE (SMON) 44 1 LIAUDET ORACLE.EXE (CKPT) 45 1 LIAUDET ORACLE.EXE (LGWR) 46 1 LIAUDET ORACLE.EXE (DBW0) 47 1 LIAUDET ORACLE.EXE (MMAN) 48 1 LIAUDET ORACLE.EXE (PSP0) 49 1 LIAUDET ORACLE.EXE (PMON)
16 ligne(s) sélectionnée(s).
Ici, on voit que deux clients sqlplus sont connectés.
On voit aussi les processus d’arrière plan du serveur oracle.exe : DBW0, LGWR, etc.
La liste des processus d’arrière plan peut être obtenue par la commande :
SQL> select username, program, background from v$process 2 order by background, program ;
ou, sous unix, par
ps –ef | grep ora_
Suppression
Les champs SID et SERIAL# identifient une session.
On peut supprimer les sessions utilisateurs (les clients).
La commande :
SQL> alter system kill session '29,5';
va déconnecter l’utilisateur « Bertrand ».
Les fichiers d’alerte (alert.log) et de trace (.trc)
Principe
Le fichier d’alerte (alert_<SYS>.log) est un tableau de bord historique de tous les événements de la BD.
C’est un outil vital pour la gestion quotidienne d’une BD.
Les fichiers de trace (.trc) sont générés pas chaque processus d’arrière plan. Ils donnent des détails supplémentaires par rapport au fichier d’alerte
Localisation
Dans le paramètre : background_dump_test ...\app\oracle\admin\<SYS>\bdump
A noter que le paramètre : user_dump_test permet d’accéder aux alertes du serveur.
Ménage des fichiers de trace !
A noter que le processus MMON génère des fichiers <SID>_mmon_XXXX.trc de taille importante (plusieurs mégas) régulièrement (toutes les x minutes) dans le répertoire C:\oraclexe\app\oracle\admin\XE\bdump !
Ces fichiers *.trc peuvent être supprimées sans risques d’erreur.
Le paramètre MAX_DUMP_FILE_SIZE permet de limiter la taille de ces fichiers.
Remarque sur les erreurs
Les erreurs Oracle sont numérotées : ORA-XXXX
A partir de ce n°, on peut trouver des explications sur l’erreur en cherchant sur internet.
Le LISTENER
La connexion au serveur est établie via un processus d’écoute : le LISTENER.
Le protocole est le suivant :
1. L’application demande la connexion au LISTENER 2. Le LISTENER transmet la demande au serveur 3. Le serveur demande confirmation au client 4. Le client confirme
5. Le serveur notifie la connexion
Ce mécanisme permet, entre autre, de protéger le serveur de demandes de connexion intempestives
Connection :
Connect nomUser / password@ // nomDuServeur:nomDuPort / service
Un processus application sur la machine serveur peut contourner le LISTENER.
Une fois connecté, le LISTENER n’intervient plus dans la vie des processus applications.
Le contrôleur du Listener : LSNRCTL
• LSNRCTL.exe permet d’entrer dans le contrôleur du LISTENER.
• Help : liste les commandes disponibles.
• Status : pour connaître l’état du LISTENER.
• Stop : pour arrêter le LISTENER.
• Start : pour démarrer le LISTENER (ou start LISTENER).
INSTANCE ET BD
Gestion d’une instance Notion d’instance
Les concepts d’instance et de base de données sont les concepts centraux de l’architecture Oracle.
• La base de données (BD) correspond essentiellement aux fichiers de données.
• Une instance est l’ensemble des processus d’arrière plan et des zones mémoires qui permettent l’exploitation d’une BD. Une instance peut être vue comme une instanciation du serveur pour une BD donnée.
Les caractéristiques de l’instance (nom du ficher de contrôle, nombre de processus pouvant se connecter simultanément, taille d’un bloc de données, etc.) sont contenues dans le fichier de paramètres associé à l’instance.
Une instance correspond à une BD et une seule. Une BD peut être utilisées par plusieurs instances.
Pour accéder à la BD, il faut que l’instance soit disponible. Le démarrage et l’arrêt de l’instance sont des tâches d’administration.
L’utilisateur se connecte à la base de données, avec des droits, à travers une instance.
Utilisateur SYS et SYSTEM
SYS et SYSTEM sont deux utilisateurs administrateurs créés automatiquement à l’installation d’Oracle.
« SYS » désigne en général l’instance.
L’utilisateur SYS a tous les privilèges, dont celui d’administrer l’instance.
SYSTEM peut créer tous les objets de la base mais ne peut pas administrer l’instance.
Rappels sur les utilisateurs et la connexion
SYSDBA est un rôle qui donne tous les privilèges (c’est le rôle de l’administrateur : « DBA » de l’instance « SYS ») : privilèges sur l’instance et sur la BD.
Connect sys / password as sysdba
L’utilisateur est SYS.
SYSOPER est un rôle équivalent à SYSDBA sans la possibilité de créer une BD.
Connect sys / password as sysoper
L’utilisateur est PUBLIC.
Pour se connecter en tant que SYSTEM :
Connect system / password
L’utilisateur est SYSTEM
Consultation de l’utilisateur connecté :
Show user
Rappels sur les privilèges
Vue SESSION_PRIVS : privilèges de l’utilisateur
Select * from session_privs order by privilege ;
Vue DBA_SYS_PRIV : privilèges système de tous les utilisateurs de la base
Select privilege, admin_option from dba_sys_privs ;
Les vues DBA_TAB_PRIVS et DBA_COL_PRIVS listent les privilèges accordés aux tables et aux colonnes ;
L’authentification des administrateurs
Pour se connecter à la base en tant qu’administrateur, on peut être authentifier par l’OS ou par un fichier de mots de passe d’Oracle.
L’authentification par l’OS
L’utilisateur qui a installé le serveur est membre du groupe ORA_DBA.
Le groupe ORA_DBA est un groupe d’utilisateurs qui reçoit les privilèges SYSDBA.
Connect / as sysdba
L’utilisateur est SYS.
Le « / » veut dire « pas de nom d’utilisateur / pas de mot de passe »
L’authentification par fichier de mot de passe
Un fichier de mots de passe permet d’authentifier les utilisateurs.
Ce fichier peut se créer avec l’utilitaire ORAPWD.
Nom et localisation du fichier :
ORACLE_HOME / database / pwd<SID>.ora
ORACLE_HOME est le nom du répertoire dans lequel on trouve les programmes Oracle.
<SID> est le nom de l’instance
Création du fichier : ORAPWD
L’outil ORAPWD permet de créer un fichier de mots de passe
Modification du fichier : Alter La commande
SQL > alter user system identified by newPassword
Permet de donner un nouveau mot de passe à l’administrateur SYSTEM.
Le fichier de paramètres : PFILE
Le fichier de paramètres décrit les caractéristiques du serveurs tel que la taille du SGA, le nombre de processus utilisateurs maximum, etc.
Il existe un fichier de paramètres par instance.
C’est un fichier texte.
Nom et localisation du fichier
ORACLE_HOME / database / init<SID>.ora
ORACLE_HOME est le nom du répertoire dans lequel on trouve les programmes Oracle.
<SID> est le nom de l’instance
Typologie des paramètres
Il existe plus de 1250 paramètres dont 250 documentés.
Les paramètres non documenté ont un nom commençant par « _ »
Les paramètres documentés se divisent en paramètres de base (environ 30) et paramètres avancés.
Quelques paramètres de base
DB_BLOCK_SIZE : taille du bloc Oracle
DB_CREATE_FILE_DEST : répertoire des fichiers de données, de contrôle et journaux.
DB_NAME : nom de la BD. Non modifiable.
INSTACE_NAME : nom de l’instance.
NLS_LANGUAGE : langue par défaut
PROCESSES : nombre maximal de processus utilisateurs connectés simultanément.
REMOTE_LOGIN_PASSWORDFILE : authentification des administrateur par OS ou fichier.
SESSIONS : nombre max. de sessions (toujours supérieur à PROCESSES : sessions récursives).
SGA_TARGET : taille max. du SGA.
Consultation des paramètres utilisés : la vue V$PARAMETER
SQL> select name, type, value
from v$parameter where name like 'nls_language';
est équivalent à :
SQL> show parameter nls_language
Résultats :
NAME TYPE VALUE
--- --- --- nls_language string AMERICAN
Modification dynamique des paramètres
Modification au niveau de la session (du processus utilisateur connecté) :
SQL> Alter session set nomParamètre=valeur ;
Modification au niveau de l’instance (pour tous les processus utilisateurs connectés) :
SQL> Alter system set nomParamètre=valeur ;
Pour savoir à quel niveau on peut modifier un paramètre :
Attributs ISSES_MODIFIABLE et ISSYSMODIFIABLE de la vue V$PARAMETER
SQL> Select name, isses_modifiable, issys_modifiable from v$parameter where name='nls_language';
NAME ISSES ISSYS_MOD --- --- --- nls_language TRUE FALSE
Exemple :
SQL> alter session set nls_language='ITALIAN';
Modificata sessione.
SQL> select to_char(sysdate,'dd month yyyy') from dual;
TO_CHAR(SYSDATE,'DDMONTHYYYY')
--- 24 febbraio 2010
SQL> show parameter nls_language
NAME TYPE VALUE
--- --- --- nls_language string AMERICAN
A noter que la valeur ‘ITALIEN’ a bien été prise en compte dans le traitement, mais on ne la retrouve pas dans les paramètres.
On verra à la fin du paragraphe où on peut la retrouver ! Ce qui n’est pas évident !!!
Le fichier de paramètres serveur : SPFILE
Le fichier de paramètres serveur est un fichier binaire et dynamique géré par le serveur oracle.
Nom et localisation du fichier
ORACLE_HOME / database / spfile<SID>.ora
ORACLE_HOME est le nom du répertoire dans lequel on trouve les programmes Oracle.
<SID> est le nom de l’instance
Dans le fichier, les paramètres « spfile » et « ifile » déterminent l’emplacement du SPFILE et d’un éventuel fichier complémentaire.
Priorité entre les fichiers de paramètres
Le SPFILE, s’il existe, est prioritaire sur le PFILE.
Le serveur choisit prioritairement dans l’ordre :
• spfile<SID>.ora
• spfile.ora
• init<SID>.ora
Toutefois, au démarrage d’une instance, on peut forcer le choix d’un fichier plutôt que d’un autre.
Création d’un SPFILE par copie du PFILE
SQL >Create spfile from pfile
Création d’un PFILE par copie du SPFILE
SQL >Create pfile from spfile
Création d’une instance : utilitaire ORADIM L’étape OS : utilitaire ORADIM
Les répertoires de travail
Il existe trois répertoires de travail à noter:
• un pour les fichiers d’administration : C:\oraclexe\app\oracle\admin\maBase
• un pour les fichiers de données : C:\oraclexe\oradata\maBase Pour créer le service Windows :
C:\>set oracle_sid=mabase
C:\>ORADIM –new –sid mabase –intpwd monPwd –startmod a
Pour supprimer le service Windows :
C:\>ORADIM –delete –sid mabase
Pour que le service démarre automatiquement
C:\>ORADIM –edit –sid mabase –srvcstart system
ORADIM permet aussi de lancer et d’arrêter une instance.
Pour plus de détails :
C:\>ORADIM \?
Pour créer le fichier de paramètres SPFILE :
C:\>set oracle_sid=mabase C:\ sqlplus /as sysdba
Connecté à une instance inactive
SQL>create spfile from pfile=’C:\...\initMaBase.ora’;
Fichier créé
PFILE = ‘C:\oraclexe\app\oracle\product\10.2.0\server\database/initMABASE.ora’
SPFILE = 'C:\oraclexe\app\oracle\product\10.2.0\server\dbs/spfileMABASE.ora'
Pour lancer l’instance
SQL>startup nomount Instance oracle lancée
Démarrage et arrêt d’une instance et d’une BD Les 3 étapes du démarrage : nomount, mount et open
L’étape « nomount » : démarrage de l’instance Lire le fichier de paramètres
Allouer la mémoire du SGA
Démarrer les processus d’arrière plan Ouvrir les fichiers de trace et d’alerte
L’étape « mount » : montage de la BD Associer la BD à l’instance démarrée Ouvrir les fichiers de contrôle.
A cette étape, seul les administrateurs SYSDBA ou SYSOPER peuvent accéder à la BD.
L’étape open : ouverture de la BD
Vérifier que les fichiers de données et les fichiers journaux sont accessibles.
Permettre la connexion de tous les utilisateurs.
Lancer un processus d’arrière plan SMON pour restaurer la BD si nécessaire.
La commande startup
Startup permet de démarrer l’instance et la BD.
SQL > startup
On peut limiter le startup au « nomount » ou au « mount ».
SQL > startup mount
On peut préciser le fichier de paramètres.
SQL > help startup
La commande alter database
La commande alter database permet de passer d’un état (« mount ») à un autre (« open »).
SQL > startup nomount SQL > alter database open;
Les 4 types d’arrêt Shutdown abort
Arrêt le plus brutal et le plus rapide. Pas de rollback avant pendant l’arrêt. Ce shutdown nécessite une récupération d’instance au redémarrage.
Shutdown immediate
Ce shutdown évite de perdre des données mais les transactions en cours sont arrêtées avec un rollback.
C’est le mode qui, associé au redémarrage est le plus rapide, car le redémarrage ne nécessite pas de récupération.
Shutdown transactionnal
Ce shutdown évite de perdre des données et attend que toutes les transactions en cours soient validées par un commit. Aucune nouvelle transaction n’est autorisée.
Shutdown normal
Ce shutdown évite de perdre des données et attend que toutes les connexions en cours soient arrêtées. Aucune nouvelle connexion n’est autorisée.
Les vues dynamiques
Les vues associées aux étapes de démarrage
Vues dynamiques Etapes Eléments montés
V$PARAMETER NOMOUNT Fichier de paramètres
V$SPPARAMETER Instance (SGA,
V$SGA processus d’arrière plan)
V$SGA_DYNAMIC_COMPONENTS V$OPTION
V$SESSION V$INSTANCE
V$CONTROLFILE MOUNT Fichier de contrôle
V$DATABASE V$DATAFILE V$LOGFILE
Vues du dictionnaire OPEN Fichiers de données
des données Fichiers journaux
La vue de toutes les vues dynamique : V$FIXED_TABLE Dans cette vue on peut trouver :
SQL> select * from v$fixed_table where name like 'V$%PARAM%';
NAME OBJECT_ID TYPE TABLE_NUM --- --- --- --- V$PARAMETER 4294950940 VIEW 65537 V$SYSTEM_PARAMETER 4294951200 VIEW 65537 V$PARAMETER2 4294951591 VIEW 65537 V$SYSTEM_PARAMETER2 4294951592 VIEW 65537 V$OBSOLETE_PARAMETER 4294951488 VIEW 65537 V$SPPARAMETER 4294951748 VIEW 65537 V$PARAMETER_VALID_VALUES 4294952696 VIEW 65537 V$NLS_PARAMETERS 4294951071 VIEW 65537 V$LOGMNR_PARAMETERS 4294951547 VIEW 65537 V$HS_PARAMETER 4294951608 VIEW 65537 10 ligne(s) sélectionnée(s).
Dans la vue V$NLS_PARAMETERS, on trouve :
SQL> select * from v$nls_parameters where parameter='NLS_LANGUAGE';
PARAMETER VALUE --- --- NLS_LANGUAGE FRENCH
SQL> alter session set nls_language='ITALIAN';
Modificata sessione.
SQL> select * from v$nls_parameters where parameter='NLS_LANGUAGE';
PARAMETER VALUE --- --- NLS_LANGUAGE ITALIAN
A noter qu’il y a 1383 vues dans la vue V$FIXED_TABLE !!!
Gestion d’une BD Notion de BD
Les concepts d’instance et de base de données sont les concepts centraux de l’architecture Oracle.
La BD est l’ensemble des trois fichiers obligatoire : les fichiers de contrôle, les fichiers de données et les fichiers journaux.
Les fichiers de la BD
Les fichiers de données sont les fichiers contenant les données de la base.
Le fichier de contrôle est un fichier qui permet de contrôler tous les fichiers oracle.
Les fichiers journaux (fichier redo-log) contiennent les modifications successives de la BD.
Le fichier de paramètre contient les paramètres de démarrage de l’instance.
Le fichier de mots de passe vérifie l’authenticité des utilisateurs privilégiés.
Création manuelle d’une BD : CREATE DATABASE La création d’une BD est une tâche importante.
Le nom de la BD et la taille des blocs ne pourront plus être modifiés.
On peut créer une BD à partir de rien ou à partir d’une BD existante en effaçant les fichiers de données.
La BD est créée à partir d’un administrateurs connecté à une instance démarré en « nomount » avec des privilèges SYSDBA.
C:\ sqlplus /as sysdba
Connecté à une instance inactive
SQL>create spfile from pfile=’C:\...\initMaBase.ora’;
Fichier créé
SQL>startup nomount Instance oracle lancée
La création de la BD va créer les fichiers de données de la BD. Ces fichiers seront lus par les processus d’arrière plan de l’instance.
La création des fichiers de données se fait par commande : CREATE DATABASE
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/create.htm#i1008985
SQL>create database “maBase” ...;
SQL > alter database open;
Une fois l’instance démarrer en « nomount », on peut créer la BD. On peut ensuite la monter et l’ouvrir avec l’alter database.
Pour visualiser le DB_NAME (nom de la BD, 8 caractères maximum)
Show parameter DB_NAME
DB_UNIQUE_NAME : nom de la BD sur 30 caractères.
Pour visualiser le INSTANCE _NAME (nom de l’instance, en général même nom que la BD) :
Show parameter INSTANCE _NAME
Création du dictionnaire
Pour créer le dictionnaire des données, il faut exécuter des scripts qui sont dans le répertoire :
%ORACLE_HOME% / RDBMS / admin
Les deux scripts obligatoires sont :
• catalog.sql
• catproc.sql
Mais il y en a d’autres !
Exemple de code :
SQL > connect / as sysdba
SQL > spool ./createCatalog.log
SQL > @%ORACLE_HOME \ rdbms \ admin \ catalog.sql ; SQL > @%ORACLE_HOME \ rdbms \ admin \ catproc.sql ; SQL > spool off
On commence par se connecter en tant qu’administrateur avec privilèges SYSDBA.
On redirige les résultats dans le fichier createCatalog.log pour pouvoir les lire ensuite.
On exécute les deux fichier catalog.sql et catproc.sql.
On ferme le fichier spool.
Changer d’instance pour une BD
Oradim -DELETE -SID XE Set ORACLE_SID=bertrand
Oradim -NEW -SID bertrand -INTPWD liaudet -STARTMODE m Sqlplus / as sysdba
Create spfile from
pfile=’C:\oraclexe\app\oracle\product\10.2.0\server\database\initXE .ora’;
Startup
Select instance_name from v$instance ; Select name, open_mode from v$database ;
Sauvegarder : lister tous les fichiers de la BD
Pour sauvegarder, il suffit de copier tous les fichier résultats de la requêtes suivante :
Select name from v$datafile Union all -- all évite le tri Select name from v$controlfile Union all -- all évite le tri Select member from v$logfile ;
NAME
---
C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF C:\ORACLEXE\ORADATA\XE\UNDO.DBF C:\ORACLEXE\ORADATA\XE\SYSAUX.DBF C:\ORACLEXE\ORADATA\XE\USERS.DBF C:\ORACLEXE\ORADATA\XE\CONTROL.DBF
C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_50R MMBVC_.LOG
C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_1_50R MM9TV_.LOG
7 ligne(s) sélectionnée(s).
DICTIONNAIRE
Dictionnaire et dictionnaire des données
Présentation Le dictionnaire
Le dictionnaire est un ensemble de tables, de vues et de synonymes contenant toutes les informations concernant tous les objets de la base, que ce soit du point de vue de l’utilisateur ou de l’administrateur, que ce soit d’un point de vue logique ou d’un point de vue physique.
Le dictionnaire est mis à jour automatiquement à chaque modification de la BD.
Le propriétaire du dictionnaire est l’utilisateur SYS.
Le dictionnaire des données
Le dictionnaire des données est une partie du dictionnaire.
Le dictionnaire des données contient les données des bases de données pour les utilisateurs.
La vue « dictionnary » ou le synonyme « dict » Description du dictionnaire
C’est une table avec deux attributs : « table_name » et « comments » Il contient environ 1800 tuples.
SQL> select count(*) from dict ; COUNT(*)
--- 1821
Chaque tuple du dictionnaire concerne une table, une vue ou un synonyme.
Les attributs de chaque table sont accessibles à partir de la vue : « dict_columns ».
Les 4 types d’objets du dictionnaire Le dictionnaire contient :
• Environ 1000 objets du dictionnaire des données tous préfixés par DBA (env. 500), ALL (env. 250) ou USER (env. 250)
• Environ 400 vues des performances toutes préfixées par « V_$ », accessibles par des synonymes tous préfixées par « V$ ».
• Environ 350 Les vues des performances des bases en cluster, toutes préfixées par
« GV$ »
• Environ 30 objets relevant en général du dictionnaire des données.
La vue de toutes les performances est dans « v$fixed_table ».
Exemple de requête
column table_name format a30 column comments format a80
select table_name, comments from dict where substr(table_name, 1, 2)!='V$' and substr(table_name, 1, 3)!='GV$' and substr(table_name, 1, 4)!='ALL_' and substr(table_name, 1, 4)!='DBA_' and substr(table_name, 1, 5)!='USER_';
Dictionnaire des données
Premiers usages du dictionnaire des données Lister toutes les tables
SQL> select * from cat;
SQL> select * from user_catalog;
SQL> select * from all_catalog;
SQL> desc user_tables ;
SQL> select table_name from user_tables ; // lister les tables
Description des attributs d’une table
SQL> desc nomTable // description d’une table
Tous les utilisateurs
desc all_users ;
select * from all_users
Utilisateur courant
desc user_users ;
select username from user_users
Utilisateur courant
desc user_objects;
select object_name, object_type from user_objects;
Principales vues du dictionnaire des données
all_catalog -- tables, sequence, synonyme, vue, environ 4000 all_objects -- 19 types d’objets, environ 5000
all_views -- les vues, environ 1000
cat -- équivalent à user_catalog user_catalog -- les tables et les séquences user_objects -- tous les objets
user_tables -- les tables user_constraints -- les contraintes user_indexes -- les index
etc.
La vue des vues : all_views
Les tables du dictionnaires des attributs sont des vues.
En général, les vues sont préfixées soit par « all » soit par « user ».
La vue qui contient toutes les vues : « all_views »
Desc all_views
select count(*) from all_views ;
-- pour chercher les vues qui concernent les sequences :
Select view_name from all_views where view_name like « %SEQ% » ;
-- pour chercher les vues qui concernent les privilèges :
Select view_name from all_views wher view_name like « %PRIV% » ; Etc.
Les vues du dictionnaires des données
Ce sont les vues du dictionnaire préfixées par « DBA_ », « ALL_ » ou « USER_ ».
• Les vues « DBA_ » contiennent des informations sur tous les objets de tous les schémas.
• Les vues « ALL_ » contiennent des informations sur les objets accessibles par le groupe PUBLIC et par l’utilisateur courrant. Les vues « ALL » sont les vues accessibles à tous.
• Les vues « USER_ » contiennent les informations sur les objets accessibles par l’utilisateur courant.
Les 3 catalogues
Le catalogue est la vue contenant tous les objets accessibles.
Il y a 3 catalogues : « DBA_Catalog », « ALL_Catalog » et « USER_Catalog »
« CAT » est un synonyme de la vue « USER_catalog ».
Les différents objets
On peut ensuite accéder aux OBJECTS, TABLES, TAB_COLUMNS, VIEWS, SYNONYMS, SEQUENCES, CONSTRAINTS, CONS_COLUMNS, INDEXES, IND_COLUMNS, CLUSTERS, CLU_COLUMNS.
Exemple
Select object_name, object_type, created, last_ddl_time From DBA_OBJECTS
Where owner like ‘Toto’
Accès aux statistiques
Les tables DBA_TABLES et DBA_TAB_COLUMNS permettent d’accéder aux informations d’identification (owner, table_name, column_name, etc.), d’espace de stockage (tablespace_name, cluster_name) pour les tables et de définition pour les colonnes (data_type, data_length, nullable, etc.).
Elles permettent aussi d’accéder à des informations de statistiques qui interviendront dans le calcul d’optimisation : num_rows, blocks, cache, num_distinct, num_null, etc.)
Les utilisateurs et leurs privilèges
Vues des utilisateurs
La vue « USERS » permet de lister les utilisateurs et leurs caractéristiques
Select * from all_users ;
Vues des roles
Les vues « ROLES » et « ROLE_PRIVS » permettent de lister les rôles des utilisateurs.
Pour un utilisateur ayant le rôle DBA,
SQL> select * from dba_roles order by role;
Permet de lister les rôles de l’utilisateur. Ca donne le même résultat que :
SQL> select * from user_role_privs order by granted_role;
Et
SQL> select * from dba_role_privs order by granted_role;
permet de lister tous les rôles de tous les utilisateurs.
Pour un utilisateur ayant simplement les rôles « CONNECT » et « RESSOURCE » seul la vue
« USER_ROLE_PRIVS » est accessible :
SQL> select * from user_role_privs order by granted_role;
USERNAME GRANTED_ROLE ADM DEF OS_
--- --- --- --- --- BERTRAND2 CONNECT NO YES NO BERTRAND2 RESOURCE NO YES NO
Autres droits
Les vues « SYS_PRIVS », « TAB_PRIVS » et « COL_PRIVS » permettent de détailler les droits.
CONTROLE, JOURNAUX ET UNDO
Les fichiers de contrôle
Un fichier de contrôle est un fichier binaire de petite taille associé à une base de données.
Il contient des informations concernant : la BD, les fichiers, les tablesspaces, la taille d’un bloc de données, les journaux, les archives, les points de contôle (checkpoint).
Il précise aussi, entre autres, le nombre maximum de journaux (MAXLOGFLES, MAXLOGMEMBERS), d’archives (MAXLOGHISTORY).
Pour créer un fichier de contrôle (CREATE CONTROLFILE), il faut préciser tous les paramètres cités.
Show parameter control_file permet de connaître le nom et l’emplacement du fichier de contrôle.
Les vues V$CONTROLFILE, V$PARAMETER permettent aussi de connaître des informations sur les fichiers de contrôle.
Etant donné l’importance de ce fichier, il est conseillé d’avoir au moins deux fichiers de contrôle.
La commande : ALTER SYSTEM SET CONTROL_FILES = NOM DU FICHIER permet de spécifier le fichier de contrôle qu’on veut utiliser.
La commande SHOW PARAMETER CONTROL_FILES permet de connaître le nom et de répertoire du fichier de contrôle actuellement utilisé.
Les fichiers de journaux
Les fichiers de JOURNAUX sont aussi appelés : fichiers REDO ou fichiers de REPRISE.
Présentation
Les fichiers journaux sont des fichiers qui conservent toutes les modifications successives de la BD : toutes les opérations validées (transaction terminée) ou non validées (transaction en cours) effectuées sur les données de la BD sont d’abord écrites dans les fichiers journaux.
Ils sont utiles lors d’une restauration à la suite d’un problème.
Gestion de base Principes
Les fichiers de journaux prennent un volume important.
Il faut les placer sur un périphérique différent de celui des fichiers de la BD
Le processus LGWR écrit dans les fichiers journaux. L’utilisation est circulaire : quand le dernier est plein, LGWR reprend au premier. Les fichiers sont numérotés mais quand on revient au premier le numéro ne reste pas 1 mais suit la progression.
Gestion des groupes et des membres
Les fichiers de journaux ont intérêt à être dupliqués (comme le fichier de contrôle) pour se protéger du dysfonctionnement d’un fichier. Les copies ont intérêt à être placées sur des disques distincts.
Un fichier et ses copies forment un « groupe » dont chaque fichier est un « membre ».
MAXLOGFILES fixe le nombre maximum de fichiers gérés en tout (nombre maximum de membres en tout). MAXLOGMEMBERS fixe le nombre maximum de membres par groupe.
CF. fichier de controle/
La vue V$LOGFILE permet de récupérer les informations sur les fichiers de journaux.
Les commandes suivantes permettent de gérer les groupes et les membres :
• ALTER DATABASE ADD LOGILE GROUP
• ALTER DATABASE ADD LOGFILE MEMBER
• ALTER DATABASE DROP LOGILE GROUP
• ALTER DATABASE DROP LOGFILE MEMBER Gestion des performances
Augmenter la taille des fichiers de journaux améliore les performances d’utilisation mais ralentit le temps de reprise et augmente la taille des pertes en cas de problème.
NOARCHIVELOG et ARCHIVELOG
En mode ARCHIVELOG, le système fait une copie de chaque fichier journal quand il est plein (processus ARCn).
Le mode NOARCHIVELOG réduit l’utilisation de la mémoire sur le disque et améliore les performances mais il réduit les chances de reconstruire correctement les fichiers de données à partir des fichiers journaux.
ARCHIVE LOG LIST permet de consulter l’état courant de la base à ce sujet.
L’attribut LOG_MODE de la vue V$DATABASE permet aussi de connaître l’état de la base à ce sujet.
On peut sélectionner le mode ARCHIVELOG ou NOARCHIVELOG au démarrage du serveur :
• STARTUP MOUNT
• ALTER DATABASE ARCHIVELOG
• ALTER DATABASE OPEN
Le segment UNDO
Chaque BD gère un ou plusieurs segments UNDO qui contiennent les anciennes valeurs des enregistrements en cours de modification dans les transactions.
Ces segments sont stockées dans un tablespace spécial appelé UNDO.
Seul ORACLE peut lire ces segments. Les utilisateurs et les administrateurs ne le peuvent pas.
Ces segments servent à ORACLE pour :
• Gérer une lecture cohérente des données
• Gérer l’annulation d’une transaction
• Gérer la récupération en cas d’arrêt brutal du serveur
• Interroger les données dans l’état où elles étaient avant des modifications (FLASHBACK ORACLE 9i)
TABLESPACE
LES ASSISTANTS ORACLE
Oracle Net
Gestion des paramètres du fichier SPFILE Arrêter et démarrer le serveur
OEM : Oracle Entreprise Manager
Gestion des paramètres du fichier SPFILE Arrêter et démarrer le serveur
L’assistant DBCA
Création et configuration d’une BD
http://download.oracle.com/docs/cd/B19306_01/server.102/b14196/install003.htm#CHDFGJEI
TP
Installation d’une instance Méthode de travail
Conserver une trace écrite de toutes les commandes que vous effectuez, avec les résultats.
Fonctionner au maximum par essai – erreur, en analysant les messages d'erreurs
Essayer d'être autonomes. Lisez les messages d'erreurs sont le plus souvent explicites, ils mettent sur la voie d’une solution.
Chercher dans la documentation et sur google.
Quelques pistes google :
http://st-curriculum.oracle.com/tutorial/DBXETutorial/index.htm http://orafrance.developpez.com/dbahelp/ : pense-bête DBA Oracle http://mbouayoun.developpez.com/Fctladm/ : sur les fichiers de contrôle etc...
Objectif
Obtenir une première base avec son instance, sans être regardant sur les paramètres, les emplacements des fichiers…
Le nom de l’instance sera (en majuscules) : DB suivi des 2 premières lettres de votre prénom, suivi des 3 premières lettres de votre nom (ex. : DBELIA).
Paramètres de l'instance :
On définie les paramètres suivants, les autres gardant leurs valeurs par défaut :
• nom de base : identique au nom de l'instance,
• un fichier de contrôle,
• 50 processus utilisateurs peuvent se connecter simultanément à l'instance,
• taille d'un bloc de données : 8 192 octets,
• taille du tampon de données (db_cache_size) : 2 516 582 octets,
• taille de la zone SQL partagée (shared_pool_size) : 54 525 953 octets,
• taille du tampon Java (java_pool_size) : 0 octets,
• les fichiers de dump (background, core et user) doivent être rangés dans des sous- répertoires de votre compte.
Paramètres de la base :
• 32 groupes de fichiers redo-log pourront être créés,
• taille des fichiers redo-log : 6 Mo,
• taille du fichier de données système : 30 Mo,
• taille du fichier de données auxiliaires : 10 Mo.
A la fin de la séance, il faut arrêter votre instance.
