Est-il utile d'avoir le répertoire racine de l'instance SQL Server sur un lecteur distinct?
Je sais qu'il est possible de modifier bon nombre des chemins par défaut lors de l'installation de SQL Server, et généralement lorsque je fais une installation, je modifie les dossiers de données et de journaux pour qu'ils se trouvent sur des lecteurs distincts (généralement D et E), mais j'ai récemment reçu un machine préinstallée qui exécute un nom d'instance autre que le nom par défaut et ils ont configuré le répertoire racine de l'instance pour qu'il soit sur le lecteur D avec les fichiers mdf. Cela signifie que sur ce qui serait normalement un lecteur relativement propre avec seulement des dossiers et des fichiers de base de données, j'ai maintenant une installation complète des binaires SQL Server également.
c'est-à-dire que j'ai maintenant ce qui suit:
C:\Program Files\Microsoft SQL Server\ --Base Install
D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries
D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files
E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files
Où normalement je courrais avec quelque chose comme:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries
D:\MSSQL\DATA --Data Files
E:\MSSQL\LOGS --Log Files
Je peux comprendre pourquoi avoir un dossier binaire d'instance distinct est nécessaire, mais je ne vois pas pourquoi il serait utile de mettre tous ces binaires sur un lecteur séparé.
Quelqu'un peut-il me dire pourquoi ce serait une chose raisonnable à faire? Ou peut-être que cela ne fait aucune différence? Pour moi, cela semble terriblement désordonné ...
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 provoquer 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 des serveurs 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 d'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 - Autre remarque - 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 vivant sur le même lecteur que certains de vos fichiers de base de données utilisateur, 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 juste de garder vos fichiers séparés. 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 ..
Eh bien, il n'y a que 26 lettres de lecteur possibles dans Windows. 1
Mais vous avez la possibilité d'utiliser des points de montage. 2
Donc, si vous devez installer 25 serveurs différents (SQL, Web, ...) sur une machine, il peut être judicieux d'avoir une lettre de lecteur pour l'un des serveurs.
Mais si vous n'avez qu'un seul serveur, il serait plus judicieux d'avoir des lettres de lecteur différentes pour les fichiers journaux, la base de données et les fichiers programme.
Vous pouvez également diviser les fichiers journaux/base de données/programmes s'ils se trouvent dans des dossiers différents.
- arrêter le serveur SQL
- ajouter une partition
- copier tous les fichiers de base de données sur la partition
- changer le point de montage dans le dossier où se trouvaient les fichiers de base de données (par exemple: d:\database)
- fini