Administration des bases de donn�es by yOm8H3

VIEWS: 6 PAGES: 10

									                  Espaces disques logiques ("tablespace")
                                         Chap. 10, page 259 à 302

Du coté de l'instance, du point de vue logique, un tablespace accueille tous les objets logiques (les
segments de tables, d'index, …) de la base de données.

Du coté du système d'exploitation, le tablespace est un espace de stockage composé de un ou plusieurs
fichiers.

Les tablespaces permettent…
       Un meilleur contrôle de l'allocation de l'espace disque, soit:
        o Isoler des données du dictionnaire Oracle des données applicatives.
        o Cloisonner les données de plusieurs applications fonctionnant dans la même BD.
        o Segmenter le stockage des différents types d'objets (segments de tables, d'index, …).
       L'établissement de quotas pour limiter l'expansion des données par un utilisateur,
       Le fractionnement des opérations de sauvegarde et de restauration, car le tablespace est le plus
        petit niveau de sauvegarde/restauration. Il est donc possible de réaliser des
        sauvegardes/restaurations partielles.
       Un meilleur rendement si ces tablespaces sont répartis sur plusieurs disques ("stripping"). Il est
        alors possible de répartir la charge des entrées/sorties afin d'éviter
        les contentions («goulots d'étranglement») et d'augmenter la disponibilité des donnée.

La gestion et les performances de la base de données sont affectées directement par l'implantation et
l'organisation des tablespaces.

Les types de segments
   1.   Les segments de tables et d’index (permanent)
   2.   Les segments d’annulation
        Ces segments stockent la valeur précédente des colonnes mises à jour ou un indicateur en cas
        d'insertion d'une nouvelle ligne. Si la session de l'utilisateur est interrompue avant qu'il n'ait pu
        émettre une commande commit ou rollback, l'opération est annulée.
   3.   Les segments temporaires
        Ils servent lors de tris qui sont trop lourds pour être exécutées dans la PGA.




                                                    Page 1
Le stockage physique
Un serveur Oracle devrait posséder au minimum 10 disques (ce qui n’est pas souvent le cas 1), utilisant
une technologie de type RAID0+1 (SAME: Strip and Mirror Everything)

RAID-0 ("Strip")
Double les performances (en théorie) et fusionne tous les disques durs en un seul disque logique pour
augmenter la capacité. Il faut avoir 2 disques durs minimum. Le RAID 0 créé en fait une partition logique
dont la taille est égale à la somme des disques intégrés dans le système RAID.

RAID-1 ("Mirror")
Le RAID 1 est appelé "mirroring" car il fait une copie pure et simple du premier disque (donc pour 2
disques d'une taille égale, on obtient un espace de stockage égal à l'espace d'un seul disque).



Gestion des extensions du tablespace
La gestion de l'espace disque des fichiers de données d'une BD Oracle repose sur les concepts de
segment, d'extension et de bloc.

La gestion par le dictionnaire de données
La gestion des extensions libres et allouées est centralisée au sein du dictionnaire de données.

Oracle recommande l’utilisation de tablespaces gérés localement. Il est possible que la gestion par le
dictionnaire de données ne soit plus supportée par Oracle éventuellement…

La gestion locale
La gestion des extensions libres et allouées est déléguée à chaque tablespace qui les stocke dans les en-
têtes des fichiers en format bitmap.

Index bitmap.
Une chaîne de bits est utilisée pour chaque cardinalité (valeur possible). L'index bitmap contient x
bitmaps, x étant la cardinalité. Exemple:

           Libre               0   0    0    0    1    0    1   0    1    0    0   0    0    0
           Occupé              0   1    0    1    0    0    0   0    0    1    1   0    0    0


Cette gestion réduit les risques de contention pour le tablespace SYSTEM, car Oracle n'a pas besoin
d'accéder aux tables du dictionnaire de données pour allouer ou désallouer de l'espace à un tablespace.
Il y a donc :
            Moins d’énoncées SQL liées à la mise à jours du dictionnaire de données
            Les extensions adjacentes libres sont automatiquement identifiées
            Élimine la fragmentation et le gaspillage des extensions de l’espace libre.




                                                   Page 2
Type de tablespace BIGFILE/SMALLFILE

Le BIGFILE
Le tablespace de type "Bigfile" est utilisé pour :
 les bases atteintes de gigantisme,
 faciliter le travail du DBA,
 réduire le nombre de fichiers dans un tablespace,
 économiser de l'espace dans la zone SGA et du fichier de contrôle, cas il y a moins de fichiers de
     données à suivre.

Avec un tablespace BIGFILE, un seul fichier de donnée est alloué avec une taille pouvant atteindre 8Eo
(exaoctet = 260) et un maximum de 232 blocs.

Le tablespace traditionnel (SMALLFILE)
Ce tablespace est composé de un ou plusieurs fichiers de données. Souvent les fichiers sont sur des
disques différents.

Maximum de 1 022 fichiers de données et de 222 blocs.

Les types de tablespaces.

Les tablespaces permanents.
Les tablespaces SYSTEM (SYSTEM01.DBF) et SYSAUX (SYSAUX01.DBF) sont deux tablespace permanents.
Tous les segments utilisateur qui doivent être conservés au-delà d'une session ou d'une transaction
devraient être placés dans d’autres tablespaces.

SYSTEM
Contient principalement le dictionnaire de données.

Lorsque le tablespace SYSTEM est géré localement, les autres tablespaces de la BD doivent l'être
également ou être placés en lecture seule.

Aucun segment utilisateur ne devrait être enregistré dans ce tablespace.

SYSAUX
Contient les objets de l’usager SYSTEM et les fonctions d'administration et de collecte de données
statistiques.

Lorsque les applications du SYSAUX produisent un goulot d'étranglement en raison d'une forte
contention entre ces applications, il est possible de déplacer ces applications dans un autre tablespace
sur un autre disque.

Aucun segment utilisateur ne devrait être enregistré dans ce tablespace.




                                                  Page 3
Les tablespaces temporaires
Lorsqu'une requête nécessite un tri qui ne peut pas s'exécuter en mémoire (dans la PGA), Oracle peut
utiliser :
   -   un segment temporaire créé dans n'importe quel tablespace permanent. À éviter, puisqu’à
       chaque tri, le segment temporaire sera alloué et libéré. Mauvais pour la performance et pour la
       fragmentation.
   -   un segment temporaire créé dans un tablespace temporaire. Dans ce cas, un segment de tri est
       créé par le 1er tri et réutilisable par les tris suivants. Ce segment est libéré uniquement lors de
       l’arrêt de l’instance.

Ces requêtes peuvent provenir de l'énoncé SQL CREATE GLOBAL TEMPORARY TABLE ou d'énoncés SQL
contenant :

ORDER BY, GROUP BY, DISTINCT, UNION, INTERSECTION, MINUS, CREATE INDEX, SORT, MERGE …

Plusieurs tablespace temporaires peuvent être en ligne et actifs simultanément dans une base de
données et contenu dans un groupe de tablespaces temporaires. Cette approche peut améliorer le
temps de réponse pour les applications dont les requêtes s’exécutent régulièrement en parallèle. Faire
un groupe de tablespaces aide à la performance surtout si plusieurs disques durs sont disponibles.

Un tablespace temporaire à un fonctionnement particulier :
        o Les modifications ne sont pas enregistrées dans les fichiers de journalisation/redo-log.
        o ll ne peut pas être renommé ou déplacé (doit le détruire et le recréer)




                                                  Page 4
Les tablespaces d'annulation (UNDO)
Lorsqu’une modification aux données est en cours, Oracle conserve certaines informations qui seront
utilisées si la modification est annulée.

Ces informations sont en fait les valeurs précédentes des données (« before image »).

Par exemple, si une transaction en cours modifient les lignes d’une table et que celle-ci est finalement
annulée (ROLLBACK), alors Oracle se servira des informations d’annulation pour replacer les anciennes
données à leur place. S’il y a un COMMIT, l'espace occupé sera conservé un certain temps pour une
possible opération de Flashback.

Ces informations d’annulation sont sauvegardées dans des segments d’annulation et donc dans un
tablespace d’annulation. Les modifications aux blocs sont enregistrées dans les fichiers de journalisation.

Ces informations d’annulation sont utilisés pour :
  l’annulation de transactions (ROLLBACK)
  la lecture cohérente
       Les données modifiées d’une transaction en cours ne doit pas être vues par les autres utilisateurs.
  les requêtes de Flashback
  la récupération de la base de données (RECOVER)
       Permet d’annuler des modifications de blocs non validés qui ont déjà été écrites dans les fichiers
       de données (voir cours #2 - DBWn).

Une base de données peut supporter plusieurs tablespaces d’annulation, mais un seul un d'entre eux
peut être actif à la fois.

Un tablespace d’annulation actif ou qui contient des données d'annulation pour une transaction non
validée, ne peut ni être détruit, ni être mis hors ligne.

Les extensions d'un tablespace d’annulation doivent être gérées localement par le système (EXTEND
MANAGEMENT LOCAL AUTOALLOCATE).

Les paramètres d'initialisation associés aux opérations de recouvrement sont:
  UNDO_MANAGEMENT = AUTO
  UNDO_TABLESPACE                = UNDOTBS1
  UNDO_RETENTION                 = 900 secondes (données conservées pour au moins 900 sec.)

Pour interroger les paramètres de la session actuelle, provenant habituellement du fichier de
paramètres, utiliser : SHOW PARAMETERS xxx

Exemple : SHOW PARAMETERS UNTO_TABLESPACE;




                                                   Page 5
Espace d’annulation
Les opérations n’ont pas toutes le même poids en espace d’annulation
     INSERT :
            o Il n’y a pas de « before image »
     UPDATE/DELETE :
            o Plus la modification/suppression affecte les données, plus il y a d’informations
                d’annulation


Directives sur l’organisation des tablespace pour les applications

       SYSTEM et SYSAUX ne doivent pas contenir de données utilisateurs
       Créer/Avoir au minimum (en plus de SYSTEM et SYSAUX):
              Un tablespace d’annulation
              Un tablespace temporaire
              Un tablespace permanent pour les tables
              Un tablespace permanent pour les index.
       Si possible répartir les fichiers de données sur des disques différents pour éviter les délais de
        lecture/écriture (disques différents).
       Créer des tablespaces différents en regroupant les segments par fonctionnalité pour :
              Avoir plus de souplesse (depProduction, depAdministration…) :
              Réaliser des sauvegardes/restaurations partielles (différents tablespace),
              Contrôler la disponibilité des données (différents tablespaces).
       Utiliser des tablespaces dont la gestion des extensions est géré localement (entête de fichier) et
        ce même pour le tablespace SYSTEM.
       Utiliser un mode de gestion automatique de la taille des extensions lorsque l’on n’a pas une
        bonne vision des besoins.




                                                  Page 6
Gestion des tablespaces permanents et temporaires
La gestion des tablespaces (création, modification, suppression, …) est bien expliquée à partir de la page
261 pour les tablespaces permanents, et à partir de la page 282 pour les tablespaces temporaires.

Voici un résumé des opérations les plus importantes :

Création d’un tablespace permanent
CREATE SMALLFILE ou BIGFILE TABLESPACE nomTablespace
DATAFILE
   nomFichier SIZE xxx REUSE
        AUTOEXTEND
             OFF
             ON NEXT xxx MAXSIZE
                 UNLIMITED
                 xxx
   ,fichier 2 …
EXTENT MANAGEMENT
   DICTIONARY
   LOCAL
        AUTOALLOCATE
        UNIFORM xxx
SEGMENT SPACE MANAGEMENT
   MANUAL
   AUTO
DEFAULT
   COMPRESS
   NOCOMPRESS
LOGGING ou NOLOGGING
FORCE LOGGING
FLASHBACK
   ON
   OFF
ONLINE ou OFFLINE;

Note : xxx est valeur numérique, comme : 350K, 100M, 1T ou 10G

Exemple
   CREATE TABLESPACE monTablespace
   DATAFILE ‘C:/Oracle/oradata/b55/monTbs01.dbf’ SIZE 1G AUTOEXTEND ON NEXT 250M
   EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M
   SEGMENT SPACE MANAGEMENT AUTO;



                                                  Page 7
DATAFILE
Fichier(s) du tablespace.

La section AUTOEXTEND permet de définir si un fichier peut grossir ou pas lorsqu’il est plein. NEXT xxx
permet de spécifier la taille supplémentaire que le fichier prendra. MAXSIZE est la taille maximale du
fichier.

Si REUSE est utilisé, alors le tablespace peut écraser un fichier de données existant, si celui-ci existe déjà.

EXTENT MANAGEMENT
Est-ce que le tablespace est géré localement ou par le dictionnaire de données ? Il est recommandé de
le faire localement.

Pour les tablespaces gérés localement, il est possible d’ajouter des extensions de taille uniforme, mais il
est préférable pour Oracle de le laisser décider la taille qu’il allouera aux nouvelles extensions
(autoallocate).

SEGMENT SPACE MANAGEMENT
Pour les tablespace gérés localement seulement, cette clause permet de définir si la gestion de l’espace
libre des segments est automatique ou manuel.

Imaginons un bloc de données Oracle. Celui-ci possède plusieurs informations. Par exemple, les lignes 3
à 10 de la table USAGERS. Cependant, ce bloc peut ne pas être complètement plein. Oracle possède
donc deux mécanisme de gestion de ces espaces libres. Le mode automatique est conseillé pour une
meilleure performance. (p.365)

DEFAULT
Permet de spécifier si les blocs du tablespace doivent être compressés ou pas. Alors que compressé les
blocs sont échangés plus rapidement entre les fichiers de données et la cache de données, cela
demande un travail supplémentaire pour le CPU lors de la lecture. Il faut noter qu’Oracle conserve la
version compressée du bloc en cache, puisqu’il est capable d’en faire la lecture directement. C’est
cependant plus long que lorsqu’il est décompressé.

LOGGING ou NOLOGGING
Permet de spécifier le mode de journalisation de segments qui n’ont pas de mode défini. Par exemple,
doit-on journaliser la création ou la reconstruction des index, la création de tables par requête ?

Par exemple, si lors de la création d’un index NOLOGGING est spécifié, alors cette création de segment
ne sera pas enregistrée dans les fichiers de journalisation, même si le tablespace est en mode LOGGING.
Les opérations qui suivront seront cependant inscrit dans les fichiers de journalisation (INSERT, DELETE,
…)




                                                    Page 8
Si la base de données ou le tablespace est mis en mode FORCE LOGGING, alors NOLOGGING est ignorée
et toutes les opérations font une trace dans les fichiers de journalisation.

FORCE LOGGING
Si le tablespace est en mode FORCE LOGGING, alors toutes les modifications au tablespace seront
enregistrées dans les fichiers de journalisation et ce, même si certaines opérations sont en NOLOGGING.

FLASHBACK
Permet au tablespace de revenir à un état antérieur (relativement proche) lorsque la base de données
fait un flashback.

FLASHBACK DATABASE TO SCN 1234567;

Les informations liées au flashback du tablespace sont enregistrées dans le tablespace d’annulation.
Pour savoir le temps de rétention minimum des informations d’annulation pour un tablespace, utiliser :

SHOW PARAMETERS DB_FLASHBACK_RETENTION_TARGET;

ONLINE / OFFLINE
Permet de spécifier si le tablespace est en ligne ou hors ligne après sa création.


Création d’un tablespace temporaire

CREATE BIGFILE OU SMALLFILE TEMPORARY TABLESPACE nomTempTablespace
TEMPFILE
   emplacement/nomFichier SIZE xxx
        AUTOEXTEND
             OFF
        ON NEXT xxx MAXSIZE
             UNLIMITED
             Xxx
   , fichier2…
EXTENT MANAGEMENT
   LOCAL
   UNIFORM SIZE xxx

Exemple :
CREATE TEMPORARY TABLESPACE nomTbsTemporaire
TEMPFILE ‘c:/…/tmp.dbf’ SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 1G;




                                                   Page 9
Modification des tablespaces

Renommer un tablespace
ALTER TABLESPACE ancien RENAME TO nouveau;

Ajouter un fichier de données
ALTER TABLESPACE nomTablespace ADD DATAFILE emplacement/nomFic SIZE 100M AUTOEXTEND OFF;

Supprimer un fichier de données
ALTER TABLESPACE nomTablespace DROP DATAFILE emplacement/nomFichier;

Placer un tablespace hors ligne
ALTER TABLESPACE nomTablespace OFFLINE;

Placer un tablespace en mode lecture seule
ALTER TABLESPACE nomTablespace READ ONLY (au lieu de READ WRITE);


Supprimer un tablespace

DROP TABLESPACE nomTablespace INCLUDING CONTENTS AND DATAFILES;

Ce n’est pas une opération où il y un ROLLBACK possible. À utiliser avec précaution ! Il est également
conseillé de mettre le tablespace OFFLINE avant de le supprimer.




                                                 Page 10

								
To top