共用方式為

當 TokenAndPermUserStore 快取的大小在 SQL Server 中成長時，查詢需要較長的時間才能完成

本文可協助您針對成長大小 TokenAndPermUserStore 時的查詢效能相關問題進行疑難解答。 它也提供各種原因和因應措施。

原始 KB 編號： 927396

徵兆

在 Microsoft SQL Server 中，您會遇到下列徵兆：

  • 通常執行快速的查詢需要較長的時間才能完成。

  • SQL Server 進程的 CPU 使用量大於一般。

  • 當您執行臨機操作查詢時，效能會降低。 不過，如果您查詢 sys.dm_exec_requests 或 sys.dm_os_waiting_tasks 動態管理檢視，結果不會指出臨機操作查詢正在等候任何資源。

  • 快取的大小 TokenAndPermUserStore 會以穩定的速度成長。

  • 快取的大小 TokenAndPermUserStore 是數百 MB（MB）。

  • 在某些情況下，執行 DBCC FREEPROCCACHE 或 DBCC FREESYSTEMCACHE 命令可提供暫時的救濟。

原因

效能問題，例如高 CPU 和記憶體使用量增加，可能是因為快取中的 TokenAndPermUserStore 專案過多所造成。 根據預設，只有在 SQL Server 發出內部記憶體壓力時，才會清除此快取中的專案。 在具有大量 RAM 的伺服器上，內部記憶體壓力可能不會經常觸發。 當此快取成長時，搜尋現有專案需要較長的時間才能重複使用。 此快取的存取是由微調鎖定所控制。 一次只有一個線程可以進行搜尋。 此行為最終會導致查詢效能降低，且發生更多CPU使用量。

若要監視快取的大小 TokenAndPermUserStore ，您可以使用類似下列查詢的查詢：

SELECT SUM(pages_kb) AS 
   "CurrentSizeOfTokenCache(kb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

快 TokenAndPermUserStore 取會維護下列安全性令牌類型：

  • LoginToken
    • 每個伺服器層級主體一個登入令牌。
  • TokenPerm
    • 記錄 UserToken 和 SecContextToken 安全性實體物件的所有許可權。
    • 此快取中的每個專案都是特定安全性實體的單一許可權。 例如，在數據表 t1 上授與給使用者 u1 的選取許可權。
    • 此令牌專案與存取檢查結果 （ACR） 快取中的專案不同。 ACR 專案主要表示使用者或登入是否有執行整個查詢的許可權。
  • UserToken
    • 針對登入，每個資料庫有一個使用者令牌。
    • 儲存資料庫層級角色中成員資格的相關信息。
  • SecContextToken
    • 每個伺服器層級主體建立一個 SecContextToken。
    • 儲存主體的全伺服器安全性內容。
    • 包含使用者令牌的哈希表快取。
    • 儲存伺服器層級角色中成員資格的相關信息。
  • TokenAccessResult
    • TokenAccessResult 專案的不同類別存在。
    • 存取檢查指出特定資料庫中的指定使用者是否有權執行涉及多個對象的查詢。
    • Microsoft SQL Server 2008 之前，ACR 安全性快取會儲存在單一快取中。 TokenAndPermUserStore
    • 在 SQL Server 2008 中，ACR 快取會分開，而 ACR 快取專案則會在他們自己的個別使用者存放區中追蹤。 此區隔改善了效能，併為快取提供更好的貯體計數和配額控制。
    • TokenAndPermUserStore目前和 ACRCacheStores 是唯一使用的安全性快取類型。 如需 ACR 快取的詳細資訊，請參閱 存取檢查快取伺服器組態選項。

您可以執行下列查詢，以取得不同快取及其個別大小的相關信息：

SELECT type, name, pages_kb 
FROM sys.dm_os_memory_clerks 
WHERE type = 'USERSTORE_TOKENPERM'

您可以執行下列查詢，以識別 在 中 TokenAndPermUserStore成長的權杖種類：

SELECT [name] AS "SOS StoreName",[TokenName],[Class],[SubClass], count(*) AS [Num Entries]
FROM
(SELECT name,
x.value('(//@name)[1]', 'varchar (100)') AS [TokenName],
x.value('(//@class)[1]', 'varchar (100)') AS [Class],
x.value('(//@subclass)[1]', 'varchar (100)') AS [SubClass]
FROM
(SELECT CAST (entry_data as xml),name
FROM sys.dm_os_memory_cache_entries
WHERE type = 'USERSTORE_TOKENPERM') 
AS R(x,name)
) a
GROUP BY a.name,a.TokenName,a.Class,a.SubClass
ORDER BY [Num Entries] desc

因應措施

SQL Server 提供兩個追蹤旗標，可用來設定 的配額 TokenAndPermUserStore （根據預設，沒有配額。這表示此快取中可以有任意數目的專案。

  • TF 4618 - 將 中的 TokenAndPermUserStore 項目數目限制為 1024。
  • TF 4618+TF 4610 - 將 中的 TokenAndPermUserStore 項目數目限制為 8192。

如果 4618 的非常低的項目計數造成其他效能考慮，請使用追蹤旗標 4610 和 4618。

追蹤旗標 4610 和 4618 記載於《在線叢書》主題 DBCCC TRACEON - 追蹤旗標。

這些追蹤旗標應該用於未系結成長 TokenAndPermUserStore 對伺服器的案例。 這通常發生在兩種環境中：

  • 低端或中端硬體 TokenAndPermUserStore 會佔用伺服器大量可用的記憶體，以及新專案建立的速度較快或快取收回的速度一樣快。 這可能會導致伺服器其他部分的記憶體爭用和更頻繁的快取失效（例如，程式快取）。

  • 具有大量記憶體的高階計算機（例如，數個最近的支援案例涉及超過 1 TB 的 RAM）。 在這些環境中，快取存放區可以在遇到任何記憶體壓力之前成長。 這可能會導致長時間貯體鏈結或步行的效能降低。

作為暫時緩和措施，您可以使用下列方法定期清除此快取：

  • 從快取排 TokenAndPermUserStore 清專案。

注意：

  1. 若要這樣做，請執行下列命令：

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. 當問題開始出現時，請觀察快取大小的臨界值 TokenAndPermUserStore 。

  3. 建立採用下列動作的排程 SQL Server Agent 作業：

    • 檢查快取的大小 TokenAndPermUserStore 。 若要檢查大小，請執行下列命令：

      SELECT SUM(pages_kb) AS 
 "CurrentSizeOfTokenCache(kb)" 
 FROM sys.dm_os_memory_clerks 
 WHERE name = 'TokenAndPermUserStore'

    • 如果快取大小大於觀察到的臨界值，請執行下列命令：

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  • Last updated on