How long eseutil p take

That way I can test the utility's rate without doing it on my live db. Is there a different ration for the stm MIME db, or does it compact at about the same rate as the edb? Thursday, May 7, PM. BTW, why are you defraging database? You should first check event for available white space in database, that is the approx amount of size which will be compacted after defrag. BTW, which version of Exchange do you use? If you have enterprise edition of Exchange then you can create a new storage group and DB and move all mailboxes to it which will indirectly compact the size of DB.

Gim Friday, May 8, AM. Hey Arun,. After defrag is complete, you need to make sure you have created a full backup of database as it will not match the previous backup the database has a new structure now. Defragmentation should not be performed on databases connected within DAG. If it is preformed, a new GUID of the database is created which means that the Exchange will see it as a completely new object.

Each log file or the. The result of this cmdlet is presented above. You can see that there is much information about the database. This piece of information means that there is no incompatibility between the information in log file and the database. Here you can also find the information on so-called DB Signatures which indicates the database signature already mentioned in the previous section of this article. In the screenshot above, it is displayed after the word Rand.

Additional important information is carried by the Log Signature header which points to the last log signature. In the example above, the signature number is The header called Log Required tell us which log files are required to start the database.

In our case, the value shows which suggests that everything is fine and no file is required. However, in the case when the database had been stopped unexpectedly, this value could be, e. To do that, you can use the cmdlet below to see what is included in the main Exchange log file — E In the screenshot above, you can see lGeneration number, which represents a sequential log number to be used in the future — in the example above, it is EC.

You can also notice that next to the Signatures header, there is the following number displayed: — the same that was found in the database file. This suggests that this log file belongs to the previous database.

As you can see, the sequence consists of only two logs: E The additional information provided is that they do not generate any problems at this moment. The last file that we can take a look at is the checkpoint file E Run the cmdlet below to display results:.

One of the important pieces of information that you can find here is the name of the last checkpoint — the file that has been already added to the database. In this case, it is 1C which refers to the file E Of course, what is always significant is the signature that point to the log file which corresponds with the E Before you start working on your database with the ESEUTIL tool make sure that you have all files from the database catalogue backed up and safe.

As it was already mentioned, in some situations a so-called Dirty Shutdown may happen. When you see such a status displayed next to the State header, this suggests that some required log files are missing. As you can see, the Dirty Shutdown state has been reported. In the next line, there is the Log Required header which informs about the necessary log files. According to the screenshot above, the missing log files are from 23 to 27 in the hexadecimal format 23 stands for 17 and 27 stands for 1b so the missing log files are from E Those logs are required to recover the database without data loss.

If you have the missing logs, the recovery process would be a piece of cake. Divide the figure that you obtained in step 3 by 9 GB per hour. The figure that you obtain is the approximate time that it will take to defragment the database. This number is only for reference. The exact number depends on your hardware and production environment. Post a Comment. The repair runs at approximately 4 to 6 gigabytes GB per hour GB database requires approximately 8 hours for repair and approximately 8 hours for the ISInteg process, for a total of 16 hours The defragmentation option makes used storage contiguous, eliminates unused storage, and compacts the database, which reduces the database's size.

To determine the actual space required, follow these steps Make sure that the information store service is not running. No comments:.