Chování Oracle LOB je následující.
LOB je uložen inline, když:
(
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
)
LOB je uložen mimo řádek, když:
(
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
)
Nyní to není jediný problém, který může ovlivnit výkon.
Pokud LOB nakonec nejsou uloženy inline, výchozí chování Oracle je vyhnout se jejich ukládání do mezipaměti (pouze vložené LOBy jsou ukládány do mezipaměti s ostatními poli řádku). Chcete-li společnosti Oracle říci, aby také ukládala do mezipaměti nevložené objekty LOB, měla by se při definování LOB použít možnost CACHE.
Výchozí chování je ENABLE STORAGE IN ROW a NOCACHE, což znamená, že malé LOBy budou vloženy, velké LOBy nikoli (a nebudou uloženy do mezipaměti).
Konečně je zde také problém s výkonem na úrovni komunikačního protokolu. Typičtí klienti Oracle provedou 2 další zpáteční cesty na LOB, aby je načetli:- jeden pro načtení velikosti LOB a odpovídající alokaci paměti - jeden pro načtení samotných dat (za předpokladu, že LOB je malý)
Tyto další zpáteční cesty se provádějí, i když se k načtení výsledků používá rozhraní pole. Pokud načtete 1 000 řádků a velikost vašeho pole je dostatečně velká, zaplatíte za 1 zpáteční cestu k načtení řádků a 2 000 zpáteční cestu k načtení obsahu LOBů.
Upozorňujeme, že není závisí na skutečnosti, zda je LOB uložen inline nebo ne. Jsou to úplně jiné problémy.
Pro optimalizaci na úrovni protokolu poskytl Oracle nové sloveso OCI pro načtení několika LOBů v jednom zpátečním spojení (OCILobArrayRead). Nevím, jestli něco podobného existuje u JDBC.
Další možností je svázat LOB na straně klienta, jako by to byl velký RAW/VARCHAR2. Toto funguje pouze v případě, že lze definovat maximální velikost LOB (protože maximální velikost musí být poskytnuta v době vazby). Tento trik se vyhýbá zbytečným průtahům:LOBy jsou zpracovány jako RAW nebo VARCHAR2. Používáme ho hodně v našich intenzivních aplikacích LOB.
Jakmile je počet zpátečních cest optimalizován, lze velikost paketu (SDU) změnit v konfiguraci sítě tak, aby lépe odpovídala situaci (tj. omezenému počtu velkých zpátečních cest). Má tendenci redukovat čekací události „SQL*Net více dat klientovi“ a „SQL*Net více dat z klienta“.