Nr błędu: 429501 (SQLBUDT)

Objawy

W Microsoft SQL Server 2005 mogą wystąpić następujące symptomy:

  • Kwerendy, które zwykle działają szybciej trwać dłużej zakończenia działania.

  • Wykorzystanie Procesora dla procesu programu SQL Server jest więcej niż zwykle.

  • Gdy występuje obniżenie wydajności podczas uruchamiania kwerend ad hoc, zobacz kwerendy widoku zarządzania dynamicznego sys.dm_exec_requests lub sys.dm_os_waiting_tasks . Jednakże kwerenda nie oczekuje na dowolny zasób.

  • Rozmiar magazynu pamięci podręcznej TokenAndPermUserStore rośnie w stałym tempie.

  • Rozmiar magazynu pamięci podręcznej TokenAndPermUserStore są w kolejności nawet kilkaset megabajtów (MB).

  • W niektórych przypadkach wykonanie polecenia DBCC FREEPROCCACHE zawiera tymczasowe zwolnienie.

Aby monitorować rozmiar pamięci podręcznej TokenAndPermUserStore, można użyć kwerendy, podobny do następującego:

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

Przyczyna

TokenAndPermUserStore magazynu pamięci podręcznej przechowuje typy tokenów zabezpieczeń folllowing:

  • LoginToken

  • TokenPerm

  • UserToken

  • SecContextToken

  • TokenAccessResult.

Różne rodzaje TokenAccessResult wpisy są również obecne. Ten problem występuje, ponieważ wiele zapisów TokenAccessResult, które mają klasy 65535 są obecne.


W wystąpieniu programu SQL Server, który ma wysoki stopień wykonywanie kwerend dynamicznych losowe można zauważyć wiele wpisów TokenAccessResult, które mają klasy 65535 w widoku sys.dm_os_memory_cache_entries . TokenAccessResult wpisy, które mają klasy 65535 reprezentują wpisy pamięci podręcznej specjalne. Te wpisy pamięci podręcznej są używane do kontroli uprawnień zbiorczej dla kwerend. Na przykład można uruchomić następującą kwerendę:

select * 
from t1 join t2 join t3

W takim przypadku program SQL Server oblicza wyboru uprawnień zbiorczej dla tej kwerendy. Ten test określa, czy użytkownik ma wybrać opcję na t1, t2, t3. Te wyniki sprawdzania uprawnień zbiorczej są osadzone na wpis TokenAccessResult i są wstawiane do magazynu TokenAndPermUserStore pamięci podręcznej o identyfikatorze 65535. Jeśli ten sam użytkownik ponownie używa lub wykonuje tę kwerendę wiele razy, SQL Server ponownie używa wpis pamięci podręcznej TokenAccessResult jeden raz.

Podczas tego magazynu pamięci podręcznej rośnie, zwiększa się czas, aby wyszukiwać istniejące wpisy do ponownego użycia. Dostęp do tej pamięci podręcznej jest kontrolowany, tak, że tylko jeden wątek można przeprowadzić wyszukiwanie. To zachowanie ostatecznie przyczyny zapytania zmniejszenie wydajności i występuje więcej wykorzystanie procesora CPU.

Rozwiązanie

Informacje dodatku Service pack

Aby rozwiązać ten problem, należy uzyskać najnowszy dodatek service pack dla programu SQL Server 2005. Aby uzyskać więcej informacji, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:

913089 jak uzyskać najnowszy dodatek service pack dla programu SQL Server 2005
Aby rozwiązać ten problem, SQL Server 2005 z dodatkiem Service Pack 2 zmienia zachowanie buforowania tokenów uprawnień. Domyślnie wpis pamięci podręcznej zabezpieczeń TokenAccessResult dla kwerend ad hoc są buforowane tylko, gdy szczególne kwerend ad hoc jest wykonywana ponownie.

Obejście problemu

