Menu de navegação

[rwarstatParticipante]

Bom, fiz a carga somente do trecho da package onde normalmente dá problema (a package é dividida em 3 partes principais – gastos, materiais e receitas), que é a de receitas. A carga ocorreu sem problemas, inserindo em 22.370 registros numa boa.
O problema é que não posso fazer a execução por partes, tenho que fazer tudo de uma vez só.

Abraço,
Roberto

[Rodrigo AlmeidaParticipante]

Roberto,

Vamos analisar por partes.

1) Inbound Connection

Esse erro é quando se tem algum profile configurado no usuário, que limite o CONNECT_TIME ou IDLE_TIME, onde ele derruba a conexão.

Se pode ter esses erros também por configurações no arquivo sqlnet.ora e listener.ora, pois tu pode mencionar o tempo de conexão para um determinado client.

Se estiver utilizando o RESOURCE MANAGER, seu usuário pode estar em grupos de recursos que podem lhe limitar a sua utilização. Por isso os Inbounds.

2) ORA-00060 – Deadlock

Bom, esse é sem dúvida, concorrência pelos registros, ou seja, necessariamente tu não precisa executar a mesma PROCEDURE para acontecer o DEADLOCK, outros processos em paralelo, executados manualmente ou automáticos, podem concorrer com você pelas alterações dos registros, e quando o Oracle identifica isso, acontece o DEADLOCK, onde uma sessão automáticamente é derrubada.

Com certeza, algum processo, que faça DMLs está utilizando alguma tabela que pertence ao seu processo. Para saber com mais detalhes, cada Deadlock gerado, irá gerar um trace, apenas abra esse trace que ele fornece até o comando que foi executado para acontecer o deadlock.

Abraços,

Rodrigo Almeida

[rwarstatParticipante]

Rodrigo,

Vamos cotninuar por partes.

1) Irei passar para o nosso DBA dar uma olhada, pois isso foge da minha alçada.

2) O início dos tracers de deadlock são os que estão abaixo

/oracle/admin/orainfo1/udump/orainfo1_ora_4212.trc
Oracle Database 10g Release 10.2.0.1.0 – Production
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: srvhcc
Release: 2.6.9-42.0.0.0.1.ELsmp
Version: #1 SMP Sun Oct 15 14:02:40 PDT 2006
Machine: i686
Instance name: orainfo1
Redo thread mounted by this instance: 1
Oracle process number: 51
Unix process pid: 4212, image: oracleorainfo1@srvhcc

*** 2009-05-11 17:25:39.978
*** SERVICE NAME:(SYS$USERS) 2009-05-11 17:25:39.946
*** SESSION ID:(297.37456) 2009-05-11 17:25:39.946
DEADLOCK DETECTED
[Transaction Deadlock]
Current SQL statement for this session:
update matmed SET qt_estoque =( qt_estoque – :1 ) WHERE cd_material =:2 AND qt_estoque >= :3
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-00030028-0000a35a 51 297 X 17 317 X
TX-00050024-0000a818 17 317 X 51 297 X
session 297: DID 0001-0033-000010E0 session 317: DID 0001-0011-00002B9B
session 317: DID 0001-0011-00002B9B session 297: DID 0001-0033-000010E0
Rows waited on:
Session 317: obj – rowid = 000070C5 – AAAIMWAAJAAAADqAAQ
(dictionary objn – 28869, file – 9, block – 234, slot – 16)
Session 297: obj – rowid = 000070C5 – AAAIMWAAJAAAADqAAM
(dictionary objn – 28869, file – 9, block – 234, slot – 12)
Information on the OTHER waiting sessions:
Session 317:
pid=17 serial=21180 audsid=6685672 user: 121/JOSAINE
O/S info: user: farm2, term: FARM2, ospid: 1204:1720, machine: TIFARM2
program: suprim.exe
application name: suprim.exe, hash value=0
Current SQL Statement:
update matmed SET qt_estoque =( qt_estoque – :1 ) WHERE cd_material =:2 AND qt_estoque >= :3
End of information on OTHER waiting sessions.

/oracle/admin/orainfo1/udump/orainfo1_ora_12057.trc
Oracle Database 10g Release 10.2.0.1.0 – Production
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: srvhcc
Release: 2.6.9-42.0.0.0.1.ELsmp
Version: #1 SMP Sun Oct 15 14:02:40 PDT 2006
Machine: i686
Instance name: orainfo1
Redo thread mounted by this instance: 1
Oracle process number: 17
Unix process pid: 12057, image: oracleorainfo1@srvhcc

