Partitionnement dans l'exemple de base de données AdventureWorks
SQL Server 2005 comprend deux exemples de scripts Transact-SQL pouvant être exécutés sur l'exemple de base de données AdventureWorks afin d'implémenter un scénario de partitionnement. Pour plus d'informations sur l'installation et l'exécution des scripts, consultez Readme_PartitioningScript et Readme_SlidingWindow.
Le premier script, PartitionAW.sql, partitionne les tables AdventureWorks, TransactionHistory et TransactionHistoryArchive. La table TransactionHistory contient les enregistrements de ventes de l'année en cours. Elle est principalement utilisée pour insérer de nouveaux enregistrements et les mettre à jour le cas échéant. La table TransactionHistoryArchive contient les enregistrements de ventes plus anciens que ceux de l'année en cours. Elle est principalement utilisée pour les requêtes SELECT et en tant que table intermédiaire pour le déplacement de données dans un entrepôt de données. Pour plus d'informations sur le partitionnement de ces tables, consultez Directives de planification des index et des tables partitionnés.
Dans un scénario réaliste, les tables TransactionHistory et TransactionHistoryArchive deviendraient probablement deux des plus grandes tables de la base de données. En les partitionnant, des sous-ensembles de données mensuelles peuvent être gérés entre elles. Chaque mois, le mois de données le plus ancien est déplacé de TransactionHistory vers TransactionHistoryArchive. De cette manière, les données contenues dans TransactionHistory restent à jour pour les opérations INSERT et UPDATE, tandis que les données plus anciennes sont déplacées vers TransactionHistoryArchive pour les opérations de purge et d'analyse. Comme les tables sont partitionnées, le transfert des « blocs » mensuels de données entre elles ne dure généralement que quelques secondes (et non plus plusieurs minutes ou plusieurs heures comme dans les versions précédentes). Cela est dû au fait qu'il s'agit uniquement d'une opération sur les métadonnées et non d'une relocalisation physique des données.
Le deuxième script, Sliding.sql, implémente ce scénario de « glissement de fenêtre » pour un mois de données. Pour plus d'informations sur le fonctionnement de ce script, consultez Création de partitions pour gérer les sous-ensembles de données.
Voir aussi
Concepts
Concepts sur les tables et les index partitionnés