I grund och botten är Oracles standardstrategi för de senaste ojdbc jars att "förallokera" en array per "prefetch"-rad som rymmer den största tänkbara storleken att returnera från den frågan. För alla rader. Så i mitt fall hade jag några VARCHAR2(4000) där, och 50 trådar (uttalanden) * 3 kolumner av varchar2:s * 4000 blev mer än gigabyte RAM-minne med en setFetchSize på några hundra [yike]. Det verkar inte finnas ett alternativ att säga "fördela inte den arrayen i förväg, använd bara storleken när de kommer in." Ojdbc håller till och med dessa förallokerade buffertar runt mellan förberedda uttalanden (cachad/anslutning) så att den kan återanvända dem. Definitivt ett minnessvin.
En lösning:använd setFetchSize till något vettigt belopp. Standard är 10 vilket kan vara ganska långsamt på anslutningar med hög latens. Profilera och använd bara så hög av setFetchSize som faktiskt gör betydande hastighetsförbättringar.
En annan lösning är att fastställa den maximala faktiska kolumnstorleken och sedan ersätta frågan med (förutsatt att 50 är den kända maximala faktiska storleken) select substr(column_name, 0, 50)
Andra saker du kan göra:minska antalet förhämtningsrader, öka java -Xmx Välj bara de kolumner du faktiskt behöver.
När vi väl kunde använda åtminstone förhämtning 400 [se till att profilera för att se vilka siffror som är bra för dig, med hög latens såg vi förbättringar upp till förhämtningsstorleken 3-4K] på alla frågor, förbättrades prestandan dramatiskt.
Jag antar att om du ville vara riktigt aggressiv mot glesa "riktigt långa" rader så kanske du skulle kunna fråga igen när du stöter på dessa [sällsynta] stora rader.
Detaljer ad nauseum här