Oracle LOBs adfærd er følgende.
En LOB er gemt 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 gemmes uden for rækken, 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 er dette ikke det eneste problem, der kan påvirke ydeevnen.
Hvis LOB'erne endelig ikke gemmes inline, er standardadfærden for Oracle at undgå at cache dem (kun inline LOB'er cachelagres i buffercachen med de andre felter i rækken). For at bede Oracle om også at cache ikke-indlejrede LOB'er, skal CACHE-indstillingen bruges, når LOB'en er defineret.
Standardadfærden er ENABLE STORAGE IN ROW og NOCACHE, hvilket betyder, at små LOB'er bliver inlinet, store LOB'er vil ikke (og vil ikke blive cachelagret).
Endelig er der også et præstationsproblem på kommunikationsprotokolniveau. Typiske Oracle-klienter vil udføre 2 yderligere rundrejser pr. LOB'er for at hente dem:- en for at hente størrelsen af LOB'en og allokere hukommelse i overensstemmelse hermed- en til at hente selve dataene (forudsat at LOB'en er lille)
Disse ekstra rundrejser udføres, selvom en array-grænseflade bruges til at hente resultaterne. Hvis du henter 1000 rækker, og din matrixstørrelse er stor nok, betaler du for 1 tur/retur for at hente rækkerne og 2000 tur/retur for at hente indholdet af LOB'erne.
Bemærk venligst, at det ikke gør det afhænger af, om LOB'en er gemt inline eller ej. De er fuldstændig forskellige problemer.
For at optimere på protokolniveau har Oracle leveret et nyt OCI-verb til at hente flere LOB'er på én rundrejse (OCILobArrayRead). Jeg ved ikke, om noget lignende findes med JDBC.
En anden mulighed er at binde LOB på klientsiden, som om det var en stor RAW/VARCHAR2. Dette virker kun, hvis der kan defineres en maksimal størrelse af LOB'en (da den maksimale størrelse skal angives på bindetidspunktet). Dette trick undgår de ekstra roundtrips:LOB'erne behandles bare som RAW eller VARCHAR2. Vi bruger det meget i vores LOB-intensive applikationer.
Når antallet af rundrejser er blevet optimeret, kan størrelsen på pakkestørrelsen (SDU) ændres i netkonfigurationen for bedre at passe til situationen (dvs. et begrænset antal store rundrejser). Det har en tendens til at reducere ventehændelserne "SQL*Net flere data til klient" og "SQL*Net flere data fra klient".