We recently upgraded our EV 6.0 server to EV 6.0 SP2. I've been getting a lot of strange errors, most of which seem to be related to EV doing a rebuild of one of our Journaling indexes.
Right now I'm wondering about the following error:
Event Type:Error
Event Source:Enterprise Vault
Event Category:Storage Crawler
Event ID:6882
Date:5/22/2006
Time:2:22:44 PM
User:N/A
Computer:SRV-MPLS-KVS
Description:
Unable to complete retrieval request
Reason: The docfile has been corrupted.
Vault: compliancemailbox3
Vault Id: 160C3981C16BBF9469C4136DEDA1E54791110000kvsvault
Item Id: 160C3981C16BBF9469C4136DEDA1E54791110000kvsvault+818000000000000~200604172041430000~0~068FDDCC7EFF4EBCBA0039EE3348D01+0++0+2+38858.37494178240700000+11+19653++3+3+1619367
Reference: LSFF/LF
Suplementary Info: F:\Enterprise Vault Stores\Journal Ptn1\2006\04\17\20\818000000000000~200604172041430000~0.DVS
I'm getting a whole slew of these errors, but mostly for just a few items that are being processed by the StorageCrawler service.
a dtrace of the StorageCrawler service gives me errors like this:
747119:09:07.231 (StorageCrawler)<4508>EV:LCItemFetcher::FindFirstPendingRequest Request Info: ]
Now, I realize that these are most likely corrupted files, or something along those lines- is it safe to ignore them, or am I better off removing the offending files? Will these get fixed once the index finishes rebuilding?
I'm also seeing some messages like this:
746919:09:07.231 (StorageCrawler)<4508>EV:MCArchiveRevisions::GetItem ArchiveId:160C3981C16BBF9469C4136DEDA1E54791110000kvsvault (compliancemailbox3)|Original Descriptor:160C3981C16BBF9469C4136DEDA1E54791110000kvsvault+817000000000000~200605021637510000~0~55678729638A4214A81DC21A65674E0+0++0+2+38858.35156392361400000+9+19535++3+3+1619249|Actual Descriptor:(null) (hr=Unable to retrieve item, if an HSM is being used check that it is running Saveset Id: %1 Saveset File: %2 Vault Store: %3 Vault Store Id: %4 Partition: %5 Partition Id: %6 )
747919:09:07.231 (StorageCrawler)<3048>EV:MCArchiveCrawler::GetNextItem Next ISN:19535 Format:3 (hr=Success )|SSID:817000000000000~200605021637510000~0~55678729638A4214A81DC21A65674E0 Item ISN:19535 Item type:VT_ERROR(Saveset is temporarily unavailable. Try operation again later. )
748019:09:07.231 (IndexServer)<4244>EV~IUnable to add the item to the index since it is not currently available from the Storage Service. |Reason: Saveset is temporarily unavailable. Try operation again later. |Attempt: 3 | |Index: 160C3981C16BBF9469C4136DEDA1E54791110000kvsvault/Volume:132 (compliancemailbox3) |Saveset Id: 817000000000000~200605021637510000~0~55678729638A4214A81DC21A65674E0 |Sequence Number: 19535 |
I'm going to open up a support ticket on this, but I haven't had much good luck going through the support process, so if anyone has some pointers to areas that are possible culprits it might help define the support request.
We had a rather large journaling archive, and started getting some messages that made it sound like the index was full. Since we had 6.0 SP2, I assumed it would roll over into a new volume, but we didn't see that happening, so we created a new journal archive and pointed the Journaling task at the new one instead (the compliancemailbox3 mentioned in the above errors). I don't know if this is the source of the problem or not, but once we created the new Journal archive it started archiving mail from the journal mailbox again, so we thought it was OK.
Also getting some errors in CA, where the vault store for the large journal archive (the one prior to the creation of the new one, above) doesn't show up under the available "vaults" in the CA main administrative page. But that's an error to take up with support, I think.
-Eric
