Partitionnement d`un data warehouse relationnel
publicité
Partitionnement d’un data warehouse relationnel Les sections suivantes décrivent brièvement le concept de data warehouse relationnel, les avantages du partitionnement de data warehouses relationnels, ainsi que les avantages de la migration vers le partitionnement dans Microsoft SQL Server 2005. À propos des data warehouses relationnels Les data warehouses relationnels offrent une source de données et une infrastructure complètes pour le développement de solutions d’analyse décisonnelle. En outre, les data warehouses relationnels sont utilisés par les applications de création de rapports et les requêtes SQL ad hoc complexes. Un data warehouse relationnel typique est constitué de tables de dimensions et de tables de faits. La taille des tables de dimensions est généralement inférieure à celle des tables de faits ; les tables de dimensions offrent des détails sur les attributs qui expliquent les faits. Article, magasin et heure sont des exemples de dimensions. Les tables de faits représentent les enregistrements métier, tels que les informations sur les ventes d’articles pour tous les magasins. Les tables de faits sont mises à jour périodiquement avec les données collectées récemment. Une implémentation réussie d’une solution de data warehouse relationnel implique une planification soigneuse et à long terme. Voici quelques-uns des facteurs à prendre en considération lors du développement d’un data warehouse relationnel : • • • • • • • Volume des données Fenêtre de chargement des données Fenêtre de maintenance des index Caractéristiques de la charge de travail Stratégie d’expiration des données Stratégie d’archivage et de sauvegarde Caractéristiques matérielles Une étude détaillée de ces facteurs est fournie dans les sections suivantes de ce document. Un data warehouse relationnel peut être implémenté à l’aide d’une approche par partition ou une approche par table de faits monolithique (énorme). Le choix de conception entre ces deux approches dépend en grande partie des facteurs détaillés plus haut dans ce document. Les data warehouses relationnels peuvent tirer parti du partitionnement des données. La section suivante décrit les avantages du partitionnement des data warehouses relationnels. Avantages du partitionnement À mesure que la taille des bases de données d’une organisation augmente, avec des volumes importants de données, il est essentiel de maintenir la haute disponibilité tout en satisfaisant à la nécessité d'une petite fenêtre de maintenance de la base de données. Cette exigence fait du partitionnement une solution naturelle pour les bases de données très volumineuses. Le partitionnement répond à des problèmes essentiels dans la prise en charge des tables très volumineuses en vous permettant de les décomposer en partitions plus petites, ce qui facilite la gestion des facteurs tels que le chargement, l’expiration et l’archivage des données. Microsoft SQL Server prend en charge le partitionnement des données par l'intermédiaire de vues partitionnées dans SQL Server 7.0/2000, ainsi que la prise en charge des tables partitionnées dans SQL Server 2005. Partitionnement dans SQL Server 7.0/2000 SQL Server 7.0 a introduit la prise en charge du partitionnement par l'intermédiaire des vues partitionnées. Dans SQL Server 2000, la fonctionnalité a été améliorée afin de prendre en charge les vues partitionnées pouvant être mises à jour. Une vue partitionnée est particulièrement adaptée à un data warehouse relationnel lorsque la table de faits peut être naturellement partitionnée ou divisée en tables distinctes par plages de données. Les tables sous-jacentes de la vue partitionnée font l’objet d'une UNION afin de présenter un ensemble de données unifié. Les vues partitionnées réduisent considérablement la complexité des applications, car l’implémentation physique est déduite des méthodes d’accès aux données par l’application. Dans SQL Server 2000, les vues partitionnées peuvent être étendues afin d’inclure des vues partitionnées distribuées, ce qui permet la fédération des bases de données sur plusieurs serveurs/instances. L’étude des vues partitionnées distribuées sort du cadre de ce document. Pour une étude détaillée, reportez-vous au document « Vues partitionnées distribuées » sur MSDN (Microsoft Developer Network) à l’adresse http://www.microsoft.com/sql/evaluation/features/distpart.asp . Partitionnement dans SQL Server 2005 Le partitionnement de tables et d’index dans SQL Server 2005 limite la complexité liée à la gestion de bases de données très volumineuses par l'intermédiaire de vues partitionnées. SQL Server 2005 permet le partitionnement horizontal par plage avec la ligne de données comme plus petite unité de partitionnement. Les objets pouvant être partitionnés sont les suivants : • • • Tables de base Index (en cluster ou non) Vues indexées Les partitions par plage sont des partitions de table définies par des plages personnalisables de données. L’utilisateur définit la fonction de partition avec des valeurs limites, un schéma de partition avec mise en correspondance des groupes de fichiers, ainsi que des tables mises en correspondance avec le schéma de partition. Une fonction de partition détermine à quelle partition appartient une ligne particulière d’une table ou d’un index. Chaque partition définie par une fonction de partition est mise en correspondance avec un emplacement de stockage (groupe de fichiers) via un schéma de partition. Pour une étude complète de l’implémentation du partitionnement avec SQL Server 2005, reportez-vous à l’article « Tables et index partitionnés dans SQL Server 2005 » sur MSDN. La section suivante explique les avantages du partitionnement dans SQL Server 2005 et offre une stratégie pour la migration vers les tables partitionnées SQL Server 2005. Avantages du partitionnement dans SQL Server 2005 Le partitionnement de tables et d’index dans SQL Server 2005 facilite la gestion des bases de données très volumineuses via la gestion étape par étape des partitions. Cette section décrit quelques-uns des avantages des tables partitionnées par rapport aux vues partitionnées, s’agissant des data warehouses relationnels. Gestion L’un des inconvénients de l’utilisation de vues partitionnées est que les opérations de base de données doivent être effectuées sur des objets individuels plutôt que sur la vue proprement dite. Par exemple, si l’index existant doit être supprimé et qu’un nouvel index doit être créé, l'opération doit être effectuée sur chaque table sous-jacente. Dans SQL Server 2005, les opérations de base de données telles que la maintenance des index sont effectuées sur la table partitionnée proprement dite et non sur les partitions sous-jacentes, ce qui permet de simplifier considérablement la gestion des index. Mécanisme de parallélisme plus performant Dans SQL Server 2000, les opérations sont effectuées sur des tables individuelles et les données sont agrégées à un niveau de vue partitionnée. Les lignes des tables sous-jacentes sont collectées à l’aide de l’opérateur de concaténation afin de représenter la vue. Des agrégations sont ensuite effectuées sur les données résultantes. Dans SQL Server 2005, les requêtes exécutées sur les tables partitionnées peuvent utiliser un nouvel opérateur appelé parallélisme de demande. Le parallélisme de demande est influencé par les ressources système et les paramètres MAXDOP. Les requêtes qui utilisent des tables partitionnées sont compilées beaucoup plus rapidement que les requêtes équivalentes utilisant des vues partitionnées. La durée de compilation des requêtes est proportionnelle au nombre de partitions lors de l’utilisation de vues partitionnées, tandis que la compilation n’est pas affectée par le nombre de partitions lors de l’utilisation de tables partitionnées. Les requêtes sur des vues partitionnées peuvent présenter de meilleures performances dans certains cas, par exemple : • La plus petite unité de parallélisme, lorsque le parallélisme de demande est choisi par l’optimiseur, est une partition. Les performances des requêtes sur une partition unique dans une table partitionnée SQL Server 2005 peuvent être dégradées en raison du fait que le degré de parallélisme est limité à un. La même requête sur une vue partitionnée peut offrir de meilleures performances en raison d’un meilleur parallélisme dans une partition. • Les vues partitionnées peuvent offrir de meilleures performances lorsque le nombre de partitions est inférieur au nombre de processeurs, en raison d’une meilleure utilisation des processeurs disponibles via le parallélisme. Lorsque le nombre de partitions est supérieur au nombre de processeurs, les performances des requêtes sur les tables partitionnées peuvent s’en trouver dégradées si les données ne sont pas réparties uniformément sur les partitions. • Les requêtes sur les vues partitionnées peuvent offrir de meilleures performances en cas de nonuniformité de la distribution des données sur les partitions. Identification du parallélisme de demande dans un plan de requête Voici un exemple de plan de requête généré à partir d'une requête d'agrégation additive. La section encerclée en rouge indique la présence du parallélisme de demande dans le plan de requête. L’enfant de gauche de l’opérateur de boucle imbriquée est représenté par les ID de partition. L’enfant de droite de l’opérateur de boucle imbriquée est représenté par la table partitionnée proprement dite. Dans cette illustration, pour chaque ID de partition renvoyé par l’enfant de gauche, un opérateur de recherche d'index en parallèle génère une itération sur les lignes de la partition appropriée. Toutes les opérations au-dessus de l’opérateur de boucle imbriquée sont également influencées par le nombre de threads parallèles défini par le parallélisme de demande. L’enfant de gauche représente uniquement les ID de partition affectés par la requête lorsque la sélection de partitions est effective par exemple lorsque la requête filtre les résultats par partition. Figure 1. Identification du parallélisme de demande Voir l’image en taille réelle Migration vers des tables/index partitionnés SQL Server 2005 à partir de vues partitionnées SQL Server 2000 Une application existante basée sur des vues de tables monolithiques ou des vues partitionnées peut être restructurée ou migrée vers une solution SQL Server 2005 basée sur le partitionnement. La décision de restructurer ou de migrer l’application implique une analyse détaillée des exigences en termes de performances, de gestion et de disponibilité. Une procédure simple pour la migration de vues partitionnées SQL Server 2000 vers des tables partitionnées SQL Server 2005 comporte les étapes suivantes : • Créez une fonction et un schéma de partition afin de déterminer les points limites et l’emplacement de stockage physique de chaque partition. Les points limites doivent correspondre à ceux des tables sous-jacentes de la vue partitionnée. • Créez une table partitionnée sur le schéma de partition nouvellement créé. La table doit spécifier la • Basculez les tables individuelles sous-jacentes des vues partitionnées dans chaque partition de la table même structure physique, y compris les index, que les tables sous-jacentes de la vue partitionnée. de faits partitionnée nouvellement créée. Les groupes de fichiers référencés dans le schéma de partition doivent correspondre au groupe de fichiers de la table vers laquelle le basculement a lieu. En outre, les tables à migrer doivent satisfaire aux exigences de l’instruction de basculement. Par exemple, la table cible ne peut pas être un composant d’une vue avec liaison de schéma. Pour connaître la liste des exigences de l’instruction de basculement, reportez-vous au document « Transfert efficace de données avec le changement de partition » dans la documentation en ligne de SQL Server 2005. Haut de page Facteurs qui influencent le partitionnement de data warehouses relationnels L’implémentation réussie d’un data warehouse relationnel partitionné implique la planification de la croissance de la base de données et la simplicité de gestion. Les sections qui suivent expliquent les facteurs qui influencent le partitionnement pour les data warehouses relationnels et apportent des détails sur les implémentations de fenêtres glissantes. Volume des données Une approche partitionnée rend la gestion plus complexe sans apporter de réelle plus-value lorsque les tables de faits sont plus petites. Cette taille est basée sur les caractéristiques de l’application et doit être déterminée pour chaque implémentation. À titre d’information, plusieurs clients ont demandé que la taille des tables de faits soit au moins égale à 100 Go avant toute implémentation du partitionnement. Chargement des données Le chargement des données fait partie intégrante d’un data warehouse. Presque tous les data warehouses sont périodiquement alimentés avec les données collectées récemment. La gestion réussie d’un data warehouse dépend de l’efficacité du processus de chargement en masse, au cours duquel les données existantes doivent continuer d’être disponibles. Il existe deux options pour la création de votre table de faits : • • Créez une table monolithique unique, ou Utilisez une approche par partition L’approche par table monolithique entraîne une disponibilité inférieure par rapport à l’approche par partition, en raison du chargement incrémentiel en masse effectué dans les environnements de data warehouse typiques. Par exemple, le chargement incrémentiel en masse peut largement tirer parti d'un verrou de table sur la table cible. Avec une table unique, aucun utilisateur ne pourra plus accéder à la table au cours du chargement des données. La solution optimale consiste à planifier la fenêtre de maintenance pour le chargement incrémentiel des données. Pour une étude complète du chargement en masse avec l'approche par table monolithique, consultez l'article « Étude de cas d’un chargement en masse incrémentiel dans SQL Server 2000 » à l’adresse http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx . L’approche par partition implique le chargement en masse des données dans des tables intermédiaires individuelles, chacune représentant une plage de partitions déterminée. La table intermédiaire est ensuite ajoutée à la vue partitionnée ou basculée dans la table partitionnée en tant que nouvelle partition. Étant donné que chaque partition est logiquement représentée par une table intermédiaire individuelle, les chargements en masse incrémentiels n’affectent pas la disponibilité et les performances des requêtes sur les données existantes. Une solution de data warehouse typique inclut la transformation des données en parallèle de leur chargement en masse. La transformation inclut le nettoyage et/ou l'agrégation des données source afin d'alimenter le data warehouse de destination. Une transformation est généralement effectuée à l’aide d’outils tels que Microsoft System Integration Services. Les clients peuvent choisir d’utiliser SELECT/INTO pour exécuter cette transformation si le processus ne nécessite pas de workflow complexe. Indexation Après le chargement des données dans un data warehouse relationnel, il est courant de créer des index afin de prendre en charge les requêtes utilisateur. La création et la maintenance des index jouent un rôle fondamental dans l’architecture des data warehouses relationnels. Les performances des requêtes sur les tables de faits sont généralement moins bonnes en l’absence d’index. Pour une table de faits monolithique, une solution optimale peut consister à supprimer tous les index, à charger les données et à recréer les index. Cette approche entraîne la réduction de la disponibilité et une fenêtre de maintenance plus importante à mesure que la taille de la table monolithique augmente, ce qui la rend peu commode dans certains cas. Les vues partitionnées résolvent ce problème de manière efficace dans SQL Server 2000, car les index sont créés sur les tables sous-jacentes. SQL Server 2005 prend en charge la recréation et la réorganisation des index sur les partitions individuelles, ce qui facilite la gestion des index partitionnés. Expiration des données Les données anciennes font l’objet d’accès moins fréquents que les données plus récentes. Les lois et réglementations imposent aux entreprises de conserver les données expirées en ligne en vue d'un accès immédiat. Il est par conséquent essentiel qu’une entreprise gère efficacement les données anciennes, tout en préservant la haute disponibilité des données existantes et en facilitant le chargement plus rapide des nouvelles données. L’expiration des données peut être gérée efficacement via une fenêtre glissante. Si les données sont partitionnées, l’implémentation d’une fenêtre glissante est possible. Pour plus d’informations, reportez-vous à la section « Implémentation de fenêtres glissantes » plus loin dans ce document. Archivage des données L’implémentation réussie d’un data warehouse de plusieurs téraoctets ne se borne pas à la création d’un système performant et linéairement évolutif. Il est également nécessaire de garantir la disponibilité élevée du système. Si les données sont partitionnées, une sauvegarde étape par étape peut être implémentée dans SQL Server. Les opérations de sauvegarde et de restauration étape par étape dans SQL Server offrent davantage de flexibilité pour la gestion des partitions. Les opérations étape par étape impliquent que les partitions individuelles, lorsqu’elles sont confinées dans leurs propres groupes de fichiers, peuvent être sauvegardées et restaurées individuellement sans affecter la base de données entière. Le groupe de fichiers doit être en mode lecture seule pour que la sauvegarde étape par étape fonctionne dans un modèle de récupération simple. Dans le cas du modèle de récupération en masse ou du modèle de récupération complète, il est nécessaire de sauvegarder les journaux de transactions. Cela est essentiel pour la réussite de la restauration des groupes de fichiers. Pour plus d’informations sur ces restrictions, reportez-vous à la section « Sauvegarde (Transact-SQL) » dans la documentation en ligne de SQL Server. Performances des requêtes Les requêtes ad hoc font partie intégrante des solutions de data warehouse relationnel. Les caractéristiques de l’application et la nature des requêtes qui en résultent influencent de manière importante le partitionnement des data warehouses relationnels. Par exemple, si les requêtes comportent une clé de filtrage correspondant à la clé de partitionnement, le temps de réponse sera inférieur comparé à la même requête sur une table monolithique. Cela tient au fait que l’utilisation du partitionnement encourage l’utilisation d’opérations en parallèle et que la clé de partitionnement dans le prédicat de requête facilite la sélection des données. Haut de page Implémentation de fenêtres glissantes Les fenêtres glissantes sont l’un des principaux facteurs qui influencent le partitionnement des data warehouses relationnels, ce qui explique que nous consacrons une section distincte à leur implémentation. Le scénario de fenêtre glissante implique l’intégration de nouvelles partitions et l’exclusion des partitions ayant expiré de la table ou vue partitionnée. Les nouvelles données peuvent être interrogées par les utilisateurs alors que les données anciennes sont archivées. L’essentiel est de réduire la durée de l’indisponibilité lors du déplacement des partitions. Les données ayant expiré peuvent être archivées et extraites lorsque cela s’avère nécessaire via la restauration des sauvegardes appropriées, ou elles peuvent être déplacées vers un sous-système d’E/S moins permanent et plus abordable, toujours disponible pour l’interrogation des utilisateurs. L’illustration suivante représente l'implémentation d'une fenêtre glissante dans notre scénario de test. Dans ce scénario, le client collecte les données des ventes auprès des magasins de tout le pays. Les données sont chargées, nettoyées et agrégées afin de prendre en charge les décisions métier. Dans notre scénario test, une partition représente logiquement une semaine de données. Actuellement, huit semaines de données sont identifiées comme actives. Les données actives sont interrogées beaucoup plus fréquemment que les données anciennes. À mesure que de nouvelles données sont incluses, les données anciennes sont extraites. Il existe une règle qui stipule que les données anciennes doivent rester en ligne mais être stockées sur un sous-système d’E/S peu coûteux. Figure 2. Scénario de fenêtre glissante Voir l’image en taille réelle Dans SQL Server 2000, les fenêtres glissantes peuvent être implémentées à l’aide de vues partitionnées. L’inconvénient est que la vue partitionnée doit être reliée afin d’inclure les données nouvellement intégrées à la vue UNION. La reliaison nécessite un verrou sur les métadonnées et peut être bloquée par tout accès à la vue existante ou aux tables sous-jacentes. SQL Server 2005 facilite une meilleure implémentation du scénario de fenêtre glissante en prenant en charge l’inclusion et l’exclusion de partitions via des instructions Transact-SQL. Le changement de partition nécessite un verrou de schéma sur la table partitionnée. Les partitions peuvent être incluses et exclues lorsque aucun autre processus n’a acquis de verrou au niveau table sur la table partitionnée. Si les partitions sont utilisées par d'autres processus ou si un verrou au niveau table a été acquis par d'autres processus sur la table partitionnée, l'instruction permettant le changement des partitions attend jusqu'à la libération du verrou par d'autres processus. Le changement de partition est une opération de métadonnées qui est très rapide. La procédure suivante peut être utilisée pour implémenter un scénario de fenêtre glissante dans SQL Server 2005 à l’aide de tables partitionnées : • Créez la fonction de partition, le schéma et la table avec les points limites et les groupes de fichiers • • • Créez les tables représentant les partitions individuelles. appropriés. Procédez ensuite au chargement initial décrit dans les quatre étapes qui suivent. Alimentez les tables individuellement. Ajoutez des contraintes de vérification aux tables afin de lier la valeur des données aux plages correspondantes et créez les index appropriés. SQL Server 2005 offre une option supplémentaire permettant de créer l’index initial après la création de la table partitionnée. • • Déplacez les tables nouvellement alimentées dans chaque partition de la table partitionnée. Après les chargements initiaux, toute nouvelle donnée est chargée et transformée dans une table ne faisant pas partie de cette table partitionnée. Lorsque les données sont prêtes, la table est transférée dans la table partitionnée après la manipulation des points limites appropriés. • De la même façon, les données anciennes peuvent être déplacées vers un sous-système d’E/S moins coûteux, tout en restant disponibles en ligne. La section suivante traite des méthodes recommandées pour le fractionnement de la table partitionnée et le changement de partitions dans la table partitionnée. Méthodes recommandées pour le changement de partitions Le scénario de fenêtre glissante fonctionne uniquement lorsque la table ou partition cible est vide. Par exemple, si une partition P appartenant à la table partitionnée PT doit être sortie vers la table T, la table cible T doit être vide. De la même façon, lors du transfert de la table T dans la partition P de la table partitionnée PT, la partition cible P doit être vide. Le scénario de fenêtre glissante fonctionne le mieux lorsque les déplacements de données entre partitions est limité. Le code suivant définit la fonction de partition et le schéma de partition. Lorsqu’une table est créée sur ce schéma de partition, la table partitionnée comporte trois partitions. La première partition contient les données avec les valeurs de clé <=200401, la deuxième avec les valeurs de clé >200401 et <=200403, la troisième avec les valeurs de clé >200403. CREATE PARTITION FUNCTION SALES_MONTHLY_PARTITION_FUNCTION (INT) AS RANGE LEFT FOR VALUES ( 200401, 200403 ) GO CREATE PARTITION SCHEME SALES_MONTHLY_PARTITION_SCHEME AS PARTITION SALES_MONTHLY_PARTITION_FUNCTION ALL TO ([PRIMARY]) GO CREATE TABLE t ( col1 INT )ON SALES_MONTHLY_PARTITION_SCHEME(col1) GO Lorsqu’une nouvelle limite avec une valeur de 200402 est ajoutée à l’aide de la fonctionnalité de fractionnement de la fonction ALTER PARTITION, les lignes sont déplacées entre les partitions appropriées. ALTER PARTITION FUNCTION PARTITION_FUNCTION() SPLIT RANGE (200402) GO Les lignes sont déplacées entre les partitions via la suppression des lignes à la position d’origine, et l’insertion des lignes à la nouvelle position. Les partitions impliquées dans ce transfert sont inaccessibles au cours de cette période. Dans cet exemple, la nouvelle deuxième partition contient les données avec les valeurs de clé >200401 et <=200402. Les données avec les valeurs de clé appropriées sont supprimées de la deuxième partition et insérées dans la nouvelle partition. La nouvelle partition (>200401 et <=200402) et la troisième partition (>200402 et <=200403) sont inaccessibles au cours de cette période. Dans notre exemple de scénario, les nouvelles données sont ajoutées en fractionnant la fonction de partition à l’extrémité active. Les anciennes données sont supprimées par fusion de la fonction de partition à l’extrémité ancienne. Cet exercice, pour l’implémentation d’une fenêtre glissante, supprime le déplacement de données entre les partitions lors de l’exclusion ou de l'inclusion de partitions par exemple, les nouvelles données sont chargées en masse dans une table, puis transférées vers la nouvelle table partitionnée via son fractionnement à l’extrémité active, de la façon suivante : ALTER TABLE NEW_PARTITION SWITCH TO PARTITIONED_TABLE PARTITION $partition.WEEK_PARTITION_FUNCTION (200404) GO Pour plus d’informations, reportez-vous au document « Conception de partitions pour gérer des sousensembles de données » dans la documentation SQL Server en ligne. Techniques pour l’archivage des données vers un sous-système d’E/S peu coûteux Une implémentation de fenêtres glissantes peut être étendue en faisant glisser les données anciennes vers un sous-système d’E/S peu coûteux. Par exemple, dans notre scénario de test, nous transférons les données anciennes d'un sous-système d'E/S très performant vers un sous-système d’E/S moins coûteux et ne présentant pas les mêmes performances élevées. Cette implémentation particulière des fenêtres glissantes ne peut pas être effectuée avec l’opération de sauvegarde et de restauration disponible dans SQL Server. Il existe différentes méthodes alternatives pour implémenter une telle stratégie : • Si les fichiers source sont disponibles, chargez les données dans une autre table qui réside sur le soussystème d’E/S moins coûteux. Reconstruisez les index. Supprimez l’ancienne partition et ajoutez la table nouvellement chargée dans la table partitionnée. Le temps d’indisponibilité correspond au temps nécessaire pour changer de partition, lequel est relativement négligeable, quelle que soit la taille de l’ensemble de données. • Si le processus de chargement implique une transformation, il serait efficace de créer la nouvelle table sur le sous-système d’E/S moins coûteux en utilisant une requête SELECT/INTO afin d’alimenter les données à partir de la partition ancienne et de recréer les index. Le temps d’indisponibilité est le temps nécessaire au changement de partition. Haut de page Stratégies pour le partitionnement de data warehouses relationnels La section suivante décrit deux stratégies importantes pour le partitionnement d'un data warehouse relationnel. Cette section sera suivie d’une étude de la façon dont les stratégies affectent les facteurs qui influencent le partitionnement. Stratégie I : lier une partition à son propre groupe de fichiers Une partition peut être liée de façon logique à un groupe de fichiers, de la façon suivante : • Créez la base de données avec plusieurs groupes de fichiers. Chaque groupe de fichiers représente • Chaque groupe de fichiers comporte un fichier. Les groupes de fichiers peuvent contenir un ou • Créez la fonction de partition et mettez en correspondance les points limites avec les groupes de logiquement une partition. plusieurs fichiers physiques créés à partir d’un ou plusieurs volumes logiques/disques physiques. fichiers appropriés à l’aide de schémas de partition pour créer une corrélation un à un entre le groupe de fichiers et la partition. Pour un exemple de code illustrant l’implémentation du partitionnement basé sur cette stratégie, reportez-vous à l’annexe D. Figure 3. Partition mise en correspondance avec son propre groupe de fichiers Voir l’image en taille réelle Stratégie II : lier plusieurs partitions au même groupe de fichiers La deuxième stratégie consiste à mettre en correspondance plusieurs partitions avec le même groupe de fichiers. Le groupe de fichiers peut être constitué d’un ou plusieurs fichiers physiques répartis sur un ou plusieurs volumes logiques/disques physiques. Pour un exemple de code qui implémente le partitionnement basé sur cette stratégie, reportez-vous à l’annexe D. Figure 4. Plusieurs partitions mises en correspondance avec le même groupe de fichiers Voir l’image en taille réelle Quelle solution est préférable ? Le partitionnement peut être implémenté à l’aide de l’une de ces deux stratégies, ou avec une combinaison des deux. La stratégie I et la stratégie II sont reprises dans le tableau suivant, lequel explique leur impact sur les facteurs qui influencent le partitionnement pour les data warehouses relationnels. Stratégie I Stratégie II Stratégie I Chargement des données • Les groupes de fichiers ne peuvent pas être spécifiés de manière explicite dans Stratégie II • effectuées en parallèle, dans la mesure l’instruction SQL SELECT/INTO. En où toutes les partitions sont mises en raison de cette limitation, les correspondance avec le même groupe transformations initiales ne peuvent de fichiers. pas être effectuées en parallèle lors de l’utilisation d’une instruction • SELECT/INTO. • Les transformations peuvent être Les chargements de données incrémentiels ne sont pas affectés par la stratégie de partitionnement. Les chargements de données incrémentiels ne sont pas affectés par la stratégie de partitionnement. Sauvegarde/ Restauration • • La création d’une relation un à un entre le groupe de fichiers et la partition • Si toutes les partitions sont mises en correspondance avec les mêmes permet les opérations de sauvegarde et groupes de fichiers, la table de restauration étape par étape au partitionnée dans son ensemble peut niveau partition. être sauvegardée et restaurée à l’aide Assurez-vous que les partitions sont d’une commande unique. marquées en lecture seule avant la sauvegarde de la base de données. Si • Cette solution n’offre pas la souplesse de la sauvegarde étape par étape au tel n’est pas le cas, les journaux de niveau de granularité de partition transactions doivent être appliqués lors individuelle. de la restauration de la base de données. Performances des requêtes • Si les groupes de fichiers contiennent un seul fichier et que les tables sont Si les groupes de fichiers sont constitués de plusieurs fichiers, alimentées en série l'une après l'autre, SQL Server utilise l’alimentation l'allocation des extents pour ces objets proportionnelle, ce qui entraîne la est contiguë. Cela implique que fragmentation des extents. SQL Server puisse exécuter jusqu’à 256 ko d’E/S (4 extents) pour une • • • De la même façon, rien ne garantit que les extents alloués pour les analyse séquentielle. objets/partitions ne seront contigus au Cela favorise les charges impliquant de cours des opérations en parallèle, telles nombreuses analyses séquentielles, car que le chargement de données en les données sont contiguës. parallèle. • SQL Server ne peut exécuter qu’un maximum de 64 ko d’E/S (1 extent) pour l’analyse séquentielle lorsque les extents alloués pour les objets ne sont pas contigus. • Cela favorise les charges comportant un grand nombre d’E/S aléatoires simultanées, car les données sont réparties sur de nombreux disques physiques. Il est également possible de démarrer SQL Server avec le commutateur -E. Dans ce cas, SQL Server peut allouer Stratégie I Stratégie II 4 extents au lieu d’un seul. Par conséquent, le commutateur -E permet à SQL Server d’exécuter 256 ko d’E/S même s’il existe une fragmentation des extents en raison du remplissage proportionnel. Haut de page Conclusion Ce livre blanc a étudié les facteurs qui influencent le partitionnement et a comparé les avantages et les inconvénients de deux stratégies essentielles pour la conception de partitions. Les informations présentées doivent vous aider à gérer plus efficacement vos data warehouses relationnels via le partitionnement. Haut de page Pour plus d'informations Ce document décrit des fonctionnalités spécifiques de SQL Server 2005 concernant le partitionnement de data warehouses relationnels. Pour plus d'informations : • La documentation SQL Server 2005 en ligne offre une multitude d’informations sur ce sujet et constitue un bon point de départ pour l’implémentation du partitionnement des données à l’aide de SQL Server 2005. • Site Web CLARiiON CX600 : http://www.emc.com/products/systems/clariion_cx246.jsp Haut de page Annexe A : Performances Toutes les valeurs indiquées dans cette section ont été observées au cours de nos tests avec SQL Server 2005. Les tests ont été réalisés sur les plates-formes matérielles décrites dans les annexes B, C et D. Performances d’insertion en masse Au cours de nos tests, nous avons pu chargé 2,5 milliards de lignes en un peu moins d’une heure dans SQL Server 2005. Le schéma de la table de faits contient neuf colonnes d’entiers, une colonne dateheure et une colonne de type caractère. Les performances représentées ici ont été capturées lorsque tous les threads s’exécutaient en parallèle et le schéma de partitionnement était basé sur la stratégie I. Nombre de threads en parallèle 8 Durée d’exécution (tous les threads en cours 52 minutes d’exécution) Utilisation des processeurs (sur 8 processeurs) 88 % Nombre de lignes insérées 2550835652 Débit de copie en masse/seconde 44,77 Mo/seconde Lignes de copie en masse/seconde 6,53,339 Débit du disque 41,17 Mo/seconde sur 8 LUN sur CLARiiON Les performances représentées ici ont été capturées lorsque tous les threads s’exécutaient en parallèle et le schéma de partitionnement était basé sur la stratégie II. Nombre de threads en parallèle 8 Durée d’exécution (tous les threads en cours 52 minutes d’exécution) Utilisation des processeurs (sur 8 processeurs) 92,625 % Nombre de threads en parallèle 8 Nombre de lignes insérées 2,550,835,652 Débit de copie en masse/seconde 46,42 Mo/seconde Lignes de copie en masse/seconde 677285 Débit du disque 44,29 Mo/seconde sur 8 LUN sur CLARiiON La stratégie choisie pour le partitionnement du data warehouse n’a pas affecté le débit de chargement en masse. Performances de transformation Dans nos tests, le processus de chargement en masse a été suivi d’un processus de transformation. Le processus de transformation impliquait de joindre les données source avec les tables de dimensions afin d’alimenter le data warehouse de destination avec les valeurs des clés de dimension extraites. Voici un exemple du code utilisé dans notre scénario de test : SELECT fact.fact_data_1, ... sdim.store_key, pdim.product_key, tdim.time_key INTO sales_transformed FROM sales fact, stores sdim, products pdim, time tdim WHERE fact.store_id = sdim.store_id AND convert(bigint, (fact.system + fact.generation + fact.vendor + fact.product)) = pdim.productid AND fact.weekid = tdim.weekid La requête de transformation a été exécutée à la suite, une requête immédiatement après l’autre, de sorte à préserver le schéma de partitionnement défini dans la stratégie I. Nombre de threads en parallèle 1 Temps d’exécution Environ 1 heure 13 minutes pour chaque transformation Utilisation du processeur (sur 1 processeur) 100 % Nombre de lignes transformées (chaque Environ 300 millions de lignes transformation) Débit de lecture du disque 3,5 Mo/seconde sur 1 LUN sur CLARiiON (lecture 256 ko) Débit d’écriture sur disque 2,8 Mo/seconde sur 1 LUN sur CLARiiON (écriture 128 ko) Voici les valeurs de performance d’un schéma de partitionnement basé sur la stratégie II lorsque tous les threads s’exécutaient en parallèle. Nombre de threads en parallèle 8 Nombre de threads en parallèle 8 Temps d’exécution 1 heure 9 minutes Utilisation des processeurs (sur 8 processeurs)99 % Nombre de lignes transformées (total) 2,478,765,081 Débit de lecture du disque 33,10 Mo/seconde sur 10 LUN sur CLARiiON Débit d’écriture sur disque 26,66 Mo/seconde sur 10 LUN sur CLARiiON Performances de la création d’index Dans nos tests, nous avons pu créer un index en cluster sur trois colonnes d’entiers (clés de dimension) sur huit partitions avec 2,5 millions de lignes en deux heures. L’option SORT_IN_TEMPDB permet l’utilisation de tempdb pour le tri des données. Cette option a été utilisée au cours de ce test pour isoler les disques physiques utilisés pour les lectures et écritures au cours de la création de l’index. Lorsque l’option "sort_in_tempdb" est activée, tempdb doit disposer de suffisamment d’espace disque libre pour contenir la taille de l’index entier au cours de la création d’index hors ligne. Lorsque le tri est effectué dans une base de données utilisateur, chaque groupe de fichiers/partition doit comporter suffisamment d’espace disque libre pour contenir les partitions appropriées. Dans notre scénario et notre conception, chaque partition représente logiquement une semaine de données avec une valeur de clé identique pour toutes les lignes d’une partition donnée. Le degré maximum de parallélisme pour chaque création d'index individuelle est seulement de 1, car le nombre de valeurs de clé distinctes est de 1. Par conséquent, l'index initial est créé après la table partitionnée dans SQL Server 2005, afin de mieux utiliser les processeurs disponibles pour la création initiale de l’index. Nombre de threads en parallèle 8 Temps d’exécution 2 heures Utilisation du processeur 86 % Nombre de lignes 2,478,765,081 Performances de sauvegarde de base de données Dans nos tests, nous avons sauvegardé la partition active sur quatre LUN RAID 3 sur EMC CLARiiON en un peu plus d’une heure. La partition active était répartie sur huit LUN sur un ensemble RAID 5 (4+1 10 000 tpm) EMC CLARiiON. Le périphérique cible était un ensemble RAID 3 (4+1, 5 000 tpm ATA) CLARiiON. Temps d’exécution 1 heure 20 minutes Nombre de pages (8 ko) sauvegardées 30,518,330 Débit de sauvegarde/restauration par seconde50,15 Mo/seconde Transfert des données anciennes vers les disques ATA Le transfert des données anciennes vers les disques ATA implique le chargement en masse de données à l’aide de l’instruction SELECT/INTO. Voici un exemple de code utilisé pour implémenter la fenêtre glissante. ALTER DATABASE [Customer] ADD FILEGROUP [ARCHIVE_1] GO ALTER DATABASE [Customer] ADD FILE (NAME = N'ARCHIVE_1', FILENAME = N'F:\ATA\RAID5\2\ARCHIVE_PARTITION_1.NDF', SIZE = 100GB, FILEGROWTH = 0) TO FILEGROUP [ARCHIVE_1] GO ALTER DATABASE Customer MODIFY FILEGROUP [ARCHIVE_1] DEFAULT GO SELECT * INTO iri..Sales_129_ARCHIVE FROM VISF WHERE TIME_KEY = 129 OPTION (MAXDOP 1) Un index en cluster identique à l’index en cluster sur la table partitionnée existante doit être créé sur la nouvelle table afin de permettre le transfert ultérieur vers la table partitionnée. Dans nos tests, nous avons utilisé SELECT/INTO pour transférer la première partition ayant expiré avec 279 millions de lignes vers un ensemble de disques ATA en moins de 20 minutes. La création de l’index en cluster sur la même table a été effectuée en moins de 40 minutes. Haut de page Annexe B : détail des plates-formes Les composants matériels et logiciels suivants ont été utilisés pour les tests décrits dans ce document : Logiciels Microsoft Microsoft Windows Server 2003 Datacenter Edition Build 3790 Microsoft SQL Server 2005 bêta 2 Plate-forme serveur Unisys ES7000 Orion 130 64 bits 16 processeurs Itanium 2 1,30 GHz avec 3 Mo de cache 64 Go de RAM Stockage EMC Symmetrix 5.5 96 disques de 72 Go 10 000 tpm avec 16 Go de cache lecture/écriture EMC CLARiiON FC4700 155 disques de 133,680 Go 10 000 tpm avec 16 Go de cache lecture/écriture 30 disques de 344 Go 5 000 tpm (ATA) Adaptateur de bus hôte 8 adaptateurs de bus hôte Emulex LP9002L 2 Go/seconde Fibre Channel Tous les adaptateurs mis en correspondance avec l'ensemble de stockage CLARiiON faisaient l’objet d’un équilibrage de charge avec le logiciel Powerpath Logiciel de gestion du stockage EMC Powerpath v 3.0.5 Haut de page Annexe C : architecture du serveur Nous avons utilisé un serveur Unisys ES7000 Orion 130 pour nos tests. Il est important de comprendre l’architecture du serveur, car il s’agit d’un des facteurs qui déterminent le débit théorique de votre système. Par exemple, un bus PCI 100 MHz peut offrir un débit de 800 Mbits/seconde. Cette annexe illustre brièvement l’architecture ES7000 Orion. Le serveur d'entreprise ES7000 Orion 130 est un système modulaire monté en rack, basé sur un chipset Intel et des processeurs de la gamme Intel Itanium 2. Le serveur Orion utilisé au cours des tests a été configuré avec 2 modules serveur, 16 processeurs et 64 Go de mémoire. Chaque module serveur comporte un module IOHM (Input/Output Hub Module). Chaque IOHM contrôle un sous-système d’E/S constitué de quatre PCIAM (PCI Adapter Module). Chaque PCIAM comporte 2 bus, desservant chacun 2 logements pour carte PCI. Les cartes PCI sont prises en charge jusqu’à 100 MHz sur chaque bus. Les logements mis en surbrillance sont actuellement configurés. Le logement 2 sur BUS 0-0 et BUS 0-1 sur PCIAM 0-0/IOHM-0 sont configurés pour les disques SCSI locaux et la carte réseau, ce qui laisse 16 logements libres. Huit d’entre eux sont mis en correspondance avec l’ensemble de stockage CLARiiON avec le logiciel Powerpath. Figure 5. Configuration d’E/S du serveur CASSIN utilisé pour ce scénario Voir l’image en taille réelle Haut de page Annexe D : stockage EMC CLARiiON Nous avons utilisé un ensemble de stockage CLARiiON CX600 pour nos tests. Cette annexe décrit la configuration de l’ensemble de stockage utilisé. L’ensemble de stockage CLARiiON est constitué d’un ensemble de tiroirs ou logements. Chaque tiroir peut recevoir jusqu'à 15 disques. Un certain nombre de disques dans les tiroirs sont regroupés afin de constituer un groupe RAID. Le LUN (Logical Unit Number) créé à partir du groupe RAID est exposé au système d'exploitation Microsoft Windows. Si la capacité de stockage doit être augmentée par la suite, des disques peuvent être ajoutés aux tiroirs de stockage et constitués en groupes RAID. Les groupes RAID nouvellement créés peuvent être joints à n'importe quel groupe RAID existant, constituant un méta-LUN exposé au système d'exploitation Windows. Le méta-LUN conserve le numéro de LUN du LUN source. Le modèle dans lequel ces disques physiques sont regroupés en groupes RAID n’affecte pas les performances, car la conception des ensembles de stockage CLARiiON équilibre la charge sur les tiroirs et les disques physiques. L’ensemble de stockage EMC CLARiiON utilisé pour nos tests comporte un mélange de configurations RAID 1+0, RAID 5 et RAID 3. RAID 1+0 est utilisé pour les fichiers journaux de base de données et RAID 5 est utilisé pour les fichiers de données. RAID 3 a été utilisé pour sauvegarder et restaurer les partitions de base de données. Les disques physiques 10 000 tpm présentent une taille de 133 Go, tandis que ceux à 5 000 tpm présentent une taille de 344 Go. Notre configuration de stockage comprenait cinq LUN RAID 1 + 0. Les LUN sont issus d’un groupe RAID constitué de huit disques physiques. Dans la mesure où les disques sont mis en miroir et en bande, la capacité de chacun de ces LUN est d’environ 500 Go ((8*133,680 Go)/2). Deux de ces LUN RAID 1+0 ont été utilisés pour notre fichier journal de base de données. Douze LUN RAID 5 ont été utilisés pour les fichiers de données. Cinq LUN RAID 5 ont été utilisés pour tempdb. Chacun de ces LUN présentait une capacité approximative de 500 Go. Chaque LUN est issu d’un groupe RAID. La configuration RAID 5 est composée de moins de disques que les groupes RAID 1 + 0. Les groupes RAID 5 sont composés de cinq disques de 133 Go. Voici une illustration des groupes RAID et disques organisés dans un ensemble de stockage CLARiiON. Trois disques physiques du tiroir 2 et deux disques physiques du tiroir 1 sont regroupés dans un groupe RAID. Le groupe RAID suivant est constitué par alternance du nombre de disques de chaque tiroir. Les disques physiques sont entrelacés entre les tiroirs, ce qui permet de cantonner les défaillances au niveau tiroir. Figure 6. Configuration CLARiiON RAID 3/5 et des groupes RAID Topologie Pour nos tests, nous avons utilisé la technologie Fibre Channel et nous avons implémenté une topologie standard de type « switched fabric ». Le canal fabric faisait l’objet d’une zone logicielle avec le nom WWN (World Wide Name) des adaptateurs Fibre HBA (Host Bus Adapters) au niveau switch. Les LUN étaient tous masqués afin d’être visibles pour le serveur hôte au niveau du contrôleur de stockage pour ce scénario de test. La figure 7 illustre la mise en correspondance entre le HBA, le port de stockage et les LUN. Dans la mesure où les volumes logiques étaient directement mis en correspondance avec un LUN unique dans notre scénario de test, l’illustration peut être considérée comme une mise en correspondance avec un volume logique. Le logiciel multichemin EMC Powerpath a été utilisé pour l’équilibrage de la charge des E/S entre tous les LUN sur l’ensemble de stockage CLARiiON. Huit des HBA Emulex ont fait l’objet de zones afin de voir tous les LUN issus de l’ensemble de stockage CLARiiON. Pour plus d’informations sur l’installation de HBA Emulex avec le stockage EMC, consultez le site http://www.emulex.com/ts/docoem/framemc.htm Figure 7. Mise en correspondance HBA - port de stockage - volume Voir l’image en taille réelle Haut de page Annexe E : Isolation du stockage . L’isolation du stockage joue un rôle significatif dans les environnements des réseaux de stockage, en particulier lorsque les données sont partagées entre une ou plusieurs applications. Cette annexe décrit certaines considérations relatives à l’isolation du stockage lors du partitionnement de votre data warehouse relationnel. L’exemple de cette annexe met en évidence l’ensemble de stockage EMC Symmetrix utilisé lors de nos tests initiaux. Le volume logique peut être créé à partir de plusieurs disques physiques. De la même façon, plusieurs volumes logiques peuvent être créés à partir du même disque physique. Dans certains cas, plusieurs volumes logiques peuvent être créés à partir d’un ensemble de disques physiques. Cette pratique est surtout courante dans les environnements des réseaux de stockage. Dans EMC Symmetrix, les disques physiques sont logiquement divisés en hyper volumes. Les hyper volumes de plusieurs disques physiques sont regroupés afin de créer un métavolume. Les métavolumes sont regroupés afin de créer un volume logique. Dans cette illustration, les numéros 1 à 32 représentent les disques physiques individuels. Chaque disque physique est divisé en huit hyper volumes de 9 Go. Les hyper volumes 1.1 à 8.1 sont regroupés afin de créer un métavolume. Dans cette illustration, les métavolumes sont numérotés 0001a et 0011a à 0071b. Les métavolumes 0001a et 0001b sont regroupés afin de créer un volume logique. Les disques physiques à droite de la ligne verticale épaisse représentent la paire de miroirs. Figure 8 : Vue logique de l’ensemble de disques de stockage Symmetrix Voir l’image en taille réelle Nous pouvons par exemple créer deux volumes logiques, l’un appelé L1 créé par regroupement des métavolumes 0001a, 0001b et l'autre, appelé L2, créé par regroupement des métavolumes 0011a, 0011b. Si ces volumes logiques connaissent un nombre élevé de demandes d’E/S simultanées, un conflit de disques a lieu, car les hyper volumes sont créés à partir du même ensemble de disques physiques sous-jacents. Pour éviter cela, il importe de prendre soin de créer des partitions pouvant faire l’objet d’un accès simultané sur des volumes logiques et disques physiques isolés. Comme pour la conception du stockage de n'importe quel data warehouse, il existe un équilibre entre l’isolation des données au niveau physique et l’organisation de la conception de sorte que le matériel soit pleinement utilisé. Les données de la partition active et les partitions d’archivage ont été placées sur des axes physiques communs, mais séparés sur des volumes logiques pour la surveillance et la gestion. Une partition active peut être créée sur le volume logique L1 et une partition d’archivage peut être créée sur le volume logique L2. Bien que ces deux partitions soient isolées logiquement, elles partagent le même ensemble d’axes physiques. L’alternative aurait été d’isoler les données actives des données d’archivage au niveau de l'axe physique. Cela aurait permis de réduire le nombre d’axes utilisés pour les partitions de données actives, ce qui aurait pu conduire à une sous-utilisation des axes utilisés pour les partitions d’archivage, car ces données font l’objet d'accès moins fréquents. Avec les périphériques de stockage réseau modernes équipés d’un cache de stockage important et de modèles d’utilisation imprévisibles et partagés, il est préférable de répartir les données sur autant d’axes que nécessaire. Cela permet d’optimiser l’utilisation des ressources et du matériel afin d’offrir des performances acceptables. Configuration du stockage L’ensemble de stockage a été configuré de manière optimale, en étroite collaboration avec les ingénieurs EMC, en fonction des exigences de notre scénario. Nous encourageons nos clients à collaborer étroitement avec leurs fournisseurs de matériel lors de la configuration du stockage pour une implémentation de SQL Server. Haut de page Annexe F : scripts Voici le script utilisé pour créer la base de données, la fonction de partition et le schéma de partition dans l’implémentation de la stratégie II décrite précédemment dans ce livre blanc, dans la section intitulée « Stratégies pour le partitionnement de data warehouses relationnels ». CREATE DATABASE [SALES] ON PRIMARY ( NAME = N'SALES_PRIMARY', FILENAME = N'D:\SALESPrimary\SALES_PRIMARY.MDF', SIZE = 100MB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition1 (NAME = N'SALES_ACTIVE_PARTITION_1', FILENAME = N'F:\RAID5\DATA\1\SALES_ACTIVE_PARTITION_1.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition2 (NAME = N'SALES_ACTIVE_PARTITION_2', FILENAME = N'F:\RAID5\DATA\2\SALES_ACTIVE_PARTITION_2.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition3 (NAME = N'SALES_ACTIVE_PARTITION_3', FILENAME = N'F:\RAID5\DATA\3\SALES_ACTIVE_PARTITION_3.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition4 (NAME = N'SALES_ACTIVE_PARTITION_4', FILENAME = N'F:\RAID5\DATA\4\SALES_ACTIVE_PARTITION_4.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition5 (NAME = N'SALES_ACTIVE_PARTITION_5', FILENAME = N'F:\RAID5\DATA\5\SALES_ACTIVE_PARTITION_5.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition6 (NAME = N'SALES_ACTIVE_PARTITION_6', FILENAME = N'F:\RAID5\DATA\6\SALES_ACTIVE_PARTITION_6.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition7 (NAME = N'SALES_ACTIVE_PARTITION_7', FILENAME = N'F:\RAID5\DATA\7\SALES_ACTIVE_PARTITION_7.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition8 (NAME = N'SALES_ACTIVE_PARTITION_8', FILENAME = N'F:\RAID5\DATA\8\SALES_ACTIVE_PARTITION_8.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition9 (NAME = N'SALES_ACTIVE_PARTITION_9', FILENAME = N'F:\RAID5\DATA\9\SALES_ACTIVE_PARTITION_9.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition10 (NAME = N'SALES_ACTIVE_PARTITION_10', FILENAME = N'F:\RAID5\DATA\10\SALES_ACTIVE_PARTITION_10.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_DIMENSIONS (NAME = N'SALES_DIMENSIONS_1', FILENAME = N'F:\RAID5\DATA\11\SALES_DIMENSIONS_1.NDF', SIZE = 450GB, FILEGROWTH = 0), (NAME = N'SALES_DIMENSIONS_2', FILENAME = N'F:\RAID5\DATA\12\SALES_DIMENSIONS_2.NDF', SIZE = 450GB, FILEGROWTH = 0) LOG ON (NAME = N'SALES_LOG', FILENAME = N'F:\SQL\Path8\SALES_LOG.LDF', SIZE = 120GB, FILEGROWTH = 0) GO CREATE PARTITION FUNCTION SALES_WEEK_PARTITION_FUNCTION (INT) AS RANGE RIGHT FOR VALUES ( 129, 130, 131, 132, 133, 134, 135, 136 ) GO CREATE PARTITION SCHEME SALES_WEEK_PARTITION_SCHEME AS PARTITION SALES_WEEK_PARTITION_FUNCTION TO ( SALES_ActivePartition1, SALES_ActivePartition2, SALES_ActivePartition3, SALES_ActivePartition4, SALES_ActivePartition5, SALES_ActivePartition6, SALES_ActivePartition7, SALES_ActivePartition8, SALES_ActivePartition9, SALES_ActivePartition10 ) GO Voici le script utilisé pour créer la base de données, la fonction de partition et le schéma de partition dans l'implémentation de la stratégie II décrite précédemment dans ce livre blanc. CREATE DATABASE [SALES] ON PRIMARY (NAME = N'SALES_PRIMARY', FILENAME = N'D:\SALESPrimary\SALES_PRIMARY.MDF', SIZE = 100MB, FILEGROWTH = 0), FILEGROUP SALES_ActivePartition (NAME = N'SALES_ACTIVE_PARTITION_1', FILENAME = N'F:\SQL\Path2\1\SALES_ACTIVE_PARTITION_1.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_2', FILENAME = N'F:\SQL\Path2\2\SALES_ACTIVE_PARTITION_2.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_3', FILENAME = N'F:\SQL\Path3\1\SALES_ACTIVE_PARTITION_3.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_4', FILENAME = N'F:\SQL\Path3\2\SALES_ACTIVE_PARTITION_4.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_5', FILENAME = N'F:\SQL\Path4\1\SALES_ACTIVE_PARTITION_5.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_6', FILENAME = N'F:\SQL\Path4\2\SALES_ACTIVE_PARTITION_6.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_7', FILENAME = N'F:\SQL\Path5\1\SALES_ACTIVE_PARTITION_7.NDF', SIZE = 100GB, FILEGROWTH = 0), (NAME = N'SALES_ACTIVE_PARTITION_8', FILENAME = N'F:\SQL\Path6\1\SALES_ACTIVE_PARTITION_8.NDF', SIZE = 100GB, FILEGROWTH = 0), FILEGROUP SALES_DIMENSIONS (NAME = N'SALES_DIMENSIONS_1', FILENAME = N'F:\RAID5\DATA\11\SALES_DIMENSIONS_1.NDF', SIZE = 450GB, FILEGROWTH = 0), (NAME = N'SALES_DIMENSIONS_2', FILENAME = N'F:\RAID5\DATA\12\SALES_DIMENSIONS_2.NDF', SIZE = 450GB, FILEGROWTH = 0), LOG ON (NAME = N'SALES_LOG', FILENAME = N'F:\SQL\Path8\SALES_LOG.LDF', SIZE = 120GB, FILEGROWTH = 0) GO CREATE PARTITION FUNCTION SALES_WEEK_PARTITION_FUNCTION (INT) AS RANGE RIGHT FOR VALUES ( 129, 130, 131, 132, 133, 134, 135, 136 ) GO CREATE PARTITION SCHEME SALES_WEEK_PARTITION_SCHEME AS PARTITION SALES_WEEK_PARTITION_FUNCTION ALL TO (SALES_ActivePartition) GO
