From oracle-l-bounce@freelists.org Mon Feb 14 00:08:35 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j1E68ZnS026560 for ; Mon, 14 Feb 2005 00:08:35 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j1E68Yem026556 for ; Mon, 14 Feb 2005 00:08:35 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CB82171217; Mon, 14 Feb 2005 00:07:26 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18918-04; Mon, 14 Feb 2005 00:07:26 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4F9BE71265; Mon, 14 Feb 2005 00:07:26 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 13 Feb 2005 22:03:00 -0700 Subject: Re: database links and performance From: Tim Gorman To: "Oracle L (E-mail)" Message-ID: In-Reply-To: <003001c50dec$0c985540$3e04050a@johnman> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 16114 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: tim@evdbt.com Precedence: normal Reply-To: tim@evdbt.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on air891.startdedicated.com X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=ham version=2.60 X-Spam-Level: John, > We are considering using database links in Oracle 9i but are concerned about > performance. > > Presumably the network can be a bottleneck when using database links. > > Does anyone have any useful experiences with performance of database links? Well, first a big question in return... What are your alternatives to database links? Shell scripting? File transfer with some kind of "unload" on one side and "load" on the other? Something custom written in C, C++, or Java? You absolutely need transactional controls (i.e. COMMIT and ROLLBACK logic). No "if"s or "but"s about it. Chances are good that many of the alternate solutions under consideration will not support transactions, which is crucial if you want to be certain that the data gets from point "A" to point "B". You don't want the odds to be "good" for reliable transfer -- five 9's (i.e. 99.999%) reliability is unacceptable. You want it airtight 100% reliable and able to be rolled back cleanly in the event of any failure. Just try to implement two-phase commit in a shell script or 3GL program -- I dare ya! :-) It really isn't easy and Oracle mastered this a long time ago. If you have a reliable solution to that question, then to answer your original question, database links perform best with bulk operations using arrays. Row-at-a-time processing, which stinks up PL/SQL performance even without database links, is even stinkier with database links. PL/SQL and SQL provide numerous mechanisms for non-chatty communication over database links, including PL/SQL tables (a.k.a. collections or "arrays"). Also, in general, I find "pulling" data across a database link to perform better than "pushing" data across. That is, "INSERT INTO local-table SELECT ... FROM remote-table" seems to perform better than "INSERT INTO remote-table SELECT ... FROM local-table", but you should test it yourself and not take my word for it. I mention this only to alert you that this could be a consideration for performance. There is no trade-off in reliability. Also, be aware that parallel execution is possible across database links, if you are trying to move truly large volumes of data. Again, pulling seems to work better than pushing, in my experience; your mileage may vary... Upshot: 1. Please don't believe everything you've read and heard. Try it out. 2. Use PL/SQL bulk operations and collections, if appropriate. 3. Reliability is far more important than speed. Hope this helps... -Tim -- http://www.freelists.org/webpage/oracle-l