Gestion Structures Stockage

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 26

4

Gestion des structures de stockage


Niveaux de stockage

La structure de stockage au sein d’une base de données oracle se compose de


deux niveaux:

• Structures physiques de stockage


• Fichiers de données
• Fichiers de journalisation (Redo Log)
• Fichiers de contrôles
• Autres fichiers
• Structures logiques de stockage
• Tablespaces
• Segment
• Extent
• Bloc de données
Structures physiques de stockage

Se compose de fichiers du système d’exploitation sur lequel est située la base de


données:

• Fichiers de données
• Stocke le dictionnaire de données, les objets utilisateurs…
• Fichiers de journalisation(Redo Log)
• Stocke toutes les modifications apportées à la base de données (pour la
reconstruire en cas de panne)
• Fichiers de contrôle
• contient les informations nécessaires à la mise à jour et à la vérification
de l'intégrité des données.
• Autres fichiers
• fichier de paramètres, fichier mot de passe, fichiers de reprise archivés
etc.
Le dictionnaire de données

Le dictionnaire de données est un ensemble de tables et de vues où est stockée


l’information sur la structure logique et physique de la BDD:

• Les utilisateurs des base de données


• Noms et caractéristiques des objets stockés dans la base de donnée
• Contraintes d’intégrités
• Ressources physiques allouées à la base
• D’autres informations
Il est créé à la création de la BDD, mis à jour au fur et à mesure de la création d’objets,
et ne doit jamais être modifié directement à l'aide d'une instruction SQL.

Il possède deux composants:

• Les tables de base


• Les vues du dictionnaire de données

La vue DICTIONARY du dictionnaire de données contient le nom et la description de


toutes les tables et vues du dictionnaire :
Les tables de base du dictionnaire de données

Les tables de base sont les tables réelles d'Oracle qui stockent les informations sur
une base de données.

Ces tables sont créées avec le script sql.bsq Ce script est stocké dans le répertoire
ORACLE_HOME\rdbms\admin. Les informations stockées dans les tables de base
sont lues et écrites par le serveur Oracle. Ces informations sont rarement
accédées directement par les utilisateurs car ces informations sont normalisées et
stockées sous une forme encodée.

Les utilisateurs ou administrateurs de bases de données ne doivent pas utiliser de


commandes LMD, telles que INSERT, UPDATE et DELETE, pour mettre à jour les
tables de base directement, à l'exception de la table de trace d'audit lorsque la
fonctionnalité d'audit est utilisée.
Les vues du dictionnaire de données

Les tables de base sont accessibles par le biais de vues prédéfinies sur ces tables:

• Elles sont crées par le script catalog.sql


• Elles simplifient et résument les informations contenues dans les tables de
base
• Elles stockent également ces informations sous une forme que les utilisateurs
de la base de données peuvent lire facilement.
• Elles permettent au DBA de gérer et d’administrer la base de données.

Les utilisateurs ont accès à ce dictionnaire éventuellement en lecture à travers 3


catégories de vues:

• USER_<vues> : Vues sur les objets créé par un utilisateur


• ALL_<vues>: Vues sur les objets auxquels un utilisateur a accès (pas
nécessairement qu’il a créés)
• DBA_<vues>: Vues sur tous les objets de la base de données de tous les
utilisateurs accessible par les administrateur(DBA)
Exemples

Vue Description
Dictionary Vues générales.
Dict columns
Dba_tables Informations sur les objets tels
Dba_objects que les tables, les contraintes,
Dba_constraints les colonnes ,etc.
Dba_tab_columns
Dba_users Informations sur les rôles et le
Dba_roles privilèges des utilisateurs
Dba_extents Informations sur l’allocation
Dba_segments d’espace pour les objets de BD
Dba_data_files Informations sur la strucuture
Dba_tablespaces générales de la BD
Dba_audit_trail Informations d’audit
Dba_audit_objetc
Exemples

Voici quelques exemples de consultation de vues du dictionnaire de données:

Select * from user_tables;

Permet de lister les tables qui ont été créées dans le schéma de l’utilisateur
lançant la requête

Select * from dba_users where account_status=‘OPEN’;

