Software

Ask something
Discussion Locked

Exchange 5.5 running out space

0 helpful
10 replies

by rick_b 2 views

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

My exchange server ran out space and stopped.I have deleted over 2GB of old mail and haven't gotten the spaceback. I have just repaired my priv.edb with the eseutil and gained some space back and I have run the Performance Optimizer and it still doesn't give the space back. I have reinstalled SP4 for Exchange 5.5 and Service Pack 6a on the NT, still no luck.

Any suggestions on how to get the space back??
1000 points to the person(s) they give my space back . Thanks

10 replies

by maxwell edison

You're seeing the confluence of two separate issues. First is that NT's management utilities (like Explorer and the command shell) can't accurately report the size of an open file. That means that if one of your EDB files grows, or shrinks, a great deal that just examining the file size won't show you that change unless you stop and restart the IS. More to the point, why isn't your priv.edb file getting smaller? The answer is at once simple and counterintuitive: it won't get any smaller. Normally, the EDB database files are like those little sponge pellets you buy for your kids. When you drop them in water, they expand into dinosaurs, birds, or whatever. There's no way to shrink the sponge back into its original pellet size. The Exchange IS is designed NOT to release space back to the filesystem, since it's likely that any space it releases is going to be grabbed back up by the database. You can force the IS to yield up its free space by stopping the IS service and using eseutil to doan offline defragmentation. However, since space is really tight you should consider whether now is a good time to add more disk space.

(continued in comments...)

by maxwell edison

.
.
Keeping that in mind, consider this: Exchange writes all transactions first to the current transaction log file. Thus, the current database encompasses the uncommitted data in the transaction log and the .edb database file.

You should perhaps consider placing log files on a disk separate from the .edb files - for two reasons. First, you can increase performance significantly, perhaps by 30 percent or more, by placing the .log files away from the .edb files. Second, the chances of recovering from a system meltdown increase when .log files are separate from .edb files. For example, if the hard disk where you store the Exchange databases suddenly fails, you can rebuild the .edb files to their state before the crash if the .log files are still available on the other good partition.

You can move transaction log files to other partitions (disks) in two ways. The easiest way is to use the Performance Optimizer which automatically determines whether you can separate the transaction logs from the databases.

This may not be the exact answer you're looking for, but if you "can't get there from here" (so to speak) perhaps it's time to consider a different destination.

Best of luck and have a GREAT 2002!

Maxwell

by maxwell edison

.
.
A reason why you may not have recovered that disk space:

Offline defragmentation (Eseutil.exe) works by creating a new database consisting only of pages actually used from the original one, and then copying that database over the original one. To perform offline defragmentation, you therefore need at least as much free disk space as the expected size of the new database. The normal recommendation is to have at least as much space free as the size of the original database.

If you run out of space or offline defragmenation fails for some other reason, there is no harm done to your original database, but you should find and manually delete the partial new database (usually Tempdfrg.edb) to free up disk space.

So look for thatfile (Tempdfrg.edb - or something similar) and delete it. (Backup the file someplace else first, just in case it's the wrong file.)

Offline defragmentation can be performed in place or out of place on another server if you are short on disk space. To defragment on another server, copy Ese.dll, Eseutil.exe and the EDB file to be defragmented to a drive with sufficient space. Copy the defragmented EDB file back in place after defragmentation completes.

It is important to perform a full online backup after defragmentation.

Regards,

Maxwell

by maxwell edison

.
.
A reason why you may not have recovered that disk space:

Offline defragmentation (Eseutil.exe) works by creating a new database consisting only of pages actually used from the original one, and then copying that database over the original one. To perform offline defragmentation, you therefore need at least as much free disk space as the expected size of the new database. The normal recommendation is to have at least as much space free as the size of the original database.

If you run out of space or offline defragmenation fails for some other reason, there is no harm done to your original database, but you should find and manually delete the partial new database (usually Tempdfrg.edb) to free up disk space.

So look for thatfile (Tempdfrg.edb - or something similar) and delete it. (Backup the file someplace else first, just in case it's the wrong file.)

Offline defragmentation can be performed in place or out of place on another server if you are short on disk space. To defragment on another server, copy Ese.dll, Eseutil.exe and the EDB file to be defragmented to a drive with sufficient space. Copy the defragmented EDB file back in place after defragmentation completes.

It is important to perform a full online backup after defragmentation.

Regards,

Maxwell

by rick_b

Great Job, I got another hard drive and moved my transaction logs, to the new drive. That on slipped by me

This discussion is closed to new replies.