Il y a essentiellement deux catégories de fichiers ‘oracle’ :
- ceux correspondants au logiciel lui même (le SGBDR)
- ceux correspondant à la (aux) bases de données
Oracle recommande une structure de répertoire et de fichiers standards pour l’une et l’autre catégorie. Cette organisation standard est baptisée O.F.A (Oracle Flexible Architecture)
OFA Unix :
Pour la racine d’installation du logiciel ($ORACLE_HOME ou %ORACLE_HOME% :
/u01/app/oracle/product/10.1.0/db_1et pour les fichiers et leurs ’sauvegardes’ :
/oradata//dbf Tablespace datafiles.
/oradata//recovery1 Archive, Control, Flashback et Redo files.
/oradata//recovery2 Multiplexed: Archive, Control and Redo files.
/oradata//rman RMAN backup files.
/oradata//exports ExportDataPump files.
OFA Windows
ORACLE_HOME directories
oradata directories (for the physical files of the database)
admin directories (for database administration files).
dbump background process trace files
cdump core dump files
create database creation files
exp database export files
pfile initialization parameter file
background process trace files core dump files database creation files database export files initialization parameter files
Les principaux fichiers physique d’une base de données
… apparaissent ci-après
le fichier de contrôle
Le control file contient une ‘cartographie’ de la base de données physique, et principalement les emplacements, noms et statuts des fichiers de données et des fichiers journaux.
Ce fichier est indispensable au montage et à l’ouverture de la base. De ce fait il est vivement conseillé d’en utiliser plusieurs versions simutanées ‘en miroir’.
Cela est possible grace au paramètre d’initialisation CONTROL_FILES
exemple
# Fichier init.ora
#
CONTROL_FILES = (disque1:CTL1.DBF, disque2:CTL2.DBF, disque2:CTL3.DBF)
Les fichiers de données
Les fichiers de données contiennent … les données proprement dites (essentiellement les tables et leurs lignes),
mais aussi les autres objets Oracle connexes aux tables : index, vues, synonymes, database links, procédures stockées, etc.).
note : Il aurait été plus judicieux de les appeler autrement, mais je traduis le terme Oracle ‘data file’…
Suivant les systèmes d’exploitation (ou la version d’Oracle) ils ont l’extension ‘.dbf’ ou ‘.ora’ ou ‘.dbs’
Ce qui n’est pas vraiment des données…dans les fichiers de données :
* Les Vues , synonymes, database links peuvent être considérés comme des données puisque “pointent” sur des données dans des tables.
* Les indexes et les clusters n’en sont évidemment pas, mais plutôt des “accélérateurs” de traitement
* Les procédures stockées (et fonctions et packages) non plus, mais des morceaux de programmes (PL.SQL) stockés dans la base.
et pire encore :
* les Images avant ou “rollback segments” qui sont des zones temporaires qui permettent de “revenir en arrière” sur des mises à jour, ou en d’autres termes d’annuler des transactions
Pourtant tout ce petit monde est stocké dans les data files !
Les fichiers journaux
Les fichiers journaux ou LOGFILES ou REDOLOG FILES ou REDOLOGS
servent à mémoriser toutes les modifications (validées ou non) faites sur la base, à des fins de reprise en cas de perte de données physiques.
Ils ont en général l’extension ‘.LOG’
La journalisation (assurée par le process LGWR) est un mécanisme permanent et obligatoire d’Oracle, pour assurer un minimum de sécurité des données.
Cycle des Logfiles
Les fichiers journaux appartiennent à des groupes, et sont remplis de manière séquentielle et circulaire (quand on a fini de remplir le log du groupe courant, on attaque le log du groupe suivant. Quand on arrive au dernier, on recommence à écrire dans le premier…).
C’est pour ça qu’il faut au minimum 2 (groupes de) redo log.
lorsqu’on boucle un cycle, on perd les premières journalisations qui ont été faites et l’on ne saura pas toujours restaurer la totalité des données en cas de problème. C’est pour ca qu’on peut “archiver” tout l’historique des redo logs, en utilisant l’archivage optionnel.
Par sécurité on peut multiplexer ou “mirrorer” l’écriture dans plusieurs redo log en même temps (sur des disques différents bien sur).
Dans ce cas on a plusieurs fichiers par groupe, et LGWR écrit tous les fichiers du groupe courant en même temps.
multiplexage des journaux (redo log files)
On a vu que l’écriture dans les redo logs files est circulaire.
Au minimum une base doit contenir 2 groupes de un fichier.
Pour permettre l’écriture simultanée de plusieurs redo logs et ainsi les sécuriser, on crée 2 fichiers ou plus par groupe.
exemple : le minimum, 2 groupes contenant chacun un fichier (pas de multiplexage donc…)
CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’) SIZE 500K;
un peu mieux, LGWR va écrire simultanément dans les 2 fichiers du groupe courant
CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’, ‘e:dataoratest_log1b’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’, ‘e:dataoratest_log2b’) SIZE 500K;
protection max : ceinture ET bretelles (on écrit dans 3 fichiers en même temps)
CREATE DATABASE test DATAFILE ‘d:dataoratest_system’ SIZE 10M
LOGFILE GROUP 1 (’d:dataoratest_log1a’, ‘e:dataoratest_log1b’ , ‘f:dataoratest_log1b’) SIZE 500K,
GROUP 2 (’d:dataoratest_log2a’, ‘e:dataoratest_log2b’ , ‘f:dataoratest_log1b’) SIZE 500K;
Si on veut augmenter le temps de rebouclage du cycle d’écriture, ou en d’autres termes augmenter le délai avant écrasement éventuel du contenu du 1er journal, on peut rajouter des groupes supplémentaires…
