- Este tópico contém 3 respostas, 2 vozes e foi atualizado pela última vez 6 anos, 5 meses atrás por José Laurindo Chiappa.
-
AutorPosts
-
13 de julho de 2018 às 12:06 am #109341ysmaylyka soares macedoParticipante
Depois de olhar no alert.log sobre este erro, em que outro lugar eu saberia o que teria ocasionado o ORA-00020 ?
13 de julho de 2018 às 12:58 am #109342José Laurindo ChiappaModeradorBlz ? Então, esse erro *** NECESSARIAMENTE *** é causado por algum programa ou usuário que, ANTES do programa / usuário atual que recebeu o erro conectar, consumiu muitos recursos do database, não sobrando o suficiente pro coitado que recebeu o tal erro, ok ?? O cara que recebeu o erro NÂO É O CAUSADOR, ele é uma vítima, tá certo ??
A única maneira de vc descobrir qual é o recurso no database Oracle sendo esgotado é vc MONITORAR o consumo a cada 5 minutos ou coisa assim…. E só pra raferenciar, com “recursos” do database, quero dizer número de sessões/conexões E/OU número de processos criados no Sistema Operacional pelo banco E/OU número de transações simultâneas E/Ou alguns outros itens….
A query que vc teria que ter sendo executada a cada poucos minutos (num job seu, talvez, OU na sua tool de monitoramento de bancos) seria :SELECT RESOURCE_NAME “Name”, CURRENT_UTILIZATION “Current”,
MAX_UTILIZATION “Max”, INITIAL_ALLOCATION “Init”, LIMIT_VALUE “Limit”
FROM V$RESOURCE_LIMIT;Uma vez descoberto qual recurso tá sendo consumido até o limite, se possível AUMENTE o limite no banco (há parâmetros no banco que controlam alguns desses limites, como SESSIONS, PROCESSES, etc) e no Sistema Operacional… Nesse instante que vc notar aumento vai também atrás do pessoal de desenv e veja o que eles estão fazendo nesse momento : não é NADA raro neguim (por exemplo) querer aumentar número de conexões no pool de conexões, ou aumentar a quantidade de usuários simultâneos ou coisas assim SEM avisar o coitado do DBA, que fica com a batata quente na mão…. E claro, também não é NADA DIFÍCIL os duhvelopers terem simplesmente introduzido um BUG no Aplicativo que está fazendo o banco abrir NOVAS conexões sem fechar as já existentes, aí não tem Limite de recurso que aguente…
[]s
Chiappa
24 de julho de 2018 às 5:04 pm #109350ysmaylyka soares macedoParticipanteNossa, agregou demais na minha analise.
Muito obrigada.24 de julho de 2018 às 6:21 pm #109351José Laurindo ChiappaModeradorok… Pra não ficar só no blablablá, vamos a um exemplo :
=> meu banco está configurado para 150 processes e 170 sessões :
system@DESENV:SQL>show parameters 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
logmnr_max_persistent_sessions integer 1
session_cached_cursors integer 20
session_max_open_files integer 10
sessions integer 170
shared_server_sessions integersystem@DESENV:SQL>show parameters process
NAME TYPE VALUE
———————————— ———– ——————————
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 0
job_queue_processes integer 10
log_archive_max_processes integer 2
processes integer 150system@DESENV:SQL>
=> vamos ver o consumo neste momento :
system@DESENV:SQL>SELECT RESOURCE_NAME “Name”, CURRENT_UTILIZATION “Current”,
2 MAX_UTILIZATION “Max”, INITIAL_ALLOCATION “Init”, LIMIT_VALUE “Limit”
3 FROM V$RESOURCE_LIMIT;Name Current Max Init Limit
—————————— ——— ——— ———- ———-
processes 18 35 150 150
sessions 20 40 170 170
enqueue_locks 58 73 2220 2220
enqueue_resources 58 128 968 UNLIMITED
ges_procs 0 0 0 0
ges_ress 0 0 0 UNLIMITED
ges_locks 0 0 0 UNLIMITED
ges_cache_ress 0 0 0 UNLIMITED
ges_reg_msgs 0 0 0 UNLIMITED
ges_big_msgs 0 0 0 UNLIMITED
ges_rsv_msgs 0 0 0 0
gcs_resources 0 0 0 0
gcs_shadows 0 0 0 0
dml_locks 0 93 748 UNLIMITED
temporary_table_locks 0 3 UNLIMITED UNLIMITED
transactions 0 11 187 UNLIMITED
branches 0 2 187 UNLIMITED
cmtcallbk 0 2 187 UNLIMITED
sort_segment_locks 0 7 UNLIMITED UNLIMITED
max_rollback_segments 11 11 187 65535
max_shared_servers 1 1 UNLIMITED UNLIMITED
parallel_max_servers 0 0 0 360022 linhas selecionadas.
==> Agora vou (em outras janelas) abrir várias novas sessões, no caso conectando no sqlplus mas não importa qual foi a tool usada :
SQL*Plus: Release 8.0.6.0.0 – Production on Ter Jul 24 10:09:54 2018
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Conectado a:
Oracle Database 10g Release 10.2.0.5.0 – 64bit Productionscott@DESENV:SQL>
=> outra …
SQL*Plus: Release 8.0.6.0.0 – Production on Ter Jul 24 10:09:55 2018
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Conectado a:
Oracle Database 10g Release 10.2.0.5.0 – 64bit Productionscott@DESENV:SQL>
…. e várias outras…. Aí consulto de novo na janela do SYSTEM :
system@DESENV:SQL>/
Name Current Max Init Limit
—————————— ——— ——— ———- ———-
processes 23 35 150 150
sessions 25 40 170 170
enqueue_locks 58 73 2220 2220
enqueue_resources 58 128 968 UNLIMITED
ges_procs 0 0 0 0
ges_ress 0 0 0 UNLIMITED
ges_locks 0 0 0 UNLIMITED
ges_cache_ress 0 0 0 UNLIMITED
ges_reg_msgs 0 0 0 UNLIMITED
ges_big_msgs 0 0 0 UNLIMITED
ges_rsv_msgs 0 0 0 0
gcs_resources 0 0 0 0
gcs_shadows 0 0 0 0
dml_locks 0 93 748 UNLIMITED
temporary_table_locks 0 3 UNLIMITED UNLIMITED
transactions 0 11 187 UNLIMITED
branches 0 2 187 UNLIMITED
cmtcallbk 0 2 187 UNLIMITED
sort_segment_locks 0 7 UNLIMITED UNLIMITED
max_rollback_segments 11 11 187 65535
max_shared_servers 1 1 UNLIMITED UNLIMITED
parallel_max_servers 0 0 0 360022 linhas selecionadas.
system@DESENV:SQL>
===>> tá aí : tanto o recurso de PROCESSES quanto o de SESSIONS foram Consumidos com as novas sessões, blz ??? Como eu disse, cabe agora a você verificar com os Analistas da aplicação o que que eles aprontaram – se entrara mais usuários, se criaram novos jobs, se mexeram em pool de conexão ….. Tenha CERTEZA do que foi feito E também que o hardware aguenta antes de sair Aumentando os parâmetros de banco ok ???
[]s
Chiappa
-
AutorPosts
- Você deve fazer login para responder a este tópico.