Discussion :

[Greg07]

Voilà mon problème : j'ai quelques tables qui concentrent la majorité des données et qui sont la cible de la majorité des requêtes.
Je suis sous Oracle 9.2.
Je me demandais ce qui serait le plus intéressant à faire :
partitionner les tables,
partitionner les indexes de tables,
autre chose ?

Table 1 : 100 M de lignes 34 Go 4 indexes, 1 unique
Table 2 : 39 M de lignes 15 Go 7 indexes, 1 unique
Table 3 : 14 M de lignes 5 Go 11 indexes, 1 unique
Table 4 : 12 M de lignes 2 Go 1 indexe unique
Table 5 : 10 M de lignes 1 Go 3 indexes, 1 unique

Et surtout je me demandais comment faire !

D'avance merci,
Greg

[orafrance]

11 et 7 indexes c'est beaucoup.

A part ça :

Y a-t-il des problèmes de perf ?
En écriture, lecture ou les deux ?
Sur toutes les tables ?
Toutes les données sont utiles ou seulement les plus récentes ?
Quel critère de partitionnement envisages-tu ?

[Greg07]

11 et 7 indexes c'est beaucoup.

Je suis bien d'accord. Mais je n'ai pas le "cut", je peux simplement faire des propositions... argumentées

Y a-t-il des problèmes de perf ?
En écriture, lecture ou les deux ?
Sur toutes les tables ?
Toutes les données sont utiles ou seulement les plus récentes ?
Quel critère de partitionnement envisages-tu ?

Oui il y a de gros problèmes de perf en lecture. (En écriture je ne sais pas vraiment comment ça se passe.)
Sur au moins 4 de ces 5 tables !
Pour l'instant les tables contiennent 4 ans de données, mais les requêtes portent essentiellement sur l'année en cours, et régulièrement sur l'année dernière. Presque rien sur les années précédentes N-2, N-3...
Je pensais partitionner les tables en fonction des années, et éventuellement des mois (mais je ne suis pas sûr que ce soit efficace car la majorité des requêtes portent sur l'année entière).

[orafrance]

moi ça me semble prématuré de partitionner si tu n'as pas fait un semblant d'analyse sur les causes des problèmes de perf: extent trop petit, initrans mal taillé, index incorrect, etc...

[Greg07]

Argh...
Alors je ne suis pas DBA, je suis plus du côté "restitution" et nous avons de gros problème de temps de réponse.
Je cherche donc comment améliorer les choses avec mes petits moyens...
Du coup je ne comprend pas bien : "extent trop petit, initrans mal taillé, ..." pour les indexs je pense qu'ils ne sont pas trop mal, on doit quand même pouvoir faire du ménage (sur les 11 et les 7).

[nuke_y]

Moi aussi je pense à partitionner des index et des données. Principalement pour ne pas garder online des Go de données d'années passées sur lesquelles on ne travaille plus du tout.

[remi4444]

Il faut surtout regarder les plan d'exécution des requêtes longues (c'est assez facile à voir avec toad par exemple puisque ce sont elles qui sont la majeures partie du temps dans les session actives.

Parcque si tu ne fais pas ça tu risque de faire tout un gros travail pour rien....

[orafrance]

Alors je ne suis pas DBA, je suis plus du côté "restitution" et nous avons de gros problème de temps de réponse.

Il est alors temps de faire appel aux compétences de ton DBA

chacun son boulot

[Greg07]

Il faut surtout regarder les plan d'exécution des requêtes longues (c'est assez facile à voir avec toad par exemple puisque ce sont elles qui sont la majeures partie du temps dans les session actives.

Parcque si tu ne fais pas ça tu risque de faire tout un gros travail pour rien....

J'ai bien Toad

Il est alors temps de faire appel aux compétences de ton DBA

chacun son boulot

Si seulement c'était aussi simple

[Harry Potter]

Si tu as les moyens et la place de le faire, ça vaut le coup de faire un test de perf après avoir partitionné tes tables sur l'année, puis recrée tes index en local non-préfixé (seulement ceux comprenant la date dans l'index).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
CREATE TABLE TOTO (
  idassure	NUMBER(10)	NOT NULL,
  date_maj	DATE		NOT NULL,
  idpersonn	NUMBER(12),
  ) TABLESPACE &tbs_data
PARTITION BY RANGE(date_maj)
(	PARTITION 2001 VALUES LESS THAN (TO_DATE('01/01/2002','dd/mm/yyyy'),
	PARTITION 2002 VALUES LESS THAN (TO_DATE('01/01/2003','dd/mm/yyyy'),
...
	PARTITION 2006 VALUES LESS THAN (maxvalue)
);
 
Ensuite tu peux créer un  index en local
CREATE INDEX TOTO_IDPERSONN_IN ON TOTO
(idpersonn)
TABLESPACE TITI LOCAL;

Tu vas alors avoir un index sur la colonne idpersonn mais partitionné sur la colonne datemaj (Attention, cet index ne sera correctement utilisé si et seulement si tu as la clause AND datemaj = 'date_voulue' dans tes requêtes.

Les autres types de partitionnement sont par list ou par hachage.