RE: Poor performance on bulk transfer across db link -- wrapup
- From: David Aldridge <david@xxxxxxxxxxxxxxxxxx>
- To: tanel.poder.003@xxxxxxx, 'Oracle List' <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 16 Nov 2007 04:55:34 -0800 (PST)
Sorry Tanel, missed your post.
This sounds intriguing. I'll have to bounce it off the DBA's and network
people. We're 100% Solaris 64bit here -- I'll have to checkup on the exact
versions. The source db is 9.2 and the target is 10.2.
Now would this affect Oracle Net in particular? If ftp achieves speeds an
order of magnitude faster than Oracle NET does that still indicate that the
buffer sizes are too low?
Tanel Poder <tanel.poder.003@xxxxxxx> wrote:
David,
You may need to alter the TCP send & receive buffer sizes for getting the
throughput out of your network.
If the packet roundtrip time in your LAN is 1ms ( 0.001 sec ) and you want to
achieve 40MB/sec transfer rate then your TCP sent/receive buffers must be at
least 0.001 * 40 MB = 40 kB.
In most OSes I've seen, the default TCP buffer sizes are usually very low (
tcp_xmit_hiwat = 8 kB in solaris for example ).
On which OS and Oracle version are you on? Oracle 10g allows you to specify
RECV_BUF_SIZE and SEND_BUF_SIZE for TCP connections in sqlnet.ora ( subject to
OS level max buffer & tcp window settings ). If not on Oracle 10g, then you
need to use OS specific settings.
http://download-uk.oracle.com/docs/cd/B14117_01/network.101/b10775/performance.htm#i1007572
--
Regards,
Tanel Poder
http://blog.tanelpoder.com
---------------------------------
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of David Aldridge
Sent: Friday, November 09, 2007 00:25
To: Oracle List
Subject: Re: Poor performance on bulk transfer across db link -- wrapup
Thanks to everyone who responded.
We did a bunch of testing on changing SDU, but aren't able to change the MTU
due to the impact on other production systems. Reducing the SDU to match the
MTU produced no performance change. DB Links just seem to be problematic for
performance, maybe due to something in our own environment, but our timeline
doesn't give us the opportunity to investigate further..
We're looking at other solutions -- transportable talespaces, in fact.
Thanks again.
Other related posts:
