Re: Event 445 strangeness

Tech-Archive recommends: Fix windows errors by optimizing your registry

Not having memorized every single event ID, I don't know what a 445 is,
sorry.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"R Stovall" <richard-at-@xxxxxxxxxxxxxxxxx> wrote in message
news:802965CF-377E-452A-8D24-9B59BBE1C75C@xxxxxxxxxxxxxxxx
> Thanks for the reply Ed. I realize that the deleted items are not
> actually
> removed from the database (and the space freed) until the retention period
> has been reached for each message.
>
> The situation here was that the database started the day with 4340 MB free
> space and wound up shrinking by about that much after an offline defrag 22
> hours later. The maintenance process (online defrag, etc.) had not run
> before the database was dismounted and the offline defrag took place.
>
> After I remounted the database I change the retention settings and forced
> the maintenance process to run which freed up the additional 93 MB of
> space.
>
> What I don't understand is why it started throwing the 445 warnings in the
> middle of the day, yet the store never dismounted and the users were
> sending
> and receiving the whole day until the offline defrag.
>
> Weird.
>
> Thanks,
>
> RS
>
> "Ed Crowley [MVP]" wrote:
>
>> Remember that retained deleted items (the dumpster) gets deleted after
>> the
>> end of the deleted item retention period. If yours is set to seven days,
>> and your heavy user deleted a bunch of stuff, the store wouldn't show it
>> as
>> free space for seven days.
>> --
>> Ed Crowley
>> MVP - Exchange
>> "Protecting the world from PSTs and brick backups!"
>>
>> "R Stovall" <richard-at-@xxxxxxxxxxxxxxxxx> wrote in message
>> news:A5CB3001-8510-4A4A-A402-FF469825C76B@xxxxxxxxxxxxxxxx
>> > Some background...
>> >
>> > I have a client running SBS 2003. SBS is not SP1 yet, but Exchange was
>> > updated to SP1 before the server went into production.
>> >
>> > Last month the client maxed out the Exchange private database and the
>> > store
>> > dismounted, as expected. We recovered about 4 gigabytes of free space
>> > and
>> > they've been running smoothly since. Yesterday afternoon the 445
>> > events
>> > started and the client called me to let me know there were problems.
>> >
>> > I did an offline defragmentation and was again able to recover about 4
>> > gigabytes of space. The combined size of the database files was right
>> > at
>> > 12
>> > GB.
>> >
>> > I changed the deleted items retention settings, remounted the store,
>> > started
>> > the maintenance process and recovered an additional 93 MB of free space
>> > according to the resulting event 1221 log entry.
>> >
>> > Looking back at the logs, the previous event 1221 entry for the mailbox
>> > store was yesterday morning indicated that 4.3 gigabytes of space was
>> > free.
>> > It is not conceivable that 4.3 gigs of space were consumed in the
>> > following
>> > 12 hours, which is right about when the 445 events started showing up.
>> > Oddly, the store never dismounted in the 9 hours between the time the
>> > errors
>> > started and the client called me.
>> >
>> > My questions are:
>> >
>> > 1) Why didn't the store dismount if the database was indeed maxed out?
>> > 2) The database had 4340 MB of free space when the day started, and
>> > shrank
>> > by roughly the same amount after offline defragmentation. Is it
>> > possible
>> > that it simply filled up with data that would, under normal
>> > circumstances,
>> > have been eliminated when the nightly maintenance process ran?
>> > 3) If the above is what happened, does this represent a sort of 'false
>> > limit' in which the database is too big even when it isn't? Is there a
>> > way
>> > to prevent crossing this threshold in the future?
>> >
>> > Thanks for any thoughts. This client produces a high volume email
>> > (several
>> > thousand messages per day to many more thousands of recipients) and I'd
>> > really like to find out exactly what happened so we can watch out for
>> > it
>> > in
>> > the future.
>> >
>> > RS
>> >
>>
>>
>>


.

Quantcast