Discussion :

[Bruno2r]

Bonjour à tous,

Je viens de recevoir une Base toute neuve en Oracle 10g pour monter mon infocentre.

Au moment de créer clés primaires et indexes sur mes premières tables, j'ai un doute...
J'ai un seul tablespace USERS.
J'avais pris l'habitude en V8 de les créer dans un tablespace séparé.
Est ce que cela est toujours d'actualité en Oragle 10g ?
SACHANT QU'ON EST EN RAID5 et que tout ça s'écrira sur les mêmes disques
Merci d'avance.

[Invité]

L'usage veut que l'on mette les tables et les indexes dans des tablespaces distincts.

[hurricane]

En 10g on peut toujours mettre les indexes dans un tablespace à part.

[Invité]

oui, je voulais dire un tablespace pour les tables et un pour les indexes.

[Bruno2r]

Merci les amis
Mais ça ne répond pas à ma question.
Je sais bien qu'on le fait, qu'on peut le faire et qu'on peut en espérer un gain en temps de réponse.

Mais je ne sais pas si cette coutûme ou orthodoxie a encore un intérêt en Oracle 10g lorsque le serveur est sur une baie de disques SATA en RAID 5.

McM t'as une idée ?

[McM]

Mais pourquoi moi ?


Du moment où tu es sur une baie, tu n'as presque plus le contrôle de où sont tes données.
Dans mon précédent boulot, un expert IBM était venu et nous avait dit que la meilleure solution était de créer des disque logiques qui utilisaient des groupes de disques différents, et de séparer les tablespaces Data et Index suivant ces disques logiques.
Sinon, tu n'as pas moyen de savoir si ton index n'est pas lu sur le même disque physique que tes données.

C'est sur que ça faut le faire avant de tout créer.

[Bruno2r]

Merci McM
C'est déjà plus ... logique comme réponse.
Pourquoi Toi, ben j'ai de bons souvenir de nos réponses de cet été et comme c'est la première fois que je demande de l'aide je voulais pas rester sur ma faim. Alors j'ai fait appel à ta pertinence.
Merci

[McM]

Tss.. ch'suis pas DBA moi !
J'ai juste été responsable de l'optimisation, et ai suivi 3 j / 5 de la formation DBA 3

[Bruno2r]

Ben je suis pas DBA non plus
Mais ça m'empêche pas de me poser des questions.
Et puis qu'est ce que le savoir technique ... voire le diplôme ...
sans expérience
sans pertinence
sans bon sens
sans curiosité
et sans astuce ...
un titre

[laurentschneider]

Mon conseil est de créer des tablespaces "logique", par exemple l'application A utilise le tablespace A et l'application B utilise le tablespace B.

Vu que tout est sur les mêmes disques, la recommendation de séparer index et tables me parait un peu mythique, non? Je ne pense pas que cela va améliorer la performance. Mais bon, si le dba aime faire ça, je n'y vois pas d'inconvénient

[LeoAnderson]

Mon conseil est de créer des tablespaces "logique", par exemple l'application A utilise le tablespace A et l'application B utilise le tablespace B.

Vu que tout est sur les mêmes disques, la recommendation de séparer index et tables me parait un peu mythique, non? Je ne pense pas que cela va améliorer la performance. Mais bon, si le dba aime faire ça, je n'y vois pas d'inconvénient

vrai, la séparation par données/indexes n'a pas grand sens sur les mêmes disques mais :

• ça ne coute pas vraiment plus cher de le faire
• si un jour, on a un disque nouveau, on a déjà tout prêt
• en cas de crash, c'est pas inintérêssant de savoir ce qui est potentiellement en danger

[laurentschneider]

oui, bon, on peut dire que l'on sépare les index et les tables, mais on pourrait aussi séparer les petites tables et les grandes, ou les tables a faible taux d'ecriture et les tables a fort taux d'écritures, ou les tables qui commencent par A-M et celles qui commencent par N-Z.

Avec deux disques, je préfère avoir les indexes sur deux disques et les tables sur deux disques plutôt que 1 disque pour les tables et 1 disque pour les index. Mais c'est un vieux débat...

Le mythe veut que l'on sépare tables et index pour éviter les accès concurrents. Or il n'y a pas d'accès concurrent, car le bloc d'index est lu avant la table...

[McM]

Vu que tout est sur les mêmes disques, la recommendation de séparer index et tables me parait un peu mythique, non? Je ne pense pas que cela va améliorer la performance. Mais bon, si le dba aime faire ça, je n'y vois pas d'inconvénient

Le but est de créer 2 groupes de disques physiques : 1 pour les données, 1 pour les indexes. Là tu y gagnes.

[laurentschneider]

non, je ne crois pas

il y a eu il y a quelque temps une fameuse discussion à ce sujet où de nombreux experts comme Tom Kyte, Jonathan Lewis et Howards Rogers ont tenté de démystifier ce principe de sépararer les index et les tables, mais je vois qu'il y a toujours un village de gaulois qui résiste à l'envahisseur

http://groups.google.ch/group/comp.d...7b38c17b?hl=fr

[LeoAnderson]

oui, bon, on peut dire que l'on sépare les index et les tables, mais on pourrait aussi séparer les petites tables et les grandes, ...

ça oui... si par "petite tables" tu veux dire "table dont les lignes sont petites" !

effectivement, ajuster les blocksize est plus intérêssant !

quant à la discussion que tu cites, je n'aurais qu'un mot : MERCI !
c'est un régal de voir un tel échange de points de vue

Je restais dans le village gaulois non par conviction mais par habitude (le "ça coute pas plus cher alors...") mais je crois que je vais aller me construire ma hutte ailleurs !

[McM]

Si en plus Tom Kyte se met contre moi.. je m'incline

[laurentschneider]

Je vois ça

Si le dba a séparé et sépare par principe table et index, je ne dis rien

Par contre quand un consultant arrive et après 30 minutes s'exclame : "quelle horreur, les index et les tables sont dans le même tablespace, réorganisons vite tout ça !", là je m'oppose

[Invité]

Comme quoi les mythes urbains ont la vie dure !

[Bruno2r]

Merci à tous pour cet échange ... fructueux.
J'avais vu evoqué le mythe du tablespace index différent du tablespace tables mais sans trop de démonstration.
Voilà qui me confirme que je peux aller construire ma hutte hors du village gaulois.

[orafrance]

Le mythe veut que l'on sépare tables et index pour éviter les accès concurrents. Or il n'y a pas d'accès concurrent, car le bloc d'index est lu avant la table...

En effet, mais là où le mythe devient un besoin c'est dans l'usage d'extent de tailles différentes.

Le point 4.3 pondère donc mes propos tenu dans le point 4.1

En réalité, on rencontre se type de besoin surtout dans les bases utilisées et pour l'OLTP et pour le datawarehouse (du moins c'est ce que j'ai eu l'occasion de voir ) ce qui n'est pas recommandé

Finalement, on peut pas du tout être affirmatif concernant le stockage tant les problématiques peuvent être différente... j'ai vu des stats sur SYS en 9i améliorer sensiblement les perfs, une révision du data placement dans les baies de stockage révolutionner les temps de réponses (quand les admin systémes juraient que ça ne change rien), etc... c'est indéniablement une des problématiques les plus complexes à appréhender malgré l'impression de facilité renforcé par Oracle (notion de tablespace, ASSM, etc...).