Esta es una de las preguntas más comunes sobre el Programador. Aquí enumeramos algunos de los problemas comunes y sus soluciones.
1) job_queue_processes puede ser demasiado bajo (este es el problema más común) El valor de job_queue_processes limita el número total de trabajos dbms_scheduler y dbms_job que se pueden ejecutar en un momento dado. Para verificar si este es el caso, verifique el valor actual de job_queue_processes con SQL> seleccione el valor de v$parameter where name='job_queue_processes';Luego verifique el número de trabajos en ejecuciónSQL> select count() from dba_scheduler_running_jobs;SQL> select count( ) de dba_jobs_running;
Si este es el problema, puede aumentar el parámetro usando SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes puede ser demasiado bajo. Si este parámetro no es NULL, entonces limita la cantidad de trabajos de dbms_scheduler que se pueden ejecutar a la vez. Para verificar si este es el problema, verifique el valor actual usando SQL> seleccione el valor de dba_scheduler_global_attributewhere atributo_name='MAX_JOB_SLAVE_PROCESSES'; luego verifique el número de trabajos en ejecuciónSQL> seleccione el recuento (*) de dba_scheduler_running_jobs;
Si este es el problema, puede aumentar el número o simplemente anularlo usando SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) las sesiones pueden ser demasiado bajasEste parámetro limita el número de sesiones en cualquier momento. Cada trabajo de Scheduler requiere 2 sesiones. Para verificar si este es el problema, verifique el valor actual usando SQL> seleccione el valor de v $ parámetro donde nombre ='sesiones'; luego verifique el número actual de sesiones usando SQL> seleccione el recuento (*) de v $ sesión;
Si los números están demasiado cerca, puede aumentar el máximo usando SQL> alter system set job_queue_processes=200;
4) ¿Aplicó recientemente un parche de actualización de zona horaria o actualizó la base de datos a una versión con información de zona horaria más reciente? Si omitió algún paso al actualizar la información de la zona horaria, es posible que los trabajos no se ejecuten. Para verificar si este es el caso, intente hacer SQL> select * from sys.scheduler$_job;andSQL> select * from sys.scheduler$_window;y asegúrese de que terminen sin errores.
Si arroja una advertencia de zona horaria, vuelva a aplicar la actualización o el parche de zona horaria y asegúrese de seguir todos los pasos.
5) ¿La base de datos se ejecuta en modo restringido? Si la base de datos se ejecuta en modo restringido, no se ejecutarán trabajos (a menos que esté usando 11g y use el atributo ALLOW_RUNS_IN_RESTRICTED_MODE).>
Si los inicios de sesión están restringidos, puede desactivar el modo restringido usando SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) ¿El trabajo está programado para ejecutarse en una instancia que está inactiva?
Puede verificar esto al ver si la instancia_id está configurada para el trabajo (consulte la vista dba_scheduler_jobs) y, de ser así, debe verificar si esa instancia está activa.
7) ¿Está el trabajo programado para ejecutarse en un servicio que no se ha iniciado en ninguna instancia?
Puede verificar esto comprobando a qué job_class apunta un trabajo y luego verificando si esa clase apunta a un servicio. Si es así, asegúrese de que el servicio se haya iniciado en al menos una instancia en ejecución. Puede iniciar un servicio en una instancia usando dbms_service.start_service.
8) ¿El administrador de recursos está vigente con un plan de recursos restrictivo?
Si está en vigor un plan de recursos restrictivo, es posible que los trabajos del programador no tengan suficientes recursos asignados, por lo que es posible que no se ejecuten. Puede comprobar qué plan de recursos está en vigor haciendo
SQL> seleccione el nombre de V$RSRC_PLAN;
Si no hay ningún plan en vigor o el plan en vigor es INTERNAL_PLAN, el administrador de recursos no está en vigor. Si el administrador de recursos está activo, puede desactivarlo haciendo
SQL>alterar el conjunto del sistema resource_manager_plan ='';
9) ¿Se ha deshabilitado el programador? Esta no es una acción admitida, pero es posible que alguien la haya hecho de todos modos. Para verificar este doSQL> seleccione el valor de dba_scheduler_global_attribute donde atributo_name='SCHEDULER_DISABLED'
Si esta consulta devuelve VERDADERO, entonces puede arreglar esto usando SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');
Razones por las que los trabajos pueden retrasarse
1) Lo primero que debe verificar es la zona horaria en la que el trabajo está programado con SQL> seleccione propietario, nombre_trabajo, próxima_ejecución_fecha de dba_scheduler_jobs;
Si los trabajos están en la zona horaria incorrecta, es posible que no se ejecuten a la hora esperada. Si next_run_date utiliza una diferencia de zona horaria absoluta (como +08:00) en lugar de una zona horaria con nombre (como EE. UU./PACÍFICO), es posible que los trabajos no se ejecuten como se esperaba si el horario de verano está en vigor; es posible que se ejecuten una hora antes o después.
2) Es posible que en el momento en que se programó la ejecución del trabajo, se haya alcanzado temporalmente uno de los varios límites anteriores, lo que provocó que el trabajo se retrase. Compruebe si los límites anteriores son lo suficientemente altos y, si es posible, verifíquelos durante el tiempo que dure el trabajo. el trabajo se está retrasando.
3) Una posible razón por la que se puede alcanzar uno de los límites anteriores es que puede haber entrado en vigor una ventana de mantenimiento. Las ventanas de mantenimiento son ventanas de OracleScheduler que pertenecen al grupo de ventanas denominado MAINTENANCE_WINDOW_GROUP. Durante una ventana de mantenimiento programado, se ejecutan varias tareas de mantenimiento utilizando trabajos. Esto puede provocar que se alcance uno de los límites enumerados anteriormente y que los trabajos de los usuarios se retrasen. Consulte la guía de administración para obtener más información sobre esto (capítulo 24).
Para obtener una lista de ventanas de mantenimiento, use SQL> seleccione * de dba_scheduler_wingroup_members;
Para ver cuándo se ejecutan las ventanas useSQL> seleccione * de dba_scheduler_windows;
Para solucionar esto, puede aumentar los límites o reprogramar las ventanas de mantenimiento para que se ejecuten en momentos más convenientes.
Diagnóstico de otros problemas
Si nada de esto funciona, aquí hay algunos pasos adicionales que puede seguir para tratar de averiguar qué está pasando.
1) Compruebe si hay algún error en el registro de alertas. Si la base de datos tiene problemas para asignar memoria o se ha quedado sin espacio en disco o ha ocurrido cualquier otro error catastrófico, debe resolverlo primero. Puede encontrar la ubicación del registro de alerta usando SQL> select value from v$parameter where name ='background_dump_dest';El registro de alerta estará en este directorio con un nombre que comienza con "alert".
2) Verifique si hay un archivo de seguimiento del coordinador de trabajo y, si lo hace, verifique si contiene algún error. Si existe, se ubicará en el directorio 'background_dump_dest' que puede encontrar como se indicó anteriormente y tendrá un aspecto similar a SID-cjq0_nnnn.trc . Si hay algún error aquí, puede indicar por qué los trabajos no se están ejecutando.
3) Si cualquiera de los anteriores indica que el tablespace SYSAUX (donde el programador almacena sus tablas de registro) está lleno, puede usar el procedimiento dbms_scheduler.purge_log para borrar las entradas de registro antiguas.
4) Vea si hay una ventana actualmente abierta. Si lo hay, puede intentar cerrarlo para ver si eso ayuda.
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5)intente ejecutar un trabajo simple de una sola vez y vea si se ejecuta
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) Si un trabajo simple de una sola ejecución no se ejecuta, puede intentar reiniciar el programador de la siguiente manera.
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');
