Início / dba / Perguntas / 124466
Accepted
Zane
Asked: 2015-12-24 08:28:16 +0800 CST

O trabalho não está sendo executado na programação

  • 772

Portanto, tenho um trabalho básico de agente SQL que executa um script Robocopy para mover todos os arquivos de uma pasta para outra.

Job é uma configuração bastante básica. Habilitado

Com uma programação bem básica.

Cronograma

E, no entanto, ainda não foi executado. Não quero dizer executar com sucesso, quero dizer executar. Existe alguma razão para este ser o caso?

Para obter informações adicionais, também criarei o script do trabalho.

USE [msdb]
GO

/****** Object:  Job [MoveMantisFilesToArchive]    Script Date: 12/23/2015 10:21:52 AM ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object:  JobCategory [[Uncategorized (Local)]]]    Script Date: 12/23/2015 10:21:52 AM ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'MoveMantisFilesToArchive', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=2, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'Moves Mantis files to archive. It''s a very descriptive title.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'sa', 
        @notify_email_operator_name=N'MyEmailGroup', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
/****** Object:  Step [Move the files in the afformentioned title.]    Script Date: 12/23/2015 10:21:53 AM ******/
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Move the files in the afformentioned title.', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'CmdExec', 
        @command=N'robocopy MySoruce MyDestination /mov', 
        @flags=0, 
        @proxy_name=N'RunsAs'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'M-F', 
        @enabled=1, 
        @freq_type=8, 
        @freq_interval=62, 
        @freq_subday_type=1, 
        @freq_subday_interval=0, 
        @freq_relative_interval=0, 
        @freq_recurrence_factor=1, 
        @active_start_date=20151218, 
        @active_end_date=99991231, 
        @active_start_time=170000, 
        @active_end_time=235959, 
        @schedule_uid=N'bcb83273-19e8-49fb-a456-8517642370e3'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

GO
sql-server sql-server-2012

1 respostas

  1. Best Answer

    Comentário sobre esta questão: Examinando esta postagem, observo que seu trabalho estava sendo executado originalmente como 'sa'. Parece que a conta de serviço do seu SQL Server não recebeu direitos para os compartilhamentos de arquivos necessários .

    Aparentemente, foi isso que fez com que o trabalho parecesse "em execução " para sempre. Claro, nada estava realmente acontecendo.

    É uma prática recomendada não conceder à conta de serviço do SQL Server direitos a quaisquer pastas não essenciais . Isso ajuda a impedir que o ambiente do SQL Server seja explorado para atividades inseguras. (Praticamente o mesmo motivo pelo qual o xp_cmdshellprocedimento armazenado é desativado por padrão.)

    Quando você mudou sapara uma conta que tinha os direitos necessários para o sistema de arquivos, tudo funcionou. O que era, claro, a coisa certa a fazer.

    Às vezes, os trabalhos agendados do SQL Agent travam (mas parecem que ainda estão 'em execução') por muito tempo. Provavelmente, isso geralmente ocorre devido a problemas externos, como não obter acesso ao sistema de arquivos.

    Enquanto o SQL Agent acreditar que o trabalho está "em execução", ele não tentará iniciá-lo novamente.

    Lições simples:

    1. Pense em 'sa' como governando o SQL Server, mas deve implorar por direitos em outro lugar.
    2. Ao revisar o histórico de tarefas do SQL Agent, fique atento às tarefas que estão em execução há muito tempo. Isso geralmente significa que o SQL Agent não percebe que o processo foi encerrado.
    3. Sempre planeje usar uma conta proxy para trabalhos do SQL Agent que precisam acessar dados ou objetos fora do SQL Server. E certifique-se de que os direitos sejam concedidos à credencial que o proxy está usando.

    E, claro, toda regra tem exceções.

    • 5

relate perguntas