Discussion :

[hemeury]

Bonjour à tous,

Menant une analyse de perf sur une appli qui calcule des itiniéraires, j'ai pris manuellement 9 snapshots à différent moments,
et voici la synthèse des Top 5 Timed Foreground Events:


La grosse majorité du temps est passé en lecture et écriture des donnés.

Une analyse des requetes SQL donnent les résultats suivants:

on rencontre donc des requetes qui prennent 12 MINUTES pour s'éxecuter !!!

Cela vous inspire quoi ?

On sait que le modèle de donnée est catastrophique car les attributs de l'élément de base est sauvegardé dans 4 tables différentes en fonctions des types d'attribut.
Depuis que le volume des données est passé à 60000 élements, les perf se sont vraiment dégradées.

[Pomalaix]

Un rapport statspack présente une vue multifacette de l'activité de la base, et en général une rubrique a besoin de l'éclairage de plusieurs autres pour être interprétée correctement.
En particulier, la rubrique "top 5 events" ne se suffit pas à elle-même.


Par exemple, les attentes "control file sequential read" représentent 70% du temps de traitement en avant plan pour le rapport numéro 2, ce qui est louche a priori.
Mais on ne sait pas quelle est la période couverte par ce rapport, ni quelle était la charge DB time.
Ainsi, si la période couverte est de 1 heure, que le DB time est de 23 secondes, dont 70% de "control file sequential read", circulez, y a rien à voir !
C'est comme si l'événement majeur de ma journée complète était de dire "j'ai mangé une pomme à 11h10".


Concernant vos requêtes, avez-vous pris en compte le fait qu'il faut diviser "Total elapsed time" par le nombre d'exécutions ?


Je vous suggère plutôt de choisir un rapport statspack couvrant une période problématique, et de nous le fournir dans son intégralité.

[hemeury]

Bonjour Pomalaix,

Merci pour ta réponse, et voici les infos demandées.

Test de perfo sur une appli qui génère des trajets style GPS.

Voici la séquence des snaps:
180911_report_7_8_for_developpez_com.pdf180911_report_7_8_for_developpez_com.pdf180911_report_7_8_for_developpez_com.pdf
1 après lancement de l'appli
2 après connexion en tant que "Préparateur"
3 après le chargement de toutes les trajets calculés
4 après la recherche des trajets validés
5 après la recherche d'un trajet précis
6 après la création d'un trajet
7 lors du calcul de trajet
8 lors du calcul de trajet
9 après le calcul de trjet

effectivement la charge du CPU n#est pas significative entre la tache 1 et 2, étant la seule utilisatrice pendant ces tests. Nous avons demandé de réaliser des tests de performances sur la base de prod, afin de bénéficier d'un traffic réel, mais ce n'est pas encore autorisé. Donc on se contente de prendre en main Statspack, et montrer qu'il faut vraiement passer par cette étape de test en conditions réelles.

Voici le rapport d'instance généré entre les snap 7 et 8
180911_report_7_8_for_developpez_com.pdf

[dell68]

Bonjour ,

ça serai plus claire avec un Rapport AWR !

[Ikebukuro]

Je pense que sa boite n'a pas payé le Diagnostic Pack...

[Pomalaix]

Juste quelques mots après un bref coup d'oeil à ce rapport statspack.

Le rapport couvre une période d'environ 15 minutes, c'est un bon dosage permettant des conclusions significatives.
L'activité est faible (équivalent d'une seule session active en moyenne), la consommation CPU très inférieure aux capacités.

La durée des traitements est essentiellement due aux lectures sur disque, dans le cadre d'accès indexés.
(db file sequential read qui représentent 70% du temps total)

Tout se concentre sur la requête suivante, qui représente près de 74% du temps de traitement total, et 99% des lectures physiques
SELECT * FROM VN$VI_A_TROUT_TELEM WHERE EOID_TJNCT_FROM = :B1
700 secondes pour 168 192 exécutions

Les performances d'E/S sont médiocres : environ 20 ms en moyenne. Mais s'il s'agit d'une simple machine de test...

Dans la rubrique "Segments by logical reads" : ce sont les objets SYS.CDEF$ et SYS.TAB$ qui sont prépondérants, et concentrent 70% des lectures logiques à eux deux !
Ceci est tout à fait anormal.
Cependant, les lectures logiques, qui se traduisent par de l'activité CPU, ne constituent pas une part majeure dans l'activité totale.

