I seem to think it was about 8GB/hour last time I ran it - this was on a 70GB DB on a Dell PowerEdge 1650 (old).
From: Jim Majorowicz [mailto:jmajorow...@gmail.com] Sent: Friday, December 19, 2008 11:25 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle The last time I ran a ESEUTIL /G then an ESEUTIL /D, I seem to remember it being a 3 hour process against a 16GB db (this was prior to SP2). Anyone care to guess how long I should expect this little gem to run? From: Michael Ross [mailto:mr...@itwif.com] Sent: Friday, December 19, 2008 10:18 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle Eseutil never removes data from the store.. if you run it with a /d or /g, it doesn't remove emails, or calendar data, or mailboxes for example Then again, if you run it and lose data, the database was in poor shape anyway and that needed to be done to insure you didn't have another crash later. You could always restore to a RSG, and exmerge any missing data out of there to a PST and exmerge it back into the live database if need be. Eseutil is your friend, never be afraid to use it with the proper switches. Always do a /g first and if its consistant, do a /d to defrag it. A defrag will never hurt the database. (to be honest, and not to insult anyone, that's 12 years of Exchange experience coming out of my brain) Ive never, ever, lost data doing a defrag, even back to the days of 5.5 From: Erik Goldoff [mailto:egold...@gmail.com] Sent: Friday, December 19, 2008 11:16 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle yeah, but IMNSHO, I'd try to image the drive first to at least preserve current state for multiple troubleshooting efforts... sometimes, as we all know, eseutil is like removing cancer, you often find that you removed wanted material along with the mess Erik Goldoff IT Consultant Systems, Networks, & Security ________________________________ From: Michael Ross [mailto:mr...@itwif.com] Sent: Friday, December 19, 2008 12:10 PM To: NT System Admin Issues Subject: RE: Exchange Puzzle Yes it will . id run eseutil and clean up the white space in the db.. I know that's not a popular statement to make, but it would at least make the database contiguous and consistent to say the least. From: Erik Goldoff [mailto:egold...@gmail.com] Sent: Friday, December 19, 2008 10:37 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle Hmmmm, not an SBS expert (actually not even a fan) but does that version of Exchange get rid of the 16gb store limit that Exchange Enterprise does ? Erik Goldoff IT Consultant Systems, Networks, & Security ________________________________ From: Jim Majorowicz [mailto:jmajorow...@gmail.com] Sent: Friday, December 19, 2008 11:11 AM To: NT System Admin Issues Subject: Exchange Puzzle I've got a client (SBS 2003 SP2) that has a fairly large DB for the Private store. I had set the DB Size Limit in GB to 64 GB, but yesterday at 5 AM it spontaneously reverted back to 16GB after failing a defrag and of course dismounted the store. When I checked to make sure it was working properly after changing the setting back I couldn't help but notice some discrepancies in the numbers. The 9690 event that took the DB offline shows the size at 48 GB. At 8 am, when the 1216 and 9685 events that report the failure to mount (done before coffee or even a check of the event logs), the size reported was 53 GB. The 1216 Event after I fixed the DB Size Limit in the registry, still said 53 GB. To really confuse me, the Usage Report (Which is what I use to monitor the size of the store in the first place) shows the total of all mailbox sizes to be 38,623.8 MB, which is about 37.5 GB... In the effort of full disclosure, this server is bane of my existence. It eats SCSI drives for lunch on an almost quarterly basis. It has had a critical failure in the past year that forced me to restore from backup. I've been hesitant to ESEUTIL this store because of the trouble I had getting the damn thing back online after the restore. Still, I'm a little worried. I don't have anything in either the APP or SYS logs that show what the heck happened at 5 AM to change the DB Size Limit, and I'm a little hesitant to blow off a 16 GB gap in reported size differences as simple whitespace. Anybody have any insight, or should I just run the ESEUTIL and hope it cleans up the issue? ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
