Not Allowed Disable EMC Centera Collection - Event 6902

[ianG]

Hi folks,

Basically a follow on to the following forum thread:

https://www-secure.symantec.com/connect/forums/not-allowed-disable-emc-centera-collection

And the long and short of it, is that I'm also having difficulty changing the Collections area for a couple of partitions. I ran the SQL query as suggested in the linked forum post, and I am getting a return of 'count' > 0. Unfortunately though, Im not sure what to do next.

Event log entry:

Event Type:    Error
Event Source:    Enterprise Vault
Event Category:    Storage Management
Event ID:    6902
Date:        03/10/2011
Time:        12:37:01
User:        N/A
Computer:    evserver01
Description:
Unable to update Vault Store Partition record.
 
 Partition   : 17AD37CC0BE4F3248XXXXXX5F707531C61q10000kvsarchive
 Destination :
 
 Internal references:
 Flags     :
 Error     : EMC Centera Collection cannot be disabled until all uncollected Savesets have been collected.   If the Storage Service is not running start it and try again later.   If the Storage Service is running try again later.      [0xc0041af9]
 Reference : .\StorageManage.cpp (CStorageManage::EMCCenteraDisableCollection) [lines {...,2533,2534,2543,2544,2548,2552,2553,2554,2564,2579,2583,2585}] built Apr 12 00:51:34 2010
 

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp

Storage service is running, and have tried it a few times. Vault store usage report, shows 0 items awaiting backup (for what thats worth).

[JesusWept3]

look in your collections and see if there are any MSG files are contained there
also you will probably want to look in sql to determine if there are items in that partition with a CollectionIdentity set to null (which is really what is stopping you)

[ianG]

Hmm, better break this up as theres 2 partitions Im having difficulty with. One has 2 items in the Collections area (.dvs files, with recent creation dates of just last night), but the other one doesnt. Just a large empty folder structure.

Both of them have a alot of items with CollectionIdentity set to null though (~20,000+ ).

We have been archiving to these 2 stores for years now though, so it might have been that the ones with a null CollectionIdentity are the earliest items, and predate us enabling Collections - would that make sense?

[ianG]

Just picking this up again after not getting time to look at it for the past few months. Unfortunately, the issue is still hanging around and so I've opened a support call.

Any further thoughts though in the meantime?

[Chris_Warren]

For the items in the Saveset table with a CollectionIdentity of NULL, how old are the ArchiveDate for these?  You can also confirm that these items were archived before Collections by taking the SavesetIdentity values in the Saveset table and looking these up in the SavesetStore table.  If Centera Collections are not configured at the time of storage, the individual items will be referenced here (clip would be recorded as the StoreIdentifier value)

Another way of looking at this is to check the Collection table for any records with a NULL RelativeFileName.  During the storage to collections, EV will first build the Collection record and assign the CollectionIdentity to the Savesets and then, once the items are stored, update this record with a clip under RelativeFileName.  If that is null, EV built the record, but never got a clip, so it will still think the DVS files reside in the staging area.

Chris

[ianG]

Thanks for your input Chris

Just looking at one of the partitions, which has ~20,000 null collectionidentitys. The majority (90%) of 'ArchivedDate' for these is 2006/2007, but there are quite recent ones. One in fact with a date of '2012-01-26 02:13:00' - while I cant pinpoint the exact date when Centera Collections were enabled, they were (and still are) definitely in use throughout 2011 to date - so something wrong there..?

The 'SavesetStore' table has the same number of rows, as there are null collectionidentities in the  'SaveSet' table - so 20288. No coincidence Im sure

The 'Collection' table just has one NULL entry under the RelativeFileName - which has a creationdate of 30/01/2012 - may explain a seperate issue Im having, but not related to this Centera Collections problem?

And just to confirm, there a no files (DVS or otherwise) in the collection areas, just lots of folders.

Looking more and more like the SQL database needs to be tidied up?

[ianG · Accepted solution]

Got this resolved via help from Symantec support - had to go in and delete some erronious SQL entries holding up the disable.

Long and short of it is, if the following SQL query:

 

SELECT COUNT(*) AS Records FROM view_Saveset_Collection
      WHERE IdPartition = 0
        AND (CollectionIdentity IS NULL OR RelativeFileName IS NULL)
        AND StoreIdentifier IS NULL 

Returns records greater then 0, you cant disable Centera collections (in my case, I wanted to move the collections area to a new drive).

You'll need to get onto Symantec, to have them guide you through what exactly needs to be removed, and from where though.

[ianG]

Just wanted to also add, this looks to have also resolved an event that was being logged in the event viewer - 6621:

 Event Type:         Error
Event Source:     Enterprise Vault 
Event Category:                Storage File Watch 
Event ID:              6621
Date:                     04/02/2012
Time:                     09:43:50
User:                     N/A
Computer:          evserver01
Description:
An exception has occurred. 
Type: ce 
Reference: VSEMCC/CCSOS1 
Reason: The system cannot find the path specified.  [0x80070003] 

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp 

A dtrace of the storagefilewatch process came back with a particular .dvs file not being found. But the last 20 odd characters of the .dvs matched the transaction ID of one of the erronious SQL entries found by the SQL query in my previous post.

So managed 2 birds with one stone here, quite happy :)