Zachowanie obiektów Oracle LOB jest następujące.
LOB jest przechowywany w trybie inline, gdy:
(
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 jest przechowywany poza rzędem, gdy:
(
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
)
To nie jedyny problem, który może mieć wpływ na wydajność.
Jeśli obiekty LOB nie są w końcu przechowywane w trybie inline, domyślnym zachowaniem Oracle jest unikanie ich buforowania (tylko obiekty LOB w linii są buforowane w pamięci podręcznej bufora z innymi polami wiersza). Aby powiedzieć Oracle, aby również buforował niewbudowane obiekty LOB, należy użyć opcji CACHE, gdy obiekt LOB jest zdefiniowany.
Domyślnym zachowaniem jest ENABLE STORAGE IN ROW i NOCACHE, co oznacza, że małe obiekty LOB będą wbudowane, a duże nie (i nie będą buforowane).
Wreszcie, istnieje również problem z wydajnością na poziomie protokołu komunikacyjnego. Typowi klienci Oracle wykonają 2 dodatkowe rundy na każdy LOB, aby je pobrać:- jeden, aby pobrać rozmiar LOB i odpowiednio przydzielić pamięć - jeden, aby pobrać same dane (pod warunkiem, że LOB jest mały)
Te dodatkowe objazdy są wykonywane nawet wtedy, gdy do pobierania wyników używany jest interfejs tablicy. Jeśli pobierzesz 1000 wierszy, a rozmiar tablicy jest wystarczająco duży, zapłacisz za 1 podróż w obie strony, aby pobrać wiersze i 2000 podróży w obie strony, aby pobrać zawartość LOB.
Pamiętaj, że nie zależy od tego, czy LOB jest przechowywany w linii, czy nie. To zupełnie inne problemy.
Aby zoptymalizować na poziomie protokołu, firma Oracle udostępniła nowe zlecenie OCI umożliwiające pobranie kilku obiektów LOB w jednej rundzie (OCILobArrayRead). Nie wiem, czy coś podobnego istnieje w JDBC.
Inną opcją jest powiązanie LOB po stronie klienta tak, jakby był to duży RAW/VARCHAR2. Działa to tylko wtedy, gdy można zdefiniować maksymalny rozmiar LOB (ponieważ maksymalny rozmiar musi być podany w czasie wiązania). Ta sztuczka pozwala uniknąć dodatkowych okrążeń:LOB są przetwarzane jak RAW lub VARCHAR2. Używamy go bardzo często w naszych aplikacjach intensywnie korzystających z LOB.
Po zoptymalizowaniu liczby podróży w obie strony można zmienić rozmiar pakietu (SDU) w konfiguracji sieci, aby lepiej dopasować się do sytuacji (tj. ograniczonej liczby dużych podróży w obie strony). Ma tendencję do zmniejszania zdarzeń oczekiwania "SQL*Net więcej danych do klienta" i "SQL*Net więcej danych od klienta".
