How to Fix - ExchangeStoreDB Event ID 139?
In this article, we will be discussing the ExchangeStoreDB Event ID 139 issue that you might face and see in the event viewer of the server hosting the Exchange Server. We will be discussing the causes behind the issue and how to resolve the issue in the least possible time and impact to the business.
What is ExchangeStoreDB Event 139?
In the Event Viewer, you may notice several events in one or more databases with the following error.
At '<time>' the copy of database '<database name>' on this server appears to be experiencing performance issues, possibly as a result of storage failure. Consult the event log on the server for other storage and 'ExchangeStoreDB' events for more specific information about the failure. Recovery was not attempted.
As you can see from the message, it is not an error to be taken lightly. You might also see similar entries in the Event Viewer with Event ID 533 and 153.
Event 533
Information Store – DBX01 () DBX01@ A Request to write to the file 'M:\Databases\DBX01.edb' at offset <offset> for <amount> bytes has not completed for xx second(s). This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.
Event 153
At '<time>' the Exchange store database '<database name>' copy on this server detected a Hung IO and logged an event. For more details about the failure, consult the Event log on the server for other storage and 'ExchangeStoreDB' events.
These errors are common when you have a Database Availability Group (DAG), where you have multiple copies of databases across the infrastructure.
If you have more than one database, it is important to check if the error is only on one particular database or all the databases to try to understand where the problem is.
What causes this issue?
There are many factors that may cause this issue. There could be some hardware issues with the server itself or the underlying hardware of the host (if it is a virtual machine). There could be issues with the network storage, or the hard drives are damaged. It is highly recommended to communicate with the hardware team or the supplier to make sure that there are no issues or faults. All hardware must be checked and even the hard drives for potential failure. If network storage is in place, you need to ensure that all fibre connections are secured.
There could have been a sudden loss of power where the server was turned off improperly, causing corruption in the Exchange Server database or transaction logs. The issue could also occur if the search catalogue is corrupted.
The issue could also occur if a third-party software like backup or antivirus software and configurations are not directly compatible with your Exchange Server version.
Possible Solutions to Resolve the Event ID 139 Issue
With regards to hardware, you can take the help of your hardware team or vendor to replace the faulty drives or other hardware.
Rebuilding the Search Catalogue
Logon to the server where the issue is and open the Exchange Management Shell (EMS). Then, change the directory to the ResetSearchIndex.ps1 script.
<drive> :\Program Files\Microsoft\Exchange Server\Scripts
Suspend the replication from active node and shift to another passive node using the below command:
Suspend-MailboxDatabaseCopy -Identity <database name>\<server name>
Execute the below command to reset the search index:
ResetSearchIndex.ps1 -force <server name>
To verify the status of rebuilding of index, add the MSExchange Search Indices\Full Crawl Mode Status counter to Performance Monitor before running the above command. The counter will be 0 before running the command, changes to 1 during the full crawl, and then back to 0 after the indexing is complete.
Once all is done, run the following command:
Resume-MailboxDatabaseCopy -Identity <database name>\<server name>
Fixing the Corrupt Database or Transaction Logs
You can use the EseUtil command to perform Soft Recovery to try to fix minor issues. If it fails, you can go for Hard Recovery. However, Hard Recovery is not recommended as it simply purges any corrupted data or possible corrupted data from the database. Also, there is no guarantee that the database will work afterwards.
Businesses are dependent on emails for communication, notifications, and information. So, resolving the problem as fast as possible with minimum impact is important.
You can find this Microsoft thread for more thoughts of community experts.