El comportamiento de los LOB de Oracle es el siguiente.
Un LOB se almacena en línea cuando:
(
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
)
Un LOB se almacena fuera de fila cuando:
(
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
)
Ahora bien, este no es el único problema que puede afectar el rendimiento.
Si los LOB finalmente no se almacenan en línea, el comportamiento predeterminado de Oracle es evitar almacenarlos en caché (solo los LOB en línea se almacenan en caché en el caché del búfer con los otros campos de la fila). Para indicarle a Oracle que también almacene en caché los LOB no alineados, se debe usar la opción CACHE cuando se define el LOB.
El comportamiento predeterminado es HABILITAR ALMACENAMIENTO EN FILA y NOCACHE, lo que significa que los LOB pequeños se alinearán, los LOB grandes no (y no se almacenarán en caché).
Finalmente, también hay un problema de rendimiento a nivel del protocolo de comunicación. Los clientes típicos de Oracle realizarán 2 viajes de ida y vuelta adicionales por LOB para obtenerlos:uno para recuperar el tamaño del LOB y asignar la memoria en consecuencia, uno para obtener los datos en sí (siempre que el LOB sea pequeño)
Estos viajes de ida y vuelta adicionales se realizan incluso si se utiliza una interfaz de matriz para recuperar los resultados. Si recupera 1000 filas y el tamaño de su matriz es lo suficientemente grande, pagará 1 viaje de ida y vuelta para recuperar las filas y 2000 viajes de ida y vuelta para recuperar el contenido de los LOB.
Tenga en cuenta que no depende del hecho de que el LOB se almacene en línea o no. Son problemas completamente diferentes.
Para optimizar a nivel de protocolo, Oracle ha proporcionado un nuevo verbo OCI para obtener varios LOB en un viaje de ida y vuelta (OCILobArrayRead). No sé si existe algo similar con JDBC.
Otra opción es vincular el LOB en el lado del cliente como si fuera un gran RAW/VARCHAR2. Esto solo funciona si se puede definir un tamaño máximo de LOB (ya que el tamaño máximo se debe proporcionar en el momento del enlace). Este truco evita los viajes de ida y vuelta adicionales:los LOB simplemente se procesan como RAW o VARCHAR2. Lo usamos mucho en nuestras aplicaciones intensivas de LOB.
Una vez que se ha optimizado el número de viajes de ida y vuelta, se puede cambiar el tamaño del paquete (SDU) en la configuración de red para adaptarse mejor a la situación (es decir, un número limitado de viajes de ida y vuelta grandes). Tiende a reducir los eventos de espera "SQL*Net más datos para el cliente" y "SQL*Net más datos del cliente".
