Conference ulysse::rdb_vms_competition

    Oracle V6 just went to production about 3 weeks ago. It still will not
    support VAXclusters in the sense of running simultaneous access on more
    than one node. The Oracle person usually says "Sure it supports
    VAXclusters" meaning that the Oracle RDBMS can indeed run on one
    cluster node.
    
    As far as SMP, the Oracle database processes (it is still a detached
    process database) run on one processor. Even if this Oracle person were
    right and I/O database processes could be started on other processors,
    the locking would still be controlled on one processor. As we
    understand it, the Oracle RDBMS processes (5, I think) all execute on
    only one processor in an SMP arrangement. Were that not true, why has
    Oracle released no performance information for SMP systems with real
    interactive users. Clearly Oracle could do so if they had such
    information. If you believe the Oracle rep, just ask for references and
    talk to them.
    
    I will bet that he will stand by his statements...but be unable to
    furnish a reference site.
    
    ---- Michael Booth

>>    The customer is not at all disposed to junk what they have developed
>>    and do it again based on RDB.

It is their only chance to provide a good growth alternative.  Rdb will let
them do VAXclusters, you'll never get there with oracle of any flavor.
    
>>    We are now in a position of having to compete with Unix Hotbox
>>    Suppliers, HP etc for the business for the 20 sites.

We are too.  Sequent and Bull's XPS100 are forcing us to discount heavily.
    
>>    Our salesman had heard a lot of internal stuff about Oracle not
>>    running in clusters and performing poorly in SMP configurations
>>    so he got hold of an oracle support guy locally who told him :-
    
>>    (1)That Oracle works fine in clusters 

The Oracle rectimoid lied !!!  Push back !!  Ask oracle for references and
watch them sweat.

Please read notes 397.3, 367.2, 295, 273, 207, and 206.5 for more information
on Oracle in VAXclusters.  

"works fine" is subject to interpretation (tastes great or less filling ?) but
let me pose the following question:  If running Oracle V5.1.22 in SHARED MODE
in a VAXcluster caused your DIOs to increase 3-5 times the non-cluster
performance AND tripled the SCS message rate on the CI, would you call that
"fine" ???   Oracle V6/TPO V6.0.26 DOES NOT run in SHARED MODE (Oracle term) in
a VAXcluster .... period !!!   Push back !!
    
>>    (2)That Oracle is magic in SMP. In fact it will run better in a
>>    multi processor configuration that in a uni-processor with equivilant
>>    power.

NO NO NO !!!!  This guy is a rookie and is caught up in the Oracle magic
himself. Please read notes 349.2, 349.4, and 324.1 for a discussion of Oracle
on SMP. Oracle uses detached processes to do reading and writing to the
database.  Think about what that means.  At any point in time, the DBWR (Oracle
V6 database writer) can ONLY execute on a single VMS CPU within an SMP systems.
Consequently, the DBWR is only as powerful as a single cpu (6.0 in 88xx
systems) vs the entire system.  The oracle detached processes are not
multithreaded AND DO NOT run in parallel.  Push back on the Oracle guy and tell
him his new-hire training is over and it's time for him to face reality about
his product.

>>    Until now I have believed that 
    
>>    (1)In clusters
    
>>    		At Version 5 Oracle can share a single database over multiple
>>    		nodes of a cluster but that synchronisation between
>>    		the database servers has to be done by writing information
>>    		to disk therefore it is going to be pretty slow.

Absolutely.  Think what this would be like in a local area VAXcluster.
    
>>                At Version 6 Oracle cannot share a database between
>>    		multiple nodes in a VAX Cluster. 

IN SHARED MODE.  This is really important because without the SHARED MODE
requirement, Oracle will be free to configure network or standalone access.
    
>>    (2)In SMP
>>    		Oracle has a single database server. Oracle will run
>>    		in an SMP configuration but the database server will 
>>    		run in only 1 processor. This is OK up to a point but
>>    		a situation with Oracle can develop where that single 
>>    		processor cannot service all the requests being made 
>>    		of the database. The only solution to this problem is 
>>    		to swap in bigger processors (i.e. extra processors
>>    		added to the system will have no effect). The Oracle
>>    		guy says that a separate task ? is created on each 
>>    		processor in an SMP configuration to handle database IO

