Conference ulysse::rdb_vms_competition

578.0. "Oracle Rebuts" by BANZAI::BOOTH (What am I?...An Oracle?) Tue Feb 20 1990 16:03

    Oracle has gotten its hands on a copy of my Oracle-Rdb comparison. I
    have commented on the Oracle rebuttal.

    My comments are prefaced with >>>. Two things should be noted. First,
    the Oracle rebuttal only hits a few minor points of a three-page
    document. In other words, the bulk of the story was not even touched.
    Secondly, again an INTERNAL USE ONLY document fell into Oracle's hands.
    This speaks very poorly of security practices.

    I see no reason to do a massive rewrite or get into knee-jerk mode.
    The Oracle rebuttal is very limited and leaves the bulk of our
    comparison untouched. The fact that such a comparison made Oracle react
    must mean that the comparison document is working.

    ---- Michael Booth



*****************************************************************************
*	  	   FIRST------>Fast InfoRmation to Sales Team               *
*     Information that will help you make an IMPACT selling ORACLE on VMS!  *
*                                                                           *
* CONTENTS:	Oracle answers DEC's competitive fact sheet.                *
*		This response was made possible because information about   *
*		DEC's fact sheet was provided by the field.  Send DMKT      *
*		info about the competition and we will address it.          *
*****************************************************************************
 
Digital recently distributed an ORACLE V6.0 Competitive Fact Sheet to 
their sales force.  The document is inaccurate and misleading, 
and presents many errors as fact. The following are Digital's major 
claims and our responses:
 
 
        "Oracle's published benchmarks are highly suspect and they
         used a poorly defined TP1..."
 
** The ORACLE benchmark was designed in accordance with the standard TP1 
definition and was AUDITED and VERIFIED by Tom Sawyer, Senior Consultant at 
Codd & Date Inc., one of the most respected relational database consulting 
firms in the country.  ORACLE achieved 66 tps on a VAX 6000 Model 360 
compared to Rdb's 30.6 (See the "Auditor's Report of ORACLE and Digital Rdb 
TP1 Benchmark Results," Part # 50542-1089).

    >>> There is no "standard TP1 definition." Oracle's TP1 is different
    >>> than Sybase's TP1, which is different than Informix's TP1. The
    >>> Oracle TP1 is all batch, has no interactive users, measures only
    >>> pure engine performance. This is very unlike a Debit/Credit (soon
    >>> TPC-A) which requires a specified database size, number of users,
    >>> performance measurement, etc. 
 
        "Digital has made it clear that its direction is toward SMP [Symmetric
        Multi Processing].  While that bodes well for Rdb, Oracle has problems
        with this type of configuration."
 
** Digital is creating a smoke screen to cover ITS OWN problems with SMP.
There isn't a database available that has been more optimized than ORACLE
to take advantage of SMP (whether for DEC SMP, Sequent, NCube, etc.).
Scalability, the increase in performance as more processors are added, is 
the clearest indicator of optimization for SMP.  Refer to Digital's own 
audited Rdb benchmarks (Jan. 1989) for the VAX 6300 series:
 
                6310     8.4 tps
                6320    16.0 tps
                6340    25.4 tps
                6360    30.0 tps
 
Note that two extra processors at the high-end give you only 4.6 additional 
tps! Now, is that optimization?  A Digital News article (12/11/89) states 
that Tom Sawyer of Codd & Date attributed ORACLE's superior performance to 
its "ability to maximize Digital's SMP architecture"  and  that Sawyer 
"noted that ORACLE's performance increases in a more linear fashion as 
processors are added, and Rdb's performance levels off as processors are 
added."  In other words, Rdb definitely does NOT fare well with SMP.

    >>> Again, Oracle's test had no interactive or simulated user load. It
    >>> is not difficult to design a batch benchmark to make it appear to
    >>> utilize SMP. It is much harder to utilize SMP in the real world. The
    >>> Oracle architecture is detached processes with only the READ process
    >>> able to run concurrently on multiple processor. Admit it now or admit it
    >>> later, but that architecture means that all significant database work
    >>> is done on ONE PROCESSOR. That is not an effective utilization of SMP.
 
 
        "If the [ORACLE] database expands beyond the assigned limits, all
        database activity must be stopped while the space is reallocated and
        the database reloaded."
 
