Performance Update ?

[D_light]

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.

[orafrance]

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 ?

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

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 ?

[orafrance]

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 ?

[D_light]

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

Merci en ts cas Orafrance de ta rapidité.

[orafrance]

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

[D_light]

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 .


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

[Michel SALAIS]

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

[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

[orafrance]

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

[D_light]

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

[orafrance]

rien à redire

[Michel SALAIS]

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

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

[D_light]

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.

[D_light]

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.

[orafrance]

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

[D_light]

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

[Michel SALAIS]

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

[wondersonic]

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 ?