Conference ulysse::rdb_vms_competition

Hello Michael,

Are you talking about Oracle*TPX, which is planned to be announced by
Oracle Corp. in the fall of 1987 ?

If it's the case, first of all one must remember all the questions that 
an anouncement usually raises :

- at what time will the product actually be available ?
- will it really be as good as it intended to be ?
- ...

Second, the last version of Oracle (ie 5.17) shew that a new version can
sometimes be less performant than the previous one (ie 5.16).

Third, I guess "Rdb" plans to set sights on OLTP too, according  to the
objectives of the future versions (3.0 and higher...).

I had recently received a document (Oracle internal use only, of course...)
which briefly describes the new product Oracle*TPX.

It seems to target real OLTP applications with high volumes and transaction 
rates.

Here is the beginning of this document. If you don't have the following, I
will add it in a reply.

-------------------------------------------------------------------------------
ORACLE*TPX

Oracle Corporation, the market and technology leader in relational database
management systems, plans to announce ORACLE*TPX (Transaction Processing
Accelerator) in the fall of 1987. ORACLE*TPX will be the premiere database
management system for high volume, multi-user on-line transaction processing 
(OLTP) applications, information centers, and other large database applications.

This ORACLE*TPX breakthrough in relational database technology will provide
users with very high transaction rates, a powerful procedural language, and
nearly continous use of their database. Oracle has thoroughly redesigned over
one third of the database code to widen the technological lead ORACLE has
over competitive database management systems.


Follow some other information about :

- ACCELERATED TRANSACTION PROCESSING

- PROCEDURAL TRANSACTION PROCESSING

- CONTINUOUS DATABASE OPERATION

- ENHANCED DBA FACILITIES

- PRICING AND AVAILABILITY

--------------------------------------------------------------------------------


Well, perhaps we are going to be far behind.
But perhaps we won't.

In any case, assertions like :

"Oracle Corporation, the market and technology leader in relational DBMS",

"widen the technological lead ORACLE has over competitive DBMS",

