Précédent   Forum du club des développeurs et IT Pro > Bases de données > Oracle > Administration
Administration Forum d'entraide sur l'administration du serveur Oracle
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse
 
Outils de la discussion
Publicité
'
Vieux 13/12/2012, 11h40   #1
Kyreos
Invité de passage
 
Homme
Développeur Java
Inscription : février 2012
Messages : 1
Détails du profil
Informations personnelles :
Sexe : Homme
Localisation : France

Informations professionnelles :
Activité : Développeur Java
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : février 2012
Messages : 1
Points : 0
Points : 0
Par défaut Lenteurs aléatoires DUMP

Bonjour à tous,

Depuis près d'une semaine je suis soumis à un problème assez frustrant.
Pour vous expliquer le contexte, ma tâche consiste à effectuer des reprises de données de BDD de logiciels de mes clients pour les intégrer dans la BDD de mon logiciel.
Des reprises comme celle ci, j'en ai déjà fait des dizaines et je n'ai jamais eu le problème évoqué ci-dessous.

Le problème :
Après avoir effectué ma reprise de données, j'ai fait quelques tests d'usage en exécutant quelques requêtes pour vérifier le fonctionnement et à ma grande surprise, le temps de traitement est extrêmement long.

Ce qui est étonnant, c'est que le soucis semble assez aléatoire.

J'ai effectué le DUMP de cette base pour le réimporter dans un autre utilisateur. Dans ce nouvel utilisateur, plus aucun problème de lenteur.
Par contre, en important dans encore un autre utilisateur, les problèmes de lenteurs étaient de nouveau présent.

Je ne pense pas que cela vienne de l'installation d'Oracle ou du réseau étant donné que ces problèmes surviennent sur mon serveur (Qui est en Oracle 10) et du coté du client (Qui est en Oracle 11).
Je ne pense pas que cela vienne non plus de la SGA. Déjà parce que le problème n'est pas toujours présent et qu'elle est de près de 1.5Go.

Même si je pensais pouvoir exclure aussi un problème de données, j'ai testé de supprimant le contenu d'une table et en le réinsérant. Lors du premier test sur un utilisateur, plus de lenteurs mais lors du second test sur un autre utilisateur, rebelote, présence des problèmes de lenteur.

J'ai aussi repasser le script de mes vues, recompilé les index et mis à jours les statistiques :
EXEC DBMS_STATS.gather_schema_stats('USER', cascade=>TRUE);
Rien n'y fait.

Je suis complètement à cour d'idées. Je suis à l'écoute de tout axe de recherche que l'on pourrait me proposer

Merci à vous
Kyreos est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 13/12/2012, 14h52   #2
mnitu
Expert Confirmé Sénior
 
Avatar de mnitu
 
Homme Marius Nitu
Ingénieur développement logiciels
Inscription : octobre 2007
Messages : 4 115
Détails du profil
Informations personnelles :
Nom : Homme Marius Nitu
Localisation : France, Marne (Champagne Ardenne)

Informations professionnelles :
Activité : Ingénieur développement logiciels
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : octobre 2007
Messages : 4 115
Points : 8 010
Points : 8 010
Vous voyez bien qu’un essayant un coup par ci un autre par là ça ne mène nul part.

Vous avez un traitement que vous trouvez qu’il prend trop des temps ! Vous ne savez pas ce qui fait que ce traitement prend trop de temps ; vous ne savez pas en fait ou le temps passe ! La première chose à faire c’est de faire en sorte pour le savoir : que est-ce qu’il fait que mon traitement prend trop de temps ?

Chez Oracle cela se fait via la trace du traitement. Activez donc la trace sql étendue (chechez l'aide de votre DBA ou autre utilisateur expérimenté) et ré exécutez le traitement. Cela va générer un fichier de trace qui peut être analysé avec l’aide des divers outils (tkprof ou profilers) pour comprendre où le temps passe.

C’est l’analyse de cette trace qui vous dirait ce qui ne va pas. Sinon c’est la boule de cristal et les précieux conseils des marabouts.
mnitu est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse
Outils de la discussion

Navigation rapide


Fuseau horaire GMT +2. Il est actuellement 21h32.


 
 
 
 
Partenaires

Hébergement Web