Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The volume that has the Exchange 2007 databases on has less than 10GB left out of 250GB. I can't move over to another server just yet and there is no spare capacity in the server for additional disks.

Do I have any short term options I can run without much disruption? Compact the database maybe? Any powershell commands to magically shrink the db? Thanks

PS I've already set some policies to clean up old mail but these don't appear to have made any difference.

Thanks S

share|improve this question
add comment

5 Answers

up vote 1 down vote accepted

Short term, get an external SCSI enclosure that is 500GB+ with your preferred disk setup and move your databases there.

share|improve this answer
add comment

It's doubtful that the database is taking up all that much disk space. What's the size of the edb file(s)? It's more likely that you have a large number of transaction logs that haven't been flushed. My recommendation would be to perform a full backup of Exchange using an Exchange aware backup program that can flush the transaction logs after the backup completes.

share|improve this answer
1  
Forgot about logs. We've been bitten more than once by space issues and having gigs of transaction log txt files left on a partition. Deleting them freed up huge amounts of space. –  Bart Silverstrim Nov 30 '09 at 19:06
3  
ACK! You don't EVER delete Exchange transaction logs. You perform a full backup and allow the engine to flush them itself! –  Evan Anderson Nov 30 '09 at 20:33
1  
I'm with Evan on this, deleting the logs is only asking for trouble. Perform a full Exchange aware backup as suggested and let the backup flush the logs. –  joeqwerty Nov 30 '09 at 21:38
1  
I wasn't in charge of the exchange server in question, but out of curiosity, was something keeping them open or still using them? –  Bart Silverstrim Nov 30 '09 at 22:52
2  
The transaction logs are never flushed\purged unless an Exchange aware backup is performed with the flush logs option enabled, or a full backup of the Information Store is performed by an Exchange aware backup program (or you have circular logging enabled). Here's some good info from the MS Exchange Team regarding the transaction logs: msexchangeteam.com/archive/2004/05/12/130556.aspx –  joeqwerty Nov 30 '09 at 23:54
show 3 more comments

First I would check is that you regurlarly do Exchange backups, as this will flush out your transaction logs, freeing valuable space.

Apart from that, as long as your Exchange database is running database maintenance regularly, it will free up space itself.

You can also use the export-mailbox cmdlet to copy parts of user's mailboxes (say, items older than two years for instance) to pst files. I wouldn't do this without some end user communication first, though.

share|improve this answer
2  
@Trondh: Your comments regarding the Exchange maintenence process and regarding exporting users mailboxes to pst file are incorrect. These operations, while removing items from the database, do not reduce the size of the physical file. In order to reduce the size of the physical file and reclaim the disk space, you need to perform an offline defrag of the database using the ESEUTIL utility. –  joeqwerty Nov 30 '09 at 17:23
add comment

There are no "magical" commands to shrink the database. The database file (EDB) will only shrink if you perform an offline degfragmentation, and even then it won't shrink unless the database had white-space (free space) in the file to begin with.

Assuming you are doing backups with an Exchange-aware backup, your database doesn't have any significant quantity of white space in it, and the database file really is approaching 250GB, there's not a lot that you can do other than add storage or get users to delete a sufficient quantity of items (and perform a backup so that those items are actually flushed from the store) in order to create white space in the database file to arrest the growth of the database file. (You can find your white space by looking for event ID 1221 in your Application Log, from event source "MSExchangeIS Mailbox Store").

My guess lies with the other posters' answers, though. You're probably building up database transaction logs (do you see many, many gigabytes of ".LOG" files in your Exchange database directory-- \Program Files\Microsoft\Exchange Server\Mailbox, by default) and you're not doing proper backups. If you're not using an Exchange aware backup you're likely not going to be able to recover your server in the event of a fault condition, and you're going to have disk space exhaustion like you're seeing.

(It is theoretically possible to enable circular logging for a storage group and stop transaction log growth, as well, but you're sacraficing recovery capabilities if you do that.)

share|improve this answer
add comment

Our run after the basics already outlined is to identify the biggest mail users and have them export their old email to a .pst archive...usually there's a small number of users taking up a huge amount of space. Seems to help with buying time.

share|improve this answer
    
@Bart: See my comment to Trondh's answer. Exporting to pst files does not reduce the size of the physical file, so at the end of the day you're left with a database file with lots of whitespace and a physical file that hasn't changed in size. To reduce the size of the physical file, you need to perform an offline defrag of the database with eseutil. –  joeqwerty Nov 30 '09 at 17:33
    
@joeqwerty: you're saying it's a two-step process then...so I was giving half-good advice? :-) –  Bart Silverstrim Nov 30 '09 at 19:04
2  
Anything involving pst files is unlikely to be good :-) –  ThatGraemeGuy Nov 30 '09 at 21:13
    
@Graeme:See, my personal preference says that anything involving Exchange is unlikely to be good in many cases :-) –  Bart Silverstrim Nov 30 '09 at 22:51
    
It's a complex beast, there's no denying it. But there's still no viable alternative after all these years. –  ThatGraemeGuy Dec 2 '09 at 14:26
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.