Re: Execution time in SHARED SERVER vs. DEDICATED SERVER (RAC 10gR2)

Hi Krish,

thanks for your reply.

krish.hariharan_at_quasardb.com schrieb:
> There are differences in the path and path length to the client (shared
> server, dispatcher, request queue, response queue, where sort area is
> managed, etc).

That's something to look after.

> If a query runs for that long, I don't think it is a candidate to be
> switched over to the shared server, to begin with; you are violating the
> principle of sharing by dedicating the shared server to a connection!
I did not switch over, the statement just was slow on the application server (ded) and fast on the web server (shared), and we wondered why. There's no need to fuss around this way.

> From an academic point of view, all other things being equal, I would not
> expect that large a difference if your result set is small, I would think
> that some amount of time would be devoted to managing the memory spaces in
> SGA vs the PGA but a 50% increase is not what I would have expected. What
> were the wait events during that time or rather, what were the differences?

We started the same queries (remember, it's not one special query) at the same time for test, the execution plans have been byte-identical, the needed IOs in our test have been at 1.030 IOs at all. 90% of the wait in both (ded and shared) cases was CPU, but in one case for seconds, in dedicated mode for hours.

We are talking about a UAT system here: The appropriate production system does not have this problems (UAT was created by rman/DUPLICATE DATABASE TO...).
First idea was, that server-side load balancing was different on shared and dedicated services. First of all, that was wrong, all values have been default/equal. But changing it to throughput optimization by load balancing advisory (like production is set up like) didn't change anything in behaviour - it simply has nothing to to with SSLB.

I just don't know...

Thanks for all new ideas
Martin

-- 
Usn's IT Blog for Linux, Oracle, Asterisk
www.usn-it.de

--
http://www.freelists.org/webpage/oracle-l