cancel
Showing results for 
Search instead for 
Did you mean: 

DB13 job running as <sid>adm instead of ora<sid>

Former Member
0 Kudos

Of course I am a 1 year newbie to SAP as a SAP DBA...

The jobs I scheduled in DB13 were creating logs under ora<sid> with no permission problems.

I recreated the schedule on the 12th as the same user that was running the jobs and now they are failing with permissions issues on the saparch directory.

So I altered the directory to 777 so anyone could write to it and it appears the jobs are now running as <sid>adm.

Although, it then failed cuz no permissions to run brarchive and other issues.

Here is an ls on the logs:

-rw-rr 1 orapdm sapsys 18016 Apr 9 03:38 aecyxhbf.svd

-rw-rr 1 orapdm sapsys 4207140 Apr 11 03:54 archPDM.log

-rw-rr 1 orapdm sapsys 18016 Apr 11 03:54 aeczheba.svd

-rw-rr 1 pdmadm sapsys 1848 Apr 14 11:00 aeczxjkj.svd

-rw-rr 1 pdmadm sapsys 1984 Apr 14 11:06 aeczxjwx.svd

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Ah... yes... the question of how could the sticky bit be changed on a system that has been in place for two years..

And only on one of the br exe's. This is unexpected and difficult to pinpoint. Unless your aware of some way that the permissions could get changed by the SAP system... without human intervention.

In any case, thank you everyone for your quick reply's.

Former Member
0 Kudos

Thank you... I had already referenced that note, just didnt double check everything, I was more focused on the file permissions issue.

Sure enough... somehow the permissions were no longer correct for brarchive(see below).

Interesting though.. that apparently the jobs from db13 start with <sid>adm and then run as ora<sid>.

The log file is again owned by ora<sid>.

> ls -l br*

-rwxrwxr-x 1 orapdm dba 5895976 Aug 5 2007 brarchive

-rwsrwxr-x 1 orapdm dba 6054320 Aug 5 2007 brbackup

-rwsrwxr-x 1 orapdm dba 7842640 Aug 5 2007 brconnect

-rwxrwxr-x 1 orapdm dba 6420368 Aug 5 2007 brrecover

-rwxrwxr-x 1 orapdm dba 2336816 Aug 3 2007 brrestore

-rwxrwxr-x 1 orapdm dba 8188440 Aug 5 2007 brspace

-rwsrwxr-x 1 orapdm dba 3460328 Aug 5 2007 brtools

> chmod 4775 brarchive

> ls -l br*

-rwsrwxr-x 1 orapdm dba 5895976 Aug 5 2007 brarchive

-rwsrwxr-x 1 orapdm dba 6054320 Aug 5 2007 brbackup

-rwsrwxr-x 1 orapdm dba 7842640 Aug 5 2007 brconnect

-rwxrwxr-x 1 orapdm dba 6420368 Aug 5 2007 brrecover

-rwxrwxr-x 1 orapdm dba 2336816 Aug 3 2007 brrestore

-rwxrwxr-x 1 orapdm dba 8188440 Aug 5 2007 brspace

-rwsrwxr-x 1 orapdm dba 3460328 Aug 5 2007 brtools

Former Member
0 Kudos

Hi Paul,

I am happy that reffering the SAP note again, help you to understand where you made mistake in permissions (sticky bit).

That's what I wanted suggest actually...

Regards.

Rajesh Narkhede

Former Member
0 Kudos

Hi Paul,

Just set the BRTools permissions as per the below note.

[113747 - Permissions for DBA tools BRTools and SAPDBA|https://service.sap.com/sap/support/notes/113747]

Your problem will get solved !...

Also check the permission of "saparch" directory... It should be writable for ora<SID> user.

Regards.

Rajesh Narkhede

Former Member
0 Kudos

Check your br* tools under your kernel has correct permission.

If not, please run "/sapmnt/PDM/exe/saproot.sh PDM" to set correct permission.