Dit is een van de meest gestelde vragen over Planner. Hier geven we een overzicht van enkele veelvoorkomende problemen en hun oplossingen.
1) job_queue_processes kan te laag zijn (dit is het meest voorkomende probleem) De waarde van job_queue_processes beperkt het totale aantal dbms_schedule en dbms_job jobs dat op een bepaald moment kan worden uitgevoerd. Om te controleren of dit het geval is, controleert u de huidige waarde van job_queue_processes met SQL> selecteer waarde uit v$parameter waarbij name='job_queue_processes';Controleer vervolgens het aantal actieve jobsSQL> selecteer telling() van dba_scheduler_running_jobs;SQL> selecteer telling( ) van dba_jobs_running;
Als dit het probleem is, kunt u de parameter verhogen met SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes kan te laag zijn. Als deze parameter niet NULL is, beperkt het hoeveel dbms_scheduler-taken tegelijkertijd kunnen worden uitgevoerd. Om te controleren of dit het probleem is, controleert u de huidige waarde met SQL> select value from dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES';Controleer vervolgens het aantal actieve jobsSQL> select count(*) van dba_scheduler_running_jobs;
Als dit het probleem is, kunt u het aantal verhogen of het gewoon NULLEN met SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) sessies kunnen te laag zijn. Deze parameter beperkt het aantal sessies op elk moment. Elke Scheduler-taak vereist 2 sessies. Om te controleren of dit het probleem is, controleert u de huidige waarde met behulp vanSQL> selecteer waarde van v$parameter waar name='sessions';Controleer vervolgens het huidige aantal sessies met behulp vanSQL> selecteer telling(*) van v$session;
Als de getallen te dicht bij elkaar liggen, kunt u het maximum verhogen met SQL> alter system set job_queue_processes=200;
4) Heeft u onlangs een update-patch voor de tijdzone toegepast of de database geüpgraded naar een versie met nieuwere tijdzone-informatie? Als u stappen hebt overgeslagen bij het bijwerken van de tijdzone-informatie, worden taken mogelijk niet uitgevoerd. Om te controleren of dit het geval is, kunt u proberen met SQL> selecteer * van sys.scheduler$_job;enSQL> selecteer * van sys.scheduler$_window;en zorg ervoor dat ze zonder fouten eindigen.
Als het een tijdzonewaarschuwing geeft, moet u de upgrade of de tijdzonepatch opnieuw toepassen en ervoor zorgen dat u alle stappen volgt.
5) Draait de database in de beperkte modus? Als de database in de beperkte modus draait, worden er geen taken uitgevoerd (tenzij u 11g gebruikt en het ALLOW_RUNS_IN_RESTRICTED_MODE attribuut gebruikt). Om dit te controleren useSQL> selecteert u logins van v$instance;
Als aanmeldingen beperkt zijn, kunt u de beperkte modus uitschakelen met SQL> ALTER SYSTEEM UITSCHAKELEN BEPERKTE SESSIE;
6) Is de taak gepland om te worden uitgevoerd op een instantie die niet beschikbaar is?
U kunt dit controleren door te kijken of instance_id is ingesteld voor de taak (controleer de weergave dba_scheduler_jobs), en zo ja, controleer dan of die instantie actief is.
7) Is de taak gepland om te worden uitgevoerd op een service die op geen enkele instantie is gestart?
U kunt dit controleren door te controleren naar welke job_class een job verwijst en vervolgens te controleren of die klasse naar een dienst verwijst. Als dit het geval is, zorg er dan voor dat de service is gestart op ten minste één actieve instantie. U kunt een service starten op een instantie met dbms_service.start_service.
8) Is de Resource Manager van kracht met een restrictief resourceplan?
Als er een beperkend resourceplan van kracht is, zijn er mogelijk niet voldoende resources toegewezen aan plannertaken, zodat ze mogelijk niet worden uitgevoerd. U kunt controleren welk resourceplan van kracht is door te doen
SQL> selecteer naam uit V$RSRC_PLAN;
Als er geen plan van kracht is of als het van kracht zijnde plan INTERNAL_PLAN is, is de resourcemanager niet van kracht. Als de resource manager actief is, kunt u deze uitschakelen door te doen
SQL>systeemset wijzigen resource_manager_plan ='';
9) Is de planner uitgeschakeld? Dit is geen ondersteunde actie, maar het is mogelijk dat iemand het toch heeft gedaan. Om deze doSQL te controleren, selecteert u een waarde uit dba_scheduler_global_attribute waarbij attribute_name='SCHEDULER_DISABLED'
Als deze query TRUE retourneert, kunt u dit oplossen met SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Redenen waarom vacatures mogelijk te laat komen
1) Het eerste dat u moet controleren, is de tijdzone waarin de taak is gepland met SQL> select owner, job_name, next_run_date van dba_scheduler_jobs;
Als de taken zich in de verkeerde tijdzone bevinden, worden ze mogelijk niet op de verwachte tijd uitgevoerd. Als de next_run_date een absolute tijdzone-offset gebruikt (zoals +08:00) in plaats van een benoemde tijdzone (zoals US/PACIFIC), kunnen de taken niet worden uitgevoerd zoals verwacht als de zomertijd van kracht is - ze kunnen een uur eerder of later worden uitgevoerd.
2) Het kan zijn dat op het moment dat de taak werd gepland om te worden uitgevoerd, een van de bovenstaande limieten tijdelijk is bereikt, waardoor de taak is vertraagd. Controleer of de bovenstaande limieten hoog genoeg zijn en controleer ze indien mogelijk gedurende de tijd dat de taak taak wordt uitgesteld.
3) Een mogelijke reden dat een van de bovenstaande limieten wordt bereikt, is dat er mogelijk een onderhoudsvenster van kracht is geworden. Onderhoudsvensters zijn OracleScheduler-vensters die behoren tot de venstergroep met de naam MAINTENANCE_WINDOW_GROUP. Tijdens een gepland onderhoudsvenster worden verschillende onderhoudstaken uitgevoerd met behulp van jobs. Dit kan ertoe leiden dat een van de hierboven genoemde limieten wordt bereikt en dat gebruikerstaken worden vertraagd. Zie de beheerdershandleiding voor meer informatie hierover (hoofdstuk 24).
GebruikSQL> om een lijst met onderhoudsvensters te krijgen, selecteer * van dba_scheduler_wingroup_members;
Om te zien wanneer de vensters draaien useSQL> selecteer * van dba_scheduler_windows;
Om dit op te lossen, kunt u de limieten verhogen of de onderhoudsvensters opnieuw plannen zodat ze op geschiktere tijden worden uitgevoerd.
Andere problemen diagnosticeren
Als dit allemaal niet werkt, volgen hier enkele verdere stappen die u kunt nemen om erachter te komen wat er aan de hand is.
1) Controleer of er fouten in het waarschuwingslogboek staan. Als de database problemen heeft met het toewijzen van geheugen of als er onvoldoende schijfruimte is of als er andere catastrofale fouten zijn opgetreden, moet u deze eerst oplossen. U kunt de locatie van het waarschuwingslogboek vinden door SQL te gebruiken> waarde selecteren uit v$parameter waarbij naam ='background_dump_dest'; Het waarschuwingslogboek zal in deze map staan met een naam die begint met "alert".
2) Controleer of een taakcoördinator een traceerbestand bevat en zo ja, controleer of het fouten bevat. Als dit bestaat, bevindt het zich in de directory 'background_dump_dest' die u kunt vinden zoals hierboven en ziet er ongeveer uit als SID-cjq0_nnnn.trc . Als er hier fouten zijn, kunnen ze een hint geven waarom taken niet worden uitgevoerd.
3) Als een van de bovenstaande punten aangeeft dat de SYSAUX-tabelruimte (waar de planner zijn logtabellen opslaat) vol is, kunt u de procedure dbms_scheduler.purge_log gebruiken om oude loggegevens te wissen.
4) Kijk of er momenteel een raam openstaat. Als dat zo is, kun je proberen het te sluiten om te zien of dat helpt.
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5)probeer een eenvoudige run-once-taak uit te voeren en kijk of deze werkt
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) Als een eenvoudige run-once-taak niet wordt uitgevoerd, kunt u proberen de planner als volgt opnieuw te starten.
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');