Conference ulysse::rdb_vms_competition

Who is Frank McCabe and why is he making a statement like:

"Oracle has again demonstrated performance leadership on Digital's
hardware," said Frank McCabe, vice president of Digital's Global Information
Systems.

What is the point of this statement?  Is Frank simply and impartial observer who
happens to be an expert in database systems and TP benchmarks?

Sorry for the flame but I can't control myself this time.

Steve Farlow @STO

.1> Who is Frank McCabe and why is he making a statement like:
    
    All Marketing in Digital is divided into three parts:
    	Frank McCabe, GIS (Global Info Sys) [aka, the big stuff]
    	Charlie Christ, SME (Small and Medium enterprises) [aka,
    				departmental computing, small business)
    	BJ, Industry Marketing [the IBUs you know and love].
    
    These three Marketing VPs are peers of Bob Palmer, David Stone, and a
    few others.  They report jointly to Ken and Jack Smith.
    
    In Frank's case, Bill Demmer (all VAX, Alpha, and VMS Engineering)
    reports to him. 
    
    That's who Frank McCabe is.
    
    As to why he said it, I assume that Oracle asked Digital for a nice
    quote from somebody important in praise of this glorious achievement,
    and voila! But I can only speculate.
    
    S

    V7 runs even faster on a slide projector!

Just like you I would like to see better performance figures for Rdb/VMS than
the ones from Oracle. We don't do much TPC-B testing though, just once to
prove Oracle's measurement of 60 TPS for Rdb/VMS was inaccurate. We measured
190 TPS or so, well above Oracle's performance of 153.

So, if Oracle has managed to achieve better figures with V7 than we with
Rdb/VMS, we have to live with that and try to improve our products even more.

Henny Olthof, TP-DB The Netherlands

============================================================================
PROFILE:    System Dev. Tools (sponsored by InfoMktg)
FOR:        Oracle (to FirstTools)
ISSUE DATE: July 14, 1992
SUBJECT:    Oracle Says Version 7 Breaks Records
SOURCE:     Newsbytes via First! of INDIVIDUAL, Inc.
STORY DATE: July 13, 1992
----------------------------------------------------------------------------
                    ORACLE SAYS VERSION 7 BREAKS RECORDS

  WANCHAI, HONG KONG, 1992 JUL 13 (NB) via First! -- Oracle Corporation
claims that Oracle 7, the latest version of its relational database, has set
new benchmark records on every platform on which it has been tested.

  Running on a host of platforms including Sequent, Hewlett-Packard, Sun
Microsystems, Digital Equipment and Data General, Oracle 7 not only logged
the highest TPC-A and TPC-B performance scores ever, it was also the fastest
ever in terms of TPC-A throughput, the second fastest in TPC-B throughput
and logged the best TPC-B cost/performance benchmark ever, according to
Oracle.

  "These record breaking benchmark numbers firmly establish Oracle as the
industry price/performance leader," proclaimed Henry Chan, sales director of
Oracle Systems Hong Kong Ltd. "Oracle 7 has set certified performance
records on every type of computer it has been tested on to date."

  Chan added that Oracle 7's scalable high performance, combined with high
reliability, made a client-server configuration the first real alternative
to mainframes for the current generation of mission critical applications.

  Running on a Sequent Symmetry 2000/750 system, Oracle 7 set a blistering
605.27 tpsA and established a new low cost/tpsA of US$10,919 for this level
of performance. This represents a saving of 35 percent per tpsA compared to
the last Oracle/Sequent cost/tpsA figure and is nearly triple the previous
mark of 214 tpsA released in January (1992).

  The Hewlett-Packard/Oracle 7 combination scored the second fastest TPC-A
benchmark of all time, Oracle says. Running on an HP 9000/890 system, Oracle
7 recorded 578 tpsA at a cost/tpsA of $11,894. This is compared to an HP
9000/870S/4 running the same TPC-A benchmark under Informix-Online V4.1,
which logged 173.2 tpsA for a cost/tpsA of US$15,868.

  Oracle 7 also set new records in TPC-B tests. It logged the best ever
