Vous êtes sur la page 1sur 7

Formation : Oracle 8 Administration

Généralités
La base de données (database) au sens Oracle correspond à l’aspect logique de l’organisation des données (tablespaces,
rollback segments, etc.).
Une base de données comporte des utilisateurs, certains d’entre eux vont être amenés à créer des objets (tables, index,
etc.) et donc devenir des schémas.
Le modèle physique de données d’une application est en fait un schéma.
Une instance correspond à l’organisation en mémoire des données (SGA, etc.)

1. Création d’une base de données

1.1. Création d’une arborescence pour la base

1.2. Création d’une instance


1.2.1.Création du service
Pour créer une base de données on va avoir besoin d’une instance. Pour Windows NT une instance est un service. La
création d’un service étant une chose complexe il faut utiliser Oradim80.Exe.

C:\> Oradim80 –new –sid <SID> -intpwd <INTERNAL PASSWORD>

<SID> : nom de l’instance. 4 Caractères maximum jusqu’en version 8, 8 caractères à partir de la version 8i.
<INTERNAL PASSWORD> : mot de passe de l’utilisateur INTERNAL, celui qui a les droits pour monter ou tomber la
base. En général on le fixe à ORACLE, on peut aussi lui fixer la même valeur que le <SID> pour éviter les erreurs.
1.2.2.Connexion à l’instance
On ouvre une session MSDOS

On fixe comme instance par défaut Oracle, l’instance qu’on vient de créer. Cela se fait en affectant <SID> à la variable
système ORACLE_SID

C:\> set ORACLE_SID = <SID>

On lance le Server Manager (svrmgr30.exe) et son se connecte à l’aide du user INTERNAL et du mot de passe fixé plus
haut.

C:\ORANT\BIN> Svrmgr30
SVRMGR> connect INTERNAL / <INTERNAL PASSWORD>

On démarre l’instance :

SVRMGR> startup nomount pfile=<CHEMIN FICHIER INIT>

<CHEMIN FICHIER INIT> : chemin d’accès au fichier d’initialisation de la base INIT<SID>.ORA

On peut contrôler que tout s’est bien passé en faisant


Select * from v$parameter (qui ne renvoie aucune ligne) ou Select * from v$sga (qui renvoie les paramètres de la SGA
tels que fixés dans le fichier d’initialisation).

Remarque :
Si on crée l’instance avec le paramètre –startmode auto et –pfile il ne sera pas nécessaire de redémarrer la base lors de
la prochaine connexion.

C:\> Oradim80 –new –sid <SID> -intpwd <INTERNAL PASSWORD> –startmode auto -pfile=<CHEMIN
FICHIER INIT>
1.3. Création de la base de données
1.3.1.Le script de création
Il faut créer le script de la base de données, on l’enregistre sous le nom Cree<SID>.sql

create database <SID>


logfile
group 1 ('D:\DATABASE\<SID>\LOG\<SID>11.log',
'D:\DATABASE\<SID>\LOG\<SID>12.log')
size 10M,

group 2 ('D:\DATABASE\<SID>\LOG\<SID>21.log',
'D:\DATABASE\<SID>\LOG\<SID>22.log')
size 10M

datafile 'D:\DATABASE\<SID>\DATAFILE\<SID>.dtf'
size 100M

character set WE8ISO8859P1;

Remarque :

Les membres des groupes des fichiers de log devraient être placés sur des disques différents pour des raisons de
sécurité.

On lance le script sous svrmgr

SVRMGR> @<CHEMIN FICHIER SCRIPT> Cree<SID>.sql

1.3.2.Lancement des scripts standard


Certaine fonctionnalités d’Oracle ne seront accessibles qu’après avoir lancé les scripts SQL correspondants  :
 catalog.sql (dictionnaire de données)
 catproc.sql (option procédurale, PL/SQL)
 catexp.sql (imports / exports)

SVRMGR> @C:\ORANT\RDBMS80\ADMIN\catalog.sql
SVRMGR> @C:\ORANT\RDBMS80\ADMIN\catproc.sql
SVRMGR> @C:\ORANT\RDBMS80\ADMIN\catexp.sql

