Conference 7.286::digital

    I can articulate the business benefits of Oracle...it's about killing
    sales of DEC/EDI, which uses Oracle-RDB for its database.  We're trying
    to sell systems wherein the price of Oracle-RDB for a minimum eight
    user license is over $12,000.  This one issue is knocking us completely
    out of the ballpark and it'll be a year before Engineering is able to
    give the user a choice of another database provider.
    
    Phhhbbbffftttt!!!

Sure - it's a great way to sell lots of memory.

			Steve

    VLM in and of itself has no "business benefit" it's an enabling
    technology for very large databases, which themselves are an enabling
    technology for applications that provide the real business benefits,
    for example with SAP R/3 you are able to integrate information about
    different business funtions that were previously divided into
    stovepipes but if you are a large company the size of the database
    becomes a limiter on how much of the enterprise you can bring together
    in one place, bigger databases = more span of coverage, more accurate
    and timely business data available to management. 

> VLM in and of itself has no "business benefit" it's an enabling
> technology for very large databases, ...

  Or very high speed databases. The kinds of sorts and searches
  that VLM can do "in memory" would have been possible in the past
  but would have required very extravagant numbers of disk acces-
  ses. This would have translated into a lot of time to accomplish
  all of those accesses.

  VLM runs like the wind.

                                   Atlant

    This is pretty useful:
    
    ** Aberdeen Group Report on Oracle and Digital **
        Gary Kuba, Database Program Office
    
    The Aberdeen Group report, "Digital and Oracle: Delivering the
    Industry's First Ready-For-Industrial Use LIMD (large in-memory
    database) Technology" provides an extremely positive look at the
    benefits and impact of the Digital/Oracle solution now available for
    your customers.
    
    The report is available from VTX LOS - part number: EC-Y5104-48 or on
     VTX IR document ID # ST0174.
    
    Greg
    

    I 2d the previous noter (.5).  Ordered 10 for my key customers (single
    order maximum) & have another order in for more.  The Aberdeen report is 
    powerful for those who will read and understand it.
    
    Ever notice how everyone's trying to put their own acronyms on
    the notion of very large system memory (LIMD, VLDB, VLM, EMM, etc.)?

    
>    Ever notice how everyone's trying to put their own acronyms on
>    the notion of very large system memory (LIMD, VLDB, VLM, EMM, etc.)?
                   ~    ~     ~      ~
    		

       <<< Note 3937.1 by DPDMAI::EYSTER "Livin' on refried dreams..." >>>
    >>>           -< It's well known that we *can't* due to price! >-
    >>>
    >>> I can articulate the business benefits of Oracle...it's about killing
    >>> sales of DEC/EDI, which uses Oracle-RDB for its database.  We're trying
    >>> to sell systems wherein the price of Oracle-RDB for a minimum eight
    >>> user license is over $12,000.  This one issue is knocking us completely
    >>> out of the ballpark and it'll be a year before Engineering is able to
    >>> give the user a choice of another database provider.
    
    
    We've are trying to address this issue and are in discussions with PM
    to make Rdb available to EDI customers under workable Ts & Cs.  We're
    as anxious to solve this as you are.
    
    Jim Steiner
    Dir. Prod. Mgmt. & Mktg.
    Oracle Rdb Products Division

    Here are the Oracle Rdb benefits of VLM; these are also true for
    Oracle7.
    
    Jim
    
    
    

Oracle Rdb and 64-bit Capability for VLM on Digital Alphaservers

Below are the salient technical points that make Oracle Rdb a true 64-bit 
RDBMS with complete support for VLM on Digital UNIX today, and on OpenVMS in 
the near future.  
                
1. Native 64-bit support. 
All data structures and references are designed to work correctly and 
efficiently in the 64-bit addressing environment.  In addition, to fully 
exploit the Alpha architecture, data structures have been carefully aligned 
for optimal performance. Rdb's code generator also generates machine code 
optimized and aligned for 64-bit addressing architecture.  Native 64-bit 
support end-to-end means maximum performance for customer applications.

