Hi there,

A logical partion for logs and databases is technically OK. However not
really in this case as they are on the same physical RAID set. It depends if
you find this acceptable or not - many probably wouldn't.

For example, having both on logical partitions but each on a different set
of disks wouldn't be so much of a problem.

Example

RAID10 4 disk set - 2 logical partitions for SG1 and SG2 logs
RAID10 4 disk set - 2 logical partitions for SG1 database and SG2 database.

Following on from that you can still see there's an element of risk,
compared to having dedicated 'disks' for all.

You need to sum up what is acceptable to your client/your business, and
ensure you can recover in whatever agreed SLA is in place.

Oliver

It means the second option you listed. But, depending on your budget and
level of tolerance, you can do it as option 1, too.

Deji

There are really two reasons for seperating the logs and databases onto
seperate spindles:

1.  It provides an extra level of recoverability.  If you lose the partition
where the database resides then, after repairing the hardware you an restore
from backup and roll the logs forward.  Instead of losing up to 24 hours of
data (assumes backup once a day), you would potentially be up to the minute.

2.  Writes to the logs are the single most user visible aspect of Exchange
IO.  If  multiple LUNs share the same physical spindles, then IO against one
LUN can negatively impact the performance of another.  This is called
comingling.  Very few storage systems out there provide a mechinism to
mitigate comingling effects.

If you create two logical LUNs on the same spindles, you lose a bit on your
RPO, and you potentially expose yourself to comingling issues.  It can be
done; it's just not a best practice.