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
    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 éprouvé
    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
    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.

###raw>template_hook.ano_emploi###