The Oracle new-hire guy is confused between SMP and VAXclusters.
Cmon' YOU know better than that !!!  You can't specify which processor
board  in a 6330 that a program is to execute on .... VMS decides, NOT
the developer, NOT the DBA, and certainly NOT Oracle.  You are right,
only bigger CPU boards or larger uniprocessors will help.  

Oh, yeah, extra processors will help all the application programs run faster to
the point where they must wait for the Oracle detached processes to load and/or
write the SGA cache to/from disk.  Think of it like this ... you got 10 people
running 100 yard/meter dash.  They all go like hell to the finish line but can
only cross one at a time in lane 1.  Push back !! 

    
>>    As I have already said we are constrained to bid systems to run
>>    Oracle but one of the customers requirments is to be able to increase
>>    the capacity of each system proposed by 100%.                    

Let's see ... if you started with a 6210 at 2.8 VUPS, you would be able to
show upgrade paths to 6000-410 at 7 VUPS.  Looks like that is your answer 
since VAXclusters ain't. Push back and MAKE Oracle give you something in
writing.

>>    Because the customer is trying to tie us up in contractural commitments
>>    we have to be very sure of our information i.e. is what I have written
>>    above correct ?

Unless you are the prime on this, I would put weasel words like crazy in 
the document and point the finger at Oracle in all cases.  

Good luck and remember, PUSH BACK !!!

-- gerry                                                                

    

    Once again from "O" advertising:
    
    "And since ORACLE is optimized for the DEC/VAX architecture, you can
    count on mainframe-class OLTP performance when the Rigel and Aridus
    Symmetrical Multiprocessing (SMP) systems are introduced."
    
    Infers SMP support, which sounds like full support when first read.
    
    The reduction in licence costs might well pay for the conversion excercise
    (if 3GL code)!.
    
    Cheers, Martin

    Re .1,.2 and Oracle's Detached Processes on SMP
    
    If what I understand is correct, that Oracle uses separate dedicated
    processes to do all reads, all writes etc, then why cannot that use
    SMP? In a dual processor configuration couldn't one processor be
    running the reader process for some read operation, while the other
    processor is running the writer process? Or am I missing something...
    
    John.

    After a lengthly discussion with my customer's Oracle DBA, he convinced
    me that each user attached to an Oracle V6/TPO database does in
    fact do his own reads from the database pages.  There is, however,
    still only one database writer task and it is a detached process
    named DBWR.

    This whole thing about Oracle and SMP seems to be mis-understood
    which is where Oracle wants us and the market to be.

    You are correct in that the V6/TPO task DBWR AND the user programs
    can, in fact, run on different CPUs in an SMP environment.  I have
    observed this.  The point about SMP is that with Oracle's architecture
    (ie the database writer DBWR detached process) their total throughput
    will never be able to run as fast as Rdb since Oracle has only
    one writer to the database where Rdb has n writers to the database.
    (This is also a potential problem with Ingres and Sybase.)
        
    So, if you had an application which was heavy insert and/or update
    and you sized a 6000-430 because it is listed around 19 VUPs, you
    could get burned because the DBWR Oracle task runs only on one
    processor at a time (7 VUPS).  Thus for write performance, Oracle
    has the problem (at least in theory) that it will never have better
    WRITE performance than a 6000-410 no matter what model of 6000 you
    quote.  Rdb, on the other hand, can have many writers to the database
    and can provide write performance of 19 VUPs on a 440.  
    
    Hope this helps.
    
    -- gerry
    
    (Oh by the way, I had a chance to browse through Oracle's object
    libraries recently and noticed a routine named KSMP in their
    kernel library.  Looks like they may be working on something.)

    

    We decided to try and get the Oracle position from the horse's mouth.
    We visited the local Oracle office to discuss the best configurations
    to bid.
    
    This is what they told us :-
    
    (1)Clusters
    
    (1.1) Oracle V5.1.22
    
    Oracle V5.1.22 works in shared mode in CI clusters. (This version 
    is OK for our customer).
                               
    Oracle V5.1.22 does not work in LAVCs (anyone know why not ?)
    
    They do not know if V5.1.22 works in dual-host micro vaxes (anyone
    know if it does ?)
                                                 
    They also said that V5.1.22 uses Distributed Lock Manager.
    
    Now as the salesman said this and his techie nodded agreement I
    had a good idea they were lying to me but how can I prove it.
    
    If I am in a competitive situation and I say 'the version of Oracle
    which runs in clusters does not use DLM' then the Oracle guy comes
    in and says to the customer 'yes it does' who does the customer
    believe ?
    
    Is there any documentation available (preferably from Oracle) which
    says how they do achieve locking in a cluster with V5.1.22 or is
    there some other way to convince our customers that we are telling
    the truth.      
    
    (1.2) Oracle V6 with TP%
    
    The code for V6 which works in clusters is now written and goes
    into Beta test 'next week'.
    
    It should be available to customers within 6 months. 
    
    This seems to conflict with what we are saying. Does anyone know
    what the real position is ?
    
    
    (2)Oracle and SMP
    
    The Oracle guys say that Oracle is made up of a number of detached
    porcesses (5 they think !) one of which is the database writer.
    All user processes can do their own database reading.
    
    They say that in most applications reading and writing will balance
    out and no single process will be swamped.
    
    They refuse to accept that even in a very heavy write-biased
    application that the single database writer will become a bottleneck.
    
    Once again who does the customer believe ? 
    
    Do we have any data to support what we say i.e. that Oracle's single
    database writer can only run as fast as 1 processor in an SMP
    configuration and that a queue of database writes will build up
    in a heavy write-biased applications ? 
    
    
                                                                    
    Angus

    As to the lock manager...If Oracle uses it, they should then have
    automatic recovery in a cluster, right? But they don't have automatic
    recovery. Why?
    
    Why must we disprove what Oracle says? It seems rather sensible to
    believe that the right process can be swamped since it only runs on one
    processor. That's self-evident. To believe otherwise, one must assume
    that reading is more resource consumptive than writing. That is absurd.
    
    Clusters with V6. beta-test now...production in 6 MONTHS. This seems
    like either a desperately long beta-test or an inability to add the
    code to the current Oracle product.
    
    In other words, to defuse these issues, it requires deductive reasoning
    and questions. I don't see how we can "disprove" them other than
    suggesting that they are logically unsound.
    
    ---- Michael Booth

    (1)Clusters
    
    (1.1) Oracle V5.1.22
    
    Oracle V5.1.22 works in shared mode in CI clusters. (This version 
    is OK for our customer).
                               
