本文介绍 AD 复制延迟并生成 Win32 错误 8461 的情况的症状、原因和解决方法步骤:
复制操作被抢占。
原始 KB 数: 2981628
现象
具体症状如下:
症状 1:
DCDIAG 报告 Active Directory 复制测试失败并出现错误状态(8461):复制操作已被抢占。
来自 DCDIAG 的示例错误文本如下所示:
测试服务器: <站点><DC 名称>
开始测试:复制
* 复制检查复制延迟警告
[复制检查,<DC 名称>] 此复制路径被优先级较高的工作抢占。
从 <源 DC> 到 <目标 DC>
命名上下文:DC=<DN 路径>
复制生成了错误(8461):
复制操作被抢占。
沿此路径复制新更改将延迟。
进度通常在此路径上发生。症状 2:
REPADMIN.EXE报告最后一次复制尝试因正常原因而延迟,结果为 8461 (0x210d)。
REPADMIN
通常引用 8461 状态的命令包括但不限于:REPADMIN /REPLSUM
REPADMIN /SHOWREPL
REPADMIN /SHOWREPS
REPADMIN /SYNCALL
症状 3:
Repadmin /rehost
失败并生成状态代码 8461。症状 4:
Repadmin /queue
输出显示状态为“PREEMPTED”的一个或多个任务。[12142] 排队 2011-11-26 06:05:55 优先级 40
从源同步
NC dc=west,dc=contoso,dc=com
DSA Boulder\BoulderDC DC DSA 对象 GUID GUID <>
DSA 传输添加器 <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY抢占症状 5:
Active Directory 站点和服务(DSSITE)中的“立即复制”命令。MSC) 失败并生成以下错误消息:
复制操作被抢占。
对话框标题:立即复制
消息文本:尝试从域控制器<源 DC 同步目录分区>的命名上下文 <DNS 名称期间发生以下错误>
到域控制器 <目标 DC>:
复制操作被抢占。症状 6:
目录服务事件日志中的事件引用错误状态 8461。
事件源和事件 ID 消息 NTDS 复制 1839 复制队列中正在等待以下操作数。 自以下时间以来,最旧的操作一直在等待。 时间:<等待操作的日期><时间>数:<>如果此域控制器上的总体复制工作负荷太大或复制间隔太小,则可能会出现此条件。 NTDS 复制 2094 性能警告:在对以下对象应用更改时复制延迟。 如果此消息频繁发生,则表明复制正在缓慢进行,并且服务器可能难以跟上更改。 源:NTDS 复制
事件 ID 1839
类型: 警告
说明:
以下操作数正在等待
在复制队列中。 最早的操作具有
自以下时间以来一直在等待。
时间:
等待操作数:
如果总体情况发生此情况
此域控制器上的复制工作负荷为
太大或复制间隔太小。注意
如果详细复制诊断日志记录已设置为0x1或更大值,则还会记录长时间运行的复制任务时,也会记录事件 1580。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics]“5 个复制事件”=dword:00000001
事件源和事件 ID 事件字符串 NTDS 复制 1580 长时间运行的Active Directory 域服务入站复制任务已完成以下参数。
已用时间(分钟):
84
运行:
同步副本
选项:
0x21000051
参数 1:
DC=Contoso,DC=com
参数 2:
<源 DC ntds 设置对象 guid>
参数 3:
参数 4:
当系统不可用或目录分区长时间不可用时,也可能会发生长时间运行的复制任务。 长时间运行的复制任务可能指示大量更新,或源目录服务中发生的大量复杂更新。 在非关键时间执行这些更新可能会阻止复制延迟。
在添加新目录分区以Active Directory 域服务时,长时间运行的复制任务是正常的。 由于新的安装、全局目录升级或知识一致性检查器(KCC)生成的连接,可能会出现这种情况。
其他数据
错误值:
操作已成功完成。
原因
当目标 DC 入站队列中存在更高的优先级复制任务时,将返回此复制状态。 它不指示故障条件;复制任务不会取消,而是将任务置于保留模式中,直到优先级较高的工作完成。 在较大的环境中定期返回此消息是正常的,请务必注意条件是暂时性的。
虽然此问题很常见,但暂时性,但其他一些 AD 复制问题可能会导致队列积压。 如果发生这种情况,你可能会开始看到复制任务经常被抢占。 事件 2094“性能警告”(示例事件显示在“症状”和“解决方法”部分)的频繁日志记录是可能需要进行故障排除的另一个指示。
调查这些问题
说明 repadmin /queue
和复制优先级
分析一段时间内的队列输出,以确定是否正在处理任务
说明 repadmin /showrepl /verbose
Active Directory 复制已被抢占。 | 入站复制的进度因优先级较高的复制请求(例如使用命令手动 repadmin /sync 生成的请求)中断。 |
等待复制完成。 此信息性消息指示操作正常。 |
---|
复制负载
- 合作伙伴过多
- 对象和属性更新过于频繁
- 频繁更新与站点间更改通知相结合,导致高冗余更改通知率
- 小型复制计划窗口
基于性能的问题
- 磁盘和或内存性能
- 网络性能
解决方法
此状态不指示失败条件。 在许多情况下,这是一个临时问题,不需要解决步骤。
如果状态 8461 永远不会清除,则有很多工作要做以确定要采取的正确路径。 此问题需要对多个故障排除工具的高级知识。 可能需要寻求Microsoft 支持部门帮助协助数据分析过程。
在实施任何解决基础问题的步骤之前,必须确定原因。 复制状态 8461 的原因可能发生在以下任一情况下:
暂时性条件
复制负载
- 一致加载
- 临时加载
性能问题
- OS 性能
- 磁盘性能
- 网络性能
确定这是否只是暂时性条件。 记录手动复制启动的时间,并在输出中找到 repadmin /queue
相应的任务。 稍后,请运行 repadmin /queue
并确定手动启动的任务是否仍然存在。
如果复制任务已排队。 查看当前正在运行的任务,并进行调查。
使用事件日志数据、repadmin 输出和性能监视器来帮助隔离问题的原因。 确定处理更新的速度以及更改率。
复制负载
一致
域控制器的复制伙伴过多或复制负载过大。 重载 DC 的症状是:
即使复制任务及时处理,也永远不会清除的复制队列
注意
随着时间的推移,
repadmin /queue
可以使用这些数据并将其与性能数据相关联,以确定此方案。复制状态 8461 频繁出现
解决方法:减少入站连接(平衡中心站点 DC 之间的连接(此处ADLB.exe很有用),添加新 DC 并重新平衡连接,在辐射站点中部署 RODC,减少更改的过度复制。
复制过多
经常更新的属性。 使用详细复制事件日志事件(或使用 repadmin /showchanges
)标识属性更新,然后与 repadmin /showobjmeta
目标 DC 上的多个对象相关联。 查看事件中标识的属性并查找高版本号,或获取同一对象的多个日志,并查看版本号是否频繁增加。
临时
- 批量更改不经常
- 首次或在重新托管期间托管分区后
基于性能的问题
性能引发的队列生成常见症状包括
事件 ID 2094
事件类型: 警告
事件源:NTDS 复制
事件类别:复制
事件 ID:2094
说明:
性能警告:复制延迟
对以下对象应用更改时。 如果为
消息频繁发生,指示
复制发生缓慢,服务器可能
很难跟上变化。
对象 DN:CN=JUSTINTU,OU=Workstations,DC=contoso,DC=com
对象 GUID: <GUID>
分区 DN:DC=contoso,DC=com
服务器: <GUID>._msdcs.contoso.com
已用时间 (秒): 13
用户操作:
看到此延迟的一个常见原因是,此对象的大小(其值大小或值数)特别大。 应首先考虑是否可以更改应用程序,以减少存储在对象上的数据量或值数。如果这是一个大型组或通讯组列表,则可以考虑将林版本提升到 Windows Server 2003,因为这会使复制更高效地工作。 你应该评估服务器平台是否在内存和处理能力方面提供足够的性能。 最后,可能需要考虑通过将数据库和日志移动到单独的磁盘分区来优化 Active Directory 数据库。如果想要更改警告限制,则如下所示的注册表项。 值为零将禁用检查。
其他数据警告限制(秒):10 限制注册表项:System\CurrentControlSet\Services\NTDS\Parameters\Replicator 最大等待更新对象(秒)
通过使用性能监视和 repadmin /queue
输出来确定应用于数据库的更改是否正在缓慢发生。 将 AD 复制计数器与基本 OS 性能计数器(磁盘、内存、网络和 CPU)相关联。
DC
磁盘
网络
队列包含 55 个项目。
当前任务开始在 <DateTime> 执行。
任务已执行 508 分钟 53 秒。
[6485] 排队 2011-11-26 01:55:33 优先级为 590
SYNC FROM SOURCE NC DC=corp,DC=contoso,DC=com
DC Houston\5thWardDC
DC 对象 GUID GUID <>
DC 传输添加器 <GUID>._msdcs.contoso.com
FORCE
[12142] 优先级为 40 的<排队日期时间>
SYNC FROM SOURCE NC dc=west,dc=contoso,dc=com
DC 布尔德\布尔德DC
DC 对象 GUID GUID <>
DC 传输添加器 <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY抢占
详细信息
慢速 AD 复制故障排除
此问题需要对多个故障排除工具的高级知识。 可能需要寻求Microsoft 支持部门帮助协助数据分析过程。
术语:慢速与潜伏
在慢速 AD 复制中,更改会缓慢提交到 Active Directory 数据库,或者复制任务需要很长时间才能处理。
常见原因包括:
DC/OS 性能问题
- 资源耗尽
- 磁盘瓶颈
AD 数据库问题
- 逻辑或物理损坏
- 对象或属性问题
DC 加载问题
处理过多的客户端
复制风暴
- 对对象和属性的更改率高
- 完全分区同步
在延迟 AD 复制中,DC 在很长一段时间内不会收到有关更改的通知:
常见原因包括:
- AD 拓扑配置(计划、站点链接、复制计划、断开连接的拓扑)
本文档和数据收集策略用于对慢 AD 复制进行故障排除。
AD 复制速度缓慢的症状
数据收集
Repadmin 数据
用于 Repadmin /queue
记录排队的复制任务。 监视队列,以查看处理复制任务是否存在延迟。 将所有 repadmin /queue
输出记录到同一文本文件,以便具有良好的历史数据。
Repadmin /queue DCName >DCNameReplQueue.txt
Choice /d y /t 300
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 300
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 900
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 900
Repadmin /queue DCName >>DCNameReplQueue.txt
Choice /d y /t 1800
Repadmin /queue DCName >>DCNameReplQueue.txt
查看输出以查看复制任务是否及时处理。 文件顶部包含当前正在运行的任务及其运行时间长度。 如果同一任务始终位于输出顶部,则可以使用详细输出 repadmin /showrepl
来监视进度。
Repadmin 更改
Repadmin /showrepl
使用 Repadmin /showrepl
和 /verbose
选项监视上次复制状态和要复制的更改数。
Repadmin /showrepl /verbose DCNameDomainDN
Repadmin /showrepl /verbose 5thwardCorpDC dc=corp,dc=contoso,dc=com
若要限制输出,以便仅显示所需的源 DC,请使用以下内容:
Repadmin /showrepl /verbose DCNameDomainDN SourceDcDSAObjectGUID
Repadmin /showrepl /verbose 5thwardCorpDC <GUID> dc=corp,dc=contoso,dc=com
Repadmin /showutdvec
在 Repadmin /showutdvec
源和目标 DC 上使用来确定复制增量。
repadmin /showutdvec DCName DomainDN
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com
从有关分区的源 DC 和目标 DC 获取 Repadmin /showutdvec /latency
。
在输出中,记录以下内容:
- 从源 DC showutdvec:源 DCName 旁边的 USN #
- 从源 DCNanme 旁边的目标 DC showutdvec USN#
源 DC
Dallas\2008DC1 @ USN 451265 @ Time <DateTime>
Dallas\SourceDC @ USN 1126541 @ Time <DateTime>
Houston\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\2012DC2 @ USN 460219 @ Time <DateTime>
Dallas\DestinationDC @ USN 1353465 @ Time <DateTime>
Dallas\2003DC1 @ USN 15556 @ Time <DateTime>
目标 DC
Dallas\2008DC1 @ USN 451265 @ Time <DateTime>
Dallas\SourceDC @ USN 801224 @ Time <DateTime>
Houston\2012DC3 @ USN 469842 @ Time <DateTime>
66a1b264-80b8-44f8-8356-9ebcd7a34f15 @ USN 32811 @ Time <DateTime>
Dallas\2012DC2 @ USN 460219 @ Time <DateTime>
Dallas\DestinationDC @ USN 1359087 @ Time <DateTime>
Dallas\2003DC1 @ USN 15556 @ Time <DateTime>
源 DC
SourceDC @ USN 1126541
目标 DC
SourceDC @ USN 801224
1126541-801224 = 325317
目标 DC 落后 325,317 个 USN。
注意
还可以使用以下命令从源 DC 获取源 DC 中最高的提交USN :
repadmin /showattr SourceDC . /atts:highestcommittedusn DN: 1> highestCommittedUSN: 1126541
性能数据
在使用 AD 诊断模板的性能监视器中创建新的用户定义的数据收集器集。
此处的步骤详细介绍了如何设置一组良好的基线 DC 性能计数器。 需要修改某些设置,例如持续时间和示例间隔,以适应特定方案。
如何创建用户定义的数据收集集
- 在 Windows Server 2008 或更高版本的完整版本上打开服务器管理器。
- 展开诊断 > 性能 > 数据收集器集。
- 右键单击“用户定义的”并选择“新建 > 数据收集器集”。
- 键入名称(如 AD DS 诊断),并保留从模板(建议)选择的默认选择。 然后选择下一步。
- 从模板列表中选择 Active Directory 诊断,然后选择“下一步”,然后按照向导提示进行操作(进行任何认为必要的更改)。
- 右键单击新的用户定义的数据收集器集并查看属性。
- 若要更改运行时,请在“停止条件”选项卡中修改“总持续时间”设置,然后单击“确定”以应用更改。
要考虑的选项:
总体持续时间 -可以在收集一定时间后停止数据收集器
限制 - 可以在达到时间或大小阈值后让数据收集停止(可以选择自动重启)
如果要限制日志大小,设置限制是有利的。
按限制重启数据收集器集
持续时间
最大大小
查看用户定义的数据收集器集的性能计数器属性
- 选择新的用户定义的数据收集器集。
- 右键单击“性能计数器”,然后选择“属性”。
此处提供了更改示例间隔以及添加或删除其他计数器的选项。
对于此方案,默认采样间隔应足够 3 秒。 但是,对于更长的采样时间,3 秒的间隔太频繁。
所有建议的计数器都包含在默认 AD 诊断收集器集中,但有三个例外:
数据库 ==>Instances(lsass/NTDSA)\ *
LogicalDisk\\*
对于 LogicalDisk:不需要所有实例 - 应至少包括存储数据库和日志的系统驱动器和驱动器
安全系统范围的统计信息\*
将 AD DS 数据库计数器添加到用户定义的数据收集集
在 “性能计数器属性”中,选择“添加”。
展开 数据库 ==>Instances (应突出显示所有计数器)。
在所选对象的实例下,选择 lsass/NTDSA
选择“添加”,然后单击“确定”。
同时添加 LogicalDisk 和安全系统范围的统计信息对象。
将设置配置为喜欢后,可以直接从服务器管理器运行新的数据收集器集,或将其导出并部署到特定服务器。
准备好开始收集性能数据时,启动新定义的收集集:
若要从 MMC 启动新定义的数据收集集,
- 在 性能监视器 mmc 中,导航到“性能”/“数据收集器集”/“用户定义的”
- 右键单击新集合集 AD DS 诊断 ,然后选择“启动”。
- 可以通过选择“用户定义的 AD DS 诊断 ”来验证它是否已启动,其状态应为“正在运行”
测试完成后,停止 AD DS 诊断收集集:
- 在 性能监视器 mmc 中,导航到性能/数据收集器集/用户定义。
- 右键单击新集合集 AD DS 诊断,然后选择“停止”。 可以通过选择“用户定义的”来验证它是否已停止。
AD DS 诊断 应从“正在运行”状态变为“正在编译”,最后停止 ,请注意,MMC 对刷新其视图并不好。因此,如果在单击“停止”后似乎停滞在“正在运行”或“编译”中,请尝试刷新屏幕。
编译的报表在“性能”/“报告”/“用户定义的”/“AD DS 诊断”下 可查看
Windows 资源管理器中的默认路径如下所示: %systemdrive%\PerfLogs\Admin\AD DS 诊断
命令行说明:从命令行收集 AD 诊断:
若要从命令行启动数据收集,请从提升的命令提示符发出此命令: logman start "user defined\AD DS Diagnostics" -ets
若要在默认 5 分钟之前停止数据收集,请发出此命令:(获取此问题至少一个完整的 5 分钟示例) logman stop "user defined\AD DS Diagnostics" -ets
此处记录了诊断数据:C:\PerfLogs\Admin\AD DS Diagnostics\DateStamp
示例数据收集脚本
logman start "system\Active Directory Diagnostics" -ets time /t >slow.txt
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
:start
ping 127.0.0.1 -n 60 >NUL
time /t >>slow.txt time /t >>slowrepl.txt
repadmin /showrepl /verbose LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slowrepl.txt
repadmin /queue LiverpoolDC1 >>slow.txt
repadmin /showutdvec LiverpoolDC1 dc=north,dc=fabrikam,dc=com >>slow.txt
goto start
事件日志数据
目录服务事件日志中启用的默认日志记录可用于监视指示更改应用程序速度缓慢的事件。 (事件 X)可以启用详细诊断日志记录,以查看当前正在应用的更改。 在本文中所述级别启用诊断日志记录将导致日志填满相当快,因此仅在主动排查此情况时启用它。 若要了解使用此级别详细记录的事件速率:
一个目录服务事件日志,配置为 100 MB 包装不到两分钟(1 分 27 秒)。 该日志包含 195,728 个事件。 在所有事件中,189,340 个事件 ID 为 1412(属性添加)。
增加目录服务事件日志的大小
调整事件日志大小,使增强型日志记录不会使日志在短时间内换行
启用 AD 复制诊断日志记录以0x5:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics 5 Replication Events = 5
在收到状态 8461 后不久导出目录服务事件日志,并将诊断日志记录减少到合适的级别。
查看事件日志,了解以下内容:
属性值写入数据库的速度有多快? ->Directory Services 事件日志事件 ID 1412 甚至更好,使用性能计数器:DirectoryServices/DRA Inbound Properties Applied/sec
在复制事件的诊断级别 5 中,对于用户对象创建,大约 25 个左右的事件 1412(具体取决于在创建用户时写入的内容)是写入的(每个属性值一个)。 添加所有属性后,将记录对象创建事件(事件 ID 1365)。
事件的说明部分包含以下数据:
内部事件:
以下对象更改应用于本地Active Directory 域服务数据库。
属性:900dd (sAMAccountName)
对象:CN=xtestingusers14167,CN=Users,DC=north,DC=fabrikam,DC=com 对象
GUID: <GUID>
远程版本:1
远程时间戳: <DateTime>
远程发起 USN:540828
Property 节包含特性的 attributeID 和 lDAPDisplayName。
在此调试日志级别为每个值写入一个事件。 筛选事件并确定给定时间段内发生的条目数。 查看事件详细信息,以确定是否要为多个属性编写值以实例化对象,或者是否要跨多个对象写入同一属性。 虽然这种分析级别看起来很麻烦,但它在确定根本原因方面可能很有用。 例如,如果你看到我们每秒只写入几个事件,则可能表明事务正在缓慢地写入数据库,或者我们有太多合作伙伴正在发送冗余更改(事件 ID 1239)。
请注意,当复制诊断设置为0x5时,看到事件 ID 1239 是完全正常的。 如果筛选掉事件 1239,并且看不到其他任何事件,并且有相当长的事件日志历史记录,则可能表示出现问题。 在启用了站点间更改通知的大型 Active Directory 环境的客户观察到此问题。 如果确定每秒有大量事件,则复制可能不受性能问题的影响。
对象元数据
如果记录了指示更改需要很长时间来处理事件 ID 的事件,请记录 objectGUID,然后获取以下输出:
复制元数据:
Repadmin /showobjmeta "<GUID=ObjectGUID>" >objectmeta.txt
查看最近修改的属性的输出。 特别注意具有频繁修改版本号的属性。 具有高版本计数的属性可能指示对属性进行频繁更改。 如果怀疑这一点,可以查看属性值以获取一些上下文,了解属性更改的原因,或者可以让一段时间过去,然后获取添加 repadmin /showobjmeta
输出,以便检查同一对象上相同属性的版本是否已进一步增加。
对象和属性数据:
使用实用工具输出对象和属性值。 然后,查看最近修改过数据的属性的属性数据。 以下示例演示了两种方法来执行此操作。
repadmin 中的对象属性值:
Repadmin /showattr DCName "<GUID=ObjectGUID>" /allvalues /long >objectByGuid.txt
LDP 中的对象属性值
在 LDP 中连接并绑定到服务器,并将对象的所有输出复制到文本文件
ldpoutput.txt
与网络相关的数据
Tasklist /svc >nets.txt Netstat -anob >>nets.txt
Data AnalysisKey AD 复制特定的性能计数器
- 剩余的 DRA 入站完全同步对象
- 应用的 DRA 入站对象数/秒
- DRA 入站对象/秒(入站复制)
- 筛选的 DRA 入站对象数/秒(建议所有新属性)
- 自启动复制队列以来的 DRA 出站字节总数:
DirectoryServices\DRA 挂起的复制同步 | 指示为此服务器排队的目录同步数。 此计数器有助于识别复制积压工作数越高,积压工作就越大。 | 此计数器应尽可能低。 如果不是,服务器硬件可能会降低复制速度。 |
---|
使用此计数器确定复制队列。 Repadmin /queue DCName 还会报告此信息。
Gauging Current Performance:
应用的 DRA 入站对象数/秒 | 显示通过入站复制和应用从邻居接收的对象数。 |
---|---|
应用了 DRA 入站属性/秒 | 显示从入站复制伙伴应用的对象属性(属性)总数。 |
可以使用这两个计数器来监视对数据库应用更改的速度。
数据库:
服务器性能:
DirectoryServices\DRA 入站对象更新剩余数据包 | 指示在尚未应用于本地服务器的最近目录复制更新数据包中收到的对象更新数。 | 此计数器指示受监视的服务器正在接收更改,但需要很长时间才能将其应用到数据库。 此计数器应尽可能低。 如果不是,它通常表示服务器硬件正在减慢复制速度。 |
---|
网络:
Object\counter | 说明 | 指南 |
---|---|---|
DirectoryServices\DRA Inbound Bytes Total/sec | 指示通过入站复制每秒接收的总字节数。 此数字是入站期间收到的未压缩和压缩数据的字节之和 |
测试
方案两个 DC 是隔离的(没有客户端或其他服务器活动),15,000 个用户是从脚本创建的,其中填充了一个 DC 上的最小属性,这两个 DC 之间的连接。
若要了解使用此级别详细记录的事件速率:
一个目录服务事件日志,其大小配置为 100 MB,包装不到两分钟(1 分 27 秒)。 该日志包含 195,728 个事件。 在所有事件中,189,340 个事件 ID 为 1412(属性添加)。 每秒事件 1412 秒的数目:
01: 2400
02: 3570
03: 3540
04: 2160
05: 1170
06: 1890
07: 2225
08: 1435
09: 4233
10: 2817
事件 ID 1365(创建对象)在 1 分 27 秒内记录了 6,312 次。 在一分钟内,创建了 4,630 个用户对象,其中包含 138,900 个属性)或大约 77 个对象/秒。
若要有效地排查此问题,需要了解 NTDS 性能计数器。
每秒对象创建数通过以下性能计数器获取:
已应用 NTDS / DRA 入站对象数/秒
数据库添加数/秒
NTDS / DRA 入站值 (仅限 DN)/秒 此数字包括引用其他对象的对象。 可分辨名称的值(如组或通讯组列表成员身份)比其他类型的值更昂贵,因为组或通讯组列表对象可以包含数百或数千个成员。 相比之下,简单对象可能只有一个或两个属性。 此计数器中的大量数字可能会解释入站更改为何应用于数据库的速度较慢。 每秒创建属性数为:
已应用 NTDS / DRA 入站属性/秒
经常遇到特殊情况
Repadmin /rehost 结果状态为 8461:
重新托管的 GC 正忙于接受其他分区的更新时,会出现此问题。 可写域分区(包括架构、配置和域分区)的溯源本质上比重新托管只读域分区优先级高。
Repadmin /queue 输出应显示添加分区的请求已排队,最终将进行处理。 但是,有时必须使用分区重新托管的替代方法:
- Repadmin /unhost
- 等待事件 ID 1660
- 禁用 KCC 连接转换
Repadmin /addIf
该过程在 /add 完成之前被抢占,你可以禁用入站复制并使用repadmin /replicate
以及/readonly
用于在重新启用入站复制之前重新托管分区的选项/force
。
数据收集
如果需要Microsoft支持方面的帮助,建议按照使用 TSS 收集 Active Directory 复制问题的信息中所述的步骤收集信息。