Tables avec valeur NEXT à 17 TB suite à "IMP/EXP" avec option "TABLESPACE TRANSPORTABLE"

Bonjour à tous,

Nous sommes actuellement dans un contexte de migration d'une base 9.2.0.8.0 vers une base 11.2.0.4 R2.

Dans le principe, nous avons créer une base vide en 11gR2 puis nous transférerons les données de la base 9i vers la base 11gR2 par un export/import (exp/imp) avec l'option "TABLESPACE TRANSPORTABLE".

D'après ce que j'ai vu, l'option NEXT n'existe pas au niveau STORAGE pour les tables en 9I.

Une fois la migration réalisée, les tables et leurs données sont bien basculées mais l'option NEXT de toutes nos tables côté 11G se retrouvent avec la valeur extravagante de 17TB !8O

exemple DDL sur la base 11G d'une petite table qui ne contient que 7 enregistrements :

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

CREATE TABLE VENTES.MOTIF_DELAIS ( ID NUMBER(6), DESCRIPTION VARCHAR2(100 BYTE), PREFIXELOT VARCHAR2(3 BYTE), VISIBLEENTETE VARCHAR2(1 BYTE) ) TABLESPACE VENTES PCTUSED 0 PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE ( INITIAL 64K NEXT 17179869176K MAXSIZE UNLIMITED MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 BUFFER_POOL DEFAULT ) LOGGING NOCOMPRESS NOCACHE NOPARALLEL MONITORING;

---

D'où provient selon vous cette valeur très précise sachant que ce n'est évidement pas moi qui l'ai spécifié ?

y'a t'il quelque chose que nous avons oublié de préciser dans notre migration ? un paramètre manquant ??

quelle est généralement la valeur que prend ce paramètre ?

Est-ce une valeur calculée par ORACLE ? selon quelle règle ??



Beaucoup de questions en cette période estivale...:lol:
j'espère que vous n'êtes pas tous partis !!

merci d'avance pour vos conseils et remarques avisés !



Richard

Hello,

Je ne vais pas pouvoir t'aider vraiment mais :
1) si je fais une recherche Google sur 17179869176K j'obtiens juste deux résultats donc ton post; zut, je pensais que ce pb était plus fréquent...
2) la migration se fait vraiment avec les vieux outils import/export ou avec Datapump via les commandes expdp/impdp? Si c'est avec imp/exp, as-tu essayé avec Datapump pour voir si le résultat est le même?

Bonjour,
Je suppose que les tablespaces de destination sont locally managed (extent management local) et ces paramètres peuvent être ignorés (NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, et DEFAULT STORAGE)
Juste pour être sur, tu peux faire un 'alter table ... allocate extent' en test pour être sûr.
Cordialement,
Franck.

Bonjour Ikebukuro ,

1- j'avais déjà tenter le coup mais sans succès :)
2- je suis obliger de travailler avec les vieux outils imp/exp car le datapump n'a été introduit que depuis la version 10 d'Oracle et ces versions ne sont pas compatibles : On ne peut pas faire un export classique et un import DP.

merci,


Richard

Ah oui, tu as raison, Datapump ne remonte que à la version 10g 8O je pensais que c'était un outil plus vieux.

Citation:

---

Envoyé par pachot

Bonjour,
Je suppose que les tablespaces de destination sont locally managed (extent management local) et ces paramètres peuvent être ignorés (NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, et DEFAULT STORAGE)
Juste pour être sur, tu peux faire un 'alter table ... allocate extent' en test pour être sûr.
Cordialement,
Franck.

---

Bonjour,

oui ils sont tous effectivement en "local".
peux-tu préciser car je ne comprends pas ta remarque concernant le fait que ces paramètres puissent être ignorés.
peux-tu aussi être plus précis sur le test que tu souhaites que je réalise sur 'alter table ... allocate extent'.

merci d'avance Franck :)

Je veux dire que ces paramétrés n'avaient de sens que du temps des 'dictionary managed tablespaces.
L'idée est de forcer l'allocation d'un extent pour être sûr qu'il n'alloue pas 16GB

suite au dépôt sur MOS du "SR 3-13060276001 : How to calculate the value "NEXT" on ORACLE 11G ?" ORACLE annonce qu'il s'agit d'un BUG reconnu dû à l'utilisation de l'option "TRANSPORTABLE TABLESPACE"...

cdlt,

Richard