Det här är en av de vanligaste frågorna om Scheduler. Här listar vi några av de vanliga problemen och deras lösningar.
1) job_queue_processes kan vara för lågt (detta är det vanligaste problemet) Värdet på job_queue_processes begränsar det totala antalet dbms_scheduler och dbms_job-jobb som kan köras vid en given tidpunkt. För att kontrollera om så är fallet kontrollera det aktuella värdet av job_queue_processes withSQL> välj värde från v$parameter där name='job_queue_processes';Kontrollera sedan antalet körande jobbSQL> välj antal() från dba_scheduler_running_jobs;SQL> välj antal( ) från dba_jobs_running;
Om detta är problemet kan du öka parametern med SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes kan vara för låg Om denna parameter inte är NULL begränsar den hur många dbms_scheduler-jobb som kan köras åt gången. För att kontrollera om detta är problemet, kontrollera aktuellt värde med SQL> välj värde från dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES'; Kontrollera sedan antalet körande jobbSQL> välj antal(*) från dba_scheduler_running_jobs;
Om detta är problemet kan du öka antalet eller bara NULLA det med SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) sessioner kan vara för låg.Denna parameter begränsar antalet sessioner när som helst. Varje Scheduler-jobb kräver 2 sessioner. För att kontrollera om detta är problemet, kontrollera aktuellt värde med hjälp avSQL> välj värde från v$parameter där name='sessions'; Kontrollera sedan det aktuella antalet sessioner med hjälp avSQL> välj count(*) från v$session;
Om siffrorna är för nära kan du öka maxvärdet med SQL> alter system set job_queue_processes=200;
4) Har du nyligen använt en tidszonuppdatering eller uppgraderat databasen till en version med nyare tidszonsinformation? Om du hoppade över några steg när du uppdaterade tidszonsinformationen kanske jobb inte körs. För att kontrollera om så är fallet, försök att göraSQL> välj * från sys.scheduler$_job;ochSQL> välj * från sys.scheduler$_window;och se till att de avslutas utan fel.
Om det ger en tidszonsvarning, applicera uppgraderingen eller tidszonskorrigeringen igen och se till att följa alla steg.
5) Körs databasen i begränsat läge? Om databasen körs i begränsat läge kommer inga jobb att köras (såvida du inte använder 11g och använder attributet ALLOW_RUNS_IN_RESTRICTED_MODE). För att kontrollera detta useSQL> välj inloggningar från v$instance;
Om inloggningar är begränsade kan du inaktivera det begränsade läget med hjälp avSQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Är jobbet schemalagt att köras på en instans som är nere ?
Du kan kontrollera detta genom att se om instans_id är inställt för jobbet (kontrollera vyn dba_scheduler_jobs), och i så fall bör du kontrollera om den instansen är uppe.
7) Är jobbet schemalagt att köras på en tjänst som inte har startats på några instanser?
Du kan kontrollera detta genom att kontrollera vilken job_class ett jobb pekar på och sedan kontrollera om den klassen pekar på en tjänst. Om den gör det, se till att tjänsten har startats på minst en körande instans. Du kan starta en tjänst på en instans med dbms_service.start_service.
8) Har resurshanteraren en restriktiv resursplan?
Om en restriktiv resursplan är i kraft kan det hända att schemaläggningsjobb inte har tillräckliga resurser tilldelade så att de kanske inte körs. Du kan kontrollera vilken resursplan som gäller genom att göra
SQL> välj namn från V$RSRC_PLAN;
Om ingen plan är i kraft eller om den aktuella planen är INTERNAL_PLAN är resurshanteraren inte aktiv. Om resurshanteraren är aktiv kan du inaktivera den genom att göra
SQL>alter system set resource_manager_plan ='';
9) Har schemaläggaren inaktiverats? Detta är inte en åtgärd som stöds men det är möjligt att någon har gjort det ändå. För att kontrollera detta doSQL> välj värde från dba_scheduler_global_attribute där attribute_name='SCHEDULER_DISABLED'
Om den här frågan returnerar TRUE kan du fixa detta med SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Orsaker till att jobb kan bli försenade
1) Det första att kontrollera är tidszonen som jobbet är schemalagt med SQL> välj ägare, jobbnamn, nästa_körningsdatum från dba_scheduler_jobs;
Om jobben är i fel tidszon kanske de inte körs vid förväntad tid. Om nästa_körningsdatum använder en absolut tidszonförskjutning (som +08:00) istället för en namngiven tidszon (som US/PACIFIC) kan det hända att jobben inte körs som förväntat om sommartid är i kraft - de kan köras en gång i timmen eller sent.
2) Det kan vara så att vid den tidpunkt då jobbet var schemalagt att köras, kan en av de flera gränserna ovan ha nåtts tillfälligt vilket gör att jobbet blev försenat. Kontrollera om gränserna ovan är tillräckligt höga och kontrollera om möjligt dem under den tid som jobbet försenas.
3) En möjlig orsak till att en av ovanstående gränser kan nås är att underhållsfönstret kan ha trätt i kraft. Underhållsfönster är OracleScheduler-fönster som tillhör fönstergruppen MAINTENANCE_WINDOW_GROUP. Under ett schemalagt underhållsfönster körs flera underhållsuppgifter med jobb. Detta kan leda till att en av gränserna som anges ovan nås och användarjobb försenas. Se administratörsguiden för mer information om detta (kapitel 24).
För att få en lista över underhållsfönster useSQL> välj * från dba_scheduler_wingroup_members;
För att se när Windows körs useSQL> välj * från dba_scheduler_windows;
För att fixa detta kan du antingen öka gränserna eller schemalägga underhållsfönstren så att de körs vid mer lämpliga tidpunkter.
Diagnostisera andra problem
Om inget av detta fungerar, här är några ytterligare steg du kan ta för att försöka ta reda på vad som händer.
1) Kontrollera om det finns några fel i varningsloggen. Om databasen har problem med att allokera minne eller har slut på diskutrymme eller om andra katastrofala fel har inträffat, bör du lösa dessa först. Du kan hitta platsen för varningsloggen genom att användaSQL> välj värde från v$parameter där namn ='background_dump_dest'; Varningsloggen kommer att finnas i den här katalogen med ett namn som börjar med "alert".
2) Kontrollera om en spårningsfil för jobbsamordnare och om den gör det, kontrollera om den innehåller några fel. Om detta finns kommer det att finnas i katalogen 'background_dump_dest' som du kan hitta enligt ovan och kommer att se ut ungefär som SID-cjq0_nnnn.trc . Om det finns några fel här kan de tipsa om varför jobb inte körs.
3) Om något av ovanstående indikerar att SYSAUX-tabellutrymmet (där schemaläggaren lagrar sina loggningstabeller) är fullt, kan du använda proceduren dbms_scheduler.purge_log för att rensa bort gamla loggposter.
4) Se om det finns ett fönster öppet. Om det finns kan du försöka stänga den för att se om det hjälper .
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5)försök att köra ett enkelt körningsjobb och se om det körs
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) Om ett enkelt körningsjobb inte körs kan du prova att starta om schemaläggaren enligt följande.
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');