lenteur sur table avec beaucoup de colonne

[ukanoldai]

Bonjour,
dans le cadre d'un datawarehouse sur 9i j'ai une table avec beaucoup de mesures, +/- 400, et des cles vers une dizaine de dimension,et toutes mes opérations d'insert/update sont extremement lentes, la table fait +/- 2.5 millions de lignes

par exemple lors d'un update d'un champ d'une dimension cela prend pour le moment plusieurs heures alors que mon query est optimisé et que cela devrait prendre qques secondes sur une table normale.

je cherche des solutions, est ce que une table partitionnée avec d'un cote les dimensions et de l'autre coté mes mesures pourraient aider dans ce cas? c'est a dire qu'il ne chargerait que les données de la table de dimension?

car pour le moment a part fractionner mes update je ne vois pas trop de solution.

si vous avez des pistes

merci de votre aide

[orafrance]

si il y a beaucoup de colonnes la solution pourrait venir d'un split de la table en plusieurs tables pour réduire le nombre de colonne de chacune d'elle.

pour 2,5 millions de ligne le partitionnement ne devrait pas être utile

[remi4444]

Envoyé par ukanoldai

par exemple lors d'un update d'un champ d'une dimension cela prend pour le moment plusieurs heures alors que mon query est optimisé et que cela devrait prendre qques secondes sur une table normale

l'update porte sur toute la table ou juste sur quelques lignes ?


Commence d'abord par editer le plan d'exécution de ta requête lente et compare le au plan d'exécution d'une requête rapide sur une autre table. Avant de se lancer dans une réorganisation complète de tes donner la moindre des chose est de valider que le problème de vient pas d'ailleur...

Ceci dit, 400 colonnes ça abuse un peu pour une table...

[Nick_Holmes]

J'ai eu un problème similaire sur une table avec une colonne de type VARCHAR2(2048). Les select mettaient énormement de temps. On est en train de splitter la table en plusieurs et en attendant, on fait une copie de table sans les grosses colonnes inutiles pour nos select gourmands.

@+,
NicK.