如何解决本地连续复制问题
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上一次修改主题： 2007-10-10
本主题介绍如何解决在 LCR 环境中运行 Microsoft Exchange Server 2007 时可能遇到的问题。本主题中介绍的过程可解决下列问题：
Get-StorageGroupCopyStatus cmdlet 报告数据库已失败且未被设定为种子。
Get-StorageGroupCopyStatus cmdlet 报告数据库已失败。FailedMessage 值将提供有关故障来源的特定信息。
警报、性能计数器或 Get-StorageGroupCopyStatus cmdlet 指示存储组副本的复制或重播队列发生积压。
Get-StorageGroupCopyStatus cmdlet 报告 LastInspectedLogTime 值过时。
设定种子失败。
针对 LCR 的 Restore-StorageGroupCopy cmdlet 报告 Exx.log 不可用。
如果出现以上所列问题之外的其他问题，请查看事件日志以确定其原因以及进行恢复所必须执行的可能操作方法。如果标识了故障的时间，则其他事件日志可以帮助您更好地了解该问题。有关可能有助于解决 LCR 问题的工具的详细信息，请参阅解决高可用性部署问题的工具。
开始之前
若要执行这些过程，必须为您使用的帐户委派 Exchange Server 管理员角色以及目标服务器的本地 Administrators 组。有关管理 Exchange 2007 所需的权限、角色委派以及权利的详细信息，请参阅权限注意事项。
步骤
Get-StorageGroupCopyStatus cmdlet 报告数据库已失败且未被设定为种子
可能的原因 出现配置问题，或者复制副本的基准数据库无效。未在本地计算机上启用存储组也可能会导致此问题。
解决方法 请执行下列操作：
验证该副本的存储配置正确且运行正常。如果发现错误，则可以通过挂起并继续存储组来触发新的副本检查。
验证 LCR 副本的路径配置正确。这可通过在 Exchange 命令行管理程序中使用 Get-StorageGroup cmdlet 来实现。有关使用 Get-StorageGroup cmdlet 查看配置信息的详细信息，请参阅如何查看本地连续复制配置设置。
使用 Update-StorageGroupCopy cmdlet 可以将存储组副本设定为种子。
Get-StorageGroupCopyStatus cmdlet 报告数据库已失败，FailedMessage 值提供有关失败原因的特定信息
可能的原因 导致被动副本被视为已失败的可能原因有多种。FailedMessage 值专门用于标识检测到的问题。
解决方法可以运行 Get-StorageGroupCopyStatus cmdlet 来获取完整的 FailedMessage 值。此字符串用于标识检测到的特定问题。如果所报告的情况是日志损坏或丢失，请尝试找一个具有正确生成编号的未损坏的日志。如果无法找到正确的日志，请使用 Update-StorageGroupCopy cmdlet 重新设定种子。如果邮件指示来源中的日志不可用，请删除来源日志目录中的共享并重新启动该计算机上的 Microsoft Exchange 复制服务。分析 FailedMessage 值所提供的信息，然后解决已标识的条件。
警报、性能计数器或 Get-StorageGroupCopyStatus cmdlet 指示被动副本的复制或重播队列发生积压
可能的原因日志复制或重播活动发生积压的情况可能指示恢复过程中存在问题或者出现了转换条件。当被动副本在挂起相当长的时间之后刚恢复时，就会出现转换条件。如果该条件不是转换条件，则导致此问题的原因可能是下列其中一项：
存在配置问题。
复制活动已挂起。
Microsoft Exchange 复制服务已停止。
存储已失败或处于脱机状态。
解决方法通过执行下列操作确定是存在实际问题还是存在转换条件：
确认 Microsoft Exchange 复制服务正在运行。使用“服务”管理单元可以完成此任务。如果该服务已停止，则必须启动该服务。
通过 fl 命令运行 Exchange 命令行管理程序 cmdlet Get-StorageGroupCopyStatus，然后确定被动副本是否已挂起。如果被动副本已挂起，请确认被动副本的文件显示正确，然后使用 Resume-StorageGroupCopy cmdlet 恢复被动副本。
通过 fl 选项运行 Exchange 命令行管理程序 cmdlet Get-StorageGroupCopyStatus，确定副本是否正常。如果副本已失败，请检查状态字段列表来确定必要的更正操作。
对复制性能计数器持续观察数分钟，以确定进程是否正在执行中。应特别关注重播生成编号与检查生成编号。如果副本队列长度持续增加，而重播队列长度较短或不断减少，则主动副本或主动服务器本身的网络文件共享可能存在问题。使用存储组的 GUID 验证主动存储组副本的日志目录上定义了网络文件共享。您可以在 Exchange 命令行管理程序中结合使用 Get-StorageGroupCopyStatus cmdlet 与 fl 选项来确定存储组的 GUID。
Get-StorageGroupCopyStatus 为 LastInspectedLogTime 报告一个过期时间
可能的原因以下三种原因可能会导致此问题：
主动副本的数据库已被卸除。
已装入主动副本，但没有以很快的速率对其进行更改。因此，该主动副本不会产生日志。
Microsoft Exchange 复制服务没有运行。
解决方法确定导致问题出现的原因是上述三项中的哪一项。您可以通过执行以下操作来确定：
确定数据库是否已卸除，方法是使用 Exchange 管理控制台或者在 Exchange 命令行管理程序中运行 Get-StorageGroupStatus cmdlet。如果已卸除，则必须装入该数据库，而且必须在 LastInspectedLogTime 更改之前创建新的日志文件生成序列。
确认 Microsoft Exchange 复制服务正在运行。如果该服务已停止，则必须启动该服务。
验证数据库已装入之后，检查该数据库是否生成日志。查看活动数据库的日志目录，并使用最高生成编号标识日志文件。检查该日志的时间戳。它应与 LastInspectedLogTime 相匹配。
设定种子失败
可能的原因正在对主动副本进行备份，或者存在通信问题。
解决方法 确认当前没有对受影响的存储组或数据库执行备份。
Restore-StorageGroupCopy cmdlet 报告 Exx.log 不可用
可能的原因Restore-StorageGroupCopy cmdlet 提示您确定在缺少 Exx.log 的情况下是否应继续。
解决方法如果您希望通过激活来生成未丢失任何数据的数据库，请对该提示响应否。如果 Exx.log 在 Restore-StorageGroupCopy cmdlet 运行时不可用，则执行恢复会丢失数据。如果您响应否，则必须解决阻止访问生产日志的所有问题。更正这些问题之后，可以重新运行 Restore-StorageGroupCopy cmdlet。
详细信息
有关本主题中所涉及的 Exchange 命令行管理程序 cmdlet 的详细信息，请参阅下列主题：