partitionnement sql server

bonjour a tous
Si je fait une action du partitionnement d'un table sans changer l’emplacement physique c'est dire je travaille toujours sur le même Groupe du Fichier primary qui est aussi positionner sur la même emplacement du disque
Est ce que ma action du partitionnement ne va pas donner d'amélioration en terme performance
Est ce que chaque action du partitionnement doivent être associer avant par la création d'un deuxième Group du fichier qui est aussi doit être mis sur un disque physique dédier
MERCI

Très peu au final. Le seul intérêt étant qu'en cas d'escalade de verrou la montée se fait primairement à la partition avant la table quand c'est possible.

A +

Bonjour,

Je serais moins formel que SQLPro.

Le partitionnement, en terme de performances, c'est deux principaux atouts:

• Elimination des partitions non pertinentes. Dans une requête qui contient un filtre sur la colonne partitionnée, le moteur ne brassera pas les partitions qui ne correspondent pas au filtre. Moins de données brassées = meilleure performance. Ceci est valable même lorsque les partitions sont dans le même groupe de fichiers.
• Parallélisme. Dans une requête qui ne contient pas de filtre sur la colonne partitionnée, le moteur peut "éclater" certaines opérations en plusieurs opérations parallèles. Il s'agira ici de brasser des données en parallèle, la performance sera meilleure lorsque les données seront positionnées sur des disques physiques différents (et pas sur des groupes de fichiers placés sur les mêmes disques...).

Vous trouverez un complément d'informations sur le sujet dans cet article.

Je serais moins affirmatif que bvesan... !

Citation:

---

Envoyé par bvesan

Bonjour,

Je serais moins formel que SQLPro.

Le partitionnement, en terme de performances, c'est deux principaux atouts:

• Elimination des partitions non pertinentes. Dans une requête qui contient un filtre sur la colonne partitionnée, le moteur ne brassera pas les partitions qui ne correspondent pas au filtre. Moins de données brassées = meilleure performance. Ceci est valable même lorsque les partitions sont dans le même groupe de fichiers.

---

Tout dépend des requêtes. Si toutes vos requêtes passent la colonne de partitionnement dans un prédicat alors oui. mais en pratique c'est loin d'être le cas. Et un index, fait encore mieux !

Citation:

---

• Parallélisme. Dans une requête qui ne contient pas de filtre sur la colonne partitionnée, le moteur peut "éclater" certaines opérations en plusieurs opérations parallèles. Il s'agira ici de brasser des données en parallèle, la performance sera meilleure lorsque les données seront positionnées sur des disques physiques différents (et pas sur des groupes de fichiers placés sur les mêmes disques...).

---

SQL Server faisant naturellement du parallélisme lors des accès aux tables et notamment lorsque les tables sont grosses et les données à rapporter importante, il n'ay a donc pas de grosse différence avec une table partitionné.

MAIS, là ou c'est pire, c'est sur de petite tables, car les plans de requêtes sont plus complexes et mettent plus de temps à être calculés !

Bref, il faut tester ! mais tester tout (avant et après partitionnement) et sur un volume réel....

A +

Citation:

---

Envoyé par SQLpro

SQL Server faisant naturellement du parallélisme lors des accès aux tables et notamment lorsque les tables sont grosses et les données à rapporter importante, il n'ay a donc pas de grosse différence avec une table partitionné.

---

Je pensais plutôt au parallélisme sur jointure de tables: Parallel Hash Join et Parallel Merge Join lorsqu'une des deux tables est partitionnée, et Collocated Joins (jointures par partitions) lorsque les deux tables suivent le même schéma de partition.
Un article intéressant sur le sujet (en anglais)..
A noter que l'on gagnera aussi en finesse de statistiques puisque ces dernières existent pour chaque partition d'une table ou d'un indexe partitionné...

Citation:

---

Envoyé par bvesan

Je pensais plutôt au parallélisme sur jointure de tables: Parallel Hash Join et Parallel Merge Join lorsqu'une des deux tables est partitionnée, et Collocated Joins (jointures par partitions) lorsque les deux tables suivent le même schéma de partition.

---

Mais ce sont des algorithmes massivement plus lours donc intéressant sur de gros volumes sur lesquels les partitions seront sur différents storage physiques

Citation:

---

Un article intéressant sur le sujet (en anglais)..
A noter que l'on gagnera aussi en finesse de statistiques puisque ces dernières existent pour chaque partition d'une table ou d'un indexe partitionné...

---

Tout dépend de la dispersion des données... Si tu partitionne par année et non par date, aucun intérêt !

A +