No. When all stores are backed up the logs will be flushed. Ed Crowley MCITP MCSE+I MCSE+M MCTS MVP "There are seldom good technological solutions to behavioral problems."
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Wells Sent: Tuesday, July 08, 2008 10:32 AM To: Exchange Discussions Subject: Re: Storage Group and Database Best Practice? No - in fact, that should be preferred, since it will reduce your backup recovery time by having smaller SGs/smaller databases. Especially if you can get to doing full backups more often. You should be fine with multiple storage groups' transaction logs on a single spindle...but if you can size it, you really need to split those disks up and have different RAID groups for transaction logs vs. database. There are more concerns on disk I/O on the DB spindles if you combine multiple databases onto one physical volume, but it sounds like you are stuck with the disks that you have... Ed -- on the backup comment....he'll need to backup the entire SG with one command in order to flush transaction logs...correct? If they're all individual backups (one per store), then it's not possible to commit the logs at the end... --James On Tue, Jul 8, 2008 at 9:26 AM, Paul Hutchings <[EMAIL PROTECTED]> wrote: > FWIW when I ran all the numbers before, we're small enough that > virtualizing shouldn't be an issue, and I'd assumed that there's no > significant performance overhead from running several storage groups > over one? > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Egan, William > Sent: 08 July 2008 15:23 > To: Exchange Discussions > Subject: RE: Storage Group and Database Best Practice? > > In an ideal world, this would involve separate tran log volumes for > each storage group, with the storage group being the tran log > boundary, correct? If so, this gets expensive from a disk standpoint > (in terms of # of disks required, not necessarily dollar cost.) What > are the real-world consequences of sharing a single RAID1 or RAID10 > volume for tran logs from multiple storage groups? Is it fine since > its all still sequential writes from the I/O profile standpoint? > > Thanks, > bill > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ed > Crowley > Sent: Tuesday, July 08, 2008 10:10 AM > To: Exchange Discussions > Subject: RE: Storage Group and Database Best Practice? > > Creating several storage groups is a good idea. When you set up your > backup you can back up each storage group separately. I recommend > that you back up individual stores in each storage group serially but > separately so each has its own backup file. This will make > restoration easier if you just need to restore one, and will keep the > backup file sizes down. You can do all this with a set of batch > files. > > Ed Crowley MCITP MCSE+I MCSE+M MCTS MVP "There are seldom good > technological solutions to behavioral problems." > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Paul Hutchings > Sent: Tuesday, July 08, 2008 8:41 AM > To: Exchange Discussions > Subject: Storage Group and Database Best Practice? > > I have six new 15k SAS disks sat waiting to go in our SAN to form the > basis of a new Exchange Server to replace our existing, full one. > > It's Exchange 2003 SP2 Enterprise. > > The current server has around 150gb of private store, all in a single > database. Suffice to say backups take a long time. > > With the new server I'm looking at using multiple storage groups and > databases so I can (hopefully) backup several stores concurrently. > > We also intend to impose mailbox and message limits on the new server > and I'm unsure of the best way to do this. We would like to have > three tiers/bands for mailbox sizes, but Exchange seems to offer > either store level quotas, or mailbox level, not group level. > > I'd appreciate any input on how people would approach this. Best > practise from what I read seems to be that if you want three stores > you would create three storage groups with one database each vs. one > storage group with three databases? > > Thanks in advance, > Paul > > > -- > MIRA Ltd > > Watling Street, Nuneaton, Warwickshire, CV10 0TU, England. > > Registered in England and Wales No. 402570 VAT Registration GB 114 > 5409 96 > > The contents of this e-mail are confidential and are solely for the use of the intended recipient. > If you receive this e-mail in error, please delete it and notify us either by e-mail, telephone or fax. > You should not copy, forward or otherwise disclose the content of the e-mail as this is prohibited. > > > > _________________________________________________________________ > 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] m > 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.
