Update:

So the problem ended up being that the VCS Oracle Agent StartUpOpt I was 
using was:

SRVRCTLSTART (aka. srvctl)

Since this is a RAC environment, srvctl seems to not directly call the 
database to start, it calls for CRS to do it....specifically: 
crsd.bin....which I'm guessing is normal for Oracle RAC?.....

Since crsd.bin is owned and run by root, not Oracle or Oracle CRS 
user...that is why it was always inheriting the "system" contract....

So to fix, I made the change in the file /etc/init.d/init.crsd:
FROM
$ORA_CRS_HOME/bin/crsd $BOOTFLAG $*
TO
/usr/bin/newtask -p Oracle $ORA_CRS_HOME/bin/crsd $BOOTFLAG $*

So in the end, it was not a Veritas issue....it was due to the fact I'm 
running RAC and me not knowing the intricacies of how Oracle RAC is 
really running....ie. srvctl calling CRS to start the DB instances...

So what you are recommending I'm sure must work in non-RAC environments.

Thanks.

-Bryan

James T. Wonder wrote:
>
> Bryan,
>
>    Something is very strange then.  I have a customer with Solaris 10 
> running Oracle 10G and resource manager and we set it up exactly as I 
> outlined and all works fine.  I can see all the processes in the 
> correct project after the DB starts up.  I might think you have 
> another problem that is outside what we are trying to fix at this 
> point.  I would try starting the DB by hand with the newtask command 
> and see if that works.  What I do is log-in and the simply execute the 
> newtask -p <project> -c $$ in the shell to make it go to the correct 
> project.  You can verify by running "id -p" that the shell is indeed 
> in the correct project.  Then start Oracle and see if the processes 
> are in the correct project.
>
>    By the way, the /etc/system does not work in Solaris 10 for Oracle, 
> you must use the /etc/project file.  The problem with VCS is that it 
> runs as root, and root defaults to "default" or "system" depending on 
> your setup.  Most of my customers want a database or a group of 
> databases per project to allow them to control the resources.  i.e. 
> test dbs, standby dbs or production dbs sharing the same box.
>
>    Hope this helps.
>
> James
>
>
>
>
> On Apr 13, 2007, at 9:39 AM, Bryan Pepin wrote:
>
>> Update:
>>
>> I tried putting the following script to be run as part of the EnvFile
>> Attribute of the Oracle agent.
>>
>> Unfortunately this did not work either.
>>
>> #!/bin/sh
>> echo "Setting Project to Oracle"
>> /usr/bin/newtask -p Oracle -c $$
>>
>> I see the file get executed, ie. the output from the echo command, but
>> still does not get it to work.
>>
>> Seems that for our environments running Solaris 10 with VCS Oracle
>> agents will need to continue to use the /etc/system file.
>>
>> -Bryan
>>
>> James T. Wonder wrote:
>>>
>>> Bryan,
>>>
>>>    What I have done in the past is to use an environment file in the
>>> agent configuration to assign the proper project to the starting
>>> process.  I have done this by making an environment file with
>>> something like:
>>>
>>> #!    /bin/sh
>>> newtask -c $$ -p 'IPC Tunables'
>>>
>>> which tells it to put the current process ($$) into the project
>>> listed.  This way you can have one environment file for each database
>>> you are starting, and start each in a different project if you wish.
>>>
>>> Remember that the listeners also need to source the very same
>>> environment file due to the fact that remote connections (local=no)
>>> will go into the default or system project by default.  By starting a
>>> listener per project you guarantee that the limits will be honored.
>>>
>>> Hope this helps...
>>>
>>> James
>>>
>>>
>>> On Apr 11, 2007, at 10:03 PM, Jim Senicka wrote:
>>>
>>>> Bryan
>>>> Unfortunately, at this time the VCS 5.x agents are pretty much not
>>>> designed to work in an SRM environment. We are looking at what it will
>>>> take to support this
>>>>
>>>> -----Original Message-----
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED] On Behalf Of Bryan
>>>> Pepin
>>>> Sent: Tuesday, April 10, 2007 4:34 PM
>>>> To: [email protected]
>>>> Subject: [Veritas-ha] VCS 5.0 / Solaris 10 Resource Controls / Oracle
>>>> Agent
>>>>
>>>> Hello,
>>>>
>>>> In the process of deploying Oracle 10g on top of SFRAC 5.0 running
>>>> Solaris 10, I've noticed the following issues around setting shared
>>>> memory parameters for Oracle. The Oracle Agent does not assume the
>>>> project that I have assigned to the Oracle user? It is assuming the
>>>> system project, and when I try to add the resource controls to that
>>>> system or the default project, that does not work either?
>>>>
>>>> Here are the details:
>>>>
>>>> Trying to use Solaris' new project methodology to establish the IPC
>>>> tunables, here is what I did:
>>>>
>>>> # projadd -c 'IPC Tunables' -U oracle -G dba -K
>>>> 'project.max-shm-memory=(privileged,16gb,deny)' user.oracle
>>>>
>>>> Now, as the Oracle user, this allows the DB to open without issue.
>>>>
>>>> However, when I configure the Oracle VCS agent to start the DB, it
>>>> appears that the VCS processes are assuming the "system" project, and
>>>> when they start the database processes, they are assuming the roles of
>>>> that project, rather than those of the oracle user that I have 
>>>> defined?
>>>>
>>>> Here is the error in the messages file when the DB tries to open from
>>>> the VCS agent:
>>>>
>>>> [ID 883052 kern.notice] privileged rctl project.max-shm-memory (value
>>>> 6291603456) exceeded by project 0
>>>>
>>>> So I logically thought I could apply the same tunings to the system
>>>> project, but that does not work either.
>>>>
>>>> This is what my project file looks like:
>>>>
>>>> system:0::::process.max-sem-nsems=(privileged,4096,deny);\
>>>> process.max-sem-ops=(privileged,4096,deny);project.max-sem-ids=(privileg 
>>>>
>>>> ed,4096,deny);\
>>>> project.max-shm-ids=(privileged,512,deny);project.max-shm-memory=(privil 
>>>>
>>>> eged,17179869184,deny)
>>>> user.root:1::::
>>>> noproject:2::::
>>>> default:3::::
>>>> group.staff:10::::
>>>> user.oracle100:IPC
>>>> Tunables:oracle:dba:process.max-sem-nsems=(privileged,4096,deny);\
>>>> process.max-sem-ops=(privileged,4096,deny);project.max-sem-ids=(privileg 
>>>>
>>>> ed,4096,deny);\
>>>> project.max-shm-ids=(privileged,512,deny);project.max-shm-memory=(privil 
>>>>
>>>> eged,17179869184,deny)
>>>>
>>>> What I have been able to do is change the parameters on the fly with
>>>> prctl:
>>>>
>>>> # ps -ef -o pid,project,args | grep -i OracleAgent --> to get the PID
>>>> and Project # prctl -n project.max-shm-memory -i process <PID> --> to
>>>> display # prctl -n project.max-shm-memory -r -v 16gb -i process <PID>
>>>> --> to set
>>>>
>>>> Once I do that, it allows me to start the database via the Oracle 
>>>> Agent.
>>>>
>>>> Has anyone run into this issue?
>>>>
>>>> This may be me not properly setting up the system project, but I 
>>>> figure
>>>> someone must have run into this and they could share how they resolved
>>>> it.
>>>>
>>>> I'm hoping there is an easy solution out there, rather than having to
>>>> always change the parameter on the running Agent?
>>>>
>>>> Hope that all makes sense.
>>>>
>>>> Thanks.
>>>>
>>>> -Bryan
>>>>
>>>> PS. What I have realized is that if I put the shmmax parameters in the
>>>> /etc/system that works, but I was hoping to have to fall back into 
>>>> that
>>>> routine.
>>>>
>>>> --************************************************
>>>> Bryan Pepin
>>>> Unix Enterprise Systems
>>>>
>>>> EMC Corporation
>>>> 4400 Computer Drive
>>>> Westboro, MA 01580
>>>> 508-898-4776
>>>> [EMAIL PROTECTED]
>>>>
>>>> _______________________________________________
>>>> Veritas-ha maillist  -  [email protected]
>>>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
>>>>
>>>>
>>>> _______________________________________________
>>>> Veritas-ha maillist  -  [email protected]
>>>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
>>>
>>>
>>>
>>>
>>
>> --************************************************
>> Bryan Pepin
>> Unix Enterprise Systems
>>
>> EMC Corporation
>> 4400 Computer Drive
>> Westboro, MA 01580
>> 508-898-4776
>> [EMAIL PROTECTED]
>>
>> _______________________________________________
>> Veritas-ha maillist  -  [email protected]
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha
>
>
>
>

-- 
************************************************
Bryan Pepin
Unix Enterprise Systems

EMC Corporation
4400 Computer Drive
Westboro, MA 01580
508-898-4776
[EMAIL PROTECTED]

_______________________________________________
Veritas-ha maillist  -  [email protected]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Reply via email to