Oracle 11g - ADMINISTRATION

Transcription

Oracle 11g - ADMINISTRATION
Erik Jourdain
Support ORA-ORSYS
Version 2.5
Erik Jourdain
●
DBA Oracle
●
●
●
Administration et Optimisation
Linux
●
Debian, RedHat
●
Cluster et virtualisation Xen et KVM
Langages
●
SQL, PL/SQL, Perl, Shell
●
E-mail : [email protected]
●
Blog : http://www.silverlake.fr
●
Twitter : silverlakefr
Avertissement
●
Ce cours est conçu pour Linux
●
Il est facilement adaptable à Windows
●
●
●
●
Différences minimes signalées
Attention toutefois aux noms des répertoires qui sont à adapter :
/u01/app/oracle → c:\U01\app\oracle
Quelque soit la plate-forme les principes d'administration
Oracle sont identiques.
La version de Oracle disponible chez Orsys pour la formation
est la 11.2.0.1, certains concepts utilisés sur les anciennes
versions seront justes survolés.
●
Le cours se fait principalement en ligne de commande.
●
Le Database Control ( graphique ) sera vu pour les exercices.
Editeur de texte
●
●
Le cours utilise vi, mais il est possible d'utiliser
l'éditeur de son choix.
gedit se rapproche de notepad de Windows.
●
vi /etc/hosts ou
●
gedit /etc/hosts.
Plan du cours
●
Architecture Oracle
●
Installation de Oracle
●
Oracle et le réseau, Oracle*Net
●
Création d'une base de données
●
Outils d'administration Oracle
●
Arrêt et démarrage d'une base Oracle
●
Gestion des fichiers de contrôle et de journalisation
●
Les tablespaces
●
Les utilisateurs et les droits
●
Les structures de stockage
●
Sauvegardes et restauration
●
Utilitaires Oracle
Présentation de l'architecture
ORACLE
Architecture Oracle 11g
●
L'instance et les zones mémoires
●
La base de données et les fichiers
●
Principe des transactions
●
Les processus
●
Oracle et la mémoire
●
L'administrateur des données → DBA
●
Les comptes d'administration
●
Le dictionnaire des données
Serveur Oracle
●
●
●
Composé de deux éléments distincts
●
L'instance
●
La base de données
Instance
●
Zones mémoire
●
Processus
Base de données
●
●
Ensemble de fichiers physiques
Une instance n'ouvre qu'une seule base de données
●
Exception : RAC → x Instances ouvrent une base de données.
●
RAC : Real Application Clusters ( non vue ici )
Principes serveur Oracle
Oracle Stand-Alone
INSTANCE
Oracle RAC
INSTANCE
1
n Instances Oracle
minimum 2
Mémoire
Disque
Base de
données
Base de
données
INSTANCE
n
INSTANCE
ORACLE_SID
Architecture de base
Utilisateurs
System Global Area
Shared Pool
Database
Buffer Cache
Serveur
DBW0
Library Cache
Ordres SQL
Dictionnary
Cache
Insert, Select,
Delete, PL/SQL...
Result
Cache
CKPT
PMON SMON
Redo
Log
Buffer
ARC0
optionnel
LGWR
BASE DE
DONNEES
DB_NAME
init.ora
Fichier de
paramètres
PGA
Fichiers de
données
Fichier de
contrôle
Fichiers
d'archives
Fichiers de
journalisation
L'instance
●
Une zone mémoire partagée → SGA
●
Ensemble de processus d'arrière plan
●
●
●
Distincts sous Linux
●
Unique ( service ) sous Windows
Ensemble de processus serveur
●
Partagent une autre partie de la mémoire : la PGA
●
PGA : Program Global Area
L'instance est accédée via une variable
d'environnement de l'OS : ORACLE_SID
Notions de tablespace
●
●
●
●
Les données Oracle sont stockées dans des
fichiers physiques sur disque.
Toutefois Oracle utilise principalement la notion
de tablespace et non de fichier.
Un tablespace est un ensemble logique
contenant 1 ou x fichiers physiques.
La manipulation des tablespaces est une des
tâches principales d'administration Oracle, un
chapitre plus complet sera présenté dans ce
cours.
Exemple de tablespace
●
●
●
Le tablespace DATA est composé de 3 fichiers
physiques d'une taille de 10Go,20Go et 15Go.
Les fichiers physiques ne sont pas
obligatoirement de taille identique.
La dimension du tablespace DATA est de 45Go
data_01.dbf
10Go
data_02.dbf
20Go
data_03.dbf
15Go
DATA
Base de données
●
●
●
Constituée au minimum par :
●
1 fichier de paramètres ( texte : pfile ou binaire : spfile ) → init.ora
●
1 fichier de contrôle ( controlfile )
●
2 tablespaces : system et sysaux
●
2 groupes de fichiers de journalisation ( redolog )
En complément
●
1 ou plusieurs tablespaces ( datafile )
●
1 ou plusieurs tablespace temporaire ( tempfile )
●
1 tablespace pour les annulations ( undo )
Une base de données est nommée par le paramètre
DB_NAME
Catégories de bases de données
●
Transactionnelles
●
●
●
OLTP : OnLine Transaction Processing
Forte activité de mise à jour ( insert/update ) sous forme de
petites transactions.
●
Un nombre d'utilisateurs concurrents plus ou moins important.
●
Exigence d'un temps de réponse court.
Décisionnelles
●
DSS : Décision Support Systems
●
Forte activité d'interrogation ( select )
●
Gros volume de données
●
Mise à jour périodique → batches
Le fichier de paramètres
●
Contient le mode de fonctionnement de l'instance et des indicateurs pour
la base de données :
●
Son nom, DB_NAME
●
La taille SGA, SGA_TARGET
●
L'emplacement du ou des fichiers de contrôle...
●
Il y a plus de 340 paramètres dans Oracle
●
Tous ont une valeur par défaut
●
●
La valeur précisée dans le fichier de paramètres surcharge la valeur par
défaut.
Le fichier de paramètre peut être :
●
texte → pfile
●
binaire → spfile
●
Le spfile permet de modifier certains paramètres, par la commande alter system
set, sans devoir redémarrer l'instance.
Le fichier de contrôle
●
●
●
●
Informations sur la base de données
●
Son nom
●
Date de création
●
Emplacement des autres fichiers de la BD
●
Numéro de séquence actuel ( SCN )
●
Information sur point de reprise ( checkpoint )
Mise à jour automatique par Oracle
Il est conseillé de les multiplexer sur des axes différents,
en général 3 copies.
Le fichier de contrôle peut aussi contenir le référentiel des
sauvegardes RMAN
Les fichiers de journalisation
●
●
●
Nommés aussi REDOLOG
Enregistrent l'ensemble des modifications de la BD. Ordres : insert,
delete et update.
Utilisés suite à un arrêt anormal ou récupération suite à la perte d'un
fichier de données → les transactions sont rejouées
●
Organisés en groupe, composés de membres
●
Minimum deux groupes de un membre
●
●
●
Ecriture circulaire → informations périodiquement écrasées
●
Conservation possible en activant le mode ARCHIVELOG de la BD ( optionnel ).
Utilise une zone de la SGA ( redolog buffer ) et un processus dédié
( LGWR )
Le passage d'un groupe à l'autre est appelé switch et peut être forcé par
la commande alter system switch logfile
Principe des REDOLOGS
GROUPE
1
GROUPE
2
Enregistrement
des transactions
Enregistrement
des transactions
Quand GROUPE 2
est rempli → Retour
à GROUPE 1
Quand GROUPE 1
est rempli → Passage
à GROUPE 2
Un cycle complet de REDOLOG provoque un effacement des transactions, pour conserver
l'ensemble des transactions la base doit fonctionner en mode ARCHIVELOG
Les fichiers de données
●
●
Contiennent les informations de la base
●
Dictionnaire des données ( system )
●
Statistiques sur ressources ( sysaux )
●
Données utilisateurs
●
Index
Logiquement regroupés en tablespaces
system01.dbf
sysaux01.dbf
tablespace
system
tablespace
sysaux
data01.dbf
data02.dbf
tablespace
data
Organisation du stockage
●
Les fichiers sont découpés en blocs Oracle
●
Un bloc Oracle est un multiple du bloc système
●
5 tailles de blocs possibles ( 2,4,8,16 et 32Ko )
●
Depuis la 9i Oracle peut utiliser plusieurs tailles de blocs
●
La taille du bloc standard est fixé par le paramètre DB_BLOCK_SIZE et ne peut être
modifié après création de la base.
●
Le bloc est la plus petite unité d'entrée/sortie de Oracle.
●
La notion de bloc est fondamentale et se retrouve partout dans Oracle.
●
Un ensemble de blocs contigus forme un extent
●
Un ensemble d'extent forme un segment
●
4 types de segments
–
–
–
–
●
table
index
annulation( undo ) → ordre ROLLBACK
temporaire → tri, clause order by, group by...
Un segment appartient à un tablespace
Principe du stockage
BASE DE DONNEES
TABLESPACE
SEGMENT
EXTENT
BLOC
FICHIER PHYSIQUE
segment de table, d'index,
temporaire ou d'annulation ( UNDO )
Cycle d'un segment
●
●
●
●
Implicitement ou explicitement créé dans un
tablespace.
Un ou plusieurs extents alloués lors de la
création, sans être obligatoirement remplis.
Allocation d'un nouvel extent lors d'un ajout au
segment si tous les extents sont remplis.
Les extents d'un segment sont dans le même
tablespace mais pas obligatoirement dans le
même fichier.
Exemple de stockage
tablespace data
SEGMENT A ( extent 1 )
SEGMENT A ( extent 2 )
SEGMENT B ( extent 1 )
data01.dbf
SEGMENT C ( extent 1 )
data02.dbf
Blocs
Alloués
Blocs
Libres
Utilisation de blocs de tailles
multiples
●
Utile pour la fonction de tablespace transportable apparue en 8i
●
●
●
●
●
Opération effectuée par DataPump ou EXP/IMP
Prérequis → les tailles de blocs doivent être identiques entre les
bases
Il est ainsi possible d'utiliser des tablespaces avec des blocs de
16Ko dans une base ayant un bloc standard de 8ko
Permet au sein d'une même base d'avoir des tablespaces
dédiés au décisionnel → grand bloc et des tablespaces dédiés
au transactionnel → petit bloc
La gestion des blocs multiples demande un soin particulier, car
il faut spécifier manuellement un tampon mémoire différent qui
est inclus dans le DB_BUFFER_CACHE.
Système de stockage
●
●
●
●
2 types possibles
Système de fichiers, cas classique. Oracle préconise
l'utilisation de plusieurs disques pour répartir les
entrées/sorties (I/O).
ASM : Automatic Storage Management
●
Arrivé en 10g
●
Similaire au LVM de Linux
●
Répartition des I/O par Oracle en fonction des disques disponibles
●
Demande une instance supplémentaire spéciale ( Instance ASM )
●
Utilisable avec RAC
Le mode RAW DEVICE présent dans les versions pré-11gR2
n'est plus supporté,
Notion de schéma
●
Ensemble des objets appartenant à un utilisateur.
●
Tables
●
Vues
●
Synonymes
●
Index
●
Séquences
●
Programme PL/SQL
●
Schéma et Utilisateur ( user ) sont souvent équivalents dans Oracle
●
Un utilisateur doit posséder des privilèges spéciaux pour créer des objets.
●
Seuls les tables et les index utilisent du stockage dans les tablespaces
●
Les autres objets sont définis dans le dictionnaire des données.
●
Il existe la commande suivante dans Oracle :
●
●
CREATE AUTHORIZATION SCHEMA
Cette commande est utilisée pour créer un ensemble d'objets ( tables, vues, indexs... ).
L'ensemble des créations doit aboutir sinon rien n'est créé.
Règles de nommage
●
●
●
Débute par une lettre
Composé de lettres, de chiffres et des trois caractères
spéciaux : _, $ et #.
De 1 à 30 caractères maxi, sauf :
●
Database : 8 caractères
●
Database Link : 128 caractères. @ et . sont autorisés pour
nommer les database links.
●
Insensible à la casse, sauf avec DataPump ( bug ? )
●
Doit être unique pour un même utilisateur quelque soit l'objet.
●
Ne doit pas être un mot réservé Oracle.
La SGA
●
●
●
●
Zone mémoire partagée par les processus
Oracle
Allouée au démarrage de l'instance et libérée
lors de son arrêt.
Dimensionnable à chaud par les paramètres :
●
sga_target,
●
sga_max_size
Divisée en pool dont la gestion de certains peut
être automatique ( 10g et + ) ou manuelle.
Pool de la SGA
System Global Area
Shared Pool
Database
Buffer Cache
Library Cache
Ordres SQL
Insert, Select,
Delete, PL/SQL...
●
Database Buffer Cache : cache des données
●
Shared Pool
●
Library Cache → cache des requêtes SQL
●
Dictionnary Cache → cache du dictionnaire des données
●
Result Cache → Résultats de requêtes.
Dictionnary
Cache
Result
Cache
JAVA POOL
Redo
Log
Buffer
LARGE POOL
STREAM POOL
●
RedoLog Buffer : tampon pour les transactions sur la BD
●
Large Pool : utilisée pour des processus optionnels ( RMAN, configuration en serveur partagé )
●
Java Pool : à 0 si la machine virtuelle java de Oracle n'est pas utilisée
●
Stream Pool : tampon pour échange via flux stream ( fonctionnalité non maintenue post 11g )
●
En cas d'utilisation de blocs Oracle de tailles multiples, la SGA contient en plus un pool par taille de blocs
qui se trouvent dans le Database Buffer Cache.
Database Buffer Cache
●
●
●
●
●
Contient les blocs de données Oracle les plus utilisés
●
Table
●
Index
●
Segment d'annulation
Lu par le processus DBW0 afin d'écrire dans les fichiers de données.
Les blocs doivent être dans ce pool pour pouvoir être traités par une requête
SQL.
Dimensionné par les paramètres suivants :
●
db_block_size → bloc standard
●
db_nK_cache_size → blocs multiples, n valant 2,4,8,16 ou 32.
Dans certaines configurations avancées il est possible de définir deux autres
zones dans ce pool
●
●
KEEP → données devant rester le plus possible en cache → db_keep_cache_size
RECYCLE → données ne devant pas rester trop longtemps dans le cache →
db_recycle_cache_size
Shared Pool
●
Composée de deux structures
●
Library Cache
–
–
–
●
–
●
●
Phase de parsing
Dictionnary Cache
–
●
Texte de l'ordre SQL
Sa version analysée
Son plan d'exécution
Description des tables
Droits des utilisateurs
Dimensionnée par le paramètre shared_pool_size
L'équilibrage Library Cache / Dictionnary Cache est assuré par
Oracle.
Son paramétrage est complexe et influe énormément sur les
performances de Oracle.
Library Cache
●
Une requête SQL passe par 2 ou 3 phases
●
Analyse ( parsing )
–
–
–
●
●
Syntaxiquement correcte
Sémantiquement correcte : les données existent et l'utilisateur a le droit de
les utiliser.
Déterminer le plan d'exécution ( se base sur des statistiques )
●
Exécution ( execute )
●
Recherche ( fetch ), uniquement pour les select
La phase d'analyse est longue et consommatrice de
ressources.
Le stockage en Library Cache permet en cas d'exécution
multiple de la requête de ne pas refaire la phase d'analyse →
requêtes identiques
Requêtes identiques
●
Oracle analyse le texte d'une requête au caractère près.
●
Les requêtes suivantes sont toutes différentes :
●
●
●
select * from client where id = 1;
●
select * FROM client Where id = 1;
●
select * from client where id = 2;
Il importe dans une application de coder selon une norme
( majuscule/minuscule, espace... )
Pour les valeurs variables il faut utiliser des variables bind afin d'affecter
un paramètre à la requête :
●
●
●
select * from client where id = :v;
La paramètre cursor_sharing=force transforme tous les littéraux en
variables bindées. Cet "artifice" aide un peu Oracle.
Il s'agit d'un axe important lors d'une démarche d'optimisation du code
SQL. L'amélioration des performances peut être spectaculaire.
Dictionnary Cache
●
●
●
●
Tout Oracle est dans Oracle → dictionnaire des
données.
Le dictionnaire des données stocke l'ensemble des
informations de la base
●
Structure des tables, colonnes, type...
●
●
Stockage...
Lors de la phase d'analyse, le dictionnaire des données
est sollicité pour valider sémantiquement la requête.
Oracle cherche à maintenir la plus grosse partie, voir
l'ensemble, du dictionnaire dans cette zone.
Result Cache
●
●
●
●
●
La version 11g de Oracle introduit une zone
suppémentaire.
Cette zone est située dans la Shared Pool donc en
SGA.
Elle contient le résultat produit par une ou des
requêtes précédente.
Le Result Cache est davantage un concept
programmation qu'administration.
L'annexe de ce document présente mieux le
Result Cache.
Redo Log Buffer
●
●
●
Tampon mémoire sur toute transaction
●
insert
●
update
●
delete
A chaque transaction une entrée de redo est écrite dans ce pool
Le processus LGWR écrit dans les fichiers de journalisation
( redolog ) selon certains événements ( voir plus loin ),
●
Les select n'utilisent pas beaucoup voir pas du tout ce pool,
●
Dimensionné par le paramètre log_buffer
●
●
La chaine redolog buffer, LGWR et fichiers redolog est un goulot
d'étranglement au niveau de Oracle ( base OLTP) car l'ensemble
des transactions passe par elle.
Son optimisation est complexe mais fondamentale.
Notion de granule
●
●
Plus petite unité d'allocation mémoire des pool
de la SGA
Sa taille dépend de la taille de la SGA
●
●
●
4 Mo si la SGA est inférieure ou égale à 1Go
8 Mo ( Windows ) ou 16 Mo ( autres OS ) si la SGA
est supérieure à 1Go
L'allocation est toujours un multiple du granule
à la valeur supérieure.
Les transactions
●
●
●
●
Une transaction porte sur les ordres SQL :
●
insert,
●
update,
●
delete.
L'enregistrement définitif d'une transaction doit être
explicitement fait par la commande :
SQL> commit;
Il est possible d'annuler une transaction par la commande :
SQL> rollback;
Les transaction utilisent les redolog et des segments
d'annulation ( anciennement rollback segment → tablespace
undo ).
Principe des transactions
Après t5 pour revenir à t0, il faut utiliser le mode FLASHBACK de Oracle
TEMPS
t0
t1
commit;
commit;
t2
t3
t4
t5
rollback;
commit;
rollback;
Les transactions t2 et t3
sont annulées
Les données de la base
correspondent à t1
t1
Les données de la base
correspondent à t4
Point de contrôle
●
●
Un rollback ramène la base dans l'état du dernier commit.
Il est possible de mémoriser un ou plusieurs états de la base lors
d'une transaction → SAVEPOINT
●
SQL> insert into compositeur values ( '25', 'Franz', 'Schubert' ) ;
●
SQL> savepoint s1 ;
●
SQL> insert into compositeur values ( '26', 'Joseph', 'Haydn' ) ;
●
SQL> rollback to s1 ;
●
SQL> commit ;
●
Seule la ligne '25', 'Franz', 'Schubert' est enregistrée dans la base.
Processus
●
●
●
●
●
Lancés au démarrage de Oracle
Il existe environ une trentaine de processus Oracle. Leur lancement dépend de la
configuration de oracle.
Certains processus peuvent être lancés en plusieurs exemplaires, notamment DBWn,
ARCn et CJQn. Le n désigne le nombre 0 pour le premier...
Le nom des processus est normalisé sur 4 caractères ( plus pour les processus en
multi-lancement ). Les processus standards sont les suivants :
●
DBWn
●
LGWR
●
CKPT
●
SMON
●
PMON
●
CJQn
●
ARCn ( optionnel )
Windows n'utilise pas des processus, mais des threads qui sont regroupés dans un service
unique.
DBWn
●
●
●
●
Database Writer → DBW0
Chargé d'écrire les blocs modifiés du Database Buffer Cache dans les fichiers de
données.
Sur les systèmes multi-processeurs ayant une forte activité de mise à jour il est
conseillé d'en lancer plusieurs en parallèle ( maxi 20 )
L'écriture est déclenché par un des événements suivants :
●
Un processus serveur ne trouve pas de place libre dans le Database Buffer Cache
●
Périodiquement pour faire avancer le point de reprise
●
Un COMMIT n'écrit pas forcément dans les données dans les fichiers.
●
A un instant t, la situation suivante est possible :
●
●
●
Un fichier ne contient pas les données commitées
Si le Database Buffer Cache est trop petit et que le commit tarde, les données non validées
peuvent être écrites dans les fichiers.
En cas de plantage à cet instant ?
●
Les transactions étant dans les fichiers de journalisation, l'instance au moment du redémarrage
remet les fichiers dans un état cohérent ( processus SMON ).
LGWR
●
●
●
Log Writer → LGWR
Ecrit le contenu du RedoLog Buffer dans le fichier de journalisation
courant.
L'écriture est déclenchée sur un des évènements suivants :
●
Une transaction est validée par un commit,
●
Le RedoLog Buffer est au tiers plein,
●
●
DBWn s'apprête à écrire des données modifiées mais non validées dans
ses fichiers,
Séquentiellement toutes les 3 secondes
●
C'est l'unique action produite lors d'un commit
●
L'écriture est rapide, notion de fast-commit.
●
Les processus DBWn et LGWR sont de véritables "bêtes de somme",
ce sont eux qui assurent la part la plus importante du travail de
Oracle.
CKPT
●
●
●
●
●
Checkpoint → enregistre le point de reprise dans le fichier
de contrôle et les fichiers de données.
Périodiquement les blocs modifiés dans le Database Buffer
Cache sont écrits dans les fichiers de données →
Cohérence des numéros SCN
Ce mécanisme définit un point de reprise dans les fichiers
de journalisation → Modification la plus ancienne qui n'est
pas écrite dans les fichiers de données.
En cas d'arrêt anormal, ce point marque le début des
données à utiliser pour récupérer l'instance.
Un point de reprise peut être forcé par la commande alter
system checkpoint.
SMON
●
System Monitor
●
Chargé de récupérer l'instance après un arrêt anormal.
●
Libère les segments temporaires inutilisés
●
●
Compacte l'espace contigu disponible dans les
tablespaces gérés par le dictionnaire ( déconseillé par
Oracle ).
Effectue lors de la récupération 2 actions :
●
●
rollforward → applique aux fichiers de données les
transactions validées non écrites.
rollback → retire des fichiers de données les transactions
non validées.
Arrêt anormal de l'instance
●
En cas d'arrêt anormal la situation suivante peut être :
●
●
●
Les fichiers de données contiennent des transactions non
validées
Cette situation ne pose pas de problème
●
●
●
Des transactions validées ne sont pas écrites dans les fichiers de
données
Les fichiers de journalisation contiennent les informations pour
refaire les transactions validées et défaire les transactions non
validées.
Cette action est automatique via le processus SMON
Lors de la validation d'une transaction un numéro SCN est affecté par
Oracle. Ce numéro est fondamental pour que le système sache ou il
en est.
Numéro SCN
●
System Change Number. Horloge interne à Oracle.
●
Stocké dans le fichier de contrôle.
●
●
●
●
●
●
Unique, s'accroît dans le temps. Ne prend jamais la valeur 0 tant que la base n'est
pas recréée.
Oracle effectue une restauration uniquement par rapport au SCN
Au démarrage de la base, le processus SMON vérifie le SCN dans toutes les entêtes
des fichiers de données. Les SCN doivent être identiques à celui du fichier de
contrôle.
Le SCN joue également un rôle important pendant la lecture des blocs Oracle.
Au début, un SCN est attribué à une transaction (SCN1), après elle lit le SCN de la
dernière modification dans le bloc (SCN2), si SCN2 est supérieur à SCN1, cela
signifie que le bloc à été modifié après le démarrage de la transaction.
La requête suivante donne le SCN courant
SQL> select dbms_flashback.get_system_change_number() from dual;
PMON
●
●
●
Process Monitor
Chargé du nettoyage lors du plantage d'un
processus utilisateur.
●
Annulation de la transaction → rollback
●
Libération des verrous et des ressources
Peut détecter la non présence d'un utilisateur
●
Utilisateur connecté n'ayant pas fermé sa session
●
L'application utilisateur est plantée
●
Le réseau est coupé...
CJQn
●
●
●
Job Queue
Chargés d'exécuter des taches périodiques
programmées par Oracle → cron interne à
Oracle.
Le processus CJQn surveille si il y a des
travaux à lancer et démarre des processus
esclaves ( J000 à J999 ).
ARCn
●
Archiver
●
Ce processus est optionnel
●
●
●
●
Il permet l'archivage des fichiers de journalisation pleins
avant leur effacement
La base fonctionne en mode ARCHIVELOG
Il est fortement recommandé d'activer ce mode de
fonctionnement en production. En cas de crash, si les
archivelogs sont préservés, Oracle peut reconstruire
toute la base de donnée jusqu'au moment du crash.
Inconvénient → Demande de l'espace disque pouvant
être important.
Volume des archivelogs
●
Soit des groupes de redolog de 50Mo.
●
Avec un switch par 1/4 heure
●
Volume d'archivelogs :
●
●
En 1 heure : 200Mo
●
En 1 jour : 4,8Go
●
En 1 semaine : 33,6Go
●
En 1 mois : 144Go
Les archivelogs sont, en général, conservés
uniquement entre deux sauvegardes.
Les processus serveurs
●
●
●
●
●
●
●
Chargés de traiter les requêtes des utilisateurs
Communiquent avec le Database Buffer Cache soit en local, soit via le
réseau ( couche Oracle*Net ).
Par défaut Oracle utilise un processus serveur par connexion utilisateur
→ mode serveur dédié.
Oracle peut être configuré en serveur partagé, mode MTS, afin qu'un
processus serveur puisse être utilisé par plusieurs utilisateurs différents.
La configuration d'un serveur partagé est complexe et n'est pas couverte
par ce cours. Elle ne doit être utilisée que dans des cas très spécifiques.
Les processus serveurs utilisent une zone mémoire dédiée : la PGA
En cas d'utilisation d'un serveur en MTS ( partagé ), une partie de la PGA
est stockée dans la Large Pool de la SGA.
Dédié vs Partagé
●
Dédié est le mode de serveur par défaut d’Oracle.
●
●
●
Une session utilisateur utilise un processus serveur dédié à cette session.
Le mode serveur dédié est souvent utilisé lorsque des utilisateurs adressent
directement les instances en sessions distantes ou bien lorsque des applications
spécifiques adressent les instances.
Partagé ou encore MTS (« Multi Threaded Server ») est un bon choix lorsque
le nombre d’utilisateurs qui s’adressent à l’instance commence à approcher
100 sessions simultanées.
●
●
●
●
A ce moment là, le nombre de processus serveur dédié peut alourdir inutilement la
charge et la consommation mémoire.
Le mode partagé part du principe que le nombre de processus serveur est plus petit
que le nombre de sessions utilisateurs établies mais que, à un instant t, ce nombre
n’est jamais atteint. On économise alors de la CPU et de la mémoire.
Un Dispatcheur (DISPATCHER) reçoit les requêtes de tous les processus utilisateurs
et se charge de les stocker dans une file d’attente de requêtes entrantes (Queue de
requêtes ou « Query Queue »).
Les processus serveurs partagés, en fonction de leur disponibilité, traitent les
messages postés dans cette file d’attente et stockent les réponses dans une file
d’attente de réponses (Queue de réponses ou « Response Queue »).
PGA
●
Program Global Area
●
Pour un processus serveur la PGA contient :
●
●
●
●
Une zone de travail SQL pour certaines opérations, notamment les tris.
●
Des informations sur la session
●
Des variables de session
●
Des informations sur le traitement des requêtes
La PGA allouée à l'ensemble des processus serveurs est
nommée PGA agrégée.
Depuis la 9i la PGA est gérée dynamiquement via le paramètre
pga_aggregate_target.
Ainsi la quantité de PGA affectée à chaque processus est
automatiquement gérée par Oracle.
La gestion de la mémoire
●
Pour la PGA la gestion est automatique, le mode manuel est possible
mais déconseillé.
●
SGA Manuelle ou Automatique
●
Pour la SGA la gestion manuelle permet de définir chaque pool individuellement
●
●
●
●
●
Obligation pré-10g
●
Complexe et figée, peut ne pas convenir selon certaines période d'activité de la base
La gestion automatique de la SGA permet de laisser Oracle définir dynamiquement les
pools suivants :
●
Database Buffer Cache
●
Shared Pool
●
Large Pool
●
Java Pool
●
Streams Pool
Affecter une valeur à l'un des pool alors que la SGA est en gestion automatique permet
de définir une valeur minimale de ce pool.
Seul le redolog buffer et éventuellement les zones pour taille de blocs différents du bloc
standard sont à définir manuellement, ainsi que les valeurs keep et recycle.
La gestion automatique de la SGA est conseillée et se paramètre en donnant une valeur
à sga_target et à sga_max_size.
Répartition SGA/PGA
●
●
Pour les bases transactionnelles ( OLTP )
●
SGA : 80% de la mémoire affectée à l'instance
●
PGA : 20 %
Pour les bases décisionnelles ( DSS )
●
SGA : 30 à 50% de la mémoire affectée à l'instance
●
PGA : 50 à 70 %
●
●
Dans une bases décisionnelle les processus serveurs
sont plus "gourmands" ( tris importants ).
Il s'agit d'une répartition de départ, devant être
affinée.
Exemple de répartition mémoire
●
Soit un serveur avec 1Go de RAM et une seule instance
Oracle de type transactionnelle.
●
20% pour l'OS → 200Mo
●
80% pour Oracle → 800Mo
●
●
●
80% pour la SGA → 640Mo
●
20% pour la PGA → 160Mo
Pour la PGA une bonne base peut être aussi d'affecter
de 5 à 10Mo par session simultanée.
Le système présenté en exemple doit donc supporter
sans problème la connexion de 16 à 32 utilisateurs en
simultané.
La mémoire et Oracle
●
●
●
●
Oracle n'est pas conçu pour fonctionner entièrement en
RAM.
Augmenter la mémoire sur un serveur n'est pas la solution
en cas de performance médiocre. L'effet inverse peut
même se produire → Oracle passant le plus clair de son
temps à gérer sa mémoire au lieu de traiter les requêtes.
Dans 95% des cas les mauvaises performances sont plus
dues à un code mal écrit ou à des plans d'exécution non
optimisé ( absence d'index ou statistiques non mises à jour
), qu'à un manque de mémoire système.
Il est très facile de diagnostiquer un problème mémoire
sous Oracle ( voir plus loin ).
Mémoire et 11g
●
●
●
La version 11g de Oracle défini un nouveau paramètre :
MEMORY_TARGET
La répartition SGA/PGA est alors automatiquement réglée
par Oracle.
Exemple :
●
●
●
●
MEMORY_TARGET=1G
Oracle gérera la répartition en fonction du besoin, il est donc dans
ce cas inutile de spécifier SGA_TARGET et
PGA_AGGREGATE_TARGET.
Ce paramètre ne fonctionne pas systématiquement.
MEMORY_TARGET est incompatible avec la gestion des
HUGE PAGES.
Le DBA
●
Administrateur de la base de données
●
Principales tâches
●
●
Installer les produits
●
Créer, démarrer et arrêter la BD
●
Gérer les structures de stockage
●
Gestion des utilisateurs et des droits
●
Sauvegardes et restauration
●
Assurer un fonctionnement optimal de la base de données.
Une base Oracle contient toujours 2 comptes administrateur ou DBA
●
sys, mot de passe par défaut : change_on_install
–
–
●
system, mot de passe par défaut : manager
–
●
sys possède le dictionnaire des données
c'est le compte utilisé pour arrêter ou démarrer la base
Possède des tables complémentaires utilisées par les outils Oracle
Laisser pour sys et system les mots de passe par défaut revient à donner
l'ensemble des droits sur la base de données à n'importe qui.
Identification privilégiée
●
Par le système d'exploitation
●
●
●
●
L'outil d'administration est alors lancé sans nom d'utilisateur ou de mot de passe avec le privilège
SYSDBA ou SYSOPER
Exemple avec SQL*Plus
sqlplus /nolog
SQL> connect / as sysdba
sqlplus ''/as sysdba''
Par fichier de mot de passe
●
●
●
●
●
●
L'utilisateur doit faire partie du groupe dba ou oper défini sous Linux ( ORA_DBA ou ORA_OPER
sous Windows )
Ce fichier est créé par l'utilitaire Oracle orapwd
Il doit se trouver dans le répertoire $ORACLE_HOME/dbs pour Linux ou %ORACLE_HOME
%/database pour Windows
Il doit avoir pour nom orapwSID.ora → SID étant le nom de l'instance Oracle
Exemple pour une base nommée RED
orapwd file=$ORACLE_HOME/dbs/orapwRED.ora password=manager11
Exemple avec SQL*Plus
sqlplus /nolog
SQL> connect sys/manager11 as sysdba
Bien que les 2 modes soient possibles, certaines fonctionnalités Oracle exigent une
authentification par fichier de mot de passe ( démarrer une base à distance par exemple ).
Utilisation de SYS ou SYSTEM
●
●
●
L'administration courante ne demande pas d'utiliser le compte
sys.
Le compte system permet de :
●
Gérer les structures de stockage
●
Gérer les utilisateurs
●
Gérer les objets d'un schéma
Le compte sys, privilège sysdba est requis pour :
●
Créer la base de données
●
Arrêter ou démarrer la base
●
Effectuer les opérations de récupération
●
Il est implicitement utilisé par RMAN pour la sauvegarde et la
restauration.
Le compte system
●
●
●
System est un utilisateur comme un autre au
niveau Oracle.
Il dispose d'un rôle DBA.
Pour des raisons de sécurité, ce compte est
souvent verrouillé après la création de la base.
Autres comptes Oracle
●
●
●
●
Lors de la création d'une base de données
deux autres comptes peuvent être créés
sysman, utilisé par le database control ( Oracle
Enterprise Manager )
sysman à pour mot de passe par défaut :
change_on_install et est un compte DBA.
dbsnmp, utilisé par un agent Oracle Entreprise
Manager pour superviser une base. Ce compte
est utilisé pour mettre en place le Grid Control
Dictionnaire des données
●
Ensemble de tables contenant des informations sur
les objets de la base.
●
Sa mise à jour est assurée par Oracle
●
Les tables sont consultables par select.
●
Pour la plupart il s'agit en fait de vues
●
Les tables du dictionnaire se classent en 3 catégories
de préfixe :
●
user_ : tables dont l'utilisateur est propriétaire,
●
all_ : tables auxquelles l'utilisateur a accès,
●
dba_ : tables accessibles uniquement au DBA.
Structure du dictionnaire des
données
DBA_TABLES
Ensemble des tables de la base
de données. Accès réservé au DBA.
ALL_TABLES
Tables accessibles
par l'utilisateur. Notion de grant.
USER_TABLES
Tables possédées
par l'utilisateur.
Vues dictionnaire vs Performance
Vues dictionnaire
●
●
●
●
●
Préfixée par DBA_, en
général au pluriel.
Vues performance
●
Exemple :
DBA_DATA_FILES.
●
Visibles base ouverte.
●
Données généralement
en majuscules.
●
Statiques, non effacées
si base arrêtée.
●
Préfixée par V$, en
général au singulier.
Exemple :
V$DATABASE.
Visibles base montée.
Données généralement
en minuscules.
Dynamiques, effacées à
chaque démarrage.
Vues du dictionnaire les plus utiles
●
●
●
●
DBA_TABLES : liste l'ensemble et les
caractéristiques de stockage des tables de la
base.
DBA_USERS : Informations sur les utilisateurs
de la base de données.
DBA_VIEWS : Liste les vues de la base de
données.
DBA_TAB_COLUMNS : Liste les noms des
colonnes et le type de données pour chaque
table.
Vues de performance
●
●
●
●
V$DATABASE : informations sur la base de
données.
V$SESSION : informations sur les sessions
connectées.
V$SESSION_WAIT : liste les événements
d'attente par session.
V$SQL : Requêtes SQL en cours.
Installation de
ORACLE
Installation
●
Oracle Universal Installer
●
La norme OFA
●
Prérequis
●
Installation
●
Post-installation
Linux vs Windows
●
●
●
●
L'installation sous Linux est un peu plus complexe car il
faut paramétrer le noyau, créer un user Oracle, installer
certains packages...
Sous Windows, il suffit d'insérer le CD-ROM et
l'installation démarre.
Il y a toutefois un pré-requis sous Windows, l'installation
se faisant souvent sous le compte Administrateur, celuici doit disposer du droit "Ouvrir une session en tant que
tâche", sinon certaines fonctions seront inaccessibles
Les slides suivants concernent donc uniquement Linux.
Information
●
●
●
Sur le blog silverlake, dans la partie wiki se
trouve une procédure complète et très détaillée
de l'ensemble de l'installation d'une base
Oracle 11g sur un serveur Centos 5.5
Cette procédure reprend la quasi totalité des
manipulations vues en cours.
http://www.silverlake.fr/wiki
●
Rubrique "Installation d'un serveur Oracle 11g"
Installation Serveur
●
●
Une interface graphique est indispensable. Sinon il faut utiliser le
mode silence.
Sur un serveur linux la couche X-Window suffit et il est simple de
faire un export display via ssh :
●
●
●
●
●
ssh -X oracle/manager11@serveuroracle
Il est possible de faire des installations silencieuses avec un
fichier de pré-configuration , un exemple est présenté plus loin.
L'installateur de Oracle est écrit en Java et identique sur toutes les
plate-formes
Bien lire les prérequis Oracle dépendant de la plate-forme utilisée.
L'ensemble de la documentation est disponible par l'url suivante :
http://www.oracle.com/pls/db112/homepage
La norme OFA
●
●
●
●
Oracle Flexible Architecture
Ensemble de recommandations sur l'arborescence et le nommage des fichiers
du serveur.
Un des principes est de séparer le ou les produits Oracle installés des fichiers
de bases de données.
OFA permet une cohabitation facile de différentes versions de Oracle sur le
même serveur.
●
OUI, respecte la norme OFA
●
Le standard OFA se base sur 2 variables d'environnement :
●
ORACLE_BASE, répertoire racine de Oracle
●
ORACLE_HOME, sous répertoire de ORACLE_BASE, donnant le produit Oracle utilisé.
●
●
En modifiant ORACLE_HOME il est ainsi possible d'utiliser une 9i et une 10g sur le même
serveur très simplement.
Le texte original de la norme OFA ( 1995 ) est disponible sur l'URL suivante :
http://www.lifeaftercoffee.com/downloads/oracle_ofa_whitepapaer.pdf
Arborescence OFA
/u01/app/oracle/
$ORACLE_BASE
Binaires
Oracle
product/
9.2.4/dbhome_1
10.2.0/dbhome_1
11.2.0/dbhome_1
$ORACLE_HOME
RED
BLUE
BLACK
Fichiers
Bases de
données
oradata
Installation Orsys
Linux
●
Au démarrage du poste, choisir Oracle Linux.
●
Se connecter avec le compte oracle/oracle
●
Le compte root n'est requis que
ponctuellement. Le mot de passe root est root (
root01 ) sur certaines plate-formes.
Installation d'Oracle 11
●
Ne pas utiliser su, mais se déconnecter de la session
root pour revenir à la fenêtre de connexion.
●
Se reconnecter oracle/oracle.
●
Se déplacer dans le dossier d'installation :
●
●
cd /Source_Installation/Oracle_11gR2/Oracle_11gR2
L'installateur se lance ainsi :
●
./runInstaller
●
Accepter l'erreur éventuelle de swap en tapant "Y" au message.
●
Sous Windows, il suffit de cliquer sur "setup.exe"
●
Sauf indication contraire, il suffit la plupart du temps de valider
l'écran via le bouton "Suivant"
Décocher cette case
Message sur e-mail
●
Ne pas tenir compte de cet avertissement et
répondre « Oui »
Choisir cette option
Installer uniquement le logiciel
Choisir Base de données mono-instance
Choisir la version Entreprise
Licences et Editions Oracle
●
●
Oracle propose 2 types de licences
●
Par utilisateur ( minimum 5 ou 25 selon les éditions )
●
Par processeur ( intéressant à partir de 50 utilisateurs )
Les versions sont :
●
●
Entreprise → Toutes les fonctionnalités, pas de limitations
Standard → Certaines fonctions absentes ( partitionning, dataguard, flashback database ). Limitée à 4
processeurs.
●
Standard One → Limitée à deux processeurs, pas de possibilité RAC.
●
Il existe une version gratuite, nommée Oracle XE avec les limites suivantes :
–
–
–
●
●
●
1 processeur
1Go de RAM
BD de 15Go maxi en 11g ( 4Go en 10g ).
L'intégralité des produits Oracle, y compris la documentation, est disponible en
téléchargement gratuit sur le site Oracle Technology Network.
Ces versions ne sont toutefois pas les dernières en date.
Oracle autorise l'utilisation gratuite à des fins de formation, développement, test de ses
produits et demande l'acquisition de licence en cas de passage en production.
●
L'achat d'un produit Oracle donne l'accès à My Oracle Support ( ex Metalink ).
●
Un compte My Oracle Support est requis pour accèder aux mises à jour et correctifs.
Tarif Oracle novembre 2014 ( en
Dollar USA )
Ne pas tenir compte de
Messages d'erreurs éventuels.
Scripts de configuration
●
Ouvrir une session en parallèle en tant que root
et exécuter les deux scripts présentés.
Définition des variables
d'environnement
●
Editer le fichier de configuration du profil de
l'utilisateur Oracle
●
●
●
vi /home/oracle/.bash_profile
Ajouter au fichier les lignes suivantes:
●
export ORACLE_BASE=/u01/app/oracle
●
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
●
export ORACLE_OWNER=oracle
●
export NLS_LANG=FRENCH_FRANCE.UTF8
●
export PATH=$PATH:$ORACLE_HOME/bin
Sourcer le fichier
●
. .bash_profile
Test SQL*Plus
●
La connexion SQL*Plus doit être opérationnelle.
[oracle@lx13 ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Mar. Avr. 2 15:22:58 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> exit
[oracle@lx13 ~]$
Fin spécifique Orsys
Installation silencieuse
●
Permet de ne pas utiliser le mode graphique.
●
Utile si l'unique mode de connexion au serveur est ssh.
●
●
●
●
Demande un fichier de réponses aux questions de
l'installeur OUI.
Un exemple documenté est fourni dans le répertoire
database/responses du média d'installation.
Attention selon la version de Oracle, les options du fichier
réponse varient. Celui de la 11.2.0.1 est différent de la
11.2.0.2.
Il est possible de procéder à une installation graphique et
d'enregistrer les réponses dans un fichier.
Exemple de fichier réponse
●
Fichier /home/oracle/db.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v11_2_0
oracle.install.option=INSTALL_DB_SWONLY
ORACLE_HOSTNAME=lx81
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/u01/app/oraInventory
SELECTED_LANGUAGES=en,fr
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
ORACLE_BASE=/u01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.isCustomInstall=false
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
DECLINE_SECURITY_UPDATES=true
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
●
Lancement de l'installation
●
●
●
./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -responseFile
/home/oracle/db.rsp
Les clauses -ignoreSysPrereqs et -ignorePrereq sont requises si
l'installation n'est pas sur une version certifiée ( Redhat... )
Il faut en fin d'installation exécuter les scripts $ORACLE_HOME/root.sh
et $ORACLE_BASE/oraInventory/orainstRoot.sh en se connectant root.
Le réseau et ORACLE
Oracle*Net
Oracle * Net
●
Rôle de Oracle*Net, ancien nom SQL*Net
●
Configuration côté serveur
●
Configuration côté client
Rôle de Oracle*NET
●
●
●
Couche réseau de Oracle
Rend transparent pour les applications la localisation des bases de
données
Les fichiers de configuration Oracle*Net peuvent être pointés par la
variable d'environnement $TNS_ADMIN
●
Export TNS_ADMIN=$ORACLE_HOME/network/admin
sqlplus scott/tiger@red
Client
Oracle
Le client doit
résoudre un nom
de service
réseau
TCP/IP
LISTENER
Port 1521
Serveur
Oracle
Sur le serveur
un processus
écoute les demandes
de connexion des clients
RED
Configuration serveur
●
Un processus, le listener, écoute le réseau sur le port 1521 d'un réseau TCP/IP
●
Il est possible de configurer plusieurs processus d'écoute sur le même serveur
●
Ils doivent porter un nom différent
●
Ils doivent écouter sur des ports distincts
●
Par convention le processus d'écoute se nomme LISTENER
●
Le port d'écoute 1521 est aussi une convention
●
Il est possible d'utiliser un autre nom et/ou un autre port d'écoute.
●
Il est conseillé de renseigner le port d'écoute dans le fichier /etc/services.
●
La configuration du listener se fait dans un fichier, listener.ora, situé sous
$ORACLE_HOME/network/admin.
●
C'est le seul fichier à configurer, sauf si le serveur est aussi client d'un autre serveur.
●
Le listener se lance par la commande lsnrctl start, s'arrête avec lsnrctl stop
●
●
●
Sous Windows, il existe un service spécial pour le listener : « OracleOraDb11g_home1TNSListener »
qui se démarre/s'arrête par la commande net start/stop
La commande lsnrctl status permet de visualiser l'état du listener.
Si le serveur comporte plusieurs versions de Oracle ( 9i, 10g, 11g... ) il faut toujours utiliser la
version la plus récente du listener.
LISTENER.ORA
●
●
Configuration via deux programmes
●
Assistant netca
●
Programme netmgr
Edition directe du fichier de configuration
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION (ADDRESS=(PROTOCOL = TCP)(HOST = lx810 )(PORT = 1521))
)
)
Il est possible de mettre l'adresse IP ou le nom du serveur,
toutefois celui-ci doit être résolu ( voir fichier /etc/hosts )
Assistant netca
Configuration du listener avec netca
●
En ligne de commande taper : netca
●
Dans l'assistant choisir: Configuration d'un processus d'écoute et faire Suivant
●
Choisir Ajouter et faire Suivant
●
Nommer le processus d'écoute LISTENER, ce qui est fait par défaut, et faire Suivant
●
Choisir le protocole TCP et faire Suivant
●
Dans l'écran du choix du port, valider le port standard 1521 et faire Suivant
●
●
●
●
A la question créer un autre processus d'écoute, répondre Non et faire Suivant deux
fois afin de revenir à l'écran principal et choisir Terminer.
En ligne de commande taper : lsnrctl status pour vérifier le lancement correct du
listener.
Vérifier le contenu du fichier $ORACLE_HOME/network/admin/listener.ora
Important : TCP n'est pas le seul protocole possible, mais le plus courant. En local sur
une même machine les protocoles IPC ou BEQ sont plus performants. Il est également
possible d'utiliser IPX de Novell.
Listener et procédures externes
●
●
●
Une procédure externe est écrite dans un langage autre que le PL/SQL et
pouvant être appelée à partir du PL/SQL.
Seul les langages C et Java sont supportés nativement par Oracle.
Sous Windows il s'agit d'un fichier .DLL, sous Linux, il s'agit d'un fichier
.so
●
Ces fichiers peuvent contenir une ou plusieurs procédures externes.
●
La gestion des procédures externes dépasse le cadre de ce cours.
●
La configuration du listener via l'assistant netca suppose l'utilisation de
procédures externes en incluant dans le listener.ora cette ligne :
●
●
(DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)))
Si la base de données ne fait pas appel à des procédures externes,
Oracle recommande de supprimer cette configuration améliorant ainsi la
sécurité.
Configuration client
●
La configuration d'un client demande deux choses :
Comment résoudre les noms de service → sqlnet.ora
●
Configurer les différentes méthodes de résolution de nom de service →
tnsnames.ora
●
●
Ces deux fichiers sont sous $ORACLE_HOME/network/admin
●
Ils se configurent via netca, netmgr ou en éditant directement les fichiers.
●
sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
●
tnsnames.ora
RED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = lx-1-3 )(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = RED)
)
)
Configuration des méthodes de
résolution avec netca
●
●
●
●
●
En ligne de commande taper : netca
Choisir Configuration des méthodes de résolution de noms et faire
Suivant
Passer les méthodes de la fenêtre méthodes disponibles à la fenêtre
méthodes sélectionnées en utilisant l'icône de flèche choisir :
●
Résolution locale de noms
●
Résolution de noms Easy Connect
Faire Suivant à deux reprises pour revenir à l'écran principal et Faire
Terminer.
Vérifier le contenu du fichier
$ORACLE_HOME/network/admin/sqlnet.ora qui doit contenir la ligne
suivante :
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
Connexion simplifiée
●
Protocole easy-connect
●
Apparu en 10g
●
Ne fonctionne que sous TCP/IP
●
Ne demande pas de configuration du client
●
La méthode peut être toutefois présente dans sqlnet.ora
●
●
Exemple :
sqlplus scott/tiger@//lx-1-3/red
En cas d'utilisation d'un port différent du standard il faut
le préciser dans la commande
●
sqlplus scott/tiger@//lx-1-3:1522/red
Création d'une base
de données
Création d'une base de données
●
●
●
Il existe plusieurs méthodes
●
Manuellement
●
Graphiquement avec DBCA
●
DBCA en mode silencieux
●
Clonage
Ce cours présentera chaque méthode
Il sera également présenté la création et la
gestion OMF ( Oracle Management Files )
Etape de création de la BD
●
●
Dans un premier temps le modèle physique de la BD doit être conçu. Cette
étape est obligatoire afin d'administrer efficacement une BD.
Création proprement dite
●
Création d'une instance → définition d'un fichier de paramètres.
●
Création des fichiers de la base ( control files, redolog, tablespaces Oracle )
●
Création du dictionnaire des données
●
La base est à ce stade une enveloppe vide, prête à recevoir les données
applicatives.
●
Création des structures de stockage ( tablespaces )
●
Création du ou des schémas applicatifs ( propriétaire du schéma )
●
Création des objets dans chaque schéma ( tables, index, vues...)
●
Création des utilisateurs finaux ( user applicatif ) gestion des droits
●
Sauvegarde
Fichier de paramètres
●
●
●
●
●
●
●
Avant de créer une première base de données il est nécessaire de maîtriser les
paramètres Oracle.
Depuis la 9i, Oracle conseille l'utilisation d'un fichier de paramètres serveur ( spfile ).
Toutefois pour créer ce fichier l'étape fichier texte ( pfile ) est indispensable.
Il est ensuite possible de créer le spfile depuis le pfile et réciproquement.
Le fichier de paramètre texte est placé dans le répertoire
$ORACLE_BASE/admin/SID/pfile et se nomme initSID.ora. SID étant le nom de
l'instance Oracle
Il y a plus de 340 paramètres Oracle documentés. En règle générale seule une
trentaine de paramètres sont à connaître.
Il existe des paramètres non documentés, dont le nom commence par "_" → Il ne
faut jamais utiliser ces paramètres sauf recommandation directe par le
support Oracle.
Le fichier de paramètre, texte ou serveur, est le premier fichier lu quand l'instance
démarre.
Principaux paramètres ...
●
DB_NAME : Nom de la base de données. 8
caractères maxi, le plus souvent égal à ORACLE_SID
●
●
DB_NAME = RED
DB_DOMAIN : Localisation logique de la base de
données. Associé à DB_NAME, il permet à Oracle de
construire un nom global.
●
DB_DOMAIN=PARIS.ORSYS.FR
●
→ RED.PARIS.ORSYS.FR
●
●
Ce principe permet de différentier des bases ayant le même
nom sur des emplacements géographiques différents.
DB_DOMAIN peut contenir 128 caractères.
Principaux paramètres suite ...
●
●
●
●
COMPATIBLE : Indique un numéro de version Oracle avec laquelle la base doit être compatible.
Ceci permet de tester une nouvelle version en restant compatible avec l'ancienne.
●
Valeur de 10.0.0 à la version actuellement installée. Valeur par défaut : 11.0.0
CONTROL_FILES : Emplacement des fichiers de contrôles de la base. Le ou les fichiers de
contrôles permettent à l'instance Oracle après démarrage d'être montée.
●
Un seul est obligatoire, Oracle conseille 3 controlfiles sur des axes différents →
multiplexage.
●
CONTROL_FILES =
( "/u01/app/oracle/oradata/RED/control01.ctl", "/u02/app/oracle/oradata/RED/control02.ctl",
"/u03/app/oracle/oradata/RED/control03.ctl" )
DB_BLOCK_SIZE : Taille du bloc standard Oracle. Ne peut être modifié sans recréer la base.
La taille est de 2, 4, 8, 16 ou 32Ko. La taille est exprimée en octets.
●
DB_BLOCK_SIZE = 8192
●
Les systèmes transactionnels utilisent des petits blocs 4 ou 8Ko
●
Les systèmes décisionnels utilisent des blocs plus gros 16 voir 32Ko.
●
Oracle peut utiliser des tablespaces avec d'autres tailles de bloc que le bloc standard.
DB_nK_CACHE_SIZE : Taille dans le Database Buffer Cache pour les blocs de nKo. Ce
paramètre n'est utile que si on souhaite utiliser des tailles autres que le bloc standard. Sa
gestion est manuelle au sein de la SGA et doit donc faire l'objet de plus d'attention.
●
DB_16K_CACHE_SIZE = 25M
●
MEMORY_TARGET : Taille mémoire affectée à l'instance Oracle
●
●
SGA_MAX_SIZE : Taille maximale de la SGA
●
●
●
●
●
●
●
Ce paramètre permet la répartition automatique entre la SGA et la PGA. Il est apparu en 11g. Attention, il y a
certaines contraintes avant de pouvoir utiliser ce paramètre ( voir doc Oracle )
Ce paramètre permet de définir une limite pour la SGA dont la taille est fixée par SGA_TARGET permettant
ainsi son augmentation à chaud.
SGA_MAX_SIZE = 1G
SGA_TARGET : Taille souhaitée pour la SGA
●
SGA_TARGET = 640M
●
Cette taille peut être augmentée à chaud dans la limite de SGA_MAX_SIZE.
Par défaut SGA_MAX_SIZE = SGA_TARGET.
Si SGA_MAX_SIZE est supérieur à SGA_TARGET, l'OS alloue totalement la mémoire à la
valeur SGA_MAX_SIZE.
Il reste possible de définir chaque pool de la SGA individuellement, ce qui en règle générale
n'apporte aucune valeur ajoutée.
PGA_AGGREGATE_TARGET : Quantité de mémoire alloué à la PGA. La gestion interne est
automatique en fonction des besoins de chaque processus serveur.
●
PGA_AGGREGATE_TARGET = 160M
●
UNDO_MANAGEMENT : Mode de gestion souhaité pour les segments
d'annulation.
●
●
●
●
Manual est déconseillé, il implique une gestion via les rollback segments qui est
complexe. Cette méthode n'est qu'une fonction de compatibilité et obsolète. En 11g par
défaut la valeur est auto.
UNDO_MANAGEMENT = auto
UNDO_TABLESPACE : Tablespace contenant les segments d'annulation si la
gestion automatique est mise en place ( fortement conseillé ! )
●
●
AUTO ou MANUAL
UNDO_TABLESPACE = UNDO_TBS
NLS_LANGUAGE : Langage par défaut de l’instance, utilisé pour les messages,
les noms de jour et de mois et le tri.
●
Détermine aussi la valeur des paramètres NLS_DATE_LANGUAGE et NLS_SORT.
●
La valeur par défaut est dérivée de la variable d’environnement NLS_LANG.
●
NLS_LANGUAGE = french
●
●
●
●
DB_RECOVERY_FILE_DEST : Emplacement de la zone de récupération
rapide ( Flash Recovery Area ). Cette zone est la destination par défaut des
sauvegardes RMAN, des archivelogs, des fichiers Flashback...
●
Permet une simplification des mécanismes de reprise après défaillance.
●
Oracle conseille de mettre cette zone sur un disque dédié.
●
DB_RECOVERY_FILE_DEST = /u01/app/oracle/flash_recovery_area/RED
DB_RECOVERY_FILE_DEST_SIZE : Taille maximale de la zone de récupération rapide.
Obligatoire avec le paramètre précédent.
●
DB_RECOVERY_FILE_DEST_SIZE = 20G
●
Oracle préconise une taille égale à 2,5 fois la taille totale de la base de données pour cette zone.
OPEN_CURSORS : Détermine le nombre maximum de curseurs qui peuvent être ouverts
simultanément par une session.
●
Valeur par défaut : 50.
●
OPEN_CURSORS = 500
PROCESSES : Nombre maximum de processus qui peuvent se connecter simultanément
à l’instance. Compter un pour chaque session utilisateur simultanée, plus une quinzaine
pour Oracle et 10 de plus si utilisation du database control.
●
●
PROCESSES = 200
OPEN_CURSORS et PROCESSES sont fréquemment modifiés à posteriori Ils sont
fortement liés à la logique de programmation de l'application connectée.
●
BACKGROUND_DUMP_DEST : Répertoire de destination des traces des
processus d’arrière-plan et du fichier d’alerte de l’instance.
●
●
USER_DUMP_DEST : Répertoire de destination des traces des processus
utilisateurs.
●
●
●
●
BACKGROUND_DUMP_DEST = /u01/app/oracle/admin/RED/bdump
USER_DUMP_DEST = /u01/app/oracle/admin/RED/udump
DIAGNOSTIC_DEST : En 11g les 2 paramètres ci-dessus ne sont plus
conservés que pour la compatibilité. Oracle défini un nouveau format ( fichiers
XML ) pour les traces accessible par l'utilitaire adrci( voir plus loin ). Oracle
préconise d'utiliser en fait $ORACLE_BASE pour ce paramètre, ce qui est sa
valeur par défaut.
Connaître les paramètres présentés ici suffisent la plupart du temps. Consulter la
documentation Oracle pour en spécifier d'autres.
Tous les paramètres Oracle ont une valeur par défaut si ils ne sont pas
explicitement spécifiés.
Création manuelle
●
●
●
●
●
L'exemple présenté ici va créer une base de données nommée RED
avec le minimum requis
●
1 fichier de contrôle,
●
2 groupes de redolog...
Certains concepts ne seront abordés que plus tard dans le cours
●
tablespace temporaire
●
tablespace undo
Au fur et à mesure du cours, cette base sera modifiée afin de la
préparer à un environnement de production.
L'ensemble des commandes présentées peut ensuite être mis dans
un script afin d'automatiser la création.
Avertissement : bien respecter les noms et chemins des fichiers
pour la logique du cours.
Arborescence de la base de
données
●
●
●
La norme OFA sera respectée.
Toutes les manipulations se font sous le compte
Linux Oracle.
Vérifier $ORACLE_BASE et $ORACLE_HOME
●
●
●
echo $ORACLE_BASE → /u01/app/oracle
echo $ORACLE_HOME →
/u01/app/oracle/product/11.2.0/dbhome_1
En ligne de commande taper :
●
mkdir -p /u01/app/oracle/admin/RED/pfile
●
mkdir -p /u01/app/oracle/oradata/RED
Création du fichier de paramètres
●
vi /u01/app/oracle/admin/RED/pfile/initRED.ora
●
db_name = RED
●
db_block_size = 8192
●
control_files = /u01/app/oracle/oradata/RED/control01.ctl
●
sga_target = 320M
●
pga_aggregate_target = 80M
●
La taille du bloc standard est de 8ko
●
400Mo de RAM sont affectés à Oracle.
●
La SGA et la PGA sont définies statiquement.
●
La gestion automatique des segments d'annulation est
activée par défaut en 11g.
init.ora et ifile
●
●
●
●
Par défaut quand une instance démarre elle recherche son fichier de
paramètres sous $ORACLE_HOME/dbs ( %ORACLE_HOME%\database
pour Windows ). Or ceci ne respecte pas la norme OFA.
Pour utiliser cette fonctionnalité mettre en place un lien symbolique vers le vrai
fichier de paramètre sous $ORACLE_BASE/admin/SID/file
Pour la base RED
●
cd $ORACLE_HOME/dbs
●
ln -s $ORACLE_BASE/admin/RED/pfile/initRED.ora initRED.ora
Windows n'utilisant pas les liens symboliques il est possible d'utiliser la
directive ifile en créant un fichier initRED.ora sous %ORACLE_HOME
%\database\initRED.ora
●
cd %ORACLE_HOME%\database
●
Créer un fichier initRED.ora contenant la ligne suivante
●
ifile=%ORACLE_BASE%\admin\RED\pfile\initRED.ora
●
Il est possible d'utiliser aussi cette méthode sous Linux au lieu du lien symbolique.
Création du fichier de mot de passe
●
Ce fichier contient le mot de passe de l'utilisateur sys pour la
connexion en mode sysdba.
●
cd $ORACLE_HOME/dbs
●
orapwd file=orapwRED password=manager11
●
Sous windows il faut, en plus, créer un service avec oradim
ainsi :
●
●
●
●
oradim -new -sid RED -intpwd manager11 -startmode auto
-startype SRVC,INST
Ceci va également créer le fichier des mots de passe.
Voir aussi dans la base de registre les valeurs sous :
HKLM\SOFTWARE\ORACLE\KEY_Oracle_Home
La suppression d'un service se fait ainsi : oradim -delete -sid RED
Création de l'instance
●
Pour le cours charger le fichier createRED.sql ainsi
●
wget http://192.168.4.224/ORA/createRED.sql
●
export ORACLE_SID=RED
●
sqlplus /nolog
●
●
SQL> startup nomount;
●
SQL> create spfile from pfile;
●
SQL> shutdown abort;
●
●
SQL> start $HOME/createRED
Contenu du script createRED.sql
create database RED
character set AL32UTF8
national character set AL16UTF16
logfile
group 1 '/u01/app/oracle/oradata/RED/redo01a.log' size 50M,
group 2 '/u01/app/oracle/oradata/RED/redo02a.log' size 50M
datafile '/u01/app/oracle/oradata/RED/system01.dbf' size 500M extent management local
sysaux datafile '/u01/app/oracle/oradata/RED/sysaux01.dbf' size 500M
undo tablespace UNDO_TBS datafile '/u01/app/oracle/oradata/RED/undo_tbs01.dbf' size 25M
default temporary tablespace TEMP tempfile '/u01/app/oracle/oradata/RED/temp01.dbf' size 50M;
Création des tables du dictionnaire
●
SQL> start $ORACLE_HOME/rdbms/admin/catalog.sql
●
SQL> start $ORACLE_HOME/rdbms/admin/catproc.sql
●
●
Ces deux scripts sont assez long environ 10 minutes, le
premier est le plus rapide, le second un peu plus long.
Les messages d'erreurs sont normaux, car les scripts
détruisent des objets avant de les créer et comme ils
n'existent pas...
User sys et system
●
Donner un mot de passe à sys et system
●
SQL> alter user sys identified by manager11;
●
SQL> alter user system identified by manager11;
●
●
Le temps de création dépend de la machine, il
est sur une machine standard d'environ 15
minutes.
A ce stade l'enveloppe de la BD est prête, il reste
à configurer son accès par le réseau depuis les
postes clients.
PUPBLD.SQL
●
●
Sortir par exit et se reconnecter en system/manager11 et lancer le
script pupbld.sql
sqlplus system/manager11
SQL> start $ORACLE_HOME/sqlplus/admin/pupbld.sql
SQL> exit
●
●
Ce script créé une table, PRODUCT_USER_PROFILE, dont la
présence est testée par les outils Oracle lors de la connexion d’un
utilisateur. Si la table n’existe pas et que l’utilisateur n’est pas un DBA,
un message d’alerte est affiché, mais la connexion est acceptée.
La table PRODUCT_USER_PROFILE peut être utilisée pour limiter la
nature des ordres SQL qu’un utilisateur peut exécuter avec les outils
(par exemple, interdire l’utilisation de l’ordre UPDATE dans SQL*Plus)
→ Voir la doc SQL*Plus de Oracle.
SPFILE ou PFILE ?
●
●
La requête suivante permet de savoir si la base
a été démarrée avec un pfile ou un spfile
SQL> select decode(count(*), 1, 'spfile', 'pfile' )
from v$spparameter
where rownum=1
and isspecified='TRUE';
Accès client à la base RED
●
En ligne de commande lancer netca
●
Choisir : Configuration d'un nom de service local et faire Suivant,
●
Choisir Ajouter et faire Suivant
●
Dans le champ nom du service, mettre RED et faire Suivant
●
Choisir le protocole TCP et faire Suivant
●
Dans le champ nom d'hôte mettre l'adresse IP ou le nom du
serveur supportant la base et faire Suivant
●
Ne pas faire le test, il échouerait, faire Suivant
●
Renseigner le nom du service avec la valeur RED et faire Suivant
●
Répondre Non à la question de configuration d'un autre service
réseau et faire 2 fois Suivant pour revenir à l'écran principal. Sortir
par Terminer.
Accès aux autres bases RED
●
La configuration précédente permet à la machine locale de se connecter à RED, pour permettre la connexion depuis un client un
réseau, il faut modifier le fichier tnsnames.ora
●
Il est possible d'utiliser netca pour cela mais l'édition du fichier tnsnames.ora est plus simple et plus rapide.
●
vi $ORACLE_HOME/network/admin/tnsnames.ora
●
●
●
Recopier le bloc RED et effectuer les corrections en gras
RED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =LX-1-3)(PORT = 1521))
)
(CONNECT_DATA =
)
)
RED_LX-34-3 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = LX-34-3)(PORT = 1521))
)
(CONNECT_DATA =
)
)
La base RED, présente sur LX-34-3 est alors accessible ainsi
sqlplus system/manager11@RED_LX-34-3 → RED_LX-34-3 est la chaine de connexion Oracle*Net
Il est aussi possible d'utiliser la connexion easy-connect ainsi : sqlplus system/manager11@//lx-34-3:1521/red, si le port d'écoute
du listener est le 1521, il est inutile de le spécifier → sqlplus system/manager11@//lx-34-3/red
Diagnostic Oracle*Net
●
Si la connexion échoue, il faut vérifier :
●
Le serveur est accessible ? commande ping
●
La base est-elle démarrée ?
–
●
Sur le serveur le listener est-il lancé ?
–
●
●
●
ps -ef | grep RED
lsnrctl status
Pour tester la résolution correcte utiliser tnsping
Exemple :
tnsping red
→ retourne OK si la configuration est correcte.
Attention la commande tnsping ne vérifie pas si la base est
connue du processus d'écoute.
Erreurs Listener et TNS
les plus courantes
Image source :
http://www.dba-ora.fr
Enregistrement statique dans le
listener
●
●
●
●
●
Si le listener est démarré avant la base de données,
celle-ci s'enregistre automatiquement au moment de
son démarrage auprès du listener.
Si le listener est démarré après la base de données, le
listener ne connait pas forcement la base à écouter.
Il est parfois judicieux de spécifier statiquement dans la
configuration du listener quelles bases il écoute.
Cet enregistrement statique est obligatoire pour
démarrer une base à distance.
Le programme netmgr permet graphiquement de
rajouter une base dans le listener.
Enregistrer la base RED dans le
listener...
●
●
●
En ligne de commande taper : netmgr
Dans l'arborescence développer Local, Processus
d'écoute et mettre en surbillance LISTENER
Dans la combo de droite, choisir Service de base
de données et Cliquer sur le bouton Ajouter une
base de données
Enregistrer la base RED dans le
listener suite.
●
●
●
Renseigner les champs Nom global et SID avec la valeur
RED
En principe le répertoire d'origine ORACLE_HOME est
correct.
Faire ensuite Fichier et Enregistrer la configuration réseau
puis Quitter.
Vérification de l'enregistrement
statique de RED dans le listener
●
Editer le fichier $ORACLE_HOME/network/admin/listener.ora et remarquer la
présence de cette section dans la section
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = RED)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = RED)
)
)
●
●
●
Cette procédure est obligatoire pour démarrer une base de données depuis un
poste distant.
Bien que facultatif, il est de bonne pratique de renseigner statiquement les bases
dans le listener.
Recharger la configuration listener
●
lsnrctl reload
Enregistrer la base RED dans
oratab
●
●
●
Ce fichier est situé sous /etc et permet sous Linux de démarrer au
boot du serveur la base de données
Il permet aussi la cohabitation de base de données sous des
versions différentes.
vi /etc/oratab
●
RED:/u01/app/oracle/product/11.2.0/dbhome_1:Y
●
$ORACLE_HOME
●
Il faut de plus sous Linux créer un script de démarrage.
●
Charger le script ainsi
●
su - root
●
cd /etc/init.d/
●
wget http://192.168.21.24/ORA/oracle
Démarrer automatiquement les bases Oracle
●
Sous Windows il faut configurer les services en démarrage automatique.
●
Sous Linux créer /etc/init.d/oracle avec les lignes suivantes :
# chkconfig: 235 80 20
# description: ajout de service auto pour start/stop oracle
#!/bin/bash
ORACLE_OWNER=oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
case $1 in
start)
echo n "Démarrage Oracle DB:"
su $ORACLE_OWNER c "$ORACLE_HOME/bin/dbstart $ORACLE_HOME"
touch /var/lock/subsys/oracle
;;
stop)
echo n "Arrêt Oracle DB:"
su $ORACLE_OWNER c "$ORACLE_HOME/bin/dbshut $ORACLE_HOME"
rm /var/lock/subsys/oracle
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac
●
●
Le rendre exécutable : chmod 0755 /etc/init.d/oracle
Activer les niveaux d'exécution : chkconfig --add oracle et chkconfig oracle on ( centos ) ou
update-rc.d oracle defaults ( debian et ubuntu ).
PFILE vs SPFILE
●
Pour la création de la base RED nous avons utilisé un PFILE
●
Pour créer le SPFILE ( en sysdba )
●
●
Si le fichier se nomme initRED.ora et est situé sous $ORACLE_HOME/dbs, la commande
se résume à :
●
●
●
●
●
SQL> create spfile from pfile ;
La création du SPFILE permet la modification de certains paramètres Oracle à chaud,
sinon avec un PFILE il faut redémarrer la base.
Le SPFILE est un fichier binaire, il est situé sous $ORACLE_HOME/dbs et se nomme
spfileRED.ora pour la base RED.
Il est possible de créer un PFILE depuis le SPFILE
●
●
SQL> create spfile from pfile="/u01/app/oracle/admin/RED/pfile/initRED.ora";
SQL> create pfile='$HOME/initRED.pfile.ora' from spfile;
Important, le spfile est souvent "oublié" par les sauvegardes, il est certes facile à recréer
depuis une copie texte ( si elle existe ).
RMAN permet la sauvegarde et la restauration simple d'un spfile
Les paramètres Oracle
●
●
●
En 11g il y a plus de 340 paramètres Tous ont une valeur par défaut.
Les paramètres indiqués dans le PFILE ou SPFILE surchargent la valeur par
défaut.
La commande show parameter depuis le SQL donne la liste de tous les
paramètres avec leur valeur.
●
Il est possible de filtrer sur un mot contenu dans le nom du ou des paramètres
●
Exemple :
SQL> show parameter sga
lock_sga boolean
FALSE
●
pre_page_sga boolean
FALSE
●
sga_max_size big integer
320M
●
target big integer
320M
●
●
Modification des paramètres à
chaud
●
La base doit avoir été démarrée avec un spfile.
●
Il faut être connecté sysdba
●
Dans l'exemple nous allons modifier le paramètre open_cursors
●
La commande show parameter permet de visualiser la valeur actuelle.
SQL> show parameter open_cursors → 50
Passer la valeur à 500
●
●
SQL> alter system set open_cursors=500 scope=both;
● SQL> show parameter open_cursors → 500
La commande alter system parametre=valeur permet l'affectation
●
●
●
Il faut notifier à Oracle la notion de scope
memory → la modification est valide jusqu'au redémarrage de l'instance
● spfile → la modification sera prise en compte au redémarrage de l'instance
● both → la modification est valide et le sera après redémarrage.
En complément il est possible de spécifier l'option DEFFERED, seules les prochaines
sessions qui se connecterons auront la nouvelle valeur. Cette option n'a pas de sens avec un
scope à spfile et ne concerne pas tous les paramètres.
●
●
Gestion des paramètres
d'initialisation
●
●
Tous les paramètres ne sont pas modifiables à
chaud.
Pour certains seule la clause spfile de scope est
possible
●
●
●
Exemple : SGA_MAX_SIZE
Les paramètres sont modifiés au niveau global par
la commande alter system set
Ils peuvent être modifié pour une session, par la
commande alter session set , dans ce cas la clause
scope n'est pas précisé et seuls les paramètres
modifiables à chaud peuvent être utilisés.
Paramètres modifiables
●
●
●
●
●
La requête suivante permet de connaître les paramètres modifiables ou
non au niveau système et session
SQL> col name format a60;
SQL> select name, issys_modifiable sys ,isses_modifiable ses
from v$system_parameter order by name;
La colonne issys_modifiable, niveau système, peut prendre 3 valeurs :
●
IMMEDIATE → modifiable en mémoire, donc dans spfile via le scope=both
●
DEFERRED → la valeur est valide en mémoire pour les futures sessions
●
FALSE → modifiable uniquement dans scope=spfile
La colonne isses_modifiable, niveau session, peut prendre 2 valeurs :
●
TRUE → modifiable au niveau session
●
FALSE → non modifiable au niveau session
Outils d'administration
ORACLE
Outils d'administration
●
SQL*Plus
●
Diagnostics, le référentiel ADR
●
Oracle Enterprise Manager Database Control
●
SQL Developper
●
La documentation Oracle
SQL*Plus
●
Application en mode console
●
Outil de base du DBA
●
Saisie des ordres SQL
●
Lancement de scripts
●
Lancement de programme PL/SQL
●
Connexion en local en paramétrant la variable ORACLE_SID
●
Connexion par le réseau en utilisant un nom de service Oracle*Net
●
●
Exemple local :
sqlplus system/manager11
Exemple réseau
sqlplus system/manager11@RED
sqlplus system/manager11@//192.168.4.24/red ( syntaxe easy-connect )
Connexion SQL*Plus en SYSDBA
●
●
Utilisé pour créer, arrêter ou démarrer une base de
données.
sqlplus /nolog
SQL> connect / as sysdba → identification par OS
●
Variante :
sqlplus ''/ as sysdba''
sqlplus sys/manager11 as sysdba → identification par fichier de
mot de passe
–
●
●
sqlplus sys/manager11@RED as sysdba → identification à
distance, fichier de mot de passe obligatoire.
Exécuter un script
●
SQL> start script
●
●
SQL> @script →
●
●
L'extension .sql est prise par défaut
variante, @ = start
SQL> @?/rdbms/admin/utlsampl
●
●
? symbolise ORACLE_HOME
Equivalent à :
start
/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/utlsampl
Fonctions SQL*Plus utiles
●
●
Exécuter une commande OS
●
SQL> host cp fichier1.sql fichier2.sql
●
SQL> ! cp fichier1.sql fichier2.sql ( ne fonctionne pas sous Windows )
Définir l'éditeur
●
●
●
En cas d'erreur, il est possible d'utiliser un éditeur de texte pour modifier la
commande.
On utilise la commande ed
Par défaut sous Linux c'est ed qui est choisi, pour utiliser vi il faut définir la variable
_editor ainsi :
–
–
●
●
●
SQL> define _editor=vi
Pour rendre ceci permanent, editer le fichier $ORACLE_HOME/sqlplus/admin/glogin.sql et y
placer la ligne ci-dessus.
Le "/" en fin de fichier via la commande ed symbolise le ";", il ne faut donc pas mettre
de ";" pour terminer une commande modifiée par ed.
Une fois la commande éditée, sa re-exécution se fait par l'ordre run au niveau SQL.
Améliorer le prompt SQL
●
Rajouter dans le fichier $ORACLE_HOME/sqlplus/admin/glogin.sql la ligne suivante :
–
●
set sqlprompt ''_user'@'_connect_identifier >''
Le prompt SQL*Plus contiendra le nom de connexion et de la base de données.
Rappel des commandes SQL*Plus
●
La version Linux de SQL*Plus n'offre pas le rappel des commandes SQL à l'aide des touches
fléchées.
●
Cette fonctionnalité étant native sous Windows...
●
Les postes ORSYS disposent déjà de cette fonctionnalité.
●
Afin de disposer de cette ergonomie, il faut charger le package rlwrap
●
aptitude install rlwrap sur Debian/Ubuntu
●
Centos n'a pas de package pour rlwrap, il faut le charger à l'adresse suivante :
●
●
wget -O rlwrap-0.24-rh.i386.rpm "http://ivan.kartik.sk/oracle/download_from.php?site_id=5"
●
wget http://silverlake/rlwrap-0.24-rh.i386.rpm
●
Il faut un package supplémentaire : yum install compat-readline43
●
Et l'installer : rpm -i rlwrap-0.24-rh.i386.rpm
Il suffit alors de lancer SQL*Plus ainsi :
●
●
rlwrap sqlplus scott/tiger
Il est possible de définir un alias ainsi :
●
alias sqlplus='rlwrap sqlplus'
●
Il suffit de mettre cet alias dans le .bashrc pour qu'il soit permanent.
●
Grace à rlwrap, il sera possible de rappeler les commandes dans SQL*Plus.
Diagnostiquer les problèmes
●
●
●
La version 11g introduit une nouvelle infrastructure pour le diagnostic des
problèmes, Automatic Diagnostic Repository.
ADR se présente sous la forme d'une arborescence de répertoires qui
stocke de manière centralisée les données de diagnostic.
Il existe 2 concepts :
●
Les problèmes
–
●
Les incidents
–
●
●
Erreur Internes ORA-00600, OS ORA-07445...Chaque problème inclut un code ORA...et
éventuellement des paramètres supplémentaires.
Il s'agit d'une occurrence d'un problème, chaque incident porte un numéro
Il existe un autre composant, le Health Monitor, qui supervise, à l'aide
d'outils automatiquement ou manuellement, le bon état de la base.
L'exploitation du ADR se fait en ligne de commande par l'utilitaire adrci. Il
existe une interface graphique ( Support Workbrench ) dans le database
control.
Le référentiel ADR
●
Stocke tous les fichiers de traces et journaux pour
l'ensemble des produits s'exécutant sur le serveur.
●
●
●
BD, listener...
Défini par le paramètre DIAGNOSTIC_DEST, sa valeur
par défaut est $ORACLE_BASE si cette variable est
définie, sinon $ORACLE_HOME/log
La racine de ce répertoire se nomme diag et contient
un sous répertoire par produit Oracle
●
●
rdbms → BD, ce répertoire contient un sous répertoire par
instance de base de données.
tnslsnr→ listener...
diag/rdbms
●
●
Suite à la création de la base RED, sous
$ORACLE_BASE/diag/rdbms/red/RED.
●
red correspond au nom unique de la base de données
●
RED au nom de l'instance
Les principaux répertoires sont :
●
Alert : Fichier d'alerte format XML
●
Incident : Fichiers relatifs aux incidents
●
●
Trace : Fichier de trace des processus et format texte du
fichier d'alerte ( alert.log )
Les anciens paramètres BACKGROUND_DUMP_DEST
et USER_DUMP_DEST sont dépréciés.
Fichiers d'alertes et de traces
●
●
●
●
Oracle maintient un fichier d’alerte dans lequel il écrit des messages
d’information ou d’erreurs sur la vie de la base de données :
●
Création de la base de données,
●
Démarrages et arrêts,
●
Modifications de la structure (tablespaces, fichiers de données),
●
Erreurs internes (ORA-00600, ORA-07445),
●
Erreurs de bloc corrompu (ORA-01578),
●
Problèmes relatifs à l’écriture ou à l’archivage des fichiers de journalisation.
En complément, lorsqu’un processus rencontre un problème, il écrit des
informations dans un fichier de trace.
Le fichier d'alerte est disponible sous deux formats : texte et XML.
●
Le nom du fichier d’alerte xml est de la forme : log.xml ( sous répertoire alert )
●
Le nom du fichier d’alerte texte est de la forme : alert_<SID>.log ( sous répertoire trace )
Processus d'arrière plan ( sous répertoire trace )
●
●
Le nom des fichiers de trace des processus d’arrière-plan est de la forme :
<sid>_<nom_processus>_<id_processus>.trc.
Le nom des fichiers de trace des processus serveur est de la forme :
<sid>_ora_<id_processus>.trc.
ADRCI
●
●
●
Automatic Diagnostic Repository Command
Interpreter.
Outil ligne de commande et interactif pour gérer
les erreurs Oracle.
Fonctionnalités
●
Visualiser le fichier alert.log
●
Gestion des problèmes et des incidents
●
●
Création de packages zippés pour envoi au support
Oracle.
Purge des fichiers de traces...
Un exemple de dysfonctionnement
●
Se connecter en sys
●
sqlplus sys/manager11@red as sysdba
●
●
●
SQL> create user alice identified by ecila;
●
SQL> grant connect,resource to alice;
●
SQL> connect alice/ecila@red
●
SQL> create table t ( n number );
●
SQL> select object_id from user_objects;
Noter le numéro retourné par la requête ( exemple 17322 ) et se
reconnecter sys
●
SQL>connect sys/manager11@red as sysdba
●
SQL>update tab$ set cols=2 where obj#=17322;
●
SQL>commit;
Cet update fausse le dictionnaire des données, à ne pas faire
en production !
Tester le dysfonctionnement
●
Dans un premier temps purger la shared_pool afin de
vider le dictionnary cache
●
●
SQL> alter system flush shared_pool;
Se reconnecter alice
●
●
SQL> select * from t;
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 2236
Session ID: 29 Serial number: 9
●
Sortir du SQL par exit
Utilisation de adrci
●
Au niveau du shell, lancer adrci, puis la commande show home
●
adrci>show home
ADR Homes:
diag/tnslsnr/LX-1-3/listener
diag/rdbms/red/RED
●
●
Il existe plusieurs ADR directory, relatives ici au listener ( diag/tnslsnr )
et au moteur de Oracle ( diag/rdbms ).
L'erreur s'est produite au niveau du moteur Oracle donc rdbms.
Toujours sous adrci, se positionner dans la bonne arborescence.
●
●
Visualiser la fin du fichier alert.log
●
●
adrci> set home diag/rdbms/red/RED
adrci>show alert -tail -f
Taper Ctrl+C pour sortir.
Identifier le problème
●
●
●
●
ADR défini les concepts de problème et d'incident.
Un incident est une occurrence d'un problème, ainsi si la
même erreur se reproduit une seconde fois il n'y aura
qu'un problème mais 2 incidents
Ouvrir une seconde session et sous sqlplus en connexion
alice et relancer la commande select * from t;
A nouveau sous adrci taper la commande show problem.
●
●
adrci>show problem
Relever le numero du problème ( problem_id ) exemple
ici : 1
Identifier les incidents
●
adrci> show incident
●
Relever le numéro de l'incident, par exemple 12971.
●
Demander l'affichage de l'incident
●
adrci> show incident -mode detail -p "incident_id=12971"
●
●
●
●
●
●
Repérer le numéro du PROBLEM_ID et demander l'édition de la trace, il s'agit
du nom de fichier de la dernière ligne.
adrci>show trace
/u01/app/oracle/diag/rdbms/red/RED/incident/incdir_12971/RED_ora_2944_i12
971.trc
Ceci lance dans vi le fichier trace, il est possible de retrouver la requête SQL en
recherchant le mot "current_sql"
***** Current SQL Statement for this session (sql_id=89km4qj1thh13) *****
select * from t
***** current_sql_statement *****
Envoyer les traces au support
Oracle
●
Le problème généré dans cet exemple ne peut pas être facilement
diagnostiqué, aussi il faut envoyer les traces au support oracle,
pour cela créer un package zippé.
●
adrci>ips create package problem 1 correlate all
Created package 2 based on problem id 1, correlation level all
●
Selon le cas, le chiffre peut être différent de "1"
●
adrci>ips generate package 2 in "/home/oracle"
●
●
●
●
Generated package 2 in file
/home/oracle/ORA7445qc_20120606132038_COM_1.zip, mode complete
Ici aussi, selon le cas le chiffre peut être différent de "2"
Envoyer le fichier zip à Oracle.
Il existe sous My Oracle Support une page spéciale pour ce type
d'erruer ( ORA-00600 et ORA-07445 )
Purge des traces
●
Avec le temps il est nécessaire de purger les traces.
●
La commande suivante liste l'ensemble des traces par ordre chronologique
●
●
●
●
adrci> show tracefile -rt
La durée de retention par défaut des traces ordinaires( switch redo log par
exemple ) est de 720 heures, soit 30 jours. Pour les incidents 8760 heures soit un
an
●
adrci>show control
●
SHORTP_POLICY : Traces ordinaires → 720
●
LONGP_POLICY : Incidents → 8760
Ceci se paramètre par les commandes suivantes :
●
adrci> set control (SHORTP_POLICY = 360) → 15 jours
●
adrci> set control (LONGP_POLICY = 2190) → 3 mois.
Pour purger les traces on indique le nombre de minutes, par exemple purger les
traces de plus de 2 jours ( 2880 minutes )
●
adrci> purge -age 2880 -type trace
Supprimer le user alice
●
Pour la suite du cours se connecter à RED en
system/manager11 et supprimer le user alice.
●
sqlplus system/manager11@red
●
SQL> drop user alice cascade ;
●
SQL> exit ;
Oracle Enterprise Manager
Database Control
●
Outil d'administration complet accessible par un navigateur Web
●
Limité à une seule base
●
Administration possible de plusieurs bases par Grid Control ( licence payante )
●
Le Database Control est très complet et demande du temps pour l'utiliser. Dans ce
cours il ne sera que survolé et vu en complément des commandes en ligne.
●
A noter, certaines fonctions graphiques demande l'installation du plugin flash.
●
Dans certains environnements, le database control n'est pas configuré par sécurité.
●
Particularité Windows
●
Pour utiliser le database control, l'utilisateur doit être membre du groupe
administrateur,
●
Avoir le privilège : Ouvrir une session en tant que tache.
●
Sinon certaines fonctions seront inaccessibles.
Création du database control
●
En création manuelle d'une base de données, celui-ci doit être configuré séparément.
●
La création dure environ 10 minutes.
●
●
Il faut spécifier un paramètre de plus dans la configuration, job_queue_processes doit être au
minimum à 1
●
●
sqlplus /nolog
●
●
SQL> alter system set job_queue_processes=1 scope=both;
●
SQL> exit ;
En 11g, job_queue_processes est par défaut à 1000, cette manipulation est donc inutile. Ceci
peut être vérifier ainsi.
●
●
SQL> show parameter job_queue_processes;
●
●
emca -repos create → création du référentiel EM
Le script pose 4 questions :
– SID → RED
– Port d'écoute → 1521
– Mot de passe SYS → manager11
– Mot de passe SYSMAN → manager11 ( cet utilisateur va être créé )
– Répondre Y pour lancer le traitement
Mise en place de l'interface Web du
database control
●
●
●
●
●
emca -config dbcontrol db → configuration de l'interface web
Le script pose 8 questions
– SID → RED
– Processus d'écoute → 1521
– Répertoire d'origine ORACLE_HOME du processus d'écoute : accepter
– Mot de passe de SYS → manager11
– Mot de passe de DBSNMP → manager11 ( cet utilisateur va être créé )
– Mot de passe de SYSMAN: → manager11
– Adresse électronique pour les notifications (facultatif): Laisser vide
– Serveur de messagerie sortant (SMTP) pour les notifications (facultatif): Laisser
vide
– Répondre Y pour lancer le traitement
Se connecter à l'URL sécurisée donnée ( https://serveur:1158/em )
La liste des ports est dans le fichier $ORACLE_HOME/install/portlist.ini
Démarrage du database control
●
●
●
●
●
●
●
Le database control utilise un processus à part du démarrage de
l'instance à l'instar du listener.
Le database control permet de démarrer le listener et l'instance, il
faut donc positionner la variable ORACLE_SID
emctl start dbconsole → Le démarrage est assez lent ( plus d'une
minute )
Pointer ensuite le navigateur Web sur l'URL indiquée au
démarrage.
La commande emctl stop dbconsole arrête le database control.
La commande emctl status dbconsole donne l'état du database
control
Connexion au Database
Control
●
Se connecter en system/manager11 en mode "Normal"
●
L'autre possibilité est sys/manager11 en mode "SYSDBA"
Vue du Database Control
Serveur → Tablespaces
Supprimer le Database Control
●
Suppression des fichiers de configuration
●
●
Suppression du repository
●
●
●
$ORACLE_HOME/bin/emca -repos drop
Les deux actions ci-dessus ensembles
●
●
$ORACLE_HOME/bin/emca -deconfig dbcontrol db
$ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop
Suppression manuelle de fichiers
●
$ORACLE_HOME/hostname_sid
●
$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_sid
●
Adapter hostname et sid à l'environnement.
Liens sur le sujet
●
●
http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/dbcontrol005.ht
m#BEJJDHGB
http://sites.google.com/site/madrid9999/emdbcontrolreconfigure
SQL Developer
●
Livré en standard avec oracle 11g. Utilise VM Java.
●
Produit connu auparavant sous le nom de Raptor.
●
●
Orienté développement avec quelques fonctions
d'administration.
Téléchargeable gratuitement sur le site Oracle :
http://www.oracle.com/technetwork/developer-tools/sql-developer
Interface SQL Developer
Documentation Oracle
●
Prérequis : maîtriser l'anglais !
●
Disponible en ligne via l'URL suivante :
●
●
La publication 2 days DBA permet une bonne
approche de l'administration Oracle avec le
Database Control
●
●
http://download.oracle.com/docs/cd/B19306_01/server.1
12/b14196/toc.htm
L'achat d'un produit Oracle donne automatiquement
un accès à My Oracle Support ( ex-Metalink )
Arrêt et démarrage d'une
base ORACLE
Démarrage et Arrêt d'une base
●
Ces deux actions demandent le privilège sysdba
●
Elles sont possibles depuis SQL*Plus ou le database control
●
Avant d'être accessible ou stoppée, la base passe par 3 phases
distinctes :
●
Démarrage
–
–
–
●
Arrêt
–
–
–
●
Démarrage de l'instance ( état NOMOUNT )
Montage de la base de données ( état MOUNT )
Ouverture de la base de données ( état OPEN )
Fermeture de la base de données
Démontage de la base de données
Arrêt de l'instance.
Chaque phase permet certaines actions sur la base.
Démarrage
●
●
sqlplus /nolog
●
●
La commande startup permet le démarrage en mode open
de la base
●
SQL> startup
●
C'est le plus simple si tout est correct :
●
Présence du pfile/spfile
●
Présence du/des fichiers de contrôle
●
Présence des fichiers de données et cohérence avec le fichier de
contrôle.
Les différents modes de démarrage
●
SQL> startup nomount
●
●
●
SQL> startup nomount pfile="init.ora"
●
Lance l'instance sur un fichier texte de paramètres
●
Utilisé pour créer une base ou démarrer sur des valeurs autres que celles du spfile.
●
En cas de perte du spfile, Oracle utilise un fichier pfile par défaut afin de restaurer le spfile.
●
Permet aussi de recréer le spfile depuis le pfile ou de restaurer le fichier de contrôle
SQL> startup mount
●
●
●
●
●
Lit le spfile et lance l'instance en mémoire
Lit le fichier de contrôle, si non présent la base reste à l'état nomount.
Cette phase permet de modifier le comportement de la base, par exemple d'activer le mode archivelog ou
encore d'effectuer une restauration par RMAN.
SQL> startup open ( ou startup )
●
Après lecture du fichier de contrôle, ouvre l'ensemble des fichiers de données
●
Si un fichier manque, Oracle reste en mode mount et demande une restauration.
La commande alter database permet de passer de nomount à mount puis de mount à open, mais
uniquement dans cet ordre :
●
SQL> startup nomount
●
SQL> alter database mount
●
SQL> alter database open
Il n'est pas possible de passer de open à mount directement.
Phases de démarrage
Oracle
Fichier
de paramètres
pfile ou spfile
Allocation
mémoire
(sga)
redo-logs
Processus
arrière-plan
(dbw0,pmon,
smon,ckpt...)
startup nomount
Fichiers
de contrôle
alter database mount
Fichiers
de données
alter database open
startup
Démarrage en mode restrict
●
Il est possible de démarrer la base en mode restrict
●
●
●
SQL> startup restrict
Seul les utilisateurs avec le privilège RESTRICTED
SESSION ( cas du DBA ) peuvent effectuer des actions
Utile pour réorganiser le stockage, créer des index,
faire un import/export ou bien charger des données par
SQL*Loader sans être perturbé par les applications.
●
En fin de procédure on désactive le mode restrict ainsi :
●
SQL> alter system disable restricted session;
●
La base devient alors disponible à tous.
Activer restricted session
Pour activer restricted session, sans redémarrer l'instance.
●
●
SQL> alter system enable restricted session ;
Statut visible dans la vue v$instance, champ LOGINS →
ALLOWED/RESTRICTED
●
Les utilisateurs connectés doivent être manuellement déconnectés.
●
Rechercher les sessions
SET LINESIZE 100
COLUMN spid FORMAT A10
COLUMN username FORMAT A10
COLUMN program FORMAT A45
SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username,
FROM gv$session s, gv$process p
WHERE p.addr = s.paddr AND p.inst_id = s.inst_id
AND s.type != 'BACKGROUND';
●
Supprimer une session
●
SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';
s.program
Arrêt
●
●
sqlplus /nolog
●
●
SQL> shutdown normal ( shutdown )
●
●
Ce mode est rarement utilisé, car il suppose que tous les utilisateurs ont
fermé leur session. La base ne s'arrêtera pas sinon.
Les autre modes sont :
●
●
●
immediate → déconnecte toutes les sessions et annule les transactions en cours. Ce
mode est utile pour une sauvegarde à froid en mode batch.
transactionnal → attend la fin de toutes les transactions en cours avant la
déconnexion des sessions. Les nouvelles connexions sont rejetées.
abort → ferme brutalement la base, une récupération sera nécessaire au prochain
redémarrage.
●
Normal, immediate et transactionnal sont des arrêts propres de la base
●
Abort doit être utilisé que si aucun autre mode ne répond.
Autres outils de création
d'une base de données
Création d'une base avec DBCA
●
●
DBCA est un assistant graphique de création de base.
Il se base sur des modèles de bases de données et
effectue un clonage.
●
Méthode rapide et simple de création
●
Configure la couche Oracle*Net
●
Permet de créer ses propres modèles
●
Paramètre automatiquement le database control
●
●
Demande une interface graphique. Toutefois il peut être
lancé en mode silencieux.
En ligne de commande taper : dbca et suivre l'assistant,
afin de créer une base nommée YELLOW.
DBCA en mode silencieux
●
●
Permet de rapidement mettre en place une base de données sans utiliser
d'interface graphique.
Charger le script par wget
●
●
●
●
wget http://192.168.11.24/dbcasilence.sh
dbca -silent -createDatabase
\
-templateName General_Purpose.dbc \
-gdbName BLUE
\
-sysPassword manager11
\
-systemPassword manager11
\
-emConfiguration NONE
\
-datafileDestination /u01/app/oracle/oradata \
-storageType FS
\
-characterSet UTF8
\
-memoryPercentage 20
dbca utilise le clonage pour la création, ce qui rend l'opération très rapide.
La commande suivante permet de supprimer la base
●
dbca -silent -deleteDatabase -sourceDB BLUE
Gestion du fichier de contrôle
et des fichiers de journalisation
Nouvelle structure de répertoires
●
●
Pour la suite du cours il est nécessaire de
mettre en place de nouveaux répertoires
●
●
Ces répertoires simuleront 2 disques
supplémentaires dans le serveur.
Le fichier de contrôle et les redologs
●
Gestion du fichier de contrôle
●
Multiplexage du fichier de contrôle
●
●
●
Gestion des fichiers de journalisation ( redologs
)
Notion de groupes et de membres
Trouver le nombre de groupes idéal et la
dimension correcte des membres.
Gestion des fichiers de contrôle
●
Le fichier de contrôle est le premier fichier lu par la base de données.
Le fichier de paramètres est lu par l'instance.
●
Sa mise à jour est faite par Oracle
●
Il contient :
●
●
Le nom de la base de données
●
L'emplacement des autres fichiers
●
Le numéro SCN actuel...
Il est possible de visualiser le contenu du fichier de contrôle au format texte ainsi :
●
sqlplus /nolog
●
●
SQL> alter database backup controlfile to trace as '$HOME/svg_ctrl.txt';
●
●
●
Cette fonctionnalité est intéressante pour recréer les fichiers de contrôle en cas de perte ou
encore pour cloner une base par copie physique des fichiers de données.
Par sécurité Oracle recommande 3 copies, multiplexage, du fichier de contrôle sur
des axes différents.
La requête suivante donne l'emplacement des fichiers de contrôle.
●
SQL> select name from v$controlfile;
Multiplexer le fichier de contrôle
●
●
●
●
●
●
●
La base RED ne dispose que d'un fichier de contrôle.
Il faut indiquer dans un premier temps au fichier de paramètres l'emplacement
des futurs fichiers de contrôle.
Se connecter sysdba à la base RED
SQL> alter system set control_files=
'/u01/app/oracle/oradata/RED/control01.ctl',
'/u02/app/oracle/oradata/RED/control02.ctl',
'/u03/app/oracle/oradata/RED/control03.ctl'
scope=spfile;
SQL> shutdown immediate;
SQL> host cp /u01/app/oracle/oradata/RED/control01.ctl
/u02/app/oracle/oradata/RED/control02.ctl
●
SQL> startup
●
SQL> select name from v$controlfile;
●
Le database control ne permet pas de multiplexer les fichiers de contrôle.
Exercice
●
Simulation de la perte d'un fichier de contrôle.
●
Arrêter la base de données et supprimer un des fichiers de contrôle.
●
●
SQL> shutdown immediate
●
SQL> host rm /u02/app/oracle/oradata/RED/control02.ctl
●
Tenter de redémarrer la base avec startup → erreur.
●
Stopper à nouveau la base avec shutdown immediate.
●
Recopier un fichier de contrôle valide en le renommant à
l'emplacement du fichier perdu
●
●
SQL> startup
Gestion des fichiers de
journalisation
●
●
●
●
●
Les redologs enregistrent l'ensemble des transactions de la base de
données.
●
Les informations sont écrites de manière circulaires.
●
Les redologs sont organisés en groupe et composés de membres.
●
Il faut au minimum 2 groupes de 1 membre par base de données.
La requête suivante donne l'emplacement des redologs
●
SQL> col member format a60;
●
SQL> select group#,member from v$logfile;
Oracle préconise d'avoir au moins 3 groupes de 2 membres.
La gestion des redologs doit être effectuée avec soin, l'ensemble des
transactions Oracle passant par eux.
Certaines manipulations sur les redologs obligent à redémarrer l'instance.
Redolog et RAID5
●
●
Il s'agit d'un sujet ayant engendré au fil des ans tout
et son contraire.
La position de Oracle est claire → S.A.M.E !
●
●
●
●
Stripe And Mirror Everything → RAID10 ou RAID 0+1
En clair : on ne fait pas de RAID5 avec Oracle. Pourquoi ?
→ Parce que Oracle le dit !
Pour les redologs, ne pas utiliser RAID5 semble une
évidence. Les redologs sont soumis à des écritures
répétées et massives, hors RAID5 doit à chaque
écriture recalculer la parité.
La gestion des fichiers avec ASM permet de
s'affranchir de ces questions.
Ajouter un nouveau membre à un
groupe
●
●
L'objectif est de multiplexer les membres de chaque groupe
SQL> alter database add logfile member
'/u03/app/oracle/oradata/RED/redo01b.log' to group 1;
●
Effectuer la même manipulation pour le groupe 2.
●
Visualiser le résultat
●
SQL> set linesize 150
●
SQL> col member format A60
●
SQL> select group#,member from v$logfile order by 1,2;
GROUP 1
GROUP 2
redo01a.log
redo01a.log
redo02a.log
redo02a.log
GROUP 1
GROUP 2
redo01a.log
redo01a.log
redo02a.log
redo02a.log
redo01b.log
redo01b.log
redo02b.log
redo02b.log
Ajouter un nouveau groupe
●
●
●
L'objectif ici est de créer un troisième groupe de
redologs.
SQL> alter database add logfile group 3
( '/u01/app/oracle/oradata/RED/redo03a.log',
'/u02/app/oracle/oradata/RED/redo03b.log' )
size 50M;
SQL> select group#,member from v$logfile order by1,2;
GROUP 1
GROUP 2
GROUP 3
2
redo01a.log
redo02a.log
redo02a.log
redo03a.log
redo01b.log
redo02b.log
redo02b.log
redo03b.log
Exercice
●
●
●
●
Ajouter un quatrième groupe de redolog d'une taille de
50M et composé de trois membres.
SQL> alter database add logfile (
'/u01/app/oracle/oradata/RED/redo04a.log',
'/u02/app/oracle/oradata/RED/redo04b.log',
'/u03/app/oracle/oradata/RED/redo04c.log'
) size 50M;
Il n'est pas obligatoire de nommer le groupe, par
défaut Oracle affecte la dernière valeur + 1.
Visualiser la configuration par la commande suivante :
●
SQL> select group#,member from v$logfile order by group#;
Statut des redologs
●
La requête suivante permet de connaître le status des
groupes.
●
SQL> select group#, status, members from v$log order by group#;
GROUP# STATUS MEMBERS

