Importancia de la ubicación de instalación de Microsoft SQL Server


10

Tengo un servidor con disco lento barato y un disco rápido caro.

Quiero usar el costoso disco para todas las cosas en las que es importante que sea rápido, como mis bases de datos.

Para ahorrar dinero, quiero usar el disco lento para cualquier cosa en la que no haga mucha diferencia, ya sea rápido o lento, como las copias de seguridad.

Ahora, mi pregunta es, ¿debo instalar mi Microsoft SQL Server en el disco lento o rápido?

(Para ser claros, colocaré mis bases de datos en el disco rápido sin importar qué, así que mi pregunta solo se refiere a la ubicación de la instalación en sí)


3
¿Por qué considerarías esto dado que un ssd de baja escritura de 120 gb es (a) BARATO y (b) súper rápido y (c) lo suficientemente bueno para todo lo relacionado con los programas OS +? Trasladé todos los sistemas operativos a 120 gb ssd hace 2 años y el costo realmente no importó, en ese momento. Ahora es aún menos relevante.
TomTom

¿Desea confiar una base de datos de misión crítica en un disco SSD? Recuérdame que nunca haga negocios contigo ...
Shadur

2
@Shadur, qué cebo. Sí, lo colocaré en un disco configurado con RAID 10 basado en SSD que se replica en otros 2 discos localmente y se respalda todas las noches en una ubicación remota. ¡Bienvenido a la década!
Niels Brinch

@TomTom tienes razón, por supuesto, pero estoy en una situación bastante costosa en este caso, por eso incluso me estoy molestando con este tipo de hiperoptimización. Mi pregunta se volverá cada vez más irrelevante a medida que pase cada año, como es el caso con la mayoría de las preguntas aquí, supongo.
Niels Brinch

@NielsBrinch Cent Smart y Pound Foolish. Seriamente.
TomTom

Respuestas:


11

Esto es una especie de opinión, pero pondría los binarios de SQL Server en el disco lento. Es bastante común poner los binarios en el disco del sistema operativo (aunque algunas personas odian eso), o en un disco más lento.

Sin embargo, definitivamente debe recordar colocar las bases de datos del sistema, especialmente tempdb, en el disco más rápido. De hecho, también es común poner tempdb solo.

Esto está en línea con un par de artículos que encontré que podrían serle útiles.

También hay que pensar en las copias de seguridad del registro de transacciones, y me molesta esto porque desea que los LDF estén en el disco más rápido y también desea copias de seguridad en un disco diferente de donde viven las bases de datos, pero sería mejor si estuvieran en un disco más rápido Tendrá que hacer una llamada de juicio, pero probablemente haré una copia de seguridad en el disco más lento y me quejaré. ;)


Gracias. ¿Está diciendo que no afecta el rendimiento, especialmente si la instalación del servidor sql (binarios, etc.) está en el disco lento o rápido?
Niels Brinch

1
No es que me haya dado cuenta. Y es una configuración bastante común.
Katherine Villyard

66
Katherine tiene razón, porque los binarios en sí mismos no están particularmente vinculados a IO. En general, poner binarios en un disco rápido mejorará los tiempos de carga, pero rara vez afecta la velocidad de operación general ya que el código se ejecuta desde la memoria. A menos que reinicie el servidor con frecuencia, no le afectará significativamente tener los binarios en un almacenamiento más lento.
Corey

@ Corey muchas gracias por la explicación muy puntual. Esto es lo que estaba buscando.
Niels Brinch

6

Me gustaría seguir con la respuesta bastante buena que Katherine Villyard ya dio.

De alguna manera depende del uso previsto de su base de datos.
Si usted está esperando una gran cantidad de operaciones de escritura, seguir adelante y poner .mdfy .ndfarchivos en el disco más rápido.

Sin embargo, si su base de datos es generalmente bastante estática (por ejemplo, sirve contenido web). Y las consultas no varían mucho, lo más probable es que obtenga una gran cantidad de las consultas en su memoria, o incluso en caché en el lado de la aplicación. Momento en el que es mejor usar el disco más rápido para sus .ldf, tempdby copias de seguridad.

