| �� He indicated that ORACLE finds the Distributed Lock Manager
�� unacceptable and that ORACLE is creating its own version of the DLM so
�� that ORACLE can run on a cluster.
Does this surprise you ? Of course they find it unacceptable because they can't
get it to perform because Oracle's database ARCHITECTURE HAS NO STRATEGY for
VAXclusters. This is EXACTLY the same message I heard Oracle tell one of my
customers over a year ago !!! Remember that Oracle is one of the best companies
in the world at shifting the blame for THEIR product deficiencies.
Oracle DECIDED long ago to use a large amounts of memory for database cache. As
you probably know, it is (and has always been) the application's responsibility
(in this case Oracle) to sync memory caches from different cpus in a cluster
environment. This is why we invented the DLM and all the DECnet task-to-task
communication mechanisms.
You should be aware that Oracle DID use the DLM in version 5.1.17 and DECIDED
to NOT use the DLM in version 5.1.22. In addition, they DECIDED to NOT support
VAXclusters when they architected their Version 6 product set and left it out
ON PURPOSE in order to get the product to market.
As you can tell, I get really sick and tired of hearing this crap. Hey, tell
them to write their own DLM since they're so damn smart ! There are not US or
foreign laws that says they have to use our DLM !! And oh by the way, tell them
to fix the read consistency problem that V6/TPO customers are having which
causes a read_only transaction to get degree-2 consistency !!!
�� Since we were with a customer, I didn't ask the following questions:
Ouch ... you missed the golden opportunity. You MUST learn to attack Oracle
when they make these negative and very misleading statements about our
technology. Among other things, you should have asked them why Ingres and Rdb
run OK in a cluster along with THOUSANDS of other RMS based applications ?
�� 1) Does that mean that if you install ORACLE on a cluster you will no
�� longer have access to DLM?
Some things in life don't change. Don't let the fact that you're dealing with
Oracle negate what you know about VMS, VAXclusters, and, most of all, common
sense. The DLM is buried deep down inside VMS and the VAXcluster software. If
you have a VAXcluster, you have the DLM. There is absolutely nothing you, I, or
Oracle can do about this. The DLM is goodness.
�� 2) How do you access data on an HSC without DLM?
The DLM has nothing to do with HSC since the DLM is used in ALL clusters (local,
mixed, and CI). You do nothing with the code OR the database. I have a
customer with 8550/8840/6460 cluster running a bunch of Oracle V6 databases.
The databases are not shareable and are local to each specific machine.
�� 3) Can you run other applications accessing the ORACLE database data
�� outside of ORACLE without the DLM?
You cannot access the same Oracle database from two different nodes at the same
time.... period. If you try, data will become corrupted.
�� 4) Can you run other applications not accessing the ORACLE database
�� data on a cluster with the ORACLE proprietary lock manager?
You're all messed-up. First, Oracle has no lock manager for V6. Second,
IF they did, you wouldn't want to use it because it would be poorly engineered
and would most certainly NOT use the CI path in a CI cluster.
�� Has anybody else heard this? I didn't know what to make of it.
This is the same old line I've heard many times. Drink some of that Rambo juice
and ask the following questions of the Oracle person IN FRONT OF THE CUSTOMER:
Q: What EXACTLY is the problem with the DLM ?
Q: Can Digital help Oracle understand how to use the DLM since WE know how
along with Ingres.
Q: When will your super-locker be ready for field test ?
|
| Ther is no reason someone couldn't write their own lock manager that
works across the cluster for their own purposes. It doesn't need to be
'in VMS' and certainly doesn't replace DLM. All it does it coordinate
locking amongst the resources owned by the database manager itself.
I could build a better lock manager for databases than DLM, but the cost
of re-implementing the good aspects of DLM generally outweigh the
benefits. Of course, as Digital engineering groups we can try to
influence the VMS folks to make changes for us. This is not necessarily
an option for ORACLE (not that VMS immediately jumps when a layered
product group asks for something either).
I think the real reason that ORACLE is writing their own DLM is simple:
IT WILL WORK ON OTHER PEOPLE'S HARDWARE. Once ORACLE has their own DLM
they will be able to construct a VAXcluster-like system out of any
processor and disk combination where the disks can be dual ported!!!!!
They are using the excuse that the DLM doesn't work to mask their real intent.
A major drawback of a product-specific lock manager is that it can't
detect deadlocks with other resources that are using the DLM. This is
easily handled by timing out the other lock requests, but it means that
the ORACLE lock manager requests will always be the ones selected to be
killed as a result of a deadlock. The other problem with the
product-specific lock manager is that currently DLM is the fastest
interprocess communications mechanism in a VAXcluster. Thus, the
overhead of a private lock manager should be higher. The biggest
benefit of a private lock manager is that the amount of communications
between processors can be reduced and the relationship between "process"
and "resource" can be changed (it would take too much time to explain
how this could be used, but suffice to say that its critical to building a
VAXcluster-wide global cache).
Basically, ORACLE isn't technically wrong in building their own lock
manager. But, they are being their usual marketing slime-balls by
making negative comments about the VMS DLM AND it remains to be seen if
they can really pull their own lock manager off in a timely and
high-quality fashion. History says they will be late with something
that takes a few versions to reach acceptable quality.
|