oinstall vs. dba UNIX Group
Michael42
As many of you I always installed Oracle versions (7-9) on UNIX
systems using "dba" as the primary group. On new 10g Database
installations the installation guide advises the use of "oinstall" as
the primary group and "dba" as the seconday group.
With the installation of a new system there are no concerns.
Installing 10g on a system with 9 can be a little tricky in the area
though.
>From your point of view, what are the pros and cons of using oinstall
as the primary group rather than dba?
Thanks,
Michael
DA Morgan
The pro is that you are following best practice, as recommended by
Oracle, and if something goes wrong you will likely get better support.
Of course you will also gain a measure of flexibility if installing
multiple products which is, I believe, the point.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
hpuxrac
The only "pro" to using oinstall is IF you have people that will be
installing and maintaining oracle software that are NOT part of the
dba group.
How many people and sites actually operate with people that do that
( complicated ) oracle software maintenance activities that are not
"operationally or organizationally" part of the oracle dba group? Not
many in my experience.
Captain Morgan's reply is off target. Oracle will fully support
oracle installs based on whatever group name's and user names ( ie not
actually oracle ) you select.
Mark D Powell
>
> - Show quoted text -
I think oinstall exists at least partially for those sites that have
split the DBA job function into Infrastructure DBA and Application DBA
where the Application DBA's work with the developers but are not
responsible for installation, configuration, or tuning of the database
itself. The Infrastructure DBA does that along with applying all the
patches. The Infrastructure DBA does not create objects (except via
Oracle provided scripts like catalog, catproc, etc...), touch user
data, or issue any application grants.
I agree with hpuxrac that there is no real benefit at this point in
time to not using DBA if you have not split the DBA job function.
HTH -- Mark D Powell --
HansF
> From your point of view, what are the pros and cons of using oinstall
> as the primary group rather than dba?
I'm thinking that this is yet another SarbOx reaction - auditable
separation of the jobs to install the software vs the daily operations.
In the installs I;ve done, I have not seen an impact either way on the
operation.
That said, oinstall is a group that has write access to the inventory
whereas dba typically does not.
Implication is simple - does your shop permit the general DBA to manage
patches? If yes, then no impact ... if no, then keep 'em separate.
--
Hans Forbrich (mailto: Fuzzy.GreyBeard_at_gmail.com)
*** Feel free to correct me when I'm wrong!
*** Top posting [replies] guarantees I won't respond.
Michael42
I guess in short, if I choose to NOT create an "oinstall" group and
have everything continue to be owned by "dba" it should still be OK it
sounds like.
I have a slight concern that Oracle might put out a patch that
requires "oinstall" be in place, this goes back to Dan's point of
sticking to the docs, i.e. the Oracle published\recommended way.
Thanks again,
Michael
HansF
> Thanks all very much for the very diverse take on this topic.
>
The thing I find with Oracle - it is designed for the entreprise from the
ground up. If I stop at just technology perspective, I only understand
about 1/2 of the stuff in there. If I think about the business side as
well, I often get an 'ah ha' as to why it's done a specific way.
It's almost as if Larry is in the design meetings asking "what impact will
that have on the CEO's business? how does that help his: availability?
revenue generation? shareholder value? bottom line?" (Not that it does,
but the development team had better have some answer in that area!)
> I guess in short, if I choose to NOT create an "oinstall" group and
> have everything continue to be owned by "dba" it should still be OK it
> sounds like.
>
> I have a slight concern that Oracle might put out a patch that
> requires "oinstall" be in place, this goes back to Dan's point of
> sticking to the docs, i.e. the Oracle published\recommended way.
I would temper Daniel's comment. It's still a slight issue (as explained
at the end) but not a biggie.
Although Oracle has not made it clear in the docco, Oracle database
environment has 3 'group definitions' - OSDBA, OSOPER and oinstall. The
first two are well documented, as in
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/dba.htm#sthref150
but the last is somewhat hidden.
Interesting to note is that the value for "oinstall" and "OSDBA" groups
are prompted by the OUI during install. oinstall is then used by the root
config script in the inventory base directory to do the chown of the
inventory directories and files.
Therefore, the 'support' issue should only be visible when doing a second
install and the install group is not the same as the one that owns the
inventory. In which case, the support call will probably end with a
Homer Simpson (trademarked) 'DOH!' by the person requesting support.
Niall Litchfield
>> The only "pro" to using oinstall is IF you have people that will be
>> installing and maintaining oracle software that are NOT part of the
>> dba group.
>>
>
> I think oinstall exists at least partially for those sites that have
> split the DBA job function into Infrastructure DBA and Application DBA
> where the Application DBA's work with the developers but are not
> responsible for installation, configuration, or tuning of the database
> itself. The Infrastructure DBA does that along with applying all the
> patches. The Infrastructure DBA does not create objects (except via
> Oracle provided scripts like catalog, catproc, etc...), touch user
> data, or issue any application grants.
>
> I agree with hpuxrac that there is no real benefit at this point in
> time to not using DBA if you have not split the DBA job function.
That's certainly one advantage. I think however the primary benefit of
this design involves considering more than just the one database, or
more than just the one piece of software.
Two examples.
First up, you may consider it sensible to host more than one database on
the same hardware for different groups within a business. Either because
you want to run different versions, or for political or security
reasons, particularly in the latter case it isn't a great stretch to
imagine that you'd want two different sets of dbas, with appropriate dba
group memberships. You'd be unlikely however to wish to have two
separate inventories.
Second, Oracle corp do sell more than just the database software. It
isn't at all inconceivable that you might run an application server and
a database server on the same box. Again in this situation it isn't a
great leap to imagine that you might wish to separate the roles of
software maintenance from straight dba responsibility.
Having the two groups gives more flexibility than if there were just the
one. It's a shame therefore to my mind, that on windows the installer
has to be a local administrator of the server, and on *nix that root
access is needed.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info/services
hpuxrac
> On Fri, 16 Feb 2007 13:12:17 -0800, Michael42 wrote:> separation of the jobs to install the software vs the daily operations.
> > From your point of view, what are the pros and cons of using oinstall
> > as the primary group rather than dba?
>
> I'm thinking that this is yet another SarbOx reaction - auditable
Well it could only be a reaction if this was changed and then
standardized/recommended by oracle "after" sox. But it's been around
for a very long time.
>
> In the installs I;ve done, I have not seen an impact either way on the
> operation.
>
> That said, oinstall is a group that has write access to the inventory
> whereas dba typically does not.
>
> Implication is simple - does your shop permit the general DBA to manage
> patches? If yes, then no impact ... if no, then keep 'em separate.
Probably I should have been clearer in my original reply.
Does my shop use the oinstall and dba groups? Yes we do.
Do we really need to operate like that. Not really.
If a shop has done the oracle installs and just used the dba group is
that a problem? No.
HansF
> On Feb 16, 10:10 pm, HansF <Fuzzy.Greybe...@gmail.com> wrote:
>> On Fri, 16 Feb 2007 13:12:17 -0800, Michael42 wrote:> separation of the jobs to install the software vs the daily operations.
>
>> > From your point of view, what are the pros and cons of using oinstall
>> > as the primary group rather than dba?
>>
>> I'm thinking that this is yet another SarbOx reaction - auditable
>
> Well it could only be a reaction if this was changed and then
> standardized/recommended by oracle "after" sox. But it's been around
> for a very long time.
The intention of my statement was to highlight the rationalle used by
SarbOx (job separation, auditability) rather than blame SarbOx
specifically.
Oracle has being promoting logical job separation for a loooooong time -
Chapter 1 of the Administrator's Guide has made that clear, way back to
Oracle 7.0 and possibly earlier.
Sorry for being unclear.
>
>>
>> In the installs I;ve done, I have not seen an impact either way on the
>> operation.
>>
>> That said, oinstall is a group that has write access to the inventory
>> whereas dba typically does not.
>>
>> Implication is simple - does your shop permit the general DBA to manage
>> patches? If yes, then no impact ... if no, then keep 'em separate.
>
> Probably I should have been clearer in my original reply.
>
> Does my shop use the oinstall and dba groups? Yes we do.
>
> Do we really need to operate like that. Not really.
>
> If a shop has done the oracle installs and just used the dba group is
> that a problem? No.
In that we agree. You can take my response as further supporting
yours.
---
HURLEY WINFORD HEMINGWAY
✅ เข้าเว็บไซต์
http://bit.ly/3RPBnb1
✅ สมัครสมาชิก
http://bit.ly/3RPBnb1
✅ ติดต่อเรา
http://bit.ly/3RPBnb1
✅ รับโปรโมชั่น
http://bit.ly/3RPBnb1