AWR et traces suite régression de performances

**devkais** · 18/03/2013, 00h04

Bonjour,
Suite à une migration Oracle 10g vers 11g, un traitement qui dure normalement 9 heures (10g) , dure maintenant 21 heures (11g) !
Afin de comprendre la situation et la raison de cette régression faut-il faire un rapport AWR sur une durée de 21 heures ? Est-ce fiable ? Faut-il se limiter à une heure pour un rapport AWR ? si oui comment ?
Par ailleurs, J’ai essayé de tracer le traitement de 21 heures, mais les fichiers traces ont fait exploser le file système …
En effet l’utilisation du paramètre MAX_DUMP_FILE_SIZE n’est pas suffisante puisqu’il s’agit d’un traitement (boîte noire) multi-connexions/sessions donc génération de plusieurs fichiers traces…
Avez-vous une idée ?
Merci pour votre aide précieuse.

**pachot** · 18/03/2013, 09h31

Bonjour,

Le rapport sur 21 heures peut permettre de comparer les stats (timed event, timemodel) avec le rapport sur 9 heures d'avant migration pour se faire une idée.
Les sections 'segment statistics' peuvent permettre une comparaison rapide aussi.

Mais il ne contiendra pas tous les SQL. Donc il ne permettra pas de voir les quelques requêtes qui sont plus longues. Parce que les SQL qui ne sont plus en shared pool à la fin ne seront pas présents.

Il y a plusieurs approches possibles:
- voir avec les pages performances de OEM les requêtes qui semblent longues.
- Tunig Pack as des outils qui peuvent permettre de comparer (si la 10g est toujours dispo)
- regarder des rapports sur des durées plus courtes. En regardant 'Captured SQL account for ...% of Total DB Time (s)' dans la section 'SQL ordered by Elapsed Time' on vérifie que le rapport couvre quelque chose de significatif.
- faire des requêtes sur dbs_hist_sqlstat pour trouver les requêtes les plus consommatrices

D'une manière générale dans ce genre de cas, je ne perd pas trop de temps à chercher à comprendre ce qui est plus long qu'avant. Je préfère me concentrer à tuner le traitement 11g avec comme objectif d'arriver à 9 heures de traitement. La comparaison, c'est juste pour avoir une idée.

Cordialement,
Franck.

**mnitu** · 18/03/2013, 09h47

Si possible, essayez de faire tourner le traitement avec l’optimiseur en compatibilité 10g (optimizer_features_enable) comme un fix rapide pour gagner le temps nécessaire à l’optimisation du traitement.

**ojo77** · 18/03/2013, 10h51

Pour un meilleurs diagnostique vous pouvez aussi effecteur un SQLHC pour la requête (dès lors que vous avez le SQL_ID de la requête) voire une SQLT (tous deux disponibles sur MyOracleSupport notes 1465741.1 et 1366133.1) ... Mieux qu'AWR (à mon avis) lorsqu'il s'agit de tuning SQL

**Oratorio** · 04/04/2013, 14h05

C'est un réél problème qu'on a rencontré et la solution n'est pas unique mais en règle générale

- update stats avant le migration
- ALTER SYSTEM SET cursor_sharing=force (see [ID 1169017.1])

We recommend that customers discontinue setting cursor_sharing = SIMILAR due to the many problematic situations customers have experienced using it. The ability to set this will be removed in version 12 of the Oracle Database (the settings of EXACT and FORCE will remain available). Instead, we recommend the use of Adaptive Cursor Sharing in 11g.

A number of customers have seen an increase in the number of child cursors since migrating to Oracle Database 11g Release 2. This can lead to many problems including complete CPU saturation of a machine requiring a database instance bounce or general database performance issues in the form of waits on mutexes and 'library cache lock'.

aussi cela a amélioré certains traitements de quelques heures à 2 minutes
- optimizer_index_cost_adj=10
- db_file_multiblock_read_count=32
- _optimizer_cost_based_transformation=off

**ojo77** · 04/04/2013, 17h10

Envoyé par Oratorio

- optimizer_index_cost_adj=10
- db_file_multiblock_read_count=32
- _optimizer_cost_based_transformation=off

Ho non, pitié !!!! Pourquoi pas optimizer_mode=rule tant qu'on y est ?

Les deux paramètres que vous donnez auront meilleurs compte à être calculé par Oracle à partir des statistiques système (dbms_stats.gather_system_stats) et le paramètre caché que vous dennez enlève à oracle la possibilité de réécrire les requêtes.

**Oratorio** · 05/04/2013, 09h30

Envoyé par ojo77

et le paramètre caché que vous dennez enlève à oracle la possibilité de réécrire les requêtes.

c'est les changements adaptés à notre situation
à vous de voir parmi ces paramètres ce qui vous convient

Le paramètre en question a été modifié car l'optimiseur 11 n'était pas capable d'évaluer l'utilisation de champs (surtout de type date) basés sur des fonctions alors que l'optimiseur 10.2.0.4 était capable de le faire