O TempDB não encolherá. Nenhuma transação aberta

Eu tenho um TempDB no SQL 2008 que ficou muito grande (> 40gb) e quero diminuí-lo. Eu usei o dbcc shrinkdatabase, dbcc shrinkfile e o comando shrink através do Management Studio.

Estou tendo o erro a seguir:

Página 1: 4573184 não pôde ser movida porque é uma página da tabela de trabalho.

Consegui recuperar algum espaço para me livrar do perigo executando o DBCC FREEPROCCACHE e executando uma das rotinas de redução, mas obviamente isso não é o ideal e provavelmente só me comprará um pouco de tempo.

Eu executei o DBCC OpenTran e não há nada lá fora.

Em todos os lugares que li na internet se resume à reciclagem do SQL Server ... certamente tem que haver uma maneira melhor ... de alguém?

Obrigado,

Tom

Nota: esta postagem também pode ser útil:

Problemas com o arquivo mdf TempDB cada vez maior

A menos que você possa descobrir qual processo está usando essa tabela de trabalho (e pode matá-la com segurança), eu teria que concordar com o que suas pesquisas já produziram: alterne o servidor e você poderá reduzir o tempdb.

Uma pergunta diferente tratou de descobrir isso nas tabelas #temp; Não sei se ele pode ser adaptado para mesas de trabalho:

Encontre qual sessão está mantendo qual tabela temporária

Também escrevi em blog (novamente, para #temp tables):

http://sqlperformance.com/2014/05/t-sql-queries/dude-who-owns-that-temp-table

Duvido que a tabela de trabalho esteja relacionada ao armazenamento de isolamento / versão de instantâneo, mas apenas no caso de:

Encontre transações que estão preenchendo o armazenamento de versão

Além disso, não confie DBCC OPENTRAN;- observei muitos cenários em que sei que tenho uma transação ativa, mas ela não aparece lá. E observe que o contexto do banco de dados é importante; o banco de dados em que a transação está ativa não é necessariamente tempdb. O que você vê aqui? Qualquer coisa?

SELECT * FROM sys.dm_tran_active_transactions
  WHERE name = N'worktable';

Depois de reduzir o tempdb

Obviamente, essa não é uma solução permanente. Você vai encolher o tempdb e depois crescerá novamente. Isso pode se tornar muito chato e entediante para jogar este jogo toda vez que isso acontece. E se ele crescer novamente, o que você fará com esse espaço livre nesse meio tempo? Alugue e despeje as pessoas quando o tempdb precisar dele novamente? Você precisa:

1. Corrija o processo que está fazendo o tempdb crescer anormalmente grande em primeiro lugar.
2. Aloque espaço suficiente para o tempdb para que ele não precise crescer e pare de reduzi-lo (especialmente se apenas temporariamente; isso é apenas desperdício de trabalho!).

Algumas outras sugestões:

• Não use SHRINKDATABASE(que deve ser chamado de fragmento automático) ou a interface do usuário. Escreva SHRINKFILEcomandos específicos e direcionados para afetar arquivos individuais.
• Considere usar vários arquivos para tempdb (que você pode espalhar para armazenamento diferente, se / quando possível) e considere sinalizadores de rastreamento 1117 (desde que esse comportamento não afete também os bancos de dados do usuário) e 1118.
• Algumas dicas sobre como minimizar a utilização do tempdb aqui:
  • Como identificar qual consulta está preenchendo o log de transações tempdb?

Em todos os lugares que li na internet se resume à reciclagem do SQL Server ... certamente tem que haver uma maneira melhor ... de alguém?

Não, esta é uma solução temporária. Eu acho que você postou a mesma pergunta antes, por favor, diga qual é o tamanho total do banco de dados que você possui na sua instância do SQL Server. O tamanho do tempdb depende de quanto suas consultas o estão usando. Ele não pode crescer sozinho, a menos que você o use. Os links compartilhados pelo Aron ajudariam, mas você precisará ajustar as consultas se elas estiverem usando muito o temdbb ou se esse for o requisito padrão do seu ambiente. Eu tenho visto poucos env. onde 200 G de tempdb eram aceitáveis ​​porque as consultas exigiam uma quantidade grande de espaço no tempdb.