Oracle DBMS जॉब नहीं चल रहा है

यह पूछे जाने वाले सबसे आम शेड्यूलर प्रश्नों में से एक है। यहां हम कुछ सामान्य समस्याओं और उनके समाधानों को सूचीबद्ध करते हैं।

1) job_queue_processes बहुत कम हो सकता है (यह सबसे आम समस्या है) job_queue_processes का मान dbms_scheduler और dbms_job नौकरियों की कुल संख्या को सीमित करता है जो एक निश्चित समय पर चल सकती हैं। यह जाँचने के लिए कि क्या यह मामला है SQL के साथjob_queue_processes के वर्तमान मूल्य की जाँच करें> v$पैरामीटर से मूल्य का चयन करें जहां नाम ='job_queue_processes'; फिर चल रहे नौकरियों की संख्या की जांच करेंSQL> dba_scheduler_running_jobs से गिनती () का चयन करें; SQL> गिनती चुनें ( ) dba_jobs_running से;

यदि यह समस्या है तो आप SQL> का उपयोग करके पैरामीटर को बढ़ा सकते हैं सिस्टम सेट को बदल सकते हैं job_queue_processes=1000;

2) max_job_slave_processes बहुत कम हो सकता है यदि यह पैरामीटर NULL नहीं है तो यह सीमित करता है कि एक समय में कितने dbms_scheduler कार्य चल सकते हैं। यह जाँचने के लिए कि क्या यह समस्या है, SQL का उपयोग करके वर्तमान मान की जाँच करें> dba_scheduler_global_attributewhere से मान चुनें विशेषता_नाम ='MAX_JOB_SLAVE_PROCESSES'; फिर चल रही नौकरियों की संख्या की जाँच करेंSQL> dba_scheduler_running_jobs से गिनती (*) का चयन करें;

यदि यह समस्या है तो आप संख्या बढ़ा सकते हैं या SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)

3) सत्र बहुत कम हो सकते हैंयह पैरामीटर किसी भी समय सत्रों की संख्या को सीमित करता है। प्रत्येक अनुसूचक कार्य के लिए 2 सत्रों की आवश्यकता होती है। यह जाँचने के लिए कि क्या यह समस्या है, SQL का उपयोग करके वर्तमान मान की जाँच करें> v$पैरामीटर से मान का चयन करें जहाँ name='sessions';फिर SQL का उपयोग करके सत्रों की वर्तमान संख्या की जाँच करें> v$session से गिनती (*) का चयन करें;

यदि संख्याएं बहुत करीब हैं, तो आप SQL का उपयोग करके अधिकतम बढ़ा सकते हैं> सिस्टम सेट को बदलें job_queue_processes=200;

4) क्या आपने हाल ही में टाइमज़ोन अपडेट पैच लागू किया है या डेटाबेस को नए टाइमज़ोन जानकारी वाले संस्करण में अपग्रेड किया है? यदि आपने समय क्षेत्र की जानकारी अपडेट करते समय किसी भी चरण को छोड़ दिया है, तो हो सकता है कि कार्य न चले। यह जाँचने के लिए कि क्या यह मामला है SQL> sys.scheduler$_job;andSQL> से * चुनें * को sys.scheduler$_window से चुनें; और सुनिश्चित करें कि वे त्रुटियों के बिना समाप्त होते हैं।

यदि यह समय क्षेत्र चेतावनी देता है, तो सभी चरणों का पालन करना सुनिश्चित करते हुए अपग्रेड या टाइमज़ोन पैच को फिर से लागू करें।

5) क्या डेटाबेस प्रतिबंधित मोड में चल रहा है? यदि डेटाबेस प्रतिबंधित मोड में चल रहा है तो कोई कार्य नहीं चलेगा (जब तक कि आप 11g का उपयोग नहीं कर रहे हैं और ALLOW_RUNS_IN_RESTRICTED_MODE विशेषता का उपयोग नहीं कर रहे हैं)। इस उपयोग की जांच करने के लिएSQL> v$instance से लॉगिन का चयन करें;

यदि लॉगिन प्रतिबंधित है तो आप SQL> ALTER SYSTEM DISABLE प्रतिबंधित सत्र का उपयोग करके प्रतिबंधित मोड को अक्षम कर सकते हैं;

6) क्या कार्य एक ऐसे उदाहरण पर चलने के लिए निर्धारित है जो बंद है?

आप यह देख कर देख सकते हैं कि क्या इंस्टेंस_आईडी कार्य के लिए सेट है (dba_scheduler_jobs दृश्य देखें), और यदि ऐसा है तो आपको जांचना चाहिए कि क्या इंस्टेंस चालू है।

7) क्या नौकरी ऐसी सेवा पर चलने के लिए निर्धारित है जो किसी भी समय शुरू नहीं हुई है?

आप यह जांच कर सकते हैं कि जॉब_क्लास किस जॉब की ओर इशारा करता है और फिर यह जांच कर कि वह क्लास किसी सर्विस की ओर इशारा करता है या नहीं। यदि ऐसा होता है, तो सुनिश्चित करें कि सेवा कम से कम एक चल रहे उदाहरण पर शुरू की गई है। आप dbms_service.start_service का उपयोग करके एक उदाहरण पर एक सेवा शुरू कर सकते हैं।

8) क्या संसाधन प्रबंधक प्रतिबंधात्मक संसाधन योजना के प्रभाव में है?

यदि कोई प्रतिबंधात्मक संसाधन योजना प्रभावी है, तो हो सकता है कि अनुसूचक कार्यों में पर्याप्त संसाधन आवंटित न हों, इसलिए वे चल नहीं सकते। आप यह जाँच कर सकते हैं कि कौन सी संसाधन योजना प्रभावी है

