CORRECÇÃO: Um aumento gradual do consumo de memória para o arquivo de cache USERSTORE_TOKENPERM ocorre no SQL Server 2005

Este artigo descreve os seguintes sobre esta versão de correcção:

• Os problemas corrigidos por este pacote de correcção
• Pré-requisitos para aplicar o pacote de correcções
• Se é necessário reiniciar o computador depois de aplicar o pacote de correcções
• Se o pacote de correcções é substituído por qualquer outro pacote de correcção
• Se deve efectuar quaisquer alterações de registo depois de aplicar o pacote de correcções
• Os ficheiros contidos no pacote de correcção

Quando uma aplicação personalizada que está a ser executado no Microsoft SQL Server 2005 utiliza funcionalidades que accionam alterações na base de dados frequente protecção carimbo de data/hora, um aumento gradual do consumo de memória para o arquivo de cache USERSTORE_TOKENPERM ocorre. Além disso, muitos movimentos TokenAccessResult duplicados têm uma classe de 65535 na vista de gestão dinâmica sys.dm_os_memory_cache_entries.

Para obter mais informações sobre o problema e sobre as condições que provocam protecção alterações de carimbo de data/hora para uma base de dados, consulte a secção "Mais informação".

Este problema ocorre porque a verificação de permissão cumulativa de uma consulta é armazenada no arquivo de cache USERSTORE_TOKENPERM como uma entrada de TokenAccessResult com uma classe de 65535. Entradas TokenAccessResult utilizam o carimbo de data/hora de protecção para determinar se ocorreram alterações de segurança que invalida a entrada da cache. Sempre que altera o carimbo de data/hora de protecção, as entradas de cache antiga não podem ser reutilizadas uma vez que as entradas antigas podem não ser actuais. Por conseguinte, tem de ser introduzida uma nova entrada de cache. No entanto, uma entrada antiga não é removida até que o SQL Server experiências pressão de memória. Este problema pode conduzir a um aumento do consumo de memória pelo arquivo de cache de USERSTORE_TOKENPERM.

Informações do Service Pack

Este problema foi 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 de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:

Informações sobre a correcção

Tem uma correcção suportada disponível na Microsoft. No entanto, esta correcção destina-se a corrigir o problema descrito neste artigo. Aplique esta correcção apenas em sistemas que tenham o problema descrito neste artigo. Esta correcção poderá ser submetida a testes adicionais. Por conseguinte, se não estiver a ser gravemente afectado por este problema, recomendamos que aguarde pela próxima actualização de software que contenha esta correcção.

Se a correcção está disponível para transferência, existe uma secção "denominada transferência de correcção disponível" na parte superior deste artigo da base de dados de conhecimento. Se esta secção não for apresentado, contacte o serviço de apoio a clientes da Microsoft e suporte para obter a correcção.

Nota Se ocorrerem problemas adicionais ou se for necessário efectuar algum procedimento para resolução de problemas, poderá ter de criar um pedido de assistência separado. Os custos normais do suporte serão aplicados a perguntas de suporte adicionais e problemas que não são elegíveis para esta correcção específica. Para obter uma lista completa dos números de telefone do serviço de apoio a clientes da Microsoft e suporte da ou para criar um pedido de assistência separado, visite o seguinte Web site da Microsoft: Nota O formulário "Transferência de correcção disponível" apresenta os idiomas para o qual a correcção está disponível. Se não vir o idioma, é porque uma correcção não está disponível para esse idioma.

Pré-requisitos

Tem de ter o Microsoft SQL Server 2005 Service Pack 2 (SP2) instalado para aplicar esta correcção.

Para obter mais informações sobre como obter o SQL Server 2005 Service Pack 2, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:

Informações sobre reinício

Não é necessário reiniciar o computador depois de aplicar esta correcção.

Informações de registo

Não é necessário alterar o registo.

Informações sobre os ficheiros da correcção

Esta correcção contém apenas os ficheiros que são necessárias para corrigir os problemas listados neste artigo. Esta correcção poderá não conter todos os ficheiros que necessita para actualizar completamente um produto para a compilação mais recente.

A versão inglesa desta correcção tem os atributos de ficheiro (ou atributos de ficheiro posteriores) listados na seguinte tabela. As datas e horas destes ficheiros são indicadas na hora universal coordenada (UTC). Quando visualiza as informações do ficheiro, são convertida para a hora local. Para determinar a diferença entre a UTC e a hora local, utilize o separador Fuso horário no item data e hora no painel de controlo.

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 secção "Aplica-se a".

Pode utilizar as seguintes duas consultas para determinar se tem este problema.

• Quando executa a consulta seguinte, notará esse consumo de memória pelos 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 executa a consulta seguinte, receberá muitas entradas na coluna Endereço de arquivo e na coluna ID:

  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 esta consulta não produz nenhum resultado, não tiver o problema descrito neste artigo.

Muitas condições alterar o carimbo de data/hora de protecção da base de dados. Por exemplo, a maior parte das operações de linguagem DDL (Data Definition Language) alterar o carimbo de data/hora de protecção.

A operação de DDL Criar tabela e o funcionamento de Drop Table DDL para tabelas temporárias altera a hora de protecção na base de dados tempdb.

As seguintes operações DDL são instruções Transact-SQL. Estas operações alterar a hora de protecção na base de dados principal:

• Criar o início de sessão
• Alterar o início de sessão
• Largue o início de sessão
• Criar o ponto final
• Alterar o ponto final
• Largue o ponto final

As seguintes operações DDL estão relacionados com objectos de utilizador, tais como o objecto de tabela. Estas operações alterar a protecção timestamp qualquer base de dados. Estas bases de dados incluem a base de dados principal e a base de dados tempdb.

• Criar
• Alterar
• Largar

As seguintes operações DDL estão relacionadas com segurança. Todas as operações relacionadas com segurança alterar a protecção timestamp qualquer base de dados. Estas bases de dados incluem a base de dados principal e a base de dados tempdb. A lista seguinte atribui alguns exemplos de operações DDL relacionadas com segurança.

• Criar
• Alterar
• Largar utilizador
• Função
• Função de aplicações
• Certificado
• Esquema
• Chaves simétricas
• Chaves assimétricas

Além disso, operações que conceder, revogar ou negar permissões num objecto estão relacionadas com segurança. Estas operações também alteram a protecção timestamp qualquer base de dados. Estas bases de dados incluem a base de dados principal e a base de dados tempdb.

Outras condições também podem causar a cache USERSTORE_TOKENPERM para aumentar ao longo do tempo. A correcção descrita neste artigo destina-se uma condição muito específica. Isto é, uma alteração no carimbo de data/hora protecção provoca o arquivo de cache a crescer. Para obter mais informações sobre a cache USERSTORE_TOKENPERM, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft: Depois de instalar esta correcção, é adicionado um novo atributo denominado carimbo de data/hora entry_data colunas na vista 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 é novamente compilado, o carimbo de data/hora é 1. Este valor é recalculado se o carimbo de data/hora de protecção for alterado. 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. Devem diminuir a frequência das consultas ad hoc ou das operações de recompilação. Em alternativa, pode resolver o problema mediante a aplicação de sinalizador de rastreamento 4618 para limitar o número de entradas por arquivo de cache do utilizador. Utilizar o sinalizador de rastreamento 4618 pode assumir uma CPU pequena sobrecarga porque este sinalizador de rastreio remove entradas de cache antigo, são inseridos novos movimentos. O sinalizador de rastreamento efectua esta acção para limitar o tamanho da cache de crescimento, arquivo. No entanto, a CPU sobrecarga é distribuída ao longo do tempo.

Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft: Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft: