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

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.

sql-server backup best-practices maintenance Solomon Rutzky
fuente

Por curiosidad, ¿estás tratando de solucionar un problema de copia de seguridad lenta? Normalmente, los valores predeterminados funcionan bien en la mayoría de los entornos. Además, la opción de energía está configurada para un alto rendimiento, ya que la copia de seguridad utiliza ciclos de CPU.

Kin Shah

@ Kin No, las copias de seguridad no son específicamente lentas. Pero, si hacer un cambio menor los haría / podría hacerlos un 20% (o más) más rápidos, entonces ciertamente lo tomaría. Para 206 bases de datos, se necesitan aproximadamente 62 minutos para las copias de seguridad COMPLETAS (una vez por semana) y entre 7 y 20 minutos para las copias de seguridad DIFF en los días restantes. Y eso los está ejecutando secuencialmente (hilo único). Cuando comencé con este cliente, la configuración anterior era usar 4 MB para MaxTransfer y 50 para BufferCount. En este momento solo estoy usando los valores predeterminados, por lo que no estoy seguro de si anulé una ganancia de rendimiento, por lo que quería aprender más antes de realizar cualquier cambio.

Solomon Rutzky

@srutzky, solo un punto rápido de su último comentario, ahorré un tiempo considerable dividiendo mis copias de seguridad en varios archivos que van al mismo volumen. Solo quería compartirlo contigo en caso de que aún no lo hayas intentado. Si sus 206 DB ejecutan una copia de seguridad en paralelo a través de múltiples DB, es posible que no obtenga los beneficios de subprocesos múltiples.

Ali Razeghi

@MaxVernon "Las copias de seguridad de la interfaz del dispositivo virtual (VDI) permiten que las soluciones de copia de seguridad de terceros se integren con el SQL Server", que se tomó del Recurso # 10 en mi Pregunta :). No quería pasar por tanto esfuerzo ;-)

Solomon Rutzky

@srutzky en caso de que quiera divertirse: lea las copias de seguridad de MSSQL, verifique el tamaño máximo de transferencia de HBA , el tipo es brillante y muy minucioso en sus pruebas. Y algo que probablemente coincida con sus pruebas: el ajuste automático de respaldo de SirSQL .

Marian

Establecer BUFFERCOUNT, BLOCKSIZE y MAXTRANSFERSIZE para el comando BACKUP

Respuestas: