Question around IndexCommited
Created: 22 Nov 2012 | Updated: 05 Dec 2012 | 10 comments
This issue has been solved. See solution.
Hi All
I have a customer on EV 10 sp2 and we are seeing some strange behavior around the Indexing
The users are not seeing consistent Indexes in AE and search. I can see in the JournalArchive table the IndexCommited column that there are thousands of items with a value of 0. This tells me that these items have not been added to the Index so it explains the user Index inconsistency. Yet the EV monitoring isn't picking this up. Before the upgrade it would as per the article below
My question is why would the EV monitoring not reflect these missing items in the Index. We do have a call open with support but they are looking at underlying Index issues and not this specific anomaly
Thanks
Discussion Filed Under:
Comments 10 Comments • Jump to latest comment
I guess the question is, how many items are awaiting to be indexed?
And I'm not entirely sure it does report on them anymore and it's in the system status section of the VAC instead
Does it show in the system status?
Hi Alex
The System Status in the VAC is what I am referring to when I said "monitoring". I should have explained properly.
So the issue being EV says system is healthy , green light; but in fact we have Items not committed to Indexing from SQL
Hi Bruce,
Sounds like a bug with the EVAC to me!!! :-)
In your IndexLocations (physical locations) check and see when was the last item created/modified? Does this match up with info in the SQL?
Regards,
Chau Tran
ASC, STS, SCS and MCITP
Hi Bruce,
Do you have any index administration tasks running or queued up? Particularly Upgrades?
This could explain delays in adding items to indexes being processed.
Hope this helps
Authorised Symantec Consultant on Archiving and eDiscovery ASC, STS, SCS, SSE+
Microsoft, NetApp and VMware certified professional MCTS, MCSE, MCSA, NCDA, NCIE-BR, VCP, VTSP
Hi Jack
You have raised some good points which I need to confirm with the customer
The customer in the past has upgraded some Indexes to 64 bit and they plan to do more. But I need to clarify something about why an Index Upgrade would impact the IndexCommited column
Thanks
My experience has been that the system prioritises the index upgrade over deleting or inserting items into the new 64bit index. Others may know for sure, but my impression has been that the new item inserts don't occur at all until the index upgrade completes.
Authorised Symantec Consultant on Archiving and eDiscovery ASC, STS, SCS, SSE+
Microsoft, NetApp and VMware certified professional MCTS, MCSE, MCSA, NCDA, NCIE-BR, VCP, VTSP
Possibly relevant Technotes.
http://www.symantec.com/business/support/index?pag...
http://www.symantec.com/business/support/index?pag...
Authorised Symantec Consultant on Archiving and eDiscovery ASC, STS, SCS, SSE+
Microsoft, NetApp and VMware certified professional MCTS, MCSE, MCSA, NCDA, NCIE-BR, VCP, VTSP
Hi Jack
This is an important point so hopefully we can get confirmation around this.
Thanks for the input around this anyway.
OK so here's what i would do
1. get a SELECT COUNT(*) FROM JournalArchive WHERE indexCommited = 0
2. Go to the Vault admin console,right click your site name and go to properties
3. Go to the Monitoring tab, second item down should be "Archived Items Awaiting Index"
4. What is the "Threshold" set to, is it higher than the COUNT(*) you got from step one?
5. Is it even Checked to monitor for items awaiting index?
6. If you right click "Status" under your "Directory on ...." , click "re-run all checks"
7. Does the alert then come up ?
One obscure thing it could be that i remember in the back of my mind is that you may need to update statistics in SQL, as i seem to remember a case or two when it would complain that it had X amount of items awaiting backup when it was really a lot lower and it was reporting stale information
So in that case i would do this and run the following SQL Statements
Thanks Alex, those are some good suggestions
Would you like to reply?
Login or Register to post your comment.