bits and pieces, here and there, over time. The optimizer would not use that technique if the client was a shared server (eg: you can and still will get different plans for the same exact query based on part on the fact you have a shared server connect versus a dedicated server)

It'll mostly only affect large DW type queries.

I would equate this with a db upgrade, a patch, a tweak, a change. You should test. Do you have adequate shared servers configured? Do you need shared server? those would be more relevant probably then the query plan changes.

I think you meant chapter 3.

a1) because a single client process may open more then one session at a time. There is a CONNECTION, then within connections you create sessions -- as many as you need. typically -- this is "one session"

but you changed my words when you say:

<quote>
In a dedicated server connection, why dosen't it mean that every single
connection has a dedicated server?
</quote>

in a dedicated server connect, every CONNECTION does have a dedicated server, however, each SESSION need not have one.


a2) they are not possible simultaneously. you've taken some things out of context. Allow me to reproduce the text in question:


<quote>
So, in dedicated server mode, there is a one-to-one mapping between processes in the database and a client process. Every dedicated server connection has a dedicated server allocated solely to it. That does not mean every single session has a dedicated server, for it is possible for a single application, using a single physical connection (dedicated server) to have many sessions concurrently active. In general however, when in dedicated server mode, there is a one to one relationship between a session and a dedicated server.
</quote>

you left out the "IN GENERAL HOWEVER" that time, a key modifier -- in general, there is a one to one relationship. What MOST people will observe in practice is a one to one relationship. However, there need not be a one to one relationship.


1) that is not a client decision -- the database must be setup for it as well. I do not consider rewriting configuration files to be a "client decision". The database must be setup for shared server

2) the database, when it registers itself with the listener, decides how the service will work.

3) the listener and database deal with that.

4) dedicated is default out of the box (always there)

sqlplus is an example.

when you set autotrace on with statistics -- sqlplus will actually use TWO sessions -- one you interact with and run the query in and another that watches your statistics (so as to not have the watching of the statistics INFLUENCE the statistics themselves!)

so, there you have a case where by you have one connection (physical circut from client to server) but more then one session.

forms does it -- for debugging.


app servers do it, for connection pooling.

because you need a dedicated server for them -- consider that in order to startup for example, you need "something" there. if the "something" was a shared server -- the database would already be up, for you cannot have a shared server without a database instance! it would be a chicken and egg, similar with shutdown -- in order to shutdown, there will be no instance. if there is no instance, there can be no shared server, if you don't have a shared server, you cannot shutdown cleanly.

if you have 50,000 CLIENT SERVER users (if you are 50,000 users connected over a stateless web application - you don't need to consider shared server, you already have a connection pool...) you need to ask yourself:

o how many do I want to be concurrently active at any point in time.

pick that number, set that number. That is the number of concurrent active sessions you feel your hardware can deal with.

If you have 50,000 client server users that run statements are measured in 10's of seconds - you have a much bigger problem.


There is AQ + streams (complimentary technologies).

your session migrates from process to process in shared server.

In shared server, your session only has a process when your session is actively doing something in the database. Every request you make in shared server might use a different operating system process to perform the work (unlike dedicated server where you have your own process and your session is bound to that process).

Your session "migrates" from process to process - moves.