È utile disporre della directory principale dell'istanza di SQL Server su un'unità separata?

So che è possibile modificare molti dei percorsi predefiniti durante l'installazione di SQL Server e, in genere, quando eseguo un'installazione, cambio le cartelle dei dati e dei log in unità separate (in genere D ed E), tuttavia di recente mi è stato assegnato un macchina preinstallata che esegue un nome di istanza diverso da quello predefinito e hanno configurato la directory principale dell'istanza in modo che si trovi sull'unità D insieme ai file mdf. Ciò significa che su quella che normalmente sarebbe un'unità relativamente pulita con solo cartelle e file di database, ora ho anche un'installazione completa dei binari di SQL Server.

cioè ora ho il seguente:

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

Dove normalmente correrei con qualcosa del tipo:

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries
D:\MSSQL\DATA --Data Files
E:\MSSQL\LOGS --Log Files

Posso capire perché sia ​​necessaria una cartella binaria di istanza separata, ma non riesco a capire perché sarebbe utile mettere tutti quei binari su un'unità separata.

Qualcuno può dirmi perché potrebbe essere una cosa ragionevole da fare? O forse non fa alcuna differenza? A me sembra terribilmente disordinato ...

Per quanto riguarda la suddivisione della radice dell'istanza, ci sono un paio di argomenti a favore di farlo.

1. Alcune persone sono favorevoli a mantenere la loro unità "C" dedicata solo al sistema operativo e ai binari del sistema operativo. Questo può darti alcune diverse opzioni per il ripristino in caso di arresto anomalo sull'unità C, può aiutare a impedire al sistema operativo di causare o ricevere problemi relativi allo spazio dalla condivisione con altre app.
2. Stai isolando i file binari di SQL Server da altri programmi e assicurando la disponibilità di alcune delle cartelle critiche come la cartella Logs dove vanno i log degli errori - questa cartella deve essere accessibile per l'avvio dei server SQL. In sostanza, ti stai proteggendo dagli altri.

È possibile inserire i file binari / di istanza di SQL Server nello stesso posto in cui si tende a inserire gli altri file di programma. Ma se lo fai, almeno assicurati di prendere i file del database di sistema e potenzialmente il percorso di backup predefinito e spostarlo in un altro posto.

Ecco cosa tendo a fare quando mi viene dato un numero illimitato di lettere di unità con cui giocare (almeno .. Le lettere non sono importanti qui):

• C - File di sistema operativo e di sistema. Solo
• D - File di programma per tutte le app (incluso SQL Server)
• S - File a livello di istanza / database di sistema di SQL Server e file di registro in genere (eccetto TempDB) (nota .. Se ho più istanze, non ne farei 4 di queste .. Metterei tutti i binari SQL per tutte le istanze su S nella maggior parte dei casi, con le cartelle che forniscono la separazione)

( ED- Un'altra nota: spesso non ho un'unità "S" disponibile. Alla fine della giornata, i file del database di sistema per Master, Model, MSDB e Resource db vivono sulla stessa unità di alcuni dei tuoi utenti file di database, ma in una cartella separata per la separazione logica per mantenere le cose meno confuse non è la fine del mondo.)

• F - File di dati per database utente
• L - Unità file di registro per database utente
• T - TempDB
• X - Unità di backup (anche se in molti casi scelgo di eseguire lo streaming di un backup su un'unità di rete, non pagando una copia dopo il backup e eseguo immediatamente il backup per l'archiviazione da qualche altra parte.)

Avrò spesso più unità di dati e log e, a volte, un'altra unità TempDB. Aggiungi in più istanze e puoi esaurire rapidamente le lettere di unità. Puoi certamente cavartela mettendo i tuoi file a livello di istanza su C :. E faccio molti controlli di integrità per i client che sono stati configurati in questo modo - e non dico mai "oh wow .. dobbiamo risolverlo ora" - Ora se ci sono anche i loro file TempDB, di solito fagli cambiare questo. A volte sposta anche i loro database master e MSDB.

Ma il mondo non finirà se non dividi queste cose. Penso che il vantaggio sia davvero quello di mantenere separati i tuoi file. Come DBA dovresti avere una sana paranoia attorno ad altri ruoli nella tua azienda, altre applicazioni, altre installazioni, ecc. E più puoi isolarti dal potenziale di conflitti, migliore sarà. E ti dà alcune altre opzioni per la reinstallazione e il ripristino. Quindi sì, separa i tuoi file binari da C. Ma il mio consiglio non sarebbe di impazzire su un'unità separata per ogni istanza.

Bene, ci sono solo 26 possibili lettere di unità in Windows. 1
Ma hai la possibilità di usare i mount points. 2

Quindi, se è necessario installare 25 server diversi (SQL, Web, ...) su un computer, potrebbe avere senso avere una lettera di unità per uno dei server.
Ma se si dispone di un solo server, sarebbe più sensato avere lettere di unità diverse per i file di registro, il database e i file di programma.
È inoltre possibile dividere i file di registro / database / programma se si trovano in cartelle diverse.

1. arrestare il server SQL
2. aggiungi una partizione
3. copia tutti i file di database nella partizione
4. cambia il punto di montaggio nella cartella, dove sono stati i file di database (ad esempio: d: \ database)
5. finito