Backint Error BKI0062E

[sivaramakrishn]

Hi All,

After this weekend, all our production servers have problems with archive backup scheduled via DB13 (SAP transaction). This has started happening from Monday onwards. Till then, all backups were running succefully via DB13. On checking the logs, the following is the error:

BKI0062E: The input file /oracle/RP1/saparch/.adxgdwhd.lst is not valid.

On checking, BRTOOLS is not executable by <SID>adm whereas it is executable by ora<SID>. But, proper permissions are required for <SID>adm as this is the user executing the backup from SAP (DB13).

In some of the servers, <SID> did not have write permissions on directory /oracle/<SID>/saparch (which was strange as backups till then were successful). In ECC however, the permissions were correct but still the error persists (even though I am able to manually create the file).

Any clues/suggestions?

Thanks

Siva

[stefan_koehler · Accepted solution]

Hello Siva,

http://www.personal.psu.edu/dept/aset/ait/tsm/5.1docs/html/messages/anrcms34.htm

> BKI0062E The input file filename is not valid.

> Explanation: Tivoli Data Protection for R/3 is not able to read the input file filename correctly.

> User Response: Check the path and name of the output file and the appropriate file access permission.

Please check the permissions for saparch.

If you are not sure about the rights of the BR*Tools... so please run the script saproot.sh as root in the folder /sapmnt/<SID>/exe

Regards

Stefan

[Former Member · Accepted solution]

Dear Siva,

I agree with Stefan, as it is totaly related with permissions, and try to execute the script saproot.sh (UNIX system) as a root user.

As we also faced the similar problem, we changed the permission.

Kindly check SAP note:113747 - Permissions for DBA tools BRTools and SAPDBA*.

Hope it may help you.

regards,

Shaibaz

[sivaramakrishn]

Hi,

Thanks for the replies. I had already checked the permissions to saparch and even tried with 777. Fortunately, we found the problem today. This was due to changing of umask for sidadm from 022 to 077 (as part of the security checks on AIX).

Once we reverted back umask, everything started working as before.

Once again, thanks for the help.

Cheers

Siva