共用方式為

針對AD複寫錯誤 8461 進行疑難解答

本文說明 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 PREEMPTED

  • 徵兆 5：

    Active Directory Sites and Services 中的 「立即複寫」命令（DSSITE。MSC） 失敗並產生下列錯誤訊息：

    已先占復寫作業。

    對話框標題：立即複寫
    消息正文：嘗試從域控制器<來源DC同步處理目錄分割>的命名內容 <DNS 名稱期間發生下列錯誤>
    至域控制器 <目的地 DC>：
    已先占復寫作業。

  • 徵兆 6：

    目錄服務事件記錄檔中的事件會引用錯誤狀態 8461。

    事件來源和事件標識碼 訊息
    NTDS 複寫 1839 下列作業數目正在復寫佇列中等候。 自下列時間以來，最舊的作業一直在等候。 時間： <日期><時間> 等候作業數目： <如果> 此域控制器上的整體復寫工作負載太大或復寫間隔太小，就可能發生這個條件。
    NTDS 複寫 2094 效能警告：將變更套用至下列物件時，複寫已延遲。 如果此訊息經常發生，表示復寫發生速度緩慢，而且伺服器可能難以跟上變更。

    來源：NTDS 複寫
    事件標識碼 1839
    類型：警告
    描述：
    正在等候的作業數目如下
    在複寫佇列中。 最舊的作業具有
    自下列時間以來一直在等候。
    時間：
    等候作業數目：
    如果整體情況發生，就會發生此情況
    此域控制器上的複寫工作負載為
    太大或復寫間隔太小。

    注意

    當長時間執行的復寫工作完成時，如果詳細資訊複寫診斷記錄已設定為0x1或更新的值，也會記錄事件 1580。

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics]“5 複寫事件”=dword：00000001

    事件來源和事件標識碼 事件字串
    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 上的數個物件相互關聯。 查看事件中識別的屬性，並尋找高版本號碼，或全天取得相同物件的多個記錄，並查看版本號碼是否經常增加。

暫存

  • 大量變更不常發生
  • 第一次或重新裝載期間裝載分割區之後

效能型問題

效能引發佇列組建的常見徵兆包括

事件標識碼 2094

事件類型: 警告
事件來源：NTDS 複寫
事件類別：複寫
事件標識碼：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 休斯頓\5thWardDC
DC 物件 GUID GUID <>
DC 傳輸載入巨集 <GUID>._msdcs.contoso.com
FORCE
[12142] 優先順序為 40 的<加入佇列日期時間>
SYNC FROM SOURCE NC dc=west，dc=contoso，dc=com
DC Boulder\BoulderDC
DC 物件 GUID GUID <>
DC 傳輸載入巨集 <GUID>._msdcs.contoso.com
ASYNCHRONOUS_OPERATION NEVER_COMPLETED NEVER_NOTIFY PREEMPTED

其他相關資訊

慢速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取得 Repadmin /showutdvec /latency 。

在輸出中，記載下列各項：

  1. 從來源 DC showutdvec：Source DCName 旁的 USN #
  2. 從來源 DCNanme 旁邊的目的地 DC showutdvec USN#

來源 DC

Dallas\2008DC1 @ USN 451265 @ Time <DateTime>
Dallas\SourceDC @ USN 1126541 @ Time <DateTime>
休斯頓\2012DC3 @ USN 469842 @ 時間 <日期時間>
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>
休斯頓\2012DC3 @ USN 469842 @ 時間 <日期時間>
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 性能計數器。 您必須修改某些設定，例如持續時間和範例間隔，以符合您的特定案例。

如何建立使用者定義數據收集組

  1. 在 Windows Server 2008 或更新版本的完整版本上開啟 伺服器管理員。
  2. 展開 [診斷 > 效能 > 數據收集器集合]。
  3. 以滑鼠右鍵按兩下 [使用者定義]，然後選取 [新增 > 數據收集器集合]。
  4. 輸入 AD DS 診斷等名稱，並將 [從範本建立] 的預設選取範圍保留為 [建議] 。 然後選取下一步。
  5. 從範本清單中選取 [Active Directory 診斷]，然後選取 [下一步]，然後遵循精靈提示進行 （進行任何您認為必要的變更）。
  6. 以滑鼠右鍵按下新的 [使用者定義的數據收集器集]，然後檢視[屬性]。
  7. 若要變更運行時間，請修改 [停止條件] 索引標籤中的 [整體持續時間] 設定，然後按兩下 [確定] 以套用變更。

