Import de table plus long si table vidée que si table droppée/recréée ? [Résolu]

[scheu]

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

[orafrance]

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.

[scheu]

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

[orafrance]

Envoyé par scheu

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 ?

Envoyé par scheu

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

[scheu]

Mes tables n'étaient pas partitionnées (c'était justement pour ça que je devais faire des exports/imports partiels pour pouvoir les purger)

[Tracnac]

Envoyé par scheu

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 :

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 :

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>

[scheu]

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 :

TRUNCATE TABLE matable DROP STORAGE;

J'avais oublié le DROP STORAGE