Re: import questions

On 14 Jul 2006 15:04:01 -0700, "EdStevens" <quetico_man_at_yahoo.com> wrote:

>That got me past the first problem, the table with the CLOB. Then I
>had a bunch of views, FKs, and procedures that weren't importing.
>Digging deeper, I found the FK's were failing because the PK's they
>referenced were failing. The PK defs were failing because they had
>storage clauses that referenced the TS used by the original schema, and
>am specifically preventing the new schema from having objects in the TS
>used by the old schema.
>

imp with constraints=n , followed by imp with rows=n can fix this.

>So I decided to take the same approach ... export rows=n, and message
>the resulting .dmp file. Lot's of problems. First, there are a couple
>of thousand tables, with their indexes and constraints, and a bunch of
>triggers, so manually fixing it up is not an option. Can't just
>globally add the semicolons to the end of every line because SOME of
>the DDL commands are spread across multiple lines.

vi can be pretty powerful, and vi even exists on winblows

 Again, too many to
>fix by hand. And there are some other things in there that appear to
>be markers used by IMP but are not valid SQL statements -- at least one
>for every table.
>
>Next, I turned to dbms_metatdata. Have never used it so did a lot of
>reading, and it appears that a lot of people find it to be insufficient
>as well. Found some comments about this from Niall on his blog, and a
>LOT of discussion on AskTom. Appear to be a lot of problems again with
>long lines wrapping/breaking in bad places, no command terminators,
>etc. Also I don't know the password of the schema I'm exporting, so
>must do the export as system; can't seem to get that to work at all.
>
>So I'm ready for a fresh look at this if anyone can throw me a bone.
>To restate the problem: replicate one schema to another in the same 9.2
>database, with the new schema useing a new tablespace dedicated to it.

I don't think there is a fresh look. I think the only solution is to bite the bullet. At least that is what I always did so many years, and what is inherent to the profession.

--
Sybrand Bakker, Senior Oracle DBA