Công việc không chạy theo Lịch trình

Vì vậy, tôi có một công việc tác nhân SQL cơ bản chạy tập lệnh Robocopy để di chuyển tất cả các tệp từ thư mục này sang thư mục khác.

Công việc là một thiết lập khá cơ bản.

Với một lịch trình khá cơ bản.

Vậy mà nó vẫn chưa chạy. Tôi không có nghĩa là chạy thành công hoặc tôi có nghĩa là chạy tất cả. Có bất kỳ lý do này có thể là trường hợp?

Để biết thêm thông tin, tôi cũng sẽ viết kịch bản.

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

Bình luận về câu hỏi này: Nhìn qua bài đăng này tôi nhận thấy rằng công việc của bạn ban đầu là "sa". Dường như tài khoản dịch vụ cho Máy chủ SQL của bạn không được trao quyền đối với các chia sẻ tệp cần thiết .

Đây rõ ràng là những gì dẫn đến công việc trông như thể nó đang " Chạy " mãi mãi. Tất nhiên, không có gì thực sự xảy ra.

Đó là cách tốt nhất để giữ lại việc trao quyền tài khoản dịch vụ SQL Server cho bất kỳ thư mục không cần thiết nào . Điều này giúp giữ cho môi trường SQL Server không bị khai thác cho các hoạt động không an toàn. (Nhiều lý do tương tự rằng xp_cmdshellthủ tục lưu trữ bị tắt theo mặc định.)

Khi bạn chuyển từ samột tài khoản có các quyền cần thiết cho hệ thống tệp, mọi thứ đều hoạt động. Tất nhiên đó là điều đúng đắn.

Các công việc Tác nhân SQL được lên lịch đôi khi bị treo (nhưng có vẻ như chúng vẫn đang 'chạy') trong một thời gian dài. Có khả năng điều này thường là do các vấn đề bên ngoài, chẳng hạn như không truy cập được vào hệ thống tệp.

Miễn là Tác nhân SQL tin rằng công việc đang "chạy", nó sẽ không cố gắng bắt đầu lại công việc.

Bài học đơn giản:

1. Hãy nghĩ về 'sa' khi cai trị Máy chủ SQL, nhưng phải xin quyền ở nơi khác.
2. Khi xem xét lịch sử công việc của Tác nhân SQL, hãy cảnh giác với các công việc đã chạy quá lâu. Điều đó thường có nghĩa là Tác nhân SQL không nhận ra rằng quy trình đã chết.
3. Luôn có kế hoạch sử dụng tài khoản proxy cho các công việc của Tác nhân SQL cần truy cập dữ liệu hoặc đối tượng bên ngoài Máy chủ SQL. Và đảm bảo rằng các quyền được cấp cho Thông tin xác thực mà Proxy đang sử dụng.

Và, tất nhiên, mọi quy tắc đều có ngoại lệ.