Freigeben über

Abfragen dauern länger, wenn die Größe des TokenAndPermUserStore-Caches in SQL Server wächst

  • Artikel

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

Ursprüngliche KB-Nummer: 927396

Problembeschreibung

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 wird die Leistung verringert. Wenn Sie jedoch die Ansichten der sys.dm_exec_requests dynamischen sys.dm_os_waiting_tasks Verwaltung 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 das Ausführen des Befehls oder DBCC FREESYSTEMCACHE des DBCC FREEPROCCACHE Befehls eine vorübergehende Erleichterung.

Ursache

Leistungsprobleme wie hohe CPU- 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 Speicherdruck signalisiert. Auf Servern mit viel RAM wird der interne Speicherdruck möglicherweise nicht häufig ausgelöst. Wenn dieser Cache wächst, dauert es länger, nach vorhandenen Einträgen zu suchen, um sie wiederzuverwenden. Der Zugriff auf diesen Cache wird durch ein Spinlock gesteuert. Nur jeweils ein Thread kann die Suche ausführen. Dieses Verhalten führt schließlich dazu, dass die Abfrageleistung verringert wird und mehr CPU-Auslastung auftritt.

Um die Größe des TokenAndPermUserStore Caches 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 eine bestimmte sicherungsfähige Person. Beispiel: Eine auswahlberechtigung, die in Tabelle t1 für Benutzer u1 erteilt wurde.
    • Dieser Tokeneintrag unterscheidet sich von Einträgen im ACR-Cache (Access Check Results). ACR-Einträge geben hauptsächlich an, ob ein Benutzer oder eine Anmeldung ü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 wurde pro Prinzipal auf Serverebene erstellt.
    • Speichert serverweiten Sicherheitskontext für einen Prinzipal.
    • Enthält einen Hashtabellencache von Benutzertoken.
    • Speichert Informationen zur Mitgliedschaft in Rollen auf Serverebene.
  • TokenAccessResult
    • Es sind verschiedene Klassen von TokenAccessResult-Einträgen vorhanden.
    • Access Check 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 einzigen Cache gespeichert. TokenAndPermUserStore
    • In SQL Server 2008 wurden die ACR-Caches getrennt, und die ACR-Cacheeinträge wurden in ihren eigenen Benutzerspeichern nachverfolgt. Durch diese Trennung wurde die Leistung verbessert und eine bessere Bucketanzahl und Kontingentsteuerung für die Caches bereitgestellt.
    • TokenAndPermUserStore Derzeit und ACRCacheStores sind die einzigen Arten von Sicherheitscaches, die verwendet werden. Weitere Informationen zu ACR-Caches finden Sie unter Access Check Cache Server Configuration Options.

Sie können die folgende Abfrage ausführen, um Informationen zu den verschiedenen Caches und deren 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 in der 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

Problemumgehung

SQL Server bietet zwei Ablaufverfolgungskennzeichnungen, mit denen das Kontingent des TokenAndPermUserStore Kontingents konfiguriert werden kann (Standardmäßig gibt es kein Kontingent. Dies bedeutet, dass es eine beliebige Anzahl von Einträgen in diesem Cache geben kann).

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

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

Spurenkennzeichnungen 4610 und 4618 sind im Thema "Books Online" dokumentiert, DBCCC TRACEON - Trace Flags.

Diese Ablaufverfolgungskennzeichnungen sollten für Szenarien verwendet werden, in denen das ungebundene Wachstum 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, für die TokenAndPermUserStore eine große Menge des verfügbaren Speichers für den Server belegt und für die die Rate der Erstellung neuer Einträge schneller oder so schnell wie die Rate der Cacheräumung ist. Dies kann zu Speicherkonflikten und häufigeren Ungültigkeit des Caches für andere Teile des Servers führen (z. B. proc-Cache).

  • 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 ein Speicherdruck auftreten kann. Dies kann zu Leistungsbeeinträchtigungen von langen Bucketketten oder Wanderungen führen.

Als temporäre Entschärfung können Sie diesen Cache regelmäßig mithilfe der folgenden Methode löschen:

  • Leeren von Einträgen aus dem TokenAndPermUserStore Cache.

Hinweise:

  1. Führen Sie zu diesem Zweck den folgenden Befehl aus:

    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

  2. Beobachten Sie den Schwellenwert der 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 zum Überprüfen der Größe den folgenden Befehl aus:

      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')