Question Ghost Cleanup


D'après ce que je comprends du processus de nettoyage des images fantômes, toutes les cinq secondes, il cherchera à supprimer les enregistrements fantômes d'un index. et afin de ne pas surcharger le système, il ne «nettoiera» qu’une dizaine de pages à la fois.

Donc, cela signifie que cela ne nettoie qu'environ 80 000 $ de disques toutes les cinq secondes? semble que mes index seraient toujours remplis de disques fantômes et que le nettoyage ne se terminerait jamais.

alors, disons que je lance une suppression, peut-être un million de lignes, et que les enregistrements d'index de ces millions de lignes ont une taille d'environ 8 Go. donc environ 100 000 fois la différence de 80 000 $. Cela signifie-t-il que le processus de nettoyage des fantômes prendra 500 000 secondes, soit presque six jours?

Il est clair que quelque chose me manque ici, car il n’a pas de sens que cela prendrait autant de temps pour effacer les disques fantômes. et qu'en est-il de l'autre activité qui atteint ce même indice? le processus de nettoyage des images fantômes provoque-t-il des attentes ou doit-il attendre d'autres processus?

[Cette question soulevée par des problèmes de performances que nous avons rencontrés dans OpsMgrDW et que nous voulions en savoir plus sur ce processus]


7
2018-06-10 16:01


origine




Réponses:


J'ai écrit deux articles de blog détaillés expliquant le nettoyage des fantômes (c'est le seul endroit où il est expliqué en profondeur, que ce soit en version imprimée ou en ligne).

Le premier est À l'intérieur du moteur de stockage: nettoyage en profondeur de Ghost et le second est Nettoyage fantôme redux. Oui, 10 pages à chaque fois et il est possible que la tâche de nettoyage des images fantômes ne rattrape jamais le nombre de suppressions en continu.

Le nettoyage des images fantômes en dehors des 10 pages toutes les 5 secondes peut être déclenché de manière agressive en s'assurant que le moteur de stockage "voit" les enregistrements fantômes. Forcer un scan de la table ou de l'index affecté en utilisant quelque chose comme

sélectionnez * de [problem-table] avec (index = problem-index)

Cela mettra en file d'attente une demande de nettoyage agressif des enregistrements fantômes. Attention cependant, il générera beaucoup de journaux de transactions pendant qu'il le fait. Ils doivent également être effacés par les reconstructions d'index ou les réorganisations dans le cadre de la maintenance régulière de l'index.

J'espère que cela t'aides.


4
2018-06-10 22:18





J'ai toujours pensé que la reconstruction d'index "résoudrait" tous les problèmes en suspens lorsque les structures seraient déplacées.


2
2018-06-10 16:38





Il y a quelques années, j'ai rencontré ce problème et je n'ai pas été en mesure de résoudre le problème via la configuration, ce qui a déclenché le nettoyage des images fantômes ou quelque chose du genre. Je travaillais avec une base de données qui comportait des insertions et des suppressions en continu, et SQLServer se bloquait de temps en temps en raison du déclenchement du nettoyage fantôme.

Ma solution éventuelle consistait à partitionner les tables de problèmes par heure et, au lieu de supprimer les anciennes lignes, je pouvais simplement supprimer les anciennes tables. Cela a énormément aidé. Cela peut ne pas être faisable pour votre situation, mais cela s'applique à beaucoup, avec quelques variantes.


2
2018-06-10 22:33



c'est intéressant. OpsMgr essaie également de supprimer des tables, mais nous voyons régulièrement des conflits avec le nettoyage des images fantômes. - SQLRockstar
Yup - le partitionnement est toujours une meilleure solution (en théorie) que les suppressions massives, mais il est généralement impossible de l'implémenter. La plupart des outils tiers ne la prennent pas en charge car cela peut modifier les caractéristiques d'interrogation de la charge de travail et peut entraîner des problèmes de blocage. - Paul Randal


nous avons une situation similaire. Une de nos tables contient de nombreux enregistrements fantômes et ceux-ci ne sont pas nettoyés par le processus de nettoyage Ghost. DB Shrinking, DBCC Cleantable, la reconstruction de l'index et la réorganisation de l'index sont inutiles. Pour résoudre ce problème, nous transférons les données dans une table temporaire, puis analysons la table et transférons les données dans une table tronquée. Cette table contient les données LOB (2 colonnes nvarchar (max)). Y at-il un autre moyen de résoudre ce problème?


2