Remarque :
Pour lancer ces scripts il faut être connecté en tant que user SYS. Le mot de passe par défaut est
CHANGE_ON_INSTALL.

1.4. Gestion des tablespaces


Une base de données qui vient d’être créée comporte par défaut un Tablespace nommé SYSTEM qui correspond au(x)
Datafile(s) défini(s) lors de la création de la base (CREATE DATABASE).
Ce tablespace va servir à stocker les données concernant la structure de la base (tables système, définition des users,
etc.).

Pour s’assurer de bonnes performances il ne faut pas hésiter à définir un tablespace SYSTEM de grande taille, afin que
les données soient contiguës.
On peut aussi le définir avec le paramètre AUTOEXTEND.

Lorsqu’on crée un tablespace il ne faut pas hésiter à définir des valeurs importantes pour le INITIAL et le NEXT car le
nombre d’extent maximum est 121, et il faut s’assurer qu’on aura la place de stocker les données sans atteindre cette
limite.
Pour ce faire on pourra estimer la taille des tables dont les données seront stockées dans le tablespace.

On créera plusieurs Tablespaces, au minimum un pour les données, un pour les rollback segments et un tablespace
temporaire. On peut aussi en créer un pour les index.
La taille du tablespace destiné aux index doit être au minimum deux fois supérieure à la taille du tablespace destiné aux
données.

La taille du tablespace temporaire dépend du nombre d’utilisateurs et de la quantité de données manipulées par les
requêtes de ces derniers. On pourra fixer par défaut une taille égale à 20% de la taille du tablespace de données.

create tablespace tbs_data


datafile 'd:\database\groo\datafile\tbs_data1.dtf' size 100M
online;

On peut utiliser ALTER DATABASE DATAFILE ‘<CHEMIN DATAFILE>’ RESIZE <TAILLE> pour retailler un
datafile.

1.5. Les rollback segments


Les rollback segments servent à gérer les rollbacks dans la base. Leur taille est déterminée en fonction du nombre
d’utilisateurs de la base (Cf. support de cours).
Il s’agira ensuite de créer plusieurs rollback segments pour améliorer les performances. Une règle qu’on peut utiliser est
de créer un nombre de rollback segments égal au nombre de sessions maximum divisé par 4.

Si l’application comporte des batches manipulant une très grande quantité d’informations on pourra créer un rollback
segment de très grande taille qui sera affecté à un user spécifique que l’on utilisera pour les batches.

Enfin, dans le but d’améliorer les performances on créera un tablespace spécifiquement destiné aux rollback segments.

alter rollback segment rbs_data1 offline;


drop rollback segment rbs_data1;
create public rollback segment rbs_data1
tablespace tbs_rollback
storage(initial 10k);
alter rollback segment rbs_data1 online;

Les rollback segments sont créés OFFLINE, il est donc nécessaire de les mettre ONLINE.

Pour s’assurer que les rollback segments seront bien placés ONLINE au prochain démarrage de la base il faudra
modifier le fichier d’initialisation et spécifier pour la clef ROLLBACK_SEGMENTS le nom des rollback segments à
mettre ONLINE .

ROLLBACK_SEGMENTS = (<ROLLBACK SEGMENT 1>, <ROLLBACK SEGMENT 2>, …)

Par défaut les rollback segments publics sont mis ONLINE au démarrage, contrairement aux rollback segments privés.

1.6. Les tables


Il est utile de lancer régulièrement des requêtes d’analyse des tables afin de permettre une optimisation efficace des
requêtes, en particulier sur les tables sur lesquelles il y a beaucoup de mouvements.

Ces requêtes permettent notamment de déterminer si la table comporte des lignes chaînées. A partir de 5 ou 10% de
lignes chaînées il est utile de la décompresser.
On pourra le faire en utilisant l’utilitaire d’import / export ou en créant une table temporaire pour dupliquer. la table

Le script utlchain.sql permet de créer la table dans laquelle seront stockées les informations sur les lignes chaînées
renvoyées par la requête d’analyse.

1.7. Les index


Cf. Support de cours

1.8. Les clusters


Cf. Support de cours

