The fetch size might be the same, which would make the number of SQL*Net
round-trips the same, but are the setting for the SDU (session data unit)
the same. Extra time might mean a smaller SDU size on the 19c setup. If you
can't check it directly then check to see if the number of "sql*net MORE
DATA to client" waits is larger for 19c than it is for 11g.
Another possible cause for the difference in time could be something to do
with character set translation. If the 11g client and 11g server are using
the same character set then there's no time spent in SQL*Net on
translation, but if (somehow) the 19c installation has managed to introduce
a change in characterset then SQL*Net could be using CPU on the
translation. You might see this as a change in the statistics relating to
"bytes sent/received via SQL*net" - but you might have to create a custom
test to be able to see/measure it (it might also be another cause of
increases in "more data" waits
Regards
Jonathan Lewis
On Tue, 21 Feb 2023 at 10:46, Laurentiu Oprea <laurentiu.oprea06@xxxxxxxxx>
wrote:
Dear colleagues,
It started like a performance investigation where DB was blamed that after
an application upgrade queries started to be slower. We managed to isolate
the issue to only the oracle client.
They are using an application (qlikview) using OLEdb for oracle driver.
When they configure it with the oracle client 19c is fetching almost 50%
slower compared with the 11g client. Everything is identical in rest. I saw
from the sql monitor report that the same fetch size is used, probably this
is dictated by the driver which is the same in both cases.
Anyone have any idea what could be the issue here?
Appreciate your help,
Laurentiu.
