T.R | Title | User | Personal Name | Date | Lines |
---|
931.1 | | UKEDU::SMITHB | Bazzoo� | Wed May 22 1991 10:02 | 10 |
| >
> we're down to one performance claim: That DLM and Row Level Locking
> are not used by Digital Rdb sites due to the performance hit.
>
Does this statement suggest that Oracle claims that Rdb does not
use DLM and row locking?
Interesting, it's a bit hard to turn it off!
Barry
|
931.2 | We wouldn't want to confuse Oracle with the truth! | KBEAR::STENOISH | DBS West | Wed May 22 1991 17:50 | 22 |
| To restate .1, it is impossible to turn-off row-level locking.
However, Oracle might be referring to adjustable lock granularity. You
CAN disable adjustable lock granularity. (When enabled, adjustable
lock granularity tries locking chunks of pages instead of individual
pages in an attempt to reduce the number of locks required. If
multiple Rdb users contend for the same chunks of pages, then each Rdb
code automatically locks a smaller chunk of pages (it only locks chunks
containing the pages it needs). If there is STILL contention for pages
in a chunk, then the Rdb code in the process locks individual pages
that are needed. If multiple processes frequently contend for pages
that fall into the same chunks, then some time is spent locking smaller
chunks. If adjustable lock granularity is disabled, then Rdb locks
only pages and doesn't need to spend time switching between locks for
smaller chunks of pages. Whether adjustable lock granularity should be
disabled depends entirely on the application; some perform better with
it on, others don't. Whether it is enabled or not, Row level locking
is ALWAYS done. (If you need to learn more, the guide to maintenance
and performance discusses adjustable lock granularity).
Jim
|
931.3 | | HGOVC::DEANGELIS | Momuntai | Thu May 23 1991 05:47 | 14 |
| � <<< Note 931.1 by UKEDU::SMITHB "Bazzoo�" >>>
� Does this statement suggest that Oracle claims that Rdb does not
� use DLM and row locking?
�
� Interesting, it's a bit hard to turn it off!
Hi Barry,
I guess a VAXcluster site can choose to 'turn off' DLM by simply accessing
the database from 1 node. In fact I know of some customers who do this...
But to generalise to all Rdb sites is another example of Oracle 'marketing'.
John.
|
931.4 | | UKEDU::SMITHB | Bazzoo� | Thu May 23 1991 12:54 | 9 |
|
Hi,
yes, it just seems real crazy that they can say these things and
get away with it. Oracle are excellent salesmen.....maybe DEC
should by some of them ;-)
Barry.
|
931.5 | How low can you discount? | SHALOT::DUNCAN | Joe - CIS/EIC/DCC Groupworks Team | Mon Jun 24 1991 16:03 | 3 |
| No thanks. We have enough trouble with margins as it is! ;-)
Joe Duncan @ OPA
|
931.6 | You pay for your Oracle concurrency! | NOVA::NOVA::R_ANDERSON | My timing is Digital. | Tue Sep 03 1991 16:28 | 16 |
| From my limited experience with Oracle, you have to PAY extra to get
row-locking capabilities (I think this option is part of the transaction-
processing package???). Anyways, the default locking is page-based, which IS
more efficient for distributed lock managers, but provides extremely degraded
retrieval concurrency. Again, what type of locking is best depends on the
application.
With Rdb, you get page-level locking until concurrency conflicts arise, at which
time you automatically switch into row-level-locking mode. I think someone
explained adjustable-locking-granularity earlier in this topic.
We are looking into disabling row-locking in Rdb (it's a long ways off, so don't
start offering it to customers :-) for those types of applications that don't
need high-retrieval-concurrency.
FYI.
Rick
|