locked
Mail Flow to a single databse stops in Exchange 2010 without dismounting the database when log drive is full RRS feed

  • Question

  • Mail Flow to a single databse stops in Exchange 2010 without dismounting the database when log drive is full ... and you get Event ID 10014 Source Event 10014 MSExchangeIS Mailbox Store. Wondering what new mechanism has been added that is causing this behaviour ?
    Friday, April 23, 2010 2:58 PM

Answers

  • In exchange 2010, instead of allowing a disk to run out of space, thus leading to a forced dismount of the database, the Store automatically monitors available free space for both the database and log drives. When the Store detects that the space available on a log or database drive is below 1GB, it cuts off all transport delivery to that database(s). This is to prevent a disk from running out of space. When the disk space goes above 1.5GB, the Store allows deliveries to continue.

    When a disk runs out of space the database can't be mounted or debugged. The database space also can't be reclaimed. This is a self-protecting mechanism that should only trigger if there is no reaction to the space issue

    errors generated by the Store.

     

    A new maintenance task called “Check critical system health" has been added to the Store. The task runs periodically to check the free disk space as reported by the operating system for both the logs and database drives. When low disk space is detected, the Store responds to the Store Driver with one of two errors that indicate the problem: ecLowMdbSpace and ecLowMdbLogSpace. The Store Driver is designed to periodically retry delivery to the database when these exceptions are encountered. When the low disk space issue has been resolved, the Store Driver automatically resumes delivery to the database.

     

    Regards,

    Xiu

    • Marked as answer by Xiu Zhang Thursday, May 6, 2010 2:53 AM
    Wednesday, April 28, 2010 9:46 AM

All replies

  • Could be back pressure. Are you running the hub transport and mailbox roles on the same box?

    Understanding Back Pressure
    http://technet.microsoft.com/en-us/library/bb201658.aspx
    Friday, April 23, 2010 4:35 PM
  • Backpressure event Ids are 15000 series - 15002, 15007 etc and it should stop all mailflow. Why just the mailflow for 1 database and the issue is resolved by creating space on the log drive for the affected databse - this drive does not host the HT queue database althought the server is hosting all the roles.

    Friday, April 23, 2010 6:11 PM
  • The database dismounts when the drive is full.
    Friday, April 23, 2010 10:03 PM
  • yes .. the database dismounts ... and it did not .. just stopped sending and receiving email. thats what  this question is about .. something has changed in 2010
    Sunday, April 25, 2010 9:24 AM
  • Nothing changed in this respect from Exchange 2003, to Exchange 2007 to Exchange 2010. When the log drive fills up the database dismountes.

    Don't let your log drive fill up.

    Monday, April 26, 2010 12:32 AM
  • Exactly ... thats what i discovered ... I am running Exchange 2010 Rollup 2 .. for one of the Databases .. my log drive had less than 1 percent of free space remaining AND THE DATABASE did not dismount -

    Exchange logs Event ID 10014 and stops the emails addresses to and from that database. So something has changed and thats what i am searching for .. NO Longer is the DATABASE dismounted. So there is something new here. And once i freed up space the email flow again started. So the mechanism is different.

    Also i will appreciate if the next person that posts something here reads what i am trying to say.

    Monday, April 26, 2010 9:43 AM
  • The database dismounting is related to the amount of space on the drive, not the percentage that's free on the drive. Does this database have multiple copies? It's possible that the drive filled up on one of the servers and then failed over to another server that had just a little bit more room.
    Monday, April 26, 2010 2:25 PM
  • In exchange 2010, instead of allowing a disk to run out of space, thus leading to a forced dismount of the database, the Store automatically monitors available free space for both the database and log drives. When the Store detects that the space available on a log or database drive is below 1GB, it cuts off all transport delivery to that database(s). This is to prevent a disk from running out of space. When the disk space goes above 1.5GB, the Store allows deliveries to continue.

    When a disk runs out of space the database can't be mounted or debugged. The database space also can't be reclaimed. This is a self-protecting mechanism that should only trigger if there is no reaction to the space issue

    errors generated by the Store.

     

    A new maintenance task called “Check critical system health" has been added to the Store. The task runs periodically to check the free disk space as reported by the operating system for both the logs and database drives. When low disk space is detected, the Store responds to the Store Driver with one of two errors that indicate the problem: ecLowMdbSpace and ecLowMdbLogSpace. The Store Driver is designed to periodically retry delivery to the database when these exceptions are encountered. When the low disk space issue has been resolved, the Store Driver automatically resumes delivery to the database.

     

    Regards,

    Xiu

    • Marked as answer by Xiu Zhang Thursday, May 6, 2010 2:53 AM
    Wednesday, April 28, 2010 9:46 AM
  • Yeah .. this does sound like what was happening .. and the best part is that there are no Technet / KB articles available yet for this. I even called MS for this case and the person there was getting this confused with Backpressure as well and the case is still .. have not heard from them and have not had the time to follow up with MS on this either.

     

    P.S. So Nitesh if you happen to read this .. please find something out on this.

    Thursday, May 6, 2010 11:29 AM
  • This condition and explaination was exactly the issue we faced. Very helpful.
    Friday, October 15, 2010 4:41 PM