Dedicated and shared server

If you are running in 9i or above, there are two parameters (not one) which govern whether or not you are capable of running in shared server mode.

With dispatchers and shared server processes configured, in other words, an instance can "support shared server connection requests". That's rather different than "running in shared server mode". The distinction is important because privileged actions (startup, shutdown, backup and recover commands) cannot be processed by a shared server process, so it's important for an instance that is configured for normal users to use shared server processes to still support the connection to dedicated server processes by suitably credentialled users.If a user does end up connected to a shared server process, there is usually a performance penalty to pay compared to using a dedicated server process. A user submits a query and instead of it being immediately processed by a server process, it gets submitted to a dispatcher ...which promptly sticks it on a job queue! You then have to wait for a shared server process to become free and decide to pick your job off the queue. That's inevitably slower than doing it the dedicated way.

People use shared server as the first line of scaling up their databases... and you're right that it primarily depends on the number of users connected to the server concurrently. In dedicated server mode, a new connection means a new process gets spawned (or a new thread on Windows) and a new connection socket is opened. Servers can only handle so many connection sockets, processes or threads before they start to keel over under the strain. Shared server, as the name suggest, means that new connections do not cause new server processes to be spawned. So 300 users can be processed with, maybe, 30 or 40 processes in total. If your box would normally keel over handling 300 dedicated connections, then clearly with that sort of sharing ratio, you'd be able to scale to nearer 3000 users before it starts wilting by using shared processes.

But it's also a bit subtler than that: a data warehouse would be daft to implement shared server, even if it did have 300+ concurrent users. That's because the users of such systems typically run queries that run for hours... and a shared process that is nabbed to perform one job for hours on end isn't really a shared process any more, is it?! So the rule of thumb as to when to implement shared server is yes, (a) when your concurrent user count starts reaching levels that your server just doesn't seem able to sustain any more AND (b) when you can be sure that the users tend to issue short, sharp queries -say, about 3 seconds or so to process, max.

Again, there are mixed states to get through, too. You might have lots of OLTP-type sub-3-second transactions on the same database on which one or two users regularly run big reports. In that case, you make sure the reporters have a tnsnames.ora that says SERVER=DEDICATED and the OLTP-type people use one that has SERVER=SHARED in it; configure the DISPATCHERS and SHARED_SERVER parameters for the instance and then those that can benefit from shared servers can do so and those that wouldn't won't be stealing shared processes from those that can!

The alternative approach for those with more cash is to go and buy better server hardware that can cope with the user community numbers! Shared Server configuration, however, comes free. You pays your money and you takes your choices!

-- Doc by HJR