IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PL/SQL Oracle Discussion :

Différence de temps entre SELECT "rapide" et INSERT "très lent"


Sujet :

PL/SQL Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Nouveau candidat au Club
    Femme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2015
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 50
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Septembre 2015
    Messages : 1
    Par défaut Différence de temps entre SELECT "rapide" et INSERT "très lent"
    Bonjour,

    J'ai une question a vous soumettre, suite à des problèmes de tablespace TEMP qui explose.

    J'effectue une requête SQL un peut compliquée (jointures multiples avec une table de base de 300 millions lignes).
    Quand je fais un select count(*) from xx_tables : cela met 12 minutes => la requête renvoie un count(*) de 3 millions de lignes
    Mais quand je fais le insert matable from select xx_champs from xx_tables => la requête prend 1H30.

    Comment expliquer un tel décalage de temps entre le select et le insert ? Cela vous parait normal ?
    J'ai l'impression qu'entre le select et le insert on ne reste pas sur le serveur BDD (alors que je pensais que si) car j'obtiens une durée de 1H30 lorsque je fais un select xx_champs from xx_tables et que les 3 millions de lignes naviguent entre le serveur et mon requêteur toad.

    Pour info, on a fait une migration récente en oracle 12 donc je me pose la question s'il n'y aurait pas un paramétrage qui expliquerait mes problèmes(tablesspace temp et durée de requête qui explosent) alors que la requête et la volumérie n'ont pas changé.


    Merci d'avance pour vos réponses,
    Claire

  2. #2
    Membre Expert Avatar de ojo77
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Décembre 2010
    Messages
    680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Décembre 2010
    Messages : 680
    Par défaut
    Bonjour,

    Le select count(*) risque de n'utiliser que des index de type primary key et foreign-key pour compter les lignes.

    Pas besoin d'aller chercher les colonnes dans la table (et donc sur disque), c'est juste un comptage des lignes qui est nécessaire.
    Dans le cas du select avec plusieurs champs, il faut bien aller les récupérer ces champs et de fait le plan d'exécution peut être totalement différent.

    De ce fait, vous comparez des choses qui ne sont pas comparables. il est assez peu surprenant que les résultats soient différents.

    Il peut être inéressant de faire des "explain plans" pour les deux requêtes et de comparer leur résultats.

  3. #3
    Expert confirmé Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 : 5 611
    Par défaut
    En plus si votre table de destination contient beaucoup des indexes et ou contraintes de type clé étrangère voir déclencheurs tout ce que cela implique en terme de travail supplémentaire à la simple insertion des données dans la table de destination peut être très important.
    Tracez votre traitement d'insertion pour comprendre où le temps passe et ensuite en fonction de résultat prenez les actions nécessaires à l'optimisation du traitement.

  4. #4
    McM
    McM est déconnecté
    Expert confirmé

    Homme Profil pro
    Développeur Oracle
    Inscrit en
    Juillet 2003
    Messages
    4 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Oracle

    Informations forums :
    Inscription : Juillet 2003
    Messages : 4 580
    Billets dans le blog
    4
    Par défaut
    Pour l'insert il faut aussi prendre en compte le temps d'écriture dans les redologs, d'augmentation d'extents de la table, les undo.

Discussions similaires

  1. Requête rapide après une 1ere execution / très lente avant
    Par nc_dvlp dans le forum Administration
    Réponses: 5
    Dernier message: 03/06/2008, 18h29
  2. Réponses: 7
    Dernier message: 27/02/2008, 13h55
  3. [MySQL] SELECTION DE TEMPS ENTRE 2 DATES
    Par oceane751 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 14/04/2006, 01h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo