Por que estou recebendo “RESTORE DATABASE TERMINTED ABNORMALLY” (Erro 3013) ao restaurar do Armazenamento de Blobs do Azure para o SQL Server 2014?

3

Nosso servidor de banco de dados de produção está fazendo backup de seus bancos de dados todas as noites para o Armazenamento de Blobs do Azure, usando o comando BACKUP TO URL no SQL Server 2014 Standard. Agora estou tentando restaurar esses backups para uma nova VM do SQL Server que configuramos no Azure, que também está executando o SQL Server 2014 Standard. Estou executando o seguinte comando 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;

Quando faço isso, a restauração é executada por mais de 10 minutos, e posso ver isso progredindo na janela "Mensagens" do SQL Server Management Studio. No entanto, antes de chegar a 100% concluído, a seguinte mensagem de erro é exibida.

Saída na VM do Azure executando o Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64 bits) no Windows NT 6.3 (Build 9600:) (Hypervisor):

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

Pesquisando "Erro do SQL Server 3013" ou "Banco de dados de restauração do SQL Server sendo encerrado de forma anormal" produz muitas páginas sugerindo que meu arquivo de banco de dados está corrompido. No entanto, eu não acho que é, porque eu posso executar exatamente o mesmo SQL no meu laptop executando o SQL Server 2014 Express, e recebo a seguinte saída:

Saída no laptop executando o Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Express Edition (64 bits) no Windows NT 6.3 (compilação 10240:) (hipervisor):

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).

Ambas as instruções de restauração foram executadas exatamente na mesma URL, com o mesmo arquivo de backup inalterado. Se ele for restaurado corretamente na minha cópia local do SQL Server Express, ele não poderá estar corrompido, certo?

Aqui estão algumas outras possíveis causas que tentei excluir:

  • Incompatibilidade de versão - O backup foi executado em um servidor que executa o Microsoft SQL Server 2014 - 12.0.2269.0 (X64) Standard Edition (64 bits). A restauração foi executada em um servidor que executa o Microsoft SQL Server 2014 - 12.0.4213.0 (X64) Standard Edition (64 bits). Esses números de versão foram determinados executando SELECT @@VERSION em cada um dos servidores.
  • Erros de perimssions - Ambos, RESTORE HEADERONLY e RESTORE FILELISTONLY , funcionam corretamente na VM do Azure que não restaurará o banco de dados.
  • Espaço livre - A unidade C: na VM do Azure tem mais de 80 GB livres.
  • Conectividade de rede - Eu não fiz nenhum teste abrangente, mas como a VM que executa o SQL Server está sendo executada no Azure, e o arquivo de backup também está no Azure, imagino que seja bastante estável. Downloads de arquivos e testes simples com o navegador parecem indicar que a conexão é estável e rápida.

O banco de dados em questão é de cerca de 2 GB quando restaurado, com um arquivo de log de 5 GB. Tenho outros backups do mesmo banco de dados armazenados no Azure e obtenho os mesmos resultados ao tentar restaurar qualquer um deles (funciona no SQL Server Express 2014 local, falha no VMware SQL Server Standard 2014 do Azure).

Alguma idéia do que pode estar causando isso e como corrigi-lo?

    
por Joshua Carmody 15.10.2015 / 21:20

0 respostas