Il comportamento delle LOB Oracle è il seguente.
Un LOB viene memorizzato inline 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
)
Una LOB viene archiviata fuori riga 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
)
Questo non è l'unico problema che può influire sulle prestazioni.
Se infine le LOB non vengono archiviate inline, il comportamento predefinito di Oracle consiste nell'evitare di memorizzarle nella cache (solo le LOB inline vengono memorizzate nella cache del buffer con gli altri campi della riga). Per indicare a Oracle di memorizzare nella cache anche le LOB non inline, l'opzione CACHE deve essere utilizzata quando la LOB è definita.
Il comportamento predefinito è ABILITA ARCHIVIAZIONE IN RIGA e NOCACHE, il che significa che i LOB piccoli verranno inseriti, i LOB grandi no (e non verranno memorizzati nella cache).
Infine, c'è anche un problema di prestazioni a livello di protocollo di comunicazione. I client Oracle tipici eseguiranno 2 roundtrip aggiuntivi per LOB per recuperarli:- uno per recuperare la dimensione del LOB e allocare memoria di conseguenza- uno per recuperare i dati stessi (a condizione che il LOB sia piccolo)
Questi roundtrip aggiuntivi vengono eseguiti anche se viene utilizzata un'interfaccia di matrice per recuperare i risultati. Se recuperi 1000 righe e la dimensione dell'array è sufficientemente grande, pagherai 1 andata e ritorno per recuperare le righe e 2000 andata e ritorno per recuperare il contenuto delle LOB.
Tieni presente che non dipende dal fatto che la LOB sia memorizzata inline o meno. Sono problemi completamente diversi.
Per ottimizzare a livello di protocollo, Oracle ha fornito un nuovo verbo OCI per recuperare più LOB in un roundtrip (OCILobArrayRead). Non so se esiste qualcosa di simile con JDBC.
Un'altra opzione è associare la LOB sul lato client come se fosse un grande RAW/VARCHAR2. Funziona solo se è possibile definire una dimensione massima del LOB (poiché la dimensione massima deve essere fornita al momento del binding). Questo trucco evita i viaggi di andata e ritorno extra:i LOB vengono semplicemente elaborati come RAW o VARCHAR2. Lo usiamo molto nelle nostre applicazioni LOB intensive.
Una volta che il numero di roundtrip è stato ottimizzato, la dimensione del pacchetto (SDU) può essere ridimensionata nella configurazione di rete per adattarsi meglio alla situazione (cioè un numero limitato di grandi roundtrip). Tende a ridurre gli eventi di attesa "SQL*Net più dati al client" e "SQL*Net più dati dal client".