>>    Oracle V5.1.22 does not work in LAVCs (anyone know why not ?)

Why don't we let Oracle explain this.  But, this is wrong !!!  I have a
customer using Oracle financials in a LAVC (MVII, MV2000, MV3300) with Oracle
5.1.22 AND IT RUNS.  In addition, they were doing development on a LAVC (MVII
and MV2000) and it works. 

If your customer knows VMS, VAXcluster software, etc, think how stupid
Oracle must seem to him to suggest that it runs OK in one VAXcluster but
not in another type of VAXcluster.  All of the components below Oracle are
the same for both.  Stop right now and think about this ...... 

>>    They do not know if V5.1.22 works in dual-host micro vaxes (anyone
>>    know if it does ?)

For heaven's sake.  A dual-host MicroVAX can be used in two ways.  1) is when 
they are being used as file servers for workstations.  In this scenario,
if one of the uVAX servers fails WHILE SERVING A WORKSTATION, the other
uVAX in the VAXcluster will continue to serve the workstation.  
2) As a local area VAXcluster, the dual-host works the same as any other
VAXcluster except that the disks are not MSCP served and are available
to the surviving uVAX even in a VAXcluster state transition.

So the answer is, "of course since the dual-host IS a local area VAXclsuter".
Now, Mr. Oracle, what's wrong with 5.1.22 in a local are VAXcluster?

>>    They also said that V5.1.22 uses Distributed Lock Manager.

I don't believe this is true.  My source says 5.1.17 used DLM for its resource
locking (tables, partitions, etc.).  Then in 5.1.22, Oracle used another
method (disk marking) for resource locking.  This is a great example of how
Oracle can twist the terms.  

