Re: Drawbacks for direct path

"Mark Bole" <makbo_at_pacbell.net> wrote in message news:exovd.33590$zx1.24975_at_newssvr13.news.prodigy.com...
> Goran wrote:
> > "zeb" <spam_at_nowhere.com> wrote in message
> > news:41bdfca9$0$11630$636a15ce_at_news.free.fr...
> >
> >>Hi,
> >>
> >>It seems direct path for export and SQL Loader is always
> >>quicker than conventional path ...
> >>
> >>What are the drawbacks for direct path ?
> >>Why not to use always direct path ?
> >>When it is better to use diret path and
> >>when it is better to use conventional path ?
> >>
> >>Thanks for your lights ...
> >>
> >>Oracle 8i, 9i
> >>HP-UX 11.0 AIX 5L
> >>
> >
> >
> > Direct path export (8i, not sure about other versions, not sure if it's
> > platform specific or generic) behaves very wrong if a table has
> > chained/migrated rows. So wrong that it produces unusable dump. Easy to
> > reproduce...
> >
> > Regards...
> >
>
> It's an old version, but just as a matter of curiousity, do you remember
> what specific imp/exp error(s) indicated that the export file was
> unusable? I supported a system that did daily direct path exports and
> although re-importing them (into another database) was rare, we never
> had any problems. Never checked for presence of chained/migrated rows...
>

We encountered a problem when we couldn't import some archived dumps, no matter what we tried. I don't remember exact import errors reported. Dumps were exported from a 8174 64bit db on HPUX 11.11 using direct path export.
It quite easy to reproduce, all you have to do is create a small table, produce some row chaining (set pctfree=0, insert rows with some null values, update them to non-null values, check if there is row chaining), perform direct export, truncate the table and try to import :)

Regards Received on Mon Dec 13 2004 - 16:37:35 CST