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

Administration Oracle Discussion :

Statspack, plan d'exécution bizarre avec Scan Index APRES accès table


Sujet :

Administration Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2013
    Messages
    2 005
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Avril 2013
    Messages : 2 005
    Par défaut Statspack, plan d'exécution bizarre avec Scan Index APRES accès table
    Rebonjour les experts Oracle
    Dans le plan d'exécution ci-dessous, j'ai la désagréable impression que les étapes 14 et 15 sont inversées ou mal affichées.
    J'ai effacé les noms des objets pour des raisons de confidentialités (absence de l'INSERT aussi) mais l'index en ligne 14 est l'index associé à la PK de la table de la ligne 15.
    Quand on regarde leur indentation, la ligne 14 doit être exécutée avant la 15, l'opération 14 étant la fille de l'opération 15.
    Le pb c'est que l'affichage ne suit pas ce qui est fait pour les opérations 8 et 9, 10 et 11, 12 et 13

    A noter que ce plan d'exécution lit 1Go sur le disque dur et 1To en mémoire, soit un rapport de 1 000... est-ce que les deux sont liés?

    Dernière question : la ligne 7 fait un sort et n'a besoin que de 10Mo et pas 10Go pour s'exécuter en mémoire?
    Nom : PlanExecution.jpg
Affichages : 303
Taille : 79,5 Ko

    Un GROS GROS merci pour votre aide.

  2. #2
    Membre Expert

    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
    Par défaut
    Hello

    C'est l'effet de la transformation appelée NLJ_BATCHING (Nested Loop Join Batching)

    https://docs.oracle.com/cd/B28359_01...s.htm#BABFCIAI

    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
    SQL> select * from t1 where id in (select id from t2 where x1 = 17335) order by id  ;
     
    Plan hash value: 250297636
    ----------------------------------------------------------------------------------------
    | Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT               |       |       |       |   255 (100)|          |
    |   1 |  NESTED LOOPS                  |       |   100 | 13100 |   254   (1)| 00:00:01 |
    |   2 |   NESTED LOOPS                 |       |   100 | 13100 |   254   (1)| 00:00:01 |
    |   3 |    SORT UNIQUE                 |       |   100 |  1000 |   103   (0)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| T2    |   100 |  1000 |   103   (0)| 00:00:01 |
    |*  5 |      INDEX RANGE SCAN          | T2_I1 |   100 |       |     3   (0)| 00:00:01 |
    |*  6 |    INDEX RANGE SCAN            | T1_N1 |     1 |       |     2   (0)| 00:00:01 |
    |   7 |   TABLE ACCESS BY INDEX ROWID  | T1    |     1 |   121 |     3   (0)| 00:00:01 |
    ----------------------------------------------------------------------------------------
     
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       5 - access("X1"=17335)
       6 - access("ID"="ID")
    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
    SQL> select /*+ no_nlj_batching(t1) */ * from t1 where id in (select id from t2 where x1 = 17335) order by id  ;  
     
    Plan hash value: 1500308460
    ----------------------------------------------------------------------------------------
    | Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    ----------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT               |       |       |       |   255 (100)|          |
    |   1 |  TABLE ACCESS BY INDEX ROWID   | T1    |     1 |   121 |     3   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                 |       |   100 | 13100 |   254   (1)| 00:00:01 |
    |   3 |    SORT UNIQUE                 |       |   100 |  1000 |   103   (0)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| T2    |   100 |  1000 |   103   (0)| 00:00:01 |
    |*  5 |      INDEX RANGE SCAN          | T2_I1 |   100 |       |     3   (0)| 00:00:01 |
    |*  6 |    INDEX RANGE SCAN            | T1_N1 |     1 |       |     2   (0)| 00:00:01 |
    ----------------------------------------------------------------------------------------
     
    Predicate Information (identified by operation id):
    ---------------------------------------------------
     
       5 - access("X1"=17335)
       6 - access("ID"="ID")

    Bien à vous
    Mohamed

  3. #3
    Membre Expert
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2013
    Messages
    2 005
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Avril 2013
    Messages : 2 005
    Par défaut
    Je n'en avais jamais entendu parler... un gros merci à toi Mohamed car cela m'intriguait fortement


    Il reste deux questions à résoudre; allez messieurs-dames, à vot'bon coeur
    - ce plan d'exécution lit 1Go sur le disque dur et 1To en mémoire, soit un rapport de 1 000... je pensais à un pb de Nested Loop Joins mais chaque jointure utilise un index, et hyper sélectif car sur PK...
    - la ligne 7 indique un sort : la taille affichée est bien de 10Mo et non pas de 10Go pour s'exécuter en mémoire?

Discussions similaires

  1. [18c] Baseline avec deux plans d'exécutions pour un ordre avec le hint INDEX
    Par Ikebukuro dans le forum Administration
    Réponses: 6
    Dernier message: 13/10/2019, 10h27
  2. Réponses: 10
    Dernier message: 14/10/2016, 11h03
  3. Parametre d'instance pour explain plan avec Bitmap index
    Par Arvulis dans le forum Administration
    Réponses: 1
    Dernier message: 06/02/2009, 14h14
  4. Optimiser la requête avec un plan d'exécution
    Par irnbru dans le forum Développement
    Réponses: 1
    Dernier message: 20/08/2008, 00h07
  5. MySQL - Probleme avec 2 index sur une table
    Par xG-Hannibal dans le forum Outils
    Réponses: 7
    Dernier message: 31/03/2006, 14h08

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