Menu de navegação

[rwarstatParticipante]

Em um banco 10g Standard, versão 10.2.0.1 em uma máquina Red Hat 4 com kernel 2.6.9-42, executo uma package para integração
entre sistemas. A integração é entre 2 schemas na mesma instância e após um certo tempo (em torno de 2hs de execução) a
package continua em execução no banco, mas não faz mais nenhuma inserção. E se deixar ela assim ela fica.
Em uma máquina Red Hat 5 com kernel 2.6.18-53, com a mesma versão de banco isso não aocntece.
Alguma sugestão do que pode estar acontecendo?

Abraço,
Roberto

[Rodrigo AlmeidaParticipante]

Primeiramente, verificar alguns pontos.

1) Gerar um trace da execução da procedure.

2) Verificar quais os eventos de Wait está gerando na sessão que está executando a proc no banco.

3) Verificar os LOGS do RHEL e depois dos alert.log do banco.

Acho que com isso, dá para iniciar as investigações.

Abraços,

Rodrigo Almeida

[rwarstatParticipante]

Rodrigo,
Não entendo no que isso pode ajudar, uma vez que a nívle de banco está tudo ok, visto que em máquinas com RHEL 5 e windows xp (minha máquina que uso para desenvolvimento) está funcionando normalmente.

Abraço,
Roberto

[vieriParticipante]

que lhe garantiu que na camada de banco de dados está tudo ok,
se estivesse não ficaria rodando a package por horas,
ela tem problemas de performance e/ou lógica,
ou tem algum wait event na instância puxando o freio de mão do processo,
por isso siga as instruções do Rodrigo.

[rwarstatParticipante]

Mas é isso que não entendo, pois em máquinas inferiores, mas com outra versão do RHEL a paclage roda perfeitamente. e nessa em questão é que está dando problema.

Irei colocar o processo para rodar novamente e verificar se tem algum wait event. Descarto problema de lógica, pois senão eu teria o problema em qualquer banco.

[Rodrigo AlmeidaParticipante]

Roberto,

Se a package não executa em um banco de dados Oracle no servidor de RHEL 4, é que algum problema tem, seja por parte do Linux ou por parte do banco de dados.

Os itens que passei, são para verificar os possíveis problemas que podem estar ocorrendo, e verificar onde o banco de dados está parando quando manda as instruções para o servidor.

Essas instruções podem trabalhar com memória, CPU e disco do Linux, onde o linux não está conseguindo fornecer isso. Por isso o travamento!!!

Os problemas, podem ser desde uma má instalação do banco de dados no servidor, falta de pacotes do Linux, desatualização de lib, BUG do Oracle, desatualização do Kernel ou até mesmo, falta de recurso.

Mas, insisto em que o Vieri disse, se a PROCEDURE, que está sendo executada no banco de dados está parando, é porque o banco de dados está com problemas também!

Abraços,

Rodrigo Almeida

[David SiqueiraParticipante]

Analisando as recomendações do Rodrigo e do Vieri você pode fatalmente chegar a conclusão de que seu problema possa estar na arquitetura do Hardware, e não apenas na camada banco de dados, é comum acharmos que esta tudo bem no banco só porque não aparece visivelmente um erro ORA, mais as vezes uma controladora configurada errada, um semaforo de Kernel configurado errado, um parametro de S.O confugurado a menor podem gerar alguns problemas bem irritantes. Check as recomendações da rapaziada e post pra gente ver se pode te ajuda rparceiro.

Abração.

David

[rwarstatParticipante]

Estarei fazendo isso, etão logo tenha algum resultado eu posto aqui.
Estou lendo um material que o Chiapp passou através da lista de discussão (postei a minha dúvida lá e aqui, pois sei que tem alguns membros que não lêem o fórum).
Acredito que amanhã terei alguma novidade para postar aqui.

Por enquanto, obrigado a todos.

Abraço,
Roberto

[rwarstatParticipante]

Durante a manhã estava executando o processo novamente no banco através do TOAD e monitorando usando o sql abaixo

select sid, lockwait, status, current_queue_duration,
row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
event, wait_class, seconds_in_wait, state, sql_id
from v$session
where sid = 242

A partir de um determinado momento o resultado foi

   SID LOCKWAIT STATUS   CURRENT_QUEUE_DURATION ROW_WAIT_OBJ# ROW_WAIT_FILE#

---

ROW_WAIT_BLOCK# ROW_WAIT_ROW#

---

EVENT

WAIT_CLASS SECONDS_IN_WAIT

---

STATE SQL_ID

---

   242          INACTIVE                      0            -1              0
          0             0

SQL*Net message from client
Idle 2666
WAITING

Irei testar agora executando diretamente no servidor para vê qual a mensagem que irá retornar.

Abraço,
Roberto

[Rodrigo AlmeidaParticipante]

Até o momento só eventos gerados por tráfego de rede!!!

Executar localmente, nos fornece mais informações.

E durante a execução, poste os últimos registros do alert.log e algum trace gerado durante o horário, no BDUMP ou UDUMP.

Abraços,

Rodirgo Almeida

[rwarstatParticipante]

Como faço para gerar o trace de uma rotina pl/sql?
Sei como fazer de sql, mas quando está executando a partir de um pl/sql não consigo.

[rwarstatParticipante]

Executei localmente e a package rodou sem problemas.
Agora estarei executando novamente remoto para pegar os log´s.

