BRARCHIVE is run by SIDADM instead of ORASID, causing permission denied

[former_member256254]

Hi all,

I have gotten this error this week, while I don't remember performing any change in the configuration.

While doing whole database backup from T-Code DB13, backup is error caused by permission error in the target (the target is disk in another directory).

Checking the target directory with orad11, it have all the authorization needed (read, write, delete). So, chmod 775 is performed in the target dir.

After successfully performed datafile backup, it is seen that the file was written by d11adm instead of orad11. Which is strange.

Currently, Redo-Log backup from DB13 cannot be performed because BRARCHIVE have to delete the archive files after the backup. I think it is not a good practice to set all archive files to be owned by d11adm.

Here is the error message:

BR0002I BRARCHIVE 7.00 (40)
BR0006I Start of offline redo log processing: aefofhhp.svd 2011-03-31 16.34.17
BR0484I BRARCHIVE log file: /oracle/D11/saparch/aefofhhp.svd
BR0477I Oracle pfile /oracle/D11/102_64/dbs/initD11.ora created from spfile /oracle/D11/102_64/dbs/spfileD11.ora
BR0101I Parameters
Name                           Value
oracle_sid                     D11
oracle_home                    /oracle/D11/102_64
oracle_profile                 /oracle/D11/102_64/dbs/initD11.ora
sapdata_home                   /oracle/D11
sap_profile                    /oracle/D11/102_64/dbs/initD11.sap
backup_dev_type                disk
archive_copy_dir               /sapbackup/arch
compress                       no
disk_copy_cmd                  copy
cpio_disk_flags                -pdcu
archive_dupl_del               only
system_info                    d11adm/d11adm srmdev HP-UX B.11.31 U ia64
oracle_info                    D11 10.2.0.4.0 8192 1508 49655535 srmdev UTF8 UTF8
sap_info                       701 SAPSR3 0002LK0003D110011I13760381130015Maintenance_ORA
make_info                      hpia64 OCI_102 Feb 21 2009
command_line                   brarchive -u / -jid LOG__20110331163416 -c force -p initD11.sap -sd
BR0280I BRARCHIVE time stamp: 2011-03-31 16.34.18
BR0008I Offline redo log processing for database instance: D11
BR0009I BRARCHIVE action ID: aefofhhp
BR0010I BRARCHIVE function ID: svd
BR0048I Archive function: save_delete
BR0011I 107 offline redo log files found for processing, total size 4366.435 MB
BR0112I Files will not be compressed
BR0130I Backup device type: disk
BR0106I Files will be saved on disk in directory: /sapbackup/arch
BR0134I Unattended mode with 'force' active - no operator confirmation allowed
BR0202I Saving init_ora
BR0203I to /sapbackup/arch/D11 ...
BR0278E Command output of 'LANG=C cd /oracle/D11/102_64/dbs && LANG=C cp initD11.ora spfileD11.ora /sapbackup/arch/D11':
cp: cannot create /sapbackup/arch/D11/initD11.ora: Permission denied
cp: cannot create /sapbackup/arch/D11/spfileD11.ora: Permission denied
BR0280I BRARCHIVE time stamp: 2011-03-31 16.34.18
BR0279E Return code from 'LANG=C cd /oracle/D11/102_64/dbs && LANG=C cp initD11.ora spfileD11.ora /sapbackup/arch/D11': 1
BR0222E Copying init_ora to/from /sapbackup/arch/D11 failed due to previous errors
BR0016I 0 offline redo log files processed, total size 0.000 MB
BR0007I End of offline redo log processing: aefofhhp.svd 2011-03-31 16.34.18
BR0280I BRARCHIVE time stamp: 2011-03-31 16.34.18
BR0005I BRARCHIVE terminated with errors

We have checked SAPNote 113747, which said that:

brarchive, brbackup, and brconnect must have sticky bit. And this is already applied in the system.

That note also said that brarchive can be started by orad11 or d11adm.

So looks like if this kind of problem happened, we cannot blame d11adm who run the backup.

Please help, moreover if you can give us understanding on what has happened.

Thank you very much for any response.

[former_member266290 · Accepted solution]

Hi

Check the remote user name parameter

remote_user

in init<SID>.sap file.

If it is not set, set to ora<SID> user.

Let us know, if this has resolved your problem.

Regards

[Former Member · Accepted solution]

Basically this is fine, when running brarchive from Db13. You should check the permissions of the executables:

sidadm> ll br*
-rwsrwxr-x 1 orasid sapsys 5474726 Aug 30  2010 brarchive
-rwsrwxr-x 1 orasid sapsys 5599004 Aug 30  2010 brbackup
-rwsrwxr-x 1 orasid sapsys 7258790 Aug 30  2010 brconnect
-rwxr-xr-x 1 sidadm sapsys 6020169 Aug 30  2010 brrecover
-rwxr-xr-x 1 sidadm sapsys 2244652 Aug 30  2010 brrestore
-rwxr-xr-x 1 sidadm sapsys 7677654 Aug 30  2010 brspace
-rwxr-xr-x 1 orasid sapsys 3084175 Aug 30  2010 brtools

Pay attention to the setuid bits.

Cheers Michael

[former_member256254 · Accepted solution]

Hi Vijay and mho,

Thanks for your answers.

I have put remote_user in initD11.sap, but the problem still persists. d11adm wants to write the logfile to the backup dir.

This is actually no problem, but I have once let d11adm write logfile, and error will occured since d11adm cannot delete archive log (-sd mode is chosen)

As to mho, I have checked the sticky bit, it is there, I also have checked sapnote:113747

Hope this problem can be solved. Though I still can perform backup using brtools. But scheduler is not runing

Thank you

[former_member204746 · Accepted solution]

add user SIDADM as part of Unix group "dba"

good luck.

[former_member256254 · Accepted solution]

Hi Eric,

d11adm already member of dba, as seen below:

sapsys::106:dj1adm
dba::107:d11adm,dj1adm,de1adm
oper::108:d11adm,orad11,dj1adm,orade1,de1adm,oradj2

AFAIK, oracle archive files below to orad11 with permission: -rw-r-----

So only orad11 will have permission to delete the file after the backup. I think brarchive may be run by d11adm, but file operation must be performed by orad11. CMIIW

Thank you.

[Former Member · Accepted solution]

I did a few more checks. Please confirm that the brarvchive binary is owned by orasid.

When i run brarchive from DB13, then the process is indeed owned by sidadm

root# ps -ef|grep brarchive
  sidadm  1835  1834  0 08:31:23 ?         0:01 brarchive -u / -jid LOG__2011...

The logfile of the brarchive run is owned by orasid with group sapsys (exactly the same as the brarchive binary).

-rw-r--r--   1 orasid     sapsys        1967 Apr  1 08:31 aefojufd.svd

Could you please check this on your box? It is still almost sure, that something with the file permissions is incorrect. There could be a few other very exotic reasons, like double entries of dba/sapsys groups in the /etc/group file.

Cheers Michael

[former_member204746 · Accepted solution]

Oracle binary might have the wrong permissions. it might be missing a sticky bit.

other thing, umask must be set to 022 for sidadm and orasid.

[former_member256254 · Accepted solution]

Hi mho,

Please confirm that the brarvchive binary is owned by orasid.

That solve the problem.

Thank you very much.

I think that statement should be added in SAPNote: 113747

Points distributed.

Thanks everyone.