Conference ulysse::rdb_vms_competition

    < Note 492.0 by MABUZZ::BUZZERD "Why NOT Rdb ??" >

    
    Unfortunately, an increasing number of DoD customers are
    "standardizing" on a specific dbms. Some services have selected Oracle,
    this one, Sybase. So far, none (to my knowledge) has selected Rdb, but 
    we're working at it.

    Sybase performance on VMS is pretty poor. It's better on Unix, probably
    much better on Stratus where the Sybase architecture has been
    "tailored" to the hardware architecture.
    
    ---- Michael Booth

i've just completed a sybase conversion from unify/ultrix to sybase/vms;
a measure of performance was time to commit one particular transaction;
on the current system this takes 3-9 seconds depending on load; 

we were able to commit in 1.6 - 1.9 seconds for a larger workload by using the
following config;

	9 simultaneous commits; each is approx 60 sql verbs!
	3 vs3100s clients, each 35-40% cpu bound
	1 8000 w/ 288MB, 85-95% cpu bound

the customer likes our progress and has purchaed two 9210 to finish the work.
what we learned about the product (objectively)

	the maximum db size we can support without a redesign is ~500MB
	(assuming multiple db servers and REAL 2PC)

	in an update intensive application, it thrashes miserably the added
	memory (128MB) helped quite a bit

	under v3.2 a multi-file sybase db is 3 times as slow than if it were
	a single file; we're investigating v4.0

	there's no way to tune, debug, redesign stored procedures; also there's
	no way to export table definitions for a table restructuring; about
	the only thing you can do is to manual execute the the procedure thru
	isql (interactive sql util) with traceflags (set showplan on)

in all systems, we were the only user active

/los

    
    I have been the DBA for a Rdb-to-Sybase conversion for the last nine
    months.  Sybase is terrible on a VAX.  Please consider (if you can)
    another database system.  Some of the reasons that Sybase 3.2 and 4.0
    are performance dogs ( term 'performance dog' : slang for slower than
    slow) are
    
    o Sybase performs as a single process under VMS
    
    o Sybase locks only at the page level; it does not implement the VMS
      lock manager.
    
    o Sybase only supports B-tree indices; no hash indices are available
    
    o Most joins create a temporary results table in a separate database
      called TEMPDB.
    
    o Sybase completes the entire query before any data is passed back to 
      the user.
    
    o There is no dynamic space allocation.  One can not condense the size
      of the database.
    							..partee.. 

the selection of SYBASE was market driven, considering a majority of the
systems in this business segment (financial) are unix based. the way things
currently sit, we're finishing the sybase port; if performance becomes an
issue we have always considered Rdb a failsafe; however such a move/switch
is a very political one that we can't fight yet;

btw; the "S" in sybase stands for something else too ;-)

/los

Hi All

I too have Sybase on a customer site, arriving on the account after Sybase was  
decided on. That was history, thie followingis now. Currently the Server runs 
on a VAX 8700 one node VAXcluster. We are about to go to a two node VAXcluster 
with the second node, a VAX 6000-420 system. Beside the fact fact that we still 
have host based X.25 comms into the VAX 8700, I get the feeling that failover 
to the VAX 8700 if the 6000 goes down will take some re-coding on behalf of the 
Software Houses part.

Two immediate questions that arise are

- If two server processes are utilised, do these run ok with an SMP machine
- Is Sybase an even worse implementation than Oracle (V5) on a VAXcluster (and 
boy have I been thru the Oracle issue many times!)
- Do I read that with no dymanic allocation, we mean disk space. If so, I 
presume a re-create (larger size d/b) and reload is the recovery route (hope 
that makes sense)

Nice thing here is that this project has had another related project merged 
with the business (same customer), the second project have their database on 
good ol' RDB, so we have some leverage there at present. Given that situation, 
all knock offs (comments) welcome, good and bad,

Regards, Martin

    You can't have multiple servers with Sybase. It's a SINGLE SERVER! So
    forget SMP. On VAXclusters, you can use the "fail-over server" that
    will allow one node to monitor the activties of the database node and
    take over if the DB node fails. Of course, the fail-over server only
    works on one node, so if both the fail-over server node and the DB node
    crash, tough luck.
    
    As far as disk space, remember that Sybase has no multifile capability.
    In other words, you will be working with VMS bound volumes.
    
    Sounds like lots of fun, doesn't it?
    
    ---- Michael Booth

    
    Following is the text of a note I wrote to Sales when they asked for a
    quick comparison of Rdb and Sybase and the issues that a customer
    should reflect upon.  Hope this helps...!
    
    Cheers,
    
    Gil
    
    
    
                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     26-Jan-1990 12:47pm CST
                                        From:     GIL DAVIS
                                                  DAVIS.GIL
                                        Dept:     SCA Software Services
                                        Tel No:   (505)857-7245

