1

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

Steven
  • 349
  • 4
  • 8
  • 17

6 Answers6

4

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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 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: http://msexchangeteam.com/archive/2004/05/12/130556.aspx – joeqwerty Nov 30 '09 at 23:54
  • 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! – Steven Dec 01 '09 at 10:06
  • @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? – Bart Silverstrim Dec 02 '09 at 14:56
  • @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. – joeqwerty Dec 02 '09 at 22:54
2

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.

Trondh
  • 4,201
  • 24
  • 27
  • 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
2

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.)

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
1

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.

Bart Silverstrim
  • 31,172
  • 9
  • 67
  • 87
  • @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 02 '09 at 14:26
  • @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. – Bart Silverstrim Dec 02 '09 at 14:49
1

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

DanBig
  • 11,423
  • 1
  • 29
  • 53
0

The reason for low disk space is that mailbox database had significant amounts of white space. White space cause issues with disk space utilization.

To check the White Space in your Exchange Server database, use following command:

Get-MailboxDatabase -Status | Select Name, AvailableNewMailboxSpace, DatabaseSize

The output will list all databases with their White Space. It will gove White Space in the root portion of databases.

First dismount the database, Use EseUtil /ms command, for detailed information:

Eseutil /ms “PathToDatabase\DatabaseName.edb”

After that, reclaim the White Space by defragmentation or by move mailboxes from the current database to a new one and then deleting the old one.

Refer this article for more information

Eric Simson
  • 78
  • 4