*** 2009-05-11 17:25:43.257
*** SERVICE NAME:(SYS$USERS) 2009-05-11 17:25:43.251
*** SESSION ID:(317.21180) 2009-05-11 17:25:43.251
DEADLOCK DETECTED
[Transaction Deadlock]
Current SQL statement for this session:
update matmed SET qt_estoque =( qt_estoque – :1 ) WHERE cd_material =:2 AND qt_estoque >= :3
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-00050024-0000a818 17 317 X 51 297 X
TX-00030028-0000a35a 51 297 X 17 317 X
session 317: DID 0001-0011-00002B9B session 297: DID 0001-0033-000010E0
session 297: DID 0001-0033-000010E0 session 317: DID 0001-0011-00002B9B
Rows waited on:
Session 297: obj – rowid = 000070EC – AAAIP1AAHAAAa+uAAv
(dictionary objn – 28908, file – 7, block – 110510, slot – 47)
Session 317: obj – rowid = 000070C5 – AAAIMWAAJAAAADqAAQ
(dictionary objn – 28869, file – 9, block – 234, slot – 16)
Information on the OTHER waiting sessions:
Session 297:
pid=51 serial=37456 audsid=6681886 user: 72/MARILISE
O/S info: user: farm5, term: FARM5, ospid: 1996:2000, machine: TIFARM5
program: suprim.exe
application name: suprim.exe, hash value=0
Current SQL Statement:
update matmed_hospital SET qt_estoque =( qt_estoque – :1 ) WHERE cd_hospital =:2 and cd_material =:3 and qt_estoque >= :4
End of information on OTHER waiting sessions.

Na tabela mencionada eu não mexo durante o meu processo. Acesso essas tabelas somente para leitura através de cursores. Ao que tudo me indica ocorreu um deadlock quando da operação rotineira do sistema pelo nosso cliente.
Estou certo?

Abraço,
Roberto

[Rodrigo AlmeidaParticipante]

Roberto,

1)

Melhor verificar com o DBA as configurações para saber os limites de cada sessão de banco de dados, isso pode sim lhe limitar recursos e tempo dentro do banco de dados.

É recomendado dar uma olhada.

2)

Sobre os Deadlocks, tu pode estar certo sim, não exatamente na abertura dos seus cursores, por cursor irá fazer somente SELECT, mas em outro momento dentro do processo que tente fazer um UPDATE ou DELETE do registro lido.

Para identificar os carinhas, está abaixo em negrito.

/oracle/admin/orainfo1/udump/orainfo1_ora_4212.trc
Oracle Database 10g Release 10.2.0.1.0 – Production
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: srvhcc
Release: 2.6.9-42.0.0.0.1.ELsmp
Version: #1 SMP Sun Oct 15 14:02:40 PDT 2006
Machine: i686
Instance name: orainfo1
Redo thread mounted by this instance: 1
Oracle process number: 51
Unix process pid: 4212, image: oracleorainfo1@srvhcc

*** 2009-05-11 17:25:39.978
*** SERVICE NAME:(SYS$USERS) 2009-05-11 17:25:39.946
*** SESSION ID:(297.37456) 2009-05-11 17:25:39.946
DEADLOCK DETECTED
[Transaction Deadlock]
Current SQL statement for this session:
update matmed SET qt_estoque =( qt_estoque – :1 ) WHERE cd_material =:2 AND qt_estoque >= :3
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-00030028-0000a35a 51 297 X 17 317 X
TX-00050024-0000a818 17 317 X 51 297 X
session 297: DID 0001-0033-000010E0 session 317: DID 0001-0011-00002B9B
session 317: DID 0001-0011-00002B9B session 297: DID 0001-0033-000010E0
Rows waited on:
Session 317: obj – rowid = 000070C5 – AAAIMWAAJAAAADqAAQ
(dictionary objn – 28869, file – 9, block – 234, slot – 16)
Session 297: obj – rowid = 000070C5 – AAAIMWAAJAAAADqAAM
(dictionary objn – 28869, file – 9, block – 234, slot – 12)
Information on the OTHER waiting sessions:
Session 317:
pid=17 serial=21180 audsid=6685672 user: 121/JOSAINE
O/S info: user: farm2, term: FARM2, ospid: 1204:1720, machine: TIFARM2
program: suprim.exe
application name: suprim.exe, hash value=0
Current SQL Statement:
update matmed SET qt_estoque =( qt_estoque – :1 ) WHERE cd_material =:2 AND qt_estoque >= :3
End of information on OTHER waiting sessions.

Abraços,
Rodrigo Almeida[/b]

[rwarstatParticipante]

Rodrigo,
Já passei para o DBA olhar a questão dos Inbound Connection.
E os deadlocks foram ocasionados pelo uso do nosso aplicativo, mas pelo que andei olhando foi algo pontual.

Alguma sugestão sobre o comportamento “estranho” dessa package?

Abraço,
Roberto

[rwarstatParticipante]

Depois de alguns testes chegamos a conclusão de que a package está funcionando perfeitamente. Executamos ela 2 vezes localmente no cliente e não houve qualquer erro.
A orientação que irei passar para a equipe é de que essa package não pdoe ser executada via rede, somente local.

Muito obrigado a todos.

Abraço,
Roberto

[Autor]

Posts