TO: See Below

Subject: XXXXXXX XXXXXXXXX Database Decision

         Max,
         
         In answer to your request for a comparison of the Sybase 
         Database product and VAX Rdb/VMS, there are a number of 
         issues that need discussion.  I would suggest that a customer 
         consider the following when evaluating Sybase versus VAX 
         Rdb/VMS. 
         
         1. SMP Support - Sybase does not take advantage of Digital's 
         Symmetric Multiprocessing Technology.  This limits the size 
         of the SYBASE Server to the largest uniprocessor VAX.  The 
         SYBASE SQL SERVER is based upon a single-process (Server) 
         architecture to access the database.  Using this type of 
         approach works in a single-processor system, however 
         additional processors in the same cabinet (i.e. 6000-420) 
         provide minimal improvement in performance.  15% improvement 
         can be a surprise for the customer expecting 80-95% 
         performance improvement when investing in additional CPU 
         power.  There is a big difference in the statement "runs on" 
         a VAX, as in the case of Sybase, versus "takes advantage of" 
         VAX Architecture as in the case of VAX Rdb/VMS.  From a 
         Sybase product strategy standpoint this situation seems very 
         logical.  For them to invest in a special version of Sybase 
         which was tailored for SMP systems would be a major 
         undertaking, both in terms of cost and development effort.    
         Sybase has done some re-engineering to adapt to SMP, but the 
         product is still dependent upon a single database writer 
         which runs only on one processor at a time. While Sybase has 
         a product which can be sold on multiple platforms, it becomes 
         in effect a "lowest common denominator" product which doesn't 
         take advantage of the Multiprocessor VAX.
         
         2. VAXcluster Support - The Sybase database engine (Server) 
         does not run on multiple nodes in a VAXCluster, all accessing 
         the same database.  Sybase has stated that there is no 
         intention to have their product run on multiple nodes in the 
         VAXcluster.  This points back to the Sybase SQL Server 
         strategy and the major-rewrite of code that would be required 
         to take full advantage of a VAXcluster.  The strategy is to 
         avoid the use of a facility such as the VMS Distributed Lock 
         Manager (DLM) in the name of performance.  While Sybase will 
         point to the DLM as a bottleneck, in reality, the ability to 
         perform distributed lock management provides the path to 
         expansion beyond the uniprocessor database server.  The 
         database server can now expand beyond the single-processor on 
         a single node.  Many products (such as VAX Rdb/VMS, Ingres) 
         all use the DLM very effectively.
         
         3. Distributed Database - While Sybase claims to have a 
         Two-Phase commit protocol, it is implemented in a limited 
         fashion.   Digital will be announcing a true, two-phase 
         commit protocol, integral to the VAX/VMS operating system, 
         next month.  Also, there is no distributed dictionary 
         capability as is provided in VAX CDD/plus.  It is interesting 
         to note that in light of IBM's recent announcment of a 
         system-wide, distributed dictionary offering in two years, 
         industry analysts point out that Digital has that strategy 
         already in place in VAX CDD/Plus.  
         
         4. Vendor Support - The Sybase database product has it's 
         origins in technology originally conveived on a Britton-Lee 
         database.  Their base technology was then developed on a UNIX 
         platform and later ported to VAX/VMS.   The Sybase support 
         organization is staffed with primarily Unix-oriented 
         specialists who know little about the VAX/VMS environment.
         For a VAX/VMS customer, this can be a hardship.
         
         5.  Tools Strategy - A customer that chooses the Sybase 
         strategy of tools combined with database engine is forever 
         locked into the Sybase toolset (If all you have is a hammer, 
         then a hammer is the right tool, regardless of the job that 
         needs to be done).  Digital's strategy with VAX Rdb/VMS is to 
         provide an interface to our database engine that 3rd 
         party-vendors can layer their tools upon.  Tools such as 
         Smartstar, Ingres, Informix, Adabas, Powewrhouse... (Over 170 
         in all), all run on top of Rdb. The Rdb Solutions Vendor 
         Program (RSVP) has an average of one applicant per day 
         requesting information on how to make their product interface 
         to Rdb.  We can arrange demonstrations with numerous tool 
         vendors, providing customers with a broad range of solutions 
         to different business problems.   It is interesting to note 
         that of all the major database vendors, only Oracle and 
         Sybase have chosen to NOT have their toolsets access VAX 
         Rdb/VMS databases.  
         
         6. Database Engine Features - There are a number of database 
         management features for which there is no support in Sybase.  
         VAX Rdb/VMS support all of the features described below (and 
         many others): 
         
              o Dynamic File Allocation - Sybase requires a manual 
              intervention to expand a file that has attempted to 
              exceed it's initial space allocation. This means that 
              production is stopped while the database is made larger.   
              With VAX Rdb/VMS, this expansion occurs automatically, 
              online, dynamically, and without the intervention of the 
              Database Administrator as is required by Sybase.
              
              o Hash Index Support - Sybase offers only B-tree 
              indexing.  VAX Rdb/VMS offers both B-Tree and Hashed 
              indexes, providing an additional highly desirable 
              performance optimization feature not found in most other 
              database products.
              
              o Backup facility - Sybase has no database-specific 
              backup facility.  Their product is dependent upon the 
              administrator performing an export and then subsequently 
              using the VMS Backup facility.  VAX Rdb/VMS provides a 
              database specific backup facility (RMU-BACKUP) which can 
              perform both online and incremental backups and backup 
              to multiple simultaneous tapedrives in a VAXcluster.
              
         
         7. Open Architecture - While Sybase will claim that they have 
         an "open architecture" their claim is only valid as long as 
         the customer stays within the Sybase product set.  They do 
         provide a pathway to other databases, but it is up to the 
         CUSTOMER to develop the code required using a few 
         pre-packaged Sybase "routines" (3gl code).  There are 
         numerous standards committees involved with Forms, SQL, 
         Windowing, OSI, all of which are readily apparent in 
         Digital's product strategies.
         
         8. Cost of Ownership - Sybase is a little more expensive than 
         Ingres and a little less expensive than Oracle.  Sybase is 
         approximately 2-3 times the cost of VAX Rdb/VMS (Development 
         license) and impossible to compare in the Runtime version, as 
         VAX Rdb/VMS runtime is included with the VMS operating system 
         at no charge.  Choosing VAX Rdb/VMS as a strategic database 
         platform results in a much lower cost for the customer.  I 
         would be happy to help out with Cost-of-Ownership analysis of 
         this on any VAX platform.
         
         9. Maintenance - Sybase (like Oracle) charges approximately 
         15% of the initial license charge for the ongoing maintenance 
         of the product.   VAX Rdb/VMS maintenance is priced at 
         approximately 2.5% of the initial charge for the full 
         development license and is included with VAX/VMS for the 
         runtime component.  Usually customers will see a discounted 
         initial license charge and then an annual maintenance charge 
         which is based upon the full list price.
         
         In summary, there are numerous issues that must be considered 
         when choosing a database management system.   The ones I 
         touched upon in this memo are a small portion of a much 
         bigger picture.  The database manager is an extremely 
         strategic decision will drive the Information Systems 
         direction in a corporation for a number of years.  Digital's 
         database strategy provides a customer with the most cost 
         effective, flexible and powerful solution while taking 
         advantage of the VAX/VMS environment.
         
         If I can be of further help in presenting this strategy to 
         your customer, please feel free to call.
         
         Regards,
         
         Gil Davis
         Software Consultant
         Transaction Processing and Database

