In these cases, repeatedly shrinking the database is a wasted operation, and likely created the need for autogrowth events to reclaim the space, hindering performance. A shrink operation does not preserve the fragmentation state of indexes in the database, and generally increases fragmentation to a degree. This is another reason not to repeatedly shrink the database.
Point to Tasks , point to Shrink , and then select Database. Current allocated space Displays the total used and unused space for the selected database. Available free space Displays the sum of free space in the log and data files of the selected database. By default, this option is not selected when the dialog is opened. If this option is selected, the user must specify a target percent option. Maximum free space in files after shrinking Enter the maximum percentage of free space to be left in the database files after the database has been shrunk.
Permissible values are between 0 and Copy and paste the following example into the query window and select Execute. Data that is moved to shrink a file can be scattered to any available location in the file. No data loss, although it will cost some downtime. Then you find that somebody put a 2 liter bottle of soda on top of the backup tapes. A bottle with a leaky seam.
Not all things go better with Coke! Your Exchange database is unstartable and your backups are bad. What do you do next? Exchange includes two very sophisticated utilities that will come to your rescue: Eseutil and Isinteg. If there is salvageable data in your injured database, they'll stitch it back together for you. In actual practice, these two utilities are remarkably successful in fixing up a database almost like brand new.
In fact, they may be a little too successful. I've seen too many administrators who've gotten careless with their backups because they know they can count on the repair tools to almost always save their bacon. That parenthetical almost is why you can't rely on repairing a database as your primary method of data recovery. Nothing beats having an extra copy of your data safely off in a second location like on a backup tape.
And repair can only repair what's still there. Massive damage to the existing database or complete loss of the drives is an all too frequent occurrence, even with today's redundant disk hardware. Here's how to repair an Exchange database that won't start:. Check the Application Log--Exchange logs pretty detailed events for the startup of a database.
One thing to remember about Exchange event logging: We have pretty generic event IDs for wide classes of events, and we usually put the real error or information in the description field. Restart the server. I know everyone is tired of hearing this advice from Microsoft support people, but let's face it--it's a really good way of clearing out random problems in an environment and getting you back to a good state when you don't have time to find the root cause before correcting the problem.
If you're not sure where your database files are, or what they are called, you can find out in Exchange System Manager by accessing the database properties. The Database page lists the paths and names.
The easiest way to do this is to have both database files. EDB and. STM in the same directory which they usually are. If they're in different places, you're going to have to point to the files on the command line. Here is a loaded up Eseutil repair command line:. This command line will repair DB1. EDB located on C: along with its matching. STM file located on D: and will put the temporary file on the E: drive. If your streaming database file. STM is not matched to the database file.
This will destroy the. STM file and repair only the data in the. EDB file. What do you lose if you lose the. STM file? It depends on what kind of clients attach to your Exchange server. STM file. You may lose some in transit messages that haven't been delivered yet. STM file, and its loss will be catastrophic to them. If clients use Outlook Web Access, messages will be in the. EDB file, but attachments sent will be in the. Repair can take a while--hours.
You're not finished yet, however. There are two more steps to complete. Repair may leave index and space allocation problems in the database. It will however create a larger amount of whitespace once online maintenance has run online maintenance is continuous in Exchange Whitespace stops the Exchange database from physically growing on your disks and allows new data coming into the Mailbox database to be consumed within the whitespace within.
To reclaim that whitespace you are correct, you would have to run an offline defrag. However, if you have Exchange I would suggest just simply moving mailboxes to a new store and removing the old one, as Exchange Standard supports 5 databases by default.
Hello Sandy, Mailbox management policy plays significient role in maintaining the size of the store. Once you have successfully completed the mailbox management policy activity then you have to ensure that online maintainance by looking at the event id , and to confirm the same.
Then you can follow the below mentioned KB for further assistance in running offline defrag. Thanks Oliver, yes we are running Exchange I hadn't thought about just moving the mailboxes to a new store. Lots of good info to consider. Orange County District Attorney Hi, It's easier than performing an offline defrag if you have the capacity to do it.
0コメント