C'est une grande question «ça dépend».
Je ne peux pas répondre à la question de savoir comment créer les tableaux RAID individuels pour vous, car je ne suis pas un expert en stockage, mais je peux vous aider avec le reste.
La première chose à considérer est la charge de travail sur les différentes bases de données - OLTP (lecture / écriture) ou DSS / DW (lecture-principalement). Pour les charges de travail en lecture / écriture, vous devriez envisager RAID 1 ou RAID 10 (RAID 1 + 0), car ils offrent une redondance et de grandes performances de lecture / écriture. Pour les charges de travail principalement en lecture, vous pouvez utiliser RAID 5. La raison pour laquelle RAID 5 ne doit pas être utilisé pour les charges de travail en lecture / écriture est que vous payez une pénalité de performances sur les écritures.
Les journaux de transactions, de par leur nature même, sont en lecture / écriture (ou surtout en écriture, selon que vous utilisez le journal de transactions pour quelque chose - par exemple, des sauvegardes de journaux ou une réplication) et ne doivent donc jamais être placés sur RAID 5.
Cela signifie que pour certaines bases de données et charges de travail, vous pouvez avoir des fichiers de données sur RAID 5 et des fichiers journaux sur RAID 1/10, et pour d'autres bases de données, vous pouvez avoir tout sur RAID 1/10. Pour aller plus loin, si vous avez une base de données partitionnée, elle peut contenir des données en lecture et en lecture / écriture, peut-être même dans la même table. Cela peut être divisé en groupes de fichiers séparés, puis chaque groupe de fichiers est placé sur un niveau RAID approprié.
La séparation des bases de données réelles dépend à nouveau de la charge de travail et des capacités du sous-système d'E / S sous-jacent - un degré de séparation plus élevé peut être requis pour stocker des éléments sur des matrices RAID individuelles que sur un SAN, par exemple.
Tempdb est un cas particulier à lui tout seul, car il s'agit généralement d'une base de données lourdement chargée et doit être stocké séparément des autres bases de données. Les bases de données système ne doivent pas être fortement utilisées et peuvent être placées n'importe où tant qu'il y a redondance.
Voici un lien vers un livre blanc que j'ai aidé à rédiger et qui devrait vous aider: Physical Database Storage Design . Assurez-vous également que votre sous-système d'E / S peut gérer la charge de travail prévue - consultez ce livre blanc: Meilleures pratiques d'E / S avant le déploiement . Enfin, assurez-vous que vous utilisez la taille de bande RAID correcte (généralement 64 Ko ou plus sur les systèmes plus récents), la taille d'unité d'allocation NTFS correcte (généralement 64 Ko) et que sur les systèmes antérieurs à Windows Server 2008, vous définissez correctement le décalage de la partition de disque . Pour plus d'informations sur ces derniers, et des pointeurs vers plus d'informations à leur sujet et pourquoi vous devez les configurer de cette façon, consultez cet article de blog: Vos décalages de partition de disque, les tailles de bande RAID et les unités d'allocation NTFS sont-ils correctement définis? .
Ligne Bototm: connaissez votre charge de travail et vos capacités de sous-système d'E / S, puis implémentez-les en conséquence.
J'espère que cela vous aide.
PS En ce qui concerne tempdb, c'est une grosse boîte de vers sur la façon dont vous devez le configurer et il y a toutes sortes d'informations contradictoires. J'ai écrit un article de blog complet sur la configuration des fichiers de données tempdb à Misconceptions autour de TF 1118 .