We should look for options when “Exchange Databases are not mounting”
Good backup Available.
No Backup – Exchange mailbox Databases are down.
Mounting a blank database – Keeping the messaging alive until you repair the exchange databases.
Soft recovery and Repairing the Exchange Databases
Recovery Databases
Have tried to include as much scenarios as possible.
Good backup Available
Best option is restoring from Backup software’s like Symantec which is the best option to have minimal downtime. but make sure you have to retain the live data whichever is on the existing drives – As you will lose data from the Backup taken time to the Storage Failure time.
if you have a good backup First Restore from the Backup get the production running. Then you can create a recovery database and repair the broken databases and merge with your production.
you may have to take a copy or rename the database file before restoring using the backup software as they can overwrite the databases files residing on the existing drives.
No Backup – Exchange mailbox Databases are down
Some Organizations start depending on DAG . Backup less solutions . Still there are chances where your Database didn’t failover due to a network issue or various other reasons. Try forcing the failover. Check you can access the storage and bring that back. The stability of the databases have increased where the server or storage undergoes a intermittent failure new exchange version cure themselves in few scenarios when it comes to database copies.
If you don’t have a backup , repairing the existing databases takes time approximately 5-10 Gb per hour.Totally depends on the IOPS/processor. if you don’t have a backup always take a copy of the broken databases. so that even if your repair is interrupted you don’t lose hope,you can copy it again for recovery purposes . Before that,There are various ways to get your databases healthy, 5-10 gb per hour is the worst case scenario.
You got to check the health of the database , Where Exchange cannot connect back to a database again . if its not gracefully dismounted or disconnected from storage or server or anti virus removes sometimes hold the log files mistakenly. lets see how to check the health of the databases.
Open powershell
Locate to the .\eseutil.exe,Default location –
To Check the status of the Exchange database :
locate to the bin folder to check the health of the exchange database
there are two results, It may say clean or dirty , will go through both.
showing CLEAN SHUTDOWN – Database is healthy and its in a good shape. It couldn’t mount as its not able to understand the existing sequence of the log files.
Removing all the logs files from the logs files location and Mount the database. It should generate a new series of log files and mounting the database gracefully.
To get log file Location –
To force mount the databases –
showing Dirty SHUTDOWN – Database is not in a good state (worst case) , if the database sizes are massive, you cannot keep the environment down until the databases are repaired. here is the trick of mounting a blank database to keep the environment active going with a blank mailbox. and repair the broken databases and swap it again then merge them. if you don’t want to mount a blank database.skip it.
Mounting a blank database – Keeping the messaging alive until you repair the exchange databases.
Stop Microsoft Exchange Search Service
Stop Microsoft Exchange Search Host Controller Service
Now you can rename the database folder. Create a identical folder.
Mounting the store will force the creation of an empty database.
As soon as you mount a blank database in the messaging environment. Outlook will prompt for a restart. Once the outlook is restarted.
Users get an option of getting into Temporary mailbox to send and receive emails or Use Old data to look their cached PST ,if they are in Outlook cache mode.
if health check shows dirty –
Lets see how we can handle the broken database. you can see a row called “logs required”
Check the required logs are available or not . in my case its 6079 – 6104
Check if you have the logs available
if you have the logs available – Make sure you got the .chk file in the same location. If you don’t have the required log files skip this step.
You can try running the soft recovery – (/r)
Have the database and log files in the default location
If you cannot have in the default location use /D for database location , /s for checkpoint file location , /l for log file location.
if you don’t mention it. it will take the default location
“/a” is for – even if some log files are missing it will try to get the database to a good shape (Data loss will be there)
E01 – Go to the log file location check how it starts E00 or E01 or E02
Check the status after the soft Recovery – If its showing Clean Shutdown – You can mount the database, if it doesnt , you can always move the logs and try mounting it as the databases are in clean shutdown.
If its not in Clean shutdown . Even after soft recovery Process
Repairing the Exchange Database : (5 to 8 GB /hour) (Exchange 2010 and later versions are much faster)
It will repair the database with 98% of success – Where data loss will be there in the corrupted portion of it. Mostly its minimal.
Once the repair process is completed.We can see the database to Clean shutdown .
I would recommend to get the mailboxes moved to a different database as soon as possible , to be on a safer side. also the Microsoft supportability point of view.
Recovery Databases –
when its comes to recovery databases,you have to understand about database swapping as well.if you repaired a 500 Gb databases and your temporary database is 5 gb. there is no point in merging 500 gb recovery database with 5 gb temporary database. Also the outlook will always wants the old database back in place to overcome the initial prompt when you have a temporary database mounted. As you dismount the blank database and mount the repaired database as primary and smaller database on the recovery . So that merging can be done quicker and simpler.
Creating a recovery database with existing database –
Merge them for one mailbox –
If you have different users with same display name – below command should help you.
Merge them in bulk –
Known Errors :
Resolution –
Use
Now Consider Database Repair Failed –
Mount a blank database.
Go to the cached outlook – Export to PST via Outlook.
Create a new Outlook Profile – Import PST
Other options – you can consider 3rd party solutions for EDB to PST conversion.
After repairing the databases if users have issues in accessing folder you can run a repair on the mailbox
Known issues –
Issue :
Resolution –
Database is in bad share after repair – Create a new database and move them
Issue :
Log Name: Application
Source: MSExchangeIS
Event ID: 2006
Level: Error
Description:
Microsoft Exchange Information Store worker process (12584) has encountered an unexpected database error (Illegal duplicate key) for database ‘Mailbox Database’ with a call stack of
at Microsoft.Exchange.Server.Storage.PhysicalAccessJet.JetTableOperator.Insert(IList`1 columns, IList`1 values, Column identityColumnToFetch, Boolean unversioned, Boolean ignoreDuplicateKey, Object& identityValue)
at Microsoft.Exchange.Server.Storage.PhysicalAccessJet.JetInsertOperator.ExecuteScalar()
at Microsoft.Exchange.Server.Storage.PhysicalAccess.DataRow.Insert(IConnectionProvider connectionProvider)
at Microsoft.Exchange.Server.Storage.StoreCommonServices.ObjectPropertyBag.Flush(Context context)
at Microsoft.Exchange.Server.Storage.LogicalDataModel.Item.Flush(Context context)
at Microsoft.Exchange.Server.Storage.LogicalDataModel.Message.Flush(Context context)
at Microsoft.Exchange.Server.Storage.LogicalDataModel.Message.SaveChanges(Context context)
at Microsoft.Exchange.Server.Storage.LogicalDataModel.TopMessage.SaveChanges(Context context, SaveMessageChangesFlags flags)
at Microsoft.Exchange.Protocols.MAPI.MapiMessage.SaveChangesInternal(MapiContext context, MapiSaveMessageChangesFlags saveFlags, ExchangeId& newMid)
Log Name: Application
Source: MSExchangeIS
Event ID: 1046
Level: Error
Description:
Unexpected error encountered in critical block. Location:(Microsoft.Exchange.Diagnostics.LID), scope: (MailboxShared), callstack: ( at Microsoft.Exchange.Server.Storage.StoreCommonServices.Context.OnCriticalBlockFailed(LID lid, CriticalBlockScope criticalBlockScope)
at Microsoft.Exchange.Server.Storage.StoreCommonServices.Context.CriticalBlockFrame.Dispose()
at Microsoft.Exchange.Server.Storage.LogicalDataModel.TopMessage.SaveChanges(Context context, SaveMessageChangesFlags flags)
at Microsoft.Exchange.Protocols.MAPI.MapiMessage.SaveChangesInternal(MapiContext context, MapiSaveMessageChangesFlags saveFlags, ExchangeId& newMid)
Log Name: Application
Source: MSExchangeIS
Event ID: 1002
Level: Error
Description:
Unhandled exception (Microsoft.Exchange.Server.Storage.Common.DuplicateKeyException: JetTableOperator.Insert —> Microsoft.Isam.Esent.Interop.EsentKeyDuplicateException: Illegal duplicate key
at Microsoft.Isam.Esent.Interop.Server2003.Server2003Api.JetUpdate2(JET_SESID sesid, JET_TABLEID tableid, Byte[] bookmark, Int32 bookmarkSize, Int32& actualBookmarkSize, UpdateGrbit grbit)
at Microsoft.Exchange.Server.Storage.PhysicalAccessJet.JetTableOperator.Insert(IList`1 columns, IList`1 values, Column identityColumnToFetch, Boolean unversioned, Boolean ignoreDuplicateKey, Object& identityValue)
Resolution –
Database is in bad shape after repair – Create a new database and move them
The post How to restore Exchange Databases from a Storage failure appeared first on CareExchange.in.