1 INACTIVE
2
2 ACTIVE 2
3 CURRENT 2
●
●
CURRENT : Oracle écrit en ce moment dans ce groupe
ACTIVE : Il reste dans ce groupe des informations importantes non
écrites dans les datafiles → attente du checkpoint.
●
INACTIVE : Le groupe ne contient plus d'informations utiles.
●
UNUSED : Le groupe n'a pas encore été utilisé → création.
Modifier le statut des groupes de
redologs.
●
●
Pour certaines actions, le statut ne doit pas être
CURRENT ou ACTIVE.
Pour modifier le groupe courant :
●
●
SQL> alter system switch logfile;
Pour écrire dans les datafiles les données des
groupes
●
SQL> alter system checkpoint;
Exemple
Supprimer un membre d'un groupe
●
●
L'exercice précédent a créé un membre de trop dans
le groupe 4.
Le groupe doit disposer de 2 membres pour pouvoir en supprimer 1. Il faut toujours
un membre valide dans un groupe.
●
La suppression de tous les membres se fait en supprimant le groupe.
●
La requête suivante permet de savoir si un membre est supprimable.
●
●
●
●
●
SQL> select group#, status, members from v$log order by group#;
Seuls membres des groupes dont le statut est INACTIVE ou UNUSED peuvent
être supprimés.
Afin de forcer un changement de statut par un basculement de groupe, il faut
utiliser la commande alter system switch logfile suivie d'un alter system
checkpoint.
SQL> alter database drop logfile member '/u03/app/oracle/oradata/RED/redo04c.log';
IMPORTANT : le fichier n'est pas physiquement supprimé, il faut le faire explicitement
par l'OS.
Supprimer un groupe
●
●
Le groupe 4 n'est pas utile, pour le supprimer son
statut doit être égal à INACTIVE.
Utiliser la commande alter system switch logfile et
alter system checkpoint pour forcer un éventuel
basculement.
●
Il doit toujours rester au minimum 2 groupes.
●
SQL> alter database drop logfile group 4;
●
Comme pour la suppression d'un membre, les
fichiers doivent être explicitement supprimés par
l'OS.
Déplacer un membre
●
Cette opération peut s'effectuer de deux manières.
●
●
●
●
Arrêt de la base, déplacement du fichier au niveau de l'OS, modification du
fichier de contrôle et redémarrage de la base.
Création d'un nouveau membre dans le groupe et suppression de l'ancien
membre.
La seconde méthode évite l'arrêt de la base.
Méthode arrêt de la base
●
●
●
●
●
SQL> host mv '/u03/app/oracle/oradata/RED/redo01b.log'
'/u02/app/oracle/oradata/RED/redo01b.log'
SQL> startup mount;
SQL> alter database rename file '/u03/app/oracle/oradata/RED/redo01b.log'
to '/u02/app/oracle/oradata/RED/redo01b.log';
SQL> alter database open;
Exercice
●
●
●
●
Déplacer le membre redo02b.log sous
/u02/app/oracle/oradata/RED sans arrêter la base de
données.
Il peut être nécessaire de devoir faire de nombreux
appels à alter system switch logfile + alter system
checkpoint et de vérifier le statut des groupes
SQL> select group#, status, members from v$log
order by group#;
Conclusion, bien que séduisante au premier abord
cette manière de faire peut demander plus de
manipulations que de passer par un arrêt de base.
Déterminer la taille de redolog
●
●
Il est important de contrôler la fréquence des point de reprise
→ fréquence de basculement des redologs.
La requête suivante permet de visualiser cette fréquence
●
●
●
●
●
SQL> select sequence#,
to_char(first_time,'DD/MM/YYYY HH:MI:SS') first_time
from v$log_history;
Déterminer la taille du log_buffer, le nombre et la taille des redologs est un sujet
complexe.
Se baser sur les évènements d'attente types :
●
redo log space →log_buffer trop petit
●
log file sync → log_buffer trop grand
Oracle offre des mécanismes d'audit afin de choisir au mieux ces valeurs.
Très important, la base de données doit avoir eu une certaine activité avant de
prendre une décision.
Nombre et taille des redologs
●
L'objectif est simple :
●
●
●
●
●
●
●
Utiliser des redologs de taille suffisante afin d'obtenir de 4 à 6 basculements par heure.
Utiliser un nombre suffisant de groupes pour permettre un point de reprise avant un
cycle complet → Erreur Oracle checkpoint not complete.
Augmenter la taille des redologs en cas de basculement trop fréquent liés à
une forte activité de mise à jour engendre le risque de perte de données en
cas d'arrêt anormal et perte du redolog courant.
L'erreur checkpoint not complete ( voir alert.log ) montre qu'il faut augmenter
le nombre des groupes.
Une préconisation "non officielle" dit d'être généreux avec le nombre de
groupes → déterminer le nombre de groupe idéal et en ajouter 1.
Les redologs sont en général de petits fichiers, en avoir un grand nombre n'est
pas une contrainte.
Les redologs doivent si possible avoir des disques dédiés → et proscrire le
RAID5 !
Estimer la fréquence de basculement de redolog
●
●
La vue v$log_history donne cette information, elle est
également tracée dans l'alert.log.
La requête suivante permet de cartographier simplement la
fréquence des redolog.
set linesize 150;
select
to_char(first_time,'MM-DD') Jour,
to_char(sum(decode(to_char(first_time,'HH24'),'00',1,0)),'999') " 00",
to_char(sum(decode(to_char(first_time,'HH24'),'01',1,0)),'999') " 01",
...idem pour chaque heure jusqu'à 23...
to_char(sum(decode(to_char(first_time,'HH24'),'23',1,0)),'999') " 23"
from v$log_history group by to_char(first_time,'MM-DD') order by 1;
●
Charger le fichier carto_log.sql
●
wget http://192.168.4.224/ORA/carto_log.sql
●
Se connecter sous sqlplus et lancer le script carto_log.sql
●
sqlplus system/manager11@red @$HOME/carto_log.sql
Exemple de cartographie redologs
Utilisation des switches redolog
●
●
●
●
Le nombre de switches redolog par heure est un bon indicateur sur
les périodes d'activité transactionnelle de la base.
Il est ainsi possible de focaliser la recherche de requêtes
consommatrices sur le/les créneaux horaires ( rapports AWR )
Il est possible de forcer un switch régulier, par exemple tous les 1/4
heures ( 900 secondes ) même si le groupe n'est pas rempli.
Le paramètre ARCHIVE_LAG_TARGET permet ceci.
●
SQL> alter system set archive_lag_target = 900 scope = both;
●
Ce paramètre n'influe pas sur les fréquences normales de switch.
●
Il suffit d'une transaction par 1/4 d'heure pour générer un switch.
●
Si aucune transaction n'est enregistrée durant 15 minutes, aucun
switch n'est fait.
Méthode de calcul
●
Oracle préconise de positionner le paramètre FAST_START_MTTR_TARGET qui indique
le nombre maximum de secondes souhaité pour le redémarrage de l'instance après un
arrêt anormal.
●
Ceci permet à Oracle d'ajuster la fréquence des points de reprise.
●
Attention des points de reprise trop fréquents dégradent fortement les performances.
●
On utilise ensuite la vue v$instance_recovery pour superviser le temps estimé de restauration.
●
SQL> alter system set fast_start_mttr_target = 30 scope=both;
●
SQL> select estimated_mttr, optimal_logfile_size from v$instance_recovery;
ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE

