Grundlæggende er oracles standardstrategi for de seneste ojdbc-jars at "pre-allokere" et array pr. "prefetch"-række, der rummer den størst mulige størrelse at returnere fra den forespørgsel. For alle rækker. Så i mit tilfælde havde jeg noget VARCHAR2(4000) derinde, og 50 tråde (erklæringer) * 3 kolonner af varchar2's * 4000 samlede op til mere end gigabyte RAM med en setFetchSize på et par hundrede [yikes]. Der ser ikke ud til at være en mulighed for at sige "tildel ikke det array på forhånd, brug bare størrelsen, når de kommer ind." Ojdbc holder endda disse forudtildelte buffere omkring mellem forberedte erklæringer (cache/forbindelse), så den kan genbruge dem. Absolut et mindesvin.
En løsning:brug setFetchSize til et eller andet fornuftigt beløb. Standard er 10, hvilket kan være ret langsomt på forbindelser med høj latency. Profil og brug kun så høj af setFetchSize, som faktisk gør væsentlige hastighedsforbedringer.
En anden løsning er at bestemme den maksimale faktiske kolonnestørrelse og derefter erstatte forespørgslen med (forudsat at 50 er den kendte maksimale faktiske størrelse) select substr(column_name, 0, 50)
Andre ting du kan gøre:mindske antallet af forhåndshentningsrækker, øge java -Xmx parameter, skal du kun vælge de kolonner, du faktisk har brug for.
Da vi var i stand til at bruge mindst prefetch 400 [sørg for at profilere dig for at se, hvilke tal der er gode for dig, med høj latenstid så vi forbedringer op til prefetch-størrelse 3-4K] på alle forespørgsler, forbedret ydeevnen dramatisk.
Jeg formoder, at hvis du ville være virkelig aggressiv over for sparsomme "virkelig lange" rækker, kunne du måske forespørge igen, når du støder på disse [sjældne] store rækker.
Detaljer ad nauseum her