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

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien Help Desk
    Inscrit en
    avril 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations professionnelles :
    Activité : Technicien Help Desk
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2018
    Messages : 2
    Points : 1
    Points
    1
    Par défaut Base TEST rafraichie par EXPDP/IMPDP et requête SQL couteuse => TEMP.DBF > 33 Go
    Bonjour,

    j'ai un serveur de base de données sous Oracle 10gR2 (serveur WINDOWS serveur 2008 x64).

    Il y a plusieurs bases de données dessus, y compris la base Production liée à une application, mais aussi la base TEST qui est bien utile pour tester les mises à jour de l'application, ou suite paramétrage à faire suivant les demandes des utilisateurs.

    En temps normal, tout va bien.
    j'ai un traitement via cette application qui tourne sur ma base de production, qui dure 2 heures et c'est nickel.

    J'ai besoin de tester ce traitement sur la base TEST et donc, j'effectue un EXPDP de ma base production puis un IMPDP pour rafraichir la base TEST.

    Puis j’exécute ce traitement. Ce traitement effectue des requêtes SQL (requêtes lancées par une application d'une société éditrice), et l'une d'elles (un SELECT avec des UNION, des group by et qui fait appel à des tables de plusieurs millions de lignes) fait gonfler le TEMP.DBF jusqu'à 33 Go, puis bien entendu, le traitement s'arrête et n'aboutit pas (exclusivement sur la base TEST).

    Si j'attends le lendemain, le traitement fonctionne de nouveau sur la BASE TEST et tout est OK (le TEMP.DBF ne gonfle pas et les temps sont les mêmes que sur la base production).

    Le premier traitement de ce genre sur la base TEST peut faire grossir le TEMP.DBF et fait planter le traitement. Mais le lendemain, c'est toujours OK.
    Si le problème doit se produire, je dois absolument faire exécuter le traitement, pour que le TEMP.DBF passe à 33 Go pour que le lendemain, cela soit ok.
    Ce que je veux dire, c'est que si le problème se produit sur la base TEST, il doit se produire au moins une fois pour être corrigé le lendemain.
    Exemple :
    rafraîchissement de la base TEST
    je lance ensuite le traitement => il plante
    le lendemain => OK
    Je rafraîchis de nouveau la base TEST
    Je ne lance pas le traitement
    le jour suivant, je lance le traitement => il plante
    puis, le jour d'après => OK.

    Donc, je suppose qu'Oracle analyse (au moins) une fois par jour les requêtes SQL executées puis les optimise en évaluant un meilleur plan d’exécution ou met à jour des stats, ou des éléments qui font que le problème n’apparaît plus.

    Donc, afin de ne pas attendre le lendemain, sauriez vous s'il est possible de forcer ce traitement Oracle en journée et si oui comment ?

    Si vous le souhaitez je peux donner plus d'informations.

    En vous remerciant par avance.

  2. #2
    Membre éclairé Avatar de 13thFloor
    Homme Profil pro
    DBA Oracle freelance
    Inscrit en
    janvier 2005
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : DBA Oracle freelance

    Informations forums :
    Inscription : janvier 2005
    Messages : 645
    Points : 889
    Points
    889
    Par défaut
    Hello,
    il y a en effet un job de collectes de statistiques qui se déclenche chaque soir à partir de 22h. Les tables ayant une variation de + de 10% de blocs sont concernées.
    Tu as dû faire un import datapump sans stats ou avec des stats incorrectes ou manquantes.
    Quelles sont les options utilisées du impdp ?

    Mon conseil : un calcul des stats après l'import devrait éviter la saturation du TStemp, et donc de meilleurs plans d'exécution.
    Syntaxe : exec dbms_stats.gather_schema_stats('TON_SCHEMA',estimate_percent=>100,cascade=>true,method_opt=>'for all columns size repeat');
    Si tu as 4 cpu : ajoutes ,degree=>4

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien Help Desk
    Inscrit en
    avril 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations professionnelles :
    Activité : Technicien Help Desk
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2018
    Messages : 2
    Points : 1
    Points
    1
    Par défaut Réponse
    Bonjour,

    tout d'abord, merci pour votre réponse.

    Dans le log de l'expdp, j'ai ceci avant l'export des données :

    Traitement du type d'objet SCHEMA_EXPORT/USER
    Traitement du type d'objet SCHEMA_EXPORT/ROLE_GRANT
    Traitement du type d'objet SCHEMA_EXPORT/DEFAULT_ROLE
    Traitement du type d'objet SCHEMA_EXPORT/TABLESPACE_QUOTA
    Traitement du type d'objet SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/TABLE
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/INDEX/INDEX
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
    Traitement du type d'objet SCHEMA_EXPORT/VIEW/VIEW
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS


    donc, je suppose que les stats sont dans le dump généré.

    De plus, je pense que l'impdp a été effectué avec les stats, car j'ai ceci à la fin du fichier log, après l'import des données :

    Traitement du type d'objet SCHEMA_EXPORT/TABLE/INDEX/INDEX
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
    Traitement du type d'objet SCHEMA_EXPORT/VIEW/VIEW
    Traitement du type d'objet SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS


    et voici les paramètres de impdp :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    REMAP_SCHEMA=BASE_PROD:BASE_TEST REMAP_TABLESPACE=BASE_PROD:BASE_TEST
    est ce qu'il faut rajouter 1 ou des paramètres en plus ?

    Concernant vos conseils, je vais voir sur un serveur de test cloné et en vase clos, et exécuter la ligne de commande proposée.

Discussions similaires

  1. Réponses: 3
    Dernier message: 13/02/2014, 17h03
  2. Requête trés couteuse en temps
    Par jm49 dans le forum SQL
    Réponses: 7
    Dernier message: 22/07/2009, 17h26
  3. [adodbapi]Effectuer des requêtes SQL sur un fichier dbf
    Par Marie S. dans le forum Général Python
    Réponses: 5
    Dernier message: 22/10/2008, 13h57
  4. [RegEx] remplacer AND par WHERE dans une requête SQL
    Par Kyaan dans le forum Langage
    Réponses: 2
    Dernier message: 17/07/2008, 15h42
  5. [MySQL] Requête sql dans le temps
    Par Hurin dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 02/06/2008, 17h51

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