As you know, in normal applications, when I ask to read a disk record, block of
records, etc., VMS will automatically take out locks in my behalf.  I don't
have to do anything.  When Oracle does disk I/O, it gets MANY records
(resources).  At this point ALL VMS knows is that Oracle has read 50 disk
blocks.  VMS (and the lock manager) have no idea what is in those disk blocks. 
Now, with that background, here's how you ask this question: 

"Mr Oracle, when I have two programs trying to update records in the SAME
table, what mechanism does Oracle use to lock the table so one updater won't 
clobber the other updater ???"  (FYI, Oracle 5.1.22 has table locking NOT
row locking.)

"What image name or library routine does Oracle use to take out the lock on
table x and to manage the locks and the queueing. ?? In what image name or
library routine does Oracle call VMS ENQ and DEQ system service routines
in order to do Oracle table and resource locking ??"

    
>>    Now as the salesman said this and his techie nodded agreement I
>>    had a good idea they were lying to me but how can I prove it.

I usually tell the Oracle techie to go do his homework and remind them
they can't know too much since they have to learn ".. over 70 platforms ".
    
>>    If I am in a competitive situation and I say 'the version of Oracle
>>    which runs in clusters does not use DLM' then the Oracle guy comes
>>    in and says to the customer 'yes it does' who does the customer
>>    believe ?

I usually handle it this way. "You know Mr Customer, I guess it really
doesn't matter if Oracle uses the DLM or not.  What IS important that
Oracle runs as well in a VAXcluster as an RMS based application.  Also,
Mr. Customer I think you should know that our experience with other
Oracle customers indicate a discrepancy in Oracle's statement which could
affect your system either in terms of performance or recovery or both.
Ultimately you have to be satisfied with the response to this issue
even if I am not."  And then I let it cook a while.
    
>>    Is there any documentation available (preferably from Oracle) which
>>    says how they do achieve locking in a cluster with V5.1.22 or is
>>    there some other way to convince our customers that we are telling
>>    the truth.      

Oracle does not publish internal at all.  (If they did we could expose them
even more !!!)  Your relationship with the customer will decide who he
believes.  If you can prove Oracle wrong just once (and you can with the
LAVC 5.1.22 issue), you should be in a stronger position.
    
    (1.2) Oracle V6 with TP%
    
>>    The code for V6 which works in clusters is now written and goes
>>    into Beta test 'next week'.

Ah yes, the old "next week" line right out of Oracle sales 101.  I've heard 
that crap in three sales calls.  Ask the Oracle guy the name of the customer,
how many beta (non-Oracle) sites there are.  Ask him the results of Oracle's
internal testing.  Ask him what mechanism Oracle is going to use to manage
the locks on rows.  Ask him what mechanism Oracle is going to use to
give read consistency across VAX nodes using rollback segments.  (Oracle
gives read consistency to a program by reconstructing records from global pages 
and rollback segments.  So, if two nodes are updating the same table, pieces of 
the same table will be in two system's global sections.  Since Oracle doesn't
write records to disk at commit time, how will they provide the updated records 
from one system's memory to an application running on the other system?  Think
about this and remember that global sections are local to one node only.)
    
>>    It should be available to customers within 6 months. 

Available.... maybe.  How many would be willing to use it !!
    
    This seems to conflict with what we are saying. Does anyone know
    what the real position is ?
    
    
>>    (2)Oracle and SMP
    
As far as I can tell, Oracle does nothing with SMP.  Specifically, I 
don't believe they link to the VMS parallel runtime library.

>>    The Oracle guys say that Oracle is made up of a number of detached
>>    porcesses (5 they think !) one of which is the database writer.
>>    All user processes can do their own database reading.

Tell them to do their homework.  V5.1.22 uses four (ARH: async read ahead,
BIW: before image writer, BWR: database and journal writer, CLN: cleanup 
after failed process)  Page 11 in Version 5.1 DBA guide.

V6.x uses five (LGWR: redo log writer, DBWR: database writer, ARCH: archiver
SMON: system monitor, PMON, process monitor)  Note that the ARCH is not 
active unless you are archiving redo logs to tape.