Les inconvénients du cluster sont les suivants :


 Les insertions dans une table situées dans un cluster sont très coûteuses.
 La destruction d’un cluster entraîne la destruction des tables qu’il contient.

On peut reconstruire un index grâce à l’instruction ALTER INDEX REBUILD.

2. Arrêt / démarrage d’une base

2.1. La commande Startup


La commande Startup est utilisée pour démarrer base de données. Une base de données peut se trouver dans un des états
suivants :

Nomount : Le fichier d’initialisation est lu, la SGA est créée, mais aucun fichier de données n’est lu. Le seul user
existant est INTERNAL. La base est inaccessible.
Mount : La base est montée. Tous les fichiers de contrôle, de log, etc. sont ouverts et vérifiés. Seuls les DBA peuvent se
connecter à une base dans cet état (user INTERNAL, SYS et SYSTEM).
Open : La base est montée et ouverte. C’est le paramètre par défaut.

La commande Startup permet de placer la dans un de ces états. Un startup sans paramètres correspond à un Startup
open.

SVRMGR> startup nomount pfile=< CHEMIN FICHIER INIT >


SVRMGR> startup mount
SVRMGR> Startup open

Remarque :
Une base passe dans les différents états successivement, par exemple pour passer à l’état Mount, la base passe d’abord à
l’état Nomount.
Il est possible de monter d’un état (Nomount -> Mount) à l’aide d’un ALTER DATABASE MOUNT.
Pour descendre il faut fermer la base par la commande SHUTDOWN et la redémarrer par STARTUP.

Il est possible de forcer l’ouverture d’une base avec le paramètre force. Une base démarrée de cette manière doit être
refermée et réouverte « proprement » par un startup open.

2.1. La commande Shutdown


Cf. Support de cours

3. La sécurité
Les droits Oracle sont gérés par l’union des autorisations, c’est à dire que lorsqu’on a le droit de faire quelque chose
quelque part, on a le droit de le faire partout.

3.1. Les utilisateurs


3.1.1.Généralités
Il est possible en version 8 de créer un user identifié par un dictionnaire LDAP.

Create user <UTILISATEUR> globally as <CHAINE LDAP>…

Il est indispensable de spécifier un default tablespace sans quoi c’est le tablespace SYSTEM qui est utilisé.

En version 8 il est possible de mettre en place des expirations de mots de passe et une historisation des mots de passe.

Il faut faire attention, le formalisme Oracle distingue User et Schéma, un User ne possède aucun objet (il n’a pas créé de
tables, etc.) alors qu’un Schéma a créé des objets et est en fait considéré comme une base, comme un objet.
Cependant il n’existe qu’un seul objet Oracle recouvrant ces deux notions.
Tout ceci implique que la destruction d’un objet User entraîne la destruction de tout ce qu’il a créé.
3.1.2.Profils et rôles
Pour que les profils fonctionnent il faut mettre en place la limitation des ressources, c’est à dire place dans le fichier
d’initialisation la ligne : RESSOURCE_LIMIT = TRUE

drop profile PRF_GUEST cascade;


create profile PRF_GUEST limit
IDLE_TIME 1;

drop user GUEST;


create user GUEST
identified by GUEST
default tablespace tbs_data
profile PRF_GUEST;
grant CONNECT to GUEST;
alter user GUEST
default role CONNECT;

4. Audit et optimisation
Pour accéder à l’audit, se connecter en INTERNAL ou SYS et passer le script CATAUDIT.sql

4.1. Le mode trace

Il y a deux possibilités pour obtenir des renseignements sur ce qui se passe :

Mettre le moteur en mode trace ( SQL_TRACE = TRUE dans le fichier d’initialisation). Par ce moyen tout ce que fait
le moteur de base de données est tracé. Une quantité d’informations considérable et difficilement utilisable est produite,
il convient donc de n’opter pour cette solution que si on suspecte un comportement anormal du moteur.

Placer la session en mode trace (ALTER SESSION SET SQL_TRACE = TRUE).

Toutes les données de trace sont stockées dans des fichiers situés dans les répertoires USER_DUMP_DEST et
BACKGROUND_DUMP_DEST.

