Oracle LOBs beteende är följande.
En LOB lagras inline när:
(
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
)
En LOB lagras utanför raden när:
(
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
)
Nu är detta inte det enda problemet som kan påverka prestandan.
Om LOB:erna slutligen inte lagras inline, är standardbeteendet för Oracle att undvika att cachelagra dem (endast inline LOB:er cachelagras i buffertcachen med de andra fälten i raden). För att tala om för Oracle att också cachelagra icke-inlagda LOB:er, bör alternativet CACHE användas när LOB är definierad.
Standardbeteendet är ENABLE STORAGE IN ROW och NOCACHE, vilket innebär att små LOB:er infogas, stora LOB:er inte (och kommer inte att cachelagras).
Slutligen finns det också ett prestandaproblem på kommunikationsprotokollnivå. Typiska Oracle-klienter kommer att utföra 2 extra rundresor per LOB för att hämta dem:- en för att hämta storleken på LOB och allokera minne därefter- en för att hämta själva data (förutsatt att LOB är liten)
Dessa extra rundresor utförs även om ett array-gränssnitt används för att hämta resultaten. Om du hämtar 1000 rader och din arraystorlek är tillräckligt stor, betalar du för 1 tur och retur för att hämta raderna och 2000 tur och retur för att hämta innehållet i LOB:erna.
Observera att det inte gör det beror på det faktum att LOB är lagrad inline eller inte. De är helt olika problem.
För att optimera på protokollnivå har Oracle tillhandahållit ett nytt OCI-verb för att hämta flera LOB:er på en runda (OCILobArrayRead). Jag vet inte om något liknande finns med JDBC.
Ett annat alternativ är att binda LOB på klientsidan som om det vore en stor RAW/VARCHAR2. Detta fungerar bara om en maximal storlek på LOB kan definieras (eftersom den maximala storleken måste anges vid bindning). Detta trick undviker de extra rundresorna:LOB:erna bearbetas bara som RAW eller VARCHAR2. Vi använder det mycket i våra LOB-intensiva applikationer.
När väl antalet tur- och returresor har optimerats kan storleken på paketstorleken (SDU) ändras i nätkonfigurationen för att bättre passa situationen (dvs. ett begränsat antal stora tur- och returresor). Det tenderar att reducera väntehändelserna "SQL*Net more data to client" och "SQL*Net more data from client".