Re: slower fetch speed with oracle client 19c vs 11g

From: Jonathan Lewis <jlewisoracle_at_gmail.com>
Date: Tue, 21 Feb 2023 11:08:45 +0000
Message-ID: <CAGtsp8=KYCv2iGZe-BpAtFNa454QDoWqc=khEC4AEsp9AL3aeA_at_mail.gmail.com>



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_at_gmail.com> 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.
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 21 2023 - 12:08:45 CET

Original text of this message