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 :

delete trop long à cause d'une fk ou des stats oracle ?


Sujet :

Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    358
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 358
    Par défaut delete trop long à cause d'une fk ou des stats oracle ?
    bonjour,
    j'ai une petite question Oracle ou SQL...

    J'ai une table OPERATION

    OPE_ID ##### OPE_DATE ##### OPE_PRECEDENTE
    1 ######## 29/10/10 ######## NULL
    2 ######## 29/10/10 ######## NULL
    3 ######## 29/10/10 ######## 2
    4 ######## 29/10/10 ######## 1
    5 ######## 29/10/10 ######## 4

    OPE_ID : clé primaire
    OPE_PRECEDENTE : foreign key sur la clé primaire OPE_ID

    J'ai une requête qui a 38000 enregistrements à supprimer de cette table OPERATION.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    Delete from operation where ope_id in (select ope_id from extr_id_arc_pur);
    Nous avons testé sur une base iso-prod en désactivant la contrainte (foreign key FK_OPE_PRECEDENTE) de cette table.

    Le temps d'exécution est de 3min.

    Nous avons réactivé cette contrainte et réimporter les données de la base et le temps d'exécution est > 6 heures.

    Cette colonne OPE_PRECEDENTE peut avoir des valeurs null.

    Il y a un index sur cette colonne.

    J'aurai voulu savoir s'il est possible que cette contrainte puisse faire ralentir les perfs ? A chaque delete, Oracle que fait-il ? il contrôle les foreign key ?

    Autre chose, après le re-import de la base, doit-on recalculer les statistiques oracle ?

    En espérant avoir été clair !!!

    Merci d'avance.

  2. #2
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Sr. Specialist Solutions Architect @Databricks
    Inscrit en
    Septembre 2008
    Messages
    8 454
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Sr. Specialist Solutions Architect @Databricks
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 454
    Par défaut
    Oui, à chaque DELETE Oracle va vérifier l'intégrité référentielle, impacter les index et ça prend du temps.

    Supprimer les index et désactiver les contraintes avant de faire la suppression est une pratique courante.

    Pour les statistiques ça dépend. Si vous supprimez 38.000 lignes d'une table de 50.000 lignes ou de plusieurs millions. Dans le premier cas il faut recalculer, dans le second c'est à priori pas nécessaire.

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    358
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 358
    Par défaut
    finalement, il n'y avait pas d'index sur cette colonne (pas en prod) uniquement en dev.
    Dans l'environnement isoprod, il n'y avait pas d'index.

    On l'a rajouté, on passe de 6h à 3min !!!!!!!

    Lorsque nous avions supprimé la contrainte, il n'y avait pas de souci mais en la réactivant, il faisait un full scan

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
     
    select /*+ all_rows */ count(1) from "NAEADM"."OPERATION" where "OPE_ID_PRECEDE                                                            
    NTE" = :1                      
     
    Plan 1(PHV: 2489153561)
    Execution Plan                                                                                                                              
    --------------------------------------------------------------------------------                                                            
    | Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |                                                            
    --------------------------------------------------------------------------------                                                            
    |   0 | SELECT STATEMENT   |           |       |       | 39197 (100)|          |                                                            
    |   1 |  SORT AGGREGATE    |           |     1 |     2 |            |          |                                                            
    |   2 |   TABLE ACCESS FULL| OPERATION |     1 |     2 | 39197   (2)| 00:07:51 |                                                            
    --------------------------------------------------------------------------------

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

Discussions similaires

  1. Réponses: 1
    Dernier message: 06/03/2014, 18h24
  2. Les mots de passe trop longs peuvent occasionner une attaque DoS
    Par Stéphane le calme dans le forum Sécurité
    Réponses: 15
    Dernier message: 09/02/2014, 17h25
  3. DELETE Trop long
    Par pconrad dans le forum SQL
    Réponses: 8
    Dernier message: 05/02/2008, 09h52
  4. Réponses: 1
    Dernier message: 29/04/2007, 16h18
  5. Passage d'une page web à une autre TROP long
    Par minusette dans le forum Web
    Réponses: 16
    Dernier message: 27/10/2005, 17h40

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