asked on

What is the root cause of corrupt exchange 2010 database search

Do you know what would cause the searches to fail on Exchange 2010 databases ?
Users are reporting that they are unable to find all items during a search. Helpdesk knows how to fix the problem by recreating the search files or to go around it by building new a database and copying the mailboxes. However we are trying to find out what is causing the frequent corruption. The Exchange server is Exchange 2010, Trend Micro Scan Mail for exchange mail filter, code two pro signature and Symantec Backup Exec 2015 remote agent also run on the server.

This link is a discussion of similar problems with DAGs and one user traced the problem to an anti virus product.

https://social.technet.microsoft.com/Forums/exchange/en-US/d0d84126-2b83-48bf-8eed-240465900430/repeatedly-corrupted-search-catalogs-on-multiple-dag-members?forum=exchange2010

Guy Lidbetter

Hi masterofnone ;-p

I previously had a very similar issue a while back and stumbled across a post which resolved the issue for us. It came down to the Index DB being corrupt so a CatalogOnly reseed just rebuilt a corrupt DB that failed at a later stage once again on a DB move.

I don't recall where I got it from but I've had this as a sticky in my one note:

1. Logon to the Exchange 2010 server that has the problem database and index.

2. Open the Exchange Management Shell.

3. Change to the following directory where the ResetSearchIndex.ps1 script is located: <drive> :\Program Files\Microsoft\Exchange Server\Scripts

4. Suspend the MailboxDatabaseCopy process from the active node MBX2 to the target passive node MBX1:

Suspend-MailboxDatabaseCopy -Identity DB1\MBX1

5. Run the following script to remove the index directories that are associated with the specified mailbox database with the source MBX2.

ResetSearchIndex.ps1 -force MBX2

How to Rebuild the Full-Text Index Catalog

http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx

Note: it also applies to Exchange 2010.

6. Verify that the rebuilding of the index has completed:

a. Before doing the ResetSearchIndex - add this counter to a live Perfmon: MSExchange Search Indices\Full Crawl Mode Status

b. This counter will be 0 before running ResetSearchIndex and go to 1 during the full crawl and then back to 0 after ResetSearchIndex finishes.

c. You will receive MSExchange Search Indexer Event ID 109 when the full crawl begins.

d. You will receive MSExchange Search Indexer Event ID 110 when the full crawl ends.

7. Reseed the content index catalog from a specific source (source node is the active node MBX2 and the passive node is MBX1):

Update-MailboxDatabaseCopy -Identity DB1\MBX1 -SourceServer MBX2 -CatalogOnly

Reseed the Search Catalog: Exchange 2010 Help

http://technet.microsoft.com/en-us/library/ee633475.aspx

8. Resume the MailboxDatabaseCopy from the active node MBX2 to the passive node MBX1:

Resume-MailboxDatabaseCopy -Identity DB1\MBX1

Give it a go and let me know how you get on....

ASKER CERTIFIED SOLUTION

Guy Lidbetter

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Will Szymkowski

If you are getting consistent indexing corruption i would look in the logs to check and see if anything in there is standing out in regards to your database. Also what SP version and RU do you have installed for your Exchange 2010 environment? If you are way out I would consider upgrading to the latest version.

Will.

masterofall

ASKER

Guy Questions

Are the Exchange Servers Virtual? ==> No

Have you checked the AV exclusion lists? ==> Yes, we did not find any scans.

Are you running a file level backup of the index DB directory? ==> Yes and my backup admin suspect that it is the problem.

Have you run any disk IO (read\write Delays, queues etc) monitors ==> Just ran Dell DPACK this weekend.

masterofall

ASKER

The problem was caused by backup exec's SDR backup. It was backing up the directory with the search file. The SDR backup does not nee that drive so we unchecked it.

Guy Lidbetter

Glad you got that sorted!