Bonjour,
J'ai actuellement une table partitionnée.
A priori les index présents sur cette table (hormis l'index de partition) ne sont pas partitionner....
Comment faire pour partitionner aussi les index de cette table?
Merci d'avance
Version imprimable
Bonjour,
J'ai actuellement une table partitionnée.
A priori les index présents sur cette table (hormis l'index de partition) ne sont pas partitionner....
Comment faire pour partitionner aussi les index de cette table?
Merci d'avance
tu recrées l'index avec le paramètre LOCAL mais attention, ce n'est pas forcément judicieux notamment si la requête qui utilise l'index doit "traverser" les partitions.
Merci pour l'info.Citation:
Envoyé par orafrance
L'index "traverse" effectivement la partition. Dans ce cas là, faut t'il alors ajouter le champ de référence de la partition dans l'index pour qu'il soit plus efficace?
Non, dans ce cas là vaut mieux pas utiliser l'option LOCAL en principe ;)
Merci pour ton aide!
Je suis bien interesse par votre discussion. merci
Et Je comprends pas tres bien le "ce n'est pas trop judicieux" sur la partition d'index.
Je suis actuellement dans le meme cas.
J'ai une tres grosse table que j'ai partitionne :
- par periodes de temps (mois par mois)
- puis repartitionne par des divisions (cad departement, service ou organisation dans l'entreprise) car les personnes n'ont acces qu'aux donnees de leur division.
Hors ils se peut que quelques personnes hierarchiquement bien place aient aussi le droit de voir plusieurs divisions (Big boss entre autre)
Est-ce cela le fait de "traverser" les partitions et pourquoi ce n'est pas judicieux alors que le fait de partitionner te reduit l'acces I/O ?
Pourquoi ne devrais-je pas partitionne mon index ?
D'avance Merci
déjà j'ai le sentiment que le partitionnement n'est pas dans le bon sens. Si tes requêtes porte sur un département sans restriction sur la date alors il va y avoir des problèmes de perfs puisque pour avoir tout un département tu vas parcourir toutes les partitions sur le mois :?
parcourir plusieurs partitions ce n'est pas forcément génant mais dans ce cas un index global a des chance d'être plus performant. Dans ton cas, le soucis est plus sur le parcourir des mois que sur les divisions. Si un user veut récupérer toutes les lignes de sa division, le partitionnement est inutile puisqu'il parcourt tous les mois. Le partitionnement par mois a un sens fonctionnel ou c'est uniquement pour les purges ?
Partitionner ne réduit pas les IO si tu ne te sers pas de ce partitionnement. Et si tu traverses toutes tes partitions alors le partitionnement est inutile, voir même, aggrave les perfs :?
Merci pour la reponse et desole pour la lenteur de la mienne.
Les requetes renvoyees utilisent a plus de 80% de select sur le temps et sur les divisions.
Je croyais que partitionner equivalait a decouper la table en saucisson et qu'Oracle se debrouillait apres via un arbre de choix.
Je m'explique :
- je decoupe par mois (partition)
- je redecoupe par division (subpartition)
Si j'ai par exemple 10 mois avec 3 divisions, ca me fait au total 30 partitions (ou 30 petites tables).
Si je fais une requete uniquement sur une division (et donc pas sur les mois), il va aller dans la partition du premier mois choisir la subpartition de la division.
Puis dans la deuxieme, etc ...
Non, je me trompe ?
A moins que l'image du decoupage en petite table ne soit pas bonne.
En tout cas, j'ai pu faire des tests sur une table (fact table) de 23 millions d'enregistrement avec schema classique (star) avec bitmap index sur les cles et un select sur la partition.
Apres partition, je n'avais plus que 4 millions d'enregistrement et les gains de performances etaient de 30% mais sur 1 minutes trente, c'est pas assez.
En dessous de 100 000, la requete renvoie bien un temps inferieur a 7 secondes. Alors je m'oriente vers les vues materialisees. Bref, j'explore.
Merci. bonne journee.
bitmap index sur une clé ? :koi: Ca risque fort d'être catastrophique comme index :?
Je m'exprime peut etre mal.
Je te met en lien la documentation oracle sur l'optimization des Star Queries :
http://download.oracle.com/docs/cd/B...htm#sthref1583
Et ici un petit bout :
To get the best possible performance for star queries, it is important to follow some basic guidelines:
- A bitmap index should be built on each of the foreign key columns of the fact table or tables.
- The initialization parameter STAR_TRANSFORMATION_ENABLED should be set to TRUE. This enables an important optimizer feature for star-queries. It is set to FALSE by default for backward-compatibility.
C'est que j'ai fait.