Discussion :

[yoyolut]

Bonjour à tous,

Nous avons passé notre base de la V11 à la V12. Depuis nous constatons un gain important sur l'ensemble de nos requêtes, sauf sur une ou la perte de temps est colossale et n'est pas compensé par le gain obtenu sur les autres requêtes.

La requête en question :

Code :

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

1
2
UPDATE TH_RECLAMATION R 
SET R.DATE_ETAT_T = (SELECT MIN(NVL(RC.DHISTO,XDATE)) DATE_ETAT FROM US_ODS.TS_RECLAMATION_COM RC,T_EVNT_ELEMENT@DBLINK_H8803_CC_00 TE WHERE UPPER(TE.ACTION) = 'TRAITEMENT' AND RC.EVNT = TE.CODE AND RC.NUME_RECL = R.ID_RECL) WHERE (R.STA_RECL = 't' OR R.STA_RECL = 'x' OR R.STA_RECL = 's')

Il s'agit de l'update d'une table via un select d'autre table.

Un explain plan de cette requte nous renvoi ceci :



La mise à jour des statistiques sur les tables concernées à hauteur de 10% ne résout visiblement pas le souci, l'explain plan reste identique. Le rebuild de l'index de la table TH_RECLAMATION ne résout pas le problème.

Ma question est donc la suivante, par quel bout dois je prendre le problème pour le résoudre, le temps annoncé par l'ex-plain plan de 7:00:00 est énorme, mais je ne sais pas comment savoir ce qui explique ce temps élevé. C'est d'autant plus étonné que sur les 130 Jobs réalisés seul celui-ci a un moins bon résultat qu'avant la migration.

D'avance merci,
Yo

[al1_24]

Essaye de reformuler la requête avec un MERGE (sans la branche WHEN NOT MATCHED bien sûr ).
Cette commande est souvent beaucoup plus efficace qu'un UPDATE avec jointure.

[vanagreg]

Bonjour,

Déjà le fait de préciser :

Code :

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

UPPER(TE.ACTION) = 'TRAITEMENT'

va empêcher l'utilisation potentielle d'un index sur TE.ACTION, sauf si tu crées un FBI. Es-tu obligé de faire cet UPPER?
De plus, y-a-t-il un index sur R.STA_RECL? Tu mets à jour que pour 3 valeurs de cette colonne, mais peut-être que ce n'est pas assez sélectif.

[escartefigue]

Et aussi, remplacer la jointure décrite dans le WHERE par l'utilisation de l'opérateur JOIN, ça peut jouer et ce sera plus clair

[yoyolut]

Bonjour,

Merci pour vos réponses !

Je complexifie le problème, je n'ai pas vraiment la main sur la requête, disons que j'ai plutôt le rôle DBA que développeur ici. Ce qui m'amène a chercher dans la voie DBA c'est que cette même requête prenait 4 fois moins de temps en 11 qu'en 12.

Je n'ai pas d'index sur STA_RECL uniquement sur ID_RECL

Le constat que j'ai pu faire c'est qu'oracle fait une grosse opération de lecture sur le Tablespace au moment du passage de la requête.

Bonne journée,

[vanagreg]

Tu as le même plan d'exécution en 11g?

[escartefigue]

Les colonnes de jointure portent des noms différents, du coup, question de base : sont elles bien de même type et de même longueur ?

Code :

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

1
2
       AND RC.EVNT      = TE.CODE 
       AND RC.NUME_RECL = R.ID_RECL

Un index sur STA_RECL ne sera pertinent que si les valeurs recherchées sont discriminantes. A vérifier.

[Waldar]

je n'ai pas vraiment la main sur la requête, disons que j'ai plutôt le rôle DBA que développeur ici.

Vous avez tout à fait le droit de proposer une meilleure requête aux développeurs.
En en plus vous pouvez supplanter le plan d'une requête par une autre en tant que DBA.

Ca vaut vraiment le coup de vérifier ce merge :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 merge into TH_RECLAMATION tgt
 using ( select RC.NUME_RECL
              , min(NVL(RC.DHISTO, XDATE)) as DATE_ETAT
           from US_ODS.TS_RECLAMATION_COM         RC
           join T_EVNT_ELEMENT@DBLINK_H8803_CC_00 TE on TE.CODE = RC.EVNT
          where UPPER(TE.ACTION) = 'TRAITEMENT'
       group by RC.NUME_RECL) src
    on (src.NUME_RECL = tgt.ID_RECL
   and  tgt.STA_RECL in ('t', 'x', 's'))
  when matched then update
   set tgt.DATE_ETAT_T = src.DATE_ETAT;

Edit : Coquille corrigée, merci al1_24.

[al1_24]

Attention ligne 10 : whennot matched then update

[yoyolut]

Merci à tous pour vos réponses

Je vais travailler au sujet avec vos propositions. Et recherche la réponse à certaines questions que vous posez. Je fais cela demain. Et je vous ferrais un retour.

Pour répondre a l'aspect philosophique, oui je peux proposer une meilleure option au développeur, mais il n'est pas en interne c'est un outil tierce. Et mon souci est le fameux ça marchait en 11 ça doit marché en 12.

Bonne soirée à tous,

[Paraffine]

Existe t-il un index sur les colonnes NUME_RECL (desc), DATE_HISTO (desc) sur la table TS_RECLAMATION_COM ?
Sinon, cela vaut vraisemblablement la peine d'en créer un.

Ainsi peut-être qu'un index bitmap (index pour les valeurs de faible cardinalité) sur la colonne STA_RECL de la table TH_RECLAMATION :

Code SQL :

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

1
2
3
CREATE BITMAP INDEX 
sta_recl_bitmap_idx
ON TH_RECLAMATION (STA_RECL);

On peut aussi tenter :

Code SQL :

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

1
2
3
CREATE BITMAP INDEX 
action_evnt_bitmap_idx 
ON T_EVNT_ELEMENT (UPPER(ACTION));

Puisque la requête met à jour une colonne date, il faudrait aussi vérifier s'il existe un (ou plusieurs) index dessus ; s'il est vraiment TRÈS pénalisant en Update, cela vaut peut-être la peine de le dropper, quitte à le recréer après le batch ; j'ignore combien de temps il faudrait à Oracle pour reconstruire l'index, mais ça peut valoir la peine.

[JeitEmgie]

À essayer :
créer une vue côté DBLINK avec le WHERE UPPER avec un index sur le UPPER(TE.ACTION) et accéder cette vue dans votre query.