I've "noticed" that when we ask the question of what DB size to aim for -- if it's in the context of disaster recovery planning, we don't really get an answer - just more formulas to determine what size, based on recovery point/recovery time objectives. I don't really have a problem with that, because it's a customer decision.
When we've been in a situation where large stores have become corrupted, an the ISINTEG+DEFRAG combo is taking a while (for example, on 8 stores ranging in size from 10GB to 120GB), THEN we're told that the larger databases (large being anywhere from 50GB to 100GB) is too large to deal with, and that we should stick to smaller sizes. Again - these were usually for disaster situations and it was the recovery times that were the real goal. But even after a disaster, we've been advised multiple times be PSS to get smaller databases. I think there is probably a gap in the best practices suggestion, because of the type of Exchange deployments that have changed in the past few years, at least that I've seen -- larger environments have been moving away from smaller Exchange servers at each site to centralized, Enterprise-edition servers...and the Exchange adoptions in the higher-education space (me) have tended to go in the same direction, since they're single-site or one large LAN anyway. With mailbox stores no longer spread out like they were, anyone with growth rates or other causes for stores above 50GB may start to see issues because of it. But disaster recovery objectives usually become the reason to aim for smaller DBs, so I don't think performance implications are ever really addressed... --James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Crowley [MVP] Sent: Tuesday, March 20, 2007 12:49 PM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. In what form have you "noticed" this PSS behavior? I've never heard of it. Again, the reason people have usually suggested 50GB is because of the time it takes to restore a database larger than that, not because of corruption. I'm not saying that large stores are in any way more desirable than small stores, but I want to be sure that the reasons are clearly understood. Ed Crowley MCSE+Internet MVP Time Magazine's Person of the Year! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wells, James Arthur Sent: Tuesday, March 20, 2007 5:47 AM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. I've noticed that extremely large DBs get us into gray areas that Microsoft PSS really isn't comfortable supporting. The recommendation I hear from engineering folks and field engineers is usually no more than 50GB. Beyond that, there are limitations for all sorts of maintenance activities. We had a corruption on 8 stores, some of which were over 100GB, and because of some miscommunication about tape-based restore SLAs, had to resort to an ISINTEG on a DB for recovery on a few, until we got full restores completed. It wasn't pretty. Based on the performance issues we've seen on Exchange 2003 with huge stores -- and more importantly -- the need to keep our options open in case of a disaster recovery, we're targeting about 40GB once we add some storage groups and finish an email archive process. Exchange 2007 may have some incremental architecture changes, but given that the number of stores available per server has increased dramatically, I'd say smaller stores are still better... --James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pfefferkorn, Pete (pfeffepe) Sent: Tuesday, March 20, 2007 7:21 AM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. Who said we were experiencing corruption problems? We have been running Exchange from since 4.0 and during that time we had one corruption which was hardware related. Since then we have not experience any other corruptions, although we did see the DB's abnormally growing and moving the mailboxes to a different store resolved that issue. As to the question of who cares what everyone else is doing? I do for one. Finding out what other administrators and sites have deployed and their experiences helps me formulate a plan. Forming SLA's is good policy but part of the evaluation needs to include getting real life experiences from this list. I remember when we first deployed Exchange 4.0 and the MS whitepapers toted that they could put something like 40,000 per server. Could you do it? Probably but I wouldn't recommend it. Pete Pfefferkorn University of Cincinnati Information Technology Services Senior Systems Analyst/Mail Administrator Phone: (513) 556-9076 Fax: (513) 556-2042 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Crowley [MVP] Sent: Friday, March 16, 2007 5:59 PM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. Who cares what everyone else does? What YOU should do is size your stores to meet your SLAs, while applying business judgment to your SLAs to ensure that they make business sense. I would never recommend using ISINTEG or ESEUTIL in the way you describe as a part of a disaster recovery procedure. Instead, I would implement a dial-tone procedure and use those tools to recover any e-mail that might not be recovered by other means after you've used the best-effort recovery. If you're experiencing corruption, then you might want to reevaluate your choice of hardware vendor. Ed Crowley MCSE+Internet MVP Time Magazine's Person of the Year! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pfefferkorn, Pete (pfeffepe) Sent: Friday, March 16, 2007 1:34 PM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. We use Tivoli for restoration so the time to restore is minimal. But if a database gets corrupt and the size is substantial the time to run the check/repair can be a day or more where as a restore can be done within an hour. If it were not for the time it takes to run ISINTEG for a corrupt database, then I would feel comfortable expanding the DB's to 100 or 200 gig a piece. Do other system admins allow for larger DB's 100 or 200 gig and just take the chance that there will never be a corruption or use backups in the advent that it does get nailed by a hardware failure or whatever. Pete Pfefferkorn University of Cincinnati Information Technology Services Senior Systems Analyst/Mail Administrator Phone: (513) 556-9076 Fax: (513) 556-2042 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Crowley [MVP] Sent: Friday, March 16, 2007 12:32 PM To: Exchange Discussions Subject: RE: Exchange 2007 and database size/rebuild questions. The recommendation to keep database sizes "small" has nothing to do with larger databases being susceptible to failure, but to allow administrators to be able to comply with their time-to-restore SLAs. Having more smaller databases means that the time to restore one if it fails is shorter. Larger databases are no more likely to fail, especially since database failure is nearly always related to hardware failures. This really doesn't change in Exchange 2007. In fact, since you can now have 50 databases (up from 20) on an Exchange 2007 server, you can go even smaller if you want. Ed Crowley MCSE+Internet MVP Time Magazine's Person of the Year! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pfefferkorn, Pete (pfeffepe) Sent: Wednesday, March 14, 2007 6:38 AM To: Exchange Discussions Subject: Exchange 2007 and database size/rebuild questions. I have a question about Exchange 2007 that maybe someone can answer for me. We are starting to look into Exchange 2007. We currently have our faculty/staff deployed on Exchange which accounts for about 8,000 mailboxes on 4 backend servers with about 9 stores total size of 433 gig with each store no larger than 50 gig or so. Users have a total of 100 meg per mailbox. Our students are located on a proprietary mail system which can accommodate the 75,000 users with 50 meg stores. One of the reasons we did not deploy students on Exchange, was the scalability issue and the number of servers and stores that would have to be deployed to accommodate the number of users we are talking about. The other issue was restriction on the size of the DB's in the advent a corruption occurs and the time to run a repair on a database. In 2007 is there still the underlying recommendation to keep DB sizes to a smaller size in case a corruption occurs? Anyone know if the ISINTEG has been revamped at all to get better throughput? Currently we try and keep the size of a DB to about 50 gig. I recall that the ISINTEG is jet oriented and could only process about 4gig to 6 gig per hour. Pete Pfefferkorn University of Cincinnati Information Technology Services Senior Systems Analyst/Mail Administrator Phone: (513) 556-9076 Fax: (513) 556-2042 Email: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
