Job läuft nicht nach Zeitplan

Ich habe also einen einfachen SQL-Agentenjob, der ein Robocopy-Skript ausführt, um alle Dateien von einem Ordner in einen anderen zu verschieben.

Job ist eine ziemlich einfache Einrichtung.

Mit einem ziemlich einfachen Zeitplan.

Und doch muss es noch laufen. Ich meine auch nicht erfolgreich laufen, ich meine überhaupt laufen. Gibt es einen Grund, warum dies der Fall sein könnte?

Für zusätzliche Informationen werde ich den Job auch ausschreiben.

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

Kommentar zu dieser Frage: Wenn ich mir diesen Beitrag ansehe, stelle ich fest, dass Ihr Job ursprünglich als "sa" ausgeführt wurde. Es scheint, dass dem Dienstkonto für Ihren SQL Server keine Rechte für die erforderlichen Dateifreigaben erteilt wurden .

Dies hat anscheinend dazu geführt, dass der Job so aussah, als würde er für immer " laufen ". Natürlich passierte eigentlich nichts.

Es ist ein Best Practice , die SQL Server - Dienstkonto Rechte an einzubehalten gibt nicht wesentliche Ordner . Dies verhindert, dass die SQL Server-Umgebung für unsichere Aktivitäten ausgenutzt wird. (Ähnlich wie die xp_cmdshellgespeicherte Prozedur standardmäßig deaktiviert ist.)

Wenn Sie von saeinem Konto mit den erforderlichen Rechten für das Dateisystem gewechselt sind , hat alles funktioniert. Das war natürlich das Richtige.

Geplante SQL Agent-Jobs hängen manchmal lange (aber es sieht so aus, als würden sie noch ausgeführt). Wahrscheinlich liegt dies normalerweise an externen Problemen, z. B. daran, dass kein Zugriff auf das Dateisystem möglich ist.

Solange der SQL Agent glaubt, dass der Job "ausgeführt" wird, wird er nicht versuchen, den Job erneut zu starten.

Einfache Lektionen:

1. Stellen Sie sich 'sa' als Regel für den SQL Server vor, müssen Sie jedoch an anderer Stelle um Rechte bitten.
2. Achten Sie beim Überprüfen des SQL Agent-Auftragsverlaufs auf Aufträge, die viel zu lange ausgeführt wurden. Dies bedeutet normalerweise, dass der SQL Agent nicht erkennt, dass der Prozess beendet ist.
3. Planen Sie immer die Verwendung eines Proxy-Kontos für SQL Agent-Jobs, die auf Daten oder Objekte außerhalb von SQL Server zugreifen müssen. Stellen Sie sicher, dass die Rechte für den vom Proxy verwendeten Berechtigungsnachweis gewährt werden.

Und natürlich hat jede Regel Ausnahmen.