Priv.edb is 70 GB

[ConfusedByExchange]

I am running Exchnage 5.5 SP4. Last Thurday night my information store size went from 40 Gb to 71 Gb (stopped when it ran out of disk space). According to my brick level backup (Veritas) the total size of my mailboxes is 18 GB. I cannot account for the extra 50 GB of storage
being taken up by the priv.edb file. I ran an eseutil defrag and an eseutil integrity check with no major results. I have verified that the brick-level backup is backing up all the mailboxes including the hidden ones, so the 18 GB seems to be a good estimate of the actual size of the mailboxes. According to the list of mailbox resources under Exchange admin none of them is very big, like 30 GB so I am doubting I have a mail loop.

Anyone know how I can shrink my store back to the appropriate size? Any ideas why this happened?

 

[zbnet]

How much whitespace does the priv have (check for event 1221 written overnight by the online maintenance).

 

[ConfusedByExchange]

I checked my eventlog and the eventid 1221 message I have 3.5 GB of whitespace.

 

[zbnet]

Then you have approx 67GB of 'mail' in your store, regardless of what the total of each individual mailbox comes to.

Obviously we would never expect the total amount of space used by the mail to be greater than the sum of the mailboxes - even if each mailbox has totally different content (unusual) then the sum of these should equal the total amount of mail stored. In fact, with single instance storage playing its part, we'd expect the total mail stored to be somewhat less than the sum of the mailboxes - the difference between these two numbers is known as the single instance ratio (perfmon has a counter that will reveal this for you). More than 1 means people are sharing email content. Less than one means you have some mail items in your store without pointers. What are they doing there? Ligitimately they might be deleted items that the store is retaining because of deleted item retention (the higher you set this, the more mail is stored).

Alternatively, the mail could be there because your store has got corruption, when the internal table pointers have become screwed. This is far more difficult to deal with.

 

[ConfusedByExchange]

I ran an integrity check that didn't really clear up anything. I can't see it being a single instance issue because if I had that issue I would see the totals reflected in the brick-level backups

 

[zbnet]

So if your brick backup says all the user email equals 18GB, but your store is 67GB full, then you do have corruption - some of the mail is being retained, even though it doesn't have pointers from real mailboxes anymore - corruption in the pointer tables is most likely.

A 'store refresh' would do the trick. You take a backup of every mailbox (your brick-level backup would do, or via ExMerge to PST files), then you stop the IS, delete the priv.edb(!), then you start the IS again. It makes a new, empty, clean priv.edb - then you put all your content back again.

It breaks single instance storage for all mail currently in the db, but then that's hardly going to be an issue for you if the current db is circa 70GB. It also takes some (down)time...

 

[ConfusedByExchange]

Good suggestions. It might come to this. Thank you. I will let you know how it works out.

 

[ConfusedByExchange]

Figured I try this site again due to the good info that is being posted. I would like to update my problem of the information store that grew too big.

What I have done is create a revovery server and restored the IS to that server. Server comes up fine with the 73gb IS. What I have done is deleted all the mailboxes exept the Administrator, mailer and Postmaster mailboxes. I have gone in and cleaned these. So what I am left with is an IS store that has 3 mailboxes with no mail at all in them. I run a defrag and the 71 GB drops down to 43 GB which confirms that by mailboxes are only taking up 28 GB. The other 43 GB cannot be explained. Anyone know what could be using the 43 GB of space? I know I can import the mailboxes into a fresh IS but I am concerned if I cannot explain the IS growth it could happen again.