Consultas levar mais tempo para concluir a execução quando o tamanho do cache TokenAndPermUserStore cresce no SQL Server 2005

• Consultas que normalmente executam mais rapidamente levar mais tempo para concluir a execução.
• Utilização da CPU para o processo do SQL Server é mais comum.
• Ao enfrentar uma redução no desempenho quando você executa uma consulta ad hoc, você exibir a consulta da exibição de gerenciamento dinâmico sys.dm_exec_requests ou sys.dm_os_waiting_tasks . No entanto, a consulta não parece estar aguardando a qualquer recurso.
• O tamanho do armazenamento de cache TokenAndPermUserStore cresce a uma taxa constante.
• O tamanho do armazenamento de cache TokenAndPermUserStore é na ordem de várias centenas megabytes (MB).
• Em alguns casos, a execução do comando DBCC FREEPROCCACHE fornece alívio temporário.

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

Voltar para o início

• LoginToken
• TokenPerm
• UserToken
• SecContextToken
• TokenAccessResult.

select * 
from t1 join t2 join t3

Voltar para o início

Informações sobre o service pack

Voltar para o início

• Parametrizar explicitamente consultas ad hoc.
  
  anotações
  • Esse método lhe permite reutilizar com eficiência consultas ad hoc e seus planos.
  • Quando você usa esse método, não é necessário criar uma entrada TokenAccessResult toda vez que executar a consulta ad hoc juntamente com parâmetros diferentes.
  • Com esse método, o tamanho do TokenAndPermUserStore cache permanece em limites razoáveis.
• Quebra automática de consultas ad hoc em procedimentos armazenados e use procedimentos armazenados em vez de diretamente executar consultas ad hoc.
  
  anotações
  • Planos de execução são armazenados em cache para as instruções no procedimento armazenado.
  • A entrada TokenAccessResult para cada instrução está associada com a entrada de plano de execução.
  • Desde que o plano de execução para isso armazenado procedimento permanece no cache, cada execução do procedimento armazenado efetivamente reutiliza as entradas TokenAccessResult. Portanto, não é necessário criar TokenAccessResult nova entradas.
• Habilite a opção de banco de dados FORCE_PARAMETERIZATION.
  
  anotações
  • Esse método lhe permite reutilizar com eficiência consultas ad hoc e seus planos.
  • Quando você usa esse método, não é necessário criar uma entrada TokenAccessResult toda vez que executar a consulta ad hoc juntamente com parâmetros diferentes.
  • Com esse método, o tamanho do TokenAndPermUserStore cache permanece em limites razoáveis.
• Adicione o logon executa variados consultas ad hoc como membro do grupo de servidor sysadmin.
  
  anotações
  • TokenAccessResult entradas são criadas somente para uma consulta ad hoc quando a consulta é executada por um logon não é um membro do grupo de servidor sysadmin.
  • Como as entradas TokenAccessResult não são criadas, esse comportamento mantém o tamanho do cache TokenAndPermUserStore para um tamanho gerenciável.
• Libere entradas do cache TokenAndPermUserStore.
  
  anotações
  • Para fazer isso, execute o seguinte comando:
    DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
  • Idealmente, tente assistir o limite do tamanho de cache TokenAndPermUserStore quando problemas começam a aparecer.
  • Você pode criar um trabalho agendado SQL Server Agent que executa as seguintes ações:
    • Verifique o tamanho do tamanho de cache TokenAndPermUserStore. Para fazer isso, execute o seguinte comando:

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

    • Se o tamanho do cache for maior que o limite que você observou, execute o seguinte comando:

      DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Voltar para o início