Le comportement des LOB Oracle est le suivant.
Un LOB est stocké en ligne lorsque :
(
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
)
Un LOB est stocké hors ligne lorsque :
(
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
)
Ce n'est pas le seul problème susceptible d'affecter les performances.
Si les LOBs ne sont finalement pas stockés en ligne, le comportement par défaut d'Oracle est d'éviter de les mettre en cache (seuls les LOBs en ligne sont mis en cache dans le buffer cache avec les autres champs de la ligne). Pour indiquer à Oracle de mettre également en cache les LOB non intégrés, l'option CACHE doit être utilisée lorsque le LOB est défini.
Le comportement par défaut est ENABLE STORAGE IN ROW et NOCACHE, ce qui signifie que les petits LOB seront intégrés, les grands LOB ne le seront pas (et ne seront pas mis en cache).
Enfin, il existe également un problème de performance au niveau du protocole de communication. Les clients Oracle typiques effectueront 2 allers-retours supplémentaires par LOB pour les récupérer :- un pour récupérer la taille du LOB et allouer de la mémoire en conséquence - un pour récupérer les données elles-mêmes (à condition que le LOB soit petit)
Ces allers-retours supplémentaires sont effectués même si une interface de tableau est utilisée pour récupérer les résultats. Si vous récupérez 1000 lignes et que la taille de votre tableau est suffisamment grande, vous paierez 1 aller-retour pour récupérer les lignes et 2000 allers-retours pour récupérer le contenu des LOB.
Veuillez noter que ce n'est pas dépendent du fait que le LOB est stocké en ligne ou non. Ce sont des problèmes complètement différents.
Pour optimiser au niveau du protocole, Oracle a fourni un nouveau verbe OCI pour récupérer plusieurs LOB en un aller-retour (OCILobArrayRead). Je ne sais pas si quelque chose de similaire existe avec JDBC.
Une autre option consiste à lier le LOB côté client comme s'il s'agissait d'un gros RAW/VARCHAR2. Cela ne fonctionne que si une taille maximale du LOB peut être définie (puisque la taille maximale doit être fournie au moment de la liaison). Cette astuce évite les allers-retours supplémentaires :les LOB sont simplement traités comme RAW ou VARCHAR2. Nous l'utilisons beaucoup dans nos applications intensives LOB.
Une fois le nombre d'allers-retours optimisé, la taille des paquets (SDU) peut être redimensionnée dans la configuration du réseau pour mieux s'adapter à la situation (c'est-à-dire un nombre limité d'allers-retours importants). Il a tendance à réduire les événements d'attente "SQL*Net more data to client" et "SQL*Net more data from client".