[Ikebukuro]

Pour précision,
SYS.CDEF$ : vraie table des contraintes d'intégrité (utiliser plutôt DBA_CONSTRAINTS).
SYS.TAB$ : vraie table des tables de la base (utiliser plutôt DBA_TABLES).

Que donnent les requêtes suivantes?

Code :

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

1
2
3
4
5
6
 
select owner, count(*) from dba_tables group by owner order by count(*) DESC; (ou tu filtres sur ton schéma)
select owner, count(*) from dba_constraints group by owner order by count(*) DESC; (ou tu filtres sur ton schéma)
 
Pour ton schéma, tu peux aussi filtrer les contraintes sur celui-ci.
select table_name, count(*) from dba_constraints where owner in ('ton_schema1', 'ton_schema2') having count(*) > 10 group by table_name order by count(*) DESC;

[hemeury]

Bonjour à tous,

Merci bcp pour vos éclairages !

Voici le résultats des requetes demqndées:

select owner, count(*) from dba_tables group by owner order by count(*) DESC;
OWNER COUNT(*)
------------------------------ ----------
SYS 975
SYSMAN 728
VFADMIN2_SCHEMA 470
SYSTEM 158
ORDDATA 73
PERFSTAT 72
MDSYS 57
CTXSYS 50
EXFSYS 47
XDB 46
WMSYS 44
DBSNMP 20
ASPNET_DB_USER 13
VFHTMLLOC 10
ORDSYS 5
APPQOSSYS 4
OUTLN 3

select owner, count(*) from dba_constraints group by owner order by count(*) DESC;
OWNER COUNT(*)
------------------------------ ----------
VFADMIN2_SCHEMA 7539
SYS 3193
SYSMAN 3009
PERFSTAT 488
SYSTEM 472
ORDDATA 406
MDSYS 209
CTXSYS 111
WMSYS 110
EXFSYS 90
XDB 89
ASPNET_DB_USER 88
DBSNMP 80
VFHTMLLOC 22
ORDSYS 15

et pour le schéma:
select table_name, count(*) from dba_constraints where owner in ('ton_schema1', 'ton_schema2') having count(*) > 10 group by table_name order by count(*) DESC;
TABLE_NAME COUNT(*)
------------------------------ ----------
VN$TA_M_RDCTRY 88
VNV$TA_A_TROUT_TELEM 42
BIN$VEXfXCZgS/qJezVLVlr3Lw==$0 42
BIN$vaIplH5RRjG4gTLM+KuNXw==$0 42
BIN$5rGEKSFcTFOcP6Z5jDZDDQ==$0 42
BIN$5FexWIItTSiwtY+fqB67RQ==$0 42
VN$TA_A_TROUT_TELEM 42
BIN$SQr9a+JVQsGeQ8gVw85TIg==$0 42
BIN$FhOlVXXkRhKk96NI8Ix3Ug==$0 42
BIN$7l4k5R6cTii1s+wrbeuBzw==$0 41
BIN$9n4uD4EmSuuHPuaJKQbQyw==$0 41
BIN$qH5uVjRBRkO+cyJ7CudxkA==$0 41
BIN$d4Q4byZcSceAz73WHrGkpA==$0 41
BIN$VlkMRIg6Rkyyj83Yh7DsLw==$0 41
VNV$TA_MOVP 41
VN$TA_A_TROUT_TELEM_TMP 41
BIN$XK27PjBIRJ2HZazqInFCSw==$0 41
VN$TA_M_RDCTRY_VO 30
VN$TA_M_ATTRIBUTE 22
BIN$G+5vbFe2QmC9mLprVBLjvw==$0 19
BIN$8Wurc7XJRhydRM4A9svB1A==$0 19
VN$TA_M_OBJECT 19
BIN$QKjYC9n4T9y41f6vPJsP7w==$0 19
BIN$IyWO+e2gQXeCtLIdJWwpqw==$0 19
BIN$oKQ+lzj2St2jjKXRr06xlw==$0 19
VNV$TA_MOVB 19
BIN$4bRe+pKSREqdA5sFlqOS8Q==$0 17
BIN$EVa9bDYsTJ2PZnxE/mZhTw==$0 17
BIN$BLLIO5jiR+OKRPjekmXSmw==$0 17
BIN$XMaC8DuCQpu2jX03krhsBw==$0 17
BIN$KM9EB8BOTKCQfIGAXbkeTw==$0 17
VNV$TA_AP030_L 17
VN$TA_M_OBJATTRCON 14
VN$TA_USR_SESSION 13
BIN$tSwP6ILhQdm2hi2m3/zaOg==$0 11
BIN$wr87apbsQpyNCjnZd+9kAw==$0 11
VNV$TA_AQ070_L 11
BIN$VItJbX3fSeypMWuQ42wKUQ==$0 11
BIN$nSuaeD2jRbyaCedlR9Do5Q==$0 11
VN$TA_M_COUNTRY 11
BIN$2YHcj3EIR9SozzlPlf1OJQ==$0 11
VN$TA_USR_PROJECT 11
VN$TA_A_OCCUP_COORD 11

