Hi,

On Wed, Mar 12, 2008 at 11:09:36AM +0900, HIDEO YAMAUCHI wrote:
> Hi Dejan
> 
> >> (oralce-RA) 
> >> 1.I supported fail over with the backup mode. 
> >> When a clear_backupmode parameter is appointed, and there is it, I examine 
> >> a backup mode. 
> >> And I remove a backup mode. 
> >> If we do not appoint this parameter, oracle is the same as a former 
> >> version. 
> >
> >Does this influence in any way the shutdown method? Wouldn't 
> >shutdown abort take care of this automatically? What I'm worried 
> >about is that this command might hang under some circumstances. 
> 
> I think that do not influence shutdown, but what kind of
> condition do you worry about being hung up in?

Oracle is heavy weight ;-) Sometimes it's not easy to predict
which way it will go. Anyway, since this is an optional
attribute, we may as well include it.

> >> 2.I revised it to be able to output log of oracle precisely. 
> >> This revision is sake corresponding to the problem of our character code. 
> >> 
> >> (old) SU $ORACLE_OWNER 
> >> (new) SU - $ORACLE_OWNER 
> >
> >Are you refering to the Japanese language environment? Can you 
> >elaborate further on this? The difference betwen 'su' and 'su -' 
> >is that the latter executes the startup scripts such as .profile. 
> >I can't recall exactly anymore, but I think that there was a 
> >reason why I've chosen 'su' and not 'su -'. 
> 
> Yes, it is Japanese environment.
> I can set even .profile, but I surely think that there is not the problem 
> with su.

'su -' executes .profile. So, without 'su -' your sqlplus won't
work?

> I don't understand why you did not choose the 'su -' command.
> After all is the 'su -' command not good?

'su -' implies executing scripts which sometimes may be rather
involved and include non-trivial environment changes. Often it
also prints something to stdout/stderr which would fill the logs.

> >> 3.Like oralsnr, I changed it to use the runasdba function. 
> >> The reason is because it thought that I am easy to watch a similar source. 
> >
> >oracle and oralsnr share some code, but, unfortunately, it hasn't 
> >been put into a separate file. That's why there is runasdba in 
> >oracle even though it is not used. Perhaps now that we have 
> >OCF_ROOT we can also take care of that. Note that runasdba means 
> >exactly what it says: run a command as the dba user. The change 
> >you made also changes the meaning, i.e. we should rename the 
> >function for example to execsql. 
> 
> According to your suggestion, let's change it into a name called execsql.
> Possibly do I understand your opinion by mistake?

No, you understood it correctly.

> >
> >> 4.I changed it for a step-by-step stop. 
> >> The first stop is too dangerous in abort. 
> >> For security, you had better stop from immediate sequentially. 
> >
> >Is there a chance for shutdown immediate to hang? Did you test 
> >this under various (and unfavourable) circumstances? Again, can't 
> >recall exactly (need new memory ;-), but I think that there was a 
> >reason not to use shutdown immediate at all. 
> 
> However, is not abort for the shutdown considerably dangerous?

No, because there's a checkpoint before shutdown.

> Possibly abort may be made to stop the effective processing.
> After all I think that I should stop step by step.

Apparently shutdown immediate may take a while. Given typical
timeouts this may be an issue, because once the stop fails there
will be an implicit "shutdown abort" (through stonith) and that,
without a checkpoint, could make the next startup long depending
on the rollback size. There are even reports that the database
may require lengthy and manual recovery.

Anyway, it is not good to change the semantics of the stop
action. If you still insist on using "shutdown immediate", we may
introduce another attribute: shutdown_method which could take two
values "checkpoint/abort" (default) and "immediate".

> >> (oralsnr-RA) 
> >> 1.For our demand of a special customer, I added the restart of monitor 
> >> disorder. 
> >> This patch permits only one time of monitor error of oralsnr. 
> >> It limits outbreak in fail over by a problem only for oralsnr. 
> >> For this function, I added a parameter of require_once. 
> >> If we do not appoint this parameter, oralsnr is the same as a former 
> >> version. 
> >
> >Must say that I don't like this, i.e. restarting the service in 
> >the monitor operation. It would be preferable to either fix the 
> >service or use the CRM configuration to deal with occasional 
> >service failures. Anyway, why does this happen? >
> 
> This is our special demand.
> After all we should not usually write restart in RA.
> The suggestion of this restart withdraws it as our special patch.

Sorry, I don't follow this. Could you please explain why does it
happen and why can't it be done using the configuration?

> >> 2.I revised it to be able to output log of oralsnr precisely. 
> >> This revision is sake corresponding to the problem of our character code. 
> >> 
> >> (old) SU $ORACLE_OWNER 
> >> (new) SU - $ORACLE_OWNER 
> >> 
> >> 3.I revised a spelling error. 
> >> pATH -> PATH 
> >
> >Oops. Wonder how did this typo survive for such a long time. 
> >
> >> Give me an opinion about this patch and if there is not a problem, please 
> >> adopt it. 
> >
> >There is one typo: dbsql instead of dbasql. 
> I'm sorry. It is a mistake.
> 
> >
> >The patch is much bigger than it should be because there's a mix 
> >of spaces and tabs in indentation. That makes it hard to follow 
> >what has changed. Can you please use only tabs for indentation. 
> 
> I wait for your comment and contribute the thing which I revised to a tab.

Sorry that it took so long. I was out refreshing memory ;-)

Cheers,

Dejan

> Regards,
> Hideo Yamauchi.
> 
> 
> 
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to