Quand les index non cluster doivent-ils être stockés sur des groupes de fichiers séparés?

J'ai entendu dire que le stockage d'index sur un groupe de fichiers et un lecteur différents augmente les performances dans une base de données car le lecteur n'a pas à faire la navette entre l'index et les données auxquelles l'index fait référence. J'ai également entendu dire que c'est un mythe.

Quand est-il conseillé de stocker des index non cluster sur un groupe de fichiers et un lecteur séparés? Quelle preuve perfmon / profiler me conduirait à arriver à cette conclusion? Le matériel joue-t-il un rôle dans la décision (si un RAID / SAN est utilisé sur un seul disque)?

La partie la plus lente d'un système de base de données est les unités de disque. L'élimination des goulots d'étranglement au niveau du disque améliorera les performances. Lorsque des données sont recherchées et qu'un index est utilisé, l'index est d'abord recherché, puis les données correspondantes sont extraites. Si à la fois l'index et les données se trouvent sur les mêmes disques, il y a un conflit. Alors que, si les données se trouvaient sur un autre disque (physique), les entrées-sorties sont plus rapides, augmentant ainsi les performances. La partie principale à noter est que les données ou index se trouvent sur des disques physiques ou LUN distincts.

Vous utiliseriez un tel scénario si vous avez besoin d'obtenir de meilleures performances de votre système, à condition que vous ayez les disques. Pour vos compteurs perfmon vous pouvez utiliser Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/secd'avoir une comparaison avant et après vos modifications.

Il est certainement vrai que la répartition de vos E / S simultanées entre différents lecteurs augmentera les performances - ce n'est pas un mythe. C'est un mythe que de le faire deux fois améliorera à nouveau les performances.

Si vous MÊME , alors diviser votre tableau en deux partitions et mettre des index sur une et des tables sur une autre est une perte de temps.

Séparation des index des données sur des groupes de fichiers séparés = l'amélioration des performances est hautement discutable. L'amélioration des performances "peut" se produire si vous avez le matériel sous-jacent pour le prendre en charge, mais simplement par le fait que les séparer en différents groupes de fichiers ne vous donne pas un coup de fouet. Et il n'est pas non plus facile de mesurer le boost de perf à cause de cela.

Réf: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx

Vous devez d'abord poser la question. Pourquoi avez-vous besoin de faire ça?

1. Cherchez-vous à améliorer les performances des sauvegardes en N'incluant PAS les index?
2. Cherchez-vous à améliorer les performances de lecture et d'écriture sur ces index?
3. Faites-vous cela pour une meilleure gérabilité de placement des objets sous-jacents?
4. Avez-vous de gros volumes de données qui ont des besoins de performances variables?
5. Cherchez-vous à utiliser des disques SSD pour des index non cluster pour améliorer les performances, etc.

J'ai regardé cette tâche pour soutenir le besoin de # 5 dans la liste ci-dessus et cela semble être une bonne proposition pour moi bien que nous n'ayons pas encore donné suite à cela.

Notez que cette décision n'est PAS facile à prendre et que vous devez comprendre ce que vous essayez de faire et vous assurer que vous avez le matériel à prendre en charge. Ne faites pas de changements comme celui-ci à moins d'avoir bien testé et que vous voyez une amélioration significative de la performance, sinon vous pourriez aussi bien abandonner cette idée. Cela ne vaut pas la peine si vous vous attendez à une amélioration de la performance en séparant simplement les index sur des groupes de fichiers distincts.

Je vais vous raconter mon expérience personnelle concernant cet article. Les index non clusterisés doivent être stockés sur un groupe de fichiers séparé lorsque le lecteur de disque actuel n'est pas assez grand pour l'espace nécessaire :-). Vous pouvez en rire .. mais ça arrive.

Ainsi, une solution d'urgence pour nous, lorsque nous étions sur le point de rester sans espace libre sur un lecteur de données, était de créer un joli script pour recréer tous les index non clusterisés en ligne sur un nouveau groupe de fichiers sur un lecteur avec de l'espace libre. On pourrait penser que c'est facile et rapide d'acheter un nouveau stockage .. mais ce n'est pas vraiment ça.

En ce qui concerne les performances, nous n'avons rien vu d'extraordinaire après le déménagement. Mais c'est une grande boîte de stockage SAN où tout est réuni :-).

En général; le fractionnement des données et des index sur des disques distincts ayant des performances similaires peut augmenter les performances pour des opérations d'écriture substantielles sur cette table ou des opérations de lecture volumineuses qui utilisent cet index. Une méthodologie similaire à certaines autres opérations d'E / S, comme une table partitionnée répartie sur plusieurs disques physiques.

Cependant, il dépend également largement du stockage . Par exemple; si vous avez un serveur avec un joli ioDrive Fushion (ou quelque chose de similaire) et avez également des disques de rotation individuels. Il pourrait être plus avantageux de tout garder sur l'ioDrive (sauf si l'espace est limité). Il y a aussi d'autres choses à prendre en considération - configuration RAID, configuration de stockage réseau.

Effectuez un certain benchmarking sur un serveur de test avec un matériel similaire ou (uniquement si un serveur secondaire n'est pas une option) pendant les heures creuses avec des données temporaires. Le lien DBA-Monkey de Sankar ci-dessus est un bon sujet de réflexion.