Opa, tudo jóia ? Então, os archives são simplesmente ** cópias ** do redo log
gerado, E Necessariamente redo log só é gerado quando alguém/algo faz
TRANSAÇÕES , ie, manda algum tipo de INSERT ou UPDATE ou DELETE, ok ?? Isso é
CONCEITUAL, é algo que se pode contar, é Básico num RDBMS...
Sendo assim, Não Há Escapatória : se vc está vendo archived redo logs sendo
gerados numa taxa grande, Obrigatoriamente teu database está Sofrendo
transações que estão gerando REDO, não tem como o REDO ser gerado do vácuo, sem
uma causa ... Já que vc diz que não há sessões de usuário final abertas no
momento, NECESSARIAMENTE podemos concluir que OU há JOBs disparando e criando
transações OU há outros databases conectando nesse via dblink ou acesso remoto
e criando transações remotas OU vc tem alguma aplicação e/ou script/tool
Externa conectando ao database e abrindo Transações... okdoc ? É nisso que
chegamos, ie, a empresa *** NÃO *** está totalmente "parada", tem algo/alguém,
talvez de outro departamento OU algum sistema/aplicativo, que está SIM mexendo
nesse database....
Para vc encontrar as sessões causando redo em alto volume, basicamente vc
consulta as Estatísticas internas de uso do database, que são refletidas em
views internas, e/ou pode consultar as DATAS de gerações de redo log e/ou (SE
vc tiver Licença de uso que permita isso!) pode consultar o AWR/ASH :
http://damir-vadas.blogspot.com.br/2011/02/how-to-redo-logs-generation.html
exemplifica todas as opções....
Isso posto, a sua resposta : todos esses objetos citados nos DMLs que vc
obteve ()ie, SYS.JOB$, SYS.SCHEDULER$_EVENT_LOG, etc) são objetos INTERNOS do
database (o owner SYS já Evdidencia isso) e são todos relacionados a JOBs de
database - quando um JOB dispara todos os objetos internos de controle de jobs
tem que ser atualizados com o resultado do JOB, pelo jeito é isso que vc está
vendo aí... Esse cenário Reforça a hipótese de que vc tenha JOBs disparando e
gerando o redo que implica em grande qtdade de archives, analise direitinho
isso ...
[]s
Chiappa