cost/performance TPC-B benchmark of 100.85 tpsB for a cost/tpsB of US$1,588,
running on a DG AViiON 4625 system from Data General, Oracle claims.

  Other breakthroughs in TPC-B performance included Digital Equipment's VAX
platforms. Oracle 7 scored 315 tpsB for a cost/tpsB of US$4,725 on a VMS
6000-560 and 560.87 tpsB for a cost/tpsB of US$2,970 running on a VMS 6000-
660.

  "These benchmarks reflect the true flexibility and sophistication of the
new Oracle 7 database. It can reduce resource utilization by as much as 30
percent and support more users with fewer resources on low-end platforms and
hundreds or even thousands of users on high-end platforms," said Mr Chan.
"In the future, Oracle 7's scalable performance, coupled with very low cost
will allow emerging applications to access very large databases containing
image, text, voice and other data in true multimedia applications."

  (Brett Cameron/19920712/Press Contact:Karen Wan, Oracle, tel:+852-824
0118; HK time is GMT + 8)

  [07-13-92 at 15:00 EDT, Copyright 1992, Newsbytes News Network., File:
n0713161.217]

----------------------------------------------------------------------------
Entire contents (C) 1992 by INDIVIDUAL, Inc., 84 Sherman Street, Cambridge,
MA 02140 - Phone: 617-354-2230, FAX: 617-864-4066.  Unauthorized electronic
redistribution without prior written approval of INDIVIDUAL, Inc. is
prohibited by law.  Any authorized copy must carry in full the copyright
notice of the information source, if any, of First! and of INDIVIDUAL, Inc.
==============[The End - First! (TM) - Your Smart News Agent]===============

    anybody know what the TPC-A numbers are for the VAX machines?  
    I didn't notice any in the news release.

�                     <<< Note 1168.6 by COOKIE::STENOISH >>>

�    anybody know what the TPC-A numbers are for the VAX machines?  
�    I didn't notice any in the news release.

You probably didn't notice any in the press release since they haven't 
released any yet :)

I checked the latest list from TPC and they've got ORACLE7 TPC-B figures on 
VAXes but not TPC-A figures (Oracle has A figures for about 4 vendors 
listed, as I recall, HP, Sun, Unisys, Sequent, (might have missed one 
here)).

For those of you wondering how ORACLE achieved this performance:

ORACLE created a new transaction type started by
BEGIN_DISCRETE_TRANSACTION.  These transactions have severe restrictions
that appear to make them useless for all but very short special case
transactions (ala DebitCredit).  To quote a piece of the HP and Sequent
TPC-A reports for ORACLE V7:

"The performance of the TPC-A transaction was improved by using the
BEGIN_DISCRETE_TRANSACTION procedure.  The procedure streamlines
transaction processing so that short, non-distributed transactions can
execute more rapidly.

This streamlined transaction processing is useful for 
transactions that:

- modify only a few database blocks
- change each database block only once per transaction
- do not modify data likely to be requested bny long-running queries"

In other words, they implemented a new feature specifically for the
purpose of generating TPC numbers, with extremely limited usefullness in
actual customer applications.

