cancel
Showing results for 
Search instead for 
Did you mean: 

After 8.2 Upgrade Status 29's happening

Krutons
Moderator
Moderator
   VIP   

Has anyone else seen Status code 29's for legacy DB backups using scripts? I can't figure out why it's happening. Sometimes the DB backup is successful but the parent job still ends with a status 29.

1: (29) failed trying to exec a command

13 REPLIES 13

davidmoline
Level 6
Employee

I suspect it will be that the script isn't in an allowed path. 

Have a review of the following article and see if this helps https://www.veritas.com/support/en_US/article.100039639

I think you need to add or set the DB_SCRIPT_PATH = to include the location where your scripts reside (or move them to a trusted location - /usr/openv/netbackup/db_ext or <installPath>\NetBackup\dbext). 

Krutons
Moderator
Moderator
   VIP   

The scripts are in the allowed path which is in the bp.conf

BPCD_WHITELIST_PATH = /oracle/<DB Name>
DB_SCRIPT_PATH = /oracle/<DB Name>/121/dbs

It also doesn't happen every time the backup runs.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@Krutons 

It does not seem to be a 'known issue'.
All I can suggest is to dig into logs... 

script output, dbclient, bphdb.
There will hopefully be a clue in one these logs. 

Hhay83
Level 3
I’m having same issues with large RMAN back
Have you find out a solution

You have a busy master server? How many jobs run per day? Are you using the default client time-out parameters?

 

Krutons
Moderator
Moderator
   VIP   

Master server has 30,000 jobs a day give or take.
Timeouts are not default on the media servers.

The status 29 can get thrown during busy times and also when their is little to no use going on.

Currently have a ticket open with Veritas but they have only asked that we add stdout/stderr outputs throughout our script which hasn't produced anything.

You would try to use the following parameters on master.

echo "1000000" > /usr/openv/netbackup/db/config/BPSCHED_THRESHOLD
echo "25000000" > /usr/openv/netbackup/db/config/RBALLOC_KBYTES_THRESHOLD
echo "3600" > /usr/openv/netbackup/db/config/REPORT_RAW_KBS
echo "25000" > /usr/openv/netbackup/MAX_ENTRIES_PER_ADD
echo "20"> /usr/openv/netbackup/bin/DBMto
echo "0" > /usr/openv/netbackup/NET_BUFFER_SZ

Had that issue happening intermitently and above worked for me.

All of the mentioned toch files has been created, also deployed the recommended EEB's from Veritas

still backup is failing, we disabled all policies and run only one RMAN backup it go without any issues for 6 hours then failed with same error???

Takes too much time to close the allocated channels at the end of the backup? Is it the behaviour you've seen?

Hi there,

Just checking but did you get a resolution to this? Im having the same issue with RMAN backups post 8.2 upgrade and have applied the suggestions from this forum.

Cheers

Krutons
Moderator
Moderator
   VIP   

No resolution. Veritas just pointed at our scripts saying they were the issue (They had no issues till that upgrade). We eventually coaxed the DBA's to abandon legacy backup and let us implement OIP backups for the Oracle DB's.

pats_729
Level 6
Employee
Hi
Is it that you upgraded master / media and clients leaving clients to use older templates of scripts ?
Try using one of the latest script templates.