Le Ghost Cleanup

Nous disposons de deux moyens nous permettant de suivre l’activité du Ghost Cleanup : le suivi de l’exécution du process lui-même et le trace flag 662.

Suivi du process Ghost Cleanup

Cette opération consiste à journaliser dans une table chaque apparition du Ghost Cleanup, ce qui permettra de constater s’il se déclenche. Voici pour cela un petit script qui répondra à nos besoins :

SELECT * INTO #T_GhostAudit FROM sys.dm_exec_requests  WHERE Session_id = 0
GO
DECLARE @Durée INT
DECLARE @HeureDebut DateTime

SELECT @Durée = 10 –durée d’exécution de la collecte, en seconde
SELECT @HeureDebut = GETDATE()

WHILE getdate() < DATEADD(SECOND, @Durée, @HeureDebut)
    INSERT INTO #T_GhostAudit SELECT * FROM sys.dm_exec_requests WHERE command LIKE ‘%Ghost%’
GO
SELECT * FROM #T_GhostAudit
GO
DROP TABLE #T_GhostAudit
GO

Lorsque le script se termine, vous devez obtenir un jeu de résultat équivalent à celui-ci :

(((IMG6250)))

On constate dans l’exemple ci-dessus que le process est bien actif.

Trace flag 662

Le second moyen consiste à écrire directement dans le journal SQL ce que fait le Ghost Cleanup lorsqu’il s’active, autrement dit, combien de Ghost records il supprime. Nous utiliserons pour cela le trace flag 662 : l’activation de ce trace flag (à manipuler avec précaution car non officiellement supporté) permet effectivement de journaliser dans la log SQL Server le travail du Ghost Cleanup. Après son activation, nous obtenons une succession de message dans la log sql du type :

‘Purged page Dbid 7, File 1, Page 656939, Records cleaned: 150’

Nous connaissons donc le nombre d’enregistrements supprimés, pour chaque page de chaque fichier de chaque base de données.

Avec ces deux outils, il est facile de déterminer si le Ghost Cleanup tourne ou pas, et s’il supprime effectivement des pages lorsqu’il travail.

Pour la petite histoire, dans le cas que j’ai rencontré, le Ghost Cleanup tournait effectivement, mais aucune activité n’était révélée dans la log malgré l’activation du trace flag 662. Ayant essayé différentes solution sans succès,  j’ai finalement passé le SP2, qui a effectivement solutionné le problème. Dès le redémarrage de l’instance, le Ghost Cleanup a commencé son travail et trois heures après, tous les Ghost records avaient disparus, la taille de la table était redevenue beaucoup plus raisonnable !

Pour aller plus loin

Sur certains systèmes très sollicités, le Ghost Cleanup peut être à l’origine de contention, du fait du surplus d’IO générés au moment de son action. Le trace flag 661, référencé dans la kb KB 920093, nous permet de le désactiver dans le but d’alléger le système. Mais attention et vous l’aurez compris, dans ce cas, l’espace occupé par les Ghost records ne sera pas automatiquement libéré.

Ce qui nous amène à nous demander : si l’on désactive le Ghost Cleanup, comment libérer l’espace occupé par les Ghosts record ? Deux solutions s’offrent à nous :

– Le rebuild des index concernés (rappelez-vous que les Ghost records ne concernent que les enregistrements sur des pages d’index)
– L’utilisation des procédures stockées  sp_clean_db_free_space et sp_clean_db_file_free_space qui ont pour effet de supprimer les Ghost records d’une base complète pour la première ou d’un fichier de données pour la deuxième.

Attention cependant, ces deux méthodes de suppression « manuelle » des Ghosts records sont très, très couteuses en I/O et sont donc à planifier en dehors des heures d’utilisation de la base.

Remerciement à Michel Degremont pour sa précieuse relecture.