¿Es útil tener el directorio raíz de la instancia de SQL Server en una unidad separada?

Sé que es posible cambiar muchas de las rutas predeterminadas al instalar SQL Server, y generalmente cuando hago una instalación, cambio los datos y las carpetas de registro para que estén en unidades separadas (generalmente D y E), sin embargo, recientemente me dieron un máquina preinstalada que ejecuta un nombre de instancia diferente al predeterminado y ha configurado el directorio raíz de la instancia para que esté en la unidad D junto con los archivos mdf. Esto significa que en lo que normalmente sería una unidad relativamente limpia con solo carpetas y archivos de base de datos, ahora también tengo una instalación completa de los binarios de SQL Server.

es decir, ahora tengo lo siguiente:

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

Donde normalmente correría con algo como:

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

Puedo entender por qué es necesario tener una carpeta binaria de instancia separada, pero no puedo ver por qué sería útil poner todos esos binarios en una unidad separada.

¿Alguien puede decirme por qué podría ser algo razonable? ¿O tal vez simplemente no hace ninguna diferencia? A mí me parece terriblemente desordenado ...

Con respecto a la división de la raíz de la instancia, hay un par de argumentos a favor de hacerlo.

1. Algunas personas están a favor de mantener su disco "C" dedicado solo al sistema operativo y los binarios del sistema operativo. Esto puede darle algunas opciones diferentes para la recuperación en caso de un bloqueo en la unidad C, puede ayudar a evitar que el sistema operativo cause o reciba problemas relacionados con el espacio al compartir con otras aplicaciones.
2. Está aislando los archivos binarios de SQL Server de otros programas y asegurando la disponibilidad de algunas de las carpetas críticas, como la carpeta de Registros donde van los registros de errores; esta carpeta debe ser accesible para el inicio de los Servidores SQL. Te estás protegiendo de los demás, básicamente.

Puede colocar los archivos binarios / instancia de SQL Server en el mismo lugar donde tiende a colocar sus otros archivos de programa. Pero si lo hace, al menos asegúrese de tomar los archivos de la base de datos del sistema y, posiblemente, su ubicación de respaldo predeterminada y moverla a otro lugar ...

Esto es lo que tiendo a hacer cuando se me da un número ilimitado de letras de unidad para jugar (como mínimo. Las letras no son importantes aquí):

• C - Sistema operativo y archivos a nivel de sistema. Solamente
• D: archivos de programa para todas las aplicaciones (incluido SQL Server)
• S: archivos de nivel de instancia / bases de datos del sistema de SQL Server y archivos de registro normalmente (excepto TempDB) (nota ... Si tengo varias instancias, no haré 4 de estas ... Pondría todos los binarios de SQL para todas las instancias en S en la mayoría de las situaciones, con las carpetas que proporcionan la separación)

( ED- Otra nota: a menudo no tengo una unidad "S" disponible. Al final del día, tener los archivos de la base de datos de su sistema para Master, Model, MSDB y Resource db viviendo en la misma unidad que algunos de sus usuarios archivos de base de datos, pero en una carpeta separada para la separación lógica para mantener las cosas menos confusas no es el fin del mundo).

• F - Archivos de datos para bases de datos de usuarios
• L: unidad de archivo de registro para bases de datos de usuario
• T - TempDB
• X - Unidad de copia de seguridad (aunque en muchos casos elijo transmitir una copia de seguridad a una unidad de red, sin pagar una copia después de la copia de seguridad e inmediatamente estoy haciendo una copia de seguridad en otro lugar).

A menudo tendré más unidades de datos y de registro y, a veces, otra unidad TempDB. Agregue varias instancias y puede quedarse sin letras de unidad rápidamente. Ciertamente puede salirse con la suya poniendo sus archivos de nivel de instancia en C :. Y hago muchas comprobaciones de estado para clientes que se configuraron así, y nunca digo "oh wow ... tenemos que arreglar eso ahora". Ahora si sus archivos TempDB también están allí, normalmente que cambien eso. A veces también mueven sus bases de datos maestra y MSDB.

Pero el mundo no terminará si no divide estas cosas. Creo que el beneficio es realmente mantener separados sus archivos. Como DBA, debe tener una paranoia saludable en torno a otros roles en su empresa, otras aplicaciones, otras instalaciones, etc. y cuanto más pueda aislarse del potencial de conflictos, mejor será. Y le brinda algunas opciones más para la reinstalación y recuperación. Así que sí, separe sus binarios de C ... Pero mi consejo no sería volverse loco en un disco separado para cada instancia ...

Bueno, solo hay 26 posibles letras de unidad en Windows. 1
Pero tienes la posibilidad de usar puntos de montaje. 2

Entonces, si necesita instalar 25 servidores diferentes (SQL, web, ...) en una máquina, podría tener sentido tener una letra de unidad para uno de los servidores.
Pero si solo tiene un servidor, tendría más sentido tener letras de unidad diferentes para los archivos de registro, la base de datos y los archivos de programa.
También puede dividir los archivos de registro / base de datos / programa si están en carpetas diferentes.

1. detener el servidor SQL
2. agregar una partición
3. copia todos los archivos de la base de datos a la partición
4. cambie el punto de montaje a la carpeta, donde han estado los archivos de la base de datos (por ejemplo: d: \ database)
5. terminado