index partitionné, seul ou accompagné ?

bonjour,

En parcourant les questions (toujours en quete de savoir...), j'ai vu qu'on pouvait partitionner un index, plutôt que la table elle-même. Soit.
Je viens d'essayer, avec un petit + sur certaines tables (de type comptables), rien sur d'autres . (je vérifie avec v$sqlarea).

Question ; comment se comporte ce type d'index si d'autres index sont présents ? Doit-il être seul pour mieux fonctionner ? Peut on donner une priorité à certains index ? Et comment ?

Par exemple, une table stockant depuis 1901 toutes les jolies filles :mrgreen:, avec un index sur la date de naissance et l'ID de la personne, et aussi un index partitionné sur le siècle (permettant normalement un accès plus rapide en cas de select/update avec ce paramètre renseigné)... Est ce bon ?

Le partitionnement d'index n'a d'intérêt que si l'index lui-même est TRES gros et qu'une recherche dans l'index est très longue. J'ai vu des perfs améliorés sur un partitionnement d'index uniquement sur des tables de plusieurs dizaine de millions d'enregistrement et un index avec une très grande cardinalités.

J'ai du mal à suivre.:aie:

Qu'entendez vous par 'si l'index est très gros' ? Parlez vous, du champ sur lequel porte l'index (si oui, comment pourrait-il être très gros) ?

J'ai vu un progrès significatif sur une table assez faible en taille pour vous visiblement (un peu plus d'un million de ligne); mais j'ai bien l'intention de tester sur des tables de moindre taille, dans l'espoir que l'accès aux différentes partition offre un accès plus rapide dans certains cas (recherche ou update global avec le champ indexé en paramètre)

Enfin, que voulez vous dire par 'index avec une très grande cardinalités' ?

Merci !

Citation:

---

Envoyé par olivanto

Qu'entendez vous par 'si l'index est très gros' ? Parlez vous, du champ sur lequel porte l'index (si oui, comment pourrait-il être très gros) ?

---

C'est plus simple d'avoir un index pour retrouver une info dans une encyclopédie de 30 volumes mais si l'index fait 300 pages faut trouver une manière de faciliter la recherche... c'est le but du partitionnement d'index ;)

Citation:

---

Envoyé par olivanto

J'ai vu un progrès significatif sur une table assez faible en taille pour vous visiblement

---

Comparé à un index non partitionné ?

Citation:

---

Envoyé par olivanto

Enfin, que voulez vous dire par 'index avec une très grande cardinalités' ?

---

qui a bcp de valeurs distinctes comme un index unique par exemple ;)

okay........c'est plus clair, merci.

"Comparé à un index non partitionné ?" :

- oui, tout à fait. La différence est assez énorme sur une requete simple avec des agrégats, dont le principal critère est justement le champ indexé de manière partitionné
avant ; V$.ELAPSED_TIME donne 6.973.123 (en moyenne)
après ; V$.ELAPSED_TIME donne 885.461 (en moyenne)
En gros, huit fois plus vite.

Maintenant c'est clair que sur mes tables de petit volume, le gain est plus une satisfaction de DBA amateur qu'un réel besoin utilisateur car il est réduit (1mS en moyenne...:?), mais cela ne peut pas faire de mal....

J'ai encore trois questions...après j'arrête !

- dans quel partition vont les tuples d'un table dont le champ servant à l'index partitionné n'est pas rempli ?

- par défaut Oracle crée l'index dans le tablespace SYSTEM .... j'ai crée le mien dans le tablespace INDX...c'est "plus mieux", non ?

- après avoir crér l'index partionné, vaut-il mieux reconstruire tous les index de la table ?

Et merci encore.

Citation:

---

Envoyé par olivanto

- oui, tout à fait. La différence est assez énorme sur une requete simple avec des agrégats, dont le principal critère est justement le champ indexé

---

En effet ça peut être spectaculaire :ccool:

Citation:

---

Envoyé par olivanto

- dans quel partition vont les tuples d'un table dont le champ servant à l'index partitionné n'est pas rempli ?

---

Ca dépend du critère de partitionnement mais probablement dans la partition de débordement (qui ne répond à aucun des critères de partitionnement)

Citation:

---

Envoyé par olivanto

- par défaut Oracle crée l'index dans le tablespace SYSTEM .... j'ai crée le mien dans le tablespace INDX...c'est "plus mieux", non ?

---

Sans aucun doute puisque le tablespace SYSTEM est difficilement réorganisable. Il faut le réserver au catalogue uniquement.

Citation:

---

Envoyé par olivanto

- après avoir crér l'index partionné, vaut-il mieux reconstruire tous les index de la table ?

---

Pas du tout, l'index vit sa vie, il ne perturbe pas la table et ses indexes ;)

Réponse rapide, bravo.:king:

Je crois avoir fait le tour du sujet, donc je clos mon sujet.

un grand merci !

ps; je vais lire la doc, en effet...

pour plus d'info je t'invite à lire la doc quand même ;)