☰

Почему я получаю сообщение «ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ ЗАВЕРШЕНО НЕПРАВИЛЬНО» (ошибка 3013) при восстановлении из хранилища BLOB-объектов Azure в SQL Server 2014?

tag-icon • tag-icon sql-server azure sql-server-2014
Почему я получаю сообщение «ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ ЗАВЕРШЕНО НЕПРАВИЛЬНО» (ошибка 3013) при восстановлении из хранилища BLOB-объектов Azure в SQL Server 2014?

Наш сервер рабочей базы данных каждую ночь создает резервные копии своих баз данных в Azure Blob Storage, используя команду BACKUP TO URLв SQL Server 2014 Standard. Сейчас я пытаюсь восстановить эти резервные копии на новую виртуальную машину SQL Server, которую мы настроили в Azure, на которой также работает SQL Server 2014 Standard. Я запускаю следующую команду SQL:

RESTORE DATABASE Example FROM URL = 'https://exampleaccount.blob.core.windows.net/livedbbackups/ExampleBackup-2015-10-15T01-13-08.bak';
WITH CREDENTIAL = 'AzureBackupCredential', 
MOVE 'Example' TO 'C:\Databases\Example.mdf',
MOVE 'Example_log' TO 'C:\Databases\Example.ldf',
STATS = 5;

Когда я это делаю, восстановление выполняется более 10 минут, и я вижу его прогресс в окне «Сообщения» SQL Server Management Studio. Однако, прямо перед тем, как оно будет выполнено на 100%, отображается следующее сообщение об ошибке.

Вывод на виртуальной машине Azure под управлением Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64-разрядная версия) на Windows NT 6.3 (сборка 9600: ) (гипервизор):

85 percent processed.
90 percent processed.
95 percent processed.
Msg 3013, Level 16, State 1, Line 5
RESTORE DATABASE is terminating abnormally.

Поиск в Google "Ошибка SQL Server 3013" или "Аномальное завершение восстановления базы данных SQL Server" выдает множество страниц, предполагающих, что мой файл базы данных поврежден. Однако я так не думаю, потому что я могу запуститьточно такой же SQLна моем ноутбуке, работающем под управлением SQL Server 2014 Express, я получаю следующий вывод:

Вывод на ноутбуке с установленным Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Express Edition (64-разрядная версия) на Windows NT 6.3 (сборка 10240: ) (гипервизор):

85 percent processed.
90 percent processed.
95 percent processed.
100 percent processed.
Processed 233600 pages for database 'Example', file 'Example' on file 1.
Processed 5 pages for database 'Example', file 'Example_log' on file 1.
RESTORE DATABASE successfully processed 233605 pages in 205.802 seconds (8.867 MB/sec).

Оба эти оператора восстановления были запущены для одного и того же URL с одним и тем же неизмененным файлом резервной копии. Если он восстанавливается правильно на моей локальной копии SQL Server Express, он не может быть поврежден, верно?

Вот еще несколько возможных причин, которые я попытался исключить:

  • Несоответствие версий- Резервное копирование было запущено на сервере под управлением Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Standard Edition (64-bit). Восстановление было запущено на сервере под управлением Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64-bit). Эти номера версий были определены путем запуска SELECT @@VERSIONна каждом из серверов.
  • Ошибки разрешений- Оба метода корректно RESTORE HEADERONLYработают RESTORE FILELISTONLYна виртуальной машине Azure, которая не восстанавливает базу данных.
  • Свободное место- На диске C: на виртуальной машине Azure свободно более 80 ГБ.
  • Сетевое подключение- Я не проводил обширного тестирования, но, учитывая, что виртуальная машина, на которой запущен SQL Server, работает внутри Azure, а файл резервной копии также находится в Azure, я полагаю, что все довольно стабильно. Загрузки файлов и простые тесты с браузером, похоже, указывают на то, что соединение стабильно и быстро.

База данных, о которой идет речь, занимает около 2 ГБ после восстановления, с файлом журнала размером 5 ГБ. У меня есть другие резервные копии той же базы данных, хранящиеся в Azure, и я получаю те же результаты при попытке восстановить любую из них (работает на локальном SQL Server Express 2014, не работает на Azure VM SQL Server Standard 2014).

Есть идеи, что может быть причиной этого и как это исправить?

решение1

Эта тема немного устарела, но сегодня я столкнулся с той же проблемой. Я сделал восстановление из хранилища blob некоторое время назад, и все работало нормально, неделю спустя то же самое восстановление возвращало ошибку «RESTORE DATABASE TERMINATED ABORMALLY». Поэтому я переместил свои файлы резервных копий в другой контейнер, и все работало нормально.

Надеюсь, этот способ решения проблемы поможет кому-то еще.

Связанный контент