Choix de colonne pour le partitionnement

bonjour a tous
afin d’accélérer le processus de suppression des données qui ne sont plus utiles et Optimiser certaines requêtes je viens aujourd’hui de penser sur la fonction du partitionement pour les grand tables
Dans l'interface d'assistant j'était devant le choix du colonne du partitionnement
Dans mon cas seul le colonne "id_h" est inclus dans un index ordonnées (CLUSTERED)
mon question est le suivant Est il est nécessaire que la clé de partitionnement soit incluse dans la définition de cet index ? OU Je peut choisir n'importe quel autre colonne ? Si oui est ce que le choix du clé de partitionnement a un impact sur la performance ?
merci pour l'aide de nos experts

L'intérêt principal du partitionnement est de pouvoir travailler sur des sous-ensembles cohérents de données, d'un point de vue fonctionnel. Par exemple regrouper des factures par mois d'émission.
C'est donc le premier élément à prendre en compte pour choisir la clé de partitionnement.
Ensuite ce partitionnement aura un impact sur l'organisation physique de la table... qui sera "découpée" en fonction de cette clé de partitionement. Il faut donc partir du besoin fonctionnel (je veux pouvoir travailler sur les factures d'un mois donné sans naviguer à travers toute la table, supprimer toutes le lignes d'un mois sans la désorganiser...) et pas des contraintes techniques existantes. De toute façon, celles-ci seront impactées.

La clef de partitionnement peut être celle de votre index existant mais vous êtes libre de créer un autre index.

Le partitionnement consiste à créer des tablespace différents pour chaque partition, il y a un impact bénéfique sur les perfs :
- moins de contention grâce aux espaces distincts
- possibilité de paralléliser des travaux batch plutôt que de traiter en séquence
- possibilité de passer des utilitaires sur des partitions pendant que d'autres sont ouvertes aux applications

Exemple d'utilisation : une multinationale possède des agences dans différents pays, avec des fuseaux horaires différents. On peut passer les batchs avec un critère fonctionnel identifiant l'agence et par là même le fuseau horaire adéquat pour les traitements batch, sans perturber le fonctionnement des agences ouvertes des autres fuseaux horaires.

Avant même de parler de partitionnement tu pourrais nous donner ton contexte dans les grandes lignes ?
Quels sont les raisons qui motivent ce partitionnement ? Administration, performances ...

Je demande cela car partitionner introduit une certaine complexité de gestion et les plans d'exécutions sont beaucoup plus complexes ..

++

c'est pour Supprimer de gros volume de données grâce au partitionnement ce ci dont le but d'éviter l'opération delete
le but c'est de profiteer l'opération switch vers une dexiéme table intermédiére puis faire un truncate

Citation:

---

c'est pour Supprimer de gros volume de données grâce au partitionnement ce ci dont le but d'éviter l'opération delete
le but c'est de profiteer l'opération switch vers une dexiéme table intermédiére puis faire un truncate

---

Est-ce une opération récurrente ou qui sera exceptionnelle ?
Quelle quantité de données va être supprimée par rapport au volume global (10 - 20 - 80%) ?

++

il serai une opération récurrente , ce ci dont le cas ou on détecte une saturation disque

on estime une suppression de 80% du data

Je n'ai pas idée de la volumétrie que cela représente chez toi mais dans ce cas ne serait il pas plus simple de créer une autre table à l'identique et d'insérer les 20% de données qui doivent rester (en mode bulk), supprimer l'ancienne table et renommer la nouvelle table avec l'ancien nom (et d'ajouter tous les objets dépends par la suite .. index, contraintes, etc ...)?

Autre idée .. avoir une routine de suppression régulière qui s'exécute selon une planification définie .. Suppression effectuées par petits lots pour éviter de verrouiller l'ensemble de la table et de faire grossir de manière trop importante le fichier journal de ta base ?


Quelle est la nature de la donnée que tu veux supprimer? Des logs applications? Un historique de quelque chose? Quoi qu'il en soit ces données ont l'air plus de te gêner qu'elles sont réellement utiles non ? Peut être voir côté applicatif s'ils ne peuvent pas réduire cet affût de données dans ta base ?

++

Si vous devez régulièrement supprimer 80% des données ce qui est beaucoup, et si vous disposez d'une plage de travaux batch dans laquelle vous pouvez rendre la base non disponible, vous pouvez aussi
- décharger votre table sur un fichier
- supprimer les enregistrements de ce fichier
- trier le fichier résultant selon la clef cluster
- recharger en mode replace ce fichier dans la table

Vous avez ainsi un table-space réorganisé ET purgé a peu de frais, et vous n'avez pas chargé inutilement la log contrairement avec ce qui se passe lors de delete en masse
les 3 premières étapes ne nécessitent pas l'arrêt complet des applis, mais seulement la mise en lecture seule, l'étape 4 par contre est exclusive

Citation:

---

Envoyé par abdallah_mehdoini

c'est pour Supprimer de gros volume de données grâce au partitionnement ce ci dont le but d'éviter l'opération delete
le but c'est de profiteer l'opération switch vers une dexiéme table intermédiére puis faire un truncate

---

Vous vous méprenez sur le partitionnement. Ce n'est pas fait en différentes tables contrairement à certaines solutions brouillonnes du style PostGreSQL... Mais au sein de la même table et il n'est donc pas possible de faire un TRUNCATE d'une partition.

Néanmoins il est possible de faire ce que vous évoquez par des moyens détournés. Par exemple "abandonner" une partition d'une table partitionnée. Cela reste néanmoins une pratique délicate non supportée par MS.

A +