Permet de lister les utilisateurs de la base qui sont actuellement autorisés à se


connecter.
DESC dba_indexes;

Permet de lister les colonnes de la vue DBA_INDEXE


Fichiers de données (Data files)

Les fichiers de données ou Data files sont utilisés pour stocker le dictionnaire de
données et les objets de la base de données.

Ces fichiers sont souvent très volumineux. Et les données dans le buffer de
données et le dictionnaire cache sont récupérés de ces fichiers.

Pour Lister les fichiers de données d’une BD avec leurs détails il suffit d’exécuter la
commande suivante:
Select * from dba_data_files;
Fichiers de journalisation(Redo Log)

Les fichiers de journalisation ou Redo log file permettent de journaliser les


transactions afin de garantir la reconstruction des données en cas de panne de la
base de données.

Chaque transaction est écrite de manière synchrone dans le tampon de


journalisation (redo log buffer), puis transférée dans les fichiers de journalisation
pour fournir un mécanisme de récupération.

Les fichiers de journalisation ne servent qu'à la récupération de données


Structure des fichiers de journalisation

L'administrateur de base de données peut configurer la base Oracle pour gérer


des copies de fichiers de journalisation en ligne afin d'éviter de perdre des
données en cas d'incident.
Le serveur Oracle nécessite au moins deux groupes de fichiers de journalisation
en ligne pour garantir un fonctionnement correct de la base de données
Un ensemble de copies identiques de fichiers de journalisation en ligne est
nommé Groupes de fichiers de journalisation en ligne

Chaque fichier de journalisation en ligne d'un groupe est nommé membre


Les membres d'un groupe portent tous le même numéro de séquence de journal
qui sert comme identifiant et ont tous
la même taille.
Mode de fonctionnement des Redo Log File

Le serveur Oracle enregistre de manière séquentielle toutes les modifications


apportées à la base de données dans le tampon de journalisation.
Les entrées de journalisation sont écrites par le processus LGWR dans l'un des
groupes de fichiers de journalisation, appelé groupe de fichiers de journalisation
en cours, dans les cas suivants :
• Lorsqu'une transaction est validée,
• Lorsqu'un tiers du tampon de journalisation est occupé,
• lorsque le tampon de journalisation contient plus d'un mégaoctet
d'enregistrements modifiés,
• Avant que le processus DBWn n'écrive les blocs modifiés du cache de
tampons (buffer cache) de la base de données dans les fichiers de données.

Le processus LGWR écrit de façon séquentielle dans les fichiers de journalisation


en ligne. Lorsque le groupe de fichiers de journalisation en ligne en cours est
complet, le processus LGWR passe au groupe suivant. On parle alors de changement
de fichier de journalisation.
Fichiers de contrôle

Le fichier de contrôle est un petit fichier binaire nécessaire au démarrage et au


bon fonctionnement de la base de données.
Chaque fichier de contrôle est associé à une seule base de données Oracle. Avant
l'ouverture d'une base, le fichier de contrôle est lu afin de déterminer si cette
base est opérationnelle et pour localiser l’emplacement des fichiers de données et
des fichiers de journalisation .
Ce fichier est constamment mis à jour par le serveur Oracle pendant l'utilisation
de la base de données. Il doit donc être accessible en écriture à chaque ouverture
de la base.
Si ce fichier est inaccessible, la base ne fonctionne pas correctement. Si toutes les
copies des fichiers de contrôle d'une base de données sont perdues, cette
dernière doit être récupérée pour être ouverte.
Le contenu du fichier de contrôle

Le fichier de contrôle contient les informations suivantes :


• Le nom de la base de données correspond au nom indiqué par le paramètre
d'initialisation DB_NAME,
• L'identificateur de la base de données est enregistré à la création de cette
dernière,
• L'horodatage de création de la base de données ,
• Le nom et l'emplacement des fichiers de données et des fichiers de
journalisation en ligne (online redo logs) associés sont mis à jour lors de l'ajout,
du changement de nom ou de la suppression de l'un de ces fichiers dans la
base de données,
• Le numéro de séquence du journal en cours est enregistré lors des
changements de fichier de journalisation.,
• L'historique de journalisation est enregistré lors des changements de fichier
de journalisation.
• Et bien d’autres informations…
Les informations sur le fichier de contrôle

