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
-
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.
joeqwerty : @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.From Trondh -
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.
joeqwerty : @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.Bart Silverstrim : @joeqwerty: you're saying it's a two-step process then...so I was giving half-good advice? :-)Graeme Donaldson : Anything involving pst files is unlikely to be good :-)Bart Silverstrim : @Graeme:See, my personal preference says that anything involving Exchange is unlikely to be good in many cases :-)Graeme Donaldson : It's a complex beast, there's no denying it. But there's still no viable alternative after all these years.Bart Silverstrim : @Graeme: for what it is, it's good enough. But I'd still say there are viable alternatives, depending on how users are actually using the platform (for example, our organization is using it just for email. I personally think it's overkill to run Exchange JUST for email...) This isn't the forum to get into that though. If you need calendar, notes, addressbook, domain integration, email, integration with Windows services...yeah, exchange is great.From Bart Silverstrim -
Short term, get an external SCSI enclosure that is 500GB+ with your preferred disk setup and move your databases there.
From Dan -
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.
Bart Silverstrim : 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.Evan Anderson : ACK! You don't *EVER* delete Exchange transaction logs. You perform a full backup and allow the engine to flush them itself!joeqwerty : 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.Bart Silverstrim : I wasn't in charge of the exchange server in question, but out of curiosity, was something keeping them open or still using them?joeqwerty : 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: http://msexchangeteam.com/archive/2004/05/12/130556.aspxSteven : The logs are not taking up much space, the logs are removed by our backup program. The space is mostly the databases, guess I'll have to move the databases double quick!Bart Silverstrim : @joeqwerty: if I'm understanding your link correctly, it's okay to delete the transaction logs as long as you leave the last few in the system for recovery and consistency. I think that's what our site had done...deleted logfiles older than, say, a month, then restart. Am I mistaken in that understanding?joeqwerty : @Bart: Yes, you're slightly mistaken. While I never recommend deleting the log files, if you absolutely need to you can but you can't just pick some random log files based on the timestamp. You need to make sure the logs you delete have been commited to the database. The article I posted a link to details how to determine this.From joeqwerty -
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.)
From Evan Anderson
