Discussion :

[devkais]

Bonjour ,

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

Merci de votre aide.

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

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

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

[Mohamed.Houri]

Bonjour ,

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

Merci de votre aide.

Code :

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

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 :

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

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.

[Pomalaix]

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

[Mohamed.Houri]

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

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

[devkais]

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.

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

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

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

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

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

[devkais]

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.

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

[Mohamed.Houri]

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?

[pachot]

Bonjour Mohamed,

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

[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

[devkais]

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.