Remember that you get these 4 or 5 processes for EVERY database you're using.  
For example, my customer has 4 databases in production and they get 20 VMS 
processes running EVEN when noone is logged on.

>>    They say that in most applications reading and writing will balance
>>    out and no single process will be swamped.

Well this may be true but all you want to do is get them to acknowledge that
IN THEORY the DBWR and/or LGWR can become bottlenecks.  The more important
issue is that the DBWR can only run on a single processor in an SMP box. 

Here's how it probably works.  Your program commits a transaction.  An Oracle 
routine you've linked which does the commit sends an AST to the LGWR.  The LGWR
writes the pieces of the database page to the redo log and marks the global
section as being commited.  The LGWR checks the value of 
LOG_CHECKPOINT_INTERVAL to see if it has written that number of VMS blocks to
the redo log.  If it has, it probably sends an AST to the DBWR and tells it
which global sections to write back to the database.  Because these two
processes can only run on one VAX CPU at a time, they can never be as powerful
as the machine itself.  By that I mean that if I have an 8550 (6 vup) the DBWR
gets 6 vup of power to do his work and thus I have 6 vups of write power.  When
I run this on a 6220 (6 vup for sake of conversation), the DBWR gets 3 vup of
write power to do his work because I have 2-3 vup processors and the DBWR can
only run on one processor at a time.  Now, the longer it takes the DBWR and
the LGWR to do their work, the greater the chance is that the global sections
will still be in use and the greater the chance that the application programs
will have to wait for the global sections to be marked available so they can
do their reads.

Remember, with Oracle there is only ONE process (the DBWR) that is doing the
writes to disk. 

On the other hand, each RDB user does his own write to disk.  So if I have two 
users writing to disk, each Rdb user does his own writes.  So, on the 8550 each 
user gets 6 vup of write power.  On the 6220, since VMS would likely schedule
each user on separate processors (assuming they were both ready to run), user 
number 1 would get 3 vup of write power, user number 2 would get 3 vup of
write power for a total of 6 vup of write power.

Get the idea ?

    
>>    They refuse to accept that even in a very heavy write-biased
>>    application that the single database writer will become a bottleneck.

Of course they won't.  Nor will they accept the fact that the sga (global 
sections) could become a bottleneck if the application mix is causing the
dirty memory pages.  Nor will they accept that the LGWR and/or DBWR can
cause disk i/o spikes when the "decide" to write to disk.  Rdb will always
be able to provide a more balanced solution in terms of memory usage,
disk i/o and cpu load.

>>    Do we have any data to support what we say i.e. that Oracle's single
>>    database writer can only run as fast as 1 processor in an SMP
>>    configuration and that a queue of database writes will build up
>>    in a heavy write-biased applications ? 

Nope but you can prove this to the customer using Oracle V5.1.22. Here's how. 
Get any SMP system (6220 etc.) Shut off all processor but one (6210).  Run two
batch update programs hitting the SAME TABLE.  (It's important that these are
batch programs because you'd never be able to measure the performance hit with
terminals.) Turn on the rest of the processor(s) and run the same two update
programs. What you should see is that the 6220 run about the same as the 6210
(at least that is what my customer saw).  Last weekend, I saw 6420 run about
the same as 6440 running 3 batch jobs updating the same table (AND I was using
V6/TP%). 

Hell, this isn't rocket science, it's more common sense than anything else. 
Don't lose confidence in what you know about VMS and SMP scheduling.    I don't
think you'd see a queue because the Oracle dba would up the size of global
memory, redo logs, and rollback segments, and the LOG_CHECKPOINT_INTERVAL
logical.  What you would most likely see is increased CPU utilization due to
the fact that so many more bits must be flipped by the LGWR and the DBWR and
you would probably see larger spikes to the disk farm when these guys worked. 

The point to all of this is that the customer will be unable to predict
how much cpu to buy as his application grows.  For example, let's say 
he's running 100 users on an 6000-410 (7 vups).  If he wants to go to 
300 users, I don't think he can assume that an upgrade to the 6000-430
will do the trick.  With Rdb, he could make the assumption with a decent
level of confidence.
                                                                    
