Início / dba / Perguntas / 149886
Accepted
Ste Bov
Asked: 2016-09-17 03:12:37 +0800 CST

Uso do espaço interno do TempDB crescendo lentamente do agente de serviços

  • 772

Estou executando SQL Server 2012 (11.0.6540.0)em um grupo de alta disponibilidade AO com outro servidor.

O uso do tempDB geralmente fica em torno de 819 MB (média de uma semana a partir de 2 semanas atrás), mas desde que fizemos um failover e um ciclo de patch, o tempDB começou a crescer gradualmente (nenhuma alteração de DDL foi feita neste período). Acabamos de fazer um failover de teste e movemos o tempDB para fora da unidade SAN conjunta à qual ambas as máquinas têm acesso (não queremos uma peça de hardware que possa derrubar nossa réplica primária e secundária).

O failover mais recente e a reinicialização da instância (para mover o tempDB) viram o salto de uso do tempDB para 6348 MB usados ​​e seu crescimento lento.

O crescimento está todo nos objetos internos que podem ser vistos usando:

SELECT   top 5 session_id, request_id, 
         SUM(internal_objects_alloc_page_count) AS request_internal_objects_alloc_page_count
FROM     sys.dm_db_task_space_usage 
GROUP BY session_id, request_id
ORDER BY request_internal_objects_alloc_page_count DESC

Analisando, tudo está sendo executado no spid 35 e 32, ambos relacionados ao service broker.

Eu dei uma olhada e há rumores de que isso se deve a WITH CLEANUPuma conversa indefinida, mas a palavra limpeza só aparece nos comentários, então estou confiante de que esse não é o problema.

Quando a instância voltou e assumiu o nó primário, o agente de serviços não estava funcionando, então eu precisei alternar todas as filas para o estado desabilitado e depois habilitado (tivemos que fazer isso uma vez antes de um ano atrás, mas não ver esta questão).

Uso do TempDB

Você pode ver aqui o uso no tempDB como está atualmente nos últimos 4 dias. a entrega desta manhã é a reinicialização da instância e os failovers.

Alguém sabe o que estou perdendo para colocar isso de volta sob controle.

sql-server sql-server-2012

1 respostas

  1. Best Answer

    TLDR; Verifique se as conversas estão sendo deixadas completamente abertas.

    Em nosso sistema reutilizamos conversas e temos uma mesa dedicada a manter essas conversas que são usáveis, porém a equipe de desenvolvimento configurou um novo agente de serviço sem meu conhecimento há muito tempo enquanto eu estava fora, não configurou esses pontos de conversa e não não defina nenhum limite no alerta.

    Quando o novo sistema é ativado, as conversas estão sendo abertas, mas não fechadas corretamente e, como não há nenhuma no pool, é apenas criar uma nova conversa (chegamos a 7,1 milhões de conversas para um agente de serviço)

    Minhas etapas para consertar foram criar e registrar os 20 manipuladores de conversa que eu preciso para aquele agente de serviços e gravá-los em nossa tabela. Isso interrompeu o crescimento do tempDB para impedir o risco de o banco de dados cair.

    Então veio o longo processo de encerrar todas as conversas não usadas

    select 
    se.[conversation_handle] 
from 
    sys.conversation_endpoints se with (nolock) 
    left outer join [queue].[maintained_Conversations] qh with (nolock) on qh.[conversation_handle] = se.[conversation_handle]
where 
    qh.service_name is not null 
    and se.far_service = @service

    Dá a lista de todos os IDs do cursor por esses valores e simplesmente executa END CONVERSATION @id;em cada um deles.

    Depois que o processo terminar, o espaço temporário do banco de dados ficará mais solto (observe que não faz isso quando você os fecha, parece fazê-lo em grandes blocos quando você não está mais trabalhando para criá-los / finalizá-los (não posso garantir que isso seja como funciona, apenas o que observei depois de interromper o processo no meio e o tempDB recuperando algum espaço)

    • 0

relate perguntas