Re: Performance over the web - Querying Oracle DB server over WAN

From: Robert Klemme <shortcutter_at_googlemail.com>
Date: Sun, 21 Aug 2011 13:00:56 +0200
Message-ID: <9bc6r8F33mU1_at_mid.individual.net>



On 21.08.2011 11:00, Ilan Shiber wrote:
> We have several applications which access the oracle DB and issue
> queries. Usually these applications are very close to the database
> (over LAN). However some of them are going off-shore and will
> communicate with the DB server over WAN. Are there any commercial
> products that accelerate the communication with the Oracle DB?

Depending on access patterns Oracle's Times Ten might help:

http://www.oracle.com/us/products/database/in-memory-database-cache-066510.html

But: changing from LAN to WAN access is an architectural change. The most appropriate solution to this would be to change application architecture in a way to honor this fact. This typically means, breaking up parts of your application into a client and server component which communicate with a protocol that is adjusted to the nature of WAN communication:

  • higher latency
  • lower throughput
  • insecurity

You might also need to introduce local caching of data which rarely changes. Since you have knowledge of the application data's nature, you can come up with more efficient caching schemes than any generalized tool (e.g. the database).

Note: I do not have in depth knowledge of Oracle NET's protocol. Encryption for traffic is possible and it may be that it works well with larger latency, although I doubt it.

> (Of course replicating the database is an option, but I would want to
> move away from it).

Whether replication is an option mainly depends on DB access patterns: if the database is updated infrequently but read accessed frequently then replication might be an option. Otherwise you might end up with much higher data traffic than necessary for the remote application to work.

Kind regards

        robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Received on Sun Aug 21 2011 - 06:00:56 CDT

Original text of this message