** Not true.  A reallocation and reload are NOT necessary.  If the database 
does run out of space, the DBA can simply add another file while processing 
continues.  Further, the DBA can issue a simple query at any time to find out 
how much space is left in the database so that this should NEVER happen in 
the first place.
 
    >>> Let's see, that means IF the Oracle DBA monitors constantly, and
    >>> sees space running out, everything works. But IF the DBA doesn't
    >>> monitor constantly, the database could shut down. Further, it means the
    >>> Oracle database requires extra disk space to preclude the possibility
    >>> of such a shutdown---not an efficient use of disk space. The fact
    >>> remains that Oracle is a "static state" database with no dynamic space
    >>> utilization.
 
        "Rdb can be recovered easily from either corrupt data or a media
        failure.  Oracle handles corrupt data, but recovery from media
        failure is complex and time consuming.  What happens if your disk
        crashes?  How many days will you lose attempting to restore that
        Oracle database?"
 
** ORACLE provides FULL ON-LINE data recovery mechanisms in the event of a 
media failure.  Should there be a media failure, the rest of the database 
continues to operate while the DBA takes whatever steps necessary to repair 
the disk. Then the most recent backup of the damaged file(s) is applied, 
the redo log is applied to bring the tablespace back to the point just 
before the crash occurred, and that table space is brought back on line.
All of this can be done while the rest of the database is in operation.  
No "days" lost here -- unless that's how long it takes Digital to fix your 
crashed disk.
 
    >>> "The rest of the database operates" is an interesting concept. So
    >>> if one table is lost, and that table has dependencies to the remainder
    >>> of the Oracle database, how much work can be done? Remember that Rdb
    >>> uses a concept of multiple Rdb databases on a system, while Oracle
    >>> allows only one Oracle database per system. The Oracle method for
    >>> restoring from media failure is both complex and time-consuming.
    >>> "...that tablespace is brought back on line" covers a multitude of
    >>> steps. The above scenario appears to be a "best case."
 
        "Oracle V6.0 cannot operate on more than one node in a
         VAXcluster System."
 
** False.  You can run ORACLE V6.0 on as many nodes in a VAXcluster as
desired using SQL*Net to communicate between them.  What V6.0 doesn't yet 
support is the ability to start the database in multi-instance mode, 
allowing nodes to independently access data on the shared disk without 
using SQL*Net.  Customers who require multi-instance support can use 
RDBMS V5.1.22 until V6 provides this functionality.

    >>> This is really a semantic game. Certainly different Oracle
    >>> databases can run on different nodes. That is Database A on node A,
    >>> Database B on Node B. But "operating on more than one node" means
    >>> Database A on nodes A, B, and C. Yes, "customers who require
    >>> multi-instance support can use RDBMS V5.1.22..." which provides roughly
    >>> 1/5 the performance of Rdb. Lets see, V5.1.22 doesn't work at all well 
    >>> with SMP, but V6 doesn't support VAXclusters. What about the Digital
    >>> customer with SMP machines in a VAXcluster system?
 
 
        "Digital can see the 'big picture' beyond just the database."
 
** Has Digital heard of Oracle Complex Systems?  Oracle Financials?
Oracle*Mail?  Oracle's CASE products?  How about "heterogeneous computing
environments?"?  The only 'big picture' Digital can possibly see is $$$ 
-- lock people into Rdb and all that 'big picture' can ever contain is 
Digital hardware and related products.
 
    >>> Hardware prices are dropping as software prices are rising. Hardware
    >>> is a trivial expense compared to software. Digital can see networking,
    >>> connectivity, systems integration, and applications with an eye toward
    >>> effectiveness, rather than an eye on expensive database software
    >>> licenses on every machine. Every Oracle "solution" requires the
    >>> Oracle database. Digital will use SQL/Services to network PCs
    >>> running any database. Digital's CDD/Plus repository tracks
    >>> Definitions from VAX DBMS, Rdb, and RMS, not just a database.
    >>> Digital's prime goal is customer satisfaction.

        "Oracle's multiversioning has a major failing in that if a record 
        has not been recently altered, the database will be unable to find 
        a copy of that record in the 'redo' log."
 
