We have just upgraded from 7.0 to 18.104.22.168 on our master and media servers. They are running on Sun Solaris version 10. Previously we had no issues with restores, but now it seems that most of our restores are remaining in a queued state after being submited from anywhere from 30 to 60 or minutes before they begin execution. Once they begin running, they restore fine with normal transfer rates and complete successfully.
Has anyone every come across this issue before and do you have any suggestions on where to look to reduce the "queued" time ? The backups seem to run as they did prior to the upgrade, it seems to only be a problem with the restores.
nbrb / nbjm / nbemm / nbpem log.
Log call with Symantec
Ask that the logs are put through IRMA. If enginner not aware of this, ask them to ping a UK engineer who will be.
This may not give a exact answer, but it is the quickest way to spot where the selay is. May need 167 and 137 logs enabling (these go into the above logs).
vxlogview can be run by the TSE, but must be run with -d all option
Well done MKT, I had completely forgotten about that, you could be onto something there.
What is really annoying is that I have seen thaat exact issue a few times, and still forgot about it ... and thus, got the logs a bit wrong - still the IRM logs would narrow it down.
Looking at the etrack, there are EEBs available for :
... so it looks like an EEB could be the answer, and you'll need to look in the bpdbm log as per the TN.
If it is not this, then I think the logs as I suggested, but include bpdbm and bprd as well ...
seeing this with netbackup 8.0 on a new rhel linux server with 1TB RAM and 32 cores. bprd process stays at 100% CPU while the job is queued. some jobs do not queue and start restoring almost instantly, but when the jobs queue for more than a minute, they are staying queued for > 5 hours.