Link to home
Start Free TrialLog in
Avatar of broadway69
broadway69

asked on

SBS 2003 Database Consolidation

I have a client whose Exchange 2003 database is growing out of control.  They are currently at about 50 GB, which is a lot considering there are only 5 people in the office.  The issue is they are architects and need to email large files back and forth to clients.  They always copy other workers in the office and due to the letigious nature of the business they must keep ALL emails.  As you can imagine with multiple copies of the same large files floating around things got out of control.  

We've since implimented an archiving system which requires all users to move project related emails into public folders.  Once the projects are done the specific public folder is archived and removed from Exchange all together.

The issue is the scheduled online defrag of the database does not remove any whitespace, therefore despite massive reductions in mailbox size the overall database size remains the same.  I have tried an offline defrag of the private databases, but despite doing this the size of the database stayed the same.  Below is the command prompt I used:

c:\program files\exchsrvr\bin\eseutil /d d:\exchsrvr\mdbdata\priv1.edb /b c:\priv1_bak.edb

It created the backup on c: which was the original size and the "defragged" database is int he original location the exact same size.  With help from a guru I found event ID 1221 and discovered the whitespace was only 2 MB.  We adjusted the maintenance period and set the deleted mailbox save period to 0.  After waiting a couple hours event ID 1221 reported 17 GB free.  I ran the same command line again but got this error.


C:\Program Files\Exchsrvr\bin>eseutil /d d:\exchsrvr\mdbdata\priv1.edb /b c:\pri
v1.bak

Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode...
            Database: d:\exchsrvr\mdbdata\priv1.edb
      Streaming File: d:\exchsrvr\mdbdata\priv1.STM
      Temp. Database: TEMPDFRG8656.EDB
Temp. Streaming File: TEMPDFRG8656.STM

                  Defragmentation Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ........................................



Operation terminated with error -1014 (JET_errOutOfBuffers, Out of database page
 buffers) after 15210.828 seconds.




C:\Program Files\Exchsrvr\bin>
Avatar of Glen Knight
Glen Knight
Flag of United Kingdom of Great Britain and Northern Ireland image

How much disk space is there on the server, there should be around 130% of the size of the EDB file available, if there isn't move the file to another server and run eseutil on that server.

Also try increasing the size of the page file?
Avatar of absremote
absremote

Lower your deletion retention to 0 days before online maintenance.  Then the event will show you the space you know should be there.  demazter is correct if you dont have enough space move the edb somewhere else and run the offline defrag.
Already covered that in a different question absremote.
Avatar of broadway69

ASKER

Thanks guys, I did lower the retention rate before.  I use Tree File and discovered the temp edb and stm files were never deleted eating up about 30 GB of space?  Is that normal?  I did use the /b switch again and when i examine it appears there wasn't enough space for the backup on the C: drive because these temp files were not removed (two sets from me running eseutil two night in a row).  Now that I think I found the problem I'm concerned why those temp files were not deleted.
It doesnt always delete them, i have seen this a lot.
Can often be because the process doesnt complete due to some reason or another.

Its always good to check.

At least you know what the problem is, glad i was able to help you again.

eseutil does not automatically delete the files it was creating the new database on when it crashes.

If they are the temporary files and NOT the priv1/pub1 .edb/.stm files, you can safely delete them. If Exchange is running, you cannot delete the database files anyway, as they will have file locks on them preventing them being deleted.

You said earlier in your question:

>>  As you can imagine with multiple copies of the same large files floating around things got out of control.  

Exchange 2003 uses Single Instance Storage (SIS) for all emails - including attachments - so if messages are copied in to co-workers, only one copy of that message is ever stored in the database.

It is a good idea to not use Exchange for long-term storage, so I like the sound of you archiving the data out of Exchange once you're done. Exchange is a collaboration tool, not a long-term storage tool -- many people seem to forget that!

-Matt
I attached a gif with all the temp*.* files I found in the c:\program files\exchsrvr\bin folder.  I think I know the answer to my questions (whether or not I can just delete them) but wanted to be 100% before I did!

Thanks
bin-folder.GIF
They can be removed they are simply the temporary defrag files.
If you are not sure then move them somewhere else that way if something goes wrong you can move them back but I doubt it will.

Besides if they are in use you won't be able to move/delete them.
ASKER CERTIFIED SOLUTION
Avatar of Glen Knight
Glen Knight
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks guys