sm

We're getting ready to setup EX2003 on a new box. Currently we have 1
mailbox database and 1 public store database. To help improve recovery
speed the mailbox database is going to be broken into 3 databases. Here's
the question... Is it better to put each DB into it's own Storage Group
(thus using all 4 SG's)? It seems like more overhead, but I was thinking
that in the event of a restore it might be nice to have seperate transaction
logs. What's common practice?

Thanks in advance.

-SM

jan englund

Hi
If you are going to be running on a Enterprise licens and the server is well
eqipped hardwarewise i would actually dived the users into as many databases
as possible (20) (19 if you need 1 for the PF).
This would give you the best restore time overall.
And yes an increase of storagegroups will add more load on the server so
only do this if you have a low baseline.
But if you compare this with what you suggest i think you will find this to
be a better solution restorewise.


--
Best Regards
Jan Englund
Capgemini Sweden
MCSA 2000/2003, MCSE NT4/2000/2003
MCSA 2000/2003:Messaging MCSE2000/2003:Messaging
http://www.se.capgemini.com

sm

Jan, thanks for the feedback. Sorry I didn't mention the database size
before, it's about ~120GB. Restore times would be quicker, but I think
having 20 DB's would be overkill for our organization (more chance for one
of them to fail, plus alot of overhead and very little single instance
storage). I'm thinking maybe I'll use 2 SG's with something like the
following?

SG1
*Pub Folder ~35GB
*Exec users ~ 10GB

SG2
*A-G ~30GB
*H-N ~ 30GB
*O-Z -30GB

Thanks again,
SM

al mulnick

In that case, you won't really meet your requirements then, will you?
I wouldn't have any qualms about putting the user DB's in their own SG as
much as possible. There is overhead in terms of memory and log files IOPS to
work out, but I think it's worth it in terms of recovery/backup scenarios.
You can backup/restore in parallel at the SG level, not the DB level. That
can significantly impact your backup and recovery *time*. You need the
throughput either way, so don't forget to plan for it.

Al