Administration des Bases

de données
Dr. Cheikh Tidiane DIENG
Université Gaston Berger de Saint-Louis
UFR Sciences Appliquées et Technologie
Section Informatique
cheikh-tidiane.dieng@ugb.edu.sn
 Module 3: Les processus d’arriére plan
• Les processus d’arrière plan (background process ou shadow process)
permettent d'assurer le bon fonctionnement de l’instance.
• Ils gèrent les flux entre la mémoire et les disques, et sont nécessaires
au bon fonctionnement de la base de données.
Les processus d’arriere plan (DBWn) (1)
• DBWn( Database Writer)
• Transfert les blocs de données modifiées du data buffer dans les fichiers disque de la
base de données.
• Le paramètre d’initialisation DB_WRITERS_PROCESSES permet de démarrer plusieurs
processus DBWR, afin d ’augmenter le taux d ’écriture sur disque. Le processus LGWR
est active a chaque écriture du DBWRn,
Les processus d’arriere plan (DBWn) (2)
• DBWn copie les blocs modifiés des tables, index, les segments d’annulation et les segments
temporaires à chaque occurrence d’un des évènements suivants:
• Toutes le 3 secondes DBWn copie une petite partie des blocs modifies sur disque
• Dès que la longueur de la « liste CHECKPOINT » dépasse un seuil défini en interne
• Chaque fois qu’un processus consulte la liste des blocs récemment utilisés (LRU list) et ne peut
trouver un emplacement libre après un nombre prédétermine en recherche de blocs. Ainsi la
lecture d’une table de très grande taille peut forcer l’ écriture des blocs modifies sur disque
• Lors de chaque CHECKPOINT
• Chaque fois que la base de données est arrêté anormalement
• Chaque fois qu’une table est effacée ou tronquée
• Chaque fois qu’un tablespace est mis en mode hors ligne ou lecture seule ou s’il fait partie d’une
sauvegarde en ligne.
Les processus d’arriere plan (DBWn) (3)
Plusieurs processus DBWn (numérotés DBW1, DBW2, DBW3, DBW4, etc .)
peuvent s’executer simultanément selon la plateforme et le système
d’exploitation, ce qui limite les risques de contention lors d’importantes
opérations portant sur plusieurs fichiers de données. Le nombre de ces
processus est défini à l’aide du paramètre « DB_WRITER_PROCESSES ». Si
votre système n’accepte pas les opérations d’E/S asynchrones, vous avez la
possibilité de créer un seul processus DBWn avec plusieurs esclave d’E/S
DBWn. Le nombre de esclave est spécifié au moyen du paramètre
d’initialisation « DBWR_IO_SLAVES ».
Les processus d’arriere plan (LGWR)
• LGWR(Log Writer)
• Écrit les données modifiées depuis la zone mémoire redo-log buffer dans
les fichiers redo-log. Cela est nécessaire pour éviter une incohérence de la
base de données en cas de panne d’instance. Les informations journaux
des blocs modifies doivent être écrites dans le fichier journaux avant que
les blocs modifies eux-mêmes ne soient écrits dans les fichiers de
données. Les fichiers de journaux doivent toujours être plus récents que
les fichiers de données. Le processus LGWR maintient toujours l’état le
plus à jour de la base, puisque le processus DBWn peut attendre avant de
consigner les blocs de données modifies dans les blocs de données.
Les processus d’arriere plan (LGWR)
• L’ecriture des tampon de reprise (Buffer redo log) doit etre termine physiquement avant
que le controle ne soit rendu au processus serveur demandant la validation.

• LGWR ecrit le tampon de journaux de reprise (Buffer redo log) dans les fichiers journaux
(fichiers redo log), sous l’une quelconque des conditions:
• Toutes les secondes (independamment du DBWn)
• Lors de la validation d’une transaction en cours COMMIT.
• Chaque fois que le tampon des journaux de reprise est rempli
• Lors de chaque Checkpoint (Voir processus CKPT)
• Lorsqu’il est déclenché par le processus DBWn.
 Les processus d’arriere plan (CKPT) (1)
