Hi, recently we migrate 2007 to 2010. in 2010 we create 2 database. one our database full. so that we move some mailboxes from database1 to database2. but database1 disk not increase the size. how to increase the size after move the mailboxes Rgrds, Selva

Moving mailboxes out off a mailbox database does not reduce the external size of the database.You'll only get more free space inside the database. In order to reduce the actual database size, you'll have to take the dismount the database and preform an offline defragmentation. A better idea is to move off all mailboxes to a new database and delete the old one. You can verify how much white space you have gained by looking at event ID 1221. The number is not exact, but gives an idea. See also Mailbox Move http://social.technet.microsoft.com/Forums/en/exchangesvradmin/thread/e7463d29-5890-41d8-82a6-64c0be0e524a There are a lot of good scripts out there: Exchange 2007 / 2010 Database Reporting Script http://unlockpowershell.wordpress.com/2010/06/06/exchange-2007-2010-database-reporting-script/ Show Whitespace with Flashy Visuals http://gsexdev.blogspot.com/2008/07/show-exchange-whitespace-retained-items.html Exchange White Space Script 1221 http://smtp25.blogspot.com/2008/01/exchange-white-space-script-1221_28.htmlMCTS: Messaging | MCSE: S+M

After move the mailbox it will increase the size as user will start using their quota. It does not mean that if you have 500 MB quota given to 10 users then mailbox database size will be 4+ GB immediatly. It will increase as user will start occupying quota space. Jon-Alfred has provide enough link for your reference.Anil

Thanks for your reply. what i am asking is the disk space is 1TB and 1000 Maiboxes. the disk space almost 900GB full. Then i create new database to another 1TB disk and move 500 mailboxes to new database. But the old database disk size not increase(that means 100GB to 500GB).Note: not a database. i'm asking Disk Size. thanking youRgrds, Selva

Quote "But the old database disk size not increase(that means 100GB to 500GB" Are you talking about log generation when you move 500 mailbox into new 1 TB disk ?.Anil

No. i am talking only database diskRgrds, Selva

No, the disk size -- or more precisely the free space on disk -- does not increase automatically. You have moved mailboxes worth 400 GB in size from your old mailbox database to your new database on another disk. The only thing you achieve by this in terms of your old database is that you free up about 400 GB of white space inside the old database. The database itself is not reduced in size. Now you have two options: (1) do an offline defragmentation of the old database or (2) move all mailboxes from the old database to a new one on a separate disk in your case and delete the old database. Then recreate a new database on the old disk and move for instance 400 GB of mailboxes back. In general option 2 is the recommended approach, as you will have to take the database offline with option 1, and the defragmentation can take a long time, depending on your disk subsystem you might be able to defrag something between 10 and 20 GB per hour. With option 2 there is only a short downtime while you move a mailbox. In an online mailbox move, end users can access their e-mail accounts during the move. Users are only locked out of their accounts for a brief time at the end of the process, when the final synchronization occurs. Now, you might run into some problems with each approach. For instance, with option 1 you must use another disk for the actual defragmentation, since you don't have enough free space on the disk hosting your old database. With option 2, you might have to move off some system mailboxes which require some special procedures. Please tell us which option you chose, and we'll guide you through the procedures. For option 1 see the second link, but it a good idea to understand how the ESE work, so go through both articles: Eseutil - Part 1: Database Technologies http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/eseutil-part1.html Eseutil - Part 2: Eseutil Switches http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/eseutil-part2.html MCTS: Messaging | MCSE: S+M

As you databse size is big, offlline defrag will take long time to complete and you have to dismount database till it does not complete. If you can manage new Disk/LUN then create one new database and then move your mailbox into it and delete exisitng DB, Later you can move back them to original place by ceating new DB. This whole jubbling allow you to remove lots of unwanted space from EDB. We do this in our organization for cleaning white space and never seen any issue.Anil

Hi; Don't normally post online, so at risk of sounding extemely stupid, have a question relative to whitespace reclamation. How different is this from the backup/truncate operations in a sql database? repost: I will answer my own quesiton: relational vs. btree. http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/eseutil-part2.html So http://technet.microsoft.com/en-us/library/bb125040.aspx reference to online 24x7 defrag does not take care of recovering whitespace? Still would like to see some other mechanism besides sending data around in circles for resolving reclaiming space on a database.

Hi; Don't normally post online, so at risk of sounding extemely stupid, have a question relative to whitespace reclamation. How different is this from the backup/truncate operations in a sql database? So http://technet.microsoft.com/en-us/library/bb125040.aspx reference to online 24x7 defrag does not take care of recovering whitespace? You would think that this would be a pretty major chunk of functionality that is an "expected' functionality of db maintenance. Are we wrong to expect that if we pull 3,000 mailboxes out of a DB, there would be a corresponding decrease in the size of the DB? At any rate, from what I am reading here, it sounds like manual operations required to recover space. Otherwise, should be part of design recommendations to have at least one "swap" message store available for moving mailboxes around in circles manually in order to reclaim space. Reason, from where i stand, is that in a small college environment, we are typically faced with a turn-over in accounts depending on semester, something like 4000-5000 email accounts. compared to exchange 2003, DAG environment requires more storage space (plus loss of single instance message store; think of this in an environment where a single message sent to all students with 20 MB attachment is multipled instead of divided; ouch is all I can say), but 24x7 automated management sounded like some management would be handled by system instead of having to come in on Sunday at O'dark thirty to run esutils. All I can say is, expected behavior (maybe irrational to expect) is that it would be possible to perform the same task with the exchange db as we do with the sql db; backup and shrink, or better yet, that the db maintenance task would be automated for us. Regardless what is said about using cheaper disk on message store, there really is no such thing as cheap storage in a server environment; any type of storage has to be multiplied by at least 4; either dag redundancy, raid redundancy, or both plus at least two backup copies of the data. In reality, I don't see how DAG is saving any money or management overhead vs. what I saw in exchange 2003 cluster environment. In the scenario described as "the method" to use to manage whitespce, you will need to have (if you want to avoid the risk of losing a db): 1. original storage, either raid or a DAG with 3 instances. 2. Destination (again, either raid or DAG with 3 instances.) 3. A complete backup of the db before you do your move) (I am not quite sure what happens if there were some type of failure (power outage, etc.) during the move. What would be the state of source db; at what point is there a commit on the operation? Wouldn't it make more sense just to reclaim the white space? Thanks for input.