Freigeben über

Der Abschluss von Abfragen dauert länger, wenn die Größe des TokenAndPermUserStore-Caches in SQL Server

  • Artikel

Dieser Artikel hilft Ihnen bei der Behandlung von Problemen im Zusammenhang mit der Abfrageleistung, wenn die Größe von TokenAndPermUserStore zunimmt. Außerdem werden verschiedene Ursachen und Problemumgehungen bereitgestellt.

Ursprüngliche KB-Nummer: 927396

Symptome

In Microsoft SQL Server treten die folgenden Symptome auf:

  • Abfragen, die in der Regel schnell ausgeführt werden, dauern länger.

  • Die CPU-Auslastung für den SQL Server Prozess ist größer als üblich.

  • Beim Ausführen einer Ad-hoc-Abfrage tritt eine Leistungseinbuße auf. Wenn Sie jedoch die sys.dm_exec_requests dynamischen Verwaltungssichten oder sys.dm_os_waiting_tasks abfragen, geben die Ergebnisse nicht an, dass die Ad-hoc-Abfrage auf eine Ressource wartet.

  • Die Größe des TokenAndPermUserStore Caches wächst stetig.

  • Die Größe des TokenAndPermUserStore Caches beträgt mehrere hundert Megabyte (MB).

  • In einigen Fällen bietet die Ausführung des DBCC FREEPROCCACHE Befehls oder DBCC FREESYSTEMCACHE eine vorübergehende Entlastung.

Ursache

Leistungsprobleme wie hohe CPU-Auslastung und erhöhte Arbeitsspeicherauslastung können durch übermäßige Einträge im TokenAndPermUserStore Cache verursacht werden. Standardmäßig werden Einträge in diesem Cache nur bereinigt, wenn SQL Server internen Speichermangel signalisiert. Auf Servern, die über viel RAM verfügen, kann es vorkommen, dass die auslastung des internen Speichers nicht häufig ausgelöst wird. Wenn dieser Cache zunimmt, dauert es länger, nach vorhandenen Einträgen zu suchen, um sie wiederzuverwenden. Der Zugriff auf diesen Cache wird durch einen Spinlock gesteuert. Die Suche kann jeweils nur von einem Thread ausgeführt werden. Dieses Verhalten führt schließlich dazu, dass die Abfrageleistung abnimmt und eine größere CPU-Auslastung auftritt.

Um die Größe des Caches TokenAndPermUserStore zu überwachen, können Sie eine Abfrage verwenden, die der folgenden Abfrage ähnelt:

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

Der TokenAndPermUserStore Cache verwaltet die folgenden Sicherheitstokentypen:

  • LoginToken
    • Ein Anmeldetoken pro Prinzipal auf Serverebene.
  • TokenPerm
    • Zeichnet alle Berechtigungen für ein sicherungsfähiges Objekt für ein UserToken und SecContextToken auf.
    • Jeder Eintrag in diesem Cache ist eine einzelne Berechtigung für ein bestimmtes sicherungsfähiges Element. Beispielsweise eine Auswahlberechtigung, die dem Benutzer u1 für Tabelle t1 erteilt wird.
    • Dieser Tokeneintrag unterscheidet sich von Einträgen im ACR-Cache (Access Check Results). ACR-Einträge geben hauptsächlich an, ob ein Benutzer oder ein Anmeldename über die Berechtigung zum Ausführen einer gesamten Abfrage verfügt.
  • Usertoken
    • Ein Benutzertoken pro Datenbank für eine Anmeldung.
    • Speichert Informationen zur Mitgliedschaft in Rollen auf Datenbankebene.
  • SecContextToken
    • Ein SecContextToken, das pro Prinzipal auf Serverebene erstellt wird.
    • Speichert den serverweiten Sicherheitskontext für einen Prinzipal.
    • Enthält einen Hashtabellencache mit Benutzertoken.
    • Speichert Informationen zur Mitgliedschaft in Rollen auf Serverebene.
  • TokenAccessResult
    • Es sind verschiedene Klassen von TokenAccessResult-Einträgen vorhanden.
    • Die Zugriffsüberprüfung gibt an, ob ein bestimmter Benutzer in einer bestimmten Datenbank über die Berechtigung zum Ausführen einer Abfrage verfügt, die mehrere Objekte umfasst.
    • Vor Microsoft SQL Server 2008 wurden ACR-Sicherheitscaches in einem einzelnen Cache gespeichert, TokenAndPermUserStore.
    • In SQL Server 2008 wurden die ACR-Caches getrennt, und die ACR-Cacheeinträge wurden in ihren eigenen individuellen Benutzerspeichern nachverfolgt. Diese Trennung verbesserte die Leistung und bot eine bessere Bucketanzahl und Kontingentsteuerung für die Caches.
    • TokenAndPermUserStore Derzeit sind und ACRCacheStores die einzigen Arten von Sicherheitscaches, die verwendet werden. Weitere Informationen zu ACR-Caches finden Sie unter Konfigurationsoptionen für die Zugriffsüberprüfung des Caches.

