84
Chapitre 4. Optimisation des objets et de la structure de la base de données
férents types (type_desc) : IN ROW DATA – Ligne à l’intérieur de la page ; LOB DATA
– objet large ; ROW OVERFLOW DATA – Ligne partagée sur plusieurs pages (voir
section 4.1.2).
Vous pouvez également employer directement dans la table une fonction qui renvoie, dans quelle partition doit se trouver chaque ligne (selon la fonction de partitionnement. Elle ne va pas vérifier physiquement si la ligne se trouve dans le bon
groupe de fichier). Cela permet de tester le respect des plages :
SELECT
COUNT(*) as cnt,
MAX(OrderDate) as MaxDate,
MIN(OrderDate) as MinDate,
$PARTITION.pfOrderDate(OrderDate) AS Partition
FROM Sales.SalesOrderHeader_Partitionne
GROUP BY $PARTITION.pfOrderDate(OrderDate)
ORDER BY Partition;
Le partitionnement permet des facilités d’administration non négligeables. Ajouter, supprimer, déplacer, séparer ou fusionner des partitions peut être pris en charge
très rapidement à l’aide des instructions dédiées SWITCH, MERGE et SPLIT. Il n’entre pas
dans le cadre de cet ouvrage de vous présenter en détail leur utilisation. Voici pour
exemple comment déplacer une partition sur une autre table (existante) :
ALTER TABLE Sales.SalesOrderHeader_Partitionne
SWITCH PARTITION 1
TO Sales.SalesOrderHeader_Old;
Ces opérations sont pratiquement instantanées, car elles agissent directement au
niveau du stockage de la partition, et non en déplaçant les lignes d’une table à une
autre. Elles permettent ainsi une administration extrêmement efficace, par exemple
pour un archivage régulier.
Attention – La création d’index non alignés empêche l’utilisation de ces instructions.
On ne peut pas déplacer une partition si un index non aligné existe sur la table.
Dans notre exemple de partitionnement, si nous avions créé une clé primaire sur
la colonne SalesOrderID, nous aurions dû la faire nonclustered et non-alignée,
comme ceci : CONSTRAINT [PK_SalesOrderHeader_Partitionne_SalesOrderID]
PRIMARY KEY NONCLUSTERED (SalesOrderID) ON [PRIMARY]. Cela nous aurait empêchés de réaliser des SWITCH après coup.
Enfin, grâce à la possibilité de réaliser des sauvegardes de fichiers ou de groupes
de fichiers, la partitionnement de table permet d’optimiser vos stratégies de backup.
Chapitre 4. Optimisation des objets et de la structure de la base de données
férents types (type_desc) : IN ROW DATA – Ligne à l’intérieur de la page ; LOB DATA
– objet large ; ROW OVERFLOW DATA – Ligne partagée sur plusieurs pages (voir
section 4.1.2).
Vous pouvez également employer directement dans la table une fonction qui renvoie, dans quelle partition doit se trouver chaque ligne (selon la fonction de partitionnement. Elle ne va pas vérifier physiquement si la ligne se trouve dans le bon
groupe de fichier). Cela permet de tester le respect des plages :
SELECT
COUNT(*) as cnt,
MAX(OrderDate) as MaxDate,
MIN(OrderDate) as MinDate,
$PARTITION.pfOrderDate(OrderDate) AS Partition
FROM Sales.SalesOrderHeader_Partitionne
GROUP BY $PARTITION.pfOrderDate(OrderDate)
ORDER BY Partition;
Le partitionnement permet des facilités d’administration non négligeables. Ajouter, supprimer, déplacer, séparer ou fusionner des partitions peut être pris en charge
très rapidement à l’aide des instructions dédiées SWITCH, MERGE et SPLIT. Il n’entre pas
dans le cadre de cet ouvrage de vous présenter en détail leur utilisation. Voici pour
exemple comment déplacer une partition sur une autre table (existante) :
ALTER TABLE Sales.SalesOrderHeader_Partitionne
SWITCH PARTITION 1
TO Sales.SalesOrderHeader_Old;
Ces opérations sont pratiquement instantanées, car elles agissent directement au
niveau du stockage de la partition, et non en déplaçant les lignes d’une table à une
autre. Elles permettent ainsi une administration extrêmement efficace, par exemple
pour un archivage régulier.
Attention – La création d’index non alignés empêche l’utilisation de ces instructions.
On ne peut pas déplacer une partition si un index non aligné existe sur la table.
Dans notre exemple de partitionnement, si nous avions créé une clé primaire sur
la colonne SalesOrderID, nous aurions dû la faire nonclustered et non-alignée,
comme ceci : CONSTRAINT [PK_SalesOrderHeader_Partitionne_SalesOrderID]
PRIMARY KEY NONCLUSTERED (SalesOrderID) ON [PRIMARY]. Cela nous aurait empêchés de réaliser des SWITCH après coup.
Enfin, grâce à la possibilité de réaliser des sauvegardes de fichiers ou de groupes
de fichiers, la partitionnement de table permet d’optimiser vos stratégies de backup.