Compartir a través de


Se produce un error al cargar contenido de blobs o bloques en Azure Blob Storage

En este artículo se describe cómo resolver errores que pueden producirse cuando se usa Microsoft Azure Blob Storage junto con las aplicaciones en la nube para cargar contenido de blobs o bloques.

Requisitos previos

Síntomas

Recibe uno de los siguientes mensajes de error.

Código de error Mensaje de error
BlockCountExceedsLimit "El recuento de bloques no confirmados no puede superar el límite máximo de 100 000 bloques".
InvalidBlobOrBlock "El contenido de bloque o blob especificado no es válido".
InvalidBlock o InvalidBlockList "La lista de bloques especificada no es válida".

Causa 1: La longitud del bloque que se especificó en la llamada Put Block no es válida

La longitud de bloque especificada en la solicitud Put Block URI no es válida por uno o varios de los siguientes motivos:

  • La aplicación o el cliente especificaron un tamaño de bloque que no se admite.

  • El tamaño del bloque es mayor que el tamaño máximo permitido del bloque. Para buscar los límites de tamaño de bloque para diferentes versiones de la API REST de Blob Service, consulte la sección Comentarios del artículo de referencia "Put Block".

  • Cuando intentó cargar bloques de datos mediante más de una aplicación, había bloques no confirmados que tenían longitudes de bloque incoherentes. Esta situación se produce porque diferentes aplicaciones usan longitudes diferentes para cargar datos o porque se produjo un error en una carga anterior.

  • El blob tiene demasiados bloques no confirmados porque se canceló una operación de carga anterior. El número máximo de bloques no confirmados que se pueden asociar a un blob es de 100 000.

Quite los bloques no confirmados mediante la implementación de una de estas soluciones.

Solución 1: Esperar a que la recolección de elementos no utilizados recoga los datos no confirmados

Espere siete días a que la recolección de elementos no utilizados limpie la lista de bloques sin confirmar.

Solución 2: Uso de un blob ficticio para realizar la transferencia de datos

Use el SDK de Azure Storage para transferir los datos mediante un blob ficticio. Para ello, siga estos pasos:

  1. Cree un blob ficticio que tenga el mismo nombre de blob y esté en el mismo contenedor. Este blob puede tener una longitud de cero.

  2. Transfiera el blob mediante una transferencia desbloqueada.

Solución 3: Confirmar la lista de bloques sin confirmar mediante el SDK de Azure Storage

Use el SDK de Azure Storage para confirmar la lista de bloques sin confirmar y limpiar el blob. Para ello, siga estos pasos:

  1. Recupere la lista de bloques sin confirmar realizando una solicitud URI Get Block List en la que el blocklisttype parámetro URI se establece uncommitteden .

  2. Confirme la lista de bloques mediante la solicitud PUT Block List URI.

  3. Elimine el blob.

La siguiente función de PowerShell es un ejemplo de cómo recuperar una lista de bloques sin confirmar y, a continuación, eliminarla. La función requiere los parámetros siguientes.

Nombre del parámetro Descripción
-StorageAccountName Nombre de la cuenta de almacenamiento.
-SharedAccessSignature Token de firma de acceso compartido (SAS) que usa los parámetros <ss=b;srt=sco;sp=rwldc>uri . Estos parámetros se describen en Construcción de un URI de SAS de cuenta.
-ContainerName Nombre del contenedor de almacenamiento.
-BlobName Nombre del blob.
[CmdletBinding()] Param(
    [Parameter(Mandatory=$true, Position=1)] [string] $StorageAccountName,
    [Parameter(Mandatory=$True, Position=1)] [string] $SharedAccessSignature,
    [Parameter(Mandatory=$True, Position=1)] [string] $ContainerName,
    [Parameter(Mandatory=$True, Position=1)] [string] $BlobName
)

# Build the URI strings in the REST API for GET and DELETE.
$uriDelete = (
    "https://$StorageAccountName.blob.core.windows.net/",
    "$ContainerName",
    "/",
    "$BlobName",
    "$SharedAccessSignature"
) -Join ""
$uriGet = (
    "$uriDelete",
    "&comp=blocklist",
    "&blocklisttype=uncommitted"
) -Join ""
Write-Host "The Delete URI is $uriDelete."
Write-Host "The Get URI is $uriGet."

# Make a REST API call to get the uncommitted block list.
$listFileURI = Invoke-WebRequest -Uri $uriGet -Method Get
$FileSystemName = $listFileURI.Content
$String = $FileSystemName -replace '' , ''
$String |
    Select-Xml –XPath "/BlockList/UncommittedBlocks/Block" |
        Select-Object -Expand Node
$Count = $String.Count

# Delete the blob and the uncommitted block.
if ($Count.Count -gt 0) {
    $listFileURI1 =  Invoke-WebRequest -Uri $uriDelete -Method Delete
    $FileSystemName1 = $listFileURI1.StatusCode
    Write-Host "The deletion was successful. The API returned status code $FileSystemName1."
}

Write-Host "Check whether the uncommitted blocks are still present."
Try {
    $listFileURI2 = Invoke-WebRequest -Uri $uriGet -Method Get
} Catch {
    # $err = $_.Exception
    Write-Host "StatusCode:" $_.Exception.Response.StatusCode.value__
    Write-Host "StatusDescription:" $_.Exception.Response.StatusDescription
}

Write-Host (
    "In this error message, we can verify that the",
    "uncommitted blocks and their respective blob have been deleted.",
    "The name and size of the uncommitted blocks that have been deleted are shown."
)

Causa 2: Las operaciones PUT se producen simultáneamente para un blob

Se produce un problema de temporización o simultaneidad. Esto hace que se produzcan varias operaciones PUT (Put Block) aproximadamente al mismo tiempo para un solo blob. La operación Put Block List escribe un blob especificando la lista de identificadores de bloque que componen el blob. Para escribirse como parte de un blob, un bloque debe haberse escrito correctamente en el servidor en una operación put block anterior.

Nota:

Este error puede producirse durante las confirmaciones de carga simultáneas después de iniciar la carga, pero antes de confirmarla. En este caso, se produce un error en la carga. La aplicación puede reintentar la carga cuando se produce el error o puede probar otra acción de recuperación basada en el escenario necesario.

Solución: Uso de concesiones

En lugar de usar la simultaneidad optimista, intente implementar la simultaneidad pesimista (concesiones) mediante el SDK de Azure Storage o una herramienta basada en GUI, como Explorador de Azure Storage. Para obtener más información sobre la simultaneidad optimista y pesimista, consulte Administración de la simultaneidad en Blob Storage.

Si el error se debe a problemas de simultaneidad, es posible que también tenga que limpiar los bloques no confirmados siguiendo una de las soluciones de la causa 1.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.