Establecer BUFFERCOUNT, BLOCKSIZE y MAXTRANSFERSIZE para el comando BACKUP

Busco práctica guía para establecer los valores para el BUFFERCOUNT, BLOCKSIZEy MAXTRANSFERSIZEdel BACKUPcomando. He hecho un poco de investigación (ver más abajo), he hecho un poco de prueba, y soy plenamente consciente de que cualquier respuesta verdaderamente valiosa comenzará con "Bueno, depende ...". Mi preocupación por las pruebas que he realizado y las pruebas que se muestran en cualquiera de los recursos que he encontrado (ver más abajo) es que las pruebas se realizan en el vacío, muy probablemente en un sistema sin otra carga.

Tengo curiosidad acerca de la orientación adecuada / mejores prácticas con respecto a estas tres opciones que se basan en la experiencia a largo plazo: muchos puntos de datos durante semanas o meses. Y no estoy buscando valores específicos ya que eso es principalmente una función del hardware disponible, pero me gustaría saber:

• Cómo varios factores de hardware / carga influyen en lo que se debe hacer.
• ¿Hay circunstancias en las que ninguno de estos valores debe ser anulado?
• ¿Existen dificultades para anular cualquiera de estos que no son inmediatamente obvios? ¿Usa demasiada memoria y / o E / S de disco? ¿Complicando las operaciones de restauración?
• Si tengo un servidor con varias instancias de SQL Server ejecutándose (una instancia predeterminada y dos instancias con nombre), y si ejecuto las copias de seguridad de las 3 instancias simultáneamente, ¿eso afecta la forma en que configuro estos valores más allá de asegurarme de que el colectivo ( BUFFERCOUNT* MAXTRANSFERSIZE) no supera la RAM disponible? ¿Posible contención de E / S?
• En el mismo escenario de tener las tres instancias en un servidor y volver a ejecutar las copias de seguridad en los tres al mismo tiempo, ¿cómo afectaría también la configuración de estos valores al ejecutar las copias de seguridad para múltiples bases de datos simultáneamente en cada instancia? Es decir, si cada una de las tres instancias tiene 100 bases de datos cada una, se ejecutan 2 o 3 copias de seguridad por cada instancia simultáneamente, de modo que hay entre 6 y 9 copias de seguridad ejecutándose simultáneamente. (En esta situación, tengo muchas bases de datos pequeñas a medianas en lugar de algunas grandes).

Lo que he reunido hasta ahora:

• BLOCKSIZE:

  • Los tamaños admitidos son 512, 1024, 2048, 4096, 8192, 16384, 32768 y 65536 (64 KB) bytes. ^[1]
  • El valor predeterminado es 65536 para dispositivos de cinta y 512 de lo contrario ^[1]
  • Si está realizando una copia de seguridad en la que planea copiar y restaurar desde un CD-ROM, especifique BLOCKSIZE = 2048 ^[1]
  • Cuando escribe en discos individuales, el valor predeterminado de 512 está bien; si usa matrices RAID o SAN, debe probar para ver si el valor predeterminado o 65536 es mejor. ^{[13 (página 18)]}

  • Si se configura manualmente, el valor debe ser> = el Tamaño de bloque utilizado para crear los archivos de datos; de lo contrario, obtendrá el siguiente error:

    Msg 3272, Nivel 16, Estado 0, Línea 3
    El dispositivo 'C: \ Archivos de programa \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' tiene un tamaño de sector de hardware de 4096, pero el parámetro de tamaño de bloque especifica un valor de anulación incompatible de 512. Vuelva a emitir la declaración utilizando un tamaño de bloque compatible.

• BUFFERCOUNT:

  • Por defecto ^{[2], [8]} :

    SQL Server 2005 y versiones posteriores:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [misterio_multiplicador]: hay alguna inconsistencia con respecto a este valor. Lo he visto expresado en 3 formas:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    Las pruebas que muestran que el multiplicador 3se realizó en SQL Server 2005 SP2 ^[9] .

    Mis pruebas en SQL Server 2008 R2 y 2012, y un comentario de un usuario sobre SQL Server 2014 ^[8] , muestran el multiplicador 4. Significado, dado el valor informado para GetSuggestedIoDepth(directamente debajo), ya sea:

    • GetSuggestedIoDepthes ahora 4o
    • el multiplicador es ahora GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthdevoluciones 3para dispositivos DISK ^[9]
  • No hay un valor máximo establecido, pero dado que se requiere memoria = ( BUFFERCOUNT* MAXTRANSFERSIZE), parecería que un valor máximo práctico sería: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Los valores posibles son múltiplos de 65536 bytes (64 KB) que van hasta 4194304 bytes (4 MB). ^[1]
  • Valores predeterminados: si el dispositivo está en modo de lectura (restauración) o se trata de una Edición de escritorio o Express, use 64K, de lo contrario use 1 MB. ^[9]
