Frågor som tar längre tid att avslutas när storleken på cacheminnet för TokenAndPermUserStore växer i SQL Server 2005

Gäller för: Microsoft SQL Server 2005 Developer EditionMicrosoft SQL Server 2005 Enterprise EditionMicrosoft SQL Server 2005 Enterprise X64 Edition

Programfel #: 429501 (SQLBUDT)
PROGRAMFEL #: 429501 (SQL BU defekt spårning)BUG #: 64830 (Innehållsunderhåll)

Symptom


I Microsoft SQL Server 2005, kan följande problem uppstå:
  • Frågor som vanligtvis snabbare ta längre tid att slutföras.
  • CPU-användningen för SQL Server-processen är mer än vanligt.
  • När du får sämre prestanda när du kör en fråga i ad hoc-visa frågan från vyn sys.dm_exec_requests eller sys.dm_os_waiting_tasks dynamisk hantering. Frågan verkar dock inte väntar på någon annan resurs.
  • Storleken på cache-lagra TokenAndPermUserStore växer i jämn takt.
  • Storleken på cache-lagra TokenAndPermUserStore är i flera hundra megabyte (MB).
  • I vissa fall innehåller körning av kommandot DBCC FREEPROCCACHE tillfällig befrielse.
Om du vill övervaka storleken på cacheminnet för TokenAndPermUserStore kan du använda en fråga som liknar följande:
SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'

Orsak


Cache-lagra TokenAndPermUserStore underhåller folllowing security token typer:
  • LoginToken
  • TokenPerm
  • UserToken
  • SecContextToken
  • TokenAccessResult.
Det finns också olika klasser av TokenAccessResult transaktioner. Detta problem beror på att det finns många poster i TokenAccessResult som har en klass med 65535.


På en instans av SQL Server som har hög hastighet av slumpmässiga dynamiska Frågekörningen Observera massor av TokenAccessResult transaktioner som har en klass med 65535 i vyn sys.dm_os_memory_cache_entries . TokenAccessResult-poster som har en klass med 65535 representerar särskilda cacheposter. Dessa poster används för kumulativa behörighet kontroller för frågor. Du kan till exempel köra följande fråga:
select * from t1 join t2 join t3
I det här fallet beräknar SQL Server kumulativa behörigheten kontroll för den här frågan. Den här kryssrutan avgör om en användare har Välj t1, t2, t3. Resultat av dessa kumulativa behörighet är inbäddade i en TokenAccessResult post och infogas i TokenAndPermUserStore cache-lagring med ID 65535. Om samma användare återanvänder eller kör den här frågan flera gånger, återanvänder SQL Server TokenAccessResult cache-post en gång.

När den här cachen butiken växer ökar tid att söka efter befintliga poster att återanvända. Åtkomst till den här cachen är kontrolleras så att endast en tråd kan utföra sökningen. Detta beteende så småningom orsaker fråga sämre prestanda och mer CPU-användningen sker.

Lösning


Information om Service pack

Lös problemet genom att skaffa den senaste service Packet för SQL Server 2005. För mer information klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
913089 hur du skaffar den senaste service Packet för SQL Server 2005
Lös det här problemet, ändrar SQL Server 2005 Service Pack 2 cachelagringens beteende behörighet token. Som standard cachelagras endast cacheposten för TokenAccessResult säkerhet för ad hoc-frågor när en särskild ad hoc-fråga körs igen.

Temporär lösning


Undvik det här problemet genom att använda en eller flera av följande metoder:
  • Uttryckligen parameterstyra ad hoc-frågor.

    Kommentarer
    • Den här metoden kan du effektivt återanvända ad hoc-frågor och deras planer.
    • När du använder den här metoden behöver du inte skapar en TokenAccessResult varje gång du kör ad hoc-fråga med olika parametrar.
    • Med den här metoden förblir storleken på cacheminnet för TokenAndPermUserStore under rimliga gränser.
  • Radbryt ad hoc-frågor inom lagrade procedurer och använda lagrade procedurer i stället för att direkt köra ad hoc-frågor.


    Kommentarer
    • Körning av planer cachelagras för programsatser som finns i den lagrade proceduren.
    • Posten TokenAccessResult för varje utdrag är associerad med posten för körning av planen.
    • Så länge Körningsplan för detta lagrad procedur finns kvar i cachen, återanvänder varje körning av den lagrade proceduren effektivt TokenAccessResult transaktioner. Därför behöver du inte skapa nya poster i TokenAccessResult.
  • Aktivera alternativet FORCE_PARAMETERIZATION databas.

    Kommentarer
    • Den här metoden kan du effektivt återanvända ad hoc-frågor och deras planer.
    • När du använder den här metoden behöver du inte skapar en TokenAccessResult varje gång du kör ad hoc-fråga med olika parametrar.
    • Med den här metoden förblir storleken på cacheminnet för TokenAndPermUserStore under rimliga gränser.
  • Lägga till inloggningen som utför olika ad hoc-frågor som medlem av sysadmin-servergrupp.

    Kommentarer
    • TokenAccessResult transaktioner skapas endast för ett ad hoc-frågan när frågan körs med en inloggning som inte är medlem av sysadmin-servergrupp.
    • Eftersom TokenAccessResult transaktioner skapas, behåller detta TokenAndPermUserStore cache-storleken till hanterbar storlek.
  • Rensa poster från cachen för TokenAndPermUserStore.

    Kommentarer
    • Det gör du genom att köra följande kommando:
      DBCC FREESYSTEMCACHE (TokenAndPermUserStore)
    • Vi rekommenderar försök se på tröskelvärdet cachestorleken TokenAndPermUserStore när problem börjar visas.
    • Du kan skapa ett schemalagt SQL Server Agent-jobb som utför följande åtgärder:
      • Kontrollera storleken på cache-storlek för TokenAndPermUserStore. Det gör du genom att köra följande kommando:
        SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • Om cache-storleken är större än tröskelvärdet som du kör du följande kommando:
        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Referenser


För mer information klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:

933564 KORRIGERA: en gradvis ökning minnesanvändningen för cache-lagra USERSTORE_TOKENPERM inträffar i SQL Server 2005

959823 hur du anpassar kvoten för TokenAndPermUserStore cache-lagra i SQL Server 2005 Service Pack 3