Pourquoi le statut "DbccFilesCompact" est-il "Suspendu"?

J'exécute le fichier SHRINK sur un fichier de données 600G.

Actuellement, le statut est signalé comme "suspendu" et sys.dm_exec_requests.percent_completepour les DbccFilesCompactrapports de commande, il s'exécute (mais très lentement)

Existe-t-il un moyen de vérifier pourquoi il est suspendu et comment le rendre plus fluide?

FYI - Requête SQL pour vérifier l'état

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

Non, vous ne pouvez pas vérifier pourquoi cela fonctionne lentement, mais je peux vous donner quelques indices:

1) Dans SQL 2005, la gestion des index non clusterisés est passée du moteur de stockage (mon équipe) au processeur de requêtes. Cela a de nombreux effets secondaires, dont la vitesse à laquelle les pages de données de tas peuvent être déplacées par rétrécissement. Tous les enregistrements d'index non cluster contiennent un lien retour vers l'enregistrement de données qu'ils indexent - dans le cas d'un segment de mémoire, il s'agit d'un lien physique vers un numéro d'enregistrement sur une page de données spécifique. Lorsqu'une page de données de segment de mémoire est déplacée par réduction, tous les enregistrements d'index non cluster qui font un lien vers les enregistrements de cette page doivent être mis à jour avec le nouvel emplacement de la page. En 2000, cela a été fait très efficacement par le moteur de stockage lui-même. À partir de 2005, cela doit être fait en appelant le processeur de requêtes pour mettre à jour les enregistrements d'index non cluster. C'est parfois jusqu'à 100 fois plus lent qu'en 2000.

2) Les valeurs LOB hors ligne (types de données LOB réels ou données de dépassement de ligne) ne contiennent pas de lien retour vers les données ou l'enregistrement d'index dont elles font partie. Lorsqu'une page d'enregistrements LOB est déplacée, l'ensemble de la table ou de l'index dont ils font partie doit être analysé pour déterminer quels enregistrements d'index / données pointent vers eux, afin qu'ils puissent être mis à jour avec le nouvel emplacement. C'est aussi très, très lent.

3) Il peut y avoir un autre processus utilisant la base de données qui provoque le blocage du rétrécissement en attendant les verrous dont il a besoin pour déplacer les pages.

4) L'isolation des instantanés peut être activée et la réduction ne peut pas déplacer les pages avec des liens de magasin de versions tant que les transactions nécessitant ces anciennes versions ne sont pas terminées.

5) Votre sous-système d'E / S est peut-être sous-alimenté. Une longueur de file d'attente de disque supérieure à un seul chiffre bas signifie que votre sous-système d'E / S est dans le goulot d'étranglement.

Tout ou partie de ces éléments pourraient contribuer à ralentir les temps de rétrécissement.

En général, cependant, vous ne voulez pas exécuter de réduction. Voir cet article de blog pour plus de détails: Pourquoi vous ne devriez pas réduire vos fichiers de données .

J'espère que cela t'aides!

Vous pouvez exécuter ce script pour vérifier le pourcentage achevé!

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

Je réduis une base de données dans SQL Server 2008 SP1 et une façon dont je peux dire la progression de la commande Shrink est d'exécuter sp_lock spid et pour la plupart je peux voir qu'il met un verrou sur le fichier 1 puis une fois terminé, il place un verrouiller l'ID de fichier 2, etc.

Merci,

Alex Aguilar

J'ai découvert quel était le problème (dans mon cas) et je vous propose ici la solution que j'ai utilisée.

Je n'avais rien en utilisant la base de données, et master était la base de données par défaut sur ma session, j'ai vérifié cela en utilisant sp_who2. Ensuite, j'ai fait un clic droit sur la base de données, sélectionnez "tâches" puis "réduire" et "ok" la boîte de dialogue. En recommençant avec sp_who2, le statut est "suspendu" de plusieurs minutes et après cela abandonné car "aucun verrou exclusif ne peut être obtenu". Devinez-vous, mais je suis sûr que le dialogue lui-même est celui qui cause cela.

J'ai donc décidé de passer par la ligne de commande en utilisant:

DBCC SHRINKDATABASE (myDataBase)

(La sorcière est partout documentée), puis le rétrécissement n'a pris que quelques secondes.