Hi Dejan Thank you for comment.
> 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. I understood it. Then because this is an optional attribute, I just have it and suggest 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? The English message is given to the log. And it work. But, we want to take out a Japanese message in log. I understand setting such as .profile which you say. I want to omit the setting of troublesome NLS_LANG, besides. The simplest realization method is 'su - '. #But, I think even English log not to have any problem when I think about your concern. How do you think? > > > 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. Thank you. All right. > > > > > > >> 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". Then I want to suggest that I appoint the option attribute that you say. I add a parameter to a patch. > > > >> (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? We do not want to control failcount. But, I withdraw it because this is a very special demand. > > > >> 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 ;-) Your opinion intends to have understood by me. I will send the patch which revised later. Regards, Hideo Yamauchi. > > 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/ > _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
