Partition vs Index

Bonjour,

Soit une table partitionnée sur un champ A.
1) Est-il utile de mettre en plus un index sur ce champ A ?

2) Pour gagner en rapidité, Vaut-il mieux faire une sous-partition sur un champ B de cette même
table ou bien seulement mettre un index local sur ce champ B ?

Merci d'avance.

Bonjour,

Vous trouverez les infos ici :
http://blog.developpez.com/sqlpro/p9...ur_ameliorer_l

Que voulez vous dire par sous-partition ?

Je n'ai pas vraiment trouvé mes réponses sur le site...

J'entends par "sous-partition" créer une partition B dans une partition A.
Cependant je crois que ce n'est pas possible en fait...

Citation:

---

Envoyé par blackstrobe

1) Est-il utile de mettre en plus un index sur ce champ A ?

---

Peut-être, peut-être pas.
Par exemple, si vous partitionnez une table sur une date par mois, et que cette colonne a une précision au mois l'index est inutile.
Si la colonne conserve une précision à la seconde, et que vous cherchez des données avec cette précision, oui l'index sera très efficace.
Et il y a toute la zone entre ces deux extrêmes qui mérite des tests sur votre base avec votre matériel.

Citation:

---

Envoyé par blackstrobe

2) Pour gagner en rapidité, Vaut-il mieux faire une sous-partition sur un champ B de cette même
table ou bien seulement mettre un index local sur ce champ B ?

---

Ça va dépendre de la sélectivité de votre colonne B.
Faible sélectivité => une sous partition
Forte sélectivité => un index local

Par contre, attention aux tables avec des sous partitions, si vous avez trop de sous-partitions, votre catalogue en particulier et donc votre base en général va souffrir.
Je n'utilise qu'extrêmement rarement des sous-partitions dans un environnement à volumétrie déjà significative, 30 To.

Merci pour ta réponse !

Concernant ton explication à ma 1ère question, je n'ai pas bien compris.
Tu pourrais donner des exemples de valeurs ?

Non parce que si l'on a un champ date "dd/mm/yyy hh:mm:ss" (avec une précision à la seconde donc), comment faire pour ne partitionner que sur le mois ?

C'est en fonction de la précision indiquée au niveau du partitionnement, par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

create table t_part_1 ( col1 date , col2 number(10) ) partition by range (col1) ( partition p2015 values less than (to_date('2016-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016 values less than (to_date('2017-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2017 values less than (to_date('2018-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss')) );   create table t_part_2 ( col1 date , col2 number(10) ) partition by range (col1) ( partition p2016092500 values less than (to_date('2016-09-25 01:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092501 values less than (to_date('2016-09-25 02:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092502 values less than (to_date('2016-09-25 03:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092503 values less than (to_date('2016-09-25 04:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092504 values less than (to_date('2016-09-25 05:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092505 values less than (to_date('2016-09-25 06:00:00', 'yyyy-mm-dd hh24:mi:ss')) , partition p2016092506 values less than (to_date('2016-09-25 07:00:00', 'yyyy-mm-dd hh24:mi:ss')) );

---

La première table a une granularité de partition à l'année, la seconde à l'heure.
Rien n'empêche de mixer plus granularité : sur des données plus anciennes on peut souvent se contenter de partitions plus larges, mais encore une fois c'est le besoin et l'utilisation qui vont dicter le cycle de vie de vos données.

Notez que si vous êtes au moins en 11g, vous avez accès au partitionnement automatique par intervalle :
https://oracle-base.com/articles/11g...ncements-11gr1

C'est plus clair.
Merci beaucoup pour tout !