• General / Misceláneo:
  • El tamaño máximo que se puede utilizar es ( Buffer Pool's To Physical Memory / 16 ). Según lo devuelto por la llamada API GlobalMemoryStatusEx (ullTotalPhys). ^[9]
  • Trace Flag 3213emite parámetros de configuración de copia de seguridad / restauración mientras realiza operaciones de copia de seguridad / restauración, y 3605vuelca la salida al archivo ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • Puede usar DISK = N'NUL:'(equivalente a DOS / Windows /dev/nullen UNIX) para probar más fácilmente algunas métricas (pero no obtendrá una buena idea del tiempo total del proceso ya que se saltea la E / S de escritura)

Recursos

1. Página de MSDN para el comando T-SQL BACKUP
2. KB904804: Experimenta un rendimiento lento cuando realiza una copia de seguridad de la base de datos en SQL Server 2000
3. Opciones para mejorar el rendimiento de la copia de seguridad de SQL Server
4. Copia de seguridad y restaurar
5. Optimización de la copia de seguridad y restauración de SQL Server
6. Optimizar el rendimiento de la copia de seguridad
7. Cómo aumentar la velocidad de la copia de seguridad completa de la base de datos SQL utilizando compresión y discos de estado sólido
8. La opción incorrecta de transferencia de datos de BufferCount puede conducir a la condición de OOM
9. Cómo funciona: cómo Copia de seguridad y restauración de SQL Server selecciona tamaños de transferencia
10. Cómo funciona: SQL Server Backup Buffer Exchange (un foco VDI)
11. Copia de seguridad SQL que ajusta grandes bases de datos
12. Memoria del servidor SQL para el buffer de respaldo
13. Un estudio de caso: copia de seguridad y restauración rápidas y confiables de un VLDB a través de la red (archivo .docx)
14. ¿Cuántos dispositivos de respaldo se recomiendan para mejorar el rendimiento del respaldo?

Probé con:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

ACTUALIZAR

Parece que a veces me olvido de agregar parte de la información que siempre les pido a los demás que proporcionen cuando respondo una pregunta ;-). Sí proporcioné información sobre mi situación actual, pero puedo proporcionar más detalles:

Estoy trabajando para un cliente que proporciona una aplicación SaaS 24/7 / 365.25. Por lo tanto, existe la posibilidad de que los usuarios estén activos en cualquier momento, pero de manera realista, todos los usuarios tienen su sede en los EE. UU. (Por ahora) y tienden a trabajar en su mayoría horas "estándar": 7 a.m. Pacífico (es decir, 10 a.m. Este) a 7 p.m. Pacífico (es decir, 10 p. m., hora del este), pero los 7 días de la semana, no solo de lunes a viernes, aunque la carga del fin de semana es un poco más ligera.

Están configurados de modo que cada cliente tenga su propia base de datos. Es una industria de nicho, por lo que no hay decenas de miles (o más) de clientes potenciales. El número de DB de cliente varía según la instancia, y la instancia más grande tiene 206 clientes. El DB más grande es de aprox. 8 GB, pero solo unos 30 DB tienen más de 1 GB. Por lo tanto, no estoy tratando específicamente de maximizar el rendimiento de un VLDB.

Cuando comencé con este cliente, sus copias de seguridad siempre estaban COMPLETAS, una vez al día, y sin copias de seguridad de LOG. También habían establecido MAXTRANSFERSIZE en 4 MB y BUFFERCOUNT en 50. Reemplacé esa configuración con una versión ligeramente personalizada del script de copia de seguridad de la base de datos de Ola Hallengren . La parte ligeramente personalizada es que se ejecuta desde una herramienta de subprocesos múltiples (que escribí y espero comenzar a vender pronto) que descubre dinámicamente los DB a medida que se conecta a cada instancia, y permite la aceleración por instancia (por lo tanto, actualmente estoy ejecutando el tres instancias simultáneamente, pero las bases de datos por cada instancia de forma secuencial ya que no estaba seguro de las ramificaciones de ejecutarlas simultáneamente).

La configuración es hacer una copia de seguridad COMPLETA un día por semana y copias de seguridad DIFF los otros días; Las copias de seguridad de LOG se toman cada 10 minutos. Estoy usando los valores predeterminados para las 3 opciones que estoy investigando aquí. Pero, sabiendo cómo se habían configurado, quería asegurarme de que no estaba deshaciendo una optimización (solo porque había algunas fallas importantes en el viejo sistema no significa que todoestaba mal). Actualmente, para las 206 bases de datos, se necesitan aproximadamente 62 minutos para las copias de seguridad COMPLETAS (una vez a la semana) y entre 7 y 20 minutos para las copias de seguridad DIFF en los días restantes (7 el primer día después de las COMPLETAS y 20 el último día anterior el próximo COMPLETO). Y eso los está ejecutando secuencialmente (hilo único). El proceso de copia de seguridad de LOG, en total (todas las bases de datos en las 3 instancias), tarda entre 50 y 90 segundos cada vez (nuevamente, cada 10 minutos).

