Discussion :

[sgora]

En ce qui concerne le partitionnement, si on partitionne l'index en local par année, en correspondance avec les partitions de la table, on ne parcourra qu'une partition d'index, ce qui revient à dire qu'on va sans doute gagner un niveau deans le parcours de l'arbre de l'index.
Donc si pour obtenir une ligne spécifique tu parcours actuellement mettons trois blocs d'index et un bloc de la table, tu vas (peut-être, faudrait tester) gagner une I/O, soit un bloc d'index de moins à lire.
Tu vas donc gagner, mais pas beaucoup, sur chaque exécution.

[SheikYerbouti]

Gagner peu, peut être relatif également, car certains traitements durent plus d'une heure.

[sgora]

Après, tout dépend des traitements, si ceux-ci utilisent l'index, on va peut-être gagner quelques % si on passe des centaines de milliers de fois par la PK.
En revanche, pour du FTS, le gain va être considérable.
Il y a peut-être des traitements qui passent aujourd'hui par l'index qui gagneraient après partitionnement à faire des FTS !

[mnitu]

Comprimer l'index permet de réduire le nombre des I/O dans certains cases (index à plusieurs niveau que "normal") d'où la question sur la valeur de la colonne BLEVEL. Comme dans tous autre solution d'acceleration de la performance il y a un prix à payer. Seulement une analyse contradictoire peut dire si ça va le coût ou pas.

Pour les traitement qui durent des heures, il peut y avoir des autres causes. La meilleur chose est de activer la trace SQL étendue et d'analiser le fichier trace en utilisant un outil de type profiler de traitement (tvd$tat par exemple). Comme ça il devient vite visible:

• où le temps passe
• combien on peut espèrer gagner pour chaque solution envisageable

ce qui permet de prendre une décision basée sur des données fiable.

[sgora]

De toute manière, il n'y a pas de mystère. La seule manière de gagner beaucoup consiste à optimiser effectivement le code (et les stats, qui sont également très importantes).

Par exemple, si tu as un traitement qui veut sélectionner toutes les lignes d'une année donnée pour les traiter et qui passe par la PK, ça peut se révéler long et coûteux, alors que passer par un FTS sur une table partitionnée par année sera bien plus performant en termes d'I/O. Dans ce cas, le partitionnement agit comme un index "gratuit" (pas de coût de création, mise à jour d'un index supplémentaire).

Suivant tes traitements, créer des index sur d'autres champs de la table pourrait aussi se révéler plus utile que le partionnement. Tout dépend de ton code...

[SheikYerbouti]

Il n'y a pas vraiment de requêtes sur des ensemble, mais plutôt de l'accès direct dans des boucles, dont voici un example schématique:

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
 
For employe in 
(
  select employe
  from   societe
  where  soc = x
) Loop
  For lig in 1 .. 100 Loop
    Select tx
    From   XXX
    Where  soc = 
    and    annee = 
    and    employe = 
    and    C1 = lig
    ...
  End loop;
End loop;

[sgora]

Reste à déterminer si la solution la plus efficace est de faire des boucles imbriquées comme l'exemple que tu donnes, ou bien des jointures entre les tables considérées, cela dépend surtout du volume de données. Si tes critères dans les clauses where sont très discriminants, la solution des loops sera sans doute supérieure.
Si par contre les critéres sont peu sélectifs et le volume des tables important, alors le FTS avec jointure de type hash est en principe le plus performant.

Pour revenir au partitionnement, son effet sera peu ou pas perceptible dans le premier cas, il sera très utile dans le second.

[SheikYerbouti]

Comme je l'ai dis, je ne peux pas toucher aux requêtes existantes.

[mnitu]

Il n'y a pas vraiment de requêtes sur des ensemble, mais plutôt de l'accès direct dans des boucles, dont voici un example schématique:

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
 
For employe in 
(
  select employe
  from   societe
  where  soc = x
) Loop
  For lig in 1 .. 100 Loop
    Select tx
    From   XXX
    Where  soc = 
    and    annee = 
    and    employe = 
    and    C1 = lig
    ...
  End loop;
End loop;

Quelle version d'Oracle ?
For lig in 1..100 signifie BULK FECTHING pour le premier select ? Et pour le deuxième ?
Il y a des autres select après le ... et avant END LOOP?
Tu ne veux pas tenter la trace SQL et le profiler ?

[sgora]

Bon, dans ce cas là, le partitionnement n'aura pas de grande incidence sur les performances de l'application, il peut être utile sur d'autres aspects (facilité d'administration des tables volumineuses, par exemple, ou calcul de statistiques uniquement sur la partition de l'année courante...)

[SheikYerbouti]

Mnitu,

Oracle 11g.
l'exemple que je donne est schématique , et il faut noter que je ne peux modifier les requêtes stockées dans des centaines de modules externes...
Soit je peux jouer sur l'architcture de la table, soit je ne fais rien.

[mnitu]

Mnitu,

Oracle 11g.
l'exemple que je donne est schématique , et il faut noter que je ne peux modifier les requêtes stockées dans des centaines de modules externes...
Soit je peux jouer sur l'architcture de la table, soit je ne fais rien.

La question sur version c'était parce que il y a une optimisation des boucles avec un curseur implicite For c In (Select ...) pour faire du bulk fetch derrière la scène.

Je ne pense pas qu'il est possible d’améliorer ce traitement sans toucher aux requêtes. Mais, je te conseille de faire la trace SQL et d'utiliser tvdxtat (version beta c'est gratuit) pour faire le profil du traitement. Ce profil pourrait indiquer si des solutions alternatives existent mais surtout quel pourcentage de gain peut-on obtenir.

[SheikYerbouti]

Ok, merci

[pachot]

Bonjour,

J'ai quelques remarques à faire:

1) Le partitionnement n'est pas forcément utile pour les performances de l'appli, mais aussi de la maintenance. Si tu te retrouve à purger les anciennes années, alors un partitionnement par année rends celà immédiat. Si tu a envie de réorganiser une table ou reconstruire un index (pour quelque raison que ce soit), le faire partition par partition rendra la chose plus facile...

Donc vu la grosseur de la table, je pense qu'un partitionnement par année est déjà une bonne chose.

2) Pour l'accès par PK, il faut disintguer les cas de l'index local ou global.