Sie können die folgende Abfrage ausführen, um Informationen zu den verschiedenen Caches und ihren individuellen Größen abzurufen:

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

Sie können die folgende Abfrage ausführen, um die Arten von Token zu identifizieren, die TokenAndPermUserStoreim wachsen:

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

Problemumgehung

SQL Server bietet zwei Ablaufverfolgungsflags, die zum Konfigurieren des Kontingents von TokenAndPermUserStore verwendet werden können (Standardmäßig gibt es kein Kontingent. Dies bedeutet, dass in diesem Cache eine beliebige Anzahl von Einträgen vorhanden sein kann.

  • TF 4618 : Beschränkt die Anzahl der Einträge in TokenAndPermUserStore auf 1024.
  • TF 4618+TF 4610 - Begrenzt die Anzahl der Einträge in TokenAndPermUserStore auf 8192.

Wenn die sehr niedrige Eintragsanzahl von 4618 andere Leistungsprobleme verursacht, verwenden Sie die Traceflags 4610 und 4618 zusammen.

Die Ablaufverfolgungsflags 4610 und 4618 sind im Thema der Onlinedokumentation DBCCC TRACEON – Ablaufverfolgungsflags dokumentiert.

Diese Ablaufverfolgungsflags sollten für Szenarien verwendet werden, in denen das unbegrenzte Wachstum von TokenAndPermUserStore für den Server zu groß ist. Dies tritt in der Regel in zwei Arten von Umgebungen auf:

  • Low-End- oder Medium-End-Hardware, die TokenAndPermUserStore einen großen Teil des verfügbaren Arbeitsspeichers für den Server belegt und bei der die Rate der Erstellung neuer Einträge schneller oder so schnell ist wie die Rate der Cacheentfernung. Dies kann zu Speicherkonflikten und häufigeren Cacheinvalidierungen für andere Teile des Servers (z. B. Proc-Cache) führen.

  • High-End-Computer mit viel Arbeitsspeicher (z. B. mehrere aktuelle Supportfälle mit mehr als 1 TB RAM). In diesen Umgebungen kann der Cachespeicher groß werden, bevor er zu arbeitsspeicherauslastung kommt. Dies kann durch lange Bucketketten oder Schritte zu leistungseinbußen führen.

Als vorübergehende Entschärfung können Sie diesen Cache in regelmäßigen Abständen löschen, indem Sie die folgende Methode verwenden:

  • Leeren von Einträgen aus dem TokenAndPermUserStore Cache.

Hinweise:

  1. Führen Sie dazu den folgenden Befehl aus:

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Beachten Sie den Schwellenwert für die TokenAndPermUserStore Cachegröße, wenn Probleme auftreten.

  3. Erstellen Sie einen geplanten SQL Server-Agent Auftrag, der die folgenden Aktionen ausführt:

    • Überprüfen Sie die Größe des TokenAndPermUserStore Caches. Führen Sie den folgenden Befehl aus, um die Größe zu überprüfen:

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

    • Wenn die Cachegröße größer als der beobachtete Schwellenwert ist, führen Sie den folgenden Befehl aus:

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')