SQL Server 2K / 2K5 / 2K8 y discos de estado sólido: ¿optimizaciones específicas?

¿Alguien está ejecutando SQL Server en unidades de estado sólido? ¿Has encontrado algún consejo de optimización específico? Estoy específicamente interesado en formas de reducir la frecuencia con la que SQL Server realiza pequeñas operaciones de escritura aleatoria, ya que son la némesis del rendimiento SSD, particularmente las unidades SSD MLC.

Hay algunas optimizaciones obvias que uno puede hacer, por supuesto: los datos pesados ​​de lectura deben servirse desde el SSD, y las cosas pesadas de escritura deben dejarse a los discos giratorios tradicionales. ¡Eso incluye registros de transacciones, naturalmente!

Dado el presupuesto suficiente, por supuesto, uno querría usar discos SSD SLC como el X25-E o la serie Vertex Ex o varias ofertas de nivel empresarial. Pero también estoy interesado en consejos que podrían beneficiar las configuraciones de SSD MLC. Creo que es un área interesante. Uno de los clientes de mis clientes tiene un presupuesto pequeño y un conjunto de datos que ha crecido enormemente y se enfrentan a una reescritura completa de casi cien consultas para mantener un nivel de rendimiento decente. Sin embargo, tengo la sospecha de que menos de $ 500 de RAM y espacio en SSD podrían generarles una mayor ganancia de rendimiento que miles (posiblemente decenas de miles) de dólares en tiempo de desarrollo.

No estoy seguro de lo que quiere decir al reducir la cantidad de pequeñas escrituras aleatorias que hace SQL Server. SQL Server escribe páginas de datos solo durante los puntos de control, por lo que la única forma de limitar el número de escrituras es cambiar el intervalo del punto de control o no realizar tantas operaciones de DIU. ¿Querías decir otra cosa?

En todas las implementaciones de SSD que he visto (un puñado), es todo lo contrario de lo que estás sugiriendo: el mejor uso de SSD parece ser para registros de transacciones pesados ​​de escritura y tempdb, básicamente, ¿dónde está el mayor I / O subsistema de cuello de botella y pegue los SSD allí, ya que el tiempo de búsqueda y la latencia se reducen a una constante baja.

Consulte este documento de investigación que MS produjo (desafortunadamente no está muy detallado en los detalles de SQL Server): Migración del almacenamiento del servidor a SSD: análisis de compensaciones .

¡Espero que esto ayude!

No puede modificar las características de E / S de los servidores SQL. Su unidad básica de acceso al disco, para archivos de datos, es una página de 8Kb. Los escribirá principalmente durante un punto de control, pero también los escribirá perezosamente cuando pueda.
SQL no espera a que se completen las escrituras en el disco de datos antes de regresar, solo las escrituras de registro deben completarse. Si solo puede mantener un registro de base de datos en un disco, entonces serán escrituras secuenciales y estarán bien en discos duros rápidos normales.
El impacto en el rendimiento desde el punto de vista de SQL es cuando tiene que leer los discos. Si puede darle más memoria, entonces SQL contendrá más páginas de datos en la memoria, que es más rápido que cualquier tipo de disco, SSD o de otro tipo. Obviamente, también puede reducir la cantidad de lecturas de disco creando índices apropiados. Espero que un SSD también ayude con estas lecturas porque es probable que sean aleatorias y se mantengan en espera de que se muevan los cabezales de las unidades.
No sé de qué tamaño de la base de datos estamos hablando aquí, pero puede que desee echar un vistazo a HyperOS. Hacen discos sata que en realidad son solo una carga de ram ram DDR2, con un SSD o un disco de 2.5 pulgadas como respaldo. El patrón de acceso del servidor no importará mucho. Sin embargo, no pondría los registros en nada como esto. Los registros son los que mantienen sus datos consistentes, necesitan ir en un medio confiable y, a pesar de su SSD y batería de respaldo, y el servidor probablemente tenga un UPS, etc., todavía me sentiría incómodo por no tener mis registros en un disco duro real en algún tipo de matriz RAID tolerante a fallas.

Las pequeñas operaciones aleatorias son la némesis de los discos tradicionales, debido a la latencia de búsqueda de cabeza ... Los SSD son excelentes para abordar exactamente esto.

Con operaciones largas y secuenciales, los discos estándar funcionan bastante bien, por lo que no tendría ningún propósito usar SSD (desde un punto de vista de rendimiento, por supuesto).

No basta con señalar aquí todavía para agregar al hilo de comentarios, pero si configura el tamaño de página de la base de datos / recuento de múltiples lecturas para cualquier cosa en las SSD a un múltiplo del tamaño de página de la SSD, esto no debería ser un problema.

No he trabajado en SQL Server en mucho tiempo, así que no estoy seguro de si estas opciones están disponibles allí. He estado haciendo Oracle y DB2 durante los últimos años y esto resolvería sus inquietudes ya que la base de datos se ajustaría adecuadamente a las características del disco.

Recomendaría alinear la partición donde se almacenan los archivos de la base de datos.

También recomendaría decidir qué pasa en RAID 0 para perf (ldf y TempDB), y colocar datos críticos en RAID 1 (mdf).

En tercer lugar, realmente debe actualizar el firmware de la unidad, así como los controladores / firmware del controlador SATA. Al hacerlo, le da a la compañía de hardware y a sus desarrolladores la oportunidad de optimizar el rendimiento para usted.