Estou usando o script de manutenção de Ola Hallengren e estou tendo um problema que parece documentado no FAQ.
Para contextualizar, havia um problema em que os backups existentes do SQL Server precisavam ser movidos para um novo compartilhamento e, portanto, o histórico no MSDB e o local atual dos novos backups não correspondiam ao que existe agora.
Ao executar o trabalho padrão que MaintenanceSolution.sql cria, "DatabaseBackup - USER_DATABASES - FULL" (com pequenas modificações nos parâmetros em que é executado), vejo que o trabalho agora falha porque parece que a exclusão dos arquivos esperados existiria:
EXECUTE @ReturnCode = [master].dbo.xp_delete_file 0, N'\\UNC\Path\Server\Database... Process Exit Code 1. The step failed.
Após o primeiro erro desse tipo, todo o trabalho é interrompido.
No FAQ https://ola.hallengren.com/frequently-asked-questions.html , encontrei o seguinte parágrafo que aborda o problema que acredito estar tendo:
Por que meu trabalho para após o primeiro erro?
Esse problema está acontecendo porque você está usando etapas de trabalho T-SQL. Eu recomendo que você use as etapas de trabalho CmdExec com sqlcmd e a opção -b. Em seguida, o trabalho continuará após um erro.
Você pode usar o script MaintenanceSolution.sql para criar as tarefas.
Verifiquei duas vezes (porque achei que esse era o padrão que a solução configurou) e com base no que vejo no SSMS é (Tipo: Sistema operacional (CmdExec)) e descobri que era esse o caso.
Também verifiquei que o trabalho também está usando a opção -b:
sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'USER_DATABASES', @Directory = N'\\UNC\Path\', @BackupType = 'FULL', @Verify = 'N', @CleanupTime = 750 , @CheckSum = 'Y', @LogToTable = 'Y'" -b
Eu estava executando rapidamente o procedimento armazenado e descobri que ele simplesmente atribui qualquer erro do comando xp_delete a uma variável e o gera como um erro (sql padrão completamente bog), então falta alguma coisa para fazer isso funcionar sem modificar sua solução?
Obrigado!
Depois de pesquisar mais (e quase enviar um e-mail para Ola), descobri a fonte da minha confusão.
Depois de consultar a tabela CommandLog (@LogToTable = 'Y'), descobri que, embora as etapas do trabalho TSQL relatassem o erro , o trabalho realmente foi concluído, registrou os comandos na tabela como bem-sucedidos (e, claro, os arquivos existiam no disco).
Parece que não apenas as etapas de trabalho do TSQL param de relatar no primeiro erro, que é referenciado em uma parte diferente do FAQ.
Se você estiver vendo que o histórico do SQL Server Agent relata um trabalho com falha, verifique se a mesma falha é relatada na tabela master.dbo.CommandLog e certifique-se de ter @LogToTable = 'Y' especificado.
O trabalho de Ola está se comportando conforme descrito no FAQ, e a referência às etapas do trabalho TSQL foi a dica de que eu precisava.