Voici un problème rencontré chez un client sur System Center 2012 Operations Manager. Une alerte Partitioning and grooming has not completed recently se lève. Le grooming est une opération de maintenance sur la base de données opérationnelle visant à nettoyer les données ayant atteint la date limite de rétention. Les paramétrages de rétention sont définis dans Administration – Settings – Database Grooming.
Lorsque cette erreur se répète jour après jour, cela signifie que votre infrastructure ne fait plus le nettoyage nécessaire et que votre base de données grossit. Plus vous attendez, plus le problème devient difficile à gérer.
Pour comprendre le grooming, le produit exécute une première procédure stockée p_PartitioningAndGrooming. Cette dernière fait elle-même appel à deux autres procédures : p_Partitioning et p_Grooming. p_Partitioning regarde les paramétrages de la table PartitionAndGroomingSettings puis appelle la procédure p_PartitionObject pour chaque objet dont le champ est à IsPartitioned = 1.
En exécutant la requête suivante, vous obtenez les procédures stockées de grooming, le nombre de jour de rétention et la dernière date d’exécution :
select * from PartitioningAndGrooming
GroomingSproc |
DaysToKeep |
GroomingRunTime |
DataGroomedMaxTime |
NULL |
3 |
2014-11-28 12:30:16.597 |
2014-11-24 23:00:00.000 |
NULL |
3 |
2014-11-28 12:30:16.597 |
2014-11-24 23:53:33.000 |
p_AlertGrooming |
3 |
2014-11-28 12:30:22.187 |
2014-10-25 00:24:25.057 |
p_StateChangeEventGrooming |
3 |
2014-11-28 13:02:06.193 |
2014-10-25 00:29:52.310 |
p_MaintenanceModeHistoryGrooming |
3 |
2014-11-28 13:01:45.877 |
2014-10-24 22:03:22.840 |
p_AvailabilityHistoryGrooming |
3 |
2014-11-28 13:02:00.103 |
2014-10-25 00:18:38.420 |
p_JobStatusGrooming |
3 |
2014-11-28 13:00:46.630 |
2014-10-24 08:15:13.910 |
p_MonitoringJobStatusGrooming |
3 |
2014-11-28 13:01:01.437 |
2014-10-24 17:19:16.310 |
p_PerformanceSignatureGrooming |
1 |
2014-11-28 13:27:32.043 |
2013-07-17 00:00:00.000 |
p_PendingSdkDataSourceGrooming |
1 |
2013-07-17 00:00:00.000 |
2013-07-17 00:00:00.000 |
p_InternalJobHistoryGrooming |
60 |
2014-11-28 13:19:02.650 |
2013-07-17 00:00:00.000 |
p_EntityChangeLogGroom |
7 |
NULL |
NULL |
p_UserSettingsStoreGrooming |
60 |
NULL |
NULL |
p_TriggerEntityChangeLogStagedGrooming |
1 |
NULL |
NULL |
p_GroomTypeSpecificLogTables |
1 |
2014-04-28 00:00:00.000 |
2014-04-28 00:00:00.000 |
Si la date DataGroomedMaxTime et GroomingRunTime ont un écart en nombre de jours supérieur à DaysToKeep, alors vous avez en effet un problème.
La requête suivante permet d’avoir les derniers jobs de grooming et l’état d’exécution :
select * from InternalJobHistory order by InternalJobHistoryId DESC
TimeStarted |
TimeFinished |
StatusCode |
Command |
Comment |
2014-11-28 13:46:24.703 |
NULL |
0 |
Exec dbo.p_GroomChangeLogs 05CDEC95-786E-4D77-A8C0-EBEFCE505D42, 10080, , 10000 |
NULL |
2014-11-28 13:19:55.330 |
2014-11-28 13:20:16.887 |
1 |
Exec dbo.p_GroomTypeSpecificLogTables |
Success |
2014-11-28 13:19:12.773 |
NULL |
0 |
Exec dbo.p_GroomChangeLogs 7D57C7E1-B216-4388-955B-E4FDBC5E3BD8, 10080, , 10000 |
NULL |
2014-11-28 12:58:08.530 |
NULL |
0 |
Exec dbo.p_GroomPartitionedObjects and dbo.p_Grooming |
NULL |
2014-11-28 12:55:30.863 |
2014-11-28 12:56:11.517 |
1 |
Exec dbo.p_GroomTypeSpecificLogTables |
Success |
2014-11-28 12:30:16.587 |
NULL |
0 |
Exec dbo.p_GroomPartitionedObjects and dbo.p_Grooming |
NULL |
2014-11-28 01:00:00.227 |
NULL |
0 |
Exec dbo.p_DataPurging |
NULL |
2014-11-27 22:59:59.830 |
NULL |
0 |
Exec dbo.p_GroomPartitionedObjects and dbo.p_Grooming |
NULL |
2014-11-26 23:00:00.577 |
NULL |
0 |
Exec dbo.p_GroomPartitionedObjects and dbo.p_Grooming |
NULL |
2014-11-26 01:00:00.090 |
NULL |
0 |
Exec dbo.p_DataPurging |
NULL |
Dans ce cas précis, on voit que la date de fin est à NULL et que le code d’état à 0.
Après avoir tenté d’exécuter la procédure (exec p_PartitioningAndGrooming) à la main, cette dernière finie en timeout au bout d’une heure et quelques. J’ai ensuite exécuté les procédures stockées de la table PartitioningAndGrooming à la main avec succès mais sans changer l’issue de p_PartitioningAndGrooming. Notez que la table PartitioningAndGrooming affiche maintenant des dates cohérentes.
Le problème se situe au niveau au niveau du grooming des partitions qui prend trop de temps. Pour rappel les données partitionnées correspondent aux évènements et données de performance collectées. Dans ce cas, la seule solution trouvée, revient à complétement nettoyer les tables de partitionnement. Notez que cette opération va vous faire perdre toutes les données (Performance + événements) !
Pour faire ce nettoyage, il faute exécuter la procédure p_PartitioningAndGrooming autant de fois qu’il y a de table partitionnée + 1 fois ! Pour connaître le nombre de table partitionnée, vous pouvez exécuter :
select * from PartitionTables
where IsCurrent = 1
Cette requête affiche les tables partitionnées en cours d’écriture. Prenez l’identifiant de partition et ajoutez 1 pour obtenir le nombre d’exécution nécessaire (71 fois dans l’exemple si dessous). Vous pouvez ensuite utiliser un compteur à exécuter via SQL Server Management Studio sur la base opérationnelle :
declare @i int set @i = 0 while @i < 71
begin
exec p_PartitioningAndGrooming
set @i = @i + 1
end
Ceci aura vidé vos tables de partitionnement et le grooming reprendra normalement.