Question:  Is winning the TPC-A/B performance race sufficiently important
to our Rdb sales/marketing efforts to justify adding a similar
special-purpose "fast path" to Rdb?  Would it be better to come close to,
but not beat ORACLE, if our numbers were the result of standard and
generally useful features (versus beating them through the use of
"benchmark only" features such as their "discrete transactions?)

    Why couldn't they have been honest and at least called the procedure
    BEGIN_DEBIT_CREDIT_TRANSACTION?
    
    Of course, this will all be lost on Oracle apologists...

	Re. .7

	> (Oracle has A figures for about 4 vendors 
	> listed, as I recall, HP, Sun, Unisys, Sequent, 

	Actually, it's only 3 vendors. Note that the Unisys result is the
	same as the Sequent result, since Unisys simply re-sells the 
	Sequent line as its own. Under the TPC rules, the re-selling vendor
	can use the actual vendor's TPC result as its own (the prices will
	vary as the vendors will have different system prices, different
	maintenance prices, and terminal prices).

	Also look for Bull to re-publish many IBM (RISC) TPC tests as its own
	soon.

Jim Stenoish was right in saying they just should have called it
BEGIN_DEBIT_CREDIT_TRANSACTION.  The restrictions are so severe that
discrete transactions appear useless for just about anything else.  I've
been thinking of adding a similar concept to Rdb...a special case
transaction type for short-running update transactions...but never would
I add something with restrictions like:

- "Because discrete transactions cannot see their own changes, a discrete
transaction cannot perform inserts or updates on both tables involved in
a referential integrity constraint."

In other words, you can't do things like add a department and add an
employee to that department in the same transaction.

- "Because a discrete transaction cannot see its own chjanges nor modify
the same block twice, a SELECT FOR UPDATE statement and the subsequent
update statement is not supported for discrete transactions."

In other words, there is no way to prevent buried updates when using
discrete transactions (except to take out an exclusive table lock).  The
application can read some data and update it, but in between those two
events another transaction can modify the data.  The other transaction's
update will then be lost when the discrete transaction performs its
update.

ORACLE has broken their entire transaction model, which they usually sell
hard as an alternative to system provided Isolation Level 3 (aka Degree
3) transactions, in providing this feature.  The next point re-emphasizes
this:

- "Because no undo information is generated for discrete transactions, a
discrete transaction that starts and completes during a long query can
cause the query to receive the "snapshot too old" error if the query
requests data changed by the discrete transaction."

In other words, you can't use the SELECT statement (the primary statement
in SQL) in a non-discrete transaction while there are discrete
transactions running unless you can tolerate a very high rate of
transaction aborts.  An analogy would be to think of an implementation in
which all lock conflicts resulted in aborts rather than waiting for the
other transaction to give up the lock.

Note that "snapshot too old" is a fatal error in ORACLE, requiring the
transaction be rolled back and restarted.  ORACLE relies on their
snapshots (a.k.a. "rollback segments") much more heavily than Rdb.  Their
entire transaction model is based on the concept that SELECT, even in a
read-write transaction, retrieves data from the snapshots.  (The only way
(short of locking the entire table exclusively) to read and lock a record
in ORACLE is to use the SELECT FOR UPDATE statement.)  ORACLE does not
have the ability to drop into a standard locking model when they can't
use rollback segments to maintain consistency, so their only alternative
is to abort transactions that conflict!

- "Since discrete transaction can change each database block only once,
certain combinations of data manipulation statements on the same table
are better suited for discrete transactions than others."  "Multiple
INSERT statements (or INSERT statements that use queries to specify
values), however are likely to affect the same database block."

With discrete transactions you can't INSERT multiple records into the
same table because that is likely to go into the same "block", a physical
unit of storage in ORACLE.  You can't UPDATE two records that happen to
be in the same block.  Within one table this might mean that you can't
update all the line items in an order because they happen to be adjacent
to each other.  You can't use ORACLE's clustering facility if related
records are to be updated in discrete transactions, since clustering
records together cause them to be in the same block.

The reality is that ORACLE V7's "outstanding" performance is based on
their implementation of a "benchmark special".  Rather than improving
ORACLE's overall performance, or adding a performance feature generally
useful for a substantial number of customers, they have implemented a
feature whose only real use is to win the TPC-A and TPC-B benchmarks.
If more than ten of the tens of thousands of ORACLE customers can make
use of this feature, I'll be highly surprised.

Hal

