Hay un grupo que está de acuerdo en que en un HDD sería beneficioso separarlo, todavía afirman que para las unidades SSD esto ya no es necesario.
Entonces, para ellos, quiero preguntar "si no hay problemas de contención, ¿por qué un RAID 10? ¡Ya no hay necesidad de eliminarlos! Así que duplicar solo sería suficiente, y por supuesto no hay necesidad de 8 unidades, 2 veces la base de datos el tamaño debería ser suficiente ".
Sin embargo, la realidad es que si algo necesita un RAID 10, ¡es el archivo de registro!
Esto no es solo por el problema de secuencial versus aleatorio (ver recursos a continuación), sino que es realmente crucial una vez que comprende cómo funcionan las unidades SSD.
Para resumir una historia larga (para una descripción más larga, ver
http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), una unidad SSD es muy eficiente en las lecturas y en la escritura de ceros, sin embargo, para escribirlas no es tan eficiente, ya que tiene que borrar toda la sección para escribir incluso una sola.
Si bien esto no es un problema para las escrituras generales, ya que de todos modos se almacenan en la memoria y se escriben en los límites de la página, es un problema importante para el archivo de registro, ya que el archivo de registro omite cualquier caché y en su lugar bloquea el servidor SQL hasta que los registros se escriben en el disco !, lo que significa que para cada escritura probablemente habrá un borrado completo de la sección.
Por lo tanto, para optimizarlo, sugeriría dedicar cada disco adicional (además del doble del tamaño de la base de datos, ¡no es necesario eliminarlo!) Para el archivo de registro, de esta manera podrá procesar la mayor cantidad posible en un período de tiempo más corto.
RESPUESTA ANTIGUA
La respuesta es sí, por tres razones. 1) Aleatorio versus secuencial: si bien está claro que SSD aumentó el rendimiento de manera espectacular para las escrituras aleatorias, aún queda el problema de aleatorio versus secuencial, como se puede ver en los siguientes documentos y enlaces:
2) Confiabilidad: existe una gran posibilidad de que todas las unidades SSD fallen simultáneamente, en cuyo caso RAID no es protección, sin embargo, dado que una unidad SSD utilizada únicamente para secuencial tiene una vida útil diferente, este podría ser su salvavidas
3) Contención de escritura: la razón para colocar registros en su propio eje no se debe solo a la secuencia aleatoria frente a la secuencial, sino también a la contención de la escritura, como se puede ver por el hecho de que también se recomienda tener tempdb en un volumen separado que indica que el problema aquí también se trata de contención de escritura.
Y esto debería aplicarse aún más para el archivo de registro, ya que las escrituras en el registro impiden que las transacciones se consideren confirmadas hasta que se escribe en la superficie del disco.
De hecho, para los registros, puede usar unidades de disco duro normales como el documento técnico de Dell en http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf
EDITAR
Microsoft recomienda poner tempdb en su propia matriz para discos giratorios, consulte
y muchos otros y es la noción general aceptada en SQL Server, mientras que nadie expresó un problema con la división de la matriz.
Además, el equipo de SQL Server ha creado los conceptos de partición de grupo de archivos y particionamiento, con la única intención de poder moverlos en una matriz separada.
Y, de hecho, el MSDN en http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) recomienda que podría haber un beneficio de rendimiento al separar el índice no agrupado en su propia matriz (aunque esto no debe tomarse como un consejo general para cada situación, solo para cargas de trabajo específicas, consulte más información en http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).
Como tal, es solo una extensión lógica decir que el motivo de la separación en los discos giratorios no solo está relacionado con el tema de las lecturas secuenciales versus las aleatorias, sino también con la contención general de la escritura, algo que también se aplica a los SSD.
Si bien es posible que algunas personas no estén de acuerdo con ese consejo y consideren que no es beneficioso poner tempdb y su propio volumen (como Jack Douglas), e incluso podría afirmar que no es beneficioso separar los archivos de registro (como Mark Storey -Smith), y en su lugar afirman que dividir la matriz es mucho peor, aún así, no olviden que este es un nuevo enfoque que va en contra del enfoque general aceptado sugerido por Microsoft y la comunidad, y hasta ahora nadie ha proporcionado enlaces a ningún pruebas de referencia para apoyarlo.
Entonces, mi palabra para todos los que votan es que me parece poco ético rechazar una publicación solo porque tiene una opinión diferente a la suya, especialmente cuando 1) su opinión va en contra de la teoría general aceptada 2) y está en contra de los proveedores (Microsoft ) propia documentación 3) y no ha proporcionado ninguna prueba solo una opinión.
Pero en este caso es aún más ridículo, ya que mi publicación no es más que la extensión lógica de esta teoría, por lo que uno que considere esta publicación como un consejo de cama necesita, por supuesto, volver a todas las publicaciones que aconsejan esta teoría y desestimarlas. .
Digamos que alguien decide que RAID es la teoría de la vieja escuela y rechaza todas las publicaciones que lo recomiendan, ¿cómo tiene sentido?