Dotazy trvat delší dobu dokončení, když se zvětší velikost mezipaměti TokenAndPermUserStore na serveru SQL Server 2005

Překlady článku Překlady článku
ID článku: 927396 - Produkty, které se vztahují k tomuto článku.
Bug #: 429501 (SQLBUDT)
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Příznaky

V roce 2005 Microsoft SQL Server můžete zaznamenat následující příznaky:
  • Dotazy, které obvykle rychleji trvat déle na dokončení spouštění.
  • Využití PROCESORU pro proces serveru SQL je více než obvykle.
  • Při poklesu výkonu setkáte, když spustíte dotaz ad hoc, zobrazit dotaz ze zobrazení dynamickou správu sys.dm_exec_requests nebo sys.dm_os_waiting_tasks. Dotaz však nezobrazí čekání na libovolný zdroj.
  • Velikosti úložiště mezipaměti TokenAndPermUserStore roste ustálenou rychlostí.
  • Velikost úložiště mezipaměti TokenAndPermUserStore je v pořadí podle několika set megabajtů (MB).
  • Provedení příkazu DBCC FREEPROCCACHE v některých případech poskytuje dočasné osvobození od dovozního cla.
Chcete-li sledovat velikost mezipaměti TokenAndPermUserStore, můžete použít dotaz podobný následujícímu:
SELECT SUM(single_pages_kb + multi_pages_kb) AS 
   "CurrentSizeOfTokenCache(kb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

Příčina

Úložiště mezipaměti TokenAndPermUserStore udržuje typy tokenu zabezpečení folllowing:
  • LoginToken
  • TokenPerm
  • UserToken
  • SecContextToken
  • TokenAccessResult.
Různé třídy TokenAccessResult položek jsou také obsaženy. Tato konkrétní problému dochází, protože jsou k dispozici mnoho TokenAccessResult položky, které nemají třídu 65535.

Na instanci serveru SQL Server s vysokou rychlostí provádění náhodných dynamické dotazu zjistíte mnoho TokenAccessResult položky, které nemají třídu 65535 v sys.dm_os_memory_cache_entries zobrazení. TokenAccessResult položek, které obsahují třídy 65535 představují položky speciální mezipaměti. Tyto položky mezipaměti jsou používány pro kontroly kumulativní oprávnění pro dotazy. Například může spustit následující dotaz:
select * 
from t1 join t2 join t3
v tomto případě serveru SQL Server vypočítá kumulativní oprávnění vyhledat tento dotaz. Tato kontrola Určuje, zda má uživatel vybrat t1, t2, t3. Tyto výsledky zaškrtnutí kumulativní oprávnění jsou vloženy do položky TokenAccessResult a jsou vloženy do úložiště mezipaměti TokenAndPermUserStore, jehož ID je 65535. Případně stejný uživatel opakovaně používá spustí tento dotaz vícekrát, SQL Server znovu použije položka mezipaměti TokenAccessResult jednou.

Při této mezipaměti úložiště roste, zvyšuje doba hledání znovu použít existující položky. Přístup k této mezipaměti je řízena tak, aby pouze jeden podproces může provést hledání. Toto chování nakonec způsobí, že dotaz snížení výkonnosti a dojde k další využití PROCESORU.

Řešení

Informace o aktualizaci Service Pack

Tento problém vyřešíte pomocí nejnovější aktualizace service pack pro SQL Server 2005. Další informace získáte následujícím článku znalostní báze Microsoft:
913089Jak získat nejnovější aktualizaci service pack pro SQL Server 2005
Chcete-li tento problém vyřešit, SQL Server 2005 Service Pack 2 změní chování ukládání do mezipaměti tokenů oprávnění. Ve výchozím ukryto pouze položka mezipaměti TokenAccessResult zabezpečení pro dotazy ad hoc při zvláštních ad hoc dotaz znovu.

Jak potíže obejít

Chcete-li tento problém vyřešit, použijte jednu nebo více z následujících metod:
  • Explicitně parametrizaci dotazů ad hoc.

    Poznámky
    • Tato metoda umožňuje efektivně znovu použít dotazy ad hoc a jejich plány.
    • Při použití této metody, nemáte vytvoření TokenAccessResult položky při každém spuštění dotazu ad hoc spolu s jinými parametry.
    • Touto metodou, velikost TokenAndPermUserStore, mezipaměti zůstane v přijatelných mezích.
  • Zalomit dotazy ad hoc v uložené procedury a uložené procedury použít namísto přímo spuštění dotazů ad hoc.

    Poznámky
    • Provádění plánů jsou ukládány do mezipaměti pro příkazy, které jsou uložené procedury.
    • Položka TokenAccessResult pro každý příkaz souvisí s položka plán provádění.
    • Tak dlouho, dokud plán vykonání tohoto postupu zůstane uložen v mezipaměti, každé provedení uložené procedury účinně opakovaně používá TokenAccessResult položky. Proto není nutné vytvořit nový TokenAccessResult položky.
  • Povolte možnost databáze FORCE_PARAMETERIZATION.

    Poznámky
    • Tato metoda umožňuje efektivně znovu použít dotazy ad hoc a jejich plány.
    • Při použití této metody, nemáte vytvoření TokenAccessResult položky při každém spuštění dotazu ad hoc spolu s jinými parametry.
    • Touto metodou, velikost TokenAndPermUserStore, mezipaměti zůstane v přijatelných mezích.
  • Přidat, přihlášení, který provádí dotazy ad hoc lišily jako člen skupiny serveru sysadmin.

    Poznámky
    • Položky TokenAccessResult vytvoří se pouze pro dotaz ad hoc při spuštění dotazu pomocí přihlášení, které není členem skupiny serveru sysadmin.
    • Protože položky TokenAccessResult se nevytvoří, udržuje toto chování velikost mezipaměti TokenAndPermUserStore na zvládnutelnou velikost.
  • Vyprázdnění položky z mezipaměti TokenAndPermUserStore.

    Poznámky
    • Chcete-li to provést, spusťte následující příkaz:
      DBCC FREESYSTEMCACHE (TokenAndPermUserStore)
    • V ideálním případě zkuste sledovat práh velikost mezipaměti TokenAndPermUserStore při zahájení se objeví problémy.
    • Můžete vytvořit naplánovanou úlohu Agent serveru SQL Server, které provede následující akce:
      • Zkontrolujte velikost mezipaměti TokenAndPermUserStore. Chcete-li to provést, spusťte následující příkaz:
        SELECT SUM(single_pages_kb + multi_pages_kb) AS 
           "CurrentSizeOfTokenCache(kb)" 
           FROM sys.dm_os_memory_clerks 
           WHERE name = 'TokenAndPermUserStore'
      • Pokud je velikost mezipaměti větší než práh, který zaznamenali, spusťte následující příkaz:
        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Odkazy

Další informace získáte v následujícím článcích v databázi Microsoft Knowledge Base:
933564Oprava: Postupné zvýšení spotřeby paměti pro úložiště mezipaměti USERSTORE_TOKENPERM v dojde k serveru SQL Server 2005
959823Jak přizpůsobit kvóty pro úložiště mezipaměti TokenAndPermUserStore v aktualizaci SQL Server 2005 Service Pack 3

Vlastnosti

ID článku: 927396 - Poslední aktualizace: 28. července 2009 - Revize: 4.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
Klíčová slova: 
kbmt kbtshoot kbinfo kbsql2005tsql kbprb KB927396 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:927396

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com