[DWH] Bonnes pratiques avec les tablespace

**nuke_y** · 05/12/2013, 22h21

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** · 05/12/2013, 23h06

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** · 06/12/2013, 09h39

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** · 06/12/2013, 10h37

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** · 06/12/2013, 12h08

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** · 06/12/2013, 12h21

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

**jkofr** · 06/12/2013, 14h19

Pour le point 2:

Imagine que pour une raison X tu pers un datafile appartenant à un tablespace et que pour des raisons sombres et obscures tu as de grandes difficultés pour restaurer...

Tu sera sans doute moins dans la mouise si, par chance, le datafile est celui d'un TBS qui ne contient que des indexes.

jko

**nuke_y** · 06/12/2013, 17h02

Merci, mais par "point 2" j'entendais le fait de grouper toutes les DATA de toutes les tables, de tous les schémas (hors système) sur un seul TBS, est-ce que ça a un intérêt ou pas ? Orafrance m'a déjà donné son avis mais j'aime bien en avoir plusieurs.

Merci

**orafrance** · 06/12/2013, 17h04

Qui ne dit mot consent

**pachot** · 08/12/2013, 21h21

Bonjour,

A ceux qui veulent séparer les tables et les index, pour vérifier s'ils ont de bonnes raisons, je leur demande où ils mettent:
- les vues matérialisées, qui sont des tables, mais avec des données qu'on peut reconstruire - comme des index.
- les IOT qui sont des index mais avec des données qu'on ne peut pas reconstruire - donc des tables avec une structure d'index.

Cordialement,
Franck.

**orafrance** · 09/12/2013, 10h21

Et bien les MV dans le tablespace des indexes et IOT dans les tables bien entendu.

**nuke_y** · 09/12/2013, 11h04

Si la séparation répond au besoin de séparer les données pérennes des données qui peuvent être recalculées / reconstruites je dirais comme Orafrance.

Sinon d'autres logiques peuvent mener à d'autres choix. Par exemple si la logique c'est que des donnée qui bougent souvent avec une organisation en index doivent être sur un TBS particulier, les index et les IOT pourraient se trouver groupés.

J'avoue que je ne sais pas, tout est question de compromis mais ce que j'essaye surtout de comprendre c'est pourquoi on ferait le choix de cloisonner, quels sont les bénéfices (perfs / maintenance) d'une organisation cloisonnée (ou pas) des TBS et quels sont les Best Practices.

J'ai l'impression qu'il y a pas mal de choses qui sont plus du domaine de la croyance. Si on me dit "C'est comme ça parce que ça ne mange pas de pain et on a l'habitude de faire comme ça", je suis OK, pourquoi pas ? Mais si on me dit "Aaaaah c'est gravissime tu n'as pas fait comme ça, c'est une faute" alors qu'il n'y a aucune raison factuelle, ça ça m'agace.

Merci à tous pour le débat en tout cas

**orafrance** · 09/12/2013, 11h35

Il y a aussi autre chose qui peut motiver le choix c'est le besoin ou pas de performance. Genre des tables de référence mise en cache mais dont l'accès ne nécessitent par forcément des perfs de dingues (vu que ce n'est lu qu'une fois). Ces tables pourraient être dans un datafile stocké par un disque moins rapide.

**jkofr** · 09/12/2013, 11h46

Envoyé par orafrance

Il y a aussi autre chose qui peut motiver le choix c'est le besoin ou pas de performance. Genre des tables de référence mise en cache mais dont l'accès ne nécessitent par forcément des perfs de dingues (vu que ce n'est lu qu'une fois). Ces tables pourraient être dans un datafile stocké par un disque moins rapide.

En 12c la fonctionnalité est native

jko