Dégradation de perfs suite migration oracle

Version imprimable

17/03/2012, 17h18
devkais

Dégradation de perfs suite migration oracle

Bonjour ,

ci-joint les Top 5 des events pour un traitement super lourd en 11g !!!!

Merci de votre aide.
17/03/2012, 19h28
Heaven93

bonsoir,

pour quelqu'un qui semble avoir des soucis, tu ne te donnes pas les chances d'obtenir une réponse constructive.
les indications que tu nous donnes sont maigres :
migration. ok. par upgrade? changement de machine? si oui : export import ou copie de fichiers puis upgrade? (c'est pour savoir si la distribution des données a changé).
ensuite le top five : sur combien de temps le snapshot (elapsed time)? plus bas dans l'awr tu trouveras les traitements les plus coûteux, trouver leur plan d'exécution , et tu pourras comparer avec le plan d'exécution des requêtes avant upgrade.
17/03/2012, 20h19
devkais

Merci pour votre réactivité.
Il s'agit d'une migration via import 9i => export nouvelle machine 11g.
Ci-joint l'info concernant l'elapsed time.
J'ai comparé le plan d'exécution entre la requête 11 qui rame (10h) et celui de la 9i (1h) : même plan d’exécution sauf le coût (cost)11g = 150 fois celui de la 9i.
Cette requête fait du FULL SCAN dans les 2 cas.
Merci d'avance.

Citation:

Statistic Name Time (s) % of DB Time
sql execute elapsed time 126,244.75 98.17
DB CPU 28,035.38 21.80
PL/SQL execution elapsed time 27,752.58 21.58
parse time elapsed 630.12 0.49
hard parse elapsed time 602.57 0.47
failed parse elapsed time 323.75 0.25
PL/SQL compilation elapsed time 64.49 0.05
hard parse (sharing criteria) elapsed time 58.19 0.05
repeated bind elapsed time 5.73 0.00
connection management call elapsed time 4.55 0.00
hard parse (bind mismatch) elapsed time 1.55 0.00
sequence load elapsed time 0.47 0.00
DB time 128,596.55
background elapsed time 4,630.38
background cpu time 491.69

Citation:

Envoyé par devkais

Bonjour ,

ci-joint les Top 5 des events pour un traitement super lourd en 11g !!!!

Merci de votre aide.
Code:

1 2 3 4 5 6 7 Event Waits Time(s) Avg wait (ms) % DB time Wait Class db file sequential read 11,342,034 29,931 2 24.09 User I/O DB CPU 29,036 22.80 db file scattered read 364,62 1,511 4 1.19 User I/O Data file init write 7,587 798 108 0.62 User I/O control file sequential read 631,765 521 1 0.38 System I/O
Savez vous, Monsieur, que n'importe quel rapport AWR aura toujours un "Top 5 Timed Events " que votre base de données fonctionne normalement ou qu'elle souffre d'un problème de performance. Il y va donc sans dire, que pris seul, le "Top 5 Timed Events" ne veut rien dire. Il faudrait donc au moins associer à ceci, les parties "LOAD Profile", "Instance Efficiency Percentages" et "Workload Repository"

Ceci est la première remarque. Quant à la deuxième non moins importante est que vous semblez avoir un problème de performance général. Vous semblez ne pas savoir du tout d'où vient votre problème de performance; c'est pourquoi vous avez décidé de générer un rapport AWR. Si c'est le cas, c'est très bien vous êtes sur le bon chemin. Faites uniquement attention à avoir (a) un rapport AWR correspondant au moment où l'application était lente et (b) un rapport dont la durée n'est pas excessive. Mais si vous avez localisé la requête incriminée, alors laissez tomber le AWR et commencez par analyser cette requête. Et dans ce cas, la première chose à faire en 11 g est ceci
Code:

1 2 alter session set optimizer_features_enable='9.2.0.3'; -- votre version en 9i
Pour l'instant, avec ce que vous avez donné comme informations, je peux simplement remarquer que vous faites plus de 11 millions de "db file sequential read" (ou d'accès via index) tout en ayant un excellent temps d'accès par block (2ms). Je pencherai bien pour un changement de plan d’exécution utilisant un index au lieu d'un table scan ou utilisation d'un index non précis.