voilà !
je ne peux pas analyser ces résultats ....

[Ikebukuro]

Je constate que ton schéma applicatif VFADMIN2_SCHEMA a 470 tables pour 7539 contraintes soit 16 contraintes par table en moyenne. Cela me semble vraiment beaucoup, surtout que SYS n'en a que 3 par table..

Si je t'ai demandé ça c'est parce que Pomalaix a parlé de SYS.CDEF$ qui était fortement accédée. J'ai l'impression qu'il y a trop de contraintes sur tes tables mais peut-être que cela s'explique d'un point de vue applicatif.

La table principale du rapport est VN$VI_A_TROUT_TELEM : elle en a 42... pfiouuuu...

Que donnent les requêtes suivantes :

Code :

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

1
2
SELECT count(*) from dba_tab_cols where table_name = 'VN$VI_A_TROUT_TELEM' and owner = 'VFADMIN2_SCHEMA'; --> nous donnera le nombre de colonnes; à rapprocher de 42
SELECT CONSTRAINT_TYPE, count(*) from dba_constraints where table_name = 'VN$VI_A_TROUT_TELEM' and owner = 'VFADMIN2_SCHEMA' group by constraint_type order by count(*) DESC; --> nous donnera le type des contraintes

[McM]

Ikebukuro, si tu as une table avec 20 colonnes que tu déclares NOT NULL, ça fait 20 contraintes.
Ca ne me choque pas tant que ça.

[Ikebukuro]

Oui, c'est vrai, dit comme ça... c'est pour ça que je voulais les types de contraintes.
En tout cas pour la table la plus accédée il y en a 42

[hemeury]

Merci beaucoup pour vos expertises !!!

hier j'ai modifier le fichier ini.ora, ai regéneré le fichier SPFILE mais la base n'a pas redémarrée....
n'ayant pas sauvegardé le fichier SPFILE original je ne peux pas faire un retour arrière rapide.
l'erreur donné est lié à ORACLE_BASE:


Mais comment forcer la valeur de ORACLE_BASE ?

Nous travaillons sous Windows avec 2 sessions virtuelles. Les var d'env sont:


Et comme je ne peux pas redémarrer la base, je ne peux pas regarder la nature des contraintes sur la table VI_A_TROUT_TELEM...
J'ai pensé à redémarrer à partir du fichier initial ini.ora en passer la commande:


mais le service n'est toujours pas lancé:


Je sors un peu de ce fil de discussion, mais n'est pas trouvé de réponse ailleurs ...

[hemeury]

Bon... j'ai rétabli la virtulle machine depuis le précédent "Prüfpunkt" et donc retour avec init.ora initial.... si à l'occasion vous avez une idée pour cette histoire d'ORACLE_BASE non correctement positionnée lors de la création du SPFILE, cela m'intéresse.

sinon, revenons à notre discussion:

Code :

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

1
2
SELECT count(*) from dba_tab_cols where table_name = 'VN$VI_A_TROUT_TELEM' and owner = 'VFADMIN2_SCHEMA'; --> nous donnera le nombre de colonnes; à rapprocher de 42
==> 41

Code :

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