sound very close to the report that was made after a benchmark between Oracle 
and Rdb (where Oracle won, of course...it's been put somewhere in this 
conference, I think it's in note 14).

So I personaly keep my eyes wide open and wait for what's going to appear, but
until then I don't want to believe that Rdb will be far behind, especially if
the competitor's name is Oracle...
 
Regards,

		Jean-Michel
                    

      I'm sure Oracle* TPX is the product the magazine was addressing.
    I probably shouldn't have been moaning about being behind again.
    We've done great things with Rdb performance over the past 12 months,
    and I'm sure it will continue to improve. But for the moment it
    does appear that Oracle has leap-frogged us. 
      Incidentally, I've heard transaction rates on TPX quoted everywhere
    from 25 TPS to 200 TPS. Anybody have any hard evidence of the
    performance expected from Oracle * TPX.
    
    ---- Michael Booth

Hello,
    
    As some people mailed me to have the additional information about
    ORACLE*TPX, here is the little I have.
                                 
    
Regards,
    
    	Jean-Michel    
    
    
-----------------------------------------------------------------------------   
    ORACLE*TPX

--------------------------------------------------------------------------------
Oracle Corporation, the market and technology leader in relational database
management systems, plans to announce ORACLE*TPX (Transaction Processing
Accelerator) in the fall of 1987. ORACLE*TPX will be the premiere database
management system for high volume, multi-user on-line transaction processing 
(OLTP) applications, information centers, and other large database applications.

This ORACLE*TPX breakthrough in relational database technology will provide
users with very high transaction rates, a powerful procedural language, and
nearly continous use of their database. Oracle has thoroughly redesigned over
one third of the database code to widen the technological lead ORACLE has
over competitive database management systems.


ACCELERATED TRANSACTION PROCESSING

Ten-Fold Increase in Transaction processing throughput :
------------------------------------------------------
ORACLE*TPX speeds transaction processing with up to a ten-fold increase in
transactions per second over ORACLE version 5 through :

	. many fewer disk writes when committing transactions,
	. less contention among users modifying rows in a table,
	. faster location of rows and index entries,
	. reduced data dictionary locking,
	. more efficient VAXcluster support.

Ten times as many simultaneous Users :
------------------------------------
The above improvements enable ORACLE*TPX to supportr up to ten times as many
simultaneous users as ORACLE version 5 in transaction processing applications
on large computers.

More granular control of transactions :
-------------------------------------
In addition to commiting or rolling back entire transactions, ORACLE*TPX can 
roll back a single statement or set of statements to provide better control 
over transaction execution.
                                                                            

PROCEDURAL TRANSACTION PROCESSING
 
Faster transaction processing :
-----------------------------
ORACLE*TPX includes PL/SQL, a portable procedural transaction language fully
integrated with SQL. In PL/SQL, a single database request executes a multi-
statement transaction entirely within the RDBMS. In a distributed environment,
this single request substantially reduces the amount of communication across
the network interface.

Expanded RDBMS Language Functionality :
-------------------------------------
PL/SQL adds powerful functionality ti the SQL langage with :

	. full procedural language capabilities,
	. variable references in SQL statements,
	. user-defined PL/SQL datatypes within a procedure.


CONTINUOUS DATABASE OPERATION

Less scheduled downtime :
-----------------------
ORACLE*TPX offers the following features to decrease business interruptions
caused by mandatory database shutdowns :

	. on-line backup of entire or partial database,
	. space-efficient on-line media failure protection,
	. on-line media failure protection for VAXclusters.

ENHANCED DBA FACILITIES

Increased DBA control over space use :
------------------------------------
ORACLE*TPX gives DBAs more control over database space. They can better 
regulate storage costs and reduce maintenance efforts resulting from rapid
database growth with :

	. space allocation quota for each user,
	. table storage parameters that can be modified at any time,
	. incremental export of recently modified tables.

30% reduction in space use :
--------------------------
ORACLE*TPX reduces storage costs by using 30% less space than ORACLE version 5
for a typical database with :

	. much smaller recovery logs to protect media and memory,
	. better use of space freed by deleted rows and indexes,
	. more compact storage of clustered data.

Improved database control and performance analysis :
---------------------------------------------------
ORACLE*TPX provides enhanced DBA utilities for better database control and
performance analysis. These supports :

	. interactive database maintenance,
	. startup and shutdown of remote databases,
	. useful performances statistics (e.g. I/O counts, cache hits...),
	. performance statistics queryable from remote nodes,
	. secure access to all performance statistics.

PRICING AND AVAILABILITY 

Pricing and packaging for new or existing ORACLE users is being finalized.

The Product Management RDBMS Group is selecting Development Partners to alpha
test ORACLE*TPX during the summer of 1987. To nominate Development Partners,
call David Martin at (415) 598-8098.

ORACLE*TPX will be ported to all ORACLE environments and will be compatible
with current and future Oracle products.
--------------------------------------------------------------------------------

    
    
    	I do not think, that we are behind again;  
    	ACMS is working very fine with DBMS and Rdb/VMS in a
    	VAXCluster- and in a distributed environement since nearly 2
    	years ago !
    	
        DBMS V3.3 is achieving up to 46 DEBIT/CREDIT TPS in a 3 node
    	8650 environement, without using ACMS. You certainly can increase
    	this numbers by using ACMS.  
    
    	This numbers a real measured; not a goal :-))
    
    
    	R�diger
    

    Hello,
    
    I'm very interested in the results you've just mentioned.
    Could you give more details about the environment in which one could
    get 46 TPS (database size & number of disks, number of active users, 
    response time ...) ?
    Do you know whether some tests have been conducted with Rdb (2.2
    or 2.3) in a similar environment ?    
    
    Thank you in advance !
    
    Regards,
    
    		Jean-Michel
    

      Are we knee-jerking again? I mentioned a relational database,
    Oracle, which is coming to market with a high-performance RELATIONAL
    model. A couple of the replies indicated we are not behind, because
    our Codasyl model will perform at a high level. That's a real apples
    to oranges comparison.
      My comment regarded RELATIONAL performance. I know that DBMS
    performance is excellent. But you cannot compare a combination of
    a TP monitor and a Codasyl (plex, network, whatever you want to
    call it) database to a relational model on performance.
      The point of the original note was a comment regarding the lag-time
    between the release of the new Oracle product, and the release of
    Rdb v3.0. It was intended as a "warning" to be aware that Oracle
    is ahead of us in releasing the high-performance RELATIONAL product.
      
    ---- Michael Booth