7
●
369
Cette requête montre que la valeur de fast_start_mttr_target demande des redologs de plus de 350Mo, or
Oracle estime une valeur minimale de 7 pour ce paramètre.
●
SQL> alter system set fast_start_mttr_target = 7 scope=both;
●
SQL> select estimated_mttr, optimal_logfile_size from v$instance_recovery;
ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE

7
●
●
49
La requête montre que 50M est une bonne valeur, ce qui est logique car la base à une activité quasi nulle. La
valeur actuelle est donc bonne.
Conseil : Positionner en production fast_start_mttr_target à 30 secondes et laisser tourner la base un temps
afin d'affiner la valeur.
Complément FAST_START_MTTR_TARGET
●
●
●
●
Oracle conseille une fois la valeur fixée pour
FAST_START_MTTR_TARGET de mettre les
paramètres suivants à 0.
●
LOG_CHECKPOINT_TIMEOUT
●
LOG_CHECKPOINT_INTERVAL
●
FAST_START_IO_TARGET
Par défaut les deux derniers le sont mais pas
LOG_CHECKPOINT_TIMEOUT qui a la valeur 1800
SQL> show parameter log_checkpoint_timeout
SQL> alter system set log_checkpoint_timeout=0
scope=both;
Changer la taille des redologs
●
●
●
●
●
●
Un redolog ne peut pas être redimensionné dynamiquement. Il faut
supprimer et recréer le redolog. Attention il est impossible de faire
travailler la base Oracle avec moins de 2 groupes de redo-log.
De plus le groupe doit être dans le statut "INACTIVE" pour être supprimé. Les
commandes alter system switch logfile / alter system checkpoint et la consultation
de la vue v$log aident dans cette démarche.
select group#, status from v$log;
Utiliser les commandes suivantes pour forcer un switch et mettre le groupe 1 inactif
si besoin :
●
SQL> alter system switch logfile;
●
SQL> alter system checkpoint;
Ré-intérroger la vue v$log, il faut parfois plusieurs switches de log pour rendre un
groupe inactif.
Création
●
●
SQL> alter database add logfile group 1 '/u01/app/oracle/oradata/RED/redo01a.log', size
150M;
Suppression
●
SQL> alter database drop logfile group 1;
Les tablespaces
Tablespaces et fichiers de données
●
Vue d'ensemble
●
Tablespace permanent
●
Tablespace temporaire
●
La gestion OMF
●
Tablespace UNDO
Principe du tablespace
BASE DE DONNEES
est composée de
appartient à
TABLESPACE
est divisé en
lié à
FICHIER PHYSIQUE
contient
est conservé dans
SEGMENT
segment de table,
d'index ou d'annulation
Tablespace
●
●
●
●
Unité logique de stockage composé d'un ou de plusieurs fichiers physiques.
La majorité des opérations de stockage se font au niveau tablespace et non
au niveau fichier physique.
Les tablespaces permettent une transparence de la localisation des fichiers
physiques
Il permettent aussi de lever les limites de certains systèmes de fichiers
●
●
●
En FAT16 un fichier ne peut faire plus de 2Go.
La notion de tablespace permet d'obtenir un espace de stockage de 8Go en
regroupant 4 fichiers de 2Go ou 8 de 1Go...
Les tablespaces sont :
●
●
●
Permanent → stockage des données
Temporaire → gestion des tri ( clause order by, group by ), création des index, calcul
des statistiques...
Annulation ( undo ) → Introduit en 9i, il automatise et remplace avantageusement la
gestion des annulations par rollback segment
Tablespace permanent
●
Ce type de tablespace contient les données et les index.
●
Par défaut une base Oracle dispose de 2 tablespaces
●
●
●
●
●
SYSTEM → contient le dictionnaire des données
SYSAUX → contient le référentiel AWR utilisé notamment par le database
control.
Ces deux tablespaces ne doivent jamais contenir des données utilisateurs.
Pour stocker les données utilisateurs, il faut créer des tablespaces
supplémentaires.
Il existe deux types de tablespace permanents
●
●
●
smallfile : contient de 1 à 1022 fichiers physiques avec une taille maximale de
tablespace de 2^22 blocs Oracle soit pour des blocs de 8ko : 32Go
bigfile : contient un seul fichier de données dont la taille maximale est de 2^32
blocs Oracle soit pour des blocs de 8ko : 32To
Par défaut les tablespaces sont de type smallfile.
Etat des tablespaces
●
Deux états possibles :
●
●
●
●
●
online → accessible, utilisation normale.
offline → permet des opérations de maintenance, les
données sont momentanément inaccessibles
Il existe d'autres états ( begin backup, end
backup...qui seront vus lors des sauvegardes )
Il est possible de positionner un tablespace en
mode READ ONLY. Utile pour des données
d'archives ne devant pas être modifées.
Le tablespace SYSTEM ne peut être mis offline.
Directives sur les tablespaces
●
En plus de SYSTEM et SYSAUX, créer au minimum :
●
un tablespace d'annulation ( undo )
●
un tablespace temporaire
●
Il est d'usage pour chaque schéma d'avoir :
–
–
–
●
●
●
●
●
un tablespace temporaire
un tablespace pour les données
un tablespace pour les index
Si possible mettre les fichiers physiques sur des disques différents.
Si on suit à la lettre les préconisations Oracle sur ce sujet, un serveur doit avoir
10 disques minimum !
Les tablespaces apportent une souplesse au stockage, à la
sauvegarde et au transfert entre base de données.
RMAN par exemple peut sauvegarder un tablespace particulier et bien
sur le restaurer.
Les tablespaces transportables permettent de faire rapidement passer
des données d'une base à une autre.
Base de données type
Tablespace
SYSTEM
Tablespace
SYSAUX
Tablespace
UNDOTBS
Tablespace
TEMP
ORACLE
Tablespace
DATA_ALICE
Tablespace
DATA_SCOTT
Tablespace
INDX_ALICE
Tablespace
INDX_SCOTT
Tablespace
TEMP_ALICE
Tablespace
TEMP_SCOTT
ALICE
SCOTT
Gestion locale ou par dictionnaire des extensions
dans les tablespaces
●
●
Dans un tablespace, le stockage est organisé en segments,
composés d'extensions ( extent ).
Dans un gestion par dictionnaire,les informations sur les extensions libres et allouées
sont stockées dans des tables du dictionnaire des données.
●
●
●
●
Ce principe est aujourd'hui obsolète et déconseillé, car il dégrade les
performances → le dictionnaire des données doit être interrogé pour chaque
transaction.
Il oblige à surveiller les extensions libres/allouées et à assurer manuellement la
gestion → alter tablespace … coalesce.
Il est probable que ce mode sera supprimé dans les prochaines versions.
Dans une gestion locale, ces informations sont dans l'entête du tablespace
●
●
●
Il s'agit du mode par défaut des tablespaces pour la gestion.
Il se paramètre par la clause extent management local | dictionnary de l'ordre
create tablespace.
Utiliser des tablespaces gérés par le dictionnaire n'apporte que des contraintes
et nuit aux performances.
Gestion des segments dans les tablespaces
●
●
●
●
●
Elle peut être automatique ou manuelle
Elle est paramétrée par la clause segment management
auto | manual
Le mode manuel est déconseillé, il oblige à définir avec
précision les clauses de stockage. Ces clauses sont pour la
plupart sans intérêt pour un tablespace géré localement.
La clause storage demande un certain nombre de valeurs
dont la seule vraiment utile est initial.
Initial définie la taille initiale d'un segment . Il s'agit en fait de
réserver dès la création d'un objet un certain volume
d'espace afin que lors des insertions le segment tienne dans
une seule extension
Création d'un tablespace
●
Ordre SQL : create tablespace
●
Un tablespace porte un nom et contient au moins un fichier de données.
●
●
●
●
SQL> create tablespace DATA_VENTES datafile
'/u02/app/oracle/oradata/RED/data_ventes_01.dbf' size 100M;
Cet ordre va créer un tablespace smallfile nommé DATA_VENTES, géré
localement et d'une taille de 100Mo.
D'autres options peuvent être utilisées lors de la création du tablespace
notamment sur la gestion du stockage et des extensions.
●
Par défaut la gestion du stockage et des extentions est automatique.
●
Dans certains cas il est intéressant de changer ces options ( voir plus loin ).
Tablespace par défaut
●
●
●
●
●
●
●
Lors de la création d'un segment, table ou index, si le
tablespace n'est pas spécifié, Oracle le stocke dans le
tablespace par défaut de l'utilisateur.
Ce tablespace par défaut de l'utilisateur est mis en place par l'ordre create user ( voir
plus loin ). Il peut toutefois être omis et Oracle utilise alors le tablespace par défaut
de la base : SYSTEM.
Ceci pose un problème car les données de l'utilisateur seront alors stockées dans le
tablespace SYSTEM.
Il est possible de définir un autre tablespace par défaut au niveau de la base.
Ne pas spécifier de tablespace par défaut pour un utilisateur ou dans la création du
segment n'est pas conseillé. Pour limiter ce problème, créer un tablespace par défaut
de très petite taille ( 100Ko minimum ). Ainsi Oracle le satura très vite indiquant ainsi
un "oubli".
SQL> create tablespace users datafile '/u01/app/oracle/oradata/RED/users_01.dbf'
size 100K;
SQL> alter database default tablespace users;
Agrandir un tablespace
●
●
Au fur et à mesure le tablespace se rempli, si la place vient à manquer, il faut
agrandir le tablespace. Il existe 2 méthodes
●
Ajouter un fichier de données
●
Agrandir un fichier existant
Ajout d'un fichier
●
●
●
Le tablespace a maintenant une taille de 200Mo
Agrandissement d'un fichier
●
●
●
SQL> alter tablespace DATA_VENTES add datafile
'/u01/app/oracle/oradata/RED/data_ventes_02.dbf' size 100M;
SQL> alter database datafile '/u02/app/oracle/oradata/RED/data_ventes_01.dbf'
resize 200M;
Le tablespace a maintenant une taille de 300Mo.
La requête suivante permet de voir le résultat
●
SQL> select tablespace_name, sum(bytes/1024/1024) "Taille en Mo" from
dba_data_files group by tablespace_name;
Auto-extension du tablespace
●
●
Il est possible de définir le fichier de données du
tablespace en auto-extension. Ainsi si la place vient à
manquer le fichier s'agrandit de lui même.
SQL> create tablespace PERTES_DATA datafile
'/u02/app/oracle/oradata/RED/data_pertes_01.dbf' size
100M autoextend on next 100M maxsize 500M;
●
●
Ce tablespace aura une taille initiale de 100Mo, puis
s'agrandira par pas de 100Mo jusqu'à son maximum
500Mo.
maxsize peut prendre la valeur unlimited, le fichier
grandira tant que possible.
Renommer un tablespace
●
●
●
●
Cette possibilité est apparue en 10g
SQL> alter tablespace PERTES_DATA rename
to DATA_PERTES;
SYSTEM et SYSAUX ne peuvent pas être
renommés
Un tablespace placé offline ne peut pas être
renommé.
Passer un tablespace online/offline
●
Pour certaines actions le tablespace doit être mis offline.
●
●
La requête suivante permet de contrôler le statut des tablespaces.
●
●
●
●
SQL> select file#,name,status from v$datafile;
Le tablespace SYSTEM ne peut être mis offline, le statut est d'ailleurs
SYSTEM.
Le statut peut aussi avoir la mention RECOVER indiquant qu'il faut
restaurer le tablespace.
Remise online
●
●
SQL> alter tablespace DATA_PERTES offline;
SQL> alter tablespace DATA_PERTES online;
Attention : le statut est conservé lors d'un arrêt, ainsi un
tablespace offline le restera au prochain redémarrage.
Renommer ou déplacer un fichier de données
●
Ces deux actions sont identiques au niveau Oracle.
●
Il existe deux méthodes :
●
●
●
Mettre le tablespace offline, déplacer ou renommer le
fichier, mettre à jour le fichier de contrôle et remettre le
tablespace online.
Arrêter la base, la relancer en mode mount, déplacer ou
renommer le fichier, mettre à jour le fichier de contrôle,
ouvrir la base.
La seconde méthode est obligatoire pour une action
sur le tablespace SYSTEM car il ne peut être mis
offline.
Première méthode de déplacement/renommage
●
●
●
●
SQL> alter tablespace DATA_PERTES offline;
SQL> host mv
'/u02/app/oracle/oradata/RED/data_pertes_01.dbf'
'/u03/app/oracle/oradata/RED/data_pertes_01.dbf'
SQL> alter tablespace DATA_PERTES rename
datafile
'/u02/app/oracle/oradata/RED/data_pertes_01.dbf' to
'/u03/app/oracle/oradata/RED/data_pertes_01.dbf';
SQL> alter tablespace DATA_PERTES online;
Seconde méthode déplacement du tablespace SYSTEM
●
Attention connexion SYSDBA
●
●
SQL> startup mount;
●
●
●
SQL> host mv
'/u01/app/oracle/oradata/RED/system01.dbf'
'/u02/app/oracle/oradata/RED/system01.dbf'
SQL> alter database rename file
'/u01/app/oracle/oradata/RED/system01.dbf' to
'/u02/app/oracle/oradata/RED/system01.dbf';
Suppression d'un tablespace
●
●
●
●
●
●
●
SQL> drop tablespace nom
Un tablespace contenant des données ne peut être
supprimé ainsi.
Les fichiers physiques ne sont pas supprimés.
La syntaxe pour supprimer le tablespace, ses données et
ses fichiers est la suivante :
SQL> drop tablespace DATA_PERTES including contents
and datafiles;
Supprimer un tablespace est irréversible.
Important : Toute action sur les tablespaces est tracée
dans l'alert.log.
Allocation de l'espace lors de la création d'un segment
●
●
●
●
●
Oracle alloue une ou plusieurs extensions dans le
tablespace.
Quand l'espace initial est plein, Oracle alloue une
nouvelle extension et ainsi de suite.
Toutes les extensions d'un segment sont dans le même
tablespace mais pas obligatoirement dans le même
fichier physique.
Lors de la suppression d'un segment les extensions
sont libérées.
Des créations / suppressions trop fréquentes induisent
une fragmentation du tablespace.
Gestion du stockage dans les
tablespaces
●
La gestion des extensions peut être :
●
●
●
Automatique → autoallocate, mode par défaut. Oracle
détermine la taille des extensions.
Uniforme → uniform size nK/M. Dans ce type de gestion
toutes les extensions ont la même taille de nK ou nM ( la
valeur par défaut est de 1M )
La gestion du stockage dans le tablespace est défini
par la clause segment space management qui peut
être
●
manual
●
auto
Spécifier le mode de gestion d'un tablespace
●
Via la clause extent management de l'ordre create tablespace.
●
L'option dictionnary est déconseillée
●
●
●
●
En cas de gestion locale ( extent management local ), il faut
spécifier le mode de gestion des extension :
●
autoallocate
●
uniform size valeur
Le mode par défaut est autoallocate.
La gestion des extensions uniform permet d'éliminer presque
totalement la fragmentation du tablespace. L'espace peut
toutefois être mal réservé.
La gestion uniform des extentions est le mode par défaut des
tablespace temporaires.
Spécifier le stockage d'un segment
●
●
●
Via la clause storage de l'ordre create
tablespace.
Cette clause est vitale si le tablespace est géré
par le dictionnaire, ce qui est déconseillé par
Oracle.
Dans le cas d'une gestion locale du tablespace
seule l'option initial de la clause storage est
importante. Elle est toutefois plus souvent
employée lors de la création du segment
( create table, create index ).
Spécifier le stockage d'un segment
●
●
●
Via la clause storage de l'ordre create
tablespace.
Cette clause est vitale si le tablespace est géré
par le dictionnaire, ce qui est déconseillé par
Oracle.
Dans le cas d'une gestion locale du tablespace
seule l'option initial de la clause storage est
importante. Elle est toutefois plus souvent
employée lors de la création du segment
( create table, create index ).
Tablespace temporaire
●
●
●
●
Lors d'une requête demandant un tri, Oracle tente de faire celui-ci en PGA.
Si le tri ne tient pas en mémoire, Oracle stocke les résultats intermédiaires
sur disque, dans un tablespace temporaire.
Les requêtes concernées sont :
●
select ...order by
●
select ...group by
●
select distinct...
●
Requête ensembliste : union, intersect, minus
●
create index
●
calcul des statistiques optimiseur
●
Jointure sort merge join ou tri fusion
●
Les tables temporaires.
Lors de la création de l'instance, il est conseillé de définir un tablespace
temporaire par défaut, sinon le tablespace SYSTEM est utilisé.
Création d'un tablespace temporaire
●
●
●
●
●
La syntaxe ressemble à celle des tablespaces permanent,
toutefois Oracle n'utilise pas un datafile, mais un tempfile.
SQL> create temporary tablespace TMP tempfile
'/u02/app/oracle/oradata/RED/tmp_01.dbf' size 2G;
La création est rapide, car le fichier n'est pas vraiment
créé. Il grandira en fonction des besoins jusqu'à sa taille
maxi, ici 2Go.
Un tablespace temporaire est toujours créé avec des
extensions uniform d'une taille par défaut de 1M.
Le tablespace temporaire utilise toujours des blocs
standards.
Exercice
●
Pour la suite du cours
●
Créer un tablespace permanent DATA_ALICE de 20Mo
●
Créer un tablespace temporaire TEMP_ALICE de 5Mo
●
●
SQL> create tablespace DATA_ALICE datafile
'/u01/app/oracle/oradata/RED/data_alice_01.dbf' size
20M;
SQL> create temporary tablespace TEMP_ALICE
tempfile
'/u01/app/oracle/oradata/RED/temp_alice_01.dbf' size
5M;
Tablespace temporaire par défaut
●
●
●
Un tablespace temporaire pour être utilisé doit être affecté à un
utilisateur. Ce point sera vu lors de la gestion des utilisateurs.
Il est conseillé de définir un tablespace temporaire par défaut pour
l'ensemble de la base, car sinon le tablespace SYSTEM est utilisé et
c'est très mauvais pour les performances.
Lors de la création de la base RED, fut mis en place un tablespace
temporaire par défaut.
●
Il est possible de changer le tablespace par défaut ainsi:
●
SQL> alter database default temporary tablespace TMP;
●
Cette fonction est pratique pour déplacer le tablespace temporaire
sur un autre disque, bien qu'il soit possible d'utiliser la même
technique que pour le tablespace SYSTEM ( pas de notion
oline/offline sur un tablespace temporaire ).
Espace alloué au tablespace
temporaire
●
●
●
●
Contrairement aux tablespaces permanents, l'espace disque pour un tablespace
temporaire n'est pas véritablement créé. Ainsi il est possible que la taille souhaitée
ne puisse pas être obtenue.
Pour éviter ce phénomène, le plus simple est de réserver, à sa création, l'espace
souhaité pour le tablespace temporaire.
Dans un premier temps, créer un tablespace ordinaire
SQL> create tablespace TEMPO datafile
'/u02/app/oracle/oradata/RED/tempo_01.dbf' size 2G;
●
Cette action réserve un fichier de 2G, puis supprimer le tablespace ainsi :
●
SQL> drop tablespace TEMPO;
●
●
●
Enfin créer le tablespace temporaire définitif en réutilisant le fichier créé
précédement
SQL> create temporary tablespace TEMPO tempfile
'/u02/app/oracle/oradata/RED/tempo_01.dbf' size 2G reuse;
Ainsi aucun risque de manquer d'espace pour le tablespace temporaire.
Trouver les informations sur les tablespaces.
●
Il existe plusieurs vues dans le dictionnaire des données donnant ces informations.
●
DBA_TABLESPACES
●
DBA_DATA_FILES → tablespaces permanents
●
DBA_TEMP_FILES → tablespaces temporaires
●
SQL> select tablespace_name, file_name, (bytes/1024/1024) "Taille en Mo"
from dba_data_files order by tablespace_name,file_name;
TABLESPACE_NAME FILE_NAME
Taille en Mo

