{"id":1161,"date":"2015-03-01T22:46:35","date_gmt":"2015-03-01T21:46:35","guid":{"rendered":"http:\/\/www.sqlserver.fr\/blog\/?p=1161"},"modified":"2026-05-02T14:30:45","modified_gmt":"2026-05-02T12:30:45","slug":"plan-de-maintenance-et-tables-sans-index-clustered","status":"publish","type":"post","link":"https:\/\/www.sqlserver.fr\/blog\/plan-de-maintenance-et-tables-sans-index-clustered\/","title":{"rendered":"Plan de maintenance et tables sans index clustered"},"content":{"rendered":"

M\u00eame si certains oublient de les mettre en place (et s’\u00e9tonnent ensuite de voir les performances de leur application se d\u00e9grader au fil du temps …), des plans de maintenance sont g\u00e9n\u00e9ralement\u00a0impl\u00e9ment\u00e9s\u00a0sur les serveurs SQL Server, et int\u00e8grent notamment une d\u00e9fragmentation des index. Mais dans certains cas, ce type de t\u00e2ches n’est pas suffisant …<\/p>\n

Dans les exemples de tables que nous prendrons ici, nous consid\u00e9rerons que l’on a un certain nombre (10 millions par exemple) d’enregistrements dans nos tables, et que nous en supprimons les\u00a0trois quarts. Ensuite, nous progresserons dans notre plan de maintenance pour en observer l’efficacit\u00e9.\u00a0L’\u00e9tude sera faite sur\u00a02 tables : une avec un index clustered, et l’autre sans.<\/p>\n

Voici le script de cr\u00e9ation des tables :<\/p>\n

CREATE TABLE AvecClustered (Id int IDENTITY PRIMARY KEY, Valeur varchar(100))\r\nCREATE TABLE SansClustered (Id int IDENTITY PRIMARY KEY NONCLUSTERED, Valeur varchar(100))<\/pre>\n
Et voici le script de remplissage :<\/p>\n
SET NOCOUNT ON\r\nGO\r\nINSERT INTO AvecClustered (Valeur) SELECT NEWID()\r\nINSERT INTO SansClustered (Valeur) SELECT NEWID()\r\nGO 10000000<\/pre>\n
On peut d’ores et d\u00e9j\u00e0 observer la taille occup\u00e9e sur disque par ces deux tables :<\/p>\n
\"TablesPleines\"<\/a><\/p>\n
Ensuite, on efface 3 enregistrements sur 4.<\/p>\n
DELETE FROM AvecClustered where Id%4<>0\r\nDELETE FROM SansClustered where Id%4<>0<\/pre>\n
En regardant l’espace occup\u00e9, on s’aper\u00e7oit qu’il n’a pas chang\u00e9 alors que le nombre d’enregistrements a \u00e9t\u00e9 divis\u00e9 par 4 !<\/p>\n
\"Volume_Gruyere\"<\/a><\/p>\n
Utilisons ensuite l’assistant de plan de maintenance pour g\u00e9n\u00e9rer une t\u00e2che basique de reconstruction d’index.<\/p>\n
\"PlanMaintenance\"<\/a><\/p>\n
Et apr\u00e8s ex\u00e9cution de ce plan, voici les volumes occup\u00e9s par les deux tables :<\/p>\n
\"Moitie\"<\/a><\/p>\n
On voit donc que le plan de maintenance, destin\u00e9 \u00e0 reconstruire tous les index, a bien consid\u00e9rablement r\u00e9duit le volume occup\u00e9 par la table AvecClustered. Mais il n’a pas touch\u00e9 \u00e0 la table SansClustered, qui est un segment m\u00e9moire sans aucun index clustered.<\/p>\n
Plusieurs solutions se pr\u00e9sentent pour pouvoir r\u00e9duire tout de m\u00eame l’espace disque occup\u00e9 :<\/p>\n