Limpeza fantasma

Question

minha compreensão do processo de limpeza fantasma é que a cada cinco segundos ele procurará remover os registros fantasma em um índice. e assim não sobrecarregará o sistema, ele apenas "limpará" aproximadamente dez páginas de cada vez.

Então, isso significa que apenas limpa cerca de 80k de registros a cada cinco segundos? Parece que meus índices sempre seriam preenchidos com registros fantasmas e a limpeza nunca terminaria.

Então, digamos que eu execute uma exclusão, talvez um milhão de linhas, e os registros de índice para essas milhões de linhas tenham aproximadamente 8 GB de tamanho. tão aproximadamente 100.000 vezes a diferença de 80k. Isso significa que o processo de limpeza do fantasma levará 500.000 ou quase seis dias para ser concluído?

claramente eu estou perdendo alguma coisa aqui, porque não faz sentido que levaria tanto tempo para limpar os registros fantasmas. e a outra atividade que atinge o mesmo índice? o processo de limpeza fantasma causa a espera ou tem que esperar por outros processos?

[essa questão foi gerada por problemas de desempenho que temos visto no OpsMgrDW e queríamos saber mais sobre esse processo]

    

Answer 1

Eu escrevi dois posts abrangentes que explicam a limpeza de fantasmas (é o único lugar explicado em profundidade em qualquer lugar, seja impresso ou online).

O primeiro deles é Inside the Storage Mecanismo: Limpeza do Ghost em profundidade e o segundo é Redux do cleanup do Ghost . Sim, 10 páginas todas as vezes, e é possível que a tarefa de limpeza fantasma nunca alcance o alto volume de exclusões contínuas.

A limpeza de fantasmas, além das 10 páginas a cada 5 segundos, pode ser acionada de forma agressiva, garantindo que o mecanismo de armazenamento 'veja' os registros fantasmas. Forçar uma verificação da tabela ou índice afetado usando algo como

selecione * em [tabela de problemas] com (índice = índice de problemas)

Isso enfileira uma solicitação para limpar os registros fantasmas de forma agressiva. Cuidado, porém, que irá gerar muito log de transações enquanto ele faz isso. Eles também devem ser removidos por recondicionamentos de índice ou reorganizados como parte da manutenção regular do índice.

Espero que isso ajude.

    

Answer 2

Sempre achei que as reconstruções de índice "corrigiriam" os problemas restantes quando as estruturas forem alteradas.

    

Answer 3

Há alguns anos, me deparei com esse problema e não consegui consertá-lo por meio da configuração, provocando a limpeza fantasma ou qualquer outra coisa desse tipo. Eu estava trabalhando com um banco de dados que tinha inserções e exclusões continuamente e SQLServer seria efetivamente travar periodicamente devido ao disparo fantasma de limpeza.

Minha solução final foi particionar as tabelas de problemas pelo tempo e, em vez de excluir linhas antigas, eu poderia simplesmente descartar as tabelas antigas. Isso ajudou imensamente. Isso pode não ser viável para sua situação, mas se aplica a muitos, com alguma variação.

    

Answer 4

temos situação semelhante. Uma de nossas tabelas tem muitos registros fantasmas e esses registros não são limpos pelo processo de limpeza do Ghost. Encolhimento de DB, DBCC Cleantable, Reconstrução do índice e Reorganização do índice não tem uso. Para resolver isso, nós transferimos dados para a tabela temporária e, em seguida, trucamos a tabela e traçamos os dados de volta para a tabela truncada. Esta tabela contém dados LOB (2 colunas nvarchar (max)). Existe alguma outra maneira de corrigir isso?