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

9

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

sql-server-2008 tempdb shrink user45117
fonte

Respostas:

7

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:
Aaron Bertrand
fonte
11
SELECT * FROM sys.dm_tran_active_transactions WHERE nome = N'worktable '; retorna 6 linhas, todas da mesma data (10/10/14). O transaction_id representa o SPID?
user45117
Não, transaction_id não é SPID. Se as transações estiverem realmente ativas (e não forem transações do sistema ), você poderá corresponder a um session_id em sys.dm_tran_session_transactions. De qualquer forma, você tem certeza de que esta é a mensagem que está recebendo do DBCC SHRINKFILE? E quanto a ALTER DATABASE ... MODIFY FILE? Também não sei ao certo por que a limpeza do cache de procedimentos o deixou com problemas; cache de procedimento está na memória, não em tempdb ...
Aaron Bertrand
A mensagem veio do DBCC SHRINKDATABASE. Eu não tentei o ALTER DATABASE ... MODIFY FILE ... que será o próximo. A limpeza do cache do procedimento permitiu que o tempdb fosse reduzido em aproximadamente 10% e me devolveu 4 GB de espaço em disco. Eu não era capaz de ligar os transaction_id de sys.dm_tran_active_transactions a qualquer coisa em sys.dm_tran_session_transactions
user45117
11
Eu acho que limpar o cache do procedimento estava menos relacionado a "permitir" que o tempdb diminuísse do que você pensa. Coincidências acontecem o tempo todo.
Aaron Bertrand
0

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.

Shanky
fonte