SELECT CONSTRAINT_TYPE, count(*) from dba_constraints where table_name = 'VN$VI_A_TROUT_TELEM' and owner = 'VFADMIN2_SCHEMA' group by constraint_type order by count(*) DESC;

--> nous donnera le type des contraintes
==> un seul type de contrainte: celui de type 0 => Check NON NULL

Avpns nous réellement besoin dd'une contrainte NON NULL sur chaque colonne ??

C'est presque comme un escape gqme qvec des indices à trouver ...

[Ikebukuro]

Oh, des messages d'erreur en allemand, ça faisait vingt ans que j'avais pas vu ça et ça ne me manquait pas

Sinon, pour Oracle_base, je ne comprends pas pourquoi dans le message ORA-48140 le mot ORACLE_BASE est derrière dbhome. Dans l'architecture OFA de Oracle tu as ORACLE_BASE au dessus de ORACLE_HOME, comme dans tes variables Windows. Ce ORACLE_BASE derrière DATABASE est certainement le ADR_BASE : voir ici http://www.dba-oracle.com/t_adr_base.htm

Sinon, une contrainte NOT NULL par colonne c'est beaucoup quand même.

Au fait, en réfléchissant plus, je ne vois pas pourquoi SYS.CDEF$ serait consulté pour un SELECT. Il n'y a pas d'INSERT ou de DELETE dans ton rapport? Il faut bien que la consultation de cette table serve à quelque chose pourtant.

[hemeury]

Effectivement, tous ces select permette de définir la fameuse route en construction. Pourquoi on ne les voit pas ?
je vais creuser ....

et oui, suis immergée en Teutonie ....

[Ikebukuro]

Si tu sais comment utiliser une trace 10046 et tkprof (pas compliqué), peut-être que tu verras la lumière :-)

Sinon, un lien ici : http://dbaoraclesql.canalblog.com/ar.../36132561.html

L'objectif est de lancer tes ordres SQL une fois ta session tracée et de voir ce que fait réellement Oracle en mémoire. Le fichier trace peut-être hermétique mais en s'accrochant, on peut découvrir des choses.

[mnitu]

…
Avpns nous réellement besoin dd'une contrainte NON NULL sur chaque colonne ??

C'est presque comme un escape gqme qvec des indices à trouver ...

Vous est sur une mauvaise piste et vous perdez votre temps. Une table doit avoir autant des contraintes que nécessaires au respect des règles de business. "Trop des contraintes" c'est une aberration!

L'optimiseur d'Oracle peut mieux optimiser ses requêtes en présence de ces contraintes et il est normal que vous voyez de trace des requêtes internes que la base émet lors du parsing des requêtes envoyées par l'application. Peut être que l'application fait trop de parsing mais cela c'est une autre histoire qu'à la limite vous pouvez investiguez.

De toute façon si votre modèle est foiré il n'y a pas de remède miracle. Il faut le revoir!
Voilà une petite lecture qui pourrait vous enseigner ce que cela signifie: BadCarma

[hemeury]

Bonjour à tous,



Alors finalement, en activant la gestion automatique de la mémoire, en ajoutant les paramètre MEMORY_TARGET et MEMORY_MAX_TARGET dans init.ora, nous avons pu réduire les temps de réponses (certains de moitié !). Les couts indiqués dans les EXECUTION_PLAN ont été réduits, et donc cette amèlioration a pû être quantifiée.

Encore merci pour votre aide tout au long de cette analyse !

[dell68]

Merci. de. ton. mail.
Je. souhaiterai. savoir. par. mode. de. diagnostique. es tu. arriver. à. résoudre. ces. problèmes. de. performance, quel. outils. t’a. suggéré. ??

[hemeury]

J'ai utilisé l'outils gratuit STATSPACK qui te permet de prendre des photos (snapshot), c-à-d de sauvegarder les valeurs de différents paramètres au moment de la prise de vue:
Ensuite, tu peux générer un rapport global (Top 5 Events, SQL per CPU Time, ...) ou pour un requête sql (EXECUTION_PLAN).
Plus d'info sous: http://www.oracledistilled.com/oracl...ing-statspack/

Je viens de télecharger SpReporter et attend de recevoir les numéros de licence pour l'utiliser: à partir des rapports générés par Statspack, des graphes seront produits. A voir !

Bon courage !