Conference ulysse::rdb_vms_competition

    Let's try some reality here. Oracle began developing better performance
    about two years ago. Their development cost was so high that they
    chose to package the performance improvements seperately so that
    the current user base would have to BUY the new performance.
    
    As far as we can tell, TPS has rwo-level locking, the new PL/SQL
    language that taps into the re-written kernal, and a re-do log that
    reduced journaling activity, but makes recovery more difficult.
    
    Version 6 Oracle itself has almost no performance enhancements.
    It is more of a bug-fix release than anything else.
    
    Their big performance numbers came on a VAX 6240 with NO USERS,
    simulated otherwise. Consequently, the numbers are meaningless.
    The high user numbers are the result of TPS using client/server
    architecture. Just as Sybase quotes large numbers of users, so does
    Oracle. It is very unclear what users would be doing to have that
    many of them on an 8820. Maybe they are just doing queries. That
    could explain it.
    
    In view of the fact that Oracle's latest benchmarking is sooooo
    suspect, I would question any and every number and statistic they
    present.
    
    ---- Michael Booth

    Thanks for the input in .1
    
    Following from this,
    
    1/ What exactly is Client/Server architecture and potentially why
    can this support 'more users' than perhaps a non-Client/Server
    arcitecture.
    
    2/ Does RDB use a Client/Server architecture and what are the arguments
    for/against the use of this approach.
    
    3/ What is PL/SQL (I know I could ask ORACLE but I dont have a
    contact!).
    
    Regards, Stefan (Learning fast...)

    Client/server should enable more users to be on the system, assuming
    the server is multi-threaded. Essentially what this does is allow
    multiple users to access the database via a single server process,
    rather than generating multiple database binds and a single process
    for each user. That should significantly reduce system overhead.
                                  
                                  
    PL/SQL (Performance Language/SQL) is Oracle's new programming language
    for gaining high performance applications with the Oracle RDBMS.
    The story currently circulating is that PL/SQL has some substantial
    inconsistencies with SQL*Plus, which many Oracle accounts have used
    to write pre-compiled queries and reports. Many of those SQL*Plus
    routines will have to be rewritten if they are to be compatible
    with PL/SQL.                  
                                  
    I'll let someone else tackle the pros and cons of client/server
    architecture.                                  
                 
    ---- Michael Booth

The customer  benefit of client/server architecture are nebulous at
best.  To understand why some of the current vendors are pushing it so
heavily right now, one has to look at their old architectures.  In most
of the old architectures, I'll use INGRES as an example.  In INGRES,
each user application process fired up a subprocess to perform the
database access.  So, for every user you had 2 processes:  The
application and the database.  This uses lots of resources.  In a
client/server model (at least as the terms are used by most of our
database competitors) there is a single MULTI-THREADED back-end process
that each user application program talks to, thus cutting the total
number of processes in half and saving lots of resources.

Now, Rdb/VMS uses neither of these techniques.  Instead, the Rdb/VMS
code runs as a privileged subroutine library inside of the users
application program.  Rdb/VMS achieves data integrity and security, not
by running in a separate process, but by using the VAX hardware
protection modes (just like RMS and other components of the VMS
operating system).  So, we avoid the interprocess communications between
the application program and the database code, as well as the single
back-end process.  Want other reasons for avoiding the single backend
process?  Well, in an SMP environment the the single back-end process
can only run on one CPU at a time.  So, if the back-end takes more than
1 CPUs worth of horsepower then adding more processors DOESN'T HELP.

So, why have so many vendors gone to the multi-threaded back-end model
over the Rdb/VMS approach?  There are two reasons:

1) Portability: By running all the database software in a backend process
they can avoid using some operating system services which may not have
equivalents on other operating systems.  Also, the Rdb/VMS approach
makes use of VAX-architecture specific features and a couple of
undocumented VMS interfaces.

2) Ease of Implementation: Certain algorithms are easier to implement
when you don't have interprocess coordination.  Moving all of the
database code into a single back-end eliminates this coordination while
permitting these high performance algorithms to be implemented.

Obviously, we have invested (and will continue to invest) the time and
effort to get the advantages of the latest algorithms AND the privileged
run-time library architecture.

    RE: .4
    
    Thanks for a most lucid explanation.  --- Stefan (Now Enlightened!)