我们希望逐步摆脱对服务器内部驱动器的依赖，开始从 iSCSI LUN 运行（出于各种无趣的原因）。该计划的前几周主要涉及将 Exchange LCR 运行到 iSCSI 驱动器并观察其运行情况以测试连接的稳定性。几周来，复制过程一直顺利，没有出现任何错误，因此我们已准备好进行切换，也就是说，我们希望开始从 iSCSI 驱动器运行主动数据库，并将其复制到内部驱动器上的被动数据库。
长话短说，我一直在阅读——或者说，试图阅读——这背后的过程。不幸的是，所有可用的文档似乎都假设您正在从故障中恢复。这是可以理解的，我明白这是该功能的重点，但它让我对这种情况有点偏执。我想确保我不会在无灾难的情况下使用灾难响应步骤来制造灾难。
我发现最简洁的步骤是http://www.exchangeinbox.com/article.aspx?i=138在“恢复本地连续复制数据库”部分下，天哪，他们让它看起来很简单！？屏幕截图中的“已用时间：0:03”让我充满希望，我们可以在下午 5 点完成这件事，然后在 5:15 之前出门。我是不是太天真了？
因此，从本质上讲，我想确认的是，通过遵循这个过程：
- 我们只是改变了交换的配置，以便它在新位置寻找活动数据库（这与将整个数据库从一个地方复制到另一个地方或类似耗时的事情相反）
- 我们应该在很短的时间内知道我们是否成功（也就是说，我不必整夜留下一些长时间运行的命令，然后祈祷邮件在早上能收到）
答案1
我自己来回答这个问题 - 我们昨晚做了这件事，确实花了 2 分钟 - 轻而易举。搜索索引器必须运行完全爬行 - 这是我完全没有预料到的 - 这导致磁盘读取/秒在一段时间内达到最大值，但虽然这会减慢本地交付速度，但情况并不太严重（我从我的 Exchange 帐户发送给自己的消息在 4 分钟内到达，从我的 gmail 到 Exchange 的消息仍在不到 10 秒内到达）。总而言之，这是一个轻松的过程。