Conference ulysse::rdb_vms_competition

461.0. "ORACLE's Rdb "Fact Sheet"" by SRFSUP::LANGSTON (Ask me about RALLY) Thu Oct 19 1989 00:57

    The following was obtained from anonymous sources.  It is alleged to
    be an ORACLE sales tool.  Get your "REPLY" key ready.
    
                                 Rdb/VMS V3.0
                            Competitive Fact Sheet
    
    
    
                                                                 May 1989
    
    
    Rdb/VMS Version 3.0 is the latest release of Digital Equipment 
    Corporation's relational database management system for VAX computers.  
    It does not, however, represent a siginificant technological 
    advancement over its previous release.  ORACLE is superior to Rdb in:
    
    o	Performance
    
    o	Portability
    
    o	Continuous Operation
    
    o	Multi-versioning
    
    o	Distributed Database Capabilities
    
    o	Locking
    
    o	Support
    
    o	Tools Integration
    
    
    
    WHAT'S NEW in Rdb/VMS 3.0?
    
    o	Supports milti-file databases
    
    o	Supports hashed indexes
    
    o	Digital's VAX/SQL V2.0 is included
    
    o	Improvements in the Common Data Dictionary/Plus
    	(CDD/plus)
    
    o	On-line backup and restore facilities
    
    
    PERFORMANCE:  In a time of decreasing CPU costs, Rdb is still an I/O 
    bound system.  For each transaction, Rdb does several times the number 
    of I/O's as ORACLE V6.0.  In effect, Rdb is limited to the throughput 
    of today's desk drive technology.  Digital's own published benchmarks 
    confirm this limitation.  Rdb was not able to achieve more than 30 
    transactions per second (tps) on the VAX 6360 as reported in the VAX 
    6300 Series ACMS/Rdb DebitCredit Benchmark Summary.  Compare that to 
    ORACLE's benchmark of 66 tps on a 6360.
    
    In addition, Rdb's scalability is almost non-existent: 8.4 on a 6310, 
    16.0 on a 6320, 25.4 on a 6340, and 30.0 on a 6360.  Rdb is obviously 
    not optimized for VMS.
    
    
    PORTABILITY: None for Rdb.  It runs only on VAX/VMS. It does not even 
    run on ULTRIX, Digital's version of UNIX.  People buying Rdb are 
    locking themselves into more than a database; they're committing 
    themselves to Digital's hardware and operating systems for the entire 
    life of their information management system.
    
    
    CONTINUOUS OPERATION:  ORACLE V6.0 can run 24 hour a day, 7 days a week 
    without interruption of service.  Rdb cannot.  Although Rdb does 
    support on-line backup, it requires the use of snapshot (SNP) files on 
    the entire database.  These files require an extra write for all 
    update, insert and delete operations.
    
    Rdb's real problem with continuous operation is the after-image journal 
    (AIJ) file which it needs for recovery.  The AIJ is a single file.  
    When it fills up, all transactions (except for read only transactions) 
    must be stopped so that the data in the AIJ can be written to tape.
    
    Digital recommends that you use an entire disk to store the one AIJ 
    file so that you need only write to tape once a day, i.e., at night.  
    If you are only running your system at a throughput rate of 5 to 10 
    tps, this method works.  If you are running at 30 tps, however, (Rdb's 
    maximum), the AIJ file can fill up in just a few hours.  If Rdb could 
    run at 66 tps or more (ORACLES's speed), the AIJ file would fill up 
    even faster.
    
    ORACLE uses multiple redo files to store recovery information.  When 
    one file fills up, another one takes over.  Data in the full file can 
    then be archived to tape with no interruption in service.
    
    
    MULTI-VERSIONING: ORACLE and Rdb are able to maintain multiple read 
    consistent versions of the database.  Thus, readers don't block 
    writers, and writers don't block readers.  Rdb's implementation of this 
    capability, however, extracts heavy performance penalties.  Rdb stores 
    read consistent versions of data on disk in snapshot files.  Thus, 
    reading a previous version of data requires a 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.  Rdb has one extra I/O operation for 
    every update, insert or delete.
    
    DISTRIBUTED DATABASE CAPABILITIES: Rdb claims to have distributed 
    capabilities, but in reality it just distributes data by providing 
    snapshot copies of the source database across multiple nodes.  The VAX 
    Data Distributor uses two methods of copying the source database: 
    extraction and replication.  Extraction allows both read and write 
    access to the snapshot, but changes made to the snapshot database after 
    the extraction are not transferred back to the source database, and 
    vice versa.  During updates, the entire snapshot must be replaced with 
    a new extraction from the source.  A replicated snapshot has read 
    access only, but may receive updates from the source at specified time 
    intervals.
    
    On a VAXcluster, Rdb allows users to query data which is stored on 
    other processors in the cluster.  However, users must specify the name 
    of the device they are addressing (the system is not 
    location-transparent), and distributed updates are not supported.
    
    
    LOCKING: Rdb uses the VMS Distributed Lock Manager, which offers 
    adjustable lock granularity.  In other words, if there is more than one 
    transaction trying to query or update data in the same table, Rdb may 
    demote the table lock to a page or row level.  The drawback here is the 
    overhead associated with changing the lock granularity.
    
    It is only in Rdb's shared write mode that muliple users may update the 
    same table.  But, lock contention increases as does the likelihood of  
    deadlocks.  Overall, transaction turnaround slows down and, in the case 
    of deadlocks, users have to redo work.
    
    
    SUPPORT: One rationale that Digital offers for buying Rdb is that it is 
    fully supported by Digital.  But because of two less profitable 
    quarters, Digital has reduced its sales support, and in particular, 
    OLTP support has been affected.  Digital has no past experience to draw 
    upon.  Oracle has far more support people in the field that are fully 
    qualified to support the ORACLE RDBMS on VAX hardware.
    
    
    PERFORMANCE MONITORS:  Rdb has good, interactive performance mnitoring 
    tools.  Displays can be printed to flat files, summary reports can be 
    generated, runs can be saved and replayed, and statistics can be 
    reported graphically or numerically.  Unlike ORACLE, however, Rdb does 
    not have a resource lock monitor. 
    
    
    
    TOOLS
    
    Rdb                  ORACLE
    ___________________________
    
    Rdb, CDD/Plus    ORACLE RDBMS
    DECforms         SQL*Forms
    VAX RALLY        SQL*Menu, SQL*Forms
    VAX DATATRIEVE   SQL*Report Writer
    VAX TEAMDATA     Easy*SQL, SQL*Calc
    
    Since all Oracle tools are SQL based, a user can apply the skills he 
    learns with one Oracle product (such as Easy*SQL) towards another 
    product (such as SQL*Forms). In contrast, knowledge of any given 
    Digital tool is of no use in learning any other Digital tool.  Thus, 
    Digital's tools require much more training than Oracle's.
    
    
    THIRD-PARTY INTERFACES: Focus, RTI, and Excelerator: Digital's lack of 
    integrated tools has forced them to integrate with third-party vendors.  
    The future of these relationships is unclear, since Digital's marketing 
    strategy is to be a single supplier.  Customers who purchase these 
    short term solutions will lose when Digital has its own quality tools 
    to sell.
    
    
    PRECOMPLIERS: Ada, BASIC, C, COBOL, FORTRAN and PL/I.
    
    
    PRICING: The run-time version of Rdb is now bundled into VMS V 5.0. 
    However, users will need to purchase the full development version to 
    use Digital's or RTI's tools. The run-time version does not include 
    CDD/Plus ($340 to $10,810) which is so closely coupled with Rdb that it 
    is almost mandatory.  Documentation and service contracts cost extra, 
    too. Also, low revenue products tend to have low R&D budgets.
    
    
    GARTNER GROUP COMMENTS:  From Gartner Group's Software Management 
    Strategies Feb. 8, 1988 Bulletin: "Rdb still lags the three prominent 
    ISV products (ORACLE, Ingres, and Sybase) in overall function and even 
    in exploitation of VAX/VMS, a situation which should persist for 
    several more years."
    
    From the same article: "...the fact is that Digital hasn't yet unveiled 
    DDBMS capabilities in the commonly understood sense.  Not before 1993 
    will we see Rdb/VMS's role in integrating the enterprise."
    
    
    MARKET SHARE: Currently, Oracle is the RDBMS VAX/VMS market share 
    leader, and has a 3 to 1 lead over Digital for planned purchases.
    

    What happened to the note ??
   

    I have released the notes. The reason that they were set hidden is that
    I have seen this report and have written an "internal use only" Digital
    competityive fact sheet for Oracle V6. It will be available on:
    NOVA::pm01:[booth.public]oracle_competitive.ps.
    
    You'll like it.
    
    ---- Michael Booth

    
    I can go with a lot of words, comments, and phrases to describe your
    article, Mike (as posted in 461.3) but I'll forgo all of that...
    
    
                           B R A V O   !!!
    
    Bob

Re: .3 ...

How about an LN03 version of the file for those of us in remote offices 
that are too poor to buy an LN03R!

Rick C


P.S.:	Don't feel too sorry for me...I feel sorry enough for myself!

    Given the fact that a specific format was desired, and that ASCI
    characters were not good enough, and that we don't have access to
    ALL-IN-1 up here, the options were quite limited. I will try to get the
    document typed in. However, the graphic will not be tranfereable, nor
    will much of the emphasis be there.
    
    So, I'll try to get one typed in, but the effect will be less than
    dazzling.
    
    ---- Michael Booth

    
    I took the liberty of extracting the Rdb/VMS V3.0 fact sheet (the one
    that ORACLE puts out, not Michael's piece...) and setting it up in 
    SDML format.  From there, of course, it can go to terminal, LN03, etc.
    
    If you're interested, send me mail and I'll jet it out to you.  It's
    done in two_column format so that you can put it side-by-side with
    Michael's "rebuttal."
    
    Too bad we can't whip this out to customers...
    
    Bob
    
    PS: Michael, would you like me to re-do yours in DOC?  All I'd need is
        a plain ASCII version.

    
    (Just read the latest NewsBooth, with mention of the Oracle paper,)
    
    So, now we know how well Oracle respects their own "internal policies,"
    generating an Internal Use document that gets distributed freely to
    their customers and prospects.
    
    We, on the other hand, have a very neat 'rebuttal' paper available, 
    but we really can't give this to a customer due to the label on the
    bottom that we all must respect.  (Ahem, right, people?)
    
    From the account that I mentioned earlier (recipients of misleading
    Oracle evaluations of DEC products) I've found that the lasting
    impressions left by such documents is remarkable.  We could, on the
    other hand, diminish their effectiveness if not turn the impression
    around entirely by distributing *our* side of the story.  This is
    not to say that we should fight fire with fire, but by making the
    documents available, we can point out the folly of Oracle's claims,
    or at least show customers that there are two sides to every story.
    
    I would imagine that getting such documentation pushed through the
    Digital system is not an easy task, but I think it's an important
    one.  Fact sheets and other counter-claim literature can be an
    important sales tool... a highly effective one.
    
    So, my question: what can we/DEC do to make this information available
    to customers, and how long would it take?  If this can't be done in a
    reasonable time frame, can anyone suggest a position to take with the
    customer on why WE don't choose to publish our statments?
    

    
    Ted, 
    
    Your question, and that of 475.1, is addressed in 461.x, that being
    Mike Booth's great point-for-point, jam-it-in-their-face rebuttal
    to the Oracle sheet.
    
    But, as raised in my previous reply here, I'd really like to see
    something that is "approved" for customer distribution.  See, we
    all could figure out ways around "internal use only" restrictions,
    but not only does that subrogate us to sneaking around the policy,
    the customer would have a greater sense of faith in our facts if
    we could �leave� a �professional quality� document behind for their
    evaluation.
    
    As always, and has been noted before, the longer Oracle raises FUD
    at the customer with "heresay sheets", the more difficult it becomes
    for Sales and Sales Support to dislodge the maligned impressions of
    Rdb/VMS and Digital in general.
    
    

	I hit the <next unseen> too quickly and did not read Mike's
	reply. I have pulled the rebuttal article and am heading toward
	the office to read it...

    I used the information from the Oracle V6.0 Compatitive Fact Sheet in a
    presentation to an existing customer. Issues I addressed were:
    	portability <-> interoperability
    	architecture
    	performance
    	marketshare
    	price
    	availability and reliability
    	tools
    	vendor image
    
    All subjects had first Oracle's claims followed by our FACTS. This
    customer (XEROX) really loved it. "For the first time a real
    presentation that will help us to position ORACLE against Rdb/VMS" they
    said.
    
    I agree with all who say that we should operate more aggressive with
    Rdb/VMS.
    
    
    Thanks for all the good information and slides Michael.

    Does anyone have a copy or know where I can get a copy of the fact
    sheet that was mentioned in 461.3?  I get a directory not found
    error message when I try to copy the file.
    
    Thanks.
    

    NOVA::PM01:[DBS_HELP.PUBLIC]
    
    Barry