Ps: All quotes are from Appendix A of the ORACLE V7 Application
Developer's Guide.

    Hal,

	excellent entry ! Thanks

	The problem with the whole aria of the discrete_trx is that
	noone is avare that ORACLE is driving here a more than dirty
	trick. As example, ORCALE, does not mention this 'feature'
	in their training nor at sales or marketing events, they
	emphasis on the numbers.
	And everybody knows, that the numbers is what the people
	are keeping in mind. 
	("Do not bother me with technical details" ).

	I would really apreciate a article in a magazin or paper
	describing exactly this feature.
	This will open the eyes to all DB-people.
	I think the DB-Business is a serious one, and it should
	remain serious.

	R�diger

	DOPE-FREE-DB/TP-Business

It would be rather strange to have a Digital person write an article on
this feature in ORACLE.  What we need is some independent author.  I'll
try to interest a couple of them that I know to look into and write about
Discrete Transactions.

Hal, I agree that the efffects on other concurrent transactions are surprising.
But I can imagine cases where the restrictions on multiple references to the
same database block wouldn't be a problem.  Suppose I have some updates to do,
and I'm 99% sure they won't need to access the same block after it is updated.
I try it as a discrete transaction.  If it fails, indicating that I've violated
the rule, I just roll back and try my update again as a non-discrete transaction.
This has a performance cost of
	1% * non-discrete + 100% * discrete
which is likely to be much less than
	100% * non-discrete.

Granted, this makes the programming of such applications a bit harder.  But we
need to be prepared for a response like this if we say "discrete transactions
are entirely useless."

I can easily contrive circumstances where discrete transactions make
sense.  Those circumstances are so incredibly limited as to make the
feature questionable.  Beyond that, I don't see the retry of discrete
transactions as the issue...I see the retry of non-discrete transactions
because they access a record modified by a discrete transaction as
much more of an issue.  In practical terms, you can't use discrete
transactions where:

1) Any non-discrete transaction attempts to read the same tables as being
updated by discrete transactions

2) The discrete transaction needs to examine a data value before changing
it.  You can't say "If X>0 THEN X = X-1" in a discrete transaction.  You
can only say "If X>0 at some arbitrary point in the past THEN X = X-1".

There are probably some applications that don't have either of the above
problems.  TPC-A/B, as single transaction benchmarks, can use them.

    And don't forget the maintenance and tuning nightmare.
    Actually Oracle has violated one of the major "rules" in relational
    theory.
      A program must be functional independant of the physical
      implementation of a data model
    
    Or said in another way.
    Simply rearranging the physical storage parameters of the database
    shouldn't change the function of the application nor
    endanger the integrity of the data.
    
    Discerte transactions breakes this rule, by making a program dependent
    on a low level I/O Block.
    Simply make a CLUSTER and the program fails.
    
    If this wasn't for real, I would have thought that these guys were
    making the biggest joke in Database History (well maybe they are :-)
                                       
    fwiw
    Lars

    There is something fishy here ?!
    
    The TPC-B benchmark consists of 4 different tests
    
    1) The Atomicity test
      ie Test that there is a concept of COMMIT
    
    2) Consistency test
       ie test that the application really is using the transactions as it
       should
    
    3) The isolation test
       Ie test what happens if two branches are updated from different
       transactions simultanously.
    
    4) the actual performance test
    
    How on earth did Oracle get test 2 and 3 verified if they were using
    the discrete transactions, or did they actually use different programs
    /DB-setups for test 2,3 and 4 ?
    
    confused
    Lars

	Re. .17

	Oracle passes the Isolation test (actually that would be the only
	relavant one here) by failing to commit a transaction if it's required
	to read data repeatedly (which it can not do with discrete transactions).
	
	Rolling back a transaction is a valid way to pass the Isolation test
	as per the TPC specs. 

	Unfortunate, but true.

	-amitabh.

    That cleared up the mud for me,
    
    Also it makes a nice story in a customer situation.
    Would you like your work done real fast ?
      Use discrete transactions
      ohh and by the way
        unforntunatly in 90% of the cases the work won't ever be done
    
    
    Thanks amitabh