Redolog dbf file created in wrong permission

[Former Member]

Hi Experts

We have installed a new SAP system with oracle in AIX platform. When we checked for the redolog file direcotry it shows as below

-rw------- 1 ora<sid> dba 135168 Jan 13 18:39 <sid>arch1_1441_856886348.dbf

-rw-r----- 1 ora<sid> dba 12865024 Jan 13 21:24 <sid>arch1_1442_856886348.dbf

-rw------- 1 ora<sid> dba 6878720 Jan 13 23:04 <sid>arch1_1443_856886348.dbf

-rw-r----- 1 ora<sid> dba 45330944 Jan 14 07:00 <sid>arch1_1444_856886348.dbf

here u can see one file is written in 600 permission and alternate in 640 permission. when i trigger the archival from orasid user the archival backup is successful. but when i trigger from DB13 it triggered error. I have TDP for taking backup.

I have got the follwoing error

BKI2017I: Blocksize is set to 131072 bytes

BKI0032E: Error opening file /oracle/<SID>/oraarch/<SID>arch1_1432_856886348.dbf: The file access permissions do not allow the specified action.

BKI1200E: Cannot read/write file: /oracle/<SID>/oraarch/<SID>arch1_1432_856886348.dbf.

BR0233E Backup utility has reported an error while saving file /oracle/<SID>/oraarch/<SID>arch1_1432_856886348.dbf

BKI1200E: Cannot read/write file: /oracle/<SID>/oraarch/<SID>arch1_1433_856886348.dbf.

BR0233E Backup utility has reported an error while saving file /oracle/<SID>/oraarch/<SID>arch1_1433_856886348.dbf

BKI1200E: Cannot read/write file: /oracle/<SID>/oraarch/<SID>arch1_1434_856886348.dbf.

BR0233E Backup utility has reported an error while saving file /oracle/<SID>/oraarch/<SID>arch1_1434_856886348.dbf

BKI1200E: Cannot read/write file: /oracle/<SID>/oraarch/<SID>arch1_1435_856886348.dbf.

Because of the dbf file permission the backup is failing in sidadm

Regards

bala

[Former Member]

Hi

We have resolved this issue. this is maily happend due to backup script.

regards

ba

[Former Member]

Hi Joe

this is not Oracle RAC. And the HA is hardwrae level HA and the Installation was central installation only.

The same way we have installed other system which is working finr.

regards

bala

[Former Member]

Hello Bala,

I am running out of ideas. But as there wasn't any other answer for several days, let me try a few more thoughts:

So you have got two problems:

1) Alternate permissions of archived redo logs. This problem goes away by restarting Oracle, but comes back soon.

2) Error messages because of wrong permissions during brarchive from DB13. You already checked s-bit and other permissions.

I am still not convinced that problem 1 is the cause of problem 2. However both problems might have the same cause.

In your orignal post you show alternate permissions for logs 1441-1444. Then you show error messages for logs 1432-1435, not alternating.

Well, this doesn't prove anything. For clarification please make sure whether or not you get error messages for exactly those logs with wrong permissions.

I still suppose that your archiver process might get in a strange state. Reason could be a resource bottleneck or a bug in either Unix or Oracle. You might find a clue in respective log files. Make sure you have applied all the recommended patches and correct parameter settings for both Unix and Oracle.

You might reply: Configuration is the same as in the other system, and there it is working! Well, configuration may be the same, but load most probably isn't.

regards

[Former Member]

Hi Markus

I have retsarted the oracle now the genrated three oracle files are in 640 permission but in coming days it may create problem because yesterday the same way i have restarted the oracle that it was fine but today now again it is not triggering in correct permission and again we restarted. Is there any process or executables should be checked. this system is in HA.

Regards

Bala

[Former Member]

Hello Bala,

I still think that with correct s-bit it should work, no matter what file permissions are.

But now (at last!) you mention that you are in an HA environment. I am not familiar with AIX, but I presume brarchive works when you start it from Unix on the database host. And I presume there are problems from DB13 because there is an SAP application server on a different host.

Is this correct?

And is there also an SAP application server on the database host, for example the central instance?

[Former Member]

And by the way, is it Oracle RAC ?

[Former Member]

Hi Markus

SystemA:sidadm> exit

$ sudo su - orasid

orasid> umask

022

orasid> exit

$ sudo su - sidadm

SystemA:sidadm> umask

022

SystemA:sidadm>

and Joe

SystemA:sidadm> cd mirrlogB

SystemA:sidadm> ls -lt

total 204818

-rw-r-----    1 orasid   dba        52429312 Jan 14 07:00 log_g14m2.dbf

-rw-r-----    1 orasid   dba        52429312 Jan 13 21:24 log_g12m2.dbf

drwxr-xr-x    2 root     system          256 Dec 21 11:21 lost+found

SystemA:sidadm> cd ../mirrlogA