要考慮的選項：

  • 整體持續時間 -您可以在收集一段時間后停止數據收集器

  • 限制 -您可以在達到時間或大小閾值之後停止收集資料（您可以選擇自動重新啟動）

    當您想要限制記錄大小時，設定限制會比較有利。

    • 在限制下重新啟動數據收集器集

    • 期間

    • 大小上限

      AD DS 診斷 屬性視窗 的螢幕快照，其 [大小上限] 設定為 100 MB。

檢視使用者定義資料收集器集的性能計數器屬性

  1. 選取新的 [使用者定義的數據收集器集]。
  2. 以滑鼠右鍵按兩下 [性能計數器]，然後選取 [屬性]。

您可以在這裡選擇變更範例間隔，以及新增或移除其他計數器。

在此案例中，默認取樣間隔應為3秒就已足夠。 不過，針對較長的取樣時間，間隔太頻繁 3 秒。

性能計數器 屬性視窗 螢幕快照，其中已設定間隔 3 秒。

所有建議的計數器都會包含在預設 AD 診斷收集器集中，但有三個例外：

  • 資料庫 ==>Instances（lsass/NTDSA）\ *

  • LogicalDisk^\*

    針對 LogicalDisk：不需要所有實例 - 儲存資料庫和記錄的系統磁碟驅動器和磁碟驅動器至少應包含整個安全性系統統計數據\*

  • 安全性全系統統計數據\*

將 AD DS 資料庫計數器新增至使用者定義資料收集組

  1. 在 [性能計數器屬性] 中，選取 [新增]。

  2. 展開 [資料庫 ==>實例 ] （應反白顯示所有計數器）。

  3. 在 [選取對象的實例] 下，選取 lsass/NTDSA

  4. 選取 [新增]，然後按兩下 [確定]。

    所選物件實例下所選取 lsass/NTDSA 的螢幕快照。

  5. 同時新增LogicalDisk與 Security System-Wide Statistics 物件。

    性能計數器 屬性視窗 的螢幕快照，其中已選取LogicalDisk與 Security System-Wide Statistics 物件。

設定好您的喜好之後，您可以直接從 伺服器管理員 執行新的數據收集器集，或將其匯出並部署到特定伺服器。

當您準備好開始收集效能資料時，請啟動新定義的收集組：

若要從 MMC 啟動新定義的資料收集群組：

  1. 在 效能監視器 mmc 中，流覽至 [效能] / [資料收集器集合] /[使用者定義]
  2. 以滑鼠右鍵按下新的收集組 AD DS 診斷 ，然後選取 [啟動]。
  3. 您可以選擇[使用者定義的 AD DS 診斷 ] 來確認它已啟動，其狀態應該是 [執行中]

測試完成之後，請停止AD DS診斷收集組：

  1. 在 效能監視器 mmc 中，流覽至 [效能] / [資料收集器集] /[使用者定義]。
  2. 以滑鼠右鍵按下新的收集組 AD DS 診斷，然後選取 [停止]。 您可以選取 [使用者定義] 來確認它已停止。

AD DS 診斷 應該會從 [執行] 狀態移至 [編譯]，最後 [已停止 ] 請注意，MMC 對於重新整理其檢視並不大。因此，如果您在按兩下 [停止] 之後似乎停滯在 [執行] 或 [編譯] 中，請嘗試重新整理畫面。

編譯的報表可在 [效能]/[報告] /[使用者定義] /[AD DS 診斷] 下 檢視

Windows 檔案總管中的預設路徑如下： %systemdrive%\PerfLogs\Admin\AD DS 診斷

命令行指示：從命令行收集AD診斷：

若要從命令列啟動資料收集，請從提升許可權的命令提示字元發出此命令： logman start "user defined\AD DS Diagnostics" -ets
若要在預設 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個是事件標識碼1412（屬性新增）。

  • 增加目錄服務事件記錄檔的大小

  • 調整事件記錄檔的大小，讓增強式記錄不會造成記錄檔在短時間內換行

  • 啟用AD複寫診斷記錄以0x5：

    HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics 5 Replication Events = 5

在您收到狀態 8461 之後不久，請匯出 Directory Services 事件記錄檔，並將診斷記錄縮減為適當的層級。

