Conference ulysse::rdb_vms_competition

    I AGREE!!
    
    Sybase is attempting to eat out lunch in the relational database
    and OLTP market. I heard they did a good job marketing in NYC and
    they're now in my turf (Boston). If any RDB developers are reading
    this I urge you to come forward and voice your opinion. Sybase seems
    to glorify itself in two phase commits, atomic commits and rollbacks
    on distributed databases and what really ticks me off is they make
    their comparisons to RDB without a TP monitor like ACMS.
    
    FYI Sybase has it's own TP monitor, very similar (functionally) to 
    distributed ACMS, which enables them to boast of their high volume
    tps rates.
    
    I see this as a serious problem which threatens our products. Interest-
    ingly enough, sales reps / and customers are mesmorized by Sybases
    claims and are willing to forgo seeing RDB/ACMS. Sales reps get
    excited about selling the iron and don't want to 'confuse' the sale.
    
    Your thoughts? (we need an action plan!)
    
    Joe D.
    

The next version of Rdb/VMS addresses many of SYBASE's claimed
advantages in OLTP.

As for the 2PC claim, well they do have one.  But, they are using some
smoke and mirrors in that the customer is required to write the
coordinator, which is the most difficult part of 2PC.

    Is your customer interested in a cluster environment or may they
    be interested in a cluster environment at some future date?  Clusters
    are rumored to be Sybases current Faux Paux.  They can serve a database
    only from a single node in a cluster.  They claim to have a cluster
    failover capability, but the last I heard was it wasn't working.
    It seems they have a problem with their Deadman Locking Scheme.
    
    Larry
    

    re: .3

    > They claim to have a cluster
    > failover capability, but the last I heard was it wasn't working.
    
    SYBASE doesn't use the VMS Distributed Lock Manager and I know that
    its own lock manager doesn't work across cluster nodes, so how does
    it failover at all?  Maybe I am missing something.

    re: .2

    What "space" is Rdb V3 going to fill (just want to hear your thinking)?  

    I ran into SYBASE a couple times here in New York.  Their main claim is 
    performance.  As far as their 2PC stuff, I think it is more marketing 
    hype than anything else.  If the customer knows how to write a 
    coordinator, he may just as well do the whole thing himself.

    The major point we have to stress when we compete against SYBASE is
    their lack of support.  I don't know how many support people they
    have now in New York, but last year, they had NONE!  New York was
    supported out of their D.C. office which is where their original
    customer, TRW, is located.  I doubt that if they even have an office
    in Boston.  If they do, maybe only Suns support is available.  However,
    I have to admit that they have very sharp people at their Berkeley
    headquarter.

    Their claim about being a TP monitor is nothing more than a multi-
    threaded db server.  SYBASE has no multi-threaded front end, so it
    would be a pig if you try to connect many terminals onto one system.  
    I don't think it has security management at the task/transaction level.
    It has no queuing, no flow control, and no sub-transaction.  I think 
    it has a long way to go before they can call it a TP monitor.

    Finally, after all the negative things I said about SYBASE, I have
    to say that it is definitely a very strong competition, especially
    in the UNIX and workstation environment (I think it beats us there).

    - Tom

    re: .4

>    re: .3
>
>    > They claim to have a cluster
>    > failover capability, but the last I heard was it wasn't working.
>    
>    SYBASE doesn't use the VMS Distributed Lock Manager and I know that
>    its own lock manager doesn't work across cluster nodes, so how does
>    it failover at all?  Maybe I am missing something.
>
    They are attempting to have a second DB Server running in the cluster
    that will take over should the first DB Server die for some reason.
    That is the only use they are making of the Distributed Lock Manager.
    
    Larry
    

    The DEC Professional had an interesting (though highly inaccurate)
    article in it, written by one of SYBASE's product managers.  They
    point out in "subtle" terms that the distributed lock manager is much to
    slow to use for anything but occasional fail-overs.  So it appears
    that they do use the Lock Manager for Deadman failover.  Perhaps
    they just haven't coded the ENQ's right yet.
    
    Any SYBASE server must lock its buffers into physical memory.  If
    you have configured 8 MB worth of buffers, you need to have at least
    8 MB of physical memory around.  What we have been trying to find
    out is whether the backup server needs to do the same thing.  That
    is; if Server B is backup for Server A does Server B also have to
    lock its buffers in memory prior to taking over from A or only at
    the point where it takes over from A.  If it is the former, then
    we are going to sell a lot more Vaxes, particularly in LAVC's. 
    Any comments?
    
    								Neil

