Il y a un groupe qui convient que sur un disque dur, il serait avantageux de séparer, ils affirment toujours que pour les disques SSD, ce n'est plus nécessaire.
Donc, pour eux, je veux demander "s'il n'y a pas de problème de contention, alors pourquoi un RAID 10? Il n'y a plus besoin de décapage! Donc, la simple mise en miroir suffirait, et bien sûr, il n'y a pas besoin de 8 disques, 2x la base de données la taille devrait suffire! ".
Cependant, la réalité est que si quelque chose a besoin d'un RAID 10, c'est le fichier journal!
Ce n'est pas seulement à cause du problème de séquentiel vs aléatoire (voir les ressources ci-dessous), mais c'est en fait très crucial une fois que vous comprenez comment fonctionnent les disques SSD.
Pour faire une histoire courte (pour une description plus longue, voir
http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), un lecteur SSD est très efficace en lecture et en écriture de zéros, mais pour en écrire, il n'est pas aussi efficace qu'il doit effacer toute la section pour en écrire une seule!
Bien que ce ne soit pas un problème pour les écritures générales, car elles sont de toute façon mises en mémoire tampon et écrites dans les limites de page, c'est un problème majeur pour le fichier journal, car le fichier journal contourne tout cache et à la place les blocs de serveur SQL jusqu'à ce que le les journaux sont écrits sur le disque !, ce qui signifie que pour chaque écriture, il y aura probablement une suppression complète de la section.
Donc, pour l'optimiser, je suggère de dédier chaque disque supplémentaire (en plus de 2x la taille de la base de données, pas besoin de supprimer!) Pour le fichier journal, de cette façon, il pourra en traiter autant que possible dans un délai plus court.
RÉPONSE ANCIENNE
La réponse est oui, pour trois raisons. 1) Random vs Sequential - Bien qu'il soit clair que le SSD a considérablement augmenté les performances pour les écritures aléatoires, le problème de random vs sequential demeure, comme le montrent les whitepapers et les liens suivants:
2) Fiabilité - Il y a de fortes chances que tous les disques SSD tombent en panne simultanément, auquel cas le RAID n'est pas protégé, mais comme un disque SSD utilisé uniquement pour le séquentiel a une durée de vie différente, cela pourrait vous sauver la vie
3) Contention d'écriture - La raison pour laquelle les journaux sont placés sur sa propre broche n'est pas seulement à cause de l'aléatoire vs séquentiel mais aussi à cause de la contention d'écriture, comme on peut le voir du fait qu'il est également recommandé d'avoir tempdb sur un volume séparé qui indique que le problème ici concerne également les conflits d’écriture.
Et cela devrait s'appliquer encore plus pour le fichier journal, car l'écriture dans le journal empêche les transactions d'être considérées comme validées jusqu'à ce qu'elles soient écrites sur la surface du disque.
En fait, pour les journaux, vous pouvez utiliser des disques durs standard comme livre blanc de Dell apr à http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf
ÉDITER
Il est recommandé de placer tempdb sur sa propre matrice pour faire tourner les disques, voir
et de nombreux autres et c'est la notion généralement acceptée dans Sql Server, alors que personne n'a exprimé de problème avec le fractionnement du tableau.
De plus, l'équipe SQL Server a créé les concepts de partitionnement de groupe de fichiers et de partitionnement, avec la seule intention de pouvoir les déplacer sur un tableau séparé.
Et en fait, le MSDN à http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) recommande qu'il puisse y avoir un avantage en termes de performances à séparer l'index non cluster sur son propre tableau (bien que cela ne doit pas être considéré comme un conseil général pour chaque situation, uniquement pour des charges de travail spécifiques, voir plus d'informations sur http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).
En tant que tel, c'est juste une extension logique de dire que la raison de la séparation sur les disques en rotation n'est pas seulement liée au problème des lectures séquentielles vs aléatoires, mais à la contention d'écriture générale, quelque chose qui s'applique également aux SSD.
Bien que certaines personnes soient en désaccord avec ces conseils et considèrent qu'il n'y a aucun avantage à mettre tempdb et son propre volume (comme Jack Douglas), et vous pourriez même prétendre qu'il n'y a aucun avantage à séparer les fichiers journaux (comme Mark Storey -Smith), et prétendent plutôt que le fractionnement du tableau est bien pire, n'oubliez pas qu'il s'agit d'une nouvelle approche allant à l'encontre de l'approche généralement acceptée suggérée par Microsoft et la communauté, et jusqu'à présent, personne n'a fourni de liens vers tests de référence pour le soutenir.
Donc, ma parole à tous les downvoters est, je trouve très contraire à l'éthique de downvote un message simplement parce qu'il a une opinion différente de la vôtre, surtout quand 1) votre opinion va à l'encontre de la théorie généralement acceptée 2) et elle est contre les fournisseurs (Microsoft ) propre documentation 3) et vous n'avez fourni aucune preuve juste une opinion.
Mais dans ce cas, c'est encore plus ridicule, car mon post n'est rien de plus que l'extension logique de cette théorie, donc celui qui considère ce post comme un conseil de lit doit bien sûr revenir à tous les postes qui conseillent cette théorie et les voter de manière négative .
Supposons que quelqu'un décide que le RAID est une théorie de la vieille école et que tous les articles le recommandent, comment cela a-t-il un sens?