O comportamento dos LOBs do Oracle é o seguinte.
Um LOB é armazenado em linha quando:
(
The size is lower or equal than 3964
AND
ENABLE STORAGE IN ROW has been defined in the LOB storage clause
) OR (
The value is NULL
)
Um LOB é armazenado fora da linha quando:
(
The value is not NULL
) AND (
Its size is higher than 3964
OR
DISABLE STORAGE IN ROW has been defined in the LOB storage clause
)
Agora, este não é o único problema que pode afetar o desempenho.
Se os LOBs finalmente não forem armazenados inline, o comportamento padrão do Oracle é evitar armazená-los em cache (somente LOBs inline são armazenados no cache de buffer com os outros campos da linha). Para dizer ao Oracle para também armazenar em cache LOBs não embutidos, a opção CACHE deve ser usada quando o LOB for definido.
O comportamento padrão é ENABLE STORAGE IN ROW e NOCACHE, o que significa que pequenos LOBs serão embutidos, LOBs grandes não (e não serão armazenados em cache).
Finalmente, há também um problema de desempenho no nível do protocolo de comunicação. Clientes Oracle típicos realizarão 2 viagens de ida e volta adicionais por LOBs para buscá-los:- um para recuperar o tamanho do LOB e alocar memória de acordo - um para buscar os dados em si (desde que o LOB seja pequeno)
Essas viagens de ida e volta extras são executadas mesmo se uma interface de matriz for usada para recuperar os resultados. Se você recuperar 1.000 linhas e o tamanho do array for grande o suficiente, você pagará 1 ida e volta para recuperar as linhas e 2.000 ida e volta para recuperar o conteúdo dos LOBs.
Observe que não dependem do fato de o LOB ser armazenado em linha ou não. São problemas completamente diferentes.
Para otimizar no nível do protocolo, a Oracle forneceu um novo verbo OCI para buscar vários LOBs em uma viagem de ida e volta (OCILobArrayRead). Não sei se existe algo semelhante com JDBC.
Outra opção é vincular o LOB no lado do cliente como se fosse um grande RAW/VARCHAR2. Isso só funciona se um tamanho máximo do LOB puder ser definido (já que o tamanho máximo deve ser fornecido no momento da ligação). Esse truque evita as viagens extras:os LOBs são processados apenas como RAW ou VARCHAR2. Nós o usamos muito em nossos aplicativos intensivos de LOB.
Uma vez que o número de viagens de ida e volta tenha sido otimizado, o tamanho do pacote (SDU) pode ser redimensionado na configuração da rede para melhor se adequar à situação (ou seja, um número limitado de grandes viagens de ida e volta). Ele tende a reduzir os eventos de espera "SQL*Net mais dados para o cliente" e "SQL*Net mais dados do cliente".
