Colega, algumas obs :
1. COMO, usando qual tool/script/whatever, vc está vendo locks ? Mostre para
a gente o script/procedimento, E os valores que vc está obtendo... Isso vai,
entre outras coisas, nos mostrar se REALMENTE é lock de dados (resultado de
DMLs como o teu INSERT), OU se é lock para acesso à objetos internos,
dicionário, whatever... Por exemplo,
http://surachartopun.com/2009/11/investigate-row-cache-lock.html mostra um caso
aonde o evento era row cache lock decorrente de acesso à sequences com cache
baixo...
Como vc diz que é RAC, talvez vc esteja vendo locks para acesso aos recursos
Globais do cluster, como o Global Cache Lock : pegue no metalink os
scripts/tools específicos para consultar isso, como o racdiag.sql, e consultas
na GV$LOCK também podem ajudar, como
http://www.runningoracle.com/product_info.php?products_id=305 exemplifica...
2. uma vez comprovado que há locks, tenha em mente que eles só interferem na
performance SE :
a. vc está tendo ESPERA pelo recurso bloqueado pelo lock (ie, outras
sessões querem exatamente nessa hora acessar exatamente esse recurso bloqueado)
e
b. essa espera é Constante (repetida diversas vezes), relativamente
longa E presente em qtdade significativa
A simples Contagem de locks absolutamente não quer dizer nada : vc pode ter ,
por exemplo, ** UM BILHÃO ** de locks de linha resultantes de DMLs, que as
outras linhas NÂO SERÃO afetadas, para as outras sessões que não estão tentando
alterar/remover essas linhas lockadas a performance VAI SER ABSOLUTAMENTE
NÃO-AFETADA : o RDBMS Oracle é TOTALMENTE DIFERENTE de outrso RDBMSs aonde a
qtdade de locks interfere em escalabilidade, onde há uma tabela de locks a
manter/controlar, isso não existe aqui...
3. SE vc realmente comprovar que está havendo espera por locks, E que elas
são significativas dentro do tempo total (consultas na V$SESSION, bem como um
tkprof de um trace 10046 level 12 com waits seriam muito úteis nisso), o ponto
de estranheza aqui é que vc diz que a operação em curso é um INSERT : veja,
INSERTs geram (claro) locks, mas as linhas sendo inseridas são ** NOVAS **, não
existiam, então é muito difícil que outras sessões estejam querendo
atualizá-las ... Como uma possibilidade, eu checaria por triggers sendo
disparadas nesse INSERT acima, talvez...
[]s
Chiappa
OBS : se vc encontrar algum subsídio/indicação que aponte para a necessidade
de se cachear num valor mais alto as SEQUENCEs envolvidas, recomendo testar
especificando NOORDER : cfrme
http://www.pythian.com/blog/sequences-in-oracle-10g-rac/ nos diz, se vc
especificar ORDERED via de regra isso Implica num lock global para controlar os
valores, assegurando que eles serão ordenados não importa qual nó os
solicitar...
--- Em oracle_br@yahoogrupos.com.br, Jales Jose Moraes escreveu
>
> Pessoal estou tendo problemas de lock em uma transação que realiza alguns
> inserts. Verificamos os índices, as fk's desta tabela e a lógica na aplicação
> (na qual é simples) mas os locks ainda continua.
>
> No entanto, foi levantado a questão aqui de que pode ser problemas nas
> sequences, já que o ambiente é RAC e as clausas ORDER e CHACHE tem
> significativa
> importãncia neste ambiente, já que o CHACHE dos valores são armazenados
> independente em cada nó e não há necessidade de sincronismo quando a sequence
> está com a clausula NOORDER.
>
> Bom, este fato pode ser o desencadeador dos locks?
>
> [As partes desta mensagem que não continham texto foram removidas]
>
