Dette er et af de mest almindelige spørgsmål fra planlægningsprogrammet. Her viser vi nogle af de almindelige problemer og deres løsninger.
1) job_queue_processes kan være for lav (dette er det mest almindelige problem) Værdien af job_queue_processes begrænser det samlede antal dbms_scheduler og dbms_job job, der kan køre på et givet tidspunkt. For at kontrollere, om dette er tilfældet, skal du kontrollere den aktuelle værdi af job_queue_processes medSQL> vælg værdi fra v$parameter hvor name='job_queue_processes';Tjek derefter antallet af kørende jobSQL> vælg antal() fra dba_scheduler_running_jobs;SQL> vælg antal( ) fra dba_jobs_running;
Hvis dette er problemet, kan du øge parameteren ved at brugeSQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes kan være for lav. Hvis denne parameter ikke er NULL, begrænser den, hvor mange dbms_scheduler-job, der kan køre ad gangen. For at kontrollere, om dette er problemet, skal du kontrollere den aktuelle værdi ved hjælp afSQL> vælg værdi fra dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES'; Kontroller derefter antallet af kørende jobSQL> vælg antal(*) fra dba_scheduler_running_jobs;
Hvis dette er problemet, kan du øge antallet eller bare NULL det ved at brugeSQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) sessioner kan være for lave. Denne parameter begrænser antallet af sessioner til enhver tid. Hvert Scheduler-job kræver 2 sessioner. For at kontrollere om dette er problemet, tjek den aktuelle værdi ved hjælp afSQL> vælg værdi fra v$parameter hvor name='sessions'; Kontroller derefter det aktuelle antal sessioner ved hjælp afSQL> vælg antal(*) fra v$session;
Hvis tallene er for tæt på, kan du øge det maksimale ved at brugeSQL> alter system set job_queue_processes=200;
4) Har du for nylig anvendt en tidszoneopdateringspatch eller opgraderet databasen til en version med nyere tidszoneoplysninger? Hvis du sprang nogle trin over under opdatering af tidszoneoplysningerne, kører job muligvis ikke. For at kontrollere, om dette er tilfældet, prøv at gøreSQL> vælg * fra sys.scheduler$_job;ogSQL> vælg * fra sys.scheduler$_window;og sørg for, at de afsluttes uden fejl.
Hvis den sender en tidszoneadvarsel, skal du genanvende opgraderingen eller tidszonepatchen og sørge for at følge alle trinene.
5) Kører databasen i begrænset tilstand? Hvis databasen kører i begrænset tilstand, vil ingen job køre (medmindre du bruger 11g og bruger attributten ALLOW_RUNS_IN_RESTRICTED_MODE). For at kontrollere dette, skal du brugeSQL> vælg logins fra v$instance;
Hvis login er begrænset, kan du deaktivere den begrænsede tilstand ved at brugeSQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Er jobbet planlagt til at køre på en instans, der er nede?
Du kan kontrollere dette ved at se, om instance_id er indstillet til jobbet (tjek visningen dba_scheduler_jobs), og hvis det er tilfældet, skal du kontrollere, om den instans er oppe.
7) Er jobbet planlagt til at køre på en tjeneste, der ikke er startet på nogen forekomster?
Du kan kontrollere dette ved at kontrollere, hvilken job_class et job peger på og derefter kontrollere, om den klasse peger på en tjeneste. Hvis det gør det, skal du sørge for, at tjenesten er startet på mindst én kørende forekomst. Du kan starte en tjeneste på en instans ved hjælp af dbms_service.start_service.
8) Har ressourceadministratoren en restriktiv ressourceplan?
Hvis en restriktiv ressourceplan er i kraft, har planlægningsjob muligvis ikke tilstrækkelige ressourcer allokeret, så de kører muligvis ikke. Du kan kontrollere, hvilken ressourceplan der er i kraft, ved at gøre
SQL> vælg navn fra V$RSRC_PLAN;
Hvis ingen plan er i kraft, eller den gældende plan er INTERNAL_PLAN, er ressourcemanageren ikke i kraft. Hvis ressourcehåndteringen er aktiv, kan du deaktivere den ved at gøre
SQL>alter system set resource_manager_plan ='';
9) Er skemalæggeren blevet deaktiveret? Dette er ikke en understøttet handling, men det er muligt, at nogen har gjort det alligevel. For at kontrollere denne doSQL> vælg værdi fra dba_scheduler_global_attribute hvor attribute_name='SCHEDULER_DISABLED'
Hvis denne forespørgsel returnerer TRUE, kan du rette dette ved at brugeSQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Årsager til, at job kan løbe for sent
1) Den første ting at tjekke er tidszonen, som jobbet er planlagt med SQL> vælg ejer, job_name, next_run_date fra dba_scheduler_jobs;
Hvis opgaverne er i den forkerte tidszone, kører de muligvis ikke på det forventede tidspunkt. Hvis next_run_date bruger en absolut tidszoneforskydning (som +08:00) i stedet for en navngivet tidszone (som US/PACIFIC), kører opgaverne muligvis ikke som forventet, hvis sommertid er i kraft - de kan køre en time for tidligt eller sent.
2) Det kan være, at på det tidspunkt, hvor jobbet var planlagt til at køre, kan en af de flere ovenstående grænser være blevet midlertidigt nået, hvilket forårsagede, at jobbet blev forsinket. Tjek, om grænserne ovenfor er høje nok, og kontroller dem om muligt i det tidsrum, hvor jobbet bliver forsinket.
3) En mulig årsag til, at en af ovenstående grænser kan blive ramt, er, at vedligeholdelsesvinduet kan være trådt i kraft. Vedligeholdelsesvinduer er OracleScheduler-vinduer, der tilhører vinduesgruppen med navnetMAINTENANCE_WINDOW_GROUP. I løbet af et planlagt vedligeholdelsesvindue køres flere vedligeholdelsesopgaver ved hjælp af job. Dette kan medføre, at en af grænserne nævnt ovenfor bliver ramt, og brugerjob bliver forsinket. Se administratorvejledningen for mere information om dette (kapitel 24).
For at få en liste over vedligeholdelsesvinduer brugSQL> vælg * fra dba_scheduler_wingroup_members;
For at se, hvornår Windows kører, skal du brugeSQL> vælg * fra dba_scheduler_windows;
For at løse dette kan du enten øge grænserne eller omlægge vedligeholdelsesvinduerne til at køre på mere passende tidspunkter.
Diagnosticering af andre problemer
Hvis intet af dette virker, er her nogle yderligere trin, du kan tage for at prøve at finde ud af, hvad der foregår.
1) Tjek, om der er fejl i advarselsloggen. Hvis databasen har problemer med at allokere hukommelse eller er løbet tør for diskplads, eller der er opstået andre katastrofale fejl, bør du løse dem først. Du kan finde placeringen af advarselsloggen ved at brugeSQL> vælg værdi fra v$parameter hvor navn ='background_dump_dest'; Advarselsloggen vil være i denne mappe med et navn, der starter med "alert".
2) Tjek, om en jobkoordinator-sporingsfil, og hvis den gør, kontrollere, om den indeholder fejl. Hvis dette eksisterer, vil det være placeret i 'background_dump_dest'-mappen, som du kan finde som ovenfor, og vil ligne noget som SID-cjq0_nnnn.trc. Hvis der er fejl her, kan de antyde, hvorfor job ikke kører.
3) Hvis en af ovenstående indikerer, at SYSAUX-tablespacet (hvor planlæggeren gemmer sine logningstabeller) er fyldt, kan du bruge proceduren dbms_scheduler.purge_log til at rydde gamle logposter ud.
4) Se om der er et vindue åbent i øjeblikket. Hvis der er, kan du prøve at lukke den for at 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) prøv at køre et simpelt run-once job og se, om det kører
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) Hvis et simpelt run-once-job ikke kører, kan du prøve at genstarte skemalæggeren som følger.
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');