1 2 Previous Next 27 Replies Latest reply on Jan 16, 2013 8:45 AM by Maahjoor

    dedicated/shared mode

      Dear all,

      How to ensure that my database is running in dedicated or shared server mode.

      Thanks in advance
        • 1. Re: dedicated/shared mode
          check V$SESSION.SERVER.

          Actually you can have on the same instance sessions in dedicated or shared mode depending on your Oracle Net configurations.
          • 2. Re: dedicated/shared mode
            Well have you searched here


            I am not giving a chilled beer this time

            • 3. Re: dedicated/shared mode
              Maran Viswarayar
              Ensure or Check?

              select * from v$shared_server
              • 4. Re: dedicated/shared mode

                select * from v$shared_server

                gives the following output
                Name PaDDR                  Status                
                S000 070000001F2980D0 WAIT(COMMON)     

                message breaks bytes
                0.00        0.00     0.00

                circuit   idle
                00        284.846.678.00

                busy        requests
                0.00     0.00
                • 5. Re: dedicated/shared mode
                  If there is a dispatcher configured (which is done by default for the XDB protocol), it will run in shared server mode, whether you use it or not.
                  Ie: the large pool will be used, if you didn't configure the large pool, the shared pool.

                  Sybrand Bakker
                  Senior Oracle DBA
                  • 6. Re: dedicated/shared mode
                    If there is a dispatcher configured
                    Are you talking about the mts_dispatcher
                    I checked the mts_dispatcher and there is no value assigned.

                    • 7. Re: dedicated/shared mode
                      dispatcher or mts_dispatcher depending on version.

                      If the parameter is empty: no dedicated server.
                      If the parameter is non-empty, but you don't use it: database will be running in shared server mode.

                      Sybrand Bakker
                      Senior Oracle DBA
                      • 8. Re: dedicated/shared mode
                        dispatcher or mts_dispatcher depending on version.
                        Sorry, the parameter dispatcher has the following
                        (PROTOCOL=TCP) (SERVICE=timXDB)

                        however mts_dispatcher is empty.

                        So it is dedicated server?

                        • 9. Re: dedicated/shared mode
                          No, the database runs in shared server mode: the large pool will be used.
                          If you didn't configure the large pool, the memory will be taken from the shared pool.
                          You can easily confirm this by running a full version (with the DBA module) of Toad against the database and use the Database probe tool.
                          It will complain about dedicated sessions in a shared server database.

                          Sybrand Bakker
                          Senior Oracle DBA
                          • 10. Re: dedicated/shared mode

                            The shared_servers, is it larger than 0? and check your listener with lsnrctl services to accept incoming shared connection,


                            • 11. Re: dedicated/shared mode
                              It will complain about dedicated sessions in a shared
                              server database.
                              Yes I could see that there are dedicated sessions by using Database probe.


                              One last question: How does it have effect on performance or it depends on number of users being connected to the server.
                              Message was edited by:
                              • 12. Re: dedicated/shared mode
                                I'll just summarise, because I can see some rather iffy advice being offered in this thread.

                                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.

                                DISPATCHERS governs whether a job dispatcher runs. You have to have at least one of them configured before shared server is possible. However, the mere fact that a dispatcher runs does NOT mean your database is running in shared server mode. There also have to be shared server processes capable of handling the work dispatched by the dispatcher(s), and those are configured with the SHARED_SERVERS parameter. If that's set to any number greater than 1, you have shared server processes running on your instance. But that STILL doesn't mean you're running in shared server mode! If you have SHARED_SERVERS=57 and no dispatcher, you simply have 57 processes sitting around doing nothing whatsoever (and incapable of doing useful work!)

                                In short, you have to have DISPATCHERS and SHARED_SERVERS set.

                                Note, for example, that 10g configures a single dispatcher for all databases by default (if they're created with DBCA and you don't get in there to stop it happeneing), but it does NOT configure SHARED_SERVERS, so by default a 10g database does not run in shared server mode.

                                The other thing I'd clarify is that a database doesn't really run in shared server mode anyway! The fact that your instance has a dispatcher and shared server processes running doesn't necessarily mean your users will end up connected to the dispatcher and having shared server processes handling their job requests. They will by default, but if the tnsnames.ora they use to connect (or its centralised equivalent) contains the line SERVER=DEDICATED, then they will get to use dedicated server processes, no matter what the dispatcher or shared server processes might think about it!

                                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!
                                • 13. Re: dedicated/shared mode
                                  Great post! You're good!! :)

                                  Message was edited by:
                                  • 14. Re: dedicated/shared mode
                                    Yes, i agree.

                                    I wonder if Howard has ambitions to write a book about oracle - i think its very likely that it would become a new bestseller.
                                    1 2 Previous Next