DATA_RED /u02/app/oracle/oradata/RED/DATA_RED_01.dbf
2500
DATA_RED /u02/app/oracle/oradata/RED/DATA_RED_02.dbf
2500
DATA_STATS
/u02/app/oracle/oradata/RED/DATA_STATS_01.dbf
4000
DATA_STATS
2500
DATA_STATS
1500
IDX_STATS
/u03/app/oracle/oradata/RED/IDX_STATS_01.dbf
4000
IDX_STATS
3000
IDX_STATS
3000
SYSAUX
/u01/app/oracle/oradata/RED/sysaux01.dbf 500
SYSTEM
/u01/app/oracle/oradata/RED/system01.dbf 500
UNDO_TBS /u01/app/oracle/oradata/RED/undo_tbs01.dbf
50
Gestion OMF
●
Oracle Management Files
●
Permet une gestion plus facile des fichiers et des tablespaces.
●
On défini un emplacement où seront stockés les fichiers
●
La gestion des noms de fichiers et leur dimensionnement est automatique
●
Un tablespace est créé ainsi :
●
●
●
●
●
SQL> create tablespace DATA;
Le tablespace DATA aura une taille de 100Mo et s'agrandira par pas de 10Mo
jusqu'aux limites physiques.
OMF permet donc de s'affranchir de l'administration des fichiers de données.
OMF est utile pour créer rapidement une base à des fins de tests ou de
développement. Utile aussi pour une application stand-alone utilisant une base
Oracle.
OMF est très souvent utilisé en conjonction avec ASM.
Modification de RED pour utiliser
OMF
●
●
Se connecter root et créer un nouveau répertoire.
●
su - root
●
mkdir -p /u04/app/oracle/oradata
●
chown -R oracle:oinstall /u04
●
exit
Se connecter à RED en system
●
●
Créer un tablespace DATA
●
●
SQL> alter system set db_create_file_dest = '/u04/app/oracle/oradata'
scope= both;
SQL> create tablespace DATA;
Le fichier se trouve sous /u04/app/oracle/oradata/RED/datafile.
Création avec OMF
●
Cette méthode montre le principe de création
d'une base en OMF
●
La base de données sera nommée GREEN.
●
Préparation des répertoires
●
mkdir -p /u04/app/oracle/admin/GREEN/pfile
●
mkdir -p /u04/app/oracle/oradata/GREEN
Fichier de paramètres OMF
●
Placer ce fichier sous /u01/app/oracle/admin/GREEN/pfile et le
nommer initGREEN.ora
db_name = GREEN
db_block_size = 8192
control_files =/u04/app/oracle/oradata/GREEN/control1.ctl
db_create_file_dest = /u04/app/oracle/oradata
db_create_online_log_dest_1 = /u04/app/oracle/oradata
sga_target = 640M
pga_aggregate_target = 160M
●
●
Il y a en OMF une directive pour les datafiles et une autre pour les
groupes de redologs.
Sous windows il faut créer un service avec oradim ainsi :
●
oradim -new -sid GREEN -intpwd manager11 -startmode manual
Fichier de mot de passe OMF
●
●
Le fichier des mots de passe est sous
%ORACLE_HOME%\database sous windows
et $ORACLE_HOME/dbs sous linux
( orapwGREEN.ora ).
Se positionner sous ce répertoire.
●
cd $ORACLE_HOME/dbs
●
orapwd file=orapwGREEN.ora password=manager11
Création de l'instance OMF
●
export ORACLE_SID=GREEN
●
sqlplus /nolog
●
●
SQL> startup nomount pfile='/u01/app/oracle/admin/GREEN/pfile/initGREEN.ora';
●
SQL> create spfile from
pfile='/u01/app/oracle/admin/GREEN/pfile/initGREEN.ora';
●
SQL> create database GREEN
undo tablespace UNDO_TBS
default temporary tablespace TEMP;
●
Les tablespaces system et sysaux sont créés automatiquement. En gestion OMF un
fichier de tablespace fait 100Mo extensible par pas de 10Mo et en taille illimitée.
●
Les datafiles seront sous /u04/app/oracle/oradata/GREEN/datafiles
●
Les redologs sous /u04/app/oracle/oradata/GREEN/onlinelogs
Finalisation création OMF
●
●
●
Création des tables du dictionnaire
●
SQL> @?/rdbms/admin/catalog.sql
●
SQL> @?/rdbms/admin/catproc.sql
●
SQL> @?/rdbms/admin/utlrp.sql
Mots de passe sys et system
●
SQL> alter user sys identified by manager11;
●
SQL> alter user system identified by manager11;
Se reconnecter en system/manager11 et lancer le script pupbld.sql
●
SQL> @?/sqlplus/admin/pupbld.sql
●
Ne pas oublier de configurer le réseau ( tnsname.ora ).
●
Configurer éventuellement le database control
●
export ORACLE_SID=GREEN
●
emca -repos create
●
emca -config dbcontrol db
Tester la gestion OMF
●
●
●
●
Se connecter à la base GREEN en
system/manager11 et créer un tablespace
nommé DATA_GREEN
SQL> create tablespace DATA_GREEN;
SQL> select tablespace_name, file_name,
(bytes/1024/1024) "Taille en Mo"
from dba_data_files order by
tablespace_name,file_name;
Vérifier la création du fichier physique sous
/u04/app/oracle/oradata/GREEN/datafiles
Les segments d'annulation
●
●
●
●
Stockent les informations avant la modification de cellesci.
Les segments d'annulation sont utilisés :
●
par l'ordre rollback
●
la lecture cohérente
●
certaines fonctions de flashback
●
la récupération de la base ( RECOVER )
L'ordre INSERT est peu gourmand en segments
d'annulation → pas de données avant.
Les ordres UPDATE et DELETE génèrent plus de
segments d'annulation.
Gestion des segments d'annulation
●
●
●
●
●
Elle peut être manuelle ou automatique par la configuration du
paramètre d'initialisation undo_management=auto ou manual.
Oracle déconseille la gestion manuelle qui oblige à gérer des rollback
segments comme sous les versions pré-9i.
La gestion manuelle n'apporte aucun avantage.
Il existe un segment d'annulation nommé SYSTEM et stocké dans le
tablespace SYSTEM. Il permet à une base de toujours démarrer
même si les structures adaptées ( tablesapce UNDO ou rollback
segment ) n'existent pas.
Il faut toutefois créer au moins un tablespace UNDO spécifique sinon
la première transaction hors données du dictionnaire échouera
( Erreur Oracle : ORA-01552 ).
Durée de rétention
●
Quand une transaction se termine par commit ou rollback, les données
contenue dans le tablespace UNDO deviennent inutiles sauf :
●
●
●
●
●
Pour la lecture cohérente ( celle qui déclenche parfois l'erreur : ORA-01555,
snapshot too old )
Pour certaines fonctions de flashback.
Le paramètre undo_retention permet de définir la durée de
conservation des données dans le tablespace UNDO. Sa valeur par
défaut est de 900 secondes → 15 minutes.
Il est possible de garantir la durée de rétention dans le tablespace
UNDO. Attention cette fonctionnalité peut interdire les transactions si le
tablespace UNDO est trop petit pour garantir la durée de rétention →
Erreur Oracle ORA-30036.
Si l'erreur ORA-01555 se produit, ce qui est normalement rare, il faut
agrandir le tablespace UNDO.
Mise en œuvre de l'annulation
●
●
Mettre le paramètre undo_management=auto. En
11g c'est la valeur par défaut.
Déclarer éventuellement le tablespace UNDO
●
●
●
undo_tablespace=undo_tbs
Ce tablespace sera utilisé au démarrage de l'instance,
sinon on utilise celui du tablespace SYSTEM.
Définir la durée de rétention ( 15 minutes par défaut ).
●
undo_retention=1800
●
→ 30 minutes
●
La valeur maximale est 2^32 - 1 = 49 000 jours.
Lecture cohérente
Alice
Requête de
mise à jour de
la table article :
prix → +10%
Bob
écriture
Requête demande
de prix d'un article
→ prix avant augmentation
La lecture se fait dans les
segments d'annulation
lecture
Requête demande
de prix de plusieurs articles
→ prix avant augmentation
La lecture se fait dans les
segments d'annulation
lecture
commit
Fin de la requête de Bob, qui
voit toujours les données au
moment de son lancement
malgré le commit de Alice.
Incidence nulle
sur la requête de
Bob.
Temps
Segments
d'annulation
Temps
Transactions et UNDO
●
●
●
●
●
●
Les transactions portent sur les
ordres DML insert, update et delete.
Lors d'une transaction les données
avant modification sont copiées
dans un bloc du tablespace UNDO.
Ces blocs restent disponibles
jusqu'à la validation de la
transaction soit par commit ou
rollback.
Commit provoque une écriture dans
le redolog courant.
Rollback remet les données de
l'UNDO dans le Database Buffer
Cache.
Les données restent également
dans les blocs du tablespace UNDO
pour les actions de flashback.
Database
Buffer Cache
UNDO
rollback
Ordre
DML
commit
lgwr
Redolog
Blocs dans tablespace
UNDO
Bloc
protégé
Bloc
non protégé
Blocs non expirés
●
●
●
Bloc
non protégé
Blocs expirés
Rouge : Bloc non expiré et protégé. Bloc ne devant pas être
supprimé
●
Attente de fin de transaction
●
Lecture cohérente
●
Garantie de rétention
Orange : Bloc non expiré et non protégé. Bloc n'étant plus
utilisés mais entrant dans la politique de garantie de rétention.
Vert : Bloc expiré et non protégé. Bloc pouvant être recyclé.
Visualiser l'état des segments
d'annulation
●
●
La requête suivante permet de lister dans un
tablespace d'UNDO les segments d'annulation en
cours d'utilisation (ACTIVE) ou contenant des blocs
n'ayant pas encore expirés (UNEXPIRED) :
SQL> select segment_name,
sum(bytes/1024/1024) as "Taille (Mb)", status
from dba_undo_extents
where tablespace_name = 'UNDO_TBS'
and status in ('ACTIVE','UNEXPIRED')
group by segment_name,status order by 2 desc ;
Informations sur l'UNDO
●
3 paramètres dans le spfile
●
SQL> show parameter undo
NAME
TYPE
VALUE

