Rodrigo Gazzaneo wrote:

> Kells,
>
> >     dsmserv.opt -- unlikely to change, and changes are unlikely to affect
> >                             an emergency recovery (maybe memory changes
> >etc).
>
> Ok. But still you may lose some work on tuning. You
> could live with that. Like I said, on a more
> complicated site, people wouldn't like to live
> with that.

   You would recover that from your offsite copies in the case of a disaster,
and from the other server in the case of a bad HACMP node.

> >     dsmserv.dsk -- will be recreated when you recreate the dbs and logs
> >
>
> This is the point I disagree. Why recreate dbs and logs ?
> In my solution, all you have to do is import ADSM external
> VG and start it, everything you need will be there, you
> won't move a muscle on reconfiguration, recovering files,
> editing anything. This is HACMP, not DRM.

   There are two scenarios:
 1. loss of an HACMP node
 2. loss of ALL HACMP nodes

     I think where our problems in communicating with each other are that
I am addressing both concerns, while you seem to be only addressing
scenario 1.

   You will need to restore the dsmserv.dsk and other friends from a Recovery
Plan File if you encounter scenario 2.  For scenario 1, copy the files over
from
the working primary node.

> You won't have to run DRM. Besides DRM is an expensive
> feature and not everybody buys it. Would they have to
> reinstall and reconfigure ADSM all the time ? In my
> solution the answer is no. In your solution, the
> answer seems to be yes.

      Uhhh... nooo.  We are both talking about a shared disk solution where
the database and logs reside (see my previous comments about distributed
databases).  The DRM functionality (whether homegrown or brand name :)
will be needed for a scenario 2 failure.

     Agreed, you do not require DRM as you can build your own.  A number
of people on this list have done so.  What you DO require is a backup of key
configuration files to an offsite location, which you have correctly identified

(dsmserv.opt, volhist and devconfig).  This is a necessary for a scenario 2
failure recovery.

> Imagine a cluster that has to rebuild ADSM database
> everytime it does a failover ...

     That would be insane. <shudder>

> >     You forgot the step of re-installing the ADSM binaries, patches etc
> >back onto the ADSM server. :)
>
> No, I didn't. ADSM binaries and patches are on
> rootvg. You restore rootvg, you restore ADSM.

     Oops!  I looked back at what you said, and you are consistent with
what you had said before.  Sorry, in light of that, this was an odd comment
on my part.  :)

> In your cluster solution, you will be dealing with a
> very dangerous aspect of HACMP : the possibility of
> having different data files on each site of the cluster.
> Have you ever worked with HACMP ? CLAM and IBM
> does not suggest this kind of solution ...

    I think we have been misunderstanding each other.  We are, in fact,
stating pretty much the same solution, with the exception that you create
symlinks on each box to config files on the shared disk.

   And yes, I have worked with HACMP as well as HA products on
other platforms.  As you have misunderstood my solution, I can
understand your skepticism.


> >    From this discussion, I don't think you're paranoid enough about being
> >able
> >to recover your data, but hey -- that's your comfort level.
>
> Please, don't use such word as "paranoid". But as a system
> support specialist, I should be very concerned with
> data protection, availability and consistency, because they
> are often much more dear to the corporation then a
> humble system support specialist.

    I'm taking a lot less umbrage at your heavy-handed comments
now that I know where our misunderstanding lies.

> Kells, HACMP is not DRM.

<sarcasm  mode on>
     No way!  Is THAT why I had to write two SEPARATE exams
in order to get HACMP and ADSM certifications!  Wow! :)
<sarcasm mode off>

> Finally, if you think I am paranoid with recovery, maybe
> you should change your opinion before working on a
> bigger, critical, big-money-flying-around solution.

    Actually, I didn't think you were paranoid enough, because of
your failure to address the two types of scenarios I was thinking of
(and finally! stated explicitly in this e-mail).

> PS: let's stop this discussion ? You have your
> point and I have mine.

   Agreed.  G'day!


kells