• CKPT(Checkpoint)
• Les points de contrôle (checkpoint) créent et enregistrent des points de synchronisation
dans la BD, de manière à faciliter sa récupération en cas de défaillance d’une instance ou
d’un media.
• Le processus CKPT exécute des points de contrôle (checkpoints), met à jour l’en-tête des
fichiers de données; lui-même n’écrit pas les données modifiées sur disque, c’est le role
du processus DBWn.
• Signe à des intervalles réguliers, le moment d ’écriture des données modifiées dans la
SGA dans les fichiers de la base de données.
• Ce processus s’execute naturellement à chaque basculement des fichiers journauux
(fichier redo log) ou peut etre execute manuellement par un DBA.
 Les processus d’arriere plan (CKPT) (2)
• Le processus Checkpoint (CKPT) a un rôle important dans le bon fonctionnement d'une Instance.

Checkpoint inscrit les informations de point de reprise dans les fichiers de Controles et dans l'entête
de chaque fichier de données. C'est ce point de reprise (SCN) qui permet de rendre cohérent les
fichiers de controles et les fichiers de données, indispensable pour un processus de récupération.
• Le processus Checkpoint n'écrit pas les blocs sur le disque, c'est le role du processus
Database Writer DBWn.
 Les processus d’arriere plan (CKPT) (3)
• Les numéros SCN enregistrés dans les fichiers garantissent que toutes les
modifications apportées aux blocs de base de données avant un numéro SCN ont été
écrites sur le disque.En cas d'arrêt anormal de l'instance, ce SCN marque le début
début des données à utiliser pour la récupération de l'instance.

Le processus Log Writer (LGWR) n’écrit pas dans le fichier de journalisation (REDO
LOG) tant que le processus CKPT n'a pas synchronisé, car tant que cette
synchronisation n'est pas faite, le fichier de journalisation contient des données
nécessaires à une éventuelle récupération après défaillance de l'instance.

A savoir qu'une synchronisation se déclenche aussi à chaque basculement de REDO

LOG, lors de l’arrêt de la base de données, lors de la mise hors ligne d'un Tablespace.
 Les processus d’arriere plan (CKPT) (3)
• Le paramètre FAST_START_MTTR_TARGET peut être utilisé pour obliger la base à
effectuer des points de reprise régulièrement. En effet ce paramètre indique un
nombre maximum de secondes pour le redémarrage de l’instance après un arrêt
anormal.
• Le positionnement de ce paramètre permet à l’instance d’ajuster des points de
reprises de manière à pouvoir rejouer l’activité perdue sur la base en respectant les
valeurs du paramètre. Attention à ne pas avoir de points de reprises trop fréquents ce
qui dégraderait les performances.
 Archivage
• Le processus LGWR écrit dans chacun des fichiers journaux (fichiers redo-log) à tour
de rôle. Lorsque le premier est plein, il écrit dans le deuxième, et ainsi de suite. Une
fois le dernier fichier rempli il écrase le contenu du premier.
• Lorsque la BD opère dans le mode ARCHIVELOG, elle réalise une copie de chaque
fichier journal (fichier redo-log) plein; ces fichiers archivés sont généralement
enregistrés sur le disque.
• La fonction d’archivage c’est-à-dire la copie de chaque fichier journal plein, est assure
par le processus ARCn.
• Le fichier ARCn n’est pas un processus obligatoire; il est active uniquement si la base
de données fonctionne dans le mode ARCHIVELOG.
• Si la base de données fonctionne dans le mode NOARCHIVELOG, les fichiers journaux
(fichier redo log) seront écrasés régulièrement, ce qui réduit les chances de
reconstruction des fichiers de données à partir des fichiers journaux (fichier redo-
log).
 Le processus d’arriere plan (SMON)