undo_management string
AUTO
undo_retention
900
integer
undo_tablespace string
UNDO_TBS
Modifier la durée de
rétention
●
Se connecter en system/manager11@red
●
●
●
●
SQL> alter system set undo_retention=1800
scope=both ;
La durée de retention est maintenant de 1 800
secondes soit 30 minutes.
Cet ordre peut échouer si le tablespace UNDO
n'est pas assez volumineux.
Il faut dans ce cas agrandir le tablespace UNDO.
Agrandir le tablespace UNDO
●
●
●
Modifier la taille d'un tablespace UNDO n'est pas toujours simple.
Lors de la création de la base un tablespace UNDO ( UNDO_TBS ) d'une
taille de 25Mo fut mis en place. Si cette taille est insuffisante procéder ainsi.
Création, similaire aux tablespaces permanents en stipulant undo
tablespace.
●
●
Changer le tablespace undo actif
●
●
●
create undo tablespace tbs_undo datafile
'/u02/app/oracle/oradata/RED/tbs_undo_01.dbf' size 2G;
alter system set undo_tablespace = tbs_undo scope=both;
Si des segments d’annulations sont utilisés dans des transactions lors d'un
changement de tablespace undo, leurs états ne seront pas OFFLINE mais
PENDING OFFLINE jusqu'à la fin des transactions en cours.
Supprimer le tablespace undo original.
●
drop tablespace undo_tbs including contents and datafiles;
Erreur ORA-30013
●
●
●
ORA-30013: undo tablespace ‘UNDO_TBS' is
currently in use
Cette erreur survient si lors du changement de
tablespace UNDO il y a encore des blocs non
expirés.
Il faut alors rechercher les sessions qui utilisent
encore le tablespace UNDO afin de demander
la validation des transactions en cours.
Sessions utilisant UNDO
●
●
La requête suivante permet de connaître les sessions utilisant le tablespace
UNDO.
SQL> select a.name,b.status,d.username,d.sid, d.serial#,d.osuser
from v$rollname a, v$rollstat b, v$transaction c, v$session d
where a.usn=b.usn and a.usn=c.xidusn
and c.ses_addr=d.saddr and a.name in
( select segment_name from dba_segments
where tablespace_name='UNDO_TBS' );
NAME STATUS USERNAME SID SERIAL# OSUSER
_SYSSMU3$ PENDING OFFLINE ALICE 121 36482 oracle
●
Il suffit de demander à l'utilisateur alice de valider sa transaction.
●
Il est également possible de forcer la deconnexion
●
SQL> alter system kill session '121,36482' immediate;
Garantir la durée de
rétention
●
SQL> select tablespace_name, retention
from dba_tablespaces;
TABLESPACE_NAME RETENTION

