And all i do is plug my free website :)
-----Original Message-----
To: Multiple recipients of list ORACLE-L
Sent: 6/22/01 5:47 PM
But Lisa, don't you think Chris posts too much, just like on LazyDBA?
<very evil grin>
-----Original Message-----
Sent: Friday, June 22, 2001 5:27 PM
To: Multiple recipients of list ORACLE-L
Christopher, this is exactly why you should keep posting no matter what
they whiners say.
Thanks for sending this to the list. I learned something today.
Have a great weekend!
Lisa Koivu
Ft. Lauderdale, FL, USA
-----Original Message-----
Sent: Friday, June 22, 2001 4:45 PM
To: Multiple recipients of list ORACLE-L
1) You can expect to see as much as 75% performance gain on
export. There
is just about no performance gain on the import. The reason for this is
it
avoids 3 copies and 2 character conversions when exporting the data.
This is
due to the conversion from column major to row major when bringing in
the
buffers into the buffer cache, then converting back to column major to
handle the select. I would recomend looking at the recordlength
parameter
as it has a good (1-4%) effect on performance initially, but after 32k
it
generally has very little performance gain. During conventional
exports,
recordlength can prove as much as 6% performance gain. Ussually setting
it
to 32k is the best you will see.
One thing to know about exports is conventional exports are cpu
bound where
as direct exports are Io bound. But either will only use a fractional
portion of the cpu/io. Also note, if your using consistent exports it
will
incur locking as well as redo/rollback generation. So time for exports
cannot be 100% accurately consistent.
Another thing is direct exports use as much as 65% less memory
than
conventional and about 35% less cpu. Also direct exports tend to do a
three
fold increase in io throughput over conventional. You can ussually
export a
max export sustained speed of around 5-6% of max i/o.
2) Target, source, and client used to export must be of the
same character
set and you cannot export lobs.
This is perhaps more than you asked for, but hopefully it helps.
"Walking on water and developing software from a specification
are easy if
both are frozen."
Christopher R. Spence
Oracle DBA
Fuelspot
-----Original Message-----
Sent: Friday, June 22, 2001 12:56 PM
To: Multiple recipients of list ORACLE-L
Oracle : 8.0.5
Platform : Sun
Currently we have cron job every night (starting from 11pm) to
do export. I
changed the setting "direct" to "y" two days ago while leaving all other
parameters unchanged, hoping to gain some performance. I am a bit
surprused
to find that it did not. It actually took longer to create dump file
with
less data to export. The whole exp process takes about 2 hours to
finish.
Yes, there could be lots of other unix processes running during that
time.
But I would still expect to see some improvement because we are doing
this
way for quite a while. So my questions are:
1. From your "real" export experience, how much performance
boost did you
see when you set "direct=y"?
2. If "direct=y" improves the performance, why would anyone want
to use
"direct=n"?
Thanks.
Guang
-- here is my orcle dump file's time stamp:
(dmp.1 and dmp.2 are from direct=y,
dmp.3, dmp.4 and dmp.5 are from direct=n).
-rw-rw-r-- 1 mt prog 1042197132 Jun 18 01:05
oracle.dmp.5.gz
-rw-rw-r-- 1 mt prog 1042375633 Jun 19 01:04 oracle.dmp.4.gz
-rw-rw-r-- 1 mt prog 1042556662 Jun 20 00:25 oracle.dmp.3.gz
-rw-rw-r-- 1 mt prog 1034773279 Jun 21 01:17 oracle.dmp.2.gz
-rw-rw-r-- 1 mt prog 1035237986 Jun 22 01:22 oracle.dmp.1.gz
--here is the parameter file:
BUFFER = 64000
COMPRESS = Y
CONSISTENT = N
CONSTRAINTS = Y
DIRECT = Y
FILE = /oracle/exports/oracle.dmp.pipe
#FULL = Y
GRANTS = Y
INDEXES = Y
LOG = /oracle/exports/export.log
ROWS = Y
USERID = xxx/yyy
OWNER = (aaa,bbb)
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
<http://explorer.msn.com>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<http://www.orafaq.com>
--
Author: Guang Mei
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858)
538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<http://www.orafaq.com>
--
Author: Christopher Spence
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858)
538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Christopher Spence
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
