RE: "DB Link are Inherently Slow" -- True or False?

Slow is a relative term. If the alternate transfer method is an export, FTP, and import then even if the insert select across the link was slower than the import step it is likely to be faster than the combined exp/imp or exp/FTP/imp process.  

The real question is how important is the transfer speed? How often will the transfer need to be performed? Will the receiving object need to be re-created, cleared out prior to the task or will the data need to be merged? If the data is merged what are the chances of getting an error?  

The answers to these questions should allow you to choose the best solution for your needs.    

• Mark D Powell -- Phone (313) 592-5148

  ---

        From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Howard Latham

	Sent: Tuesday, July 15, 2008 10:43 AM
	To: david_at_david-aldridge.com
	Cc: Oracle List
	Subject: Re: "DB Link are Inherently Slow" -- True or False?
	
	
	DB Links can be slow -or slow down processing - and for two
reasons -
	1. Network is Slow
	2. Code
	
	Some code is slowed down badly by using a DB Link. I'm not sure
why by some apps really suffer 
	while others don't I think it's to with what is is happening in

        On the OTHER HAND COPY over a DBLINK can be VERY VERY FAST! and therefore one of the best ways for bulk transfer of data.                                             

        2008/7/15 David Aldridge <david_at_david-aldridge.com>:         

I am being persistently told by a DBA that DB links are inherently slow and not suited to bulk transfer of data.  

Does anyone have any experiences to share on the sort of practical MBytes/sec throughput we ought to be getting on a 10GBit network between two databases having no intervening firewalls, routers, or other potentially performance limiting network components? We're seeing 2MBytes/sec using data pump import in network mode with parallelsim of 10 (ie. sourcing data through a db link from another db on a different host) :(

	-- 
	Howard A. Latham
	

--
http://www.freelists.org/webpage/oracle-l