Bom, eu acho que vc tem duas questões diferentes em mãos - causalmente
aconteceram no mesmo timeframe, mas pode muito bem ser que não estejam
relacionadas com causa e efeito, ie : que o ORA-600 foi foi causado por eventos
disparados pelo UPDATE é certo, mas Não É certo que seja o ORA-600 que está
causando o enqueue, okdoc ?? Vamos tratar separadamente, então...
Começando com o ORA-600 : não tenho outro conselho que não seja o default, ie
: usar a tool de lookup de ORA-600 no metalink *** E ***, mais importante de
tudo, abrir um Chamado no Suporte Oracle ....
Sobre enqueue em LOBs , meu conselho principal é que vc analise com carinho a
possibilidade de usar SECUREFILES para as tablespaces que contém os LOBs, elas
via de regra são Muito mais eficientes em manutenção/alocação de extents do que
BASICFILES.... Em segundo lugar, vc VAI abrir um Chamado no Suporte para
comprovar que os bugs já conhecidos (e em princípio já sanados) comuns em LOBs
não estão re-surgindo no seu ambiente (principalmente os bugs 4450406, 5636728
e o 5565887, entre outros : não é comum bugs tão antigos resurgirem (após um
PSU, após alguma alteração de ambiente) mas é o Suporte que vai confirmar ou
negar isso...
Como WORK-AROUND, vc pode experimentar deixar alguns tantos muitos extents já
pré-alocados (com muitas execuções de ALLOCATE EXTENT), alterar params de
storage / controle de alocação nos blocos (e eventualmente adicionar
FREELISTS), experimentar inverter o tipo de controle de extents da tablespace
(ie, se hoje é ASSM mudar para manual/MSSMN, se hoje é manual mudar para
ASSM)....
Vc também pode aproveitar esse mesmo Chamado vc aproveita para pedir
Autorização para implementar coisas como o param _bump_highwater_mark_count ,
ás vezes ajuda, mas Nem em Sonhos Pense em fazer isso em prod sem Autorização,
que a Oracle corta o teu Suporte sem dó nem pena se descobrir...
[]s
Chiappa
