CORRECÇÃO: Um aumento gradual em consumo de memória de armazenamento de cache USERSTORE_TOKENPERM ocorre no SQL Server 2005

Este artigo descreve o seguinte sobre esta versão de hotfix:

• Problemas corrigidos por este pacote de hotfix
• Os pré-requisitos para aplicar o pacote de hotfix
• Se é necessário reiniciar o computador após aplicar o pacote de hotfix
• Se o pacote de hotfix é substituído por qualquer outro pacote de hotfix
• Se você deve fazer alterações no registro depois de aplicar o pacote de hotfix
• Arquivos que estão contidos no pacote de hotfix

Quando um aplicativo personalizado que está sendo executado no Microsoft SQL Server 2005 usa recursos que acionam alterações de carimbo de data/hora do banco de dados freqüentes proteção, ocorre um aumento gradual no consumo de memória para o armazenamento de cache USERSTORE_TOKENPERM. Além disso, muitas entradas duplicadas de TokenAccessResult tem uma classe de 65535 no modo de exibição de gerenciamento dinâmico sys.dm_os_memory_cache_entries.

Para obter mais informações sobre o problema e sobre as condições que causam alterações de carimbo de data/hora para um banco de dados de proteção, consulte a seção "Mais informação".

Esse problema ocorre porque a verificação de permissão cumulativa de uma consulta é armazenada no armazenamento de cache USERSTORE_TOKENPERM como uma entrada TokenAccessResult que tenha uma classe de 65535. Entradas TokenAccessResult usam o carimbo de data/hora proteção para determinar se ocorreram alterações de segurança que invalidaria a entrada de cache. Sempre que o carimbo de data/hora proteção for alterado, as entradas de cache anterior não podem ser reutilizadas porque as entradas antigas podem não ser atuais. Portanto, é preciso inserir uma nova entrada de cache. No entanto, uma entrada antiga não é removida até que o SQL Server enfrenta pressão da memória. Esse problema pode causar um aumento no consumo de memória pelo armazenamento de cache USERSTORE_TOKENPERM.

Informações do Service Pack

Esse problema é corrigido no SQL Server 2005 Service Pack 3. Para obter mais informações sobre como obter o SQL Server 2005 Service Pack 3, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

Informações sobre hotfix

Um hotfix compatível foi disponibilizado pela Microsoft. No entanto, esse hotfix destina-se a corrigir o problema descrito neste artigo. Aplique-o somente aos sistemas que apresentarem o problema descrito neste artigo. Este hotfix pode ser submetida a testes adicionais. Portanto, se esse problema não o prejudicar, recomendamos que você aguarde a próxima atualização de software que contém esse hotfix.

Se o hotfix está disponível para download, há uma seção "Download de Hotfix disponível" na parte superior deste artigo do Knowledge Base. Se esta seção não exibida, contate o suporte e atendimento ao cliente Microsoft para obter o hotfix.

Observação: Se ocorrem problemas adicionais ou se for necessária qualquer solução de problemas, talvez seja necessário criar uma solicitação de serviço separada. Os custos normais de suporte serão aplicados a questões de suporte adicionais e problemas que não se qualificam para esse hotfix específico. Para obter uma lista completa dos números de telefone de suporte e Atendimento Microsoft ou para criar uma solicitação de serviço separada, visite o seguinte site da Microsoft: Observação: O formulário "Download de Hotfix disponível" exibe os idiomas para os quais o hotfix está disponível. Se você não vir seu idioma, é porque não há um hotfix disponível disponível para esse idioma.

Pré-requisitos

Você deve ter o Microsoft SQL Server 2005 Service Pack 2 (SP2) instalado para aplicar esse hotfix.

Para obter mais informações sobre como obter o SQL Server 2005 Service Pack 2, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

Reiniciar informações

Não é necessário reiniciar o computador após aplicar esse hotfix.

Informações do registro

Não é necessário alterar o registro.

Informações sobre o arquivo de hotfix

Esse hotfix contém apenas os arquivos necessários para corrigir os problemas que este artigo lista. Esse hotfix não pode conter de todos os arquivos que você deve ter para actualizar completamente um produto para a compilação mais recente.

A versão em inglês deste hotfix apresenta os atributos de arquivo (ou atributos de arquivo posteriores) listados na tabela a seguir. As datas e horas desses arquivos são listadas em UTC (hora coordenada universal COORDENADO). Quando você exibe as informações do arquivo, ele é convertido em hora local. Para encontrar a diferença entre o UTC e a hora local, use a guia fuso horário no item Data e hora no painel de controle.

SQL Server 2005, versões de 32 bits