SystemA:sidadm> ls -lt

total 204818

-rw-r-----    1 orasid   dba        52429312 Jan 14 12:45 log_g11m2.dbf
-rw-r-----    1 orasid   dba        52429312 Jan 13 23:04 log_g13m2.dbf
drwxr-xr-x    2 root     system          256 Dec 21 11:21 lost+found
SystemA:sidadm> cd ../origlogA
SystemA:sidadm> ls -lt
total 204810
-rw-r-----    1 orasid   dba        52429312 Jan 14 12:45 log_g11m1.dbf
-rw-r-----    1 orasid   dba        52429312 Jan 13 23:04 log_g13m1.dbf
drwxr-xr-x    2 orasid   dba             256 Dec 29 13:19 cntrl
drwxr-xr-x    2 root     system          256 Dec 21 11:17 lost+found
SystemA:sidadm> cd ../origlogB
SystemA:sidadm> ls -lt

total 204818
-rw-r-----    1 orasid   dba        52429312 Jan 14 07:00 log_g14m1.dbf
-rw-r-----    1 orasid   dba        52429312 Jan 13 21:24 log_g12m1.dbf
drwxr-xr-x    2 orasid   dba             256 Dec 29 13:19 cntrl
drwxr-xr-x    2 root     system          256 Dec 21 11:18 lost+found





root#SystemB> cd origlogA
root#SystemB> ls -lt
total 204818
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:46 log_g11m1.dbf
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:14 log_g13m1.dbf
drwxr-xr-x    2 orasit   dba             256 Sep 13 02:45 cntrl
drwxr-xr-x    2 root     system          256 Aug 24 08:53 lost+found
root#SystemB> cd ../origlogB
root#SystemB> ls -lt
total 204818
-rw-r-----    1 orasit   dba        52429312 Jan 14 13:00 log_g12m1.dbf
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:28 log_g14m1.dbf
drwxr-xr-x    2 orasit   dba             256 Sep 13 02:45 cntrl
drwxr-xr-x    2 root     system          256 Aug 24 08:54 lost+found
root#SystemB> cd ../mirrlogA
root#SystemB> ls -lt
total 204818
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:46 log_g11m2.dbf
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:14 log_g13m2.dbf
drwxr-xr-x    2 root     system          256 Aug 24 08:55 lost+found
root#SystemB> cd ../mirrlogB
root#SystemB> ls -lt
total 204818
-rw-r-----    1 orasit   dba        52429312 Jan 14 13:00 log_g12m2.dbf
-rw-r-----    1 orasit   dba        52429312 Jan 14 11:28 log_g14m2.dbf
drwxr-xr-x    2 root     system          256 Aug 24 08:55 lost+found
root#SystemB>

[markus_doehr2]

> orasid> umask

> 022

This is your problem.

You'll need to switch that 002 to get the permissions you want.

man umask

Markus

[Former Member]

Bala

thanks,

so my first guess was wrong.

But here is one more:

I suppose there are two archiver processes ora_arc0_<SID> and ora_arc1_<SID> in your system. One of them seems to be a bit weird. And I suppose this phenomenon might dissappear when you restart Oracle.

Markus

sorry, I can't imagine how a wrong umask could result in alternate permissions as shown in the original question. Or what am I missing?

regards

Edited by: Joe Bo. on Jan 14, 2010 2:30 PM (typo)

[Former Member]

Hi Joe

System A :

SystemA:sidadm> cd mirrlogB

SystemA:sidadm> ls -lt

total 204818

-rw-r----- 1 orasid dba 52429312 Jan 14 07:00 log_g14m2.dbf

-rw-r----- 1 orasid dba 52429312 Jan 13 21:24 log_g12m2.dbf

drwxr-xr-x 2 root system 256 Dec 21 11:21 lost+found

SystemA:sidadm> cd ../mirrlogA

SystemA:sidadm> ls -lt

total 204818

-rw-r----- 1 orasid dba 52429312 Jan 14 12:45 log_g11m2.dbf

-rw-r----- 1 orasid dba 52429312 Jan 13 23:04 log_g13m2.dbf

drwxr-xr-x 2 root system 256 Dec 21 11:21 lost+found

SystemA:sidadm> cd ../origlogA

SystemA:sidadm> ls -lt

total 204810

-rw-r----- 1 orasid dba 52429312 Jan 14 12:45 log_g11m1.dbf

-rw-r----- 1 orasid dba 52429312 Jan 13 23:04 log_g13m1.dbf

drwxr-xr-x 2 orasid dba 256 Dec 29 13:19 cntrl

drwxr-xr-x 2 root system 256 Dec 21 11:17 lost+found

SystemA:sidadm> cd ../origlogB

SystemA:sidadm> ls -lt

total 204818

-rw-r----- 1 orasid dba 52429312 Jan 14 07:00 log_g14m1.dbf

