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 :

Import de table plus long si table vidée que si table droppée/recréée ?


Sujet :

Administration Oracle

  1. #1
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut Import de table plus long si table vidée que si table droppée/recréée ?
    Tout est dit dans le titre : comment se fait-il qu'un import de table soit plus long lorsque l'on a fait au préalable un TRUNCATE que si on l'a droppée puis recréée ?

    PS : je suis en 9i
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  2. #2
    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
    A priori il n'y a pas de raison... mais on peut imaginer qu'après le DROP tu ne recrées pas tout de suite les indexes et contraintes et que du coup l'import est plus rapide.

  3. #3
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    En fait je devais purger plusieurs tables non partitionnées qui faisaient chacune plusieurs millions de lignes, donc j'avais fait pour chaque table :
    1) export partiel (clause where en ne gardant que les lignes que je veux garder)
    2) truncate
    3) drop indexes et désactivation contraintes
    4) import du dump partiel
    C'est bizarre à chaque fois c'était beaucoup plus long que si j'avais droppé puis recréé la table, en mettant les mêmes paramètres d'import (j'ai fait le test) ..

    Autre question, pourquoi quand on truncate une table, sa taille dans la vue dba_segments reste à sa taille d'origine (avant le truncate) au lieu de revenir à la taille d'un extent ? Ca veut dire qu'elle occupe physiquement toujours le même espace dans le tablespace ? Y a-t-il un moyen d'y remédier ?

    Merci d'avance
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  4. #4
    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
    Citation Envoyé par scheu Voir le message
    C'est bizarre à chaque fois c'était beaucoup plus long que si j'avais droppé puis recréé la table, en mettant les mêmes paramètres d'import (j'ai fait le test) ..
    Avec les mêmes règles de partitionnement ?

    Citation Envoyé par scheu Voir le message
    Autre question, pourquoi quand on truncate une table, sa taille dans la vue dba_segments reste à sa taille d'origine (avant le truncate) au lieu de revenir à la taille d'un extent ? Ca veut dire qu'elle occupe physiquement toujours le même espace dans le tablespace ? Y a-t-il un moyen d'y remédier ?
    Probablement que cette taille correspond au INITIAL * nb de partitions. Seul moyen d'y remédier : réduire le INITIAL ou le nombre de partition

  5. #5
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Mes tables n'étaient pas partitionnées (c'était justement pour ça que je devais faire des exports/imports partiels pour pouvoir les purger)
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  6. #6
    Membre régulier
    Inscrit en
    Septembre 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : Septembre 2005
    Messages : 73
    Points : 82
    Points
    82
    Par défaut
    Citation Envoyé par scheu Voir le message

    Autre question, pourquoi quand on truncate une table, sa taille dans la vue dba_segments reste à sa taille d'origine (avant le truncate) au lieu de revenir à la taille d'un extent ? Ca veut dire qu'elle occupe physiquement toujours le même espace dans le tablespace ? Y a-t-il un moyen d'y remédier ?

    Merci d'avance
    Hello,

    BIzarre je pense que tu ne lis pas les bonnes infos...

    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
     
    COL SEGMENT_NAME FORMAT A20
    COL BLOCKS FORMAT 99
    drop table BIGEXTENT;
    create table BIGEXTENT (a varchar2(255));
    select SEGMENT_NAME, BLOCKS
    from dba_segments
    where SEGMENT_NAME = 'BIGEXTENT';
    DECLARE
    a varchar2(254);
    i integer;
    BEGIN
    for i in 1..10000 LOOP
    insert into BIGEXTENT values ('ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789');
    end loop;
    END;
    /
    select SEGMENT_NAME, BLOCKS
    from dba_segments
    where SEGMENT_NAME = 'BIGEXTENT';
    truncate table BIGEXTENT;
    select SEGMENT_NAME, BLOCKS
    from dba_segments
    where SEGMENT_NAME = 'BIGEXTENT';
    Résultat

    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
     
    SQL> 
    Table dropped.
     
    SQL> 
    Table created.
     
    SQL>   2    3  
    SEGMENT_NAME         BLOCKS
    -------------------- ------
    BIGEXTENT                 8
     
    SQL>   2    3    4    5    6    7    8    9  
    PL/SQL procedure successfully completed.
     
    SQL>   2    3  
    SEGMENT_NAME         BLOCKS
    -------------------- ------
    BIGEXTENT                64
     
    SQL> 
    Table truncated.
     
    SQL>   2    3  
    SEGMENT_NAME         BLOCKS
    -------------------- ------
    BIGEXTENT                 8
     
    SQL>

  7. #7
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Pour ceux qui auraient le même problème j'ai trouvé la solution pour éviter les problèmes lorsqu'on vide une table en vue de la réimporter (partiellement ou non), il faut faire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    TRUNCATE TABLE matable DROP STORAGE;
    J'avais oublié le DROP STORAGE
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

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

Discussions similaires

  1. Réponses: 10
    Dernier message: 22/04/2016, 10h50
  2. Table plus volumineuse aprés export/import
    Par ora00600 dans le forum Import/Export
    Réponses: 3
    Dernier message: 14/05/2012, 20h20
  3. Réponses: 0
    Dernier message: 15/03/2012, 18h24
  4. Update de date vide dans une table
    Par gidebo dans le forum Bases de données
    Réponses: 4
    Dernier message: 15/03/2004, 16h48
  5. [conception] champs vides ou plusieurs tables ?
    Par in dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 17/02/2004, 08h41

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