SQL> V$RSRC_PLAN से नाम चुनें;

यदि कोई योजना प्रभाव में नहीं है या प्रभावी योजना INTERNAL_PLAN है तो संसाधन प्रबंधक प्रभाव में नहीं है। यदि संसाधन प्रबंधक प्रभाव में है तो आप इसे कर कर अक्षम कर सकते हैं

SQL>अल्टर सिस्टम सेट रिसोर्स_मैनेजर_प्लान ='';

9) क्या अनुसूचक अक्षम कर दिया गया है? यह समर्थित कार्रवाई नहीं है, लेकिन यह संभव है कि किसी ने इसे वैसे भी किया हो। इसे जांचने के लिए doSQL> dba_scheduler_global_attribute से मान चुनें जहां विशेषता_नाम ='SCHEDULER_DISABLED'

यदि यह क्वेरी TRUE लौटाती है, तो आप इसे SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

कार्य देर से चलने के कारण

1) जांच करने वाली पहली चीज यह है कि कार्य एसक्यूएल के साथ निर्धारित है> dba_scheduler_jobs से मालिक, job_name, next_run_date चुनें;

यदि कार्य गलत समय क्षेत्र में हैं तो वे अपेक्षित समय पर नहीं चल सकते हैं। अगर next_run_date नामित टाइमज़ोन (जैसे यूएस/पैसिफिक) के बजाय एक पूर्ण टाइमज़ोन ऑफ़सेट (जैसे + 08:00) का उपयोग कर रहा है, तो डेलाइट सेविंग प्रभावी होने पर नौकरियां अपेक्षित रूप से नहीं चल सकती हैं - वे एक घंटे या देर से चल सकती हैं।

2) यह हो सकता है कि जिस समय नौकरी को चलाने के लिए निर्धारित किया गया था, ऊपर की कई सीमाओं में से एक अस्थायी रूप से काम में देरी के कारण पहुंच गई हो सकती है। जांचें कि क्या ऊपर की सीमाएं काफी अधिक हैं और यदि संभव हो तो उन्हें समय के दौरान जांचें कि काम में देरी हो रही है।

3) उपरोक्त सीमाओं में से एक के प्रभावित होने का एक संभावित कारण यह है कि रखरखाव खिड़की प्रभावी हो सकती है। रखरखाव विंडो OracleScheduler विंडो हैं जो MAINTENANCE_WINDOW_GROUP नामक विंडो समूह से संबंधित हैं। शेड्यूल्ड रखरखाव विंडो के दौरान, जॉब का उपयोग करके कई रखरखाव कार्य चलाए जाते हैं। इससे ऊपर सूचीबद्ध सीमाओं में से कोई एक प्रभावित हो सकती है और उपयोगकर्ता कार्य में देरी हो सकती है। इस बारे में अधिक जानकारी के लिए व्यवस्थापक मार्गदर्शिका देखें (अध्याय 24)।

रखरखाव विंडो की सूची प्राप्त करने के लिए SQL का उपयोग करें> dba_scheduler_wingroup_members से * चुनें;

यह देखने के लिए कि विंडोज़ कब चलती है SQL> dba_scheduler_windows से * चुनें;

इसे ठीक करने के लिए आप या तो सीमा बढ़ा सकते हैं या रखरखाव विंडो को अधिक सुविधाजनक समय पर चलाने के लिए पुनर्निर्धारित कर सकते हैं।

अन्य समस्याओं का निदान

यदि इनमें से कोई भी काम नहीं करता है, तो यह पता लगाने के लिए कि क्या हो रहा है, यहां कुछ और कदम उठाए जा सकते हैं।

1) जांचें कि क्या अलर्ट लॉग में कोई त्रुटि है। यदि डेटाबेस को स्मृति आवंटित करने में समस्या हो रही है या डिस्क स्थान समाप्त हो गया है या कोई अन्य विनाशकारी त्रुटि हुई है, तो आपको पहले उन्हें हल करना चाहिए। आप एसक्यूएल> v$पैरामीटर से मूल्य का चयन करके अलर्ट लॉग का स्थान ढूंढ सकते हैं जहां नाम ='background_dump_dest'; अलर्ट लॉग इस निर्देशिका में "अलर्ट" से शुरू होने वाले नाम के साथ होगा।

2) जांचें कि क्या कोई नौकरी समन्वयक फ़ाइल का पता लगाता है और यदि ऐसा होता है, तो जांचें कि इसमें कोई त्रुटि है या नहीं। यदि यह मौजूद है, तो यह 'background_dump_dest' निर्देशिका में स्थित होगा जिसे आप ऊपर के रूप में पा सकते हैं और SID-cjq0_nnnn.trc जैसा कुछ दिखाई देगा। अगर यहां कोई त्रुटि है तो वे संकेत दे सकते हैं कि नौकरियां क्यों नहीं चल रही हैं।

3) यदि उपरोक्त में से कोई भी इंगित करता है कि SYSAUX टेबलस्पेस (जहां शेड्यूलर अपनी लॉगिंग टेबल संग्रहीत करता है) भरा हुआ है, तो आप पुरानी लॉग प्रविष्टियों को साफ़ करने के लिए dbms_scheduler.purge_log प्रक्रिया का उपयोग कर सकते हैं।

4) देखें कि क्या वर्तमान में कोई विंडो खुली है। अगर वहाँ है, तो आप इसे बंद करके देख सकते हैं कि क्या इससे मदद मिलती है।

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');

5) एक साधारण रन-वन जॉब चलाने का प्रयास करें और देखें कि क्या यह चलता है

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) यदि एक साधारण रन-वन जॉब नहीं चलता है, तो आप निम्नानुसार शेड्यूलर को पुनरारंभ करने का प्रयास कर सकते हैं।

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');