Performance Update ?

Voila j'ai une requête type update tapant sur davantage de champs:

Code:

---

1 2 3 4

update TEST set TEL = 28 where id_personne = Teddy;

---

Cette requête met énormément de temps a effectuer la mise a jour (130 lignes/secondes contre 2000 lignes/secondes pour un select sur la même table).

Les stats sont à jour, la table ne posséde qu'un index PK.

Voila j'aimerai savoir si il était possible d'améliorer les perfs concernant un update, par exemple avec un hint , ou au niveau serveur ? il ne m'est pas possible pour des raisons applicatives d'utiliser un curseur par exemple.

Un DBA débutant qui vous remerci d'avance.

faudrait voir l'explain plan pour voir si l'index est utilisé à bon escient avec le nombre de lignes updatées par rapport au nombre de lignes total. Est-ce qu'il y a des triggers ou contraintes sur ta table ?

En fait l'update est incorporé de maniére applicative dans le traitement, ci bien que l'utilisateur est incapable de me donner la requête compléte.

Si j'utilise une requête update simple de mon côté le plan d'execution indique bien qu'il utilise l'index PK, il s'agit d'un index partitionné, ainsi que la table.

La baisse de perfs ne peut être du qu'a une mauvaise utilisation de l'index ?, si la clause where ne fait pas reference a l'index il serai donc bon d'en creer un ?

Bah ça peut être à cause de plein de chose, là ça devient bien plus complexe que ton 1° message : partitionnement + clause WHERE complexe... faudrait quand même penser à donner tous les éléments tout de suite :?

déjà, es-tu bien certains que ça vient de l'update ? As-tu fait une trace ou au moins suivi les événements d'attente dans v$session_wait pendant que la requête tourne ?

Non, il a stoppé la session dés qui l'a relance j'observerai les événements sur lesquelles la requête galére dans la vue v$session_events v$session_waits et si ça donne rien je pousserai via une analyze vers tk_prof et je vous tiens au courant.

Mais ma question a la base c y'a t'il des solutions usinés pour améliorer les performances d'un gros update ? sans vraiment rentrez dans le détail de la requête me concernant étant donné que je n'y ai même pas accés :mouarf:

Merci en ts cas Orafrance de ta rapidité.

bah pas vraiment éventuellement vérifier que le type d'index (global ou local) répond bien aux exigences de la partition ;)

Thx Ora, l'index utilise un partitionnement local personnelement rien ne me choque. Demain je demanderai de relancer la requête et j'y verrai de plus prés :aie:.


Je marque pas encore le probléme résolu, j'attend un peu.

C'est quel type de partitionnement de la table? La clé de partitionnement est la colonne indexée?

Oui, le partitionnement se fait par hash sur la même colonne utilisé par l'index PK dc rien de choquant ?

Je vous tiens au jus pour la suite 8-)

non, rien de choquant, y'a combien de partitions ?

8 partitions pour la table et autant pour l'index, hum ?

rien à redire :)

Citation:

---

Envoyé par D_light

Oui, le partitionnement se fait par hash sur la même colonne utilisé par l'index PK dc rien de choquant ?

Je vous tiens au jus pour la suite 8-)

---

Pour résumer alors :
La clé de partitionnement est la clé priamire et la clause WHERE porte sur la clé primaire et le partitionnement est par hash et l'index est local. Rien de choquant dans tout ça ...

Si tout ce qui précède est vrai et que l'instruction UPDATE utilise l'index alors il n'y a pas de raison que l'instruction soit longue. Alors
- soit l'index n'est pas utilisé
- soit autre chose mais liée à l'instruction qui pose le problème (verrou par exemple)

C'est bien sûr dans l'hypothèse que l'instruction UPDATE est l'origine de l'attente en l'absence de mesures de performance précises ...

Bon le client ve pas relancer ts de suite l'update dc je suis contraint au silence, le résumé que tu fais michel est celui ci. Je rajoute qu'il n'y pas de trigger sur la table.