SQL Server 2005, versões de 64 bits

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".

Você pode usar consultas a seguir para determinar se você está enfrentando esse problema.

• Quando você executa a consulta a seguir, você observar esse consumo de memória, os aumentos de cache USERSTORE_TOKENPERM:

  select sum(single_pages_kb+multi_pages_kb) 'total memory for tokenperm' from sys.dm_os_memory_clerks where type = 'USERSTORE_TOKENPERM'

• Quando você executa a consulta a seguir, você recebe muitas entradas na coluna Endereço de armazenamento e na coluna identificação:

  select [Store Address], [id], count (*) 'number of entries'
  from  
  	(select 
  		 cast(entry_data as xml).value ('(//@store_address)[1]', 'varchar (100)') as [Store Address],
  		 cast(entry_data as xml).value ('(//@id)[1]', 'bigint') as [id]
  		 from sys.dm_os_memory_cache_entries
  		where type = 'USERSTORE_TOKENPERM' and cast(entry_data as xml).value ('(//@name)[1]', 'varchar (100)') = 'TokenAccessResult' and 
  			cast(entry_data as xml).value('(//@class)[1]', 'bigint') = 65535
  	) R 
  group by [Store Address], [id] 
  having count (*) > 1
  order by count (*) desc
  

  Se essa consulta não produz nenhum resultado, você não está enfrentando o problema descrito neste artigo.

Muitas condições de alterar o carimbo de hora de proteção de banco de dados. Por exemplo, a maioria das operações de DDL (linguagem de definição de dados) alterar o carimbo de data/hora proteção.

A operação de DDL Criar tabela e a operação do DDL Drop Table para tabelas temporárias altera o carimbo de data/hora de proteção no banco de dados tempdb.

As seguintes operações de DDL são instruções Transact-SQL. Essas operações alterar o carimbo de data/hora de proteção no banco de dados mestre:

• Criar login
• Alterar logon
• Cancelar o login
• Criar ponto de extremidade
• Alterar o ponto de extremidade
• Solte o ponto de extremidade

As operações de DDL a seguir estão relacionadas a objetos de usuário, como o objeto de tabela. Essas operações alterar o carimbo de data/hora de proteção em qualquer banco de dados. Esses bancos de dados incluem o banco de dados mestre e o banco de dados tempdb.

• Criar
• Alterar
• Para soltar

As operações de DDL a seguir estão relacionadas à segurança. Todas as operações relacionadas à segurança, altere o carimbo de data/hora de proteção em qualquer banco de dados. Esses bancos de dados incluem o banco de dados mestre e o banco de dados tempdb. A lista a seguir alguns exemplos de operações de DDL relacionadas à segurança de nomes.

• Criar
• Alterar
• Solte o usuário
• Função
• Função de aplicativo
• Certificado
• Esquema
• Chaves simétricas
• Chaves assimétricas

Além disso, as operações que conceda, revogar ou negar permissões de um objeto estão relacionadas à segurança. Essas operações também alteram o carimbo de data/hora de proteção em qualquer banco de dados. Esses bancos de dados incluem o banco de dados mestre e o banco de dados tempdb.

Outras condições também podem fazer com que o cache USERSTORE_TOKENPERM para crescer com o passar do tempo. A correção descrita neste artigo é uma condição muito específicas. Ou seja, uma alteração no carimbo de data/hora proteção faz com que o armazenamento de cache para crescer. Para obter mais informações sobre o cache USERSTORE_TOKENPERM, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: Depois de instalar esse hotfix, um novo atributo chamado carimbo de data/hora é adicionado ao entry_data colunas na exibição sys.dm_os_memory_cache_entries. Este atributo especifica o número de vezes que o SQL Server verifica as permissões em cada plano. Quando um plano recém compilado ou é recompilado, o carimbo de data/hora é 1. Esse valor é recalculado se altera o carimbo de data/hora proteção. You can use the following query to take snapshots of the timestamp:If over time you see many timestamps of 1 for each store_address column, an application has a high rate of ad hoc queries or of recompile operations. Você deve diminuir a taxa de consultas ad hoc ou de operações de recompilação. Como alternativa, você pode solucionar o problema aplicando o sinalizador de traço 4618 para limitar o número de entradas por armazenamento de cache do usuário. Usar o sinalizador de traço 4618 pode incorrer uma CPU pequena sobrecarga porque o sinalizador de traço remove entradas antigas de cache como novas entradas são inseridas. O sinalizador de rastreamento realiza essa ação para limitar o tamanho do cache de armazenamento de crescimento. No entanto, a sobrecarga da CPU é distribuída ao longo do tempo.

Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: