Discussion :

[rcb73]

Bonjour,

j'ai une requête SQL qui porte sur une colonne indexée:

Code :

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

1
2
3
UPDATE m2oequipement eq
SET eq.m2oCodeSup = 'SUP_INCO'
WHERE eq.sysClass = 'm2oModule'

Le résultat de cette requête porte sur environ 93% de la table, l'index n'est pas donc pas très discriminant.
Lorsque j'affiche le plan d'exécution, je vois qu'il exécute un FULL SCAN.

Lorsque j'affiche le plan d'exécution de la même requête mais avec une condition sur une valeur plus discriminante (6%):

Code :

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

1
2
3
UPDATE m2oequipement eq
SET eq.m2oCodeSup = 'SUP_INCO'
WHERE eq.sysClass = 'm2oRepeteur'

Je vois qu'il fait un RANGE SCAN.

Est-ce qu'ORACLE décide ou non d'utiliser l'index pour sa requête en fonction du fait qu'il soit discriminant ou pas ?
Dans ce cas il va quand même interroger l'index au préalable ?

merci !

[pachot]

Bonjour,

Est-ce qu'ORACLE décide ou non d'utiliser l'index pour sa requête en fonction du fait qu'il soit discriminant ou pas ?

Oui, Au moment où la requête est parsée, il choisit le meilleur accès.

Dans ce cas il va quand même interroger l'index au préalable ?

Oui et non. Il interroge les statistiques (qui elles sont calculées auparavant en interrogeant l'index). Ou s'il n'y a pas de statistiques, il fait du dynamic sampling (en interrogeant un échantillon de l'index).

Ici c'est les stats sur les colonnes, probablement des histogrammes, qui lui permettent d'estimer la selectivité de chaque valeur.

Cordialement,
Franck.

[rcb73]

merci pour la réponse, c'est très clair.

Est-il possible d'optimiser une requête aussi simple ?
La table fait environ 400 000 lignes à l'heure actuelle mais va progressivement grossir jusqu'à environ 5 millions de lignes...

Le premier update restera sur une proportion de 93% des lignes de la table.

Il semblerai également que cette requête soit consommatrice en tablespace UNDO, faut-il faire une boucle avec des commits intermédiaires pour palier à ce problème ?

merci.

[Waldar]

Vous pouvez déjà filtrer les lignes qui ont la bonne valeur :

Code :

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

1
2
3
4
UPDATE m2oequipement eq
   SET eq.m2oCodeSup = 'SUP_INCO'
 WHERE eq.sysClass = 'm2oModule'
   AND (eq.m2oCodeSup <> 'SUP_INCO' OR eq.m2oCodeSup is null);

[mnitu]

How to Update millions or records in a table

[rcb73]

Vous pouvez déjà filtrer les lignes qui ont la bonne valeur :

Code :

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

1
2
3
4
UPDATE m2oequipement eq
   SET eq.m2oCodeSup = 'SUP_INCO'
 WHERE eq.sysClass = 'm2oModule'
   AND (eq.m2oCodeSup <> 'SUP_INCO' OR eq.m2oCodeSup is null);

avec cette requête je suis moins gourmand en tablespace undo mais je perds un peu en performances c'est ça ?

[rcb73]

How to Update millions or records in a table

merci pour le lien, il y a plusieurs choses intéressantes, je vais m'en inspirer pour mes traitements.

[ora_home]

merci pour la réponse, c'est très clair.

Est-il possible d'optimiser une requête aussi simple ?
La table fait environ 400 000 lignes à l'heure actuelle mais va progressivement grossir jusqu'à environ 5 millions de lignes...

Le premier update restera sur une proportion de 93% des lignes de la table.

Il semblerai également que cette requête soit consommatrice en tablespace UNDO, faut-il faire une boucle avec des commits intermédiaires pour palier à ce problème ?

merci.

Bonjour,
Normalement si la requête sera exécuter une seule fois, vaut mieux de recréer la table avec les nouveaux valeur du champ que vous voulez modifier, puis DROPER la table mère, comme ça tu ne généras pas des UNDO.

[rcb73]

Malheureusement cette table est amenée à être modifiée en même temps par d'autres traitements, donc il y a un risque d'incohérence de données.
Est-ce qu'il y a un moyen de contourner ce problème ?

[pachot]

Bonjour,
Il faudrait comprendre exactement le besoin et peut-être revoir le design général. Les use-case où il est nécessaire de faire un update sur des millions de lignes sont assez rares.
Cordialement,
Franck.

[fahdijbeli]

bonsoir,
si javais compris ton problème , il faut utiliser la méthode des partitions des tables , faire googler pour comprendre ça

[rcb73]

Bonjour,
Il faudrait comprendre exactement le besoin et peut-être revoir le design général. Les use-case où il est nécessaire de faire un update sur des millions de lignes sont assez rares.
Cordialement,
Franck.

Le principe est celui-ci :

- au départ on positionne un flag ("eq.m2oCodeSup = 'SUP_INCO'" -> etat de supervision inconnu) sur TOUS les objets d'un certain type d'une table ("eq.sysClass = 'm2oModule'" -> ces objets représentent environ 93% de la table)
- on parcourt l'arbre de ces objets sous certaines conditions, si jamais pendant ce parcourt on rencontre un des objets précédents on met à jour le flag ("eq.m2oCodeSup = 'SUP_OK' ou 'SUP_NOK'" -> etat de supervision ok/nok), à la fin les objets qui n'auront pas été atteint (parcqu'ils ne remplissent pas les bonens conditions) resteront dans l'état positionné auparavant ('SUP_INCO' -> etat de supervision inconnu)

j'espère avoir été assez clair

merci pour votre aide.

[rcb73]

bonsoir,
si javais compris ton problème , il faut utiliser la méthode des partitions des tables , faire googler pour comprendre ça

au vu de mes requêtes, tu penserai faire un partitionnement comment ?
est-ce qu'un type list serait adapté ?
dans ma table (m2oequipement) j'ai une colonne (sysClass) ou seulement 3 valeurs sont possibles :
- 'm2oModule' = 93%
- 'm2oRepeteur' = 6%
- 'm2oConcentrateur' = 1%

cette colonne est souvent une condition de mes requêtes.

merci.

[pachot]

Bonjour,

j'espère avoir été assez clair

Oui. tout à fait clair. Le problème: vous utilisez cette table un peu comme une table de travail. Donc tous les mécanismes de persistence (undo, redo, maintenance des index, etc) sont un travail inutile.

Après traitement, il reste quel pourcentage positionné à SUP_INCO ? S'il y en a peu, alors il faudrait changer le design pour éviter de faire la mise à jour 2 fois.
Peut-être que ce flag devrait se trouver dans une autre table: pas de ligne pour SUP_INCO (donc au début du traitement on la vide avec truncate) puis on remplit avec SUP_OK ou SUP_NOK au fur et à mesure. Par contre, lorsqu'on l'interroge, on fait une jointure (externe si on veut avoir les SUP_INCO)

Cordialement,
Franck.