Discussion :

[korian]

Bonjour,

Je travaille sur une base 10g avec un applicatif Java couplé à un framework Windchill.

Un traitement par lot connait actuellement de forts et inexpliqués ralentissements (~x100). J'investigue sur plusieurs pistes (stats, index, code, etc.) depuis une semaine mais je ne comprends pas d'où vient le problème. Et le jeu de ping-pong entre l'équipe développeur et moi, le "dba" (très honorifique...) commence à lasser.

En parallèle, un développeur de l'équipe m'explique que le dba de l'industriel, qui a développé la plateforme il y 6 ans, lui avait dit que certains problèmes de performances peuvent être dus au mauvais dimensionnement des tablespaces.

Tous les tablespaces sont en autoextend. Certains sont effectivement en permanence entre 98% et 99% d'occupation mais Oracle gère très bien l'allocation automatique et depuis 2 ans, rien à déplorer de ce coté.

De plus, un traitement identique sur ce domaine fonctionnel avait très bien fonctionné il y a un mois. Le souci est l'opacité de la couche Winchill/objet qui créé de nombreuses occurrences dans ses tables hors métier sans que nous maîtrisions vraiment les processus de création/mise à jour.
Pour exemple du bon fonctionnement de l'autoextend, lors de ce traitement, la table Métier principale était passée de 1.5 M de lignes à 31 M, avec augmentation de la taille de la base de 10Go (dont 7,5 pour cette seule table dans son tablespace particulier) sans difficulté particulière. Pour éviter toutes mauvaises surprises, tous les index de la base ont été reconstruits et les stats ont été recalculées.

Le traitement actuel est un complément beaucoup plus petit (1/3) mais les temps de traitement sont très très très, trop, longs.

Je me doute qu'avec la description succincte du problème vous ne pourrez pas me donner de réponse précise. Mais je cherche pour l'instant simplement à éliminer les pistes les plus improbables ou à trouver une nouvelle piste à suivre.

Je vous remercie par avance de toute aide que vous voudrez bien m'apporter.

[ojo77]

La piste à suivre a été indiquée dans ce post par mnitu.

Donc voir où le temps est perdu et comprendre pourquoi.

[ducho]

Bonjour ,

ESt-ce que cette modification aussi importante n'explique pas les temps de traitements ?

Pour exemple du bon fonctionnement de l'autoextend, lors de ce traitement, la table Métier principale était passée de 1.5 M de lignes à 31 M, avec augmentation de la taille de la base de 10Go (dont 7,5 pour cette seule table dans son tablespace particulier) sans difficulté particulière. Pour éviter toutes mauvaises surprises, tous les index de la base ont été reconstruits et les stats ont été recalculées.

Cdlt

[Pomalaix]

A ce stade de l'enquête, je ne saurais dire mieux que Ojo77.

Pour ceux qui sont en 11g (j'ai bien vu que ce n'est pas le cas ici), il existe un nouveau processus nommé SMCO, qui se charge d'effectuer, en tâche de fond et à temps perdu, des allocations d'espace anticipées pour les fichiers autoextensibles. L'objectif est justement de ne pas être pénalisé par des allocations dynamiques qui devraient, sinon, avoir lieu en plein traitement.
Ceci dit, il est évident que ce mécanisme vise le transactionnel, et ne pourra pas anticiper des chargements massifs.

http://docs.oracle.com/cd/E11882_01/...s.htm#REFRN104

[korian]

Merci pour vos réponses.
Je vais mettre en place les traces (pour la première fois ).

[korian]

Première question : Puisque l'ordre de base est un ALTER SESSION, le fait que je ne "maîtrise" pas les sessions (géré par un pool de connexion dans le framework Windchill) qui lance effectivement les traitements, va-t-il poser problème ?

Si oui, un indice ?
Merci d'avance.

[ojo77]

Peut-être que les commandes suivantes peuvent vous aider (dans SQL*Plus)

Code :

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

1
2
oradebug doc event
oradebug help

[mnitu]

Vous avez besoin d’identifier la session pour activer la trace que pour cette session. Investiguez si l’application utilise DBMS_APPLICATION_INFO pour exposer le code_module ou l’action ou la zone client_info. Autre piste pourrait être un éventuel utilisateur applicatif. Si c’est le cas bingo vous pouvez tracer en fonction de ces informations.
Sinon abattez-vous vers AWR si vous avez la licence ou le vieux statpack. Faite une snapshot avant de lancer le traitement qui pose des problèmes de performance et un autre 15 minutes plus tard ou à la fin.

[korian]

Bien, bien, bien...

Les développeurs ont - enfin - analyser leurs propres traces et ont découvert que la nouvelle organisation des données, qu'ils avaient mis en place entre les deux occurrences de traitement, avait eut de conséquences inattendues
Une de leur étape ramenait dorénavant 6500 objets au lieu de ... 1 ...en Java .

Donc merci à tous pour le temps dépensé
Le problème ne vient pas d'Oracle.

Ceci dit, j'ai mis en place les traces en suivant l'activité de l'utilisateur applicatif (all_users, v$session) et ai utilisé ce post que j'ai trouvé très utile et très bien rédigé : ICI (Merci à Tafora).