Indexing Problems with very large file on EMC Centera

[ManfredS]

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

[Rob_Wilcox1]

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]

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_Wilcox1]

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.

[Rob_Wilcox1]

By the way, I found:

http://www.symantec.com/business/support/index?page=content&id=TECH48803

Hope that helps,

[ManfredS · Accepted solution]

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.

[Rob_Wilcox1]

It is good to hear that you got things sorted out.