Por que o status “DbccFilesCompact” é “Suspenso”?

Question

Estou executando o arquivo SHRINK em um arquivo de dados 600G.

Atualmente, o status é relatado como "suspenso" e sys.dm_exec_requests.percent_complete para o comando DbccFilesCompact relata que está em execução (mas muito lentamente)

Existe uma maneira de verificar por que ele está sendo suspenso e como fazê-lo funcionar mais suavemente?

FYI - Consulta SQL para verificação de status

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

    

Answer 1

Não, você não pode verificar porque está indo devagar, mas posso dar algumas dicas:

1) No SQL 2005, o gerenciamento de índices não-clusterizados foi alterado do Mecanismo de Armazenamento (minha equipe) para o Processador de Consultas. Isso tem muitos efeitos colaterais, um dos quais é a velocidade com a qual as páginas de dados de heap podem ser movidas por encolher. Todos os registros de índice não-clusterizados contêm um backlink para o registro de dados que estão indexando - no caso de um heap, esse é um link físico para um número de registro em uma página de dados específica. Quando uma página de dados de heap é movida por redução, todos os registros de índice não-clusterizados que fazem backlink para registros nessa página devem ser atualizados com o novo local da página. Em 2000, isso foi feito de forma muito eficiente pelo próprio mecanismo de armazenamento. Em 2005, isso deve ser feito chamando o Processador de Consulta para atualizar os registros de índice não-clusterizados. Isso às vezes é até 100 vezes mais lento do que em 2000.

2) Os valores de LOB fora de linha (tipos de dados de LOB reais ou dados de estouro de linha) não contêm um backlink para os dados ou registro de índice dos quais fazem parte. Quando uma página de registros LOB é movida, toda a tabela ou índice dos quais fazem parte deve ser verificada para descobrir qual registro de dados / índices aponta para eles, para que possam ser atualizados com o novo local. Isso também é muito, muito lento.

3) Pode haver outro processo usando o banco de dados que está causando o bloqueio para bloquear a espera pelos bloqueios necessários para mover as páginas.

4) É possível que o isolamento de instantâneo esteja ativado e o recurso de redução não pode mover páginas com links de armazenamento de versão até que as transações que exigem essas versões mais antigas sejam concluídas.

5) Seu subsistema de E / S pode estar com pouca potência. Um comprimento de fila de disco maior que um dígito único significa o seu subsistema de E / S no afunilamento.

Qualquer um ou todos eles podem estar contribuindo para atrasar o tempo de execução do psiquiatra.

Em geral, você não quer executar o encolhimento. Veja este post para mais detalhes: Por que você deveria não encolha seus arquivos de dados .

Espero que isso ajude!

    

Answer 2

Você pode executar este script para verificar a porcentagem concluída!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

    

Answer 3

Estou encolhendo um banco de dados no SQL Server 2008 SP1 e uma maneira que eu posso dizer o progresso do comando Shrink está executando sp_lock spid e para a maior parte eu posso ver que ele coloca um bloqueio no arquivo 1, em seguida, quando feito ele coloca um bloqueio no ID do arquivo 2, e assim por diante, e desta forma eu posso dizer quando ele está trabalhando no último id do arquivo e esta é a minha indicação de que ele está quase completo.

Obrigado,

Alex Aguilar

    

Answer 4

Descobri qual foi o problema (no meu caso) e ofereço aqui a solução que usei.

Eu não tinha nada usando o banco de dados, e master era o banco de dados padrão na minha sessão, eu verifiquei que usando sp_who2. Então eu cliquei direito no banco de dados, selecione "tarefas" e depois "encolher" e em "ok" a caixa de diálogo. Cheking novamente com sp_who2, o status é "suspenso" por vários minutos e depois disso abortado porque "nenhum bloqueio exclusivo pode ser obtido". Adivinhe-se, mas tenho certeza de que o diálogo em si é o que causa isso.

Então decidi usar a linha de comando usando:

DBCC SHRINKDATABASE (myDataBase)

(Witch está documentado em todos os lugares), Então o psiquiatra levou apenas alguns segundos.