Pour obtenir des informations sur le statut et l’emplacement des fichiers de


contrôle, on peut interroger les vues suivantes:

• V$CONTROLFILE: pour répertorier le nom et le statut de tous les fichiers de


contrôle associés à l’instance.
• SELECT * FROM V$CONTROLFILE;

• V$PARAMETER: le paramètre control_files permet de répertorier


l’emplacement de tous les paramètres.
• SELECT name, value from V$PARAMETER WHERE name =
'control_files';

• V$CONTROLFILE_RECORD_SECTION: fournit des informations sur les


enregistrements des différentes sections des fichiers de contrôle.
• SELECT type, record_size from V$CONTROLFILE_RECORD_SECTION;
Structures logiques de stockage

L’utilisateur, qu’il soit connecté par une application, ou directement à la BD par


SQL*Plus, ne voit que la structure logique de la BD, à aucun moment ne fait appel
aux fichiers physiques.

Le relation entre les tables et les données stockées dans le fichier physique se fait
par un objet logique appelé « tablespace ».

Les données d’une base Oracle sont mémorisées dans une ou plusieurs unités
logiques appelées tablespaces et physiquement dans des fichiers associés à ces
tablespaces.
Tablespace

• Un tablespace est la plus grande unité logique de stockage allouable dans


oracle.
• Un tablespace est composé d’au moins un fichier de données ayant une
existence physique(stocké sur disque dur). Ces fichiers sont des structures
physiques conformes au système d'exploitation sur lequel s'exécute le serveur
Oracle.
• Tout objet du schéma de base de données est crée dans un seul tablespace,
mais peut s’étaler sur plusieurs fichiers de données
Tablespace et fichiers de données

• Un tablespace:
• Ne peut appartenir qu’à une seule base de données,
• Est composé d’un ou de plusieurs fichiers de données,
• Est divisé en unités logiques de stockage.
• Un fichier de données
• Ne peut appartenir qu’à un tablespace et qu’à une seule base de données,
• Peut être stocké physiquement sur toutes les technologies de stockage
pris en charge par Oracle.
• Tout objet du schéma de base de données est crée dans un seul tablespace,
mais peut s’étaler sur plusieurs fichiers de données.
• Les tablespaces peuvent être activés (online) ou désactivés (offline)
individuellement pour d’éventuelles opérations de maintenance
Utilisation des Tablespaces

• Un tablespace est utilisé pour :


• Contrôler l’allocation d’espace et l’affectation de quotas aux utilisateurs,
• Contrôler la disponibilité des données par la mise online et offline,
• Distribuer le stockage des données sur plusieurs dispositifs,
• Conserver des volumes importants de données statiques sur des
dispositifs en lecture seule
• Exécuter des sauvegardes partielles
• Le nombre maximal de fichier par tablespace est 1023
• Le nombre maximal de tablespace par base de données est 64000
Tablespaces--Segments—Extents--Blocs

Les niveaux de stockages suivant dans un tablespace Oracle sont les segments, composés
d'extents, composés de bloc de données Oracle.

Segment: L'espace occupé par un objet dans un tablespace est appelé segment. Un segment est
un ensemble d'extents alloués et appartient à un tablespace. Lorsque qu'un segment est crée, une
ou plusieurs extensions lui sont attribuées:

• Segments de données ou Segments de tables.: Espace occupé par les tables


• Segments d'index: Espace occupé par les index ,
• Segments d'annulation: Espace temporaire utilisé pour stocker les données permettant
d'annuler une transaction,
• Segments temporaire: Espace temporaire créé par la base Oracle lorsque l'exécution
d'une instruction SQL requiert une zone de travail temporaire, notamment lors d'un tri

Extent: Un extent ou extension est un ensemble de blocs contigus dans l'organisation logique
d'une base de données Oracle. Il est composé d'un nombre de blocs de données.

Bloc: Le bloc de données Oracle est le niveau le plus fin. Il correspond à un nombre d'octets
spécifique d'espace physique sur le disque.
Tablespaces--Segments—Extents--Blocs
Types des Tablespaces