Del mismo modo, si espera muchas consultas grandes, como una OLAPbase de datos, es mejor que almacene su .mdf, tempdben el disco más rápido. Y poner los .ldfdiscos más lentos ya que a menudo no formará parte del cuello de botella.

En cualquier caso, no se moleste en colocar los archivos binarios en el disco rápido, generalmente los colocamos en un disco lento (no el sistema si se puede evitar).
Además, no se obsesione con tratar de obtener los archivos .ldfy .mdfen el disco rápido, generalmente están separados siempre que sea posible.

En resumen, revise su carga para ver cuál será su cuello de botella más probable.


3

Tienes cosas al revés. Sé que es contra-intuitivo, pero desea las copias de seguridad (especialmente las copias de seguridad del registro de transacciones) en el disco rápido, y los archivos mdf / ldf (con la notable excepción de tempdb) en el disco lento.

Puede pensar que Sql Server mantiene dos representaciones de sus datos. Los archivos MDF + LDF representan el estado actual de la base de datos, mientras que la copia de seguridad (incluidas las copias de seguridad del registro de transacciones desde la última copia de seguridad completa) representa lo que necesita para restaurar el estado actual de la base de datos en caso de falla. Desea mantener estas dos representaciones separadas entre sí, de modo que un evento que destruya una representación no dañará la otra representación.

Resulta que el rendimiento del servidor SQL tiende a depender MUCHO más de qué tan rápido puede escribir archivos de registro de transacciones y sus copias de seguridad en función de qué tan rápido puede acceder a los archivos mdf. Esto significa que debe considerar colocar copias de seguridad en el disco rápido (lo ideal sería agregar un pequeño SSD al servidor que puede usar para archivos ldf, para darles velocidad y al mismo tiempo preservar la separación de sus copias de seguridad). Desafortunadamente, esto deja el disco lento para sus archivos MDF, pero de nuevo: no importará tanto como cree.

Vale la pena señalar que lo anterior supone que tiene suficiente RAM, que sigue las cargas de trabajo típicas y que planea usar el modo de recuperación completa, en lugar de simple. Además, el sistema operativo y el programa Sql Server instalado se pueden colocar en el disco lento, aunque, por supuesto, es probable que desee tanto como tenga espacio para vivir en el disco rápido.


Por copias de seguridad me refiero a los archivos que no están en uso, sino que simplemente se almacenan. Pondría archivos mdf y ldf en el disco rápido. Para mí es una novedad que mdf está bien poner en el disco lento, esa fue una información interesante e inesperada.
Niels Brinch

1
No quiere el mdf en el mismo disco que las copias de seguridad / registros. MDF representa el estado actual de la base de datos. Backup + LDF representa lo que necesita para recuperar la base de datos a su estado actual. Desea que las dos representaciones estén separadas entre sí, por lo que un evento que destruya una no dañará a la otra. Y dado que los registros y las copias de seguridad deben estar en el disco rápido (el rendimiento depende mucho más de lo rápido que puede escribir en el archivo ldf que de lo rápido que puede escribir en el archivo mdf), eso significa que mdf debería ir al disco lento.
Joel Coel

Voy a editar la mayoría de los comentarios anteriores en la respuesta.
Joel Coel

1
No estoy seguro de por qué usted está diciendo que sobre el .ldfy .mdfnecesidad de separarse en caso de desastre ... No es generalmente asumido que va a utilizar cualquiera de ellos para la recuperación de desastres, eso es lo que las copias de seguridad son para. Si desea una pérdida de datos tan cercana a 0 como sea posible, obtendrá copias de seguridad de registros extremadamente frecuentes, no confíe en el archivo de registro en sí.
Reaces

@Reaces Tienes razón. Tuve un pedo cerebral y estaba escribiendo archivos LDF con mis dedos mientras pensaba en las copias de seguridad de TRN en mi cabeza. Los pensamientos generales se mantienen, pero tendré que revisarlos significativamente para aclarar eso (trabajando en ello ahora).
Joel Coel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.