Conference ulysse::rdb_vms_competition

763.0. "Oracle Facts on Rdb (and my comments)." by COPCLU::BRUNSGAARD (ACID isn't just music and junk) Tue Oct 09 1990 16:03

    Hi,
    
    Just go my hands on an Oracle Competitive fact sheet on Rdb.
    
    I will try to highlight the points here:
    and include my own commetns afterwards.
    
    Overall impression:
    They don't know much about Rdb (or VMS for that matter).
    The Paper presents itself EXACTLY like the ones MIKE BOOTH used to
    make, ie two page, ending with a diagra showing number of licenses.
    
    The facts:
    
    The fact sheet is about V3.0 Of Rdb !!!! which is stated to be the
    LATEST RELEASE of Rdb.
    >They are a bit far behind aren't they ??
    
    Oracle is superior to Rdb with regards to:
    
    Performance:
    Rdb is limited to the speed of the disks, Rdb does 30TPS
    whereas Oracle does 66TPS
    >Has anyone heard about a database system NOT limited by disk speed ?
    >If Oracle is not they are actualy "officially" stating here they are
    >cheating with the benchmarks, ie not using disks.
    
    Portability:
    Rdb does not run on UNIX, therefore you are lokced into teh VAX
    environment.
    >True, but O customers are locked into O, much more than Rdb customers
    >are locked into VMS
    
    Continuous Operation:
    Oracle V6 run 24x7, rdb does not, as it requires processing stopped 
    while the AIJ is backed up.
    When the AIJ fills up the operation stops on Rdb.
    The AIJ will become very large on Rdb systems.
    The multiple redo files are superior to the one AIJ file.
    >Well they have completely missed the fact the RMU/BACKJUP/AFTER works
    >online, and never requieres users to exit the database.
    >The aij can be continually spooled to tape (or anotehr disk to backup
    >to tape afterwards)
    >The multiple REDO files they have makes it fairly hard to RECOVER form
    >disk crash as you need to appli teh files in correct order, and there
    >is not help form oracle here.
    >It seems that O has gotten things mixed up with regards to which
    >product stops when files fill up.
    > Rdb will stop when a disk fills, O will stop when ANY datafile fills
    >up, note that all redo files counts as "one" file here.
    >The princip O uses is that REDO files are used both for ROLLBACK and
    >RECOVER, meaning that both operations suffer in performance.
    
    Multiversioning:
    Both product maintain multiple read-consistant copies of records, but
    Rdb pays a high performance price as DISKS are needed to store the old
    versions.
    >Hmm this is rather interesting, as O clearly states that their SNAP
    >capabilities are based on MEMORY usage. Kind-a-hard to see cluster
    >support emerging around this concept. WHEN O needs to write old copies
    >to disk (no more memory) it uses ONE file for the whole database.
    >I think their implementation is the one that needs a refreshment to
    >avoid contensionproblems on the disk.
    
    Distributed Capabilities:
    Rdb is claimed to have distributed capabilities, but is just
    distributed data through DATA DISTRIBUTER.
    >I haven't heard anyone CLAIMING we have a distributed database, we
    >just we have the option of using data distributor to distribute copies
    >of data...
    
    On a VAXcluster, rdb allows users to query data stored on other
    processors in the cluster. However users must know the names of the
    device where the database resides.
    >No that interesting, Database on each processor. This really shows
    >their in-depth knowlegde about clusters, that files ACTUALLY can be
    >SHARED between nodes.
    >Of course they have never heard about logical names either to addres
    >files...
    
    Locking:
    Rdb uses the VMS distributed Lockmanager, which offers adjustable
    locking granularity.
    >Hmm maybe Rdb engineering should see this. Now they can remove all
    >code they have written to handle this as the lock-manager now can
    >handle it by itself.
    
    It is only in Rdb's shared write mode that multiple users may update
    the same table.
    >Yes of course...
    
    Support:
    Support is bad on Rdb because of two less profitable quaters for
    Digital, especially aroud OLTP support. Digital has no exsperience to
    draw upon. Oracle has FAR more support people in the field than Digital
    >I think these lines speak for themselves
    
    Percompilers:
    >They forgot PASCAL (oh and didn't tell that all precompileres come
    >with teh developmetn licence with no extra charge
    
    Market share:
    Currently Oracle is the VMS database market leader and has a 3 to 1
    lead over DIGITAL for planned purchase
    >Planned purchase surveys are always, and will alwyas be complete
    >nonsence to used competitive market SHARE information.
    
    I hope this can be used by you girls and guys, they are as much behind
    Rdb in functionality and technical strenght as this fact sheet is
    behind the V3.1 release of Rdb.
    
    A bet: Rdb will release V4 of Rdb the day after Oracle ANNOUNCES is's
    version 7, but the actual realease data of V7 will be sometime in 92
    (and their competitive fact sheet will be update to reflect V3.1 of Rdb
    just after V4 is shipped).
    
    Lars

    Thought this would fit here.....hahahahaha
    
The following was taken from the September 1990 issue of VARBUSINESS, page 21 
in an article entitled "ORACLE'S PERFORMANCE IS NO JOKE"
        
        "{ .... But the joke isn't funny anymore.
        
        	At least not to people like Desmond Gilligan, project 
        manager in the MIS department at Dataquest Inc., a San Jose 
        market research firm, which last year spent $1 million on a suite 
        of Oracle products only to find that some of them were 
        practically unusable. "We had several Oracle products and we 
        threw three out." recalls Gilligan. "They sold us a bill of 
        goods. We could have wasted as much as $200,000."
        
        	Now Gilligan's project is six months behind schedule and 
        his lead programmer has quit, citing frustration with Oracle 
        products as his chief complaint.
        
        	Gilligan isn't alone. In the last year Oracle has been 
        beset by users complaining that the Belmont, Calif., company was 
        shipping products that had significant flaws. Some users were so 
        angry that they stopped paying for products.
        
        	Even on Wall Street, where Oracle's 100 percent annual 
        growth rate made the company a favorite, securities analysts are 
        advising caution. The reason is that Oracle still has problems. 
        Some, ....... are operational. Others are technical. Products 
        such as forms 3.0 are still riddled with bugs, according to 
        users.}"


The article goes on to talk about the lack of success of Oracles VAR program 
with such descriptive quotes as: 

"With Oracle, a $30,000 solution can balloon up to $250,000"

"The commitment they wanted in comparison to the amount of product we could 
sell was ridiculous"

"We've the largest reseller in Chicago, and we couldn't come near the 
numbers they were expecting"