SYSTEM NOT APPLY
SYSAUX NOT APPLY
UNDO_TBS NOGUARANTEE
TEMP NOT APPLY
●
Activer la garantie de rétention
●
●
SQL> alter tablespace undo_tbs retention guarantee ;
Annuler la garantie de rétention
●
SQL> alter tablespace undo_tbs retention noguarantee ;
Dimensionner le tablespace
UNDO
●
●
La rêquete suivante permet de donner la dimension optimale du tablespace UNDO.
SQL> select d.undo_size/(1024*1024) "Taille Actuelle [Mo]", substr( e.value,1,25) "Undo Rétention
[Sec]",
(to_number(e.value) * to_number(f.value) * g.undo_block_per_sec) / (1024*1024) "Taille Optimale
[Mo]"
from ( select sum(a.bytes) undo_size from v$datafile a, v$tablespace b, dba_tablespaces c where
c.contents = 'UNDO' and c.status = 'ONLINE' and b.name = c.tablespace_name and a.ts# = b.ts# )
d,
v$parameter e, v$parameter f,
( select max(undoblks/((end_time-begin_time)*3600*24)) undo_block_per_sec from v$undostat ) g
where e.name = 'undo_retention' and f.name = 'db_block_size' ;
●
Il est important d'avoir eu un temps d'activité sur la base avant de prendre une décision.
●
Le Database Control propose un conseiller ( Undo Advisor ) qui effectue cette tâche.
●
Article intéressant sur le sujet en langue anglaise. http://tamimdba.wordpress.com/category/howto/performace-tuning/optimize-oracle-undo-parameters-performace-tuning-how-to/
User SCOTT/TIGER
●
●
Pour la suite du cours, il sera fait appel aux 4 tables du user
scott.
●
emp
●
dept
●
salgrade
●
bonus
Charger le script de création de cet utilisateur :
●
●
Créer le user scott ainsi :
●
●
wget http://192.168.21.24/ORA/createscott.sql
sqlplus system/manager11@red @$HOME/createscott.sql
Ce script va déclarer un user scott mot de passe tiger et créer
les 4 tables exemples
Les utilisateurs et les droits
Gestion des utilisateurs
●
Ordre SQL : create user
●
●
●
●
User et Schéma sont équivalents sous Oracle
Il est d'usage d'affecter à un utilisateur un
tablespace par défaut.
Il est de bonne pratique de lui affecter également
un tablespace temporaire dédié
●
SQL> create user alice identified by ecila default
tablespace data_alice temporary tablespace
temp_alice;
Identification des utilisateurs
●
●
●
●
Les utilisateurs peuvent être identifiés de plusieurs manières :
●
Par oracle, c'est le cas de l'utilisateur alice créé précédemment
●
Par le système d'exploitation.
●
Par un produit tiers, Oracle Fusion MiddleWare avec notamment OID
Identification Oracle
●
L'utilisateur se connecte ainsi :
●
sqlplus alice/ecila
Identification OS
●
L'utilisateur se connecte ainsi :
●
sqlplus /
●
Oracle vérifie simplement que l'utilisateur existe au niveau du système d'exploitation.
Identification OID
●
Oracle Internet Directory
●
Produit Oracle → Annuaire LDAP
●
La mise en place de OID dépasse le cadre de ce cours.
Identification OS Linux
●
●
●
●
Pour faire le lien entre l'utilisateur OS et la base de données, Oracle
utilise un préfixe défini par le paramètre os_authent_prefix dont la
valeur par defaut est ops$.
Ainsi un utilisateur gaston au niveau linux aura pour login de
connexion dans oracle ops$gaston.
Il est possible de mettre os_authent_prefix="", ainsi utilisateur
système et oracle sont identiques.
Pour déclarer un utilisateur dans Oracle identifié par l'OS :
●
SQL> create user ops$gaston identified externally;
●
SQL> grant connect to ops$gaston;
●
Si os_authent_prefix="" alors :
●
SQL> create user gaston identified externally;
●
SQL> grant connect to gaston;
Exemple d'authentification OS
●
●
Au niveau Linux créer un utilisateur nommé gaston ( passer root, su root )
●
adduser gaston
●
passwd gaston
●
Mettre le mot de passe de votre choix
Se connecter gaston
●
●
●
su - gaston
Exporter les 3 variables suivantes :
●
export ORACLE_BASE=/u01/app/oracle
●
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
●
export PATH=$PATH:$ORACLE_HOME/bin
Se connecter sous oracle ainsi
●
●
sqlplus /
Identification OS Windows
●
●
●
●
●
Sous Windows, le nom de la machine fait partie du login
utilisateur
Ainsi un utilisateur gaston au niveau Windows sur une machine
silverlake aura pour login de connexion dans oracle
OPS$silverlake\GASTON
De plus l'utilisateur gaston doit être membre du groupe
ORA_DBA.
Il est impératif de saisir la chaîne OPS$silverlake\GASTON entre
guillemet et en majuscules.
Pour déclarer un utilisateur dans Oracle identifié par l'OS :
●
SQL> create user ''OPS$silverlake\GASTON'' identified externally;
●
SQL> grant connect to ''OPS$silverlake\GASTON'';
●
●
●
●
Créer un utilisateur ne suffit pas, il faut lui
donner des privilèges
Le privilège minimum pour se connecter à
Oracle est create session.
Historiquement ce privilège est inclus dans le
rôle connect.
Les rôles permettent de regrouper un
ensemble de privilèges sous un nom unique.
●
●
●
●
●
Créer un utilisateur ne suffit pas, il faut lui donner des privilèges
Le privilège minimum pour se connecter à Oracle est create
session.
Historiquement ce privilège est inclus dans le rôle connect.
Les rôles permettent de regrouper un ensemble de privilèges
sous un nom unique.
Il existe 3 rôles historiques dans Oracle
●
connect
●
resource → Permet de créer tables et index ( entre autres )
●
dba → tous les droits !
Affectation de droits
●
Ordre SQL : grant
●
●
●
●
SQL> grant connect, resource to alice ;
Alice peut se connecter ( rôle connect ) et créer des objets ( rôle
resource ).
Création d'un autre user : Bob qui n'aura que le droit d'utiliser les
objets d'Alice
●
SQL> create user bob identified by robert ;
●
SQL> grant connect to bob ;
Bob n'a pas besoin de tablespace par défaut car il n'a pas d'objet à
créer. Il est par contre judicieux de lui donner un tablespace
temporaire. Dans l'exemple bob utilisera le tablespace temporaire
de alice.
●
SQL> alter user bob temporary tablespace temp_alice;
Privilèges et Rôles
●
●
●
●
●
L'objectif est de sécuriser l'accès aux données de la base.
Le principe est d'accorder ( grant ) ou de retirer ( revoke )
des privilèges à un utilisateur.
Pour faciliter la gestion il est possible de regrouper un
ensemble de privilèges dans un rôle.
Oracle propose 3 rôles prédéfinis :
●
connect → permet juste la connexion à la base.
●
resource → permet la création d'objets tables et index.
●
dba → tous les droits, à donner avec parcimonie.
Il est possible de créer des rôles personnalisés.
Types de privilèges
●
●
Système : Autorise création, modification, suppression et exécution
d'objets.
●
create table,
●
create view,
●
create sequence
●
execute...
Objet : Autorise des manipulations sur des objets spécifiques.
●
select
●
insert,
●
delete
●
update
●
Les 4 privilèges ci-dessus peuvent être donnés via le mot clé "all"
●
Affectés à une table.
Création d'objets
●
Se connecter Alice
●
●
●
SQL> create table personne ( code char(2), prenom char(15)) tablespace
data_alice ;
●
SQL> insert into personne values( '01','Alice') ;
●
SQL> insert into personne values( '02','Bob') ;
●
SQL> insert into personne values( '03','Charles') ;
●
SQL> commit ;
Se reconnecter Bob
●
SQL> connect bob/robert@red
●
SQL> select * from personne ;
●
Ne fonctionne pas, il faut spécifier le nom du propriétaire
●
SQL> select * from alice.personne ;
●
Ne fonctionne toujours pas car Bob n'a pas de droits sur les objets de Alice.
Affecter des droits aux autres user
●
Se connecter alice
●
●
Donner le droit de sélection à Bob
●
SQL>grant select on personne to bob ;
●
Les droits peuvent être :
●
●
select
●
update
●
insert
●
delete
●
all
Se reconnecter Bob et tester l'accès à la table personne de alice.
●
●
SQL> select * from alice.personne;
Utiliser les objets d'un autre user
●
●
●
●
Il faut utiliser la commande grant pour donner les droits à un utilisateur.
Il est possible d'utiliser le dictionnaire des données afin de créer simplement un script
d'affectation des droits.
Soit un utilisateur alice souhaitant donner le droit select à bob sur toutes ses tables :
●
SQL> spool $HOME/droits_bob.sql
●
SQL> select 'grant select on ' || table_name || ' to bob;' from user_tables;
●
SQL> spool off
●
Il suffit ensuite de lancer ce script sous sqlplus.
Afin d'éviter à bob de devoir spécifier le nom de alice devant toutes les tables il est
possible de spécifier le schéma sur lequel on travaille. Le DBA doit avoir donné à Bob
le privilège alter session
●
SQL> connect system/manager11@red
●
SQL> grant alter session to bob;
●
●
SQL> alter session set current_schema=alice ;
●
SQL> select * from personne;
Affectation de privilèges objet
●
●
Un utilisateur dispose de tous les droits sur les objets qu'il a créé.
Un utilisateur doit en plus obtenir des privilèges sur les objets des autres utilisateurs pour
les utiliser.
●
Soit deux utilisateurs alice et bob ainsi qu'une table personne appartenant à alice.
●
Alice souhaite donner le droit de sélection et d'insert à Bob sur sa table personne.
●
Connecté alice sur la base :
●
●
●
●
SQL> grant select, insert on personne to bob;
Pour donner tous les droits à Bob sur sa table personne, alice procède ainsi :
●
SQL> grant select, update, delete, insert on personne to bob;
●
ou
●
SQL> grant all on personne to bob;
Il est possible de ne donner des privilèges que sur certaines colonnes de la table
●
SQL> grant update ( prenom ) on personne to bob;
●
→ Bob ne pourra faire un update que sur le champ prénom.
Important : Pour mettre à jour ou supprimer des lignes update et delete ne suffisent
pas, select est requis.
WITH GRANT OPTION
●
●
●
●
Soit la requête suivante exécuté en connexion
alice:
SQL> grant all on personne to bob with grant
option;
Cette affectation donné par Alice à Bob sur la
table personne accorde le droit à Bob de
transmettre ce privilège à un autre utilisateur.
Un utilisateur ne peut pas transmettre plus de
privilèges qu'il a reçu.
PUBLIC
●
●
●
Oracle offre la possibilité de donner des
privilèges à tous.
SQL> grant select on personne to public;
Alice donne à tous les utilisateurs présents et
futurs le droit de sélection sur la table
personne.
Rôles
●
Un utilisateur dispose parfois de nombreux privilèges. Afin
de faciliter l'affectation des mêmes privilèges à plusieurs
utilisateurs il est possible de créer un rôle.
●
Un rôle regroupe des privilèges.
●
Syntaxe : create role
●
SQL> create role developpeur;
●
SQL> grant create session, create table, create indextype,
create view to developpeur;
●
Affectation du rôle développeur à charles :
●
SQL> create user charles identified by selrahc;
●
SQL> grant developpeur to charles;
Pour en savoir plus
●
●
●
Le site developpez.com comporte un article
intéressant et en français sur les rôles et les
privilèges.
http://oracle.developpez.com/guide/administrati
on/adminrole/
Consulter la documentation Oracle afin d'avoir
l'ensemble des options relatives aux privilèges
et aux rôles.
Supprimer des droits
●
Ordre SQL revoke
●
Se connecter alice
●
SQL> connect alice/ecila@red;
●
SQL> revoke all on personne from bob ;
●
→ supprime tous les droits de bob sur la table personne.
●
Comme pour grant les droits supprimés peuvent être :
●
select
●
update
●
insert
●
delete
●
all
Exercice
●
●
Créer un utilisateur charles avec comme rôle
connect et resource. Lui donner un mot de
passe quelconque.
Se connecter charles et créer la table produit
●
●
SQL>create table produit ( p char(2), np char(15));
Insérer une ligne
●
SQL>insert into produit values('P1','Huitre');
●
SQL>commit;
Suppression d'un utilisateur
●
Ordre SQL : drop user
●
SQL> drop user charles;
●
●
●
→ Cet ordre échoue car charles possède des
objets, la table produit. Pour supprimer charles
il faut d'abord supprimer tous ses objets ou
utiliser la commande :
SQL> drop user charles cascade;
Cette commande supprime tous les objets de
charles et enfin son compte oracle.
Verrouiller un compte
●
Plutôt que de supprimer un utilisateur, il est possible de
lui interdire toute action.
●
Seul un DBA peut verrouiller un compte
●
Exemple verrouiller le compte Bob
●
●
●
Il sera impossible à Bob de se connecter. Faire l'essai
●
●
SQL> alter user bob account lock;
SQL> connect bob/robert@red → compte verrouillé !
Déverrouillage
●
SQL> alter user bob account unlock;
Les profils
●
Ensemble de limitations de ressources affectées à un utilisateur.
●
Les ressources suivantes peuvent être limitées :
●
●
●
●
Temps CPU
●
Nombre de lectures logiques
●
Nombre de sessions simultanées
●
Temps d'inactivité d'une session
●
Durée maxi d'une session
●
Quantité de mémoire SGA( en MTS uniquement )
Le profil peut aussi mettre en place une politique de gestion des mots de passe.
Si rien n'est spécifié, un utilisateur dispose d'un profile nommé DEFAULT qui
n'a aucune limite.
En pratique les profils ne sont pas très souvent utilisés, car Oracle propose une
autre solution → Database Ressource Manager via le package
dbms_resource_manager ( hors cours )
Exemple de profil
●
●
●
●
SQL> create profile exploitation limit
sessions_per_user 3
idle_time 30;
Ce profil limite à 3 le nombre de sessions simultanées et à 30
minutes d'inactivité de session.
Pour que la gestion des profils soit prise en considération il faut
l'activer
●
SQL> connect system/manager11@red
●
SQL> alter system set resource_limit=true scope=both;
Affectation à un utilisateur
●
●
SQL> alter user alice profile exploitation;
Affectation lors de la création du user
●
SQL> create user denise identified by esined profile exploitation;
Durée validité mot
de passe
●
●
●
Quand un utilisateur est créé il hérite par défaut
d'un profile nommé DEFAULT.
Avant la 11gR2 la clause
PASSWORD_LIFE_TIME avait la valeur
UNLIMITED. Elle est maintenant de 180 jours.
SQL> select limit from dba_profiles
where resource_name =
'PASSWORD_LIFE_TIME'
and profile = 'DEFAULT';
Modifier la durée de
validité du mot de passe
●
●
●
Sans action sur ce plan certaines applications
risquent de bloquer au bout de 6 mois.
La requête suivante permet de revenir aux
conventions pré-11gR2.
SQL> alter profile default
limit password_life_time unlimited;
Comment supprimer une session
Rechercher la session
SET LINESIZE 100
COLUMN spid FORMAT A10
COLUMN username FORMAT A10
COLUMN program FORMAT A45
SELECT s.inst_id, s.sid, s.serial#, p.spid, s.username,
s.program
FROM gv$session s, gv$process p
WHERE p.addr = s.paddr AND p.inst_id = s.inst_id
AND s.type != 'BACKGROUND';
●
Supprimer une session
●
SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';
Les structures de stockage
Gestion des tables
●
●
●
Les tables sont un des objets principaux de la
base de données.
Avec les index, il s'agit des seuls objets
occupant de la place en plus de leur définition
dans le dictionnaire des données.
Les tables contiennent des segments
composés d'extensions ( extent ) eux même
composés de blocs contigus .
Organisation du stockage dans les
blocs
En-tête de bloc
Espace Libre
Les lignes sont
de longueur variable
selon le remplissage
de chaque colonne.
Ligne 10
Ligne 9
Ligne 8
Ligne 5
Ligne 6
Ligne 4
Ligne 2
En-tête
de ligne
Ligne 7
Taille du bloc:
8192 → 8ko
Ligne 3
Ligne 1
05
En-tête de colonnes
Emile
Donnée de la colonne
En-tête du bloc
●
●
●
L'en-tête contient
●
l'adresse du bloc,
●
le type de segment ( table, index, temporaire, annulation ),
●
un répertoire des tables, si bloc de table,
●
un répertoire des lignes et des entrées pour les transactions
●
Taille variable de 100 à 200 octets.
Stockée dans la partie haute du bloc, les données sont
insérées par le bas du bloc.
L'en-tête peut grossir ( vers le bas ) en fonction de
l'activité du bloc. Il ne rétrécit jamais.
Structure d'une ligne
●
●
●
●
L'en-tête de ligne contient :
●
le nombre de colonnes,
●
chaînage éventuel ( voir plus loin ),
●
verrou
●
Taille minimale 3 octets
Ensuite chaque colonne est stockée avec une en-tête de
colonne qui contient la longueur de la colonne ( taille de 1 à 3
octets ) puis la valeur de la colonne.
La longueur totale d'une ligne dépend du type de données de
chaque colonne et du nombre de colonne.
Un bloc ne contient donc pas que des données. Il y a des
informations utiles à Oracle pour sa gestion.
Gestion de l'espace dans un bloc
●
●
●
●
●
Géré manuellement ou automatiquement.
La gestion manuelle est un héritage des anciennes
versions de Oracle, son emploi est déconseillée.
La gestion automatique ( ASSM ) permet une
meilleure utilisation de l'espace dans les blocs.
La gestion automatique est une option du
tablespace via la clause segment space
management auto qui est la valeur par défaut.
Avec la gestion automatique le seul paramètre
éventuellement à surveiller est PCTFREE.
PCTFREE
●
●
●
●
Pourcentage Libre
Permet de ne pas remplir le bloc à 100% afin de
conserver de la place pour les mises à jour de la ligne
( update ).
Lorsqu'une ligne est insérée toutes ses colonnes ne
sont pas obligatoirement renseignées. Oracle réserve
donc de l'espace afin que la ligne reste dans le même
bloc lors d'un update.
Si la place est insuffisante, Oracle migre la ligne dans
un autre bloc entraînant ainsi un chaînage de ligne
dommageable pour les performances.
Principe du PCTFREE
●
●
●
Exemple d'un PCTFREE à 10 → 10%
Le bloc ne sera rempli qu'à 90%, ensuite il n'y
aura plus d'insertions dans le bloc.
Ces 10% seront utilisés pour les ordres update
sur les lignes contenues dans le bloc.
En-tête
En-tête
Espace libre
insertions
Espace libre
Données
PCTFREE
Principe de la gestion automatique
●
●
●
Oracle utilise un bitmap pour connaître le taux de remplissage de
chaque bloc.
●
0% → bloc plein ( - pctfree éventuel ),
●
0 à 25% d'espace libre,
●
●
●
75 à 100% d'espace libre.
Lors de l'insertion d'une ligne Oracle consulte ce bitmap pour
déterminer quel bloc il peut utiliser.
La gestion manuelle utilise des informations complémentaires
( pctused, freelist... ) stockées dans le dictionnaire des données.
Ce processus pénalise les performances et ne présente aucun
intérêt.
Déterminer le PCTFREE
●
●
●
●
Il est fixé au niveau du tablespace, il peut
toutefois être modifié pour une table.
Sa valeur par défaut est de 10%
Si une ligne est insérée et ne sera jamais
modifiée, le PCTFREE peut être à 0, le bloc sera
utilisé à 100% de sa capacité.
Par contre si une ligne après son insertion fait
l'objet de nombreux update susceptibles
d'agrandir sa taille, le PCTFREE peut être
augmenté. Sinon il se produira une migration.
Le ROWID
●
●
●
●
●
●
●
Colonne virtuelle, ou pseudo-colonne.
●
SQL>connect alice/ecila@red
●
SQL> select rowid, code, prenom from personne;
Présente dans chaque table, donne l'adresse physique du stockage de la
ligne.
Utilisé en interne par Oracle pour les index.
C'est l'accès le plus rapide à une ligne quand il est connu → Oracle pointe
directement à la bonne adresse.
Le ROWID est unique pour toute ligne et ne change jamais, tant que la
ligne n'est pas supprimée.
Un update ne change pas le rowid et si suite à un update la ligne ne peut
être contenue dans un bloc Oracle la migre dans un autre.
Ce phénomène, dit row chained, est préjudiciable aux performances et
doit être évité.
Structure du rowid
●
SQL> select rowid,dname from scott.dept;
ROWID DNAME

AAACyfAAFAAAAAOAAA ACCOUNTING
AAACyfAAFAAAAAOAAB RESEARCH
AAACyfAAFAAAAAOAAC SALES
AAACyfAAFAAAAAOAAD OPERATIONS
●
●
Le codage est en base 64
●
AAACyf → Numéro de l'objet, voir object_id dans dba_objects
●
AAF → Numéro du fichier de données, voir file_id dba_data_files
●
AAAAAO → Bloc de données, relatif au fichier et non au tablespace.
●
AAA → Numéro de ligne dans le bloc.
Le package dbms_rowid, contient des fonctions pour décoder les rowid.
●
Objet : rowid_object
●
Numéro de fichier : rowid_relative_fno
●
Bloc : rowid_block_number
●
Numéro dans bloc: rowid_row_number
Un exemple d'utilité du
rowid
●
Créer en tant que user alice une table personne avec des lignes en double.
●
●
SQL> create table personne ( code char(2), prenom char(15));
●
SQL> insert into personne values ( '01','Alice');
●
SQL> insert into personne values ( '02','Bob');
●
SQL> insert into personne values ( '02','Bob');
●
SQL> insert into personne values ( '03','Charles');
●
SQL> insert into personne values ( '04','Denise');
●
SQL> insert into personne values ( '04','Denise');
●
SQL> insert into personne values ( '05','Emile');
●
SQL> commit;
●
SQL> select rowid,code, prenom from personne;
Utiliser le ROWID pour supprimer des doublons
●
Soit la table personne suivante :
●
Cette table contient des doublons
●
●
Le rowid permet de
différentier chaque ligne
et donc d'éliminer
les doublons
SQL> delete from personne p1
where rowid < (
select max( p2.rowid )
from personne p2
where p1.code=p2.code
and p1.prenom=p2.prenom );
●
Supprimer la table personne
●
SQL> drop table personne ;
Chainage et Migration
●
●
●
Dans Oracle on parle souvent de lignes chainées pour
désigner en fait une migration.
L'ambiguïté vient du mot row chained.
Le chainage est du au fait qu'une ligne est trop longue
pour tenir dans un seul bloc.
●
●
●
Le seul moyen d'éviter cela est d'agrandir la taille du bloc.
Grace à la gestion des blocs multiples il est possible de
mettre ces données dans un tablespace ayant des blocs de
16Ko alors que la taille standard est de 8ko.
La migration ( row chained ) peut et doit être évitée en
positionnant correctement le PCTFREE
Principe de migration
rowid
ligne
La ligne augmente
en taille
update
rowid
En-tête
de ligne.
ligne
Si le PCTFREE est suffisant la ligne reste dans le même bloc. Sinon Oracle migre
la ligne dans un autre bloc. Pour lire la ligne, Oracle devra donc lire 2 blocs au lieu d'un.
rowid
Le rowid et l'en-tête de ligne reste dans le bloc d'origine.
L'en-tête contient un pointeur vers le nouveau bloc
stockant la ligne.
ligne
La ligne est migrée dans un autre bloc.
Ce phénomène peut se reproduire plusieurs fois.
Spécifier le PCTFREE à la création d'une table
●
●
●
●
Ordre SQL : create table
SQL> create table article
( codart char(8),
nomart varchar2(50),
codfam char(8),
prix number(6,2) )
tablespace data
pctfree 30;
La table produit sera dans le tablespace data, dont le
pctfree est de 10% mais pour cette table il sera de 30%.
La valeur de pctfree peut varier de 0 à 99, par défaut 10.
Détecter les rows chained
●
La commande analyze table est utilisée pour cela. Attention cette
commande ne fait pas la différence entre chaînage et migration de ligne.
●
Il faut au préalable créer une table dédiée aux rows chained.
●
●
SQL> @?/rdbms/admin/utlchain
●
Ce script met en place la table chained_rows qui servira pour la détection
●
SQL> analyze table alice.personne list chained rows;
●
●
SQL> select count(head_rowid) from chained_rows where
table_name='PERSONNE' and owner_name='ALICE';
Si le résultat est > 0, il faut interroger la ou les lignes afin de voir si il
s'agit d'un problème de chaînage ou de migration.
●
●
SQL> select head_rowid from chained_rows where tablename='PERSONNE' and
owner_name='ALICE' and rownum = 1; → rowid de la ligne
SQL> select * from alice.personne where rowid =
Chainage ou Migration
●
●
●
●
●
La colonne avg_row_len de la table dba_tables donne la
dimension moyenne d'une ligne par table.
Si la longueur moyenne des lignes est supérieur à la
taille du bloc, c'est un problème de chaînage → La table
doit utiliser des blocs plus grands.
Sinon c'est un problème de migration.
Il n'y a pas de réponse exacte au pourcentage
admissible de lignes migrées. L'usage veut de
considérer le problème à partir de 5% des lignes.
Pour supprimer les lignes migrées, il faut réorganiser la
table avec un PCTFREE plus important.
Réorganisation de table
●
Les lignes migrées ne sont pas le seul besoin en
réorganisation de table :
●
libérer l'espace au dessus de la HWM ( voir plus loin )
●
améliorer le taux de remplissage des blocs
●
●
●
réorganiser plus globalement le stockage de la table
( changement de tablespace par exemple )
Oracle propose plusieurs méthodes pour
réorganiser une table, la plus efficace est MOVE.
Réorganiser la table en augmentant le PCTFREE
●
SQL> alter table alice.personne move pctfree 20;
Un exemple de migration
●
Se connecter sous le user alice.
●
●
Créer la table chained_rows
●
●
sqlplus alice/ecila@red
SQL> @?/rdbms/admin/utlchain ;
Créer une table test et y insérer des lignes
●
SQL> create table test_migration ( code number, jour date ) ;
●
SQL> begin
for i in 1..100000 loop
insert into test_migration values ( i, sysdate + i );
end loop;
commit;
end;
/
Un exemple de migration suite
●
●
Ajouter une colonne à la table et la remplir avec la
chaine 'A BLANC'
●
SQL> alter table test_migration add ( texte varchar(15)) ;
●
SQL> update test_migration set texte='A BLANC' ;
●
SQL> commit ;
Analyser la table afin de compter les lignes migrées.
●
SQL> analyze table test_migration list chained rows ;
●
SQL> select count(*) from chained_rows;
●
→ plus de 40 000 lignes migrées.
Un exemple de migration fin
●
Il faut donc réorganiser la table avec un
PCT_FREE plus important
●
●
SQL> alter table test_migration move pctfree 20;
Refaire l'analyse
●
●
SQL> delete from chained_rows ;
SQL> analyze table test_migration list chained
rows ;
●
SQL> select count(*) from chained_rows;
●
→ Plus de lignes migrées.
Estimer le PCTFREE
●
●
●
●
PCTFREE = 100 x ( 1 -Ti / Tf )
Ti = taille initiale moyenne de la ligne en octets,
donc au moment de l'insertion.
Tf = taille finale moyenne de la ligne en octets,
donc après mise à jour.
Les valeurs de Ti et Tf peuvent être estimées à
partir des statistiques → colonne avg_row_len
de la table dba_tables.
Surveiller l'utilisation d'une table
●
Depuis la 10g les tables sont nativement mise en surveillance.
●
●
●
●
Paramètre STATISTICS_LEVEL <> BASIC
Ceci augmente l'efficacité du calcul de l'optimiseur statistique.
Ce mécanisme permet d'analyser l'activité sur une table et de
disposer d'une évaluation sur ses transactions.
Ces informations sont stockées dans la table
dba_tab_modifications ( schéma sys )
●
table_name = nom de la table
●
inserts = nombre approximatif de lignes insérées
●
updates = nombre approximatif de lignes mise à jour
●
deletes = nombre approximatif de lignes supprimées
Spécifier la clause storage lors de la création d'une table
●
●
●
●
●
●
Cette option vue au niveau du tablespace est le plus souvent employée lors
de la création de la table.
SQL> create table article
( codart char(8),
nomart varchar2(50),
codfam char(8),
prix number(6,2) )
tablespace data
storage ( initial 10M );
Lors de la création de la table article une extension de 10M sera allouée.
Ce principe permet en estimant la volumétrie finale de la table d'être certain
que toutes les données seront dans la même extension.
Il est important de noter que le fait qu'une table soit stockée dans plusieurs
extensions ne pose pas de problème de performance.
Il est de bonne pratique de dédier un tablespace aux tables volumineuses.
Espace occupé par une table
●
Pour chaque table, Oracle connait le dernier bloc utilisé.
●
Il s'agit de la HWM ( High Water Mark )
●
La HWM augment lors des insertions mais ne diminue pas lors
des suppressions.
Table vide
initialement
Table après
insertions
HWM
●
Table après
suppression
HWM
La HWM permet de connaître le nombre maximal de blocs utilisés pendant son existence. Mais
pas les blocs réellement utilisés ou leur remplissage.
●
La HWM marque pour Oracle le dernier bloc où il est susceptible de trouver une ligne.
●
En cas de parcours complet de la table, Oracle recherche donc dans tous les blocs sous la HWM.
HWM et remplissage de bloc
●
●
●
●
Si une table est soumise à des suppressions
nombreuses, le taux d'occupation des blocs peut
ne plus être optimal.
De plus en cas de parcours complet de la table
tous les blocs, y compris les vides, seront
explorés.
Le package dbms_space permet de connaître le
taux d'occupation des blocs d'une table.
Il existe plusieurs procédures dans ce package,
dont la plus utile est space_usage.
dbms_space.space_usage
●
●
●
Charger les scripts espace.sql et inutile.sql ainsi :
●
wget http://192.168.21.24/ORA/espace.sql
●
wget http://192.168.21.24/ORA/inutile.sql
La section intéressante se trouve après le begin, il suffit de changer le
nom du propriétaire et de la table avant utilisation
...
begin
dbms_space.space_usage(
segment_owner
=> 'ALICE',
segment_name
=> 'TEST',
segment_type
=> 'TABLE',
…
Ce script permet de calculer le taux d'occupation d'une table dans ses
blocs.
Mise en place du test
●
Créer la table test
●
●
ALICE:RED > create table test as
select rownum as numop,
rownum / (24 * 60) + sysdate - 1000 as date_op
from dual
connect by rownum <= 200000;
●
Cette commande va créer une table de 200 000
enregistrements.
Mesurer l'espace initial dans la table TEST
ALICE:RED > sta espace
Blocs :
. Pleins
= 497
. 0 à 25% d'espace libre = 0
. Non formatés
=0
ALICE:RED > sta inutile
Blocs :
. Total = 640
●
. Inutilisés
= 125
. Utilisés
= 515 → HWM
La différence entre le nombre de blocs pleins et utilisés ( 18 ) vient des index bitmap pour
la gestion automatique qui ne sont pas comptés par dbms_space.
Supprimer une ligne sur deux
ALICE:RED > delete test where mod(numop, 2) = 0;
ALICE:RED > commit;
Blocs :
. Pleins
=1
. 25 à 50% d'espace libre = 496 → les blocs ne sont remplis qu'à 50% maxi
. Non formatés
=0
Blocs :
. Total = 640
. Inutilisés
= 125
. Utilisés
= 515 → la HWM n'est pas modifiée
Réorganiser la table
ALICE:RED > alter table test move;
Blocs :
. Pleins
= 249
. Non formatés
=0
Blocs :
. Total = 384
. Inutilisés
= 121
. Utilisés
= 263 → HWM modifiée, un parcours complet ne lira plus que 263 blocs au
lieu de 515.
Alter table...move
●
●
Cette action n'est pas neutre, car les rowid des
enregistrements changent.
Il faut donc reconstruire les index ( si ils existent )
●
●
alter index … rebuild
Il faut également recalculer les statistiques de
l'optimiseur
●
exec dbms_stats.delete_table_stats('ALICE','TEST');
●
exec dbms_stats.gather_table_stats('ALICE','TEST');
Gestion des index
●
●
●
Un index est défini sur une ou plusieurs colonnes
d'une table, formant ainsi la clé d'index.
Un index contient deux colonnes
●
la clé d'index ( qui peut être sur x colonnes )
●
le rowid de l'enregistrement
Exemple : On recherche dans l'index le code '04'
Parcours de l'index
INDEX
TABLE PERSONNE
CLE
ROWID
ROWID
CODE
PRENOM
01
A
124
007
04
DENISE
02
278
124
01
ALICE
03
269
269
03
CHARLES
04
007
278
02
BOB
05
730
436
06
FRANCIS
06
436
730
05
EMILE
Pointe vers
Type d'index
●
●
●
●
Un index peut être unique ou non
Oracle préconise de ne pas utiliser d'index unique
mais de définir une contrainte primary_key ( un
index implicite est alors mis en place )
Un index peut être sur un ou plusieurs colonnes
( index concaténés )
Oracle utilise deux type d'index
●
B-Tree
●
Bitmap
Index B-Tree
●
●
●
●
Arbre Balancé, c'est le type d'index le plus courant.
L'index stocké sous forme d'arbre ordonné et
équilibré automatiquement par Oracle.
Il peut avoir 2, 3 voire plus de niveaux (profondeur
de branche).
La recherche consiste en la détermination de
l'intervalle pour connaître le niveau inférieur et ainsi
de suite jusqu'à atteindre la feuille qui stockera, prés
de sa valeur, le rowid du ou des enregistrements
recherchés.
Principe B-Tree : Trouver la valeur
18
7
4
1
3
Chemin pour
trouver 18.
16
10
4
6
7
8
10
20
12
16
18
20
22
24
24
26
27
Index Bitmap
●
●
●
●
●
Ils servent à indexer les champ à faible cardinalité →
4/5 valeurs distinctes.
Ils peuvent parfois améliorer les performances
Toutefois ils sont gourmands en ressource, car l'index
est reconstruit à chaque mise à jour de la ligne et pas
uniquement de la colonne indexée.
Ils ne sont d'ailleurs utilisés que pour les bases de type
datawarehouse, où les informations sont mises à jour
en batch.
Il importe d'effectuer des tests avant d'utiliser des index
bitmap, car l'effet peut être contraire à celui recherché.
Sélectivité d'un index
●
●
●
Un bon index est un index sélectif .
La sélectivité est le rapport entre le nombre de valeurs dans
l'index et le nombre de lignes dans la table.
Elle est facile à calculer :
●
select count(distinct valeur_colonne)/count(*) from table;
●
Exemple : select count(distinct code_art)/count(*) from article;
●
Plus ce chiffre se rapproche de 1 plus l'index est sélectif
●
Plus ce chiffre se rapproche de 0 , moins l'index est sélectif
●
Une colonne n'ayant que des valeurs uniques est un bon index.
●
Une colonne n'ayant que 2 valeurs possibles, exemple
OUI/NON n'est pas un bon index.
Index ou pas
●
●
●
●
●
Un parcours complet de table est parfois plus efficace
qu'un index, surtout sur les petites tables ( < 200
lignes ).
Si une table tient dans un bloc unique, il est inutile de
l'indexer, Oracle lit la table d'un coup.
Trop d'index sur une table dégradent les performances
en écriture → mise à jour des index.
Si la clé d'index contient les colonnes du select, il est
inutile de lire la table.
Utiliser une fonction sur une clé d'index dans une
clause where → parcours complet de la table.
Index invisibles
●
●
●
●
Sous Oracle 11g, il est possible de définir la
caractéristique INVISIBLE pour un index.
L'index est tenu à jour mais l'optimiseur ne le prend
pas en compte.
Cette fonction permet de tester la pertinence d'un
index
Ceci se configure avec le paramètre :
●
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE
●
OPTIMIZER_USE_INVISIBLE_INDEXES=TRUE
●
La valeur par défaut est FALSE.
Utilisation d'un index invisible
●
Création
●
●
SQL> create index indx_01 on table test ( ville )
invisible;
Il est également possible de rendre un index
visible/invisible par alter:
●
SQL> alter index indx_01 visible;
●
SQL> alter index indx_01 invisible;
Reconstruire les index
●
●
●
●
Les index Oracle sont maintenus automatiquement. Il est
le plus souvent inutile de les reconstruire.
Cette action est toutefois nécessaire en cas de
réorganisation d'une table ou d'un tablespace
●
alter table … move
●
alter tablespace … move
L'ordre le plus efficace est :
●
alter index...rebuild
●
Cet ordre est similaire au alter table...move pour les tables.
La création et la reconstruction d'un index utilisent le
tablespace temporaire.
Le partionning
●
●
●
●
Fonctionnalités optionnelle → version Entreprise de
Oracle
Le partitionnement de tables est généralement
effectué pour améliorer la gestion, la performance ou
la disponibilité.
Chaque partition se retrouve sur des serveurs ou des
disques différents.
Cela permet également d'obtenir une capacité de
base de données supérieure à la taille maximum des
disques durs ou d'effectuer des requêtes en parallèle
sur plusieurs partitions.
Partitionnement
●
●
●
Le partitionnement permet de découper une table
ou un index sur des critères logiques.
La table se comporte alors comme plusieurs tables
de dimensions plus petites.
Les avantages principaux du partitionnement sont :
●
●
de pouvoir définir des critères de stockage différents
pour chacune des partitions → tablespace, initial...
le découpage logique de la table permet un accès plus
rapide aux informations → moins de lectures disques à
effectuer.
Types de partitionnements
●
●
●
●
●
by range : on définit les partitions par tranche supérieure exclusive
(toutes les données < 0)
by list : on définit une valeur par partition (utilisé lorsque la liste de
valeur pour le champ considéré est faible)
by hash : la partition de stockage est calculée dynamiquement par un
calcul de type hash code, ce mode impose un nombre de partitions
2^n
composite : c'est une méthode de partitionnement hybride. Les
données sont d'abord partitionnées by range. Ensuite, chaque partition
sera sous-partitionnée soit by hash ou by list. Il n'est pas nécessaire
d'avoir exactement le même nombre de sous-partitions par partition :
par exemple, une partition peut être constituée de 4 sous-partitions
alors qu'une autre sera composée de 5 sous-partitions.
Le mécanisme de découpage logique peut être étendu sur plusieurs
champs, ainsi que sur deux niveaux. On parle dans ce cas de souspartitionnement.
Exemple de partition
COTPART
ISIN
AVANT
2000
DTE
OUV MAX
De 2000
à 2005
MIN
De 2006
à 2009
CLO
2010
VOLUME
2011
et +
PARTIONNEMENT SUR L'ANNEE DE COTATION
Création de la table
COTPART
●
SQL> create table COTPART (
isin
varchar2(20),
dte
date,
ouv
number,
max
number,
min
number,
clo
number,
volume number )
partition by range (dte)
(
partition cot2000 values less than( to_date('01/01/2000','DD/MM/YYYY')),
partition cotfutur values less than( maxvalue)
);
●
Pour les tables très volumineuses, il est conseillé d'affecter un tablespace par partition.
Insertion des données
●
Insertion
●
SQL> insert into COTPART select isin, dte, round(100*dbms_random.value, 2),
round(100*dbms_random.value, 2),
round(100000*dbms_random.value)
from ACTION, ( select sysdate-rownum dte
from ALL_OBJECTS where rownum < 200000 );
●
Recalculer les statistiques
●
●
SQL> exec dbms_stats.gather_schema_stats ( 'ALICE' );
Visualiser le nombre de lignes par partition
●
SQL> select table_name, partition_name, num_rows from user_tab_partitions;
Gestion des contraintes
●
Pour utiliser les tables, il est possible de définir
des règles → Les contraintes.
Type de la contrainte
Description
Not Null
Une valeur doit être affectée au champ mais les
valeurs ne doivent pas être uniques.
Unique Key
Toutes les valeurs de cette colonne doivent être
uniques. Null est accepté.
Primary Key
Toutes les valeurs de cette colonne doivent être
uniques et ne peuvent pas être nulles.
Foreign Key
Toutes les valeurs de cette colonne sont liées à une
colonne d’une autre table. Null est accepté.
Check
La valeur ajoutée à cette colonne doit valider la règle
de gestion définie pour cette colonne.
Exemple de contraintes
Base de données EPICERIE
PRODUIT
P
NOM_P
COULEUR
ORIGINE
PRIX
La colonne P de la
table produit est une
clé primaire.
MAFOURNITURE
FOURNISSEUR
F
P
QTE
F
NOM
REMISE
VILLE
La concaténation de la
colonne P et de la colonne
F de la table mafourniture
est une clé primaire.
P est une clé étrangère
F est une clé étrangère
La colonne F de la
table fournisseur est une
clé primaire.
Intégrité référentielle
●
●
Les clés primaires et étrangères garantissent
l'intégrité référentielle de la base.
Il est impossible de supprimer un
enregistrement référencé clé étrangère.
Exemple :
SQL> delete from fournisseur
where f='F7';
→ erreur, il faut au préalable supprimer les
enregistrements de F7 dans la table
MAFOURNITURE.
Contraintes des Contraintes
●
●
●
Dans certains cas il faut lever les contraintes et les
réactiver par la suite.
Lors d'un import ou de chargement SQL*Loader il
est possible que les contraintes ne permettent pas
l'intégration.
La désactivation des contraintes doit se faire table
par table et contrainte par contrainte.
●
SQL> alter table <table> disable <contrainte>;
●
La réactivation suit la même logique
●
SQL> alter table <table> enable <contrainte>;
Lever et activer toutes les
contraintes
●
●
●
●
C'est la méthode la plus souvent utilisée.
Le DBA lève ( disable ) toutes les contraintes,
charge les données et réactive ( enable ) cellesci.
Le dictionnaire des données et une boucle
PL/SQL permettent facilement de mettre au point
des scripts pour effectuer ces tâches.
Les deux scripts présentés ici active/désactive
les contraintes pour un schéma et non sur la
base complète.
Script pour lever les contraintes
●
A exécuter sous la connexion de l'utilisateur.
BEGIN
FOR c IN
(SELECT c.owner, c.table_name, c.constraint_name
FROM user_constraints c, user_tables t
WHERE c.table_name = t.table_name
AND c.status = 'ENABLED'
ORDER BY c.constraint_type DESC)
LOOP
dbms_utility.exec_ddl_statement('alter table ' || c.owner || '.' || c.table_name
|| ' disable constraint ' || c.constraint_name);
END LOOP;
END;
Script pour réactiver les contraintes
●
A exécuter sous la connexion de l'utilisateur.
BEGIN
FOR c IN
(SELECT c.owner, c.table_name, c.constraint_name
FROM user_constraints c, user_tables t
WHERE c.table_name = t.table_name
AND c.status = 'DISABLED'
ORDER BY c.constraint_type)
LOOP
dbms_utility.exec_ddl_statement('alter table ' || c.owner || '.' || c.table_name
|| ' enable constraint ' || c.constraint_name);
END LOOP;
END;
Statistiques Optimiseur
●
●
●
●
●
Oracle utilise des statistiques pour déterminer le plan d'exécution optimal
d'une requête.
Les statistiques doivent être recalculées régulièrement si la base à de
nombreuses mises à jour sur ses colonne indexées
●
Ajout de lignes,
●
Suppression de lignes
Les updates sur des champs non indéxés ne demandent pas de recalculer
les statistiques.
Les statistiques peuvent être calculées sur
●
une table ou un index
●
un schema
●
toute la base
Les statistiques peuvent aussi se faire sur l'ensemble des données ou sur
un echantillon.
Statistiques et 11g
●
●
●
●
Par défaut un job est lancé chaque nuit ( 22h00 ) par oracle
pour recalculer les statistiques.
C'est Oracle qui décide si une statistique doit ou non être
recalculée.
Il est possible de forcer ce calcul, par l'utilisation du package
dbms_stats.
Il faut recalculer les statistiques dans les cas suivants :
●
Import de données ( imp, datapump ou SQL*Loader )
●
alter table...move
●
Création de nouveaux index...
●
Beaucoup de structures recalculent systématiquement chaque jour
les statistiques.
Visualisation des jobs par défaut
set linesize 200
col PROGRAM_NAME format a35
col PROGRAM_ACTION format a60
select a.JOB_NAME,
a.PROGRAM_NAME,
b.PROGRAM_TYPE,
b.PROGRAM_ACTION,
b.NUMBER_OF_ARGUMENTS
from DBA_SCHEDULER_JOBS a,
DBA_SCHEDULER_PROGRAMS b
where a.PROGRAM_NAME = b.PROGRAM_NAME;
Le package DBMS_STATS
●
Calculer les statistiques sur le schéma alice
●
●
Calculer les statistiques sur le schéma alice avec un echantillon de 25%
●
●
●
SQL> exec dbms_stats.delete_schema_stats('ALICE');
Pour connaître la date du dernier calcul de statistiques sur une table :
●
●
SQL> exec dbms_stats.gather_database_stats;
Supprimer les statistiques du schéma alice
●
●
SQL> exec dbms_stats.gather_table_stats('ALICE','PERSONNE',null,30);
Calculer les statistiques sur toute la base
●
●
SQL> exec dbms_stats.gather_table_stats('ALICE','PERSONNE');
Calculer les statistiques sur la table personne de alice avec un échantillon de 30%
●
●
SQL> exec dbms_stats.gather_schema_stats('ALICE',25);
Calculer les statistiques sur la table personne de alice
●
●
SQL> exec dbms_stats.gather_schema_stats('ALICE');
SQL> select table_name, last_analyzed from dba_tables;
Il est possible d'exporter les statistiques vers une autre base afin de simuler du volume.
Le package et les fonctions de dbms_stats contiennent de nombreuses options, voir la
documentation Oracle.
Sauvegarde et
restauration
"Sauvegarder à rien ne sert,
si restaurer ne peut se faire."
Modes de sauvegarde
●
●
●
●
●
Il existe de nombreuses manières de sauvegarder une
base Oracle.
La sauvegarde peut être :
●
Cohérente → sauvegarde à froid
●
Incohérente → sauvegarde à chaud
Une sauvegarde cohérente, implique un arrêt de base.
Une sauvegarde incohérente implique un
fonctionnement en archivelog.
Le sujet est vaste, ORSYS propose un cours sur 3 ou
5 jours uniquement sur ce thème.
Recovery MANager
●
●
●
●
RMAN est l'outil fournit avec Oracle pour la sauvegarde et la restauration
des bases de données.
Livré en standard depuis la version 8i, RMAN permet :
●
sauvegarde complète ou incrémentale
●
sauvegarde partielle
●
restauration globale ou partielle
●
clonage de base
●
corriger les blocs corrompus...
RMAN est un produit très complet. L'ensemble des fonctions fait l'objet
d'un cours spécial.
Note sur import/export. Très utilisé comme mode de sauvegarde car
simple, cet outil n'a jamais été conçu comme solution de sauvegarde et
encore moins de restauration.
Architecture RMAN
●
La base à sauvegarder est appelée cible → target. La connexion à une
base cible utilise la couche Oracle*Net
●
L'ensemble d'une sauvegarde est nommé backupset
●
Un backupset contient des backuppieces
●
●
●
●
Il est possible d'avoir des backuppieces d'une taille données → option
maxpiecesize.
Les informations sur la sauvegarde peuvent être stockées sous deux
formes :
●
dans le fichier de contrôle de la base,
●
dans un catalogue.
L'utilisation d'un catalogue permet de centraliser la sauvegarde de
bases multiples.
RMAN permet également de sauvegarder les fichiers tels que →
backup as copy.
Principe de communication
RMAN
Canaux de
communication
Base
cible
●
●
Processus
Oracle
référentiel
de sauvegarde
base catalogue
ou fichier de
contrôle de la base
cible
Média
de stockage
Le média de stockage peut être du disque ou une
bande.
Il est possible de paralléliser la communication en
allouant plusieurs canaux → allocate channel.
Le client RMAN
●
Utilitaire en ligne de commande.
●
Appel depuis l'OS :
●
●
●
●
●
rman target /
●
RMAN>
La connexion à la base cible ( target ) s'effectue implicitement en
sysdba.
Connexion à une base distante
●
rman target sys/manager11@red
●
RMAN>
Appelé sous cette forme RMAN utilise le fichier de contrôle de la base de
données comme référentiel des sauvegardes.
Autres appels de RMAN
●
●
●
●
La syntaxe du slide précédent est la plus simple.
Il est possible de se connecter également à une
base auxiliaire → auxiliary et/ou à une base
catalogue → catalog.
Ces deux autres types d'appels seront vus lors du
clonage pour auxiliary et via un catalogue pour
catalog.
Il est également possible d'utiliser RMAN depuis
l'interface Web du Database Control.
RMAN et la mémoire
●
●
●
●
●
●
RMAN utilise la large pool de la SGA.
En cas de gestion automatique de la SGA celle-ci s'adapte
en fonction du besoin.
La gestion manuelle demande plus de soin.
Il est possible d'avoir une grosse activité de swap durant
un processus RMAN
Le lien suivant permet de mettre en place des outils pour
optimiser les process RMAN
http://docs.oracle.com/cd/B28359_01/backup.111/b28270/
rcmtunin.htm
Sauvegardes RMAN
●
RMAN permet de sauvegarder :
●
●
●
A froid → Base stoppée. On parle de sauvegarde
cohérente.
A chaud → base ouverte. On parle alors de
sauvegarde incohérente.
La sauvegarde à chaud implique un
fonctionnement en mode archivelog. Sans
cela RMAN génère une erreur et refuse
d'effectuer la sauvegarde.
Sauvegarde avec RMAN Prérequis
●
Pour utiliser RMAN simplement, il faut définir une zone de récupération
rapide → flash recovery area. Mais cela n'est pas obligatoire.
●
La flash recovery area permet de simplifier les sauvegardes/restauration.
●
Au niveau système créer le répertoire suivant :
●
mkdir -p /u01/app/oracle/flash_recovery_area
●
Se connecter à RED en sysdba
●
●
●
●
SQL> alter system set db_recovery_file_dest_size=2G scope=both ;
SQL> alter system set
db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
scope=both ;
SQL> exit ;
Sauvegarde RMAN à froid
●
Une sauvegarde à froid avec RMAN demande une base en statut « mount »
●
Lancer RMAN
●
●
rman target / → La connexion est implicitement en sysdba
●
RMAN> configure controlfile autobackup on ; → à faire une fois.
●
RMAN> shutdown immediate;
●
RMAN> startup mount;
●
RMAN> backup database;
●
RMAN> alter database open;
●
RMAN> exit ;
●
Les fichiers de sauvegarde sont sous
/u01/app/oracle/flash_recovery_area/RED/backupset/<date> et
/u01/app/oracle/flash_recovery_area/RED/autobackup/<date>
Script shell de sauvegarde
●
●
Créer sous $HOME un fichier nommé svfroid.rma avec
les lignes suivantes :
run {
shutdown immediate;
startup mount;
backup database;
delete noprompt obsolete;
alter database open;
Seule la dernière sauvegarde
est conservée.
}
●
●
Lancement en ligne de commande
●
●
rman target / @$HOME/svfroid.rma
Lancement depuis un cron, éditer /etc/crontab et rajouter :
●
00 23 * * * oracle . ~/.bash_profile ; export ORACLE_SID=RED ; rman target /
@$HOME/svfroid.rma > $HOME/svfroid.rma.log
Sauvegarde avec compression
●
La syntaxe de connexion est identique, seule la
commande de sauvegarde de la base change
●
●
RMAN> backup as compressed backupset
database ;
La compression prend du temps CPU mais
divise la taille des sauvegarde d'un facteur
voisin de 5.
Restauration
●
Se connecter en sysdba à RED et arréter la base.
●
Sous /u01/app/oracle/oradata/RED supprimer tous les fichiers
●
Tenter de démarrer la base → erreur, elle reste en mode nomount
●
Lancer RMAN
●
●
rman target /
●
RMAN> shutdown abort ;
●
RMAN> startup nomount ;
●
RMAN> restore controlfile from autobackup ;
●
RMAN> alter database mount ;
●
RMAN> restore database ;
●
RMAN> recover database ;
●
RMAN> alter database open resetlogs ;
●
RMAN> exit ;
●
La commande restore restaure tous les fichiers manquants.
●
La commande recover rejoue les redologs.
Recovery Data Advisor
●
Détecte la corruption ou la perte de données.
●
●
Détermine les actions à effectuer.
●
●
list failure
advise failure
Propose l'exécution des actions suggérées.
●
repair failure preview → Montre l'effet de l'action
●
repair failure → lance l'action après confirmation
●
repair failure noprompt → lance l'action directement.
Principe de l'archivelog
●
●
●
●
●
●
Les transactions sont enregistrées dans les redologs.
Le principe de l'écriture cyclique des redologs fait que l'information
est périodiquement écrasée.
Pour éviter ceci, il est possible de configurer la base en mode
archivelog.
Une copie du redolog est effectuée dès que celui-ci est rempli au
moment du passage vers un autre groupe.
Utiliser le mode archive-logs et une gestion multiplexée des
redologs permet en cas de crash de ne perdre aucune transaction.
Inconvénient du mode archivelog est la génération d'un volume
important sur les disques.
Processus d'archivage
6 : basculement
1 : Les transactions
remplissent redo01
redo01
2 : redo01 est plein,
redo01 est copié
→ archivelog
redo02
4 : Les transactions
remplissent redo02
3 : basculement
5 : redo02 est plein,
redo02 est copié
→ archivelog
arch01
arch02
Mode archivelog
●
Permet de sauvegarder une base à chaud
●
Permet de rejouer toutes ou une partie des transaction à partir d'une sauvegarde.
●
Les archivelogs sont par défaut stockés dans la flash_recovery_area
●
Passer la base en archivelog
●
●
●
●
●
●
SQL> startup mount ;
●
SQL> alter database archivelog;
●
SQL> alter database open ;
●
SQL> select log_mode from v$database ;
●
SQL> alter system archive log current ;
Les fichiers d'archives sont sous
/u01/app/oracle/flash_recovery_area/RED/archivelog/<date>
En cas de faible activité transactionnelle il est possible de forcer un archivage tous les x
secondes via le paramètre ARCHIVE_LAG_TARGET.
Exemple :
●
SQL> alter system set archive_lag_target=900 scope=both; → Un archivelog est forcé toutes les
15 minutes, toutefois si l'activité de transaction est nulle rien n'est archivé.
Sauvegarde à chaud RMAN
●
●
Une sauvegarde à chaud avec RMAN ne demande pas
un arrêt de base.
Afin d'optimiser le processus de sauvegarde il est possible de
demander la sauvegarde automatique du spfile et du
controlfile.
●
●
RMAN> backup database plus archivelog delete all input;
●
RMAN> exit;
●
●
Cette simple ligne sauvegarde l'ensemble de la base, les
archivelog et les efface après sauvegarde.
Les fichiers de sauvegarde sont sous
/u01/app/oracle/flash_recovery_area/RED/backupset/<date> et
/u01/app/oracle/flash_recovery_area/RED/autobackup/<date>
Visualiser les sauvegardes
●
●
●
●
RMAN> list backup ;
●
RMAN> list backup summary ;
Supprimer les sauvegardes obsolètes
●
RMAN> report obsolete ;
●
RMAN> delete obsolete ;
Supprimer toutes les sauvegardes
●
●
RMAN> delete backup ;
Ces deux dernières commandes demande une
confirmation.
Restauration avant crash
●
●
●
Dans cet exemple nous allons faire des modifications
dans la base qui ne sont pas dans la sauvegarde.
Se connecter alice : sqlplus alice/ecila@red
●
SQL> insert into personne values ('06','Flugence' );
●
SQL> insert into personne values ('07','Gudulle');
●
SQL> commit ;
Arrêter la base pour simuler le crash
●
SQL> connect sys/manager11@red as sysdba
●
SQL> shutdown immediate ;
●
SQL> exit ;
Principe de restauration
18/04
20/04
19/04
redologs
100-200
redologs
201-275
21/04
redologs
275-322
Phase restore
Sauvegarde
Base
Crash
Base
Archivelogs
100-322
21/04
21/04
Réapplication
redologs
100-200
Restauration
Base
Réapplication
redologs
201-275
Phase recover
Réapplication
redologs
275-322
Reconstitution
Base
Si le redolog courant
est perdu, une partie
des transactions sera
perdue.
La phase recover
signalera un échec.
redolog
courant
Simulation du crash et restauration
●
●
●
●
Supprimer tous les fichiers sous /u01/app/oracle/oradata/RED
La perte est de certains fichiers de contrôle, des redologs et des
datafiles.
●
RMAN> startup nomount ;
●
RMAN> restore controlfile from autobackup;
●
RMAN> alter database mount;
●
RMAN> restore database;
●
RMAN> recover database;
●
RMAN> alter database open resetlogs;
●
RMAN> exit ;
Se reconnecter à la base en alice et vérifier la présence des deux
dernières lignes insérées.
Incrémental vs Cumulative
●
●
●
●
Une incrémentale de niveau 0 correspond à une sauvegarde
complète
Une sauvegarde complète n'est pas une incrémentale de niveau 0
Les incrémentales de niveau 1 sont plus rapides que les
cumulatives niveau 1 en sauvegarde
Les cumulatives niveau 1 sont plus rapides que les
incrémentales niveau 1 en restauration.
0
1
1
1
Incrémental
0
0
1
1
1
Cumulative
0
Sauvegardes incrémentielles
●
Niveau 0
●
●
Niveau 1
●
●
●
●
RMAN> backup incremental level=0 database ;
RMAN> backup incremental level=1 database ;
Si un niveau 1 est demandé sans la présence d'un niveau 0,
un niveau 0 est automatiquement exécuté.
Par défaut les sauvegardes incrémentielles de niveau 1 sont
en mode différentiel.
L'option cumulative permet de passer en mode cumulatif.
●
RMAN> backup incremental level=1 cumulative database ;
Block Change Tracking
●
●
●
Permet de tenir à jour la liste des blocs Oracle
modifiés accélérant ainsi la sauvegarde
incrémentielle.
SQL> alter database enable block change
tracking using file
'/u01/app/oracle/oradata/RED/block_change_tr
acking.trc';
SQL> select * from v$block_change_tracking;
Paramétrage RMAN
●
●
La configuration de RMAN se visualise par la
commande show all.
Il est possible de modifier la configuration par
défaut via la commande configure.
●
RMAN> configure controlfile autobackup on ;
●
Par défaut la durée de rétention est de 1.
●
Il est possible de définir un nombre différent ainsi :
●
RMAN> configure retention policy to redundancy 3 ;
●
●
Il est possible de définir une fenètre de retention en
jours, par exemple 7 jours
RMAN> configure retention policy to recovery
window of 7 days ;
Obsolescence des sauvegardes
●
●
●
RMAN gère les sauvegardes obsolètes en
fonction de la politique de rétention.
La commande report obsolete permet de
connaître celles-ci.
La commande delete obsolete permet leur
suppression.
Bloc corrompu
●
●
Erreur ORA-01578
SQL> select segment_name , header_file, header_block from
dba_segments where segment_name = 'PERSONNE' and
owner='ALICE' ;
●
→ 6 14
●
cd /u01/app/oracle/oradata/RED
●
dd of=data_alice_01.dbf bs=8192 conv=notrunc seek=14 <<
EOF
●
> corrupt !
●
> EOF
Test de la corruption
●
sqlplus "/ as sysdba"
●
SQL> alter system flush buffer_cache ;
●
SQL> connect alice/ecila
●
SQL> select * from personne
●
→ ORA-01578
Restauration
●
rman target /
●
RMAN> blockrecover datafile 6 block 14 ;
●
RMAN> exit
●
●
SQL> select * from personne ;
Nouvelle sauvegarde
●
●
●
Pour la suite du cours, il importe de refaire une
nouvelle sauvegarde de la base de données
RMAN> backup database plus archivelog
delete all input;
●
RMAN> delete obsolete;
●
RMAN> exit;
Flashback
●
Oracle offre la possibilité de remonter le temps pour ses données.
●
La notion de flashback existe depuis la version 9i.
●
En 11gR2 il existe 8 fonctionnalités de flashback.
●
●
Flashback Query
●
Flashback Versions Query
●
Flashback Transaction Query
●
Flashback Table
●
Flashback Drop
●
Flashback Data Archive
●
Flashback Transaction Backout
●
Flashback Database
Les différentes possibilités de flashback sont liées à la licence souscrite
( Standard ou Enterprise ).
Flashback et les données
●
Les différents Flashback n’utilisent pas les mêmes fichiers Oracle pour
récupérer les données.
●
Flashback Database utilise des journaux Flashback
●
Flashback Drop utilise une corbeille.
●
Flashback Data Archive utilise la notion d’archive Flashback.
●
●
●
●
Flashback Table, Flashback Version Query, Flashback Query, Flashback Transaction
Query utilisent le tablespace undo.
Flashback Transaction Backout utilise le tablespace undo et les archivelogs.
Certaines fonctions de flashback ne modifient pas la base → lecture seule.
La base doit être configurée avec certaines options afin de pouvoir utiliser
certaines fonctions
●
Mode Archivelog
●
Mode Flashback
Paramétrage du tablespace
UNDO
●
●
●
●
Le tablespace UNDO est largement utilisé dans le
Flashback.
Sa dimension et surtout sa durée de rétention
doivent être précisées avec soin.
Si la notion de Flashback est un impératif, il faut
de plus gérer la garantie de rétention.
Garantir la rétention peut interdire l'insertion ou la
mise à jour de données de manière temporaire →
Erreur ORA-30036.
Rappels gestion de
l'annulation
●
Manuelle, déconseillée →gestion via rollback segments
●
Automatique, par défaut →utilise un tablespace UNDO.
●
●
UNDO_MANAGEMENT=AUTO
●
UNDO_TABLESPACE = UNDO_TBS
●
●
Modifier la durée de rétention à 30 minutes
●
●
alter system set undo_retention=1800 scope=both ;
Garantir la durée de rétention
●
●
UNDO_RETENTION=900 → Valeur par défaut, 15 minutes ( 900 secondes ) non
garantie.
alter tablespace undo_tbs retention guarantee ;
Retirer la garantie de rétention
●
alter tablespace undo_tbs retention noguarantee ;
Flashback query
●
Permet de lire les données telles qu'elles étaient dans le passé.
●
Se connecter scott/tiger@red
●
SQL> update emp set sal=sal*4 ;
●
SQL> commit ;
●
SQL> select ename,sal from emp;
●
●
●
Relire les valeurs de sal avant l'augmentation, remonte ici de 2
minutes dans le passé.
SQL> select ename, sal from emp as of timestamp ( sysdate ( 2/1440 ));
sysdate demande un nombre de jours en plus ou en moins, pour
remonter de 2 minutes on divise 2 par le nombre de minutes dans
un jour → 1440
Flashback table
●
Ramène une table à ses valeurs passées.
●
SQL> delete from emp ;
●
SQL> commit ;
●
SQL> select * from emp ;
●
Table vide.
●
SQL> alter table emp enable row movement ;
●
●
SQL> flashback table emp to timestamp ( sysdate ( 5/1440 )) ;
Les lignes sont revenues.
Flashback drop
●
Supprimer la table emp de scott
●
●
La table est en fait stockée dans la corbeille
●
●
●
●
SQL> drop table emp;
SQL> show recyclebin;
L'ordre suivant permet de sortir la table de la corbeille et de la
restaurer
●
SQL> flashback table emp to before drop;
●
SQL> select count(*) from emp;
Attention si la table est dans le tablespace SYSTEM cette
fonction ne marche pas.
La tablespace SYSTEM n'a pas de corbeille, une raison de plus
pour ne pas mettre d'objet dans le tablespace SYSTEM.
Flashback base de données
●
Il s'agit ici de ramener l'intégralité d'une base de données
dans le passé.
●
Cette fonction n'est disponible qu'en version Enterprise.
●
La base doit fonctionner en mode archivelog
●
Il faut activer le mode flashback
●
●
●
SQL> startup mount;
●
SQL> alter database flashback on;
●
●
SQL> select log_mode, flashback_on from v$database;
Exemple de flashback base de
données
●
Toujours connecté sys as sysdba.
●
Relever le numero SCN
●
●
SQL> select dbms_flashback.get_system_change_number() from dual;
●
→ 4017852.
Supprimer la table emp de scott
●
●
●
SQL> drop table scott.emp;
Rajouter une ligne dans la table personne de alice
●
SQL> insert into alice.personne values ( '06','Francis' );
●
SQL> commit;
Stopper la base et demander le flashback
●
●
SQL> startup mount;
●
SQL> flashback database to scn 4017852;
●
SQL> alter database open resetlogs;
●
Vérifier le retour de la table scott.emp et que la valeur dans la table personne de alice est bien
absente.
Flashback avec RMAN
●
Il est possible d'utiliser RMAN pour le flashback
●
La base doit être en archivelog
●
●
●
●
L'exemple demande de remettre la base de données dans son état au
18/04/2013 à 15H00 pile !
rman target sys/manager11@red as sysdba
●
RMAN> run {
●
RMAN> shutdown immediate
●
RMAN> startup mount;
●
RMAN> set until time "to_date('18/04/2013 15:00:00' , 'dd/mm/yyyy hh24:mi:ss')";
●
●
●
●
RMAN> }
Il est impératif d'utiliser un bloc run quand une commande set until time est
introduite.
La commande set until time permet de dire à RMAN jusqu'à quand rejouer les
archivelogs à partir de la dernière sauvegarde.
Clonage avec RMAN
●
●
●
●
Cloner une base est très pratique pour obtenir un
environnement de test reflétant une production. RMAN permet
cette action à partir d'une sauvegarde.
Objectif : créer une base BLACK depuis la sauvegarde RMAN
de la base RED
Créer l'aborescence
●
mkdir -p /u01/app/oracle/admin/BLACK/pfile
●
mkdir -p /u01/app/oracle/oradata/BLACK
●
●
●
Procéder à une sauvegarde complète de la base RED.
Créer le fichier initBLACK.ora
●
Depuis le spfile de RED, créer le pfile
●
●
sqlplus /nolog
●
●
●
SQL> create pfile=
'/u01/app/oracle/admin/BLACK/pfile/initBLACK.ora' from spfile;
Editer ce fichier et remplacer toute occurrence de RED par BLACK.
●
Avec vi passer en mode commande et taper :
:1,$s/RED/BLACK/g
En fin de fichier rajouter les lignes suivantes :
–
●
●
DB_FILE_NAME_CONVERT=('RED','BLACK')
●
LOG_FILE_NAME_CONVERT=('RED','BLACK')
●
INSTANCE_NAME='BLACK'
L'instance BLACK
●
●
●
Créer le fichier de mot de passe pour BLACK
●
cd $ORACLE_HOME/dbs
●
orapwd file=orapwBLACK password=manager11
Créer le lien symbolique vers le pfile
●
cd $ORACLE_HOME/dbs
●
ln -s /u01/app/oracle/admin/BLACK/pfile/initBLACK.ora initBLACK.ora
Sous windows créer le service pour BLACK
●
oradim -new -sid BLACK -intpwd manager11 -startmode auto -startype SRVC,INST
●
Démarrer BLACK
●
export ORACLE_SID=BLACK
●
sqlplus /nolog
●
●
●
SQL> quit
Création du clone
●
●
rman target sys/manager11@RED auxiliary /
●
●
●
RMAN> duplicate target database to black;
Renseigner la base BLACK dans le tnsnames.ora et le listener.
Renseigner BLACK pour le démarrage automatique dans
/etc/oratab
Clonage en 11g
●
La version 11g apporte une améliora tion en permettant le clonage sans
sauvegarde.
●
Ici création de BLACK depuis RED directement.
●
La base BLACK doit être statiquement enregistrée dans le listener.
●
sqlplus sys/manager11@black as sysdba
●
SQL> shutdown immediate ;
●
SQL> exit ;
●
rman target sys/manager11@red auxiliary sys/manager11@black
●
RMAN>startup clone nomount ;
●
RMAN> duplicate target database to black from active database ;
●
RMAN> exit ;
Exemple listener.ora
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = lx-1-3 )(PORT = 1521)
)
)
)
SID_LIST_LISTENER =
( SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = RED)
(SID_NAME = RED)
)
(SID_DESC =
(GLOBAL_DBNAME = BLACK)
(SID_NAME = BLACK)
)
)
Exemple tnsnames.ora
RED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = lx-1-3)(PORT = 1521))
)
(CONNECT_DATA =
)
)
BLACK =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = lx-1-3 )(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = BLACK)
)
)
RMAN avec catalogue
●
●
●
Il est possible d'enregistrer les informations de
sauvegarde dans un catalogue.
Ainsi RMAN peut sauvegarder de multiples
bases et avoir un point central pour la gestion
des sauvegardes.
Un catalogue est stocké dans une base de
données Oracle ordinaire.
Principe du catalogue
RMAN
Base à
Sauvegarder
( cible )
Oracle
Server
Session
Espace de
Sauvegarde
(FLAR)
Base
catalogue
Création du catalogue
●
●
Dans cet exemple nous allons utiliser la base BLACK pour gérer le
catalogue
Dans cette instance, créer un tablespace et un utilisateur pour RMAN
●
●
sqlplus system/manager11@black
SQL> create tablespace rman_data datafile
'/u01/app/oracle/oradata/BLACK/rman_data_01.dbf' size 200M;
●
SQL> create user rman identified by rman default tablespace rman_data;
●
SQL> grant connect, resource, recovery_catalog_owner to rman;
●
SQL> exit
●
Se connecter à rman et créer le catalogue.
●
rman catalog rman/rman@black
●
●
RMAN> create catalog;
●
RMAN> exit
Ces étapes sont à faire une fois.
Enregistrement des bases à
sauvegarder
●
●
●
●
Il faut enregistrer les bases de données que l'on souhaite
sauvegarder, les cibles ou target. Par exemple ici la base RED
rman catalog rman/rman@black target sys/manager11@red
●
RMAN> register database;
●
RMAN> resync catalog ;
●
RMAN> exit
La seconde commande permet de synchroniser le catalogue
avec le fichier de contrôle.
Retirer une base du catalogue
●
rman catalog rman/rman@black target sys/manager11@red
●
RMAN> unregister database red;
●
RMAN> exit
RMAN et le DBID
●
●
●
Lors de la connexion à la base cible ( target ) RMAN donne le
DBID de la base.
Le DBID ( Database Identifier ) est important si des bases ayant le
même nom ( SID ) sont dans le catalogue RMAN.
Lors de la restauration il sera nécessaire de donner ce DBID afin
de lever l'ambiguïté sur quelle base restaurer.
●
Le DBID peut se trouver par la requête suivante :
●
SQL> select dbid from v$database ;
●
Ou encore en interrogeant la table RC_DATABASE du catalogue
RMAN.
●
Sous RMAN on positionne le DBID ainsi :
●
RMAN> set DBID 2265554275;
Changer le DBID
1/2
●
Il peut arriver, notamment par clonage ou par récupération d'une
autre sauvegarde que le DBID de deux bases soit identique.
●
Le modifier est simple en utilisant la commande nid.
●
●
sqlplus /nolog
●
●
SQL> select dbid from v$database; → Noter le dbid
●
●
SQL> startup mount;
●
SQL> exit;
●
nid target=sys/manager11
●
Répondre YES à la question
Changer le DBID
2/2
●
●
Redemarrer la base en mode mount et l'ouvrir
avec l'option resetlogs.
sqlplus /nolog
●
●
SQL> startup mount;
●
SQL> alter database open resetlogs;
●
●
SQL> select dbid from v$database; → Nouveau
dbid
SQL> exit;
Sauvegarde
●
rman catalog rman/rman@black target
sys/manager11@red
●
●
●
RMAN> backup full database plus archivelog delete
all input;
RMAN> exit
Les sauvegardes sont générées dans la flash
recovery area par défaut.
Restauration
●
●
Les principes de restauration sont les mêmes
qu'avec une gestion autonome.
rman catalog rman/rman@black target
sys/manager11@red
●
RMAN> startup mount ;
●
●
●
●
RMAN> exit;
Utilitaires ORACLE
Les utilitaires
●
exp et imp
●
Datapump
●
SQL*Loader
●
Explain plan
●
TKPROF
Export avec exp
●
●
●
Bien que déprécié, exp est toujours très utilisé.
On parle souvent de "créer un dump" de la base de
donnée.
Appelé en ligne de commande, exp passe en mode
interactif et demande des réponses.
●
●
exp system/manager11@red
Il est possible de passer les arguments sur la ligne
commande.
●
exp userid=system/manager11@red file=$HOME/alice.dmp
log=$HOME/alice.exp.log owner=alice
Exp et fichier de paramètres
●
●
Il s'agit de la méthode la plus pratique. Le fichier contient l'ensemble
des options de la commande exp.
Les options ont toutes une valeur par défaut, il ne faut donc spécifier ici
que celles ayant une valeur différente.
●
Editer un fichier texte
●
vi $HOME/alice.param.exp
userid=system/manager11@red
buffer=1000000
file=$HOME/alice.dmp
log=$HOME/alice.exp.log
owner=alice
●
Lancer l'export
●
exp parfile=$HOME/alice.param.exp
Import avec imp
●
●
Il s'agit du complément à la commande exp, elle permet d'importer
le contenu d'un fichier export.
La commande imp s'utilise de la même façon que exp. Les options sont plus
nombreuses.
●
Il est possible d'importer les données d'un schéma dans un autre ( alice → scott )
●
Editer un fichier de paramètres
●
vi $HOME/scott.param.imp
buffer=1000000
file=$HOME/alice.dmp
log=$HOME/scott.imp.log
fromuser=alice
touser=scott
●
Lancer l'import
●
●
imp parfile=$HOME/scott.param.imp
Tester en se connectant scott la présence de la table personne.
Data Pump
●
Remplace exp/imp depuis la 10g. Datapump est incompatible
avec exp/imp.
●
Un fichier exporté avec exp doit être importé avec imp et réciproquement.
●
Trois éléments
●
●
●
●
Package dbms_datapump
●
Package dbms_metadata
●
Clients expdp et impdp
Modes export et import
●
Complet
●
Schéma
●
Table
●
Tablespace
Privilèges de l'utilisateur
●
exp_full_database
●
imp_full_database
Demande un objet Oracle DIRECTORY
Mise en place Data Pump
●
Créer un répertoire pour Data Pump
●
●
Créer un utilisateur dédié
●
●
●
SQL> create user dp identified by dp ;
SQL> grant connect,resource, imp_full_database,exp_full_database to dp ;
Créer l'objet DIRECTORY
●
●
mkdir /u01/app/oracle/oradata/RED/dpump
SQL> create directory dpump as '/u01/app/oracle/oradata/RED/dpump' ;
Droit lecture et écriture sur l'objet DIRECTORY à l'utilisateur
dédié
●
SQL> grant read, write on directory dpump to dp ;
Remise en etat des données
SCOTT
●
●
Pour la suite des manipulations en raison des
modifications faites sur les tables de SCOTT,
récréer celles-ci en relançant le script
createscott.sql
Si perdu, le charger ainsi :
●
●
wget http://192.168.4.224/createscott.sql
Lancement
●
sqlplus system/manager11@red @createscott.sql
Export Data Pump
●
Créer un fichier de paramètres
●
●
●
directory=dpump
dumpfile=scott.dpump
logfile=scott.dpexp.log
schemas=scott
Lancement de l'export
●
●
vi $HOME/scott.dpexp
expdp dp/dp@red parfile=$HOME/scott.dpexp
Résultats visibles sous
/u01/app/oracle/oradata/RED/dpump
Import Data Pump
●
Supprimer le user scott
●
●
SQL> drop user scott cascade ;
●
SQL> exit;
●
●
●
●
directory=dpump
logfile=scott.dpimp.log
schemas=scott
Lancement de l'import
●
●
vi $HOME/scott.dpimp
impdp dp/dp@red parfile=$HOME/scott.dpimp
Voir le log sous /u01/app/oracle/oradata/RED/dpump
Import Data Pump avec transfert de schéma et filtre
●
Créer un utilisateur blake
●
●
●
●
SQL> create tablespace data_blake datafile '/u01/app/oracle/oradata/RED/data_blake_01.
dbf' size 5M ;
SQL> create temporary tablespace temp_blake tempfile '/u01/app/oracle/oradata/RED/temp_blake_01.
dbf' size 2M ;
SQL> create user blake default tablespace data_blake temporary tablespace temp_blake identified by mortimer ;
SQL> grant connect,resource to blake ;
●
vi $HOME/blake.dpimp
directory=dpump
logfile=blake.dpimp.log
table_exists_action=replace
schemas=scott
query=scott.emp:"where SAL < 1500"
exclude=table:"in('BONUS','SALGRADE')"
remap_schema=scott:blake
●
●
Les noms de colonnes et de tables doivent être en majuscules sinon les clauses
exclude et query ne fonctionnent pas ( bug ? )
●
impdp dp/dp@red parfile=$HOME/blake.dpimp
●
Voir le log sous /u01/app/oracle/oradata/RED/dpump
●
Se connecter blake/mortimer et vérifier la présence des tables et des données.
Principe du database link
●
●
Permet d'accéder à un objet ( table, vue,...)
situé dans une autre base de données que celle
où on est connecté.
Dans cet exemple un utilisateur connecté sur BLACK
souhaite accéder à la table personne de alice située sur RED.
le database link lien utilise
la chaine Oracle*Net RED
PERSONNE
RED
lien
BLACK
select * from personne@lien ;
Database Link
●
Base RED sur serveur lx-4-20
●
●
SQL> create public database link lien1 connect to dp identified by dp
using 'RED_LX-4-21';
Base RED sur serveur lx-4-21
●
SQL> create public database link lien1 connect to dp identified by dp
using 'RED_LX-4-20';
Serveur LX-4-20
Serveur LX-4-21
RED
RED
tnsname.ora :
RED
RED_LX-4-21
tnsname.ora :
RED
RED_LX-4-20
Import Data Pump par DBLink
●
Permet d'éviter le fichier export intermédiaire
●
Utilise le réseau et la couche Oracle*NET
●
Détruire les tables du user blake.
●
●
●
●
vi $HOME/scott_blake.dpimp
directory=dpump
network_link=lien1
logfile=scott_blake.dpimp.log
schemas=scott
exclude=table:"in('BONUS','SALGRADE')"
remap_schema=scott:blake
●
impdp dp/dp@RED parfile=$HOME/scott_blake.dpimp
Imp/Exp - Datapump
●
●
●
●
●
Il faut noter que l'export soit par exp soit par
datapump est toujours plus rapide que l'action
d'import.
Les index ne sont jamais exportés, seules leurs
définition l'est.
Lors de l'import les index sont donc recréés.
En pratique on observe qu'un export durant
1heure, demande 3 heures d'import.
Les statistiques doivent toujours être recalculées
après un import.
SQL*Loader
●
Intégration de données depuis un fichier plat
Fichier de
données
Fichier
contrôle
Fichier
bad
Fichier
Log
SQL*Loader
Fichier
discard
Base de
données
Fonctionnement de SQL*Loader
●
●
●
●
●
●
En entrée, SQL*Loader prend un fichier de contrôle qui pilote le chargement, et un ou
plusieurs fichiers de données ASCII.
En sortie, SQL*Loader alimente la base de données Oracle et génère un fichier journal
(log), un fichier des rejets (bad - données erronées) et un fichier des refus (discard données écartées).
Pour des petits volumes, les données peuvent être directement incluses dans le fichier
de contrôle.
Le fichier discard contient des enregistrements qui ont été refusés (écartés) par
SQL*Loader car ils ne respectaient pas des conditions spécifiées dans le fichier de
contrôle.
Le fichier bad contient des enregistrements qui ont été rejetés soit par SQL*Loader
(format de l’enregistrement non valide par rapport à la description du fichier de contrôle),
soit par Oracle (violation d’une contrainte d’intégrité, type de données non valide, etc.).
Les enregistrements rejetés ou refusés sont écrits tels quels dans les fichiers bad et
discard qui ont donc, la même structure que les fichiers de données utilisés en entrée ;
après correction éventuelle des enregistrements, les fichiers bad et discard peuvent être
utilisés comme fichiers d’entrée.
Table d'interface
●
Récupérer le fichier csv via le lien suivant
●
●
wget http://192.168.4.224/ORA/agent.csv
Créer une table recevant les données en se connectant
alice/ecila@red
●
SQL> create table agent ( code varchar2(15), matr varchar2(15), titre varchar2(15), nom varchar2(50), adr1 varchar2(50), adr2 varchar2(50), codpst varchar2(10), ville varchar2(50)) ;
Création du fichier de contrôle
●
●
vi $HOME/agent.ctl
LOAD DATA INFILE '$HOME/agent.csv'
TRUNCATE
INTO TABLE ALICE.AGENT
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
( CODE, MATR, TITRE, NOM, ADR1, ADR2, CODPST, VILLE
)
Lancement du chargement
●
Création d'un fichier de paramètres
●
vi $HOME/agent.load
●
●
control=$HOME/agent.ctl
discard=$HOME/agent.discard
bad=$HOME/agent.bad
log=$HOME/agent.log
sqlldr parfile=$HOME/agent.load
Accélerer le chargement
SQL*Loader
●
●
Si le chargement ne demande pas de commit
régulier il est possible d'utiliser le mode direct.
Modifier le fichier $HOME/agent.load et ajouter
juste la ligne suivante :
●
direct=y
●
Relancer le chargement.
●
sqlldr parfile=$HOME/agent.load
Installation d'un patch
●
●
Dans l'exemple présenté le patch 8670579 va être installé. Ce patch corrige,
entre autre, DBCA sous processeur AMD.
Récupérer le patch
●
●
●
En étant connecté oracle, le décompresser et se positionner sous le
répertoire créé.
●
unzip p8670579_112010_LINUX.zip
●
cd 8670579
Vérifier les pré-requis du patch
●
●
$ORACLE_HOME/OPatch/opatch query
Installer le patch par la commande opatch apply
●
●
$ORACLE_HOME/OPatch/opatch prereq
Vérifier les actions du patch
●
●
wget http://192.168.4.224/ORA/p8670579_112010_LINUX.zip
$ORACLE_HOME/OPatch/opatch apply
La commande suivante permet de voir l'installation du patch.
●
$ORACLE_HOME/OPatch/opatch lsinv
Créer un fichier délimité
●
Créer un fichier agent.sql contenant les lignes ci-dessous
set feedback off
set linesize 300
set verify off
set heading off
set pagesize 0
set trimspool off
set termout off
set colsep '|'
spool '$HOME/agent.txt'
select * from agent;
spool off
exit;
●
Lancer le script ainsi
●
●
sqlplus -s alice/ecila@red @agent.sql
L'option -s correspond au mode silence de sqlplus, bien mettre exit en fin de
script car sinon l'écran semble figé.
Activer le mode autotrace
●
●
Cette fonctionnalité est très pratique afin de visualiser
rapidement les ressources et le plan d'exécution d'une
requête.
Le rôle plustrace doit être activé dans la base et affecté à
l'utilisateur. Ce qui n'est pas fait par défaut.
●
Création du rôle plustrace
●
●
●
SQL> sta $ORACLE_HOME/sqlplus/admin/plustrce.sql
●
SQL> grant plustrace to scott;
L'utilisateur scott peut maintenant utiliser set autotrace on
Exemple autotrace
●
Se connecter SCOTT
●
sqlplus scott/tiger@red
●
SQL> alter table emp add primary key ( empno );
●
SQL> alter table dept add primary key ( deptno );
●
SQL> set linesize 150;
●
SQL> set autotrace on
●
●
SQL> select empno,ename,job,dept.deptno,dname
from emp,dept where emp.deptno=dept.deptno;
SQL> set autotrace off;
Exemple de plan d'exécution
Mise en place de l'Explain Plan
●
●
●
Permet de connaître le plan d'exécution d'une
requête.
Fonction redondante avec set autotrace on
Nécessaire pour récupérer le plan d'exécution
dans les traces → tkprof
●
Demande la création d'une table :
●
●
SQL>@?/rdbms/admin/utlxplan.sql
●
Doit être fait sous le compte de l'utilisateur.
Analyse de la requête
●
SQL> explain plan for select * from personne ;
●
Exploitation
●
SQL>@?/rdbms/admin/utlxpls
SQL trace et TKPROF
●
●
Activation au sein d'une session, possible
au niveau de l'instance mais ralenti
notablement les performances.
●
Collecte les instructions SQL
●
Génère une trace mise en forme par TKPROF
SQL Trace
BD
Fichier
trace
TKPROF
Stocké sous le répertoire
adr ( $ORACLE_BASE/diag/... )
Fichier
d'état
Activer le mode trace
●
L'utilisateur doit disposer du privilège alter session
●
SQL>connect system/manager11@red
●
SQL>grant alter session to scott ;
●
SQL>connect scott/tiger@red
●
SQL>alter session set sql_trace=true ;
●
SQL>select empno,ename,job,dept.deptno,dname from emp,dept
where emp.deptno=dept.deptno;
●
SQL>alter session set sql_trace=false ;
●
SQL>exit;
●
La trace est dans $ORACLE_BASE/diag/rdbms/red/RED/trace
●
Il s'agit en général du dernier fichier créé → utiliser la commande ls
-rtl.
Mise en forme TKPROF
●
Transient Kernel PROfile
●
cd $ORACLE_BASE/diag/rdbms/red/RED/trace
●
tkprof red_ora_3107.trc $HOME/trace.txt sys=no
●
●
●
La clause sys=no permet d'exclure les requêtes
internes Oracle ( mais pas toutes ).
Le nom du fichier trace est certainement
différent.
Editer le fichier $HOME/trace.txt pour exploiter
le résultat.
Résultat mise en forme TKPROF
Annexes
Result Cache
●
●
Stocke le résultat d’une requête SQL ou d’une fonction PL/SQL.
Réutilisation directe d’un résultat sans avoir à ré-exécuter
l’instruction.
●
Le temps de réponse est proche de 0.
●
Le Result Cache est un sous pool de la Shared Pool.
●
●
Les requêtes ou fonctions adaptées à l’exploitation de cette
fonctionnalité sont celles travaillant sur de nombreuses lignes pour
retourner un résultat peu volumineux.
Cette fonctionnalité peut s’appliquer à des sous-interrogations.
Conditions d'utilisation
●
●
●
●
Les données de la table n’ont pas changé, pas
de mise à jour
La fonctionnalité soit activée (hint, paramètre,
attribut de la table)
La requête ne fait pas référence à des
éléments contextuels ( sysdate par exemple )
ou temporaires.
Le résultat soit encore en cache
Non utilisation du result
cache
●
●
●
●
Le cache de résultat est désactivé pour les requêtes contenant :
●
des tables temporaires
●
des tables systèmes
●
des séquences CURRVAL et NEXTVAL
●
les fonctions SYSDATE, CURRENT_DATE, SYS_GUID
●
DML ou DDL sur des bases distantes
Le cache de résultat ne libère pas automatiquement la mémoire, il
augmente jusqu'à son maximum.
La procedure DBMS_RESULT_CACHE.FLUSH purge la mémoire.
Avec les variables bindées, le cache de résultat n'est découvert
qu'avec les mêmes valeurs pour les variables.
Paramètres de l'instance
●
●
RESULT_CACHE_MODE
●
MANUAL, valeur par défaut, spécifier le hint "result_cache"
●
FORCE, tous les résultats seront stockés en cache, si conditions respectées.
RESULT_CACHE_MAX_SIZE
●
Défini la taille du cache
●
Désactive le cache de résultat si positioné à 0
●
Par défaut il dépend d'autres paramètres mémoire
–
–
–
●
●
0.25% de memory_target
0.5% de sga_target
1% de share_pool_size, ne peut pas dépasser 75% du shared_pool
RESULT_CACHE_MAX_RESULT
●
Définie la taille maximum pour un seul résultat
●
Défaut à 5%, paramètre au niveau system ou session
RESULT_CACHE_REMOTE_EXPIRATION
●
Défini le temps d'expiration du cache qui dépend d'objets distants → DBlink
●
Défaut à 0 → ne doit pas être utilisé sur des objets distants.
Utilisation d'un hint
●
Utiliser le Result Cache
●
●
●
/* + RESULT_CACHE */
Select /* + result_cache */ ename, dname from emp, dept
where emp.deptno=dept.deptno ;
Ne pas utiliser le Result Cache
●
●
●
/* + NO_RESULT_CACHE */
Select /* + no_result_cache */ ename, dname from emp,
dept where emp.deptno=dept.deptno ;
Utile si RESULT_CACHE_MODE=FORCE et souhait de ne
pas utiliser le result_cache.
Caractéristique de la table
●
Une table peut systématiquement utiliser le
résult cache
●
●
CREATE TABLE….RESULT_CACHE (MODE
{ DEFAULT | FORCE } )
ALTER TABLE….RESULT_CACHE (MODE
{ DEFAULT | FORCE } )
Vues utiles
●
V$RESULT_CACHE_STATISTICS
●
●
V$RESULT_CACHE_MEMORY
●
●
Objets, caches de résultats et dépendances, avec leur attribut
V$RESULT_CACHE_DEPENDENCY
●
●
Blocks mémoire et statistiques associées
V$RESULT_CACHE_OBJECTS
●
●
statistiques sur l'usage des caches et de la mémoire
Détails des liens entre caches de résultats et leurs dépendance
Consulter le contenu du Result Cache :
●
SQL> SELECT type, status, name, object_no, row_count,row_size_avg
FROM v$result_cache_objects ORDER BY 1;
DBMS_RESULT_CACHE
●
Status du Cache
●
●
Rapport sur l'usage du cache de résultat
●
●
EXECUTE DBMS_RESULT_CACHE.FLUSH;
Invalidation des caches de résultat spécifiques
●
●
EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT;
Vidange de tous les caches de résultat
●
●
SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;
EXECUTE DBMS_RESULT_CACHE.INVALIDATE('EMP','DEPT');
Le lien Internet suivant contient une bonne présentation d'un cas
avec le result cache.
●
http://blog.arkzoyd.com/2012/10/fonctions-result-cache-en-action.html
Result Cache et outils décisionnels
●
●
●
●
●
Les requêtes décisionnelles profitent le plus du result cache.
Certains outils décisionnels, Cognos, Business Object,
Microstrategy..., disposent de leur propre cache. Le
result_cache peut-il être interressant ?
Le cache applicatif est souvent limité au périmètre de la
requête (les prédicats d'interrogation et de sécurité permettant
de déterminer ce périmètre).
Lorsque l'on souhaite un cache plus étendu coté application, il
s'agit souvent d'options
Pour profiter du result_cache comme un cache plus large que
les caches applicatifs classiques, il est intéressant de passer
par des vues incorporant le hint /*+result_cache*/ et d'utiliser
ces vues dans le catalogue ou l'univers.
Mise à jour
●
Arrêter la base de données
●
Installer la mise à jour, par exemple 11.2.0.3
●
Démarrer la base en mode mount et la passer en mode upgrade.
●
●
SQL> startup mount;
●
SQL> alter database open upgrade;
●
SQL> @?/rdbms/admin/catupgrd.sql;
Tester ensuite la mise à jour correcte
●
SQL> select comp_name, version from dba_registry;
COMP_NAME VERSION

