4 votes

MS SQL Layout pour de meilleures performances

Nous avons acheté un nouveau serveur qui servira de backend à MS SQL. Je suis curieux de savoir quelle serait la meilleure configuration pour ce serveur.

Le serveur est un Dell R710 qui possède 6 disques durs : 2x 74GB 15k et 4x 146GB 15k.

Il est actuellement installé dans une configuration RAID 1/Raid10.

Ma question est de savoir où (quel tableau) les éléments suivants doivent être placés ?

TEMPDB (nombre, taille et croissance) Bases de données système (maître, modèle, etc.) MDF d'application LDF d'application Fichier de pages du système

Le système d'exploitation est déjà installé sur le RAID1.

13voto

Bob Points 34449

TempDB

J'ai fait des recherches il y a quelque temps sur l'optimisation de tempdb et j'ai répondu à mes propres questions. question sur Stackoverflow . Voici ce que j'ai découvert.

Afin d'optimiser les performances de tempdb, il convient de prêter attention à la configuration du disque physique, à la configuration des fichiers, ainsi qu'à certains paramètres de la base de données.

Configuration du disque physique

tempdb doit résider sur son ses propres disques physiques dédiés . Cela lui permet de séparer les transactions d'entrée/sortie du reste des volumes sur le serveur SQL.

Pour déplacer tempdb vers une nouvelle unité de disque, utilisez la commande suivante ALTER DATABASE . Il s'agit de la commande T-SQL clé pour effectuer cette opération. Microsoft propose un bon exemple dans SQL Server 2005 Books Online. Le nom de l'article est ALTER DATABASE (Transact-SQL) et la section spécifique est G. Moving tempdb to a new location".

La base de données tempdb est une base de données à très forte capacité d'écriture. Par conséquent, une matrice RAID 5 n'est pas l'endroit approprié pour elle. Vous devez placer la base de données tempdb sur une matrice RAID 1 ou RAID 10 car ils sont optimisés pour les applications à forte capacité d'écriture. Si vous pouvez vous permettre d'utiliser des matrices RAID 1 ou RAID 10 supplémentaires pour chaque fichier de base de données physique pour la tempdb, vous obtiendrez des performances accrues.

Fichiers de base de données

Vous devez avoir un fichier physique par cœur de processeur dans le serveur . Ainsi, si vous disposez d'un serveur à double puce et à double cœur, vous devez avoir quatre fichiers de base de données physiques pour la base de données tempdb. Lorsque vous ajoutez des fichiers de base de données supplémentaires, il est important de configurer les fichiers au niveau de l'onglet la même taille initiale et les mêmes paramètres de croissance . De cette manière, SQL Server écrira les données dans les fichiers de la manière la plus homogène possible.

Taille du fichier de la base de données

La taille de la base de données tempdb peut affecter les performances d'un système. Par exemple, si la taille définie pour tempdb est trop petite, une partie de la charge de traitement du système peut se retrouver dans la base de données tempdb. pris en charge par la croissance automatique de tempdb jusqu'à la taille requise pour supporter la charge de travail à chaque fois que vous redémarrez l'instance de SQL Server. . Vous pouvez éviter cette surcharge en augmentant la taille des données tempdb et du fichier journal.

La détermination de la taille appropriée de tempdb dans un environnement de production dépend de nombreux facteurs, notamment de la charge de travail existante et des fonctions SQL Server utilisées. Microsoft recommande d'analyser la charge de travail existante en effectuant les tâches suivantes dans un serveur SQL test l'environnement :

  1. Activer la croissance automatique pour tempdb (dans un environnement de test !) .
  2. Exécutez des requêtes individuelles ou des fichiers de suivi de la charge de travail et surveillez l'utilisation de l'espace tempdb.
  3. Exécuter des opérations de maintenance d'index, telles que la reconstruction d'index, et surveiller l'espace tempdb.
  4. Utilisez les valeurs d'utilisation de l'espace des étapes précédentes pour prévoir l'utilisation totale de votre charge de travail ; ajustez cette valeur en fonction de l'activité simultanée prévue, puis définissez la taille de tempdb en conséquence.

La taille minimale recommandée pour tempdb est la suivante :

  Envir. Size  DB Size (MB)  Log Size (MB)
  -----------  ------------  -----------
  Small                1024            256
  Medium               5120           1024
  Large               10024           2048

Paramètres de la base de données

Vous pouvez encore améliorer les performances de tempdb en désactivation de la mise à jour automatique des statistiques ce qui épargnera du travail à votre tempdb. Vous pouvez également définir l'option option de création automatique de statistiques à false .

Avertissement : les réglages doivent être modifiés avec précaution. En fonction de la charge que vous faites peser sur votre tempdb, la modification des paramètres peut avoir un impact négatif sur les performances du système.

Pour obtenir des performances optimales de tempdb, suivez les lignes directrices et les recommandations fournies dans le document Optimiser les performances de tempdb .

Comment surveiller l'utilisation de tempdb ?

La course à pied manque d'espace disque dans la base de données tempdb peut provoquer des perturbations importantes dans l'environnement de production du serveur SQL et peut empêcher les applications en cours d'exécution de terminer leurs opérations.

