Avoir plusieurs fichiers de données/journaux est-il une bonne chose même sur le même LUN?

Question

J'ai lu que c'est une bonne idée d'avoir un fichier par CPU/Core Core afin que SQL puisse streamer plus efficacement les données vers et à partir des disques. Ok, je peux voir l'avantage si elles sont sur des broches différentes, mais si j'ai seulement une broche (4 disques dans Raid 10) pour mes fichiers de données (.mdf et .ndf), vais-je encore bénéficier de la division des fichiers de données (à partir du fichier .mdf à un fichier .mdf et plusieurs fichiers .ndf)? Il en va de même pour le fichier journal, même si je ne vois aucun avantage car les données doivent être écrites en série et vous êtes limité par la vitesse d'écriture séquentielle de la broche ...

FYI, ceci concerne SQL Server 2005/2008 ...

Merci.

Answer 1

La recommandation pour plusieurs fichiers de données tempdb ne concerne absolument pas les IOPS. Il s'agit de conflit sur les pages d'allocation (GAM, SGAM, PFS) dans tempdb. SQL 2005+ ne nécessite pas une charge aussi importante sur ces pages, mais un conflit persiste. Tous les systèmes n'ont pas besoin d'un mappage de 1 fichier vers 1. La plupart des systèmes fonctionneront bien avec 1 fichier à 2 ou 4 cœurs. Avoir trop de fichiers ajoute une surcharge pour la gestion des fichiers. Une bonne recommandation est de commencer avec 1: 4 ou 1: 2 et augmente si la contention se poursuit. Ne pas aller au-dessus de 1: 1.

Pour d'autres bases de données, cela n'est pas recommandé.

Et oui, seulement 1 fichier journal ... toujours.

Answer 2

Toujours bien. Il ne s'agit pas d'IOPS - il s'agit de SQL Server BLOQUANT un fichier pour certaines opérations. surtout lorsque les extensions de fichier sont allouées à une table/index. Si vous faites beaucoup d'insertions/mises à jour, plusieurs fichiers signifient qu'un autre thread bloquera un autre fichier, et non le premier. Donc, il ne s'agit pas vraiment de charges IOPS, mais d'un comportement de blocage.

Answer 3

8 Steps to better Transaction Log throughput:

Créer uniquement Un fichier journal des transactions. Même si vous pouvez créer plusieurs fichiers journaux de transactions , vous n'avez besoin que de ... SQL Server NE "stripe" pas entre plusieurs fichiers journaux de transactions. Au lieu de cela, SQL Server utilise les fichiers journaux des transactions de manière séquentielle.

Misconceptions around TF 1118:

Pourquoi l'indicateur de trace pas nécessaire si beaucoup en 2005 et 2008? Dans SQL Server 2005, mon équipe a modifié le système d'allocation pour tempdb afin de réduire la possibilité de conflit . Il y a maintenant un cache de tables temporaires. Quand une nouvelle table temporaire est créé sur un système froid (juste après le démarrage), il utilise le même mécanisme que pour SQL 2000. Quand il est a chuté si, au lieu de toutes les pages étant désallouées complètement, une page IAM et une page de données sont allouées et la table temporaire est placée dans un cache spécial. Les créations de table temporaires suivantes vont chercher dans le cache pour voir si elles peuvent simplement saisir une table temporaire pré-créée 'sur l'étagère '. Si c'est le cas, cela évite d'accéder complètement aux bitmaps d'allocation . Le cache de table temporaire n'est pas énorme (je pense que c'est 32 tables), mais cela peut encore conduire à big laisser tomber dans le verrou contention dans tempdb.

Donc la réponse est NON aux deux questions. La segmentation des logs n'a jamais été un problème, et le NDF-par-CPU est en grande partie un mythe, qui prendra beaucoup de temps à s'éteindre. Plusieurs fichiers à mon humble avis ont un sens seulement si vous pouvez rayer IO (séparer les LUN).Plusieurs groupes de fichiers mais ont un sens, mais pas pour des raisons d'E/S, à des fins administratives: piecemeal restores et archiver les groupes de fichiers en lecture seule.