Проблемы
Если база данных SQL Server 2012 или SQL Server 2014 имеет большой файл журнала транзакций, восстановить базу данных в службе хранилища больших двоичных объектов Microsoft Azure нельзя. Например, если размер файла журнала транзакций настолько велик, что для его восстановления требуется более 3 минут, восстановить базу данных нельзя. Например, если вы хотите создать резервную копию базы данных с очень большим адресом URL-адреса, может произойти сбой со следующим сообщением об ошибке:
<DateTime> ошибка резервного копирования: 3041, уровень важности: 16, состояние: 1. <DateTime> Архивация резервной копии не удалось выполнить командную базу данных архивации BravoII_AS_PROD с помощью РАЗНОСТной резервной копии. Проверьте журнал приложений резервного копирования на предмет подробных сообщений. <DateTime> spid55 Error: 18210, Severity: 16, State: 1. <DateTime> spid55 BackupVirtualDeviceFile:: RequestDurableMedia: сбой сброса на устройстве резервного копирования "https://xxx.blob.core.windows.net/production/yyy.bck". Не удалось собрать ошибку операционной системы с удаленной конечной точки.
Кроме того, если вы включите флаг трассировки URL-адреса "резервное копирование" (DBCC TRACEON (3004, 3051, 3212, 3014, 3605, 1816,-1)), вы можете получить информацию, похожую на приведенную ниже, в журнале backuptoUrL.
<DateTime>: код состояния HTTP 201, сообщение о состоянии HTTP, созданное<DateTime>: полезные данные: Start 7319191552, команда размером 1048576, размер полезных данных 1048576, StartTime 84313,5811126, EndTime 84313,6281149, продолжительность 47,0023 МС, попыток 1, Дата и ответ True<DateTime>: код состояния HTTP 201, сообщение о состоянии HTTP, созданное<DateTime>: выполнение операции ввода-вывода изменило число допустимых параллельных операций на 64, счетчик регулирования числа потоков 63 был вычислен<DateTime>: истекло время ожидания<DateTime>: время ожидания для команды DATALENGTH, время ожидания, равное 20000, будет повторно попыток<DateTime>.20000 время ожидания в 20000 пытается попытаться<datetime>: тайм-аут, заданный в команде DATALENGTH, время ожидания, равное 20000, пытается выполнить повторную попытку<datetime>: тайм-аут, установленный в 20000, попытается<дата и время ожидания. 20000 , время ожидания для 20000 попытается<DateTime>: время ожидания в команде DATALENGTH, время ожидания, равное 20000, будет повторено<DateTime>: тайм-аут, установленный для команды DATALENGTH, время ожидания, равное 20000, попытается выполнить повторную попытку<DateTime>: сбой при обмене данными с SqlServr HR = 0x80770003<DateTime>: неустранимая ошибка, возникающая во время обмена данными с обработчиком, сведения об исключении пропадают при выполнении операций с помощью SQLServer, HRESULT: 0X80770003<DateTime>: Stack: в Microsoft. SqlServer. VdiInterface. VDI. PERFORMPAGEDATATRANSFER (CloudPageBlob pageBlob, AccessCondition leaseCondition, ForBackup) в BackupToUrl. Program. MainInternal (String [] args).><
Решение
Эта проблема впервые устранена в следующем накопительном обновлении SQL Server.
Накопительное обновление 1 для SQL Server 2014 с пакетом обновления 1 (SP1) /en-us/help/3067839
Накопительное обновление 6 для SQL Server 2012 с пакетом обновления 2 (SP2) /en-us/help/3052468
Накопительное обновление 16 для SQL Server 2012 с пакетом обновления 1 (SP1) /en-us/help/3052476
Накопительное обновление 7 для SQL Server 2014 /en-us/help/3046038
Все новые накопительные обновления для SQL Server содержат все исправления и все исправления для системы безопасности, которые были включены в предыдущий накопительный пакет обновления. Ознакомьтесь с самыми последними накопительными обновлениями для SQL Server.
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".