Menu de navegação

[PR0GParticipante]

Salve galera (Oracle 10.2.0.5 – Redhat 5.6)

Seguinte, estou com um problema (nem sei se é mesmo problema):

Vejam os dados tirados do Enterprise Manager:

– Processo: MMON ( ora_m000_ – executando a 18:00 horas)
– Logged On For: 1 Days, 1 Hours, 11 Minutes, 50 Seconds
– Last Call Elapsed Time:1 Days, 1 Hours, 12 Minutes, 9 Seconds
– Current Wait Event: direct path write
– P1: file number +DGROUP1/blah/datafile_blah.24.747306495
– P2: first dba 30418
– P3: block cnt 1

Esse cara ta lá travadão, e ainda travando outra sessão.
Tá, posso matar ele (simples) mas de vez em quando (ou de vez em sempre) ele tá lá enroscado…

Sou novato nisso, alguém pode me dar uma luz? Pelo menos o que posso procurar/ler/estudar para entender isso ? Não quero ter que fazer um script para matar ele depois de “x” tempo… Nem sei o efeito que isso causaria…

Já li um pouco (bem pouco) sobre o que o MMON faz, mas porque será que ele está travando? Qualquer luz será bem vinda!!

Obrigado desde já!

[felipegParticipante]

Opa

Amigo o MMON, de modo resumido, é responsável pela coleta das estatisticas do sistema afim de gerar as métricas (por exemplo leitura em disco por segundo).

Ele também é reponsável por monitorar se alguma métrica quebrou o seu nível de alerta para aquele valor (por exemplo uma tablespace que passou de 80% do tamanho).

Sugiro dar uma olhada no seu parâmetro STATISTICS_LEVEL, o recomendado dele para o banco é TYPICAL.

Já vi alguns casos de queda de performance quando esse cara estava setado como ALL, pois o sistema aumenta em muito o range de informações e a qualidade delas.

Tenta ai

Show parameter statistics


E vê o que aparece.
Atenciosamente,
Felipe.

[Victor ArmbrustMestre]

@PR0G

Como o @felipeg disse, o MMON é responsável pelas coletas de estatísticas, consequentemente também trabalha com a coleta dos Snapshots do AWR e métricas.

O processo aparentemente travado é um “slave process” do MMON. (M00**).

Informações de Background Processes do Oracle 10.2: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm

Recomendo vc dar um look nestes notes abaixo:
(Todos dizem que isto foi corrigido na versão 10.2.0.5, mas acho que vale a pena dar uma olhada..)

[b]
Bug 8295094 – M000 reported as potential blocker of WRH$_ACTIVE_SESSION_HISTORY (Doc ID 8295094. 8)

Bug 6057351 – AWR deadlock between Mxxx processes during snapshot purging process (Doc ID 6057351. 8)

Bug 5944498 – MMON goes into deadlock while running tablespace check action (Doc ID 5944498. 8)

[/b]

Realmente é um problema conhecido até a versão 10.2.0.4…

[PR0GParticipante]

Obrigado pela dica Felipe. Veja:

Connected to:
Oracle Database 10g Release 10.2.0.5.0 - Production

SQL> Show parameter statistics;

NAME TYPE VALUE

---

statistics_level string TYPICAL
timed_os_statistics integer 0
timed_statistics boolean TRUE


Está OK, mas já aprendi mais uma.

Eu já estava ligando esse cara às coletas de estatísticas mesmo. Agora reforçou (e muito) meu conceito.

O que me preocupou foi esse “Last Call Elapsed Time: 1 Days, 3 Hours, 14 Minutes, 41 Seconds”

Mas a sessão está ativa, não está idle, ou seja, alguma coisa ele tá fazendo… Deve tá feia a coisa para conseguir coletar. E o ambiente não é ruim… É um IBM Power7, ASM usando Luns de um Storage IBM também…

Bom, vou deixar esse cara chegar até o fim…