Me doy cuenta de que puedo ejecutar varios archivos por base de datos, pero a) no estoy seguro de cuánto mejor se les dará el subprocesamiento múltiple y el tamaño pequeño a mediano de las bases de datos, yb) no quiero complicar el proceso de restauración ( Hay varias razones por las que se prefiere tratar con un solo archivo).

También me di cuenta de que podía habilitar la compresión (mi consulta de prueba lo ha desactivado intencionalmente), y se lo recomendé al equipo, pero me llamó la atención que la compresión incorporada es un poco desagradable. Parte del proceso anterior consistía en comprimir cada archivo en un RAR, e hice mis propias pruebas y descubrí que sí, la versión RAR es al menos un 50% más pequeña que la versión comprimida de forma nativa. Intenté usar la compresión nativa primero para acelerar las cosas y luego RAR los archivos, pero esos archivos, aunque eran más pequeños que los comprimidos de forma nativa, aún eran un poco más grandes que la versión comprimida solo RAR, y con una diferencia suficiente para justificar No utiliza compresión nativa. El proceso para comprimir las copias de seguridad es asíncrono y se ejecuta cada X minutos. Si encuentra un .bako.trnarchivo, lo comprime. De esta forma, el proceso de copia de seguridad no se ralentiza por el tiempo que lleva comprimir cada archivo.

Has abordado un montón de artículos en tu pregunta. ¡Gracias por ser tan minucioso!

Solo un par de cosas que noto de inmediato:

• Cómo varios factores de hardware / carga influyen en lo que se debe hacer.

¿Estás ejecutando una instancia 24x7? ¿Cuál es la carga durante todo el día? Noto que tiene la compresión de respaldo deshabilitada; ¿Es eso por diseño para la prueba, o es deseable por alguna razón tenerlo apagado cuando lo pones en producción? Si tiene toneladas de espacio libre de hardware (CPU / RAM), y completar la copia de seguridad en el menor tiempo es de suma importancia, entonces querrá ajustar estos parámetros para el hardware particular que tiene con ese objetivo en mente. Si desea asegurarse de que las cargas de trabajo OLTP se atiendan las 24 horas del día y no desea que la copia de seguridad afecte eso, es probable que deba ajustar estos parámetros al revés. Sin embargo, no ha identificado sus objetivos de diseño ya que solicita orientación general, ya que tan sabiamente dice "depende".

• ¿Hay circunstancias en las que ninguno de estos valores debe ser anulado?

Desearía conservar la configuración predeterminada si le preocupaba la compatibilidad en el futuro después de que ya no mantiene la instancia y no está seguro acerca de las capacidades de su reemplazo. Es probable que desee dejar los valores predeterminados en su lugar a menos que tenga una necesidad específica de ajustarlos. Deje que los perros dormidos mientan, como dicen.

• ¿Existen dificultades para anular cualquiera de estos que no son inmediatamente obvios? ¿Usa demasiada memoria y / o E / S de disco? ¿Complicando las operaciones de restauración?

Como indican claramente los documentos a los que hace referencia, aumentar demasiado estos parámetros puede tener un impacto negativo en el tiempo de actividad. Al igual que con todas las cosas basadas en la producción, debe probar esto a fondo antes de implementarlo y dejar la configuración sola a menos que sea absolutamente necesario.

• Si tengo un servidor con varias instancias de SQL Server ejecutándose (una instancia predeterminada y dos instancias con nombre), y si ejecuto las copias de seguridad de las 3 instancias simultáneamente, ¿eso afecta la forma en que configuro estos valores más allá de asegurarme de que el colectivo (BUFFERCOUNT * MAXTRANSFERSIZE) no excede la RAM disponible? ¿Posible contención de E / S?

Querrá asegurarse de dejar suficiente RAM para circunstancias imprevistas. Ciertamente me preocuparía usar más del 60% o 70% de RAM disponible para operaciones de respaldo a menos que supiera con 100% de certeza que nada más sucederá durante la ventana de respaldo.

Escribí una publicación de blog con un código que muestra cómo hago las pruebas de rendimiento de copia de seguridad, en SQLServerScience.com

^{Esta puede no ser la mejor respuesta que he escrito, pero como The Great One ™ dijo una vez, "se pierde el 100% de las fotos que no toma"}