Hang in there.  Don't let these Oracle guys dilute what you know about VMS.
If you need to, play dumb and say, "gosh... help me understand this Mr Oracle.
I thought VMS handled it this way .....".

Good luck !
    

Let's examine a few of these issues:

1) ORACLE is telling your customer that approximately TWO YEARS after
they announced V6, it will finally support VAXclusters.  And, they are
trying to make it seem like less by making Beta Test seem like general
availability of production quality software. Well, TPO has been in Beta
for something like 15 months now, and the production version STILL isn't
shipping.  ORACLE announces products before they are in field test, in
fact often before they are done coding. Digital's Corporate Policy is
that products aren't announced until field test (aka Beta) is at least
50% complete.  It nearly requires an act of god to violate this rule.
(By way of example, ORACLE announced V6 the day before Rdb/VMS V3.0.
Rdb/VMS was shipping to customers THE SAME MONTH.  It took ORACLE 6
months, shipping a Beta version of TPO, and dropping VAXcluster support,
to "make good" on their announcement.  You want to know who your
customer should trust?  Doesn't ORACLE's cavalier attitude towards
pre-announcing things, and inability to meet commitments, versus
Digital's track record on coming through as promised, answer the question?

2) ORACLE sells itself on portability.  Yet, 15 months after V6
announcement they are still selling V5 on many platforms
(VAXclusters included).  It is probably as difficult to be a DBA/System
Manager for a shop running two different major releases of ORACLE as to
be one in a shop running INGRES on one system and Rdb/VMS on another!
What good is the 'same database system on all platforms' when
the transition from version to version takes TWO YEARS across your platforms!

3) I had slides from an ORACLE training course on one of the V5 releases
that indicated they do use the DLM in a VAXcluster.  BUT, they don't use
it very much, just for a few operations.  So, for example, they don't
use it to coordinate writing to the AIJ.  Instead they partition the AIJ
into fixed chunks assigned to each processor.  When a processor's chunk
fills, it hangs.  Another wonderful point:  the processors compete for
this randomly accessed AIJ, which causes disk access arm movement, which
limits performance.  In the end the sharing technology doesn't matter,
just the results. ORACLE V5 was known to have terrible VAXcluster
performance.  Rdb/VMS V2.3 could beat it with no trouble at all.

4) Let's take ORACLE's claim that reads and writes are balanced and
therefore the single process for writing doesn't matter.  First,
applications are all over the map.  In non-TP applications the balance
tends towards 80% reads, 20% writes.  In TP applications I would bet
that its more like 50-50, if you want a gross generalization.  But, TP
applications are all over the place, with some heavily read oriented and
others very heavily write oriented.  In general, having lots of memory
allows you to cache information and avoid reads, but you can't avoid
writes (though you can defer and group them).  DebitCredit, for example,
is dominated by writes since the Branch and Teller are fully cached.
You need only read the Account, although you modify Branch, Teller,
Account, and then write a history record.  So, we can easily show
examples of situations far more write intensive than 50-50.

Let's assume that the application really is 50-50 reads vs writes.  Also
assume the configuration is a 6000-440.  Ok, so we now have 4 processors
that can process reads simultaneously, but only one processor can handle
writes!  So, in a 50-50 scenario we have a serious potential bottleneck on the
database writer!  Basically, ORACLE is correct if you consider SMP to
mean no more than two processors.  In that case, only a pathological
application would see the database writer become the bottleneck.  But,
add more processors and the odds of the database writer becoming a
problem go way up.