Só uma informação a mais:

Current Module MMON_SLAVE
Current Action Auto-Flush Slave Action

Vou esperar pra ver se/quando ele acaba…

Valeu pessoal!!

[felipegParticipante]

Cara, acho que há um engano ai.

O MMON não “termina” (a menos que você configure claro, mas não recomendo nem de longe).

Seu Last Call Elapsed Time só diz a quanto tempo este cara está ativo, se você procurar na v$session vai encontrar o coitado lá, trabalhando.

Se a sessão estiver inativa o Last call dirá a quanto tempo ela está assim.

Como ele é responsável por “vigiar” o banco e coletar os dados para as métricas ele sempre estará trabalhando.

Se eu não me engano ele coleta as métricas de curta duração a cada 15 segundos e as longas a cada 60 segundos, se estiver errado por favor me avisem.

Seu banco de dados está ativo desde quando?

Outra coisa, não confunda a coleta de estatísticas de dados para métricas (leituras por segundo, cpu por user) com as estatísticas das Tabelas e índices ok?

Atenciosamente,
Felipe.

[PR0GParticipante]

Bom, vamos ver se eu entendi.

A sessão atual desse cara, que é um slave do MMON (ora_m001_XXXX) é a 237, que está ativa já há quase 19:00 horas.

O MMON não cria uma sessão, faz a varredura dele e depois fecha?
Então ele abre e fica lá, por toda a existência do banco até o próximo shutdown?

O MMON pai eu até entendo que não pare. Mas esse é um processo filho, não é… Não deveria acabar um dia? Dúvidas bem “newbie” mesmo…

Digo isso porque já não é a primeira vez que vejo esse m001 (e até m002) lá, há muitas horas (já chegou a 4 dias – de uma quinta até no domingo a noite – quando matei ele 😳 ).

Chegou uma hora que parei (shutdown) e voltei tudo, em um outro momento.

Eu estou atualmente com dois servidores, um em cada, vamos dizer filial, e sem nem mesmo ligação entre eles, sistemas diferentes, ramos de atividades diferentes. Ambos Linux on Power, 10.2.0.5

No segundo servidor, nada disso acontece. Não tenho processos parados há dias sem cair… (não falei das sessões SNIPED que nunca morem aqui – mas é outro papo, programa mal codificado mesmo). No segundo servidor um DBA de fora da empresa tem acesso. Será que ele fez algo para otimizar a vida do MMON. Bom,

De qualquer forma foi muito bom e esclarecedor esse papo.

Valeu!!

[jspaulonciParticipante]

PROG, se eu fosse você nem pensava em dar kill no MMON, e em nenhum outro processo do banco, o único momento que podemos apelar para matar esses processos é quando não conseguimos realizar nenhuma tarefa com o sys as sysdba, (acreditem esses momentos existem), fora isso, não é recomendável.

Quanto a informação a informação do last call da v$session , ela será de pouca valia, porque ela tentará manter a sessão proxima ao momento do startup do banco, ou seja, a primeira vez que o SYSMAN entrar de fato para coletar as estatísticas.

Faça o seguinte select e post o retorno se existir

Set lines 400
Set pages 400
select /* Eventos de espera por sessão /
s.username,s.SID,s.SERIAL#, s.osuser,s.server, W.WAIT_TIME,w.SECONDS_IN_WAIT segs,
w.event, w.state
/, w.p1, w.p2, w.p3 / from v$session_wait w,
v$session s where w.sid = s.sid and s.username is not NULL
AND W.WAIT_TIME > -1 and w.event ‘SQLNet message from client’
and w.event not like ‘wait for unread message on broadcast%’ and
w.event not like ‘Streams AQ: waiting for messag%’
and w.event not like ‘TCP Socket (KGAS)%’
And w.EVENT Not Like ‘class slave wait’
And w.EVENT Not Like ‘%SQL*Net more data to client%’

[Autor]

Posts