Conference ulysse::rdb_vms_competition

    Mark, I too have seen similar requests. Of course there are lots
    of "problems" if the data to be memory resident is also to be
    updatable. But even if Rdb implemented some method that only supported
    read-only relations being memory-resident, that would still help
    many people. 
    
    Some of this is a technology problem: if we had solid state memory
    disk drives, then your access would be at memory speeds anyway,
    and you'd have DSA checking, etc.. Even tiny RAM disks would be
    useful!
    
    I'm guessing a problem with dbms's that rely on in-memory caching
    for a single CPU is that it may degrade VAXcluster performance if
    not managed very cleverly. This could be ORACLEs problem in clusters.
    

I'm not sure there are any commerical RELATIONAL database systems that
let the user explicitly specify portions of the database which should be
made memory resident.  In general, database systems work much like
virtual memory systems, trying to keep active data in memory by dynamic
algorithms. Some database systems use/rely on this more than others, for
example SYBASE REQUIRES lots of memory because its entire design relies
on being able to keep large portions of the database memory resident. 
If SYBASE can't keep much of the database memory resident, then its
performance will degrade significantly.

Rdb/VMS attempts to keep active data in memory, but it still uses
algorithms which were designed to work well in limited memory
configurations.  As a result, it doesn't make as effective use of large
memories as do some competitors, but compensates with more powerful data
placement control.  The net result is generally equal to better
performance (for Rdb/VMS) in most real applications.

One indirect way that some database products allow portions of the
database to be specified as memory resident is to allow multiple buffer
pools and assign different relations to different buffer pools.  Then,
if you allocate a pool large enough to contain an entire relation and
assign only that relation to that buffer pool, you effectively get a
memory resident database.

The most well know memory resident database is the main-storage database
portion of IMS/Fast-Path.  Although relatively limited in functionality
and difficult to program, MSDBs do allow for substantial performance
gains.  IMS/Fast-Path is only available under MVS (meaning 3090-class
IBM systems).

    This should probably be in the Rdb conference, but here goes anyway.
    
    While I agree that explicitly marking a relation for complete storage 
    in memory is a `bogus requirement', I feel that there could be some
    improvement made to Rdb/VMS's buffer management.
         
    Using multiple buffer pools and allowing specific relations to be
    assigned to specific pools is entirely analogous to on disk placement
    control and I feel something worth providing.
    
    More efficient management of large buffers and of large buffer pools
    would also be required.  My understanding is that Rdb/VMS expects that
    buffers and buffer pools will be small enough that O(N) algorithms
    can be used.  This is generally true, however it does mean that when
    you have an excess of memory, you can't use it efficiently because you
    soon spend so much time managing and searching buffers that it's
    quicker to do the I/O. 
    
    -mark

    I don't understand why being able to make sections of the
    data base memory resident is a bogus requirement!

    After all, in .2 it does point out that main-storage
    databases do allow for substantial performance gains.

    Comparing database systems to virtual memory systems, isn't
    making database areas memory resident analogous to locking
    pages into memory ($LCKPAG)? 


    Can ORACLE lock tables (or parts thereof) into memory?

    Thanks,
    Mark

>    I don't understand why being able to make sections of the
>    data base memory resident is a bogus requirement!
>
>    After all, in .2 it does point out that main-storage
>    databases do allow for substantial performance gains.

>    Comparing database systems to virtual memory systems, isn't
>    making database areas memory resident analogous to locking
>    pages into memory ($LCKPAG)? 

And 99.99% of the time locking a page in memory will not do anything for
you, or worse, it will degrade performance because that doesn't leave
enough memory for pages that REALLY are accessed more often.

I happen to agree with the requests for multiple buffer pools.  I've
been asking for them in "KODA" since before VAX DBMS V1.0 shipped.

This is off track a bit, but...


Can a disk-less ELN system run Rdb/ELN?


This is even more off the track, ...


I have seen many RFP's where speed was critical.  If there was such
a thing as a memory resident 'disk' that would be supported by a 
database system, ...  

Sorta like the ones you can have with RSX.  You tell the system that
you want n MB of memory to be used as a disk, give the disk a name and go.

VAXELN systems can run as diskless nodes off the ethernet.  I believe
the new version of VAXELN supports RAM disks.  Thus, you could run
Rdb/ELN on this diskless node for fast data collection and retrieval
and then migrate the data to Rdb/VMS for long-term storage and reporting.

--david