Conference ulysse::rdb_vms_competition

    The latest version of ORACLE (released last month) supports clusters.
    They can now run multiple instances of ORACLE DBMS on different nodes 
    in a cluster, although ORACLE admits that locking can cause serious 
    degradation of performance.  They recommend its use for retrieval only
    applications.

    Anne,
    
    Does that mean that they do automatic recovery in clusters now or is it
    just back to the V5.X period (running on clusters but bad performance)?
    
    Henny Olthof, TP-DB Netherlands

    Yes, I'm pretty sure they do automatic recovery in clusters.
    The performance problems are due to their less than optimal use
    of the Lock Manager.  They were hoping to build their own lock
    manager, but in the end they decided to use ours.  

    An ORACLE product manager told me that the version that supports
    clusters is a VMS-only version. It will not be supported on other
    platforms and presumably will not be kept up to date with the other
    releases of the product. He implied that this was a fairly quick and
    dirty release to address the clustering issue.
    
    FWIW
    Tony J.

    
    At the Decus symposium on December 13, I had the dubious honor of
    having a one-on-one conversation with the Oracle VMS product manager
    (Walter something-or-other); naturally, Oracle on clusters was a
    big issue.
    
    He indicated at the time that the next version of Oracle (I forget
    whether the version was 7.0 or incremental 6) would properly handle
    multiple instances of a database, on different cluster nodes. According
    to him, this version was currently in beta test, and he would not
    give even a clue as to official release date. Given this evasiveness,
    I am surprised to hear that the product was released last month;
    (perhaps it was only in Europe or only to accelerated-distribution
    customers?).            
    
    His explanation of 'performance degradation for updates across
    instances' is as follows:
    
    Normally, Oracle follows a 'deferred database update' philosophy;
    database pages are read into the SGA, modified there, and written
    at some later time by the DBWR server process. This does not
    necessarily occur because of a committed change. (Supposedly they
    can properly construct the modified page from log files). Especially
    with the 6.0 TPO row-level-locking feature, this makes it at least
    theoretically possible for multiple users to make multiple updates
    to a database page before the physical database write occurs. The
    page copies are kept around in the SGA for as long as practical.
    The minimization of disk i/o is trumpeted by Oracle as a big
    performance feature. This, combined with the reduction of 'unnecessary'
    blocking between users with TPO, supposedly makes oracle well suited
    for high performance TP applications.
    
    It turns out that nearly all of these performance features can be 
    negated when a second instance of the database (second set of servers
    and a different SGA global section on another machine) is introduced.
    The question which the instances constantly need to keep agreement
    on is "who has the official copy of database PAGE X?"
    
    According to the product manager, the new Oracle version will use
    both the Distributed Lock Manager AND its own internal locking scheme.
    DLM will be used to manage PAGE locks between the instances, and
    the Oracle lock facility will be used for ROW locks and other locks.
    
    If instance A needed to read and update page X (assuming another
    instance does not have it) it first obtains a relatively high level
    DLM lock on the 'page X' resource. It also internally takes out
    whatever Oracle locks it needs. Instance A keeps the page lock at
    a high level until it writes a copy of the page to the database,
    at which time it downgrades the lock. 
    
    If, while instance A was still holding the high level page lock,
    instance B needed update access to the same page, instance B will
    request the same high level DLM page lock. This will 'ping' instance
    A (blocking AST feature of DLM?), which will write the page and
    downgrade the lock as soon as possible; when the lock is downgraded,
    instance B is unblocked and can read the page. The Oracle internal
    locks supposedly remain intact through this process.
    
    For an application with a 'hot' table which has updaters randomly
    distributed across machines, this could result in every user blocking
    every other user, despite TPO, and waiting for a database read and
    write as well. The Oracle product manager suggested somehow(?)
    directing update processes for a given table to run on a single
    particular machine.
    
    The problem is thus not just a 'locking mechanism' problem, but
    (primarily) a 'storage management' and 'increased i/o' problem as
    well.
    
    I hope this info will be of some help.
               
    Paul Sliwinski, EIS PSS, Connecticut, USA.

    If somone has a description of their "handling of cluster failover" I'd
    like to hear it.
    
    thanks
    
    -Jay
    

    In Oracle magazine, Vol V, number 2, Spring 1991, there's an article
    entitled "ORACLE Parallel Server Version 6.2".
    
    "Each VAXcluster node can run an instance of the O Parallel Server.
    Each instance serves multiple clients. The OPS gives multiple
    instances full R/W access to the same database..."
    
    It uses VAX DLM, but "DLM is not designed for the workload of DBMS
    transaction concurrency... a DBMS system must minimize its use of the
    VMS DLM."
    
    "If one node of the VAXcluster fails, affected users can switch to
    other nodes..." [Jay, this doesn't sound like transparent failover to
    me.]
    
    "6.2 will initially support VAXclusters connected via... a CI".
    
    "The initial release of OPS will be available with O 6.2 in the first
    half of 1991... will be fully supported in O V7." 
    
    This is what O are sending to their customers. I don't include it here
    as hands-on technical fact, but as a guide to what our customers are
    hearing from O.
    
    BTW, O magazine goes out once a quarter to their distribution list of
    prospective customers. As well as technology issues, it has articles on
    industry segments.
    
    	Andrew.
    

