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

Oracle Discussion :

Purge très longue [10gR2]


Sujet :

Oracle

  1. #1
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut Purge très longue
    Bonjour,


    Je suis sur oracle version 10GR2.
    J'utilise une procédure pour faire une purge ou delete de lignes.
    Cela prend enormement de temps.
    En observant le rapport AWR lors de l'utilisation de la purge :

    Si on observe le rapport AWR de la journée du 14 novembre 2013 14:03 entre 14h00 et 15h00
           Snap Id      Snap Time      Sessions Curs/Sess
        --------- ------------------- -------- ---------
    Begin Snap:     22823 14-Nov. -13 14:00:5       73       2.5
      End Snap:     22824 14-Nov. -13 15:00:0       77       2.6
       Elapsed:               59.15 (mins)
       DB Time:              102.48 (mins)

    On voit bien que le DB Time le temps que la base travaille est important 102 minutes.

    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    ------------------------------ ------------ ----------- ------ ------ ----------
    db file scattered read            1,364,770       2,917      2   47.4   User I/O
    CPU time                                          1,700          27.6
    db file sequential read             502,263       1,277      3   20.8   User I/O
    log file sync                        31,882         529     17    8.6     Commit
    read by other session                25,704         242      9    3.9   User I/O
    
    
    
    SQL ordered by Elapsed Time          DB/Inst: TIBCO/TIBCO  Snaps: 22823-22824
    -> Resources reported for PL/SQL code includes the resources used by all SQL
       statements called by the code.
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
    -> Total DB Time (s):           6,149
    -> Captured SQL account for     137.5% of Total
    
      Elapsed      CPU                  Elap per  % Total
      Time (s)   Time (s)  Executions   Exec (s)  DB Time    SQL Id
    ---------- ---------- ------------ ---------- ------- -------------
         3,468      1,395            0        N/A    56.4 5rk61v1gk6us7
    Module: JDBC Thin Client
    BEGIN TIBCO_LOGGER.PURGE_EAILOGGER(:1,:2,:3); END;
    
         3,467      1,395           35       99.1    56.4 3c624n8d6d4zm
    Module: JDBC Thin Client
    DELETE FROM LOG_EVENT L WHERE L.LOGID=:B1
    
         3,464      1,395           35       99.0    56.3 9ux3g30p8t92r
    Module: JDBC Thin Client
    select /*+ all_rows */ count(1) from "TIBCO_LOGGER"."APPLICATION_CONTEXT" where
    "LOGID" = :1
    On retrouve bien les requêtes en question :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    BEGIN TIBCO_LOGGER.PURGE_EAILOGGER(:1,:2,:3); END;
     
    DELETE FROM LOG_EVENT L WHERE L.LOGID=:B1
     
    select /*+ all_rows */ count(1) from "TIBCO_LOGGER"."APPLICATION_CONTEXT" where
    "LOGID" = :1
    On a bien la procédure de purge. Et la requête en question :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    DELETE FROM LOG_EVENT L WHERE L.LOGID=:B1
    Comment faire pour améliorer les performances de cette purge.


    Merci pour votre aide.


    Genius

  2. #2
    Membre éclairé Avatar de jkofr
    Homme Profil pro
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    Octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 484
    Points : 724
    Points
    724
    Par défaut
    Hello,

    Combien de CPU à votre serveur?

    Dans le rapport AWR on constate que l'équivalent de 1 CPU (env) est utilisé constamment pendant la période.

    Vous pouvez, dans le cas ou vous disposez de suffisamment de CPU, effectuer l'opération en parallèle.

    ALTER SESSION FORCE PARALLEL DDL PARALLEL 8; (degré fonction de vos CPU).

    Une idée serait aussi de partitionner vos tables... LOGID semble être une bonne partition key.

    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  3. #3
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    Quelques remarques d'ordre général

    Ce n'est pas normal de faire plus de full segment (table/index) scans que de lectures via index dans une application OLTP. Heureusement que vous êtes servi pas un disque très rapide au vu du temps moyen de lecture du disque de ces deux événements à savoir 2 ms et 3 ms respectivement.

    Vous faites 31,882 log file sync en 1 heure ce qui veut dire presque 9 commits par seconde. Chaque log file sync prend 17 ms. Ce n'est pas un nombre de commit exorbitant. Mais à votre place je vérifierai quand même combien de user commits vous faites par heure. Je réduirai ce nombre de commit dans le code PL/SQL. Je crois bien que vous faites plusieurs user commits mais comme vous les soumettez en bloque PL/SQL il y a donc un log file sync par appel ce qui réduit le nombre de log file sync à votre avantage. Il représente quand même presque 10% de votre temps (8,6%).

    Identifiez les sql qui font des lectures physiques sur les tables (sql ordered by read et segment ordered by physical read), prenez leur plan d’exécution et essayez de réduire les full table scans. Cela représente presque 50% de votre temps. Et c’est là où les efforts doivent être concentrés.
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  4. #4
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Merci très chers collegues pour vos réponses.
    Je prends note de vos remarques.
    En terme de CPU il n'y en a que deux. Donc on ne peut jouer sur le paralellism.
    Pour ce qui est des requêtes je vais faire un focus dessus.

    Par contre étant donné que c'est une purge donc des deletes n'y a t'il pas des problemes sur les foreign key ?
    N'est ce pas dans cet axe qu'il faudrait que je m'oriente ?


    Cordialement,


    genius92

  5. #5
    Expert éminent sénior 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
    Points : 11 252
    Points
    11 252
    Par défaut
    Que est-ce que la procédure TIBCO_LOGGER.PURGE_EAILOGGER fait (sa logique) ?
    Pourquoi a t-elle été exécutée 35 fois dans une heure (à quoi ça corresponde dpv applicatif) ?
    Pourquoi vous comptez les enregistrements de la table APPLICATION_CONTEXT (que est-ce que vous faite avec le résultat)?
    En plus regardez les plans d'exécutions de ces deux requêtes.

  6. #6
    Membre expérimenté

    Homme Profil pro
    Inscrit en
    Mars 2010
    Messages
    536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 536
    Points : 1 359
    Points
    1 359
    Par défaut
    En terme de CPU il n'y en a que deux. Donc on ne peut jouer sur le paralellism.
    2 CPU * 59.15 min * 60 sec = 7098 secondes de CPU disponible

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    ------------------------------ ------------ ----------- ------ ------ ----------
    CPU time                                          1,700          27.6
    Sur les 7098 secondes vous avez consommé 1700. Ce qui veut dire que vous êtes déjà à 24% d'utilisation de la CPU. Ca n'est pas encore problématique mais il va falloir tenir cela à l'oeil.
    Bien Respectueusement
    www.hourim.wordpress.com

    "Ce qui se conçoit bien s'énonce clairement"

  7. #7
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Bonjour,



    J'ai pu récupérer la procédure de purge :


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    TEXT
    --------------------------------------------------------------------------------
    PROCEDURE                                                      PURGE_EAILOGGER (
    indiceCommit in integer, nbLineOut out integer, statutCode out varchar2)
     
    IS
     
        flowcodeC VARCHAR2(64 BYTE);
        logidC NUMBER;
        contextidC VARCHAR2(64 BYTE);
        flowidC VARCHAR2(256 BYTE);
        indice number ;
        nbLine number ;
     
    TEXT
    --------------------------------------------------------------------------------
        file_handle UTL_FILE.FILE_TYPE;
        v_file_name VARCHAR2(256) := 'log_purge_eailogger_'|| TO_CHAR(sysdate, 'YYYY
    MMDD_HH24MI') || '.txt';
     
        v_file_location VARCHAR2(256) := 'PURGE_EAILOGGER_REP';
     
            Cursor DataToPurge IS
            select DISTINCT l.flowcode,  l.logid , l.contextid , l.flowid
        from log_event l ,dalkia_gui.halfflow_description tf
        where cast(l.clientlogtimestamp as date) < sysdate-tf.retentionday
        and tf.halfflow_code =l.halfflowcode
     
    TEXT
    --------------------------------------------------------------------------------
        and tf.ispurge='Y' and halfflowcode!='FLAT_FILE-TO-FLAT_FILE'
        --group by l.flowcode,l.halfflowcode,l.flowid
        order by l.flowcode desc;
     
     
     
     
                    begin
        file_handle := UTL_FILE.FOPEN(v_file_location,v_file_name,'A');
        UTL_FILE.PUT_LINE(file_handle,'Purge begins at '|| TO_CHAR(sysdate, 'YYYY/MM
    /DD_HH24:MI'));
     
    TEXT
    --------------------------------------------------------------------------------
     
        UTL_FILE.FFLUSH(file_handle);
     
          indice:=0;
          nbLine:=0;
          statutCode:='OK';
          nbLineOut:=0;
                            Open DataToPurge;
                                    Loop
                                            Fetch DataToPurge into flowcodeC,logidC,contextidC,FLOWIDC;
                                            exit when DataToPurge%NOTFOUND;
     
    TEXT
    --------------------------------------------------------------------------------
     
              begin
                delete from exception e where e.logid=logidC;
                delete from msg_body m where m.contextid=contextidC;
                delete from process_context p where p.contextid=contextidC;
                delete from application_context ac where ac.flowid=FLOWIDC;
                delete from log_event l where l.logid=logidC;
                DELETE FROM TIBCO_REMEDIATION.RESUBMISSION_V2  WHERE flowid=flowidc;
     
     
     
     
    TEXT
    --------------------------------------------------------------------------------
                                            EXCEPTION
                                            when OTHERS Then
              UTL_FILE.PUT_LINE(file_handle,'Exception in Purge');
              statutCode:='KO';
              exit;
              ROLLBACK ;
              end;
              if (indice=indiceCommit) then
              commit;
              indice:=0;
              UTL_FILE.PUT_LINE(file_handle,'Total lines purged '|| nbLine ||' at '|
     
    TEXT
    --------------------------------------------------------------------------------
    | TO_CHAR(sysdate, 'YYYY/MM/DD_HH24:MI'));
     
              UTL_FILE.FFLUSH(file_handle);
              end if;
             indice:=indice+1;
             nbLine:=nbLine+1;
                                    end loop;
                            close DataToPurge;
          if(statutCode = 'OK') then
          commit;
          UTL_FILE.PUT_LINE(file_handle,'Purging is complete');
     
    TEXT
    --------------------------------------------------------------------------------
          UTL_FILE.PUT_LINE(file_handle,'Total lines purged '|| nbLine ||' at '|| TO
    _CHAR(sysdate, 'YYYY/MM/DD_HH24:MI'));
     
          end if;
          nbLineOut:=nbLine;
          UTL_FILE.FFLUSH(file_handle);
          UTL_FILE.FCLOSE(file_handle);
                    end;


    Genius92

  8. #8
    Membre éclairé Avatar de jkofr
    Homme Profil pro
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    Octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 484
    Points : 724
    Points
    724
    Par défaut
    Hello,

    Quelle est la distribution des valeurs logidC,contextidC,FLOWIDC?

    Valeurs distinctes?
    Nombre de lignes dans chaque tables?


    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  9. #9
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Voici les plans d' exécutions des deux requêtes :

    1/ requete 1:


    SQL> explain plan for DELETE FROM TIBCO_LOGGER.LOG_EVENT L WHERE L.LOGID=:B1;
    
    Explained.
    
    SQL> @/app/local/oracle/product/10.2.0/Db_1/rdbms/admin/utlxpls.sql
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    Plan hash value: 231597685
    
    -----------------------------------------------------------------------------------
    
    | Id  | Operation          | Name         | Rows  | Bytes | Cost (%CPU)| Time  |
    
    -----------------------------------------------------------------------------------
    
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    |   0 | DELETE STATEMENT   |              |     1 |   165 |     3   (0)| 00:00:01 |
    
    |   1 |  DELETE            | LOG_EVENT    |       |       |            |
      |
    
    |*  2 |   INDEX UNIQUE SCAN| PK_LOG_EVENT |     1 |   165 |     3   (0)| 00:00:01 |
    
    --------------------------------------------------------------------------------
    ---
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("L"."LOGID"=TO_NUMBER(:B1))
    
    14 rows selected.



    2/ requete 2 :


    SQL> explain plan for SELECT /*+ all_rows */ count(1) FROM "TIBCO_LOGGER"."APPLICATION_CONTEXT" WHERE "LOGID" = :1 ;
    
    Explained.
    
    SQL> @/app/local/oracle/product/10.2.0/Db_1/rdbms/admin/utlxpls.sql
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    Plan hash value: 3410848644
    
    ------------------------------------------------------------------------------------------
    
    | Id  | Operation          | Name                | Rows  | Bytes | Cost (%CPU)|Time     |
    
    ------------------------------------------------------------------------------------------
    
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT   |                     |     1 |     6 |   137K  (1)|00:27:26 |
    
    |   1 |  SORT AGGREGATE    |                     |     1 |     6 |            |         |
    
    |*  2 |   TABLE ACCESS FULL| APPLICATION_CONTEXT |     7 |    42 |   137K  (1)|00:27:26 |
    
    ------------------------------------------------------------------------------------------
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - filter("LOGID"=TO_NUMBER(:1))
    
    Nombre de lignes des tables :

    SQL> select count(*)  from  TIBCO_LOGGER.APPLICATION_CONTEXT;
    
      COUNT(*)
    ----------
      68692146
    
    SQL>  select count(*)  from  TIBCO_LOGGER.LOG_EVENT;
    
      COUNT(*)
    ----------
      69453183

  10. #10
    Membre éclairé Avatar de jkofr
    Homme Profil pro
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    Octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 484
    Points : 724
    Points
    724
    Par défaut
    Hello,

    Essayez d'utiliser les balises de code et de formater un peu.
    Cela facilitera la lecture.

    Jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  11. #11
    Membre expérimenté 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 : 49
    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
    Points : 1 597
    Points
    1 597
    Par défaut
    Combien d'index y-a-t-il sur votre table ?

  12. #12
    Membre éclairé Avatar de jkofr
    Homme Profil pro
    Senior Consultant DBA (Trivadis SA)
    Inscrit en
    Octobre 2006
    Messages
    484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : Suisse

    Informations professionnelles :
    Activité : Senior Consultant DBA (Trivadis SA)
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 484
    Points : 724
    Points
    724
    Par défaut
    27 min pour exécuter la requête:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    SELECT /*+ all_rows */ count(1) FROM "TIBCO_LOGGER"."APPLICATION_CONTEXT" WHERE "LOGID" = :1 ;
    C'est normal, sans doute, avec un full scan...

    jko
    OCM 11g, RAC and Performance & Tuning Expert 11g
    RMAN Backup & Recovery, Data Guard and Grid Control

  13. #13
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Rebonjour,

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    SQL> select OWNER,INDEX_NAME,INDEX_TYPE,GENERATED,LAST_ANALYZED  from dba_indexes  where
      2  TABLE_OWNER='TIBCO_LOGGER'
      3  and TABLE_NAME='LOG_EVENT';
     
    OWNER                          INDEX_NAME                     INDEX_TYPE                  G LAST_ANA
    ------------------------------ ------------------------------ --------------------------- - --------
    TIBCO_LOGGER                   IDX_LOGEVENT_HALFFLOW          NORMAL                      N 18/11/13
    TIBCO_LOGGER                   IDX_LOG_EVENT                  NORMAL                      N 18/11/13
    TIBCO_LOGGER                   IDX1_LOG_EVENT                 NORMAL                      N 18/11/13
    TIBCO_LOGGER                   LOG_EVENT_FLOWID               NORMAL                      N 18/11/13
    TIBCO_LOGGER                   LOG_EVENT_HALFFLOWID           NORMAL                      N 18/11/13
    TIBCO_LOGGER                   LOG_EVENT_CONTEXTID            NORMAL                      N 18/11/13
    TIBCO_LOGGER                   SYS_IL0000051901C00010$$       LOB                         Y
    TIBCO_LOGGER                   PK_LOG_EVENT                   NORMAL                      N 18/11/13
     
    8 rows selected.
     
    SQL> select OWNER,INDEX_NAME,INDEX_TYPE,GENERATED,LAST_ANALYZED  from dba_indexes  where
      2   TABLE_OWNER='TIBCO_LOGGER'
      3  and TABLE_NAME='APPLICATION_CONTEXT';
     
    OWNER                          INDEX_NAME                     INDEX_TYPE                  G LAST_ANA
    ------------------------------ ------------------------------ --------------------------- - --------
    TIBCO_LOGGER                   APPLICATION_CONTEXT_FLOWID     NORMAL                      N 12/11/13
    J'ai fait une recherche sur la view INDEX_STATS:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    SQL> select (DEL_LF_ROWS_LEN/LF_ROWS_LEN)*100   from  INDEX_STATS
      2  where NAME='IDX1_LOG_EVENT';
     
    no rows selected
     
    SQL> select *  from  INDEX_STATS;
     
    no rows selected


    Il semble qu'il n'y ai pas de stats sur les indexes.
    Cela expliquerai pourquoi l'indexe 'IDX1_LOG_EVENT' n'est pas utilisé dans la requête :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    DELETE FROM TIBCO_LOGGER.LOG_EVENT L WHERE L.LOGID=:B1;
    Merci pour votre avis.

    Genius92

  14. #14
    Expert éminent sénior 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
    Points : 11 252
    Points
    11 252
    Par défaut
    Citation Envoyé par GENIUS92 Voir le message
    J'ai pu récupérer la procédure de purge :
    ...
    Supprimer dans une boucle c’est la meilleure façon de se prendre pour plomber les performances. ! Récrivez la procédure pour exécuter les N delete une seule fois sans aucune boucle. Si cela vous semble compliqué réécrivez la procédure pour utiliser les collections et la suppression via ForAll. Dans ce cas vous pouvez attendre de temps de réponse comparable à la première solution.
    En même temps analysez les plans d’exécution de vos requêtes pour qu’ils utilisent le bon plan. Notez par ailleurs que l’analyse via la commande explain plan en présence des variables de liaison n’est pas fiable parce que cette commande ne fait pas d’introspection des variables « peek variable binding ». Autrement dit vous analysez un plan hypothétique et non pas le plan réel (qui peut être différent). Dans ce cas exécutez la requête avec des variables de liaison et analysez-la avec dbms_xplan.display_cursor.

  15. #15
    Membre expérimenté 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 : 49
    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
    Points : 1 597
    Points
    1 597
    Par défaut
    J'ajouterai qu'il serait intéressant de rendre tous les index qui ne correpsondant pas à des contraintes unusable avant la purge et de les reconstruire après. en effet, actuellement, à chaque ligne mise à jour,
    • la pk est parcourue en mode monobloc pour accéder à la ligne à supprimer
    • la clé est supprimée au niveau de la pk
    • la ligne est supprimée dans la table
    • chaque index est parcouru en mode multibloc pour supprimer l'entrée correspondant à la ligne supprimée

    tout cela prend évidemment un temps phénoménal.

  16. #16
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    Sinon, si c'est un traitement nouveau qui tournera régulièrement, ce n'est peut-être que la première passe qui coute du temps. Dans ce cas, ça peut valoir la peine d'extraire les données à garder dans une table temporaire, tronquer les tables à purger et réinjecter les lignes pour ensuite faire tourner la purge "normalement" sur un volume qui sera plus acceptable pour les perfs attendues

  17. #17
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Novembre 2013
    Messages : 7
    Points : 3
    Points
    3
    Par défaut
    Merci pour toutes vos remarques.
    Je suis en train de contacter la TMA afin d'exposer plusieurs points que j'ai pu voir avec vous.

    Cordialement,

    Genius92

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [AJAX] Passage d'une variable très longue avec AJAX
    Par Figaro83 dans le forum Général JavaScript
    Réponses: 8
    Dernier message: 18/09/2006, 17h53
  2. Réponses: 12
    Dernier message: 09/09/2006, 12h54
  3. Réponses: 4
    Dernier message: 09/12/2005, 09h25
  4. Comment écrire une très longue variable dans un fichier ?
    Par hijodelanoche dans le forum Langage
    Réponses: 8
    Dernier message: 17/11/2005, 17h12
  5. Acquisition longue, très longue...
    Par pc.bertineau dans le forum Windows
    Réponses: 3
    Dernier message: 24/02/2005, 14h54

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