Discussion :

[neo.51]

Bonjours,

Je suis actuellement sur oracle 8i.

J'ai une table de 38 champs dont 8 sont indéxés.

La table contient aproximativement 2 000 000 enregistrements.

Je fais un update de tous les champs d'un rows que je sélectionne par son identifiant unique (qui est indexé).

L'update d'un rows prend entre 9 et 12 secondes sur un serveur dédié à oracle :
Xeon 3,2 Ghz
1 Go de RAM
windows 2003 server

Le temps d'update est énorme et inacceptable. Quelles pistes pour améliorer les temps d'update ?

-ne pas updater systèmatiquement les 38 champs de la rows ?
-enlever quelques indexes ? (8 c'est peut-être un peu beaucoup sur une table aussi grosse)
-mettre en place un système d'archivage de cette grosse table ?
-revoir ma configuration du serveur oracle car je dois pouvoir avoir de meilleures performances sur un tel cas de figure.

j'attends vos remarques

[neo.51]

l'insertion de 150 rows dans la même table est quasi instantanné

même pas le temps de regarder le temps d'éxécution des requetes d'insertion...

[Fabien Celaia]

Ta table est peut-être bien fragmentée :

Tu as la tête de l'update et son plan d'exécution ?

[McM]

Ta table a-t-elle des tables la référençant ?
Sinon, la PK fait combien de colonnes ?

[neo.51]

update classique

Code :

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

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
UPDATE tache
    SET clntache = :b1, 
        figtache = :b2, 
        filtretch = :b3, 
        libtache = :b4, 
        datemintch = :b5, 
        datemaxtch = :b6, 
        niveautch = :b7, 
        typecollectetch = :b8, 
        coteconduitetch = :b9, 
        colortch = :b10, 
        activitetch = :b11, 
        modeparcourstch = :b12, 
        segmentationtch = :b13, 
        numordretch = :b14, 
        longueurtch = :b15, 
        senstronctch = :b16, 
        clenoeud1 = :b17, 
        clenoeud2 = :b18, 
        cleaccesreseau1 = :b19, 
        cleaccesreseau2 = :b20, 
        clezone = :b21, 
        cleservice = :b22, 
        clevehicule = :b23, 
        cletronc = :b24, 
        clefrequence = :b25, 
        cletachemere = :b26, 
        codetch = :b27, 
        noscenariotch = :b28, 
        typeflag = :b29, 
        marchearrieretch = :b30, 
        bdrtronc = :b31, 
        observation = :b32, 
        hlpintertch = :b33, 
        nomchauftch = :b34, 
        planntch = :b35, 
        typeincidenttch = :b36, 
        libincidenttch = :b37, 
        ostch = :b38
    WHERE cletache = :b39

(requête oci paramétré)

Il y a un index sur cletache.

Je vais chercher de la doc sur la fragmentation

[neo.51]

Ta table a-t-elle des tables la référençant ?

non

Sinon, la PK fait combien de colonnes ?

1 colonne

[plabrevo]

Difficile d'investiguer sans
1) L'explain plan
2) La liste exhaustive des indexes.

Pour obtenir 1), re-execute l'update sous sqlplus apres un ordre autotrace on
Pour 2), dump le contenu de USER_IND_COLUMNS pour la table en question

[neo.51]

j'ai supprimé l'index sur ma cle primaire et je l'ai recréé... ben maintenant les updates sont instantannés.

... résolut mais je sais pas ce qu'il s'est passé :s


à ceux qui m'ont aidé à chercher

[Jaouad]

J'arrive à la bourre mais dans ca cas la il faut l'explain plan ( il ne devait pas passer par l'index ) et surtout les évenements d'attentes

Joauad

[Fabien Celaia]

1) Jaouad, pourquoi ne devrait-il pas prendre l'index ?
2) La recréation de l'index a dû le défragmenter... ça m'a l'air logique comme explication, non ?

[LeoAnderson]

Si les stats ne sont pas calculées, que l'index a subit de fortes modifications (profondeur trop importantes), des stats obsolètes, ... sont autant de raisons qui peuvent expliquer la non-utilisation de l'index !

[SheikYerbouti]

Ce qui relance le débat sur la méthode et la fréquence de raffraîchissement des stats...

[LeoAnderson]

Quel débat ? il n'y a pas à débattre, c'est une obligation de le faire régulièrement (en tout cas, avant la 10g) ! ;-)

[SheikYerbouti]

Quel débat ? il n'y a pas à débattre, c'est une obligation de le faire régulièrement (en tout cas, avant la 10g) ! ;-)

Mais quand ? comment ? est-ce automatisable ?

[LeoAnderson]

Ah oui, évidemment.... c'est uniquement sur le comment que l'on peut débattre, pas sur le pourquoi ! ;-)

[Jaouad]

1) Jaouad, pourquoi ne devrait-il pas prendre l'index ?

Voir la réponse qu'a donnée notre cher léo .Autre cas qui n'a rien a avoir ici c'est le clustering factor.

Calcul des stats :
Une solution que nous avons mis en place ici est la suivante ( elle présente des avantanges et des inconvénients )

Le principe est le suivant , tu ne me calcul les stats que pour les index et les tables que lorsque la volumétrie à bougé de 10 %. Permettant ainsi de calculer seulement ce qui est nécessaire. Ce calcul est quotidien ( les bases font l'objet de bcp d'activité ) puis tout les semaines il y a une validation ( validate strucure ) des index/Tables si l'index n'est plus en phase avec la table , il y a un rebuild et aprés un calcul des indess.

Il faut également pour les index utiliser trés fréquemment , construire des histogrammes .

Voila ce n'est qu'une proposition parmit d'autres

[LeoAnderson]

Pour ne pas avoir à compter le pourcentage qui bouge, il suffit de passer les tables en "MONITORING" et ensuite, de faire un premier calcul des stats.

ensuite, le package DBMS_STAT te permet de lister les objets pour lesquels les stats sont "STALE" (obsolètes); il suffit alors de ne recalculer que ces stats là ! :-)

[Jaouad]

Pour ne pas avoir à compter le pourcentage qui bouge, il suffit de passer les tables en "MONITORING" et ensuite, de faire un premier calcul des stats.

ensuite, le package DBMS_STAT te permet de lister les objets pour lesquels les stats sont "STALE" (obsolètes); il suffit alors de ne recalculer que ces stats là ! :-)

Oui effectivement c'est cela dont je parlais , je ne me paluche pas à la main les 20 000 index de mes ERP ( c'est vrai que j'ai opublié de le dire )

[LeoAnderson]

Pour ne pas avoir à compter le pourcentage qui bouge, il suffit de passer les tables en "MONITORING" et ensuite, de faire un premier calcul des stats.

ensuite, le package DBMS_STAT te permet de lister les objets pour lesquels les stats sont "STALE" (obsolètes); il suffit alors de ne recalculer que ces stats là ! :-)

Oui effectivement c'est cela dont je parlais , je ne me paluche pas à la main les 20 000 index de mes ERP ( c'est vrai que j'ai opublié de le dire )

Je m'en doutais bien, mais je craignais que certains ne commencent à imaginer un trigger sur insert/update/delete afin de déterminer le pourcentage de mouvements... ;-)

[McM]

Le MONITORING n'est pas coûteux si on le fait sur toutes les tables ?