Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Indexing Problems with very large file on EMC Centera

Created: 08 Jan 2013 • Updated: 11 Jan 2013 | 6 comments
This issue has been solved. See solution.

Hi everybody,

I have the problem that a file in the FSA is already archived to our EMC Centera and now has to be indexed. Unfortunately Vault cannot retrieve this file in a timely manner as the file is about 1 GB of size. The only way to get it back is using FSAUtility and even with this program the retrieval takes quite a lot of time.

36           14:34:48.438      [3096]  (StorageCrawler)            <7208> EV:L       CItemFetcher::Start ArchiveID:116F5C8324031254DBDCB8C6D783865131110000evserver01 Slave thread: 8992  (hr=Success  (0))

37           14:34:48.438      [3096]  (StorageCrawler)            <7208> EV:M     CItemFetcher::RequestItem (BTID:8992) NextISN:17297 MaxISN:18446744073709551615 Format:3 MaxMarshallSize:10240 (KB) IIRebuildMode:1 (hr=Success  (0))

38           14:34:48.438      [3096]  (StorageCrawler)            <7208> EV:L       CItemFetcher::WaitForItem Request Info: [17297, ifIndexMetadata (3), 10240 (KB), iirmNone (1), 1C2556C79F73CED48BB21FBB173C06B561110000evserver01+201210180549237~201107080020300000~Z~50FFFDB0DB44DC2AE5738F1EC8BCD391+0+8RJTCITSJC0QReF0UG21DA45T68G4179PLFLS705CKAVKEQKU8NN4+0+1+41200.35624999999700000+1310985+17297++500+3+17310+1, 17297, The data necessary to complete this operation is not yet available.  (0x8000000a)]

39           14:34:48.438      [3096]  (StorageCrawler)            <7208> EV:L       CItemFetcher::WaitForItem waiting NextISN:17297 Wait:5 (secs)

40           14:34:50.048      [3096]  (StorageCrawler)            <7500> EV:L       {CPools::TimerCallback} (Entry)

41           14:34:50.048      [3096]  (StorageCrawler)            <7500> EV:M     CPools::TimerCallback -- Connection string: XXXXXX,XXXXXX?C:\Sources\mailarchiv1.pea, PoolRef: 441660165098608, Usage count: 0

42           14:34:50.048      [3096]  (StorageCrawler)            <7500> EV:M     CPools::TimerCallback -- FPPool_Close -- Connection string: ANSA11,ANSA21?C:\Sources\mailarchiv1.pea, PoolRef: 441660165098608

43           14:34:50.048      [3096]  (StorageCrawler)            <7500> EV:M     CPools::TimerCallback -- Connection string: XXXXXX,XXXXXX?c:\Sources\mailarchiv1.pea, PoolRef: 334608095456168, Usage count: 0

44           14:34:50.048      [3096]  (StorageCrawler)            <7500> EV:L       {CPools::TimerCallback} (Exit) Status: [Success]

45           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:L       CItemFetcher::WaitForItem Request Info: [17297, ifIndexMetadata (3), 10240 (KB), iirmNone (1), 1C2556C79F73CED48BB21FBB173C06B561110000evserver01+201210180549237~201107080020300000~Z~50FFFDB0DB44DC2AE5738F1EC8BCD391+0+8RJTCITSJC0QReF0UG21DA45T68G4179PLFLS705CKAVKEQKU8NN4+0+1+41200.35624999999700000+1310985+17297++500+3+17310+1, 17297, The data necessary to complete this operation is not yet available.  (0x8000000a)]

46           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:L       CItemFetcher::WaitForItem (BTID:8992) NextISN:17297 Timeout:5 (secs) SSID:(null) ItemISN:0 (hr=The request timed out.      (0x80041b3a))

47           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:M     CArchiveCrawler::GetNextItem Next ISN:17297 Format:3 (hr=The request timed out.      (0x80041b3a))|SSID:(null) Item ISN:0 Item type:VT_EMPTY

48           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:L       {CClientIdentity::DetermineIdentity} (Entry)

49           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:L       {CClientIdentity::DetermineIdentity}|Validating using COM security ==> XXXXXXX

50           14:34:53.439      [3096]  (StorageCrawler)            <7208> EV:L       {CClientIdentity::DetermineIdentity} (Exit) Status: [Success]

It looks like I am running in a timeout as the storagecrawler seems to have a timeout of 5 seconds per file. That's quite too short for this big file. Any idea how I can increase this timeout ?

The indexing of this file is blocking the whole indexing process of this archive unfortunately.

Kind regards

Manfred

Comments 6 CommentsJump to latest comment

Rob.Wilcox's picture

I for one can't find any registry key related to that .. but..  the best bet is to open a Support Case and see if Support can provide you the details.

ManfredS's picture

Hi,
Actually I have already opened a case. But by it is not too helpful for me. The outcome by now is: the storage has to do it with more speed. Symantec cannot do anything. Fact is that I can retrieve the file using FSAUtility. So now I have a file in my store that needs to be indexed, but cannot, and so the whole indexing process of this archive has got stuck. The problem is, that I cannot delete this file because it does not appear in the archive explorer and we did not create placeholder files as we do not need them. So I see no way to delete the file to check if the indexing process works then. Nevertheless this file has to be archived. Is there a filesize limit for archivig ?
So I am completely stuck without any help.
Manfred

Rob.Wilcox's picture

Manfred - you do have help, both here in these forums and more importantly perhaps via Symantec Support.

There is a registry key called MaxMessageSizeToArchiveMb, which I know for sure works on the Exchange archiving side of things.  I'd be surprised if there wasn't something similar for FSA - however I'm not an FSA expert, and though I've looked in the Registry Guide I can't find the equivalent for FSA.

ManfredS's picture

Together with the support, we have deleted the problematic file and made an update to the index. now we are clean. I do not know what the problem is with this one file as it is a plain text file and we have even larger mdb files in the archive. so finally we have all but one file indexed.

SOLUTION