The claims Oracle makes as stated in .-1 are right. 
    
"If one node becomes unavailable, processing continues on other nodes
 and users can switch to these other nodes".
    
"ORACLE Version V6.2 will initially support VAXclusters that are
 connected via a high-speed backplane CI (Cluster Interconnect) bus.
 LAVC and Mixed Interconnect may be supported in a future release."
    
"The ORACLE Version 6.2 architecture will be fully supported in Oracle
 Version 7"
    
Ok, what can we learn from that:
- To my opinion, we do no better after failure. Both Rdb and Oracle
  rollback transactions after a node failure. In both cases however, users
  have to login again! Even with ACMS you have to restart the task.
- Strange they don't support LAVC and MI clusters, we could use that as
  an argument. Note they say MAY BE SUPPORTED
- Seems like they were under time pressure to fix the cluster problem
  quick (full support in V7), we may use that as an argument.
    
Also in Oracle's papers what we can use:
- "The ORACLE Parallel Server provides full backup capabilities.
   However,in the initial release, operations that add, drop or recover
   datafiles or tablespaces must be dodne while the ORACLE Parallel
   Server is offline. This restriction will be removed in subsequent
   releases"

  How do we compare to this, does Rdb/VMS better with this? Could be as we
  don't use global buffering.

- "Depending on the application, the performance gain of adding a node
    to a VAXcluster will range from negligible to roughly proportional
    to the amount of CPU power added"
    
  So, now real commitments there. Oracle claimed 140-170% at my customer site.
  
- "The Oracle Parallel Server is ideal for VAXcluster applications that fit into
   one of the following categories: decision support, departmentalized where
   each application uses different tables in the same database, OLTP with
   partitioned data (modify mostly disjoint sets), OLTP with random access to
   a large database".

  So, they DO support cluster but more or less restict the use to applications
  that:
  - either don't wite at all
  - write to disjunct data from different nodes
  - are likely to have minimal inteference with data also used by other
    applications
  One may argue, wether that's a homogeneous solution. To my opinion, Oracle
  tries to discourage people form really using it.


All quotes are from
- ORACLE Version 6.2: Support for Shared Databases on VAXclusters,
  Kevin Jernigan, Andy Laursen, Brian Hirano, paper number 515 pages
  1317 - 1319
- ORACLE Parallel Server in the Digital Environment, Kevin Jernigan,
  Walter Schenk, part number 3000101-0291

	I read in some replies that Oracle supports only CI clusters ?

	What about LAVC clusters ?

	I would like to have 1 Oracle database accessible via 3 VAXstations 
	in a LAVC cluster.
	Is this possible via the latest Oracle version ?
	
	Or do we have to wait for Oracle version 7 ?

	If yes, when will it be available ?

	Many thanks for your help.


	Regards,

	Stefaan
 

When we say that ORACLE doesn't support clusters, what we mean is that there
can only be one Instance of the ORACLE DBMS on a single node within a cluster
which can access a single ORACLE database.  But that one Instance can service 
requests from an node in the cluster (CI or LAVC) or from any non-VMS node 
which is running SQL*Net (ORACLE's communication layer).

-- You say this sounds like cluster support?  Well, yes, but not _full_ 
cluster support.  In Rdb, you can have any number of Rdb Runtime systems 
running in a cluster, and all of these runtime systems can access the same 
database at the same time.  Therefore you don't have all database access
funneling through a single node.

    Any additional competitive info. on ORACLE V7.0? The latest issue of
    'Digital Review' has an article on it.
    
    ashim

    re -2
    
    You can run Oracle on a Cluster, meaning two Oracle instances are
    mapped against the same Oracle database with Oracle evrsion V6.2,
    also known as the Parallel Server. Synchonisation between databuffers
    in the memories of the participating nodes is done using DLM.
    
    There are many restrictions on the type of applications and
    transactions that can benefit from V6.2 (check the V6.2 brochure).
    
    Personally I don't think it will help many of the poor Oracle users to
    increase performance.
    
    Henny Olthof, TP-DB Netherlands