En ce qui concerne le fractionnement de la racine d'instance, il y a quelques arguments en faveur de le faire.
- Certaines personnes sont en faveur de garder leur lecteur "C" dédié uniquement au système d'exploitation et aux binaires du système d'exploitation. Cela peut vous donner différentes options de récupération en cas de panne sur le lecteur C, cela peut aider à empêcher le système d'exploitation de causer ou de recevoir des problèmes liés à l'espace de partage avec d'autres applications.
- Vous isolez les fichiers binaires de SQL Server des autres programmes et vous assurez la disponibilité de certains des dossiers critiques comme le dossier Logs où se trouvent les journaux d'erreurs - ce dossier doit être accessible pour le démarrage de SQL Server. Vous vous protégez des autres, en gros.
Vous pouvez placer les fichiers binaires / instance SQL Server au même endroit que vous avez tendance à placer vos autres fichiers programme. Mais si vous faites cela - assurez-vous au moins de prendre vos fichiers de base de données système et potentiellement votre emplacement de sauvegarde par défaut et de le déplacer ailleurs.
Voici ce que j'ai tendance à faire quand on me donne un nombre illimité de lettres de lecteur pour jouer avec (au minimum .. Les lettres ne sont pas importantes ici):
- C - Fichiers au niveau du système d'exploitation et du système. Seulement
- D - Fichiers de programme pour toutes les applications (y compris SQL Server)
- S - Fichiers de niveau instance / bases de données système SQL Server et fichiers journaux généralement (sauf TempDB) (remarque .. Si j'ai plusieurs instances, je n'en créerai pas 4 .. Je mettrais tous les binaires SQL pour toutes les instances sur S dans la plupart des situations, les dossiers assurant la séparation)
( ED- Une autre note - Je n'ai souvent pas de lecteur "S" disponible. À la fin de la journée, avoir vos fichiers de base de données système pour Master, Model, MSDB et Resource db sur le même lecteur que certains de vos utilisateurs fichiers de base de données, mais dans un dossier séparé pour une séparation logique afin de garder les choses moins confuses n'est pas la fin du monde.)
- F - Fichiers de données pour les bases de données utilisateur
- L - Lecteur de fichier journal pour les bases de données utilisateur
- T - TempDB
- X - Lecteur de sauvegarde (bien que dans de nombreux cas, je choisis de diffuser une sauvegarde sur un lecteur réseau, sans payer de copie après la sauvegarde et je sauvegarde immédiatement vers le stockage ailleurs.)
J'aurai souvent plus de lecteurs de données et de journaux et parfois un autre lecteur TempDB. Ajoutez dans plusieurs instances et vous pouvez manquer de lettres de lecteur rapidement. Vous pouvez certainement vous en sortir en plaçant vos fichiers de niveau d'instance sur C :. Et je fais beaucoup de contrôles de santé pour les clients qui ont été configurés comme ça - et je ne dis jamais "oh wow .. nous devons résoudre ce problème maintenant" - Maintenant, si leurs fichiers TempDB sont là aussi, je vais généralement demandez-leur de changer cela. Parfois, déplacez également leurs bases de données master et MSDB.
Mais le monde ne finira pas si vous ne divisez pas ces choses. Je pense que l'avantage est vraiment de garder séparés vos fichiers. En tant qu'administrateur de base de données, vous devriez avoir une saine paranoïa autour d'autres rôles dans votre entreprise, d'autres applications, d'autres installations, etc. et plus vous vous isolerez du potentiel de conflits, mieux vous serez. Et cela vous donne plus d'options pour la réinstallation et la récupération. Alors oui séparez vos binaires de C .. Mais mon conseil ne serait pas de devenir fou sur un lecteur séparé pour chaque instance ..