-rw-r----- 1 orasid dba 52429312 Jan 13 21:24 log_g12m1.dbf

drwxr-xr-x 2 orasid dba 256 Dec 29 13:19 cntrl

drwxr-xr-x 2 root system 256 Dec 21 11:18 lost+found

SystemB:

root#SystemB> cd origlogA

root#SystemB> ls -lt

total 204818

-rw-r----- 1 orasit dba 52429312 Jan 14 11:46 log_g11m1.dbf

-rw-r----- 1 orasit dba 52429312 Jan 14 11:14 log_g13m1.dbf

drwxr-xr-x 2 orasit dba 256 Sep 13 02:45 cntrl

drwxr-xr-x 2 root system 256 Aug 24 08:53 lost+found

root#SystemB> cd ../origlogB

root#SystemB> ls -lt

total 204818

-rw-r----- 1 orasit dba 52429312 Jan 14 13:00 log_g12m1.dbf

-rw-r----- 1 orasit dba 52429312 Jan 14 11:28 log_g14m1.dbf

drwxr-xr-x 2 orasit dba 256 Sep 13 02:45 cntrl

drwxr-xr-x 2 root system 256 Aug 24 08:54 lost+found

root#SystemB> cd ../mirrlogA

root#SystemB> ls -lt

total 204818

-rw-r----- 1 orasit dba 52429312 Jan 14 11:46 log_g11m2.dbf

-rw-r----- 1 orasit dba 52429312 Jan 14 11:14 log_g13m2.dbf

drwxr-xr-x 2 root system 256 Aug 24 08:55 lost+found

root#SystemB> cd ../mirrlogB

root#SystemB> ls -lt

total 204818

-rw-r----- 1 orasit dba 52429312 Jan 14 13:00 log_g12m2.dbf

-rw-r----- 1 orasit dba 52429312 Jan 14 11:28 log_g14m2.dbf

drwxr-xr-x 2 root system 256 Aug 24 08:55 lost+found

root#SystemB>

Hence they have same permissions and but the archival backup is not happening in one of the system.

regards

bala

[Former Member]

Hi Markus

How to find the umask of orasid and sidadm. As well the file write in alternate permissions of each file.

regards

bala

[markus_doehr2]

> How to find the umask of orasid and sidadm. As well the file write in alternate permissions of each file.

- logon as ora<SID>

- execute 'umask'

Markus

[Former Member]

Hi Mark / Joe

Let explain u in detail.

Our SAP system is SCM 7.0 ABAP only.

and consider one system name is A and other as B.

The redolog copied from the online redo log with different permissions are in system A.where i could not trigger in DB13.

But in System B the same config and samelevel of permission ( i have checked the sapmnt and oraarch and orig and mirrlog directotries which are same) and successfully i could take backup of System B but not A.

Regards

bala

[Former Member]

Not sure if this does answer my question.

Let me too explain in detail.

Got to the system A where permissions are differnt. Compare permissions of files (not permissions of directories) in origlog and mirrlog. Are they different?

Just a guess, but because redo logs in oraarch are copies from origlog/mirrlog, this could be a reason....

In other words: in origlog/mirrlog are there both files with -rw---- and -rw-r--- ?

Edited by: Joe Bo. on Jan 14, 2010 2:00 PM

[markus_doehr2]

What is the umask for ora<SID> and <SID>adm?

Markus

[Former Member]

Hi

This executable are taking backup files but my error is the redolog file itself writes in diffrerent permission levels

regards

bala

[Former Member]

Hello Bala,

not sure if I understood what you mean by here and other system.

Like Mark, I think that it should work with s-bit set properly.

As for your question about different permissions:

Not sure about it, but let me suggest to check file permissions in your origlog* and mirrlog* directories.

regards

[Former Member]

Hi

I have checked the note 113747 and 12741 and checked other systems .

ls -lt br*

-rwxrwxr-x 1 orasid dba 6996331 Feb 24 2009 brspace

-rwxrwxr-x 1 orasid dba 5670503 Feb 24 2009 brrecover

-rwsrwxr-x 1 orasid dba 5202913 Feb 24 2009 brbackup

-rwsrwxr-x 1 orasid dba 6786275 Feb 24 2009 brconnect

-rwsrwxr-x 1 orasid dba 5074068 Feb 24 2009 brarchive

-rwsrwxr-x 1 orasid dba 2785581 Feb 22 2009 brtools

-rwxrwxr-x 1 orasid dba 2132759 Feb 20 2009 brrestore

here other than brtools which is sticky bit were same.but in the other system we maintain the same permission whetre it works well.

regards

bala

[Former Member]

What version of SAP you running compared to others.....

I would have expected ora<sid>:sapsys to run through DB13

Mark

[Former Member]

Hi,

What permissions are your BR* tools can you cut and paste.

Mark