Re: "Import succeded with warnings" and ERRORS!?

There's a paper on cloning at my web site (see "Tips" "Administration"). But at the heart of all cloning activities is getting your mits on the actual dbfs. If they are several Gbs big, I think -as you say- that this is not going to be an option for you either.

Sounds like you've been tasked to do the bleedin' impossible with the infinitely improbable, and by yesterday to boot!

Regards
HJR

--
Resources for OracleT: www.geocities.com/howardjr2000
=========================================


"Rick Denoire" <100.17706_at_germanynet.de> wrote in message
news:i2f6ttkll6or95u2d745tqnv71cim08c59_at_4ax.com...


> "Howard J. Rogers" <howardjr_at_www.com> wrote:

>

> >Well, a blunderbuss technique would be:

> >spool masstrunc.txt

> >select 'truncate table ' || table_name || ';' || from dba_tables;

> >spool off

> >@masstrunc.txt

>

> Thanks, this is what I should have done!

> (Sorry, I am not an Oracle expert).

>

> >> I can't still see a straight, reliable way to import a DB in Oracle

> >> and get a copy. Ingres was far easier.

>

> >Well, I'm just going to have to say that you're using the wrong tool with

> >too little information.  If you wan't an *exact* copy of a database (I

mean


> >a logical duplicate, but where file paths etc are allowed to change) then

> >you don't use import blind of the source like this, you use cloning

> >techniques.

>

> You are completely right. I just realized  that there should be

> another way to clone the DB. We get the dump files from a company

> which developed the DB application, but the DB developers themselves

> are not directly reachable. People from this company we deal with are

> not competent enough to explain anything concerning the DB. We are not

> supposed to know anything about the DB schema either and are not

> allowed to make any changes in it. The front end application itself is

> complicated enough.

>

> >If you're using import, it really helps to know something about how the

> >export was done, what the source database looks like and so on.

> >Import/Export are really backup tools, not cloning ones.  They can be

made


> >to do the deed, but not if the nature of the source is kept hidden from

you,


> >and not if you don't know precisely what's in the dump file.

>

> I am wondering about an alternative way to make this clone.

> Transferring the datafiles (physical copy) is not feasible, due to

> their size (several GB).

>

> >> I don't know if I should emphasize again: I need an exact copy of the

> >> exporting DB!

> >>

> >

> >Then don't use export/import, use cloning techniques.

>

> Would you be so kind to mention a few key words about cloning

> techniques? Then I would go for that.

>

> Still learning,

>

> Rick