Distribution:

    re:.7  single server only; and providing hot standby in a cluster

    re:.8  v4.0 allow data segments and placement of 'objects' on any
    segment; however on the v3.2 product you can also create multiple disk
    'devices' and data will rollover onto them when the prior ones are
    full; one word or caution though is that in our testings we'e found
    that the performance suffers proportionally to the number of devices
    configured; collasping the database to a few spindles as possible is
    the clear way to go, better yet if it all fits on a single spindle.

    one word of caution; i've begun to see sybase tech reps recommend a 1
    minute checkpoint interval on database recovery; this implies that
    every minute (normally) a checkpoint is performed on the system; this
    sort of busy work incurred i view as a prelude to moving to nonDEC h/w;
    when i asked the customer why the change, they expressed the same
    question to sybase but didn't get a satisfactory answer; i then told
    them to re-ask the question until they felt satisfied.

    btw if your interested in db comparisons, we run a class here in nyc
    which compares 8 db products (sybase,oracle,ingres,rdb,db2,tandem,ca-db
    and turbo-informix)

    /los
    

    If the customer likes SYBASE for the user interface ( fastbuild?)
    the same product is available on Rdb/VMS - called UNIFACE.
    
    Open systems ..........

    
RE: .11    

>    If the customer likes SYBASE for the user interface ( fastbuild?)
>    the same product is available on Rdb/VMS - called UNIFACE.
    
     WHERE CAN I GET "UNIFACE" INFORMATION ?

     I NEED IT URGENTLY...

THANKS IN ADVANCE,

TOHRU

    it is all in softbase -from VTX
    
    good luck