Re: Database Recoverable to Disk White Space Not Available As Expe
- From: Scott <Scott@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 25 Apr 2008 09:44:01 -0700
Thnx, John.
The reasons we wish to reduce the logical and physical space on disk are
discussed in the article 'Preventative Maintenance for Microsoft Exchange':
http://whitepapers.silicon.com/0,39024759,60306738p,00.htm. Our Information
Store is currently around 84 GB.
We have 1270 mailboxes and only a single Exchange admin. Impacting four
users at a time times 300+ iterations poses logistical issues for our
organization. In the scenario you propose, those four users at a time don't
have email access...correct? Someone has to give them notice, etc. Finally,
we don't have enough space on disk now to do that.
"John Fullbright" wrote:
1. So, first your maintenance job runs. Next you wait the 14 days of DIR..
Then, you wait for online maintenance to complete to all the free pages get
marked free. Then you wait for the next online defrag to run so the space
gets consolidated. Now, finally, check the 1221. If your DIR is 14 days,
I'd expect the entire process end to end to take 15 or 16 days.
2. There are lots of reasons you get different numbers when viewing from
different tools. Jeremy Kelly explains in his blog how space is counted for
the 1221 and why. It's really just the space in the messages and
attachments tables, although other free space likely exists in other tables.
Then again, you have to account for SIS. If users a, b, and c are on the
same store and a sends an 100mb message to b and c, then only one instance
of the message is stored and all three get a pointer to it (the message and
presumably attachment both have a reference count of 3). The mailbox size
in ESM will reflect the 100mb message for all three. Now, if a cleans out
their sent items and b also deletes the message but c does not, then in ESM
the removal of the 100mb message is reflected in the mailbox size for a and
b. As for the actual database, only pointers were removed from a and b.
Because user c retained a copy of the message, there is no actual reduction
in the size of data in the message or attachments table (the reference count
is 1), and the space is not reflected as white space in the 1221. In order
for an item to be reclaimed as whitespace, it must have a reference count of
0 (no pointers to it).
3. There is a difference between the logical size of a database and the
physical size of a database. For one thing, depending on what clients are
used and where specific messages originate, properties can be duplicated and
stored in both the EDB and STM files. If I recieve a message from the
internet and then read it with a MAPI client, this is the case. If you have
OWA or Entourage users mixed with outlook (mapi) users you could see some
fairly large STM file sizes.
4. If there is white space within a database, it will be reused before the
size of the actual edb file grows. With the enterprise version of exchange,
there is no logical size limit for a store. The physical size is limited to
the space available on disk. an offline defrag takes the store offline for
a long time, and requires free disk space 110% the size of your database.
Why do you want to inflict that kind of pain on yourself and your users?
Create a new store, and move all the mailboxes to it. This only requires
free space equal to the logical size of your database, and it fully promotes
all items to the edb which effectively truncates your STM. Then just
dismount and delete the old empty store to reclaim the space. User impact
is limited to mailboxes in motion (4 at any given moment by default). and
you don't have to take the store offline.
"Scott" <Scott@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:274C0BC4-50E4-4D00-AAF0-4BBB33988793@xxxxxxxxxxxxxxxx
On 4/10/08 we implemented a mailbox management policy modifying the
'Deleted
Items' retention period from 90 days to 14 days. The reason this was done
is
that ESM mailboxes was showing a total size of around 60 GB for the
deleted
items folder. Following the execution of that policy, the mailbox
management
informational message indicated that around 10GB had been deleted (which
was
actually far less than what I had expected). Nonetheless, today I checked
for
an event id 1221 on Exchange Server 2003 Enterprise SP2 indicating that
the
10GB was recoverable, but only 1.8 GB of space is reported as recoverable.
I
have therefore postponed a scheduled offline defrag (we need the space).
Why
wasn't the disk space recoverable? Would it take longer than 14 days?
The last time we performed such a mailbox management task when we
instituted
an Inbox management policy change from unlimited retention to 90 day
retention, the disk space was recoverable after 90 days. Therefore, I
reasoned that in going from a 'Deleted Items' change from 90 to 14 days,
that
the recoverable disk space should have been reflected after 14 days.
- References:
- Database Recoverable to Disk White Space Not Available As Expected
- From: Scott
- Re: Database Recoverable to Disk White Space Not Available As Expected
- From: John Fullbright
- Database Recoverable to Disk White Space Not Available As Expected
- Prev by Date: isinteg problem
- Next by Date: Re: Log Files missing information?
- Previous by thread: Re: Database Recoverable to Disk White Space Not Available As Expected
- Next by thread: Exchange 2007 OWA issue.
- Index(es):
Relevant Pages
|
Loading