• SMON(System Monitor)
• Le processus SMON est un processus obligatoire qui s’apparente a un observateur du
système. Ce moniteur système est essentiel au démarrage de l’instance d’Oracle et est
impliqué dans tout rétablissement qui s’avere nécessaire. Il nettoie egalement les
segments temporaires et inutilisés, efface les vieux processus, et fusionne même l‘espace
libre dans le plus grands blocs contigus.
• SMON surveille la base de données lors de son démarrage, puis au cours de son
fonctionnement.
• Le fonctionne de ce processus est automatique, aucune action de l’adminsitrateur de la
base de donnees n’etant requise. C’est l’un des points forts d’oracle.
Le processus d’arriere plan (PMON)
• PMON (Processus Monitor)
• Le processus de surveillance PMON est un processus obligatoire qui est affecté à la récupération des
processus utilisateurs défaillants. Il libère le cache de blocs de données ainsi que les ressources qui étaient
exploitées par l’utilisateur, telles que les verrous, afin de les mettre à disposition d’autres utilisateurs.
• Nettoie les transactions défaillantes, comme celle d ’un poste client arrêter brutalement durant une transaction
(zonez allouées libérées, les verrous posés sont supprimés, les ressources affectées sont annulées).
• A l’instar du processus de surveillance SMON (System Monitor), le processus de surveillance PMON s’active
régulièrement pour se rendre compte si on a besoin de ses services.
• Le rôle de PMON est très important si vous utilisez un système comportant de nombreux utilisateurs ou
encore si vous effectuez des requêtes lourdes. Chaque connexion à une base Oracle consomme quelques
méga-octets de mémoire et du temps processeur. Si un utilisateur arrête brutalement sa machine ou si la
connexion réseau est perdue au cours d’une longue requête SQL, un ensemble de ressources peut ainsi être
bloqué inutilement si PMON ne détecte pas et ne nettoie pas les transactions anormalement interrompues.
AUTRES PROCESSUS
• RECO Les transactions distribuées nécessite un « COMMIT » à deux phases. Le COMMIT dans une base
de données doit être coordonnée avec le COMMIT correspondant dans une la deuxième base de
donnée; ainsi si l’un est annulé, le deuxième doit être annulé pour préserver la cohérence des
données. Le COMMIT à deux phases préparent chaque BD en écrivant les journaux dans les fichiers de
journaux (la première phase), et une fois que cela est confirmé, la transaction est signalée comme
étant accomplie dans toutes les BDs.
• MMON Le processus qui a été introduit avec la version Oracle 10g est le processus nécessaire pour
l’auto-controle et l’auto-reglage de la BD. L’instance de base de données collecte un grand nombre de
statistiques sur l’activité et les performances. Ces statistiques sont accumulées dans la SGA et elles
peuvent être interrogées par des requêtes SQL. MMON capture régulièrement les statistiques du SGA
et le transcrit dans le dictionnaire de données où elles peuvent être conservées indéfiniment (alors
que par défaut elles sont conservées pendant huit jours seulement). Chaque fois que MMON collecte
un ensemble de statistiques, un cliché (snapshot), il lance également le moniteur de diagnostic
automatique de la base de données (Automatic Database Diagnostic Monitor).
AUTRES PROCESSUS
• MMNL est un processus qui aide MMON. Il y’a des moments ou la frequence prevue
par le processus MMON n’est pas suffisante. Par exemple, les informations
statistiques accumulées dans le SGA sont ecrites par MMON toutes les heures. Si la
mémoire tampon utilise pour accumuler ces statistiques est remplie avant, MMNL
prendra la responsabilite d’ecrire les donnees sur disque.
• MMAN ce processsus a été introduit dans Oracle 10g, et il permet de gérer
automatiquement le dimensionnement automatique du SGA. A partir d’Oracle 11g,
la gestion de la mémoire va plus loin: le DBA fixe la limite totale de mémoire pour la
BD; ainsi le processus MMAN gere automatiquement le redimensionnement
automatique du SGA, et egalement la demande de la mémoire pour les session PGA.
L’automatisation de la mémoire est l’une des grandes avancees techniques des
dernieres versions d’Oracle. Elle permet d’automatiser une grande partie des taches
des DBA et de donner d’énormes avantages en termes performances et d’utilisation
des ressources.
AUTRES PROCESSUS
• D000 Dans un environnement de serveur partage, lorsqu'une requête utilisateur est
reçue, le processus répartiteur D000 (dispatcher) l’examine puis le place dans une file
d’attente commune. Un dispatcher peut prendre en charge plusieurs connexions au
moyen de circuits virtuels qui sont des portions de mémoires partagée contenant les
informations nécessaires pour communiquer avec chaque client. Il place ces circuits
sur la file de requêtes commune à laquelle accèdent les processus serveur.
AUTRES PROCESSUS
• CJQ0 et J000 Les processus permettent de gérer les taches planifiées sur le système.
Le coordonnateur de la file d’attente des travaux CJQn surveille la file d’attente et
démarre un ou plusieurs processus Jnnn pour l’execution des travaux.
• QMNC et Q000 Le gestionnaire de file d’attente QMNC surveille les files d’attente
dans la base de données et assigne les processus Qnnn pour le traitement des
messages vers et à partir de ces files d’attente. Les files d’attente peuvent être créées
par des programmeurs (comme un moyen de session de communication) et sont
également utilisées en interne. Par exemple, l’utilisation des files d’attente pour
stocker les transactions qui doivent être propagées à des bases de données distantes.
• RVWR Le processus « Recovery Writer » écrit les informations de récupération sur le
disque lorsque la fonctionnalité de « Flashback Database » est mise en œuvre.
• CTWR Le processus « Change Tracking Writer » conserve la trace des blocs modifies
pour faciliter les sauvegardes incrémentales à l’aide de l’utilitaire de sauvegarde
RMAN.
Le système de fichiers d’Oracle
 Structure de base de données Oracle
