Existe uma maneira de limitar o intervalo de portas dinâmicas disponíveis para o SQL Server do lado do banco de dados ou do lado do servidor de banco de dados? Nosso SOP é usar portas estáticas no firewall da rede e um fornecedor está tendo problemas para bloquear suas portas. Teoricamente, se permitíssemos um intervalo de 1.000 portas dentro do intervalo dinâmico (49152–65535) no firewall, como eu limitaria o SQL Server para atribuir apenas uma porta dinâmica dentro desse intervalo?
Pelo que posso descobrir, o armazenamento de versões limpará apenas as versões anteriores à transação ativa mais antiga. Descrição: O banco de dados de transações mais antigo é específico ou o SQL Server manterá todas as versões, independente do banco de dados, se houver uma transação mais antiga ainda ativa, ponto final?
Histórico - SQL Server 2005 SP4 Enterprise hospedando cerca de 40 bancos de dados. Atualmente, o TempDB é de 102 GB, o armazenamento de versão é de cerca de 98 GB. Um dos aplicativos hospedados na instância do banco de dados tem uma transação aberta de 40 dias com base em sys.dm...database_transactions. Dois grandes bancos de dados separados tiveram uso extremamente pesado no mês passado e vimos um crescimento consistente do TempDB coincidindo com essas operações. Esperávamos algum crescimento. Não esperávamos que continuasse crescendo. Pergunta: As versões armazenadas no armazenamento de versões do TempDB desses dois bancos de dados separados ainda estão lá porque um terceiro banco de dados independente tem uma conexão de 40 dias e mostra um transaction_state aberto?
Perfmon counters: O armazenamento de versões está crescendo continuamente nas poucas horas que acompanhei esta manhã. A taxa de geração de versão AVG é de cerca de 30 kb/s, a taxa de limpeza de versão é de 0 kb/s.
Muito espaço deixado para o TempDB, há cerca de 300 GB de arquivos de dados totais para todos os bancos de dados do usuário, o TempDB cresceu em média 350 MB por dia para cada um de seus 8 arquivos de dados desde a última reinicialização. Esse comportamento é anormal e a investigação revelou o armazenamento de versão grande
Respostas para perguntas de comentários para não ter uma seção de comentários longa:
P: Por que crescimento automático no tempdb? R: O TempDB é configurado para inicializar em um tamanho que consideramos apropriado para a maior parte do tempo. Permitimos o crescimento automático para lidar com atividades anormais do banco de dados. Também monitoramos o crescimento automático.
P: Como você sabe que a transação está ativa e não apenas uma conexão ativa? A: transaction_state diz ativo em sys.dm_tran_active_snapshot_database_transactions e outras coisas. O Activity Monitor diz que cada conexão tem 1 transação aberta.
P: Por que seu aplicativo é tão estúpido? R: É de terceiros. Um dos muitos nesta instância. Não sei se o comportamento é anormal ou facilmente corrigido.
RESOLUÇÃO
A(s) transação(ões) aberta(s) impede(m) qualquer limpeza do armazenamento de versão, então Jon estava certo, a limpeza do armazenamento de versão é feita independentemente dos bancos de dados. O fechamento das transações ofensivas permitiu o início da limpeza do armazenamento de versão. A teoria atual por trás do porquê é de Jon Seigel
O armazenamento de versão só pode limpar versões com base na transação ativa mais antiga em toda a instância, para oferecer suporte ao uso de isolamento de instantâneo em nível de transação em vários bancos de dados simultaneamente.
Se alguém souber com certeza ou puder provar isso, por favor, faça
Pergunta referenciada: encontre-transações-que-estão-preenchendo-a-loja-de-versão
Documentos referenciados:
TempDB 2005 WP
Teratrax tuning tempDB
Idera Desmistifique Tempdb