Oracle 11g - ADMINISTRATION

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...

●

Droits des utilisateurs

●

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@lx­1­3 ~]$ 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@lx­1­3 ~]$

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=lx­8­1 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 = lx­8­10 )(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

Principaux paramètres suite ... ●

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

Principaux paramètres suite ... ●

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

Principaux paramètres suite ... ●

●

●

●

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.

Principaux paramètres suite ... ●

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> connect / as sysdba

●

SQL> startup nomount;

●

SQL> create spfile from pfile;

●

SQL> shutdown abort;

●

SQL> startup nomount;

●

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 = (SERVICE_NAME = RED) ) ) RED_LX-34-3 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = LX-34-3)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = RED) ) ) 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 : export ORACLE_SID=RED 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. export ORACLE_SID=RED sqlplus /nolog SQL> connect / as sysdba → identification par OS ●

Variante :

export ORACLE_SID=RED sqlplus ''/ as sysdba'' export ORACLE_SID=RED 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_.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 : __.trc. Le nom des fichiers de trace des processus serveur est de la forme : _ora_.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> connect alice/ecila@red

●

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 ●

export ORACLE_SID=RED

●

sqlplus /nolog

●

SQL> connect / as sysdba

●

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;

En ligne de commande taper : ● ●

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 ● ● ●

● ●

En ligne de commande taper : 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 export ORACLE_SID=RED 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://www.oracle.com/pls/db112/homepage

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 ●

export ORACLE_SID=RED

●

sqlplus /nolog

●

SQL> connect / as sysdba

●

sqlplus sys/manager11@red as sysdba

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 ●

export ORACLE_SID=RED

●

sqlplus /nolog

●

SQL> connect / as sysdba

●

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 ●

mkdir -p /u02/app/oracle/oradata/RED

●

mkdir -p /u03/app/oracle/oradata/RED

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> connect / as sysdba

●

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> host cp /u01/app/oracle/oradata/RED/control01.ctl /u03/app/oracle/oradata/RED/control03.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. ●

sqlplus sys/manager11@red as sysdba

●

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> host cp /u01/app/oracle/oradata/RED/control01.ctl /u02/app/oracle/oradata/RED/control02.ctl 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> shutdown immediate; 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.

●

sqlplus system/manager11@red

●

●

●

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> shutdown immediate;

●

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'; SQL> alter database open;

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

                /u02/app/oracle/oradata/RED/DATA_STATS_02.dbf

            2500

DATA_STATS

                /u02/app/oracle/oradata/RED/DATA_STATS_03.dbf

            1500

IDX_STATS

                /u03/app/oracle/oradata/RED/IDX_STATS_01.dbf

            4000

IDX_STATS

                /u03/app/oracle/oradata/RED/IDX_STATS_02.dbf

            3000

IDX_STATS

                /u03/app/oracle/oradata/RED/IDX_STATS_03.dbf

            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> connect / as sysdba

●

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é sqlplus system/manager11@red ●

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 ●

export ORACLE_SID=RED

●

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'';

Droits des utilisateurs ●

●

●

●

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.

Droits des utilisateurs ●

●

●

●

●

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> connect alice/ecila@red 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

●

SQL> connect alice/ecila@red

●

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> connect bob/robert@red

●

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> connect bob/robert@red

●

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

●

sqlplus system/manager11@red ●

●

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,

●

25 à 50% d'espace libre,

●

50 à 75% 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> connect alice/ecila@red

●

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.

●

sqlplus system/manager11@red ●

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 ●

sqlplus alice/ecila@red

●

ALICE:RED > create table test as select rownum as numop, rownum / (24 * 60) + sysdate - 1000 as date_op from dual connect by rownum sta inutile 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; ALICE:RED > sta espace Blocs : . Pleins

= 249

. 0 à 25% d'espace libre = 0 . 25 à 50% d'espace libre = 0 . 50 à 75% d'espace libre = 0 . 75 à 100% d'espace libre = 0 . Non formatés

=0

