I have been following this thread for a couple of days and I would like to add a thought and ask a couple of questions.
My guess is that the performance problems described here originate with RDBMS application development and implementation more than they might with satcom limitations.
Data locking is a tricky mechanism for interactively managing database application performance. DBA's and system administrators are constantly fighting about application integrity versus performance. To DBA's it is a security and integrity issue, to sysadmins it is a traffic and end-user performance issue. My experience has been that locking manipulation might be a temporary "fix" to certain bottlenecks, but it is not a resolute solution to an applications performance problems. If an application is designed to use a particular level of locking, then it could cause either performance or integrity problems irregardless of the RDBMS that you are using.
My questions:
Has this locking issue been discovered as the primary source of performance problems?
Has anyone developed an implementation template for these distributed satcom applications? If not, I might take a look at it myself.
Who is working on input to this problem from the distribution/replication/normalization side? If not, perhaps someone could feed me a few more details.
Has anyone figured out how to make the 24 hour day longer?
Thanks.
Joe D. Rhemann
North American Company LLC
http://www.north-american.com
mailto://[email protected]
-----Original Message-----
From: Curtis Villamizar [SMTP:[email protected]]
Sent: Monday, November 17, 1997 11:58 AM
To: Ashok Rao
Cc: '[email protected]'
Subject: Re: Problems with Oracle Database applications over satellite
In message <[email protected]>, Ashok Rao writes:
> I've heard that Oracle Database applications have "problems" when they are ru
> n over satellite
> links. Does anyone have any more information to offer on this ?
>
> Thanks
>
> Ashok Rao
> Senior Scientist
> Network Technology
> COMSAT Labs
> [email protected]
There is a lot of control available over the granularity of locking.
You can choose a very fine granularity, making very small operations
atomic and locking out others for a minimal time. This works fine on
a LAN but is very slow over a WAN, not just a satellite link. This is
true of any of the major RDBMS. (It is true of any RDBMS but the not
so majors tend not to have the level of control). The alternate is to
make larger operations atomic, locking as much as possible, doing as
much work as possible in a single transaction, and then unlocking.
This can be slower on a LAN with many stations competing for access to
the database (but often isn't) and is generally *much* faster on a
WAN. Just don't lock and wait for user input.
We saw this sort of problem with customers using another major RDBMS
and they blamed poor performance on "the net" and/or the RDBMS when it
didn't perform well over a very low loss 20 msec RTT path as it did on
the benchtop. Just imagine what more than 500 msec RTT would do to
such an application. Changing the granularity of locking operations
in the application solved the problem for this particulr application.
Curtis
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:33 EST