Chiappa, Consegui habilitar a métrica para monitorar PROCESSES no cloud control.
Atenciosamente, Rogério Camatini. Em 3 de dezembro de 2014 11:21, Roger Camatini <rogerio.camat...@gmail.com> escreveu: > Chiappa, > > Fiz a alteração mencionada, mas decidi manter os valores para PROCESSES e > SESSIONS: > > NAME TYPE VALUE > ------------------------------------ ----------- > ------------------------------ > aq_tm_processes integer 1 > cell_offload_processing boolean TRUE > db_writer_processes integer 1 > gcs_server_processes integer 0 > global_txn_processes integer 1 > job_queue_processes integer 10 > log_archive_max_processes integer 4 > processes integer 1000 > processor_group_name string > SQL> show parameter session > > NAME TYPE VALUE > ------------------------------------ ----------- > ------------------------------ > java_max_sessionspace_size integer 0 > java_soft_sessionspace_limit integer 0 > license_max_sessions integer 0 > license_sessions_warning integer 0 > session_cached_cursors integer 50 > session_max_open_files integer 10 > sessions integer 1528 > shared_server_sessions integer > SQL> exit > > Situação atual: > > oracle@hostname:/oracle> ps -ef | grep homol11 | grep -v grep | wc -l > 135 > oracle@hostname:/oracle> > > Situação após restart da instancia: > > oracle@hostname:/oracle> ps -ef | grep homol11 | grep -v grep | wc -l > 22 > oracle@hostname:/oracle> > > Utilizamos aqui o Cloud Control 12c, consigo monitorar essa anomalia com > esta ferramenta? > > > Atenciosamente, > Rogério Camatini. > > Em 3 de dezembro de 2014 10:13, jlchia...@yahoo.com.br [oracle_br] < > oracle_br@yahoogrupos.com.br> escreveu: > > >> >> Nada como consultar a fonte da verdade real, né não ? A query na >> RESOURCE_LIMIT mostra **** claramente **** que SIM, vc chegou a ter uma >> quantidade de sessions E de processes que bateu no limite, então MUITO >> CERTAMENTE isso foi a causa da tua impossibilidade de conectar... Vc vai >> ter que fazer o seguinte agora : >> >> 1. fazer a investigação (principalmente no log do listener, cfrme >> mostrado nos links que passei) para vc ver se realmente não está tendo >> leaking de processos : isso parece provável, pois a tua situação de agora, >> com mais de 700 processes para apenas 30 e poucas sessions absolutamente >> *** Não é Normal *** >> >> 2. alteração dos parâmetros : primeiro 1000 como job_queue_processes é >> questionável : via de regra isso não pega nada porque ninguém sai criando >> centenas de jobs simultãneos em banco, mas vai saber... Acho mais seguro vc >> colocar um valor não-default e Realista nesse cara... Também recomendo que, >> se vc achar por bem subir um pouco sessions/processes, que vc siga a >> fórmula da Doc (ie, (1.1 * PROCESSES) + 5, iirc) para SESSIONS e PROCESSES >> >> 3. restart do database (sendo banco homo, não-prod, não deve ter grandes >> impedimentos), para que zerem os contadores da resource_limit >> >> 4. ativar os recursos que vc tiver de MONITORAÇÃO nesse database, para >> ser Alertado quando o consumo chegar perto do limite : o OEM tem recursos >> pra isso por default, vc pode ter um job (interno ou externo ao db) que >> periodicamente checa isso, pode ter uma trigger de logon, enfim, n >> possibilidades... O ponto é que, pelo que vejo, está **** PROVADO **** que >> o problema é EXTERNO ao database, é aplicação abrindo muitas sessões e/ou >> com leaking e/ou com erro na config de pools e/ou criando centenas de jobs >> ou abrindo threads no database.... NADA disso tem a ver com o database, que >> no caso está sendo é Vítima desse consumo externo inapropriado... >> >> []s >> >> Chiappa >> >> > >
