Unsolved
This post is more than 5 years old
44 Posts
0
2044
fast inventory oddity after update: "The media data base has no volume with barcode ..."
After updating to version 8.2.3.3 of Networker, fast inventory on our jukeboxes (nsrjb -II ...) will only perform a fast inventory on tapes that have not changed position, and will report an error for all tapes that have been changed, e.g.
09/12/16 09:20:30.866477 Info: The media data base has no volume with barcode = `XY0247L6'.
09/12/16 09:20:30.866501 Info: Fast Inventory cannot identify volume in slot `23'.
...
09/12/16 09:20:30.867000 Error: Fast Inventory fail to identify some or all of the selected slots.
The message "The media data base has no volume with barcode ..." is definitely wrong, as there always is a volume with that barcode in the media database.
For these tapes / slots we then have to perform a slow inventory.
EMC support mainaints that we should be fine with that, but I disagree, and we do not want to spend hours for inventorying large jukeboxes
I suspect the change in the ressources database to SQLite might play a role in this:
"In NetWorker 8.2 SP3, SQLite replaces WiSS as the media database."
Did anybody see similar effects? Who could offer a solution?
Kind regards, Tom
ble1
14.3K Posts
1
September 30th, 2016 10:00
I haven't seen it, but then again I do not move tapes around the lib and I started with 8.2.3.4 (now using 8.2.3.6). What I would suggest is:
- nsrjb -HvE
- if all volumes in lib are known to NW, run now fast inventory
swadm
44 Posts
0
October 5th, 2016 03:00
Hrvoje, thanks for replying.
It's not really about moving around tapes in the jukebox, it's mainly about putting fresh tapes into it.
"nsrjb -HvE" did not help, sorry.
Kind regards, Thomas
bingo.1
2.4K Posts
1
October 5th, 2016 04:00
So far we have not seen that problem. However, I would proceed as follows:
- verify the AC contents as follows:
nsradmin
. type: nsr jukebox
show volumes
p
- compare that output with the info from the media db:
mminfo -q "barcode= " -r "volume,barcode"
If the message is true then the info from the media db must have disappeared somehow.
swadm
44 Posts
0
October 6th, 2016 03:00
Bingo,
when I do the "p" in nsradmin, I get "" for all troublesome volumes.
The output of mminfo is also very confusing, e.g.
Kind regards, Tom
swadm
44 Posts
0
October 6th, 2016 05:00
EMC support recommends to do a full inventory in such a situation!
bingo.1
2.4K Posts
0
October 6th, 2016 05:00
With the nsradmin command you verify what the jukebox resource knows about the volumes.
Obviously, it does not know the troublesome ones.
mminfo uses the media index -
If you query for the volume it knows volume and barcode.
But if you query for the barcode, there is no match.
This is weird. And it is in contradiction with respect to your first statement.
Sorry, but at the moment I am rather clueless. You should 'cross-check' the 2 databases but honestly, I do not know how to do this except running a full inventory of the jukebox. This is bad. Even worse, you do not know whether this will solve the issue for the future.
You better ask EMC whether they have an appropriate tool.
bingo.1
2.4K Posts
0
October 6th, 2016 23:00
Maybe this is somehow related/connected to ETA 490166 (KB article 000490166) which we received today.
swadm
44 Posts
0
October 7th, 2016 02:00
No, I don't think that our issue is related to savesets changing to E (expired), it is an issue about the media database.
ble1
14.3K Posts
0
October 7th, 2016 07:00
And running full inventory results in...? The barcode thingy is a bit strange, but it could be that lib didn't provide it at some point (can be verified with sjirdtag command) and this may in some rare instances cause issues, but not sure if this is your case.
swadm
44 Posts
0
October 10th, 2016 03:00
A full inventory will do what we expect, and will correctly recognize the tapes. I will run a very long time.
I'm afraid that we do not run SJI compliant jukeboxes.
Kind regards, Thomas
ble1
14.3K Posts
0
October 10th, 2016 04:00
Every jukebox is SJI compliant. You can always run full inventory (-Ip) per slot (-S) - you easily see which slots are affected and have those corrected that way.
swadm
44 Posts
0
October 10th, 2016 05:00
Hrvoje,
sjirdtag will report
So that's why I guessed we lack the SJI support.
Regards, Thomas
ble1
14.3K Posts
0
October 11th, 2016 04:00
It could be just busy (locked) port. For example, since I'm not sure which NW version, it will lock it if NW has lib defined over that port and only way to run sji commands is if lib is disabled in NW (or if you have multiple ports for robotic then use another port). But top of my head, you would get busy message I think and not the one you get right now... I can check...
ble1
14.3K Posts
0
October 11th, 2016 04:00
Well, I tried it on Linux where I run now all my libs and it worked there (so it might be based on OS or perhaps if lib is busy at the same time as mine is activity free for almost a day now).
swadm
44 Posts
0
October 12th, 2016 00:00
In our case it is SLES 11 SP3.
I get the error even when all networker services on storage node are down.