Conference smurf::ase

Re: scaling:  The 17k number is quite new, the 30k number is getting
quite old.  The 30k cluster used 300 MHz cpus, MC 1.0 boards, an
older operating system and compilers, rz28 disks.   

Re: mode of operation: the main difference is the ASE will have two
instances of the database whereas the production server will have one.  
I'm no db expert, but that usually presents operational difficulties
that should be avoided.  Most folks don't like idle hardware, so
balancing the instances can be difficult.

Dave
[Posted by WWW Notes gateway]

    re .0
    If you are just looking for the failover capability I would always go
    for ASE. Even if the recovery of the failed Oracle instance takes
    longer. In the ASE case Oracle basically needs to recover from a
    crashed database just like on a single node after a system crash.
    
    With OPS the surviving instance will automatically recover the open
    transactions of the failed instance while it keeps on running. So
    clients connected to the surviving instance will just keep on working.
    
    If you really want to exploit the resources of 2 machines and get your
    database application to scale you need to put quite a bit of effort
    into the database and application layout. A 'normal' database
    application is usually not 'OPS ready'. In certain cases running an
    existing database application on OPS without changes may even be slower
    than on a single node.
    
    On the other hand if your database and application can be 'partitioned'
    scaling will be just fine; e.g. building several Oracle indexes in
    parallel scales close to 100%.
    
    Just my 2 Pfennige
    
    	Martin 
    

    Thanks for the responses.
    I did not realise that the 17k and 30k results are from different
    generations.
    I also did not realise that the recovery of the database in a
    production cluster may be faster than in ASE environment.
    This may be important for very large and active databases when there
    is a customer imposed limit on recovery time.
    
    Trying to summarise the discussion so far I believe that the economics
    are against TCR Production Server in the scenario described in .0
    
    If the baseline single machine 2CPU configuration yields troughput
    of 1, then  from a cluster of two such machines we can expect 
    say 1.5 without significant programming work in the application.
    
    By comparison the ASE configuration with the whole application
    running on 1 node of 3 processors virtually guarantees nearly
    1.5 throughput with no programming work and no licencing and
    operational costs of running TCR Production Cluster and OPS.
    This still leaves an idle second machine with 1 CPU in it
    for failover prupuses.
    
    And if 1 CPU is deemed not enough a second one can be purchased 
    for an equivqlent of about 10days work of an Oracle consultant. (:-)).
    
    Is this a reasonable approach?
    
    Chris Jankowski
    Melbourne Australia

    re .3
    Well the recovery with OPS is not only faster but clients can access
    the database (on the surviving node) all of the time. The clients which
    were connected to the failed node will have to re-connect to the
    surviving node though. 
    
    You also need to configure your I/O subsystem for media/controller/cable
    failure. So if database downtime is not acceptable for any longer period
    of time you would need to go for OPS. Remember you are basically using
    2 (up to 4) machines to access the exact same data.
    
    And for the 3 CPU/1 CPU setup you need to find out if the lesser
    equiped system can sustain the normal user load (if that's required).
    And you are also working on the assumption that the database
    application scales with the number of CPU's on a single node. Which may
    not always be the case.
    
    	Martin           

I agree with .2 in that there are a lot of ORACLE applications out there 
which WILL NOT RUN ON OPS. For example, An application uses X.25 for all its
transactions which are POS & Cash Machine Operations. The System holds the X.25
address of the caller and does a match on the incoming addres and allows the
call into the application. The applic also stores the PID of the PARENT process
so that it can tidy up. The application consists of many processes that 
communicate to each other. There is also some hardware that just cannot be 
shared, for example a DES Encryption module.

If you put all this together, you see that ASE is preferable to TruCluster.
But and its a BIG BUT, salesmen will always try to sell as much as possible.
I have been in the situation where I have had to explain to the customer that
his TruCluster is in reality a speedier ASE, in terms of Failover as you don't
have to failover ORACLE.

The merits of ASE vs TruCluster can be debated until the cows come home. It is
sometimes difficult to explain to both Sales & Customer why they should spend
a little less on Software (and buy more disk instead). 

Unless the application can REALLY take full advantage of multiple instances etc
then play safe and go for ASE. If you are in any doubt, benchmark it.

Stephen Davies