Qd j'affiche le plan d'execution d'un update simple, utilisant la colonne indexe ds la clause where celui ci utilise bien l'index.

Alors peut être des verrous c possible vi, mais sans doute autre chose que j'ignore encore ^^. Je suis en attente. Je vous remerci en attendant de l'attention porté a ma demande.

Re,

Code:

---

1 2 3 4 5 6 7 8 9

SID EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT MAX_WAIT TIME_WAITED_MICRO   44 db file sequential read 1245130 0 1415357 1 113 14153567464 44 SQL*Net message from client 1268866 0 12381 0 1 123812085 44 free buffer waits 123 3 2062 17 98 20619042 44 SQL*Net message to client 1268866 0 147 0 0 1472845 44 log file switch completion 6 0 58 10 34 581769 44 log buffer space 7 0 40 6 12 395655 44 write complete waits 1 0 11 11 11 106455

---

Voici ce que me donne la vue v$session_event

donc il a du mal pr lire les données en mémoire si j'ai bien compris.

Voici le resultat de la mise en trace:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 13176 5.00 165.61 12964 28061 13399 13176 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 13176 5.00 165.61 12964 28061 13399 13176   Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 22       ********************************************************************************   OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 13176 5.00 165.61 12964 28061 13399 13176 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 13176 5.00 165.61 12964 28061 13399 13176   Misses in library cache during parse: 0     OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 0 0.00 0.00 0 0 0 0   Misses in library cache during parse: 0   1 user SQL statements in session. 0 internal SQL statements in session. 1 SQL statements in session.

---

Donc pour moi rien d'inquiétant.

Au niveau serveur la commande TOPAS ne n'indique aucun soucis particulier.

On m'a conseiller de mettre la table en nologging histoire d'éviter l ecriture dans les redos.

Autre indice le plan d'execution de la requête m'indique l'utilisation de "partition hash single", ce qui on m'a dit(on m'en dit des truks ^^) indique qu'il n'utilise pas la parralelisation des procs or dans le script de création d'index et de table il est bien précisé le degre de parralelisation qui est a 8.
Quoi qu'il en soit je ne pe forcer la paralelisation avec un hint parralel etant donne que c un traitement applicatif auxquelle le user n'a pas accés.

Voila voila ptetre vous allez me donner d'autres news ^^.


PS: dsl pour les fautes d'orthographe, je suis un peu speed.

Apparemment il fait très bien son boulot c'est à dire d'écrire les données sur le disque en faisant des accés par index (db file sequential read).

Quand au parallélisme... bah c'est bien de paralléliser mais comme tu ne sollicites pas le CPU j'vois pas l'intérêt... celui qui t'as dit ça n'a probablement pas bien saisie le but du parallélisme qui reste un traitement TRES lourd (c'est pas le tout de paralléliser mais coordonner les process et consolider le résultat ça se fait pas tout seul ;)) quand au nologging, c'est effectivement une idée mais qui n'est pas sans comporter de risque puisqu'une restauration complète serait rendue impossible :?

Pour moi, t'as pas grand chose à faire si ce n'est s'interroger sur les performances des disques

Ouki merci Ora je vais voir avec l'exploitant alors pr qui me donne son avis sur ses disques.

Citation:

---

Envoyé par D_light

On m'a conseiller de mettre la table en nologging histoire d'éviter l ecriture dans les redos.

---

Nologging ne sera pas utile pour toi étant donné que tu fais un update. NOLOGGING n'a d'effet que pour certaines instructions et update n'en fait pas partie.

Sans parler des "problèmes" que ça peut produire ...

Citation:

---

Envoyé par D_light

En fait l'update est incorporé de maniére applicative dans le traitement, ci bien que l'utilisateur est incapable de me donner la requête compléte.

---

-1- Peut-être pourrais-tu détailler ce traitement ?
-2- Il s'agit d'un update par (et uniquement par) PK ?
-3- Et il y en a de nombreux qui s'exécutent en parallèle ?