on 01-01-2010 8:42 PM
Hi,
It is always wired for me.
As we all know, when we create a backup job with DB13. The job will start within username <SID>adm
The job creates a directory for the backup and it is writable only for <SID>adm.
But after the integration of RMAN, the username will be altered to ora<SID>, and then, how could RMAN be able to write the file in the backup directory?
I know that it is not a general case, but thanks in advance for your response.
> It is always wired for me.
Hopefully it is wired and not too weired.
> As we all know, when we create a backup job with DB13. The job will start within username <SID>adm
> The job creates a directory for the backup and it is writable only for <SID>adm.
Nope.
The "Job" does not create a directory - it's brbackup that does this.
And brbackup performs the RMAN call as well - in the same session.
> But after the integration of RMAN, the username will be altered to ora<SID>, and then, how could RMAN be able to write the file in the backup directory?
Because it does this as <SID>ADM in that case.
regards,
Lars
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes it is brbackup that creates the directory, so the owner of directory is <sid>adm. with the permission 747.
And then, when the RMAN is called. I think (Maybe wrong), the connected database user is OPS$ora<sid>. which cannot add a file in the backup directory. So the normal backup couldn't be continued.
Am I right ?
> And then, when the RMAN is called. I think (Maybe wrong), the connected database user is OPS$ora<sid>. which cannot add a file in the backup directory. So the normal backup couldn't be continued.
>
> Am I right ?
Nope, you're wrong.
When the DB13 calls brbackup to start the backup it does this as <sid>adm.
And within this user context brbackup calls RMAN.
That's one of the reasons why you need to assign the DBA and OPER groups to the <sid>adm user as well.
regards,
Lars
At first, thanks for your responses. Your response is correct, however it does not hit the point.
What I talked about is brbackup with RMAN (such as full / incremental backup).
In these cases:
1. backup starts with brbackup - The user is <sid>adm now
2. brbackup creates the directory with OS user <sid>adm, of permission 747
3. however, when the backup really begin , brbackup calls RMAN as following commands:
SHELL=/bin/sh /oracle/DEV/102_64/bin/rman nocatalog
RMAN> connect target *
.....
At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.
Anyway, I don't think that RMAN uses <sid>adm. And it is the origin of my question.
Waiting for hearing that I've made some mistakes and have a good 2010!
> In these cases:
> 1. backup starts with brbackup - The user is <sid>adm now
> 2. brbackup creates the directory with OS user <sid>adm, of permission 747
> 3. however, when the backup really begin , brbackup calls RMAN as following commands:
> SHELL=/bin/sh /oracle/DEV/102_64/bin/rman nocatalog
> RMAN> connect target *
> .....
> At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.
Ok, let's do it the other way round.
What makes you believe that brbackup changes it's user context before calling RMAN?
Why should this be the case?
How and where did you see that?
regards,
Lars
Hello Xia,
please let me put some thoughts to your last post.
At first i have to mention, that we don't perform RMAN backups with the BR*Tools, but i think you have some fundamental understanding "problems".
> 1. backup starts with brbackup - The user is <sid>adm now
Ok, this is correct.
> 2. brbackup creates the directory with OS user <sid>adm, of permission 747
Maybe - i don't exactly know the permissions that are set by the BR*Tools, but keep in mind if the permissions ar set to 747 then every OS-user is able to write in this directory .. no matter if it is <SID>adm or ora<SID>.
> At this time, the connected database user is OPS$ora<sid>, and then the related OS user has been altered to ora<sid>, and then it could not write a file to the created backup directory.
Wrong - you connect to the database with the RMAN client with an external authentication (prefix OPS$), but this has no influence on the corresponding database shadow process. The shadow process normally runs with ora<SID>. If you perform a "normal" (= not parallel) backup with RMAN, the database spawns 2 shadow processes (one process for calling packages, performing backup and coordinating other RMAN channels processes, one process for "monitoring").
If you think about it now, you should get the solution.
Regards
Stefan
Thanks for your answers. I've recently made a test, how I can't explain the result.
Here is my test:
1. I've modified the init<sid>.sap to activate the backup with RMAN.
- backup_dev_type = disk
- disk_copy_cmd = rman
2. Run a full online backup in DB13.
3. The error occurs
BR0280I BRBACKUP time stamp: 2010-01-03 16.34.03
BR0198I Profiles saved successfully
BR0202I Saving /oracle/DP1/sapdata2/sr3_1/sr3.data1
BR0203I to /backup/backup/becguudi/sr3.data1 ...
BR0278E Command output of 'SHELL=/bin/sh /oracle/DP1/10264/bin/rman nocatalog':_
Recovery Manager: Release 10.2.0.4.0 - Production on Sun Jan 3 16:34:03 2010
4. However, I check the directory /backup/backup/becguudi, it has been created. And the permission is set to 755(I was wrong, it is not 747), owner is <sid>adm.
The error in RMAN is:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on dsk channel at 01/03/2010 16:34:06
ORA-19504: failed to create file "/backup/backup/becguudi/sr3.data1"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Why it could occur... If the owner of the processes of RMAN is <sid>adm.
It is weired, no?
[1]ls -la /backup/backup/
total 20
drwxrwxrwx 5 root root 4096 2010-01-03 15:27 .
drwxr-xr-x 4 root root 4096 2010-01-01 22:01 ..
drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 05:14 becgspyo
drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 becguudi
drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 05:14 DP1
[2]ls -la /backup/backup/becguudi/
total 8
drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 .
drwxrwxrwx 5 root root 4096 2010-01-03 15:27 ..
[3]ps -ef grep oracle
oradp1 712 1 0 17:30 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 714 1 0 17:30 ? 00:00:00 oracleDP1 (LOCAL=NO)
dw1adm 839 7778 0 17:34 ? 00:00:00 sh -c ps -ef grep oracle
dw1adm 841 839 0 17:34 ? 00:00:00 grep oracle
oradp1 7193 1 0 Jan02 ? 00:01:32 /oracle/DP1/102_64/bin/tnslsnr LISTENER -inherit
oradp1 24619 1 0 06:21 ? 00:00:08 oracleDP1 (LOCAL=NO)
oradp1 24622 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24624 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24626 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24638 1 0 06:21 ? 00:00:04 oracleDP1 (LOCAL=NO)
oradp1 24640 1 0 06:21 ? 00:00:03 oracleDP1 (LOCAL=NO)
oradp1 24642 1 0 06:21 ? 00:00:04 oracleDP1 (LOCAL=NO)
oradp1 24678 1 0 06:21 ? 00:00:01 oracleDP1 (LOCAL=NO)
oradp1 24772 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24774 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24776 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24778 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24780 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24782 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24784 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24786 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 24788 1 0 06:23 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 27666 1 0 09:45 ? 00:00:08 oracleDP1 (LOCAL=NO)
oradp1 29872 1 0 14:15 ? 00:00:00 oracleDP1 (LOCAL=NO)
oradp1 31411 1 0 15:26 ? 00:00:00 oracleDP1 (LOCAL=NO)
Hello Xia,
thanks for the output ... you can see the cause of the problem there.
shell> ls -la /backup/backup/
drwxr-xr-x 2 dw1adm sapsys 4096 2010-01-03 15:27 becguudi
shell> ps -ef grep oracle
oradp1 24619 1 0 06:21 ? 00:00:08 oracleDP1 (LOCAL=NO)
oradp1 24622 1 0 06:21 ? 00:00:00 oracleDP1 (LOCAL=NO
The owner of the directory "becguudi" is dw1adm and the group members of "sapsys" and any other user are not allowed to write into this directory ( drwx r-xr-x ). The oracle shadow processes (and also the ones that are spawned through the RMAN client) are running under oradp1, and this user is not allowed to write into "/backup/backup/becguudi".
No idea, why the BRTools are creating the folder "becguudi" with such a strange permission. Have you already checked the permissions of the BRTools itself (especially the s-bit) .. take a look at sapnote #113747 for that.
Regards
Stefan
I've checked the Note 113747.
Changing the permissiom of brtools will change the permission of the create directory?
If it could happen, I will take a test....
Anyway, should I create an OSS message for it?
P.S. Thanks for your help, fortunately, I've learned a lot about this thread. I will let it open for some more day and then close it.
P.S.2: My first thread is right .
Hello Xia,
> Changing the permissiom of brtools will change the permission of the create directory?
If the s-bit or owner is not set correct - yes.
Explanation: If setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed
> If it could happen, I will take a test....
Check the s-bit and the owner of the BR*Tools binaries ... it could be the problem.
> Anyway, should I create an OSS message for it?
As i already mentioned we are not using BR*Tools and if the s-bit and owner is set correctly i would suggest this. By the way Lars Breddemann, who already posted some replies to this thread is a SAP employee in the database team .. so ...
Regards
Stefan
Here is the my verification of note 113747
(1)
ora<sid> and <sid>adm on DB server have a search path on /sapmnt/<SID>/exe. (All br* and sapdba are contained in this directory.)
ora<sid> belongs to the dba group,
<sid>adm belongs to the sapsys group,
Done
(2)
<sid>adm on the database server has the rhosts entry: "+ <sid>adm".
DB server and central instance server is the same one.
(3)
The ops$<sid>adm Oracle user must be created in the DB and must have the sapdba role (not DBA!) (refer to Note 134592 for more information about the role).
<sid>adm has the following role: DBA, SAPDBA, CONNECT, RESSOURCE
P.S. sapdba_role.sql has been executed.
(4)
brarchive, brbackup, and brconnect have permission 4775:
-rwsrwxr-x ora<sid> sapsys ...
These can be started by the ora<sid> or the <sid>adm OS user.
brrestore, brrecover, brspace, brtools, and sapdba have permission 755:
-rwxr-xr-x <sid>adm sapsys ...
These should only be started by the ora<sid> OS user.
The result of command line:
[4]ls -la /sapmnt/DW1/exe/brbackup
-rwxrwxr-x 1 oradp1 sapsys 4284895 2009-02-24 21:37 /sapmnt/DW1/exe/brbackup
[5]ls -la /sapmnt/DW1/exe/brarchive
-rwxrwxr-x 1 oradp1 sapsys 4178065 2009-02-24 21:37 /sapmnt/DW1/exe/brarchive
[6]ls -la /sapmnt/DW1/exe/brconnect
-rwxrwxr-x 1 oradp1 sapsys 5527676 2009-02-24 21:37 /sapmnt/DW1/exe/brconnect
And.. again. The same error.
Hello Xia,
> And.. again. The same error.
And again you haven't read the sapnote #113747 accurately.
Your command output:
shell> ls -la /sapmnt/DW1/exe/brbackup
-rwxrwxr-x 1 oradp1 sapsys 4284895 2009-02-24 21:37 /sapmnt/DW1/exe/brbackup
shell> ls -la /sapmnt/DW1/exe/brarchive
-rwxrwxr-x 1 oradp1 sapsys 4178065 2009-02-24 21:37 /sapmnt/DW1/exe/brarchive
shell> ls -la /sapmnt/DW1/exe/brconnect
-rwxrwxr-x 1 oradp1 sapsys 5527676 2009-02-24 21:37 /sapmnt/DW1/exe/brconnect
.... and it should look like (corresponding to sapnote #113747)
-rwsrwxr-x ora<sid> sapsys ...
And what is wrong?
Take a look at the s-bit ... you need a "S" at fourth position ... and you have a "X" ... just execute "chmod 4775" for the files brarchive, brbackup, and brconnect like described in sapnote #113747
Regards
Stefan
Must re-attribute pointes
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
67 | |
26 | |
9 | |
9 | |
7 | |
6 | |
4 | |
4 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.