Discussion :

[magic charly]

bonjour a tous,

je réalise actuellement la modification d'une base de données existante. Je ne suis pas expert (loin de là) dans le domaine mais j'ai quand même quelques notions. remarque : La base de données est une Oracle

la question est la suivante :

j'ai une table tres grande pour lesquels j'ai des temps d'accès qui sont trop longs. Cette table est une table de mesure qui contient plusieurs types de mesures cependant tous les attributs de cette table sont communs a chaque type de mesure.

Devrais-je laisser toutes les mesures au sein d'une même table ?
(selon moi le + logique)
ou devrais-je créer une table par type de mesure ?

(sachant qu'une table par type de mesuer n'apporte aucune information supplémentaire)

Merci d'avance, pour votre aide...

Charly mieux connu sous le nom de "database beginner touch"

[plabrevo]

Pour un modele de donnees et une application bien construites, le volume n'est pas un frein a la performance.

Une table "trop grande" dans les conditions decrites, parce qu'elle regroupe les mesures de 3 instruments, sera peut-etre 3 fois plus rapide en acces une fois decomposee en 3 tables dedies pour chacune de ces instruments, mais les problemes de performance persisteront.

Il faut mieux analyser les raisons de ces problemes de performance: manque d'index? manque d'index pertinent? non selectivite de la recherche?, etc.

[azertyman]

cela peut venir de la base autant que des requetes

[magic charly]

merci de preter attention a mon probleme

En fait, le soucis vient de la façon sont faites les requetes ... toutes en memes temps (toutes les 15 min). il y a donc des accès concurrents d'insertinon dans la table. Et je me demandais si de séparer les types de données dans différentes tables de données ne pourrait pas accèlérer les choses.



:

[pifor]

Est-ce que vous pouvez nous donner quelques chiffres:
- taille de la table ?
- taille de la base ?
- nombre d'insertions par unité de temps ?
- temps d'accès très longs ?

Une solution possible à un goulot d'étranglement pour des insertions massives est l'utilisation du partitionnement: la table est découpée par Oracle en partitions et les insertions peuvent être réparties sur les différentes partitions de façon assez transparente par Oracle.

voir le chapitre 17 de l'admin guide 9i dans:
http://oraclesvca2.oracle.com/docs/c...titi.htm#20590

[bpprive]

Sans mentionner le fait qu'en divisant le modèle selon la logique d'affaire, on a un gain de performance certes, mais une évolutivité réduite... Plus le modèle est collé à la structure administrative, plus il est performant mais moins évolutif.

Un juste milieu est nécéssaire. Dans le cas présent, j'arbore plabrevo en disant que je ne crois pas que le volume freine la performance, c'est probablement un problème d'utilisation plutot que de capacité ou de modélisation.

[azertyman]

quand j'ai dit que cela pouvait venir des requêtes, evidemment que les ralentissement sont dues au fait qu'il y a des requêtes, mais ce que je voulais dire c'est que certaines requêtes sont plus optimisées que d'autres (INNER JOIN au lieu de WHERE par exemple)

[dyvim]

Est ce que tu pourrais nous donner le script de création de la table (pour avoir les colonnes et les indexes...)? En précisant le volume de celle ci.

Est ce que tu pourrais nous faire parvenir les requetes d'insertion?
(en nous donnant une idée du nbre de fois et du rythme auquel elles sont jouées)

Sinon splitter la table en plusieurs pour éviter les accès concurrentiels peut être une bonne idée. Mais normalement, s'il n'y a que des requetes d'insertions, cela ne devrait pas poser de problemes (pas de concurrence)

Si les insertions sont longues cela peut venir d'un (trop?) grand nombre d'index ou de l'utilisation d'index bitmaps ou encore des contraintes ou des triggers.

Autre question: Est ce que toutes les colonnes sont utilisées par tous les instruments?
Si ce n'est pas le cas, il y a peut être moyen de modéliser cela par héritage...

[orafrance]

un partitionnement de la table par type de mesure pourrait être une solution non ?

[Process Linux]

Je suis avec la solution de Fred_D, un partitionnement résoud le problème.
Je vais ajouter une solution à un niveau plus bas , généralement il faut mettre cette table dans un tablespace independant, les fichiers de ce tablespace seront dans un autre HDD , comme ca , il y aura un seule controlleur disque qui est dédié à cette table, les accés I/O sont plus rapides.

[magic charly]

Bonjour,

dsl j'ai été amené a me pencher sur problèmes + "urgents" :p et j'ai quelque peu délaissé ma super table oracle .

je m'en excuse pour les gens qui ont pris la peine la peine de ramasser ma bouteille de Gin-Oracle jetée à la mer....

je pense que je vais m'orienter vers un partionnement mais je ne sais pas quelles difficultés cela représente tant d'un point de vue administratif que d'un point de vue technique étant donné que je suis assez novice dans le domaine des bases de données.

Sauriez-vous sur quels sont les points auxquels je devrais faire attention?
et surtout comment mettre en place le partitionnement proprement?

j'ai un peu peur de faire de grosses bétises en partant bille en tête sur la mise en place de la solution.

merci d'avance, 8)
Charly,

Optimiseur Oracle en herbe