cancel
Showing results for 
Search instead for 
Did you mean: 

NB6 Upgrade: nbpushdata GlobDB errors

Chuck_Stevens
Level 6
When I run "nbpushdata -add" after upgrading my NBU 5.0 MP6 master server to NBU 6.0 MP1, I get these errors:

****
Processing: D:\Program Files\VERITAS\Volmgr\database\globDB
Estimated time remaining will be displayed every 5 minutes.
ERROR: globDB_push OUT_ <1>
ERROR: globDB_push OUT_ <1>
ERROR: globDB_push OUT_ <1>
ERROR: globDB_push OUT_ <1>
ERROR: globDB_push OUT_ <2>
ERROR: globDB_push OUT_ <2>
Failed to push 6 records to EMM.
Pushed 47 records to EMM.
****

What are these errors? A sign of database inconsistency? If so, how do I find out where the bad entries are?

TIA

Chuck
11 REPLIES 11

zippy
Level 6
Chuck

Check out this URL

http://seer.support.veritas.com/docs/279359.htm

Jim

Chuck_Stevens
Level 6
I saw that article. Unfortunately, it refers to errors with merging mediaDB and volDB into the EMM database. My errors refer to globalDB, the global device database.

Chuck

zippy
Level 6
How about

http://seer.support.veritas.com/docs/269133.htm

http://seer.support.veritas.com/docs/258951.htm

You could rebuild it, it sounds like the original DB was not right before the upgrade.

Message was edited by:
James DunnMessage was edited by:
James Dunn

Chuck_Stevens
Level 6
Neither of those article seem to apply to my installation.

My NBU 5.0 MP6 system is working perfectly; if I had a corrupt global device database, wouldn't I be having problems with my media servers/robot/tape drives?

Chuck

zippy
Level 6
Chuck

No, I have seen many times a corrupt database, one way it happens is when you change a tape drive, a new tape drive has a new serial number, this never gets updated unless you force it to update.

these three get whacked... fix em on 5.x then upgrade.

you can look at them by running "strings volDB" on a UNIX box.

globDB
ltidevs
volDB


Jim

AKopel
Level 6
Have you called support? We had very good luck fixing some issues with our 5.0MP6 -> 6.0MP1 upgrade by calling them.

Aaron

Chuck_Stevens
Level 6
Solved it.

The problem had to do with how I had configured my tape library (STK SL500) to run with my various media servers. I had each media server configured to be a local Robot Control Host, which worked fine but caused GlobDB inconsistencies. Choosing one server (the master) to be the Local Robot Control Host, and setting the rest to use it as a Remote Robot Control Host removed the inconsistencies, and thereby the nbpushdata GlobDB errors.

No that my upgrade is complete, I just have to figure out why my backup policies don't start on time...

AKopel
Level 6
We had that problem too...
It seemed like everything went smoother after we recreated the policies... seems like the upgrade is a little flaky carrying over the policies.

Basically did this:
1) Create a new policy from scratch with same basic settings (policy type, compression ect)
2) Copy and paste back in the same schedules
3) Copy and paste back in the clients.

Chuck_Stevens
Level 6
Yeah, that's what I'm doing right now. Fortunately, redoing all my policies was actually on my to-do list anyway (to standardize naming conventions, schedules, etc.).

Stumpr2
Level 6
yippee, skippee!

I have over 230 policies

Chuck_Stevens
Level 6
Update:

Re-creating all my backup policies did nothing to help with the jobs not starting on time. I have a case open with Symantec, and they are poring over the logs I've sent them. No word yet.