Hal

    Just to expand on the comments in .9.
    
    I've seen the V6/TPO manual and you will still have to partition some
    of the journal files for VAXcluster support.  So the concept of a disk
    i/o bottleneck will still apply. 
    
    My customer has V5 and V6 of Oracle.  Because of changes in some of the
    dba functions, the dba has two sets of .COM files for building indexes,
    creating storage areas (let's see... is that tablespaces (V6) or
    partitions (V5) ...), and journal files just to name a few.
    
     
   

    Given all these problems with Oracle on SMP machines, I am interested
    in hearing how various offices are handling customers who are already 
    locked in to Oracle but who need to upgrade from an 8xxx (in my
    case, an 8650) to a more powerful CPU? What solutions are being 
    recommended?
    
    I have been asked for help for exactly this type of situation here
    in Canada. Oracle, of course, are pushing a Sequent box. If we get 
    asked to do a benchmark (which the customer is considering asking
    for), we can't win price/performance wise, so there isn't much point
    in doing it.
    
    I'd appreciate hearing from some of you, especially if you've been
    successful in solving this problem.
    
    Thanks,
    Janet
    

    re:11
    If Sequent is the competition, why can't we compete?  If UNIX is being
    considered, can't we pitch our RISC systems to be competitive?
    
    ps...is ORACLE really pushing Sequent into this VAX account?  If so,
    please forward the name of the account & the ORACLE sales rep so we
    can remedy the situation.  Send the info to me at NUTMEG::SILVERBERG.
    
    Regards,
    Mark
    

    As long as Oracle plays games with their license prices on Sequent
    and VAX, you'll never be able to win the price/performance game.
    Since VAX can beat Sequent (that's right ... you heard it here),
    you'll be forced into discounting heavy on the VAX side in order
    to keep your customer.  (Check with Paul Naish for recent sales.)
    
    If you customer runs a lot of batch jobs (more than 70% of the toal
    workload), a VAX 6000-420 will beat the smaller Sequent box.  A
    VAX 6000-440 will beat the bigger Sequent box, maybe by as much
    as 40%. Interactive jobs are almost impossible to benchmark accuately
    when using VAX against VAX.  The difference between VAX and Sequent
    would be impossible for your customer to measure but they should
    try.  
    
    We were competing against Sequent and ended up winning the order
    (6440, 2-6420, 1-6410).  Based on my customer's benchmark, the Sequent
    was not fast enough, didn't have enough growth potential (my customer
    didn't buy the "we'll have 486 power soon" line), and did NOT handle
    batch well at all.  In order to equalize the price, the customer did
    a site license for Oracle which basically said that they could put
    Oracle on any machine they wanted for two years.  This was a good
    deal for us but a very bad one for the customer.  When this license
    expires in two years, my customer will have lots of big VAXes and
    Oracle will want a small fortune to renew the licenses.
    
    Getting the Oracle license fees out gets you close enough to win
    the the hardware discount wars.  We ended up having to sell $400k
    of value for the four systems.  Major factors that assisted us:
    
      - VMS vs Unix
      - Systems performance tools (Ethernim, VPA, SPM, VMS monitor)
    	  We had meetings with the VP where we would review VPA reports
    	  in order to help estimate the size of the remote systems.
    	  Over time, he became quite comfortable with VPA as a management
   	  tool.  Sequent (or Unix) didn't have anything to match.
      - Availability.  They still get value out of a cluster even if
    	  the application isn't available "cluster wide" and must be
    	  managed on a cpu-to-cpu basis.  My customer was going to have
    	  buy two Sequents.
      - Volume shadowing on VMS, when combined with VAXsim+ has a much
    	  better solution than Sequent.
      - Our extended warranty and 24x7 support showed a weak spot in
    	  the Sequent product line.
      - Sequent is not always installed OR serviced by Sequent, so beware.      
      - Sequent has weak training, especially in the DECstart type of
    	  of services.
        

    Basically, it came down to a VMS vs Unix sales ONCE the customer
    realized that Oracle was playing games with license fees.  Until
    your customer realizes that Oracle is jerking THEM around, you'll
    have a tough time selling the added value of VMS.

    Let me know how I can help.  If you want to know about my customer's
    benchmark, give me a call at (816) 943-3445.

    --gerry

    re: .12
    
    No, we can't "pitch" our RISC systems. Oracle has declined porting the
    Oracle software to our RISC architecture (perhaps because it competes
    with Sequent). Consequently, we cannot use the RISC machines for
    price/performance advantage.
    
    ---- Michael Booth

    Mike, et al....
    
    If Oracle can't run on our RISC system, how can the Oracle Financials
    run on our RISC system ?
    
    --gerry

    Most of the ORACLE products (CASE, DB, tools, etc) are already ported
    & verified on our RISC machines; we have an agreement to sell the
    financials on a customer by customer basis on the RISC machines.
    Mark
    

    And those believable ads say Oracle runs on Ultrix/RISC.
    
    A few questions RE: -1,  
    
    Is the verification on the DECsystems 5400 and 5800 or just
    workstations ? 
    
    Does the "agreement" have a provision that keeps Oracle from switching
    the customer to Sequent ? 
    
    Barry Wallis in Irvine recently received a promo from Sequent which
    was obviously taken from an Oracle mailing list.  Is there any
    assurance int he "agreement" that Oracle will not provide similar
    lists to Sequent, Ncube, et al. ?
    
    
    

    re.18  VAX RISC???  Do you mean RISC ULTRIX??
    Digital helped ORACLE port their products to our RISC ULTRIX platforms,
    including the 3100 & 5xxx series.  They released press annoucements as
    such, we had them as participants in the July RISC product
    announcement, we had their products running on DS5400s at the ORACLE
    User show in Dallas, we talked with many ORACLE customers using our
    RISC products, etc.
    
    If you really mean VAX RISC ( unannounced products??), then ORACLE
    is doing the right thing by saying they do not run on VAX RISC.  If
    you really mean ULTRIX RISC, then by all means send me the names of 
    the reps & accounts & we will fix this problem.
    
    Mark
    

    Yes, I mean RISC ULTRIX. 
    
    The problem is now quite clear. A small subset of Oracle products, that
    is, the core products, RDBMS, CASE, 4GL are available on all platforms.
    But all new Oracle development, things like Financials, Manufacturing,
    Banking, Mail, etc. are developed on Sequent, then have to be ported to
    VAX. So there is a 6-12 month lag in the product's being released on Sequent
    and being available for the VAX.
    
    Consequently, when people want to know "does Oracle run on RISC
    ULTRIX?", we should qualify the question by asking which Oracle
    product. It also should be mentioned that if the customer "wants it
    now" (before the product is ported to the VAX), he will have to buy    
    Sequent, not VAX.
    
    Conceptually, that would mean that if a customer bought Oracle
    Financials on a VAX, and the next release had major improvements, the
    customer might jump to Sequent to get the improved version in a more
    timely manner.
    
    ---- Michael Booth

    First off, is this really the place (or A place) to be running your
    mouths (fingers?) about operating system futures?
    
    Secondly, IF it were to exist, it would be VMS/RISC. VAX is a hardware
    architecture, upon which an operating system runs. RISC is a hardware
    architecture, upon which an operating system runs. The two operating
    systems in question, VMS and ULTRIX, could, conceivably, run on either
    hardware. Both have been modularly designed to run hardware
    independently.
    
    The database management system, if it is not incorporated in the
    kernal-mode code, runs at the next layer up from the OS. If it is also
    modularly designed, it can, conceivably, run on both OS's.
    
    Note the word CONCEIVABLY. The biggest thing that makes some of these
    things inconceivable is the terrible performance which sometimes
    results from such gerry-rigging. Modularity means limiting the
    tailoring of the DBMS to the OS, and the OS to the HW. This usually
    compromises performance, either across the board, or on one platform at
    the expense of another. ORACLES's dramatically disparate performance
    on VMS and ULTRIX is a good example of this.
    
    But we dodge the point.....
    
    Get your customer to lean on ORACLE, hard, to support the SMP & cluster
    services which we provide. I do not envy your task of dancing, in the
    short term, around the performance wall issue.
    
    By the way, if ORACLE runs on DEC RISC as just the db, can they serve
    the VMS applications from ULTRIX DECServers?
    
    thomas

>    First off, is this really the place (or A place) to be running your
>    mouths (fingers?) about operating system futures?

I don't think Mike was talking about, or even implying, any futures in
any fashion.  I think it was purely a 'slip of the tongue'.  I see this
all the time with regard to the three words VAX, RISC, and ULTRIX being
used in unintended and impossible combinations.  Unfortunately, the last
two authors have made comments that would lead one to believe Mike might
be talking about something real.

Lest someone misinterpret said remarks, I think the moderator should
mark the offending notes HIDDEN.

Hal