Início / dba / Perguntas / 230419
Accepted
Rick
Asked: 2019-02-22 11:07:30 +0800 CST

O SQL Server 2017 falha ao fazer backup porque o caminho do arquivo está errado

  • 772

Eu estava tentando restaurar meu banco de dados e o SQL Server continuava travando. Eu receberia uma mensagem no SSMS que dizia que havia um erro de transporte de rede (a conexão caiu devido à falha). Verifiquei os logs e não encontrei nada além do SQL Server fechado inesperadamente. Eu teria então que ir e reiniciar o serviço.

Eu reduzi o problema ao script que a GUI estava tentando executar. O problema é que quando ele vai fazer um backup do tail log, o caminho para os arquivos de backup está errado. Deveria serD:\mapbenefits\...

BACKUP LOG [mapbenefits]
TO  DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT,  NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
    NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

Eu tenho duas perguntas.

  1. Como faço para corrigir esse caminho? Eu tentei entrar nas configurações do servidor e o caminho de backup está D:sem barra. Se eu adicionar a barra, o gui a remove. Este é o SSMS v17.9.1. Eu posso escolher D:\mapbenefits\e isso funciona, mas eu queroD:\DATABASE\...

  2. Isso é um inseto? O servidor SQL deve travar apenas porque um caminho foi digitado incorretamente? Depois de corrigir o caminho do arquivo, não há problemas. Eu posso reproduzir a qualquer momento apenas bagunçando o caminho do arquivo.

Se eu executar uma consulta para verificar a versão, recebo CU13, mas se eu entrar nas configurações, vejo a versão 14.0.1000.169.

Parece que isso é um bug e é reproduzível, então eu postei aqui: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup-log-command- causas

sql-server backup

1 respostas

  1. Best Answer

    Eu consegui reproduzir isso.

    Em 2016, se eu colocar um caminho inválido assim, recebo esta mensagem:

    Não é possível abrir o dispositivo de backup 'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'. Erro do sistema operacional 3(O sistema não pode encontrar o caminho especificado.)

    Em 2017 CU 13 (14.0.3048.4), isso resulta na falha do serviço. Você já mencionou que no hotfix mais recente (14.0.3049.1), o serviço não trava, mas a sessão é encerrada.

    Confirmei que o mesmo comportamento exato se aplica RESTORE DATABASEtambém - passar um caminho como "D:Backups" (com uma barra invertida ausente) ou "D::\Backups" (dois pontos extras) trava a instância do SQL Server (obrigado Michael K Campbell por trazer isso).

    Se eu colocar um caminho "válido" que não existe, recebo o comportamento correto ("não é possível encontrar o caminho especificado") em 2017.

    Este é um bug - tanto no CU 13 quanto na compilação do hotfix. Passar parâmetros incorretos para os comandos BACKUPou RESTOREnão deve travar o serviço ou matar sua sessão. Você pode denunciá-lo no site de comentários .

    Nota: a versão de falha de serviço deste bug pode ser reproduzida em uma versão de visualização pública do SQL Server 2019 (CTP2.2 - obrigado a Denis Rubashkin por apontar isso)

    Olhando para isso em um depurador, parece que o código de validação de caminho está simplesmente quebrado. Ele acaba causando um estouro de pilha ao chamar recursivamente sqlmin!CheckFileStreamReserveddepois que as verificações normais (e bastante extensas) no caminho fornecido não fazem sentido. O estouro de pilha desativa o serviço na compilação 3048. A mesma coisa acontece no 3049, exceto que uma sequência de violações de acesso ao tentar lidar com o estouro de pilha interrompe a conexão em vez de interromper todo o servidor.

    Uma correção para esse bug foi lançada no SQL Server 2017 CU 15:

    CORREÇÃO: o SQL Server 2017 falha devido ao estouro de pilha quando você tenta fazer backup do banco de dados mestre em disco

    O problema também foi resolvido no SQL Server 2019 CTP 3.0.

    • 25

relate perguntas