Lenteur à l'exécution de la requête

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:

---

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 :

Pièce jointe 585514

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

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.

Bonjour,

Déjà le fait de préciser :

Code:

---

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.

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

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,

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

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:

---

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.

Citation:

---

Envoyé par yoyolut

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:

---

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.

Attention ligne 10 : whennot matched then update

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,

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:

---

1 2 3

CREATE BITMAP INDEX sta_recl_bitmap_idx ON TH_RECLAMATION (STA_RECL);

---

On peut aussi tenter :

Code:

---

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.

À 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.