Conference ulysse::rdb_vms_competition

    There is another approach to maintaining indices that doesn't hold
    locks on index nodes for the duration of a transaction.  RMS and
    Rdb/ELN use this approach; I would expect DB2 to use it as well.
    
    There are three features you might like to get all at once:
      1	- update index nodes without holding locks for transaction duration
      2	- support snapshot readers with no locks at all
      3	- allow queries to use data in index as a trustworthy substitute
    	  for data in records (Rdb's "index-only retrieval").
    
    It doesn't seem possible to get all of these benefits.  Rdb/VMS gets
    #2 and #3; Rdb/ELN gets #1 and #2.

    
    Yes, it's a lousy test if the choice of data causes a problem that
    would not be seen in normal system operation. Was hash indexing
    considered? This would have prevented the problem.
    
    Bill, .1 seems to me to imply that...
>      3	- allow queries to use data in index as a trustworthy substitute
>    	  for data in records (Rdb's "index-only retrieval").
    doesn't lock the index nodes it reads. Not true, surely?
    
    	Andrew.
    
    

re: .0

i was asked to talk about rdb to a customer here who was considering switching
over a series of applications; i was asked by sales to 'shoot them down';
what i did was to show them the competetive fud oracle had been delivering,
addressed them, and then made the statement that i'd prefer to address my product
rather than waste a lot of time countering such hogwash.

throughout my talk i made references to oracle defficiencies (cluster support,
smp, large db support); what happened as a result was that the customer created
a list of question for oracle to answer in return.  oracle said that digital had
'done them wrong' and that they would meet with us to 'get the real poop that
was said' and follow with their replies.

i was told of this follow up meeting to which i requested the customer be
present to get a first hand view and to stop this negative sell tactic to which
oracle refused (i told sales however, to make this known to the customer).

the meeting turned out to be an oracle marketing brain dump on how v6 fixes
everying thing and they mentioned the lock manager problem 'we have and that 
we're trying to address'. they also mentioned how they have been working with
us in identifying this problem (lock manager performance tops off at some
undefined rate, configuration...) i asked the individual if he knew he was
talking about and he said yes, and that i could use his name to verify such
info with rdb development;

what i also was told point blank was that v6 currently is single instance
(only 1 copy) per cluster, partly due to this, but that they had it running -
they we just not happy with the performance. they also mentioned that on smp
systems, the lock manager they've devised works, scales, is more efficient
that ours.

i had about all i could stomach at this point and asked them not to insult me
with their arrogance and ignorance, that if they felt as they spoke behind 
closed doors that they should be as confident in front of a customer. they
balked.

for the record here's the attendies, Neil is the person who said he had all the
inside poop and would be willing to meet to 'bring ME up to date' at my
convenience.

folks from oracle:

	frank harvey
	district manager (PA)
	215.768.0944

	james w. spivey jr.
	sales manager (NJ)
	201.906.4501

	victoria bliss
	national account manager (MA)
	617.862.7339

	neil anderson
	senior technical support manager (MA)
	617.862.7339

talk about nerve!

/los

�< Note 508.0 by MEO78B::SHERRATT >
�    in the test data.  Where they went wrong was to use employee numbers
�    1 to 30.  The load test failed and Rally got the blame.
 
    Richard, in case you didn't get the time to check the RALLY
    application:
    
    	o	Ensure that the DSD for the relation (I assume that
		it is a single relation update) has the attribute 
    		"Lock records at:" defined as UPDATE.
    
    	o	On the Form/Report's   "Edit a data group"
    		definition form, select option 8 and make the attribute
    		"Commit when leaving record" defined as  YES.
    
    Without these set, the record locking for updaters will happen as
    soon as the user moves off the first changed field and will continue
    until the user exits the form/report!.  This is a function
    of RALLY and can (and has been known to) cause user problems.
    
    Cheers, Martin

Re: .0

>>    Have ORACLE and IBM invented some form of magic, or is this just
>>    the usual ignorance and bias showing through?  A customer is being
>>    told that they have a better locking scheme than Rdb.

Remember, Rdb gives the customer the CHOICE to choose a number of parameters
and other items in order to control lock contention.  Other database vendors
(including Oracle, Ingres, and DB2) offer no such choice.  Would the customer 
think Oracle's locking is better even though it increases cpu utilization by 
20-40 % ?  I would make them define what is "better" BUT ONLY after listening
to a detail explanation AND performance test of Rdb.
    
>>    I am now hearing stories from the customer about Rdb having a locking
>>    problem.  The person who chose the test data is a consultant/contractor
>>    to the customer and has little Rdb experience, but is reputed to
>>    have 'lots' of ORACLE and DB/2 experience.  She is apparently saying
>>    that ORACLE and DB/2 would not have given the same results as Rdb.

Hey, make 'em prove it is they're so darn smart ! 

Some other things you can try include:

a. hash index on the table (be sure to use large storage area and let
	Rdb tell you the placement of the keys before you load the
	data)
b. partition the table to 30 storage areas which would cause the indexes 
	to be partitioned as well.  (in other words, play hard ball)
d. reduce size of buffers in Rdb to avoid extra dio when writing or updateing
	records on the same pages from two or more processes.


>>    To me, a project manager/consultant/information engineer rather
>>    that Rdb specialist, that sounds patently absurd.  But am I missing
>>    something?  Have ORACLE and IBM got a better way of adding records
>>    to an indexed table?  Any help most welcome.

No Oracle and IBM have not got a better way.  I always try to position the 
customer that relational databases have two primary problems:  lock contention
and i/o.  Everyone does both differently.  Given that, what the customer needss
without creating an imbalanced system in terms of cpu, memory, and i/o 
performance.  Rdb has more choices for monitoring AND tuning than either Oracle 
or DB2.  

You should also bring up the fact that a skilled consultant can make anything 
look anyway they want and some very objective and measureable metrics would be 
welcome by Digital.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
re: .3     

Yep, those guys at Oracle are real rectimoids !

>> what i also was told point blank was that v6 currently is single instance
>> (only 1 copy) per cluster, partly due to this, but that they had it running -
>> they we just not happy with the performance. 

It is true that V6 only allows one instance ANYWHERE to access a database.
ANYWHERE could be a VAXcluster OR the same node.  Oracle has lots of "things" 
running and lots of "deals" cooking.  Maybe that's why they can't get anything 
fixed.

>> they also mentioned that on smp systems, the lock manager they've devised
>> works, scales, is more efficient that ours. 

The lock manager they refer to is the row level lock manager that is included 
with the V6/TPO product.  Read my lips on this one... they do nothing special 
on a SMP machine in terms of locking.  My customer has an 8840, 6000-460, and 
8550 and ALL use the same distribution for creating and linking the Oracle
kernel.  Further, tests run with my customer indicate Oracle is far from
the perfect scaling due to the write bottle neck of their architecture.

>> for the record here's the attendies, Neil is the person who said he had all the
>> inside poop and would be willing to meet to 'bring ME up to date' at my
>> convenience.

I believe Neil's last name is Mendelson not Anderson.  

Why don't you ask Neil about message ORA-1555 (Rollback segment not old enough) 
which causes a read-only transaction to fail when trying to deliver degree 3
consistency ?
    

    Thanks for all the useful input.
    
    Re .4, Yep, the thing was set up as you suggested.
    
    Re .5?  They can't use a hashed index because something like 90
    to 95% of the transactions to hit the relation are trying to read
    a range of records.  Pity.
    
    Richard