05-13-2019 04:43 AM
I just started to see this a few days ago when running my EV Health Checks. I have done about everything possible which includes.
Restarted the Server which would include all of the EV Services. Dtraced the both Storage Crawler and IndexVolumeProcessor. Made sure there is pleny of space on the Index volumes. Also there is nothing in Backup Mode. We also looked at the Database Vault Store for Fragmentation and found none. There are No failed Indexes either. No Firewall issues as well.
WTF......................
Solved! Go to Solution.
05-14-2019 03:38 AM
I wanted to give thanks to everyone that helped me resolve the problem. I found that it was a failed index volume and I had to run a rebuild on the volume to repair it. By finding the archive ID i was able to track down who the archive ID belonged to and ran the rebuild on it. It ended up being a Exchange Users Mailbox. The indexes have been repaired and I dont see the issue anymore when I run the health checks.
Thanks again. All of you in this thread who replied ROCK :)
05-13-2019 05:59 AM
Hi there,
have you checked for Errors in the Event Viewer?
Have you set the backup mode then cleared it, waited for 10 min then restarted admin service? Where are you checking the backup mode? In the GUI or with Management Shell?
05-13-2019 06:01 AM
Do you have 41334 event for backup mode clearing correctly:
https://www.veritas.com/support/en_US/article.100011782.html
What other error events (if any) you have for Index Admin Service.
Are there any errors in the dtrace?
If there are no other errors or issues, run this query on affected Vault store DB to check which archive has majority of the backlog:
select ArchivePoint.ArchivePointId, count(*) Records from journalarchive inner join ArchivePoint on ArchivePoint.ArchivePointIdentity = JournalArchive.ArchivePointIdentity where indexcommited=0 group by JournalArchive.ArchivePointIdentity, ArchivePoint.ArchivePointId Order by Records Desc
05-13-2019 06:19 AM
Yep, checked both Event ID;s in Windows and the Symantec EnterpriseVault. Yes did a Clear on both Backup Vault Stores and Index Locations and restarted the Index Service on that server. Still the indexe's are not moving. Doesnt make sense.
05-13-2019 06:20 AM
Yep, checked both Event ID;s in Windows and the Symantec EnterpriseVault. Yes did a Clear on both Backup Vault Stores and Index Locations and restarted the Index Service on that server. Still the indexe's are not moving. Doesnt make sense. I appreciate the advice.
05-13-2019 06:22 AM
No 41334 Events and I didnt see any errors from the Dtrace that I'm aware of such as Timeouts, etc.....I will run the query and update the thread.
05-13-2019 06:33 AM
I ran the query and this was the output. The 158706 is what its saying as not been indexed.
ArchivePointId Records
1CE00873C31D6E442A892D7FED9F978CC1110000EVJRN1 158706
05-13-2019 06:37 AM
I did a search on that archive ID in the VAC and its a Exchange Public Folder. Its state is Healthy and Online with No Errors.
05-13-2019 06:38 AM
Hi Mike_Reed,
What is the idpartition of the items awaiting indexing? If it is -1 then they are in the Storage queue and cannot be indexed from there.
The 29057 events could be an issue and the items are continually trying to be stored, which would then allow them to index.
Regards,
Patrick
05-13-2019 07:29 AM
Hey Patrick,
Where do I get the idPartition number from?
Thanks
05-13-2019 09:03 AM
Found the issue. Its a Failed Index on a Exchange Users Mailbox. Tried to run a verify. It failed. Tried to run a Sync it failed. Going totry and perform a Rebuild.
Stay Tuned.
05-13-2019 10:10 AM
Good luck with it.
05-13-2019 12:40 PM
If needed you can get it from the JournalArchive table.
SELECT ArchivePointIdentity, IndexCommited, IdPartition
FROM JournalArchive
WHERE ArchivePointIdentity = (SELECT ArchivePointIdentity from ArchivePoint WHERE ArchivePointId = '1CE00873C31D6E442A892D7FED9F978CC1110000EVJRN1')
AND IndexCommited = 0
Regards,
Patrick
05-14-2019 03:38 AM
I wanted to give thanks to everyone that helped me resolve the problem. I found that it was a failed index volume and I had to run a rebuild on the volume to repair it. By finding the archive ID i was able to track down who the archive ID belonged to and ran the rebuild on it. It ended up being a Exchange Users Mailbox. The indexes have been repaired and I dont see the issue anymore when I run the health checks.
Thanks again. All of you in this thread who replied ROCK :)