• Physiquement, une base de données Oracle est composée d'un
certain nombres de fichiers :
• des Fichiers de données
• des fichiers REDO LOG
• des fichiers de contrôle
• des fichiers d'Archivage
(si fonctionnement avec Archives)
 Module 4: Les différents fichiers d’Oracle

• Le fichier de parametre (.ora)

• Les fichiers de données (dont l'extension est .dbf)
• Les fichiers Redo Log (dont l'extension est .rdo ou .log)
• Les fichiers de contrôle (dont l'extension est .ctl).
 Les différents fichiers d’Oracle
Une base de données Oracle nécessite au minimum :
- un fichier de données
- deux fichiers redo Log
- et un fichier de contrôle
 Le fichier de paramètres

• Contient le mode de fonctionnement de l'instance et des indicateurs pour la base de

donnees :
• Son nom, DB_NAME
• La taille SGA, SGA_TARGET
• L'emplacement du ou des fichiers de controle...
• Il y a plus de 340 parametres dans Oracle
• Tous ont une valeur par defaut
• La valeur precisee dans le fichier de parametres surcharge la valeur par defaut.
• Le fichier de parametre peut etre :
• texte → pfile
• binaire → spfile
• Le spfile permet de modifier certains parametres, par la commande alter system set, sans devoir
redémarrer l'instance.
 Les fichiers Redo-Log
• Les fichiers Redo-log contiennent l'historique des modifications
apportées à la base de données Oracle. Ces fichiers de journalisation
enregistrent les modifications successives de la base de données afin
de pouvoir restaurer la base de données en cas de défaillance d'un
disque dur. Ainsi le cas échéant, la base de données Oracle est à
même de simuler l'ensemble des commandes n'ayant pas été
sauvegardées pour rétablir le contenu de la base de données.
 Les fichiers Redo-Log
• Au même titre que les fichiers de données, les fichiers Redo-log sont
dans un format propriétaire Oracle et l'écriture dans ces fichiers est
assurée par le processus LGWR (Log Writer).
• Oracle propose également un mode archivage permettant la
sauvegarde du fichier Redo-log avant sa réutilisation pour restaurer la
base. Si ce mode n'a pas été activé, le contenu du fichier Redo Log est
supprimé après utilisation.
• Enfin ces fichiers peuvent être multiplexés afin de fournir un
maximum de sécurité.
 Les fichiers Redo-Log
• Le tampon des journaux de reprise « buffer redo log » est généralement utilse par tous les
processus serveur qui modifient les données ou la structure d ’une ou plusieurs tables. Chaque
enregistrement dans le tampon des journaux de reprise est une information qui concerne la
modification d’un seul bloc.
• L’enregistrement contient un ensemble de vecteurs de modification du bloc concerné par la
modification, ainsi que l’identificateur de transaction. Ainsi lorsque vous effectuez la mise à jour
d’un enregistrement, vous modifiez le bloc de la table, vous insérez l’ancienne image du bloc dans
le segment UNDO et vous modifiez également la table transaction du segment UNDO. Il convient
aussi de remarquer que chaque fois que vous insérez ou modifiez un enregistrement d’une table,
vous insérez ou modifiez les index correspondants et vous aurez autant de blocs UNDO à traiter.
• Une fois que la transaction a été validée par un COMMIT, oracle lui assigne un System Change
Number (SCN) pour identifier les enregistrements qui font partie de cette transaction.
• Le SCN est seulement une valeur numérique séquentielle qui permet de déterminer l’etat
d’avancement des mise à jour en temps, et beaucoup plus fiable que l’utilisation de la date et
l’heure.
 Les fichiers Redo-Log
• Au même titre que les fichiers de données, les fichiers Redo-log sont
dans un format propriétaire Oracle et l'écriture dans ces fichiers est
assurée par le processus LGWR (Log Writer).
• Oracle propose également un mode archivage permettant la
sauvegarde du fichier Redo-log avant sa réutilisation pour restaurer la
base. Si ce mode n'a pas été activé, le contenu du fichier Redo Log est
supprimé après utilisation. Enfin ces fichiers peuvent être multiplexés
afin de fournir un maximum de sécurité.
 Les fichiers Redo-Log
sont
• Les tampons des journaux est utilises de manière sequentielle et circulaire.
Le processus LGWR transcrit le contenu du tampon des journaux de reprise
sur disque lorsque survient l’un des évènements suivants:
• Toutes le 3 secondes
• Lors d’un commit
• Chaque fois q’un volume d’information correspond au tier de la taille du tampon des
journaux de reprise a été écrit dans ce buffer. Egalement chaque fois qu'un volume 1
M est rempli. Cela ne signifie pas que le tampon des journaux de reprise ne sera
jamais rempli au-delà du tiers, mais simplement que le processus LGWR transcrit son
contenu des lors que le seuil du tiers est atteint.

• Lorsqu’il est déclenché par le processus DBWn

 Les fichiers Redo-Log
• Notion de groupe:
• Select group#, member from v$logfile;

• Création de groupe de fichiers journaux:

• ALTER DATABASE ADD LOGFILE GROUP nom_groupe SIZE 50M;
 Les fichiers de contrôle
• Ces fichiers permettent de stocker les informations sur l'état de la
base de données.
• Le fichier de contrôle contient les informations suivantes :
• Nom de la base de données
• Emplacement des fichiers de données
• Date et heure de création de la base
• L'emplacement des fichiers journaux (Redo-Log)
• Les fichiers de contrôle sont eux-mêmes repérés par le fichier des
parametres.
 Les fichiers de controle
• Liste des fichiers de contrôle:
• select * from v$controfile;
• Creation d’un fichier de contrôle
• alter system set controlfiles=‘myfile’;
• Initialisation d’un fichier de donnees
• alter system set db_create_file_dest;
• Initialisation d’un fichier de recuperation rapide (fichier de journaux
et de contrôle)
• alter system set db_create_online_log_dest _n=‘myfile’;
 Multiplexage du fichier de controle
• Chaque fichier de contrôle qui recense des informations sur tous les
autres fichiers essentiels de la base. En raison de son importance,
Oracle permet de multiplexer ce fichier pour avoir plusieurs copies,
afin de parer à toute corruption ou perte de fichier.

• Il est conseillé de faire fonctionner la BD avec au moins deux fichiers

de contrôle, si possible sur des disques differents
 Multiplexage du fichier de controle
• Le multiplexage des fichiers de contrôle peut être mis en œuvre lors de la
création de la BD, en spécifiant la liste des fichiers de contrôle souhaités
dans le paramètre « CONTROL_FILES ».
• Le multiplexage peut aussi être mis en œuvre ultérieurement

• select name from v$controlfile;

• alter system set controlfiles= ‘fichier1’,’fichier2’ scope=spfile;
• shutdown immediate
• copy ‘fichier1’ ‘fichier2’
• startup
• select name from v$controlfile;
 Les fichiers de donnees
• Ces fichiers contiennent l'ensemble des données de la base (les tables, les
vues,
• les procédures stockées, ...). Il sont codés dans un format propriétaire.
Seule les
• requêtes SQL permettant un accès implicite à ces fichiers.
• Les fichiers de données contiennent des informations de deux types :
• Le dictionnaire de données et de travail
• Les données des utilisateurs
• La lecture de ces fichiers de données est faite à l'aide des processus
utilisateurs tandis que l'écriture est assuré par le processus DBWR
(Database Writer).
 Les tablespaces
• Une base de données est composée d'unités logiques : les tablespaces;
• Une base peut être décomposée en tablespaces : partitions logiques contenant
un ou plusieurs fichiers.
• Un fichier appartient à 1 et 1 seul tablespace.
Un tablespace peut s'étendre soit par ajout (on-line) d'un fichier, soit par auto-
extension DU fichier du tablespace.
• Pour chaque base, il y a au moins un tablespace d'origine appelé SYSTEM, qui
contient le dictionnaire des données (toutes les informations sur la base)
• un tablespace peut être actif (online) ou désactivé (offine)
• Un tablespace correspond a un ou plusieurs fichiers physiques;
• une table ou ses index sont créés dans un tablespace , qui peut s‘étendre sur
plusieurs fichiers physiques..
Les tablespaces
Les tablespaces
Tablespaces et fichiers de données
•Oracle stocke les données logiquement dans les
tablespaces et physiquement dans les fichiers de
données.
• Un tablespace :
• ne peut appartenir qu’à une seule base de données à la fois,
• est composé d’un ou de plusieurs fichiers de données,
• est divisé en unités logiques de stockage.
• Un fichier de données : Base de données
• ne peut appartenir qu’à un
tablespace et qu’à une seule Tablespace
• base de données,
• est un référentiel pour les Fichiers de
• données d’objet de schéma. données
 Types de tablespace
• Le tablespace SYSTEM :
• est créé en même temps que la base de données,
• contient le dictionnaire de données,
• contient le segment d'annulation SYSTEM.
• Le tablespace non SYSTEM
• sépare les segments,
• facilite l'administration de l'espace,
• gère la quantité d'espace allouée aux utilisateurs.
 Créer des tablespaces
•Un tablespace est créé à l'aide de la commande :
•CREATE TABLESPACE
CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/userdata01.dbf' SIZE 100M
AUTOEXTEND ON NEXT 5M MAXSIZE 200M;
Gestion de l'espace dans les tablespaces
• Tablespace géré localement :
• Extents libres gérés dans le tablespace
• Un bitmap est utilisé pour enregistrer des extents libres
• Chaque bit correspond à un bloc ou à un groupe de blocs
• La valeur des bits indique si ceux-ci sont disponibles ou
utilisés
• Tablespace géré au moyen du dictionnaire :
• Les extents libres sont gérés par le dictionnaire de
données.
• Les tables appropriées sont mises à jour lorsque les
extents sont alloués ou libérés.
 Tablespaces gérés localement
• La contention au niveau des tables du dictionnaire
de données est réduite.
• Aucune annulation n'est générée lors de l'allocation
ou de la libération d'espace.
• Aucune fusion n'est requise.

CREATE TABLESPACE userdata

DATAFILE '/u01/oradata/userdata01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
 Tablespaces gérés au moyen
du dictionnaire
• Les extents sont gérés dans le dictionnaire de
données
• Chaque segment stocké dans le tablespace peut
posséder une clause de stockage différente
• Une fusion est requise

CREATE TABLESPACE userdata

DATAFILE '/u01/oradata/userdata01.dbf'
SIZE 500M EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE
(initial 1M NEXT 1M PCTINCREASE 0);
 Tablespace d'annulation
• Il permet de stocker des segments d'annulation.
• Il ne peut contenir aucun autre objet.
• Les extents sont gérés localement.
• Il ne peut être utilisé qu'avec les clauses DATAFILE
et EXTENT.

CREATE UNDO TABLESPACE undo1

DATAFILE '/u01/oradata/undo01.dbf' SIZE 40M;
 Tablespaces TEMPORARY
• Ils sont utilisés pour les opérations de tri
• Ils ne peuvent pas contenir d'objets permanents
• La gestion locale des extents est recommandée
CREATE TEMPORARY TABLESPACE temp
TEMPFILE '/u01/oradata/temp01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4M;
Tablespace TEMPORARY par défaut
• Définit un tablespace TEMPORARY par défaut
correspondant à la base de données.
• Permet d'effectuer des suppressions à l'aide du
tablespace SYSTEM pour stocker des données
temporaires.
• Un tablespace TEMPORARY peut être créé à l'aide de :
• CREATE DATABASE
– Géré localement
• ALTER DATABASE

ALTER DATABASE
DEFAULT TEMPORARY TABLESPACE temp;
 Créer un tablespace TEMPORARY
par défaut
• Pendant la création de la base de données :

CREATE DATABASE DBA01

LOGFILE
GROUP 1 ('/$HOME/ORADATA/u01/redo01.log') SIZE 100M,
GROUP 2 ('/$HOME/ORADATA/u02/redo02.log') SIZE 100M,
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
DATAFILE '/$HOME/ORADATA/u01/system01.dbf' SIZE 325M
UNDO TABLESPACE undotbs
DATAFILE '/$HOME/ORADATA/u02/undotbs01.dbf' SIZE 200
DEFAULT TEMPORARY TABLESPACE temp
TEMPFILE '/$HOME/ORADATA/u03/temp01.dbf' SIZE 4M
CHARACTER SET US7ASCII
Créer un tablespace TEMPORARY
par défaut

• Une fois la base de données créée :

ALTER DATABASE
DEFAULT TEMPORARY TABLESPACE default_temp2;

• Pour trouver le tablespace TEMPORARY par défaut

de la base de données, interrogez
DATABASE_PROPERTIES.

SELECT * FROM DATABASE_PROPERTIES;

 Restrictions relatives au tablespace
TEMPORARY par défaut

•Les tablespaces TEMPORARY par défaut ne peuvent pas être :

• supprimés tant qu'un nouveau tablespace par défaut n'est pas disponible,
mis hors ligne,
• transformé en tablespace permanent.
Tablespaces accessibles en lecture seule
• Utilisez la commande suivante pour placer un
tablespace en lecture seule.
ALTER TABLESPACE userdata READ ONLY;

• Crée un point de reprise.

• Ces données sont disponibles pour les opérations de
lecture uniquement.
• Il est possible de supprimer des objets des tablespaces
Mettre un tablespace hors ligne
• Non disponible pour l'accès aux données
• Tablespaces ne pouvant pas être mis hors ligne :
• Tablespace SYSTEM :
• Tablespaces contenant des segments d'annulation actifs
• Tablespace TEMPORARY par défaut
• Mettre un tablespace hors ligne :

ALTER TABLESPACE
• Mettre userdata
un tablespace OFFLINE;
en ligne :

ALTER TABLESPACE userdata ONLINE;

 Modifier les paramètres de stockage
• Utiliser la commande ALTER TABLESPACE pour modifier les paramètres de
stockage :
ALTER TABLESPACE userdata MINIMUM EXTENT 2M;

ALTER TABLESPACE userdata

DEFAULT STORAGE (INITIAL 2M NEXT 2M
MAXEXTENTS 999);

• Les paramètres de stockage des tablespaces gérés localement ne peuvent pas

être modifiés.
 Redimensionner un tablespace
•Un tablespace peut être redimensionné en :
• modifiant la taille d'un fichier de données :
• automatiquement à l'aide de AUTOEXTEND
• manuellement à l'aide de ALTER TABLESPACE
• ajoutant un fichier de données à l'aide de ALTER TABLESPACE
 Activer l'extension automatique
des fichiers de données
• Les fichiers peuvent être redimensionnés automatiquement à l'aide des
commandes suivantes :
• CREATE DATABASE
• CREATE TABLESPACE
• ALTER TABLESPACE … ADD DATAFILE
• Exemple :
CREATE TABLESPACE user_data
DATAFILE
'/u01/oradata/userdata01.dbf' SIZE 200M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M;

• Interrogez la vue DBA_DATA_FILES pour déterminer si AUTOEXTEND est

activé.
 Redimensionner manuellement
un fichier de données
• Augmentez ou réduisez manuellement la taille d'un fichier de données à l'aide de
ALTER DATABASE.
• Redimensionner un fichier de données ajoute de l'espace sans ajouter de fichier de
données.
• Le redimensionnement manuel d'un fichier de données requiert l'utilisation de
l'espace libre d'une base de données.
• Exemple :

ALTER DATABASE
DATAFILE '/u03/oradata/userdata02.dbf'
RESIZE 200M;
 Ajouter des fichiers de données
à un tablespace
• Augmente l'espace alloué à un tablespace en ajoutant des fichiers de
données.
• La clause ADD DATAFILE permet d'ajouter un fichier de données.
• Exemple :

ALTER TABLESPACE user_data

ADD DATAFILE '/u01/oradata/userdata03.dbf'
SIZE 200M;
Méthodes de déplacement des fichiers
de données
• ALTER TABLESPACE
• Le tablespace doit être hors ligne.
• Les fichiers de données cible doivent exister.
ALTER TABLESPACE userdata RENAME
DATAFILE '/u01/oradata/userdata01.dbf'
TO '/u02/oradata/userdata01.dbf';
• Etapes permettant de renommer un fichier
• Mettez le tablespace hors ligne.
• Utilisez la commande appropriée du système d'exploitation pour
déplacer ou copier les fichiers.
• Exécutez la commande ALTER TABLESPACE RENAME DATAFILE.
• Mettez le tablespace en ligne.
• Au besoin, utilisez la commande appropriée du système
d'exploitation pour supprimer le fichier.
Méthodes de déplacement des fichiers
de données
• ALTER DATABASE
• La base de données doit être montée.
• Le fichier de données cible doit exister.

ALTER DATABASE RENAME

FILE '/u01/oradata/system01.dbf'
TO '/u03/oradata/system01.dbf';
 Supprimer des tablespaces
• Un tablespace ne peut pas être supprimé :
• s'il s'agit du tablespace SYSTEM,
• s'il possède des segments actifs.
• INCLUDING CONTENTS supprime les segments
• INCLUDING CONTENTS AND DATAFILES
supprime les fichiers de données
• CASCADE CONSTRAINTS supprime les
contraintes d'intégrité référentielle
DROP TABLESPACE userdata
INCLUDING CONTENTS AND DATAFILES;
Gérer des tablespaces à l'aide d'OMF

• Définissez le paramètre DB_CREATE_FILE_DEST

en utilisant l'une des méthodes suivantes :
• Fichier de paramètres d'initialisation
• Définition dynamique à l'aide de la commande ALTER
SYSTEM

ALTER SYSTEM SET

db_create_file_dest = '/u01/oradata/dba01';
• Lorsque vous créez le tablespace :
• le fichier de données est automatiquement créé dans
DB_CREATE_FILE_DEST,
• la taille par défaut est de 100 Mo,
• La valeur UNLIMITED est affectée à AUTOEXTEND.
Gérer des tablespaces à l'aide d'OMF
• Créer un tablespace OMF
CREATE TABLESPACE text_data DATAFILE SIZE 20M;
• Ajouter un fichier de données OMF à un tablespace existant

• Modifier
ALTER de manière
TABLESPACE dynamique ADD
text_data l'emplacement
DATAFILE;du fichier
par défaut :

ALTER SYSTEMunSET
• Supprimer tablespace supprime également des fichiers
db_create_file_dest = '/u01/oradata/dba01';
du système d'exploitation.
 Obtenir des informations
sur les tablespaces
•Vous pouvez obtenir des informations sur les tablespaces et les fichiers de
données en interrogeant les éléments suivants :
• Tablespaces :
• DBA_TABLESPACES
• V$TABLESPACE
• Informations sur le fichier de données :
• DBA_DATA_FILES
• V$DATAFILE
• Informations sur les fichiers temporaires :
• DBA_TEMP_FILES
• V$TEMPFILE
 Quelques exemples SQL pour les tablespaces
et les fichiers
• rem creation d'un tablespace nommé RBS contenant un fic de 10MO et des EXTENTS
de 1MO
CREATE TABLESPACE RBS DATAFILE 'E:\orant\database\TEST\Rbs1TEST.ora' SIZE 10M
DEFAULT STORAGE ( INITIAL 1024K NEXT 1024K PCTINCREASE 0);
ALTER TABLESPACE toto OFFLINE;
• rem changement des parametres d'un tablespace existant
ALTER TABLESPACE SYSTEM DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1
MAXEXTENTS 300 PCTINCREASE 1);
• rem Ajout ajout d'un ficheir auto exyensible jusqu'a 100 MO
ALTER TABLESPACE toto ADD DATAFILE 'E:\orant\database\TEST\TEST.ora' SIZE 10M
AUTOEXTEND ON NEXT 5M MAXSIZE 100M;
• rem passage en AUTO extension d'un fichier de tablespace existant
ALTER DATABASE DATAFILE 'E:\orant\database\TEST\Usr1TEST.ora' AUTOEXTEND ON;