** Ludicrous.  The fact sheet refers to ORACLE error ORA-1555, which they 
claim is "rollback segment not old enough"  but is in fact "snapshot too old 
(rollback segment too small)."  This error occurs when a system has been 
IMPROPERLY set up for the activity load it must handle.  This statement 
indicates that Digital has some major misconceptions about ORACLE V6 
architecture.

    >>> This information came from a customer site where Oracle technical
    >>> support was heavily involved. One must then assume that Oracle itself
    >>> "has some major misconceptions about ORACLE V6 architecture."
 
 
        "SQL*DBA [is] for maintenance rather than tuning and performance
        monitoring."
 
** Did Digital miss the SQL*DBA MONITOR command?  This command brings up a 
full screen display that allows you to view many aspects of database activity.
 
    >>> The SQL*DBA utilities are wholly for routine maintenance. There is
    >>> a monitoring utility as with all databases. The utilities are not
    >>> for performance tuning, but rather for maintenance functions.
 
        "PL/SQL is still not available in 9/89.  Further, it has been
        widely reported that PL/SQL is incompatible with the current
        SQL*Plus.  That means it will require rewrites of applications."
 
** PL/SQL was released as production with the transaction processing option
on VMS in September, 1989.  SQL*Plus V3.0 is production with RDBMS V6
and PL/SQL is fully compatible with it.  PL/SQL is the procedural extension
to the SQL language; it requires no rewrite of current applications unless 
the user wants to add PL/SQL syntax.

    >>> Or unless the customer wants the performance increases that Version
    >>> 6 promised, since PL/SQL is a big component of that better performance.
 
        "At the time of this report, the MVS version of ORACLE V6 was
        not available.  Oracle has no plans to provide V6 for MS-DOS.  What
        does that say about application portability?"
 
** V6 for MVS is available.  V6 and all the V6 tools, including Forms 3.0,
ARE being ported to MS-DOS and will be available in a few months. There
goes Digital's application portability argument.  What is DEC implying
anyway -- that Rdb WILL be ported to MVS and MS-DOS??  DEC provides a long
list of platforms to which Rdb will be ported: VMS, VMS, VMS, VMS, VMS, 
and VMS.  Oh, and also VMS.  And, of course, DEC happened to forget all our 
UNIX and minicomputer V6 ports too.
 
    >>> If Oracle V6 is being ported, that is in direct contradiction to
    >>> what Oracle announced. There lack of V6 ability on PCs has been widely
    >>> reported as has there lack of any desire to have V6 on MS-DOS. "Will be
    >>> available in a few months" is unconvincing. DEC is "implying" that
    >>> different versions of Oracle on different platforms undercuts Oracle's
    >>> portability arguments.

That's it!  Go get 'em!!
 
Author: Ojas Rege
 

Like Michael, I am quite concerned about our Digital security. I am
appalled that a document clearly marked INTERNAL USE ONLY was in any way
leaked so that Oracle got hold of it.  This frightens me!

However, I believe that we have one way to deal with Oracle's use of that
document.  All written material is implicitly copyrighted even as an
unpublished work.  Oracle took our written, and therefore copyrighted,
material and quoted liberally from it in another written document that
they then distributed (and will no doubt give to their customers).  I
believe that we should address the copyright issue and stop this malarkey.
Don't forget, Oracle is the company whose license agreements prohibit
anyone from revealing their performance figures so that we (for example)
cannot publicly compare Rdb/VMS with Oracle while they can do whatever
they please about that.  Fair's fair, and they must be held accountable
when they break the law.

Grumble,
   Jim

    I'm working with a customer/prospect who asked us in after they
    tried Oracle's products and Oracle "couldn't support its products
    on [4381] VSE" at least in southern California.
    
    I guess they have to be selective about which of the many platforms
    they run on get support resources.

    Let's drop the tit-for-tat garbage. Oracle published an internal;
    comparison. We published an internal comparison. Of course they
    attempted to rebut our comparison. The interesting thing is that so
    little of the comparison was questioned, and most of that was semantic
    gamesmanship.
    
    I'm sure both their Internal and our Internal document wound up in the
    hands of customers. That's the way the game is played. Our document was
    forthright and effective. More importantly, this is one of if not THE
    first time Oracle has been placed in a reactive posture. That is a
    substantial change. Let's keep the pressure up. The more reactive a
    company gets, the less effective they become.
    
    ---- Michael Booth

    Please, where is the original article?  I want to read it.
    
    I promise that I will not show or tell it to a salesperson.  Betcha a
    bunch that is how it leaked.  Hope it wasn't in a Sales or Competitive
    Update I missed.  That is almost as good as putting it in your local
    newspaper.
    
    Fred