Les informations contenues dans ces fichiers étant difficiles à relire, il est préférable d’utiliser un utilitaire nommé
TKPROF80 qui retraite les fichiers pour les rendre lisibles.

5. La sauvegarde

5.1. La sauvegarde physique

Il s’agit de la copie physique des datafiles, des control files et des log files sur un support quelconque (bande …).

5.1.1.La sauvegarde à froid


La meilleure manière de procéder est la sauvegarde à froid, c’est à dire après avoir arrêté la base de données.
Il suffit pour cela de faire un Shutdown de la base, de faire une copie des fichiers concernés (d’où l’utilité d’une
arborescence bien conçue).

5.1.2.La sauvegarde à chaud


Si cela ne s’avère pas possible, on effectue une sauvegarde à chaud, c’est à dire base ouverte.

Pour pouvoir la mettre en place il faut que la base soit en mode archive log.

 Pour ce faire il faudra rajouter dans le fichier d’initialisation les trois clefs suivantes :
LOG_ARCHIVE_START = TRUE
LOG_ARCHIVE_DEST = <REPERTOIRE DE SAUVEGARDE>
LOG_ARCHIVE_FORMAT = text%s.arc

Remarque :
Le nom des fichiers sera du type textxxx.arc où arc est un numéro.

 La base a été arrêtée, il va falloir la monter par STARTUP MOUNT.


 La mettre en mode archive log par ALTER DATABASE ARCHIVELOG
 Puis l’ouvrir par ALTER DATABASE OPEN

En mode archive log, les fichiers log vont être automatiquement sauvegardés au moment du basculement d’un logfile à
un autre.

1) Sauvegarde des log files


On pourra forcer une sauvegarde du fichier log courant en forçant un basculement sur un autre fichier log par :

alter system switch logfile ;

il va cependant falloir prendre garde à la multiplication des fichiers d’archive et donc déplacer ou détruire les fichiers
les plus anciens.

2) Sauvegarde des control files


Pour effectuer la sauvegarde des control files on lancera la commande suivante :

Alter database backup controlfile to <FICHIER> [reuse] ;

3) Sauvegarde des datafiles


Il faudra pour cela procéder de la manière suivante :

alter tablespace <NOM DU TABLESPACE> begin backup ;


-> On sauvegarde le fichier correspondant
alter tablesapce <NOM DU TABLESPACE> end backup ;

5.2. La sauvegarde logique


La sauvegarde logique s’effectue par import / export. L’utilitaire correspondant se nomme EXP (ou EXP73, EXP80).
Pour effectuer des import / export il faut avoir passé le script catexp.sql

Le moyen le plus simple d’utiliser cet utilitaire est le suivant :

EXP parfile = <FICHIER PARAMETRES>

<FICHIER PARAMETRES> : est un fichier qui contient toutes les informations nécessaires dont un user et password.

5.3. La restauration
Les datafiles contiennent les données jusqu’au dernier enregistrement, les fichiers log contiennent les modifications
faites, les fichiers control contiennent l’état de la base et en particulier un numéro de série qui s’incrémente au fur et à
mesure des modifications.

Les sauvegardes à froid constituent des états de référence de la base, la base étant arrêtée on est sûr que tout est correct
à ce moment là.

Si on met en place le mode archivelog, les fichiers log vont être sauvegardés à chaque basculement d’un groupe à un
autre.

On met en suite un mode de sauvegarde à chaud pour enregistrer les fichiers de contrôle et les datafiles.
Le principe de la restauration est de partir d’un état stable des datafiles (issus d’une sauvegarde à froid ou à chaud),
pour arriver à un état donné par un fichier de contrôle. Pour ce faire on va effectuer toutes les modifications qui ont été
effectuées historiquement et qui ont été stockées dans les fichiers log et archivés par le mode archive log.

En conséquence il peut être utile de prévoir des fichiers log contenant toutes les modifications d’une journée. Ceci
permet par exemple de faire une sauvegarde à froid tous les jours et de pouvoir reconstituer toute une journée en cas de
crash.

La commande de récupération doit être lancée avec une base montée mais pas ouverte.
On peut y accéder par :

ALTER DATABASE RECOVER … ;


SVRMGR> RECOVER…