Het gedrag van Oracle LOB's is als volgt.
Een LOB wordt inline opgeslagen wanneer:
(
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
)
Een LOB wordt buiten de rij opgeslagen wanneer:
(
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
)
Dit is niet het enige probleem dat de prestaties kan beïnvloeden.
Als de LOB's uiteindelijk niet inline worden opgeslagen, is het standaardgedrag van Oracle om ze niet in de cache op te slaan (alleen inline LOB's worden in de buffercache opgeslagen met de andere velden van de rij). Om Oracle te vertellen dat het ook niet-inline LOB's moet cachen, moet de CACHE-optie worden gebruikt wanneer de LOB is gedefinieerd.
Het standaardgedrag is OPSLAG IN RIJ INSCHAKELEN en NOCACHE, wat betekent dat kleine LOB's inline worden geplaatst, grote LOB's niet (en zullen niet in de cache worden opgeslagen).
Ten slotte is er ook een prestatieprobleem op het niveau van het communicatieprotocol. Typische Oracle-clients zullen 2 extra roundtrips per LOB's uitvoeren om ze op te halen:- één om de grootte van de LOB op te halen en dienovereenkomstig geheugen toe te wijzen - één om de gegevens zelf op te halen (op voorwaarde dat de LOB klein is)
Deze extra roundtrips worden zelfs uitgevoerd als een array-interface wordt gebruikt om de resultaten op te halen. Als je 1000 rijen ophaalt en je array is groot genoeg, dan betaal je voor 1 roundtrip om de rijen op te halen en 2000 roundtrips om de inhoud van de LOB's op te halen.
Let op:dit doet niet afhankelijk van het feit of de LOB al dan niet inline is opgeslagen. Het zijn totaal verschillende problemen.
Om op protocolniveau te optimaliseren, heeft Oracle een nieuw OCI-werkwoord geleverd om meerdere LOB's in één rondreis op te halen (OCILobArrayRead). Ik weet niet of er iets soortgelijks bestaat met JDBC.
Een andere optie is om de LOB aan de clientzijde te binden alsof het een grote RAW/VARCHAR2 is. Dit werkt alleen als er een maximale grootte van de LOB kan worden gedefinieerd (aangezien de maximale grootte moet worden opgegeven op het moment van binden). Deze truc vermijdt de extra roundtrips:de LOB's worden gewoon verwerkt zoals RAW of VARCHAR2. We gebruiken het veel in onze LOB-intensieve applicaties.
Zodra het aantal retourvluchten is geoptimaliseerd, kan de pakketgrootte (SDU) in de netconfiguratie worden aangepast om beter bij de situatie te passen (d.w.z. een beperkt aantal grote rondreizen). Het heeft de neiging de wachtgebeurtenissen "SQL*Net more data to client" en "SQL*Net more data from client" te verminderen.