Criei um trabalho de manutenção do SQL usando o Azure Elastic Job Agent com a seguinte etapa:
EXEC jobs.sp_add_jobstep @job_name = @jobName,
@step_name = 'Optimize indexes and statistics',
@command=N'
EXECUTE dbo.IndexOptimize
@Databases = ''USER_DATABASES'',
@FragmentationLow = NULL,
@FragmentationMedium = ''INDEX_REORGANIZE,INDEX_REBUILD_ONLINE'',
@FragmentationHigh = ''INDEX_REBUILD_ONLINE'',
@FragmentationLevel1 = 10,
@FragmentationLevel2 = 30,
@MinNumberOfPages = 10,
@TimeLimit = 3600,
@UpdateStatistics = ''ALL'',
@OnlyModifiedStatistics = ''Y'',
@SortInTempdb = ''Y'',
@MaxDOP = 1,
@LogToTable = ''Y''
',
@credential_name = @jobStepCredName,
@target_group_name= @targetGroupName,
@retry_attempts = 0,
@step_timeout_seconds = 3600,
@max_parallelism = 1 -- IMPORTANT! We don't want to run index optimization on multiple databases at the same time
O código usa o procedimento armazenado dbo.IndexOptimize fornecido por Ola Hallengren.
O trabalho está programado para ser executado diariamente às 5 da manhã e falha uma ou duas vezes por semana. O motivo da falha é o problema interno do Azure Elastic Job Agent: "Serviço de trabalhos reiniciado enquanto esta tarefa estava em andamento.". O serviço do Azure ainda está em versão prévia, portanto, são esperados erros de serviço internos.
Minha solução atual é definir @retry_attempts como um número maior que 0 para que o Job Agent possa repetir a etapa, mas não tenho certeza se é uma boa ideia tentar novamente uma etapa com falha para otimização de índice.
Em particular, não tenho certeza do que aconteceria com os processos INDEX REBUILD, INDEX REORGANIZE OU UPDATE STATISTICS se eles fossem cancelados ou eliminados.
Então, para resumir, tenho as seguintes perguntas:
- É uma boa ideia tentar novamente a manutenção do índice se a etapa falhar?
- O que acontece quando os processos INDEX REBUILD, INDEX REORGANIZE OU UPDATE STATISTICS falham ou são encerrados.
Agradeço o seu feedback sobre este assunto.
No seu caso, você deve adicionar a opção @Resumable = 'Y' ao seu trabalho e reiniciar ou apenas aguardar o próximo agendamento para executar o trabalho e terminar, dependendo do tempo e dos problemas de simultaneidade, como executar a reconstrução do índice enquanto muitos usuários estão usando o banco de dados pode ser um problema.
As recriações de estatísticas e de índice eram transacionais em versões anteriores, portanto, se uma instrução de reconstrução de índice alter falhou, os resultados foram revertidos e o objeto antigo usado, mas em 2017 em diante, há uma nova opção WITH (RESUMABLE=ON) que permite retomar a reconstrução de índice mais tarde.
Você também deve observar os parâmetros @WaitAtLowPriorityMaxDuration e @LockTimeout nos scripts do Ola, pois eles podem ajudar a minimizar o bloqueio.