Best practices with Oracle and root access

[Rick Garland]

I have not seen such a document.
In regards to the root.sh script, as you are aware this is only run once during the install. DBAs do not need root access, EVER!

If this is such a worry, put them in sudoers for a limited time - until the database install is complete. Then yank him out.

[Pat Obrien_1]

My DBA's don't require me to run this script very often. Once a quarter maybe for production systems. I use sudo, and it is so rare we have not made a rule there for them. Wonder why yours feels the need?

[Indira Aramandla]

Hi Geoff,

â Should DBA have root accessâ , this should not be a subject of a document of â Best Practicesâ .

Because a DBA will not require root access to perform his daily database administration tasks. Oracle, for example, has several tools with which you can administer Oracle itself, almost negating the need for a UNIX login altogether. One of these on the high-end being Enterprise manager, and on the other low-end being the Oracle client.

DBA's should have non-root access to the servers and would require a some sudo access. To run root.sh will not be a frequent job. It will be on new installations and patches which would be once in 6 months or so. DBAâ s require server access to troubleshoot their own backups and space issues.

It will be a good practice to build up a good rapport between the DBAâ s and Sysadmin teams in the events when some of the tasks of one team require the other team to run the jobs. This should be considered as sharing rather than â I donâ t want to bother you all the timeâ .

Another issue is server accountability within a given IT organization. How secure have you made your server. If the DBA's and Sysadmin's reported to the same supervisor, it will be a bad idea to share root access across food chains.

I once worked in an organisation where I was UNIX Sysadmin and the DBA. I also, worked at one firm where I had dba access with no root access. And I can say as a DBA with non-root access I could perform my instance admin tasks without any issues.



Indira A

[Sanjay Kumar Suri]

root access is only needed for runing root.sh during Oracle upgrade process. This is also mentioned in the Oracle upgrade document released by SAP: http://service.sap.com/instguides

Sample output from root.sh is enclosed below (to get an idea of what it does) during Oracle upgrade from 8i to 9i:

Enter the full pathname of the local bin directory: [/usr/local/bin]: press enter
(Backup the following three files)
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y
Copying coraenv to /usr/local/bin ...

Adding entry to /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script

Yes you are right: It is called root.sh - because Oracle (and SAP) want you to get a sysadmin to run that script for you.

Oracle admin and OS admin are two different roles and should be performed by two differnt people. However in some organization it is done by one for shortage of manpower.

The reason given by DBA in this case does not hold. If DBA has to bother sysadm then he has to; especially in this case when sysadm would like OS to be protected from all quarter.


sks

[Eric Antunes]

Hi Geoff,

The question is not just about root.sh...

Yesterday, for example, I recovered a Production database and loose a day of work because of data corruption in the morning.

The solution was to place the 07 February end of the day database backup, change the system date BACKWARD from 09 to 08 February and redo all Wednesday work. Because I'm the system and database administrator, I didn't need to call anybody to change the date form me.

So, you won't find any satisfactory document about this question but in my opinion, in your situation you should avoid giving him direct access to root.

Best Regards,

Eric Antunes

[Alzhy]

Eric, you nailed it.

You epitomize the ideal System Administrator - who's also a Database Administrator. There are now actually enterprises out there who value (and require) System Admins also act as DBA's or vice versa. This increases the efficiency of overall administration of a system - by cutting the proverbial "how many XYZ Company IT hands is needed to fix a lightbulb" -

And some CIOs are now actually discovering that Small IT Shop techniques (i.e. IT Staff responsible for multipe roles) also apply to big IT shops.

And it cuts cost too! ;^)

[Eric Antunes]

Nelson, that's precisely my point of view. Specialization is good but it can't be too deep.

With Oracle, for example, the DBA must know until where he can increase the SGA without hurting the whole system (Paging out, etc...) and to achieve this he must be a system administrator too.

Best Regards,

Eric Antunes

[Jeff Schussele]

Eric/Nelson,

Well....you can get away with that in smaller organizations.
But we literally have dozens of DBAs & over a hundred SAs - of all UNIX flavors
We can't afford to do this.
sudo is our huckleberry.

My $0.02,
Jeff

[Alzhy]

And that is actually slowly changing Jeff as more and more CIO/IT leaders are being promoted from the "ranks" - so they "know".

And with today's OSes and RDBMSes starting to get to be easily managed and with an abundance of tools - these new breed of CIOs/IT leaders actually know what is really required in an Organization and what each staff can actually do. In organizations I consult with - I have seen SysAdmin to Servers Ratio drop from 1:5 to 1:50 in the last five years. I've also seen consolidation of roles like - ersthwhile Storage Admin, Network Admin and UNIX System Admin positions now being handled by a lone person. And DBA's are increasingly provided with UNIX Admin and Storage Admin skills and roles as well.

[Ken_109]

Eric,

I respectfully disagree.. Specialization is everything. To prove my point.. An oracle recover is SCN based not time based, you can choose to recover to a point in time of course.

Without knowing the details of your recovery situation I'd say that your data loss of 1 day was most probably avoidable...

Send me your configuration and details and I'll be happy to review it for availability.

kennethinbox-forums@yahoo.com

Ken