A questão dos LOBs é que embora eles realmente tenham limites máximos
altíssimos, as linguagens utilizadas no RDBMS (ie, SQL e PL/SQL) possuem
limites menores para o tanto de informação que conseguem enviar/receber do
database de uma só vez (varia de acordo com a versão, mas normalmente é de 4000
bytes para SQL e 32767 para PL/SQL) : assim sendo, vc tem que ** quebrar ** a
informação a receber/enviar de/para os seus LOBs em pedaços de tamanho
adequado, okdoc ? Portanto sim, vc pode ter trocentros gigabytes no teu LOB no
total, mas lidos/gravados de 4000 em 4000 bytes de cada vez (ou de 32767 em
32767 bytes de cada vez, se for PL/SQL).... certo ?
Em cima disso, o que o Analista está supondo pelo que entendi é que a tua
aplicação está usando as APIs da linguagem SQL e por falha de programação em
alguns casos ao invés de enviar pro banco pedaços de 4000 bytes está enviando
pedaços de 4001 bytes, E por bug do RDBMS ao invés de rejeitar o pedaço de
comprimento inválido ele está dando ORA-600, é isso.... Se for uma aplicação
desenvolvida in-house, Confirme com os programadores se eles estão usando a
metodologia apropriada ao trabalhar com LOBs, enviando um pedaço de cada vez da
informação, E se for aplicação de fornecedor, acione o Suporte do fornecedor
para verificar se eles tem notícia de bug desse tipo na Aplicação.... Outra
ação que pode ser MUITO esclarecedora é vc pedir um TRACE (sem tkprof, só o
trace bruto) de uma execução e enviar isso pro Suporte - lá fica registrado
direitinho cada operação que a aplicação fez no banco - , ou mesmo (com a Ajuda
do Suporte Oracle) ativar um evento que gere dump na inserção de um LOB.... Com
essas ações vc Comprova ou Rejeita a Suposição do analista da Oracle...
[]s
Chiappa
OBS : outra coisa que vc pode fazer é testar por corrupção nesses LOBs -
procure no metalink por LOB CORRUPTION que vc acha algumas notas com
procedimentos para isso.....
---Em oracle_br@yahoogrupos.com.br, <raffaell.t...@yahoo.com> escreveu:
Chiappa, obrigado pelas ficas, ja homologuei o procedimento no database de
homologação do SECURE FILES, enquanto isso recebi uma resposta do Suporte da
Oracle no qual fiquei sem entender, poderia me ajudar? Eles falaram o seguinte:
From the supplied trace files here, this looks to be a problem in the
application code, in that it is attempting to update a column with a value
greater than the maximum defined length of the column. For example, we see the
failing statement as:
UPDATE TABELA_XUXA
SET DTEXP = :DTEXP
, DTIMP = :DTIMP
, INDEXP = :INDEXP
, INDIMP = :INDIMP
, TXT = :TXT
, TXTWORD = :TXTWORD
, TXTPDF = :TXTPDF
WHERE CODDOC = :CODDOC
AND NUMSEQ = :NUMSEQ
AND CODLOCALRESP = :CODLOCALRESP
In the bind values for this we see bind number 4 which equates to the 'TXT'
column as being defined as a VARCHAR2 of length 4000 bytes, but the actual bind
variable length is 4001 bytes, and so this overflows the column and hence
corrupts the subsequent lob column. Therefore you need to correct the
application code so that it uses a character value of 4000 bytes or less.
Eu dei um desc na tabela_XUXA e a mesma me trouxe o seguinte:
Name Null? Type
----------------------------------------------------- --------
------------------------------------
CODDOC NOT NULL NUMBER(10)
NUMSEQ NOT NULL NUMBER(4)
TXT CLOB
TXTWORD BLOB
CODLOCALRESP NOT NULL NUMBER(4)
DTEXP DATE
DTIMP DATE
INDEXP VARCHAR2(1)
INDIMP VARCHAR2(1)
TXTPDF BLOB
INDVOTOVISTA VARCHAR2(1)
INDVOTOCONDUTOR VARCHAR2(1)
O campo TXT é CLOB, e não VARCHAR2 como o atendente da Oracle falou acima, e o
tamanho máximo suportado por uma coluna do tipo CLOB e BLOB é de 8TB, me
corrijam se estiver errado. Não sei se esse exemplo que o rapaz deu, é um
exemplo fictício para tentar demonstrar o que está ocorrendo, mas se tratando
de um campo LOB, acho difícil alguém conseguir atualizar um dado maior do que
uma coluna do tipo LOB suporta.
Em Quarta-feira, 7 de Maio de 2014 14:14, "jlchia...@yahoo.com.br"
<jlchia...@yahoo.com.br> escreveu:
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
