Tablespaces et performances : Best practices

Bonjour
Un nouveau projet est en cours de conception et implémentation.
Ma question concerne la gestion des tablespaces.
Certes nous devrions séparer les data (tbsdata) des indexes (tbsidx)
Mais y a t il d'autres subtilités à prendre en compte dans l'organisation des tablespaces afin
de gagner en maintenance et performances sachant que nos tables sont partitionnées voir sous-partitionnées ?
Je pense aussi au :
- sous-partitionnement par hachage ?
- au bigfile ?
- à 3 catégories de tablespaces : petites tables ,moyennes et grosses tables ?
Votre avis ,merci .

Autoextend ON ?

Bonjour
Idéalement il faut dispatcher les données sur différents disques pour éviter les contentions.

Le tablespace permet de faire un lien entre les segments(structure logique) et les fichiers .dbf(structure physique).

Bonjour,

Citation:

---

Envoyé par devkais

Idéalement il faut dispatcher les données sur différents disques pour éviter les contentions.

---

Pour cela on le fait plutôt par striping. Donc la séparation en tablespaces est plutôt une question d'administration pour ce qui se gère au niveau tablespace: transport de tablespace, backup/restauration, attributs (extent size).
Donc l'idée de base, c'est de séparer par application (pour pouvoir mettre offline un tablespace sans interrompre plusieurs applis) et éventuellement mettre les grosses tables à part.
Cordialement,
Franck.

Citation:

---

Envoyé par pachot

... et éventuellement mettre les grosses tables à part.
Franck.

---

Pourriez-vous développer ce concept ?

Bonjour
Hormis la séparation entre tablespaces DATA et tablespces INDEX que peut-on préconiser ?

Bonjour, en plus des points déjà cités (séparation index et table, stripping etc ...)
- utiliser : ASSM SEGMENT SPACE MANAGEMENT AUTO
- extent uniforme : EXTENT MANAGEMENT LOCAL UNIFORM SIZE xx, adapter la taille des extents des tables.

comme le dit pachot si vos bases de données sont sur une baies de disque
La performance I/O est a obtenir par un bon slicing des disques de la baie.
La separation des data et index en differents tablespace a peu d'interet.
Mieux vaut utiliser les tablespace pour des séparations fonctionnel (ex: par applications, par schémas).

Citation:

---

Envoyé par a.presles

La separation des data et index en differents tablespace a peu d'interet.

---

Je ne suis pas d'accord car cela facilite les opérations de maintenance et apporte beaucoup au niveau perfs ;)

Citation:

---

Envoyé par devkais

Je ne suis pas d'accord car cela facilite les opérations de maintenance et apporte beaucoup au niveau perfs ;)

---

Autant sur la simplification de certaines opérations de maintenance je suis d'accord, autant le gain au niveau des performances (sauf configuration stockage spécifique) me laisse dubitatif.
Pourriez-vous détailler comment vous obtenez des gains de performance ? Quelle est votre architecture ?

Bonjour ,il est possible dans certains cas d'avoir un gain en perfs en séparant les tables et les indexes dans des tablespaces différents ayant une taille d'extent(index) < taille d'extent (data).
Sinon en général avec les baies modernes le striping permet de minimiser les contentions IO par une répartition automatique des blocs de donnés sur les différents disques.
Enfin avoir un tbs index et un autre tbs data n'a aucun inconvénient et permet aussi d'avoir une bonne organisation logique ;)

bonsoir,
c'est vrai que cela n'a aucun inconvénient, mais il n'y a aucune justification non plus.cette conception est tombée en désuétude à partir de la 8i mais certains fournisseurs de logiciels, progiciels insistent encore lourdement sur cette séparation qui ne trouve aucun fondement si on n'a pas les mêmes points de montage pour les deux types de données.
pour des raisons d'administration? séparation par schéma serait plus judicieux.
quand à LMU... oracle se débrouille mieux en auto allocate. pour éviter les contentions I/O c'est effectivement le dispatching sur plusieurs disques qui fait la différence.
mais puisque vous en êtes à la conception, testez et faites vous une idée! le partitionnement est une notion très fonctionnelle, à tester aussi.

Bonjour,
A ceux qui séparent tablespace table et index, je leur demande en général où ils mettent les vues matérialisées (qui sont des tables mais redondantes commes les index) et où ils mettent les IOT (qui sont des tables, mais stockées commes des index).
Cordialement,
Franck.

Bonjour Franck,
Donc selon vous ,pour une nouvelle base à créer UN SEUL tablespace applicatif suffit ?
merci pour votre retour.
Z.

Il faut d'abort isoler les applis s'il y en a plusieurs sur la base (consolidation)
Ensuite on séparer les tablespaces pour isoler d'autres choses: de très gros objets pour lesquels on veut une taille d'extend particulière, des données d'archives qu'on veut mettre dans un filesystem monté sur des disques moins chers, des tables chargées en nologging pour lesquelles on veut faire un backup après chargemetn sans backuper toute la base, etc.

Sur le fait de mettre à part les données qu'on peut reconstruire (indexes, mviews) pourquoi pas. Mais pourquoi ? il faut les backuper aussi. Il est rare qu'on puisse se permettre de passer des heures à reconstruire tous les index. Sans parler des plantages à cause des tempfiles trop petits. Et des changement de plans d'exécution une fois que tout est reconstruit.

Bonjour à tous,

Petite question... est-ce que les datafiles sont sur un système de fichiers ou sur ASM?

Parce que si le tout est sur ASM, dans mon cas, je crée des tablespaces différents pour les tables, les index et les LOB mais je place tous les tablespaces dans le même diskgroup.

J'ai aussi l'habitude de séparer les applications en donnant des tablespaces différents pour chaque.

Et pour terminer, le flash_recovery_area est sur un autre diskgroup.

Bonne journée.

Sylvain

Citation:

---

Envoyé par struchon

Bonjour à tous,

Petite question... est-ce que les datafiles sont sur un système de fichiers ou sur ASM?

---

Bonjour ,
Les datafiles sont sur un FS.
Mais rien n'empêche de basculer vers ASM s'il le faut ...nous sommes déjà au début ;)
Z.