Поведението на Oracle LOB е следното.
LOB се съхранява вградено, когато:
(
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 се съхранява извън реда, когато:
(
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
)
Сега това не е единственият проблем, който може да повлияе на производителността.
Ако най-накрая LOB не се съхраняват вградени, поведението по подразбиране на Oracle е да избягва кеширането им (само вградените LOB се кешират в буферния кеш с другите полета на реда). За да кажете на Oracle да кешира и невградени LOB, трябва да се използва опцията CACHE, когато LOB е дефиниран.
Поведението по подразбиране е ENABLE STORAGE IN ROW и NOCACHE, което означава, че малките LOB ще бъдат вградени, големите LOB няма (и няма да бъдат кеширани).
И накрая, има и проблем с производителността на ниво комуникационен протокол. Типичните клиенти на Oracle ще извършат 2 допълнителни двупосочни посещения на LOB, за да ги извлекат:- едно за извличане на размера на LOB и съответно разпределяне на памет - едно за извличане на самите данни (при условие, че LOB е малък)
Тези допълнителни обиколки се извършват дори ако се използва интерфейс на масив за извличане на резултатите. Ако извлечете 1000 реда и размерът на вашия масив е достатъчно голям, ще платите за 1 двупосочно пътуване за извличане на редовете и 2000 двупосочни посещения за извличане на съдържанието на LOB.
Моля, имайте предвид, че не не зависят от факта, че LOB се съхранява в линия или не. Това са напълно различни проблеми.
За да оптимизира на ниво протокол, Oracle предостави нов OCI глагол за извличане на няколко LOB в едно двупосочно преминаване (OCILobArrayRead). Не знам дали нещо подобно съществува с JDBC.
Друг вариант е да обвържете LOB от страна на клиента, сякаш е голям RAW/VARCHAR2. Това работи само ако може да се дефинира максимален размер на LOB (тъй като максималният размер трябва да бъде предоставен по време на свързване). Този трик избягва допълнителните обиколки:LOB просто се обработват като RAW или VARCHAR2. Използваме го много в нашите интензивни LOB приложения.
След като броят на двупосочните пътувания бъде оптимизиран, размерът на пакета (SDU) може да бъде преоразмерен в мрежовата конфигурация, за да пасне по-добре на ситуацията (т.е. ограничен брой големи двупосочни посещения). Има тенденция да намалява събитията за изчакване „SQL*Net повече данни към клиента“ и „SQL*Net повече данни от клиента“.
