Bin,
You're absolutely correct that we had mentioned the use of SQL*Plus as a
cheap homegrown SQL*Unloader tool in our book, and I've posted Gary's
unload.sql scripts on my website (http://www.EvDBT.com/library.htm) as
well. But for high-volumes of data, SQL*Plus simply does too much work (it
Tim,
Thank you for your reply.
There are two issues that I cannot use pipe. One is two databases are in two
different isolated network. Second is we need the flat files for archives.
BTW, whenever we
can use PIPE, we can use database link. Is it right?
I understand that SQLPlus is just a
Stephane,
pdqout does give me a real good impression, not only the speed but also the
interface. I can see it uses parallel query. However, I, as a production
DBA, intend to change the application which come from a third party as a
package as small as possible. It takes 4hours to extract data at
Stephane,
pdqout does give me a real good impression, not
only the speed but also the
interface. I can see it uses parallel query.
However, I, as a production
DBA, intend to change the application which come
from a third party as a
package as small as possible. It takes 4hours to
extract data
On Tuesday 23 April 2002 21:53, Bin Wang wrote:
Hi,
Our application uses sqlplus + sqlloader to transfer data between
databases. It takes nearly four hours to unload to data to flat
files(1G), which is far too slow. In the application, the query looks
like the following. All those 3,4,5
Hey Jared,
I got quite a few folks waiting for your book now. I am really pushing
Perl at the office:-) When is the scheduled release again?
-Original Message-
Sent: Thursday, April 25, 2002 12:03 AM
To: Multiple recipients of list ORACLE-L
On Tuesday 23 April 2002 21:53, Bin Wang
: Is sqlplus too slow to unload data?
Hey Jared,
I got quite a few folks waiting for your book now. I am really pushing
Perl at the office:-) When is the scheduled release again?
-Original Message-
Sent: Thursday, April 25, 2002 12:03 AM
To: Multiple recipients of list ORACLE-L
On Tuesday
Bruce,
SQLPlus:
set pages 0;
set lines 1;
set termout off;
set trimspool on;
set trimout on;
set echo off;
set feedback off;
set verify off;
set recsep off;
set arraysize 2000;
PDQOut is 3rd party product I test. I also test the PL/SQL from Thomas Kyte's book. I
call it from sqlplus, and
As somebody who has insider's knowledge of pdqout and a decent understanding of exp
and SQL*Plus, I think that you must have a good number of numbers and dates in your
data. Both types (as opposed to strings) require conversion. Which is why exp, which
dumps bytes 'as is', can be so fast -
If you have PRO*C and a c-compiler, you can follow this link (you need both
lines) to download a basic sqlunldr tool. It is almost as fast as exp.
http://asktom.oracle.com/pls/ask/f?p=4950:8:646297::NO::F4950_P8_DISPLAYID,F
4950_P8_CRITERIA:459020243348,%7BSQLDA%7D
Caver
-Original
It's SQL*Plus. Love it to pieces, but it just dawdles when used as an
unloader. It must spend a tremendous amount of processing just formatting
or something...
Never bother blaming the network or Net8 unless you are just trying to get
someone off your back to delay for time. DBAs will say it
Hi,
Our application uses sqlplus + sqlloader to transfer data between
databases. It takes nearly four hours to unload to data to flat
files(1G), which is far too slow. In the application, the query looks
like the following. All those 3,4,5 are for sqlldr format.
select ' ' ||
'4' || replace(
Bin,
Have you tried setting term off in your sqlplus session - what effect does this have?
I would guess that the Pro*C program also uses Net8 so the problem would be in SQLPlus.
Which 3rd party product did you try?
Have you tested PDQOut from http://www.oriole.com - this is written in OCI.
13 matches
Mail list logo
