Discussion :

[nuke_y]

Bonjour à tous,

2 questions très basiques sur la bonne pratique de l'utilisation de tablespaces dans un datawarehouse suite à un débat entre spécialistes BI mais pas DBA:

-Il faut un TBS séparé pour les index et les données. Ca me semble la bonne pratique (j'ai toujours vu ça). Les 2 raisons pour le faire, données par 2 personnes différentes, il doit bien y en avoir une des deux qui est bonne, ou une 3e dont je ne me souviens pas :

• Ca permet de mettre les tablespaces sur des datafiles différents, avec des propriétés différentes (plus rapide d'accès pour les Index que les données, ou l'inverse)

• Ca permet d'avoir un réglage fin différent (politique d'extend, partitionnement) et une administration différentes (recreate Index avec option reuse, exp/imp en vue de sauvegarde, etc.) car les index bougent plus que les données qui peuvent bouger seulement en append mais sauver les index n'est pas primordial

- Il FAUT utiliser le même TBS pour les index des faits et des dimensions, et le même TBS pour les données des faits et des dimensions. Donc grouper TOUS les index sur le même TBS et TOUTES les données sur un autre TBS, et pas plusieurs TBS. Là dessus je suis beaucoup plus suspicieux. Pour moi, en dehors des logiques de fine tuning avec des datafiles sur des disques différents, restons sur le cas d'UN disque sur lequel se trouve tous les datafiles, l'intérêt d'utiliser un seul TBS n'est pas évident.

Bien sûr si on requête les données des faits joints avec les dimensions, on va attaquer toujours le même TBS, donc on va moins se promener dans le disque. Mais est-ce qu'on ne risque pas par la même occasion de disperser des données au travers de tous les datafiles ? Si on a 10 tables de faits, 20 dimensions, quand je fais une requête avec 1 table de faits et 20 dimensions est-ce qu'Oracle ne va pas devoir aller picorer les blocs dans la totalité des datafiles ? Est-ce que le fait de mettre TOUTES les données sur un seul TBS ne limite pas fortement l'intérêt et les possibilité du partitionnement ?

Bref est-ce qu'il y a un REEL avantage, surtout d'un point de vue perfs, à tout regrouper dans seulement 2 TBS (INDEX et DATA) ?

Moi j'en étais resté à une règle qui disait que, en dehors du fine tuning qui obéit à d'autres règles, on fait 1 TBS par type d'administration:

• Manual extend -> 1 TBS

• Autoextend -> 1 TBS

• recreate index avec reuse -> 1 TBS

• etc.

Merci de vos éclaircissements

[nuke_y]

En fouillant un peu j'ai trouvé ça qui semblerait plutôt aller dans le sens du mono-TBS, qui serait plutôt meilleur pour les perfs que plusieurs TBS.

[orafrance]

le post que tu cites parle d'une table par TS, j'vois rien sur les indexes

Moi je préfère 2 TS séparé simplement parce que la gestion des objets est différente et donc les possibilités de shrinker le tablespace aussi. Rebuilder les indexes pour gagner de l'espace et se retrouver avec un bloc de table en bout de TS c'est rageant

Pour le reste, je crois surtout qu'il n'y a pas de règle, tout dépends de l'utilisation des indexes, des volumes dont on parle, du type de stockage (le data placement est surement plus sensible notamment), etc. La seule règle c'est : observer et réagir

Si tu veux une règle gérérale : il parait que le nombre d'or d'Oracle c'est 1024. Donc pas plus de 1024 extents par exemple dans un segment, ni dans un TS. Ceci dit, j'ai jamais pu le vérifier dans la vraie vie

[nuke_y]

Salut Orafrance, toujours actif à ce que je vois

Le 1er j'avais peu de doute.

Merci pour ton avis sur le 2e point, ça me rassure déjà un peu l'idée du "ça dépend, il n'y a pas de vraie règle à appliquer systématiquement".

S'il y a d'autres avis, dans la même direction ou dans une autre, je suis preneur pour étoffer la reflexion.

Merci beaucoup

[Waldar]

L'utilisation de différents tablespaces pour les tables et les index ne servent que pour de l'administration, mais côté performance ça ne change plus rien.
Idem pour les extents, laissez Oracle gérer (je ne sais jamais si c'est ASM ou ASSM).

Edit : déjà en 2002 c'était devenu un mythe
https://groups.google.com/forum/#!to...B1-25-false%5D

[nuke_y]

Oui je suis d'accord avec ce qui se dit dans le lien que tu as donné Waldar : ça peut aider légèrement en administration, et sinon il faut vraiment se pencher sur du fine tuning pour que ça ait un intérêt.

Un avis sur le 2e point ?

Merci