Re: Anybody use Maximo on 8i OPS?

Hi Howard,

Note your description of consistent block transfers were possible without disk pinging with OPS in 8i. It's changed blocks that were a right pain in OPS that have been addressed with RAC.

Cheers

Richard
"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:MoUA9.76591$g9.216283_at_newsfeeds.bigpond.com...
>
> "ctemp" <ctemp01_at_hotmail.com> wrote in message
> news:4d44e6cf.0211141252.5c161098_at_posting.google.com...
> > Hi,
> >
> > We are currently using Maximo 4.11 (Asset management s/w from MRO) on
> > Windows 2000 and the backend is a single instance Oracle 8i database
> > on Solaris 8. Since we are seeking a more stable and high avalaibility
> > database, considering to upgrade the db to OPS which will be on Sun
> > Cluster 3.0. But recently the Oracle guy told us that Maximo 411 won't
> > work on OPS and he recommends us to use 9iRAC. The reason he said is
> > that Maximo can not recognize the cluster environment and will cause
> > problem. If we want to use OPS we have to modify the code in maximo.
> > Also he said 9i RAC has no such problem. At this point I got confused.
> > What maximo see the db on windows side is only a TNS connection and it
> > should not matter if the db is a single instance or OPS and the
> > failover thing is on the cluster. I thought all third part
> > applications can work on either single instance or OPS db and there
> > maybe such cases that some applications are not appropriate for using
> > OPS in terms of performance. Maybe I am wrong. I had a kind of feeling
> > that they are push us to use 9i RAC but maximo 4.11 is developed
> > before 9i and not sure if it will be happy with 9i. Finally I asked
> > him if we can use the HA option and he said 'yes'.
>
> What your Oracle guy was getting at is that for Parallel Server to work
> properly, and not introduce a whole raft of new bottlenecks and points of
> contention, the application has to (or ought to) be 'partitioned'. I don't
> mean partitioning in the sense of range partitioning, or hash
partitioning.
> I mean that it has to be re-written so that you try and arrange for
> particular chunks of data always to be accessed from one of the two (or
> more) instances running in OPS.
>
> The reason for that is simply that in OPS, transferring data blocks
between
> instances is a slow a nd painful experience. Say I, connected to Instance
A,
> have queried the EMP table. Therefore, blocks of data from EMP are in my
> Instance's buffer cache. You connect to Instance B and query something
from
> EMP. I therefore have to pass the EMP blocks from my Instance to
yours -and
> I do so by writing them to disk, so that you can read them from disk. In
> effect, you've forced me to write blocks to disk. Forced writes like this
is
> known as 'pinging' a block. And pinging blocks means it is very difficult
to
> pass data around the cluster. So you write your applications with the aim
of
> ensuring that you don't have to do it, or at least do it very
infrequently.
>
> You arrange, for example, that anybody querying the EMP table *must*
> establish a connection to Instance A, so the EMP blocks are always in that
> Instance alone. And if you want to query DEPT, you have to connect to
> Instance B, so the DEPT blocks never move from that Instance. And that's
> what we mean by talking about "application partitioning". It's a direct
> result of the massive cost of transferring data around an OPS cluster.
>
> Now why do you think Oracle called the 9i version of OPS "Real Application
> Clusters"? Because in RAC, you can use "real" -that is, unpartitioned-
> applications. What worked fine in a single instance database should work
> equally fine *without modification* on a 9i RAC. Why? Because in RAC, it
is
> trivially cheap to move data around the cluster... we pass blocks of data
> via the high-speed interconnect between each machine, not via a slow hard
> disk. Block pinging goes away, so it now ceases to be a concern where
anyone
> connects, or what data they want to access.
>
> So that's what your Oracle guy was trying to say: that Maximo needs to be
> partitioned if its to work effectively on an 8i OPS, but that it can run
> unmodified on a 9i RAC. Without the modifications for OPS, the application
> would spend all its time writing to disk, and waits to get hold of data
> blocks would go through the roof. It's not that an application needs
> anything coded to make it "aware" it is running in a clustered
> environment... to that extent, you're quite right that to the app, it
> "should not matter if the db is a single instance or OPS". But a
> non-partitioned app in 8i OPS is going to run into trouble which it
wouldn't
> were it running on 9i RAC.
>
> Just to confuse the issue, it is actually a bit of marketing department
> hoo-har to say that RAC doesn't need applications to be partitioned. It's
> very largely true, but it's not entirely true: there are still costs
> involved in shunting data around over the cluster interconnect, and having
> to do that sort of work a lot can compromise application performance.
> There's an interesting paper by James Morle called "Unbreakable",
available
> at www.oaktable.net (the 'Files' link) that discusses whether application
> partitioning really is unnecessary in a RAC environment.
>
> But don't take that to mean RAC isn't a much better bet than OPS. It is.
> Hugely better. And your Oracle guy is perfectly correct in what he's
telling
> you.
>
> Regards
> HJR
>
>
>
>
> >
> > Any comments will be highly appreciated especially for those who have
> > experience on using Maximo.
> >
> > Thanks,
> > Kevin
>
>
Received on Thu Nov 14 2002 - 17:58:42 CST