Introduction
Note: for more comprehensive coverage of Exchange 2007 storage please see this blog post:
http://msexchangeteam.com/archive/2007/01/15/432199.aspx
This is the second of a four...
Updated Jul 01, 2019
Version 2.0
Blog Post
Wolf70:
You are correct, it is a pull. Here is my attempt to describe it:
The transaction log is closed and then pulled by the passive using a copy mechanism such as \servershare. After they are 'pulled' to the target/passive LUN eseutil is run to ensure that it is not corrupt, for the right database, and to check if it is in sequence. If it passes this test, the log file is moved from this inspector directory to the configured log directory. Once inspected the logs are replayed into the target database assuming the storage group is not blocked.
Josh Maher:
I'll investigate. I am not aware of a feature in the product that will do this.
Lee:
In my next blog I talk a little bit about capacity, and performance on the Hub server. Geographically dispersed solutions are being testing, and best practices are being worked on now.
Elf:
Very good question. In the next blog I spend a bit of time on this and it should be completed very soon. The short answer is yes, you _can_ place more than 1 storage group's databases on a single LUN (and logs as well, but be sure to separate log/db LUNs at both logical and physical level). I will try to make pro and con arguments for this strategy. It is particularly appealing if you group a couple of storage groups into a 'backup set' and place them on the same LUN. There are many cases where the restoration of a database with this strategy will impact other databases performance, and with a VSS clone restore for example, it will cause downtime during log replay if you restore the LUN which houses other databases. Be patient, more details are coming soon.
Thank you,
Robert Quimbey
You are correct, it is a pull. Here is my attempt to describe it:
The transaction log is closed and then pulled by the passive using a copy mechanism such as \servershare. After they are 'pulled' to the target/passive LUN eseutil is run to ensure that it is not corrupt, for the right database, and to check if it is in sequence. If it passes this test, the log file is moved from this inspector directory to the configured log directory. Once inspected the logs are replayed into the target database assuming the storage group is not blocked.
Josh Maher:
I'll investigate. I am not aware of a feature in the product that will do this.
Lee:
In my next blog I talk a little bit about capacity, and performance on the Hub server. Geographically dispersed solutions are being testing, and best practices are being worked on now.
Elf:
Very good question. In the next blog I spend a bit of time on this and it should be completed very soon. The short answer is yes, you _can_ place more than 1 storage group's databases on a single LUN (and logs as well, but be sure to separate log/db LUNs at both logical and physical level). I will try to make pro and con arguments for this strategy. It is particularly appealing if you group a couple of storage groups into a 'backup set' and place them on the same LUN. There are many cases where the restoration of a database with this strategy will impact other databases performance, and with a VSS clone restore for example, it will cause downtime during log replay if you restore the LUN which houses other databases. Be patient, more details are coming soon.
Thank you,
Robert Quimbey