Exchange error 629

[Maximum Error]

So after deleting a large number of mailboxes during a tidy out of our AD we are seeing error 629 pop up twice a day with the details below. 

 

Information Store (796) Mailbox Database (X): Database 'path to DB': While attempting to move to the next or previous node in a B-Tree, the database engine skipped over 30299 non-visible nodes in 117 pages. In addition, since this message was last reported 7 hours ago, 0 other incidents of excessive non-visible nodes were encountered (a total of 0 nodes in 0 pages were skipped) during navigation in this B-Tree. It is likely that these non-visible nodes are nodes which have been marked for deletion but which are yet to be purged. The database may benefit from widening the online maintenance window during off-peak hours in order to purge such nodes and reclaim their space. If this message persists, offline defragmentation may be run to remove all nodes which have been marked for deletion but have yet to be purged from the database. 
Name: MSysObjects 
Owning Table: MSysObjects 
ObjectId: 2 
PgnoRoot: 4 
Type: 2 
Unversioned Deletes: 30299 
Uncommitted Deletes: 0 
Committed Deletes: 0 
Non-Visible Inserts: 0 

I have obviously tried increasing our maintenance window to over 48 hours over Friday, Saturday and Sunday but this hasn't fixed it. The only two options I can see now are:

1. Take the database offline and perform an offline defrag. Any ideas how long this will take on a 250GB database? 
2. Migrate everyone (in stages) to a new database.

Before I take either one of these options I wanted to check here and see if anyone has come across this error before? 

 

Thanks guys.

 

[sc302 Veteran]

Yes you will need to run a defrag or a repair on the db to get things back in order.  eseutil will defrag 9 GB an hour so around 28 hours.  You are honestly better off migrating to a new database if you want it to be faster.

[Maximum Error]

Yes you will need to run a defrag or a repair on the db to get things back in order.  eseutil will defrag 9 GB an hour so around 28 hours.  You are honestly better off migrating to a new database if you want it to be faster.

 

Ouch....... 9GB an hour would be a totally unacceptable level of downtime. I've never ran an offline defrag so didn't know. I will definitely be going down the migration route. Do you know any more detail on what causes this to happen? My guess is that when it came to purge the 200+ mailboxes we deleted (a tidy up had not been done for years) it just couldn't cope with the massive amount of data to be purged. 

[sc302 Veteran]

If I knew why databases became corrupt, I would have a better fix than running the repair tool...corruption probably wouldn't happen to begin with.