Collection Reference Counts do not match

[banana_john]

Enterprise Vault 8.0.4 on Windows 2008 servers

We run EVSVR verify every weekday during the backup window.

For a while (since about June), we've been getting
"Collection Reference Counts do not match"
nearly every week (typically "Collections with mismatched RefCounts: 5" for some reason).

So far as I can tell, it's always on the same partition.  Looking over the last several weeks, it looks like it is always stuff archived on 30 January
(e.g. from EVSVR report:
2014-10-02 17:22:30            Collection file path: \\xyz-EV2\EVPartition01ce95060321c410$\2014\01-30\4\Collection222101.CAB, Identity: 222101
2014-10-02 17:22:30              Collection Reference Counts do not match: Collection: 1, Savesets: 0, SISParts and Converted Contents: 0)

I've had a look at that collection file path: the file is there and there are items in it.  All *.DVSSP and *.DVSCC (no *.DVS)

Is this something we should worry about?  If so, is there a good way to fix it?

Thanks

- John

[JesusWept3]

So basically in Collections, each CAB file created has an entry in the Collections table and given an ID like 1234.

So collection ID 1234 turns in to Collection1234.cab.
Each DVS record is stored in the Saveset table and says CollectionIdentity = 1234, so when an item is opened, it looks at the Collection table for ID 1234 and can find the file name and path of the CAB where the item is stored.

The DVSSP and DVSCC is held in the Vault Stores Saveset SISPart table, so if its looking for a particular DVSSP that has been collected, it can go to ID 1234 and find the CAB etc

When the CAB file is created, it is given a Total Count and a Reference Count, and both should match at the very beginning, so if you store 100 items, RefCount and TotalCount = 100

When you delete an item, or an item expires, the refCount is then decreased by however many items were deleted. so if you delete 50 items, you now have a refcount of 50 and TotalCount of 100

When the RefCount is a certain percentage of the total count, it then extracts out the existing DVS/DVSCC/DVSSP files to their original location and deletes the CAB file, because you cannot delete items in a CAB file (same as you can't delete items in a ZIP or RAR file etc) --- This is called Sparse Collections

But lets say it loses count for whatever reason, and it has a refcount of 5 and a total count of 100
Well this would be enough to trigger the Sparse Collections process, but then it looks at the Saveset table which says "i have 20 items belonging to ID 1234, not 5!"

So at that point it throws the error because it tried to perform sparse collections, but in reality the number isn't low enough, so somewhere along the line theres been an issue where the counts are misaligned

And in the same token, you may have CAB files that say it has a refcount of 30 , but really it should be a refcount of 5 etc, so you're holding on to extra data unnecessarily

Your best bet is to run an EVSVR -- it has options to Verify and repair the collections count -- or at least the newer versions do, i really don't know about 8 SP4 as EVSVR was still going under alot of improvements at the time

[AndrewB]

i'd strongly recommend upgrading to a current version of EV. it looks like you're already on Win2k8 so hopefully that means you can do it in place. as JW said, there have been substantial improvements to EVSVR since EV 8.

[banana_john]

Reading between the lines, then, it looks like this should not be a major problem and we can wait till after the EV upgrade to fix it.

Thanks for the responses.

[JesusWept3 · Accepted solution]

Actually looking at the documentation you have no choice but to wait as the fix is in newer versions of EVSVR, but it's not critical, simply means you're cosuming more space than necessary