The following came from the USENET.  Obviously, I can't vouch for its veracity,
but you might find it interesting...

Bryan

Newsgroups: comp.databases
Path: decwrl!sun!rod!rod
Subject: Re: Sybase Questions
Posted: 30 Sep 88 21:07:41 GMT
Organization: Sun Microsystems, Mountain View
 
In article <[email protected]> [email protected] (Don Pajerek) writes:
>
>along with the marketing spiels. Could anyone with Sybase experience
>answer some or all of these questions:
>
>1. Does Sybase use a single data server or multiple servers? How does
>   it stand up under heavy loads?
 
We use Sybase in Sun's board manufacturing plant. 108 ascii terminals 
spread
among 3 3/280s with another 3/280 dedicated to the DataServer process.
About 50 - 70 users logged into the DataServer on the average.  The
transaction load is pretty light at about 30 TP1 equivalents per minute.
The following is the disk and cpu columns from a vmstat 5 12 run just
now (I have absolutely no idea how normal/representative this is):
 
       disk        cpu
   x0 x1 x2 x3  us sy id
    2  4  0  0  16  9 75  <---- reflects the startup of vmstat and the
    0  0  0  0   5  1 94        tail of the hourly transaction log dump
    0  1  0  0   3  4 92
    0  0  0  0   2  1 97
    1  0  0  0   7  3 90
    9  0  0  0  32 10 58
    0  0  0  0   4  1 96
    0  0  0  0   8  2 90
    1  0  0  0  13  4 83
    0  0  0  0   3  1 96
    0  0  0  0   2  1 97
    4  0  0  0  12  6 82
>
>3. Performance: how does Sybase compare to Oracle and/or Ingres?
>
Faster than Ingres 5.0 when we benchmarked them; don't know about Oracle.
>
>5. Does Sybase use a 4GL exclusively, or can you embed database queries
>   in programs written in conventional languages (specifically, C)?
>
Our application program is exactly the latter using C function calls to
their DB Library for data base I/O and to their Forms Library for screen
I/O.
 
>6. Networking: how easy is it to run a Sybase front-end on one machine, and
>   have it talk to a Sybase server running on another machine? We will have
>   Ethernet connectivity, either TCP/IP or DECnet, or both.
>
See 1. above.  We wrote zero lines of code to use the DataServer over the
Sun's net.
 
>7. How buggy is Sybase, and how does the company respond to technical
>   complaints/questions? Are they reasonably prompt and knowledgeable, or
>   do you have to wait three days for a return call, only to find out
>   that nobody there has ever seen the problem you're referring to?
>
For a new product it isn't too bad.  They are learning how to do support
and are eager to make it (support) work.
 
>8. When a new release comes out, does existing code break?
>
Usually not.
 
>11. Does Sybase have good interactive query tools for viewing and updating
>    the database outside of any application?
>
It has two: isql (interactive sql) and the DataWorkbench.  Both work fine.
isql is line oriented and the DWB is screen oriented.
 
>13. Does the company emit a lot of vapor, as it "We'll be delivering that
>    great new upgrade real soon now".
>
No more than normal.  They understand their market and are focused on it.
Their track record on delivery vs. estimates is pretty good, e.g., usually 
late but not a whole lot.
 
Hope this helps.  Send e-mail if you need more info.