Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

OmniBack II, session owner is always root.

SOLVED
Go to solution
Michael Lopes
Occasional Visitor

OmniBack II, session owner is always root.

I'm trying to run a backup as the owner of my Oracle database and put pre and post scripts into the backup to stop and start the database.

My problem is I can't get the owner of the backup to change to the oracle logon. It always logs on as root. I have a whoami in the script which always shows root.

The oracle owner has been added to the admin and operator groups in OMNIBACK II. I've even tried the Change Owner function and it had no effect.

I've also tried loging onto the unix system as oracle and created the backup but it still runs as root.

Help!
6 REPLIES
Vincenzo Restuccia
Honored Contributor

Re: OmniBack II, session owner is always root.

Don't have the script with su - oracle ?
Gadura Praveen
Frequent Advisor

Re: OmniBack II, session owner is always root.

Michael,

I think what you are looking for, is to run the startup and shutdown scripts for the database as Oracle user. For this , you can create the pre-exec and post-exec files in /opt/omni/lbin . Both these executable files will be owned by root and will have the database startup/shutdown script by su ing to Oracle.

Ex. pre-exec script in /opt/omni/lbin has :-
su - oracle /orasw/dba/db_shutdown

Ex. post-exec script in /opt/omni/lbin has:-
su - oracle /orasw/dba/db_startup.

After this , even if the backups run as root , the post and pre exec scripts will shutdown databases as Oracle user.

Hope this helps.

Praveen
Gadura Praveen
Frequent Advisor

Re: OmniBack II, session owner is always root.

Michael,

I think what you are looking for, is to run the startup and shutdown scripts for the database as Oracle user. For this , you can create the pre-exec and post-exec files in /opt/omni/lbin . Both these executable files will be owned by root and will have the database startup/shutdown script by su ing to Oracle.

Ex. pre-exec script in /opt/omni/lbin has :-
su - oracle -c /orasw/dba/db_shutdown

Ex. post-exec script in /opt/omni/lbin has:-
su - oracle -c /orasw/dba/db_startup.

After this , even if the backups run as root , the post and pre exec scripts will shutdown databases as Oracle user.

Hope this helps.

Praveen
Joseph T. Wyckoff
Honored Contributor

Re: OmniBack II, session owner is always root.

I moved this question here to databases, where I think there are probably lots of people who can help. The tape libraries area is somewhat hardware focused.

Another relevant forum area is 'Openview applications' - where many other Omniback issues are addressed.

Looking at some knowledge base articles that give one approach (I think there are several.)

You can set the job to be run as some owner other than root.

You will also want that owner NOT be a member of the ADMIN group.

Instead, create a group specifically for your Oracle backups. Make sure that the group rights DO NOT INCLUDE 'run backup as root.'

Good Luck.
Omniback and NT problems? double check name resolution, DNS/HOSTS...
Alberto Tagliaferri
Occasional Contributor
Solution

Re: OmniBack II, session owner is always root.

Michael, I've dealed with that problem many times. Two options (I assume your dba account login is "oracle"):
a - leave your shell script run a root and "su - oracle" inside (OB2 does not officilly support suing inside pre/pos exec scripts but it works ok -almost always-).

b - in the backup specification editor set "change ownership" to "oracle". In de "users editor" window, define "oracle" on a group that has "backup as root" capability _disabled_. If it's enabled "change ownership" seems to be ignored (what was very annoying to me until I guessed this).

Hope this helps,

AT.
Michael Lopes
Occasional Visitor

Re: OmniBack II, session owner is always root.

Thanks to all. The answer I was looking for was to remove the oracle user from the admin group in omniback. Once I did that it worked fine.

It also worked with the su but I didn't want the backup running as root.