Conference ulysse::rdb_vms_competition

475.0. "Oracle's Rdb comparison paper" by DPDMAI::DAVISGB (Gil Davis DTN 554-7245) Mon Oct 30 1989 17:45

    Thanks to Ramon Smitherman for typing this in.  Here's the paper that
    Oracle sales people have been handing out to customers.....Designed to
    generate *F*ear *U*ncertainty and *D*oubt.....
    
    
                     ORACLE/Rdb Overview - September, 1989



ORACLE V6.0 is the latest release of Oracle's relational database management 
system.  Rdb V3.0 is the latest release of Digital Equipment Corporation's 
relational database management system.  Based on our review of these two 
products, we feel that ORACLE is superior to Rdb because:

ORACLE OUT PERFORMS Rdb.
	Recent TP1 benchmarks which were audited by Codd & Date, show that 
        ORACLE is 2.16 times faster than Rdb.  The TP1 benchmark was run using 
        ORACLE V6.0.27.4 and Rdb V3.0 on a DEC VAX 6360.

	Audited Benchmark Results:  ORACLE vs. Rdb

	DATABASE			Transactions per Second
	-------------------------------------------------------
	ORACLE V6.0				66.0
	Rdb V3.0				30.6

ORACLE OFFERS BETTER PRICE/PERFORMANCE THAN Rdb.
	As part of the TP1 benchmark discussed above, price/performance was 
	studied.  When comparing the 5 year total system cost per transaction, 
	Rdb is 50% more expensive than ORACLE.  Even when using Rdb's runtime 
	license, Rdb is 44% more expensive than ORACLE.

	Audited Benchmark Results:  ORACLE vs. Rdb

					5 YEAR 4K/TPS		5 YEAR 4K/TPS
	DATABASE			(development)		(runtime)
	---------------------------------------------------------------------
	ORACLE V6.0			    28.47		    27.34
	Rdb V3.0			    42.68		    39.26

ORACLE USES SMP ARCHITECTURE MORE EFFICIENTLY THAN Rdb.
	In order to study the efficiency of ORACLE and of Rdb on Digital's 
	Symmetrical Multi-processor (SMP) architecture, the TP1 benchmark was
		run on a VAX 6310, VAX 6320, VAX 6340 and VAX 6360.  ORACLE's 
	performance increases in a more linear fashion as processors are added.  
	ORACLE can take better advantage of the SMP architecture because of a 
	superior cache architecture.  Rdb must re-read and updated data page 
	while ORACLE can read the updated cache buffer. Thus, Rdb requires more 
	I/O bound operations per transaction, resulting in an I/O bound system.  
	On the other hand, ORACLE, not being I/O bound, can make full use of all 
	available CPU power.



	ORACLE/Rdb Overview - page 2


ORACLE OFFERS CONTINUOUS OPERATION.  Rdb DOES NOT.
	ORACLE can run 24 hours a day, 7 days a week without interruption of 
	service.  Rdb cannot.  Although Rdb does support on-line backup, it 
	requires an extra write for allo update, insert and delete operations.  
	In order to guarantee rollforward recovery, the after-image journal 
	(AIJ) is required.  The Rdb AIJ is a single file.  When it fills up, all 
	transactions (except for read-only) must be stopped.  this is not 
	acceptable in an environment requiring continuous operation.  This 
	recovery architecture is similiar to the old ORACLE V5 recovery 
	architecture.  However, ORACLE V6 solved this problem with mutiple redo 
	logs.  When one fills, the next takes over so that data can be archived 
	with no interruption in service.

ORACLE MINIMIZES DISK I/O.  Rdb DOES NOT.
	ORACLE minimizes disk I/O by supporting shared buffer technology.  Once	
	a data page in the buffer cache is updated, Rdb must write that page to 
	disk.  Then Rdb must re-read the updated data page from disk while 
	ORACLE can read updated data directly from the updated cache buffer.  
	ORACLE  also fast commits, deferred writes and multi-block reads and 
	writes to reduce I/O contention.

ORACLE OFFERS SUPERIOR LOCK MODEL THAN Rdb.
	ORACLE offers a row level lock model.  Rdb's locking is managed by a 
	mechanism called "adjustable lock granularity".  If there is more than 
	one transaction trying to query or update in the same table, Rdb may 
	demote the table lock to page or row level.  The drawback is the 
	overhead associated with montoring and changing the lock granularity.  
	ORACLE manages the row level locks on a transaction level.  Therefore, 
	ORACLE's lock lists are much shorter than one would expect in a system 
	that does row level locking and the lock management overhead is minimal.

ORACLE OFFERS BETTER MULTI-VERSIONING SUPPORT THAN Rdb.
	Multi-versioning is the capability to maintain multiple read consistent 
	versions of the database so that readers do not block writer and writers  
	do not block readers.  Although Rdb offers this capability, the 
	implementation extracts heavy performance penalties.  Rdb stores the 
	read consistent versions on disk in snapshot files.  Thus, an operation 
	which requires read consistent data will need to perform disk access. 
	In contrast, ORACLE stores this data in rollback segments which can 
	usually be kept in memory.  Similarly, when a transaction modifies data, 
	Rdb needs to write this data to disk.  ORACLE only needs to write the 
	old version of the data to the rollback segment in memory.  Therefore, 
	Rdb has one extra I/O operation for every update, insert or delete.



		ORACLE/Rdb Overview - page 3

ORACLE OFFERS PORTABILITY.  Rdb DOES NOT.
	ORACLE runs on a wide variety of hardware platforsm under many different 
	operating systems, including all the operating systems offered by DEC.  
	Rdb runs only on VAX/VMS.  It does not run on Ultrix, Digital's version 
	of UNIX or any other operating system.  ORACLE allows you to take 
	advantage of all of Digital's hardware offerings as well as those of 
	many other vendors.  Rdb does not.

ORACLE OFFERS MORE ADVANCED DISTRIBUTED CAPABILITIES THAN Rdb.
	ORACLE's distributed capabilities include site autonomy and location 
	transparency while Rdb's do not.  Site autonomy allows for the 
	independent operation of each node in a network.  Location transparency 
	implies that the location of the data is transparent to users and 
	applications.

ORACLE OFFERS INTEGRATED APPLICATION DEVELOPMENT.  Rdb DOES NOT.
	ORACLE's tools are integrated and SQL based.  Therefore, a user can 
	apply the  skills learned with on ORACLE products towards another ORACLE 
	product.  In contrast, the tools that are available for use with Rdb are 
	not integrated or even similiar in look and feel.  Therefore, knowledge 
	of one tool is of no use in learning another tool.  Because Digital 
	lacks integrated tools, they have teamed with third-party vendors.  
	However, the future of these relationships is unclear since Digital 
	traditionally prefers to offer Digital developed products.

The information presented above is meant to be factual and accurate.  If any of 
the information is found to be incorrect, it was not an intentional 
misrepresentation.


    

    Well folks, this is the information that Oracle has been spreading
    for awhile now.  It would be great to hear a realistic rebuttal
    from someone who can address each of the issues from a technical
    (not a marketing :-) ) point of view.  The paper from Oracle is
    perceived (by some/many of my customers) to be very technical in 
    nature and Oracle is blackening our collective eye(s) with this
    one.
    
    So, how do we respond???????
    
    -Rick Brewis & Bruce Langston

    see note 461.3 and enjoy !!