Sintomi
Quando un database di SQL Server 2012 o SQL Server 2014 contiene un file di log delle transazioni di grandi dimensioni, non è possibile ripristinare il database nel servizio di archiviazione BLOB (Binary Large Objects) di Microsoft Azure. Ad esempio, se il file del log delle transazioni è così grande che impiega più di 3 minuti per ripristinarlo, non è possibile ripristinare il database. Ad esempio, se Esegui il backup di un database di grandi dimensioni in URL e potrebbe non riuscire con il messaggio di errore seguente:
<DateTime> backup error: 3041, gravità: 16, stato: 1. <DateTime> backup backup non è riuscito a completare il DATABASE di BACKUP del comando BravoII_AS_PROD con DIFFERENZIAle. Controllare il log delle applicazioni di backup per i messaggi dettagliati. <DateTime> spid55 errore: 18210, gravità: 16, stato: 1. <DateTime> spid55 BackupVirtualDeviceFile:: RequestDurableMedia: errore di svuotamento nel dispositivo di backup ' https://xxx.blob.core.windows.net/production/yyy.bck '. Impossibile raccogliere l'errore di errore del sistema operativo dall'endpoint remoto.
E se si Abilita il flag di traccia del backup in URL (DBCC TRACEON (3004, 3051, 3212, 3014, 3605, 1816,-1)), è possibile che vengano ricevute le informazioni simili a quelle seguenti in backuptoUrL log:
<DateTime>: codice di stato HTTP 201, messaggio di stato HTTP creato<DateTime>: payload: Start 7319191552, dimensione cmd 1048576, dimensione payload 1048576, StartTime 84313,5811126, EndTime 84313,6281149, durata 47,0023 MS, tentativi 1, callback eseguito? True<DateTime>: codice di stato HTTP 201, messaggio di stato HTTP creato<DateTime>: il completamento di IO ha modificato le operazioni parallele consentite in 64, il calcolo del numero di throttle Delta di 63 è stato calcolato<DateTime>: si è verificato un timeout in GetCommand, lunghezza del timeout di 20000, riprovare<DateTime>: si è verificato un timeout su GetCommand, lunghezza del timeout di 20000 intervallo di timeout di 20000, riprovare<> DateTime: si è verificato un timeout su GetCommand, lunghezza del timeout di 20000, riprovare<> DateTime: si è verificato un timeout su GetCommand, lunghezza del timeout di 20000, riprovare<DateTime>: si è verificato un timeout su GetCommand, lunghezza del timeout di 20000, riprovare<DateTime> , la lunghezza di timeout di 20000 Riprova<> DateTime: si è verificato un timeout su GetCommand, lunghezza di timeout di 20000, riprova<DateTime>: si è verificato un timeout su GetCommand, lunghezza del timeout di 20000, riprovare<DateTime>: la comunicazione di backup con sqlservr non è riuscita, HR = 0x80770003<> DateTime: si è verificato un errore fatale durante le comunicazioni del motore, le informazioni sulle eccezioni seguono<DateTime>: informazioni sull'eccezione: si è verificato un errore durante le operazioni di trasferimento dei dati con SqlServer, HRESULT: 0x80770003<DateTime>: stack: at Microsoft. SqlServer. VdiInterface. VDI. PerformPageDataTransfer (CloudPageBlob pageBlob, AccessCondition leaseCondition, Boolean forBackup) in BackupToUrl
Risoluzione
Il problema è stato risolto per la prima volta nel seguente aggiornamento cumulativo di SQL Server.
Aggiornamento cumulativo 1 per SQL Server 2014 SP1 /en-us/help/3067839
Aggiornamento cumulativo 6 per SQL Server 2012 SP2 /en-us/help/3052468
Aggiornamento cumulativo 16 per SQL Server 2012 SP1 /en-us/help/3052476
Aggiornamento cumulativo 7 per SQL Server 2014 /en-us/help/3046038
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutti gli aggiornamenti della sicurezza inclusi nell'aggiornamento cumulativo precedente. Vedere gli ultimi aggiornamenti cumulativi per SQL Server:
Stato
Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".
