Tablespaces, datafiles et filesystem, comprendre le stockage

Une fois votre base installée, paramétrée, démarrée et en production (quelques étapes ont volontairement été sautée), le gros du travail du DBA de production consiste à maintenir cette base en conditions optimales, c'est à dire que les temps de réponses ne se dégradent pas avec la croissance de la volumétrie et que Oracle "ne tombe pas".

Les tables ont été crées, les index également, vous utilisez des LOB, des vues matérialisées, tout ça permet une amélioration des performances mais prend de la place ; et trouver une information parmi 4To ou parmi 500Go n'est pas sans incidence sur les dites performances.


Voici comment est structurée la gestion physique des données :
Les objets (LOB, tables, index, vues matérialisées) sont stockées au sein de tablespaces.
Il convient généralement selon le type des objets et leur taille de les séparer dans des tablespaces différents (que l'on paramètrera de manière spécifique).
Un tablespace reste une notion abstraite car ne définit pas un espace disque donné. En effet, un tablespace stocke ses données dans des datafiles ; ce sont les fichiers .dbf que vous pouvez apercevoir depuis votre OS. Ceux ci ne sont pas figés car il est possible de grandir un dbf, mais il existe quelques subtilités ; en effet contrairement à un fichier texte qu'on ouvre auquel on ajoute trois lignes, sa taille grandit lorsque qu'on le sauve pour quitter, dans Oracle, on définit, à l'avance, la taille du dbf que l'on veut associer à son tablespace. L'avantage est que cette limitation empèche un accroissement soudain qui nous remplirait le filesystem (espace disque au niveau os (encore appelé partition : d:\ sous windows, /dev/hdc2 sous unix). L'inconvénient est qu'il faut bien viser ou bien surdimensionner notre espace (cas de tablespace full).

Au sein de chaque tablespace, des segments sont alloués aux datafiles auquels ils sont rattachés. Les segments sont les morceaux de fichiers composés d'extents qui sont une suite contigü de bloc du disque.
Parmi les différents segments, on distingue notamment les rollback segments (RBS). qui ont laissé leur place à l'ensemble du tablespace UNDO, dédié à la gestion des opérations de rollback.
Toutes les contraintes de gestion bas niveau ont été amenuisées au fil des versions, notamment avec l'apparition d'auto-extent et la gestion automatique des segments, mais une veille sur les tablespaces et les filesystem reste indispensable.

Pour augmenter de l'espace dans un tablespace, différentes possibilités :
Ajouter un datafile (peu importe le filesystem) :
ALTER TABLESPACE tbs_idx ADD DATAFILE '/oracle/oradata5/tbs_idx_2.dbf' SIZE 2G;
ou augmentation d'un datafile existant :
ALTER DATABASE DATAFILE '/oracle/oradata2/tbs_idx_1.dbf' resize 5G;
ou encore allocation dynamique des extent dans la limite d'une certaine taille afin de ne pas saturer le filesystem
ALTER DATABASE DATAFILE '/oracle/oradata2/tbs_idx_1.dbf' AUTOEXTEND ON NEXT 512M MAXSIZE 5G;


Le tablespace UNDO se gère de la même manière qu'un tablespace de données classiques : ALTER DATABASE DATAFILE '/oracle/oradata2/undo01.dbf' RESIZE 100M;
ALTER TABLESPACE UNDO ADD DATAFILE '/oracle/oradata3/undo01.dbf' SIZE 200M;

Cas particulier du tablespace TEMP :
Notez bien que le tablespace TEMP (ou tout autre tablespace temporaire) est quelque peu particulier car on ne parle alors plus de datafile mais de tempfile :
ALTER DATABASE TEMPFILE '/oracle/oradata2/temp01.dbf' RESIZE 100M;
ALTER TABLESPACE temp ADD TEMPFILE '/oracle/oradata2/temp02.dbf' SIZE 200M;
Les débats font rage, autoextent ou pas autoextent, celà dépend de vos surveillances et de la criticité des deux "scénarii catastrophes" (filesystem plein ou tablespace plein).

Erreur liées : ORA-01652: unable to extend temp segment by
ou ORA-30036: unable to extend segment by string in undo tablespace

Voir également comment migrer les index de tablespaces et comment migrer les LOB de tablespaces.




Vous n'avez pas trouver réponse à votre question ? Préciser votre recherche :

Catégories