80
Chapitre 4. Optimisation des objets et de la structure de la base de données
WITH CHECK ADD CONSTRAINT chk$SalesOrderHeader$OrderDate
CHECK (OrderDate NOT BETWEEN '20020101' AND '20021231 23:59:59.997');
GO
ALTER TABLE Sales.SalesOrderHeader_Archive2002
WITH CHECK ADD CONSTRAINT chk$SalesOrderHeader_Archive2002$OrderDate
CHECK (OrderDate BETWEEN '20020101' AND '20021231 23:59:59.997');
Le WITH CHECK n’est pas nécessaire, car la vérification de la contrainte sur les
lignes existantes est effectuée par défaut. Nous désirons simplement mettre l’accent
sur le fait que la contrainte doit être reconnue comme étant appliquée aux lignes
existantes, pour que l’optimiseur puisse s’en servir.
Relançons le même ordre SELECT, et observons les statistiques de lectures :
Table 'SalesOrderHeader_Archive2002'. Scan count 1, logical reads 18...
Seule la table SalesOrderHeader_Archive2002 a été affectée. Grâce à la contrainte spécifiée, l’optimiseur sait avec certitude qu’il ne trouvera aucune ligne dans
Sales.SalesOrderHeader qui corresponde à la fourchette de dates demandée dans la
clause WHERE. Il peut donc éliminer cette table de son plan d’exécution.
En utilisant les contraintes CHECK, vous pouvez manuellement partitionner horizontalement vos tables, les rejoindre dans une vue, et ainsi augmenter vos performances de lecture sans sacrifier les fonctionnalités.
Cette technique conserve un désavantage : l’administration (création de tables
d’archive) reste manuelle. À partir de SQL Server 2005, des fonctions intégrées de
partitionnement horizontal de table et d’index simplifient l’approche.
Partitionnement intégré
Les fonctionnalités de partitionnement sont disponibles sur SQL Server 2005 dans
l’édition Entreprise seulement.
Tout ce que nous venons de faire manuellement, et plus encore, est pris en charge
par le moteur de stockage. Depuis SQL Server 2005, une couche a été ajoutée dans
la structure physique des données, entre l’objet et ses unités d’allocation : la partition. L’objectif premier du partitionnement est de placer différentes parties de la
même table sur différentes partitions de disque, afin de paralléliser les lectures physiques et de diminuer le nombre de pages affectées par un scan ou par une recherche
d’index.
La lecture en parallèle sur plusieurs unités de disques n’est vraiment intéressante,
bien entendu, que lorsque les partitions sont situées sur des disques physiques différents, et de préférence sur des bus de données différents, ou sur une baie de disques
ou un SAN, sur lequel on a soigneusement organisé les partitions. Chaque disque
physique n’ayant qu’une seule tête de lecture, il ne sert à rien de compter sur un simple partitionnement logique sur le même disque : les accès ne pourront se faire qu’en
Chapitre 4. Optimisation des objets et de la structure de la base de données
WITH CHECK ADD CONSTRAINT chk$SalesOrderHeader$OrderDate
CHECK (OrderDate NOT BETWEEN '20020101' AND '20021231 23:59:59.997');
GO
ALTER TABLE Sales.SalesOrderHeader_Archive2002
WITH CHECK ADD CONSTRAINT chk$SalesOrderHeader_Archive2002$OrderDate
CHECK (OrderDate BETWEEN '20020101' AND '20021231 23:59:59.997');
Le WITH CHECK n’est pas nécessaire, car la vérification de la contrainte sur les
lignes existantes est effectuée par défaut. Nous désirons simplement mettre l’accent
sur le fait que la contrainte doit être reconnue comme étant appliquée aux lignes
existantes, pour que l’optimiseur puisse s’en servir.
Relançons le même ordre SELECT, et observons les statistiques de lectures :
Table 'SalesOrderHeader_Archive2002'. Scan count 1, logical reads 18...
Seule la table SalesOrderHeader_Archive2002 a été affectée. Grâce à la contrainte spécifiée, l’optimiseur sait avec certitude qu’il ne trouvera aucune ligne dans
Sales.SalesOrderHeader qui corresponde à la fourchette de dates demandée dans la
clause WHERE. Il peut donc éliminer cette table de son plan d’exécution.
En utilisant les contraintes CHECK, vous pouvez manuellement partitionner horizontalement vos tables, les rejoindre dans une vue, et ainsi augmenter vos performances de lecture sans sacrifier les fonctionnalités.
Cette technique conserve un désavantage : l’administration (création de tables
d’archive) reste manuelle. À partir de SQL Server 2005, des fonctions intégrées de
partitionnement horizontal de table et d’index simplifient l’approche.
Partitionnement intégré
Les fonctionnalités de partitionnement sont disponibles sur SQL Server 2005 dans
l’édition Entreprise seulement.
Tout ce que nous venons de faire manuellement, et plus encore, est pris en charge
par le moteur de stockage. Depuis SQL Server 2005, une couche a été ajoutée dans
la structure physique des données, entre l’objet et ses unités d’allocation : la partition. L’objectif premier du partitionnement est de placer différentes parties de la
même table sur différentes partitions de disque, afin de paralléliser les lectures physiques et de diminuer le nombre de pages affectées par un scan ou par une recherche
d’index.
La lecture en parallèle sur plusieurs unités de disques n’est vraiment intéressante,
bien entendu, que lorsque les partitions sont situées sur des disques physiques différents, et de préférence sur des bus de données différents, ou sur une baie de disques
ou un SAN, sur lequel on a soigneusement organisé les partitions. Chaque disque
physique n’ayant qu’une seule tête de lecture, il ne sert à rien de compter sur un simple partitionnement logique sur le même disque : les accès ne pourront se faire qu’en