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.