ALICE:RED > sta inutile 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 cot2005 values less than( to_date('01/01/2006','DD/MM/YYYY')), partition cot2009 values less than( to_date('01/01/2010','DD/MM/YYYY')), partition cot2010 values less than( to_date('01/01/2011','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(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 disable ;

●

La réactivation suit la même logique

●

SQL> alter table enable ;

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 :

●

●

●

●

export ORACLE_SID=RED

●

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

●

sqlplus sys/manager11@red as 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

●

export ORACLE_SID=RED

●

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/ et /u01/app/oracle/flash_recovery_area/RED/autobackup/

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 ●

export ORACLE_SID=RED

●

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

●

export ORACLE_SID=RED

●

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

●

●

●

●

sqlplus sys/manager11@red as sysdba

●

SQL> shutdown immediate;

●

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/ 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 target sys/manager11@red

●

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/ et /u01/app/oracle/flash_recovery_area/RED/autobackup/

Visualiser les sauvegardes ●

●

●

rman target sys/manager11@red ●

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 target sys/manager11@red ●

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 ;

Durée de rétention ●

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 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

●

sqlplus alice/ecila@red

●

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 target sys/manager11@red 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

Durée de rétention ●

●

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 ●

sqlplus sys/manager11@red as sysdba

●

SQL> shutdown immediate;

●

SQL> startup mount;

●

SQL> alter database flashback on;

●

SQL> alter database open;

●

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> shutdown immediate;

●

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> restore database;

●

RMAN> recover database;

●

RMAN> alter database open;

●

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

●

mkdir -p /u02/app/oracle/oradata/BLACK

●

mkdir -p /u03/app/oracle/oradata/BLACK

●

mkdir -p /u04/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

●

export ORACLE_SID=RED

●

sqlplus /nolog ●

●

●

SQL> connect / as sysdba 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> connect / as sysdba

●

SQL> startup nomount;

●

SQL> quit

Création du clone ●

export ORACLE_SID=BLACK

●

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) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = RED) ) (SID_DESC = (GLOBAL_DBNAME = BLACK) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = BLACK) ) )

Exemple tnsnames.ora RED = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = lx-1-3)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = RED) ) ) 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.

●

export ORACLE_SID=RED

●

sqlplus /nolog ●

SQL> connect / as sysdba

●

SQL> select dbid from v$database; → Noter le dbid

●

SQL> shutdown immediate;

●

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> connect / as sysdba

●

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> restore database;

●

RMAN> recover database;

●

RMAN> alter database open;

●

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 userid=system/manager11@red 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

●

sqlplus system/manager11@red

●

SQL> drop user scott cascade ;

●

SQL> exit;

●

Créer un fichier de paramètres ● ●

●

directory=dpump dumpfile=scott.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 ;

Créer un fichier de paramètres ●

vi $HOME/blake.dpimp directory=dpump dumpfile=scott.dpump logfile=blake.dpimp.log table_exists_action=replace schemas=scott query=scott.emp:"where SAL  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 :

●

sqlplus alice/ecila@red

●

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  avgrq­sz  avgqu­sz     await     svctm     %util Moyenne:       dev8­0    155,54   2635,67   2339,94     31,99      0,98      6,29      5,87     91,35 Moyenne:       dev8­1      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:       dev8­2      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:       dev8­3      0,80      0,24      2,32      3,20      0,01     10,10      2,60      0,21 Moyenne:       dev8­4      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:       dev8­5      6,60      0,64    655,10     99,39      0,02      2,33      2,32      1,53 Moyenne:       dev8­6    139,74   2633,51    911,00     25,36      0,94      6,71      6,42     89,68 Moyenne:       dev8­7      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:       dev8­8      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:       dev8­9      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:      dev8­10      0,64      0,32      5,76      9,50      0,00      6,50      2,12      0,14 Moyenne:      dev8­11      0,16      0,32      0,96      8,00      0,00      9,25      8,75      0,14 Moyenne:      dev8­12      0,16      0,00      2,88     18,00      0,00      5,00      5,00      0,08 Moyenne:      dev8­13      7,44      0,64    761,94    102,54      0,01      1,38      1,37      1,02 Moyenne:      dev8­16      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00 Moyenne:      dev8­17      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 = (ADDRESS = (PROTOCOL = TCP)(HOST = lx-4-20)(PORT = 1521)) ) ) ADR_BASE_LIST1 = /u01/app/oracle LIST2 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = lx-4-20)(PORT = 1522)) ) ) 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 ●

export ORACLE_SID=RED

●

sqlplus "/ as sysdba"

●

SQL> alter system set local_listener='LSNR1' scope=both

●

SQL> alter system register ;

●

SQL> exit;

●

export ORACLE_SID=BLACK

●

sqlplus "/ as sysdba"

●

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

●

http://www.oracle.com/pls/db112/homepage