Lenteur du datawarehouse et demande d'aide pour optimisation

[codacoda]

Bonjour,

Nous avons un datawarehouse en place avec les caractéristiques suivantes:

• 2 intel xeon six coeurs 2.67GHz
• 32Go RAM
• 4 HDD en raid 5 7200 rpm IBM

Voilà le problème est que nous avons des lenteurs dû au fait que les data et les index se trouvent sur les mêmes disques physiques entre autres.

Nous utilisons la mémoire à 50% et le processeur à 10%. Le bottleneck est clairent les HDD.

Nous savons que si nous ajoutons un autre raid de 4 disques et que nous mettons les index dessus par exemple cela sera plus rapide.

J'aimerais vous poser la question suivante : Si je propose de mettre un deuxième raid de SSD, quels sont les éléments de la base de données Oracle (quels tablespaces? index? data? autres?) que je pourrais mettre dessus pour profiter de la puissance en lecture séquentielle des SSD.

Merci beaucoup pour vos réponses

Codacoda

[Mohamed.Houri]

Le gain de performance du à la séparation des tablespaces des indexes de ceux des tables est un mythe qui malheureusement continue d'exister. Si vous faites cette séparation pour gagner en performance alors vous vous trompez. Si, par contre, vous procédez à cette séparation de tablespaces pour des raisons de "manageability" et de facilité de maintenance, cela pourrait être une bonne idée. D'ailleurs, chez tous les clients où je suis passé, existe cette séparation implémentée (encore une fois) pour des raisons de performance alors que nous avons à chaque fois résolu des problèmes de performance autrement que par cette séparation de tablespace.

Les deux liens suivants vous donneront plus de détails à ce sujet

http://forums.oracle.com/forums/thre...hreadID=443920

http://richardfoote.wordpress.com/20...s-right-place/

Mohamed Houri

[13thFloor]

Bonjour,
le "bottleneck" est toujours les IO. les temps d'accès aux disques seront toujours moins rapide que la mémoire.
Mais avant d'incriminer les disques et d'envisager un changement d'architecture, il faudrait argumenter cette hypothèse et vérifier l’origine des goulots d'étranglement, au moins à l'aide d'awr, qui vous indiquera les attentes, les requêtes les plus consommatrices, les temps moyen d'accès aux fichiers etc.
Avant d'ajouter de modifier l'archi disque, il sera utile de minimiser les IO par : les statistiques, les indexs, le partitionnement, le codage sql...