Aby obejść ten problem, użyj jednej lub kilku z następujących metod:

  • Jawnie Definiowanie parametrów kwerend ad hoc.

    Uwagi

    • Ta metoda umożliwia efektywne ponowne używanie kwerend ad hoc i ich planów.

    • Gdy używasz tej metody, nie trzeba utworzyć wpis TokenAccessResult każdym uruchomieniu kwerend ad hoc razem z różnymi parametrami.

    • Przy użyciu tej metody rozmiar pamięci podręcznej TokenAndPermUserStore pozostaje w rozsądnych granicach.

  • Zawijaj kwerend ad hoc w ramach procedur przechowywanych, a zamiast bezpośrednio wykonywanie kwerend ad hoc za pomocą procedur przechowywanych.


    Uwagi

    • Wykonanie planów są buforowane dla instrukcji, które znajdują się w procedurze przechowywanej.

    • Wpis TokenAccessResult dla każdego zestawienia jest skojarzony z wpisem planu wykonania.

    • Tak długo, jak długo plan wykonania dla tej przechowywana procedura pozostaje w pamięci podręcznej, co wykonanie procedury przechowywanej skutecznie ponownie używa wpisów TokenAccessResult. W związku z tym nie trzeba tworzyć nowe wpisy TokenAccessResult.

  • Włącz opcję bazy danych FORCE_PARAMETERIZATION.

    Uwagi

    • Ta metoda umożliwia efektywne ponowne używanie kwerend ad hoc i ich planów.

    • Gdy używasz tej metody, nie trzeba utworzyć wpis TokenAccessResult każdym uruchomieniu kwerend ad hoc razem z różnymi parametrami.

    • Przy użyciu tej metody rozmiar pamięci podręcznej TokenAndPermUserStore pozostaje w rozsądnych granicach.

  • Dodaj identyfikator logowania, który wykonuje różne kwerend ad hoc, jak członek grupy serwera sysadmin.

    Uwagi

    • TokenAccessResult wpisy są tworzone tylko dla kwerend ad hoc, gdy kwerenda jest wykonywana przez logowania, który nie jest członkiem grupy serwera sysadmin.

    • Ponieważ nie są tworzone wpisy TokenAccessResult, to zachowanie zachowuje rozmiar pamięci podręcznej TokenAndPermUserStore do rozmiaru w zarządzaniu.

  • Opróżnienie wpisów z pamięci podręcznej TokenAndPermUserStore.

    Uwagi

    • Aby to zrobić, uruchom następujące polecenie:

      DBCC FREESYSTEMCACHE (TokenAndPermUserStore)

    • W idealnej sytuacji spróbuj oglądać próg wielkości pamięci podręcznej TokenAndPermUserStore, gdy problemy zaczną się pojawiać.

    • Można utworzyć zaplanowane zadanie agenta programu SQL Server, który wykonuje następujące czynności:

      • Sprawdź rozmiar rozmiar pamięci podręcznej TokenAndPermUserStore. Aby to zrobić, uruchom następujące polecenie:

        SELECT SUM(single_pages_kb + multi_pages_kb) AS 
        "CurrentSizeOfTokenCache(kb)"
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • Jeśli rozmiar pamięci podręcznej jest większy niż próg, który należy przestrzegać, uruchom następujące polecenie:

        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Powiązane artykuły

Aby uzyskać więcej informacji kliknij następujące numery artykułów w celu wyświetlenia tych artykułów z bazy wiedzy Microsoft Knowledge Base:

NAPRAW 933564 : stopniowy wzrost zużycia pamięci dla magazynu pamięci podręcznej USERSTORE_TOKENPERM występuje w programie SQL Server 2005

Jak dostosować normy dla TokenAndPermUserStore magazynu pamięci podręcznej w dodatku Service Pack 3 dla programu SQL Server 2005 959823

Potrzebna dalsza pomoc?

Rozwijaj swoje umiejętności
Poznaj szkolenia
Uzyskuj nowe funkcje w pierwszej kolejności
Dołącz do niejawnych testerów firmy Microsoft

Czy te informacje były pomocne?

Jaka jest jakość języka?
Co wpłynęło na Twoje wrażenia?

Dziękujemy za opinię!

×