Eu tenho muitos arquivos de dados secundários (.ndf) criados para tempdb. Para remover os arquivos em excesso, preciso esvaziá-lo (o conteúdo será movido para outros arquivos):
DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);e exclua o arquivo:
ALTER DATABASE tempdb REMOVE FILE tempdbfile8;Mas o EMPTYFILEcomando retorna o erro:
DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.Não se preocupe, só preciso localizar o objeto que está usando esta página para fazer algo a respeito:
DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920O comando retorna muitas informações, object_id entre elas. Mas:
Metadata: ObjectId = 0 Não tenho ideia do que fazer sobre isso. Que gato está impedindo que esta página seja movida? Como localizar esse objeto, processo, sessão ou o que for? Qualquer ajuda será apreciada, mas observe que deixar tudo como está ou remover outro arquivo não é uma solução válida para esse problema;).
EDITAR:
Estou removendo os arquivos, porque seguíamos as "práticas recomendadas" de criar um arquivo por núcleo do processador (mesmo tamanho inicial, mesma taxa de crescimento). Mas até onde eu sei, até que você tenha problemas de contenção, não há sentido em criar arquivos tempdb adicionais no mesmo dispositivo. No nosso caso, faz sentido, porque temos o MPIO ativado e o dispositivo de armazenamento pode lidar com quatro caminhos. Mas houve um erro e acabamos com um total de 5 arquivos com uma CPU de 6 núcleos. É mais que caminhos MPIO, menos que núcleos de CPU e não é um número par. Pode não causar problemas, mas simplesmente não parece certo :).
Finalmente, consegui esvaziar e remover o arquivo sem reiniciar o servidor, definindo um dos bancos de dados (que suspeitava causar o problema) para o modo de usuário único (reversão imediata). Funcionou, mas tive sorte. O que eu realmente quero é ser sempre capaz de rastrear a página :).
fonte
dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Sobre sua solução: funcionaria, mas eu realmente gostaria de fazer isso sem interromper a instância.Respostas:
Reiniciar o servidor deve ser suficiente - essas tabelas de trabalho devem ser limpas. Mas eu provavelmente o inicializaria no modo de usuário único (-m) para impedir que outros processos criem tabelas de trabalho antes de remover esses arquivos com êxito. Redefina os arquivos necessários para
tempdb; talvez excluindo arquivos desnecessários, alterando tamanhos, etc. Você também deve garantir que tenha um número par de arquivos, que todos estejam configurados para o mesmo tamanho e que tenham as mesmas configurações de crescimento automático (em MB, não em%). E pode ser um bom momento para considerar também o TF 1117 e o TF 1118 ( ponto de partida ).Eu ficaria muito cauteloso com a sugestão de excluir os arquivos do sistema de arquivos antes de iniciar o SQL Server novamente - ele pode não ser iniciado.
(Eu também ficaria curioso sobre qual é o problema real. Ter muitos arquivos não machuca você realmente.)
fonte
https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- a-work-table-page? forum = sqldatabaseengine
Conforme proposto por Mike no fórum msdn, as tabelas de trabalho estão principalmente associadas ao cache do plano. Limpá-los também removeria a mesa de trabalho e você poderá encolher o Tempdb. Isso funcionou para mim. E isso poupa também a reinicialização do servidor. Haverá alguma sobrecarga, pois o SQL Server precisará recriar os planos de execução novamente.
fonte