Perché lo stato "DbccFilesCompact" è "Sospeso"?

Sto eseguendo il file SHRINK su un file di dati 600G.

Attualmente, lo stato viene segnalato come "sospeso" e sys.dm_exec_requests.percent_completeper i DbccFilesCompactcomandi indica che è in esecuzione (ma molto lentamente)

C'è un modo per verificare perché è stato sospeso e come renderlo più fluido?

Cordiali saluti - Query SQL per il controllo dello stato

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

No, non puoi controllare perché sta funzionando lentamente, ma posso darti alcuni suggerimenti:

1) In SQL 2005, la gestione degli indici non cluster è cambiata dal motore di archiviazione (il mio team) al processore di query. Ciò ha molti effetti collaterali, uno dei quali è la velocità con cui le pagine di dati dell'heap possono essere spostate con una riduzione. Tutti i record di indice non cluster contengono un backlink al record di dati che stanno indicizzando: nel caso di un heap, si tratta di un collegamento fisico a un numero di record in una pagina di dati specifica. Quando una pagina di dati heap viene spostata per compattazione, tutti i record dell'indice non cluster che rimandano ai record in quella pagina devono essere aggiornati con la nuova posizione della pagina. Nel 2000 ciò è stato fatto in modo molto efficiente dal motore di archiviazione stesso. A partire dal 2005, ciò deve essere fatto chiamando il processore di query per aggiornare i record dell'indice non cluster. Questo a volte è fino a 100 volte più lento rispetto al 2000.

2) I valori LOB fuori riga (tipi di dati LOB effettivi o dati di overflow di riga) non contengono un backlink ai dati o al record dell'indice di cui fanno parte. Quando una pagina di record LOB viene spostata, l'intera tabella o indice di cui fanno parte deve essere scansionata per capire quale record di dati / indice punta a loro, in modo che possano essere aggiornati con la nuova posizione. Anche questo è molto, molto lento.

3) Potrebbe esserci un altro processo che utilizza il database che sta causando il blocco della riduzione in attesa dei blocchi necessari per spostare le pagine.

4) È possibile che sia abilitato l'isolamento dello snapshot e la riduzione non può spostare le pagine con collegamenti dell'archivio versione fino al completamento delle transazioni che richiedono quelle versioni precedenti.

5) Il sottosistema I / O potrebbe essere sottodimensionato. Una lunghezza della coda del disco superiore a singole cifre basse indica il sottosistema I / O nel collo di bottiglia.

Uno o tutti questi potrebbero contribuire a rallentare i tempi di riduzione.

In generale, tuttavia, non si desidera eseguire la riduzione. Vedi questo post del blog per i dettagli: Perché non dovresti ridurre i tuoi file di dati .

Spero che sia di aiuto!

Puoi eseguire questo script per verificare la percentuale completata!

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

Sto restringendo un database in SQL Server 2008 SP1 e un modo in cui posso dire che l'avanzamento del comando Riduci è eseguendo sp_lock spid e per la maggior parte vedo che mette un blocco sul file 1 quindi quando ha posto un bloccare l'ID file 2, e così via e in questo modo posso dire quando sta funzionando sull'ultimo ID file e questa è la mia indicazione che è quasi completa.

Grazie,

Alex Aguilar

Ho scoperto qual era il problema (nel mio caso) e offro qui la soluzione che ho usato.

Non avevo nulla usando il database e master era il database predefinito nella mia sessione, ho verificato che usando sp_who2. Quindi ho cliccato con il tasto destro sul database, ho selezionato "task" e poi "riduci" e su "ok" la finestra di dialogo. Rivolgendosi nuovamente a sp_who2, lo stato viene "sospeso" di alcuni minuti e successivamente interrotto perché "non è possibile ottenere un blocco esclusivo". Indovina te stesso, ma sono sicuro che il dialogo stesso sia quello che lo provoca.

Quindi ho deciso di passare dalla riga di comando usando:

DBCC SHRINKDATABASE (myDataBase)

(La strega è documentata dappertutto), poi la contrazione ha richiesto solo pochi secondi.