Discussion :

[joKED]

Bonjour à tous

J'ai une table volumineuse (environ 20Millions de lignes), que j'ai positionné dans un fichier .ndf, dans un filegroup distinct, sur un disque rapide.

Cependant, du fait des nombreux accès à cette table, je souhaiterais encore améliorer les performances. Mes indexs fonctionnent bien, et les temps d'accès sont corrects, cependant, en parcourant divers sites ainsi que la msdn, je suis tombé sur divers articles concernant le partionnement de tables, chose que je souhaiterais mettre en place, vu que ce système est recommandé pour les tables volumineuses et dont les accès sont nombreux.

Cependant, j'ai assez de mal à comprendre le fonctionnement du système.

Soit ma table T_Essai, contenant les colonnes suivantes :
IdEssai int PK
Resultat int
Horodatage datetime

Les utilisateurs veulent très souvent consulter les derniers résultats (ceux du mois en cours), et plus rarement ceux des mois précédents. en gros, 70% des demandes sur le mois en cours, 30% pour les mois antérieurs.

Si j'ai bien compris, il est possible de partitionner la table de telle sorte qu'on ait les résultats courants dans une partition, et les résultats anciens dans une autre.

Ma question : Quid de l'ajout? Si j'avance dans le temps, mes données vieillissent, mais elles ne seront pas déplacées dans l'autre partition. Donc je n'y gagne rien? A moins de créer une partition automatiquement à chaque changement de mois ? Auquel cas, comment implémenter ce fonctionnement?

Merci de vos éclaircissements, j'ai vraiment du mal à avec ce concept

[Babyneedle]

Bonjour,

J'utilise le partionnement pour deux raisons.

Pour la performance quand j'ai un nombre élévé de petites requêtes sur l'ensemble d'une table. Je fais alors un partionnement logique, comme par exemple, la première lettre du nom de famille. Une requête ne sera pas plus rapide, par contre (avec la configuration serveur appropriée) un groupe de 50 requêtes simultanées sera terminé 12-16 fois plus vite.

Pour l'entretien des disques. Quand des données ne sont plus nécessaires, des processus automatisés détachent la partition et la transporte dans un datastore. L'exemple le plus fréquent est l'historique des actions des utilisateurs. Une fois le mois courant passé et que les cubes sont à jour, la partition finit sur un DVD.

Dans ton cas précis, le partionnement n'aidera en rien à la performance s'il existe déjà des index sur un champ date et que les requêtes utilisent cette colonne.

Voici un lien qui va t'éclairer:

Partitioning

[SQLpro]

Attention, le partitionnement n'a d'intérêt que si les différentes partitions SONT SUR DES DISQUES PHYSIQUES DIFFÉRENTS...
Si les partitions restent sur le même disque, alors cela dégrade les performances.

Pour faire en sorte que les résultats les plus récents soient situés dans une partition, il va falloir administrer votre partition en faisant régulièrement glisser les partitions les unes dans les autres à l'aide des commandes MERGE et SPLIT et cela de manière régulière (chose que l'on peut planifier dans l'agent SQL Server).

Au fait quand vous parlez de millions de lignes, cela ne veut rien dire...
20 millions de lignes constitué de :
IdEssai int PK
Resultat int
Horodatage datetime
ne représente en fait que 305Mo. Excusez moi, mais c'est une toute petite table. Inutile de partir sur du partitionnement.
ordinairement la partitionnement n'a d'intérêt que si la taille de la fenêtre des données exploitées de la table est supérieur à la RAM du serveur. Donc au moins des partitions de quelques Goctets !!!
Si vous faites du partitionnement sur de si petites tables, cela sera contre performants...

Avez vous pensé au moins à créer pour votre base,d es fichiers de tailles fixe dimensionnés de manière a recevoir au moins 3 années d'exploitation ?
Cela serait beaucoup plus efficace !

A +

[nicorem]

Bonjour,

je dois avoir à peu près la même problèmatique, vous parlez de créer la base avec des fichiers de tailles fixes !