檢閱下列事件記錄檔：

屬性值寫入資料庫的速度有多快？ ->Directory Services 事件記錄檔事件標識碼 1412 甚至更好，使用性能計數器：DirectoryServices / DRA Inbound Properties Applied/sec

在復寫事件的診斷層級 5 中，針對用戶物件建立，大約 25 個左右的事件 1412（視使用者建立時寫入的內容而定）會寫入（每個屬性值一個）。 新增所有屬性時，會記錄物件建立事件（事件標識符 1365）。

事件描述區段包含下列資料：

內部事件：
下列物件變更會套用至本機 Active Directory 網域服務 資料庫。
屬性：900dd （sAMAccountName）
物件：CN=xtestingusers14167，CN=Users，DC=north，DC=fabrikam，DC=com 物件
GUID： <GUID>
遠端版本：1
遠程時間戳： <DateTime>
遠端原始 USN：540828

Property 區段同時包含 屬性的 attributeID 和 lDAPDisplayName。

這個偵錯記錄層級的每個值會寫入一個事件。 篩選事件，並判斷指定期間內有多少專案。 檢閱事件詳細數據，以判斷我們是否要寫入多個屬性的值，以便具現化物件，或是否要跨多個物件寫入相同的屬性。 雖然這種分析層級似乎很麻煩，但它在判斷根本原因方面很有用。 例如，如果您看到我們每秒只撰寫一些事件，則可能表示交易正在緩慢寫入資料庫，或可能是我們有太多夥伴正在傳送備援變更（事件標識碼 1239）。

請注意，當復寫診斷設定為0x5時，看到事件標識碼 1239 是完全正常的。 如果您篩選掉事件 1239，而且看不到其他任何事件，而且您有相當長的事件記錄檔歷程記錄，則可能表示發生問題。 此問題是由已啟用網站間變更通知的大型 Active Directory 環境的客戶所觀察到。 如果您判斷每秒有大量的事件，複寫可能不會受到效能問題的影響。

物件元數據

如果記錄事件，指出變更需要很長的時間來處理事件標識符，請記錄 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 也會報告這項資訊。

擷取目前效能：

套用的 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個是事件標識碼1412（屬性新增）。 每秒事件 1412 秒的數目：

01: 2400
02: 3570
03: 3540
04: 2160
05: 1170
06: 1890
07: 2225
08: 1435
09: 4233
10: 2817

事件標識碼 1365 （物件建立） 在 1 分 27 秒內記錄了 6,312 次。 在一分鐘內，已建立 4,630 個用戶物件，其中包含 138,900 個屬性），或大約每秒 77 個物件。

需要瞭解 NTDS 性能計數器，才能有效地針對此問題進行疑難解答。

每秒的物件建立是透過下列性能計數器取得：

  • NTDS / DRA Inbound Objects Applied/sec

  • Database adds/sec

  • NTDS / DRA 輸入值 （僅限 DN）/秒 此數位包含參考其他物件的物件。 辨別名稱的值，例如群組或通訊組清單成員資格，比其他類型的值更昂貴，因為群組或通訊組清單物件可以包含數百或數千個成員。 相反地，簡單物件可能只有一或兩個屬性。 此計數器的大量數位可能會說明為什麼將輸入變更套用至資料庫的速度很慢。 每秒建立的屬性為：

  • NTDS / DRA Inbound Properties Applied/sec

經常遇到特殊情況

Repadmin /rehost 會導致狀態 8461：

重新裝載的 GC 正忙於接受其他分割區的更新時，就會發生此問題。 可寫入網域分割區的來源，包括架構、組態和網域分割區，本質上比重新裝載只讀網域分割區更高的優先順序工作專案。

Repadmin /queue 輸出應該會顯示新增數據分割的要求已排入佇列，最終將進行處理。 不過，有時候必須使用分割區重新裝載的替代方法：

  1. Repadmin /unhost
  2. 等候事件標識碼 1660
  3. 停用 KCC 連線轉譯
  4. Repadmin /addIf 在 /add 完成之前先佔程式，您可以停用輸入複寫，並使用 repadmin /replicate 和 /readonly /force 選項，在重新啟用輸入複寫之前，先重新裝載分割區。

資料收集

如果您需要Microsoft支援方面的協助，建議您遵循使用 TSS 收集 Active Directory 複寫問題的資訊中所述的步驟來收集資訊。