Vous pouvez utiliser le sys.dm_db_file_space_usage pour surveiller l'espace disque utilisé par ces fonctionnalités dans les fichiers tempdb. En outre, pour surveiller l'activité d'allocation ou de désallocation de pages dans tempdb au niveau de la session ou de la tâche, vous pouvez utiliser la fonction sys.dm_db_session_space_usage y sys.dm_db_task_space_usage des vues de gestion dynamiques.

Ces vues peuvent être utilisées pour identifier les requêtes volumineuses, les tables temporaires ou les variables de table qui utilisent beaucoup d'espace disque tempdb. Il existe également plusieurs compteurs qui peuvent être utilisés pour surveiller l'espace libre disponible dans tempdb et les ressources qui utilisent tempdb.

Liens :

2voto

SuperCoolMoss Points 1252

Je mettrais le système d'exploitation, le fichier de pagination et le(s) LDF sur la matrice RAID1. Tout le reste sur la matrice RAID10.

Si vous n'utilisez pas Windows 2008, assurez-vous que vos partitions sont correctement alignées :

http://msdn.microsoft.com/en-us/library/dd758814.aspx

Comme expliqué précédemment, ajoutez un fichier TEMPDB par cœur de processeur - faites en sorte qu'ils aient tous la même taille.

Dimensionnez vos fichiers journaux de manière appropriée et créez-les en une seule étape.

Envisagez de sauvegarder vos bases de données sur un autre serveur via un partage de réseau si possible, afin de réduire le risque que votre baie tombe en panne et entraîne avec elle votre base de données et vos sauvegardes.

1voto

Joe Chin Points 306

La réponse générique la plus simple est que tout ce qui implique une grande quantité d'E/S doit être placé sur le groupe de disques RAID 10. Avez-vous également décidé de votre stratégie de partitionnement ou de cette partie de la question ?

Dans votre premier groupe de disques, je créerais probablement une partition unique (environ 70 Go utilisables) sur laquelle je placerais le système d'exploitation et l'application MSSQL.

Sur le second, je créerais les partitions suivantes

1) partition pour le fichier de pages (en fonction de la quantité de mémoire dont vous disposez, mais environ 10-20 Go) 2) partition pour les fichiers journaux des transactions 100GB 3) partition pour les fichiers de données 100GB

Cela vous laissera environ 50 Go de libre que je laisserais non affectés afin que vous puissiez augmenter soit la partition des journaux, soit celle des données, en fonction de l'évolution de vos besoins.

Il est intéressant de noter que je travaille actuellement sur la même machine, mais que j'utilise Linux et Oracle.

Jacques

1voto

JohnMcG Points 5062

Les réponses ont été excellentes jusqu'à présent, je ne prendrai donc pas la peine d'en rédiger une, mais je vous poserai une question.

Pourquoi n'avez-vous pas posé cette question avant d'acheter le serveur ? Pourquoi essayez-vous de faire entrer un système dans un serveur déjà acheté au lieu d'acheter un serveur adapté aux besoins du système ?

1voto

Garrett Points 196

Désolé, j'ai posé cette question en tant qu'utilisateur non enregistré et je ne peux pas la marquer comme répondue. J'attends le retour des administrateurs pour voir s'ils peuvent rattacher mon compte à la question.

Pour en savoir plus, ce serveur ne sera pas soumis à une charge énorme, il s'agit en fait d'un backend de contrôle de source. L'achat d'un serveur et d'un DAS ou d'un SAN ISCSI ou autre aurait été excessif et le coût aurait réduit à néant les chances du projet. Je travaille pour une PME d'environ 100 personnes, notre budget informatique est donc serré, surtout en ce moment.

@mrdenny

Nous avons posé la question à l'éditeur du logiciel qui a recommandé cette configuration. Nous l'avons acheté, puis lorsque nous avons posé la question que j'ai posée ici, ils nous ont dit de mettre le journal, les bases de données et les tempdbs sur la partition raid 10. Je ne suis pas un grand spécialiste des bases de données (vraiment ??) mais cela semblait louche, car presque tout le monde sait qu'il ne faut pas mélanger les ldfs et les mdfs sur les mêmes spindles.

@splattne - Merci pour l'éclairage sur les tempdb's, cela sera utile pour cette installation et les futures installations SQL.

@SuperCoolMoss - J'ai parlé à quelques personnes de mon propre réseau d'informaticiens et ils sont d'accord avec vous sur ce point. OS, Pagefile et LDFs sur RAID1 et tempdb et MDFs sur RAID10.

Merci à tous ceux qui ont fait des commentaires.

D'après ce que j'ai lu, voici les règles de base à suivre lors du déploiement de SQL en ce qui concerne les disques. A mon avis, elles doivent être suivies dans cet ordre, faites-moi savoir si vous êtes d'accord ou non.

  1. Utiliser des disques redondants (assez évident)
  2. Utiliser des disques rapides (SCSI/SAS, 15k si possible)
  3. Séparez vos fichiers ldf et mdf sur des broches différentes.
  4. Ne pas utiliser RAID5 pour ldfs ou tempdbs (utiliser RAID10 ou RAID1)
  5. Placez votre tempdb sur vos fuseaux les plus rapides ; si possible, séparez les tempdb des fuseaux ldf et mdf.

N'hésitez pas à partager votre version modifiée de cette liste.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X