Re: Transportable Tablespaces and Deferred segment creation "bug"
- From: pier paolo Bruno <pbrunoster@xxxxxxxxx>
- To: oracle@xxxxxxxxxxxxxxx
- Date: Tue, 27 Nov 2012 09:31:24 +0100
If i remember correctly if you make an exp full you don't export table
without associated segment. What i was suggesting you is to make in 2 steps
, first usual transportable tablespace step and then an expdp of the
metadata only of the full database and an import of the metadata_only on
the new instance after you import and make writable the transported
tablespace. In this way it should recreate the tables you miss with no
segment. With imp exp I don't think this works .
2012/11/27 Norman Dunbar <oracle@xxxxxxxxxxxxxxx>
> Morning Pier Paolo,
>
> On 26/11/12 23:11, pier paolo Bruno wrote:
> > Pherhaps it seems stupid .
> No, questions are never stupid!
>
> > I imagine that at the end of the procedure to move your instance you have
> > to make an import for loading all not segment objects...
> Yes. After the TT import and some work setting default tablespaces and
> changing the transported tablespaces to read write, there is a norow
> import.
>
> However, I like to have my problems resolved at one step before movving
> on to the next. When the problem occurred, I wasn't aware of what it was
> nor the cause. The docs are next to useless on the matter as they don't
> go in to any detail about the fact that deferred segments are not
> acceptable to SE databases.
>
> > Can you let impdp with CONTENT=METADATA_ONLY recreate empty and missing
> > table for you from a dump created with content=metadata_only (you can not
> > use exp with rows=no for deferred_segment_creation )
> Impdp, in this example, is unusable because doing a TT impdp requires a
> database link be created between the importing database and the
> exporting database. In our set up, production networks are air-gapped
> from test and/or QA networks, so the transfer of data must be by tape
> (and, as it turns out, secure courier).
>
> Exp/imp is simple, works, and everything is there. Expdp/impdp is not!
>
>
> Cheers,
> Norm.
>
> --
> Norman Dunbar
> Dunbar IT Consultants Ltd
>
> Registered address:
> Thorpe House
> 61 Richardshaw Lane
> Pudsey
> West Yorkshire
> United Kingdom
> LS28 7EL
>
> Company Number: 05132767
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
