Đây là một trong những câu hỏi phổ biến nhất của Trình lập lịch biểu được hỏi. Dưới đây chúng tôi liệt kê một số sự cố thường gặp và giải pháp của chúng.
1) job_queue_processes có thể quá thấp (đây là vấn đề phổ biến nhất) Giá trị của job_queue_processes giới hạn tổng số dbms_schedulerand dbms_job job có thể chạy tại một thời điểm nhất định. chọn giá trị từ tham số v $ trong đó name ='job_queue_processes'; Sau đó kiểm tra số lượng jobSQL đang chạy> chọn count () từ dba_scheduler_running_jobs; SQL> select count ( ) từ dba_jobs_running;
Nếu đây là sự cố, bạn có thể tăng tham số bằng cách sử dụngSQL> thay đổi bộ hệ thống job_queue_processes =1000;
2) max_job_slave_processes có thể quá thấp Nếu tham số này không phải là NULL thì nó sẽ giới hạn số lượng công việc dbms_scheduler có thể chạy tại một thời điểm. Để kiểm tra xem đây có phải là sự cố hay không, hãy kiểm tra giá trị hiện tại bằng cách sử dụngSQL> chọn giá trị từ dba_scheduler_global_attributewhere thuộc tính_name ='MAX_JOB_SLAVE_PROCESSES'; Sau đó, kiểm tra số lượng công việc đang chạySQL> chọn số lượng (*) từ dba_scheduler_running_jobs;
Nếu đây là vấn đề, bạn có thể tăng số lượng hoặc chỉ NULL bằng cách sử dụngSQL> execute dbms_scheduler.set_scheduler_attribute ('max_job_slave_processes', null)
3) phiên có thể quá thấp Tham số này giới hạn số phiên bất kỳ lúc nào. Mỗi công việc của Trình lập lịch yêu cầu 2 phiên. Để kiểm tra xem đây có phải là sự cố hay không, hãy kiểm tra giá trị hiện tại bằng cách sử dụngSQL> chọn giá trị từ tham số v $ trong đó name ='phiên'; Sau đó kiểm tra số phiên hiện tại bằng cách sử dụngSQL> chọn số lượng (*) từ v $ phiên;
Nếu các con số quá gần nhau, bạn có thể tăng tối đa bằng cách sử dụngSQL> thay đổi bộ hệ thống job_queue_processes =200;
4) Gần đây, bạn có áp dụng bản vá cập nhật múi giờ hoặc nâng cấp tập dữ liệu lên phiên bản với thông tin múi giờ mới hơn không? Nếu bạn bỏ qua bất kỳ bước nào khi cập nhật thông tin múi giờ, công việc có thể không chạy. Để kiểm tra xem có phải trường hợp này hay không, hãy thử doingSQL> select * from sys.scheduler $ _job; andSQL> select * from sys.scheduler $ _window; và đảm bảo rằng chúng hoàn thành mà không có lỗi.
Nếu nó đưa ra cảnh báo múi giờ, hãy áp dụng lại bản vá nâng cấp hoặc múi giờ, đảm bảo làm theo tất cả các bước.
5) Cơ sở dữ liệu có đang chạy ở chế độ hạn chế không? Nếu cơ sở dữ liệu đang chạy ở chế độ hạn chế thì sẽ không có công việc nào chạy (trừ khi bạn đang sử dụng 11g và sử dụng thuộc tính ALLOW_RUNS_IN_RESTRICTED_MODE) .Để kiểm tra useSQL này> chọn thông tin đăng nhập từ v $ instance;
Nếu thông tin đăng nhập bị hạn chế, bạn có thể tắt chế độ hạn chế bằng cách sử dụngSQL> ALTER SYSTEM HẠN CHẾ HẠN CHẾ HẠN CHẾ;
6) Công việc có được lên lịch chạy trên một phiên bản bị lỗi không?
Bạn có thể kiểm tra điều này bằng cách xem liệu instance_id có được đặt cho công việc hay không (kiểm tra chế độ xem dba_scheduler_jobs), và nếu có, bạn nên kiểm tra xem phiên bản đó đã hoạt động chưa.
7) Công việc có được lên lịch chạy trên một dịch vụ chưa được bắt đầu trên bất kỳ trường hợp nào không?
Bạn có thể kiểm tra điều này bằng cách kiểm tra job_class mà một job trỏ đến và sau đó kiểm tra xem class đó có trỏ đến một dịch vụ hay không. Nếu có, hãy đảm bảo rằng dịch vụ đã được khởi động trên ít nhất một phiên bản đang chạy. Bạn có thể bắt đầu một dịch vụ trên một phiên bản bằng dbms_service.start_service.
8) Trình quản lý tài nguyên có hiệu lực với một kế hoạch tài nguyên hạn chế không?
Nếu một kế hoạch tài nguyên hạn chế đang có hiệu lực, các công việc của bộ lập lịch có thể không có đủ tài nguyên được phân bổ để chúng có thể không chạy. Bạn có thể kiểm tra xem kế hoạch tài nguyên nào đang có hiệu lực bằng cách thực hiện
SQL> chọn tên từ V $ RSRC_PLAN;
Nếu không có kế hoạch nào có hiệu lực hoặc kế hoạch có hiệu lực là INTERNAL_PLAN thì trình quản lý tài nguyên không có hiệu lực. Nếu trình quản lý tài nguyên đang có hiệu lực, bạn có thể tắt nó bằng cách thực hiện
SQL> thay đổi tập hợp hệ thống resource_manager_plan ='';
9) Bộ lập lịch đã bị vô hiệu hóa chưa? Đây không phải là một hành động được hỗ trợ nhưng có thể ai đó đã thực hiện nó. Để kiểm tra doSQL này> hãy chọn giá trị từ dba_scheduler_global_attribute trong đó thuộc tính_name ='SCHEDULER_DISABLED'
Nếu truy vấn này trả về TRUE thì bạn có thể sửa lỗi này bằng cách sử dụngSQL> execute dbms_scheduler.set_scheduler_attribute ('Scheduler_disabled', 'false');
Lý do khiến công việc có thể bị trễ
1) Điều đầu tiên cần kiểm tra là múi giờ mà công việc được lên lịch vớiSQL> chọn chủ sở hữu, job_name, next_run_date from dba_scheduler_jobs;
Nếu công việc không đúng múi giờ, chúng có thể không chạy đúng thời gian dự kiến. Nếu next_run_date đang sử dụng độ lệch múi giờ tuyệt đối (như + 08:00) thay vì múi giờ đã đặt tên (như US / PACIFIC) thì công việc có thể không chạy như mong đợi nếu chế độ tiết kiệm ánh sáng ban ngày có hiệu lực - chúng có thể chạy nhanh hoặc muộn.
2) Có thể tại thời điểm công việc đã được lên lịch chạy, một trong các mức giới hạn trên có thể đã tạm thời đạt đến khiến công việc bị trì hoãn. công việc đang bị trì hoãn.
3) Một lý do có thể xảy ra mà một trong các giới hạn trên có thể bị ảnh hưởng là cửa sổ bảo trì có thể đã có hiệu lực. Các cửa sổ bảo trì là các cửa sổ OracleScheduler thuộc nhóm cửa sổ có tênMAINTENANCE_WINDOW_GROUP. Trong một cửa sổ bảo trì theo lịch trình, một số tác vụ bảo trì được chạy bằng các công việc. Điều này có thể khiến một trong những giới hạn được liệt kê ở trên bị ảnh hưởng và công việc của người dùng bị trì hoãn. Xem hướng dẫn quản trị để biết thêm thông tin về phần này (chương 24).
Để lấy danh sách các cửa sổ bảo trì, hãy sử dụng useSQL> hãy chọn * từ dba_scheduler_wingroup_members;
Để xem khi nào cửa sổ chạy useSQL> hãy chọn * từ dba_scheduler_windows;
Để khắc phục điều này, bạn có thể tăng giới hạn hoặc lên lịch lại các luồng bảo trì để chạy vào những thời điểm thuận tiện hơn.
Chẩn đoán các vấn đề khác
Nếu không có cách nào trong số này hoạt động, đây là một số bước tiếp theo mà bạn có thể thực hiện để cố gắng tìm hiểu xem điều gì đang xảy ra.
1) Kiểm tra xem có bất kỳ lỗi nào trong nhật ký cảnh báo hay không. Nếu cơ sở dữ liệu đang gặp sự cố cấp phát bộ nhớ hoặc đã hết dung lượng đĩa hoặc bất kỳ lỗi nghiêm trọng nào khác đã xảy ra, bạn nên giải quyết những lỗi đó trước. Bạn có thể tìm vị trí của nhật ký cảnh báo bằng cách sử dụngSQL> chọn giá trị từ tham số v $ trong đó name ='background_dump_dest'; Nhật ký cảnh báo sẽ nằm trong thư mục này với tên bắt đầu bằng "alert".
2) Kiểm tra xem liệu một tập tin theo dõi điều phối viên công việc có và nếu có, hãy kiểm tra xem nó có chứa bất kỳ lỗi nào không. Nếu điều này tồn tại, nó sẽ nằm trong thư mục'background_dump_dest 'mà bạn có thể tìm thấy như trên và sẽ trông giống như SID-cjq0_nnnn.trc. Nếu có bất kỳ lỗi nào ở đây, họ có thể hiểu tại sao công việc không chạy.
3) Nếu một trong hai điều trên chỉ ra rằng vùng bảng SYSAUX (nơi bộ lập lịch lưu trữ các bảng ghi nhật ký của nó) đã đầy, bạn có thể sử dụng thủ tục dbms_scheduler.purge_log để xóa các mục nhật ký cũ.
4) Xem có cửa sổ nào hiện đang mở không. Nếu có, bạn có thể thử đóng nó lại xem có hữu ích không.
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5) thử chạy một công việc đơn giản chạy một lần và xem nó có chạy không
SQL>begin
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
end;
/
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';
6) Nếu công việc chạy một lần đơn giản không chạy, bạn có thể thử khởi động lại bộ lập lịch như sau.
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL>
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL>
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');