Le serveur Oracle accepte deux types de tablespace : le tablespace SYSTEM et tous les
autres tablespaces

• Le tablespace SYSTEM :

• Est créé en même temps que la base de données,


• Doit exister dans toutes les bases de données,
• Contient le dictionnaire de données,
• Ne doit pas contenir de données utilisateur, bien que cela soit possible,

• Les tablespaces non SYSTEM :

• Facilitent l'administration de la base de données,


• Séparent les segments d'annulation, les segments temporaires, les segments de
données d'application et les segments d'index d'application,
• Séparent les données en fonction des besoins de sauvegarde,
• Séparent les données dynamiques des données statiques,
• Gèrent la quantité d'espace allouée aux objets utilisateur,
Gestion d’espace dans les Tablespaces

Les tablespaces affectent de l'espace dans les extents. Lors de leur création, le DBA peut
choisir l'une ou l'autre des méthodes de gestion de l'espace libre et utilisé suivantes:

• Tablespaces gérés localement (option par défaut à partir de la version 8i) :

• Les extents sont gérés dans le tablespace via des bitmaps,


• Chaque bit du bitmap correspond à un bloc ou à un groupe de blocs,
• Lorsqu'un extent est alloué ou libéré pour être réutilisé, le serveur Oracle modifie
les valeurs bitmap pour indiquer le nouveau statut des blocs. Cette méthode est
utilisée par défaut dans Oracle11g.

• Tablespaces gérés au moyen du dictionnaire:


• Les extents sont gérés à l'aide du dictionnaire de données,
• Le serveur Oracle met à jour les tables appropriées dans le dictionnaire de données
chaque fois qu'un extent est alloué ou libéré,
Création de tablespaces

Un tablespace est créé à l’aide de la commande:

CREATE TABLESPACE nom


DATAFILE: spécifie le ou les fichiers de données liés au tablespace
[ONLINE|OFFLINE]: rend le tablespace disponible/indisponible immédiatement après la
création.
[PERMANENT|TEMPORARY]: spécifie que le tablespace peut être utilisé pour contenir
des objets permanents ou temporaires.
[LOGGING|NOLOGGING] : option par défaut qui spécifie que toutes les tables, indexes et
partitions dans le tablespace génèrent des infos de redo log | pas de génération.
[EXTENT MANAGEMENT [DICTIONARY |LOCAL : géré localement ou via le dictionnaire
[AUTOALLOCATE |UNIFORM [SIZE valeur [K|M]]]]]: la taille des extents est gérée par
oracle, c’est l’option par défaut | une taille des extents est uniformément définie en k octets
ou en M octets . La taille par défaut est de 1 méga Octet
[DEFAULT clause _ storage ]: définit les paramètres de stockage par défaut pour tous les
objets créés dans le tablespace (cette option est dédiée pour les tablespaces gérés par le
dictionnaire)
[BLOCKSIZE valeur [K]]: définit la taille des blocs de données.
Quelques exemples

Exemple 1:

CREATE TABLESPACE TP1


DATAFILE '/u02/app/oracle/oradata/ORCL/tp1.dbf‘
SIZE 300M;

Exemple 2:

CREATE TABLESPACE TP2 DATAFILE '/u01/aporpod/TP2.dbf‘ SIZE 200M EXTENT


MANAGEMENT LOCAL UNIFORM size 2M ONLINE;
Tablespace temporaires et d’annulation

Tablespace temporaire (TEMPORARY):


• Utilisé pour les opérations de tri,
• Ils ne peuvent pas contenir d’objets permanents,
• La gestion local des exents est recommandée.

CREATE TEMPORARY TABLESPACE temp2 TEMPFILE ‘/DISK2/temp01.dbf’ SIZE


500M Extent management local uniform size 4M;

Tablespace d’annulation(UNDO):
• Ils sont utilisés uniquement pour stocker les segments de undo (annulation),
• Ils ne peuvent contenir aucun autre objet,
• Ils ne peuvent être utilisé qu’avec la clause datafile.
• Exemple:

CREATE UNDO TABLESPACE undo1 DATAFILE ‘u01/oradate/undo101.dbf’ SIZE 40M;

Vous aimerez peut-être aussi