2. Scalable in-memory data structures.  Rdb is carefully engineered to scalably
exploit very large in-memory data  structures. For example, patented algorithms
for navigating and manipulating in-memory locks and global buffers will
continue to remain efficient even as memory  expands from tens of megabytes to
tens or hundreds of gigabytes.   

3. Very large global buffers and in-memory databases.
Rdb's global buffers can expand to make full use of large amounts of main 
memory. Thus, a relatively modest-sized database, say 10 GB in size, can be 
fully resident in memory, thereby not requiring any disk I/O to access the 
data. Further, isochronous delivery of video and audio data is possible simply
by caching an entire video or audio script (such as a full-length movie)
in main memory.  More operations are performed at memory speed, application
performance increases dramatically.  

4. Accelerated commitment processing:
Even when a database is fully resident in memory, disk I/O is still required
to save the journal data upon each, or a group of, commit operations.  Rdb
has the unique ability to speed up journal I/O by using a very small but fast
solid state disk. This algorithm for Accelerated Commitment through
Electronic disks (ACE) is the subject of a patent being sought, and
is especially useful at high throughput and concurrency levels. Thus,
in-memory databases can support even higher transaction rates by further
reducing stalls resulting from disk I/O.

5. Scalability of throughput with large memory:
Server databases with very large memory are expected to scale and support
larger and larger numbers of users. In other words, the total number
in-memory lock entries should scale with memory and users. Rdb's lock manager
is scalable with memory size and supports more users as more memory is 
available for storing lock entries.  

6. Recoverable global buffers:
Rdb's global buffers are fully recoverable from process failures without
requiring a refresh from disk.  This is a significant performance enhancement
given that it may otherwise take a large fraction of an hour to refresh 10 
or more gigabytes of memory from several disks (all transferring data in 
parallel).  If a process (user) aborts and corrupts the global buffer control 
structures, Rdb repairs these structures in a fraction of a second, and 
continues serving the other processes in the system.  This isolates system 
performance from overhead inherent in maintaining cache integrity. 

7.  Large Block I/O 
Oracle Rdb supports large I/O transfers between memory and disk for maximum
performance in those instances where magnetic disks are accessed.  The size 
of the transfer is a parameter that can be set by the customer, one of the 
many ways to tune a VLM application.

    > Ever notice how everyone's trying to put their own acronyms on
    > the notion of very large system memory 
    
    If Oracle hadn't trademarked VLM in their product name maybe everybody
    would have had the option of not reinventing it.
    
    DougO$onsite_at_the_home_of_"LMA" ;-)

    I'm trying to put together acouple of examples for our Business
    Partners.  I have three examples that I found in the inFORM magazine. 
    However, I remember reading about an European automobile manufacture
    that took a months data from it's European Subsidaries and massage the
    data.  I believe that it took 8 days and with the AlphaServer and VLM
    it got down to 5 hours.  Not sure if the numbers are correct but does
    anyone remember reading this?  I'm looking for the Company and actual
    numbers.
    
    	Regards,

    Contact Jerry Vennard, the VP with the VLM64 program office. If not
    him, Paul Krneta might be able to help.

    Lisa

    Classic example of DEC responsiveness - sent a message to the two names
    suggested and NEVER got a reply.  Just totally ignored.  We don't do
    marketing and we don't respond to inquires.

    You're right - it's typical - and I'm sorry to hear it. You might try
    Kevin McCoole in the Enterprise Server program office. 

    Lisa

    I don't think that's entirely fair.  All three of the names you
    mentioned were extraordinarily busy last week, since the Database
    Market Development Group was holding a week-long planning meeting
    for FY97 to plan how we're going to make another big jump in our
    license share with the major database partners.  This planning meeting
    brought in upstream and downstream players, involved the various
    initiatives, identified the budgeting shortfalls, put the marketing
    plans on track, and got a whole bunch of related organizations face-
    to-face to deal with a very complex set of problems.  Jerry Vennard,
    Paul Krneta, and Kevin McCoole were all heavily involved, so if they
    put off answering a query about wins that have already been published
    in normal channels, I think that's understandable.
    
    Why don't you try them again, or start with the SBU marketing web page?
    
    http://sbu.mro.dec.com/
    
    DougO