Commande SQL Server rétractable 'estimated_completion_time "continue de monter
Exécution SQL 2012 R2 ...
Microsoft SQL Server 2014 (SP2-GDR) (KB4019093) - 12.0.5207.0 (X64) édition standard (64 bits)
A couru la commande rétractable
DBCC SHRINKDATABASE(databaseNameHere)
(Oui, je sais que cela ne devrait pas être fait régulièrement, si jamais ... nous avons une base de données de 200 Go et éclaircie de nombreuses années de données et devraient pouvoir récupérer environ 100 Go d'espace)
Lorsque j'ai vérifié l'état de la tâche à 1,5 heure, c'était 49.1xxx percent_complete.
Cela fonctionne pendant 2,5 heures ... et maintenant à 49.5xxx percent_complete.
De plus, juste au cours des 20 dernières minutes, le estimated_completion_time (trouvé dans sys.dm_exec_requests) est passé de 8 741 035 millisecondes à 9 385 086 millisecondes ...
Il y a toujours une tonne d'espace disponible sur le lecteur. C'est une base de données de développement/test que personne n'utilise ... alors quelle est la transaction? Pourquoi le temps estimé continue-t-il à augmenter?
J'utilise sp_who2 active Pour vérifier qu'il n'y a pas de blocs ...
SHRINKDATABASE et SHRINKFILE _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ne libérera pas l'espace sur le disque jusqu'au dernier moment: il doit déplacer tout le contenu dans les fichiers d'abord (qui est la partie qui prend beaucoup de temps ).
Pour la raison pour laquelle les progrès ne semblent pas constants: l'espace libre/usagé est étalé dans un fichier volumineux, il va donc "sauter à l'avance" lorsqu'il rencontre un patch vide et "ralentir" quand il frappe une section d'utilisée pages.
Comme mentionné dans les commentaires, je vous recommande vivement d'utiliser SHRINKFILE au lieu de SHRINKDATABASE, car vous pouvez contrôler les tailles cible de chaque fichier individuel et donner à chacun une cible raisonnable. Par exemple, j'essaie habituellement de laisser 15 à 25% d'espace libre dans chaque fichier de données.