j'ai du mal à comprendre l'interet ou le principe
est-ce que ça veut dire qu'on donne une taille limite au fichier et qu'une fois cette taille atteinte, un nouveau fichier sera créé automatiquement ? ainsi dans le fichier le plus récent, on aura également les données les plus récentes, qui sont généralement les plus requetées.
si oui, comment faire pour créer ces fichiers ?

merci de votre réponse

Attention, le partitionnement n'a d'intérêt que si les différentes partitions SONT SUR DES DISQUES PHYSIQUES DIFFÉRENTS...
Si les partitions restent sur le même disque, alors cela dégrade les performances.

Pour faire en sorte que les résultats les plus récents soient situés dans une partition, il va falloir administrer votre partition en faisant régulièrement glisser les partitions les unes dans les autres à l'aide des commandes MERGE et SPLIT et cela de manière régulière (chose que l'on peut planifier dans l'agent SQL Server).

Au fait quand vous parlez de millions de lignes, cela ne veut rien dire...
20 millions de lignes constitué de :
IdEssai int PK
Resultat int
Horodatage datetime
ne représente en fait que 305Mo. Excusez moi, mais c'est une toute petite table. Inutile de partir sur du partitionnement.
ordinairement la partitionnement n'a d'intérêt que si la taille de la fenêtre des données exploitées de la table est supérieur à la RAM du serveur. Donc au moins des partitions de quelques Goctets !!!
Si vous faites du partitionnement sur de si petites tables, cela sera contre performants...

Avez vous pensé au moins à créer pour votre base,d es fichiers de tailles fixe dimensionnés de manière a recevoir au moins 3 années d'exploitation ?
Cela serait beaucoup plus efficace !

A +

[SQLpro]

vous parlez de créer la base avec des fichiers de tailles fixes !
j'ai du mal à comprendre l'interet ou le principe

C'est simple, il n'y aura plus d'opération de croissance de fichier puisque le fichier aura été suffsament dimensionné !

Lisez le blog que j'ai écrit et faite le test !
http://blog.developpez.com/sqlpro?ti..._fichiers_et_t

est-ce que ça veut dire qu'on donne une taille limite au fichier et qu'une fois cette taille atteinte, un nouveau fichier sera créé automatiquement ?

Pas du tout. Une fois rempli la base ne fonctionnera plus. D'où l'intérêt :
1) de prévoir large (3 à 5 ans d'exploitation)
2) de prévoir une porte de sortie : un pas de croissance de 25 Mo par exemple
3) d'auditer régulièrement l'espace occupé dans les fichiers

si oui, comment faire pour créer ces fichiers ?

ALTER DATABASE ... ALTER FILE ...

A +

[nicorem]

Ok merci d'avoir répondu
par contre ma base étant sur un serveur web ,je fais un backup quotidien
ça veut dire que je vais devoir rapatrier chaque nuit 100 mo, au lieu des 5 mo actuelles.
à moins que je fasse désormais des backup différentielles plutot que "full", mais ça me fait un peu peur le différentielle. est-ce que mes craintes sont fondées, ou est-ce que c'est aussi efficace et surtout sûr ?
autre chose, si j'agrandis le fichier alors que ma base est déjà en production, je ne risque pas de tout planter.
en tout cas un grand merci pour votre réponse, je vois que vous êtes un des meilleurs experts francophone, à chacune de mes recherches sur sql server dans google , je tombe sur votre nom

[SQLpro]

ça veut dire que je vais devoir rapatrier chaque nuit 100 mo, au lieu des 5 mo actuelles.

Une sauvegarde n'est pas une copie de fichiers !!!! Les bases de données ne travaillent sur des concepts de fichiers. mais sur des données structurées dans des pages. Quand vous faites une sauvegarde, vous enregistrez dans un nouveau fichier les pages de la base. Donc le seul volume utilisé. Lorsque vous restaurez il y a recréation des fichiers originaux et mise en place des pages de données dans le fichier...

A +