architecture oracle - Site de Bertrand LIAUDET

Transcription

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
Méthodes de connexion
La connexion
Les fichiers oracle
Structure des fichiers de la BD
Problème conceptuel : la notion de base de données, BD
Architecture de l’instance
Les processus d’arrière-plan et le processus serveur
La mémoire : SGA et PGA
Le shared pool (pool partagé)
Le buffer cache
Principe
Notion de bloc oracle
Bloc oracle et buffer cache
L’exécution d’un requête
Principe
Le buffer redo log : tampon des journaux de reprise
Le java pool
Les processus d’arrière plan
DBWn : DataBase Write
LGWR
ARCn 10
CKPT 11
SMON
PMON
Gestion des processus : vue v$session – v$process
Les fichiers d’alerte (alert.log) et de trace (.trc)
Principe
Localisation
Ménage des fichiers de trace !
Remarque sur les erreurs
Le LISTENER
Le contrôleur du Listener : LSNRCTL
11
11
11
12
12
12
12
12
13
13
INSTANCE ET BD
14
INSIA - BASES DE DONNÉES – SIGL – ARCHITECTURE ORACLE - page 1/34 - Bertrand LIAUDET
3
3
3
4
4
5
5
6
6
7
7
7
7
8
8
8
10
10
10
10
10
Gestion d’une instance
Notion d’instance
Utilisateur SYS et SYSTEM
Le fichier de paramètres : PFILE
Le fichier de paramètres serveur : SPFILE
Création d’une instance : utilitaire ORADIM
Démarrage et arrêt d’une instance et d’une BD
Les vues dynamiques
Gestion d’une BD
Notion de BD
Les fichiers de la BD
Création manuelle d’une BD : CREATE DATABASE
Création du dictionnaire
Changer d’instance pour une BD
Sauvegarder : lister tous les fichiers de la BD
14
14
14
16
17
18
19
20
22
22
22
22
23
23
24
DICTIONNAIRE
Dictionnaire et dictionnaire des données
Présentation
La vue « dictionnary » ou le synonyme « dict »
Dictionnaire des données
Premiers usages du dictionnaire des données
Les vues du dictionnaires des données
Les 3 catalogues
Les différents objets
Accès aux statistiques
Les utilisateurs et leurs privilèges
25
25
25
25
26
26
27
27
27
27
27
CONTROLE, JOURNAUX ET UNDO
Les fichiers de contrôle
Les fichiers de journaux
Présentation
Gestion de base
Le segment UNDO
29
29
29
29
29
31
TABLESPACE
32
LES ASSISTANTS ORACLE
Oracle Net
OEM : Oracle Entreprise Manager
L’assistant DBCA
32
32
32
32
TP
33
33
Installation d’une instance
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
BASES DE DONNEES
1
1
*
SCHEMAS
*
*
*
*
T ABLESPACES
FICHIERS
1
1
1
*
*
T ABLES, INDEX, CLUST ERS,
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.
STRUCTURE
LOGIQUE
STRUCTURE
PHYSIQUE
BASES DE DONNEES
1
1
*
SCHEMAS
*
*
*
*
TABLESPACES
FICHIERS
1
1
1
1
*
TABLES, INDEX, CLUST ERS,
*
1
*
*
BLOCS ORACLE
*
BLOCS OS
1
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
----- ---------- -----------25
1
29
5 BERTRAND
31
23 SYS
33
1
36
3
37
5
39
1
41
1
42
1
43
1
44
1
45
1
46
1
47
1
48
1
49
1
MACHINE
-----------------LIAUDET
MSHOME\LIAUDET
MSHOME\LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
LIAUDET
PROGRAM
-----------------ORACLE.EXE (q000)
sqlplus.exe
sqlplus.exe
ORACLE.EXE (QMNC)
ORACLE.EXE (MMON)
ORACLE.EXE (q001)
ORACLE.EXE (MMNL)
ORACLE.EXE (CJQ0)
ORACLE.EXE (RECO)
ORACLE.EXE (SMON)
ORACLE.EXE (CKPT)
ORACLE.EXE (LGWR)
ORACLE.EXE (DBW0)
ORACLE.EXE (MMAN)
ORACLE.EXE (PSP0)
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
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
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
V$SPPARAMETER
V$SGA
V$SGA_DYNAMIC_COMPONENTS
V$OPTION
V$SESSION
V$INSTANCE
NOMOUNT
Fichier de paramètres
Instance (SGA,
processus d’arrière plan)
V$CONTROLFILE
V$DATABASE
V$DATAFILE
V$LOGFILE
MOUNT
Fichier de contrôle
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
-----------------------------V$PARAMETER
V$SYSTEM_PARAMETER
V$PARAMETER2
V$SYSTEM_PARAMETER2
V$OBSOLETE_PARAMETER
V$SPPARAMETER
V$PARAMETER_VALID_VALUES
V$NLS_PARAMETERS
V$LOGMNR_PARAMETERS
V$HS_PARAMETER
OBJECT_ID
---------4294950940
4294951200
4294951591
4294951592
4294951488
4294951748
4294952696
4294951071
4294951547
4294951608
TYPE
TABLE_NUM
----- ---------VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
VIEW
65537
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
SQL
SQL
SQL
SQL
>
>
>
>
>
connect / as sysdba
spool ./createCatalog.log
@%ORACLE_HOME \ rdbms \ admin \ catalog.sql ;
@%ORACLE_HOME \ rdbms \ admin \ catproc.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
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
all_objects
all_views
cat
user_catalog
user_objects
user_tables
user_constraints
user_indexes
etc.
-- tables, sequence, synonyme, vue, environ 4000
-- 19 types d’objets, environ 5000
-- les vues, environ 1000
-------
équivalent à user_catalog
les tables et les séquences
tous les objets
les tables
les contraintes
les index
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
-------------------BERTRAND2
BERTRAND2
GRANTED_ROLE
-----------------------------CONNECT
RESOURCE
ADM
--NO
NO
DEF
--YES
YES
OS_
--NO
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 sousré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.

architecture oracle - Site de Bertrand LIAUDET

Transcription

Documents pareils

Administrateur Base de données (DBA) LIEU DE

Cadre Informaticien Contexte du recrutement et définition de poste

L`oracle de Margyle

L`Oracle bleu - Passage du livre

voir le détail de l`offre

Formation PL-SQL Plan de cours

L`oracle Belline : plus de 2.600 associations des cartes

Administrateur de bases de données

Le COFFRET de L`ORACLE BLEU

Oracle - Apex - Alternative Formation