Comentarios en: Optimización avanzada de Backups: BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT

Por: Reduce el tiempo de tus BACKUPS a la mitad o más - SoyDBA

Reduce el tiempo de tus BACKUPS a la mitad o más - SoyDBA — Sun, 26 Jan 2025 23:13:57 +0000

[…] semana pasada publiqué un post sobre las configuraciones avanzadas de backups BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT y cómo impactan en el rendimiento de nuestras copias de seguridad. A raíz de este artículo, […]

Por: Héctor Dobao

Héctor Dobao — Thu, 23 Jan 2025 09:46:51 +0000

Quiero corregir una errata. En el final del texto cuando menciono «blobs» me refería a «BLOCKS» que básicamente es el número de bloques permitidos en un blob container (contenedor de blobs en la Storage Account de Azure). El artículo correcto es este:

Grandísimo Artículo, Roberto!
Estoy actualmente jugando con estos mismos parámetros para hacer un backup en la SQL Managed Instance que expliqué en mi sesión de «SQL Server en Español».
El concepto es el mismo pero la sintaxis cambia un poco. BACKUP TO URL XXXX.
Cómo bien dice la documentación siempre han de ser COPY_ONLY y se harán a una Azure Storage Account, preferentemente usando el tipo BLOCK BLOB (en lugar de los vetustos page blobs).
Haciendo esto hay que tener en cuenta que las Storage accounts tienen un límite específico de tamaño del block blob (el formato con el que se almacena nuestro fichero .BAK en la Storage Account). La REST API hasta ahora tenía 195 GB por block blob con lo que te obliga a hacer un backup en «stripes ó partes» en lugar de un sólo file.
Es cierto que aplicando el campo de COMPRESSION podemos intentar optimizar y reducir el número de ficheros .bak troceados pero no menos importante es el flag que aquí mencionas (MAXTRANSFERSIZE) que para este tipo de backups yo recomiendo de poner a 4MB (4194304) ya que podría alcanzarse el número máximo de bloques (BLOCKS) permitidos (50.000) al transferirse unidades más pequeñas al storage desde la instancia de SQL (por ejemplo MAXTRANSFERSIZE = 1 MB).
En este artículo explica cómo podemos evitar esa limitación de los 195 GB por fichero pero también cómo evitar la limitación de 50000 bloques permitidos, la cual elevando el MAXTRANSFERSIZE a 4MB (lo máximo que soporta SQL Server), sortearíamos también.
URL: https://learn.microsoft.com/es-es/archive/blogs/sqlcat/backing-up-a-vldb-to-azure-blob-storage

Por: Héctor Dobao

Héctor Dobao — Thu, 23 Jan 2025 09:42:11 +0000

Grandísimo Artículo, Roberto!
Estoy actualmente jugando con estos mismos parámetros para hacer un backup en la SQL Managed Instance que expliqué en mi sesión de «SQL Server en Español».
El concepto es el mismo pero la sintaxis cambia un poco. BACKUP TO URL XXXX.
Cómo bien dice la documentación siempre han de ser COPY_ONLY y se harán a una Azure Storage Account, preferentemente usando el tipo BLOCK BLOB (en lugar de los vetustos page blobs).
Haciendo esto hay que tener en cuenta que las Storage accounts tienen un límite específico de tamaño del block blob (el formato con el que se almacena nuestro fichero .BAK en la Storage Account). La REST API hasta ahora tenía 195 GB por block blob con lo que te obliga a hacer un backup en «stripes ó partes» en lugar de un sólo file.
Es cierto que aplicando el campo de COMPRESSION podemos intentar optimizar y reducir el número de ficheros .bak troceados pero no menos importante es el flag que aquí mencionas (MAXTRANSFERSIZE) que para este tipo de backups yo recomiendo de poner a 4MB () ya que podría alcanzarse el número máximo de blobs permitidos (50.000) al transferirse unidades más pequeñas al storage desde la instancia de SQL (por ejemplo 1 MB).
En este artículo explica cómo podemos evitar esa limitación de los 195 GB por fichero pero también la limitación de blobs permitidos, la cual elevando el MAXTRANSFERSIZE a 4MB (lo máximo que soporta SQL Server), salvaríamos también.
URL: https://learn.microsoft.com/es-es/archive/blogs/sqlcat/backing-up-a-vldb-to-azure-blob-storage