>>      The point of the original note was a comment regarding the lag-time
>>    between the release of the new Oracle product, and the release of
>>    Rdb v3.0. It was intended as a "warning" to be aware that Oracle
>>    is ahead of us in releasing the high-performance RELATIONAL product.

Michael,
      
I think that after 3 tries, you made your point clear...(it's
been clear since the beginning, for my opinion...).

I personaly never meant to compare any apple to any orange.

I was just asking for details about those 46 TPS with DBMS.
If you meant by "irrelevant" that the note should have been 
introduced in the DBMS notesfile, I agree. But I think it's 
a valuable info wherever it may be...

A question now : 
--------------

Do you have any (precise) idea of the date when Oracle WILL
release their new Oracle*TPX OLTP product, and of the lag-time
between this release and the release of Rdb 3.0 ? 

Thanks for help,

Regards,

Jean-Michel	

      The timetable I have seen indicates Oracle will release their
    product in "early 1988". I would estimate such a release will put
    them about 5 months ahead of us.
    ---- Michael Booth
    
    P.S.
    I wasn't hitting you about your DBMS entry. It should have been
    prefaced with RE: .4. That was the rep which mentioned DBMS
    performance, which in this case is an invalid comparison.
    I'm very interested as well in the particulars of the benchmark
    with DBMS. I haven't heard of numbers that high for DBMS.

ORACLE hasn't even ANNOUNCED their TP-oriented software.  They are just
running around telling everyone what they are going to do in the future.
We tend not to provide such advanced warning.  We also tend to be very
conservative in our performance claims, and in most everything else.
Conservative is not a word that ever applies to things ORACLE tells the
world.

On top of all that, even if they were going to ship something in advance
of V3.0, 5 months is a pretty small amount of time to be worrying about.
Now if they were doing something a couple of years in advance I would be
worried.

Absolutely agree, Hal. 
I remember they had something about *REAL* distributed databases in 
their flyers and had to remove it, because they couldn't do it.

Gerold

    I just attended a presentation of oracle TPS ( TPX was already used by
    someone else ) last week.  It will almost certainly be released before
    May which is ORACLEs business year end.  The increase in throughput is
    basically achieved by writing only the bytes changed to disk rather
    than blocks.  this will also greatly reduce the size of the BI file and
    AIJ files.  The scary part is the report writer and query by example
    packages that will be available according to them by May.  The main
    complaint with ORACLE by most users it the lack of a good report
    writer.  This one is being demoed on a SUN workstation and is supposed
    to be very slick.  Also some big enhancements to SQL*FORMS to be added
    by MAY.  If the Report writer is as big of an improvement as SQL*FORMS
    2.18 it will be a major selling item.  This report writer is not to be
    intended for use by end users.  For that they have a query by example
    that is almost a copy fof IBM's query by example.  The procedural SQL
    will look a lot like ADA and will be available only with TPS.  Oracle V
    6 will also be available in MAY.  The only real important issue they
    were not able to address was after image journaling on VAX clusters. 
    
    In response to a real distributed database Catapiller Corp is claiming
    to be running oracle in a distributed design on IBM connected to DB2
    with sql*connect and on VAXes and APOLLO workstations with databases
    residing on all nodes using HYPER BUS by NETEX for the communication
    medium.  Also the Processing of the screen programs is being done with
    PC's networked with The entire system.  I haven't seen or talked with
    anyone who has but have heard fairly reliable reports that they are
    very pleased with it. 

    Re: .11
    
    The new Oracle report writer and query by example are quite likely
    to be similar to DEC's offering.  Both DEC and ORACLE several years
    ago acquired the rights to develop products based on ALLY, a 4GL
    originally written by a software house in North Carolina (which
    has since been bought out by UNISYS, but that's another story).
    About a year and half ago DEC released RALLY version 1.0, based
    on ALLY, and with added functionality including support for Rdb.
    On that basis DEC is 2 years ahead of ORACLE.  By the time ORACLE ships
    version 1 of its product, RALLY version 2.0 will probably have been
    released.  While ORACLE's product may have some additional
    functionality after these 2 years, so will RALLY version 2.0 (in
    RALLY's case many of the improvements have been motivated by the
    response in the field to RALLY version 1).
    
Lew Lasher
VAX RALLY development

Unfortunately, it takes more than a good technical solution.  We may indeed
be ahead of ORACLE technically, but that's academic if the customers don't know
it (or don't care).  Like it or not, what counts is customers' perceptions.
This is partially a marketing problem, and partially an engineering problem.

We have a problem when competing with people like ORACLE who sell their
products as an integrated set (they may or may not actually be integrated, but
that's what their pitch is), when we have what appear to be different products
produced by different groups, orderable under different Q numbers (or DO we
have a package that is orderable under one Q number that includes both Rally 
and Rdb/VMS ?), etc. Teamdata and Rally may indeed be as well integrated with
our underlying database as ORACLE's, (Are they ?  I really don't know.) but the
customer's perception may be different. 

Also, are you suggesting that Rally be the report writer that we propose
when we bid against ORACLE ?  I don't know the price figures, but it would
seem to me that that would be a little like using a sledgehammer to crack
a walnut, since Rally is much more than just a report writer, and presumably
costs correspondingly more. 

Then there is the question of integrated forms support, and many of the same
questions arise there, too.  (I know that Rally does forms, too.)  DEC has
for some time had a considerable credibility gap in the forms area.  I truly
hope that VAXForms will solve this problem (especially since it is supposed to
conform to the proposed forms standard (ANSI ?) ).  ORACLE, however, can
boast that they have an integrated forms product now.  To get the same from
DEC means you must either buy FMS or TDMS, which appear less than integrated,
and have not shown a great deal of support from the corporation, or Rally,
which may be more than the customer wants (and may cost too much, and may not
be 'standard' (?) ), or wait for something in the future.

I would be interested in comments from people out there in the real world about
how you sell against ORACLE and INGRES with their 'integrated set of products',
with our current products.  Do you see the credibility problems, or is there an
effective way of countering their message ?  What solutions would you like to
see ?

>    ORACLE and INGRES with their 'integrated set of products'...
                                                                 
    I think that the constrast between our mix'n'match approach and
    the apparently more integrated offerings of companies such as the
    ones mentioned is a good subject for discussion. So good, in fact,
    that I'll start a new topic for it to avoid it getting lost in this
    topic.
               
    'Next unseen' and you'll be there.
    
    	Andrew.

	re.4 and add to .3

	I know, that the comparison of Rdb/VMS and DBMS is comparing
	apples and pears.
	The complain, was that we do not have products for the OLTP-market;
	what I am only saying is that we have the products with ACMS in 
	conjunction of Rdb/VMS and DBMS, and DBMS is able to deliver 
	the TPS-rate mentioned in my note. The TPS are DEBIT/CREDIT ones.
	The benchmark was done by Steve Klein.

	R�diger

    
    Oracle*TPX aka Oracle*TPS now seems to be SQL*TPS. Claims at Oracle
    seminars have been downgraded recently from 10 times version 5
    performance at 28 TPS. Does this mean the current version is only
    2.8 TPS? THe next claim was 8 and then 6 times faster. Can you say
    'backpeddal'?
    
    It has also been rumored that the reason for SQL*TPS delays is that
    Sybase performance numbers are much better. SQL*TPS was aimed at
    DB2, but they can hardly lose in their own back yard and save face.
    So release in fall of '87 as first announced may not even become
    real in the spring of '88 unless there is significant revenue on
    the line based on TPS sales.
    
    Also note that several things like space management, online backup,
    etc. which are being integrated into Digital database offerings
    are extra cost items with Oracle. SQL*TPS contains much of which
    should be part of the standard data base package. This gives us
    a tremendous price advantage and integration message.
    
    Jamey Nordby