Re: Using GRID Infrastructure to control third party applicaitons?

From: Ls Cheng <exriscer_at_gmail.com>
Date: Tue, 26 Jan 2016 00:49:37 +0100
Message-ID: <CAJ2-Qb9yNd=6me+F4WQbJcmCcEDQY_RfsXOdPRcUJddAjx-1xA_at_mail.gmail.com>

Hi

In 12c you have to look in $ORACLE_BASE/diag/..................

(DIAGNOSTIC_DEST) On Mon, Jan 25, 2016 at 8:02 PM, Mark J. Bobak <mark_at_bobak.net> wrote:

> Hi Ilmar,
>
> Thanks for the reply. It appears the log doesn't exist in 12c, or it has
> a different name....
>
> [oracle_at_my_new_test log]$ pwd
> /u01/app/12.1.0/grid/log
> [oracle_at_my_new_test log]$ find . -name script\*
>
> No results under DRS_HOME/log for any filename starting with 'script'.
>
> I'll poke around, see if I can figrue out the correct log file.
>
> -Mark
>
> On Mon, Jan 25, 2016 at 11:45 AM, Ilmar Kerm <ilmar.kerm_at_gmail.com> wrote:
>
>> Hi
>>
>> We have run it successfully for years to provide high availability for
>> MySQL and currently I'm also setting it up to have a cold standby for
>> Oracle database in Windows.
>>
>> I haven't seen the attributes START_PROGRAM,STOP_PROGRAM and PID_FILES.
>> Are they new in 12.1?
>> In 11.2 I've only used attribute ACTION_SCRIPT that points to the script
>> that handles startup/stop and check actions.
>>
>> Could you have problem with the check action? After start and stop
>> actions clusterware will also invoke check action to verify that
>> startup/shutdown was successful.
>> You could verify it from scriptagent logfile:
>> $CRS_HOME/log/<hostname>/agent/crsd/scriptagent_<username>
>> It logs all the actions executed and the responses.
>>
>> My old presentation about this topic:
>>
>> http://www.slideshare.net/ilmarkerm/making-mysql-highly-available-using-oracle-grid-infrastructure
>>
>> Ilmar
>>
>> On Mon, Jan 25, 2016 at 5:28 PM, Mark J. Bobak <mark_at_bobak.net> wrote:
>>
>>> Hi all,
>>>
>>> Has anyone sucessfully done this? In my case, I've managed to figure
>>> out how to create teh necessary resource, but it doesn't actually work.
>>>
>>> What I'm tying to do, is start up a Glassfish server (running on the DB
>>> server, single instance, in my case), with a dependency on the database. I
>>> have ORDS (formerly known as APEX Liostener) deployed in Glassfish, and if
>>> I just start Glassfish via init.d, it will start before the database, and
>>> gets stuck reporting 404, even after the db starts, until I bounce
>>> Glassfish. So, I want to start if from GI home, using crs/has, and have a
>>> dependency on the db, to solve the startup sequence issues. (Also, to make
>>> it (presumably?) stop and stat automatically whenever the DB is bounced.)
>>>
>>> So, I created the resource, like so:
>>> crsctl add resource glassfish -type generic_application -attr
>>> "START_PROGRAM='/etc/init.d/glassfish_domain1
>>> start',STOP_PROGRAM='/etc/init.d/glassfish_domain1
>>> stop',START_DEPENDENCIES='hard(ora.orcl.db)',STOP_DEPENDENCIES='hard(ora.orcl.db)',PID_FILES=/var/run/glassfish.pid"
>>>
>>> This seems to have worked, no error is returned, and one can query the
>>> resource and see it exists:
>>> crsctl status res glassfish
>>> NAME=glassfish
>>> TYPE=generic_application
>>> TARGET=OFFLINE
>>> STATE=OFFLINE
>>>
>>> But, when I try to start it, I get this:
>>> crsctl start res glassfish
>>> CRS-2672: Attempting to start 'glassfish' on 'my_new_test'
>>> CRS-2674: Start of 'glassfish' on 'my_new_test' failed
>>> CRS-2679: Attempting to clean 'glassfish' on 'my_new_test'
>>> CRS-2681: Clean of 'glassfish' on 'my_new_test' succeeded
>>> CRS-4000: Command Start failed, or completed with errors.
>>>
>>> And, at the end, the glassfish server is, in fact, running. So, it
>>> thinks it failed to start, but it starts, then it does the clean, and it
>>> thinks it cleaned everything up (remove logifle and pid file and kill
>>> process) but it in fact remains running.
>>>
>>> I suspect that there is a 'tamplate' for the startup/shutdown script? I
>>> found a doc on MOS, that says my script must accept 'start','stop','clean,
>>> and 'check' as parameters. When I run my sript from the command line, it
>>> works beautifully, and those parameters all work as expected.
>>>
>>> So, my next guess is return values? Not sure what to try next...
>>>
>>> Has anyone gotten this to work? Any idea what I'm missing from my
>>> script?
>>>
>>> Thanks,
>>>
>>> -Mark
>>>
>>
>>
>>
>> --
>> Ilmar Kerm
>>
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Jan 26 2016 - 00:49:37 CET