Oracle
 sql >> Base de Dados >  >> RDS >> Oracle

Trabalho do Oracle DBMS não está em execução


Esta é uma das perguntas mais comuns do Agendador. Aqui listamos alguns dos problemas comuns e suas soluções.

1) job_queue_processes pode estar muito baixo (este é o problema mais comum) O valor de job_queue_processes limita o número total de jobs dbms_scheduler e dbms_job que podem ser executados em um determinado momento. selecione o valor de v$parameter onde name='job_queue_processes';Em seguida, verifique o número de jobs em execuçãoSQL> selecione contagem() de dba_scheduler_running_jobs;SQL> selecione contagem( ) de dba_jobs_running;

Se este for o problema, você pode aumentar o parâmetro usando SQL> alter system set job_queue_processes=1000;

2) max_job_slave_processes pode ser muito baixo Se este parâmetro não for NULL, ele limita quantos trabalhos dbms_scheduler podem ser executados por vez. Para verificar se esse é o problema, verifique o valor atual usandoSQL> selecione o valor de dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES';Em seguida, verifique o número de jobs em execuçãoSQL> selecione count(*) de dba_scheduler_running_jobs;

Se este for o problema, você pode aumentar o número ou simplesmente NULL usando SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)

3) as sessões podem ser muito baixasEste parâmetro limita o número de sessões a qualquer momento. Cada job do Agendador requer 2 sessões. Para verificar se este é o problema, verifique o valor atual usingSQL> selecione o valor de v$parameter where name='sessions';Depois verifique o número atual de sessões usingSQL> selecione count(*) de v$session;

Se os números estiverem muito próximos, você pode aumentar o máximo usando SQL> alter system set job_queue_processes=200;

4) Você aplicou recentemente um patch de atualização de fuso horário ou atualizou o banco de dados para uma versão com informações de fuso horário mais recentes? Se você pulou alguma etapa ao atualizar as informações de fuso horário, os trabalhos podem não ser executados. Para verificar se este é o caso tente fazer SQL> selecione * de sys.scheduler$_job;andSQL> selecione * de sys.scheduler$_window;e certifique-se de terminar sem erros.

Se ele lançar um aviso de fuso horário, aplique novamente o patch de atualização ou fuso horário certificando-se de seguir todas as etapas.

5) O banco de dados está rodando em modo restrito? Se o banco de dados estiver rodando em modo restrito então nenhum job será executado (a menos que você esteja usando 11g e use o atributo ALLOW_RUNS_IN_RESTRICTED_MODE). Para verificar isso useSQL> selecione logins de v$instance;

Se os logins forem restritos, você poderá desabilitar o modo restrito usando SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) O trabalho está programado para ser executado em uma instância que está inativa?

Você pode verificar isso vendo se instance_id está definido para o trabalho (verifique a visualização dba_scheduler_jobs) e, se estiver, verifique se essa instância está ativa.

7) O trabalho está programado para ser executado em um serviço que não foi iniciado em nenhuma instância?

Você pode verificar isso verificando para qual job_class um job aponta e, em seguida, verificando se essa classe aponta para um serviço. Se isso acontecer, verifique se o serviço foi iniciado em pelo menos uma instância em execução. Você pode iniciar um serviço em uma instância usando dbms_service.start_service.

8) O Resource Manager está em vigor com um plano de recursos restritivo?

Se um plano de recursos restritivo estiver em vigor, as tarefas do planejador podem não ter recursos suficientes alocados para que não sejam executadas. Você pode verificar qual plano de recursos está em vigor fazendo

SQL> selecione o nome de V$RSRC_PLAN;

Se nenhum plano estiver em vigor ou o plano em vigor for INTERNAL_PLAN, o gerenciador de recursos não estará em vigor. Se o gerenciador de recursos estiver em vigor, você pode desativá-lo fazendo

SQL>alter system set resource_manager_plan ='';

9) O Agendador foi desabilitado? Esta não é uma ação com suporte, mas é possível que alguém tenha feito isso de qualquer maneira. Para verificar este doSQL> selecione o valor de dba_scheduler_global_attribute onde attribute_name='SCHEDULER_DISABLED'

Se esta consulta retornar TRUE, você poderá corrigir isso usando SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

Motivos pelos quais os trabalhos podem atrasar

1) A primeira coisa a verificar é o fuso horário em que o trabalho está agendado com SQL> select owner, job_name, next_run_date from dba_scheduler_jobs;

Se os trabalhos estiverem no fuso horário errado, eles podem não ser executados no horário esperado. Se next_run_date estiver usando um deslocamento de fuso horário absoluto (como +08:00) em vez de um fuso horário nomeado (como US/PACIFIC), os trabalhos podem não ser executados conforme o esperado se o horário de verão estiver em vigor - eles podem ser executados de hora em hora ou atrasado.

2) Pode ser que no momento em que o trabalho foi agendado para execução, um dos vários limites acima tenha sido atingido temporariamente causando atraso no trabalho. Verifique se os limites acima são altos o suficiente e, se possível, verifique-os durante o tempo em que o trabalho trabalho está sendo adiado.

3) Uma possível razão pela qual um dos limites acima pode ser atingido é que uma janela de manutenção pode ter entrado em vigor. As janelas de manutenção são janelas do OracleScheduler que pertencem ao grupo de janelas chamado MAINTENANCE_WINDOW_GROUP. Durante uma janela de manutenção programada, várias tarefas de manutenção são executadas usando trabalhos. Isso pode fazer com que um dos limites listados acima seja atingido e os trabalhos do usuário sejam atrasados. Consulte o guia de administração para obter mais informações sobre isso (capítulo 24).

Para obter uma lista de janelas de manutenção useSQL> selecione * de dba_scheduler_wingroup_members;

Para ver quando as janelas executam useSQL> selecione * from dba_scheduler_windows;

Para corrigir isso, você pode aumentar os limites ou reagendar as janelas de manutenção para serem executadas em horários mais convenientes.

Diagnosticando outros problemas

Se nada disso funcionar, aqui estão alguns passos adicionais que você pode tomar para tentar descobrir o que está acontecendo.

1) Verifique se há algum erro no log de alertas. Se o banco de dados estiver tendo problemas para alocar memória ou ficar sem espaço em disco ou ocorrerem outros erros catastróficos, você deve resolvê-los primeiro. Você pode encontrar a localização do log de alerta usando SQL> select value from v$parameter where name ='background_dump_dest';O log de alerta estará neste diretório com um nome começando com "alert".

2) Verifique se há algum arquivo de rastreamento do coordenador de trabalho e, se houver, verifique se contém algum erro. Se isso existir, ele estará localizado no diretório 'background_dump_dest' que você pode encontrar como acima e será parecido com SID-cjq0_nnnn.trc . Se houver algum erro aqui, eles podem indicar por que os trabalhos não estão sendo executados.

3) Se um dos itens acima indicar que o tablespace SYSAUX (onde o planejador armazena suas tabelas de log) está cheio, você pode usar o procedimento dbms_scheduler.purge_log para limpar as entradas de log antigas.

4) Veja se há uma janela aberta no momento. Se houver, você pode tentar fechá-lo para ver se isso ajuda.
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');

5) tente executar um trabalho simples de execução única e veja se ele é executado
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) Se um trabalho de execução única simples não for executado, você pode tentar reiniciar o agendador da seguinte maneira.
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');