Início / dba / Perguntas / 276609
Accepted
Metaphor
Asked: 2020-10-07 04:53:29 +0800 CST

sp_update_schedule diz que @schedule_id não existe

  • 772

Eu escrevi um script que lê agendas de trabalho msdb.dbo.sysschedulese executa sp_update_schedulepara alterar o active_start_timepara um determinado subconjunto de trabalhos. Em cada caso, sp_update_schedulefalha com a mensagem "O @schedule_id('xxx') especificado não existe". (ID da mensagem 14262, gravidade 16)

O schedule idin sysschedulesnão é o que está procurando? O que estou perdendo aqui?

sql-server sql-server-agent

1 respostas

  1. Best Answer

    O @schedule_idparâmetro on sp_update_schedulese refere à schedule_idcoluna emmsdb.dbo.sysschedules

    sp_update_schedulecontém uma chamada para sp_verify_schedule_identifierspara validar o agendamento, e é a partir dessa etapa de verificação que você está recebendo esse erro (mensagem 14262).

    EXECUTE @retval = msdb.dbo.sp_verify_schedule_identifiers 
          @name_of_name_parameter = '@name',  
          @name_of_id_parameter   = '@schedule_id',  
          @schedule_name          = @name             OUTPUT,  
          @schedule_id            = @schedule_id      OUTPUT,  
          @owner_sid              = @cur_owner_sid    OUTPUT,  
          @orig_server_id         = NULL

    Se você estiver passando um ID de agendamento e um nome de agendamento, pode haver um problema na string que você está passando para o nome, pois ela é usada para filtragem adicional no procedimento de verificação.

    Sugiro fazer alguns testes com chamadas diretamente para sp_verify_schedule_identifierspara que você possa simplificar sua solução de problemas e verifique se está passando parâmetros válidos para sp_update_schedule:

    DECLARE  
  @name_of_name_parameter   VARCHAR(60) ,--= '@schedule_name',
  @name_of_id_parameter     VARCHAR(60) = '@schedule_id',
  @schedule_name            sysname     ,--= 'syspolicy_purge_history_schedule',  
  @schedule_id              INT         = 8,  
  @owner_sid                VARBINARY(85),  
  @orig_server_id           INT,  
  @job_id_filter            UNIQUEIDENTIFIER    = NULL,
  @RetCode                  INT;

EXEC @RetCode = sp_verify_schedule_identifiers 
  @name_of_name_parameter    = @name_of_name_parameter,
  @name_of_id_parameter      = @name_of_id_parameter,  
  @schedule_name             = @schedule_name,    
  @schedule_id               = @schedule_id,           
  @owner_sid                 = @owner_sid,             
  @orig_server_id            = @orig_server_id,
  @job_id_filter             = @job_id_filter;

SELECT  
   RetCode              = @RetCode,
   NameOfNameParam      = @name_of_name_parameter, 
   NameOfIdParam        = @name_of_id_parameter,  
   ScheduleName         = @schedule_name,    
   ScheduleID           = @schedule_id,
   OwnerSid             = @owner_sid,
   OrigServerID         = @orig_server_id,
   JobIDFilter          = @job_id_filter;

    As permissões também podem estar atrapalhando. Você precisaria, no mínimo, GRANT EXEC ON sp_update_schedule TO <your login>para fazer a chamada que está tentando fazer. EXECPara executar a etapa de solução de problemas que listei acima, você também precisaria receber sp_verify_schedule_identifiers-- embora você só precise disso se executá-lo diretamente. Normalmente, o encadeamento de propriedade permitiria que você precisasse apenas da permissão de nível superior e você teria implicitamente a permissão para fazer o que esse procedimento faz. Você também pode ser adicionado à SQLAgentUserRolefunção de segurança no msdb, que inclui outras permissões também - se estiver reagendando trabalhos, também poderá precisar/querer algumas dessas outras permissões para realizar seu trabalho, supondo que este seja um nível aceitável de acesso.

    • 2

relate perguntas