Index global sur table partitionnée: l'index sera un peu plus gros, car chaque entrée d'index aura 4 octets de plus (extended ROWID)

Index local sur table partitionnée: comme la clé de partition est inclue dans la cléf primaire, pas de pb. Les accès par clé primaire utilisent une partition d'index, donc probablement plus rapide (b-arbre moins profond). Tu peux même aller plus loin que l'année dans ce cas: mois, semaine, ...

D'après ce que tu présente ici, un index local sur table partitionnée me parait judicieux.

Et pourquoi pas partitionner sur SOC et sous-partitionner sur ANNEE ?
Celà te permets de mettre ensemble les enregistrements d'une même SOC, et comme ton code accède à une SOC particulière, c'est mieux de les regrouper ('clusteriser') car tu aura plus de chance de trouver les blocs en cache à chaque fois.

Et pourquoi pas une IOT (index organized table) partitionnée ?
C'est l'idéal pour un accès par PK

Tu devrais pouvoir te retrouver à lire seulement 1 ou 2 blocs par requête, et la plupart du temps en cache.

Cordialement,
Franck.

[mnitu]

...
Et pourquoi pas une IOT (index organized table) partitionnée ?
C'est l'idéal pour un accès par PK

Tu devrais pouvoir te retrouver à lire seulement 1 ou 2 blocs par requête, et la plupart du temps en cache.

Cordialement,
Franck.

C'est pas la peine dans ce cas!

[pachot]

C'est pas la peine dans ce cas!

Pourquoi ? L'idée c'est d'éviter d'aller voir un bloc de plus en allant lire la table pour avoir la colonne 'tx' qui n'est pas dans l'index.
1 bloc de moins, sur un accès qui lit 2 blocs d'index, c'est 30% de perf gagnés

[SheikYerbouti]

La partition par année est la seule (à mon avis possible) puisque le nombre de sociétés se chiffre en centaines.
Pour l'IOT, j'ai déjà fait le test sans constater la moindre amélioration.

[mnitu]

Pourquoi ? L'idée c'est d'éviter d'aller voir un bloc de plus en allant lire la table pour avoir la colonne 'tx' qui n'est pas dans l'index.
1 bloc de moins, sur un accès qui lit 2 blocs d'index, c'est 30% de perf gagnés

Salut Frank,

Je suis d'accord avec toi pour une table où la pk est c1, c2, c3, c4 et il y encore c5 et peut être c6.
Mais, pas par une table où on a la pk c1, c2, c3, c4 et après c5, c6, .. c12. L'index associé à la pk est c1, c2, c3, c4. Après que la table est organisé en IOT l'index (table en mêm temps) devient c1, c2, … c12. Pense tu que cela va apporter un gain de performance pour une requête de type

Code :

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

1
2
 
Select … from XXX where c1 and c2 and … c4 ?

[pachot]

Pense tu que cela va apporter un gain de performance pour une requête de type

Code :

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

1
2
 
Select … from XXX where c1 and c2 and … c4 ?

Ca dépends de ce qu'il y a a dans les '...' s'il n'y a que du c1,c2,c3,c4 alors non, ça ne change rien. Mais s'il y a une colonne non indexée, alors l'IOT évite d'aller faire une lecture de plus.

[SheikYerbouti]

Il n'y a que les colonnes de la PK dans la clause Where, raison pour laquelle le test en IOT n'a rien donné de concluant.
Merci pour votre participation.