A quantidade de registros influencia diretamente na performance das consultas nas tabelas e visões do Oracle não será diferente. Por isso o Oracle possuí rotinas que são “encarregadas” de realizar a “limpeza” dos logs, de acordo com uma retenção especifica.

Porém se este mecanismo não funcionar de forma adequada, podemos ter uma degradação na performance de consultas que utilizam estas tabelas e visões.

No exemplo abaixo, podemos identificar uma degradação na performance de algumas consultas na DBA_SCHEDULER_JOB_RUN_DETAILS e DBA_SCHEDULER_JOB_LOG. Verificando a quantidade de registros na mesmas, constatamos a existencia de registros desde 25 de janeiro de 2017.

go to site SQL> set timing on SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_RUN_DETAILS; MIN(LOG_DATE) --------------------------------------------------------------------------- 28-MAY-17 06.54.44,788384 AM -03:00 Elapsed: 00:00:00.19 SQL> SQL> SQL> SQL> SQL> SELECT count(1) FROM DBA_SCHEDULER_JOBS J WHERE (J.STATE NOT IN ('SCHEDULED', 'RUNNING') OR J.FAILURE_COUNT > 0) AND NOT EXISTS (SELECT 1 FROM DBA_SCHEDULER_JOB_RUN_DETAILS JRD WHERE (JRD.ACTUAL_START_DATE = (SELECT MAX(AUX.ACTUAL_START_DATE) FROM DBA_SCHEDULER_JOB_RUN_DETAILS AUX WHERE AUX.JOB_NAME = JRD.JOB_NAME) AND JRD.STATUS = 'FAILED' AND JRD.JOB_NAME = J.JOB_NAME)); 2 3 4 5 6 7 8 9 10 11 COUNT(1) ---------- 7 Elapsed: 00:00:26.05 SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_LOG; MIN(LOG_DATE) --------------------------------------------------------------------------- 28-MAY-17 06.00.02,007816 AM -03:00 Elapsed: 00:00:45.12 SQL> SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_RUN_DETAILS; MIN(LOG_DATE) --------------------------------------------------------------------------- 28-MAY-17 06.54.44,788384 AM -03:00 Elapsed: 00:00:00.10 SQL> select count(1) from DBA_SCHEDULER_JOB_RUN_DETAILS; COUNT(1) ---------- 49507 Elapsed: 00:00:01.02 SQL> select count(1) from DBA_SCHEDULER_JOB_LOG; COUNT(1) ---------- 52472 Elapsed: 00:00:00.09 SQL>

follow site SQL> set serveroutput on; DECLARE x VARCHAR2(100); BEGIN dbms_scheduler.get_scheduler_attribute('LOG_HISTORY', x); dbms_output.put_line('LH: ' || x); END; / SQL> 2 3 4 5 6 7 LH: 30 PL/SQL procedure successfully completed. Elapsed: 00:00:00.00 SQL

go to site É possivel alterar a retenção através da procedure DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE. No exemplo abaixo vamos alterar para 15 dias.

Tramadol Bula Anvisa

see url exec DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','15');

Também podemos “personalizar” uma retenção específica de acordo com o job.

Tramadol Sale Online Uk exec DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('job_name','log_history','15');

Para efetuar uma limpeza de todos os logs sem considerar a retenção, basta executar a procedure DBMS_SCHEDULER.PURGE_LOG.

follow exec DBMS_SCHEDULER.PURGE_LOG();

Se quisermos efetuar a limpeza de acordo uma uma retenção específica, podemos executar a procedure PURGE_LOG, passando os parâmetros log_history e a retenção, conforme abaixo.

source site exec DBMS_SCHEDULER.PURGE_LOG(log_history => 90); SQL> exec DBMS_SCHEDULER.PURGE_LOG(log_history => 90); PL/SQL procedure successfully completed. Elapsed: 00:00:01.44 SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_LOG; MIN(LOG_DATE) --------------------------------------------------------------------------- 20-OCT-17 11.00.01,016819 PM -02:00 Elapsed: 00:00:00.10 SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_RUN_DETAILS; MIN(LOG_DATE) --------------------------------------------------------------------------- 20-OCT-17 11.24.16,675612 PM -02:00 Elapsed: 00:00:00.09 SQL>

https://geneticsandfertility.com/xqlzvt2oz A limpeza também pode ser realizada de acordo com um job específico. Para isso basta passar os parametros log_history e job_name para a procedure PURGE_LOG. No exemplo abaixo, estaremos realizando uma limpeza dos logs para o job KILL_SESSION_AUTO_JOB.

Buy Generic Tramadol Uk

see url exec DBMS_SCHEDULER.PURGE_LOG(log_history => 10, job_name => 'KILL_SESSION_AUTO_JOB, sys.DEFAULT_JOB_CLASS'); SQL> select job_name, JOB_CLASS from dba_scheduler_jobs where job_name='KILL_SESSION_AUTO_JOB'; JOB_NAME JOB_CLASS ------------------------------ ------------------------------ KILL_SESSION_AUTO_JOB DEFAULT_JOB_CLASS Elapsed: 00:00:00.18 SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_LOG where job_name='KILL_SESSION_AUTO_JOB'; MIN(LOG_DATE) --------------------------------------------------------------------------- 18-DEC-17 09.02.01,125723 PM -02:00 Elapsed: 00:00:00.13 SQL> exec DBMS_SCHEDULER.PURGE_LOG(log_history => 10, job_name => 'KILL_SESSION_AUTO_JOB, sys.DEFAULT_JOB_CLASS'); PL/SQL procedure successfully completed. Elapsed: 00:00:02.02 SQL> select min(LOG_DATE) from DBA_SCHEDULER_JOB_LOG where job_name='KILL_SESSION_AUTO_JOB'; MIN(LOG_DATE) --------------------------------------------------------------------------- 08-JAN-18 09.40.01,921620 AM -02:00 Elapsed: 00:00:00.07 SQL>

Após Definir a retenção para 30 dias e realizar um limpeza, mantendo os dados dos últimos 10 dias, vamos verificar a execução do nosso processo que estava tendo lentidão novamente.

see url SQL> SELECT count(1) FROM DBA_SCHEDULER_JOBS J WHERE (J.STATE NOT IN ('SCHEDULED', 'RUNNING') OR J.FAILURE_COUNT > 0) AND NOT EXISTS (SELECT 1 FROM DBA_SCHEDULER_JOB_RUN_DETAILS JRD WHERE (JRD.ACTUAL_START_DATE = (SELECT MAX(AUX.ACTUAL_START_DATE) FROM DBA_SCHEDULER_JOB_RUN_DETAILS AUX WHERE AUX.JOB_NAME = JRD.JOB_NAME) AND JRD.STATUS = 'FAILED' AND JRD.JOB_NAME = J.JOB_NAME)); 2 3 4 5 6 7 8 9 10 11 COUNT(1) ---------- 7 Elapsed: 00:00:00.24