Lavoro non in esecuzione su Pianificazione

Quindi ho un lavoro di agente SQL di base che esegue uno script Robocopy per spostare tutti i file da una cartella all'altra.

Job è una configurazione piuttosto semplice.

Con un programma piuttosto semplice.

Eppure deve ancora correre. Non intendo correre con successo né intendo correre affatto. C'è qualche motivo per cui questo potrebbe essere il caso?

Per ulteriori informazioni scriverò anche il lavoro.

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

Commento su questa domanda: guardando questo post, osservo che il tuo lavoro inizialmente era in esecuzione come 'sa'. Sembra che all'account del servizio per SQL Server non siano stati concessi i diritti per le condivisioni di file necessarie .

Questo è apparentemente ciò che ha portato il lavoro a sembrare "in esecuzione " per sempre. Certo, non stava succedendo nulla.

Si tratta di una pratica migliore di trattenere dare i diritti di account di servizio di SQL Server per eventuali cartelle non essenziali . Ciò consente di evitare che l'ambiente SQL Server venga sfruttato per attività non sicure. (Più o meno lo stesso motivo per cui la xp_cmdshellprocedura memorizzata è disabilitata per impostazione predefinita.)

Quando sei passato da saun account che aveva i diritti necessari per il file system, tutto ha funzionato. Qual è stata, ovviamente, la cosa giusta da fare.

I processi di SQL Agent pianificati a volte si bloccano (ma sembrano essere ancora in esecuzione) per molto tempo. Probabilmente ciò è dovuto in genere a problemi esterni, come il mancato accesso al file system.

Finché SQL Agent ritiene che il processo sia "in esecuzione", non tenterà di riavviare il processo.

Lezioni semplici:

1. Pensa a "sa" come a governare SQL Server, ma deve chiedere diritti altrove.
2. Quando si esamina la cronologia dei lavori di SQL Agent, fare attenzione ai lavori in esecuzione da troppo tempo. Questo di solito significa che SQL Agent non si rende conto che il processo è morto.
3. Pianificare sempre di utilizzare un account proxy per i processi di SQL Agent che devono accedere a dati o oggetti all'esterno di SQL Server. E assicurarsi che i diritti siano concessi alle credenziali utilizzate dal proxy.

E, naturalmente, ogni regola ha delle eccezioni.