Outra providência que estamos tomando é criar um ambiente aqui na empresa para testarmos as atualizações do banco.

À medida que forem surgindo eventos novos irei postar aqui.

Roberto

[rwarstatParticipante]

Fiz o seguinte teste:
Limpei todas as tabela envolvidas com truncate e rodei novamente o processo de carga. Para o primeiro mês tudo o ocorre normalmente, a carga é efetuada sem problema algum.
Para o segundo mês, a carga trava no final. Sendo que dessa vez ela chegou até o final, fez a atualização na tabela com a informação de que a carga foi efetuada com sucesso, comitou, mas não liberou a sessão.

O trecho final do alert.log está abaixo:

Mon May 11 15:05:33 2009
Thread 1 advanced to log sequence 2745
Current log# 3 seq# 2745 mem# 0: /oracle/oradata/orainfo1/redo03.log
Mon May 11 15:07:19 2009
Thread 1 advanced to log sequence 2746
Current log# 1 seq# 2746 mem# 0: /oracle/oradata/orainfo1/redo01.log
Mon May 11 15:12:46 2009
Thread 1 advanced to log sequence 2747
Current log# 2 seq# 2747 mem# 0: /oracle/oradata/orainfo1/redo02.log
Mon May 11 15:19:31 2009
Thread 1 advanced to log sequence 2748
Current log# 3 seq# 2748 mem# 0: /oracle/oradata/orainfo1/redo03.log
Mon May 11 15:22:39 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 15:30:10 2009
Thread 1 advanced to log sequence 2749
Current log# 1 seq# 2749 mem# 0: /oracle/oradata/orainfo1/redo01.log
Mon May 11 15:40:50 2009
Thread 1 advanced to log sequence 2750
Current log# 2 seq# 2750 mem# 0: /oracle/oradata/orainfo1/redo02.log
Mon May 11 15:54:38 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 15:56:54 2009
Thread 1 advanced to log sequence 2751
Current log# 3 seq# 2751 mem# 0: /oracle/oradata/orainfo1/redo03.log
Mon May 11 16:07:36 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 16:07:47 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 16:10:12 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 16:27:37 2009
Thread 1 advanced to log sequence 2752
Current log# 1 seq# 2752 mem# 0: /oracle/oradata/orainfo1/redo01.log
Mon May 11 16:29:53 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 16:50:32 2009
Thread 1 advanced to log sequence 2753
Current log# 2 seq# 2753 mem# 0: /oracle/oradata/orainfo1/redo02.log
Mon May 11 17:06:00 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 17:10:13 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 17:13:59 2009
Thread 1 advanced to log sequence 2754
Current log# 3 seq# 2754 mem# 0: /oracle/oradata/orainfo1/redo03.log
Mon May 11 17:25:40 2009
ORA-00060: Deadlock detected. More info in file /oracle/admin/orainfo1/udump/orainfo1_ora_4212.trc.
Mon May 11 17:25:43 2009
ORA-00060: Deadlock detected. More info in file /oracle/admin/orainfo1/udump/orainfo1_ora_12057.trc.
Mon May 11 17:25:46 2009
ORA-00060: Deadlock detected. More info in file /oracle/admin/orainfo1/udump/orainfo1_ora_4212.trc.
Mon May 11 17:30:07 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 17:40:45 2009
WARNING: inbound connection timed out (ORA-3136)
Mon May 11 17:46:33 2009
Thread 1 advanced to log sequence 2755
Current log# 1 seq# 2755 mem# 0: /oracle/oradata/orainfo1/redo01.log

Os arquivos traces trouxeram as seguintes informações:

Trace file: orainfo1_ora_12057.trc
Sort options: default

---

count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call

---

Trace file: orainfo1_ora_12057.trc
Trace file compatibility: 10.01.00
Sort options: default

   1  session in tracefile.
   0  user  SQL statements in trace file.
   0  internal SQL statements in trace file.
   0  SQL statements in trace file.
   0  unique SQL statements in trace file.
9055  lines in trace file.
   0  elapsed seconds in trace file.

Trace file: orainfo1_ora_4212.trc
Sort options: default

---

count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call

---

Trace file: orainfo1_ora_4212.trc
Trace file compatibility: 10.01.00
Sort options: default

   1  session in tracefile.
   0  user  SQL statements in trace file.
   0  internal SQL statements in trace file.
   0  SQL statements in trace file.
   0  unique SQL statements in trace file.

16605 lines in trace file.
0 elapsed seconds in trace file.

A sessão está como waiting e o evento é o “SQL*Net message from client”.

O interessante é que se eu limpar as tabelas e fizer a carga de um mês vai correr tudo normal, mas se esse mês for o segundo a ser carregado, trava tudo.

[David SiqueiraParticipante]

Cara e esses erros ai que vc postou, você ja sanou eles ?

WARNING: inbound connection timed out (ORA-3136)
ORA-00060: Deadlock detected. More info in

Tem algum processo rodando que faça a mesma coisa que seu processo esta fazendo , pra que gere esse DEADLOCK?

ABcs..
David

[rwarstatParticipante]

David,

Quanto ao deadlock, não tem mais nenhum outro processo fazendo a mesma coisa que o meu.

Em relação ao ORA-3136, acredito que para o meu caso isso seja normal, pois estou conectado remotamente em um cliente. Ao menos essa é a impressão que eu tive lendo essa discussão http://forums.oracle.com/forums/thread. … 7&tstart=0

Abraço,
Roberto

[Autor]

Posts