Discussion :

[orafrance]

En fait j'aimerai bien discuter avec Tom pour lui soumettre quelques idées... dommage que mon anglais soit pas uffisant

Il dit :

Think about HOW indexes are actually used and then put that against the
statement "since they have a great deal of concurrent I/O during both data
manipulation and queries.". Now, does that statement make sense? Is there
concurrent IO to index and table data during DML/select? Rhetorical question --
no, the IO is in fact serial in nature. Read the index to find the table data.
Index then data, one after the other. Serial....

Sauf que là il ne tient pas du tout compte de l'endroit où sont les blocs de données dans les datafiles (puisqu'on parle de tablespace mais en fait, c'est bien les datafiles qui sont important), des requêtes qui ne tapent que dans les indexes et de celles qui ne tapent que dans les datas... Donc ma conclusion est la suivante, dans l'absolu il a probablement raison mais dans des applications avec énormément d'accés concurrent ça peut faire la différence et je l'ai vu de mes propres yeux à mes débuts ou le DBA avait fait de telles séparations de datafile dans Oracle Application avec plus de 120 users simultanés et ça a considérablement réduit les temps d'attente sur les I/O

La deuxiéme conclusion, c'est que de toute manière le contexte est pour 80% dans le choix d'une architecture de la base de données et que tout les articles du monde ne vaudront pas une mise en pratique avec une comparaison objective des résultats dans un contexte déterminé.

J'avais d'ailleurs déjà fait le même type de démonstration avec les tables partitionnées où on me disait que ça n'améliore pas les perfs, sauf que quand la table est partitionné l'accés aux blocs des données est plus fin et du coup les accés concurrents sont bcp mieux gérer... encore une fois, c'est un constat que j'avais fait et j'avais posté un topic à ce sujet

[orafrance]

Encore une précision

Toutes mes remarques s'entendent dans un contexte où le serveur a plusieurs CPU (pour paralléliser les traitements) et plusieurs disques, le tout gérer par un OS optimisé pour cette config (donc pas Windows 95 )

j'attends vos remarques qui feront imanquablement avancer le débat , je signale que ce ne sont que des remarques basées sur ma propre opinion et l'analyse que j'ai faite des optimisations que j'ai constaté sachant que cette analyse peut être erroné du fait d'effet de Bore que je n'aurais pas maitrisé et vu

[SheikYerbouti]

Merci pour toutes ces précisions et je vous rejoins sur le fait qu' aucune théorie n'est à l'abri des circonstances particulières de chaque environnement.

[Marc Musette]

vive les tests !

[orafrance]

aïe aïe aïe... merci de ne pas tenir compte des fautes d'orthographes

[phig]

Bonjour,

Sans pouvoir citer mes sources car je me souviens plus, j'avais lu un expert qui disait effectivement que la séparation des index et de données n'améliorait PLUS les performances. Il disait effectivement que la recherche était séquentiel : index puis données et que le seul gain était que la tête de lecture du disque n'avait pas à se déplacer des zones où sont stockées les données, des zones où sont les index. Mais compte tenu des performances actuelles des systèmes de stockage, c'était devenu totalement négligeable vis à vis des autres délais. Donc, index séparés des données était valable avant.
Personnellement, j'ai fait cette séparation il y a quelques semaines, et pour certains traitements brassant beaucoup de données, je gagne 10 à 15% de temps. Mais selon mon administrateur système, notre machine Unix commence à se faire vieille.

voilà, c'était juste pour apporter ma modeste contribution à ce débat.

Phig

[SheikYerbouti]

Le concept est pourtant simple à comprendre car il ne faut pas raisonner "mono-utilisateur".

Plusieurs utilisateurs (dizaines, centaines, milliers) exécutent des requêtes.

si tous les datafiles sont stockés sur 1 disque, il faudra bien que l'accès à l'index attende le retour de l'accès à la table et vice-versa.
s'ils sont séparés sur 2 disques, les attentes sont en théorie divisées par 2.

[Marc Musette]

apparemment il doit attendre dans les deux cas puisqu'il s'agit de lectures séquentielles ... d'abord l'index puis le datafile ...


au fait personne ne stocke ses datafile sur du raid5 ?

[SheikYerbouti]

Décidément.... je parlais d'accès MULTI-UTILISATEURS ou l'accés à l'index pour l'utilisateur 1 n'attend pas le retour d'accès aux datas de l'utilisateur 2...

[SheikYerbouti]

au fait personne ne stocke ses datafile sur du raid5 ?

bonne précision, qui ne saurait tarder de renvoyer ces débats aux livres d'histoire.

[orafrance]

BrunoJ -> c'est vrai si tu ne travailles qu'avec 2 tablespaces mais si il y en a 4 tu croises les tablespaces (data/index par disque) et là ça peut devenir TRES intéressant

En plus, il n'est pas seulement question de temps d'accés mais aussi de contention sur les fichiers en accés concurrent