Re: conventional path export with direct=y

"joel garry" <joel-garry_at_home.com> wrote in message news:1167633898.882485.325140_at_h40g2000cwb.googlegroups.com...
>
> Gerry Sinkiewicz wrote:
>> "Frank van Bortel" <frank.van.bortel_at_gmail.com> wrote in message
>> news:en8067$gho$1_at_news5.zwoll1.ov.home.nl...
>> > joel garry schreef:
>> > > This one is causing hair loss.
>> > >
>> > > hp-ux 11.11, oracle 9.2.0.6
>> > >
>> > > I have a script that has been running for a couple of years now with
>> > > a
>> > > series of direct path exports, no problems. I recently created a new
>> > > schema that is a subset and ETL of an existing schema, through a
>> > > series
>> > > of imports and SQL modifications. The application that uses these
>> > > schemata is a bit picky about its data, and doesn't seem to have a
>> > > problem with any of the schemata.
>> > >
>> > > The exp commands in the script are of the form (each on one line):
>> > >
>> > > exp abcdef/xyz DIRECT=Y compress=N recordlength=65535
>> > > file=/oradata/exports/abcdef.exp log=/oradata/exports/abcdef.log
>> > >
>> > > The result of this is an export with only about a quarter of the
>> > > tables, and none of the other objects like views, stored procedures,
>> > > triggers, etc. It just lists the tables that it exports, then says
>> > > Export terminated successfully without warnings. It also says it is
>> > > using conventional path!
>> >
>> > I know, not all tables can be exported with direct=y (LOBs mainly);
>> > exp will automatically switch to conventional export (and note that
>> > in the log). Also, NLS_LANG should be set
>> >
>> (http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:46622033
>> 5026)
>> > but have never seen failure to do so export only a quarter of
>> > the tables.
>> > However, I never have used recordlength.
>> > --
>> > Regards,
>> > Frank van Bortel
>> >
>> > Top-posting is one way to shut me up...
>>
>> Try adding full=y explicitly and as already said NLS_LANG is important.
>> LOBS/CLOBS do cause a switch to conventional but only on those objects
>> with
>> LOBs etc.
>> Are you exporting under an id with the proper privs (like DBA)?
>
> Well, since it worked for me when I cut and pasted to a regular old
> oracle unix login, I don't think it is a privs or LOB problem (I don't
> think there are LOB's, but it's been a while since I've checked). But
> I'll be checking to be sure it is running as oracle and poke around the
> data types anyways. I'm currently running the live load (which drops
> and recreates the schema), so hopefully that will fix the problem as
> mysteriously as it appeared.
>
> I'm still looking for suggestions, anyways.
>
> Thanks guys, and Happy New Year!
>
> jg
> --
> @home.com is bogus.
> "How about a staggeringly pompous, interminable, uninformed, dishonest
> spasm of intellectual chicken-choking in a major magazine? How 'bout
> that?" - Sarah W. Gaymon
>

You are not reaching a filesystem limit are you ? For example an export dump file bigger than 2GB on a non-large file enabled filesystem ? Or a ulimit setting of the oracle software owner ?

Matthias Received on Mon Jan 01 2007 - 09:31:52 CST