Oracle Database Catalog Views 11.2.0.3.0
Oracle Database Packages and Types 11.2.0.3.0
●
Il peut y avoir plus de lignes sur cette requête.
●
Relancer le script catupgrd.sql si les versions sont différentes.
Outils système utiles
●
●
●
●
Bien que le database control donne de bonnes indications sur la santé
de la base, il est intéressant de connaître des outils Linux basiques. Il
permettent très rapidement de déceler un problème disque, processeur,
mémoire ou noyau.
Les chiffres dans les commandes suivantes indiquent pour le premier le
temps en secondes entre deux mesures, le second le nombre de
mesures.
La commande sar :
●
sar -u 5 10 → donne des informations sur l'utilisation du processeur.
●
sar -d 5 5 → donne des informations sur l'utilisation des disques.
La commande vmstat
●
●
vmstat 5 5 → donne des informations sur la pagination.
La commande ipcs donne des informations sur les paramètres noyau,
notamment les sémaphores.
Exemple sur imp
●
Les exemple suivants montrent l'activité d'un serveur Oracle lors d'un import de données
●
Commande sar -d 5 5
●
On distingue nettement l'utilisation du disque ( dev8-0 ) et des partitions 5,6 et 13
Moyenne: DEV tps rd_sec/s wr_sec/s avgrqsz avgqusz await svctm %util
Moyenne: dev80 155,54 2635,67 2339,94 31,99 0,98 6,29 5,87 91,35
Moyenne: dev81 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev82 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev83 0,80 0,24 2,32 3,20 0,01 10,10 2,60 0,21
Moyenne: dev84 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev85 6,60 0,64 655,10 99,39 0,02 2,33 2,32 1,53
Moyenne: dev86 139,74 2633,51 911,00 25,36 0,94 6,71 6,42 89,68
Moyenne: dev87 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev88 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev89 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev810 0,64 0,32 5,76 9,50 0,00 6,50 2,12 0,14
Moyenne: dev811 0,16 0,32 0,96 8,00 0,00 9,25 8,75 0,14
Moyenne: dev812 0,16 0,00 2,88 18,00 0,00 5,00 5,00 0,08
Moyenne: dev813 7,44 0,64 761,94 102,54 0,01 1,38 1,37 1,02
Moyenne: dev816 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Moyenne: dev817 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Exemple sur imp suite
●
La commande sar -u 5 5
●
Ici encore le système I/O est fortement solicité.
18:49:59 CPU %user %nice %system %iowait %steal %idle
18:50:04 all 2,90 0,00 0,50 47,15 0,00 49,45
18:50:09 all 4,50 0,00 0,90 44,86 0,00 49,75
18:50:14 all 4,20 0,00 0,70 45,25 0,00 49,85
18:50:19 all 4,40 0,00 0,60 45,60 0,00 49,40
18:50:24 all 4,40 0,00 0,60 45,15 0,00 49,85
Moyenne: all 4,08 0,00 0,66 45,60 0,00 49,66
Exemple sur imp suite et fin
●
●
La commande vmstat 5 5
Cette commande confirme que l'activité
système est actuellement sur le disque, ce qui
est normal pour une importation de données.
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 19204 13900 3952 803844 7 9 3508 3385 580 512 13 3 39 44 0
0 1 19204 13816 3980 803916 0 0 1493 1155 1148 375 5 1 50 45 0
0 1 19200 13600 3980 804284 0 0 1680 1409 1149 414 5 1 50 44 0
1 1 19200 14292 4000 805316 0 0 1307 1080 1162 410 4 1 50 45 0
0 1 19200 14168 3988 805408 0 0 1390 1034 1168 421 4 1 50 45 0
Configuration à 2 listeners
●
●
●
Le principe général est d'affecter RED à LSNR1 et
BLACK à LSNR2.
RED est accessible via le port 1521 alors que
BLACK l'est via le port 1522 en TCP/IP.
Stopper le listener actuel.
●
●
lsnrctl stop
Il faut dans un premier temps modifier le fichier
$ORACLE_HOME/network/admin/listener.ora afin
de créer 2 listeners distincts :
●
LIST1
●
LIST2
Principe
client
client
TCP/IP
1521
LIST1
RED
LIST2
BLACK
client
client
client
TCP/IP
1522
listener.ora
LIST1 =
(DESCRIPTION_LIST =
(DESCRIPTION =
)
)
ADR_BASE_LIST1 = /u01/app/oracle
LIST2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
)
)
ADR_BASE_LIST2 = /u01/app/oracle
Alias listener
●
●
Ensuite ajouter dans
$ORACLE_HOME/network/admin/tnsnames.or
a des alias vers ces deux listeners.
Ce sont ces alias qui serviront pour le
paramètre LOCAL_LISTENER.
tnsnames.ora
LSNR1 =
(DESCRIPTION =
(ADDRESS_LIST =
( ADDRESS = ( PROTOCOL = TCP ) ( HOST = lx-4-20 )( PORT = 1521))
)
)
LSNR2 =
(DESCRIPTION =
(ADDRESS_LIST =
( ADDRESS = ( PROTOCOL = TCP ) ( HOST = lx-4-20 )( PORT = 1522))
)
)
Démarrage listener
●
●
Redémarrer les deux listeners
●
lsnrctl start list1
●
lsnrctl start list2
Activer sur chaque instance le paramètre LOCAL_LISTENER
●
●
●
SQL> alter system set local_listener='LSNR1' scope=both
●
SQL> alter system register ;
●
SQL> exit;
●
●
●
SQL> alter system set local_listener='LSNR2' scope=both
●
SQL> alter system register ;
●
SQL> exit;
Bibliographie
●
En français, un bon ouvrage est
celui des éditions ENI ( très orienté
Windows et Database Control )
●
●
●
http://www.editions-eni.fr
Les meilleurs livres sinon sont en
anglais et tout particulièrement les
manuels SYBEX pour la
certification OCA et OCP.
Ils comportent le livre, sa version
PDF et un QCM très complet.
●
http://www.sybex.com
Sites Web
●
●
En français
●
http://www.oracle-wiki.net/
●
http://blog.arkzoyd.com/
●
http://www.silverlake.fr
En anglais
●
http://www.dba-village.com
●
http://www.akadia.com
●
http://www.dba-oracle.com
●