[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:DEC Rdb against the World
Moderator:HERON::GODFRIND
Created:Fri Jun 12 1987
Last Modified:Thu Feb 23 1995
Last Successful Update:Fri Jun 06 1997
Number of topics:1348
Total number of notes:5438

924.0. "More V6.2 Propaganda" by CLO::MOLLEY () Wed May 01 1991 20:45

    Just finished reading an article on ORACLE's Parallel Server V6.2.  In
    this particular article, they state that the "VMS Distributed Lock
    Manager is not designed for the workload of DBMS transaction
    concurrency" and "to provide high performance and scalability, a DBMS
    must minimize its use of the VMS DLM".
    
    I read a note by Vicky Farrel (DEC) that addressed some of the V6.2
    (mis)statements, but nothing regarding the Distributed Lock Manager. 
    Any technical rebuttals out there?
    
    Regards,
    Nik
    
    
T.RTitleUserPersonal
Name
DateLines
924.1ANITA::KELLEYWho is Zaphod BeeblebroxThu May 02 1991 01:2315
Well, IMPO, I agree that the DLM is not designed for high transaction 
throughput.  However, it is designed for high availability.  This is based on
the fact, that you get less tps from cluster in terms of percentage, then you
do from a single node.  Why do you think that our TPC-* tests are run with 
partitions of the database all being accessed from a single node?
Also, why do you think that we spend so much effort in getting the numbers of 
locks down.  It is not because lock mgmt is so fast.

Now, there certainly can be ways to make the DLM even slower.  my guess is that
O could not figure out how to optimze.  Or maybe they figured that if they
built it a different way and only use the DLM for certain things, that they 
would have something to tell the press like DEC stuff is too slow, that is why
rdb is slow and anyone else who uses it is slow.

chuck
924.2Machiavelli, the resident's guruMJBOOT::WEINBROMJack of all trades-Master of noneFri May 03 1991 23:3531
    FWIW, I think that Oracle's marketing only supports their (probable) goals.
     
    If O had used Digital's Distributed Lock Manager, then they would be
    implicitly condoning it and they would ruin one of their marketing
    strategies against Rdb.  (i.e. Customer to O: If DLM is so bad, then
    why are you using it?)  I know that they use DLM for some things, but
    they seem to denigrate it to a minor role.
    
    In addition, the VAX Distributed Lock Manager is not portable.  If O
    creates their own "DLM", then they can use it on other platforms.  If
    you accept that logic, then given that they've gone to all of the
    trouble of creating their own DLM, why would they then admit that
    Digital's is any good?  Once again, if they did admit that it was OK,
    then they would be implicitly admitting that Rdb (based on LM and by
    extension DLM) must be OK.  Oracle is certainly not known for inept
    marketing.
    
    BTW, when I took my VAXcluster Distributed Lock Manager course
    (admittedly, 5 years ago) there was a distinction made between local
    locks and distributed locks.  If a resource was local, then so were its
    locks.  If a resource was distributed, then so were its locals.  At the
    time, there was an order of magnitude difference in performance between
    a local lock (contained within 1 CPU) and a distributed lock (which had
    to travel across the CI which is slow compared to memory.)
    
    I would assume that Oracle would have the same problems and issues to
    solve as we did in designing a DLM and so I can't believe that their
    DLM's performance would be better than ours.  After all, we've had a
    few years to refine the design. Nonetheless, the goal of both database
    designs has to be to reduce the number of remote locks.  (The CI is the
    same speed for both O and DEC, assuming that they use the CI.)