¿Qué puedo agregar a un servidor para que las restauraciones de SQL sean más rápidas?

Tengo una base de datos SQL de 2.8TB (principalmente archivos de datos, unos 400GB de archivos de registro) que actualmente tarda alrededor de 9 horas en restaurar. Esta base de datos se utiliza con fines de prueba y debe eliminarse y restaurarse desde una copia de seguridad entre cada ejecución, para asegurarse de que siempre comencemos desde el mismo punto.

Mi pregunta es que el servidor actualmente tiene 12 núcleos y 92 GB de RAM, con un subsistema de disco RAID 5 en el que se encuentra la base de datos. ¿Qué áreas suelen causar cuellos de botella para los procesos de restauración de SQL? ¿Es el disco, la memoria o la CPU?

sql-server performance

— Sean Long
fuente

¿Desde qué medio de respaldo está restaurando? Por cierto, RAID 5 incurre en una fuerte penalización de escritura en comparación con la mayoría de los otros niveles de RAID, por lo que este puede no ser el mejor para las pruebas de rendimiento.

— Chris McKeown

Los .bak (8 de ellos divididos) están en la misma matriz RAID 5 a la que se están restaurando, lo que me hace darme cuenta de que probablemente pueda manejarlo mejor en el futuro. No tengo otra matriz lo suficientemente grande como para contener todos los archivos .bak, pero podría dividirlos en diferentes unidades conectadas directamente. Además, es un buen punto sobre el RAID 5. Soy consciente de eso, pero todavía no estamos haciendo pruebas de estrés, por lo que está bien si hay un cuello de botella en la unidad de disco en este momento durante las pruebas de carga reales. Una vez que avancemos un poco más, aumentaremos el rendimiento del disco a través de SAN, RAID 0 o RAID 1 + 0

— Sean Long

Ciertamente, también sufres excesivamente por tener las copias de seguridad en el disco que estás restaurando. ¿Cuántos discos hay en tu RAID5 actual?

— Mark Storey-Smith

Así que estás usando compresión, supongo. ¿Qué otras opciones de respaldo estás usando? ¿Cómo se particionan sus datos? ¿Puede distribuir datos de manera inteligente entre los grupos de archivos (podría hacer copias de seguridad y restauraciones de grupos de archivos con los datos modificados)?

— swasheck

El problema es que las pruebas tocan un porcentaje muy grande de la base de datos, por lo que tendríamos que restaurar en varios grupos de archivos (y las pruebas cambiarían según las necesidades y el desarrollo de la carga de trabajo). Por lo tanto, tendríamos que mirar constantemente el maquillaje de prueba y restaurar los grupos de archivos específicos. Si bien esa es una opción, no estoy seguro de que nos permita ahorrar mucho tiempo.

— Sean Long

Respuestas:

Su principal cuello de botella en una restauración será el disco IO. Para solucionarlo, básicamente necesita discos más rápidos o una configuración diferente. Sin embargo, no sé lo suficiente sobre RAID o SAN para sugerir nada. Incluso podría considerar SSD. Son cegadoramente rápidos. No me gustaría usarlos en algo que no se vuelva a crear de forma regular (tempdb siempre es un buen candidato para esto), pero dado que lo restaura con frecuencia, podría estar bien. Por otro lado, es probable que desee asegurarse de que su servidor de prueba esté lo más cerca posible de su servidor de producción si está realizando pruebas de rendimiento.

Hay un par de otras cosas que puedes hacer para ayudarte. Primero comprima sus copias de seguridad si aún no lo ha hecho. Por supuesto, esto supone SQL 2008 o superior. Reducirá no solo el espacio en disco para almacenar la copia de seguridad sino también el IO para leerla. Hay un costo de CPU involucrado, así que tenga en cuenta. Tampoco elimine su base de datos, solo restaure sobre ella. De esta manera, los archivos ya están en su lugar y no hay gastos generales para crearlos. Puede activar la inicialización instantánea de archivos (es un permiso de nivel de servidor) para acelerar drásticamente la creación / crecimiento de archivos para su archivo de datos, pero no funcionará para su archivo de registro.

— Kenneth Fisher
fuente

Buena información, no me di cuenta de que restaurar sobre lo existente es mejor que soltar / restaurar desde una copia de seguridad. Ya estamos usando la compresión y estoy planeando verificar que la inicialización instantánea de archivos esté habilitada para la cuenta que realiza la restauración. Realmente aprecio la claridad de su respuesta, ¡gracias!

— Sean Long

Asegúrese de que la inicialización instantánea de archivos esté activada en la cuenta que ejecuta SQL Server también. Para una base de datos pequeña, probablemente no sea tan importante, pero para algo del tamaño que está viendo podría hacer una gran diferencia.

— Kenneth Fisher

Buena llamada. También gracias por darse cuenta de que las pruebas de rendimiento no siempre significan pruebas de estrés (y que estoy bastante limitado por la forma en que se configura mi configuración de producción, actualmente).

— Sean Long

OT: "considere los SSD ... no me gustaría usarlos en algo que no se vuelva a crear de forma regular" ... ¿por qué?

— Martin

Todavía estaría nervioso porque ellos fallaran. Todo lo que he leído me dice que los use para bases de datos como tempdb que se recrean cada vez que se inicia la instancia, pero no para usarlos en bases de datos de usuarios normales. Aunque estoy seguro de que eso está cambiando con el tiempo.

— Kenneth Fisher

No haga una copia de seguridad y restauración; usar instantáneas de SQL Server. Se necesita mucho espacio en disco para almacenar un archivo disperso del mismo tamaño que los archivos que ha capturado, pero retroceder es cientos de veces más rápido.

Están disponibles en las ediciones SQL Server Enterprise y SQL Server Developer.

— Mark Henderson
fuente

Esa es una buena idea, y si se tratara de cualquier otro servidor que no sea un servidor de prueba de rendimiento, parece una excelente manera de hacerlo. Sin embargo, parece que las instantáneas de la base de datos no funcionarán porque causará una sobrecarga adicional para la base de datos de origen, que no puedo tener. La prueba que se está realizando es una prueba de rendimiento (carga, estrés, etc.), por lo que debemos evitar cualquier cosa externa que pueda causar estrés.

Personalmente, no he notado ninguna diferencia de rendimiento con tener una instantánea, pero supongo que la copia en escritura tiene algo de sobrecarga; sin conocer tu carga de trabajo no puedo juzgar.

— Mark Henderson

La sugerencia de @SeanLong Mark es probablemente la mejor opción para su escenario. Lo que creo que estás malentendido es cuándo y de qué tomas la instantánea. El plan en un servidor de prueba sería restaurar la base de datos de prueba de su copia de seguridad en vivo, luego tomar una instantánea de la base de datos de prueba, ejecutar su ciclo de prueba, luego revertir la instantánea, enjuagar y repetir. Periódicamente puede volver al paso 1 y restaurar la copia de seguridad en vivo para volver a probar.

— Mark Storey-Smith

Ah, ya veo. Pensé que mantener la instantánea requería una cantidad constante de sobrecarga de la base de datos de prueba, lo que afectaría nuestras pruebas de carga (muy pesadas en escritura / lectura). No me importa si nuestra carga de trabajo está causando el cuello de botella en la unidad de disco, simplemente no quiero un factor externo (que pensé que sería la captura de db) para causarlo.

— Sean Long