Discussion :

[SheikYerbouti]

Bonjour,

Je travaille sur une table contenant plusieurs millions d'enregistrements.
Chaque année, elle grossit d'autres millions de lignes.
Le traitement s'effectue toujours sur une année donnée, donc une partie de la table. Le partionnement de cette table sur la colonne annee (number) semble approprié.
Le simple fait de créer les différentes partitions est-il suffisant, ou faut-il également agir sur l'indexation. Aujourd'hui, seule un PK est définie sur cette table. J'ajoute, pour finir, qu'il est hors de question de modifier les requêtes existantes qui agissent sur cette table.
D'avance merci.

[mnitu]

Bonjour,

Je travaille sur une table contenant plusieurs millions d'enregistrements.
Chaque année, elle grossit d'autres millions de lignes.
Le traitement s'effectue toujours sur une année donnée, donc une partie de la table. Le partionnement de cette table sur la colonne annee (number) semble approprié.
Le simple fait de créer les différentes partitions est-il suffisant, ou faut-il également agir sur l'indexation. Aujourd'hui, seule un PK est définie sur cette table. J'ajoute, pour finir, qu'il est hors de question de modifier les requêtes existantes qui agissent sur cette table.
D'avance merci.

Les requêtes qui utilisent la clé primaire n'ont pas besoin de partitionement.
Les requêtes qui font full table scan vont automatiquement béneficier de la partition.
Mais il faut voir la tête des requêtes pour parler index.
Il y a un chapitre (3) du Effective Oracle By Design du Tom Kyte disponible en télechargement sur sont site qui parle du partitionement.
Il semble que le but du partitionement dans ton cas c'est la performance, est-ce vrai ?

[sgora]

Tu peux aussi créer des partitions sur tes index, sachant que ce ne sera pas l'idéal pour la PK, puisque tu devras le déclarer en global sur la table, ce qui est moins pratique de d'avoir une partition locale, où on a correspondance parfaite entre partition de table et partition d'index.

On peut ruser pour contourner cela en mettant l'année dans la PK, mais c'est bricoler...

Ca dépend aussi si tes traitements se servent beaucoup de la PK, si ce n'est pas le cas, partitionner les tables suffit à réduire les temps de traitement.

[SheikYerbouti]

oui, les traitements n'utilisent que la PK.

[sgora]

Dans ce cas, on peut préfixer la PK par l'année, on pourra alors construire un index partitionné en local sur la table partitionnée, ce qui veut dire qu'on est sûr dans ce cas de n'utiliser qu'une partition de table et la partition correspondante de l'index.

[SheikYerbouti]

Dans notre cas, l'année est en 2ème position dans la PK et je ne suis pas certain que la passer en première position n'ait auncune incidence sur les requêtes existantes.

[SheikYerbouti]

Voici le plan sur la table partitionnée avec sa PK sans index particulier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
SQL> SELECT * FROM XXXX WHERE annee = 2008 and ROWNUM < 100
  2  /
99 ligne(s) sélectionnée(s).
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=99 Bytes=52
          47)
   1    0   COUNT (STOPKEY)
   2    1     PARTITION RANGE (SINGLE) (Cost=2 Card=101 Bytes=5353)
   3    2       TABLE ACCESS (FULL) OF 'XXXX' (TABLE) (Cost=2 Card=1
          01 Bytes=5353)

Il semblerait que la bonne partition sélectionée.

[mnitu]

oui, les traitements n'utilisent que la PK.

Donc partitionner ne servira pas à grand chose.
Mais, est ce que t'as un exemple (table, pk, requête)?
Et c'est quoi le problème ?

[SheikYerbouti]

Donc partitionner ne servira pas à grand chose.
Mais, est ce que t'as un exemple (table, pk, requête)?
Et c'est quoi le problème ?

Il n'a pas de problème a proprement parler. Je cherche des solutions d'optimisation s'il y en a. cette table fait 70 millions de lignes et il me semblait que le partitionnement était justement fait pour améliorer les temps de traitement des requêtes.

[mnitu]

Il n'a pas de problème a proprement parler. Je cherche des solutions d'optimisation s'il y en a. cette table fait 70 millions de lignes et il me semblait que le partitionnement était justement fait pour améliorer les temps de traitement des requêtes.

Je dirait plutôt d'améliorer les temps de traitement des certaines requêtes.