Discussion :

[Gnatit]

Bonjour,

N'arrivant pas à trouver de solutions à mon problème, je finis par venir demander de l'aide car je n'avance plus. J'ai une table sur laquelle je dois mettre à jour plusieurs colonnes. Toutes les lignes doivent être mises à jour. Comme je dois faire un full scan pour mettre à jour chaque colonnes, je mets à jour toutes les colonnes avec un seul update. J'ai donc une requête de ce type là:

Code :

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

1
2
3
4
5
update matable set
col1 = case ... when ... else ... end,
col2 = case ... when ... else ... end,
col3 = case ... when ... else ... end,
col4 = case ... when ... else ... end;

Sur Oracle 10g, cet update mettait juste deux fois plus de temps que la mise à jour d'une colonne, 1h00 on va dire.

Depuis le passage à Oracle 11g, la mise à jour met à peut près 15h alors que la mise à jour d'une colonne met toujours 0h30. Il devient en fait plus rentable de mettre à jour toutes les colonnes séparément.

Je me demandais donc ce qui pouvait cause ce problème de performances ou si vous aviez des pistes de recherche.

Pour ce que ca vaut, le plan d'exécution est le même que je mette à jour une ou toutes les colonnes.

Merci d'avance!!

[mnitu]

Difficile à dire ce qui ne va pas avec seulement ces informations. Un petit exemple sera bien venu.
Il est plus performant de récréer une table que de mettre à jour tous ces lignes.

[ojo77]

Je rejoins Mnitu, l'expérimentation montre qu'à partir de 5 % des blocs modifiés (en mode direct) ou 15 % (avec logging contraint) il est plus intéressant de recréer un table dans laquelle les données sont à jour et de l'échanger ensuite avec l'originale.

[Gnatit]

Je mets à jour 25 colonnes sur 260, de tout type (des objets géométriques, des varchars, des integer). Cependant, les colonnes ne sont pas remplies avant la mise à jour et sont toutes à null car je viens de les créer. Je ne peux pas les remplir avant malheureusement.

J'aimerai mettre un exemple mais la requête est trop important et trop lié au projet pour la modifier simplement.

Je vais tester la création d'une autre table. Merci, je compléterai si ca ne marche toujours pas.

[Waldar]

Vous n'avez pas un problème de PCTUSED / PCTFREE sur votre tablespace en 11g ?

[Gnatit]

Possible, je ne connais pas ces paramètres. Je me renseigne mais si je comprends leur signification, je ne vois pas comment les consulter.

edit: Sous oracle 11g pour cette table j'ai ceci:
PCT_FREE 10
PCT_USED null

Pareil sous oracle 10g

[Mohamed.Houri]

Bonjour,

Depuis le passage à Oracle 11g, la mise à jour met à peut près 15h alors que la mise à jour d'une colonne met toujours 0h30. Merci d'avance!!

Bonjour,

Comme cela a déjà été signalé, il est difficile de se faire une idée quant aux causes ayant entrainé cette lenteur manifeste de votre update suite à votre migration de base de données de 10g vers 11g. Mais quelqu'ait été la methode utilisée pour faire cette migration, beaucoup de choses auquelles vous ne vous attendiez pas peuvent surgir à la fin de cette migration. Vous ne parlez pas des indexes qui existent sur cette table? ont-ils changé de définition? les données (clustering factor) ont-elles été eparpillées lors de cette migration? pas de where clause dans cet update, quelle type de table, etc... Vous ne "postez" pas aussi l'explain plan suivi par cet update.

Néamoins, avez vous vérifié, les nouvelles valeurs des paramètes de l'optimisateur qui sont par exemple

Code :

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

1
2
3
4
 
  (a) db_file_multiblock_read_count
  (b) optimizer_index_cost_adj
  (c) optimizer_index_caching

en 11g par rapport à ce que vous aviez en 10g?

Avez-vous tentez de faire votre update en utilisant le hint

Code :

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

1
2
 
   /*+ optimizer_features_enable('10.2.0.4') */

10.2.0.4 doit correspondre à la base que vous aviez avant la migration

Bien cordialement

Mohamed Houri

[Gnatit]

Si il y a eu des problèmes lors de la migration (il y en a eu), ils ne devraient pas avoir d'effets sur cette table car elle est recréée toutes les semaines et donc a été créée sous oracle 11g.

Les paramètres que vous citez sont les mêmes sous oracle 10g et 11g, respectivement 16, 100 et 0.

Je ne connaissais pas ce hint, je vais essayer. J'aurais d'ailleurs du préciser que j'utilise deux hints pour l'update: /*+ FULL(matable) PARALLEL(matable, DEFAULT) */

Merci beaucoup pour ces réponses.

[Gnatit]

Pour information, en créant une nouvelle table copie de la première mais en mettant à jour les colonnes, je suis passé de 15h à 12 minutes. Je ne pensais pas qu'Oracle s'empêtrait autant avec les updates

[mnitu]

Faites une trace étendue de votre requête en 11g pour apprendre ce qui se passe.

[ojo77]

Faites une trace étendue de votre requête en 11g pour apprendre ce qui se passe.

Oracle met à jour l(es) index à chaque foi qu'une ligne est mise à jour sauf dans le cas où l'update utilise un filtre sur une colonne indexée et qu'il utilise l'index.

[ORA-007]

Bonjour,

Quelle est la volumétrie de la table concernée ?
Cette dernière était de combien avant migration ?

Ce temps de 15 h est il systématique ?

y a-t-il des traitements en parallèle de votre Update (transactions / batch ) ? présence de Locks ?

cordialement.