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? > >> 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. I don't understand why you did not choose the 'su -' command. After all is the 'su -' command not good? > >> 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? > >> 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? Possibly abort may be made to stop the effective processing. After all I think that I should stop step by step. > >> (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. > >> 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. Regards, Hideo Yamauchi. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
