cancel
Showing results for 
Search instead for 
Did you mean: 

DB13 Jobs failing

Former Member
0 Kudos

Hi ALL,

I have scheduled Jobs in "DB13" like "UpdateStats" and "CheckDB".

These Jobs are failing with the Error Message

"BR252E Function fopen() failed for '/oracle/DEV/sapbackup/.user.pas' at location brconnect-1

BR253E errno 2: No such file or directory

BR074E BRCONNECT call failed

External program terminated with exit code 1

BRCONNECT returned error status E".

Thanks,

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi ALL,

My Thanks to everybody for the Inputs. My problem is solved.

The was the Problem :

I had ALL Br* files also available in the home directory of <SID>adm "/home/devadm". like

-rwxr-xr-x 1 devadm sapsys 360448 Oct 25 2005 brtools.

I removed these files and it started working.

May be this was the reason it was not able to create ".user.pas".

donald_voorhees
Participant
0 Kudos

This is common when systems have not had saptoot.sh run after a kernel upgrade or any other kind of kernel work. The fix is not to change the directory permissions but to run "saproot.sh <SID>" as root from the /sapmnt/<SID>/exe directory.

fidel_vales
Employee
Employee
0 Kudos

Hello Donald,

Sorry, but the problem has nothing to do with any "script".

The problem was related to

- BR* tools on the wrong directory

Note that the tools had also wrong authorizations, but no script would have solve this as they do not expect the tools ( or kernel or oracle client or .... ) to be on the wrong directory

Former Member
0 Kudos

Hi ,

These errors indicate the user running the BRBACKUP does not have the correct permissions to create the stated log file in the sapbackup directory.

To resolve this check the permissions of /oracle/Dev/sapbackup and make sure it is writeable (rwx) by the user running the backup.

This can occur if the sapbackup directory is owned by oraa01:dba (orasid user, dba group) and the permissions are 755 (rwxr-xr-x). If the backups are being run as a different user like devadm (sidadm), it will encounter this error. Since sidadm is in the dba group, it is usually sufficient to change the permissions to 775.

Please add /give feedback with points if it helps you

Regards,

Gokul B.

Former Member
0 Kudos

Check your BR* tools version to see if it's compatible.

regards

tamilboy

Former Member
0 Kudos

Have you set the permissions and s bit for br* files correctly . Check note 113747 for more info.

Thanks

Prince Jose