Partitionnement des tables pour l'archivage des données


13

Scénario:

  • deux bases de données: DB_A et DB_Archive avec une très grande table appelée tableA.
  • chaque jour, les enregistrements de plus de 60 jours sont supprimés de DB_A et déplacés vers DB_Archive principalement pour laisser la chose "séparée" car la tableA est fortement interrogée sur DB_A pour les enregistrements des 2 derniers mois.

Je veux me débarrasser de ce processus car il est lent et consomme beaucoup de ressources. Je pense à implémenter le partitionnement de table sur DB_A avec une fonction de partition sur une colonne de date et à stocker tous les enregistrements <2 mois sur une partition et tous les enregistrements> 2 mois sur une autre partition. Mes questions:

  • ce scénario va-t-il se comporter comme si j'avais 2 bases de données différentes? Si je demande à ma tableA des enregistrements> getdate () - 30, est-ce que ça va lire la partition d'archivage?
  • Je suppose que je dois aussi partitionner les index, non?
  • Comment gérer le fait que demain ma fonction de partition "changera", je veux dire, si je crée la fonction aujourd'hui (2 juillet, sa plage sera le 2 mai, mais demain serait le 3 mai). Puis-je créer une fonction de partition dynamique?

Je ne pense pas qu'une fonction dynamique soit une bonne idée même si elle était autorisée (je ne pense pas que ce soit le cas) ... nous pouvons entrer dans les détails sous peu mais je pense que vous devriez probablement partitionner en fonction de la date du calendrier et quitter une partition à la fois ... Mais il existe une variété d'options ici.
JNK

J'ai écrit un exemple dans le sens de ce que vous voulez faire l'année dernière. C'était un cas quelque peu spécial où nous voulions conserver x jours de données sur une matrice rapide (coûteuse) et déplacer les données d'archives vers un stockage moins cher. Si je peux désinfecter un exemple de script, je le publierai, sinon ce ne sera qu'un résumé du processus.
Mark Storey-Smith

salut la marque, oui s'il vous plaît, et si vous pouvez également partager votre expérience. a-t-il réussi?
Diego

Cela fonctionne mais était finalement inutile (nous avons pris un itinéraire plus simple). Peut-être pourriez-vous expliquer pourquoi la limite de 60 jours existe dans votre cas? Cela aiderait tout le monde à vous orienter dans la bonne direction.
Mark Storey-Smith

Réponses:


6

Avec le partitionnement, vous auriez à faire une partition par jour, ce qui place la limite Pre-SQL 2012 de 1000 partitions dans une nouvelle perspective car elle ne permettrait que l'archivage de 3 ans. Avec SQL Server 2012, vous obtenez 15 000 partitions, ce qui est suffisant pour 1 partition par jour.

Chaque jour, vous ajoutiez une nouvelle partition. Si vous souhaitez déplacer la partition du 61e jour, vous pouvez le faire efficacement, mais cela reste une opération hors ligne. Voir Déplacer efficacement une partition vers un autre groupe de fichiers .

Tous vos index devraient être alignés, voir Directives spéciales pour les index partitionnés .

Acheter en partitionnement n'est pas une décision facile et il peut être assez difficile à mâcher ... voir Comment décider si vous devez utiliser le partitionnement de table . Plus précisément, vous ne devez pas vous attendre à des améliorations des performances du partitionnement. Vous devez aborder les problèmes de performances en temps réel en les regroupant par date et heure.


La nouvelle limite est disponible dans 2008 SP2 et 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
Jon Seigel

@Jon: l'implémentation du SP2 2008R2 SP1 en 2008 est accompagnée d' un gros avertissement . As explained in this white paper, there are implications on certain features, including performance. . La prise en charge de SQL 2012 est livrée sans avertissement.
Remus Rusanu

Merci d'avoir fait remarquer cela; c'est vrai qu'il y a quelques mises en garde pour l'utiliser sur 2008/2008 R2, mais c'est une option disponible si nécessaire.
Jon Seigel

Merci pour votre commentaire. Je lirai le commentaire matériel plus tard
Diego

2

Je ne sais pas si la fonction de partition peut être dynamique mais j'en doute. Quelques options pour vous sans emprunter cette voie:

1 - Partitionnez le calendrier DATE et sortez de la plus ancienne partition chaque jour

2 - Créez une vue qui filtre par date et pointez-y toutes vos requêtes existantes (cela peut être facilement géré en renommant la table sous-jacente en quelque chose d'autre et en nommant la vue quel est le nom de la table actuelle). Cela peut également être optimisé avec des changements d'index.

Gardez à l'esprit que la première option ci-dessus fonctionnera beaucoup mieux si vous utilisez le champ date dans vos requêtes. Si vous ne le faites pas, ce sera toujours plus rapide que le processus actuel, mais les requêtes n'auront pas une énorme amélioration. Le partitionnement en général fonctionne mieux si vous pouvez filtrer sur votre champ de partition et que l’optimiseur sait quelle partition regarder.


Je voudrais éviter les opérations manuelles "chaque jour"
Diego

2

Voici ce qui devrait fonctionner pour vous: DB_A - tableA avec une partition différente pour chacun des 60 derniers jours - stagingTable pour déplacer les données de la plus ancienne partition

DB_Archive tableA - stocke toutes les données de plus de 60 jours. (non partitionné)

Processus: 1. avant la fin de la journée: modifier la fonction de partition - fractionner la plage pour ajouter une nouvelle partition pour la nouvelle journée. (NB: au lieu de créer des partitions pour "la date du jour + 1 jour", vous pouvez avoir un peu d'avance. Par exemple: "la date du jour + 5 jours"

  1. Après la fin de chaque journée, vous basculez d'abord la plus ancienne partition de DB_A.tableA vers DB_A.stagingTable; Fusionnez les partitions les plus anciennes.

  2. Importez des données de DB_A.stagingTable vers DB_Archive.tableA. Enfin trunacte DB_A.stagingTable

Ce qui précède est appelé Rolling Window et est un scénario assez courant pour les VLDB. Consultez ce livre blanc de Microsoft sur le partitionnement: stratégies de table et d'index de partition ou essayez-le spécifiquement sur le scénario de fenêtre coulissante


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.