The same goes for offline defragmentation.
The days of online maintenance killing itself trying to defragment partially filled 4K pages of data to be on a single ESE page are gone. How often do I expect this to be used? Rarely and typically as part of troubleshooting. Note that the database must be dismounted, else you will receive JET errors and no data will be returned.ĭumping out the table information is a fairly quick operation, unless the verbose /V option is used and then the time taken will greatly increase. To get an accurate representation of the amount of white space in an Exchange 2010 database we need to use ESEUTIL /MS. Recovery must first be run to properly complete database operations for the previous shutdown.) Operation terminated with error -550 ( JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Operation terminated with error -1032 ( JET_errFileAccessDenied, Cannot access file, the file is locked or in use)Īnd if you are thinking that I’ll be sneaky and run it on a passive database copy in a DAG, then you will receive this error instead, after stopping the replication service else you will get the same error as listed above:
Note that this can only be executed against a dismounted database, and you will receive the following error if running against an active mailbox: Running ESEUTIL /MS against a lab database shows the following:įrom this we can see the breakdown in the database structure and where space is being consumed. We need to use ESEUTIL /MS to get an accurate picture of white space in an Exchange 2010 database. Remember we would come back to ESEUTIL /MS? For reference the relevant text is shown below. This is clearly stated in the Exchange team blog post. This parameter only looks at the root portion of the database. So NewAvailableMailboxSpace looks good? Well not so much. We can see the difference below, note the second command has –Status added: This data is returned when the –Status parameter is also specified to execute the more expensive work items. Enhanced ESE physical store to improve performanceĪs part of the changes to the mailbox role, the venerable event ID 1221 was removed, and output was added to Get-MailboxDatabase called AvailableNewMailboxSpace.Then along came Exchange 2010, sans Event ID 1221….Įxchange 2010 introduced numerous improvements to the Mailbox role. Event 1221 was still with us and reporting on the database white space! stm file and just like Atomic Kitten, the. Details on defragmenting databases are can be found in this KB.Įxchange 2007 dropped the. Though this could be changed by specifying the /I switch. stm would have been defragmented in addition to the. If ESEUTIL /D was executed against a database the. For a trip down memory lane there is an excellent read in this document Determining the True Amount of Space in an Exchange Database
Event 1221 does not review this shiny streaming thingymabob, and did not report what free space may have been available within the. The intent was to store native RFC content in the streaming file as the Internet was the future and content would be converted between the. Things advanced, the dotcom bubble popped and with the advent of Exchange 2000 the streaming file was introduced. Free pages that are owned by other tables in the database are not taken into account. Event 1221 estimates free space by calculating the number of empty pages owned by the messages table, the attachments table, and the database root. All space in an Exchange database is owned either by the database root or by particular tables in the database. If you perform offline defragmentation, you will recover at least the amount of space that is reported as free. More on this later….Īs mentioned in the KB, the free space that is reported by Event 1221 is a conservative estimate. Life was indeed simple and good! Additionally Exchange 5.5 SP1 also added a second enhancement for determining white space which was the ESEUTIL /MS switch to dump out the space consumed by tables in the database. Event ID 1221 would then report on the white space contained within the database file. Standard Edition could have a database of up to 16GB, and Enterprise had the “unlimited” database. In those simple Exchange days we would have one Public Folder (pub.edb) and one Mailbox database (priv.edb) per server. This event was introduced in Exchange 5.5 SP1 back in August 1998. This event would tell us the amount of white space within the database. In ye olden days when Exchange admins went to work on horses (alright, iron horses), we would look for the venerable application event log entry 1221. Historical Approach To Checking White Space