Exchange 2010 DB and Logs

Paul,

Thanks for sharing great points.

I think some of these best practices (circular logging and isolation of DB and logs) are rather optimistic. It assumes that HA/DAG will protect from all situations where you would want to play back all or some of your logs.

In general, I still recommend that circular logging is disabled for all configurations. Past logs can come in handy when recovering from logical corruption that may have affected multiple copies in the DAG.

I also still recommend that logs and databases be isolated, for few reasons:

1. Performance: It’s much easier to meet the critical write-latency requirements for the transaction logs when the underlying disks are not also servicing database workloads

2. It’s impossible to have set of resources tuned simultaneously for semi-random large block read/write workloads and sequential, small-block, 100% write workloads.

Really, the only time I could be convinced to collocate DB/Logs would be in a JBOD configuration, or very small configuration where a couple extra disks can’t be spared for logs.

--paul

I am working with a Investment and Financial firm that is moving to Exchange 2010 on VBlock from Notes for a 32,000 user deployment. It will be a 3 copy implementation - 2 local and 1 remote.

As this is going to be virtualized in VMware, we were running into the 255 VMware LUN limit. Microsoft was asked to come in and assist to work around this and recommended colocating Logs and DB onto the same drive/LUN. Here is the link that they provided to justify that architecture.

http://technet.microsoft.com/en-us/library/ee832794.aspx#One

Not implemented yet. They are just beginning the build out.

Regards,

Sam Lantto – Sr. Technical Consultant

sam.lantto@emc.com

MOB: (952) 270-7198

OFC: (952) 562-7309

FAX: (952) 828-9509

For Symmetrix arrays we've been advocating sharing data and log on the same spindles for quite a long time.  Depending on the HA requirements, it could be data and log from the same Exchange storage groups/databases or mixing the data and log of separate databases (Log of DB1, Database of DB2.)

For performance, everything goes through cache on the Symmetrix, so regardless of the underlying disk response time, the cache hit of the log write provides the host response time.  The small sequential log writes are also coalesced into fewer larger sequential writes and will have less of an impact on the disk as the front end/host iops number would otherwise indicate.

While the recommendation is to share data and log on the disks themselves, it is still recommended to separate the database and logs onto separate host addressable LUNs.  This way the log writes are not in the same LUN queue as the more bursty database writes (and reads for that matter) which generally have a higher response time.

This is a great question and depending on customer requirements there are lots of right answers.

Thanks for your input..has your customer experience any issues by doing this?

Hi Slantto,

Does this case also applies for the Exchange Server 2013 ?