RE: Poor performance on bulk transfer across db link -- wrapup
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <david@xxxxxxxxxxxxxxxxxx>, "'Oracle List'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 9 Nov 2007 17:06:44 -0500
long thread - I'm not sure whether anyone mentioned the alternative of
sqlplus copy. Arraysize and copycommit control the ack nak and avoid
creating a single gigantic transaction. You have to be careful about whether
all the types you have are fully supported, and may sure your session LONG
is set to at least the length of your longest long in a given table being
copied. Since the monolithic transaction size is controlled it is reasonable
to ramp up the number of concurrent sessions running copies to your desired
level of saturation of cpus and network bandwidth. My experience is that
running the copy of from the side you are pulling to works marginally
better, but the last time a copied a *LOT* of data this way was when you
could still time network database transport speeds with an analog
wristwatch.
Regarding other approaches, do not underestimate the speed of sneakernet.
Are your servers within walking distance? Do they have compatible media?
Good luck.
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of David Aldridge
Sent: Thursday, November 08, 2007 11:25 AM
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:
