I don't know the answer for sure, but can hazard a guess. :-)
65535 is typically the maximum number of bytes that can be written with
a single write() system call. If you use a shorter record length,
you'll execute multiple write()'s for each 64K of data, which involves
multiple trips through kernel land. If you use larger values, you're
not buying anything unless it's a multiple of 65535; i.e. if you specify
65536 you'll be back to 2 writes per chunk. Specifying 2x65535 will
require the same two writes, and gets 65534 more bytes transferred than
the previous example!
It's a very small incremental time, but over the course of a 20G export
all those round trips between kernel and user space can really add
up....
--
Rich Holland (913) 645-1950 SAP Technical Consultant
print unpack("u","92G5S\=\"!A;F]T:&5R(\'!E<FP\@:&%C:V5R\"[EMAIL PROTECTED]");
-----Original Message-----
Lisa
Sent: Friday, May 23, 2003 10:25 AM
To: Multiple recipients of list ORACLE-L
Steve,
Why?
Lisa
-----Original Message-----
Sent: Thursday, May 22, 2003 9:17 PM
To: Multiple recipients of list ORACLE-L
I'm still catching up so somebody may have added to this, but adding
recordlength=65535 with the direct=y will improve it even more.
----- Original Message -----
To: Multiple recipients of list ORACLE-L
Sent: Thursday, May 22, 2003 8:26 AM
I ran across an export that was taking 9 1/2 to 10 hours to complete
(the resulting dmp
file was about 7GB compressed). I added DIRECT=Y and it now takes 3 1/2
hours. My
question is: What are the reasons that someone would choose not to use
DIRECT=Y?
This is an 8.1.5.0.0 database running on a Solaris box; I would hate to
have just removed a
work around for some 8.1.5.0.0 bug! I have found comments in some
scripts here, but
they all seem to be in my handwriting!!
Kurt [EMAIL PROTECTED]
A ran a diff on the log files after the change. Here is the beginning
(just what I expected).....
23c23,24
< . about to export SYSTEM's tables via Conventional Path ...
---
> . about to export SYSTEM's tables via Direct Path ...
> EXP-00067: Table DEF$_AQCALL will be exported in conventional path.
24a26
> EXP-00067: Table DEF$_AQERROR will be exported in conventional path.
29a32
> EXP-00067: Table DEF$_LOB will be exported in conventional path.
33a37
> EXP-00067: Table DEF$_TEMP$LOB will be exported in conventional path.
127c131
< . about to export OUTLN's tables via Conventional Path ...
---
> . about to export OUTLN's tables via Direct Path ...
130,136c134,140
< . about to export DBSNMP's tables via Conventional Path ...
< . about to export OPS$ORACLE's tables via Conventional Path ...
< . about to export CW30_AUDITOR97's tables via Conventional Path ...
< . about to export CW30_LAC_MANUAL's tables via Conventional Path ...
< . about to export DISPUTES2's tables via Conventional Path ...
< . about to export DISPUTES3's tables via Conventional Path ...
< . about to export BANK's tables via Conventional Path ...
---
> . about to export DBSNMP's tables via Direct Path ...
> . about to export OPS$ORACLE's tables via Direct Path ...
> . about to export CW30_AUDITOR97's tables via Direct Path ...
> . about to export CW30_LAC_MANUAL's tables via Direct Path ...
> . about to export DISPUTES2's tables via Direct Path ...
> . about to export DISPUTES3's tables via Direct Path ...
> . about to export BANK's tables via Direct Path ...
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Rich Holland
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