Regardez la partie du rapport AWR concernant "SQL ordered by" particulièrement "SQL ordered by Reads" et "SQL ordered by Gets"

Si vous donnez plus de détails, je pourrai éventuellement vous guider.

18/03/2012, 11h10
Pomalaix

Citation:

Envoyé par Mohamed.Houri

alter session set optimizer_features_enable='9.2.0.3';

Tout à fait d'accord sur la démarche ! En revanche, de mémoire et vérifié à l'instant, 9.2.0.3 n'est pas une valeur valide (fort heureusement, celles qui sont valables s'affichent immédiatement dans le message d'erreur).
18/03/2012, 15h29
Mohamed.Houri

Citation:

Envoyé par Pomalaix

Tout à fait d'accord sur la démarche ! En revanche, de mémoire et vérifié à l'instant, 9.2.0.3 n'est pas une valeur valide (fort heureusement, celles qui sont valables s'affichent immédiatement dans le message d'erreur).

Pomalaix,

Oui tout à fait. J'avais pris un exemple pour la 10g et j'ai fait un copié/coller en mettant en commentaire -- votre version en 9i

Bien à vous
18/03/2012, 20h36
pachot

Bonjour,
Etant donné que la somme des Top-5 events ne couvrent que la moitié du DB time (lorsqu'on ajoute les %) il semble qu'il y ait une contention on niveau de la CPU du système.
En effet, DB CPU ne compte pas le temps passé en attente de CPU lorsque la CPU doit être partagée entre plusieurs process.
Il faudrait voir au niveau du systéme.
Cordialement,
Franck.
18/03/2012, 22h59
devkais

Gestion de la mémoire !

J’ai oublié de préciser que la mémoire est configurée en automatique :
- memory_target = 4 G
- sga_target = 0
- pga_aggregate_target = 0

Faut-il modifier ce paramétrage de la mémoire ? Basculer en gestion manuelle ?
Quelles valeurs à attribuer sachant que la RAM est de 28Go.
NB : lock_sga= false !!!
Merci.
19/03/2012, 14h06
Z3phur

Bonjour,

si vous avez 28Go de RAM et que le serveur n'héberge que cette instance. Vous pouvez aller pour la memory_target à 80% de la RAM => environ 22Go.
19/03/2012, 16h48
13thFloor

Bonjour,
le même plan 10 fois plus long en 11g qu'en 9i suite à une migration par import ?
C'est curieux et pas banal.
Les temps d'accès aux TS/datafiles sont-ils très différents (partie Tablespace IO Stats et File IO Stats du rapport awr) ?
La table accédée l'est bien en local (pas en remote) ?
Qu'est-ce qui pourrait faire qu'un full est 10 fois plus long :
- accès disque sur plutôt qu'en mémoire (en 11g si les données ramenées dépasse 2% du cache, elles ne sont pas mises en cache)
- architecture disques/baies/contrôleurs moins véloces (mais à ce niveau de différence, ce serait usb 1.0 vs ssd)
- changement de type de partitionnement

Une publication de la requête et des 2 plans aiderait.
20/03/2012, 21h54
devkais
Dans le cadre de l'analyse du problème de perfs cité ci-dessus ,j'ai quelques interrogations au passage :

1/Que pensez-vous de la méthode qui consiste à ne rien toucher au paramétrage 11g par défaut et modifier uniquement le paramètre compatible= version actuelle du noyau ? 11.2.0.2 en occurrence.
2/ Dans la vue v$parameter , parfois un paramètre est changé mais la colonne DEFAULT affiche 'OUI' càd valeur par défaut :Est-ce normal ?

3/Suite à des modifications du paramétrage de la base , quelle méthode permet de savoir la valeur du paramètre par défaut autre que la doc Oracle ?

4/Existe-il un site permettant d'effectuer une vérification globale en mode online d'un paramétrage d'une base Oracle et donner des recommandations ?

5/ Quand peut-on modifier les paramètres cachés d'Oracle ? est-ce recommandé de ne pas le toucher ?
6/ Le paramétrage de la base a été modifié comme suit :
Code:

1 2 3 ALTER SYSTEM SET optimizer_mode='FIRST_ROWS_10' SCOPE=BOTH; ALTER SYSTEM SET optimizer_index_cost_adj=130 SCOPE=MEMORY;
Que pensez-vous de cette modification pour améliorer le temps du traitement batch qui pose problème.

7/ Quelle paramètres 11g à ne pas toucher ?

Merci les Experts pour vos retours ...
07/04/2013, 21h46
devkais

Citation:

Envoyé par pachot

Bonjour,
Etant donné que la somme des Top-5 events ne couvrent que la moitié du DB time (lorsqu'on ajoute les %) il semble qu'il y ait une contention on niveau de la CPU du système.

Bonjour Franck , s'agit-il une règle à appliquer :

somme des Top-5 events >= 50% DB Time sinon contention CPU système ?
Pourriez-vous expliquer ce point important.
Merci.
07/04/2013, 22h35
pachot

Bonjour,

En général, s'il y a plus de temps enregistré apr DB time que de temps enregistrés par les wait events + par CPU time, alors il faut vérifier la contention CPU.

La raison en est que 'CPU time' mesure le temps passé en CPU tel qu'il est donné pas l'OS. Le temps passé en attente de CPU (runqueue) sur un système surchargé n'est pas compté. Donc pour simplifier
'DB time' -'total foreground wait events' - 'CPU time' = 'attente CPU'

ce n'est pas une règle générale, juste un point à vérifier lorsqu'on est dans ce cas.

Cordialement,
Franck.
08/04/2013, 08h44
Mohamed.Houri

Citation:

Envoyé par devkais

Bonjour Franck , s'agit-il une règle à appliquer :

somme des Top-5 events >= 50% DB Time sinon contention CPU système ?
Pourriez-vous expliquer ce point important.
Merci.

Si vous voulez savoir si votre système est limité en CPU vous devez faire ceci:

A = Temps disponible pour la CPU = la durée du rapport AWR * 60 (secondes) * nombre de CPU

B = Temps CPU montré dans le TOP 5 AWR

%utilisation CPU = (B/A)*100

Exemple :

• AWR d’une durée de 30,11 min.
• Nombre de CPU = 32
• Temps CPU dans le TOP 5 = 1561 secondes

A = 30,11 *60 * 32 = 57811,2 secondes de CPU disponibles

%utilisation CPU = (B/A)*100 = (1561/57811,2) * 100 = 2,7%

Ce système n’a pas de problème de CPU.

Est-ce que vous avez résolu votre problème de performance ou pas encore?
08/04/2013, 15h15
pachot

Bonjour Mohamed,

Citation:

Envoyé par Mohamed.Houri

%utilisation CPU = (B/A)*100

C'est l'utilisation des CPU par l'instance. Il peut y avoir d'autres instances sur le système, ou d'autres process non Oracle...
Cordialement,
Franck.
08/04/2013, 15h41
Arkhena

Bonjour,

Pour information, j'ai eu le cas d'une requête qui durait 1h en 9i et plus de 10h en 11g.
Après l'analyse de la requête, il y avait un énorme produit cartésien. Dans ce cas là, le produit cartésien était moins bien pris en charge par l'optimiseur.
Il n'empêche qu'un produit cartésien est un erreur qui ne devrait pas exister.

Malheureusement, certains programmeurs sont très obtus...

Cordialement,

Arkhena
09/04/2013, 00h31
devkais

Citation:

Envoyé par Mohamed.Houri

Est-ce que vous avez résolu votre problème de performance ou pas encore?

Oui heureusement :)
Le cas le plus tordu que j'ai résolu c'était un INDEX RANGE SCAN très lent.
Je l'ai remplacé par TABLE FULL SCAN et le problème est résolu.
A ce jour je n'ai pas compris pourquoi Oracle 11g a choisi le range scan !
depuis je fais attention aux INDEX RANGE SCAN :)
merci.