Partitionnement sur un seul groupe de fichiers

J'ai de très grandes tables dans ma base de données, mais une partie substantielle de ces données est "ancienne".

En raison de circonstances indépendantes de ma volonté, je ne suis pas autorisé à supprimer ces "anciennes" données. L'autre limitation est que je ne peux pas modifier la base de données, ce qui signifie y ajouter des groupes de fichiers. Dans l'état actuel des choses, tout réside dans le PRIMARYgroupe de fichiers.

Je pensais à partitionner ces tables en quelques partitions, telles que "nouvelles", "anciennes", "archivées" et similaires. J'ai une colonne "état" que j'aimerais utiliser à cet effet.

Étant donné le scénario et les limitations décrits, je me demandais si le partitionnement avait un sens ici. En d'autres termes, si ma table est partitionnée de cette manière, mais que toutes les partitions se trouvent sur le même groupe de fichiers, SQL Server sera-t-il suffisamment intelligent pour trouver cette zone spéciale dans le fichier sous-jacent où résident mes "nouvelles" données et ne pas toucher le zone avec des "anciennes" données?

Autrement dit, si, disons, 80% de mes données sont "anciennes". SQL Server dispose-t-il d'un mécanisme pour éviter d'accéder à 100% des fichiers sous-jacents et d'accéder à seulement 20% qui contient de "nouvelles" données (en supposant, bien sûr, que je spécifie ma colonne de partitionnement dans la WHEREclause des requêtes).

Je suppose que pour répondre à cela, il faudrait comprendre comment le partitionnement est mis en œuvre en interne. J'apprécie tous les conseils.

Le partitionnement d'une table dans le même groupe de fichiers présente deux avantages:

1. Permet de reconstruire progressivement des parties d'un grand index, ce qui permet une maintenance plus efficace. Consultez le ALTER INDEX [foo] REBUILD PARTITION=npour plus de détails.
2. Tirer parti de l'élimination de la partition et (éventuellement) du verrouillage au niveau de la partition pour améliorer la maintenance des requêtes. J'en discute sur mon blog .

Il y a plusieurs choses à garder à l'esprit si vous partitionnez.

• Si votre table a un index clusterisé (et il le devrait vraiment), votre clé de partitionnement doit faire partie de l'index clusterisé.
• Pour éviter les problèmes de performances, vous devez aligner vos partitions. Cela signifie que tous vos index doivent inclure votre clé de partition, que ce soit en tant qu'inclusion ou en tant que partie de l'index lui-même.
• Les reconstructions d'index pour les partitions sont hors ligne dans les versions actuelles de SQL Server (2005-2012). Si vos partitions sont trop volumineuses et votre reconstruction par partition, cela pourrait entraîner des problèmes de blocage.

Je recommande de faire des recherches approfondies sur le partitionnement avant de l'implémenter. Kendra Little a une excellente liste de ressources où vous pouvez commencer.

La réponse est oui". Il a un mécanisme sur toute requête qui filtre les entrées en fonction de la logique utilisée pour définir les partitions.

Vous devez cependant avoir le filtre approprié, sinon toute la partition sera analysée. Cela impliquerait généralement d'avoir des filtres de date (dans votre cas) pour choisir la partition.

Une façon de faire respecter cela est d'avoir des vues qui accèdent à une seule partition, avec la bonne logique dans la vue.